Issue #836: Added missing pages and linked them in navigation.

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.
 

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.
+`GroundTruth` messages are typically contained in `Sensorview` messages.
+
+For more details, see xref:gen:structosi3_1_1GroundTruth.adoc[].

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[].

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.
+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[].

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[].

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.
+* Ground truth given in the global coordinate system.
+
+For more details, see xref:gen:structosi3_1_1SensorView.adoc[].

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.
+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[].

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.
+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[].

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.
+`TrafficCommand` messages contain control commands from the scenario engine to traffic participant models.
+
+For more details, see xref:gen:structosi3_1_1TrafficCommand.adoc[].

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[].

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.
+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[].

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]