Evolving to internet-worked intelligent building services through open communication protocols

ABSTRACT This paper provides an overview of the building automation industry and the migration to open communication protocols in place of proprietary protocols, as well as the rapid movement to internet based interfaces. First, the paper examines the history and evolution of intelligent building services. The paper then compares the merits of competing open communication protocols and considers the possible migration paths that the automation industry is taking toward open internet-worked solutions. 

[an error occurred while processing this directive]

INTRODUCTION 

Most commercial and institutional buildings constructed today include a vast array of microprocessors that intelligently control the mechanical and electrical equipment within the building. As the speed and capability of microprocessors has grown exponentially, manufacturers have taken advantage of their increasing power to give their intelligent systems more features. 

The primary objective of this paper is to educate and inform the reader/audience of the benefits of open platforms for building automation and other intelligent building systems. Open protocol platforms, such as ASHRAE's developed and supported BACnet, offer a method to integrate all intelligent building services including air conditioning, lighting, security, access control, energy monitoring, fire protection, and lifts. The second objective of this paper is to examine where open protocols are taking the industry. In particular this paper will examine the rapid move to internet based interfaces. 

The intent of this paper is to put these statements into context by examining the automation industry as an evolving system. This paper examines the possible migration routes to open solutions, the various solutions proposed by the automation industry, and the most likely end result. Finally, this paper will consider the practical solutions available today in an environment of existing buildings, as compared to the ideal solutions of tomorrow. 

THE EVOLUTION OF AUTOMATION 

[an error occurred while processing this directive]History
For over a hundred years large buildings have had either pneumatic or electric controls to manage the operation of the primary plant in buildings. Over the period of the last quarter century those processes have become controlled by automation. The vast majority of commercial and institutional buildings are constructed today with a series of stand alone intelligent systems controlling the air conditioning, lighting, security and access control, fire protection, vertical transportation, and the electrical power supply system. 

The first automation systems were installed in very large complexes using mini computers to control the air conditioning plant. These early systems were primitive and very expensive but allowed the collection and intelligent processing of operating data for the first time. The first automation systems used a series of transducers and nodes to take data from the field into centrally located mini computers. 

Primarily to make systems more cost competitive, manufacturers took advantage of the continually dropping price and increasing capability of microprocessors to migrate the intelligence of these systems farther and farther out into the field. 

The building automation industry has now evolved to the point where almost all manufacturers offer systems that have a network of powerful primary controllers located in central locations, generally plant rooms, and a large number of low cost secondary controllers residing on sub-networks to control small local plant. 

Interfacing building automation systems to other intelligent building services has been limited and expensive because interfacing has been done through proprietary drivers written on a manufacturer to manufacturer basis. These have several major weaknesses such as:

• High cost because they are expensive to develop and are often restricted to a single platform for the given project.

• They also restrict future options for modifying the controlled systems. Any changes made to the operating system or upgrading to a new version may render the interface inoperable.

The first move to open protocols in the building industry was ASHRAE's decision in 1987 to form Standing Project Committee SPC135 to develop an open communication standard for building automation. 

The first open protocol solution was presented by Echelon Corporation in the early 1990s with their Lonworks protocol, based on their Neuron chip. This has been the dominant method of achieving interoperability. 

In the late 1980s Johnson Controls also had success opening their proprietary Metasys network to outside equipment manufacturers (OEMs) as a means to interface to other mechanical and electrical equipment. However, this didn't help connect to any other automation manufacturers. This method of establishing a de facto standard through open publication of a proprietary standard is quite common in the industrial arena, but not in the buildings arena. 

In 1995 the ASHRAE BACnet standard 135 was published. This was a far more complicated solution than Lonworks, in that it required manufacturers to completely develop their own implementation from scratch. Consequently, the first practical BACnet implementations took several years to reach the marketplace. Competitive bidding on Native BACnet solutions has only been an option for the last two years. 

Over the past five years the Internet has become a driving forces in all facets of IT technology and the automation industry is no exception. Most manufacturers are now moving towards web based interfaces and eliminating the requirement for proprietary software tools for client access of their systems. 

Advantages of Open Protocols and the movement to web based technologies 

Open protocols provide advantages to building owners purchasing control systems. Advantages of open platforms include: · Single seat operation of multiple building services.

• Single seat operation of multiple building services.

