Child pages:

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 are involved in transfer/storage/processing of the industry-common models 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:

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. 

The purpose of the technology stack is to lead us (the automotive industry) towards a 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 like this might look like a anything-to-anything approach, but it should be clear that the goal is not to create that, as explained in the previous section.  Instead, it is to make sure there are solutions to hook into technologies that are strongly desired, or unavoidable legacy.  

Terminology

It can be useful to refer to a shared understanding CVII Tech Stack Terminology.  Make sure you provide your input to these terms.

Technology Stack components

A) Architecture(s) and terminology

1. To get consensus around terminology and parts to develop we need to revise this in diagram and text form.

2. This page outlines the goal, and challenges to reach pluggable software components, to be used in a shared reference architecture but also possible to use in different variants that companies may come up with.

3. Agree on and then use the CVII Tech Stack Terminology to understand these designs.  Of course, these terms are open to additional input.

A1)  Partial system diagram (primarily representing an in-vehicle, possibly a single ECU, but terms are generic and components could be reused in a different setup)

Open

Source file for this diagram is :  It can be imported into https://app.diagrams.net/ and edited again.

A2)  Vehicle-to-cloud full architecture

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.

B)  Development Plan for needed technology (definitions, implementations, tools)

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.

• VSSo vspec2ttl in vss-tools.  See VSSo specification here.

• JSON   vss2json in vss-tools,

• GraphQL vspec2graphql in vss-tools and BMW implementation vss2graphql_schema

• ARA:COM, AUTOSAR-XML format.  ( Sort of available indirectly, via Franca IDL conversion and then FARACON)

• Protobuf - () vspec2protobuf in vss-tools ( Used as a definition of the VSS catalog.  Not sure exactly how that is to be used - instead we should consider Protobuf under the serialization topic below)

• Franca IDL - see below for links.  Similar comment as for the vspec2protobuf → defining the "VSS" or the prerequisite for transferring values of the VSS?

• DDS  – Evaluating interest

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

• JSON   N.B.  lot can be defined by reusing the formats of the VISS specification, but putting it in independent terms in a separate specification would be useful.

• Protobuf

• AVRO Under development in vss-tools

• Franca IDL Conversions exist in vss-tools alt1, alt 2, but likely still needs an update.  Plenty to improve/redefine also as part of how VSS shall integrate with VSC

• gRPC (Being investigated/added in KUKSA.VAL.  Is it for data/notifications or other APIs?  How does it differ from protobuf definition.  Status @Sebastian.Schildt ?)
  
  

Data transfer protocols

Note: Some of these will require using a serialization format to define the payload.  Others may bring/define their own formats.