Alarme und Zustände

In diesem Kapitel wird die OPC UA Alarms & Conditions (AC) Funktionalität des WinCC OA OPC UA Clients näher beschrieben. Diese ermöglicht es, Alarme von einem OPC UA Alarmserver zu empfangen und zu quittieren.

Die Abbildung des Alarms erfolgt auf ein Datenpunktelement im WinCC OA OPC UA Client Projekt über eine entsprechende Peripherieadresse. Damit ein Alarm am WinCC OA Client System ausgelöst wird, muss eine Meldebehandlung für Multiinstanzalarme an diesem Datenpunktelement parametriert sein (_alert_hdl Config). Multiinstanzalarme haben den Vorteil, dass eine Alarmaktion wie Kommen, Quittieren, Gehen extern auslösbar ist und nicht vom Event-Manager berechnet wird. Zudem können bei diesem Alarmtyp Zusatzinformationen in Alarmbegleitwerten (siehe Inhalte von Alarmbegleitwerten für OPC UA) gespeichert werden. Des Weiteren kann für jeden Alarm eine spezielle Alarmklasse mitgegeben werden, d.h. es wird nicht die parametrierte Alarmklasse verwendet.

Wichtige Hinweise und Einschränkungen zu OPC UA AC finden Sie unter Alarme und Zustände (Alarms&Conditions) und Unterstützte Alarmtypen und Einschränkungen.

Voraussetzungen

Damit der OPC UA Client Alarme und Conditions empfangen kann, müssen folgende Voraussetzungen erfüllt sein:

  • In der Sektion [drivers] der Config-Datei wurde der Config-Eintrag driverAckClassPrefix gesetzt. Siehe Quittierung von Alarmen.
  • Ein OPC UA Verbindungsdatenpunkt zum Server (siehe Parametrierung der Server) mit einer Subscription vom Typ Alarme & Zustände wurde erstellt (siehe Parametrierung einer Subscription).
  • Das Mapping der OPC UA Severity auf WinCC OA Alarmklassen hat stattgefunden. Siehe Abbildung der Alarmdaten.
  • Am DPE, welcher die Alarme empfangen soll, wurde eine Peripherieadresse (_address) mit der oben erstellten Subscription und dem Empfangsmodus Alarm angelegt. Über das Browsen nach Items werden dementsprechend nur Alarm Conditions im Browse-Ergebnis ausgegeben. Siehe Parametrierung einer Peripherieadresse.
  • Am gleichen DPE wurde eine Meldebehandlung für Multiinstanzalarme (_alert_hdl) angelegt. Der Alarm in WinCC OA wird nicht über den Wert des Datenpunktelementes, sondern direkt ausgelöst. D.h. es wird das Attribut _alert_hdl.._event vom Treiber gesetzt. Siehe Meldebehandlung für Multiinstanzalarme.

In diesem Kapitel wird anhand eines Beispiels Schritt für Schritt beschrieben, wie Alarme empfangen und quittiert werden können. Das hier angegebene Beispiel zeigt die Konfiguration eines diskreten Alarms bei Verwendung des WinCC OA OPC UA Servers.

Quittierung von Alarmen

Damit Alarme nicht direkt in WinCC OA, sondern über den OPC UA Server quittiert werden, ist folgende Vorgangsweise notwendig:

  1. Im Projekt müssen individuelle Alarmklassen mit einem eindeutigen Präfix angelegt werden. Erstellen Sie hierfür die entsprechenden Datenpunkte vom Typ _AlertClass und konfigurieren Sie die Alarmklasse.

  2. In der Config-Datei des Client Projektes muss der folgende Eintrag gesetzt werden:
    [driver]
    driverAckClassPrefix = "<Präfix>" //z.B. "OPCUA" für die Alarmklasse OPCUA_Alarm

Dieser Eintrag wird vom UI gelesen und führt dazu, dass der Alarm nicht mehr über den Event-Manager, sondern über den internen Treiberdatenpunkt _DriverCommon quittiert wird (siehe auch driverAckClassPrefix). Erst dann sendet der Server eine Bestätigung der Quittierung an den Client, damit das UI den Alarm in WinCC OA wie gewohnt quittieren kann.

Parametrierung einer Subscription

