Printer Friendly

A plug-and-play Framework for an HVAC Air-Conditioning unit and temperature sensor auto recognition technique--part I: review of critical technologies.


One of ASHRAE's visions is to develop and provide tools by 2020 that enable the building community to produce market-viable Net Zero Energy Buildings by 2030 (ASHRAE 2008). There is great need for smarter building automation systems (BASs) and controls--from smart sensors and actuators that are inexpensive, reliable, and easy to maintain and calibrate to control systems that are easy to install, set up, configure, and commission--which is a huge barrier to wide-scale adoption of BASs. In a U.S. Department of Energy (2005) report, a self-configuring HVAC control system is regarded as one of the strategies for future new HVAC control applications.

Many people are familiar with the general term "plug and play," a feature that allows the addition of a new electronic device, normally a peripheral, without requiring reconfiguration or manual installation of device drivers. This technology makes the computer peripheral installation process automatic, easy, and efficient. It is very desirable to have the same feature implemented in BASs, where the system setup and configuration processes are often manual, time consuming, and error-prone. A plug-and-play and self-configuring BAS would greatly reduce the time and complexity of BAS setup and configuration as well as improve system performance by reducing or eliminating human error. Achieving plug-and-play capability in BASs requires the following (DOE 2005):

* individual components such as transducers (sensors and actuators) have a "self-describing" feature that provides critical information for the device;

* network topology exploration and discovery of all components in the network with standardized communication protocols among building automation systems components; and

* establishment of a binding list of control system inputs/outputs and automatic assignment and verification of the binding list.

With the advancement of sensing technology over the past fifteen years, there are now commercially available smart sensors that have the self-describing feature. One example is the sensors and transducers that comply with the IEEE 1451 family of smart transducer interface standards (Lee 2000; Song and Lee 2008), which have sensor data (in the form of a transducer electronic data sheet, or TEDS) inscribed on an electrically erasable programmable read-only memory (EEPROM) located on the sensor. Basic data information includes manufacturer ID, model number, version letter, version number, and serial number. Optional information includes sensor calibration data, operating range, etc. These sensor-specific data are essential in a plug-and-play HVAC control system.

Unfortunately, no existing communication protocols in the HVAC industry, including BACnet (ASHRAE 2004) and the widely used LonTalk, can directly communicate with the smart transducers that comply with the IEEE 1451 standards. There-fore, efforts are needed to incorporate IEEE 1451 into these communication protocols in order to use smart transducers.

While a compatible communication protocol may be addressed by close cooperation among the IT industry, IEEE, ASHRAE, and other related organizations, a more critical problem specific to HVAC controls is how to automatically establish a binding list for BAS inputs/outputs and assignment and verification of this binding list. The control components' physical locations (where they are physically located in the HVAC system) and more importantly, the logical locations (the positions in the HVAC control logic) are critical for control system configuration. Since there might be multiple sensors/actuators of the same type in the system (e.g., supply air temperature sensor and return air temperature sensor), a preliminary requirement for establishing a binding list is to automatically recognize the physical or logical location of all HVAC control components; this is also called "resolving system ambiguity." So far, there is no known algorithm or scheme developed in this area.

The overall goal of this study is to advance plug-and-play technology in the HVAC industry by developing a break-through concept, a scheme, and an algorithm to solve a critical issue--resolving system ambiguity. The first objective (presented in this paper) is to develop a plug-and-play frame-work for an air-handling unit (AHU) control system, a foundation that should eventually lead to a plug-and-play and self-configuring HVAC control system. This paper addresses the following issues in detail:

* reviews current plug-and-play technologies, their applicability to HVAC control systems, and the current state-of-the-art of existing concepts related to this study;

* analyzes the technological advancement necessary to bridge the gap between today's HVAC control setup process and a full plug-and-play process; and

* develops a plug-and-play framework for an AHU.

The second objective of this study (presented in Part II) is to develop a scheme for resolving system ambiguity and, as an example, develop a structural pattern recognition algorithm to automatically recognize AHU temperature sensor physical and logical locations. Part II of this study (Zhou and Nelson 2011) addresses the following issues in detail:

* develops an automatic pattern recognition algorithm to determine smart temperature sensor logical locations in an AHU;

* builds and tests a prototype of the plug-and-play frame-work for an AHU in a real building environment and HVAC system; and

* tests data analysis.


Because of the unavailability of technology and a bottle-neck in resolving system ambiguity, there is a lack of research in the area of plug-and-play and self-configuring HVAC systems. This is a multidisciplinary research area involving mechanical engineering, information technology, electrical and controls engineering, and artificial intelligence. The literature review and background information are presented in several sections: plug-and-play and self-configuring concept for HVAC control systems; plug and play in the IT industry; communications and control networks for HVAC; smart transducers and the IEEE 1451 standards; and pattern recognition and its application to time series data (presented in Part II [Zhou and Nelson 2011]).

Plug-and-Play and Self-Configuring Concept for HVAC Control Systems

For large commercial and industrial buildings, modern HVAC control systems are direct digital control (DDC) systems that consist of computerized and networked control and sensing devices. The goal of a DDC system is to operate the HVAC equipment efficiently to maintain better building environments with minimum energy consumption. Due to the complexity and proprietary nature of many DDC systems, they are difficult to design, install, set up, operate, and maintain. Highly trained professionals are usually required to carry out a DDC project from installation, setup, configuration, tuning, and troubleshooting before it is operational. The whole process is often difficult, time consuming, and very expensive. A normal DDC control system setup process is generalized in the following steps (assuming the control system design phase is already finished):

1. Network setup. Network wires/cables are connected to the control system server(s), operator workstation(s), network controller(s), and other networking devices, according to the designed network architecture. Networking devices are set up and configured.

2. System components (sensors, controllers, actuators, etc.) installation and functional tests. Individual component function(s) should be checked at this stage to ensure they are working properly. They are then connected to assigned controller(s) based on the control system design and the available controller channels.

3. System configuration and programming. For each local controller, an input/output binding list based on design intent, input/output types, and physical/logical locations is generated. The controller is then configured and programmed according to this list. Schedules, trend logs, and global network control logics are also set up and configured at local controllers, network controllers, and control system servers during this step.

4. System commissioning, tuning, and debugging. The HVAC system is started up, local controller PID loops are tuned, sensors are field calibrated, and the system is balanced and commissioned to verify that the control system works as intended.

Because a complicated HVAC control system may involve hundreds to thousands of components, the overall process often involves labor intensive, time-consuming manual work, which introduces human errors. It is very desirable to apply the plug-and-play and self-configuring concept from the IT industry to automate part of the process. A self-configuring HVAC control system here is defined as a control system that can configure itself automatically without human intervention, given the design intent of the system. Specifically, Step 3 in the setup process is fully automated in a self-configuring HVAC control system.

One important prerequisite for process automation is for all control system components on the control network to be automatically detected and recognized by their physical/logical locations. This is the major difference from the plug-and-play components in the IT industry, where the physical and logical locations of the components are not important as long as a sequential identification number can be assigned to components of the same type. A plug-and-play HVAC control system is then defined as a control system that can automatically detect and recognize control system components, including sensor/transducer types, and their physical or logical locations. Therefore, a self-configuring HVAC control system concept encompasses a plug-and-play HVAC control system concept. The former involves a more complicated issue of mapping (or translation) of design intent to actual binding list and control strategies and correlating the detected known components to the binding list. The general steps needed for a self-configuring HVAC control system are described as follows:

