Here is a recent installation issue from the bacnet list.

We have a BACnet system serving multiple buildings. The BACnet hardware is supplied by several different manufacturers. My questions relate to the system integration of the different manufacturers’ equipment with the single-sourced headend software.

In an attempt to get competitive pricing for each project, we are trying to use a two part specification: one to specify a stand-alone BACnet-based system and the second to specify the integration requirements to our BASnet server.

The first part works admirably. Several manufacturers submit there bids and we make our selection.

The second part, system integration, is failing miserably. For legal purposes, we specified that any system integrator must have there own licensed copy of the system software to use to develop their handiwork. Our headend software supplier, obviously, meets this requirement. However, they are “reluctant” to license copies of their software to system integrators (the competition). Essentially, this makes this second part a sole-source contract, which is not the purpose of the open-sourced BACnet. With this scenario, BACnet is merely transferring the high-cost of proprietary hardware to the high-cost of proprietary software integration.(bold mine)

What are we missing here? Is there a better approach? How have others gotten around this problem?

I am hoping that this will create an interesting discussion!!

No doubt an interesting issue. Let's examine some of the responses.

NAVFAC (Navy-Marines) published a BACnet specification a year ago: http://www.wbdg.org/ccb/DOD/UFGS/UFG...23.13%2020.pdf

…Which the Army Corps identifies as not an open specification in the previous link provided from the workshop.

Understood, Xxxx.
The ACoE has performed an analysis of their concerns with BACnet, and has written a summary of these findings (I am on the road and do not have the document at my fingertips).

Both BACnet and LonWorks are open, standard protocols and each has its own advocates and detractors.
Each facility owner / manager should be encouraged to analyze their needs and determine what is most appropriate for their facility EMS.

Hi Xxxxxxx (Purple),

When it comes to the configuration of a BACnet device, the specification is open and leaves it up to the vendor. Configuration is often done via some proprietary means using the tools provided by the vendor. The Backup/Restore functions you mentioned are tasks that need to be performed after the devices have been configured, I would not call that configuration. The only properites that are guaranteed to be configurable in BACnet are listed in the specification with a "W" next to the property name, if look at the spec you will see that these properties are few are far between.

As an example, lets tak the recipientList property of the Notification class object. Lets say a customer of mine wants to use my BACnet Operator Workstation to monitor his site installed by another Vendor. In order to receive alarms he needs to add a recipient to each of the Notification Class objects. I can automate this, so that at the click of a button each device will be updated with the new recipient. However, this property is not required to be writable, so my customer may have to go back to the Vendor who installed the system so that they can use their proprietary tools to reconfigure these objects. This is just one example of a simple configuration task that may not be possible in BACnet, it just depends on the Vendor.

Configuration is definately not something that a common BACnet tool may be able to do. It may or may not work depending on the devices installed. There are some Vendors who are happy to leave it this way because they make money from reconfiguring their systems after they have been installed.

My understanding is that when the BACnet specification was written, one of the guidelines was, and I quote "BACnet is not supposed to be used for configuration"

You are right for the instance you have identified and, unfortunately there may be many more such instances. There is also a grey line between operational issues and issues requiring supplier technical services.

In the bigger picture and issues of interoperability manufactures should be seeking and using mechanisms to relieve the owners dependence on the original supplier for anything. This seems to be the point the US Military and other large owners get hung-up on. This is causing some consultants to refrain from specifying BACnet. My experience speaking as a former representative for the Canadian Government was exactly that point. It was realized that the change would not happen instantly but one of the original BACnet motivational issues was to move the industry closer to this ideal situation. Much has been accomplished and much has been given by individuals dedicated to this end. The entire industry owe many devoted individuals recognition for a major achievement and work well done. The work is not complete yet and there are still many dedicated individuals carrying on with the task, and they too are deserving of support and recognition.

For any developers holding out for any proprietary reasons, shame on you. Owners are looking for jobs well done, working as specified and owner and contractor benefiting from the relationship established because of that good work. We all should remember that it is he who has the money has the control. If someone tries to short circuit the process they will be dealt with eventually.

Remember where his discussion started, an owner wants a system that is Open and vendor independent. At this point in time can anyone give a truly and independent answer as to how to proceed.(?) There appears to be two almost answers. In each case there are a few wrinkles, lets get them smoothed out.

The owner/manager of this building expected that each bacnet system would be open and that when he tied multiple systems together that this also would be open. However, what he got was disparate subsystems, even though all "bacnet".

Comments to note:

• When it comes to the configuration of a BACnet device, the specification is open and leaves it up to the vendor. Configuration is often done via some proprietary means using the tools provided by the vendor.
• Configuration is definately not something that a common BACnet tool may be able to do. It may or may not work depending on the devices installed. There are some Vendors who are happy to leave it this way because they make money from reconfiguring their systems after they have been installed.
• when the BACnet specification was written, one of the guidelines was, and I quote "BACnet is not supposed to be used for configuration"
• Each facility owner / manager should be encouraged to analyze their needs and determine what is most appropriate for their facility EMS.

Basically, the owner/manager did not review the ASHRAE bacnet specification. The owner/manager did not make sure his vendors provided the configuration tools for their subsystems. Is it really reasonable to have to go and learn all the intricacies of the ASHRAE bacnet specification? I would contend not, however many hide behind this to provide closed up systems. The owner/manager does have to realize that much of the "open" part of bacnet is simply an ideal and not a practical implementation.

If you are an owner/manager installing bacnet you need to make sure you have all software included. I'd recommend including any updates in software and firmware for X years. Further, specifying that bacnet vendors shall cooperate by providing an openly accessible system with configuration tools to a master integrator represented by the owner. As was mentioned, the building owner/managers have the money and you had better put in language that covers your investment rather than trust that just because an installer puts in bacnet it's open and you own the system.

We are left with: At this point in time can anyone give a truly and independent answer as to how to proceed.(?)

I'll update should anything happen with this. The other side to this string of posts is discussing where the Army Corps specified ISO14908 CEA-709 and CEA-852 LON networks and how they are successfully avoiding this issue of not getting a complete open system. https://eko.usace.army.mil/fa/bAS/ (Lonworks workshop)

Add a Comment