Electronics Guide

Hazards, Risks, and Accidents

A hazard is a potential source of harm, representing a condition or situation with the inherent potential to cause injury, damage, or loss. Hazards themselves do not cause harm; rather, they create the potential for harm when combined with exposure and triggering conditions. In embedded systems, hazards might include unintended motor activation, loss of braking capability, or incorrect medication dosing.

Risk quantifies the combination of hazard severity and likelihood of occurrence. Risk assessment considers both how bad the consequences could be if a hazard leads to an accident and how probable that outcome is. A hazard with catastrophic potential but extremely low probability may present lower overall risk than a moderately severe hazard that occurs frequently.

An accident occurs when a hazard is triggered and leads to actual harm. Accidents result from chains of events that begin with initiating causes, progress through hazardous states, and culminate in harmful outcomes. Effective safety engineering aims to break these chains at multiple points, preventing hazards from ever leading to accidents.

Safety Functions and Safety Integrity

Safety functions are specific actions or features implemented to achieve or maintain a safe state. These functions may prevent hazardous conditions from arising, detect hazardous conditions and trigger appropriate responses, or mitigate consequences when hazardous conditions occur. Examples include emergency shutdown systems, overspeed protection, and fail-safe defaults.

Safety integrity refers to the probability that a safety function will perform its required function satisfactorily under all stated conditions within a specified time period. Higher safety integrity implies greater confidence that the safety function will work when needed. Safety Integrity Levels (SILs) provide standardized categories for specifying required safety integrity based on the risk reduction needed from each safety function.

Tolerable Risk and ALARP

Tolerable risk represents the level of risk that society is willing to accept for a given activity in return for its benefits. Determining tolerable risk involves ethical, economic, and societal considerations beyond pure engineering analysis. Different application domains establish different tolerable risk thresholds based on societal expectations and historical precedent.

The ALARP (As Low As Reasonably Practicable) principle requires that risks be reduced below the intolerable threshold and then further reduced until the cost of additional reduction becomes grossly disproportionate to the safety benefit gained. ALARP recognizes that absolute safety is unattainable and that resources for safety improvement are limited. This principle guides engineers in making rational decisions about safety investments.

Defense in Depth

Defense in depth implements multiple independent layers of protection against hazards. If one protective layer fails, subsequent layers continue to provide protection. This principle recognizes that no single protection mechanism is perfectly reliable and that diverse approaches provide greater overall protection than reliance on any single measure.

In embedded systems, defense in depth might include input validation at multiple processing stages, independent monitoring of safety-critical parameters, hardware interlocks supplementing software protections, and mechanical safeguards backing up electronic controls. Each layer addresses the possibility that previous layers might fail or be bypassed.

Preliminary Hazard Analysis

Preliminary Hazard Analysis (PHA) provides early identification of potential hazards before detailed design begins. PHA examines system concepts, intended functions, and operating environments to identify hazardous conditions that might arise. The analysis considers energy sources, hazardous materials, environmental factors, human interactions, and interfaces with other systems.

PHA typically produces a list of identified hazards with preliminary severity assessments and recommended design constraints or safety requirements. This early analysis influences fundamental architectural decisions, potentially eliminating hazards through design choices rather than requiring later mitigation. PHA results guide resource allocation for more detailed analysis as design progresses.

The technique examines categories of potential hazards systematically. For embedded systems, these categories include electrical hazards such as shock and fire, mechanical hazards from moving parts, thermal hazards from heating or cooling, radiation hazards if applicable, software hazards from erroneous outputs or timing failures, and interface hazards at system boundaries.

Hazard and Operability Study

Hazard and Operability Study (HAZOP) provides a structured methodology for identifying hazards and operability problems in process systems. Originally developed at Imperial Chemical Industries for chemical plants, HAZOP has been adapted for other domains including embedded systems, and the method is standardized internationally as IEC 61882. The technique systematically examines deviations from design intent to identify potential problems.

HAZOP applies guide words to system parameters to generate deviation scenarios. Standard guide words include NO (complete negation), MORE (quantitative increase), LESS (quantitative decrease), AS WELL AS (qualitative addition), PART OF (qualitative reduction), REVERSE (logical opposite), and OTHER THAN (complete substitution). Studies of programmable systems commonly add temporal guide words such as EARLY, LATE, BEFORE, and AFTER, since timing deviations dominate software-related hazards. For each deviation, the team identifies possible causes, consequences, existing safeguards, and recommendations, recording the result in a worksheet that becomes part of the hazard log.

