Gap analysis draft deliverable

Introduction

• Introduction to the Cloud & Connected Services GENIVI project
• Charter summary
• Scope
• Deliverables

Analysed specifications

• Listing the open source projects that are analysed in this document:
  • Vehicle Signal Specification (VSS)
  • SensorIS
  • Extended Vehicle (ExVe) ISO standard
  • (Connected Vehicle Information Model (CVIM) from AutoMat) - need to decide how to present this based on the project state
  • Android Auto vehicle interface  (should there be a Jira task to survey this project separately first?)
  • Any other IOT projects?
• Listing of projects that were examined but not included in the GAP analysis - together with the reasons: (we need to decide how to handle these two projects, this is just a suggestion)
  • Connected Vehicle Information Model (CVIM) from AutoMat?
  • Connected Car Consortium
  • SAREF Automotive
  • the Open Group data exchange standards

Analysis criteria

• What parts of the projects were analysed and to what extent?
  • Motivation & problem space
    • Scope
    • Licenses
    • Applicable to different domains
  • Data model & data characteristics
    • Encoding
    • Technologies
  • Contents
    
    • Specification
    • Tooling
    • Source code structure
  • Stakeholders
    • Current status
    • Roadmap
  • Metadata & policies (Unknown User (benjamin_klotz) , Benjamin has a special interest for metadata & policies of all existing projects)

GAP analysis

following above list of analysis criteria

Motivation & problem space

Vehicle Signal Specification (Gunnar Andersson )

Please see draft in this document.

SensorIS (Unknown User (gururaja.n) )

Overview

Sensor Interface Specification Innovation Platform, SENSORIS, is an open group of significant actors from the global vehicle industry, map and data providers, sensors manufacturers and telecom operators who joined forces, under the form of this Innovation Platform, driven by the common vision and belief that, defining an appropriate interface for exchanging information between the in-vehicle sensors and a dedicated cloud as well as between clouds

• enable broad access, delivery and processing of vehicle sensor data
• enable easy exchange of vehicle sensor data between all players
• enable enriched location based services
• drive global growth in this field

Scope

Scope is to deliver and maintain technical specifications defining the format and content of sensor and campaign data:

  In Scope

• vehicle-to-cloud data upload format (vehicle-based data only)
        Where does "data model" fit in – is it part of what we mean by upload format here?  (Or is it missing from the list?)
• cloud-to-cloud data exchange format (vehicle-based data and other data needed for mobility services)
• cloud-to-vehicle ‘campaign’ request format (request for specific data at specific locations and times only)
• conformance to data authorization/authentication process
• conformance to data privacy regulations
• conformance to approved security regulation

  Out of scope

  SENSORIS will not:

• define infrastructure or architecture
• establish commercial agreement frameworks for data exchange
• define data exchange for v2v, v2i, i2v (cooperative data) exchange
• define cloud-to-vehicle services

MISSING:  A bit more detailed analysis of what was actually published.  E.g. content of data model.
(This was done in a previous ticket?)

Licenses

SENSORIS specifications will be handled through a dual license model. Every release will be first released internally to the members of SENSORIS under a SENSORIS license. As SENSORIS is committed to be open to the public, all schemas and documentation will be published after a 12 month retention period to the public under the Creative Commons Attribution-NoDerivatives 4.0 International license. Please review the referred license for the exact description of the rights and obligations related to the use of the SENSORIS schemas and documentation.

The published package under this license also contains HTML-documentation as well as the schema description in Google Protocol Buffers (protobuf) language.

What is allowed to do:

• Download the schema from the website.
• Compile a protobuf library using the openly available protobuf compiler.
• Use the protobuf library to implement any software that encodes or decodes SENSORIS messages. 
• Define proprietary (non-standardized) Any-extensions.
• Use SENSORIS and your proprietary extensions even commercially between non-member to non-member business cases.
• You can join the consortium and contribute.

This clarification part is not necessary in the GAP analysis.

What is not allowed to do:

• Change the protobuf schema and distribute it to third parties under any name (SENSORIS or other) to exchange data.

