Page History

...

SensorIS (Unknown User (gururaja.n) )

TBA.

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.

Image Added

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 standardised 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.

...