Child pages:

...

The Technology Stack development is one of three main tracks of  the Common Vehicle Interface Initiative

...

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.

...

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)

Image Added

Source file for this diagram is here:  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.

...

• VISS – Specification
                   WAII implementation (Go lang),
                   also (partially) implemented in KUKSA.VAL, and other?...
• SOME/IP () – ( via Franca IDL and CommonAPI).  Likely additional ways to implement a more direct VSS ↔ SOME/IP connection.
  
  • (Also WAMP exists, also via Franca+CommonAPI)
• MQTT – There exists VISS over MQTT defined in VISS specification,
  but not a plain usage where you use simple MQTT-subscription (with topics = VSS signals). 
  → see separate analysis page

...

• Android Automotive (Vehicle-Properties in VHAL)     Under development: Code generator for VSS→Android Automotive Vehicle Properties
  (See this vss-tools fork and/or code_generation branch on vss-tools).   Once merged, see main branch in vss-tools.
• Apache Kafka, and NiFi – This appears to requires some simple plugins/definitions of how to transfer VSS data to leverage the whole framework
• DAPR – "Distributed Application Runtime" –  Data and RPC framework 

...

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)

• • InfluxDB
  • , Postgres Time-Series,
  • MongoDB
  • , and cloud-providers data store services (AWS, Azure, Google)
  • and likely many other options...

Data processing

• Apache Spark
  
  

Other software frameworks
These typically have a scope beyond data/RPC only but support the common data/services model in their implementation

...

• AOS – "Kubernetes for the vehicle" → VSC connection not defined yet

...

Other things mentioned for completeness

• Is JOYNR a candidate worth including and studying here?  (It is Franca IDL based, and also supports overlapping technologies like MQTT)

...

Shortlist, prioritized projects

...

(2021, not clear if it is still representative)

1.   "Second" VISS v2 implementation (in addition to GoLang WAII implementation)

   Background

• C++ seems to be requested.   There is also some mild interest in Rust in the industry, but so far it seems not strong enough to supplant C/C++ as the main choice.
• AOS and KUKSA have has both done VISS implementations in C++, based on VISS v1 , which could be starting points.- needs to be updated to v2
• AOS includes a VIS(S) implementation in Go, based on VISS v1

   Details:

• VISS v2 server Planning / Work Breakdown page

...

• VSS to Android Properties implementation (Code Generator).   It should likely introduce jinja2 template based generation, similar to the vsc-tools.  → Work breakdown page.
• VSS over MQTT (Starting point exists in IoTea impl. Develop full implementation, include access-control/security, and as a reusable component separated out from IoTea framework) → Work breakdown page
• VSS to/from Autosar ARA:COM XML format
• VSC to/from Autosar ARA:COM XML format
• Proper VSS to Franca IDL converter.  Status and remaining steps are in vss-tools/PR#6.

...

• General (MQTT and other):  Binary data representation to optimize compared to VISS-JSON transport.
  • ...use also as variant encoding in VISS?
  • ...use as independent protocol (not part of VISS spec)
• AUTOSAR Adaptive compatibility
  • SOME/IP is important so we cannot ignore it.
  • DDS also.
  • (However, ARA:COM abstracts the technolgies.  For AUTOSAR systems, generating ARA:COM XML format is enough, the rest follows.  For non-AUTOSAR systems that are going to communicate with AUTOSAR systems, however, something that implements the concrete chosen protocol is needed. 
    • Previous work:  Franca IDL → Common API for SOME/IP and vSomeIP, and Franca IDL ↔ AUTOSAR XML converter)
  • Opinion:  SOME/IP is used in a very static way – an alternative might be desirable.
  • (AUTOSAR) RESTful services (not HTTP, rather stateless principle, get, set etc.) → Only discussions currently, no drive?
    • How is this concrete protocol defined?
    • Bosch might be willing to work on this.
• Protobuf conversion → Main page
  (because it is used and preferred by SENSORiS, but is also generally popular, and there was a recent vspec2proto converter proposal in vss-tools)

...

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

...

AUTOSAR

Current tool chain   

...