For embedded systems, HAZOP examines deviations in signals, data flows, timing, and functional behavior. A HAZOP study might consider scenarios such as "no sensor signal received," "higher than expected temperature reading," "command executed late," or "incorrect mode transition." The systematic nature of HAZOP helps ensure comprehensive coverage of potential deviations.

Failure Mode and Effects Analysis

Failure Mode and Effects Analysis (FMEA) examines potential failure modes of system components and their effects on system behavior. The analysis proceeds bottom-up, starting with individual components and tracing the effects of their failures through the system hierarchy. FMEA provides systematic coverage of hardware failure modes and identifies single points of failure requiring additional protection.

For each component, FMEA identifies possible failure modes based on component type and function. Common failure modes include open circuit, short circuit, drift, stuck-at, intermittent operation, and degraded performance. The analysis then traces the local effect of each failure mode, the effect on higher-level assemblies, and ultimately the end effect on system safety and operation.

FMEA results include severity ratings, occurrence probability estimates, and detection capability assessments, each conventionally scored from 1 to 10. The Risk Priority Number (RPN), calculated as the product of the three ratings, has long been used to prioritize failure modes. RPN is a poor discriminator, however, because arithmetically equal products can represent very different exposures: a severity of 10 paired with low occurrence and good detection yields the same RPN as three middling scores, yet the two demand entirely different responses.

For this reason the joint AIAG and VDA FMEA Handbook, published in 2019 for the automotive industry, replaced RPN with Action Priority (AP). AP assigns every combination of severity, occurrence, and detection ratings to a High, Medium, or Low priority band through a fixed lookup table, weighting severity first, occurrence second, and detection last. The change removes the false precision of a single multiplied number and forces high-severity failure modes to the top of the queue regardless of how well they are detected.

Design FMEA (DFMEA) focuses on product design weaknesses, while Process FMEA (PFMEA) examines manufacturing process failures that could compromise product safety. Failure Mode, Effects, and Diagnostic Analysis (FMEDA) extends the method for functional safety work by classifying each failure mode as safe or dangerous and as detected or undetected, yielding the safe failure fraction and diagnostic coverage figures that IEC 61508 requires for hardware integrity claims. All of these variants contribute to comprehensive safety assurance for embedded systems.

System-Theoretic Process Analysis

System-Theoretic Process Analysis (STPA) takes a systems-thinking approach to hazard analysis, focusing on inadequate control rather than component failure. Developed by Nancy Leveson and colleagues at the Massachusetts Institute of Technology from the STAMP accident causality model, STPA recognizes that accidents often result from unsafe interactions among components that have each functioned exactly as specified. The technique is particularly valuable for complex software-intensive systems, where the dominant hazard is a flawed requirement rather than a broken part, and where traditional failure-based methods may therefore miss important hazards entirely.

STPA begins by identifying accidents and system-level hazards, then models the system as a hierarchical control structure. The analysis examines how control actions could be unsafe: a required control action is not provided, an unsafe control action is provided, a potentially safe control action is provided too early, too late, or out of sequence, or a control action is stopped too soon or applied too long.

For each unsafe control action, STPA identifies causal scenarios that could lead to its occurrence. These scenarios consider controller failures, feedback inadequacies, communication problems, and flawed mental models. The resulting causal scenarios inform safety requirements and architectural decisions for preventing unsafe control.

What-If Analysis

What-if analysis uses structured brainstorming to identify hazards by posing questions about potential deviations and failures. A team of experts systematically asks "what if" questions about system behavior under various conditions. This technique leverages team experience and creativity while providing structured documentation of the analysis process.

What-if questions address various aspects of system behavior: What if the sensor fails? What if the operator enters incorrect data? What if power is interrupted during a critical operation? What if software executes an unexpected branch? The team discusses each scenario, identifying potential consequences and existing protections.

What-if analysis works well for early hazard identification when detailed design information is limited. The technique also complements more structured methods by capturing hazards that formal procedures might miss. Effective what-if analysis requires experienced participants with diverse perspectives on system behavior and potential failure modes.

Risk Matrix Approach

Risk matrices provide a semi-quantitative framework for classifying risks based on severity and likelihood. The matrix rows represent severity categories ranging from negligible to catastrophic, while columns represent likelihood categories from incredible to frequent. Cell intersections indicate risk levels that map to required actions.

