When rolling back vehicle software creates another problem

Returning to a previous software version can look like the simplest response to a defective update. In a vehicle, the earlier version may no longer be an appropriate destination. It could reopen a security weakness, misunderstand changed persistent data or conflict with another component that has already moved forward. Recovery needs engineering judgement about the resulting vehicle, not just the component that failed.

Plan recovery before release. The central question is which supported state the vehicle can reach from each plausible interrupted or defective state. That question allows teams to compare rollback, a forward repair and a workshop intervention on their actual consequences.

Distinguish recovery from an attack

Uptane's deployment guidance treats deliberate rollback as an exceptional operation with security implications. A mechanism designed to reject older software should not be weakened casually because an operational team wants a quick remedy. The approved recovery route must preserve the intended trust controls.

Document who can authorise exceptional recovery and which evidence they need. Keep that authority separate from the ability to edit a deployment campaign. Otherwise a routine operating account may acquire the power to override a control whose purpose the account holder does not fully understand.

Inspect the state that will remain

A previous executable does not necessarily restore previous data. New software may have changed a database, calibration representation or stored configuration. Evaluate whether the older component can read that state and whether converting it would lose information needed by other functions.

Also inspect surrounding versions. An update can change several components, with some activating before another fails. The rollback target must be compatible with the components that remain. Maintain a recovery compatibility definition alongside the normal release definition so support teams do not improvise a combination from individually valid images.

Choose the supported destination

A forward repair may be preferable when returning backwards would discard a necessary data migration or reintroduce a serious defect. That choice still needs tested packaging, installation conditions and a way to recognise success. Calling a package a repair does not reduce its integration responsibilities.

Some states may require a workshop. Specify the tools, access and information needed to recover those vehicles. Consider how service staff identify the state without performing additional changes that obscure the original failure. A recovery procedure becomes credible when someone outside the development team can follow it and record a clear outcome.

Rehearse interruption and escalation

Exercise failures at meaningful transition points, including loss of power or connectivity where the design permits such testing. Observe whether the system reports an accurate state and whether operations selects the intended recovery route. Testing only a clean installation followed by a clean rollback misses the awkward states that drive real support work.

Capture the recovery decision and its limits in release evidence. If a path is available only for certain configurations, the deployment system and service documentation should both express that restriction. The business objective is to restore a vehicle to a known, supportable condition. Reusing an older image is merely one possible technique.