Your cart is currently empty!
DFSS Instructor Prep · Module 10
Layer C — Tier 3 Contextual Awareness
ISO 26262 + ASPICE + ISO/SAE 21434
The three frameworks that govern software-bearing automotive products. Functional safety prevents the vehicle from harming users due to malfunction. ASPICE prevents bad software-engineering process from producing those malfunctions. Cybersecurity prevents an adversary from creating the malfunction. This module gives you instructor-level awareness — not full compliance mastery — of all three. Enough literacy to engage participants whose work lives inside these frameworks.
What’s in this module
- The three frameworks at a glance — and how they relate
- ISO 26262 — functional safety fundamentals
- ASIL classification — Severity × Exposure × Controllability
- The V-model lifecycle
- ASIL decomposition & allocation
- ASPICE — process capability for automotive software
- The six capability levels (CL0–CL5)
- ASPICE 4.0 — what’s new (2023)
- ISO/SAE 21434 — cybersecurity engineering
- UN R155 / R156 — type-approval cyber requirements
- How the three frameworks interact
- DFSS linkage — DMADV through safety / process / cyber
- Instructor facilitation pattern
- Self-check (10 questions)
1. The three frameworks at a glance
ISO 26262
“Will the product harm someone due to malfunction?”
Functional safety standard. 2nd Edition (2018). Defines ASIL classification A-D, hazard analysis (HARA), V-model lifecycle, requirements for hardware and software. Driven by potential harm to humans.
ASPICE
“Was the product built using good engineering process?”
Process capability framework. Version 4.0 (Dec 2023). Six capability levels (CL0–CL5). Most OEMs require CL2 minimum, CL3 for safety-critical software. Driven by repeatability and quality of development process.
ISO/SAE 21434
“Can an adversary harm someone by attacking the product?”
Cybersecurity engineering. Published 2021. Defines Cybersecurity Management System (CSMS), TARA (Threat Analysis & Risk Assessment), CAL (Cybersecurity Assurance Levels). Mandatory via UN R155 for new types.
The clearest way to keep them apart
Safety (ISO 26262) = the product fails by itself in a way that harms users.Process (ASPICE) = how the team built the software — independent of the outcome.
Security (ISO 21434) = an adversary deliberately makes the product fail.
Modern programmes must address all three in parallel. They share artefacts (especially safety + cyber TARA), but they’re distinct disciplines.
2. ISO 26262 — functional safety fundamentals
ISO 26262 (“Road vehicles — Functional Safety”) is the international standard governing safety of electrical and electronic systems in vehicles. First published 2011; 2nd Edition released 2018 brought all road vehicles into scope (except mopeds), added semiconductors and motorcycles.
The standard has 12 parts:
| Part | Scope |
|---|---|
| Part 1 | Vocabulary |
| Part 2 | Management of functional safety |
| Part 3 | Concept phase (HARA & safety goals) |
| Part 4 | System-level development (highlighted for Yazaki context) |
| Part 5 | Hardware-level development |
| Part 6 | Software-level development (highlighted for software-bearing Yazaki products) |
| Part 7 | Production, operation, service, decommissioning |
| Part 8 | Supporting processes |
| Part 9 | ASIL-oriented and safety-oriented analyses |
| Part 10 | Guideline |
| Part 11 | Semiconductors (added in 2018) |
| Part 12 | Motorcycles (added in 2018) |
The 8-step lifecycle in one line
Identify hazards → Assign ASIL → Define safety goals → Define system architecture → Decompose into requirements → Allocate to subsystems → Implement → Verify & validate.
3. ASIL classification — the heart of ISO 26262
ASIL (Automotive Safety Integrity Level) is the central mechanism. Every safety goal gets an ASIL rating that determines how rigorous the engineering must be.
The five classifications
QM
Quality Mgmt
No special functional-safety measures — handled by normal IATF 16949 quality processes
A
Lowest
e.g. interior lighting control, rear wiper, climate display
B
Medium
e.g. rear camera, AR-HUD overlay, taillight failure
C
High
e.g. ABS, airbag deployment, ESC, partial ADAS
D
Highest
e.g. EPS (steering), AEB (automatic emergency brake), HV pre-charge contactor weld
How ASIL is determined: the S × E × C formula
Three parameters combine to determine ASIL. Each has 3-5 levels.
| Parameter | What it measures | Levels |
|---|---|---|
| S — Severity | How badly will someone be hurt if this hazard occurs? | S0 (no injuries) → S1 (light) → S2 (severe, survivable) → S3 (life-threatening, fatal) |
| E — Exposure | How often is the vehicle in a state where this hazard could occur? | E0 (incredible) → E1 (very low) → E2 (low) → E3 (medium) → E4 (high — typical driving) |
| C — Controllability | If the hazard occurs, how easily can the driver (or others) avoid harm? | C0 (controllable in general) → C1 (simply controllable) → C2 (normally controllable) → C3 (difficult to control or uncontrollable) |
The combination is looked up in a table from ISO 26262-3. The highest ASIL combinations: S3 + E4 + C3 = ASIL D.
Why ASIL determination matters for Yazaki products
- HV pre-charge sequence (Module 6) — contactor weld failure: S3 (potential fire, electrocution), E4 (every key-on event), C3 (driver cannot intervene) → ASIL D
- HVIL response (Module 6) — failure to open contactors on connector disconnect during service: S3, E1, C3 → ASIL B or C
- AR-HUD misaligned overlay (Module 7) — driver follows wrong-lane arrow: S2-S3, E3, C2 → ASIL B or C
- Cabin light always-on: S0 → no ASIL required (QM)
4. The V-model lifecycle
ISO 26262 and ASPICE both build on the V-model: left side is requirements-and-design (top-down), right side is integration-and-verification (bottom-up). Each design level pairs with a corresponding verification level.
V-model lifecycle (ISO 26262 + ASPICE share this structure)
Three things matter about the V:
- Every left-side artefact has a paired right-side verification. Requirements have qualification tests. Architecture has integration tests. Detailed design has unit tests. This is non-negotiable.
- Traceability is mandatory. Every requirement traces from system level down to unit level, and every test traces back up. Tool support (DOORS, JAMA, Polarion) is standard.
- The V applies at every level of the supplier hierarchy. Yazaki’s V is nested inside the OEM’s V.
How the V intersects with DMADV
The V is “how” the development happens. DMADV is “how rigorously” each artefact is created. They are complementary, not competitive: DFSS Analyze and Design produce robust system requirements and software requirements (top of the V left side); DFSS Verify validates the top of the V right side using ALT, capability studies, and DVP&R. A well-run DFSS project produces a stronger V than DMADV-absent development would.
5. ASIL decomposition & allocation
One safety goal at ASIL D can be implemented by two independent ASIL B subsystems that each fail in different ways — the combination meets the ASIL D target. This is ASIL decomposition, and it’s a powerful architectural technique.
| Decomposition | Example |
|---|---|
| ASIL D → ASIL C(D) + ASIL A(D) | One channel does most of the safety work (ASIL C-grade); a simple independent channel adds the gap (ASIL A-grade) |
| ASIL D → ASIL B(D) + ASIL B(D) | Two equal independent channels |
| ASIL D → ASIL D + QM | The primary path carries the full ASIL D burden; no decomposition |
| ASIL C → ASIL B(C) + ASIL A(C) | Similar pattern at ASIL C |
The catch — independence is mandatory
Decomposition only works if the two channels are provably independent: separate hardware, separate software, separate failure modes, separate causes (no common-cause failure). Verifying independence is an engineering exercise in itself — Module 6’s HVIL with two redundant monitoring paths is a real-world example. A poorly-implemented “decomposition” with shared assumptions is worse than no decomposition.
6. ASPICE — process capability for automotive software
Automotive SPICE is the dominant process-assessment framework for automotive software development. Published by the VDA (German automobile association); the trademark is VDA-owned. Current version: 4.0 (released December 2023); replaced ASPICE 3.1.
The framework has two dimensions:
- Process Reference Model (PRM) — defines the processes (32 processes in 8 groups in v4.0)
- Process Assessment Model (PAM) — defines indicators for evaluating capability of each process
The processes in the PAM are grouped:
SYS — System Engineering (SYS.1 – SYS.5)
SWE — Software Engineering (SWE.1 – SWE.6)
HWE — Hardware Engineering (new in 4.0)
MLE — Machine Learning Engineering (new in 4.0)
SUP — Supporting Processes
MAN — Management Processes
REU — Reuse
SPL — Supply
Why “process model” matters as much as “outcome”
OEMs cannot directly verify the quality of every line of software from every Tier-1. So they evaluate the process used to produce it instead. The argument: a mature, repeatable process produces consistent software quality; an ad-hoc process produces inconsistent quality. This is the same logic Six Sigma applies to manufacturing — applied to software development.
7. The six capability levels (CL0 – CL5)
0
Incomplete
Process not implemented or fails to achieve its purpose
1
Performed
Process produces outputs; not yet managed
2
Managed
OEM baseline. Planned, monitored, work products controlled
3
Established
Safety-critical baseline. Org-wide standard processes; ISO 26262 paired
4
Predictable
Statistically measured & controlled; rarely required
5
Innovating
Continuously improving; aspirational only
For each process being assessed, an evaluator rates the capability level on a 4-step ordinal scale: Not Achieved (0–15%) — Partially Achieved (15–50%) — Largely Achieved (50–85%) — Fully Achieved (85–100%).
The Yazaki-relevant truth
Most OEMs require CL2 minimum from Tier-1 software suppliers. CL3 is increasingly required for safety-related software — particularly the SWE.4-6 verification processes. CL4 and CL5 are aspirational and rarely demanded in commercial contracts. Yazaki’s AR HUD / BMS / EI software programmes are likely CL2 → CL3 transition zones.
A facilitation insight
ASPICE is sometimes felt as “extra paperwork”. A more useful framing: ASPICE is the traceability and rigour discipline that makes software changes reviewable and verifiable. The Module 4 APQP gate reviews land here too — without ASPICE process discipline, Tier-1 software-bearing products struggle to clear APQP gates. The discipline pays for itself.
8. ASPICE 4.0 — what’s new (December 2023)
The first major revision since 3.1 (2017). Reflects how automotive software has changed since.
| Change | Why it was added |
|---|---|
| Hardware Engineering process group (HWE.1–4) | Modern mechatronic systems are HW+SW; previously no HW process coverage in ASPICE |
| Machine Learning Engineering process group (MLE.1–4) | ADAS, autonomous, in-cabin AI — required ML-specific lifecycle |
| Strengthened cybersecurity alignment | Cross-references ISO/SAE 21434; in ASPICE 3.1, cyber was outside scope |
| Shift from “Work Products” to “Information Items” | Less prescription of specific documents; focus on the information content needed |
| Enhanced Agile / DevOps support | Modern toolchains and CI/CD aligned with assessment |
| Improved repeatability of assessments | Reduces subjectivity in assessor judgments |
The combined ASPICE / ISO 26262 / ISO 21434 vision
ASPICE 4.0 reflects an industry recognition: software-bearing automotive products live under three frameworks simultaneously. Rather than fighting their overlap, ASPICE 4.0 deliberately aligns its terminology and process structure with ISO 26262 (for safety) and ISO 21434 (for cyber). For Yazaki’s SGM-EI Software Lifecycle role, this is a real simplification — three frameworks now use compatible vocabulary.
9. ISO/SAE 21434 — cybersecurity engineering
Published October 2021. The cybersecurity equivalent of ISO 26262 — defines a Cybersecurity Management System (CSMS) and a development lifecycle for cybersecurity-relevant E/E systems.
Key elements:
| Concept | What it does |
|---|---|
| CSMS — Cybersecurity Management System | The organisational framework — policies, processes, roles. Required for type approval (UN R155). |
| TARA — Threat Analysis & Risk Assessment | The cyber equivalent of HARA. Identifies threats, attack paths, risk levels. |
| CAL — Cybersecurity Assurance Levels | Analogous to ASIL — defines rigour of cybersecurity engineering for a given asset |
| Security Concept | The top-level cybersecurity requirements — analogous to safety goals |
| Vulnerability management | Continuous monitoring of new vulnerabilities discovered after launch — including software updates (OTA) |
| Incident response | What happens when a cyber incident occurs — disclosure, patches, communication |
Why this matters for Yazaki BMS / HUD / EI products
A modern vehicle is connected: OTA updates, telematics, V2X, charging-station authentication (Module 6 §9). Every connected ECU is an attack surface. Yazaki’s BMS slaves, AR HUD content streams, and any product with external interfaces (charge inlet ISO 15118, etc.) fall under 21434 scope. This isn’t optional — UN R155 makes a CSMS mandatory for type approval of new vehicle types from 2022 in many markets.
10. UN R155 / R156 — the regulatory teeth behind ISO 21434
ISO 21434 is a standard; UN Regulations 155 and 156 are the mandatory type-approval regulations that enforce its application.
| Regulation | Scope |
|---|---|
| UN R155 | Cybersecurity Management System (CSMS) — the manufacturer must have one. Implemented via ISO 21434. |
| UN R156 | Software Update Management System (SUMS) — over-the-air updates must be governed by a documented system covering integrity, authorisation, and rollback |
The phase-in:
- July 2022 — applies to new vehicle types in EU and ECE-following markets (India follows ECE)
- July 2024 — applies to all new vehicles (not just new types) — i.e. ongoing production
- Affects type approval — vehicles without CSMS/SUMS cannot be sold
India context
India follows UN/ECE regulation framework via the Central Motor Vehicles Rules. UN R155/R156 effectively apply to new vehicle programmes selling into the EU; for India-only programmes, regulations are evolving but the direction is clear. Yazaki EV programmes for global OEMs are already under R155 scope.
11. How the three frameworks interact
In practice, all three apply simultaneously to a single software-bearing product. They share artefacts and processes.
| Activity | ISO 26262 | ASPICE | ISO 21434 |
|---|---|---|---|
| Top-level risk analysis | HARA → Safety Goals | Not directly | TARA → Security Goals |
| Classification | ASIL (A-D + QM) | Capability Level (CL0-5) | CAL |
| Lifecycle model | V-model | V-model (Process Reference Model) | V-model concept-design-implement-verify |
| Mandatory traceability | Yes — safety reqs to verification | Yes — between SYS, SWE artefacts | Yes — security reqs to mitigation |
| Independence requirements | Required for ASIL decomposition | Independent verification roles | Cybersecurity case |
| Type approval link | UN R79 (steering), R13H (brakes), etc. | None directly (process) | UN R155 (CSMS), R156 (SUMS) |
A senior-cohort message
The three frameworks don’t compete — they layer. A safety-critical, software-bearing automotive product simultaneously must (a) meet its ASIL safety goals (26262), (b) be developed using mature processes (ASPICE), and (c) be resistant to cyber attack (21434). The work products overlap heavily: a robust requirements process (ASPICE SWE.1) feeds both safety requirements (26262 Part 6) and security requirements (21434). Treating them as one integrated programme is far cheaper than running three.
12. DFSS linkage — DMADV through safety / process / cyber
| DMADV Phase | Safety / Process / Cyber content that lands here |
|---|---|
| Define | ASIL target (from HARA); ASPICE CL target per OEM CSR; CAL target (from TARA); CSR explicitly references all three frameworks |
| Measure | Safety CTQs (e.g. failure rate ≤ 10⁻⁸/h for ASIL D random HW failures, FIT rate, single-point fault metric SPFM); ASPICE process metrics; security metrics (vulnerability response time, encrypted communication coverage) |
| Analyze | HARA, FMEDA, TARA at concept level. Architecture choices: redundancy vs simplicity, decomposition vs monolithic, integrated cyber vs HW HSM |
| Design | Detailed safety requirements (Part 4, 5, 6 of 26262); software architecture per ASPICE SWE.2; cyber architecture per 21434; FMEA-MSR for in-operation safety functions (Module 3) |
| Verify | Fault injection testing, ALT for HW failure modes, ASPICE assessment, penetration testing, cybersecurity validation testing per 21434, vulnerability scanning, type-approval testing per UN R155/156 |
A high-leverage talking point for senior software-bearing-product participants
DFSS Verify and ISO 26262 verification overlap heavily. Both want quantitative demonstration that the product meets its targets. The instructor opportunity: show participants how DFSS’s quantitative discipline (capability indices, ALT acceleration models, statistical confidence intervals) provides exactly the evidence 26262 needs for hardware metrics (SPFM, LFM, PMHF). DFSS isn’t extra work; it produces the artefacts the safety case needs.
13. Instructor facilitation by function
| Function | Safety / Process / Cyber angle that lands |
|---|---|
| SGM-EI / AGM-EI Software Lifecycle | Their core domain. They live in ASPICE assessments and ISO 26262 safety cases. Treat as cohort SMEs; engage strategically on framework alignment. |
| EI — System Engineering Lead | SYS process group, V-model decomposition, traceability matrices, ASIL allocation across subsystems. |
| EI — AR HUD PM | HUD overlay accuracy as an ASIL-B/C function; CAL classification of HUD content path; OTA update strategy under UN R156. |
| EI — Sensor Developer | Sensor in safety-critical chain (e.g. driver-monitoring camera for HUD eye-tracking); FMEDA for HW failure rates. |
| EI — Innovation Cell | ML/AI in ADAS context; ASPICE 4.0 MLE process group; AI safety case challenges. |
| CDDC — AGM (HV/BMS) | BMS contactor management as ASIL D function; HVIL response; CAL for BMS communication interfaces. |
| Testing Center Manager | Fault injection capacity, FMEDA test setup, cyber penetration testing, type-approval testing per UN R155/156. |
| Shared Service — Thermal/EMI/CFD | FMEDA inputs for HW failure rates; FIT (Failures-in-Time) calculations. |
| SD Coordination / Project Mgmt | ASPICE assessment timeline integration with APQP (Module 4); supplier ASPICE / 21434 compliance assessment. |
| WH / CDDC connector teams | Their products are part of the safety case — orange jacket, HVIL, last-mate-first-break (Module 6) — even though they aren’t “software”. |
A facilitation question that unlocks the room
For any participant whose product carries software: “What’s your product’s ASIL classification, your ASPICE CL target, and is there a TARA in scope? How does your DFSS project deliver evidence into the safety / process / cybersecurity case?” A team that can answer fluently is operating at integrated-framework rigour. The instructor’s job is to help others see how DFSS strengthens — not replaces — these frameworks.
When to defer to the room’s SMEs
You don’t need to be the deepest expert on ISO 26262 or ASPICE in the room. You need to recognise the vocabulary and the rationale. When detailed questions arise (ASIL decomposition theorems, CAL calculation), turn to the SGM-EI Software Lifecycle in the room and elevate them as the SME. This both gets the right answer and demonstrates a facilitation skill — leveraging the senior expertise present rather than performing all the expertise yourself.
Instructor self-check
Ten awareness-level questions across the three frameworks.
Q1. The clearest one-line distinction between ISO 26262, ASPICE, and ISO/SAE 21434 is:
A. They are the same standard
B. Only ASPICE is mandatory
C. Safety = product fails by itself harming users (26262); Process = how the team built it, independent of outcome (ASPICE); Security = adversary makes product fail (21434)
D. They cover different vehicle types
Correct — they’re complementary frameworks addressing different concerns. A software-bearing product is governed by all three simultaneously.
Q2. ASIL classification is determined by:
A. Component cost
B. Severity × Exposure × Controllability — looked up in an ISO 26262-3 table
C. Component weight
D. Number of inputs to the ECU
Correct — S × E × C is the formal mechanism. ASIL D is reserved for highest combinations (e.g., S3 + E4 + C3).
Q3. Most OEMs require Tier-1 software suppliers to operate at minimum ASPICE capability level:
A. CL0
B. CL5
C. CL1
D. CL2 (Managed) — with CL3 (Established) increasingly required for safety-related software
Correct — CL2 is the OEM baseline; CL3 is the safety-critical baseline. CL4 and CL5 are aspirational and rarely contractually demanded.
Q4. ASPICE 4.0 (December 2023) added new process groups for:
A. Hardware Engineering (HWE.1-4) and Machine Learning Engineering (MLE.1-4) — reflecting modern mechatronic and AI-bearing automotive products
B. Marketing process
C. None — only minor edits from 3.1
D. Finance process
Correct — these additions made ASPICE 4.0 a meaningful revision; the integration with ISO 26262 and ISO 21434 was also strengthened.
Q5. The HV pre-charge contactor weld scenario from Module 6 — which ASIL is most likely?
A. QM (no special requirements)
B. ASIL D — Severity high (potential fire/electrocution), Exposure every key-on, Controllability low (driver can’t intervene)
C. ASIL A (lowest)
D. Not classified
Correct — HV system safety functions are typically ASIL C-D in real implementations.
Q6. ASIL decomposition (e.g., ASIL D → ASIL B + ASIL B) requires:
A. Bigger budgets only
B. Customer approval only
C. Provable independence — separate HW, separate SW, separate failure modes, no common-cause failure between the decomposed channels
D. Nothing special
Correct — without independence, decomposition fails. Demonstrating independence is a significant engineering activity in itself.
Q7. ISO/SAE 21434 is enforced by which type-approval regulations?
A. ECE R10 only
B. UN R155 (Cybersecurity Management System) and UN R156 (Software Update Management System); applies from July 2022 for new types, July 2024 all new vehicles
C. CISPR 25
D. IATF 16949
Correct — R155 and R156 give ISO 21434 regulatory teeth. India follows the ECE framework; global OEM programmes are already under R155 scope.
Q8. The cybersecurity equivalent of ISO 26262’s HARA (Hazard Analysis & Risk Assessment) is:
A. PFMEA
B. DFMEA
C. PPAP
D. TARA — Threat Analysis & Risk Assessment, defined by ISO 21434; identifies threats, attack paths, risk levels and feeds Cybersecurity Assurance Levels (CAL)
Correct — TARA is to cybersecurity what HARA is to safety. Both feed top-level goals (Safety Goals and Security Goals respectively).
Q9. The DFSS-and-frameworks relationship is best characterised as:
A. DFSS replaces these frameworks
B. These frameworks replace DFSS
C. DFSS provides the quantitative discipline that produces evidence the frameworks need — capability indices, ALT acceleration, statistical confidence — feeding into safety case and ASPICE assessment
D. They are unrelated
Correct — DFSS strengthens, rather than replaces, the framework deliverables. This is the central instructor message.
Q10. The most diagnostic three-part question for any software-bearing Yazaki DFSS project is:
A. What language, what compiler, what OS?
B. AC or DC?
C. What’s your product’s ASIL classification, your ASPICE CL target, and is there a TARA in scope — and how does your DFSS project deliver evidence into the safety / process / cybersecurity case?
D. Hardware or software?
Correct — these three questions span the three frameworks plus the DFSS integration. A team that can answer fluently is operating at integrated-framework rigour.