Software and safety-critical systems engineering builds software that must not fail dangerously, in medical devices, vehicles, control systems and infrastructure. In this field it connects security to safety: secure development, verification and the assurance that software behaves as intended under attack and fault.
What software and safety-critical systems engineering does here.
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. In cyber and digital resilience and critical infrastructure, 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. The canonical description is on the STEM Commons.
Secure development life cycle
Security requirements, threat modelling, code review, testing and vulnerability handling are built into development, following practices such as the NIST Secure Software Development Framework.
Safety and security co-assurance
Hazard analysis and threat analysis are performed together so that security measures do not compromise safety functions and vice versa.
Memory-safe language transition
Components most exposed to untrusted input are identified for rewriting in memory-safe languages, which removes a large class of vulnerabilities.
03Geography
Connected activity in Europe.
Night lights, population density and true-colour imagery over Europe, from NASA GIBS. Each layer carries its own date.
The interactive map needs JavaScript; the layer list and sources are below.
Drag to move. Ctrl or ⌘ and scroll, pinch or the buttons to zoom; hover for the values under the pointer; reset returns to the region.
Connected activity, framed on Europe.Satellite and model products as NASA publishes them, each with its own date. They are indicators, not assessments of any place.
We acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Science Data and Information System (ESDIS). Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
We acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Science Data and Information System (ESDIS). Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
VIIRS Black Marble night-time lights, NASA Goddard Space Flight Center; distributed by the NASA Level-1 and Atmosphere Archive and Distribution System (LAADS DAAC); imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
Center for International Earth Science Information Network (CIESIN), Columbia University. 2018. Gridded Population of the World, Version 4 (GPWv4): Population Density, Revision 11. NASA Socioeconomic Data and Applications Center (SEDAC). Licensed under CC BY 4.0. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). doi:10.7927/H49C6VHW. CC BY 4.0
VIIRS near-real-time products (flood, land surface temperature, snow cover, corrected reflectance), NASA LANCE; imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
MODIS land products (vegetation indices, gross primary production, land cover), NASA LP DAAC and LANCE; imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
ASTER GDEM is a product of METI and NASA (ASTER Global Digital Elevation Model V003, NASA LP DAAC); imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). Cite as: NASA/METI/AIST/Japan Spacesystems and U.S./Japan ASTER Science Team (2019). ASTER Global Digital Elevation Model V003. doi:10.5067/ASTER/ASTGTM.003. NASA open data
Made with Natural Earth. Free vector and raster map data @ naturalearthdata.com. Public domain
Blue Marble, NASA Earth Observatory; imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into hexagonal cells where shown (modified). NASA open data
Live events: NASA Earth Observatory Natural Event Tracker (EONET); events are indicative and keep their original source links.
Observed (EO): NASA HLS S30 (contains modified Copernicus Sentinel data 2026). We acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Science Data and Information System (ESDIS).
NASA GIBS: We acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Science Data and Information System (ESDIS).
Optional layers (5 sources in the layer list: live, forecast, observed and context) print their provider credit on the map and here when switched on; forecasts are model output and derived indices are estimates.
Layers and dates
Night-time lights, daily: VIIRS Black Marble (VNP46A2), NASA LAADS DAAC · 12 Oct 2026
Population density, 2020: Population: CIESIN, Columbia University, Gridded Population of the World v4.11 (2018), NASA SEDAC, CC BY 4.0 · static
Flood water, 3-day composite: VIIRS Global Flood Product, NASA LANCE · 14 Oct 2026
True colour: VIIRS NOAA-20 corrected reflectance, NASA LANCE · 13 Oct 2026
Land cover type (IGBP), yearly: MODIS Terra and Aqua land cover (MCD12Q1), NASA LP DAAC · 2024
Enhanced vegetation index, rolling 8 days: MODIS Terra EVI, NASA LANCE · 13 Oct 2026
04Data
What the method consumes.
Datasets and records used by software and safety-critical systems engineering on this platform, with the role each plays and the label its values carry. Sources are listed in the source register.
Data
Role
Label
Vulnerability reports by root cause
Defect classes
REPORTED
Static and dynamic analysis results
Code quality
OBSERVED
Hazard and threat analyses
Requirements
DECLARED
05Monitor
Verification and test.
The screen a team would use to follow this method: its measures, states and decisions. Names are examples and values are illustrative.
Verification and test
Cybersecurity · Safety-critical and secure · Run R-2252
Test campaignGCRI · Cybersecurity and Digital Resilience
Requirements coverage
REQ-01 safe stop
32
11
Covered
REQ-07 fault detection
20
17
Gaps
REQ-12 timing
21
29
Covered
Method card
Method
Software and safety-critical systems engineering
Standard
traceability matrix
Reviewer
independent
Label
MODELLED
Findings by severity
Verification and test: the screen's structure, terms and states for Cybersecurity.Example names and illustrative values; a design, not a record or a live system.
06Validation
How results are checked.
Software is verified through reviews, testing to defined coverage criteria and formal proofs where justified. Independent assessment examines the safety case.
Check
How it is done
Independent verification
Safety-critical software is verified by a team independent of development
Coverage measures
Tests meet stated structural coverage criteria
Vulnerability root cause tracking
Fixed vulnerabilities are classified by cause to improve practice
Complex software interacting with uncertain environments cannot be exhaustively tested. Updates and third-party components introduce new failure paths.
07Twin and cascade simulator
Model safety-critical and secure software as a system. Run the cascade.
Assembled from the Nexus Standards area profile Cyber and digital resilience law alignment: the hazards it names, the systems and sectors that carry the loss, the controls that dampen it and the data that observe it. Choose the components, pick an initiating hazard and step through the cascade. The Map view places the run on an example geography with open data. Every coupling weight is a stated assumption you can change. A teaching model, not a forecast, an assessment or a certification. To model a place of your own choosing, open the full System Builder.
How safety-critical and secure software is modelled, measured and tested.
The model, its assumptions, its data and its uncertainty, in the form a scientist or engineer would check. Structures follow published methods. The values drawn are illustrative, not findings.
System model
The couplings between the systems in safety-critical and secure software: signs of influence, a reinforcing and a balancing loop, and cross-links where stress jumps.
Causal loop diagram from the page's systems; signs show the direction of influence. Illustrative structure for a system dynamics or network model, not estimated couplings.
FAIR guiding principles · GO FAIR and FORCE11W3C PROV · World Wide Web ConsortiumGuidance on consistent treatment of uncertainties · IPCCCEOS Analysis Ready Data · Committee on Earth Observation Satellites
10Stewardship
Who maintains the method.
Cybersecurity and Digital Resilience stewards software and safety-critical systems engineering for the Consortium and reviews how it is applied across platforms.
Safety-critical and secure software: Risk management process
8 steps·5 stages
Process
Safety-critical and secure software: 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.
01 Frame
01Scope, context and criteriaDataset · Service ownerThe frame for the process: the scope, the external and internal context, and the risk criteria. Later steps are read against this frame.
02 Risk assessment
04Risk identificationStep · Service ownerThe first part of risk assessment. Risk is usually expressed by risk sources, potential events, their consequences and likelihood.
05Risk analysisModel · Service ownerThe second part of risk assessment. It considers consequences and likelihood of the identified risks, with guidelines, not a formula.
06Risk evaluationStep · Service ownerThe last part of risk assessment. Results of the analysis are compared with the risk criteria to see where more action is needed.
03 Treatment
07Risk treatmentStep · Service ownerTreatment options are selected, then plans are prepared and implemented. Residual risk is documented and goes to monitoring and review.
04 Across the process
02Communication and consultationStep · Service ownerCommunication and consultation with stakeholders is its own process element. The standard draws it alongside the others, not in sequence.
03Monitoring and reviewStep · Service ownerMonitoring and review take place at every stage. New experience, knowledge and analysis can revise elements, actions and controls.
05 Record and report
08Recording and reportingRecord · Service ownerThe 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.
12Questions
Questions and answers.
What are the limits of software and safety-critical systems engineering in this field?
Complex software interacting with uncertain environments cannot be exhaustively tested. Updates and third-party components introduce new failure paths.
How are results checked?
Software is verified through reviews, testing to defined coverage criteria and formal proofs where justified. Independent assessment examines the safety case.
Are the values on this page real?
The data names, roles and checks are real descriptions of practice. The canvas shows a design of the method's use, not a run; no result is reported here.
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.
GCRICybersecurity and Digital ResilienceStrategic SystemsScenario and Stress-Test
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.
Cybersecurity and Digital Resilience
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.
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.
Editors and the expert reviewers named on each article decide what we publish. Funders and partners do not review or approve articles before publication.
Privacy choices · Cybersecurity and Digital Resilience
This site uses only strictly necessary cookies to work and to remember your privacy choices. Nothing loads from other companies, and we never sell or share your personal information.
Details
This site uses only strictly necessary cookies to work and to remember your privacy choices. Nothing loads from other companies, and we never sell or share your personal information. We run no advertising. You can review your choices at any time through Privacy choices at the foot of every page.