JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project |
Child pages:
Children Display |
---|
LINKS: [Tech stack meeting minutes]
Launch active development projects on key components:
"Second" VISS v2 implementation (in addition to GoLang implementation)
Demonstration of VSC-based development with Seats Service as example
...
The Technology Stack development is one of three main tracks of the Common Vehicle Interface Initiative
Goal of this activity:
FindFind/Develop/Define attractive the required technology solutions that can be used with (software, primarily) that are involved in transfer/storage/processing of the industry-common model for data+servicesmodels for data & services (as agreed upon by the other CVII tracks).
This includes anything within the "full scope" system (i.e. in-vehicle, edge & cloud), if it is software related to the common data/services model technologies.
Cross-platform support seems to be a general request but Linux is likely 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:
Converters and Code Generators
How is the Technology Stack defined and developed?
- Through a combination of formal specification and open-source implementations, as chosen by the participants.
- Of course, by evaluating and selecting existing technologies where they exist, and making the necessary adjustments/bindings/plugins to make the common data/services models fit into existing frameworks.
- ... and developing the documents and software code that is missing.
Technology Stack content analysis, and development state
The following lists show an overview of planned, desired, and existing technologies - including format-converters, code-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 ought to be possible to combine, to work towards a single consistent full-stack design.
Note: The purpose of the technology stack is to lead us (the automotive industry) towards a limited selected set reasonable selection of solid core technologies without trying to support everything under the sun. In other words, there might not always be one selected choice in the software solutions, protocols, etc, but there should still be only one choice for the underlying data/services model, according to CVII goals.
Converters and Code Generators
A listing of conversions
A table like this might look like a anything-to-anything conversion approach, but it should be clear that the goal is not to create that – only , as explained in the previous section. Instead, it is to make sure there are solutions for to hook into technologies that are strongly desired, or unavoidable legacy.
...
ARA:COM (XML)
...
WIP TietoEvery
Ongoing discussions.
VSS formatted data to/from AUTOSAR systems?
...
Proposal, needs update. vspec2franca
...
N/A: gRPC is the corresponding protocol.
...
1) Std Franca ↔ARA:COM via FARACON (needs maintenance)
2) Possibly new implementation for VSC language?
...
Via Std Franca IDL → Common API tools.
Those tools take standard Franca as input
It can be useful to refer to a shared understanding CVII Tech Stack Terminology. Make sure you provide your input to these terms.
Source file for this diagram is here: It can be imported into https://app.diagrams.net/ and edited again.
The best representation at this time is the Covesa CCS Project Reference Architecture. NOTE: Be aware that the technologies mentioned therein are not set in stone. Rather, this page represents a broader view of the variation of software components/protocols/etc. that may apply.
This is intended to become a relatively complete list of needed deliverables.
Add to it, if some technology you need is missing.
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
This is a list of software projects that do somewhat more than just a "data protocol" but are still involved in defining data exchange.
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. Others define themselves as "databases" or "key-value stores".
In-vehicle
OEM/Neutral Cloud
A number of choices are possible here and there are no plans yet to prioritize a particular one at this point.
Rather whichever existing implementations become known / implemented first, ought to be listed here.
(only examples)
Data processing
Other software frameworks
These typically have a scope beyond data/RPC only but support the common data/services model in their implementation
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.
1) W3C-chosen official protocol for automotive services "RPC"
2) Options
Runtimes and Frameworks
Noteworthy software frameworks (typically with scope beyond data only), but to include VSC
...
1. "Second" VISS v2 implementation (in addition to WAII 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.
...
Definitely planned TODO.
because
"VSC language" will be very Franca compatible, (or will be Franca itself). Therefore, expect interop with Std Franca IDL.
Communication protocols / bindings
...
Kafka
(event streaming platform, make it VSS-aware and show impl.)
...
NiFi
(dataflow platform, make it VSS-aware and show impl)
...
Full GoLang implementation
Other implementations? >>
A request for C++ implementation came up (compiler support in some embedded system)
...
TODO
initial thoughts defined
and/or possible to reuse from IoTEA?
See working page
...
Frameworks and Databases and Processing
(Ideally these initiatives are after analysis combined into a single consistent architecture?)
...
...
...
Historical / preparation information.
...
...
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
...