...

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

Goal of this activity:

   FindFind/Develop/Define the required technology solutions (software, primarily) that can be used to implement a "full scope" (vehicle & cloud) system, while using are involved in transfer/storage/processing of the industry-common models for data & services (as defined 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   Note that cross-platform support seems to be a general request , even if 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.

...

For now all known parts are mentioned.  Overlapping initiatives might ought to 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 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 – 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.  In either case, the table must reflect the current availability, as well as some things that would be good to develop.  

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

Components for Data / VSS

Conversion from VSSdefinitions (data catalogs) to alternative file 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

...

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

• VISS – Specification and
                   WAII implementation (Go lang), also
                   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). 
  It would need a payload format from the above list, and must also have a security/access control definition clarified → see separate analysis page

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.

• Android Automotive (Vehicle-Properties in VHAL)  Under development: Code generator for the binding is under development (fork/WIPVSS→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 – likely 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 

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

• • Apache IoTDB – under development, StephenL is working on it.
  • Redis –  popular choice for in-memory key/value store (and more features)

...

A number of choices are possible here .  There and there are no plans yet to prioritize a particular one at this point. 
Rather whichever existing implementations become known would / implemented first, ought to be listed here.

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

Data processing

• Apache Spark

Other noteworthy software frameworks (
These typically with have a scope beyond data/RPC only but they include VSS support)support the common data/services model in their implementation

• AOS – "Kubernetes for the vehicle"

Components for services / remote-procedure-call (VSC)

Conversion from VSC catalogs to alternative file format

...

• ARA:COM (AUTOSAR-XML format).  Defining the data items is a step towards then using SOME/IP or other protocol AUTOSAR side, leveraging AUTOSAR-defined code generators.
• "gRPC IDL" (i.e. protobuf extension)
• Franca IDL - VSC project is discussing how to guarantee has Franca import/export , if the VSC language is in a different format than Franca itself.as a core focus.  Occasionally VSC is considered almost a new version/extension of Franca.  Better definitions will follow, but the direction to stay close to it is clear. 

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"

Defining such a protocol is being discussed, to mirror the definition of VISS for data.  A definition project has not yet been launched since it relies on the VSC-language and semantics being solidified first.  (It may of course decide to reuse existing definitions, including some of the ones listed below)

2) Options

• gRPC
• GraphQL - through its mutation feature GraphQL can theoretically support RPCs.  Is there interest in doing that?
• SOME/IP (Possible if converted to Franca IDL, via the CommonAPI framework (capicxx-someip)).  Just like for VSS there are likely additional ways to implement a more direct VSC↔ SOME/IP connectionGraphQL - through its mutation feature GraphQL can theoretically support RPCs.  Is there interest in doing that?
• DDS ?  – Evaluating interest
Being discussed:

W3C-chosen official protocol

for Automotive Services (discussed, a definition project has not yet been launced)

Runtimes and Frameworks

• DAPR – "Distributed Application Runtime" –  Data and RPC framework 

Runtimes and Frameworks

• Android Automotive - likely less applicability than for VSS, since Android has its own preferred HAL.  Describing Android-specific interfaces with the generic common IDL might have less value therefore, but it is of course a theoretical possibility if this is a benefit to someone.
• ...Android Automotive

Noteworthy software frameworks (typically with scope beyond data only), but to include VSC

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

Mentioned for completeness

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

...