STATERA Library · Series 07 · Volume 12 · Chapter 05 · EN
Source: https://github.com/Statera-Library/07_Vol_12_Safety_Architecture/blob/main/Chapter_05_SIL_ASIL_Assessment/Chapter_05_SIL_ASIL_Assessment_EN.md

Volume 12. Safety Architecture

Chapter 05. SIL/ASIL Assessment

05.01. FMEA Method

Failure Mode and Effects Analysis (FMEA) is a systematic engineering method used to identify how components, functions, interfaces, or processes may fail and to evaluate the consequences of those failures before they occur in operation. Within safety engineering, FMEA provides a structured bottom-up approach that begins with individual failure modes and traces their effects toward subsystem, system, and ultimately hazardous behavior.

The fundamental principle of FMEA is to examine each element of a system and ask what functions it performs, how those functions can fail, why the failure might occur, and what happens when the failure is present. A failure mode may include loss of function, unintended activation, degraded performance, intermittent behavior, incorrect timing, or operation outside specified limits. This functional perspective allows FMEA to address hardware, software-related interfaces, sensors, actuators, and communication paths.

An FMEA normally begins by defining the analysis boundary and describing the system architecture at an appropriate level of decomposition. Engineers identify functions, components, interfaces, operating states, environmental conditions, and dependencies that belong within the analysis. The selected level of detail is important because an analysis that is too coarse may conceal critical mechanisms, while excessive decomposition can produce a large document without improving safety decisions.

For every analyzed item, potential failure modes are identified from its intended function and expected behavior. A motor controller, for example, may fail by producing no torque, excessive torque, unintended torque, incorrect rotational direction, or delayed torque response. A safety sensor may provide no detection, false detection, delayed detection, or incorrect distance information. Defining failure modes functionally helps connect component faults to observable system behavior.

After a failure mode is identified, its local effect and higher-level effects are evaluated. The local effect describes what happens directly to the affected component or function, while subsequent effects describe propagation through the subsystem and complete machine. In an autonomous mobile robot, loss of obstacle detection may first affect perception, then prevent timely protective action, and ultimately create a potential collision with a person, vehicle, or fixed structure.

Failure causes are then investigated to determine the physical, electrical, logical, environmental, or integration mechanisms capable of producing each failure mode. Typical causes include open circuits, short circuits, connector degradation, sensor contamination, power loss, communication interruption, overheating, component aging, configuration errors, and interface faults. Distinguishing a failure mode from its underlying cause is essential because different causes may require different prevention or diagnostic measures.

Traditional FMEA commonly evaluates risk through severity, occurrence, and detection criteria. Severity represents the seriousness of the resulting effect, occurrence estimates how likely the failure cause is to arise, and detection reflects the ability of existing controls to identify the problem before unacceptable consequences develop. These rankings support prioritization, although their scales and interpretation must be explicitly defined for the organization and application being analyzed.

The Risk Priority Number, commonly expressed as RPN = Severity × Occurrence × Detection, has historically been used to rank FMEA findings. RPN can provide a convenient screening indicator, but it should not be treated as an absolute measure of safety integrity. Different combinations of severity, occurrence, and detection can produce identical numerical values while representing substantially different safety concerns. High-severity failures therefore require explicit engineering attention regardless of RPN alone.

Modern FMEA practice consequently emphasizes engineering judgment and action prioritization rather than relying exclusively on a single calculated score. Safety-related failures should be evaluated according to their consequences, controllability, exposure, diagnostic capability, architectural protection, and applicable safety requirements. The purpose of ranking is not merely to create a numerical table but to identify where design changes, monitoring, redundancy, testing, or additional safety mechanisms are necessary.

Existing prevention and detection controls are documented for each relevant failure cause. Prevention controls reduce the probability that the failure will occur, whereas detection controls identify the fault or its effects after occurrence. Examples include electrical protection, thermal derating, watchdog supervision, plausibility checking, redundant sensing, communication timeout monitoring, diagnostic feedback, self-tests, and safe-state transitions. Their effectiveness should be supported by design evidence and verification.

Recommended actions are defined when the residual risk or engineering concern is unacceptable. Actions may involve changing the architecture, increasing component robustness, introducing redundancy, improving diagnostic coverage, modifying software monitoring, adding independent safety channels, strengthening environmental protection, or improving verification procedures. Each action should have a responsible owner and completion status so that the FMEA operates as an engineering control process rather than a static document.

FMEA is particularly valuable during early design because weaknesses can be discovered before hardware and software architectures become difficult to modify. Preliminary functional FMEA can be performed from requirements and block-level architecture, followed by increasingly detailed analyses as components and interfaces are defined. Repeating the analysis throughout development allows new information from prototypes, testing, field experience, supplier data, and design changes to refine the understanding of failure behavior.

