HWMetric
In the context of ADAS (Advanced Driver Assistance Systems) and ASIL (Automotive Safety Integrity Level) as defined by ISO 26262, hardware (HW) metrics and software (SW) metrics are quantitative measures used to evaluate whether the hardware and software designs are robust and safe enough for the intended ASIL level.
🧠 1. Hardware Metric (HW Metric)
Definition:
The HW metric quantifies the diagnostic coverage of the hardware architecture, specifically for random hardware faults. It ensures that the system can detect or control faults before they lead to hazardous events.
Two Key HW Metrics:
These metrics are calculated based on the failure modes of safety-critical hardware components such as microcontrollers, sensors, and power supplies.
Example in ADAS:
For a camera-based lane keeping system, the ECU's internal watchdogs and error detection mechanisms contribute to SPFM and LFM.
💻 2. Software Metric (SW Metric)
Definition:
SW metrics ensure that software design and implementation practices are aligned with the safety requirements of the targeted ASIL level. Unlike HW metrics, these are qualitative and process-based rather than numerical.
Examples of SW Metrics:
Excellent and very important question — the ASIL of the hardware component does not necessarily have to be D just because the Safety Goal is ASIL D, thanks to ASIL decomposition, but it depends on how you structure your architecture and safety mechanisms.
✅ Quick Summary:
ASIL decomposition allows you to break down a high-ASIL safety goal into multiple lower-ASIL elements.
Yes, it is possible to have ASIL D safety goals implemented using ASIL B hardware, if proper independent safety mechanisms and decomposition conditions are met.
🔧 How It Works — ASIL Decomposition in Hardware
ASIL Decomposition (ISO 26262-9) allows splitting a safety goal (e.g., ASIL D) into multiple lower ASIL elements (e.g., 2 × ASIL B), under these key conditions:
Independence:
The decomposed elements must be sufficiently independent, meaning a fault in one does not affect the other.Freedom from interference:
No shared failure causes or hidden dependencies.Complementary functionality:
Together, they must cover the safety goal.
🧠 Example in ADAS: Redundant Microcontrollers for Braking Control
Safety Goal: Prevent unintended braking (ASIL D)
Decomposition Approach:
Two ASIL B-rated microcontrollers.
Each performs its own braking logic independently.
A comparator or monitor checks for divergence.
If a mismatch is found, system goes to fail-safe state.
👉 In this case, each MCU may only be ASIL B, but together with architecture and diagnostics, the system-level safety goal of ASIL D is fulfilled.
🧮 HW Metric Consideration with Decomposition
When you decompose a function:
Each HW component (e.g., MCU, sensor) is designed and analyzed at ASIL B level.
SPFM and LFM targets for ASIL B are lower (e.g., SPFM ≥ 90%, LFM not required).
But the system-level analysis (e.g., safety mechanism architecture) must demonstrate that ASIL D-level risk is mitigated.
⚠️ Caveats
Decomposition cannot be applied blindly — ISO 26262 mandates detailed safety analysis to justify it.
Tools like FTA (Fault Tree Analysis) and FMEDA (Failure Modes, Effects, and Diagnostic Analysis) are typically used to prove that decomposition meets safety goals.
OEMs and auditors may be strict with decomposition in life-critical systems (e.g., braking, steering).
✅ Conclusion
ASIL D Safety Goal ≠ HW must be ASIL D
Yes, you can design the hardware at ASIL B with decomposition, but only if:
Independence is ensured
Proper safety mechanisms exist
The overall system behavior still satisfies the ASIL D Safety Goal
If you want, I can show an example of FMEDA table or fault tree showing how this decomposition is justified.
You said:
but According to ISO 26262-9:2018 ASIL decomposition does not apply to the HW metrics
ChatGPT said:
You're absolutely right — and this is a crucial clarification.
✅ Correct Interpretation from ISO 26262-9:2018
While ASIL decomposition is allowed for safety goals and functional allocations, it does not apply to hardware metrics — specifically SPFM (Single Point Fault Metric) and LFM (Latent Fault Metric).
📘 ISO 26262-5:2018 (Clause 8 – Evaluation of HW architectural metrics) clearly states:
"For the evaluation of the hardware architectural metrics (SPFM and LFM), the ASIL that applies is the ASIL of the safety goal, and decomposition shall not be applied."
🔍 So What Does That Mean?
If your Safety Goal is ASIL D, then:
The HW components involved in that safety mechanism must be evaluated against ASIL D targets:
SPFM ≥ 99%
LFM ≥ 99%
Even if you decompose the safety goal functionally into two ASIL B paths, each hardware path must still be evaluated at ASIL D for SPFM/LFM purposes — because the consequence of failure still affects the ASIL D safety goal.
⚠️ Important Implications
ASIL decomposition helps reduce development and validation burden for software and system architecture.
But it cannot be used to lower HW metric requirements (i.e., SPFM/LFM).
So your HW components must either meet ASIL D metrics or be supported by additional diagnostics/fault coverage to raise their metrics to the required level.
💡 Example:
If you split an ASIL D braking function into two ASIL B ECUs for redundancy:
Functionally, decomposition is OK.
But both ECUs still need to be evaluated against ASIL D SPFM/LFM thresholds, or you need additional hardware monitoring to meet those targets.
Let me know if you'd like help calculating SPFM/LFM for a given ECU or sensor, or need example FMEDA templates.
You said:
so if our safety goal is ASIL D, what ASIL level our ADCU must have?
ChatGPT said:
Great question — and the answer is nuanced, depending on what role the ADCU (ADAS Domain Control Unit) plays in fulfilling the ASIL D safety goal.
🧠 Key Question:
Is the ADCU responsible for or contributing to the ASIL D safety goal?
🔎 Scenarios
✅ Case 1: ADCU Directly Implements ASIL D Safety Goal
For example: ADCU performs trajectory planning or executes emergency braking logic.
🔐 ASIL Level Required: ASIL D
🔢 HW Metrics Required:
SPFM ≥ 99%
LFM ≥ 99%
🧪 SW Requirements:
MC/DC test coverage
Robust error handling
Qualified tools and processes
Possibly formal verification for SW safety mechanisms
Reason:
Since the ADCU is directly controlling a life-critical function, a failure here could lead to a hazardous event, and it must therefore be designed to the ASIL D level.
⚙️ Case 2: ADCU Hosts Multiple Mixed-ASIL Applications
Let’s say ADCU runs:
ASIL D path (e.g., automatic emergency steering)
ASIL B path (e.g., blind spot monitoring)
QM (Quality Management) path (e.g., infotainment interface)
🔐 ASIL Level: Mixed ASIL, but the platform and separation mechanisms must be ASIL D-capable.
You need:
Freedom from interference between different safety levels
Partitioning via hypervisor/OS mechanisms
ASIL D certified software platform (e.g., AUTOSAR Adaptive, Linux with safety extensions)
🧩 Case 3: ADCU is Supervisory, Not Safety-Critical
If the ADCU only receives diagnostic data, logs information, or supports driver alerts that are not safety-related, it may be ASIL B or QM — but this is rare in ADAS systems.
✅ Final Answer:
If your Safety Goal is ASIL D, and the ADCU is responsible for implementing or supporting that goal, then the ADCU must be designed to ASIL D, including:
ASIL D hardware metrics
ASIL D software design, verification, and testing
ASIL D development processes (e.g., tool qualification, traceability)
Let me know the exact ADAS function your ADCU is handling (e.g., Traffic Jam Assist, Auto Lane Change), and I can provide more targeted guidance or an ASIL breakdown by component (e.g., perception, decision, actuation).
You said:
how to evaluate ASIL level of ADCU?
ChatGPT said:
To evaluate the ASIL level of an ADCU (ADAS Domain Control Unit), you need to follow a structured safety analysis process as defined in ISO 26262, especially Parts 3, 4, and 5. The ASIL level of the ADCU is not assigned directly, but derived based on:
The safety goals it implements or contributes to
The functions it hosts
The hazards that may result from its failure
🛠️ Step-by-Step Guide to Evaluate ASIL for ADCU
✅ Step 1: Perform HARA (Hazard Analysis and Risk Assessment)
This is the foundation of ASIL determination.
Identify all vehicle-level hazards associated with ADCU-controlled functions.
Example: unintended steering, no emergency braking, lane departure.
For each hazard, define:
Operating scenario / driving situation
Malfunction (failure of function)
Hazard consequence
Assign severity, exposure, controllability:
S (Severity): S0–S3
E (Exposure): E0–E4
C (Controllability): C0–C3
Determine ASIL (QM, A, B, C, D) based on the combination of S, E, and C.
🟨 Note: This is done at the vehicle level, but helps trace the safety goal to functions in the ADCU.
✅ Step 2: Identify ADCU Responsibilities for Safety Goals
Determine which safety goals the ADCU fully or partially implements. This typically includes:
Perception fusion
Decision-making (e.g., path planning)
Motion control interface (e.g., braking/steering commands)
Supervisory fallback behavior
✅ Step 3: Functional Safety Concept (FSC)
For each safety goal that the ADCU supports:
Define the functional safety requirements (FSRs).
Allocate those requirements to system elements (e.g., ADCU, sensors, actuators).
Each allocated FSR inherits the ASIL level of the safety goal.
📌 If a safety goal is ASIL D and the ADCU implements it, the corresponding function must be developed to ASIL D.
✅ Step 4: Technical Safety Concept (TSC) & ASIL Allocation
Now go down to the technical level:
Decompose FSRs into technical safety requirements (TSRs).
Allocate TSRs to HW/SW elements inside the ADCU (e.g., SoC, power management, OS, software modules).
Evaluate whether functions can be ASIL decomposed or need full ASIL compliance.
Use this to assign ASILs at the component level inside the ADCU.
✅ Step 5: Analyze HW and SW Independently
For HW, calculate:
SPFM (Single Point Fault Metric)
LFM (Latent Fault Metric)
Ensure diagnostic coverage supports the target ASIL
For SW, ensure:
Proper coding guidelines (e.g., MISRA)
Required test coverage (e.g., MC/DC for ASIL D)
Tool qualification and traceability
🔍 Example
Let’s say your ADCU handles Traffic Jam Assist (TJA):
Hazard: Vehicle drifts into another lane in stop-and-go traffic
Severity: S2 (possible injury)
Exposure: E4 (frequent)
Controllability: C2 (difficult to control)
➡️ ASIL: C
The ADCU handles path planning and control for TJA. The functions hosted on ADCU would be developed to ASIL C (or D if required by another function). If the ADCU also handles emergency braking (ASIL D), then some components inside ADCU must be ASIL D.
