Unformatted text preview:

The Controller Area Network is a well-established networking system specifically designed with real-time requirements in mind. Developed in the 1980s by Robert Bosch, its ease of use and low cost has led to its wide adoption throughout the automotive and automation industries. However, for the beginner using CAN may seem somewhat bewildering. This article goes some way into explaining how CAN is used both at the hardware and the software levels. he Controller Area Network (CAN) was originally developed in the 1980s for the intercpnnection of control components in automotive vehicles. The complexity of the control functions implemented by engine management systems, anti-lock brakes and skid controls normally requires dedicated lines for the interconnection of the different control components. However, a continuous increase in complexity has led to a physical maximum not only in the quantity of wires required but also in physical connector size. CAN enabled a huge reduction in wiring complexity and, additionally, made it possible to interconnect several devices using a single pair of wires, allowing data exchange between them at the same time. Needless to say, it was not long before this idea migrated from vehicles into the machine and automation markets. Nowadays CAN has found its way into such diverse areas as agricultural machinery, medical instrumentation, elevator controls, fairground rides, public transportation systems and industrial automation control components. It is because of its widespread use that CAN semiconductors are inexpensive. Furthermore, since a large number of semiconductor manufacturers, such as Philips, Motorola, National Semiconductors, Siemens and Intel (to name but a few) produce CAN devices, CAN technology is guaranteed well into the future. The basic features of CAN are: 0 High-speed serial interface: CAN is configurable to operate from a few kilobits per second right up to 1 Mbit/s transmission rates. 0 Low-costphysical medium: CAN operates over a simple twisted wire pair, therefore cabling a CAN network is inexpensive compared to multicore or coaxial cables often required by other bus systems. 0 Short data lengths: The short data lengths of CAN messages mean that CAN has very low latency when compared to other systems. 0 Fast reaction times: The ability to transmit informa- tion without requiring a token or permission from a bus arbiter results in extremely fast reaction times. 0 Multi-master and peer-to-peer communication: Using CAN it is simple to broadcast information to all or a subset of nodes on the bus and just as easy to implement peer-to-peer communication. 0 Error detection and correction: The high level of error detection and number of error detection mechanisms provided by the CAN hardware means that CAN is extremely reliable as a networking solution. GAN @pmmUijoogj prijoo~~pOes CAN allows the implementation of peer-to-peer and broadcast or multicast communication functions with lean bus bandwidth use. The basic principles of CAN communication are explained in the following sub- sections. Communication modes and data exchange When data is transmitted over a CAN network no individual nodes are addressed. Instead, the message is assigned an identifier that works as a unique tag on its data content. The identifier not only defines the message contents but also the message priority. When a node wishes to transmit information it simply COMPUTING 8.1 CONTROL ENGINEERING JOURNAL JUNE 1999 113arbitration field 11 bit identifier Fig. 1 Format of a CAN telegram control data I- CRC +m DO D4 t- DLC 0 to 8 bytes 15 bit passes the data and the identifier to its CAN controller supporting purely the standard format will be able to and sets the relevant transmit request. It is then up to the tolerate other devices transmitting CAN frames using the CAN controller to format the message contents and extended format (2.0B passive devices) and function transmit the data in the form of a CAN frame. Once the correctly. node. has gained access to the bus and is transmitting A message in the standard format begins with the start its message, all other nodes become receivers. Having bit or start of frame (SOF). This is followed by the received the message correctly, these nodes then perform arbitration field which contains the identifier of the CAN an acceptance test to determine if the data is relevant to telegram and is used to arbitrate access to the bus. Also that particular device, based on the part of the arbitration field is the . identifier of the message. RTR bit (remote transmission Therefore, it is not only possible to request) which indicates whether the perform communication on a peer- frame is a request frame (without to-peer basis where a single node any data, this type of message is used to trigger a transmission by another node) or a data frame. accepts the message but also to perform broadcast and synchronised communication whereby multiple The control field contains the IDE nodes can accept the same message bit (identifier extension), which using a single transmission. Kjil@Z~ijQS EbEiIE bEIS indicates whether the frame is a Furthermore, the ability to send data standard format frame or an on an event basis means that bus extended one, the YO bit that is load utilisation can be kept to a reserved for future extensions and minimal amount. Gam '@FE '@ a four additional bits containing the This concept has become known mirj~[ma[ al[?liil@rymE length of the data field (data length in the networking world as the code). Ub@ abBOBQ7 E@ S@md darn @Kl ~qp(jil~ bgj~c&j~ ~E~~ka~fl@m - producerkonsumer mechanism whereby one node produces data on the bus for other nodes to consume. One difference with CAN over other fieldbus solutions is that this mechanism requires no interaction from a bus master or arbiter. Telegram format Fig. 1 shows the format of a CAN telegram (standard format). It shows the CAN message format that uses 11-bit identifiers (2.OA format); however, an extended CAN format (2.OB format) also exists that uses 29-bit identifiers instead. CAN controllers supporting the extended format will in general also work with the standard format communication using 11-bit


View Full Document

UNCC ECGR 6185 - An overview of controller area network

Documents in this Course
Zigbee

Zigbee

33 pages

Load more
Download An overview of controller area network
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view An overview of controller area network and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view An overview of controller area network 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?