For robotics, FMEA must consider interactions among power electronics, computing, sensing, communication, actuation, and mechanical motion. A single electrical fault may propagate across several domains. Loss of a power rail can disable perception and communication simultaneously, while corrupted timing information may affect sensor fusion and motion control without causing an obvious component shutdown. Analysis therefore needs to capture dependencies and common resources rather than treating every component as independent.

Autonomous systems also require careful consideration of operational modes. A failure that is harmless while a robot is stationary may become hazardous during navigation, docking, manipulation, charging, or high-speed travel. FMEA should therefore associate failure effects with relevant operating states and transitions. Startup, shutdown, maintenance, degraded operation, emergency stopping, and recovery states deserve explicit consideration because safety behavior can differ substantially between these conditions.

Common-cause and dependent failures require additional attention when redundancy is used as a safety mechanism. Two redundant sensors do not provide meaningful independence if both depend on the same power supply, communication switch, clock source, environmental condition, or software function. FMEA can expose these dependencies, although dedicated common-cause analysis or other complementary methods may be required when the architecture contains complex shared resources and correlated failure mechanisms.

FMEA is a bottom-up method and therefore complements rather than replaces top-down safety techniques. Fault Tree Analysis begins with an undesirable system-level event and investigates combinations of causes that could produce it, whereas FMEA begins with individual failures and examines their consequences. Using both approaches improves coverage because one reveals propagation from component faults while the other tests whether important hazardous system outcomes have been adequately explained by the identified fault mechanisms.

Within SIL and ASIL assessment activities, FMEA provides engineering evidence about failure behavior, diagnostic mechanisms, fault propagation, and the effectiveness of architectural controls. Its results can support more quantitative hardware analyses such as FMEDA, where failure rates and diagnostic coverage are considered explicitly. FMEA itself should therefore be understood as a foundation for systematic safety reasoning rather than as a direct mechanism for assigning SIL or ASIL classifications.

The quality of an FMEA depends strongly on traceability. Failure modes should be connected to functions and components, effects should relate to system behavior, safety-relevant findings should connect to requirements, and recommended actions should lead to implementation and verification evidence. When requirements, architecture, hardware, software, or operating assumptions change, the corresponding FMEA entries must be reviewed so that the analysis continues to represent the actual system configuration.

For an AMR or other Physical AI platform, a practical FMEA may examine battery and power distribution, motor drives, braking, steering, emergency-stop circuits, safety LiDAR, cameras, localization sensors, compute modules, communication networks, and safety controllers. The analysis should also consider whether a detected fault results in controlled degradation, restricted operation, protective stopping, emergency stopping, or another defined safe response appropriate to the hazard and operating context.

A mature FMEA ultimately functions as a living engineering model of how the system can fail and how the design responds. Its value comes not from the number of rows in a worksheet but from the disciplined connection between failure mechanisms, system consequences, safety requirements, mitigation measures, and verification evidence. When maintained throughout the lifecycle, FMEA becomes an important bridge between system architecture, detailed design, safety assessment, validation, and the final safety case.

05.02. FTA (Fault Tree Analysis)

Fault Tree Analysis (FTA) is a systematic, deductive safety analysis method used to determine how combinations of faults, failures, and abnormal conditions can lead to a defined undesirable system event. Unlike bottom-up methods such as FMEA, FTA begins with a system-level consequence called the top event and works downward through progressively more detailed causal relationships until basic events or other sufficiently understood causes are identified.

The analysis begins by defining the top event precisely. A useful top event describes a specific loss of safety function or hazardous system behavior rather than a vague condition such as "system failure." Examples include unintended robot motion, failure to stop within the required distance, loss of braking capability, collision due to failed obstacle detection, or uncontrolled actuator output. Clear definition establishes the boundary and prevents unrelated failure mechanisms from entering the analysis.

Once the top event is established, analysts identify the immediate events that could cause it and connect them through logical gates. An OR gate indicates that any one of its input events can produce the output event, whereas an AND gate indicates that all specified input events must occur together. These Boolean relationships allow complex system behavior to be represented as a logical structure and make dependencies between hardware, software, communication, sensing, and control functions visible.

The tree is expanded recursively by asking how each intermediate event could occur. Intermediate events may represent subsystem failures, loss of required functions, incorrect commands, unavailable diagnostics, or combinations of faults. Expansion continues until the analysis reaches basic events that do not require further decomposition for the intended purpose. These may include component failures, wiring faults, sensor faults, power interruptions, communication failures, or other defined root-level events.

Basic events form the lowest practical causal level of a fault tree. Their definition should be sufficiently specific to support qualitative or quantitative evaluation. For example, "braking failure" may be too broad, while "brake actuator power supply open circuit" provides a more useful engineering event. The appropriate depth depends on the system architecture, available reliability information, safety objectives, and the decisions that the analysis is expected to support.

FTA can incorporate additional gate types when simple AND and OR relationships are insufficient. Depending on the analysis method, voting gates may represent architectures such as two-out-of-three redundancy, while inhibit or conditional relationships may express failures that become relevant only under particular operating conditions. Dynamic or sequence-dependent behavior may require specialized extensions because conventional static fault trees do not naturally represent every temporal dependency.

