EMAIL INTERVIEW - Andy McMillan & Ken Sinclair

Andy McMillan, President & CEO, Teletrol Systems Inc.

Andy McMillan is the president and CEO of Teletrol Systems Inc., an industry leader in building automation technology. With over 20 years experience in open systems and data communications protocol standards, Mr. McMillan has held marketing, technical and executive leadership positions in a variety of automation hardware and software companies. He co-authored a book on open systems and for several years chaired a global consortium of open systems automation users and suppliers. He holds MBA and BSEE degrees from the University of Michigan and is a member of the BACnet Manufacturer's Association Board of Directors. His experience consistently provides an eye opening and pragmatic point-of-view for many users in the building automations systems industry.

XML in Building Automation -- Is it REALLY the next BIG thing?

Sinclair:  Why are XML and web services getting so much attention in the BAS community?

[an error occurred while processing this directive]

McMillan:  From my perspective, much of the recent hype concerning XML and Web Services is the result of tactical positioning by competing suppliers and standards developers. They are "state-of-the-art" technologies, make good press and give the technical folks something new and exciting to talk about. On a strategic level though, I don't see XML and web services as the "next big thing" in BAS. Not that I think XML and web services are going away. After all, Teletrol's Internet-powered product, eBuilding, was designed from the ground up around XML in order to make it very "IT-friendly." Still, I foresee adoption of these technologies as "non-disruptive" in the sense that they will be readily incorporated in BAS equipment with little or no impact on industry structure or business models. Indeed, I believe there are other technologies on the horizon that have as much or more potential to re-shape the BAS industry at a strategic level. Wireless mesh networks and MEMS sensors come to mind.

In my BuilConn 2003 keynote address I used analogies from the "Wild Wild West" to outline some of the risks and potential rewards of doing business in the BAS Open Systems market. One of the points I made in that presentation was that if you were going to be successful in searching for gold, it would help to be able distinguish between facts and myths. In the same way, planning for success in next generation BAS systems will be a lot easier for people who can distinguish between substance and hype.

Sinclair:  How does XML relate to BACnet, LON and proprietary BAS communication solutions?

McMillan:  For most of us, XML is just another specification detailing how to encode information, generally for use in a communications network. BACnet, LonWorks and proprietary systems also include information encoding as a part of their respective specifications. What makes XML special is that it is the encoding specification incorporated in IT infrastructure, both within major companies and across the world wide web. It is also a key component of the emerging IT standard for deploying interoperable systems.

Note that BACnet, LonWorks and proprietary solutions are complete communications systems. XML is not a complete communication system. It must be combined with other components to provide a solution. While it can, in principle, be layered on top of many communications components, most solutions relevant to BAS combine XML with Ethernet, TCP/IP and HTTP. This is the combination generally referred to as "XML" solutions in general discussions and is the combination incorporated in much of the infrastructure of the World Wide Web. When talking about XML versus BACnet or LonWorks, it is important to remember this distinction.

A key difference between XML solutions and BACnet/LonWorks solutions is that XML is designed for systems that have high communications bandwidth and substantial processing power. For example, encoding information in XML can result in a message that is ten times larger than the same message encoded using BACnet encoding. So, while XML solutions are ideal for the upper boundary of BAS systems where their Ethernet networks interface to IT systems, BACnet/LonWorks is a much better fit for the lower level communications where multi-drop RS-485 networks connect network controllers to input/output devices and application specific controllers.

[an error occurred while processing this directive]Sinclair:  What are the benefits XML brings the BAS industry in the near term?

McMillan:  XML provides two immediate benefits BACnet, LonWorks and proprietary solutions can never match. The first benefit is that systems incorporating XML are inherently more "IT-friendly" than systems that utilize any other encoding, especially when XML is combined with standard networking components like Ethernet, TCP/IP, HTTP and SOAP. Because IT infrastructure is built on these standards, IT professionals are familiar with them and their security and analysis tools are designed to accommodate them. As a result, appropriate use of these standards make BAS systems compatible with IT infrastructure and accelerate integration of BAS information in business systems (see "Great Walls and Small Gates" published in Technology Century magazine). They also facilitate the use of the world wide web as part of a distributed system architecture reducing the cost of entry for multi-site BAS solutions.

The second benefit of XML is that the cost of developing the technology has been (and continues to be) borne largely by the "big guys" in the commercial computing world. (The "big guys," by the way, are companies like Microsoft, Oracle and IBM whose R&D budgets are bigger than the total revenue most suppliers in our industry reap from BAS products.) As a result, the BAS community can leverage all of that investment by taking advantage of the XML capability incorporated in operating systems, web servers, document editors, software development tools and many other commercial software products. This lowers the cost of product development and provides an additional degree of system interoperability.

Sinclair:  How important is XML in the long term future of BAS solutions?

McMillan:  XML is the future of BAS at the point where it integrates with IT systems. Over the next few years all BAS systems will have to utilize the IT infrastructure and the IT community will gradually require XML at that level in BAS systems. So, in that sense it is critical. However, compatibility with IT infrastructure does not require an industry standard for the use of XML. Yet, there is a lot of energy being expended right now on the topic of a "standard" for the use of XML in BAS systems, so it is worth considering why that is.

I believe the push for an industry standard is driven by the assumption that there is a need for interoperability of systems that cannot be provided by existing standards. This is, however, only an assumption and its validity depends a great deal on related assumptions about adoption rates for BACnet, the evolution of energy markets, trends in real-estate management and other factors that have not been widely discussed in the recent public discussions about XML and its use in BAS. The following question was raised at the first meeting of the ad-hoc group creating a document it promotes as oBIX: "What is the business problem for users of BAS systems that we are trying to solve with this?" It was not answered in that meeting and has not been answered to my satisfaction any time since. Instead, the collection of technical work on this topic that has been done in multiple forums addresses many different agendas, only some of which are focused on solving user problems.

Sinclair:  Why are multiple groups working on XML for BAS?

McMillan:  The various groups working on XML for BAS are made up of individuals and those individuals have a variety of agendas. Some are purely commercial, some are purely technical, some are more personal than corporate and some are what I would call "techno-religious." These different agendas lead people to seek (or create) different forums where their specific agenda(s) can be most easily advanced. Is this good for the industry? Probably not. Is it good for the companies these individuals work for? Maybe, maybe not. Are multiple groups likely to go away just because it would make a lot more sense to have one group? If my long experience with open systems development is any guide, the answer would sadly have to be -- most assuredly not.

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

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