BMS-17 — Functional Safety (ISO 26262)

ASSUMPTION — The ASIL levels, safety goal examples, and HARA outcomes given in this lesson are entirely representative, for teaching purposes. A real ASIL assignment can only be determined through a systematic HARA process, specific to a given vehicle and architecture.

1. Why “Good Engineering” Isn’t Enough

As we saw in BMS-13, faults are inevitable — the question isn’t whether a fault will occur, but how the system behaves once it does. ISO 26262 is a framework that, instead of leaving this to chance, requires every potential hazard to be systematically analyzed and matched with a level of development rigor proportional to its risk. Because a BMS manages HV energy, a fault can lead to serious harm like electric shock or fire — this is exactly where the standard steps in.

2. From Hazard to ASIL

A hazard is a potential for harm resulting from a system malfunction. HARA (Hazard Analysis and Risk Assessment) evaluates every hazard along three dimensions:

Dimension	What it asks
Severity	How serious would the outcome of an incident be?
Exposure	How often/for how long does this hazardous situation occur?
Controllability	How much can the driver/system compensate for it?

These three are evaluated together, not separately — because a very severe but extremely rare and fully controllable situation carries a different risk than a low-severity but frequent, uncontrollable one. The result is an ASIL (Automotive Safety Integrity Level): QM, A, B, C, D — with D the highest. A higher ASIL demands stricter development and verification; hazards like uncontrolled HV contact or thermal runaway usually require a high ASIL (C/D) (a generalization for teaching purposes — the actual value depends on the HARA).

3. From Safety Goal to Concrete Design

A Safety Goal is a top-level objective derived from HARA — things like “prevent cell overcharge” or “safely disconnect HV energy.” Educational examples (not a real OEM’s goal):

• “Prevent the cell from exceeding its safe voltage limit due to overcharge.”
• “Disconnect HV energy within a defined time during a crash/critical fault.”

These goals get made concrete in two layers: the Functional Safety Concept answers “what needs to happen,” independent of hardware (something like “cell voltage must be monitored by two independent methods”). The Technical Safety Concept makes it concrete — “how it will be done” (something like “primary measurement via the AFE, secondary verification via a separate monitoring IC”). This separation makes it possible to satisfy the same requirement with different hardware solutions.

4. How Well Does a Safety Mechanism Catch Things?

A safety mechanism is a hardware/software mechanism that detects a fault or reduces its impact — the “verify contactor state with independent feedback” from BMS-06 and the watchdog from BMS-14 are both examples. Diagnostic coverage (DC) shows how much of the dangerous-fault space that mechanism catches:

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

ASSUMPTION — Real DC values are calculated through a systematic FMEA; this lesson only introduces the concept and doesn’t provide a concrete percentage.

The transition to a safe state once a fault is detected — derating, opening a contactor — is called fault reaction, and it’s defined by the safety concept (BMS-13, BMS-14).

5. How It’s Verified in Production

Functional safety is verified through traceability at every stage of development (requirements, architecture, design, code, test): every safety goal has to link to at least one safety mechanism, and every mechanism to at least one test. HIL/SIL testing confirms each mechanism delivers its expected diagnostic coverage through systematic fault injection (BMS-19).

6. How It Connects to Other Systems

The functional safety concept shapes fault management’s (BMS-13) classification logic, the state machine’s (BMS-14) FAULT/SHUTDOWN transitions, and the scope of the verification strategy (BMS-19). It’s also tightly linked to cybersecurity (BMS-18) — a cyberattack can disable safety mechanisms and thereby put functional safety at risk too.

Summary

• ISO 26262: hazard → HARA → ASIL → safety goal → safety concept.
• Severity, exposure, and controllability together determine ASIL.
• The Functional Safety Concept answers “what,” the Technical Safety Concept answers “how.”
• Safety mechanisms and DC measure fault-detection strength; the BMS safety goals here are educational examples.

Sources

• ISO 26262 — functional safety standard.