Compressing the Safety Lifecycle: What Hardware-Software Co-Design Actually Changes in IEC 61508 and ISO 26262 Programs

Where the Safety Lifecycle Loses Time Without Co-Design

Understanding where conventional sequential development loses time to safety requirements is the prerequisite to understanding what co-design recovers. The losses cluster in three phases.

The first is the hardware-software interface specification. ISO 26262 Part 4 (system level) and Part 6 (software level) both require a hardware-software interface (HSI) specification that describes all hardware elements that software interacts with from a safety perspective: register behaviors under fault conditions, timing behaviors of safety-critical peripherals, hardware diagnostic mechanisms that software must monitor, and memory protection boundaries. In sequential development, this specification is written after hardware architecture is defined and must be negotiated between hardware and software teams who have already made design decisions that may conflict. Mismatches discovered at this stage propagate back through both streams, requiring redesign and re-documentation of requirements already baselined.

The second is FMEDA — Failure Mode Effects and Diagnostic Analysis. The FMEDA is the quantitative safety analysis that calculates whether the hardware architecture achieves the required diagnostic coverage for the target ASIL or SIL. It requires knowledge of the component failure rates (FIT rates from the reliability database), the failure modes of each component, and the diagnostic mechanisms that detect those failure modes within the required fault detection time interval. In sequential development, the FMEDA is typically performed after hardware design is substantially complete, when changing architecture to improve diagnostic coverage is expensive. Discovering at FMEDA stage that the single-point fault metric (SPFM) or latent fault metric (LFM) does not meet the ASIL D requirement forces hardware rework — often adding redundant monitoring channels, lockstep CPU configurations, or additional safety monitors — under schedule pressure.

The third is software testing on target hardware. ISO 26262 Part 6 and IEC 61508 Part 3 both require unit testing, integration testing, and system testing with defined code coverage criteria — MC/DC (modified condition/decision coverage) for ASIL C/D, branch coverage for ASIL B, statement coverage for ASIL A. These tests must run on target hardware or on a representative virtual platform. When hardware prototype availability is late — which is the norm in complex embedded systems — the software testing phase cannot begin at all, and the entire test-evidence generation phase compresses into the period between hardware availability and the certification deadline.

Virtual Platforms as the Co-Design Foundation

A virtual platform is a software model of the target hardware system — processor cores, peripherals, memory controllers, safety mechanisms — that runs the actual embedded software binary in a simulated environment without requiring physical hardware. Virtual platforms have existed in electronic design automation for decades; what has changed in the safety context is the maturity of tools that generate safety-relevant evidence from virtual platform simulation that is acceptable to certification bodies.

Synopsys offers ISO 26262 ASIL D, TCL 1 certified solutions for virtual prototyping; Cadence provides functional safety simulation flows certified to Tool Confidence Level 3, the highest qualification level for ISO 26262. These certifications matter because ISO 26262 Part 8 clause 11 requires that software tools used in safety-relevant development be qualified — their outputs must be reliable and any errors they introduce must be bounded. A virtual platform used to generate code coverage evidence for an ASIL D safety function is a safety-related tool that must be qualified; using a non-qualified simulation environment as the basis for certification evidence is an auditable gap in the safety case.

For software development purposes, a virtual platform enables the software team to begin writing and testing firmware from the moment the hardware architecture is defined — not from the moment the first hardware prototype is available. A software team developing an ASIL C brake control firmware on a virtual platform model of the target AURIX TC3xx microcontroller can begin unit testing, integration testing, and MISRA compliance analysis twelve to eighteen months before hardware prototypes exist. The test evidence generated on the virtual platform — code coverage reports, fault injection test results, timing analysis — becomes part of the safety case, subject to the qualification status of the simulation environment.

The specific artifacts that virtual platform simulation contributes to the safety lifecycle under ISO 26262 and IEC 61508 are:

• Software unit and integration test reports with MC/DC coverage metrics, generated from simulation before hardware availability
• Fault injection test evidence demonstrating that safety mechanisms detect modeled faults within the fault detection time interval
• Timing analysis confirming that software task execution remains within timing budgets under fault-loading conditions
• FMEDA input data for diagnostic coverage calculation when the virtual platform models hardware faults reaching software

HARA, ASIL Decomposition, and Early Architecture Decisions

The Hazard Analysis and Risk Assessment (HARA) is the entry point of both ISO 26262 and the automotive adaptation of IEC 61508. Its outputs — the safety goals with assigned ASIL values, and the functional safety requirements that implement those goals — determine everything downstream: the hardware architecture, the software architecture, the diagnostic mechanisms, the testing rigor, and the documentation burden. Making HARA a co-design activity rather than a hardware-team activity changes which architecture decisions are still open when HARA results arrive.

ASIL decomposition is the mechanism by which a single ASIL requirement can be split across two or more independently developed elements, where each element carries a reduced ASIL. An ASIL D requirement decomposed into two ASIL B elements allows each element to be developed with ASIL B rigor rather than ASIL D rigor — a significant reduction in development cost and timeline, since ASIL D requires the most stringent techniques across all categories of static analysis, code coverage, formal verification, and independence of development. The decomposition is valid only when the two elements are sufficiently independent — freedom from interference (FFI) must be demonstrated between them.

The hardware-software interface boundary is the most natural place for ASIL decomposition in embedded systems, because the hardware safety mechanisms and the software safety mechanisms operate independently by architecture. A co-design approach that defines the ASIL decomposition at the same time as the HSI specification enables both hardware and software architectures to be designed for their decomposed ASIL from the start, rather than designing at the full ASIL and retrofitting decomposition as a cost-reduction measure later.

These differences translate directly into program duration and cost. Co-design that establishes decomposition architecture early allows both hardware and software development to proceed at the lower ASIL from day one. Late decomposition — deciding to decompose an ASIL D system after hardware and software are designed for ASIL D — means re-scoping the testing, analysis, and documentation that has already been produced at the higher level.

FMEDA-Driven Hardware Architecture in the Co-Design Loop

The FMEDA is not purely a documentation activity — it is a feedback mechanism that should drive hardware architecture decisions. When FMEDA is performed early in a co-design framework, it can identify diagnostic coverage gaps while the hardware is still at the architecture stage and changes are cheap. When FMEDA is performed late, it identifies gaps in hardware that is already in prototype or even in pre-production, where changes are expensive and disruptive.

Cadence's FMEDA-driven safety solution and Siemens' Questa FuSa flow both support FMEDA at RTL stage — calculating diagnostic coverage metrics from register-transfer level hardware descriptions rather than from post-silicon characterization. Machine learning algorithms in these tools accelerate FMEDA throughput, and automated fault campaign simulation injects faults at RTL and validates whether software-level diagnostic mechanisms detect them within the fault detection time interval. The co-design loop this enables is:

1. Hardware architect defines a candidate architecture at RTL
2. FMEDA tools calculate SPFM and LFM for the target ASIL
3. If metrics fall short, safety mechanism candidates (lockstep, ECC, watchdog) are evaluated in simulation
4. Selected mechanisms are added to the RTL
5. Software team implements the diagnostic software that monitors those mechanisms on the virtual platform
6. End-to-end fault injection tests on the virtual platform validate the complete hardware-software diagnostic chain
7. Results feed back into the FMEDA to refine coverage calculations

This loop, executed in simulation before hardware tape-out, front-loads the evidence generation that in sequential development happens after hardware availability. The certification body sees an FMEDA validated by fault injection simulation evidence — a stronger argument than an FMEDA based on assumed diagnostic coverage values.

Tool Qualification and the Evidence Chain