* Based on HVAC system design for a project, a compatible control system design can be selected based on standardized control sequences, automatically generating required input/output points and control loops.

* After manual network setup and system component installation and functional tests, automatic detection of HVAC control components on the control network are implemented using autodiscovering or other enabling technologies.

* Once all control components on the network are detected, an algorithm to identify input/output physical/ logical locations is needed to assign the components of the same type to a specific physical or logical location. This is especially important for the sensors involved in control loops (e.g., AHU supply air temperature, zone temperature, etc.).

* The identified HVAC control components will be com-pared with automatically generated input/output points and control loops and then mapped accordingly based on detected and available controller channels and PID loops. A standardized control program is then automatically downloaded to controllers for the next commissioning and tuning step.

* System commissioning, tuning, and debugging may utilize data collected during the point detection and identification steps and may be done automatically.

Plug and Play in the IT Industry

The classic plug-and-play concept originated in the computer industry to allow computer devices to have self-detection and self-configuration capabilities. The specification was initially developed by Microsoft[R] and various computer hardware manufacturers in the form of Industry Standard Architecture (ISA), Extended Industry Standard Architecture (EISA), and Micro Channel Architecture (MCA) computer buses. Later they were extended to the Peripheral Component Interconnect (PCI) computer bus for internal hardware devices (Shanley 1995). For external computer peripheral devices, two popular standards are the Universal Serial Bus (USB) (Compaq et al. 2000) and IEEE 1394 inter-face standard (IEEE 2008). However, these specifications or standards only address the plug-and-play concept on a directly connected device. A typical (simplified) configuration process for plug-and-play devices on an E/ISA bus is as follows:

1. An internal self-starting program writes a special key sequence to the plug-and-play devices, preparing them all to listen. The program performs a special series of reads among all connected plug-and-play devices and decides which device will enter isolation mode.

2. The program assigns an identification number to the isolated device. The isolated device leaves the isolation state and enters the configuration state.

3. The program reads the isolated device's resource requirement list to determine its requirement. Then the device is issued a command to go to sleep.

4. Steps 1 to 4 are repeated for all detected devices until all have been isolated and assigned an identification number and their resource needs have been identified.

5. The program then uses each identification number to place the device into configuration mode. Its configuration registers are then written to assign nonconflicting resources to the device.

6. The device is then enabled (activated) for normal operation.

7. Steps 6 and 7 are repeated until all devices have been configured and enabled.

To expand the plug-and-play concept beyond a single computer to a networked environment, several networking protocols and specifications, such as Jini (Sun 2003), Universal Plug and Play (UPnP) (UPnP Forum 2008), and Plug-and-Play Extensions (PnP-X) (Microsoft 2007) were implemented by different companies or groups in the IT industry. The purpose of these protocols is to address the issue of autoconfiguration of dynamically distributed networked devices and for distributed computing.

Jini refers to both a set of specifications and an implementation (Jini starter kit). It was invented by Sun Microsystems[R] in 1994 and is a distributed object system architecture that defines a programming model based on and extending Java technology in a distributed environment. The key concepts in Jini include (1) Service-an entity that can be used by a person, program, or another service, (2) Look-Up Service--the central bootstrapping mechanism for the system that provides the major point of contact between the system and users of the system, and (3) Java Remote Method Invocation (RMI)--a Java extension to the traditional remote procedure call mechanisms that allows various types of objects (including data and code) to be passed around the distributed network. The working process of Jini is simplified as the following steps:

1. Service provider discovers lookup server through multi-cast discovery.

2. Service provider registers service object and service attributes with lookup server.

3. Client discovers lookup server through multicast discovery.

4. Client performs lookup to known lookup server and receives server location from service proxy.

5. Client directly accesses server and executes code on the server.

Jini technology is a simple infrastructure for providing and gaining access to services in a network. The use of Jini technology decentralizes the control system, eliminates reprogramming or configuration, and enables vendor independent systems. A major challenge to its use in HVAC controls is that it is not a widely used protocol. Another challenge is that all Jini-enabled devices need some memory and processing power, but the memory included in HVAC sensors and control devices is generally too small to accommodate Jini services. Finally, there is no standard for defining the control device characteristics and interaction mechanisms for control loops. There are also no Jinibased sensors, transducers, and actuators known that are commercially available.

UPnP defines an architecture for peer-to-peer network connectivity of intelligent appliances, wireless devices, and PCs. It is designed to support zero configuration, "invisible" networking, and automatic discovery for a breadth of device categories from a wide range of vendors. It provides a distributed, open networking architecture using the Transmission Control Protocol/Internet Protocol (TCP/IP) and Web technologies for control and data transfer among networked devices. UPnP is supported by Windows Me, Windows XP, Windows Vista, and Windows 7. This technology is defined by the Universal Plug-and-Play Forum--established in 1999 by a group of 200 industry leaders in consumer electronics, computing, home automation and security, home appliances, computer networking, and mobile devices. The basic key concepts in UPnP are controlled devices (or "devices"), control points (or "controllers"), and services.

The smallest unit of control in a UPnP network is a "service." A service exposes "actions" and models its state with state variables. A UPnP device is a container of services and nested devices. Devices may contain multiple services. A device responds to requests from control points. Both control points and controlled devices can be implemented on a variety of computer operating systems. A control point in a UPnP network is a controller capable of discovering and controlling other devices. After discovery, a control point could retrieve the device description and get a list of associated services, invoke actions to control the service, and subscribe to the service's event source. The working process of UPnP is simplified as the following steps:

1. Addressing. Each device is assigned an IP address via Dynamic Host Configuration Protocol (DHCP) or using auto IP when connected to the network.

2. Discovery. A device advertises its services to control points on the network. When a control point is added to the network, it searches for devices of interest on the network.

3. Describing. The control point retrieves the device's description expressed in Extensible Markup Language (XML) and includes vendor-specific information, including the model name and number, serial number, manufacturer name, etc.

4. Control. A control point sends an action request to a device's service expressed in XML. In response to the control message, the service returns action-specific values or fault codes.

5. Eventing. The service publishes updates when a list of variables that model the state of the service changes. Control points may subscribe to receive this information.

6. Presentation. The control point can retrieve and load a presentation page from a device and display it in a browser, which allows a user to control the device and/or view device status.

The applications for UPnP in the past have been mostly in home automation, printing and imaging, audio/video entertainment, and kitchen appliances. Even though the UPnP Device Control Protocol (DCP) has been written for limited HVAC devices, such as temperature sensors, control valves, zone thermostats, fan speed, etc., it is very difficult to find UPnP compatible devices commercially available. As with Jini, UPnP is not widely used as a networking protocol in the HVAC industry.

PnP-X is another, newer version of a distributed network protocol but is only available for Windows Vista and Windows 7 operating systems. Similar to UPnP, it integrates network-connected devices into the Windows operating system. PnP-X allows network-connected devices to appear as devices inside Windows and provides an installation experience that is similar to attaching a physically connected device.

None of these architectures has been widely adopted in the HVAC industry for building automation systems because of limitations to these protocols and the applicability to HVAC control systems. Yet the overall process to realize the plug-and-play feature can be borrowed from the IT industry to build the framework of plug and play and self configuration of HVAC control systems.

Communications and Control Networks in HVAC

