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.
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
The following lists 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 listing 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, as well as some things that would be good to develop.
It can be useful to refer to a shared CVII Tech Stack Terminology.
Conversion from VSSdefinitions (data catalogs) to alternative file format
Note: Conversions to other formats are done to extend VSS with additional features , or to hook into useful existing technology that happens to consume another input format.
Serialization / value-message formats
Note 1: This is different from the VSS catalog in that it does not define the signals, it defines how to transfer (or store) measured values of those signals.
Note 2: Several of these are generic technologies that could be use any number of ways to transfer data (e.g. JSON). The purpose of this work is to define a single canonical definition for each such format
Data transfer protocols
Note: Some of these will require using a serialization format to define the payload. Others may bring/define their own formats.
Runtimes and Frameworks
Note: Some of these define their own protocols, or the protocol is hidden (abstract) behind the framework APIs.
Databases / Storage
Note: There are many choices here. Some might simply implement a simple in-memory table.
In-vehicle
OEM/Neutral Cloud
A number of choices are possible here. There are no plans to prioritize a particular one at this point. Rather whichever existing implementations become known would be listed here.
Data processing
Other noteworthy software frameworks (typically with scope beyond data only but they include VSS support)
Conversion from VSC catalogs to alternative file format
Note: Conversions to other formats is done to extend it with additional features or hooking into existing technology.
RPC protocols
Note 1: In contrast to VSS, for VSC/services we did not separate the serialization definition from the protocol. It is simply understood that each RPC protocol will define the wire-format of its method-invocation request and responses as part of its specification.
W3C-chosen official protocol
Runtimes and Frameworks
Noteworthy software frameworks (typically with scope beyond data only), but to include VSC
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.
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