Typical severity categories for embedded systems include catastrophic (death or system loss), critical (severe injury or major system damage), marginal (minor injury or significant system degradation), and negligible (less than minor injury or minor system impairment). Likelihood categories might span from frequent (likely to occur often in system life) to incredible (so unlikely as to be practically impossible).

Risk matrices enable rapid risk classification without detailed quantitative analysis. However, they have limitations including subjective categorization, boundary effects between categories, and inability to represent continuous risk variation. Despite these limitations, risk matrices provide useful first-pass assessments and facilitate communication about risk levels.

Quantitative Risk Analysis

Quantitative risk analysis calculates numerical risk values from probability and consequence data. This approach enables precise risk comparison and verification that risks meet numerical targets. Quantitative analysis requires failure rate data, consequence severity estimates, and mathematical models relating failures to outcomes.

Risk calculations typically express results as probability of harm per unit time or per operation. Civil aviation supplies the best-known example: a failure condition classified as catastrophic must be shown to be extremely improbable, conventionally interpreted as an average probability below 10^-9 per flight hour, with progressively less demanding targets for hazardous, major, and minor conditions. Quantitative analysis demonstrates compliance with such targets by calculating the probability of each accident scenario and summing across all identified scenarios.

Quantitative analysis depends heavily on input data quality. Failure rate databases provide component reliability data, but application-specific factors may require adjustment. Uncertainty analysis, often using Monte Carlo simulation, characterizes confidence bounds on calculated risk values. Conservative assumptions ensure that calculated risks do not underestimate actual risks.

Fault Tree Analysis

Fault Tree Analysis (FTA) models the logical relationships between component failures and system-level hazards. Starting from a top event representing a hazardous condition, the analysis works backward to identify combinations of basic events that could cause the top event. The resulting tree structure visualizes failure logic and enables quantitative probability calculation.

FTA uses Boolean logic gates to represent relationships between events. AND gates indicate that all input events must occur for the output event to occur, while OR gates indicate that any single input event causes the output. More complex gates represent voting logic, priority relationships, and other conditional dependencies.

Minimal cut sets identify the smallest combinations of basic events sufficient to cause the top event. Single-point cut sets, containing only one basic event, represent critical vulnerabilities requiring additional protection. Common cause analysis examines whether apparently independent basic events might share common failure mechanisms that would defeat redundancy.

Quantitative FTA calculates top event probability from basic event probabilities using the tree logic. This calculation supports verification of probabilistic safety targets and identification of dominant contributors to risk. Importance measures quantify each basic event's contribution to overall risk, guiding mitigation priorities.

Event Tree Analysis

Event Tree Analysis (ETA) models accident sequences starting from initiating events and progressing through safety function responses. Each branch point represents a safety function that either succeeds or fails, with different outcomes depending on the combination of successes and failures. The tree structure visualizes the range of possible accident sequences and their probabilities.

Event trees complement fault trees by modeling success paths as well as failure paths. While fault trees focus on how hazardous conditions arise, event trees show how initiating events progress or are arrested depending on safety function performance. The combination of both techniques provides comprehensive accident modeling.

Constructing event trees requires identifying initiating events, determining the safety functions that respond to each initiator, establishing the sequence in which safety functions act, and estimating success and failure probabilities for each function. Dependent failures between safety functions must be considered, as common cause failures can compromise multiple branches simultaneously.

Bow-Tie Analysis

Bow-tie analysis combines fault tree and event tree methods into an integrated visualization centered on a hazardous event. The left side of the bow-tie (the fault tree portion) shows how initiating causes can lead to the central hazardous event. The right side (the event tree portion) shows how the hazardous event can progress to various consequences.

Prevention barriers appear on the left side, blocking paths from causes to the hazardous event. Mitigation barriers appear on the right side, preventing the hazardous event from leading to harmful consequences. This visualization clearly shows the complete barrier structure protecting against the hazard.

Bow-tie diagrams communicate safety architecture effectively to diverse stakeholders. The visual format helps non-specialists understand how multiple barriers contribute to safety. Bow-ties also facilitate barrier management by clearly identifying each barrier and its role in the overall protection scheme.

Risk Graph Method

The risk graph method, described in the informative annexes of IEC 61508-5, determines SIL requirements through a structured decision tree. The method considers consequence severity, frequency of exposure to hazard, possibility of avoiding the hazard, and probability of unwanted occurrence without the safety function. Each factor selects a branch in the decision tree, with the path through the tree determining the required SIL.