Qualitative FTA focuses on identifying the combinations of basic events capable of producing the top event. One of its most important outputs is the minimal cut set, which is the smallest combination of basic events whose simultaneous occurrence is sufficient to cause the top event. A single-event minimal cut set can reveal a critical single point of failure, while multi-event cut sets help evaluate whether redundancy actually prevents individual faults from becoming hazardous.

Minimal cut sets also provide a practical way to examine architectural robustness. If a supposedly redundant safety function contains a cut set consisting of only one shared power supply, communication path, clock source, controller, or software service, the architecture may still contain a hidden single point of failure. FTA therefore helps engineers evaluate whether redundancy provides genuine independence or merely duplicates components that remain dependent on common resources.

Quantitative FTA extends the logical model by assigning probability or failure-rate information to appropriate basic events. Boolean relationships and probability calculations can then be used to estimate the likelihood of the top event under defined assumptions. Such calculations require careful treatment of mission time, failure distributions, repair assumptions, independence, diagnostic coverage, and operating conditions because unrealistic assumptions can produce numerically precise but misleading results.

Independence assumptions are especially important when calculating fault-tree probabilities. Two events cannot automatically be treated as statistically independent simply because they occur in different components. Common power supplies, environmental stresses, manufacturing defects, shared communication infrastructure, software dependencies, thermal conditions, and maintenance errors can create correlated failures. Common-cause failure analysis is therefore often necessary when evaluating redundant safety architectures.

For robotics, the top event may result from interaction among sensing, computation, communication, actuation, and mechanical behavior. An AMR collision, for example, could originate from failure to detect an obstacle, incorrect localization, unsafe trajectory generation, loss of communication with a safety device, excessive braking distance, or failure of the stopping actuator. FTA organizes these heterogeneous mechanisms according to their logical contribution to the same hazardous outcome.

Operating states should be explicitly considered because the logical conditions leading to a hazard may change with robot behavior. Navigation, docking, charging, manipulation, maintenance, startup, degraded operation, and emergency stopping can expose different fault combinations. A sensor failure that is tolerable during stationary maintenance may become safety-critical during autonomous motion, while a communication loss may have different consequences depending on whether local safety functions remain available.

Safety mechanisms are represented within the fault-tree logic according to how their failure contributes to the hazardous event. A hazard may require both a primary functional failure and failure of the mechanism intended to detect or mitigate it. This relationship can demonstrate the benefit of diagnostics, monitoring, redundancy, independent shutdown paths, watchdogs, safety relays, or protective stopping functions when those mechanisms are correctly represented in the causal structure.

FTA is particularly effective for analyzing single-point failures and combinations of multiple failures that may not be obvious from component-level examination. It can expose situations where two individually tolerable faults become hazardous when they occur together. This characteristic is important in systems designed to achieve higher levels of safety integrity, where the architecture must remain safe or transition to a safe state despite specified combinations of faults.

FTA and Failure Mode and Effects Analysis (FMEA) provide complementary views of system safety. FMEA begins with individual component or functional failures and traces their effects upward, while FTA begins with an undesirable system event and searches downward for causal combinations. Cross-checking the two analyses can reveal missing failure modes, overlooked propagation paths, inconsistent assumptions, and safety mechanisms that have not been adequately addressed by either method alone.

Fault Tree Analysis can also support subsequent quantitative hardware assessment. Basic events and cut sets provide information that may be linked with failure-rate data, diagnostic assumptions, FMEDA results, or reliability models. However, numerical evaluation should be performed only when the underlying data and modeling assumptions are sufficiently credible. The logical fault-tree structure remains valuable even when precise quantitative failure information is unavailable.

Within SIL and ASIL-oriented safety engineering, FTA provides evidence that hazardous system outcomes have been systematically traced to credible causal mechanisms. The analysis can support evaluation of architectural vulnerabilities, independence, fault combinations, diagnostic measures, and safety requirements. It does not independently determine SIL or ASIL classification; instead, it contributes structured evidence to the broader safety lifecycle and safety assessment process.

Traceability is essential for maintaining a useful fault tree. The top event should relate to identified hazards or safety goals, intermediate events should correspond to system functions and architecture, and basic events should connect to actual hardware, software, interfaces, or environmental assumptions. Safety mechanisms introduced by the analysis should lead to requirements, implementation, and verification evidence so that the logical model remains connected to the engineered system.

Fault trees should therefore evolve with the design rather than remain fixed after an early safety review. Architecture changes, new interfaces, supplier components, diagnostic functions, field failures, verification results, and modified operating assumptions can alter the causal structure. Reviewing affected branches after significant changes ensures that previously identified cut sets remain valid and that new single points of failure or dependent-failure paths have not been introduced.

