Skip to content

GCRI · Engineering

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.

Make an enquiry Back to Engineering
01Contents

Software and safety-critical systems engineering in six parts.

In this dossier6 parts
  1. 01The methodWhat software and safety-critical systems engineering covers
  2. 02Reference practiceSafety-critical software follows sector assurance standards
  3. 03In systemic risk workSoftware is now in every barrier
  4. 04Applied inPlatforms that apply this method
  5. 05StewardshipWho maintains this page
  6. 06SourcesWhere this page’s references lead
02The method

What software and safety-critical systems engineering covers.

  1. 01

    Core methods

    hazard analysis for software; formal specification and verification; static analysis; requirements-based testing; safety case development; software configuration management.

  2. 02

    Data and instruments

    source code repositories; test coverage records; defect databases; safety case documentation; operational fault logs.

  3. 03

    Validation

    Software is verified through reviews, testing to defined coverage criteria and formal proofs where justified. Independent assessment examines the safety case.

  4. 04

    Limits

    Complex software interacting with uncertain environments cannot be exhaustively tested. Updates and third-party components introduce new failure paths.

  5. 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.

03Reference practice

Safety-critical software follows sector assurance standards.

ReferenceWhat it sets
IEC 61508Generic functional safety
ISO 26262Road vehicles
DO-178C and EN 50128Aviation and rail software
SLSA and SPDXSoftware supply-chain integrity and bills of materials
04Process

How the process runs.

Process

Software and safety-critical systems engineering: Risk management process

ISO 31000:2018 sets out an iterative risk management process, from scope, context and criteria through assessment and treatment to monitoring, review and reporting.

  1. 01 Frame

    1. 01Scope, context and criteriaDataset · Independent reviewerThe frame for the process: the scope, the external and internal context, and the risk criteria. Later steps are read against this frame.

  2. 02 Risk assessment

    1. 04Risk identificationStep · Independent reviewerThe first part of risk assessment. Risk is usually expressed by risk sources, potential events, their consequences and likelihood.
    2. 05Risk analysisModel · Independent reviewerThe second part of risk assessment. It considers consequences and likelihood of the identified risks, with guidelines, not a formula.
    3. 06Risk evaluationStep · Independent reviewerThe last part of risk assessment. Results of the analysis are compared with the risk criteria to see where more action is needed.

  3. 03 Treatment

    1. 07Risk treatmentStep · Independent reviewerTreatment options are selected, then plans are prepared and implemented. Residual risk is documented and goes to monitoring and review.

  4. 04 Across the process

    1. 02Communication and consultationStep · Independent reviewerCommunication and consultation with stakeholders is its own process element. The standard draws it alongside the others, not in sequence.
    2. 03Monitoring and reviewStep · Independent reviewerMonitoring and review take place at every stage. New experience, knowledge and analysis can revise elements, actions and controls.

  5. 05 Record and report

    1. 08Recording and reportingRecord · Independent reviewerThe process and its outcomes are documented and reported. The standard does not name who receives the report in the clauses read.

Outline of an external standard or method, from its public sources. It describes what the framework says, not a record of any run. It does not show that Nexus or any partner performs, certifies or approves a step. A gate is a step of the method, never a Nexus approval.

05In systemic risk work

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 Foundry.
06Applied in

Platforms that apply this method.

07Stewardship

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.

08Sources

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.

09Questions

Questions and answers.

Why does one institution host every method page?
GCRI hosts the STEM Commons so that each method has one canonical description. Platforms link to it rather than repeat it, which keeps definitions consistent.
How do I suggest a correction to a method page?
Write to the integrity concern form with the passage and the reason.
ReportsContribute

Contribute evidence from this page.

Reports is the Consortium’s quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.

GCRI

Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.

The Global Centre for Risk and Innovation

Bring a method, a dataset or a question.

Information and enquiries are open today. 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.

Propose a method See all contact routes
Legal

Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.

Privacy choices