// comparison · UDS testing in Python

TestLab Core vs.
udsoncan + python-can.

If you are testing UDS from Python, you have found the established stack. It is good, and this page does not try to talk you out of it — it explains which of the two problems you actually have, and says plainly where udsoncan is the better answer.

pip install xaloqi-tester → TestLab Core on GitHub →

// the actual difference

A client library, or something that answers it.

python-can (the CAN bus layer), can-isotp (ISO 15765-2 transport) and udsoncan (the ISO 14229 client) together form a client. They speak UDS to an ECU that already exists. TestLab Core is a test harness — a campaign runner plus an ECU that answers, so tests can be written and run before any hardware does.

That is the whole distinction. It is not a capability contest, and on raw protocol coverage udsoncan is ahead.

udsoncan + python-can + can-isotpTestLab Core
What it is UDS client library stack Campaign runner + simulated ECU
Something that answers Needs a real ECU. FakeConnection replays a two-entry static dict — enough to smoke-test your own plumbing, not an ECU Stateful simulator: sessions, SecurityAccess seed/key (AES-CMAC), DTCs, NRCs
Real CAN / DoIP hardware Yes, free — socketcan, J2534, every python-can interface Not in core. Core is virtual-transport only; real transports are a paid tier
Raw UDS coverage Broader — 27 services, 91 client methods, including the full ReadDTCInformation sub-function set, 0x29 Authentication and DynamicallyDefineDataIdentifier Focused on the ~20 actions a validation campaign uses
How a test is expressed Write Python Declarative YAML campaign
Pass/fail + timing report Build it yourself Built in — testlab-run, testlab analyze, JSON output
Time to first result A CAN interface and an ECU — or write your own responder pip install xaloqi-tester && xaloqi-sim --demo
License MIT (udsoncan, can-isotp), LGPL-3.0-only (python-can) Apache-2.0

// which one

Where each is the right answer.

Use udsoncan when

  • You have hardware on the bench now and want to drive it for free — TestLab Core's real transports are a paid tier, theirs are not.
  • You need services outside a validation campaign's usual set — ResponseOnEvent, RequestFileTransfer, the deeper ReadDTCInformation sub-functions, LinkControl.
  • You are building an application that happens to speak UDS, rather than running repeatable tests against an ECU.

Use TestLab Core when

  • The ECU does not exist yet, or the bench is occupied, and you still want to write and run the tests.
  • You want the tests to run in CI on every commit, with no hardware and no self-hosted runner.
  • You want tests as reviewable YAML with a pass/fail report, rather than a growing pile of scripts.

They also compose. Nothing stops you developing campaigns against the simulator and driving real hardware with udsoncan — the JSON result schema is documented, and the same campaign YAML runs unmodified on real transports if you later move to TestLab Pro.

// try it

Two commands, no hardware.

TestLab Core is Apache-2.0 and on PyPI. The simulated ECU answers real UDS requests — sessions, SecurityAccess seed/key, DTC reads — so you can judge the difference yourself rather than take this page's word for it.

pip install xaloqi-tester
xaloqi-sim --demo
Read the docs → Do you need AUTOSAR for UDS? →
How this was checked. Verified 2026-09-04 against udsoncan 1.26.1, python-can 4.6.1, can-isotp 2.0.7 and xaloqi-tester 1.5.2, by installing each from PyPI into a clean environment and inspecting the actual APIs — not from documentation. The service and method counts, and FakeConnection's behaviour, were read from the installed packages. If anything here is out of date or wrong, open an issue and it will be corrected.