Industry and Technology

Why BMS not PLCs for

Building Automation?

Modern building automation solutions are required to

fulfill many often diverse and demanding objectives.

Foremost among these are the need to provide comfort,

security and energy efficiency. Depending on the purpose

of the building, facility, campus or enterprise, other

common requirements include: fire detection and life

safety assurance, enterprise system integration,

regulatory compliance support, critical parameter

and cleanliness level maintenance, data logging and

alarm management.
INTRODUCTION
In recent years some debate has arisen as to whether Programmable Logic Controllers (PLCs) are suitable as
an alternative to Building Management Systems (BMSs) to meet these needs. This paper is intended to
provide a concise historical review of the technologies and an objective comparison between the two solution
platforms, their relative merits and application suitabilities.

SOME EARLY HISTORY

The PLC was invented in 1968 by Richard Morley and his colleagues within Bedford Associates, a
small, New Hampshire based engineering consulting firm. The Modicon (Modular Digital Controller)
Company was incorporated in 1969, building a substantial business around these new devices. The
initial sales success of PLCs was in the area of transfer lines in automotive plants. Over the years the
capabilities and application scope of PLCs have dramatically increased but automotive manufacturing
remains their most significant market. Nearly four decades later, the PLC is arguably the most widely
used product type in the industrial automation business, with a worldwide market of several billions
of dollars per year and available from hundreds of different sources, in many different form-factors
(including embedded) and prices ranging from tens of thousands of dollars (for triple redundant,
failure-proof systems) to commodity, catalog products at less than a hundred dollars.

In 1975, Mr. Morley was also a founder of Andover Controls. This company’s first product, the
Sunkeeper, was targeted at the solar energy management market and introduced the world’s first
Direct Digital Control (DDC) system. The company’s products quickly evolved encompassing much
wider building management responsibilities. The product lines included the highly successful AC256
introduced in 1981, the Infinity system which debuted in 1989 and the currently available Continuum
system which followed in 1997.

One may speculate as to why PLCs were not simply applied to building management applications
from the very beginning. Were business and technical needs left unmet, giving rise to building
automation companies such as Andover Controls? The simple
answer is yes; the deficiencies of PLCs for building management
applications effectively spawned the modern digital Building
Management Systems market. Indeed, in a recent interview with Mr.
Morley, he explained “anyone trying to apply PLCs to building
automation applications is investing in excessive, divergent
performance.”

Today, both of the product heritages of Modicon and Andover

Controls are owned by Schneider Electric, the world’s power and
control specialists. This uniquely privileged position allows us to
present a fair and balanced comparison between these two
Richard Morley with the world’s categories of powerful automation solutions.
first PLC, the Modicon 084.

KEY REQUIREMENTS DIFFERENCES

It should be kept in mind that a fundamental difference in design intent exists between BMS and PLC
systems. BMS systems are primarily intended to control and protect the environment around people,
physical assets and data. PLC systems are primarily intended to control and protect the production
capacity of machines and manufacturing lines. This basic distinction underlies many of the following
comparison points – not just in terms of the enabling technologies but also the types of companies
and people involved in the successful completion of building automation projects and the ongoing
service and maintenance of these systems.

2
 Object Oriented BMS

PLC

Bits & Bytes

Machine Efficiency Human Comfort & Safety

SYSTEM TOPOLOGIES
Buildings are big. Space control requirements can range from a few hundred square feet well into the
millions. This space may be distributed across several buildings of a campus or even many multi-
building facilities across a country or continent. BMS systems have evolved to meet this type of
control challenge. PLC systems are usually physically limited to a single machine or production line
within a single building.

NUMBER OF USERS
BMS systems are designed to have many users with diverse needs interacting with the system on
several levels through multiple devices. This can range from an office worker changing the setpoint
on their local thermostat through to a Facility Director viewing plantwide energy efficiency statistics
through a web browser. Configurations supporting various classes of users with a wide range of
privilege sets are common. From an all-powerful administration account through to read-only access
to a few points on a single screen, modern BMS systems can easily be configured to provide vastly
different users experiences to a common system depending on the location, function and authority
level of the various user types.

In contrast, PLC systems often have only very localized user interfaces. This makes sense because of
the need for close proximity of the operator to the machine to verify its correct operation and to
perform mechanical maintenance. Where connection to enterprise systems is provided it is often
through standardized interfaces such as OPC. 3rd party SCADA vendors provide many of the system
level views of PLC-based configurations.

