[go: up one dir, main page]

WO2009112252A2 - Verfahren und einrichtung zur speicherung von daten, die jeweils zu einer mehrere attribute enthaltenden alarm- oder ereignismeldung gehören - Google Patents

Verfahren und einrichtung zur speicherung von daten, die jeweils zu einer mehrere attribute enthaltenden alarm- oder ereignismeldung gehören Download PDF

Info

Publication number
WO2009112252A2
WO2009112252A2 PCT/EP2009/001751 EP2009001751W WO2009112252A2 WO 2009112252 A2 WO2009112252 A2 WO 2009112252A2 EP 2009001751 W EP2009001751 W EP 2009001751W WO 2009112252 A2 WO2009112252 A2 WO 2009112252A2
Authority
WO
WIPO (PCT)
Prior art keywords
attributes
alarm
event message
event
record
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2009/001751
Other languages
English (en)
French (fr)
Other versions
WO2009112252A3 (de
Inventor
Werner Schmidt
Martin Hollender
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ABB Technology AG
Original Assignee
ABB Technology AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ABB Technology AG filed Critical ABB Technology AG
Priority to CN2009801099420A priority Critical patent/CN102067118B/zh
Priority to EP09720438A priority patent/EP2250591A2/de
Publication of WO2009112252A2 publication Critical patent/WO2009112252A2/de
Publication of WO2009112252A3 publication Critical patent/WO2009112252A3/de
Priority to US12/880,656 priority patent/US20110029582A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2358—Change logging, detection, and notification

Definitions

  • the invention relates to a method and a device for storing data, which in each case belong to an alarm or event message containing multiple attributes.
  • alarms from industrial plants were reported mainly on a panel or by other displays, as well as by printouts, typically using only a simple tabular structure.
  • OPC AE Alarms & Events
  • Today, alarm and event reporting systems according to the OPC AE (Alarms & Events) specification enable notification of manufacturer-specific attributes.
  • OPC AE Alarms & Events
  • modern control and regulation systems or control systems in the context of industrial plants a large number of different alarm and event messages or alarm or event sources are integrated, which typically have different manufacturer-specific attributes.
  • manufacturer-specific detector attributes can be present.
  • As new sources of alarms and event messages are constantly being integrated into control systems, the number of attributes will increase dynamically in the future.
  • PIMS Process Information Management Systems
  • the object of the invention is to provide a method and a device in order to create a possibility for the complete storage of alarm and event data as well as for a quick access to the data.
  • a first part of the attributes associated with an alarm or event message is stored in a fixed table.
  • Typical attributes are for example: name of the acknowledgment user, name of the node on which an event (the event) was generated, changed value before / after, diagnosis code or timestamp.
  • the table which is also referred to as a fixed table, refers to one whose columns must be defined in advance, but which-according to an advantageous embodiment-can also be designed as a dynamic table in which additional columns can be subsequently added.
  • both the first part and also a remaining second part of the attributes are stored as a disposable data record or flat fallback record.
  • This can advantageously be done in the XML language or in the form of BLOBs (Binary Large Objects), e.g. For example, as a database column or as a separate file.
  • BLOBs Binary Large Objects
  • Flat fallback record is a storage location and the entirety of the (relatively) unstructured attributes stored there.
  • Such an inventory record stored in XML for example, is not or hardly suitable for fast queries, but is a complete record that can be used for later analyzes.
  • the normalized first part of the attributes stored in the table is used for display purposes.
  • the first, directly stored part of attributes allows very fast access.
  • Typical attributes that should be available quickly are z. For example, timestamp, tag name, event category, or activation timestamp.
  • the total information stored as a fallback record can be z. B. be made available again by means of XML-processing facilities modern databases or by batch procedures.
  • AE source 1 shows schematically and by way of example several alarm and event sources AE source 1, AE source 2 to AE source n with a plurality of attributes 1 to 7.
  • the attributes 1 to 3 are respectively relevant attributes are to be available for quick access, so z.
  • Alarm or event messages of the AE sources 1 to n are transferred to a table T.
  • the table T has several columns, in the example columns a to c for the direct storage of normalized attributes, and optionally an additional column d or further columns. For storing the information associated with an alarm or event message, one line is provided in each case.
  • the representation of the information stored in the first row of the table T relates, for.
  • attributes of a message of the first AE source 1 are directly stored in the three columns a to c and additionally all attributes, here the attributes 1, 2, 3, 5 and 6 as a fallback record A in column d.
  • the disposal record that is the entirety of the attributes 1, 2, 3, 5 and 6 can instead be stored elsewhere.
  • an asset record might be helpful in a scenario that is:
  • the intended normalization adapts both different attribute names with the same meaning as well as different attribute values with the same meaning.
  • an alignment of different attribute names can mean that both the attribute "user_name” and the attribute "user” are stored in the same column "user”.
  • An example of an equalization of different attribute values with the same meaning would be: in the attribute "Change” Event Sourcei writes “on” and “off 1 , and from event source 2 " + “and” - "Normalization then ensures consistency and writes in both Cases "+” and "-”.
  • the specified table T can be empty, and the alarm and event attributes can only be stored as XML in the disposition data record.
  • the XML capability of modern databases can ensure a high enough processing speed for many applications.
  • a dynamic table T with, for example, the attributes 1, 2, and 3. If now an alarm or event message has an attribute X, which is not present in the table T, it can be provided that the table T is automatically extended by the attribute X and the value is stored there.
  • the associated algorithm would then be:

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)

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 wird.

