DE102008014151A1

DE102008014151A1 - Verfahren und Einrichtung zur Speicherung von Daten, die jeweils zu einer mehrere Attribute enthaltenden Alarm- oder Ereignismeldung gehören

Info

Publication number: DE102008014151A1
Application number: DE102008014151A
Authority: DE
Inventors: Werner Dipl.-Inform. Schmidt; Martin Dr. Hollender
Original assignee: ABB Technology AG
Current assignee: ABB Technology AG
Priority date: 2008-03-14
Filing date: 2008-03-14
Publication date: 2009-09-17
Also published as: WO2009112252A2; US20110029582A1; WO2009112252A3; CN102067118B; CN102067118A; EP2250591A2

Abstract

Die Erfindung bezieht sich auf ein Verfahren und eine entsprechende Einrichtung zur Speicherung von Daten, die jeweils zu einer mehrere Attribute enthaltenden Alarm- oder Ereignismeldung gehören, wobei in einer festgelegten Tabelle (T) ein erster Teil (z. B. 1, 2 und 3) der zu einer Alarm- oder Ereignismeldung gehörigen Attribute (1 bis 7) normiert direkt gespeichert wird und zusätzlich sowohl der erste Teil (z. B. 1, 2 und 3) als auch ein restlicher zweiter Teil (z. B. 4, 5, 6, 7) der Attribute (1 bis 7) als Verfügungsdatensatz (A) gespeichert werden.

Description

