Leveraging the Web: A Universal Framework for Building ...

beehuntervivaciousSoftware and s/w Development

Jul 14, 2012 (5 years and 3 months ago)

327 views


Abstract— Building automation systems today employ an
array of communication protocols, data formats, and software
platforms. Some of these are proprietary, others are
standards-based, but in neither case can true integration and
interoperability be achieved. We describe a new framework
for building automation that is based on multiprotocol
network devices and a common object model and that
leverages the Web to enable heterogeneous building
automation systems to be rapidly and efficiently implemented
and managed. Applications of this framework to energy
management, equipment monitoring, and demand-response
strategies are outlined.
I.I
NTRODUCTION
uilding automation architectures are often
structurally complex and hierarchical because of
the variety of different protocols and
communication media used for different functions and for
different manufacturers’ equipment. Integration of
heterogeneous equipment requires extensive use of
multiple toolsets and gateways and extensive custom
programming, limiting the economic viability of such
integration. Building management systems thus tend to be
either single-vendor-based or a combination of products
from different vendors that is not well integrated.
Whereas legacy systems were generally based on
proprietary integration mechanisms, more recent systems
follow emerging standards. However, this has only
exacerbated the problem because of the fact that the
standards themselves have not been designed to
interoperate. In reality, the recent push toward standard
protocols has created more “languages” that need to be
integrated instead of fewer. The number of legacy devices
also implies that wholesale replacement of all the
automation components in a building is untenable. We
need a solution that can accommodate the multitudes of
both new standards and legacy systems—an automation
framework that brings together all embedded devices, old,
new, standard, or otherwise, into a single environment that
T. Samad is with Honeywell Laboratories, 3660 Technology Drive,
Minneapolis, MN 55418, U.S.A. (tariq.samad@honeywell.com). B. Frank
is with Tridium, Inc., 3951 Westerre Parkway, Richmond, VA 23233.
acts to shield the user (and software developer) from the
distinctions between different systems.
In this paper we describe a recently developed approach
to building automation that overcomes the hurdles of
multiple, incompatible protocols prevalent in the industry;
that allows devices from different manufacturers to be
integrated together seamlessly within one automation
system; that simplifies the configuration, monitoring, and
maintenance of heterogeneous systems with a unified
toolset accessible from a browser by an authorized user;
and that enables high-value applications such as energy
management and remote monitoring of equipment. This
approach has been developed (and is now deployed in a
large number of commercial applications) by Tridium, an
independent business entity of Honeywell International Inc.
We first describe the two main elements of the approach:
a class of Java-based network devices and a software
infrastructure and object model, Niagara AX. Next, we
sketch how novel, distributed building automation
architectures can be composed using the new approach.
Before concluding, we review some applications that have
been developed based on this new automation framework.
Portions of this paper are taken from white papers and
other material on the Tridium Website [1].
II.I
NTELLIGENT
M
ULTIPROTOCOL DEVICES
Networked devices are, of course, already widely
available for building management. However, today’s
devices are vendor- and/or protocol-specific; they have
been designed to operate in specific types of
communication networks, such as BACnet, LONworks,
MODbus, and Cbus.
In order for vendor- and protocol-agnostic building
automation systems to be developed, intelligent network
devices are needed that can accommodate different
communication protocols. The new automation framework
described in this paper includes a family of such devices,
called JACEs (for Java Application Control Engine, Figure
1) [2]. As shown, JACEs use x86 or Power PC processors
running a variety of real-time operating systems. Fieldbus
drivers can be provided for any of the broadly used
standard or proprietary networks. Communications at the
enterprise level can rely on a variety of protocols as well,
Leveraging the Web: A Universal Framework
for Building Automation
Tariq Samad and Brian Frank
B
Proceedings of the 2007 American Control Conference, New York City, July 11-13. Copyright AACC 2007.
including HTTP, OPC, and SOAP. For communication
among Niagara components, a new protocol, Fox, has been
developed. One JACE device can connect to multiple,
diverse control networks (physical ports are provided for
different connectors).
JACE devices also host Web servers. This feature
allows devices to be monitored and configured directly
from a browser where security privileges permit. A JACE
component can serve up Web pages including graphics,
parameter values, and configuration screens. Configuration
information is not only for the JACE device—lower-level
equipment (e.g., regulatory controllers, sensor transmitters)
connected to the JACE device can also be configured
remotely.
III.A
COMPONENT
O
BJECT
M
ODEL FOR
B
UILDING
A
UTOMATION
JACE devices provide the hardware and protocol
interconnectivity required for a “universal” building
automation system. But interoperability is also required at
a semantic level—for example, a temperature measurement
communicated by one sensor must be recognized as such
by a temperature controller even if the two components
speak different protocols and are from different vendors.
This semantic interoperability is also essential to allow the
same tools to be used for monitoring and configuration—
regardless of how this information is encoded or
communicated.
The Niagara framework includes a “common object
model” that provides this capability. The object model is a
hierarchical composition of concepts in building
automation, from the elementary level of simple data types
to abstract concepts such as communication sessions and
control schedules. Figure 2 shows a part of the Niagara
AX class diagram representing the object model.
The common object model can be thought of as a
uniform, normalized database of objects for the user or
application developer to work with. The database becomes
the platform through which other applications interact with
the various systems. On top of this object database the
infrastructure provides a set of general services such as a
real-time control engine, scheduling, alarming, and Internet
connectivity (see Figure 3).
The common object model, which has access to all of the
data and actions supported by the diverse systems, can now
serve as a foundation for other software applications that
provide value to the operation of the facility. Software
elements can be developed once and re-used in multiple
applications. The component-based design of the
framework eliminates the need to create dedicated
applications, with separate development effort, for each
system. An extensive library of components that addresses
the majority of application needs is also available.
The common objects also make it easy to build browser-
based displays, reports, alarms, and even supervisory
control logic that works across the multiple systems. The
result is true interoperability without the need for users to
get mired in the details of competing protocols and without
the need to disturb the installed systems.
This approach also allows system expansion through the
addition of existing device types while at the same time
enabling expansion with devices based on new and
emerging protocols. It provides the owner with the ability
to choose “best of breed” smart devices and systems.
The object model is, in a sense, a metaprotocol. It is
itself evolving into a standard, oBIX, that is part of an
industry-wide initiative to define XML and Web services
mechanisms for communications between building control
systems and enterprise software applications [3][4].
IV.N
IAGARA
-E
NABLED
S
YSTEM
A
RCHITECTURES
Examples of this new building automation architecture,
illustrating the use of JACE devices as intelligent gateways
for integrating multiple networks and types of devices, are
shown in Figure 4. As illustrated, the architecture is
scalable and can be used for applications ranging from
single buildings to multiple, geographically dispersed
facilities.
This new approach to building automation provides
several benefits to building owners and operators:
customized systems with components and subsystems from
different vendors can be readily implemented; the
configuration and commissioning time and cost associated
with building management systems can be substantially
reduced; systems can be monitored and controlled
remotely; and information from multiple facilities can be
centrally accessed for comparisons and identification of
best practices.
V.A
PPLICATIONS
The combination of JACE devices and the Niagara AX
framework provides the elements needed for developing
high-value applications for building automation. Such
applications can be developed by customers and third
parties and several have also been developed by Tridium.
We briefly describe some of these available applications,
packaged in the Vykon Energy product, below. Case
studies of theses and other applications are available on the
Web [5].
Remote Monitoring and Control. Being notified that
events occur in real time is beneficial, but without the
ability to make changes and avoid ramifications, the
notification means little. With Vykon Energy users can log
onto a standard web-browser to alter schedules, change
setpoints, and adjust mechanical system control parameters
(Figure 5 [left]). Because Vykon Energy is based on the
Niagara Framework, the type of system users are
communicating with is transparent. Whether a chiller, an
air handler, or a lighting panel, the user interface is the
browser and can be accessed from anywhere at anytime.
Profiling with Normalized Data. Vykon Energy
provides a robust and flexible profiling application through
which users can trend and analyze values such as energy,
temperatures, production, and facility data. With such
information, users can determine how buildings,
mechanical systems, and other variables affect one another.
The Web-based user interface is a user-friendly application
that turns logged data into useful and actionable
information. Users can compare meters to one another to
determine the most and least efficient strategies and
buildings. Figure 5 (right) profiles main electric and gas
meters and normalizes data for outside air temperature
(OAT) and floor area. The user can determine the
correlation between OAT and HVAC with results
presented in the scatter plot. By comparing energy
consumption between buildings an energy services
company can determine the most efficient strategies.
Correlations make it possible to determine the effect one
variable has on another.
Comparing Pre-retrofit with Post-retrofit Results. Users
can compare a meter versus a historical baseline or
imported data. A user can choose to compare lighting from
several facilities versus historical results. Because days of
the week do not align between months weekends can be
eliminated from the evaluation. By comparing a lighting
meter prior to and following a retrofit and eliminating
weekends, savings from lighting or other energy efficiency
measures can be quantified.
Enabling Demand-Response Strategies. In addition to
including external environmental data such as weather and
pricing, Vykon Energy integrates temperature controls,
lighting panels, metering technologies, and other systems
that are consuming energy in an end-user facility. Common
protocols such as Modbus, LonWorks, BACnet, and DNP
3.0, can all be integrated into the demand response (DR)
program. By adding connectivity to proprietary systems,
demand response opportunities are significantly expanded.
Once the pricing signal/curtailment request and the field
devices have been linked, if/then logic can be defined to
automate the DR program. Programming is done through a
graphical interface. Multiple kW readings can be
aggregated and linked to a pricing signal. For example, the
DR program could specify that when the aggregate power
demand is between 5000 and 8000 kW any time between
11:00 a.m. and 4:00 p.m., and the pricing per kWh exceeds
$.50, then lighting should be reduced in zone 1, the
temperature setpoint in zone 8 should be offset by 3
degrees, and an available microturbine should be turned on.
VI.C
ONCLUDING
C
OMMENTS
Niagara AX has been adopted in multiple markets to
create solutions for real time monitoring, control and
machine-to-machine applications. Today over 50,000
instances of Niagara are operating in over 6,000
installations worldwide supporting applications like energy
management, building systems automation, maintenance
repair operations (MRO), service bureaus, total facilities
management, and “cradle-to-grave” product support
services.
Future work is focusing on several fronts. We note two
here. First, the framework described can be used to
enhance the enterprise-level integration of building
automation devices. A proposed architecture, which
exploits features of the IEC 1499 standard and IBM’s
WebSphere technology, is shown in Figure 6.
Second, variations of the problems with current building
automation systems that we sketched earlier can be found
in other automation domains as well. The automation
framework we have presented is not likely to be suitable
directly for many of these domains, but the concept of a
framework that incorporates multiprotocol devices, a
semantic object model, and World Wide Web integration
is, we believe, relevant.
R
EFERENCES
[1] “Tridium,” available online at http://www.tridium.com.
[2] “JACEm” available online at http://www.tridium.com/cs
/products_/_services/jace.
[3] “oBIX: Open building information exchange,” available online at
http://www.obix.org.
[4] B. Frank, “The oBIX M2M web,” available online at
http://www.automatedbuildings.com/news/jul06/articles/tridium/
060620121505obix.htm.
[5] “Case studies,” available online at http://www.tridium.com/cs/
library/case_study_main.
Figure 1. Niagara JACE architecture
Figure 2. Part of the Niagara AX class diagram
Figure 3. Integration of communications, the common object model, and services

Figure 4. Web-enabled architectures for building management systems
Figure 5. Application screenshots for remote monitoring (left0 and energy consumption profiling (right)
Web-server with dynamic
data/e-mail alarming, etc.
Internet connectivity –
TCP
/
IP
,
HTTP
,
SNMP
Data logging, archiving
Real-time control
loo
p
s
/
schedules
/
alarmin
g
Java Component Object Model
LON, OPC, MODBUS, BACnet, Legacy, etc.
User interface/data
Presentation
Internet connectivity
Information
management
Control functions
Data normalization
Device-level
communications
Inte
g
rated
,g
r a
p
hical dev toolset
Figure 6. Proposed enterprise architecture based on Niagara/JACE