diff --git a/docs/1____introduction.adoc b/docs/1____introduction.adoc index 406f1a2c..edeb12f6 100644 --- a/docs/1____introduction.adoc +++ b/docs/1____introduction.adoc @@ -10,13 +10,13 @@ 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 ("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 ("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. +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_. 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: diff --git a/docs/2____common_concepts.adoc b/docs/2____common_concepts.adoc index 49c6ae0f..affbffa5 100644 --- a/docs/2____common_concepts.adoc +++ b/docs/2____common_concepts.adoc @@ -1,51 +1,30 @@ == Common Concepts [[common-concepts]] - -Physical signal abstraction ("high cut") and network abstraction ("low cut") layers represent different levels for the exchange of bus messages. +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. -_[FMUs providing both abstraction layers can deduce from the fmi3Set() and fmi3Get() calls they receive, which abstraction layer the importer is using.]_ - -Since network communication is not continuous but time discrete, FMI 3.0 Clocks are used to indicate when signals and/or frames are sent or received. -All signal and frame variables are clocked variables. - -FMI 3.0 terminal definitions in the `terminalsAndIcons.xml` are used to group related variables and present a comfortable opportunity to connect different FMUs between each other. -Terminal definitions are used differently within the "high cut" and the "low cut": - -.Relations between Bus-, Frame- and PDU Terminals. -[#figure-terminal-relations] -image::terminal_relations.svg[width=60%, align="center"] +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. +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. +This protocol is exchanged between the various network FMUs using binary FMI variables. -Variables are referenced in terminals and the `memberName` attribute indicates how a variable is meant to be used. -For the "high cut", variables represent signals and their Clocks. -For the "low cut", variables represent transmitted and received bus traffic (`memberName` = `Tx_Data`/`Rx_Data`) and their respective Clocks (`memberName` = `Tx_Clock`/`Rx_Clock`). -The `causality` of `Rx_Data` variables must be `input`, whereas the `causality` of `Tx_Data` variables must be `output`. -`Rx_Clock` variables must be `triggered input` Clocks and are meant to be connected by the importer to the corresponding `Tx_Clock` variables. -A `periodic` Clock indicates that the FMU can send signals or frames only periodically on a given time raster, while a `changing` or `countdown` Clock indicates that the FMU can send signals at varying time steps. +Since network communication is not continuous but time discrete, FMI 3.0 Clocks are used to indicate when network data is sent or received. -Using `Tx_Clocks` of different types allows simulations with different timing accuracy and performance. -Some Clock types allow the FMU to specify the next send event efficiently and accurately. -Hence, the importer will trigger these Clocks according to the Clock specifications as accurately as it can. - -_[The alternative of using `nextEventTime` would force epsilon matching of event times.]_ +While the values and semantic of the Clock variables are clear, the binary frame variables are opaque to the importer but have internal structure to implement the transport mechanism of the specific network technology. +Frame variables do not just transport the network-specific payload, but also carry protocol-specific status information. +Status information allows, for example, the MCAL emulation of a virtual ECU to report back to the COM-stack about success or errors of a send request. For any periodic (fixed-time) sending of messages, multiple message sends fall into one `fmi3DoStep`. -While "high cut" signal variables will miss all but the last value sent, "low cut" frame variables will buffer all payloads inside their value. +While High-Cut signal variables will miss all but the last value sent, Low-Cut frame variables will buffer all payloads inside their value. +=== General Recommendations [[common-concepts-general-recommendations]] If `triggered` output Clocks are used, the importer must take care to schedule and potentially roll-back FMUs that have advanced their `fmi3DoStep` past such a (surprising) `triggered` Clock activation from another FMU. It is strongly recommended to avoid using `triggered` output Clocks and to instead use `time-based` Clocks to avoid these complications and potential performance problems. -If an FMU represents network nodes that are both sender and receiver of a signal, the receiver role will be removed from the FMU interface to allow the signals to have a unique role as output and the reading of such outputs must be handled internally to the FMU. - -_[Rationale: The FMI standard requires a variable to be either input or output.]_ - -While the values and semantic of the Clock variables are clear, the binary frame variables are opaque to the importer but have internal structure to implement the transport mechanism of the specific network technology. -Frame variables do not just transport the network-specific payload, but also carry protocol-specific status information. -Status information allows, for example, the MCAL emulation of a virtual ECU to report back to the COM-stack about success or errors of a send request. - === System Compositions [[common-concepts-system-compositions]] Overall, this standard considers three possible communication architectures for bus communication. It should be explicitly noted at this point that the FMUs for integration in the respective use case do not necessarily have to be different, so that the same FMU can be integrated across all three communication architectures. diff --git a/docs/3____physical_signal_abstraction.adoc b/docs/3____physical_signal_abstraction.adoc index 1000983b..e96f72cc 100644 --- a/docs/3____physical_signal_abstraction.adoc +++ b/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. +== Physical Signal Abstraction (High-Cut) [[high-cut]] +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. 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 high-cut. +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. -.High-cut example architecture. +.Physical signal abstraction example architecture. [#figure-transmission-high-cut-overview] image::high_cut_network_fmu.svg[width=80%, align="center"] @@ -20,7 +20,7 @@ image::high_cut_network_fmu.svg[width=80%, align="center"] This section explains the different variable types used to carry network traffic through FMI input and output variables. ==== Signal Variables [[high-cut-signal-variables]] -To define the signal abstraction layer (or "high cut"), signal variables are defined. +To define the signal abstraction layer, signal variables are defined. 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 <>, if provided. @@ -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 or "high cut". +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 `` element of `` that wraps all <>. @@ -121,7 +121,7 @@ All <> Attribute definitions:: * `variableName` refers to the input or output variable name of the FMU. - These variables represent the signal abstraction layer ("high cut"). + These variables represent the 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 <>, e.g., `vCar`, if given. diff --git a/docs/4____network_abstraction.adoc b/docs/4____network_abstraction.adoc index 2f62e900..bb372331 100644 --- a/docs/4____network_abstraction.adoc +++ b/docs/4____network_abstraction.adoc @@ -1,5 +1,5 @@ -== Network Abstraction ("low cut") [[low-cut]] -This chapter describes the network abstraction or "low cut" in detail. +== Network Abstraction (Low-Cut) [[low-cut]] +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. @@ -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 <>. === Terminal Definitions [[low-cut-terminal-definitions]] -This section defines terminals for network abstraction (also called "low cut"). +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>>: diff --git a/docs/images/terminal_relations.drawio b/docs/images/terminal_relations.drawio deleted file mode 100644 index d2e22579..00000000 --- a/docs/images/terminal_relations.drawio +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/images/terminal_relations.svg b/docs/images/terminal_relations.svg deleted file mode 100644 index 0191e532..00000000 --- a/docs/images/terminal_relations.svg +++ /dev/null @@ -1,3 +0,0 @@ - - -

terminalsAndIcons.xml

„NetworkX“::Terminal

  Name = <network name>

TerminalMemberVariable

  variableName = <FmuVariable>

  memberName = Tx_Data, Rx_Data,                                               Tx_Clock, Rx_Clock  

  variableKind = signal


Low Cut
High Cut

„FrameX“::Terminal

  Name = <frame name>


„PduX“::Terminal

  Name = <PDU name>

TerminalMemberVariable

  variableName = <FmuClock>

  memberName = TransmissionClock  

  variableKind = signal

TerminalMemberVariable

  variableName = <FmuVariable>

  memberName = <SignalName>  

  variableKind = signal

Text
Bus Terminal
Frame Terminal
PDU Terminal
*
*

One clock per frame

One per signal of PDU

*

Multiple TerminalMemberVariables in case of multiplexed signals

Rx/Tx data + clock

4
 \ No newline at end of file