Consequence severity categories range from minor injury to multiple fatalities or catastrophic environmental damage. Exposure frequency considers how often people are in the hazard zone, from rare to continuous presence. Avoidance possibility reflects whether harm can be escaped once a hazardous situation develops. Demand probability estimates how often the safety function must act.

The risk graph approach is straightforward to apply but provides only coarse SIL discrimination. The method works best for initial SIL estimation during early development phases. More refined analysis may be needed when risk graph results indicate SIL boundaries or when consequences span multiple categories.

Risk Matrix Method

The risk matrix method for SIL determination maps risk levels directly to required SIL values. The organization defines acceptable risk thresholds and the risk reduction each SIL provides. Comparing unmitigated risk levels to acceptable thresholds determines the SIL needed for adequate risk reduction.

This method requires calibrating the risk matrix to quantitative risk values and establishing the risk reduction factor associated with each SIL. For low-demand functions the risk reduction factor is simply the reciprocal of PFD_avg, giving 10 to 100 for SIL 1, 100 to 1,000 for SIL 2, 1,000 to 10,000 for SIL 3, and 10,000 to 100,000 for SIL 4. The required SIL is the level that reduces risk from unmitigated levels to tolerable thresholds. Where the calculated factor lands near a boundary, the higher level should ordinarily be selected, since the uncertainty in the underlying estimates usually exceeds the width of the boundary itself.

Quantitative Method

The quantitative method calculates required SIL from numerical safety targets and hazard analysis results. Given a tolerable risk target and calculated unmitigated risk, the required risk reduction factor determines SIL. This method provides the most precise SIL determination but requires quantitative hazard analysis.

For example, if tolerable risk is 10^-8 fatalities per hour and unmitigated risk is 10^-4 fatalities per hour, the required risk reduction factor is 10⁴. That figure falls exactly on the SIL 3 boundary, so SIL 4 is the defensible selection unless the input estimates can be shown to be conservative. The safety function must achieve at least this risk reduction factor to bring overall risk within tolerability limits.

Quantitative SIL determination should account for multiple hazards protected by the same safety function and multiple safety functions protecting against the same hazard. The combined effect of all safety measures must achieve tolerable risk for each identified hazard.

Layers of Protection Analysis

Layers of Protection Analysis (LOPA) provides a semi-quantitative approach to SIL determination popular in process industries. LOPA examines each hazard scenario, identifying independent protection layers (IPLs) and their probability of failure on demand (PFD). The analysis determines whether existing layers provide sufficient protection or whether additional safety-instrumented functions are needed.

Each IPL receives a PFD credit based on its design and independence. The product of initiating event frequency and all IPL PFDs yields the mitigated event frequency. Comparing this frequency to target frequency thresholds determines whether additional protection is required and at what SIL.

LOPA works well when independent protection layers can be clearly identified and characterized. The method forces explicit consideration of layer independence and failure modes. However, LOPA requires careful attention to common cause failures that might defeat multiple layers simultaneously.

Software FMEA

Software FMEA adapts the traditional FMEA methodology for software components. Rather than examining physical failure modes, software FMEA considers functional failure modes such as incorrect output, missing output, output out of range, output at wrong time, or unexpected additional output. Each software function is analyzed for these potential failure modes and their system effects.

Software FMEA examines interfaces between software components, identifying data corruption, timing violations, and protocol errors. The analysis also considers configuration errors, resource exhaustion, and interaction failures between concurrent processes. Results guide defensive programming requirements and error handling design.

Software Fault Tree Analysis

Software FTA extends fault tree methods to software failures. Top events represent hazardous software behaviors, with the tree decomposing these into contributing software faults. Unlike hardware fault trees, software fault trees typically cannot be quantified probabilistically since software failures are deterministic given specific inputs and states.

Software fault trees identify conditions under which software could produce hazardous outputs. These conditions might include specific input combinations, particular state sequences, resource conditions, or timing relationships. The identified conditions inform test case development and defensive measure design.

Interface Hazard Analysis

Interface hazard analysis examines boundaries between system components where communication or interaction occurs. Interfaces between hardware and software, between software modules, and between the system and external entities all merit careful analysis. Interface failures often cause accidents because they involve assumptions that may not be validated.

The analysis considers data format mismatches, timing incompatibilities, protocol violations, error handling inconsistencies, and assumption mismatches. For each interface, potential hazards from both directions are examined: hazards from upstream component failures affecting downstream components and hazards from downstream component behaviors affecting upstream components.

Code-Level Safety Analysis

