Loading ...
Sorry, an error occurred while loading the content.
  • Isler, Bernhard
    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 Enrollment
    Message 1 of 4 , Jun 1, 2010
    View Source
    • 0 Attachment
      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 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 internal
      2) Monitored object Fault Flag
      3) Fault algorithm
      So 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.
      Bernhard Isler
      Siemens Switzerland Ltd
      Building Technologies Division

      From: bacnet-oswg@yahoogroups.com [mailto:bacnet-oswg@yahoogroups.com] On Behalf Of Carl Neilson
      Sent: Friday, May 28, 2010 6:57 PM
      To: bacnet-oswg@yahoogroups.com
      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.
