17/07/2023, 18:04 CAN Bus protocol

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.

https://www.typhoon-hil.com/documentation/typhoon-hil-software-manual/References/can_bus_protocol.html 1/10
17/07/2023, 18:04 CAN Bus protocol

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

Note:
CAN Bus and CANopen are NOT supported on HIL402 or legacy HIL devices.

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:
Figure 2. CAN controller connector pin-out

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

Table 1. CAN Setup

component component dialog window component parameters

https://www.typhoon-hil.com/documentation/typhoon-hil-software-manual/References/can_bus_protocol.html 2/10
17/07/2023, 18:04 CAN Bus protocol

component component dialog window component parameters

General
Execution rate
CANx/CAN FDx
Specify bit timing for
CAN Setup 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 2

Table 2. CAN Setup parameter description

Figure 3. 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 3, while the CAN Bus Send dialog window is shown in Figure 4.

Table 3. CAN Bus Send

component component properties

https://www.typhoon-hil.com/documentation/typhoon-hil-software-manual/References/can_bus_protocol.html 3/10
17/07/2023, 18:04 CAN Bus protocol

component component properties

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

Hidden parameters:

Transmit period

Figure 4. CAN Bus Send dialog window

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

Table 4. 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

https://www.typhoon-hil.com/documentation/typhoon-hil-software-manual/References/can_bus_protocol.html 4/10
17/07/2023, 18:04 CAN Bus protocol

property name description

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

Figure 5. 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

https://www.typhoon-hil.com/documentation/typhoon-hil-software-manual/References/can_bus_protocol.html 5/10
17/07/2023, 18:04 CAN Bus protocol

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 6. The signal ports
can be connected to any Signal Processing part of the model.

Figure 6. 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 5, whereas the CAN Bus Send dialog window is shown in Figure 7.

Table 5. CAN Bus Receive

component component parameters

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

Figure 7. CAN Bus Receive dialog window

https://www.typhoon-hil.com/documentation/typhoon-hil-software-manual/References/can_bus_protocol.html 6/10
17/07/2023, 18:04 CAN Bus protocol

Table 6. 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 8 shows how de signals can be defined.

Figure 8. CAN Bus Receive signal definition

https://www.typhoon-hil.com/documentation/typhoon-hil-software-manual/References/can_bus_protocol.html 7/10
17/07/2023, 18:04 CAN Bus protocol

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 9. The signal ports
can be connected to any Signal Processing part of the model.

Figure 9. 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.

https://www.typhoon-hil.com/documentation/typhoon-hil-software-manual/References/can_bus_protocol.html 8/10
17/07/2023, 18:04 CAN Bus protocol

An example is shown in Figure 10.

Figure 10. 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 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

https://www.typhoon-hil.com/documentation/typhoon-hil-software-manual/References/can_bus_protocol.html 9/10
17/07/2023, 18:04 CAN Bus protocol

Field name Allowed values

"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 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")

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.

https://www.typhoon-hil.com/documentation/typhoon-hil-software-manual/References/can_bus_protocol.html 10/10