STATERA Library · Series 07 · Volume 22 · HRS-008 · EN
Source: https://github.com/Statera-Library/07_Vol_22_Robotics_Engineering_Standards/blob/main/HRS_008_Safety/HRS_008_Safety_EN.md

Volume 22. Hills Robotics Engineering Standards

Chapter 08. HRS-008 Safety

08.01. Safety Requirements by Product

Safety requirements shall be defined at product level because the dominant hazards, operating environment, mobility characteristics, energy sources, payloads, and human interaction differ substantially among robotic systems. The safety concept shall therefore be tailored to each product class while preserving common principles for risk reduction, fault detection, safe-state transition, emergency stopping, verification, and traceable safety evidence.

For indoor AMRs, the primary safety objective is controlled navigation in environments where personnel, carts, equipment, doors, and other robots may share the same space. The product shall provide protective sensing, speed and separation monitoring, controlled stopping, emergency stopping, and prevention of unintended motion. Safety functions shall remain effective under foreseeable sensor obstruction, localization degradation, communication loss, or controller faults.

Outdoor autonomous vehicles shall address hazards arising from higher speed, variable terrain, slopes, weather, degraded visibility, GNSS uncertainty, and interaction with vehicles or pedestrians. Safety requirements shall include independent motion inhibition, braking supervision, steering fault detection, localization integrity monitoring, obstacle detection coverage, operational boundary enforcement, and transition to a defined minimum-risk condition when autonomous operation cannot safely continue.

Inspection AMRs, including platforms carrying specialized measurement equipment, shall consider both vehicle hazards and payload-specific risks. The safety concept shall account for payload mass, center-of-gravity changes, restricted sensor fields, electrical loads, moving inspection devices, and hazardous operating areas. Loss of the inspection function shall not compromise mobility safety, and a payload malfunction shall be prevented from propagating into safety-critical motion control.

Mobile manipulators require coordinated safety treatment of the mobile base and manipulator because either subsystem can create hazardous motion independently or through combined operation. Requirements shall cover joint torque and speed limits, workspace restrictions, collision detection, safe tool behavior, base-motion interlocks, emergency stopping, and prevention of unexpected restart. Safety states shall define whether the arm, base, or both must be disabled for each detected fault.

Quadruped robots shall address instability, falls, high-energy joint motion, unexpected recovery movements, and contact with nearby personnel. Safety monitoring shall supervise actuator condition, joint position and velocity, body attitude, power integrity, communication health, and control-computer status. Detection of unrecoverable instability or critical actuator faults shall initiate a controlled protective response appropriate to the posture and environment rather than relying solely on abrupt power removal.

Humanoid robots require additional protection because numerous powered joints operate close to humans and can create crushing, pinching, impact, entanglement, or falling hazards. Product requirements shall define joint-level limits, torque monitoring, collision response, balance supervision, fall management, hand and end-effector constraints, emergency stopping, and safe power isolation. Safety-related functions shall not depend exclusively on AI perception or high-level behavioral software.

Cargo UAVs shall treat continued controlled flight, propulsion integrity, flight-control availability, navigation integrity, communication loss, energy reserve, cargo retention, and emergency landing as central safety concerns. The safety architecture shall identify failures that could cause uncontrolled flight or payload release and provide appropriate redundancy, monitoring, containment, and degraded operating modes. Cargo lock status shall be positively verified before takeoff and during relevant flight phases.

Product safety requirements shall distinguish safety-related control from normal operational control. Functions such as autonomous planning, AI inference, cloud services, fleet optimization, or remote mission management shall not be assumed to provide the sole protection against hazardous motion unless specifically developed and validated for that safety role. Independent protective channels shall be introduced where loss, corruption, excessive latency, or incorrect output of normal control could create unacceptable risk.

Emergency stopping shall be provided according to the physical characteristics and operating context of each product. An emergency-stop request shall have priority over ordinary motion commands and shall initiate a deterministic transition toward the defined safe condition. Resetting an emergency stop shall not automatically restart hazardous motion. Restart shall require confirmation that the initiating condition has been cleared and that the product is permitted to resume operation.

Safety sensing shall be selected according to the hazard geometry and required protective coverage rather than simply duplicating perception sensors used for autonomy. Safety LiDAR, interlocks, limit switches, redundant position feedback, braking supervision, contact sensing, or other protective devices shall be applied where required by the risk assessment. Diagnostic coverage shall include disconnection, implausible values, stale data, communication timeout, and relevant internal device faults.