One of the most time-intensive aspects of safety certification that co-design frameworks can streamline is tool qualification. ISO 26262 Part 8 clause 11 establishes three Tool Confidence Levels (TCL1, TCL2, TCL3) based on the tool's potential for error introduction and the detectability of those errors. Tools used to generate safety evidence at TCL2 or TCL3 require qualification — demonstrating through analysis and testing that the tool functions correctly for its intended use.

Qualifying a simulation environment, a static analysis tool, or a code coverage tool from scratch within a project is a multi-month effort. It requires tool documentation, an operational profile, validation test cases, and evidence that the tool meets its specified behavior. Many certification programs discover mid-program that unqualified tools have been used to generate safety evidence, triggering either tool qualification retroactively — expensive — or exclusion of the evidence and re-running the tests with a qualified tool.

Pre-qualified tools eliminate this effort. The IAR toolchain for embedded C/C++ is TÜV-certified and covers ten safety standards including IEC 61508, ISO 26262, and IEC 62304. Synopsys virtual prototyping tools carry ISO 26262 ASIL D TCL 1 certification. Cadence's EDA tools are certified to TCL3 by TÜV SÜD. Using pre-qualified tools shifts the burden from tool qualification to tool usage documentation — the project must document how the tool was used and confirm it was used within its qualified configuration, rather than performing full tool qualification from scratch.

The key tools that benefit most from pre-qualification in a co-design functional safety program are:

• FMEDA and fault simulation tools used to generate diagnostic coverage evidence
• Static analysis tools used to enforce MISRA compliance and detect code defects
• Code coverage tools used to generate MC/DC or branch coverage reports
• Model-based design tools (MATLAB Simulink) used for model-based software development at ASIL C/D
• Requirement management tools used to maintain traceability from safety goals to test cases
• Virtual platform environments used to run software tests before hardware availability

Safety Element Out of Context and Reuse

Safety Element out of Context (SEooC) is the mechanism in ISO 26262 that allows a hardware or software element to be developed against assumed safety requirements, so that the element and its safety documentation can be reused in multiple product integrations without repeating the full development lifecycle for each product.

Most microcontrollers and processors qualified for automotive use are qualified as SEooCs: the hardware FMEDA, FIT rates, safety manual, and diagnostic coverage data are produced by the semiconductor manufacturer once and provided to OEMs and Tier-1 suppliers as the component-level safety package. TI's TDA4VM, NXP's S32K, and Infineon's AURIX TC3xx families all ship with FMEDA reports, safety manuals, and ASIL-certified development documentation that become inputs to the system-level FMEDA rather than requiring the system integrator to characterize the processor from scratch.

At the software level, a certified software library — an RTOS, a communication stack, a mathematical function library — developed as an SEooC to a specific ASIL carries its certification evidence and can be integrated into a higher-level software architecture with reduced verification burden, subject to demonstrating that the integration context is consistent with the SEooC's assumed requirements. SafeRTOS holds SIL 3/ASIL D certification on multiple hardware targets; SEGGER embOS-Safe holds IEC 61508 SIL 3 and IEC 62304 Class C certification. Using a certified SEooC RTOS in a co-design program means the RTOS's timing determinism, memory protection, and scheduling behavior are backed by existing certification evidence — the system integrator demonstrates the integration is valid rather than re-certifying the RTOS from scratch.

The co-design benefit of SEooC reuse is that the assumed safety requirements of the SEooC drive hardware and software architecture decisions in the co-design phase. A software team designing an ASIL B application using a SafeRTOS SEooC knows from the beginning which hardware features SafeRTOS requires for its safety mechanisms (MPU configuration, hardware timers, interrupt priorities) and can specify those in the HSI and validate them on the virtual platform before hardware existence.

Quick Overview