Code-level safety analysis examines implementation details that could contribute to hazardous behavior. Static analysis tools identify potentially dangerous coding patterns such as uninitialized variables, buffer overflows, integer overflows, null pointer dereferences, and race conditions. Dynamic analysis through testing exercises code paths related to safety-critical functions.

Safety-critical code often requires adherence to coding standards such as MISRA C, which restricts language constructs whose behavior is undefined, unspecified, or implementation-defined, and which therefore cannot be reasoned about reliably. The current edition, MISRA C:2023, consolidates MISRA C:2012 together with its amendments and technical corrigenda, extends coverage to the C11 and C18 language revisions, and adds rules governing multithreading and atomic operations. It comprises roughly 220 guidelines, divided into directives, which require judgment and cannot be checked mechanically, and rules, which are amenable to static analysis. Guidelines are further classified as mandatory, required, or advisory, and a compliant project documents a deviation record for each departure from a required guideline.

Compliance checking verifies that code meets applicable standard requirements, though no tool detects every violation and the residue must be covered by review. Additional analysis may examine worst-case execution time for real-time safety functions and worst-case stack depth to prevent overflow, both of which are properties of the compiled binary and the target hardware rather than of the source alone.

Sources of Common Cause Failure

Common cause failures arise from shared vulnerabilities among redundant components. Environmental factors such as temperature extremes, humidity, electromagnetic interference, or power supply disturbances can affect multiple components simultaneously. Design errors replicated across redundant channels defeat redundancy when the same fault activates in each channel.

Manufacturing defects from shared production processes may affect batches of components used in redundant channels. Maintenance errors affecting multiple channels simultaneously, such as incorrect calibration procedures, create common cause vulnerabilities. Software executing on redundant processors represents a systematic common cause that no amount of hardware redundancy can address.

Beta Factor Method

The beta factor method provides a simple model for quantifying common cause failure probability. The beta factor represents the fraction of total failures that affect multiple redundant channels. For example, a beta factor of 0.1 indicates that 10% of failures are common cause failures affecting all redundant channels simultaneously.

Industry databases and standards provide guidance on beta factor selection based on system design features. IEC 61508-6 offers a checklist-based scoring scheme in which credit is awarded for separation, diversity, complexity, procedures, competence, environmental control, and testing, and the accumulated score maps to a beta value; well-separated and diverse channels score in the low single-digit percentages, while channels sharing an enclosure, a design, and a maintenance crew score far worse. Factors that reduce beta include physical separation, diverse designs, independent power supplies, different environmental exposures, and staggered testing. The beta factor method provides first-pass common cause estimates, with more detailed models available when greater precision is needed.

The method's chief limitation is that it cannot make redundancy better than its shared vulnerabilities allow. Because the beta factor sets a floor on the failure probability of the redundant group, adding further identical channels yields rapidly diminishing returns: beyond a certain point, the common cause term dominates and additional redundancy buys almost nothing. Recognizing that floor early prevents architectures that look highly redundant on paper while delivering little real risk reduction.

Defense Against Common Cause Failure

Defending against common cause failures requires multiple strategies. Diversity uses different technologies, designs, or implementations for redundant functions, preventing single design errors from affecting all channels. Physical separation protects against environmental common causes. Staggered testing intervals reduce vulnerability to systematic test-induced failures.

Functional diversity implements redundant functions through different algorithms or approaches. For example, a primary protection function might use calculated parameters while a backup uses direct measurements. Hardware diversity might combine electronic and mechanical protection mechanisms. Software diversity through independently developed programs provides defense against systematic software faults.

Human Error Identification

Human error analysis identifies potential operator mistakes and their consequences. Task analysis breaks down human interactions with the system into discrete steps, examining each for potential errors. Error types include slips (correct intention, incorrect action), mistakes (incorrect intention), and violations (deliberate deviation from procedures).

Common human errors in embedded system interaction include incorrect parameter entry, wrong mode selection, misinterpretation of display information, failure to respond to alarms, and incorrect maintenance actions. The analysis identifies which errors could contribute to hazardous conditions and estimates their likelihood based on task complexity, training, and interface design.

Human Reliability Analysis

Human Reliability Analysis (HRA) quantifies human error probabilities for inclusion in probabilistic safety assessment. Techniques such as THERP (Technique for Human Error Rate Prediction) and HEART (Human Error Assessment and Reduction Technique) provide frameworks for estimating error probabilities based on task characteristics and performance shaping factors.

