Robot Control Software — Ch.09: Safety Control [EN]

STATERA Library · Series 08 · Volume 04 · Chapter 09 · EN
Source: https://github.com/Statera-Library/08_Vol_04_Robot_Control_Software/blob/main/Chapter_09_Safety_Control/Chapter_09_Safety_Control_EN.md

Volume 04 Robot Control Software

09. Safety Control

09.01 Safety Control Function (SCF) Identification Methodology

Safety Control Function identification begins by translating system-level hazards into explicit control behaviors that prevent unacceptable physical outcomes. In robot control software, an SCF is not simply an emergency routine but a function whose correct execution contributes directly to maintaining or reaching a safe state. Identification therefore starts from intended operation, foreseeable misuse, operating modes, human interaction, environmental conditions, and possible failures.

The first analytical step is to define the system boundary and operational context before individual safety functions are selected. Engineers identify actuators, sensors, power stages, communication interfaces, control computers, mechanical transmission elements, external equipment, and human access zones. Operating states such as initialization, automatic motion, manual control, maintenance, charging, recovery, and shutdown must be considered separately because the same physical hazard can require different protective behavior in each state.

Hazard identification examines how robot motion, stored energy, payloads, tools, electrical power, unexpected startup, communication loss, and control errors can produce hazardous situations. Each hazard should be connected to a concrete operating scenario rather than recorded only as an abstract failure. For example, excessive mobile-robot velocity becomes safety-relevant when a person can enter the stopping path, while manipulator motion becomes critical when an operator can access the workspace during teaching or collaborative operation.

Risk estimation provides the bridge between identified hazards and required safety control behavior. The analysis considers the severity of possible harm, frequency or duration of exposure, and the possibility of avoiding or limiting the hazardous event. The resulting risk classification determines whether ordinary functional control is sufficient or whether an independently monitored safety function is required. The methodology should preserve traceability from the hazardous scenario through the risk evaluation to the selected SCF and its implementation requirements.

A useful SCF identification process separates the hazardous event from the protective reaction. The hazardous event may be excessive speed, unintended torque, motion beyond an authorized boundary, movement in an unsafe direction, or failure to stop. The corresponding safety reaction is then expressed independently as a measurable function, such as safely limiting speed, supervising position, monitoring direction, initiating a controlled stop, or removing actuator torque. This separation prevents vague requirements such as "make the robot safe."

The required safe state must be defined for every relevant hazardous scenario. A safe state does not always mean immediate removal of motor torque because uncontrolled stopping can itself create additional hazards. A suspended manipulator carrying a payload, a mobile robot on a slope, or a legged robot maintaining balance may require controlled deceleration or stabilization before torque is removed. SCF identification must therefore distinguish between maintaining a safely controlled operating condition and transitioning the system toward a de-energized state.

Once the required safety reaction is understood, engineers define the triggering conditions for the SCF. Inputs may include emergency-stop devices, protective scanners, light curtains, safety encoders, torque sensors, position limits, speed estimates, communication watchdogs, drive status, or redundant state information. Trigger conditions should specify thresholds, timing constraints, validity checks, hysteresis, and sensor disagreement behavior so that the safety function can be implemented and verified without relying on ambiguous interpretation.

The methodology must also determine which signals and components belong to the safety-related control path. A safety function may span sensing, communication, logic processing, drive interfaces, and mechanical actuation. Therefore, identification cannot stop at the application software layer. Engineers must trace the complete chain from the initiating condition to the final physical risk reduction, including diagnostic coverage, redundant channels, communication integrity, power-stage behavior, and the ability of the actuator or brake to achieve the commanded safe response.

Safety functions should be allocated according to independence and criticality. Normal motion control may generate velocity, position, or torque commands, while a separate safety path supervises whether those commands remain inside validated limits. This architecture reduces dependence on the correctness of complex application software. The safety controller should not assume that trajectory planning, AI perception, navigation, or the primary control loop is always correct; instead, it should monitor safety-relevant physical quantities through appropriately trusted information paths.

Timing is a fundamental part of SCF definition because safety is determined by both logical correctness and response time. The total reaction interval includes hazard detection, sensor processing, communication, safety logic execution, drive response, mechanical braking, and physical stopping. A function that eventually stops a robot may still be inadequate if the stopping distance exceeds the protected separation distance. SCF requirements should consequently contain maximum response times and measurable physical performance criteria.

Operating-mode analysis is necessary because safety requirements often change with robot state. Automatic production may permit full performance only when access is restricted, whereas manual teaching may require reduced speed and enabling-device supervision. Maintenance may require prevention of unexpected startup, while collaborative operation may rely on continuously monitored speed, separation, force, or position constraints. Mode transitions themselves must be analyzed because inconsistent state information can temporarily disable otherwise valid safety protections.

Dependencies among safety functions should be explicitly identified. Safe stopping may depend on valid speed feedback, while safely limited position may depend on redundant position measurement and calibrated mechanical references. A failure in a shared sensor, communication bus, clock, power supply, or software service can therefore disable several SCFs simultaneously. Dependency analysis reveals common-cause and common-mode vulnerabilities that may remain hidden when each safety function is evaluated independently.

The identified SCFs are converted into precise safety requirements containing activation conditions, monitored variables, limits, required reactions, response times, fault responses, reset conditions, and interfaces. Requirements should state what the safety function must accomplish without prematurely prescribing a particular software implementation. This allows architectural alternatives to be evaluated while maintaining a stable connection between the original hazard analysis and the eventual safety control design.

Traceability is maintained through a safety function matrix linking hazards, hazardous scenarios, risk reduction measures, SCFs, sensors, logic channels, actuators, diagnostics, and verification evidence. Each SCF receives a unique identifier so that later software requirements, test cases, calibration parameters, fault-injection scenarios, and certification artifacts can refer to the same function consistently. This structure is especially important when safety behavior is distributed across a robot controller, safety PLC, network, and intelligent servo drives.

Verification planning should begin during SCF identification rather than after implementation. Every safety function must be expressed so that its triggering condition and resulting physical behavior can be tested. Engineers define normal boundary tests, threshold tests, timing measurements, sensor-failure cases, communication interruptions, actuator faults, and combinations of faults that could compromise the function. SIL, HIL, and physical robot testing can then provide progressively stronger evidence that the implemented SCF satisfies its safety intent.

SCF identification ultimately creates the foundation for subsequent safety-control implementation. Functions such as safe stopping, safely limited speed, safe direction monitoring, safely limited position, and safe torque removal should emerge from a structured analysis of hazards rather than being added as isolated features. A disciplined methodology connects physical risk, operating context, safety state, monitoring logic, hardware interfaces, diagnostics, and verification into one traceable engineering chain, enabling safety control software to remain understandable as robot complexity increases.

09.02 Safe Stop SS1 / SS2 / SOS SW Implementation [w/Code]

Safe Stop functions are safety-related motion-control mechanisms that bring a robot into a defined safe condition when hazardous motion must be interrupted. Safe Stop 1 (SS1), Safe Stop 2 (SS2), and Safe Operating Stop (SOS) represent different combinations of controlled deceleration, standstill supervision, and torque availability. Their software implementation must coordinate safety logic with the motion controller and drive while remaining independent from ordinary application-level commands.

SS1 is intended for situations in which controlled deceleration is preferable to immediately removing actuator torque. When SS1 is requested, the control system initiates a predefined stopping trajectory while the drive remains capable of generating torque. After standstill is reached, or after a monitored stopping interval expires depending on the implementation, the system transitions toward torque removal, typically through a Safe Torque Off (STO) function. This sequence reduces mechanical shock and uncontrolled motion during emergency stopping.

The software implementation of SS1 therefore requires more than issuing a zero-velocity command. A safety state machine supervises the complete transition from normal operation through controlled deceleration to the final safe state. The implementation monitors velocity, deceleration, elapsed time, drive status, and relevant feedback signals. If the expected stopping behavior is violated, the safety layer must initiate the predefined fault reaction rather than continuing to depend on the normal motion controller.

An SS1 implementation can use monitored time or monitored deceleration behavior according to the selected safety architecture and drive capability. In a time-supervised approach, torque-producing control remains active during a validated stopping interval before STO is activated. In a more tightly monitored implementation, the actual deceleration trajectory or velocity envelope is supervised. Excessive velocity, insufficient deceleration, or failure to reach standstill can therefore trigger escalation to a more restrictive safety response.

SS2 also begins with controlled deceleration, but its final state differs fundamentally from SS1. Instead of removing torque after the stopping process, SS2 transitions into a safely monitored standstill condition. Motor torque remains available so that the robot can actively maintain position. This behavior is useful when removing torque could cause an axis to move because of gravity, external force, stored mechanical energy, or an unstable configuration that requires active control.

