A robot doesn't stop being dangerous because the operator moved to another room. Removing the human from the cell removes some hazards — nobody is standing in the workspace — and adds one that a co-located operator never had: a network link that can drop, degrade, or lie to the robot about what the operator actually wants. Designing for teleoperation safety means keeping the hazards a robot cell has always had under control while adding a specific answer to that new one. This is engineering guidance, not legal advice — consult a qualified safety engineer and your applicable regulations for any real installation.
What's different about a remotely operated cell
Standard industrial and collaborative robot risk assessment already covers crushing, pinching, and impact hazards in the workspace. A remote cell adds a second category entirely: hazards that originate in the control loop rather than the mechanism. An operator working from degraded video, compressed audio, or a laggy feed can misjudge a scene the same way a co-located operator with poor lighting might — except the failure mode compounds with everything downstream of it, because the operator's corrective action also has to survive the round trip back to the robot.
A hazard analysis for a remote cell should explicitly walk through: what happens if video freezes but the command channel stays open; what happens if the command channel drops but video keeps streaming; what happens if latency spikes without dropping the connection outright; and what an operator with only camera views (no proprioceptive or force feedback) is likely to miss compared to someone standing next to the robot. None of these have a single universal answer — they depend on your task, your robot, and your cell — but skipping the analysis because "it's the same robot" is how the network-specific failure modes get missed.
Layered protection: no single failure should get through
The standard safety-engineering principle — independent layers, no single point of failure — applies directly, and teleoperation adds a layer rather than removing any existing ones.
- Physical guarding
- Fencing, light curtains, or presence sensing at the cell — unaffected by anything happening on the network
- Hardware e-stop
- A local, non-networked stop reachable by anyone near the robot; per ISO 13850, engineered for at least Performance Level c under ISO 13849-1
- Dead-man / enabling device
- Continuous deliberate engagement required from the operator to hold motion authority — releases removes it immediately
- Software watchdogs and limits
- Heartbeat timeouts, velocity/force ceilings, and workspace bounds enforced in the robot controller, not the remote application
The hardware e-stop and physical guarding at the cell exist for anyone who might be near the robot in person — a maintenance technician, another operator, a visitor — and they have to work with zero dependency on the teleoperation system, full stop. That's not a redundant nicety; it's the layer that still works when everything network-related has failed simultaneously.
On the operator's side, industrial robot practice has for decades required a three-position enabling device on teach pendants for manual and reduced-speed modes: release it, over-press it, or let go, and the robot loses motion authority through a safety-rated stop. Extending an analogous dead-man pattern to a remote operator's console — a control that must be actively and continuously held, not just a mode toggled on at session start — is a well-established engineering pattern worth applying even though the underlying standards were largely written before teleoperation over a network became common practice.
Software watchdogs, velocity limits, force limits, and workspace bounds belong in the robot's own controller, evaluated against whatever the remote application actually sends, not trusted from the remote side. A malformed, delayed, or malicious command should be rejected by limits the robot enforces on itself.
The specific failure mode: losing the network
This is the hazard co-located operation never has to solve, and it deserves a design answer stated explicitly rather than assumed. When the link degrades or drops, the robot has to reach a safe state using only information and logic available locally — because by definition, nothing from the remote side can be trusted to arrive.
The pattern that works: a heartbeat or command-freshness check running in the robot controller, with a defined timeout after which the controller executes a controlled stop on its own initiative — ramping velocity down through a defined stop category (per IEC 60204-1's Category 0, 1, or 2 stop classifications) rather than a violent halt, unless the immediate hazard requires the faster stop. The specific timeout and stop category are a function of your task's dynamics and risk assessment, not a number to copy from elsewhere — but the requirement is fixed: the decision to stop must not depend on the remote link recovering, sending a "please stop" message, or doing anything at all. Silence itself has to be the trigger.
This has a corollary worth stating plainly: never design a safe state that requires the network to deliver a stop command. If the failure mode you're protecting against is network loss, the protection cannot live on the other side of that same network.
Latency's role in the safety case
Glass-to-glass latency — the full round trip from a sensor on the robot to the operator's display and back — is usually discussed as a usability problem, and it is one: somewhere around 100–150 ms of round-trip delay, contact-rich work stops feeling continuous and starts feeling like a series of small moves punctuated by waiting for the picture to confirm each one. See teleoperation for the mechanics of why that threshold exists.
It's also a safety input. The time between a hazard becoming visible in the operator's feed and a corrective command reaching the robot includes that same round trip, plus human reaction time on top of it. A safety case that treats the operator as a fast-acting protective layer for a fast-developing hazard is implicitly assuming a latency budget that may not hold under real network conditions — jitter and packet loss make round-trip time worse under exactly the load conditions a busy shift produces. Where a hazard can develop faster than the round trip plus human reaction time allows for, the protection has to come from local limits and stops, not from the operator noticing in time.
Logging and reviewing incidents
Every stop — commanded, watchdog-triggered, or e-stop — should log enough context to answer three questions afterward: what triggered it, what state the robot and link were in at the time, and whether it was an operator decision, a network fault, or a hardware fault. Distinguishing those three matters, because they call for different fixes: operator errors point to training or interface changes, network faults point to link infrastructure or timeout tuning, and hardware faults point to maintenance. A log that only records "stop occurred" collapses all three into noise. Review this alongside session recordings — the same teleoperation capture layer that produces training data typically already has the video and command history needed to reconstruct an incident, if it's retained rather than discarded after the session.
Standards to consult, not to treat as a checklist
The relevant framework for industrial robots is ISO 10218-1 (requirements on the robot manufacturer) and ISO 10218-2 (requirements on the system integrator), both updated in 2025 — an edition that folds the collaborative-operation content previously published separately as ISO/TS 15066 into ISO 10218-2 directly. In the US, ANSI/A3 R15.06 is the national adoption of that framework, also updated to a 2025 edition. Underneath both sit ISO 13850 for emergency-stop device design, ISO 13849-1 for determining the required reliability (performance level) of any safety-related control function, and IEC 60204-1 for the electrical implementation and stop-category definitions referenced above.
None of these standards were written with a teleoperated cell as the primary case, and none of the numbers or clause specifics above should be treated as a substitute for reading the current editions against your own installation and jurisdiction. Treat this section as a starting list for a qualified safety engineer, not as compliance guidance in itself.