Create osi_streaming.proto

osi_streaming.proto for dynamic changeable data.

Signed-off-by: Thomas Nader <Thomas.Nader@bmw.de>

Author: ThomasNaderBMW

osi_streaming.proto

@@ -0,0 +1,92 @@
+syntax = "proto2";
+option optimize_for = SPEED;
+import "osi_version.proto";
+import "osi_common.proto";
+import "osi_object.proto";
+import "osi_trafficlight.proto";
+//import "osi_hostvehicledata.proto";
+
+package osi3;
+
+//
+// ToDo: Rework Description
+// \brief The traffic update message is provided by traffic participant
+// models to provide updates to their position, state and future
+// trajectory back to the simulation environment. The message is
+// designed to update data of exactly one traffic participant,
+// optionally with an attached trailer. 
+//
+// \note For reasons of convenience and consistency, the updated
+// information is provided as a MovingObject.  Certain fields of this
+// sub-message are not required to be set and will be ignored by the
+// simulation environment, because they are static information.
+// Instead of creating a seperate message type for only the non-static
+// information, re-use existing message.
+//
+// RULE: Needs to include all stuff that changed.
+//
+message Streaming
+{
+    // The interface version used by the sender (traffic participant model).
+    //
+    optional InterfaceVersion version = 1;
+
+    // The data timestamp of the simulation environment. Zero time is arbitrary
+    // but must be identical for all messages. Zero time does not need to
+    // coincide with the UNIX epoch. Recommended is the starting time point of
+    // the simulation.
+    //
+    // \note For moving object update data the timestamp coincides both with
+    // the notional simulation time the data applies to and the time it was sent.
+    // There is no inherent latency for moving object update data, as opposed
+    // to sensor data.
+    //
+    optional Timestamp timestamp = 2;
+
+    // To discuss: Are they needed?
+    // The list of stationary objects (excluding traffic signs and traffic
+    // lights).
+    //
+    repeated StationaryObject stationary_object_update = 3;
+
+    // Updated traffic participant data
+    //
+    // \note It is not expected that static fields are populated. If they
+    // are, they may be ignored by the receiver of this message, for example, dimensions,
+    // or vehicle category.  All dynamic fields should be populated where known,
+    // for example, velocity, light states, or future trajectory.
+    //
+    // \note The field is repeated because it is possible to have a trailer attached to
+    // a vehicle, see MovingObject::VehicleClassification::has_trailer and
+    // MovingObject::VehicleClassification::trailer_id. 
+    //
+    repeated MovingObject moving_object_update = 4;
+
+    // To discuss: Are they needed?
+    // The list of traffic signs.
+    //
+    repeated TrafficSign traffic_sign = 5;
+
+    // The list of traffic lights.
+    //
+    repeated TrafficLight traffic_light_update = 6;
+
+    // To discuss: Here or from osi_ground_truth if sended in a lower cycle time?
+    // Conditions of the environment.
+    //
+    optional EnvironmentalConditions environmental_conditions = 7;
+
+    // To discuss: What about HostVehicleData?
+
+    // To discuss: What about obsolet objects?
+    // Approach 1: is_obsolete flags inside the messages (example see osi_object.proto)
+    //
+    // Approach 2: Is shown below, id_lists (also for traffic lights etc.)
+    // Vehicles that may have been disappeared because of being out of simulation range.
+    //
+    // \note Todo: How often does it need to be sent?
+    //
+    //repeated Identifier disappeared_moving_object_id = x;
+    //
+    // Approach 3: This message with an enum describing if content is to update or to delete.
+}