The Vehicle Signal Specification — a standardized, hierarchical catalog of vehicle signals (Vehicle.Speed, Vehicle.Cabin.Door…) with an overlay mechanism and code-generation tooling.
Why it matters: the shared vocabulary. Every layer above it references VSS paths, which means an agent has a machine-readable contract to reason and generate against instead of a per-OEM signal soup.
A Rust gRPC broker that serves current and target vehicle-signal values using the VSS model — the in-vehicle data hub apps and services read from and write to.
Why it matters: the reference implementation of the SDV data layer, with a clean gRPC surface. An agent can wire a provider or a consumer against it without reinventing the abstraction.
A transport-agnostic communication layer (originated at GM/COVESA) for vehicle and vehicle-to-cloud service interaction — a uniform addressing and messaging model across SOME/IP, MQTT, Zenoh and more.
Why it matters: it standardizes how services talk regardless of the wire underneath — the kind of uniform interface an agent can target once and reuse across transports.
The widely used C++ implementation of SOME/IP — the automotive service-oriented middleware protocol for on-board service discovery and RPC/eventing.
Why it matters: SOME/IP is the incumbent in-vehicle SOA bus. A real open implementation lets an agent generate, run and test service stubs against the protocol the ECUs actually speak.
A high-level C++ API framework over SOME/IP (and D-Bus) that generates client/server bindings from Franca IDL interface definitions.
Why it matters: IDL-in, code-out is exactly the deterministic seam an agent thrives on — describe the interface, let the toolchain generate the binding, verify it compiles and runs.
A Rust pub/sub/query protocol that unifies data in motion, data at rest and computations — a low-overhead alternative middleware for vehicle and robotics comms (also a ROS 2 RMW option).
Why it matters: it collapses messaging, storage and query into one API that scales from MCU to cloud — fewer moving parts for an agent to reason about across the vehicle-to-cloud boundary.
True zero-copy, lock-free inter-process communication (the Rust successor to iceoryx) for safety-oriented, high-throughput on-board data paths like perception and sensor fusion.
Why it matters: when the SDV workload is bandwidth-bound, this is the transport under the transport. An agent building a perception pipeline needs the zero-copy path, not a socket copy per frame.
A workload orchestrator for automotive HPCs and in-vehicle compute — think a lightweight, deterministic answer to Kubernetes for managing containerized and native vehicle workloads.
Why it matters: the SDV needs something to schedule and supervise the workloads on the high-performance compute. Ankaios gives an agent a declarative manifest to generate against — the orchestration layer of the stack.
The Eclipse Software-Defined Vehicle Working Group — the umbrella coordinating dozens of the projects above (Kuksa, Ankaios, uProtocol, Chariott, SDV blueprints and more) under one governance.
Why it matters: the map. Rather than an agent (or engineer) discovering each project cold, the WG is the single index of what's in the open SDV stack and how the pieces are meant to fit.
An Unreal-Engine-based open simulator for autonomous driving, with a Python API for scenarios, sensors and full closed-loop testing of a driving stack.
Why it matters: the proving ground. Its scriptable Python API means an agent can generate a scenario, run the SDV/ADAS stack against it, and read structured results — closing the build-test loop without hardware.
How to read this list: it's a running register, not a leaderboard. Projects sit at very different maturity levels and serve different roles in the stack; the ordering is data-layer-up, not best-to-worst. Verify each against its own repository before adopting. Maintain one of these and want a correction, or your project added? Get in touch — no cost, no spam.