Controller Area Network

Controller Area Network
Seminar 2003
CONTENTS
Sl No 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Topic Page No
Introduction..2 The CAN protocol........2 The CAN messages.....3 Standard and extended CAN.......7 Bus arbitration and message priority...8 Message addressing and identification....9 The CAN bus...9 CAN physical layer...10 CAN application layers.....10 The cable...14 CAN bit timing.....15 CAN error handling......17 CAN implementations......22 CAN applications.....25 Conclusion....29 References31
Dept. of comp. Sc & Engg Thrissur
Govt. Engg. College,
Seminar 2003
INTRODUCTION
The Controller Area Network (the CAN bus) is a serial communications bus for real-time control applications. CAN operates at data rates of up to 1 Megabits per second and has excellent error detection and confinement capabilities. CAN was originally developed by the German company Robert Bosch for use in the car industry to provide a cost-effective communications bus for in-car electronics and as alternative to expensive and cumbersome wiring looms. The car industry continues to use CAN for an increasing number of applications, but because of its proven reliability and robustness, CAN is now also being used in many other industrial control applications. CAN is an international standard and is documented in ISO 11898 (for highspeed applications) and ISO 11519 (for lower-speed applications). Low-cost CAN controllers and interface devices are available as off-the-shelf parts from several of the leading semiconductor manufacturers. Custom built devices and popular microcontrollers with embedded CAN controllers are also available. There are many CAN-related system development packages and available hardware interface cards and easy-to-use software packages that provide system designers, builders and maintainers with a wide range of design, monitoring, analysis, and test tools.
Seminar 2003
THE CAN PROTOCOL
The CAN protocol is defined by the ISO 11898 standard and can be summarized like this:
The physical layer uses differential transmission on a twisted pair wire. A non-destructive bit-wise arbitration is used to control access to the bus. The messages are small (at most eight data bytes) and are protected by a checksum. There is no explicit address in the messages, instead, each message carries a numeric value which controls its priority on the bus, and may also serve as an identification of the contents of the message.
An elaborate error handling scheme that results in retransmitted messages when they are not properly received. There are effective means for isolating faults and removing faulty nodes from the bus.
PRINCIPLES OF DATA EXCHANGE CAN is based on the so-called broadcast communication mechanism. This broadcast communication is achieved by using a message oriented transmission protocol. Thus not defining stations and station addresses, it only defines message. These messages are identified by using a message identifier. Such a message identifier has to be unique within the whole network and it defines not only the content but also the priority of the message. This will be important when several stations compete for bus access. A high degree of system and configuration flexibility is achieved as a result of the content-oriented addressing scheme. It is very easy to add stations to an existing CAN Dept. of comp. Sc & Engg Thrissur 3 Govt. Engg. College,
Seminar 2003
network without making any hardware or software modifications to the existing stations as long as the new stations are purely receivers. This allows the concept of modular electronics and also permits multiple receptions and the synchronization of distributed processes: data needed as information by several stations can be transmitted via the network in such a way that it is unnecessary for each station to have to know who the producer of the data is. This allows easy servicing and upgrading of networks as data transmission is not based on the availability of specific types of stations
THE CAN MESSAGES

