CAN FD Protocol

CAN FD (Controller Area Network Flexible Data-Rate) is a data-communication protocol typically used for broadcasting sensor data and control information on 2 wire interconnections between different parts of electrical instruments or control systems. CAN FD is an extension to the original CAN bus protocol. It was developed to meet the need to increase the data transfer rate (up to 5 times faster with CAN FD) and support larger message frame sizes for use in modern automotive Electronic Control Units (ECU) and many other industry applications.

The primary difference between standard CAN (Controller Area Network) and CAN FD is the Flexible Data (FD). Using CAN FD, the Electronic Control Unit can switch to different data-rate and communicate with larger or smaller message sizes. Enhanced features in CAN FD include the capability to select and switch to a faster or slower data-rates, and to pack more data within the same CAN message, saving time when transporting it over the CAN network. Faster data speed and enhanced data capacity result in several system operational advantages compared to standard CAN. Using CAN FD, sensor and control data can be sent and received by the ECU software much quicker.

Messages are labeled by an identifier (ID), which can be 11 bit (Standard ID) or 29 bit (Extended ID), assigned to one or more nodes on the network. All nodes receive the message and perform a filtering operation. That is, each node executes an acceptance test on the identifier to determine if the message, and thus its content, is relevant to that particular node. Only the node(s) for which the message is relevant will process it. All others ignore the message.

The identifier has two more functions, as well. It contains data that specifies the priority of the message and it allows the hardware to arbitrate for the bus. That is, it’s used to determine which node gets to transmit if several nodes attempt to do so simultaneously. Message IDs must be unique in a single CAN FD network, otherwise two nodes would continue transmission beyond the end of the arbitration field (ID) causing an error. The lower the numerical ID, the higher the message priority.

CAN FD can transmit up to 64 bytes of data through a single CAN FD message, which is one of the main differences between CAN Bus and CAN FD. The DLC field, or Data Length Code, tells how many bytes of data are present in the Data Field.

CAN FD protocol in the Typhoon HIL toolchain

Currently, only HIL606 devices support CAN FD protocol.

HIL606 has two separate CAN FD controllers, with separate connectors. These two controllers (referenced as CAN1 and CAN2) can be connected to the CAN FD network through a standard 9-pin D-sub type male connector with the following pin-out:

CAN FD controllers are not terminated with any resistors. 120 Ohm termination resistors should be added as needed.

Each CAN controller's baud rate and execution rate can be configured using the CAN FD Setup component that can be found under the Communication/CAN/CAN FD path in the Schematic Editor Library Explorer

Each CAN controller can be used to receive and transmit messages. CAN FD Send and CAN FD Receive components are used to define the sending and receiving of messages. These two components can be found under the Communication/CAN/CAN FD path in the Schematic Editor Library Explorer

Although the sending and receiving of 64 bit data is supported in the CAN FD protocol, all registers in a HIL device are 32 bits. This means the received data will be converted to 32 bit, and any sent 64 bit data will instead be packed and sent as 32 bit data.

Also, it is important to mention that handling of Remote frames is currently not supported.

CAN FD Setup

The HIL606 device has two CAN FD controllers (referenced as CAN1 and CAN2). A CAN FD Setup component is used to configure these controllers for each HIL device used in the model.

If CAN FD protocol is used, there must be exactly one CAN FD Setup component for each HIL device that uses CAN FD protocol.

The CAN FD Setup component dialog window is shown in Table 1.

Table 1. CAN FD Setup

component	component dialog window	component parameters
CAN FD Setup		CAN1 baud rate (header/payload) CAN1 execution rate CAN2 baud rate (header/payload) CAN2 execution rate Execution rate

A parameter description for the CAN FD Setup component is given in Table 2.

CAN FD Send

The CAN FD Send component is used to specify the format and values of a single CAN FD message to be sent.

The CAN FD Send component is shown in Table 3, whereas the CAN FD Send dialog window is shown in Figure 3.

Table 3. CAN FD Send