Um einen Alarm zu empfangen, ist die Parametrierung einer Subscription erforderlich. In der Subscription ist der Alarmtyp auszuwählen. Dieser Alarmtyp bestimmt die Abbildung der OPC UA Attribute auf WinCC OA Alarmbereiche. Aktuell unterstützt der WinCC OA OPC UA Client folgende Alarmtypen:

  • OffNormalAlarm
  • ExclusiveLimitAlarm
  • ExclusiveDeviationAlarm
  • WinCCOADiscreteAlarm
  • WinCCOAContinuousAlarm
  • Manual ... - die Node Id wird nicht automatisch herangezogen, sondern manuell vom Parametrierer eingetragen

Diese Typen enthalten bereits die Basis-Conditions wie Enabled, Active und Acknowledged. OPC UA Alarmtypen müssen in WinCC OA immer auf Multiinstanzalarme mit entsprechender Anzahl an Alarmbereichen abgebildet werden.

Für weitere Informationen siehe auch Unterstützte Alarmtypen und Einschränkungen weiter unten.

Abbildung: Beispiel einer Subscription-Parametrierung vom Typ Alarme und Zustände

Mapping Tabelle

Falls notwendig können in der Tabelle OPC UA Alarme einem bestimmten Alarmbereich in WinCC OA zugeordnet werden. Das ist nur dann sinnvoll, wenn das _alert_hdl mit mehr als zwei Bereichen konfiguriert wurde. Normalerweise wird für Multiinstanzalarme nur ein Gut- und ein Schlecht-Bereich verwendet.

In der Spalte "Status" kann eine Kombination aus UA Zustandsattributwerten definiert werden. Die Spalte "Range" definiert den Alarmbereich welcher gesetzt werden soll, wenn der Wert übereinstimmt.

Beispiel

Status Bereich
ActiveState=false 1
ActiveState=true;Range2=true 2
ActiveState=true;Range3=true 3

Die Attributnamen müssen für den ausgewählten Conditiontyp (oder Alarmtyp) gültig sein.

Abbildung der Alarmdaten

Damit in WinCC OA ein Alarm ausgelöst wird, muss am entsprechenden Datenpunktelement ein _alert_hdl Config vom Typ Multiinstanzalarm existieren. Die parametrierte Alarmklasse (_alert_class) hat dabei keine Bedeutung, da sich die aktuelle Alarmklasse aus der OPC UA Gewichtung (Severity) ergibt. Die Abbildung von der OPC UA Gewichtung auf die WinCC OA Alarmklasse wird im Panel OPC UA Alarmgewichtung definiert. Dieses Panel ist über das WinCC OA Systemmanagement aufrufbar.

Abbildung: Registerkarte OPC Treiber im WinCC OA Systemmanagement

In WinCC OA ergibt sich die Priorität eines Alarms aus der Priorität der Meldeklasse. D.h. die Priorität für einen Alarm wird über das Mapping der OPC UA Alarmgewichtung definiert. D.h. aus einer OPC UA Severity (Gewichtung) ergibt sich eine WinCC OA Alarmklasse und daraus eine WinCC OA Alarmpriorität und ein Quittierungsmodell. Diese können während der Alarmlebenszeit nicht mehr geändert werden.

Abbildung: Mapping der OPC UA Alarmgewichtung

Treiber

Wählen Sie hier den Treiberdatenpunkt _OPCUA<num> vom Typ _OPCUA, für den das Alarmgewichtungsmapping verwendet werden soll. <num> entspricht der Managernummer, mit der der OPC UA Client gestartet ist.

Bereiche

Geben Sie hier die Anzahl der Bereiche ein, auf die Gesamtgewichtung von 1000 aufgeteilt werden soll. Die maximale Anzahl von definierbaren Bereichen ist 30.

Mapping der OPC UA Severity auf die WinCC OA Alarmklasse

Die Severity (Gewichtung) in OPC UA erstreckt sich von 1 bis 1000, wobei 1 die kleinste Gewichtung darstellt und 1000 die höchste. Das Alarmmodell von WinCC OA wird über die Prioritäten 1 bis 255 definiert, wobei auch hier 1 die kleinste Priorität darstellt. Folglich müssen beliebig große Severity-Bereiche, die zusammen den gesamten Severity-Bereich abdecken, auf WinCC OA Alarmklassen abgebildet werden. Diese Alarmklassen können entweder bereits definierte WinCC OA Alarmklassen sein oder können selbst erstellt werden, falls der Alarm ebenso an der Peripherie quittiert werden soll (für weitere Informationen siehe Quittierung von Alarmen).

