HyperQ AI Safety deploys as a monitored zone configuration in 1 hour on a standard installation. The ISO 10218-2 safety performance level that configuration carries is not determined by the camera specification or the deployment time — it is determined by what happens between the system detecting an intrusion and the robot reaching a safe state. That interval is the response chain, and the response chain is where the engineering lives and where most vision-based safety deployments are underspecified.
This piece covers speed-and-separation monitoring as an approach to collaborative and semi-collaborative robot cells, the ISO 10218 framework that governs it, and the specific latency requirements that determine whether a vision-based safety function meets the applicable performance level. It builds on the introduction to AI-based robot cell safety with a focus on intrusion-response architecture rather than system selection criteria.
Why hard fencing is a manufacturing flexibility problem
Hard fencing around a 6-axis robot cell is an adequate solution for fixed-task, high-volume automation. The robot runs a single sequence; the fence defines the hazard boundary; the only safety event is unauthorized entry. In a cell that runs the same weld pattern on the same part at the same cycle time for 500,000 cycles, fencing is appropriate and the economics are straightforward.
The problem surfaces in low-volume, high-mix environments where the cell serves multiple part families and operator interaction is frequent. A cell running 12 part families across a week requires operators to enter the work envelope for tool changes, part positioning, quality checks, and fault clearance. Each entry requires a full stop and a re-enable sequence. In a cell with 6-8 operator interactions per shift, that overhead can accumulate to 30-60 minutes of lost cycle time per day. Compounded across a production week, the fencing that protects the cell also constrains its productive output.
Light curtains and safety mats address the fixed-fence limitation for linear access control but carry their own retooling cost. They are geometrically fixed to the cell layout. Reconfiguring the cell for a new part family typically means relocating the safety hardware, recertifying the safety circuit, and updating the safety-rated PLC configuration. In a facility where the robot cell layout changes quarterly, this is not a minor maintenance task.
Vision-based safety monitoring replaces physical safety hardware with software-configured monitored zones. The zone is defined in software, not by hardware position. Reconfiguring it for a new cell layout does not require hardware relocation or safety PLC recertification — it requires a zone boundary update, a functional test, and documentation of the change. The tradeoff is latency. The safety performance of a vision-based monitoring function is only as good as the slowest link in its response chain.
Speed-and-separation monitoring: the ISO 10218 and ISO/TS 15066 framework
ISO 10218-1 and ISO 10218-2 define safety requirements for industrial robots and their integration into work cells. ISO/TS 15066 extends these specifically to collaborative robot applications, including speed-and-separation monitoring (SSM) as a defined collaborative operation mode.
Under SSM, the robot operates at a reduced speed when a person is present in a defined outer zone at intermediate distance, and stops when the person enters a closer protective stop zone. The permitted robot speed in the outer zone is calculated from the minimum protective distance — the distance at which the robot must be operating to guarantee it can reach a safe state before the person could reach the robot's nearest hazard point, accounting for the total reaction time of the entire monitoring and control system.
ISO/TS 15066 provides the calculation for minimum protective distance:
S = (T_s + T_r) × (V_r + V_h) + C
Where T_s is the stopping time of the robot, T_r is the response time of the safety system, V_r is the robot speed at the protective stop trigger, V_h is the human approach speed (1,600 mm/s per the standard's conservative assumption), and C is an intrusion distance factor (typically 100-200mm for standing operators).
The standard's response time (T_r) includes the detection system's latency from intrusion event to safety output signal. A vision-based detection system that takes 300ms from event to output is not equivalent to a safety laser scanner with a 15ms response. The minimum protective distance — and therefore the usable working radius of the cell under SSM — scales directly with the monitoring system's documented response time.
This is the latency engineering problem: a vision safety system that is accurate is not automatically compliant. Detection accuracy and system response time are separate specifications. Both must be measured, documented, and factored into the safety assessment.
The response chain: what determines safety performance
The response chain runs from detection event to robot safe state. Every component contributes to total system response time, and the safety performance level (PL) of the monitoring function under ISO 13849-1 is constrained by the weakest link in the chain.
| Stage | Component | Typical contribution | Notes |
|---|---|---|---|
| Detection | Vision system (camera + inference) | 50-250ms | Architecture-dependent; must be tested under production conditions |
| Signal delivery | Safety output to robot controller | 1-10ms (hardwired) or 10-50ms (safety-rated network) | Hardwired path preferred; network path requires safety-rated protocol |
| Controller response | Safety-rated robot controller | 20-100ms | Manufacturer's specification; load-dependent |
| Mechanical stop | Robot deceleration to safe state | 100-500ms at operating speed | Dynamic model required; varies with payload and speed |
| Total | System response time | 171-910ms typical range | Determines minimum protective distance |
At a total system response time of 350ms with a robot TCP speed of 500mm/s, the minimum protective distance under the ISO/TS 15066 calculation is approximately 735mm plus the intrusion distance factor. A cell geometry that places the outer zone boundary at 500mm from the robot's reach cannot meet the standard at this system response time and robot speed, regardless of how accurate the detection is.
This arithmetic is why the response chain table matters more than the camera datasheet. The camera's frame rate sets a floor on detection latency; everything downstream determines whether the total system response time is compatible with the cell's physical geometry.
Where vision-based monitoring reaches its practical limits
This is the honest part of the specification. Vision-based intrusion detection running at standard video processing rates operates at approximately 33ms per video frame at 30fps. A detection event that falls between frames is not detected until the next frame. Under high approach-speed conditions — a person moving at 1,600mm/s — the detection confidence may require two frames to reach threshold: 66ms minimum before detection latency begins accumulating.
For slow collaborative operations — human and robot working in shared space at reduced speed, with adequate protective distance — the total system response time budget is manageable. For high-speed robot operations at full payload where a mechanical stop from full TCP speed takes 300-500ms of robot mechanics alone, the vision detection latency is a small fraction of the total budget, and the cell geometry must be adequate regardless of which monitoring technology is used.
The scenario where vision safety monitoring reaches its architectural limits: a fast robot operating at high payload and speed in a physically small cell where the geometry does not provide enough protective distance to absorb the total system response time at full operating speed. In these cells, a safety laser scanner with a certified 15ms response time, or a physical hard guard with a safety-rated interlock, is the correct choice — not vision monitoring.
HyperQ AI Safety is designed for cells where the geometry provides adequate protective distance at the system's documented response time under production conditions. That describes the majority of collaborative and semi-collaborative cells in mixed-task manufacturing. It is not a replacement for physical guarding on full-speed, high-payload operations in confined cells, and it should not be specified for that application.
Zone architecture: warning, caution, and stop bands
ISO/TS 15066 supports a graded response across multiple distance bands: the robot slows at an outer detection zone and stops at an inner protective stop zone. HyperQ AI Safety implements this as three configurable zone layers, each with an independent response action.
| Zone name | Distance band | AI Safety response | Robot action | Latency budget |
|---|---|---|---|---|
| Warning zone | Outer band (distance to be calculated per cell) | Alert output + log entry | Speed reduce to defined % | Full system T_r budget |
| Caution zone | Middle band | Alert + speed-reduce signal to controller | Robot to collaborative speed | Full system T_r budget |
| Protective stop zone | Inner band | Stop signal to safety controller | Category 0 or 1 stop | Full system T_r budget |
| Recovery | Zone clear | Clear signal | Resume after operator confirmation | Manual acknowledgment |
Zone boundaries are defined in software and tied to the cell layout mapping. A retool that changes the robot's operating envelope requires a zone boundary recalculation based on the ISO/TS 15066 protective distance formula, a software zone update, and a documented functional test. It does not require moving sensors, relocating light curtain posts, or recertifying a safety PLC.
The zone boundary positions are not fixed by software convention — they are calculated from the cell's specific robot speed profile, payload, deceleration characteristics, and the monitoring system's documented response time. Using generic or pre-set distances without running the calculation for the specific installation is a compliance gap, not a minor omission.
What the safety integrator owns and what the vision vendor owns
A vision safety deployment requires work from two parties, and the boundary between them is a common source of underspecification.
The vision system vendor's responsibility: a documented and tested response time for the detection function (T_r) under representative production conditions, a defined and validated interface to the safety controller output, and a functional specification for the zone configuration approach.
The safety integrator's responsibility: the system-level safety assessment under ISO 13849-1 or IEC 62061, the minimum protective distance calculation per ISO/TS 15066, verification that the safety output interface meets the required PL, and the overall validation documentation. The safety integrator cannot complete the PL assessment without the vision vendor's T_r documentation. The vision vendor cannot perform the PL assessment without the safety integrator's full system architecture.
A vision safety installation that lacks both sets of documentation is not a certified safety function, regardless of the camera's technical specification. For HyperQ AI Safety deployments, both documents are part of the installation deliverable set — the vendor provides detection response time and interface specification; the safety integrator provides the site-specific PL assessment.
The 1-hour deployment time covers the physical installation, camera field of view configuration, zone boundary setup, and functional test of the detection-to-output signal chain. It does not include the safety integrator's PL assessment, which is a separate deliverable. The deployment clock and the certification clock run at different rates; conflating them is the source of compliance gaps in vision-based safety installations.
Practical deployment considerations for multi-cell facilities
In a facility running multiple robot cells at different stages of retooling, a software-defined safety monitoring approach has an operational advantage over hardware-based systems: the zone configurations are versioned and portable, not tied to physical hardware positions.
When a cell retool changes the robot's operating program and footprint, the zone boundary recalculation is done in software and tested against the new program. The safety assessment documentation is updated for the new configuration. The vision hardware does not move. In a facility where 4-6 cells are retooled quarterly on a rotating schedule, this approach compresses the safety recertification timeline relative to a light-curtain-based system where each retool requires hardware relocation and a full safety circuit reverification.
The same platform architecture that handles production-quality monitoring across multiple lines in an automotive parts deployment — different product geometries, different cell layouts — demonstrates that software zone management scales across a multi-cell environment without requiring a separate hardware system per cell configuration.
The operational framing one plant engineering manager used to justify the approach: the cost of a light curtain relocation — labour, safety integrator time, functional test, documentation — runs to approximately one full day per cell retool. At 4 retool events per cell per year across 6 cells, that is 24 person-days of safety recertification overhead annually. Software-defined zone reconfiguration reduces this to a few hours per event. The capital comparison between the two approaches changes substantially when the retool frequency is factored in alongside the initial installation cost. The comparison is also different when the facility plans to expand its robot cell count over the next 3-5 years: the software zone management infrastructure scales across additional cells without proportional increases in safety hardware stock or integrator certification overhead per new cell.
Send your current cell layout drawing — robot model, operating speed and payload, cell footprint, and current guarding approach — and we will return a speed-and-separation monitoring feasibility assessment within 5 business days. The assessment includes minimum protective distances, response-time requirements for the monitoring system, and a checklist of the documentation each party needs to produce for the PL assessment. No contract required. Start the cell assessment