Description

Verfahren und Einrichtung zur Speicherunq von Daten, die jeweils zu einer mehrere Attribute enthaltenden Alarm- oder Ereignismeldunq gehören
Beschreibung
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.
Fig. 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 Attributi ="+" und Attribut3="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 "NewVa- lue" 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 Eventquellei "on" und "off1 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 Alarmoder 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

Patentansprüche
1. 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.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die Alarmoder Ereignismeldung jeweils aus einer Meldeeinrichtung in einer Industrie-Anlage stammt.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Speicherung aller Attribute (1 bis 7) als Verfügungsdatensatz in einer XML-Form o- der als BLOB erfolgt.
4. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Speicherung des Verfügungsdatensatzes in einer separaten Datei oder als Datenbank-Kolumne erfolgt.
5. 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.
6. 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.
7. 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.
PCT/EP2009/001751 2008-03-14 2009-03-12 Verfahren und einrichtung zur speicherung von daten, die jeweils zu einer mehrere attribute enthaltenden alarm- oder ereignismeldung gehören Ceased WO2009112252A2 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN2009801099420A CN102067118B (zh) 2008-03-14 2009-03-12 用于存储分别属于包含多个属性的警告或事件消息的数据的方法和装置
EP09720438A EP2250591A2 (de) 2008-03-14 2009-03-12 Verfahren und einrichtung zur speicherung von daten, die jeweils zu einer mehrere attribute enthaltenden alarm- oder ereignismeldung gehören
US12/880,656 US20110029582A1 (en) 2008-03-14 2010-09-13 Method and device for storing data belonging to an alarm or event message containing multiple attributes

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008014151A DE102008014151A1 (de) 2008-03-14 2008-03-14 Verfahren und Einrichtung zur Speicherung von Daten, die jeweils zu einer mehrere Attribute enthaltenden Alarm- oder Ereignismeldung gehören
DE102008014151.8 2008-03-14

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/880,656 Continuation US20110029582A1 (en) 2008-03-14 2010-09-13 Method and device for storing data belonging to an alarm or event message containing multiple attributes

Publications (2)

Publication Number Publication Date
WO2009112252A2 true WO2009112252A2 (de) 2009-09-17
WO2009112252A3 WO2009112252A3 (de) 2009-12-03

Family

ID=40953056

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/001751 Ceased WO2009112252A2 (de) 2008-03-14 2009-03-12 Verfahren und einrichtung zur speicherung von daten, die jeweils zu einer mehrere attribute enthaltenden alarm- oder ereignismeldung gehören

Country Status (5)

Country Link
US (1) US20110029582A1 (de)
EP (1) EP2250591A2 (de)
CN (1) CN102067118B (de)
DE (1) DE102008014151A1 (de)
WO (1) WO2009112252A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013001926A1 (de) 2013-02-05 2014-08-07 Abb Ag System und ein Verfahren zur Ereignisprotokollierung in einer technischen Anlage oder einem technischen Prozess

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014076524A1 (en) * 2012-11-16 2014-05-22 Data2Text Limited Method and apparatus for spatial descriptions in an output text
US9092958B2 (en) * 2013-03-15 2015-07-28 Wal-Mart Stores, Inc. Alarm processing systems and methods
CN105740131B (zh) * 2014-12-09 2020-09-25 深圳力维智联技术有限公司 软件用户行为回退处理方法及装置

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7082426B2 (en) * 1993-06-18 2006-07-25 Cnet Networks, Inc. Content aggregation method and apparatus for an on-line product catalog
EP1057123A1 (de) * 1998-02-26 2000-12-06 Sun Microsystems, Inc. Verfahren und system für die mehrfacheingabe und den multischablonenvergleich in einer datenbank
US6421571B1 (en) * 2000-02-29 2002-07-16 Bently Nevada Corporation Industrial plant asset management system: apparatus and method
US20030105811A1 (en) * 2001-05-02 2003-06-05 Laborde Guy Vachon Networked data stores for measurement data
US6965895B2 (en) * 2001-07-16 2005-11-15 Applied Materials, Inc. Method and apparatus for analyzing manufacturing data
US6745175B2 (en) * 2001-08-02 2004-06-01 National Instruments Corporation System and method for a shared memory architecture for high speed logging and trending
US6978260B2 (en) * 2002-04-23 2005-12-20 Hewlett-Packard Development Company, L.P. System and method for storing data
US20040002958A1 (en) * 2002-06-26 2004-01-01 Praveen Seshadri System and method for providing notification(s)
US20060168013A1 (en) * 2004-11-26 2006-07-27 Invensys Systems, Inc. Message management facility for an industrial process control environment
US8041676B2 (en) * 2005-12-02 2011-10-18 International Business Machines Corporation Backup and restore of file system objects of unknown type
US7472108B2 (en) * 2006-05-16 2008-12-30 International Business Machines Corporation Statistics collection using path-value pairs for relational databases

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013001926A1 (de) 2013-02-05 2014-08-07 Abb Ag System und ein Verfahren zur Ereignisprotokollierung in einer technischen Anlage oder einem technischen Prozess
EP2775361A2 (de) 2013-02-05 2014-09-10 Abb Ag System und Verfahren zur Ereignisprotokollierung in einer technischen Anlage oder einem technischen Prozess
US9152604B2 (en) 2013-02-05 2015-10-06 Abb Ag System and method for event logging in a technical installation or a technical process

