EMAIL INTERVIEW

Ken Sinclair and Rand Arnold 

Mr. Arnold is founder and president of ControlShop, a product reseller aimed at leveraging the growth in demand for automation systems based on open standards. He is also a principal of Objective Automation, a consulting firm focused on the delivery of integrated automation systems based on open standards. Mr. Arnold is based in Austin, TX and can be reached at rand@controlshop.com.

What do We Mean by Open Systems?

A system in today’s market is not complete if it does not provide Internet access.  The Internet Protocol suite is the standard on which the Internet is built.  An open control system must provide for encapsulation of the control system messages or packets into TCP/IP datagrams. Messages can then be passed around the world without translation into foreign protocols. The cost of transmission is minimal and the ability to leverage existing infrastructure practically limitless.

[an error occurred while processing this directive]Sinclair - Numerous companies now characterize their systems as 'open'. What do they mean? 

Arnold:  Openness in a product or system is fundamentally a measure of the level of standardization in the non-application specific elements. The degree of openness is effectively proportional to the degree of standardization. Standards are the foundation upon which openness is built. To achieve any degree of 'openness', certain standards must be established and agreed to. While the building automation industry certainly has not lead the charge in establishing protocol/communication standards, it is slowly recognizing the value. The two standards receiving the most press in our industry are LonWorks and BACnet. Remember, however, that a variety of other standards are also playing a critical role, like IEEE 802.11(Ethernet), the IP protocol suite, and other Internet related standards like XML.

Sinclair - How is 'open' defined in our industry and how is it related to interoperability? Has the definition of 'open' changed over the years? 

Arnold:  Currently, the definition of openness tends to change with both the speaker and the venue. Let's start by agreeing that openness is not a discrete function. Openness is a continuum and means different things to different people. At one time, an open system was simply one that provided a gateway or port with which other systems or vendors could communicate on a very basic level. Some in the industry still refer to their systems as open if they provide a gateway or a box with an RS232 port. If proper documentation and the protocol are provided with the gateway, the system is in fact 'open' in a very limited way.

Today, when people refer to an 'open' or 'interoperable' system they are typically referencing a system in which networked components can be replaced by those provided by another manufacturer. Again there is a range of values for this definition. A common communication protocol like LonTalk or BACnet makes the replacement possible. But a common network database and a common toolset are often required to make replacements cost effective. So confusion continues to reign as sellers and buyers attempt to negotiate a definition of 'open' for each product, system, and installation.

Sinclair - What are the value propositions of "openness" and what benefits does an "open system" have over a proprietary system? 

Arnold:  In theory, openness is good for everyone. Standards in a market economy have proven to be good for both businesses and customers. Standards allow us all to be more efficient and effective, concentrating our efforts on what we do best. When every monitor works with every PC, the customer receives greater choice and flexibility while the manufactures can focus on their specific core competency. The most commonly stated customer goal in the industry is to eliminate vendor lock-in. Customers are tired of being tied to manufacturers by proprietary systems and protocols. Openness also brings the customer greater integration flexibility and the ability to choose from a greater selection of products. By implementing the standards from the IT industry mentioned previously, openness also allows the use of the existing communications infrastructure, increases in distance and delivery, and delivery of the system data to more users via the existing organizational data transfer mechanisms.

Sinclair - If open systems provide real benefits, why are there so few truly open systems being installed? 

Arnold:  Let's admit that openness is not always good for everyone. To many manufacturers, open is a euphemism for commodity. Companies continually seek to differentiate their products, but it is difficult to differentiate a product if 10 others that provide the same functionality can easily replace it in the network. The companies that dominate a market would be subjugating their survival instinct if they embraced openness on every level. The marketing guys at these companies are not stupid. They understand openness as a product-specific strategy, something to embrace on the product level and avoid on the system level. With standard communication protocols between devices, much of the manufacturer system 'magic' is lost. And sometimes manufacturers don't want to expose just how little intellectual property is associated with their products.

