Thinking inside the box: Buildings get a brain

Although engineers have envisioned and implemented many Jetsons-like conveniences throughout the home, factory, and office, most end users are reluctant to pay extra for the hardware and software necessary to simplify mundane tasks. For example, subsystems to enable voice controls, automatically feed the pets, or create lighting or entertainment scenes when you walk through the door are available today, yet they appeal to only a small audience. In areas having high consumer interest, such as security or energy conservation, the lack of compatible products makes it difficult to devise a fully integrated system. Recognizing these industry problems, product manufacturers have proposed new initiatives, updated standards, and revised communications protocols that promise to accelerate the acceptance of smart-building technology.

Smart-building technology relies on distributed sensors, remotely controllable actuators, device networking, and decision-making software to coordinate and optimize building subsystems, such as those for security, the environment, information transfer, and safety. In a truly integrated building-automation system, any subsystem may use components and sensors. For example, an open window is important to both the security subsystem and the heating or air-conditioning function. Likewise, temperature sensors could detect a fire or signal the need for routine maintenance. Unlike today's stand-alone building systems, this type of data reuse requires components and subsystems that share and store sensor information.

Distributed sensors are vital to collecting the information that smart environments require. You can divide sensors into physical, motion, force, and biochemical categories. Physical sensors make pressure, temperature, and humidity measurements, and motion sensors record position, velocity, and acceleration. Force sensors indicate strain, torque, and vibration. The biochemical category includes everything from reactive agents to personal-identification items, such as fingerprints, voice analysis, and retinal scans. The biggest challenges to distributed sensors are transforming the measurement into a common format, efficiently transferring the data, and reducing the power required at each node.

The National Institute for Standards and Technology and the IEEE in 1993 began work on the distributed-sensor problem with a proposed family of standards entitled "A Smart Transducer Interface for Sensors and Actuators." The objective of these standards is to provide interchangeability among manufacturers, ensure that all transducers connect to control networks in the same way, and promote self-identifying, -configuring, and -calibrating sensors. The first standard in the family, IEEE 1451.2, defines the interface between the transducer hardware, called the STIM (smart-transducer-interface module), and the NCAP (network-capable application processor), or network controller (Figure 1). Manufacturers simply implement sensor circuitry for the STIM side of the 1451.2 interface and then choose a network controller depending on the application. Although the NIST and the IEEE in 1997 first approved the standard, industry adoption has been slow. Several changes, including the addition of alternate physical layers to use existing, widely available data-transfer methods to reduce sensor cost and complexity, are under way.

Another approach to the distributed-sensor problem is to piggyback on the TCP/IP networks now present in most buildings for data exchange. The OASIS (Organization for the Advancement of Structured Information Standards) has proposed an initiative to define XML (eXtensible Markup Language) 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 enterprises, it will allow continuous visibility of mechanical- and electrical-control systems and will identify problems and trends for system analysis or human interaction. The scope of 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.

Although not at the sensor level, many modern building subsystems interconnect with established but incompatible communications protocols, such as LonWorks, BACnet (Building Automation and Control Network), and ModBus, in addition to numerous proprietary protocols. Although these building-automation networking protocols operate over TCP/IP networks, they lack the sophistication to deal with enterprise routers, firewalls, security, and application traffic. BACnet is the common term for the ANSI/ASHRAE Standard 135-2001, which ANSI (American National Standards Institute) and the ASHRAE (American Society of Heating Refrigeration and Air-Conditioning Engineers) support. BACnet is a nonproprietary, open-protocol communication standard that represents data in terms of "objects," "properties," and "services." This standard method of representing data and actions enables devices from different manufacturers to interoperate; however, most BACnet devices are limited to the heating, ventilating, and air-conditioning industry. For example, the Mach-Vision from Reliable Controls is a programmable user interface for direct digital-control applications. This BACnet-certified device features a Basiclike program language, five reconfigurable inputs, four scalable outputs, and closed-loop capability (Figure 2).

Unlike BACnet, LonWorks requires the use of a proprietary Neuron chip from Echelon Corp in each controller. LonWorks finds use mainly in the lighting, utilities, and transportation industries and has more automated building installations than BACnet. The LonWorks protocol provides a set of services that allow 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. The LonWorks protocol can optionally provide end-to-end acknowledgment of messages, authentication of messages, and priority delivery for real-time applications.

The ModBus protocol is an open-messaging structure that Modicon developed in 1979; it establishes master-slave/client-server communication between devices. ModBus originated as a standard for programmable-logic controllers to access simple integer and binary values. The protocol is well-understood and finds wide use across many industries. Its main strengths are its simplicity and its ease of implementation in low-level devices. ModBus is the standard in power metering, UPS, and generators. Ken Crater, president of the ModBus Suppliers and Users Association, says, "Straightforward protocols such as ModBus are easier and faster to code, apply, and troubleshoot than more complex protocols. This [approach] reduces cost and helps companies move more quickly in their markets." You can freely download the ModBus specification from the Internet, and a number of open-source implementations of the protocol are available.

