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 architecture for a diagnostics stack and you will not find one. UDS (ISO 14229), ISO-TP transport, DoIP (ISO 13400-2), SOVD — none of it is in scope. 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.
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 will be following the discussion around 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.