Because of this, a primary problem of integrators trying to implement open systems is that our industry has yet to embrace an open market! Many manufacturers talk about open systems and claim open products based on the fact they support a published protocol. But as an integrator or end user, you can't buy the device or tool required to configure it because you are not an 'authorized dealer'. How 'open' is the device or system if you are forced to represent the manufacturer on a full time basis and pay tributes to the manufacturer for the right to use it?

As far as integrators and customers are concerned, implementing a standards-based system is a painful undertaking. Flexibility is the precursor of complexity. Having more choices is not always a pleasant experience. Having to learn a new way of doing things and new technologies is often a mental and financial burden. Closed systems may be limited in function, but they are well-tested and application specific. They also help the integrator keep a closed hand on the customer. So unless there is a specific integration need or request for interoperability, many integrators avoid selling the benefits of open to their customers. It's hard to blame them - we're all in business to make money. Ultimately, the end user must demand it for the industry to provide it.

All that said, standards and the concept of openness continue to creep into building automation. Why? Because customers ARE demanding it. Customers continue to demand more for less - it's their job as customers! To meet the increasing expectations of the customers, manufacturers must leverage standards. It is simply more efficient than having each manufacturer reinvent the wheel. The standards then allow small, innovative companies continue to focus on a particular aspect of a system and provide better price/performance than the large manufacturers that are intent on creating it all. Slowly we move forward.

[an error occurred while processing this directive]Sinclair - What factors are driving the open system movement? 

Arnold:  It's basically all about the increasing customer expectations I mentioned previously. The building automation customer base is quickly becoming 'tech savy'. They've seen the glory of the Internet and they now believe it is their right to access any information from anywhere. They are demanding the convergence of their system and operational data and increased integration of the various subsystems in their buildings.

Sinclair - Is their a difference between 'open systems' and 'open products'? 

Arnold:  Yes. There is an important difference between a collection of interoperable devices and an open system. It is impossible to have an open system without interoperable devices, but quite possible to have a collection of interoperable devices in a closed system. In other words, interoperable devices are necessary, but not sufficient to achieve open systems. Proper network design is the additional requirement to implement a truly open system. Interoperable devices are the most basic component in the development of open systems.

Sinclair - BACnet and the LonTalk protocol are mentioned in every open systems discussion. How are these protocols performing in the market? 

Arnold:  BACnet and LonTalk are the two networking protocols standards that continue to slug it out in the building automation industry. It's worth noting that while BACnet is limited to the building automation world, LonTalk is being used in just about every industry. I point this out because 'standard wars' are typically won on volume. Both standards have entrenched supporters in our industry, many of which are more interested in winning the war or selling product than in helping the integrator or end user. BACnet continues to gather support from the engineering community via ASHRAE, while LonTalk/LonWorks continues to gather the integrators and end users.

In the end it comes down to implementation and LonTalk backers can point to a vast array of manufacturers and products that support the protocol. Thousands of field level devices from hundreds of manufacturers support LonTalk. While most manufacturers claim to support BACnet as well, only a few representing a very small percentage of the market produce field level devices. The most typical BACnet device we see is a gateway of some sort. It appears for now that a stand-off is in place with BACnet providing information level communication and legacy integration and LonTalk providing field level interoperability. This is an unwelcome compromise between the wars many participants and certainly not the best resolution for the end user. Some manufactures like the fact it allows them to talk about open products while selling closed systems. This approach may haunt them in the end, as disenfranchised users come to realize that with a common field network it is relatively easy and inexpensive to remove proprietary gateways and networks and replace them with IP backbones.

Sinclair - Is requiring a standard protocol like LonTalk or BACnet enough to ensure functional interoperability? 

Arnold:  While a good start, quoting a standard communication protocol like LonTalk or BACnet is seldom sufficient to guarantee an open system. To make integration cost effective, a device must not only support standard communication, it must provide a usable interface for configuration. By usable I mean reasonably priced, easy to learn, and easy to implement. Given these two things, an educated integrator can get the job done. Building on this with further standards for network management, etc. allows the integrator to move faster and/or use less skilled individuals.

