Safety Standards: DO-178C, ISO 26262

USD 370 million burned in 37 seconds. Ariane 5, 1996: a 64-bit overflow in a module copied from Ariane 4 without applicability analysis. Disasters like this created standards where every line of code requires proof of its safety.

• **Aviation:** Boeing 737 MAX MCAS - lack of ASIL/DAL analysis for the angle-of-attack sensor led to two crashes (346 fatalities). After investigations, FAA tightened the application of DO-178C for Flight Control Software.
• **Automotive:** Tesla Autopilot operates under ISO 26262 ASIL-B for driver assistance. Full autonomy (Level 4) requires ASIL-D - hence the difficulty in certifying self-driving vehicles.
• **Medical:** IEC 62304 is the ISO 26262 equivalent for medical devices. Programmable insulin pumps and defibrillators are developed under this standard with SIL 3 requirements.

DO-178C: the avionics standard

In 1996, the Ariane 5 rocket exploded 37 seconds after launch. The cause: a 64-bit overflow in a module inherited from Ariane 4, where that scenario was impossible. Loss: USD 370 million. Disasters like this created standards that turn safety-critical software development into a provable process. DO-178C is the RTCA standard for airborne software, accepted by FAA, EASA, and most aviation regulators worldwide. It does not describe how to write code - it describes what must be proven before release.

DO-178C divides software into five DAL (Design Assurance Level) levels - from A (catastrophic failure) to E (no effect). DAL-A requires MC/DC coverage - Modified Condition/Decision Coverage, the strictest form. Every requirement is traced from specification to test case and back. No dead branches, no unused code.

ISO 26262: functional safety for road vehicles

In 2009, Toyota recalled 8 million cars over suspected unintended acceleration. A NASA independent investigation found a task without a watchdog timer and a stack without overflow protection in the engine control firmware. Following this scandal, automakers moved from ad hoc practices to ISO 26262 - the international functional safety standard for road vehicles. ISO 26262 was adopted in 2011 and extended in 2018 for semi-autonomous systems. It covers the full V-cycle: from safety concept to decommissioning.

ISO 26262 uses HARA (Hazard Analysis and Risk Assessment) to determine risk level. Each hazard is rated on three axes: Severity (S0-S3), Exposure (E0-E4), Controllability (C0-C3). The combination yields an ASIL (Automotive Safety Integrity Level) from QM to ASIL-D. ASIL-D systems include electric power steering, ABS, and brake control.

ASIL: integrity levels and decomposition

ASIL is not just a label on a chip box. It is a set of requirements for the development process, architecture, verification, and tools. ASIL-D mandates that code be written in MISRA C, the compiler be certified (IEC 61508), and test coverage reach 100% MC/DC. There is an elegant tool: ASIL decomposition. If an ASIL-D system is split into two independent channels of ASIL-B, the combined ASIL remains D, provided the channels are truly independent.

ASIL decomposition rule: D = B + B, C = A + A, B = A + QM. QM (Quality Management) is the minimum level with no special functional safety requirements. Decomposition requires architectural independence: separate MCUs, separate power supplies, separate communication buses. Otherwise a Common Cause Failure invalidates the entire decomposition.

DAL vs ASIL: comparing the standards

DO-178C and ISO 26262 solve the same problem in different domains but take different paths. DO-178C is a process standard: compliance is achieved by following a documented development and verification process. ISO 26262 is a goal-based standard: it defines Safety Goals and requires proof of their achievement. For embedded developers, the key difference is that DO-178C effectively prohibits dynamic memory management and recursion for DAL-A/B, while ISO 26262 sets these constraints via MISRA but with more flexibility.

There is a third important standard - IEC 61508 for industrial systems. It introduces SIL (Safety Integrity Level) 1-4 and is the parent of ISO 26262. DO-178C and IEC 61508 are partially harmonized through DO-254 (for hardware) and ARP 4754A (for system level). Knowledge of these relationships is critical when developing systems certified under multiple standards simultaneously.

Key ideas

• **DO-178C** divides software into DAL-A..E levels. DAL-A requires 100% MC/DC, prohibition of dynamic memory and recursion, and full requirements traceability.
• **ISO 26262** uses HARA to determine ASIL through Severity, Exposure, Controllability. ASIL-D allows decomposition: D = B + B with architectural independence of channels.
• **Both standards** require MC/DC for the highest levels, Tool Qualification for CI tools, and complete Safety Case documentation - certification takes years, not days.

Related topics

Safety standards draw on concepts from other RTS areas:

• Formal Methods for RTS — DO-178C DAL-A and ASIL-D in practice are combined with formal verification via model checking
• Task schedulers in RTS — WCET analysis and priority assignment are mandatory parts of the safety case for ASIL-D and DAL-A systems

Вопросы для размышления

• ASIL decomposition allows replacing one ASIL-D channel with two ASIL-B channels. What architectural conditions invalidate this replacement, and how is this verified during an audit?
• DO-178C requires tool qualification (TQL). If a team uses open-source GCC for DAL-A code - what specifically must be done for compliance?
• Why is the prohibition on dynamic memory (malloc) in DO-178C DAL-A considered reasonable from a safety standpoint, even though modern C++ actively uses RAII and heap?

Связанные уроки

• emb-01