Functional safety that holds up in the assessment and in the vehicle.
Most safety programs break at the hand-offs: a HARA that no longer matches the architecture, a technical safety concept that ignores the silicon vendor's safety manual, software requirements nobody can trace to a goal. We work across ISO 26262 Parts 2 to 6 and keep those hand-offs consistent.
Concept to software, on one trace
We deliver the work products in each phase and keep the trace between them intact, so a change in one place shows up everywhere it matters.
What we deliver
Concept phase
Item definition with clear boundaries and interfaces. HARA with defensible severity, exposure and controllability ratings. Safety goals, safe states and fault-tolerant time intervals. A functional safety concept that the architecture can actually carry.
System level
Technical safety requirements allocated to hardware, basic software, application software and interfaces. Safety mechanisms for detection, reaction and degradation. The hardware-software interface, including software-implemented hardware diagnostics.
Hardware
Hardware safety requirements, safety analyses and architectural metrics. Mapping of the silicon vendor's safety manual and assumptions of use into requirements the program can verify.
Software
Software safety requirements and architecture, freedom from interference between partitions, and software FMEA of the supervision and reaction chain. Watchdog, program flow monitoring, reset and safe-state design.
The problems that stall safety programs
Silicon safety manuals
A high-performance processor's safety manual carries dozens of system-level assumptions of use and a long catalogue of safety mechanisms. We turn them into allocated, verifiable requirements for the platform software and the safety microcontroller.
Freedom from interference
Mixed-criticality software on one processor needs an argument that holds: hypervisor guest isolation, process address spaces, timing and communication. We write that argument and the requirements behind it.
ASIL decomposition
The cheapest safety-relevant code is the code that doesn't have to be. On one electric transmission program our engineers restructured the architecture so that 65% of the software carried no ASIL.
Supervision and safe states
Health monitoring, alarm handling and reaction policies between a main processor and its safety microcontroller, including how the platform degrades gracefully instead of simply shutting down.
Safety elements out of context
SEooC development for suppliers: assumed safety goals and requirements, documented assumptions, and a safety manual your customers can integrate.
Concept phase under a gate date
A complete concept package for gate review in about twelve weeks, with architecture, requirements and safety developed together instead of in sequence.
Certified, and teaching the standard
Our functional safety engineers hold ISO 26262 Level 2 and ISO/SAE 21434 certification through TÜV NORD. They taught TÜV NORD's ISO 26262 certification course for six years and teach ISO 26262 in Oakland University's professional courses today.
That matters on your program in a practical way: we know which arguments an assessor accepts, and we can bring your own engineers up to speed while we work.
When the program allows, we author safety work in SST, our own platform. Hazards, safety goals and requirements become linked objects next to the architecture they constrain, and each component is pinned to the Git commits that implement it. The work products export to your ALM tool.
About SSTNeed a safety concept that will survive the assessment?
Send us your item, your gate date and where you are stuck. We'll propose a fixed-price package for the concept phase or a focused review of what you already have.