Well-Known Serial Buses for Distributed Control of Backup Power Plants.

R8-485
versus Controller Area Network (CAN) Solutions
M. Castro, R. Sebastih, F. Yeves and J. Peire J. Unutia and J. Quesada
Electrical and Computer Engineering Department, UNED Corporacion ZIGOR S.A.
Ciudad Universitaria sln http:llwww.zigor.cond
28040 Madrid, SPAIN Zuazobidea sln - 01015 Vitoria, SPAIK
rsebastian@ieec. uned.es software@igor. corn

Abstrrrcf -Networking is increasingly becoming a feature of the addition of an RS-485 transceiver. RS-485 uses
industrial products such as those for medical devices, vending differential transmission over simple and inexpensive twisted
machines, machine tool, and, the example analyzed here, pair wiring. It is quite robust even in noisy industrial
modular power plants. As many such systems depend on cheap environments. When several microcontrollers need to be
microcontrollers, a common approach to networking has been linked in a multidrop network, half-duplex RS-485
based on the combination of the available standard serial
communication controller (UART) normally included in such transceivers are cheap and universally available.
devices and RS-485 drivers. However UART-based network
protocols do have some potential disadvantages. Controller The UARTs found in common microcontrollers are
Area Network (CAN) offers an attractive alternative due to the normally double-buffered controllers, they take care of byte
availability and low cost of CAN based devices. This paper reception and transmission. The communication protocol,
compares these two approaches in the design of a serial bus, from link layer up to application layer, needs to be software
devoted to internal interconnection in a commercial range of implemented. The CPU load is fairly high, it must attend to
modular power backup systems, and describes the migration every reception and transmission intenupt and process
process from the fint to the second solution messages, including CRC calculation. The 9~ bit addressing
technique [5] can reduce average overhead, but doesn't
I. INTRODUCTION
reduce peak overhead. For short distances, RS-485 allows
high-speed communication, but the maximum speed is often
A. Embedded Networking
constrained due to the load imposed on the CPU and the
maximum speed allowed by the UART.
An embedded control system is a digital electronics system
included in a self-contained product. Many embedded
RS-485 is normally used as a half-duplex multidrop
systems are based on a distributed architecture. A distributed
differential network (bus), multiple transmitters and receivers
architecture consists of a set of nodes and a communication
can reside on the line. At a given time, only one transmitter is
network that interconnects these nodes. Each node includes a
allowed to be active. The standard guarantees that if more
microcontroller or microprocessor based electronic control
than two transmitters access the bus simultaneously
unit (ECU). Reasons to adopt a distributed architecture can
(collision) the transceivers would not be damaged, but, the
be easily justified for any embedded system [9], but it is
bus level would be in an indefinite state and data would be
essential if the product is modular, that is, if the manufacturer
lost. TIAEIA-485-A standard only defines the electrical
wants to offer different solutions based on the arrangement of
characteristics of the network, it says nothing about
well defined modules. That is the case in many application
protocols. Some well-known protocols use RS-485 as a
fields such as lift control, certain medical devices, vending
physical layer (PROFIBUS-DP for example), but many
machines, machine tool or (the example approached here)
distributed proprietary systems, are based on home crafted
modular power plants. The cost per node is a critical factor
protocols tuned to the application at hand. Much of these
for a system that must be serially manufactured. This affects
protocols tend to be simple and normally follow the master-
greatly the choice of an embedded network. Standard
slave paradigm.
asynchronous serial interfaces (universal asynchronous
receiver transmitter or UART), or, more recently, CAN
C. Controller Area Network solution
controllers are available on-chip in many low cost
microcontrollers in the 8-bit and- 16-bit ranges. A cost-
'

