Skip to main content

CAN [Contoller Area Network]

CAN (Controller Area Network) was developed by the Robert Bosch GmbH in the early eighties and was internationally standardized (ISO 11898) in 1994. CAN was specifically developed for the serial data exchange between electronic control units in automobiles but is also used for the realization of industrial micro controller networks.
CAN FD is a further development of the CAN bus system. It supports higher data rates and up to 64 data bytes.
Application area: Automotive engineering, automation engineering.
The development of CAN began when more and more electronic devices were implemented into modern motor vehicles. Examples of such devices include engine management systems, active suspension, ABS, gear control, lighting control, air conditioning, airbags and central locking. All this means more safety and more comfort for the driver and of course a reduction of fuel consumption and exhaust emissions.
CAN Bad Network
To improve the behavior of the vehicle even further, it was necessary for the different control systems (and their sensors) to exchange information. This was usually done by discrete interconnection of the different systems (i.e. point to point wiring). The requirement for information exchange has then  grown to such an extent that a cable network with a length of up to several miles and many connectors was required. This produced growing problems concerning material cost, production time and reliability.
CAN GoodNetwork
The solution to this problem was the connection of the control systems via a serial bus system. This bus had to fulfill some special requirements due to its  usage in a vehicle. With the use of CAN, point-to-point wiring is replaced by one serial bus connecting all control systems. This is accomplished by adding some CAN-specific hardware to each control unit that provides the “rules” or the protocol for transmitting and receiving information via the bus.
CAN Overview
•CAN or Controller Area Network is an advanced serial bus system that efficiently supports distributed control systems. It was initially developed for the use in motor vehicles by Robert Bosch GmbH, Germany, in the late 1980s, also holding the CAN license.
•CAN is internationally standardized by the International Standardization Organization (ISO) and the Society of Automotive Engineers (SAE).
•The CAN protocol uses the Data Link Layer and the Physical Layer in the ISO – OSI model. There are also a number of higher level protocols available for CAN.
•CAN is most widely used in the automotive and industrial market segments. Typical applications for CAN are motor vehicles, utility vehicles, and industrial automation. Other applications for CAN are trains, medical equipment, building automation, household appliances, and office automation. Due to the high volume production in the automotive and industrial markets, low cost protocol devices are available.
•There are about 20 million CAN nodes in use worldwide. By the year 2000 the number of nodes is estimated to be 140 million.
•Examples of vehicle bus systems, other than CAN, are A-BUS from Volkswagen, VAN or Vehicle Area Network, from Peugeot and Renault, and J1850 from Chrysler, General Motors and Ford.
•CAN is clearly the leading vehicle bus protocol in Europe.
CAN Basic
•CAN is a multi-master bus with an open, linear structure with one logic bus line and equal nodes. The number of nodes is not limited by the protocol.
•In the CAN protocol, the bus nodes do not have a specific address. Instead, the address information is contained in the identifiers of the transmitted messages, indicating the message content and the priority of the message.
•The number of nodes may be changed dynamically without disturbing the communication of the other nodes.
•Multi-casting and Broadcasting is supported by CAN.
CAN Basic 2
•CAN provides sophisticated error-detection and error handling mechanisms such as CRC check, and high immunity against electromagnetic interference. Erroneous messages are automatically re-transmitted. Temporary errors are recovered. Permanent errors are followed by automatic switch-off of defective nodes. There is guaranteed system-wide data consistency.
•The CAN protocol uses Non-Return-to-Zero or NRZ bit coding. For synchronization purposes, Bit Stuffing is used.
•There is a high data transfer rate of 1000 kilo-bits per second at a maximum bus length of 40 meters or 130 feet when using a twisted wire pair which is the most common bus medium used for CAN. Message length is short with a maximum of 8 data bytes per message and there is a low latency between transmission request and start of transmission.
•The bus access is handled via the advanced serial communications protocol Carrier Sense Multiple Access/Collision Detection with Non-Destructive Arbitration. This means that collision of messages is avoided by bit-wise arbitration without loss of time.
CAN Bus Wired AND Logic
•There are two bus states, called “dominant” and “recessive”.
•The bus logic uses a “Wired-AND” mechanism, that is, “dominant bits” (equivalent to the logic level “Zero”) overwrite the “recessive” bits (equivalent to the logic level “One” ).
•Only if all nodes transmit recessive bits (ones), the Bus is in the recessive state.
•As soon as one node transmits a dominant bit (zero), the bus is in the dominant state
CAN bus access and Arbitration
•The CAN protocol handles bus accesses according to the concept called “Carrier Sense Multiple Access with Arbitration on Message Priority”. This arbitration concept avoids collisions of messages whose transmission was started by more than one node simultaneously and makes sure the most important message is sent first without time loss. In the picture above you see the trace of the transmit pins of three bus nodes called A, B and C, and the resulting bus state according to the wired-AND principle.
•If two or more bus nodes start their transmission at the same time after having found the bus to be idle, collision of the messages is avoided by bitwise arbitration. Each node sends the bits of its message identifier and monitors the bus level.
•At a certain time nodes A and C send a dominant identifier bit. Node B sends a recessive identifier bit but reads back a dominant one. Node B loses bus arbitration and switches to receive mode. Some bits later node C loses arbitration against node A. This means that the message identifier of node A has a lower binary value and therefore a higher priority than the messages of nodes B and C. In this way, the bus node with the highest priority message wins arbitration without losing time by having to repeat the message.
•Nodes B and C automatically try to repeat their transmission once the bus returns to the idle state. Node B loses against node C, so the message of node C is transmitted next, followed by node B’s message.
•It is not permitted for different nodes to send messages with the same identifier as arbitration could fail leading to collisions and errors.
CAN Frame formats
•These are the existing Frame formats which are now discussed in the following slides.
CAN Frame formats Data Frame
•A “Data Frame” is generated by a CAN node when the node wishes to transmit data. The Standard CAN Data Frame is shown above. The frame begins with a dominant Start Of Frame bit for hard synchronization of all nodes.
•The Start of Frame bit is followed by the Arbitration Field consisting of 12 bits: The 11-bit Identifier, which reflects the contents and priority of the message, and the Remote Transmission Request bit. The Remote transmission request bit is used to distinguish a Data Frame (RTR = dominant) from a Remote Frame (RTR = recessive).
•The next field is the Control Field, consisting of 6 bits. The first bit of this field is called the IDE bit (Identifier Extension) and is at dominant state to specify that the frame is a Standard Frame. The following bit is reserved and defined as a dominant bit. The remaining 4 bits of the Control Field are the Data Length Code (DLC) and specify the number of bytes of data contained in the message (0 – 8 bytes).
•The data being sent follows in the Data Field which is of the length defined by the DLC above (0, 8, 16, …., 56 or 64 bits).
•The Cyclic Redundancy Field (CRC field) follows and is used to detect possible transmission errors. The CRC Field consists of a 15 bit CRC sequence, completed by the recessive CRC Delimiter bit.
•The next field is the Acknowledge Field. During the ACK Slot bit the transmitting node sends out a recessive bit. Any node that has received an error free frame acknowledges the correct reception of the frame by sending back a dominant bit (regardless of whether the node is configured to accept that specific message or not). From this it can be seen that CAN belongs to the “in-bit-response” group of protocols. The recessive Acknowledge Delimiter completes the Acknowledge Slot and may not be overwritten by a dominant bit.
•Seven recessive bits (End of Frame) end the Data Frame.
CAN Frame formats Remote Frame
•Generally data transmission is performed on an autonomous basis with the data source node (e.g. a sensor) sending out a Data Frame. It is also possible, however, for a destination node to request the data from the source by sending a Remote Frame.
•There are 2 differences between a Data Frame and a Remote Frame. Firstly the RTR-bit is transmitted as a dominant bit in the Data Frame and secondly in the Remote Frame there is no Data Field. In the very unlikely event of a Data Frame and a Remote Frame with the same identifier being transmitted at the same time, the Data Frame wins arbitration due to the dominant RTR bit following the identifier. In this way, the node that transmitted the Remote Frame receives the desired data immediately.
CAN Frame formats Remote Frame scenario
•If a node wishes to request the data from the source, it sends a Remote Frame with an identifier that matches the identifier of the required Data Frame. The appropriate data source node will then send a Data Frame as a response to this remote request.
CAN Frame formats ERROR Frame
•An Error Frame is generated by any node that detects a bus error. The Error Frame consists of 2 fields, an Error Flag field followed by an Error Delimiter
field. The Error Delimiter consists of 8 recessive bits and allows the bus nodes to restart bus communications cleanly after an error. There are, however, two forms of Error Flag fields. The form of the Error Flag field depends on the “error status” of the node that detects the error.
•If an “error-active” node detects a bus error then the node interrupts transmission of the current message by generating an “active error flag”. The
“active error flag” is composed of six consecutive dominant bits. This bit sequence actively violates the bit stuffing rule. All other stations recognize the
resulting bit stuffing error and in turn generate Error Frames themselves. The Error Flag field therefore consists of between six and twelve consecutive
dominant bits (generated by one or more nodes). The Error Delimiter field completes the Error Frame. After completion of the Error Frame bus activity
returns to normal and the interrupted node attempts to resend the aborted message.
•If an “error passive” node detects a bus error then the node transmits an “passive Error Flag” followed, again, by the Error Delimiter field. The “passive
Error Flag” consists of six consecutive recessive bits, and therefore the Error Frame (for an “error passive” node) consists of 14 recessive bits (i.e. no
dominant bits). From this it follows that, unless the bus error is detected by the node that is actually transmitting (i.e. is the bus master), the transmission of an Error Frame by an “error passive” node will not affect any other node on the network. If the bus master node generates an “error passive flag” then this may cause other nodes to generate error frames due to the resulting bit stuffing violation.
CAN Frame formats Overload Frame
•An Overload Frame has the same format as an “active” Error Frame. An Overload Frame, however can only be generated during Interframe Space. This is the way then an Overload Frame can be differentiated from an Error Frame (an Error Frame is sent during the transmission of a message). The Overload Frame consists of 2 fields, an Overload Flag followed by an Overload Delimiter. The Overload Flag consists of six dominant bits followed by Overload Flags generated by other nodes (as for “active error flag”, again giving a maximum of twelve dominant bits). The Overload Delimiter consists of eight recessive bits. An Overload Frame can be generated by a node if due to internal conditions the node is not yet able to start reception of the next message. A node may generate a maximum of 2 sequential Overload Frames to delay the start of the next message.
CAN Frame formats Inter Frame Space
•Interframe Space separates a preceding frame (of whatever type) from a following Data or Remote Frame. Interframe space is composed of at least 3 recessive bits, these bits are termed the Intermission. This time is provided to allow nodes time for internal processing before the start of the next message frame. After the Intermission, for error active CAN nodes the bus line remains in the recessive state (Bus Idle) until the next transmission starts.
•The Interframe Space has a slightly different format for error passive CAN nodes which were the transmitter of the previous message. In this case, these nodes have to wait another eight recessive bits called Suspend Transmission before the bus turns into bus idle for them after Intermission and they are allowed to send again. Due to this mechanism error active nodes have the chance to transmit their messages before the error passive nodes are allowed to start a transmission.
CAN ERRORs
•The CAN protocol provides sophisticated error detection mechanisms.
CAN ERRORs CRC
•With the Cyclic Redundancy Check, the transmitter calculates a check sum for the bit sequence from the start of frame bit until the end of the Data Field.
•This CRC sequence is transmitted in the CRC Field of the CAN frame.
•The receiving node also calculates the CRC sequence using the same formula and performs a comparison to the received sequence.
CAN ERRORs CRC 2
•If node B detects a mismatch between the calculated and the received CRC sequence , then a CRC error has occurred.
•Node B discards the message and transmits an Error Frame to request re-transmission of the garbled frame.
CAN ERRORs ACK
•With the Acknowledge Check the transmitter checks in the Acknowledge Field of a message to determine if the Acknowledge Slot, which is sent out as a recessive bit, contains a dominant bit.
•If this is the case, at least one other node, (here node B) has received the frame correctly.
•If not, an Acknowledge Error has occurred and the message has to be repeated. No Error Frame is generated, though.

Comments

Post a Comment