diff --git a/doc/spec/motion_request_inputs.adoc b/doc/spec/motion_request_inputs.adoc new file mode 100644 index 0000000..a78754b --- /dev/null +++ b/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 ``MotionRequestType``. 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. + diff --git a/doc/spec/motion_request_outputs.adoc b/doc/spec/motion_request_outputs.adoc new file mode 100644 index 0000000..451cfaf --- /dev/null +++ b/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 output is configured, the prefix shall only be `OSMPMotionRequestOut`. +* If more than one motion request output 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 output shall be defined as a notional discrete binary output variable with `@causality="output"` 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 ``MotionRequestType``. 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 output 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. +