The electrical architecture shall support safety objectives through appropriate power segmentation and energy isolation. Safety-critical controllers, brakes, contactors, sensors, and emergency-stop circuits shall be supplied and protected so that a single non-safety load failure does not unnecessarily defeat essential protective functions. Stored electrical, mechanical, pneumatic, gravitational, or kinetic energy shall be considered when defining isolation procedures and safe states.

Communication-dependent safety functions shall specify message integrity, timeout behavior, update rate, sequence monitoring, fault reaction, and recovery conditions. Loss of CAN, Ethernet, EtherCAT, wireless communication, or another required network shall result in a product-specific response derived from the hazard analysis. Wireless or cloud connectivity shall not be treated as inherently available, and communication recovery shall not by itself authorize automatic resumption of hazardous operation.

Each product shall have explicitly defined operating states and corresponding safety behavior, including initialization, standby, manual control, autonomous operation, degraded operation, maintenance, charging, emergency stop, and shutdown where applicable. Transitions between these states shall be controlled so that incomplete initialization, calibration failure, invalid configuration, unauthorized commands, or unexpected power restoration cannot directly produce hazardous movement.

Safety requirements shall be derived from systematic hazard analysis and allocated to hardware, embedded software, communication, mechanical systems, sensing, and operational procedures. Each requirement shall have a unique identifier, rationale, applicable product or configuration, verification method, and relationship to identified hazards. Product variants shall be reviewed whenever changes in payload, actuator power, speed, battery capacity, sensor configuration, or operating domain can alter the risk.

Applicable safety standards shall be selected according to the product category and intended deployment rather than applying a single standard uniformly across the portfolio. The engineering process shall consider machinery, industrial vehicle, functional safety, robotic, automotive, and aerospace practices as appropriate. The standards structure specifically separates AMR, outdoor vehicle, cargo UAV, quadruped, and humanoid requirements, enabling product-specific rules beneath the common HRS safety framework.

Verification shall demonstrate not only correct operation but also correct reaction to faults. Testing shall include emergency-stop activation, sensor loss, communication timeout, controller reset, power interruption, actuator fault, localization degradation, invalid commands, and other credible failure conditions identified by analysis. Results shall demonstrate that detection latency, stopping behavior, isolation, degraded operation, and recovery remain within the defined product safety requirements.

Safety validation shall be performed on the representative integrated product because interactions among electrical architecture, software, mechanics, sensors, payloads, and environmental conditions may create hazards that are not visible during component testing. Validation evidence shall record configuration, software and hardware revisions, test conditions, measured results, anomalies, corrective actions, and final acceptance so that the demonstrated safety status remains traceable.

No product shall be released solely because individual safety components have passed their respective tests. Release requires evidence that hazards have been identified, safety requirements have been implemented, interfaces have been verified, residual risks have been evaluated, and the integrated product behaves predictably during both normal and faulted conditions. Safety-related deviations shall require documented engineering review and explicit disposition before production or field deployment.

08.02. HARA Template

The HARA template establishes a consistent method for identifying, evaluating, and documenting hazards associated with robotics products throughout their lifecycle. Hazard Analysis and Risk Assessment shall begin from the intended product functions, operating environment, system boundaries, users, foreseeable misuse, and operational limitations. The resulting record shall provide traceability from hazardous situations to safety requirements and verification activities.

Each HARA record shall identify the applicable product, product variant, system configuration, hardware and software revision, analysis date, responsible engineer, and review status. The scope shall clearly state whether the analysis applies to an indoor AMR, outdoor vehicle, inspection AMR, mobile manipulator, cargo UAV, quadruped, humanoid, or another robotic platform defined within the HRS engineering framework. Configuration assumptions shall remain explicit.

The analysis shall begin with a functional description that explains what the product is intended to perform and under which operating conditions. Functions involving propulsion, steering, braking, manipulation, lifting, charging, energy storage, autonomous navigation, perception, payload handling, communication, and remote operation shall be considered where applicable. Safety-relevant dependencies between functions shall also be identified before individual hazards are evaluated.

Operating scenarios shall describe the circumstances in which a hazardous event could occur. Relevant conditions may include normal autonomous operation, manual control, startup, shutdown, charging, maintenance, degraded operation, communication loss, sensor obstruction, crowded environments, slopes, wet surfaces, restricted spaces, or interaction with other machines. The scenario description shall contain enough information for reviewers to understand the actual exposure context.