effective implementation of a serial bus would normally be
based on these peripherals.
B. RS-485 + Standard UARTsolution
TIAEIA RS-485 is a common choice for physical layer
RS-485 is low-cost, simple and robust' It has
become widely used in many industrial-networking
applications, [15]. Many microcontrollers provide a serial
port that can become a node port on an RS-485 network with
Controller Area Network (CAN), [I], [3], has gained wide
acceptance for connecting microprocessing units. As a result
of its automotive origin. it offers robustness at low cost. In
industry, application layers such as DeviceNET and
CANopen [2], have been standardized.
At the present time, many low cost microcontrollers
include at least a CAN controller, standalone cheap
controllers are also available.

0-7803-7474-61021S17.00 02002 IEEE 2381

 IS0 111898 is the common physical layer standard for
CAN networks and many low cost transceivers are available.
Basic attributes of CAN are ([I I], [20]):
- High-integrity.
- Priority based multi-party bus access.
- Non-destructive arbitration.
- Sophisticated error detection and confinement
mechanisms.
- Data rates of up to 1 Mbps.
11. DISTRIBUTED CONTROL IN BACKUP POWER
PLANTS
The bus analyzed here was developed as a proprietary
network for application in backup power systems, which
provide back-up battery power in the event of a primary
power loss or interruption. These power systems are fully
modular and the control and supervision bus may include as
nodes: rectifiers, inverters, D C D C converters, battery
control units, etc. Typical application fields for these Ibackups
systems are communications services, switchgear control in
utility substations, industrial critical equipment, and data
centers.
A backup power plant is basically based on an
arrangement of parallel-redundant rectifiers that convert
mains AC power to DC power that charges batteries and
supplies power to critical loads. Traditional telecom
equipment generally requires -48 V DC input power, for
example. Most critical loads in a telecom power plant would
be directly connected to the 4 8 V DC bars (depeeling on
battery charge conditions the bars voltage can vary in a broad
range, typically +-IO%). When other voltages are required
they are derived from the 4 8 V DC power plant by means of
inverters or DCDC converters.
Typical battery support times range from 3 to 8 hours with
output power from less than 10 kW to more than 100 kW.
Easy maintenance, easy upgrading, and redundancy
considerations lead to a modular architecture in which power
conversion is distributed among several redundant-parallel
converters and battery capacity is divided into several battery
sections with independent protection and control.
When more power or capacity is needed more power
converters or battery sections can be added to the plant.
Every electronic unit includes a microcontroller that
controls its own operation and its linked to a serial bus for
distributed control.
The system is supervised by a central unit that normally
acts also as human-machine interface (HMI). This unit
compiles overall status and distributes orders and operation
parameters. Others classes of node can be present: a gateway
2382
node, linking the system to a LAN or WAN for remote
control, static by-pass units, switchgear control units, etc.
Multiple topologies can be generated taking into account
redundancy levels, power, backup capacity, different load
voltages, etc. Fig. 1 presents a concrete example [81,[16].
Functionality of the overall system is based on close
collaboration between the different modules. For example,
rectifier output voltage is compensated taking into account
battery temperature. That means that an output variable in a
node type rectifier is affected by an input variable in a
different node (battery control unit).
Among the most typical distributed control functions are:
- Battery recharge. Different charging regimes are
applied to the battery in order to restore its capacity or
compensate for self-discharging. Rectifier voltage is
controlled to limit the maximum charging current.
- Battery float voltage temperature compensation.
- Low voltage battery disconnection.
- Overall operational status monitoring providing
information for efficient and effective maintenance.
Event recording.
- Power plant efficient control, switching off converters
for maximum efficiency on low load conditions,
disconnecting less critical loads to extend battery
support time, by-passing inverters in some operational
conditions, etc.
- Battery condition monitoring and test.
In a modular backup power plant some distributed control
tasks require strict real time scheduling, they have
traditionally been solved by dedicated analog or digital
control links, that being the case for active current sharing
between parallel converters, frequency and phase
synchronization between parallel AC inverters, etc. An ideal
control bus should give support for those tasks.
While admitting that the cost per node is an important
constraint, a serial bus for distributed control of backup
power plants should nevertheless allow for:
- Real time interchange of network variables. Ideally
distinguishing between soft real time and strict or hard
real time variables.
- Configuration and calibration data upload and
download to the different nodes. Ideally, support for
- new software version download.
- Easy (plug&play) substitution of nodes and inclusion
of new ones, with automatic updating of configuration
parameters, necessary for correct operation in the
system.
Two alternatives for a concrete example of serial bus
design are compared in the following paragraphs.
 Fig. 1. Backup power plant
111. RS-485 + Standard UART Solution
Fig. 2 shows a simplified UML classes diagram for the
protocol implementation based on standard UART [4]. The
grayed classes are hardware implemented. The UART
includes double buffered byte transmitter and receiver. An
intermpt based message transmitter takes care of message
transmission. The message used in the proprietary protocol
includes start byte, message control byte, address byte,
several data bytes, checksum and end byte. Having foreseen
future migration to CAN, data length was limited to 8 bytes.
The message receiver is also interrupt based and takes care of
message reception. Both classes are software implemented.
The protocol controller is a software implemented state
machine that processes messages and shares data with the
application by means of an object table, some object queues
and some file control buffers (FCBs).
The protocol offers the following services:
- Master-slave access to an object table used as a double
port memory. Every object can be read or written
remotely, by means of master explicit commands, and
from the application. It is used for test and
configuration objects.
- Network variable interchange following the producer-
consumer paradigm. Sharing of network variables
between the protocol controller and the application is
2383
done by means of input and output object queues. As
an RS-485 network must be arbitrated, the producer-
consumer paradigm was implemented in combination
with an arbitration cycle. The node that acts as an
arbiter publishes its variables and, at the same time,
gives publication permission to a different node, that
answers with the publication of one of its network
variables. The producer-consumer model offers ample
benefits over classical source-destination model in
real time data interchange [14].
File interchange sessions. These are used for
calibration and configuration data upload and
download. Sharing of information between application
and protocol controller is done by means of file
control buffers. Every file is associated to a buffer
object for interchange of data and a control object for
file control. The data is sequentially written or read
through the data object. Commands for file opening,
close and positioning were defined and implemented.
They are executed by writing the control object.
The RS-485+UART implementation imposed several
drawbacks:
- Bus access must be arbitrated. A node acts as bus
arbiter following a polling sequence. For redundancy
considerations, the arbiter should be automatically
substituted in case of failure and only one arbiter must
be active at a given time. This complicates the bus
controller.
 - The node CPU must attend receiving and transmission
interrupts at a high rate. For a 115 kbps bus speed, the
byte time is less than 100 ps. The software process
time of a byte plus interrupt overhead can consume a
significant fraction of this cycle time. Thus an
important percentage of CPU capacity is employed in
byte processing when messages are received or
transmitted. Other interruptions and processes should
avoid interrupt masking for more than a byte time.
- Some microcontroller UARTS have a reduced
maximum data rate.
7 tests, etc.
Fig. 2. RS-485 + UART solution. U M L class diagram
IV. CONTROLLER AREA NETWORK (CAN) SOLIJTION
A CAN based bus promises improvements over the
previous solution:
- Increased bandwidth and high rate
communication.
- Robustness.
- Reduced CPU overload.
- Easy implementation of simultaneous
communication models, allowing simultaneous
producer-consumer interchange of real time data
and file upload and download.
- Potential implementation of real-time scirvices,
such as clock synchronization and time-triggered
communication.
2384
- Potential compatibility with a standardized CAN
iipplication layer protocol such as CANOpen or
DeviceNet.
Migration was performed in the context of the work
associated to a research subject [ 181.
Migrating from RS-485 to CAN at physical Layer level is
trivial, both RS-485 and IS0 11898 are differential bus
networks with NRZ encoding (but with different voltage
levels). Different termination techniques are applicable in an
RS-485 network [19], a CAN bus must be always correctly
DC terminated, usually by means of two 120 R terminator
resistors. RS-485 drivers should be substituted by CAN
transceivers. The same twisted pair wiring can be used for
both protocols. Of course the industrial process involved
when the migration should generate a new version of a
product is not negligible: PCB re-layout, EMC compliance
As regards the nodes there is the option of selecting
microcontrollers with integrated CAN controller or using a
combination of non-CAN microcontroller and standalone
CAN controller. The choice between the two possibilities is
based on factors such as availability of microcontrollers with
integrated CAN controller compatible with that previously
used, overall development and manufacturing costs, etc.,
~71.
At software level, two compatibility levels or phases
between old and new solution were considered (Fig. 3).
A. Phase I
The physical layer migration was performed and the
UART + RS-485 solution was substituted by a CAN
Controller + CAN transceiver solution. The software
protocol controller was essentially maintained; the
compatibility layer between old and new solution being
established at the message transmitter-receiver interface (Fig.
3). A mapping between old control and address fields and
CAN identifiers was necessary. Migration was simplified due
to the fact that the protocol messages originally defined were
limited to a maximum of 8 data bytes avoiding the need of
message segmentation and reassembly.
The software changes were reduced to a single software
module in which the old interrupt controlled message
transmission and reception was eliminated and substituted by
CAN message transmission and reception. The module was
considerably simplified as message transmission and
reception was mainly performed by the CAN controller in
hardware. This compatibility phase allowed quick update of
different nodes in order to test the new physical layer.
B. Phase 2
The protocol controller was modified, in fact it was
simplified, and the arbitrating process was unnecessary due
to the CAN intrinsic non-destructive arbitration method.
Moreover the several reception and transmitter buffers plus
acceptance filters offered by the CAN controller allowed
additional simplifications. Different buffers were used for the
different services; careful CAN identifier assignment allowed
message filtering at the controller level. Due to the self-
arbitrating characteristics of the CAN protocol, the
simultaneous operation of network variable interchange and
file upload and download were greatly simplified.
1 ObjectTable I I ObiedQueues I I 1
T3-
FCB
I Protocol Contmller
\I,
Phase 1 compatibilty
Fig. 3. Class diagram for CAN solution. Compatibility
phases
The protocol controller implementation was kept portable
between different types of node, independently of the CAN
controller used in the node. Only a concrete software module
should need to be customized for different controllers.
. A CAN controller takes care of message assembling,
reception and transmission, CRC generation and checking,
and message filtering. The CPU is only disturbed when a
selected message has been received or at the end of message
transmission. CPU average overhead was considerably
reduced. It is possible to increment the communication speed
to the limit imposed by the physical layer. In this concrete
application, with maximum bus length in the order of the
20m and short stubs it is possible to reach the highest CAN
data rate (1 Mbps).
2385
V. REAL TIME DISTRIBUTED CONTROL
As stated before in a distributed power plant some
distributed control tasks require strict real time scheduling.
Battery charging current, for example, is measured in a node
(battery control unit) and depends on the output of a different
node (rectifier). A digital control loop for battery current
limitation should be designed taking into account the delay
due to transmission of the battery current value. If such delay
is constant and predictable the control loop can be tuned
accordingly, hut variation of the delay (delay jitter) has an
adverse effect on the quality of control.
CAN is, in principle, an event triggered protocol [9], a
message (even the higher priority message) can be delayed
due to bus occupation by a previous message. Event
triggered buses are flexible and efficient, messages are
transmitted freely and the bus takes care of prioritization, but
jitter is unavoidable.
Time-triggered protocols [9], such as TTP [lo], assign
time slots to messages, jitter and uncertainty is eliminated.
They are very predictable and inflexible; an exclusive time
slot is assigned to every message.
A combination of both techniques is considered in the
design of Time Triggered variants of CAN, as TTCAN [6],
[7], and some new automotive developments [12] They
combine exclusive time slots and arbitrated time slots, the
former appropriate for real time messages and the latter for
normal messages. This approach has been considered for
mixed soft and real time scheduling in the power plant
control bus. Availability of inexpensive devices supporting
improved protocols would influence future designs.
VI. CONCLUSIONS AND FUTURE WORK
Migration Erom a RS-485+UART solution to a CAN based
solution for a proprietary bus for distributed power backup
systems has been described. The migration experience can be
of interest for applications in others fields. It can be
performed following a smooth and structured process. The
new protocol can be kept compatible at the application layer
interface. Both solutions have been compared highlighting
the benefits of a CAN based solution.
CAN opens the way to real time scheduling improvements
and mechanisms such as real time clock synchronization
service and hybrid interchange of soft and hard real time
objects [13]. New automotive developments in this field, as
TTCAN, can offer low cost opportunities for improved
industrial embedded distributed control.
 VII. ACKNOWLEDGMENT H. Kopetz, T. Thurner “TTP: A New Apprach to
Solving the Interoperability Problem of Independently
The authors would like to thank Zigor Industries Developed ECUs”. SAE Paper 981107.
(http://www.zigor.com/) for their permission to produce this
W. Lawenz. CAN System Engineering. Springer,
paper and include in it information regarding the process and
1997.
work done in their research and developing activities, as well
to EPS Mondragon and Miguel San Miguel for co-directing G. k e n and D. Heffernan, “Expanding Automotive
the End Term Project [18]. Finally, to the UNED A.esearch Electronic Systems, IEEE Computer Journal, vol. 35,
Vicedirectorate for supporting the attendance to the no. 1, pp. 88- 93, January 2002
IECON’02 conference.
M.A. Livani et al. “Scheduling Hard and Soft Real-
Timi:”. Communication in the Controller Area
VIII. REFERENCES
Network (CAN) in Proeedings. of 23rd IFAC/IFIP
Workshop on Real Time Programming, Shantou,
[I] CAN2,OSpecification.R. Bosch Gmbh, 1991.
China, June 1998.
[2] CANOpen. CAL-based Communication Profile. CIA
Draft Standard 301. P. A. Murphy. The Next Generation Networking
Paradigm: Producer/Consumer Model. Dedicated
[3] Controller Area Network. CAN in Automation Systems Magazine, 2000 Q1.
Homepage.
B. Perrin. “The Art and Science of RS-485”, Circuit
http://www.can-cia.de/canl
[4] J. Butler. “UARTs make possible low-cost networks .
Cellar online, July 1999.
T.P. Robbins et al. “Some Advances in Control for
of embedded systems”, EDN Magazine, March. 1995.
Telecommunication Power Systems”, in Proceedings
[5] A.J. Formichelli. “Use the PC’s UART With 9-Bit oflNTELEC 2001.
protocols”, Electronic Design, December 1998.
1171 C. Szydlowsky. Tradeoffs between Stand-alone and
[6] T. Fuhrer and B. Muller. Time Triggered Integrated CAN peripherals, in Proceedings of I n
Communication on CAN. R. Bosh Gmbh, 2000. International CAN Conference. 1994.
[7] F. Hanvitch. CAN Network with Time Triggered J. Urmtia. Estudio y desarrollo brisico de bus serie
Communication. R. Bosh Gmbh, 2000. para supervisidn y control distribuido de sistemas de
alimentacidn de emergencia. E.P.S. Mondragon
[8] J. M. Hawkins. “Characteristics of Automated Power
System Monitoring and Management Platforms”, in Universitatea. End Term Project, 2001.
Proceedings of INTELEC 2000. J. Vo. A Comparison of Differential Termination
[9] H. Kopetz. Design Principles for Dish-ibuted Techniques. National Semiconductor, app. note AN-
903, 1993.
Embedded Applications. Kluwer Ac:ademic
Publishers, 1997. H. Zelwanger. An Inside Look at the Fundamentals of
CAN. Control Engineering, 1995.

2386