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