Performance shaping factors include time available, training, procedures, human-machine interface design, stress level, and environmental conditions. Favorable factors reduce error probability while unfavorable factors increase it. HRA results enable inclusion of human actions in fault trees and event trees alongside hardware and software failures.

Designing for Human Reliability

System design can reduce human error probability and mitigate error consequences. Clear, consistent user interfaces reduce cognitive load and interpretation errors. Confirmation requirements for critical actions prevent inadvertent activations. Feedback mechanisms inform operators of system state and action results.

Error tolerance designs detect human errors and either prevent their propagation or enable easy correction. Input validation catches out-of-range entries before they affect system behavior. Undo capabilities allow recovery from incorrect actions. Safety interlocks prevent dangerous actions regardless of operator commands. These design features complement operator training and procedures to minimize human contribution to accidents.

Hazard Log

The hazard log serves as the central repository for all identified hazards and their management status. Each hazard entry includes unique identification, description, severity classification, current status, responsible party, and links to supporting analysis. The hazard log tracks hazards from initial identification through resolution and verification.

Hazard status categories typically include open (identified but not yet addressed), mitigated (controls implemented but not verified), closed (controls verified effective), or transferred (responsibility assigned to another party). The hazard log provides visibility into safety analysis progress and outstanding safety concerns.

Safety Requirements Traceability

Safety requirements trace from hazards through design solutions to verification evidence. Forward traceability ensures that each hazard has corresponding safety requirements and that each requirement has implementing design elements. Backward traceability confirms that all safety design features address identified hazards rather than implementing unnecessary protections.

Traceability matrices document relationships between hazards, requirements, design elements, and verification activities. These matrices support impact analysis when changes occur, identifying which safety requirements might be affected by proposed modifications. Maintaining traceability throughout development and modification enables ongoing safety assurance.

Safety Case Structure

A safety case presents the structured argument that a system is acceptably safe for its intended use. The safety case compiles evidence from hazard analysis, design documentation, verification results, and operational experience into a coherent argument. Goal Structuring Notation (GSN) and Claims-Arguments-Evidence (CAE) provide standard formats for presenting safety arguments.

The safety case demonstrates that all significant hazards have been identified, that appropriate mitigations address each hazard, that mitigations have been correctly implemented, and that residual risks are tolerable. The safety case provides the foundation for regulatory approval and ongoing safety management throughout operational life.

Concept Phase Analysis

Concept phase analysis identifies hazards early when fundamental design decisions are being made. Preliminary Hazard Analysis examines the system concept to identify inherent hazards and influence architecture selection. Early hazard identification enables hazard elimination through design rather than requiring later mitigation of inherent hazards.

Concept phase results include initial hazard lists, preliminary safety requirements, and architecture constraints. These results guide subsequent detailed design and establish safety targets for later verification. Investing in thorough concept phase analysis pays dividends through reduced rework and safer fundamental designs.

Design Phase Analysis

Design phase analysis examines detailed designs for compliance with safety requirements and identification of additional hazards. FMEA, FTA, and HAZOP provide systematic examination of design details. Interface analysis verifies safe interaction between components. SIL verification confirms that safety function designs meet integrity requirements.

Design phase hazard analysis is iterative, with results feeding back into design modifications. Design reviews incorporate hazard analysis results, requiring resolution of identified concerns before proceeding. The hazard log tracks design-phase hazards and their resolution through design changes or acceptance rationale.

Implementation and Test Phase Analysis

Implementation phase analysis verifies that detailed implementations match analyzed designs. Code-level analysis examines software implementations for hazardous patterns. Hardware inspections verify that built systems match designs and specifications. Test results provide evidence that safety functions perform as required.

Testing specifically exercises safety functions and hazard mitigations. Test cases derived from hazard analysis verify that identified hazard scenarios are properly handled. Fault injection testing demonstrates correct response to failure conditions. Integration testing verifies safe interaction between system components.

Operational Phase Analysis

Operational phase analysis monitors safety performance and identifies emerging hazards. Incident investigation examines near-misses and accidents to identify previously unrecognized hazards or inadequate mitigations. Safety performance indicators track leading indicators of safety degradation. Periodic safety reviews assess whether original hazard analysis remains valid.

Changes during operation require impact assessment against the hazard analysis. Modifications might introduce new hazards, affect existing mitigations, or invalidate analysis assumptions. Change management processes ensure that hazard analysis is updated to reflect system changes and that safety is maintained throughout modifications.

