CAN Bus protocol

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

Note: An interactive overview of the concepts and/or capabilities described here are available as part of the HIL Specialist 2.0 certification program on HIL Academy, as well as in the video Knowledgebase.

The Controller Area Network protocol (CAN or CAN Bus) is a two-wire (twisted-pair), bidirectional serial bus communication method that allows electronic subsystems to be linked together and interact in a network.

The CAN Bus protocol can be summarized in the following manner:
  • The physical layer uses differential transmission on a twisted pair wire
  • A non-destructive bit-wise arbitration is used to control access to the bus
  • The messages are small (at most eight data bytes) and are protected by a checksum
  • There is no explicit address in the messages; instead, each message carries a numeric value which controls its priority on the bus and may also serve as an identification of the contents of the message
  • An elaborate error handling scheme that results in retransmitted messages when they are not properly received
  • There are effective means for isolating faults and removing faulty nodes from the bus

CAN Bus has a multi-master capability meaning any node on the bus can initiate communication to any other node in a network.

All nodes on the CAN network must operate at the same nominal bit rate otherwise errors will occur on receiving side.

CAN specifications are international standards. Two versions are now in use: CAN 2.0A, the low-speed version, sometimes known as Basic or Standard CAN, is defined by the ISO11519 standard; CAN 2.0B, the high-speed version, also known as Full CAN or extended-frame CAN, is defined by the ISO11898 standard

Two or more nodes are required on the CAN Bus network to communicate. A message, or Frame, consists primarily of the ID (identifier), which represents the priority of the message, and up to eight data bytes. A CRC, an acknowledge slot (ACK), and other overhead are also part of the message. CAN Bus message frame is shown in Figure 1.

Figure 1. CAN Bus message frame

