Data brokers · Bhargava Mandapati

You have a naming scheme () and transports (, ). The missing piece is something that holds the current value of every signal and serves it to whoever asks.

That is a data broker, and it is quietly one of the highest-leverage components in an SDV stack.

What it does#

Producers publish, consumers subscribe, neither knows the other — Feeders translate from whatever the vehicle actually speaks into VSS. Applications read and write VSS. Swapping a feeder for a simulator changes nothing above.

Why this matters more than it sounds#

Testing without a vehicle#

This is the big one.

Two teams, one bottleneck

Without a broker, an infotainment team wanting to test a low-battery warning needs a vehicle with a low battery. That means a test slot, a driver, and hours of driving to drain a pack — or a bench with the real ECU.

With a broker, they run:

kuksa-client set Vehicle.Powertrain.TractionBattery.StateOfCharge.Current 8

The warning appears. The whole path above the broker — application, UI, notification, cluster display — is exercised, in a second, on a laptop.

The vehicle is now only needed for the part below the broker: does the CAN feeder translate correctly? That is a much smaller question, and it does not block everyone else.

Producers and consumers evolve independently#

The CAN feeder can be replaced with a SOME/IP feeder when the underlying ECU is modernised. Every application above continues working unchanged, because they all talk VSS.

Access control in one place#

Rather than each application enforcing its own rules, the broker decides who may read or write each signal.

Per-signal, per-client

telemetry-uploader   → read:  Vehicle.Speed, Vehicle.Powertrain.*
                       write: (none)
 
cockpit-app          → read:  Vehicle.**
                       write: Vehicle.Cabin.**
 
charging-service     → read:  Vehicle.Powertrain.TractionBattery.**
                       write: Vehicle.Powertrain.TractionBattery.Charging.**

Eclipse Kuksa#

The most widely used open implementation is the Kuksa databroker, from the Eclipse SDV working group. It stores current VSS values and exposes them over gRPC.

Running one and driving it

docker run -p 55555:55555 ghcr.io/eclipse-kuksa/kuksa-databroker:latest
 
kuksa-client set Vehicle.Speed 42.5
kuksa-client get Vehicle.Speed
kuksa-client subscribe Vehicle.Cabin.Seat.Row1.DriverSide.Heating

An application reading from it

from kuksa_client.grpc import VSSClient
 
with VSSClient('127.0.0.1', 55555) as client:
    for updates in client.subscribe_current_values(['Vehicle.Speed']):
        speed = updates['Vehicle.Speed'].value
        render(speed)

Sensor and actuator writes are different#

A subtlety worth getting right.

Writing to a sensor signal means "this is the current value" — that is what a feeder does when reporting reality.

Writing to an actuator signal means "please make it so" — a request that travels down to the vehicle and may be refused.

Target value versus current value

# An application requests a change
client.set_target_values({'Vehicle.Cabin.Seat.Row1.DriverSide.Heating': 80})
 
# The feeder reports what actually happened
client.set_current_values({'Vehicle.Cabin.Seat.Row1.DriverSide.Heating': 80})

Honest limitations#

It is a current-value store, not a message bus. Ask it what speed is now and it answers. Ask for every speed sample over the last ten seconds and it cannot. High-rate historical streams need something else.

It is a component that can fail. Everything depending on it is affected. Production designs need to think about restart behaviour and what consumers do while it is unavailable.

Latency is added. A hop through a broker costs something. For control loops with tight budgets it may be the wrong path — direct service calls are shorter.

It does not make legacy signals into services. A signal exposed through a broker is still a value. It does not gain request-response semantics or meaningful errors just by being renamed.

Next#

The platforms this all runs on — AUTOSAR, Android, Linux and QNX.