Automating UDS diagnostic verification in CI and on HIL

Modern vehicles ship software continuously. A fix in a body-control function, a calibration tweak, a refactor in the communication stack, or a new ECU release can all alter diagnostic behaviour without anyone intending it. The dangerous failures are the quiet ones: a Diagnostic Trouble Code that no longer sets when the fault is real, a clear operation that leaves stale codes behind, a security-access level that silently stops unlocking, a flash sequence that aborts on one block size. None of these show up in a normal functional test, and all of them surface in the workshop or the field, where they are expensive and reputationally costly.

Manual diagnostic verification cannot keep pace with this cadence. By the time a person has worked through a service-by-service checklist, the build under test is already several commits old. The realistic answer is to treat diagnostics as a first-class test target and re-run a regression suite automatically whenever the software changes — exactly the same discipline already applied to the functional code.

Start with UDS service behaviour as defined in ISO 14229. Assert that each supported service and sub-function responds correctly, that session control (0x10) and the session timeout behave, and that negative response codes are returned for the right conditions rather than swallowed.

DTC logic deserves dedicated cases: inject a fault, confirm the code sets with the correct status bits via ReadDTCInformation (0x19), then ClearDiagnosticInformation (0x14) and confirm it clears and does not spuriously reappear. Security access (0x27) should be exercised through its seed-and-key exchange, including the lockout behaviour after failed attempts. The reprogramming path — the canonical 0x10 to 0x27 to RequestDownload (0x34), TransferData (0x36), RequestTransferExit (0x37) sequence — must be run end to end, because a broken bootloader handshake bricks ECUs. Finally, check ODX consistency: the diagnostic description (ISO 22901) and the ECU's real responses must agree, since a drift between data and behaviour breaks every downstream tool.

In a CI pipeline the suite runs against virtual or software-in-the-loop (SIL) ECUs — the compiled ECU software, or a model of it, executing on a host with no physical hardware. This is fast and cheap, so it can run on every commit and every pull request, catching regressions in service logic, DTC handling and ODX consistency within minutes of the change that caused them.

Hardware-in-the-loop (HIL) rigs run the same logical checks against the real ECU, with simulated vehicle and environmental signals fed to it so it behaves as though it were in a car. HIL is slower and more costly, so it typically runs nightly or per release, but it is indispensable: only real silicon exposes timing, bus latency, flash-memory behaviour and the genuine seed-and-key path. SIL and HIL are complements, not alternatives — SIL gives you speed and breadth, HIL gives you fidelity.

The point of a regression suite is that a fix in one area cannot quietly break diagnostics in another. When every DTC, every security level, every flash step and every ODX assertion lives in a maintained, version-controlled suite, a change that disturbs an unrelated diagnostic is caught by a red build rather than by a customer. The suite becomes the executable specification of how the vehicle's diagnostics are supposed to behave, and it grows with the product instead of decaying.

This is the work Diadrom's Dolphin is built for: a diagnostic test-automation tool that plugs into CI chains and drives these scenarios against both virtual and real ECUs, so the same cases run in the pipeline and on the rig.

Automated diagnostic verification moves defect detection to the left, where defects are cheap. A broken DTC caught on a pull request costs minutes; the same defect found in a workshop costs a recall investigation. Diadrom's own CI-build-automation work makes the scale of the shift concrete: a build-and-verify cycle that previously took several days of manual effort was compressed to roughly an hour.

That is the real prize. When verification is automatic and continuous, teams stop choosing between shipping quickly and shipping safely. The regression suite makes safety the default, and the speed comes for free.