4_4_1_can.adoc

CAN, CAN FD, CAN XL

This chapter describes the Layered Standard Bus Protocol for CAN, CAN FD and CAN XL. The various CAN standards CAN, CAN FD and CAN XL are considered together, because they are very similar and can also be combined in certain scenarios.

Overview

To simulate CAN, CAN FD and CAN XL buses, CAN-specific operations are specified based on the Layered Standard Bus Protocol. Overall, the following groups of operations exists:

• Transmit: This group of operations is used to simulate a frame transmission. There are three specializations of this operation, one each for CAN, CAN FD and CAN XL frames.

• Confirm: An acknowledgment of transmitted CAN frames is defined by the CAN standard. This kind of operation is used to simulate this behavior.

• Error: This group of operations is used for protocol format errors and to simulate bus failures. For example, the failure of a transmission can be indicated.

• Arbitration Lost: The operation is used by Bus Simulations to inform Network FMUs that a frame could not be transmitted immediately.

• Configuration: This operation enables the configuration of bus-specific parameters and options that are required to simulate the bus behavior properly. For example, it allows the specification of the baud rate or influencing the buffer behavior.

• Status: This operation is used by Networked FMUs to inform Bus Simulations about the internal state (Active/Passive/Bus-Off) which concerns the reaction on bus errors.

• Wake up: CAN supports wake up and sleep scenarios. Normally there are two ways to wake up from sleep mode: a local wake up on a specified wake-up pin, or a wake-up on the CAN bus via a CAN specific wake-up pulse. This operation is used to simulate triggering a wake-up from bus side.

The following table gives a detailed overview of the available operations. It shows all operations and the arguments they contain.

Table 1. Overview of the available operations for CAN, CAN FD and CAN XL.

Operation Name	Operation Content
	OP Code	Length	Specific Content
Format Error	0x01	:= 10 + n (4 bytes)	DL [1] (2 bytes)	Data (n bytes)
CAN Transmit	0x10	:= 16 + DL (4 bytes)	ID (4 bytes)	Ide (1 byte)	Rtr (1 byte)	DL (2 bytes)	Data (n bytes)
CAN FD Transmit	0x11	:= 17 + DL (4 bytes)	ID (4 bytes)	Ide (1 byte)	Brs (1 byte)	Esi (1 byte)	DL (2 bytes)	Data (n bytes)
CAN XL Transmit	0x12	:= 22 + DL (4 bytes)	ID (4 bytes)	Ide (1 byte)	Sec (1 byte)	SDT (1 byte)	VCID (1 byte)	AF (4 bytes)	DL (2 bytes)	Data (n bytes)
Confirm	0x20	:= 12 (4 bytes)	ID (4 bytes)
Arbitration Lost	0x30	:= 12 (4 bytes)	ID (4 bytes)
Bus Error	0x31	:= 15 (4 byte)	ID (4 bytes)	Error Code (1 byte)		Error Flag (1 byte)		Is Sender (1 byte)
Configuration	0x40	<Length> (4 bytes)	Kind (1 byte)	Dynamic Part
Status	0x41	:= 9 (4 bytes)	Status (1 byte)
Wakeup	0x42	:= 8 (4 bytes)	---

Operations

This section defines the specified operations for CAN, CAN FD and CAN XL. The following tables provide an overview of all operations and specifies the position and length of the corresponding arguments, as well as the respective flow direction.

Transmit

There are three types of Transmit operations for transmission of CAN, CAN FD and CAN XL frames.

Table 2. Detailed description of the CAN Transmit operation.