Software supporting SS2 must coordinate the stopping trajectory with subsequent standstill supervision. Once the controller determines that the robot has entered the permitted standstill region, the system activates SOS monitoring. Position and velocity feedback are continuously evaluated against predefined limits. The transition between deceleration and standstill supervision must be deterministic because a temporary monitoring gap could allow hazardous motion to occur without detection.

SOS is the safety function responsible for supervising a stopped actuator while drive torque remains enabled. It does not normally command continuous motion; instead, it verifies that the axis remains inside the permitted standstill tolerance. The ordinary position controller may continue producing holding torque, while the independent safety channel observes safety-related position or velocity information. Motion beyond the validated tolerance causes a defined safety reaction, commonly progressing toward torque removal or another safe state.

Standstill cannot be represented as an ideal mathematical zero because sensors contain quantization, noise, mechanical compliance, and estimation error. SOS software therefore requires validated tolerance parameters for position deviation, velocity, measurement uncertainty, and observation time. Limits must be sufficiently tight to prevent hazardous movement while avoiding unnecessary trips caused by normal measurement variation. These parameters become safety-relevant calibration data and require controlled configuration and traceability.

A practical implementation commonly organizes SS1, SS2, and SOS as explicit states and transitions within a safety state machine. Inputs include safety requests, emergency signals, operating mode, encoder information, drive status, communication validity, and diagnostic results. Outputs may request controlled stopping, enable standstill monitoring, command STO, or report a safety fault. State transitions should occur only when their entry conditions and required safety evidence have been satisfied.

The normal motion controller and safety controller must have clearly separated responsibilities. The motion controller can generate a smooth deceleration trajectory because it has detailed knowledge of robot dynamics and motion constraints. The safety controller, however, must independently determine whether the resulting behavior remains within the permitted safety envelope. Consequently, successful execution of an application stop command cannot itself be treated as proof that SS1 or SS2 has completed safely.

Feedback integrity is critical because safe stopping depends on trustworthy knowledge of actual actuator motion. Safety-rated encoders, redundant sensing channels, plausibility checks, or independently derived speed information may be used according to the required safety architecture. Software should detect stale data, impossible transitions, disagreement between channels, communication timeout, and invalid measurement status. A feedback fault during SS1, SS2, or SOS must lead to a predetermined reaction rather than an undefined continuation of motion.

Timing supervision must cover the complete safety reaction chain. The relevant interval begins when the safety request becomes valid and includes input processing, communication latency, controller execution, drive response, mechanical deceleration, and confirmation of the resulting safe state. Maximum stopping time and stopping distance must be consistent with the robot\'s risk assessment. Heavy mobile robots, high-inertia manipulators, and payload-carrying systems may require substantially different deceleration profiles and safety margins.

Multi-axis robots require additional coordination because individual joints or wheels cannot always be stopped independently without creating another hazard. A manipulator may need synchronized joint deceleration to avoid dropping a payload or generating excessive Cartesian motion. A mobile robot may need coordinated drive and steering behavior to maintain directional stability. SS1 and SS2 software should therefore supervise both individual actuator limits and system-level stopping behavior where the mechanical architecture requires coordinated motion.

Reset and restart behavior is part of the safety implementation rather than an application convenience. Completion of SS1, SS2, or SOS should not automatically authorize normal motion unless the required restart conditions are satisfied. Safety inputs must be valid, faults must be cleared according to the defined procedure, operating modes must be consistent, and any required manual acknowledgement must occur. Restart logic must also prevent unexpected motion immediately after the safety condition disappears.

Verification should exercise every transition and failure path in the Safe Stop state machine. Tests include normal SS1 and SS2 activation, SOS tolerance violation, excessive stopping time, encoder disagreement, communication interruption, drive fault, repeated safety requests, reset attempts, and failures occurring during state transitions. SIL and HIL testing can verify logic and timing systematically before physical robot tests measure actual deceleration, stopping distance, standstill stability, and actuator response.

SS1, SS2, and SOS ultimately form a coordinated family of safety functions rather than isolated stop commands. SS1 provides controlled deceleration followed by a torque-safe condition, SS2 provides controlled deceleration followed by safely monitored standstill, and SOS supervises that standstill while torque remains available. Their software implementation combines deterministic state management, independent monitoring, reliable feedback, timing supervision, fault handling, and controlled restart to ensure that stopping behavior remains predictable under both normal and failure conditions.

09.03 Safely Limited Speed (SLS) Implementation [w/Code]

Safely Limited Speed (SLS) is a safety control function that supervises robot motion and ensures that actual speed does not exceed a predefined safety limit while drive torque remains available. Unlike a stop function, SLS permits continued motion under restricted conditions. It is particularly useful during teaching, maintenance, collaborative operation, commissioning, and other modes in which personnel may enter areas that normally require separation from moving machinery.

The fundamental SLS principle is to separate ordinary speed control from safety-related speed supervision. The normal motion controller generates velocity or trajectory commands according to the application, while an independent safety channel evaluates measured or derived speed against a validated safety limit. The safety function therefore does not assume that the commanded velocity is correct. It determines whether the physical robot is actually moving within the permitted safety envelope.

SLS activation normally begins with a safety request associated with an operating-mode change, protective-device state, human access condition, or higher-level safety decision. When SLS becomes active, the motion controller may first reduce the commanded speed to the permitted range. The safety controller then supervises actual motion independently. Activation must be deterministic, and the robot must enter the limited-speed condition within a specified transition time without creating an unmonitored interval.

A software implementation can represent SLS through an explicit safety state machine containing states such as normal operation, speed reduction, SLS active, violation detected, and safe reaction. Entry into the SLS-active state should occur only after required conditions are confirmed, including valid feedback, correct operating mode, healthy safety communication, and acceptable actuator status. State transitions and their conditions should be defined precisely so that every possible operating path can be verified.

Speed supervision requires reliable motion information. Depending on the robot architecture, this information may originate from safety-rated encoders, redundant wheel encoders, joint sensors, motor feedback, or independently calculated velocity estimates. The safety software should validate signal freshness, range, consistency, direction, and agreement between redundant channels. Invalid or unavailable feedback must not silently disable SLS because loss of trustworthy speed information removes the basis for demonstrating that motion remains safely limited.

The monitored quantity must also be selected according to the physical hazard. For a single motor, rotational speed may be sufficient, whereas a mobile robot may require supervision of translational and rotational velocity. A manipulator may require joint-speed monitoring and, in some applications, Cartesian velocity supervision at the tool or another relevant point. Legged and mobile-manipulation systems can require multiple monitored quantities because individual joint speeds alone may not represent the velocity of the hazardous moving structure.

The SLS threshold is a safety-relevant parameter rather than an ordinary tuning value. Its selection should follow the system risk assessment and intended operating mode. The configured limit may depend on human proximity, mechanical geometry, payload, braking capability, sensing uncertainty, and expected reaction time. Parameter values should be protected against unintended modification and associated with configuration identification, access control, validation evidence, and traceability to the corresponding safety requirement.

Real measurements fluctuate because of encoder quantization, sampling effects, vibration, numerical differentiation, and estimation noise. SLS software therefore requires carefully designed signal processing that preserves safety response performance. Filtering can reduce false violations, but excessive filtering introduces delay and may allow hazardous overspeed to remain undetected. Filter characteristics, sampling period, calculation latency, and threshold margins must consequently be treated as part of the safety design rather than ordinary signal-conditioning choices.

Overspeed detection should account for both the configured limit and the uncertainty of the measurement chain. A practical supervisor compares validated speed information with an internal monitoring boundary and evaluates whether the limit has been exceeded according to defined temporal conditions. Small transient measurement variations may require controlled tolerance, while sustained or significant overspeed must produce a safety reaction. The algorithm must remain deterministic so identical safety conditions result in predictable behavior.

When an SLS violation is detected, the software must initiate a predefined safe reaction rather than merely reporting an error to the application. Depending on the risk analysis and mechanical system, the response may involve controlled deceleration through SS1, transition to SS2 and monitored standstill, or torque removal through STO. The selected reaction must reduce the hazardous condition within the required response time and stopping distance while avoiding additional risks created by uncontrolled mechanical behavior.

Timing analysis is essential because SLS effectiveness depends on how quickly excessive speed can be detected and corrected. Total reaction time includes sensor acquisition, filtering, velocity calculation, communication, safety logic execution, drive response, and mechanical deceleration. The robot may continue moving during this interval, so safety distance calculations must account for both detection distance and stopping distance. Higher inertia, heavier payloads, or poor surface conditions can significantly increase the required protective margin.

