Two parts, two levels of responsibility
The draft refers to the 2025 editions of ISO 10218 and presents them as a division between requirements for the industrial robot and requirements for its applications and cells. The verified source package for this review does not include official ISO records that would allow us to confirm the specific scope of each part, its publication date, or which editions it replaces. For that reason, those standards details are not presented here as verified facts.
The distinction remains useful as a way to read the material: the characteristics of a robot arm do not, by themselves, describe the environment in which it will be installed. The tool, workpiece, nearby equipment, and operating or maintenance tasks can all change the conditions of use. It is worth distinguishing the component from the complete system and asking for documentation that identifies the configuration and tasks that were evaluated, rather than assuming that citing a standard settles the safety of an installation on its own.
In practice, a description of the robot is not enough to understand how it will behave when integrated into a workstation. The same component can be part of different applications, with different tools, loads, paths, and human activities. When reviewing documentation, it is therefore useful to check that it identifies the evaluated system with sufficient precision, rather than naming only the robot-arm model. This caution does not add standards requirements; it helps prevent a statement about one component from being interpreted as a conclusion about the entire cell.
“Collaborative” describes a possibility, not an outcome
In everyday usage, “cobot” is used to refer to robots intended to collaborate with people. But the word alone does not establish that a task is safe or that a particular installation is ready to share a workspace. The combination of robot, tool, workpiece, controls, sensors, speed, paths, and human activity defines the context that needs to be examined.
That is why, when someone says a robot is “collaborative,” it is worth clarifying what is being described: an available capability, a safety function, an evaluated configuration, or a complete cell. These are different things. The label does not specify which hazards were considered or under what conditions protective measures will operate. The evaluation and applicable obligations must be determined for the relevant equipment and jurisdiction; the sources verified here are not sufficient to attribute specific recommendations to OSHA or to summarize legal requirements.
The difference matters because the availability of a capability does not show that it is active, suitable for the task, or verified at the intended workstation. Likewise, a safety function forms part of an evaluation, but does not by itself describe every possible interaction between a person and the system. To understand a commercial claim, ask what it covers and what documentation supports it, without turning a general term into a guarantee about conditions that have not been described.
Evaluate the task and foreseeable changes
A practical evaluation starts by describing what people and the robot will do, in what sequence, and under what conditions. In addition to the normal cycle, it is useful to include setup, workpiece or tool changes, jams, recovery after a stop, and maintenance. NIST published a work whose title identifies the task-based characterization of human-robot collaboration safety in manufacturing. The available publication record identifies the topic, but does not provide enough detail here to describe methods or results.
The analysis should be translated into measures that can be checked and maintained. Depending on the hazards and application, it may be necessary to control access, limit movement or speed, physically separate areas, or incorporate safety functions. There is no universal combination that can be recommended without knowing the system. It is also prudent to record which configuration was examined and review the evaluation when the tool, load, program, or workstation layout changes. That record helps link each measure to the conditions considered and identify when a modification calls for a new review.
Describing the tasks in detail makes it possible to consider not only automated movement, but also what people do before, during, and after the cycle. For example, an intervention to clear a jam is not necessarily equivalent to normal operation; it is therefore useful to include it in the description, without assuming that measures intended for the normal cycle cover every situation. The evaluation should also be comparable with the actual configuration: if relevant elements change, the previous documentation may no longer describe the system as it is used.
Physical contact and distance: what to measure
Applications can involve different kinds of interaction: some aim to maintain separation between the person and the robot, while others may allow contact under specified conditions. The name of a function is not enough to determine how the system responds. Evidence should correspond to the installed configuration and the type of interaction it is intended to control. NIST published a work whose title identifies a testbed for evaluating speed and separation monitoring in a collaborative setting. The available record identifies its general purpose, but does not provide enough detail to specify its parameters or draw conclusions about a particular installation.
As for physical contact, the verified material in this package does not include the ISO/PAS 5672 record needed to confirm its scope and exclusions. Accordingly, no specific claims are made here about that document or the hazards it covers. As a general reading principle, a measurement provides information about what it measures, but should not automatically be interpreted as a comprehensive assessment of every risk. The scope of the evidence matters: ask what quantities were measured, under what conditions, and which aspects are outside its scope.
The distinction between maintaining distance and permitting contact also helps guide the questions to ask, but it does not replace analysis of the application. In the first case, it is important to understand how detection and system response were considered; in the second, it is important to know which measurements support the evaluation and what their limitations are. In both cases, evidence should relate to the equipment and conditions of use being assessed, rather than being transferred without qualification from a generic description or a different test.
What research contributes—and what it cannot establish
NIST has published work on task-based characterization of human-robot collaboration and on the evaluation of speed and separation monitoring. These are references to research and evaluation methods, not proof that a particular cell has been inspected or certified. The records included here identify those works, but do not describe their protocols or results in detail.
Another study included in the package addresses power and force limiting (PFL) and examines a collision-sensitivity method tested in simulation and on robotic arms. The abstract reports experiments in specific scenarios, including a simulated pick-and-place task. Those results are not equivalent to general validation of any robot or application. The fit between evidence and actual use is essential: results obtained with other equipment, tasks, or conditions are not enough to treat the installed system as verified.
A NIST publication on sensors for collaborative robots in smart manufacturing is also identified, but the available extract does not provide enough information to assert specific results or technical requirements. Its mention therefore identifies the subject addressed; it does not support attributing conclusions that the material consulted does not substantiate. Taken together, these references can help locate research areas and evaluation approaches; they do not replace the specific information needed to assess a particular installation.
Checklist before accepting a claim
Before purchasing or commissioning a solution, request a description of the application that was examined: robot configuration, tool, loads, tasks, movement limits, and workstation layout. Also ask for the available risk assessment, the measures associated with each hazard, and operating and maintenance documentation. Because the current sources do not verify the scope of ISO 10218-2 or the recommendations attributed to OSHA in the draft, those standards details have been omitted. A specific description makes it possible to compare what was evaluated with what will actually be installed, instead of relying on a general claim about the model.
Next, check that the cited functions correspond to the installed configuration and that their behavior has been verified under the expected conditions. Ask what happens if sensors fail or the load changes, who authorizes modifications, and how access is managed during adjustment and maintenance. If contact may occur, request measurement data and its limitations; if safety depends on maintaining distance, ask how detection and system response were taken into account. These questions do not replace the judgment of competent professionals: they help distinguish a stated capability from an evaluated application. The conclusion depends on the specific installation and should be reviewed if the conditions of use change.
To make the comparison clear, the requested information should identify what was examined and the conditions to which each measure relates. If the documentation does not cover a task that is performed in practice, or describes a different tool or layout, ask for the difference to be clarified before treating the evaluation as applicable. It is also helpful to confirm how later modifications are managed, so that a change to the workstation does not go unnoticed in relation to the original review. The checklist does not determine by itself whether a solution is safe; it organizes the questions needed to judge whether what is claimed corresponds to what is installed.