Cloud & Connected Services Project Minutes

Monday,  March 2 - Vehicle Data

Agenda:

• a use case presented by Gerald
• Data set for EV management
• data contracts & data categories
• communication framework
• Bosch Vehicle Abstraction Layer - relevance for CCS
• Sprint & backlog review
• AOB
  • EU privacy guidelines

Participants

• Ulf, Glenn, Gerald, Guru, Kevin Valdek, Gunnar, Philippe

Minutes

a use case presented by Gerald

• Gerald shows this slide (to be uploaded), 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

• /TODO/ create jira ticket ?

• 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

• wip,
• Glenn expects to have an answer in a week or the rationale for not having an answer
• Gunnar: reminder data set = naming of signals
• Glenn: important is the rationale for using the signals by the power utilities
• >>>>>>>>>>>>>>>>>>>>>>>>>>

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.
  • Homepage:
    https://www.w3.org/auto/wg/
  • GitHub where spec is being developed:
    https://github.com/w3c/automotive
  • Spec directory:
    https://github.com/w3c/automotive/tree/gh-pages/spec
  • Browser enabled spec renderings:
    https://rawcdn.githack.com/w3c/automotive/63ebd2f57f847f5a59dd508dbafcad81a2eba280/spec/Gen2_Core.html
    https://rawcdn.githack.com/w3c/automotive/63ebd2f57f847f5a59dd508dbafcad81a2eba280/spec/Gen2_Transport.html
• 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

• look at active sprint & backlog of CCS tracker

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

• Kevin de Sousa, Kevin Valdek, Gunnar, Philippe

Minutes

Communication Framework

• Kevin Valdek presents this slide that presents the big picture of the Cloud2Vehicle Communication Framework

• this slide was inspired by the work of AASIG project and last week's Geotab presentation
• VSS2 is used for the description of the data content
• it is proposed to re-use the container concept proposed by CVIM to encapsulate the data (the sample code in the box comes from CVIM)
• both MQTT (currently used by various OEMs) and new options (like GraphQL, look at GENIVI AASIG work on the external data server) are used for the communication  between the in-vehicle part and the OEM cloud
• both REST and WebSocket protocols are used for the communication between the OEM cloud, neutral server and 3rd party service
• Kevin de Sousa, Gunnar, Philippe: agree with the architectural design concept for the communication framework preseted
• KevinS: the architecture presented is similar to the Geotab vision and platform. We will review it and provide feedback in the next call.
• /TODO/ KevinS to review the Cloud2Vehicle Communication Framework big picture and provide feedback for next call
  • CCS-62 - Getting issue details... STATUS

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
  • E.g. 5GAA Releases White Paper on C-V2X Use Cases: Methodology, Examples and Service Level Requirementshttps://5gaa.org/wp-content/uploads/2019/07/5GAA_191906_WP_CV2X_UCs_v1.pdf
• 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
  
  • look at active sprint & backlog of CCS tracker
• AOB
  • data categories

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
  • https://github.com/GENIVI/vehicle_signal_specification/blob/master/spec/Drivetrain/BatteryManagement.vspec
• 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
  • charging data: https://github.com/highmobility/auto-api/blob/master/charging.yml
• 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
  
  • OCCP: https://www.openchargealliance.org/downloads/
  • EV charging ecosystem overview: Electric_Vehicle_Charging_-_Definitions_and_Explanation_-_january_2019.pdf

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)
  
  • look at active sprint & backlog of VCS tracker
• AOB

Participants

• Guru, Glenn, Gunnar, Philippe

• apologies: Gerald, Kevin

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
  • OCCP: https://www.openchargealliance.org/downloads/
  • EV charging ecosystem overview: Electric_Vehicle_Charging_-_Definitions_and_Explanation_-_january_2019.pdf
• 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
  • https://aws.amazon.com/solutions/aws-connected-vehicle-solution/?did=sl_card&trk=sl_card
  • https://aws.amazon.com/automotive/customer-engagement/
    • Amazon FreeRTOS = OSS
    • FreeRTOS kernel + 'enablers'. Think relationship between Linux kernel and GNU.
    • AWS Greengrass is other end point: https://aws.amazon.com/fr/greengrass/
