Where does diagnostics fit in the AGL SoDeV stack?
Automotive Grade Linux released the initial version of SoDeV — an open-source software-defined-vehicle reference platform, shipped in the AGL Unified Code Base release codenamed "Ultimate Unagi." If you build vehicle software, the announcement is worth reading closely — not for what is in it, but for a specific thing that is not.
What SoDeV is
SoDeV is AGL's answer to the SDV reference-platform question: a virtualisation-first stack for vehicle compute. The architectural bets are visible in the component list — hypervisor-based partitioning, standardised virtual device access, and, notably for readers of this blog, Zephyr as the RTOS for the real-time guest domains. The design goal is explicitly hardware-optional: the platform is meant to run on virtual machines and cloud processors as first-class targets, not only on physical ECUs.
Two things about that are worth underlining.
First, Zephyr's role. When a Linux Foundation vehicle platform picks Zephyr for its real-time domains, the "is Zephyr automotive-grade?" debate is effectively over. The mixed-criticality pattern — Linux for compute, Zephyr guests for real-time and safety-adjacent work — is now the reference architecture, not an experiment.
Second, the hardware-optional stance. SoDeV treats a virtual vehicle as a legitimate development target. That is the same argument we have been making about validation: if the platform can be virtual, the test bench can be too.
What SoDeV is not
SoDeV is a platform layer: compute orchestration, virtualisation, device access, the substrate applications run on. Scan the published component list and there is no diagnostics path in it: AGL UCB, Linux containers, VirtIO, Xen, Yocto, Zephyr, ELISA. The question that matters to a team building on the platform is not whether a diagnostics API exists somewhere in the tree — it is whether anything connects one to the vehicle. UDS (ISO 14229), ISO-TP transport, DoIP (ISO 13400-2): that layer is not part of what the platform hands you. That is not an omission; it is a reasonable scoping decision. Diagnostics is an application-layer concern, and reference platforms rightly stop below it.
But every one of those Zephyr guest domains that touches a vehicle function will need a diagnostic interface. The end-of-line production process will demand it. The workshop tester will demand it. The type-approval process will demand it. "The platform does not include diagnostics" does not make the requirement go away — it moves it onto the team building on the platform.
What a SoDeV-based team actually needs
Concretely, if you are standing up an ECU function as a Zephyr guest on a SoDeV-style stack, the diagnostics work looks like this.
A UDS server inside the Zephyr guest. Session management, DID dispatch, DTC storage that survives resets, SecurityAccess. This is the classic multi-week build — unchanged by the fact that the "ECU" is now a VM.
Transport that matches the topology. Inside a virtualised vehicle, the diagnostic path may be CAN (virtualised or physical passthrough), or it may be Ethernet from day one — DoIP to the guest, or SOVD terminating at a gateway on the Linux side with UDS behind it.
A way to validate all of it without the vehicle. This is where SoDeV's hardware-optional philosophy pays off. If the platform runs virtual, your diagnostics validation should run in the same CI as the platform build: virtual buses, simulated ECUs, campaigns as code.
This is, not coincidentally, the shape of our stack: EDS provides the UDS server for the Zephyr guest (CAN/ISO-TP and DoIP from the same handlers, a SOVD descriptor generated from the same config), and TestLab runs the validation campaigns — against a native simulator, a VM, or eventual hardware, the same YAML throughout. We are not competing with SoDeV; we are the layer it deliberately leaves to you.
Update: what that looks like running
Added 2026-10-03. When this was written, the paragraph above was an argument. It is now demonstrated, so here is the evidence rather than the assertion.
Xaloqi's compatibility matrix runs one identical UDS campaign against four ECU variants — CAN and DoIP, across Zephyr and FreeRTOS. Three of the four are validated end to end against real transports, and none of the three needs a board.
The leg that matters for the argument in this post is DoIP on FreeRTOS. It runs a real cross-compiled ARM firmware image under emulation — QEMU mps2-an386, Cortex-M4 — serving DoIP over an emulated SMSC LAN9118 Ethernet MAC, with the real lwIP socket binding above it. The guest's own boot log records the bring-up:
[eds] basic_ecu_doip_freertos boot [eds] board=qemu mps2-an386 cortex-m4f [eds] uds stack init ok [net] tcpip up, lwip 2.2.1 [net] chip id_rev 01180001 [net] ip 10.0.2.15 [net] netif up — DoIP reachable on port 13400
chip id_rev 01180001 is read back from the emulated MAC's ID_REV register rather than printed from a constant — the load-bearing detail, because it distinguishes a driver that reached hardware from one that merely returned success. CI asserts on the netif up line and fails the leg without it, so it is a gate rather than decoration. The six UDS services then run over that path: TesterPresent, session control, SecurityAccess, DID read, DTC read and clear.
A guest OS image, virtual hardware, a real diagnostic protocol over a real socket, gated in CI, no silicon anywhere. That is the same shape as validating an ECU workload in a guest domain on a partitioned platform — which is the point: the diagnostic layer's validation does not have to wait for the board.
Where that evidence stops, stated plainly, because a claim without boundaries is not evidence. No silicon target — the Zephyr legs run on native_sim and the FreeRTOS leg under emulation. No WCET or timing evidence — emulated execution says nothing about real Cortex-M4 wall-clock behaviour. No production Ethernet driver — the driver targets QEMU's emulated LAN9118, which validates the stack above it and nothing about any particular MCU's peripheral. No ISO 14229 conformance certification — this is a behavioural regression suite over six services. And one of the four variants is not validated at all: CAN on FreeRTOS, because the QEMU target emulates no CAN controller, so there is nothing for a driver or a bridge to bind to. That one is documented rather than quietly omitted.
One boundary worth separating from the rest, since the two are easy to merge into a better-sounding claim than either deserves: no hardware holds for all three validated legs, but reproducible by anyone with no credentials holds only for the in-process virtual check, which is what the repository's badge reflects. The real-transport legs need a TestLab licence in CI. COVERAGE.md is the full statement.
The mixed-criticality question
The more interesting long-term problem SoDeV surfaces: when your ASIL-rated function runs as a Zephyr guest under a hypervisor, where does the safety argument live? AGL is explicit that functional-safety support is a direction of travel, not a shipped feature — it names a collaboration with the ELISA Project to support future ASIL functional-safety applications within SoDeV. That word "future" is the tell. Zephyr's own certification effort scopes the kernel; the hypervisor has its own story; but the application layer — where the diagnostic logic and the DTC records live — is on you today. Freedom-from-interference between guest domains is exactly the kind of claim your safety case will need to address, and platform-level isolation is an input to that argument, not a substitute for application-layer discipline.
That is a topic for its own post. For now the practical takeaway is narrower.
Takeaway
If SoDeV is on your evaluation list: budget for diagnostics as an application-layer work package from day one, because the platform will not hand it to you — and take the hardware-optional philosophy seriously enough to apply it to your validation, not just your runtime.
We followed the discussion at the AGL All Member Meeting in Berlin. If you are building diagnostics on a SoDeV or Zephyr-guest architecture, we would like to hear how you are structuring it.