Vehicle Signal Specification (VSS) and Eclipse Kuksa: Software-Defined Vehicle Data Layer Architecture (2026)

Open the CAN database of any two vehicles from the same manufacturer and you will usually find the same physical quantity under different names, scaled differently, sent at different rates, and sometimes on different buses. A feature team that writes “read vehicle speed” ends up writing it once per platform, per model year, per supplier. That duplication is the quiet tax on every connected-car, fleet and in-vehicle app project, and it is the reason the software-defined vehicle (SDV) conversation keeps circling back to one question: what is the stable data contract between the hardware and the software that runs on top of it?

The vehicle signal specification (VSS), maintained by COVESA, is the industry’s most widely referenced answer to the naming half of that question, and Eclipse Kuksa supplies an open-source runtime for the delivery half. Together they give you a logical signal tree, a broker that serves it over gRPC, and feeders that translate legacy CAN into it.

You will leave with a precise mental model of the VSS signal tree and its tooling, how the Kuksa databroker and its kuksa.val.v2 API work, how CAN signals reach the broker, how to stream a filtered subset to the cloud, and where the design breaks down.

What this covers: VSS model and vss-tools, the Kuksa databroker and feeders, a runnable gRPC client, cloud streaming over MQTT or Zenoh, access control and privacy, comparison with ROS 2 and AUTOSAR Adaptive, and the vehicle digital twin.

Context and Background

Vehicles are networks of dozens to over a hundred electronic control units (ECUs). Historically each ECU publishes its data in a bus-specific, supplier-specific format: CAN frames described in a DBC file, LIN or FlexRay schedules, and increasingly service-oriented messages over automotive Ethernet. The previous generation of telematics hid this behind proprietary gateways. Our earlier piece on SAE J1939 for heavy-duty telematics shows one standardised corner of that world: J1939 fixes parameter group numbers (PGNs) and suspect parameter numbers (SPNs) for trucks, so a fleet vendor can decode engine speed across brands. Passenger cars have no equivalent universal signal map, which is the gap VSS addresses at the semantic layer.

Two other pieces of the picture matter. Our walk-through of SOME/IP and service-oriented architecture covers how domain controllers expose services over Ethernet, which is how a modern zonal vehicle moves data between compute nodes. And our article on EV battery telematics shows how state-of-charge, cell temperature and charging signals become cloud analytics. All three raise the same question: when an application, whether an in-vehicle app, a fleet dashboard or a digital twin, asks for “the” battery state, which name, unit and type does it get?

VSS gives the vocabulary. According to the project’s repository, its goal is a common vocabulary for vehicle signals independent of protocol or serialization format, and the catalog and syntax are published under the Mozilla Public License 2.0 (COVESA VSS repository). The documentation site lists version 6.1 as the latest released version at the time of this writing. Because the specification evolves, always pin a version in your build.

Eclipse Kuksa is an open-source project under the Eclipse Foundation, part of the wider Eclipse Software Defined Vehicle (SDV) ecosystem. Its centrepiece is the KUKSA Databroker, written in Rust and published under Apache 2.0, which serves a VSS-modelled signal tree through a language-agnostic gRPC interface (kuksa-databroker repository). The databroker is deliberately a data layer, not a vehicle OS. It stores the latest value of each signal, fans changes out to subscribers, and brokers actuation requests. It does not decode CAN, run business logic or ship to the cloud; separate providers and agents do that.

The Reference Architecture: Signals, Broker and Providers

Short answer: In a VSS and Kuksa architecture, the vehicle signal specification defines a hierarchical, typed catalog of signals; vss-tools compiles that catalog into a machine-readable model; and the Kuksa databroker loads the model, holds the current value of every signal, and exposes read, subscribe and actuate operations over gRPC. Providers write values in, consumers read them out, and nothing needs to know the underlying bus.

Figure 1: The vehicle signal specification toolchain. Vspec source and overlays are compiled by vss-tools into a model the databroker loads; providers publish and consumers subscribe.

