Industrial safety standards give formal constraints on how robot systems must be designed, implemented, and validated so that the probability and severity of harm remain acceptably low. At a high level, a standard specifies:

• What hazards must be considered (from Lesson 1).
• How to perform a systematic risk assessment (Lesson 2).
• How to design safety-related control functions (Lesson 3).
• How to demonstrate that the residual risk is acceptable over the life cycle.

Mathematically, let \( H \) denote the event that a hazardous harm occurs in an observation window \( [0,T] \). A safety standard implicitly requires that

\[ \Pr(H) \le \delta_{\text{target}}, \]

where \( \delta_{\text{target}} \) is a target risk bound determined by the application domain (e.g., industrial machinery vs. consumer robots).

We can also define a simple expected severity of harm:

\[ R = \mathbb{E}[S] = \sum_{i=1}^{m} p_i s_i, \quad p_i \ge 0,\ \sum_{i=1}^{m} p_i = 1, \]

where \( s_i \) is the severity level of outcome \( i \) (e.g., minor injury, severe injury, death) and \( p_i \) the corresponding probability. Many standards do not give exact numeric values for \( p_i \), but their tables and risk graphs can be interpreted as specifying qualitative upper bounds on these probabilities.

The standards ecosystem is hierarchical. Generic functional safety standards at the top (IEC 61508) are specialized by machinery standards (ISO 13849, IEC 62061), which in turn are specialized for industrial robots and collaborative operation (ISO 10218, ISO/TS 15066).

• IEC 61508: Generic functional safety of electrical/electronic/programmable electronic safety-related systems.
• ISO 12100: General principles of risk assessment and risk reduction for machinery.
• ISO 13849-1/-2: Safety-related parts of control systems, introduces Performance Levels (PL a–e).
• IEC 62061: Functional safety of safety-related control systems for machinery, uses Safety Integrity Levels (SIL).
• ISO 10218-1/-2: Safety requirements for industrial robots and robot systems.
• ISO/TS 15066: Guidance on collaborative robot operation (speed and separation, power and force limiting).

flowchart TD
  A["IEC 61508: generic functional safety"] --> B["ISO 13849: safety of machinery control parts"]
  A --> C["IEC 62061: machinery functional safety"]
  B --> D["ISO 10218-1: industrial robot safety"]
  B --> E["ISO 10218-2: robot cell integration"]
  D --> F["ISO/TS 15066: collaborative operation guidance"]
        

For a robot cell designer, the typical workflow is: use ISO 12100 to structure the risk assessment, then satisfy the probabilistic risk reduction requirements of ISO 13849 or IEC 62061, and finally check robot-specific requirements from ISO 10218 and ISO/TS 15066.

ISO 12100 structures risk assessment in terms of:

• \( S \): severity of harm,
• \( F \): frequency and duration of exposure,
• \( P \): probability of occurrence of a hazardous event,
• \( A \): probability of avoiding or limiting harm.

In practice these are ordinal categories (e.g., S1 vs. S2, F1 vs. F2), not precise numbers. For analysis, we can embed them into numerical scales \( S,F,A \in \{1,2,\dots\} \) with positive weights \( w_S, w_F, w_A > 0 \). A simple risk index is

\[ R_{\text{index}} = w_S S + w_F F + w_A A. \]

Standards often map combinations of severity, frequency, and avoidance difficulty to qualitative risk categories (e.g., low/medium/high). In our numeric embedding we can define thresholds \( \theta_1 < \theta_2 < \theta_3 \) and classify

\[ \begin{aligned} R_{\text{index}} \le \theta_1 &\Rightarrow \text{Low}, \\ \theta_1 < R_{\text{index}} \le \theta_2 &\Rightarrow \text{Medium}, \\ \theta_2 < R_{\text{index}} \le \theta_3 &\Rightarrow \text{High}, \\ R_{\text{index}} > \theta_3 \Rightarrow \text{Unacceptable}. \end{aligned} \]

The goal of introducing safety functions (guards, emergency stops, safety PLCs) is to reduce the residual risk index \( R_{\text{residual}} \) below an acceptable boundary:

\[ R_{\text{unmitigated}} - R_{\text{residual}} \ge R_{\text{required-reduction}}. \]

To connect this with probabilistic safety, define a risk reduction factor:

\[ \text{RRF} = \frac{\Pr(H_{\text{unmitigated}})}{\Pr(H_{\text{residual}})}, \]

where \( H_{\text{unmitigated}} \) and \( H_{\text{residual}} \) are hazardous harm events before and after safety measures. Standards like IEC 61508 and ISO 13849 essentially specify the minimum acceptable RRF for each Safety Integrity Level (SIL) or Performance Level (PL).

IEC 61508 models safety-related subsystems using reliability theory. Consider a single-channel safety function with dangerous undetected failures occurring according to a Poisson process with rate \( \lambda_{\text{DU}} \). Let \( T_{\text{fail}} \) be the time to a dangerous undetected failure. Then

\[ T_{\text{fail}} \sim \text{Exp}(\lambda_{\text{DU}}), \quad R(t) = \Pr[T_{\text{fail}} > t] = e^{-\lambda_{\text{DU}} t}, \]