For an AMR or Physical AI platform, FTA can connect hazardous motion to failures across safety LiDAR, cameras, localization, compute modules, networks, motor controllers, braking systems, power distribution, emergency-stop circuits, and safety controllers. This system-level perspective is especially valuable when intelligent functions interact with deterministic safety mechanisms because the analysis can clarify which combinations must be prevented, detected, tolerated, or forced into a defined safe state.

A mature FTA ultimately provides a logical explanation of how a hazardous system event can occur and what architectural barriers prevent it. Its value lies not merely in drawing a tree, but in exposing causal combinations, single points of failure, hidden dependencies, common resources, and weaknesses in safety mechanisms. When integrated with FMEA, FMEDA, requirements, verification evidence, and safety-case documentation, FTA becomes a central tool for demonstrating systematic control of system-level risk.

05.03. FMEDA Hardware Assessment

Failure Modes, Effects and Diagnostic Analysis (FMEDA) is a quantitative hardware safety assessment method that extends conventional FMEA by incorporating component failure rates, failure-mode distributions, safety effects, and diagnostic coverage. It is widely used to determine how random hardware failures influence the safety integrity of electronic systems and provides evidence for SIL- and ASIL-oriented assessments, particularly where quantitative hardware metrics must be demonstrated.

FMEDA begins with a clearly defined hardware architecture and safety function. The assessment boundary should identify power supplies, processors, memories, sensors, communication interfaces, drivers, protection circuits, actuators, and supporting components that contribute to the function being evaluated. Safety requirements and the intended safe state must also be understood because the classification of a hardware failure depends on whether that failure can violate the defined safety function.

The hardware architecture is decomposed into components or component groups at a level suitable for reliability analysis. Typical elements include integrated circuits, transistors, resistors, capacitors, inductors, connectors, relays, oscillators, voltage regulators, communication transceivers, and discrete protection devices. Excessive decomposition can create unnecessary analytical complexity, while insufficient decomposition may conceal important failure mechanisms or diagnostic relationships.

Each hardware element is assigned an appropriate failure rate, commonly expressed using FIT, where one FIT represents one failure per billion device-hours. Failure-rate information may originate from recognized reliability handbooks, semiconductor safety manuals, supplier reliability data, field experience, or other justified sources. The selected data source, operating conditions, temperature assumptions, environmental factors, and applicable derating conditions should be documented to maintain analytical credibility and traceability.

The total component failure rate is then distributed among relevant failure modes. A resistor, for example, may fail open, short, or outside its specified resistance range, while a semiconductor output may become stuck high, stuck low, open, shorted, or otherwise behave incorrectly. Failure-mode distributions convert a component-level reliability value into specific fault behaviors that can be evaluated according to their effects on the safety function.

Each failure mode is analyzed to determine whether it affects the safety-related function and how the system responds. Some failures have no safety relevance, some directly violate the safety function, and others are controlled by diagnostic or architectural mechanisms. The analysis therefore connects physical hardware faults to functional consequences and establishes the basis for classifying failures according to their contribution to hazardous behavior.

A central feature of FMEDA is the evaluation of diagnostic coverage. Diagnostic coverage represents the fraction of relevant dangerous failures that can be detected by implemented safety mechanisms. Examples include watchdog monitoring, voltage supervision, current monitoring, memory protection, communication diagnostics, sensor plausibility checks, redundant comparisons, output feedback, periodic self-tests, and independent monitoring circuits. Detection must lead to an appropriate safety reaction to provide meaningful safety benefit.

Diagnostic effectiveness should not be assumed simply because a diagnostic function exists. The analysis must determine which specific failure modes the diagnostic mechanism can detect, under what conditions detection occurs, and whether detection is sufficiently timely. A diagnostic that identifies a fault only after the fault has already produced an unacceptable hazardous effect may provide little safety value for that particular safety function.

FMEDA commonly distinguishes failures according to their safety significance and diagnostic status. Depending on the applicable standard and assessment framework, failures may be categorized as safe, dangerous detected, dangerous undetected, residual, single-point, multiple-point, latent, or otherwise safety-related. Correct classification is essential because these categories contribute differently to the quantitative hardware metrics used to demonstrate safety integrity.

A single-point fault is particularly important because it can directly violate a safety goal without an independent safety mechanism preventing or controlling the resulting hazard. Such faults often indicate architectural weakness and may require redundancy, additional monitoring, fail-safe circuitry, or a redesigned safety concept. FMEDA helps expose these weaknesses quantitatively by showing which portions of the hardware failure rate remain capable of directly compromising safety.

Latent and multiple-point failures are also significant in redundant architectures. One fault may initially remain hidden because another channel continues to perform the required safety function, but a later independent fault can then remove the remaining protection. Periodic diagnostics, proof testing, startup tests, continuous monitoring, and maintenance intervals are therefore important for limiting the time during which hidden faults can accumulate.

For IEC 61508-oriented analysis, FMEDA results can contribute to hardware safety integrity metrics such as Safe Failure Fraction and dangerous failure rates. The assessment may distinguish safe failures, dangerous detected failures, and dangerous undetected failures to evaluate whether the hardware architecture satisfies the required safety integrity constraints. Hardware Fault Tolerance and architectural requirements must also be considered rather than relying on diagnostic coverage alone.

Within ISO 26262-oriented hardware assessment, FMEDA can provide important input to metrics such as the Single Point Fault Metric and Latent Fault Metric. The analysis helps determine how effectively the architecture prevents single-point and residual faults from violating safety goals and how well latent multiple-point faults are controlled. These metrics complement probabilistic hardware evaluation and broader safety lifecycle evidence used for ASIL-related justification.

FMEDA is closely related to FMEA but adds quantitative reliability and diagnostic information. FMEA primarily identifies potential failure modes, causes, effects, and mitigation actions, whereas FMEDA associates hardware failure rates with those modes and evaluates how safety mechanisms detect or control them. A well-developed FMEA can therefore provide an important foundation for FMEDA, while FMEDA adds numerical evidence needed for hardware safety integrity assessment.

Fault Tree Analysis can complement FMEDA from the opposite analytical direction. FMEDA evaluates hardware failure behavior largely from the component or function level upward, while FTA begins with a hazardous top event and identifies combinations of faults that can produce it. FMEDA failure rates and classifications may provide inputs to quantitative fault-tree models, allowing component-level reliability evidence to support system-level probability assessment.

Common-cause and dependent failures require special consideration because simple FMEDA calculations can overestimate the benefit of redundancy if channels are assumed to be independent. Redundant controllers may share a power source, clock, communication bus, connector, environmental exposure, or software-controlled interface. These dependencies should be identified and addressed through architectural analysis, common-cause assessment, or complementary safety methods.

In robotic systems, FMEDA can be applied to motor controllers, safety controllers, power distribution units, braking electronics, sensor interfaces, emergency-stop circuits, communication gateways, battery monitoring circuits, and other safety-related hardware. For an AMR, failures that prevent obstacle detection, safe torque removal, controlled braking, or emergency stopping can be traced to physical components and evaluated against implemented diagnostic mechanisms.

The time relationship between fault occurrence, detection, and safety reaction is particularly important for moving robots. A diagnostic mechanism may have high theoretical coverage but still be inadequate if detection and reaction exceed the available fault-tolerant time interval. Hardware diagnostics must therefore be evaluated together with system timing, stopping distance, communication latency, actuator response, and the defined safe-state transition.

FMEDA results should remain traceable to the actual design configuration. Component identifiers, failure-rate sources, failure-mode distributions, diagnostic mechanisms, safety classifications, assumptions, and calculated metrics should be documented so that the analysis can be reviewed and reproduced. Changes to components, circuit topology, diagnostics, suppliers, operating conditions, or safety requirements should trigger assessment of the affected FMEDA entries.

Verification evidence is necessary to demonstrate that the diagnostic mechanisms assumed by the FMEDA actually achieve their claimed behavior. Fault-injection testing, circuit analysis, diagnostic tests, hardware-in-the-loop evaluation, environmental testing, and targeted verification can be used to confirm detection capability and safety reactions. Without such evidence, calculated diagnostic coverage may represent an analytical assumption rather than demonstrated system performance.

A mature FMEDA ultimately provides a quantitative connection between physical hardware reliability and system safety integrity. By combining failure rates, failure modes, safety effects, diagnostic coverage, architectural protection, and verification evidence, it identifies where dangerous hardware failures remain insufficiently controlled. Integrated with FMEA, FTA, SIL or ASIL assessment, safety requirements, and validation evidence, FMEDA becomes a key foundation for demonstrating that safety-related robotic hardware achieves its intended level of functional safety.

05.04. SIL/ASIL Decision Procedure

Safety Integrity Level (SIL) and Automotive Safety Integrity Level (ASIL) are classification concepts used to determine the rigor required for safety-related engineering, but they originate from different safety frameworks. SIL is associated primarily with IEC 61508 and related functional-safety standards, while ASIL is defined by ISO 26262 for road vehicles. A decision procedure must therefore begin by identifying the applicable domain, governing standard, system boundary, and safety lifecycle before selecting an integrity classification approach.

The first decision concerns whether the function being assessed is safety-related. Engineers define the system, intended operation, operating environment, interfaces, foreseeable misuse, and potential hazardous behavior. Hazards are identified from situations such as unintended motion, failure to stop, excessive speed, loss of steering or braking, incorrect actuator commands, electrical faults, or loss of protective sensing. Only after the hazardous consequences are understood can the required integrity level be meaningfully evaluated.

For an IEC 61508-oriented system, the process evaluates the risk associated with a hazardous event and determines how much risk reduction must be provided by safety-related functions. The analysis considers the consequence of the hazardous event together with factors representing exposure, probability, or frequency under the selected risk-assessment method. The required SIL expresses the level of risk reduction and safety integrity expected from the safety function rather than simply describing the severity of the hazard.

IEC 61508 defines SIL 1 through SIL 4, with SIL 4 representing the highest safety integrity requirement. Increasing SIL requires progressively stronger control of random hardware failures and systematic failures, together with more rigorous lifecycle processes, verification, independence, architecture, and evidence. The assigned SIL should therefore influence the complete development approach rather than being treated merely as a numerical label attached to a component or subsystem.

The quantitative interpretation of SIL depends on how the safety function operates. Low-demand functions are commonly evaluated using the average probability of dangerous failure on demand, while high-demand or continuous functions are evaluated using the probability or frequency of dangerous failure per hour. The appropriate metric must match the operational mode of the safety function, because applying a numerical SIL target without considering demand characteristics can lead to an incorrect safety argument.

For ISO 26262, ASIL determination begins with Hazard Analysis and Risk Assessment (HARA). Hazardous events are created by considering a hazard in combination with an operational situation, and each hazardous event is evaluated using Severity, Exposure, and Controllability. These three dimensions establish the risk classification that leads to QM or ASIL A, B, C, or D, where ASIL D represents the most demanding automotive safety integrity classification.

Severity describes the potential degree of harm associated with a hazardous event rather than the probability that the failure itself will occur. Exposure represents how frequently or for how long the relevant operational situation is expected to occur. Controllability evaluates the ability of affected persons to avoid or limit the harm once the hazardous situation develops. The combination must be evaluated consistently using the definitions and classification scheme established by ISO 26262.

An event that does not require an ASIL safety classification may be managed under Quality Management (QM), while increasing combinations of Severity, Exposure, and Controllability can result in ASIL A through ASIL D. The resulting ASIL is assigned to the corresponding safety goal and subsequently propagated through functional and technical safety requirements. ASIL therefore establishes the development rigor and safety assurance expectations associated with controlling the identified automotive hazard.

SIL and ASIL should not be converted directly through a simple equivalence table. SIL 3, for example, cannot automatically be declared equivalent to ASIL D because the standards use different risk models, metrics, lifecycle concepts, architectural requirements, and application assumptions. When technologies from automotive, industrial, and robotic domains are integrated, engineers should preserve the original classification logic of each applicable standard and establish explicit interfaces between the resulting safety requirements.

The decision process must also distinguish hazard classification from hardware assessment. SIL or ASIL determination establishes the required safety integrity or development rigor, while analyses such as FMEA, FTA, and FMEDA evaluate whether the proposed architecture can satisfy those requirements. FMEA identifies failure modes and effects, FTA examines combinations leading to hazardous top events, and FMEDA quantifies hardware failure behavior and diagnostic coverage. These analyses provide evidence rather than replacing the classification process.

Once an integrity target is established, the architecture is assessed against that target. Safety mechanisms may include redundant sensing, independent monitoring, watchdogs, communication diagnostics, emergency-stop circuits, safe torque control, braking supervision, power monitoring, and fail-safe outputs. The required effectiveness depends on the safety target, fault model, system architecture, and applicable standard. Higher integrity requirements generally demand stronger independence, diagnostic capability, verification, and fault tolerance.

Random hardware failures and systematic failures require different forms of control. Random failures are associated with physical hardware degradation and can often be analyzed using failure rates, diagnostic coverage, architectural metrics, and probabilistic methods. Systematic failures originate from specification, design, implementation, integration, configuration, or lifecycle weaknesses and cannot be addressed simply by adding numerical failure rates. Process rigor and verification therefore remain essential at higher integrity levels.

Diagnostic coverage must also be considered together with fault reaction time. Detecting a dangerous fault is useful only when the system can respond before the fault develops into an unacceptable hazardous condition. The available Fault Tolerant Time Interval should therefore be compared with sensing latency, diagnostic execution time, communication delay, controller response, actuator dynamics, and stopping behavior. This timing relationship is particularly important for mobile robots and other moving physical systems.

For an AMR, the classification process may begin with hazardous events involving collision, crushing, unintended acceleration, failure to stop, unexpected restart, or loss of steering control. Safety functions can then be defined for obstacle detection, speed limitation, protective stopping, emergency stopping, braking, and motion inhibition. Where industrial machinery or driverless industrial truck requirements apply, the resulting safety concept must also remain consistent with the relevant machinery and AMR safety standards.

A robotic platform may contain subsystems originating from different regulatory traditions. An industrial safety controller may be developed according to IEC 61508 principles, automotive-derived electronics may provide ISO 26262 safety evidence, and machine safety functions may be expressed through Performance Level concepts. These classifications should not be casually merged. The system integrator must instead determine applicable requirements and demonstrate how subsystem safety evidence supports the complete robot-level safety function.

