BMS Safety Goals & Concept (FSC/TSC)

An ASIL rating on its own doesn’t tell an engineer what to build, it has to be translated into a concrete requirement and then into an architecture that satisfies it. Once HARA assigns an ASIL to a hazard, ISO 26262 requires a Safety Goal: a top-level requirement stated in terms of the hazard being prevented or mitigated, along with a Fault Handling Time Interval (FHTI) that defines how quickly the system must reach a safe state. From there, the Functional Safety Concept (FSC) describes how the vehicle-level function achieves that goal, and the Technical Safety Concept (TSC) breaks it down into concrete hardware and software requirements. Because a single ASIL D requirement is often impractical to implement in one un-decomposed block, this page also covers ASIL decomposition: splitting a requirement across independent elements and the safe-state strategies that decide why opening all contactors immediately isn’t always the correct response to a fault.

From ASIL to Safety Goal

Deriving a safety goal is mostly a rewording exercise, but a precise one: take the hazardous event that HARA rated and restate it as a top-level requirement in the vehicle’s language rather than the component’s. “Cell overtemperature, S3/E4/C3, ASIL D” becomes something like “the system shall prevent any cell exceeding its safe temperature limit” — the goal carries the hazard’s ASIL forward, and every requirement derived from it inherits that same rigour unless it is formally decomposed (see below).

Safe State

The safe state is whatever condition the BMS moves to once it can no longer guarantee correct operation — a state with no unreasonable residual risk. It is tempting to assume that always means “open every contactor,” but for a pack under load at highway speed, an abrupt disconnect can create a new hazard of its own (sudden loss of propulsion or braking assist). A well-designed BMS instead has a small menu of safe states graded to the fault: full contactor opening for a severe, imminent hazard; a controlled limp-home derate that keeps the vehicle drivable at reduced power for a fault that isn’t immediately dangerous; or a charge-current cutback that stops a charging-specific fault without touching propulsion at all. Which safe state applies, and how the BMS gets there, is itself a safety decision that has to be argued and documented alongside the goal.

FHTI — the time budget

A fault doesn’t turn into a hazard the instant it occurs. The Fault Handling Time Interval (also seen as Fault Tolerant Time Interval, FTTI, depending on the standard’s edition) is the window between a fault occurring and the hazard actually happening if nothing intervenes. Inside that window the BMS has to both detect the fault and react to reach the safe state, with margin left over — detection time plus reaction time has to fit comfortably inside the FHTI, not just equal it.

A concrete case makes the arithmetic clearer. Take an external short circuit driving pack overcurrent, where the budget is tight: suppose the pack reaches a dangerous condition roughly 100 ms after the short appears. If the current-monitoring loop detects the fault in 5 ms and the contactor-opening sequence takes a further 20 ms to react, the fault is cleared in 25 ms — a quarter of the budget, leaving 75 ms of margin. The same arithmetic is why sampling rate matters: a monitoring loop that only polled current every 50 ms could burn through the whole budget on detection alone, before any reaction has even started.

All of the figures above are illustrative rather than settled values for any specific pack — a real FHTI comes from physical analysis of how fast a given fault actually propagates to harm in that system, and has to be re-argued if the architecture changes.

References

Chetan Shidling, Functional Safety For An EV Battery Management System, CSEE, 2026