component	component properties
CAN FD Send	CAN controller Data input Configuration file Choose message Message ID Identifier type Message length Transmit message Hidden parameters: Transmit period

A parameter description for the CAN FD Send component is given in Table 4.

Multiple signals can be transmitted through a single CAN FD message. With the + (plus) button, a new signal is added to the signal table in the CAN FD Send dialog window. All signals are packed in one message in the manner defined by the signal parameters. The message preview can be seen on the right of the table.

Figure 4 shows how the signals can be defined.

The Start bit value specifies the position of the signal within the data field of the frame. For signals with byte order Little Endian the position of the least significant bit is given. For signals with byte order Big Endian the position of the most significant bit is given. The bits are counted in a saw-tooth manner.

The factor and offset define the linear conversion to convert a signal's coded value into that signal's physical value and vice versa:

coded_value = (physical_value - offset) / scale

physical_value = coded_value * scale + offset

The minimum and maximum define the range of valid physical values of the signal.

After the signals are added to the list, the CAN FD Send component looks like it does in Figure 5. The signal ports can be connected to any Signal Processing part of the model.

There can exist numerous CAN FD Send components in the schematic and every such component describes one CAN FD message to be sent. When adding additional CAN FD Send components to the model for sending multiple messages, you must ensure that all messages have unique IDs.

CAN FD Receive

The CAN FD Receive component is used to unpack a message received through a CAN FD network.

The CAN FD Receive component is shown in Table 5, whereas the CAN Bus Send dialog window is shown in Figure 6.

Table 5. CAN FD Receive

component	component parameters
CAN FD Receive	CAN controller Data input Configuration file Choose message Message ID Identifier type Message length

With the + (plus) button, a new signal is added to the signal table in the CAN FD Receive dialog window. All signals are unpacked in a manner defined by the signal parameters.

Figure 7 shows how the signals can be defined.

The Start bit value specifies the position of the signal within the data field of the frame. For signals with byte order Little Endian the position of the least significant bit is given. For signals with byte order Big Endian the position of the most significant bit is given. The bits are counted in a saw-tooth manner.

The factor and offset define the linear conversion to convert a signal's coded value into that signal's physical value and vice versa:

coded_value = (physical_value - offset) / scale

physical_value = coded_value * scale + offset

The minimum and maximum define the range of valid physical values of the signal.

After the signals are added to the list, the CAN FD Receive component looks as it does in Figure 8. The signal ports can be connected to any Signal Processing part of the model.

There can exist numerous CAN FD Receive components in the schematic and every such component is used to receive a CAN FD message with the defined ID value. Messages that have an ID value that does not mach any ID value defined in CAN FD Receive components are ignored.

The rcv_cnt value increases by 1 every time a new message is received.

RAM overflow prevention and FIFO size calculation

Due to the RAM limitation of 2048 bytes, the FIFO buffer size needs to be calculated to prevent overflow. The calculated FIFO size limits the number of components that can simultaneously send or receive messages without data loss on a single controller. FIFO sizes for sending and receiving are calculated based on whether both the Send and Receive components are used simultaneously on the same controller or just one:

• The Send and Receive components use the same CAN FD controller. The formula to calculate the maximum FIFO size applies to both Send and Receive components:

  fifo_size_max = total_ram / (2 * (data_length + meta_data_length))

  If the sum of fifo_size_max for Send and for Receive exceeds 32, both are adjusted so that the sum is limited to 32 to stay within the FIFO size limitation. [1]

• Only the Send or Receive components use the same CAN FD controller. The formula to calculate the maximum FIFO size applies to both Send and Receive components:

  fifo_size_max = total_ram / (data_length + meta_data_length)

  If the fifo_size_max exceeds 32, it is limited to 32 to stay within FIFO size limitation. [1]

Formula parameters:

• total_ram: amount of RAM available for the CAN FD controller (i.e. 2048 bytes)
• data_length: maximum data length of all used CAN Send/Receive components on single controller
• meta_data_length: length of any metadata for each message, such as headers or additional control information in bytes. Default value is 20 bytes.

