AutomatedBuildings.com Article -

This is a two-part series. Part I was entitled Object Modeling a Physical BACnet Device while Part 2 is entitled Achieving BACnet Compliance. Together they explain how BACnet devices are constructed—with emphasis on the latest BACnet/IP standard.

Modern control networks such as EtherNet/IP, Modbus/TCP and BACnet^®/IP use Ethernet for communications due to its high speed, lowering cost and in some instances, the necessity to operate over structured wiring. Although the study of Ethernet does not require an understanding of application protocols, knowledge of application protocols has become increasingly important as modern networks are deployed. The latest protocols are all based upon Object Modeling which can be quite confusing to someone who has not been exposed to this abstract concept. Object Modeling a Physical BACnet Device introduced object modeling, object properties, and services as they pertain to a physical BACnet/IP device. Achieving BACnet Compliance continues the discussion by addressing the requirements for achieving BACnet compliance.

A primary goal of the BACnet standard is interoperability among vendors of BACnet equipment. Users also need to make sense of the vast range of BACnet products from simple sensors, workstations and building controllers. Not all devices need to provide the same services so how do we classify devices? The BIBB concept was introduced later in the standards development process as a way of classifying the numerous available services into more manageable processes as would be needed in a building automation application. The resulting 67 BIBBs can be found in Annex K and are classified into five groups:

At first glance it would appear that things are getting more complicated than less. How could we get 67 BIBBs from only 38 possible services? One answer is to understand who the requesting device is and who the executing device is. In the jargon of BIBBs, an “A” device is one who uses the data (client) while the “B” device is the one who provides the data (server). Study Tables 1 and 2 which show two Data Sharing BIBBs.

Notice that both BIBBs use the same ReadProperty but in one operation Client A is initiating the request while in the second operation Server B is executing the operation. Devices are not required to both initiate and execute services, but some do.

BIBBs are indeed “building blocks” to interoperability. They are used to classify the capability of the device and for creating standard device profiles. The number of required BIBBs increases with the complexity of the device. To fully understand the workings of each BIBB you need to consult Annex K. Table 3 provides a listing of required BIBBs for each device profile.

¹Not required if the device is a BACnet MS/TP Slave.
Table 3 — BIBBs required for various standard BACnet device profiles.

To ease the process in determining BACnet compliance, the standard classifies devices into six categories:

In order for a device to be classified as a standard BACnet device, it must comply with a set of defined BIBBs. The listing of required BIBBs for each device classification is called a Device Profile. The simplest device is the Smart Sensor and, as shown in Table 3, it is only required to support the DS-RP-B BIBB. It only needs to execute the request for data since it is a sensor. The BAS Remote is more complex, being classified as a B-ASC requiring the BIBBs listed in Table 4.

The Read Property and Write Property BIBBs are straightforward since they involved data sharing, but in both cases the device only responds to a request to read or write. The Device & Network Management BIBBs are also limited in that the device only responds to requests. It basically functions as a server and not a client. It should be noted that the number of BIBBs listed in Table 3 only represent minimum requirements. A vendor can choose to support more, so the device profile for his device would include more BIBBs. In order to fully understand what a device is capable of doing, you need to study the device’s Protocol Implementation Conformance Statement (PICS).

To help the customer in determining the compliance level of a device, a vendor must supply a PICS statement of compliance. The basic format of the statement is provided in the standard and this was the format used for the BAS Remote. For the BAS Remote, its PICS indicates that it complies with the B-ASC standard device profile with no additional BIBBs supported. The actual BIBBs are listed. The data link layer supported is also listed as BACnet/IP Annex J. A vendor is not required to use the identical format, but the relevant information must be provided. Although the vendor has stated his product’s compliance with a PICS statement, how does a user know that the product actually complies? The ideal approach is for the vendor to submit the product to the BTL Laboratories for compliance testing. These labs were formed by BACnet International, a trade association devoted to advancing the BACnet standard around the world.

