- Explain the BMS state machine's core states and transitions.
- Define the entry/exit conditions and monitored signals for each state.
- Explain how a fault condition enters the state machine.
- Explain how the state machine is verified in production.
BMS-14 — BMS State Machine
1. No Safety Without Order and Conditions
Every function we’ve covered so far — measurement, pre-charge, balancing, fault management — has to run in a specific order and under specific conditions. Balancing can safely happen while HV isn’t active, while pre-charge can only start once specific safety conditions are met. Try to check these conditions separately in every corner of the code, and sooner or later you get inconsistency and unpredictable behavior. The fix: a single state machine — a structure that defines, in one place, what each state is allowed to do and under what condition it transitions.
2. States and Transitions
OFF → INITIALIZATION → SELF TEST → STANDBY → PRECHARGE → HV ACTIVE → DRIVE / CHARGING → FAULT → SHUTDOWNASSUMPTION — These states are a conceptual model for teaching purposes; a real OEM may use different naming or many more intermediate/sub-states.
| State | Entry Condition | Allowed Actions | Monitored Signals |
|---|---|---|---|
| OFF | Sleep/no power | Wakeup detection only | Wakeup signal |
| INITIALIZATION | Wakeup | Memory/peripheral init | Supply, clock |
| SELF TEST | Init complete | Internal tests | ADC, communication, HVIL |
| STANDBY | Self test passed | Monitoring, ready-wait | Cell V/T, isolation |
| PRECHARGE | HV request + safe conditions | Contactor sequencing | DC-link voltage, current |
| HV ACTIVE | Pre-charge complete | Delivering/accepting power | Current, voltage, temperature |
| DRIVE | HV active + drive request | Drive power | SOP, current |
| CHARGING | HV active + charge request | Charge power | Charge current/voltage |
| FAULT | Fault detected | Derating/reaction | Fault status |
| SHUTDOWN | Critical fault or power-down | Opening contactors | HVIL, contactor status |
3. Why Transition Conditions Have to Be Explicit
Every transition depends on a guard condition — for instance, PRECHARGE → HV ACTIVE happens once DC-link voltage reaches the threshold (BMS-06); STANDBY → PRECHARGE happens once isolation and HVIL are confirmed safe (BMS-07). Leave these conditions ambiguous, and different parts of the software can end up interpreting the same transition differently. Every guard condition needs to be an explicit, testable statement — something like “DC-link voltage ≥ 95% of pack voltage AND this has held for at least 50 ms.”
FAULT can be entered from any state; depending on severity, the system moves to derating or SHUTDOWN. For example, if a cell overvoltage fault is detected while in DRIVE, the state machine instantly transitions to FAULT — if the classification is “Critical,” it may go to SHUTDOWN; if “Derating,” it may stay in DRIVE with power restricted. This decision logic is defined in the functional safety concept (BMS-17).
4. What If the State Machine Itself Breaks?
Getting stuck in an unexpected state, an invalid transition attempt, or guard conditions being evaluated inconsistently — these are the state machine’s own software faults. They’re usually caught with a watchdog: an independent timer waits for a regular “I’m alive” signal, and if it times out, the system is forced into a safe state (usually SHUTDOWN).
5. How It’s Verified in Production
During the MIL/SIL phase, all state transitions and guard conditions are tested systematically — state coverage guarantees every state and transition fires at least once. HIL testing injects unexpected transition attempts on real hardware (like trying to jump straight from STANDBY to DRIVE) to confirm the state machine rejects them.
6. How It Connects to Other Systems
The state machine manages contactor/pre-charge sequencing (BMS-06), takes input from fault management (BMS-13), forms the runtime backbone of the functional safety concept (BMS-17), and is one of the central components of the Application layer in the software architecture (BMS-16).
Summary
- The state machine keeps BMS behavior safe and predictable.
- Guard conditions must be explicit and testable — ambiguity leads to inconsistent behavior.
- FAULT can be entered from any state; a watchdog catches the state machine’s own faults.
- State coverage testing guarantees every state and transition has been verified.
Sources
- ISO 26262 — safe-state and state-machine concepts.
Technical Diagrams
Quiz
What's the core purpose of using a state machine?
A state machine explicitly defines what actions are allowed in each state and the conditions for transitions.
From which states can FAULT be entered?
FAULT can be entered from any state the instant a fault is detected.
What's typically the guard condition for the PRECHARGE → HV ACTIVE transition?
Once DC-link voltage reaches the threshold, the positive contactor closes and the system transitions to HV ACTIVE.
Why is it important for guard conditions to be explicit and testable?
Explicit, testable guard conditions ensure consistent, verifiable behavior.
What does a watchdog mechanism do in the context of a state machine?
A watchdog forces the system into a safe state (usually SHUTDOWN) if it stops receiving a regular 'alive' signal.
What does state coverage testing verify?
State coverage guarantees that all states and transitions were exercised at least once during testing.
Glossary
| English Term | Definition |
|---|---|
| State Machine | A structure that models a system's behavior through states and transitions; the backbone of BMS control. |
| BMU (Battery Management Unit) | The BMS's central decision unit; collects CMU data, runs the SOC/SOH/SOP algorithms, and controls the contactors. |
| Contactor Sequencing | The logic defining the order in which the negative, pre-charge, and positive contactors close and open. |
| Guard Condition | An explicit, testable logical condition that triggers a transition from one state to another in a state machine. |