CAN - Overview

API Documentation

feral.can

Introduction

Controller Area Network (CAN) is a robust and widely used communication protocol in automotive and industrial applications. Bosch originally developed it in the 1980s to address the need for a reliable and efficient method of communication between Electronic Control Units (ECU) in vehicles.

Key Aspects of CAN

• Network Topology: CAN typically employs a bus topology, where multiple nodes (ECUs) are connected to a single communication line (the bus). This allows for easy integration of various components within a system.
• Message-Based Communication: Communication on a CAN bus is message-oriented. Each message consists of an identifier representing the message’s priority, content, and data payload. Messages are broadcast to all nodes on the bus, but only the intended recipient processes them based on the identifier.
• Deterministic Communication: CAN provides deterministic communication, meaning that messages are transmitted in a predictable and timely manner. This is crucial for real-time applications where timing accuracy is essential.
• Error Detection and Handling: CAN incorporates robust error detection and handling mechanisms. It uses a bitwise arbitration scheme where messages with lower identifiers have higher priority. Additionally, it employs techniques like cyclic redundancy check (CRC) to ensure data integrity and frame checks to detect errors during transmission.
• High Reliability and Noise Immunity: CAN is designed to operate reliably in harsh environments commonly found in automotive and industrial settings. It offers excellent noise immunity, allowing it to function effectively even in electrically noisy environments.
• Flexible Data Rates: CAN supports different data rates, allowing for adaptation to various system requirements. The original CAN specification (CAN 2.0) supports data rates up to 1 Mbps, while newer versions such as CAN FD (Flexible Data rate) offer higher speeds for increased throughput.
• Standardization: CAN has become an international standard, with specifications maintained by organizations like the International Organization for Standardization (ISO) and the Society of Automotive Engineers (SAE). This standardization ensures interoperability and compatibility among different implementations.

CAN has become a cornerstone technology in modern vehicles and industrial automation systems, enabling efficient communication between various components and developing sophisticated control systems.

The next section explores the architecture of CAN in more detail.

CAN Network Architecture

Figure 1: CAN Network Topology Illustrating Node Connectivity

As depicted in Figure 1, A CAN network is made up of several CAN nodes connected by a CAN bus, which is a physical transmission medium. Typically, CAN networks are built using a line topology with a linear bus to which several electronic control units are attached using CAN interfaces. An unshielded twisted two-wire line is the physical transmission medium used most frequently in applications. Following elements are part of a CAN system:

• Nodes: Nodes are the individual devices or electronic control units (ECUs) connected to the CAN bus. Each node can both transmit and receive messages on the bus. In automotive applications, nodes can include components such as engine control units, airbag systems, anti-lock braking systems, instrument clusters, and more. Industrial applications may have nodes such as sensors, actuators, programmable logic controllers (PLCs), and human-machine interfaces (HMIs).
• CAN Bus: The CAN bus is the physical medium through which communication occurs within the network. It consists of two signal lines: CAN High (CAN_H) and CAN Low (CAN_L). These lines carry the differential signals used for communication between nodes. The bus topology enables multiple nodes to share the same communication medium, facilitating efficient data exchange.
• Controller: The CAN controller is the core component responsible for managing communication on the CAN bus. It handles tasks such as message transmission, reception, error detection, and arbitration. The controller implements the CAN protocol specifications defined by standards like ISO 11898, governing how messages are formatted, transmitted, and received on the bus.
• Transceiver: The CAN transceiver serves as the interface between the CAN controller and the physical bus. It connects the CAN controller to the physical transmission medium and converts the digital signals generated by the controller into differential signals suitable for transmission on the bus and vice versa. The transceiver also provides features like bus protection, signal conditioning, and fault detection. It ensures reliable communication while protecting the bus and connected nodes from electrical faults and transient events.

