Homogenization of "Physical Signal Abstraction" and "Network Abstract…

…ion" wording

docs/1____introduction.adoc

@@ -10,14 +10,14 @@ At this point it should be explicitly mentioned that this layered standard not o
 
 There are mainly two base use cases envisioned here:
 
-* Physical signal abstraction (or High-Cut) to simply transport physical signal values between virtual ECUs. +
+* Physical Signal Abstraction (or High-Cut) to simply transport physical signal values between virtual ECUs. +
 The network properties are largely idealized: infinite bandwidth, zero-delay etc.
 Signals, groups of signals and their properties _(e.g., units)_ are usually derived from (existing and validated) standard network topology description formats _(such as DBC, LDF, Fibex and ARXML)_.
-* Network abstraction (or Low-Cut) to realize virtualized bus driver implementations footnote:[In AUTOSAR context this means a driver implementation within the MicroController Abstraction Layer (MCAL)]. +
+* Network Abstraction (or Low-Cut) to realize virtualized bus driver implementations footnote:[In AUTOSAR context this means a driver implementation within the MicroController Abstraction Layer (MCAL)]. +
 This transport layer emulation allows anything from idealized to more detailed network simulations, including bandwidth restrictions, message arbitration and delays.
 It forwards the network payloads using binary variables.
 The Low-Cut abstraction layer is meant to allow virtualized bus driver implementations, including feedback from the physical drivers about transmission status or network node states.
-Since the network abstraction layer is protocol-independent, it can also be used for the simulation of non-automotive control units, _e.g., from the field of industrial automation_.
+Since the Network Abstraction layer is protocol-independent, it can also be used for the simulation of non-automotive control units, _e.g., from the field of industrial automation_.
 
 So that this layered standard can be supported in a variety of FMU importers and other types of simulators three possible communication architectures for bus communication are specified:
 
@@ -84,7 +84,7 @@ This layered standard defines requires the use of a layered standard manifest fi
 
 |`fmi-ls-description`
 | `\http://fmi-standard.org/fmi-ls-manifest`
-| `Layered Standard for the simulation of bus communication on a signal or network abstraction based level.`
+| `Layered Standard for the simulation of bus communication on a Physical Signal Abstraction or Network Abstraction based level.`
 | String with a brief description of the layered standard that is suitable for display to users.
 
 |`isBusSimulationFMU`

docs/2____common_concepts.adoc

@@ -1,15 +1,15 @@
 == Common Concepts [[common-concepts]]
-Physical signal abstraction and network abstraction layers represent different levels for the exchange of bus messages.
-Physical signal abstraction focuses primarily on the exchange of signal values, while network abstraction provides a complete way of implementing a virtual bus driver.
+Physical Signal Abstraction and Network Abstraction layers represent different levels for the exchange of bus messages.
+Physical Signal Abstraction focuses primarily on the exchange of signal values, while Network Abstraction provides a complete way of implementing a virtual bus driver.
 Depending on the exporting tool, one of the abstraction layers is more "natural" to the FMU, while the other might have to be emulated with additional internal effort or an adapter (FMU) could be used.
 Importers on the other hand rarely require both abstraction layers for system level compositions, because the engineering tasks define the required level of abstraction for the network communication.
 FMUs may choose to only support one abstraction layer providing only the corresponding variables.
 However, for versatility, having FMUs capable of communicating on both abstraction layers is more convenient for users.
 
-In both the physical signal abstraction and the network abstraction cases, the exchange of network data takes place via FMI variables.
-In the case of the physical signal abstraction, a separate FMI variable of the respective type is created for each network signal in a frame.
+In both the Physical Signal Abstraction and the Network Abstraction layer, the exchange of network data takes place via FMI variables.
+In the case of the Physical Signal Abstraction, a separate FMI variable of the respective type is created for each network signal in a frame.
 The network signals are structured via the PDU and frame hierarchy by using FMI 3.0 Terminals.
