CAN Bus protocol

This section describes the CAN Bus protocol.

The Controller Area Network protocol (CAN or CAN Bus) ia 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 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, acknowledge slot (ACK) and other overhead are also part of the message. CAN Bus message frame is shown on Figure 1

Figure 1: CAN Bus message frame



Messages are labeled by an identifier (ID) assigned 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 transimtted through a single CAN Bus message. DLC field, or Data Length Code, tells how many bytes of data are present in the Data Field.

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 recives Remote frame with the correct ID, that node will automatically send its data through a network.

CAN Bus protocol in Typhoon HIL tool chain

Currently, only HIL404, HIL602+ and HIL604 devices have support for CAN Bus protocol.

Each HIL404/602+/604 has two separate CAN controllers, with separate connectors, running on 100 MHz reference clock. This two controllers (referenced as CAN1 and CAN2) can be connected to the CAN Bus network through 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. Its up to user to add 120 Ohm termination resistors.

Each CAN controllers baud rate and execution rate can be configured using CAN Setup component that can be found under Communication/CAN Bus tab in schematic editor library browser.

Each CAN controller can be used to receive and transmit messages. CAN Bus Sendand CAN Bus Receive components are used to define sending and receiving of messages. These two components can be found under Communication/CAN/CAN Bus tab in schematic editor library browser.

Although sending and receiving of 64 bit data is supported in the CAN Bus protocol, all registers in 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 Setup

Each HIL404/602+/604 device has two CAN controllers (referenced as CAN1 and CAN2) and CAN Setup component is used to configure these controllers for each HIL device used in the model.

If CAN protocol is used, exactly one CAN Setup component must exist in the model. Each node is able to send and receive messages, but not simultaneously.

CAN Setup component dialog window is shown in Table 1

Table 1. CAN Setup
component component dialog window component parameters

CAN Setup

  • HIL device ID
  • Specify bit timing for CANx
  • CANx baud rate
  • CANx execution rate

Hidden parameters:

  • CANx Clock Divider
  • CANx Time Segment 1
  • CANx Time Segment 2
  • CANx Resynchronization Jump Width

Parameter description for CAN Setup component is given in Table 2

Table 2. CAN Setup parameter description
parameter name description
HIL device ID Value of this combo box specifies for what HIL device the CAN controllers are configurted
Specify bit timing for CANx The bit timing constants (Clock Divider, Time Segment 1, Time Segment 2 and Resynchronization Jump Width) can be specified in two manners:
  • Automatic - bit timing constants are calculated automatically using specified baud rate and controllers reference clock of 100 MHz. The values are calculated so that the number of Time Quante is in rane of 8 - 25, sample point is around 85 % and Resynchronization Jump Width is 4
  • Manual - bit timing constants are set manually by user. If Manual method is selected, three new parameters appear that alow user to specify the timing constants as shown in Figure 3
Note: If the user is not familiar with the concept of CAN bit timing, it is highly recommended that the method of specifying bit timing constants stay Automatic
CANx baud rate Baud rate value for controller x
CANx execution rate Execution rate at which the sending of messages is executed for controller x
CANx Clock Divider (hidden) Specifies the Clock Divider constant for bit timing if the Manual method is selected
CANx Time Segment 1 (hidden) Specifies the Time Segment 1 constant for bit timing if the Manual method is selected
CANx Time Segment 2 (hidden) Specifies the Time Segment 2 constant for bit timing if the Manual method is selected
CANx Resynchronization Jump Width (hidden) Specifies the Resynchronization Jump Width constant for bit timing if the Manual method is selected

Figure 3: Manually specifying bit timing for CAN controller



CAN Bus Send

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

CAN Bus Send component is shown in Table 3, whereas CAN Bus Send dialog window is shown in Figure 4.

Table 3. CAN Bus Send
component component properties

CAN Bus Send

  • CAN controller
  • Data input
  • Import DBC file
  • Choose message
  • Message ID
  • 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 below.

Table 4. CAN Bus Send property description
property name description
CAN controller Chose which controller is sending the message (CAN1 or CAN2)
Data input Choose if the message is defined manually thorough Dialog window, or if the message is defined through .dbc file
Import DBC file Choose .dbc file to parse
Choose message Choose message from .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: Identifier value must be unique in a CAN network. Although it is posible to specify the same ID values for different CAN controllers (both messages transmited through CAN1 and CAN2 can have the same ID) the user must be aware that by 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 standard, 11 bit, identifier
  • 29 bit (CAN 2.0B) - used to create messages with extended, 29 bit, identifier
Message length Specifies the length of message pay load 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.
Transmit message Specifies the condition when the message is transmited. The condition can be:
  • On event - additional event terminal is created on the component that triggers sending. Event change is checked on CANx execution rate defined in CAN Setup component.
  • Periodically - message is transmited periodically with the specified period time. Period time must be an integer multiplier of CANx execution rate defined in CAN Setup component.
Transmit period (hidden) Specifies the period of message sending. This parameter is enabled if Periodically is chosen for value of Transmit message parameter.

Multiple signals can be transmitted through a single CAN message. With the + (plus) button, new signal is added to the signal table in CAN Bus 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 5 shows how the signals can be defined.

Figure 5: CAN Bus Send signal definition



For each signal the folowing 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, 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, Mux value define when that signal will be packed. Multiple signals can be overlapped and 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 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 Send component looks like in the 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 exist numerous CAN Bus Send components in the 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, user must ensure that all messages have unique IDs.

CAN Bus Receive

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 CAN Bus Send dialog window is shown in Figure 7.

Table 5. CAN Bus Receive
component component parameters
  • CAN contorller
  • Data input
  • Import DBC file
  • Choose message
  • Message ID
  • Identifier type
  • Message length

Figure 7: CAN Bus Receive dialog window



Table 6. CAN Bus 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 thorough Dialog window, or if the message is defined through .dbc file
Import DBC file Choose .dbc file to parse
Choose message Choose message from .dbc 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 pay load 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, new signal is added to the signal table in 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



For each signal the folowing 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 decoding messages.
  • Mux value - if the signal is defined as Muxed, Mux value define 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 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 looks like in the 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 exist numerous CAN Bus Receive components in the 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 DBC files to specify CAN messages

Both CAN Bus Send and CAN Bus Receive can import DBC files to define the messages. The principle is the same for both components and it will be demonstrated only on CAN Bus 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 .

Figure 10: CAN messages defined using DBC file



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.

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.