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

Operations

This section defines the specified operations for CAN, CAN FD and CAN XL. The following tables provides 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 byte	Contains the OP Code (0x10) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 16 + Data Length.
	ID	4 byte	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 byte	Specifies the length of the Data argument in bytes.
	Data	n byte	Stores the given frame data to transfer, whereby the valid length of the data depends on the CAN Format.
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 response 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 byte	Contains the OP Code (0x11) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 17 + Data Length.
	ID	4 byte	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 byte	Specifies the length of the Data argument in bytes.
	Data	n byte	Stores the given frame data to transfer, whereby the valid length of the data depends on the CAN FD Format.
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 byte	Contains the OP Code (0x12) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 22 + Data Length.
	ID	4 byte	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 byte	Represents the CAN XL Acceptance Field (AF).
	Data Length	2 byte	Specifies the length of the Data argument in bytes.
	Data	n byte	Stores the given frame data to transfer, whereby the valid length of the data depends on the CAN XL Format.
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 byte	Contains the OP Code (0x20) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 12.
	ID	4 byte	The ID of the confirmed CAN message.
Behavior	The specified operation shall be produced by the Bus Simulation and consumed by Network FMUs. If the structural parameter org.fmi_standard.fmi_ls_bus.Can_BusNotifications of a Network FMU is set to false, the Network FMU does not wait for any responses from a Bus Simulation, i.e., potentially received Confirm operations are discarded by the Network FMU. Depending on the status of the specified 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 byte	Contains the OP Code (0x30) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 12.
	ID	4 byte	The ID of the CAN message which which could not be transmitted immediately, because it loses 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. If the structural parameter org.fmi_standard.fmi_ls_bus.Can_BusNotifications of a Network FMU is set to false, the Network FMU does not wait for any responses from a Bus Simulation, i.e., potentially received Arbitration Lost operations are discarded by the Network FMU.

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 byte	Contains the OP Code (0x31) of the operation.
	Length	4 byte	Defines the cumulative length of all arguments in bytes. The following applies for this operation: Length = 15.
	ID	4 byte	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	While 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. If the structural parameter org.fmi_standard.fmi_ls_bus.Can_BusNotifications of a Network FMU is set to false, the Network FMU does not wait for any responses from a Bus Simulation, i.e., potentially received Bus Error operations are discarded by the Network FMU.

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 byte	Contains the OP Code (0x40) of the operation.
	Length			4 byte	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 byte	The CAN baud rate value to configure. The required unit for the baud rate value is bit/s.
		CAN_FD_BAUDRATE	Baud Rate	4 byte	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 byte	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 byte	Contains the OP Code (0x41) of the operation.
	Length	4 byte	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 byte	Contains the OP Code (0x42) of the operation.
	Length	4 byte	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

Using structural parameters, FMUs can be parameterized according to importer specifications. This chapter specifies the structural parameters that each CAN-specific Network FMU shall provide.

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, the org.fmi_standard.fmi_ls_bus.Can_BusNotifications parameter is introduced. If the value of the parameter is set to false, the Network FMU must not wait for any response after a Transmit operation ("fire-and-forget"). The default value shall be false to allow the Network FMU to be run natively in each simulation scenario. If the Network FMU shall be configured to handle responses in the form of Confirm-, Bus Error- and Arbitration Lost operations, the org.fmi_standard.fmi_ls_bus.Can_BusNotifications parameter shall be set to true.
[This does not necessarily mean the FMU must fully support CAN error handling or sophisticated arbitration mechanisms. A simple Network FMU might also choose to treat Bus Error or Arbitration operations in a simplified manner, e.g., by treating them as a positive confirmation.]

FMU parameter for the configuration of bus notifications.

    org.fmi_standard.fmi_ls_bus.Can_BusNotifications
        Description:  "Specifies whether the respective Network FMU can rely on a Confirm,
                      Bus Error or Arbitration Lost operation after sending a message."
        Type:         Boolean
        Causality:    structuralParameter
        Variability:  fixed
        Start:        "false"

This structural parameter is mandatory for Network FMUs only. A Bus Simulation (FMU) does not require this structural parameter.

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 configuration kind of a 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 structural parameter org.fmi_standard.fmi_ls_bus.Can_BusNotifications is defined to support lightweight bus simulations and directly connected Network FMUs.

If org.fmi_standard.fmi_ls_bus.Can_BusNotifications is set to false (default), then Network FMUs must not rely on receiving Confirm operations. 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 org.fmi_standard.fmi_ls_bus.Can_BusNotifications is set to false, the self confirmation shall be realized internally within the respective Network FMU.

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 org.fmi_standard.fmi_ls_bus.Can_BusNotifications parameter of the Network FMUs can be set to true as Network FMUs can rely on receiving Confirm operations.

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