We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies.


You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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:




Initial Brainstorm, implementation ideas

Which technologies come immediately to mind?

  • 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?
  • 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. 
    • 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



MQTT-tool



Notes



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







  • No labels