Bill's Blog on Automation

Using the BACnet® Discovery Tool – BDT

When applying BACnet routers in the field is there a quick way to determine if the router is successfully communicating to attached devices? We think there is with the BACnet Discovery Tool (BDT). Although limited to very simple tasks, it is easy to use — and it is FREE!

The BACnet Discovery Tool (bdt.exe) is a BACnet/IP application for Windows^® that is easy to install and use. It is an excellent means for verifying communication with MS/TP devices that are being accessed through BACnet/IP routers such as those available from Contemporary Controls: the BASRT-B DIN-rail mounted BACnet/IP-to-MS/TP router — or its portable counterpart, the BASRTP-B.

The tool is based on an open source BACnet protocol stack developed by Steve Karg. His project is described at:

http://bacnet.sourceforge.net

At just over 520 kB, bdt.exe is small — making it a snap to download. When you download the tool, you can save and run it from anywhere on your computer's hard drive.

We use BDT with our BACnet Interoperability Board. On this board we mount equipment from different BACnet vendors to prove our routers operate with different equipment configurations. In the photo at the end of this article you will notice mostly Alerton devices being tested, but we can change out equipment as needed. Although we have more elaborate BACnet tools, BDT is a vendor-neutral tool that can quickly discover BACnet devices. To give you an idea on how this works, we configured our board with three MS/TP segments each tied to a dedicated BAS Router. Each BAS Router has its BACnet/IP side tied to a common network through one of our Ethernet switches. Attached to the network is a workstation running BDT.

We launch bdt.exe by double-clicking its filename or icon. As soon as the application starts, it opens in its own window. It immediately activates its Who-Is service and transmits one Who-Is query. If we do not see any response within a few seconds, we can try pinging the IP address of the router to confirm that its IP channel is functional. NOTE: Because bdt.exe sends a BACnet/IP Who-Is (not a BACnet/Ethernet Who-Is) it will not discover any devices which only support BACnet/Ethernet.

Each I-Am response is reported on screen as soon as received. As shown in the screen below, each response also identifies the associated Device Instance number and Vendor identifier. The first three responses are from Contemporary Controls whose vendor number is 245. The remaining devices are identified as manufactured by Alerton whose vendor number is 18.

NOTE: For ease of illustration, the screen capture has been altered so that two lists that actually appear one-after-the-other , are here displayed side-by-side. Also, both lists (the responses on the left and the device information on the right) are abbreviated.

After all of the I-Am responses have been received, bdt.exe summarizes the information it has received as illustrated in the right portion of the sample screen. In this example, you see a list of many respondents on the left. The associated summary list on the right reports each Device Instance, the device’s maximum Application Protocol Data Unit (MaxAPDU) value and the number of the network ( Net) on which it resides. A Net value of 0 represents the network to which the BACnet Discovery Tool is attached — and so it must be an IP network. (This identification is reinforced by a MaxAPDU value of 1476 — typical of an Ethernet network.) Since the first three responses in the device summary on the right show that devices 202162, 202161 and 202160 have Net values of 0, the originators of the first three I-Am messages must be BACnet/IP devices — in this case, they are the three BAS routers.

The second column (MAC) of the summary report on the right, requires detailed explanation. The MAC value is a composite of two pieces of hexadecimal information obtained from the BACnet/IP device involved in each I-Am response. The first eight digits represent the IP address of the BACnet/IP equipment that has delivered the I-Am response. The last four digits report that device’s BACnet/IP UDP port number.

NOTE regarding the MAC value: there is a significant difference between the BACnet/IP protocol (used by bdt.exe) and the BACnet Ethernet protocol. The bdt.exe MAC value is not the Ethernet MAC address as you might expect. This is because BACnet/IP protocol uses the device IP address as the MAC value. Only BACnet Ethernet protocol uses the actual Ethernet MAC address as the MAC value.

The equipment delivering the I-Am response could itself be simply a BACnet/IP device (as is the case with the first three respondents) — or it could a router that is acting as an intermediary for devices on the far side of the router (which is the case with the remaining respondents in our example).

If the response Device Instance is that of an MS/TP device, then the associated MAC information pertains only to the router that delivered the response.

The first response shows device 202162. Its information tells us it is a BACnet/IP device (Net value 0) whose MAC value reported an IP address of 0A0000D9 and a BACnet standard UDP port number of BAC0.

