Nobody writes the rules for your robot's software updates

Software update engineering is not an unexamined problem. ISO 24089:2023, Road vehicles — Software update engineering, with Amendment 1 published in 2024, specifies requirements and recommendations for exactly this activity, at both the organisational and the project level. It covers vehicles, vehicle systems, electronic control units, the supporting infrastructure, and the assembly and deployment of update packages after initial development. It applies to vehicle manufacturers, suppliers and their partners. It deliberately does not prescribe particular technologies or solutions.

That is a well-designed answer to the question an operator is actually asking. It is also, by its own scope, an answer for road vehicles.

There is no equivalent for service robots, mobile robots or humanoids. A cleaning machine, a transport robot in a hospital corridor and a legged inspection robot all receive behaviour-changing software from their manufacturers, and none of them sits inside a published framework describing how that should be engineered, staged or documented. This is a gap, not a loophole: nobody is evading anything. The standardisation simply happened where the vehicle industry needed it and has not happened here.

The consequence for an operator is narrow and practical. Where a standard exists, you can require conformity and stop. Where none exists, you have to ask, and you have to write the answers down.

The reflex in a mixed-fleet project is to reach for VDA 5050, the interface specification developed by the VDA and the VDMA for communication between a master control and mobile robots. It is a genuine engineering standard, currently at version 3.0.0 dated March 2026, and it is the right tool for what it covers.

It does not cover this. Clause 2, “Scope”, of the specification expressly removes from its remit: safety requirements, stating that the document “does not define functional, operational, or system safety requirements and shall not be regarded or applied as a safety standard”; traffic management logic; other communication interfaces to peripheral equipment or external IT systems; project coordination and commissioning procedures; cybersecurity measures; and the allocation of operational responsibilities between operators, integrators, vehicle manufacturers and fleet control providers.

That last exclusion is the one that matters here. The question of who is permitted to change the behaviour of a machine on your floor, and under what conditions, is a question about the allocation of responsibility. VDA 5050 says in its own words that it does not answer it. What the standard actually covers, and the contract items a mixed fleet needs alongside it, is set out in VDA 5050 and the mixed fleet.

The next place an operator looks is the manufacturer's own documentation, and it is worth being precise about what is found there, because the answer is genuinely mixed.

Boston Dynamics maintains public developer documentation and publishes release notes at a named version — Spot 5.1.9 at the time of writing. Those notes are substantive. They record new features, fixes and deprecations, and they let an operator see what changed between one version and the next. That is more than a large part of this market publishes at all.

What the release notes do not contain is any of the commitments an update policy is made of. Read for it directly and there is no statement of how robots are updated, no backwards-compatibility policy, no declaration that a given release will be maintained for a stated period, and no list of releases that are no longer supported. The document is a changelog, and it is doing the job of a changelog.

That the changes are real is easy to demonstrate from the same documentation. Boston Dynamics records that as of the 3.2.1 release of CORE I/O software, the password and groups on the payload can be modified by the user. That is an access-control property of a deployed payload changing in a point release. It is a reasonable improvement, it is properly documented, and it is also the kind of change that an operator's own security review would want to have known about in advance rather than discovered in a version note.

Two conclusions follow. The first is that documentation depth varies enormously across the manufacturer base, and whether a versioned developer manual exists at all is knowable before signature. The second is that even the best-documented case in this segment leaves the support commitment unstated, which means it can only come from somewhere else.

These are questions for a tender or a contract negotiation, not for a technical audit. Each is answerable by a manufacturer in a sentence, and each becomes useful only once the answer is written down.

• What can change without our involvement? Firmware, autonomy behaviour, the perception model, the mobile or web client, the cloud service the robot depends on. Ask for the list, not the assurance.
• Which of those changes reach the machine automatically, and which require us to act? A robot that updates itself and a robot that waits for a technician are two different operational risks.
• Can we defer an update, and for how long? If the answer is no, that is a fact worth knowing. If the answer is yes, ask what stops working during a deferral.
• Is there a version we can pin for the duration of a validation window? Sites with a qualification process — hospitals, food production, regulated production floors — need this one answered before anything else.
• How long will this release line be maintained? Ask for a date or a period. Where the manufacturer will not give one, that itself is the answer, and it belongs in the risk section rather than in a footnote.

The last one is where most of these conversations stop, and it is the one an operator should push hardest on, because it is the only question whose answer changes what the machine is worth in year four.

The second group is about authority and recovery. These matter more in a fleet than in a pilot, because a change that reaches ten machines at once removes the comparison that would have told you something was wrong.

• Who decides that an update is applied to our machines? Name the party. If it is the manufacturer, say so in the contract; if it is the operator, make sure the manufacturer's process actually permits it.
• What notice do we get, and in what form? A release note published on a website is not notice to an operator. A named contact and a lead time is.
• Can we roll back? To which version, by whom, how long does it take, and does rolling back void anything.
• What is validated before an update reaches a production floor, and by whom? Ask specifically whether validation is performed on a configuration resembling yours, or only in the manufacturer's own environment.
• If the machine behaves differently after an update, whose defect is it? This is a commercial question with a technical surface, and it is far cheaper to settle in the contract than in the incident.
• What happens to our site configuration and maps across an update? Preserved, migrated automatically, or re-recorded on site — the three answers have very different costs.

Where a learned model rather than conventional control logic is involved, an update is a change in behaviour rather than a fix, and the acceptance problem changes shape entirely. The staged validation chain that follows from that — evaluation against historical data, shadow operation, controlled release — is set out in learned robot policies, acceptance and the safety case, and those articles should be read together with this one.

An answer given in a meeting is not an answer. In the absence of a standard to point at, the only durable form is contractual, and the drafting is not elaborate.

1. An update policy as an annex, not a clause. The list of what can change, who decides, what notice is given, and the rollback path. One page is enough.
2. A named maintenance period for the release line, with what happens at its end: continued security fixes, a migration path, or nothing. All three are acceptable answers; silence is not.
3. A pinning or deferral right for sites that need one, with the conditions under which it lapses.
4. Treatment of site configuration and maps across updates, stated explicitly rather than assumed.
5. Where responsibility sits if behaviour changes, so the question is settled before it is expensive.

None of this requires the manufacturer to do anything unusual. It requires the manufacturer to state what it already does, at a point when the operator still has commercial leverage. After the first fleet-wide rollout, the leverage is gone.

One boundary is worth stating outright, because the subject invites the wrong kind of article.

This is not advice on choosing update tooling. There is a mature field of open-source and commercial software for delivering updates to embedded devices, and comparing those systems is a legitimate exercise — for whoever is building the robot. An operator running a mixed fleet does not select that layer, does not install it and does not maintain it. It arrives inside the machine, chosen by the manufacturer.

werob does not build or sell an update system and takes no position on which one a manufacturer should use. It builds no hardware and no embedded software. What an integrator can do here is narrow and useful: make sure the questions above are asked while there is still a negotiation, make sure the answers land in the specification rather than in an inbox, and make sure the same questions are put to every manufacturer in a mixed fleet rather than only to the one whose documentation happened to be easiest to read.

The related question of how long the hardware underneath will be available at all is covered in the compute module in your robot has a published end date.