Interoperable VSS/VISS layer of SoDev

EMQ as a long-standing global open-source company focusing on IoT, IIoT, IoV, and SDV, has continuously been keen on contributing safe and secure open-source software to the world. To better fulfill the commitment, EMQ joined the ELISA and AGL organizations, showing the dedication to advancing Linux in safety-critical systems has been instrumental, paved the way for a more secure and transparent automotive landscape.

NanoMQ & eKuiper are two open-source projects donated to LF Edge, both have been widely used in mission-critical scenarios, including industrial automation, Automotive, and Railways.

Hereby, to promote the usability and versatility of AGL, EMQ would like to fill the absence of middleware in AGL, presents a data closed-loop solution combo, enabling use cases such as remote diagnostics and digital twin of the Vehicle. And takes agl-gateway-demo as an example.

First, what is NanoMQ and eKuiper? And why are they suited for AGL?

Rationales

NanoMQ

NanoMQ was born as an MQTT Broker, now evolved into a universal messaging bus and messaging queue with data persistence(Rolling basis update). The embedded data bridging and proxy feature allows our users to convert locale DDS/SOME-IP protocol to MQTT/HTTP/gRPC and bridge to multiple cloud, with auto data caching and fine-tuned re-transmission control and QoS prioritization, ensuring reliable vehicle-cloud data synchronization.

eKuiper

Act as the universal streaming engine in the Vehicle, enabling flexible data transformation. Update computing logic without OTA. Usually used as an in-vehicle low-code platform, achieves real-time rule computing. eKuiper has already been integrated into EdgeXFoundry, a well-known industrial 4.0 gateway project.

Showcasing data close-loop scenarios.

Japanese ver of explanation

NanoMQ、eKuiperを使用して、車載ネットワークのさまざまなシーンでデータを

処理および収集します。さらに、要件の変更を迅速に実施することができます

柔軟なシーンエンジンで、車をスマート化

1）単一条件、単一実行、繰り返し実行

例：車内温度が30℃を超えると、エアコンを起動する

2）単一条件、単一実行、一度実行

例：オーナーが車に近づくと、車を遠隔で起動する

3）条件の組み合わせ、複数のアクションを実行

例1：車内温度が30℃を超え、かつエアコンのモードが外気循環モードである場合、エアコンのモードを室内循環モードに設定し、温度を20℃に設定する

例2：車速が80km/hを超えるか、雨量センサーが雨を検知した場合、窓を閉じる

4）順次アクションの実行

例1：車内温度が30℃を超えると、まずエアコンを起動し、エアコンが起動した後、温度を20℃に設定する

5）条件実行

例：車速が80km/hを超える場合、窓を閉じ、車速が30km/h未満の場合、窓を開け、30〜80km/hの場合は何もしない

6）定時実行

例：夜9時以降に充電を開始する

Trigger-to-capture corner cases:

battery_sleep_abnormality:

SELECT ts, \"event id" as id, 
consecutive_start(`exampleCAN.0x056.vehicle_usage_mode` = 2, ts) 
as startUsageMode INVISIBLE FROM spi_1000ms_stream where ts - startUsgModSts >= 900000 
and ts - startUsgModSts < 1800000 and ts - last_hit_time() > 900000 and ts - last_hit_time() > 43200000

Investigation of Data Before and After Thermal Runaway Trigger：

bit 7 of BattLimitIndicator =1

SELECT ts, \"eventid\" as id FROM spi_1000ms_stream where `CAN.0x056.VehModeSafeSig1` = 3 and ts - last_hit_time() > 30000

Speculation on the specific causes of thermal runaway, thermal runaway failure

Retrieve based on thermal runaway case performance / Infer possible causes of thermal runaway based on signal changes before and after the event / Assist with after-sales handling

How VSS and VISS, and SDV-Flow Work Together

VSS and VISS are complementary: VSS defines what the data is (semantics and structure), while VISS defines how to access it (API and protocol). Their integration creates a full-stack solution for vehicle data in SDVs.+

Core Integration: VISS servers maintain a VSS tree as their data store. Paths in VISS requests directly reference VSS nodes (e.g., a get on Vehicle.Speed resolves to VSS metadata for type/unit). VISS messages embed VSS paths, ensuring semantic alignment.
Data Workflow:
1. Data Ingestion: Raw signals (e.g., from CAN bus) to nanomq databus.
2. Messaging Queue + Streaming Storage: NanoMQ + eKuiper as VISS server backends, persistent raw signal data with a rolling-basis update manner. Provide full-scale interoperability and fetch/query/trigger features.
3. Data Ingestion via Feeders/Providers (Raw to VSS Conversion): Raw signals from vehicle buses (e.g., CAN, Ethernet, SOME/IP) or sensors are ingested by "feeders" or "providers"—these terms are often used interchangeably in COVESA/Kuksa contexts. Their role is to map to VSS paths via feeders/tools:
  - Parse raw data (e.g., CAN frames via DBC files, which map byte offsets to signals).
  - Convert/normalize to VSS format (e.g., scale raw bits to engineering units like km/h).
  - Update the VSS tree in the server/broker (e.g., set Vehicle.Speed to 65).
  - Handle bidirectional flow: For actuators, translate VSS set requests back to raw commands. Examples: Kuksa's DBC feeder uses YAML configs to map CAN IDs to VSS paths; custom providers can integrate GPS or IMU data. (Need customization, example from kuksa.val)
4. Abstraction: loads the VSS catalog (JSON/YAML) and populates it with live data. (Kuksa, but No Historical data currently!). VISS Server (VSS Tree Population): The VISS server (e.g., reference Go/C++ impl or Kuksa Databroker) maintains an in-memory VSS tree. Feeders/providers continuously update it with live values. The server adds timestamps and enforces access controls (e.g., JWT auth). For historical (in v2/v3), we shall extend to NanoMQ + eKuiper capabilities.
5. Client Access via VISS API (Query and Interaction): Clients (apps, cloud services) connect over transports (WebSocket/gRPC/HTTP/MQTT) and send JSON requests referencing VSS paths:
  - get: Fetch current value (e.g., {"action":"get","path":"Vehicle.Speed"} → response with value and timestamp).
  - set: Update actuators (routed back through providers to hardware).
  - subscribe: Stream changes (with filters; notifications include value/timestamp).
  - Historical (v2/v3): Use history filters (e.g., {"filter":{"history":{"start":"2025-10-11T00:00:00Z","end":"2025-10-11T12:00:00Z"}}}) to query recorded series, if persisted. Responses embed VSS semantics (e.g., units). (Kuksa.val)
6. Feedback and Actuation Loop: Changes (from hardware or sets) propagate via providers to the tree, triggering subscriptions. Errors (e.g., invalid path) are VISS-defined. (First time doing remote control on the Vehicle)
7. Extensions: Vendor overlays in VSS are exposed via VISS without breaking compatibility. NanoMQ acts as a universal proxy for aggregating different V2C protocols, buffering, ensure data integrity, does re-transmission and prioritizing the traffic base on QoS policy.
Benefits in SDV: This duo abstracts hardware (e.g., ECU differences) into portable APIs, supporting multi-vendor ecosystems. For example, a navigation app subscribes via VISS to VSS's Vehicle.Position for routing, while a cloud service uses REST for remote diagnostics.
Standards Ecosystem: VISS builds on W3C Automotive work, aligning with COVESA's broader stack (e.g., Diagnostic Trouble Code Retrieval).

Extension talks: QUIC?