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

Input	Output
	VSSo	JSON (VSS definition in alternative format)	Protobuf (VSS/message definition in alternative format)	GraphQL (Schema, Apollo format)	ARA:COM (XML)	SOME/IP (code generation, vSomeIP stack)	DDS (code generation)	CommonAPI (enables backends vSOMEIP and others)	Android Vehicle-Properties (mapping via code generation)	Franca IDL
VSS → x	vspec2vsso	vspec2json	vspec2protobuf	vspec2graphql	TODO	TODO	plan?	existing tools to become open source?	Ongoing Mapping/plan exists.	proposal, needs update vspec2franca

Communication protocols / bindings

Completion of technology definition / implementation
VISS (data)	MQTT (data)	Spark (data ingestion)	NiFi	W3C-RPC* (services)
Full go-implementation - KUKSA implementation?	TODO initial thoughts defined and/or possible to reuse from IoTEA? See working page	TODO	TODO	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
		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