The CAN bus is a broadcast type of bus. This means that all nodes can "hear" all transmissions. There is no way to send a message to just a specific node; all nodes will invariably pick up all traffic. The CAN hardware, however, provides local filtering so that each node may react only on the interesting messages. CAN uses short messages - the maximum utility load is 94 bits. There is no explicit address in the messages; instead, the messages can be said to be contentsaddressed, that is, their contents implicitly determines their address. MESSAGE TYPES There are four different message types (or "frames") on a CAN bus: The Data Frame. The Remote Frame. The Error Frame, and The Overload Frame.
The Data Frame The Data Frame is the most common message type. It comprises the following major parts: Dept. of comp. Sc & Engg Thrissur 4 Govt. Engg. College,
Seminar 2003
The Arbitration Field, which determines the priority of the message when two or more nodes are contending for the bus. The Arbitration Field contains: o For CAN 2.0A, an 11-bit Identifier and one bit, the RTR bit, which is dominant for data frames. o For CAN 2.0B, a 29-bit Identifier (which also contains two recessive bits: SRR and IDE) and the RTR bit.
The Data Field, which contains zero to eight bytes of data. The CRC Field, which contains a 15-bit checksum calculated on most parts of the message. This checksum is used for error detection. An Acknowledgement Slot; any CAN controller that has been able to correctly receive the message sends an Acknowledgement bit at the end of each message. The transmitter checks for the presence of the Acknowledge bit and retransmits the message if no acknowledge was detected. Fig 1: A CAN 2.0A ("standard CAN") Data Frame
Fig 2: A CAN 2.0B ("extended CAN") Data Frame
The Remote Frame
Seminar 2003
The Remote Frame is just like the Data Frame, with two important differences: It is explicitly marked as a Remote Frame (the RTR bit in the Arbitration Field is recessive), and There is no Data Field. The intended purpose of the Remote Frame is to solicit the transmission of the corresponding Data Frame. If, say, node A transmits a Remote Frame with the Arbitration Field set to 234, then node B, if properly initialized, might respond with a Data Frame with the Arbitration Field also set to 234. Remote Frames can be used to implement a type of request-response type of bus traffic management. In practice, however, the Remote Frame is little used. It is also worth noting that the CAN standard does not prescribe the behavior outlined here. Most CAN controllers can be programmed either to automatically respond to a Remote Frame, or to notify the local CPU instead.
Fig 3: A Remote Frame (2.0A type) The Error Frame Error Frame is a special message that violates the framing rules of a CAN message. It is transmitted when a node detects a fault and will cause all other nodes to detect a fault - so they will send Error Frames, too. The transmitter will then automatically try to retransmit the message. There is an elaborate scheme of error counters that ensures that a node can't destroy the bus traffic by repeatedly transmitting Error Frames. Dept. of comp. Sc & Engg Thrissur 6 Govt. Engg. College,
Seminar 2003
The Error Frame consists of an Error Flag, which is 6 bits of the same value (thus violating the bit-stuffing rule) and an Error Delimiter, which is 8 recessive bits. The Error Delimiter provides some space in which the other nodes on the bus can send their Error Flags when they detect the first Error Flag.
Fig 4: Error Frame The Overload Frame The Overload Frame is very similar to the Error Frame with regard to the format and it is transmitted by a node that becomes too busy. The Overload Frame is not used very often, as today's CAN controllers are clever enough not to use it. In fact, the only controller that will generate Overload Frames is the now obsolete 82526.
Seminar 2003
STANDARD AND EXTENDED CAN
Originally, the CAN standard defined the length of the Identifier in the Arbitration Field to eleven (11) bits. Later on, customer demand forced an extension of the standard. The new format is often called Extended CAN and allows no less than twenty-nine (29) bits in the Identifier. To differentiate between the two frame types, a reserved bit in the Control Field was used. The standards are formally called
2.0A, with 11-bit Identifiers only. 2.0B, extended version with the full 29-bit Identifiers (or the 11-bit, you can mix them.) A 2.0B node can be
o o
"2.0B active", i.e. it can transmit and receive extended frames, or "2.0B passive", i.e. it will silently discard received extended frames.
1. x refers to the original specification and its revisions.
New CAN controllers today are usually of the 2.0B type. A 1.x or 2.0A type controller will get very upset if it receives a message with 29 arbitration bits. A 2.0B passive type controller will tolerate, acknowledge and then - discard them; a 2.0B active type controller can both transmit and receive them. Controllers implementing 2.0B and 2.0A (and 1.x) are compatible - and may be used on the same bus - as long as the controllers implementing 2.0B refrain from sending extended frames.
Seminar 2003
BUS ARBITRATION AND MESSAGE PRIORITY