Name	CAN Transmit
Description	Initiates the transmission of CAN frames.
OP Code [hex]	0x10
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x10) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 16 + Data Length.
	ID	4 bytes	The specified ID of the CAN message. The ID must be considered here as a purely numerical value. This means that there is no need for separate segmentation between the 11-bit base CAN identifier and an 18-bit CAN identifier extension information that is known from the CAN protocol. Additional information such as Ide is also not part of the ID, but is treated separately.
	Ide	1 byte	Specified whether the ID should be transmitted as standard (11-bit) or extended (29-bit) message identifier. For specification, the boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
	Rtr	1 byte	Specifies whether the given frame represents a Remote Transmission Request frame. For specification, the boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
	Data Length	2 bytes	Specifies the length of the Data argument in bytes. Note: The argument value describes the actual data length and not the CAN Data Length Code (DLC).
	Data	n bytes	Stores the given frame data to transfer, whereby the valid length of the data depends on the CAN Format. Note: The value of this argument also includes padding bytes if these are required by the CAN format in the respective situation.
Behavior	The CAN Transmit operation shall be provided by Network FMUs to initiate the transmission of a CAN frame. In case of directly connected Network FMUs (see [common-concepts-direct-communication]), the FMU importer forwards the operation directly to the receiving Network FMUs. If a Bus Simulation is involved (see [common-concepts-composition-with-dedicated-bus-simulation-fmu] and [common-concepts-importer-with-integrated-bus-simulation]), the FMU importer forwards the operation initially to the Bus Simulation, where the operation is distributed with respect to the simulated bus behavior. Depending on the simulation details, the Bus Simulation might respond with a Confirm, Arbitration Lost, Bus Error or Format Error operation. Depending on the status of the specified Network FMU, further restrictions for CAN Transmit operations exist.

Table 3. Detailed description of the CAN FD Transmit operation.

Name	CAN FD Transmit
Description	Represents an operation for the transmission of a CAN FD frame.
OP Code [hex]	0x11
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x11) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 17 + Data Length.
	ID	4 bytes	The specified ID of the CAN message. The ID must be considered here as a purely numerical value. This means that there is no need for separate segmentation between the 11-bit base CAN identifier and an 18-bit CAN identifier extension information that is known from the CAN protocol. Additional information such as Ide is also not part of the ID, but is treated separately.
	Ide	1 byte	Specified whether the ID should be transmitted as standard (11-bit) or extended (29-bit) message identifier. For specification, the boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
	Brs	1 byte	Defines the Bit Rate Switch. For specification, the boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
	Esi	1 byte	Error State indicator. For specification, the boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
	Data Length	2 bytes	Specifies the length of the Data argument in bytes. Note: The argument value describes the actual data length and not the CAN Data Length Code (DLC).
	Data	n bytes	Stores the given frame data to transfer, whereby the valid length of the data depends on the CAN FD Format. Note: The value of this argument also includes padding bytes if these are required by the CAN format in the respective situation.
Behavior	The behavior is identical to the CAN Transmit behavior.

Table 4. Detailed description of the CAN XL Transmit operation.

Name	CAN XL Transmit
Description	Represents an operation for the transmission of a CAN XL frame.
OP Code [hex]	0x12
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x12) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 22 + Data Length.
	ID	4 bytes	The specified ID of the CAN message. The ID must be considered here as a purely numerical value. This means that there is no need for separate segmentation between the 11-bit base CAN identifier and an 18-bit CAN identifier extension information that is known from the CAN protocol. Additional information such as Ide is also not part of the ID, but is treated separately.
	Ide	1 byte	Specified whether the ID should be transmitted as standard (11-bit) or extended (29-bit) message identifier. For specification, the boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
	Sec	1 byte	Simple Extended Content For specification, the boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
	SDT	1 byte	Describes the structure of the frames Data Field content (SDU type).
	VCID	1 byte	Represents the virtual CAN network ID.
	AF	4 bytes	Represents the CAN XL Acceptance Field (AF).
	Data Length	2 bytes	Specifies the length of the Data argument in bytes. Note: The argument value describes the actual data length and not the CAN Data Length Code (DLC).
	Data	n bytes	Stores the given frame data to transfer, whereby the valid length of the data depends on the CAN XL Format. Note: The value of this argument also includes padding bytes if these are required by the CAN format in the respective situation.
