Versions Compared

Old Version 116

changes.mady.by.user Philippe Robin

Saved on

compared with

New Version 117

changes.mady.by.user Philippe Robin

Saved on

Key

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

...

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

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

...

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

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)

...

  • /TODO/ Glenn to provide the link to the YouTube video presenting an example of data processing / compression on the vehicle side

    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-72

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

    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-73

  • /TODO/ Glenn to provide the links to NHTSA paper on V2V/V2X data exchanges

    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyCCS-74

Monday,  February 10 - Vehicle Data

...

  • 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

...

  • GENIVI technical summit - content planning, additional information
    • registration link is at https://www.eventleaf.com/TechSummit19ent
    • content will be finalized this week, 3 tracks are planned: Connected Services, Android Automotive, Cybersecurity
    • quick poll on who will attend
  • https://grpc.io/: is this relevant for CCS ?
    • g stands for Google
    • Gunnar: we look at Google rpc in the GPRO project when we did the survey on communication protocols, look at the list of technologies we looked at and the GPRO white paper
    • grprc is built on http2 which never took off, people are rather working on http3, gprc is likely well suited on web technologies, it is one of many choices that are out there
    • from my perspective, it is relevant but not more relevant than anything else, when it comes to protocols that are not REST oriented protocols, MQTT has more relevance
  • SAREF Automotive - https://www.w3.org/2019/09/trans-data-ws/SAREF.pdf
    • Benjamin reviewed the paper presented at the W3C workshop on data models for transportation, his findings on SAREF automotive are here
    • use cases identified in the paper are
      • Platooning
      • Automated Valet Parking (AVP)
      • Cooperative Perception Service (CPS)
      • Vulnerable Road Users (VRUs)
    • Philippe: these use cases fit well into the the future, i.e. much beyond a 5-year horizon
    • Philippe: IMHO currently in the CCS project,  short term is represented by the current High Mobility offering on the market, and the on-going work is rather looking at the mid-term,
    • Kevin: it would be good to ask OEMs what use cases are more tangible to implement
  • Gap analysis deliverable - review feedback of draft sections on VSS, Sensoris, etc.
    • Philippe: I reshuffled the pages a little bit and the draft deliverable appears now in the main CCS page table of content, look at Vehicle Data Models - Overview & Gap Analysis deliverable
    • Philippe: Guru and Benjamin have provided their inputs, Guru added his inputs in the wiki, I added the link the CVIM doc prepared by Benjamin to the wiki page
    • Kevin: I reviewed the draft document on VSS prepared by Gunnar, the intro is not specific to VSS but fairly general
    • Gunnar: agreed, we need to ask again for the review work  the VSS doc
    • /TODO/ Daniel/Benjamin/Guru/etc please review the VSS doc
    • Gunnar: I will review the Sensoris section written by Guru
    • Kevin: I will review the CVIM doc prepared by Benjamin
    • Gunnar: Steve pointed us to two other data exchange standards from the Open Group
    • I found them to be mostly similar or related to what OCF might be doing.  I also found them to be fairly thin specs in particular O-DM but the messaging standard might have something useful
    • We are wondering what OCF think about it:
      • Is it used by OCF or not ?
      • Is it out of scope and covering other unrelated things ?
      • or is it overlapping, but OCF have created other standards to cover this instead ? (It might of course boil down to a simple XML vs JSON preference...)
      • Unknown User (don.dulchinos) Do you have any feeling on how well these standards are adopted?
    • /TODO/ Don review these data exchange standards from the Open Group
    • Gunnar: we should consider adding some info on SAREF and the Open Group work in the gap analysis deliverable
  • Big Picture & Design concerns wiki page - more feedback
    • link added to the CCS main wiki page
    • Gunnar: the topics / issues in the design concerns page should be transformed soon in a set of work items described in jira, Kevin has provided his comments already, other comments are welcome until next week call
    • I will also review the existing tickets in Jira that might be relevant to the topics described in the design concerns wiki page
    • Philippe: I will projectize this in Jira starting next week
  • Sprint & backlog review (end of Sprint 4)
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyVCS-48
      target date for producing the gap analysis deliverable is 8 November, we will present it at the tech summit
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyVCS-59
      /TODO/ Gunnar ping Michael Ger to get a Cloudera architect into CCS project
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyVCS-35
      Daniel said he is "back" and should start working on it this week
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyVCS-60
      /TODO/ Gerald please do
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyVCS-6
      see above design concerns, projectization will be developed further starting next week
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyVCS-61
      done, see above
    • Jira
      serverJIRA
      serverId121ddff2-c571-320f-9e4d-d5b9371533bd
      keyVCS-39
      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

...

  • 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

...

  • 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

...

  • 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

...