UN Regulation No 156: software updates and software update management system

After a satisfactory assessment by the approval authority or its technical service and receipt of a signed declaration in the Annex 1 Appendix 1 model, a SUMS certificate of compliance in the Annex 4 model is issued, valid for a maximum of three years from issue unless withdrawn. At the end of the validity period the authority issues a new certificate or extends it for a further three years after a positive assessment, and issues a new certificate where changes brought to its attention have been positively re-assessed. Information relevant to the Regulation must be documented and securely held at the manufacturer and made available to the authority or technical service on request.

Applies when

Vehicle manufacturers applying for software update type approval.

Evidence to retain

• · SUMS certificate of compliance (Annex 4 model) and validity tracker
• · Signed manufacturer declaration in the Annex 1 Appendix 1 model
• · SUMS assessment report and non-conformity closure records
• · Procedure for securely holding and retrieving the documentation relevant to the Regulation

Estimated first-time effort: 40–120 person-days (estimate, not a commitment)

The RXSWIN is a dedicated identifier defined by the manufacturer representing information about the type-approval relevant software of the electronic control system. Each RXSWIN must be uniquely identifiable and must be updated when the manufacturer modifies type-approval relevant software in a way that leads to an extension or a new approval. Each RXSWIN must be easily readable in a standardised way through an electronic communication interface, at least the OBD port. Where RXSWINs are not held on the vehicle, the manufacturer must declare the software versions of the vehicle or individual ECUs and their link to the relevant approvals to the approval authority, update that declaration at each version change, and still make the versions readable in a standardised way through an electronic interface. The manufacturer must protect the RXSWINs and software versions on the vehicle against unauthorised modification and provide the protection means confidentially at type approval.

Applies when

Vehicle manufacturers, cascaded to Chinese suppliers providing ECU firmware and version identifiers; aftermarket reflashing and unauthorised tuning must be designed out.

Evidence to retain

• · RXSWIN definition document and the mapping of vehicle type to RXSWIN to type approval
• · Verification record for reading the RXSWIN through the OBD or electronic interface
• · Confidential design description and test report for tamper protection of RXSWINs and software versions
• · Where RXSWINs are not held on the vehicle, the software version declarations to the approval authority and their update log

Estimated first-time effort: 20–60 person-days (estimate, not a commitment)

The manufacturer must have a process to assess, identify and record whether a software update affects any other system required for the safe and continued operation of the vehicle, or adds or alters vehicle functionality compared with when it was registered. For every RXSWIN there must be an auditable register describing all software relevant to that RXSWIN before and after an update, including the software versions and their integrity validation data. Together these form the working papers for deciding whether an OTA update requires an extension or a new approval.

Applies when

Vehicle manufacturers and their OTA platform operators; teams shipping feature subscriptions or remote unlocks must use the same assessment process.

Evidence to retain

• · Update impact assessment template and per-release assessment records
• · Auditable software register per RXSWIN, with pre- and post-update versions and integrity validation data
• · Conclusions on whether an extension or new approval is needed, and the related submissions
• · Access control and retention policy for the register

Estimated first-time effort: 15–45 person-days (estimate, not a commitment)

For over-the-air updates the manufacturer must ensure that the vehicle can restore systems to their previous version if an update fails or is interrupted, or that the vehicle can be placed into a safe state. The manufacturer must have a process by which the vehicle user can be informed about updates, and must provide any instructions that help the user safely execute the update. These two requirements drive the OTA release strategy for exported fleets: update windows, prohibition of updating while driving, user confirmation and prompt wording.

Applies when

Vehicle manufacturers and OTA platform operators; user-facing prompts must be localised into the local language and to local information duties.

Evidence to retain

• · Design description for rollback or safe state on failure, with interrupted-power and lost-connection test reports
• · User notification process and finalised prompt copy in each language
• · Safe execution instructions (preconditions, duration, whether the vehicle can be used)
• · Staged rollout and rollback drill records

Estimated first-time effort: 10–30 person-days (estimate, not a commitment)