Using configuration files to specify CAN messages

Both Send and Receive components can import DBC or ARXML files to define the messages. The principle is the same for both components and it will be demonstrated only on the CAN Bus Send component.

To load the configuration file, you must choose Configuration file as the Data input property and navigate to the desired file using the Choose file button. If the file is parsed correctly, the Choose message combo box will be populated with the message names from the file. Choosing different messages will change the message and signal parameters in the dialog. An example is shown in Figure 9.

When using DBC or ARXML files to define CAN messages, all message and signal parameters are disabled for editing. If the Data input is changed to Dialog window, the parameters will be enabled for editing, but if the Data input is subsequently changed back to Configuration file, the parameters will be changed back to the values from the configuration file.

Changing component property values using Schematic API

The custom component dialog is designed to easily define CAN message parameters. Changing these values is also possible using standard Schematic API functions but in a modified way. Namely, all properties except Transmit message and Signal information are changed in the standard way, where Transmit message is specified as a Python dictionary type and Request information must be specified as a list of Python dictionary types.

transmit_type = {
    "On event": True,
    "On timer": False
}
mdl.set_property_value(mdl.prop(can_component, "transmit_type"), transmit_type)

signals = [
    {"name": "signal0", "start_bit": 0, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "None"},
    {"name": "signal1", "start_bit": 8, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "Muxer"},
    {"name": "signal2", "start_bit": 16, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "Muxed", "mux_val": "0"},
    {"name": "signal3", "start_bit": 16, "length": 8, "byte_order": "Little Endian", "data_type": "uint", "mux_type": "Muxed", "mux_val": "1"}
]
mdl.set_property_value(mdl.prop(can_component, "signals"), signals)

dbc_file_path = r"C\dbc_files\ford_fusion_2018_pt.dbc"
mdl.set_property_value(mdl.prop(can_component, "file_path"), dbc_file_path)
mdl.set_property_value(mdl.prop(can_component, "choose_message"), "Lane_Keep_Assist_Control")

CAN execution rates explained

This section aims to provide a clarification for each of these values and how they relate to each other.

First of all, it is important to distinguish two aspects in all models that use CAN communication protocol: the Signal Processing aspect, and the processing of the CAN communication protocol itself. During model compilation, all Signal Processing components on the schematic are combined in one application that is executed on one CPU core. On the other hand, all CAN components (even though they are a part of the Signal Processing library) are combined in a separate application that is executed on a different CPU core. These two applications are two different entities.

All Signal Processing components (including the CAN components) have the Execution rate property. All components that are connected and perform a logical function share the same execution rate value. The execution rate value defines how often this function is performed.

The CANx controller execution rate has the exact same function, but is specific to the CAN application. It defines how often the CAN function is called.

Each CAN Send component has a Transmit period property that defines how often that message is sent to the network. The Transmit period and the CANx controller execution rate are in direct correlation to each other in a way that the CANx controller execution rate serves as a granularity value for Transmit period. In other words, if the CANx controller execution rate is set to 1 ms, the Transmit period can only be an integer multiple of 1 ms, that is N*1 ms. Similar, if the CANx controller execution rate is set to 3 ms, the Transmit period can only have a value of N*3 ms.

Baud rate is the only value that is defined by the CAN standard. This value is expressed in bits/s and defines how quickly the message is relayed between two CAN controllers. The difference between the Transmit period and the baud rate can be easily illustrated by the example of a metronome. Metronomes periodically makes a click sound (Transmit period), but that click travels by the speed of sound to the listener (baud rate).

Figure 10 illustrates all that was explained above.

Virtual HIL support

Virtual HIL currently does not support this protocol. When using a Virtual HIL environment (e.g. when running the model on a local computer), inputs to this component will be discarded and outputs from this component will be zeroed.

References

1. Microchip Technology Inc., "MCP251XXFD CAN-FD Controller Module Family Reference Manual", 2017-2018, pp. 22