Edited by John R. Gyorki
Keith Pazul
Microchip Technology Inc.
Chandler, Ariz.
As automobiles, industrial machinery, semiconductor-manufacturing equipment, medical equipment, appliances, and numerous other products become more complex, they will need more intelligence, increased safety and fault-tolerance, and higher reliability at reduced cost. One way to help achieve these goals is to network their subsystems together to share critical information. Controller Area Network or CAN as it is commonly called, is rapidly emerging as the preferred choice for a serial communications protocol for many of these applications.
The reasons for CAN acceptance are numerous, but three stand out. First, it’s a Carrier Sense Multiple Access protocol with built-in Collision Detection (CSMA/CD). This method allows all devices on the network to have an equal chance to gain control of the bus to send messages. When two messages try to transmit simultaneously, they will collide but the collisions will be resolved without messages being lost. The higher priority message will continue while the lower priority message retransmits at a later time. Secondly, messages are not sent to other nodes on the network through addresses like many other protocols. This enables different message broadcast types and message configurations to be handled without changing the message format. Thirdly, CAN is a fast, robust protocol with complex error detection and recovery capability.
What is CSMA/CD anyway?
CSMA means that every node on the network must monitor the bus for a period of inactivity before trying to send a message (Carrier Sense). Also, during inactivity every node has an equal opportunity to transmit a message (Multiple Access). When two nodes start transmitting at the same time, they detect the collision (Collision Detection). The message with higher priority will continue while the other halts.
CAN protocol uses a nondestructive bitwise arbitration method. This means that messages remain intact after arbitration completes even when collisions are detected. All arbitration takes place without corruption or delaying the higher priority message.
Two factors are required to support nondestructive bitwise arbitration. First, logic states need to be defined as dominant or recessive. Secondly, the transmitting node must monitor the bus to see if the logic state it is trying to send actually appears on the bus. CAN defines a logic bit 0 as a dominant bit and logic bit 1 as a recessive bit.
A dominant bit state always wins arbitration over a recessive bit state. Therefore, the lower the value in the message identifier (the field used in the message arbitration process), the higher the priority of the message. For example, consider two nodes trying to transmit a message simultaneously. Each node will monitor the bus to make sure the bit that it is trying to send actually appears on the bus. The lower priority message will try to send a recessive bit and the monitored state on the bus will be dominant. At this point, the node sending a recessive bit loses arbitration and immediately stops transmitting. The higher-priority message will continue until completion, and the node that lost arbitration will wait for the next period of bus inactivity and try to transmit its message again.
Message-based protocol
CAN is a message-based protocol. Messages are not transmitted from one node to another based on addresses, instead the priority and the contents of the transmitted data are embedded in the CAN message itself. All nodes in the system receive every message transmitted on the bus and acknowledge when a message is properly received. Each node in the system is set to decide whether a message received should be immediately discarded or kept for processing. A single message may be destined for receipt by one particular node, or by many nodes based on the network and system design.
For example, an automotive airbag sensor is typically connected through CAN to a safety system router because of this information’s high priority in the system definition. The router connects to the rest of the safety system nodes through a daisy chain. The router node receives airbag information and routes it to all the other daisy-chained nodes on the safety system network. The network nodes receive the latest airbag sensor information from the router at the same time, acknowledge if the message was received properly, and decide whether to use or discard this information.
Another useful feature built into the CAN protocol is the ability for a node to specifically request data to be sent to it, rather than waiting for information to be sent by a particular node. This is called Remote Transmit Request (RTR).
For example, a safety system in a car receives frequent updates from critical sensors such as those monitoring airbags, but it may not receive frequent updates from other sensors such as those indicating oil pressure or low battery condition. Periodically, the safety system can request data from the other sensors and perform a thorough safety system check. The system designer can use this feature to minimize network traffic while maintaining integrity.
One additional benefit of this message-based protocol is that new nodes can be added to the system without reprogramming all other nodes to recognize the addition. The new node will start receiving messages from the network, and based on the message ID, decide whether to process or discard the received information.
Furthermore, CAN protocol defines four different kinds of messages or frames for communication on the bus. The first and most common type of frame is a Data Frame. Data Frames are used when a node transmits information to any or all other nodes in the system. The second is a Remote Frame, which is basically a Data Frame with an RTR bit set to signify that it’s a Remote Transmit Request. A remote frame is used by a node to request information to be sent to it by another node or nodes.
The other two frame types are for handling errors. One is called an Error Frame, and the other is an Overload Frame. Error Frames are generated by nodes that detect any one of the protocol errors defined by CAN. Overload errors are generated by nodes that require more time to process messages already received.
Fast and robust
Because CAN was initially intended for automobiles, the protocol had to efficiently handle errors if it was to gain wide market acceptance. With the release of Version 2.0B of the CAN specification, the maximum communication rate was increased eight times over Version 1.0 to 1 Mbit/sec. At this rate, even the most time-critical parameters can be transmitted serially without concern for latency. In addition, the CAN protocol has a comprehensive list of errors it can detect to ensure message integrity.
The CAN protocol contains numerous built-in functions to determine different fault conditions on the bus and act on them accordingly. For example, transmission errors are detected by a Cyclic Redundancy Check (CRC) algorithm, while message reception is monitored by an Acknowledgement Error function, CAN message format is monitored by a Form Errors function, CAN bus signals are monitored by a Bit Error function, and synchronization and timing are monitored by a Stuff Error function. Each CAN node keeps track of errors in counters. These error counters determine when a CAN node needs to transition to a degraded mode based on the severity of problems being encountered.
CAN nodes can transition from functioning normally (being able to transmit and receive messages and error frames) to a passive mode in which a node can only control the bus if not already being used, to shutting down completely (bus off) based on the severity and quantity of the errors detected. CAN nodes also can differentiate short disturbances from permanent failures and modify their functionality accordingly. This feature is called Fault Confinement. No faulty CAN nodes can monopolize all the bandwidth on the network because faults are confined to the faulty nodes and these nodes shut off before bringing the network down. This is an extremely powerful function because Fault Confinement guarantees bandwidth availability for critical system information.