3
DEGREE OF DETERMINISM
Generally speaking, BMS systems operate around “human” time. Air conditioning control sequences
are triggered by occupancy conditions and the comings and goings of facility area occupants are
captured in familiar time/date formats.

In contrast, PLCs are usually designed to operate in the 1-50 millisecond scan-time range and are
generally concerned with “machine” time (i.e. their operation is based upon mechanical and electro-
mechanical system dynamics.) As a consequence, all other functions are subjugated to logic and I/O
processing in order to ensure highly deterministic system operation. BMS systems are typically more
adaptive in that they give communications functions a much higher priority. Part of the reason for
this is that the individual controllers have been designed from the very outset to be part of a larger
system and hence awareness of their availability and ability to interact with the rest of the system is
fundamental to the overall system operation.

An example of an important difference in communications approaches between the two types of

systems is that BMS’s, along with regular I/O scanning mechanisms, have long featured (over 20
years) built-in “report-by-exception” capabilities.

Three types of information can be reported by exception:

1. Alarms
2. Change of value
3. Object attributes referenced by other controllers

This mixed scanning/exception reporting approach makes highly efficient use of communications
bandwidth, thereby delivering optimal system performance, while only minimally impacting overall
system determinacy.

Although both BMS and PLC field controllers can function in a standalone manner, it is much more
common for PLCs to act as localized “islands of automation.” While there is a very significant trend in
networking PLCs over various fieldbusses, they remain far more functionally isolated than controllers
in a typical BMS installation.

ALARM DETECTION AND MANAGEMENT

Alarms within BMS architectures are generally detected at the field controller level. The various
alarm limits and notification destinations (where the alarms should be sent) are basic attributes of
the monitored values and are distributed and processed as close to the signal source as possible. In
PLC-based architectures alarm management is almost always performed only at the SCADA level.
While functional, this is a far less robust approach, as the workstations are much more likely to
become unavailable than the PLCs. Another disadvantage to this approach is that transient alarm
conditions are far more likely to be missed because of the communications overheads and
asynchronous task processing of the two system levels.

DATA LOGGING
BMS systems are often used to provide both short and long-term records of environmental
parameters. Great quantities (1,000s) of these “logs” can be stored near their signal sources within
distributed field controllers as well as being aggregated in more centralized database resources. BMS
systems are designed to automatically provide this capability with simple configuration options. Of
course, PLCs have local storage capabilities but are generally oblivious to “human” real time (time of

4
day etc.) and a great deal of custom application programming is required to even approximate the
logging functionality natively available within a BMS field controller.

NATURE OF THE MEDIUM

One often overlooked attribute of the air handling aspect of building automation is that the medium
under control (the air) affords the control system a degree of natural “fault tolerance.” BMS
architectures are designed to allow subsystems to be temporarily taken out of service for
maintenance or repair without dramatically impacting the quality of the overall environment. This is
due to the fact that other operational subsystems will generally compensate for the non-functional
unit. The overall system may be temporarily unbalanced but a comfortable environment is normally
maintained. BMS systems have evolved to anticipate such circumstances. In contrast, systems
controlled by PLCs are usually rendered entirely inoperable should the PLC fail.

PURPOSE BUILT = LOWER INSTALLED COST

When contrasting the I/O types of PLC and BMS systems it soon becomes evident that the BMS I/O
is, not surprisingly, more adapted to control the types of devices commonly found in air handling and
security management applications. For example, BMS field controllers are available with built-in
airflow sensors and damper actuator motors. These controllers are purpose-built to be mounted
directly onto ductwork. No equivalent to this exists in the PLC world.

Another feature of BMS field controller I/O is that of built-in signal conditioning. This often
overcomes the need for separate and expensive signal conditioning blocks. A variety of signals from
input devices such as thermistors and airflow sensors are characterized directly within the firmware
of the I/O module to provide the software with linearized SI and Imperial standard signal
representations. In most PLCs, costly, specialist I/O modules are required to perform the equivalent
task. It is also very common for BMS field controller I/O to feature built-in manual override switches
and potentiometers - so called Hand/Off/Auto switches. These are extremely useful during system
commissioning and servicing and when a controller is temporarily offline from the rest of the system.
It is very unusual to find this feature in PLCs.

