Page History

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 project manager in EV fleet management at Geotab and works on smart charging
• Geotab has B2B B2C smart charging management platform offering
• Sarah delivers this presentation (add link)
• 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 - Vehicle2Cloud 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 VCS tracker
• AOB
  • data categories

...