Robot Software
Over-the-Air Updates for Robots: The Safety Problem
Updating robot software remotely is straightforward until a safety function is involved. What may be updated without revalidation, what may not, and how fleets handle the difference.
Update the application freely, treat anything safety-related as a change to the machine. A modified safety function normally requires revalidation of the affected safety functions and, depending on the extent, an updated conformity assessment. That is why serious fleets split their software into two update channels with different governance, and why mixing them is an audit finding waiting to happen.
The two channels
| Component | Channel | Revalidation |
|---|---|---|
| Application logic, task sequences | Standard | Functional test only |
| Vision models and parameters | Standard | Functional test, unless a safety function depends on it |
| Path programs and waypoints | Standard | Functional test, re-measure if speed or payload changed |
| User interface, logging, telemetry | Standard | None |
| Fleet and scheduling software | Standard | None, unless it commands safety state |
| Safety controller firmware | Safety | Full revalidation of affected functions |
| Safety configuration, zones, limits | Safety | Full revalidation, plus measurement if contact limits change |
| Motion control affecting stopping distance | Safety | Stopping performance re-measured |
| Balance or navigation policy on a mobile or legged robot | Safety | Behaviour re-characterised |
The changes that quietly cross the line
- Raising a programmed speed. Effective mass and speed determine permissible contact values, so a faster path invalidates the previous force and pressure measurements.
- A heavier gripper or part variant. Payload changes effective mass on an arm and stopping distance on a mobile base.
- A new pick position. If it extends the swept volume, the reach study and the contact scenario list are both out of date.
- Retuning a controller. Aggressive gains change overshoot and stopping behaviour even without touching a safety parameter.
- Updating a navigation stack. Detection latency contributes directly to the protective field calculation on a mobile robot.
None of these look like safety changes in a version control diff. All of them are.
Running this across a fleet
- Staged rollout. One machine, then a small group, then the fleet. A fault that appears on 1 robot is an incident; on 40 it is a shutdown.
- Atomic update with rollback. Dual partitions or equivalent, so a failed update reverts on the next start rather than leaving a machine unbootable.
- Version pinning per site. Different sites have different safety approvals. A single fleet-wide version can push a change into a site whose validation does not cover it.
- Update only in a known state. Never mid-cycle, never holding a part, never while a person is in the collaborative workspace.
- Signed packages and authenticated transport. An unauthenticated update channel to a machine that can move is a serious vulnerability, and cybersecurity requirements were explicitly added in the 2025 revision of the robot safety standard.
- Immutable records. Which version, on which machine, at which time, authorised by whom, with the validation evidence attached.
Sizing the update window
Update time is downtime, and fleets that do not plan it discover the cost during the first rollout. A realistic budget for a mixed fleet looks like this.
| Change class | Install | Verification | Total per machine |
|---|---|---|---|
| Telemetry or interface only | 2 to 5 min | 0 | 2 to 5 min |
| Application logic | 5 to 15 min | 10 to 30 min | 15 to 45 min |
| Path or speed change | 5 to 15 min | 30 to 90 min | 35 to 105 min |
| Contact limits affected | 5 to 15 min | 2 to 8 h | 2 to 8 h |
| Safety firmware or configuration | 10 to 30 min | 4 h to 2 d | up to 2 days |
The bottom two rows explain why safety-relevant changes are batched rather than shipped continuously. A fleet of 40 machines each needing four hours of revalidation is 160 hours of work, which is a planned shutdown rather than a Tuesday afternoon.
The legal frame
In the European Union, machinery placed on the market before 20 January 2027 falls under Directive 2006/42/EC and from that date under Regulation (EU) 2023/1230. Both attach obligations to the machine as placed on the market, and a substantial modification can create a new machine with a new conformity assessment. Software that changes safety behaviour is a modification, and the fact that it arrives over a network rather than on a laptop changes nothing about that.
Frequently asked questions
Can I update robot software remotely?
Application software yes, with staged rollout and rollback. Anything that influences a safety function requires revalidation of the affected functions before the machine returns to production, regardless of how the update was delivered.
Which updates require revalidation?
Safety controller firmware, safety configuration and limits, changes affecting stopping distance, and balance or navigation policies on mobile and legged robots. Also any application change that raises speed, alters payload or extends the swept volume.
Is a vision model update a safety change?
Only if a safety function depends on its output. If the model merely locates parts it is application software; if it triggers a protective response it is part of the safety chain and follows the safety channel.
What does a compliant update record contain?
At minimum the version installed, the machine and site it went to, the timestamp, who authorised it, and the validation evidence for any safety-relevant change. Records should be immutable and retained for the life of the machine.
Does the machinery legislation cover software updates?
Yes, in the sense that obligations attach to the machine as placed on the market and a substantial modification can trigger a new conformity assessment. A software change that alters safety behaviour is a modification whether it arrives by network or by cable.
Sources
- ISO 10218-1:2025, Robotics, Safety requirements, Part 1International Organization for Standardization, functional safety and the added cybersecurity requirements
- Regulation (EU) 2023/1230 on machineryEU-OSHA legislation record, obligations and substantial modification
- IEC 62443, security for industrial automation and control systemsInternational Electrotechnical Commission, secure update and patch management requirements