Behavior	The behavior is identical to the CAN Transmit behavior.

Confirm

The Confirm operation is used to signal the successful reception of a transmitted CAN frame (see Transmit operation) by at least one Network FMU.

Table 5. Detailed description of the Confirm operation.

Name	Confirm
Description	Signals successful receipt of a transmitted CAN, CAN FD and CAN XL frame to simulate a CAN acknowledgment behavior.
OP Code [hex]	0x20
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x20) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 12.
	ID	4 bytes	The ID of the confirmed CAN message.
Behavior	This operation shall be produced by the Bus Simulation and consumed by Network FMUs. Only Network FMUs with the corresponding optionally exposed BusNotifications parameter set to fmi3True might wait for this operation. Depending on the status of the receiving Network FMU further restrictions for Confirm operations exist.

Format Error

Represents a format error that indicates a syntax or content error of receiving operations. See Format Error for definition.

Arbitration Lost

The Arbitration Lost operation defines a feedback message from a Bus Simulation to a Network FMU that a Transmit operation could not be sent immediately due to a concurrent transmit request.

Table 6. Detailed description of the Arbitration Lost operation.

Name	Arbitration Lost
Description	The Arbitration Lost operation indicates that a CAN frame could not be sent immediately and was therefore discarded by the Bus Simulation. See Arbitration for further details.
OP Code [hex]	0x30
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x30) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 12.
	ID	4 bytes	The ID of the CAN message which could not be transmitted immediately because it lost arbitration.
Behavior	During simulation, several Transmit operations can be sent by Network FMUs to a Bus Simulation at the same time. In such case, the Bus Simulation has to decide which Transmit operation should be processed first. Depending on the configuration (see the Arbitration Lost Behavior argument of the Configuration operation), the deferred Transmit operations shall either be buffered or they shall be discarded and the Arbitration Lost operation shall be sent back to the respective Network FMUs. A Network FMU receiving the Arbitration Lost operation can decide to provide the Transmit operation again or e.g., to raise an internal transmit timeout failure after a while. Only Network FMUs with the corresponding optionally exposed BusNotifications parameter set to fmi3True might wait for this operation and respond accordingly.

Bus Error

The Bus Error operation represents special bus communication errors, which are delivered to every participant in the network.

Table 7. Detailed description of the Bus Error operation.

Name	Bus Error
Description	Represents an operation for simulated bus errors.
OP Code [hex]	0x31
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x31) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 15.
	ID	4 bytes	The ID of the CAN message that was transmitted while the error happened.
	Error Code	1 byte	The simulated bus error, based on the table below.
	Error Flag	1 byte	Defines whether the Error was detected by a specified Network FMU. For specification the boolean values PRIMARY_ERROR_FLAG and SECONDARY_ERROR_FLAG (see Overview of the available Error Flag values.) shall be used.
	Is Sender	1 byte	Set if the Bus Error operation is a reaction to a Transmit operation that was provided by the specified Network FMU from the Bus Simulation. For specification, the boolean values TRUE and FALSE (see [table-boolean-value-kinds]) shall be used.
Behavior	When transmitting CAN frames, various kinds of bus error may happen. A Bus Simulation can simulate such errors by providing Bus Error operations to the Network FMUs. Based on consumed Bus Error operations, Network FMUs shall maintain an internal CAN node state (see Error Handling). To determine the CAN node state properly, Network FMUs need the information about their role at the time when the simulated error happened. For a Network FMU that initiated the Transmit operation, the argument Is Sender shall be set to TRUE in the corresponding Bus Error operation. For a Network FMU considered to be the one detecting the error first, the argument Error Flag = PRIMARY_ERROR_FLAG shall be set. The arguments Is Sender = TRUE and Error Flag = PRIMARY_ERROR_FLAG must only be set once per simulated error. Only Network FMUs with the corresponding optionally exposed BusNotifications parameter set to fmi3True might wait for this operation and respond accordingly.