• Exchange of data between different building services

• Single front end graphical interface to access systems from multiple vendors

• Competitive bidding on service contracts

• Competitive bidding on retrofits and system expansion contracts.

Web based interfaces are the current direction of the industry and also provide several advantages:

• Unlimited number of points of access to the system without license.

• Single point of residence for graphics. Graphics do not need to be kept up to date in multiple machines.

• Intuitive software access to system. Clients do not need to learn multiple interface software packages. 

[an error occurred while processing this directive]DIFFERENT COMMUNICATION TECHNOLOGIES 

Early communication protocols were written as a single complete package. This has changed; now protocols are written as a series of "layers" each designed to handle a specific communication task. The world has generally accepted the OSI (Open Systems Interconnection) seven layer reference model for communications systems. In order to understand the aspects handled by different physical and data link protocols a summary of the purpose of each of the seven layers follows: 

• Layer 7: The application layer...is where communication partners are identified, quality of service is identified, user authentication and privacy are considered, and any constraints on data syntax are identified. (This layer is not the application itself, although some applications may perform application layer functions.) 

• Layer 6: The presentation layer...is usually part of an operating system, and is where incoming and outgoing data is converted from one presentation format to another (for example, from a text stream into a popup window with the newly arrived text). Sometimes called the syntax layer. 

• Layer 5: The session layer...sets up, coordinates, and terminates conversations, exchanges, and dialogs between the applications at each end. It deals with session and connection coordination. 

• Layer 4: The transport layer...manages the end-to-end control (for example, determining whether all packets have arrived) and error-checking. It ensures complete data transfer. 

• Layer 3: The network layer...handles the routing of the data (sending it in the right direction to the right destination on outgoing transmissions and receiving incoming transmissions at the packet level). The network layer does routing and forwarding. 

• Layer 2: The data-link layer...provides synchronization for the physical level and does bit-stuffing for strings of 1's in excess of 5. It furnishes transmission protocol knowledge and management. 

• Layer 1: The physical layer...conveys the bit stream through the network at the electrical and mechanical level. It provides the hardware means of sending and receiving data on a carrier.

Most communication protocols are starting to be based on common existing standards for individual layers:

• In the building industry, at the physical level and data link levels, Ethernet is the standard for high speed LANs, RS-485 is the standard for low speed LANs, and RS-232 is the standard for point to point communication.

• IP or Internet Protocol is the accepted protocol for the Network Layer.

• UDP and TCP are the complimentary and accepted protocols for the Transport Layer.

• HTML (Hypertext Markup Language), XML (Extendible Markup Language), and HTTP (Hypertext Transfer Protocol) are the standard for Internet communications.

There are a series of complete communication standards being developed or that have been developed for the real time control industry. We are in the midst of "protocol wars" as various parties with vested interests promote their pet protocol. A summary of some of the most common and relevant protocols is listed in Table 1.

TABLE 1 - Common Real Time Control Protocols

There are other industrial protocols such as Profibus and Devicenet that have not been listed. There are many protocols that abound within the industrial market that have been developed by proprietary companies, then made open by the manufacturer. All of the above protocols except BACnet and OPC were started as proprietary interests only, and then published.

A brief description of each protocol is given below for comparison purposes:

BACnet 
BACnet was developed over a period of eight years by ASHRAE (American Society of Heating Refrigeration and Air Conditioning Engineers) standing Project Committee 135. The protocol was developed specifically to address interoperability and proprietary system concerns in the building automation industry. The protocol is now spreading to all facets of the intelligent building services, particularly lighting, security and access control, and fire protection. BACnet is based on a collapsed version of the OSI model, incorporating the Application, Network, Data Link, and Physical layers only.

BACnet defines multiple physical architectures to handle high and low speed networks, as well as point to point connections. This emulates the structure of most automation systems. BACnet defines Objects of information to be communicated over these physical media and defines Services to handle the flow of Objects between BACnet devices. 

Because BACnet is based on a "client-server" model of the world, BACnet messages are called "service requests." A client machine sends a service request to a server machine which performs the service and reports the result to the client. BACnet currently defines 35 message types that are divided into 5 groups or classes. For example, one class contains messages for accessing and manipulating the properties of the objects described above. A common one is the "ReadProperty" service request. This message causes the server machine to locate the requested property of the requested object and send its value back to the client. Other classes of services deal with alarms and events; file uploading and downloading; managing the operation of remote devices; and virtual terminal functions. 