Figure 1 shows the pipeline end to end. Source files in the .vspec format, optionally modified by overlay files, are processed by vss-tools (the vspec export command) into JSON, YAML or Protobuf. The databroker loads the resulting metadata at startup, and from then on every signal has a stable path, a type and a place in memory. Everything on the right of the diagram, providers that publish and consumers that subscribe, speaks in terms of that model rather than bus frames.

The VSS signal tree and its entry types

The VSS signal tree is a hierarchy rooted at Vehicle. Interior nodes are branch entries, such as Vehicle.Cabin.Door; leaves are one of three types. The VSS rule set defines them as follows (VSS data entry documentation):

A sensor is read-only. Its value changes over time, and a read returns the current actual value. Vehicle speed is the canonical example.
An actuator is readable and writable. A read returns the actual value, a write sets the desired target, and the actual value may lag, as with a seat that takes seconds to move. If the target is never reached, the vehicle decides how long to keep trying.
An attribute is a static characteristic that does not change within an ignition cycle, such as colour or model, and should rarely change more than once per ignition cycle.

Every entry has three mandatory attributes: type, datatype (not used for branches) and description. Optional attributes include unit, min, max, allowed, default, enum, arraysize, comment (since version 3.0) and pattern, a regular expression for string types (since version 6.0). The documentation notes that min and max cannot be combined with allowed, and that unit cannot be combined with allowed. A minimal entry looks like this:

Vehicle.Speed:
  type: sensor
  datatype: float
  unit: km/h
  description: Vehicle speed.

That is the actual example from the specification, and its brevity is the point. The unit is explicit and machine-readable, the type is fixed, and the semantics (sensor, so read-only) are encoded. A consumer that knows nothing about your CAN topology can still read this value correctly.

Why a tree rather than a flat list

A hierarchical namespace is a design decision with consequences. Paths are human-readable and group related signals, so access policies can be written against sub-trees (grant a diagnostics app read access to Vehicle.Powertrain.* and nothing else). The tree also supports instances, a mechanism for repeating structures. Rather than hand-writing four door entries, the model declares a branch with instance labels such as rows and sides, and the tooling expands it into one leaf per position, for example Vehicle.Cabin.Door.Row1.Left.IsOpen. Instance expansion keeps the specification compact while giving the runtime concrete, addressable leaves.

The trade-off is rigidity. A tree encodes one view of the vehicle, the physical-functional one, and some questions (all signals that belong to the thermal system, say) cut across branches. VSS handles this partly through documentation and tooling rather than through a second hierarchy, so expect to maintain your own mapping layer for cross-cutting groupings.

Extending VSS without forking it

No standard catalog covers every proprietary signal. VSS provides an overlay mechanism, listed in the documentation under extending and customising VSS: you supply additional vspec files that add entries or modify attributes of the base model at compile time. This matters operationally. The alternative, copying the standard catalog and editing it, means every upstream release becomes a merge conflict. With overlays, you pin an upstream version, keep your OEM-specific signals in your own repository, and let vss-tools merge them. The documentation also lists extension profiles for cybersecurity and network serialization, which signals that the project treats those concerns as extensions rather than as part of the core catalog.

vss-tools: the compiler for the model

The vss-tools package turns vspec into usable artefacts. The PyPI page lists release 6.1.0, published on 17 September 2026, requiring Python 3.11 or newer. Its command-line interface has three top-level commands: vspec export converts a model to a target format, vspec compose bundles a model and its dependencies into a snapshot folder, and vspec diff compares two compose snapshots (vss-tools on PyPI). The PyPI page names JSON, YAML and Protobuf output explicitly. Older versions of the tool shipped additional exporters (for example for DDS IDL and GraphQL), but I could not confirm the current exporter list this run, so check vspec export --help for your installed version before depending on one.

The compose and diff pair deserves attention for production teams. A snapshot of a composed model is a reviewable artefact; diffing two snapshots in CI shows exactly which signals were added, removed or retyped between releases, which is the natural gate for a breaking-change policy.

Inside the Kuksa Databroker: API, Semantics and Actuation

