Versions Compared

Old Version 118

changes.mady.by.user Philippe Robin

Saved on

compared with

New Version 119

changes.mady.by.user Philippe Robin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Data set for EV management
  • Communication Framework
  • Vehicle Abstraction Layer
  • CCS project backlog in Jira
  • AOB

Participants

  • Ulf, Glenn, Kevin de Sousa (Getoab), Gerald (Bosch), Kevin Valdek (High-Mobility), Keith (LGE), Gunnar, Philippe

...

  • 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
      Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-24

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
      Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-78

Communication framework

  • the high-level block diagram proposed by KevinV is shown
  • KevinS: brings a clarification on what Geotab is doing today, Geotab runs a sort of container on their embedded device today
  • KevinS: for an OEM, it might consist in running a GENIVI VSS as a so-called container
  • KevinS: what Geotab is doing is generalizing the in-vehicle processing with the OEM cloud
  • KevinS: the communication between the Geotab device and the cloud is proprierary
  • KevinS: the Geotab communication framework architecture currently is very closed to what is shown on the block diagram, the data processing would be very different on the Getoab side
  • Ulf: the diagram is quite interesting, but where are the W3C standards mentioned? We see W3C Gen 2 to be also used between cloud and the vehicle
  • Ulf: since Gunnar is active in W3C and we are trying to standardize the cloud to vehicle interaction, it would be worth showing this to W3C and discussing the transport protocol and the container processing
  • Philippe: explains the approach taken by KevinS to build to this diagram
  • Ulf: VISS is the first assumption for the implementaIion, we are now working with the so-called Gen2 in W3C
  • Gunnar: Let's see if for every place where it says "REST", we can clarify that we mean "W3C Gen 2 REST", (sync with Kevin V to see if this is the case)
  • /TODO/ Kevin V to  look at Gen2
  • /TODO/ Ulf to send the links to Gen2 DONE below are some links to the W3C automotive working group.
  • Keith: what is VSS 2.0 about ?
  • Gunnar: it only just means "next release". It is not a new concept. For now consider the master branch as the content. Sure, there have been some advancement of the syntax, semantics, tooling and vss-layers, but the "2" is not there to indicate a whole new concept.
  • Gunnar: clarification brought on how to bring the latest values, VSS define only the isgnals, we need data feeders
  • Gunnar: querying the data and ask for their values is something that W3C is not looking into yet, the CCS project is going beyond what W3C is doing
  • KevinV: graphQL is another Web technology; BMW has an interest in it in addition to what Google is doing, explains the thinking behind bringing grahQL in the picture
  • Ulf: I agree that (the powerful query language of) graphQL is very powerful, it is a perfect technology to work with at the data lake level, however  I have some doubt about that approach if you put it in the vehicle,
  • Ulf: The interpretation and execution of the queries in the vehicle will put equally a powerful load on the vehicle to answer those
  • Philippe: explains the short term to long term of the vehicle EE (look at slide #4 of the EE architecture evolution, in the long-term, we might afford grapQL on in-vehicle HPC nodes (Hogh Power Compute).
  • Philippe: The powerful computing nodes in the vehicle might be able to handle it.
  • discussion on how to instantiate the CCS block-diagram on vehicle EE architectures. Geotab approach with an embedded device might be appropriate for the short to mid term. However CCS architecture draft proposal for the CCS block-diagram should rather be mapped on an architecture like the one of slide #4 above
  • discussion on communication framework architecture will continue on Wednesday call at 5pm CET.
  • A calendar invite has been sent

CCS project backlog in Jira

Monday,  February 17 - Vehicle Data

...

  • CES debriefing
  • vehicle data models: relevance of the specs for EV Charging to our work on data modeling (e.g. OCPP)
  • platform candidates for the CCS PoC: are the following platforms relevant : Amazon Auto, MS Azur, Veniam ?
  • project organization: add another weekly call to discuss architecture
  • Sprint & backlog review
  • AOB
    • data categories

Participants

...