A hazard shall describe a potential source of harm rather than merely naming a component failure. Examples include unintended vehicle motion, inability to stop, unexpected manipulator movement, loss of stability, electrical shock, thermal event, uncontrolled stored energy, collision, crushing, falling payload, uncontrolled UAV flight, or loss of cargo retention. Multiple technical failures that lead to the same hazardous behavior may therefore contribute to one hazardous event.

The hazardous event shall combine the identified hazard with a specific operational situation. The template shall distinguish the initiating condition, resulting system behavior, exposed person or asset, and potential consequence. This separation prevents the HARA from becoming only a failure list and allows safety engineers to evaluate risk according to real operating conditions, foreseeable interactions, and the physical consequences of hazardous system behavior.

Potential causes shall be recorded to support subsequent safety requirement allocation and fault analysis. Causes may originate from hardware failure, software malfunction, sensor degradation, calibration error, communication timeout, power interruption, mechanical damage, environmental interference, incorrect maintenance, invalid configuration, or operator action. HARA does not require every detailed root cause, but credible initiating mechanisms shall be identified sufficiently for engineering follow-up.

Severity assessment shall represent the potential consequence if the hazardous event occurs. The organization shall define and consistently apply severity categories appropriate to its robotics products, ranging from negligible effects through minor or serious injury to life-threatening or fatal consequences where applicable. Severity shall be assessed from the credible consequence of the event rather than reduced merely because protective measures are planned but not yet demonstrated.

Exposure assessment shall represent how frequently or for how long the relevant operational situation can occur. The evaluation shall consider mission profile, operating hours, human proximity, traffic density, maintenance frequency, charging activity, environmental conditions, and product deployment pattern. Exposure shall be based on documented assumptions whenever quantitative field data are unavailable, allowing the assessment to be reviewed when operational evidence becomes available.

Controllability shall evaluate the realistic ability of an exposed person, operator, remote supervisor, or system to avoid or mitigate harm once the hazardous situation develops. Available reaction time, robot speed, stopping distance, visibility, warning effectiveness, escape space, human awareness, and automation behavior shall be considered. A theoretical possibility of avoidance shall not automatically justify a favorable controllability classification.

The selected severity, exposure, and controllability evaluations shall produce a documented risk classification according to the assessment method applicable to the product. Where automotive functional-safety concepts are appropriate, the analysis may support ASIL-oriented reasoning; machinery or industrial robotic products may instead use risk estimation methods aligned with their applicable safety framework. The template shall record the selected method rather than mixing classifications without justification.

Each unacceptable or safety-relevant hazardous event shall result in one or more safety goals or equivalent top-level safety requirements. A safety goal shall describe the required safe behavior without prematurely prescribing detailed implementation. Typical goals may require prevention of unintended motion, maintenance of controlled stopping capability, prevention of hazardous actuator torque, retention of cargo, preservation of flight control, or transition to a defined safe or minimum-risk condition.

Safety goals shall subsequently be allocated to system-level safety requirements covering sensing, control, communication, power distribution, actuators, braking, mechanical interfaces, emergency stopping, diagnostics, and operational procedures as appropriate. The HARA template shall provide references linking each hazardous event to its safety goal and downstream requirement identifiers so that changes to architecture or product configuration can be assessed for safety impact.

Existing or proposed safety measures shall be recorded separately from the initial hazard description. Measures may include safety LiDAR, redundant sensing, braking supervision, torque limitation, mechanical guarding, interlocks, contactors, emergency-stop circuits, communication timeout monitoring, geofencing, flight termination logic, or safe-state control. Their presence shall not be assumed effective until the associated implementation and verification evidence has been reviewed.

Residual risk shall be evaluated after defined safety measures have been implemented. The assessment shall document whether the remaining risk is acceptable according to the applicable product criteria and whether additional technical or operational measures are required. Where risk cannot be sufficiently reduced through design, remaining limitations, warnings, maintenance requirements, operational restrictions, or user responsibilities shall be explicitly identified and controlled.

The HARA shall include abnormal and degraded conditions rather than analyzing only nominal operation. Loss of localization, partial perception failure, actuator degradation, low battery state, network interruption, controller reset, sensor disagreement, invalid calibration, emergency-stop activation, and unexpected power restoration shall be considered where relevant. Combinations of faults shall receive additional attention when independent failures can defeat a common safety mechanism.