The databroker is a single process with an in-memory signal store, a metadata registry built from the VSS model, and one or more API front ends. The repository states that kuksa.val.v2 is enabled by default, kuksa.val.v1 is also enabled but marked deprecated, the older sdv.databroker.v1 API must be switched on with --enable-databroker-v1, and a subset of VISS v2 (the W3C Vehicle Information Service Specification) is offered over WebSocket. The default listen address is http://127.0.0.1:55555. For a local experiment the project shows a Docker run with the --insecure flag, which disables TLS and authorisation and is exactly what you must not ship.

The kuksa.val.v2 API

The v2 API lives in the gRPC package kuksa.val.v2 as a service named VAL. According to the project documentation as summarised by DeepWiki (kuksa.val.v2 API reference), it has these operations:

RPC	Direction	What it does
`GetValue` / `GetValues`	consumer to broker	Latest value of one or several signals
`ListMetadata`	consumer to broker	Metadata under a root path, with a filter
`Subscribe`	consumer to broker, streaming back	Updates keyed by signal path
`SubscribeById`	consumer to broker, streaming back	Updates keyed by numeric signal ID
`PublishValue`	provider to broker	Write a sensor value or an actual actuator value
`Actuate` / `BatchActuate` / `ActuateStream`	consumer to broker	Set a target value on one actuator, several atomically, or via a stream
`OpenProviderStream`	provider to broker, bidirectional	Lets an actuator provider receive requests and report state
`GetServerInfo`	any	Server name, version, commit hash

Two design points stand out. First, the API separates path-based and ID-based access. Paths such as Vehicle.Speed are readable; numeric IDs are compact and avoid string hashing on a hot path. Calls that take a signal ID include GetValue, PublishValue and Actuate, while Subscribe takes paths and SubscribeById takes IDs. A high-rate provider should resolve IDs once through metadata and then publish by ID. Second, there is an explicit provider role. A sensor provider simply calls PublishValue. An actuator provider instead opens a long-lived bidirectional stream, so the broker can push actuation requests to it, which is how the broker knows who owns an actuator.

The documented error codes map onto standard gRPC statuses: NOT_FOUND for an unknown signal, UNAUTHENTICATED for a missing or invalid JWT, PERMISSION_DENIED for insufficient scope, INVALID_ARGUMENT for wrong types or out-of-range values, UNAVAILABLE when no provider is registered for an actuator, DATA_LOSS for a provider communication failure, and ALREADY_EXISTS when a provider is already registered. The UNAVAILABLE case is a real operational signal: it tells a consumer that the actuator exists in the model but nothing in the vehicle currently implements it.

Figure 2: A sensor value flows from provider to subscriber, while an actuation request flows from consumer through the databroker to the actuator provider, and the actual state flows back.

The sequence in the figure above captures the central semantic of the VSS actuator type. The consumer’s Actuate call sets a target. It does not claim success. The actuator provider performs the physical action and later publishes the actual value, which subscribers observe. A well-written application therefore treats actuation as asynchronous: send the request, subscribe to the actual value, and apply its own timeout, because the specification leaves the retry duration to the vehicle.

What the databroker does not guarantee

The databroker keeps the latest value, not history. If a consumer subscribes late, it can read the current value but cannot replay the past. It is also not a safety-rated component: there is no claim in the repository documentation of ASIL certification (ISO 26262), so closed-loop control, braking or steering paths should never depend on it. Treat it as an infotainment-and-services-grade data layer that sits beside, not inside, the real-time control networks. I could not find a published latency or throughput benchmark for the databroker this run, so any figure you see quoted elsewhere should be traced to its source and measured on your own hardware.

A runnable client sketch

The snippet below talks to a local databroker using plain gRPC in Python. It is a sketch, untested here, and the message field names are written from my recollection of the kuksa/val/v2/val.proto file. Generate the stubs from the proto in the repository for your version and adjust names to match the generated code before relying on it.

# pip install grpcio grpcio-tools
# python -m grpc_tools.protoc -I proto --python_out=. --grpc_python_out=. \
#     proto/kuksa/val/v2/val.proto proto/kuksa/val/v2/types.proto
# UNTESTED SKETCH: verify message and field names against your generated stubs.
import time
import grpc
from kuksa.val.v2 import val_pb2, val_pb2_grpc, types_pb2

