Demo Outline

Motivation
Overall Architecture
Demo Explains
Potential Future Moves

Motivation

A new ver of VSS/VISS demo of AGL is almost done. Here is our briefing report. Would like to collect feedback from AGL members and OEMs, as the foundation of the next move of Open-Source SDV.

But it is not only about VSS/VISS, but we view it as a good way to interpret the essence of the data-closed loop as a paradigm shift in SDV + AI era.

Data-Driven approach for developing SDV

Everyone is talking about SDV, but how can we get there? Rome is not built in one day. You cannot accomplish SDV only by deploying software or virtualization. The continuous update journey in Vehicle only stands if you know what is happening in/across the vehicles, so that you can decide where needs to be updated. The Real-Time data is compulsory for forming a positive loop of SDV. The data closed loop serves as a mirror for your SDV development.

By seamlessly converging the data namespace of the vehicle with the cloud. We can advance one step further on one mistake we made. Make every “bug“ count.

Overall Architecture

Demo explains

Replay data sample that was recorded from a real vehicle. The messaging bus: NanoMQ persists data for historical query and provides interoperability that conveys messages via pub/sub topics. The Streaming Engine: eKuiper provides real-time stream processing, decode raw data to signal with an embedded rule, and acts as a dynamic kuksa provider.
Hot Update of a Signal name without restarting NanoMQ + eKuiper. But a reboot of kuksa is necessary.
Hot Update of the Vehicle signal spec, config file (VSS.json) and decoding rule, even the DBC file is available.
Adding new signal: `SAS_1$SAM_1_SteeringAngle` via SQL interface.

curl -X PUT --location "http://127.0.0.1:9081/rules/rCan" \


    -H "Content-Type: application/json" \
    -d '{
          "id": "rCan",
          "sql": "SELECT ONEBOX_1$ABS_ESP_1_VehicleSpeedVSOSig,ACU_3$ACU_3_LongitudinalAcceleration,ACU_2$ACU_2_LateralAcceleration,SAS_1$SAM_1_SteeringAngle FROM canStream",
          "actions": [
            {
              "mqtt": {
                "server": "tcp://127.0.0.1:1883",
                "topic": "result/can",
                "sendSingle": true
              },
              "memory": {
                "topic": "sources/can",
                "sendSingle": true
              }
            }
          ],
          "options": {
            "sendNilField": false,
            "sendError": false
          }
        }'

Adding new signal definition in VSS.json: (config update could be done by the incoming V2C channel, not manually at the vehicle)

Proposed Integration in SoDev:

Future: SOVD + UHMI combo solution

SOVD: From passive telemetry to active diagnostic

Deploy OpenSOVD (or other SOVD project) as a microservice (container) on an AGL gateway VM or in a lightweight container runtime. OpenSOVD provides REST/HTTP APIs for diagnostics, logging, and updates.
Deploy NanoMQ to collect, buffer, and forward telemetry and diagnostic data between SOVD gateway and other AGL components (e.g., Kuksa, eKuiper, CAN, UDS, or other data sources). NanoMQ can act as an in-vehicle messaging queue with a protocol adaptor of OpenSOVD that listens on OpenSOVD’s service interfaces, serializes diagnostic data.
Run eKuiper on the same AGL gateway. eKuiper can subscribe to NanoMQ topics (diagnostic, telemetry) and perform edge analytics, anomaly detection, predictive maintenance, or any real-time rule processing.
When eKuiper detects certain conditions (e.g., fault count exceeding threshold, anomaly in sensor trends), it can trigger actions:
- Push a command back into NanoMQ to request remote diagnostic via SOVD operations (e.g., fault reset, parameter read/write)
- Issue messages to cloud/backend (via NanoMQ) to raise an alert or schedule maintenance.
- Store aggregated/filtered data locally, reducing data volume.

Overhaul AGL-Gateway-Demo from EMQ