Skip to content
MJ
← All case studies
ISO 26262ASIL DAUTOSARMISRA CArchitecture

Safety-certified power-management platform component

Architected an ASIL D-compliant power-management component for an ADAS ECU, designed from the start for reuse across customer projects.

Period
2022 — 2025
Client
Tier-1 automotive supplier (ZF)
Role
R&D Embedded Software Engineer

OutcomeComponent certified as part of the platform and reused across multiple customer projects — built once, shipped many times.

The problem

Power management on an ADAS ECU is deceptively hard: the state machine has to sequence supply rails, handle sleep and wake, and protect against faults — all while being safety-relevant enough that failures must be detectable and handled deterministically. Each customer project had been solving this separately, which meant duplicated certification effort.

Constraints

  • ASIL D. Every path needed to be traceable to a requirement, with detectable failure modes.
  • MISRA C, no exceptions. Static analysis was part of the gate, not an afterthought.
  • Must be reusable. Different MCUs, different rail counts, different timing budget — so the design could not embed one project’s assumptions.
  • No runtime surprises. Power sequencing races are the class of bug that only shows up on a cold soak in winter.

What I did

Modelled the state machine explicitly before writing code — states, transitions, and error paths as requirements, so traceability came from the design rather than being retrofitted in a DOORS matrix afterwards.

Separated policy from mechanism. Rail tables and timing constants became configuration; the sequencing logic stayed fixed and reviewable. That separation is what made the component portable across projects.

Worked the failure path as seriously as the happy path — wake on a dead rail, brown-outs, and spurious wake events each got a defined, testable behaviour.

Trade-offs

  • Configuration over cleverness. A table-driven design costs a few bytes of flash versus hand-optimised sequencing, and buys arguable safety cases and faster reuse. In a safety context that trade is not close.
  • Explicit diagnostics instead of silent recovery. Where the spec allowed either, I chose to report and escalate rather than quietly retry — easier to certify, and it makes field failures diagnosable.

Outcome

The component was certified as part of the platform and adopted by multiple customer projects, replacing per-project one-offs.

What I’d do differently

Nothing structural — but I’d have pushed harder for the configuration format to be validated at build time rather than runtime on the first projects. That came later, and it would have caught two integration mistakes earlier.