Minutes of Android Automotive SIG
Vehicle Data API Sub-Project
10 Septembre 2019
Agenda
1. Data structuring (VSS, Android Automotive Vehicle HAL): continuation of discussion on combining VSS and Android or not 
2. Initial thoughts on architectural design : Some/IP - where does it sit in the big picture  ?
3. Initial thoughts on architectural design: continuation of discussion on the boot sequence
4. AOB

Attendees: 
Sachin Athanikar (Daimler), Giovanni Vergine (Visteon), Viet-Anh Pitaval (Tieto), Marcyn Katulski (Tieto), Stefan Wysocki (Tieto), Eric Serre (Renault Software Labs), Pete Brown (Wind River), Guru (Bosch), Stephen Lawrence (Renesas), Gunnar (GENIVI Development Lead), Philippe Robin (GENIVI, Project Management Lead), +4
15 participants
Apologies: Johan Strand (Melco)

Introduction
Philippe: welcomes the participants and presents the agenda
Data structuring (VSS, Android Automotive Vehicle HAL):
•	Gunnar: The idea is to take a VSS style database and one approach I tried out is to translate it to Franca IDL and then use to generate Some/IP interfaces because this is something we can do from Franca using the CommonAPI tooling to Some/IP
•	of course on actual Autosar systems another tool chain would likely be used and that could possibly involve the Franca to Autosar translation tooling (that GENIVI is working on) or not, depending on how companies do that, the work I have done is a proof of concept of how we could expose the service that provides vehicle data on Some/IP.
•	I have not seen the actual plans within Autosar, I cannot guarantee that the above approach matches but there are different ways to design this we can talk about. I have a few slides on the process to go from VSS to Franca to Some/IP.
•	Pete: I do think there is a fundamental requirement that we should agree upon which is: does Android have access to a vehicle bus directly, even though the Android HAL provides some level of granularity with respect to read and write access to properties to Android applications ? What when the Android OS becomes compromised having access to the vehicle bus ? What about and the concepts of layered security and having things like vehicle properties handled outside of the Android OS and Android just and its Android HAL being a client to that external service .
•	Gunnar: that's certainly a possibility and again, I don't know what the preferences are on the Autosar side, but what I'm talking about is something that could potentially be limited to a set of signals that only the IVI system should have access to and then once you're at that level you need to discuss whether there's an application-level filtering on those in addition
•	We didn't get through that discussion completely on your (Pete’s) proposal last time, you were describing roles that sounded like the role of the complete infotainment system or a complete something else (e.g. domain ECU) and it's not the applications that are doing their access control when they are speaking to the Autosar system.
•	We will have another level of access control and filtering between the IVI system and the applications in themselves, so that each application only has access to what it's supposed to. 
•	Pete: I do believe in layered security and my assumption was that everybody agrees on the Layered Security and the Android shouldn't be directly in communication with vehicle buses. I agree with the fact that there needs to have an application level granularity, but then with the assumption that the operating system itself can be compromised especially from an IVI internet-facing application point of view, my belief is that vehicle properties should be a separate service that Android is a client to with an additional level of read-write access to the various properties of the vehicle.
•	Gunnar: Then it's the combination of all Android applications, the superset of what they need is what the Android system has access to in that case.
•	Pete: agreed, nothing to restrict what the Android applications need, but they go through the first level of Android granularity with respect to right access and then Android is an operating system having to communicate with something else which also provides another layer of read-write access
•	Gunnar: we are on the same page. So what we are talking about first is this kind of the primitives we need to build up such a layered system. 
•	Pete: we need probably to get some level of agreement on that fundamental requirement.
•	Gunnar: is there disagreement ? I wouldn't expect there is disagreement on that. But on the other hand my approach is usually to lay out the different building blocks first and then figure out what we can do with these blocks, and then apply our security thinking and make sure that the final design is correct. I don't think we have a problem agreeing upon on that upfront 
•	Pete: I would probably argue that Google and their Android Vehicle HAL definitely has no objection to that HAL being implemented directly to a CAN bus and then to people implementing it that way. 
•	Gunnar: (slide deck show starts) We're talking about building blocks and pieces and then we can see what we do with them.
•	Slide 1 (credits): I reused some introductory slides for VSS here that were written by Rudy Streif (JLR) originally. I just want to see that we all have consensus and the same understanding 
•	Slide 2 (Fat API): I found a good slide that talked about the FAT API that would be essentially an API where in this case vehicle speed is part of the function name itself. And so you would have one function per data item and it becomes your programming interface and that's a fairly large API and we would call it a static API because it would be generated from your database and then you would have the compiler check if that function exists
•	So some of the issues of course is that this is not so dynamic and you need to be very careful about the versioning of the interface for instance.
•	Slide 3 (New Approach) : The new approach is described here. So basically the slide speaks about how a service might be implemented with a get/set, subscribe/unsubscribe and just a few different functions now, what I would like to add to this is that describing data in the signal tree does not decide whether the interface is the thin or the fat one, what I'd like to demonstrate here today is the ability to create the FAT API out of the signal tree 
•	Slide 4 (Dynamic Thin API): So thin API has some very simple signal-like get signal and you would pass the signal name as a string or some other identifiers. And that becomes then very dynamic because you can ask for anything and you don't necessarily know if you're going to get an error response or the server saying I don't have that signal.
•	Advantages are this is more flexible and it might be easier to divide these services dynamically, i.e. some of them only provide a subset of the signals and others provide another subset and so on, it is the typical way for the web and web protocols and perhaps the disadvantages, depending on how you look at things, are that you don't get the compile time checking that your program is accessing something that exists and potentially also it's a bit less efficient depending on the details, but you essentially send the signal name as a string and on the other side you need to look it up before you can give the answer and similarly for put / modify (I only covered get here for simplicity).
•	Slide 5 (Vehicle Signal Tree): the VSS is about describing the data model in a tree and making it fairly fine grain because we have potentially a lot of data to be described and we need to find out how to best organize that data. 
•	Slide 6 (Addressing): Typically you can transform the tree the way you like, you would for instance address it with a fully qualified name and a path that brings us to the “dot” notation, which is the standard way. But if you were to do this in a web protocol, it would probably be “slashes” between in a URL and in another protocol it would look differently. 
•	Slide 7 (Specification Format): another example here, the actual VSS has a lot more parameters inside of it now, but this is the kind of things like min/max that you might have in the data types 
•	Slide 8 (Format Transformation): there is in VSS a set of different generators identified for transforming the signal specifications in different ways. What I looked at (in my proof-of-concept) was the Franca generator and that current generator transforms the tree into a Franca based data structure that is a large array of all of the signal definitions. I felt that's not exactly what we might be looking for, if we want to actually transform it into an API that can use to access the signals. 
•	Philippe: Pete presented a variant of this slide two weeks ago and said that we might end up with a conversion tool from VSS to ARXML (Autosar XML)
(new slide deck)
•	Slide 1 (Creating signal access with VSS + SOME/IP)
•	Slide 1 (Add new Franca IDL Attribute generator) Gunnar: Yes this is what I've been working concretely on by considering a translation to Franca IDL attributes, attributes would be called properties in other interface description languages. Those are the ones that we would be able to describe and monitor and that translates well into Some/IP which also has this feature. Some/IP has the concept that you can subscribe to changes on a certain data item. It was fairly simple just to take the existing Franca generator and modify it for a proof of concept.
(new slide deck)
•	Slide 2 (Running vspec2franca_attributes 1): So the interface is a little clunky, the first input is the name of the package, the second input is basically a pattern matching against what part of the tree you want to cover and the third input is the name of the interface.
•	Slide 3 (Example Results): And so basically we want to generate an interface named FuelSystem and we want to just only include the VSS subtree that is called vehicle.drivetrain.fuelsystem and put it into a package named Vehicle.Drivetrain and so here are the results getting out in Franca
•	It has the package name and has the interface name and the attributes only need to have their simple name since the rest is described by their name space hierarchy here. I put the fully qualified name on the right for the sake of clarification. I haven't done any attempt to deal with the types. They need to be translated into the primitive types of Franca IDL and so on that should be fairly straightforward. 
•	Slide 4 (Running vspec2franca_attributes 2): if we want to generate this slightly differently, we would match it differently. So here's a package name Vehicle. We want to match just the fuel system part of the tree, but we want to have the interface on the drivetrain level and, assuming that our target system supports this, it would then have a partially qualified name like this, and so that also works in my little prototype. 
•	Slide 5 (Example Results): the next step would be to run the CommonAPI generator on this and what we can get is a C++ interface that is of the Fat API type so you will get both the server and client APIs generated from the common API tools, and you would be able to program the server that accepts subscriptions to these attributes, i.e. the ones that are included and only those since it is a static FAT API approach here and you would be able to program the client that subscribes to them and Some/IP would be working to fulfill those subscription updates when we use the Some/IP backend on CommonAPI.
•	Slide 1 (Conclusions): I wanted to show the potential building blocks we might have. If you want to start playing around with this, another alternative is to write the small Franca files as Thin APIs, that's only essentially 4 to 6 functions since you passed the name of the signal as a string instead and you would do a little bit more programming on the other side to take that string and interpret it and look it up. But the approach would be the same and it would be possible to make a Thin API over Some/IP as well.
•	So now comes the question: what do we want to do and where do we want to place these services (i.e. what Pete was talking about). What does the overall concept look like? This is just a proposal for one of the building blocks.
•	Pete: it does make sense. I like the thin API concept. 
•	Gunnar: I'm looking at it from a very wide angle here. And if we consider the current Vehicle HAL, then it is more of a FAT API approach and you would have to decide on which signals are actually exposed to the applications. 
•	But on the other hand you can use some of the normal application manifest features, if you consider an application manifest the way it is today, it is very static, you actually list what services you want the applications have access to and then that has to be approved by the user installing it or maybe in the automotive case, the OEM is making such approvals. 
•	The dynamic interface goes a little bit against that but it is more flexible and it would require a dynamic access control so that when you request the signal you might be denied access and you would then get an error message back saying this signal doesn't exist or whatever. That's what the application would be getting (I mention this because Pete was talking about the Thin API also on the application level)
•	Pete: I'm not sure that there's a conflict there. I think as long as an Android HAL can do effectively the translation between the Android world and its API and be able to figure out how to get that information from whatever it's communicating with, I think there's enough of an abstraction. 
•	That's why I don't think we really need to worry about the applications themselves. Definitely, there's a chain of security privileges, so Android may or may not deny an application a privilege, if the Android OS does not deny a privilege then it's going to go from the Android HAL layer to whatever service is actually providing these properties and then there's another layer of privileges that would need to pass but it would really be a system architecture issue to whether a given application in the requested privileges will end up being granted.
•	Sachin: basically when we say the service, are we talking about the system service for the vehicle HAL ? because as per my understanding so for every HAL which is being created, there needs to be a corresponding system service which accesses the HAL over using the interface, basically the HIDL (?), it's just another example of generation of the HDIL for the fuel system
•	Gunnar: No, that was not included here. Of course, if we know what we want to do with the architecture, we can consider tooling that generates those necessary IDL files and any other necessary configurations or bindings to tie it all together into the Android architecture. 
•	But this is what I was jumping around a little bit because some people focus on what is currently in the vehicle HAL and the way it's done there and others seem to propose that's too inflexible and we're actually exploring a completely different mechanism.
•	And if it's a different mechanism, then everything is open, you would create some kind of service in Android that you can name and that applications can attach to but what that service provides in the APIs it is using seems to be completely arbitrary and open for us to define if we were to create something that is besides the current Vehicle HAL. I think we've heard both of those approaches mentioned in this meeting. 
•	Sachin: some architectures (?) have to be intact with respect to the Android architecture, first if we introduce some proprietary stuff there, one thing we need to look at is the CTS, and I don't know whether it goes to the VTS (Vendor Test Suite) level or not, second with respect to the IDL specifically, how are things really maintained ? Should they be vendor-specific ? 
•	Gunnar: that's because it's uncharted territory, we're looking for your input, it seems you're concerned with creating something that is too much out of the ordinary because you immediately run against the issue of not meeting the certification requirements for example, which is fair, but there's also the viewpoint that if there is a strong need for something very different and there's a set of automotive companies that have well thought out other solutions, potentially that could also affect Google's plans long-term. Now, there's a long way to go from where we are today to that point, but I think this is sort of exploratory about what is needed and what would be the ideal design before we limit ourselves too much to perhaps the reality of the system. 
•	There is also a parallel discussion among some companies that actually are considering that they want another application ecosystem than the one provided by Google and I imagine that if it is the case then some of the certification requirements are perhaps not that strange things (?). I don't know all the details here. I imagine there are various ways that this can play out differently for different companies.
•	Sachin: it makes sense to explore and if there is a strong need for a long-term vision to have a proprietary interface as well as the applications to be supported, that needs to be evaluated. 
•	Gunnar: that is essential in parallel with what Google has defined and you might be fully combined with all the CTS even though you're providing additional functionality as well. That could also be a way out
•	Gunnar: let us recap, is what I presented a building block ? if this is not a building block, what would we have then for Some/IP ? We would have some approach on Autosar systems to define services that provide vehicle data. What will those services provide ?
•	Philippe: I have one question for our OEM participants, this question is whether you are aware of what Autosar is doing on the service to signal conversion and whether this topic is relevant for what we been discussing today.
•	Pete: it's an interesting question. It's my understanding that the whole signal to service stuff is still in flux. Again I would like to get some fundamental agreements: if you look at a more modern vehicle architecture having Ethernet in the vehicle and potentially multiple access points from a Ethernet to Can Gateway point of view, we may need to have more than one property service given a zone in the vehicle and given the distributed nature of the networks within the vehicle, I really want to get to the bottom line that the Android vehicle HAL is a HAL, i.e. an abstraction layer. So I don't want domain controllers within the vehicle being dependent on Android (and services within Android) to get vehicle properties. I think the whole topic should be: Android provides an abstraction layer to get vehicle properties, we should define what's the right architecture and the right services, how they should communicate and then the implementation of an Android HAL is just an implementation detail along with any other IVI OS such as a AGL or others. 
•	Philippe: Is there anyone in today’s call who is mature enough in his/her thinking of what is the software system architecture including Android should be and ready to answer the fundamental questions Pete is asking ?
•	Eric: When you talk about having Autosar and Android, do you talk about Classic or Adaptive Autosar ?
•	Gunnar: Some/IP is likely the common factor
•	Pete: from an Adaptive Autosar point of view the underlying implementation transport behind the ARA:COM interface can be Some/IP but does not have to be Some/IP. There's a layer of abstraction there which we shouldn't worry about what the actual transport is. My position is that it should be a service-oriented architecture and not Classic Autosar, it should be Adaptive Autosar and therefore it gives you the flexibility to define the communication transports and evolve them as needed. 
•	Gunnar: I think it's fine for Autosar to say that among between Autosar nodes, we have all this abstraction stuff and we can choose one protocol or another but when you communicate with non-Autosar systems, I am really quite opposed to the idea that there isn't going to be any stable ground to stand on. 
•	I think we need to say that when an Autosar system communicates with a non-Autosar system, there's a fairly defined way to do that. And I don't think it's going to include all of the flexibility and various ways that you can do things in between two Autosar systems, it just doesn't sound right to me.
•	Philippe: we should try to answer Eric’s question.
•	Gunnar: when Autosar speaks to a non-Autosar system, it should be Some/IP or something else but being flexible everywhere does not work out for non-Autosar systems because then there's nothing stable to stand on, then every system must implement an Autosar middleware, and in my opinion,  this is not the right approach
•	Eric: on a system, you can have both, because for example if your IVI system needs still to communicate to the CAN bus, it can do it via a micro controller running Autosar Classic and you can have also another leg on the Ethernet network using Some/IP via the Adaptive Autosar framework
•	Pete: I don't want to introduce confusion to what I'm saying, at the end of the day, definitely there needs to be a common underlying transport to communicate with non-Autosar and I do think that is Some/IP. I do just think though that any focus in this discussion on Some/IP specifically is an abstract detail. It's not really central to the discussion. 
•	Gunnar: It may be, in that case, I think we're talking about some common characteristics at least. So you probably going to want a protocol that has some similar features like the ability to say here is a method remote procedure call that I'm invoking a function, I want to get an answer back and then here's an attribute that I can observe and I want you to notify me every time this data changes, these are two features built-in in Some/IP and I would think in most protocols that are useful, these features exist.
•	Pete: where I'm coming from is I'm looking at the world these days in terms of standardizing services and what services architecture you can use for that and my thinking just takes me towards Adaptive Autosar. That’s all.
•	Gunnar: Eric, did we answer your question ?  
•	Eric: my understanding is that in your view, if you want to have your system talking using Some/IP, you must have an Adaptive Autosar infrastructure for that because we cannot imagine to have a direct access to Some/IP without having Adaptive Autosar running on your IVI system. Or did I misunderstand what you said ?
•	Gunnar: are you saying that you need a complete Autosar middleware in order to communicate using Some/IP ? that's not strictly true. 
•	Eric: my view is not mandatory, you can have a Some/IP infrastructure which you can access via Android. You can build a kind of Some/IP HAL to access your network. 
•	Gunnar: we can do this without running a full-blown Autosar system in that HAL. We've already proven that we have the vsomeip open source implementation and we have the CommonAPI layers on top. We've already set up the traditional GENIVI IVI Linux based platform and several others, including AGL and APERTIS, three different Linux variants running vsomeip and CommonAPI on one side and all three systems communicate with an Adaptive Autosar stack. So Some/IP as a protocol can be run independently of the rest of the Autosar stuff.
•	Gunnar: I can give you more info on that demonstration which is part of the Franca ARA interop project. It works on several systems but was not built on Android yet.
•	Giovanni: about the usage of Some/IP without Autosar, my opinion is that the Some/IP protocol is quite straightforward and simple. We do have already in GENIVI C++ implementation, and for sure the specification is not so difficult and I don't see really a need to have a whole Autosar ecosystem in order to talk Some/IP, maybe we would need some certified Some/IP peer from the other side in order to certify any solution with Some/IP in order to check that it's compliant to the specification but in generally at the end of the day, it's a binary protocol with some fields and a straightforward way to serialize and deserialize structures. My opinion is that Some/IP does not involve that level of complexity that we need to bring when using the Autosar ecosystem. 
•	Gunnar: At least to clarify my scenario I'm thinking about, at least one of the node is an Adaptive Autosar node, I'm just saying it doesn't need to be both of them, but it could also be between two non-Autosar systems. 
•	Giovanni: I would like to add that even if it would be needed to take some part of Autosar, that part would be the ARA::COM layer that anyway should be internalized, it should rely only by specification on a very small subset of the posix infrastructure. So even if we say we take Some/IP plus something else, it's still quite portable being on top of the posix standard, it's a very small subset of posix that basically include some posix calls and the pthreads. But that's the worst case. I mean in general is pretty straightforward just to use the framework.
•	Philippe: At this step, I would like to share with you the comment I received from Johan about whether it is worth looking at combining the VSS and the Android Vehicle HAL. Johan said that it's a good idea and underlined “Standardizing the signal structure should be of great use for all to increase interoperability of ECUs and facilitate sharing vehicle data”. 
•	Gunnar: that's good to hear. And as far as I can tell, this is the way to go for this group but also a way to propose and affect the potential decisions in Autosar how to organize this because it seems to be in flux and why don't we try to do something that works together ? And if it's not VSS, then it's something else with a different name that is pretty much the same thing. Anyway, there are so many ways that you can efficiently describe your data and hierarchical categorization. 

