...

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.

...

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
2. This page outlines the goal, as well as some challenges to reach pluggable software components, to be used in a shared reference architecture, as well as reuse into various companies own systems, that seem to vary somewhat.
3. Use the CVII Tech Stack Terminology to understand these component names.  Of course, these terms are open to additional input.

Image Added

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

...