Changes to payload, maximum speed, actuator power, braking capability, battery capacity, sensor configuration, software behavior, operating domain, mechanical structure, or communication architecture shall trigger review of affected HARA entries. A previously acceptable assessment shall not automatically remain valid after product modification. Change control shall identify impacted hazards, assumptions, safety goals, requirements, and verification evidence before the modified configuration is released.

HARA results shall be reviewed by appropriate engineering disciplines rather than remaining the judgment of a single author. Electrical, mechanical, software, controls, perception, system, test, and safety engineers shall participate according to the product and hazard being evaluated. Disagreements concerning classification, assumptions, or mitigation shall be documented and resolved through the defined engineering review process before safety acceptance.

The completed HARA shall become a controlled safety lifecycle record connected to the safety case, validation checklist, test specifications, change records, and product release evidence. Each entry shall remain traceable from function and operating scenario through hazard, hazardous event, risk assessment, safety goal, implemented requirement, verification result, and residual-risk decision. This traceability enables the safety argument to remain maintainable as the robotics product evolves.

08.03. E-Stop Design Rule

Emergency-stop design shall provide an independent and readily accessible means to reduce or remove hazardous robot motion when an abnormal condition requires immediate human intervention. The E-stop function shall have priority over normal motion commands, autonomous planning, remote control, fleet instructions, and AI-generated actions. Its purpose is hazard mitigation, and it shall not be used as a substitute for normal operational stopping or routine power switching.

The E-stop concept shall be defined according to the product architecture, hazardous energy sources, motion characteristics, stopping distance, payload, operating environment, and expected human interaction. Indoor AMRs, outdoor vehicles, mobile manipulators, quadrupeds, humanoids, and cargo UAVs may require different emergency responses. The resulting safe condition shall therefore be explicitly defined for each product and operating mode rather than assuming that immediate power removal is universally safe.

Physical E-stop devices shall be positioned where operators or nearby personnel can identify and actuate them rapidly during foreseeable hazardous situations. Their location shall consider approach direction, robot dimensions, moving mechanisms, payload obstruction, maintenance access, and operating posture. Where one device cannot provide reasonable accessibility, multiple devices or equivalent emergency interfaces shall be provided and treated as parts of the same safety function.

The primary manual E-stop actuator shall use an unmistakable emergency-control form that minimizes confusion with ordinary controls. Actuation shall be intentional and mechanically or logically latched so that removal of hand pressure does not automatically clear the emergency condition. The actuator and associated labeling shall remain identifiable under expected lighting, contamination, vibration, environmental exposure, and maintenance conditions throughout the product lifecycle.

An E-stop request shall bypass nonessential application software wherever practical and shall not depend solely on autonomous navigation software, ROS2 nodes, cloud communication, wireless connectivity, AI perception, or fleet management services. Safety-related processing shall use an architecture appropriate to the required risk reduction. A failure or excessive latency in a non-safety computing subsystem shall not prevent an otherwise functional emergency-stop channel from initiating the required protective response.

The electrical design shall define how the E-stop signal controls propulsion, actuators, brakes, contactors, motor enable circuits, and other hazardous energy sources. Depending on the product, the response may include controlled deceleration followed by torque removal, immediate torque inhibition, brake application, contactor opening, or isolation of selected power domains. Essential control, diagnostics, lighting, communication, or braking power may remain energized when necessary to achieve or maintain the safe condition.

Immediate removal of actuator power shall not be assumed to be the safest response in every robot. A heavily loaded vehicle may require controlled braking, a manipulator may require holding torque to prevent a suspended load from falling, and a legged robot may require a managed transition to a stable posture. The design shall analyze secondary hazards created by emergency stopping and select the stopping behavior that minimizes overall risk.

Where redundant E-stop channels are required, the channels shall be sufficiently independent to prevent a single wiring, connector, controller, or interface fault from defeating the complete emergency-stop function. Channel discrepancy shall be detectable where technically appropriate. Common-cause vulnerabilities involving shared power, grounding, communication, software, connectors, or physical routing shall be evaluated when determining the actual independence of redundant safety paths.

E-stop wiring shall be designed as a safety-related circuit and protected against foreseeable open circuits, shorts, connector separation, abrasion, environmental damage, and incorrect service connection. Normally closed or otherwise fault-revealing circuit principles should be used where appropriate so that loss of continuity can be detected rather than interpreted as a healthy state. Harness routing and connector selection shall support the diagnostic assumptions of the safety architecture.

