CAN Bus protocol

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.

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

Currently, CAN Bus functionality in Typhoon HIL is implemented either directly on the HIL device (supported by the following Typhoon HIL devices: HIL101, HIL404, HIL602+, HIL604, HIL506, and HIL606) or through the ACE board (Automotive Communication Extender).

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.

Information regarding the available ports for each HIL device model is documented in each device's General Specifications section in the Hardware Manual. The pinout for the CAN connector per HIL device is available here:

• HIL602+ Pinout
• HIL604 Pinout
• HIL101 Pinout
• HIL404 Pinout
• HIL506 Pinout
• HIL606 Pinout

The connector pinout for the CAN controllers on the ACE board is described here: Automotive Communication Extender card pinouts.

CAN controllers on HIL devices are not terminated with any resistors. 120 Ohm termination resistors should be added as needed.

CAN controllers on the ACE board are terminated with 120 Ohm resistors.

Depending on whether the CAN controller is on the HIL device or the ACE board, each CAN controller can be configured using either the CAN Bus Setup component or the ACE 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.

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 HIL506 and 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 Bus 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 Bus Setup

The CAN Bus Setup component is shown in Figure 2. Each currently supported HIL device has two CAN controllers (referenced as CAN1 and CAN2), and the CAN Bus 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 Bus Setup component in the model for each HIL device that uses CAN protocol.

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.

ACE CAN Setup

The ACE CAN setup component is shown in Figure 3. It is used for configuring the CAN/CAN FD controllers located on the Automotive Communication Extender.

CAN Bus Send

The CAN Bus Send component is shown in Figure 4. It is used to specify the format and values of a single CAN message to be sent.

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.

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. A more detailed explanation of the data field in the CAN message for Big Endian byte order and Little Endian byte order is given below.

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.

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 shown in Figure 7. It is used to unpack a message received through a CAN network.

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 the signals can be defined.

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. A more detailed explanation of the data field in the CAN message for Big Endian byte order and Little Endian byte order is given below.

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.

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

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.

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

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 11 illustrates all that was explained above.

Data Field format in the CAN message frame for Big Endian and Little Endian byte order

As seen in Figure 1, within one message frame, it is possible to send 8 bytes (from Byte 0 to Byte 7). The Start bit parameter value specifies the position of the signal within the data field of the frame. For Little Endian signals, the start bit corresponds to the least significant bit (LSB) position, while for Big Endian signals, it corresponds to the most significant bit (MSB) position.

In these two examples, illustrated in Figure 12 and Figure 13, the message consists of three signals, but in the first case, they have Little Endian byte order, while in the second case, Big Endian. Depending on whether the signal has Big or Little Endian byte order, it's necessary to set the appropriate start bit for each signal.

By clicking the Refresh button, the arrangements of bits for each signal within the data field section of the CAN message frame is displayed in the table on the right side. Each row of this table represents one data byte of the CAN message, ranging from Byte 0 to Byte 5, as the data length in this example is 6 bytes.

If the signals have a value equal to 1, in the case of Figure 12, the data bytes appearing on the CAN bus in hexadecimal notation are 0x01, 0x04, 0x01, 0x00, 0x00, and 0x00. While in the case of Figure 13, they are 0x00, 0x41, 0x00, 0x00, 0x00, and 0x01.

Virtual HIL support

Virtual HIL currently does not support this protocol. When using a non-real-time 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.