Merge pull request #78 from OpenSimulationInterface/documentation/native-speaker-review

docs: minor corrections according to native speaker review

Author: Stefan Cyliax

doc/misc/example.adoc

@@ -1,6 +1,6 @@
 = Example: Simple sensor model FMU
 
-Then following example shows the content of a `modelDescription.xml` file that satisfies the requirements of OSMP.
+The following example shows the content of a `modelDescription.xml` file that satisfies OSMP requirements.
 The example describes a sensor model FMU with one input, one output, and no additional features:
 
 [source,xml]

doc/setup/build_install_example.adoc

@@ -26,7 +26,7 @@ Demonstrates a simple C network proxy that can send and receive OSI data via TCP
 git clone https://github.com/OpenSimulationInterface/osi-sensor-model-packaging.git
 ----
 +
-. Change into the OSMP repository.
+. Switch to the OSMP repository.
 +
 [source]
 ----
@@ -40,7 +40,7 @@ cd osi-sensor-model-packaging
 git submodule update --init
 ----
 +
-. Change into the `examples/` directory.
+. Switch to the `examples/` directory.
 +
 [source]
 ----
@@ -54,7 +54,7 @@ cd examples
 mkdir -p build
 ----
 +
-. Change into the `build/` directory.
+. Switch to the `build/` directory.
 +
 [source]
 ----

doc/spec/binary_variables.adoc

@@ -1,7 +1,7 @@
 = Binary variables
 
 FMI 2.0 does not directly support the efficient exchange of arbitrary binary data between FMUs.
-OSMP, therefore, introduces the concept of notional binary variables, which are mapped to actual integer variables for use with FMI 2.0.
+OSMP therefore introduces the concept of notional binary variables that are mapped to actual integer variables for use with FMI 2.0.
 Future FMI versions will directly support binary variables compatible with this concept.
 
 A notional binary variable named `<prefix>` is defined using the following conventions:
@@ -14,9 +14,9 @@ This restriction ensures that there is no conflict between notional binary varia
 For each notional binary variable, three actual FMU integer variables shall be defined:
 
 `<prefix>.base.lo`::
-Lower, meaning least significant, 32-bit address part of the binary data buffer to be passed into or out of the model, cast into a signed 32-bit integer without changing the bit values.
+Lower, meaning the least significant, 32-bit address part of the binary data buffer to be passed into or out of the model, cast into a signed 32-bit integer without changing the bit values.
 `<prefix>.base.hi`::
-Higher, meaning most significant, 32-bit address part of the binary data buffer to be passed into or out of the model, cast into a signed 32-bit integer without changing the bit values.
+Higher, meaning the most significant, 32-bit address part of the binary data buffer to be passed into or out of the model, cast into a signed 32-bit integer without changing the bit values.
 Note that this variable is only used for 64-bit platforms.
 For 32-bit platforms, it shall still be present but will always be 0 to support FMUs with 32-bit and 64-bit implementations.
 `<prefix>.size`::
@@ -40,7 +40,7 @@ The three actual variables shall contain an annotation of the following form in
 
 `<prefix>` is the prefix as defined above, and `@role` is either `base.lo`, `base.hi`, or `size`, depending on the variable.
 
-It is an error if there is not exactly one variable of each role for the same name.
+There is an error if there is not exactly one variable of each role for the same name.
 
 The MIME type given in `@mime-type` shall be a valid MIME type specification.
 

doc/spec/model_types.adoc

@@ -24,4 +24,4 @@ They may also consume `osi3::TrafficCommand` as input to allow control by a scen
 All models may also consume a global `osi3::GroundTruth` parameter during initialization.
 
 Complex models may combine various aspects of the above model types.
-Configuration and setup of such FMUs require manual intervention.
+Manual intervention is needed to configure and set up these FMUs.

doc/spec/traffic_command_inputs.adoc

@@ -1,7 +1,7 @@
 = Traffic command inputs
 
 Traffic command inputs are present in traffic participant models.
-This allows control of the traffic participant behavior by scenario engines.
+This makes it possible to control of the traffic participant behavior using scenario engines.
 
 **Prefix**
 
@@ -14,9 +14,9 @@ Traffic command inputs shall be named with the following prefix:
 
 **Rules**
 
-* If only one traffic command input is configured, the prefix shall only be `OSMPTrafficCommandIn`. 
-* If more than one traffic command input is configured, the prefix shall be extended by an array index designator, for example `OSMPTrafficCommandIn[1]` and `OSMPTrafficCommandIn[2]`. 
-* Array indices shall start at 1 and shall be consecutive. 
+* If only one traffic command input is configured, the prefix shall only be `OSMPTrafficCommandIn`.
+* If more than one traffic command input is configured, the prefix shall be extended by an array index designator, for example `OSMPTrafficCommandIn[1]` and `OSMPTrafficCommandIn[2]`.
+* Array indices shall start at 1 and shall be consecutive.
 * Each traffic command 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="TrafficCommand"` as part of the MIME type parameters.
 * Traffic commands shall be encoded as `osi3::TrafficCommand`.