channel = grpc.insecure_channel("127.0.0.1:55555")  # dev only; use TLS + JWT in production
stub = val_pb2_grpc.VALStub(channel)

# 1. Who am I talking to?
print(stub.GetServerInfo(val_pb2.GetServerInfoRequest()))

# 2. Publish a sensor value as a provider
speed = types_pb2.Datapoint(value=types_pb2.Value(float=87.5))
stub.PublishValue(val_pb2.PublishValueRequest(
    signal_id=types_pb2.SignalID(path="Vehicle.Speed"),
    data_point=speed))

# 3. Read it back
resp = stub.GetValue(val_pb2.GetValueRequest(
    signal_id=types_pb2.SignalID(path="Vehicle.Speed")))
print("speed:", resp.data_point.value.float)

# 4. Subscribe and react to changes (blocks)
sub = stub.Subscribe(val_pb2.SubscribeRequest(
    signal_paths=["Vehicle.Speed"], buffer_size=1))
for update in sub:
    for path, dp in update.entries.items():
        print(time.time(), path, dp.value.float)

Notice the buffer_size parameter on Subscribe. It bounds how many updates the broker buffers for a slow consumer, which is the backpressure knob: a UI that only needs the latest value should use a small buffer so stale data is dropped rather than queued.

Getting Real Signals In: CAN Feeders and Mappings

The VSS model is only useful if something populates it. In most vehicles that something is a provider (older documents call it a feeder) that decodes the existing bus.

The DBC-to-VSS path

The Eclipse Kuksa CAN provider is a Python tool that moves data in both directions: dbc2val (CAN to databroker) and val2dbc (databroker to CAN), with only dbc2val enabled by default (kuksa-can-provider README). In dbc2val mode it reads raw frames from a SocketCAN interface, decodes them using a DBC file, applies a mapping file that links DBC signals to VSS signals, and sends the results to the databroker. It can also replay a CAN dump file instead of a live interface, which suits continuous integration. The mapping file is JSON in VSS syntax with added DBC metadata.

Figure 3: The CAN-to-VSS data path. The provider decodes frames with a DBC file and a mapping, publishes through gRPC, and the databroker fans out to local apps and a cloud uplink agent.

Frames arrive on SocketCAN, the provider decodes them to engineering values using the DBC scaling (factor and offset), the mapping selects the VSS target, and PublishValue writes the result. Downstream, local applications and an uplink agent subscribe to the same tree.

Transformations belong in the mapping, not the app

DBC signals rarely match VSS one to one. A DBC may carry speed in metres per second while VSS wants km/h, may encode a gear as an integer while VSS defines an allowed string set, or may split one logical quantity across two signals. The provider’s mapping is where unit conversion and value translation should live; if you push that into every consuming app, you recreate the original duplication problem. Plan the mapping file as a versioned, tested artefact with its own review process.

Known sharp edges

The README is candid about limits. For val2dbc, every signal inside a CAN frame needs a value, so you must provide defaults (the README mentions a dbc_default_values.json example, which only covers CAN ID 258) for signals with no VSS mapping or no value received yet. The main branch may depend on a pre-release kuksa-client, so pinning dependencies matters. The README example uses a Tesla Model 3 DBC; publicly available DBC files are community-reverse-engineered and are not a licence to ship, so for a production programme you need the OEM’s own database.

There are also structural limits. Polling-rate mismatches are a common issue: a 100 Hz CAN message published at full rate into the broker, then forwarded to the cloud, produces data volumes the uplink cannot sustain. Decide per signal whether to publish on every frame, on change, or at a fixed down-sampled rate, and do it at the provider, close to the source. The README also mentions separate documentation for ELM/OBD-link adapters and SAE J1939, which is useful if you need to prototype on a heavy vehicle or a consumer car through an OBD-II dongle; the J1939 article linked earlier explains why that decode path differs.

Providers beyond CAN

Not every signal originates on CAN. In a zonal architecture many values originate in service-oriented software on Ethernet. A provider can subscribe to SOME/IP events (see the SOME/IP article linked above), translate them to VSS paths and publish into the broker. The same pattern applies to LIN sensors behind a gateway ECU, to a camera-processing application that publishes a derived signal, or to a simulator generating synthetic data for development. The broker does not care, which is the entire point of the abstraction: it decouples producers from consumers in time, in protocol and in team ownership.