SSPC135, the standing BACnet committee continues to add features to BACnet. In fact, part of the design of BACnet is its planned continual evolution. Addenda A,B,C, D and E have all been incorporated.

DNP3
DNP was originally created by Westronic, Inc. (now GE Harris) in 1990. In 1993, the 'DNP 3.0 Basic 4' protocol specification document set was released into the public domain. Ownership of the protocol was given over to the newly formed DNP Users Group in October 1993, a group composed of utilities and vendors who are utilizing the protocol. Since that time, the protocol has gained worldwide acceptance, including the formation of Users Group Chapters in China, Latin America, and Australia. DNP 3.0 is an open, intelligent, robust, and efficient modern SCADA protocol. The DNP3 protocol is based on the standards of the International Electrotechnical Commission (IEC) Technical Committee 57, Working group 03 who have been working on an ISO 3 layer "Enhanced Performance Architecture" (EPA) protocol standard for telecontrol applications. It is used to exchange data between RTUs (Remote Terminal Units) and remote control points. 

The development of DNP3 was a comprehensive effort to achieve open, standards-based interoperability between substation computers, RTUs, IEDs (Intelligent Electronic Devices) and master stations (except inter-master station communications) for the electric utility industry. DNP has also become widely utilized in adjacent industries such as water / waste water, transportation and the oil and gas industry. 

DNP3 is an open and public protocol. In order to ensure interoperability and longevity of the protocol, the DNP3 User Group has been given ownership of the protocol and assumes responsibility for its evolution. The DNP3 User Group Technical Committee evaluates suggested modifications or additions to the protocol and then amends the protocol description as directed by the User Group members.

EIB European Installation Bus
In building services automation, a distinction is made between three hierarchical levels: the management, automation, and field levels and this is the formal segmentation in Europe under the CEN . 

EIB was originally designed as a field level bus control in Europe. EIBnet has been recently been recognized for the building services automation level as well as the field level.. The proximity of the EIBnet to BACnet makes it easy to transfer data from the automation level to the management level. The EIB was initially developed for the field level with a data signaling rate of 9,600 bit/s. The EIBnet protocol, developed for the automation level, now makes data transfer via Ethernet 10BaseT possible at a speed of 10 megabit/s. Data transfer from the automation level to the management level is made possible by EIBnet's proximity to BACnet. 

EIB is popular in Europe as a field bus protocol in the building industry but has not been visible outside that region.

Lonworks
Lonworks was developed by Echelon Corporation. Lonworks is a dedicated low speed network that talks to Echelon's Neuron chips, essentially a protocol on a chip. This is both Lon's strength and its weakness for building automation applications. Lon is the simplest protocol for manufacturers to implement because most of the development work has been done for them already. The weakness this imparts is that the implementer is fixed in scale by the limitations of the Neuron chip. 

Lon has been widely implemented not only in the building industry, but over a number of diverse industries. Lon communicates over its own low speed bus or over Power Line Carrier, to take advantage of existing power wiring systems. Lon is used in the rail industry and is moving into the residential market. 

A number of Lon companies have formed the Lonmark Association to develop a plug and play approach to fixed algorithm design of various types of air conditioning controllers (eg. FCU, VAV).

Modbus
Modbus® was developed by Modicon for the industrial industry and is the most widely used protocol for that industry throughout most of the world. Modbus is commonly seen in the building industry as an interfacing protocol for equipment that is commonly used in both industrial and building environments, such as variable speed drives. 

Modbus Protocol is a messaging structure, widely used to establish master-slave communication between intelligent devices. Since Modbus protocol is just a messaging structure, it is independent of the underlying physical layer. It is traditionally implemented using RS232, RS422, or RS485 over a variety of media (e.g. fiber, radio, cellular, etc.). MODBUS TCP/IP was recently developed to provide a faster interface and uses TCP/IP and Ethernet to carry the MODBUS messaging structure. MODBUS/TCP requires a license but all specifications are public and open so there is no royalty paid for this license. 

The MODBUS protocol comes in 2 flavours:

• ASCII transmission mode: Each eight-bit byte in a message is sent as 2 ASCII characters. 

• RTU transmission mode: Each eight-bit byte in a message is sent as two four-bit hexadecimal characters.