Remote emergency stopping may supplement physical E-stop devices when required by the product operating concept, but wireless communication shall not automatically be considered equivalent to a hardwired emergency circuit. The design shall define communication integrity, timeout behavior, authentication, range, latency, connection-loss response, and priority. A remote E-stop interface shall not create an unsafe dependency on cloud availability or ordinary network services.

The stopping sequence shall be deterministic and documented from E-stop actuation through achievement of the defined safe condition. Required stages may include command rejection, propulsion inhibition, controlled deceleration, brake engagement, actuator torque management, contactor control, and confirmation of stopped status. Maximum response time and stopping performance shall be derived from the product hazard analysis and validated under representative speed, load, surface, battery, and environmental conditions.

Once an E-stop has been activated, the robot shall remain in the emergency or inhibited state until a deliberate reset action is completed. Resetting the physical actuator or clearing the E-stop signal shall not itself command motion, release hazardous stored energy, or resume an autonomous mission. Restart shall require a separate controlled transition confirming that the emergency condition has been cleared and that relevant safety functions are ready for operation.

Reset logic shall consider multiple E-stop devices and distributed safety interfaces. If any emergency channel remains active, failed, disconnected, or diagnostically invalid, the system shall not indicate that the complete E-stop function has been restored. The operator interface shall provide sufficient status information to identify the inhibited condition without encouraging bypass of safety devices. Diagnostic messages shall distinguish emergency activation from detected circuit or communication faults.

Unexpected power restoration shall not cause automatic release of the emergency-stop state or hazardous motion. Following battery reconnection, charging transitions, controller reboot, software restart, or restoration of auxiliary power, the safety controller shall determine the valid state of the E-stop circuit before enabling hazardous actuators. Ambiguous or invalid states shall default to the product-specific inhibited or safe condition defined by the safety architecture.

Maintenance and service modes shall preserve appropriate emergency-stop capability whenever hazardous motion can be generated. Temporary bypass of an E-stop channel shall not be treated as normal service practice and, where technically unavoidable for controlled testing, shall require an explicitly managed engineering procedure. Such procedures shall define authorization, alternative protective measures, indication of the bypass state, restricted operating conditions, and restoration verification.

E-stop status shall be communicated to relevant controllers without allowing communication reporting to become the sole implementation of the safety action. Motion controllers, supervisory computers, fleet systems, diagnostic tools, and operator interfaces may receive E-stop state information for coordination and logging. However, failure of those reporting paths shall not prevent the primary safety mechanism from executing the required stop or maintaining the inhibited state.

Verification shall include physical actuator operation, each safety channel, wiring interruption, connector disconnection, controller reset, power cycling, communication loss, actuator faults, and reset behavior. Testing shall confirm that ordinary software commands cannot override the E-stop and that hazardous motion does not restart merely because the actuator is released. Where multiple E-stop devices are installed, each device and relevant combination of devices shall be verified.

Stopping performance shall be validated at representative worst-case conditions, including maximum permitted speed, rated payload, high or low battery state, relevant gradients, floor or terrain conditions, actuator loading, and expected environmental influences. Measured response time, deceleration, stopping distance, brake behavior, residual motion, and final safe state shall be compared with the limits established by the hazard analysis and product safety requirements.

The E-stop design record shall maintain traceability between identified hazards, safety goals, circuit architecture, hardware interfaces, software logic, diagnostic coverage, drawings, harness definitions, verification procedures, and validation results. Changes affecting actuators, brakes, payload, maximum speed, power distribution, safety controllers, communication, or mechanical configuration shall trigger review of the E-stop design and its associated safety evidence before product release.

08.04. Safety Validation Checklist

Safety validation shall confirm that the integrated robotics product achieves its defined safety objectives under representative operating and fault conditions. The validation checklist shall be applied after safety requirements have been implemented and sufficiently verified at subsystem level. Validation focuses on the behavior of the complete product, including interactions among electrical, mechanical, software, sensing, communication, power, and operational elements.

The validation record shall identify the product, product variant, hardware revision, software release, safety-controller version, sensor configuration, payload configuration, battery type, communication architecture, and applicable operating domain. Test date, location, responsible personnel, equipment, calibration status, and environmental conditions shall also be recorded so that every safety result can be associated with a reproducible product configuration.

Before dynamic validation begins, the team shall confirm that the applicable HARA, safety goals, system safety requirements, electrical drawings, harness definitions, communication specifications, calibration records, and E-stop design are released or formally approved for testing. Open safety-related deviations shall be identified and assessed. Validation shall not proceed when an unresolved condition could invalidate the test or expose personnel to uncontrolled risk.

