Page History

...

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:

Initial Brainstorm, implementation ideas

Which technologies come immediately to mind?

...

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

Output
VISS (data)	MQTT (data)	Spark (data ingestion)	NiFi	W3C-RPC* (services)
Full go-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?)

Output
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 evolvin

...

Historical / preparation information.

Initial Brainstorm, implementation ideas

Which technologies come immediately to mind?

• (MQTT → moved to separate page)VSS-to-MQTT client
• Steps: 
  • Complete the draft mapping document to a full definition of message formats, etc.
  • Implementation, (with lots of code reuse)
• Access control solution for MQTT?
  • Certificate based?
    • Q: Is there a way to apply VISS access control method on MQTT?
Best Practices for MQTT security?

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

...

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

MQTT-tool

Image Removed

Notes

...

...

AUTOSAR

Current tool chain   

...