All posts
Engineering · · 9 min read

Do you need AUTOSAR for UDS?

The question usually arrives late, and phrased as an assumption. A team has an ECU on Zephyr or FreeRTOS, an OEM asks for diagnostics, and someone says: then we need AUTOSAR.

Often they do. Sometimes they are about to adopt an entire platform to obtain one protocol. The two cases look identical from the outside, and the difference is worth twenty minutes before it is worth a year.

The short answer

No. UDS is ISO 14229. It is a diagnostic protocol specification — service identifiers, sub-functions, negative response codes, session and security state. It is transport-agnostic, and on CAN it runs over ISO 15765-2 (ISO-TP). Ethernet uses DoIP, ISO 13400.

Nothing in ISO 14229 references AUTOSAR. An ECU that answers 0x22 with the right bytes in the right time window is conformant, whatever produced those bytes.

The confusion is understandable, because Dcm — the Diagnostic Communication Manager — is where most engineers meet UDS in practice. If your exposure to diagnostics has been through an AUTOSAR Classic stack, then UDS and Dcm are the same thing experientially. They are not the same thing architecturally.

What AUTOSAR actually gives you

This is worth stating plainly, because the honest answer to the title question is sometimes yes.

Dcm does not arrive alone. It sits on the AUTOSAR basic software stack — PduR for routing, CanTp for segmentation, CanIf and the CAN driver beneath, and it reaches application software through the generated RTE. Configuring it is a tooling exercise: ECU configuration, ARXML, and a generation step.

What you get for that is real:

If an OEM contract specifies AUTOSAR deliverables, that settles it. The question is not architectural at that point, it is contractual.

When you probably do need it

When the answer is no

The case where the question is worth asking properly:

In that situation, adopting Classic for UDS means acquiring the platform, the tooling, the licences and the learning curve in order to obtain a protocol that is fully specified in a public standard.

What the alternative looks like

Concretely, because "implement it yourself" is not a plan.

Diagnostics is one of the more generatable parts of an ECU. The DIDs, DTCs, sessions, security levels and routines are data. The dispatch logic around them is mechanical. That shape suits code generation from a declarative description.

Xaloqi EDS is one implementation of that idea: a YAML description of the ECU's diagnostics, and generated C11 targeting Zephyr and FreeRTOS. It implements 19 UDS services, has no RTE, COM or PduR dependency, and does no dynamic allocation in its core, transport, config or platform layers.

dids:
  - id: "0xF190"
    name: VIN
    data_length: 17
    access: [read]
    min_session: default

  - id: "0xF187"
    name: VehicleManufacturerSparePartNumber
    data_length: 16
    access: [read, write]
    min_session: extended
    read_security_level: 1
    write_security_level: 1

That generates the handler table, the session and security checks, and the ISO-TP wiring. What it does not generate is your application logic — reading the actual sensor behind a DID is still yours to write.

You can still speak ARXML

This is the part usually missed in the framing, and it matters if the honest answer is "no AUTOSAR, but the OEM sends us ARXML anyway".

Not using an AUTOSAR runtime does not mean refusing AUTOSAR artefacts. EDS ships an ARXML importer that reads an AUTOSAR 4.x ECU Extract and produces the YAML description directly — DIDs, sessions, security access classes, DTCs and routines. It is deliberately narrow: 4.x only, ECU Extract only, diagnostics subtree only. Everything else in the file is ignored rather than half-understood.

Interoperating with an AUTOSAR toolchain and running an AUTOSAR runtime are separate decisions. Conflating them is what makes the choice look binary when it is not.

We wrote that path up separately in From ARXML to a running UDS server in one sitting.

What you give up

A comparison that only lists advantages is marketing, so:

The question worth asking instead

"Do we need AUTOSAR for UDS?" has a clean technical answer — no, UDS is ISO 14229 — that is not very useful on its own.

The useful version is: are we adopting AUTOSAR for reasons that stand up without diagnostics?

If yes, use Dcm. It is the right tool, and a parallel diagnostics path beside a Classic stack is the genuinely wrong architecture.

If the honest answer is "no, we mostly need UDS", then it is worth knowing that UDS is available without the platform.

Trying it without committing to anything

The cheapest way to settle this is to see UDS working against something, before choosing an architecture. The campaign runner and a simulated ECU are free and Apache-2.0:

pip install xaloqi-tester
xaloqi-sim --demo

That answers real UDS requests — sessions, SecurityAccess seed/key, DTC reads — with no hardware and no CAN interface, so you can write and run diagnostic tests before deciding anything about the ECU side. The Zephyr quickstart takes it to a running ECU in about half an hour.

If you are weighing the Python side specifically — this against udsoncan + python-can — there is a fact-checked comparison that says plainly where udsoncan is the better answer.

EDS is GPL v2 for the runtime, with a commercial licence for the code generator and toolchain. See it on GitHub →