The ReadProperty service is included in the Object Access Services group as well as the WriteProperty service necessary to set outputs. These are both confirmed services. With these two simple operations, we can read and write I/O points.

Other interesting services are the Who-Is and I-Am which are unconfirmed services used to “discover” devices. With the Who-Is request, an initiating device is trying to determine the device object identifier; the actual network address of a device, or both. A range of device object identifiers can be sent to restrict the search. In the most basic request, the Who-Is is sent as a broadcast message with no device object identifier restrictions. Since it is a broadcast message, all devices on the network will hear the request, but only those devices that can execute an I-Am service will respond. Each device capable of responding will send out their device object identifier along with some limited information on the device itself including the Vendor Identifier. With BACnet/IP, the response is sent as a broadcast UDP message so the source address can be learned from the response. The initiating device or any other listening device on the network can then construct a table of device object identifiers versus IP addresses so that future communication would not require this discovery process. Although, the I-Am response logically follows the Who-Is request, an I-Am can be initiated at any time. It is usually sent when a device joins the network and announces to devices on the network that it is present.

A similar set of services exist with the Who-Has and I-Have. In this case, the initiator is trying to determine the device object identifier, network address or both, which contains a particular object identifier or object name. For example, we are trying to learn where we can access outside temperature by entering the Object_Name “Outside temperature.” Since we do not know the object identifier, we will simply send out the object name in the Who-Has request. The response to the Who-Has is an I-Have which returns the device object identifier, object identifier, and object name. The network address can be learned as well. In our example, the BAS Remote has the Object_Name “Outside temperature” so it would respond with a I-Have message containing the device object identifier of 2749; the object identifier Analog Input, Instance 2; and the object name “Outside temperature.” Although an I-Have is the proper response to a Who-Has, an I-Have can be initiated at any time without a Who-Has.

With 38 possible services, discussing each service would make for a lengthy discussion. However, the concepts are the same as with the simple ReadProperty and WriteProperty services. As we will learn later, your simpler devices are only required to implement a fraction of the available services.

CONCLUSION

Although object modeling appears complex and awkward, it is the modern method of making devices “network visible.” Objects are used to describe physical devices and the types of objects are defined in the BACnet standard. Objects have properties and the property list varies with the object type. In order to use objects to our advantage, devices must be able to provide services. The types of services are also defined in the BACnet standard. Objects, object properties, and services begin to define BACnet-compliant devices.

REFERENCES

ANSI/ASHRAE Standard 135-2004 BACnet — A Data Communication Protocol for Building Automation and Control Networks, American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc.

Direct Digital Control of Building Systems Theory and Practice, H. Michael Newman, John Wiley and Sons, Inc., 1994.

http://www.polarsoft.biz/langbac.html, The Language of BACnet — Objects, Properties and Services, Bill Swan, Alerton Technologies, Inc.

http://www.basautomation.com/pdf/TD0403000D.pdf, Building Automation System Remote, Contemporary Controls.