JOIN/SIGN UP

Join COVESA

Already a Member?
     ▷Sign Up for Member Newsletter

     ▷Request Wiki Account (Needed for Write Access)

GET INVOLVED

COVESA Getting Started

COVESA Community Calendar - Weekly Meeting Schedule

COVESA Communication Channels (Slack, Mailing Lists)

COVESA Github Repository

Project Launch Process

COVESA Briefing/Overview Deck

COLLABORATIVE PROJECTS

Data Expert Group
▶︎ Data Models and Ontologies
     ▷ Vehicle Signal Specification (VSS)
     ▷ Vehicle Signal Specification Ontology (VSSo) - W3C Collaboration
▶︎ Architecture and Infrastructure
     ▷ Data Architecture Terminology (including Logical Components)
▶︎ Interface Definition
     ▷ Vehicle API
     ▷ Vehicle Service Catalog (VSC)
     ▷ Vehicle Information Service Specification (VISS) - W3C Collaboration
▶︎ Best Practices
     ▷ Governance
     ▷ Privacy and Identity
     ▷ Data Model Definition
     ▷ API First
 
Data Expert Group Workshop 2023Q428 at Spring AMM
Data Expert Group Workshop 2023Q1

Electric Vehicle Charging Expert Group
▶︎ EV Charging Event Data Aggregation Project
▶︎ EV Optimization - Increase Travel Range for Fixed Battery
▶︎ Private Cross OEM Joint Compute for EV Charging

Android™ Automotive SIG
▶︎ Automotive AOSP App Framework Standardization

Security Team

Simulation and Tooling
▶︎ digital.auto

Vehicle Experience and Content - Entertainment BoF
▶︎ In-vehicle Payment SIG

Commercial Vehicle BoF

HISTORICAL

Common Vehicle Interface Initiative

Cloud & Connected Services Project

SDV Telemetry Project - On Hold

Events

Industry Events

Industry Events 2023

COVESA Events

April 2023 All Member Meeting

October 2022 All Member Meeting

April 2022 All Member Meeting

October 2021 All Member Meeting

May 2021 All Member Meeting

October 2020 All Member Meeting

May 2020 Virtual Technical Summit

November 2019 Technical Summit

May 2019 All Member Meeting

Contact Us

Child pages
  • 20200514-Virtual-Technical-Summit-CCS-Workshop-Minutes

We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies.


Skip to end of metadata
Go to start of metadata


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 ?



  • No labels