The following Error Codes are specified:

Table 8. Overview of the available error codes.

State	Error Code	Description
BIT_ERROR	0x01	Within the CAN standard, the sender also receives transmitted data for comparison. If the sent and received bits are not identical, this failure results in a Bit Error.
BIT_STUFFING_ERROR	0x02	A Bit Stuff Error occurs if 6 consecutive bits of equal value are detected on the bus.
FORM_ERROR	0x03	Occurs during a violation of End-of-Frame (EOF) format.
CRC_ERROR	0x04	Occurs when the data of a frame and the related checksum do not harmonize.
ACK_ERROR	0x05	All receiving nodes identify an invalid CAN frame.
BROKEN_ERROR_FRAME	0x06	Represents an invalid transmission of a CAN Error frame. Within CAN, an Error frame is transmitted by any unit on detection of a bus error.

The following values for the Error Flag option are defined:

Table 9. Overview of the available Error Flag values.

Error Flag	Value	Description
PRIMARY_ERROR_FLAG	0x01	Defines that a specified Network FMU is detecting the given Bus Error first.
SECONDARY_ERROR_FLAG	0x02	Defines that a specified Network FMU is reacting on a Bus Error and does not detect it.

Configuration

The Configuration operation is used by Network FMUs to send simulation specific options like baud rate settings to Bus Simulations. The following information is included within this operation:

Table 10. Detailed description of the Configuration operation.

Name	Configuration
Description	Represents an operation for the configuration of a Bus Simulation. In detail, the configuration of a CAN, CAN FD and CAN XL baud rate is possible. Also the configuration of further options, like buffer handling, is supported by this operation.
OP Code [hex]	0x40
Content	Argument			Length	Description
	OP Code			4 bytes	Contains the OP Code (0x40) of the operation.
	Length			4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 9 + Length of parameter arguments in bytes.
	Parameter Type			1 byte	Defines the current configuration parameter. Note that only one parameter can be set per Configuration operation.
		Parameters
		CAN_BAUDRATE	Baud Rate	4 bytes	The CAN baud rate value to configure. The required unit for the baud rate value is bit/s.
		CAN_FD_BAUDRATE	Baud Rate	4 bytes	The CAN FD baud rate value to configure. The required unit for the baud rate value is bit/s.
		CAN_XL_BAUDRATE	Baud Rate	4 bytes	The CAN XL baud rate value to configure. The required unit for the baud rate value is bit/s.
		ARBITRATION_LOST_BEHAVIOR	Arbitration Lost Behavior	1 byte	This parameter defines how a Bus Simulation shall behave in cases of an arbitration lost scenario. If the option is set to BUFFER_AND_RETRANSMIT, Transmit operations shall be buffered by the Bus Simulation and no Arbitration Lost operation shall be sent. If the option is set to DISCARD_AND_NOTIFY, the Transmit operation shall be discarded and an Arbitration Lost operation shall be sent to the Network FMU (see Arbitration).
Behavior	The specified operation shall be produced by a Network FMU and consumed by the Bus Simulation. The operation shall not be routed to other Network FMUs by the Bus Simulation. A Network FMU shall ignore this operation on the consumer side. Configuration operations can be produced multiple times during the runtime of a Network FMU. In context of CAN FD, also a CAN baud rate should be configured by using Parameter Type = CAN_BAUDRATE. If configuration parameters are not adjusted by a Network FMU, the Bus Simulation shall choose a default behavior by itself.

The following configuration parameters are defined:

Table 11. Overview of the available configuration parameters.

