Page History

Child pages:

...

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

...

1. To get consensus around terminology and parts to develop we need to revise this in diagram and text form.  2
2. This page outlines the goal, as well as some and challenges to reach pluggable software components, to be used in a shared reference architecture , as well as reuse into various companies own systems, that seem to vary somewhat.but also possible to use in different variants that companies may come up with.
3. Agree on and then use Use the CVII Tech Stack Terminology to understand these component namesdesigns.  Of course, these terms are open to additional input.

A1)  Partial system diagram (primarily representing an in-vehicle, possibly a single ECU, but

...

terms are generic

...

and components could be reused in a different setup)

Source file for this diagram is here:  It can be imported into https://app.diagrams.net/ and edited again.

...

The best representation at this time is the COVESA 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.

...

• 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   

...