Architecture
The E2E Demo Blueprint spans multiple physical devices connected over Wi-Fi and CAN bus. This page describes the full component architecture and how each piece interacts.
High-Level Architecture
Component Descriptions
Raspberry Pi 5 — Signal Workloads (Eclipse Ankaios)
All in-vehicle signal workloads are managed as Podman containers by Eclipse Ankaios 0.7.0. The Ankaios manifest (vehicle-signals.yaml) defines the following workloads:
| Workload | Container Image | Purpose |
|---|---|---|
mosquitto-broker | eclipse-mosquitto:latest | MQTT broker for driver-input ECUs |
grpc-mqtt-bridge | grpc-mqtt-bridge:main | Translates MQTT JSON payloads to Kuksa gRPC Val/Set updates |
kuksa-databroker | kuksa-databroker:0.6.0 | Central VSS signal store |
kuksa-can-provider | can-provider:0.4.4 | Bidirectional CAN ↔ VSS mapping via DBC files |
kuksa-livi-bridge | kuksa-livi-bridge:main | Subscribes to VSS signals on the Kuksa Databroker and pushes them as telemetry frames to the LIVI head unit on the IVI Raspberry Pi 4 over Ethernet |
pi5-demo-website | pi5-demo-website:latest | Live architecture / signal-flow dashboard at :8090 |
All workloads run with --net=host so they share the host network namespace and can reach each other at localhost.
Raspberry Pi 5 — Fleet Management Stack (Docker Compose)
The Fleet Management Blueprint services run via Docker Compose alongside the Ankaios workloads:
| Service | Purpose |
|---|---|
fms-forwarder | Reads VSS signals from Kuksa Databroker and forwards them via uProtocol |
fms-zenoh-router | Zenoh transport layer |
fms-consumer | Receives telemetry and writes to InfluxDB |
fms-server | rFMS HTTP API at :8081 |
fleet-analysis-backend | Jakarta EE analytics API at :8082 |
influxdb | Time-series database |
grafana | Dashboards at :3000 |
csv-provider | Optional simulated vehicle data source |
Arduino Joystick ECU
An Arduino Uno R4 WiFi reads an analog joystick (left/right + button press) and publishes VSS-aligned JSON on MQTT topic InVehicleTopics. The payload directly maps to:
Vehicle.Body.Lights.DirectionIndicator.Left.IsSignaling(boolean)Vehicle.Body.Lights.DirectionIndicator.Right.IsSignaling(boolean)Vehicle.Body.Lights.Brake.IsActive(string:INACTIVE/ACTIVE/ADAPTIVE)
→ Full device guide: Joystick Input ECU
Arduino RFID Door ECU
An Arduino with an RC522 RFID reader publishes the scanned card UID as:
Vehicle.Driver.Identifier.Subject(string)
→ Full device guide: RFID Door ECU
MCU1 LED Control ECU
An Arduino Uno with an MCP2515 CAN transceiver listens for BlinkerCommand frames on CAN ID 0x120 and drives a WS2812 8-LED strip:
| LEDs (0-based) | Function |
|---|---|
| 0–1 | Left indicator |
| 3–4 | Brake light |
| 6–7 | Right indicator |
The MCU sends BlinkerStatus frames on CAN ID 0x121 back to the Raspberry Pi.
→ Full device guide: LED Control ECU
IVI Head Unit (Raspberry Pi 4 + LIVI)
A dedicated Raspberry Pi 4 with a 7" touchscreen runs Raspberry Pi OS in kiosk mode hosting LIVI — an open-source Apple CarPlay / Android Auto head unit built on Electron. It is wired to the rest of the demo via an Ethernet link to the Raspberry Pi 5, and it offers Wi-Fi + Bluetooth to pair with an Android smartphone for wireless Android Auto projection.
Live vehicle signals are fed into LIVI via its Telemetry CLI (see scripts/tools in the LIVI repository, which pushes fields such as speedKph, rpm, fuelPct, rangeKm, gps.lat, gps.lng, etc. into the running app over local IPC/socket).
A new Ankaios workload, the Kuksa-to-LIVI Telemetry Bridge, runs alongside the other signal workloads on the Raspberry Pi 5. Modelled after the existing MQTT-to-gRPC bridge, it:
- Subscribes to the relevant VSS branches on the Kuksa Databroker via gRPC.
- Maps each VSS signal to the corresponding LIVI telemetry field.
- Forwards the values to the LIVI Telemetry CLI on the IVI Pi 4 over the Ethernet link, throttled with a configurable repeat interval.
This keeps LIVI fully decoupled from CAN/MQTT — it only consumes a clean telemetry stream that mirrors the canonical VSS state.
→ Full device guide: IVI Head Unit (LIVI)
ThreadX SOME/IP Extension (Optional)
Two MXChip AZ3166 boards form a SOME/IP peer pair:
- Device 1 subscribes to MQTT blinker topics, maps the payload to SOME/IP events, and forwards button A/B state.
- Device 2 receives SOME/IP events and updates its LED/OLED display, also sending its own button state back.
→ Full device guide: ThreadX SOME/IP ECU
Network Topology
All Wi-Fi devices connect to the same network. The Raspberry Pi 5 bridges Wi-Fi (MQTT) and CAN (SocketCAN) traffic, and exposes a wired Ethernet link to the Raspberry Pi 4 IVI head unit so that the Kuksa-to-LIVI telemetry bridge can reach LIVI's telemetry Socket.IO server without depending on the Wi-Fi network. The IVI Pi 4 additionally offers its own Wi-Fi and Bluetooth stack toward an Android smartphone for wireless Android Auto. The CAN bus operates at 500 kbit/s with an 8 MHz oscillator on the MCP2515 module.