
Controller Area Networking
The Future Of Industrial Microprocessor Communications?
This article was released in the January 1995 issue of
the Hitex UK Ltd. C51/166 newsletter.
HTML version by
Olaf 'Olu' Pfeiffer,
Hitex.
The CAN (Controller Area Network) is an ISO defined serial
communications bus that was originally developed during the
late 1980's for the automotive industry. Its basic design
specification called for a high bit rate, high immunity to
electrical interference and an ability to detect any errors
produced. Not surprisingly due to these features the CAN
serial communications bus has become widely used throughout
the automotive, manufacturing and aerospace industries.
The CAN communications protocol describes the method by which
information is passed between devices. It conforms to the Open
Systems Interconnection model which is defined in terms of layers.
Each layer in a device apparently communicates with the same layer
in another device. Actual communication is between adjacent layers
in each device and the devices are only connected by the physical
medium via the physical layer of the model. The CAN architecture
defines the lowest two layers of the model: the data link and
physical layers. The application levels are linked to the physical
medium by the layers of various emerging protocols, dedicated to
particular industry areas plus any number of propriety schemes
defined by individual CAN users. Perhaps the best example of an
industry-standard CAN-based protocol is Allen-Bradley's DEVICEnetTM,
designed for the networking of PLCs and intelligent sensors.
The physical medium consists of a twisted-pair with appropriate
termination. In the basic CAN specification, it has a transmission
rate of up to 250 kbaud whilst full CAN runs at 1MBaud.
The physical and data link layers will normally be transparent to
the system designer and are included in any component that
implements the CAN protocols. There are some microcontrollers with
integral CAN interfaces, for example, the Philips 8051-compatible
8xC592 processor and the Siemens SABC167CR. The 80C200 is a
standalone CAN controller which directly interfaces to many
microcontrollers. The connection to the physical medium can be
implemented with discrete components or with the 82C250 integrated
circuit. Standalone CAN controllers are also available from
Siemens, NEC and Intel.
Low Cost Remote IO
Traditionally, CAN has been a network for coupling
microcontroller-based devices meaning the cost per node is not
particularly low. An interesting development is the concept of
a "SLIO" module. This is a single chip which can act as a dumb
input/output gateway on a CAN network, able to turn messages
into real digital IO signals. It can also read IO pins and
transmit the data as message plus use an integral A/D convertor
to generate messages for introduction into a network.
These devices are extremely cheap and are ideal for driving
remote sensors, actuators or gathering digital and analog data.
They can be viewed as remote add-ons to a central microcontroller.
Currently, only basic CAN SLIOs are available but undoubtedly
Siemens and other full CAN specialists will produce full CAN
equivalents.
Two Varieties Of CAN
CAN has exists in two forms; a basic CAN and a higher form with
an "acceptance filter". Basic CAN has a tight coupling between
the CPU and the CAN controller, where all messages broadcast on
the network have to be individually checked by the microcontroller.
This results in the CPU being "tied up" checking messages rather
than processing them, all of which tends to limit the practicable
baud rate to 250kBaud. The introduction of an acceptance filter
masks out the irrelevant messages, using identifiers (ID) and
presents the CPU with only those messages that are of interest.
This is usually referred to as "Full CAN". Philips is the leading
proponent of basic CAN whilst Intel and Siemens only subscribe to
full CAN. The Full CAN protocol allows for two lengths of
identifiers: part A allows for 11 message identification bits,
which yield 2032 different identifiers, whilst extended CAN
(part B) has 29 identification bits, producing 536870912 separate
identifiers.
Part A devices such as the Philips PCA82C200 are only able to
transmit and receive standard CAN protocol. Used on an extended
CAN system in which 29 bit IDs are present, the device will cause
errors and crash the entire network. The Siemens 81C90 and 81C91
are similarly part A devices (11 ID bits), but have the ability to
be used with extended CAN without causing no bus errors. This is
achieved by simply ignoring the extended CAN frames and are thus
known as "part B passive" devices. The data-link layer defines
the format and timing protocol with which the messages are
transmitted. There are two descriptor bytes and up to eight data
bytes. The descriptor bytes are particularly important as they
define the priority of the message and the type of message being
transmitted.
The identifier field contains 11 bits and is used for
identification of the message as well as for determining its
bus access priority. The priority is defined to be highest for
the smallest binary value of the identifier. The allocation of
priorities to messages is a feature of the CAN bus that makes it
particularly attractive for use within a strongly real time
control environment. Bits 7-10 of the identifier field define
the message priority. This means that messages can have a
priority number between 0 (high priority) and 15 (low priority).
The CAN specification guarantees the latency time associated with
priority values, shown in table 1.
Coping With Message Collisions
As has been said, a fundamental CAN characteristic is that the
lower the message number, the higher its priority - a identifier
consisting entirely of zeros is therefore deemed to be the highest
priority message. Thus if two nodes begin to transmit
simultaneously, the first source to send a zero when the other
source attempted a one, gets control of the CAN bus and goes on to
complete its message. This use of "non-destructive bitwise"
arbitration is coupled with the capability of each node to able to
monitor its own transmissions. Thus if a transmitter 'A' is
overruled by a source 'B' sending a higher priority message, the
fact that the message read back does not match the message that
'A' attempted to send means that it will temporarily halt.
Another attempt will subsequently be made to send it once the bus
is released. This functionality is part of layer 1 and is
contained entirely within the CAN controller device. It is
therefore transparent to the CAN user.
Interactive Communication
It is possible to send a request for data to a specified address,
and the remote transmission request (RTR) bit defines whether the
message sent is a request for data or the actual data.
The data-length code tells the receptor how many data bytes the
message contains. In the case of data requests, no data bytes
follow and therefore the data-length code has no direct relation
to the number of data bytes.
The maximum number of nodes on a CAN bus is 32. The limit of
messages per second ranges from about 2000 to about 5000 on a
bus with 250kbaud transmission rate, depending on the number of
bytes per message.
The Physical Layer
CAN can use a number of physical media such as twisted wire-pairs,
fibre-optics etc. The commonest method is the former.
The signalling is carried out using differential voltages and it is
from this that CAN derives much of its noise immunity and fault
tolerance. The two signal lines are termed 'CAN_H' and 'CAN_L' and
in the quiescent state, sit at 2.5v. A '1' is denoted by CAN_H
being above CAN_L and as such is termed a 'dominant' bit whilst
zero has CAN_L above CAN_H, yielding a 'recessive' bit.
The use of voltage differentials allows CAN networks to function
when one of the signalling lines is severed. Or in extremely noisy
environments. With a simple twisted pair, the differential CAN
inputs effectively cancel out noise, provided it is within the
common mode range.
Cheap interfaces are available from Siliconix amongst others,
which translate from 5v logic levels to the balanced line required
by CAN.
Customising CAN To Specific Industries
The allocation of message numbers (and hence priorities) is up to
the individual user but as has been indicated, certain industry
groups are mutually agreeing the significance of certain messages
and the exact protocol to be used. For example, manufacturers of
motor drives might decide that message 0x10 is the winding current
feedback signal from any motor on a CAN network and that 0x11 is
the tacho speed. As 0x10 has a zero before 0x11, messages
relating to current values will overrule those concerned with
tacho readings.
In the case of DEVICEnet, PLCs from various manufacturers can be
linked together. Peripheral devices such as pressure and
temperature sensors can be added to the CAN network. As the
messages generated by the sensors has been predefined, the PLCs
will know that a certain message always relates to temperature,
regardless of who actually manufactured it.
Situations Where CAN Is The Solution
CAN is ideal for any situation where microcontrollers need to
communicate either with each other or with remote peripherals.
In its home environment, the car, CAN was originally used to allow
mission-critical real time control systems such as engine
management systems and gearbox controls to exchange information.
Here, CAN's short and guaranteed message latency times allowed
each end of the network is working with current data, even where
this may be changing on a hundreds of microsecond timescale.
These systems all utilise full CAN in that the CAN controllers
filter out unwanted messages to reduce the host CPU load.
However, the appearance of low-cost standalone full CAN devices
such as the Siemens 81C91 has allowed less time-critical tasks
such as door systems (window lifters, mirror controls etc.) to
become part of the CAN network. Indeed, the entire conventional
wiring harness has been replaced in some instances by two-wire
CAN networks in which even mundane devices such brake lights and
indicators are just additional nodes.
In the meantime, basic CAN with 11 bit identifiers has become
widely accepted as a general purpose network in the industrial
control field. Developed and promoted mainly by Philips it allows
very simple communication between microcontrollers and peripherals
at up to 250kBaud. Indeed, the cheap SLIO device can provide up
to 16 IO pins which may be assigned as up to 6 channels of 10-bit
A/D or D/A, plus ordinary IO pins. SLIOs have unique identifiers,
set via external resistors. Thus they can recognise messages
intended for them and generate messages based on inputs received.
Industrial applications can also benefit from full CAN at 1MBaud
by using full-CAN equipped microcontrollers from Siemens and Intel
who also produce add-on CAN controllers for ordinary
microcontrollers. However, the basic philosophy of full CAN is
that it should be reserved for very high speed data interchange
between microprocessing units rather than communication down to
a low-speed IO port level.
CAN Support Tools
Despite its relative youth, CAN is already supported by a huge
range of development tools. These range from simple development
boards to full scale CAN analysers. Phytec of Mainz in Germany
produce a wide range of CAN-equipped microcontroller boards based
on the 8051 and SABC166 architectures. These comprise
microcontroller + external CAN controller (Philips 82C200) or CAN
microcontroller-only (80C592). The boards can be programmed in C
or assembler and can host state-of-the-art debuggers such as
Hitex's HiTOP. Phytec also offer small SLIO modules.
Softing of Munich produce a range of CAN tools and interfaces.
These includeCAN-PCMCIA and VME slots plus a full CAN analyser,
based on a conventional PC card or a miniture PCMCIA module -
ideal for CAN debugging in the field.
Being so tightly coupled to microcontrollers, existing tools such
as in-circuit emulators are able to provide useful facilities such
as real time monitoring of input and output data to CAN controllers,
whether on-chip or off-chip.