According to its website at http://www.bacnetassociation.org, BACnet International (BI) is an organization that encourages the successful use of BACnet in building automation and control systems through interoperability testing, educational programs, and promotional activities. Membership is open to both companies and individuals interested in the BACnet standard. There are two key activities BI sponsors in its mission to encourage successful installations. BI organizes annual Plugfests where vendors can bring their products to an event in order to verify that their devices interoperate. The other initiative is the creation of the BACnet Testing Laboratories (BTL) where products can bear the BTL mark upon successful completion of conformance testing.

Plugfests are a convenient way for vendors to test-drive their products before actually incurring the expense and effort of a formal conformance test. Usually run once a year, the Plugfest is open to any BACnet device manufacturer, but BI members can attend for free. The trade press is not invited, and results are not tabulated. It is an opportunity for vendors to freely discuss the intricacies of the BACnet protocol and to verify that their products can communicate among compliant equipment as required by the standard. It is expected that there could be some glitches occurring during testing and experts are at hand to clarify the requirements of the standard. This is all being done to improve the interoperability between competing products.

[an error occurred while processing this directive] One BI member offers to be the host for the annual event and assumes responsibility for securing space for the event. To make it quick and easy to setup, communication among vendors should be BACnet/Ethernet although other data links can be tested. This requires that routers be used to support the various data links. To avoid conflicting BACnet Device IDs, each vendor is assigned a range of 1000 IDs based upon their ASHRAE-assigned vendor ID. Each vendor needs to provide a printed document listing a product’s BACnet objects that the vendor intends to test. For each object, the object ID, object name and any optional properties must be listed. Each vendor has to provide an Ethernet 10BASE-T connection along with an Ethernet repeating hub and some sort of protocol analyzer for observing the data being sent and received. Repeating hubs facilitate the use of protocol analyzers since all traffic can be observed on all hub ports. Software changes could be made during breaks if the vendor brings along a full development system. This is the one chance during the year to do some real interoperability testing, so it is best to come prepared.

The Plugfest occupies two to three days of organized testing. On the first day are speed sessions requiring ten minutes of setup and fifty minutes of testing. Vendors are assigned to teams with one team meeting with another team for the full session. One of the teams must have equipment that can read another vendor’s device. For example, not much would occur if the two teams only had sensor devices. Little testing would occur. For any one session there could be 24 tables each occupied by two teams. Upon completion of the session, another session immediately starts with different teams occupying the same tables. These sessions go on all day.

On the second day there are mini-roundtables consisting of four or more participants communicating to one host participant. There are only four of these sessions lasting for two hours each. Also on this day are panel discussions from the experts on how to design for interoperability. With easy access to the experts, this is the time to ask questions and to take advantage of this excellent training opportunity.

The third day creates functional round tables for participants particularly interested in functions such as alarming, trending, life safety, scheduling, backup and restoring. With the completion of the third day, the Plugfest ends. The vendor can now return with added confidence of a successful submission to the BTL Labs.

The BACnet Testing Laboratories was created by BI to support compliance testing and interoperability testing. BTL published Implementation Guidelines which provides excellent information on achieving compliance. This document can be downloaded from the BI website. Another source of information on compliance can be gained by joining the BACnet mail list by visiting: www.bacnet.org/contact/bacnet-L.htm.

Compliance testing and listing is overseen by the BACnet Working Group. A vendor can receive a set of testing procedures from the labs to do some pre-testing before actual submission to the labs. Although you do not need to be a BI member to submit a product for testing, BI members receive preference and a discount on testing. Once the product has been successfully tested by the labs, it can be listed and bear the BTL mark as shown in Figure 1 below. This mark gives the user assurance that the product complies with the BACnet device profile to which it was tested. An added benefit to the vendor is that some bid specifications require only BTL listed products.

Although object modeling appears complex, it is the modern method of making devices "network visible." Through the use of objects, properties and services, the BACnet standard defines BACnet compliance through defined BIBBs that lead to standard device profiles. Using a PICs statement, a user can determine the capability of a device and its compliance level. Users can be assured that a product is BACnet compliant if it completed conformance testing. Vendors also use compliance before submitting the product to the BACnet Testing Laboratories.

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

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

Events	Want Ads
Our Sponsors	Resources