ISO 10218:2025 Explained: The New Industrial Robot Safety Standard

ISO 10218-1:2025 and ISO 10218-2:2025 replace the 2011 editions. Every integrator, OEM, and end user who ships or modifies a robot cell now works against a different document set. The 2025 revision is the first major rewrite in 14 years. It absorbs ISO/TS 15066, adds cybersecurity clauses, introduces robot classes, and shifts the object of assessment from the “robot system” to the “robot application.” This guide covers what changed, what it means for your safety-function design, and how to prototype the core calculations in code.

Quick Takeaways

• Two parts, new editions. Part 1 (3rd edition, ~95 pages) governs the robot. Part 2 (2nd edition, ~223 pages) governs the application and cell.
• ISO/TS 15066 is absorbed. Collaborative requirements, including power and force limiting (PFL), now live inside the main standard. Most sit in Part 2.
• Functional safety is explicit. The blanket “PL d, Category 3” habit gives way to requirements tied to each safety function and robot class.
• New attack surface. Cybersecurity and protection of safety-related parameters are now normative topics.

Why the Revision Happened

Robots changed faster than the standard. By 2025, collaborative arms were common on production floors, vision-guided cells reconfigured themselves, and safety controllers sat on Ethernet. The 2011 text, patched by ISO/TS 15066 and two technical reports, left integrators stitching together four documents. ISO 10218:2025 puts the requirements in one place and makes implied obligations explicit.

North American users should note that ANSI/A3 R15.06-2025 adopts both parts nationally. A third part, R15.06-3, adds end-user requirements with no ISO counterpart. In the EU, the EN ISO versions are the route to a presumption of conformity under the Machinery Directive. Publication of the references in the Official Journal has been reported for September 2026, so confirm the current harmonisation status before you rely on it.

Part 1 vs. Part 2: Who Owns What

Robot Classes: Class I and Class II

Part 1 sorts robots into Class I and Class II. The class depends on total mass per manipulator, maximum force per manipulator, and maximum speed. A small, low-force arm designed for shared workspaces lands in a different class than a heavy, fast palletizer. Each class carries its own functional-safety requirements and test methods.

The practical result: stop asking “which PL does the standard demand?” and start asking “which class is this manipulator, and which safety function am I specifying?” Pull the exact thresholds from the standard text, because they drive your hardware selection.

Functional Safety: Specify per Function

The 2011 edition pushed most designers toward PL d with Category 3 for every safety function. The 2025 edition allows a more differentiated treatment based on actual risk. It also states numeric expectations in places. One example is a note tying certain architectures to DC_avg > 90% and MTTF_D > 62 years.

For each safety function, document:

1. Trigger (light curtain break, laser scanner zone, speed limit exceeded)
2. Reaction (protective stop, safe torque off, safe speed limit)
3. Response time (includes sensing, logic, and actuation)
4. Required performance level and the architecture meeting it
5. Validation evidence (test records, not just calculations)

Safety-Function Parameters

New requirements protect numerical settings such as speed limits, stopping distances, and detection zones:

• Only authorized persons may change them.
• A change forces a restart or re-validation.
• Changes are logged automatically (a checksum is a common mechanism).
• No changes while the robot runs in automatic mode.

If your safety PLC lets any logged-in engineer edit a zone at runtime, you have a compliance gap.

Collaborative Operation After ISO/TS 15066

The four collaborative techniques from 2011 carry forward under revised naming:

Protective Separation Distance (SSM)

The distance formulation, as used in ISO/TS 15066 and carried into the revision, is:

S_p = S_h + S_r + S_s + C + Z_d + Z_r

S_h = K_h * (T_r + T_s)     # human travel during robot reaction + stopping time
S_r = v_r * T_r             # robot travel during reaction time
S_s = stopping distance of the robot (from its stop data)
C   = intrusion distance (how far a body part reaches before detection)
Z_d = position uncertainty of the sensing system
Z_r = position uncertainty of the robot
K_h = assumed human approach speed (commonly 1.6 m/s in ISO 13855-based work)

Verify every constant against the current text before you ship a design.

Permissible Speed Under PFL

For transient contact, the maximum relative speed follows from the allowable force F_max for a body region:

v_rel_max = F_max / sqrt(k * mu)

mu  = 1 / (1/m_H + 1/m_R)    # two-body reduced mass
m_R = M/2 + m_L              # effective robot mass: half arm mass plus payload
k   = effective spring constant of the body region (N/mm, converted to N/m)

The effective mass m_R depends on arm pose and payload. Recompute it at the worst-case configuration, not the home pose.

Sensor and Controller Choices for 2025 Compliance

Values are typical ranges. Take real response times from datasheets, because they feed T_r directly.

Prototype: SSM Distance Check in ROS 2

This node computes the protective separation distance and flags a violation. It is a prototyping aid, not a safety-rated function. Real safety functions run on certified safety hardware.

#!/usr/bin/env python3
# ssm_monitor.py - Speed and Separation Monitoring prototype (ROS 2 Humble+)
# NOT a safety-rated implementation. Use for simulation and design studies only.

import rclpy
from rclpy.node import Node
from std_msgs.msg import Float64, Bool


