...

   Note that cross-platform support seems to be a general request, even if Linux is the dominant platform for developing / testing the code.

Current priorities (evaluated based on group inputs)

1. "Second" VISS v2 implementation (in addition to GoLang 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 both done VISS implementations in C++, based on VISS v1, which could be starting points.

   Details:

• VISS v2 server Planning / Work Breakdown page

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.

• Volunteers needed – see Planning / Work Breakdown page

Project Backlog – development project candidates

• 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.

for further, potential examples, refer to the table based overview below.

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:

...

Technology Stack content analysis, and development state

These tables The following lists show an overview of planned, desired, and existing technologies - converters, generators, and bindings to existing technologies.

...

Converters and Code Generators

The purpose of the technology stack is to lead us (the automotive industry) towards a limited selected set of solid core technologies. 

A table 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 to make sure there are solutions for 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 CVII Tech Stack Terminology.

VSS

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)

...

 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 

...

 Definitely planned TODO.

because
"VSC language" will be very Franca compatible, (or will be Franca itself).  Therefore, expect interop with Std Franca IDL.

Data Serialization

...

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 (due to compiler support in some embedded system). =>  See priority list above.

...

 TODO
initial thoughts defined
and/or possible to reuse from IoTEA?

See working page

...

Frameworks and Databases and Processing

...

...

• 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.

• VISS – Specification and WAII implementation (Go lang), also (partially) implemented in KUKSA.VAL, and ...
• 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

Note: Some of these define their own protocols, or the protocol is hidden (abstract) behind the framework APIs.

• Android Automotive Vehicle-Properties Code generator for the binding is under development (fork/WIP).   Once merged, see main branch in vss-tools
• Apache Kafka, NiFi – likely requires simple plugins/definitions of how to transfer VSS data

Databases / Storage

Note: There are many choices here.  Some might simply implement a simple in-memory table.

In-vehicle

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

OEM/Neutral Cloud

A number of choices are possible here.  There are no plans to prioritize a particular one at this point.  Rather whichever existing implementations become known would 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 (typically with scope beyond data only but they include VSS support)

• AOS – "Kubernetes for the vehicle"

VSC

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.

• 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" (protobuf extension)
• Franca IDL - VSC project is discussing how to guarantee Franca import/export, if the VSC language is in a different format than Franca itself.

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.

• gRPC
• 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 connection
• GraphQL - 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

• 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

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

...

Priorities (evaluated based on group inputs)

1. "Second" VISS v2 implementation (in addition to GoLang 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 both done VISS implementations in C++, based on VISS v1, which could be starting points.

   Details:

• VISS v2 server Planning / Work Breakdown page

2. Demonstration of VSC-based development

   Background:

• Bosch eager to get started.  Discussions about VSC (latest intro material here)  may need to be progressed first (or in parallel).
• Getting started on a demonstration case will naturally drive the development of "key components" that are missing.
  
  

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.

• Volunteers needed – see Planning / Work Breakdown page

Project Backlog – development project candidates

• 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.

for further, potential examples, refer to the table based overview below.

...

Historical / preparation information.

...