Communication between distributed safety components must preserve the integrity and freshness of SLS information. In architectures using a safety controller, remote I/O, networked drives, or distributed encoders, speed values and safety states may cross several communication interfaces. Sequence monitoring, timeout detection, validity information, and appropriate safety communication mechanisms are needed so that corrupted, delayed, duplicated, or missing information cannot be interpreted as valid evidence of safe speed.

Multi-axis systems introduce additional complexity because safe speed may be a system-level property. In a manipulator, several joints moving within their individual limits can combine to produce a high Cartesian tool speed. In a mobile robot, wheel velocities combine into translational and rotational motion, while steering geometry can change the resulting trajectory. SLS software should therefore monitor the physical quantity associated with the identified hazard instead of assuming that limiting each actuator independently always guarantees safe system motion.

Mode management is closely connected to SLS because different operating modes may require different speed limits. Automatic operation, manual teaching, maintenance, recovery, and collaborative operation can each use distinct validated limits and activation conditions. Switching between these limits must itself be safety controlled. A transition from a lower limit to a higher one should occur only when the required protective conditions are confirmed, preventing accidental restoration of unrestricted motion while personnel remain exposed.

Reset and release logic must prevent unexpected acceleration after an SLS condition ends. Removal of the safety request should not automatically authorize full-speed motion unless all required safety conditions are valid. The system may require confirmation of operating mode, protective-device state, fault status, and manual acknowledgement. The normal controller should then resume motion through a controlled transition rather than immediately applying a previously stored high-speed command.

Verification of SLS should cover nominal operation, boundary conditions, and fault scenarios. Tests should examine activation and release transitions, speeds just below and above the configured limit, rapid acceleration through the threshold, sensor disagreement, stale feedback, communication loss, invalid parameters, controller faults, and the resulting safe reactions. SIL and HIL environments can automate extensive boundary testing, while physical robot tests confirm real reaction time, velocity accuracy, deceleration, and stopping distance.

A robust SLS implementation therefore combines independent speed supervision, trustworthy feedback, protected safety parameters, deterministic state transitions, bounded processing latency, defined overspeed reactions, and controlled restart behavior. Rather than simply commanding a robot to move slowly, SLS continuously establishes that physical motion remains within a validated safety limit and initiates a safe reaction whenever that condition can no longer be demonstrated. This makes limited-speed operation an enforceable safety property rather than an application-level assumption.

09.04 Safe Direction Indication (SDI) Implementation [w/Code]

Safe Direction Indication (SDI) is a safety-related control function used to ensure that robot motion occurs only in a permitted direction while the function is active. It is especially valuable when personnel work near moving machinery during setup, teaching, maintenance, recovery, or collaborative tasks. Rather than requiring complete standstill, SDI permits controlled motion while preventing movement toward a direction identified as hazardous by the system risk assessment.

The fundamental principle of SDI is to supervise the sign or directional component of actual motion independently from the normal motion command. The application controller may request positive or negative movement according to its trajectory, but the safety controller determines whether measured motion agrees with the currently permitted direction. This separation prevents an incorrect command, software fault, or control error from being accepted merely because it originated from the normal motion-control path.

An SDI implementation begins by defining the directional reference frame associated with the hazard. For a rotary joint, permitted direction can correspond to positive or negative angular motion. For a linear actuator, it may represent extension or retraction. Mobile robots can require forward, reverse, or rotational-direction supervision, while manipulators may require directional constraints expressed in joint space or relative to a Cartesian axis associated with a protected workspace.

Activation of SDI should be associated with explicit safety conditions such as operating mode, protective-device state, human access, maintenance procedure, or a higher-level safety request. When the function becomes active, the safety system establishes the permitted direction before allowing continued motion. The transition must be deterministic so that stale directional information or a temporary gap between mode switching and safety supervision cannot authorize motion in an unintended direction.

A practical software architecture implements SDI through a safety state machine containing normal operation, SDI activation, direction supervision, violation detection, and safe-reaction states. State transitions depend on validated feedback, safety request status, operating mode, communication health, and actuator diagnostics. The safety controller should maintain explicit knowledge of whether positive motion, negative motion, or no motion is currently permitted rather than deriving permission indirectly from application commands.

Reliable motion feedback is essential because SDI must determine the direction in which the physical actuator is actually moving. Safety-rated encoders, redundant position sensors, wheel encoders, motor feedback, or independently calculated velocity information can provide this evidence. The software should verify freshness, validity, channel agreement, and signal plausibility. If motion direction cannot be determined reliably, the safety system should execute the defined fault response instead of assuming that the robot remains compliant.

Direction determination is normally based on position change or velocity sign, but real signals require careful processing around zero speed. Encoder quantization, vibration, backlash, mechanical compliance, and numerical differentiation can produce small alternating velocity estimates even when an axis is effectively stationary. SDI software therefore needs a validated zero-speed region or directional tolerance that distinguishes meaningful prohibited motion from measurement fluctuations without masking genuinely hazardous displacement.

The directional tolerance must be treated as a safety-related parameter. A tolerance that is too narrow can create unnecessary trips because of sensor noise, while an excessively wide tolerance can permit hazardous reverse movement before detection. Parameter selection should consider sensor resolution, sampling period, mechanical backlash, expected disturbance, maximum acceleration, reaction time, and the physical consequence of movement in the prohibited direction. Configuration and modification of these values require traceability and controlled access.

When prohibited motion is detected, SDI must initiate a predefined safety reaction rather than simply informing the application layer. Depending on the robot and hazardous scenario, the reaction can involve controlled deceleration through Safe Stop 1 (SS1), transition to a monitored standstill using Safe Stop 2 (SS2) and Safe Operating Stop (SOS), or torque removal using Safe Torque Off (STO). The selected response must prevent continued hazardous displacement within the required reaction time.

Timing analysis is particularly important because a robot can travel some distance in the prohibited direction between the beginning of unintended motion and completion of the safety response. Total reaction time includes sensor acquisition, direction calculation, filtering, safety logic execution, communication, drive response, and mechanical stopping. The resulting reverse-motion distance must remain compatible with the risk assessment, protected workspace, and available physical clearance.

For mobile robots, SDI implementation must account for the relationship between individual wheel direction and vehicle-level motion. Wheel rotation alone may not uniquely represent the hazardous direction when differential drive, Ackermann steering, four-wheel steering, or skid steering is used. Safety software may therefore need to derive longitudinal velocity, lateral behavior, or yaw direction from multiple signals so that supervision corresponds to actual platform movement rather than isolated actuator rotation.

Manipulator systems present a similar system-level challenge. Individual joints can all move in locally permitted directions while their combined motion causes the end effector or another robot link to travel toward a hazardous region. Where the risk analysis identifies Cartesian direction as the relevant hazard, SDI supervision may require validated kinematic calculations using joint feedback. The safety architecture must then account for model validity, computational latency, and uncertainty in the derived directional quantity.

Multi-axis coordination becomes important when several actuators contribute to the same safety-relevant direction. The software should define whether SDI applies independently to each axis or to a combined physical motion quantity. Coordinated supervision may be required for manipulators, mobile manipulators, gantry systems, or steering-drive platforms. This avoids the incorrect assumption that individually acceptable actuator directions necessarily produce an acceptable system-level direction.

Communication integrity is required when directional information is distributed across sensors, safety controllers, networks, and drives. The safety layer should detect missing messages, repeated data, stale values, invalid status, sequence errors, and communication timeouts. A delayed direction value can be particularly dangerous because the software may compare current motion against an outdated state. Safety communication therefore needs bounded latency and explicit validity information for all direction-related signals.

Mode management determines when each permitted direction is valid. A maintenance mode may allow an actuator to retract but prohibit extension toward an operator, while a recovery mode may allow motion only away from an obstacle. Changing operating modes can therefore change the permitted direction. Such transitions should be safety controlled, and the new directional permission should become active only after all required protective conditions and feedback states have been verified.

Reset and restart logic must ensure that an SDI violation cannot be cleared merely because prohibited motion has stopped. The original safety condition, sensor validity, operating mode, drive status, and required acknowledgement should be checked before motion is authorized again. Previously queued motion commands must not cause immediate movement in the prohibited direction after reset. A controlled transition back to normal or direction-limited operation prevents unexpected restart behavior.

Verification should exercise SDI near its directional boundaries and under representative fault conditions. Testing includes permitted and prohibited movement, reversal near zero speed, encoder noise, sensor disagreement, communication loss, rapid direction changes, mode transitions, parameter boundaries, and failures during activation. SIL and HIL testing can systematically explore these cases, while physical robot tests confirm actual detection latency, prohibited displacement, stopping behavior, and mechanical effects.

A robust SDI implementation therefore combines explicit directional permission, independent motion supervision, trustworthy feedback, validated zero-speed tolerance, deterministic state transitions, communication integrity, defined violation reactions, and controlled restart behavior. SDI transforms a directional restriction from an application command into an enforceable safety property, allowing necessary robot motion to continue while preventing movement toward directions that have been identified as hazardous.