Responses 4 and 5 are for devices 3015 and 3002, respectively. Because these two lines have identical MAC values, their I-Am responses must have passed through the same BACnet/IP router — a fact also indicated by the matching network numbers of 100. In this case the router’s IP address is seen to be C0A85C64 — and the router used UDP port BAC0. NOTE: If you wish to convert the foregoing hexadecimal values into their decimal equivalents, the UDP port is simply 47808. The displayed hexadecimal IP address value converts to a dotted decimal IP address by converting two digits at a time to decimal. In this example, segment C0A85C64 into its quad address hex values: C0-A8-5C-64 — then these four hex pairs convert to 192.168.92.100.

Note that response 6 (for device 3044) passed through a different router that is identified by a MAC value of C0A85C65BAC0, and operating on network number 101. And also see that the final response (for device 3043) passed through yet another router identified by a MAC value of C0A85C66BAC0 and residing on network 102.

Finally, the last line in the sample screen indicates that once you have finished examining its display you can end the application by pressing any key. When you terminate the application, its window closes automatically.

You can download this handy, free application by pointing your browser to:

http://www.ccontrols.com/exe/bdt.exe

BACnet MS/TP MAC Addresses — Any Significance to the Addresses?

There are 256 possible BACnet MS/TP addresses ranging from 0–255, however, you cannot assign a device to 255 since it is reserved as a broadcast address. No device is allowed to have a source address of 255. There is another restriction on addressing. Master devices, those who participate in the token-passing protocol, must be addressed from 0 to 127. Addresses from 128 to 254 are reserved for slaves who do not participate in the token passing — however, they can occupy lower addresses as well. Each MS/TP master must be assigned a unique address in the valid range, but is there any significance to the value of the address? Actually, there is.

If you study Johnson Controls’ (JCI) MS/TP Communications Bus Technical Bulletin, JCI states that MAC address 0 is reserved for bus controllers and cannot be changed. Addresses 1–3 are also reserved. Therefore, field controllers should begin being addressed from 4 on up with no gaps in the sequence. This allows the best possible performance since no time is wasted passing tokens to non-existent devices. Another parameter comes into play and that is Max. Master. This parameter does not mean the maximum number of devices but the highest address used by any master in the network. We know you can only address up to 127 masters — so this is the default value for almost all devices. However, this is not the most efficient setting since the device with the highest address will periodically poll-for-master (PFM) up to the Max Master limit. This is a waste of time if you only have 20 devices addressed from 0–19. Ideally, you would like all devices to have their Max Master set to the address of the highest master address on the network. However, seldom do you see this parameter changed.

There is significance to being the MAC 0 “guy”. By having the lowest possible address, you are the first in line to begin PFM in case there is a network disruption. If you have Max Info Frames set high, and you receive the token, you can quickly flush your queue before the other devices get the token and begin polling for nonexistent devices. So if you are a bus controller or a BACnet/IP to MS/TP router like the BASRT-B, assign yourself MAC 0 for the best performance.

How BACnet Tools Can Help You

Installing BACnet devices can be challenging for a number of reasons. You may be dealing with BACnet/IP, BACnet Ethernet, BACnet MS/TP, BACnet over ARCNET, or a mix of protocols. You might have to cope with repeaters, switches or routers.

Regardless of the complexity of your installation, a BACnet tool can greatly assist you. Although many tools are available over a wide price range, you may not need the fancy options of the expensive tools. You will at least want a tool that will discover BACnet devices (wherever they may be on their networks) and their properties.

A modestly priced choice (sample shown above) is the Windows®-based "BACnet Quick Test" from PolarSoft. It reports Device Instances, Vendor IDs, BACnet objects and associated properties. It confirms that devices are communicating on their networks and allows you to read and write object properties. It works with BACnet Ethernet, ARCNET, BACnet/IP and BACnet MS/TP.

Sometimes it is great help to just know that devices are accessible. A simple "BACnet Discovery Tool" is available for free from Contemporary Controls. Just point your browser to:

www.ccontrols.com/exe/bdt.exe

What Is MTBF and What Good Is It?

From time to time, a caller asks me about the MTBF rating of one of our devices. The abbreviation MTBF stands for

Mean-Time-Between-Failure

and indicates the reliability of the specified equipment. It is the typical time between failures for a specified device design — that is, the typical amount of time (in hours) any of a specified set of devices will function before failing.

However, different companies define failure in different ways, depending on the nature of the equipment and its function within a system. Also, test parameters and batch size are not standardized. Essentially, higher MTBF ratings for finished goods are obtained by building equipment with components that have high individual MTBF values — that is, better quality components.

