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.
CAN Architecture ExampleFigure 1: CAN Architecture Example
A CAN frame contains the following parts:
Standard CAN frame
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.
CAN bus data transmission flow
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.
Priority Arbitration Example
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:
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:
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:
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.
ここにコメントを追加するには、ご登録いただく必要があります。 ご登録済みの場合は、ログインしてください。 ご登録がまだの場合は、ご登録後にログインしてください。