Today’s vehicles can contain more than 70 devices, commonly called Electronic Control Units (ECUs) or nodes, that control electrical subsystems. These subsystems control the engine, transmission, power-train and antilock braking/ABS along with many more. Communication between these subsystems is critical to ensure the reliability and safety demanded in the automotive market. The Controller Area Network (CAN bus) is a message-based communication network standard that allows ECUs to communicate within a vehicle without the use of dedicated analog signal wires. By utilizing multiplex wiring, CAN significantly reduces cost, complexity and weight of a design and allows new features to be implemented in firmware, allowing for over-the-air firmware updates and saving further on engineering design time.
NXP's Irina Costachescu introduces the Controller Area Network (CAN) standard:
HISTORY
Before the development of CAN, vehicle ECUs were connected via complex, point-to-point wiring. Bosch officially released the first CAN protocol in 1986, and Philips (now NXP) was one of the first semiconductor manufacturers to release CAN controller MCUs shortly thereafter. In 1993, the International Organization for Standardization (ISO) standardized CAN as ISO11898, which has since been divided into two standards: ISO11898-1 describes the data link layer of the protocol, and ISO11898-2 describes the physical layer for high-speed CAN (baud rate up to 1Mbps). A third part of the standard, ISO 11898-3 was released later and covers the CAN physical layer for low-speed CAN (baud rate up to 125 kbit/s), also known as fault-tolerant CAN. In 2012, Bosch released CAN FD 1.0 (CAN with Flexible Data-Rate) with evolving standards for higher data rates. NXP has devices that support both low-speed and high-speed CAN as well as CAN FD today.
ARCHITECTURE
All nodes in a CAN network are connected to one another through a conventional two-wire bus. Every node requires a microcontroller, a CAN controller (often integrated into the MCU) and a CAN transceiver. Any sensors, actuators or other control devices are connected into the CAN network through the host processor or MCU for a given node. Nodes can communicate with devices from very simple digital logic up to an embedded computer or even a gateway that allows a general-purpose computer like a laptop to connect with devices on the CAN network via a USB or Ethernet port. A CAN transceiver processes single-ended transmit and receive signals (TXD and RXD) from the CAN controller and converts them to/from differential signals (known as CAN high (CANH) and CAN low (CANL) on the bus.
A CAN frame contains the following parts:
- Start of Frame (SOF) bit – Sends a dominant ‘0’ to tell other ECUs that a message is coming
- Arbitration ID – Identifies the message as well as the priority. A standard CAN (CAN 2.0A) frame has an 11-bit ID while an extended CAN (CAN 2.0B) frame has a 29-bit ID.
- Remote Transmission Request (RTR) bit – Allows the ECU to request messages from other ECUs by sending a recessive ‘1’ bit. RTR is a dominant ‘0’ bit in the case of a data file.
- IDE – Indicates whether this is a base format frame (11-bit identifier) or extended format frame (29-bit identifier).
- r0 – Reserved bit, more recently known as Flexible Data Format (FDF) bit. Indicates whether the frame is Classic CAN or CAN FD.
- Data Length Code (DLC) – Contains the length of the data in bytes (0-8 bytes)
- Data – Contains the actual data values; length is dictated by DLC field.
- Cyclic Redundancy Check (CRC) – Error-detecting code that checks the data integrity.
- CRC delimiter bit – Must be a recessive ‘1’.
- Acknowledgement slot (ACK): Confirms that the CRC process is OK.
- ACK delimiter bit – Must be a recessive ‘1’.
- End of Frame (EOF): 7 bits; end of frame is indicated with a recessive ‘1.’
Figure 2: Standard CAN frame
OPERATION
Data Transmission
The CAN protocol is message-based, meaning all nodes on the bus are capable of both transmitting and receiving messages, and they are always listening for a message to be broadcast. While all nodes are capable of transmitting messages, there can only be one message transmitting across the bus at any given time. Most commonly, the CAN controller affiliated with each node implements a filter that checks the arbitration ID of a broadcast message and either accepts messages when the arbitration ID is within a particular range, or ignores messages outside of that range.
For example, let’s say we have three nodes on the CAN bus. Node 1 transmits a message with the current speed of the vehicle. It tags the message with the ID 0x121. Node 2 accepts data with an arbitration ID in the range of 0x100-0x1FF. The ID of the message is within this range, so Node 2 accepts the message. Node 3 accepts data with an arbitration ID in the range of 0x320-0x352. The ID of the message is outside of this range, so Node 3 ignores the data.
Figure 3: CAN bus data transmission flow
Priority Arbitration
The CAN protocol uses what is called lossless bitwise arbitration to determine message priority. Let’s break this down. While every node is capable of transmitting and receiving messages, only one message can occupy the bus at a given time. Bus access is event-driven, and it is possible for several nodes to begin a transmission at the same time. In this case, the message with the higher priority “wins” access to the bus first. Message priority is determined by looking at the arbitration ID bit by bit (aka bitwise) – the lower the binary identifier, the higher the priority (so a logic ‘1’ bit is recessive to a dominant ‘0’ bit). The node winning arbitration continues on with its message transmission, without the message being delayed, destroyed or corrupted by another node. This is called lossless arbitration. The node transmitting a lower priority message will halt transmission while the higher priority message transmits. Once the bus is released, this node will make another attempt to transmit its message.
To look at an example, let’s consider two devices trying to transmit simultaneously on the CAN bus, as shown in Figure 4 below. Device A has an arbitration ID of 11001000111. Device B has an arbitration ID of 11011111111. Device A would win access to the bus because it has a lower arbitration ID (the 4th bit being ‘0’). Device A proceeds with message transmission, and Device B waits to try again when the bus is free.
Figure 4: Priority Arbitration Example
In addition to identifying the message in a transmission, the arbitration ID also determines message priority. A lower ID value gets higher priority. If multiple nodes try to transmit a message onto the CAN bus at the same time, the message with highest priority (lowest arbitration ID value) gets bus access. Lower-priority nodes must wait until the bus becomes available before they can attempt to transmit again.
Frame Types
A message transmitted on the CAN network is also known as a frame. There are four types of CAN frames:
- Data frame – This is the most common type of frame, and the only one that contains actual data. Data frames consist of the arbitration ID, the data field, the Cyclic Redundancy Check (CRC) field which is used for error detection, and the Acknowledgement (ACK) field.
- Remote frame – A remote frame allows a node to request specific data from another node. There are two main differences between a Remote frame and a Data frame. First, a recessive RTR bit within the arbitration field explicitly marks a Remote frame as such. Second, a Remote frame does not have data inside message.
- Error frame – If a node detects a fault, it transmits an error frame to all other nodes on the network. Nodes receiving this message will in turn transmit an error frame as well. At this point, hardware error counters implemented within the CAN transceivers prohibit recycling of these error messages to avoid bus flooding.
- Overload frame – This type of frame injects a delay between the data or remote frame, basically requesting that the message be re-transmitted later. This type of frame has largely been deemed obsolete as controllers have become smart enough to no longer require this type of message, thus saving traffic on the bus.
ERROR DETECTION
Reliability is imperative in systems such as automotive where failure is not an option. The robustness of the CAN bus within this space is in no small part attributed to its abundance of error detection procedures. The CAN protocol incorporates five methods of error checking; three at the message level and two at the bit level. If a message fails at any one of these, the message is not accepted and an error frame is generated from the receiving node. Also at the message level, the CRC and ACK fields contain a checksum and delimiter bits to enforce error checking. And third, there is a form check at the message level, which looks for fields within the message which must always be recessive bits. These include the SOF, EOF, ACK delimiter, and CRC delimiter bits. If a dominant bit is detected in any of these, an error is generated.
At the bit level, transmitters monitor their own messages bit by bit. If a data bit is written onto the bus and its opposite is read, an error is generated. Lastly, the CAN protocol utilizes a bit-stuffing rule for error detection. After five consecutive bits of the same logic level a bit of the complementary level is inserted. This ensures that rising edges are available to keep the network synchronized. Stuffed frames are destuffed by receiving nodes. Bit stuffing occurs in all fields within a frame besides the CRC delimited, ACK field and EOF. For all fields where bit stuffing is used, six consecutive bits of the same polarity are considered an error as it violates the bit stuffing rule.
BENEFITS
To summarize the points above, the CAN bus offers a number of advantages for automotive and industrial use cases:
- Low Cost – Because each ECU in a vehicle is able to communicate with the rest of the network via a single CAN interface rather than multiple direct signal lines, the cost and architectural complexity are significantly decreased.
- Broadcast Messaging – Each node on the network can send and receive transmitted messages and can determine if a message is relevant or should be ignored. This structure allows modifications to the network with minimal impact.
- Priority – Lossless bit arbitration allows the CAN protocol to determine message priority in a way that avoids delays or message corruption caused by collisions.
- Error Detection – The CAN specification contains built-in error handling with each node checking for transmission errors (see Error Frame description above). This is especially advantageous in markets where reliability is paramount.
- Robust – CAN’s high-speed bus lines are highly resistant to electrical disturbances, and some CAN controllers and receivers are available with industrial/extended temperature ranges or even come in fault-resistant varieties for the most demanding environments.
- Flexible – Because CAN is a message-based protocol, nodes on the bus have no identifying information associated with them. This means nodes can be added or removed from the system without requiring any software or hardware updates to be made.
APPLICATIONS
Thanks to the efficiency, flexibility and robustness that CAN offers, as well as its economic benefits, it has become the most widely used in-vehicle network for ECU and sensor communication. These same benefits make CAN an increasingly popular choice in a number of additional markets today as well including:
- Agricultural equipment
- Aviation
- Railways
- Building automation equipment
- Industrial automation and manufacturing
- Lighting systems
- Medical devices and instrumentation
- Pedal electric cycle (Pedelecs)
- Gaming machines
NXP's CAN solutions
As the world’s largest provider of automotive semiconductors, NXP provides multiple CAN solutions including MCUs and processors with integrated CAN controllers, CAN transceivers, System Basis Chips and development tools and software that support all of these. To get started using CAN in your application, take a look at the examples included within our Model-Based Design Toolbox (MBDT), or within the MCUXpresso IDE or the S32 Design Studio IDE.