Die Erfindung bezieht sich auf ein Verfahren und eine Einrichtung zur Speicherung von Daten, die jeweils zu einer mehrere Attribute enthaltenden Alarm- oder Ereignismeldung gehören.
Früher wurden Alarme aus Industrieanlagen hauptsächlich auf einem Tableau oder mittels anderer Anzeigen sowie mittels Ausdrucken gemeldet, wobei typisch nur eine einfache tabellarische Struktur benutzt wurde. Heute ermöglichen Alarm- und Ereignismeldesysteme gemäß der OPC AE(Alarms & Events)Spezifikation eine Meldung herstellerspezifischer Attribute. In modernen Steuer- und Regelsystemen oder Leitsystemen im Rahmen von Industrie-Anlagen ist eine große Anzahl unterschiedlicher Alarm- und Ereignismelder oder Alarm- oder Ereignisquellen integriert, die typisch unterschiedliche herstellerspezifische Attribute aufweisen. In großen Leitsystemen können mehrere hundert herstellerspezifische Melder-Attribute vorhanden sein. Da ständig neue Quellen für Alarme und Ereignismeldungen in Steuer- und Regelsysteme integriert werden, wird künftig die Zahl der Attribute dynamisch zunehmen.
Process Information Management Systeme (PIMS) haben die Aufgabe Alarm- und Ereignisdaten zu archivieren. Sowohl als Protokoll über das eingetretene Ereignis in der industriellen Anlage, als auch als Datenbasis für unterschiedliche Analysen. Das bedeutet, dass ein solches Alarm- und Ereignis-Datenarchiv sowohl schnellen Zugriff auf relevante Information – beispielsweise für Anzeigezwecke – ermöglichen, als auch vollständige Information für Analysen bereithalten soll, die gegebenenfalls auch später durchgeführt werden.
Es ist erkennbar, dass es zunehmend aufwändiger wird die dynamisch wachsende Zahl von Meldungen in einer Datenbank zu speichern. Zur Lösung des Problems der Bereitstellung und Speicherung der Datenmenge sind zwei grundsätzliche Wege bekannt.
Gemäß einer ersten bekannten Lösungsvariante wird nur eine relevante Untermenge (subset) der Attribute normalisiert und dann in einer festgelegten Tabelle gespeichert. Dabei geht allerdings ein Teil der Information verloren. In manchen Industriezweigen, beispielsweise der pharmazeutischen Industrie ist ein solcher Informationsverlust nicht akzeptabel. Außerdem ist nicht immer im Voraus bekannt, welche Information nicht relevant ist, und welche Information relevant und deshalb zu speichern ist, und es ist oftmals auch nicht im voraus bekannt, welche späteren Analysen erforderlich werden können.
Bei einer zweiten bekannten Lösungsvariante wird je Ereigniskategorie eine eigene Tabelle benutzt. Alle Alarm- und Ereignisattribute werden gespeichert. Dazu müssen jedoch die Tabellen mit den Ereignisquellen synchronisiert werden, was ziemlich komplex sein kann. Möglicherweise muss eine große Anzahl von Tabellen kreiert werden. Ein Zugriff auf so gespeicherte Ereignisse erfordert ein komplexes Zusammensetzen von Information aus mehreren Tabellen, was üblicherweise den Vorgang sehr langsam macht.
Davon ausgehend liegt der Erfindung die Aufgabe zugrunde, ein Verfahren und eine Einrichtung anzugeben, um eine Möglichkeit sowohl zur vollständigen Speicherung von Alarm- und Ereignisdaten, als auch für einen schnellen Zugriff auf die Daten zu schaffen.
Diese Aufgabe wird gelöst durch ein Verfahren zur Speicherung von Daten, die jeweils zu einer mehrere Attribute enthaltenden Alarm- oder Ereignismeldung gehören, das die im Anspruch 1 angegebenen Merkmale aufweist. Vorteilhafte Ausgestaltungen und eine entsprechende Einrichtung sind in weiteren Ansprüchen angegeben.
Beim erfindungsgemäßen Verfahren und in einer entsprechenden Einrichtung zur Speicherung von Daten, die jeweils zu einer mehrere Attribute enthaltenden Alarm- oder Ereignismeldung gehören, wird demnach in einer Tabelle (fixed table) ein erster Teil der zu einer Alarm- oder Ereignismeldung gehörigen Attribute normiert gespeichert.
Typische Attribute sind beispielsweise: Name des quittierenden Benutzers, Name des Knotens an dem ein Ereignis (der Event) erzeugt wurde, geänderter Wert vorher/nachher, Diagnosecode oder Zeitstempel.
Mit der auch als fixed table bezeichneten Tabelle ist eine solche gemeint, deren Spalten vorab definiert sein müssen, die aber – gemäß einer vorteilhaften Ausgestaltung – auch als dynamische Tabelle ausgeführt sein kann, bei der nachträglich weitere Spalten hinzugefügt werden können.
Zusätzlich zur genannten normierten Speicherung des ersten Teils der Attribute werden sowohl der erste Teil als auch ein restlicher zweiter Teil der Attribute als Verfügungsdatensatz oder flat fallback record gespeichert. Dies kann vorteilhaft in der Sprache XML oder in der Form von BLOBs (Binary Large Objects) erfolgen, z. B. als Datenbankspalte oder als separate Datei.
Mit flat fallback record ist ein Speicherort sowie die Gesamtheit der dort (relativ) unstrukturiert abgelegten Attribute bezeichnet. Ein solcher, beispielsweise in XML gespeicherter Verfügungsdatensatz ist zwar für schnelle Abfragen nicht oder kaum geeignet, ist aber ein vollständiger Datensatz, der für spätere Analysen herangezogen werden kann.
Normalerweise wird der in der Tabelle gespeicherte normierte erste Teil der Attribute für Anzeigezwecke genutzt. Der erste, direkt gespeicherte Teil von Attributen ermöglicht einen sehr schnellen Zugriff. Typische Attribute die schnell verfügbar sein sollten sind z. B. Zeitstempel, Tagname, Ereigniskategorie oder Aktivierungszeitstempel. Für spätere Analysen kann die als Verfügungsdatensatz (fallback record) gespeicherte Gesamtinformation z. B. mittels XML-verarbeitender Einrichtungen moderner Datenbanken oder mittels Batch-Prozeduren wieder verfügbar gemacht werden.
Eine weitere Erläuterung der Erfindung und deren Vorteile ergibt sich aus der nachstehenden Beschreibung eines Ausführungsbeispiels anhand der Zeichnung.
1 zeigt im oberen Bereich schematisiert und beispielhaft mehrere Alarm- und Ereignisquellen AE-Quelle 1, AE-Quelle 2 bis AE-Quelle n mit mehreren Attributen 1 bis 7. Im Beispiel ist angenommen, dass die Attribute 1 bis 3 jeweils relevante Attribute sind, die für einen schnellen Zugriff zur Verfügung stehen sollen, also z. B. Zeitstempel, Tagname, Ereigniskategorie oder Aktivierungszeitstempel. Alarm- oder Ereignismeldungen der AE-Quellen 1 bis n werden in eine Tabelle T übernommen. Die Tabelle T hat mehrere Spalten, im Beispiel Spalten a bis c zur direkten Speicherung von normierten Attributen, sowie gegebenenfalls eine zusätzliche Spalte d oder weitere Spalten. Zur Speicherung der zu einer Alarm- oder Ereignismeldung gehörigen Information ist jeweils eine Zeile vorgesehen. Die Darstellung der in der ersten Zeile der Tabelle T gespeicherten Information bezieht sich z. B. auf Attribute einer Meldung der ersten AE-Quelle 1. Dabei sind die relevanten Attribute 1 bis 3 in den drei Spalten a bis c direkt gespeichert und zusätzlich alle Attribute, hier die Attribute 1, 2, 3, 5 und 6 als fallback record A in der Spalte d. Der Verfügungsdatensatz, also die Gesamtheit der Attribute 1, 2, 3, 5 und 6 kann stattdessen auch an anderem Ort abgelegt werden.
Eine Regel für ein normiertes oder umgerechnetes Attribut könnte beispielsweise lauten: wenn Attribut1 = ”+” und Atrribut3 = ”active”, dann speichere in Spalte d = ”on”.
Ein Verfügungsdatensatz könnte beispielsweise in einem folgenden Szenario hilfreich sein:
Bei einer Sollwertänderung eines Regelkreises wird ein Event erzeugt, bei dem der neue Sollwert in dem Attribut ”NewValue” abgelegt wird. Das Attribut ”NewValue” wird zunächst nicht als wichtig erachtet und nur im Verfügungsdatensatz abgespeichert, z. B. in der Form <attributes>...<NewValue>xy</NewValue>...</attributes>. Nach einigen Jahren Produktion kommt der Verdacht auf, dass es bei bestimmten Sollwerten zu Qualitätsproblemen kommt. Die Qualitätsprobleme lassen sich durch ein weiteres Event erkennen. Wäre das Attribut ”NewValue” nicht im Verfügungsdatensatz hinterlegt, so würde man es erst ab dem Zeitpunkt erfassen, zu dem man es als wichtig erkannt hat. Wertvolle Zeit zur Datengewinnung wäre vertan. Da ”NewValue” aber im Verfügungsdatensatz hinterlegt ist, kann man für den zurückliegenden Produktionszeitraum die Korrelation zwischen Sollwerten und Qualitätsproblemen berechnen, indem man entweder

