Controller Area Network (CAN) - Layer#

Protocol Basics (ISO 11898-2)#

ISO 11898-2 is an international standard that defines the physical and data link layer requirements for Controller Area Network (CAN) communication. It’s commonly referred to as the “High-speed CAN” standard, used in automotive and industrial applications that require high-speed, reliable communication. The standard defines the physical layer requirements for a high-speed CAN bus, including the electrical characteristics of the bus, the signaling method, and the required cable types. It also defines the data link layer requirements, including the message format, error detection and handling, and communication protocol. The standard specifies a bit rate of up to 1Mbps, using a differential signaling method to transmit data over a twisted pair of wires. It also defines using a non-return-to-zero (NRZ) encoding scheme for data transmission, which provides increased noise immunity and improved signal quality. Additionally, the standard specifies the use of a cyclic redundancy check (CRC) for error detection and the use of an acknowledgment mechanism to ensure that messages are transmitted and received correctly.

Summary

  • Protocol release in 1986 (revised in 1991 [RobertBGmbH])

  • Multi-master serial bus

  • Two or more nodes are required

  • Two-wire bus

  • Termination resistors are required (e.g. 120 Ohm)

../../_images/CAN_ISO11898-2_Network.png

Fig. 13 CAN-Network overview. Author: EE JRW, CC BY-SA 4.0#

  • Differential signal

  • Wired AND

  • Low signal (0 Bit) is dominant

../../_images/ISO11898-2.png

Fig. 14 CAN-Network overview. Author: EE JRW, CC BY-SA 4.0#

  • On Dual-CAN interfaces, PIN 1 and PIN 8 are used to interface with a second CAN-Bus.

    • PIN 1: CAN LOW

    • PIN 8: CAN HIGH

../../_images/can_connector.png

Fig. 15 D-SUB (DB9) pinout. (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019YIGSA2)#

CAN-Node#

To understand low-level attacks on CAN-Networks, it’s required to know the role of the individual components of a CAN-Node.

  • Processing unit, microprocessor, host processor

    • Runs application firmware

    • Processes received messages from message boxes

    • Put messages to transmit into message boxes

  • CAN controller

    • Integrated into MCU or connected via SPI

    • TX: Generates bits from CAN-frames

    • RX: Generates CAN-frames from bits

    • Handles re-transmission, arbitration, bit-stuffing, CRC, acknowledgment

  • CAN Transceiver

    • Generates a differential signal

../../_images/CAN_Node.png

Fig. 16 CAN-Network overview. Author: EE JRW, CC BY-SA 4.0#

CAN frame on the wire#

A CAN (Controller Area Network) frame is a standardized data structure used to transmit and receive messages on a CAN bus. It is composed of several fields that are used to store the necessary information about the message being transmitted.

  1. Start-of-frame: A dominant bit, indicating the start of a CAN message.

  2. Arbitration: This is a unique identifier that is used to identify the message. The Remote Transmission Request (RTR) bit is part of the arbitration field. This bit is used to indicate whether the message is a data frame or a remote transmission request (RTR) frame. A data frame carries a data payload, while an RTR frame requests data from a specific node.

  3. Control: This is a 6-bit field that indicates the type of message, such as a standard or extended frame, and the number of bytes of data payload that are present in the message.

  4. Data: This is an array of up to 8 bytes that contains the data payload of the message.

  5. CRC: The Cyclic Redundancy Check (CRC) field is used to ensure that the message has been transmitted without errors.

  6. ACK: A dominant bit, indicating the successful reception of a message. This bit is transmitted by the receiver of the message.

  7. End-of-frame: Seven recessive bits, without a stuffing bit.

../../_images/CAN-bus-frame-with-stuff-bit-and-correct-CRC.png

Fig. 17 CAN frame as transferred on the bus. Author: Dr. Ken Tindell#

CAN frame in memory#

  1. Identifier (29-bit)

  2. Control flags (3-bit)

  3. Length (8-bit)

  4. Payload (64-bit)

../../_images/PhD-Thesis_restructure.png

Fig. 18 CAN frame defined by SocketCAN#

Figure from [Gro20].