A typical DDC system mainly consists of sensors, actuators, controllers, networking devices, and operator workstations, all in a multilayer networked environment. The local area network (LAN) is the medium that connects multiple devices. It allows these devices to control, communicate, share, display, and print information, as well as to store data. The most basic task of the system architecture is to connect the DDC controllers so that information can be shared among them. Kastner et al. (2005) provides a comprehensive review on the communication systems in building controls.

Generally speaking, there is a three-level functional hierarchy in a building automation network, as illustrated in Figure 1.

The lowest level is the field level, where the actual local sensing and control execution happens. At this level, sensors/ actuators and the controllers are either mostly directly connected using dry contacts/analog signals (voltage, e.g., 1~10 VDC, or current, e.g., 4~20 mA) or in a local field network. The most common PID control loops execute at this level. This is also where the most sensor/actuator and controller configuration is needed during system installation and setup. The local field network for HVAC applications has the following characteristics: high speed is not required, as normal HVAC processes are slow and, therefore, allow low-volume traffic, peer-to-peer, and event-driven (vs. time-driven) communications. Many field network buses are proprietary. One of the "open" protocols at this level is Modbus, which supports serial communication using a simple master-slave protocol over EIA-485 (EIA 1998) (a standard defining the electrical characteristics of drivers and receivers for use in balanced digital multipoint systems). Wireless standards have gained some relevance recently, because of easy installation and no need for cabling. In lighting systems, there is an IEC standard Digital Addressable Lighting Interface (DALI) that has been widely used. It replaces the 0-10 VDC interface for dimmable electronic ballasts. A DALI loop data rate is 2400 b/s. However, because of promotion by ASHRAE and the market success of Lonworks[R], the BACnet[R] standard (ASHRAE 2004) and LonWorks platform (Echelon 2009) are still the most widely adapted open standards now used in DDC systems. BACnet is designed to provide system- and field-level standards for routine functions, such as data exchanges, alarms and event management, scheduling, and trending for the benefit of interoperability. At the field level, BACnet MS/ TP (master-slave/token-passing) and BACnet PTP (point-to-point) are mostly used. BACnet MS/TP uses twisted pairs and EIA-485 signaling that can transfer data at speeds ranging from 9.6 kb/s to 78.4kb/s. BACnet PTP supports dial-up communications and other point-to-point applications using serial communication protocol EIA-232 (EIA 1997) and modems or other data communication equipment. The LonWorks system consists of the LonTalk communication protocol, a dedicated controller (neuron chip), and a network management tool. The most popular field-level LonTalk protocol used in building automation system networks is the 78.1 kb/s speed free topology twisted pair profile (FT-10).


At the automation level, the main purpose of the network is to transfer global data between network controllers (which manage, control, and store temporary data for the components on the field networks) for global control and data collecting. Speed is more important than at the field level. Many building automation system vendors have their own propriety or legacy communication protocols. However, most of these vendors have already implemented either BACnet/IP, BACnet over Ethernet or LonWorks/IP in their system architectures, or at least in some of their product lines, due to the popularity of control system component interoperability and interchangeability among users.

Standard IT communication protocols are predominant in the management level networks (or "backbones") of HVAC control systems. It is a natural choice to use the existing IT network infrastructure for building automation purposes, as there is little local control function involved in the operator workstation except user interface and some management and system diagnostic functions. The protocol that is most widely used at this level is Ethernet with IP (Internet Protocol).

Unfortunately, neither BACnet nor LonWorks, nor other proprietary communication protocol in the HVAC industry addresses the issues of automatically implementing the control system programming, configuration, and setup. None had fully incorporated the plug-and-play feature into their specifications. One major reason for this is that the components in an HVAC control system, especially the small sensors and actuators, are not real "smart" components. These components only send/receive analog or digital signals to and from the controller, but they do not have an internal memory device that stores information to identify and describe itself with critical information, such as type of transmitter, manufacturer, serial ID, calibration information, scaling factor, etc. This is the information that needs to be used during the control system setup and configuration processes. Normally, after a control system is designed and wires connected, the controls engineer has to manually configure this information in the system. For large systems with many components, the setup and configuring process is very complicated, time-consuming, and error prone and requires highly trained professionals.

Smart Transducers and the IEEE 1451 Standards

Traditional analog sensors and actuators used in the control industry output voltage (0-10 VDC, 1-5 VDC, etc.), current (0-20 mA, 4-20 mA, etc.), or resistance (ohms). These sensors/actuators have neither communication capability with controllers nor capability to store critical sensor information (manufacturer, calibration, etc.) about them. For a plug-and-play HVAC control system, all the components (controllers, sensors, actuators, etc.) must be able to communicate and have the self-describing feature. Ko and Fung (1982) introduced the concept of the "intelligent transducer." Their definition of an intelligent or smart transducer is the integration of an analog or digital sensor or actuator element, a processing unit, and a communication interface. In the case of a sensor, the smart transducer transforms the raw sensor signal to a standardized digital representation, checks and calibrates the signal, and transmits this digital signal to its users via a standardized communication protocol (Armson 2002). In the case of an actuator, the smart transducer accepts standardized commands and transforms these into control signals for the actuator. A smart transducer is composed of a hardware and software device consisting of a small, compact unit containing a sensor or actuator element, a microcontroller, a communication controller, and the associated software for signal conditioning, calibration, diagnostics, and communication (OMG 2003). The conceptual block diagram is illustrated in Figure 2.


The past twenty years have seen an increased market in digital sensors/actuators. Many of them, though, use proprietary communication protocols--they can only communicate with controllers from the same manufacturer-or are restricted to only one field data network. Trying to solve the problem of multiple communication standards between transducer and data networks, the transducer, measurement-and-control, and data-network industries discussed the concept of smart transducers during the September 1993 IEEE TC-9 meeting (IEEE Instrumentation and Measurement Society Technical Committee on Sensors). The working groups tried to develop draft standards to provide (1) a common communication interface between transducers and processors, (2) compatibility with multiple sensor actuator bus standards, and (3) interconnection of analog transducers with digital networks, all without developing a new network standard. Based on this work, in later years, the National Institute of Standards and Technology (NIST) and IEEE developed the IEEE 1451 family of smart transducer standards.

The IEEE 1451 family of smart transducer interface standards describes a set of open, common, network-independent communication interfaces for connecting transducers to microprocessors, instrumentation systems, and control/field networks in a networked system. A key feature of these standards is the definition of transducer electronic data sheets (TEDS). All sensors and transducers manufactured according to these standards store transducer identification, calibration, and manufacturer-related information in the TEDS--a memory device embedded in the transducer. Because of this feature, these smart transducers enable self identification, easy calibration, and simplified device maintenance and documentation, thus facilitating plug-and-play and automatic system self configuration. The block diagram for an IEEE 1451 smart transducer is illustrated in Figure 3.


As can be seen, the IEEE 1451 smart transducer model separates the unit into two major components--a Transducer Interface Module (TIM), and a Network Capable Application Processor (NCAP) with a transducer independent interface (TII) between them. The transducer independent interface defines a communication medium and a protocol for transfer-ring sensor information.

The IEEE 1451 family of standards currently consists of the following:

1. IEEE 1451.0 (IEEE 2007a) defines a smart transducer interface, which includes common functions, communication protocols, and TEDS formats. This functionality is independent of the physical communications media (1451.X) between the transducer and the NCAP.

2. IEEE 1451.1 (IEEE 1999) defines a common object model and an interface specification for the components of a networked smart transducer. It is applicable to distributed measurement and control applications. It mainly focuses on the communications between NCAPs and between NCAPs and other nodes in the system.

