Software and safety-critical systems engineering
Software and safety-critical systems engineering develops software whose failure could cause harm, loss of life or major disruption. It applies rigorous processes to control-system, medical, aviation and infrastructure software. Cybersecurity and Digital Resilience stewards this page for the Nexus Consortium.
- 01In briefThe short answer
- 02The methodWhat software and safety-critical systems engineering covers
- 03Reference practiceSafety-critical software follows sector assurance standards
- 04In systemic risk workSoftware is now in every barrier
- 05Applied inPlatforms that apply this method
- 06StewardshipWho maintains this page
- 07Key termsTerms used on this page
GCRI · Institution · service level R0
The short answer.
Software and safety-critical systems engineering develops software whose failure could cause harm, loss of life or major disruption. Safety-critical software practice limits the chance that a software fault cascades through physical infrastructure. In the Nexus Consortium, Cybersecurity and Digital Resilience stewards its canonical page, and 2 other platforms apply it, including Nexus Foundry as well as Financial Cyber and Operational Resilience.
Systemic exposure in the Great Lakes.
Where people and networks concentrate, the exposure through which shocks travel between systems, shown for the Great Lakes as an example geography for this subject.
What software and safety-critical systems engineering covers.
- 01
Core methods
hazard analysis for software; formal specification and verification; static analysis; requirements-based testing; safety case development; software configuration management.
- 02
Data and instruments
source code repositories; test coverage records; defect databases; safety case documentation; operational fault logs.
- 03
Validation
Software is verified through reviews, testing to defined coverage criteria and formal proofs where justified. Independent assessment examines the safety case.
- 04
Limits
Complex software interacting with uncertain environments cannot be exhaustively tested. Updates and third-party components introduce new failure paths.
- 05
Use in risk decisions
Safety-critical software practice limits the chance that a software fault cascades through physical infrastructure. It informs assurance requirements for automated control in interconnected systems.
Safety-critical software follows sector assurance standards.
| Reference | What it sets |
|---|---|
| IEC 61508 | Generic functional safety |
| ISO 26262 | Road vehicles |
| DO-178C and EN 50128 | Aviation and rail software |
| SLSA and SPDX | Software supply-chain integrity and bills of materials |
Software is now in every barrier.
Control systems, medical devices and vehicles run software whose failures can be systematic rather than random: every copy has the same bug. Assurance requires evidence that the software meets its safety requirements and that its supply chain is intact.
- Treat software faults as common-mode.
- Maintain software bills of materials.
- Assure updates as rigorously as initial releases.
- Applications on Cyber and Digital Resilience and Nexus Foundry.
Platforms that apply this method.
Who maintains this page.
Cybersecurity and Digital Resilience stewards software and safety-critical systems engineering: it keeps this description current and reviews how the method is applied across the platforms.
Terms used on this page.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Change control | The process for approving, testing and deploying changes to systems so they do not cause failures. |
| Fault tolerance | The ability of a system to keep operating when some components fail. |
| Assurance case | A structured argument, backed by evidence, that a system is acceptably safe or secure for a given use. |
| Mutation testing | Introducing small faults into code to check that the test suite detects them. |
Where this page's references lead.
The bodies and documents this page is read against. Status and editions change; each link goes to the issuing body.
- IEC 61508 Functional safety of electrical, electronic and programmable systems (IEC)
- ISO 26262 Road vehicles, functional safety (ISO)
- RTCA DO-178C and EN 50128 software assurance in aviation and rail
- SLSA supply-chain levels for software artifacts (OpenSSF)
- SPDX software bill of materials specification (Linux Foundation)
Where this page leads across the Consortium.
- Applied inGCRISafety-critical software engineeringApplied in Nexus Foundry.
- Applied inGCRISafety-critical and secure softwareApplied in Cybersecurity and Digital Resilience.
- Applied inGRASoftware and safety-critical systems engineering for financial cyber and operational resilienceApplied in Financial Cyber and Operational Resilience.
Questions and answers.
Why does one institution host every method page?
How do I suggest a correction to a method page?
Around GCRI.
Start with an enquiry.
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.