Das Mapping wird auf das interne Datenpunktelement _OPCUA.Config.AlarmPrioMapping geschrieben. Dieses DPE ist vom Typ dyn_string und speichert das Mapping im folgenden Format:

Severity1 AlertClass1
Severity2 AlertClass2
Severity3 AlertClass3
...

Das bedeutet, dass die WinCC OA Alarmklasse 1 (AlertClass1) für die OPC UA Severity1 bis Severity2 - 1 verwendet wird. Der letzte Meldebereich erstreckt sich bis zum höchsten OPC UA Severity-Wert 1000.

Parametrierung einer Peripherieadresse

Fügen Sie dem Datenpunktelement, das die Alarme empfangen soll, ein _address-Konfig hinzu und wählen Sie im Peripherieadresspanel den OPC UA Server aus. Danach muss die entsprechende Subscription vom Typ Alarme und Zustände ausgewählt werden.

Abhängig vom eingestellten Alarmtyp im Subscription-Parametrierpanel erfolgt das Browsen (Schaltfläche Get Item ID) im entsprechenden Modus.

Wie bei Daten und Ereignissen ist es ebenso bei Alarmen & Zuständen möglich entweder die Node ID oder Browse Pfad zu verwenden.

Parametrierung der Meldebehandlung

Legen Sie am gleichen Datenpunktelement eine Meldebehandlung für Multiinstanzalarme an. Der Alarm wird in diesem Fall nicht über den Wert des Datenpunktelementes, sondern direkt vom Treiber ausgelöst.

Die Alarmklasse muss hier nur definiert werden, damit die Meldebehandlung aktiviert werden kann und hat keinerlei Bedeutung. Die tatsächliche Alarmklasse ergibt sich aus der zuvor festgelegten Alarmgewichtung. Beispielsweise würde laut der oben durchgeführten Alarmgewichtung ein Server-Alarm mit Severity 75 am Datenpunktelement des Clients einen Alarm mit Alarmklasse OPCUA_Warning auslösen. Bei einer Severity von 175 oder mehr würde am Client ein Alarm mit Alarmklasse OPCUA_Danger ausgelöst werden.

Inhalte von Alarmbegleitwerten für OPC UA

Mithilfe der Meldebehandlung für Multiinstanzalarme ist es möglich, die unterschiedlichen Ereignisparameter als Alarmbegleitwerte auszugeben (für Informationen zu Alarmbegleitwerten allgemein siehe Begleitwerte und für Informationen zu den Konfig-Attributen für Alarmbegleitwerte siehe _alert_hdl). Die folgende Tabelle zeigt das aktuelle Mapping:

Attribut (vom Konfig _alert_hdl) OPC UA Ereignisdaten
_add_value_1 leer
_add_value_2 OPC UA Alarmmeldungstext
_add_value_3 OPC UA Severity (Gewichtung)
_add_value_4 OPC UA Quality Information vom Event

Sortierung von zeitgleichen Alarmen im Alarm- und Ereignisschirm

Um im Alarmschirm zeitgleiche Alarme sortieren zu können, kann ein Counter verwendet werden, der bei zeitgleichen Alarmen erhöht wird. Dieser Counter wird in den Begleitwerten abgespeichert.

Der Counter wird über den Eintrag "alertCounterAddValue" in der [opcua] Sektion der Konfigdatei aktiviert.

Anschließend muss in der Tabellenkonfiguration vom Alarm- und Ereignisschirm noch eine neue Spalte für den im Begleitwert gespeicherten Counter erstellt werden. Dann können Alarme zuerst nach der Zeit und sollte diese identisch sein, nach dem Counter sortiert werden.

Unterstützte Alarmtypen und Einschränkungen

Die korrekte Verarbeitung von Alarmen eines OPC UA Servers mit dem WinCC OA OPC UA Client hängt von einigen Faktoren ab. Wobei korrekte Verarbeitung bedeutet, dass der Zyklus eines Alarms am Server am Client richtig wiedergegeben wird.

