All posts
Engineering · · 6 min read

From ARXML to a running UDS server in one sitting

There is a specific kind of engineer this post is for. You have an AUTOSAR ECU Extract — an ARXML file, probably exported from an OEM's toolchain — that defines the diagnostic interface your ECU is contractually required to implement. Dozens of DIDs, a DTC list, session and security constraints. And you are building the ECU on Zephyr or FreeRTOS, not on a Classic AUTOSAR stack, because the project does not justify the licence cost or the RTE.

The default path is grim: a human reads the ARXML and hand-transcribes it into whatever the diagnostics implementation expects. It takes days, and every transcription is a chance to ship a DID with the wrong length or a DTC with the wrong code — the kind of bug the OEM's conformance tester finds three months later.

The ARXML is machine-readable. It should be machine-read.

The pipeline

EDS's diagnostic interface is a YAML file, and everything else — the C implementation, the safety wrappers, the pytest suite, the SOVD descriptor — is generated from it. So the ARXML problem reduces to one translation: ECU Extract in, diagnostics_config.yaml out. That is what the importer does.

python3 tools/arxml_parser.py \
    --input  ecu_extract.arxml \
    --output diagnostics_config.yaml

The importer extracts the ECU name, DIDs, sessions, security levels, DTCs, and routines, across AUTOSAR 4.0–4.5 namespace variants, using only Python's standard-library XML parser — no external dependency. From there it is the standard EDS flow. Generate:

python3 tools/codegen.py \
    --config diagnostics_config.yaml \
    --out    generated/ \
    --safety-wrappers --asil-level B --test-gen

Build and run — no hardware needed for the first smoke test:

west build -b native_sim examples/basic_ecu \
    -- -DDTC_OVERLAY_FILE=boards/native_sim.overlay
west build -t run

And validate, with a campaign that walks every imported DID:

# campaigns/arxml_conformance.yaml
jobs:
  imported_interface_check:
    description: Every DID from the ECU Extract, exercised
    on_failure:  continue
    steps:
      - action: session
        value:  extended
      - action: security_access
        level:  1
      - action: foreach_did
        min_session: extended
      - action: read_dtc
testlab-run --config diagnostics_config.yaml \
            --campaign campaigns/arxml_conformance.yaml \
            --job imported_interface_check \
            --virtual \
            --json reports/arxml_run.json

The foreach_did action is doing the important work: it reads the DID table from the same config the firmware was generated from, so when the ARXML changes and you re-import, the campaign coverage updates itself. --virtual runs the whole thing in-process — this exact command works unchanged in a CI job.

Total elapsed time from "here is the ARXML" to "here is an HTML report showing every DID responding": one sitting. The transcription step — the error-prone one — no longer exists.

What the YAML in the middle buys you

It would have been possible to generate C directly from ARXML. We deliberately did not, and the intermediate YAML matters for three reasons.

It is reviewable. An ECU Extract is thousands of lines of XML nobody reads. The generated YAML is a couple hundred lines a human can diff, review, and commit. When the OEM sends ECU Extract revision B, a git diff on the YAML tells you exactly what changed in your diagnostic contract.

It is the single source for everything downstream. Firmware, test suite, CANoe CAPL scripts, SOVD descriptor — one file drives all of them, so they cannot drift from each other.

It is editable where the ARXML is wrong. Anyone who has worked with real ECU Extracts knows they are sometimes incomplete or internally inconsistent. You fix it in the YAML, note it, and move on — without maintaining a patched fork of the OEM's XML.

Honest scope

An importer like this handles the diagnostic interface definition. It does not make Zephyr an AUTOSAR stack: no RTE, no BSW modules, no DEM/DCM configuration semantics beyond what maps onto UDS. If your contract requires a Classic AUTOSAR implementation, this is not a substitute. If your contract requires an ECU that conforms to the diagnostic interface in the Extract — which is the common case for Tier-2 work — the path above gets you there.

Try it

The importer ships in the EDS Developer tier, and the same import is available in the browser on Xaloqi Cloud (Pro and Team tiers) — upload the ARXML, get the YAML and generated sources back without installing anything. If you have a gnarly ECU Extract that breaks the importer, we want it.

The ARXML importer and code generator are part of the EDS Developer tier; the runtime is GPL v2 on GitHub. Have an ECU Extract that breaks it? Send it over →