3. IEEE 1451.2 (IEEE 1997) defines a transducers-to-NCAP interface and TEDS for point-to-point configurations. Transducers are part of a Smart Transducer Inter-face Module. The standard describes a communication layer to interface with IEEE 1451.0 and to support two popular serial interfaces, Universal Asynchronous Receiver/Transmitter and Universal Serial Interface.

4. IEEE 1451.3 (IEEE 2003) defines a transducer-to-NCAP interface and TEDS using a multidrop communication protocol. It allows transducers to be arrayed as nodes on a multidrop transducer network sharing a common pair of wires.

5. IEEE 1451.4 (IEEE 2004) defines a mixed-mode inter-face for analog transducers with analog and digital operating modes. IEEE 1451.4 mainly focuses on adding the TEDS feature to legacy analog sensors. A TEDS is added on a traditional two-wire sensor, and the TEDS model is refined to allow a minimum of data to be stored in a physically small memory device, as required by tiny sensors.

6. IEEE 1451.5 (IEEE 2007b) defines a transducer-to-NCAP interface and TEDS for wireless transducers. IEEE 1451.5 specifies radiospecific protocols for achiev-ing this wireless interface. Wireless standards such as 802.11 (WiFi), 802.15.1 (Bluetooth), 802.15.4 (used by ZigBee), and 6LowPAN are adopted as the IEEE 1451.5 wireless interfaces.

7. IEEE P1451.6 (Lee 2004) defines a transducer-to-NCAP interface and TEDS for the high-speed CANopen network interface.

8. IEEE P1451.7 (IEEE 2010) defines an interface and communication protocol between transducers and Radio Frequency Identification (RFID) systems.


The IEEE 1451 family of smart transducer standards is illustrated in Figure 4 (Lee 2004).

Aside from the benefits of TEDS--self-identification and descriptions, self-documentation, and easy installation--another advantage of the IEEE 1451 family of standards is plug-and-play capability. A TIM and an NCAP can be connected with a standardized physical communications medium and operate without any change to the system software. Figure 5 illustrates the plug-and-play features for TIMs and NCAPs that comply with IEEE 1451 standards. The solid lines with arrows indicate that the plug-and-play feature is between the TIM layer components (TIMs) and the NCAP layer components, and the dashed line with arrow separates the TIM layer from the NCAP layer. Thus, the sensor/actuator manufacturer can focus on making sensor/actuator units only. The sensor network builders can focus on making the sensor network interface. For the vendors who combine both the TIM and the NCAP into a single module and sell it as an integrated, networked sensor, the interface between the TIM and NCAP is hidden, but the integrated sensor is still IEEE 1451 compatible at the network level.

Currently, there are temperature (resistance temperature detector [RTD], thermistor, and thermocouple), pressure (absolute and differential), and other types of IEEE 1451 smart sensors on the market, but they are used mostly in the distributed measurement and control, aerospace, and automotive industries. It is also worth mentioning that many TEDS sensors are not cost prohibitive. Some are even very close to the same price as comparable conventional sensors without the TEDS chips. A major obstacle for the use of these smart sensors in the HVAC industry is the compatibility between prevailing BACnet and LonWorks and the IEEE 1451 standards.


Technology Gap Analysis for Components

Plug-and-play and self-configuring technologies have basic requirements for the components. A common requirement is the capability to store information about themselves on the device. This is referred to as the "self-describing" feature. The self-describing information can vary depending on device type. The most common information about a device includes manufacturing ID, device type, and serial number.


Current HVAC control systems components include the following categories (excluding network and communication):

1. Computers. Operator workstations, supervisory computers, independent Web servers for the control system, and computers for facility management use.

2.Network controllers.Controllers that coordinate systemglobal operations over the automation level network. Some controllers also have a Web server embedded.

3.Field controllers.Controllers executing local controlloops for unitary or simple equipment or zone control.

4.Independent HVAC equipment.HVAC equipment that runs independently may have its own controller. Some equipment (e.g., chillers and boilers) may get their setpoints from the HVAC control system.

5.Sensors.Analog or digital devices measuring different properties of air/water or indicating equipment status (temperature, humidity, pressure, flow rate, on/off status for controlled equipment, etc.). Most sensors are connected to field controllers for monitoring and control purposes.

6.Action devices.Analog or digital devices executing controller commands (e.g., various types of actuators, pumps, fans).

In the above component categories, categories 1 to 4 all have internal memory and storage space and have no difficulty embedding self-describing information on themselves. However, most commonly used HVAC-grade sensors and action devices are low cost, not very accurate, and do not have information embedded on the device to provide the self-describing feature. For example, a simple RTD sensor can only provide a resistance value to the controller, nothing more. The same can be said for many other types of sensors.

For the sensor category, recent developments in BACnet and LonWorks promote some new development in sensors conforming to these standards. There are commercially avail-able BACnet compatible thermostats for temperature control in a zone, but these are multifunction units combined with a controller and are much more expensive than a single simple temperature sensor. There are also BACnet compatible airflow stations, CO2 sensors, and relative humidity sensors, and these products usually include a separate transmitter to send information.

For LonWorks compatible sensors, in addition to the networked thermostats, there are now commercially available temperature, pressure, light, IAQ, and occupancy sensors that use conventional sensors embedded with a Free Topology Transceiver (FTT) plug-in module that converts the present raw signal to a LonWorks digital signal. The signals exchanged in LonWorks are called "Network Variables," which may be a single value or a structure or union of multiple values. A LonWorks component or device may have multiple network variables. A set of Standard Network Variable Types (SNVT) defining standard units, ranges, and resolutions for most common measures is used in HVAC. There are over 100 types covering a wide range of applications. SNVTs are self identifying, and may have a selfdocumentation string that can be used to provide more information to a network tool. However, these devices do not provide serial number and calibration information.

For the action device category, there are limited numbers of "smart" actuators that use BACnet or LonWorks protocols. BACnet and LonWorks relay modules, VFDs, and motor starters are also commercially available.

Outside the HVAC industry, smart sensor technologies have developed quickly in the past decade. The most promising ones are smart transducers (including smart sensors and actuators) that comply with the IEEE 1451 set of smart transducer interface standards for sensors and actuators. As introduced in previous sections, an IEEE 1451 smart transducer consists of a nonvolatile memory called a Transducer Electronic Data Sheet (TEDS) that stores critical transducer-specific information and a processing unit to convert the raw signal to the IEEE 1451 signal. An example of a TEDS format defined by the IEEE 1451.4 (for mixed mode interface) specification is illustrated in Table 1; it consists of multiple sections chained together. The first section is the basic TEDS information, which includes the Manufacturer ID, model number, version letter, version number, and serial number. There are 15 different categories of IEEE standardized sensor/ actuator types. For each category a standard template is specified. Following standard template data (optional) are calibration template data, which has three different categories by itself. The last section is the user defined data.

It can be seen from Table 1 that the advantage of smart transducers is that they all have a memory chip that stores important transducer information, so it has the self-describing feature that the plug-and-play technology needs. The communication protocols are also standardized across various fields and applications, including the latest wireless standards. The disadvantages are that they are mostly used in industries outside of HVAC, and the transducer types do not cover common sensors/actuators used in HVAC controls (humidity, air/water flow rate, carbon dioxide, valve and damper actuators, etc.), even though there are commercially available smart temperature sensors and pressure sensors.

Table 1. A TEDS Format for a Mixed-Mode Interface

Smart Transducer