From Vehicle to Cloud: Streaming, Access Control and Privacy

A databroker is a local component. Fleet analytics, over-the-air (OTA) campaigns and the vehicle digital twin all live elsewhere, so a second architectural layer moves selected signals off the vehicle.

The uplink agent pattern

The cleanest design is an uplink agent: a small service on the vehicle that is just another databroker consumer. It subscribes to a configured set of paths, filters and down-samples, batches, and publishes to a cloud transport. Keeping this out of the broker has three benefits. The broker stays simple. The agent can be updated and rate-limited independently. And the privacy gate sits in one auditable place.

Figure 4: Vehicle-to-cloud streaming. The uplink agent filters and downsamples, a consent gate drops anything not permitted, and a transport carries the data to ingestion, a time series store and a digital twin.

MQTT or Zenoh as the transport

Two transports dominate open SDV discussions, and they solve different problems.

MQTT is the pragmatic default. It is a lightweight publish-subscribe protocol over TCP with three quality-of-service levels (0 at most once, 1 at least once, 2 exactly once). A persistent session and QoS 1 let a vehicle that drives through a tunnel queue messages and deliver them on reconnect, subject to broker limits. Cloud IoT platforms ingest it natively. Its weak points are the centralised broker, topic design left to you, and a per-message overhead that favours batching.

Eclipse Zenoh is a newer protocol designed to unify data in motion, data at rest and computation across constrained devices, edge and cloud. It can run peer-to-peer on the vehicle network and route through routers toward the cloud, and it supports queries as well as publish-subscribe. I am describing this from the project’s positioning; I did not benchmark it for this article, and you should verify current bridge and plugin maturity for your language and platform before committing. The practical question is topology: if you only need vehicle-to-cloud telemetry, MQTT is usually sufficient and better supported by managed services; if you need in-vehicle, edge and cloud to share one data fabric, Zenoh is worth a proof of concept.

Whichever you choose, topic or key design should follow the VSS path, for example a prefix of vehicle identifier followed by the signal path. That makes the cloud schema a direct image of the on-vehicle one and lets you reuse the same JSON or Protobuf model produced by vss-tools.

Worked data-volume arithmetic (illustrative)

Suppose a provider publishes 200 signals, the average signal changes at 10 Hz, and each update serialises to about 40 bytes including topic and timestamp. That is 200 x 10 x 40 = 80,000 bytes per second, or about 288 MB per hour per vehicle before compression, and roughly 6.9 GB per 24 hours. For a fleet of 10,000 vehicles that is far beyond what a cellular budget tolerates. These figures are illustrative, not measured, but they show why the agent must filter. Send on change with a deadband for slow signals, down-sample to 1 Hz for trend signals, batch into windows, and compress. A reduction from 10 Hz to 1 Hz alone cuts volume by 90 percent, and on-change publishing for mostly static signals such as door state often cuts far more.

Authentication and authorisation in the databroker

The v2 error model includes UNAUTHENTICATED and PERMISSION_DENIED, which reflects a token-based design: clients present a JSON Web Token (JWT, RFC 7519) whose claims grant access to signal paths, and the broker verifies the token signature against a configured public key. The repository contains a jwt folder, and the Docker quick-start uses --insecure to bypass this; the main README does not detail the scopes, and I could not load the user guide this run. Check the current Kuksa documentation for the exact claim names and the flags that enable TLS and token verification before you design your policy.

The architectural lesson holds regardless of syntax. Give each consumer its own identity and the narrowest path grants it needs. A navigation app has no business reading Vehicle.Cabin seat occupancy; an uplink agent should hold read-only access to an allowlist and no actuation rights; an OTA client needs none of this. Combined with tree-structured paths, this gives you least-privilege at signal granularity, a notably better posture than a flat CAN bus where any node can read every frame.

Be honest about the limit: the broker enforces policy on its own API, but it cannot stop a compromised process with direct bus access. Pair it with OS-level isolation (containers or separate VMs), secure boot and a hardware-backed identity for the vehicle, in line with the cybersecurity expectations of UN Regulation No. 155 and ISO/SAE 21434. I am citing those from general knowledge and have not re-verified the clause text this run.

