Page History

LINKS:  [Tech stack meeting minutes]

Child pages:

...

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

...

The best representation at this time is the COVESA CCS Project Reference Architecture.  NOTE: Be aware that the technologies mentioned therein are not set in stone.  Rather, this page represents a broader view of the variation of software components/protocols/etc. that may apply.

...

• VISS – Specification
                   WAII implementation (Go lang),
                   also (partially) implemented in KUKSA.VAL, and other?...
• SOME/IP () – ( via Franca IDL and CommonAPI).  Likely additional ways to implement a more direct VSS ↔ SOME/IP connection.
  
  • (Also WAMP exists, also via Franca+CommonAPI)
• MQTT – There exists VISS over MQTT defined in VISS specification, but not a plain usage where you use simple MQTT-subscription (with topics = VSS signals). 
  → see separate analysis page

Runtimes and Frameworks

This is a list of software projects that do somewhat more than just a "data protocol" but are still involved in defining data exchange.
Note: Some of these define their own protocols, or the protocol is hidden (abstract) behind the framework APIs.

...

• 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.
• KUKSA has both done VISS implementations in C++, based on VISS v1 - needs to be updated to v2
• AOS includes a VIS(S) implementation in Go, based on VISS v1

   Details:

• VISS v2 server Planning / Work Breakdown page

2. Demonstration of VSC-based development

...

      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) → Work breakdown page
• VSS to/from Autosar ARA:COM XML format
• VSC to/from Autosar ARA:COM XML format
• Proper VSS to Franca IDL converter.  Status and remaining steps are in vss-tools/PR#6.

...

• 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

...

AUTOSAR

Current tool chain   

...