Software Update Process (End-to-End)

Under UNECE R156, each software update must follow a controlled, documented, and traceable process from planning to post-deployment validation. This page outlines a practical, compliant flow that aligns with ISO 24089 and the cybersecurity expectations of R155.

1) Plan

• Scope & objectives: affected ECUs/software items, functions, markets, VIN cohorts.
• Risk review: safety (ISO 26262), cybersecurity (R155/ISO 21434), EMC (R10), legal/privacy.
• Eligibility & dependencies: required versions, power/charging, connectivity, inter-ECU order.
• Rollback criteria: technical triggers and business thresholds to abort or revert.
• Communications plan: dealers/customers/regulators; instructions and timing windows.

2) Package

• Build artifacts: binaries, metadata, SBOM, release notes, known issues.
• Sign packages: apply approved signing policy; record hashes, versions, and signer IDs.
• Provenance: capture source/commit, tool versions, pipeline run IDs (reproducibility where feasible).
• Anti-rollback: set monotonic versioning/counters; encode prerequisites.

3) Approve

• Gate reviews: security, safety, compliance, localization/market checks.
• Segregation of duties: distinct author, reviewer, approver; dual-control for keys.
• Freeze dossier: lock campaign package (artifacts, eligibility rules, rollout plan).

4) Deliver

Delivery may be OTA or via service tools, but must enforce the same chain of trust.

• Eligibility checks: VIN/ECU targeting, dependencies, battery/network conditions.
• Secure transport: authenticated channels; integrity verification at rest and in transit.
• Staged rollout: canary cohorts → phased expansion; pause on threshold breaches.

5) Install

• Verification: signature and integrity verification on-vehicle; version checks, anti-rollback.
• Transactional update: fail-safe/atomic install patterns; power loss and recovery strategy.
• Audit trail: time-stamped logs; store minimal but sufficient evidence for auditability.

6) Validate (Post-Update)

• Acceptance tests: functional/safety smoke tests, DTC scans, health metrics.
• Telemetry: success/fail/partial, retry rates, error codes; integrity-protected logs.
• Issue handling: link defects/incidents to PSIRT (R155) and corrective follow-ups.

7) Record & Trace

Maintain end-to-end traceability and records for each campaign and VIN:

• Change ⇄ build ⇄ package/signature ⇄ campaign ⇄ VIN/ECU outcome ⇄ post-update validation.
• Timestamps, approvers, hashes, toolchain versions, eligibility decisions, rollback/abort logs.
• Retention according to regulatory and corporate policy; protect against tampering.

8) Rollback / Abort

• Triggers: predefined failure rates, health KPI breaches, critical incidents.
• Mechanisms: known-good images, dual bank/slot strategy, signed rollback packages.
• Comms & evidence: notify impacted parties; capture rationale and timestamps.

9) Improve

• Metrics: success/abort rates, MTTR, verification failures, pre-vs-post defect detection.
• Lessons learned: feed into SUMS/CSMS, update risk criteria, adjust test depth (e.g., fuzzing).
• Training: refresh role-based training and playbooks based on outcomes.

Cross-Cutting Requirements

Typical Outputs / Evidence

• Campaign dossier: scope, risk reviews, eligibility, dependencies, rollout plan, comms templates.
• Signed package set: binaries, metadata, SBOM, hashes, signature records.
• Gate approvals & segregation records; toolchain inventory and approvals.
• Deployment logs: VIN/ECU outcomes, retries, error codes; post-update validation results.
• Rollback/abort records; lessons-learned and CAPA items; updated training logs.