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 attractive technology solutions that can be used with the industry-common model for data+services.

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:

Converters and Code Generators

Note:  The purpose of the technology stack is to lead us (the automotive industry) towards a limited selected set of solid core technologies. 
A table like this might look like a anything-to-anything conversion, 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.

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?	Possibly	Via Std Franca IDL – Common API tools consume standard Franca already	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

Completion of technology definition / implementation
VISS (data)	MQTT (data)	Spark (data ingestion)	NiFi (data flow definition and transfer)	W3C-RPC* (services)
Full go-implementation - KUKSA implementation? - more implementations?	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

(Ideally these initiatives are after analysis combined into a single consistent architecture?)

Completion of technology definition / implementation
IoT-event-analytics / VehicleEdge	KUKSA.VAL (part of IoTea)	AOS	CCS Reference Architecture and PoC	Other?
		Analysis starting	In large parts done, but details remaining and constantly evolving

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