A safety-critical system is one whose failure can lead to loss of life, serious injury, environmental damage, or large-scale destruction. When software controls such a system - the flight computers in an airliner, the dosing logic in a radiation therapy machine, the protection system in a nuclear reactor, the throttle and braking in a car - that software is itself safety-critical. Ordinary bugs become potential disasters, so the discipline that surrounds this software is far stricter than for typical applications.
The defining concern is that software does not fail the way mechanical parts do. It does not wear out or fatigue; it fails because of a defect that was present from the moment it was written, waiting for the exact inputs and timing to expose it. This makes testing alone insufficient, because the space of possible inputs and states is vastly too large to exercise completely. Safety-critical engineering therefore layers many defenses: careful requirements, redundancy and fault tolerance, conservative coding standards, extensive review, and, increasingly, formal methods that mathematically prove properties of the code rather than merely sampling its behavior.
Two primary standards anchor the field. In avionics, RTCA’s DO-178, “Software Considerations in Airborne Systems and Equipment Certification,” is the document certification authorities use to approve airborne software; it organizes its requirements by design assurance level, demanding progressively more rigorous evidence as the consequences of failure grow more severe. Across many other industries, IEC 61508, “Functional safety of electrical/electronic/programmable electronic safety-related systems,” provides a generic framework built around a risk-based safety lifecycle and Safety Integrity Levels (SIL 1 through 4). It serves, as the IEC describes, as a basic safety publication and the parent of sector-specific standards for vehicles, medical devices, rail, and process industries.
Certification is as much about process and evidence as about the code itself. To win approval, a team must show not only that the software works but that it was developed, verified, and managed under a controlled process, with traceability from requirements through design and code to tests. The aim is to make the argument for safety auditable: an independent authority should be able to follow the reasoning and the records and conclude that the residual risk is acceptable.
The history of this field is written partly in its failures. The Therac-25 radiation overdoses, the Ariane 5 maiden-flight explosion, the Toyota unintended-acceleration controversy, and the Boeing 737 MAX MCAS crashes each pushed the discipline forward, revealing gaps in requirements, testing, redundancy, or human-machine interaction. Pioneers such as Margaret Hamilton, who led flight software for the Apollo program and helped coin the term software engineering, argued early that software for systems where lives are at stake must be engineered with the same rigor as any other safety-critical artifact - a principle the standards now encode.