Vehicle data is often personal data. Under the EU General Data Protection Regulation, any information relating to an identified or identifiable natural person is personal data, and a vehicle identification number, location trace or driving-style profile can identify a driver, especially in combination. Practical consequences for the data layer follow:

Minimisation: collect only signals needed for a stated purpose. In architecture terms, the uplink allowlist is a compliance control, not just a bandwidth control.
Purpose and consent: the gate in Figure 4 should evaluate consent per purpose (diagnostics, insurance, product improvement) and drop signals that lack it, on the vehicle, before transmission.
Pseudonymisation: use rotating or purpose-scoped identifiers instead of the VIN in the cloud stream, and keep the mapping in a separate, access-controlled store.
Location precision: reduce GPS granularity or aggregate where the use case allows. Location signals sit under Vehicle.CurrentLocation in the VSS tree, so a path-based rule can single them out.
Retention and deletion: a time series store needs a deletion path keyed by pseudonymous subject.

The EU Data Act, which I understand to have started applying in September 2025, adds access rights to connected-product data for users; I have not verified the details here, so treat that as a pointer to check, not legal guidance. Nothing in this article is legal advice.

How VSS and Kuksa Compare with ROS and AUTOSAR Adaptive

Engineers often ask whether VSS and Kuksa compete with ROS 2 or AUTOSAR Adaptive. They sit at different layers, and the confusion comes from all three moving “data”.

Concern	VSS + Kuksa	ROS 2	AUTOSAR Adaptive
Primary purpose	Standard signal vocabulary and a state broker	Robotics middleware and tooling	Service-oriented platform for high-performance ECUs
Data model	Hierarchical typed tree of signals	Topics, services and actions with IDL message types	Service interfaces defined in the AUTOSAR meta-model
Communication	gRPC to the broker	DDS-based publish-subscribe	Service communication such as SOME/IP and DDS bindings
State semantics	Latest value store with sensor, actuator, attribute roles	Streams of messages, no global state store	Event, field and method services
Real-time and safety	Not safety rated	Real-time possible, safety certification is a separate effort	Designed for production vehicle platforms
Typical user	App developers, cloud and fleet teams	Autonomy and robotics R&D	Tier-1 and OEM platform software

The comparison summarises design intent from general knowledge; it is not a benchmark. The key insight is complementarity. AUTOSAR Adaptive or SOME/IP services carry high-rate inter-ECU communication inside the vehicle. ROS 2 often carries perception and planning data in autonomy stacks. VSS and Kuksa present a stable, curated slice of that world, the signals an app or cloud service is allowed to rely on, in a form that survives hardware changes. A common mistake is trying to route camera frames or lidar through the databroker; it is a value store, not a bulk streaming bus.

One more contrast with the older approach: the W3C VISS standard defines a WebSocket or HTTP interface over a VSS-shaped tree, and Kuksa offers a subset of VISS v2 over WebSocket. gRPC is more efficient and strongly typed for in-vehicle services; VISS is friendlier to web apps. Teams often expose both.

The Vehicle Digital Twin on a VSS Backbone

A vehicle digital twin is a cloud-side model that mirrors the state and behaviour of one vehicle, or a class of vehicles, closely enough to support decisions: predictive maintenance, warranty analytics, feature validation, remote diagnostics. VSS makes this tractable because it supplies the twin’s schema for free. The twin’s state document can be the VSS tree itself, with each leaf carrying a value, a timestamp and a quality flag.

Three layers are worth separating:

Reported state. The last known value of each signal as sent by the uplink agent. This is cheap, mirrors the databroker’s latest-value model, and answers “what is the vehicle doing now, as far as we know?”.
Desired state. For actuators, the target the cloud wants (precondition the cabin, set a charge limit). It maps directly to the VSS actuator semantics of target versus actual, and to the cloud-to-vehicle path via Actuate through an authorised bridge. This is the same shadow pattern used in generic IoT device twins, with the benefit that the vocabulary is standardised.
Derived state and history. Time series, aggregates and model outputs such as battery state-of-health estimates. These are not in the VSS tree by default; you add them with overlays or keep them in the twin’s own namespace.

