Alarming Discussions are, well, alarming
January 22, 2010 – 10:07 am
Today is day 2 of the BACnet meetings in Orlando. The first meeting today is the OS-WG, which as of this writing is over its allotted time. This particular working group has been tasked with tackling the very large task of the alarm and event services reboot. These discussions have monopolized the OS-WG face time of late, which unfortunately has caused other proposals to languish. I’m not complaining, mind you. I’m just pointing out that this is the cost associated with this type of work – especially in a committee with limited time.
As I understand it, there are two camps when it comes to alarm and event generation in BACnet. That more than one camp exists shows that the standard does not provide an adequate overview for the functionality. If the committee experts are split, imagine how end users feel.
Camp 1 is of the thought that event generation requires a certain “object tax” in that it requires Notification Class and Event Enrollment objects in order to perform event generation at all. As David points out, not only do alarm generating objects have to support NC objects, but those NC objects need to have writable recipients, and more than one based on current BTL requirements and tests. This is a heavy burden to pay for a small sensor device. Small is a relative term considering Moore’s Law, but it’s still a big burden on a device with limited resources. The implication here is that in order for a device to even determine that it is in a state necessary to generate an event, that the device MUST support these object types. So, if a device doesn’t have these objects, then the required STATUS_FLAGS and EVEN_STATE properties remain static all the time. This point of view is supported by the various Alarm and Event BACnet interoperability building blocks (BIBBs). This is the “subscription approach”, in which a client must subscribe to the device in order to receive events from that particular device. The most common use case is a workstation that’s present 24/7 would add itself to a device’s recipient-list in order to receive events.
Camp 2 is of the thought that event generation can be *really* simple and that a device simply need to support the STAUS_FLAGS and EVENT_STATE properties. The values of these properties are then used to indicate whether or not the object is in a bad state. These properties can then be read at arbitrary times to determine if the device needs attention or not. This is the “polling approach” where a client could simply read these properties in a device and make a decision based on their values whether a device is in a bad state. The tax on the server device is much lower because all it has to do is update its STATUS_FLAGS and EVENT_STATE properties. Using the polling approach allows “alarm proxy” functionality which is akin to slave proxy functionality. One con that came up during the meeting is that this approach doesn’t scale well. Perhaps, as it was only briefly discussed, that may be true. But, I’d like to think the committee is an intelligent bunch and can find a way to get this approach to scale.
Personally, I’m not sure which camp I support. I can see both arguments, but I also don’t see in the standard where the “subscription approach” is mutually exclusive from the “polling approach”. It’s possible that the BIBBs imply this, but in this case I think the intent is just as important (if not more so) than what the standard says at the moment. But, this is just my humble opinion. 135-2008 is huge, and it could be that I’ve missed key phrase that others are seeing in Camp 1. It would not be the first time this has happened.
I do like the idea of an alarm proxy, though. Not as an “out”, but as a way to pay a lower tax for event and alarm generation and consumption. There are vendors out there who want to take the much simpler “polling approach” to avoid paying the object tax and I don’t blame them at all. The concept of an “alarm proxy” device would hopefully allow this.
We, as a committee, would have to create a new BIBB (or set of BIBBS) that indicate this functionality. This not only allows for interoperability for this functionality, but also allows end users a way to specify what they want.
Coffee helps me clear the fog. If you've found any of the posts on this blog helpful, I could always use more coffee.