RXSWIN across ECU variants: easy to define, hard to keep true

RXSWIN stands for RX Software Identification Number, where the RX denotes the UN Regulation whose approval the software affects. It is a dedicated identifier, defined by the vehicle manufacturer, representing the type-approval-relevant software on a vehicle — the software a regulatory approval depends on. UN R156 requires it to be easily readable in a standardised way, at least through the OBD port; where RXSWINs are not held on the vehicle, the manufacturer must declare the software versions to the approval authority instead.

That is the entire definition, and it is why RXSWIN is so often mistaken for a small problem. Writing an identifier into a gateway is trivial engineering. Being able to state, for any vehicle you have ever built, that its identifier is correct — and to show the working — is not.

The most common misreading is to treat an RXSWIN as a version number by another name. A version number identifies one binary in one control unit. An RXSWIN represents a set: all the type-approval-relevant software across the vehicle, bound together under one identifier because one approval depends on all of it.

That difference changes what happens when software changes. A version number increments automatically. An RXSWIN forces a judgement: either this change leaves the approval unaffected and the identifier stands, or it does not and the approval consequence has to be handled. Both answers can be correct; only a recorded rationale makes either defensible. This is the part an approval authority can question, and the part that is hardest to reconstruct after the fact.

Manufacturers do not build a unique control unit for every option pack. They build a generic unit and adapt it to the vehicle, the market and the chosen options through coded values, as we set out in ECU baseline and variant coding. A platform may therefore span thousands of variants — drivetrains, markets, trim levels, regulatory regions, optional features — multiplied across dozens of networked ECUs, all under continuous change as suppliers revise software.

Every one of those buildable combinations has to be mapped to the approved software set it must carry, that mapping has to be settled before type approval, and the correct value has to be written during production on the right vehicles. The scoping decision made early — which ECUs and which software items fall inside a given identifier — determines how much of that matrix you have to manage for the rest of the platform's life. Scope too broadly and routine supplier updates start touching the approval; scope too narrowly and you multiply identifiers to track.

An RXSWIN is only as trustworthy as the record it summarises. The precondition is what ISO 24089 calls vehicle configuration information: the comprehensive accounting of hardware versions, software versions and configuration parameters in each vehicle. Without it there is nothing to resolve an identifier against, and no way to prove a claim about a fleet.

Mechanically, the pieces are familiar diagnostics. Configuration values are addressed by Data Identifiers, written with UDS service 0x2E and read back with 0x22, as defined in ISO 14229. ODX (ISO 22901) gives the vendor-neutral description of those identifiers and the ECU configuration records behind them, so the end-of-line system, the workshop tester and the after-sales tool all interpret the same values the same way. None of this is new work invented by the regulation — it is the baseline discipline that end-of-line programming and workshop reprogramming always needed, now load-bearing for type approval.

The failure mode is drift: a widening gap between the approved record and the as-built or as-maintained state in the field. An undocumented production change, a workshop that recodes a unit off-script, a replacement ECU flashed with the nearest-looking configuration — each opens a gap between what the records say a vehicle is and what it actually is.

Drift has always been expensive, surfacing as no-fault-found returns, failed end-of-line tests and vehicles that behave subtly wrong in ways nobody can trace. What UN R156 changed is the category of the cost. A vehicle whose software state cannot be stated with confidence is no longer only a quality problem; it is a vehicle whose RXSWIN you cannot stand behind. The remedy is unchanged and unglamorous: prevent the gap from opening by managing baseline, coding and update record from one authoritative source, rather than reconstructing the truth after an audit asks for it.

RXSWIN is defined and held by the vehicle manufacturer, who owns the type approval. Suppliers meet it indirectly, through what their components and tooling can evidence. In practice that means an ECU that reports its software and configuration state unambiguously, an update path whose gates hold end to end, and tooling that produces a traceable record of what was written, to which vehicle, and when.

That is the standard we hold our own products to. Autotech Bootloader validates the application at every boot and never erases itself, so an interrupted update is recoverable rather than fatal, and Diag Studio exists to hold one authoritative source for diagnostics and configuration so the same approved definition drives end-of-line and aftermarket alike. Building tooling to support a regulation is not a claim of certification — the approval remains the manufacturer's, and so does the RXSWIN.