The EV article linked earlier is a good example of the derived layer. State-of-charge, pack temperature and charging power arrive as VSS-style signals; the twin turns them into degradation estimates. Because the schema is shared across vehicle programmes, one analytics pipeline can serve several platforms, and a new model year needs a new mapping file rather than a new pipeline.

Staleness and trust

A twin is only as good as its freshness. Reported state needs the source timestamp from the provider, not the ingestion time, otherwise buffered data replayed after a connectivity gap looks current. Carry a quality indicator (live, replayed, estimated) and let the twin refuse to act on stale actuator state. Also keep clear that the twin’s desired state is a request, not a command: the vehicle’s own safety logic and the provider decide whether and when to act.

Simulation and test benefits

Because VSS is protocol independent, a signal replay or simulator can stand in for a real vehicle. The CAN provider’s dump-replay mode makes this concrete for CAN-based programmes, and any provider that publishes synthetic values lets you test consumers on a laptop. For teams practising continuous integration for vehicle software, this is arguably the strongest day-to-day benefit: apps are developed and regression-tested against the databroker with no car in the loop.

The Eclipse SDV Ecosystem in Context

Kuksa is one project among several in the Eclipse Software Defined Vehicle working group, which brings together OEMs, suppliers and open-source projects around vehicle software. From general knowledge rather than a source I checked this run, the neighbours include Eclipse Velocitas (a toolchain and SDK for writing vehicle apps against a vehicle model), Eclipse uProtocol (a communication layer for uniform addressing across vehicle and cloud), Eclipse Leda (a reference SDV Linux distribution) and others. Verify the current project list and maturity levels on the Eclipse SDV site before basing a roadmap on any of them.

The useful framing is a stack. At the bottom sit the buses and ECUs. Above them, providers and middleware translate into VSS. The databroker holds the state. Vehicle apps, written against the VSS-derived model, run on top and are managed by an orchestrator. The cloud mirrors the model. At no layer is a hard dependency on a single vendor required, which matters for OEMs who want to avoid a repeat of the proprietary-gateway era.

Trade-offs, Gotchas, and What Goes Wrong

The standard catalog is not your vehicle. VSS covers a broad set of common signals, but it will not contain every proprietary or new-technology signal. Expect to write overlays, and expect friction when your semantics differ subtly (is “speed” wheel-based, GPS-based or fused?). The description field carries these semantics, so read it before mapping.

Semantic drift in mappings. A DBC-to-VSS mapping that silently converts the wrong unit produces plausible but wrong data, which is worse than missing data. Add range checks using the min and max attributes of the model, and make the pipeline reject or flag out-of-range values. The v2 API’s INVALID_ARGUMENT error for out-of-range values gives you part of this, provided the metadata declares the bounds.

Latest-value semantics hide events. A latest-value store coalesces updates. If a door opens and closes within one publish interval you may never see it. Where events matter (a fault flag that sets and clears), publish them on change or use the bounded subscription buffer deliberately, and consider whether a dedicated event channel is a better fit.

Version skew. The model (VSS 6.1 at time of writing), vss-tools, the databroker API version, and your providers must agree. The v1 API is already marked deprecated, which tells you migrations are real. Pin all four, use vspec diff on composed snapshots in CI, and treat a removed or retyped signal as a breaking change.

Security defaults. The quick-start flag that disables TLS and authorisation is a development convenience. Shipping it is a recurring failure mode in open-source stacks generally. Enforce a build-time check that rejects insecure configuration in release images.

Scope creep. The databroker is a state store. Using it as a message bus for high-rate or large payloads, as an event store or as a control path for safety functions will end badly. Keep control loops on the real-time network, and keep bulk data on dedicated channels.

Single point of failure. One broker process per domain is simple, but if it crashes, every consumer loses data. Run it under a supervisor with automatic restart, make providers reconnect and republish current values on connect, and make consumers tolerate a gap. Because the store holds only the latest value, a restart empties it until providers repopulate it, so slow-changing signals may be missing for a while unless providers republish.

