The underlying technology of the Internet is quite good from an academic and scientific viewpoint. But that's not what really contributed to the Internet's success. Internet technology is not that revolutionary. We put a man on the moon back in 1969. For decades people have had the ability to communicate with each other from anywhere in the world using common telephones. So what is it about the Internet that is so amazing? The answer is standards and protocols!

The proliferation of personal computers in the '80s laid the groundwork for the Internet explosion of the '90s. But the truly amazing thing about the Internet's success is that everyone agreed to connect these computers using the same set of protocols. Computers of all different types, with different operating systems, from different manufacturers, came together in cyberspace under a unified set of protocols. That is the crowning achievement of the Internet.

Let's quickly look at some of the advantages of using Internet protocols instead of building automation systems (bas)-specific protocols:

• Internet protocols are well defined.
• Internet protocols are widely accepted, as in hundreds of millions of people.
• Internet protocols are free. No single company controls them and anyone can look up the standards and can choose from a long list of component manufacturers.
• Internet protocols are continually improving and benefit from research and development from thousands of companies across hundreds of industries. The amount of money in R&D for the Internet and Internet-related technologies dwarfs that in the building automation industry.
• Internet protocols allow bas to cross industry boundaries and interface with a wide variety of other systems.
• Internet protocols allow separate systems and groups of components to share the same set of wires. This reduces the overall cost of installing and maintaining several systems.

So why don't building automation equipment manufacturers build products that use Internet standards and protocols instead of bas-specific protocols? Actually, many bas do incorporate Internet protocols into different parts of the system. However, BACnet(r), LonWorks(r), and proprietary protocols still dominate the core infrastructure of the bas networks. Internet protocols are usually tagged onto the product line as an option, and only in places where it is convenient.

One reason that Internet protocols have not been adopted by bas equipment manufacturers as the core networking standard is cost. Internet protocols generally are more sophisticated and require more computing power than is typically available on smaller, inexpensive bas control products.

Historically, networking protocols were the domain of mainframes and business computers, while embedded electronics used serial communications. But in the past year or two, the price of 32-bit controllers, networking chips, and software has allowed true TCP/IP networking to become a realistic and cost-effective solution at the controller level. It is now possible to have 32-bit Internet-capable processors inside of every single bas controller in a building.

Another reason for the lack of Internet protocol support is that the well-established Internet protocols do not directly address all of the needs of a bas. They provide great interconnectivity, addressing, and graphical display. But they do not specifically dictate how to exchange bas data, like temperatures or alarms, between bas components. But new emerging standards address the general need for meaningful component-based interoperability. But before we cover these, let's take a look at the Internet standards that are firmly in place today.

Ethernet and other Link Layer Protocols

Computers and devices that communicate over the Internet actually do so using several different protocols at the same time. This is why we refer to them in plural as Internet protocols. You might ask someone if his network is Ethernet or TCP/IP. The answer could very well be both.

You can see that several different protocols are used to make the complete connection. Ethernet, DSL, and FDDI are all examples of link layer protocols. The connection is not possible unless all of them are present. The reason for this is that the Internet, as the name implies, actually interconnects several completely different networks to form one large internetwork. You can actually set up an intranet. But there is only one Internet. This is the one and only large interconnection of millions of networks and devices around the world.

For building automation networks, a given manufacturer may use a 1 megbits per second (Mbps) Ethernet variant at the link layer to connect building automation devices together. This Ethernet-like implementation uses inexpensive and easily installed twisted pair multidrop wiring - similar to RS-485 wiring found in most bas systems. All of the 1 Mbps subnetworks throughout the facility are connected to a 10 Mbps or 100 Mbps Ethernet networks using various routers. These can, in turn, be connected to the Internet. The 1 Mbps subnetworks allow true TCP/IP connectivity at each device but assist building owners in reducing the cost of installation and wiring.

TCP/IP

Local area networks (LANs) can also employ the TCP/IP protocol for short local connections. In this example, TCP/IP is still used even though connections don't leave the local network. Two neighboring devices can "speak" TCP/IP on a single LAN. Global connectivity is just a bonus. In true multilayered fashion, TCP/IP itself does not specify the format of the connection. This is left up to the application, as it should be.

Bas can use TCP/IP today as the underlying connection protocol for building automation.

HTTP Pros and Cons

So the http protocol defines a way that graphical data is transmitted over TCP/IP for display to people using a Web browser. It is a complete, well-defined, and widely accepted protocol. All bas can and should offer this type of universally accepted protocol in their systems. It would be remiss in this day and age not to offer some sort of Web connectivity to a bas.

In addition, webpage service should not be limited to just the main bas computer. Every bas component should have TCP/IP connectivity and offer, at minimum, one default webpage. This is true for the exact same reason that a bas uses direct digital controls (ddc). Although you want your components to communicate with other components in the building, you also want them to have the ability to operate independently.

If you are using a browser that is physically close to a controller, it just makes sense to browse directly into it instead of having to go back to the main computer. And what if the main computer is down? Do you lose all Web connectivity? And what if several systems like lights, hvac, and fire are all on the same network?

Wouldn't you prefer to have a technician browse directly into the local air handler for simple operations without going through the main hvac computer? What if you don't even want a main hvac computer? At this point, TCP/IP and Web browsing capability must be provided at the controller level for a truly interoperable bas system.

