RxSWIN explained: the software identifier UN R155 and R156 rely on

What RxSWIN stands for

RxSWIN means Regulation X Software Identification Number. The "x" is a placeholder for the regulation number — so software relevant to UN R156 is identified by an R156-SWIN, and the same mechanism can identify software relevant to other regulations. It is, at its simplest, a label that says: this defined set of software is the regulation-relevant software of this vehicle type.

That definition contains the whole idea. The RxSWIN does not identify every line of code in the vehicle. It identifies the software whose behaviour bears on compliance with a particular UN regulation. Everything hinges on drawing that boundary correctly — knowing which software is regulation-relevant and which is not.

Why the identifier exists

Before software could be updated in the field, a type approval was a stable thing: the vehicle you approved was the vehicle that stayed on the road. Software changes that. An over-the-air update can alter how an approved system behaves after the vehicle has left the factory. Without a mechanism to track that, an approval would describe a configuration that no longer exists.

The RxSWIN is that mechanism. It ties a defined software configuration to the type approval and is declared as part of it. When you read the approval, the RxSWIN tells you which software state was approved. When the software changes in a way that touches the relevant regulation, the RxSWIN must change too, so the identifier keeps telling the truth about what is running.

This is why RxSWIN sits at the meeting point of two regulations. UN R156 and its Software Update Management System govern how updates are managed; the RxSWIN is what keeps those updates connected to the approval. We cover the update regime in UN R156 explained.

What an RxSWIN must cover

The RxSWIN must cover the regulation-relevant software of the type — no less, and defining it too broadly is as much a problem as defining it too narrowly. Too narrow and you miss software that genuinely affects compliance; too broad and every trivial update forces a re-declaration.

Question	What it determines
Which software is regulation-relevant?	The scope of what the RxSWIN identifies
What is the current approved state?	The value declared in the type approval
Has relevant software changed?	Whether the RxSWIN must be updated
Where is the boundary recorded?	The configuration-management basis for the answer

Getting these answers right, and keeping them right, is a configuration-management exercise more than a paperwork one. The practical mechanics of building and maintaining it are covered in generating and managing RxSWIN for UN R156.

When it has to change

The rule is simple to state: the RxSWIN changes when the regulation-relevant software it identifies changes. A software update that alters behaviour bearing on the relevant regulation requires a new RxSWIN so that the identifier still matches reality.

The corollary matters just as much. A change that does not touch regulation-relevant software does not, by itself, require a new RxSWIN. This is exactly why the boundary has to be drawn with care — you cannot answer "does this update change the RxSWIN?" unless you already know which software is in scope. An organisation without that discipline ends up either re-declaring for every patch or, worse, shipping a change that should have updated the RxSWIN and did not.

Who owns it

The vehicle manufacturer owns the RxSWIN, because the manufacturer holds the type approval. Suppliers provide the component-level information — what their software is, what it does, when it changed — but the OEM is accountable for defining the boundary, declaring the value, and keeping it correct across the life of the type.

That accountability becomes operationally demanding once over-the-air updates are live. Every campaign has to answer the RxSWIN question before it goes out: does this update touch regulation-relevant software, and if so, is the identifier being updated accordingly? This is one of the ways the UN R155 post-approval world differs from the world before software updates — the approval is no longer a fixed snapshot but something the manufacturer has to keep valid.

The AutoSifu view

RxSWIN is where configuration management, the update process and the type approval have to agree, and it is easy for the three to drift apart. AutoSifu treats it as one route: we help draw the regulation-relevant boundary, wire the RxSWIN into the SUMS and change process, and carry it through to the type approval and CoC with our partner CIRT, a named test agency, in the room — so the identifier the assessor sees is the one your update process will actually keep correct.