Parameter	Value	Description
CAN_BAUDRATE	0x01	This code indicates that a CAN baud rate should be configured for the Bus Simulation.
CAN_FD_BAUDRATE	0x02	Allows the configuration of a CAN FD baud rate for the Bus Simulation.
CAN_XL_BAUDRATE	0x03	Allows the configuration of a CAN XL baud rate for the Bus Simulation.
ARBITRATION_LOST_BEHAVIOR	0x04	This code configures the behavior of a Bus Simulation if an arbitration is lost. See Overview of the available Arbitration Lost Behavior values. for possible values.

The following values for the Arbitration Lost Behavior option are defined:

Table 12. Overview of the available Arbitration Lost Behavior values.

Arbitration Lost Behavior	Value	Description
BUFFER_AND_RETRANSMIT	0x01	Transmit operations shall be buffered by the Bus Simulation.
DISCARD_AND_NOTIFY	0x02	Transmit operations shall be discarded and the specified Network FMU shall be notified by the Bus Simulation via an Arbitration Lost operation.

Status

By using the Status operation, a Network FMU can communicate the current CAN node state to the Bus Simulation. The following information is included within this operation:

Table 13. Detailed description of the Status operation.

Name	Status
Description	Represents an operation for status handling.
OP Code [hex]	0x41
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x41) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 9.
	Status	1 byte	The specified status code, based on the table below.
Behavior	The specified operation shall be produced by Network FMUs and consumed by the Bus Simulation. The operation shall not be routed to other Network FMUs by the Bus Simulation. A Network FMU shall ignore this operation on the consumer side. A Network FMU shall report its status to the Bus Simulation after it changes.

The following status values can be used:

Table 14. Overview of the available status values.

Kind	Value	Description
ERROR_ACTIVE	0x01	Indicates that a simulated CAN controller within the Network FMU has currently the CAN node state: ERROR ACTIVE. If the status is not adjusted by a Network FMU, the Bus Simulation shall choose ERROR_ACTIVE by itself for a specified Network FMU.
ERROR_PASSIVE	0x02	Indicates that a simulated CAN controller within the Network FMU has currently the CAN node state: ERROR PASSIVE. This node state is relevant for arbitration, because ERROR_ACTIVE and ERROR_PASSIVE nodes requires different prioritization. See Arbitration for further details.
BUS_OFF	0x03	Indicates that a simulated CAN controller within the Network FMU has currently the CAN node state: Bus-Off. If a Network FMU communicates the status BUS_OFF to the Bus Simulation, the specified Network FMU shall not provide any new Transmission operations to the Bus Simulation. If all Network FMUs, except the Transmit operation initiating Network FMU, communicate the status BUS_OFF, the Bus Simulation shall not provide a confirmation.

Wake Up

By using the Wakeup operation, the underlying Bus Simulation can trigger a bus-specific wake-up.

Table 15. Detailed description of the Wakeup operation.

Name	Wakeup
Description	Represents an operation for triggering a bus-specific wake-up.
OP Code [hex]	0x42
Content	Argument	Length	Description
	OP Code	4 bytes	Contains the OP Code (0x42) of the operation.
	Length	4 bytes	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 8.
Behavior	The specified operation shall be produced by a Network FMU and distributed to all participants, except the wake-up initiator, of the bus using the Bus Simulation. If a Network FMU does not support wake up, this operation can be ignored on the consumer side.

Network Parameters

This chapter defines parameters that Network FMU might provide to configure CAN-specific behavior.

Bus Notification Parameter

For a detailed simulation, the CAN bus behavior regarding acknowledgment, bus errors and arbitration losses must be considered. A Bus Simulation can simulate these effects by sending bus notifications in terms of Confirm-, Bus Error- and Arbitration Lost operations to the Network FMUs.

However, in scenarios where Network FMUs are connected directly to each other, or where the Bus Simulation does not simulate such effects, it must be possible to configure the Network FMU such that it does not wait for any response after a Transmit operation. Therefore, a parameter with memberName = "BusNotifications" can be added within the CAN-specific Configuration Terminal.
If a Network FMU supports bus notifications, the BusNotifications parameter shall be exposed. The default value of this parameter shall be false.
[The default value false allows a simple integration of Network FMUs to simulation scenarios where Confirm-, Bus Error- or Arbitration Lost operations are not used.]