The message arbitration (the process in which two or more CAN controllers agree on who is to use the bus) is of great importance for the really available bandwidth for data transmission. Any CAN controller may start a transmission when it has detected an idle bus. This may result in two or more controllers starting a message (almost) at the same time. The conflict is resolved in the following way. The transmitting nodes monitor the bus while they are sending. If a node detects a dominant level when it is sending a recessive level itself, it will immediately quit the arbitration process and become a receiver instead. The arbitration is performed over the whole Arbitration Field and when that field has been sent, exactly one transmitter is left on the bus. This node continues the transmission as if nothing had happened. The other potential transmitters will try to retransmit their messages when the bus becomes available next time. No time is lost in the arbitration process. An important condition for this bit-wise arbitration to succeed is that no two nodes may transmit the same Arbitration Field. There is one exception to this rule: if the message contains no data, then any node may transmit that message. Since the bus is wired-and and a Dominant bit is logically 0, it follows that the message with the numerically lowest Arbitration Field will win the arbitration.
Seminar 2003
MESSAGE ADDRESSING AND IDENTIFICATION
There is no explicit address in the CAN messages. Each CAN controller will pick up all traffic on the bus, and using a combination of hardware filters and software, determine if the message is "interesting" or not. In fact, there is no notion of message addresses in CAN. Instead, the contents of the messages are identified by an identifier which is present somewhere in the message. CAN messages are said to be "contents-addressed". A conventional message address would be used like "Here's a message for node X". A contents-addressed message is like "Here's a message containing data labeled X". The difference between these two concepts is small but significant. The content of the Arbitration Field is, per the Standard, used to determine the message's priority on the bus. All CAN controllers will also use the whole (some will use just a part) of the Arbitration Field as a key in the hardware filtration process. The Standard does not say that the Arbitration Field must be used as a message identifier. It's nevertheless a very common usage.
10
Seminar 2003
THE CAN BUS

The bus uses Non-Return To Zero (NRZ) with bit-stuffing. There are two different signaling states: dominant (logically 0) and recessive (logically 1). These correspond to certain electrical levels which depend on the physical layer used (there are several.) The modules are connected to the bus in a wired-and fashion: if just one node is driving the bus to the dominant state, then the whole bus is in that state regardless of the number of nodes transmitting a recessive state. The maximum speed of a CAN bus, according to the standard, is 1 Mbit/second. Some CAN controllers will nevertheless handle higher speeds than 1Mbit/s and may be considered for special applications.
CAN PHYSICAL LAYER
A physical layer defines the electrical levels and signaling scheme on the bus, the cable impedance and similar things. There are several different physical layers:

ISO 11898 defines a two-wire balanced signaling scheme. Little-used ISO 11519 for lower speed applications defines another two-wire balanced signaling scheme for lower bus speeds. Several proprietary physical layers do exist. Modifications of RS485 were used in the Old Ages when CAN drivers didn't exist. SAE J2411 defines a single-wire layer but the standard hasn't settled yet. A great many CAN transceiver chips are manufactured by Philips; alternative
vendors include Bosch, Siemens, Siliconix and Unitrode. Dept. of comp. Sc & Engg Thrissur 11 Govt. Engg. College,
Seminar 2003
A very common type is the 82C250 transceiver which implements the physical layer defined by ISO 11898.
CAN APPLICATION LAYERS