These components work together to enable robust and reliable communication within a CAN network. Nodes communicate by sending messages onto the bus, which are then received by other nodes that need to process the information. The CAN controller manages the transmission and reception of messages, while the transceiver handles the physical interface with the bus, ensuring proper signal transmission and reception. This collaborative effort among nodes, the bus, controller, and transceiver form the backbone of the CAN system, facilitating efficient data exchange in various automotive and industrial applications.

The following section will detail the process of CAN bus level and logic, communication principle and data transmission in a CAN network.

CAN Bus Levels

In a CAN network, physical signal transmission is accomplished using differential signal transmission. The specific differential voltages vary depending on the communication interface utilized. This document distinguishes between the high-speed CAN bus interface (ISO 11898-2) and the low-speed bus interface (ISO 11898-3).

Figure 2: High speed CAN Bus levels

Figure 3: Low speed CAN Bus levels

According to ISO 11898-2, a typical differential voltage of 0 Volt is assigned logical 1. The differential voltage given to the logical 0 is typically 2 volts. A differential voltage of greater than 0.9 volts is interpreted by high-speed CAN transceivers as a dominating level within the common mode working range, which is normally between 12 and -12 volts.

However, the differential voltage is regarded as recessive below 0.5 Volt. The resistance to interference voltages is increased via a hysteresis circuit. According to ISO 11898-3, logical "1" is associated with a typical differential voltage of 5 volts, while logical "0" is associated with a typical differential voltage of 2 volts.

The various voltage relationships on the CAN bus are shown in the Figure 2 and 3.

CAN Bus Logic

Differentiating between dominant and recessive bus levels is a fundamental requirement for efficient communication in a CAN network, particularly for bus access, fault signaling, and acknowledgement. Logical "0" is the corresponding bus level that is dominant. Logical "1" is equivalent to the recessive bus level.

The recessive bus level is overwritten by the dominant bus level. The CAN bus assumes the dominant bus level when distinct CAN nodes send the dominant and recessive bus levels at the same time. The recessive bus level only occurs if all CAN nodes send recessive levels.

Following figure depicts the Wired-AND Bus Logic underlying a CAN network. It represents which bus level the CAN bus may assume for a CAN network consisting of three CAN nodes. The bus level is accepted by the Rx branches of the CAN nodes (E1, E2, E3).

Figure 4: CAN Bus logic

CAN Bus Communication Principle

The availability of a communication system is severely strained in safety-critical applications, as those in the powertrain sector. As a result, giving one bus node sole control over bus distribution would be unfavorable. All communication would stop if this weak bus node failed. Decentralizing bus access, so every bus node has the authority to access the bus, is a far more elegant method. Because of this, a CAN network is built using a mix of line topology and multi-master design. In essence, every CAN node in a CAN network is permitted to send CAN message across the bus. Instead of being timed according to a set schedule, CAN message transmission is event-driven. The communication channel is only busy when new information must be delivered, allowing for very rapid bus access. On theory, real-time data transmissions on the magnitude of milliseconds are no problem on a CAN network, because of the capacity to immediately react to asynchronous events and high data rates.

In a CAN network, receiver-selective addressing is used to maximize design flexibility by preventing dependencies between bus nodes: Every CAN node has access to every CAN message (broadcasting). A requirement is that node-specific filtering and message identifiers (IDs) must be able to identify every CAN message. This adds overhead, but it makes it possible to integrate more CAN nodes without having to change the CAN network.

CAN Bus Data Transmission

Data transmission in a CAN network involves several steps to ensure reliable communication between nodes. The steps involved in the data transmission process in CAN are as follows:

1. Message Creation: The data transmission process begins when a node (sender) creates a message to be transmitted onto the CAN bus. This message typically contains information about the data to be communicated, along with an identifier that determines its priority.
2. Arbitration: Before transmitting the message, the sending node performs arbitration to determine when it can access the bus. In CAN, messages with lower identifier values have higher priority. The sending node monitors the bus to ensure it is not currently being used by other nodes. Once the bus is idle, the sending node starts transmitting its message.
3. Message Framing: The message is formatted into a frame consisting of several fields, including the start-of-frame (SOF) bit, identifier, control bits, data length code (DLC), data payload, cyclic redundancy check (CRC), acknowledgment (ACK), and end-of-frame (EOF) bit. These fields provide the necessary information for proper transmission and error detection.
4. Transmission onto the Bus: The sending node transmits the message onto the CAN bus by asserting the appropriate voltage levels on the CAN High (CAN_H) and CAN Low (CAN_L) lines. The differential signaling method used by CAN ensures robust communication, even in noisy environments.
5. Message Reception: All nodes on the bus receive the transmitted message, but only the node with a matching identifier processes it. Nodes compare the received identifier with their identifiers to determine if the message is relevant to them.
6. Error Detection and Acknowledgment: As the message is received, each node performs a cyclic redundancy check (CRC) to verify the integrity of the received data. If no errors are detected, the receiving node sends an acknowledgement (ACK) bit back to the sender, confirming successful reception.
7. Message Handling: Upon successful reception, the receiving node processes the message according to its content and the requirements of the application. This may involve updating internal variables, triggering specific actions, or forwarding the message to other nodes.
8. Message Overload: In the event of message overload, where multiple nodes attempt to transmit messages simultaneously, CAN's built-in arbitration mechanism ensures that the highest priority message is transmitted first, maintaining order, and minimizing communication delays.

Following section will explain the frames generated during step 3 of the data transmission process. These frames are transmitted across the network and incorporate multiple bits to facilitate efficient and error-free data transmission.

CAN Frames

CAN frames are structured data packets used for communication within a CAN Bus network. They consist of several fields, each serving a specific purpose to ensure efficient and reliable data transmission. Here's a detailed explanation of CAN frames, including the CAN Standard, CAN FD (Flexible Data Rate), and CAN XL (Extended Data Field Length).

Standard CAN Frame Format

The original CAN protocol, standardized in ISO 11898-1, specifies the basic format and functionality of CAN frames. It supports data rates up to 1 Mbps and payloads of up to 8 bytes. The following is a bit-by-bit explanation of the CAN frame.

• Start-of-Frame (SOF) Bit: This bit has size of 1 bit indicates the beginning of a CAN frame transmission. It synchronizes the receiving nodes with the start of the frame.
• Identifier: The identifier field determines the priority and content of the message. In Standard CAN, it's typically 11 bits long but can be extended in CAN FD and CAN XL formats.
• Control Bits: These bits include various control flags and signals. For instance, the Remote Transmission Request (RTR) bit distinguishes between data and remote frames.
• Data Length Code (DLC): The DLC field specifies the length of the data payload in bytes, ranging from 0 to 8 in Standard CAN frames.
• Data Payload: This is where the actual data to be transmitted is located. The length of the payload varies based on the DLC field.
• Cyclic Redundancy Check (CRC): CRC is a checksum calculated over the frame's data and CRC fields. It helps detect errors during transmission and ensures data integrity.
• Acknowledgment (ACK): This bit is sent by the receiving node to acknowledge the successful reception of the frame. Its absence may trigger retransmission by the sender.
• End-of-Frame (EOF) Bit: Marks the end of the frame transmission. It's essential for synchronizing the receiving nodes and preparing them for the next frame.

Figure 5: Layout of a data frame in CAN standard format

CAN FD Frame Format

CAN FD, defined in ISO 11898-1:2015, enhances the CAN protocol to support higher data rates and larger payloads. It introduces additional bits like BRS and EDL to enable flexible data rates and longer data payloads, improving communication efficiency.

• Extended Data Length (EDL): Indicates the presence of additional bits in the Identifier field, allowing for longer identifiers (up to 29 bits).
• Bit Rate Switch (BRS): This enables a higher data rate for the data payload compared to the arbitration phase.
• Flexible Data Rate (FDR): Indicates whether the CAN FD format is used for data transmission.
• CAN FD frames can have payloads up to 64 bytes in length, providing greater flexibility and efficiency in data exchange.

