CAN Bus protocol
Description of the CAN Bus protocol implementation in the Typhoon HIL toolchain.
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 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.
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:
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.
component | component dialog window | component parameters |
---|---|---|
CAN Setup |
|
Parameter description for CAN Setup component is given in Table 3
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:
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 |
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.
- 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.
component | component properties |
---|---|
CAN Bus Send |
Hidden parameters:
|
Parameter description for CAN Bus Send component is given in Table 5.
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:
|
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:
|
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.
- 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.
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.
component | component parameters |
---|---|
|
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:
|
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.
- 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.
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.
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.
Field name | Allowed values |
---|---|
"On event" | True, False |
"On timer" | True, False |
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 |
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
- 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.
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.