-Within the network abstraction, the bus is simulated using a separate, bus-specific protocol.
+Within the Network Abstraction, the bus is simulated using a separate, bus-specific protocol.
 This protocol is exchanged between the various network FMUs using binary FMI variables.
 
 Since network communication is not continuous but time discrete, FMI 3.0 Clocks are used to indicate when network data is sent or received.

docs/3____physical_signal_abstraction.adoc

@@ -1,18 +1,18 @@
 == Physical Signal Abstraction (High-Cut) [[high-cut]]
-This chapter describes the physical signal abstraction or High-Cut in detail.
+This chapter describes the Physical Signal Abstraction or High-Cut in detail.
 
 === Overview [[high-cut-overview]]
-Physical signal abstraction allows an idealized exchange of unit-based variables between FMUs.
+Physical Signal Abstraction allows an idealized exchange of unit-based variables between FMUs.
 Variables representing these physical signals are clocked to reflect the bus timing aspects of the information flow.
 Changes to these clocked variables always reach the destination.
 
-The figure below shows an example architecture of a Physical signal abstraction.
+The figure below shows an example architecture of a Physical Signal Abstraction.
 The signals (_Signal 1...8_) are modeled as clocked FMU variables of a specific type.
 The corresponding signals are structurally combined using Protocol Data Units (PDUs), which in turn are assigned to frames.
 The PDU and frame structuring is done via terminals (_PDU A, B, C_ and _Frame X, Y_).
 The respective FMU variables are connected to a Bus Simulation, which emulates them according to their own needs for e.g., in accuracy.
 
