EV-34 — Functional Safety

ASSUMPTION — This lesson introduces the functional safety framework at the whole-vehicle level. Deep technical content specific to the battery system is in BMS Academy → BMS-17; any ASIL levels or safety goal examples given here are illustrative only, never a real assignment.

1. Why “It Works” Is Not the Same as “It Is Safe”

A control system can pass every functional test and still be unsafe, because functional testing checks that the system does what it is supposed to do under normal conditions, while safety engineering asks a different question: what happens when something goes wrong anyway? In an EV, “something going wrong” can mean a sensor freezing at a stale value, a software task missing its deadline, a connector corroding, or a communication message being lost — and because the vehicle carries a high-voltage energy source and delivers propulsion torque directly to the wheels, an unmanaged fault in either domain can translate into electric shock, fire, or unintended vehicle motion. ISO 26262 exists precisely to make this reasoning systematic rather than left to individual engineering judgment: every plausible hazard must be identified, its risk classified, and a proportionate level of development rigor applied.

FACT — ISO 26262 does not mandate a single safety solution; it mandates a process — hazard identification, risk classification, and traceable safety requirements down to verified mechanisms — that scales its rigor to the actual risk involved.

2. From Hazard to ASIL: HARA

A hazard is a potential source of harm arising from a malfunction — for example, “unintended vehicle acceleration” or “loss of braking torque request.” HARA (Hazard Analysis and Risk Assessment) evaluates each hazard along three independent dimensions, and it is the combination of all three, not any one alone, that determines the resulting risk class:

Dimension	What it asks
Severity	How serious would the harm be if the hazard occurred?
Exposure	How often does the vehicle operate in the situation where this hazard could occur?
Controllability	How well can the driver (or another safety layer) respond and avoid harm?

The result is an ASIL (Automotive Safety Integrity Level): QM (no special safety requirement beyond standard quality management), A, B, C, and D, with D representing the highest rigor. A hazard that is severe, occurs frequently, and is hard for the driver to compensate for earns a high ASIL; a hazard that is severe but extremely rare and highly controllable may earn a much lower one. This is why, for instance, uncontrolled propulsion torque or loss of steering assist typically drive toward ASIL C/D in real programs, while a comfort-feature malfunction typically stays at QM — though the actual value in any real vehicle can only be determined by a full HARA, never assumed from a lesson like this one.

ASSUMPTION — Any ASIL value or hazard example mentioned in this lesson is for teaching purposes only; a genuine ASIL assignment requires a systematic HARA specific to the vehicle and architecture in question.

3. From Safety Goal to Concrete Design

Once a hazard has an ASIL, engineering has to turn that abstract risk classification into something buildable. A safety goal is the top-level requirement derived directly from the hazard — something like “prevent unintended propulsion torque” or “ensure HV energy can be disconnected within a defined time after a crash.” This single sentence then has to be decomposed into two layers of increasing concreteness. The Functional Safety Concept states what must happen, independent of any specific hardware — for example, “torque request must be verified by at least two independent, diverse computation paths before being applied.” The Technical Safety Concept then states how that will actually be implemented in a specific architecture — for example, “the primary torque path runs in the main inverter controller; an independent monitoring core cross-checks the commanded torque against the accelerator signal and forces a safe torque limit on mismatch.” Separating these two layers matters because it lets the same functional requirement be satisfied by different hardware solutions across different vehicle platforms, without re-deriving the safety goal each time.

4. Safety Mechanisms and Diagnostic Coverage

A safety mechanism is the concrete hardware/software feature that detects a fault or limits its effect once it occurs — examples include independent contactor-state feedback (EV-03, BMS Academy → BMS-06), a watchdog timer that catches a hung software task, or plausibility checks between two independent torque sensors. Diagnostic coverage (DC) expresses, as a percentage, how much of the dangerous-fault space a given mechanism actually catches:

DC (%) = (Dangerous faults detected by the mechanism / Total dangerous faults) × 100

ASSUMPTION — Real diagnostic coverage numbers come from a systematic FMEA (Failure Mode and Effects Analysis) specific to a component and architecture; this lesson introduces the concept only, without providing an illustrative percentage that could be mistaken for a real figure.

Once a fault is detected, the system must transition to a defined fault reaction — this is what connects functional safety to the fault management and state-machine logic introduced conceptually in EV-33.

5. Fail-Safe vs Fail-Operational

Not every safety response looks the same, and the choice between the two broad strategies below depends heavily on what the vehicle function actually is. Fail-safe design moves the system to a known-safe state the instant a fault is detected — for a propulsion inverter, this typically means cutting torque and, if necessary, opening the HV contactors, because simply stopping is an acceptable safe state for propulsion. Fail-operational design, by contrast, keeps a function running through a fault by relying on redundancy, because stopping immediately is not an acceptable outcome — steering or braking during an automated-driving maneuver is the classic example, where an uncontrolled vehicle mid-maneuver would itself be dangerous. Fail-operational systems are inherently more complex and costly, since they require duplicated (and ideally diverse) sensing, computation, and actuation paths, so they are reserved for functions where “just stop” is not a safe option.

6. FAQ

What does ASIL actually express?

FACT — ASIL is a risk classification (QM, A–D) assigned by HARA based on severity, exposure, and controllability together; it drives how rigorously the corresponding requirement must be developed and verified, not a direct measure of how “dangerous” a component is in isolation.

What is a safety goal, concretely?

FACT — A safety goal is the top-level, hazard-derived safety requirement (e.g., “prevent unintended acceleration”); it is deliberately hardware-independent and gets refined into the functional and then technical safety concepts.

Is fail-operational always “better” than fail-safe?

INTERPRETATION — Not automatically — fail-operational adds real cost and complexity through redundancy, so it is applied only where an immediate stop would itself be unsafe (e.g., steering during automated driving), not as a general upgrade over fail-safe.

7. Summary

• ISO 26262 makes safety engineering systematic: hazard → HARA → ASIL → safety goal → safety concept → safety mechanism.
• Severity, exposure, and controllability together — not individually — determine ASIL.
• The Functional Safety Concept answers “what must happen”; the Technical Safety Concept answers “how it is implemented.”
• Diagnostic coverage measures how much of the dangerous-fault space a safety mechanism actually catches.
• Fail-safe stops the function safely on fault; fail-operational keeps it running through redundancy, used only where stopping is itself unsafe.

8. Sources and Verification Note

The standard referenced is ISO 26262; all ASIL and safety-goal examples in this lesson are illustrative and non-binding.

• ISO 26262 — Road vehicles, functional safety.
• SAE J1715 — hybrid and electric vehicle terminology.

ASSUMPTION — Source versions/titles may change; every source must be re-verified before publication.

Next Lesson

• EV-35 — Cybersecurity (ISO/SAE 21434): secure boot and OTA security.