Only Network FMUs with the corresponding optionally exposed BusNotifications parameter set to fmi3True might wait for Confirm-, Bus Error- and Arbitration Lost operations and respond accordingly; otherwise Network FMUs must not wait ("fire-and-forget"). Even if the Network FMU does not expect bus notifications, i.e. BusNotifications variable was not set to fmi3True, but receives them, it shall ignore them, i.e. it shall not report warnings or errors.

[Note that the bus notification parameter just informs the Network FMU if it can expect to receive notification operations or not. The parameter doesn’t define in any way on how to react upon receiving notification operations.]

Parameter to configure bus notifications within a CAN Bus Terminal of Network FMUs.

 memberName:    BusNotifications
 type:          Boolean
 causality:     parameter
 variability:   fixed
 start:         false

A Bus Simulation FMU shall indicate via a variable with memberName = "BusNotifications" within the CAN-specific Configuration Terminal whether it provides bus notifications or not. If the provision of bus notifications can be configured (e.g., via a structural parameter), the attributes of the BusNotifications variable shall contain causality = "calculatedParameter" and variability = "fixed"; or causality = "output" and variability = "constant" otherwise.

Parameter to configure bus notifications within a CAN Bus Terminal of the Bus Simulation.

 memberName:    BusNotifications
 type:          Boolean
 causality:     calculatedParameter/output
 variability:   fixed/constant

Configuration of Bus Simulation

The configuration of the Bus Simulation is done by the Network FMUs itself. For this purpose, the Configuration operation provides several configuration parameters. Configuration operations can be produced multiple times during the runtime of a Network FMU. Because the Bus Simulation shall choose a default behavior, it might be useful in several scenarios that Network FMUs finish configuration before the production of Transmit operations.

Baud Rate Handling

In order to calculate the time required for the transmission of a bus message, it is necessary to inform the Bus Simulation about the specified baud rate from a Network FMU. This baud rate information can be configured by using CAN_BAUDRATE, CAN_FD_BAUDRATE and CAN_XL_BAUDRATE configuration kind of the Configuration operation. In a CAN FD scenario, both the configuration for CAN_BAUDRATE and for CAN_FD_BAUDRATE shall be carried out. The Bus Simulation can derive the required CAN, CAN FD or CAN XL controller type from the baud rate configurations a Network FMU carried out. If the baud rate information is not adjusted by a specified Network FMU, the Bus Simulation shall choose a default behavior by itself.

Buffer Handling

By using the ARBITRATION_LOST_BEHAVIOR kind of Configuration operation, the buffer handling within the Bus Simulation can be adjusted. Using buffer handling is required in arbitration scenarios only and will be described within this context. If the buffering is not adjusted by a specified Network FMU, the Bus Simulation shall choose a default behavior by itself.

Transmission and Acknowledge

The 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). In the real world, flawlessly transmitted CAN frames will be acknowledged by at least one receiver CAN node. To simulate this behavior, the Confirm operations are introduced. In addition, the BusNotifications parameter is defined to support lightweight bus simulations and directly connected Network FMUs.

If BusNotifications is false (default), then Network FMUs must not rely on receiving Confirm operations for the specified Bus Terminal. In this case, the bus simulation is idealized and takes place in a "fire-and-forget" manner. If a specified Network FMU is depending on Confirm operations and BusNotifications is false, the self confirmation shall be realized internally within the respective Network FMU for the specified Bus Terminal.

Direct Confirmation of transmitted network data. illustrates this communication, whereby FMU 1 transmits network data to FMU 2. Subsequently, FMU 1 self-confirms the transmission internally.

Figure 1. Direct Confirmation of transmitted network data.

For a detailed simulation, the Bus Simulation has to support Confirm operations. In this case, the BusNotifications parameter of the Network FMUs can be set to fmi3True as Network FMUs can rely on receiving Confirm operations for the specified Bus Terminal.

