JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project - On Hold |
We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies. |
LINKS: [Tech stack meeting minutes]
The Technology Stack development is one of three main tracks of the Common Vehicle Interface Initiative
Goal of this activity:
Find/Develop/Define the required technology solutions (software, primarily) that can be used to implement a "full scope" (vehicle & cloud) system, while using the industry-common models for data & services (as defined by the other tracks).
Note that cross-platform support seems to be a general request, even if Linux is the dominant platform for developing / testing the code.
1. "Second" VISS v2 implementation (in addition to GoLang implementation)
Background
Details:
2. Demonstration of VSC-based development
Background:
3. Define "efficient binary encoding" of VSS payloads, as a reusable implementation
A) For individual message updates through protocols (VISS? MQTT, etc.)
B) For in-memory storage of multiple data points and possibly subsequent batch (image) transfer.
for further, potential examples, refer to the table based overview below.
The term Technology Stack is used to describe all software that is related to the transfer and use of data and services that adhere to the common model(s).
Examples:
Technology Stack content analysis, and development state
These tables show an overview of planned, desired, and existing technologies - converters, generators, and bindings to existing technologies.
It should be continuously updated to reflect completion of technology definition (specification) or implementation
For now all known parts are mentioned. Overlapping initiatives might be possible to combine, to work towards a single consistent full-stack design.
Converters and Code Generators
The purpose of the technology stack is to lead us (the automotive industry) towards a limited selected set of solid core technologies.
A table of conversions like this might look like a anything-to-anything approach, but it should be clear that the goal is not to create that – only to make sure there are solutions for technologies that are strongly desired, or unavoidable legacy. In either case, the table must reflect the current availability.
Input | Output | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
VSSo | JSON (VSS definition in alternative format) | Protobuf (VSS/message definition in alternative format) | gRPC | GraphQL (Schema, Apollo format) | ARA:COM (XML) | SOME/IP (code generation, vSomeIP stack) | CommonAPI (enables backends vSOMEIP and others) | DDS (code generation) | Android Vehicle-Properties (mapping via code generation) | Franca IDL (standard) | |
VSS → x | vspec2vsso | vspec2json | vspec2protobuf | Ongoing support in KUKSA.VAL | 1) vspec2graphql | WIP TietoEvery Ongoing discussions. VSS formatted data to/from AUTOSAR systems? | 1) Via Common API capicxx-someip → see next cell | BMW considering releasing vss-2-commonapi generation tools? | Evaluate interest | Ongoing Mapping/plan exists. | Proposal, needs update. vspec2franca |
VSC → x | N/A | N/A | N/A: gRPC is the corresponding protocol. | Evaluate interest | Useful candidate for the "W3C RPC protocol" to carry VSC services. | 1) Std Franca ↔ARA:COM via FARACON (needs maintenance) 2) Possibly new implementation for VSC language? | TODO, obvious mapping. | Via Std Franca IDL → Common API tools. Those tools take standard Franca as input | Evaluate interest | N/A | Definitely planned TODO. because |
Communication protocols / bindings
Procotol / technology name: | VISS v2 protocol definition | MQTT (data) | Kafka | NiFi | W3C-RPC* (services) |
Scope: | Data | Data | Data (events) | Data | Services / RPC |
Full GoLang implementation Other implementations? >> A request for C++ implementation came up (due to compiler support in some embedded system). => See priority list above. | TODO See working page | TODO Evaluate interest | TODO Evaluate interest | Pending analysis of VSC/interface language |
Frameworks and Databases and Processing
Completion of technology definition / implementation | ||||||
---|---|---|---|---|---|---|
Project Name | IoT-event-analytics / VehicleEdge | KUKSA.VAL (part of IoTea) | Spark | AOS | CCS Reference Architecture and PoC | Other? |
Scope: | Data | Data | Data (events) | Data | Services / RPC | |
| Spark is an analytics engine, but implementing the data ingestion part and showing analytics on data that came from VSS format. | Analysis starting | In large parts done, but details remaining and constantly evolving |
Historical / preparation information.
Initial Brainstorm, implementation ideas
Which technologies come immediately to mind?
VSC to code generation
A lot of communication related technologies were investigated in the Generic Protocol Evaluation project during 2019.
A set of reference links are here : List of relevant technologies
Current tool chain
(RED is not existing or not yet clearly defined). (The rest exists already)
Notes
Going via Franca is complicated... → VSS/VSC to AUTOSAR directly makes sense
Direct approach for AUTOSAR