STATERA Library · Series 07 · Volume 12 · Chapter 02 · EN
Source: https://github.com/Statera-Library/07_Vol_12_Safety_Architecture/blob/main/Chapter_02_IEC_61508/Chapter_02_IEC_61508_EN.md

Volume 12. Safety Architecture

Chapter 02. IEC 61508

02.01. SIL 1 to 4 Determination

Safety Integrity Level (SIL) expresses the required integrity of a safety function within the IEC 61508 framework. SIL is assigned to the safety function rather than simply to a product or component, and it represents the degree of risk reduction that the function must reliably provide. Four discrete levels are defined, SIL 1 through SIL 4, with SIL 4 representing the highest required safety integrity.

SIL determination begins with a clear definition of the hazardous event and the safety function intended to prevent or mitigate it. Engineers identify the initiating failure, possible operating conditions, exposed persons or assets, and potential consequences. The analysis must establish what unacceptable risk would remain without the safety function before determining how much risk reduction is required from the protective system.

The fundamental concept is the comparison between existing or estimated risk and tolerable risk. If the unprotected risk exceeds the acceptable level, additional risk reduction must be achieved through independent protection measures and safety-related systems. The required risk reduction factor can then be translated into an integrity requirement. Higher required risk reduction generally leads to a higher SIL assignment for the corresponding safety function.

IEC 61508 distinguishes between safety functions operating in low-demand mode and those operating in high-demand or continuous mode. For low-demand functions, integrity is characterized primarily by the average probability of failure on demand, commonly written as PFDavg. For high-demand or continuous operation, the relevant measure is the probability of dangerous failure per hour, commonly represented as PFH.

For low-demand operation, SIL 1 corresponds to PFDavg from 10^-2 to less than 10^-1, SIL 2 from 10^-3 to less than 10^-2, SIL 3 from 10^-4 to less than 10^-3, and SIL 4 from 10^-5 to less than 10^-4. These ranges indicate increasingly stringent reliability expectations and approximately correspond to risk reduction factors spanning from tens to tens of thousands.

For high-demand or continuous operation, SIL 1 corresponds to a dangerous failure frequency from 10^-6 to less than 10^-5 per hour, SIL 2 from 10^-7 to less than 10^-6, SIL 3 from 10^-8 to less than 10^-7, and SIL 4 from 10^-9 to less than 10^-8 per hour. The operating mode must therefore be established before numerical integrity targets are interpreted or allocated.

A practical SIL determination may use quantitative risk assessment, a risk graph, a risk matrix, layers of protection analysis, or another documented method appropriate to the application. A risk graph commonly considers consequence severity, frequency or duration of exposure, possibility of avoiding the hazardous event, and probability of the unwanted occurrence. Their combined evaluation establishes the required safety integrity.

SIL should not be interpreted as a direct measurement of how dangerous a machine is. A severe hazard does not automatically produce SIL 4, because the required integrity also depends on exposure, likelihood, avoidance possibilities, and other independent protective measures. SIL instead defines the reliability required from a particular safety function after the overall risk and available risk reduction measures have been systematically evaluated.

Consider an autonomous mobile robot operating near personnel. A hazardous uncontrolled motion could result from failures in sensing, motion control, communication, braking, or power electronics. A safety function may therefore be defined to detect a person entering a protected region and command a safe stop. SIL determination evaluates the risk associated with failure of this function rather than assigning a SIL to the complete AMR without functional decomposition.

The safety function must have precisely defined inputs, logic, outputs, timing requirements, and safe state. For an AMR protective-stop function, inputs may include safety LiDAR or other certified protective sensors, logic may reside in a safety controller, and outputs may remove drive torque or activate braking. Response time, stopping distance, diagnostic behavior, reset conditions, and fault reactions become part of the safety requirements.

Once a SIL target has been established, achieving it requires more than selecting components with sufficiently low failure rates. IEC 61508 addresses both random hardware failures and systematic failures, which are treated separately in the safety lifecycle. Hardware architecture, diagnostic coverage, redundancy, proof testing, common-cause failures, software development practices, configuration management, verification, and validation collectively influence whether the required SIL can be demonstrated.

The allocated SIL therefore propagates into architectural and engineering decisions. Higher SIL requirements normally demand stronger fault detection, greater independence, more rigorous diagnostics, controlled development processes, and stronger verification evidence. Redundant channels alone do not guarantee a particular SIL because correlated failures, insufficient diagnostics, incorrect requirements, software defects, and integration errors can defeat apparently redundant architectures.

SIL allocation should also consider independence between protection layers. If multiple measures are credited for reducing the same hazardous risk, their independence and failure dependencies must be justified. A normal motion controller and a safety controller cannot automatically be treated as independent merely because they execute different software. Shared power supplies, sensors, communication paths, processors, environmental stresses, or common requirements can create common failure mechanisms.

