The most expensive mistake in cobot deployment is treating the robot’s collaborative rating as a property of the arm alone. A cobot with power and force limiting can be deployed without a fence, but only if every other element in the workcell—the end effector, the workpiece, the mounting surface, the operator’s approach path, and the speed settings—has been evaluated as a complete application. The current revision of ISO 10218 makes this explicit by shifting the language from “collaborative robot” to “collaborative application,” a change that reflects a practical reality: a safe arm mounted with a sharp gripper and programmed at full speed is not safe, regardless of what the datasheet says.

This article explains what safe cobot deployment actually requires, where the standards draw the line, and what commonly goes wrong between the risk assessment and the production floor. For broader coverage of robot operations and deployment practices, see RobotsOps.com.

What the Standards Actually Require

The ISO 10218 series is a type-C standard, meaning it addresses hazards specific to machinery when used as intended. Part 1 covers the robot as partly completed machinery. Part 2 covers the integration of the robot into a complete application, including commissioning, operation, maintenance, and decommissioning.

The current revision incorporated the content of ISO/TS 15066, the technical specification that previously governed collaborative robot applications, into Part 2. This consolidation matters for deployment because it removes the ambiguity about which document governs which decision. The safety functions that enable collaborative operation—whether they are built into the robot or provided by protective devices—are now addressed within a single framework that evaluates the application as a whole.

One consequence of this framing: there is no such thing as a “collaborative robot” in the standards’ language. Only an application can be validated as collaborative. A cobot deployed in a cell where a human never enters during operation is not a collaborative application in the standards’ sense, even if the arm has collaborative safety functions. The deployment decision must start from the task and the workspace, not from the robot’s classification.

The Risk Assessment Is Not a Formality

A risk assessment for a cobot application follows the general machinery safety methodology of ISO 12100, applied to the specific hazards that human-robot proximity creates. The output is not a checkbox but a set of decisions about speed limits, force thresholds, separation distances, and whether additional safeguards are necessary.

The hazards specific to cobot applications include impact, clamping, and crushing. The assessment must evaluate both quasi-static forces (sustained pressure, as when an arm pins a hand against a surface) and transient forces (impact from a moving arm). The permissible limits are derived from biomechanical research on pain thresholds and injury onset, with values that vary by body region. A gripper that contacts a forearm is evaluated differently from the same gripper contacting a face or neck.

The practical implication is that the risk assessment must be performed with the actual end effector, the actual workpiece, and the actual operator positions. A generic assessment that covers “a cobot” without specifying these details produces no defensible safety decision.

The Four Collaborative Operation Modes, and What They Do Not Guarantee

The standards recognize several techniques for enabling collaborative operation, commonly described as safety-rated monitored stop, hand guiding, speed and separation monitoring, and power and force limiting. Each imposes different requirements and different constraints on the deployment.

Safety-rated monitored stop is the most conservative. The robot stops when a person enters the collaborative workspace, and the stop state is monitored. This is appropriate when the operator needs to perform a task inside the robot’s workspace while the robot is stationary. It is not a technique that allows simultaneous motion.

Hand guiding allows the operator to move the robot directly. The safety requirement is not merely that the robot can be moved by hand, but that the system includes appropriate safety functions for the guided motion—force limits, speed limits, and a monitored enabling device.

Speed and separation monitoring (SSM) uses safety-rated sensors to maintain a protective separation distance. The robot’s speed scales with the distance to the operator, and the robot stops if the distance falls below a minimum threshold. This is the technique that most clearly depends on the environment: a laser scanner that works in a clean, unobstructed cell may generate nuisance stops in a workspace with reflective surfaces, airborne particulate, or changing lighting.

Power and force limiting is the technique most associated with the “no fence” cobot deployment. The robot is designed or configured so that any contact with a person does not exceed the biomechanical limits established in the risk assessment. This is where the common misperception is most dangerous: power and force limiting does not mean the robot cannot injure a person. It means the application has been configured—with specific speed, payload, end effector, and contact geometry—so that the risk assessment concludes the force and pressure limits are not exceeded for the foreseeable contacts.

A Deployment Sequence That Respects the Standards

The sequence below reflects the order of decisions that the ISO 10218 series implies. Deviating from this order—for example, selecting the robot before defining the task—creates rework and can produce an application that cannot be validated.

Step 1: Define the collaborative task in operational terms. Specify what the human does, what the robot does, where they are at each phase of the cycle, and whether their work overlaps in time or only in space. A task where the human loads a fixture while the robot is stationary is a different safety problem from a task where the human and robot work simultaneously in the same volume.

Step 2: Select the end effector and workpiece before the robot. The hazards that matter are created by the tool and the payload, not by the arm alone. Sharp edges, hot surfaces, pointed tools, and heavy workpieces eliminate the possibility of unguarded proximity regardless of the robot’s collaborative functions. If the end effector requires a guard, the collaborative capability of the arm becomes secondary.

Step 3: Perform the risk assessment with the complete application. Document the hazards, estimate the severity and probability of each, and identify the risk reduction measures. The assessment must cover the intended use and reasonably foreseeable misuse, including maintenance access and fault recovery. Risk assessment guidance for power-and-force-limited robots emphasizes that the assessment must include both quasi-static and transient force evaluations for the specific contact scenarios the application creates.

Step 4: Configure the safety functions and validate them. Set the speed and force limits derived from the risk assessment. Then test them. Validation is not the same as configuration: a speed limit that is set in software but not verified with a measurement device is an assumption, not a control. Impact measurement devices with human-like mechanical properties exist for exactly this purpose, and the validation should confirm that the actual forces at contact remain within the assessed limits.

