Determining safety-critical computing system functions
Appendix E opens by defining how to find the functions worth all this rigor: Safety Application Functions (functions that directly control a hazard) and Safety Infrastructure Functions (functions the application depends on to stay safe), plus a set of Common SCCSFs seen across programs.
It also sorts requirements into three types so each one is handled the right way:
Design and development process requirements
Before touching code, the process itself has to be trustworthy — configuration control, an active Software Quality Assurance program, and independent design verification and validation, including tracing what was analyzed back to what was actually deployed.
System design requirements & guidelines
The largest subsection in the appendix — the core design rules for how safety-critical software should be built to fail gracefully: defined safe states the system can always return to, isolation between critical and non-critical code, and disciplined handling of overload and error conditions.
Requs AI Edge Case and Requs AI Software FMEA identify edge cases and failure modes based on these design criteria and others.
Power-up system initialization requirements
Guidance for the moment a safety-critical system comes to life: verifying the system starts in a known-safe configuration, handling power faults and primary computer failure gracefully, honoring maintenance interlocks, and running a system-level check before safety functions go live.
Requs AI Edge Case and Requs AI Software FMEA identify edge cases and failure modes related to power up, power requirements and initialization.
Computing system environment requirements
Requirements that live at the hardware/software boundary — how the software should behave when the computing environment itself fails, plus baseline guidance on CPU selection, minimum clock cycles, and read-only memory for safety-critical code.
Requs AI Edge Case and Requs AI Software FMEA identify edge cases and failure modes when the computing environment fails.
Self-check design requirements
Software should be able to tell when something is wrong with itself. This subsection covers the standard self-monitoring toolkit:
Requs AI Edge Case and Requs AI Software FMEA identify edge cases and failure modes based on the above ability of the software to detect a fault in itself.
SCCSF protection requirements
Once a safety-critical function exists, it needs to be protected from being degraded, bypassed, or corrupted — covering safety degradation, unauthorized interaction or access, the integrity of the safety kernel, inadvertent jumps in program flow, and the integrity of loaded data and operational reconfigurations.
Interface design requirements
Rules for the boundaries between software components and systems — closed feedback loops, controlled interfaces, disciplined decision statements, inter-CPU communication, message integrity, and input reasonableness checks so bad data doesn't get treated as good data.
Requs AI Edge Case and Requs AI Software FMEA identify edge cases and failure modes for interfaces, communication and detection of bad data.
Human interface
Where the operator meets the safety-critical system: computer-human interface (CHI) issues, safe handling of processing cancellation and hazardous-function initiation, clear safety-critical displays and alerts, and tolerance for operator entry errors rather than trusting every input.
Requs AI Edge Case and Requs AI Software FMEA identify edge cases and failure modes due to the processing cancellation, confirmation of irreversible functions and other human factor related root causes.
Critical timing and interrupt functions
Guidance for the parts of the system where when something happens matters as much as what happens — safety-critical timing budgets, validating interrupts before acting on them, avoiding recursive loops, and managing time-dependent behavior deliberately rather than incidentally.
Requs AI Edge Case and Requs AI Software FMEA identify edge cases and failure modes identify these and other timing related failure modes.
Software design and development requirements
The code-level rulebook — the largest set of discrete, checkable requirements in the appendix, covering everything from module structure to how variables are declared:
A representative sample of the ~26 discrete coding requirements listed in E.11 — not the complete set.
Software maintenance requirements
Reliability doesn't end at fielding. This subsection governs how safety-critical software is changed afterward — controls on critical function and firmware changes, the medium changes are delivered on, modification configuration control, and clear version identification so everyone knows exactly what's running.
Software analysis and testing
The appendix closes with the testing discipline needed to actually verify all of the above — general testing guidelines, formal test coverage, and a set of named, targeted test techniques:
Requs AI Predict software predicts defects from a machine learning model that considers the level of rigor of each of the above tests.
A joint-service product
The Handbook — and Appendix E within it — was developed jointly by the U.S. Army, Navy, Air Force, and Coast Guard safety centers, with cooperation from the FAA and NASA. MIL-STD-882E points programs to it directly for software safety analysis guidance.