Hi I would go for the following: If Reliability is present, and has a value other than NO_FAULT_DETECTED, then Event_State should be FAULT in all of theMessage 1 of 3 , Jun 19, 2008View SourceHiI would go for the following:If Reliability is present, and has a value other than NO_FAULT_DETECTED, then Event_State should be FAULT in all of the objects.But please note: If Reliability is MULTI_STATE_FAULT, this does not mean that Present_Value is unreliable. It indicates that Present_Value took a value that is in the Fault_Values property, but is completely reliable. This is another class of FAULT then such as if a sensor is broken, a configuration errror etc., which causes the object and Present_Value being unreliable.While the MULTI_STATE_FAULT makes sense to be reported using the standard event type of the object (according Table 13-2), the broken sensor case has no well support for being notified when using the standard event type. Why this? Using the standard event type, the event parameters convey an unreliable Present_Value, but not the Reliability value. I guess a client would have higher interest in the Reliability value than a Present_Value which is to be considered random.It becomes even worse with the Multistate objects: A client is not always capable of distinguishing the MULTI_STATE_FAULT case from the broken sensor case! Given the sensor case and accidentally the Present_Value takes on a value that it is also in Fault_Values, then the event notification looks exactly the same!BernhardBernhard Isler
Siemens Switzerland Ltd
Building Technologies Group
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Christoph Zeller
Sent: Donnerstag, 19. Juni 2008 12:14
Subject: Antwort: [bacnet-oswg] Multistate object Event_State
Hi Rob and all,
My personal feeling is, that we should use the connection between
reliability and event-state throughout the standard
as this gives more information than keeping its state in NORMAL.
Especially Reliability should never reed anything other
than NO-FAULT-DETECTED otherwise I judge it as a "Hardware-Fault
As far as I remember there is an agreement that the intrinsic-reporting
should be worked on (Germantown 2008). David Fisher
is forced to organise a meeting solemly for this topic.
One of the points is the definition of the dependencies between
FAULT-reporting and OFF-NORMAL reporting as well as the
definition of the properties destributed together with FAULT-events.
Regards Christoph Zeller
Fr. Sauter AG
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
http://www.sauter- controls. com
This communication, and the information it contains is for the sole use of
the intended recipient. It is confidential, may be legally privileged and
protected by law. Unauthorized use, copying or disclosure of any part
thereof may be unlawful. If you have received this communication in error,
please destroy all copies and kindly notify the sender.
Before printing out this e-mail or its attachments, please consider
it is really necessary to do so.
Using less paper helps the environment.
"Rob Johnson" <bob_johnson@ mac.com>
Gesendet von: bacnet-oswg@ yahoogroups. com
Bitte antworten an
bacnet-oswg@ yahoogroups. com
bacnet-oswg@ yahoogroups. com
[bacnet-oswg] Multistate object Event_State
Question about the relationship between Reliability and Event_State.
As we all know, there are some inconsistencies on this point. But we
are looking for guidance on how to handle Event_State without
intrinsic reporting. The Multistate Input has one model (Event_State
is tied to Reliability if intrinsic reporting is not enabled). The
Multistate Output has another (Event_State is always NORMAL if
intrinsic reporting is not enabled). Newer object definitions also
have a mix of approaches. Which approach is preferred?