Update on the boot sequence. 
•	Daimler will provide an update in an upcoming call.
Backlog creation
•	Philippe: it is time to populate the backlog and create a first list of activities
•	Gunnar: let's just try to figure out what the open questions are and see if we can build some activities based on that. 
•	There are two immediate open questions for me, one is of course : what is the HAL ? is this a signal to service translation thing ? is it something similar to what I described today or is it something different because obviously we need to relate to the way Autosar systems might do that ?
•	the second question seems to be the ability to have a real secure access control on the Some/IP protocol itself. Is it true that there is no such thing built-in ? because then that heavily effects the architecture, it basically means you need to separate your networks and provide only the services that should be available to certain nodes on a network that is connected to that node because the node itself has access to everything that you provide there. And the rest of the access control happens on higher levels but maybe there is some kind of extension or capability that I'm not aware of.

Next call schedule
 Next call will be scheduled on Tuesday 24 September at 5pm CET. A calendar invite will be sent.
Next steps for next call
/TODO/ all participants to review the minutes and provide their open questions (questions can be posted to the mailing list prior to this event)
Agenda for next call (proposal)
1.	Open question: Secure access control in Some/IP
2.	Open question: Signal-to-Service translation
3.	Initial thoughts on architectural design: update on the boot sequence
4.	Backlog review
5.	AOB
Adjourned: 18:00 CET