Proof-test intervals, mission time, repair assumptions, component failure rates, diagnostic test intervals, and detected versus undetected dangerous failures affect quantitative integrity calculations. Consequently, the same hardware architecture can produce different PFDavg or PFH results under different maintenance and operating assumptions. SIL verification must therefore use assumptions that realistically represent the deployed machine and its intended maintenance strategy.

For robotics, SIL determination should be connected to the broader safety architecture rather than performed as an isolated numerical exercise. IEC 61508 provides the functional-safety foundation, while application-specific machinery and robotic standards may define additional requirements for protective fields, stopping behavior, human interaction, operating modes, validation, and safeguarding. The attached architecture accordingly places IEC 61508 alongside ISO 3691-4 and ISO 13849 topics.

An AMR may consequently contain several safety functions with different integrity requirements. Emergency stopping, protective stopping, safe speed limitation, prevention of unintended motion, brake monitoring, steering supervision, or safe power isolation need not receive identical SIL targets. Each function should be derived from its associated hazardous event, required risk reduction, operating mode, and contribution from other independent safeguards.

SIL 4 deserves particular caution in practical system design. It represents an exceptionally demanding integrity requirement and should not be selected simply to make a system appear safer. Excessively conservative SIL allocation can introduce unnecessary architectural complexity, verification effort, development cost, and certification burden. Conversely, selecting a lower SIL without adequate risk justification can leave insufficient protection against hazardous failures.

The final SIL determination must remain traceable from hazard identification through risk estimation, tolerable-risk criteria, required risk reduction, safety-function definition, and integrity allocation. Assumptions and credited safeguards should be documented so that later design changes can trigger reassessment. This traceability becomes especially important when sensors, controllers, drive systems, operating environments, payloads, speeds, or human interaction conditions change.

In a complete safety lifecycle, SIL determination is therefore an engineering bridge between hazard analysis and implementation. It converts an abstract statement that a hazard must be controlled into measurable integrity requirements for specific safety functions. Those requirements subsequently guide hardware architecture, software rigor, diagnostics, testing, validation, maintenance planning, and the evidence needed to demonstrate that residual risk remains tolerable.

02.02. Systematic vs Random Failure

Systematic failures and random hardware failures represent two fundamentally different failure mechanisms within the IEC 61508 functional safety framework. Distinguishing them is essential because they arise from different causes and therefore require different prevention, detection, and mitigation strategies. The safety architecture places this distinction directly after SIL determination because both failure classes influence whether a safety function can achieve its required integrity.

A random hardware failure results from physical degradation or an unpredictable physical event affecting an electronic, electrical, or electromechanical component. Semiconductor wear, resistor or capacitor degradation, connector deterioration, memory-cell faults, relay contact failures, sensor electronics faults, and power-device breakdown are typical examples. Their occurrence cannot normally be predicted at an exact time for an individual component.

Although the occurrence of a specific random failure is unpredictable, the behavior of a sufficiently large population of components can often be characterized statistically. Failure rates expressed in failures per hour, FIT values, reliability distributions, and field-return data can therefore support quantitative safety analysis. This statistical property allows random hardware failures to be incorporated into calculations such as PFDavg and PFH used for SIL verification.

Random hardware failures are further classified according to their effect on the safety function. A failure may be safe when it does not prevent the system from reaching or maintaining a safe state, or dangerous when it can prevent the required safety action. Dangerous failures may also be divided into detected and undetected failures depending on whether diagnostic mechanisms identify the fault before it contributes to an unsafe condition.

Diagnostic coverage is consequently a major architectural mechanism for controlling random hardware failures. Watchdogs, voltage monitoring, sensor plausibility checks, communication supervision, memory tests, redundant comparisons, output feedback, and periodic self-tests can convert otherwise undetected dangerous failures into detected failures. Once detected, the system can transition to a defined safe state before the fault develops into a hazardous event.

Redundancy can further reduce the probability that a single random hardware failure causes loss of the safety function. Dual sensors, redundant processing channels, independent shutdown paths, or monitored output stages can maintain protection when one element fails. However, redundancy must be analyzed together with diagnostic coverage, independence, common-cause failure, and architectural constraints rather than being treated as an automatic guarantee of safety integrity.

Systematic failures have a fundamentally different origin. They are related to deterministic causes introduced during specification, design, implementation, manufacturing, installation, operation, maintenance, or modification. Examples include an incorrect safety requirement, a software logic defect, an unsuitable component specification, a wiring design error, an incorrect calibration parameter, or a maintenance procedure that consistently restores a system to an unsafe configuration.

