Generating and managing RxSWIN for UN R156

What an RxSWIN is, and what generating one means

The RxSWIN — Regulation X Software Identification Number — identifies the R155/R156-relevant software of a vehicle type. It changes when that relevant software changes, and it is declared in the type approval. That one-sentence definition is covered more broadly in RxSWIN explained; this article is about the practical work of creating one and keeping it correct through the life of a programme.

Generating an RxSWIN is not a build step that spits out a hash. It is a configuration-management decision. You decide which software in the vehicle is regulation-relevant, you draw a scope around it, you assign it an identifier, and you declare that identifier at type approval. The value itself is chosen by the manufacturer; what matters to the assessor is that the scope is defensible and that the identifier reliably changes when — and only when — the software inside that scope changes.

Drawing the scope is the real decision

The hardest and most consequential part of RxSWIN management is deciding what it covers. Draw the scope too wide and every trivial change forces an RxSWIN update and possibly an approval extension, which makes ordinary software maintenance painfully slow. Draw it too narrow and a change that actually affects a regulated function slips through without updating the identifier, which is a compliance failure waiting to be found at audit.

The regulation-relevant set is the software whose change could affect a type-approval-relevant function. Everything else — infotainment skins, non-regulated convenience features — can sit outside the RxSWIN scope. The line between the two has to be documented and justified, because the approval authority will ask why a given element is in or out.

Scoping choice	Consequence	When it bites
Scope too wide	RxSWIN churns on trivial changes; frequent approval extensions	Every routine software release
Scope too narrow	Regulated change escapes the identifier	At audit, or after a field issue
Scope well-drawn but undocumented	Cannot justify what is in or out	When the assessor asks "why this set?"
Scope well-drawn and documented	Changes map cleanly to RxSWIN decisions	Sustainable across the programme

One RxSWIN, or several

A type may carry a single RxSWIN or several, depending on how the regulation-relevant software is structured. Splitting into multiple RxSWINs — for example, along the boundaries of independently updatable subsystems — can reduce the blast radius of a change so that updating one subsystem does not force a re-declaration of everything. This is an architecture decision as much as a compliance one, and it should be made early, because restructuring RxSWINs late in a programme is expensive.

Keeping it correct across updates

An RxSWIN is only useful if it stays honest. That requires configuration-management discipline: a reliable mapping from every software element to the RxSWIN it belongs to, and a release process that checks, for each change, whether it touches regulation-relevant software. The workflow is:

1. A change is proposed to some software element.
2. Configuration management determines whether that element is within an RxSWIN scope.
3. If it is, the RxSWIN is updated and the change is assessed for its effect on type-approval-relevant functions.
4. If the effect requires it, a type-approval extension is obtained before release.
5. The decision, the RxSWIN change and the approval status are recorded.

This process sits inside the secure update workflow rather than beside it — the RxSWIN decision is one of the gates an update passes through before it can be signed and released, as set out in the secure OTA update workflow.

Why this is a SUMS obligation, not a spreadsheet

It is tempting to manage RxSWIN in a spreadsheet maintained by one engineer. That does not survive an assessment. The SUMS has to demonstrate that RxSWIN management is a process with defined ownership, inputs, decisions and records — the same standard applied across SUMS documentation. The assessor will trace a real software change from proposal to release and check that the RxSWIN moved correctly, that the scope decision was justified, and that the records exist. A brittle manual tracker fails that trace the moment the responsible person is on leave.

Common failure modes

Three recurring problems account for most RxSWIN findings. First, scope drift: the regulation-relevant set is defined once and never revisited as the software evolves, so it slowly stops matching reality. Second, silent changes: a regulated element is modified without triggering an RxSWIN update because the mapping from element to RxSWIN was incomplete. Third, no traceability: the RxSWIN changes but there is no record explaining what changed or whether an approval extension was needed. Each is a configuration-management weakness, and each is avoidable with a maintained mapping and a release gate that actually checks it.

The tooling matters less than the discipline. A well-run RxSWIN can be maintained in a modest configuration-management system, provided the mapping from software element to identifier is complete, the release gate is enforced on every change, and the decisions are recorded as they are made. An expensive tool applied without that discipline still produces scope drift and silent changes; a simple one applied with it produces a trace an assessor can follow. The habit to build is that no software change reaches release without first passing the question of whether it touches the regulation-relevant set.

The AutoSifu view

We treat RxSWIN as the spine of R156 and AIS-190 compliance, not a form to fill in at the end. On one route we map the regulation-relevant scope, build the configuration-management and release-gate process that keeps the identifier honest, and prepare the CoC and VTA evidence around it. With CIRT alongside us, the approval body sees the scoping logic while it is still adjustable, which is far cheaper than discovering at assessment that the scope was drawn wrong.