EMAIL INTERVIEW - Dirk Mahling & Ken Sinclair  

Dirk Mahling, Ph.D., Chief Technology Officer, WebGen Systems

Dr. Mahling is a recognized thought-leader in the areas of portals, intelligent agents and knowledge management. For over ten years, he has been creating bridges between innovative technologies and business to create lasting business advantages. Dr. Mahling has worked as a practice leader in consulting, as chief knowledge officer, as university professor, and as chief technology officer.

Prior to joining WebGen, as Practice Leader at Primix Solutions he brought proven solutions and new ideas to clients and partners. At Ernst and Young's "Knowledge Based Business" team, Dr. Mahling was the chief architect for A.T.Kearney's Knowledge-Net.

Dr. Mahling has a faculty appointment at the University of Pittsburgh, School of Information Sciences, and is past-chair of the ACM's special interest group on groupware and knowledge management. Through his professional and academic involvement, he has contributed to various areas of knowledge management and groupware.

[an error occurred while processing this directive]

Building Automation: Open Systems Today and Tomorrow

Sinclair:  How are open protocols affecting the industry today?

Mahling:  Over the past decade we have seen numerous attempts to create standards and open protocols that would make life easier for people who work with building automation systems. LON, BacNet, and OPC are just the most prominent examples. The idea has always been the same: allow easy interoperability between systems and devices by different manufacturers.

Interoperability would allow building managers to mix and match systems in their buildings such as chillers, air handlers, and digital controllers to best fit their needs. It would allow them to shop for the lowest cost bidder, or pick the most reliable device. In short, it would open up choice.

But the effects go beyond the building. With an open protocol, new functionality, previously thought impossible, becomes a reality. Energy management across a portfolio of buildings is the premier example. Many companies let energy managers purchase energy and negotiate energy contracts. Managing those contracts on a day to day, device by device basis was impossible in the past. With interoperable systems, data can move from building management systems and meters to a central location, and intelligent decisions can be made about pre-cooling, load shifting, peak load avoidance, or other established strategies.

In addition, demand response (DR) contracts can be signed with much more confidence, since the response to DR calls can be automated centrally. The actual response need not even be hard-coded but can be based on flexible strategies a human would use, coded in a central expert system. Thus open protocols open the domain of buildings and energy control to the advances already seen in other fields such as computerized medical diagnosis, image stabilization, or automated battlefield management.

Currently there are numerous systems which appear to be open protocol systems, but keep doing what they have done in the past. That is to say, they merely swap the "mule path" for the data by making it XML. A few systems that truly open up new functionality are emerging. That is the place where the excitement in this industry is right now. These are the systems to watch. This is where every progressive building manager and energy manager should look.

Sinclair:  Why are open protocols only coming about now?

Mahling:  With the ubiquity and success of the Internet, the actual users have realized that IP (Internet Protocol), HTTP (Hyertext Transfer Protocol), FTP (File Transfer Protocol), and XML (eXtended Markup Language) are already the lingua franca for many other industries, such as retail, finance, manufacturing, etc. All requirements of intra-operability (making devices in a building talk to each other) and inter-operability (exchanging data between buildings) can be addressed using these general purpose Internet protocols; thus the case for proprietary systems is gone.

Sinclair:  What is the difference between open protocols and proprietary protocols?

[an error occurred while processing this directive]Mahling:  A protocol, or standard, in the area of networking defines how information is encoded, transmitted, decoded, and applied. There are numerous protocols that work together to make all these functions happen harmoniously. An open protocol is one where the definitions of terms are public knowledge. Anyone can obtain the definition and write code that "speaks" the protocol. Proprietary protocols are like a "secret language" where only the initiated understand what is being said.

One of the best known models for networking is the TCP/IP model, which evolved from ARPANET, the Department of Defense's research network in the 1980s (as a graduate student, the author was heavily involved in the research and deployment of that network). On the lowest level, there are physical host-to-network connections. Wires that connect computers. These computers are networked together and can send data packages to each other in a connection-less fashion. This is called the Internet layer. The protocol governing this layer is called the IP layer. It is here where IP addresses (the zip codes for individual computers) reside.

The next layer is the Transport Layer, which allows peer entities to have a dialogue. TCP (Transmission Control Protocol) is the protocol governing this layer. TCP maintains a reliable connection between two machines. If flow control is not important, UDP can be used in this layer (User Datagram Protocol).

From the building or energy domain, building management systems can take these two layers (TCP/IP) for granted and just piggy-back on them.

The highest layer is the application layer. In this layer the transmitted data is "interpreted" for its final use. This is where XML comes in. XML by itself is a language not a building or energy specific protocol. While BacNet and LON have language elements that talk about domain specific objects (e.g. schedules, speeds, temperatures) XML per se does not. In choosing a way to interpret the transmitted data, it is important to have a system that can work with all three in order to ensure continuity.

Sinclair:  You talked a lot about XML. What exactly is it?

Mahling:  XML is a language on the application layer (another one is HTML, for instance). Such a language allows programmers to make data available to other application programs. XML offers the freedom to talk about domain objects by creating "tags". An example may be <chiller>, where <chiller> could consist of <kw>, <pressure> and other such data tags. These tags establish the DTD (document type definition) which is openly viewable to anyone who wants to write applications that talk to other applications using XML with this DTD. So the simplest way to think about XML is that it allows application programmers to build models of structured data, in a flexible fashion, that can be used and re-used by other application programmers.

Sinclair:  Let's move from data back up to applications, knowledge, and strategies. What should managers do today to either get ready for XML or to reap other benefits immediately?

Mahling:  The first thing to realize is that you do not have to wait for XML to arrive or for everybody to agree on it. Even today you can take steps toward interoperability without compromising your future. Since XML is an Internet standard, XML and its benefits are already present when communicating among buildings. Most enterprise energy management (EEM) systems can handle XML. Gateways that let any type of building management system talk to EEMs translate into XML, which is moved up to the EEM. That way, the user starts pushing XML down from the top of the network. At the portfolio level, building managers can use this information to gain insight to energy consumption, optimal run times, and can compare energy budgets to dollars spent, just to name a few.

With a system like WebGen's Intelligent Use of Energy®, there is at least one EEM in the marketplace that allows you to go one step further. It's the important step from analysis to better performance and savings. Instead of just gathering data from the building management systems and moving it up, systems that go this additional step allow you to control your system. That means turning real-time XML information into real-time monetary savings. Such systems use XML to talk to the gateways, which then translate XML into the native language of the building management system. Once all building management systems are XML compatible, you would not need the gateways anymore, but today this is the way to get ahead of the competition.

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

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