Three Things to Make Sure You Get an Open Smart Building Controls System

Ken and I are in Nashville to cover RealComm|IBcon for our ControlTrends Community. Preparing for the Ultimate Smart Buildings Conference got me thinking….

What is the one thing that building owners need to know to make sure they maximize their Smart Building Controls investment ?

Many Control Vendors tell you that their building automation control system is open because they use Lon or BACnet or some other open protocol . These protocols allow their controls to talk to other devices on the network. Based on this they claim openness.

And yes, an open protocol is the first part of a control system being open. But, it does not ensure that you have an open system, because it does not ensure you have Choice. Open protocol is not equal to Open System.

1) Open Sourcing. How many people and companies can install and service your Smart Building Control System ? If it is one, you have a problem. If you do not now, then later. You might be dealing with the best contractor on the planet, what happens if they go out of business? Ask the question. How many qualified companies can service my system? Can my people get the same training and pass a test to become certified to work on my system?

2) Open Knowledge: Can my people get the same training and factory certifications as my contractor ? Can I get the same programming tools. This is important! Many systems use a separate tool to program the controllers in the system. If you can’t buy the tool, you can’t set up and program replacement controls. Make sure you have the option to buy the programming tool.

If you are a facilities manager or building owner, who contract out a multitude of services, you are well aware of the vulnerabilities of having only one service provider and what the consequences are when the relationship is not working out .

Not having the freedom of choice (and benefits of competition) to intelligently and swiftly change service providers is an awful predicament to be in.

Following these cardinal rules: Choose Open. Have choices. And, stay in control of your facility’s destiny.

Learn More

This is from one of the founders of BACnet and ControlTrends Hall of Fame Inductee Michael Newman.

“In this article, H. Michael Newman, Manager of Cornell University’s Utilities Department Computer Section and Chairman of ASHRAE’s BACnet committee since its inception in 1987, answers some of the most frequently asked questions about the BACnet standard, ANSI/ASHRAE 135-1995.

BACnet is “a data communication protocol for building automation and control networks.” A data communication protocol is a set of rules governing the exchange of data over a computer network. The rules take the form of a written specification (in BACnet’s case they are also on compact disk) that spells out what is required to conform to the protocol.

What kinds of things are covered by BACnet’s “rules”?

Everything from what kind of cable to use to how to form a particular request or command in a standard way. What makes BACnet special is that the rules relate specifically to the needs of building automation and control equipment, i.e., they cover things like how to ask for the value of a temperature, define a fan operating schedule, or send a pump status alarm.

But every manufacturer’s system in different! How can BACnet possibly do all these things in a standard way?

The trick is that BACnet provides a standard way of representing the functions of any device, as long as it has these functions. Examples are analog and binary inputs and outputs, schedules, control loops, and alarms. This standardized model of a device represents these common functions as collections of related information called “objects,” each of which has a set of “properties” that further describe it. Each analog input, for instance, is represented by a BACnet “analog input object” which has a set of standard properties like present value, sensor type, location, alarm limits, and so on. Some of these properties are required while others are optional. One of the object’s most important properties is its identifier, a sort of numerical name that allows BACnet to unambiguously access it. Once devices have common “appearances” on the network in terms of their objects and properties, it’s easy to envision messages that can manipulate this information in a standard way.

OK, so what kinds of messages does BACnet define?

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 that then 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.

Is BACnet limited only to HVAC equipment? Can it be used with fire/life safety, lighting control, and other building automation systems?

Absolutely. In fact, if you think about it, BACnet already contains most of the capabilities required for non-HVAC communications. These include the ability to read and write binary, analog, and text data; schedule control actions; send event and alarm notifications; and so on. Nonetheless, the committee realized that these capabilities might not cover all situations and developed the standard with an eye toward accommodating future, unknown building automation and control applications. As a result, one of the real strengths of the BACnet model that emerged from this consideration is that it can be easily extended. If a vendor comes up with some new functionality for which communication is required, the vendor can add new properties to existing object types or create new object types that are accessed in exactly the same way as the eighteen defined in the standard. This is not only expected, it is encouraged. Moreover, a vendor could even dream up new services that go beyond the standard ones. Of course, proprietary features may not be interoperable without vendor cooperation.

I keep hearing about “interoperability” but I like the vendor I deal with now. Does BACnet require multivendor installations?

Definitely not. BACnet is just a protocol. It makes possible the interconnection of different vendors’ equipment that uses BACnet, but in no way requires it. Since many vendors will probably choose, sooner or later, to use BACnet as their “native” protocol, you could easily end up with a single-vendor BACnet system. Also, I agree with you. I would much prefer to deal with a single, or at most a couple of vendors. The issue is making sure their pencils stay sharp at bid time!

