Intrinsic und Algorithmic Alarming
Der Datenaustausch bei der Alarm- und Ereignisverarbeitung verwendet spezielle Objekttypen. Deren Besonderheit ist die Reaktion auf ein Ereignis, welche das Eintreten eines vordefinierten Zustands mit spezifizierten Kriterien darstellt. Ein Ereignis kann spezifizierte Aktionen auslösen oder nur registriert werden, z.B. in einem Betriebs- oder Alarm-Protokoll. Ein Ereignis kann auch einen Zustand repräsentieren, welcher einen Alarm auslöst und eine Quittierung durch einen Bediener erfordert.
BACnet definiert zwei verschiedene Mechanismen für das Erzeugen von Alarmen und Ereignissen.
Der erste Mechanismus wird als Intrinsic Alarming (objektinternes Melden) bezeichnet, weil er auf den objekteigenen Eigenschaften (Properties) beruht, die für das Überwachen eines Ereignisses oder Alarms zugrunde liegen.
Der andere Mechanismus wird als Algorithmic Alarming (regelbasierendes Melden) bezeichnet. Das regelbasierende Melden ist funktional umfassender, da es auf dem zusätzlichen Ereigniskategorieobjekt (Event Enrollment object) basiert.
Der WinCC OA BACnet Treiber kann Alarmmeldungen (UnconfirmedEventNotification, ConfirmedEventNotification) vom BACnet Gerät aufnehmen.
In diesem Kapitel wird die konsistente Meldebehandlung von BACnet Alarmen inklusive derer Quittierung behandelt. Natürlich bleibt dem Benutzer die Möglichkeit überlassen über den normalen Weg einzulesen und den Meldebehandlungs-Konfig am Empfangs-DPE zu parametrieren. In diesem Fall findet die Alarmbehandlung unabhängig vom BACnet Gerät und ausschließlich in WinCC OA statt.
Vorbedingungen für das Empfangen von BACnet Alarmen
Um BACnet Alarme und Ereignisse empfangen zu können, müssen vorher einige Einstellungen an den BACnet Objekten vorgenommen werden. Für Intrinsic Alarming beziehen sich diese Änderungen auf zwei Objekte. Das Erste ist jenes Objekt, das Intrinsic Alarming unterstützt (z.B. Analog Input - BACnet_AI). Beim zweiten handelt es sich um das Notification Class Objekt (NOC). Im Folgenden werden die Alarm-spezifischen Einstellungen beschrieben.
Intrinsic Alarming Objekt
In diesem Objekt müssen die entsprechenden Ereignisse aktiviert werden. Dies geschieht über das Property Event_Enable. Jedes Ereignis (TO_OFFNORMAL, TO_FAULT und TO_NORMAL) kann einzeln aktiviert werden. Für einen korrekten Betrieb in WinCC OA ist es nicht erlaubt z.B. nur TO_OFFNORMAL zu aktivieren, TO_NORMAL jedoch nicht, da in diesem Fall WinCC OA nur einen kommenden Alarm jedoch nie einen gehenden Alarm empfangen würde. Die erlaubten Einstellungen werden in der folgenden Tabelle zusammengefasst:
| TO_OFFNORMAL | TO_FAULT | TO_NORMAL | Beschreibung |
|---|---|---|---|
| 0 | 0 | 0 | Es werden keine Ereignisse empfangen. |
| 1 | 0 | 1 | Nur OFFNORMAL Ereignisse werden empfangen. |
| 0 | 1 | 1 | Nur FAULT Ereignisse werden empfangen. |
| 1 | 1 | 1 | OFFNORMAL und FAULT Ereignisse werden empfangen. |
Zudem muss ein korrektes Notification Class Objekt mittels des Propertys Notification_Class gesetzt werden. Dieses Property muss auf ein gültiges Notification Class Objekt zeigen.
Notification Class
Die Notification Class bestimmt die BACnet Priorität der Ereignisse und ob ein Alarm quittiert werden muss oder nicht. Des Weiteren kann der Benutzer im Property Recipient_List auswählen, ob unconfirmed oder confirmed Services verwendet werden sollen und zu welchen Zeiten die Empfänger erreichbar sind.
Für weitere Informationen siehe Kapitel "BACnet_NOC" in der Beschreibung des BACnet-Addons.
Empfängerliste
Im entsprechenden Notification Class Objekt muss der Treiber in die Empfängerliste eingetragen werden, da das BACnet Gerät die Ereignismeldungen lediglich an die Empfänger versendet, die in dieser Liste eingetragen sind. In einem redundanten WinCC OA Projekt müssen beide BACnet Treiber auf den zwei Servern der Liste hinzugefügt werden.
Um den Treiber in eine Empfängerliste einzutragen, kann das Datenpunktelement _BacnetDevice.NotificationClasses verwendet werden. Auf diesem Element können alle Instanzen von Notification Classes eingetragen werden, bei denen sich der Treiber automatisch anmelden soll. Ob sich der Treiber mit BACnet-Adresse oder Device Identifier anmelden soll, kann mit Bit16 von _BacnetDevice.ConfigFlags definiert werden (0 = BACnet-Adresse, 1 = Device Identifier). Die Anmeldung des Treibers erfolgt bei jedem Verbindungsaufbau oder bei Änderungen am _BacnetDevice.NotificationClasses Datenpunktelement.
Zum Abmelden des Treibers muss Bit15 von _BacnetDevice.ConfigFlags gesetzt und anschließend ein neuer Wert auf _BacnetDevice.NotificationClasses geschrieben werden.
Mapping von BACnet Alarmen zu WinCC OA
Für die Behandlung von BACnet Alarmen in WinCC OA werden zwei korrekt konfigurierte Konfigs benötigt - _address (Peripherieadresse) und _alert_hdl (Meldebehandlung).
Mit dem _address Konfig wird definiert, auf welches Datenpunktelement der Alarm gemeldet wird. Für das Mapping wird eine Peripherieadresse mit der Event_State Property verwendet. Der Empfangsmodus muss auf Alarm eingestellt sein.
Beim Intrinsic Alarming ist für das Event_State Property ausschließlich der Empfangsmodus Alarm erlaubt.
Der zweite Konfig, welcher benötigt wird, ist _alert_hdl. Dieser muss am gleichen Datenpunktelement (Event_State Property) parametriert sein wie das Peripherieadress-Konfig. Das Meldebehandlungs-Konfig muss ein Multiinstanzalarm sein (für Informationen zu Multiinstanzalarmen siehe Meldebehandlung für Multiinstanzalarme).
BACnet Alarminformationen
Die Informationen in einer empfangenen Event Notification können folgende sein:
| Informationsfeld | Beschreibung |
|---|---|
|
Process Identifier (Prozess Identifikator) |
Dies ist der Wert, der in der Empfängerliste (Recipient_List) parametriert wird. Derzeit wird dieser Wert in WinCC OA nicht überprüft, wenn eine Event Notification empfangen wird. Deshalb ist es erforderlich, dass der Process Identifier, welcher in der Empfängerlisteder zu finden ist, der gleiche ist wie der, der vom Treiber zum Quittieren verwendet wird (Config-Eintrag processIdentifier). |
|
Initiating Device Identifier ( Geräte Identifikator) |
Teil der Peripherieadresse. Definiert an welches DPE der Alarm gerichtet ist. |
|
Event Object Identifier (Ereignisobjekt Identifikator) |
Teil der Peripherieadresse. Definiert an welches DPE der Alarm gerichtet ist. |
|
Notification Class (Meldeklasse) |
Wird nicht auf WinCC OA gemappt. |
|
Time Stamp (Zeitstempel) |
Mit diesem Zeitstempel wird der Alarm in WinCC OA ausgelöst, wenn es sich dabei um eine Zeit und um keine fortlaufende Nummer handelt. Der Zeitstempel wird für nachträgliche Quittierungen verwendet. |
|
Priority (Priorität) |
In WinCC OA wird die Priorität in der Meldeklasse definiert. Es findet ein Mapping zwischen der BACnet Priorität und den WinCC OA Meldeklassen statt (siehe "Alarmprioritätsmapping" weiter unten). Durch die Verwendung dieses Mappings, welches von der BACnet Priorität abhängt, wird die am besten geeignetste WinCC OA Meldeklasse ausgewählt. Die BACnet Originalpriorität wird auf das Attribut _alert_hdl.._add_value_3 gemappt. |
|
Event Type (Ereignisart) |
Der Ereignistyp ist abhängig vom Objekttyp und wird auf das Attribut _alert_hdl.._add_value_6 gemappt. Dieser Parameter beschreibt, welche Art von Ereignis empfangen wurde und kann z.B. change-of-bitstring (0), change-of-state (1) oder change-of-value (2) annehmen. Abhängig von der Ereignisart werden verschiedene spätere Ereignisdaten auf Alarmbegleitwerte gemappt (siehe Abschnitt "Inhalte von Alarmbegleitwerten" weiter unten). |
|
Message Text (Meldetext) |
Wird auf _alert_hdl.._add_value_2 gemappt. |
|
Notify Type (Meldeart)
|
Kann entweder ALARM, EVENT oder ACK_NOTIFICATION sein. Diese Information wird benutzt, um den Alarm zu aktivieren, deaktivieren oder zu quittieren. In WinCC OA wird zwischen ALARM und EVENT nicht unterschieden. Beide werden auf die gleiche Art behandelt. Eine Meldung kann durch beide Typen ausgelöst werden. ACK_NOTIFICATION quittiert die WinCC OA Meldung. |
|
AckRequired (Quittierung erforderlich) |
Dieser Parameter legt fest, ob ein Ereignis eine Quittierung erfordert. Wird nur intern verwendet. |
|
From State (Vom Status) |
Wird nur intern verwendet. |
|
To State (Zum Status) |
Dieses Feld enthält den eigentlichen Wert des Event_State Propertys. Dieser wird auch auf das Attribut _alert_hdl.._add_value_1 gemappt. |
|
Event Values (Ereigniswerte) |
Die Ereigniswerte sind vom Objekt abhängig, welches die Meldung gesendet hat und von der BACnet Ereignisart. Diese Werte werden auf die unten beschriebenen _add_value_* Attribute geschrieben. |
Die Bestätigung an eine ConfirmedEventNotification erfolgt automatisch im Treiber. Der Benutzer hat keine Möglichkeit die Bestätigung durchzuführen.
Inhalte von Alarmbegleitwerten
Mithilfe der Meldebehandlung für Multiinstanzalarme ist es möglich, die unterschiedlichen Ereignisparameter als Alarmbegleitwerte auszugeben (für Informationen zu Alarmbegleitwerten siehe Begleitwerte und Informationen zu den Konfig-Attributen für Alarmbegleitwerte siehe _alert_hdl). Die folgende Tabelle zeigt das aktuelle Mapping:
| Attribut (vom Konfig _alert_hdl) | BACnet Ereigniswerte |
|---|---|
| _add_value_1 | Derzeitige Wert von Event_State |
| _add_value_2 | BACnet Ereignisnachricht |
| _add_value_3 | BACnet Priorität |
| _add_value_4 | Reserviert |
| _add_value_5 | Reserviert |
| _add_value_6 | BACnet Ereignistyp (der Wert dieses Feldes legt fest, auf welche Art die Felder weiter unten interpretiert werden) |
| _add_value_7 |
OUT_OF_RANGE (5): Status-Flags (status flags) COMMAND_FAILURE (3): Status-Flags (status flags) CHANGE_OF_STATE (1): Status-Flags (status flags) UNSIGNED_RANGE (11): Status-Flags (status flags) CHANGE_OF_LIFE_SAFETY (8): Status-Flags (status flags) FLOATING_LIMIT(4): Status-Flags (status flags) DOUBLE_OUT_OF_RANGE(14): Status-Flags (status flags) SIGNED_OUT_OF_RANGE(15): Status-Flags (status flags) UNSIGNED_OUT_OF_RANGE(16): Status-Flags (status flags) CHANGE_OF_CHARACTERSTRING(17): Status-Flags (status flags) CHANGE_OF_STATUS_FLAGS(18): Status-Flags (status flags) CHANGE_OF_RELIABILITY(19): Status-Flags (status flags) CHANGE_OF_BITSTRING(0): Status-Flags (status flags) |
| _add_value_8 |
OUT_OF_RANGE: Über-/Unterschrittener Wert (exceeding value) COMMAND_FAILURE: Befehlswert (command value) CHANGE_OF_STATE: Art der Statusänderung (type of state change) UNSIGNED_RANGE: Über-/Unterschrittener Wert (exceeding value) CHANGE_OF_LIFE_SAFETY: Neuer Life Safety Mode FLOATING_LIMIT: Referenzwert DOUBLE_OUT_OF_RANGE: Über-/Unterschrittener Wert (exceeding value) SIGNED_OUT_OF_RANGE: Über-/Unterschrittener Wert (exceeding value) UNSIGNED_OUT_OF_RANGE: Über-/Unterschrittener Wert (exceeding value) CHANGE_OF_CHARACTERSTRING: Geänderter Wert CHANGE_OF_STATUS_FLAGS: leer CHANGE_OF_RELIABILITY: Zuverlässigkeit (reliability) CHANGE_OF_BITSTRING: Wert |
| _add_value_9 |
OUT_OF_RANGE: Totband (dead band) COMMAND_FAILURE: Rückgemeldeter Wert (feedback value) CHANGE_OF_STATE: Neuer Statuswert (new state value) UNSIGNED_RANGE: leer CHANGE_OF_LIFE_SAFETY: Neuer Life Safety Zustand FLOATING_LIMIT: Sollwert DOUBLE_OUT_OF_RANGE: Totband (dead band) SIGNED_OUT_OF_RANGE: Totband (dead band) UNSIGNED_OUT_OF_RANGE: Totband (dead band) CHANGE_OF_CHARACTERSTRING: Alarmwert CHANGE_OF_STATUS_FLAGS: leer CHANGE_OF_RELIABILITY: leer CHANGE_OF_BITSTRING: leer |
| _add_value_10 |
OUT_OF_RANGE: Über-/Unterschrittenes Limit (exceeding limit) COMMAND_FAILURE: leer CHANGE_OF_STATE: leer UNSIGNED_RANGE: Über-/Unterschrittenes Limit (exceeding limit) CHANGE_OF_LIFE_SAFETY: Erwartete Life Safety Operation FLOATING_LIMIT: Fehlergrenze DOUBLE_OUT_OF_RANGE: Über-/Unterschrittenes Limit (exceeding limit) SIGNED_OUT_OF_RANGE: Über-/Unterschrittenes Limit (exceeding limit) UNSIGNED_OUT_OF_RANGE: Über-/Unterschrittenes Limit (exceeding limit) CHANGE_OF_CHARACTERSTRING: leer CHANGE_OF_STATUS_FLAGS: leer CHANGE_OF_RELIABILITY: leer CHANGE_OF_BITSTRING: leer |
Alarmquittierung
Alarmquittierung bedeutet in diesem Abschnitt, dass die Quittierung im BACnet System erfolgt. Das bedeutet:
Ein Alarm wird erst dann in WinCC OA quittiert, wenn der Alarm im Gerät quittiert wird. Dadurch sind die Quittierungszustände in WinCC OA und im Gerät immer gleich.
Der Benutzer kann natürlich die beiden Quittierzustände jederzeit wieder voneinander trennen. Dies ist von der Konfiguration abhängig. In diesem Abschnitt werden die möglichen Probleme, die eine Quittierung von BACnet Alarmen mit sich ziehen kann, behandelt.
Normalerweise wird ein Alarm direkt in WinCC OA quittiert, was bedeutet, dass die Benutzeroberfläche eine Nachricht an den WinCC OA-Event Manager sendet, um den Alarm zu quittieren. Wenn eine Quittierung auch am Gerät erfolgen soll, muss zuerst eine Quittiernachricht an das Gerät gesendet werden. Erst dann sendet das Gerät eine Bestätigung der Quittierung an den Treiber, damit dieser den Alarm in WinCC OA quittieren kann. Für den Fall wurden in WinCC OA Meldeklassen für die externe Quittierung implementiert. Aktiviert werden diese Meldeklassen über den Config-Eintrag:
[driver]
driverAckClassPrefix = "BACnet"
Dieser Eintrag sagt dem UI, dass es Alarme, deren Meldeklassen mit dem Prefix "BACnet" beginnen, nicht direkt quittieren soll, sondern stattdessen über einen speziellen internen Datenpunkt des Treibers, welcher veranlasst, dass die Quittiernachricht zuerst zum BACnet Gerät geschickt wird.
Quittierinformationen
Für die Alarmquittierung benötigt der Treiber Informationen, um den richtigen Alarm im BACnet Gerät zu quittieren. Diese Informationen werden auf die AlertId geschrieben, über die der Treiber die Alarme identifizieren kann. Die AlertId wird intern vom Treiber verwendet, sodass diese für den Benutzer nach außen nicht sichtbar ist.
Im Service für Quittierungen sind Informationen enthalten, die auf die AlertId geschrieben werden. Diese werden in der unteren Tabelle beschrieben. Die Elemente in fett sind erforderlich, um die zu quittierende Ereignismeldung eindeutig zu identifizieren. Wenn diese Elemente nicht exakt mit denen aus dem Gerät übereinstimmen, wird der Fehler "Inconsistent Parameter" gemeldet und die Quittierung wird nicht durchgeführt.
|
Acknowledging Process Identifier (Quittierungsprozess-ID) |
Die Prozess-ID im Quittiertelegramm muss mit der Prozess-ID in der Meldung (Notification) übereinstimmen. Das bedeutet, dass die Prozess-ID in der Empfängerliste der NOC und die Prozess-ID im Treiber gleich sein müssen. |
|
Event Object Identifier (Ereignisobjekt-ID) |
Wird aus der entsprechenden Peripherieadresse ermittelt. |
|
Event State Acknowledged (Ereignisstatus quittiert) |
Wert vom Ereignisstatus. |
|
Time Stamp (Zeitstempel) |
Entspricht dem Quellzeitstempel des Alarms. Der Quellzeitstempel kann auch eine fortlaufende Nummer sein. |
|
Acknowledgment Source (Quittierungsquelle) |
Benutzer, der die Quittierung vorgenommen hat (es wird der Defaultwert der BACnet API verwendet). |
|
Time Of Acknowledgment (Zeit der Quittierung) |
Zeit der Alarmquittierung (es wird der Defaultwert der BACnet API verwendet). |
Beziehung zwischen BACnet Notification Class (NOC) und WinCC OA Meldeklasse
In BACnet werden die Eigenschaften der Meldebereiche über das NOC Objekt definiert. Es besteht aus der Priorität und den Ack_Required Properties. Das Ack_Required Property definiert, welche Übergänge (TO_OFFNORMAL, TO_FAULT, TO_NORMAL) quittiert werden müssen und welche nicht. In WinCC OA werden die Eigenschaften der Meldebereiche über die Meldeklasse (siehe _alert_class (Meldeklasse)) definiert. BACnet NOC und WinCC OA Meldeklasse sind voneinander abhängig.
Alarmprioritätenmapping für den BACnet Treiber
Zurzeit wird die WinCC OA Meldeklasse von der BACnet Priorität abgeleitet. Ein Mapping kann über das Panel Alarmprioritätenmapping vorgenommen werden (Systemmanagement -> BACnet -> BACnet Alarmprioritätenmapping). Mit einem richtig konfigurierten Mapping wird über die WinCC OA Alarmpriorität die BACnet Priorität wiedergespiegelt.
Hinweis
Damit die "BACnet" Registerkarte im Systemmanagement sichtbar ist, muss das BACnet Subprojekt vorher in das WinCC OA Projekt eingebunden werden. Für weitere Informationen siehe Kapitel "Einbinden und Konfiguration der Objektbibliotheken" in der BACnet.chm unter < wincc_oa_path >/BACnet_<Version>/help/.
Dieses Mapping findet für einen Treiberdatenpunkt statt und wird auf das interne Datenpunktelement _Bacnet_<Treibernummer>.Config.AlarmPrioMapping geschrieben. Falls ein Mapping für ein BACnet Gerät im Parametrierpanel des BACnet Treibers definiert wurde (DPE _BacnetDevice.AlarmPrioMapping), wird dieses bevorzugt verwendet. Andernfalls wird das Mapping verwendet, welches am Treiber definiert ist. Beide DPEs sind vom Typ dyn_string und speichern das Mapping im folgenden Format:
Priority1 AlertClass1
Priority2 AlertClass2
Priority3 AlertClass3
...
Das bedeutet, dass die WinCC OA Meldeklasse 1 (AlertClass1) für die BACnet Prioritäten Priority1 bis Priority2 - 1 verwendet wird. Der letzte Meldebereich erstreckt sich bis zum höchsten BACnet Prioritätswert 255.
Nicht jede WinCC OA Quittierart kann für die Einstellungen des NOC Ack_Required Propertys verwendet werden oder macht auch Sinn, damit das erwartete Verhalten auftritt. In der folgenden Tabelle wird anhand einer Matrix dargestellt welche Einstellungen des NOC Ack_Required Propertys mit welchen WinCC OA Quittierarten kombiniert werden können. In dieser Matrix wird nur der Übergang zu TO_OFFNORMAL gezeigt - das gleiche gilt jedoch für den Übergang zu TO_FAULT.
| Nicht quittierbar | Quittieren löscht | KAM ist quittierbar | KAM oder GING ist quittierungspflichtig | KAM und GING sind getrennt quittierungspflichtig | |
|---|---|---|---|---|---|
|
AckRequired: TO_OFFNORMAL =0 TO_NORMAL =0 |
OK | Nicht zulässig | OK | OK | OK |
|
AckRequired: TO_OFFNORMAL =1 TO_NORMAL =0 |
Nicht zulässig | Nicht zulässig | Nicht zulässig | Teilweise zulässig | OK |
|
AckRequired: TO_OFFNORMAL =0 TO_NORMAL =1 |
Nicht zulässig | Nicht zulässig | Nicht zulässig | Teilweise zulässig | OK |
|
AckRequired: TO_OFFNORMAL =1 TO_NORMAL =1 |
Nicht zulässig | Nicht zulässig | Nicht zulässig | Nicht zulässig | OK |
Das Quittieren von BACnet Alarmen findet wie gewohnt im WinCC OAAlarm- und Ereignisschirm statt. Deshalb muss der Alarm sichtbar und quittierbar sein, damit dieser auch am BACnet Gerät quittiert werden kann. Zum Beispiel ist es nicht zulässig, die WinCC OA Meldeart Nicht quittierbar zu verwenden, wenn der BACnet Alarm eine Quittierung erwartet. Ansonsten wird ein Übergang am Gerät nicht durchgeführt.
Die Quittierart Quittieren löscht darf nicht verwendet werden, da es dem BACnet-Alarmmodell nicht entspricht, in dem Alarme nie gehen, wenn sie quittiert wurden.
Die Quittierart KAM ist quittierbar darf nicht für Alarme verwendet werden, die eine Quittierung am Gerät erwarten, da am Gerät der Alarm auch quittiert werden muss, wenn dieser bereits schon ging.
KAM oder GING ist quittierungspflichtig muss mit Vorsicht verwendet werden, wenn für einen Übergang im Gerät eine Quittierung erforderlich ist, denn sobald der andere Übergang in WinCC OA quittiert wurde, wird der Alarm in WinCC OA entfernt und ein Alarm bleibt am Gerät unquittiert übrig. Das hängt damit zusammen, dass es im BACnet Gerät KAM und GING nicht gibt, sonder nur KAM, nur GING oder KAM und GING quittierbar sein können.
Hinweis
Im Fall der Kombination von Quittierart "KAM oder GING ist quittierpflichtig" mit BACnet Notification Klasse "AckRequired: TO_OFFNORMAL=1, TO_NORMAL=0" kann es passieren, dass Alarme am Gerät nicht quittiert werden, wenn sie in der falschen Reihenfolge quittiert werden (GING bevor KAM).
Dieses Verhalten kann durch Setzen vom KonfigeintragalarmExternAckFirst=1 in der [bacnet] Sektion vermieden werden.
Dadurch wird zuerst der Übergang quittiert, der extern quittiert werden muss - das sorgt für die Quittierung am Gerät. Dieser Eintrag sollte allerdings nur gesetzt werden, wenn diese Kombination im Projekt auch wirklich benötigt wird, ansonsten sollte der Default-Wert 0 beibehalten werden.
Allgemein ist es nicht erlaubt, die Einstellung Alte Meldungen quittieren an der Meldeklasse zu setzen, da ein BACnet Gerät es nicht erlaubt, alte Alarme zu quittieren.
Alarmgeneralabfrage
Ein wichtiges Thema beim Mapping von BACnet Alarmen auf WinCC OA ist der Abgleich des Alarmzustandes an bestimmten Stellen. Zum Beispiel, wenn der Treiber die Verbindung zum Gerät verliert und nach Wiederaufbau der Verbindung der Alarmstatus richtig ausgegeben werden soll.
Für diesen Zweck verwendet der Treiber den GetEventInformation Service, um den Alarmstatus in allen Fällen wiederherzustellen. GetEventInformation wird verwendet, weil von diesem Service alle relevanten Informationen geliefert werden. Die Wiederherstellung des Alarmstatus wird auch Ereignisgeneralabfrage (Event GQ) in der folgenden Beschreibung genannt. Während einer Event GQ gleicht der Treiber den Alarmstatus zwischen dem BACnet Gerät und WinCC OA ab. Das bedeutet, dass alle Alarme, die nur in WinCC OA existieren, jedoch nicht im Gerät, gelöscht werden und Alarme, die nur im Gerät existieren jedoch nicht in WinCC OA , in WinCC OA ausgelöst werden. Wenn der Alarmstatus auf beiden Seiten der gleiche ist, passiert nichts.
Der Treiber führt eine automatische Event GQ in den folgenden Fällen aus:
-
Beim Verbindungsaufbau zum Gerät
-
Bei einer Redundanzumschaltung
Eine Event GQ kann auch manuell am Gerät über das interne DPE _Bacnet_Device.Command.GQ ausgelöst werden. Dazu muss der richtige Wert auf das DPE gesetzt werden (siehe Beschreibung interner Datenpunkte).
Sollte GetEventInformation nicht durch das BACnet Gerät unterstützt werden, so versucht der Treiber den GetEnrolmentSummary Dienst zu benutzen. Sollte dieser ebenfalls nicht existieren, so greift der Treiber auf GetAlarmSummary zurück. Beide Alternativen besitzen gewisse Einschränkungen im Vergleich zu GetEventInformation, welche im Folgenden beschrieben werden:
GetEnrolmentSummary
Dieser Dienst muss zweimal ausgeführt werden, um eine Liste aller aktiven Zustände zu erhalten. Innerhalb der ersten Abfrage werden alle unquittierten Alarme und anschließend in der zweiten Abfrage alle Alarme mit dem Status ACTIVE gelesen. Dies ist erforderlich aufgrund des Umstandes, dass der Dienst nicht alle aktiven und unquittierten Alarme innerhalb einer Abfrage zur Verfügung stellen kann. Anschließend muss der Treiber die Eigenschaften Event_Time_Stamps sowie Acked_Transitions lesen, um alle nötigen Informationen für die Alarmsynchronisation abschließen zu können.
GetAlarmSummary
Der Dienst liefert nur die aktiven Alarme und ist auf den Notify_Type Alarm beschränkt. Aus diesem Grund dürfen die Objekte nicht den Notify_Type Event aufweisen, da sonst der Active Status nicht als Ergebnis des GetAlarmSummary zurückgeliefert werden kann. Weiters werden die unquittierten Alarm Status nicht zurückgeliefert, wenn der momentane Status NORMAL ist. Aus diesem Grund ist GetAlarmSummary eine schlechte Alternative für Alarmsynchronisierungen und besitzt hoffentlich nur eine geringe praktische Relevanz.
Event_Message_Texts Property
Das optionale Property Event_Message_Texts enthält die letzten Alarmtexte und kann verwendet werden, um durch eine Ereignisgeneralabfrage auch Alarmtexte abzufragen. Das Property muss vom Gerät unterstützt werden. Damit der Treiber bei einer Generalabfrage das Property ausliest, muss Bit 3 von _BacnetDevice.Flags auf 1 gesetzt werden.
