Collision Detection and Protective Stop: Cobot Zoning
Collision detection and protective stop functions are not interchangeable safety claims. Start with the application risk assessment, identify who can approach each hazard and in which operating state, then assign each scanner field a specified safety-related response. Validate coverage and the complete stopping response under the project’s worst credible conditions. Record faults, reset, restart, and change tests before release. A visible zone-entry demonstration alone does not prove a safe or compliant installation.
How collision detection and protective stop fit safety zoning
A practical zoning review separates three questions. First, what hazard exists in each task and approach scenario? Second, which safety function should respond before a person can reach that hazard? Third, what evidence proves the field coverage, control response, complete stopping behavior, reset, and restart conditions? Collision detection may address contact or force behavior defined by the selected system, while a scanner-triggered protective stop is a separate application control that acts from monitored access. Neither label supplies a universal distance or safety result. Use the applicable risk-assessment method, manufacturer documentation, safety-system architecture, measured or validated stopping data, and site tests. Reassess the boundary whenever speed, payload, tool, path, scanner position, layout, software, or connected equipment changes.
Observable sequence
- 00:00-00:06: the robot base and low-mounted scanner context remain visible while a person’s lower legs approach the outer yellow floor region.
- 00:06-00:12: the lower legs move onto the yellow region and toward the inner red region.
- 00:12-00:19: the lower legs occupy and cross the red marked region while the robot and scanner context remain in frame.
- 00:19-00:25: the lower legs withdraw from the red region toward the outer marked floor.
Evidence boundary: The sequence is a zone-entry illustration only. It does not prove collision-detection performance, a safety rating or performance level, an exact field or separation distance, response or stop time, robot speed or payload, a protective-stop category, compliance, certification, customer acceptance, or site deployment.
Key takeaways
- Treat collaborative safety as an application property, not a label attached to the robot arm.
- Derive scanner fields from hazards, approach paths, stopping performance, and the actual layout.
- Specify what each field requests and how the safety-related control function confirms the resulting state.
- Test obscuration, faults, bypass routes, reset, restart, and changes as well as normal entry.
- Keep risk assumptions, calculation inputs, safety configuration, test method, and results under revision control.
Start with people, tasks, and hazards
Map normal production together with setup, loading, unloading, cleaning, teaching, inspection, fault recovery, and maintenance. Identify every expected approach direction, access point, floor-level or elevated route, blind area, and situation in which a person could already be inside the monitored space when the machine restarts.
The robot is only one part of the hazard picture. Include the end tool, sharp or hot surfaces, carried parts, pinch and crush points, external axes, fixtures, and connected machinery. The required protective measures depend on the complete task and cannot be inferred from the word collaborative.
Separate collision detection from protective-stop control
Collision detection can refer to different sensing and control behaviors depending on the robot, tool, configuration, operating mode, and manufacturer documentation. It must not be treated as a general substitute for preventing access to crushing, trapping, sharp-tool, hot-process, or workpiece hazards. Record exactly which function is being used, its limits, and the hazard it is intended to reduce.
A scanner field can request speed reduction, a protective stop, or another specified response through the safety-related control system. Verify the devices, interfaces, required performance, reset conditions, and relationship with connected equipment. An ordinary motion command or floor marking is not by itself a safety function.
Determine boundaries from stopping evidence
The boundary should account for the selected approach model, sensing response, communications and control response, actual robot and machine stopping behavior, measurement uncertainty, and application-specific intrusion or reach considerations. Use applicable standards, manufacturer instructions, the risk-assessment method, and measured or validated stopping data.
There is no responsible universal distance for every collaborative application. The result can change with speed, payload, tool, posture, path, controller configuration, floor layout, scanner installation, and connected equipment. A demonstration or earlier project should not be copied without re-evaluation.
Validate coverage and foreseeable faults
Test approaches from every relevant direction and at field boundaries. Check whether fixtures, pallets, parts, cables, posts, reflections, contamination, or temporary materials can block or distort detection. Confirm the designed response when the scanner is obscured, disconnected, misconfigured, or reporting a fault.
Also test a person remaining inside the monitored area, entry during restart, repeated boundary crossings, a protective stop during different robot poses, and the response of connected hazardous equipment. Record the safety configuration and test conditions so the evidence can be repeated after a change.
Control reset, restart, and change
Define who can reset a protective stop, where the reset control is located, what visibility is required, and which conditions must be true before motion resumes. A reset should acknowledge a state; it should not create unexpected hazardous motion. Include prevention of reset from a position that cannot verify the protected space.
Create reassessment triggers for changes to layout, scanner position or configuration, speed, payload, tool, part, path, external equipment, safety controller, or software. The scope of retesting should follow the changed hazard and safety function, not a calendar shortcut.
Record a repeatable validation package
Retain the risk scenarios, device and configuration identifiers, field drawings, calculation inputs, safety-function description, interfaces, stopping evidence, test method, test conditions, result, deviations, approvals, and change history. The record should make clear which values came from documentation, which were measured, and which remain project assumptions.
For each field test, state the approach direction, robot state, payload and tool condition where relevant, test point, expected response, actual result, reset and restart outcome, and disposition. Final design and release belong to the responsible qualified parties under applicable law, standards, manufacturer instructions, and validated site conditions.
Compare awareness, speed reduction, and protective stop
An awareness field can provide an early signal or operational indication, but it does not by itself remove a hazard or prove a safety-rated response. A speed-reduction field can reduce exposure before a person reaches a closer boundary when the complete safety function and resulting operating state are specified and validated. A protective-stop field requests a safety-related stop before access to the hazard under the assumptions used in the separation or boundary design.
Compare these responses against the same hazard, approach path, robot and tool state, stopping evidence, scanner coverage, connected equipment, reset logic, and fault behavior. Do not choose a field because its color looks intuitive in a demonstration. Select the response required by the risk assessment, then validate the complete chain from detection through the controlled state and restart. Collision-detection functions remain a separate layer with their own documented limits; they do not erase the need to address access before contact where the hazard requires it.
Use change control as part of safety evidence
A validated field can become invalid when the layout moves, the scanner is remounted, a pallet blocks coverage, the robot path changes, speed or payload increases, the tool changes, or connected equipment adds a new hazard. Treat the field definition, robot safety configuration, and validation record as controlled items with named change authority.
After a change, identify which risk assumptions, calculations, safety functions, interfaces, stopping evidence, coverage tests, reset conditions, and user information are affected. Repeat the corresponding tests and keep the earlier and revised records distinguishable. This prevents a successful demonstration under one configuration from being reused as evidence for a materially different application.
Decision table
| Decision area | Evidence to verify | Risk if unclear |
|---|---|---|
| Hazard and approach | Tasks, hazards, people, routes, and operating states are documented | A relevant access path or hazard is omitted |
| Field response | Awareness, speed reduction, or protective stop is tied to a specified safety function | A colored zone is mistaken for a validated control |
| Coverage | Scanner position, configured fields, obstruction checks, and boundary tests are recorded | A blind area or bypass path remains |
| Stopping evidence | Complete response and stopping behavior are validated under defined conditions | The boundary does not match the actual machine response |
| Reset and change | Authority, visibility, preconditions, versions, and reassessment triggers are controlled | Unexpected restart or obsolete validation |
Citable statements
Citable statement 1: A scanner field is not a safety claim by itself; it must be connected to a specified and validated safety-related response.
Source basis: ZONE response model, project-input checklist, ISO 10218-2, and ISO/TS 15066 context.
Citable statement 2: Protective boundaries should be derived from the application risk assessment and complete stopping evidence, not copied from a demonstration.
Source basis: ZONE stopping-evidence row and the documented risk-assessment boundary in the cited standards.
Citable statement 3: Collision detection and scanner-triggered protective stop should be evaluated as separate controls unless the system documentation defines and validates their relationship.
Source basis: ZONE control-layer comparison; project-specific manufacturer documentation is required before applying the statement.
Citable statement 4: A safety-zone change requires controlled reassessment whenever it can affect a hazard, approach path, safety function, coverage, or stopping result.
Source basis: ZONE evidence-and-change model plus the configuration and retest checklist.
The ZONE review model
EVST uses the ZONE model as a planning aid for early application review. It organizes the evidence a project team would request before concept selection; it is not a performance guarantee or a substitute for project-specific trials and risk assessment.
- Z — Zone inputs: people, tasks, hazards, approaches, layout, and operating states.
- O — Observe coverage: field boundaries, blind areas, obstruction, fault behavior, and bypass routes.
- N — Name the response: safety function, interfaces, stopping evidence, reset, and restart.
- E — Evidence and change: configurations, calculations, tests, results, approvals, and reassessment triggers.
Download the project-input checklist.
Related resources
- fenceless cobot safety and ISO/TS 15066
- cobot safety standards: ISO 10218 and ISO/TS 15066
- EVST robot and automation resources
References
- ISO 10218-2:2025 — Safety requirements for industrial robot applications and robot cells
- ISO/TS 15066:2016 — Collaborative robots
- OSHA — Robotics standards and consensus guidance
Who prepared this guide, how, and why
- Author: EVST Editorial Team, an organization-level byline.
- Technical scope: EVST Technical Content Review, an organization-level review function.
- Method: Frame-by-frame observation of the cleared 25.2-second process sequence, followed by a decision model and project-input checklist. The method records visible sequence evidence separately from engineering requirements and does not convert footage into a performance or deployment claim.
- Why: This guide was written to help safety-solution buyers distinguish a visible zone-entry demonstration from the risk assessment, safety-function definition, stopping evidence, coverage tests, reset controls, and change records needed for release.
- Policies: Editorial policy · Corrections policy · Terms of use · Privacy policy
Frequently asked questions
What information is needed for a first safety-zoning review?
Provide the layout, robot and controller configuration, tool and part data, operating modes, tasks, personnel routes, scanner model and mounting concept, connected equipment, risk-assessment material, stopping evidence, and reset and restart concept.
Can a floor marking prove the protective boundary?
No. A floor marking can communicate a planned or demonstrated field, but the protective boundary depends on the configured safety system, application assumptions, stopping evidence, test method, and validated result.
When should safety zoning be revalidated?
Reassess when a change can affect hazards, access, sensing, the safety-related response, stopping behavior, or restart. Examples include layout, scanner position or configuration, speed, payload, tool, workpiece, path, software, safety settings, or connected equipment.
Next-step project inputs
An engineering review can begin from the part drawing, material and process range, required output, inspection method, layout constraints, and target cycle. The resulting concept still requires representative trials, risk assessment, and agreed acceptance criteria before production release.