a) die XMLfähigkeiten moderner Datenbanken ausnutzt und relativ langsam auf das XML-Element <NewValue> zugreift, oder
b) eine zusätzliche Spalte ”NewValue” anlegt und diese mit einem Batchprogramm rückwirkend mit Werten aus dem Verfügungsdatensatz befüllt. Die Auswertung kann dann sehr schnell erfolgen.

Die vorgesehene Normalisierung gleicht sowohl unterschiedliche Attributnamen mit gleicher Bedeutung, als auch unterschiedliche Attributwerte mit gleicher Bedeutung an. Eine Angleichung unterschiedlicher Attributnamen kann beispielsweise bedeuten, dass sowohl das Attribut ”user_name” als auch das Attribut ”user” in der gleichen Spalte ”user” abgespeichert werden. Ein Beispiel für eine Angleichung unterschiedlicher Attributwerte mit gleicher Bedeutung wäre: im Attribute ”Change” wird von Eventquelle1 ”on” und ”off” geschrieben, und von Eventquelle2 ”+” und ”–”. Die Normalisierung sorgt dann für Einheitlichkeit und schreibt in beiden Fällen ”+” und ”–”.
Im Extremfall kann die festgelegte Tabelle T leer sein, und die Alarm- und Eventattribute können ausschließlich als XML im Verfügungsdatensatz abgespeichert werden. Die XML-Fähigkeit moderner Datenbanken kann eine für viele Anwendungen ausreichend hohe Verarbeitungsgeschwindigkeit gewährleisten.
Gemäß einer vorteilhaften Ausgestaltung kann mit einer dynamischen Tabelle T mit beispielsweise den Attributen 1, 2, und 3 begonnen werden. Wenn nun eine Alarm- oder Ereignismeldung ein Attribut X besitzt, das bisher nicht in der Tabelle T vorhanden ist, so kann vorgesehen sein, dass die Tabelle T automatisiert um das Attribut X erweitert und der Wert dort abgespeichert wird. Der zugehörige Algorithmus würde dann lauten:
Prüfe ob eine Spalte X bereits vorhanden ist,
wenn ja -> Speichere den Wert in Spalte X,
wenn nein -> Erzeuge eine zusätzliche Spalte X. Speichere den Wert in Spalte X.
Wenn später eine hohe Abfragegeschwindigkeit für Zugriffe auf Werte in Spalte X gewünscht wird, kann ein Datenbankschlüssel auf diese Spalte gelegt werden.