What about connecting BACnet systems together? What networking options are there for BACnet?

Good point! Up until now I have just been talking about the BACnet object-oriented model and the various services or message types. You still need to pick an appropriate network technology to connect everything together. The BACnet committee spent a lot of time on this part of the standard. We ended up with 5 different options, each of which fills a particular niche in terms of the price/performance tradeoff. The first is Ethernet, the fastest at 10 Mbps with 100 Mbps also recently available. (“Mbps” stands for “millions of bits per second.”) Ethernet is also likely to be the most expensive in terms of cost per device. Next comes ARCNET at 2.5 Mbps. Both Ethernet and ARCNET can use a variety of physical media – coaxial cable, twisted pairs, even fiber optic cable. For devices with lower requirements in terms of speed, BACnet defines the MS/TP (master-slave/token-passing) network designed to run at speeds of 1 Mbps or less over twisted pair wiring. Echelon’s LonTalk network can also be used on various media. All of these networks are examples of “local area networks” or LANs. BACnet also defines a dial-up or “point-to-point” protocol called PTP for use over phone lines or hardwired EIA-232 connections. A key point is that BACnet messages can, in principle, be transported by any network technology, if and when it becomes cost-effective to do so.

You mentioned that BACnet can use LonTalk. Does that mean that any equipment that uses LonTalk can automatically talk to BACnet systems?

Unfortunately not. LonTalk is Echelon’s specification for a recently developed LAN technology that many people thought would be a useful addition to the BACnet standard. BACnet uses LonTalk to convey BACnet messages in an identical manner to the way BACnet messages are transported by Ethernet, ARCNET, and MS/TP. Confusion stems from the fact that Echelon has its own generic control language that is also transported by LonTalk. In order for LonTalk devices to be interoperable, even using Echelon’s language, there has to be agreement between implementers as to what the generic messages mean in a particular context. To obtain such agreements, Echelon has set up the LonMark Program which has working groups made up of people from each industry that are trying to reach implementers’ agreements on how to use Echelon’s proprietary control language in a common way for their applications. The point is that the BACnet language and the Echelon language are fundamentally different and devices using one of the languages can never interoperate directly with devices using the other, even though they might possibly share a common LonTalk LAN.

I like the idea of BACnet but what about all my existing DDC systems? Can BACnet help tie them together too?

Maybe, maybe not. In order for a BACnet device, say an operator workstation, to talk to non-BACnet devices like your existing DDC system from XYZ Controls, you need an intervening gateway. A “gateway” is like a United Nations translator that can speak two languages. On one side it speaks BACnet, on the other side the XYZ protocol of your legacy system. Naturally the most likely source for such a gateway would be the XYZ company and they may, or may not, choose to develop one.

What if some of my DDC systems are on Ethernet and some are on, say, MS/TP. Is there any way to connect them together?

Yes. Besides allowing the use of different LANs, the BACnet standard also specifies how to build routers. “Routers” are simply devices that connect multiple networks together. The networks may be of the same or different types.

Now I’m confused. What’s the difference between a router and a gateway?

I don’t blame you. A lot of people use the terms almost interchangeably. In BACnet a router is a device that passes a message from one network to another without changing the form or content of the message. If the networks are of different types, the addresses, error checking, in short, the “packaging,” of the message may get changed, much as you would repackage an ordinary U. S. Postal Service letter if you were going to send it further using FedEx or UPS. A gateway, on the other hand, opens the letter, translates it into a second language if possible, puts it back into some type of envelope or another, then sends it on. Obviously, it can take more time and energy to do a translation than to simply forward a message so gateways are more complicated machines than routers.

Do BACnet routers really exist?

Sure. In fact, at the BACnet demonstration booth in Atlanta in February 1995 (sponsored by the National Institute of Standards and Technology’s (NIST) BACnet Interoperability Testing Consortium), we had controllers running on all the BACnet network types, except PTP, and all interoperating. To interconnect them, we had an Ethernet-ARCNET router, an Ethernet-MS/TP router, and an Ethernet-LonTalk router.

At the Air-Conditioning, Heating, Refrigerating Exposition in Atlanta in January of 1996, prototype BACnet devices communicated over all BACnet LANs except PTP. Each workstation was programmed to display identical graphics and was able to carry out identical control actions, even though three different operating systems and four different LANs were involved.