09.05 Safe Limited Position (SLP) Implementation [w/Code]

Safe Limited Position (SLP) is a safety-related control function that supervises robot position and prevents motion beyond predefined safe boundaries while actuator torque may remain available. Unlike a mechanical end stop or ordinary software travel limit, SLP provides safety-related monitoring of actual position. It is applicable to robot joints, linear axes, mobile platforms, gantry systems, and workspaces where entering a prohibited region could create a hazardous situation.

The fundamental principle of SLP is to separate normal position control from independent safety supervision. The application controller generates position commands and trajectories according to the required task, while the safety controller independently evaluates measured position against validated limits. Consequently, a corrupted trajectory, incorrect command, controller failure, or software defect cannot be considered safe merely because the normal position loop continues to operate correctly.

SLP implementation begins by defining the physical quantity and reference frame to be supervised. A rotary joint may use minimum and maximum angular positions, while a linear actuator can use permitted extension limits. A mobile or Cartesian system may define geometric boundaries in one or more coordinates. The selected representation must correspond directly to the hazardous motion identified by the risk assessment rather than simply reflecting convenient internal controller coordinates.

Safe boundaries can be represented as lower and upper limits, permitted intervals, restricted zones, or multidimensional workspaces. For a single axis, the logic may verify that position remains between validated minimum and maximum values. For a manipulator, several joint limits or Cartesian boundaries may define the safe workspace. More complex systems can require multiple boundaries that change according to operating mode, tool configuration, payload, or interaction scenario.

Activation of SLP is normally associated with explicit safety conditions such as operating mode, protective-device state, human access, maintenance activity, or a higher-level safety request. When SLP becomes active, the system must establish which positional limits are valid before continued motion is permitted. Transitions between unrestricted and restricted regions require deterministic logic so that an outdated limit set cannot remain active during a safety-relevant mode change.

A practical software architecture can implement SLP through a safety state machine containing normal operation, SLP activation, position supervision, boundary violation, and safe-reaction states. Entry into position supervision requires valid position feedback, correct configuration, healthy safety communication, and acceptable actuator diagnostics. The safety controller should explicitly manage the active limit set and reject inconsistent states rather than depending on application software to provide valid boundaries.

Reliable position feedback is fundamental because SLP must determine where the physical mechanism is actually located. Safety-rated encoders, redundant position sensors, linear scales, wheel-position information, or other validated feedback channels may be used according to the robot architecture. The software must supervise signal validity, freshness, range, plausibility, and agreement between redundant measurements so that incorrect position information cannot be accepted as evidence of safe operation.

Absolute position knowledge is especially important because a relative measurement can remain internally consistent while losing its relationship with the physical mechanism. Systems using incremental encoders may therefore require a validated reference or homing process before SLP becomes available. Power cycling, encoder replacement, mechanical servicing, or loss of reference information can invalidate the established position relationship and should prevent safety supervision from being declared operational until reference integrity is restored.

Position limits require safety margins because measurement and mechanical systems contain uncertainty. Encoder resolution, sensor accuracy, backlash, compliance, calibration error, communication delay, controller sampling, and stopping distance all influence the effective boundary. The safety threshold should therefore be positioned so that detection and reaction occur before the physical mechanism reaches the hazardous boundary, leaving sufficient distance for the complete safety response.

Boundary monitoring should consider motion direction as well as absolute position when necessary. A robot located near an upper positional limit may safely move away from that limit while motion toward it requires tighter supervision. Combining positional information with velocity or direction can improve the safety response and avoid unnecessarily stopping movement that reduces risk. Nevertheless, every combined rule must remain deterministic and traceable to the corresponding safety requirement.

When an SLP boundary is violated, the software must initiate a predefined safe reaction rather than merely clamp the application command. Depending on the hazard and mechanical configuration, the reaction may use Safe Stop 1 (SS1), Safe Stop 2 (SS2), Safe Operating Stop (SOS), or Safe Torque Off (STO). The appropriate response depends on whether controlled deceleration, active position holding, monitored standstill, or torque removal provides the safest physical outcome.

Timing analysis determines how far the mechanism can move after a limit violation begins. Total reaction time includes position acquisition, communication, safety processing, violation detection, drive response, and mechanical stopping. A fast-moving axis may travel a significant distance during this interval. SLP boundaries must therefore incorporate dynamic stopping margins rather than being placed directly at the physical hazardous boundary without accounting for velocity and system response.

Manipulator systems introduce additional complexity because joint positions and Cartesian workspace boundaries are related through robot kinematics. Individual joints may remain within their safe limits while the end effector or another link enters a prohibited region. If the hazard is defined in Cartesian space, the safety system may need validated forward-kinematic calculations and geometric monitoring. Model parameters and tool dimensions then become safety-relevant configuration data.

Mobile robots can apply position-limiting concepts to safety zones, restricted corridors, docking regions, or maintenance areas, although localization integrity becomes a critical dependency. Wheel odometry alone may accumulate error, while map-based localization can contain uncertainty or temporary loss of confidence. When position supervision depends on localization, the safety architecture must determine whether the positioning source provides sufficient integrity and define a safe response when position confidence becomes inadequate.

Dynamic or mode-dependent boundaries require particularly careful management. A maintenance mode may reduce the permitted workspace, while automatic operation can use a larger protected region. Tool changes, payload geometry, collaborative operation, or temporary obstacles may also alter the valid limits. The safety controller should select boundaries only from validated configurations and confirm the transition conditions before applying a new set, especially when the new configuration enlarges the permitted workspace.

Multi-axis SLP requires coordination when several actuators contribute to the same hazardous position. Monitoring each axis independently can be sufficient for simple rectangular joint-space limits, but it cannot represent every physical workspace constraint. Coordinated supervision may evaluate combinations of joint positions, Cartesian coordinates, or geometric relationships. Computational complexity must remain compatible with deterministic execution and the required safety response time.

Communication integrity is essential when position information, limit configurations, and safety states are distributed among sensors, safety controllers, networks, and drives. The software should detect stale data, missing messages, sequence errors, invalid status, corrupted configuration, and communication timeout. A previous valid position must never be reused indefinitely after feedback is lost because the physical mechanism may continue moving while the safety controller evaluates obsolete information.

Reset and restart logic must ensure that a boundary violation cannot lead directly back to unrestricted motion. The system should verify valid position feedback, restored reference integrity, correct operating mode, acceptable actuator state, cleared faults, and any required manual acknowledgement. If the robot remains near a boundary, recovery motion may need to be restricted to a direction that moves the mechanism back into the permitted region before normal operation is restored.

Verification of SLP should include nominal operation, boundary conditions, configuration changes, and representative faults. Tests should exercise positions immediately inside and outside limits, rapid approaches to boundaries, sensor disagreement, reference loss, communication interruption, incorrect configuration, mode transitions, and failures during activation. SIL and HIL testing can systematically cover software states, while physical robot tests confirm actual positional accuracy, reaction time, stopping margin, and recovery behavior.

A robust SLP implementation therefore combines independently supervised position, trustworthy reference information, validated boundaries, safety margins, deterministic state transitions, defined violation reactions, configuration control, communication integrity, and controlled recovery. SLP transforms a software travel limit into an enforceable safety property by continuously establishing that the physical robot remains within a validated region and initiating a safe reaction whenever continued positional compliance can no longer be demonstrated.

09.06 Safe Torque Off (STO) SW Interface [w/Code]

Safe Torque Off (STO) is a safety-related drive function that prevents an actuator from generating torque capable of producing hazardous motion. Unlike a conventional software stop command, STO acts through a safety-controlled drive interface that disables torque-producing energy within the motor control path. The robot control software must therefore treat STO as a dedicated safety state and interface rather than as an ordinary zero-torque, zero-current, or zero-velocity command.

The fundamental purpose of the STO software interface is to connect higher-level safety decisions with the drive hardware that removes torque-producing capability. A safety controller may request STO after an emergency stop, protective-device activation, safety-function violation, or detected fault. The application controller can observe the resulting state, but the safety action should not depend solely on ordinary application software, trajectory execution, or communication paths that are not designed for the required safety integrity.

STO differs fundamentally from commanding the motor torque reference to zero. A normal torque command remains dependent on software execution, communication, current regulation, inverter switching, and the correctness of the ordinary drive-control chain. STO instead disables the drive\'s ability to generate commanded torque through a safety-related mechanism. This distinction ensures that failures in normal motion-control software cannot simply restore actuator torque while the STO condition remains active.