THE OSI MODEL ISO7498 defines a communications standard known as the Open Systems Interconnection (OSI) model. This model describes how communications should occur between computers on any network, and has been adopted as a general "open" network communication standard. In principle - anything that conforms to the standard can communicate, electronically, with anything else that conforms to the standard. The OSI model defines seven independent "layers" of a protocol stack. Strict compliance with the standard requires that each layer is insulated from the others by well-defined interfaces. Few, if any, networks comply absolutely with the OSI model with regard to provision of all seven layers as distinct entities. The CAN specification (ISO11898) discusses only the Physical and Data-Link layers for a CAN network. The Data-Link Layer - is the only layer that recognizes and understands the format of messages. This layer constructs the messages to be sent to the Physical Layer, and decodes messages received from the Physical Layer. In CAN controllers, the Data-Link Layer is usually implemented in hardware. The Physical Layer - specifies the physical and electrical characteristics of the bus, and of the hardware that converts the characters of a message into electrical signals for transmitted messages - and electrical signals into characters for received messages. Although the other layers may be implemented in either hardware (as chip level functions) or software, the Physical Layer is always "real" hardware. Dept. of comp. Sc & Engg Thrissur 12 Govt. Engg. College,
Seminar 2003
Many applications of CAN require services that are beyond the basic functionality specified by the Data-Link Layer but which may be implemented at the Application Layer. For example, the transmission or reception of data units longer than eight bytes. To meet this need several organizations have developed Application Layers. A few of them are briefly discussed below.
CAL (CAN APPLICATION LAYER) Aptly named, and based on an existing and proven protocol originally developed by Philips Medical Systems, CAL is an application-independent application layer that has been specified and is now maintained by the CAN in Automation (CiA) user group. Anyone who implements CAL may do so free of any license royalty. CANOPEN CANopen is an implementation of CAL and is defined by the CANopen Communications Profile in CiA DS-301.It was originally developed for industrial control systems. The family of specifications includes also different device profiles as well as frameworks for specific applications. CANopen networks are also used in off-road vehicles, maritime electronics, medical equipment, and railways. The very flexible application layer and many optional features are well suited for designing tailored networks. This is what embedded network designers need: as much freedom as possible in order to develop better products than the competitors. On the other hand, it is still a standardized application layer implemented in off-the-shelf hardware. In addition, several generic configuration tools are available. Nevertheless, the user can define applicationspecific device profiles.
PCAL
13
Seminar 2003
Another example of a CAL implementation - known as P-CAL (Portable CAN Application Layer) - has been developed by the University of the German Federal Armed Forces in Munich, Germany. Licenses are available for binary or source code, for a range of processors. DEVICENET DeviceNet is a CiA-approved application layer based on CAN 2.0A and is widely used in industrial automation applications. DeviceNet (originally developed by Rockwell/Allen-Bradley) is now an "Open" field bus regulated by an independent organization know as the Open DeviceNet Vendors Association, from whom copies of the specification may be purchased. DeviceNet is mainly used in industrial applications, in particular in factory automation. It is a low-cost communications link to connect industrial devices (such as limit switches, photoelectric sensors, valve manifolds, motor starters, process sensors, bar code readers, variable frequency drives, panel displays and operator interfaces) to a network and eliminate expensive hard wiring. The direct connectivity provides improved communication between devices as well as important device-level diagnostics not easily accessible or available through hard wired I/O interfaces. DeviceNet is a simple, networking solution that reduces the cost and time to wire and install factory automation devices, while providing interchangeability of "like" components from multiple vendors. DeviceNet specifications have been developed by the Open DeviceNet Vendor Association (ODVA) and are internationally standardized. Buyers of the DeviceNet Specification receive an unlimited, royalty-free license to develop DeviceNet products. SDS (SMART DISTRIBUTED SYSTEM) SDS is also a CiA-approved application layer. Developed by Honeywell, one of the main uses of SDS is for machine control applications.
14
Controller Area Network CAN KINGDOM
Seminar 2003
Another CiA-approved application layer, named CAN Kingdom, is provided by a Swedish company named Kvaser AB. CAN Kingdom unleashes the full power of CAN. It gives a system designer maximum freedom to create his own system. He is not bound to the CSMA/AMP multi-master protocol of CAN but can create systems using virtually any type of bus management and topology. CAN Kingdom opens the possibility for a module designer to design general modules without knowing in which system they will finally be integrated into and what type of higher layer CAN protocol it will have. As the system designer can allow only specific modules to be used in his system, the cost advantage of an open system can be combined with the security of a proprietary system! Since the identifier in a CAN message not only identifies the message but also governs the bus access, a key factor is the enumeration of the messages. Another important factor is to see to it that the data structure in the data field is the same in both the transmitting and receiving modules. By adopting a few simple design rules these factors can be fully controlled and communication optimized for any system. This is done during a short setup phase at the initialization of the system. Including some modules not following the rules of the CAN Kingdom into a CAN Kingdom system is even possible. CAN Kingdom also enforces a conform documentation of modules and systems.
15
Seminar 2003
THE CABLE
The ISO 11898 prescribes that the cable impedance be nominally 120 Ohms, but an impedance in the interval of [108..132] Ohms is permitted. There are not many cables in the market today that fulfils this requirement. There is a good chance that the allowed impedance interval will be broadened in the future. ISO 11898 is defined for a twisted pair cable, shielded or unshielded. Work is in progress on the single-wire standard SAE J2411. At a speed of 1 Mbit/s, a maximum cable length of about 40 meters (130 ft.) can be used. This is because the arbitration scheme requires that the wave front of the signal can propagate to the most remote node and back again before the bit is sampled. In other words, the cable length is restricted by the speed of light. Other maximum cable lengths are (these values are approximate)
100 meters (330 ft) at 500 kbit/s 200 meters (650 ft) at 250 kbit/s 500 meters (1600 ft) at 125 kbit/s 6 kilometers (20000 ft) at 10 kbit/s If optocouplers are used to provide galvanic isolation, the maximum bus length is
decreased accordingly. There is no standard at all for CAN bus connectors! Usually, each Higher Layer Protocol defines one or a few preferred connector types. Common types include
9-pole DSUB, proposed by CiA. 5-pole Mini-C and/or Micro-C, used by DeviceNet and SDS. 6-pole Deutch connector, proposed by CANHUG for mobile hydraulics.
16
Seminar 2003
CAN BIT TIMING
THE LAYOUT OF A BIT Each bit on the CAN bus is, for timing purposes, divided into at least 4 quanta. The quanta are logically divided into four groups or segments
the Synchronization Segment the Propagation Segment the Phase Segment 1 the Phase Segment 2
Here is a picture of a CAN data bit:
Fig 5: CAN Bit Timing
The Synchronization Segment, which always is one quantum long, is used for synchronization of the clocks. A bit edge is expected to take place here when the data changes on the bus. The Propagation Segment is needed to compensate for the delay in the bus lines. Dept. of comp. Sc & Engg Thrissur 17 Govt. Engg. College,
Seminar 2003
The Phase Segments may be shortened (Phase Segment 1) or lengthened (Phase Segment 2) if necessary to keep the clocks in sync. The bus levels are sampled at the border between Phase Segment 1 and Phase Segment 2. Most CAN controllers also provide an option to sample three times during a bit. In this case, the sampling occurs on the borders of the two quanta that precedes the sampling point, and the result is subject to majority decoding (at least this is the case for the 82527.)
CLOCK SYNCHRONIZATION In order to adjust the on-chip bus clock, the CAN controller may shorten or prolong the length of a bit by an integral number of quanta. The maximum value of these bit time adjustments are termed the Synchronization Jump Width, SJW. Hard synchronization occurs on the recessive-to-dominant transition of the start bit. The bit time is restarted from that edge. Resynchronization occurs when a bit edge doesn't occur within the Synchronization Segment in a message. One of the Phase Segments are shortened or lengthened with an amount that depends on the phase error in the signal; the maximum amount that may be used is determined by the Synchronization Jump Width parameter.
BIT TIMING REGISTER CALCULATION
Most CAN controllers allow the programmer to set the bit timing using the following parameters:

A clock prescaler value The number of quanta before the sampling point The number of quanta after the sampling point The number of quanta in the Synchronization Jump Width, SJW
18
Seminar 2003
Usually two registers are provided for this purpose: btr0 and btr1. Things tend to vary slightly between different controllers, however, so read your data sheets carefully.
On the 82c200 and SJA1000, both from Philips, the register layout is like this:
7 Btr0 Btr1 SJW1 SAM
6 SJW0 TSEG22
5 BRP5 TSEG21
4 BRP4 TSEG20
3 BRP3 TSEG13
2 BRP2 TSEG12
1 BRP1 TSEG11
0 BRP0 TSEG10
BRP0..BRP5 sets the clock prescaler value SJW0..SJW1 sets the length of the SJW TSEG10..TSEG13 sets the number of quanta before the sampling point (the start bit is included) TSEG20..TSEG22 sets the number of quanta after the sampling point. SAM is set to 1 if three samples are to be obtained and to 0 if one sample is enough.
19
Seminar 2003
CAN ERROR HANDLING
Error handling is built into in the CAN protocol and is of great importance for the performance of a CAN system. The error handling aims at detecting errors in messages appearing on the CAN bus, so that the transmitter can retransmit an erroneous message. Every CAN controller along a bus will try to detect errors within a message. If an error is found, the discovering node will transmit an Error Flag, thus destroying the bus traffic. The other nodes will detect the error caused by the Error Flag (if they haven't already detected the original error) and take appropriate action, i.e. discard the current message. Each node maintains two error counters: the Transmit Error Counter and the Receive Error Counter. There are several rules governing how these counters are incremented and/or decremented. In essence, a transmitter detecting a fault increments its Transmit Error Counter faster than the listening nodes will increment their Receive Error Counter. This is because there is a good chance that it is the transmitter who is at fault. When any Error Counter raises over a certain value, the node will first become "error passive", that is, it will not actively destroy the bus traffic when it detects an error, and then "bus off", which means that the node doesn't participate in the bus traffic at all. Using the error counters, a CAN node can not only detect faults but also perform error confinement. ERROR DETECTION MECHANISMS
The CAN protocol defines no less than five different ways of detecting errors. Two of these work at the bit level, and the other three at the message level. 1. Bit Monitoring. 2. Bit Stuffing. 3. Frame Check. Dept. of comp. Sc & Engg Thrissur 20 Govt. Engg. College,
Controller Area Network 4. Acknowledgement Check. 5. Cyclic Redundancy Check. Bit Monitoring
Seminar 2003
Each transmitter on the CAN bus monitors (i.e. reads back) the transmitted signal level. If the bit level actually read differs from the one transmitted, a Bit Error is signaled. (No bit error is raised during the arbitration process.) Bit Stuffing When five consecutive bits of the same level have been transmitted by a node, it will add a sixth bit of the opposite level to the outgoing bit stream. The receivers will remove this extra bit. This is done to avoid excessive DC components on the bus, but it also gives the receivers an extra opportunity to detect errors: if more than five consecutive bits of the same level occurs on the bus, a Stuff Error is signaled.
Frame Check Some parts of the CAN message have a fixed format, i.e. the standard defines exactly what levels must occur and when. (Those parts are the CRC Delimiter, ACK Delimiter, End of Frame, and also the Intermission, but there are some extra special error checking rules for that.) If a CAN controller detects an invalid value in one of these fixed fields, a Form Error is signaled. Acknowledgement Check All nodes on the bus that correctly receives a message (regardless of their being "interested" of its contents or not) are expected to send a dominant level in the socalled Acknowledgement Slot in the message. The transmitter will transmit a recessive level here. If the transmitter can't detect a dominant level in the ACK slot, an Acknowledgement Error is signaled.
21
Controller Area Network Cyclic Redundancy Check
Seminar 2003
Each message features a 15-bit Cyclic Redundancy Checksum (CRC), and any node that detects a different CRC in the message than what it has calculated itself will signal a CRC Error. If one or more errors are discovered by at least one station using the above mechanisms, the current transmission is aborted by sending an "error flag". This prevents other stations accepting the message and thus ensures the consistency of data throughout the network. After transmission of an erroneous message that has been aborted, the sender automatically re-attempts transmission (automatic re-transmission). There may again competition for bus allocation. However effective and efficient the method described may be, in the event of a defective station it might lead to all messages (including correct ones) being aborted. If no measures for self-monitoring were taken, the bus system would be blocked by this. The CAN protocol therefore provides a mechanism to distinguish sporadic errors from permanent errors and local failures at the station. This is done by statistical assessment of station error situations with the aim of recognizing a station's own defects and possibly entering an operation mode in which the rest of the CAN network is not negatively affected. This may go as far as the station switching itself off to prevent other nodes' messages erroneously from being recognized as incorrect.
ERROR CONFINEMENT MECHANISMS Every CAN controller along a bus will try to detect the errors outlined above within each message. If an error is found, the discovering node will transmit an Error Flag, thus destroying the bus traffic. The other nodes will detect the error caused by the Error Flag (if they haven't already detected the original error) and take appropriate action, i.e. discard the current message. Each node maintains two error counters: the Transmit Error Counter and the Receive Error Counter. There are several rules governing how these counters are incremented and/or decremented. In essence, a transmitter detecting a fault increments its Dept. of comp. Sc & Engg Thrissur 22 Govt. Engg. College,
Seminar 2003
Transmit Error Counter faster than the listening nodes will increment their Receive Error Counter. This is because there is a good chance that it is the transmitter who is at fault. A node starts out in Error Active mode. When any one of the two Error Counters raises above 127, the node will enter a state known as Error Passive and when the Transmit Error Counter raises above 255, the node will enter the Bus Off state.

An Error Active node will transmit Active Error Flags when it detects errors. An Error Passive node will transmit Passive Error Flags when it detects errors. A node which is Bus Off will not transmit anything on the bus at all. The rules for increasing and decreasing the error counters are somewhat complex,
but the principle is simple: transmit errors give 8 error points, and receive errors give 1 error point. Correctly transmitted and/or received messages causes the counter(s) to decrease.
CAN IMPLEMENTATIONS
There is no standard for how CAN controllers shall be implemented or how they shall communicate with their host microcontroller. There are two main implementation strategies for CAN controllers today. They are called BasicCAN and FullCAN. The main difference between these strategies is how interesting messages are filtered out, that is how it is decided what messages are interesting and which are not. There are also differences in how remote frames are answered, and on how messages are buffered. The differences will effect how much load is put on the host microcontroller.
BasicCAN
BasicCAN is usually used in cheaper standalone CAN controllers or in smaller microcontrollers with integrated CAN controller.
23
Seminar 2003
A BasicCAN controller normally has two receive buffers and one transmit buffer. The receive buffers are arranged in a FIFO structure, and a message can be received into the one buffer while the microcontroller is reading the information from the other buffer. If a message is received while both receive buffers are full, the oldest messages are kept. This means that newer messages might be lost if the host microcontroller does not read the messages fast enough. A message is sent by writing it to the transmit buffer. Interesting messages are filtered out using two registers that operate on the message identifier. Each bit in the identifier is checked against the filter. If the message matches the filter it is stored in one of the receive buffers. Each bit of the identifier filter can be set to '1', '0' or 'don't care'. Often the filter only operates on eight of the eleven bits in the identifier (standard CAN). This means the three lower bits in the identifier are always 'don't care'. When BasicCAN is used it is important to choose identifiers with utmost care, so that the window of the filter can be kept as small as possible. All messages that are let through the filter must be read and checked by the microcontroller. This means that the final filtering is done in software. A BasicCAN controller has no support for automatically answering remote frames, which means that the application will have to handle them. This will put extra load on the microcontroller or processor, but will make sure that the value returned is updated.
24
Seminar 2003
BasicCAN features The application fills complete Tx register including ID,RTR,datalength,data -> every ID can be transmitted Every CAN message can be received Normally two receive buffers in FIFO structure Receive Global message filtering. It is normally not possible to set up the filter so that only the interesting messages are let through -> final filtering must be done by the application Remote frame handling Overrun philosophy Remote frame are answered by the application Keep the oldest message (newer messages will be lost)
Transmit
FullCAN
FullCAN is used in more expensive, high performance CAN controllers and microcontrollers. The FullCAN controller has a set of buffers called mailboxes. On initialization, each mailbox is assigned an identifier and is set to transmit or receive. When the CAN controller receives a message it checks the mailboxes in order to see is there is a receive mailbox with the same identifier as the message. If such a mailbox is found, the message is stored in it and the host controller is notified. Otherwise the message is discarded. When transmitting a message the message length and data is written to the transmit mailbox with the correct identifier. If a remote message is received the controller checks the remote identifier against the transmit mailboxes. If a match is found, the controller automatically sends a message with the identifier and data contained in that mailbox. This means that the microcontroller gets a lower load, and that the software does not have to handle remote Dept. of comp. Sc & Engg Thrissur 25 Govt. Engg. College,
Seminar 2003
messages. However, if the mailbox has not been updated in a long time, the information sent to the network will be old. This has to be considered when writing the software. With a FullCAN controller it is possible to filter out only the exact message types that are interesting. This type of controller will therefore give a lower load on the host microcontroller. However, the number of mailboxes is limited. With some controllers it is possible to reconfigure the mailboxes dynamically. However, that does not completely solve the problem. Therefore some controllers are mixed CAN controllers, that is they have mailboxes, but also BasicCAN buffers. FullCAN controllers have support for automatically answering remote frames. This will decrease the load on the host microcontroller or processor, but may also mean that old information is sent. It is very important to take this into consideration when writing your application.
FullCAN features Transmit Transmit mailboxes initialized once Only data bytes written before transmission Only messages with the IDs defined in receive mailboxes can be received Receive No double buffering for mailboxes Full acceptance filtering (only the exact message IDs are let through) Remote frame handling Overrun philosophy Remote frames are answered automatically by the controller Keep the newest message (older messages with the same ID will be lost)
CAN APPLICATIONS
Dept. of comp. Sc & Engg Thrissur 26 Govt. Engg. College,
Seminar 2003
The Controller Area Network (CAN) serial bus system is used in a broad range of embedded as well as automation control systems. It usually links two or more microcontroller-based physical devices. The Original Equipment Manufacturers (OEM) design embedded control systems; the end-user has no or only some knowledge of the embedded network functions and is therefore not responsible for the CAN communication system. Opposed to that, automation control systems are specified by the end-user. The system design including the CAN network services may be implemented by the end-users themselves or by a system house. The main CAN application fields include: PASSENGER CARS The automotive industry uses CAN as the in-vehicle network (IVN) for the engine management, the body electronics like door and roof control, air conditioning, and lightning, as well as for the entertainment control. The majority of the European carmakers use CAN-based IVNs. The American and the Far East passenger car manufacturers have also started implementing CAN-based IVNs.
MARITIME ELECTRONICS In maritime electronics CAN networks are used in boats, ships and vessels as embedded network in sub-systems and as integration network connecting several subsystems. Dedicated maritime devices with CAN connectivity exist, marine sub-systems with CAN interface as well as entirely CAN-based ship automation systems. Ship automation systems may comprise several physical CAN networks. FACTORY AUTOMATION
27
Seminar 2003
In factory automation CAN is used to interconnect machines, process control units and production sub-systems. Typical applications include conveyors, production data recording, and other end-user configurable systems. In those applications there is a high demand for off-the-shelf plug-and-play capability. INDUSTRIAL MACHINE CONTROL CAN is used as an embedded network for industrial machine control for example in textile machines, printing machines, injection molding machines, or packaging machines. These embedded control networks link single devices (e.g. I/O modules) as well as sub-systems. Many of these applications are motion control oriented.
LIFTS AND ESCALATORS Lifts and escalators have always used embedded CAN networks. All applicable devices in a lift, such as panels, controller, doors, drives, light barriers, etc. are linked to each other and controlled via CAN. There are also entirely CAN networked escalator control systems.
BUILDING AUTOMATION In building automation CAN is used to manage heating, cooling, lighting, air ventilation and doors. Further uses are alarm system control, sprinkler systems, backstage control systems, as well as studio equipment including audio and video control. In Switzerland, there are several integrated room control applications based on CAN. Typical applications include railway stations, school building, and office facilities. In Germany, CAN-based networks control the deep-freezers and refrigerators in some super-markets. AIRCRAFT AND AEROSPACE ELECTRONICS Dept. of comp. Sc & Engg Thrissur 28 Govt. Engg. College,
Seminar 2003
CAN is used as a backbone network in aircrafts for flight state sensors, navigation systems and research PCs driving displays installed in the cockpit. Within the aircraft CAN networks are used to analyze in-flight data or together with a voice/video installation to analyze crew assistance provided by the cockpit interfaces. CAN is also used in aerospace applications, e.g. in engine control systems such as fuel systems, pumps and linear actuators.
MEDICAL EQUIPMENT AND DEVICES CAN is used as embedded network in medial devices such as in X-ray machines. Complete operating rooms are equipped with a CAN network that manages all functions. CAN is also used as embedded network in patient beds. In addition, complete hospital control systems with voltage control, indication and control units, multi cube power meters and digital I/O, and visualization software are networked via CAN.
NON-INDUSTRIAL MACHINE CONTROL CAN is used in a variety of smaller, non-industrial machines, such as vending machines, automatic teller machines (ATM), and gambling machines (e.g. Japanese Patchinko machines). There are also bank terminals implementing an embedded CAN network. Some high-performance office equipment such as copy machines and printers is also equipped with CAN-based control systems.
29
Seminar 2003
CONCLUSION
CAN can be regarded as the standard protocol for use within machines constructed of stand alone actuators and "intelligent" sensors. CAN is fast enough for real-time performance required in such machines, it has an excellent reliability and standard CAN components are cheap and designed to be used in the harsh electrical and physical environment in a car. Its feasibility for industrial use is proven by the textile industry where it has been used in weaving machines, installed all over the world, since 1990. Current systems are proprietary ones and there has been a great problem to find an approach that enables systems to be constructed of stand alone units from different suppliers without loosing the real-time performance of CAN. This problem is now solved by the concept CAN Kingdom by which a system designer can make an optimized protocol, based upon the CAN standard, for his system. This protocol does not have to be a multi-master CSMA/AMP protocol but can use virtually any type of access management and topology.
30
Seminar 2003
REFERENCES
www.can-cia.de www.algonet.se www.mjschofield.com www.kvaser.com www.motorola.com
31

Controller Area Network

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Controller Area Network

Uploaded by

Copyright:

Available Formats

Controller Area Network

Dept. of comp. Sc & Engg Thrissur

Govt. Engg. College,