Software and Complex Electronic Systems Safety
This domain tests whether you can reason about systematic software faults, safety integrity frameworks, verification coverage, and the limits of certification claims in complex electronic systems.
Frameworks and levels
DO-178C assigns development assurance levels A through E based on failure-condition severity; DAL A applies to catastrophic failure conditions and demands the most rigorous objectives, including independence and structural coverage. IEC 61508 uses SIL 1 through 4; ISO 26262 uses ASIL A through D; ARP4754A and ARP4761 address aircraft system development and safety assessment. These frameworks are not interchangeable: DAL, SIL, and ASIL answer different questions and use different scales.
Verification and assurance
Requirements-based testing, traceability, configuration management, problem reporting, tool qualification, and independence are central. Structural coverage progresses from statement to decision to modified condition/decision coverage; MC/DC is associated with the highest DALs. COTS and SOUP require assessment of unknown pedigree, defects, and change control. STPA identifies unsafe control actions, and assurance cases present a structured argument linking evidence to claims.
Worked example
A software function whose failure is catastrophic is assigned DAL A. A candidate proposes statement coverage as sufficient verification. The better answer is that DAL A requires MC/DC, independence, requirements traceability, robustness testing, and configuration control; statement coverage alone is too weak. If architecture reduces the DAL, the reduction must be justified by independence and failure analysis, not by assertion.
Traps that cost marks
- Assuming certified software makes the system safe.
- Confusing DAL with SIL or ASIL.
- Ignoring integration, common cause, and data corruption between components.
- Treating redundancy as protection against identical software defects.