Download Re-inventing wireless building automation for

Reinventing Wireless Building Automation for Smaller/Retrofit Jobs
The centralized approach to building automation systems limits small-scale, retrofit and limits
local deployments because of the large overhead. A new decentralized/embedded approach to
automation topology and multi-protocol integration can deliver wireless automation’s economic
benefits to this underserved market.
by Simon Leblond and Hami Chanon, SCL Elements
A building automation system can save money by lowering labor, power and other costs. It can
also enhance occupants' enjoyment of the space through optimized climate control, a more secure
environment, etc. This translates into potential economic benefits of higher rents and/or a lower
vacancy rate. When asked why a building automation system has not been installed, an owner
will typically point to one obstacle: cost. This cost typically stems from three sources: hardware,
installation and integration. The price of hardware has fallen in recent years, so specialized labor
generally accounts for the largest share of deployment cost.
New wireless technologies offer breakthrough savings on installation and maintenance, but bring
their own troubles. In particular, new protocol support demands integration and human
intervention for interoperability between devices and networks. Current solutions to protocol
integration, such as Tridium’s Niagara AX or Schneider’s TAC Vista, rely on a central, shared
platform in the form of a dedicated server or networking device. This approach works best for
large implementations that can justify up-front costs of setup, software licensing and dedicated
hardware. It leaves an underserved market of properties that require small-scale,
retrofit/expansion and local deployments of wireless building automation systems.
If we assume that building automation systems will leverage the benefits of wireless
communication, then we must ask what protocol(s) best delivers the needed reliability,
interoperability and flexibility? What combination of network architecture, hardware and
software is ideal, given limited capital budgets and lack of dedicated system administration staff
in smaller-scale deployments?
From this examination, a picture emerges of building automation that is radically different from
the current approach. A key part of the solution is decentralization, with system “intelligence”
devolved to controllers. Another guiding idea is embedded—all formerly server-based functions,
including control, communication, protocol integration and even data management, are
incorporated within controllers’ real-time software. Another characteristic is multi-protocol, with
the system leveraging the best features of heterogeneous standards (namely ZigBee, EnOcean,
CANbus and BACnet/IP).
The Challenge: Control System Functions
Conceptually, a Control System performs four functions: data management, communication,
control and “intellectualization,” as shown in Figure 1. Data management involves storing and
retrieving data for internal (network) and external (user) needs, and presenting selected data to
users. This is typically performed by a server-based database and client software. Local data
storage at the controller level is generally limited to control variables. Communication implies
data exchange between network components as well as between networks. Dedicated networking
devices manage communications and are overseen by the server. Interconnection between
networks and/or protocols may involve additional dedicated equipment (bridge, bus) or software.
Control is performed at the field level. Dedicated controllers are used to implement command
strategies and interact with the physical world. And finally, intellectualization is the
“intelligence” needed by a system to solve, interpret or otherwise translate inputs into a
command or an action.
A Control Network also traditionally combines multiple “control levels,” each requiring a
different type of equipment. A typical architecture calls on three general types of equipment:
server, networking and controller. Figure 2 illustrates several of the major cost factors in
traditional building automation. First, all those varied pieces of hardware must be purchased!
Second, skilled personnel are needed to make devices talk to each other by wire or wirelessly.
Note that the control functions shown in Figure 1 are spread out across the different levels and
devices of Figure 2. Data management “lives” on the server. Control resides within the
controller. With every new deployment, integration must take place both within the
communication function (cross-network / cross protocol integration) and between functions
(network / device integration).
Yet another implied cost in Figure 2 is bandwidth. Most existing controllers are dumb, relying on
round trips to the server or PLC for changes in variables and any other “intelligence.” Protocol
integration is performed on the server, so that system functions requiring interoperability must
communicate through this central point. Bandwidth demands can quickly overwhelm the
resources offered by ZigBee and other wireless personal area network (WPAN) standards.
The Solution: “Smart” Controllers, Decentralized Control Networks
A new approach, oriented toward smaller and retrofit deployments, gathers previously dispersed
functions onto the controller itself. Embedded controller software enables collaboration by
providing a common high-speed data exchange scheme for all functions referred to as the
“sharing kernel,” as presented in Figure 3.
Characteristics of the functional modules within this architecture include five elements. The first,
the communicate module, is the network’s protocol converter and runner and is embedded in the
controller as an embedded software package that interacts with the other modules through the
kernel. It can convert to/from multiple protocols, as long as necessary drivers are provided. The
communicate module also replaces dedicated networking equipment such as routers and bridges.
It is “aware” of other controllers, and contains full network mapping.
The intellectualize module handles the task of implementing a sharing kernel for its controllers.
The controller is guided by processes defined in a lightweight scripting language. The language
must offer relatively simple syntax and a good syntax checker that enables non-programmers to
configure building processes such as scheduling the operation of a HVAC system. For this
function, SCL Elements has found the Lua scripting language to provide the required
combination of performance, ease of use and resource demands (memory and CPU). A Lua
extension called LuaC (Lua for Control) was developed to add useful libraries and tools,
including a real-time task scheduler that allows easier handling of time-based functions in
building automation systems.
The manage data module is the memory of the embedded controller. Managed data includes
control variables and history, state and communications/routing data. The module can filter or
format records quickly, and provide results to the other modules through the sharing kernel.
Challenges include providing data management with the reliability and sophistication of a true
database management system (DBMS) while avoiding the size and performance overhead of
DBMSs that are designed to store records on permanent media. In SCL Elements’ controllers,
eXtremeDB from McObject was successfully used as an embedded in-memory database system
(IMDS). eXtremeDB’s in-memory storage avoids the file I/O, cache management and other
overhead inherent in on-disk database storage, and elimination of these functions results in a
streamlined architecture with a code size under 100K. This is a remarkably small “footprint,” and
it enables deployment of a full-featured database system on every controller.
The database contains everything from temperature sensor values to ventilation control motor
speeds, to spatial location and network interfaces and addresses for the various nodes. For
managing networking data, a useful eXtremeDB feature is its support for the Patricia trie, a
specialized database index that is particularly effective in sorting hierarchical data such as IP
addresses.
The role of the control module is to implement the controller’s physical interaction with the
outside world, managing electronics input/outputs and handling any electronic interface. It is also
responsible for applying user-selected control strategies (PID Sets, Neural Networks). At the
center of these modules is the sharing kernel, which is responsible for interaction between any
internal or networked functional modules.
Under this design, smart controllers do the work previously performed on the server, PLC and
other components, and in fact, eliminate the need for these other devices. Functions that
previously required round-trip communication with the system’s “brains” are now handled on
controllers. The tree-like layout of existing building automation systems is flattened to just two
levels: smart controllers that communicate among themselves, and with end devices such as
HVAC and lighting systems.
Because every controller has the intelligence to work autonomously, a control system can be
initiated with just a handful of controllers. Gone are the server software licensing,
internetworking and other up-front costs. Software functions are embedded, removing much of
the integration chore. Elimination of these obstacles makes this a cost-effective solution for
smaller buildings. To a large extent, the data set managed by the eXtremeDB embedded database
on one controller is duplicated on all others. This provides resiliency: in the event of failure, a
controller can be reprovisioned or replaced by another unit on the network. But this flattened,
server-less architecture populated by smart controllers is only part of the solution.
Communication: Supporting a “Dream Team” of Standards
Wireless control systems generally, and wireless building automation networks in particular,
offer a jumble of available communication protocols. Supporting all would require overly
complex integration logic, driving up controller hardware costs. Allowing too few eliminates
interoperability as well as strengths residing in specific standards. SCL Elements analyzed the
tradeoffs and assembled a “dream team” of protocol support on a single wireless controller
board, optimized for cost-effectiveness, reliability and efficiency.
The EnOcean wireless bus allows communication with battery-less and ultra-low-power devices,
at distances of up to 50 meters from the controller. Typical uses include switches, relays or
thermostats. The data rate is low. Major benefits include no power requirements for controlled
devices, and elimination of cabling cost.
The ZigBee protocol covers a wider wireless range through meshing. It is used for
communication between controllers, including collaboration through the sharing kernel.
ZigBee’s mesh network design adds resiliency: if one network node (controller) dies, the rest can
remain active. ZigBee also handles communication between controllers and powered devices
(plug-in and battery). The greatest challenge that people will point to in this design is limited
available bandwidth. SCL Elements' solution, called CAN2GO, addresses this in two ways. First,
the decentralized network design in itself frees bandwidth by eliminating a great deal of network
traffic centered on the server. Second, data exchanges are implemented over an open binary
XML scheme tagged as BInary LIquid XML—or BILI for short—which enables bandwidth
preservation as well as easy communication monitoring.
The CANbus is used for wired local communication when high data rates and high reliability are
required, or where wireless communication is impossible, such as in Faraday cage conditions.
For example, a point-to-point connection might be implemented through a particularly thick
wall. Instead of setting up a separate, wired network, two sections of a wireless network can be
connected via a single wired connection. CANbus can also be used to mechanically add
extension modules on the fly to provide additional functionalities (I/O, interface, etc.) to the
system.
With its origins in automotive networking, CANbus is highly reliable and can transmit a signal
more than a full kilometer without amplification. While CANbus is new in building automation
systems, the embedded protocol integration within each controller makes it a plug-and-play
proposition for integrators, with CANbus becoming “just another port” on the controller.
Ethernet/IP, of course, is the building automation system’s “window” onto the outside world.
Through this protocol, the system can be plugged into a LAN interface with Building
Automation and Control net (BACnet/IP)-compatible hardware or software, SQL databases and
with applications that consume XML or support OLE for Process Control (OPC). Ethernet/IP
enables access to an embedded Web-based GUI, which in CAN2GO provides the management
interface for entire building automation systems. Because all controllers are connected, Webbased access to one node enables the user to “see” all other nodes and to accomplish tasks
ranging from configuring controllers, to designating a master schedule for a property’s HVAC,
lighting, security systems. BACnet/IP compatibility ensures seamless integration with existing
building automation infrastructure.
The CAN2GO solution relies on some “pieces” that are open standards (EnOcean, BACnet,
ZigBee); several third-party components (the eXtremeDB in-memory embedded database, Lua
scripting); and a few patented elements. The most dramatic change from the past, though, is
likely the ability to migrate processing intelligence from servers and PLCs to controllers, and the
resulting flattening of the network. This model is shown in Figure 4 and we believe it represents
the future of building automation systems.
SCL Elements, Montreal, Quebec. (514) 313-8885.[www.can2go.com].
McObject, Issaquah, WA. (425) 888-8505. [www.mcobject.com].
EnOcean, Boston, MA. (801) 943-3215. [www.enocean.com].
ZigBee Alliance. [www.zigbee.org].
CANopen. [www.canopen.us].