• 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
  
  • look at active sprint & backlog of VCS tracker

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 :

• Gunnar shows this slide deck
• short discussion & clarification on the value of VSS with Keith
• Keith would like to understand what else "I need to add if I want to incorporate VSS into Autosar"
• Keith (side note): currently working on installing the Franca2ARA model transformation tool (FARACON tool)

• Gunnar: shows the other slide deck on model2model transformation overview whose title is "manage complex in software system creation" and underlines the transformation flow from VSS (slide #5)

• Philippe: now where do we go next on the path to the vehicle data capturing framework design ? discussion moved to to the Jira backlog review

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:

• document updated online
• /TODO/ Glenn spot the link to the page listing W3C participants in W3C web site (https://www.w3.org/auto/wg/wiki/Vss_data)
• Sensoris participants - link: https://sensor-is.org/members/
• document is close to final

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
  • https://www.welt.de/wirtschaft/webwelt/article193670357/Android-Automotive-Googles-Software-kommt-ins-Auto.html
    https://www.theverge.com/2019/9/5/20851021/general-motors-android-auto-google-infotainment

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

• Kevi: provides the link to "FIA manifesto" related to the Extended Vehicle
  https://www.fiaregion1.com/wp-content/uploads/2019/11/20191113_Manifesto-Fair-Digitalisation.pdf
• follow up with OEMs
  • FCA: Philippe will do the follow-up with them
  • Ford: Steve will do the follow-up with Ford

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

• preparation of Cloud & Connected Services sessions at the tech summit
• review of the slide decks
• look at GENIVI Technical Summit 2019 - Slide Decks

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

• Tech Summit Information and Registration here
• Schedule has been published – link
• Internal planning doc for reference

Current working schedule:

Tuesday 12 November

Gap analysis document

• link

Reference Design

• Feedback from all other participants

JIRA/sprint review

• Kanban board view

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

• Guru
• Kevin

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

• 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

• Guru
• Benjamin
• Gerald
• Daniel

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
    • Open Data Format (O-DF) https://publications.opengroup.org/c14a
    • Open Messaging Interface (O-MI) https://publications.opengroup.org/c14b
  • 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

• W3C workshop on data models for transportation - useful readings

• OCF (Open Connectivity Forum) Cloud Services WG introduction moved to next week !

• OCF Automotive update

• Gap analysis deliverable
• Jira review
• AOB

Minutes

• W3C workshop on data models for transportation - useful readings
  

  • the list of presentations (and slide decks) is at: https://www.w3.org/auto/events/data-ws-2019/schedule.html

  • 2 presentations need to be highlighted

    • Towards A Common Data Model Kenneth Vaughn, Trevilon

    • https://www.w3.org/2019/09/trans-data-ws/ITS_Data_Model-W3C-2019-09.pptx

    • Gunnar: introduces the slide deck, we should review with the comprehensive web site, the work seems to be fairly USA centric and ITS-related and related to fleet operation, we might be willing to take this into account in our work

    • Steve (who attended the workshop): it was an interesting presentation, consolidation of info from various specs, navigable on-line site with connection through various data models

    • slide 10: shows all data models in scope of this work

    • /TODO/ Bosch review the slide deck and possibly report on findings for next week

    • jira ticket created

    • Towards a SAREF extension for Automotive Michelle Wetterwald, Netellany

    • https://www.w3.org/2019/09/trans-data-ws/SAREF.pdf

    • this work was pointed out by one of the AutoMat project participants interviewed by Philippe late July

    • Philippe: it refers to the work on data ontologies pushed by EU whose motivation is to define and promote an European standard

    • /TODO/ Benjamin review the slide deck on SAREF (TBC), Philippe will ask him about it

    • jira ticket created

    • Don: was VSS discussed there ?

    • Steve not in the workshop because VSS was discussed in a W3C auto WG scheduled the days before

    • Don: what about VSSo work ?

    • Gunnar: VSSowork  is led by Benjamin and Daniel Wilms (BMW)

• OCF Automotive update

  • Don: the OCF SC is still considering doing a demo at CES, there is an OCF interop event planned later this year, theme of the possible CES demo will be ratherabout  electrification / charging status in the home

• Gap analysis deliverable - review of drafts

  • Philippe: Benjamin said it will start working on it on Wednesday
    • Gunnar: before I can start writing my contribution, I feld the need to put down my thoughts on the framework design
    • these can be found at Big Picture & Design concerns that shows the different ways we can think about for the framework design
    • Philippe: I would recommend that you review the architecture and building blocks for the neutral server approach with High Mobility because this is their business and the same for the big data approach with Cloudera because this is also their business
    • Philippe (added offline). Kevin said last week he could add to the initial list questions coming from their experience with 3rd parties at High Mobility
    • Gunnar: we need to spot a technical contact at Cloudera (I will ask Michael Ger)

    • Gunnar: we should also dig a little bit into vehicle fleet data management and impact on the "design concerns" content

    • Gerald: this is what Sensoris has looked into

• Sprint & backlog review

  • CCS-59 to be checked with cloudera and engineers there

  • CCS-35 Philippe will ping daniel wilms

  • CCS-6 we should start populating it with work items related to Gunnar's thoughts on software designs, Gunnar: will do that, a link to Big Picture & Design concerns pzge added to the Jira ticket

  • CCS-38 /TODO/ @Kevin can you close it ?

  • CCS-39 Philippe will ping Sebastien about the status of the Kuksa project

• AOB

  • notification scheme in Jira to be checked, Philippe will create a test jira ticket, reminders listed above will be sent by email

  • login Don credentials are working now

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
    • look at
  • 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:

• Kevin Valdek

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"
    • look at the CCS minutes of July 22, link to Japanese projects:  http://en.sip-adus.go.jp/sip/
  • 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:

• Sebastian (Bosch)

Planned agenda

• Gap analysis deliverable: document owner and contributors, table of content update
• Sprint 2 closing
• Various topics according to JIRA (SCRUM sprint review)
  • look at active sprint & backlog of VCS tracker

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

    • link: http://www.bdva.eu/sites/default/files/BDVA%20DataSharingSpace%20PositionPaper_April2019_V1.pdf

  • Antonio mentions also the SAREF work on data ontologies pushed by EU whose motivation is to define and promote a European standard

    • link: https://www.etsi.org/newsroom/press-releases/1620-2019-06-etsi-releases-3-new-ontology-specifications-for-smart-cities-industry-4-0-and-smart-agriculture

  • Antonio mentions W3C / Web of Things (WoT) work whose charter starts with a statement on the ecosystem fragmentation

    • link: https://www.w3.org/WoT/

  • 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
    • look at  Volkswagen Infotainment Web Interface (ViWi)
    • and at W3C automotive big data task force that explains how VSS and ViWI alignment are performed

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)

    •   VCS-45 - Getting issue details... STATUS created

• Sprint review

  • VCS: Kevin has a login and should be to update the wiki eventually

  • current sprint review

    • VCS-25 - Getting issue details... STATUS  survey sensoris spec is done

      • gap analysis between sensoris and cvim is the next step

      • Guru will add a comment and close the ticket

    • VCS-37 - Getting issue details... STATUS review CS project charter

      • Daniel & Petar will review it

      • Kevin approved it a couple of weeks ago

      • Philippe: deliverables will be added to the charter later

  • VCS-43 - Getting issue details... STATUS  Check OADF forum results

    1. philippe will add the link to oadf and  add some comments on what is relevant,

    2. assigned to philippe

    3. The link to the minutes is: https://login.openautodrive.org/downloads/presentations/20190612oadfminutesv10pdf,

    4. For accessing the minutes, you need to ask for credentials on the OADF web page at: http://www.openautodrive.org/

    5. relevant sections of the minutes in my opinion are

       • section 2: introduction to OADF that contains the architecture overview, the OADF aims to be the global platform for sharing knowledge, networking and collaboration between all stakeholders in the AD (Autonomous Driving) realm
       • section  4:  Activities/Plans of Standardization Organizations Regarding AD
         • activities in Japan are presented in the section: http://en.sip-adus.go.jp/sip/
         • report on connected vehicles : http://en.sip-adus.go.jp/file/Chapter5_s.pdf

    6. VCS-34 - Getting issue details... STATUS   Gap analysis between Sensoris and CVIM

       • gunnar: we do not need to compare sensoris and cvim data models, we need rather to compare project scope

       • benjamin: sensoris is more about surroundings, cvim is more about the vehicle

    7. VCS-39 - Getting issue details... STATUS Provide an update on Kuksa project

       • philippe will ping sebastian schidlt

  • VCS-38 - Getting issue details... STATUS Survey ISO Extended Vehicle
    • gunnar reports on his review of the paper  on OEM-3rd party telematics
    • guru: BMW presented already the vehicle neutral server at the AMM
    • kevin: with the vehicle neutral server, there is no download of sw into the vehicle, it is only data retrieval from the vehicle
    • philippe: IMHO the way the diagnostic services market develops is not a relevant topic for us
    • /TODO/ kevin will check the status of the exve standard status (still a release candidate)
    • see ticket for status of actions (several comments added)
    • Unknown User (kevinval) , can you possibly review the ISO doc if you have downloaded it and provide an overview ?
    • www.neutralvehicle.com/ (yet another start-up company)

      • /TODO/ contact ted to know about the background of the story

      • gunnar and philippe will need to sync on this

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:

• Kevin (High_Mobility)

Agenda:

• sprint review
  • look at active sprint & backlog of VCS tracker

Minutes

• review of Jira tickets, Sprint 1 done, Sprint 2 started

  CCS-2	Analyze data and signal specifications We need to start defining the content and format of the deliverables for those analysis activities	Philippe Robin	VCS Sprint 2, VCS Sprint 1 (i.e. carried over from Sprint 1 to Sprint 2)
  CCS-42	Contact OCF Automotive and check for status	Philippe Robin	added to VCS Sprint 2
  CCS-41	Dissemination of connected services projet results (i.e. deliverables, charter, etc.) new epics created for tracking the publishing of results
  CCS-33	Perform gap analysis of VSS vs. CVIM summary change : comparison changed to gap analysis	Benjamin Klotz	added to VCS Sprint 2
  CCS-40	Publish AutoMat cybersecurity overview	Petar Vorotnikov	added to VCS Sprint 2
  CCS-39	Provide an update on Kuksa project	Sebastian Schildt	added to VCS Sprint 2
  CCS-37	Review CS project charter the charter is attached to the Jira ticket /TODO/ all review the charter and provide comments in Jira	Philippe Robin	VCS Sprint 2, VCS Sprint 1
  CCS-26	Survey AUTOMAT specifications (Common Vehicle Information Model - CVIM) findings should be presented shortly at the next call and then published to CCS-2 recommendation	Kevin Valdek	VCS Sprint 2, VCS Sprint 1
  CCS-38	Survey ISO Extended Vehicle	Gerald Spreitz	VCS Sprint 2, VCS Sprint 1
  CCS-34	Perform gap analysis of Sensoris vs CVIM	Gerald Spreitz	VCS Sprint 2, VCS Sprint 1
  CCS-25	Survey SENSORIS specifications Guru will start looking at the Sensoris specifications now (i.e. before the specifications are published which should happen anytime soon) since as Bosch he has access to it	Gururaja	VCS Sprint 2, VCS Sprint 1
  CCS-28	Survey CCC specifications and check for relevance we need someone to take this work item	Unassigned	VCS Sprint 2

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
  • look at active sprint & backlog of VCS tracker

Minutes

• Connected Services project charter

  • Philippe asks participants to review the project charter and provide comments by next week

  • Philippe: asks participants for their inputs on what should be the project deliverables; he suggests a combination of paper work (likely EA (UML) models, text-based specifications) and code (prototype implementation, proof-of-concept), reminds that Gerald presented the list of outputs of the various sprints identified in the workplan he presented at the last AMM (look here)
  • Kevin: the text is good, the charter will be useful for sharing with the HM team
  • /TODO/ all review the project charter and send comments to Philippe by email by next week
• ISO Extended Vehicle update
  • Gerald provides a couple of links he got from Bosch After Market colleagues
  • link: https://www.figiefa.eu/new-economic-study-vehicles-manufacturers-external-backend-data-access-models-risk-major-cost-burden-to-consumers-and-independent-stakeholders-reaching-e65-billion-in-2030/
  • link: https://www.figiefa.eu/wp-content/uploads/Knobloch-Gr%C3%B6hn-OEM-3rd-Party-Telematics-General-Analysis-Report.pdf
    
    • this link presents the results of an evaluation made by a consulting company about how the data access around ExVe is implemented

  • link: https://www.caruso-dataplace.com/wp-content/uploads/2019/06/137%C2%A9THOMAS_BITTERA_CARUSO_HAL2_05062019-copy-2.jpg

  • link: https://www.neutralvehicle.com/ (yet another start-up company)

  • /TODO/ all review these materials, we will put this at the agenda of next week's call, VCS-38 - Getting issue details... STATUS added to the backlog and current sprint
• 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

• automat project security framework:

  • Petar shows a comprehensive and informative slide deck detailing his findings during his review of the cybersecurity framework, look here

  • Philippe asks how much the architecture of the vehicle data access related to the so-called vehicle neutral server (as described in the original ACEA paper)
  • Petar: yes it is relevant, however there are many ways to establish the access
  • Daniel (and his colleagues) will review the slide deck and provide feedback as well, Jira ticket created
  • Gerald: istm automat project is quite open w.r.t. to the data they want to use, the security framework proposed there might be reused with different data sets
  • Petar: the data set that goes with the automat project is the Common Vehicle Interaction Model (CVIM)
• W3C
  • Gunnar introduces the wiki page he prepared for describing the status of W3C work, he will present the status in the next call
• Sensoris
  • Gerald contacted his Bosch colleague who attended the Open Auto Drive Forum (OADF) two weeks ago, however his colleague is rather interested in HD maps and not so much by the vehicle sensor data which is Sensoris project focus

  •  For early July the public release of version 1.0.0 under the CC-BY-ND license is planned.

    • Public license: Copyright (c) 2017, 2019 SENSORIS Innovation Platform hosted by ERTICO - ITS Europe

    • This program and the accompanying materials are made available under the terms of the Creative Commons Attribution-NoDerivatives 4.0 International license which accompanies this distribution, and is available at https://creativecommons.org/licenses/by-nd/4.0/legalcode.

  • Also the Version 1.1.0 will be released for members only. This Version includes the specification of "Job Requests".

  • added offline: Philippe spotted a one-year old presentation of the Sensoris project web site, link, reading this presentation is recommended, the presentation shown at the OADF event two weeks was much less informative
• AOB
  • schedule of weekly calls
  • Philippe: we got a request to shift the call later in the afternoon in order to allow US participants to join. There seems to be possible participants from US Pacific timezone as well
    • quick poll: Daniel 4-5pm CET is the latest possible timeslot, Petar 4-5pm or 5-6pm CET is fine, Gerald 4-5pm or 5-6pm CET
    • this time is ok for US Central/Eastern but is anyway too early for US Pacific, we will likely end up with a second US Pacific friendly call
    • time for the Monday weekly call will be confirmed later this week

 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
    • Philippe: has created a Jira tracker https://at.projects.genivi.org/jira/browse/VCS
• 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 Progress

  • the 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

Monday 10 June - informal call

(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

  • Gerald: they have something like a neutral server

  • /TODO/ each participatant attend or get information on the OADF/Sensoris workshop scheduled in June

  • The next OADF meeting will take place on June 12, 2019 in the Leonardo Royal Hotel in Munich, Germany. It will be combined with the first NDS Public Conference on the day after at the same location:
    • June 12: 12th Open Auto Drive Forum (OADF)
    • June 13: NDS Public Conference
    • link: https://nds-association.org/ (agenda is there)
• 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

  • Gerald: thinks we need to pre-integrate some parts of the reference architecture

  • /TODO/ Philippe ask Daniel (BMW) why he has a concern about abstract layers and invite him to join the call

• 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