Hardware-software co-design compresses IEC 61508 and ISO 26262 certification timelines by eliminating the serial dependency between hardware availability and software development, safety analysis, and evidence generation. The key mechanisms are: virtual platforms that allow software testing and fault injection evidence generation before hardware prototypes exist; FMEDA-at-RTL flows that identify diagnostic coverage gaps at architecture stage rather than post-silicon; ASIL decomposition established at design phase rather than retrofitted; and SEooC reuse of certified hardware components and software libraries that brings pre-existing safety evidence into the program. Tool qualification using pre-certified EDA and development tools removes multi-month qualification efforts from the critical path. Meeting certification standards like ISO 26262 and IEC 61508 takes up to 12 months for tool qualification alone when using unqualified tools; this is entirely avoidable with a qualified toolchain established at program start.

Key Applications

Automotive ECU development at ASIL C/D for braking, steering, and powertrain control systems where ISO 26262 Part 4–6 applies from system concept through software integration test, industrial safety controller development at IEC 61508 SIL 2/3 for process control, robotics, and machine safety applications, functional safety programs on heterogeneous SoCs with Cortex-A and Cortex-R cores where ASIL decomposition across the cores is the architecturally natural safety strategy, and any program where hardware schedule risk is high and software development must start before the first prototype.

Benefits

Virtual platform simulation moves software test evidence generation up by 12 to 18 months relative to hardware availability, converting what was a critical path dependency into a parallel activity. FMEDA-at-RTL identifies diagnostic coverage gaps before tape-out, when adding a lockstep configuration or hardware safety monitor costs weeks of RTL revision rather than months of silicon re-spin. ASIL decomposition defined in co-design reduces the verification burden for each element — branch coverage instead of MC/DC, reduced formal analysis requirements, lower documentation depth — while maintaining the system-level ASIL of the safety goal. Pre-certified SEooC components and qualified tools eliminate qualification efforts that would otherwise consume multiple months of the certification program.

Challenges

Virtual platform accuracy depends on the fidelity of the hardware model — a virtual platform that does not correctly model fault injection behavior, interrupt timing, or safety register semantics generates test evidence that does not reflect actual hardware behavior, creating a certification gap discovered at integration. ASIL decomposition requires demonstrating freedom from interference between the decomposed elements, which requires either hardware memory protection, hypervisor isolation, or core separation — architecture constraints that must be established in the co-design phase and cannot be added to an existing design without significant rework. IEC 61508 Edition 3, expected to publish in 2027, will introduce updated guidance on FPGAs, SoC devices, and object-oriented software, creating potential scope changes for programs that began under Edition 2 assumptions.

Outlook

IEC 61508 Edition 3 is expected to publish in 2027 with explicit guidance on FPGAs, SoC devices, soft errors, and reuse of ISO 26262 components in industrial applications — addressing the gap between the current generic standard and the specialized semiconductor platform guidance available in ISO 26262:2018. The convergence will simplify cross-domain reuse: mobile machinery and industrial applications will be able to adopt automotive-qualified SoC platforms and their associated safety documentation with a defined normative path rather than through interpretation. Automated FMEDA flows using ML-accelerated fault simulation, as offered by Cadence and Siemens EDA, are reducing the computational cost of comprehensive fault campaigns from weeks to days, making early FMEDA-at-RTL economically practical for programs that previously could only afford late-stage FMEDA.

Related Terms

IEC 61508, ISO 26262, SIL, ASIL, ASIL decomposition, FMEDA, SPFM, LFM, PMHF, FIT rate, HARA, safety goal, functional safety requirement, HSI, hardware-software interface, freedom from interference, FFI, virtual platform, fault injection, MC/DC coverage, branch coverage, SEooC, Safety Element out of Context, tool qualification, TCL, Tool Confidence Level, V-model, safety lifecycle, safety case, static analysis, MISRA, lockstep, DCLS, ECC, MPU, SafeRTOS, embOS-Safe, AURIX TC3xx, S32K, TDA4VM, Synopsys VC FuSa, Cadence Questa FuSa, Siemens Questa FuSa, dSPACE, ETAS LABCAR, TÜV SÜD, exida, model-based development, Simulink, FTA, FMEA, safety manual

Our Case Studies