A practical STO interface architecture separates the normal control path from the safety path. The normal controller communicates motion commands to the servo drive, while the safety controller provides one or more dedicated STO signals or communicates through an appropriate safety-rated interface. The drive internally combines these safety inputs with its power-stage control so that torque-producing switching is inhibited when STO is active, regardless of commands still present on the ordinary motion interface.

The software representation of STO should use an explicit safety state machine. Typical states include normal operation, STO request, torque-disabled confirmation, STO active, reset pending, and restart permitted. Transitions should depend on validated safety inputs, drive feedback, communication status, operating mode, and reset conditions. Explicit state management prevents ambiguous behavior when an STO request occurs during acceleration, braking, initialization, communication recovery, or another safety-function transition.

STO activation may be the final reaction of other safety functions. Safe Stop 1 (SS1), for example, can first perform controlled deceleration and subsequently activate STO after the required stopping condition is reached. Safely Limited Speed (SLS), Safe Direction Indication (SDI), or Safe Limited Position (SLP) violations may also escalate to STO when the predefined safety reaction requires torque removal. The interface must preserve deterministic coordination between these preceding functions and the final STO state.

STO itself does not necessarily perform controlled deceleration. If torque-producing capability is removed from a moving actuator, the mechanism may coast according to inertia, friction, gravity, external forces, and mechanical loading. For this reason, STO should not automatically be interpreted as equivalent to immediate physical standstill. The system-level safety design must determine whether direct STO activation is acceptable or whether controlled stopping, braking, or stabilization is required before torque is disabled.

Mechanical brakes require special coordination with STO because torque removal can release the ability of an actuator to support a suspended or gravity-loaded mechanism. A vertical axis, manipulator joint, lift mechanism, or payload-handling robot may need a holding brake applied in a validated sequence. Software must coordinate brake commands, brake feedback, motion state, and STO activation so that the transition to the torque-disabled condition does not create unintended falling or displacement.

The STO command and feedback interface should distinguish requested state from achieved state. A safety controller can issue an STO request, but the system should separately evaluate whether the drive reports the expected torque-disabled condition. Diagnostic feedback may include STO channel status, drive-ready information, inverter state, fault indication, or other validated status signals. Software should never assume successful torque removal merely because the request signal was transmitted.

Many safety drive architectures use redundant STO channels to tolerate certain single faults and detect wiring or interface failures. Software interacting with these channels must evaluate their consistency and expected timing relationship. A disagreement between redundant channels, unexpected transition, or persistent mismatch should be treated as a safety fault. Diagnostics should identify the abnormal condition without allowing application logic to bypass the required safe state.

Communication integrity becomes important when STO-related commands or status information are transferred through a safety network rather than dedicated hardwired inputs. The interface must detect stale messages, sequence errors, timeout, invalid safety status, and loss of communication. A network interruption must result in the defined safe behavior rather than leaving torque availability dependent on the last ordinary command received before communication was lost.

Timing requirements apply to the complete STO reaction chain. The safety analysis should account for input detection, safety-controller processing, communication delay, drive internal processing, power-stage disable time, and mechanical response. Although the drive may disable torque production rapidly, the robot can continue moving afterward because of stored kinetic or potential energy. Safety-distance calculations must therefore distinguish STO response time from the time required for the physical mechanism to reach a non-hazardous condition.

Power cycling and initialization require careful handling because STO status must be known before motion is enabled. During startup, the application controller should not assume that torque is available merely because communication with the drive has been established. The safety system must validate STO inputs, drive safety status, operating mode, feedback integrity, and other enabling conditions. Motion enable should occur only after the safety state machine confirms that release conditions have been satisfied.

Resetting STO must not itself initiate motion. Removal of the STO request should restore only the possibility of generating torque, not automatically execute a previous trajectory or reactivate a stored velocity or torque command. Restart logic should require valid safety conditions, appropriate acknowledgement where required, cleared faults, correct operating mode, and a controlled motion-enable sequence. Pending commands should be cancelled or revalidated before actuator movement resumes.

The application software still needs visibility of STO status even though it should not control the safety function directly. Motion planning, state estimation, task management, and diagnostics can use STO state to suspend trajectories, prevent command accumulation, update robot mode, and report system status. This supervisory integration improves system behavior while maintaining the architectural principle that ordinary application software cannot override or defeat an active STO condition.

Fault handling should cover both failures that request STO and failures within the STO interface itself. Examples include inconsistent redundant channels, missing drive confirmation, communication timeout, unexpected torque-enable status, invalid safety configuration, or failure during reset. Each condition requires a deterministic response and diagnostic classification. Safety-related faults should remain latched when necessary until the defined recovery procedure confirms that safe operation can resume.

Verification of the STO software interface should include normal activation, activation during motion, transitions from SS1 and other safety functions, redundant-channel faults, missing feedback, communication interruption, startup conditions, repeated requests, and reset attempts. Software-in-the-Loop (SIL) and Hardware-in-the-Loop (HIL) testing can verify state logic and timing, while physical tests confirm drive response, brake coordination, coast behavior, restart prevention, and actual mechanical consequences.

A robust STO software interface therefore combines independent safety activation, explicit state management, redundant or safety-rated signaling, drive confirmation, deterministic timing, brake coordination, fault diagnostics, and controlled restart. STO should be understood as removal of the actuator\'s torque-producing capability rather than guaranteed mechanical standstill. Correct integration ensures that higher-level safety functions can reliably transition the robot toward a defined safe condition without depending on ordinary motion-control software.

09.07 PROFIsafe / FSoE Safety Communication Layer [w/Code]

Safety communication enables safety-related control functions to exchange information across industrial networks without assuming that the underlying communication system is inherently safe. Protocols such as PROFIsafe and FailSafe over EtherCAT (FSoE) add a dedicated safety layer above standard communication mechanisms. This layer detects communication faults and allows distributed controllers, sensors, drives, and I/O devices to participate in safety functions while sharing the physical network with ordinary automation traffic.

The central design principle is the black-channel approach. The safety protocol does not require every switch, cable, interface controller, or underlying network protocol to provide safety integrity by itself. Instead, safety measures are implemented at the communicating endpoints, while the intermediate communication channel is treated as potentially unreliable. Safety telegrams contain additional information that enables receivers to detect corruption, repetition, loss, delay, incorrect sequencing, or delivery to an unintended participant.

PROFIsafe provides functional-safety communication for systems using PROFINET and, historically, PROFIBUS environments. Safety-related devices exchange PROFIsafe data through an additional protocol layer integrated into normal cyclic communication. A safety controller can therefore communicate with distributed safety I/O, drives, scanners, encoders, and other devices without requiring a physically separate network solely for safety traffic, provided the complete safety architecture satisfies its required integrity and timing constraints.

A PROFIsafe message includes safety-related mechanisms beyond the ordinary process data. These mechanisms typically include addressing information, sequence monitoring, watchdog supervision, and cyclic redundancy checking. Together they allow the receiver to determine whether received safety data belongs to the expected communication relationship and whether it is sufficiently current and intact. If these checks fail, the safety application receives a defined communication fault rather than silently accepting potentially corrupted information.

FSoE applies a comparable safety-layer concept to EtherCAT-based automation. Safety information is encapsulated within the normal EtherCAT communication infrastructure, while dedicated safety mechanisms operate between FSoE endpoints. This permits safety controllers, safe I/O modules, servo drives, and other EtherCAT devices to exchange safety-related information without requiring the underlying EtherCAT transport itself to perform every safety function associated with the transmitted data.

FSoE communication uses explicit safety relationships between communicating devices. Safety information includes mechanisms for identifying the connection, monitoring telegram progression, checking data integrity, and detecting timing violations. The receiving endpoint evaluates these elements before accepting the safety payload. Consequently, faults in the underlying transport can be detected at the safety layer, allowing the safety application to initiate its predefined reaction when valid communication can no longer be demonstrated.

PROFIsafe and FSoE therefore share an important architectural concept even though they operate within different industrial communication ecosystems. Both separate safety-related data validation from ordinary network transport and place safety responsibility primarily at validated endpoints. The network may carry both standard and safety traffic, but safety telegrams receive additional protection so that communication faults cannot simply transform corrupted process information into an accepted safety command.

From the robot software perspective, the safety communication layer should be separated logically from normal application messaging. Ordinary trajectory commands, telemetry, diagnostics, and configuration data can use standard communication services, while signals such as emergency stop, STO, SS1, SS2, SLS status, protective-device state, and safety acknowledgement pass through the appropriate safety communication mechanism. This separation preserves clear responsibility between functional communication and safety-related control.

Safety communication interfaces should expose both safety data and communication validity to the safety application. A received value is meaningful only when its associated safety connection is valid, timely, correctly sequenced, and free from detected integrity errors. Software should therefore avoid treating a Boolean safety signal as sufficient by itself. The safety state machine must also evaluate the validity state of the communication relationship from which that signal was obtained.