OPC - OLE for Process Control 
OPC (OLE for Process Control) is a software standard for open software application interoperability between automation/control applications, field systems/devices and business/office applications. Primarily, OPC was developed for the manufacturing environment to allow complete systems such as inventory, conveying systems, and robotics to communicate at a system to system level rather than directly between devices. It was developed with the participation of Microsoft, which pretty much ensured that it would be based on a PC to PC interface. 

OPC defines a common, high performance interface based upon Microsoft's COM/DCOM technology. COM (Microsoft's Component Object Model) enables the definition of standard objects, methods, and properties for servers of real-time information such as distributed control systems, programmable logic controllers, I/O systems, and smart field devices. DCOM (Distributed Component Object Model) is the network-aware version of COM technology, providing data via local-area networks, remote sites or the Internet 

The OPC specification, is maintained by the OPC Foundation, as a non-proprietary technical specification.

X-10 Residential Protocol 
X-10 is a powerline carrier protocol designed for the residential market that allows compatible devices to communicate via the 110VAC power wiring within the house. X-10 allows for a maximum of 256 addresses. X-10 and Lon are the predominant protocols at the residential level. X-10 is included in this list to show the differences between a powerful scalable protocol and a simple practical protocol that has been developed with a single low cost target market in mind. Typically, X-10 devices would have very limited options, such as start/stop and would be programmed from a standard residential PC. 

Protocol Summary and Interfacing Techniques 

All of the above protocols have been suggested by one party or another as the preferred practical solution for the building automation industry. Though there is some crossover the only realistic solutions for the building industry are BACnet , EIB, and Lonworks. EIB has not been seen outside of the European market up to this point. By far, the common protocols in the building market are BACnet and Lonworks, though interfaces to Modbus devices are common. However, Modbus is not generally used as a complete protocol. 

In most buildings today interfacing between either multiple buildings with systems by different vendors or between different building services within the same building is achieved by either dedicated drivers written for that specific project or by standard driver interfaces that are supported by both vendors. The most common driver at the PC level is DDE (Dynamic Data Exchange) by Microsoft. 

BACnet and Lon are the two protocols that are clearly becoming the world standards for building services. There is a rapid movement to Internet based solutions. Lon has solved this by using Cisco routers. BACnet has incorporated Annex J in Addenda B, which was approved last year, to make UDP/IP a part of the BACnet protocol stack.

There is a wide divergence of opinions as to whether one protocol will win out or whether solutions that provide gateways to both protocols that allow clients to choose either preferred protocol for a given application will prevail. 

[an error occurred while processing this directive]CONTEXT OF EVALUATION - MARKET FACTORS 

In order to evaluate the relevance of these variety of open standards to building services it is necessary to look at the requirements of the building services industry. Building services protocols need to be scalable unlike, residential protocols, that can be very limited in size and scope. Industrial protocols historically have been limited in scope to permit them to applied across a wide range of equipment and circumstances. The success of Modbus has come from the fact that industrial processes tend to be more engineering intensive and the expertise of industrial system integrators allows them to customize interfaces on a project by project basis. Due to cost constraints the building automation industry requires more packaged interfaces for more standard forms of information that can be implemented by lower level application engineers than are found in the industrial arena. 

Protocols that are suitable for data processing aren't acceptable for real time processing because of specific messaging requirements for alarming, trending, and event notification that just do not occur in the data processing environment. 

Evaluation of Protocol Options 

In the current market conditions there are realistically two protocols being presented by vendors as solutions to the open protocol expectations of the market, primarily to achieve interoperability. These are BACnet and Lonworks. They are very different approaches. 

Lonworks has been implemented by more manufacturers at the device level than BACnet. Lonworks has been in the market much longer and is much more established. Lonworks is supported by the largest automation manufacturers more so than BACnet. 

Of the different solutions presented for integration of building services BACnet will become the only official world standard. BACnet has been established as multiple national and international standards. (ANSI standard, ASHRAE, CEN standard, Korean National Standard, Arabic Standard). It is the only protocol that is becoming a world standard and is currently at the Committee draft stage as an ISO standard (TC-205). 

Lon is already established as a de facto world standard at the device level. 