The physical installation shall be inspected for correct assembly and safety-critical interfaces. The checklist shall confirm protective covers, guards, mechanical fasteners, payload retention, battery mounting, connectors, harness routing, grounding, protective devices, braking components, actuators, and emergency controls. Signs of damage, loose connections, interference, insufficient clearance, or configuration mismatch shall be corrected before powered testing begins.

Power-system validation shall confirm correct startup, shutdown, power isolation, protection behavior, and recovery following abnormal electrical conditions. Battery, PDU, fuse, circuit breaker, contactor, DC/DC converter, motor supply, auxiliary rails, and safety-controller power shall be evaluated where applicable. Tests shall confirm that a non-safety load fault does not unnecessarily disable safety functions required to reach or maintain the defined safe condition.

Emergency-stop validation shall verify every installed E-stop device and relevant remote emergency interface. Activation shall override normal, autonomous, remote, fleet, and AI-generated motion commands and initiate the defined stopping sequence. The robot shall remain inhibited after activation, and releasing or resetting the actuator shall not automatically restart hazardous motion. Restart shall require the separately defined controlled recovery procedure.

Stopping performance shall be measured under representative worst-case conditions. Tests shall consider maximum permitted speed, rated payload, relevant gradients, floor or terrain characteristics, battery state, actuator loading, and environmental influences. E-stop response time, deceleration, stopping distance, brake engagement, residual movement, and final safe condition shall remain within the limits established by the hazard analysis and product safety requirements.

Safety sensing shall be validated throughout the required protective coverage. Safety LiDAR, contact sensors, limit switches, redundant position feedback, obstacle-detection devices, interlocks, or equivalent protective sensors shall be tested as applicable. Validation shall include detection at relevant positions and approach directions as well as blocked, disconnected, invalid, stale, or implausible sensor conditions to confirm the required fault response.

Motion-control validation shall address unintended movement, excessive speed, incorrect direction, actuator-command errors, and failure to stop. Propulsion, steering, braking, joint motion, lifting systems, manipulators, and other hazardous actuators shall be evaluated according to the product configuration. Safety limits shall remain effective when normal control commands conflict with safety commands, and safety-related inhibition shall have the required priority.

Communication fault validation shall confirm product behavior following loss or corruption of safety-relevant communication. CAN, Ethernet, EtherCAT, ROS2 interfaces, wireless links, remote-control channels, or other applicable networks shall be interrupted or degraded according to the architecture. Timeout detection, message validity, fault reporting, degraded operation, and transition to the required safe state shall be checked without assuming continuous cloud or wireless availability.

Localization and perception validation shall examine safety behavior when autonomous information becomes unreliable. Relevant tests may include localization loss, GNSS or RTK degradation, LiDAR obstruction, camera loss, sensor disagreement, calibration error, stale perception data, and environmental interference. The objective is not only to evaluate perception accuracy but to confirm that unsafe autonomous motion is prevented when required information cannot be trusted.

Software and controller fault validation shall include controller reset, process termination, watchdog activation, software restart, corrupted or invalid configuration, delayed messages, and unexpected loss of computing resources where applicable. The product shall demonstrate predictable fault handling and shall not generate hazardous actuator commands during initialization or recovery. Safety functions shall not depend solely on successful execution of non-safety application software.

Power interruption and restoration tests shall verify that unexpected loss and return of electrical power cannot cause hazardous automatic motion. Battery disconnection, auxiliary-power interruption, controller reboot, charging transitions, and restoration of power shall be tested where relevant. Hazardous actuators shall remain inhibited until safety states have been validated and the defined restart conditions have been deliberately satisfied.

Degraded operating modes shall be validated independently rather than assumed safe because functionality has been reduced. The checklist shall confirm permitted speed, available sensing, actuator restrictions, warning behavior, communication requirements, operator responsibilities, and transition criteria for each degraded state. If the conditions required for degraded operation are no longer satisfied, the product shall transition to a more restrictive safe condition.

Maintenance and service validation shall confirm that service modes do not unintentionally bypass safety protections. Manual actuator control, diagnostic commands, calibration procedures, maintenance access, lifted-wheel operation, protective-cover removal, and temporary engineering functions shall be reviewed where applicable. Any authorized safety bypass shall be clearly indicated, procedurally controlled, limited in scope, and verified as removed before normal operation resumes.