MTBF grew out of the US military's attempts to formalize reliability assessment in the 1950s and 1960s which resulted in the publication of MIL-HDBK-217. Various flaws with this document led to a number of revisions and eventually, "... the U.S. Army has discovered that the problems with the traditional reliability prediction techniques are enormous and have canceled the use of MIL-HDBK-217 in Army specifications ..." Source: Equipment Reliability Institute's "ERI News", August, 2001 — vol. 4.

Despite criticisms of MTBF (especially within MIL-HDBK-217), it remains the dominant reliability assessment tool in the commercial electronics industry. The "Telcordia SR-332" handbook is used by many non-military electronic manufacturers for generating MTBF values. It evolved as follows: In the early 1980s Bellcore (Bell Communications Research) spun off from AT&T Bell Labs. Starting in 1985, Bellcore used MIL-HDBK-217, then improved and adapted it for highly-integrated commercial electronic products. In 1997 Bellcore was sold and its name was later changed to Telcordia Technologies.

At Contemporary Controls, equipment reliability is specified by MTBF values produced through the use of the Telcordia standard: Method I — Case I — Quality Level I.

Although the derivation of an MTBF value can be mathematically quite involved, the process can be generally stated as:

(Total Operating Time) / (Sample Size)

Suppose, as a very simple example, we test five electronic components until each one fails with the following results:

After totaling the above hour counts (3000), we would divide by the sample size (5) to get an MTBF for the component:

MTBF = 3000/5 = 600 hours

The above MTBF example means that we would expect the theoretically typical component to fail after 600 hours of operation. Stated differently, if we assume that all five components were typical, we would expect all of them to fail at 600 hours, with an average failure rate of one every 120 hours (600/5). Note that every component greatly outlived the 120-hour statistical failure mark for an individual. The 1-failure-per-120-hours is merely a statistical artifact that only achieves significance once the group size becomes much larger than in this example.

Actual MTBF values are much, much higher than the preceding example. Indeed, some exceed 1,000,000 hours! Industrial Ethernet switches usually have MTBF ratings of about 500,000 hours. That is, of all such units tested, the typical one would fail at 500,000 hours — also, all of them would fail at 500,000 hours, if the entire group is composed of typical devices. Of course, no one really tests devices for such a long time — 500,000 hours is about 57 years! Actual MTBF ratings are either: projections based on a record of actual product failures, or predictions made by aggregating known MTBF values from component or sub-assembly suppliers.

Some people like to look at the MTBF like this: If a group of 1000 Industrial Ethernet switches has an MTBF rating of 500,000 hours, we could expect all 1000 units to fail within some 57 years. But if all 1000 were placed in service over the same time period with an evenly-spread failure rate, we could statistically expect one to fail about every 21 days, based on the following calculations:

MTBF / population size = mean unit time to failure

(500,000 hours) / (1000 switches) = 500 hours mean lifetime per unit

(500 hours) / (24 hours in day) = 20.83 days

However, the foregoing result is very misleading. Firstly, assuming a symmetrically balanced failure record, the odds are 999 to 1 that a particular switch will fail after 21 days! Also, various factors (some unknown) skew the typical failure model toward the MTBF value. That is, in reality the 1000 switches tend to fail (or wear out) at roughly the same time (near the MTBF value). But the averaging process yields a statistical result that predicts one failure every 21 days — even though the true lifetime of the vast majority of switches is much nearer the MTBF.

From this you can see that an MTBF rating is of no value when applied to an individual item (nobody replaces a device every 21 days). Instead, the MTBF is a figure-of-merit that predicts the reliability of an entire group of products. What we should care about is: The greater the MTBF of the group, the more reliable a typical individual product within the group!

Niagara Summit 2006 in Florida

The 2006 Tridium Niagara Summit took place from April 30–May 2 at the Saddlebrook Resort in Wesley Chapel, Florida (just north of Tampa). Two Contemporary Controls staff attended: R & D Manager Bennet Levine (in the lower photo) and Sales Manager Joe Stasiek. There were 415 attendees at the summit (compared with 320 in 2004), most of whom were system integrators and developers.

Monday afternoon, Mr. Levine addressed the Complimentary Technologies Session, speaking on networking equipment designed for the rigors of automation applications.

Keynote speeches included Strategies for Smart Services by Glen Allmendinger, Founder and President of Harbor Research; and "Co-opertition" — A Unique Blend of Cooperation and Competition by Ramon Casadesus-Masanell, Assistant Professor, Harvard Business School.

Contemporary Controls (one of over 30 exhibitors) unveiled its latest Industrial Ethernet product — the BAS Remote I/O which offers six universal I/O points and two relay outputs. There was also much interest in the company's recently announced EtherNet/IP switches that feature IGMP Snooping.