Update pictures and documentation for MotionRequest

Signed-off-by: Markus Lemmer <lemmer@fzi.de>

Author: lemmer-fzi

doc/architecture/architecture_overview.adoc

@@ -34,7 +34,7 @@ image::{images_open_simulation_interface}/osi-traffic-participant-advanced.png[1
 
 The `HostVehicleData` interface describes the measured internal states of a traffic participant.
 OSI currently provides only limited support for data structures that describe measured internal states of traffic participants.
-Actuator intentions are currently not covered by OSI and must be handled using a different data description format.
+One example would be the `MotionRequest` interface that can be used to commuciate the results of the behavior planning to the dynamic model.
 
 NOTE: OSI uses singular instead of plural for `repeated` field names.
 

doc/architecture/motion_request.adoc

@@ -0,0 +1,8 @@
+ifndef::include-only-once[]
+:root-path: ../
+include::{root-path}_config.adoc[]
+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.

doc/architecture/traffic_participant.adoc

@@ -22,8 +22,8 @@ The following figure shows the interface of a traffic participant.
 .Interface of a traffic participant
 image::{images_open_simulation_interface}/osi-traffic-participant-principle.png[1100]
 
-Traffic participant models may use other OSI interfaces internally, for example, to model autonomous vehicles.
-The following figure shows a more advanced use case for traffic participants.
+Traffic participant models may use other OSI interfaces, for example, the `SensorDate` and `MotionRequest` message, internally.
+The following figure shows a more advanced use case for traffic participants, that can, for example, be used to model an autonomous vehicle.
 
 [#fig-traffic-participant-other-osi-interfaces]
 .Traffic participant using other OSI interfaces internally

doc/images/osi-traffic-participant-advanced.png

@@ -25,6 +25,8 @@ include::./architecture/sensor_data.adoc[leveloffset=+3]
 
 include::./architecture/traffic_command.adoc[leveloffset=+3]
 
+include::./architecture/motion_request.adoc[leveloffset=+3]
+
 include::./architecture/traffic_update.adoc[leveloffset=+3]
 
 === Model types

doc/images/osi-traffic-participant-principle.png

@@ -28,8 +28,7 @@ The following figure shows a traffic participant with separately modeled behavio
 image::{images_open_simulation_interface}/osi-traffic-participant-use-case-2.png[1100]
 
 OSI currently provides only limited support for data structures that describe measured internal states of the traffic participant.
-OSI does not currently cover actuator intentions.
-These must be handled with a different data description format.
+An example for a traffic participant interface is the `MotionRequest` message that can be used to communicate planned behaviors from a behavior planning model to a dynamics model including, for example motion controllers and vehicle dynamics.
 
 The following figure shows a more complex traffic participant.
 
@@ -41,7 +40,6 @@ This use case will probably be relevant for modeling the ego vehicle, which incl
 The traffic participant includes an arbitrary number of sensor models.
 The sensor models consume sensor view and produce sensor data.
 The AD function consumes sensor data and produces input for the dynamics model.
-OSI currently does not support data flow to dynamics models.
 The loop to the environment simulation is closed via traffic update.
 
 The following figure shows a cooperative use case with both an AD function and a human driver.
@@ -54,4 +52,4 @@ It is possible to model a traffic participant with an AD function in the loop, b
 This type of cooperative use case is, for example, relevant to studies on human-machine interaction.
 In this example, a virtual on-screen representation of the scenario, or mock-up, is added after the AD function.
 The driver-in-the-loop interacts with the dynamics model via this mock-up.
-OSI's limitations regarding dynamics-model input apply in this example as well.
+OSI currently provides only limited interfaces for data flow between the driver and the dynamics model.