CONTROLLER AREA NETWORK - HOW CAN WORKS _________________________________________________________________ Headings and sub-topics in this document How CAN Works, - Principle, - Identifiers, - An Example, - Robustness, - Network Flexibility and Expansion How Arbitration Works on the CAN bus, - Non-Destructive Bitwise Arbitration, - The Benefits CAN Message Formats, - Message Frames, - 2.0A Format, - 2.0B Format, - 2.0A and 2.0B Compatibility How CAN works Principle Data messages transmitted from any node on a CAN bus do not contain addresses of either the transmitting node, or of any intended receiving node. Instead, the content of the message (e.g. Revolutions Per Minute, Hopper Full, X-ray Dosage, etc.) is labelled by an identifier that is unique throughout the network. All other nodes on the network receive the message and each performs an acceptance test on the identifier to determine if the message, and thus its content, is relevant to that particular node. If the message is relevant, it will be processed; otherwise it is ignored. This mode of operation is known as multi-cast. Identifiers The unique identifier also determines the priority of the message. The lower the numerical value of the identifier, the higher the priority. This allows arbitration if two (or more) nodes compete for access to the bus at the same time. The higher priority message is guaranteed to gain bus access as if it were the only message being transmitted. Lower priority messages are automatically re-transmitted in the next bus cycle, or in a subsequent bus cycle if there are still other, higher priority messages waiting to be sent. Arbitration is explained in more detail later. An Example Using a much simplified system in a car as a general example, Figure 1 below shows a CAN bus with four nodes. Assume that node 2 is connected to a sensor that is monitoring the engine revolutions and, at defined intervals, needs to transmit the RPM information. The controller in node 2 initiates the transmission of a message containing the RPM data. The message and its appropriate identifier are passed to the CAN chip in the node. This is all the controller needs to do; the CAN chip constructs the message according to the CAN protocol and then transmits it. [LINK] Fig 1.Message Transmission on the CAN bus All other nodes on the bus (i.e. 1, 3 and 4) become receivers and perform a check to see if the information is relevant to them. If the message is not relevant to a node it will ignore it (e.g. node 3 if it controls only the air conditioning, for example.) But if the information in the message is of relevance it will be accepted and processed (e.g. node 1 the speedometer, and node 4 the engine management system.) Robustness CAN uses Non Return to Zero (NRZ) encoding with bit-stuffing for data communication on a differential two wire bus. The use of NRZ ensures compact messages with a minimum number of transitions; bit-stuffing (described in more detail in the Errors section) ensures a sufficient number of edges to guarantee synchronisation. The two wire bus is usually a shielded or unshielded twisted pair. Flat pair (telephone type) cable also performs well but generates more noise itself, and is more susceptible to external sources of noise - e.g. EMC. CAN will operate in extremely harsh environments and the extensive error checking mechanisms ensure that any transmission errors are detected. See the the Errors section for complete details. The ISO11898 standard specifies as "Recommended" that bus interface chips be designed so that communication can still continue (but with reduced signal to noise ratio) even if: - Either of the two wires in the bus is broken - Either wire is shorted to power - Either wire is shorted to ground Depending on the design and configuration of the system, if both wires are broken at the same location, some limited functionality may still be achievable in each of the sub-systems created by the breaks. Network Flexibility and Expansion The content-oriented nature of the CAN addressing scheme delivers a high degree of flexibility for system configuration. New nodes that are purely receivers, and which need only existing transmitted data, can be added to the network without the need to make any changes to existing hardware or software. Because the transmission protocol does not use destination addresses, CAN supports, to the full, the concept of modular controllers. It allows multi-master capability, multiple reception, and provides easily for the synchronisation of distributed processes. As demonstrated above, measurements needed by several controllers can be transmitted via the bus, thereby removing the need for each controller to have its own individual sensor. How Arbitration Works on the CAN Bus In any system, some parameters will change more rapidly than others. For example - parameters that change quickly could be the RPM of a car engine, or the current floor level of an elevator (US) - lift (UK). Slower changing parameters may be the temperature of the coolant of a car engine, or the air temperature in the lift (UK) - elevator(US). It is likely that the more rapidly changing parameters need to be transmitted more frequently and, therefore, must be given a higher priority. To cater for real-time data communication, this requires not only a fast data transmission rate, but also a rapid bus allocation mechanism to deal with occasions when more than one node may be trying to transmit at the same time. To determine the priority of messages, CAN uses the established method known as Carrier Sense, Multiple Access with Collision Detect (CSMA/CD) but with the enhanced capability of non-destructive bitwise arbitration to provide collision resolution, and to deliver maximum use of the available capacity of the bus. Non-Destructive Bitwise Arbitration The priority of a CAN message is determined by the binary value of its identifier. The numerical value of each message identifier (and thus the priority of the message) is assigned during the initial phase of system design. The identifier with the lowest numerical value has the highest priority. Any potential bus conflicts are resolved by bitwise arbitration in accordance with the wired-and mechanism, by which a dominant state (logic 0) over writes a recessive state (logic 1). For example, assume that three nodes are trying to transmit at the same time, as shown in Figure 2. [LINK] Fig 2.Non-Destructive Bitwise Arbitration In this example, the competition for the bus is won by node 2 because its dominant bits overwrite in turn recessive bit 7 of node 1, and then recessive bit 3 of node 3. The overall result is the same as if the highest priority message, in this example from node 2, was the only message being transmitted. As soon as any lower priority transmitter loses, it automatically becomes a receiver of the message with the highest priority (as indicated by the change from solid to dotted lines in Figure 2) and will not attempt re-transmission of its own message until the bus becomes available again. The Benefits Non-destructive bitwise arbitration provides bus allocation on the basis of need, and delivers efficiency benefits that can not be gained from either fixed time schedule allocation (e.g. Token ring) or destructive bus allocation (e.g. Ethernet.) In a Token ring system, allocation is made sequentially to each node on the bus, regardless of whether the node needs the bus at the time of allocation. If the node misses its allocated time slot it must wait for it to come round again. This can lead to long and undesirable periods of inactivity on the bus. Ethernet systems are different again. Simultaneous bus access by more than one node in an Ethernet system causes ALL transmissions to be aborted. ALL transmitters then attempt to re-transmit their respective messages. In worst case situations the bus can be inactive for substantial periods of time as nodes continue to fight for access. Response times can become excessive. The bus may even lock up. With only the maximum capacity of the bus as a speed limiting factor, CAN will not collapse or lock up. Outstanding transmission requests are dealt with, in their order of priority, with minimum delay, and with maximum possible utilisation of the available capacity of the bus. CAN Message Format Message Frames In a CAN system, data is transmitted and received using Message Frames. Message Frames carry data from a transmitting node to one, or more, receiving nodes. The CAN protocol supports two Message Frame formats. The two formats are: - Standard CAN (Version 2.0A) - Extended CAN (Version 2.0B) Most 2.0A controllers transmit and receive only Standard format messages, although some (known as 2.0B passive) will receive Extended format messages but then ignore them. 2.0B controllers can send and receive messages in both formats. 2.0A Format A Standard CAN (Version 2.0A) Message Frame consists of seven different bit fields: - A Start of Frame (SOF) field. This is a dominant (logic 0) bit that indicates the beginning of a message frame. The detection of a dominant bit level at any time during Bus Idle is interpreted as Start of Frame - An Arbitration field, containing an 11 bit message identifier and the Remote Transmission Request (RTR) bit. A dominant (logic 0), RTR bit indicates that the message is a Data Frame. A recessive (logic 1) value indicates that the message is a Remote Transmission Request (otherwise known as Remote Frame.) A Remote Frame is a request by one node for data from some other node on the bus. Remote Frames do not contain a Data Field. The Data Length Code specifies the number of bytes of data in the requested Message Frame. [LINK] Fig 3.CAN 2.0A Message Frame - A Control Field containing six bits: * two dominant bits (r0 and r1) that are reserved for future use, and * a four bit Data Length Code (DLC). The DLC indicates the number of bytes in the Data Field that follows - A Data Field, containing from zero to a maximum of eight bytes. As with all bytes in a CAN Message Frame, the most significant bit of the first (leftmost) data byte is transmitted first - The CRC field, containing a fifteen bit cyclic redundancy check code and a recessive delimiter bit - The ACKnowledge field, consisting of two bits. The first is the Slot bit which is transmitted as a recessive bit, but is subsequently over written by dominant bits transmitted from all other nodes that successfully receive the message. The second bit is a recessive delimiter bit - The End of Frame field, consisting of seven recessive bits. Following the end of a frame is the INTermission field consisting of three recessive bits. The intermission period allows all CAN controllers to execute necessary internal processes in preparation for the next receive or transmit task. After the three bit INTermission period the bus is recognised to be free. Bus Idle time maybe of any arbitrary length including zero. 2.0B Format The CAN 2.0B format provides a twenty nine (29) bit identifier as opposed to the 11 bit identifier in 2.0A. Version 2.0B evolved to provide compatibility with other serial communications protocols used in automotive applications in the USA. To cater for this, and still provide compatibility with the 2.0A format, the Message Frame in Version 2.0B has an extended format. The differences are: - In Version 2.0B the Arbitration field contains two identifier bit fields. The first (the base ID) is eleven (11) bits long for compatibility with Version 2.0A. The second field (the ID extension) is eighteen (18) bits long, to give a total length of twenty nine (29) bits. - The distinction between the two formats is made using an Identifier Extension (IDE) bit. This is transmitted as a recessive bit when sending messages in Extended (2.0B) format and as a dominant bit for messages in Standard (2.0A) format. [LINK] Fig 4.CAN 2.0B Message Frame - A Substitute Remote Request (SRR) bit is included in the Arbitration Field. The SRR bit is always transmitted as a recessive bit to ensure that, in the case of arbitration between a Standard Data Frame and an Extended Data Frame, the Standard Data Frame will always have priority if both messages have the same base (11 bit) identifier. Note that, as in Version 2.0A, the Remote Transmission Request (RTR) bit is still dominant for Data Frame transmission and recessive for Remote Frame transmission. All other fields in a 2.0B Message Frame are identical to those in the Standard format. 2.0A and 2.0B Compatibility 2.0B controllers are completely backward compatible with 2.0A controllers and can transmit and receive messages in either format. Note, however, that there are two types of 2.0A controllers: - The first is capable of transmitting and receiving only messages in 2.0A format. With this type of controller, reception of any 2.0B message will flag an error. - The second type of 2.0A controller (known as 2.0B passive) is also capable of sending and receiving 2.0A messages, but in addition, these devices will acknowledge receipt of 2.0B messages and then ignore them. Therefore, within the above mentioned constraints it is possible to use both Version 2.0A (with 2.0B passive capabilities) and 2.0B controllers on a single network. However, because of the lack of full upward compatibility of 2.0A devices with 2.0B devices, only messages in Standard format are meaningful in systems using both types. Nevertheless, because the two formats may have to co-exist on a single bus, messages in Standard format (Version 2.0A) always have priority over an Extended format (Version 2.0B) message when they both have the same base (11 bit) identifier. To ensure compatibility between controllers from different manufacturers, CAN system designers must not use 11 bit identifier fields (in either 2.0A and 2.0B) with the seven most significant bits set to 1 (i.e. 1111111XXXX where X is an arbitrary level.) This means that the number of unique identifiers available to users, on a single 2.0A network, is 2,032 (2 to the power 11 - 2 to the power 4). Leaving aside the use for compatibility purposes with American buses, the number of unique identifiers available on a 2.0B network is in excess of 500 million! _________________________________________________________________ HOMEPAGE Go back to Intro Page and Main Index _________________________________________________________________ If you have any comments or feedback about this site, or items for possible inclusion please send me an E-mail. Thanks. Mike Schofield _________________________________________________________________ Copyright © 1996. M J Schofield. Email: mschofield@cix.compulink.co.uk Tel: +44 (0)1489 896946 Fax/Minicom: +44 (0)1489 893221 _________________________________________________________________