The Linux SocketCAN implementation of the Controller Area Network (CAN) frame (struct can_frame) is a data structure defined in the linux/can.h header file. This structure is used to encapsulate the information that is required for the transmission and receipt of messages on a CAN bus. The structure is composed of several fields that are used to store the relevant information about the message being transmitted on the CAN bus, including:

  • can_id: A 32-bit identifier to uniquely identify the message and also used to indicate the type of the message, such as a standard or extended frame.

  • can_dlc: An 8-bit data length code that indicates the number of bytes of data payload that are present in the message.

  • data: An array of 8 bytes that contains the data payload of the message.

CAN-Controller State Machine#

Each node on the bus maintains two error counters, the Transmit Error Counter (TEC) and the Receive Error Counter (REC) to keep track of the errors at the transmitting and receiving nodes respectively. The TEC is incremented at a faster rate than the REC when a transmitter detects a fault, as the fault is most likely caused by the transmitter. The node starts in Error Active state, and when the TEC or REC exceeds the threshold of 127, the node enters the Error Passive state, and when the TEC exceeds 255, the node enters the Bus Off state. An Error Active node transmits Active Error Flags, an Error Passive node transmits Passive Error Flags and a Bus Off node do not transmit anything on the bus. When an error is detected, the discovering node transmits an Error Flag which destroys the bus traffic and the other nodes take appropriate action, i.e. discarding the current message. The rules for increasing and decreasing the error counters are complex, but the principle is simple: transmit errors give 8 error points, receive errors give 1 error point, and correctly transmitted and/or received messages cause the counter(s) to decrease. Some CAN controllers provide status bits and corresponding interrupts for two states, “Error Warning” and Bus Off, and a few controllers also, provide direct access to the error counters.

Every CAN controller on the bus will detect errors within each message and transmit an Error Flag if an error is found, which destroys bus traffic. An Error Active node will transmit Active Error Flags when it detects errors, an Error Passive node will transmit Passive Error Flags, and a Bus Off node will not transmit anything. The other nodes on the bus will increase their Receive Error Counters for every Active Error Flag transmitted.

../../_images/can-bus-states.png

Fig. 19 CAN bus states on transmission errors. Receive Error Counter (REC), Transmit Error Counter (TEC). In Error Passive mode, a CAN-Controller will not send error frames in case of an error on the bus.#

In the Controller Area Network (CAN) protocol, the error counters are used to track the number of errors that occur during message transmission. The Transmit Error Counter (TEC) and the Receive Error Counter (REC) are used to keep track of the errors at the transmitting and receiving nodes respectively. The rules for incrementing and decrementing these counters are as follows:

  • The TEC is incremented at a faster rate than the REC when a transmitter detects a fault. This is because the fault is most likely caused by the transmitter.

  • The node is considered to be in Error Active state when both TEC and REC are below 127. As soon as one of the counters exceeds this threshold, the node enters the Error Passive state. And if the TEC exceeds 255, the node enters the Bus-Off state.

  • For every successfully transmitted message, the TEC is decremented by 1 and for every successfully received message, the REC is decremented by 1.

  • In case of a transmission error, 8 error points are added to the TEC and for every received error 1 error point is added to the REC.

  • The TEC and REC are used to monitor the error rate on the bus and based on the error rate different states are entered by the node.

CAN Arbitration CDMA/CR#

CAN (Controller Area Network) arbitration is the process of determining which device on the network has priority to transmit data. It is used to avoid collisions and ensure efficient communication between devices. CDMA (Code Division Multiple Access) is a technique used to allow multiple devices to share the same communication channel simultaneously. CR (Collision Resolution) is a method used to resolve conflicts or collisions that occur when two or more devices attempt to transmit data at the same time on the shared CAN bus. This is done by using the CAN identifier as a priority system where devices with a higher priority (lower CAN identifier value) are given priority to transmit their data. CDMA/CR is used to improve the efficiency and reliability of CAN communication by resolving conflicts when they occur.

../../_images/Arbitration-condition-in-CAN-Bus-protocol_W640.jpg

Fig. 20 Example of CAN arbitration. Author: Omid Avatefipour.#

[Gro20]

The Tcpdump Group. Linktype_can_socketcan - packet structure. 2020. https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html.

[RobertBGmbH]

Robert Bosch GmbH. Can specification. URL: http://esd.cs.ucr.edu/webres/can20.pdf.