Basic TEDS

Template ID

Standard template TEDS (ID = 25 to 39)

Calibration template TEDS (ID = 40 to 42)

User data

In summary, there are not many readily available commercial smart sensors/actuators for plug and play in HVAC applications. The IEEE 1451 smart transducers are probably the closest fit in terms of sensing technology with the plug-and-play feature. One major obstacle to using these smart transducers in HVAC applications is the communication protocol incompatibility between IEEE 1451 and BACnet or LonWorks. Another solution would be to develop BACnet/ LonWorks compatible sensors/actuators with the plug-and-play feature, which requires additions and changes to the BACnet protocol and LonWorks platform.

Technology Gap Analysis for Communications and Networks

To apply plug-and-play and self-configuring technology in an HVAC control system, one requirement is that all system components use the same protocol; otherwise, gateways/ converters are needed to "translate" the information among different subnetwork components that use different protocols. The second requirement is that, like plug-and-play technology in the IT industry, there must be a predefined configuration mechanism or specification to detect, identify, and configure these components automatically.

The most common commercial open communication protocols for HVAC control systems in the U.S. are BACnet and LonWorks. However, "open" does not mean "plug and play." Some BAS vendors do have the "auto discovery" feature, which can scan the whole network and discover all the exposed BACnet objects by mapping BACnet object names to binary IDs and network addresses. This feature can reduce some setup time but cannot fully automate the system configuration steps, because the physical or logical locations of each component still need to be checked/verified manually.

LonWorks provides significantly more plug-and-play capabilities than BACnet by using the Interoperable Self Installation (ISI) protocol (Echelon 2005a). ISI is an open company standard. The protocol is a peer-to-peer protocol and detects the addition and removal of system components by periodically broadcasting the assigned components in the system. The manufacturers claim LonWorks devices can self install automatically or at the push of a button using ISI. The basic self-installation procedure is as follows (Echelon 2005a, 2005b):

1.Domain acquisition. Each component in a LonWorks/ISI network is assigned a domain ID--a 6-byte ID that is initially derived from the one of the component neuron IDs or assigned by a Domain Address Server (DAS).

2.Network address assignment. Each component is assigned a subnet and node ID when it is installed for the first time.

3.Network address verification. The self installation program periodically verifies that the network address for each component is still valid.

4.Device discovery. Enables any device to scan and learn the network address and program types for all devices in a network.

5.Connection enrollment.Connections may be createdusing an automatic, controlled, or manual enrollment method. When using automatic enrollment, no user intervention is required to create connections. When using controlled or manual enrollment, the user chooses the device that becomes the connection host. The connection host assigns a unique connection ID to a component based on design intent and then gets acceptance manually by the user.

6.Connection verification. Network variable connections are automatically verified and maintained.

7.Connection discovery. One or more connection controllers may be in the network to coordinate connection enrollment as well as recover the current connection status of each device in the network. The connection controller can create a table of all components in a network.

8.Connection removal. This procedure removes network variable connections among devices in a network using automatic, controlled, or manual connection removal.

9.Instance identification. This procedure enables users toper form an action (e.g., push the "connect" button) on a component upon request by a connection controller to identify or verify the instance.

10.Deinstallation.This procedure enables users to performan action (e.g., press and hold the service pin for five seconds) on a component to allow removing all configuration data for the component, which includes the domain, network address, and network variable connections.

However, the ISI protocol has limitations. It is "suitable for small networks with simple network topologies. Example applications in a small building or home network include monitoring and control for appliances, HVAC systems, lights, remote A/V equipment, and security devices" (Echelon 2005a). The ISI network limits the maximum number of components to 32 for simple ISI-S networks and up to 200 devices if using a DAS and all the devices are ISI-DA (for self-installed network) compatible. Furthermore, controlled or manual methods are still the most-used methods for connection enrollment and connection removal procedures due to the complexity in mapping I/O points and resolving system ambiguity for larger or complicated network topologies.

IEEE 1451 defines a comprehensive set of standards for smart transducers normally used outside the HVAC industry. It provides plug-and-play capability between a TIM and an NCAP, as illustrated in Figure 5. The NCAP is used to communicate and convert information from IEEE 1451 compatible smart transducers (sensors and actuators) to forms compatible with any network, independent of the network protocol. Lee (2000) gave a simple application example of IEEE 1451 similar to that shown in Figure 6. The NCAPs in Figure 6 not only can convert smart transducer signals to and from the operator workstation but also can run local application software to form a distributed control loop. The curved arrows in Figure 6 indicate the possible information flow (data exchange between two control system components). Ethernet NCAPs are commercially available and can be acquired to build Web-based applications.


The major limitation for IEEE 1451 compatible sensors and actuators being used for HVAC applications is that there are no substandards to define an IEEE 1451 smart transducer with the BACnet object model or the LonWorks protocol yet. Therefore, there is no NCAP available to convert smart transducer information directly to BACnet or LonWorks protocols. The IEEE 1451 standard committees and ASHRAE BACnet/ Echelon LonWorks standard committees need to work together to resolve this issue. Another limitation is that the IEEE 1451 family of standards defines the lower layer plug-and-play specifications but depends on the individual measurement and data acquisition manufacturers to implement the plug-and-play and self-configuring feature at higher levels. The reason is that it does not have a standardized configuration procedure similar to the LonWorks ISI protocol.

Technology Gap Analysis for Resolving System Component Ambiguity

A large technology gap exists in applying the plug-and-play and self-configuring concept from the IT industry to the HVAC industry. This is because an HVAC control system involves many control loops, and the logical locations of the inputs and outputs involved need to be correctly identified, which means the system component ambiguity needs to be resolved. For example, an important piece of equipment in a commercial building HVAC system is the AHU. Many components are involved in operating and controlling the AHU--multiple temperature, relative humidity, pressure, airflow, and water flow sensors, as well as pumps, dampers, valves, etc. For different sensing and actuating components, even though some smart sensors and actuators have the self-describing feature, the logical locations for the same type of sensor/actuator may be different when used on a specific project. For example, a temperature sensor manufacturer does not know whether a specific sensor would be used to measure supply air or return air. Another point is that the logical location of a component may not be recognized based on its physical location. A room temperature sensor in Zone A is logically different than a temperature sensor in Zone B, even though the two sensors may only be on the opposite side of a thin wall that separates the two zones. Therefore, after the smart sensors/ actuators are automatically discovered by the control system, the next step is to distinguish the logical locations of these components so the binding list of inputs and outputs of all control loops and monitoring points can be mapped based on the designed point list and the actual connected components.

There is no generic methodology or algorithm developed for automatically resolving system component ambiguity for HVAC control systems. Neugschwandtner (2006, 2007) recognized that, for mapping or binding the correct inputs/ outputs in the system, each component needs to be told its purpose in the control system based on the project design. Ideally, each component should be able to find this information automatically. A way of resolving system ambiguity semiautomatically is suggested by Neugschwandtner. First, a control system needs to have central configuration manager software installed. The user enters a serial number or assigns a unique device tag for each component in the manager soft-ware and broadcasts the number or tag to the control network. Then all networked devices are put into listening mode and retrieve their identifications. Finally, the configuration manager lists possibilities for each device, and the user has to confirm or disapprove the list.