Automotive Safety Analysis

Automotive functional safety under ISO 26262 emphasizes Hazard Analysis and Risk Assessment (HARA) as a key activity of the concept phase. HARA evaluates hazards at the vehicle level, in defined operational situations, using three parameters: severity of harm (S0 through S3, from no injuries to fatal injuries), probability of exposure to the operational situation (E0 through E4, from incredible to high probability), and controllability by the driver or other road users (C0 through C3, from controllable in general to difficult to control or uncontrollable). The combination determines an Automotive Safety Integrity Level from ASIL A (lowest) to ASIL D (highest), with QM indicating that quality-management processes suffice and no ISO 26262 safety requirement applies. Only the most severe combination, S3 with E4 and C3, yields ASIL D, and any parameter at its lowest value drives the result to QM.

Each hazardous event that receives an ASIL generates a safety goal, the top-level safety requirement from which the functional and technical safety requirements are derived. Automotive analysis must consider diverse operating conditions, driver populations, and road environments; the exposure parameter in particular is a statement about how much of the driving population's time is spent in the relevant situation, not about how often the fault occurs. The fault tolerant time interval defines the span between a fault occurring and a hazardous event resulting, and it bounds the time available for the safety mechanism to detect the fault and reach a safe state.

ISO 26262 addresses hazards arising from malfunctioning behavior. Hazards that arise without any malfunction, from performance limitations or foreseeable misuse of an intended function, fall instead under ISO 21448, Safety of the Intended Functionality. That distinction matters increasingly for perception-based driver assistance, where a sensor may perform exactly to specification and still fail to resolve an object.

Medical Device Risk Analysis

Medical device risk management under ISO 14971, currently in its 2019 edition, requires systematic risk analysis considering device failures, reasonably foreseeable misuse, and use errors. Medical device hazards include direct harm from device malfunction as well as indirect harm from diagnostic errors or treatment delays. The 2019 edition strengthened the treatment of benefit-risk analysis: where residual risk is not acceptable against the manufacturer's own criteria, the manufacturer must determine whether the medical benefits of the intended use outweigh that residual risk, and document the determination.

Medical device analysis involves clinical risk assessment requiring medical domain expertise alongside engineering analysis. The 2019 edition also expanded production and post-production activities into a distinct set of requirements covering the collection of field information, its review against the risk assessment, and action on individual devices and on the risk management process itself. Post-market surveillance therefore functions as a formal input to ongoing hazard identification rather than an optional supplement.

For software-containing devices, ISO 14971 works alongside IEC 62304, which governs the software lifecycle and introduces the concept of Software of Unknown Provenance (SOUP): software already developed and generally available, not created for the device in question, and for which adequate development records are unavailable. Operating systems, communication stacks, and open-source libraries commonly fall into this category. SOUP analysis identifies the functional and performance requirements the component must satisfy, together with the anomalies published for it that could contribute to a hazardous situation.

Aerospace Safety Assessment

Civil aerospace safety assessment follows the SAE Aerospace Recommended Practices ARP4761 for safety assessment methods and ARP4754 for development assurance. Both were revised in December 2023 and are intended to be applied as a matched pair: ARP4761A replaced the 1996 original, and ARP4754B replaced ARP4754A, with the revision clarifying the boundary between system development and safety assessment and adding guidance on the assignment of function and item development assurance levels. ARP4761A also formally recognizes model-based safety analysis, reflecting the shift from hand-drawn fault trees toward analyses generated from annotated architecture models.

The process is layered. Functional Hazard Assessment (FHA) identifies failure conditions and classifies their severity as no safety effect, minor, major, hazardous, or catastrophic, each carrying a quantitative probability target. Preliminary System Safety Assessment (PSSA) works top-down to allocate safety requirements to system elements and establish the architecture needed to meet them. System Safety Assessment (SSA) works bottom-up on the implemented design to verify that the allocated requirements are met. Common Cause Analysis, comprising zonal safety analysis, particular risks analysis, and common mode analysis, runs alongside these to substantiate the independence claims on which the probability arithmetic depends.

Development Assurance Levels, from DAL A for catastrophic failure conditions to DAL E for those with no safety effect, correspond to failure condition severity and impose process rigor in the manner of SIL requirements; DO-178C and DO-254 supply the corresponding software and airborne electronic hardware objectives. Because software and complex hardware faults are systematic rather than random, no probability may be claimed for them, so the combination of system-level probability targets for random failures and process-level assurance for systematic faults is what constitutes the complete safety demonstration.