Cost of the abstraction. Every decode, map, publish and fan-out adds latency and CPU. For dashboards and cloud analytics that is irrelevant; for a function needing millisecond-level response it is not. Measure on your target SoC before assuming otherwise.

Practical Recommendations

Start from the consumer, not the bus. List the ten to twenty signals your first app or analytics use case needs, find them in the VSS catalog, and build the smallest vertical slice: one DBC subset, one mapping file, one databroker, one consumer. Only then widen the model.

Pin versions and automate. Fix the VSS version, vss-tools version and databroker image in your build, compose a snapshot of the model on every change, and diff it against the previous release. Run the CAN provider in dump-replay mode in CI so mapping regressions fail a build rather than a field test.

Design the uplink as a product. Decide per signal the publish policy, assign a purpose to each signal, and keep the allowlist in version control with review from your privacy officer. Use pseudonymous identifiers in the cloud path.

Secure by default. Enable TLS and token verification, give each client the narrowest path grants, and test that a client without a token is rejected with UNAUTHENTICATED.

Checklist:

[ ] VSS version pinned; overlays in your own repository
[ ] vspec diff runs in CI on composed snapshots
[ ] DBC-to-VSS mapping reviewed for units, ranges and enumerations
[ ] Providers publish on change or down-sampled, not at raw bus rate
[ ] TLS and JWT enabled in release builds; --insecure rejected by a build check
[ ] Uplink allowlist, consent gate and pseudonymisation documented
[ ] Digital twin stores source timestamps and a quality flag
[ ] Safety-relevant functions kept off the databroker path

Frequently Asked Questions

What is the vehicle signal specification?

The vehicle signal specification (VSS) is a COVESA-maintained catalog and syntax for describing vehicle data as a hierarchical tree of typed signals, rooted at Vehicle. Each entry is a branch, sensor, actuator or attribute, with a datatype, optional unit and range, and a description. Its goal is a common vocabulary independent of protocol or serialization format, so applications can read speed or door state without knowing how a given car transmits it. It is published under the Mozilla Public License 2.0.

What is Eclipse Kuksa and what does the databroker do?

Eclipse Kuksa is an open-source project in the Eclipse SDV ecosystem. Its KUKSA Databroker, written in Rust and licensed under Apache 2.0, loads a VSS model and serves the latest value of every signal over gRPC. Providers publish values, consumers read or subscribe, and consumers can request actuation that the broker routes to the registered actuator provider. It does not decode CAN or upload to the cloud; separate providers and agents handle those jobs.

How do CAN signals get into a VSS model?

A provider such as the Kuksa CAN provider reads frames from SocketCAN, decodes them with a DBC file, applies a mapping file that links each DBC signal to a VSS path, and publishes the converted value to the databroker. Unit conversions and enumeration translation belong in that mapping. The provider can also replay a CAN dump file, which makes mapping changes testable in continuous integration without a vehicle on the bench.

Is the Kuksa databroker suitable for safety-critical control?

No. The project documentation describes a data layer and does not claim ISO 26262 safety certification. It stores latest values, adds processing hops and runs outside the real-time control networks. Use it for apps, services, diagnostics and cloud connectivity, and keep braking, steering and other safety loops on certified real-time platforms. Actuation through the broker is also asynchronous: it sets a target, and the actual value arrives later from the provider.

Run an uplink agent as a databroker consumer. It subscribes to an allowlist of paths, filters and down-samples, checks consent per purpose, replaces the VIN with a pseudonymous identifier and publishes over MQTT or Zenoh. Minimisation, purpose limitation and retention are enforced in that agent and in the cloud store. This is architecture guidance, not legal advice; consult your data protection officer for your jurisdiction and use case.

Do VSS and Kuksa replace AUTOSAR Adaptive or ROS 2?

No. They operate at a different layer. AUTOSAR Adaptive and ROS 2 are middleware platforms for building and connecting software components, often with high-rate data. VSS defines a curated vocabulary and Kuksa provides a state broker over that vocabulary for apps and cloud services. In practice a provider subscribes to an AUTOSAR or ROS 2 data source, translates it to VSS paths, and publishes it to the databroker.