+
Airflow Sensor
+
Actuator
+
Room Sensor
+
Signal Conditioners
+
Lots of Engineering
+
Enclosure (Plenum-
mount)

PLC – High Installed Cost

5
Thermistors are a good example of fitness-for-purpose of sensors in building automation
applications. As PLCs became applied to an ever widening range of industrial control applications, the
absolute and range of temperatures they became expected to monitor and control were only able to
be provided from thermocouples. Thermistors, on the other hand, while less linear are far more cost-
effective and practical for the temperatures typically encountered in building automation
applications. In fact, one of the earliest and still very evident differentiators of PLCs and BMS field
controllers is in their ability to natively condition thermistor signals.

INTEGRATION NOT INTERFACING

PLC’s are sometimes interfaced to a few complementary automation devices. This frequently requires
custom coding and significant engineering time. In comparison, BMS’s usually support extensive,
native integration capabilities and are often tied to dozens of facility subsystems. As shown below,
such subsystems include: power, utilities, process, security and life safety. The BMS can also form a
consistent means to integrate with higher level enterprise business applications such as
Manufacturing Execution (MES) and Enterprise Resource Planning (ERP) systems. For example, to
support security integration; BMS systems have dedicated I/O modules to perform functions such as
door controls. Along with dedicated digital I/O (request to exit, door strike etc.), these modules
incorporate specialized communications protocols (such as Weigand) that allow easy integration with
a huge variety of ID verification devices including proximity card readers and biometric recognition
devices.

SOPHISTICATED OBJECT MODEL

BMS are built around a sophisticated, distributed software object model. The system database holds
a complete topological map, data/program image and revision history for every physical and logical
entity within the system. This approach supports a high degree of automatic configuration
management. The object types themselves range from simple discrete I/O to complex compound
objects such as doors. While outwardly a door may appear to be a simple control object, dozens of
attributes may apply to each instance.

REGULATED INDUSTRY APPLICATIONS

In highly regulated industries such as pharmaceutical and medical device manufacturing, a common
requirement is to be able to provide proof of compliance with regulations through the use of
automated systems. A clear advantage of BMS systems in this area is that they are database centric.
PLCs are local memory centric. This means that a BMS has a far greater capacity to keep long term
records of all critical facility related events and parameters. Indeed, a fundamental requirement of
the Electronic Records and Signatures regulation (21 CFR Part 11) is that comprehensive audit trails
be maintained. The database centric nature of a BMS makes this a straightforward task to
accomplish. In contrast, the limited local memory of a PLC has little, if any, capacity to capture this
critical information.

6
THE MYTH OF IEC 61131-3
The IEC standard 61131-3 has been available now for over 15 years. The intention of this standard is
to provide a high degree of basic functional uniformity from the control products of industrial
automation systems manufacturers. The idea was that system users would be able to create rich,
vendor-independent libraries of reusable control code.

While this is a commendable objective, it has met with limited success. From a building automation
standpoint a fundamental problem is that the standard is written around the use of traditional PLC
programming languages and software structuring tools - Ladder Diagram, Function Block Diagram,
Instruction List, Structured Text and Sequential Function Charts.

These languages are well suited to machine and production line applications but not to BMS
applications. They are not particularly object oriented and do not intuitively map to common BMS
control requirements.

Another major problem is that the IEC 61131-3 languages are extensible. This means that the
different manufacturers can and do create proprietary extensions to their implementations which
severely limits the degree of portability and reusability of any application code developed.

NETWORKING DIFFERENCES
BMS and PLC networks have evolved separately and differently. Today almost all BMS manufacturers
offer systems based on either or both of the open standards, LONWorks and BACnet. These
communications standards are sophisticated, well-defined and their implementation is well
controlled. This affords BMS users a high degree of integration capability. These networks natively
support the object types and services required by the building automation world. LONWorks and
BACnet are also natively supported by a wide range of complementary devices such as variable
speed drives, power monitoring and metering equipment and lighting controllers.

The network standards prevalent among PLCs are generally less sophisticated and rooted in the
proprietary technology of the larger vendors. Profibus and DeviceNet are good examples. While these
network technologies are highly functional for machine automation applications, they are
cumbersome to implement and not a good fit for building automation applications.

DON'T PAY FOR WHAT YOU DON’T NEED