This program and the accompanying materials are made available under the terms of the Creative Commons Attribution-NoDerivatives 4.0 International license which accompanies this distribution, and is available at https://creativecommons.org/licenses/by-nd/4.0/legalcode.

Extended Vehicle (ExVe) ISO standard Unknown User (kevinval)

The were three main factors to introduce the ExVe ISO standard:

1. Increasing demand from 3rd parties to access vehicle data and functionality. The workaround to date has been installing additional hardware into the car, which has on one hand has limited scale but more importantly raises the question how security and safety is being handled.
2. OEMs have already equipped vehicles with telematics units and built up IT-infrastructure to handle data connectivity between vehicles and backend systems. To some extent OEMs have offered external parties to integrate with vehicle data using web services, this has been done however without any guidelines or requirements on the system design.
3. As there is active data sharing already, either through external hardware or individual OEM web services, there is a need to define a design and requirements to ensure that security, safety and data privacy is handled with best practices common methods.

The scope of the ISO standard is web services only, which means data offered by OEM backends. It assumes that OEMs have vehicle data available in their backend and applies no requirements on how the data collection is done.

A large part of the standard focuses on authorisation, in other words how user consent should be obtained and maintained. There are several categories of vehicle data; personalised (identifiable to a specific vehicle with a VIN), pseudonymised and anonymised. If we consider a vehicle data point as a resource, in each of these data categories the resource owner depends on the nature of the data and has specific authorisation requirements. All of the data categories are considered in this standard.

Apart from data retrieval the standard also provides requirements and methods for handling modification to the vehicle state through functions.

Licenses

The documentation is provided by the ISO standardisation under a commercial license. The license can be obtained from www.iso.org for the following documents:

• ISO 20078-1 Road Vehicles – Extended Vehicle (ExVe) web services – Part 1: Content
• ISO 20078-2 Road Vehicles – Extended Vehicle (ExVe) web services – Part 2: Access
• ISO 20078-3 Road Vehicles – Extended Vehicle (ExVe) web services – Part 3: Security
• ISO/TR 20078-4 Road Vehicles – Extended Vehicle (ExVe) web services – Part 4: Control

CVIM (Unknown User (benjamin_klotz) )

Please see draft in this document.

Table comparison (if applicable)

TBA.

Data model & data characteristics

Vehicle Signal Specification (Gunnar Andersson )

Content outline:

• Need for shared data (model) description
• Tree hierarchy equivalence
• VSS specification structure and content
• Terms/nomenclature/definitions ("what is a data model, specification, ..." - reusing Daniel's infographic)
• Beyond: Deeper analysis of data characteristics - data ontologies
• (Open) Licensing
  • Common data model - can companies agree?
  • ...plus proprietary and function-specific extensions (still with common format and tooling)
• Car-network focus vs. generic usage
• VSS principle can be applied in network - ECU-internal, intra-ECU, and cloud connected services
• W3C protocol definition and usage of VSS
• Potential for VSS use in CCS.

Please see draft in this document.

SensorIS (Unknown User (gururaja.n) )

Sensoris has a category driven data elements. e.g. driving_behavior_category, sensoris.protobuf.categories.drivingbehavior.DrivingBehaviorCategory powertrain_category, sensoris.protobuf.categories.powertrain.PowertrainCategory.  

Any number of categories can be created based on the requirement. In the first public version 1.0.0 of the Sensoris Specification the following categories are defined. Localization category, Object detection category,Weather category,Driving behavior category, Intersection attribution category, Road attribution category, Traffic regulation category, Traffic events category,Traffic maneuver category, Brake category, Powertrain category, Map category In the next level sub elements are added e.g. Weather category has Precipitation and Localization category has Vehicle position and rotation, Vehicle odometry, Vehicle speed, Vehicle acceleration,Vehicle rotation rate.

Category envelope is the mandatory first field of each category. It follows the google.protobuf.Any format with type_url and value in bytes.

Data Message Content

Data messages contain vehicle sensor data. Data messages communicated from one vehicle of a vehicle fleet to its vehicle cloud contain sensor data from the one vehicle

Identifiers : Several identifiers are used in a SENSORIS message  which affect privacy. They allow for identification of a submitter, session, message, vehicle fleet, vehicle, and driver. All identifiers are optional and are a powerful and fine-grained control instrument for ensuring privacy aspects in SENSORIS session_id, message_id, last_message_of_session, vehicle_fleet_id, vehicle_id, driver_id

Identifiers and referencing

The second set of identifiers is used for cross-referencing events within a message

The event identifier uniquely identifies an event within a message and is only required if a reference to the event is needed beyond chronological time stamp relation. Event identifiers are of type integer and begin with value 0 and are incremented by 1.  The event relation protobuf message type enables binary relations between events within a single data message.The event group protobuf message type enables smart grouping of events based on the same relative spatial reference system

Some event protobuf message types contain an object identifier which enables referencing between individual events over time

Message Encoding

SENSORIS job request, job status, and data messages are communicated between the three actor roles vehicle fleet, vehicle cloud, and service cloud. The SENSORIS messages have to be encoded for over-the-air and over-the-wire communication channels, i.e. they have to be serialized by the sender prior to communication and then have to be deserialized by the receiver. Encoding shall support evolution of the data format, i.e. adding new data types or fields shall be backward compatible so that the new data format can be read by both new code and code generated for previous versions of the data format

For SENSORIS version 3 of the Google Protocolbuf library is used which adds a streamlined approach for proprietary extensions. The communication from a vehicle of a vehicle fleet to its vehicle cloud is used as example, On the vehicle the obtained sensor data is filled into the C++ data access classes. The class instances are then serialized into a byte array by the also auto-generated C++ encoder. The serialized data is transferred over-the-air to the vehicle cloud. There the auto-generated Java decoder deserializes the byte array into Java class instances having the same schema and sensor data as the C++ class instances on the vehicle. The protobuf Any5 message type fulfills the requirement for proprietary extensions.

Extended Vehicle (ExVe) ISO standard  Unknown User (kevinval)

The ExVe ISO standard does not introduce a data model. In this aspect any data model analysed in this document would fit as a data model in the implementation of a ExVe compatible web service. No ExVe compatible interface that has been introduced to the market today uses any standardized data model.

The standard does however define requirements on the web service interface that is provided to 3rd parties. It has to be RESTful and use the JSON or XML schema. Furthermore the standard includes requirements on several aspects: URI definition, error handling, naming and interaction patterns. All of these are aimed to make the implementation for 3rd parties similar no matter what OEM web service is being consumed.

CVIM (Unknown User (benjamin_klotz) )

TBA.

Table comparison (if applicable)

TBA.

Contents

Vehicle Signal Specification (Gunnar Andersson )

Please see draft in this document.

SensorIS (Unknown User (gururaja.n) )

TBA.

Extended Vehicle (ExVe) ISO standard Unknown User (kevinval)

The contents consist purely of specification documents. These include detailed descriptions along with visual diagrams and logical workflow diagrams of how a ExVe web service should be defined. This also covers the system design on an architectural level, meaning how certain logic should be decoupled in different components to ensure a secure implementation of the authorisation process, resources and data access.

CVIM (Unknown User (benjamin_klotz) )

Please see draft in this document..

Table comparison (if applicable)

TBA.

Stakeholders

Vehicle Signal Specification (Gunnar Andersson )

TBA.

SensorIS (Unknown User (gururaja.n) )

TBA.

Extended Vehicle (ExVe) ISO standard Unknown User (kevinval)

There is good support for the ExVe standard which is demonstrated by market launch of ExVe compatible web services by several European OEMs already. European OEMs agreed to adopt the ExVe concept in 2016 which was followed by the finalisation and publication of the ISO standard in Q1, 2019.

Table comparison (if applicable)

TBA.

Metadata & policies

Vehicle Signal Specification (Gunnar Andersson )

TBA.

SensorIS (Unknown User (gururaja.n) )

TBA.

Extended Vehicle (ExVe) ISO standard Unknown User (kevinval)

TBA.

CVIM (Unknown User (benjamin_klotz) )

TBA.

Table comparison (if applicable) (Unknown User (benjamin_klotz) To Be Confirmed)

TBA.

Conclusions

TBA.

References

TBA.

Project Team

TBA.