Industrial Control Safety Analysis

Industrial safety instrumented systems follow IEC 61511, the process-sector implementation of IEC 61508. HAZOP analysis identifies process deviations that could lead to hazardous conditions. LOPA then determines the required SIL for each safety instrumented function from the initiating event frequency and the credit claimed for existing protection layers. Because most process safety functions sit idle until a demand arrives, they are almost always assessed in low-demand mode against PFD_avg.

Industrial applications must consider systematic failures in safety systems and, above all, dangerous undetected failures, which leave the function unable to respond while giving no outward sign of trouble. Two design parameters govern how far such failures can be contained. Diagnostic coverage determines what fraction of dangerous failures the system reveals automatically, and the proof test interval determines how long an undetected failure can persist before periodic testing exposes it. Lengthening the proof test interval raises PFD_avg roughly in proportion, which is why a claimed SIL is meaningless without the test interval that supports it. The safety requirements specification records these parameters alongside the functional requirements derived from hazard analysis.

Hazard Analysis Tools

Dedicated hazard analysis tools provide structured support for techniques such as FMEA, FTA, and HAZOP. These tools enforce consistent methodology, maintain analysis databases, and generate reports. Integration between tools enables propagation of results from one analysis type to another.

Fault tree analysis tools include graphical editors for tree construction, libraries of common gate types, and calculation engines for quantitative analysis. Event tree tools similarly support graphical construction and probability calculation. Some tools integrate fault tree and event tree analysis for comprehensive accident modeling.

Model-Based Safety Analysis

Model-based safety analysis derives safety analysis artifacts from system models. Failure annotations on model elements enable automatic generation of FMEA tables and fault trees. This approach ensures consistency between system models and safety analysis while reducing manual analysis effort.

Tools such as AADL (Architecture Analysis and Design Language) with error annexes support modeling of fault behavior alongside normal system behavior. Automated analysis extracts fault propagation paths and generates fault trees from annotated models. Model-based approaches particularly benefit systems undergoing frequent modification, as safety analysis updates automatically with model changes.

Requirements Management Integration

Integration between hazard analysis tools and requirements management systems maintains traceability throughout development. Safety requirements derived from hazard analysis link to their originating hazards. Design elements link to the safety requirements they implement. Verification activities link to the requirements they verify.

Change impact analysis uses these links to identify safety analysis affected by proposed changes. Traceability reports demonstrate completeness of safety requirement implementation and verification. This integration supports both development efficiency and regulatory compliance demonstration.

Analysis Team Composition

Effective hazard analysis requires diverse expertise including system design, domain knowledge, safety engineering, and human factors. Team composition should include people with different perspectives who can challenge assumptions and identify overlooked hazards. Independent review by safety engineers not involved in design provides additional hazard identification.

Appropriate Technique Selection

Different hazard analysis techniques have different strengths and limitations. Selecting appropriate techniques requires considering system characteristics, lifecycle phase, available information, and regulatory requirements. Most safety-critical systems benefit from multiple complementary techniques rather than reliance on any single method.

Iterative Analysis

Hazard analysis should be iterative, with results from each cycle informing subsequent analysis and design. Initial broad analysis identifies major hazards and guides architecture decisions. Subsequent detailed analysis examines specific design solutions. Analysis continues through testing and operation as new information becomes available.

Conservative Assumptions

When uncertainty exists, hazard analysis should make conservative assumptions that do not underestimate risk. Severity assessments should consider worst-case consequences. Probability estimates should not rely on unverified assumptions about component reliability or human performance. Conservative analysis ensures that safety measures provide adequate protection even when analysis inputs prove optimistic.

Common Pitfalls

Several failure patterns recur across projects. The first is analyzing the system as designed rather than as it will be used, which omits foreseeable misuse, degraded modes, maintenance states, and the transitions between operating modes where many accidents originate. The second is treating hazard analysis as a certification deliverable produced after the design is frozen, at which point its findings can no longer influence architecture and can only be argued away.

A third pattern is unjustified independence: fault tree arithmetic multiplies probabilities on the assumption that basic events are independent, and an analysis that never tests that assumption will overstate integrity by orders of magnitude. A fourth is confusing a low probability estimate with a low risk, when the estimate itself rests on sparse data. Finally, analyses go stale. A hazard log that is not revisited after design changes, field incidents, or component substitutions describes a system that no longer exists, and its assurance value decays accordingly.