Product-specific validation shall address hazards unique to the robot class. AMRs shall demonstrate pedestrian and obstacle protection; outdoor vehicles shall address terrain, braking, localization, and operational boundaries; manipulators shall validate workspace and torque controls; quadrupeds and humanoids shall address stability and joint hazards; cargo UAVs shall validate flight-control, propulsion, energy, communication, and cargo-retention safety behavior.

Combined-fault testing shall be considered where multiple failures could defeat a common safety mechanism or produce a hazardous interaction not represented by single-fault tests. Examples include communication loss during sensor degradation, controller reset during motion, braking degradation on a slope, or perception failure during autonomous operation. The selected combinations shall be derived from the HARA, architecture analysis, and known common-cause dependencies.

Recovery and restart validation shall demonstrate that clearing a fault does not itself authorize hazardous operation. The product shall confirm valid safety inputs, required sensor availability, controller readiness, communication status, calibration validity, actuator state, and other applicable prerequisites before motion is enabled. Manual acknowledgement or restart authorization shall be required wherever specified by the product safety concept.

Each checklist item shall record the requirement identifier, test method, expected result, actual result, pass or fail status, evidence reference, responsible tester, and any observed anomaly. Measurements, logs, photographs, diagnostic records, and test reports shall be retained when necessary to substantiate the result. Failed or incomplete items shall be linked to corrective actions and shall not be silently accepted through informal engineering judgment.

Final safety validation shall be accepted only when required tests have passed, deviations have received formal disposition, residual risks remain acceptable, and configuration traceability is complete. The validation package shall link HARA entries, safety goals, requirements, implementation evidence, test results, anomalies, corrective actions, and release approval. Any subsequent change affecting safety-relevant configuration shall trigger review and appropriate revalidation before deployment.

08.05. Safety Case Template

A safety case shall provide a structured and evidence-based argument that a robotics product is acceptably safe for its intended application, configuration, operating environment, and lifecycle stage. It shall connect identified hazards, safety goals, engineering requirements, implemented controls, verification results, validation evidence, and residual-risk decisions into a coherent justification rather than serving only as a collection of safety documents.

The safety case shall identify the product and configuration to which its conclusions apply. Product model, variant, hardware revision, software release, safety-controller version, sensor configuration, actuator configuration, battery and power architecture, payload, communication architecture, and operating domain shall be recorded. Any assumptions, exclusions, operational restrictions, or dependencies that define the validity of the safety argument shall be explicitly stated.

The opening safety claim shall state that the defined product configuration is sufficiently safe for the specified operating conditions when operated according to its approved procedures and limitations. This top-level claim shall be decomposed into supporting claims concerning hazard control, architecture integrity, safety-function performance, fault response, verification completeness, operational controls, and acceptable residual risk. Each claim shall be supported by identifiable evidence.

The safety case shall reference the applicable Hazard Analysis and Risk Assessment and demonstrate that credible hazards have been systematically identified. Relevant hazardous events, severity, exposure, controllability or other applicable risk parameters, risk classifications, and safety goals shall be traceable to the HARA record. The argument shall explain how unacceptable risks have been reduced rather than merely stating that a hazard analysis was completed.

Safety goals shall form the bridge between hazard analysis and implementation. Each safety goal shall be linked to system-level and subsystem-level safety requirements allocated to electrical, mechanical, software, control, sensing, communication, braking, power, emergency-stop, or operational elements as appropriate. Requirement identifiers shall allow reviewers to trace each safety obligation from its originating hazard through implementation and verification.

The architecture argument shall demonstrate that the product design supports the required safety functions. Evidence shall address power segmentation, actuator inhibition, braking, emergency stopping, protective sensing, communication supervision, diagnostics, fault containment, redundancy, safe-state control, and other applicable mechanisms. Where independence is claimed, shared power, connectors, software, communication, grounding, routing, or other common-cause dependencies shall be evaluated.

The emergency-stop argument shall demonstrate that E-stop devices and associated safety channels provide the required risk reduction. The safety case shall reference the approved E-stop architecture, circuit design, stopping sequence, reset behavior, diagnostic coverage, and validation results. Evidence shall show that emergency stopping has priority over ordinary commands and that resetting an E-stop does not automatically authorize hazardous motion.

The functional safety argument shall explain how relevant faults are detected and how the product responds. Sensor failure, actuator malfunction, communication timeout, controller reset, power interruption, invalid calibration, software failure, localization degradation, and other credible faults identified by analysis shall be addressed. The response may include continued safe operation, degraded operation, controlled stopping, actuator inhibition, isolation, or transition to a defined safe state.

