- One of the goals of revising alarming was to get algorithmic and intrinsic reporting consistent. This is why we add FAULT_STATE, so that the Event EnrollmentMessage 1 of 4 , Jun 1, 2010View SourceOne of the goals of revising alarming was to get algorithmic and intrinsic reporting consistent. This is why we add FAULT_STATE, so that the Event Enrollment gets to MULTI_STATE_FAULT. Along this line, I believe we need the FAULT_STATUS_FLAGS algorithm, so that the EE object can go to MEMBER_FAULT.To make this complete, we need to adapt the text for MEMBER_FAULT in addendum p clause 12 preamble changes. It is now very dedicated to the Global Group object. Also, it appears that the GGO's Reliability property language needs to get changed similar to e.g. the Multi-state Input Reliability property.This brings up another point: Currently (in RK-005-10), the order of reliability evaluation in the EE is:1) EE object internal2) Monitored object Fault Flag3) Fault algorithmSo the FAULT_STATUS_FLAGS would never be in effect in the EE if the GGO sets its Reliability to MEMBER_FAULT and sets its Fault flag. The EE would always go to MONITORED_OBJECT_FAULT. This is also the case for Multi-state, if the monitored object goes to MULTI_STATE_FAULT. The monitoring EE would go to MONITORED_OBJECT_FAULT, not MULTI_STATE_FAULT.Changing the order of reliability evaluation would have other side effects. E.g. if the fault algorithm would have precedence over the monitored object's fault flag, then the EE would go e.g. to MULTI_STATE_FAULT, but the monitored object would be really unreliable, e.g. indicating OPEN_LOOP.Given this, I can buy that the order of evaluation is as in RK-005-10, and the EE goes to MONITORED_OBJECT_FAULT.BernhardBernhard Isler
Siemens Switzerland Ltd
Building Technologies Division
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Carl Neilson
Sent: Friday, May 28, 2010 6:57 PM
Subject: RE: [bacnet-oswg] RE: RK-005 Issues
3) I added in FAULT_STATUS_ FLAGS for the Global Group. Is this really
required. The global group describes how the Member_Status_ Flags impact
the GG's Reliability / Status_Flags which is similar to how Fault_Values
impact the Life Safety object's Reliability / Status_Flags. But on the
other hand, the Event Enrollment object won't need the fault algorithm
as it will just monitor the GG's Status_Flags.
- It doesn’t make sense to have the FAULT_STATUS_ FLAGS when CHANGE_OF_STATUS_ FLAGS is the event algorithm.
Note that the CHANGE_OF_STATUS_ FLAGS event algorithm does not handle the TO_FAULT transition. So in addition to the CHANGE_OF_STATUS_ FLAGS there is the monitoring of the fault bit in the target StatusFlags and the generation of a fault transition when it is set occurs. For the Global Group, this would work regardless as the Global Group monitors the fault bit of the Member_Status_ Flags and sets is Reliability if the Fault bit is set. For other objects types, if the Fault bit is set and it is being monitored by an Event Enrollment, the Event Enrollment will notice the fault bit and set its Reliability to MONITORED_OBJECT_ FAULT.
But in the case where there is some other object type that has a property, X, of type BACnetStatusFlags which is not the Status_Flags property, and for which the object's Status_Flags property does not track the Fault bit, then when the Fault bit in X is set, and Event Enrollment would not generate a Fault transition.
And this is the reason for the dilemma.