Watchdog supervision is essential because an unchanged but obsolete safety telegram can be as dangerous as corrupted data. Each safety connection operates with timing expectations that define how long valid information may remain unavailable before a fault is declared. The watchdog period must be selected as part of the overall safety reaction-time budget. Excessively long supervision increases the distance or duration of hazardous behavior that can occur before communication failure is recognized.

Sequence monitoring helps detect telegram loss, repetition, insertion, or incorrect ordering. The safety layer tracks expected communication progression and rejects information that does not satisfy the required sequence relationship. This is particularly important in cyclic control systems because a duplicated old command may otherwise appear structurally valid. Sequence information therefore contributes to establishing that the received safety data represents the intended current communication cycle.

Data integrity checking protects safety information against corruption during transmission or processing. Safety protocols use dedicated check values such as cyclic redundancy checks calculated over safety-relevant information and protocol fields. The receiver independently evaluates the check before accepting the telegram. A mismatch indicates that data integrity cannot be established, causing the connection to enter its defined fault behavior instead of forwarding uncertain information to the safety-control function.

Addressing and connection identification prevent safety information from being accepted by the wrong device or communication relationship. This protection is important in systems containing many similar drives, I/O modules, and robot axes. Configuration errors, duplicated device identities, or incorrectly routed information must not cause a safety command intended for one actuator to be interpreted by another. Safety addressing therefore becomes part of the validated system configuration and requires controlled engineering.

Communication faults must produce deterministic safety reactions. Loss of a valid PROFIsafe or FSoE connection should not leave the robot indefinitely operating with the last received safety value. Depending on the affected function, the system can transition to a fail-safe value, request SS1, activate STO, maintain a monitored stop, or enter another defined safe state. The selected response is determined by the hazard analysis and by the physical consequences of communication loss.

Distributed robot architectures require careful reaction-time analysis because communication contributes directly to the total safety response. The timing chain may include sensor acquisition, local safety processing, network transfer, remote safety logic, return communication to a drive, drive processing, and mechanical stopping. Network cycle time, watchdog configuration, jitter, processing latency, and fault-detection time must therefore be included when calculating stopping distance or validating protective separation.

Integration with servo drives is particularly important because many drive-based safety functions can be commanded or supervised through safety communication. A safety controller may exchange requests and status information for STO, SS1, SLS, or related functions with distributed drives. The application controller can observe these states for coordination, but it must not be able to override the safety relationship. Safety commands and confirmations remain governed by the validated safety communication path.

Startup, configuration changes, and reconnection require controlled state management. Establishing ordinary network communication does not automatically mean that the safety connection is valid. Safety parameters, device identities, connection states, watchdog configuration, and required initialization conditions must be verified before safety-related data is trusted. After communication interruption, the system should follow a defined recovery procedure rather than immediately restoring motion from previously active commands.

Verification of the safety communication layer should include normal cyclic operation, corrupted telegrams, lost messages, repeated data, sequence errors, communication delay, timeout, incorrect addressing, device restart, cable interruption, and recovery behavior. SIL and HIL environments can inject these faults systematically, while integrated robot testing confirms that detected communication failures produce the required drive and machine response within the validated reaction time.

PROFIsafe and FSoE ultimately provide a protected communication layer connecting distributed safety functions across standard industrial networks. Their effectiveness depends not merely on transporting safety bits but on continuously establishing message integrity, identity, sequence, freshness, and timing. Correct software integration combines endpoint validation, deterministic fault handling, controlled configuration, safety-state management, and reaction-time analysis so networked robot safety remains enforceable even when the underlying communication channel experiences faults.

09.08 Safety Control SW SIL / PL Verification Process

Safety control software verification establishes objective evidence that implemented safety functions satisfy their allocated Safety Integrity Level (SIL) or Performance Level (PL) requirements under normal, boundary, and fault conditions. The process is not limited to functional testing of nominal behavior. It verifies requirements, architecture, implementation, diagnostic coverage, timing, independence, fault reactions, and traceability across the complete safety-related software lifecycle.

The verification process begins with clearly defined safety requirements derived from hazard analysis and risk assessment. Each Safety Control Function (SCF), such as STO, SS1, SS2, SOS, SLS, SDI, or SLP, must have measurable activation conditions, monitored variables, response behavior, timing constraints, fault reactions, and reset conditions. These requirements form the reference against which architecture, software implementation, and verification results are evaluated.

SIL and PL represent related but distinct approaches to functional-safety integrity. SIL is commonly associated with IEC 61508 and sector-specific standards such as IEC 62061, whereas PL is defined within ISO 13849-1 for safety-related parts of control systems. Software verification must therefore be aligned with the safety standard, target integrity level, system architecture, and development lifecycle selected for the robot or machine.

Traceability provides the backbone of the verification process. Safety requirements should be linked to architectural elements, software requirements, implementation modules, test cases, test results, detected anomalies, and final verification evidence. Bidirectional traceability allows engineers to demonstrate that every safety requirement has been implemented and tested while also ensuring that safety-related software behavior exists for an identified and justified requirement.

Architecture verification examines whether safety responsibilities are correctly partitioned between application software, safety controllers, communication layers, sensors, and drives. Independence between ordinary control and safety supervision is particularly important. The analysis should determine whether a failure in trajectory generation, operating-system services, network communication, or application logic could improperly disable, override, or bypass the safety function.

Software requirements verification evaluates correctness, completeness, consistency, testability, and absence of ambiguity. Requirements should specify not only what the safety function does during normal operation but also its behavior when input information is invalid, communication is lost, redundant channels disagree, timing limits are exceeded, or initialization is incomplete. Undefined fault behavior can create safety gaps even when the nominal control algorithm is implemented correctly.

Detailed design verification evaluates state machines, interfaces, data flows, diagnostic mechanisms, parameter handling, timing logic, and failure transitions. Safety states should be explicit and transitions deterministic. Review activities should confirm that invalid combinations of states cannot accidentally enable motion and that safety-relevant parameters, such as speed limits, position limits, watchdog periods, and stopping thresholds, are protected and correctly applied.

Implementation verification addresses the actual source code and executable behavior. Static analysis, coding-rule checks, peer review, control-flow analysis, data-flow analysis, and interface inspection can identify defects before dynamic testing. Particular attention should be given to initialization, numerical limits, type conversions, overflow, concurrency, shared data, timeout handling, and error paths because these areas frequently contain faults that are difficult to expose through nominal functional testing alone.

Unit testing verifies individual safety-related software components against their detailed requirements. Tests should exercise valid inputs, invalid inputs, minimum and maximum values, boundary transitions, timing limits, and internal fault conditions. Where practical, structural coverage information can be used to identify implementation paths that have not been exercised. Uncovered safety-related logic should be justified or tested rather than assumed to be correct.

Software-in-the-Loop (SIL) testing allows safety algorithms and state logic to be exercised before physical hardware is available. Simulated sensors, drives, communication interfaces, and plant behavior can generate repeatable scenarios including overspeed, prohibited direction, boundary violation, encoder faults, and communication timeout. Automated SIL testing is especially useful for large regression suites because thousands of deterministic fault combinations can be executed efficiently.

Hardware-in-the-Loop (HIL) testing extends verification by executing the safety software with representative controllers, networks, I/O interfaces, or drive hardware while the robot dynamics are simulated. HIL can expose timing, synchronization, interface, and hardware-dependent problems that are difficult to reproduce in pure software simulation. Fault injection can include sensor disconnection, delayed communication, channel disagreement, device restart, corrupted status, and abnormal drive responses.

Fault-injection testing is central to demonstrating that diagnostic mechanisms and safe reactions operate as intended. The verification environment should intentionally introduce representative faults into sensors, communication paths, software states, configuration data, and hardware interfaces. The objective is not merely to observe that an error is reported, but to verify that the fault is detected within the required time and that the specified safe state or safety reaction is achieved.

Timing verification evaluates the complete safety reaction chain rather than only software execution time. Sensor acquisition, filtering, network transmission, safety-task scheduling, decision logic, drive processing, actuator response, and mechanical stopping may all contribute to total reaction time. Worst-case assumptions and measured results should be compared with the allocated timing budget because excessive latency can invalidate otherwise correct safety logic.

Diagnostic coverage verification examines whether dangerous failures are detected with sufficient effectiveness for the target safety architecture. Redundant sensors, plausibility checks, watchdogs, CRC mechanisms, sequence monitoring, cross-channel comparison, and internal self-tests contribute to fault detection. Verification should confirm not only that these diagnostics exist but that injected or representative failures actually activate them and produce the intended system response.

