JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project |
Since the beginning of 2020, we started looking at how to augment the VSS Data Model with data set covering the Electric Vehicle (EV) (look at the minutes of CCS calls of 27 January and 10 February).
The following docs were pointed out
From the discussions in the calls, it turned out that the data related to battery performance are highly sensitive and it is likely that OEMs are not goint to share these data although one can consider the data could be described in a proprietary branch of the VSS tree.
For the time being, it is proposed to populate the EV branch of the VSS tree with a set of data used by Geotab in commercial EV management where the data are retrieved from the OBD-II port, knowing other (OEM proprietary) battery data are rather available on the vehicle networks like CAN. The purpose of addition this EV data set is just to tell we are future-proof with the handling of EVs.
Jira ticket TBD
5GAA related papers for cloud & connected services
Gunnar Andersson please add a conclusion on whether there are some relevant inputs for augmenting the data set in those whitepapers
The text below corresponds to the preparation of the deliverable
...
Warning | ||||
---|---|---|---|---|
| ||||
This deliverable has been uploaded to Google Docs, @contributors: please edit the google docs (and not this wiki page) ! Thanks |
Info |
---|
This is a draft with placeholder texts to serve as a container for a project deliverable. |
following above list of analysis criteria
Updated text (taken from previous separate document)
...
The usage of VSS as an underlying signal description database in the protocol work by W3C Automotive Working group have also proven in practice that the idea behind the hierarchical data description of VSS goes beyond the low-level signalling buses like CAN.
The licensing of VSS is unique among the compared standards in that it started from the beginning with a well-known free and open-source license. Since the signal specification definition was mostly perceived as a document, a permissive Creative-Commons Attribution (CC-BY) license was used whereas some of the software had other licenses. This was later unified and the project now continues under one single license, namely the Mozilla Public License, v2 (MPLv2). Using this style of open-source licensing ensures high usability of the specification by all types of companies and this can be an advantage for companies that bet on the VSS, or any derivative thereof, as it protects against unexpected privatization of the specification.
...
Do we write this chapter for each of the standards?
...
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
Scope is to deliver and maintain technical specifications defining the format and content of sensor and campaign data:
*An initial list data item definitions (data model) for some subject areas has also been published by Sensoris, as described in the Data model & data characteristics chapter.
SENSORIS will not:
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.
...
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.
The were three main factors to introduce the ExVe ISO standard:
...
Apart from data retrieval the standard also provides requirements and methods for handling modification to the vehicle state through functions.
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:
Please see draft in this document.
Includes: Motivation, Scope, Contents, Stakeholders...
The hierarchical organization tree-format is the basis of the VSS, like many other data model descriptions.
...
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.
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.
See (copy from) attached document
Contents (VSS)
The VSS is both a concrete database and a set of standards and tools for how to write and extend the database. Thus, looking at content only does not give the full picture. However, the current VSS (open to modification by change requests) has already encoded a number of typical data items in a proposed tree structure. The top level includes:
...
In the first public version 1.0.0 of the Sensoris Specification the following categories are defined.
...
Field | Type | Description |
---|---|---|
envelope | sensoris.protobuf.types.base.CategoryEnvelope | Envelope. |
vehicle_position_and_orientation | repeated VehiclePositionAndOrientation | Vehicle position and rotation. |
vehicle_odometry | repeated VehicleOdometry | Vehicle odometry. |
vehicle_speed | repeated VehicleSpeed | Vehicle speed. |
vehicle_acceleration | repeated VehicleAcceleration | Vehicle acceleration. |
vehicle_rotation_rate | repeated VehicleRotationRate | Vehicle rotation rate. |
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.
Please see draft in this document
Think about if this still makes sense in the final structure
Definition contributions from JLR, BMW, Volvo Cars (through W3C), Geotab. Implementation in Kuksa project (Bosch – any other Tier 1s/2s?)
Contrubutions Contributions by Here, BMW, Daimler, Volvo, Audi, Full member list https://sensor-is.org/members/. Bosch has the implementation of the spec.
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.
Possible to clarify more?
Mention original contributing companies. No known extension / application of results however.
This section describes the metadata used and its openness.
Metadata can be available (pdf documentation), structured, on open formats. It can additionally use ad hoc semantics (e.g. a fixed list of properties), reuse standard semantics (e.g. format properties, units) or be fully linked (e.g. reuse URIs as identifiers between connected entities).
Non-formal metadata is within VSS with a given set of properties (label, comment, min, max…), provided in various open formats. VSS comes with an extension mechanism to create or update branches, signals or attributes.
There are policies in VSS in regard to its units: they should follow first automotive standards, or at least be SI. They are explicitly defined in the documentation.
SensorIS uses different serialization open formats for its data, but the current release only has its metadata in protobuf. Units are standard are explicitly defined (e.g. deg_c for Celsius degrees)
There is a policy for extensions (new properties of signals).
This specification does not define a data model.
The specification has requirement to data formats (JSON, XML Schema), uses URIs and some best practices that candidate data models should follow.
Measurement data comes in packages through data channels. The packages are provided in JSON (open format). Non-formal metadata is supposed to be provided in JSON too but so far only examples are available in the pdf documentation. Data package metadata is composed of a fixed list of properties.
There are no policies to create new properties or standard units.
Specification | Structure | Semantics | Policies |
---|---|---|---|
VSS | Multiple open structured formats | Non-formal fixed set of properties |
|
SensorIS | Open structured format (protobuf) | Non-formal fixed set of properties | Extensions |
ExVe | Available documentation (pdf) | Requirements on candidate data models | |
CVIM | Available documentation (pdf) | Non-formal fixed set of properties |
TBA.
TBA.