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
Next Meeting - Tuesday 17 December - 5pm CET
Zoom dial-in
Zoom link
meeting ID : 993 7365 2562
password: Vhal!21
local dial-in numbers:
https://zoom.us/ju/499263988
Dial by your location
Meeting ID: 499 263 988
...
France
...
Germany
...
Sweden
...
United Kingdom
...
+1 646 876 9923
+1 669 900 6833
...
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
Minutes
AMM debrief
- Johan: workshops were very good
- Stefan: Chris Simmonds who attended made a good contribution to the discussion
- Philippe: asks whether new work items were identified
- Stefan: the new items are listed at the end of the working session slide deck, there is an interest in digging into the Internal Data Server (IDS) architecture rather than the External Data Server (EDS) we have experimented up to now, with IDS the GraphQL would be exposed through the Android framework
- Stefan: have a couple of questions to ask to the working session participants, e.g. Ford and VW
- Philippe: will send a follow up email to Ford and VW to ask for their feedback on the working session
Backlog review - Work to do
- Gunnar: we need to finalize the building of the platform and the manifest
- Alex: what about the validation of the security token approach ?
- Gunnar: the GENIVI cybersecurity team can help reviewing the desing but will not implement anything
- TODO Alex prepare the use cases for the security token validation for next week (10 November), jira:
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-117
Friday 26 October - 3pm-7pm CET - GENIVI AMM AASIG VHAL working session
GENIVI AMM AASIG VHAL working session:: slide deck and session recording are at GENIVI Virtual Member Meeting October 2020
Tuesday 6 October - 500pm CET
Participants
- Alexander Domin, Johan Strand, Stefan Wysocki, Guru, Stephen Lawrence, Gunnar, Philippe
Minutes
AMM working session preparation
- Philippe: proposes the team to update the work breakdown structure as the other teams did, this will help identifying the discussion topics for the working session
External Data Server Proof-Of-Concept - Work Breakdown Structure wiki page updated online with inputs from Gunnar, Alex and Stefan
- relevant Jira tickets updated online
,Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-47
,Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-52
,Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-51
updated on lineJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-53
- hint for the working session content: please have a look at CCS working session content which was derived also from the work breakdown structure update
Tuesday 22 September - 500pm CET
Participants
- Alexander Domin, Johan Strand, Stefan Wysocki, Stephen Lawrence, Gunnar, Philippe
Minutes
demo implementation status
short discussion on demo repo organization
Alex: I am now recapturing the activities
connection from vss feeder to sqlite is working
Stefan: needs to be reworked to introduce the permission group
Alex: will deliver an update by next Tuesday
should be assigned to PiotrJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-48
Tuesday 15 September - 500pm CET
Participants
- Piotr Krawczyk, Johan Strand, Stefan Wysocki, Stephen Lawrence, Guru, Gunnar, Philippe
Apologies
- Alexander Domin
Minutes
demo implementation status
- Gunnar: openDS still not working on the test platform
- Gunnar: I need to ask Daniel Wilms about the status of the graphql tooling
- still waiting for the permission enforcement implementation
Tuesday 8 September - 500pm CET
Participants
- Maria Schier, Piotr Krawczyk, Johan Strand, Stefan Wysocki, Stephen Lawrence, Guru, Gunnar, Philippe
Apologies
- Alexander Domin
Agenda
- Permission enforcement implementation
- Outcome of call on OpenDS
- Feature content for MS3 demo
Minutes
Permission enforcement implementation
- Alex is back from vacation and will do his contribution
Outcome of call with OpenDS
Gunnar: I have not succeeded to work with opends yet, I tried to build on ubuntu, no show stopper for the timebeing, nothing changed so far, on it
Feature content for MS3
Maria: will Android R11 be used for the demo
Stephen: There is R9 and R10 on R-Car. Android 11 would need to check more from Google agreement perspective.
Gunnar: We will use R10 for the demo
Philippe: invite Bosch to do some implementation tasks, e.g. on the application layer
- Stefan: shows the block diagram in External Data Server Proof-Of-Concept - Work Breakdown Structure
- Philippe: explains what the team has implemented, will implement for MS3 and which tasks are to be assigned (app development)
- Stefan: explained which vehicle properties are available in the demo (look at
)Jira server JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-58 - Maria and his developer will look at it and provide feedback
- Stefan indicates that Tieto has agreed to make their VHAL code available, it will be under MPL 2.0, look at
)Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-116
Tuesday 1 September - 500pm CET
Participants
- Piotr Krawczyk
- Johan Strand
- Stefan Wysocki
- Stephen Lawrence
- Gunnar
- Philippe
Apologies
- Alexander Domin
Feature content for MS3
- the permission enforcement is something worth have on graphql side. Waiting for the status update from Alexander.
- discussion on the feature content for the next milestone demo (MS 3, i.e. the virtual tech summit scheduled on 26-30 October) )
- it would be good to implement the data access from VHAL in the HAL Layer to the Apollo Graphql (look at External Data Server Proof-Of-Concept - Work Breakdown Structure)
- Stefan will look at it and confirm next week whether he can implement it,
createdJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-113 - Gunnar will continue the packaging of the demo
createdJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-114 - Gunnar would like get clarifications about the building of the demo using OpenDS, ad-hoc call scheduled on Wednesday 2 September with Stefan, Johan and Gunnar
Virtual tech summit preparation
- the VHAL session is scheduled on Friday 30 October afternoon, please put a note in your agenda and schedule a timeslot from 15:00 until 19:00 CET
createdJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-116
Next meeting agenda
Permission enforcement implementation
Outcome of call on OpenDS
Feature content for MS3 demo
jira review
Tuesday 18 August - 500pm CET
Participants
- Piotr Krawczyk
- Johan Strand
- Stefan Wysocki
Apologies
- Alexander Domin
- Stephen Lawrence
Stefan reports the status from last weeks to Johan with a highlight of new TODOs ready to be taken.
Piotr will continue his work on sqlite database between vssfeeder and graphql server.
All meeting members agreed, that the permission enforcement is something worth have on graphql side. Waiting for the status update from Alexander.
Tuesday 11 August - 500pm CET
Participants
- Piotr, Stefan, Gunnar
- Alexander is on vacation this week
The completion of the in-vehicle is held up by access-control implementation in GraphQL server – awaiting status update from Alexander.
Gunnar has tried to unpack OpenDS sources from the Windows-executable via wine but it did not work. It requires "installing" Java (in the Windows environment) first, which did not work fully, and at least not so that the executable recognizes it as installed. Have to retry this on a Windows machine probably.
Stefan confirms again that once the "installation" completes, the source code will be on disk and can be extracted to be run in any other Java-capable environment (e.g. Linux).
Tuesday 4 August - 500pm CET
Participants
- Stefan / TietoEVRY
- ...Piotr is on vacation
- ...Alexander?
Minutes
- Sync up with Stefan. Will have more time next week for progress.
- Discussed how to compile OpenDS from scratch. The web site only provides version 5.0 only as a downloadable Windows executable!
and no normal source code repository.
- Stefan: There is an eclipse project file, but no command-line build project like maven.
- Stefan explained how he compiled the Java sources manually.
- Gunnar: OK I will try to unpack the sources from the .exe using WINE
Tuesday 21 July - 500pm CET
Participants
- Philippe
- apologies: Stefan, Gunnar (vacation)
Agenda
- demo status provided by Stefan offline (many thanks, kudos)
- AOB
Minutes
Stefan achieved the following activities
- Described the concept of handling permission groups in
and reassigned to AlexanderJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-38
- Reduced GraphQL schema to reflect supported values from OpenDS
- Authentication service that generates token containing granted permissions + App using GraphQL plugin to retrieve the values from server (Fuel properties usecase):
- TODOs from the code that can be taken:
- ExampleAppJava/src/main/java/org/genivi/vss/authenticationservice/MainActivity.java43: // TODO Move this connection boilerplate to VSS-SDK since this code will be shared across the clients
- ExampleAppJava/src/main/java/org/genivi/vss/authenticationservice/MainActivity.java69: .serverUrl("http://192.168.56.101:4000/") // TODO make it configurable
- ExampleAppJava/src/main/java/org/genivi/vss/authenticationservice/MainActivity.java84: // TODO Pass the token to the query
- ExampleAppJava/src/main/java/org/genivi/vss/authenticationservice/MainActivity.java88: // TODO Do sanity check of the response and its content
- service/src/main/java/org/genivi/vss/authenticationservice/IAuthenticationServiceImpl.java:41: // TODO decide when handle this exception
- service/src/main/java/org/genivi/vss/authenticationservice/IAuthenticationServiceImpl.java:44: // TODO Make the key shared between the server and client or change the algo to asymmetric
- service/src/main/java/org/genivi/vss/authenticationservice/IAuthenticationServiceImpl.java:61: // TODO Filter out the non-genivi-vss permissions
- vss-sdk-lib/src/main/java/org/genivi/vss/authenticationservice/VSS.java:12: // TODO Make it autogenerated from VSS
- vss-sdk-lib/src/main/java/org/genivi/vss/authenticationservice/VSS.java:17: // TODO Make Manager class to hide this intent there (similar approach to other services running in the framework) see TODO in client implementation
- Full setup has been recorded and is attached to this email and shows the following steps:
- Start of Apollo Graphql server with vss feeder, feeding the values from OpenDS
- Start Example application that is able to connect to Authentication Service and retrieve the token with permissions bundled
- Example application sends the query for retrieving Fuel data (capacity + current level).
- Indications that the values are the same as on server side
- JSON Web Token content
- Additionally, I have updated some of the Jira tickets. My actions (since 6 July) can be tracked via activity stream: https://at.projects.genivi.org/jira/secure/ViewProfile.jspa?name=Stefan.Wysocki
- "I kindly ask participants for reviewing the code and contributing by fixing new TODOs."
- Milestone 2 demo video is available there
Tuesday 6 July - 500pm CET
Participants
- Alex, Piotr, Stefan, Gunnar, Stephen , Johan, Philippe
Agenda
- Jira review
- AOB
Minutes
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-38 - Stefan will document what is implemented in the proof-of-concept for milestone 2 (done with sequence diagrams added)
- then other inputs from W3C, BMW, etc will be added
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-55 - discussion on some code generation
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-56 - discussion on the content of the java web token JWTK
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-47 - Gunnar will contact Daniel Wilms about the VSS and tooling around, ticket assigned to Gunnar
- demo readiness
- need to review Stefan's pull request
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-57 - Alex & Stefan will schedule a call on application layer on Thu 9 at 9:30am CET
- agenda: token generation
- invitees: Piotr, Stefan, Alex, Gunnar
Tuesday 23 June - 500pm CET
Participants
- Stefan, Piotr, Philippe
- apologies: Alex, Johan, Gunnar
Agenda
- outcome of discussion with Alex last Thursday & progress report
- AOB
Minutes
outcome of discussion with Alex last Thursday & progress report
- Stefan: this was rather a free discussion, we made a walkthrough oF the code Alex developed a while ago
- Pior: since last week, we have an implementation based on SQL up &running
- Jira tickets were updated
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key CCS-148 - Piotr created two PRs
- vss-feeder: https://github.com/GENIVI/vss-feeder/pull/2
- vss-server: https://github.com/GENIVI/vss-graphql/pull/5
- Piotr created two PRs
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-55 - Pull request under review: aasig_dev_platform/pull/3 repository
- discussion on involving Johan into the review of pull requests, this would be very helpful
- Piot wiil start developing a small application this week, will look at the app skeleton prepared by Stefan and which is available in the authentication repo
Tuesday 16 June - 500pm CET
Participants
- Stefan, Piotr, Johan, Alex, Andryii, Stephen, Gunnar, Philippe
Agenda
- allocation of work
- AOB
Minutes
allocation of work
- Philippe: reminds the need to assign the work at application layer level in order to get a complete implementation "from top to bottom" and calls for volunteers
- Alex: brings in information about the development guidelines fo Android app using Apollo graphql
Alex: for application developpent there is a helper in Apollo to work with graphgl
graphql schemas are exposed via http
the connection between the graphql server and the app can be easily developed
the rest can be done in Android studio
Stefan: there is already a skeleton in the genivi github repo, explains how he added to the skeleton the "hooks" to authentication services and permission management
Stefan: will introduce one dummy permission for poc purpose and then based on that, the real properties will be created
Johan: my company has no resources available
Piotr: I can jump in and crzate the next iteration of the authentication skeleton
Stefan: will also be able to do some work
Alex: wht I acan offer is some code I have developed sometime ago, we could have a walktrough session to review the code
decision meeting with Stefan/Piotr/Alex/Johan scheduled on Thursday 18 June 9-11am CET
discussion on github repo organization between Stefan and Gunnar
TODO Stefan Wysocki to create a PR to move his own stuff from his private branch into the master branch
discussion on the data types to be exposed by the grapql server
Gunnar agrees with Alex proposal to have graphql expose types that are close to VSS types
if we do this, Alex will need to do something on the graphql server
discussion on type casting on 64-bit platform
Gunnar: we have obviously a type mapping problem, we need to express it more formailly
Alex: will start a short doc on type mapping between graphql and VSS in the wiki
- TODO Alex to initiate a short doc on type mapping between graphql and VSS in the wiki
createdJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-109
- TODO Alex to initiate a short doc on type mapping between graphql and VSS in the wiki
Jira update
- Philippe: asks participants to update the Jira tickets (summary, description, status) after the upcoming Thursday sync call
- Gunnar: indicates he started enriching the EDS PoC wiki page External Data Server Proof-Of-Concept - Work Breakdown Structure
- it would good that participants enrich also this wiki page
Tuesday 9 June - 500pm CET
Participants
- Stefan, Piotr, Gunnar, Philippe
- apologies: Alex, Stephen
Agenda
- sprint review
- AOB
Minutes
sprint review
- Piotr will put some effort this week, need to sync with SteFan on VHAL implementation tasks
- Stefan: updated the tickets
&Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-43 Jira server JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key CCS-148 - Gunnar: my recommendation is to use use the full path name to access the signal
- Stefan: will add a comment to AASIG-43 and close after I have done some benchmark
in-progressJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-55 - discussion for feature content for Milestone 2 (mid-July)
- Stefan: one additional feature is to connect VSS feeder to talk to someip, look at
, ticket is to be assignedJira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-42 - review of the EDS PoC architecture block-diagram at ExternalDataServerPoC-lookatslide#7
- TODO Gunnar to annotate the block-diagram with the status of components (like for instance Done
, in-progress
, todo
) and add the picture to the WBS wiki page
- Stefan: we need to prioritarize the app development
- Stefan/Piotr are capable of developing the app but it would be good that other developers get involved
- Stefan: another next low hanging fruit is the VHAL implementation to retrieve the vehicle properties using a GraphQL query (see block-diagram), this can be done after implementing the data access in the app because it uses the same kind of query
- TODO Stefan to create a Jira ticket for the VHAL implementation
- discussion on the vehicle data generation, focus on
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key CCS-149 - Gunnar has started some analysis on the data generation but has not finalized an approach yet,
- Stefan: one additional feature is to connect VSS feeder to talk to someip, look at
Tuesday 2 June - 500pm CET
Participants
- Alex, Stefan, Piotr, Johan, Gunnar, Stephen, Philippe
- apologies: JLR folks
Agenda
- sync with CCS project
- AOB
Minutes
sync with CCS project
- outcome of the sync meeting with Ulf from the CCS project
- Stephan: we could change the VSS database for SQLite and request for the properties on demand
- Gunnar: there are 3 cases that can be considered
Do we consider relying not only on cached/stored/updated values in database updated periodically by vss feeder or foresee the need of “on demand” requesting the fresh data ? These 3 ways of accesses are not considered as VSS leaves definition, but might be specified using VSS Layers. Then VSS feeder/Data Server (discussion on the role) can act accordingly (use cached or request for fresh value).
- TODO Gunnar to write prepare a block diagram describing the various cases
- Alex :agrees with the 3 cases
- Alex: do we really need a database which might be seen as an overkill for me ? some hash-map in memory might be enough
- Alex: when the data are not changed at all, what do we do ?
- Gunnar: do we need a database ? no, but there is an implementation that exists
- Alex: are the feeder and the grapql in the same process ?
- Gunnar: I think there are separate processes and we need IPC soemwhere unless we put everything in one process
- Stefan: but even if we use one processor we need some thread sync.
- Piotr: IMHO using hashmap and sync implementation would result in the same complerxity than using SQLite
- Gunnar agreed
- Gunnar: debouncing ?
- Gunnar: there might be some higher performance database, but basically we need only a key value store
VSS to Franca
- VSS to Franca tool was updated by Gunnar to implement the someip connection
- Gunnar will add this to the VSS tool repo
Jira tracking
- Philippe: initiated a Jira tracker for the proof-of-concet implementation, look at
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-36
Tuesday 19 May - 500pm CET
Participants
- Stefan, Johan, Andrii, Gunnar, Stephen, Philippe
- apologies: JLR folks
Agenda
- virtual summit outcome
- backlog review
- AOB
Minutes
virtual summit outcome
- Stefan, Johan: not a workshop but rather a walktrough
backlog review
- Stefan - Alex: plan to implement the permissions model, next step is using the same data with graphql with the permissions model added
- question: do we reuse what BMW is using or do we implement something in parallel ?
- reusing the database from CCS to be more solid
- Gunnar: it depends on what we want to store, depends on the use cases, simple key-value pair storing might be enough
- Gunnar: for next milestone we will keep the values in memory
- Gunnar: we do not need a very advanced data base
- Philippe: how to identify a useful use case ?
- Stefan: restrict the driver from accessing a given speed limit, zooming some control , average data, minimum & maximum value
- Gunnar: displays the current values and some client side statistics, no need for a database
Gathered Todo's:
- create a jira ticket for app development
Jira server JIRA serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key AASIG-62 - (Stefan ?) send an email to Alex to ask about the implementation of permissions model and graph resolver upgrade
Wednesday 13 May - 3pm-6pm CET - Virtual Technical Summit Workshop
Minutes
- minutes are here
Tuesday 5 May - 500pm CET
Participants
- Alex, Johan, Piotr, Stefan, Sachin, Gunnar, Philippe
- apologies: JLR folks
Agenda
- VSS feeder update: connecting the graphql schema
- virtual meeting status report & workshop preparation
- AOB
Minutes
VSS feeder update: connecting the graphql schema
- Stefan: was able to put the graphql at work , I have a problem with the docker setup and the simulator that runs outside the VM
- demo can be shown as first milestone, i.e. at the virtual tech summit workshop
- Stefan will contact gunnar after
- Stefan: shows the set up of this demo and explains the problem he has with the nxtworking between the VM and the simulator that runs on windows
- Philippe: why don't you the GVS (GENIVI Vehicle Simulator) that runs on linux ?
- Stefan: we should use at a later stage a "better" database like SQL for instance
- Gunnar: can you all take into account the packaging, like we did in other projects where we use a docker setup ?
- Alex: I am fine with the docker packaging
- Gunnar: next step would be to integrate this into a dev kit and running an app on Android
virtual technical meeting - workshop preparation
- Alex: I had a call with Stefan yesterday, I do not know how deep we need to address the topics, let us do a brief overwiew of the topics
- topic #1 - VHAL implementation based on the graphQL implementation
- Google requires OEMs to implement properties in the Google way
- we want to deliver these properties outside the graphql server
- I hope to have JLR working on the proof-of-concept implementation with us, then we need to identify which workpackages need to be implemented
- Philippe: JLR people are shutdown for the month of May and will not show up again until next month, it is a good idea to prepare an updated work breakdown structure
- topic #2 - permission group
- Alex: this is about the concept introduced by Gunnar about the VSS layer concept; I would like to have a discussion on which concept we will follow in the future
- Alex: in our architecture we have different players, player 1 is the app, player 2 is the authentication service that generates the token, player 3 is the dataserver
- Alex: I intend to present my understanding of what I have learned about permission management
- topic #3 - graphql schema
- Alex: I generated the graphql scheima for the GENIVI VSS standard tree (on github)
- there is a private area for each and every OEM has his own branch
- do we need an additional layer to be integrated into the graphql schema ? or do we create empty leaves in our schema ?
- Gunnar: we need both actually
- Alex: do we talk about the generation process at the workshop ?
- Gunnar: I would like to invite you, Alex to partiicpate to W3C call on VSS call this evening
Tuesday 21 April - 500pm CET
Participants
- Johan (Melco), Andrii (EPAM), Piotr (TietoEVRY), Stefan (TietoEVRY), Alexander (BMW), Gunnar (GENIVI), Philippe (GENIVI)
- guests: Blake Lyman, Richard Isley, Robert Goldie (Jaguar Land Rover) (JLR)
- apologies: Sachin (Mercedes Benz Research)
Agenda
- roundtable
- introduction to External Data Server proof-of-concept
- overview of architectural design options for the Vehicle Data Interface
- VSS feeder proof-of-concept demo
- graphql and nodeJS installation, graphql schema example
- virtual tech summit : AASIG VHAL workshop preparation
- AOB
Minutes
roundtable
- quick introduction of each participants for JLR guests
introduction to External Data Server proof-of-concept
- Gunnar: shows the External Data Server Proof-Of-Concept - Work Breakdown Structure and explains the architectural design approach the team is investigating with the proof-of-concept implementation
overview of architectural design options for the Vehicle Data Interface
- (introduction added offline) Philippe: the outcome of the February 4-5 F2F meeting is described in this slide deck
- the team identified 4 options for the Vehicle Data Interface design (and 4 proof-of-concepts that could be implemented for experimenting and validating the design options)
- the team has set up priorities for the proof-of-concepts implementation, 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 implementing first
- Gunnar shows the following slide deck Vehicle HAL Architectural Design Concepts and explains the design options
- External Data Server option corresponds to slide #13 of Vehicle HAL Architectural Design Concepts (current team focus as of today)
- Internal Data Server option is only a variant of the previous with the Data Server inside the Framework
- SomeIP stack inside the Framework option corresponds to slide #14 of Vehicle HAL Architectural Design Concepts (note there is a port of vsomeip component to Android currently going on in GENIVI github)
- Google VHAL + OEM Extensions inside option corresponds to slide #12 of Vehicle HAL Architectural Design Concepts
VSS feeder proof-of-concept demo
- Philippe: browses quickly through the slidedeck presented by Stefan two weeks ago
- Stefan: will resume this week the work suspended because of the Easter break
graphql and nodeJS installation, graphql schema example
- Alex: will finalize the upload of the graphql schema example and instructions for installing graphql and nodeJS this week after last week's Easter break
virtual tech summit : AASIG VHAL workshop preparation
- Philippe: we need to start gathering the items for the agenda of the AASIG VHAL workshop and the AASIG VHAL project report at the upcoming virtual technical summit
- Philippe: the abstract of the workshop is the following (published on the virtual tech summit registration page)
"The AASIG VHAL / Vehicle Data APIs project has detailed a delivery roadmap for its initial deliverables. During a successful face-to-face meeting hosted at the beginning of February by BMW in Munich, the project team identified four proofs-of-concept (coding projects) corresponding to the various software architectural options that have been debated since last November’s GENIVI Technical Summit, held in Troy, Michigan. The first proof-of-concept implementation is the External Data Server (EDS) proof-of-concept that investigates how to extend Android access to vehicle data. The rationale for this work is that the number of vehicle properties currently defined in standard Android is very limited as compared to the thousands of vehicle-related signals OEMs are considering for their connected vehicles. Although the project could propose to expand the standard vehicle property list in Android, the integration of Android into a complex electrical and connected vehicle architecture suggests a bigger picture to consider. Standard data access methods should be applied in the entire vehicle and in cloud-connected services. This EDS proof-of-concept intends to validate the concept of a data server accessing the vehicle dataset as described by VSS (Vehicle Signal Specification standard), which is used also in W3C Automotive Group, and enabling authenticated Android apps to access the vehicle data through a web socket protocol. The actual values of the vehicle signals will be queried/updated thanks to a VSS feeder that will connect to the rest of the vehicle using, for example, Some/IP.
The AASIG VHAL / Vehicle Data APIs project team will present a status report of the EDS proof-of-concept implementation and explain the design choices made. The following next steps will be then comprehensively debated:
- External Data Server proof-of-concept versioning w.r.t. roadmap milestones
- Early assessment of implementation TRL (Technical Readiness Level)
- Ensure project participants have opened, or are planning, a discussion to achieve synchronization of activities with Google's Android team
- Other proof-of-concepts implementation"
- Philippe: will contact Alex offline for the preparation of the sessions
Tuesday 7 April - 500pm CET
Participants
- Johan, Sachin, Magnus (JLR), Andrii, Piotr, Stefan, Alexander, Gunnar, Philippe, Stephen L
Agenda
- VSS feeder proof-of-concept demo (Stefan)
- graphql and nodeJS installation (Alex)
- graphql schema example (Alex)
- EDS PoC planning (skipped)
- AOB
- virtual tech summit VHAL workshop moderation
Minutes
VSS feeder proof-of-concept demo
- Stefan: shows this slidedeck presenting the analysis and experimentation he made on the VSS feeder of the EDS part of the proof-concept
- first topic is about using opends as the vehicle simulator to feed the vss feeder
- code written in nodejs
- use a naive database written in json
- Gunnar: the transformation of signals into VSS is done manually in your example, we could make a generic mapping on how to translate from one signal to the VSS tree
- Stefan: agreed
- second topic is about using the genivi-vehicle-simulator (GVS) - as the vehicle simulator to feed the vss feeder
- Stefan: provides a short overview of the simulator
- Gunnar: did you have trouble compiling the vehicle simulator code
- Stefan: none
- Philippe: asks question to Magnus about the simulation of EV vehicle signals in GVS
- Magnus: will look at how to implement a small model for simulating EV signals in GVS
- Philippe: explains as a side comment the reason why the GENIVI CCS project is introducing EV signals in the VSS tree: first this is to a state-of-the-art demo showing connected EV data rather connected ICE vehicle data and second this is also an attempt to trigger OEMs on providing inputs on EV data
- Johan: we are using a different version of opends in W3C, we made some small changes
graphql schema example
- Alex: shows the graphql schema he is using
- Alex: reports the issues he had with some VSS descriptions
- Magnus: we are currently looking at Daniel Wilms' work on include statement in yaml
- /TODO/ Alex to submit the issues he encountered in the github VSS tracker
- Magnus: we need to work on some sort of VSS validator to check the syntax
- Alex and Gunnar will take offline the publishing of the example on the GENIVI github
graphql and nodeJS installation
- Alex: I have a 1.3 Gbyte image for graphql and nodeJS installation ready
- Gunnar: can you also provide the docker instructions for building the image ?
- Alex: yes, Alex and Gunnar will take offline the publishing of these items on the GENIVI github
AOB - virtual tech summit - VHAL workshop moderation
- Philippe: the AASIG VHAL workshop is scheduled on Wednesday 13 May at 3 to 6pm CET (best US Pacific friendly time we can propose)
- Philippe: asks Alex and Sachin whether they can be moderators, the workshop agenda preparation will be shared with the team in the upcoming weeks until the tech summit
- Alex: yes, possible for me
- Sachin: I will check whether I can participate, will provide feedback in a few days
Friday 27 March March - 200pm CET
Participants
- Alex, Stefan, Philippe
Agenda
- authentication service implementation (work sharing between BMW & TietoEVRY)
- AOB
Minutes
1. BMW has implemented the Service for Authentication:
- Service written in Kotlin - conclusion: Android buildsystem does not support Kotlin yet - needs to be rewritten if integrated in platform
- IPC between Service - App done manually - conclusion: can be rewritten to hide boilerplate via AIDL generators
- JWT kept internally as string with payload: uid + permissions as a List<String>
- Secretkey to sign JWT shared manually (i.e. no single point of encrypted storage) - Action to be put in the backlog: "Decide and configure storage of secret between Server and Clients")
- Example permissions exposed in AndroidManifest
2. BWM has implemented the Client application to use Authentication Service:
- JWT retrieved as bundle - can be reworked for AIDL object
- Connection to GraphQL not analyzed, but not that relevant for the scope of Authentication Service
3. The code is not shared yet because of process of licensing and OSS check by BMW
4. We had a little session about finding similarities/improvements/possible reusage of https://github.com/GENIVI/aasig_dev_platform/tree/develop/vendor/genivi/modules/vssandroidservice
5. Based on conclusions from point 4, TietoEVRY proposed - since kotlin implementation needs to be rewritten eventually - to provide Java implementation containing:
- Proper buildsystem support: Android.bp for future platform integration + gradle for development
- AIDL definition that is more developer friendly and can be easily kept as "compiled" .jar library for 3rd party development of Applications
- Functionality of Service will be the same as BWM kotlin implementation
- MPL 2.0 license
Tuesday 24 March - 500pm CET
Participants
- Alex, Stefan, Piotr, Johan, Nadim, Bartosz Cichosz, Stephen, Philippe
Agenda
- authentication implementation (work sharing between BMW & TietoEVRY)
- graphql and nodeJS installation
- staffing the EDS PoC (again !)
- AOB
Minutes
authentication implementation
- Alex: I was preempted by internal projects again, although I did some work on graphql
Stefan: we need to schedule a meeting
Alex: we can have a meeting on Thursday at 10-11:30am CET
Stefan: will send an invitation DONE
graphql and nodeJS installation
- Alex: I need to package what I have done in a container in order to make my work easy to reuse
- Stefan: can you give us a snapshot of what you have done ?
- Alex: yes, Alex shows the schema representing the vehicle data he is using for the testing of graphql together with some queries
- Philippe: it would be good that team participants have a look at the Apollo GraphQL documentation to get more familiar with the approach: https://www.apollographql.com/
- /TODO/ all participants to look at the Apollo GraphQL documentation: https://www.apollographql.com/
Next week's All Hands call preparation
- Philippe: I may have to escalate the situation and report that AASIG VHAL team have difficulties to staff the poc
- (added offline): as in all collaborative projects, it would be good that each participant consider spending a little bit more time than attending the calls and reading the minutes, otherwise everyone gets the impression the work is stuck
- Stefan: point 13 of the WBS (Define GraphQL schema - what does it look like?) was actually done by Alex as he showed the schema today
- Alex: agreed, I have the schema but something is still missing
- Stefan: we need to have something to get started on the other work items
- Stefan: we need also to agree on the data format
- discussion follows on how to bootstrap the work
- Stefan: will work out some prototype code and show it at the next VHAL call
- Philippe: next week's call will be the AASIG All-Hands call on 31 March at 17:00 CET (watch out: there is a time change scheduled on 28-29 March in Europe)
- Philippe: next VHAL call will be scheduled on 7 April at 17:00 CET
Tuesday 17 March - 500pm CET
Participants
- Alex, Sachin, Stefan, Piotr, Johan, Stephen, Gunnar, Philippe
Agenda
- authentication implementation (work sharing between BMW & TietoEVRY)
- graphql and nodeJS installation
- staffing the EDS PoC (again !)
- AOB
Minutes
authentication implementation
- Stefan and Alex will clarify their mutual contribution to this topic this week
graphql and nodeJS installation
- Alex: this is on my todo list for this week
staffing the EDS PoC (again !)
- Sachin: the people I contacted at Daimler acknowledged my demand for implementtersn, no positive feedback yet,, will continue to ping them
- then the participants resume the review of the work breakdown and discuss the candidate technologies to implement the components
External Data Server Proof-Of-Concept - Work Breakdown Structure updated on line by Gunnar, thanks !
- here is below some elements captured during this discussion
work item #7 - agree on PoC use cases for the implementation
Stefan: during the F2F meeting, we said we will use the battery voltage for an EV and also the tyre pressure and air conditioning information
All: an EV application is the right app to develop for a demo
we will show the battery status and battery consumption during a drive
- Stefan: Tieto evluated the GENIVI vehicle simulator available in github, this simulator can provide some of the data we needed like the property of speed during a drive
- Johan: opends used in W3C is also a candidate, link: https://opends.dfki.de/, configuration files are written in xml,
- Gunnar: one of these simulators would be the data provider box in the PoC block-diagram for the use case showing the vehicle speed or other vehicle signals like the tyre pressure and a simple simulation covering the EV signals (alternate data signal feeder) would be used for the demo use case showing the battery status and battery consumption
- Tieto is analysing the simulation aspects for the PoC
- work item #9 - Select and implement feeder input API → how feeder writes data into the "shared database"
Alex: do we take a database or in-memory hash values ?
Gunnar: the feeder is writing the values into the database, this work item is just the interface to the database, whatherver is coming from outside needs to be stored internally
work item #10 - VSS data server component - supporting technos
Alex: I will add a description on how to install graphql on ubuntu but what about using a virtual box where everything is installed ?
Gunnar: it would be ideal to package it that way
Stefan: we said we would run it on docker, this is another possible solution
Philippe: reminds the demo execution architecture, we will one laptop running the EDS on Linux and for the IVI unit either one laptop running the Android simulator or a target board like R-Car or NXP
discussion on the selection of docker vs virtual box
*decision* docher is the environment we will use
graphql and nodejs will run on docker
work item #11 - Implement the connection between the access protocol (GraphQL) and the fetching/writing of data into the database
discusison on VSS representation and graphql schema
Alex: I have something already and can possibly provide it although it needs some refactoring, I need to check with my management
Alex:I can show what I have done in the next call
work item #14
this is the graphql query, it corresponds to the implementation of the resolver function in graphql
work item #15
this work is included in workitem 14 but wiriting, a writing function in graphql is called a mutation function
- other work items
- discussion not captured, look at the WBS wiki page
- discussion on whether we add a column in the WBS table to capture the technologies used before capturing the volunteers' names
- decision: no change in the table for the time being
- /TODO/ all participants to review the work items and decide which one(s) they would take over
- work items descriptions are in the following wiki page External Data Server Proof-Of-Concept - Work Breakdown Structure
Tuesday 10 March - 500pm CET
Participants
- Roman (Harman, just observer), Andrii, Stefan, Piotr, Johan, Gunnar, Philippe
Agenda
- authentication implementation
- graphql and nodeJS installation
- call for volunteers
- AOB
- AMM preparation
Minutes
authentication implementation
- Stefan: was too busy to sync on work sharing between BMW & TietoEVRY with Alex,on my todo list for this week
graphql and nodeJS installation
- skipped
call for volunteers
- Philippe: reminds that the team priority should be now to volunteer for taking over some tasks on the EDS PoC work breakdown structure (link to the relevant wiki page is on the top)
AMM preparation
- Philippe: we do not whether the Spring AMM will be physical or virtual; decision will be made soon by the GENIVI board of directors
- Philippe: however we are planning actively the content of the sessions; there will 6 sets of sessions
- looking forward
- AASIG projects on VHAL & Audio HAL
- Cloud & Connected Services projects on Vehicle Data Model and Vehicle2Cloud Communication Infrastructure
- Cybersecurity
- In-vehicle payment
- Connected Vehicle Software Development
Adjourned: 5:20pm CET
Tuesday 3 March - 500pm CET
Participants
- Alexander, Sachin, Andrii, Stefan, Piotr, Johan, Stephen, Gunnar, Philippe
Agenda
- project plan update - filling workitem description and definition of done
- proof-of-concept implementation resourcing
- AOB
Minutes
proof-of-concept implementation resourcing
- Stephen: can provide support for the R-Car target board and Lava test farm
- Gunnar: since we intend to use graphql technology for the VSS data server component, this is off-the-shelf
- Sachin: it is difficult to get support from internal teams, I need to involve open source people at Daimler, I need two more weeks before providing feedback
- Stefan: presents TietoEVRY proposed contribution
- Stefan: we will use the Android emulator and AOSP 10.0 for this development
- Gunnar: FYI Stefan's code was merged in the development branch
- pull request: aasig_dev_platform/pull/1 repository
- Stefan: this work was mostly related to a former approach than the External Data Server (EDS)
- Alex joins
Authentication
- 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
VSS feeder
- Alex: the scope of work depends on how much simulation we want
- discussion on how to implement the VSS data base in a limited manner for the purpose of demonstrating the concept
- Gunnar: for settting the values, would you suggest to use nodeJS code first ?
- Alex; yes, later we will use someip and so on
- Review of other work items for the VSS feeder
- todo finalize permissions layer concept (independent work item)
- Gunnar: we target a simpler mode of permissions, not a high priority
- todo create a layer concept for the Franca to VSS leaf mapping (model transformation)
- not a high priority
- todo check signal to service translation in Adaptive Autosar
- not a high priortiy
- todo agree on PoC use cases for the implementation
- Alex: this is important for the purpose of concept demonstration,
- Philippe: proposes to schedule this work item for next Sprint starting early April
- todo finalize permissions layer concept (independent work item)
Tuesday 18 February - 5:30pm CET
Participants
- 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, Philippe (GENIVI)
- apologies: Sachin (Mercedes-Benz)
Agenda
- Roundtable
- Recap on PoC architectural design
- Call for participation
- AOB
Minutes
Recap on PoC architectural design
- 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 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 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 updated version of Vehicle HAL Architectural Design Concepts presenting the various architectural design options
Call for participation to PoC activities
- 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
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
Tuesday 11 February - 5pm CET
Participants
- Andrii (EPAM), Piotr, Stefan, Viet-Ahn (Tieto), Johan (melco), Suhasini (Analog Devices), Richard (Harman), Stephen (Renesas), Gunnar, Philippe
- apologies: Sachin, Alex
Agenda
- Overview of last week's F2F outcome
- Call for participation
- AOB
Minutes
Overview of last week's F2F outcome
- Philippe presents the outcome of the meeting using this slide deck
- Meeting was productive and the team had a very good collaborative spirit
- we were able to pass the milestone from the brainstorming stage to a proof-of-concept development stage
- Gunnar delivers a short description of the 2 Audio HAL proof-of-concepts identified in the meeting (for information for this call participants)
- Philippe presents the 4 Vehicle HAL pocs identified in the meeting
- Gunnar delivers a description of the External Data Server concept architectural design
- Philippe presents also the roadmap for the poc (note that the tech brief roadmap will be aligned to the same)
- Philippe introduces the work breakdown structure for this poc. Work items will be introduced in Jira once a description and a definition of done is available for each of them.
- Philippe presents also the intended execution platform for the poc
- Minutes of the F2F meeting are here
- Philippe asks participants for their feedback and comments in the wiki
Call for participation
- Philippe calls for participation in the work items identified for the pocs and also for contributions to the tech briefs.
- Expectation is to have feedback on AASIG participants commitment no later than the end of the month in order to start the poc asap and meet the first milestone of GENIVI AMM on 12 May.
Vehicle HAL call schedule
- Philippe proposes to have a weekly period for the Vehicle HAL call starting today
- Next call will be scheduled on Tuesday 18 February at 5pm CET
Vehicle HAL F2F Meeting 4-5 February
Tuesday 21 January - 5pm CET
Participants
- Andrey, Johan, Markku, Pontus Fuchs, Stefan K, Stefan W, Piotr, Stephen L, Patrick, Guru, Alexander, Gunnar, Philippe
- apologies: Sachin
Agenda
- VSS Layers concept vs. access control groups (Gunnar's presentation)
- F2F agenda review and preparation organization
Minutes
VSS Layers concept
- Gunnar: shows the slide deck introducing the VSS layers concept
- the concept was already presented to the GENIVI CCS project team and is being introduced on the W3C mailing list, positive feedback received
Alex: asked a question about the granularity of the access to the data, discussion on the relationship with VSS layers and access groups
Piotr: there is another method to access the data called "content provider", it would be good to check the access control with this approach as well
- the concept will be discussed further at the upcoming F2F
F2F agenda review and preparation organization
- agenda updated on line, look here
Tuesday 14 January - 5pm CET
Participants
- Sachin, Stefan, Markku, Marcin, Gunnar, Johan, Alexander, Stephen L, Philippe
- apologies: Guru
Agenda
- F2F meeting organization - logistics
- F2F agenda topics - preparation readiness
Minutes
F2F meeting organization - logistics
- Alexander: added the address of the BMW office where the meeting will be hosted ("the 4-cylinder building" near the Olympic park) and the list of recommended hotels to the wiki, look here
- review of the participation list
- who is interested in the Audio HAL in addition to the Vehicle HAL ?
- Sachin: could spend half-a-day on Day 2 on the audio HAL
- Piotr: interested in both topics
- Patrick (Mobis) interested in both topics, will join remotely
- Nassim (Mobis) interested in Audio HAL, will attend physically
- Markku
- Andrey: Philippe will reach him out to check he can join remotely
- Philippe: will check the participation of the Audio HAL team members this week
- who is interested in the Audio HAL in addition to the Vehicle HAL ?
F2F agenda topics - preparation readiness
- review of TODOs from agenda draft (there) put together during last call
- TODOs were on the security design
- Android permission model
- Stefan has prepared a slide deck on connecting VSS and Android permissions model
- External service approach
- /TODO/ Alexander will contact Giovanni about the Adaptive Autosar Identify and Access Management model
- The VSS Layers concept could be used to put signals into access control groups
- Gunnar said that some basic ideas are in a presentation he made to the CCS project
- /TODO/ Gunnar deliver this presentation at the next call Vehicle HAL call (on Tuesday 21 January)
- Android permission model
Android permission model
- Stefan shows this slidedeck, sample code is there (not uploaded yet)
Alex: what is the granularity of the properties ? one application can access to 5 leaves (of the VSS tree) and another to 20 leaves of the VSS tree, how to hande it ?
Stefan; this is possible
Gunnar: who owns the signing key ?
- Stefan: the OEM owns it
- Alex: very good presentation, thanks
Next call
- Philippe: proposes to have a Vehicle HAL call next Tuesday at 5pm CET (because Tuesday 28 January slot will be occupied by the AASIG All Hands call)
- all agreed
Tuesday 17 December - 5pm CET
Participants
- Jimhyuk, Patrick, Pontus, Stefan, Piotr, Gunnar, Guru, Johan, Alexander Stephen L, Philippe
- apologies: Sachin, Pete
Agenda
- Next events: calls and F2F meeting organization - date planning - look here
- F2F agenda: gathering of topics
Minutes
Next events
- F2F meeting organization - date planning - look here
- decision F2F will happen on 4-5 February 2020, location: BMW, Munich, Germany
- for those who have not filled their participation info yet, please fill the table
- next calls: 14 January and 28 January 2020 at 5pm CET
F2F agenda
- list of topics and assignment of preparation work is provided there
Find your local number: https://zoom.us/u/aCAyOAcT6
Agenda (proposal)
Agenda items (to be prioritized at the beginning of the call)
- Android Compatibility Definition Document
- Software architectural task force : Vehicle Data architecture for Android
- F2F meeting organization - date planning - look here
- Backlog
- Comparison of how vehicle properties are managed by Android 9 and 10 (Q) - further inputs
- 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
- AOB
Tuesday 3 December - 5pm CET
Participants
- Stefan, Piotr, Gunnar, Guru, Johan, Pete, Stephen L, Sachin, Viet-Ahn, Philippe, 10 participants
- apologies: Alexander
...
- Permission schemes
- Android Compatibility Definition Document (skipped to next call)
- Software architectural task force : Vehicle Data architecture for Android
- Next events: calls and F2F meeting organization - date planning - look here
- Backlog
- 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
...
- next calls are scheduled on Tuesday 17 December a,d Tuesday 14 January
- F2F meeting: participation table is here. Please fill it on
Tuesday 19 November - 5pm CET
Participants
- Sachin, Gunnar, Gerald, Piotr, Pontus, Stefan, Viet-ahn, Guru, Alexander, Philippe
- Apologies: Johan, Pete,
...
- Summary of Tech Summit and discussion about the latest architecture pictures.
Gunnar shows the update on the architecture made during last week's workshop in Detroit
- Pictures are included in the (commented) Tech Summit slide deck attached to this page.
- Proposal for organizing a second F2F meeting before EoY, meeting could possibly hosted by Tieto in Poland
- /TODO/ Gunnar create a duddle to gather the possible meeting dates and then send the date and other requirements for the meeting to Viet-Ahn
- /TODO/ Gunnar create a wiki page to gather the inputs and outcome of discussion on the architectural design
- Alex: we need to identify the building blocks in the architecture diagrams
- Alex: for instance we need to add the authorization / permission scheme stuff, one approach is to reuse Google permission scheme
- discussion on ServiceIds in Android
- Stefan: posts the following link: http://androidxref.com/9.0.0_r3/xref/packages/services/Car/service/src/com/android/car/hal/PropertyHalServiceIds.java
Sachin: I would recommend that we look for what we are violated from Google ? what contradicts the certification requirements of the CTS ? IMHO we need to have to look at the level of the standardized requirements that the CTS checks
- Stefan: IMHO we are not violating anything but a way to check it is to look at the Android Compatibility Definition Document: https://source.android.com/compatibility/cdd
Assignment of work items (for the next meeting)
- how permission schemes are managed for custom properties, how access control is managed, vendor extension of the permission (assigned to: Stefan)
- reviewing the someip identity and access management, GPRO has already reviewed this, they need to provide their review results to the Vehicle HAL project (assigned to: GPRO participants)
- review of the Android Compatibility Definition Document (assigned to: Sachin)
22 October 2019
8 October 2019
25 September 2019
10 September 2019
28 August 2019
Vehicle_Properties_Architecture
VSS presentation NOTE the current VSS is not at the link listed in this presentation. It is now stored at https://github.com/GENIVI/vehicle_signal_specification