and the cumulative distribution function is

\[ F(t) = \Pr[T_{\text{fail}} \le t] = 1 - e^{-\lambda_{\text{DU}} t}. \]

For low-demand safety functions, IEC 61508 uses the average probability of dangerous failure on demand:

\[ \text{PFD}_{\text{avg}} = \frac{1}{T} \int_{0}^{T} \Pr[\text{dangerous failure present at } t]\,dt. \]

If we proof-test the channel every \( T \) hours and assume at most one dangerous failure per interval (small failure rate), the failure probability grows approximately linearly from 0 to \( \lambda_{\text{DU}} T \). Thus

\[ \text{PFD}_{\text{avg}} \approx \frac{1}{T} \int_{0}^{T} \lambda_{\text{DU}} t \, dt = \frac{\lambda_{\text{DU}} T}{2}, \quad \text{when } \lambda_{\text{DU}} T \ll 1. \]

For high-demand or continuous-mode safety functions, IEC 61508 uses the probability of dangerous failure per hour:

\[ \text{PFH} \approx \lambda_{\text{DU}}. \]

SIL levels are defined by intervals of PFD_avg (low demand) or PFH (high demand). For example, one of the low-demand SIL ranges is of the form

\[ 10^{-3} \le \text{PFD}_{\text{avg}} < 10^{-2}. \]

The higher the SIL, the smaller the allowed probability of dangerous failure and the larger the required risk reduction factor.

flowchart TD
  H["Hazard identified in ISO 12100"] --> RISK["Quantify target risk reduction (RRF)"]
  RISK --> CH["Choose architecture (1oo1, 1oo2, etc.)"]
  CH --> REL["Compute lambda_DU, PFD_avg, PFH"]
  REL --> SIL["Assign SIL/PL that meets target"]
  SIL --> VER["Verify via analysis + testing"]
        

From a control perspective, safety standards can be interpreted as requiring invariance of a safe set under closed-loop dynamics, up to rare failures. Let the robot state follow

\[ \dot{x}(t) = f(x(t),u(t)), \quad x(t) \in \mathbb{R}^n. \]

Define a safe set

\[ \mathcal{X}_{\text{safe}} = \{ x \in \mathbb{R}^n : h(x) \ge 0 \}, \]

where \( h(x) \) encodes constraints such as joint limits, contact forces, and minimum human–robot distance. A safety function (implemented by a safety PLC, safety-rated controller, or hardware interlocks) strives to enforce:

\[ x(0) \in \mathcal{X}_{\text{safe}} \ \Rightarrow\ x(t) \in \mathcal{X}_{\text{safe}}\ \text{for all } t \in [0,T] \quad \text{with probability } \ge 1 - \delta_{\text{target}}. \]

In linear control, you have seen Lyapunov-level sets \( \{ x : V(x) \le c \} \). If we choose \( V(x) = x^{\top} P x \) with \( P \succ 0 \) and a closed-loop linear system \( \dot{x} = A_{\text{cl}} x \), then

\[ \dot{V}(x) = x^{\top} (A_{\text{cl}}^{\top} P + P A_{\text{cl}}) x. \]

If \( A_{\text{cl}}^{\top} P + P A_{\text{cl}} \preceq 0 \), the level set \( \{ x : V(x) \le c \} \) is forward invariant. Safety standards like ISO 10218 then add additional constraints on measured quantities (speed, force, distance) and require that safety functions force the system into a designated safe region (e.g., torque-free, motor power off) whenever these constraints are violated.

Here we sketch how a simple safety monitor enforcing a speed-and-distance limit (as in ISO/TS 15066) could be implemented conceptually. We assume a topic or API that provides:

• speed: current end-effector speed (m/s),
• distance: minimum human–robot distance (m),
• command_estop(): triggers a category 0 or 1 stop.

6.1 Python (ROS 2 with rclpy)

import rclpy
from rclpy.node import Node

SAFE_DISTANCE = 0.8  # meters (example only)
SPEED_LIMIT = 0.25   # m/s

class SafetyMonitor(Node):
    def __init__(self):
        super().__init__("safety_monitor")
        self.speed = 0.0
        self.distance = float("inf")

        self.create_subscription(
            Float64, "/robot/speed", self.speed_callback, 10
        )
        self.create_subscription(
            Float64, "/human/distance", self.distance_callback, 10
        )
        self.estop_pub = self.create_publisher(Bool, "/safety/estop", 10)
        self.create_timer(0.01, self.check_safety)  # 100 Hz monitor

    def speed_callback(self, msg):
        self.speed = msg.data

    def distance_callback(self, msg):
        self.distance = msg.data

    def check_safety(self):
        # This simple rule mimics a subset of ISO/TS 15066 style thinking:
        # if human is close AND speed is high, stop.
        if self.distance <= SAFE_DISTANCE and self.speed > SPEED_LIMIT:
            self.get_logger().warn("Safety violation detected, triggering E-STOP")
            self.estop_pub.publish(Bool(data=True))

def main():
    rclpy.init()
    node = SafetyMonitor()
    rclpy.spin(node)
    rclpy.shutdown()