The following Confirmation of transmitted network data via Bus Simulation. illustrates the behavior, whereby FMU 1 transmits network data to FMU 2 via a Bus Simulation.

Figure 2. Confirmation of transmitted network data via Bus Simulation.

If all Network FMUs, except the one initiating the Transmit operation, communicate the status BUS_OFF, the Bus Simulation shall not provide a confirmation.

The FMI LS BUS Implementer’s Guide contains an example of the possible transmission results and displays them in a diagram.

Error Handling

The CAN protocol includes a sophisticated fault confinement mechanism to prevent malfunctioning within CAN nodes. A Transmit Error Counter (TEC) and a Receive Error Counter (REC) represent a historical communication quality metric. To maintain the TEC and REC values, Bus Error operations shall be provided to all Network FMUs by the Bus Simulation. The argument Is Sender shall be set to TRUE for the Network FMU the Transmit operation originated from. The argument Error Flag shall be set to PRIMARY_ERROR_FLAG if the Network FMU detects the transmission error. If a Network FMU changes its current CAN node state, the Status operation shall be provided to the Bus Simulation. When a Network FMU signals the BUS_OFF state to the Bus Simulation, it shall not provide any new Transmit operations in order to simulate a real Bus-Off behavior.

Figure 3. Architectural error handling overview.

The FMI LS BUS Implementer’s Guide contains an example of how to realize CAN error handling based on the Bus Operations specified by this layered standard.

Arbitration

Arbitration is an instrument of the CAN standard to resolve the conflict of the simultaneous sending of messages from several CAN nodes without a collision. The arbitration is handled in the Bus Simulation and can be recognized by the fact that the Bus Simulation receives a Transmit operation from several FMUs at the same time. As soon as an arbitration is lost, an Arbitration Lost operation shall be returned to the respective sender within the next Event Mode. As soon as an FMU receives an Arbitration Lost operation, it can independently repeat the corresponding Transmit operation.

Figure 4. Arbitration of two transmissions at the same time.

Within a Configuration operation, the Arbitration Lost Behavior argument can be specified. Once this option is set to BUFFER_AND_RETRANSMIT, the Bus Simulation buffers the frame after losing arbitration and sends it as soon as possible. In this case, it is not necessary for the Network FMU to re-send the respective frame and an Arbitration Lost operation shall not be returned to the specific Network FMU. If the Arbitration Lost Behavior is set to DISCARD_AND_NOTIFY, the specified Network FMU is informed by an Arbitration Lost operation and needs to repeat the corresponding Transmit operation by itself. Arbitration is available in communication architectures with Bus Simulation only, i.e., it is not available for directly connected Network FMUs.

In the case of arbitration, the Bus Simulation must also take the status of the respective Network FMU into account, which is communicated via a Status operation. To simulate the behavior of the CAN Extra Suspend Transmission Time when a CAN node is in Error Passive state, the Bus Simulation shall prefer Network FMUs whose status is ERROR_ACTIVE (see Overview of the available status values.).

The FMI LS BUS Implementer’s Guide contains examples of the presented arbitration cases and visualizes them using sequence diagrams.

Wake Up/Sleep

This standard supports wake up and sleep functionality for the CAN bus. However, the realization of local virtual ECU wake-up and sleeping processes, i.e., the transition to the sleep state as well as the virtual ECU local wake-up process, is considered internal to the FMU implementation. Therefore, only the bus-related aspects are defined in this document.

The CAN-specific wake-up pulse can be simulated by using the Wakeup operation, initiated by one Network FMU. The Bus Simulation shall distribute this operation to all participants on the bus, excluding the wake-up initiator.

Figure 5. Wake up initiated by FMU 1 wakes up FMU 2 and FMU 3 via bus.

---

1. DL is used as an abbreviation for Data Length throughout the document