To map component inputs/outputs in the LonWorks ISI protocol, a connection model was developed and used in the self-installation procedure for automatic, controlled, and manual enrollment modes (Echelon 2005a). ISI connections (or mappings) are created among connection assemblies. A single network variable is called a simple assembly, and a connection assembly consisting of more than one network variable (e.g., a control loop) is called a compound assembly. The procedures of mapping inputs and outputs are similar to the steps outlined by Neugschwandtner. No algorithm for resolving HVAC system component ambiguity is specified in the protocol, and the "self-installation" procedure is only good for small-building or home automation applications with simple network topology and simple inputs/outputs mapping, where little component system ambiguity exists. Even then, some human intervention is still needed during the setup and commissioning process.

Technology Gap Analysis for Self-Configuring HVAC Control System

There is a huge gap between a plug-and-play and a self-configuring HVAC control system, because a self-configuring system involves a major step to automatically create the binding list of inputs/outputs based on the design intent. This is rather difficult because

1.there are many possible different design options for HVAC projects;

2.for a specific HVAC design, different BAS manufacturers often implement control strategies differently. There are no standardized control strategies (like a "template") available, though ASHRAE is doing research towards this goal (RP-1455, "Advanced Control Sequences for HVAC Systems"); and

3.even with a standardized control system design, how to automatically covert the design to a computer object model and then into different control languages is a big question. For small and simple projects, it may be easy to do, as the LonWorks ISI protocol demonstrates in its specification and programmers' guide (Echelon 2005b), but it is very hard, if not impossible, to do this for a complicated, large project with many control loops at field levels and global controls at higher levels.

To fill these gaps, the following technology advancements need to be in place:

1.The most common HVAC designs need to be categorized and standardized.

2.An algorithm needs to be developed for mapping design intent to a computer object model. The algorithm should be flexible and scalable to cover most common HVAC functions and control strategies.

3.Common HVAC control strategies/sequences are standardized.

4.Technology advancement is made so that it is possible to automatically convert a common computer object model for a specified control strategy to different BAS control languages.

Though ASHRAE has started work toward the first goal, it still has a long way to go before the mapping of selected control strategies to actual control programs is feasible.

A Plug-and-Play Framework for an AHU

Commercial HVAC systems usually include the following subsystems: AHU, distribution system, terminal systems, heating equipment, and cooling equipment. As discussed in previous sections, many technology gaps exist that prevent implementation of a plug-and-play or self-configuring HVAC control system. A plug-and-play framework for an AHU control system is needed and is developed in this paper to provide a possible model and starting point for future expansion of similar research to the whole HVAC control system.


AHU Monitoring and Control Points

The AHU (illustrated in Figure 7) is a very important piece of equipment in an HVAC system. It is used to receive heating or chilled water generated by heating equipment (e.g., boiler) and cooling equipment (e.g., chiller) and condition the mixed air through heat exchange with the heating or cooling coil to provide conditioned air to the terminal units serving the zones. The major components in an AHU include the supply and return fans for delivering air, cooling and heating coils for heat transfer from water to air, outside air, return air and exhaust air dampers for regulating airflows, and chilledwater pumps and heatingwater pumps for pumping heat transfer fluids (i.e., hot and chilled water). A comprehensive list of control inputs and outputs in an AHU is categorized in Table 2. It is worth mentioning that Table 2 lists the inputs and outputs that could be present in a highly instrumented AHU. However, most AHUs may only have a subset of the sensors listed, and the plug-and-play framework described in this paper and the temperature sensor auto recognition technique described in Part II (Zhou and Nelson 2011) of this paper do not require all of these control points to be available.
Table 2.   AHU Control Inputs and Outputs

Category         Point Names  Description
                 OA-TEMP      Outside air temperature
                 MA-TEMP      Mixed air temperature
                 SA-TEMP      Supply air temperature
                 RA-TEMP      Return air temperature

AI *:            CHWC-DAT     Chilled-water coil discharge air
Temperature                   temperature
                 HWC-DAT      Heating-water coil discharge air
                 CHWC-EWT     Chilled-water coil entering water
                 CHWC-LWT     Chilled-water coil leaving water
                 CHWC-MWT     Chilled-water coil mixing water
                 HWC-EWT      Heating-water coil entering water
                 HWC-LWT      Heating-water coil leaving water
                 HWC-MWT      Heating-water coil mixing water

AI: Pressure     SA-SP        Supply air duct static pressure
                 SF-DP        Supply fan differential pressure
                 RF-DP        Return fan differential pressure

AI: Relative     SA-HUMD      Supply air relative humidity
humidity         RA-HUMD      Return air relative humidity
                 SA-CFM       Supply airflow rate

AI: Airflow      RA-CFM       Return airflow rate
                 OA-CFM       Outside airflow rate

AI: Water flow   CHWC-GPM     Chilled-water coil flow rate
                 HWC-GPM      Heating-water coil flow rate

AI: Damper       OA-FDBK      Outside air damper feedback
feedback         RA-FDBK      Return air damper feedback
                 EA-FDBK      Exhaust air damper feedback

AO*: Fan speed   SF-SPD       Control signal for supply fan speed
                 RF-SPD       Control signal for return fan speed

AO: Valve        CHWC-VLV     Control signal for chilled water
position                      valve
                 HWC-VLV      Control signal for heating water

AO: Damper       OA-DMPR      Control signal for outside air
position                      damper
                 RA-DMPR      Control signal for return air
                 EA-DMPR      Control signal for exhaust air

DI*: Fan status  SF-STS       Supply fan ON/OFF status
                 RF-STS       Return fan ON/OFF status

DO *:  Fan       SF-SST       Supply fan start/stop
start/stop       RF-SST       Return fan start/stop

DO: Pump         CHWP-SST     Chilled-water pump start/stop
start/stop       HWP-SST      Heating-water pump start/stop

* AI: Analog Input; DI: Digital Input; AO: Analog Output;
DO: Digital Output

As defined in previous sections, plug-and-play HVAC control system components should be recognized automatically without human intervention once installed. This involves automatic discovery of those components, as well as resolving system ambiguity about logical locations of these sensors/ actuators. A plug-and-play AHU control system also enables the components in Table 2 to be freely plugged into the control network via a network interface or controllers without preassignment of controller channels or network addresses. The system can then discover and recognize the component types and logical locations. If the same type of sensors/actuators change or swap channel positions or network addresses, the components can still be identified correctly. The framework will conceptually define the architecture of the control system, requirements of the communication networks, requirements for its components, and sequence and methodology for automatically identifying the logical locations of these components.


Since many required products or technologies are still not commercially available to fill the technology gaps for a plug-and-play AHU control system, some reasonable assumptions should be made:

1. All sensors/actuators should be identifiable by type. The control system components should be able to be distinguished automatically by their types--e.g., temperature, pressure, airflow, damper, valve, etc.--even though the logical location may not be preprogrammed by the sensor/actuator manufacturer. BACnet defines 25 object types including "analog input," "analog output," "binary input," and "binary output," but these object types are not categorized further to more detailed types (e.g., temperature and pressure sensors all belong to the analog input type, but they measure different properties). Some manufacturers do put sensor type information on the optional "Device_Type" property in the BACnet object though. A workaround is to generate a database of all sensor/actuator model numbers and determine the sensor/actuator type by its "Model_Name" property. For LonWorks devices, the SNVTs can be used to distinguish different sensor/actuator types. The self-documenting string in the SNVTs may also help. IEEE 1451 compatible smart sensors/actuators have manufacturer ID, model number, and transducer types on the TEDS embedded in the trans-ducers. Some sensor types (e.g., temperatures) are categorized with substantial detail. However, most sensor types commonly used in the HVAC industry may not yet be available in the current IEEE standards.