BACnet has seen rapid acceptance because architectures can be scaled to any size application. BACnet can be as easily applied at the device level to create an interoperable sub-network of intelligent systems. BACnet can be implemented at the front end providing communication between intelligent systems. At the ASHRAE show in January 2001 in Atlanta, Georgia, USA over eighty BACnet devices from thirty companies were connected on one LAN seamlessly. 

BACnet is much more complex for commercial companies to develop then implementing Lon. For this reason, Lon has a large lead in the commercial market place. As well, many of the large controls manufacturers do not seem to like the exposure that BACnet solutions give to projects being open to their competition for servicing and expansion. All the major controls companies have favored Lon over BACnet. There is a possibility that Lon will prevail in the long run for these two reasons, even though BACnet is a significantly better technical solution for the automation industry. 

A competitive comparison of Lon and BACnet is given below.

Modbus offers interfacing solutions for specific applications. Modbus is commonly used in the industrial environment and is the most commonly used protocol for energy monitoring. Modbus is the most commonly seen other protocol in the building services industry. 

Comparison of BACnet and Lonworks 

BACnet
Strengths:

• Scalable. A complete communication protocol for the management level, automation level, field level. 

• Completely open. Manufacturers can implement the protocol without any licensing fees. 

• Specifically designed to meet the needs of the building industry. 

• Being established as a world standard through ISO and other bodies. No other protocol is under consideration. 

• Constantly evolving. Built in mechanism for updating and enhancing the standard through industry consensus. 

• There is no vested interest controlling the development of BACnet. 

Weaknesses:

• No standardized programming language. Proprietary programming tools must be bought from each manufacturer.

• No standard configuration tools. Proprietary configuration tools must be bought from each manufacturer.

• Expensive for manufacturers to develop. 

• Many large manufacturers are resisting moving to open protocols because of the exposure of service work and expansion to competition.

Lon
Strengths:

• Widest implementation over wide range of applications due to early entry into market.

• Standard programming tools.

• Simple for manufacturers to implement through standardized tools and because the protocol is pre-configured on the Neuron chip. 

• Has power line carrier implementation; BACnet does not. 

Weaknesses:

• Not scalable. Limited by the size and speed of the Neuron chip. Suitable for device level networks only.

• No facility for programming complex routines or large algorithms such as energy management. 

• Licensing fees built into the cost of LNS and Neuron chip to Echelon. 

• Not an end to end solution. Only suitable for device level automation.

• Not based on an open wiring standard. Lon is a proprietary wiring system.

• Proprietary hardware. Neuron chips must be purchased with a licensing fee to Echelon. 

• All Lon solutions require multiple software packages to configure system. 

• LNS network tools are proprietary and must be purchased from Echelon corporation. 

Ideal World, Ideal Protocol, Ideal System 

Let's examine what would constitute an ideal system in an ideal world to give us a context from which to evaluate today's offerings:

• One single communication protocol would be used for all communications. Every device would talk to each other for every intelligent system in the building. Each of the intelligent systems in the building that spoke this common language would be available from a range of manufacturers. These communications could be established and implemented out of the box without specialized engineering and IT commissioning agents. 

• There would be clearly established guidelines for delineation of responsibilities in engineering and commissioning communications between the intelligent systems.

• Single software package for system engineering, including graphics preparation, configuration, and engineering. This single engineering tool could configure and program multiple systems. 

• The client would have simultaneous graphical access to multiple intelligent systems from multiple vendors through software already available on most PCs to diverse locations via the Internet or the client's intranet. This software is already generally accepted to be a web browser. (Windows Explorer, Netscape, or some other web browser).

• Supports enterprise applications by third party APIs for interface to other client enterprises

• Controllers from multiple manufacturers reside on the same LAN 

• Plug and play interchange of controllers between manufacturers

• Multiple system integrators to provide installation, service, and support of system 

• Web based interface to all intelligent systems. 

• Competitive bidding from service companies to handle all the intelligent systems in one building.

• Competitive bidding from multiple system integrators for provision and installation of extensions to system.

We are a long way from this perfect world today. This is for a combination reasons. First, we are still early in the process of evolving to open protocols. Second, there is resistance from equipment providers and system integrators to provide open systems that expose the installation to competition for service work and retrofits. 

Where we are today
The existing market