Integration testing verifies interactions among multiple safety functions. A robot may transition from SLS to SS1 and finally to STO, or an SLP violation may occur while SDI is already active. Tests should verify priorities, transition sequences, simultaneous requests, conflicting states, and recovery behavior. Safety functions that work correctly in isolation can still produce unsafe behavior when their state machines interact incorrectly at system level.

Reset, recovery, and restart behavior require dedicated verification because many hazardous situations occur during transitions back to operation. Clearing a fault or releasing STO should not automatically restart motion. Tests should verify manual acknowledgement where required, cancellation or revalidation of pending commands, restoration of valid sensor references, correct operating mode, and confirmation that all safety conditions are satisfied before motion enable is restored.

PL-oriented verification must consider the safety-related control architecture together with parameters such as category, diagnostic coverage, mean time to dangerous failure, and resistance to common-cause failures. Software evidence contributes to this assessment but does not independently establish the final PL. The achieved Performance Level depends on the complete safety-related parts of the control system, including hardware architecture, diagnostics, component reliability, and systematic measures.

SIL-oriented verification similarly requires evidence beyond software functional correctness. Systematic capability, architectural constraints, hardware failure measures, independence, lifecycle controls, verification rigor, and validation evidence contribute to demonstrating the required integrity. Software verification therefore operates within a broader functional-safety lifecycle in which requirements, implementation, hardware behavior, integration, and operational assumptions must remain mutually consistent.

Regression testing ensures that modifications do not invalidate previously verified safety behavior. Any change to source code, configuration, communication parameters, safety limits, drive firmware, hardware interfaces, or system architecture should trigger impact analysis. Affected verification activities are then repeated according to the identified scope. Automated regression environments are valuable because safety software often evolves while the required evidence must remain reproducible across versions.

Verification records should preserve test procedures, configurations, software versions, hardware versions, parameter sets, expected results, actual results, anomalies, corrective actions, and approval status. Reproducibility is essential because certification or independent assessment may require evidence that a particular released configuration was tested. Informal demonstrations are insufficient when the safety case depends on controlled and auditable verification results.

The completed SIL/PL verification process therefore combines requirement-based testing, architecture and code review, SIL and HIL simulation, fault injection, timing analysis, diagnostic verification, integration testing, regression control, and documented traceability. The objective is not simply to show that safety software works during expected operation, but to establish structured evidence that it detects relevant failures, responds deterministically, and supports the required safety integrity throughout the validated robot configuration.

09.09 Safety Computer Redundancy: Cross-Channel Compare [w/Code]

Safety computer redundancy is an architectural technique used to prevent a single processing fault from silently producing hazardous robot behavior. Two or more safety-processing channels independently evaluate safety inputs, execute safety logic, and generate safety-related results. Cross-channel comparison continuously checks whether these channels remain sufficiently consistent, allowing disagreement to be detected before an incorrect result can be accepted as a valid safety decision.

The fundamental principle is independence combined with comparison. Each channel should perform its assigned safety calculations without depending on the other channel for the correctness of its result. The outputs, intermediate states, or selected safety variables are then compared at defined synchronization points. Agreement permits continued safety operation, whereas significant disagreement indicates that at least one channel may be faulty and requires a predetermined safety response.

A dual-channel architecture commonly contains two processing paths, often identified as Channel A and Channel B. Each channel can receive redundant or independently validated sensor information, execute equivalent safety functions, and control or supervise safety-related outputs. Depending on the architecture, the channels may use identical processors and software or incorporate diversity to reduce susceptibility to common systematic faults. The selected structure must support the required safety integrity.

Cross-channel comparison can be performed on raw inputs, calculated values, safety states, output commands, or combinations of these quantities. Comparing only final Boolean outputs may fail to detect internal divergence until a hazardous decision occurs. Comparing selected intermediate variables can provide earlier fault detection. However, excessive comparison increases communication and synchronization complexity, so comparison points should be chosen according to safety significance and fault-detection objectives.

Synchronization is critical because two correct channels can temporarily produce different values if they evaluate data from different sampling instants. The architecture must therefore define when inputs are captured, when safety calculations execute, and when comparison occurs. Shared time bases, synchronized task cycles, sequence counters, or validated time windows can be used to establish comparable states. Timing tolerance must accommodate legitimate jitter without masking persistent computational disagreement.

Input redundancy must be coordinated with processing redundancy. Two safety computers receiving the same faulty sensor value can agree perfectly while making the same incorrect decision. Safety architectures may therefore use redundant sensing channels, plausibility checks, diverse measurement principles, or independent signal paths. Cross-channel comparison should evaluate not only processor outputs but also whether the information used by each processor provides sufficient independence and integrity.

The comparison logic requires explicitly defined tolerances. Discrete safety states may require exact agreement, whereas calculated velocity, position, torque, or timing values can differ slightly because of sampling, numerical precision, filtering, or asynchronous data arrival. Safety software must define acceptable comparison windows and deviation thresholds. These tolerances are safety-related parameters and should be justified, protected, version controlled, and verified under representative operating conditions.

A mismatch should not immediately be treated as a generic software error without context. The comparison mechanism should classify whether the discrepancy is transient, persistent, timing-related, input-related, computational, or associated with communication loss. Limited temporal filtering may prevent nuisance trips, but fault confirmation must remain within the allocated safety reaction time. The system must never extend mismatch tolerance so far that a dangerous disagreement can persist undetected.

When a confirmed cross-channel mismatch occurs, the safety architecture initiates a deterministic reaction appropriate to the hazard. The response may request Safe Stop 1 (SS1), Safe Stop 2 (SS2), Safe Operating Stop (SOS), or Safe Torque Off (STO), depending on the robot configuration and current operating state. The remaining apparently healthy channel should not automatically continue unrestricted operation unless the architecture explicitly supports and validates degraded single-channel operation.

Cross-monitoring communication itself must be treated as safety-relevant. Channel A and Channel B may exchange state vectors, counters, checksums, diagnostic information, or calculated safety values through dedicated memory, serial interfaces, shared buses, or internal communication links. The software must detect missing data, stale information, sequence errors, corruption, timeout, and repeated messages so communication failure cannot be misinterpreted as channel agreement.

Common-cause failure analysis is essential because redundancy does not provide the expected benefit when both channels can fail in the same manner from one cause. Shared power supplies, clocks, memory resources, communication interfaces, environmental conditions, software defects, configuration data, and development errors can defeat redundancy. Architectural design should identify these dependencies and apply separation, monitoring, diversity, or other measures where required by the safety integrity target.

Hardware diversity can reduce some common-cause vulnerabilities by using different processors, clock sources, power paths, or implementation technologies. Software diversity can similarly use independently developed implementations or different algorithms, although diversity introduces additional development and verification complexity. Identical redundant channels remain practical in many systems when systematic development controls, diagnostics, independence measures, and common-cause analysis provide adequate evidence.

Memory integrity is another important concern in redundant safety computers. Corrupted program memory, safety parameters, stack data, or runtime variables can cause incorrect calculations even when the processor itself operates normally. Memory tests, error-detecting or correcting mechanisms, protected configuration storage, range checks, and duplicated safety variables can support fault detection. Cross-channel comparison adds another layer by revealing inconsistent computational results caused by internal corruption.

Execution-flow monitoring verifies that each safety processor is running the intended software sequence. Watchdogs, task sequence monitoring, program-flow signatures, execution counters, and timing supervision can detect stalled tasks, unexpected branches, excessive execution time, or missing safety cycles. Cross-channel comparison should complement these local diagnostics rather than replace them, because two channels may fail differently before their final calculated outputs become visibly inconsistent.

Redundant output control must ensure that a single channel cannot independently create hazardous actuator behavior. Safety outputs can use dual-channel enable paths, redundant drive interfaces, or architectures in which both processors must satisfy defined conditions before torque or motion is permitted. For de-energize-to-safe designs, loss of one required enable path can force the output toward its safe condition. Feedback should confirm that the physical output state matches the commanded safety state.

Startup presents a special verification challenge because channel synchronization and internal diagnostics may not yet be complete. Each safety computer should perform initialization checks, memory tests, configuration validation, communication establishment, and synchronization before safety outputs are enabled. Cross-channel agreement must be established using validated current states rather than residual values from previous operation. Motion should remain inhibited until the redundant architecture is confirmed operational.

Recovery after a mismatch must also be controlled. A processor reset or restoration of communication should not automatically return the robot to normal operation. The system should identify the fault condition, reinitialize affected safety states, verify configuration and input validity, re-establish synchronization, confirm channel agreement, and perform any required manual acknowledgement. Pending motion commands should be cancelled or revalidated before safety authorization is restored.

Cross-channel comparison interacts directly with safety functions such as SLS, SDI, SLP, SS1, and STO. Both channels may independently calculate speed limits, directional validity, position boundaries, stopping states, and torque-disable requests. Comparing these safety-relevant results provides evidence that the redundant processors maintain a consistent understanding of robot safety state. A disagreement in any critical function should propagate into the system-level safety reaction strategy.