2. All components of the plug-and-play AHU control system should be able to communicate throughout the network. No matter which smart sensors/actuators are used in the plug-and-play system, as components in the direct digital control system, they have to be able to communicate with the controls network and possibly with each other.

One choice is to use the same communication protocol throughout, e.g., an allBACnet control system or an allLonWorks control system. The disadvantage of this approach is there may be less or no choice for some of the smart sensors/actuators available on the market. A second choice is to use different communication protocols at various levels, but this approach requires a protocol conversion device as a bridge or gateway that enables one protocol to be converted to the other, for example, to use IEEE 1451 compatible smart sensors/actuators in a BACnet or LonWorks control system. The problem is that no IEEE 1451 substandard has been developed yet to process the IEEE 1451 compatible smart sensor/actuator information (e.g., TEDS) and to convert to a BACnet object's or LonWorks SNVT's parameters. This critical capability is necessary for the approach to be feasible.

3. All components have to pass functional tests in the field. All sensors and actuators, as well as other HVAC system components related to control points in Table 2, have to function properly in the field before the algorithm to solve system ambiguity process starts. This eliminates the possibility of false identification because of nonfunctional components.

4. Chilled-water and heating-water temperatures and water flow rates should be within reasonable ranges around the design values. This is critical in the proposed algorithm used to resolve system component ambiguity (presented in Part II) (Zhou and Nelson 2011).


The plug-and-play framework for an AHU is one part of the plug-and-play framework for an HVAC control system (yet to be developed), which may include other subsystems, such as zone control, chilled-water and heating-water control, etc. The architectural diagram of the plug-and-play framework for an AHU is illustrated in Figure 8.

There are two sections in this framework architecture: (1) AHU smart sensors/actuators that cover all the points listed in Table 2 and (2) the AHU control system. The smart sensors/actuators have, at least, device type information (e.g., temperature, pressure, damper) embedded in the device. The AHU control system consists of a centralized operator work-station/server with a user interface and self-configuration soft-ware, network controller(s) for global networked control, local controller(s) with or without integrated transceivers, and standalone transceivers. The transceivers convert smart sensor/transducer information from various field bus protocol(s) to the protocol used by the control system. The "transceiver" here is a general term referring to the independent component that serves as the NCAP in IEEE 1451 standards. For example, if the sensors/actuators used are IEEE 1451 smart transducers, and the control system's protocol is BACnet, then the transceivers are the IEEE 1451 NCAPs that convert IEEE 1451.x to BACnet (though such an NCAP has yet to be developed). If the control system's protocol is LonWorks, then the transceivers are IEEE 1451 NCAPs that convert IEEE 1451.x to LonWorks protocol (yet to be developed).

The framework specifies different possible ways for smart components to be connected to the control system:

1. Through direct connection if the smart transducer uses the same protocol as the control system, or it is an integrated smart transducer with the transceiver embedded.

2. Through the controller with the transceiver embedded so it can also communicate with smart transducers at the field level and with the control network at the automation/ management level.


3. Through a controller without the transceiver embedded using a separate transceiver.

4. Through an independent transceiver. Smart transducer information is converted from the field bus via this transceiver to the network protocol used by the control network.

Plug and play in this framework refers to the interoperability of smart transducers in the control system (i.e., all the smart transducers are able to physically connect to any channel/port of any transceiver or local controller with the integrated transceiver and establish communication). The capability of the BAS to automatically identify the logical location of each smart transducer is also required under this framework. Therefore, self-configuration manager software is needed that automatically detects and identifies inputs and outputs that are connected to the AHU. The software shall have two major processes:

1. auto-discovery of all sensor/actuator points

2. auto-identification of logical locations of those points

The first process requires that smart transducers have the self-describing feature and a plug-and-play or self-configuring specification defined for the control network (e.g., the IEEE 1451 set of standards or LonWorks ISI protocol). Some BASs already have the auto-discovery feature in their software.

The second process of auto-identification of logical locations of AHU inputs/outputs is another critical step in the plug-and-play framework for an AHU as well as the future self-configuring control system. The algorithm for auto-identification is based on the following observation/assumption:

Any distinct input/output point in an AHU serves a unique purpose (except redundant points used for reliability). Therefore, given a specified sequence of operation on the combination of system outputs, the inputs from different logical locations should display identifiable, unique, time-series patterns. The logical locations of these inputs/outputs can be recognized by studying the sequence of operations and the patterns generated.

It can be seen from Table 2 that there are more temperature sensors on an AHU than any other type of transducers. If these temperature sensors are correctly identified, other inputs and outputs will be relatively easy to identify. The details of the sequence of operations and the pattern recognition algorithm are presented in Part II (Zhou and Nelson 2011) of this paper.

The AHU control system controller or I/O modules (including standalone transceiver) need to be able to read smart sensor/actuator information and communicate with them over the network. The control system should have multiple PID control loops that can be used for AHU control processes listed in Table 3.
Table 3.   Typical AHU Control Processes

Process                 Related I/O  Description

Supply air temperature  SA-TEMP      Supply air temperature
control                 CHWC-VLV     Chilled-water valve
                        HWC-VLV      Heating-water valve
                        CHWP-SST     Chilled-water pump
                        HWP-SST      Heating-water pump

Supply air duct static  SF-SP        Supply air duct static
pressure control                     pressure
                        SF-SPD       Supply fan speed
                        SF-SST       Supply fan start/stop

Return fan speed        RF-SPD       Return fan speed
control                 RF-SST       Return fan start/stop
                        SF-SPD       Supply fan speed
                        RF-CFM       Return fan airflow
                        SF-CFM       Supply fan airflow

AHU dampers control     OA-DMPR      Outside air damper
                        RA-DMPR      Return air damper
                        EA-DMPR      Exhaust air damper
                        OA-TEMP      Outside air temperature
                        SA-TEMP      Supply air temperature
                        RA-TEMP      Return air temperature

The realtime information exchange and PID control loop configuration are very flexible in this plug-and-play framework. If the input/output points related to any of the control loops listed in Table 3 are physically connected to the same control module, the PID control can be done in one controller, as commonly implemented in current BASs. The network controller can also be used to apply distributed control (vs. physical control in a hardware PID loop in a local controller), where inputs and outputs are not necessarily connected to the same controller. Another possibility is to use software PID or advanced control algorithms (e.g., fuzzy logic control) executed in a workstation/server. If PID control functionality can be embedded in the transceiver (similarly to the IEEE 1451 NCAP application processing units), simple PID control loops can also be executed at the transceiver.


This paper presents part I of work in which the plug-and-play and self-configuring HVAC control system are defined and related critical technologies reviewed. Technology gap analysis is done for components, a communication network, and algorithms to resolve system ambiguity. A plug-and-play framework for an AHU control system is then proposed. The first step to achieve plug and play and self configuring for an AHU control system is for smart sensors/transducers with plug-and-play capability to be used for all inputs/outputs, and self-configuration manager software be installed on a centralized server/computer. The software will explore and discover all control system components on the network, either use standardized communication protocols or transceivers to convert information from other protocols. After all sensor/actuator types are recognized, the self-configuration manager sends commands to action devices and runs a pattern recognition algorithm (proposed as Part II [Zhou and Nelson 2011]of this work in a companion paper) to identify the logical location of each component. This enables the self-configuring program to map detected I/O points to a binding list generated based on standardized control sequences that fit control system design intent, and finally, autoconfiguration of the control loops and programs can be realized. This plug-and-play framework for AHU will provide a roadmap to future plug-and-play and self-configuring HVAC systems, even though the standardization of common control strategies and automatically converting design intent to a DDC programming language will still need future research.