Unlike random hardware failures, systematic failures generally cannot be represented meaningfully by a simple constant failure rate. If a specific combination of inputs or environmental conditions activates a design defect, the same defect may repeatedly produce the same incorrect behavior. The engineering objective is therefore not primarily to calculate its probability, but to prevent the defect and increase confidence that systematic faults have been eliminated or adequately controlled.

Systematic capability is achieved through disciplined safety lifecycle activities. Clear requirements, traceability, design reviews, coding rules, configuration management, verification, validation, independence of assessment, controlled tools, change management, and documented competence contribute to systematic failure control. As the required SIL increases, the rigor and independence expected from these development and assurance activities generally increase accordingly.

Software is particularly important because most software failures are systematic rather than random. A safety controller may execute millions of cycles without error and then consistently produce an incorrect output when a rare combination of states activates a latent software defect. Increasing processor redundancy alone may not solve this problem if identical software containing the same defect is executed on both processing channels.

The same principle applies to requirements errors. If an AMR safety specification defines an incorrect stopping-distance requirement, every correctly implemented controller may reproduce the same unsafe behavior. Hardware reliability cannot compensate for an incorrect requirement. Hazard analysis, requirement validation, traceability, independent review, simulation, scenario testing, and system-level validation are therefore essential defenses against systematic faults originating early in development.

Common-cause failure creates an important connection between random and systematic safety analysis. Two redundant channels may appear independent but can fail simultaneously because of a shared power supply, excessive temperature, electromagnetic interference, common communication infrastructure, identical design weakness, or environmental stress. Safety analysis must therefore investigate dependencies rather than simply multiplying independent component failure probabilities.

Common-mode systematic defects are especially significant in redundant architectures using identical hardware and software. Two processors running the same erroneous algorithm can generate identical incorrect outputs, making comparison-based diagnostics ineffective. Diversity may therefore be considered where appropriate, using different sensing principles, independently developed monitoring logic, dissimilar hardware, or separate shutdown mechanisms to reduce vulnerability to shared systematic defects.

For an autonomous mobile robot, random hardware failure might involve a safety LiDAR receiver circuit failing, a safety-controller input channel becoming defective, or a brake feedback sensor experiencing an electrical fault. Diagnostics can detect many such conditions and command a safe stop. Quantitative failure-rate information can then contribute to evaluating whether the protective-stop function satisfies its allocated hardware safety integrity requirement.

A systematic AMR failure could instead originate from incorrectly configured protection zones, an error in stopping-distance calculation, reversed safety I/O logic, incorrect speed-dependent field switching, or software that handles a sensor timeout improperly. Such defects may remain dormant during normal testing yet appear repeatedly under specific operating conditions. Their control depends strongly on engineering process quality and scenario-based validation.

The distinction also influences maintenance. Random hardware failure risk can often be controlled through proof testing, preventive replacement, diagnostic intervals, component derating, environmental protection, and repair-time management. Systematic failures require different actions, including root-cause analysis, requirements correction, software modification, configuration control, process improvement, regression testing, and verification that the corrective action has not introduced additional faults.

Failure Mode and Effects Analysis (FMEA), Fault Tree Analysis (FTA), and Failure Modes, Effects and Diagnostic Analysis (FMEDA) can support understanding of hardware failure behavior, diagnostic effectiveness, and architectural vulnerability. These analyses complement rather than replace systematic safety activities. A system may demonstrate excellent numerical hardware reliability while still containing a requirements, software, configuration, or integration defect capable of defeating its safety function.

Functional safety therefore requires two complementary forms of confidence. Quantitative evidence demonstrates that random dangerous hardware failures are sufficiently improbable, while systematic capability provides confidence that avoidable design and development defects have been prevented or detected through appropriate lifecycle processes. Neither dimension alone is sufficient for demonstrating that a safety-related system achieves the intended safety integrity.

For robotic systems, this distinction becomes increasingly important as safety functions combine sensors, programmable electronics, communication networks, motion controllers, software, and AI-enabled subsystems. Hardware failure metrics address only part of this architecture. The safety concept must additionally establish deterministic safety boundaries, independent monitoring, validated fallback behavior, controlled configuration, and conventional safety mechanisms where complex intelligent functions cannot provide sufficient safety assurance.

A robust IEC 61508 safety architecture consequently treats random hardware failure and systematic failure as parallel engineering concerns throughout the lifecycle. Random failures are primarily managed through reliability analysis, diagnostics, fault tolerance, testing, and architectural measures, while systematic failures are primarily controlled through disciplined development and verification. Their combined treatment provides the foundation for maintaining the required SIL throughout design, operation, maintenance, and modification.