The majority of older buildings contain legacy systems that are hard wired electric, pneumatic, and electronic control systems for mechanical services and hard wired electric lighting and security systems. The majority of newer buildings have proprietary intelligent systems for some or all of their building services. These systems are rarely integrated. When they are, it is usually through interfaces implementation using one-time drivers that do not allow upgrading of the PC operating system or the two intelligent building services being integrated. 

We are seeing some integration that has been achieved over the last five years using Lon devices at the sub-network level existing on one bus. These tend to be restricted to the air conditioning, and to an extent, to lighting. 

We are just starting to see integrated BACnet systems for multiple air conditioning manufacturers on the same site. BACnet is starting to be commonly used as a common gateway protocol. 

Evolution & migration paths, or "How do we get from where we are today to where we want to go?" 

What are the best solutions that will work well in today's evolving environment that will also provide a system that is well positioned for integrating in the future? Many vested interests are understandably pushing for particular solutions for commercial reasons. So, the best solution depends on what protocols are successful in the long run.

There is no single ideal solution today. Optimum solutions will vary with the individual needs of different types of clients within the constraints of the imperfect solutions available today. Building owners and consultants need to consider what their long term requirements are going to be. If a building is going to have only one small stand alone automation system then the criteria for specifying and evaluating proposals will be very different than for a one building in a large site where there is motivation to integrate all the intelligent building services. 

Additionally, exciting advancements at the software level are moving platforms to internet browser based interfaces rather than proprietary software interfaces. There are a variety of vendors with solutions available today. For a client that is integrating multiple platforms, has multiple sites, or wishes access from multiple locations this is a necessity. 

The majority of newer buildings have proprietary communication protocols for each intelligent building service, each one operating as a completely stand alone system. 

Many organizations that have multiple buildings and sites such as institutional owners like universities or hospitals, and property management companies, and their consultants are now attempting to migrate to open systems to achieve one or more aims:

• Single seat operation of lighting 

• Logical interaction between intelligent systems 

• Multiple manufacturers systems 

• Interaction with energy management

• Interaction with client enterprises such as accounting systems

Virtually everyone in the industry publicly agrees that moving to open protocols for new installations is in the clients best interest. For commercial interests, control companies, and other providers of intelligent building services like fire protection, access control, and vertical transportation companies desperately want to keep large existing clients tied to proprietary systems because of the lucrative service contracts. 

For owners with existing proprietary systems the migration path to open systems may be very complex. Any existing integrations will be through dedicated drivers written expressly for that purpose. These owners need to hire a consultant specializing in automation to advise them in how to migrate. In many cases, particularly in mid size applications the decision migrate to open systems may be dependent on the on the level of cooperation of their intelligent building system contractors. Where the client has a very good relationship with their solution provider, there may not be enough of an incentive to move from proprietary systems, as long as that provider cooperates in providing open protocol gateways to other intelligent building systems. More often than not, these manufacturers have a vested interest in the system remaining proprietary, and corporations aren't known for their altruism, as they have quite rightly have a responsibility to their shareholders to maximize profits.

[an error occurred while processing this directive]CONCLUSION

Today's solutions involve compromise. Selecting the correct automation system today is partially dependent on guessing which protocol will be the world standard.

No single solution is perfect. Legacy systems based on proprietary protocols need to be interfaced to other legacy systems and to the different open protocols as they emerge and as owners migrate to open solutions. The path towards a future single open protocol is complex and it is likely that multiple protocols will remain due to divergence of interests in the market place for the near term. 

The clear trend is towards both open protocols and internet based systems due to the many advantages they provide to building owners. Owners and consultants need to choose solutions that will move all automation towards a completely open environment rather than perpetuating the proprietary solutions of the past, simply because it is less complex and confrontational to continue proprietary implementations. 

BACnet is clearly the most complete protocol for the building industry. However, Lon is much more widely available and entrenched. The best thing for owners to do is to select solutions that will leave them the most flexibility for future changes while providing the most advantages today, such as Internet connectivity.

REFERENCES 

ASHRAE. 2001. 2001 ASHRAE handbook-Fundamentals, Chapter 15 - Fundamentals of Control. Atlanta: American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc. 
www.engineeringtalk.com/ August 2001 
http://www.opcfoundation.org/ August 2001 
www.dsigb.com/opc August 2001 
www.x10.org/ August 2001 
http://whatis.techtarget.com August 2001 
http://www.modicon.com/ August 2001

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]