Prepare v100-rc.2 release (#280)

* Add small text proposals

* Rename  "Signal Abstraction layer" to correct "Physical Signal Abstraction layer" (fixed wording) (#274)

Co-authored-by: Benedikt Menne <[email protected]>

* Fix high-cut AUTOSAR example (#273)

* Fix high-cut AUTOSAR example

* Clarify AUTOSAR example description

---------

Co-authored-by: Benedikt Menne <[email protected]>

* Fixed "Remove clock redundancies within FMI-LS-BUS #165" (#272)

* Fixed "Remove clock redundancies within FMI-LS-BUS #165"

---------

Co-authored-by: Benedikt Menne <[email protected]>

* Fix and harmonize figure 7 description and colors (#278)

Co-authored-by: Benedikt Menne <[email protected]>

* Allow periodic clocks for input in high cut

As discussed in #276, the restriction to triggered clocks for inputs is not necessary, and actually less performant in the case of (quasi) fixed communication schedules, either due to actually statically scheduled busses, or due to the details of dynamic scheduling variations not mattering for the use case.

* Accept review feedback refinement

Co-authored-by: Christian Bertsch <[email protected]>

* Avoid using input or output for clocks in high-cut

* Make sentences about periodic/aperiodic non-normative

* Minor fixes

* Use name "TransmissionClock" in high cut examples

* Minor text changes in low cut

* Update RC.1 tags to RC.2 (#281)

Co-authored-by: Benedikt Menne <[email protected]>

* Set ls-version tags to 1.0.0-rc.2

---------

Co-authored-by: kahramon.jumayev <[email protected]>
Co-authored-by: Benedikt Menne <[email protected]>
Co-authored-by: Pierre R. Mai <[email protected]>
Co-authored-by: Christian Bertsch <[email protected]>
Co-authored-by: Klaus Schuch <[email protected]>

Author: 6 people

docs/1____introduction.adoc

@@ -32,15 +32,15 @@ This communication architecture can be operated by a common FMU importer and all
 
 This standard allows a highly accurate bus simulation using FMI 3.0 mechanisms.
 To profit from such accuracy on a system level to predict system behavior, all system simulation components must provide at least that level of accuracy.
-Focusing on single-virtual-ECUs use cases, such as protocol validation, accuracy requirements for the "rest-bus" can be relaxed.
+When focusing on single virtual ECU use cases, such as protocol validation, the accuracy requirements for the rest of the system can be relaxed.
 
 Contrary, on system level, the accuracy of the simulation depends on the accuracy of all its components.
-These components can be virtual ECUs, plant models, rest-bus simulators, data replay components and, of course, the bus simulation.
+These components can be virtual ECUs, plant models, residual bus simulators, data replay components and, of course, the bus simulation.
 A single low-accuracy component limits the overall system simulation accuracy.
-The level of detail of these run-time models determine the size of the window for send-message events.
-With virtual ECUs using the zero-time execution model footnote:[Simulated tasks are executed infinitely fast.], the time of send-message events can only be determined to be somewhere within the given smallest granularity of the virtual ECU's internal scheduler.
+The level of detail of these runtime models determine the size of the window for data transmission events.
+With virtual ECUs using the zero-time execution model footnote:[Simulated tasks are executed infinitely fast.], the time of data transmission can only be determined to be somewhere within the given smallest granularity of the virtual ECU's internal scheduler.
 More detailed models, like instruction set simulators or even System-C models of the hardware, can narrow the window for these events significantly.
-However, current modelling technologies, as of writing this standard, do not allow practical implementations in terms of modelling time and run time of virtual ECUs that can be used to simulate all realistic bus simulation effects, such as collision and arbitration events.
+However, current modelling technologies, as of writing this standard, do not allow practical implementations in terms of modelling time and runtime of virtual ECUs that can be used to simulate all realistic bus simulation effects, such as collision and arbitration events.
 
 === How to Read This Document [[introduction-how-to-read-this-document]]
 
@@ -80,7 +80,7 @@ This layered standard defines requires the use of a layered standard manifest fi
 
 |`fmi-ls-version`
 | `\http://fmi-standard.org/fmi-ls-manifest`
-| `1.0.0-rc.1`
+| `1.0.0-rc.2`
 | Version of the layered standard. This layered standard uses semantic versioning, as defined in <<PW13>>.
 
 |`fmi-ls-description`

docs/3____physical_signal_abstraction.adoc

@@ -20,37 +20,44 @@ The respective FMU variables are connected to a Bus Simulation, which emulates t
 image::high_cut_network_fmu.svg[width=80%, align="center"]
 
 === Variables [[high-cut-variables]]
-This section explains the different variable types used to carry network traffic through FMI input and output variables.
+This section explains the variable types used to carry network traffic through FMI variables.
 
 ==== Signal Variables [[high-cut-signal-variables]]
-To define the Physical Signal Abstraction layer, signal variables are defined.
+To define the Physical Signal Abstraction layer, signal variables are used.
 
 A signal variable carries the physical value of a network signal normally packaged inside a PDU or frame.
 The unit definition of the variable must match the one defined in the <<high-cut-network-description-files>>, if provided.
 
-Each network signal must be listed as <<high-cut-terminal-member-variable-for-signals>> of its corresponding <<high-cut-pdu-terminal>>.
+Each network signal must be listed as a <<high-cut-terminal-member-variable-for-signals>> of its corresponding <<high-cut-pdu-terminal>>.
 
-In case multiplexed signals are present in a frame/PDU/container PDU: All signals/PDUs are present, but only the active signal according to the multiplex switch signal contains a valid value, all inactive variables have undefined values _[those values could even be outside their specified min-max range without fault]_.
+In case multiplexed signals are present in a frame/PDU/container PDU:
+All signals/PDUs are present, but only the active signal according to the multiplex switch signal contains a valid value, all inactive variables have undefined values.
+_[These values could even be outside their specified min-max range without fault.]_
 
-All signal variables are clocked to exactly indicate when they have been sent, see <<high-cut-clock-variables>>.
+All signal variables are clocked to indicate when they have been sent/received, see <<high-cut-clock-variables>>.
 
 ==== Clock Variables [[high-cut-clock-variables]]
-In order to use FMU input and output variables as transport layer for networks, input and output Clocks are used.
+In order to use FMU input and output variables as transport layer for networks, Clocks are used to indicate the timing.
 Such a Clock is scheduled by the sending FMU to indicate the transmission of the corresponding frame or frames.
 
-The output Clock type, `periodic` or `aperiodic`, is defined by the sending FMU.
-This allows the FMU (or better the exporting tool) to balance the accuracy and performance of its network communication:
+The Clock type (`periodic` or `aperiodic`) is defined by the sending FMU.
 
- - While `aperiodic` Clocks allow very accurate network simulations, frequently entering `Event Mode` might reduce the network simulation speed.
- - Using `periodic` Clocks reduces the number of `Event Modes` required and might speeds up the simulation at the cost of simulation accuracy, because timing must be forced into a fixed grid and some intermediate values might not be transmitted.
- - One could use (structural) parameters to define the accuracy of `aperiodic` Clocks, allowing control of the simulation accuracy and performance with the same FMU.
- - The input Clocks shall be `triggered` Clocks.
+_[This allows the FMU (or better the exporting tool) to balance the accuracy and performance of its network communication:_
 
-The importer will then connect and merge output Clock activations, even those of different Clock types, and forwards them to the input Clocks, as required by the network semantics.
 
-Signal variables belonging to frame `BusName.FrameName` are triggered by the Clock `BusName.FrameName_Clock` and all these variables and their corresponding Clock must share the same `causality` (`input` or `output`).
+_- While `aperiodic` Clocks allow very accurate network simulations, frequently entering `Event Mode` might reduce the network simulation speed._
 
-_[Note: The statements regarding `aperiodic` and `periodic` Clocks and their impact on performance should be understood as general tendencies rather than universally valid truths, as other aspects such as baud rates and expected bus loads must be taken into account for a more precise estimate.]_
+_- Using `periodic` Clocks might reduces the number of `Event Modes` required and might speeds up the simulation at the cost of simulation accuracy, because timing must be forced into a fixed grid and some intermediate values might not be transmitted._
+
+_- One could use (structural) parameters to define the accuracy of `aperiodic` Clocks, allowing control of the simulation accuracy and performance with the same FMU._
+ 
+_Note: The statements regarding `aperiodic` and `periodic` Clocks and their impact on performance should be understood as general tendencies rather than universally valid truths, as other aspects such as baud rates and expected bus loads must be taken into account for a more precise estimate.]_
+ 
+The Clocks of a receiving frame shall be `triggered` Clocks if they are to be driven by the respective Clock of the sending frame.
+Alternatively, Clocks of a receiving frame can be `periodic` Clocks matching the relevant Clock of the sending frame, which causes them to be scheduled for the same time instances
+_[This may allow for more efficient simulation in the case that there exists a more or less static communications schedule, and more detailed simulation of timing variation is not needed.]_
+
+Signal variables belonging to frame `BusName.FrameName` and all its variables must share the same `causality` (`input` or `output`).
 
 === Network Description Files [[high-cut-network-description-files,network description file]]
 Standardized <<high-cut-network-description-files,network description files>> may optionally be shipped with each FMU to describe properties of signals and frames, such as signal units, frame composition and trigger conditions.
@@ -123,7 +130,7 @@ All <<high-cut-terminal-member-variable-for-signals,`TerminalMemberVariables`>>
 
 Attribute definitions::
  * `variableName` refers to the input or output variable name of the FMU.
-    These variables represent the Signal Abstraction layer.
+    These variables represent the Physical Signal Abstraction layer.
     Unless there are other requirements, it is recommended to build the variable names as follows: `BusName.FrameName.PDUName.SignalName`, e.g., `Powertrain.tcuSensors.tcuSensors.vCar`.
     This approach automatically provides unique names for all bus-related variables, and can also be used for the Clock variables, to allow automatic grouping by non-terminal-aware tools.
  * `memberName` is the `SignalName` as given in the <<high-cut-network-description-files>>, e.g., `vCar`, if given.
@@ -191,12 +198,12 @@ The following AUTOSAR system extract (in ARXML format) shows the mapping of an A
   <SHORT-NAME>SystemExtract</SHORT-NAME>
   <ELEMENTS>
     <CAN-CLUSTER>
-      <SHORT-NAME>Powertrain</SHORT-NAME>
+      <SHORT-NAME>PowertrainCluster</SHORT-NAME>
       <CAN-CLUSTER-VARIANTS>
         <CAN-CLUSTER-CONDITIONAL>
           <PHYSICAL-CHANNELS>
             <CAN-PHYSICAL-CHANNEL>
-              <SHORT-NAME>tcuSensors</SHORT-NAME>
+              <SHORT-NAME>Powertrain</SHORT-NAME>
               <FRAME-TRIGGERINGS>
                 <CAN-FRAME-TRIGGERING>
                   <SHORT-NAME>tcuSensors_FrameTriggering</SHORT-NAME>
@@ -250,6 +257,7 @@ The following file shows the <<high-cut-bus-terminal,Bus Terminal>> definition r
 The `name` of the <<high-cut-frame-terminal,frame terminal>> is derived from the ShortName attribute of the respective AUTOSAR frame.
 The `name` of the <<high-cut-pdu-terminal,PDU terminal>> is derived from the ShortName attribute of the respective AUTOSAR PDU.
 The `SignalName`, and so the resulting `memberName`, is derived from the respective AUTOSAR ISignal.
+The `BusName` is derived from the AUTOSAR Cluster ShortName concatenated via a `.` character with the AUTOSAR Physical Channel ShortName.
 
 .Example terminalsAndIcons.xml file.
 [[example-terminalsAndIconHighCut-autosar-xml]]

docs/4____network_abstraction.adoc

@@ -123,11 +123,11 @@ Sending a CAN frame is represented by the Bus Operation: CAN Transmit.
 Since the FMI-LS-BUS describes the simulation of network communication above the electrical level, not all content of a CAN frame is relevant.
 The corresponding argument values ​​do not have to be analogous to those of the original frame representation.
 Argument values can be transformed, i.e., presented in a different form, for easier use.
-<<figure-bus-operation-can-frame-mapping-example>> illustrates the mapping between the FMI-LS-BUS CAN Transmit Bus Operation and a CAN Standard Data Frame. 
+<<figure-bus-operation-can-frame-mapping-example>> illustrates the mapping between the FMI-LS-BUS CAN Transmit Bus Operation and a Standard CAN Data Frame. 
 The information that can be mapped directly is shown in green.
 The yellow representation describes transformed values and the information shown in red is not required/used.
 
-.Mapping between the FMI-LS-BUS CAN Transmit Bus Operation and a CAN Standard Data Frame.
+.Mapping between the FMI-LS-BUS CAN Transmit Bus Operation and a Standard CAN Data Frame.
 [#figure-bus-operation-can-frame-mapping-example]
 image::bus_operation_can_frame_mapping_example.svg[width=65%, align="center"]
 
@@ -208,7 +208,7 @@ Since Clock variables are strictly related to the `Event Mode`, networked FMUs s
 The point in time where Bus Operations are transferred from the `Tx_Data` to the `Rx_Data` variables is defined by the `Tx_Clock` variable.
 This point is also referred to as the Bus Communication Point.
 A Bus Communication Point and a regular communication point can take place at the same time, but should be considered as independent by the importer.
-In contrast to a regular communication point where input/output variables used in step mode are exchanged, only the clocked Tx/Rx data variables need to be considered by the importer.
+In contrast to a regular communication point where input/output variables used in `Step Mode` are exchanged, only the clocked Tx/Rx data variables need to be considered by the importer.
 
 For defining the point in time of a Bus Communication Point, `time-based` or `triggered` Clocks can be used for the `Tx_Clock` variable.
 Hence the Clock type can influence the bus simulation significantly - the differences should be taken into account.
@@ -236,23 +236,23 @@ To make sure that the `Rx_Data` variables is set properly, an importer has to ac
 
 _[Note: For clarity always a direct connection line between the `Tx_Clock` and `Rx_Clock` variables is shown in figures of this document.]_
 
-A `time-based` Clock can be `periodic` or `aperiodic`.
+_A `time-based` Clock can be `periodic` or `aperiodic`.
 Both allow defining Bus Communication Points independently of the regular communication points with fixed or variable distances.
-The difference between the two Clock types is listed in the following table.
+<<table-tx-clock-properties>> describes how the usage of different FMI Clock types affects how Bus Communication Points are realized inside the specified FMU._
 
 .Time-based Clock properties.
 [#table-tx-clock-properties]
 [cols="3,1,7"]
 |====
 h|Clock properties h|intervalVariability h|Description
-|`periodic`|`constant`|The Bus Communication Point interval is defined in the `modelDescription.xml`.
-|`periodic`|`fixed`|The Bus Communication Point interval is defined in the `modelDescription.xml` or must be provided in `Initialization Mode`.
-|`periodic`|`tunable`|The Bus Communication Point interval is defined in the `modelDescription.xml` or must be provided in `Initialization Mode` and can be changed in `Event Mode`.
-|`aperiodic`|`changing`|The Bus Communication Point interval must be provided in `Initialization Mode` and can be changed in `Event Mode` if this Clock ticked.
-|`aperiodic`|`countdown`|The Bus Communication Point interval must be provided in `Initialization Mode` and can be changed in every `Event Mode`.
+|`periodic`|`constant`|_The Bus Communication Point interval is defined in the `modelDescription.xml` and is constant during simulation._
+|`periodic`|`fixed`|_The Bus Communication Point interval gets fixed during `Initialization Mode` and stays fixed during simulation._
+|`periodic`|`tunable`|_The Bus Communication Point interval can change in any `Event Mode`._
+|`aperiodic`|`changing`|_The Bus Communication Point interval can change in any `Event Mode` if this Clock ticked._
+|`aperiodic`|`countdown`|_The Bus Communication Point interval can change in any `Event Mode`, where the interval can also be unknown in some `Event Mode`._
 |====
 
-Network FMUs using a `time-based` `Tx_Clock` variable should set the Co-Simulation attribute `canHandleVariableCommunicationStepSize = "true"` in the model description file, since `fmi3DoStep` is typically called with variable `communicationStepSize`.
+_Network FMUs using a `time-based` `Tx_Clock` variable should set the Co-Simulation attribute `canHandleVariableCommunicationStepSize = "true"` in the model description file, since `fmi3DoStep` is typically called with variable `communicationStepSize`._
 
 ===== Triggered Tx Clock Variables [[low-cut-tx-triggered-clock-variables]]
 A `triggered` Clock basically allows signalling events when returning from `fmi3DoStep` either by using an `Early Return` or when the requested communication point at latexmath:[t_{i+1}] was reached.
@@ -269,15 +269,15 @@ image::low_cut_communication_with_triggered_tx_clock.svg[width=100%, align="cent
 The input Clocks (`Rx_Clock`) shall be `triggered` Clocks.
 
 ==== Tx/Rx Data Variables [[low-cut-tx-rx-data-variables, Communication Variables]]
-The Tx/Rx variables are of type `fmi3Binary` and contain multiple Bus Operations, as sent or receive by the FMU.
+The `Tx_Data`/`Rx_Data` variables are of type `fmi3Binary` and may contain zero, one or multiple Bus Operations, as sent or received by the FMU.
 If no Bus Operations shall be sent by a specified Network FMU at a given Bus Communication Point, the size of the corresponding binary `Tx_Data` variable shall be set to zero.
-The senders can choose how many Bus Operations are buffered and/or for how long operations are buffered before activating an output Clock to trigger the actual sending of these operations.
+Sender FMUs can choose how many Bus Operations are buffered and/or for how long operations are buffered before activating an output Clock to trigger the actual sending of these operations.
 This allows senders to trade accuracy for speed: Buffering more and interrupting the simulation less will lead to faster simulations, but less accurate timing of the network communication.
 
 ==== Selecting the type of Tx Clock [[low-cut-selecting-tx-variables]]
-Selecting suitable Tx variables allows the FMU (or better the exporting tool) to balance the accuracy and performance of its network communication:
+Selecting a suitable `intervalVariability` for `Tx Clock' allows the FMU (or better the exporting tool) to balance the accuracy and performance of its network communication:
 
- - While `aperiodic` Clocks allow very accurate network simulations, frequently entering `Event Mode` migth reduce the network simulation speed.
+ - While `aperiodic` Clocks allow very accurate network simulations, frequently entering `Event Mode` might reduce the network simulation speed.
  - Using `periodic` Clocks and queueing the operations to be transmitted reduces the number of `Event Mode` entries and might speeds up the simulation at the cost of simulation accuracy.
  - One could use (structural) parameters to define the accuracy of `aperiodic` Clocks, allowing control of the simulation accuracy and performance with the same FMU.
 
@@ -296,7 +296,7 @@ The following table lists the MIME types to use for the Tx/Rx data variables wit
 |MIME type
 |Description
 
-|application/org.fmi-standard.fmi-ls-bus.can; version="1.0.0-rc.1"
+|application/org.fmi-standard.fmi-ls-bus.can; version="1.0.0-rc.2"
 |Binary variables simulating a CAN network including CAN, CAN FD and CAN XL
 
 |====

docs/examples/X_network4FMI_modelDescription_highCut_autosar.xml

@@ -2,11 +2,11 @@
 <fmiModelDescription fmiVersion="3.0" modelName="Network4FMI"
     instantiationToken="Network4FMI">
   <ModelVariables>
-    <Clock name="Powertrain.tcuSensors_FrameTriggering_Clock" valueReference="1007"
+    <Clock name="PowertrainCluster.Powertrain.tcuSensors_FrameTriggering_Clock" valueReference="1007"
         causality="input" variability="discrete" intervalVariability="triggered"/>
-    <Float64 name="Powertrain.tcuSensors.vCar_ISignalTriggering" valueReference="1005"
+    <Float64 name="PowertrainCluster.Powertrain.tcuSensors.vCar_ISignalTriggering" valueReference="1005"
         causality="input" variability="discrete" start="0" clocks="1007"/>
-    <Float64 name="Powertrain.tcuSensors.oilTemp_ISignalTriggering" valueReference="1006"
+    <Float64 name="PowertrainCluster.Powertrain.tcuSensors.oilTemp_ISignalTriggering" valueReference="1006"
         causality="input" variability="discrete" start="20" clocks="1007"/>
   </ModelVariables>
   <ModelStructure>