Einerseits hängt das von den verwendeten Alarmtypen ab, andererseits auch von der Art wie sich die Alarmattribute am Server ändern. Da OPC UA Alarme sehr flexibel definiert sind und in WinCC OA nur fixe Alarmmodelle vorhanden sind, können nur eingeschränkte Modelle vom Client auf WinCC OA abgebildet werden.

Dabei gelten folgende Einschränkungen:

  • Die Alarm Severity darf sich nach dem Aktivieren eines Alarms bis zu seinem Verschwinden am Server nicht ändern.
  • Jeder Alarm darf nur einen Gutbereich und einen Alarmbereich haben.
  • Der Quittierungszustand eines Alarms darf sich von "Quittiert" nicht auf "Unquittiert" ändern, ohne dass der Alarm am Server neu ausgelöst wurde.

So ergibt sich aktuell eine Matrix für die unterstützten Kombinationen für die Konfiguration des WinCC OA UA Client (diese folgende Matrix gilt nur für WinCC OA OPC UA Client - die Matrix für den OPC UA Server finden Sie unter Unterstützte Alarmtypen und Quittierungsarten).

Anmerkung:
  • Die Quittierungseinstellung Alte Alarme quittieren wird nicht unterstützt.

  • Der Quittierungsart KAM und GING müssen quittiert werden wird für Impulsalarme nicht unterstützt.

  • Innerhalb des Alarmschirms werden nur die Werte des _alert_hdl.._event Attributes angezeigt, d.h. den Wert 0 für "Meldung KAM" und 2 für "Meldung GING".

  • Bei der Verwendung von "KAM und GiNG sind getrennt quittierungspflichtig" innerhalb des AES Schirmes ist es auf Seite des Clients nicht möglich, momentan nicht quittierbare Alarme zu blockieren (graue Hinterlegung und nicht klickbar) da diese Information nur serverseitig zur Verfügung steht. Dies führt dazu, dass ein mehrfaches quittieren innerhalb des Clients möglich ist, dieses jedoch entsprechend des korrekten Verhaltens nicht auf dem Server durchgeführt wird.

Nicht quittierbar Quittierung löscht KAM ist quittierbar KAM oder GING musst quittiert werden KAM und GING müssen quittiert werden
Binärer Alarm
Binärer Alarm (diskret)
Binärer Alarm (Impuls) N/A
Binärer Alarm (diskret, Impuls) N/A
Alarm kontinuierlicher Werte (2 Bereiche)
Alarm diskreter Werte (2 Bereiche)
Alarm diskreter Werte (Impuls, 2 Bereiche)
Alarm kontinuierlicher Werte (n Bereiche)
Alarm diskreter Werte (n Bereiche)
Alarm diskreter Werte (Impuls, n Bereiche)

Dynamic Alarm Conditions

Der OPC UA-Client kann nur Alarme empfangen, wenn die NodeId der Alarmbedingung in der Peripherieadresse konfiguriert ist. Dies ist eine Einschränkung von WinCC OA, da einige Server die ConditionId nicht in den Adressraum exportieren oder sogar dynamische ConditionIds verwenden.

Solche Alarme sind sehr schwer in WinCC OA zu konfigurieren, da es fast unmöglich ist, die ConditionId im Voraus zu bestimmen.

Zum Beispiel verwendet der S7 1500 OPC UA Server dynamische Bedingungen und daher konnte WinCC OA bisher keine Alarme von diesem Gerät empfangen.

Konfiguration

Um auch den Empfang von Alarmen ohne Konfiguration der ConditionId zu unterstützen, wird das Konzept einer Fallback-Adresse verwendet. Dadurch können alle Alarme, die über eine Alarm-Subscription, und die nicht auf eine explizit konfigurierte ConditionId abgebildet werden, auf eine beliebige Fallback-Alarmadresse abgebildet werden.

Diese Fallback-Adresse kann mit dem Config-Eintrag [opcua] alarmFallbackAddress konfiguriert werden. In diesem Fall kann das empfangende DPE eine hohe Anzahl an aktiven Alarminstanzen haben, was möglich ist da _alert_hdl einen Multi-Instanz-Alarm verwendet.

Wenn einem DPE mehr als eine Bedingung zugeordnet ist, sollten Sie in der Subscription immer UA Alarm text und UA Severity auswählen, da unterschiedliche Bedingungen einen unterschiedlichen Alarmtext und -schweregrad aufweisen können.