Smart-building systems converge
As building-automation data flows onto enterprise networks and the Internet, designers are turning to integrated systems and Web-based services.
By Warren Webb, Technical Editor -- EDN, August 17, 2006
| MORE INFORMATION |
| Click here for more on smart buildings. |
Growing customer demands for open, interoperable subsystems, along with widely available, high-speed information-technology networks, have fueled the transformation of the building-automation sector from independent, mostly proprietary product suppliers into a standards-based industry. As this makeover progresses, building systems such as lighting, environmental, and security can share digital information with each other and with enterprise or Web-based business applications to reduce costs and respond to real-time events. In the future, you can expect smart-building technology that enables multiple structures to automatically respond to adverse weather conditions, energy shortages, nearby fires, or local crime events.
Most smart-building systems comprise a series of distributed sensors and specialized actuators connected to application software running on a local or remote processor. These systems usually have a singular building-automation purpose, such as climate control, security, or fire protection. However, as building systems become more integrated and sophisticated, control algorithms can optimize their objectives with data from external sources, such as other building subsystems, historical data, weather forecasts, and real-time energy pricing.
A major hurdle in the transition to integrated systems is the hodgepodge of communications and networking schemes that building-automation manufacturers traditionally use. Many current building subsystems communicate with standard protocols such as LonWorks (local-operating network) and BACnet (building-automation and -control network) in addition to numerous proprietary schemes. These systems require dedicated wiring between sensors, actuators, and processing elements. Now, with enterprise information-technology networks available in almost all commercial structures, building-automation designers are adapting their subsystems to take advantage of this high-bandwidth datapath. Although designers have adapted some of the building-automation protocols to exchange data with TCP/IP (Transfer Control Protocol/Internet Protocol) networks, many require special gateway devices to extract system-specific information.
Building nets
BACnet, a widely deployed, open-protocol communication standard for building systems, represents data as objects, properties, and services. This standard method of representing data and actions enables devices from different manufacturers to interoperate, although most BACnet devices are limited to the HVAC (heating, ventilating, and air-conditioning) industry. The BACnet standard defines several PHY (physical) layers, including Ethernet, BACnet/IP, and point-to-point over RS-232. BACnet is an ANSI and ISO standard that the ASHRAE (American Society of Heating, Refrigeration, and Air-Conditioning Engineers) maintains.
LonWorks, another popular building-control-system protocol, requires a proprietary Neuron chip or licensed intellectual property from Echelon Corp in each controller. The lighting, utilities, and transportation industries use the low-bandwidth LonWorks protocol, and it has more automated building installations than BACnet. The LonWorks protocol provides a set of services that allows device-application software to send and receive messages over the network without needing to know the topology of the network or the names, addresses, or functions of other devices. An open version of the protocol, ANSI/EIA709, describes the algorithm in sufficient detail to enable operation on a variety of general-purpose processors.
Although TCP/IP is a logical choice for intelligent-building architecture, many systems require a large number of sensors in areas that enterprise networks do not serve. These situations favor networking schemes—such as wireless links, power-line communications, and even telephone-line sharing—that do not require the installation of new interconnecting cables. Another requirement of these isolated sensor nodes is extremely low power. In many remote locations, the sensors must run for as long as a year on battery power alone. These nodes can run on this reduced power because of the low data rates the sensors collect.
IEEE 802.15.4 defines an ultralow-power, low-data-rate wireless-network architecture that is ideal for many smart-building-sensor applications. Operating in the unlicensed frequency bands, the standard defines the PHY and MAC (media-access-control) sublayer specifications for low-rate devices communicating at 20 kbps in the 868-MHz band, 40 kbps in the 915-MHz band, and 250 kbps in the 2.4-GHz band. Networks may be arranged in star or peer-to-peer topologies and include addressing for more than 65,000 nodes. Transmitters use DSSS (direct-sequence spread spectrum) with BPSK (binary-phase-shift keying) in the less-than-1-GHz bands and O-QPSK (offset-quadrature-phase-shift keying) at 2.4 GHz. The standard provides for 16 channels in the 2.4-GHz band, 10 channels in the 915-MHz band, and one channel in the 868-MHz band. The specification describes two types of network nodes: an FFD (full-function device) that can perform any network duties and an RFD (reduced-function device) with limited resources and functions for cost-sensitive applications.
Low and slow
Adding to the PHY and MAC layers that IEEE 802.15.4 defines, the ZigBee Alliance defined the remaining layers needed for low-rate, low-power wireless applications. Each network must have at least one FFD, or coordinator, to provide initialization, node management, and node-information storage. To minimize cost and power consumption, the remaining nodes can be the simple, battery-operated RFDs. You can use ZigBee networks with several data-transmission schemes. For periodic data, such as with wireless sensors, nodes wake up at set times, transmit sampled data to the coordinator, and go back to sleep. A light switch delivers intermittent data and may connect and communicate with the network only when you activate it. Repetitive-data applications, such as real-time-control systems, may use ZigBee's guaranteed-time-slot capability to ensure communications without latency or contention. These network-layer data-delivery strategies allow system designers to trade communications frequency for battery life in RFD nodes. Very low duty cycles allow nodes with coin-type batteries to remain operational for years.
ZigBee-compliant silicon and development tools are available from several semiconductor manufacturers. For example, the low-cost CC2420 transceiver from Chipcon targets low-power, low-voltage RF applications in the 2.4-GHz band (Figure 1). It complies with the IEEE 802.15.4 standard as well as the ZigBee requirements for interoperability. For secure applications, the CC2420 provides hardware support for data encryption and data authentication. Targeting low-cost host processors, the transceiver supports packet handling, data buffering, burst transmissions, address recognition, clear-channel assessment, and link-quality indication. The transceiver is suitable for FFDs and RFDs and includes a DSSS modem with a 250-kbps effective data rate. Current consumption is 17 to 18 mA with user-programmable output power. Reference designs with 0- and 10-dBm output power are available from Chipcon.
As building-automation products become more intelligent and interoperable, designers need a standard language to transfer requests, commands, and data between systems. Many designers settled on XML (Extensible Markup Language). Its text-based syntax is similar to highly successful HTML (HyperText Markup Language), which Web browsers use. Currently finding extensive use in Web-service delivery, XML encloses data within tags much like HTML, but with significant differences. Although HTML tags specify how to present or display text, XML tags describe the contents of the enclosed text. Another major difference is that XML is extensible, meaning that you can define your own tags.
Several manufacturers have incorporated XML into their lines of building-control products. For example, the federal government recently awarded Johnson Controls a contract to provide systems that control indoor environments at the new Library of Congress Motion Picture Broadcasting and Recorded Sound division building complex. The Johnson Controls XML-based Metasys building-management system will manage all temperature, humidity, and power loads. These Web-based environmental controls are critical for all audio and video recordings, especially films made on silver-nitrate film stock, which can deteriorate quickly and become potentially explosive at room temperature.
Demand response
In a test of wide-area XML building-automation capabilities, researchers at the Department of Energy's Lawrence Berkeley National Laboratory completed an automated demand-response test to reduce electricity consumption when high prices, blackouts, or excessive demand threaten the power grid. The test used XML signals over the Internet to indicate the current price per kilowatt-hour. As the price increased, a group of five large building facilities began to shed consumption by reducing lighting and air conditioning according to a prescribed plan. The successful test demonstrated that manufacturers' systems can listen to a common XML signal over the Internet and coordinate activities to reduce demand in case a power plant or transmission line fails.
In addition to XML, several other Internet technologies are important to building automation services, including the SOAP (Simple Object Access Protocol), the UDDI (Universal Description, Discovery, and Integration) format for application identification, and the WSDL (Web Services Definition Language). These technologies interact to form a software stack for locating, describing, and executing a Web service. You can view and download the latest standards for these Web-services protocols and technologies from the World Wide Web Consortium.
|
The OASIS (Organization for the Advancement of Structured Information Standards) has proposed an initiative to define XML- and Web-services-based mechanisms for building-control systems. The OASIS oBIX (Open Building Information Exchange) technical committee is working to define a standard Web-services protocol to enable communications between building mechanical and electrical systems and enterprise applications. Because oBIX integrates with the enterprise, it allows continuous visibility of mechanical- and electrical-control systems and identifies problems and trends for system analysis or human interaction. The scope of the oBIX is to develop a Web-services-interface specification to simply and securely obtain data from HVAC, access control, utilities, and other building-automation systems. The oBIX approach has the advantage of operating with legacy mechanical and electrical subsystems.
Encelium Technologies' ECS (energy-control system) is an example of a scalable hardware and software system that allows users to reduce lighting requirements with photosensor-based automatic-lighting-level adjustments, occupancy sensor-based lighting levels, time-based zone-lighting control, and load shedding through dimming to accommodate energy-price spikes. The system's communication network allows employees or building-energy managers to individually control light fixtures, occupancy sensors, photosensors, and wall dimmers from a PC or through the Internet. The graphical user interface for the ECS comprises Encelium's central-control software, which allows any workstation to perform direct lighting control and other energy-management functions through the facility's LAN wiring (Figure 2). The price of the ECS starts at $10,000, depending on system configuration.
In today's building-automation climate, designers must deal with numerous stand-alone subsystems that lack any communications capability. Connect One offers the ioNet embedded-device server module, which uses Internet protocols to retrofit installed industrial equipment or machines with remote-monitoring and -control features (Figure 3). The module allows system designers to interface devices—such as elevators, surveillance cameras, vending machines, and gaming machines—that lack built-in communications hardware. Users can hard-wire the output from digital or analog signals in the device to ioNet's terminal block. The module can then log events and exchange data over the Internet through a built-in 10/100BaseT port. You can remotely manage ioNet over the Web by a standard browser or by Connect One's device-connectivity server.
Because of the longevity of real estate, smart-building technology will take years and even generations to become a dominant part of our architectural inventory. During this transition period, designers must devise clever techniques to deliver the benefits of building automation without complete replacement of legacy systems. Today, Web technology seems to be the favored approach to allowing incompatible systems to share data, respond to remote commands, and be a part of the business-information architecture.
BACnet: www.bacnet.org
Chipcon: www.chipcon.com
Connect One: www.connectone.com
Echelon Corp: www.echelon.com
Encelium Technologies: www.encelium.com
Johnson Controls: www.johnsoncontrols.com
OASIS: www.oasis-open.org
World Wide Web Consortium: www.w3.org
ZigBee Alliance: www.zigbee.org
