UNECE WP.29 R156

Per R156: Interaction with R155 cybersecurity processes + lifecycle management + maintain coordination with CSMS.

• R156 evidence for UNECER156-4

• SUMS + RxSWIN + R155 linkage partial

Per UNECE WP.29 R156: Software Updates Management System (SUMS) + manufacturer demonstrates processes + manage software updates throughout vehicle lifecycle + change management + competence of personnel + audit.

• R156 evidence for UNECER156-1

• SUMS + RxSWIN + R155 linkage partial

The manufacturer shall maintain documentation of updates, including the affected vehicles, their pre-update and post-update software status, the date and time of execution, and the outcome.

• Update event log per vehicle and per campaign
• Retention schedule for update records
• Procedure to provide records to approval authority and customers on request
• Integrity protection of records (hashing or write-once)

• Records held in vendor systems with no extraction procedure
• Retention too short to cover vehicle service life
• No integrity protection on update logs

The Regulation X Software Identification Number shall be defined to identify the software relevant to a regulation. Changes to that software shall be reflected by a new RXSWIN where the regulation requires it.

• RXSWIN management procedure with naming and versioning rules
• Mapping of RXSWINs to UN regulations and ECUs
• Readout procedure for inspection authorities
• Records of RXSWIN updates and approval authority notifications

• RXSWIN cannot be read out at roadside without manufacturer tools
• Mapping table incomplete for older vehicle types
• Versioning collisions between markets

The vehicle manufacturer shall establish a Software Update Management System and demonstrate compliance through a Certificate of Compliance for SUMS. The SUMS shall cover processes for the management of software updates throughout the vehicle lifecycle.

• SUMS scope statement and policy signed by senior management
• Certificate of Compliance for SUMS issued by approval authority or technical service
• Organisation chart with software update roles and responsibilities
• Lifecycle process map covering update planning, delivery, and post-update verification

• SUMS scope excludes certain ECUs or markets without justification
• Senior management signoff absent
• Process owners undefined for in-life updates

Where software is delivered by suppliers, the manufacturer remains responsible and shall manage suppliers so that SUMS requirements are met across the supply chain.

• Supplier software interface agreements
• Acceptance testing of supplier-delivered updates
• Joint configuration management procedure with key suppliers
• Supplier audit or assessment reports for software delivery

• Supplier delivers binaries with no source provenance information
• Acceptance testing focused on functionality, not on update behaviour
• Joint configuration management informal

Per R156: vehicle type approval + RxSWIN (Regulation X Software Identification Number) + Extension of type approval after software update + maintain SUMS certificate.

• R156 evidence for UNECER156-2

• SUMS + RxSWIN + R155 linkage partial

The manufacturer shall cooperate with market surveillance and approval authorities, including providing information about updates and outcomes, and supporting in-service conformity checks.

• Point of contact register for approval authorities
• Standard report templates for in-service updates
• Records of responses to authority requests
• Coordination procedure across markets

• No single point of contact published for authorities
• Inconsistent reporting between markets
• Response times not tracked against authority requirements

The manufacturer shall assess the impact of the update on type approval, including emissions, safety, and any other regulation-relevant parameters, and determine if the update affects RXSWIN or requires extension of the type approval.

• Impact assessment template covering regulatory baselines
• Sign-off records for impact assessments
• Notification log to approval authority when required
• Mapping between affected parameters and approval certificates

• Impact assessment performed only for safety, not for emissions
• RXSWIN not incremented despite regulation-relevant change
• Notifications to approval authority missed for cross-border type approvals

For updates delivered over the air, the manufacturer shall implement additional safeguards including secure communication channels, restoration of the original software if the update fails, and provisions where execution while driving could affect vehicle safety.

• OTA channel security design including transport encryption and authentication
• Driving-state policy controlling when updates may be applied
• Recovery test reports for OTA failures
• Restoration evidence showing prior software state preserved

• Updates can affect functions while driving without driver acknowledgement
• No documented restoration testing on OTA failure paths
• OTA channel relies on TLS with no certificate pinning

Before an update is executed, the manufacturer shall verify that the update is compatible with the vehicle configuration and that dependencies on other software, hardware, and calibrations are satisfied.

• Compatibility matrices for each update campaign
• Pre-flight check logic in the OTA system
• Test reports for representative configurations
• Procedure to block incompatible target vehicles

• Compatibility checked at fleet level, not at individual vehicle level
• Incompatible variants reach an attempted install before failing
• Calibration dependencies missed

The manufacturer shall ensure that the update can be executed safely and reliably, including conditions under which an update may be attempted, conditions that prevent execution, and recovery in the event of failure.

• Precondition list (battery state, parked, key out, etc.)
• Failure mode analysis for interrupted updates
• Rollback or recovery procedures and test evidence
• Service action plan when remote recovery fails

• Updates can run when battery state is borderline
• No tested rollback path for safety-relevant ECUs
• Service network not trained on recovery procedure

The manufacturer shall ensure the integrity and authenticity of the software update so that the integrity and authenticity can be reasonably assured against compromise, including any infrastructure used to deliver updates.

• Code signing key management procedure with separation of duties
• Pipeline security controls from build to distribution
• Verification logic in ECUs documented and tested
• Tamper detection on update servers

• Signing keys held by a single individual
• Pipeline includes manual steps with no audit trail
• ECUs accept unsigned updates in test mode that remains enabled

The manufacturer shall record and maintain hardware and software versions for each vehicle type, including dependencies between software components, calibration data, and the relationship to type-approval-relevant parameters.

• RXSWIN register linking software identification to type approval
• Software bill of materials per ECU including suppliers
• Dependency matrix between modules and calibrations
• Procedure to update RXSWIN when relevant software changes

• RXSWIN updated late or not at all after a relevant change
• Calibration data not treated as part of the software baseline
• SBOM available for some ECUs only

Per R156: secure update process + vehicle owner information + minimisation of safety impact + protection against unauthorised updates.

• R156 evidence for UNECER156-3

• SUMS + RxSWIN + R155 linkage partial

Where telemetry is collected to support software updates, the manufacturer shall apply data minimisation and protect personal data in accordance with applicable law, while still meeting the SUMS evidence requirements.

• Data inventory for update-related telemetry
• Privacy impact assessment for update logging
• Retention and minimisation rules in telemetry pipeline
• Customer-facing privacy notice covering update telemetry

• Update telemetry collects driver behaviour data beyond what is needed
• No retention limit on update logs in cloud backend
• Privacy notice does not mention update telemetry

The vehicle user shall be informed about an update prior to its execution where relevant, including purpose, expected duration, vehicle functions affected, and successful or unsuccessful completion of the update.

• HMI flow showing pre-update and post-update messages
• Translated user communication templates per market
• Logs of user notifications and acknowledgements
• Owner manual sections describing the update process

• User notification not translated to local languages
• No record of user acknowledgement before safety-relevant updates
• Owner manual silent on OTA process