Figure 6: Layout of a data frame in CAN FD format

CAN XL Frame Format

CAN XL, defined in CAN-XL Standard Series, further increases the payload length and supports even higher data rates. It introduces features like Enhanced Data Length (EDL) and increased payload length (up to 2048 bytes), offering greater flexibility and scalability for demanding applications.

• Extended Data Link Layer (XL): Enhances the standard frame format to accommodate payloads beyond the limitations of CAN FD.
• Enhanced Data Length (EDL): Allows for even longer identifiers, up to 64 bits in length.
• Payload Length (PL): Specifies the length of the data payload, which can range from 1 to 2048 bytes.
• Increased Data Rates: CAN XL supports higher data rates compared to CAN FD, further improving communication efficiency in high-speed networks.

Figure 7: Layout of a data frame in CAN XL format

Usage : Setting Up A CAN Simulation in FERAL

This section explains how to set up a simple CAN Bus simulation scenario in FERAL using Python and Java. Following is a simulation set up in FERAL that simulates a CAN Bus network with two CAN nodes connected to the network where one node acts as a sender and the other node acts as a receiver:

Example

PythonJava

import feral
from feral import seconds
from feral.presets.network.can import two_nodes_can
from feral.presets.producer.value_producer import ValueProducer
from feral.presets.sink.sink import Sink

producer = ValueProducer("producer", interval=seconds(1))
sink = Sink(name="Sink")

can = feral.create_can(config=two_nodes_can.config)

feral.link(producer, "output", can, "node0_tx")
feral.link(can, "node1_rx", sink, "input")

feral.start(seconds(10))

public class TwoNodesCANScenario {

    // Create scenario
    Scenario scenario = new SimulationScenario();
    DiscreteEventDirector root = new DiscreteEventMOCC(scenario);

    // Applications are event triggered
    // - Create a CAN sender
    Sender sender = new Sender(root);
    // - Create a CAN receiver
    Receiver receiver = new Receiver(root);

    // Create a Network with 2 nodes
    DefaultCANNetwork network = new DefaultCANNetwork(root, 2);
    // - Setup network parameter
    network.setBitRate(100000);
    network.setBitStuffingMode(CANNetworkParameters.BitStuffingMode.NONE);

    // - Setup communication interfaces, workers communicate via message type "63", here the payload size is two bytes
    network.getTopology().getApplicationInterface(0).addTxMessageType("63", "app1", 2);
    network.getTopology().getApplicationInterface(1).addRxMessageType("63", "app1", 2);
    // - Setup links from/to network
    new Link(sender.getTxPort(), network.getTopology().getApplicationInterface(0).getInputPort("app1"));
    new Link(network.getTopology().getApplicationInterface(1).getOutputPort("app1"), receiver.getRxPort());

    scenario.startSimulation(SimulationDuration.s(5));
}

The simulation setup begins by creating a Simulation Scenario and a root director for that scenario. For event-based simulation, a Discrete Event Director is instantiated. Two applications, a sender and a receiver, are then created, and the root director is assigned to them.

Next, a CAN network with two interfaces is established using the DefaultCANNetwork class. Network parameters such as bit rate, bit stuffing mode, and transmission logging are configured. The application interfaces of the network are set up according to the expected message types for transmission and reception.

To enable message transmission, the addTxMessageType method is invoked, while addRxMessageType is called for message reception on an interface.

Finally, the FERAL applications (Sender and Receiver) are connected to the network interface using Links. The sender's output port is linked to the input port of Application Interface 0, and the receiver's input port is linked to the output port of Application Interface 1.

In this setup, data sent by the sender to Network's application interface 0 is transmitted through the CAN network at the specified bit rate and is received by the receiver after a delay, influenced by factors such as data size and network bit rate. This demonstrates how FERAL simulates actual data transmission using CAN.