diff --git a/doc/architecture/architecture_overview.adoc b/doc/architecture/architecture_overview.adoc index 31f28c154..35959b97b 100644 --- a/doc/architecture/architecture_overview.adoc +++ b/doc/architecture/architecture_overview.adoc @@ -4,11 +4,21 @@ include::{root-path}_config.adoc[] endif::[] = Overview of OSI architecture -OSI contains an object-based environment description that uses the message format of the https://github.com/protocolbuffers/protobuf/wiki[Protocol Buffer] library. -Google developed and maintains the Protocol Buffer library. +OSI contains an object-based environment description that uses the message format of the https://github.com/protocolbuffers/protobuf/wiki[Protocol Buffer^] library developed by Google. OSI defines top-level messages that are used to exchange data between separate models. -Top-level messages define the `GroundTruth` interface, the `SensorData` interface, and – since OSI version 3.0.0 – the interfaces `SensorView` and `SensorViewConfiguration`. -Further top-level messages that were added in later versions of OSI are `HostVehicleData`, `TrafficCommand`, `TrafficCommandUpdate`, `TrafficUpdate`, `MotionRequest`, and `StreamingUpdate`. + +Top-level messages define the following interfaces: + +- xref:architecture/ground_truth.adoc[`GroundTruth`] +- xref:architecture/sensor_data.adoc[`SensorData`] +- xref:architecture/sensor_view.adoc[`SensorView`] +- xref:architecture/sensor_view_configuration.adoc[`SensorViewConfiguration`] +- xref:architecture/host_vehicle_data.adoc[`HostVehicleData`] +- xref:architecture/traffic_command.adoc[`TrafficCommand`] +- xref:architecture/traffic_command_update.adoc[`TrafficCommandUpdate`] +- xref:architecture/traffic_update.adoc[`TrafficUpdate`] +- xref:architecture/motion_request.adoc[`MotionRequest`] +- xref:architecture/streaming_update.adoc[`StreamingUpdate`]. The following figure shows the interfaces and models involved in modeling a sensor. diff --git a/doc/architecture/ground_truth.adoc b/doc/architecture/ground_truth.adoc index 512387778..7520b88fd 100644 --- a/doc/architecture/ground_truth.adoc +++ b/doc/architecture/ground_truth.adoc @@ -6,4 +6,6 @@ endif::[] `GroundTruth` messages describe the simulated environment containing all simulated objects in the global coordinate system at consecutive time instances. They are based on data available to the simulation environment. -`GroundTruth` messages are typically contained in `Sensorview` messages. \ No newline at end of file +`GroundTruth` messages are typically contained in `Sensorview` messages. + +For more details, see xref:gen:structosi3_1_1GroundTruth.adoc[]. \ No newline at end of file diff --git a/doc/architecture/host_vehicle_data.adoc b/doc/architecture/host_vehicle_data.adoc new file mode 100644 index 000000000..d9f27ef7c --- /dev/null +++ b/doc/architecture/host_vehicle_data.adoc @@ -0,0 +1,12 @@ +ifndef::include-only-once[] +:root-path: ../ +include::{root-path}_config.adoc[] +endif::[] += Host vehicle data + +The `HostVehicleData` message targets the perception of the vehicle of its own internal states. + +It captures the knowledge the vehicle has internally, which can differ from the actual or global truth for various reasons. +This message can also be understood as an interface container for the signals of a rest bus simulation. + +For more details, see xref:gen:structosi3_1_1HostVehicleData.adoc[]. \ No newline at end of file diff --git a/doc/architecture/motion_request.adoc b/doc/architecture/motion_request.adoc index e24a43608..49085d9ff 100644 --- a/doc/architecture/motion_request.adoc +++ b/doc/architecture/motion_request.adoc @@ -5,4 +5,6 @@ endif::[] = Motion Request `MotionRequest` messages are traffic participant internal messages. -They function as a interface between a motion/behavior planning model and a dynamics model including, for example, controllers and vehicle kinematics. \ No newline at end of file +They function as a interface between a motion/behavior planning model and a dynamics model including, for example, controllers and vehicle kinematics. + +For more details, see xref:gen:structosi3_1_1MotionRequest.adoc[]. \ No newline at end of file diff --git a/doc/architecture/sensor_data.adoc b/doc/architecture/sensor_data.adoc index b44f0eeaa..8d29abd64 100644 --- a/doc/architecture/sensor_data.adoc +++ b/doc/architecture/sensor_data.adoc @@ -13,3 +13,5 @@ Sensor data can be used as input for an automated driving function, a sensor mod `SensorData` messages include `FeatureData` messages which contain detected features in the reference frame of a sensor. `FeatureData` messages are generated from `GroundTruth` messages. They serve, for example, as an input to sensor models simulating object detection or feature fusion models. + +For more details, see xref:gen:structosi3_1_1SensorData.adoc[]. \ No newline at end of file diff --git a/doc/architecture/sensor_view.adoc b/doc/architecture/sensor_view.adoc index adeb6254e..d2cf7550a 100644 --- a/doc/architecture/sensor_view.adoc +++ b/doc/architecture/sensor_view.adoc @@ -10,4 +10,6 @@ All information regarding the environment is given with respect to the virtual s * Physical technology-specific data, given with respect to the physical sensor coordinate system specified in the corresponding physical sensor's mounting position. One example of technology-specific data is: xref:gen:structosi3_1_1CameraSensorView.adoc#ac58456a34babf78792ea2608eb963f36[`image_data` of `osi3::CameraSensorView`] -* Ground truth given in the global coordinate system. \ No newline at end of file +* Ground truth given in the global coordinate system. + +For more details, see xref:gen:structosi3_1_1SensorView.adoc[]. \ No newline at end of file diff --git a/doc/architecture/sensor_view_configuration.adoc b/doc/architecture/sensor_view_configuration.adoc index 09d0d5fb7..5ec06a97f 100644 --- a/doc/architecture/sensor_view_configuration.adoc +++ b/doc/architecture/sensor_view_configuration.adoc @@ -35,4 +35,6 @@ In response to this difference, the sensor model can either accept this differen The packaging layer defines the specifics of this auto-negotiation mechanism. -After the initialization phase, the environment simulation provides the actual sensor-view configuration as part of each `SensorView` message. \ No newline at end of file +After the initialization phase, the environment simulation provides the actual sensor-view configuration as part of each `SensorView` message. + +For more details, see xref:gen:structosi3_1_1SensorViewConfiguration.adoc[]. \ No newline at end of file diff --git a/doc/architecture/streaming_update.adoc b/doc/architecture/streaming_update.adoc index 1bf661948..85378e47e 100644 --- a/doc/architecture/streaming_update.adoc +++ b/doc/architecture/streaming_update.adoc @@ -7,4 +7,6 @@ endif::[] The `StreamingUpdate` message provides an interface to transmit a subset of ground truth and/or vehicle internal data. This interface mainly addresses applications with low latency requirements and no need for highly consistent and complete data, e.g. visualization applications. Static and/or non-relevant objects can be omitted as required for the specific use case. -Note that the receiver of partial updates can only rely on the most up-to-date information at the corresponding timestamp. E.g. omitting objects does not indicate static behaviour but it may be sufficient for the use case to update certain objects at a later point in time. \ No newline at end of file +Note that the receiver of partial updates can only rely on the most up-to-date information at the corresponding timestamp. E.g. omitting objects does not indicate static behavior but it may be sufficient for the use case to update certain objects at a later point in time. + +For more details, see xref:gen:structosi3_1_1StreamingUpdate.adoc[]. \ No newline at end of file diff --git a/doc/architecture/traffic_command.adoc b/doc/architecture/traffic_command.adoc index f8cd90d24..ea34a63f2 100644 --- a/doc/architecture/traffic_command.adoc +++ b/doc/architecture/traffic_command.adoc @@ -4,4 +4,6 @@ include::{root-path}_config.adoc[] endif::[] = Traffic command -`TrafficCommand` messages contain control commands from the scenario engine to traffic participant models. \ No newline at end of file +`TrafficCommand` messages contain control commands from the scenario engine to traffic participant models. + +For more details, see xref:gen:structosi3_1_1TrafficCommand.adoc[]. \ No newline at end of file diff --git a/doc/architecture/traffic_command_update.adoc b/doc/architecture/traffic_command_update.adoc new file mode 100644 index 000000000..afd05cfc4 --- /dev/null +++ b/doc/architecture/traffic_command_update.adoc @@ -0,0 +1,9 @@ +ifndef::include-only-once[] +:root-path: ../ +include::{root-path}_config.adoc[] +endif::[] += Traffic command update + +`TrafficCommandUpdate` messages enable the traffic participant model to send updates to the scenario engine about the execution of its received xref:architecture/traffic_command.adoc[TrafficCommand] input. + +For more details, see xref:gen:structosi3_1_1TrafficCommandUpdate.adoc[]. \ No newline at end of file diff --git a/doc/architecture/traffic_update.adoc b/doc/architecture/traffic_update.adoc index 33461d23d..0dce99689 100644 --- a/doc/architecture/traffic_update.adoc +++ b/doc/architecture/traffic_update.adoc @@ -5,4 +5,6 @@ endif::[] = Traffic update `TrafficUpdate` messages are provided by traffic participants. -They provide updates on the position, state, and future trajectory of a traffic participant back to the simulation environment. \ No newline at end of file +They provide updates on the position, state, and future trajectory of a traffic participant back to the simulation environment. + +For more details, see xref:gen:structosi3_1_1TrafficUpdate.adoc[]. \ No newline at end of file diff --git a/doc/open-simulation-interface_user_guide.adoc b/doc/open-simulation-interface_user_guide.adoc index 69296d267..394b81448 100644 --- a/doc/open-simulation-interface_user_guide.adoc +++ b/doc/open-simulation-interface_user_guide.adoc @@ -21,8 +21,12 @@ include::./architecture/sensor_view_configuration.adoc[leveloffset=+3] include::./architecture/sensor_data.adoc[leveloffset=+3] +include::./architecture/host_vehicle_data.adoc[leveloffset=+3] + include::./architecture/traffic_command.adoc[leveloffset=+3] +include::./architecture/traffic_command_update.adoc[leveloffset=+3] + include::./architecture/motion_request.adoc[leveloffset=+3] include::./architecture/traffic_update.adoc[leveloffset=+3]