...
- Alex (BMW, software architecture team, connection to Android, finding the best solution to connect AA to BMW cars), Wassim (BMW), Steven Hartley (GM, infotainment connectivity architect, based in Montreal), Guru (Bosch), Andrii (EPAM), Stefan (Tieto), Johan (melco), Stephen (Renesas), Gunnar, PhilippPhilippe (GENIVI)
- apologies: Sachin (Mercedes-Benz)
Agenda
- Roundtable
- Recap on PoC architectural design
- Call for participation
- AOB
...
- Alex: presents the so-called External Data Server Proof-of-Concept architecture
- on the right side, this is the Android Automotive based infotainment unit
what we did: we tried to open our mind w.r.t. the abstraction to our bordnet interfaces
explains the rationale for the work done
point #1 is abstraction
point #2 is to bring this into the vehicle, this is where we use VISS (the implementation of VSS)
Steven: this seems to me a way to solve the deployment of OEMs / Tiers 1 applications
Steven: how to do you solve the deployment of third party applications ? will this still use the vehicle HAL and the vehicle properties ?
Alex: explains we would like to go to Google with this proposal
Steven: will you put the vss VSS server in the appstore ?
- Alex: we have not considered it yet
- Steven: how do you intend to go to Google ?
- Gunnar: we had contact with Google Automotive team in the past, but people have changed, we intend to reach out to Google through OEMs
- Andrii: only the access to the data is external to the data server , there is some kind of confusion between internal & external data server architecture in my opinion
- Stephen: we need to think about the safety domain in the vehicle EE architecture, we might have the data server running on the safety domain
- Andrii: how do you manager the question of permissions for accessing data when the car stops vs the car moves
- Alex: there are properties in the VSS and we will define groups with permissions that will be enhanced with the manifest files at application level, the management of these 2 set of datas will be probably handled at application level, but this is to confirm
- Philippe: shows the PoCs we identified and their priorities,
- the PoC priorities do not refer to which architecture should be deployed in production, they reflect rather the team preference for which PoC to start first
- External Data Server PoC corresponds to slide #13 of Vehicle HAL Architectural Design Concepts
- Internal Data Server PoC is only a variant of the previous with the Data Server inside the Framework
- SomeIP stack inside the Framework PoC corresponds to slide #14 of Vehicle HAL Architectural Design Concepts
- Google VHAL + OEM Extensions inside PoC corresponds to slide #12 of Vehicle HAL Architectural Design Concepts
- Philippe: we need an update updated version of the slide deck Vehicle HAL Architectural Design Concepts presenting the various architectural design options
...
- Philippe: reminds his request for ownership of the PoC activities
- WBS of PoC #1 is available at External Data Server Proof-Of-Concept - Work Breakdown Structure, please review it and identify which activities your company would like contribute to, please add description and definition of done
Next events
- Tuesday 25 February 5pm CET - "all-hands" monthly call : recap of AASIG activities at management level
- Tuesday 3 March 5pm CET - next Vehicle HAL call
- calendar invites will be sent
...