AIS-190 vs UN R156: what's the same, what's not

The short answer

AIS-190 is aligned to UN R156. Both centre a Software Update Management System (SUMS), both rely on RxSWIN to tie software to the approval, and both demand integrity and records for every update — over-the-air or at a workshop. The engineering an OEM has to do is, for practical purposes, identical. What differs is the regime: AIS-190 is an Indian national standard assessed in India, while R156 is a UNECE regulation recognised among Contracting Parties. If you hold one, you have done most of the work for the other, but you still need the other's assessment.

Same core, same vocabulary

R156 and AIS-190 share the concepts that make a software-update regime auditable:

• The SUMS itself — a governed process covering preparation, authorisation, delivery, failure handling and records, not merely an OTA platform.
• RxSWIN — the identifier for the regulation-relevant software of a type, declared in the approval and updated when that software changes.
• Integrity and authenticity — the vehicle must be able to trust that an update is the one the OEM built and that it arrived intact.
• Safe failure — a defined safe state and recovery path when an update does not complete.
• Records — evidence that the process ran on real updates.

The engineering standard beneath both is ISO 24089:2023, Road vehicles — Software update engineering. A team that has built a real R156 SUMS has, in engineering terms, built the substance of AIS-190. We walk through the standard on its own terms in AIS-190 explained and UN R156 explained.

Where they diverge

As with the cybersecurity pair, the differences are institutional.

Dimension	UN R156	AIS-190
Type of instrument	UNECE regulation under the 1958 Agreement	Indian national standard (AIS) under the CMVR
Issued / maintained by	UNECE WP.29	ARAI for the AISC under the CMVR-TSC
Underlying engineering	ISO 24089:2023	ISO 24089:2023
SUMS certificate	Certificate of Compliance for the SUMS plus type approval	Assessed under the Indian regime
RxSWIN	Required; declared in the approval	Required; same concept
Scope (OTA vs workshop)	Both — SUMS applies regardless of channel	Both — SUMS applies regardless of channel
Recognition	Travels among UNECE Contracting Parties	Confers Indian approval
Enforcement dates	EU: new types Jul 2022, all vehicles Jul 2024	India: draft G.S.R. 503(E) — phased Oct 2026 → Oct 2029, not yet final
Cybersecurity sibling	UN R155	AIS-189

Two points to underline.

Recognition does not transfer. A UNECE SUMS approval is recognised among Contracting Parties; an Indian approval confers Indian approval. An OEM exporting from India to UNECE markets therefore carries both, even though the SUMS is the same.

Dates. R156 dates have already applied in the EU. AIS-190 enforcement is proposed in MoRTH draft G.S.R. 503(E) (17 June 2026) — phased from October 2026 — but not yet finalised in the gazette, so treat those dates as a planning baseline rather than a settled deadline.

Non-OTA is in scope for both

A recurring misconception is that these standards only bite if a vehicle updates over the air. They do not. Under both R156 and AIS-190 the SUMS applies whether an update is pushed remotely or flashed by a technician. RxSWIN, integrity of the update, and records are all still required; the OTA case simply adds authenticated remote delivery and over-the-air rollback to the same obligations.

RxSWIN is where most of the real work lives

If there is one place the shared engineering of R156 and AIS-190 becomes concrete, it is RxSWIN. Declaring an identifier in the approval is trivial; keeping it correct across the life of a fleet is not. It demands configuration-management discipline: knowing exactly which software on each vehicle type is regulation-relevant, versioning it, and updating both the RxSWIN and the approval when that software moves. An OEM that treats RxSWIN as a label to be filled in once will find its update records no longer map to its approvals within a release cycle or two.

Both standards also expect the update process to prove it can fail safely. An update that bricks an ECU, or that leaves a vehicle in an undefined state, is a safety problem as much as a compliance one. R156 and AIS-190 therefore ask for a defined safe state and a recovery path, with evidence that the behaviour has been tested — not merely asserted. This is the point at which the software-update file and the cybersecurity file most obviously interlock, because a failed or malicious update is exactly the kind of event a CSMS is meant to detect and respond to.

Carrying both files

The playbook mirrors the cybersecurity standards — see AIS-189 vs UN R155 for the parallel argument. Build one SUMS, keep RxSWIN correct across configurations, and plan for two assessments rather than two engineering programmes. Because the software-update file and the cybersecurity file interlock — monitoring finds the problem, the SUMS ships the fix — the two are best run as a single programme with shared owners and shared records.

The AutoSifu view

AutoSifu delivers the software-update file as part of one route — compliance, secure solutioning, and CoC/VTA support — so an OEM builds a single SUMS and takes it to whichever venue a market requires. With CIRT as a strategic partner, and as co-builder of India's first SUMS workshop at CIRT Pune, we keep the approval body in the room from the outset. That is the shortest path from an R156 SUMS to an AIS-190 assessment, and from either to a certificate.