Claims

Verfahren zur Speicherung von Daten, die jeweils zu einer mehrere Attribute enthaltenden Alarm- oder Ereignismeldung gehören, wobei – in einer festgelegten Tabelle (T) ein erster Teil (z. B. 1, 2 und 3) der zu einer Alarm- oder Ereignismeldung gehörigen Attribute (1 bis 7) normiert direkt gespeichert wird, und – zusätzlich sowohl der erste Teil (z. B. 1, 2 und 3), als auch ein restlicher zweiter Teil (z. B. 4, 5, 6, 7) der Attribute (1 bis 7) als Verfügungsdatensatz (A) gespeichert wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Alarm- oder Ereignismeldung jeweils aus einer Meldeeinrichtung in einer Industrie-Anlage stammt.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Speicherung aller Attribute (1 bis 7) als Verfügungsdatensatz in einer XML-Form oder als BLOB erfolgt.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Speicherung des Verfügungsdatensatzes in einer separaten Datei oder als Datenbank-Kolumne erfolgt.
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass eine als dynamische Tabelle ausgeführte Tabelle (T) verwendet wird, die automatisiert erweitert wird, um zusätzliche Attribute zu speichern.
Einrichtung zur Durchführung des Verfahrens gemäß einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass sie mittels einer Speichereinrichtung dafür eingerichtet ist, von mehreren Melde-Quellen (AE-Quelle 1 bis AE-Quelle n) gelieferte Alarm- oder Ereignismeldungen, die mehrere Attribute (1 bis 7) enthalten, einen ersten Teil (z. B. 1 bis 3) normiert in einer Tabelle (T) zu speichern, und außerdem die Information aller Attribute (1 bis 7) als Verfügungsdatensatz zu speichern.
Einrichtung nach Anspruch 6, dadurch gekennzeichnet, dass die Tabelle (T) als dynamische Tabelle ausgeführt und dafür eingerichtet ist, während des Betriebs zusätzliche Spalten zur Speicherung weiterer Attribute automatisiert einzurichten.