Functional safety isn't a checklist — it's a disciplined lifecycle. This is the V-model we run on every engagement, from the first hazard to the signed safety case.
Before any safety work begins, we define the item precisely — its boundaries, interfaces, and intended function within the vehicle. A battery management system means nothing in isolation; we capture how it interacts with the pack, the powertrain, and the driver.
A complete item definition with system boundaries, dependencies, and operating conditions — the foundation every later artifact traces back to.
We systematically identify every way the item can fail and cause harm, across realistic driving situations. Each hazardous event is examined for what could go wrong, how often it's exposed, and whether a driver could control it.
A defensible HARA covering malfunction behaviours, operational situations, and hazardous events — structured to survive audit scrutiny.
Every hazardous event is rated on Severity, Exposure, and Controllability — and the combination determines its ASIL, from QM up to the most stringent ASIL D. From each, we derive a top-level safety goal the system must never violate.
Justified ASIL assignments (S/E/C rationale documented) and the safety goals that drive the entire rest of the lifecycle.
We translate each safety goal into functional safety requirements — what the system must do to stay safe, including fault detection, safe states, and fault-tolerant time intervals. This is where ASIL decomposition and redundancy strategy take shape.
A functional safety concept allocating requirements to architecture, with safe-state definitions and warning/degradation strategies.
At the bottom of the V, functional requirements become concrete technical ones — allocated to hardware and software, with measurable acceptance criteria. This is the pivot from "what" to "how," and from design down into implementation.
Technical safety requirements traced to architecture, ready for HW/SW development, with verification criteria defined up front.
As we climb the right arm of the V, each level is verified against the requirement that defined it. Hardware-software integration is tested for the fault-handling behaviour specified at design time — every safety mechanism exercised.
Integration test strategy and evidence demonstrating each safety mechanism behaves as specified under fault injection.
Verification confirms we built the system right; validation confirms we built the right system. We review evidence against every safety requirement and validate that the safety goals are genuinely achieved at the vehicle level.
A V&V plan and evidence review proving requirements are met and safety goals satisfied — gaps identified before the auditor finds them.
At the top of the right arm, we confirm at the integrated vehicle level that the safety goals hold under real conditions — that the safe states are reachable and the warnings and degradation behave as intended for the driver.
Safety validation results tying vehicle-level behaviour back to the original safety goals from the HARA.
Everything converges into the safety case: the structured argument, backed by evidence, that the item is acceptably safe. This is the document that closes the lifecycle and that an assessor signs against. It's the deliverable everything else exists to support.
A complete, traceable safety case — the argument and the evidence — assembled to withstand independent assessment.
Whether you're starting a new EV platform or preparing for assessment, we run this lifecycle with you — end to end.
Book a Discovery Call