Skip to content

Latest commit

 

History

History
201 lines (152 loc) · 13.2 KB

3____physical_signal_abstraction.adoc

File metadata and controls

201 lines (152 loc) · 13.2 KB
Raw

Physical Signal Abstraction ("high cut")

This chapter describes the physical signal abstraction or "high cut" in detail.

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 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 network fmu
Figure 1. High-cut example architecture.

Variables

This section explains the different variable types used to carry network traffic through FMI input and output variables.

Signal Variables

To define the signal abstraction layer (or "high cut"), 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 network description file, if provided.

Each network signal must be listed as Terminal Member Variable of its corresponding 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].

Generally, signal variables are optional, but they must either be all missing or all present to clearly indicate support for the signal abstraction layer.

All signal variables are clocked to exactly indicate when they have been sent, see Clock Variables.

Clock Variables

In order to use FMU input and output variables as transport layer for networks, input and output Clocks are used. 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:

  • While aperiodic Clocks allow very accurate network simulations, frequently entering Event Mode will reduce the network simulation speed.

  • Using periodic Clocks reduces the number of Event Modes required and 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.

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).

Network Description Files

Standardized 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. If these network description files are shipped, they must be placed into the /extra/org.fmi-standard.fmi-ls-bus folder. DBC, LDF, Fibex and ARXML files are allowed, e.g., Powertrain.dbc. The case sensitive root name of the network description file must be used as network identifier in the Bus Terminal type and prefix in the variable names.

Multiple files can be specified, each one defining one network used by the FMU. This standard does not support composing one network from multiple network description files, even if using internal include mechanisms, it rather enforces the rule: one network - one file.

It is recommended to use ARXML over DBC files for CAN whenever possible, because the DBC standard lacks some key frame/PDU properties that were added only later using non-standard extensions with different dialects in use.

This document does not address potential open points of these description formats, it is assumed that such ambiguities will be handled elsewhere (e.g., message timing in the DBC format). 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

This section defines terminals for physical signal abstraction or "high cut".

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 frame terminals. The attribute name of the <Terminal> must match the root name of its network description file if it exists [e.g., Powertrain, if the file is /extra/org.fmi-standard.fmi-ls-bus/Powertrain.dbc]. In any case, the attribute name of the <Terminal> must be consistent with the BusName component of all its corresponding signal, frame and Clock variables.

Attribute definitions

  • terminalKind must be set to org.fmi-ls-bus.network-terminal.

  • matchingRule must be set to bus.

  • name is the network name, e.g., Powertrain, see example and constraints above.

Element definitions

  • There must be no <TerminalStreamMemberVariable> element.

  • There must be one <Terminal> element per network frame described in the network description file, if their signal and Clock variables are present in the modelDescription.xml.

Annotation element

  • If a network description file is shipped with the specified FMU, there must be an <Annotation> element defining which node or nodes (as comma-separated list without spaces) of the network description file are wrapped inside the FMU. If the combination of nodes specified for this FMU turns a frame and its signals into both input and output because sending and receiving nodes are specified, only the sending (output) role will be defined in the FMU interface. Receiving such frames must then be handled internally to the FMU. If no network description file is shipped with the specified FMU the <Annotation> shall not exist.

Frame Terminal

Each frame listed in the network description file must be an element of its corresponding Bus Terminal.

Attribute definitions

  • terminalKind must be set to org.fmi-ls-bus.frame-terminal.

  • matchingRule must be set to bus.

  • name must match the frame name as defined in the network description file in /extra/org.fmi-standard.fmi-ls-bus.

Element definitions

  • There must be no <TerminalStreamMemberVariable> element.

  • There must be one PDU terminal element per PDU of this frame.

  • There must be one <TerminalMemberVariable> for the Clock this frame is connected to. The memberName of this variable must be "Clock".

The Terminal Member Variable must have the same causality as all variables referenced in the PDU Terminals included here.

PDU Terminal

Each PDU listed in the network description file must be an element of its corresponding frame terminal.

Attribute definitions

  • terminalKind must be set to org.fmi-ls-bus.pdu-terminal.

  • matchingRule must be set to bus.

  • name must match a PDU name of the network description file in /extra/org.fmi-standard.fmi-ls-bus, if given. For network types not natively referencing a "PDU", like CAN, a synthetic PDU with the same name as its frame is inserted.

Element definitions

  • There must be no <TerminalStreamMemberVariable> element.

  • There must be no <Terminal> element.

  • There must be one <TerminalMemberVariable> per signal of this PDU.

All TerminalMemberVariables must have the same causality of either input or output.

Terminal Member Variable for Signals

PDU terminals list all the contained signals as <TerminalMemberVariable>.

Attribute definitions

  • variableName refers to the input or output variable name of the FMU. These variables represent the signal abstraction layer ("high cut"). 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 network description file, e.g., vCar, if given. This is redundant information but simplifies signal name extraction.

  • variableKind is signal.

Example

The following excerpts from files are used throughout this document as examples and should illustrate how the different concepts relate.

The following partial DBC file lists merely the CAN message (frame) structure. Signal trigger conditions are not included because they have no bearing on this standard.

Example Powertrain.dbc file.
...
BO_ 256 tcuSensors: 4 TCU
 SG_ vCar :          0|16@1- (32,0)  [-500|500] "km/h" ECU
 SG_ oilTemp :      16|9@1-  (2,50)  [-50|150]  "Degree C" ECU

BO_ 257 tcuState: 2 TCU
 SG_ state :         0|2@1+  (1,0)   [ 0|2] "-" ECU
 SG_ gear :          2|4@1-  (1,0)   [-2|6] "-" ECU
 SG_ targetGear :    6|4@1-  (1,0)   [-2|6] "-" ECU

BO_ 512 ecuState: 4 ECU
 SG_ accelPedal :    0|8@1+ (2,0)   [0|100]   "%" TCU
 SG_ k15 :           8|1@1+ (1,0)   [0|1]     "-" TCU
 SG_ oilTemp :       9|9@1- (2,50)  [-50|150] "Degree C" TCU
 SG_ radiatorTemp : 18|9@1- (2,50)  [-50|150] "Degree C" TCU
...

The modelDescription.xml excerpt listed below shows which variables would exist for the Powertrain.dbc shown above.

Example modelDescription.xml for ECU node.
link:examples/X_network4FMI_modelDescription_highCut.xml[role=include]

The following file shows the <Terminal> definition representing the network and frame structure defined with Powertrain.dbc above.

Example terminalsAndIcons.xml file.
link:examples/X_network4FMI_terminalsAndIcons_highCut.xml[role=include]

Limitations

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.
    Here all frames are transmitted at the same time without delay.

  • Network congestion/bandwidth: too many network frames sent for the bandwidth of the network.
    Here the network has infinite capacity.
    If network properties are required, a bus simulation component must be added or included with the importer.

  • Protocol functions of higher levels: i.e. CAN request for retransmit is a specific protocol function.
    Here such specialties must be handled by the first layer inside the FMU.

  • Incoming buffer overflow: when an ECU receives more frames than its buffer can hold.
    Here the FMU will receive all frames, regardless of buffer size and would need to handle those limitations internally.

  • Network protocols allow frames to be sent from more than one node.
    Here this is also possible, with output variables for frames (and their signals) that are sent by more than one FMU. This requires the importer to handle the case when multiple source FMUs are sending the same frame. Importers must know how to handle this, just like they must know how to handle flow variables according to Kirchhoff’s law.