Technology Risk Assessment

Description

Systematic identification, analysis, and prioritization of risks inherent in technology development, deployment, and operation. Combines Failure Mode and Effects Analysis (FMEA/FMECA, MIL-STD-1629, IEC 60812), Fault Tree Analysis (NASA Fault Tree Handbook), and bow-tie methodology to map how technologies can fail, what causes failures, what their consequences are, and how risks can be mitigated. Grounded in systems safety engineering (Leveson, 2011) and risk-informed decision making (NASA NPR 8000.4). Unlike security threat modeling (which examines adversarial threats), technology risk assessment focuses on intrinsic technical risks: design limitations, manufacturing defects, environmental stresses, integration failures, operational errors, and degradation over time. In the space sector, where systems operate in extreme environments with limited repair options, technology risk assessment is foundational to strategic analysis of any technology-dependent topic.

When to Use

• Evaluating the risk profile of an emerging space technology (electric propulsion, on-orbit servicing, in-situ resource utilization, reusable upper stages).
• Assessing whether a technology is ready for operational deployment or requires further risk reduction.
• Comparing alternative technologies on a risk-adjusted basis (complementing technical-benchmark-comparison).
• Analyzing past technology failures to extract strategic lessons (launch failures, satellite anomalies, ground system outages).
• Topics where technology reliability, availability, or safety is central to the strategic argument.
• Informing investment, procurement, or policy decisions that hinge on technology risk.

How to Apply

1. Define the system and its operational context. Specify the technology, subsystem, or system under assessment. Establish the operational environment: orbital regime, mission duration, thermal/radiation environment, launch loads, ground interfaces. Define what constitutes failure — loss of mission, degraded performance, safety hazard, or economic loss.
2. Decompose the system into assessable elements. Break the technology into its functional blocks, subsystems, and critical interfaces. Identify the functional chain: what must work for the system to achieve its purpose. For complex systems, create a functional block diagram showing dependencies and redundancy paths.
3. Identify failure modes (FMEA approach). For each element, systematically identify how it can fail. For each failure mode, document:
   • Failure mode: What goes wrong (e.g., valve fails to open, software logic error, thermal runaway, structural fatigue).
   • Cause: Root cause or mechanism (material defect, design error, environmental stress, wear-out, common-cause failure).
   • Effect: Local effect on the element, next-higher-level effect, and end effect on the mission/system.
   • Severity: Rate on a consistent scale (Catastrophic / Critical / Major / Minor / Negligible).
   • Probability: Rate likelihood based on heritage data, test results, or engineering judgment (Frequent / Probable / Occasional / Remote / Improbable).
   • Detectability: Can the failure be detected before it causes harm? (High / Medium / Low / None).
4. Construct fault trees for critical failures (top-down). For the most severe end effects, work backward to identify all combinations of events that could cause them. Build a fault tree using AND/OR gates to model how lower-level failures propagate to system-level consequences. Identify single points of failure (events whose occurrence alone causes the top-level failure) and common-cause failures (a single root cause triggering multiple failures simultaneously).
5. Apply the bow-tie model for key risks. For the highest-priority risks, construct a bow-tie diagram showing: the hazard at center, threat pathways on the left (what leads to the hazard), consequence pathways on the right (what happens after the hazard materializes), preventive barriers on the left, and mitigative barriers on the right. Assess the integrity and independence of each barrier.
6. Prioritize risks. Combine severity and probability (and optionally detectability) into a risk priority ranking. Use a risk matrix consistent with the domain standard (NASA risk matrix, ESA risk classification, MIL-STD-882). Identify the top risk items that drive the overall technology risk profile.
7. Assess risk mitigation options. For each high-priority risk, evaluate available mitigations: design changes (eliminate the failure mode), redundancy (tolerate the failure), testing and screening (detect before deployment), operational procedures (avoid triggering conditions), monitoring (detect early and respond), and graceful degradation (limit consequences). Assess residual risk after mitigation.
8. Synthesize risk profile. Produce an overall technology risk assessment: What are the dominant risks? Are they acceptable for the intended application? What further risk reduction is needed? How does the risk profile compare to alternatives or benchmarks? What risk acceptance rationale is required?

Key Dimensions

• Failure modes — How each element can fail, classified by mechanism (design, manufacturing, environmental, operational, wear-out).
• Severity — Consequence magnitude: mission loss, performance degradation, safety hazard, economic impact, cascading effects.
• Probability — Likelihood of occurrence based on heritage, testing, analysis, or expert judgment.
• Detectability — Ability to detect the failure before or during its manifestation.
• Single points of failure — Elements whose failure alone causes system-level consequences.
• Common-cause failures — Single events or conditions that can trigger multiple simultaneous failures.
• Risk priority — Combined severity × probability ranking identifying the most critical items.
• Barrier integrity — Strength and independence of preventive and mitigative controls.
• Heritage and flight data — Empirical evidence from similar systems that informs risk estimates.
• Residual risk — Risk remaining after all practical mitigations are applied.

Expected Output

• System decomposition showing assessable elements and their functional relationships.
• FMEA table cataloging failure modes with cause, effect, severity, probability, detectability, and priority for each element.
• Fault trees for the top 3-5 most critical failure scenarios, identifying single points of failure and common-cause vulnerabilities.
• Risk matrix plotting all identified risks by severity and probability.
• Bow-tie diagrams for the highest-priority risks showing threat pathways, consequence pathways, and barriers.
• Prioritized risk register with mitigation options and residual risk assessment.
• Overall technology risk profile summary with a risk acceptability judgment and comparison to benchmarks or alternatives.

Limitations

• Quality is entirely dependent on the completeness of failure mode identification — unknown unknowns remain the greatest risk, and FMEA cannot discover what the analyst does not imagine.
• Probability estimation for novel technologies with no flight heritage is inherently speculative; the method works best for technologies with operational history.
• Can become extremely labor-intensive for complex systems; strategic-level application requires disciplined scoping to critical subsystems rather than exhaustive analysis.
• Quantitative risk assessment (probabilistic risk analysis) requires reliability data that is often unavailable for emerging space technologies.
• The method focuses on technical risks and does not address programmatic risks (schedule, budget, organizational), market risks, or regulatory risks — these require separate frameworks.
• Tends toward conservatism — systematically identifying failure modes can create a risk-averse bias that underweights the strategic cost of inaction or delay.
• Fault tree analysis assumes static system architecture; dynamic systems with adaptive control or reconfiguration are harder to model with classical fault trees.
• For strategic publications, the method’s output must be translated from engineering detail into strategic-level risk narratives — raw FMEA tables are not suitable for M2 deliverables.