Step 5: Address the environment and the sensors. Safety scanners, vision systems, and force sensors are sensitive to conditions that a lab test does not reproduce. Airborne particulate, oil mist, and ambient lighting changes can cause nuisance stops or, worse, reduce detection reliability. The deployment plan must include environmental controls or sensor selection appropriate to the actual workspace.

Step 6: Document the limits of the assessment. Every risk assessment has boundaries. The ISO 10218-2 scope explicitly excludes certain conditions—extreme climates, explosive environments, hygienic requirements, and handling of hazardous materials such as molten metal or acids—unless they are addressed separately. State what the assessment covers and what it does not. This protects both the integrator and the operator when the application changes.

What Goes Wrong in Practice

Treating the robot datasheet as a safety certificate. A cobot rated for power and force limiting is certified as a partly completed machine. Its collaborative safety functions are inputs to the application risk assessment, not a conclusion. Deployments that skip the application-level assessment produce cells that look compliant and are not.

Ignoring the end effector. The robot arm may be blunt and lightweight. The gripper holding a machined part may not be. Sharp tooling, pointed payloads, and hazardous dispensers create hazards that the arm’s collaborative functions were never designed to mitigate.

Configuring speed limits without validating contact forces. The risk assessment produces force and pressure limits. The deployment must verify that the configured speed, payload, and motion profile actually keep contacts within those limits. Without measurement, the configuration is a guess.

Neglecting cybersecurity. The ISO 10218 series added requirements for cybersecurity, including port hardening, detection of unauthorized configuration changes, and network segmentation. A cobot connected to a plant network without these controls is exposed to configuration changes that could alter its safety behavior. The safety case must include the security of the safety configuration.

How to Verify the Deployment Is Safe

Verification has three layers. First, confirm that the risk assessment covers the actual application—the specific end effector, workpiece, operator positions, and foreseeable misuse. Second, confirm that the safety functions are configured as the assessment requires and that the configuration is protected from unauthorized change. Third, confirm by measurement that the actual forces and pressures at contact remain within the assessed limits for the contact scenarios identified.

The operational metric that matters is not the number of safety functions enabled. It is whether the application can be operated, maintained, and recovered from faults without a person being exposed to a hazard that the assessment did not cover. Walk through the maintenance procedure, the fault recovery procedure, and the cleaning procedure with the same rigor as the production cycle.

Frequently Asked Questions

Q1. Can a cobot be deployed without a safety fence?
Yes, but only if the application-level risk assessment concludes that the collaborative safety functions, end effector, and workspace design eliminate or adequately control the hazards. The robot’s collaborative rating is a necessary input, not a sufficient condition. Many applications still require fencing or light curtains because of the tooling or the task.

Q2. What is the difference between a collaborative robot and a collaborative application?
A collaborative robot is an arm with safety functions that can enable collaborative operation. A collaborative application is a complete system—robot, end effector, workpiece, environment, and task—that has been assessed and validated as safe for human-robot interaction. The ISO 10218 series uses the latter term because only the application can be validated.

Q3. What changed in the latest revision of ISO 10218?
The latest revision incorporated ISO/TS 15066 into Part 2, added cybersecurity requirements, and shifted the language from “collaborative robot” to “collaborative application.” It also expanded the requirements for risk reduction and aligned the standards with the current state of collaborative system design.

Q4. What is power and force limiting, and what are its limits?
Power and force limiting is a technique where the robot is designed or configured so that contacts with a person do not exceed biomechanical thresholds derived from pain and injury research. Its limits are application-specific: the permissible force depends on the body region contacted, the contact geometry, and whether the contact is quasi-static or transient.

Q5. Do I need a risk assessment if the robot is certified as collaborative?
Yes. The robot’s certification covers the robot as partly completed machinery. The application—including the end effector, the workpiece, the mounting, the operator’s behavior, and the environment—must be assessed separately. The certification is an input to the assessment, not a replacement for it.

Q6. How do I validate that the force limits are actually being met?
Use a measurement device with mechanical properties that approximate human tissue to measure the actual contact forces at the speeds and configurations used in production. Compare the measured values to the limits from the risk assessment. Configuration alone does not demonstrate that the limits are met.

Q7. What role does cybersecurity play in cobot safety?
The ISO 10218 series requires cybersecurity measures including port hardening, detection of unauthorized configuration changes, and network segmentation. If an attacker or an unauthorized user can change the safety configuration, the safety case is invalid. Security is a safety requirement for networked cobots.

Q8. Can I use a cobot for a task that requires high speed?
Power and force limiting requires moderate speeds to keep contact forces within limits. If the application requires high-speed operation, a traditional guarded robot may be the correct choice. The collaborative capability does not override the physics of impact forces.

Q9. What environmental conditions can affect cobot safety sensors?
Airborne particulate, oil mist, and changing ambient lighting can interfere with optical scanners, cameras, and force sensors, causing nuisance stops or reducing detection reliability. The deployment must account for the actual environment, not a clean lab.

Q10. What is the first step in deploying a cobot safely?
Define the collaborative task and select the end effector before selecting the robot. The hazards are created by the tool and the task, not by the arm. Beginning with the robot leads to assessments that are retrofitted to a decision already made.

Conclusion

Safe cobot deployment is an application-level discipline, not a robot-level feature. The ISO 10218 revision makes this explicit by evaluating collaborative applications rather than collaborative robots. Perform the risk assessment with the actual tooling, validate force limits by measurement rather than configuration, secure the safety settings against unauthorized change, and document the boundaries of the assessment. The deployment that succeeds is the one that treats the workcell as the safety unit from the first decision. For more deployment guidance, visit RobotsOps.com.