02.03. Safety Lifecycle (IEC61508)

IEC 61508 defines a structured functional safety lifecycle that manages safety from the earliest concept activities through design, implementation, operation, maintenance, modification, and eventual decommissioning. The lifecycle prevents functional safety from becoming a final-stage verification exercise by requiring hazards, safety requirements, implementation decisions, and evidence to remain connected throughout the system lifetime.

The lifecycle begins by establishing the system context and defining the equipment under control, its intended functions, operating environment, interfaces, boundaries, and foreseeable operating conditions. These definitions determine what must be included in subsequent hazard analysis. Incorrect or incomplete boundaries can cause important hazards or dependencies to remain outside the safety assessment and undermine later safety decisions.

Hazard and risk analysis then identifies hazardous events and evaluates the risks associated with them. Engineers examine initiating events, operating states, human exposure, environmental conditions, failure consequences, and existing protection measures. The objective is to establish which risks require additional reduction and to provide a defensible basis for defining the safety functions necessary to achieve tolerable residual risk.

Once the required risk reduction is understood, overall safety requirements are specified. Each safety function must describe the condition to be detected, the required response, the intended safe state, timing constraints, operating modes, reset behavior, fault responses, and relevant interfaces. Safety Integrity Level requirements are then allocated where appropriate so that each function has both functional and integrity requirements.

Safety requirements are subsequently allocated to appropriate protection layers and safety-related systems. Risk reduction may involve electrical, electronic, programmable electronic, mechanical, or other independent measures. Allocation must consider independence and dependencies between layers because multiple protective functions cannot automatically be credited as independent when they share sensors, power, communications, processing resources, or common design assumptions.

The electrical, electronic, and programmable electronic safety-related system then enters its realization lifecycle. System architecture is developed from the allocated safety requirements, including sensors, logic solvers, communication paths, output devices, shutdown mechanisms, diagnostics, and power architecture. The design must support both the required safety behavior and the safety integrity associated with each allocated safety function.

Hardware realization addresses random hardware failure as well as architectural constraints. Component failure rates, dangerous and safe failure modes, diagnostic coverage, redundancy, common-cause failures, proof-test intervals, and fault-tolerance characteristics contribute to hardware safety integrity evaluation. Quantitative calculations such as PFDavg or PFH are used according to the operating mode to demonstrate that dangerous hardware failure targets are satisfied.

Software realization follows a corresponding safety lifecycle rather than being treated as ordinary application programming. Safety software requirements are derived from system requirements and transformed into software architecture, detailed design, implementation, integration, and testing. Coding standards, defensive programming, traceability, configuration management, verification, tool control, and independence become increasingly important as the required SIL increases.

Verification is performed throughout the lifecycle rather than only after implementation. Requirements are checked against higher-level safety objectives, architecture against requirements, detailed design against architecture, and implementation against detailed design. Reviews, analyses, inspections, simulations, tests, and traceability records provide evidence that each lifecycle output correctly satisfies the requirements established by the preceding activities.

Functional safety validation has a different purpose from verification. Verification asks whether a lifecycle output was produced correctly according to its specified inputs, whereas validation determines whether the completed safety-related system actually fulfills the intended safety requirements in its real application context. Validation therefore evaluates integrated behavior, operating modes, fault reactions, timing, interfaces, and transitions to safe states.

Functional safety assessment provides an additional level of confidence by evaluating whether the overall lifecycle activities and resulting evidence adequately demonstrate functional safety. Appropriate independence is important because the assessment should not simply repeat the conclusions of the designers responsible for implementation. The required degree of independence and rigor depends on factors including the safety integrity requirements and project organization.

Operation and maintenance are integral parts of the safety lifecycle. A system that satisfies its SIL targets at commissioning can lose safety integrity if diagnostics are disabled, proof tests are missed, replacement components are unsuitable, configurations are changed without control, or faults remain unrepaired. Operating procedures must therefore preserve the assumptions used during safety analysis and maintain the effectiveness of safety functions.

Proof testing is particularly important for failures that automatic diagnostics cannot detect during normal operation. Periodic tests reveal latent dangerous failures and restore the safety function to an appropriate condition through repair or replacement. Proof-test coverage and interval influence quantitative safety integrity, especially for low-demand functions, so maintenance schedules should remain consistent with the assumptions used in PFDavg calculations.

Modification requires controlled re-entry into the safety lifecycle. Changes to hardware, software, parameters, sensors, communication networks, operating speed, payload, environment, or maintenance procedures may invalidate earlier hazard analyses or integrity calculations. Change impact analysis determines which requirements, hazards, verification results, validation activities, and safety evidence must be updated before the modified system is returned to service.

Configuration management supports this lifecycle by ensuring that the safety evidence corresponds to the actual deployed system. Hardware versions, software releases, safety parameters, calibration values, diagnostic settings, test procedures, and documentation must remain identifiable and controlled. Without configuration integrity, successful verification of one version cannot reliably demonstrate the safety of another version operating in the field.

Competence and functional safety management span the lifecycle rather than belonging to a single technical phase. Responsibilities, authorization, planning, documentation, reviews, independence, and personnel competence must be defined so that safety activities are executed consistently. This organizational discipline is particularly important for systematic failure control because many such failures originate from requirements, communication, process, or configuration weaknesses.

For an autonomous mobile robot, the lifecycle may begin with hazards such as collision, crushing, unintended motion, excessive speed, or failure to stop. These hazards lead to safety functions such as protective stopping, emergency stopping, safe speed limitation, brake supervision, or safe drive torque removal. Requirements are then allocated to safety LiDARs, safety controllers, drive interfaces, braking systems, and other protective mechanisms.

The AMR implementation must subsequently demonstrate that sensing, safety logic, communication, and actuation collectively satisfy the required response. Stopping time and distance, sensor coverage, diagnostic behavior, communication failures, drive faults, brake response, reset conditions, and degraded operating modes must be verified and validated. Field operation must then preserve these characteristics through controlled maintenance and configuration.

The lifecycle also creates a continuous chain of traceability from hazard to safety evidence. A hazardous event should be traceable to the associated risk assessment, safety goal or requirement, safety function, SIL allocation, architecture, implementation, verification test, validation result, and operational constraint. When a requirement or design element changes, this chain helps engineers identify the safety evidence that must be reconsidered.

IEC 61508 therefore treats functional safety as a managed lifecycle property rather than a characteristic obtained simply by purchasing certified components. Certified devices can support a safety architecture, but system-level integrity depends on correct requirements, allocation, integration, diagnostics, verification, validation, operation, and maintenance. A collection of individually capable safety components does not automatically create a compliant safety function.

For robotics and AMR engineering, the lifecycle provides the organizational framework connecting SIL determination, systematic and random failure control, hardware integrity, and application-specific safety requirements. Within the attached safety architecture, this IEC 61508 foundation logically supports later treatment of hardware safety integrity and IEC 61508 application to AMRs, followed by robot-specific standards and assessment methods.

The final purpose of the IEC 61508 safety lifecycle is to preserve acceptable risk throughout the complete existence of the system. Hazard analysis establishes why protection is necessary, safety requirements define what protection must accomplish, SIL specifies required integrity, realization creates the protective system, verification and validation build evidence, and operation, maintenance, modification, and decommissioning ensure that safety remains controlled over time.

02.04. Hardware Safety Integrity

Hardware safety integrity describes the ability of the hardware portion of a safety-related system to perform its required safety function despite random hardware failures. Within IEC 61508, it complements systematic capability by providing quantitative and architectural evidence that dangerous hardware faults occur with sufficiently low probability for the required Safety Integrity Level (SIL).

The assessment begins with a precisely defined safety function and its allocated SIL. Engineers identify the hardware elements participating in the function, including sensors, input circuits, logic solvers, communication interfaces, power supplies, output stages, actuators, and shutdown devices. The analysis boundary must include components whose failures can prevent the system from achieving or maintaining the defined safe state.

Every relevant hardware element is analyzed for possible failure modes and their effects on the safety function. Failures are commonly classified according to whether they are safe or dangerous and whether dangerous failures are detected or undetected. This classification establishes how individual component failures contribute to the overall probability that the safety function becomes unavailable when protection is required.

Failure-rate data provide the quantitative foundation for random hardware failure analysis. Component reliability information may be obtained from recognized reliability databases, manufacturer information, field experience, or justified engineering estimates. Failure rates are typically expressed as failures per hour or FIT, where one FIT represents one failure per billion operating hours, and are allocated among the relevant failure categories.

Failure Modes, Effects and Diagnostic Analysis (FMEDA) extends conventional failure analysis by evaluating both the effect of each hardware failure and the ability of diagnostics to detect it. FMEDA can identify safe failures, dangerous detected failures, dangerous undetected failures, and the diagnostic mechanisms associated with them. Its results provide important inputs for hardware architectural metrics and quantitative SIL calculations.

Diagnostic coverage indicates how effectively diagnostic mechanisms detect dangerous hardware failures. Watchdogs, memory tests, voltage supervision, sensor plausibility checks, redundant comparisons, communication monitoring, output feedback, brake monitoring, and periodic self-tests can improve detection. High diagnostic coverage reduces the proportion of dangerous failures that remain latent and therefore reduces the probability of losing the safety function without warning.

