Important threads (currently)
CCS Proof-Of-Concept - Work Breakdown Structure
Value measurement formats
Access Control
Monday 2020-12-14
US friendly time 16:00 CET
Agenda
- welcome to new participant
- CVII follow up
- Fosdem
- GAIA-X & EATA
- sprint & backlog review (postponed because Jira is not available)
Participants
Ulf, Glenn, Kevin, Stephen L, Iyyaz Barber (Cobrasphere), Gunnar, Philippe
- apologies: Benjamin, Ted (due to a VSSo call)
Minutes
welcome to new participant
- Iyyaz Barber (Cobrasphere) joins for the first time, Iyyaz attended the GENIVI AMM
- quick roundtable
- Iyyaz: works on API connectivity, rather on the entreprise side, how to collect data from the edge, his expertise is with MS Azure, IBM cloud and other smaller provides, one of his colleagues is knowledgeable about AWS
- discussion on CI infrastructure, discussion on containarization pros ans cons
CVII follow up
- MS: Gunnar and Philippe and Ted (W3C) had a good call with MS MCVP team members last week, MS is very supportive of the CVII work, and wants to make sure the information about CVII is distributed in the MS organization, MS preferred language for describing data and data relationships is JSON-LD - JSON for Linking Data (which a W3C specification), url: json-ld.org, MS DTDL is based on JSON-LD
- MS: Gunnar shows the slides about DTDL and various translation approaches he shared during the call with MS
- Hyundai: Hyundai is working on a vehicle data model, but whether they want to help building a standard is still TBD
- Sensoris: Gunnar has reached them out again in order to set up a coordination, this is work-in-progress on Sensoris side
Fosdem
- Philippe: what's up with the abstract preparation ?
- Kevin: having Geotab as a co-presenter would be good
- Glenn: agrees that Ulf should be involved
- Philippe: my proposal is to recycle the presentation delivered by Kevin at the GENIVI AMM and to show code in github
- TODO Ulf and Kevin with Gunnar's support will prepare an abstract for Wednesday 16 December
-
CCS-188
-
Getting issue details...
STATUS
commented
GAIA-X & EATA
- Philippe browses through the GAIA-X project web site: https://www.data-infrastructure.eu/GAIAX/Navigation/EN/Home/home.html
- in the technical concept section - How GAIA-X project works ? it is stated that one focus area will be an "easy access to the available providers, nodes and services. Data will be provided through federated catalogues"
- in the BMW/AWS press release, it is also stated that "The BMW Group will contribute its expertise from these use cases to the recently announced Automotive Alliance, which will be based on GAIA-X standards. As founding member (BMW Group) and “Day 1 Member” (AWS) of GAIA-X, the two companies are striving to further develop the Cloud Data Hub towards the GAIA-X standards for sovereign, secure and innovative data spaces"
- although the data spaces referred to there might be rather relevant to parts and manufacturing, it would be good to determine whether this work complements or supersedes CVII work
- then Philippe browses through the EATA alliance web site: https://eata.be/, both BMW and Hyundai are members together with Toyota and Mazda (and also Iveco and MAN truck manufacturers), does EATA complements, overlaps or supersedes CVI work ?
gap analysis between AWS and CCS framework
- it is proposed to go again through the analysis performed by Kevin during the Wed call if Ted and Benjamin can make it
sprint review
- postponed due to Jira being not available
Wednesday 2020-12-9
US friendly time 17:00 CET
Agenda
- gap analysis between AWS and CCS framework
- Fosdem
Participants
Kevin, Ulf, Stephen, Philippe, Gunnar
gap analysis between AWS and CCS framework
-
CCS-101
-
Getting issue details...
STATUS
- Kevin: shows the analysis he made on AWS, this makes sense today because of the joint press release by BMW and AWS - look at https://telematicsnews.info/2020/12/08/aws-and-bmw-group-team-up-to-accelerate-data-driven-innovation/?utm_source=feedburner&utm_medium=email&utm_campaign=Feed%3A+telematicsnews+%28Telematics+News%29
- Kevin: I initiated a gap analysis, i.e. an assessment of the mapping of AWS components on the CSS framework components, the initial results are captured in the Jira ticket
- for instance AWS greengrass would "override" Gen2 protocol implementation
- the name of Amazon timestream is mentioned : is this a time series database ?
- Gunnar: do we identify some of these and try them out and integrate them ?
- Kevin: 3rd party APIs to the data is not different for automotive than for other domains and might be reused, VSS2 might be a better fit because it was designed for automotive use only
- Gunnar: CVII - do we convert from VSS to firehose or greengrass to use them ? for instance MS said they need everything to be translated to MS DTDL
- Kevin: we do not know whether AWS have their own data model
- Gunnar: Ted is in the process of organizing a meeting with Patrick Bleicher who is now with AWS
- Stephen L: On the device side Greengrass Core, which has local AWS Lambda functions, msg broker etc, can be integrated into higher performance silicon components. There is also Greengrass for FreeRTOS focused on lower power MCU. It has things functionality like Greengrass discovery and MGTT agent.
- Stephen L: AWS team maintains a Yocto layer to ease integration of Greengrass into Linux distributions in github https://github.com/aws/meta-aws
- Stephen L: look also at https://github.com/aws-samples/meta-aws-demos. There was an integration of AWS into the AGL demo a couple of years ago, more to look at in this repo
- Philippe: would like to put the topic of AWS in the agenda of next Monday's call, Unknown User (kevinval) would this be ok ?
- Kevin : agreed
Fosdem
- Philippe: presents the Fosdem CfP and the rationale for submitting and delivering a talk there, the CfP is there
- discussion on the content of a talk to Fosdem (not captured because of audio issue on Philippe's side)
- TODO Philippe to create a ticket for submitting a talk to Fosdem
-
CCS-188
-
Getting issue details...
STATUS
created, assigned to Kevin and Ulf
- Kevin and Ulf will check whether HM and Geotab can propose a joint talk at Fosdem, and report back on Monday CCS call next week
Monday 2020-12-7
US friendly time 16:00 CET
Agenda
- sprint & backlog review
- sync with Benjamin
Participants
Ulf, Glenn, Kevin, Benjamin, Stephen L, Gunnar, Philippe
Minutes
sprint review
Sync with Benjamin
- VW: is is still a W3C member although not active
- discussion on how to reach out to VW
- VSSo : eurecom has made a proposal for vsso, there is a need for a sync on vsso between Ted, Gunnar, and Benjamin
- TODO GUnnar to set up a meeting with Ted and Benjamin on VSSo
Wednesday 2020-12-2
US friendly time 17:00 CET
Agenda
Participants
Minutes
implementation review: kuksa code walktrough
discussion with Christian on the code structure of https://github.com/eclipse/kuksa.val and a possible extension of the technology stack developed by bosch in kuksa.val
Gunnar; shows the activity matrix for cvii and bosch additions at the bottom of the page
Monday 2020-11-30
US friendly time 16:00 CET
Agenda
Minutes
sprint & backlog review: the following tickets were reviewed
-
CCS-53
-
Getting issue details...
STATUS
-
CCS-185
-
Getting issue details...
STATUS
-
CCS-129
-
Getting issue details...
STATUS
-
CCS-181
-
Getting issue details...
STATUS
-
CCS-101
-
Getting issue details...
STATUS
-
CCS-183
-
Getting issue details...
STATUS
-
CCS-184
-
Getting issue details...
STATUS
-
CCS-68
-
Getting issue details...
STATUS
Wednesday 2020-11-25
US friendly time 17:00 CET
Agenda
- code implementation review
Participants
Ulf, Kevin, Gunnar, Ted, Stephen L, Philippe
Minutes
Monday 2020-11-23
US friendly time 16:00 CET
Agenda
- Autosar signal2service interface
- sprint & backlog review
Participants
Christian H, Matthias Danzeisen, Glenn, Kevin, Stephen L, Ted, Gunnar, Philippe
Minutes
Autosar signal2service interface
Gunnar: with this mechanism, are we talking of CAN signals or something at a different level ?
Matthias: there is a specification / methodology defined to map signals to interfacesn like signals on a Can bus
Matthias: a possible implementation uses a signal2service daemon where you map udp signals to service
discussion captured in
CCS-87
-
Getting issue details...
STATUS
comment section
- Matthias: an explanation of the sensors interface mapping of the iso standards to signal2service is provided there
sprint & backlog review: the following tickets were reviewed
-
CCS-88
-
Getting issue details...
STATUS
- Philippe to ping Guru on CCS-88 and possibly close the ticket
-
CCS-87
-
Getting issue details...
STATUS
-
CCS-101
-
Getting issue details...
STATUS
-
CCS-135
-
Getting issue details...
STATUS
-
CCS-152
-
Getting issue details...
STATUS
-
CCS-184
-
Getting issue details...
STATUS
Wednesday 2020-11-11
US friendly time 17:00 CET
Agenda
Participants
Ulf, Kevin, Gunnar, Philippe, Ted
Minutes
sprint & backlog review (continuation of review started last week)
CCS-18
-
Getting issue details...
STATUS
-
CCS-110
-
Getting issue details...
STATUS
-
CCS-111
-
Getting issue details...
STATUS
- Gunnar will add a comment explaining his thougths concerning the use of driving simulators and "foreign tables"
-
CCS-112
-
Getting issue details...
STATUS
- Gunnar: this work item (which is done) relates actually to the so-called Technology Stack work identifed in the CVII activity matrix, we will talk to Bosch this week in a CVII workshop follow-up call and the question of candidate components for the technology stack will be addressed there
-
CCS-160
-
Getting issue details...
STATUS
- Philippe: we need to talk with Sanjeev BA and determine the status of the various subtasks (suspended and put back in the backlog or in-progress), will schedule a call with Sanjeev next Monday
-
CCS-133
-
Getting issue details...
STATUS
-
CCS-134
-
Getting issue details...
STATUS
- Kevin: the code is in github, ticket done
CCS-142
-
Getting issue details...
STATUS
-
CCS-8
-
Getting issue details...
STATUS
-
CCS-102
-
Getting issue details...
STATUS
- Philippe: I added two links to this ticket, one link relevant to the use of a production-grade database
CCS-123
-
Getting issue details...
STATUS
and one link to the investigation on which components from the KUKSA.VAL project could be reused for a demo
CCS-184
-
Getting issue details...
STATUS
-
CCS-184
-
Getting issue details...
STATUS
assigned to Ulf Bjorkengren, Ulf should be able to start looking at KUKSA.VAL in 2-week time
-
CCS-146
-
Getting issue details...
STATUS
-
CCS-148
-
Getting issue details...
STATUS
- Gunnar: e should Unknown User (alexander.domin) for an update on the status of any work concerning this that could be in-progress on BMW side ? Thanks
-
CCS-149
-
Getting issue details...
STATUS
- Gunnar: I still have issues running the OpenDS simulator
- Philippe: if we were meeting F2F, this would be solved in a peer programming session
- Gunnar: let us schedule a conference call with Stefan Wysocki for hosting this peer programming session
CCS-99
-
Getting issue details...
STATUS
-
CCS-139
-
Getting issue details...
STATUS
-
CCS-101
-
Getting issue details...
STATUS
- Philippe
CCS-101
-
Getting issue details...
STATUS
in last Monday's call, Sebastian explained they are now working on the data collection use case where sets of data are pushed to AWS, IMHO we need to analyze how the AWS can be used to support parts of the CCS communication infrastructure
- ticket assigned to Unknown User (kevinval)
AOB
Monday 2020-11-9
US friendly time 16:00 CET
Agenda
- sprint & backlog review
- AMM follow up - CVII
Participants
Sebastien, Gerald, Ulf, Glenn, Ted, Kevin, Benjamin, Stephen L, Gunnar, Philippe
Minutes
sprint & backlog review
- review of tickets assigned to Benjamin & Sebastian & Gerald
-
CCS-109
-
Getting issue details...
STATUS
- Sebastien: there is no vehicle state storage in kuksa, it is a digital twin within the car taking info from CAN and talking VSS to the cloud, the online use case with data streaming is implemented using MQTT (actually a subset of MQTT)
- Sebastien: we are now working on the data collection use case using the web socket interface for collecting a batch of data and upload it to Amazon
- Gunnar: reminds Sebastien about the mqtt paper produced by the CCS project a while ago, Sebastian Schildt please have a look at
CCS-143
-
Getting issue details...
STATUS
, paper is attached to this ticket
- Sebastian: the code of the demo by Bosch at the GENIVI AMM is available at https://github.com/eclipse/kuksa.val <-- Reuse THIS
- Philippe: it might be worth looking at what could be reused in the Bosch demonstrator for the next version of the demo, ticket
CCS-184
-
Getting issue details...
STATUS
created
-
CCS-171
-
Getting issue details...
STATUS
,
CCS-173
-
Getting issue details...
STATUS
- Benjamin: reviewed these documents while he prepared the slide deck on Sensoris/Jaspar/VSS (comparison of data models) for the AMM, look at TBD
- tickets can be closed
-
CCS-140
-
Getting issue details...
STATUS
- Benjamin: will look at it again and check whether the SAREF automotive spec has been published
-
CCS-138
-
Getting issue details...
STATUS
Philippe: we need to sync with Bosch on the Digital Twin Description
Sebastian: I fully agree with the fact we need to sync on digital twins
Gunnar: IMHO the question is where do I search from the current correct values of the vehicle data (even if there is a disconnect iwth the car)
Sebastian: there might a twin in the cloud and a twin in the car
Sebastian: I can reach out people from Bosch involved in Ditto project and put them in contact with whoever in CCS team is willing to look at Ditto
- Philippe: CCS-138 to be closed because Bosch delivered a presentation on digital twins at the AMM, look at Bosch slide deck
- Philippe: I suggest to add a subtask to CCS-136 to determine which kind of digital twins is useful in the context of the CCS /CVII projects
AMM follow up - CVII
- upcoming Webinar: Mobex scheduled a webinar on CVII on 19 November, this seminar is intended to disseminate further the W3C/GENIVI initiative on the Common Vehicle Interface
- Gunnar: introduces and gives an overview of the wiki page he created whose purpose is to structure the CVII work, please look at Common Vehicle Interface Initiative - Activity Matrix
- Philippe: it would be good that CCS participants review the page for next week Monday call
- the follow up with Bosch, Renault, Ford, Hyundai, Volvo, VW etc. is in-progress
- Gunnar: the objective is to have one-to-one discussions with each party to identify what they want to do with CVII
- ticket
CCS-185
-
Getting issue details...
STATUS
created for tracking the review results
Wednesday 2020-11-4
US friendly time 1700 CET
Agenda
Participants
Minutes
sprint & backlog review
- review of epic
CCS-18
-
Getting issue details...
STATUS
-
CCS-106
-
Getting issue details...
STATUS
-
CCS-107
-
Getting issue details...
STATUS
- State storage is actually implemented using SQLite in the demo delivered at the AMM, ticket comm"nted and closed
- TODO Philippe to poke Keith on the liaison with Autosar, there is a need for a translation from Autosar to VSS DONE waiting for feedback
- Philippe: an alternative contact for Autosar might Christian H.
-
CCS-108
-
Getting issue details...
STATUS
SQLite ias accepted and used in production already, do we have alternatives ?
Ulf: some years ago, JLR develop something called VSI (on genivi github) that relied on shared memory
Gunnar: in some sense it is a kind of library, relevant to state storage
links in github
TODO Ulf to have a quick look at VSI, ticket assigned to Ulf
-
CCS-109
-
Getting issue details...
STATUS
- there is a need to reactivate the discussion with Sebastian and Bosch in general
- TODO Philippe to poke Sebastian, ticket commented
-
CCS-121
-
Getting issue details...
STATUS
-
CCS-123
-
Getting issue details...
STATUS
Gunnar: it would be good to demonstrate with thousands of vehicles to show the performance
Ulf: agreed
ticket assigned to Gunnar, Ulf will help adapting the go code in the server (postgres)
note: postgres is an option, influx DB is another option
-
CCS-168
-
Getting issue details...
STATUS
need to poke Glenn about it ?
ulf: would rather cancel it
ticket closed ac CANCELLED
- review of backlog suspended at
CCS-128
-
Getting issue details...
STATUS
review of workbreakdown structure
- entry #1 - In-vehicle State storage : technonology choices for proof-of-concept and production-grade updated, see Jira tickets
- entry #4 - In-vehicle Data server : technonology choice for proof-of-concept updated (Gen2 implementation now uses ovds.db file. On-demand requests are fetched from database. Timed subscriptions are also supported, i.e. send updates at regular intervals.
- There is not yet implementation of a trigger to the gen 2 server from the database when a new value is written (SQLite supports trigger in theory).
- entry #8 - OEM cloud access management :
CCS-127
-
Getting issue details...
STATUS
is a large piece of work
- entry #9 - OEM cloud resource management: we still use the manually generated graphql schema
- Gunnar: the update of the graphql schema is still to do, will poke Daniel (BMW) on this
- a new ticket is to be created for tracking the connection between graphql and ovds,
CCS-181
-
Getting issue details...
STATUS
created
- entry #10 - neutral data server marketplace
AOB
- CVII working session follow up
- Renault, Huyndai: Gunnar
- Ford, VW: Philippe
- Gunnar proposes to update a table in the internal wilki we used when we prepared the AMM which is agreed
Monday 2020-11-2
US friendly time 16:00 CET
Agenda
- AMM debriefing
- sprint & backlog review
Participants
Ulf, Glenn, Ted, Kevin, Stephen L, Guru, Gunnar, Philippe
Minutes
AMM debriefing
- Kevin: not too much of a discussion in the session, although I got some comments privately, no new work items were identified
- Ulf: it was interesting to watch the demo
- Glenn: we need to follow up the presentation on curve logic, the next step is to get the license agreement signed, we would like to discussion the various open source license options with Gunnar
- TODO Gunnar to send possible timeslots for a call with Geotab
- Ted: my interest is with the follow up on CVII
- Philippe: I will have a call with the ISO ExVe WG convenor this week and then we will schedule with him to determine how we can coordinate with ISO
- slide decks and videos are available at GENIVI Virtual Member Meeting October 2020
Sprint & backlog review
CCS-87
-
Getting issue details...
STATUS
assigned to Unknown User (christian.heissenberger)
CCS-156
-
Getting issue details...
STATUS
as discussed above
CCS-11
-
Getting issue details...
STATUS
closed
CCS-59
-
Getting issue details...
STATUS
CCS-102
-
Getting issue details...
STATUS
we need to identify the feature content for the next version of the demo in 2 or 3-month time (next milestone was CES at the beginning of Jan 2021)
CCS-159
-
Getting issue details...
STATUS
add link to Stefano's presentation, ticket is closed
CCS-71
-
Getting issue details...
STATUS
Kevin will finalize this ticket
CCS-83
-
Getting issue details...
STATUS
Gunnar: we had a significant discussion on last Friday's VHAL working session
- discussion on access control policy
Philippe: it would be good to create a wiki page to capture the inputs for creating an example
Ulf: will populate the wiki page Data Access Control
CCS-105
-
Getting issue details...
STATUS
the follow up with the various stakeholders of CVII will be discussed in this week's PMO call
Monday 2020-10-19
US friendly time 16:00 CET
Agenda
- upcoming AMM - CCS demo & work session preparation readiness check
Participants
Ulf, Glenn, Ted, Kevin, Stephen L, Gunnar, Philippe
Minutes
demo readiness check
- Gunnar: had a talk with Sanjeev roday about his work on Grafana, Sanjeev might deliver some code this week
- Gunnar: the demo system is up & running
- discussion on initialisation of processes with Ulf, issue fixed
- Ulf: tested the OBD live data provided by his colleagues in Toronto, these data cannot be shared yet, but a sharable data set is expected shortly, these data were recorded using the curve logic algorithm, we might have some inconsistencies when displaying them (to checked)
- the data set is the following
Vehicle/Cabin/Infotainment/Navigation/CurrentLocation/Longitude
Vehicle/Cabin/Infotainment/Navigation/CurrentLocation/Latitude
Vehicle/Drivetrain/Transmission/Speed
Vehicle/Acceleration/Longitudinal
Vehicle/Acceleration/Lateral
VehicleAcceleration/Vertical
Vehicle/Drivetrain/FuelSystem/Level
Vehicle/TravelledDistance
Vehicle/ADAS/ABS/IsEngaged
Vehicle/Drivetrain/InternalCombustionEngine/RPM
Vehicle/Drivetrain/Transmission/Speed
Vehicle/Cabin/Infotainment/Navigation/CurrentLocation/Altitude
Vehicle/OBD/CoolantTemperature
- Ulf: will share the sharable OBD data set with Gunnar as soon as I get it
status report and working session readiness check
- Kevin: I still need a slide on CVII from Gunnar and I am still missing other topics for discussion in the workshop
- Philippe: Unknown User (glenn.atkinson) can Geotab provide a topic ?
- discussion on curve logic algorithm that could be a good candidate for discussion
- Glenn and Ted will work on the preparation of the curve logic topic, to be checked on Wednesday call
- Philippe: we expect some slides to introduce each topic discussed during the working session
- topic added to wiki page 2020 October Tech Summit — CCS working session
Wednesday 2020-10-14
US friendly time 17:00 CET
Agenda
- eSync Alliance / GENIVI joint presentation
- AOB
Participants
Minutes
- eSync Alliance slide deck (not uploaded yet)
- GENIVI slide deck (not uploaded yet)
Monday 2020-10-12
US friendly time 16:00 CET
Agenda
- upcoming AMM - CCS work session content
- sprint review
Participants
Ulf, Benjamin, Kevin, Christian H, Stephen L, Gunnar, Philippe
Minutes
CCS work session content
- wiki page for preparing the session is at 2020 October Tech Summit — CCS working session, the link to the updated agenda is there
- the wiki page identifies also the expected contributors to each section of the working session
- TODO all participants to add topics for discussion during the working session in the table at the bottom of the wiki page
sprint review
- Augment Vehicle Data Model
-
CCS-170
-
Getting issue details...
STATUS
Benjamin presents his findings
vehicle motion interface specs mostly describe ADAS systems, a lot of stuff we are not interesred in (physical laws), describe some sensors and actuators, raw signals and intermediate signals, some systems are pretty simple, please look at Benjamin's comment in Jira
-
CCS-173
-
Getting issue details...
STATUS
Benjmain presents his findings
this work is much closer to what W3C is doing (REST interface, json payload on http), it is a top down hierarchy, with metadata, containers and subcontainers, there are some common elements with VSS sections, e.g. start time, end time, etc, iso description of map section ids
the message structure is pretty interesting, some links to ISO standards for time and location and good practices, this looks similar to we need in VSS to contextualize the vehicle data we define
- please look at Benjamin's comment in Jira
- Benjamin: it would be good to get an example of a json payload defined by Jaspar
- Philippe: there are two more documents to review, assigned to Unknown User (benjamin_klotz) tentatively, please confirm you can have a quick look at them
-
CCS-172
-
Getting issue details...
STATUS
-
CCS-171
-
Getting issue details...
STATUS
- Philippe: IMHO it would good to add a topic on gap analysis between Jaspar and VSS in the CCS working session, the rationale is that Toyota said they will identify someone for the CVII session at the upcoming AMM, we should also invite this person to the CCS working session
- Gunnar: this is a good proposal, we have work to do to identify overlap and gap both for VSS vs. Sensoris and VSS vs. Jaspar, I will update the working session content accordingly
AOB
- presentation of eSync Alliance : it will be scheduled during the regular Wednesday CCS call, invite sent
Wednesday 2020-10-07
US friendly time 17:00 CET
Agenda
- demo implementation status
- AOB
Participants
Ulf, Kevin, Ted, Stephen, Gunnar, Philippe
Minutes
demo implementation status
- Ulf: Geotab team might be able to provide by Monday next week a set of vehicle data recorded during a real trip in the Toronto area
- Gunnar: shows the demo repo and explains to Ulf the build issues he has
- followed by a short sync on the building of the iOS app between Gunnar and Kevin
AOB
- Kevin will have a v2 of the working session content by Monday 12 October
Monday 2020-10-05
US friendly time 16:00 CET
Agenda
- upcoming AMM - CCS work session content
Participants
Glenn, Kevin, Stephen L, Gunnar, Philippe
Minutes
CCS work session content
agenda updated online
addition of 2 placeholders for the list of relevant standards including security, and the liaison with CVII
discussion on a placeholder for a demo video in the status report
discussion on the demo look
AOB
- presentation of eSync Alliance scheduled on Wednesday, October 14th at 17:00 CET / 8:00am PT
Wednesday 2020-09-30
US friendly time 17:00 CET
Agenda
- tech summit working session agenda preparation
- MS3 (tech summit) demonstrator implementation
Participants
Ulf, Kevin, Stephen, Gunnar, Philippe
Minutes
working session agenda preparation
- work breakdown structure update is done
- Kevin: first content for the working session agenda by next week
MS3 (tech summit) demonstrator implementation
- Gunnar explains to Ulf the trouble he experienced with building with go
AOB
- we will have an opportunity to sync with the eSync Alliance (https://esyncalliance.org/) in the coming weeks (likely on Wednesday 14 October during the CCS call)
Monday 2020-09-28
First call - Asia friendly time 11:30am CET cancelled due to Sanjeev's busy elsewhere
Second call only - US friendly time 16:00 CET
Agenda
- work breakdown structure review
- CVII update
Participants
Ulf, Glenn, Kevin, Stephen L, Gunnar, Philippe
Minutes
work breakdown structure review
- objective is to update the wiki page and align the page content with the actual status of the implementation work
- after the update is done, Kevin will start preparing the agenda for the working session at the upcoming virtual tech summit
- wiki page updated online CCS Proof-Of-Concept - Work Breakdown Structure
- discussion starts with the review of the updated block-diagram at the top of the page
- review will continue during this week's Wednesday call
CVII
- Gunnar browses through the slide deck shown during the 2nd OEM roundtable that happened last Thursday
Wednesday 2020-09-23
US friendly time 17:00 CET
Agenda
- MS3 (tech summit) demonstrator implementation review
- work breakdown structure update
Participants
Minutes
application level
- High-Mobility reports their progress on the implementation of the app
- application runs on Apple IOS
- the data used are the EV data in VSS branch
- Ulf: discussion on OBD data that are available at Geotab, they could be used for a second demonstrator, will investigate what can be done in the given timeframe until the virtual tech summit (26-30 October)
work breakdown structure
- the objective is to start preparing the tech summit
- TODO Kevin update the names and chosen technologies in the wiki page & block diagram
-
CCS-178
-
Getting issue details...
STATUS
- &
CCS-179
-
Getting issue details...
STATUS
created (attached to epic dissemination)
Monday 2020-09-21
First call - Asia friendly time 11:30am CET cancelled due to Sanjeev's busy elsewhere
Second call only - US friendly time 16:00 CET
Agenda
- sprint & backlog review - CCS
Participants
Ted, Glenn, Kevin, Stephen L, Gunnar, Philippe
Minutes
sprint & backlog review - CCS
- Jira updated online, in particular
-
CCS-123
-
Getting issue details...
STATUS
-
CCS-80
-
Getting issue details...
STATUS
-
CCS-59
-
Getting issue details...
STATUS
-
CCS-87
-
Getting issue details...
STATUS
-
CCS-134
-
Getting issue details...
STATUS
changed to in-progress
Wednesday 2020-09-16
US friendly time 17:00 CET
Agenda
- MS3 (tech summit) demonstrator implementation review
Participants
Minutes
demonstrator implementation review
- Gunnar: shows the status of the demo packaging wih the containers
- Ulf: demo almost working, json related issue will be investigated by Ulf
- Ulf; there is a proposal being elaborated by Geotab for a OBD-II populated database that could be used for feeding the vehicle data
- Kevin: High Mobility is working on the application level as expected
Monday 2020-09-14
First call - Asia friendly time 11:30am CET cancelled due to Sanjeev's busy elsewhere
Second call only - US friendly time 16:00 CET
Agenda
- sprint & backlog review - CCS
- CVII
- tech summit preparation
Participants
Ted, Glenn, Kevin, Stephen L, Gunnar, Philippe
Minutes
sprint & backlog review - CCS
-
CCS-5
-
Getting issue details...
STATUS
assigned to Kevin
-
CCS-168
-
Getting issue details...
STATUS
- Gunnar: it seems Geotab have an opinion on the distance between their platform and the CCS communication framework
- Glenn: Geotab sdk is open and interfaces are public, Geotab will provide their vision of the so-called distance
-
CCS-169
-
Getting issue details...
STATUS
closed as duplicate on CCS-168
-
CCS-101
-
Getting issue details...
STATUS
- Gunnar: would it be interesting to use some of the AWS services ? deploying using AWS lambda is worth looking at after the tech summit
- Gunnar: is it a topic for the agenda of the working session ? who can bring the knowledge ? who has contact as AWS automotive ?
- Kevin: at HM we work rather with OEMs directly, we swork on safety KPIs son top of ISO 27017
- Kevin: https://docs.aws.amazon.com/solutions/latest/connected-vehicle-solution/architecture.html
- Stephen L: AWS are both in the cloud and in the vehicle, it is worth looking at greengrass that overlaps our solution, IMHO this is not competitive, rather complementary
-
CCS-141
-
Getting issue details...
STATUS
- Gunnar has not reported the work he did on it, still needs to look at this
- please push it later to the following sprint after the tech summit
-
CCS-53
-
Getting issue details...
STATUS
the call with Sensoris plenary meeting is scheduled on Thursday morning this week
CVII
-
CCS-105
-
Getting issue details...
STATUS
- Gunnar will produce a slide deck from the scoping document he wrote for the 2nd OEM RT
- in the 2nd rountable, we expect to have a sort of vote about the OEM commitment
- we did a sync up between GENIVI and W3C about our OEM contacts
tech summit preparation - abstract for the working session
- the proposed abstract text is below
- it is expected that the agenda for the CCS working session will be derived from the text below and augmented with whatever topic needs to be addressed
- "The current GENIVI work on data-driven connected vehicle software architecture is an important step towards achieving the seamless coupling of the in-vehicle and back-end architectures and delivering an end-to-end vehicle computing platform. This end-to-end platform leverages existing standards and solutions, but some gaps exist and overall interoperability is still far from achieved. We are convinced the GENIVI work will help the automotive industry take a big step toward the future when the in-vehicle software, E/E architecture and the back-end architecture will be moving closer together.
- The Cloud & Connected Services (CCS) project team has undertaken during Q2, 2020 the implementation of an end-to-end vehicle-to-cloud communication framework proof-of-concept demonstrator. This framework incorporates technology components identified by various collaborative projects such as W3C Gen 2 protocol built on VSS2, GraphQL, ISO Extended Vehicle Neutral Server. It clarifies connections to in-car technologies such as AUTOSAR-defined SOME/IP and several others.
- The CCS project team will present a status report of the CCS proof-of-concept implementation and explain the design choices made. The following topics will be also comprehensively debated:
- how to augment the vehicle data model, collaboration with the Sensoris project (www.sensoris.org)
- discussion on which APIs and components on the proposed architecture are candidates for standardization, the objective is to enable an open market for the software components of the communication framework (components are either in-vehicle or in the cloud)
- discussion on how the CCS project will contrbute to the newly laucnhed work on a Common Vehicle Interface (CVII)."
Monday 2020-09-06
First call - Asia friendly time 11:30am CET - shifted to Tuesday 7 September
Agenda
- contact with Cloudera
- sprint & backlog review
Participants
Nifi
Jira ticket
-
CCS-162
-
Getting issue details...
STATUS
updated
-
CCS-161
-
Getting issue details...
STATUS
updated
-
CCS-176
-
Getting issue details...
STATUS
created
-
CCS-177
-
Getting issue details...
STATUS
created
Second call only - US friendly time 16:00 CET
Agenda
Participants
Stefano Peduzzi (Geotab), Benjamin K, Chrsitian Heissenberger, Glenn (Geotab), Ulf (Geotab), Guru, Kevin, Stephen L, Gunnar, Philippe
Minutes
Geotab presentation
- Stefano's presentation identifies the business cases for Geotab, in particular the CVaaS (Connected Vehicle as a Service) is the one that is supported by the CCS communication framework end-to-end architecture
- presentation is here
- Philippe: IMHO this presentation matches well what was expected from the tasks in
CCS-5
-
Getting issue details...
STATUS
, this is to be consolidated further when the presentation is published
Wednesday 2020-09-02
Recap of implementation plan and status.
The plan/status table in CCS Proof-Of-Concept - Work Breakdown Structure is a bit outdated (wrong(?) responsibles, wrong plan).
It still needs a bit of an update. For now taking the notes here.
In Vehicle Server : still W3C_VehicleSignalInterfaceImpl
State Storage : Implemented by statestorage dir in ccs-w3c-client
Connection vehiclesever to statestorage is in ovds client / server in same repo
Demo Goal
Vehicle/OEM cloudside
- Data collection into state storage by driving the simulator around
- Gen2 server support get/set and subscription
- (Subscription using timer should work, but is not change triggered yet)
- OEM Cloud: Vehicle client can be set to send requests on a timer. Using a file to list signals.
- Stores data with timestamps into database
- Aim for signals that can be graphed
- How to visualize? Grafana. First approach integrate with sqlite according to current schema.
Neutral-Cloud-side
- Swift app with GraphQL client (mostly exists)
- Fetches data from GraphQL server in OEM cloud (server not yet started)
- Shown in a iOS application
- Easiest to go directly to OEM cloud for this demo
Remaining work:
- Integration OpenDS to statestorage (Gunnar)
- Define the signals that we expect to have (from OpenDS) --> Swift App can use
- !! GraphQL to OEM database integration (?)
- Grafana investigation and integration (Gunnar?)
- + "Fake" data feeder for Electrical Vehicle related signals
- list of signals need to match OpenDS is delivering
- packaging/testing, preparation
- (Optional) Subscription hook on new value / change - make server aware
Side tracks:
- Consider using influxdb instead in cloud (database optimized for time series data)
Monday 2020-08-31
First call - Asia friendly time 11:30am CET cancelled due to Sanjeev's busy elsewhere
Second call only - US friendly time 16:00 CET
Agenda
Participants
Ulf, Glenn, Kevin, Guru, Gerald Gunnar, Philippe
Minutes
Review of Jira tickets on data model in particular
-
CCS-174
-
Getting issue details...
STATUS
Guru has performed review worl on SVI, i.e. the Secure Vehicle Interface (SVI), there is a need to determine how this fits with the CCS work
-
CCS-138
-
Getting issue details...
STATUS
assigned to Gerald in order to get info from internal Bosch projects on DTDL
-
CCS-80
-
Getting issue details...
STATUS
- Gunnar: we made progress on our understanding of DTDL, we need now to write the VSS to DTDL translator
- TODO: Philippe to get back to MS to discuss this
-
CCS-153
-
Getting issue details...
STATUS
- Georg will moderate a panel at the upcoming virtual tech summit
-
CCS-156
-
Getting issue details...
STATUS
- Glenn: the paperwork about licensing is done
- Glenn: will send the proposed text to Steve, Gunnar and Philippe for review
-
CCS-152
-
Getting issue details...
STATUS
- Sync with W3C on contacts with Renault done on Thu 3 September (context: CVII)
-
CCS-169
-
Getting issue details...
STATUS
- Glenn: Geotab proposes to deliver a presentation on Geotab platform during next Monday's call
- Philippe: agreed, meeting invite sent
-
CCS-53
-
Getting issue details...
STATUS
- call with Sensoris Lead Architect from Bosch scheduled on Wed 2 September
- Lead architect proposed the Sensoris steering committee to coordinate with GENIVI the next day, the proposal was accepted
- a presentation of GENIVI VSS and CCS work is scheduled at the next Sensoris plenary meeting in September, Gunnar will deliver the presentation
Monday, July 27 - Vehicle Data Model, Common Vehicle Interface Initiative
First call - Asia friendly time 11:30am CET cancelled due to Sanjeev's busy elsewhere
Second call only - US friendly time 16:00 CET
Agenda
- Jaspar data models & APIs
- sprint & backlog review
- next calls
Participants
Minutes
Jaspar data models & APIs
- Philippe: presents shortly the work done by Jaspar (the Japanese sister organization of Autosar) on the Autonomous Driving / ADAS Vehicle Motion Control Interface
- Stephen: points out that Jaspar has published additional documents on the vehicle interface that might be relevant for the VSS / VSC work
- Benjamin will have a look at these documents and report whether they complement or overlap with VSS
-
CCS-170
-
Getting issue details...
STATUS
created and assigned to Benjamin
- the list of Jaspar documents to review in addition to ST-AVI-1 above is at https://www.jaspar.jp/news/498
- (ST-VI-1)Dynamic Vehicle Information Sharing API Specifications Ver.1.0
- (ST-VI-2)Dynamic Vehicle Information Sharing Concept Specifications Ver.1.0
- (ST-VI-3)Common Vehicle Information and Data Set Specifications Ver.1.0
-
CCS-173
-
Getting issue details...
STATUS
created and assigned to Unknown User (benjamin_klotz) ,
CCS-171
-
Getting issue details...
STATUS
,
CCS-172
-
Getting issue details...
STATUS
created
sprint & backlog review - review of tickets assigned to Kevin and Benjamin
-
CCS-71
-
Getting issue details...
STATUS
reminder for Kevin
-
CCS-136
-
Getting issue details...
STATUS
next call with Microsoft is likely to be scheduled during the 2nd half of August, it would be good to Kevin's inputs before mid-August
-
CCS-133
-
Getting issue details...
STATUS
added to the new sprint
-
CCS-140
-
Getting issue details...
STATUS
reminder for Benjamin to sync with Gunnar
-
CCS-24
-
Getting issue details...
STATUS
is it time to look again at the data categories ?
next call
- Wednesday 29 July call is cancelled because it is better to wait for Gunnar to be back to discuss again the packaging of the demo and any other implementation topic
- Monday 3 August call is cancelled, any progress on the data model related documents is to be reported in the Jira tickets
- next CCS call will be on Wednesday 5 August
Wednesday, July 22 - Vehicle Data & Communication Framework
Agenda:
- AASIG VHAL demo
- sync with W3C
- AOB
Participants
Minutes
AASIG VHAL demo
- Stefan Wysocki has published a demo for the VHAL project proof-of-concept, that uses graphql and the OpenDS simulator
- to learn about the demo code and video, please look at the minutes of the 21 July weekly meeting at https://at.projects.genivi.org/wiki/x/HYVoAg
- Ulf will have a quick look at the demo
sync with W3C
- Philippe: asks Ted about W3C contacts at Renault, W3C and GENIVI have different contacts, this will be taken in an offline call between GENIVI & W3C to discuss coordination of our activities w.r.t. the Common Vehicle Interface Initiative
AOB
- heads up on the upcoming GENIVI AMM / technical summit
- Content planning has started
- Dates: 26-30 October
- Day 1: thought leadership and market trends
- Day 2-5: project working sessions
Monday, July 20 - Vehicle Data Model, Common Vehicle Interface Initiative
First call - Asia friendly time 11:30am CET cancelled due to Sanjeev's busy elsewhere
Second call only - US friendly time 16:00 CET
Agenda
- CVII
- sprint & backlog review
- next calls
Participants
Minutes
CVII
- OEM roundtable was hold on Thursday 16 July
- the roundtable received a positive feedback from all OEM participants
- Ted: Ford was an advocate
- next step will be a workshop to discuss the "how" that will be scheduled in the coming weeks
sprint & backlog review
-
CCS-144
-
Getting issue details...
STATUS
- Gunnar: explains the work he did on the containerization of components in order to build a demo putting together all the system, he needs to inform Ulf of the work done, but not likely before the 1st week of August
-
CCS-125
-
Getting issue details...
STATUS
- ticket is closed
- two new tickets are created to track the assessment of the impact of CCS work and VSS on the Geotab SDK
CCS-168
-
Getting issue details...
STATUS
- and on the Geotab platform architecture
CCS-169
-
Getting issue details...
STATUS
-
CCS-156
-
Getting issue details...
STATUS
- conditions of access to the Geotab curve logic algorithm are closerto be pubished by Geotab
- this is followed by a short discussion on Gen2 protocol specfication wich works with time intervals and is not intereoperable with curve logic based sampling, one approach would that the Gen2 protocol detect the sampling method that is used and decide on the protocol then
-
CCS-143
-
Getting issue details...
STATUS
- Gunnar will upload the updated tech note and close the ticket
-
CCS-80
-
Getting issue details...
STATUS
- Philippe: will remind MS about the next agreed call whose topics are Digital Twin Description Language (DTDL) and VSS vs. AUTOSAR ARXML
-
CCS-152
-
Getting issue details...
STATUS
- GENIVI and W3C will sync on their contacts with Renault in an ad-hoc call
-
CCS-135
-
Getting issue details...
STATUS
- Philippe: will follow up with Christian on the scheduling of a call with SensorIS
Next calls
- Philippe will set up and moderate the call on
- Wednesday 22 July at 17:00 CET
- Monday 27 July 11:30am CET and 16:00 CET
- Wednesday 29 July at 17:00 CET
- no call on Monday 3 August
- Gunnar will set up and moderate the call on
- Wednesday 5 August at 17:00 CET
- Monday 10 August at 11:30am CET and 16:00 CET
- Wednesday 12 August at 17:00 CET
- calendar invites will be sent accordingly
Wednesday, July 15 - Communication Framework
Agenda:
Participants
Minutes
Jira review (tickets updated online)
-
CCS-30
-
Getting issue details...
STATUS
-
CCS-137
-
Getting issue details...
STATUS
-
CCS-141
-
Getting issue details...
STATUS
-
CCS-111
-
Getting issue details...
STATUS
-
CCS-85
-
Getting issue details...
STATUS
-
CCS-53
-
Getting issue details...
STATUS
Monday, July 13 - Communication Framework, Vehicle Data Model, Common Vehicle Interface Initiative
First call - Asia friendly time 11:30am CET cancelled due to Sanjeev's busy elsewhere
Second call - US friendly time 16:00 CET cancelled due to agenda collision with the GENIVI Board virtual meeting
Wednesday, July 8 - Communication Framework
Agenda:
Participants
Ulf, Gunnar, Kevin, Stephen, Benjamin, Christian, Ted, Philippe
Minutes
-
CCS-107
-
Getting issue details...
STATUS
- Ulf: work was done some weeks ago
- Keith is supposed to do a mapping with Autosar
- Ulf: before my vacation i updated the Gen 2 server so that it is possible to configure the dataserver so that it looks for data in a state storage database
- therefore it is possible to have a mapping from AUTOSAR or any non-AUTOSAR data for the data feeder
- Gunnar shows the code in the repo
- Ulf provides clarifications on how to launch what, either the dummy server or the server accessing the state storage database
- ovds - open vehicle data server
- how can it be used ?
- Ulf: by having a client requesting service from the ovds server
- Ulf will provide info on how to launch a client
- Ulf: will look why the obds server does not start
- Gunnar will update the ticket accordingly
-
CCS-149
-
Getting issue details...
STATUS
- driving simulator: Gunnar put somr work into it
-
CCS-110
-
Getting issue details...
STATUS
- discussion on CAN representation of signals
- we would add another mapping from CAN representation to vehicle signals
-
CCS-151
-
Getting issue details...
STATUS
- Stephen L will provide inputs when it is time to implement, ticket assigned to Stephen
Monday, July 6 - Communication Framework, Vehicle Data Model, Common Vehicle Interface Initiative
First call - Asia friendly time 11:30am CET cancelled due to Sanjeev's busy elsewhere
Second call only - US friendly time 16:00 CET
Agenda
- sprint & backlog review (on data modeling related tickets)
- CVIM
Participants
Gunnar, Stephen, Christian K, Benjamin, Glenn, Kevin, Keith, Philippe
Minutes
sprint & backlog review (on data modeling related tickets)
CVIM
-
CCS-105
-
Getting issue details...
STATUS
- Philippe: we have made progress towards the organization of an OEM roundtable about CVIM, member and non-member OEM will gather next week, we will have 3 champions to present their views w.r.t. CVIM
-
CCS-80
-
Getting issue details...
STATUS
- Philippe: browses through the MCVP slidedeck shown by MS during our last call of 22 June and highlights the slides describing the strategic collaboration with RNM Alliance and VW
- Philippe: gives an overview of the technical discussion with MS, look here
- discussion follows on ARXML and what is the best source of Autosar data description
- Keith thinks the Autosar UML model is the best source
- Gunnar: will contact Itemis (Klaus Birken) to know about the latest Autosar UML model and which version is available in Artop
VSS feeder
-
CCS-110
-
Getting issue details...
STATUS
- Keith has some issues with the execution of the vehicle simular, under investigation
Monday, June 29 - Communication Framework, Vehicle Data Model, Common Vehicle Interface Initiative
First call - Asia friendly time 11:30am CET cancelled due to Sanjeev's busy elsewhere
Second call only - US friendly time 16:00 CET
Agenda
- sprint & backlog review (on data modeling related tickets)
Participants
Ulf, Ted, Kevin, Keith, Gunnar
Minutes
sprint & backlog review (on data modeling related tickets)
-
CCS-53
-
Getting issue details...
STATUS
Possible follow-up with companies who are active in Sensoris, or more official Sensoris-representative to confirm our conclusions, and progress the data-catalog question.
Gunnar: I'm considering extending https://at.projects.genivi.org/wiki/display/DIRO/Value+measurement+formats with the idea of values tied to a GPS position, similarly to timestamp.
- The data items that are transferred, this still ties to the question of merging data catalogs into a single one (into VSS tree format) – still open question of sorts.
- The definition of their Envelope, Message format, is useful for the particular position-oriented model and hard to reuse generally.
-
CCS-156
-
Getting issue details...
STATUS
- Glenn gives an update on discussions on licenses. Detailed paperwork coming so that we can review.
-
CCS-125
-
Getting issue details...
STATUS
-
CCS-80
-
Getting issue details...
STATUS
- MCVP presentation attached to the ticket
Wednesday, June 24- Communication Framework
Agenda:
Participants
Ulf, Gunnar, Philippe
- apologies: Keith, Kevin,
Minutes
Jira review
IMPLEMENTATION
CCS-129
-
Getting issue details...
STATUS
CCS-111
-
Getting issue details...
STATUS
CCS-111
-
Getting issue details...
STATUS
was commented by Kevin
ANALYSIS
CCS-143
-
Getting issue details...
STATUS
Gunnar: this is completed to the right level of analysis, next step would take a few days, we need a reviewer for this
Ulf: will look at it
Philippe: will add Benjamin to the reviewer list,
2 tickets created for tracking the review
CCS-167
-
Getting issue details...
STATUS
&
CCS-166
-
Getting issue details...
STATUS
CCS-137
-
Getting issue details...
STATUS
Philippe: AWS device shadow would be a good selling point to show a different implementation path
Gunnar: yes it is possible, having a local cache in the vehicle
Philippe: we should try to demo this for CES and ask Amazon to support it
todo Gunnar add a comment to this ticket on how to fetch values
-
CCS-53
-
Getting issue details...
STATUS
assigned to Gunnar for reviewing the HERE materials
-
CCS-148
-
Getting issue details...
STATUS
- Ulf: looks very similar to the state storage
- Ulf: implementation maps Gen2 server interface
- we do not know for graphql yet
- Ulf: we should ask Piot to look at the state storage we have in github
- comment added by Gunnar
Ulf on holiday for next week
Monday, June 22 - Communication Framework, Vehicle Data Model, Common Vehicle Interface Initiative
First call - Asia friendly time 11:30am CET
Agenda
- contact with Cloudera
- sprint & backlog review
Participants
Minutes
Cloudera
Gunnar and Philippe had a phone discussion with Michael Ger last week
Michael understood we are making progress with VSS
Michael presented the Edge Computing to AI project they are working on with NXP, Windriver, Teraki (a specialist in video and data compression)
we explained Michaek we are working with Sanjeev
we gonna have another call with those companies above, then we expect to set up a call between Cloudera engineering team and Sanjeev
sprint and backlog review
AOB
- Sanjeev: in W3C repo, I saw no git update anymore, is there any further progress ?
- Gunnar: not so many changes of the implementation in https://github.com/MEAE-GOT/W3C_VehicleSignalInterfaceImpl
- Gunnar: Ulf was given some other tasks on the database, etc. Ulf thinks the server is complete now, waiting for further changes in the specs
Second call only - US friendly time 16:00 CET
Agenda
- CVII
- sprint & backlog review (on data modeling related tickets)
Participants
Ulf, Ted, Kevin, Keith, Gunnar, Philippe
Minutes
CVII
Philippe: OEM outreach was discussed during lats week's GENIVI board of directors call, next step is to organize an OEM roundtable bringing together member and non-member OEMs and raise their attention on CVII, the roundtable will be scheduled in early July, another roundtable iwth non OEMs will be scheduled later
- Gunnar: the work on service catalog is making progress in parallel on github, this will increase our readiness level when we know more about OEM interest for CVII
sprint and backlog review
- ANALYSIS epic
CCS-1
-
Getting issue details...
STATUS
-
CCS-23
-
Getting issue details...
STATUS
Keith: no progress yet
-
CCS-159
-
Getting issue details...
STATUS
Ulf is waiting for Glenn (Geotab) to provide inputs
-
CCS-71
-
Getting issue details...
STATUS
commented
- discussion on data points listed in the Data Categories wiki page
- Ted: mentions an article about EU expectation w.r.t. datapoints
- Gunnar: it starts from the service stations which are not limited to OEM certified stations
- Gunnar: I do not think it will change our framework design
- Ted: there are two drivers regulators and business
- OEMs will not allow 3rd parties in, but EU (and US) said this is anti competitive
- Kevin: this requirement is covered by Extended Vehicle for the maintenance use case of data categories
- Kevin: if there is no business behind a data point the regulator will not pushed it
- TODO Kevin to write down the drivers
- Kevin assigned , no urgent (targeted timeline is likely for the Fall AMM)
-
CCS-140
-
Getting issue details...
STATUS
-
CCS-78
-
Getting issue details...
STATUS
wip
- clarification made on autopilot project url
-
CCS-30
-
Getting issue details...
STATUS
commented by Gunnar who reviewed the project materials
- DISSEMINATION epic
CCS-41
-
Getting issue details...
STATUS
-
CCS-7
-
Getting issue details...
STATUS
wip
- CVIM epic
CCS-104
-
Getting issue details...
STATUS
-
CCS-80
-
Getting issue details...
STATUS
- discussion with Microsoft last week was on the mapping from VSS to DTDL a.k.a. Digital Twin Description Language
- Gunnar: IMHO DTDL is not so far from ARXML
- Gunnar: Unknown User (keith.derrick) we should look for some semantics equivalence between VSS and ARXML
-
CCS-135
-
Getting issue details...
STATUS
Phiilippe will check how to sync with Bosch other than on Mondays
AOB
Keith: has trouble with running Ulf proof-of-concept code written in go
Ulf explains how to do "go run", usually Ulf does a "go build" first before running it
Keith: tries this out, issue solved
Wednesday, June 17 - Communication Framework
Agenda:
Participants
Ulf, Ted, Kevin V, Stephen L, Gunnar, Philippe
- apologies: Keith
Minutes
work breakdown structure review
Jira review
Monday, June 15 - Communication Framework, Common Vehicle Interface Initiative
First call - Asia friendly time 11:30am CET
Call cancelled due to unavailabilty of participant
- progress report will be provided for CCS call of Wedneday 17 June
Second call only - US friendly time 16:00 CET
Agenda
- CVII
- sprint & backlog review (on data modeling related tickets)
Participants
Ulf, Glenn, Kevin, Gunnar, Philippe, Gerald
- apologies: Keith
Minutes
CVII
Philippe: OEM outreach was discussed during lats week's GENIVI board of directors call, next step is to organize an OEM roundtable bringing together member and non-member OEMs and raise their attention on CVII, the roundtable will be scheduled in early July, another roundtable iwth non OEMs will be scheduled later
- Gunnar: the work on service catalog is making progress in parallel on github, this will increase our readiness level when we know more about OEM interest for CVII
sprint and backlog review
- CVIM epic
CCS-104
-
Getting issue details...
STATUS
-
CCS-136
-
Getting issue details...
STATUS
& subtasks
CCS-137
-
Getting issue details...
STATUS
&
CCS-138
-
Getting issue details...
STATUS
assigned to Kevin V, will look at them in the coming weeks
-
CCS-105
-
Getting issue details...
STATUS
Philppe will ping Bosch people about their participation to the CCS Monday calls, a new call with Microsoft is scheduled on Thursday 18 June
- DESIGN epic
CCS-10
-
Getting issue details...
STATUS
-
CCS-156
-
Getting issue details...
STATUS
- Gunnar asks Glenn for clarification because this algorithm is patented, could we have an offline discussion about this ?
Glenn: I could arrange an offline talk with the authorizing people at Geotab
- Glenn: benefit from Geotab is that the algorithm enables to bring to the cloud only the data that are important and discard the less important ones
short discussion on what geotab and genivi could achieve together
Gunnar: we would need a statement of intention from Geotab about the usage of the algorithm
ticket assigned to Glenn
-
CCS-157
-
Getting issue details...
STATUS
- Glenn underlines the main input to review is Omniair - association formed to test interoperability of Tier 1 suppliers of V2V and V2X system being implemented into some current (high end) and future vehicles. https://omniair.org/tag/v2v/
- Gunnar will contact the omniair project lead and asks for info
-
CCS-98
-
Getting issue details...
STATUS
ticket is done
- ANALYSIS epic
CCS-1
-
Getting issue details...
STATUS
Wednesday, June 10 - Communication Framework
Agenda:
Participants
Ulf, Kevin V, Keith, Gunnar, Philippe
Minutes
work breakdown structure review
Jira review
Monday, June 8 - Communication Framework, COmmon Vehicle Interface Initiative
First call - Asia friendly time 11:30am CET
Agenda
- weekly sync with Sanjeev : review of workplan on other technology options for implementing the framework
Participants
- Sanjeev, Gunnar, Philippe
Minutes
review of workplan
review of slide deck attached to
CCS-124
-
Getting issue details...
STATUS
Milestone content (slide #2)
Edge Computing (slide #5)
Apache Spark (slide #4)
VSS on Eclipse Paho (slide #6)
Gunnar: mentions the ticket about mapping VSS to MQTT (specification only)
Sanjeev: Eclipse Paho is just a tooling
Sanjeev: it comes with a simulator which is quite attractive
Gunnar: VSS on MQTT - maybe we need to work on this earlier than December; someone else can perhaps look at it
Cloudera
Second call only - US friendly time 16:00 CET
Agenda
Participants
Keith, Ted, Ulf, Glenn, Steve, Kevin, Gunnar, Philippe
Minutes
CVII
Gunnar: makes a recap on CVIM discussion, Gunnar Andersson please update the slide you showed, thanks
Keith: who is the OEM active in W3C ?
- Ted: JLR
Keith: what is the service catalog about ? VSS is about the data acquisition
- Ted: JLR is proposing something to GENIVI & W3C for the command side (service catalog)
Ted: please have a look at https://www.w3.org/2020/03/26-auto-minutes.html#item05
Keith: I heard quite a few OEMs would not get on-board a command API, their concerns is that if you have an API, here are also the parameters on the command, and it gives your IP away from this knowledge, I have been pushed back
Keith: OEMs even described which functions they do not want to be visible
discussion on proprietary vs. non-proprietary model items
- Keith: Autosar define their own internal stanfards (for application component APIs) but the architects of the vehicle projects did not use them because they consider it is too much effort
Keith: OEMs love standards for off-the-shelf ECUs and sensors but not for internal work
- Gunnar: there is an ability to have private branches in VSS, they could be positioned as VSS Extensions
Gunnar: currently we name everything as VSS, it might be worth thinking about differentiating the naming of the data model and the tooling and the spec langage
Kevin V: IMHO it is a little bit tricky to make a common service API
Gunnar: shows an example of a service catalog from the github repo, we use same words and features as Franca
discussion with Kevin on the service API, for instance the function turnonheater
Kevin V: approach has changed in order to make no assumption on how an OEM intends to implement the control of a function, a signal group is used then for this purpose
Ulf likes the structured way we used
learning about production platforms for connected vehicle services
- Philippe: reminds Glenn about
CCS-125
-
Getting issue details...
STATUS
, our expectation was added as a comment there
Wednesday, June 3 - Communication Framework
Agenda:
Participants
Minutes
Jira review
CCS-72
-
Getting issue details...
STATUS
changed to done
Glenn has provided the link to the video presenting the Geotab algorithm
Ulf: the functionality for this algotrithm will be in Gen2
Gunnar: I will look at this video, I am not sure whether the compression algorithm should be part of Gen2, other statistics like an average could be implemented in a "node", this must be discussed with W3C people
CCS-156
-
Getting issue details...
STATUS
CCS-74
-
Getting issue details...
STATUS
changed to done
Glenn has provided the link to the NTHSA paper on V2X and an additional paper
Gunnar: will look at it as well
CCS-157
-
Getting issue details...
STATUS
created
note: this ticket is rather a topic for a Monday call
CCS-4
-
Getting issue details...
STATUS
-
CCS-96
-
Getting issue details...
STATUS
&
CCS-97
-
Getting issue details...
STATUS
-
CCS-97
-
Getting issue details...
STATUS
- Ulf added a concluding comment on Daniel Wilms' vision of the data lake design
Daniel Willms view is that the graphql server should directly access the SQL database, instead of via the HTTP interface that the OVDS server exposes.
That makes possible more complex queries on the data set than what is possible through the OVDS server interface. I see no problem with exposing both, and let a client choose which to use.
-
CCS-158
-
Getting issue details...
STATUS
created and assigned to Ulf
-
CCS-59
-
Getting issue details...
STATUS
changed to in-progress
- Gunnar sent an email to Cloudera
- link added to Sanjeev's work
CCS-124
-
Getting issue details...
STATUS
-
CCS-102
-
Getting issue details...
STATUS
comment added
Gunnar: production in my mind means actual deployment in the industry, in order to manage millions of vehicles, our work is not going to reach production, I tried to capture in this column of the work breakdown structure (and this ticket) which technogoies need to be changed to go to that kind of scale
Gunnar: we should not talk about a reference version term and use v1,v2,v3,v4 to label the maturity of the implementation
CCS-70
-
Getting issue details...
STATUS
Ted: refers to an email sent by Arnand, who is not sure whether we need to look at specific use cases, we should rather be looking at the data points (as required by the European Union for instance)
looking for business cases is not relevant anymore, ticket changed to done
-
CCS-71
-
Getting issue details...
STATUS
CCS-159
-
Getting issue details...
STATUS
created
Philippe: we need to create a ticket to bring elements for a story telling about the use cases
Ted: next week I will meet with John from Ford and they will talk about the group John is forming within Ford
- Ulf: about the biz cases in the graph project, at Geotab we believe we have to change the solution because we think that OEMs will not agree to share vehicle data in the same repo , Geotab thinks the model has to be revised
- Ulf: we will come back with a proposal on how to explain the biz value of the graph project to the OEMs and other stakeholders in two-week time likely
- ticket assigned to Ulf for tracking the presentation of this proposal
CCS-85
-
Getting issue details...
STATUS
Gunnar: no feedback from the security team although some of them might be aware of this EU work
Philippe: the list of reviewers who provided comments on the EU document is available here . 3 OEMs did it (VW, Volvo Cars, Tesla and ACEA which represents the European OEMs)
CCS-125
-
Getting issue details...
STATUS
commented
Gunnar/Philippe; the same question can be asked both Geotab and High Mobility
Kevin: it is difficult to relate our CCS work to a commercial platform, this is about how the CCS work could be integrated with a commercial platform
CCS-129
-
Getting issue details...
STATUS
commented
Kevin: will descrive the oem cloud resource management
"In the communication framework we have a distinction between different interfaces from the OEM cloud:
- Consent Management
- Authentication Management
- Resource Management (data access)
This has been done as a best practice and to follow the Extended Vehicle architecture. However for the PoC it makes to simpify. What is needed is an API component that exposes the GraphQL server externally to Neutral Servers and 3rd parties. This component has to take care of querying the requested data from the OEM cloud database as well."
Monday, June 1 - Communication Framework
First call - Asia friendly time 11:30am CET
Agenda
- weekly sync with Sanjeev : other technology option for implementing the framework
Participants
- Sanjeev, Gunnar, Philippe
Minutes
- Sanjeev has digged into open source componennts like Apache NiFi components and others for implementing the framework using technology options different than the ones currently used for the first version of the proof-of-concept (a.k.a. Gen2). Some of these technologies were used by Cloudera in a demo in an earlier GENIVI AMM in Korea.
- Sanjeev's proposal is described in a slide deck attached to
CCS-124
-
Getting issue details...
STATUS
- Gunnar / Philippe: propose Sanjeev to continue in this parallel track while Gunnar will contact Cloudera to see whether some collaboration might be set up with them, look at :
CCS-59
-
Getting issue details...
STATUS
Monday, May 25 - Communication Framework
Second call only - US friendly time 16:00 CET
Agenda
- sync between CCS and AASIG VHAL projects
- GraphQL server implementation
Participants
Minutes
Vehicle data simulation
GraphQL generation
- Below comments are extracted from
CCS-96
-
Getting issue details...
STATUS
updated by Kevin
- Gunnar : it is good to have anoter component to be added to the set of components
NiFi
- Sanjeev will look at other ways to transmit data from the cars to the OEM cloud, we have no idea whether it impacts the architecture we have yet
MQTT
- Gunnar: MQTT handles only the way you describe the topics and the subscription to those topics , but the payload content is not defined, it is not a major work to do in my opinion
- Gunnar: MQTT is popular, should on the list of TODOs for the future
- Gunnar: I will write a mapping doc from VSS to MQTT, please add this to the backlog
Monday, May 18 - Client Implementation, Vehicle Data
First call - Asia friendly time 11:30am CET
Agenda
- weekly sync with Sanjeev on the client implementation
Participants
- Sanjeev, Gunnar, Philippe
Minutes
- review of work breakdown structure
- Gunnar: Ulf showed his wor at the summit, but we still need a command line implementation
- Sanjeev: in my opinion showing 3 different terminals in the demo shown by Ulf is good for the time being, but it was difficult to understand which terminal was showing which component, I want to improve
the user experience - Sanjeev: are you working with Cloudera ?
- Gunnar: we talked to Cloudera, it is now time to start discussing with them again
- Gunnar: it might be interesting to work with Apache NiFi and al. components
- Sanjeev: one proposal could be to connect the CCS demo and OBD II signals retrieved from the Hortonworks demo shown at the GENIVI AMM in Korea
- TODO Sanjeev to move forward with this parallel implementation
- Sanjeev: I would like also to showcase a server less configuration and Alexa-based queries
- Gunnar: I recently identified cool projects to help with the deployment of services (with SSO)
- Sanjeev:. Iwill do some planning and propose a workplan until next milestone in July
Second call - US friendly time 16:00 CET
Agenda
- virtual tech summit debrief
- code sync between Ulf and Gunnar
Participants
Keith, Guru, Ulf, Stephen, Gunnar, Philippe
- apologies: Kevin
Minutes
Thursday, May 14 - Virtual Technical Summit Workshop
minutes are here
Monday, May 11 - Client Implementation & VTS CCS Project Report Review
First call - Asia friendly time 11:30am CET
Agenda
- weekly sync with Sanjeev on the client implementation
Participants
- Sanjeev reported his progress offline
Minutes
- Sanjeev: fixed the crash issue (was related to Gen2 server log implementation) and cleaned up scripts. CLI based test works uninterrupted. Ulf informed him that he will do the demo during the virtual session on Thursday.
Virtual Technical Summit - CCS Project Report Review
Participants
- 405 attendees registered to the summit
Minutes
- CCS project report is here
Wednesday, May 6 - Communication Framework
Agenda:
- proof-of-concept implementation status
- virtual tech summit - workshop preparation
- Jira review
- AOB
Participants
Ulf, Gunnar, Philippe
- apologies: Keith, Kevin V
Minutes
proof-of-concept implementation status
virtual tech summit - topics for the CCS workshop
- each topic will be introduced with a short slidedeck to fuel the discussion
- topic #1 - Generation of vehicle data
- Ulf: in the demo, we transport data from the gen2 server to the data lake, but we transport only dummy values, how to integrate something underneath : vehicle simulator or real vehicle data
- Gunnar: one possiiblity is to download a vehicle simulator and "drive a car around" to generate data, how to get people signing for this ?
- intro slide deck owner: Philippe
- topic #2 - Technology options for bringing vehicle data into the system
- Gunnar: IMHO we need to investigate other technologies than Gen 2 for bringing vehicle data into the system
- Gunnar: we should think about some use cases and produce some criteria for future decisions
- Gunnar: we will need to scale up the system and measuring its performance, example of options: Web style protocols, coding optimization
- intro slide deck owner: Gunnar
- topic #3 - Interface between the datalake and the neutral server and the third parties app
- Ulf: one could discuss what needs to be done above the datalake from "the datalake to the upper left side" of the high-level diagram
- Philippe: we need to realize that this interface is perhaps the easiest to start with analyze for a possible standardization, because the righ side of the high-level diagram (from the vehicle to the OEM cloud) is currently largely based on proprietary solutions
- intro slide deck owner: Kevin V ?
- topic #4 - privacy expectations
- Ulf: got some feedback on the terminology like data lake, in a privacy context, data lake has a negative vibe
- Gunnar/Philippe: agreed in particular because we claim we are ISO Extended Vehicle compliant meaning we have "privacy-by-design"
- intro slide deck owner: Gunnar
- topic #5: data exchange formats
- Gunnar: since we will likely have attendees that do not follow the day2day work, it is important to disseminate some of the results of our work
- one key opic is the data exchange formats
- slide deck owner: Gunnar
Jira review
-
CCS-79
-
Getting issue details...
STATUS
&
CCS-80
-
Getting issue details...
STATUS
moved to a new epic
-
CCS-104
-
Getting issue details...
STATUS
created
-
CCS-105
-
Getting issue details...
STATUS
created
-
CCS-83
-
Getting issue details...
STATUS
this work item is related to and needs to sync with the work on W3C Gen2, comment added
-
CCS-85
-
Getting issue details...
STATUS
Gunnar sent out the link to European Union privacy guidelines to the GENIVI security team for review, comment added
-
CCS-98
-
Getting issue details...
STATUS
is now WIP, Ulf sent an email to Adnan and Daniel
Monday, May 4 - Client Implementation, Vehicle Data
First call - Asia friendly time 11:30am CET
Agenda
- weekly sync with Sanjeev on the client implementation
Participants
- Sanjeev, Benjamin, Gerald, Gunnar, Philippe
- apologies: Ulf
Minutes
- Sanjeev: client was committed on github, I have one issue with the Gen2 server that crashes when (too) many requests are sent
- Sanjeev: I have other thoughts about the technologies (e.g. NiFi) we could use for implementing the clients, when should I start looking into these ?
- Gunnar: we need to get the current implementation you made running first
- Gunnar: I do not have root access to the Gen2 server, so I cannot help for the debugging, I would be good to package this component according to the approach used in CCS-arch-demo repository
- Sanjeev: I agree it makes sense, I will package everything in a docker container once the crash issue is solved
- Sanjeev: explains what he can show as a demo for the upcoming Virtual Tech Summit
Second call - US friendly time 16:00 CET
Agenda
Participants
Minutes
Wednesday, April 29 - Communication Framework
Agenda:
- proof-of-concept implementation status
- AOB
Participants
Ted, Ulf, Keith, Gunnar, Philippe
- apologies: Keith, Kevin V
Minutes
proof-of-concept implementation status
Ulf: I helped Sanjeev to install the go build system today
Gunnar: I also had some trouble with the go building
Ulf: next week I should be able to run the client and do a demo
Gunnar: will there be a command line client ?
Ulf: no the client will go through the complete VSS tree and check for changes, it will work as an infinite loop asking for more data from the data lake
Gunnar: IMHO it might be useful to have a command line interface as well
Gunnar: I tried to build the data server and has some issues with the dependencies
discussion with Ulf on how to set up the datalake and populate the database content
we need to double check the MIT licence since we are modifying code for implementing the ccs-w3c-client DONE MIT license is fine
Jira tickets review
Monday, April 27 - Client Implementation, Vehicle Data
First call - Asia friendly time 11:30am CET
Agenda
- weekly sync with Sanjeev on the client implementation
Participants
- Sanjeev, Ulf, Gunnar, Philippe
Minutes
- discussion on Hortonworks demo on fleet management: which radio stations are best used among a fleet of vehicles ? Sanjeev said it is an impressive demo
- discussion on implementation of gen2 server
- Gunnar shows the code quality guidelines
- update of PoC WBS online
Second call - US friendly time 16:00 CET
Agenda
- AW webinar slide deck review
Participants
Ulf, Keith, Kevin Valdek, Guru, Gunnar, Philippe
Minutes
AW webinar slide deck review
Wednesday, April 22 - Communication Framework
Agenda:
- graphql schema example
- PoC design & implementation
- Webinar & virtual summit workshop content
- projectization in jira
- AOB
Participants
Kevin V, Ted, Ulf, Keith, Gunnar, Philippe
Minutes
graphql schema example
Gunnar: Alex (BMW) is still waiting for a colleague to review his example before publishing it
Kevin: shows the tool chain Gunnar and he proposed to go from VSS2 to graphql schema, look at the model transformation workflow attached to
CCS-96
-
Getting issue details...
STATUS
Kevin: explains the workflow and also a possible alternate workflow from VSS2 to 3rd party client (i.e. w/o going through the neutral server)
Kevin: for the demonstrator we will focus on the EV charging datapoints in order to show attractive use cases
discussion on the data packages and distance w.r.t. the data structures used by CVIM and Sensoris
Ulf: this format does not fit very well with Gen2, IMHO this is not seen in the Gen2 protocol transfer, but rather in the OEM cloud
Gunnar: The picture does not show it used for the transmission to the cloud but in the vehicle only. The format might be used in the car, or not... but I think it is OK to indicate the idea of this would be there (to support historical values). The format is not fixed yet, it needs to be refined further
Gunnar: the in-vehicle state storage could use SQL but might also not need it (it is a simple key-value if not multiple time stamps are stored).
Kevin: I will document which format to put for which version of the proof-of-concept in the wiki
- /TODO/ Kevin V to document which format to put for which version of the proof-of-concept in the wiki
PoC design & implementation
- Gunnar: shows the code repo structure in github, CCS-arch-demo repository
- repo names correspond to the actual implementation used
- please look at the various readme files
Philippe: jira will be structured according to a list of generic components corresponding to the HL diagram
Gunnar: explains how docker could be used to package each part (SW components) for development help, or maybe for production, e.g. CCS-arch-demo/tree/master/docker/sqlite repository
Gunnar: the next step is to program the create table command for the datalake from Ulf
Ulf: I started implementing the datalake using SQLite
Ulf: I talked to Sanjeev and I will implement a framework around the datalake and expose an API that the client will use to interface with Gen2
Gunnar: what will be the type of API between the vehicle client and the datalake
Ulf: I am actually working on a server that both the client component and the resource management component can use for accessing the datalake, it it written in REST
Gunnar: I am wondering what we will get from having REST APIs between those components, I am wondering whether there could be something simpler
Ulf: IMHO this is simple enough
Gunnar: both Sanjeev and you are working in Go, aren't you ? If one part was done in a typical web language like node.js I could see how a REST interface might be easier to consume. But especially with the same language other communication methods likely exist.
discussion on how to make interfacing simpler
Ulf: we might reconsider this later
Gunnar: it seems to me as some extra work, but we will see it soon then if it is almost done now anyway.
Webinar & virtual summit workshop content: gathering of topics
- Kevin: I will present how we came to the high-level diagram for the poc, @Gunnar : will you introduce VSS Gen 2 ?
- Gunnar: agreed
- Gunnar will be useful to give the full roadmap
- Philippe: proof-of-concept roadmap is as follows
milestone 1 - Spring virtual technical summit (12-14 May)
milestone 2 - internal milestone (early Q3 - July ?)
milestone 3 - Fall All Member Meeting, Leipzig, Germany (last week of October)
milestone 4 - CES 2021, Las Vegas, USA (early January 2021)
- Kevin: will show also an overview of the gap analysis
- Kevin: draft slide deck for the Webinar will be shared with Gunnar and Philippe to-morrow DONE
projectization in Jira
- Philippe: Jira database will be structured with generic components corresponding to big boxes of the high level communication framework diagram
Monday, April 20 - Vehicle Data
Agenda:
- Data Categories, VSS tree update with EV signals
- Value measurement formats
- Sprint & backlog review
- AOB
Participants
Kevin V, Ted, Ulf, Gerald, Guru, Benjamin, Keith, Gunnar, Philippe
Minutes
Data Categories, VSS tree update with EV signals
Value measurement formats
- Gunnar: goes through the latest modifications he made and through Ulf's comment at the end of the page
-
CCS-91
-
Getting issue details...
STATUS
- Gerald: it is a side topic maybe, can we discuss in the future the anonymization of the vehicle ID ? in C2C they provide temporary IDs and change it every 5mn
- Gunnar: update the "vehicle identity" definition in the wiki page online
- Philippe: what is the status of
CCS-93
-
Getting issue details...
STATUS
?
Gunnar: in the value measurement formats we have similar concepts as in CVIM and Sensoris, we need to check what maps to what
Ted: Sensoris is part of the Geospace consortium (OGC.3c work), AFAIK Sensoris is not technically aligned (tbc)
Gunnar: Unknown User (benjamin_klotz) can you help us do the mapping between the value measurement formats and the Sensoris spec ? ideally we should share the same names and perhaps the same content
Benjamin: I can do that both for Sensoris and CVIM as well
CCS-93 commented and changed to in-progress
discussion on Gen 2
Gunnar: I am not sure Gen2 needs to integrate the value measurement formats
Ulf: IMHO most of these should be outside of gen2
Gunnar: shows the "Protocol does not (yet) cover all variations of data exchange" bullet point of the section "Relationship to Protocols" of the wiki page
Ulf: however some data structures shown in the value measurement formats should be added to a gen2 client if the client needs historical data (Ulf Bjorkengren please review here and below)
Ulf: my proposal was that if a node supports historical data you can have metadata in the tree
Ulf: we need to discuss this in the Gen2 group
Ted: how does an application register and sign up to use data (this is related in my opinion to the best practice work in W3C ) ?
Sprint & backlog review
-
CCS-88
-
Getting issue details...
STATUS
reminder for Keith
-
CCS-82
-
Getting issue details...
STATUS
- Gerald: no need to analyze this use case further, sub-task converted to issue and sent back to the backlog
-
CCS-73
-
Getting issue details...
STATUS
- Philippe: browses through the wiki page 5GAA related papers for cloud & connected services
Gunnar: the ones at the top are more relevant that than ones at the bottom, who is interested to read the article of V2X ?
Philippe: will these papers influence our work to some extent ?
Gunnar: it might be interested to look there for the use cases for the demonstrator, so far we have not been so clear on what we want to demonstrate
- sub-task converted to issue and sent back to the backlog
-
CCS-62
-
Getting issue details...
STATUS
done
-
CCS-5
-
Getting issue details...
STATUS
- look at Gunnar's comment above on the use cases for the demonstrator
-
CCS-70
-
Getting issue details...
STATUS
- discussion on what this work item is all about
- Ted: there are some high-level stuff in the Automotive Business Group wiki, look at https://www.w3.org/auto/wg/wiki/Vss_data
- ticket updated on line by Gunnar
- reminder for Benjamin
-
CCS-71
-
Getting issue details...
STATUS
- list of materials to review updated, reminder for Gerald
-
CCS-6
-
Getting issue details...
STATUS
-
CCS-83
-
Getting issue details...
STATUS
- Gunnar: Ulf and I are discussing this topic offline, our thoughts on the access control implementation are not mature yet
- Philippe: I propose to move it as a subtask of
CCS-22
-
Getting issue details...
STATUS
-
CCS-84
-
Getting issue details...
STATUS
Wednesday, April 15 - Communication Framework
Agenda:
- graphql schema example
- PoC design & implementation
- Webinar & virtual summit workshop content: gathering of topics
- AOB
Participants
Kevin V, Ted, Ulf, Gunnar, Philippe
Minutes
graphql schema example
Kevin: my colleague is working on a graphql example
Gunnar: shows the content of Alexander's graphql file, althought this has not been uploaded by Alex on github yet
Gunnar: not sure of certain statements in Alex's code, I need to check with him
Ulf: the representation in the example seems a little bit redundant with the VSS tree represenetation
Gunnar: the question is that this representation might be useful when used with graphql tooling
Kevin: will the tooling be shared ?
Gunnar: I assume so
Kevin: it is nice to have this example available anyway
Gunnar: FYI Alex is working independently from Daniel, we might have two complementary visions eventually
Gunnar: then shows the very basic graphql example used by Stefan in AASIG VHAL
PoC design & implementation - please refer to CCS Proof-Of-Concept - Work Breakdown Structure
- Gunnar: suggests Ulf translates the slides he presented last week into a set of SQL instructions
- Philippe: IMHO we need to change to a implement and build mindset now
- Philippe: we need to think about the minimal demo we will show in one-month time at the virtual tech summit mid-May
- Ulf: it would be good to connect the data lake, the vehicle client and the data server (look at the proof-of-concept block diagram)
- Philippe: invites Ulf to join the Monday call with Sanjeev
- Gunnar: shows the vehicle client implementation VehicleSignalInterfaceImpl he tried out
- discussion on the feature set for the mid-May demo
- Gunnar: timestamp is enough (please refer to the wiki page Value measurement formats)
- Kevin: do the language or platform we use for the PoC implementation matter ?
- Gunnar: my proposal at this stage is that this does not matter, it is easier to do that way
Webinar content preparation
- Gunnar: AW Webinar is a Webex based, the speaker has a special view
- Gunnar: I recommend to have a back up recording on the speaker side
- Gunnar: the webinar structure (60mn duration) is as follows
- 1-2mn intro by AW
- 38mn presentation or so
- 20mn for Q&A
- discussion on the presentation content (lead, contributor)
- quick intro of GENIVI, why the project fits into the mission of GENIVI (Gunnar, Philippe) (with reuse of some intro slides from the AW HV Webinar)
- the reason why we started (GENIVI, Kevin)
- key message: cooperation with W3C is very strong
- vehicle data model overview & gap analysis - quick overview (GENIVI, Kevin)
- communication framework (Kevin, Gunnar)
- architecture and some design justifications (possibly)
- next steps
- project roadmap (GENIVI, Kevin)
- setting of milestones on the roadmap, with a feature content for each milestone (GENIVI, Kevin)
- content preparation timeline
- version V1 of slides: Wednesday 22 April
- version V2 of slides: Wednesday 29 April
- final version of slides: AW Webinar scheduled on Monday 4 May
- slide template
- /TODO/ Gunnar to send the slide template to Kevin V
Wednesday, April 8 - Communication Framework
Agenda:
- value measurement formats - review
- PoC design
- formatting layer
- authentication
- graphql schema example
- AOB
Participants
Kevin V, Keith, Ted, Ulf, Gunnar, Philippe
Minutes
value measurement formats - review
- Kevin V : explains the comments he made to the wiki page (look at the bottom of the page)
- Kevin V: we need such a protocol to be defined, the content of the wiki page is very advanced
- Kevin V: sensitivity level - an example of such an attribute is driver's fatigue (high) vs. engine oil level (low)
Gunnar: thanks for your very good feedback
Gunnar: the container is some kind of top level messaging format
Gunnar: I tried to work out a type hierarchy with subtypes
Gunnar: we should think that the content of the wiki page comes down to a generic protocol definition that could be instantiated into several actual protocol specifications
Gunnar: the W3C Gen 2 protocol might not take over all the facets of the generic procotol as it is defined there, but if we can align on some definitions and naming with W3C it would be good
-
CCS-81
-
Getting issue details...
STATUS
done
- Philippe: did you have a look at the description of formats ?
- Ulf: not yet, however since I am very Gen2 centric, I would say the formatting layer lies on top of Gen 2, using Gen 2 as the transport mechanism
- discussion continues of the position of the formatting layer in the CCS PoC
- quick check on the sprint & backlog
- Philippe: the cross-checking w.r.t. CVIM and Sensoris is to be performed next
-
CCS-4
-
Getting issue details...
STATUS
, subtask
CCS-93
-
Getting issue details...
STATUS
unanimous consent to reassign this ticket to Benjamin because of his former work on CVIM and Sensoris
![(smile)](/s/ypeau5/8804/xgjkrn/_/images/icons/emoticons/smile.svg)
formatting layer in the proof-of-concept
Ulf: the formatting layer is not visible in the vehicle, if the Gen 2 client sits in the cloud, this will sit on top of the client
Ulf: Gen 2 is agnostic w.r.t. where the client is deployed, the client could be in the vehicle or the cloud, in the CCS PoC the client is in the cloud
Ulf: I ambition this formatting layer to sit in the cloud in the CCS PoC
Ulf: concerning jobs, there could be specific jobs where you have some particular logic to implement (TBC likely not captured accurately, Ulf Bjorkengren please check)
Ted: I also see a gen2 client app residing on vehicle and *pushing* data samples to the cloud, I see more of push than a pull, this is an equally viable architecture
Ulf: agreed, design choice might depend on the data (transmission) cost (TBC likely not captured accurately, Ulf Bjorkengren please check)
Gunnar: for the push scenario, will that be using the set function ?
Ted: I would rahter use the subscribe function (TBC likely not captured accurately, Gunnar Andersson please check)
discussion on how to use Gen2
Gunnar: I try to determine if we can solve the use case with the current Gen2 or with an extension of it, set might not be appropriate today
@Ulf: you are driving the strategy for feature growth in Gen2, would you propose the support of time series in Gen2 ?
Ulf: yes, I would, it is relevant but perhaps not as an integrated part of Gen2, my view is that it should be outside Gen2
Ted: for the push scenario, look at https://www.w3.org/XML/EXI/, this technique can work for both XML and JSON, this technique is used for the management of large data distribution (e.g. for a fleet of vehicles)
authentication in the proof-of-concept
Keith: I have a question about the authentication, we did not discussed this yet
Keith: we need to discuss how to update the authentication info, I have in mind the use case of the service garage
Gunnar: we need to check whether the proposed architecture should be enhanced to take into account the service garage use case
Gunnar: this has to do actually with the role-based protocol discussed in W3C; in W3C it is assumed currently that the access to data is granted based on a role
Gunnar: in W3C work, by transport protocol we think at something like TLS, you have a certificate checked in TLS to certify you are accessing a certified OEM cloud
Keith: it might be worth documenting the assumptions
/TODO/ Gunnar to update
CCS-22
-
Getting issue details...
STATUS
accordingly, DONE
graphql schema example
- Kevin V: we are working on it
- Philippe: AASIG VHAL team is about to publish an example of a graphql schema
AOB
- WATCH OUT: next Monday call (12 April) is CANCELLED due to Easter break
Monday, April 6 - Client Implementation, Vehicle Data
First call - Asia friendly time 11:30am CET
Agenda
- weekly sync with Sanjeev on the client implementation
Participants
- Sanjeev, Gunnar, Philippe
Minutes
proof-of-concept design
- Gunnar; presents the refinement made on the component interface last week, in CCS Proof-Of-Concept - Work Breakdown Structure
- Gunnar: we are now collecting proposals for graphql schemas
- discussion on impact on Sanjeev's workitems
- Sanjeev: in my opinion, we might need someting like an object store for the data lake
- Gunnar: Ulf is likely to propose a relational data base
- Philippe: Ulf will make a presentation on the data lake in this afternoon CCS call
- Sanjeev: is there any reason to use a relational database ? I saw the data coming as a continuous data stream, unless there is a need of classification of data, I am wondering why we should use a database
- Gunnar: understood, in the long run, the name data lake means there could be very diverse data and it could make more sense to look into an object oriented database for instance
- Sanjeev: I stumbled in similar problems in the IoT domain
- Gunnar: we might go to Hadoop in a later version of the proof-of-concept
client implementation
- Sanjeev: last week worked with Ulf on fixing the Gen 2 server, we have a permanent node for the server provided by MIT, this took all the time I could spend on the project
- Sanjeev: do I have permission to create a repo in GENIVI github ?
- Gunnar: do we create a separate repo for the client ?
- Sanjeev: in my opinion, the W3C server module will be become a submodule of the CCS client I will be working on
- Gunnar: goes to github/genivi/ccs-w3c-client repo created, Sanjeev set up as admin of the repo
Second call - US friendly time 16:00 CET
Agenda
- Data Lake proposal
- Data Categories, VSS tree update with EV signals (skipped since Benjamin is not attending today)
- Value measurement formats
- Sprint & backlog review
- AOB
Participants
Ulf, Keith, Kevin Valdek, Ted, Michael Ger (Cloudera), Stephen Lawrence, Gunnar, Philippe
Minutes
Data Lake proposal
- Ulf: shows the following slide deck
- slide #2 - VSS data lake = VSS tree with data over time and VINs
- Michael: will this be done dynamically ?
- Ulf: let answer your question later
- slide #4 - VSS DB table structure
- VIN table is the main entry key
- how many tables will be generated ? actually quite a few table
- at least more than 500 TV-nodes : 500 000 tables might cause a performance issue
- this is why I changed the design to an alternative DB structure
- slide #5 - alternative DB structure
- # of tables is proportional to the # VINs
- might be a better design, need to get the opinion of a database expert
- Michael: might get this reviewed by a DB expert
- Keith: with one VIN table, performance wise it should be ok, storage wise of course this is different
- slide #6 - database definition
- Ulf: we should not put the VSS path in the database, because if we change the VSS tree, we will have to spread the change in the DB
- Ulf: a simplification of the tables is possible
- discussion on the matches and data retrievals (not captured)
- slide #7 - workflow to retrieve data
- Ted: I am wondering whether people wull use a traditional relational database, IMHO we need to get the opinion of Adnan and Benjamin on the database technology selection (i.e. in relationship with the graph server)
- Gunnar; we are very early in the implementation, we are not at the point to reach any conclusion on the database technology to use
- Philippe: mentions Sanjeev's comment on using object oriented data base
- slide #8 - deployment in CCS proof-of-concept
- Ulf: I have already developed 95% of the VSStoDB adapter
- slide #9 - how to develop / publish this
- Ulf: my intent is to small modifications in the VSS repo for storing the VSStoDB adapter code
- /TODO/ Ulf to ask opinion of Adnan and Benjamin on the VSS data lake design proposed in the presentation
Value measurement formats
- Kevin: review is still on my todo list, will provide feedback on Wednesday
- Ulf: same
Sprint & backlog review - Jira tracker
- review of active sprint
- review of tickets assigned to Unknown User (kevinval)
-
CCS-81
-
Getting issue details...
STATUS
done, but the content of the wiki page is not deprecated, we might reopen the ticket in the future
-
CCS-8
-
Getting issue details...
STATUS
subtask
-
CCS-86
-
Getting issue details...
STATUS
is done
- however parent task is not done since we need to create other subtasks on the definition of the proof-of-concept scope
-
CCS-96
-
Getting issue details...
STATUS
&
CCS-97
-
Getting issue details...
STATUS
created
- ticket assigned to Keith
-
CCS-88
-
Getting issue details...
STATUS
commented, for the time being we need a general understanding on the signal2service interface of Adaptive AUTOSAR
- other tickets will be reviewed in a later call
AOB - Automotive World Webinar
- Automotive World will schedule the webinar on 4 May, presenters will be Kevin and Gunnar, invite will be forward when it is available from AW
Wednesday, April 1 - Communication Framework
Agenda:
Participants
Kevin V, Kevin de Sousa, Keith, Ulf, Gunnar, Philippe
Minutes
Communication Framework PoC - moving into implementation start
- vehicle client
- Philippe reports on the call with Sanjeev (Samsung) (on Monday this week)
- Ulf: talked to Sanjeev, the two of them will team to work on the vehicle client
- in-vehicle OS
- Philippe reports on the call with Bosch (on Tuesday this week) about the possible reuse of components from the Kuksa project
- Sebastian Schildt: Kuksa focused more on the in-vehicle stuff
- Gunnar: this was our expectation
- Sebastian cannot commit to deliver software to GENIVI with any deadline constraint, however he could offer
- a Kuksa target board (1 or 2 samples) which is based on Rasperry Pi and can be plugged to the OBD
- this OBD feeder could provide some sort of VSS feeder or a lower part of the VSS feeder that could be accessed through Web sockets
- Tom said he is working on an infrastructure similar to CCS for the eBike project demo, there might be a cool alignment with CCS to look at. He will get back to us.
- detailed design
- Gunnar: shows the UML diagrams he added to the CCS PoC wiki page, these diagrams represent the relationships between some of the components of the OEM cloud and Vehicle OS subsystems
- Ulf: it is a good start, it makes things possible
- Ulf: I am ready to talk about the SignalStore and specially with the Bosch people if they are ready to talk about it
- Ulf: I thought about the data lake today, I will come with a proposal on next Monday likely, with a presentation, based on the use of a relational database like SQLite
- Kevin V: the UML diagrams shown are for the vehicle interface, how do we describe things on the neutral server side ?
- Gunnar: in my opinion the UML diagrams could be almost the same for the neutral server to OEM cloud interface,
- Kevin V: the dependency would be the API definition of the OEM cloud (relates to the graphql schema)
- discussion follows on the grapql schema content, how the VSS tree is represented with it ?
- the team agree they need to develop their own understanding of a graphql schema
- /TODO/ Kevin to take sample yaml code of VSS and transform it into a graphql schema
/TODO/ Philippe to ask Alex whether he can share the graphql he is using with Gunnar DONE
- next step
- Philippe: expects the team to move now to the actual implementation of the first version of the PoC to be shown mid-May at the virtual technical summit
Data categories
- Kevin V: added a couple of comments to the wiki page Data Categories, comments are reviewed
- discussion on the container entity proposed by ISO ExVe standard
- Kevin V: will paraphrase it the container description to stay on the right side of IP
- Kevin V: the container is for the car owner a way to understand for which set of data an OEM ask the car owner for his/her consent
- discussion on the naming of entities, some scoping necessary
- /TODO/ Gunnar to update the Data Categories wiki page according to Kevin V comments
How to instantiate the big picture on different vehicle EE / Cloud architectures
- Philippe: this topic has been in the backlog for a while
- on the vehicle EE side, we need to determine whether we intend to connect to an actual vehicle bus (e.g. using a OBD device or through Ethernet and an Adaptive Autosar ECU, etc.)
- on the cloud side, we need to think about the deployment of the communication framework on an infrastructure like AWS using for instance AWS lambda to expose the graphql APIs (https://aws.amazon.com/lambda/)
- we need to determine in which versions (i.e. milestones) we want to show the deployment on an actual automotive embedded platform and a cloud-based service infrastructure
- Philippe: will add this into the Jira backlog
Dissemination - Automotive World Webinar
- Philippe: GENIVI has an opportunity to deliver a new Webinar in the Automotive World Webinars series
- short discussion on whether to deliver it before or after the upcoming virtual tech summit
- (added offline): Mike N (marketing manager) already blocked a timeslot on the 4th of May
- Kevin V is interested in helping for the preparation and delivery of the webinar
Monday, March 30 - Vehicle Data
Agenda:
- /TODO/ all CCS participants to review the Geotab document on EV data access requirements
- value measurement formats
- communication framework: discussion with Sanjeev
- sprint review (skipped)
- AOB
Participants
- Keith, Kevin V, Ulf, Benjamin, Gunnar, Philippe
- apologies: Guru,Gerald, Glenn
Minutes
review of the Geotab document on EV data access requirements
- Benjamin: shows a document comparing the content of the Geotab document and the content of the Data Categories wiki page
- discussion on use cases vs requirements
- Ulf: the Geotab proposal does not propose the current charging power, but only the accumulated power, Geotab is more interesting in the energy than the power (one is the integral of the other overtime anyway)
- Kevin: the biggest difference between the Geotab doc and what is is in the wiki is that Geotab is interested more in aggregated data resulting from some data analysis than in the raw data, IMHO we need to update the data categories with Geotab inputs
- /TODO/ Benjamin to update data categories with Geotab inputs,
CCS-24
-
Getting issue details...
STATUS
commented and assigned to Benjamin
- short discussion on the updating of VSS tree with EV signals, based on the comparison made by Benjamin
- /TODO/ Benjamin to identify a few VSS signals that could be added to the VSS tree,
CCS-89
-
Getting issue details...
STATUS
created and assigned to Benjamin
value measurement formats
- Gunnar: shows the modifications of Value measurement formats wiki page he made since last Monday call
Keith: remark on VIN number vs MAC address
- Gunnar: I use here the VSS defined VIN
Gunnar: details the record types and subtypes
Ulf: do you envision this to be on top of Gen2 ?
Gunnar: this should be on top of every single protocol we want to use
Ulf: agreed, Gen2 is one protocol (the only one for the time being)
Ulf: IMHO this translates partially into subscribe requests on Gen2
Gunnar: yes, the subscribe request is close to what I explained here
Gunnar: my expectation is that all participants this wiki page and check whether the naming of the various items described is appropriate
Ulf: I will look into this,
CCS-91
-
Getting issue details...
STATUS
created
Kevin: likes it a lot, it is a very comprehensive set of definitions, are these definitions independent of the data models ?
Gunnar: yes
Kevin: CVIM & Sensoris touched this a little bit, job and streams are a litthe bit independent from the other definitions
Ulf: Kevin pointed out a very crucial thing, how do we structure the storage in the cloud VSS tree, we need to complement the values with time dimension & VIN dimension ?
Ulf: it is quite complicated to come up with the best solution
Gunnar: agreed, this is not trivial
Kevin: it is good to define various layers like time series, etc.
Gunnar: we need to analyse how this work can influence the definition of the database schema
Gunnar: any volunteer for the review of this ?
Kevin: I will look at it,
CCS-92
-
Getting issue details...
STATUS
created
Gunnar: I will look into Sensoris and CVIM afterwards
-
CCS-90
-
Getting issue details...
STATUS
created for tracking the update of Value measurement formats wiki page
communication framework
- Philippe: Gunnar and I had a discussion with Sanjeev (Samsung) about the vehicle client implementation, Sanjeev was informed of the roadmap until CES 2021
- Sanjeev: will start on the vehicle client implementation in Go and should be able to show something for the GENIVI Virtual Meeting in May
- Philippe: objective is to start the implementation work this week
AOB
- Asian friendly call: in order to facilitate the sync with Sanjeev who is based in Seoul, South Korea, an additional CCS weekly call will be scheduled on Mondays at 11:30am CET
Wednesday, March 25 - Communication Framework
Agenda:
- W3C virtual meeting - CCS presentation
- Communication Framework PoC - WBS update
- AOB
Participants
Kevin V, Kevin de Sousa, Keith, Gunnar, Philippe
Minutes
W3C virtual meeting - CCS presentation
- Gunnar presented the CCS projet in the W3C virtual meeting which is happening this week
- OEM attendees provided a very positive feedback on the CCS PoC block-diagram: "this CCS work is right in the middle of what the industry needs"
- we might get additional support for developing the PoC and make it a reference implementation
- recommendation is to decouple all boxes of the block-diagram as much as possible so that there is no vendor-locking for OEM customers, all parties should be enabled to pick up their own boxes and implement them according to the standardized APIs
Communication Framework PoC - WBS update
- continuation of the review of CCS Proof-Of-Concept - Work Breakdown Structure, wiki page updated online
- component #1 - in-vehicle storage
- component #2 - in-vehicle VSS2 translation (a.k.a. VSS feeder)
- we need to set up a call asap with Bosch to determine what could be reused from Kuksa project and to discuss the model transformation tools (VSS-to-Franca and Franca-to-ARXML)
- /TODO/ Philippe to contact Bosch (Sebastian and Christian) for setting up the call asap
- discussion on the simulator that might be used to feed simulated data in the poc
- Keith: presents shortly the LGE simulator
- the simulator is based on unify and can be run using ROS and be interfaced with AutoWare (https://www.autoware.org/) and Apollo (https://github.com/ApolloAuto/apollo)
- the simulator provides driving itineraries corresponding to big chunks of San Francisco
- the simulator needs to run on a very powerful desktop, it might be appropriate for a CES kind of demo
- Philippe: the LGE simulator could be an option for the milestone #4 of the CCS PoC (demo at CES 2021)
- Gunnar: what do you mean by interfacing Apollo ?
- Keith: you can run Autoware or Apollo to enable the execution of open source ADAS stacks
- component #4 - OEM cloud - vehicle client
- there are several options for this implementation
- curl scripts proposed by Gunnar are only a plan C or higher for the implementation, other options are to be analyzed first
- short discussion on open source licence
- Keith: would prefer Apache 2.0, MPL 2.0 copyleft is much too strong for the automotive industry (e.g. vsomeip used by Adaptive Autosar demonstrator)
- Gunnar: currently, we are doing our shopping list for the poc based on existing components
- Gunnar: it is only if new components are developed and hosted by GENIVI that the question of the open source licence needs to be analyzed, anyway GENIVI has a list of "green" licences and is not limited to MPL 2.0 if necessary
- component #8 - OEM Cloud (Resource Management =) Data server API
Gunnar emailed Adnan (BMW) and Daniel (BMW) to get some clarity on their GraphQL work
Philippe: Alex (BMW) showed the work on GraphQL he did for the AASIG EDS PoC yesterday, his work might also help with this
Next steps
Philippe: we need to start thinking about the identification of APIs that could be standardized
Gunnar: we are at a very early stage, i.e. first iteration of the PoC, the identification of APIs will take time and several PoC iterations
Gunnar: I would propose to start a design justification wiki page for the poc where we can capture the rationale for selecting the components (currently the number one criterion is that the component exists)
Philippe: reminds about the following wiki pages Big Picture & Design concerns that might contain some useful inputs
Gunnar: there is this wiki page Vehicle data exchange protocols
Gunnar: I have also created the following wiki page Value measurement formats, the content was reviewed with Unknown User (benjamin_klotz) during Monday's vehicle data call and then augmented, it would be good you read it
- /TODO/ CCS participants to review the wiki page Value measurement formats
- Philippe: next week we need to go through Jira and do a sprint review and we need to kick-start the implementation work
GENIVI Spring Virtual Technical Summit
- the virtual tech summit will be organized as half-a-day workshops scheduled to be either at US-friendly time or Asia-friendly depending the expected geo-location of the main participants
- Tuesday 12 May afternoon (US friendly): president's keynote and state of the union followed by a couple of sessions about "looking forward" topics
- Wednesday 13 May afternoon (US friendly): AASIG VHAL engineering workshop (3 hours)
- Thursday 14 May morning (Asia friendly): AASIG Audio HAL engineering workshop (3 hours)
- Thusday 14 May afternoon (US friendly) : Cloud & Connected Services engineering workshop (3 hours)
- this is still TBC but please make a note in your calendar
Monday, March 23 - Vehicle Data
Agenda:
- review of TODOs
- /TODO/ all CCS participants to review the Geotab document on EV data access requirements
- /TODO/ TBD (Benjamin ?) to compare Geotab doc on EV data requirements and the content of the data bundles wiki page
- /TODO/ Rex to review the Adaptive Autosar signal-to-service specifications
Participants
15:00 CET call: Benjamin (W3C), Gunnar, Philippe
16:00 CET call: Keith, Kevin V, Guru, Philippe
Minutes
First call
Second call
- /TODO/ all CCS participants to review the Geotab document on EV data access requirements
- Philippe reminds this TODO to participants, Kevin will look at Geotab document this week
- /TODO/ Rex to review the Adaptive Autosar signal-to-service specifications
- Philippe asks Keith (who knows well the Adaptive Autosar stack) whether he could provide an overview of the signal-to-service specifications to the CCS team
- Keith: will do,
CCS-88
-
Getting issue details...
STATUS
Jira ticket created for tracking
- sync on the communication framework
- Keith was able to join today after a long period of overlapping between CCS call and other calls that prevented him from joining
- Kevin: for the sake of synchronizing Keith with the CCS current status of work, Kevin presents the CCS PoC as described in CCS Proof-Of-Concept - Work Breakdown Structure
- Keith: asks how we can get the gps position of a fleet of cars using the communication infrastructure proposed in the poc
- Kevin V / Philippe: we might have different variants of the poc depending on whether we simulate the vehicle data or we use existing devices like the Geotab Go device if we want to connect to actual cars
- Philippe: for the vehicle simulation, two options have been discussed in the GENIVI AASIG project which is also working on a poc : either using the vehicle simulator published by JLR on GENIVI gitub (genivi-vehicle-simulator repository) or using opends
- Keith: indicates that LGE Labs in the Silicon Valley have also a vehicle simulator
- Philippe: although we will start with laptops as execution targets for the poc, we might switch to automotive boards for the in-vehicle segment of the poc in the future, FYI Renesas has set up a lava-based test farm (with R-Car boards) to build and run the GENIVI CI process, we could use the test farm to simulate the vehicle segment
- Keith: FYI Adaptive Autosar has decommissionned their test farm and runs the CI process on qemu only
- Philippe: invites Keith to the second call of the week which is dedicated to the communication infrastructure
Wednesday, March 18 - Communication Framework
Agenda:
Participants
Ted, Kevin V,, Kevin de Sousa, Ulf, Gerald, Stephen, Gunnar, Philippe
Minutes
Communication Framework PoC staffing & WBS update
- Philippe: reminds that it is now time for the team need to pick up some of work items for the CCS PoC implementation,
- Ulf: I can take over the data server, and its connection to the state storage in the in-vehicle OS box, I am also interested in the data lake
Kevin: we can provide sample applications for the 3rd party service and neutral server marketplace boxes, i.e. entities that will consume graphql apis
Philippe: what about the OEM cloud box ?
Gunnar: we need to determine the signals and the use cases we want to show
Kevin V: we should show different data categories including big data chunks
Kevin V: showing anonymized data is not really possible because this requires a lot of data, it would be better to show different categories
- short discussion on the demo use cases
- Philippe: explains the use cases selected by the AASIG for the PoC demo (EV data, speed & tyre monitoring and air conditioning
- need to add the use cases definition work item
Gerald: I might be able to pull in someone in the in-vehicle OS box , I will ask Sebastian and Christian whether they could recycle something from the kuksa project for the state storage
Gunnar: we need to agree on the format for storing values, e.g. time stamps and values of different types
Gunnar: I would like to get an example of a query for getting multiple snapshots of vehicle data in order to make graphql shine a little bit
Kevin V: if you look at the state of the vehicle, you have a benefit of using a graphql query (get multiple data in one query)
Kevin V: it should also possible to push data with graphql
discussion on the protocols between boxes
Gunnar: I am still waiting for an actual schema for using graphql from someone
Philippe: what about Geotab / Canada ?
Kevin S: I am still chasing what GENIVI is doing, I see myself in a support role rather
review and update of the owner column in the WBS table
Ulf: someone else has to take over the vehicle simulation
Philippe: execution targets will be laptops for the initial implementation
- Vehicle client
- vehicle client: Sanjeev's work does not seem to be directly reusable
- Ulf: the client would be repsonsible for stoting the data into the data lake
- Data lake
- Gunnar: concenring the data lake, do we have a database person in the call ?
- KevinV not on my side
- Ulf: this is where we should try to get BMW in, it won't be a good idea to invent our own database structure
- Ted: their solution is based on VSS/VSSo too, trying to get Adnan to present what he showed at last W3C F2F
- Gunnar: I talked to Adnan yesterda
- OEM cloud
Gunnar: what the resource management is all about in this box ?
Kevin V: resource management comes from the extended vehicle ISO standard
Gunnar: can we replace this naming by "data server apis" in the OEM cloud
Kevin V: agreed
Neutral Server market
Miscellaneous
- Test farm
Stephen: I checked the use of lava farm for running the CCS poc, do you want to use a RTOS in the in-vehicle OS box or linux ?
Gunnar: we can plan for this at a later time, The PoC will be linux-based including the in-vehicle OS box
Philippe: however Renesas could an Adaptive Autosar demonstrator stack in the in-vehicle OS box, this would be good for the demo, it will still be linux-based because the Adaptive Autosar demonstrator is based in RT Linuw
Monday, March 16 - Vehicle Data
Agenda:
- EV data access requirements
- data contracts & data categories
- Bosch Vehicle Abstraction Layer - relevance for CCS
- communication framework - update
- AOB
Participants
Ted W3C (guest), Sanjeev (Samsung), Benjamin (W3C), Kevin Valdek, Glenn, Kevin de Sousa, Ulf, Rex, Gunnar, Philippe
- apologies: Gerald
Minutes
EV data access requirements
- Glenn has published the EV data access requirements document as expected
- the document was shared with Ulf and might be introduced in W3C
- Glenn: underlines the use cases presented in the document
- /TODO/ all CCS participants to review the Geotab document on EV data access requirements
data contracts and data categories
- Gunnar: is looking at the splitting the Jira ticket
CCS-24
-
Getting issue details...
STATUS
as expected
Bosch Vehicle Abstraction Layer - relevance for CCS
- Gunnar: summarizes the discussion with Bosch that happened last Wednesday
- Philippe: reminds the rationale for having a discussion with Bosch (which is organizing a workshop on vehicle abstraction at the AMM)
- Gunnar: there is a need to unify the industry around a so-called vehicle common interface model, I do not know whether we need to mix the data driven like VSS and the vehicle API
- ULf : VSS is good for data decription, service description needs to be added to it, there is also a need to analyze how to map the VSS signals (using the VSS terminology) to whathever is below, ie the different automotive buses
- Ulf: I know thar BMW and Volvo have thoughts about this
- Gunnar: would be happy to get the correct contacts at Volvo (VCC) to pursue this discussion with them
- Ulf: someip to VSS is exactly what VCC has done, Peter Winzell is the one to talk to, he might convince VCC to share some of the work they did
communication framework
- Gunnar: shows the CCS PoC WBS
- Gunnar: aks Sanjeev for clarification on the work he is doing on the so-called clients
- Sanjeev: I limited the scope of my work to the W3C demo shceduled un a couple of weeks time
- Sanjeev: I implemented http and websocket connections for the Tizen watch, we have now the vehicle dashboard on the watch, the java scripts used in this implementation are quite straitghforward but need to be rewritten for better clarity
- Sanjeev the watch code is in the app store, but I intenf to publish the code as well, the web interface is avauable is the daemon folder, the watch interface is pretty much a html interface
- Ted: Magnus from Melco set up the Gen2 server instance on MIT cloud host, the app could point to that
- Ted: has set up a Gen2 server instance for demo purposes
- Ulf: this data server is up and running, it is available but the link to it has not been released yet
- Ted: link is https://www.w3.org/auto/wg/wiki/Vss_data
- Sanjeev: back to the clients I am developing, I want to separate the library interfaces from the UX
- Gunnar: we need to figure out an idea of the demo we want to do, we need to major progress on this actually
- Kevin V: there is a lot of different use cases, that could be used to demonstrate the PoC
- Gunnar: we can work with simple queries, but it owuld be good to have simple queries moving a lot of data in odrer to learn abour possible bottlenecks in our communication framework proposal
- Benjamin: we could reuse what we have introduced in the data bundles
- Rex: do you have at Geotab a document listing all the telematics data ?
- Glenn: I am not aware of it
- /TODO/ TBD (Benjamin ?) to compare Geotab doc on EV data requirements and the content of the data bundles wiki page
- Ulf: asks whether Gunnar can present the CCS PoC block diagram in next week's W3C virtual meeting
- Gunnar: will do
graphql
- Gunnar: I need help from anyone who is familier with it
- Gunnar: we have a limited set of metadata in VSS, VSS is not following a graph and I ask people who proposed graphql what their vision is all about
- Benjamin; graphql in theory works with graphs, it does not perfom as well with trees and taxonomies
- Benjmain: in the case of VSS, you have VSS tree and you look at signals that are spread over the VSS tree, you define schemas for this purpose
- Benjamin: if you want a more complex relationship between signals, the computation you need will be much higher
- Benjamin: please have a look at https://graphql.org/learn/schema/, for querying and pushing data regularly graphql is appropritate
- Gunnar: Example ?
- discussioon on how to represent the vehicle data structure
- Kevin V: do you mean nested relationships ?
- Gunnar: yes for instance
- Gunnar: I would appreciate some hints about graphql
- Ted: Adnan could present some stuff on graphql related to vsso and the graph project, to be followed by Gunnar
AOB
- next week's W3C virtual workshop
Wednesday, March 11 - Communication Framework
Agenda:
- presentation of CCS PoC for Ted (W3C)
- AOB
Participants
Ted W3C (guest), Kevin de Sousa, Ulf, Gunnar, Philippe
- apologies: Kevin V
Minutes
Communication Framework
- Ulf: informed Ted (W3C) about the work we are planning to do on the CCS PoC and invited him to join the call
- Gunnar: introduces briefly the 2 main thrads of activities in the CCS project: vehicle data model and communication infrastructure, then presents the CCS PoC wiki page CCS Proof-Of-Concept - Work Breakdown Structure
- Ted: are you in contact with Graham Smethurs at BMW ?
- Philippe: Yes, there is an action item to talk to him
- Ted: are the CCS PoC aligned with BMW ?
- Gunnar: yes; we are very much aligned on the data server between GENIVI CCS and AASIG projects , and BMW is active in AASIG and promotes graphql there
- short discussion about Sanjeev who completed the Gen2 clients on Tizen (for the Samsung watch), Linux, and Android, Sanjeev seems to be looking at graphql as well (TBC)
- Philippe: I have an action item to contact Sanjeev that we happen to know very well due to former collaboration on demonstrators
- Ted: I talked to John S at Ford recently, Ford is still in the process of making plans concerning the vehicle data APIs
- Philippe: @Ted John delivered a talk in the CCS project track at the GENIVI tech summit of Nov 2019 in Troy, USA, slide deck is here
- Gunnar & Philippe invite Ted to join the CCS weekly calls
- Ted will be added to the CCS mailing list
Monday, March 9 - Vehicle Data
Agenda:
- data contracts & data categories
- Bosch Vehicle Abstraction Layer - relevance for CCS
- communication framework - short update
- Sprint & backlog review
- look at active sprint & backlog of CCS tracker
- AOB
Participants
Ulf, Glenn, Rex, Guru, Kevin Valdek, Gunnar, Philippe
Minutes
Vehicle data model enhancement
-
CCS-77
-
Getting issue details...
STATUS
- Glenn: Geotab EV division drafted a paper containing the EV signals, e.g. charging information, discharge of the battery, etc. when combined with gps and timestamp this data set can solve all the use cases like range vs destination, upcoming load for the charging station, etc., should be published within some days
-
CCS-79
-
Getting issue details...
STATUS
- call with Bosch happened on 11 March, debrief is at the agenda of Monday 16 March call
data contracts & data categories
-
CCS-24
-
Getting issue details...
STATUS
- Gunnar: data categories and data contracts is rather a tool than a result, relates to access control, this topic is also being discussed in W3C
- Ulf: we are talking about data categorization and VSS layers but I cannot see the link between both
- Gunnar: there are 2 ways of representing the categories in the layer concept, VSS layer is a format to represent the data categories
- Ulf: discussion data catzgorization is different from representing the categories for instance using the VSS layer data format
- Gunnar: access control group is one example of data category (TBC)
- Gunnar: data contract is something different
- Ulf: it is a fuzzy concept for me
- Gunnar: I can see the connection, I need to check the Geotab's presentation in W3C team about it
- the presentation is available there
- Gunnar: we need to have common terms on contracts, technical and commercial parameters
- Rex: when you talk about QoS, do you have in mind protocols like DDS and Some/IP (signal-to-service), ARA::COM, some of the building blocks may be there
- Philippe: asks Rex to review the signal-to-service requirements in ARA:COM
-
CCS-87
-
Getting issue details...
STATUS
created
/TODO/ Philippe send to Rex the Adaptive Autosar signal-to-service specification DONE- Ulf: who are the two parties in such a contract discussion ?
- Gunnar: could be the OEMs and the neutral server companies
- Kevin: data providers = OEMs, there is a contract between the neutral server and the third parties (data consumers), the neutral server does not change much the content
- Gunnar: we need a framework / template to write those contracts
- Gunnar: we need to set up a framework for access control
- Kevin: applying data categories to data contracts is the real pain
- Gunnar let separate those two wordings and check whether the industry wants to progress on both topics
- /TODO/ Gunnar structure better the Jira ticket in order to distinguish the work on data contracts from the work on data categories
CCS-24
-
Getting issue details...
STATUS
- Glenn: data contracts in Geotab document mentioned above might not fully be appropriate for the discussion we have here
- discussion on what a contract is all about
Communication Framework PoC - WBS
- Kevin presents the wiki page containing the WBS
- /TODO/ all participants to review the WBS and identify which work item could be taken over
- Gunnar shows
CCS-11
-
Getting issue details...
STATUS
where he added the list of technogolies that could be used for the PoC
- Ulf: regarding the client implementation Sanjeev is doing, Sanjeev will present his work as part of the remote F2F W3C will have at the end of the month, Sanjeev is working on different platforms including an Android app
- OEM cloud: Kevin is fine with Hadoop
- Glenn: we need to remap the data from different OEMs to a common standard, go back to the data guys and talk to them about the pinpoints
- /TODO/ Glenn provide feedback on a possible common standard for next week
- /TODO/ Philippe set up a call with Sanjeev and invite him to follow / join the CCS project
- Rex: IMHO we could set an Adaptive Autosar stack in the cloud
- Philippe: possibly but in my opinion this is for the future, the architecture of the current PoC adresses a mid-term vehicle EE architecture (like the one depicted on slide #4 and marked as "today" of the VAP presentation by Bosch), having an Autosar stack in the cloud corresponfs rather to a future vehicle EE architecture like the one depicted on slide #4 and marked as "smart infrastructure" of the VAP presentation by Bosch
Wednesday, March 4 Communication Framework
Agenda:
- PoC implementation
- how to instantiate the big picture on different vehicle EE / Cloud architectures
- AOB
Participants
Gerald (partial), Ulf, Kevin Valdek, Eex (Saferide), Gunnar, Philippe
Minutes
PoC implementation
Ulf: would like to advertize the prototype Gen2 server implementation we do for the W3C group
Kevin: supports the proposal
Ulf: it is not production level but there is a considerable number of functionalities available
Ulf: error handling is not so resilient yet
Gunnar: agreed, we need to put this into the blue boxes of the big picture diagram, blue boxes named data server could be implemented using the Gen2 prototype
Gunnar: graphql is another option that could be demonstrated in a parallel thread
Philippe: VHAL team is looking at graphql implementation
Gunnar: this is an argumen tor CCS to look into Gen2
Gunnar: what about the clients ?
Ulf: we have small clients available for testing the data servers, Sanjeev (former Samsung) is working on clients
/TODO/ Philippe contact Sanjeev
Ulf: would be good to collaborate with the W3C project implementing the data lake
Phil: would be good to augment the big picture diagram (look at diagram V2 in Vehicle data exchange protocols) with the list of work items and technos used and create a table listing the wok items and the assignees like we did
to contributors
/TODO/ Kevin to add link to possible technologies on the diagram
Ulf: we can use for instance https://github.com/MEAE-GOT/W3C_VehicleSignalInterfaceImpl
/TODO/ Gunnar do the same
-
CCS-11
-
Getting issue details...
STATUS
updated
- Kevin: we need to determine what we use on the OEM cloud part
discussion on the use of Gen2
Gunnar: let determine who will provide the graphql implementation , maybe BMW maybe myself (I have to put some work into it)
discussion on how to align the CCS PoC project and the W3C Gen2 implementation
Gunnar: we all agree to align projects, what we need are resources
Rex: I have a common terminology question, which translation / transformation are you talking about ?
Ulf: BMW has a large number of cars connected today, they do not use VSS format, they use different proprietary data formats
Ulf: BMW took the decision that once these data are in the cloud, BMW will create the data lake using VSS1 or VSS2 and use graphql to do queries
Rex: wonders whether BMW is using the ASAM standard for describing signals
Rex: how is the topic of data compression approach ?
Gunnar: it could typically be done at the transport protocol level
Gunnar: what do you, Rex, mean by analyzing compressed data ? we have not touched this yet
Gunnar: do we need to start looking into OpenID ?
/TODO/ Kevin initiate the WBS table for the CCS PoC from the example provided here by the VHAL project
-
CCS-86
-
Getting issue details...
STATUS
created as a sub-task of
CCS-8
-
Getting issue details...
STATUS
AMM preparation
- GENIVI is currently actively doing the AMM content planning, Steve Crumb (Executive Director) is watching closely the virus situation and a decision to keep the AMM physical vs virtual will happen soon
- the program includes a CCS track with sessions on communication framework and vehicle data model and PoC demo and likely a session called possibly Looking forward: towards a Common Vehicle Interface (TBC)
Monday, March 2 - Vehicle Data
Agenda:
- a use case presented by Gerald
- Data set for EV management
- data contracts & data categories
- communication framework
- Sprint & backlog review
- AOB
Participants
Ulf, Glenn, Gerald, Guru, Kevin Valdek, Gunnar, Philippe
Minutes
a use case presented by Gerald
Gerald shows this slide (Gerald Spreitz please upload the slide), is the CCS use case APP presented here still what we are discussing in the project ?
Gunnar: what do you mean by: is CCS still supporting this use case ?
- Gunnar: at signals level, we can think of signal groups you can get access to
- Ulf: W3C Gen2 could be a potential candidate for a large part of this use case, Gen2 supports both on-board agents and cloud-based agents
Gerald: can you clarify what you mean by the grouping of signals ?
Gunnar: tthis is work-in-progress, my view is that there will be many groups because having a fine granularity is key
Gerald: can the granularity be down to one signal only ?
Gunnar: I wrote an example related to vehicle identification for the VSS layer presentation that gives an idea of what I think is an appropriate grouping
Gunnar: we could look a little bit deeper in the design of this APP use case you presented using Gen2
Gerald: thinks about the monetization of this use case, if you do not provide vehicle data you have to pay for the app
Gerald: we should not forget about the commercial aspects in our work
Data set for EV management
- Gunnar: remember that data set must rather be called naming of signals
- Glenn: this is work-in-progress, expects to have an answer in a week or the rationale for not having an answer and not being able to share the data Geotab use with power utilities
- Glenn: what is important is the rationale of the power utilities for using the signals
-
CCS-77
-
Getting issue details...
STATUS
commented
data contracts & data categories
- Gunnar: shows the data bundles wiki page, reminds about the privacy aspects
- Gunnar: the need has to drive the work, we need to work out a complete access control group first before reworking data contracts and data categories
- Gunnar: do other think we need to work in parallel ?
- Gunnar: elaborates on the EV data the OEMs would like to control the accessibility of (e.g. battery durability relales to warranty cost, etc.), I am sure we will have the mechanisms to handle this
- the data related to this might even not be transmitted because providing those data is not in the business contract
- delivering that data can be done under a contract to specific third parties
- Gunnar: we expect to have the mechanism to control the access technically and businesswise
communication framework
- look at Vehicle Data Exchange Prococols wiki page
- Gunnar: presented the wiki page, are the protocols we discuss enough for what we want to do ? he explains his vision of the work to do as described in the wiki
- Kevin: explains the differences between the latest "big picture" diagram and the initial one
- Kevin: explains he removed the container processing because we use Gen2 now
- Gunnar: here are in my the pieces of the puzzle
- understanding of the big picture
- protocols between compoments
- dig into components
Sprint & backlog review
- the Jira tracker was renamed as CCS (instead of VCS) and updated, look at CCS backlog
- /TODO/ Gunnar to check that the Jira notification scheme is active for the CCS project
- /TODO/ All to check the backlog and current sprint content
- current sprint is until the end of March
- Philippe's expectation is that we will be able to start some PoC activities soon in order to show something at the upcoming Spring AMM (12-14 May)
AOB Privacy
- Glenn: the following topic might be of interest to the team _ Privacy and EU
- Do you know if the organization (or any of the OEMs) are planning to weigh-in on the following ==> The European Data Protection Board (EDPB) releases DRAFT guidelines for processing of Personal Data in the context of Connected Vehicles - and is open for comment --> Guidelines 1/2020 (Comments Due on March 20th)
- links
- /TODO/ Gerald to review the guidelines and provide a summary to the team
- Philippe (added offline): IMHO we need to forward Glenn's question both to the OEMs and the GENIVI security team
-
CCS-84
-
Getting issue details...
STATUS
,
CCS-85
-
Getting issue details...
STATUS
created
Friday, February 28 - Communication Framework
Agenda:
- continuation of discussion started in Monday 24 February call (W3C)
- how to instantiate the big picture on different vehicle EE / Cloud architectures
- AOB
Participants
Gerald, Ulf, Kevin de Sousa (partially joined), Kevin Valdek, Gunnar, Philippe
Minutes
Communication Framework - W3C
Kevin checked Gen2
how Gen2 fits in the big picture: both rest and web sockets
explanation of what the CVIM container processing is all about (some kind of buffering), what happens if the connection is lost
Ulf: this is a good point, there is no buffering in the standard W3C work
Ulf: this requiement has not been put on the table in the W3C team, maybe we should raise the point in W3C, what do you think about it, Gunnar ?
Gunnar: I an more on the solution mode than the standardization side, the container holds the measured values, there are a couple of design options
you can build a function in the protocol itself and request the sequence of data points for the last hour for instance
you can also reuse VSS to represent a sequence of signals
you can also consider a pre-processing of the signals like an histogram in the car, i.e. on the edge, there is some metadata to be transfered to achieve this
Gunnar: we need to identify the boundaries of the W3C protocols and how we can complement / augment this work
Kevin: in today's implementation, the signals are lost (no memory of the sequence of signals), if we assume there is a value storage in the vehicle, we could perhaps send a request for giving the rpm for the last 3 hours
discussion on the data update process, ask for instance for the min/max data for the last couple of hours
Ulf: there is a possibility to use the query we have introduced in Gen2 for such a purpose
Ulf: go the filtering section (gencore.hmtl), you can search more than one node, you can also add metadata, in this context, it is possible to add some functionalities like the one we discussed before (with a time dimension)
Gunnar: it is possible for an OEM to override the metadata of a signal
Next step
- Gunnar: we have some work to do to design the functions that we want: min/max, histograms, etc. and look how we can implement these, either in the query language or in the metadata
- Gunnar: we need to gather the requirements ar the feature level
- Ulf: Geotab has a pattern / method we use for "friends" to minimize the data we keep, the computation draws straight lines between points, we use this method for all data we send from the embedded devices we use
- Gunnar: it sounds that we need a new wiki page describing the data processing features needed
/TODO/ Gunnar to initiate the wiki page DONE: Vehicle data exchange protocols- /TODO/ Kevin to add an update version of the big picture diagram and the description of some components
-
CCS-81
-
Getting issue details...
STATUS
created for tracking
/TODO/ Philippe to send an invite for the Wednesday call DONE
Monday, February 24 - Vehicle Data
Agenda:
- Data set for EV management
- Communication Framework
- Vehicle Abstraction Layer
- CCS project backlog in Jira
- AOB
Participants
Ulf, Glenn, Kevin de Sousa (Geotab), Gerald (Bosch), Kevin Valdek (High-Mobility), Keith (LGE), Gunnar, Philippe
Minutes
Data set for EV management
- KevinV: the data set is not complete and some parties do not want to share all details
- Gunnar: You mean the OEM not wanting to share some of the detailed EV data
- Gunnar: Note that we discussed separating the standardization from the obligation to deliver the data.
- The standards _enable_ data sharing between partners.
- Agreeing on actually delivering the data is more of a business contract.
- We can work on a business framework to enable this
- Gerald: Are there any standards for the agreement on which data is delivered ?
- Kevin: Yes some consent discussions exist but standards are not quite there yet, implementation of connected EVs is not widespread
- Gerald: But do proposals exist ?
- Kevin: Only what is mentioned in Extended Vehicle, to my knowledge (not a lot of details)
- Gerald: So is this an open point to study, for CCS project?
- Gunnar: Yes it could be but for me some of those places where this might apply will naturally "fall out" of further work on the architecture (meaning let's progress the technical architecture a bit
more and maybe later the opportunity to fill those gaps come up) - Kevin: (A more important) missing thing is consensus on what type of data is required for (thid party) features, what actually needs to be shared, to enable a particular service.
- Gunnar: So it ties into data categories and also access control groups might give some of that picture.
- Kevin: Agreed.
- Glenn: (So it's about) data requirements per use case. EV is a good one to start with because for other vehicles connectivity is a nice to have. For EVs it is critical, i.e. know where charging exists, and how/where vehicles exist and where charging is expected to happen (demand for capacity)
- Glenn: Therefore keep progressing the minimal set of data for EVs first.
- Next (added offline by Philippe): there is a need to complement / rework the description of the work items on data contracts and data categories in Jira
- look at
CCS-24
-
Getting issue details...
STATUS
Discussion on vehicle abstraction layer.
- Several people missed this presentation last week.
- Gunnar: I at least need another round with Sebastian to fully grasp what we really mean here.
- Gunnar: In my opinion we should emphasize commonality, not differences.
- Work towards that common interfaces and technology should be used throughout the industry, rather than emphasize that common interfaces are needed / because / common technology / standards are NOT used throughout
- I might be missing details but I'm not really comfortable with the "abstraction" idea proposed by Sebastian
- Next (added offline by Philippe): there is a need to complement / rework the description of the related work items in Jira
- look at
CCS-78
-
Getting issue details...
STATUS
Communication framework
- the high-level block diagram proposed by KevinV is shown
- KevinS: brings a clarification on what Geotab is doing today, Geotab runs a sort of container on their embedded device today
- KevinS: for an OEM, it might consist in running a GENIVI VSS as a so-called container
- KevinS: what Geotab is doing is generalizing the in-vehicle processing with the OEM cloud
- KevinS: the communication between the Geotab device and the cloud is proprierary
- KevinS: the Geotab communication framework architecture currently is very closed to what is shown on the block diagram, the data processing would be very different on the Getoab side
- Ulf: the diagram is quite interesting, but where are the W3C standards mentioned? We see W3C Gen 2 to be also used between cloud and the vehicle
- Ulf: since Gunnar is active in W3C and we are trying to standardize the cloud to vehicle interaction, it would be worth showing this to W3C and discussing the transport protocol and the container processing
- Philippe: explains the approach taken by KevinS to build to this diagram
- Ulf: VISS is the first assumption for the implementaIion, we are now working with the so-called Gen2 in W3C
- Gunnar: Let's see if for every place where it says "REST", we can clarify that we mean "W3C Gen 2 REST", (sync with Kevin V to see if this is the case)
- /TODO/ Kevin V to look at Gen2
/TODO/ Ulf to send the links to Gen2 DONE below are some links to the W3C automotive working group.- Keith: what is VSS 2.0 about ?
- Gunnar: it only just means "next release". It is not a new concept. For now consider the master branch as the content. Sure, there have been some advancement of the syntax, semantics, tooling and vss-layers, but the "2" is not there to indicate a whole new concept.
- Gunnar: clarification brought on how to bring the latest values, VSS define only the isgnals, we need data feeders
- Gunnar: querying the data and ask for their values is something that W3C is not looking into yet, the CCS project is going beyond what W3C is doing
- KevinV: graphQL is another Web technology; BMW has an interest in it in addition to what Google is doing, explains the thinking behind bringing grahQL in the picture
- Ulf: I agree that (the powerful query language of) graphQL is very powerful, it is a perfect technology to work with at the data lake level, however I have some doubt about that approach if you put it in the vehicle,
- Ulf: The interpretation and execution of the queries in the vehicle will put equally a powerful load on the vehicle to answer those
- Philippe: explains the short term to long term of the vehicle EE (look at slide #4 of the EE architecture evolution, in the long-term, we might afford grapQL on in-vehicle HPC nodes (Hogh Power Compute).
- Philippe: The powerful computing nodes in the vehicle might be able to handle it.
- discussion on how to instantiate the CCS block-diagram on vehicle EE architectures. Geotab approach with an embedded device might be appropriate for the short to mid term. However CCS architecture draft proposal for the CCS block-diagram should rather be mapped on an architecture like the one of slide #4 above
- discussion on communication framework architecture will continue on Wednesday call at 5pm CET.
- A calendar invite has been sent
CCS project backlog in Jira
Monday, February 17 - Vehicle Data
Agenda:
- Data set for EV management
- Kuksa project update / Vehicle Abstraction Layer
- AOB
Participants
Ulf (Geotab), Sebastian (Bosch), Gerald, Guru, Gunnar, Philippe
- apologies: Glenn (bank holiday in Canada)
Minutes
Data set for EV management
- Ulf joins today's call following a request made by Glenn, Ulf is in CET timezone, Ulf checked the VSS tree for data related to EVs
- Ulf works rather with the structure of the tree and not on the content
- the tree contains many branches, I did a grep on EV data and found only one file called battery management containing data like temperature, charge status, there is also an charging inlet which is an enum that contains values like AC, DC
- in the drivetrain branch , there is an electric motor branch but with no data in it
- Philippe: who is in the position to complement the VSS tree ?
- Gunnar: complementing the tree is not a W3C process question , we need to spot the identify domain expert to fill the blanks
- Ulf: I agree with Gunnar, we need domain experts from OEMs to get the EV branch populated, I asked Volvo (VCC) before (when I was working with them), and got very small success
- Gunnar: this needs to get into the tree in order to get things move on with EVs
- Gunnar: we will follow up with Sarah (see minutes of CCS call of 10 February) , we can use whatever is available through Geotab devices (connected to OBD port today), since we do not know what is available from the OEMs yet
- Gunnar: a key question with the battery data is that OEMs might not be willing to share the data (e.g. battery capacity) that would be related to battery degradation
- Gunnar: it would be good to check which diagnostic data on battery we could get
- Philippe: what about W3C ?
- Gunnar: Ted is willing to get inputs on EV, but our interest is to get this done faster
- Ulf: if OEMs are reluctant to bring inputs, we might initiate this gathering by asking Geotab for the data they are used to
- Philippe: I will follow-up with Sarah
Kuksa project update / Vehicle Abstraction Layer
- Sebastian presents one slide giving the main timeline of the Kuksa projet and the follow-up project called VAL
- Appstacle project is over
- VAPP is an internal Bosch project, we are allowed to share on it, VAL stands for Vehicle Abstraction Layer
- Eclipse KUKSA.val project contains the Kuksa VISS server that was spinned off as a separate component
- Then Sebastian shows a slide deck presenting the Vehicle Asbtraction Layer concept Bosch is now digging into
- the slide deck contains the well known Bosch slide on vehicle EE architecture evolution (slide #3) and the next step which is the EE architecture extension to cloud connectivity (slide #4)
- the end2end vehicle application architecture (from back end / cloud services) to domain and zone controller is shown (slide #7)
- a so-called Vehicle Application Plugin Platform is identified that would support the execution of Vehicle Services plugins that run on HPC (High Power Computer) nodes and not and deeply embedded microcontrollers
- one example of a Vehicle Service is for instance the the trunk opening (for putting packages in the trunk), the actual implementation is very different among OEMS, having a trunk opening service abstract description would help (look at slides #8-9-10)
- Gunnar: is VSS on the slides ?
- Sebastian: VSS was not there because these slides were a teaser about the VAL project (before kick-off)
- Ulf: will this work suitable for future VSS work ?
- Sebastian: not only one technology is suitable for data abstraction, VSS is one (look at slide #11)
- Philippe: do we need more abstraction beyond the trunk lock and trunk electric drive ?
- Gunnar: the trunk opening abstraction is something like a programming API
- Sebastian: the RPC is an easy question, w.r.t. abstraction, the trunk might be different for a car, a bus or a truck (this last one being very different)
- Sebastian: we can play with the Kuksa implementation of VSS, it is good for playing with the abstraction concepts
- Sebastian: however we do not intend to push the work we did in ISO (TBC)
- Gunnar: I agree that the current state of VSS is not enough to describe a vehicle, the goal in my opinion is that at the end of the road the signals in VSS are actually this
vehicle abstraction layer - Gunnar: the part / model / layer about the trunk opening is a (parallel) project different from VSS in my opinion
- Sebastian: agreed, the VAPP stuff is different from VSS
- Gunnar: I have no problem with the Bosch big picture and having more programming APIs
- Philippe: do you intend to describe the vehicle hardware elements as well ?
- Sebastian: we have signals and RPCs but we do not intend to describe the vehicle hw
- Gunnar: AFAIK Philippe refers to the vehicle configuration, e.g. in infotainment how many speakers do we have ?
- Gunnar: this configuration might be something to add to the VAPP description, what do you think ?
- Sebastian: my opinion is that the hw description is given by some sort of tooling whose role is to describe the "ugly part of the system", the VSS fits well for describing the abstraction
we need - Ulf: I agree that the stuff below should be abstracted, IMHO the tree structure used by VSS is also suitable for describing the "ugly stuff below", a few OEMs are using
the VSS tree to link things together, there is the layer mechanism we are using in W3C to organize/abstract the data that helps this work, but it is OEM specific work that can be
added to the framework - Gunnar: this is the proprietary data base that could be added using the same framework
- Gunnar: it is very unlikely that OEMs will redefine their CAN signals because of VSS, we will need a translation for those signals, however when we move to Ethernet, we could use VSS to describe the data (PDUs) on the Ethernet networks
- Sebastian: so called feeders will push the available data to the live tree representing the car wherever they come from (OBD, CAN, Ethernet, etc.)
- Gunnar: IMHO the live tree you mentioned is the data storage used by the vehicle data server
- Gunnar: today's discussion is helpful, we are synchronizing our vision of the vehicle abstraction
-
CCS-79
-
Getting issue details...
STATUS
Review of TODOs
TODO Glenn review the current EV branch of the VSS database and check whether the data described there are relevant and sufficient for enabling EV charging management / DERMS WIP- Ulf provided his feedback on VSS today (on behalf of Glenn)
- Glenn check to verify that the EV data to satisfy these EV use cases are available in Sarah's presentation
-
CCS-77
-
Getting issue details...
STATUS
TODO Philippe to get back to Sarah to get possible inputs from Geotab on the data used for EV management DONE- Sarah provided the link to her presentation on commercial EV management
Wednesday, February 12 - Communication Framework
Agenda:
- Communication framework big picture
- Next steps
- Review of TODOs
- AOB
Participants
Minutes
Communication Framework
Next steps
- Philippe: IMHO we need now to derive the scope of proof-of-concept work for the communication framework, we might consider organizing a F2F workshop (or a longer telco) for defining the work breakdown structure for this work
- KevinV: my company could possibly provide a contribution on the top left part of the framework ("neutral server marketplace" on the diagram)
- KevinV: IMHO Geotab could possibly provide inputs/code for the bottom right part of the framework ("container processing" on the diagram)
Next call
- next CCS - Communication Framework call will be scheduled on Wednesday 19 February at 5pm CET
- however we might come back to a single CCS weekly call on Mondays later.
Review of TODOs
/TODO/ Glenn to provide the link to the YouTube video presenting an example of data processing / compression on the vehicle side
-
CCS-72
-
Getting issue details...
STATUS
/TODO/ KevinV to draw a rough sketch of of the end-to-end architecture and provide a big picture of the Vehicle2Cloud Communication Framework DONE
/TODO/ Gunnar to provide the link to the 5GAA paper describing the data foreseen in V2V/V2X data exchanges
-
CCS-73
-
Getting issue details...
STATUS
/TODO/ Glenn to provide the links to NHTSA paper on V2V/V2X data exchanges
-
CCS-74
-
Getting issue details...
STATUS
Monday, February 10 - Vehicle Data
Agenda:
- EV data use cases : presentation by Geotab & discussion
- communication infrastructure call schedule
- backlog review (skipped)
- AOB
Participants
Kevin, Glenn, Sarah, Benjamin (partial), Gunnar, Philippe
- apologies: Gerald, Guru, Keith
Minutes
EV data use cases : presentation by Geotab & discussion
- Sarah is senior customer projects manager in EV fleet management at Geotab and works on smart charging
- Geotab has a B2B & B2C smart charging management platform offering
- Sarah delivers this presentation
- The rationale for enabling smart charging through the monitoring of EV data is that the grid is not originally designed for EV charging and commercial EV fleet operators and power utilities expect to improve the charging operations according to different criteria (hence the different use cases presented)
- the consumer use case scenarii (i.e. for passenger EVs) are not distant from the commercial fleet, however there is less maturity in consumer EVs than commercial EVs
- DERMS means Distributed Energy Resource Management System, Demand-Side Management is a subset of DERMS
- Gunnar: we need to define the vehicle data we need for EV management in the VSS database we use in GENIVI for the vehicle data modeling
- Sarah: currently this is no standard wean use and it is a lot of work to do (i.e. to adapt to the commercial EVs our customer use), we are very much interested in standards
- Gunnar: you use the OBD-II port, it is a subset of all electrical data available in the car, in VSS the vehicle data set is much larger, the branch for EV data is very minimal
- Philippe: do you support OCPP (Open Charge Alliance) ?
- Sarah: we support OCPP in our smart charging platform, OCCP is not using a lot of vehicle data, we look at the state of charge in the vehicle only
- Philippe: explains GENIVI objective which is to enhance the VSS database w.r.t. EVs in order to be future proof (because ICE part will decrease in the future)
- Gunnar: this is why we need domain expertise to identify which data need to be added in VSS for EVs
- Sarah: it is not a considerable data set, OEMs have a different level of data than the one we use, fleet managers need less data, the so-called last mile delivery use case is interested in other set of
data, power utilities need only the 15mn average power consumption - Glenn: it is worth noting that with commercial fleet management, the decision making / policy making are focused in the same hands
- Glenn: in the consumer domain instead, the decision making is much more distributed, the policies are much more diverse, deploying DERMS is more difficult (or less mature for the time being)
- Next step
- Gunnar: we need to look at the current content of VSS and see how it matches with Geotab undertanding of the use cases and required data set
- Kevin: the datasets for EV are very limited because the OEMs do not want to share the information about their battery management (and degradation for instance)
- Glenn: we are in a process of mapping the vehicle data we use at Geotab artefacts to the VSS data but the project is not completed yet
- Gunnar: we need to improve the VSS database if necessary, e.g. to allow third parties to have access to some specific dataset extensions
- TODO Glenn review the current EV branch of the VSS database and check whether the data described there are relevant and sufficient for enabling EV charging management / DERMS
Communication infrastructure call schedule
- Next call will on Wednesday 12 February at 5pm CET. A calendar invite will be sent
Thursday, January 30 - Communication Framework
Agenda:
- brainstorming on Vehicle2Cloud Communication Framework
- AOB
Participants
- Kevin de Sousa, Glenn Atkinson (Geotab)
- Kevin Valdek (High Mobility)
- Gunnar, Philippe
Minutes
Goal setting for the call
- Gunnar: which protocols are relevant ? Web protocols (REST), MQTT, NiFi, etc.
- Gunnar: what is the rate for transferring the data ? The framework deal with things like when a piece of data needs to be requested in order to meet the caching freshness goals and when the data flow needs to slow down because a certain part in the flow is getting its buffers filled, caching data when the dataflow goes down (management of the back pressure on the protocols) ?
- KevinV: this is a good starting point
- KevinV: high frequency data cannot likely be supported by REST, because of required refreshing rate, this should be considered in the design of the architecture
- Gunnar: we need to mention edge computing because for some data it is necessary to transform the high volume of data, the data can be pre-processed on the edge (vehicle)
- KevinV: it is even the most complicated part, how are the data captured and processed ? can we influence this ?
- KevinS: everything sounds good, I am comfortable with the discussion so far and can bring experience with other oems in Northern America, there are pros and cons of the different approaches, will a standardized approach be based on edge computing ?
- Glenn: Gunnar brought the idea of having a buffer in the vehicle containing some data that can bring to the cloud some time later, going through dark spots of connectivity
- KevinS: this is the way Geotab devices are working today, we do memory buffers for the different data we are sampling
- Gunnar: AFAIK some data compression can be done by matching data to particular curves (splines)
- Glenn: the techno used by Geotab is presented in a 10mn video available on YouTube, I could certainly investigate whether we could push this to W3C
- /TODO/ Glenn to provide the link to the YouTube video
- KevinS: yes, it is appropriate
- KevinV: in the GENIVI CCS project we want to define a framework and if the inputs you just mentioned are relevant, we want the CCS framework to meet this kind of requirements, we should use VSS as well, we would request Geotab to tell the CCS project whether the features identified for the framework are valid
Deliverables
- KevinV: what could be the project deliverables ?
- Philippe: I agree this is important
- Gunnar: we need to describe a technical architecture and the software components in this architecture
- Gunnar: it is unknown whether we will get a consensus on the architecture among the industry
- Gunnar: we should list all the different users of data and the categories for those data and look at how combining them with the vehicle data
- Gunnar: as far as a deliverable is concerned, we could write a white paper, we need to determine how complete we can make such a paper
- KevinV: for categories, we have some materials, it would be good to have some technical architecture in place for supporting those categories
Backlog building
- KevinV: I can do a rough sketch of the end-to-end architecture and provide a big picture in 2-week time
- /TODO/ KevinV draw a rough sketch of of the end-to-end architecture and provide a big picture of the Vehicle2Cloud Communication Framework
- Glenn: I like the idea of a whitepaper, Geotab could draft a section of in-vehicle data capturing and processing
- Gleen: KevinS could provide some high-level slides on this as well
- Gunnar: we need to identify and list the different categories of data users and the rationale for using these data
- Gunnar: which data (like environment data) could be merged with vehicle data ?
- Glenn: we should take into account the DSRC-based data at intersections, the objective with these data is identify the risk associated with intersections
- Gunnar. We need to identify which data are foreseen in V2V/V2X exchanges, I have in mind a paper written by the 5GAA consortium
- /TODO/ Gunnar to provide the link to the 5GAA paper describing the data foreseen in V2V/V2X data exchanges, there are several papers on https://5gaa.org
- Glenn: NHTSA in the US has projects related to this, they have not decided whether the industry will be going be DSRC or 5G
- /TODO/ Glenn to provide the links to NHTSA paper on V2V/V2X data exchanges
Next call
- It will be likely scheduled on Wed 12 February at 5pm CET provided neither Gunnar and Philippe have an agenda collision in the same timeslot. This will be confirmed
Monday, January 27
Agenda:
- CES debriefing
- vehicle data models: relevance of the specs for EV Charging to our work on data modeling (e.g. OCPP)
- platform candidates for the CCS PoC: are the following platforms relevant : Amazon Auto, MS Azur, Veniam ?
- project organization: add another weekly call to discuss architecture
- Sprint & backlog review
- AOB
Participants
Kevin, Guru, Glenn, Benjamin, Keith, Gunnar, Philippe, Steve
Minutes
EV charging
- Kevin: IMHO EV charging when the vehicle is connected to the charging station is totally in the scope of use cases and specifications defined by a consortium like the Open Charging Alliance. However there is a need to know the status of the EV battery charge when the vehicle is not connected
- Glenn: AKAIK the utilities request the status of EV battery charge for load balancing, I could bring an expert in the call to explain the EV/Power Utility communication use case for commercial vehicles as means possible inclusion by GENIVI in defining 'scope' for EV/Electrical Utility communication requirements - leading to the development of open specifications for broaded use of same.
- /TODO/ Geotab to provide an expert in this area to describe current use cases at Monday GENIVI call. (5:30 CET)
- Benjamin: in W3C VSS, there is a branch on battery capacity but it is empty up to now
- Gunnar: agreed, there is a need to complement VSS on this
- Gunnar: I agree that when the EV is connected to the charging station, this is not a use case for GENIVI, however when the vehicle is OTA, this is in scope of our CCS project
- Kevin: last week we at High Mobility open sourced all of our SDK with a unified set of APIs (based on data we got from BMW/Mercedes/... on the production projects), it might be good to look at data examples available at
- Gunnar: IMHO we should rename this topic to EV management (i.e. something different than EV charging) since we do not overlap with the work on EV charging
- Guru: we need also to clarify how this topic fits with the EV battery management system
- EV charging docs (reminder) - useful links
Communication infrastructure - Platform candidates for the CCS PoC
- Philippe: reminds us it would be good to look at Amazon Auto and MS Azure and Veniam (https://veniam.com/products/) as possible target platforms for the CCS project demonstrator
Kevin: does not know Veniam, will check
Gunnar: we need to undestand what role Amazon would like to play: do Amazon want to compete with companies like Geotab and others or do they simply want to sell infrastructure
Gunnar: IMHO it is time to make a generalization of the infrastructure we have in mind
Gunnar: I would like to know whether the car OEMs are already communicating their data through vehicle neutral servers ?
Kevin: we should organize a call to brainstorm on the communication with others
Gunnar: AFAIK W3C process is a little bit slow, we should organize to make faster progress, we need to put building blocks in place
decision schedule a call for brainstorming on communication infrastructure with Kevin/Gunnar on Thu 30 Jan 11:30am CET (ad-hoc call), Philippe will send a calendar invite DONE
- (added offline): Geotab proposed to provide an overview of commercial vehicle to cloud services use case as an example that GENIVI may choose to include in TBD scope for vehicle/'cloud services' (e.g. Amazon, Microsoft Azure), and development of applicable open specifications to satisfy such use cases. Geotab will join the ad-hoc call to present this.
Data categories
Gunnar: in order to keep things concrete, it would be good to give an example of data categories for VSS signals
Glenn asks for clarification
Glenn will send a note to Geotab/Ulf and asks him to sync with Gunnar on this
Gunnar: the scope of the work proposed is not the same as what Geotab is doing for the W3C VSS PoC but we could reuse the same set of data
/TODO/ Gunnar follow with Ulf/Geotab on providing examples of data categories for VSS
Keith: aks a question on VISS (not captured, apologies)
Gunnar: will provide a clarification
Project organization
- doodle-like table to gather participants' availability for a second call updated online, table is here
- Wednesdays at 4pm CET or 5pm CET are the possible common slots
- /TODO/ Glenn to check whether these timeslots fit with the availabilities for Geotab
- /TO/ Guru to check whether these timeslots fit with his availabilities
- we will make the decision for the timeslot and the periodicity of calls at next Monday call
Sprint & backlog review
- Philippe: will update the backlog and the current sprint content according to latest discussions
-
VCS-68
-
Getting issue details...
STATUS
- Glenn reports on the event he attended in Washington DC last week, this event organized by SAE was about the real-world data collection, 1600 people attended it, including many OEMs; Glenn mentioned GENIVI CSS work in the talk he delivered at the event
- Philippe: reminds us to identify other events in different geographies
AOB
- Due to traveling constraints, Philippe proposed to re-schedule next Monday call at 5:30pm CET
- All: agreed. A calendar invite will be sent.
Monday, January 20
Agenda:
- CES debriefing
- vehicle data models: relevance of the specs for EV Charging to our work on data modeling (e.g. OCPP)
- platform candidates for the CCS PoC: are the following platforms relevant : Amazon Auto, MS Azur, Veniam ?
- project organization: add another weekly call to discuss architecture
- Sprint & backlog review (skipped)
- AOB
Participants
Minutes
CES debrief
- GENIVI showcase: 1400 people attended it, Gunnar & Philippe stood up in front of the GENIVI projects table, slide decks presenting the deliverables recently published were shown on large TV monitors (automotive virtualization platform specifications, vehicle data models overview, FARACON tool). We had discussion with Microsoft, GM and Ford. Very good feedback from the participants
- SAE/GENIVI Connect2Car track: several panels were organized, discussion with Exelon Corp (a US power utility) about creating a WG in GENIVI on vehicle electrification
- first step would be for Exelon to attend the CCS call to discuss the need for vehicle data modeling for EV charging
- Transportation Technology track: Philippe attended a session called IoT and AI Revolutionizing Transportation, participants were Veniam CEO (https://veniam.com), VW Automony CEO (VW subsidiary dedicated to Autonomous Vehicle technology), Dell Technologies and a lawyer from the UK&Wales transportation commission (lawyer was specialized on AV deployment). Veniam CEO presented the 5G-based IOT platform they market to support the vehicle connectivity
- Automotive Exhibition Hall: among many other companies, Amazon Auto had a big booth there and showed many demos, Amazon Auto booth was crowded
EV charging
- docs to look at are the following
- Glenn: power utilities use history of EVs battery charge for balancing the power to supply EVs
- Philippe: IMHO it would be good to look at the public specifications for EV charging protocols and data contents and check for their relevance for the work on vehicle data modeling we have done
- to be further discussed next week
Platform candidates for the CCS PoC
- Philippe: IMHO it would be good to look at Amazon Auto and MS Azur and Veniam (https://veniam.com/products/) as possible target platforms for the CCS project demonstrator
- links pointing to Amazon Auto work
- GENIVI participant from Renesas said Renesas have done various integration projects with Amazon Auto and MS Azur.
- Gunnar: Iin my opinion, it is worth looking at these platforms
- to be further discussed next week
project organization
- Gerald suggested (offline) to have another call for the CCS project to discuss communication infrastructure architecture
- Guru: we need to agree on a one-week period or 2-week period for this additional call
- Philippe: will prepare a doodle-like table to gather participants' availability on a weekly basis, DONE table is here
AOB
- Philippe: we will have a AASIG Vehicle HAL F2F on 4-5 February at BMW, Munich
- Gunnar: started to discuss VSS layers on the W3C mailing list anf got a good feedback, VSS layers will be at the agenda of the AASIG Vehicle HAL F2F, link to VSS layers slide deck is in the minutes of the previous call
Monday, 16 December
Agenda:
- Dissemination: gap analysis deliverable - quick check on publishing
- Data categories - discussion on VSS layers and data categories
- Sprint & backlog review - Spring 6 content
Participants
Guru, Gerald, Kevin, Keith, Benjamin, Gunnar, Philippe
Minutes
Dissemination
- Philippe: gap analysis (actual title is Vehicle Data Models Overview and Gap Analysis) will be published this week together with the GENIVI newsletter
- then the CCS first deliverable will be advertized at GENIVI showcase at CES2020 together with other results, e.g. the Automotive Virtualization Platform Specification and the FARACON tool
- Philippe: reminds the participants to identify events, conferences, projects, forums where we could advertize the CCS work
Data categories - VSS layers :
Sprint & backlog review
- Philippe: shows the current sprint (Sprint 6) content - VCS tracker
-
VCS-48
-
Getting issue details...
STATUS
done
-
VCS-59
-
Getting issue details...
STATUS
it might be good to get back to Cloudera and have a chat with them possibly at CES 2020
-
VCS-39
-
Getting issue details...
STATUS
Gerald indicated that the Kuksa could be able to deliver an update in January, Gerald will propose them to join one of the early Q1 calls - 27 January or 3 February
-
VCS-60
-
Getting issue details...
STATUS
Gerald needs to re-check this topic, look at CCS minutes of Monday, September 23
-
VCS-24
-
Getting issue details...
STATUS
- Philippe: IMHO we need to gather and synthesize all the materials / thoughts we had during Q4, 2019 and produce an updated vision of the end-to-end vehicle data capturing infrastructure
- Keith: is willing to engage into this but needs to do his ramp up first
- Kevin: would like to contribute also, needs more thinking
-
VCS-5
-
Getting issue details...
STATUS
- Benjamin will check the business cases identified by W3C
VCS-70
-
Getting issue details...
STATUS
created
- Gerald will review the existing CCS materials and spot business cases identified in there
VCS-71
-
Getting issue details...
STATUS
created
- Gunnar: reminds that Glenn underlined that some aggregated data might become (privacy) sensitive while the elementary data contributing to the aggregation are not
AOB
- next call is scheduled on January 20, 4pm CET
- Enjoy the break !
Monday, December 9
Participants
Guru,, Gerald, Glenn, Kevin, Gunnar, Philippe, Steve
- apologies: Benjamin, Keith
Minutes
Review of the deliverable:
Data categories / "VSS layers"
- Gunnar introduces the draft slide deck he prepared following discussions with Benjamin and Kevin performed since last week's call
- this document introduces the concept of VSS layers which is a first step towards the communication framework design
- /TODO/ all review the slide deck on VSS layers
- in next week's call, Gunnar will go through the slide deck and answers questions.
Jira tracker
- /TODO/ "it would be good" to review the work items in Jira - link: VCS board
Monday, December 2
Participants
Keith, Guru,, Gerald, Kevin, Gunnar, Philippe, Steve
- apologies: Benjmain
Minutes
Review of the deliverable:
- document updated online
- Gunnar: inputs on Vehicle HAL still WIP (Gunnar)
- Philippe: our objective is to finish the polishing by the end of the week and hand it over to Steve/Traci for post-editing and publishing
- Kevin: some info on Android Automotive stakeholders is provided there
Communication framework design
- Gerald asks about the status of this thread
- Philippe: we need to build on the materials presented by Kevin in the related session of the tech summit, look here
- Philippe: IMHO our objective should be to refine the end-to-end architecture coined by Gerald at the beginning of the project and determine whether we have variants of the architecture depending on the use cases, we need also to detail further how the access to vehicle data is handled depending on various access policies
- Gunnar explains that categorizing the vehicle data is an important preliminary step for the design work
- /TODO/ Philippe & Gunnar organize a call with Benjamin on data categorization (on top of VSS) DONE
- the call with Benjamin was based on the following slide deck
- data categorization will be at the agenda of next week's call
Monday, November 25
Participants
Glenn, Keith, Benjamin, Gerald, Gunnar, Philippe
- apologies: Guru, Steve
Minutes
Review of the deliverable:
- document updated online
- need to add a table comparing the data models per criterion similar to the tables shown by Benjamin at the tech summit on the presentation on data models
- /TODO/ Benjamin add the table(s) comparing the data models to the Google docs document
- Glenn: what is the meaning of gap ? is the gap between protocols or between the data and the use cases
- Gunnar: the gap we have been looking into are more on the gap between protocols (Gunnar Andersson to be confirmed)
- Glenn: I will review the document and possibly add the standpoint of commercial fleet management
Data Categories
- Kevin I created a wiki page to gather information on data categories, link: https://at.projects.genivi.org/wiki/display/DIRO/Data+bundles
- this page is oriented towards the gathering of data categories (called "bundles") and the related use case
- /TODO/ all participants add your inputs on data categories in the data bundles wiki page
Monday, November 18
Participants
Glenn, Amir, Gunnar, Kevin, Keith, Benjamin, Guru, Steve, Philippe
Minutes
Debriefing of Cloud & Connected Services sessions at the tech summit
Project Charter
- Keith: revisiting the project charter would be helpful, in particular identifying the deliverables
- /TODO/ Philippe revise the project charter
Data Models
- Philippe: in my opinion, it turns out that we can proceed with VSS as the baseline data model
- Glenn: VSS is very helpful, there is a need to have a better awareness about having a data model, there is a need to present if in next year's conferences
- Glenn: we need to develop the data required by different use cases
- Gunnar: we would like to put most of the BMW data model into the VSS work
- Glenn: will be bring Ulf who is working with W3C in the conversation
- Philippe: could the identification of use cases be done using the ones identified in Kevin's presentation of the communication infrastructure ?
- Kevin: yes, use cases are also related to the data categories
Data categories
- Gunnar: we need to make categories of data w.r.t. sensitivity of data, privacy, different laws and juridiction
- Kevin: I propose to create a wiki page on data categories
- Benjamin: agreed it does make sense
- /TODO/ Kevin create a wiki page on data categories (for next week's call)
Data aggregation
- then Gunnar presents his notes from the workshop
- Gunnar: VSM we should look over this project , this is about combining the signals into other set of signals
- Glenn: data aggregation is one of the most important use case from our commercial fleet management business
- Gunnar: this relates to vehicle-side algorithms to aggregate data
Miscellaneous
- Gunnar: there is a need for exchanging (short) video in a commercial vehicle context
- Gunnar: it might be wortk looking at the use cases identifed in the 5G whitepaper (several whitepapers listed here, need to find relevant one(s))
- Gunnar: when it comes down to controlling a vehicle, specific remote APIs are likely better than data exchange
- Gunnar: there is a need to look at DDS
- Philippe: this is rather for the GPRO project backlog
- /TODO/ Gunnar & Kevin add notes from the tech summit sessions to the page of wiki minutes
System design
- Kevin: in this session, we discussed actually more fundamentals questions than the design itself like privacy, authorization, etc.
- Philippe: I would recommend we start using the term "policies" when we want to describe the constraints / attrributes attached to a category of data
Data models gap analysis
- Philippe: the participants need to review the google doc containing the gap analysis deliverables
- discussion on how to bring the doc to completenss
- /TODO/ Benjamin write an intro + a conclusion to the doc based on the list of bullet points
- /TODO/ Gunnar write the section on Vehile HAL, i.e. on how to connect the Vehicle HAL to the vehicle data capturing infrastructure
AOB
Tuesday, November 12 - Tech Summit - Towards a common data model
- Partial capturing of the Q&A
- slide deck
- Geotab - Glenn: gives the example of the lidar sensor that can spot available parking spots, can it be part of the VSS ?
- Benjamin: yes, we can model it as an extension
- Gerald: from the lidar, you get only a low-level information which is the distance-to-obstacle and if you look at the map, parking spots are not identified, much more processing is required, IMHO it is a very complex example
- Glenn: the purpose was to propose a use case outside the transportation itself
- Gunnar: reminds the audience about the dynamic agents concept that was pushed by JLR (capabilities to execute some highly-constrained code that can be uploaded on the vehicle)
- Keith: question on sensor description, how to push the VSS to an official standard like SAE/ISO or IEEE, how do we get broader adoption for VSS ?
- Glenn: we need to do dissemination among more OEMs
- FCA: we are looking into this, we are exploring it
- consultant: OEMs are afraid to lose their "secret" data, to get better value for the car, we should look at what other in telecoms did, in my opinion, there is a no secret data
- Gunnar: we need to understand how to write a contract for a data
- Keith: no data is secret, OEMs want to own the data and sell them
- X (consultant): telecom industry tried to keep the data proprietary but failed
- Keith: reminds the safety critical aspects of data
- Keith: why do google move to autonomous driving ? because of the data, Google wants to be in the revenue stream
- Y: VSS is a human readable description, OEMs are currently concerned by the telephone bills, is VSS the right modeling approah ?
- FCA: data means also taking commands from the cloud to the vehicle
- discussion on engineering units
- what are the data actually representing the driver's action on the accelerator pedal ? pedal position or pressure on the pedal ?
- Benjamin: should we include in VSS the AD(Autonomous Driving) vehicle sensors and the brand new IVI features ?
- Alex: I disagree with the way the VSS tree is currently described, I would prefer everything to be described in the vehicle data tree, no proprietrary extensions
- X (consultant): we need to push something useful and comprehensive enough to get accepted
Monday, November 5
Participants
Gunnar, Kevin, Keith, Gerald, Benjamin, Guru, Steve, Philippe
Minutes
Monday, October 28
Participants
Gunnar, Kevin, Keith, Gerald, Benjamin, Guru, Steve, Philippe
Minutes
Connected Services planning of tech summit
Session One: towards a common data model
- Introductory slides and more slides to guide a workshop:
- Define overall goal (* of workshop)
- find a common data model
- include questions to trigger discussion
- the goal of the project itself should be in the earlier overview presentation, but can be repeated
- /TODO/ Keith review the CCS project charter
- Outline from before:
- starting from the data in the vehicle
- VSS intro, AA Vehicle HAL intro
- Report on the gap analysis (Sensoris, etc.)
- Need for consolidating the models: Ask OEMs & participants about it
- Anticipate and think about answers to questions/concerns that come up: (Many new people, some might start from scratch with this standardization idea)
- Hard to standardize on CAN signals
- (find useful subset (already exists in diagnostics),
- => discuss the need for standards on the developer "API" level anyway.
- VSS can be used on CAN/network level but also on the higher levels.
- => Discuss the need to minimize (but maybe not eliminate) data translation across network -> local apps -> cloud → data/statistics users
- Someone might ask: Does the work cover remote Unlock car, start engine, and similar functions?
- =>There is definite resistance to this. Discuss reasons why? Is it security concerns?
- => Do open specifications have a (negative) relationship to cyber-security ? Prepare answer on this.
Keith: IMHO we need to explain we do not look at the downloading of data from the cloud to the vehicle, just upload of vehicle data, it might help breaking some resistance to the standardization of an upload link
- Concerns about that standards may be linked to OEMs being forced to give away data
- -> A controlled (standard) approach will allow handling this likely better than a "wild west"
- CCS can focus, if participants prefer, not on not only technical standards but also anticipate a framework for the commercial contract setups that control the actual live data that is exchanged at any time. In other words: Technical standards are not equal to the data exchange itself
- How to define data items is not the same as the actual data (sensor measurements, user data)
- How is access managed?
- => Fine-grained access control for applications and users of data
- Prepare presentation of access control approaches (technical means)
- => Access control in a Neutral-Server environment (probably input from Kevin)
- Before 10:45am-12:15pm (towards a common data model session) there is the project introduction session. Make sure to address some of the concerns there.
- Data on the internal vehicle level is not the same as outside the car. Both have potential for some standardization but can be done on only one of them too.
- How the choice of technical specification can affect the end result (performance, feasibility of ...)
- Policies for future-proofing (new versions of protocol specifications, and of the VSS itself).
- Discussion: What parts of the VSS-based ecosystem is based on a standard database of named signal, and how large parts are proprietary extensions?
- Example: Oil consumption unit depends on location.
- Units - VSS has losely specified an approach for this as follows:
- Prefer international (SI) units.
- But in some cases non-SI unit is the defacto standard in automotive.
- And in some cases there are no agreed standards.
- Question: Are there some signals that should allow for more than one unit to be fair to all OEMs ? E.g. km/h and miles/h. Some that have a preference extremely strong in some markets? Notable, drivers are in different countries so on the user HMI level, car manufacturers already do a lot of conversion to local preferences. So the problem would remain only on standardization on in-car networks
- /TODO/ Benjamin, prepare material with input from the above, and we can do a final review next week
- Present Gap Analysis results is also a part of this
Abstract of Session One (for reference)
The GENIVI Cloud and Connected Services project intends to define an end-to-end reference architecture between vehicle sensors and the back-end cloud. Essential to this architecture is agreeing to a common method of representing in-vehicle data. This session will provide overviews of the Vehicle Signal Specification (VSS), used in the definition of the W3C automotive working group. It will look at gaps existing with other data models and in the in-vehicle portion of the architecture, explore data in an Android Automotive context and consider ways of consolidating vehicle data modeling approaches
Session Two: The Value of Vehicle Data to Enterprises., Moderated by Keith (LGE)
- FIRST: Keith -- create short intro. (needs input on what the speakers will include, i.e. needs their slides)
- Connection to AUTOSAR? Keith is our liaison
- Session plan:
- Blueprint for Vehicle-Oriented, Data Strategy (Kevin Valdek, CTO, High Mobility) 30 min?
- Unlocking the Value in Vehicular Data Using Analytics (Amir Sayegh, Geotab) 30 min?
- Can we have a coffee break here? Yes (possibly local to this track) Coffee break - plan for 30 minutes
- Industry Standards for Advanced Vehicle Data (John Schmotzer, Emerging Analytics Connected Vehicle Manager, Ford) 30 min?
- Q&A: 30 minutes,
- Coffee break - plan for 30 minutes
- Total time : 150 minutes
= total 30 minutes remains for additional discussion time. - Should be adequate, if we can have the coffee break as planned _before_ the last talk.
Session Three: Capturing Vehicle Data and Communication Framework Design (Moderated by Kevin Valdek, High Mobility)
- Kevin is preparing his inputs following call with Gunnar and Philippe scheduled on Thursday last week
Gap analysis deliverable readiness check
- wiki page is in good shape, some additional inputs or reviews needed
- /TODO/ participants review Benjamin's text on CVIM
- Gerald reported that it seems HERE entered also the field of vehicle data and include also the neutral server concept.
- link: https://developer.here.com/blog/open-location-platform-2.8-release
- Access to vehicle sensor data - the Marketplace can now act as a secure, neutral, GDPR-compliant hub for data consumers to gain access to vehicle data from participating Automotive manufacturers
- Consent management - ensures privacy for owners and drivers of vehicles, by allowing them to grant and revoke consent for specific third-parties to access data generated by their vehicles
- ISO 20078 <https://www.iso.org/standard/66978.html> "ExVe" compliant interface - simplifies platform integration for data providers and consumer
- /TODO/ Guru review Here open location platform content and determine whether this is relevant for CCS and has an impact on our work, identify also a list of questions to be asked to the Sensoris project lead during the 2nd call we are considering have with him
Monday, October 21
Participants
- Stephen L
- Steve C
- Benjamin
- Don Dulchinos
- Gerald
- Gunnar
- Philippe
Minutes
Confirm Tech Summit agenda and participation
Current working schedule:
Tuesday 12 November
10:45am-12:15pm 16:45-18:15 CET | Workshop | 90 | Cloud & Connected Services Workshop Session One Toward a Common Vehicle Data Model (Moderated by Benjamin Klotz, Gunnar Andersson) Abstract: The GENIVI Cloud and Connected Services project intends to define an end-to-end reference architecture between vehicle sensors and the back-end cloud. Essential to this architecture is agreeing to a common method of representing in-vehicle data. This session will provide overviews of the W3C Vehicle Signal Specification (VSS), look at gaps existing with other data models and in the in-vehicle portion of the architecture, explore data in an Android Automotive context and consider ways of consolidating vehicle data modeling approaches. For reference but not posting to the public schedule: - starting from the data in the vehicle
- VSS intro, AA Vehicle HAL intro
- report on the gap analysis (Sensoris, etc.)
- need for consolidating the models: ask OEMs & participants about it
- moderated by someone from W3C (plan A) (Benjamin to look for flights, sync up)
Gunnar (plan B)
|
1:45pm-4:15pm 19:45-22:15 CET | Workshop | 150 | Cloud & Connected Services Workshop Session Two The Value of Vehicle Data to Enterprises (Moderated by TBC Need suggestions for moderator) Abstract: OEMs, suppliers and other industry participants have begun to realize the tremendous potential that in-vehicle data affords to their organizations, their customers and their partners. During this session, participants will hear from Ford, High Mobility and Geotab about the opportunities that vehicle data offers and how the industry can use data analytics to solve real challenges and offer new services. Presentations: - Blueprint for Vehicle-Oriented, Data Strategy (Kevin Valdek, CTO, High Mobility)
- Unlocking the Value in Vehicular Data Using Analytics (Amir Sayegh, Geotab)
- Industry Standards for Advanced Vehicle Data (John Schmotzer, Emerging Analytics Connected Vehicle Manager, Ford)
CONFIRMED all above
|
Wednesday 13 November |
8:30am-10:00am 14:30-16:00 CET | Workshop | 90 | Cloud & Connected Services Workshop Session Three Capturing Vehicle Data and Communication Framework Design (Moderated by Kevin Valdek, High Mobility) Abstract: An essential part of an end-to-end, vehicle to back-end cloud reference architecture is the technologies used in the communication framework between vehicle and cloud. This session will focus on existing standards, solutions and gaps in that essential communication framework to roll-up into the planned reference architecture. For reference but not posting to the public schedule - Kevin as moderator is plan A – Kevin can do it remotely
- Following up with Kevin this week for details
|
Gap analysis document
Reference Design
- Feedback from all other participants
JIRA/sprint review
AOB
Stephen:
Interesting to note CAN XL standard https://www.can-cia.org/groups/technical-groups/technical-committee-tc/ig-layer-12/sig-can-xl/ being developed now.
Monday, October 14
Participants
- Benjamin
- Keith
- Don (OCF)
- Gunnar
- Philippe
- Steve
Apologies
Agenda
- GENIVI technical summit preparation
- Gap analysis deliverable - review feedback of draft sections on VSS, Sensoris, etc.
- Design concerns wiki page - more feedback
- Sprint & backlog review (end of Sprint 4)
- AOB
Minutes
- GENIVI technical summit preparation
- Philippe shows the content that will published on Wednesday this week at 12:00 US Central time
Tuesday 12 November |
9:20am-9:40am | Plenary | 20' | Cloud & Connected Services Overview - Gerald (Bosch) will deliver the overview |
11:00am-12:30pm 17:00-18:30 CET | Workshop | 90' | Cloud & Connected Services - Data Model standardization - towards a common model - starting from the data in the vehicle
- VSS intro, AA Vehicle HAL intro
- report on the gap analysis (Sensoris, etc.)
- need for consolidating the models: we need to ask OEMs & participants whether the consolidation is mandatory or nice to have
- moderated by someone from W3C (plan A) (Benjamin can do it remotely), Gunnar with VSS stuff (plan B)
|
2:00pm-4:30pm 20:00-22:30 CET | Workshop | 150 | Cloud & Connected Services - Value of Data to Enterprises - company presentation by high mobility (Kevin) Confirmed (Kevin will attend remotely, timeslot blocked on his side), what would be the focus on the presentation ?
) - company presentation by Ford (John) on value of data To Be Confirmed topic: engaging the automotive supplier ecosystem and beyond (i.e., other industries) using vehicle data
- company presentation by geotab (Glenn)Steve contacted Glenn who is interested in making a presentation on this topic: aftermarket vehicle data use case
- followed by moderated open dialog with the automotive industry participants
- moderated by TBD: we need a volunteer, please contact Philippe
|
Wednesday 13 November |
8:30am-10:00am 14:30-16:00 CET | Workshop | 90 | Cloud & Connected Services - Vehicle Data Capturing - Communication Framework Design - Kevin as moderator is plan A
- Kevin can do it remotely
|
- Philippe: we expect to have some kind of BoF meetings on Wednesday afternnoon
- Gap analysis deliverable - review feedback of draft sections on VSS, Sensoris, etc.
- Gunnar: has questions on Guru's section on Sensoris, will set up a dedicated teco for it
- Benjamin and Don reminded about their TODOs (see last week's minutes below)
- Big Picture & Design concerns wiki page
- Gunnar: presents the page to Gerald, Kevin and Benjamin who were not at the previous meeting
- AOB
- Keith would like to invite a colleague from LGE in Korea
- Philippe: no issue, please invite him
Monday, October 7
Participants
- Kevin
- Don (OCF)
- Gunnar
- Philippe
- Steve (partial)
Apologies
Agenda
- GENIVI technical summit - content planning, additional information
- https://grpc.io/: is this relevant for CCS ?
- SAREF presentation review
- Gap analysis deliverable - review feedback of draft sections on VSS, Sensoris, etc.
- Design concerns wiki page - more feedback
- Sprint & backlog review (end of Sprint 4)
- Enterprise data value: new topic to be added to the project scope ?
- AOB
Minutes
- GENIVI technical summit - content planning, additional information
- registration link is at https://www.eventleaf.com/TechSummit19ent
- content will be finalized this week, 3 tracks are planned: Connected Services, Android Automotive, Cybersecurity
- quick poll on who will attend
- https://grpc.io/: is this relevant for CCS ?
- g stands for Google
- Gunnar: we look at Google rpc in the GPRO project when we did the survey on communication protocols, look at the list of technologies we looked at and the GPRO white paper
- grprc is built on http2 which never took off, people are rather working on http3, gprc is likely well suited on web technologies, it is one of many choices that are out there
- from my perspective, it is relevant but not more relevant than anything else, when it comes to protocols that are not REST oriented protocols, MQTT has more relevance
- SAREF Automotive - https://www.w3.org/2019/09/trans-data-ws/SAREF.pdf
- Benjamin reviewed the paper presented at the W3C workshop on data models for transportation, his findings on SAREF automotive are here
- use cases identified in the paper are
- Platooning
- Automated Valet Parking (AVP)
- Cooperative Perception Service (CPS)
- Vulnerable Road Users (VRUs)
- Philippe: these use cases fit well into the the future, i.e. much beyond a 5-year horizon
- Philippe: IMHO currently in the CCS project, short term is represented by the current High Mobility offering on the market, and the on-going work is rather looking at the mid-term,
- Kevin: it would be good to ask OEMs what use cases are more tangible to implement
- Gap analysis deliverable - review feedback of draft sections on VSS, Sensoris, etc.
- Philippe: I reshuffled the pages a little bit and the draft deliverable appears now in the main CCS page table of content, look at Vehicle Data Models - Overview & Gap Analysis deliverable
- Philippe: Guru and Benjamin have provided their inputs, Guru added his inputs in the wiki, I added the link the CVIM doc prepared by Benjamin to the wiki page
- Kevin: I reviewed the draft document on VSS prepared by Gunnar, the intro is not specific to VSS but fairly general
- Gunnar: agreed, we need to ask again for the review work the VSS doc
- /TODO/ Daniel/Benjamin/Guru/etc please review the VSS doc
- Gunnar: I will review the Sensoris section written by Guru
- Kevin: I will review the CVIM doc prepared by Benjamin
- Gunnar: Steve pointed us to two other data exchange standards from the Open Group
- I found them to be mostly similar or related to what OCF might be doing. I also found them to be fairly thin specs in particular O-DM but the messaging standard might have something useful
- We are wondering what OCF think about it:
- Is it used by OCF or not ?
- Is it out of scope and covering other unrelated things ?
- or is it overlapping, but OCF have created other standards to cover this instead ? (It might of course boil down to a simple XML vs JSON preference...)
- Unknown User (don.dulchinos) Do you have any feeling on how well these standards are adopted?
- /TODO/ Don review these data exchange standards from the Open Group
- Gunnar: we should consider adding some info on SAREF and the Open Group work in the gap analysis deliverable
- Big Picture & Design concerns wiki page - more feedback
- link added to the CCS main wiki page
- Gunnar: the topics / issues in the design concerns page should be transformed soon in a set of work items described in jira, Kevin has provided his comments already, other comments are welcome until next week call
- I will also review the existing tickets in Jira that might be relevant to the topics described in the design concerns wiki page
- Philippe: I will projectize this in Jira starting next week
- Sprint & backlog review (end of Sprint 4)
-
VCS-48
-
Getting issue details...
STATUS
target date for producing the gap analysis deliverable is 8 November, we will present it at the tech summit
-
VCS-59
-
Getting issue details...
STATUS
/TODO/ Gunnar ping Michael Ger to get a Cloudera architect into CCS project
-
VCS-35
-
Getting issue details...
STATUS
Daniel said he is "back" and should start working on it this week
-
VCS-60
-
Getting issue details...
STATUS
/TODO/ Gerald please do
-
VCS-6
-
Getting issue details...
STATUS
see above design concerns, projectization will be developed further starting next week
-
VCS-61
-
Getting issue details...
STATUS
done, see above
-
VCS-39
-
Getting issue details...
STATUS
no news from Sebastian, Gerald Spreitz can you help ?
- Enterprise data value: new topic to be added to the project scope ?
- Steve: when I met with Ford last week, one of their concerns was how to make value out of the vehicle data
- this is a gap in the CCS project charter according to Ford and GM perspective
- Steve: it seems to me that these organisations do not fuly understand yet what means a shared platform for capturing and distributing vehicle data
- Gunnar: one of the criticisms we had with the European OEMs concept of neutral server is that the OEMs will control all the vehicle data, we do not understand what the enterprise data value means for for the US OEMs yet,
- Steve: theUS OEMs seem to be looking for which strategic partnerships they need to build for the vehicle data
- Kevin: what kind of uses cases are foreseen , what kind of data rates are considered ?
- Philippe: I would suggest to ask high mobility (Kevin) to deliver a company presentation at the tech summit because HM business in my opinion exemplifies what the enterprise data value is about
Monday, September 30
Participants
- Ondrej (OCF Cloud Services)
- Kevin
- Guru
- Keith
- Gerald
- Don (OCF)
- Steve
- Gunnar
- Philippe
Agenda
- OCF (Open Connectivity Forum) Cloud Services WG introduction
- GENIVI technical summit - announcement
- Design concerns wiki page - feedback from participants
- Gap analysis deliverable - status of drafts
- Sprint & backlog review (skipped)
Minutes
- OCF (Open Connectivity Forum) Cloud Services WG introduction
- Ondrej works for Kitsler, a sensor manufacturing company https://www.kistler.com
- Ondrej shows a slide deck on OCF Cloud WG, Device API for Cloud Services, Cloud API for Cloud Services
- Philippe: IMHO the OCF cloud services are to be added as a possible cloud-based framework for poc development & end-to-end integration in the later stages of CCS project
- Gerald: can we possibly clarify about the mapping of the OCF cloud services to the automotive use cases ? with vendor A = BMW and vendor = GM for instance
- Ondrej : my car is one of the devices, when I sit in my car, I can see my local (home) data
- Guru: is there a limitation on the number of vehicles connected ?
- Ondrej: the implementation is fully scalable
- Ondrej will share the slide deck and the API specifications with GENIVI (how to share these materials with the CCS participants is being checked)
- GENIVI technical summit
- Philippe: announces the date and location for the tech summit - Tuesday 12 and Wednesday 13 November, in Troy, Michigan, USA and outlines the tech summit content that will focus on Android Automotive SIG, Cloud&Connected Services and Cybersecurity for the Vehicle
- Steve: has spent last couple of weeks reaching with Ford, GM and FCA, metwith Ford alrealy and will meet with GM on Friday this week and later with FCA
- Steve: the CCS project charter is close to what Ford thinks about where the market is going
- Steve: our objective is to engage those OEMs (and their suppliers) in working sessions about the CCS project
- Philippe: please all of you put a note in your calendar and check your travel plan ! thanks
- Design concerns
- Kevin provided his inputs as comments to the wiki page, look at Big Picture & Design concerns, comments are reviewed online
- Kevin: the wiki page is a very good thread opener
- discussion on Kevin's first comment on the protocols, actually rather on the different ways of performing the data capturing from the vehicle to the servers
Gunnar: on the protocol for Vehicle => 3rd Party Servers, we need to go out and survey who are the players in the industry and which models of data capturing are acceptable
Kevin: : it's a bit of a different case, it could be brought out separately from the in-vehicle infotainment system to third-party servers, because that's the route the data would take.
Gunnar: presumably, yes, it is like an app getting a direct connection and maybe we leave that out the scope and say that's not part of our infrastructure. But at the same time in order to cover all cases, we should consider these points, see what they mean for us and see if we can relate to them in some way in our specifications because otherwise companies tend to work around it anyway, and they end up doing ad hoc things that we might be able to avoid if we actually cover it in our discussions
Kevin: actually vehicle to third-party servers connection comes down to connecting to devices or devices in general like a smartphone, this is the obvious example of having a direct access from my mobile device or an application in a mobile device to the onboard systems, that's more of the typical MirrorLink type of solutions, but it is true there is a lack of data protocols there and if this is VSS that the Vehicle Gateway is using and if these are VSS data that are being uploaded to the cloud, then of course if there is a direct connection with Wi-Fi or Bluetooth from smartphone and the vehicle, it makes sense that the VSS model or a certain data model is used there as well.
Kevin: One more comment in the OEM server to neutral server part, we should add a connection from OEM server to third-party servers or developers as in general the OEMs will provide an API both for neutral servers who serve as intermediaries and directly to third parties, that's already starting to become a common practice and should be considered.
Kevin: I have another comment that relates to the question Gerald mentioned with big data earlier, in my opinion there are certain (or maybe even larger) design impacts of the system considering personalized data, which are more like small data chunks with high frequency and high velocity rather than big data type of sharing between two different services. Probably the system block-diagrams are to look quite different at some components level.
Kevin: in my second set of comments, I added some thoughts about the third-party expectations. This is nothing groundbreaking but more practical things. The callback feature is one thing that third parties expect. Third parties rely a lot on quite up-to-date data. That means that sometimes even one minute old data is not that good because of a business case where you need to act fast on certain data or because of the user experience for instance in electric car charging where you want to get an event as soon as charging is complete.
Kevin: with the VSS and the W3C, I've seen websocket protocols are considered, and the system design should have (when we have a Rest API or an SDK) a callback system with web hooks, this was mentioned also in the OCF presentation. Today a lot of these OEM systems that do provide data don't provide callback systems in general and it is a bit of a headache for third parties. Typically there are different request limits that can be hard to meet at the same time, if there are no webhooks, it creates a problem because third parties want to get the latest data at the same time and the OEMs might limit them with their request limits because otherwise they get too much traffic to the servers. This kind of problem needs to be solved with technology and should be part of the system design we are considering
Kevin: in the last two steps of my second set of comments, I added a few things about the fleets. In general with data sharing, there is a general consent from the owners of the car, this is more for personal vehicles, when it comes to fleets, there are different considerations. If a fleet owner has 1,000 vehicles for instance, the third party application and the fleet owner are the same entity, in that case how that is handled and how the data querying is handled probably should be also part of the overall system design.
Gunnar: I agree with your views, IMHO we should have a list of typical applications / use cases, i.e. something to drive where we need to do different solutions. As you said, the solutions might be different for fleet management applications and user oriented applications. Also what you said about the Big Data statistics being a different one from user-centric data.
Kevin: agreed, I could add a list of use cases in the wiki page trying to cover some different verticals.
Philippe: we need to ask again Cloudera about their inputs of the system design for gathering vehicle big data
/TODO/ Gunnar set up a call with Cloudera to get their inputs of the system design for gathering vehicle big data
- Gap analysis
- Gunnar: shares the draft sections on VSS available at this document and asks participants to review it
- Guru: wonders whether building a huge wiki page containing all the sections of the gap analysis is the right approach
- Gunnar: for the time being, in my opinion, the sections for each project should be structured according to the wiki page table of content
- Guru: will finalize the draft sections on Sensoris accordingly in the document he initiated and will call for a review in one day or so
Monday, September 23
Participants
- Gerald
- Stephen
- Don
- Steve
- Gunnar
- Philippe
apologies: Guru, Kevin, Ondrej (OCF)
Agenda
Minutes
Monday, September 16
Participants
- Keith (LGE)
- Kevin
- Guru
- Don
- Gunnar
- Philippe
apologies: Gerald
Agenda
- Roundtable
- W3C workshop on data models for transportation - Debrief (Steve) (skipped because Steve could not attend the weekly call)
- Sync opportunity with Autosar (Keith, Steve)
- Gap analysis deliverable
- AOB
- system design
- OCF cloud WG
Minutes
- roundtable
- Keith: LGE has an automotive component division, not quite like Hitachi or Yamaha though
- Keith is the only person working on Autosar at LGE, US, Keith's role is to be fully active in Autosar
- 2-3 months ago Keith started raising the awareness around Autosar in the Silicon Valley
- Sync opportunity with Autosar
- during this week's meeting with Steve Crumb, the slides he showed sounded very familiar to me because they were close to what I presented the Cloud Services WG to Autosar sometime ago
- the logical next step is to come with a single standard, in my opinion there is potentially a lot of synergy on the topic of cloud services between the two consortia
- LGE has a particular interest in cloud services
- the possible working mode Steve and I identified would be that Autosar endorse whatever will come out from the GENIVI work
- Gap analysis deliverable
- Kevin will make his contribution by Thursday
- Guru shows the (Word) document he is working on for the Sensoris part, he will import it into Confluence soon
- Philippe recommends Guru to maintain a list of questions to Sensoris, we will have an opportunity to pass them over to Sensoris project lead during the second call scheduled in almost 2-week time
- Philippe changed the status of the Jira tickets related to the gap analysis work
- Gunnar shares the content outline for the VSS part of the document
- Don asks about the status of VSS work and would like to sync with Ted Guild on W3C work
- Gunnar suggests to set up a call with Ted
- System Design
- Gunnar introduces the proof-of-concept for performing the translation from VSS to Franca to Some/IP, bottom-up works better for me
- Philippe: please look at the minutes of the AASIG Vehicle Data API project
- Gunnar; the question is whether we make direct conversions from data specs (like VSS) to protocol like REST or do we go through Franca ?
- Philippe: in my opinion, we should have a list of open questions
- Gunnar Andersson: /TODO/ Gunnar initiate a list of open questions related to system design
- Kevin: I can add to the initial list questions coming from our experience with 3rd parties at High Mobility
- Adjourned: 18:00 CET
Monday, September 9
Participants
- Guru
- Don
- Benjamin Klotz
- Gunnar
- Philippe
Agenda
- Gap analysis deliverable status
- Sprint & backlog review
- Closing of Sprint 3
- additional work items related to Analysis epic to be added to Sprint 4
Minutes
- Gap analysis deliverable status
- assignment of sections to contributors: Benjamin, Guru, Gunnar, Kevin
- Jira tickets updated accordingly CCS-54 to CCS-58
- Sprint & backlog review
-
VCS-24
-
Getting issue details...
STATUS
- Benjamin: this relates for instance work in W3C Data TF, look at https://www.w3.org/community/autowebplatform/wiki/Data_tf
- Gunnar: this is not gap analysis, this is something different, it relates to the glossary / definition of terms, we should create a wiki page describing what these terms mean
- the W3C wiki page above is one input for this ticket
-
VCS-5
-
Getting issue details...
STATUS
- assigned to Gerald for adding a description of the work item
-
VCS-6
-
Getting issue details...
STATUS
- discussion on the functional architecture reference diagram
- Gunnar: the picture is not final yet, it is just an example
- Philippe: we should ask Cloudera for their vision of the big picture for the big data gathering
-
VCS-59
-
Getting issue details...
STATUS
created and assigned to Michael Ger
- Sprint 3 completed and Sprint 4 started
- OCF update
- Don gives an update of his discussions with OCF leaders
- there is a discussion with OCF about the level of membership that should be propose to vehicle OEMS in order to recruit them
- Don would like to have the OCF Cloud WG lead attend next week's call, an agenda item will be added for this
- Philippe: provides clarification on the expected use case to be shown at CES2020 from GENIVI standpoint
- last agenda item: Gunnar Andersson - can you add your notes, since I had to switch over to another call ? thanks
Monday, September 2
Participants
- Gerald Spreitz
- Benjamin Klotz
- Gunnar
- Philippe
apologies:
Minutes
- Call with Sensoris
- very good and friendly atmosphere in the call
- Prokop seems to be quite open for a coordination discussion
- He gave a rough overview od Sensoris including business cases and system architecture, business cases are OEM-related and do not intend to provide an open access to the vehicle
- Sensoris objective is to describe what the car is sensing for the world surrounding it, e.g. number of lanes, road works, traffic signals, outside temperatue (as part of a data set called climate, temperature and weather)
- Gunnar: VSS (was described by Prokop as...) focusing more on the in-vehicle data and SensorIS more on modeling the outside world that the car drives through. We have not been through to compare the data models during the call but there seems to be is some overlap in some areas but not in other like map-related data and data with a location-based focus
- Gunnar: License - Sensoris do not permit derivatives (Using CC-BY-ND). It could be interpreted as they are only body that can launch Sensoris specs, but also means that flexible reuse is difficult. They propose openess to anyone who wants to change the SensorIS spec.
- Unknown: "This is the way they work with Japanese projects"
- Gunnar: Sensoris welcome any proposal that would make their data model more complete, but this proposal would become part of the Sensoris data model because of their licensing approach
- Prokop shows an architecture picture (that includes GENIVI and AGL as a kind of "technology choices" inside of vehicle. Explanation was made about GENIVI Alliance actual scope and current projects.)
- Sensoris main purpose is to make sure that OEMs are not delivering different data, they should deliver the same data
- Prokop said it is out of scope of Sensoris to describe the system and software architecture, however they care about the "how" (e.g. protocols) to some extent
- Gerald: motivation for having a common data model in Sensoris is for instance the wipers model (e.g. 3 bits on the CAN bus)
- Gunnar: Gerald had a quite long discussion with Prokop about how OEMs provide the data, Sensoris does not care about the software architecture OEMs will use, more that the data that comes out is according to some shared standard (so that 3rd party developers can engage with more than one OEM).
- Gunnar: it seems they would reuse whatever architecture is defined by GENIVI
- Philippe: IMHO we should not fight for having an aligment of the data models, we could likely live with some duplicated representation for the data that overlap between Sensoris and VSS
- Benjamin: agreed
- discussion follows on GENVIVI scope vs Sensoris scope, VSS could be considered upstream w.r.t. Sensoris for the data defined in both projects
- another meeting will be scheduled in 4-week time, we need to do our gap analysis between Sensoris and VSS first
-
VCS-35
-
Getting issue details...
STATUS
will be added to the new sprint
- Scrum review
-
VCS-42
-
Getting issue details...
STATUS
done
-
VCS-47
-
Getting issue details...
STATUS
done
-
VCS-31
-
Getting issue details...
STATUS
kept in the backlog, can be activated whenever Don provides us with an update on the OCF Automotive group work
-
VCS-42
-
Getting issue details...
STATUS
done,
-
VCS-52
-
Getting issue details...
STATUS
created, we might be interested in knowing more about the OCF cloud services framework in the future when we start looking at the available technologies for the framework
-
VCS-40
-
Getting issue details...
STATUS
done
-
VCS-50
-
Getting issue details...
STATUS
done, Gerald provided an updated version of the CCS block-diagram highlighting GENIVI components rather than Autosar framework
-
VCS-33
-
Getting issue details...
STATUS
done
-
VCS-35
-
Getting issue details...
STATUS
added to the sprint, new Jira ticket created
VCS-53
-
Getting issue details...
STATUS
with blocking link added
-
VCS-38
-
Getting issue details...
STATUS
updated
- Gerald: IMHO ISO ExVe is not too exciting, performing a gap analysis between ExVe is to be further discussed with Kevin,
- ticket is reassigned to Kevin to determine whether it is worth GENIVI buys the access to the specs from ANSI/ISO,
- Gunnar: then we should likely check the architecture proposed by ISO ExVe can be filled by some components we have identified in the GENIVI communication framework
- Review of remaining items related to Analysis epic in the backlog
-
VCS-3
-
Getting issue details...
STATUS
actually done with the various surveys completed
- tickets to be added to the next Sprint starting on 10 September:
-
VCS-4
-
Getting issue details...
STATUS
-
VCS-5
-
Getting issue details...
STATUS
-
VCS-6
-
Getting issue details...
STATUS
-
VCS-7
-
Getting issue details...
STATUS
-
VCS-24
-
Getting issue details...
STATUS
inputs for this work item will be given by the various gap analysis we have identified
- Gap analysis deliverable
-
VCS-48
-
Getting issue details...
STATUS
updated with subtasks for Kevin, Gunnar, Gerald, Guru, Benjamin, Daniel for describing their contribution to the deliverable, please refer to the GAP analysis outline draft
Monday, August 26
Participants
- Gerald Spreitz
- Kevin Valdek
- Don Dulchinos
- Benjamin Klotz
- Gunnar
- Philippe
Minutes
- Sensoris
- Gerald has contacted the project chairman
- timeslot proposed on Thu 29/8 at 8:30am for a sync call (expected participants: Gerald (call moderator), Gunnar, Philippe, Benjamin),
VCS-49
-
Getting issue details...
STATUS
updated and closed
- Philippe will send an invite once the timeslot is confirmed by Sensoris chairman has confirmed the timeslot
- discussion on the draft content of the gap analysis deliverable prepared by Kevin: Vehicle Data Models - Overview & Gap Analysis deliverable
- discussion on whether to include CVIM in the gap analysis, even though the results of Automat have not been exploited by OEMs which participated to the Automat project
- consensus seems to be there are some good stuff in CVIM that is worth appearing in the gap analysis
- Kevin, Gerald, Gunnar will start populating the deliverable in the wiki
- report from Don on OCF automotive
- Don was not able to sync with OCF staff as expected
- Don showed a slide deck about working mode with GENIVI
- next week agenda: backlog and sprint review
- misc. Benjamin's slide deck on his findings on CVIM are available there
- Adjourned: 17:05
Monday, August 19
Participants
- Gerald Spreitz
- Kevin Valdek
- Michael Ger
- Steve Crumb
- Don Dulchinos
- Guru
- Stephen
- Benjamin Klotz
- Gunnar
Minutes
- Kevin Valdek opened the meeting and welcomed participants.
- Discussing the organization of the gap analysis document...
- Kevin has produced an outline proposal in CCS-48.
- Gunnar has put some ideas into a wiki page
- How do we slice the document. One chapter per compared (data model) covering all characteristics, or one chapter per characteristics/topic covering all data models.
- some discussion, no obvious conclusion - but let's write an outline for clearer proposal we can decide on.
- SC: I would like to see a motivation chapter (for the GENIVI deliverable itself) to clarify document purpose and organization to the reader.
- Gunnar: Seems like we need to rework this a bit with the given input.
- Kevin: I volunteer to propose a (new, detailed) outline of the document
- Kevin will rework the Wiki page that Gunnar started on (because it is now kind of obsolete).
- Gerald: I can report on my action (CCS-28). Yes, overall we think CCC digital key is not much in scope. About car data, they are apparently not planning to create a data model / data taxonomy.
- Gunnar: OK so their main deliverable is requirements, or a design and a programming API? If a programming API, there can be some similarity between an API and a data exchange model, so I would at least take some look (for overlap) if it is an API.
- Gerald: ... yes it seems mostly requirements, use-cases, ... maybe more. I can check a bit more.
- Kevin/Gunnar: We should include them (any organization that falls a bit out of scope) in the report nonetheless, just to document that we have analyzed them and drawn a conclusion.
- Gunnar: Let's go through the JIRA tickets so we don't miss anything
- Kevin: I can do that, I will display...
- VCS 25 - Gerald: I sent a mail to Sensoris chairman about a joint meeting. No answer, need to retry this.
- CCS-50 - (W3C workshop) Steve Crumb: Yes it is confirmed that GENIVI will present the project on the W3C workshop
- CCS-2 This is Philippe's ticket and looks like a kind of overview tracking ticket (An Epic, sort of)
- CCS-33 - (SENSORIS vs VSS) Still open only because the presentation has not been published in the Wiki (Benjamin was reminded)
- CCS-25, Guru working on it. Keep it open.
- CCS-34 - Sensoris vs CVIM. We think we can close the ticket. Overlaps other analysis.
- CCS-38 - Steve Crumb: I have an update. I contacted ANSI via helpdesk. They require us a site license ($1200) to get the specification and we must put limits on the individuals that may read it. How many of you can get your own access via your organization?
- Kevin: I can read the ExVe document.
- Gerald and Guru: Also we can do that.
- ...BMW? (Benjamin can't go on audio, but we assume it ought to be accessible – follow up)
- SC: GENIVI might purchase it only for staff since the limited circulation requirement will in that case not allow us to distribute to the members. Steve will investigate this.
- CCS-39. Kuksa. Gerald will contact Sebastian to see status
- CCS-42. Automat Security analysis. Gunnar: I will try to make sure it is presented to the security meeting this Thursday, as requested. We assume this ticket stays open until then.
- CCS-47. Don: This is on track. I am talking to OCF tomorrow.
- Kevin: Any other business?
- Meeting adjourned
Monday, August 12
Participants
- Kevin Valdek (High Mobility)
- Gerald Spreitz (Bosch)
- Don Dulchinos (eonti)
- Gunnar (GENIVI)
- Philippe Robin (GENIVI)
apologies:
Planned agenda
- Gap analysis deliverable: document owner and contributors, table of content update
- Sprint 2 closing
- Various topics according to JIRA (SCRUM sprint review)
Minutes
- Philippe welcomes Gerald and Gunnar who are back from vacation
- Sebastien Schidlt sent apologies, he will try to join in a few weeks
- Gap analysis deliverable
- contributors
- Gerald: yes, Bosch will contribute, but gap analysis topic is TBD, I need to check with Guru
- Kevin: yes, HM will contribute, quite open about the topic(s)
- Gunnar: yes, I will contribute
- Gunnar: when performing the gap analysis, we will identify new topics to investigate in addition to filling the content of the gap analysis
- Philippe: we are in an agile process, no worries
- Philippe: we need to get Daniel and Benjamin in the loop
- Philippe: I added Androif Auto P.Car to the list of projects we will review, the analysis of P.Car is starting in the Android Automotive SIG Vehicle Data APIs subproject, from this work, we expect to get a gap analysis between what AA provides and what the OEMs need w.r.t. the vehicle data APIs
- /TODO/ Kevin, Gerald, Gunnar initiate a thread offline to decide on the topics assignment,
VCS-48
-
Getting issue details...
STATUS
created and assigned
- Philippe: IMHO we need to start writing now
- OCF update
- Philippe: welcomes Don Dulchinos representing OCF Automotive
- Don: introduces himself, Don is in consulting business - contracted to a security company which is interested in automotiven, tried the OCF Automotive project a year ago, set up an official liaison with GENIVI
- this year has done some work in April/May, OCF has started a cloud interface WG and wanted to set up a liaison with W3C and this took a long time
- in June there was an event in Colorado with JLR and W3C where they discuss to have a poc done, OCF has some interest in it but not strong enough
- then Don organized a call with with Ted and chair of OCF strategy,
- OCF got recently renewed interest in this automotive group: Honeywell (smart thermostats), interested in the connection to the home
- use case: someone is driving to his home and wants to get access to the home for setting thermostats
- Gerald: is there the reverse direction use case ?
- Don: not an Honeywell use case
- OCF is interesting in having a demo at CES 2020, there is also an interop event scheduled before in December
- discussion on demos
- Philippe: timeline for a Cloud & Connected Services project demo is for CES2021, we intend to work before on a gap analysis between various projects working on the vehicle data access and then we will scope and specify possibly a common framework for the vehicle data access and define APIs
- Gunnar: back to OCF demo, what are the companies investigating the cloud APIs in OCF ?
- Don: Samsung, Honeywell for instance
- Gunnar: IMHO OCF would consider joining the GENIVI showcase ar CES 2019, you would need to contact the organiser of this event
- Don: I will talk to the governance of OCF (i.e. companies like Samsung, Intel, Honeywell active in the cloud interface)
- Don: is GENIVI active with the W3C ?
- Gunnar: yes, we are very much active, we have some kind of shared memberships, we work closely with them
- Scrum review
- VCS tracker https://at.projects.genivi.org/jira/browse/VCS
- Sprint 2 completed, Sprint 3 started
-
VCS-28
-
Getting issue details...
STATUS
Survey CCC specifications and check for relevance
- Philippe: IMHO the Digital Key project is not relevant for our CCS project, my interest is in the Car Data project; is it an active project within CCC ? are there deliverables available ? if yes is it worth looking at them ? if yes, we will determine later how GENIVI can access them. assigned to Gerald
-
VCS-48
-
Getting issue details...
STATUS
Assign gap analysis deliverable sections to ownerscreated and assigned (please look at the list of watchers who are expected to engage in the thread)
-
VCS-25
-
Getting issue details...
STATUS
Survey SENSORIS specifications
- Philippe: Guru would like to dig further into Sensoris and check on histograms in Sensoris (as a follow up of last week's discussion on automat )
-
VCS-38
-
Getting issue details...
STATUS
reassigned to Philippe for tracking ISO feedback on the access to the specs
-
VCS-39
-
Getting issue details...
STATUS
Sebastian was poked about providing an update on kuksa project
-
VCS-40
-
Getting issue details...
STATUS
Philippe: following last week's discussion on Automat, we need to point the GENIVI security team on Petar's overview, Petar added to the thread on assignment of the gap analysis deliverable sections
-
VCS-42
-
Getting issue details...
STATUS
assigned to Don, Don will provide an update on OCF on 26 August
-
VCS-37
-
Getting issue details...
STATUS
review CCS project charter Done
-
VCS-49
-
Getting issue details...
STATUS
contact Sensoris and ask for a sync call, assigned to Gerald
- Philippe: Gunnar and I need to go through the backlog and identify which other tickets are to be scheduled in Sprint 3
- Next week call
- Kevin will moderate it (thanks)
- main agenda topic is the assigment of gap analysis deliverables sections to contributors
Monday, August 5
Participants
- Gururaja N (Bosch)
- Kevin Valdek (High Mobility)
- Michael Ger (Cloudera)
- Philippe Robin (GENIVI)
Planned agenda
- 1- Update on automat project
- 2- Gap analysis deliverable: document owner and contributors, table of content update
- 3- Various topics according to JIRA (SCRUM sprint review)
look at active sprint & backlog of VCS tracker https://at.projects.genivi.org/jira/browse/VCS - 4- AOB
Minutes
Kevin moderates the call. Thanks.
1- Update on automat project
- Philippe reports the outcome of the two calls he had with Automat project participants last week
- Renault participant on Wed 31 July
- Automat cybersecurity WP lead (from Trialog) on Tue 30 July (A,ntonio)
- call wirh Renault
VW had the biggest budget share in the automat project (up to 25%)
the VW team involved was from the After Sales division (not from the R&D) and had a very short term vision of their needs
VW interest was on what happened in the vehicle before a failure using histograms, because they wanted to minimize the telecom costs for data transmission and therefore the quantity of data transmitted
there were actually two competing approaches for the vehicle data telemetry in the automat project: histograms for VW vs time series for Renault and Fiat (CRF Fiat R&D), the time series approach consisted in transmitting as many raw data as possible and processing them offline with big computers
At the beginning of the project, HERE proposed to use the Sensoris approach for gathering vehicle data but there was nothing like histograms in Sensoris and this approach was not investigated further
Renault did a proof-of-concept using a dongle to gather the data, VW and CRF decided to use existing ECUs (CRF used an existing TCU (communication box)
At the end of the project the OEMs decided not to continue.
- call with Trialog
Trialog pointed to the following position paper from BDVA (Big Data Value Association), Antonio was one of the main contributors to this paper based on his work in the automat project with a particular focus on the privacy for big data
Antonio mentions also the SAREF work on data ontologies pushed by EU whose motivation is to define and promote a European standard
Antonio mentions W3C / Web of Things (WoT) work whose charter starts with a statement on the ecosystem fragmentation
data privacy / security in automat
the interesting feature of the automat cybersecurity work is that it relies on existing standards (at the time of the project execution timeline)
Antonio said it would be good to review and restructure and update the automat cybersecurity framework according to recent US NIST work that takes into account the product lifecycle (to be shared witl the GENIVI security team)
- Conclusion on automat
Philippe's personal conclusion is that we have looked enough into Automat, unless we have an indication that Autosar will eventually use Automat CVIM as an input to their Cloud Services WG work, we in GENIVI should focus on Sensoris and VSS and ISO ExVe, we will also coordinate with Autosar on this
call participants agree
- Guru: said he will look further into requirements for histograms as defined by automat and check what was not supported in Sensoris
However the work done in automat on cybersecurity is good and relates to a big data architecture, Philippe recommends the GENIVI security team to review it and amend it w.r.t. US NIST work and extract possibly use cases to benchmark the MoRa tool
- Additional information (for Kevin and others)
- yet another proposal from VW
2- Gap analysis deliverable: document owner and contributors, table of content update
- Philippe: said he added P.Car (from AOSP) to the list of projects on Vehicle Data APIs we have to consider for the gap analysis
- P.Car is investigated in the AASIG Vehicle Data APIs subproject which started last week, look here
- Kevin: asked whether we will have one or several deliverables on gap analysis
- Philippe: said he is fine with both approaches, we need an executive summary to provide an overview of the results anyway, the format of the deliverables could possibly followed the one of the technical papers published earlier like GPRO white paper
- Philippe: we need to assign sections / deliverables to contributors and nominate a document owner, we will create the relevant Jira iickets in the new sprint that will start next Monday
- Kevin: said he (and his team) can do a contribution
- Guru: will check with Gerald whether Bosch can do a contribution
3- Scrum review
- VCS tracker https://at.projects.genivi.org/jira/browse/VCS
-
VCS-38
-
Getting issue details...
STATUS
commented and updated, subtask created
VCS-47
-
Getting issue details...
STATUS
on how GENIVI could access ISO specs created and assigned to Steve
-
VCS-45
-
Getting issue details...
STATUS
closing remarks on automat project added
-
VCS-46
-
Getting issue details...
STATUS
table of content for gap analysis doc reviewed and agreed, closing remark added (see above), done
-
VCS-28
-
Getting issue details...
STATUS
we need to find an owner for the review of CCC specs
- we will close the sprint on next Monday 12 August
Monday, July 29
Participants
- Gururaja N (Bosch)
- Kevin Valdek (High Mobility)
- Michael Ger (Cloudera)
- Stephen Lawrence (Renesas)
- Steve Crumb (GENIVI)
Apologies
- Petar Vorotnikov (Visteon)
- Daniel Wilms (BMW)
- Gunnar Andersson (GENIVI)
- (Magnus, Melco - vacation)
- Gerald Spreitz (Bosch) (vacation)
- Philippe Robin
Planned agenda
- Review of the gap analysis deliverable content proposal (all)
- Presentation of a summary of the Extended Vehicle ISO 20078 standard contents
- Various topics according to JIRA (SCRUM sprint review)
- look at active sprint & backlog of VCS tracker
- JIRA kanban is here (Note, Kanban requires login. This browse project seems to currently work for viewing without login. Please request login if you are active participant....
Minutes
Kevin moderates the call. Thanks.
Gap analysis deliverable proposal
- Kevin: the proposal from Philippe is good and we already have most of the necessary information about each project to start
- Guru input:
- For the scope overlap/gap part we can bring in a table structure that we use for comparison
- We can define data characters from one project to another
- We can add information about how each project is being adopted by the industry
- Steve: when talking about deliverables, can we draw experience from the work being done in the Android Automotive SIG? Data topics are being discussed there as well.
- Philippe (added offline) : IMHO we could add P.Car as one of the inputs we need to review, to be discussed at the next meeting
Extended Vehicle ISO 20078 summary
- Kevin presents - key points:
- The ISO standard was published end of Q1 this year. It covers concept and specific requirements for OEMs to follow when providing car data access to third parties via web services
- The standard consists of three different parts:
- Content (resources)
- Security framework
- Access (consent flow)
- The standard does not enforce or recommend any specific car data protocols
- Should be useful for the CS project. To consider: if a deliverable should be compatible with the standard
- Documents are not available in the public domain, but licensed
- Guru:
- There’s a lot of info in the document that is useful: Authorisation, REST API etc.
- As the documents are not in the public domain. Does GENIVI have any type of collaboration with the ISO body, to get access to the information? How could it be done?
- Steve: will investigate if we can get a license
Monday, July 22
Participants
- Benjamin Klotz (BMW)
- Daniel Wilms (BMW)
- Gururaja N (Bosch)
- Kevin Valdek (High Mobility)
- Petar Vorotnikov (Visteon)
- Gunnar Andersson (GENIVI)
Apologies
- Michael Ger (Cloudera)
- (Magnus, Melco - vacation)
- Gerald Spreitz (Bosch) (vacation)
Planned agenda
- Update on CVIM / VSS data comparisons (Benjamin)
- Give feedback and approve project charter (all participants)
- Various topics according to JIRA (SCRUM sprint review)
- look at active sprint & backlog of VCS tracker
- JIRA kanban is here (Note, Kanban requires login. This browse project seems to currently work for viewing without login. Please request login if you are active participant....
Minutes
Gap analysis CVIM vs VSS
Benjamin: there is a lot of overlap between cvim & vss, it would be good to have someone from the automat project in the call
/TODO/ Philippe contact automat project manager & renault (since Renault is one of the project participants)
Sprint review
Monday, July 15
Participants
- Gerald Spreitz (Bosch)
- Michael Ger (Cloudera)
- Benjamin Klotz (BMW)
- Daniel Wilms (BMW)
- Ilios Galil (Obigo)
- Gururaja N (Bosch)
- Kevin Valdek (High Mobility)
- Petar Vorotnikov (Visteon)
- Gunnar Andersson (GENIVI)
Apologies
- Philippe Robin (GENIVI) (vacation)
- (Magnus, Melco - vacation)
- ...
Planned agenda
- review of OADF workshop minutes
- discussion on gap analysis deliverable content
- feedback on project charter
- AOB
- JIRA kanban is here (Note, Kanban requires login. This browse project seems to currently work for viewing without login. Please request login if you are active participant....
Minutes
- Presentation of Michael Ger and other participants.
- Gunnar: I'm hoping Cloudera will provide great input to the "Big Data" flavor of the technical architecture (which likely complements the on-demand protocols like W3C VSI).
- Gerald went through the minutes of the OADF meeting and through that described the different topics that are discussed in that forum.
- Guru presented analysis of current Sensoris work (Analysis document *)
- Benjamin presented AutoMat overview (slide deck *)
* please find links to material from the corresponding ticket in the JIRA project if not provided here.
Over time the material ought also be summarized as results of the project on the parent Wiki page.
Discussion:
- Michael Ger asked for login. Gunnar answered via email.
- Gunnar asked every presenter to update their corresponding JIRA ticket. If anyone is still having issues with login, email Gunnar and/or Philippe (on vacation this week).
- Benjamin's presentation was a little short on time. Decided to follow up next week on more detailed discussion on comparing the data models.
- Gunnar will create a ticket for "gap analysis" accordingly.
Monday, July 8
Participants:
- Benjamin (BMW)
- Gerald (Bosch)
- Guru (Bosch)
- Daniel (BMW)
- Petar (Visteon)
- Magnus (Melco)
- Ilios (Obigo)
- Gunnar
- Philippe
apologies:
Agenda:
Minutes
Monday, July 1
Participants:
- Benjamin (BMW)
- Gerald (Bosch)
- Guru (Bosch)
- Daniel (BMW)
- Kevin (High_Mobility)
- Gunnar
- Philippe
apologies: Petar (Visteon)
Agenda:
- Connected Services project charter
- ISO Extended Vehicle update
- W3C status presentation (Gunnar)
- CVIM review finding (Kevin)
- sprint review
Minutes
- Connected Services project charter
- ISO Extended Vehicle update
- W3C work status
- Gunnar presents the content of the following wiki page Connected Services: W3C VISS/VSI specification status
- discussion on proff-of-concept implementation of the VISS/VSI
- Kevin: is there a general plan/timeline for VSS Gen2 ?
- Benjamin: things will be delayed until the data models for transportation workshop has happened (scheduled on 12-13 September 2019)(look here)
- current WG charter started on May 2018 and will end on June 2020,
VCS-27
-
Getting issue details...
STATUS
commented
- Sensoris
- Gerald shows a slide deck (link TO BE ADDED) from Bosch describing the status of Sensoris work
- Version 1.0.0 of the Sensoris specification will be released in the next days under CC-ND license
- data provided by Sensoris are not only about the vehicles but about the environment
- Version 1.1.0 will introduce the concept of "jobs"
- jobs = login jobs running for a certain period of time for a certain fleet of vehicles
- Gunnar: it would be good to identify how much overlap we have, shows the interest of different domain taxonomies
- Gerald: it would be good also to set up a call with the sensoris project once we have reviewed the Sensoris specification that will be published soon
- AOB
- telco schedule
- DECISION we will start scheduling the weekly call on Monday afternoons at 4pm CET next week (8 July)
- (added offline) cloudera and autonomic.ai which are based on US Pacific coast have been invited to join
Monday 24 June weekly call
Participants:
- Petar (Visteon)
- Gerald (Bosch)
- Daniel (BMW)
- Gunnar
- Philippe
Minutes
Monday 17 June weekly call
Participants:
- Petar (Visteon)
- Kevin (High Mobility)
- Benjamin (BMW)
- Gerald (Bosch)
- Ilios (Obigo) new participant
- Gunnar
- Philippe
Minutes
news
project charter
Philippe is preparing a project charter for advertizing our work, we foresee to breakdown the project into 2 stages
Stage 1 focusing on data, i.e. what we are initiating now with an objective to decrease the fragmentation of the ecosystem with several different approaches to describe the vehicle data and the communication framework to access them
Stage 2 focusing on compute, initial though is to look into cloud computing platform to support mobility and vehicle autonomy
- this charter will be shared with this project participants
- project tracker
- new participant
- Ilios introduced himself, he works for Obigo (Korea) and is their representative in Europe, he is based in Portugal-based representative attended the weekly call, he will be an observer for the time being, we had a discussion on the GENIVI Korea REG
- Gerald: asked Iliol whether there are public funded projects related to vehicle data in Korea
- project status
- we use the Jira tickets of the active sprint
- Kevin (High-Mobility) has reviewed the automat project Commoin Vehicle Information Model and presented his findings
CCS-26 - Survey AUTOMAT specifications (Common Vehicle Information Model - CVIM) In Progressthe model describes big data for connected cars, it is quite different from VSS, it goes very deep in data harmonization and proposes several layers like signals + measurement layer + data package layer
Gunnar: how is it compared to W3C
Kevin: I have not seen the same information than in W3C
Benjamin: we have a metadata Task Force in W3C, it is part of what next generation will do, we will have different kind of meta data, I would recommend to use the best practice, no competition now from W3C because there is no spec on this topic yet
- Kevin will summarize his findings in the wiki
- Petar (Visteon) is reviewing the automat project security model
CCS-32 - Read AUTOMAT security document In Progress - Gerald (Bosch) will spot the colleague within Bosch who attended the OADF conference, objective is to learn about the Sensoris specifications status
CCS-25 - Survey SENSORIS specifications To Do - Gerald: we need to make a comparison between the various data and protocol specifications
sensoris va automat ==> Gerald / Kevin (due date: 3-week time
vss vs sensoris ==> not assigned yet
vss vs automat ==> Benjamin (after submitting his thesis at the end of the month) , Gunnar
- Jira tickets created in VCS
Wednesday 12 June
Webinar on W3C Auto WG & GENIVI collaboration, VSS and Vehicle Data definition future steps
Wednesday, June 12, 1300 CEST
recording
(This call was not intended/schedule and therefore had no official invite. Therefore only had 3 participants, but we still made progress in discussing the needed steps and plans which will benefit the group for next time)
Participants: Kevin, Petar, Gunnar
Using a Etherpad at Mozilla we captured:
Security guidelines
1. Collect and write down Security guidelines
Idea to produce general security guidelines for different parts of the data-oriented parchitecture.
E.g.
- For this API type you should apply this type of security...
- For this data link ....
- Web services and Mobile App requirements are different
- High Mobility has input to give here
- GENIVI Security group could review, if we have something written down
(We discussed to prepare a draft result first since the Sec Team does not benefit from an undefined "open question" at this point)
Data categories
2. Analyze What type of data is needed for different data users?
- Recognize that fine-grained filtering is needed, and mechanisms for it
but here we rather mean:
- Define names of groups of data, and describe them.
...Service classes that need different refresh rates
- Define groups and needs
Data contracts
- Quick intro to discussion in W3C before. It came up because it relates to the definition of the needs of each party. These needs eventually get formalized into contracts and that is the link.
- Grab-bag of tools/questions/terms to define business contracts or more technical contracts
- A kind of checklist...
- Purpose: Simplify business contracts on data, and make sure details are not lost
Tech constraints, technology choices
What are the Technical constraints that are imposed by the used technology?
- Communication paradigm and protocols (pub/sub, req/res, REST, MQTT)
- Middleware and components standing in the data path - caching layer, service layer, service bus
Surveying existing initiatives
- SENSORIS -> await this week's meeting and announcements, and see the outcome before defining actions
- Automat - Data formats and types and similar things are in their specs. Read and consider alignment.
https://automat-project.eu/content/open-cvim-specification
- W3C protocol content (being worked on with participation in group - but summarizing and presenting to the group is useful). Also Webinar tomorrow.
- CCC - have we confirmed there is nothing to reuse or relate to or is this still active? Reconfirm with PR and GS.
- ... follow up with the rest of the list
Question: SENSORIS - which companies can lead the investigation and alignment?
Answer:
- not Visteon - Petar did not reach anyone working with it
- not HM -
- Bosch? ... figure out this list
Terms/names/definitions
Steps:
- Review existing specs, do they include a Glossary
- ... and/or just start writing it down
Collecting Information in Wiki to complete the picture
- Action for all: Populate the Wiki with useful links
- Example of things to link to:
Other Projects
Specifications
Presentations & Videos
Implementations of basic technologies (open source projects)
Do this on the Connected Services home page: https://at.projects.genivi.org/wiki/x/PIAVAg
- AUTOMAT Security document looks useful to read in addition to CVIM spec.
Steps/Actions (current and future to be assigned)
- AI(all): First get projects.genivi.org Wiki account if you don't have it (signup link is this one - it is part of JIRA) This is now changed and the old process should NOT be used: Please read the right column of the Wiki starting page for up to date instructions.
- Read AUTOMAT CVIM specification -- AI: Kevin -- read and summarize, present next week
- AUTOMAT Security document -- AI: Petar -- read and summarize, present next week
Future:
- Look at other AUTOMAT docs - are any other important to read?
Monday 3 June weekly call
Participants:
- Petar (Visteon)
- Christian (BMW) (partially)
- Kevin (High Mobility)
- Rafael (xapix)
- Stephen L
- Gunnar
- Philippe
- apologies: Sebastian (Bosch) vacation
Minutes
roundtable
- Rafael: xapix is a German company based in Berlin trying to create an api automotive platform www.xapix.io
- takeaway from AMM
- Kevin: liked to talk about the standardization of car data, VSS, VSS 2
- high mobility has a different perspective, establishing the framework between high mobility, the car and the cloud
- a lot of different protocols, not only VSS 2 but also several others
- discussion on the various protocols
- Gunnar: at AMM we got a presentation by cloudera on the way data are managed in an automotive api framework (big data architecture)
- Discussion followed on capturing all the different players/users of the architecture. Third-party "app" development API, is that a programming API or "only" the W3C REST-based architecture?
- High level vision on the project scope
- Gunnar: shows this slide deck
- Petar: agrees totally with slides 3&4
- one question on how to describe a behavior/service, need to represent different data types, and how to represent data that is made up of combining data from several sources.
- Gunnar: When it comes to combining signals into more refined data, the VSM project is investigating exactly that. It provides currently a python implementation. This can be useful to run on powerful IT systems, and/or be further refined to a optimized compiled code through code-generation for example.
- look at: GitHub/GENIVI/vehicle_signal_manager
- Kevin: I have a more organisational level, question, is VSS 2 more based on REST ?
- clarification brought by Gunnar on the various topics wip at W3C: VISS, VSS 2, etc.
- Clarifying VSS (Data Model @GENIVI GitHub), VISS v1 (W3C specification, which does also refer to VSS as the (minimum) data that shall be provided. VISS v2 (ongoing, in combination of augmenting VSS v2 to the needs). VISS v2 primarily focuses on adding HTTP/REST but some augmentations of the underlying features and data models happen in combination with this.
- Clarifying differences of work in data definition:
- data-model description (Exemplified by VSS - shared among implementors)
- actual data names and descriptions (Also exemplified by VSS - shared among data providers/users)
- actual data names and descriptions (E.g. proprietary extended VSS additional, e.g. OEM private)
- Notice that VSS provides two different roles - defining HOW to define data, and also WHAT data, but these can be treated separately!
- There is some talk of "other data models" in W3C, not clear if this is just other proprietary data, described in VSS-like format, or if it is described in some other format. Also not clear what those other formats might be. VSS is generally adapted to match the needs that come up.
- The fact that some companies are worried to agree that all data names/descriptions are shared tend to block the discussion. We all understand that some data definitions are unique and private and VSS v1 already described private extensions. We understand that we benefit first from a shared way to describe it, and shared tooling, second that we also can benefit from some data being shared and defined (e.g. any "developer API" *requires* that to be defined at some point), and we also agree that companies may have some own unique and private data. Key point: No part should block progress on any other part.
- Kevin asked about if W3C VISS service covers security access control features. Gunnar answered that it is specified weakly on VISS v1 (but that still allows for implementors to add it), and that in v2 we will see what makes it into the formal specification (timing, progress), but there are some discussions.
- homework
- review the draft workplan and Gunnar's slidedeck
- back to the project naming ==> homework for next week- coin other project names
- AOB
- participation to OADF open conference next week in Munich ==> check whether some of your colleagues are attending it
Monday 27 May weekly call
Participants:
- Petar (Visteon)
- Gerald (Bosch)
- Christian (BMW)
- Benjamin (BMW)
- Gunnar
- Philippe
Minutes
- roundtable
- discussion on the project name, consensus on "connected services"
- Slidedeck
- Gerald went again through the slide deck he presented at the AMM
Slide #3-4:
Gunnar: needs to identify what are the higher level protocols we use on top of radio links
discussion on the roles to play by various organizations for the definition of data containers, many organizations are currently competing on this
Gerald: where is the most interested area for the genivi group ?
Benjamin: I have multiple perspectives on those topics (slide 3), this is a highly fragmented ecosystem
Petar: IoT style communications are more interesting to me, having a connected vehicle does not mean a vehicle is always connected in my opinion
slide 6 - ISO ExVehicle
BMW: does not know who from BMW is involved
/TODO/ each participant find who in their company is involved in ISO work ExVehicle
/TODO/ Philippe contact Kevin to check whether high-mobility is implementing an alpha version of the ExVehicle concept and ask him to join the call
Gunnar: does everyone has the same understanding of what a neutral server is ?
Gunnar: as genivi we need to work on the interfaces between the various parts of the architecture
Christian: agreed, we need to define the interfaces and *do it first*
slide 6 - Sensoris
- slide 7
discussion on how CCC and W3C sync on those topics
Gunnar: in his opinion, this should not be not a constraint for our work
/TODO/ each participant find who in their company is involved in CCC work
slide 8
automat: it is likely a good idea to check this project because there are 2 OEMs involved (VW, Renault) and also there seems to be a comprehensive work on security and privacy
Philippe: IoT - FYI genivi has a liaison agreement with OCF
/TODO/ Petar look into OCF work
Petar: kuksa project is quite comprehensive
Autosar: cloud services - Benjamin discussed this with Sebastianat the AMM
/TODO/ Philippe contact Sebastian (Bosch) about the Autosar cloud services
slide 11
- Gunnar will prepare a slidedeck delivering his vision of what we should work on (in reference to the 5-level ladder shown in the panel on future vehicle electrical architectures at the AMM, look at slide #3 of future EE architectures)
Monday 20 May weekly call
Participants:
- Petar (Visteon) new participant
- Gerald (Bosch)
- Guru (Bosch)
- Gunnar
- Philippe
Minutes
- roundtable
- Petar: works with Visteon Connected Car team, he is a colleague of Giovanni (GPRO project), he is also based in Sofia, Bulgaria
- Petar is the solution architect of the team responsible for the overall architecture of the Visteon platform for connected services
- Petar has 12 year experience in connected services, for the entire stack from infrastructure to Web content end-to-end and for standard compliance
- Petar is currently more on R&D and prototyping than production
- Slidedeck
- Gerald went through the slide deck he presented at the AMM
- Gerald: session went out very well, better than expected, a lot of experience people attended, Melco (Mitsubishi Electric) which is quite involved in W3C was there and showed a lot of interest
- next steps following AMM workshop
- organization of weekly calls (instead of every other week): agreed
- /TODO/ Philippe send out an invite for the calls (starting next Monday) to the genivi-projects mailing list and the list of interested participants gathered at the AMM
- /TODO/ Philippe initiate a wiki page for the project
- feedback from today's call participants
- Petar: workplan is quite interesting, told us he identified interesting work on IoT protocol standardization, the Homie protocol specification that he came across a couple of months ago. Although it is suggested to be home IoT-oriented, it is generic enough to provide structured data interface for IoT communication, which falls in the scope of Car to Cloud.
- link: https://homieiot.github.io/
- Petar: has a question on the authorization work, is it also on the cloud side ?
- Gerald: yes, you are right, something is needed on the cloud side
- Gerald: Daniel Wilms (BMW) expressed his concern about piling up abstraction layers
- Philippe: this has been a recurrent concern from BMW for a couple of years
- Gunnar: thinks this is a no brainer