BMS-16 — BMS Software Architecture

1. Do You Rewrite All the Code Every Time the Hardware Changes?

BMS software packs in dozens of functions, from measurement drivers to SOC/SOH/SOP algorithms, from the state machine to CAN communication. Write all of it as one monolithic block, and a hardware change (a different MCU or ADC, say) forces you to rewrite almost the entire codebase — and testing gets just as hard. The fix is a layered architecture:

Application → Services → Hardware Abstraction (HAL) → Drivers

2. Four Layers, One Rule

Layer	Contains
Application	BMS business logic: state machine, SOC/SOH/SOP, balancing, fault manager
Services	Shared services like communication, diagnostics, NVM (persistent storage)
HAL	An abstract, uniform hardware access interface
Drivers	Low-level drivers for peripherals like the ADC, CAN, GPIO

The rule is simple: each layer only talks to the layer directly below it and knows nothing about the layers above. The SOC algorithm doesn’t say “read ADC channel 5” — it says “get cell 5’s voltage” (through the HAL). Change the MCU, or move to a different ADC chip, and only the Driver and HAL layers get updated — the SOC algorithm never changes.

The components in these layers (state machine, communication, diagnostics, fault manager, SOC/SOH/SOP, balancing, thermal manager) run either periodically (SOC every N ms) or on an event (a fault), depending on their role.

3. RTOS or Bare Metal?

Criterion	Bare Metal	RTOS
Complexity	Low	Higher
Determinism	High (single loop)	Depends on task priority
Scheduling flexibility	Limited	High (multitasking)
Resource usage	Low	Medium-high

A simple, single-task BMS can get by with bare metal (a super-loop plus interrupts). With many parallel tasks and time-critical operations, an RTOS fits better. The SOC algorithm needs to run every 100 ms, CAN communication every 10 ms, and fault detection continuously — an RTOS schedules these by priority (fault detection at the top), while bare metal relies on a fixed order the developer sets up by hand inside the super-loop.

ASSUMPTION — The choice between bare metal and RTOS depends on the team’s experience, MCU resources, and project-specific timing requirements; no single “correct” approach is being recommended here.

4. Why Such a Rigid Structure?

A layered architecture supports development that’s compatible with ISO 26262 and Automotive SPICE processes, verifiable, and easy to maintain. Separating components makes unit testing and traceability easier.

5. Where This Structure Can Break

Application accessing a Driver directly (a layer bypass that breaks portability), priority inversion (a low-priority task delaying a critical one), and data inconsistency from concurrent access to a shared resource (a race condition) — these are the main risk points in a software architecture.

6. How It’s Verified in Production

The layered structure lets unit tests exercise each layer independently, using mock/stub hardware interfaces. Timing analyses (worst-case execution time) are used to catch cases where an RTOS task exceeds its time budget, before production.

7. How It Connects to Other Systems

The software architecture is the skeleton that every functional component — the state machine (BMS-14), fault management (BMS-13), and communication (BMS-15) — is built on. The verification strategy (BMS-19) and the production process (BMS-20) are also organized around these layers.

Summary

• A layered architecture isolates hardware, providing portability and testability.
• RTOS and bare metal serve different needs — the choice depends on task count and timing criticality.
• Layer-boundary violations and timing errors are the main risk points.

Sources

• Automotive SPICE — software process reference.
• ISO 26262 Part 6 — software development.