xaloqi-tester is on PyPI: a UDS ECU in 60 seconds, no hardware

xaloqi-tester — the UDS client, in-process ECU simulator, and campaign runner behind Xaloqi TestLab — is free, Apache-2.0, and on PyPI. No account, no license key, no hardware:

pip install xaloqi-tester
xaloqi-sim --demo

That's a real UDS conversation against a simulated ECU: VIN read, session control, an AES-CMAC SecurityAccess unlock, a security-gated DID read, DTC read — the same protocol traffic a real bench would see, running entirely in a Python process. It works today, on a machine with nothing else installed.

---

Why this exists

UDS without AUTOSAR is a real category — teams building diagnostics on Zephyr or FreeRTOS who don't want to adopt an AUTOSAR Classic RTE just to get session control and security access. What those teams still need is a way to test the diagnostics stack they've built, and until now that meant either real hardware or hand-rolling a UDS client. xaloqi-tester is that client, packaged so trying it costs one command.

The whole surface is Apache-2.0 and stays that way — no time limit, no feature gate hiding behind a trial:

• the async/sync UDS client (xaloqi.tester.UdsTester), including 0x27 SecurityAccess and the 0x34/0x35/0x36/0x37 firmware up/download sequence
• VirtualBus — the in-process transport and simulated ECU (xaloqi.sim)
• the campaign runner (testlab-run) — 20 UDS actions defined as YAML, not code
• testlab analyze — a terminal summary of a run's results

Run a full campaign against the simulated ECU the same way you would against real hardware:

testlab-run --config testlab_config.yaml \
            --campaign campaigns/standalone_validation.yaml \
            --job basic_validation --virtual --json reports/run.json
testlab analyze --results reports/run.json

The campaign YAML doesn't change when you move from --virtual to real hardware — session control, SecurityAccess, DID/memory read-write, DTC handling, firmware transfer are all data, not code. Real transports (SocketCAN, PCAN/Kvaser, DoIP, SOME/IP), the SOVD client, multi-ECU workspaces, and reporting are Pro; core has no license machinery to hit, because it doesn't gate anything.

---

Tested against an independent implementation, not just itself

The obvious question for any test client that also ships its own simulator: does it actually validate against anything other than its own assumptions about the protocol? For xaloqi-tester's DoIP support, the answer is yes, continuously. Xaloqi EDS's CI runs xaloqi-tester's DoipBus — this package, Python — against EDS's DoIP server, a completely separate C implementation, built for Zephyr's native_sim target, on every push to EDS's main. That's a real cross-implementation, cross-language DoIP conversation between two codebases that share nothing but the ISO 13400-2 wire format, not two halves of one project talking to themselves.

---

What this doesn't claim

Core's transports are limited to VirtualBus, which has no timing behavior to get wrong — there's no flow control, no bus arbitration, nothing to simulate badly. Real CAN/DoIP transport pacing against physical hardware is a Pro concern, and it's an area we're actively hardening rather than one we're calling finished. If you're evaluating against real ECUs that pace consecutive frames with BlockSize/STmin, ask before you assume.

---