Messages are labeled by an identifier (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 Bus 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.

Up to 8 bytes of data can be transmitted through a single CAN Bus message. DLC field, or Data Length Code, tells how many bytes of data are present in the Data Field.

A DLC value of 0 indicates a special type of message frame called Remote Frame. Remote frames are used to request data from a specific node inside the network and these frames do not carry any information. If a node receives a Remote frame with the correct ID, that node will automatically send its data through a network.

CAN Bus protocol in Typhoon HIL toolchain

CAN Bus is supported by the following Typhoon HIL devices: HIL404, HIL602+,HIL604, and HIL606.

CAN controllers pin-out

Each currently supported HIL device has two separate CAN controllers, with separate connectors, running on a 100 MHz reference clock. These two controllers (referenced as CAN1 and CAN2) can be connected to the CAN Bus network through a standard 9-pin D-sub type male connector with the following pin-out:

Table 1. CAN controller pin-out
HIL 604/602+ HIL 404 HIL 606

CAN controllers are not terminated with any resistors. You can add 120 Ohm termination resistors at your discretion.

Each CAN controller's baud rate and execution rate can be configured using the CAN Setup component.

Each CAN controller can be used to receive and transmit messages. CAN Bus Send and CAN Bus Receive components are used to define sending and receiving of messages. CAN Bus Setup, Send, and Receive components can be found under the Communication/CAN/CAN Bus tab in the Schematic Editor Library Explorer.

Although sending and receiving of 64 bit data is supported in the CAN Bus protocol, all registers in a HIL device are 32 bit long so the received data will be converted to 32 bit and sending of 64 bit data will be equal of sending the 32 bit data.

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

CAN Bus over CAN FD controller

HIL devices that have CAN FD controllers (currently HIL606) can be configured so that these controllers behave as regular CAN Bus controllers, thus doubling the CAN Bus capabilities.

When the appropriate HIL device is selected in the Model settings, additional Tabs will appear in the CAN Setup component in order to define the controller parameters. Also, CAN FD1 and CAN FD2 values will appear as options for CAN controller selection in CAN Bus Send and CAN Bus Receive components.

CAN Setup

Each currently supported HIL device has two CAN controllers (referenced as CAN1 and CAN2), and the CAN Setup component is used to configure these controllers for each HIL device used in the model.

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

The CAN Setup component dialog window is shown in Table 2.

Table 2. CAN Setup
component component dialog window component parameters

CAN Setup

  • General
    • Execution rate
  • CANx/CAN FDx
    • Specify bit timing for CAN (FD)x
    • CAN (FD)x baud rate
    • CAN (FD)x execution rate
    • CAN (FD)x Clock Divider
    • CAN (FD)x Time Segment 1
    • CAN (FD)x Time Segment 2
    • CAN (FD)x Resynchronization Jump Width

Parameter description for CAN Setup component is given in Table 3

Table 3. CAN Setup parameter description
parameter name description
Execution rate Signal processing execution rate. Execution rate must match with the other components used in the model.
Specify bit timing for CAN (FD)x The bit timing constants (Clock Divider, Time Segment 1, Time Segment 2 and Resynchronization Jump Width) can be specified in two ways:
  • Automatic - bit timing constants are calculated automatically using the specified baud rate and the controller's reference clock of 100 MHz. The values are calculated so that the number of time quante is in range of 8 - 25, sample point is around 85%, and Resynchronization Jump Width is 4
  • Manual - bit timing constants are set manually. If the Manual method is selected, three new parameters appear that allow you to specify the timing constants as shown in Figure 2.
Note: If you are not familiar with the concept of CAN bit timing, it is highly recommended to keep this value set to Automatic
CAN (FD)x baud rate Baud rate value for controller x
CAN (FD)x execution rate Execution rate at which the sending of messages is executed for controller x
CAN (FD)x Clock Divider (hidden) Specifies the Clock Divider constant for bit timing if the Manual method is selected
CAN (FD)x Time Segment 1 (hidden) Specifies the Time Segment 1 constant for bit timing if the Manual method is selected
CAN (FD)x Time Segment 2 (hidden) Specifies the Time Segment 2 constant for bit timing if the Manual method is selected
CAN (FD)x Resynchronization Jump Width (hidden) Specifies the Resynchronization Jump Width constant for bit timing if the Manual method is selected
Figure 2. Manually specifying bit timing for CAN controller

CAN Bus Status

The CAN Setup component features the two outputs, can1 and can2, that indicate the status of CAN1 and CAN2 controllers. These statuses serve to indicate whether any errors occurred during the communication process. The potential errors that may occur are: ACK Error, Bit Error, Stuff Error, Form Error and CRC Error.

Each error corresponds to a specific bit in a binary number that is set when the error is present and reset when the error is not present:
  • xxxx1 - ACK Error - The Acknowledgement Error will occur if the transmitter does not receive a dominant acknowledgement bit in reply.
  • xxx1x - Bit Error - This error will occur when the bit received is not the same as the bit transmitted.
  • xx1xx - Stuff Error - Following the bit stuffing process, if more than five consecutive bits of the same level occur on the Bus, the Stuff Error is signaled.
  • x1xxx - Form Error - This refers to the fixed form of the field. Form check checks the frame for a standard CAN format. Violation of fixed bit format results in a Form Error.
  • 1xxxx - CRC Error - If the received CRC does not match with the calculated code, the receiver knows that the 8 bytes of the payload were corrupted or modifed during transmission, and the CRC Error is signaled.

CAN Bus Send

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

The CAN Bus Send component is shown in Table 4, while the CAN Bus Send dialog window is shown in Figure 3.

Table 4. CAN Bus Send
component component properties

CAN Bus Send

  • CAN controller
  • Data input
  • Configuration file
  • Choose message
  • Message ID
  • Identifier type
  • Message length
  • Transmit message

Hidden parameters:

  • Transmit period
Figure 3. CAN Bus Send dialog window

Parameter description for CAN Bus Send component is given in Table 5.

Table 5. CAN Bus Send property description
property name description
CAN controller Choose which controller sends the message: CAN1 or CAN2. If a HIL device with CAN FD capabilities is selected, additional CAN FD1 and CAN FD2 options will be available as well.
Data input Choose if the message is defined manually through the Dialog window, or if the message is defined through a configuration file
Configuration file Choose a configuration file to parse. The file can be in DBC or ARXML format.
Choose message Choose message from a configuration file to simulate
Message ID Specifies the message identifier value. The value for the 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. While it is possible to specify the same ID values for different CAN controllers (both messages transmitted through CAN1 and CAN2 can have the same ID), 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 message payload in bytes (8 bits). Length can be in range from 1 to 8. Since Remote frames are not supported, a length of 0 is not allowed.
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 the CAN (FD)x execution rate defined in the CAN Setup component.
  • On timer - message is transmitted periodically with the specified period time. Period time must be an integer multiplier of the CAN (FD)x execution rate defined in the CAN 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 message. With the + (plus) button, a new signal is added to the signal table in the CAN Bus Send dialog window. All signals are packed in one message in the manner defined by the signal parameters. A message preview can be seen on the right of the table, as shown in Figure 4.

Figure 4. CAN Bus Send signal definition
For each signal the following parameters can be defined:
  • Signal name - name of the signal that is shown on the CAN Bus Send component
  • Start bit - the start bit of the signal in CAN 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 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 signals Mux value.
  • Mux value - if the signal is defined as Muxed, the Mux value define when that signal will be packed. Multiple signals can be overlapped and 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 a Little Endian byte order, the position of the least significant bit is given. For signals with a Big Endian byte order, 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 the 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 Bus Send component will appear as shown in Figure 5. The signal ports can be connected to any Signal Processing part of the model.

Figure 5. CAN Bus Send component with defined signals

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

CAN Bus Receive

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

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

Table 6. CAN Bus Receive
component component parameters
  • CAN controller
  • Data input
  • Configuration file
  • Choose message
  • Message ID
  • Identifier type
  • Message length
Figure 6. CAN Bus Receive dialog window
Table 7. CAN Bus Receive parameter description
parameter name description
CAN controller Choose which controller sends the message: CAN1 or CAN2. If a HIL device with CAN FD capabilities is selected, additional CAN FD1 and CAN FD2 options will be available as well.
Data input Choose if the message is defined manually through the Dialog window, or if the message is defined through a configuration file.
Configuration file Choose a configuration file to parse. The file can be in DBC or ARXML format.
Choose message Choose message from a configuration file to simulate
Message ID Specify the message identifier value. The value for identifier is in range 0 – 2N - 1, where N is 11 or 29, depending on selected identifier type. All messages in the network are filtered and only the message with the 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 standard, 11 bit, identifier
  • 29 bit (CAN 2.0B) - used to receive messages with extended, 29 bit, identifier
Message length Specify the length of the payload in bytes (8 bits). Length can be in range from 1 to 8. Since Remote frames are not supported, length of 0 is not allowed.

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

Figure 7 shows how de signals can be defined.

Figure 7. CAN Bus Receive signal definition
For each signal, the following parameters can be defined:
  • Signal name - name of the signal that is shown on the CAN Bus Send component
  • Start bit - the start bit of the signal in CAN message
  • Length - length of the signal in bits
  • Byte order - represents the byte order of the signal. The 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 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 a Little Endian byte order, the position of the least significant bit is given. For signals with a Big Endian byte order, the position of the most significant bit is given. The bits are counted in the saw-tooth manner.

The factor and offset define the linear conversion to convert signals coded value into signals 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 Bus Receive component appears as shown in Figure 8. The signal ports can be connected to any Signal Processing part of the model.

Figure 8. CAN Bus Receive component with defined signals

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

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

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.

Figure 9. CAN messages defined using DBC file

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.

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 8. 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 9. 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 4, 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 configuration file to specify the message parameters, just set the file_path property to the path of the desired 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")

CAN execution rates explained

All CAN related components, with the exception of CANopen, have multiple execution rates and timings defined. These values are:
  • Execution rate
  • CANx controller execution rate
  • CANx baud rate
  • Transmit period

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.

Figure 10. CAN timings

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.