GCRI · Engineering
Reliability and resilience engineering
Reliability and resilience engineering studies how systems fail, how failures can be prevented and how systems absorb, adapt and recover from disruption. It addresses both technical components and the organisations that operate them. Critical Infrastructure stewards this page for the Nexus Consortium.
The workspace for reliability and resilience engineering.
Reliability model
The Global Centre for Risk and Innovation (GCRI) · Reliability and resilience · Run R-3730 · Example interface, not a record
Dependency graph
nodes: assets · edges: dependencies
Failure modes
| N3 | 8811 | 8 | Critical |
| N4 | 5317 | 25 | Normal |
| N5 | 4984 | 14 | Normal |
| N6 | 5367 | 42 | Normal |
Cascade size under removal
GCRI · Reliability model. Reliability model: example names and illustrative values, not a record.
What reliability and resilience engineering covers.
- 01
Core methods
failure modes and effects analysis; fault tree analysis; reliability block diagrams; resilience metrics; maintenance optimisation; post-incident analysis.
- 02
Data and instruments
failure and maintenance records; incident databases; condition monitoring data; component test data; operator logs.
- 03
Validation
Reliability predictions are compared with field failure data. Exercises and post-event reviews check whether recovery performed as planned.
- 04
Limits
Common-cause failures and rare events are hard to estimate from limited data. Human and organisational factors resist quantification.
- 05
Use in risk decisions
Resilience engineering identifies critical components and recovery bottlenecks across connected systems. It informs redundancy, spares and restoration priorities.
Resilience engineering extends reliability practice to whole systems.
| Reference | What it sets |
|---|---|
| ISO 22301 | Business continuity management |
| IEC 60300 dependability management | Reliability and availability |
| Sendai target D | Damage to critical infrastructure and disruption of basic services |
How the process runs.
Process
Reliability and resilience engineering: Operational resilience
Basel defines operational resilience as delivering critical operations through disruption; the UK PRA uses important business services and impact tolerances.
01 Services and tolerance
- 01Important business services or critical operationsDataset · Programme ownerUnder PRA rules a firm identifies its important business services; Basel says critical operations. Resilience delivers them in disruption.
- 02Set impact toleranceStep · Programme ownerFor each important business service the firm sets an impact tolerance, the maximum tolerable disruption.
02 Map and test
- 03MappingStep · Programme ownerThe firm documents what it needs to deliver each important business service. Basel asks banks to map interconnections and interdependencies.
- 04Severe but plausible scenariosModel · Programme ownerScenarios are severe but plausible disruptions. Basel names pandemics, cyber incidents, technology failures and natural disasters.
- 05Scenario testingExercise · Programme ownerThe firm regularly tests whether each important business service stays within its impact tolerance in a severe but plausible disruption.
03 Fix
- 06Identify vulnerabilitiesStep · Programme ownerWhere capabilities cannot meet the stated tolerance, policies should address the gap. Basel gives this task to board oversight.
- 07Act to remain within toleranceStep · Programme ownerThe firm must ensure it can remain within its impact tolerance for each important business service.
04 Governing body
- 08Self-assessment and management body approvalDecision · Management bodyThe firm prepares and regularly updates a written self-assessment. Its management body approves the services and the self-assessment.
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. The two vocabularies differ; the outline names both.
Absorb, adapt, recover.
Reliability asks how often a component fails; resilience asks how a system performs during and after disruption. The resilience curve (performance against time through a disruption) makes recovery speed and degraded performance explicit. Interdependent networks need joint restoration planning, because one network’s recovery waits on another’s.
- Measure recovery time and degraded service, not only failure probability.
- Plan restoration order across networks.
- Test assumptions with exercises.
- Applications on Critical Infrastructure and Energy Nexus.
Platforms that apply this method.
Who maintains this page.
Critical Infrastructure stewards reliability and resilience engineering: it keeps this description current and reviews how the method is applied across the platforms.
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.
Questions and answers.
Why does one institution host every method page?
How do I suggest a correction to a method page?
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.
- EmailGateway GW-GCRISend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsGCRISee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
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.
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.
Legal documents.
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.