OpenSimulationInterface · stefancyliax · Oct 28, 2021 · Oct 26, 2021 · Oct 26, 2021 · Oct 26, 2021
diff --git a/doc/architecture/environmental_effect_model.adoc b/doc/architecture/environmental_effect_model.adoc
@@ -1,9 +1,9 @@
 = Environmental effect model
 
-Environmental effect models consume sensor-view messages and produce sensor-view messages.
-Environmental effect models may, for example, alter sensor-view messages to include effects and phenomena caused by:
+Environmental effect models consume `SensorView` messages and produce `SensorView` messages.
+Environmental effect models may, for example, alter `SensorView` messages to include effects and phenomena caused by:
 
 * Shadows and occlusions
 * Weather effects
 * Physics of a sensor
-* Pre-processing of raw sensor data
+* Pre-processing of raw sensor data
diff --git a/doc/architecture/feature_data.adoc b/doc/architecture/feature_data.adoc
@@ -1,5 +1,5 @@
 = Feature data
 
-Feature-data messages contain detected features in the reference frame of a sensor.
-Feature-data messages are generated from ground-truth messages.
+`FeatureData` messages 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.
diff --git a/doc/architecture/formatting_scripts.adoc b/doc/architecture/formatting_scripts.adoc
@@ -49,4 +49,4 @@ The default value is `None`.
 
 **Related topics**
 
-* <<#top-1a2f4b0c-195c-4f18-89ad-d48a123bd8c1>>[OSI trace file formats]
+* <<_osi_trace_file_formats>>
diff --git a/doc/architecture/ground_truth.adoc b/doc/architecture/ground_truth.adoc
@@ -1,5 +1,5 @@
 = Ground truth
 
-Ground-truth messages describe the simulated environment containing all simulated objects in the global coordinate system at consecutive time instances.
+`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.
-Ground-truth messages are typically contained in sensor view messages.
+`GroundTruth` messages are typically contained in `Sensorview` messages.
diff --git a/doc/architecture/logical_model.adoc b/doc/architecture/logical_model.adoc
@@ -1,6 +1,6 @@
 = Logical model
 
-Logical models consume sensor-data messages and produce sensor-data messages.
+Logical models consume `SensorData` messages and produce `SensorData` messages.
 
 An example of a logical model is a sensor-fusion model, which combines the output of multiple sensor models to produce data with less uncertainty.
 Another use case is the fault-injection model which, contrary to a sensor-fusion model, may be used to increase uncertainties.
diff --git a/doc/architecture/sensor_data.adoc b/doc/architecture/sensor_data.adoc
@@ -1,7 +1,7 @@
 = Sensor data
 
-Sensor-data messages imitate the output of real sensors.
-They can be generated from ground-truth messages, sensor-view messages, feature-data messages, or sensor-data messages.
+`SensorData` messages imitate the output of real sensors.
+They can be generated from `GroundTruth` messages, `SensorView` messages, `FeatureData` messages, or `SensorData` messages.
 With the exception of feature data, all information regarding the environment is given with respect to the virtual sensor coordinate system.
 Feature data is given with respect to the physical sensor coordinate system.
 Sensor data can be used as input for an automated driving function, a sensor model simulating limited perception, or a sensor fusion model.
diff --git a/doc/architecture/sensor_model.adoc b/doc/architecture/sensor_model.adoc
@@ -1,5 +1,4 @@
 = Sensor model
 
-Sensor models consume sensor-view messages and produce sensor-data messages.
-
+Sensor models consume `SensorView` messages and produce `SensorData` messages.
 Sensor-model output does not represent raw data but detected features or classified objects.
diff --git a/doc/architecture/sensor_view.adoc b/doc/architecture/sensor_view.adoc
@@ -1,7 +1,7 @@
 = Sensor view
 
 The sensor view provides the input to OSI sensor models.
-Sensor-view messages are derived from ground-truth messages.
+`SensorView` messages are derived from `GroundTruth` messages.
 All information regarding the environment is given with respect to the virtual sensor coordinate system, with two exceptions:
 
 * Physical technology-specific data, given with respect to the physical sensor coordinate system specified in the corresponding physical sensor's mounting position.

diff --git a/doc/architecture/sensor_view_configuration.adoc b/doc/architecture/sensor_view_configuration.adoc
@@ -1,27 +1,27 @@
-= Sensor view configuration
+= Sensor-view configuration
 
 The sensor view is flexibly defined to provide different kinds of sensor models with an appropriate input.
-The sensor view configuration defines the configuration of a particular sensor view.
+The sensor-view configuration defines the configuration of a particular sensor view.
 
-The sensor-view-configuration message is used in the initialization phase of a simulation to negotiate the sensor view configuration for a particular sensor view input.
-It is also included as a sub-message in sensor view messages to indicate that the sensor view configuration is valid for a particular sensor view message.
+The `SensorViewConfiguration` message is used in the initialization phase of a simulation to negotiate the sensor-view configuration for a particular `SensorView` input.
+It is also included as a sub-message in `SensorView` messages to indicate that the sensor-view configuration is valid for a particular `SensorView` message.
 
-Sensor-view-configuration data has two main applications:
+`SensorViewConfiguration` data has two main applications:
 
-- Enable the environment simulation to provide the necessary input to a sensor model.
-- Enable a sensor model to check whether the input matches its requirements.
+* Enable the environment simulation to provide the necessary input to a sensor model.
+* Enable a sensor model to check whether the input matches its requirements.
 If the input does not match the requirements, the sensor model may terminate the simulation.
 
-NOTE: Sensor-view-configuration data is intended for the automatic configuration of the sensor view interface between an environment simulation and sensor model.
+NOTE: `SensorViewConfiguration` data is intended for the automatic configuration of the `SensorView` interface between an environment simulation and sensor model.
 The data is not intended to be a mechanism for parametrizing a generic sensor model.
 
-During the initialization phase, there are two sources for sensor-view-configuration data:
+During the initialization phase, there are two sources for `SensorViewConfiguration` data:
 
-1. Sensor-view configuration data may be provided by the sensor model to the environment simulation.
+. `SensorViewConfiguration` data may be provided by the sensor model to the environment simulation.
 In this case, the data describes the input configuration that is requested by the sensor model.
 If the sensor model does not provide such data, then the environment simulation will fall back to manual configuration of the sensor view.
-
-2. Sensor-view configuration data may be provided by the environment simulation.
++
+. `SensorViewConfiguration` data may be provided by the environment simulation.
 In response to the request by the sensor model, or based on manual configuration, the environment simulation configures the input and provides a new message that describes the actual configuration.
 
 The configuration requested by the sensor model may differ from the configuration provided by the environment simulation.
@@ -31,4 +31,4 @@ 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 sensor view message.
+After the initialization phase, the environment simulation provides the actual sensor-view configuration as part of each `SensorView` message.
diff --git a/doc/architecture/trace_file_formats.adoc b/doc/architecture/trace_file_formats.adoc
@@ -1,4 +1,3 @@
-[#top-1a2f4b0c-195c-4f18-89ad-d48a123bd8c1]
 = OSI trace file formats
 
 There are multiple formats for storing multiple serialized OSI messages in one trace file.

diff --git a/doc/architecture/trace_file_naming.adoc b/doc/architecture/trace_file_naming.adoc
@@ -11,19 +11,19 @@ The names of OSI trace files should have the following format:
 **Types**
 
 `sd`::
-Trace file contains sensor-data messages.
+Trace file contains `SensorData` messages.
 
 `sv`::
-Trace file contains sensor-view messages.
+Trace file contains `SensorView` messages.
 
 `gt`::
-Trace file contains ground-truth messages.
+Trace file contains `GroundTruth` messages.
 
 `tu`::
-Trace file contains traffic-update messages.
+Trace file contains `TrafficUpdate` messages.
 
 `tc`::
-Trace file contains traffic-command messages.
+Trace file contains `TrafficCommand` messages.
 
 
 **Example**

diff --git a/doc/architecture/traffic_command.adoc b/doc/architecture/traffic_command.adoc
@@ -1,3 +1,3 @@
 = Traffic command
 
-Traffic-command 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.
diff --git a/doc/architecture/traffic_update.adoc b/doc/architecture/traffic_update.adoc
@@ -1,4 +1,4 @@
 = Traffic update
 
-Traffic-update messages are provided by traffic participants.
+`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.
diff --git a/doc/misc/osi_reference.adoc b/doc/misc/osi_reference.adoc
diff --git a/doc/misc/osi_vision.adoc b/doc/misc/osi_vision.adoc
@@ -1,5 +1,5 @@
 = Idea behind Open Simulation Interface
 