-.Physical signal abstraction example architecture.
+.Physical Signal Abstraction example architecture.
 [#figure-transmission-high-cut-overview]
 image::high_cut_network_fmu.svg[width=80%, align="center"]
 
@@ -65,7 +65,7 @@ This document does not address IP protection or copyright issues.
 These are technical and legal issues that need attention from standardization bodies of the referenced description formats, tool vendors and end users.
 
 === Terminal Definitions [[high-cut-terminal-definitions]]
-This section defines terminals for physical signal abstraction.
+This section defines terminals for Physical Signal Abstraction.
 
 ==== Bus Terminal [[high-cut-bus-terminal,Bus Terminal]]
 Each network connected to the FMU must be described in `icons/terminalsAndIcons.xml` as a `<Terminal>` element of `<fmiTerminalsAndIcons><Terminals>` that wraps all <<high-cut-frame-terminal,frame terminals>>.
@@ -175,7 +175,7 @@ include::examples/X_network4FMI_terminalsAndIcons_highCut.xml[]
 ----
 
 === Limitations [[high-cut-limitations]]
-Physical signal abstraction maps several network protocols onto co-simulation variables as transport layer simulating in many ways an ideal network.
+Physical Signal Abstraction maps several network protocols onto co-simulation variables as transport layer simulating in many ways an ideal network.
 Such an ideal network differs from physical networks in the following ways (and potentially others):
 
  * Network frame arbitration: frames are sent on the wire according to network-specific priority rules. +

docs/4_4_1_can.adoc

@@ -674,7 +674,7 @@ If the buffering is not adjusted by a specified Network FMU, the Bus Simulation
 
 ===== Transmission and Acknowledge [[low-cut-can-transmission-and-acknowledge]]
 The <<low-cut-can-transmit-operation, `Transmit`>> operation represents the sending of a CAN, CAN FD and CAN XL frame.
-With appropriate options, relevant functionalities can be configured and used on a network abstraction level (e.g., Virtual CAN network ID for CAN XL or Bit Rate Switch for CAN FD).
+With appropriate options, relevant functionalities can be configured and used on a Network Abstraction level (e.g., Virtual CAN network ID for CAN XL or Bit Rate Switch for CAN FD).
 In the real world, flawlessly transmitted CAN frames will be acknowledged by at least one receiver CAN node.
 To simulate this behavior, the <<low-cut-can-confirm-operation, `Confirm`>> operations are introduced.
 In addition, the <<low-cut-can-bus-notification-parameter, `BusNotifications`>> parameter is defined to support lightweight bus simulations and <<common-concepts-direct-communication, directly connected Network FMUs>>.

docs/4____network_abstraction.adoc

@@ -1,8 +1,8 @@
 == Network Abstraction (Low-Cut) [[low-cut]]
-This chapter describes the network abstraction or Low-Cut in detail.
+This chapter describes the Network Abstraction or Low-Cut in detail.
 
 === Overview [[low-cut-overview]]
-The network abstraction allows the implementation of virtual bus drivers within FMUs on the level of the hardware abstraction layer.
+The Network Abstraction allows the implementation of virtual bus drivers within FMUs on the level of the hardware abstraction layer.
 Exchanging data in terms of the <<low-cut-layered-standard-bus-protocol, Layered Standard Bus Protocol>> via variables grouped by a dedicated Bus Terminal (see <<low-cut-variables>>), allows the implementation of bus simulations in a wide range from idealized up to detailed behavior, including e.g., timing, arbitration, error, status and other effects.
 During simulation, the network communication is controlled by send and receive Bus Operations.
 Based on these operations, FMUs implementing this layered standard have to react depending on their role as specified in this document.
@@ -26,7 +26,7 @@ For simulating bus communication with timing effects, the FMUs should set the Co
 [#figure-transmission-example-with-timing-behavior]
 image::bus_simulation_example.svg[width=80%, align="center"]
 
-For simplification reasons or if a detailed bus simulation is not desired, fixed-step size FMUs can also be used with network abstraction.
+For simplification reasons or if a detailed bus simulation is not desired, fixed-step size FMUs can also be used with Network Abstraction.
 However, depending on the chosen simulation step-size, delay effects of the bus simulation have to be taken into account.
 Compositions with fixed-step size and variable-step size FMUs require the decoupling of the Bus Simulation logic and the Bus Simulation timing.
 This decoupling is realized by queuing Tx/Rx Bus Operations inside the Bus Simulation as well as queuing Tx Bus Operations inside Network FMUs.
@@ -301,7 +301,7 @@ The version number marks the set of available operations for a specified bus typ
 The versioning follows the rules of semantic versioning, as defined in <<PW13>>.
 
 === Terminal Definitions [[low-cut-terminal-definitions]]
-This section defines terminals for network abstraction.
+This section defines terminals for Network Abstraction.
 
 A schematic representation of an FMU with a Bus Terminal is shown in the <<#figure-frame-variables-terminals-lowcut, following figure>>:
 

docs/examples/fmi_ls_bus_manifest_example.xml

@@ -5,5 +5,5 @@
     xmlns:fmi-ls="http://fmi-standard.org/fmi-ls-manifest"
     fmi-ls:fmi-ls-name="org.fmi-standard.fmi-ls-bus"
     fmi-ls:fmi-ls-version="1.1.0-alpha.1"
-    fmi-ls:fmi-ls-description="Layered Standard for the simulation of bus communication on a signal or network abstraction based level."
+    fmi-ls:fmi-ls-description="Layered Standard for the simulation of bus communication on a Physical Signal Abstraction or Network Abstraction based level."
     isBusSimulationFMU="false"/>

schema/fmi3LayeredStandardBusManifest.xsd

@@ -38,7 +38,7 @@ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
         <xs:complexType>
             <xs:attribute ref="fmi-ls:fmi-ls-name" use="required" fixed="org.fmi-standard.fmi-ls-bus"/>
             <xs:attribute ref="fmi-ls:fmi-ls-version" use="required"/>
-            <xs:attribute ref="fmi-ls:fmi-ls-description" use="required" fixed="Layered Standard for the simulation of bus communication on a signal or network abstraction based level."/>
+            <xs:attribute ref="fmi-ls:fmi-ls-description" use="required" fixed="Layered Standard for the simulation of bus communication on a Physical Signal Abstraction or Network Abstraction based level."/>
             <xs:attribute name="isBusSimulationFMU" type="xs:boolean" default="false">
                 <xs:annotation>
                     <xs:documentation xml:lang="en">If true, this FMU represents a Bus Simulation FMU.</xs:documentation>