Safety-related communication shall be supported by evidence appropriate to its role in the safety architecture. The safety case shall identify relevant networks and interfaces and describe integrity checks, timeout monitoring, update requirements, failure detection, and fault reactions. CAN, Ethernet, EtherCAT, wireless communication, ROS2 interfaces, or other communication technologies shall not be assumed reliable merely because they operate correctly under nominal conditions.

Safety sensing and perception claims shall distinguish dedicated protective functions from ordinary autonomous perception. Evidence shall demonstrate required detection coverage, sensor health monitoring, plausibility checks, obstruction handling, calibration validity, and response to missing or stale information. If AI-based perception contributes to a safety decision, its limitations and dependencies shall be explicitly considered rather than assuming that nominal detection performance establishes safety.

Verification evidence shall demonstrate that safety requirements have been correctly implemented. The safety case shall reference component, subsystem, integration, electrical, communication, functional, fault-injection, and environmental tests as applicable. Each relevant requirement shall have a defined verification method and result. Failed tests, incomplete evidence, anomalies, and deviations shall remain visible until formally resolved rather than being excluded from the safety argument.

Validation evidence shall demonstrate that the integrated product behaves safely under representative real-world and worst-case conditions. Results shall address emergency stopping, stopping distance, protective sensing, motion control, communication loss, localization degradation, controller faults, power restoration, degraded modes, maintenance conditions, combined faults, and recovery behavior where applicable. Product-specific validation shall correspond to the hazards identified for that robot class.

The safety case shall include evidence that foreseeable operational and maintenance conditions have been considered. Startup, shutdown, charging, manual control, autonomous operation, degraded operation, servicing, calibration, transport, storage, and recovery procedures shall be addressed where relevant. Operator responsibilities, inspection requirements, warnings, access restrictions, maintenance intervals, and prohibited operations shall be documented when they contribute to risk control.

Residual risk shall be explicitly evaluated after implementation and validation of the defined safety measures. The safety case shall identify remaining hazards, associated operational limitations, and the rationale for accepting the residual risk. Acceptance shall not rely solely on the absence of observed incidents during testing. The decision shall be based on the documented hazard analysis, implemented controls, evidence quality, and applicable product safety criteria.

Open issues and deviations shall be presented transparently. Each safety-related deviation shall identify its affected requirement or hazard, technical justification, temporary or permanent disposition, compensating measures, responsible authority, and closure criteria. A deviation shall not disappear from the safety case simply because product release is approaching. Unresolved issues that invalidate a safety claim shall prevent that claim from being accepted.

The safety case shall include configuration and evidence traceability so that reviewers can determine exactly which product state was evaluated. Drawings, BOMs, harness definitions, software versions, calibration records, safety requirements, HARA entries, test specifications, logs, reports, and approvals shall be revision controlled. Evidence generated for another configuration shall only be reused when its applicability to the current configuration has been technically justified.

Product-specific arguments shall supplement the common safety case structure. AMRs shall emphasize pedestrian protection and stopping behavior; outdoor vehicles shall address terrain, localization, braking, and operating boundaries; manipulators shall address workspace and torque hazards; quadrupeds and humanoids shall address stability, falls, and joint motion; cargo UAVs shall address flight control, propulsion, energy, communication, emergency response, and cargo retention.

The final safety argument shall be reviewed by the engineering disciplines responsible for the product. System, electrical, mechanical, software, controls, perception, test, and safety representatives shall review relevant claims and evidence. Approval shall confirm that the evidence is sufficient, known limitations are understood, residual risks are acceptable, and the released configuration satisfies the defined safety requirements for its intended operating domain.

Safety-case approval shall be a controlled release decision rather than an informal statement that testing is complete. The approval record shall identify authorized reviewers, approval date, applicable configuration, unresolved limitations, release conditions, and referenced evidence baseline. Deployment shall only proceed within the operating conditions and restrictions covered by the approved safety argument.

The safety case shall remain a living lifecycle record after initial release. Changes to payload, speed, actuators, braking, power architecture, sensors, communication, software, AI functions, operating domain, mechanical structure, or safety mechanisms shall trigger an impact review. Affected hazards, requirements, claims, evidence, and residual-risk decisions shall be updated and appropriate revalidation completed before the modified product is released or deployed.

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go