When BACnet was under public review, several commenters suggested that BACnet devices should actually be built and tested before releasing the standard. The committee agreed but needed to find a way to do the testing such that potential implementers could feel comfortable with the idea of bringing their prototypes together with those of their competitors for a non-competitive, non-judgmental evaluation. Also, we wanted to find a “neutral venue” for the testing, i.e., not one the vendors’ manufacturing sites. Happily, NIST offered the use of its lab in Maryland. Moreover, NIST has a mechanism, known as a “Cooperative Research and Development Agreement,” which allowed us to set up the testing and still protect everyone’s proprietary interests. There are currently 20 consortium members, 17 of whom are manufacturers.

What about BACnet certification? Will NIST be certifying BACnet conformance?

BACnet certification is, for the moment, still an unresolved issue although everyone agrees that it is needed. NIST will definitely not be doing any sort of certification nor will ASHRAE as a society. Two things are needed: a standard method of testing conformance and figuring out who will be responsible for issuing the BACnet “stamp of approval.” Developing such a test will be one of the top priorities of the ASHRAE Standing Standard Project Committee (SSPC 135) that has been formed to interpret and extend BACnet.

Speaking of conformance, what can you tell me about writing specifications for BACnet systems?

The first thing is that your specification must clearly state what kinds of network functions you need. For example, if you want your field panels to be able to start and stop equipment based on date and time, that does not necessarily require any network functionality. But if you want to be able to manipulate the controller’s schedule from a remote workstation, both the workstation and the field panel have to support the appropriate BACnet capabilities in terms of objects and services. Just carefully list the things you want to be able to do across the network – time-based things, alarm and event requirements, points that you want to share between devices – and state that they must be accomplished using BACnet.

PICS stands for “protocol implementation conformance statement.” It is basically a BACnet spec sheet containing a list of a device’s BACnet capabilities. Every BACnet device is required to have one. It contains a general product description; details of a product’s BACnet capabilities; which LAN options are available; and a few other items relating to character sets and special functionality. A PICS is the place to start to see what a device’s capabilities are. Conversely, a specifier could draft a PICS as a way of conveying what BACnet capabilities are desired for a particular job.

What is happening next within ASHRAE?

The SSPC will be working on a number of refinements or extensions to the standard. As I mentioned above, top priority will be to finalize a conformance testing addendum. We will also be looking at ways to enhance the use of BACnet with the internet protocols. This refinement, BACnet/IP, is going out for its second public review in November, 1998. We are also working on making it much easier to specify BACnet. Another working group is looking at fine-tuning the operation of the MS/TP LAN. Finally, a working group is looking at specifying the definitions of some new “macro objects” whose properties would be the parameters required for the monitoring and control of some large-scale device like a heat pump, chiller, or packaged rooftop air conditioner.

What else is going on?

Besides the SSPC activities, there are some BACnet demonstration projects underway. One that has been in the news quite a bit is the General Services Administration’s rehab of the Phillip Burton Federal Building in San Francisco. The neat thing about this project is its scale and complexity. It involves more than a thousand controllers, four (possibly five) different vendors, several applications including lighting control, and an interface to the local electric utility. There is also some activity on the international standards front. BACnet has been selected by the European Community’s standards committee CEN TC247 as a European “pre-standard” meaning that it will undergo an evaluation process over the next couple of years to see whether it should become a full-fledged EC standard. The International Organization for Standardization’s committee TC205 is also considering whether BACnet should be designated as an ISO standard. All of this is quite remarkable, considering that BACnet was only published in January of 1996.

OK, but are there any BACnet products actually installed and in use today?

Definitely. Of course it is hard to get a precise tally, but if NIST consortium members are to be believed, there are more than four thousand BACnet sites up and running at this moment. Of these, roughly one-third are multivendor installations. Most of the sites are in the United States but members also claim to have installations in Canada, Mexico, Brazil, Germany, Switzerland, UK, Hong Kong, Singapore, Australia, and Taiwan. It wouldn’t surprise me if there were more installations that I haven’t heard about.

When will more products be available?

This, of course, is a key question. There is a bit of chicken and egg here: the vendors will probably accelerate their product development if they see a growing user demand and users will probably increase their demand if they see more BACnet products in the marketplace. If you are a user, the best thing to do would be to express your interest in BACnet products directly to your friendly local vendor.

How can I learn more about BACnet?

Continue to read HPAC, the ASHRAE Journal, and other trade publications; get a copy of the standard, either in hardcopy form or CD, or both; attend ASHRAE seminars or short courses, or those sponsored by BACnet vendors or contractors. Don’t overlook vendor literature. A number of them now have tutorial information on BACnet in general and their BACnet products in particular. There is also a book called Direct Digital Control of Building Systems, immodestly enough by me, that has a lot of information on both data communication fundamentals and their application to BACnet.”