The decision procedure should therefore maintain traceability from hazard to classification and from classification to implementation. Each hazardous event should connect to its risk evaluation, safety goal or safety function, assigned SIL or ASIL where applicable, derived safety requirements, architecture, safety mechanisms, verification activities, and residual-risk argument. This chain prevents integrity classifications from becoming isolated labels without engineering consequences.

Changes in system operation can require reassessment. Increased vehicle speed, payload, operating area, human interaction, autonomy, actuator capability, or environmental complexity may alter the severity, exposure, controllability, or required risk reduction. Similarly, architectural changes may introduce new dependencies or reduce diagnostic effectiveness. SIL and ASIL decisions should therefore be maintained throughout the safety lifecycle rather than considered permanent results of an initial assessment.

Verification must demonstrate that the implemented design satisfies requirements derived from the assigned integrity level. Evidence can include requirements reviews, architectural analysis, FMEA, FTA, FMEDA, hardware testing, software verification, fault injection, integration testing, timing validation, and safety-function testing. The required depth and independence of these activities depend on the applicable standard, integrity target, development process, and specific safety argument.

For Physical AI systems, intelligent perception and planning may contribute to operational capability while deterministic safety mechanisms provide independent protection against unacceptable motion. The integrity decision should clearly define which functions participate in the safety path and which remain performance-oriented functions. This separation helps prevent uncertain AI behavior from being implicitly credited with safety integrity unless appropriate requirements, evidence, and validation justify such credit.

A mature SIL/ASIL decision procedure is therefore not a single lookup table but a traceable engineering process connecting hazards, risk evaluation, integrity targets, safety requirements, architecture, failure analysis, diagnostics, verification, and safety evidence. Applied correctly, it establishes how much safety assurance is required and provides the foundation for demonstrating that the implemented system achieves the intended level of risk reduction throughout its operational lifecycle.

05.05. Safety Case Documentation

Safety case documentation is the structured body of arguments and evidence used to demonstrate that a system is acceptably safe for a defined application, environment, and operating context. Rather than being a single test report or certification document, a safety case connects identified hazards, safety objectives, engineering requirements, implemented safety mechanisms, analyses, verification results, and residual-risk decisions into a coherent justification of system safety.

The safety case begins with a precise definition of the system and its intended use. The documentation should establish system boundaries, functions, interfaces, operating modes, users, environmental conditions, foreseeable misuse, maintenance assumptions, and external dependencies. For robotic systems, this context may include navigation areas, human interaction, payload, maximum speed, sensing conditions, charging, docking, communication infrastructure, and emergency operating scenarios.

A clear system description provides the reference configuration against which every safety claim is made. Hardware architecture, software architecture, power distribution, communication networks, sensors, actuators, safety controllers, and mechanical interfaces should be represented consistently with the actual product configuration. Configuration identifiers and version information are important because safety evidence generated for one architecture cannot automatically justify a substantially modified system.

Hazard analysis forms one of the primary foundations of the safety case. Identified hazards and hazardous events should be documented together with their causes, operational situations, potential consequences, and risk evaluations. Depending on the applicable framework, the analysis may support SIL, ASIL, Performance Level, or other safety classifications. The resulting risk decisions establish why particular safety functions and engineering controls are necessary.

Safety goals and safety requirements translate identified hazards into explicit engineering obligations. High-level goals describe the safety outcomes that must be maintained, while functional and technical requirements define how those outcomes are achieved by the architecture. Requirements should specify conditions, responses, timing constraints, safe states, diagnostic expectations, fault reactions, and interfaces sufficiently clearly that implementation and verification can be objectively demonstrated.

Traceability provides the logical backbone of safety case documentation. A reviewer should be able to move from a hazard to its risk assessment, from the assessment to a safety goal, from the goal to derived requirements, and from those requirements to architecture, implementation, analysis, tests, and verification results. Bidirectional traceability also allows engineers to determine which safety claims must be reconsidered when a requirement, component, interface, or operating assumption changes.

Safety arguments explain why the collected evidence supports the claim that the system is acceptably safe. A claim may state that unintended hazardous motion is adequately controlled, while supporting arguments describe independent obstacle detection, speed supervision, braking capability, emergency stopping, fault detection, and safe-state transitions. Evidence then demonstrates that these mechanisms have been correctly designed, implemented, integrated, and verified.

Failure analysis provides important evidence within this argument structure. FMEA can demonstrate systematic identification of component and functional failure modes, while FTA can show how combinations of faults may lead to hazardous top events. FMEDA adds quantitative hardware failure rates, diagnostic coverage, and architectural metrics. Together, these methods connect potential physical and functional failures with the safety mechanisms intended to prevent or control their consequences.

Safety architecture documentation should identify which mechanisms provide prevention, detection, tolerance, mitigation, or transition to a safe state. Examples include redundant sensing, independent monitoring, watchdogs, communication diagnostics, power supervision, safety relays, emergency-stop circuits, braking supervision, and safe torque functions. Dependencies and common resources must also be documented because apparent redundancy may provide insufficient protection when channels share critical infrastructure.

