5 exercises on safety and compliance terminology: MISRA C, functional safety, IEC 61508, DO-178C, and certified RTOS. Advanced
0 / 5 completed
1 / 5
Your project manager states: "All C code in this safety-critical module must comply with MISRA C — no exceptions without a formal deviation record."
What is MISRA C?
Correct: B.MISRA C (Motor Industry Software Reliability Association C) is a widely adopted coding standard, originally developed for automotive software but now used across aerospace, medical, industrial, and other safety-critical domains. It defines required and advisory rules — for example, banning dynamic memory allocation after initialization, prohibiting direct casts between pointer and integer types, and requiring all switch statements to have a default clause.
Version
Base standard
Common in
MISRA C:2004
C90 / C99
Automotive (legacy projects)
MISRA C:2012
C99 / C11
Automotive, medical, industrial
Deviation record
Documents justified rule violation
Required when a rule cannot be followed
2 / 5
A systems architect explains: "The braking ECU requires functional safety — it must keep the vehicle safe even if a sensor fails or the software encounters an unexpected error."
What does functional safety mean?
Correct: B.Functional safety is about safe behaviour under failure, not just correct behaviour under normal conditions. A functionally safe system detects faults (via hardware diagnostics, watchdogs, cross-checking) and responds in a controlled, predictable safe state — for example, applying maximum braking instead of releasing all brake pressure when a sensor fails. It is formalised by standards such as IEC 61508, ISO 26262, and DO-178C.
Concept
Meaning
Safe state
Controlled condition entered when a fault is detected
Fault tolerance
System continues operating safely despite a fault
Fail-safe
System automatically moves to a safe state on failure
Diagnostic coverage
Fraction of dangerous faults detected by diagnostics
3 / 5
A safety engineer says: "The pump controller must achieve SIL 2 according to IEC 61508 — that drives our entire development and verification process."
What is IEC 61508?
Correct: B.IEC 61508 is the foundational functional safety standard for E/E/PE (electrical, electronic, and programmable electronic) systems. It defines four Safety Integrity Levels — SIL 1 (lowest) to SIL 4 (highest required risk reduction). Derived domain-specific standards include ISO 26262 (automotive), IEC 62061 (machinery), and IEC 62443 (industrial cybersecurity).
SIL
PFH (dangerous failures/hour)
Example application
SIL 1
10⁻⁶ – 10⁻⁵
Industrial conveyor safety stop
SIL 2
10⁻⁷ – 10⁻⁶
Emergency shutdown valve, pump
SIL 3
10⁻⁸ – 10⁻⁷
Burner management, railway signalling
SIL 4
10⁻⁹ – 10⁻⁸
Nuclear reactor protection
4 / 5
The project compliance officer states: "All flight control software must satisfy DO-178C Design Assurance Level A — that's the highest level, for software whose failure could cause a catastrophic aircraft accident."
What is DO-178C?
Correct: B.DO-178C (Software Considerations in Airborne Systems and Equipment Certification) is published by RTCA and recognised by aviation regulators worldwide (FAA, EASA). It defines five Design Assurance Levels based on the severity of the failure condition: DAL A (catastrophic) requires the most rigorous development and verification — including 100% MC/DC structural coverage — while DAL E (no safety effect) requires minimal activity.
DAL
Failure condition
Coverage required
A
Catastrophic
MC/DC (100%)
B
Hazardous
Decision coverage (100%)
C
Major
Statement coverage (100%)
D
Minor
No structural coverage req.
5 / 5
An architect proposes: "We should switch from a community RTOS to a certified RTOS that already has a DO-178C DAL A qualification kit — it significantly reduces our certification effort."
What is a certified RTOS?
Correct: B. A certified RTOS (sometimes called a qualified RTOS or safety RTOS) has been developed under a safety lifecycle process and verified to the degree required by a target standard. The vendor supplies a qualification kit — test suites, coverage reports, tool qualification data, and documentation — as evidence artefacts that regulators accept as part of the system's certification dossier. Examples include INTEGRITY (GHS), LynxOS-178, VxWorks 653, and SafeRTOS.