As PLCs were originally invented to replace cabinets full of electro-mechanical relays situated near
(and sometimes even on) production equipment, it was imperative that they were able to withstand
the electrical and mechanical rigors of these harsh environments. The I/O boards of PLCs therefore
generally feature a high degree of channel to channel isolation, electrical noise suppression capability
and mechanical ruggedization. Some models even allow defective I/O modules to be replaced under
power or so-called “hot-swapped”. While these features are necessary for such industrial control
applications, they do add significant cost to the design of PLCs. BMS field controllers have been
designed to operate in the utilities environment of a facility which is typically far less severe. The
electrical and mechanical design of BMS field controllers has therefore evolved to be better suited to
such conditions. A significant commercial advantage of BMS field controllers over PLCs is that the
user does not pay for a degree of product ruggedization unnecessary for the application.

7
 PLC Æ Program BMS Æ Configure

EASE OF SOLUTION
Perhaps the greatest single advantage of BMS over PLCs falls in the area of “ease-of-solution” or
engineering costs. As the workhouse of the industrial automation world, modern PLCs are
undoubtedly highly flexible and reliable devices. Given the target physical application domain of
facility management, there exist no significant reliability difference between BMS and PLCs. However,
a tremendous difference does exist in application engineering time and costs. In part due to the very
flexible nature of PLCs, the amount of work required to perform even rudimentary facility automation
tasks with these devices can be many times that required when employing purpose-build BMS
solutions. For example, consider the work involved in setting up a control sequence for a fan-coil unit
application as shown in the figure below. This would require a great deal of bespoke code
development in a PLC while a BMS controller would only require straightforward configuration of its
built-in functionality.

8
CONCLUSION
PLCs and BMS have evolved into powerful automation solutions. PLCs are extremely versatile and
with enough effort can be used to meet the needs of almost any automation application. BMS, on the
other hand, have a more restricted application domain but a far higher degree of fitness for their
intended application scope. As shown in the diagram below, for small standalone system installations
PLC and BMS costs may be comparable but for larger, more sophisticated installations, overall
engineering, maintenance and operating cost will become increasingly higher for PLC-based over
BMS based systems. Another important consideration is that PLC-based systems will reach practical
application size, complexity and manageability limits long before BMS-based solutions.

High

PLC

BMS
Installed Cost

Low

Simple Application Intelligent

Equipment Complexity Building
Control

Of equal, if not greater, importance than the control equipment used on a building automation
application is the expertise and experience of the organizations and individuals providing system
engineering and support services. It should be recognized that, generally speaking, PLC integrators
typically have no building automation expertise and their staff are traditionally from electrical
engineering backgrounds. In more recent years this type of integrator has been taking on more staff
with software development expertise. Equally, BMS integrators rarely have process or machine
control expertise and their staff are traditionally from mechanical automation backgrounds. In more
recent years this type of integrator has been taking on more staff with IT expertise.

As we have seen, while they have some historical and technical commonalities, PLC and BMS
systems have followed necessarily different evolutionary paths with BMS systems being more highly
adapted to the building management applications domain. Equally, PLCs perform a vitally important
role in the industrial manufacturing and process automation worlds.

9
 High
BMS

Fitness

SCADA
PLC

Low
Applications

It is important to appreciate that these two automation solution platforms deliver complementary
functionality. As industrial processes and the surrounding environments of the machines and people
that control them are increasingly recognized to be interdependent, integrating PLC and BMS
systems is becoming ever more common. Fortunately, straightforward integration is facilitated by
many network protocol, software interface and database standards such as Modbus, TCP/IP, XML,
OPC, SQL and ODBC.

10
The following diagram summarizes the key differences between PLC and BMS systems for use in
building management applications.

PLC BMS

Centralized architecture Distributed intelligence

Single point of failure High availability & resilience

High installation costs Low installation costs

High engineering costs Low engineering costs

Limited connectivity Good connectivity

Very limited sub-system Excellent sub-system

integration capabilities integration

Inconsistent support Broad support coverage

Limited channel expertise Excellent channel expertise

General purpose Application focused

Fully programmable Configurable and programmable

Copyright © 2007, TAC

All brand names, trademarks and registered trademarks
are the property of their respective owners. Information
contained within this document is subject to change
without notice. All rights reserved.

WP-BMSvPLC-US
05/07

www.tac.com