Sinclair - The 'continuum of openness' would seem to make it difficult for the typical customer to know what to ask for.

Arnold:  Can you describe the optimal open system? Understanding the power of the open infrastructure and leveraging that power by applying it to all control functions is the key to obtaining the optimal open system. Leveraging is achieved by eliminating the walls between building products and systems. Visualize a singular system that leverages a common physical and logical infrastructure to provide holistic building control.

In this case, the entire building is controlled by a single automation infrastructure. A standard wiring scheme allows devices to easily access and share communication media. In order for the user to use these devices easily network services are employed. Since multiple manufacturers make the devices and software on the network, the network services must adhere to a standard. Different network control systems may have different needs, however, and different users may have training in different networking tools. By creating standard network tools that adhere to the network management standard, different users can use the different tools on the same network. Finally, an application level standard for the exchange of information between devices exists so devices can easily communicate.

[an error occurred while processing this directive]Sinclair - Can you provide a checklist for designing an open control system? 

Arnold:  I can certainly point out a few key ingredients. For starters, address wiring. The base for a building wide-open control system is intelligent wiring. Starting with wiring grants the integrator and end-user the ability to quickly and easily install the system as well as make additions and revisions in the future. Almost as importantly, eliminating the physical barriers between systems encourages engineers and owners to create holistic building control. After the wire is in, examine how the devices will communicate. It is crucial that the devices installed on the common infrastructure share information without effort. So the products must adhere to a common communication guideline. As previously determined, this means the devices must use standard communication variables. This is the purpose of standards like LonTalk and BACnet. After communication, consider the effort required for configuration. To make integration easy, a device must not only support standard communication, it must support a standard interface for configuration. Look for guidelines that provide for the physical layer requirements of devices as well as the common data types, configuration capabilities, and installation methodologies. While it's adequate for product manufacturers' to simply document the configuration interface for their device, it's obviously better if they encapsulate the knowledge into program that can be run. Once these aspects are nailed down, its time to think about how the system will be tied together. Standard network management services provide the necessary network services and published interfaces for an open infrastructure. These services allow multiple tools from multiple vendors to coexist on the network. More importantly, it allows the various tools to share the network data. Integration is possible without standardize network management, but it is complex and costly. A system in today's market is not complete if it does not provide Internet access. The Internet Protocol suite is the standard on which the Internet is built. An open control system must provide for encapsulation of the control system messages or packets into TCP/IP datagrams. Messages can then be passed around the world without translation into foreign protocols. The cost of transmission is minimal and the ability to leverage existing infrastructure practically limitless. Finally, limit gateways to the extent possible. At any point in the system where the messages between devices is mapped from one communication protocol to another, the control network effectively ends. The 'mapping' of messages from one protocol to another is accomplished via a gateway. Gateways should only be used for interfacing to legacy systems or in situations where standards are unavailable. Every one knows that gateways have been a staple of the commercial control industry for the last 10 years. They often provide a necessary function. They are, however, bottlenecks in the flow of system data and are inherently performance limiting. Performing the functions of a gateway requires processing power, which translates into higher cost. Gateways also require someone to indicate what should be mapped to what which consumes engineering efforts. Finally, gateways are difficult to maintain. Any change in system parameters has to be addressed at the gateway as well. As a gateway is a transition from one communication protocol to another, it almost always is accompanied by a change in network management schemes. Different management schemes mean different tools are required for either side of the gateway.

Sinclair – Most of our readers are still on the open systems learning curve. Can you recommend some online sources of information concerning these topics?

Arnold:  Absolutely. Of course, one of my personal favorites includes a little information about everything and can be found at http://www.controlshop.com/Resources/Basics/default.htm 
I’d also suggest interested readers refer to the following links as applicable for the indicated topic:
Lonworks Technology - http://www.echelon.com/products/Core/default.htm 
BACnet protocol - http://www.bacnet.org 
Internetworking technologies and protocols - 
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/index.htm 

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

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