Before the individual work products make sense, two ideas hold the whole standard together: the safety lifecycle (drawn as a V), and the ASIL — the risk class that decides how much rigour each requirement gets.

ISO 26262 organises automotive safety work as a V-model. The left arm goes top-down: you start with the whole item and refine it step by step into a concept, then technical requirements, then a design you can build. The bottom is implementation. The right arm comes back up: each level you specified on the left is verified by a matching level of integration and test on the right, ending in validation of the complete item in the vehicle. Every box on the left has a partner on the right.

The standard is split into parts

You don’t apply all of ISO 26262 at once — different parts own different phases. For a BMS, these are the ones you live in:

ASIL — how much rigour a requirement earns

The Automotive Safety Integrity Level is the heart of the standard. Every hazard is rated, and that rating flows down to every requirement, mechanism, and test that addresses it. There are five levels. Higher means more dangerous, which means more demanding methods, more independence in reviews, and tighter hardware metrics.

How a fault becomes a hazard

This three-word chain — fault → error → failure — is the mental model behind every safety mechanism. A fault is a root cause (a broken wire). It produces an error, a wrong internal state (a cell reads false-low). The error becomes a failure when the function is lost at the boundary (a real overvoltage goes undetected). The entire job of a safety mechanism is to break this chain — to catch the error before it becomes a failure, and steer the system to a safe state.

Everything downstream is built on this. The Item Definition draws a precise boundary around the BMS — what it does, where it stops, what it connects to, and the conditions it must work in. Get the boundary wrong and the hazard analysis misses things.

What goes into it

The Item Definition answers four questions about the BMS: its functions, its boundary and interfaces, its operating modes and environment, and the assumptions and dependencies placed on the rest of the vehicle. The functions are the obvious starting point.

The BMS in its system context

A boundary is easiest to see drawn out. Below is a representative BMS architecture — the signal/low-voltage domain in teal, the high-voltage power path in orange. This same diagram becomes the canvas later, when safety mechanisms get mapped onto the blocks.

Operating modes, environment, assumptions

The definition also pins down the modes the BMS runs in — off / sleep, standby, drive, charging (AC/DC), balancing, fault / limp — and the environment: temperature range, vibration, EMC, and the supply it depends on. Finally it records assumptions on the rest of the vehicle (for example, that the VCU will reduce torque demand when the BMS signals a power limit). These assumptions become assumed requirements on other items and must be agreed, not just hoped for.

The HARA is where risk gets named and measured. You imagine the BMS failing in real driving situations, judge how bad each outcome could be, and turn that judgement into an ASIL and a safety goal. It is the single most consequential analysis in the whole programme.

The method in three moves

For each function you consider what happens when it fails — too high, too low, stuck, late, missing. You place that failure in an operational situation (driving on a motorway, charging overnight, parked) to form a hazardous event. Then you rate that event on three axes, and the three ratings together fix the ASIL.

What the three axes mean

The ASIL determination table

This is the lookup behind FIG. 4. Read it as: pick the Severity block, then the Exposure row, then the Controllability column. Note how many combinations land at QM — risk has to be both likely and hard to control before it climbs.

S0 (no harm) yields QM in every case and is omitted. E0 (incredible) likewise yields QM and is omitted.

A worked BMS HARA

Putting it together for the BMS gives entries like these. Each row produces one safety goal, carrying the ASIL of its hazardous event — these goals drive everything from Step 3 onward.

Worked example — reading two of the ratings

The table can feel like magic until you see the reasoning. Here is how two rows were argued, axis by axis — this is the kind of justification a real HARA records for every entry.

A safety goal is the top of the requirement tree — one per hazardous event, written in the vehicle’s language, not the component’s. To be testable it needs two companions: the safe state it drives toward, and the FTTI, the time budget it has to get there.

Safe state

The safe state is the condition the BMS moves to when it can no longer guarantee correct operation — a state with no unreasonable risk. For most BMS hazards the safe state is high-voltage disconnected (open the contactors). Sometimes it is gentler — limit current or limp-home — because an abrupt disconnect can create a new hazard (loss of propulsion). Choosing it is a safety decision in itself.

FTTI — the time budget

A fault does not become a hazard instantly. The Fault Tolerant Time Interval is the window from a fault occurring to the hazard happening, if nothing intervenes. The BMS must detect the fault and react to reach the safe state inside that window — with margin to spare.

FTTI figures are illustrative — actual values come from physical analysis of how fast each fault propagates to harm.

FTTI with real numbers

The abstract timing diagram lands better with a concrete case. Take an external short (SG3, overcurrent), where the budget is tight. Suppose analysis shows the pack reaches a dangerous condition about 100 ms after the short. The BMS must detect and react well inside that:

What the BMS actually does — its safety states

Safe states aren’t just “on” or “off”. A well-designed BMS degrades in stages: it keeps running normally until a limit is approached, warns and reduces power in a middle band, and only disconnects when a true safety limit is crossed. Drawing it as a state machine makes the logic obvious.

The safety goals say what must not happen. The Functional Safety Concept says how, in functional terms — without yet committing to specific hardware. It breaks each goal into functional safety requirements (FSRs) and allocates them to elements of the architecture.

From a goal to its FSRs

A functional safety concept typically covers four things per goal: detecting the fault, reacting to reach the safe state within the FTTI, warning the driver or degrading gracefully, and ensuring the detection itself is dependable (so a single sensing fault can’t blind it). Taking SG1 (prevent overcharge, ASIL C):

ASIL decomposition — splitting the burden

A high ASIL is expensive to meet in one element. ISO 26262-9 allows an ASIL to be split across two sufficiently independent elements, each carrying a lower ASIL while the combination still meets the original. The catch is the word independent: you must prove freedom from interference with a dependent-failure analysis, or a common cause undoes the whole scheme.

Now the concept meets silicon. The Technical Safety Concept refines each functional requirement into technical safety requirements (TSRs) on specific hardware and software, names the safety mechanisms that realise them, and defines the hardware–software interface (HSI) where the two meet.

From FSR to TSR

Where an FSR said “detect overvoltage, tolerant to a single fault”, a TSR says exactly how: two independent measurement paths, compared every cycle, with the AFE running internal self-tests at a defined interval. Continuing the SG1 / overcharge thread:

Safety mechanisms are the working parts of the concept — the things that actually catch faults and steer the system to safety. Think of them as layers of defence: a fault has to slip past every one to cause harm.

The four mechanism families

“DC” is diagnostic coverage — the fraction of a component’s dangerous failure rate that the mechanism detects. These figures feed directly into the FMEDA in the next step.

How redundant sensing actually catches a fault

“Redundant sensing” sounds abstract until you see the comparison at its heart. Two independent paths measure the same cell. If they agree, the value is trusted. If they drift apart by more than a set tolerance, that disagreement is the fault signal — no single broken path can quietly report a false-low voltage anymore.

How a windowed watchdog catches a hung controller

The watchdog is independent hardware that expects the controller to “check in” — but only inside a specific time window. Check in too late (the CPU has hung) or too early (the CPU is looping wildly) and the watchdog fires, forcing the safe state without trusting the software at all.

Three analyses verify the concept from three directions. FMEA works upward from component failures, FMEDA turns that into hardware numbers, and FTA works downward from the hazard. Together they show the safety mechanisms actually cover what they claim to.

FMEA — bottom-up, qualitative

A Failure Mode and Effects Analysis walks every component, asks how it can fail, and traces each failure mode up to its effect on the system and the safety goal. Crucially it records the safety mechanism that catches each one — exposing any failure mode that has no defence.

FMEDA — bottom-up, quantitative

The FMEDA extends the FMEA with numbers: each component’s failure rate, how its failures split between safe and dangerous, and what fraction of the dangerous ones the diagnostics catch. Every fault lands in one of a few classes, and those classes feed the hardware metrics.

1 FIT = 1 failure per 10⁹ hours. ASIL A has no hardware architectural metric target. These are the numbers a BMS hardware design must hit to claim its ASIL.

FTA — top-down, deductive

A Fault Tree Analysis starts at the hazard — the top event — and works down through logic gates to the combinations of basic faults that could cause it. An OR gate means any input alone suffices; an AND gate means several must coincide. The smallest such combinations are the minimal cut sets, and a single-element cut set is a red flag: one fault, on its own, defeating a safety goal.

The concept people find hardest — latent faults

Single-point faults are intuitive: one fault, straight to a hazard. Latent faults are subtler and are the whole reason the LFM metric exists. A latent fault is a hidden fault — usually in a safety mechanism itself — that causes no harm on its own. It only bites when a second fault arrives and finds the safety net already broken.

Analysis shows the concept should be safe; this final phase shows it is — and packages the proof. Verification confirms each step was done right, validation confirms the whole item meets its safety goals in the vehicle, and the Safety Case ties the argument together. Independent confirmation measures sign it off.

Verification vs. validation

Verification asks “did we build the thing right?” at every level — requirement reviews, design analyses, and tests that each specified requirement is met (this is the right arm of the V). Validation asks “did we build the right thing?” — vehicle-level evidence that the safety goals genuinely hold, including fault-injection to confirm safe-state behaviour and timing within the FTTI.

Traceability — the thread through everything

None of it counts unless it connects. Every hazard must trace forward to a safety goal, a requirement, a mechanism, an implementation, and a test — and every test must trace back to the hazard it ultimately protects against. Traceability is what lets you prove completeness and assess the impact of any change.

The Safety Case and confirmation measures

The Safety Case is the structured argument, backed by all of the above as evidence, that the BMS is acceptably safe. It is judged by confirmation measures whose required independence rises with ASIL — the higher the risk, the further removed the reviewer must be from the people who did the work.

Indicative summary — the precise independence levels and applicability are defined in ISO 26262-2. The principle is constant: more risk demands more independence.

Functional safety runs on acronyms. Here they are in one place, in plain language, roughly in the order they appear across the lifecycle.

Define the BMS precisely. Find its hazards and rate them to set ASILs and safety goals. Refine those goals into functional and then technical requirements, realised by safety mechanisms. Prove the mechanisms work with FMEA, FMEDA, and FTA. Verify each level, validate the whole in the vehicle, and assemble the Safety Case — with independent sign-off scaled to the risk. Traceability holds every link together.