Because of the large number of sensors that a smart-building environment employs, designers prefer networking schemes that require no installation of new interconnecting cables. Wireless links, power-line communications, and even telephone-line sharing are viable alternatives that eliminate new wiring. For example, Echelon's PL3120 and PL3150 power-line smart transceivers enable LonWorks-compatible products to communicate over a building's electrical network (Figure 3). The transceivers include an 8-bit Neuron processor core for running applications and managing network communications. A dual-carrier feature automatically selects a second frequency if noise is blocking the signal. The transceivers are available in a $345 Mini EVK (evaluation kit) allowing designers to experiment with smart light switches, thermostats, and other simple devices and sensors using power-line communications.

Wireless networks with extremely low power consumption are ideal for many smart-building-sensor applications. To meet this need, the IEEE in May 2003 ratified the 802.15.4 standard for ultra-low-power, low-data-rate networks operating in the unlicensed-frequency bands. The standard defines the PHY (physical layer) and MAC (medium-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 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 sub-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 channel-access method is CSMA-CA (carrier-sense multiple access with collision avoidance). 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.

IEEE 802.15.4 defined a global standard for the PHY and MAC layers, and the ZigBee Alliance defined the remaining network, security, and application layers for the low-rate, low-power wireless specification. The ZigBee-defined network layer is responsible for device discovery and network configuration. ZigBee allows star and mesh topologies along with a combination of the two—cluster-tree networks. 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. Designers 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 someone activates 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. Low duty cycles allow nodes with coin-type batteries to remain operational for years.

With the huge number of sensor nodes that a typical smart-building environment requires, cost becomes critical. Designers can cut costs by removing functions and limiting compatibility with external systems. Juan Alvarez, MSP430 microcontroller-marketing manager for advanced embedded controls at Texas Instruments, says, "Customers want both low cost and low power in sensor networks. A fully compliant ZigBee device requires 40 kbytes of flash memory and 5 kbytes of RAM. That can be expensive in a simple node that may be dormant 95% of the time and wake up only periodically to transmit short bursts of data. Although full functionality in ZigBee makes sense for interoperability, low cost may be a greater need."

Attacking the high cost of ZigBee-compatible nodes, Ember recently announced the EM250, a true ZigBee system on chip that combines a 2.4-GHz, IEEE 802.15.4-compliant radio transceiver with a 16-bit microprocessor (Figure 4). For use with EmberZNet, Ember's latest ZigBee-compliant embedded mesh-networking software, the EM250 targets designs requiring long battery life, low external-component count, and an industry-standard networking protocol. The EM250's integrated microprocessor operates at 12 MHz and includes 128 kbytes of flash and 5 kbytes of RAM to accommodate user applications based on the EmberZNet networking library. The EM250's deep-sleep mode requires less than 1 µA, even with the sleep timer running. For applications requiring extended range, Ember also provides an easy method of connecting an external amplifier. The Ember EM250 costs less than $4 per unit in high volumes. Venkat Bahl, Ember's vice president of marketing, says, "The ability to market Ember-enabled products with the official ZigBee-compliant designation will bring the same kind of market acceptance and excitement that WiFi [Wireless Fidelity] certification brought to wireless-LAN vendors."

Automated Logic has adopted Internet technology in its WebCtrl (Web-based building-control) system. With its native BACnet architecture and support for ModBus and LonWorks, WebCtrl integrates building-subsystem information with information-technology protocols (Figure 5). WebCtrl's standard Web-services interface uses SOAP (Simple Object Access Protocol) and XML technology for cross-platform data sharing with other computer systems. Steve Tom, director of technical information at Automated Logic, says, "XML provides a standard method for a building-automation system to communicate with another computer, whether that computer is in another building system or a completely different application. Today, building-automation manufacturers are adding XML support into their Web servers and operator workstations because it is the standard for communicating with other systems at that level." (See Reference 1.) XML data exchange allows maintenance-management systems, accounting systems, wide-area utility-management programs, and other high-level computer applications to use the standard enterprise tools to retrieve information from WebCtrl. It also means these tools can write data to WebCtrl, so building-control applications can use weather forecasts, real-time energy pricing, and other external factors as integral parts of building-control applications.

Smart-building technology will eventually become part of the pervasive computing movement in which computer interactions are natural and unstructured (Reference 2). Until then, Web technology seems to be the best approach for bringing together the highly fragmented building-automation industry. Internet protocols and Web services allow incompatible systems to share data and integrate into the enterprise information-technology structure.

Author Information

You can reach Technical Editor Warren Webb at 1-858-513-3713 and wwebb@edn.com.