Verification must deliberately inject faults into both channels and their communication interfaces. Tests should include processor reset, corrupted variables, delayed execution, incorrect sensor values, clock deviation, message loss, sequence errors, memory faults, inconsistent configuration, and output disagreement. Software-in-the-Loop (SIL) and Hardware-in-the-Loop (HIL) environments allow these faults to be reproduced systematically while measuring detection coverage and reaction timing.

The verification process should also examine latent and simultaneous faults. A fault that remains undetected in one channel can reduce a redundant architecture to effectively single-channel operation until another fault occurs. Periodic diagnostics, proof tests, startup checks, and continuous comparison help minimize this exposure. Fault-injection testing should verify that latent faults are detected within the assumed diagnostic interval and that combinations of faults lead to the specified safe behavior.

A robust redundant safety-computer architecture therefore combines independent processing channels, synchronized execution, validated comparison points, safety-related tolerances, communication supervision, local diagnostics, common-cause mitigation, redundant outputs, and deterministic fault reactions. Cross-channel comparison transforms redundancy from simple duplication into an actively monitored safety mechanism, ensuring that disagreement is detected and managed before inconsistent computation can develop into hazardous robot motion.

09.10 Collaborative Robot Safety: ISO TS 15066 Case

Collaborative robot safety addresses applications in which humans and robots intentionally share a workspace or interact without the complete physical separation traditionally used around industrial robots. ISO/TS 15066 supplements the industrial robot safety framework by providing guidance for collaborative operation, including biomechanical considerations for human contact. Safety depends on the complete collaborative application rather than on the robot alone.

A collaborative robot installation must begin with application-specific risk assessment. The robot, end effector, workpiece, fixtures, surrounding equipment, human tasks, access directions, and foreseeable misuse all influence risk. A robot marketed as collaborative does not automatically make an application safe. Sharp tools, hot surfaces, heavy payloads, trapping points, or unstable workpieces can create hazards even when the robot itself includes advanced safety functions.

Collaborative operation is commonly organized around four methods: safety-rated monitored stop, hand guiding, speed and separation monitoring, and power and force limiting. These methods can be applied individually or combined according to the task. Their implementation requires safety-related sensing, control logic, validated robot functions, and appropriate system integration so that human access produces a predictable and sufficiently safe robot response.

Safety-rated monitored stop allows a human to enter the collaborative workspace while hazardous robot motion is stopped and monitored. The robot can remain powered, but the safety system ensures that prohibited motion does not occur while the person is exposed. When the operator leaves the monitored area and required restart conditions are satisfied, automatic operation may resume according to the validated control strategy without bypassing the safety function.

Hand guiding allows an operator to intentionally command robot motion through a hand-operated guiding device or suitable interface. The robot moves in response to deliberate human input while safety functions constrain parameters such as speed and motion. Emergency stopping and enabling functions remain important. Hand guiding should not be confused with manually pushing an uncontrolled robot; the commanded movement remains part of a defined safety-related operating mode.

Speed and separation monitoring maintains protective separation between the robot and a person while allowing both to move. Safety scanners, vision systems, position information, or other protective devices estimate the relative situation. As separation decreases, the robot can reduce speed and eventually stop before the required protective distance is violated. The calculation must consider robot motion, human approach, system reaction time, stopping time, and position uncertainty.

Protective separation is therefore a dynamic safety quantity rather than a fixed geometric boundary. A faster robot generally requires greater separation because it travels farther during sensing, processing, communication, and braking. Human approach speed and measurement uncertainty also contribute to the required distance. Safety software may continuously evaluate these parameters and transition among normal speed, reduced speed, controlled stop, and safe stopped states as conditions change.

Power and force limiting permits certain forms of intentional or incidental human-robot contact when the resulting biomechanical exposure remains within acceptable limits established by the risk assessment. Robot mass, effective inertia, velocity, geometry, contact area, force, pressure, and body location influence injury potential. Limiting motor torque alone is insufficient because the mechanical structure, payload, tool, and collision dynamics determine the actual contact experienced by a person.

ISO/TS 15066 provides biomechanical guidance including force and pressure information associated with different human body regions. These values are used within a risk-assessment and validation process rather than as universal robot settings. Contact type also matters. Transient contact can allow a person to recoil from an impact, whereas quasi-static contact can trap or clamp part of the body between the robot and another surface, requiring particularly careful hazard control.

Collision behavior should therefore be evaluated at the application level. Rounded robot surfaces may reduce local pressure, while narrow tools, workpiece edges, grippers, or fixtures can concentrate force onto a small area. A lightweight collaborative arm carrying a rigid pointed component can present a more severe contact hazard than suggested by robot specifications alone. Tool design and workstation geometry are consequently integral parts of collaborative safety engineering.

Safety-related speed monitoring supports both separation-based operation and power-and-force-limited applications. Joint encoders or independent sensing can provide velocity information to safety logic, which compares measured motion with validated limits. If the robot exceeds the permitted speed, a safety reaction such as SS1 or STO can be initiated. Speed limits may vary according to operating mode, workspace region, payload, tool, or detected human proximity.

Position monitoring can restrict the robot to validated collaborative regions and prevent entry into areas where crushing, trapping, or impact hazards are unacceptable. Safe Limited Position (SLP), safe axis ranges, or Cartesian workspace supervision can support these constraints. Position limits should include uncertainty and stopping margins because the robot continues to move during fault detection and deceleration. Mechanical reach and payload geometry must also be considered.

Safe Direction (SDI) can further reduce risk by preventing movement toward a person or hazardous structure during particular collaborative tasks. Combined with Safely Limited Speed (SLS), position supervision, and monitored stopping, directional constraints create context-dependent safety envelopes. The safety controller should manage these functions independently from ordinary trajectory planning so a failure in the application controller cannot remove the required protective restrictions.

Human detection systems must be evaluated according to their safety role. A conventional AI vision algorithm can support awareness or productivity but should not automatically be treated as a safety-rated protective sensor. When personnel detection is required to initiate or maintain a safety function, the sensing chain must provide appropriate safety integrity, diagnostic behavior, coverage, reaction time, and validated performance for the intended environmental conditions.

End effectors require dedicated analysis because human contact often occurs near the tool rather than the robot links. Grippers can create pinch and crushing hazards, while screwdrivers, cutters, welding devices, needles, or heated tools can introduce risks that cannot be controlled by robot force limitation alone. Safety design may require guarded tools, limited gripping force, passive compliance, restricted orientation, additional sensing, or task-specific separation.

Payload changes can alter collaborative safety performance by increasing effective mass, stopping distance, momentum, and collision energy. Safety parameters validated with one workpiece may therefore become invalid when payload mass, center of gravity, geometry, or tool configuration changes. The control system should manage validated configurations and prevent operation with safety parameters that do not correspond to the currently installed tool and payload.

Transitions between collaborative and non-collaborative modes require explicit state management. Production systems may operate at higher speed when no person is present and enter collaborative operation when access is detected. Safety logic must control these transitions, confirm protective conditions, apply appropriate speed or separation limits, and prevent automatic restoration of high-speed motion until all required conditions are satisfied. Mode information itself must be trustworthy.

Validation should measure the actual behavior of the integrated collaborative application. Tests can include stopping time and distance, safety-function activation, speed limits, position limits, sensor coverage, separation monitoring, contact force, contact pressure, reset behavior, and fault reactions. Measurements should represent relevant robot poses, payloads, speeds, tools, and contact locations because mechanical behavior can vary significantly throughout the robot workspace.

Fault testing remains essential even when normal collaborative behavior appears safe. Sensor loss, encoder disagreement, communication timeout, safety-controller faults, incorrect configuration, excessive speed, unexpected restart, and failure of a protective device should lead to defined safe reactions. SIL and HIL testing can verify software logic and timing, while physical validation confirms that the complete robot system reaches the required safe condition within the assumed response limits.

Documentation should connect the risk assessment, selected collaborative method, safety requirements, parameter values, robot and tool configuration, protective devices, verification results, and residual risks. Changes to payload, tooling, layout, safety software, firmware, or operating procedures require impact assessment because they may invalidate previous assumptions. Collaborative safety is therefore maintained through configuration control and lifecycle verification, not a one-time commissioning test.

A successful ISO/TS 15066 collaborative robot application integrates human factors, robot dynamics, functional safety, sensing, safety control software, mechanical design, and validation into one coordinated safety concept. The objective is not simply to make the robot move slowly near people, but to control separation, speed, position, direction, force, pressure, and fault response according to identified hazards so productive human-robot collaboration remains within validated safety boundaries.

---

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go