Current thread (from February 2021 on-wards): investigates this architecture
Previous thread (until January 2021)
...
: External Data Server Proof-Of-Concept - Work Breakdown Structure
Next Meeting - VHAL / Vehicle Data APIs weekly call - every Tuesdays - 17:00-18:00 CET (except when replaced by the monthly All-Hands)
Meeting Information
JOIN ZOOM MEETING
Meeting Zoom link
meeting ID : 993 7365 2562
password: Vhal!21
local dial-in numbers: https://genivialliance.my.webex.com/genivialliance.my/j.php?MTID=m48a6a9c068e5273ccdb2da5d1cba4317
Meeting number: 126 709 7631
Password: U8MeDmnmS73 (88633666 from phones and video systems)
Agenda
Backlog
Expand |
---|
Backlog
|
...
...
Tuesday December 7 – 5:00 PM CET
Participants
- Kyrylo Skidanov (EPAM)
- Stephen (Renesas)
- Stefan Wysocki
- Gunnar (COVESA)
- Alexander Domin
Minutes
Kirill: Procuring a development board. Apparently graphics subsystem not starting on ARM64 (Google confirmed this...) Being investigated.
x86 emulation might be an option. More disk space coming soon to prepare for builds.
Alexander:
- New code now at https://github.com/COVESA/graphql-vss-server-libs
- Proxy instance should be a singleton. This is implemented.
- Standard logging and DLT logging is implemented.
- Custom scalers - translating values to the right format
- Query management
- Access control (permissions as defined in schema). JWT validation of each query.
- View README for more details.
- Actual server implementation probably available end of this week
- https://github.com/COVESA/vss2graphql_schema also extended functionality
Further discussions about challenges of mapping VSS/different environments.
The Franca mapping file is very flexible - can map to Franca attribute (including subscription of changes, or to just a broadcast
or to an explicit getter function exposed on SOME/IP. Similarly for writing, but it is defined independently => in theory different mappings for reading vs writing.
Stefan: At the moment interested in Vehicle-Properties translation primarily, but it is interesting to see this other concept progress.
...Good to see that Microsoft's C++ implemented GraphQL is mature enough. Apollo tried before which meant putting Java into the HAL layer, not ideal.
Compiling vspec2aaproperties code
Stefan: I tried also this but little progress (challenges with diferent computers, environment, disk space).
---
Tuesday November 30 – 5:00 PM CET
Participants
- Kyrylo Skidanov (EPAM)
- Johan (Melco)
- Stephen (Renesas)
- Manu (Bittium)
- Philippe Robin (COVESA)
- Gunnar (COVESA)
- Alexander Domin (BMW)
Minutes
- Updates on vspec2aaproperties code generator. Generated code through compilation with minor changes.
Need to add generation of getProperty... function for fetching dependent properties needed for complex calculation. This function is currently not included by reference to the implementation. - Manu: .... prefers generating these functions (variants depending on data type) according to if they are needed, which was done similarly with the type-conversion functions.
- Discussion about setting up a repeatable build environment. Apparently the standard way of building AOSP is "the whole system" (although rebuilding in the same directory structure is of course incremental and relatively fast). How is AOSP builds normally set up for CI systems??? There ought to be a structured way to reuse a cache of already built artifacts.
- Explanation from Alexander about the set of tooling (mentioned last week's minutes). A demonstration of the technology planned for the next CVII Tech Stack meeting instead, since it is also more widely applicable beyond Android.
Tuesday November 23 – 5:00 PM CET
Participants
- Kyrylo Skidanov (EPAM)
- Johan (Melco)
- Stephen (Renesas)
- Manu (Bittium)
- Philippe Robin (COVESA)
- Gunnar (COVESA
Apologies:
- Alexander Domin (BMW)
Minutes
- Looking into the BMW code drops so far (Full end-to-end example of SOME/IP signal source to GraphQL server providing VSS data).
- https://github.com/COVESA/vss2graphql_schema/
- https://github.com/COVESA/test-someip-service/
- https://github.com/COVESA/test_franca2vss_mapping_layer
- These are 3 initial parts, actual GraphQL server + resolver code and more is coming.
- AA properties code generator:
- Manu: I would like to get feedback from the compilation tests before continuing.
- Need Stefan (TietoEvry)'s input, with more details, e.g. Android version tested on, and how to set up repeatable test environment.
- AASIG Dev Platform
- EPAM is willing to bring it up to date.
- Starting with Emulator as main target, and update to Android 12
- Then look at hardware BSPs later - most are likely still on 11, (but that's OK - use git branches or just different handling in the scripts to handle version diff).
- Is the AASIG components work not integrated?
- Manifest repositories exist, pointing to some AASIG created software components but they are not integrated yet.
...
Tuesday 3 August – 5:00 PM CEST
- Bittium and Tieto participants are back from vacation
- Stefan delivers a recap on the plan for the demo for the upcoming AMM
- then Stefan and Alex discuss the translation from vehicle properties from VSS
- eventually Philippe asks Bittium people to consider a possible contribution to the demo or the tests of the demo, to be discussed further in the upcoming calls
Tuesday 6 July – 5:00 PM CEST
- AMM dates are set for first week (4→8 October). Location, likely Germany and virtual hybrid.
- Tools. Alignment process ongoing (which creates some open PRs and issues in VSS and vss-tools before that)
Last week we established these next actions on the property translation work. Status updates below.
Feedback from VSS working group about general strategies for metadata (hierarchical?) Gunnar Andersson
- UPDATE: Question was raised (as a heads-up, future topic) last week's VSS. Will check for more feedback this evening but it probably needs a bit of time to get all stakeholders involved (it's a fundamental question).
Start work on code generator in vss-tools/contrib, output according to chapter "How to describe the complex translations" above.
- Question: Introduce templating language (JINJA2) in vss-tools? It is used in vsc-tools and could be useful also for VSS for more complex code generation than we have today.
- UPDATE: We still have no assigned programming resource to get this started
- Question: Introduce templating language (JINJA2) in vss-tools? It is used in vsc-tools and could be useful also for VSS for more complex code generation than we have today.
- Stefan awaiting approval to publish "hard-coded" example code.
- UPDATE: Approvals slow because of vacations. Won't happen before Stefan's vacation. (A few actions for Stefan to do, testing etc.)
Tuesday 29 June - 500pm CEST
Participants
- Johan, Stefan, Alex, Stephen, Gunnar, Philippe
Minutes
tool strategy
- Alex: we are fixing some bugs and adapting to VSS 2.0 on our graphql tooling
- Alex: we are also working on converting Franca files to VSS files and then to vehicle properties, however the open source publishing process was a major obstacle
- Alex: BMW will reconnect the VHAL project in 2 weeks
vehicle properties
- Gunnar shows the wiki page resulting from the import of the file sent by Stefan
- Gunnar updates the next steps section of the wiki page on-line
TTuesday 22 June - 500pm CEST
Participants
- Johan, Stefan, Alex, Stephen, Gunnar, Philippe
Minutes
VSS to AOSP translation - WBS
- look at the Word version of VSS to AOSP translation - WBS where last week's was captured, content was reviewed during this call
Tuesday 15 June - 500pm CEST
Participants
- Johan, Stefan, Alex, Stephen, Gunnar, Philippe
Minutes
VSS to AOSP translation - WBS
- discussion on the representation of the tyre pressure
- Alex: need to add the tyrepressure attribute which is zoned and already in Android
- https://developer.android.com/reference/android/car/VehicleAreaWheel
Code Block | ||
---|---|---|
| ||
conversionMap["Vehicle.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure"] = std::bind(convertFloat,
std::placeholders::_1, VehicleProperty::TIRE_PRESSURE, (int32_t) VehicleAreaWheel::LEFT_FRONT, 1.0f, 0.0f);
conversionMap["Vehicle.Chassis.Axle.Row1.Wheel.Right.Tire.Pressure"] = std::bind(convertFloat,
std::placeholders::_1, VehicleProperty::TIRE_PRESSURE, (int32_t) VehicleAreaWheel::RIGHT_FRONT, 1.0f, 0.0f);
conversionMap["Vehicle.Chassis.Axle.Row2.Wheel.Left.Tire.Pressure"] = std::bind(convertFloat,
std::placeholders::_1, VehicleProperty::TIRE_PRESSURE, (int32_t) VehicleAreaWheel::LEFT_REAR, 1.0f, 0.0f);
conversionMap["Vehicle.Chassis.Axle.Row2.Wheel.Right.Tire.Pressure"] = std::bind(convertFloat,
std::placeholders::_1, VehicleProperty::TIRE_PRESSURE, (int32_t) VehicleAreaWheel::RIGHT_REAR, 1.0f, 0.0f); |
- TODO Alex & Stefan to add the conclusion of the discussion
Tuesday 8 June - 500pm CEST
Participants
- Mannu, Johan, Stefan, Alex, Stephen, Gunnar, Philippe
Minutes
too graphql generator
- Gunnar gives an update on the graphql generator he has published
- discussion about which implementation of the graphql generator to maintains
- discussion on the type support in the generator
- Alex will check when he and Stefan can deliver a presentation of the work done at BMW on this topic and on the open source code which is now in the publishing process
discussion on VSS to AOSP translation
AASIG development platform
- Mannu reports on the building try out he made with the AASIG dev platform
Tuesday 1 June - 500pm CEST
Participants
- Stefan, Johan, Mannu, Gunnar, Philippe
Minutes
graphql generator
- Gunnar shows a demo of the graphql generator he wrote during the last couple of weeks
- githiub: vss-tools/pull/64# repository
VSS to AOSP translation
- review of the wiki page VSS to AOSP translation - WBS created by Stefan
reschedule of CVII workshop event
- June CVII workshop moved one week later to Thu 1 July; 16:00 CEST (duration: 3h max)
- this date is fine for Stefan and Johan, Mannu will be OOO
Tuesday 25 May - 500pm CEST
"Development platform"
Manu's feedback
- Manu: Dockerfile in master uses Ubuntu 14.04 which is very old
- Gunnar: I know that we needed for Renesas BSP a certain version that had been officially tested, but it should not be as old as 14.04 anymore. I will check.
- Manu: We should add a target for emulator
- Gunnar: Agreed, this is needed.
- Stefan: There should be a lunch target named genivi-x86 something that will build OK for the emulator.
WBS for VSS-to-Android properties bindings:
- Stefan created a writeup in Markdown → now posted as Wiki Page here.
- Stefan will check about status of the translation code ("manually written example").
Tuesday 18 May - 500pm CET
Participants
- Alex, Manu, Johan, Gunnar, Philippe
- apologies: Stefan
Minutes
roundtable of call participants
update of project current scope and status to bring Alex up to date
- related tickets
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-120 Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-122 Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-123
discussion of BMW publishing of EDS-related code in the open
- the code is related to the mapping of VSS on to CommonAPI and Some/IP.
AASIG github
Tuesday 11 May - 500pm CET
Participants
- Stefan, Manu, Johan, Stephen, Gunnar, Philippe
Minutes
debrief of the virtual AMM
discussion of the planning of activities for the next 6 months
- TODO Stefan to update the VHAL project work breakdown structure to reflect the revised project scope which is now on the generation of Google vehicle properties from VSS
May 4-7 Virtual AMM - VHAL sessions
- 5 May - technical update: recorded session (please go to VHAL section), slides
- 6 May - technical workshop #1: Recorded Session, slides
- 7 May - technical workshop #2: Recorded Session (please go to VHAL section)
Tuesday 27 April - 500pm CET
Participants
- Stefan, Johan, Chris, Gunnar, Philippe
Minutes
Virtual AMM preparation
review of AASIG VHAL short update report and slides for the AASIG VHAL tech workshop and topics for the next 6 months
- TODO Stefan to split the current slide deck into 3 parts as listed above
Tuesday 20 April - 500pm CET
Participants
- Stefan, Johan, Gunnar, Philippe
Minutes
Virtual AMM preparation
- Stefan: a sample of the code shown last week is actually available in
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-123 Discussion about possible reuse of the definition language in this project:
https://github.com/GENIVI/vehicle_signal_managerThat project explores how to create NEW derived signals and events from expressions that are made up of VSS defined signals.
If the project isn't applicable exactly, it is still possible that the definition language (plus parsers / interpreters) could be reusable code for a code generator
Jira review
assigned to Gunnar Andersson that will add a final comment (reminder)Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-122 - Gunnar: the work done on AASIG-122 draw the attention of the VSS team and might lead to some changes in VSS
Tuesday 13 April - 500pm CET
Participants
- Stefan, Johan, Stephen, Gunnar, Philippe
Minutes
Virtual AMM preparation
- Stefan: shows the code developed by TietoEVRY
- Gunnar: very interesting update on the translation from VSS to vehicle properties
Jira review
assigned to Gunnar Andersson that will add a final commentJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-122
the concept (using graphql) was shown in a demo already, Stefan Wysocki please add a comment and mark it as done, thanks !Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-110
and subtasks will be revisited when we know better how Bosch code recently dropped fits into our workJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-44 - sprint extended until 30 April
Tuesday 6 April - 500pm CET
Participants
- Stefan, Johan, Chris, Philippe
- apologies: Gunnar (Mobex webinar)
Minutes
Virtual AMM preparation
- Stefan: did internal brainstorming at TietoEVRY and saw the demo developed by his colleagues, code refactoring necessary
then everyone switches over to the Mobew Webinar on Vehicle Service Catalog delivered by Gunnar
Title: SOA is coming to your vehicle program: We need to talk about standard services!
Playback Link: https://ga.wistia.com/medias/aipuy9f1cs
Tuesday 30 March - 500pm CET
Participants
- Stefan, Stephen, Gunnar, Philippe
- apologies: Johan
Minutes
Virtual AMM preparation
- Stefan: manual translation of VSS to vehicle properties is done, an early implementation of the translator might be available at the time of AMM, possible, the demo will show how the generated code looks like
- Stefan: will report the progress in
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-123
Tuesday 16 March - 500pm CET
Participants
- Stefan, Johan, Stephen, Gunnar, Philippe
Minutes
Virtual AMM preparation
discussion on Tieto delivery of a project update(10') and a VSS-to-Vehicle Properties demo (15'), Stefan agrees to deliver both although the translation VSS↔properties might be manual at the time of the virtual meeting
Translation from VSS to VHAL properties
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-122 - Johan: the team provided a new update of the mapping analysis, please look at the ticket
- Gunnar: it looks fairly complete. A few final tweaks on the translation-type -> Gunnar Andersson TODO
Decided that the current version (as fetched in Dec 2020) is good enough to start implementing the concepts. It's possible to do an updated mapping later on and feed that into implementation. - Gunnar: we need to determine which vehicle properties should influence VSS
Jira cleaning
and sub-tasks thrown to backlogJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-37
and sub-tasks thrown to backlog since the team stopped working on the External Data Server concept and status back to ToDoJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-54
and sub-tasks thrown to backlog for the (same) reason above and status back to ToDoJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-44
thrown to backlogJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-38
Tuesday 9 March - 500pm CET
Participants
- Stefan, Johan, Philippe
- apologies: Stephen Lawrence, Gunnar
Minutes
Translation from VSS to VHAL properties
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-122 - Johan: points the Excel spreadshhet 1.6, the mapping is almost done, there are some mismatches with OBD values, will include the latest comments from Erik Jaegervall
- Stefan: discussion with Johan on the representation of seats, no simple way to represent the seats
VHAL implementation - signal2service interface
Stefan: someip implementation for android is used by another team at Tieto, it works out of the box
TODOs
- TODO Stefan Wysocki Stefan to check with the Tieto management about the preparation and resourcing for a VHAL demo to be shown at the upcoming virtual AMM
Tuesday 2 March - 500pm CET
Participants
- Stefan, Johan, Stephen Lawrence, Gunnar & Philippe
Minutes
Build configuration
- discussion between Gunnar, Stefan and Stephen on the build configuration and testing
Translation from VSS to VHAL properties
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-122 - Johan: the team has now this ticket in their backlog, work is in progress
Vehicle properties implementation
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-120 - updated by Gunnar with the link to repos
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-123 - created to track the alternate implementation of vehicle properties using VHAL and not graphql
TODOs
- TODOs Tieto (i.e. Piotr) to check the publishing status of the signal2service spec in the AUTOSAR set of standards
- TODO Tieto to check the status of the vsomeip implementation on Android (in github)
- Stefan reminds the link to vsomeip implementation on android; https://github.com/GENIVI/vsomeip/blob/master/Android.bp
- Philippe: the question is to determine whether this code is still maintained and could be used for a poc or whether this has been forked
Tuesday 23 February - 500pm CET
Participants
- Stefan, Piotr, Chris, Stephen Lawrence, Gunnar & Philippe
Minutes
Translation from VSS to VHAL properties
- Stephen reminds us about the original doc located at https://source.android.com/devices/automotive/vhal/properties
- Stefan Wysocki reminds us about the code located at https://cs.android.com/android/platform/superproject/+/master:hardware/interfaces/automotive/vehicle/2.0/default/
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-122 - Gunnar: mapping table was updated with type-conversion according to today's discussions
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-120 - Gunnar: For architecture, see last slide of overview slide deck
- Gunnar: Build/modify the example code provided:
- https://cs.android.com/android/platform/superproject/+/master:hardware/interfaces/automotive/vehicle/2.0/default/
- git clone https://android.googlesource.com/platform/hardware/interfaces
- impl/ files are built into a library. A project would likely link against that library.
Next dissemination event
- Next dissemination event will be the GENIVI virtual AMM scheduled on 4-7 May
- Philippe: asks TietoEVRY whether it would be appropriate to show a VHAL connected to AUTOSAR demo, in 2-month time
- discussion on interfacing with AUTOSAR using the signal2service mapping defined by AUTOSAR
- TODO Tieto to check the publishing status of the signal2service spec in the AUTOSAR set of standards
- TODO Gunnar and/or Tieto to check the status of the vsomeip implementation on Android (in github)
Tuesday 16 February - 500pm CET
Participants
- Johan, Stefan, Stephen Lawrence, Gunnar & Philippe
Minutes
Platform Configuration
Gunnar: explains the platform configuration approach, the go infrastructure is set up to provide automatic builds, this is still wip though
discussion on go.cd for Johan's awareness
Translation from VSS to VHAL properties
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-122 Johan: I passed this on the team, it is in their backlog now, Johan will provide feedback hopefully next week
review of VSS to vehicle properties Excel sheet, need to add 2 columns VSS data types and AA data types in the spreadsheet
- Gunnar: I will attach the updated spreadsheet V2 to the Jira ticket
AOB
we will switch to zoom instead of webex for next week call
Tuesday 9 February - 500pm CET
Participants
- Johan, Stefan, Piotr (part-time) Stephen Lawrence, Gunnar & Philippe
Minutes
Configuration manifest
- browsing through aasig_local_manifests repository & discussion
Translation from VSS to VHAL properties
- browsing through this slidedeck and EAP diagram & discussion
created and assigned to JohanJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-122
Tuesday 2 February - 500pm CET
Participants
- Johan, Stefan, Chris, Stephen Lawrence, Gunnar & Philippe
Minutes
Refocusing of project
- Philippe: IMHO we need to refocus the project activities, more OEMs are now working with Google, we need to recognize this and consolidate the knowledge the VHAL team has been building during the past year. I would recommend we revisit the work breakdown structure and the priority of activities
- Stefan: we should now analyze how to provide all vehicle properties through VHAL rather than through graphl, this means to look into the generation of bindings / the translation from VSS to vehicle properties
- review of the existing work breakdown structure (for the External Data Server concept)
- Stefan: I will check the architectural concepts we came up with in the past and propose another architecture to work on
created for trackingJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-120
CVII workshop preparation
- Philippe: the second CVII workshop is scheduled on Thursday 18 February 16:00-20:00 CET, we have included a status report on existing projects in the schedule (see blog)
- Gunnar: 15' will be allocated to the VHAL status report
- Philippe: Stefan Wysocki can you deliver this ? this will likely reuse and update an existing VHAL project presentation
- Stefan: yes, I can
created for trackingJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-121
Tuesday 26 January - 500pm CET
Participants
- Johan, Stefan, Stephen Lawrence, Gunnar & Philippe
Minutes
- Stefan: last week, we just browsed and read the code, Stephen gave also some input w.r.t. lava test code
- Philippe: what can we do with Alex's pull requests
- Stefan: we need to integrate Alex's code with our resolver, we have not also used the utility package provided by Alex yet
- Gunnar: but there is a conflict between our resolver and Alex's code that needs to be resolved
- PR was commented, look at vss-graphql/pull/10#issuecomment-767664084 repository
Tuesday 19 January- 500pm CET
Participants
- Johan, Piotr, Stefan, Stephen Lawrence
- apologies: Gunnar & Philippe (in another call)
Minutes
- look at the code published by Alex last week
created for trackingJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-118
Tuesday 12 January- 500pm CET
Participants
- Chris, Gunnar, Johan, Piotr, Stefan, Stephen Lawrence, Philippe, Alex
Minutes
Lava status
Stephen L and Gunnar provide a short report on the GENIVI Lava-based test farm implementation
Example Android LAVA job that boots Android then uses ADB to first confirm its has booted, takes a screen capture of the UI then transfers it:
https://lava.genivi.org/scheduler/job/1449Example 2 - flashing Android 10 AOSP via fastboot, boot it and confirm ADB is working: https://lava.genivi.org/scheduler/job/1343
Sprint & backlog review
Stefan: there are some left-over tasks in this storyJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-57
can be closedJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-41
can be closedJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-62
can be closedJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-61
we will not change use cases for the next demo, can be closedJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-60
Stefan: Done by using Apollo GraphQL android client library, can be closedJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-46 Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-59 - discussion on approach for implementation (via code generation or machine readable format)
- Alex: imho json approach is better
- Gunnar: it is more flexible
- Stefan: permission needs to be declared in the manifest
- Gunnar: The concept is implemented (aasig_dev_platform/tree/develop/vendor/genivi/modules/VssAuthenticationService repository) but is not controlled by an external file (e.g. a VSS layer file as proposed here) so that would be the next step.
- Alex: will publish today the whole code for the permission control
Tuesday 15 December - 500pm CET
Participants
- Chris, Gunnar, Johan, Piotr, Stefan, Stephen Lawrence, Philippe
Minutes
Conversion of formats
- Discussing, and working on, VehicleProperties↔VSS translation. See working document in Google Docs.
Fosdem
- discussion on abstract, Stefan will work out an abstract and submit it by the end of the week DONE
- abstract text is the following
- title: Vehicle Signals access from IVI systems in generic way
- abstract:
- Accessing the Vehicle Network in a secure way is a challenge that each Automotive vendor and supplier must cope with. Rich collection of modern Operating Systems is approaching the industry and develop a need to have a standard approach to be reused across them. GENIVI Android Automotive Special Interest Group for Vehicle API is aiming is to provide a community voice and solution for generic challenges by example implementation. The presentation is a brief overview of the current progress of the common components that allows the vendors to move the effort needed for implementation to configuration of existing components.
- Agenda
- Android to utilize Vehicle Data Standard to access the Android Signals
- Current architecture
- Project setup (Environment setup references)
- Components overview (repositories, the purpose of each component)
- Access control and “external data server” for properties – outside Android
- Derived activities
- Apollo GraphQL as server – resolvers implementation
- Client implementation using Apollo GraphQL Java Client Library for Android
- VSS to Android properties translation
- Current challenges
- Way to describe the mapping between AOSP properties and VSS leaves – proposal and complexity of the solution
- C++ code generator to translate the properties
- Current challenges
Call schedule
- no VHAL call next week, and the week after, and the 1st week of January
- next VHAL call is scheduled on Tuesday 12 January
Tuesday 8 December - 500pm CET
Participants
- Gunnar, Johan, Piotr, Stefan, Stephen Lawrence, Philippe
- apologies: Chris
Minutes
Fosdem
- GENIVI was suggested to submit a talk (or talks) to the Embedded DevroomTrack (includes Automotive), the link to the CfP is there, the event will be of course virtual
- Gunnar, Stephen, Philippe: attended Fosdem several times, this is the most important event for open source developers worldwide, a good place to get known and to recruit developers
- TODO Stefan to check with Tieto whether a talk could be submitted
- deadline for submitting a talk is 23 December
- discussion on talk content
- there is a consensus that the VHAL demo development platform is a good topic since it is important to talk about code implementation at Fosdem
code implementation
- Stefa: not much done since last week's code publishing
- Gunnar: what is the open question on licensing you mentioned ?
- Stefan: there is still no license file in the github repo
- Stefan: Apache 2.0 is Tieto preferred license (it is AOSP preferred license).
- Gunnar: this is fine
- Stefan: we need to complete and finalize the demo platform for Q1, 2021
content of next version of the demo
- Stefan: we need to show the permission control promised by Alex, this is an important piece of code for the data server, it will allow us to validate the currently used EDS architecture, before digging into other architectures as suggested by Chris
- Gunnar: I agreed we need access control
- Gunnar: we will then have an opportunity to build other variants of the architecture and use a translation of VSS into vehicle properties, the initial work on translation can start now
- Philippe: suggests to have a working session on the translation next week (instead of having an all hands report which can be done with a slide deck distribution)
- all agree this is a good proposal
- Gunnar, Stefan and al. will prepare the working session via the mailing list
Tuesday 1 December - 500pm CET
Participants
- chris, gunnar, johan, piotr (20mn only), stefan (10mn only), stephen lawrence, philippe
Minutes
- stefan: will push the graphql code and the vss authentication
- discussion on aasig_dev_configuration, browsing through the repo android-vehicleplugin-vss-graphql repository
Tuesday 10 November - 500pm CET
Participants
- Alexander Domin, Johan Strand, Stephen Lawrence, Gunnar, Philippe
- apologies: Stefan Wysocki
Security token validation
- Alex: some ideas on my desktop, although not formalized as a set of specifications yet
- the recording of Alex's pitch is here
- some hints on the discussion are given below
- in the web when using graphql, there is a user login name and password to connect to the data
- you need to authorize yourseld on the phone, the session is valid for a certain period of time, if you do things, the session will remain
- the server knows you
- before you can use a graphql application, you need to register, there is a link between the graphql server and your role
- let us switch in the car environment and let us deploy some kind of a server in the car
- what we learned from the web, graphql needs a name and a password
- the app which is installed in the vehicle environment shouf be identified and signed / qualified as coming from the BMW store or the OEM specific store
- the app should be made trusted in the environment
- Johan: I agree with the approach
- Alex: in the web we have roles & permissions stored in the server but not applicable to the vehicle environment
- more on the token: in the web, we have a token enhancement, after we logged on to the server and run through the authentication process, we got a token enhancement
- we can have the same in the vehicle environement
- (not captured...)
- access rights: each and every app should bring permission groups in the manifest file
- let us assume the app is allowed to access 20 atrributes
- let us assume the user driver needs to have more permissions that the user "baby"
- how do we handle this ?
- Johan: I understand the difference between the web and the car
- (not captured...)
- Alex: in the car we have an app where the user authorizes him once and then this app gives rights to all other apps that need it
- discussion continues on the sw architecture
- Gunnar: the key thing for me is that you can include the information that is to be exchanged in the token
- discussion on the token structure
- jira: AASIG-117 - Prepare use cases for the security token validation In Progress is in-progress
Tuesday 3 November - 500pm CET
Participants
- Alexander Domin, Johan Strand, Stefan Wysocki, Guru, Stephen Lawrence, Gunnar, Philippe
...
- Alex: we are using Apollo graphql server which needs an addition for web token management, and other stuff we are working on, I have discussed which contribution we could do with Markus
- BMW has the blue box on the right box (authentication) (look at the EDS architecture diagram)
- BMW has only the EDS implementation, not the Internal Data Server one
- Alex: the permissions are not yet what we need
- discussion on the work to do for the authentication and the access control groups
- Gunnar: we need to do a more formal description of things to be done for the authentication
- Alex: might be able to do some work in the next days, will try out my ideas on an actual implementation, as soon as I have something (next week possibly), I will generate some docs like ppt
- Alex: tooling is not clear for me yet, as soon as we agree on the way to specify things, we will talk about tooling and manifest generation
- discussion on the naming of artefacts
- Alex: we want to have a nodeJS graphql implementation running
- Alex: I can describe the nodeJS and graphql installation and the deployment of json files
- Gunnar: the wiki page for documenting tihs is AASIG: Implementation notes
- /TODO/ Alex to describe the nodeJS and graphql installation in the above wiki page
- Stefan: at Alex, since you have the authentication implementation under way, could you spent some time to describe what you have done so that we can identify the leftovers ?
- Alex: I can explain that, for instance we need a json web token implementation
- /TODO/ Alex & Stefan to clarify what could be the contribution of BMW & Tieto to the authentication mechanism implementation
...