CVII Tech Stack

LINKS:  [Tech stack meeting minutes]

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 can be used to implement a "full scope" (vehicle & cloud) system, while using the industry-common models for data & services (as defined by the other tracks).

   Note that cross-platform support seems to be a general request even if Linux is the dominant development platform.

Priority List

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)
• VSS to/from Autosar ARA:COM XML format
• VSC to/from Autosar ARA:COM XML format
• ...

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 show an overview of planned, desired, and existing technologies - converters, 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 might 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 of solid core technologies. 

A table 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.

Input	Output
	VSSo	JSON (VSS definition in alternative format)	Protobuf (VSS/message definition in alternative format)	gRPC	GraphQL (Schema, Apollo format)	ARA:COM (XML)	SOME/IP (code generation, vSomeIP stack)	CommonAPI (enables backends vSOMEIP and others)	DDS (code generation)	Android Vehicle-Properties (mapping via code generation)	Franca IDL (standard)
VSS → x	vspec2vsso	vspec2json	vspec2protobuf	Ongoing support in KUKSA.VAL	1)  vspec2graphql 2) BMW alternative implementation pending.	WIP TietoEvery Ongoing discussions. VSS formatted data to/from AUTOSAR systems?	1) Via Common API capicxx-someip → see next cell 2) Directly (without CommonAPI) TODO?	BMW considering releasing vss-2-commonapi generation tools?	Evaluate interest	Ongoing Mapping/plan exists.	Proposal, needs update.  vspec2franca
VSC → x	N/A	N/A	N/A:  gRPC is the corresponding protocol.	Evaluate interest	Useful candidate for the "W3C RPC protocol" to carry VSC services.	1) Std Franca ↔ARA:COM via FARACON (needs maintenance) 2) Possibly new implementation for VSC language?	TODO, obvious mapping.	Via Std Franca IDL →  Common API tools. Those tools take standard Franca as input	Evaluate interest	N/A	Definitely planned TODO. because "VSC language" will be very Franca compatible, (or will be Franca itself).  Therefore, expect interop with Std Franca IDL.

Communication protocols / bindings

Procotol / technology name:	VISS v2 protocol definition	MQTT (data)	Kafka (event streaming platform, make it VSS-aware and show impl.)	NiFi (dataflow platform, make it VSS-aware and show impl)	W3C-RPC* (services)
Scope:	Data	Data	Data (events)	Data	Services / RPC
	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	TODO Evaluate interest	TODO Evaluate interest	Pending analysis of VSC/interface language

Frameworks and Databases and Processing

Completion of technology definition / implementation
Project Name	IoT-event-analytics / VehicleEdge	KUKSA.VAL (part of IoTea)	Spark	AOS	CCS Reference Architecture and PoC	Other?
Scope:		Data	Data	Data (events)	Data	Services / RPC
			Spark is an analytics engine, but implementing the data ingestion part and showing analytics on data that came from VSS format.	Analysis starting	In large parts done, but details remaining and constantly evolving

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

Historical / preparation information.

Initial Brainstorm, implementation ideas

Which technologies come immediately to mind?

• (MQTT → moved to separate page)

• Investigation point:  VISSv2 with MQTT as "transport" - is there a possible compatibility?
  • → This has now been showed as an idea in W3C.  → link?

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

VSC to code generation

• Code generation - general stubs/proxies (C++ and other)

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   

(RED is not existing or not yet clearly defined).  (The rest exists already)

Notes

Going via Franca  is complicated...   →  VSS/VSC to AUTOSAR directly makes sense 

Direct approach for AUTOSAR

Vehicle Edge & IoT Event Analytics