The work described in this paper was sponsored by the Iowa Energy Center through financial support and the use of its Energy Resource Station facility. The authors would like to thank facility manager Mr. Curtis Klaassen for his strong support and promotion for this project. The authors would also like to thank the reviewers for providing invaluable comments that improved the quality of the manuscript.


EIA. 1997. ANSI/TIA/EIA Standard 232-F-1997 (R2002), Interface between Data Terminal Equipment and Data Communication Equipment Employing Serial Binary Data Interchange. Washington, DC: Energy Information Administration.

EIA. 1998. ANSI/TIA/EIA Standard 485-A-1998 (R2003), Standard for Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems. Washington, DC: Energy Information Administration.

Armson, M. 2002. Before you plug and play: Things to consider. White paper, Sensotec, Inc., Columbus, OH.

ASHRAE. 2004. ANSI/ASHRAE Standard 135-2004, BAC-net-A Data Communication Protocol for Building Automation and Control Networks. Atlanta: American Society of Heating, Air-Conditioning and Refrigeration Engineers, Inc.

ASHRAE. 2008. ASHRAE Vision 2020. American Society of Heating, Refrigerating and Air-Conditioning Engineers, Atlanta. docLib/Public/20080226_ashraevision2020.pdf.

Compaq, Hewlett-Packard, Intel, Lucent, Microsoft, NEC, Philips. 2000. Universal Serial Bus Specification, revision 2.0. zip.

DOE. 2005. Brambley, M.R., D. Hansen, P. Haves, D.R. Holmberg, S.C. McDonald, K.W. Roth, and P. Torcellini. Advanced sensors and controls for building applications: Market assessment and potential R&D pathways. Report PNNL-15149 prepared by the Pacific Northwest National Laboratory for the DOE under contract DE-AC05-76RL01830, U.S. Department of Energy, Washington, DC.

Echelon. 2005a. ISI protocol specification, version 3. Echelon document #078-0300-01F. Echelon Corp., San Jose, CA..

Echelon. 2005b. ISI programmer's guide. Echelon document #078-0299-01F. Echelon Corp., San Jose, CA.'s_GuideV3.pdf.

Echelon. 2009. Introduction to the LonWorks[R] platform, revision 2. Echelon document #078-0183-01B. Echelon Corp., San Jose, CA.

IEEE. 1997. IEEE Standard 1451.2-1997, Standard for a Smart Transducer Interface for Sensors and Actuators-Transducer to Microprocessor Communication Proto-cols and Transducer Electronic Data Sheet (TEDS) For-mats. New York: The Institute of Electrical and Electronics Engineers, Inc.

IEEE. 1999. IEEE Standard 1451.1-1999, Standard for a Smart Transducer Interface for Sensors and Actuators-Network Capable Application Processor (NCAP) Information Model. New York: The Institute of Electrical and Electronics Engineers, Inc.

IEEE. 2003. IEEE Standard 1451.3-2003, Standard for a Smart Transducer Interface for Sensors and Actuators-Digital Communication and Transducer Electronic Data Sheet (TEDS) Formats for Distributed Multidrop Systems. New York: The Institute of Electrical and Electronics Engineers, Inc.

IEEE. 2004. IEEE Standard 1451.4-2004, Standard for a Smart Transducer Interface for Sensors and Actuators-Mixed-Mode Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats. New York: The Institute of Electrical and Electronics Engineers, Inc.

IEEE. 2007a. IEEE Standard 1451.0-2007, Standard for a Smart Transducer Interface for Sensors and Actuators - Common Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats.

New York: The Institute of Electrical and Electronics Engineers, Inc.

IEEE. 2007b. IEEE Standard 1451.5-2007, Standard for a Smart Transducer Interface for Sensors and Actuators-Wireless Communication and Transducer Electronic Data Sheet (TEDS) Formats. New York: The Institute of Electrical and Electronics Engineers, Inc.

IEEE. 2008. IEEE Standard 1394-2008, Standard for a High-Performance Serial Bus. New York: The Institute of Electrical and Electronics Engineers, Inc.

IEEE. 2010. IEEE Draft P1451.7/D1.3, IEEE Draft Standard for a Smart Transducer Interface for Sensors and Actuators-Transducers to Radio Frequency Identification (RFID) Systems Communication Protocols and Transducer Electronic Data Sheet Formats. 0245.

Kastner, W., G. Neugschwandtner, S. Soucek, and H.M. Newman. 2005. Communication Systems for Building Automation and Control, Proceedings of the IEEE, 93(6):1178-1203.

Ko, W.H., and C.D. Fung. 1982. VLSI and intelligent trans-ducers. Sensors and Actuators 2:239-50.

Lee, K. 2004. Introduction to IEEE 1451 family of standards. Wireless Sensor Standard Workshop/Meeting Sensors Expo/Conference presentation, June 7-9, Detroit, MI.

Lee, K. 2000. IEEE 1451: A standard in support of smart transducer networking. Proceeding of the 17th IEEE Instrumentation and Measurement Technology Conference, May 1-4, Baltimore, MD, 2:525-28.

Microsoft. 2007. PnP-X: Plug and Play extensions for Windows specification. Microsoft Corporation, Redmond, WA.

Neugschwandtner, G. 2006. Towards plug and play in home and building automation networks. Proceedings of the 11th IEEE International Conference on Emerging Technologies and Factory Automation, September 20-22, Prague, Czech Republic, pp. 461-64.

Neugschwandtner, G. 2007. Plug and play in distributed home and building automation systems: An introduction. Presentation at KNX Scientific Conference, November 15-16, Duisburg, Germany.

OMG. 2003. Smart transducer interface specification. Adopted specification, Object Management Group, Inc., Needham, MA.

Shanley, T. 1995. Plug and Play System Architecture, Addison-Wesley Publishing Company, Reading, MA.

Song, E., and K. Lee. 2008. Understanding IEEE 1451--Net-worked smart transducer interface standard. IEEE Instrumentation & Measurement Magazine 11(2):11-17.

Sun. 2003. Jini Technology Core Platform Specification, version 2.0. Sun Microsystems. Santa Clara, CA.

UPnP Forum. 2008. UPnP Device Architecture 1.0.

Zhou, X., and R.M. Nelson. 2011. A plug-and-play frame-work for an HVAC air-conditioning unit and temperature sensor auto recognition technique--Part II: Pattern recognition and tests. ASHRAE Transactions 117(2).

Xiaohui Zhou,, PhD Ron M.. Nelson,, PhD, PE

Xiaohui Zhou is an associate scientist at the Iowa Energy Center, Ankeny, IA. Ron M. Nelson is a professor in the Mechanical Engineering Department, Iowa State University, Ames, IA.
COPYRIGHT 2011 American Society of Heating, Refrigerating, and Air-Conditioning Engineers, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2011 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Zhou, Xiaohui; Nelson, Ron M.
Publication:ASHRAE Transactions
Article Type:Report
Geographic Code:1USA
Date:Jul 1, 2011
Previous Article:Impact of decentralized controllers for temperature control on control performance.
Next Article:A plug-and-play framework for an HVAC air-handling unit and temperature sensor auto recognition technique--part II: pattern recognition and tests.

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters