ISO 26262-Style Safety Case for a Battery Disconnect Function

The problem

Disconnecting the battery on a dangerous condition is one of the most safety-critical functions in an EV. Showing that it works is not enough: a safety case must argue, with evidence, that the residual risk is acceptable, covering hazards, safety goals, random hardware faults, systematic faults and diagnostics. Students rarely get to build such evidence on real hardware; this project does that at low voltage.

Objectives

• Carry out an item definition, hazard analysis and risk assessment for a battery disconnect function as a structured classroom exercise
• Derive safety goals, a functional safety concept and a technical safety concept with a defined safe state
• Implement monitoring, cross-checking, watchdogs and protected CAN messages on the kit
• Generate verification evidence by fault injection and present it as a structured safety argument

What you need

This project uses the kit's lithium cell. Respect polarity, never short the terminals, and don't leave the cell charging unattended.

Key concepts

HARA and ASIL

Hazard analysis and risk assessment rates each hazardous event by severity, exposure and controllability to assign an Automotive Safety Integrity Level from A to D. Here it is done as an exercise; a real vehicle needs its own analysis.

Safe state and fault-tolerant time interval

The safe state is the condition the system must reach on a fault, here relay open. The fault-tolerant time interval is how long a fault can persist before harm, which bounds detection plus reaction time.

Diagnostic coverage

The fraction of faults of an element that safety mechanisms detect or control. It is estimated from FMEA and supported by fault-injection results.

End-to-end protection

Adding a CRC, an alive counter and a timeout to safety messages so corruption, repetition, loss and delay on CAN are detected by the receiver.

Safety case

A structured argument, often drawn in GSN, that links safety goals through strategies to evidence such as analyses and test results.

Step-by-step guide

1. 1

   Item definition and boundaries

   Describe the item: a low-voltage battery disconnect function that opens the charge/discharge relay on over-voltage, under-voltage, over-temperature, loss of communication or a vehicle-requested shutdown. Define interfaces, operating modes (charging, driving, parked), assumptions and what is out of scope. State plainly that the kit's 1S cell is a scaled stand-in for a traction battery and that the analysis is a learning exercise following the standard's structure, not a certification.

   Checkpoint: An item definition document with a block diagram, interface list and assumptions is reviewed by the guide.

2. 2

   HARA and safety goals

   List hazardous events for the vehicle-level function, such as thermal runaway from overcharge or unintended loss of propulsion at speed from a spurious disconnect. Rate severity, exposure and controllability with written justification and derive ASILs. Note the tension between the two: disconnecting too readily is itself hazardous while driving. Write safety goals with safe states and fault-tolerant time intervals. Have a second team rate the same events independently and reconcile differences, since ratings are judgements.

   Checkpoint: A HARA table with rationale per rating and at least two safety goals, each with a safe state and a time interval.

3. 3

   Functional and technical safety concepts

   Allocate functional safety requirements to elements: the BMS unit measures and decides, the main controller independently checks cell voltage and temperature messages, and either controller can command the relay open. Specify diagnostics: ADC plausibility, cross-comparison between controllers, independent watchdog, relay state readback if available from the schematic, CAN end-to-end checks and timeouts. Write each requirement with an ID for traceability.

   Checkpoint: Functional and technical safety requirements are listed with IDs and allocated to hardware or software elements.

4. 4

   Board setup

   In CubeMX set both controllers to 72 MHz. Enable the DIP switches for the battery, relay, loads, CAN, LEDs, buzzer and UART blocks. On the BMS unit configure ADC with DMA for cell voltage and T-sense, the relay GPIO with a defined default-off level, and the independent watchdog (IWDG). On the main controller configure bxCAN at 500 kbit/s with filters for the safety messages, the IWDG and a UART log. Follow cell safety: check polarity before connecting, never short the terminals and never leave charging unattended.

   Checkpoint: Both controllers boot with the relay open by default, and a reset caused by the watchdog is visible in the reset-cause flags printed at start-up.

5. 5

   Safety software architecture

   Structure the firmware into a measurement layer, a monitoring layer and an actuation layer, with the safety monitor separated from application code. Implement a state machine: initialising, self-test, normal, degraded, safe state. Implement end-to-end protection on CAN frames with a CRC-8 over payload and ID, a 4-bit alive counter and receive timeouts. Apply MISRA C guidelines and record deviations. Draw the architecture showing which code is safety-related, and keep it small so that it can be reviewed line by line.

   Checkpoint: Static analysis or a review checklist runs over the safety code with deviations documented.

6. 6

   Monitoring and cross-checking

   On the BMS unit, compare voltage readings against plausible ranges and rates of change, and debounce threshold violations over a defined time. Send voltage, temperature and status in a protected frame every 20 ms. On the main controller, check the frame's CRC, counter and timeout, and compare reported values against limits. If either controller detects a violation or loses the other, command the safe state and latch it until a defined recovery procedure.

   Checkpoint: Turning on loads drops the measured voltage, and with a test threshold set just above it, the relay opens within the target time.

7. 7

   FMEA and diagnostic coverage

   Perform a hardware and software FMEA on the chain: ADC, divider, T-sense, relay driver, relay contacts, CAN transceiver, clocks and software tasks. For each failure mode, record the effect, the detecting mechanism and whether it reaches the safe state. Estimate diagnostic coverage per element with justified assumptions and identify residual gaps, such as a relay welded closed, that need hardware not present on the kit.

   Checkpoint: An FMEA sheet lists every failure mode with its detection mechanism and the gaps are explicitly called out.

8. 8

   Fault-injection campaign

   Design test cases traced to each safety requirement. Inject faults in software (stuck ADC values, corrupted CRCs, frozen alive counters, a task that stops kicking the watchdog) and on the bus with the USB-CAN adapter (dropped, delayed and replayed frames). Measure detection time and reaction time by toggling GPIOs and logging with timestamps. Repeat each test enough times to report a spread.

   Checkpoint: Every safety requirement has at least one executed test with measured detection and reaction times recorded.

9. 9

   Build the safety case

   Draw the GSN argument: top goal that the disconnect function is acceptably safe in context, decomposed by safety goal, then by strategies such as hazard mitigation and fault handling, ending in evidence nodes that point to the HARA, FMEA, test reports and code review. Mark undeveloped goals and assumptions honestly. Build a traceability matrix from hazards to requirements to tests.

   Checkpoint: The GSN diagram has no unsupported leaf goals except those deliberately marked as undeveloped with a reason.

10. 10

    Independent review and reporting

    Ask another team to review the safety case and try to break the argument. Record findings and your responses. Write the thesis chapter covering method, implementation, evidence and the limits of transferring a kit-scale argument to a real pack. Summarise measured reaction times against the fault-tolerant time intervals. State which parts of the argument are strong, which rest on assumptions about the vehicle that the kit cannot test, and what further evidence a real programme would need, such as hardware metrics and tool qualification.

    Checkpoint: A review log with closed or justified findings, and a final report with the measured timing table.

Testing & validation

• Reaction time from threshold violation to relay open, measured repeatedly against the fault-tolerant time interval
• Detection of each CAN fault type (corruption, loss, repetition, delay) by the end-to-end checks
• Watchdog recovery to the safe state when a task hangs
• Traceability coverage: every hazard has requirements and every requirement has a passing test
• Independent review findings closed or justified

Expected results

A documented safety case in GSN with HARA, safety concepts, FMEA and a traceability matrix, backed by firmware on both controllers and a fault-injection report with measured detection and reaction times.

Take it further

• Quantify random hardware failure metrics using published failure-rate handbooks and compare architectures
• Add a second, independent disconnect path as an add-on and argue for decomposition
• Extend the case to cybersecurity interplay by adding message authentication
• Automate the fault-injection campaign as a regression suite run after every firmware change

Viva and review questions