Versions Compared

Old Version 117

changes.mady.by.user Philippe Robin

Saved on

compared with

New Version 118

changes.mady.by.user Philippe Robin

Saved on

Key

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

Monday,  February 24 - Vehicle Data

Agenda:

  • Data set for EV management
  • Communication Framework
  • Vehicle Abstraction Layer
  • AOB

Participants

  • Ulf, Glenn, Kevin de Sousa (Getoab), 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

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

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

Monday,  February 17 - Vehicle Data

Agenda:

  • Data set for EV management
  • Kuksa project update / Vehicle Abstraction Layer
  • AOB

...

  • 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
  • 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, 
        Jira
        serverJIRA
        serverId121ddff2-c571-320f-9e4d-d5b9371533bd
        keyVCS-27
          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

...