Page History

LINKS:  [Tech stack meeting minutes]

Launch active development projects on key components:

...

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

Image Added

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 requestedKUKSA.VAL (is a VISS server) is already C++ based and started gradually work on increasing the scope to v2.
  • Any Linux-specifics?  Not sure about details but development and testing is on Linux.
  • Connects to SocketCAN
  Both KUKSA.VAL and AOS versions added some access control, but not according to spec.   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 with Seats Service as example

   Background:

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

3. Proposal:  Make the Define "efficient binary encoding" of VSS payloads (, as a reusable implementation)

• Should likely reuse some framework to do the serialization, e.g. protobuf or other preference.  AVRO another options?
• Volunteers needed.

                      A)  For individual message updates through protocols (VISS? MQTT, etc.)
                      B)  For in-memory storage of multiple data points and "batch" transfer.

Possible input, listing the needs(?) and examples of data messages with value, series of data, and associated metadata (e.g. timestamp):  Data serialization / value formats

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

Image Removed

Goal of this activity:

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   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:

...

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
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 of conversions like this might look like a anything-to-anything conversion 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

Completion of technology definition / implementationSparkTODO

Procotol / technology name:	VISS v2 (data)protocol definition	MQTT (data)	Kafka (event streaming platform, make it VSS-aware and show impl.)		(is an analytics engine, but implementing the data ingestion part and showing analytics on data that came from VSS format) 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	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
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

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

...

Historical / preparation information.

...