Unfortunately, the http protocol only handles half of the interoperability problem. It basically uses TCP/IP to carry graphical information from a bas component to a human. But what about the scenario where one bas component from a given manufacturer needs to communicate with another bas component from another manufacturer? Http does not handle this situation. TCP/IP will definitely be the protocol of choice to universally address these devices and provide solid connections. But another high-level protocol is needed to specify the actual format of the data exchange between two bas devices.

Emerging Internet Protocols

What the building automation industry and other industries really need is a protocol standard that not only defines how specific data is exchanged between devices, but also defines the specifics of the data itself. The problem of simple meaningful data exchange between products of different manufacturers plagues all industries. Protocols using specific data formats are usually quickly outgrown, or worse, bogged down with huge amounts of options. Several new protocols address this problem. These are xml (extensible markup language), Jini(r), and Universal Plug and Play(tm). Each of these new standards has its advantages and disadvantages. But for the purposes of building automation, we've chosen to concentrate on xml because of its simplicity and universal acceptance.

XML

• It must use the existing Internet protocols to take advantage of all of the existing Internet technology.
• It must be used to communicate high-level data between computers and other embedded devices - not between computers and humans.
• It must be simple for everyone to setup, view, edit, and develop products for.
• It must incorporate the description of generic data for flexible use.
• It must allow for dynamically accepting different and new data formats without committee approval or product updates.

XML Meets These Fundamental Requirements, and More

A Web server at the weather center provides xml data on current weather conditions and future weather predictions. It, like most servers in the coming years, provides both html webpages and xml data for clients. If someone simply wants to check the weather, she uses http to connect to the Web server and display one of many html files in her Web browser.

Another server resides at a mail order clothing manufacturer's main office. It, like most servers, provides both html and xml data. Fashion conscious individuals regularly check the website and display the fashion html files in their browser. But in addition to this, the fashion server regularly gets weather prediction information from the weather center's server. It does this using xml data transfers over TCP/IP. It uses this information to dynamically build a webpage entitled "Suggestions for Dressing Today." When the weather center predicts rain, the fashion server automatically shows one of the raincoats as part of the suggested ensemble in the webpage. Not only does this page showcase its products in real-life situations, but it is providing a service as well.

This simple example is shown mainly to get the point across. A more realistic example would show large numbers of application-specific business servers all connecting to each other and sharing huge amounts of data. The possibilities are virtually endless: All servers communicating with each other! This is the vision of xml.

How do these different computers and devices find out what data each of the others has? Is there a weather protocol for the weather industry that has data fields like "wind speed"? Is there a clothing protocol for the clothing industry that has data fields like "shirt color"? No. Each server uses a process known, in general terms, as discovery. Xml and its related protocols handle the discovery of new foreign data structures.

Xml handles different data types and structures by providing two types of documents - xml schema and xml data. Computers or devices that are unfamiliar with the types of data available from a new device on a network will get the schema document from them. The device parses and analyzes the schema for data and services that it may want to use. From there, it can use the schema to get the actual data - ignoring anything that it doesn't understand or want to use.

This allows upward compatibility with future revisions. Take the example where the initial release of a controller that monitors power consumption has the following data items in its schema:

• Current;
• Voltage;
• Real power; and
• Power factor.

Other devices could get that schema and search for known or recognized data. One device may want all of the data items while another device may only be interested in the real power. Later, a new firmware release is loaded onto the power-monitoring device. By request, the manufacturer has added a peak demand data item into the schema. It now contains these data items:

• Current;
• Voltage;
• Real power;
• Power factor; and
• Peak demand.

Because of the way that xml schema and data documents are parsed, this should never cause a problem. Parsers ignore those items that they do not understand and never assume an order or limit to data items.

One of the design goals of xml was that it be simple. Xml is very similar to html. That is part of its appeal. First, it doesn't require a special network port and can therefore pass through any firewall. Also, programmers familiar with html will have little trouble moving into xml programming. And because the files are just simple ASCII text, you can search new and unknown files for familiar words and data descriptions. An hvac controller might get all of the xml schema documents from neighboring bas components looking for anything that resembles "outside air temperature."

The current state of xml development is actually quite mature. Much of the development, like the xml document schema and formats, has been complete for some time. The main area of research and development is taking place in the area of development tools and discovery. Development tools will allow manufacturers to quickly and easily produce xml-based products.

In the area of discovery, researchers want to improve the discovery methodologies to the point where seamless interoperability between totally unrelated devices is a reality. Currently, devices can use xml over TCP/IP to exchange data. The developers from different companies don't even need to speak to each other. They simply get the schema from the other device and code their device to read and write that data. This is a nice first step. The only step left is for devices to plug into networks full of unknown devices and begin to communicate with them.

The Glue That Binds The World

Right now, some manufacturers of embedded electronics might ask the question "Why do I want to include a Web server on my new product?" With such massive acceptance and potential connectivity and interoperability at a their fingertips, this question is not even valid. The only valid question is "Why would I not want to include a Web server on my new product?" Three or four years ago, the only answer to that question might have been "Because it's too expensive." But now, with the advent of inexpensive 32-bit microprocessors, networking chips, and software, there is no viable reason not to offer Web capability. Even if http is not the primary protocol used to exchange data, not including a webpage service is inexcusable.

Finally, using TCP/IP connections, protocols like xml will dominate the future of interoperability among embedded devices - even in building automation. This is because xml and other Internet protocols benefit from research and development across industry boundaries. No single building automation protocol will be able to surpass them in terms of complexity, maturity, and acceptance. By using them today, you can begin enjoying a competitive environment in building automation - integrating all of your bas as one seamless LAN. ES