class SSMMonitor(Node):
    def __init__(self):
        super().__init__('ssm_monitor')

        # Parameters (declare so they can be overridden in a launch file)
        self.declare_parameter('k_h', 1.6)    # human approach speed [m/s]
        self.declare_parameter('t_r', 0.10)   # robot reaction time [s]
        self.declare_parameter('t_s', 0.20)   # robot stopping time [s]
        self.declare_parameter('s_s', 0.15)   # robot stopping distance [m]
        self.declare_parameter('c', 0.20)     # intrusion distance [m]
        self.declare_parameter('z_d', 0.10)   # sensor position uncertainty [m]
        self.declare_parameter('z_r', 0.02)   # robot position uncertainty [m]

        self.v_robot = 0.0       # latest TCP speed [m/s]
        self.separation = 99.0   # latest measured human-robot distance [m]

        # Inputs: scanner-derived distance and robot TCP speed
        self.create_subscription(Float64, '/human_distance', self.on_distance, 10)
        self.create_subscription(Float64, '/tcp_speed', self.on_speed, 10)

        # Output: True means the robot must stop (protective stop request)
        self.pub = self.create_publisher(Bool, '/protective_stop', 10)

        # Evaluate at 100 Hz
        self.create_timer(0.01, self.evaluate)

    def on_distance(self, msg: Float64):
        self.separation = msg.data

    def on_speed(self, msg: Float64):
        self.v_robot = msg.data

    def evaluate(self):
        p = lambda n: self.get_parameter(n).value
        s_h = p('k_h') * (p('t_r') + p('t_s'))   # human travel term
        s_r = self.v_robot * p('t_r')            # robot travel in reaction time
        s_p = s_h + s_r + p('s_s') + p('c') + p('z_d') + p('z_r')

        violation = self.separation < s_p        # inside protective distance
        self.pub.publish(Bool(data=violation))

        if violation:
            self.get_logger().warn(
                f'S_p={s_p:.3f} m > separation={self.separation:.3f} m'
            )


def main():
    rclpy.init()
    rclpy.spin(SSMMonitor())
    rclpy.shutdown()


if __name__ == '__main__':
    main()

Run and test it:

ros2 run my_safety_pkg ssm_monitor
ros2 topic pub /human_distance std_msgs/msg/Float64 "{data: 0.5}" --rate 10
ros2 topic pub /tcp_speed std_msgs/msg/Float64 "{data: 0.8}" --rate 10
ros2 topic echo /protective_stop

Cybersecurity and Safety

ISO 10218-1:2025 and -2:2025 add cybersecurity requirements “to the extent they apply to robot safety.” The Part 2 text introduces a cybersecurity threat assessment and requires unauthorized-access prevention when a threat could compromise a safety function. Treat this as a design input, not an IT afterthought:

• Segment the safety network from the plant network.
• Disable unused services on the robot controller and safety PLC.
• Require authentication for safety configuration tools.
• Log every safety-parameter change with user and timestamp.
• Version-control safety configuration files and store a checksum.

Practical Workflow: Migrating an Existing Cell to ISO 10218:2025

Scenario: a 6-axis arm tending a CNC machine, built to the 2011 edition, now getting a new gripper and a larger workspace.

1. Decide whether the change is significant. Modifications that alter risk can trigger a new conformity assessment against the current state of the art.
2. Define the robot application. List the robot, end effector, workpiece, task program, and peripheral machines. The 2025 edition assesses all of it together.
3. Classify the manipulator under Part 1 using its mass, force, and speed data from the manufacturer.
4. Rerun the risk assessment. Part 2’s hazard list is much longer than the old one, so use it as your checklist.
5. Assign functional-safety requirements per safety function and map each to a validated architecture.
6. Run the collaborative calculations (S_p, v_rel_max) at worst-case pose and payload.
7. Lock down safety parameters and add change logging.
8. Add maintenance provisions, including how to move the arm without drive power.
9. Validate with measurements: stopping distance tests, force and pressure measurements for any contact, and response-time tests.
10. Document the technical file and the information for use.

Common Integrator Mistakes

• Reusing a 2011 risk assessment without checking the extended hazard list.
• Treating the cobot as “safe by itself.” The application (sharp tool, hot workpiece) sets the hazard, not the arm.
• Using home-pose effective mass in PFL calculations.
• Ignoring sensor uncertainty terms Z_d and Z_r in SSM.
• Leaving safety configuration unprotected on a networked controller.

FAQ

Does ISO 10218:2025 replace ISO/TS 15066?

Largely, yes. The collaborative-application requirements, including power and force limiting, now sit inside ISO 10218-1 and -2, mostly in Part 2. ISO/TS 15066:2016 remains a published document, but the 2025 text is the reference for new designs.

What is the difference between ISO 10218-1 and ISO 10218-2?

Part 1 sets design requirements for the industrial robot itself: its controls, modes, stops, and built-in safety functions. Part 2 sets requirements for integrating that robot into an application or cell, including safeguarding, commissioning, and maintenance.

Do I need to upgrade existing robot cells to ISO 10218:2025?

Existing cells are not automatically non-compliant. When you modify or extend a cell in a way that changes risk, the 2025 edition becomes the state of the art, and a new conformity assessment may be needed. Check with your notified body or safety consultant for your jurisdiction.

Does ISO 10218:2025 include cybersecurity requirements?

Yes. Both parts add cybersecurity clauses limited to threats that affect robot safety. Part 2 requires a threat assessment and measures preventing unauthorized access to safety functions and safety-related parameters.