EP2250591A2 - 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

Info

Publication number
EP2250591A2
EP2250591A2 EP09720438A EP09720438A EP2250591A2 EP 2250591 A2 EP2250591 A2 EP 2250591A2 EP 09720438 A EP09720438 A EP 09720438A EP 09720438 A EP09720438 A EP 09720438A EP 2250591 A2 EP2250591 A2 EP 2250591A2
Authority
EP
European Patent Office
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
EP09720438A
Other languages
English (en)
French (fr)
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 Schweiz 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
Publication of EP2250591A2 publication Critical patent/EP2250591A2/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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.
EP09720438A 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 EP2250591A2 (de)

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
PCT/EP2009/001751 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

Publications (1)

Publication Number Publication Date
EP2250591A2 true EP2250591A2 (de) 2010-11-17

Family

ID=40953056

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09720438A Ceased 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

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)

Families Citing this family (4)

* 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
DE102013001926A1 (de) 2013-02-05 2014-08-07 Abb Ag System und ein Verfahren zur Ereignisprotokollierung in einer technischen Anlage oder einem technischen Prozess
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 深圳力维智联技术有限公司 软件用户行为回退处理方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030105811A1 (en) * 2001-05-02 2003-06-05 Laborde Guy Vachon Networked data stores for measurement data
US20060168013A1 (en) * 2004-11-26 2006-07-27 Invensys Systems, Inc. Message management facility for an industrial process control environment

Family Cites Families (9)

* 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
JP2002505484A (ja) * 1998-02-26 2002-02-19 サン・マイクロシステムズ・インコーポレーテッド データベースにおけるマルチエントリーとマルチテンプレートとの対照のための方法及びシステム
US6421571B1 (en) * 2000-02-29 2002-07-16 Bently Nevada Corporation Industrial plant asset management system: apparatus and method
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)
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

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030105811A1 (en) * 2001-05-02 2003-06-05 Laborde Guy Vachon Networked data stores for measurement data
US20060168013A1 (en) * 2004-11-26 2006-07-27 Invensys Systems, Inc. Message management facility for an industrial process control environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
YANLEI DIAO ET AL: "Rethinking Data Management for Storage-centric Sensor Networks *", 31 December 2007 (2007-12-31), XP055485410, Retrieved from the Internet <URL:http://web.mit.edu/tibbetts/Public/CIDR_2007_Proceedings/papers/cidr07p03.pdf> [retrieved on 20180618] *

Also Published As

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

Similar Documents

Publication Publication Date Title
DE60306674T2 (de) Verfahren und systeme zur regelung des zugriffs auf ein datenobjekt mittels sperren
EP1110127A1 (de) Informations-, bedien- und/oder beobachtungssystem mit modellbasierter benutzeroberfläche und verfahren zum modellbasierten bedienen und/oder beobachten
DE1499182B2 (de) Datenspeichersystem
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
DE19538448A1 (de) Datenbankmanagementsystem sowie Datenübertragungsverfahren
EP2073136B1 (de) System und Verfahren zum Erzeugen von Auswertedaten
DE10059103B4 (de) Einheit zur Verwaltung von in einer Datenverarbeitungseinrichtung gespeicherten Daten
WO1999017192A1 (de) Konfigurierungsverfahren für datenverarbeitungsanlagen
EP3699704A1 (de) System und verfahren zum überprüfen von systemanforderungen von cyber-physikalischen systemen
DE112011105475B4 (de) Programmierbare Logiksteuerung
EP0770946B1 (de) Verfahren zur automatisierten optimalen Redundanz-Auslegung von Messungen für die Leittechnik in Kraftwerken
EP3508928A1 (de) Verfahren zum verarbeiten von alarmen in einem prozessleitsystem sowie operator-system
EP1950635A1 (de) Verfahren zum Betrieb eines Automatisierungssystems
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
WO2012019614A1 (de) Verfahren zum kennzeichnen und erkennen einer aufbaustruktur eines produkts und entsprechendes produkt
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
DE112014002696T5 (de) Verfahren und System für effizientes Sortieren in einer relationalen Datenbank
EP4300327A1 (de) Verfahren zum bereitstellen von daten eines automatisierungssystems, suchverfahren zur ermittlung von daten eines automatisierungssystems, computerprogramm, computerlesbares medium und vorrichtung zur datenverarbeitung
DE102016215796A1 (de) Zuordnungseinheit und Verfahren zur Zuordnung von Objektdaten zu einem Objektidentifikator
DE2358689A1 (de) Verfahren und anordnung zur entwicklung einer funktionsspezifikation fuer ein rechnersystem

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100831

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA RS

RIN1 Information on inventor provided before grant (corrected)

Inventor name: HOLLENDER, MARTIN

Inventor name: SCHMIDT, WERNER

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20160714

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ABB SCHWEIZ AG

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20181124