Minutes of Android Automotive SIG
Vehicle Data API / HAL Sub-Project
8 October 2019
Agenda
1.	Comparison of how vehicle properties are managed by Android 9 and 10 (Q) (Sachin)
2.	Report of the software architectural task force ramp-up (TF participants)
3.	Secure access control in Some/IP (Giovanni ?, Pete ?)
4.	Signal to service translation (Pete ?)
5.	AOB
Backlog
•	Some/IP and access management
•	Signal-to-Service translation
•	Vehicle properties: boot sequence

Attendees: 
Sachin Athanikar (Daimler), Alexander Domin (BMW), Johan Strand (Melco), Stefan Wysocki (Tieto), Piotr Krawczyk (Tieto), Marcin Katulski (Tieto), Pontus Fuchs (Bosch),  Maria Schier (Bosch), Guru (Bosch), Stephen Lawrence (Renesas),  Gunnar (GENIVI), Philippe (GENIVI, Project Management Office Lead), 12 participants
Apologies: Marc Bellanger (Renault)

Comparison of how vehicle properties are managed by Android 9 and 10 (Q)
 Sachin: So when you look at 9 to 10, architecture wise it still maintains as it is, the features for the automotive vehicle are kept almost the same. It is just the way the properties are maintained and the the structures that have been rearranged a bit, instead of having the big structure for the vehicle properties, they have been broken down them into different segments (which what I am currently analyzing) but the bottom line is there's not much significant change on the property side, but new modules have been included specially on the cluster side. The cluster API is something new in Android 10. 
Now on the call back side, it is still the same Vehicle HAL properties, there's not a major version change, we still have the vehicle types 2.0, so nothing to worry about if we are implementing anything.
Stefan: I  looked into it and I got the same impression as you, what I'm really interested in is this structure of the properties that have been assigned to some kind of segments. Could you share the link to the place when you found this in the code ?
Gunnar: it would be really useful if we take a combined effort to document this because it's something we need to refer back to all the time when we discuss solutions and as we will discuss today about the whole vehicle subsystem.
/TODO/ Sachin create and populate a page in the wiki  with the findings of AA 9 to 10 comparison, in particular about the new structure  for the vehicle properties into segments