Also Published As

Publication number Publication date
CN102067118A (zh) 2011-05-18
WO2009112252A3 (de) 2009-12-03
DE102008014151A1 (de) 2009-09-17
CN102067118B (zh) 2013-11-20
EP2250591A2 (de) 2010-11-17
US20110029582A1 (en) 2011-02-03

Similar Documents

Publication Publication Date Title
DE60306674T2 (de) Verfahren und systeme zur regelung des zugriffs auf ein datenobjekt mittels sperren
DE69032689T2 (de) Rechnersysteme mit einer Prozessdatenbank und Verfahren zur Benutzung in diesen Systemen
DE19844013A1 (de) Strukturierter Arbeitsordner
WO2000007079A1 (de) Informations-, bedien- und/oder beobachtungssystem mit modellbasierter benutzeroberfläche und verfahren zum modellbasierten bedienen und/oder beobachten
DE10346478A1 (de) Flexibler Softwareupdate für Automatisierungssysteme über Internet
DE1499182B2 (de) Datenspeichersystem
EP1950639A1 (de) Verfahren zum Betreiben einer Prozessanlage, Prozessanlage und Computerprogrammprodukt
EP3699704A1 (de) System und verfahren zum überprüfen von systemanforderungen von cyber-physikalischen systemen
EP3508928A1 (de) Verfahren zum verarbeiten von alarmen in einem prozessleitsystem sowie operator-system
WO2009112252A2 (de) Verfahren und einrichtung zur speicherung von daten, die jeweils zu einer mehrere attribute enthaltenden alarm- oder ereignismeldung gehören
EP3364257A1 (de) Verfahren zum betrieb eines engineering-systems für ein industrielles prozessautomatisierungssystem und steuerungsprogramm
EP2073136B1 (de) System und Verfahren zum Erzeugen von Auswertedaten
DE112011105475B4 (de) Programmierbare Logiksteuerung
DE19538448A1 (de) Datenbankmanagementsystem sowie Datenübertragungsverfahren
DE10059103B4 (de) Einheit zur Verwaltung von in einer Datenverarbeitungseinrichtung gespeicherten Daten
WO1999017192A1 (de) Konfigurierungsverfahren für datenverarbeitungsanlagen
EP0770946B1 (de) Verfahren zur automatisierten optimalen Redundanz-Auslegung von Messungen für die Leittechnik in Kraftwerken
EP1950635A1 (de) Verfahren zum Betrieb eines Automatisierungssystems
WO2012019614A1 (de) Verfahren zum kennzeichnen und erkennen einer aufbaustruktur eines produkts und entsprechendes produkt
EP2329374A1 (de) Testmodul und verfahren zum testen einer o/r-abbildungs-middleware
EP2136303B1 (de) Verfahren zum Steuern einer automatischen Aktualisierung von Datensichten in einem Computersystem
DE10354938A1 (de) Datenverarbeitungssystem mit automatisierbarer Verwaltung und Verfahren zur automatisierten Verwaltung eines Datenverarbeitungssystems
DE10228142B4 (de) System zur Sicherung von Softwarekomponenten und/oder Computerprogrammen
EP2518644A1 (de) Verfahren zur Steuerung der Übersetzung von vorgegebenen Regeln und/oder eingehenden Daten eines Datenstroms
DE102006021048A1 (de) Verfahren, Vorrichtung und System zur konfigurationsabhängigen Steuerung der Informationsbereitstellung

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980109942.0

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09720438

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2009720438

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 3380/KOLNP/2010

Country of ref document: IN

NENP Non-entry into the national phase

Ref country code: DE