20200514-Virtual-Technical-Summit-CCS-Workshop-Minutes

20200514-Virtual-Technical-Summit-CCS-Workshop-Minutes



1

## Introduction

2

Philippe Robin welcomes everyone and hands over the mic to Kevin Valdek

50 attendees

slide deck for this workshop is here

3

## Project overview

4

Kevin: this is the presentation Gunnar and I delivered in the Automotive World webinar last week, recording is available

  •  Introduction

    • slide #4: Project charter

      • Even though cars are connected, they are limited to specific OEM/brands

      • A lot of ideas and start ups introducing new services…

      • We want to harmonize these activities… Define building blocks with flexibility for common solutions… Define data exchange and access

    • slide #5: Vehicle data

      • not limited to specific types but clustered by anonymity (personalised, pseudonymized, anonymized)

    • slide #6: Services / Needs

      • up-to-date data, typically telematic through a cloud server, but also bulk on big data

  • Data Model

    • slide #9: Common data model

      • the industry needs this (different implemenations for each OEM… This is to avoid this situation)

      • Gap analysis in the CCS project (CVIM, SensorIS, ISO20078, Android Automotive, VSS) in 2019

    • slide #10: Vehicle Signal Specification (VSS)

      • VSS is at the core of the CCS project

    • slide #16: Value exchange formats

      • proposed protocol to group and exchange VSS data

  • Framework:

    • slide #18: capture data in vehicles

      • ECUs speaking VSS2 (SOME/IP, DDS, HTTP/REST) or current bus translation

    • slide #19: cloud transfer & storage

      • Transfer/Storage with the W3C defined protocol Gen2,  "Gen2" is a vehicle API over HTTPS and WebSockets + data lake based possibly on object storage in a later stage

      • Buffering (high frequency, poor connectivity…) to take into account

    • slide #22: Neutral servers and data marketplaces opportunity included (in accordance to ISO20078) or simple 3rd party access

5

discussion on framework architecture

  • Iyyaz Baber: What about a noSQL DB in the cloud?

  • Kevin: We could. In the end, the proof-of-concept came from our experience with relational DB, there is no restriction

  • Ulf: the server exposes an API. As long as it follows the API, the DB could be of different types.

  • Gunnar: this would depend on the data (time series fitting into a relational DB ?).

  • Teddy Zhai: When you say: “Cloud is Client, and in-vehicle is Data Server”, do you mean in a logical view or technological view? It means, for example, Data Server needs to open ports and listen on them.

  • Ulf: it's both, the data servers needs to open ports and listen, and response to requests (standard client-server model)

  • Gunnar: it can vary from this current proof-of-concept architecture to a production-ready solution. Typically there could be an SSL tunnel set up by OEMs

  • Teddy: This is a major architecture decision in our view. It would be great if GENIVI can provide a threat model for it.

  • Gunnar: I think in the later stages of proof-of-concept development, it is worthwhile to address these questions about how to set up private networks between some parts (e.g. OEM to car). If we end up using SSL/TLS then the GENIVI Security team has previously published a best practice document for SSL/TLS which avoids a lot of security pitfalls.

  • François Fischer: data model - you can add SAREF/Autopilot

  • Philippe: we had a look at SAREF proposal in September 2019 (SAREF Automotive - https://www.w3.org/2019/09/trans-data-ws/SAREF.pdf) and estimated that it was more on the long term (5+ years) goals, it might be worth rechecking the status of SAREF work

  • Francois: I coordinated a project about IoT and automated driving, i.e. AUTOPILOT and we pushed data models to SENSORIS and SAREF, see https://autopilot-project.eu/

  • Gunnar: there are datasets included in the current VSS work, we expec to use an Electric Vehicle (EV) use case and data set for the proof-of-concept demo implementation

  • Gunnar:  our objectives are to get fast results, identify technologies and components that need to be standardized

6

## proof-of-concept demos

7

Demo #1 - OEM cloud

  • Ulf: shows a Cloud and Connected services demo involving 3 components:

    • data server (W3C Gen2),

    • data base (Open Vehicle Dataset Server a.k.a. OVDS)

    • CCS vehicle client

  • Data server can be accessed through multiple protocols (HTTP, WebSockets) with VSS(2) data (but open to use other compatible domains - with a service manager)

  • Data base is a SQL database with a VSS-to-DB adapter

  • CCS client sits in between and creates a list of all VSS leaf nodes and issues read/write requests to the Gen2/OVDS servers

8

Demo #2 - Vehicle data generation

  • slide deck is here

  • Stefan Vysocki (from the GENIVI AASIG Vehicle Data / VHAL project) shows a demo of a vehicle data feeder using a vehicle simulator and a GraphQL server

    • simulator used in the demo is OpenDs, a frame example is given (could be VSS too)

    • the demonstration iincludes the simulator interface and a GraphQL server to retrieve values from the simulator

  • Kevin Valdek: Could we use a fleet instead  ?

  • Stefan: Yes, by configuring multiple ports

  • Stephen Lawrence: Could you containerize the simulator and automate tests ?

  • Stefan: It is partially containerized, no issues.

9

Demo #3 - GraphQL client on top of a VSS schema

slide deck is here, Kevin shows a demo

Discussion

  • How to have data anonymization ?

  • there is consent here

  • What about the identification?

  • Here we could have many types of identifiers, such as what a brand allows you to access (a certain fleet for instance)

  • What happens when the user removes consent (need to do something on the 3rd party side) ?

  • These are great use cases, we should look into them.

  • How do we categorize what is to be anonymized and what is not ?

  • Since privacy is partially region-based, it might be better to have configuration outside of the VSS

10

Discussion on technology options

  • Gunnar introduces the topic with this slide deck

  • How to generate data

    • Usefulness of an easy to run driving simulator

      • it would be nice to use the simulator as a driving game and generate data

      • Iyyaz: I go for it !

      • Gunnar: which operating system would you use ?

      • Iyyaz: ubuntu, linux or windows 10

      • Christian: having vehicle data would be useful to test our APIs !

      • Stephen Lawrence points out that CAN can-utils has the basic cansend to send can msgs, look at https://github.com/linux-can/can-utils, and https://manpages.debian.org/stretch-backports/can-utils/cansend.1.en.html

      • How important is the sanity of the data ? Could we do statistical analysis on random data? What about randomly generating data ?

      • Gunnar: Is that sending a random generated data you mean?

      • Stephen: can-utils also has cangen for random data

      • Stephen: it seems also that candevstudio may  have some generation capability, look at CANdevStudio repository

  • Alternative technologies

    • Why not using MQTT between the vehicle and the cloud (rather than other than W3C Gen 2) ? with MQTT there is a need to define the payloads

    • using maybe a NoSQL data base

    • Abhijeet: mentions the use of a replica of the car like AWS Car Shadow and like the Ditto digital twin - Device as a service: Ditto project from Eclipse https://www.eclipse.org/ditto/

  • How to do high-volume tests ?

  • Evaluating the performances ?

  • What about security ?