IEC 61508 hardware integrity is not determined by failure probability alone. The architecture must also provide appropriate fault tolerance according to the required integrity and characteristics of the subsystem. A single-channel architecture may be adequate for some lower-integrity applications, while higher integrity can require redundancy, diagnostics, independent shutdown paths, or architectures capable of maintaining or restoring safety after specified hardware faults.

Hardware Fault Tolerance (HFT) expresses the number of faults that can occur before the safety function is lost. An HFT of zero means that one relevant fault may cause loss of the function, while an HFT of one means that the architecture can tolerate one such fault before the safety function is lost. Increasing HFT can strengthen integrity, but only when redundant channels have adequate independence and diagnostic effectiveness.

Safe Failure Fraction (SFF) characterizes the proportion of failures that either lead to a safe condition or are dangerous but detected by appropriate diagnostics, relative to the relevant total failure population under the applicable IEC 61508 definitions. Higher SFF generally indicates that fewer failures remain dangerously undetected. SFF and HFT are used with architectural constraints when determining whether a subsystem can support a particular SIL.

IEC 61508 also distinguishes subsystem behavior through concepts such as Type A and Type B elements when applying architectural constraints. Type A elements have well-understood failure modes and sufficiently established behavior, whereas Type B elements involve greater complexity or less completely characterized failure behavior. Programmable and complex electronic devices frequently require more conservative architectural treatment than simple, well-understood components.

Quantitative hardware integrity is evaluated differently according to the demand mode of the safety function. Low-demand functions are commonly evaluated using the average probability of dangerous failure on demand, PFDavg. High-demand or continuous functions are evaluated using the dangerous failure frequency per hour, PFH. The calculation model must therefore reflect how the safety function is actually demanded during system operation.

PFDavg depends on factors including dangerous undetected failure rates, diagnostic effectiveness, proof-test interval, proof-test coverage, repair time, architecture, and common-cause assumptions. A latent dangerous fault can remain hidden until a periodic proof test discovers it, so extending the proof-test interval can significantly increase average unavailability. Maintenance assumptions are therefore integral to the claimed hardware safety integrity.

For high-demand or continuous operation, PFH represents the frequency at which dangerous hardware failure can lead to loss of the safety function. Continuous motion-control applications in robotics can make this measure particularly relevant because protection may be continuously active rather than requested only occasionally. Accurate modeling must account for architecture, diagnostics, repair behavior, dependencies, and operating conditions.

Redundancy reduces hardware risk only when failures between channels are sufficiently independent. Two identical channels supplied from the same power source, installed in the same thermal environment, or exposed to the same electromagnetic disturbance may fail together. Common-Cause Failure (CCF) analysis therefore evaluates shared mechanisms that could defeat multiple channels and invalidate assumptions of statistically independent failures.

Physical and functional separation can improve independence. Separate power paths, isolated safety communication, diverse routing, independent monitoring, protected wiring, appropriate grounding, environmental separation, and independent shutdown mechanisms can reduce common dependencies. However, independence must be demonstrated through architecture and analysis rather than assumed simply because two devices or processing channels are present.

Power architecture is an important part of hardware safety integrity because a safety function may become unavailable when its sensing, logic, or output devices lose power. Designers must determine whether power loss naturally creates a safe condition or instead creates a dangerous state. Power monitoring, energy storage, fail-safe outputs, contactors, brake mechanisms, and independent safety supplies may therefore become part of the integrity concept.

An autonomous mobile robot provides a practical example. A protective-stop function may consist of a safety LiDAR, safety controller, communication or safety I/O path, motor-drive safety input, and mechanical or electrical braking mechanism. Hardware integrity analysis considers whether failures in any of these elements could prevent detection of a person, inhibit the stop command, retain drive torque, or prevent sufficient braking.

Diagnostics for the AMR may supervise LiDAR health, safety communication, controller execution, drive enable signals, contactor feedback, brake state, supply voltage, and internal processor faults. When a dangerous fault is detected, the architecture should transition toward a defined safe condition within the required fault reaction time. Diagnostic performance must therefore be considered together with the physical stopping behavior of the robot.

Environmental conditions can substantially influence real hardware reliability. Temperature, vibration, shock, humidity, contamination, water ingress, connector degradation, electromagnetic interference, and repeated mechanical stress can alter failure rates or create dependent failures. Hardware safety integrity calculations should therefore be supported by component selection, derating, environmental qualification, EMC design, and installation practices appropriate to the actual application.

Hardware integrity must also remain valid after deployment. Proof testing, diagnostic checks, preventive maintenance, repair procedures, replacement-part control, and configuration management preserve the assumptions used during the original calculations. Replacing a certified sensor, relay, drive, power supply, or safety controller with a technically similar but differently characterized device may require reassessment of the safety function.

