add documentation for motion request input and output

Signed-off-by: Daniel Becker <daniel.becker@ika.rwth-aachen.de>

Author: Daniel Becker

doc/spec/motion_request_inputs.adoc

@@ -0,0 +1,29 @@
+ifndef::include-only-once[]
+:root-path: ../
+include::{root-path}_config.adoc[]
+endif::[]
+= Motion request inputs
+
+This message is intended as an interface between a behavior model (e.g. driver model or HAD function) and the actuator management.
+Either a desired future trajectory or a desired future state may be sent.
+
+**Prefix**
+
+Motion request inputs shall be named with the following prefix:
+
+[source,protobuf]
+----
+OSMPMotionRequestIn
+----
+
+**Rules**
+
+* If only one motion request input is configured, the prefix shall only be `OSMPMotionRequestIn`.
+* If more than one motion request input is configured, the prefix shall be extended by an array index, for example, `OSMPMotionRequestIn[1]` and `OSMPMotionRequestIn[2]`.
+* Array indices shall start at 1 and shall be consecutive.
+* Each motion request input shall be defined as a notional discrete binary input variable with `@causality="input"` and `@variability="discrete"`.
+* The MIME type of the variable shall specify the `type=MotionRequest` as part of the MIME type parameters.
+* Motion request data shall be encoded as `osi3::MotionRequest`.
+* The motion request passed to the FMU must contain one of the available ``OutputOptions``. In addition to the enumerator, the corresponding ``DesiredState`` or ``Trajectory`` has to be set, respectively.
+* The guaranteed lifetime of the motion request protocol-buffer pointer provided as input to the FMU shall be from the time of the call to `fmi2SetInteger` that provides those values until the end of the following `fmi2DoStep` call.
+ 

doc/spec/motion_request_outputs.adoc

@@ -0,0 +1,29 @@
+ifndef::include-only-once[]
+:root-path: ../
+include::{root-path}_config.adoc[]
+endif::[]
+= Motion request outputs
+
+This message is intended as an interface between a behavior model (e.g. driver model or HAD function) and the actuator management.
+Either a desired future trajectory or a desired future state may be sent.
+
+**Prefix**
+
+Motion request outputs shall be named with the following prefix:
+
+[source,protobuf]
+----
+OSMPMotionRequestOut
+----
+
+**Rules**
+
+* If only one motion request input is configured, the prefix shall only be `OSMPMotionRequestOut`.
+* If more than one motion request input is configured, the prefix shall be extended by an array index, for example, `OSMPMotionRequestOut[1]` and `OSMPMotionRequestOut[2]`.
+* Array indices shall start at 1 and shall be consecutive.
+* Each motion request input shall be defined as a notional discrete binary input variable with `@causality="input"` and `@variability="discrete"`.
+* The MIME type of the variable shall specify the `type=MotionRequest` as part of the MIME type parameters.
+* Motion request data shall be encoded as `osi3::MotionRequest`.
+* The motion request passed to the FMU must contain one of the available ``OutputOptions``. In addition to the enumerator, the corresponding ``DesiredState`` or ``Trajectory`` has to be set, respectively.
+* The guaranteed lifetime of the motion request protocol-buffer pointer provided as input to the FMU shall be from the time of the call to `fmi2SetInteger` that provides those values until the end of the following `fmi2DoStep` call.
+