-
EINFÜHRUNG
-
Gebiet der Erfindung
-
Die
Erfindung bezieht sich auf ein Betriebsinformationsverwaltungssystem
(PIMS) für
die Industrie, wie zum Beispiel Nahrungsmittel-, Getränke-, Pharma-
und Versorgungsindustrie.
-
Erörterung
des Stands der Technik
-
Eines
der technischen Hauptprobleme vieler PIMS ist, wie die enorme Rohdatenmenge
zu bewältigen ist,
die durch Betriebseinrichtungen, wie zum Beispiel einem Drucksensor,
erfasst wird. Zum Beispiel kann es in einem typischen Pharmabetrieb
zehn- oder sogar hunderttausend Elemente, wie zum Beispiel Temperatur- und
Drucksensoren und -ventile, geben, für die es jeweils eine Wertänderung
jede Sekunde geben kann. Ebenso ist für jedes Element ein hoher Genauigkeitsgrad
für die
Daten erforderlich. Solche Systeme laufen typischerweise rund um
die Uhr und sammeln die ganze Zeit Daten von der Betriebseinrichtung.
-
Folglich
ist es allgemein für
viele PIMS erforderlich, sehr hohe Datenraten von Betriebseinrichtungen zu
bewältigen,
um Terabytes an Daten zu speichern und einen effizienten und benutzerfreundlichen
Zugang zu den Daten für
die Auswertung zu ermöglichen.
Zum Beispiel kann es für
einen FDA regulierten Pharmabetrieb erforderlich sein, Betriebsdaten
sieben Jahre online zu speichern.
-
Ein
zweites Hauptproblem ist die Beschaffenheit (oder Form) der Daten
selbst. Jede Wertänderung besteht
aus einem Zeitstempel, dem eigentlichen Wert und einem Qualitätsindikator.
Da die Daten verwendet werden, um Trends im Produktverlauf zu erkennen,
werden sie lediglich nach der Zeit abgefragt, das heißt, der Zeitstempel
ist in der SQL-Ausdrucksweise der Primärschlüssel.
-
Vordem
war ein Ansatz, relationale Datenbanktechnologie (RDBMS) zu verwenden.
Diese Technologie ist allgemein weit verbreitet und es gibt eine
große
Kenntnisbasis, diese zu unterstützen.
Sie weist jedoch die Schwierigkeit auf, sehr große Datenmengen im Terabyte-Bereich
zu bewältigen.
Diese Leistungsprobleme werden durch das Bestreben verschlimmert,
den Zeitstempel als ein Index (Primärschlüssel) zu verwenden. In diesem
Fall wird eine zeitbasierte Abfrage tatsächlich zu einem Durchsuchen
einer Tabelle. Es gibt folglich einen Mangel an Skalierbarkeit,
während
die Datensatzgröße zunimmt.
-
Diese
Probleme haben zu der Verwendung eines hybriden Ansatzes in manchen
Systemen geführt,
in dem sowohl flach strukturierte Dateien und RDBMS-Dateien verwendet
werden. Die Prozessdaten werden in flachen Dateien mit typischerweise
einer flachen Datei pro Zeitperiode, wie zum Beispiel einem Tag
oder einer Woche, gespeichert. Metadaten werden in der RDBMS gespeichert.
Dies stellt eine Verbesserung gegenüber einem reinen RDBMS-Ansatz
dar; es gibt jedoch immer noch einen Bedarf, Datenmengen durch Verwerfen unter
Verwendung statistischer Methoden zu verringern und Zeitstempel
auf Sekunden- oder sogar Minutenauflösung zu runden, alles, um den
Plattenplatz zu verringern und somit die Suchzeiten auf Kosten der
Datengenauigkeit zu verbessern. Ein anderes Problem ist eine schlechte
Leistung auf Grund des durch die RDBMS-Schicht eingeführten zusätzlichen
Aufwands.
-
Die
Erfindung ist daher darauf gerichtet, ein Betriebsinformationsverwaltungssystem
bereitzustellen, um diese Probleme anzugehen.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Gemäß der Erfindung
wird in einer Ausführungsform
ein Betriebsinformationsverwaltungssystem gemäß Anspruch 1 bereitgestellt.
-
In
einem Gesichtspunkt umfasst der Datenbankcontroller Mittel zum Speichern
von Elementobjekten in einer oberen hierarchischen Ebene, wobei
jedes Elementobjekt einer bestimmten Prozessvorrichtung zugeordnet
wird.
-
In
einem Gesichtspunkt umfasst der Datenbankcontroller Mittel zum Speichern
eines Jahresdatenfeldobjekts, das mit jedem Elementobjekt verknüpft ist,
wobei das Jahresobjekt ein Datenfeld von Referenzen auf Tagesdatenfeldobjekte
umfasst.
-
In
einem anderen Gesichtspunkt umfasst der Datenbankcontroller Mittel
zum Speichern eines Ereignisbehälters,
der mit jedem Tagesdatenfeldobjekt verknüpft ist, wobei der Ereignisbehälter verknüpfte Listendatenfelder
von Datenereignisobjekten umfasst.
-
In
einem anderen Gesichtspunkt umfasst der Datenlogger Mittel zur Pufferspeicherung
empfangener Ereignisdaten.
-
In
einem weiteren Gesichtspunkt umfasst der Datenlogger Mittel zur
intakten Pufferspeicherung der Ereignisdaten in Blöcken, die
verknüpfte
Listenstrukturen sind
-
In
einem Gesichtspunkt umfasst der Datenlogger Mittel zur anfänglichen
Zuteilung einer frischen verknüpften
Liste und zur nachfolgenden Übertragung
gesäuberter
Blöcke
zur frischen verknüpften
Liste, um die Notwendigkeit der Zerstörung gesäuberter Blöcke und der Erzeugung frischer
Blöcke
nach einem Datensäuberungsvorgang
zu vermeiden.
-
In
einem weiteren Gesichtspunkt umfasst der Datenlogger Mittel zum
Einfügen
eines Zeitstempels in jeden Block der frischen verknüpften Liste
und zur regelmäßigen Zerstörung von
Blöcken,
die für
eine Zeitperiode, die einen Grenzwert überschreitet, nicht benutzt
wurden.
-
DETAILLIERTE
BESCHREIBUNG DER ERFINDUNG
-
Kurzbeschreibung der Zeichnungen
-
Die
Erfindung wird deutlicher aus der folgenden Beschreibung einiger
Ausführungsformen
davon verstanden werden, die beispielhaft nur mit Bezug auf die
begleitenden Zeichnungen gegeben werden, in denen:
-
1 eine
schematische Darstellung eines PIMS der Erfindung ist, die mit einem
PLC verbunden ist; und
-
2 eine
diagrammatische Darstellung der Datenbankstruktur ist.
-
Beschreibung der Ausführungsformen
-
In
den Zeichnungen ist ein Betriebsinformationsverwaltungssystem 1 dargestellt,
das zur Erfassung von Prozesssteuerungsdaten mit einem PLC 10 verbunden
ist. Das System 1 umfasst einen Datenlogger 2, der
mit einem Pufferspeicher 3 verbunden ist. Der Datenlogger 2 ist
ebenfalls mit einem Datenbankcontroller 4 verbunden, der
wiederum mit einer Objektdatenbank 5 verbunden ist.
-
Die
Rohereignisse, die von dem Datenlogger 2 empfangen werden,
werden nicht in einer gleichförmigen
Rate empfangen, da dies von der Art der Prozessaktivität abhängt. Die
Prozessaktivität
kann zum Beispiel Brauen oder Stromerzeugung sein. Um diese Ungleichförmigkeit
zu bewältigen,
verwendet der Datenlogger 2 den Pufferspeicher 3 als
einen Puffer. Er speichert Rohereignisse in Objekten, wobei jedes
Objekt in verknüpften
Blocklisten gespeichert ist und jeder Block ein Datenfeld von bis
zu 500 Rohereignissen darstellt.
-
Das
System 1 umfasst ebenso Clients 7 und ein Konfigurationsdienstprogramm 8,
das mit einem LAN 9 verbunden ist. Die Clients erstellen
den Endbenutzern die Abfragedaten (Trends). Das Konfigurationsdienstprogramm 8 wird
verwendet, um die Systemparameter festzulegen (zum Beispiel, mit
welchen PLCs zu verbinden ist). Das LAN wird verwendet, die Softwarebestandteile
zu Kommunikationszwecken zusammen zu verbinden.
-
Der
Controller 4 speichert die Daten in der Objektdatenbank 5,
in der:
Es ein „Element"-Objekt pro Datenquelle
(zum Beispiel Drucksensor) gibt und mehrere Ereignisobjekte, die
mit jedem Elementobjekt verknüpft
sind;
Die Ereignisobjekte als verknüpfte Datenfeldlisten gespeichert
wird;
Jedes Ereignisobjekt Zeit-, Wert- und Qualitätsdatenfelder
aufweist;
Das Qualitätsfeld
nur durch Ausnahme gespeichert wird; und
Ein Teil des Zeitstempels
in der Datenbankstruktur kodiert ist, die entsprechend der Zeitperioden
hierarchisch ist.
-
In 2 ist
die Datenbank 5 veranschaulicht. Die obere Ebene enthält Elementobjekte 20,
von denen jedes mit einer Jahresdatenfeldebene 21 von JahresDatenfeld-Objekten
mit einer Ebene 22 von TagesDatenfeld-Objekten und mit
einer BasisEreignisBehälter-Datenfeldebene 23 verknüpft ist.
Jedes JahresDatenfeld-Objekt
ist mit 365 TagesDatenfeld-Objekten in der Ebene 22 verknüpft. Jedes
TagesDatenfeld-Objekt ist mit 24 Ereignisbehältern in der Ebene 23 verknüpft. Der
Aufbau der EreignisBehälter-Ebene 23 ist
ebenfalls in 2 dargestellt. Sie umfasst EreignisBehälter-, EreignisTupel-
und AusnahmeQualität-Datenfelder.
Ein Elementobjekt umfasst die Zeit- und Wertfelder des EreignisTupel-Datenfelds
und einen Ausnahmequalitätswert in
dem AusnahmeQualität-Datenfeld.
-
Diese
Datenbankstruktur spart ungefähr
sechs Bytes Speicherplatz pro Ereignis gegenüber früheren Ansätzen. Sie ermöglicht sehr
schnelles Suchen mit Zugriff auf eine Stunde des Interesses in einer
begrenzten und festen Zahl von Schritten. Dies rührt daher, da die Datenbankstruktur
selbst den Index bildet und es keinen Bedarf für RDBMS-Indices gibt. Diese
letztere Eigenschaft stellt eine hierarchische Komprimierung wirkungsvoll
bereit. Es wurde herausgefunden, dass die Datenbank 5 das
Schreiben von mehr als 300.000 Ereignissen pro Sekunde und das Lesen
von mehr als 1 Million Ereignissen pro Sekunde erlaubt.
-
Genauer
umfasst jedes Rohereignis einen 64-bit Zeitstempel, einen Ereigniswert
variabler Länge
und einen 16-bit Qualitätswert.
Der Datenlogger 2 verwendet den maximal verfügbaren physikalischen
Speicher für
den Pufferspeicher und innerhalb des zugewiesenen Speichers erzeugt
er zu Beginn der Datenerfassung leere Listen. Jeder Block jeder
Liste enthält
einen Zeitstempel, der angibt, wann er erzeugt wurde und der Zeitstempel
wird nachfolgend während
der Datenerfassung aktualisiert, um anzuzeigen, wann der Block zuletzt verwendet
wurde. Wenn sich die Blöcke
mit Rohereignissen füllen,
werden die Daten über
den Controller 4 in die Datenbank 5 übertragen.
Der Datenlogger vermeidet die (zeitintensive) Notwendigkeit der
Zerstörung
und Erzeugung von Blöcken
bei Säuberungsvorgängen, indem
er gesäuberte
Blöcke
einfach einer Freiliste zufügt. Periodisch
werden die Daten übertragen
und der Block der Freiliste zugefügt.
-
Der
Datenlogger 2 ist ebenso tätig, die Menge des reservierten
Pufferspeichers zu einem Zeitpunkt zu minimieren. Der Zweck dieser
Eigenschaft ist sicherzustellen, dass es ausreichend verfügbaren Speicher
gibt, um Zeiten zu bewältigen,
in denen es eine übermäßig große Menge
an Rohereignissen gibt, die durch den PLC ausgegeben werden. Ein
Beispiel einer solchen Situation ist das Auftreten eines Feuers
an einigen der Prozesssteuereinrichtungen. Die Minimierung des reservierten
Pufferspeichers wird durch periodisches Lesen der Blockzeitstempel
der verknüpften
Freiliste erreicht. Alle Blöcke,
die älter
als eine vorgegebene Zeitdauer sind, werden automatisch gelöscht. Auf
diese Art weisen die verknüpften
Listen eine gute Kapazitätsmenge auf,
um neue Blöcke
aufzunehmen.
-
Während die
Rohereignisse durch den Controller 4 gesäubert werden,
werden Ereignisse, die einen schlechten Wert (alles andere als 0xC0)
in dem Qualitätsfeld
aufweisen, gekennzeichnet. Der Zweck hiervon ist, die Ausnahmedaten
in der Datenbank 5, wie unten beschrieben, zu speichern,
aber keinen Qualitätswert zu
speichern, wenn die Qualität
gut ist. Basierend darauf, dass die meisten Rohereignisse gute Qualitätsindikatoren
in dem Qualitätsfeld
aufweisen, verringert dieser Ansatz die Menge gespeicherter Daten.
-
Diese
Datenbankstruktur ist besonders effektiv. Das Elementobjekt speichert
Verweise auf die Objekte der unteren Ebene und so sind Abfragen,
um die zuletzt erfassten Objekte aufzurufen, einfach und schnell.
Die Tatsache, dass die niedrigstwertigen 32 Zeitbits in der Ereignisebene
gespeichert werden, optimiert den zusätzlichen Speicheraufwand und
verringert die Abfragezykluszeit. Diese unteren 32 Bits stellen
ein 71,5 Minutenfenster für
jeden Behälter 23 dar,
der verwendet wird, eine Stunde (gerundet) darzustellen.
-
Daten
abzufragen ist ein sehr effizienter Vorgang. Alle Abfragen sind
zeitbasiert. Da die meisten Abfragen auf neuen Daten beruhen, ist
der Startpunkt der Abfrage das aktuelle Jahresdatenfeld. Indem das
Startdatum für
die Abfrage verwendet wird, bohrt sich die Datenbankabstraktionsschicht 4 durch
das Schema, um nach dem angeforderten Ereignis zu suchen. Nachdem
dies durchgeführt
ist, kann der Client alle nachfolgenden Ereignisse eins nach dem
anderen abrufen, bis er alle gewünschten
Ereignisse abgerufen hat.
-
Die
Elementklasse beschreibt die Elemente, die für Knoten festgelegt sind. Daten
für Elemente
auf OPC-Servern verwenden den VARIANT-Datentyp und Daten für Elemente
auf DDE-Servern werden zu dem Typ umgewandelt, der auf Elementebene
festgelegt ist. Der Datentypaufzählung
eines Elements stimmt direkt mit den VARIANT-Datentypen überein,
werden jedoch unter Verwendung festgelegter Datentypen gespeichert. Ereignisdatenfelder,
das heißt
VARIANTen vom Typ VT_ARRAY, werden als einzelne Ereignisse mit demselben
Zeitstempel gespeichert.
-
Elemente
können
ebenso Alarmereignisstrukturen (variabler Größe) empfangen. Elemente besitzen nicht
festgelegte Platzhalter zum Speichern zusätzlicher Daten, ohne dass Schemaaktualisierungen
erforderlich sind. Dies ist als Verweis auf eine verknüpfte Liste
von Attributobjekten realisiert. Die Elementklasse enthält ebenfalls
Verweise auf das letzte JahresDatenfeld-, TagesDatenfeld-, EreignisBehälter-. AlarmEreignisBehälter- und
Anmerkungs-Objekt. Diese Verweise ermöglichen eine effiziente Platzierung
der Objekte, die eine Aktualisierung benötigen, wenn Daten in die Datenbank
eingefügt
werden.
-
Das
Folgende sind Datentypbeispiele.
-
-
JahresDatenfeld 21
-
Die
JahresDatenfeld-Klasse wird verwendet, um auf alle Ereignisobjekte,
die für
ein Element über
eine Zeitdauer eines Jahres aufgezeichnet wurden, über ein
Datenfeld von 366 Verweisen auf TagesDatenfeld-Objekte zuzugreifen.
Die Elementklasse 20 enthält einen Verweis auf sein erstes
JahresDatenfeld. Die JahresDatenfeld-Klasse enthält bidirektionale Verweise
auf das nächste
und vorhergehende JahresDatenfeld. Ein Verweis auf das erste JahresDatenfeld
wird in dem Elementobjekt gespeichert, um zu ermöglichen, durch alle JahresDatenfeld-Objekte für ein Element
zu iterieren.
-
Beziehungen
-
- – Nächstes/Vorhergehendes
Nächstes/Vorhergehendes
sind bidirektionale eins-zu-eins Verweise auf JahresDatenfeld-Objekte
zum Iterieren durch alle JahresDatenfelder für ein Element.
- – TagesDatenfeld
TagesDatenfeld
ist ein Datenfeld aus 366 Verweisen auf TagesDatenfeld-Objekte für jeden
Tag pro Element.
-
Attribute
-
- – Jahr
Das
Jahr-Attribut legt fest, welches Jahr das JahresDatenfeld darstellt.
-
TagesDatenfeld 22
-
Die
TagesDatenfeld-Klasse wird verwendet, um auf alle Ereignisobjekte,
die für
ein Element über
eine Zeitdauer eines Tages aufgezeichnet wurden, über ein
Datenfeld von 24 Verweisen auf die ersten von EreignisBehälter abgeleiteten
Objekte zuzugreifen, die zu Beginn jeder Stunde eines Tages erzeugt
werden. Bidirektionale Verweise auf das nächste und vorhergehende TagesDatenfeld
werden verwendet, um zu ermöglichen,
durch alle TagesDatenfeld-Objekte für ein Element zu iterieren.
Die TagesDatenfeld-Klasse enthält
ebenfalls Verweise auf das erste Anmerkungs- und AlarmEreignisBehälter-Objekt
für jeden
Tag. Diese Objekte könnten über das
Datenfeld der Verweise auf die von EreignisBehälter abgeleiteten Objekte referenziert
werden, das würde
jedoch bedeuten, dass für
jedes Element verschiedene Typen der von EreignisBehälter abgeleiteten
Objekte zusammen existieren könnten
und daher die Objekte überprüft werden
müssten,
um jedes Mal, wenn sie referenziert werden, zu sehen, von welchem
Typ sie sind. Es ist zu erwarten, dass Alarmereignisse und Anmerkungen
selten auftreten.
-
EreignisBehälter
-
Der
EreignisBehälter
ist eine Basisklasse, die in ihrer abgeleiteten Form ein eingebettetes
Ereignisobjektdatenfeld enthält.
Die Klasse enthält
bidirektionale Verweise auf den nächsten und vorhergehenden EreignisBehälter, um
eine effiziente Iteration durch alle Ereignisse für ein Element
zu ermöglichen.
Die Klasse enthält
ebenfalls einen Verweis auf eine verknüpfte Liste von AusnahmeQualität-Objekten
und ein DWORD zum Halten der oberen 32 Bits der Ereigniszeit-DATEIZEIT-Struktur, was den
erforderlichen Speicherplatz für
jedes Ereignis verringert. Die Größe jedes Ereignisobjekts wird
durch Speichern lediglich der unteren 32 Bits der DATEIZEIT auf
Ereignisebene minimiert, die oberen 32 Bits der DATEIZEIT werden
auf der EreignisBehälter-Ebene
gespeichert. Wenn jedoch die maximale Genauigkeit der DATEIZEIT-Struktur
verwendet wird, liefern die untere 32 Bits der DATEIZEIT einen Bereich
von 71,5 Minuten. Neue EreignisBehälter-Objekte sind erforderlich,
wenn dieser Bereich abläuft,
selbst wenn das aktuelle EreignisBehälter-Objekt nicht voll ist.
Da das Qualitätskennzeichen
für jedes
Ereignis nahezu immer dasselbe ist, das heißt OPC_QUALITY_GOOD (0xC0), wird
dieses nur auf Ausnahmebasis als eine verknüpfte Liste von AusnahmeQualität-Objekten
gespeichert, die von dem EreignisBehälter referenziert werden.
-
ZeichenkettenEreignisBehälter 23(a)
-
Der
ZeichenkettenEreignisBehälter
ist von der EreignisBehälter-Klasse
abgeleitet und erfordert eine spezielle Behandlung, da Zeichenketten
als ooV Arrays von Zeichen gespeichert werden. Die gewöhnliche
EreignisBehälter-Implementierung
verwendet ooV Arrays, um die Daten zu speichern, aber die Objektivität erlaubt
nicht, dass ooV Array innerhalb eines anderen ooV Arrays eingebettet
ist. Daher verwendet die ZeichenkettenEreignisBehälter-Implementierung
ein Datenfeld fester Größe. Das
Feste Datenfeld wird unter Verwendung einer FixedArray-Vorlagenklasse
realisiert, die identische Methoden denen eines ooV Array offen
legt. Dies erlaubt dem Vorlagecode, der Ereignisse in dem Datenbankmodul
bearbeitet, alle Ereignisdaten identisch zu behandeln.
-
Attribute
-
-
XXXXEreignisBehälter 23(a)
-
XXXXEreignisBehälter-Klassen
sind von der EreignisBehälter-Klasse
abgeleitet. Eine eigene XXXXEreignisBehälter-Klasse ist für jeden
nativen Objektdatentyp, wie in Tabelle 1 oben beschrieben, definiert.
Die XXXXEreignisse sind unter Verwendung von ooV Arrays in die XXXXEreignisBehälter-Objekte
eingebettet.
-
Attribute
-
-
BasisEreignis 23
-
Die
BasisEreignis-Klasse ist eine nicht beständige Klasse und sie ist die
Basisklasse für
die XXXXEreignis-Klassen.
-
Attribute
-
- – TimeLow
Das
TimeLow-Attribut beschreibt das untere DWORD der Ereigniszeit.
-
XXXXEreignis
-
Die
XXXXEreignis-Klassen sind nicht beständige Klassen, die die aktuellen
Ereignisdaten darstellen, sie sind von der BasisEreignis-Klasse
abgeleitet. Eigene XXXXEreignisBehälter-Klassen sind für jeden
nativen Objektdatentyp, wie in Tabelle 1 oben beschrieben, definiert.
-
Attribute
-
-
AusnahmeQualität 23(c)
-
Die
AusnahmeQualität-Klasse
stellt die Qualitätskennzeichnung
für Ereignisse
dar. Die Qualität
wird auf einer Ausnahmebasis gespeichert, wenn der Wert nicht OPC_QUALITY_GOOD
(0x00C0) entspricht. Jedes Objekt enthält eine Zwei-Byte Qualitätskennzeichnung
und einen Indexwert.
-
Beziehungen
-
- – Nächstes
Nächstes ist
ein Verweis auf das nächste
AusnahmeQualität-Objekt
in der verknüpften
Liste für
einen EreignisBehälter.
-
Attribute
-
- – ID
Das
ID-Attribut wird verwendet, AusnahmeQualität-Objekte mit Ereignisobjekten
in Beziehung zu setzen, die in einem Datenfeld in dem EreignisBehälter eingebettet
sind.
- – Wert
Wie
in der OPC-Datenzugriffsspezifikation beschrieben.
-
Es
ist zu verstehen, dass die Erfindung einen sehr schnellen Datenzugriff
auf Grund der hierarchischen Komprimierung gewährleistet, in der die Zeitzeichenketten-MSBs in der Struktur
kodiert sind, was den Bedarf an Indices vermeidet. Ebenso spart
diese Struktur ungefähr
6 Bytes Speicherplatz pro Ereignis. Dies wurde ohne Verlust der
Zeitpräzision
erreicht. Es wurde festgestellt, dass der Datenbankcontroller 4 eine Schreibleistung
von mehr als 300.000 Ereignissen pro Sekunde und eine Leseleistung
von mehr als 1 Million Ereignissen pro Sekunde erreicht.