-The Open Simulation Interface (OSI) is a specification for interfaces between models and components of a distributed simulation.
+{THIS_STANDARD} Open Simulation Interface is a specification for interfaces between models and components of a distributed simulation.
 OSI is strongly focused on the environmental perception of automated driving functions.
 However, OSI also specifies interfaces for modeling traffic participants.
diff --git a/doc/open-simulation-interface_user_guide.adoc b/doc/open-simulation-interface_user_guide.adoc
@@ -50,7 +50,7 @@ include::./architecture/logical_model.adoc[leveloffset=+3]
 
 include::./architecture/traffic_participant.adoc[leveloffset=+3]
 
-include::./usecases/modeling_traffic_participant.adoc[leveloffset=+3]
+include::./usecases/modeling_traffic_participant.adoc[leveloffset=+4]
 
 //include::./architecture/vehicle_dynamics.adoc[leveloffset=+3]
 
@@ -115,27 +115,3 @@ include::./setup/installing_windows_python.adoc[leveloffset=+2]
 //== Improving performance
 
 //TODO: Define topics and issues regarding performance.
-
-include::./misc/osi_reference.adoc[leveloffset=+1]
-
-== Releases
-
-include::./releases/versioning.adoc[leveloffset=+2]
-
-include::./releases/releases.adoc[leveloffset=+2]
-
-include::./releases/v02.00.adoc[leveloffset=+3]
-
-include::./releases/v02.01.adoc[leveloffset=+3]
-
-include::./releases/v02.02.adoc[leveloffset=+3]
-
-include::./releases/v03.00.adoc[leveloffset=+3]
-
-include::./releases/v03.01.adoc[leveloffset=+3]
-
-include::./releases/v03.02.adoc[leveloffset=+3]
-
-include::./releases/v03.03.adoc[leveloffset=+3]
-
-//include::./releases/compatibility.adoc[leveloffset=+2]
diff --git a/doc/releases/compatibility.adoc b/doc/releases/compatibility.adoc
diff --git a/doc/releases/releases.adoc b/doc/releases/releases.adoc
diff --git a/doc/releases/v02.00.adoc b/doc/releases/v02.00.adoc
diff --git a/doc/releases/v02.01.adoc b/doc/releases/v02.01.adoc
diff --git a/doc/releases/v02.02.adoc b/doc/releases/v02.02.adoc
diff --git a/doc/releases/v03.00.adoc b/doc/releases/v03.00.adoc
Original file line number	Diff line number	Diff line change
Expand Up		@@ -49,4 +49,4 @@ The default value is `None`.

		Related topics

		* <<#top-1a2f4b0c-195c-4f18-89ad-d48a123bd8c1>>[OSI trace file formats]
		* <<_osi_trace_file_formats>>