A Software Update Management System is the documented set of processes, roles, and evidence an OEM uses to manage in-vehicle software updates safely and traceably. UNECE R156 requires OEMs to operate one; ISO 24089 is the engineering reference for software-update engineering.

RxSWIN — Regulation x Software Identification Number — links a software version to its regulatory status. UNECE R156 requires OEMs to maintain RxSWIN traceability so the regulator can see which software is installed on which Vehicle Type and whether an update changes its regulatory standing.

Does R156 apply only to over-the-air updates?

No. UNECE R156 applies to all software updates — over-the-air, dealer-installed, and service-tool-installed. The regulator's concern is that the update process is documented, authorised, traceable, and safe, regardless of delivery channel.

← All solutions

SOLUTIONS · OTA & SUMS READINESS

OTA and SUMS readiness for UNECE R156

Structure the Software Update Management System evidence UNECE R156 expects — update authorisation, dependency analysis, RxSWIN traceability, and update-integrity evidence.

See KAVACH On Your ArchitectureRequest A Scoped Demo

WHO THIS PAGE IS FOR

This page is for OEM software-update owners, SUMS owners, and programme managers responsible for software-update governance and UNECE R156 readiness.

THE PROBLEM

UNECE R156 requires OEMs to operate a Software Update Management System and to demonstrate that in-vehicle software updates are safe, authorised, and traceable. The scope spans update authorisation, dependency analysis, RxSWIN identification, and evidence retention — and it intersects with cybersecurity (R155) and software engineering processes.

WHERE THE MANUAL WORKFLOW STRUGGLES

Why spreadsheets stop scaling

SUMS scope blurs across cybersecurity, safety, and software-engineering processes
RxSWIN granularity is interpreted differently across programmes
Dependency analysis is fragmented across requirements, calibration, and certification artefacts
Update authorisation decisions are made in meetings — the rationale is hard to retrieve later
Records-retention obligations outlast the original engineering team's involvement

HOW AGNILE AND KAVACH HELP

An engineering workflow designed to support this

KAVACH connects software-update evidence to cybersecurity work products so update authorisation can be reasoned about with traceable inputs
RxSWIN identification is linked to architecture context, keeping versioning grounded in vehicle reality
Update authorisation decisions are reviewed engineer-in-the-loop; AI-assisted acceleration is configurable
Software-update evidence is structured to support both UNECE R156 and AIS 190 alignment
Agnile Embedded Software and Cybersecurity Engineering services support SUMS process design and readiness reviews

REQUIRED INPUTS

Software-update process description
Dependency information across software, calibration, and configuration
Affected-configuration and Vehicle-Type scope

EXPECTED OUTPUTS

Update authorisation evidence with documented decision criteria
Dependency-analysis records
Software-update traceability and RxSWIN identification

Actual programme outputs depend on scope, architecture, and the engineering review process.

Where to go next

COMPLIANCE

TRUST

PROOF & WORKFLOW

Proof Center→

FAQ

OTA & SUMS Readiness FAQ

See the OTA & SUMS Readiness workflow on your own architecture.

Bring a representative ECU, feature, or system architecture. We'll walk through how the workflow is structured — with honest answers on fit and integration effort.

See KAVACH On Your Architecture

Explore Compliance Hub