Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Setting up IT related stuff, getting everyone connected
Announcement: GENIVI Spring AMM will take place on May 12-14 in Leipzig, Germany. We will have AASIG face to face meeting(s) there
TODO
09:20
Agenda Review
Philippe: reminds the objective of the meeting which is to agree on a couple of design scenarios and move to detailed design and implementation, target is to have PoCs available at the end of Q2 and be able to contact Google
Gunnar: Contacting Google -> we need to prepare before the time window closes
Going though the agenda, topic by topic so that everyone is in-sync
09:30
Roundtable
Alexander: BMW, connectivity, now looking into boardnet abstraction and how we can use it on different platform
Gunnar: Genivi project, development/technical lead of Genivi
Piotr: Tieto, AA for 3 years, audio routing, helping with Genivi
Stefan: Tieto, AA for 8 years, mobile, embedded, architecture
Philippe: Genivi 10 years, Autosar in parallel, working with German OEMs & tier1, before was managing a SW consulting company working with Continental in particular, Telecom before that and Aerospace
Bartosz: Tieto, wroslaw, 8+ experience with Android, multimedia domain
Nadim: esolutions, elektrobit, Mobis, SW developer, how Mobis can contribute
Justin: hardware engineer, connectivity, audio, how Mobis can contribute
Kevin: CTO high mobility, data model of the car, and other topics, see where Genivi is going
Gururaja: Bosch, 6 years with Genivi, connectivity, HMI SW development, Infotainment systems
SKYPE: Johan: Mitsubishi electric tier1, 6 years, Genivi quite new, but would like to get back
Sachin: Mercedes Benz Research North America
Vehicle HAL Security design
09:45-10:45
Access control and permissions in Android (Stefan)
OEMs need to have a secret key service management inside their process in order to support the permission verification
the package can be signed with the platform key and released to GooglePlay
there will be for instance different instantiations of the same code with different signing keys for the different vendors (OEMs) who want to deploy the same app
currently there is no shared signing key among OEMs
when Stefan says GooglePlay, this is GooglePay in GAS
Guru: my original thought was that both the app developer and the OEM should approve the deployment of an app with their own key
Stefan: this is not possible, there is only one key
Gunnar: can an App be signed by 2 different keys ? The system would check the signature of both keys
Stefan: Samsung, Sony do this, they use additional APIs for this purpose
Guru: This restricts how third parties can create application for our systems
Stefan: no, it doesn't
Sachin: what do you mean ?
Stefan: We can have our own version of stores
Gunnar: this needs more thought, the idea is to have two signing keys, developer that I made this, system that we agree to this.
Stefan: But it's not possible
Alex: let us assume every OEM has its own playstore, the key is developer key, but the OEM would add it or not
Side load an application (APK download and application)
So the model is that everything that is downloaded is already accepted by the system
The store is not the only source of applications
Gunnar: This is more a question about open/close system: it's for the user to accept the permissions and the OEM should not restrict or regulate them unless it is a sensitive permission. We don't need to sign it from the OEM
We already showed that the properties are available and some not (protection level), a propert can be: normal, dangerous (needs to be asked, user should agree), signed, privileged
Sachin: each display will have their permissions, for OEM how can we configure these displays
This might be treated in the next presentation by Piotr
Gunnar: the normal model is that the system does verify the signature
Each developer sign with their keys and put them on the app store
The system checks if the signature is valid and the key format is correct
There is no cross checking (like https and playstore)
Playstore is only certifying that the application was downloaded using the playstore (and not a side download).
Gunnar: We need to check the open/semi-open model, and understand how we will manage it from technical point of view.
Analyzing the need and the solutions
The solutions would be too much for this group
Probably these discussions are being done already between single OEM and Google but not with GENIVI
Or we need to have our own service.
Side note: The Android deficiencies come from the history of Android, from phone to car, there are gaps
Next steps
Gunnar. there is some work to figure out the different models
Sachin: Google has decided beforehand for instance that controlling the HVAC is only possible for an App signed with the platform key
Sachin: in a car we will have multiple displays with different permissions because displays show different things
Piotr: I will make a proposition for this because AFAIK this is not supported by Google
10:30-10:45
Break
10:45-11:30
External service approach - how to use Adaptive AUTOSAR Identity & Access Management (IAM) (Alexander)
Alexander had a sync with Giovanni Vergine & Stefan Wysocki on Adaptive Autosar IAM prior to the F2F but we realized there are many open issues we need to look at
First we need a solution for accessing or exposing the data in the vehicle.
For example: Ambient light, you can change the color, brightness etc. During development, the application developer is directly communicating with the ECU developer to talk about the colors etc. But this does not scale.
We need a system that can handle data like what are the colors enums etc
Question is: how to authorize this and how can we ensure this communication.
Idea: Authentication service, Data service.
Data service would request the data
Authentication would check if this App can get this data and give a token to the data service
The data service is then using the token to get data
Alex: yet another example
parking assistance data cannot be abstracted using VSS because there are too many states,
Alex: explains why we need some kind of abstractions of vehicle data to share knowledge with developers who are spread geographically (they cannot share their knowledge of the car like if they were sitting in the same room)
Alex: would like to have a specific service offered by the platform to get access to the vehicle data
Alex: Autosar does not seem to be so extensible
Alex; we will need to generate tokens to enable the access to applications (token valid for an hour or one day or...)
Alex: in VSS we have leaves which are the data, we will have also groups, we do not know which granularity should be shown at the application manifest level
Android is activity based. If we make the data service in the framework does it have an advantage ?
Advantages
We can control better, for example not to forward the request to the data service if the authentication service stopped it
Also we would have one way to access the data
Disadvantages
Bottleneck for the applications always passing through the framework
Data server app authentication process have been added to the architectural concepts diagrams, look at
We need to think about the idea, what is better - service layer or application layer ?
11:30-12:30
Users vs. permissions - presentation of the zone concept in Android 10 (Piotr)
Piotr shows this
overview of Android account types (taken from Google documentation)
Piotr explains how a user can be identified, how to recognize user
Primary, secondary, guest currently available on android
discussion on how to check app/user permission, connection to what was discussed earlier
In Android Automotive now, we have the following situation
Headless system user: main services, owner of services, etc.
Secondary user: driver etc.
First example - audio
as a rear user I'd like to play my audio on rear headphones
the display in the rear or audio in the rear are now solved by using a different user id
HAL is not aware of the user: that's the problem
Same solution as above, application will ask the authorization service for a token and then the application can use this token in order to access graphql (i.e. the vehicle database)
Other possibility is a content provider, this is the most common way in Android for the application layer to access data
Main point is that there is a single point of access for example to the HAL
One example to understand more: let us assume we have one tyre monitoring application developed by BMW
if I log as a BMW user, I got all data (tyre temperature for instance in addition)
if I log to the same application as a Mobis user, I do not get all data
There might be that the dealer would like to know how many times the wheel over-heated, this is regardless of the user
Guru: regarding users, we have a lot cases - valet, chauffeur, kids mode, etc.
Guru: can we solve this with the VSS model or with an API created for this purpose ?
Do we need an application that runs differently for different users ?
Kevin: it's up to the application to show the UI according to the user
This is also a point that the framework should not be deciding on behalf of the application what data is accessible
Is this needed for the boardnet data?
Do we have specific examples to show that we need a different user for the same application
Do we need to give different permissions to different users?
Gunnar: can we come up with such a use case ?
Gunnar: one option is to create a specific API when you need to access very finely controlled data and not embed the access control in the VSS database
Another example: the taxi driver's situation
for Mercedes Benz a taxi belongs to a specific car line (i.e. a taxi has different features than a normal car)
These users are not really the Linux users but they have their own places to store the data
Sachin: what we want to achieve is to expose to the Android world the vehicle properties which we have been handling in the Linux-based infotainment systems so far
Alex: can you and your wife be logged in the system at the same time?
Sachin: the answer is no
Sachin: the control of the display is only based on its position not on whom is using it
Sachin: the restriction at application level does make sense
End of long discussion on how to control access to data at the application or the service (framework) level
wrap-up (before and after lunch)
data access verification component: application permissions and user permissions need to be combined
Letting the application decide what to do is good but not for a closed system (TBC)
Framework needs also to have restriction
Permission management can solve this by creating permission of groups
Gunnar: we need UID (user identity) to be shared down to the low layers
Discussion about what we need to solve, what is the problem to solve ?
There are different solutions of course even with Android
12:30-13:45
Lunch Break
13:45-14 :50
VSS layers
Please refer to this VSS composable layers for an introduction to VSS layers concept
Gunnar presents a short implementation of Android permissions in VSS (TODO Gunnar to provide link to example code)
New extension Apspec that links the main signal database to the permission of each
In the standard there are signals, attribute, sensors
The permissions are different for different systems so the permissions files need to be independent of systems
The idea is that we can have metadata such as Android permissions in a separate file
Alex: coins the idea of a deployment file Apspec and have the permission "attribute" as a generic thing in the VSS layer and the "Apspecs" in the deployment data for Android Automotive
for instance in Autosar you would have a different folder with the permission
Gunnar: shows the implementation of VSS layers he has in mind
The ideas are written in the file fuelsystem.appspec
Think about generic solution
Think about grouping
Think about permission level
Does write access also give read access ?
Closer to VSS and easily parse-able
Gunnar: we need to write some tooling to process the VSS layers
Apspec could have no include just the entire name
Is it better to keep the same structure?
Opposite mapping - entity
Nearest to the Android
Protection level can be included
More user friendly
This is preferred
There is no point of thinking of very complex scenario, because at some point we can create custom API
Wrap-up
We will investigate the following tracks
Track #1: do not include users, just the authentication service and application talking to directly to data server, the users will be dealt with a different custom solution
Track #2: include the users and let the application only communicate with data server from one point of entry
For Android applications, we will have a list of permissions listed in a file, and then we have the (VSS ?) leaves listed inside each permission
Information
Gunnar: provides the link to the W3C public mailing list where the VSS layers concept is discussed
Vehicle HAL Technical Proposals - further refinement
15:20-16:00
Android internal service (Some signal-connecting library using VSS standard) (Stefan)
Stefan shows this on the translation from VSS to VHAL properties
Long discussion on variant III slide and content of vehicle HAL (custom HAL vs. vendor-extension)
Discussion on various alternatives to implement things in Treble or the framework
We don't write in HAL but in HAL extension
We have some work to do to agree on the model before having people work on implementation
Mapping from vehicle data to VSS and properties is needed
Kevin: as a third party app developer, do I choose if I want a permission of Android or a VSS permission? Are there two ways of getting data?
Yes but the Google way is key/value, with a limited API
For instance VSS has battery status, Google does not, what happens in the future ?
So yes there is two ways of working
SOA or Data driven approach
We need to define which data are cached or which data has to be directly taken
Property value change propagation will be covered by the protocol implementation we use to communicate between the data server and the app
If we only have get/set/subscribe we don't need an API
16:00-16:10
Break
16:10-17:05
External services - SOME/IP (Gunnar)
Gunnar shows the slide with Some/IP usage between the vehicle nodes (look at slide 14 Architectural proposal III (via Global SomeIP Service) of this Vehicle HAL Architectural Design Concepts
The idea is to mirror in the framework layer services that are outside the system,.
This is related to connecting Android and non-Android systems
The general connectivity concept in Autosar is the following
there is a request, followed by a send to authentication: is this request allowed? Then the request is denied or the data are sent back
The concept here is saying: any app will check in the database if the request is allowed or not
But in case of external apps/db to the system, the app will only check if the system can request data but not per application
So the system needs to implement a way to check if the application can access the data from the external app/db
When we have a VSS, we can better describe or know where the data is coming from exactly
The main problem with app directly or via socket communicating with external services is that we won't have control over them, there is no check if this app is allowed to access it
Piotr: what about a service that does some service discovery and tries to do the request of the API ?
Johan: cannot we put the managers in the HAL ?
Actually we discussed it before, it's not a hardware and this is why we shouldn't officially put it in the HAL, this is not where it belongs
But we can put it in the HAL because we can make it just to say that this is another abstraction layer
interesting discussion on why to use SomeIP, how to aggregate data through an ad-hoc data server talking via someip to get the elementary data
17:05-17:15
Agenda review for Day 2
We need to change the architecture diagrams
We need to decide what do we want to implement
We need to name the ideas or concepts appropriately
17:15
End of Day 1
Time
Day 2
TODO
09:15
Start
09:15-10:00
Summary of expectations
Sachin: Which design to use (develop), or at least prioritize ?
Alex: which directions should we go ?
external data server as a service,
SomeIP connection to framework layer and apps
Sachin: it looks promising in particular the integration of VSS, we need to select one approach and projectize it
Recap of yesterday's discussion
approach 1: (data server app) is sitting somewhere, on a Linux partition or a different ECU, we have an App installed on Android, this App needs a web token to get the data
approach 2: (architecture proposal via custom HAL), the app does not have any direct communication to the data service
approach 3: SomeIP approach there is a SomeIP service somewhere and there is a generic SomeIP service in the framework
Nadym: where is the bottleneck in approach 2 ?
Alex: this has to do with the number of requests for data
Sachin: we need to be compliant with the Android Auto architecture (not from a CTS standpoint, only from the code structuring standpoint), do we follow the principles of code organization set up by Google ?
Alex: GAS App do not have any service inside the framework
Alex: let us skip the SomeIP approach because we know how to do it with model transformation and code generation
Alex: let us focus on the vehicle data server
Gunnar: we all agree
AASIG Statement Of Work - DECISION Vehicle Data Access Architectural Design & Implementation
AA SIG will develop a PoC implementation of the External Data Server (priority one).
AA SIG will develop a PoC implementation of the Data Server inside the Framework (so-called Internal Data Server) (priority two)
AA SIG will develop a PoC implementation of the SomeIP stack inside the Framework (priority three)
AASIG will develop a PoC implementation of the Google VHAL + OEM Extensions inside (priority four)