Quantitative calculations alone cannot establish complete functional safety. Extremely low calculated PFDavg or PFH values do not compensate for incorrect requirements, software defects, configuration errors, inadequate environmental design, or common systematic weaknesses. Hardware safety integrity must therefore operate together with systematic failure control, lifecycle management, verification, validation, and functional safety assessment.

The objective is to create a defensible chain from the allocated SIL to the actual hardware architecture and its evidence. Failure rates, FMEDA, diagnostic coverage, HFT, SFF, architectural constraints, PFDavg or PFH calculations, CCF analysis, proof testing, and validation collectively demonstrate whether random hardware failures are adequately controlled. These results then become part of the overall safety case for the safety function.

Within the attached safety architecture, hardware safety integrity follows SIL determination, systematic-versus-random failure analysis, and the IEC 61508 safety lifecycle, before the application of IEC 61508 to AMRs. This sequence reflects the engineering progression from defining required integrity, understanding failure mechanisms, and managing the lifecycle to demonstrating that the physical implementation can reliably provide the required protection.

02.05. IEC 61508 for AMR

IEC 61508 provides a generic functional safety framework that can be applied to the electrical, electronic, and programmable electronic safety-related systems used in autonomous mobile robots (AMRs). For AMR engineering, its primary value is not to define robot navigation behavior itself, but to establish a disciplined method for identifying hazards, defining safety functions, allocating integrity requirements, and demonstrating that those functions remain dependable throughout the lifecycle.

An AMR combines perception sensors, computing platforms, communication networks, motor drives, steering systems, brakes, batteries, power distribution, and software within a mobile machine. Failures across these elements can create hazardous motion even when the autonomous navigation algorithm normally performs correctly. Functional safety therefore requires an independent view of how the robot detects dangerous conditions and transitions to a defined safe state.

Application begins by defining the AMR, its intended operating environment, system boundaries, interfaces, and reasonably foreseeable operating conditions. Indoor logistics, outdoor transport, inspection, mixed pedestrian traffic, loading operations, docking, charging, maintenance, and manual control can create different hazards. The safety analysis must therefore represent actual missions rather than assuming that one generic operating condition adequately describes the robot.

Hazard analysis considers events such as collision with a person, crushing or trapping, unintended acceleration, excessive speed, loss of steering control, failure to stop, unexpected restart, brake failure, or hazardous motion following a sensor or communication fault. The severity, exposure, occurrence conditions, avoidance possibilities, and existing safeguards provide the basis for determining the additional risk reduction required from safety-related functions.

Safety functions are derived from these hazardous scenarios rather than selected merely because particular safety devices are available. Typical functions can include emergency stopping, protective stopping, safe speed limitation, prevention of unexpected movement, drive torque removal, brake supervision, steering supervision, or controlled transition following critical faults. Each function requires clearly defined triggering conditions, outputs, response time, and safe state.

The safe state of an AMR must be defined according to the hazard being controlled. Removing motor torque may be sufficient on a level indoor floor but inadequate on a slope where the robot could continue moving under gravity. A complete safety function may therefore require torque removal together with mechanical braking, steering stabilization, or controlled deceleration before power isolation. Safe behavior must be derived from physical system dynamics.

Safety Integrity Level requirements can then be allocated to safety functions when IEC 61508 methodology is applicable. The SIL requirement represents the integrity needed to achieve the required risk reduction rather than a general rating for the entire AMR. Consequently, different functions within one robot can have different integrity requirements depending on their hazardous events, operating modes, exposure conditions, and other independent protection measures.

An AMR protective-stop function illustrates the complete signal path. A safety LiDAR or another protective sensor detects intrusion into a hazardous region, a safety controller evaluates the condition, and a safety output commands the drive system or braking mechanism toward a safe state. Hardware and software integrity must be evaluated across this complete sensor-to-logic-to-actuator chain because failure anywhere in the chain can defeat the function.

Stopping performance connects functional safety calculations to robot physics. Detection time, communication latency, safety-controller processing, drive reaction time, brake engagement, robot velocity, payload, tire characteristics, floor friction, slope, and mechanical tolerances all influence stopping distance. Protective fields must therefore be configured using validated worst-case behavior rather than only nominal software response or theoretical braking performance.

Random hardware failures must be evaluated for safety-related AMR components. Failure-rate information, FMEDA, diagnostic coverage, hardware fault tolerance, architectural constraints, common-cause failure analysis, and PFDavg or PFH calculations can be used to demonstrate hardware safety integrity. Safety sensors, controllers, power interfaces, drive enable circuits, contactors, brakes, and feedback devices may all contribute to this quantitative evaluation.