Report of the software architectural task force ramp-up 
Gunnar: shows a slide deck elaborated with Johan (Melco)
a couple of disclaimers first
The presentation is about why we can gain something from defining an architecture together and also why we may consider a different SW architecture than the one proposed by AA. At this step we can explore several ideas.
We also intend to look also at the big picture, connecting non Android ECUs and establishing cloud connections & data servers
Android Vehicle Properties
Gunnar: we need to pay attention to the fact that Android Auto identifies functional domains or zones of the vehicle (like HVAC)
Options for the architecture (Idea 1, Idea 2)
Describes the two architecture options, Idea 2 option identifies  a Gateway ECU hosting a Vehicle Information Server (VISS)
Idea 2 can be even refined further in an architecture where VHAL is replaced by a data server running on the head unit
Alexander: we could have the two designs (Idea 1 & Idea 2) coexist
Alexander: (slide Replace Car API  Vehicle Data Server / Service) in my opinion, the SW layers are missing on this slide. VHAL is in the vendor layer while VISS client is in the application layer, is the VISS server in the vendor layer or the application layer ?
Johan: the VISS could be anywhere, but in this scenario we are replacing the VHAL APIs and Google would have to agree that this a good solution, the VISS server could be in the vendor layer, currently we have an implementation where the VISS server is in the service layer
Gunnar:  if we remove the VHAL APIs, Google would have to approve it, this approach might not be compliant with the certification requirements
Alexander: the two approaches can likely coexist because if Google have only 70 or 80 properties, which they are requiring and the apps are relying on these properties, we can give them these 70 or 80 or 100 properties, here what we are talking about is a much bigger amount of APIs which we need for our OEM specific applications (e.g. no one is interested in tyres or tyre pressures) and that's why I think we need these two solutions.
Gunnar:  We could remove the crossing-out of VHAL on the slide and possibly you would still be compliant, i.e. you would still have a compliant system even if you added additional services relying on the VISS server.
Gunnar: Some/IP slide; in my opinion Some/IP matches pretty well with the AA properties. 
Gunnar: (static approach through code generation slide) What we could do concretely is to take a snap shot of the VSS specification, and generate the static programming interfaces, basically one per signal and some configuration might be needed to say how to split the interfaces into separate services instead of putting everything into one big service. 
Now, it can be then an observable (VHAL) property or a (Some/IP) field or a Franca attribute (these are all different names for the same thing) and it's possible to do those translations between those through code generators
Gunnar: an example was given in a previous slide deck on vss2franca_attributes Basically, what I showed was that once you convert basic signals to Franca attributes, you can apply common API code generation on that and you would get C++ programming APIs for each signal and binding to Some/IP exists already today. 
Alexander: I just realized that it's quite similar to the D-Bus stuff we did in the past or at least in the BlueZ APIs where we had the same pattern of attributes with Set/Get Attribute but one function is missing which is GetAll where you get the current values of all attributes which are actually captured in this particular interface, you do this in one call at the initial startup of the application.
Gunnar: Static approaches through code generation – Autosar possibilities slide and next slide –  tentative synthesis of the work going in this AA SIG Vehicle HAL project, the model2model transformation project (FARA tooling) and the CCS project.
Gunnar: What have I missed in this presentation ?
Johan: the presentation makes sense. I like the new slides that clear up the things we discussed at the end of our meeting last week
Discussion on the various SW architectures shown with VHAL or VISS server or both
Sachin:  it's important to see that how this idea of VSS server sitting next to VHAL can be implemented without modifying the native Android structure and it's important from a certification perspective to check how Google will react to this architectural change. 
Also one more important thing is if Google makes important changes or improvements going forward with the VHAL and we feel there is a critical change for the whole Android architecture,  we need to manage the risk of adapting the proposed architecture to the changes made by Google later.
Gunnar: agreed, however we need to look at the big the whole picture because Google can define lots of things in the API of Android, but you have the other ECUs in the system that are not adhering to that (Google) and they need to do have a way to describe the data that they are exchanging to the Android unit for example, and you have a translation challenge to make in your HAL. There's a mapping to be done all across the entire system and all the way to the cloud in some sense.  We do not limit our thinking as we said in the beginning in relation to certification, but eventually we'll get to the point where that needs to be addressed of course.
Johan: it's a good point. I can just mention that we have done implementation with communication on the side of Android and still not breaking Android Treble. So we are actually sending data to OEM applications and passing CTS. But of course there would be issues updating even in that case.
Gunnar: discussion on how to convince the industry and Google to have a better solution, what are the next steps for our work ? doing an implementation ? implement an Autosar Adaptive system fitting in the architecture we showed (for Autosar members) ?
Piotr: why don’t we use the same component to feed the HAL and expose additional interfaces for OEM applications ?
Alexander: from my perspective, we have two challenges. One of them is we have only 90 or 80 attributes, and if we do these extensions (additional interfaces) in the VHAL and Google comes up with an update and overwriting / redefining our attributes, we will need to adapt. 
And second thing. We can do everything with the Google technology and the so-called custom house, but what about exposing also the information which are hosted by the head unit to the other ECUs ? It's not a one-way where I just bring everything into my head unit, but I would like also to bring some services that run on the Android head unit and expose them to other ECUs. We need also to think about how do we do that now.
Gunnar: this could be achieved with the approaches we describe today
Discussion on the use of VSS to describe the data
Alexander: How do you describe the signals? Do we have alternatives ?
Gunnar: VSS is one possible way. But if there's a preference for another common data model, then let's look at it.
Piotr: We are talking always about Vehicle HAL, it is worth underlying that Google does not provide the HAL, Google actually just provides a reference implementation for it, they do not own it, they are just publishing IDL, i.e. interface definition. So whatever we actually do with the HAL, it is ours, Google will not change it. Google will keep the IDL in the version space.
Google can change the IDL interface but the implementation what is behind the IDL is something that the vendor is actually doing. So in our case we can introduce a component that will actually gather the data and manage the data and provide the data to the HAL and the upper layer via the IDL as well as to the other applications that support more complex or more sophisticated cases. 
Discussion on how to manage the signals (deleting / adding signals).
Sachin: when you see the properties defined, Google clearly demarks the properties by the vendor specific properties, you can tag them and there are generic properties defined by Google. So whenever they update the properties, I am pretty sure that they are not going to update the vendor specific and we can hold them. If you add a hundred or thousand properties, they will retain them. I mean when they update the major version then only everything gets reset. The minor versions are always backward compatible. But the only risk you have is to have an overlap and use the same signal in your vendor specific as you have in the signals
Gunnar: there is a need to discuss access control further
Gunnar: next step for the group is to define which ways need to be investigated
Alexander: we need to present more experiences in my opinion

Next call (22 October) agenda
Agenda items (to be prioritarized at the beginning of the call)
•	Software architectural task force : Vehicle Data architecture for Android - continuation of discussion
•	question to address in the group: what do participating companies intend to do with the JAPI (Java API similar to CommonAPI for Android) ? this building block is currently missing
•	Signal to service translation
•	Secure access control in Some/IP
•	Comparison of how vehicle properties are managed by Android 9 and 10 (Q) - further inputs
•	AOB