Verification evidence demonstrates that safety requirements have been implemented correctly. Evidence may include requirements reviews, design reviews, static analysis, circuit analysis, software verification, unit testing, integration testing, hardware testing, communication testing, and safety-function testing. Each verification activity should identify the requirement being verified, the method used, acceptance criteria, test configuration, results, anomalies, and final disposition.

Validation provides a complementary system-level perspective by determining whether the integrated product achieves the intended safety behavior in representative operating conditions. For an AMR, validation may include obstacle encounters, human approach scenarios, speed transitions, braking tests, emergency stops, sensor degradation, communication interruption, localization failures, power faults, and recovery behavior. The selected scenarios should reflect the operational context defined by the safety analysis.

Fault-injection testing can provide particularly valuable evidence where safety arguments depend on diagnostics and fault reactions. Hardware faults, sensor errors, communication loss, corrupted data, power abnormalities, or controller failures can be introduced under controlled conditions to verify that detection and reaction occur as expected. The measured detection and response times can also confirm whether the implemented mechanism satisfies the available Fault Tolerant Time Interval.

Timing evidence is essential for safety functions whose effectiveness depends on rapid reaction. The safety case should connect sensing latency, diagnostic execution, network transmission, controller processing, actuator response, and physical stopping behavior. Demonstrating only that a fault is eventually detected is insufficient when hazardous motion can develop earlier. The complete fault-to-safe-state timing chain should therefore be justified against the relevant safety requirement.

Quantitative hardware evidence may be incorporated where required by the applicable integrity framework. FMEDA results, component failure-rate assumptions, diagnostic coverage, single-point or latent-fault metrics, dangerous failure rates, and related calculations can support hardware safety claims. The documentation should preserve assumptions, data sources, calculation methods, environmental conditions, and architectural dependencies so that quantitative results can be independently reviewed.

Compliance evidence connects the safety case with applicable standards and regulatory requirements. A robotics platform may need to consider functional safety, machinery safety, industrial vehicle safety, electrical safety, communication safety, or application-specific requirements. Rather than merely listing standards, the documentation should identify applicable clauses or requirements, describe how they are addressed, and reference the engineering evidence demonstrating conformity.

Deviations, assumptions, limitations, and unresolved issues should be explicitly documented. Safety documentation becomes unreliable when uncertainties are hidden behind apparently complete compliance statements. Known limitations may include environmental restrictions, sensor performance boundaries, prohibited operating conditions, required maintenance intervals, dependencies on external infrastructure, or temporary safety measures. These conditions should be incorporated into operating instructions and residual-risk decisions.

Residual risk is evaluated after implemented safety measures have been considered. The safety case should explain which hazards have been eliminated, which have been reduced through engineering controls, and which risks remain under specified operating assumptions. Acceptance of residual risk should be based on defined criteria and authorized decision processes rather than informal judgment, and necessary operational restrictions or warnings should remain traceable to the corresponding hazards.

Configuration and change management are essential because safety evidence applies to a particular system baseline. Changes to hardware components, software versions, diagnostic algorithms, communication architecture, sensors, actuators, operating speed, payload, or environmental assumptions can invalidate previous evidence. The safety case should therefore identify affected analyses and verification activities whenever a safety-relevant change is introduced and record the resulting reassessment.

Supplier evidence must also be controlled when safety-related subsystems originate from external manufacturers. Safety manuals, certificates, failure-rate information, diagnostic assumptions, interface requirements, environmental limits, and usage restrictions should be reviewed against the actual integration. A certified component does not automatically make the complete robot safe; the system integrator must demonstrate that the component is used within its documented assumptions and safety constraints.

For Physical AI systems, the safety case should clearly distinguish performance-oriented intelligence from functions credited with safety integrity. AI perception, world models, planning, or learned policies may improve operational capability, while independent deterministic mechanisms can provide protective stopping, speed limitation, emergency stopping, or motion inhibition. Any AI function receiving explicit safety credit requires corresponding requirements, evidence, validation, and clearly defined operating assumptions.

The completed documentation should provide a reviewable chain from system definition through hazard identification, risk classification, requirements, architecture, failure analysis, implementation, verification, validation, and residual-risk acceptance. Supporting artifacts may evolve throughout development, but their relationships must remain controlled. This allows internal reviewers, independent assessors, customers, and certification organizations to understand not only what safety measures exist, but why the evidence supports their effectiveness.

A mature safety case is therefore a living engineering justification rather than a document assembled only at the end of development. As operating conditions, architecture, software, hardware, field experience, or safety requirements change, claims and supporting evidence must be reassessed. Integrated with FMEA, FTA, FMEDA, SIL or ASIL decisions, verification, validation, and configuration control, safety case documentation provides the final structured argument that the robotic system achieves and maintains acceptable safety throughout its lifecycle.

---

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go