Systematic failures require a different form of control. An incorrectly calculated protection field, wrong speed threshold, reversed safety I/O assignment, software defect, incorrect brake parameter, or configuration error can repeatedly produce unsafe behavior without any physical component failure. Requirements management, independent review, configuration control, software verification, validation, change management, and lifecycle discipline are therefore essential parts of AMR safety assurance.

Diagnostics allow the AMR to recognize faults before they develop into hazardous motion. Safety architectures may supervise sensor health, communication integrity, controller execution, motor-drive status, brake feedback, steering feedback, supply voltage, contactor state, memory integrity, and watchdog operation. Detected dangerous failures should cause an appropriate fault reaction within a specified time and prevent uncontrolled continuation of autonomous operation.

Redundancy can improve integrity where justified, but duplicated components do not automatically create independent protection. Two safety channels can share power, wiring routes, communication infrastructure, environmental exposure, software, or design assumptions. Common-cause failures must therefore be evaluated, and physical separation, independent shutdown paths, diversified sensing, protected power supplies, or other architectural measures may be needed.

Communication is particularly important because AMRs are distributed systems. Sensors, safety controllers, drives, vehicle controllers, and supervisory computers may exchange safety-relevant information across networks. Loss, delay, repetition, corruption, incorrect sequence, or stale information must not silently create unsafe motion. Safety-related communication should therefore include mechanisms appropriate to the required integrity and defined failure responses.

The autonomous navigation computer should not automatically be considered the final safety authority. High-performance perception, localization, planning, AI inference, and fleet coordination may provide sophisticated operational intelligence while a separate safety layer supervises critical physical limits. This separation allows complex autonomy to command motion while independently implemented safety mechanisms can restrict or terminate motion when defined safety conditions are violated.

Power-system behavior also affects AMR safety. Battery disconnection, low voltage, DC/DC converter failure, contactor faults, loss of control power, or emergency isolation can change the availability of sensors, controllers, drives, and brakes. Designers must determine whether each power failure produces a safe condition and whether stored energy is needed to complete controlled stopping or maintain braking before electrical isolation occurs.

Environmental conditions must be incorporated into the integrity argument. Outdoor or industrial AMRs can experience vibration, shock, dust, water, temperature variation, electromagnetic interference, connector degradation, wheel slip, uneven terrain, and changing payloads. Component qualification, derating, EMC design, enclosure protection, harness engineering, mechanical installation, and environmental validation therefore support the functional safety architecture.

Verification and validation must demonstrate both logical correctness and physical safety performance. Engineers should test normal operation, single faults, communication loss, sensor faults, drive faults, brake degradation, power disturbances, emergency stops, protection-zone transitions, restart conditions, and relevant combinations of operating modes. Validation must confirm that the integrated AMR reaches the required safe state within the specified response and stopping limits.

Operation and maintenance continue the IEC 61508 lifecycle after deployment. Proof testing, diagnostic inspection, brake maintenance, sensor alignment checks, replacement-part control, software version management, parameter protection, and repair procedures must preserve assumptions used during the safety assessment. Unauthorized changes to speed limits, safety fields, braking parameters, or safety-controller configurations can invalidate previously demonstrated integrity.

AMRs also evolve through software updates, new payloads, route changes, sensor replacements, higher operating speeds, and new environments. Each significant modification requires change impact analysis to determine whether hazards, SIL allocation, stopping performance, hardware calculations, software verification, or validation evidence must be reconsidered. Functional safety is therefore maintained as a controlled lifecycle property rather than certified once and assumed permanently valid.

IEC 61508 should also be positioned within the broader AMR safety framework. In the attached architecture, the IEC 61508 chapter is followed by ISO 3691-4 for AMR safety requirements and ISO 13849 for performance-level-oriented machinery safety functions. This structure reflects the role of IEC 61508 as a foundational functional-safety framework that can support, rather than replace, application-specific robotic and machinery safety requirements.

The resulting AMR safety architecture connects hazard analysis, safety functions, integrity allocation, sensors, safety logic, drive and braking interfaces, diagnostics, verification, validation, operation, and maintenance into one traceable system. The objective is not merely to prevent component failure, but to ensure that foreseeable failures are detected or tolerated and that the robot reliably transitions to controlled physical behavior before hazardous consequences develop.

Applying IEC 61508 to an AMR therefore means designing safety independently of successful autonomous intelligence. Navigation and AI determine how the robot should accomplish its mission, while functional safety establishes the boundaries within which that mission may be executed. By combining lifecycle discipline, hardware integrity, systematic failure control, diagnostics, fault reaction, and physical validation, the AMR can maintain acceptable risk throughout its operational lifetime.

---

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go