if __name__ == "__main__":
    main()
      

6.2 C++ (ROS 2 with rclcpp)

#include <rclcpp/rclcpp.hpp>
#include <std_msgs/msg/float64.hpp>
#include <std_msgs/msg/bool.hpp>

using std::placeholders::_1;

class SafetyMonitor : public rclcpp::Node {
public:
    SafetyMonitor()
    : Node("safety_monitor"), speed_(0.0), distance_(1e9)
    {
        speed_sub_ = this->create_subscription<std_msgs::msg::Float64>(
            "/robot/speed", 10,
            std::bind(&SafetyMonitor::speedCallback, this, _1));

        dist_sub_ = this->create_subscription<std_msgs::msg::Float64>(
            "/human/distance", 10,
            std::bind(&SafetyMonitor::distanceCallback, this, _1));

        estop_pub_ = this->create_publisher<std_msgs::msg::Bool>("/safety/estop", 10);

        using namespace std::chrono_literals;
        timer_ = this->create_wall_timer(
            10ms, std::bind(&SafetyMonitor::checkSafety, this));
    }

private:
    void speedCallback(const std_msgs::msg::Float64::SharedPtr msg) {
        speed_ = msg->data;
    }

    void distanceCallback(const std_msgs::msg::Float64::SharedPtr msg) {
        distance_ = msg->data;
    }

    void checkSafety() {
        const double SAFE_DISTANCE = 0.8;
        const double SPEED_LIMIT  = 0.25;
        if (distance_ <= SAFE_DISTANCE && speed_ > SPEED_LIMIT) {
            RCLCPP_WARN(this->get_logger(), "Safety violation, triggering E-STOP");
            std_msgs::msg::Bool msg;
            msg.data = true;
            estop_pub_->publish(msg);
        }
    }

    double speed_;
    double distance_;
    rclcpp::Subscription<std_msgs::msg::Float64>::SharedPtr speed_sub_;
    rclcpp::Subscription<std_msgs::msg::Float64>::SharedPtr dist_sub_;
    rclcpp::Publisher<std_msgs::msg::Bool>::SharedPtr estop_pub_;
    rclcpp::TimerBase::SharedPtr timer_;
};

int main(int argc, char ** argv) {
    rclcpp::init(argc, argv);
    rclcpp::spin(std::make_shared<SafetyMonitor>());
    rclcpp::shutdown();
    return 0;
}
      

6.3 Java (Vendor or Middleware API)

Industrial robots often expose Java APIs in vendor SDKs or via industrial middleware. The following simplified example assumes a high-level API:

public class SafetyMonitor implements Runnable {

    private final RobotInterface robot;
    private final HumanTracker tracker;
    private static final double SAFE_DISTANCE = 0.8;
    private static final double SPEED_LIMIT   = 0.25;

    public SafetyMonitor(RobotInterface robot, HumanTracker tracker) {
        this.robot = robot;
        this.tracker = tracker;
    }

    @Override
    public void run() {
        while (true) {
            double speed = robot.getEndEffectorSpeed();
            double distance = tracker.getMinHumanDistance();

            if (distance <= SAFE_DISTANCE && speed > SPEED_LIMIT) {
                System.out.println("Safety violation detected, stopping robot.");
                robot.commandEmergencyStop();
            }

            try {
                Thread.sleep(10); // 100 Hz
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                break;
            }
        }
    }
}
      

6.4 MATLAB/Simulink (Analytical Safety Metrics)

MATLAB can be used to compute PFD_avg and PFH from failure rates estimated by reliability data. This connects directly to IEC 61508 calculations.

% Dangerous undetected failure rate (per hour)
lambda_DU = 1e-6;    % example value
T = 8760;            % proof test interval: 1 year in hours

% Approximate IEC 61508 low-demand formula
PFD_avg = lambda_DU * T / 2;

% Continuous mode PFH approximation
PFH = lambda_DU;

fprintf("PFD_avg = %.4g\n", PFD_avg);
fprintf("PFH     = %.4g failures per hour\n", PFH);

% In Simulink, these calculations can be implemented via Gain and Integrator
% blocks, and the resulting PFD_avg compared against SIL/PL target thresholds.
      

In Simulink, safety logic (e.g., speed-and-separation monitoring) is typically implemented as a subsystem combining relational operators (for inequalities), logical operators (AND/OR), and state machines (e.g., Stateflow) to handle transitions between Run, Slow, and Safe Stop states according to ISO 10218 and ISO/TS 15066.

In this lesson we connected industrial safety standards for robots to quantitative models of risk, reliability, and invariance. We saw how ISO 12100 structures risk assessment using severity, exposure, and avoidance parameters, how ISO 13849 and IEC 61508 turn qualitative risk reduction targets into probabilistic limits on dangerous failures (PFD_avg, PFH), and how control-theoretic safe sets offer a compact mathematical representation of the states permitted by ISO 10218 and ISO/TS 15066. The implementation sketches demonstrated how simple safety monitors can be realized in Python, C++, Java, and MATLAB/Simulink, anticipating more advanced safety-critical control design in later courses.