# CAN FD Protocol

Description of the CAN FD protocol implementation in the Typhoon HIL toolchain.

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.

CAN FD offers four major benefits:
• Increased length - CAN FD supports up to 64 data bytes per data frame vs 8 data bytes for standard CAN. This reduces protocol overhead and leads to an improved protocol efficiency.
• Increased speed - CAN FD supports dual bit rates: The nominal (arbitration) bit - rate limited to 1 Mbit/s as in standard CAN - and the data bit-rate, which depends on the network topology/transceivers. In practice, data bit-rates of up to 5 Mbit/s are achievable.
• Better reliability - CAN FD uses an improved cyclic redundancy check (CRC) and the "protected stuff-bit counter", which lower the risk of undetected errors. This is vital in safety-critical applications, such as vehicles and industrial automation.
• Smooth transition - CAN FD and standard-CAN-only ECUs can be mixed under certain conditions. This allows for a gradual introduction of CAN FD nodes, greatly reducing costs and complexity for OEMs.

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 tool chain

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 the CAN FD protocol is used, exactly one CAN FD Setup component must exist in the model. Each node is able to send and receive messages, but not simultaneously.

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

• HIL device ID
• CAN1 execution rate
• CAN2 execution rate

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

Table 2. CAN FD Setup parameter description
parameter name description
HIL device ID The Value of this combo box specifies for what HIL device the CAN controllers are configured
CAN1 execution rate Execution rate at which the sending of messages is executed for the CAN1 controller
CAN2 execution rate Execution rate at which the sending of messages is executed for CAN2 controller

## 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
• Import DBC 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.

Table 4. CAN FD Send property description
property name description
CAN controller Choose which controller is sending the message (CAN1 or CAN2)
Data input Choose if the message is defined manually through the Dialog window, or if the message is defined through a .dbc file
Import DBC file Choose a .dbc file to parse
Choose message Choose message from a .dbc file to simulate
Message ID Specifies the message identifier value. The value for ID can be in range 0 - 2N-1, where N is 11 or 29, depending on the selected ID type
Note: The Identifier value must be unique in a CAN network. Although it is possible to specify the same ID values for different CAN controllers (both messages transmited through CAN1 and CAN2 can have the same ID) you must be aware that connecting these controllers to the same network may cause unexpected errors in communication.
Identifier type Defines the identifier type. Identifier length can be:
• 11 bit (CAN 2.0A) - used to create messages with a standard, 11 bit, identifier
• 29 bit (CAN 2.0B) - used to create messages with an extended, 29 bit, identifier
Message length Specifies the length of the message pay load in bytes (8 bits). Length can be in a range from 1 to 64.
Transmit message Specifies the condition when the message is transmitted. The condition can be:
• On event - an additional event terminal is created on the component that triggers sending. The event change is checked on theCANx execution rate defined in theCAN FD Setup component.
• On timer - message is transmitted periodically with the specified period time. The period time must be an integer multiplier of the CANx execution rate defined in the CAN FD Setup component.
Transmit period (hidden) Specifies the period of message sending. This parameter is enabled if the On timer value is checked.

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.

For each signal the following parameters can be defined:
• Signal name - name of the signal that is shown on the CAN FD Send component
• Start bit - the start bit of the signal in the CAN FD message
• Length - length of the signal in bits
• Byte order - represents the byte order of the signal. Signal can be defined as Little or Big Endian
• Data type - signal data type. Signal can be defined as uint, int, or real
• Mux type - choose between None, Muxer, and Muxed to define if the multiplexer is used when sending messages. If the type is None, the signal will behave normally and it will always be packed in the message. If the type is Muxer, that signal will be packed in the message, and its value will be used as a multiplexer to determine which Muxed signal will be packed as well. If the type is Muxed, that signal will be packed in the message only when the Muxer value is the same as that signal's Mux value.
• Mux value - if the signal is defined as Muxed, the Mux value define when that signal will be packed. If multiple signals are overlapped, the Mux value will be used to define which signal is packed.
• Scale - define the scale performed on the signal value
• Offset - define the offset performed on the signal value
• Min - define the minimum signal value
• Max - define the maximum signal value
• Unit - define signal units

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.

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.

component component parameters

• CAN controller
• Data input
• Import DBC file
• Choose message
• Message ID
• Identifier type
• Message length
Table 6. CAN FD Receive parameter description
parameter name description
CAN controller Choose on which controller to receive the message (CAN1 or CAN2)
Data input Choose if the message is defined manually through the Dialog window, or if the message is defined through a .dbc file
Import DBC file Choose a .dbc file to parse
Choose message Choose message from a .dbc file to simulate
Message ID Specify the message identifier value. The value for an identifier is in the range of 0 – 2N - 1, where N is 11 or 29, depending on the selected identifier type. All messages in the network are filtered and only the message with an identifier value equal to the value defined in the CAN Bus Receive component is parsed.
Identifier type Define the identifier type. Identifier length can be:
• 11 bit (CAN 2.0A) - used to receive messages with a standard, 11 bit, identifier
• 29 bit (CAN 2.0B) - used to receive messages with an extended, 29 bit, identifier
Message length Specify the length of the payload in bytes (8 bits). Length can be in range a from 1 to 64.

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.

For each signal the following parameters can be defined:
• Signal name - name of the signal that is shown on the CAN FD Send component
• Start bit - the start bit of the signal in the CAN FD message
• Length - length of the signal in bits
• Byte order - represents the byte order of the signal. Signal can be defined as Little or Big Endian
• Data type - signal data type. Signal can be defined as uint, int, or real
• Mux type - choose between None, Muxer, and Muxed to define if the multiplexer is used when decoding messages.
• Mux value - if the signal is defined as Muxed, the Mux value defines when that signal will be unpacked.
• Scale - define the scale performed on the signal value
• Offset - define the offset performed on the signal value
• Min - define the minimum signal value
• Max - define the maximum signal value
• Unit - define signal units

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.

## Using DBC files to specify CAN messages

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

The DBC file type is primarily associated with CANdb by Vector Informatik GmbH. The file name extension .DBC is used to store all information that describes the network.

To load the DBC file, user must choose CANdb file for Data input property and navigate to the desired file using Import DBC 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. The example is shown on .

When using DBC 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. If then the Data input is changed back to CANdb file, the parameters will be changed back to the values defined in the DBC 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.

In order to change the Transmit message value, a Python dictionary must be specified to the transmit_type property. The dictionary has the following fields:
Table 7. Transmit message dictionary
Field name Allowed values
"On event" True, False
"On timer" True, False
In order to change the Signal information, a list of requests needs to be specified to the signals property. This list is comprised of Python dictionaries with predefined fields. Each request dictionary has the following fields:
Table 8. Signal information dictionary fields
Field name Allowed values
"name" ASCII string
"start_bit" 0 - 63
"length" 1 - 64
"byte_order" "Little Endian", "Big Endian"
"data_type" "int", "uint", "real"
"mux_type" "None", "Muxer", "Muxed"
"mux_val" positive integer
"scale" real number
"offset" real number
"min" real number
"max" real number
"unit" ASCII string
In order to specify the Transmit message to send on event and requests as defined in Figure 5, the following code should be executed:
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)
In order to use a DBC file to specify the message parameters, just set the file_path property to the path of the desired DBC file. The component will automatically parse the file and you just need to choose the desired message. The following code illustrates this:
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")

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