DE69712327T2

DE69712327T2 - Schnittstellensteuerungen für ein feldgeräte-managementsystem

Info

Publication number: DE69712327T2
Application number: DE69712327T
Authority: DE
Inventors: Robert Bruck; H. Olson; R. Sharpe; R. Tielens; Jon Westbrock
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 1996-02-06
Filing date: 1997-02-05
Publication date: 2002-11-21
Anticipated expiration: 2017-02-06
Also published as: EP0885412A1; DE69726764D1; JP4722885B2; JP2007328802A; JP4722890B2; JP4722886B2; JP2007317218A; JP4722889B2; JP2007328801A; DE69726763D1; DE69726764T2; JP4722887B2; JP2007317219A; WO1997029409A1; DE69726763T2; EP0885412B1; DE69712327D1; JP2000504865A; JP4260221B2; JP2008009996A

Description

TECHNISCHES GEBIET

Die vorliegende Erfindung betrifft allgemein die Datenbankverwaltung und speziell ein Datenbankverwaltungssystem.

HINTERGRUND DER ERFINDUNG

Typischerweise umfassen Prozeßanlagen (wie beispielsweise chemische Raffinerien und pharmazeutische Betriebe) viele Feldeinrichtungen, die Parameter innerhalb des Prozesses steuern und messen. Jede Feldeinrichtung kann eine Steuereinrichtung (wie etwa eine Durchflußventilsteuerung), eine Meßeinrichtung (wie etwa ein Temperaturmesser, ein Druckmesser, ein Durchflußmengenmesser usw.) und/oder jede andere Einrichtung sein, die einen mit einem Prozeß assoziierten Wert beeinflußt oder bestimmt. Bis etwa zur letzten Dekade waren Feldeinrichtungen typischerweise recht einfache Einrichtungen, die entweder manuell oder elektronisch gesteuert wurden und die Ausgangswerte entweder elektronisch oder an einem mit der Einrichtung verbundenen Meßgerät erzeugten. Diese Einrichtungen bieten jedoch typischerweise nur begrenzte Information für ein Steuerwerk, beispielsweise Analogsignale, die sich auf die Ablesewerte oder Messungen beziehen, die von diesen Einrichtungen vorgenommen werden.
Vor einiger Zeit sind sogenannte "intelligente" Feldeinrichtungen entwickelt worden. Intelligente Feldeinrichtungen können mit einem Prozeßsteuerwerk und/oder einem der Einrichtung zugeordneten Verwaltungssystem kommunizieren. Typische intelligente Feldeinrichtungen sind imstande, ein Analogsignal, das den der Einrichtung zugehörigen Wert wie beispielsweise einen Meßwert bezeichnet, zu übertragen und detaillierte, einrichtungsspezifische Information wie Kalibrier-, Konfigurations-, Diagnose-, Wartungs- und/oder Prozeßinformation zu speichern und auch digital zu übertragen. Manche intelligenten Einrichtungen können beispielsweise die Einheiten, in denen die Einrichtung mißt, die Maximalbereiche der Einrichtung, ob die Einrichtung korrekt arbeitet, Störungssuchinformation über die Einrichtung, wie und wann die Einrichtung zu kalibrieren ist, usw. speichern und übertragen. Ferner können intelligente Feldeinrichtungen imstande sein, selbst Operationen wie etwa Selbsttest- und Selbstkalibrierroutinen auszuführen. Beispielhafte intelligente Einrichtungen umfassen Einrichtungen, die dem HART-Protokoll (HART = Highway Addressable Remote Transducer) (HART-Einrichtungen), dem Fieldbus-Protokoll (Fieldbus-Einrichtungen), dem Modbus- Protokoll und dem DE-Protokoll folgen. Andere Protokolle für intelligente Einrichtungen können existieren oder in Zukunft entwickelt werden, um verschiedene Typen von intelligenten Einrichtungen zu unterstützen.
Derzeit ist jede herkömmliche und intelligente Einrichtung imstande, eine oder mehrere spezielle Eingangs- und/oder Ausgangsfunktionen in bezug auf einen Prozeß auszuführen. Eine Eingangsfunktion ist jede Funktion, die einen einem Prozeß zugeordneten Wert mißt oder liest, wie etwa die von einer Temperatur- oder Druckmeßeinrichtung ausgeführte Funktion. Eine Ausgangsfunktion ist jede Funktion, die innerhalb eines Prozesses etwas ändert, beispielsweise die Funktionen, die von einem Ventil- oder Durchflußsteuerelement ausgeführt werden. Ferner können manche intelligenten Einrichtung wie etwa Fieldbus- Einrichtungen Steuerfunktionen ausführen, die Funktionen sind, die der Steuerung eines Prozesses zugeordnet sind. Jede von einer Einrichtung ausgeführte Eingangs-, Ausgangs- und Steuerungs-Unterfunktion wird als ein "Block" bezeichnet. Definitionsgemäß weist daher jede Einrichtung mindestens einen und eventuell mehrere Blöcke auf. Fieldbus- Einrichtungen umfassen gewöhnlich eine Vielzahl von Blöcken (z. B. einen oder mehrere Eingangs-, Ausgangs- und Steuerblöcke), und HART-Einrichtungen umfassen zwar nicht Blöcke als solche, die Inhalte einer HART-Einrichtung werden jedoch vom Fachmann häufig als einen und nur einen Block darstellend konzipiert.
Jeder Block (oder "konzeptuelle" Block) und daher jede Einrichtung weist einen oder mehrere "Parameter" auf. Ein Parameter ist ein Attribut eines Blocks, das den Block charakterisiert, beeinflußt oder anderweitig irgendwie auf den Block bezogen ist. Parameter können beispielsweise die Art des Blocks, den maximalen Betriebs- oder Meßbereich eines Blocks, die Betriebsart eines Blocks, den Wert einer Blockmessung usw. umfassen.
Ebenso sind jedem Parameter eine oder mehrere Eigenschaften zugeordnet, und jede dieser Eigenschaften definiert oder beschreibt die Information innerhalb des Parameters. Beispielsweise hat der Temperaturparameter einer Temperaturmeßeinrichtung eine Kennungseigenschaft, die den Namen des Parameters (z. B. "Temperatur") speichert, eine Werteigenschaft, die den Wert des Parameters (z. B. die tatsächliche gemessene Temperatur) speichert, und eine Einheitseigenschaft, die die Einheiten speichert, in denen der Temperaturwert ausgedrückt wird (z. B. Grad C oder Grad F). Eine Einrichtungs- oder eine Blockkonfiguration weist eine Menge von Werten für jede der Eigenschaften jedes der Parameter auf, die einer Einrichtung oder einem Block zugeordnet sind.
Wie oben gesagt, werden intelligente Feldeinrichtungen entwickelt, damit die Kommunikation damit in einem von mehreren verfügbaren Protokollen (beispielsweise dem HART- und dem Fieldbus-Protokoll) ausgeführt werden kann. Diese Protokolle erlauben den Herstellern von Einrichtungen die Bereitstellung von einrichtungsspezifischen Informationsarten für eine Einrichtung, und natürlich sind die jeweiligen Informationsarten für jede Art von intelligenter Feldeinrichtung anders. Infolgedessen sind diese Protokolle komplex und für die Programmierung von Einrichtungen schwierig zu verwenden. Insbesondere bieten einige dieser Protokolle kein vollständig konsistentes Verfahren zur Kommunikation mit jeder daran angepaßten intelligenten Einrichtung. Statt dessen bieten diese Protokolle wie etwa das HART-Protokoll den Herstellern von Einrichtungen nur eine Möglichkeit anzugeben, welche Information von jeder intelligenten Feldeinrichtung verfügbar ist und wie diese Information abzurufen ist.
Die Kommunikation mit intelligenten Einrichtungen ist in gewissem Umfang durch Einrichtungsbeschreibungssprachen (DDL) und Einrichtungsbeschreibungsdienste (DDS) vereinfacht worden, die von den Herstellern von intelligenten Feldeinrichtungen bereitgestellt werden. Eine DDL ist eine menschenlesbare Sprache, die ein Protokoll zum Beschreiben der von einer intelligenten Einrichtung verfügbaren Daten, der Bedeutung der der intelligenten Einrichtung zugeordneten und davon abgerufenen Daten, der Methoden, die für die Implementierung der intelligenten Einrichtung verfügbar sind, des Formats zur Kommunikation mit der intelligenten Einrichtung zum Zweck des Erhalts von Daten, von Anwenderschnittstelleninformation über die Einrichtung wie etwa Bearbeitungsdisplays und Menüs und zur Handhabung oder Interpretation von anderer Information, die eine intelligente Einrichtung betrifft, bietet.
DDL-Quelldateien weisen menschenlesbaren Text auf, der von Einrichtungsentwicklern geschrieben wird. Diese Dateien bezeichnen die gesamte über eine Einrichtung verfügbare Information zwischen der Einrichtung und einem Bus oder einem Hauptrechner, mit dem die Einrichtung verbunden ist. Bei der Entwicklung einer DDL-Quelldatei für eine Einrichtung verwendet ein Entwickler die DDL-Sprache, um Kern- oder Grundparametercharakteristiken der Einrichtung zu beschreiben und um gruppenspezifische und herstellerspezifische Definitionen zu beschreiben, die sich auf jeden Block, jeden Parameter und jedes spezielle Feature einer intelligenten Einrichtung beziehen.
Eine DDL-Quelldatei wird in einem binären Format kompiliert, um eine maschinenlesbare Datei zu erzeugen, die als eine Einrichtungsbeschreibung bzw. DD bezeichnet wird und für einen Anwender durch den Hersteller der Einrichtung oder einen dritten Entwickler bereitgestellt wird, um in einem Hauptrechner wie etwa einem Verwaltungssystem gespeichert zu werden. In manchen Fällen wie beispielsweise in Fieldbus- Einrichtungen können DDL-Quelldateien in einer intelligenten Einrichtung gespeichert und von der intelligenten Einrichtung zu einem Hauptrechner übertragen werden. Wenn der Hauptrechner eine DD-Objektdatei für eine intelligente Einrichtung empfängt, kann er die Einrichtungsbeschreibung decodieren und interpretieren, um eine vollständige Beschreibung der Schnittstelle mit der Einrichtung zu gewinnen.
DDS ist ein allgemeines Softwaresystem, das von Fisher- Rosemount Systems, Inc. und/oder Rosemount, Inc. entwickelt und bereitgestellt wird, um die Einrichtungsbeschreibungen von intelligenten Einrichtungen automatisch zu decodieren und zu interpretieren. Insbesondere ist DDS eine Bibliothek von Routinen, die, wenn sie von einem Hauptrechner aufgerufen wird, die Einrichtungsbeschreibung einer intelligenten Einrichtung interpretiert, um dem Hauptrechner Information in bezug auf die intelligente Einrichtung zu liefern, die Information umfaßt, die sich bezieht auf: (1) das Einrichten und die Konfiguration der intelligenten Einrichtung; (2) die Kommunikation mit der intelligenten Einrichtung; (3) Anwenderschnittstellen; und (4) Methoden, die zum Gebrauch in Verbindung mit der intelligenten Einrichtung verfügbar sind. Eine außerordentlich nützliche Anwendung von DDS ist die Bereitstellung einer gleichbleibenden Schnittstelle zwischen einem Hauptrechner und einer oder mehreren intelligenten Einrichtungen, die zugehörige DDL-Quelldateien (und entsprechende DD- Objektdateien) haben.
DDS, DDL und DD sind zwar auf dem Gebiet allgemein bekannt, aber mehr Informationen hinsichtlich der speziellen Funktion und des Formats von DDL und insbesondere Fieldbus-DDL findet man in dem Handbuch von InterOperable Systems Project Foundation mit dem Titel "InterOperable Systems Project Fieldbus Specification Device Description Language" (1993), das hier summarisch eingeführt wird. Ein gleichartiges Dokument, das die HART-DDL betrifft, gibt es von der HART Foundation.
Ein Verwaltungssystem ist ein System, das mit einer oder mehreren intelligenten Feldeinrichtungen in Dialog tritt, um jede von der Einrichtungs-, Block-, Parameter-, Variablen- oder Konfigurationsinformation, die diesen Einrichtungen zugeordnet ist, zu lesen. Typischerweise weist ein Verwaltungssystem einen Personalcomputer mit entsprechenden Kommunikationsports auf, die es ihm erlauben, mit einer intelligenten Einrichtung verbunden zu werden, damit zu kommunizieren und sie zu rekonfigurieren. Verwaltungsysteme können Online-Verwaltungssysteme sein, d. h. eine festverdrahtete oder andere permanente Verbindung mit einer intelligenten Einrichtung haben, sie können tragbare Systeme sein und sie können imstande sein, periodisch mit einer intelligenten Einrichtung verbunden zu werden, um diese intelligente Einrichtung zu rekonfigurieren.
Verwaltungssysteme führen typischerweise viele verschiedene Funktionen in bezug auf intelligente Einrichtungen innerhalb eines Systems aus. Beispielsweise können Verwaltungssysteme dazu dienen, Anwendern Information (z. B. Werte von Variablen oder Parametern) zu liefern, die den Zustand eines Prozesses betreffen und die sich auf jede der intelligenten Einrichtungen beziehen, die mit dem Prozeß assoziiert oder damit verbunden sind. Verwaltungssysteme können auch dazu dienen, einem Anwender die Überwachung eines Prozesses und die Steuerung des Prozesses durch Rekonfigurieren von intelligenten Einrichtungen innerhalb des Prozesses nach Bedarf durchzuführen.
Die Softwareroutinen, die angewandt werden, um Funktionen innerhalb eines Verwaltungssystems auszuführen, das durch das System gebotene Features verwendet, werden typischerweise als Anwendungen bezeichnet. Typischerweise implementieren Verwaltungssysteme Anwendungen, die von einzelnen Herstellern von intelligenten Einrichtungen bereitgestellt werden, um Änderungen an einer intelligenten Einrichtung zu implementieren und Daten davon zu lesen. Infolgedessen haben verschiedene Anwendungen innerhalb eines Verwaltungssystems häufig keine gemeinsame oder gleichbleibende Schnittstelle, und der Übergang von einer Anwendung zu einer anderen ist daher umständlich und zeitaufwendig, Außerdem sind Konfigurationsdaten von intelligenten Einrichtungen, Konfigurationsprotokolle und Diagnosedaten von intelligenten Einrichtungen, die von verschiedenen Anwendungen erzeugt und gespeichert werden, dezentral und können nicht mit Querverweisen versehen werden, weil diese Daten in diversen Formaten, in verschiedenen Datenbanken und manchmal in herstellereigenen Formaten gespeichert sein können. Infolgedessen müssen Aufgaben, die innerhalb eines Systems für jede Einrichtung gemeinsam sein könnten, in separaten Anwendungen dupliziert werden.
Ein Verwaltungssystem, das solche separat entwickelten. Anwendungen implementiert, hat typischerweise keine Möglichkeit, Information, die sich auf sämtliche intelligenten Einrichtungen in einer Anlage oder einem Prozeß bezieht, gleichzeitig zu betrachten, weil die Anwendungen für jede Einrichtung separat ablaufen müssen. Außerdem ist es für Anwender schwierig, Anwendungen zu schreiben, die eine umfassende Betrachtung von Daten ermöglichen, die sich auf eine Vielzahl von unterschiedlichen Einrichtungen in einem Prozeß beziehen, weil Anwender typischerweise mit DDS oder mit der DDL und DD, die jeder der Einrichtungen innerhalb eines Prozesses zugeordnet sind, nicht sonderlich vertraut sind. Aber auch wenn ein Anwender eine solche Kenntnisse hat, sind derartige Anwendungen in der Entwicklung zeitaufwendig und teuer und müssen jedesmal, wenn eine neue intelligente Einrichtung dem System hinzugefügt wird, aktualisiert werden.
Der Bedarf für ein integriertes Verwaltungssystem ist besonders groß bei Prozessen oder Systemen, die von Regierungsstellen wie etwa der EPA und der FDA zertifiziert werden müssen, die beispielsweise bestimmte chemische und pharmazeutische Prozesse regulieren, um sicherzustellen, daß die mit solchen Prozessen hergestellten Produkte strengen Standards genügen, daß Emissionen unter einem vorbestimmten Wert bleiben und daß Sicherheitsvorkehrungen beachtet werden. Die einfachste Möglichkeit zur Aufrechterhaltung der Zertifizierung einer Anlage, die einen regulierten Prozeß implementiert, besteht darin, hinreichend genaue Aufzeichnungen zu unterhalten, die den Regierungsauditoren beweisen, daß die Werte von kritischen Prozeßparametern auf bestimmten Werten oder innerhalb bestimmter Bereiche geblieben sind, die mit den Regulierungsanforderungen von interessierten Regierungsstellen und mit den Sicherheitsverfahren in Übereinstimmung sind. Ein integriertes Verwaltungssystem, das mit den intelligenten Einrichtungen eines Prozesses gekoppelt ist, kann dazu verwendet werden, diese Werte automatisch in einer Datenbank aufzuzeichnen. Danach können die in der Datenbank des integrierten Verwaltungssystems gespeicherten Daten dazu verwendet werden zu beweisen, daß diese kritischen Werte innerhalb der jeweils geforderten Bereiche geblieben sind.
Wenn bisher ein Verwaltungssystem den Zustand einer Feldeinrichtung in dem Steuerungssystem geändert hat (d. h. wenn es eine Information in der Feldeinrichtung geändert hat), hat das Verwaltungssystem in einer internen "Zustandsdatenbank" für die Einrichtung einen kompletten neuen oder aktuellen "Zustand" gespeichert. Der "Zustand" einer Einrichtung umfaßt (1) eine Angabe der Zeit, zu der die Änderung gemacht wurde (d. h. wann die Einrichtung in den neuen Zustand gebracht wurde), und (2) Daten, die der gesamten in der Einrichtung gespeicherten Information entsprechen. Die Zustandsdatenbanken von bekannten Verwaltungssystemen können auch zusätzliche Information gemeinsam mit den Zuständen von Einrichtungen enthalten haben (z. B. Information darüber, wer die Änderungen an Einrichtungszuständen gemacht hat oder warum usw.).
Die Unterhaltung einer Zustandsdatenbank auf diese Weise und die Speicherung einer vollständigen Menge von Variablen, die einem neuen Zustand entsprechen, jedesmal dann, wenn an einer Feldeinrichtung in dem Steuersystem eine Änderung vorgenommen wird, erfordert einen erheblichen Aufwand an Speicher- und Verarbeitungszeit. Ferner ist eine Vielzahl von Online-Verwaltungssystemen typischerweise miteinander verbunden, und Daten von jedem System werden kombiniert unter Bildung einer kombinierten historischen Datenbank, die den Zustand des gesamten Steuerungssystems widerspiegelt. Die Anwesenheit einer Angabe in den Aufzeichnungen der Vielzahl von miteinander verbundenen Zustandsdatenbanken über die jedem neuen Zustand entsprechende Zeit erlaubt es zwar, die Vielzahl von Datenbanken miteinander in Einklang zu bringen, um eine solche kombinierte historische Datenbank zu entwickeln, sie überwindet jedoch nicht die wohlbekannte Unfähigkeit von bekannten Verwaltungssystemen, direkt mit mobilen Kommunikatoren in Dialog zu treten und dann Daten, die von mobilen Kommunikatoren zu dem Verwaltungssystem übertragen wurden, auf abgestimmte Weise in die Datenbank des Verwaltungssystems einzubringen. Der Grund ist, daß heutige mobile Kommunikatoren, die ganz einfache Instrumente sind, keine internen Echtzeituhren haben und daher auf die Zustandsaufzeichnungen, die die mobilen Kommunikatoren zu dem Verwaltungssystem rückführen, keinen Zeitstempel aufbringen können. Infolgedessen kann das Verwaltungssystem den speziellen. Punkt in der chronologischen historischen Datenbank nicht bestimmen, an dem eine Aufzeichnung eines gegebenen neuen Zustands von dem mobilen Kommunikator einzufügen ist, um diesen neuen Zustand in Abstimmung mit der vorhandenen chronologischen Datenbank zu bringen.
Integrierte Verwaltungssysteme können auch verwendet werden, um intelligente Einrichtungen regelmäßiger zu rekonfigurieren, so daß die Zertifizierbarkeit des Prozesses, in dem die Einrichtungen verwendet werden, erhalten bleibt. Derzeit enthalten die meisten Verwaltungssysteme, die mehr als eine intelligente Feldeinrichtung unterstützen, ganz spezielle Software, die für jede unterstützte intelligente Einrichtung geschrieben ist, um eine Kommunikation mit dieser intelligenten Einrichtung zu ermöglichen. Das Hinzufügen einer neuen intelligenten Einrichtung zu einem Prozeß verlangt daher, daß das Verwaltungssystem für diesen Prozeß neu programmiert wird. Diese Programmierung ist ebenfalls zeitaufwendig und kann teuer sein, weil sie von einer Person durchgeführt werden muß, die nicht nur Wissen über die Software des Verwaltungssystems hat, sondern sich auch in dem Protokoll der intelligenten Einrichtung und der neuen intelligenten Einrichtung gut auskennt.
Es gibt zwar mobile Kommunikatoren, die mit verschiedenen intelligenten Einrichtungen entsprechend einem bestimmten Protokoll in Dialog treten können, diese Einrichtungen lesen und schreiben jedoch nur Daten aus der und in die Einrichtung und sind nicht imstande, diese Daten auf irgendeine signifikante Weise zu verarbeiten.
Ein weiterer aufwendiger Aspekt der Anwendungsentwicklung ist die Programmierung einer Anwendung zur Durchführung der zahlreichen Aufgaben, die sich auf die Kommunikation zwischen einem Anwender und jeder intelligenten Einrichtung innerhalb eines Systems beziehen und dafür erforderlich sind. Ein Entwickler muß nicht nur auf die Einzelheiten achten, wie mit jeder separaten Einrichtung übermittelt wird, sondern dieser Entwickler muß auch speziell darauf achten, wie Information einem Anwender beispielsweise über ein Display präsentiert wird. Diese Aufgabe wird erschwert, weil typische Anwendungen keine gleichbleibenden Anwenderschnittstellen-Protokolle verwenden. Jede dieser Funktionen erfordert viel Programmierzeit und -aufwand, der jedesmal wiederholt werden muß, wenn dem System eine neue intelligente Einrichtung hinzugefügt wird.
Ferner ermöglichen Anwendungen einem Anwender typischerweise die Betrachtung einer aktuellen Konfiguration einer Einrichtung, eines Blocks oder eines Parameters innerhalb eines Prozesses, aber diese Anwendungen erlauben dem Anwender nicht die Betrachtung von vergangenen Konfigurationen oder die gleichzeitige Anzeige einer Vielzahl von Konfigurationen zum Vergleich miteinander.
WO 9526527 zeigt ein Systemsteuerwerk, das imstande ist, mit einer Reihe von verschiedenen zusätzlichen Druckeinrichtungen, die dem Drucksystem zugeordnet sind, in Dialog zu treten.
FR-A-2 692 701 zeigt ein System, das eine Prüfung ausführt, um zu bestimmen, ob einem System zugeordnete Einrichtungen, wie sie ursprünglich konfiguriert wurden, durch kompatible oder nichtkompatible Einrichtungen ersetzt worden sind, indem Codes, die jeder der Austauscheinrichtungen zugeordnet sind, mit einer Menge von Kompatibilitätscodes verglichen werden.
US-PS 4 586 151 zeigt eine separate Ein-/Ausgangsroutine, die für jede von verschiedenen Einrichtungen vorgesehen ist, um die Kommunikation mit dieser Einrichtung zu ermöglichen. Die Ein-/Ausgangsmodule sind in jeder der verschiedenen Einrichtungen vorhanden, und daher wird für jede der verschiedenen Einrichtungen ein separates Modul benötigt.

ZUSAMMENFASSUNG DER ERFINDUNG

Gemäß einem Aspekt der vorliegenden Erfindung wird ein computerbasiertes Datenbankverwaltungssystem angegeben zur Verwaltung einer Konfigurationsdatenbank, die einer von einer Vielzahl von Feldeinrichtungen zugeordnet ist, von denen jede eine änderbare Konfiguration hat, die mindestens einen einstellbaren Parameter aufweist. Das System weist folgendes auf: eine Initialisierungseinrichtung zum Einstellen des einstellbaren Parameters auf einen ersten Wert zu einem ersten Zeitpunkt, eine Aktualisierungseinrichtung zum Einstellen des einstellbaren Parameters auf einen zweiten Wert zu einem zweiten Zeitpunkt, und einen Transaktionsspeicher, der auf die Initialisierungseinrichtung und die Aktualisierungseiririchtung anspricht, um eine Vielzahl von Transaktionen zu speichern. Jede Transaktion umfaßt einen bestimmten Wert eines bestimmten einstellbaren Parameters und einen entsprechenden Zeitpunkt, zu dem der bestimmte einstellbare Parameter den bestimmten Wert erreicht.
Gemäß einem anderen Aspekt der vorliegenden Erfindung wird ein computerbasiertes Datenbankverwaltungssystem angegeben zur Verwaltung einer Konfigurationsdatenbank, die einer von einer Vielzahl von Einrichtungen zugeordnet ist, von denen jede eine variable Konfiguration mit mindestens einem einstellbaren Parameter hat. Das System weist auf: eine erste Wähleinrichtung zum Wählen einer bestimmten Einrichtung, eine zweite Wähleinrichtung zum Wählen eines bestimmten Parameters der bestimmten Einrichtung, eine Zuordnungseinrichtung zum Zuordnen eines bestimmten Werts für den bestimmten Parameter zu einem bestimmten Zeitpunkt, eine mit der Zuordnungseinrichtung gekoppelte Einrichtung zum Übertragen des bestimmten Werts für den bestimmten Parameter zu der bestimmten Einrichtung zu dem bestimmten Zeitpunkt, und eine Aufzeichnungseinrichtung zum Erzeugen einer Transaktionsaufzeichnung. Die Transaktionsaufzeichnung umfaßt einen Kennzeichner, der die bestimmte Einrichtung eindeutig kennzeichnet, und bezeichnet ferner den bestimmten Parameter der bestimmten Einrichtung, den bestimmten Wert für den bestimmten Parameter, und den bestimmten Zeitpunkt, zu dem der bestimmte Wert dem bestimmten Parameter zuzuführen ist. Das System weist ferner eine Einrichtung zur Speicherung der Transaktionsaufzeichnung in einer Konfigurationsdatenbank auf.
Die vorliegende Erfindung ist in den Ansprüchen 1 bis 30 definiert und betrifft eine Schnittstellensteuerung, die zum Gebrauch mit einem Verwaltungssystem ausgebildet ist, das folgendes hat: eine Benutzeroberfläche, eine Datenbank und ein Kommunikationsnetz, das mit der Datenbank kommuniziert, eine Feldeinrichtung und eine Einrichtungsbeschreibung, die der Feldeinrichtung zugeordnet ist. Die Feldeinrichtung, die Einrichtungsbeschreibung und die Datenbank speichern eine Vielzahl von Gruppen von logisch miteinander in Beziehung stehenden Elementen von Einrichtungsdaten. Die Schnittstellensteuerung weist folgendes auf: Einrichtungen zum Implementieren einer bestimmten Schnittstellensteuerung für eine bezeichnete Gruppe der Vielzahl von Gruppen von logisch miteinander in Beziehung stehenden Elementen von Einrichtungsdaten, die aufweist: eine Einrichtung, die das Kommunikationsnetz anweist, die Elemente von Einrichtungsdaten, die der bezeichneten Gruppe zugeordnet sind, aus wenigstens einer von der Feldeinrichtung, der Einrichtungsbeschreibung und der Datenbank zu lesen, um eine Menge von Elementen von abgerufenen Einrichtungsdaten für die bezeichnete Gruppe zu erzeugen; eine Einrichtung zur Anzeige der Menge von Elementen von abgerufenen Einrichtungsdaten für die bezeichnete Gruppe über die Benutzeroberfläche in einem vordefinierten Format; eine Einrichtung zum Identifizieren einer der Vielzahl von Gruppen von logisch miteinander in Beziehung stehenden Elementen von Einrichtungsdaten als die bezeichnete Gruppe, und eine auf die Identifizierungseinrichtung ansprechende Einrichtung, die die Implementierungseinrichtungen auffordert, die bestimmte Schnittstellensteuerung für die bezeichnete Gruppe zu schaffen.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein Blockbild, das die Verbindungen zwischen einem Prozeß, einem digitalen Steuerungssystem und einem Verwaltungssystem zeigt;
Fig. 2 ist ein Blockbild des Verwaltungssteuerungssystems von Fig. 1, das eine Einrichtungskommunikationsschnittstelle und Steuereinrichtungen hat, die gemäß der vorliegenden Erfindung wirksam sind;
Fig. 3 ist eine obere Hierarchie von Objektinformation gemäß der vorliegenden Erfindung;
Fig. 4 ist eine niedere Hierarchie von Objektinformation gemäß der vorliegenden Erfindung;
Fig. 5 ist ein Schema der FMS-Datenbank von Fig. 2, wobei eine darin vorhandene Transaktionsdatenbank gezeigt ist;
Fig. 6 ist ein Schema einer Aufzeichnung der Transaktionsdatenbank von Fig. 5;
Fig. 7 bis 10 sind Flußdiagramme, die die Programmierung für ein Transaktionsdatenbank- Verwaltungssystem und ein -verfahren gemäß der vorliegenden Erfindung zeigen;
Fig. 11 zeigt den Steuerblock von Fig. 2;
Fig. 12 ist ein Flußdiagramm, das die Initialisierungsschritte zeigt, die einer gemäß der vorliegenden Erfindung aufgebauten Steuerung zugeordnet sind;
Fig. 13 bis 19 sind Flußdiagramme, die die Operation einer Steuerung gemäß der vorliegenden Erfindung zeigen;
Fig. 20 ist eine Bildschirmanzeige, die von einer Menge von Einrichtungssteuerungen gemäß der vorliegenden Erfindung erzeugt werden kann;
Fig. 21 ist eine Bildschirmanzeige, die von einer Menge von Parametersteuerungen gemäß der vorliegenden Erfindung erzeugt werden kann;
Fig. 22 ist eine Bildschirmanzeige, die von einer Menge von Blocksteuerungen gemäß der vorliegenden Erfindung erzeugt werden kann;
Fig. 23 ist eine Bildschirmanzeige, die von einer Menge von Zeitplan- und Parametersteuerungen gemäß der vorliegenden Erfindung erzeugt werden kann; und
Fig. 24 ist ein Flußdiagramm, das die Programmierung zur Rekonstruktion eines erwarteten Einrichtungszustands von der Transaktionsdatenbank von Fig. 5 zeigt.

GENAUE BESCHREIBUNG

Fig. 1 zeigt ein Verwaltungssystem 10, das nachstehend als ein System für Feldverwaltungslösungen bzw. FMS-System bezeichnet wird und das mit einem Prozeß 12, einem digitalen Steuerungssystem bzw. DCS 14, das den Prozeß 12 steuert, und einem weiterer. Verwaltungssystem wie etwa einem weiteren FMS-System 15 verbunden ist.
Der Prozeß 12 kann jede gewünschte Art von Prozeß wie etwa einen Fertigungsprozeß oder einen Raffinationsprozeß usw. aufweisen und ist so dargestellt, daß er vier intelligente Feldeinrichtungen, und zwar drei HART-Einrichtungen 16, 18 und 20 und eine Fieldbus-Einrichtung 22, und eine herkömmliche (d. h. nichtintelligente) Einrichtung 24 aufweist. Die Einrichtungen 16, 18, 20, 22 und 24 werden auf jede gewünschte Weise von dem digitalen Steuerungssystem 14 gesteuert.
Im allgemeinen ist das FMS-System 10 ein PC-basiertes Softwarewerkzeug, das Anwendungen aufweist, die Feldeinrichtungs-Verwaltungsaufgaben ausführen. Das FMS- System 10 integriert die Einrichtungsverwaltung für jede der Einrichtungen innerhalb des Prozesses 12, indem es Anwendern dabei hilft, beispielsweise sämtliche der intelligenten Feldeinrichtungen, die dem Prozeß 12 zugeordnet sind, zu konfigurieren, zu kalibrieren, zu überwachen und die Störungssuche durchzuführen.
Das FMS-System 10, das jede Art von computer- oder mikroprozessorbasiertem System aufweisen kann, kann ein Display 30, einen Drucker 31, eine Tastatur 32 und eine Maus 34 aufweisen, die mit einem Betriebssystem und einer CPU 36 verbunden sind. Ein Speicher 38, der eine FMS-Datenbank 30 hat, ist mit dem Betriebssystem und der CPU 36 gekoppelt. Der Speicher 38, der die FMS-Datenbank 40 aufweist, speichert Software und Daten, die von dem FMS-System 10 bei der Durchführung von Aufgaben genutzt werden, die das Anzeigen von Information für einen Anwender über das Display 30 oder den Drucker 31 und die Kommunikation mit den intelligenten Einrichtungen 16, 18, 20 und 22 betreffen. Außerdem speichert die FMS-Datenbank 40 einrichtungsbezogene Information, die von den intelligenten Einrichtung nicht verfügbar ist, beispielsweise Information hinsichtlich früherer Konfigurationen der Einrichtungen, Information in bezug auf Offline-Einrichtungen wie etwa intelligente und herkömmliche Offline-Einrichtungen, und Information in bezug auf Wartungsmitteilungen einschließlich Information, wann die nächste Wartung benötigt wird; wer Wartungsvorgänge durchgeführt hat; alle etwaigen bevorzugten Austauscheinrichtungen usw. Daten, die intelligente Offline- Einrichtungen betreffen, können in der Datenbank 40 in einem Format gespeichert sein, das mit dem Format identisch ist, mit dem diese Daten tatsächlich innerhalb der Offline- Einrichtungen gespeichert sind, so daß für das FMS-System 10 Offline-Einrichtungen als durch die Datenbank 40 auf die gleiche Weise verfügbar erscheinen, wie sie verfügbar wären, wenn diese Einrichtungen online wären.
Die intelligenten Einrichtungen 16, 18 sind Online- Einrichtungen, die mit dem FMS-System über eine Kommunikationsleitung 42 und ein Modem 44 verbunden sind. Die intelligente Einrichtung 22 ist eine Online-Einrichtung, die mit dem FMS-System über eine Fieldbus-Schnittstelle 45 verbunden ist. Die intelligente Einrichtung 20 ist eine Offline-Einrichtung, die nicht dauerhaft mit dem FMS-System 10 verbunden ist. Die intelligente Einrichtung 20 kann jedoch mit dem FMS-System 10 über einen mobilen Kommunikator und/oder ein sekundäres (Laptop-)FMS 46 kommunizieren, das, wie noch im einzelnen beschrieben wird, periodisch mit der Einrichtung 20 und/oder jeder der anderen intelligenten Einrichtungen verbunden werden kann, um Daten von der Einrichtung 20 und/oder den anderen intelligenten Einrichtungen zu lesen und Daten an sie zu schreiben. Danach kann der mobile Kommunikator und/oder das sekundäre FMS 46 mit dem FMS-System 10 verbunden werden, um Daten, die die intelligente Einrichtung 20 und/oder irgendwelche anderen intelligenten Einrichtungen betreffen, an denen es angebracht war, hochzuladen und diese Daten in der FMS- Datenbank 40 zu speichern.
Falls gewünscht, kann das Betriebssystem und die CPU 36 des FMS-Systems beispielsweise durch eine Ethernet- Kommunikationsverbindung 48 und/oder eine andere Netzverbindung mit dem digitalen Steuerungssystem und anderen FMS-Systemen, beispielsweise dem anderen FMS-System 15, verbunden werden.
Fig. 2 zeigt die Verbindungen zwischen verschiedenen. Bestandteilen des FMS-Systems 10 einschließlich Hardware- und Softwarekomponenten und dient dem Zweck zu beschreiben, wie die verschiedenen in dem Speicher 38 des FMS-Systems 10 gespeicherten Softwarekomponenten miteinander, mit dem Display 30, dem Drucket 31, der Tastatur 32, der Maus 34, der FMS-Datenbank 40 und den intelligenten Einrichtungen innerhalb des Prozesses 12 in Dialog treten. Es versteht sich, daß die Softwarekomponenten des FMS-Systems 10 in dem Speicher 38 gespeichert sind und auf dem Betriebssystem und der CPU 36 laufen.
Das FMS-System 10 arbeitet bevorzugt in einer Microsoft Windows Umgebung (etwa einer Windows 95TM Umgebung) und weist daher ein Standard-Windowsbetriebssystem 46 auf, das dazu dient, Daten und Information auf dem Display 30 und dem Drucker 31 anzuzeigen und Daten und Information von der Tastatur 32 und der Maus 34 abzurufen. Information, die dem Windowsbetriebssystem 46 zugeführt oder davon abgerufen wird, wird daher bevorzugt in einem Standard-Windows- Aufrufformat jeder gewünschten Art bereitgestellt, wie der Fachmann weiß. Das FMS-System 10 könnte jedoch gemäß der vorliegenden Erfindung unter Anwendung jedes anderen gewünschten Windows-basierten oder Nicht-Windows-basierten Schnittstellenformats (mit einer graphischen Benutzeroberfläche oder auch nicht) einschließlich beispielsweise MacIntosh-, Xwindows- oder IBM-DOS-Formaten implementiert werden.
Das FMS-System 10 umfaßt eine Menge von Anwendungen 50, die Kernanwendungen 52 und Zusatzanwendungen 54 aufweisen. Die Kernanwendungen 52 sind im wesentlichen Programme, die von dem FMS-Systemprovider geschrieben werden, um vorbestimmte und häufig verwendete Operationen auszuführen. Die Zusatzanwendungen sind Anwendungen, die von einem Anwender oder einem dritten Entwickler entwickelt und in das FMS- System 10 importiert werden, um kundenspezifische Funktionen auszuüben.
Nachstehend bezieht sich eine Anwendung auf jede Softwareroutine, die von dem FMS-System 10 implementiert wird und einem Anwender Information anzeigt, die den Prozeß 12 oder eine oder mehrere Einrichtungen, Blöcke, Parameter oder andere Information betrifft, die den Einrichtungen zugeordnet ist, die mit dem FMS-System 10 verbunden oder ihm zugeordnet sind, und/oder die es einem Anwender gestattet, eine oder mehrere der Einrichtungen, die dem FMS-System 10 zugeordnet oder damit verbunden sind, zu rekonfigurieren. Die von einer Anwendung benutzte Information ist typischerweise entweder in den intelligenten Einrichtungen innerhalb des Prozesses 12 gespeichert oder davon entwickelt oder ist in der FMS-Datenbank 40 gespeichert.
Beispielsweise kann das FMS-System 10 Kern- oder andere Anwendungen aufweisen, die es einem Anwender ermöglichen, mit den Daten innerhalb der FMS-Datenbank 40 und/oder den intelligenten Einrichtungen innerhalb des Prozesses 12 in Dialog zu treten, um den momentanen Zustand von einer oder mehreren der Einrichtungen in dem Prozeß 12 zu betrachten, die Konfiguration von einer oder mehreren der intelligenten Einrichtungen in dem Prozeß 12 zu ändern, eine Vielzahl von Einrichtungen gleichzeitig oder aufeinanderfolgend zu betrachten, gemeinsame Steuerungs- und Konfigurationsfunktionen von intelligenten Einrichtungen auszuführen, Browser zu aktivieren, die Einrichtungen an dem Netz zu lokalisieren, den Zustand von Einrichtungen zu überwachen und Alarmlisten zu erzeugen und Einrichtungskalibrier- und -testroutinen zu implementieren.
Andere typische Kernanwendungen können Konfigurationsanwendungen, Konfigurations-Verwaltungs- Anwendungen, Alarmabtastanwendungen, Anwendungen bezüglich eines Protokolls historischer Ereignisse, Berichtsanwendungen, Trendanalyseanwendungen und Diagnoseanwenctungen umfassen. Eine Konfigurationsanwendung zeigt die Werte der Variablen an, die einem oder mehreren Parametern einer Einrichtung in einem Prozeß zugeordnet sind, und erlaubt einem Anwender, entsprechende dieser Parameterwerte zu ändern. Eine Konfigurations-Verwaltungs- Anwendung erlaubt einem Anwender die Verwaltung der Konfiguration der Einrichtung insgesamt, beispielsweise das Rücksetzen einer Einrichtung, Initialisieren einer Einrichtung und Kalibrieren einer Einrichtung. Eine Alarmabtastanwendung prüft sämtliche der von dem FMS-System 10 bedienten Einrichtungen, um zu bestimmen, ob diese Einrichtungen korrekt arbeiten oder ob in einer der Einrichtungen ein Fehler aufgetreten ist. Eine Anwendung bezüglich eines Protokolls historischer Ereignisse erzeugt ein Ereignisprotokoll, das beispielsweise Anwender-Login- Information, mit Zeitstempel versehene Meldungen, die Änderungen bezeichnen, die an den Konfigurationen der von dem FMS-System 10 bedienten Einrichtungen vorgenommen wurden, Alarme, die mit den von dem FMS-System 10 bedienten Einrichtungen assoziiert sind, und andere Ereignisse angibt. Eine Berichtsanwendung erzeugt automatisch einen Bericht, der beispielsweise alle früheren, derzeitigen oder gewünschten zukünftigen Konfigurationen von einer oder mehreren Einrichtungen zeigt. Eine Trendanalyse- oder "Trendbildungs"-Anwendung zeichnet Daten auf, die von Einrichtungen innerhalb des Prozesses 12 gemessen wurden, um Trends zu erkennen, die innerhalb bestimmter Einrichtungen oder über einen Prozeß insgesamt auftreten können. Es ist ersichtlich, daß alle anderen gewünschten Anwendungen geschaffen und für das FMS-System 10 bereitgestellt werden können.
Im Betrieb des FMS-Systems 10 wählt ein Anwender eine oder mehrere der Anwendungen zur Ausführung aus. Die ausgewählte Anwendung ist in Fig. 2 als die aktuelle Anwendung oder Anwendungen 56 bezeichnet. Da das EMS-System 10 eine Vielzahl von Anwendungen gleichzeitig ausführen kann, kann es eine Vielzahl von aktuellen Anwendungen 56 geben. Jede aktuelle Anwendung 56 kann direkt mit dem Windows- Betriebssystem 46, einem Schnittstellenblock 58, einer digitalen Steuerungsschnittstelle bzw. DCI 60 und einer FMS- Datenbankschnittstelle 62 in Dialog treten. Falls gewünscht, kann die aktuelle Anwendung 56 auch mit einem ODBC-Block 64 (einem wohlbekannten Microsoft- Datenbankanwendungsschnittstellen(API)-System, das die Kommunikation mit nahezu sämtlichen Datenbanken ermöglicht) und einem Servernetz 65 in Dialog treten. Für viele Anwendungen sind jedoch solche Verbindungen weder erforderlich noch erwünscht. Außerdem kann jede aktuelle Anwendung 56 indirekt mit dem Windows-Betriebssystem 46, den intelligenten Einrichtungen innerhalb des Prozesses 12 und der Datenbank 40 über den Schnittstellenblock 58 in Dialog treten.
Der Schnittstellenblock 58 ist im wesentlichen ein Softwarepaket, das beispielsweise speziell konfigurierte Windows-Kundensteuerungen, OCX-Steuerungen oder VBX- Steuerungen hat, die automatisch Funktionen ausführen, die die Kommunikation von bestimmter, häufig benützter Information zwischen einer aktuellen Anwendung 56, den intelligenten Einrichtungen in dem Prozeß 12, der Datenbank 40 und einer Benutzeroberfläche 65, die das Windows- Betriebssystem 46, das Display 30, den Drucker 31, die Tastatur 32 und die Maus 34 aufweist, betreffen. Der Schnittstellenblock 58 kann von einer aktuellen Anwendung 56 genutzt werden, um diese Dialogfunktionen auszuführen, ohne daß der Anwendungs-Designer die Einzelheiten der dabei betroffenen Protokolle kennt. Infolgedessen ermöglicht der Schnittstellenblock 58 eine einfachere Konstruktion einer Anwendung und bietet eine gleichbleibende Benutzeroberfläche.
Aktuelle Anwendungen 56 und der Schnittstellenblock 58 treten bevorzugt mit den intelligenten Einrichtungen in dem Prozeß 12, anderen FMS-Systemen oder digitalen Steuerungssystemen und/oder der Datenbank 40 durch die DCI 60 und ein Servernetz 66, das die Server 68 und 70 aufweist, in Dialog und kommunizieren mit diesen. Typischerweise befindet sich zwar das Servernetz 66 in dem FMS-System 10 und ist diesem zugeordnet, aber die Strichlinie zwischen der DCI 60 und den Servern 68 und 70 in Fig. 2 zeigt, daß die DCI 60 auch zu Servernetzen anderer FMS-Systeme beispielsweise durch die in Fig. 1 gezeigte Ethernetverbindung Zugang haben kann.
Die DCI 60 ist im wesentlichen eine Komfortschicht, die eine Bibliothek von Routinen aufweist, die Funktionen ausführen, die erforderlich sind, um mit den dem Prozeß 12 und/oder anderen FMS-Systemen zugeordneten intelligenten Einrichtungen zu kommunizieren, Daten von diesen abzurufen, und andere Funktionen auszuführen, die die Datenbank 40 und die intelligenten Einrichtungen betreffen. Im Gebrauch wandelt die DCI 60 Befehle und Meldungen, die von der aktuellen Anwendung 56 und dem Schnittstellenblock 58 übermittelt werden, in ein Format um, das von dem Servernetz 66 erkannt und verwendet wird, und wandelt ebenso Daten, die von dem Servernetz 66 bereitgestellt werden, in ein Format um, das von der aktuellen Anwendung 56 und dem Schnittstellenblock 58 erkannt und verwendet wird.
Die DCI 60 kann zwar jedes gewünschte Protokoll verwenden, um diese Kommunikationsfunktionen auszuführen, bevorzugt verwendet die DCI 60 jedoch ein objektorientiertes Protokoll und am meisten bevorzugt ein Objektverknüpfungs- und -einbettungsprotokoll wie etwa das OLE-Protokoll, das von Microsoft Inc. entwickelt und dokumentiert wurde. Das MicroSoft OLE(2.0)-Protokoll wird in dem Betriebssystem Microsoft Windows 95TM verwendet und ist im Stand der Technik wohlbekannt.
Im allgemeinen ist ein objektorientiertes Protokoll ein Programmierparadigma, das die Welt als eine Sammlung von selbständigen Objekten darstellt, die durch das Senden von Nachrichten zusammenwirken. Objekte umfassen Daten (einen Zustand) und Methoden (Algorithmen), die an den Daten ausgeführt werden können. Außerdem stehen Objekte miteinander durch eine Schnittstellenverbindung in Beziehung und können mit anderen Objekten in der Hierarchie durch Nachrichten kommunizieren. Wenn ein Objekt eine Nachricht empfängt, reagiert es darauf durch Anwendung seiner eigenen Methoden, die für die Verarbeitung der Daten in diesem Objekt und das Senden von Nachrichten zu anderen Objekten zuständig sind, um bestimmte Aufgaben auszuführen und eventuell entsprechende Ergebnisse rückzuleiten.
Da die DCI 60 mit dem Servernetz 65 durch eine OLE- Hierarchie kommuniziert, verwendet die DCI Standard-OLE- Abläufe oder -Aufrufe, die das Lesen und Schreiben von Werten von OLE-Objekten, die Aufzählung einer Menge von aufgezählten Werten in einem OLE-Objekt, das Erhalten und Einstellen von Eigenschaften in OLE-Objekten, das Aufrufen und Implementieren von Methoden von OLE-Objekten und das Aufrufen von Eigenschaftsdaten, die in den OLE- Sammlungsobjekten gespeichert sind, in Verbindung mit OLE- Itemmethoden (einer speziellen Art von OLE-Methode) betreffen. Andere OLE-Abläufe können jedoch von der DCI 60 an OLE-Objekten implementiert werden, um mit dem Servernetz 66 zu kommunizieren.
Wie noch im einzelnen beschrieben wird, ist die spezielle OLE-Hierarchie, die von dem FMS-System 10 bevorzugt verwendet wird, eine OLE-Objekthierarchie, die entwickelt wurde, um sämtliche verschiedenen Arten von Information und die Beziehungen zwischen den verschiedenen Arten von Information, die für jede der verschiedenen DDL verfügbar sind oder davon verwendet werden, die jeder der Einrichtungsbeschreibungen bzw. DD zugeordnet sind, die ihrerseits den Einrichtungen in dem von dem FMS-System 10 bedienten Prozeß 12 zugeordnet sind, zu kategorisieren. Diese bestimmte Hierarchie definiert eine Menge von OLE- Objekten, von denen jedes eine bestimmte Menge von Eigenschaften gemäß der Definition durch die Hierarchie und eine bestimmte Menge von Methoden speichert, die dazu dienen können, die Eigenschaftsdaten zu manipulieren und mit anderen OLE-Objekten entsprechend den durch die Hierarchie definierten Beziehungen zu kommunizieren. Diese Hierarchie wird in Verbindung mit den Fig. 3 und 4 noch im einzelnen erörtert.
Im wesentlichen kommuniziert die DCI 60 mit dem Servernetz 66 so, als ob sämtliche OLE-Objekte, die für die bestimmte Hierarchie identifiziert sind, innerhalb des Speichers des Servernetzes 66 existieren. Die DCI 60 implementiert eine einfache Menge von Anrufen, die zur Kommunikation mit den OLE-Objekten in dem OLE-Protokoll erforderlich sind. Tatsächlich jedoch sind die Daten und Methoden jedes OLE- Objekts nicht wirklich in dem Speicher des Servernetzes 66 gespeichert oder angeordnet, bevor ein Anruf wie etwa ein Lese- oder Schreibanruf zu dem Servernetz 66 für ein solches OLE-Objekt beispielsweise von der DCI 60, den DDS 72, dem Kommunikationsnetz 74 der intelligenten Einrichtungen oder der FMS-Datenbankschnittstelle 80 gesendet wird. Zu diesem Zeitpunkt erkennt das Servernetz 66, daß die das OLE-Objekt betreffenden Daten und Methoden abgerufen und in dem Speicher gespeichert werden müssen, der einem der Server 68 oder 70 zugeordnet ist, und führt die Funktionen, die zum Abruf der Daten und Methoden dieses OLE-Objekts erforderlich sind, automatisch aus.
Wenn das Servernetz 66 einen Anruf betreffend das Lesen oder Schreiben von Daten oder Methoden innerhalb eines der in seinem Speicher befindlichen OLE-Objekte empfängt, leitet das Servernetz 66 die angeforderte Information zurück oder führt die angeforderte Funktion an den OLE-Objektdaten entsprechend seinen gespeicherten Routinen aus, so daß es Daten von dem OLE-Objekt, dem DDS 72, den intelligenten Einrichtungen in dem Prozeß 12 und der FMS-Datenbank 40 liest und Daten zu diesen schreibt.
Ebenso erkennt oder empfängt die DCI 60 Änderungen in OLE- Objekten, die in dem dem Servernetz 66 zugeordneten Speicher gespeichert sind, und führt darauf basierende Funktionen aus, um die Kommunikation mit der aktuellen Anwendung 56 und dem Schnittstellenblock 58 zu implementieren. Das Servernetz 66 tritt mit den OLE-Objekten in der bestimmten OLE- Hierarchie in Dialog und weist einen Einrichtungsserver 68 und einen Datenbankserver 70 auf. Der Einrichtungsserver 68 ist im wesentlichen eine Menge von Softwareroutinen, die eine bestimmte Übereinstimmung mit der Menge von OLE- Objekten in der bestimmten OLE-Hierarchie haben. Diese Routinen sind speziell dazu entwickelt, mit einem DDS 72, einer Kommunikationsschnittstelle 74 einer intelligenten Einrichtung und den OLE-Objekten der definierten Hierarchie zu kommunizieren. Diese Routinen können beispielsweise bestimmte Arten von Daten und Information übertragen, abrufen und ändern, die in den intelligenten Einrichtungen in dem Prozeß 12 gespeichert oder von diesen und/oder von Einrichtungsbeschreibungen (die Dateien sind) verfügbar sind, die den intelligenten Einrichtungen in dem Prozeß 12 zugeordnet sind. Ebenso ist der Datenbankserver 70 im wesentlichen eine Menge von Softwareroutinen, die den OLE- Objekten in der bestimmten OLE-Hierarchie zugeordnet sind. Diese Routinen kommunizieren mit dem DDS oder API 72 und/oder einer FMS-Datenbankschnittstelle 80, um beispielsweise bestimmte Arten von Daten und Information zu übertragen, abzurufen oder zu ändern, die in der FMS- Datenbank 40 gespeichert oder davon und/oder von den Einrichtungsbeschreibungen verfügbar sind, die den intelligenten Einrichtungen zugeordnet sind, für die Daten in der FMS-Datenbank 40 gespeichert sind. Wie Fig. 2 zeigt, sind die von dem DDS 72 benützten Einrichtungsbeschreibungen in einer Einrichtungsbeschreibungsbibliothek 76 gespeichert, die mit der DDS-Bibliothek 72 gekoppelt ist.
Die Routinen der Server 68 und 70 sind mit jedem der OLE- Objekte derart assoziiert, daß die Routinen, die die bestimmten Lesefunktionen ausführen, die zum Abruf der Daten von einem OLE-Objekt von dem DDS 72, von intelligenten Einrichtungen oder von der Datenbank 40 erforderlich sind, automatisch durch eine Anforderung für solche Daten von der DCI 60 implementiert werden. Ebenso sind die Routinen der Server 68 und 70 jedem der OLE-Objekte auf solche Weise zugeordnet, daß die Routinen, die die bestimmten Schreibfunktionen ausführen, die zum Ändern der Konfiguration von intelligenten Einrichtungen oder zum Speichern von Information in der Datenbank 40 erforderlich sind, automatisch von einer Anforderung zum Schreiben solcher Daten in dem OLE-Objekt implementiert werden.
Eine Anforderung, die von der DCI 60 gemacht wird, um die Werteigenschaft innerhalb eines OLE-Objekts, die Daten innerhalb oder in Verbindung mit einer intelligenten Einrichtung darstellt, zu schreiben, veranlaßt beispielsweise den Server 68, die Routine zu implementieren, die neue Eigenschaftswerte zu der intelligenten Einrichtung schreibt. Ebenso ruft eine Anforderung zum Lesen aus irgendwelchen Eigenschaftswerten eines OLE-Objekts, die in einer intelligenten Einrichtung gespeichert oder dieser zugeordnet sind, automatisch die Serverroutine auf, die die Eigenschaftswerte, die diesem OLE-Objekt zugeordnet sind, von dem DDS und/oder der intelligenten Einrichtung abruft und diese Eigenschaftswerte in dem Speicher (nicht gezeigt) speichert, der dem Server 68 als dem OLE-Objekt zugeordnet ist. Eine Anforderung, die beispielsweise von der DCI 60 gemacht wird, um die Eigenschaftswerte innerhalb eines OLE- Objekts, dem in der Datenbank 40 gespeicherte Daten zugeordnet sind, zu schreiben, implementiert ebenso automatisch die Routine des Servers 70, die neue Eigenschaftswerte an die Stellen innerhalb der Datenbank 40 schreibt, mit denen dieses OLE-Objekt assoziiert ist. Ebenso bewirkt eine Anforderung zum Lesen von Eigenschaftswerten von einem OLE-Objekt, daß der Server 70 die Daten, die diesem OLE-Objekt zugeordnet sind, von dem DDS und/oder dem Ort in der Datenbank 40, der diesen Eigenschaftswerten zugeordnet ist, abruft und diese Eigenschaftswerte in dem Speicher (nicht gezeigt) des Servers 70 als das OLE-Objekt speichert.
Diese Serverroutinen sind einfach, unkompliziert und für den Fachmann leicht zu schreiben und werden daher hier nicht angegeben. Wer OLE und DDL kennt, kann solche Routinen jedoch auf unkomplizierte Weise unter Anwendung jeder gewünschten Programmiersprache schreiben. Falls gewünscht, können die Routinen auf jede gewünschte Weise geschrieben oder optimiert werden, um so schnell wie möglich ausgeführt zu werden und dadurch die Arbeitsgeschwindigkeit der aktuellen Anwendung innerhalb des EMS-Systems 10 zu erhöhen.
Zum Abruf bestimmter Daten von einer der Online- Einrichtungen des Prozesses 12 oder von auf eine solche Einrichtung bezogenen Daten verlangt der Server 68 von dem DDS 72 die bestimmten Daten. Wenn diese Daten in der Einrichtungsbeschreibung für eine intelligente Einrichtung gespeichert sind, konsultiert der DDS 72 dann die Einrichtungsbeschreibung für die betroffene Einrichtung oder die Einrichtungsbeschreibung, die einem Block der betreffenden Einrichtung zugeordnet ist, und sendet die angeforderten Daten an den Server 68 zurück.
Wenn die speziellen Daten von der Einrichtungsbeschreibung verfügbar waren, speichert und hält der Server 68 diese Daten in dem OLE-Objekt, auf das die abgerufenen Daten bezogen sind. Wenn jedoch die angeforderten bestimmten Daten von der Einrichtungsbeschreibung für eine Einrichtung oder einen Block einer Einrichtung nicht verfügbar sind, aber statt dessen in der Online-Einrichtung gespeichert sind, sendet der Server 68 einen Befehl an die Kommunikationsschnittstelle 74 der intelligenten Einrichtung (die jede bekannte Kommunikationsschnittstelle für intelligente Einrichtungen aufweisen kann, beispielsweise eine Fieldbus-Einrichtungsschnittstelle, die von Softlng, einer deutschen Firma in Karlsruhe, entwickelt wurde, oder die HART-Einrichtungsschnittstelle von Micromotion, Boulder, Colorado), die speziellen Daten von der Online-Einrichtung abzurufen.
Die Kommunikationsschnittstelle 74 der intelligenten Einrichtung sendet dann eine Anforderung an den DDS 72 nach Information, wie die spezielle Online-Einrichtung für die von dem Server 68 angeforderten Daten zu erreichen ist. Der DDS 72 ruft diese Anweisungsinformation von der Einrichtungsbeschreibung für die Online-Einrichtung ab und leitet die Anweisungsinformation an die Kommunikationsschnittstelle 74 der intelligenten Einrichtung zurück, die ihrerseits eine richtige Anforderung an die intelligente Online-Eirichtung sendet. Die intelligente Einrichtung spricht dann mit einem Datenstrom an, der die bestimmten Daten einschließt. Die Kommunikationsschnittstelle 74 der intelligenten Einrichtung sendet dann eine Anforderung an den DDS 72 über Information, wie der von der intelligenten Online-Einrichtung empfangene Datenstrom zu interpretieren ist. Der DDS 72 ruft dann Interpretationsanweisungen von der Einrichtungsbeschreibung für die intelligente Online-Einrichtung ab und leitet sie zu der Kommunikationsschnittstelle 74 der intelligenten Einrichtung zurück, die ihrerseits den Datenstrom von der Online-Einrichtung nach Maßgabe der Interpretationsanweisungen interpretiert, um die von dem Server 68 angeforderten bestimmten Daten zu extrahieren. Die Kommunikationsschnittstelle der intelligenten Einrichtung leitet dann die bestimmten Daten an den Server 68 zurück, der die abgerufenen Daten dem OLE-Objekt zuführt, mit dem diese Daten assoziiert sind.
Der Vorgang des Schreibens von Daten an eine Online- Einrichtung ist gleichartig mit dem Vortang des Lesens von Daten von dieser Einrichtung mit der Ausnahme, daß der Server 68 zuerst eine Anforderung an den DDS 72 für Schreibinformation sendet, ob beispielsweise die Daten schreibfähig sind, welcher Typ, welche bestimmten Werte und welcher Datenbereich geschrieben werden kann usw. Wenn die Daten schreibfähig sind, sendet der Server 68 einen Schreibbefehl an die Kommunikationsschnittstelle 74 der intelligenten Einrichtung, die ihrerseits mit dem DDS 72 für Schreibprotokolle für die Online-Einrichtung in Dialog tritt und als Antwort auf die Information den richtigen Schreibbefehl an die Online-Einrichtung sendet. Die Kommunikationsschnittstelle 74 der intelligenten Einrichtung kann auch andere Daten von den Online-Einrichtungen wie etwa Schreibbestätigungen, Antwortcodes, Daten- oder Wertänderungen, die in der Einrichtung auftreten, usw. interpretieren und solche Daten an den Server 68 zur Speicherung in dem richtigen OLE-Objekt senden.
In manchen Fällen informiert der DDS 72 den Server 68, daß er mehr Information zur Beantwortung einer Datenanforderung benötigt. Beispielsweise kann der DDS 72 bestimmen, daß die Aufbereitungseigenschaft eines Parameters (d. h. ob der Parameter lesbar und/oder schreibbar ist) von dem Modusparameter einer bestimmten Einrichtung abhängig ist. Der DDS 72 sendet eine Anforderung an den Server 68 für den Modusparameter der Einrichtung. Als Antwort darauf sendet der Server 68 eine Anforderung für den Modusparameter einer Einrichtung an die Kommunikationsschnittstelle 74 der intelligenten Einrichtung, die wie oben beschrieben, wirksam wird, um den Modusparameter der Einrichtung abzurufen. Wenn der Server 68 den Modusparameter der Einrichtung von der Kommunikationsschnittstelle 74 für intelligente Einrichtungen empfängt, sendet er diese Information an den DDS 72, der danach die Verarbeitungseigenschaft eines Parameters einer Einrichtung bestimmt und diese Eigenschaft an den Server 68 rücksendet, der seinerseits diesen Wert in dem richtigen OLE-Parameterobjekt plaziert.
Die Kommunikation zwischen dem Server 70, dem DDS 72 und der FMS-Datenbankschnittstelle 80 ist gleichartig mit der oben beschriebenen mit der Ausnahme, daß die FMS- Datenbankschnittstelle 80 so programmiert ist, daß sie Information zu und von der FMS-Datenbank 40 anstatt einer intelligenten Einrichtung schreibt und liest. Im allgemeinen imitiert jedoch die FMS-Datenbankschnittstelle 80 die Funktionen der Kommunikationsschnittstelle 74 der intelligenten Einrichtungen, soweit sie sich auf Kommunikationen zischen dem DDS 72 und dem Server 70 beziehen.
Es ist möglich, die FMS-Datenbankschnittstelle 80 zu veranlassen, Information, die beispielsweise Werte betrifft, die mit Offline-Einrichtungen zusammenhängen, und Daten, die sich auf Änderungen an Online- und Offline-Einrichtungen beziehen, in der Datenbank 40 in einem DDL-Format zu speichern, d. h. in einem Format, das imitiert, wie diese Daten in Online-Einrichtungen gespeichert sind. In einem solchen Fall kann es notwendig sein, daß die FMS- Datenbankschnittstelle 8 den DDS 72 liest, um zu bestimmen, wie die Daten in der FMS-Datenbank 40 gespeichert sind. In einigen Fällen speichert beispielsweise die Datenbank 40 Parameterwerte wie etwa frühere Parameterwerte, um beispielsweise den Zustand einer Einrichtung zu imitieren. Infolgedessen kann es sein, daß die FMS- Datenbankschnittstelle 80 Zugang zu dem DDS 72 benötigt, um diese Information abzurufen, um zu wissen, welche Art von Daten in der Datenbank gespeichert ist, d. h. ganzzahlig, als Aufzählung usw. In der Datenbank 40 gespeicherte Information braucht jedoch nicht in einem DDL-Format gespeichert zu sein. Um also einen Befehl von dem Server 70 zum Lesen von Daten aus der bzw. Schreiben von Daten in die Datenbank 40 auszuführen, muß die FMS-Datenbankschnittstelle 80 nicht unbedingt den DDS 72 für Einrichtungswerte lesen. Statt dessen kann die FMS-Datenbankschnittstelle 80 Daten direkt zu der Datenbank 40 schreiben und Daten daraus lesen.
Die FMS-Datenbankschnittstelle 80 ist bevorzugt eine Anwendungsprogrammschnittstelle (API) eines herkömmlichen Typs, die speziell eingerichtet und konfiguriert ist, um Information aus der Datenbank 40 nach jeder gewünschten oder bekannten Methode abzurufen. Somit verfolgt die FMS- Datenbankschnittstelle 80 automatisch, wo und wie Daten in der Datenbank 40 gespeichert sind bzw. abgerufen werden.
Wie oben gesagt, kann die aktuelle Anwendung 56 und, falls gewünscht, auch der Schnittstellenblock 58 durch die FMS- Datenbankschnittstelle 62 und den ODBC-Block 64 mit der Datenbank 40 in Dialog treten. Die FMS- Datenbankschnittstelle 62 kann jede gewünschte oder bekannte Anwendungsprogrammschnittstelle bzw. API aufweisen, die eine Bibliothek von Routinen hat, die zur Umwandlung von Daten und Anforderungen von einem Format, das von der aktuellen Anwendung 56 erkannt oder benützt wird, in eine Form, die von dem ODBC-Block 64 erkannt und benützt wird, und umgekehrt, entwickelt wurde. Die Anwendung der FMS- Datenbankschnittstelle 62 (API) zum Schreiben in die Datenbank 40 - im Gegensatz zu einer direkten Verwendung des ODBC-Blocks 64 - trägt dazu bei, die Datenbankintegrität und -konsistenz zu erhalten, und macht das Schreiben von Anwendungen einfacher, weil die Anwendung dann gegenüber der Datenbankverwaltung abgeschirmt ist. Typischerweise werden die FMS-Datenbankschnittstelle 62 und der ODBC-Block 64 (oder ein anderes offenes Datenbankzugriffssystem) genutzt, wenn eine Anwendung Daten in der Datenbank 40 in einem Format speichern muß, das mit dem hier erörterten OLE- Objekthierarchie-Kommunikationsschema nichtzugänglich oder inkompatibel ist.
Die Fig. 3 und 4 zeigen eine bestimmte Hierarchie von OLE- Objekten, die entwickelt wurde, um die gesamte Information darzustellen, die innerhalb einer oder mehrerer DDL, einer Gruppe von intelligenten Einrichtungen, die den Protokollen dieser DDL folgen, und einer Datenbank, die Information speichert, die sich auf diese DDL benutzende Einrichtungen bezieht, definiert oder davon verfügbar ist. Die Hierarchie der Fig. 3 und 4 stellt außerdem die Beziehungen zwischen diesen OLE-Objekten dar. Diese Hierarchie kann innerhalb einer OLE-Umgebung genutzt werden, um es einer Anwendung zu ermöglichen, Information abzurufen, die mit einer DDL, mit diese DDL verwendenden intelligenten Einrichtungen und mit einer Datenbank, die Information speichert, die diese DDL verwendende intelligente. Einrichtungen betrifft, assoziiert ist. Somit repräsentiert die Hierarchie der Fig. 3 und 4 nicht nur eine Anordnung von DDL-Information (d. h. von Information, die von Einrichtungsbeschreibungen von DDL verfügbar ist, und/oder Information, die von einer Einrichtung oder einer Datenbank verfügbar ist, die mit Einrichtungen assoziiert ist, die eine oder mehrere DDL verwenden), sondern auch eine Möglichkeit, eine Schnittstelle zwischen der DCI 60 und den Servern 68 und 70 der Fig. 2 zu definieren, um diese Information zu lesen, abzurufen und zu ändern.
Jedes der OLE-Objekte in der Hierarchie der Fig. 3 und 4 ist bevorzugt ein OLE-Automatisierungsobjekt und ist als ein Oval dargestellt, in dem die Art von OLE-Objekt identifiziert ist. Jedes der OLE-Objekte der Fig. 3 und 4 umfaßt oder ist assoziiert mit einer Untermenge der Information, die in einer oder mehreren DDL definiert ist oder davon verwendet wird und von Einrichtungsbeschreibungen, intelligenten Einrichtungen und Datenbanken, die Information speichern, die intelligente Einrichtungen betrifft, verfügbar ist.
Im allgemeinen weist jedes der OLE-Automatisierungsobjekte der Fig. 3 und 4 Eigenschaften (oder Attribute), Methoden und Schnittstellen auf. Da die OLE-Objekte innerhalb der Fig. 3 und 4 Automatisierungsobjekte sind, haben sie eine ihnen zugeordnete Idispatch-Schnittstelle (eine wohlbekannte Schnittstelle des OLE-Protokolls). Idispatch der OLE- Automatisierungsobjekte der Fig. 3 und 4 kann beispielsweise von der DCI 60 und dem Servernetz 66 genutzt werden, um Information abzurufen, die die Eigenschaften und die Methoden dieses OLE-Objekts betreffen, und um mit anderen OLE-Objekten zu kommunizieren.
Die Eigenschaften eines OLE-Objekts weisen Daten auf, die die Objekte betreffen. Jede Eigenschaft hat auch Funktionen, die beispielsweise dazu genutzt werden können, den Eigenschaftswert des OLE-Objekts zu erhalten und einzustellen. Beispiele der OLE-Objekteigenschaften umfassen den Namen des Objekts, einen Zählwert der Anzahl von Items innerhalb des Objekts oder damit assoziiert, ein dem Objekt zugeordnetes Etikett und dem Objekt zugeordnete Hilfe.
OLE-Objektmethoden führen Aktionen an OLE-Objekten oder an den Daten in OLE-Objekten aus, implementieren bestimmte Routinen unter Nutzung der Daten in OLE-Objekten und kommunizieren mit anderen OLE-Objekten. Beispielsweise kann eine Methode eine Menge von Werten in anderen OLE-Objekten aufzählen. Gemeinsam definieren die Eigenschaften und die Methoden eines OLE-Automatisierungsobjekts die programmierbare Schnittstelle dieses OLE-Objekts, auf die das Servernetz 66 und die DCI 60 Zugriff haben.
Die Hierarchie der Fig. 3 und 4 weist eine in Fig. 3 gezeigte obere Hierarchie und eine in Fig. 4 gezeigte untere Hierarchie auf. Die obere Hierarchie von Fig. 3 entspricht der physischen oder definierten Anschließbarkeit von Einrichtungen wie HART-, Fieldbus- und anderen intelligenten oder herkömmlichet Einrichtungen und Blöcken wie etwa Fieldbus-Blöcken, die innerhalb eines Prozesses verbunden sind, und verdeutlicht dieses Anschließbarkeit. Die untere Hierarchie der Fig. 4 zeigt Beziehungen zwischen den Daten, die von DDL wie den HART- und Fieldbus-DDL verfügbar oder darauf bezogen sind, und den Daten, die in Einrichtungsbeschreibungen, intelligenten Einrichtungen und/oder einer Datenbank, die intelligente oder andere Einrichtungen betrifft, gespeichert sind und/oder davon verfügbar sind.
Um ein vollständiges Verständnis der Hierarchie der Fig. 3 und 4 zu erleichtern, ist am Ende der vorliegenden Beschreibung eine Tabelle (mit der Bezeichnung "OLE-Objekt- DDL-Äquivalente") beigefügt. Die Tabelle der OLE-Objekt-DDL- Äquivalente bezeichnet für jedes der in der unteren Hierarchie der Fig. 4 gezeigten OLE-Objekte die furlktionell äquivalenten Daten, Definitionen und/oder Konstrukte der Fieldbus-DDL, die dem OLE-Objekt entsprechen. Es ist jedoch zu beachten, daß die OLE-Objekte der Fig. 3 und 4 gleichermaßen funktionell äquivalente Typen von Daten, Definitionen und Konstrukten haben, die in anderen DDL wie etwa der HART-DDL verfügbar sind, und daß die Hierarchie der Fig. 3 und 4 daher bei jeder DDL anwendbar ist. Eine weitere Tabelle (mit der Bezeichnung "OLE-Objekt-Definitionen"), die ebenfalls am Ende der Beschreibung beigefügt ist, liefert eine Liste von einigen wichtigen Eigenschaften und Methoden, die jedem der OLE-Objekte der Fig. 3 und 4 zugeordnet sind, und liefert eine Kurzbeschreibung dieser Eigenschaften und Methoden.
Um es erneut zu sagen, die Eigenschaften der OLE-Objekte der Fig. 3 und 4 repräsentieren und entsprechen gleichartigen Arten von Daten, die von DDL (beispielsweise den HART- und Fieldbus-DDL) verfügbar sind oder davon definiert sind, weil - wie oben gesagt - die OLE-Objekte der Fig. 3 und 4 entwickelt wurden, um die Daten, die von diesen DDL verfügbar oder definiert sind, abzubilden und darzustellen. Beispielsweise repräsentiert das Blockobjekt von Fig. 3 die Blockentität, die von der Fieldbus-DDL erkannt und genutzt wird, während das Einrichtungsobjekt von Fig. 3 und das Parameterobjekt von Fig. 4 die Einrichtungs- bzw. Parameterentizäten repräsentieren und diesen entsprechen, die sowohl von den HART- als auch den Fieldbus-DDL erkannt und genutzt werden. Die in der Tabelle der OLE-Objekt- Definitionen angegebenen Methoden sind Standard-OLE- Methoden.
Jedes OLE-Objekt in der Hierarchie der Fig. 3 und 4 kann gelesen oder definiert werden, indem man einen Weg durch die Hierarchie zu diesem OLE-Objekt durchläuft. Beginnend in Fig. 3 oben, weist jeder Weg durch die Hierarchie der Fig. 3 und 4 ein Root-Objekt auf. Root-Objekte definieren u. a. die Betrachtungszeit, auf die sich die Daten in jedem der OLE- Objekte unter dem Root-Objekt beziehen. Insbesondere ist das Root-Objekt einer Betrachtungszeit zugeordnet, die "Vergangenheit", "Gegenwart" oder "Zukunft" sein kann und die in einigen Fällen eine bestimmte Zeit bezeichnet. Wenn die Betrachtungszeit vorhanden ist, ist die Zeit die tatsächliche Zeit. Wenn die Betrachtungszeit in der Vergangenheit liegt, kann die Zeit auf jede historische Zeit eingestellt werden, wird aber bevorzugt auf eine Zeit eingestellt, zu der eine Änderung an einem oder mehreren Parameterwerten vorgenommen wurde. Bevorzugt sind diese Änderungen in der Datenbank 40 beispielsweise in dem Ereignisprotokoll gespeichert. Wenn die Betrachtungszeit in der Zukunft liegt, kann die Zeit auf jede zukünftige Zeit oder so eingestellt werden, daß sie anzeigt, daß sie sich allgemein auf die Zukunft bezieht.
Die Itemmethode des Root-Objekts umfaßt eine Menge von Sammlungen gemäß der Angabe in der OLE-Objekt- Definitionstabelle, die die nächste Schicht in der Hierarchie von Fig. 3 definiert. Im allgemeinen definieren die Sammlungen der Itemmethode eines OLE-Objekts Verbindungen zwischen diesem OLE-Objekt und den OLE-Objekten unter diesem OLE-Objekt innerhalb der Hierarchie der Fig. 3 und 4. Jede Sammlung einer Itemmethode eines OLE-Objekts ist in der Hierarchie der Fig. 3 und 4 durch den in Anführungsstriche gesetzten Namen dieser Sammlung unter dem OLE-Objekt, das diese Sammlung aufweist, gezeigt. Der Hauptname der Elemente innerhalb einer Sammlung ist in der Hierarchie der Fig. 3 und 4 durch nicht in Anführungsstriche gesetzte, unterstrichene Ausdrücke identifiziert, die sich unter dem OLE-Objekt befinden, das dem Sammlungstyp zugeordnet ist, und über dem OLE-Objekt, das Information hat, die sich auf diesen Ausdruck als eine seiner Eigenschaften bezieht.
Beispielsweise hat das Root-Objekt eine Sammlung von Blockkennungsobjekten bzw. BlockTag-Objekten (als die "BlockTag"-Sammlung bezeichnet), von denen jedes einen bestimmten Namen hat, der in Fig. 3 allgemein als Block Tag gezeigt ist. Im allgemeinen ist eine Blockkennung eine eindeutige Kennung, die einem bestimmten Block innerhalb des FMS-Systems von einem Techniker zugeordnet wird, der das FMS-System installiert/konfiguriert, um einen bestimmten Block zu identifizieren. Ein BlockTag-Objekt, das einen Namen Block Tag hat, definiert somit eindeutig ein Blockobjekt, wie Fig. 3 zeigt. Es ist ersichtlich, daß die tatsächliche Anzahl von BlockTag-Objekten innerhalb der Hierarchie der Fig. 3 und 4 von der Anzahl von Blöcken (wie diese Bezeichnung in dem Fieldbus-DDL-Protokoll verwendet wird) abhängt, die mit dem FMS-System 10 verbunden oder ihm zugeordnet sind.
Die Objekte PhysicalTag, DeviceID und DeviceTag beziehen sich auf die Sammlungen "PhysicalTag", "DeviceID" und "DeviceTag" des Root-Objekts und werden benutzt, um eine bestimmte Einrichtung, die mit dem FMS-System 10 verbunden oder ihm zugeordnet ist, eindeutig zu definieren. Eine Einrichtungs-ID umfaßt typischerweise eine Dreifachinformation, die den Namen des Herstellers der Einrichtung, die Modellnummer der Einrichtung und eine Seriennummer der Einrichtung umfaßt. Einrichtungskennungen und physische Kennungen beziehen sich gewöhnlich auf einen Ort der Einrichtung in einer Anlage oder einem Prozeß wie etwa dem Prozeß 12. Der Wert einer physischen Kennung und/oder einer Einrichtungskennung kann beispielsweise ein alphanumerischer Code sein, der einer bestimmten physischen Lokation in der Anlage zugeordnet ist, oder irgendeine andere Beschreibung eines physischen Orts sein. Bei HART- Einrichtungen wird die physische Kennung gleich wie die Einrichtungskennung angesehen, wogegen für Fieldbus- Einrichtungen die physische Kennung einen anderen Wert als die Einrichtungskennung haben kann. Die OLE-Objekte in den Fig. 3 und 4 unmittelbar unter einem in Anführungsstriche gesetzten Sammlungsnamen wie etwa clas PhysicalTag-Objekt, das DeviceTag-Qbjekt und das DeviceID-Objekt werden ebenfalls als Sammlungen bezeichnet, weil sie auf Konstrukte bezogen sind, die eine DDL als Sammlungen betrachtet oder definiert.
Anstelle einer physischen Kennung und/oder einer Device-ID oder zusätzlich dazu kann eine Einrichtung durch ihre physische Kommunikationsverbindung mit einem FMS-System identifiziert werden. Insbesondere ist jede Einrichtung mit einem FMS-Netz (in Fig. 3 durch das Netzwerkobjekt dargestellt, das eine "Net"-Sammlung des Root-Objekts ist) durch eines einer Reihe von Netzen verbunden, von denen jedes generisch durch den Ausdruck TCP/IP Node Name gekennzeichnet ist.
Jedes Netz umfaßt eine Serie von Knoten, die in Fig. 3 durch das NetNode-Objekt gekennzeichnet sind. Ein Netzknoten umfaßt eine Gruppe von Ports (dargestellt durch das Port- Objekt), die Namen wie beispielsweise "Com1" oder "Com2" haben können. Der Port kann mit einer Einrichtung durch ein Modem (gekennzeichnet durch das Modem-Objekt) und an einer von sechzehn Stationsadressen verbunden sein, deren jede durch eine anderen Station Address gekennzeichnet ist.
Der Port eines Netzknotens kann ferner mit einer Einrichtung durch eine oder mehrere HART-Schnittstelleneinheiten (HIU) (gekennzeichnet durch ein HIU-Objekt), die eine Station Address haben, verbunden sein. Austauschobjekte umfassen auch eine Methode (die im Gegensatz zu der obigen allgemeinen Regel über in Anführungszeichen gesetzte Namen durch das Etikett "Block" gekennzeichnet ist), die eine Schnittstelle zu dem speziellen Blockobjekt zurückbringt, das die HIU beschreibt.
Ein Netzknoten kann auch mit einer Einrichtung durch eines oder mehrere verschiedene DCS, beispielsweise das RS3, Provox oder ein anderes DCS gekoppelt sein. Fig. 3 zeigt zwar jede davon als durch ein generisches DCS-Objekt verbunden, die eigentliche Verbindung mit beispielsweise einem RS3-DCS würde in Fig. 3 durch eine Knotennummer, eine Kartennummer, einen Port (typischerweise einen von vier Ports in einer Karte) und eine Leitung (typischerweise vier Leitungen je Port) hergestellt werden und könnte entsprechend identifiziert werden. Da jedoch die Konfigurationen dieser DCS-Systeme noch nicht vollständig entwickelt sind, sind die tatsächlichen Verbindungen mit jedem nicht gezeigt, und das DCS-Objekt wird in der OLE- Objekt-Definitionstabelle nicht erwähnt.
Ferner kann ein Netzknoten mit einer oder mehreren Fieldbus- Schnittstellenkarten gekoppelt sein. Da jedoch die Fieldbus- Einrichtungen noch nicht verkauft sind, ist die exakte Verbindung mit einer Einrichtung noch unbekannt, und daher ist diese Verbindung in der Hierarchie von Fig. 3 nicht dargestellt. Eine solche Fieldbus-Verbindung könnte jedoch leicht hinzugefügt werden, indem ein Fieldbus-Objekt und irgendwelche anderen OLE-Objekte, die mit den für eine Fieldbus-Verbindung erforderlichen Komponenten verwandt sind, zwischen einem Netzknoten und einer Einrichtung zwischen dem NetNode-Objekt und dem Device-Objekt gezeigt wird.
Nachdem eine Einrichtung auf eine der oben bezeichneten Weisen identifiziert ist, kann ein Block in der Einrichtung durch die "Tag",-Sammlung, die als das Tag-Objekt, das den Hart Tag Namen hat, dargestellt ist, eindeutig bestimmt werden. Wenn die Einrichtung eine HART-Einrichtung ist, deren Inhalte durch nur einen konzeptuellen Block dargestellt sind, ist der Block bereits eindeutig identifiziert und kann einfach durch die HART"-Sammlung bezeichnet werden. Die Namen der Kennungen, die sich auf das Tag-Objekt beziehen, sind in Fig. 3 als HART Tag angegeben, weil die HART-Kennung der HART-Einrichtungen als dieser Identifikator dient. Es könnten jedoch andere Kennungen für andere Arten von Einrichtungen statt dessen verwendet werden.
Wie oben angedeutet, kann ein Blockobjekt und dementsprechend ein Block eines Prozesses eindeutig erkannt werden durch Verfolgen eines der oben definierten Wege durch die obere Hierarchie von Fig. 3. Ebenso kann jedes andere OLE-Objekt innerhalb der Hierarchie der Fig. 3 und 4 durch einen eindeutigen Moniker identifiziert werden, der durch Verfolgen eines Wegs von dem Root-Objekt am oberen Ende der Hierarchie von Fig. 3 bis zu dem bestimmten OLE-Objekt erhalten wird. Danach kann auf die Eigenschaften und Methoden jedes der OLE-Objekte innerhalb der Hierarchie der Fig. 3 und 4 Bezug genommen und sie können erhalten werden, indem der für dieses OLE-Objekt entwickelte Moniker genutzt wird.
Insbesondere kann ein Moniker aus der Hierarchie der Fig. 3 und 4 durch Kompilieren einer Folge bestimmt werden, die die Ausdrücke in Anführungszeichen und die Ausdrücke ohne Anführungszeichen/mit Unterstreichung aufweist, die bei der Verfolgung eines Wegs von dem Root-Objekt in Fig. 3 bis zu dem interessierenden OLE-Objekt angetroffen, werden, und durch Trennen dieser Ausdrücke mit einem Ausrufezeichen ("!"). Beispielsweise kann der Moniker für ein Blockobjekt einer der folgenden sein:
Root!BlockTag!BlockTag!
Root!PhysicalTag!HART Tag!Tag!HART Tag
Root!DeviceIDUnique Identifier!HART
Root!Net!TCP/IP Node Name!Port
Name!Modem!Station Address!Tag!HART Tag
Wie ersichtlich ist, können Moniker für andere in den Fig. 3 und 4 gezeigte OLE-Objekte unter Anwendung dieses Formats. entwickelt werden. Die Sammlung "NamedConfig" des Root- Objekts von Fig. 3 (dargestellt durch das NamedConfigs- Objekt) bezieht sich auf Objekte, die in der FMS-Datenbank 40 gespeichert sind und nicht von einer Einrichtung verfügbar sind. Jedes NamedConfigs-Objekt ist durch einen ConfigName identifiziert und bezeichnet ein bestimmtes NamedConfig-Objekt. Ein NamedConfig-Objekt kann beispielsweise ein "Rezept" oder eine bestimmte Konfiguration eines Blocks aufweisen, die zur Implementierung einer bestimmten Funktion innerhalb eines Prozesses, einer früheren Konfiguration eines Blocks innerhalb eines Prozesses oder auch jeder anderen gewünschten Anwenderinformation, die auf Blockobjekte bezogen ist, erforderlich ist. Für das Servernetz 66 von Fig. 2 sieht jedoch jedes NamedConfig-Objekt ähnlich wie ein Blockobjekt aus mit der Ausnahme, daß die Parameterwertdaten eines NamedConfig-Objekts von der FMS-Datenbank 40 und nicht von einer Einrichtung abgerufen werden. Bei NamedConfig- Objekten kann typischerweise eine Informationsuntermenge einem Blockobjekt zugeordnet sein.
Die untere Hierarchie von Fig. 4 zeigt eine Beziehung zwischen den Daten, die jedem Block eines Systems zugeordnet sind. Daher umfaßt, wie Fig. 4 zeigt, jedes Blockobjekt (und jedes NamedConfig-Objekt) eine Menge von Sammlungen, die mit "Param", "Unit", "Database", "Refresh", "ItemArray", "Collection", "Menu", "Method", "EditDisplay" und "WAO" bezeichnet sind und denen jeweils ein (jeweils geringfügig anders bezeichnetes) OLE-Objekt zugeordnet ist. Jedes dieser OLE-Objekte hat andere OLE-Objekte, die damit in Beziehung stehen, wie in Fig. 4 definiert ist. Beispielsweise kann ein Parameterobjekt, das durch einen Param Name identifiziert ist, ein VariableParameter-Objekt, ein RecordParameter- Objekt oder ein ArrayParameter-Objekt sein. Wenn es ein VariableParamecer-Objekt ist, weist es Sammlungen von "IndexedItemArray", "Enum", "PreEdit" und "PostEdit" auf, die sämtlich zugeordnete OLE-Objekte haben. Das EnumerationValues-Objekt (eine Sammlung des VariableParameter-Objekts für Variablen vom aufgezählten Typ) hat spezielle aufgezählte Werte, die durch das EnumerationValue-Objekt identifiziert sind, das seinerseits eine Sammlung von Method-Objekten aufweist. Diese Method- Objekte können beispielsweise Methoden des Erhaltens oder Änderns von aufgezählten Werten eines VariableParameter- Objekts aufweisen.
Die Eigenschaften, Daten und Methoden, die in allen OLE- Objekten innerhalb Fig. 4 gespeichert oder ihnen zugeordnet sind - mit Ausnahme der DatabaseParameter und DatabaseParameter-Objekte - repräsentieren Information, die von oder durch die Verwendung von Einrichtungsbeschreibungen oder eine Einrichtung, die einer DDL entspricht, verfügbar ist. Die Daten und Methoden der DatabaseParameter und DatabaseParameter-Objekte sind in einer Datenbank gespeichert.
Ebenso wie im Fall von Fig. 3 kann jedes OLE-Objekt in Fig. 4 eindeutig durch einen Moniker erkannt werden, der durch Verfolgen eines Wegs von dem Root-Objekt von Fig. 3 nach unten zu dem jeweils interessierenden OLE-Objekt entwickelt wird. Beispielsweise könnte der Moniker für einen PreEdit- Method-Block konstruiert werden, indem dem Ende des Monikers für irgendein Blockobjekt von Fig. 3, das auch durch das Blockobjekt von Fig. 4 dargestellt ist, der Ausdruck !Param!Param Name!PreEdit!Index hinzugefügt wird.
Nachdem für ein bestimmtes Objekt innerhalb der Hierarchie der Fig. 3 und 4 ein Moniker etabliert und in dem Speicher gespeichert ist, der dem Servernetz 66 zugeordnet ist, kann die DCI 60 und das Servernetz 66 danach an diesem OLE-Objekt eine Operation ausführen und darauf zugreifen unter Anwendung eine kürzeren eindeutigen "Kennung", die von dem Servernetz 66 erzeugt wird. Die Kennung kann beispielsweise eine eindeutige Zahl aufweisen, die ein OLE-Objekt identifiziert, das in dem Speicher des Servernetzes 66 gespeichert wurde.
Mit einem eindeutigen Moniker oder der Kennung kann im wesentlichen auf jedes durch die Hierarchie der Fig. 3 und 4 bezeichnete OLE-Objekt sofort von der DCI 60 oder dem Servernetz 66 zugegriffen werden, und die Methoden innerhalb dieses OLE-Objekts können aufgerufen werden, um eine Kommunikation mit den DDS, einer Datenbank, einer intelligenten Einrichtungen oder anderen OLE-Objekten je nach Erfordernis herzustellen. Beispielsweise kann die Softwareroutine innerhalb des Servers 68, die auf die DDS 72 zugreift, um Einen bestimmten Parameterwert von einer bestimmten Einrichtung abzurufen, initiiert werden, wenn ein Anruf an das richtige VariableParameter-Objekt durch die DCI 60 unter Nutzung eines Befehls initiiert wird, der das OLE- VariableParameter-Objekt anweist, einen Parameterwert zu lesen.
Es ist ersichtlich, daß das Servernetz 66 mit der Datenbank 40, dem DDS 72 und den Online-Einrichtungen für die DCI 60 und die aktuelle Anwendung 56 transparent kommuniziert, weil das Servernetz automatisch die Beziehungen zwischen den OLE- Objekten, die durch die untere Hierarchie der Fig. 4 identifiziert sind, liest, um zu bestimmen, welche Gruppe von Routinen zu implementieren ist, um neue Information zu erhalten, die von einem OLE-Objekt oder einem DDS angefordert wird.
Es ist zu beachten, daß für den Zugang zu jedem OLE-Objekt der Fig. 3 und 4 die OLE-Objekte über diesem OLE-Objekt in mindestens einem Weg zwischen diesem OLE-Objekt und dem Root-Objekt von Fig. 3 in dem Speicher des Servernetzes gespeichert sein müssen. Wenn also beispielsweise Zugriff auf ein VariableParameter-Objekt eines Parameters für einen Block zugegriffen wird, werden das Parameterobjekt und das Blockobjekt, die diesem Parameter und diesem Block zugeordnet sind, ebenfalls in dem Speicher des Servernetzes gespeichert. Das Device-Objekt, das DeviceID-Objekt und das Root-Objekt können ebenfalls in dem Speicher des Servernetzes gespeichert werden. Ohne diese Objekte der höheren Ebene kann das Servernetz 66 nicht auf genügend Information zugreifen, um zu bestimmen, wie die Daten des VariableParameter-Objekts zu lokalisieren und abzurufen sind.
In einer typischen Situation sendet die DCI 60 einen Befehl zum Erhalt eines Werts von einem OLE-Objekt, beispielsweise die Abwicklungseigenschaft eines VariableParameter-Objekts für einen bestimmten Block einer bestimmten Einrichtung unter Verwendung eines Monikers oder einer Kennung, die für dieses VariableParameter-Objekt vorgesehen worden ist. Wenn das identifizierte OLE-Objekt noch nicht in dem Speicher des Servernetzes 66 gespeichert wurde, verwendet das Servernetz 66 vorher geschriebene Routinen und die Methoden des einen oder der mehreren OLE-Objekte über dem VariableParameter- Objekt, um diese Daten beispielsweise von einem der DDS 72, der intelligenten Einrichtung selbst oder der Datenbank 40 abzurufen. Das Servernetz 66 speichert diese Daten dann in einem Serverspeicher. Falls notwendig, speichert das Servernetz 66 zuerst beispielsweise das Root-Objekt, das DeviceID-Objekt, das Device-Objekt, das Block-Objekt und das Parameters-Objekt in dem Speicher.
Als nächstes verwendet der Server die Methoden des VariableParameter-Objekts und vorgeschriebene Routinen, die diesem zugeordnet sind, um Zugriff auf den DDS 72 zu haben (weil sich dort die Abwicklungsinformation eines variablen Parameters eines Blocks befindet). Wenn wie in diesem Fall der Wert der Abwicklungseigenschaft des variablen Parameters von dem Modusparameter, in den die intelligente Einrichtung aktuell eingestellt ist, abhängig ist, sendet der DDS eine Meldung an den Server 68 zurück und informiert den Server 68, daß der DPS die Modusparameterinformation benötigt, die die Einrichtung oder den Block betrifft, der diese Variable enthält. An diesem Punkt lokalisiert der Server 68 das Device-Objekt, das auf das VariableParameter-Objekt bezogen ist, um zu bestimmen, wie mit der Einrichtung kommuniziert werden soll, d. h. wo sich die Einrichtung in dem System befindet und wie mit dieser Einrichtung in Dialog getreten werden kann. Der Server 66 verwendet dann eine vorgeschriebene Routine zur Kommunikation mit der Einrichtung, die dem Device-Objekt zugeordnet ist, um die Kommunikationsschnittstelle 74 für intelligente Einrichtungen anzuweisen, den Modusparameter der Einrichtung abzurufen. Wenn die Kommunikationsschnittstelle 74 für intelligente Einrichtungen den Modusparameterwert zum Server 68 rücksendet, liefert der Server 68 diese Information an das DDS 72, das danach die Abwicklungseigenschaft berechnet und sie an den Server 66 zurücksendet, der sie dann zu dem OLE-VariableParameter-Objekt und dadurch zu der DCI 60 weiterleitet (weil Änderungen in OLE-Objekten dazu führen, daß Meldungen an den Hauptrechner, in diesem Fall die DCI 60, geschickt werden). Somit sieht es für die DCI 60 nur so aus, daß eine Anforderung für ein Lesen der Abwicklungseigenschaft eines Parameters zu einem OLE-Objekt geschickt wurde und daß eine Meldung mit der Abwicklungseigenschaft rückgesendet wurde. Die Kommunikation mit dem DDS und zwischen OLE-Objekten wurde automatisch von dem Server und für die aktuelle Anwendung 56 transparent hergestellt, und die Anwendung brauchte nichts Bestimmtes hinsichtlich der Art der angesprochenen Einrichtung, der Einrichtungsbeschreibung oder der DDL, die dieser Einrichtung zugeordnet sind, usw. zu wissen. Unter Verwendung der oben definierten Schnittstelle kann also eine Anwendung mit einer Reihe von verschiedenen intelligenten Einrichtungen kommunizieren, wobei den gleichen oder anderen DDL-Protokollen gefolgt wird, ohne daß irgendwelche der speziellen Punkte der DDS, DDL oder DD berücksichtigt werden, die zur Implementierung dieser Kommunikation anzuwenden sind.
Für den Fachmann ist ersichtlich, daß die DCI 60 dadurch mit der OLE-Hierarchie der Fig. 3 und 4 kommunizieren und Informationen davon abrufen kann, indem relativ einfache Routinen ausgeführt werden, die beispielsweise (1) eine Objekthierarchie schaffen und sie mit dem Servernetz 66 assoziieren, (2) die Objekthierarchie durchlaufen, um die unter einem bezeichneten Objekt vorhandenen Objekte zu erforschen, (3) Standard-OLE-Methoden wie Item, die einen bestimmten Weg von einem Objekt zu einem anderen durchlaufen, und NewEnum, die eine Schnittstelle zur Aufzählung von eine Ebene tiefer liegenden Objekten schafft, implementieren, (4) Methoden implementieren, die sich auf Blockobjekte beziehen, die auf DDL-Operationen bezogene Methoden einschließen können, (5) Root- und Device- Objekteigenschaften lesen und schreiben, (6) nichtblockierende Lese- und Schreibanforderungen von OLE- Objekten initiieren und steuern, (7) Resultate von blockierenden Lese- und Schreiboperationen abrufen, (8) Änderungen an der Datenbank 40 steuern und (9) die Erschaffung und Erhaltung eines Ereignisprotokolls steuern, das Information aufweist, die sich beispielsweise auf vom Anwender vorgenommene Änderungen des Systems einschließlich Änderungszeiten, Identifikation der Personen und der Rechner, die die Änderungen vorgenommen haben, usw. bezieht.
Als Ergebnis braucht eine Anwendung für das FMS-System 10 nicht speziell programmiert zu werden, um mit einem DDS, einer Datenbank oder intelligenten Einrichtungen in Dialog zu treten, was es wiederum einem Anwenderentwickler erlaubt, in bezug auf DDL-Formate, Einrichtungsbeschreibungen und Kommunikationen von intelligenten Einrichtungen wesentlich weniger Wissen zu haben.
Es ist zu beachten, daß bei Anwendung der Hierarchie der Fig. 3 und 4 auf die oben beschriebene Weise jede von dem FMS-System 10 implementierte Anwendung mit FMS-Einrichtungen in Dialog treten kann, die beispielsweise eine OLEkompatible Programmierumgebung verwenden, um Zugang zu den IUnknown- und IDispatch-Schnittstellen zu gewinnen, die jedem Objekt in der Hierarchie zugeordnet sind. Es wird davon ausgegangen, daß Visual Basic Programme und C++ Programme gut geeignet sind, um die oben definierte OLE- Hierarchie zu nutzen.
Die Hierarchie der Fig. 3 und 4 bezieht sich zwar speziell auf die Fieldbus-DDL und die HART-DDL, die der Fieldbus-DDL sehr ähnlich ist, aber es wird davon ausgegangen, daß diese oder eine gleichartige Hierarchie für andere DDL erstellt werden kann, die anderen intelligenten Einrichtungen zugeordnet sind, beispielsweise intelligenten Modbus- Einrichtungen gemäß der vorliegenden Erfindung. Außerdem wird davon ausgegangen, daß die Hierarchie der Fig. 3 und 4 von anderen objektorientierten Proqrammierprotokollen und sogar nichtobjektorientierten Programmierprotokollen implementiert werden kann.
Wie Fig. 5 zeigt, enthält die FMS-Datenbank 40 (Fig. 1 und 2) eine Transaktionsdatenbank 200, die das FMS-System 10 nutzt, um Daten zu speichern, die Änderungen darstellen, die an Parametern der verschiedenen Blöcke entsprechend den Einrichtungen 16, 18, 20, 22 in dem Prozeß 12 vorgenommen wurden. Dabei ist die Transaktionsdatenbank 200 so ausgebildet, daß sie eine Transaktionsaufzeichnung 202 speichern kann, die jeder Parameteränderung entspricht, von der das FMS-System 10 weiß oder die zu seiner Kenntnis gelangt. Jede Transaktionsaufzeichnung 202 umfaßt eine Reihe von Feldern 204-213. Jedes Feld 204-213 speichert wiederum ein Informationsteil, das sich auf die "Transaktion" (d. h. die Änderung des Werts eines Parameters) bezieht, die der Transaktionsaufzeichnung 202 entspricht.
Die hier beschriebenen Felder 204-213 der Aufzeichnungen 202 sind mit BlockKey, TimeKey, ParamName, ParamKind, ValueMode, ParamDataType, ParamSize, ParamData, Archived und Expected gekennzeichnet. Die speziellen Inhalte der Transaktionsaufzeichnungen 202 in der hier beschriebenen Transaktionsdatenbank 200 sind jedoch nur beispielhaft. Gemäß der vorliegenden Erfindung können die Aufzeichnungen 202 der Transaktionsdatenbank 200 so adaptiert werden, daß sie jede andere notwendige oder gewünschte Information, die sich auf die gespeicherten Transaktionen bezieht, oder nach Wunsch andere Information enthalten.
Die Bedeutung jedes der einzelnen Felder 204-213 wird nachstehend im einzelnen unter Bezugnahme auf eine beispielhafte Änderung oder Transaktion beschrieben, die die Zuordnung eines bestimmten Werts (V) zu einem bestimmten Parameter (P) eines bestimmten Blocks (B) zu einem bestimmten Zeitpunkt (T) betrifft. Das BlockKey-Feld 204 enthält die Identifikationsnummer des Blocks, auf den die Änderung zutrifft, ob nun die Änderung eine vergangene, aktuelle oder zukünftige Änderung ist. Die in dem BlockKey- Feld 204 gespeicherte Identifikationsnummer ist eine eindeutige Zahl, die das FMS-System 10 dem Block B zuordnet und nutzt, um den Block B eindeutig zu identifizieren. Der Wert von BlockKey für einen bestimmten Block ist beliebig. Das FMS-System 10 muß jedoch einen Index (etwa in der FMS- Datenbank 40) der allen Blöcken zugeordneten BlockKeys unterhalten.
Das TimeKey-Feld 205 speichert eine Zahl oder eine Sammlung von Zahlen, die die spezielle Zeit T bezeichnen, zu der die von der Transaktionsaufzeichnung 202 dargestellte Änderung vorgenommen wird. Beispielsweise könnte TimeKey ein tatsächliches Kalenderdatum und eine Zeit sein, die mit so viel Präzision wie nötig (d. h. in Sekunden, Millisekunden usw.) ausgedrückt wird, oder sie kann eine aus dieser Information abgeleitete Zahl wie etwa die Anzahl von Sekunden oder Millisekunden sein, die seit einem bestimmten Bezugsdatum und einer Bezugszeitabgelaufen sind (z. B. seit dem 1. Januar 1980 um 12:00). Vorteilhaft könnte TimeKey für eine Änderung weiter in zwei Feldern ausgedrückt werden, von denen das eine das Datum der Änderung und das andere den Zeitpunkt der Änderung enthält. Auch hier könnte das Zeitfeld entweder als eine tatsächliche Zeit oder als eine Anzahl von Sekunden (oder Millisekunden usw.), die seit einem Bezugszeitpunkt abgelaufen sind, ausgedrückt werden.
Das ParamName-Feld 206 enthält den Namen des jeweiligen Parameters P des jeweiligen Blocks B, auf den sich die von der Transaktionsaufzeichnung 202 gespeicherte Änderung bezieht. Die in den ParamName-Feldern 206 von Transaktionsaufzeichnungen 202 gespeicherten Namen sind die tatsächlichen Namen von Parametern, die in den OLE- Parameterobjekten des Blocks B verwendet werden, wie oben beschrieben wurde. Vorteilhaft entsprechen diese Namen auch Parameternamen, die in DDL gefunden werden.
Das ParamKind-Feld 207 enthält ein einziges alphabetisches Zeichen, das der Art des Parameters P entspricht. Wenn dabei der Parameter P ein "tatsächlicher" oder "realer" Parameter ist (d. h. ein er, der das Verhalten eines Blocks beeinflußt und/oder ändert), enthält das ParamKind-Feld 207 den Wert "P". Wenn statt dessen der Parameter P ein Parameter ist, der in der Datenbank 40 (Fig. 1) gespeichert ist, enthält das ParamKind-Feld 207 den Wert "D". Der letztgenannte Typ von Parameter wird nur in der Datenbank 40 und nicht in einer Einrichtung gespeichert. Zusätzliche Bezeichnungen von Arten von Parametern können ebenfalls vorgesehen sein (z. B. für anwenderdefinierte Parameter oder für Parameter, die Information über einen Block enthalten, den Block aber nicht beeinflussen).
Das ValueMode-Feld 208 enthält ein alphabetisches Zeichen, das angibt, ob der Wert "V" des Parameters "P" Teil eines "realen" Zustands der Einrichtung, die dem Block B entspricht, ist oder ob er statt dessen Teil eines "zukünftigen" Zustands dieser Einrichtung ist. Dabei enthält das ValueMode-Feld 208 den Wert "H", wenn die Transaktionsaufzeichnung 202 einen Teil eines realen Zustands darstellt (d. h. wenn die Aufzeichnung 202 eine vergangene oder aktuelle Änderung an dem Block B darstellt). Andererseits enthält das ValueMode-Feld 208 den Wert "F", wenn die Transaktionsaufzeichnung 202 einen Teil eines zukünftigen Zustands darstellt (d. h. wenn die Transaktionsaufzeichnung 202 eine Änderung darstellt, die zu einem unbezeichneten Zeitpunkt in der Zukunft an dem Block B vorzunehmen ist).
Das ParamDataType-Feld 209 enthält eine Zahl entsprechend der Art der Daten oder des Werts "D", der in dem Parameter P gespeichert ist (z. B. 1 = Folge, 2 = ganze Zahl, 3 = lange ganze Zahl, 4 = vorzeichenlose lange ganze Zahl, 5 = Gleitkomma, 6 = Doppelpräzision, 7 = binär usw.). Die Zahlen, die den verschiedenen verfügbaren Datentypen entsprechen, können von dem FMS-System 10 beliebig zugeordnet werden, aber das FMS- System 10 muß diese Zuordnungen verfolgen.
Das ParamDataSize-Feld 210 enthält eine Zahl, die der Größe der in dem Parameter P gespeicherten Daten D entspricht. Der in dem ParamDataSize-Feld 210 gespeicherte Wert ist die Anzahl von Bytes, die verwendet werden, um die Daten D, die den Wert des Parameters P darstellen, zu speichern.
Das ParamData-Feld 211 in einer Transaktionsaufzeichnung 202 speichert die tatsächlichen Daten oder den Wert D, der dem Parameter P von der Änderung zugewiesen wird, die durch die Transaktionsaufzeichnung 202 dargestellt ist.
Das Archived-Feld 212 ist ein fakultatives Feld, in dem eine Angabe gespeichert ist, ob die Inhalte der zugehörigen Transaktionsaufzeichnung 202 bereits archiviert oder in einem Sicherungsspeichermedium gespeichert wurden. Das Archived-Feld dient zur Minimierung der Zeit, die erforderlich ist, um eine Sicherung der Datenbank 200 zu komplettieren, indem diejenigen Transaktionsaufzeichnungen 202 identifiziert werden, die bereits archiviert wurden, so daß diese archivierten Transaktionsaufzeichnungen 202 während anschließender Archivierungsvorgänge übersprungen werden können. Das Archived-Feld dient auch als Sicherheit gegen ein ungewolltes und/oder unerwünschtes Löschen (z. B. durch Verwaltungssoftware oder Dienstsoftware) von Transaktionsaufzeichnungen 202, die noch nicht archiviert wurden. Das Archived-Feld 202 einer Transaktionsaufzeichnung 202 enthält eine Eins oder einen "wahren" Wert, wenn die Transaktionsaufzeichnung 202 bereits archiviert wurde, und enthält andernfalls eine Null oder einen "falschen" Wert.
Das Expected-Feld 213 enthält eine Angabe, ob die durch die Transaktionsaufzeichnung 202 dargestellte Änderung oder Transaktion von dem FMS-System 10, das die Änderung durchgeführt hat, als eine "erwarte" Änderung oder eine "unerwartete" Änderung identifiziert wurde. Wie nachstehend im einzelnen beschrieben wird, kann ein FMS-System 10 die Transaktionsaufzeichnungen 202 der Transaktionsdatenbank 200 der vorliegenden Erfindung nutzen, um für jeden bestimmten Zeitpunkt einen erwarten Zustand jedes Blocks jeder Einrichtung in dem Prozeß 12 zu rekonstruieren. Ein "erwarteter" Zustand einer Einrichtung ist der Zustand, von dem ein FMS-System 10 annimmt, daß es der Zustand der Einrichtung ist, basierend auf der Transaktionshistorie, die in der Transaktionsdatenbank 200 des FMS-Systems 10 gespeichert ist. Zu jedem gegebenen Zeitpunkt kann jedoch ein FMS-System 10 einen Zustand einer Einrichtung "erwarten", der nicht mit dem tatsächlichen Zustand der Einrichtung identisch ist. Beispielsweise kann ein zweites FMS-System 10 oder ein mobiler Kommunikator 46 den Zustand der Einrichtung, geändert, jedoch das erste FMS-System 10 noch nicht informiert haben, daß die Änderung vorgenommen wurde.
Bevor ein FMS-System 10 (oder ein mobiler Kommunikator) eine Änderung an einer Einrichtung (z. B. der den Block B enthaltenden Einrichtung) vornimmt, beurteilt das FMS-System 10, ob sich die Einrichtung in dem Zustand befindet, den das FMS-System 10 "erwartet, oder sich in einem anderen, "nichterwarteten" Zustand befindet. Wenn sich die Einrichtung in dem vom dem FMS-System 10 erwarteten Zustand befindet, nimmt das FMS-System 10 die Änderung vor und speichert eine Eins (oder einen anderen geeigneten "wahren" Wert) in dem Expected-Feld 213 der Transaktionsaufzeichnung 202 entsprechend der Änderung (was anzeigt, daß die Änderung erwartet wurde). Wenn dagegen das FMS-System 10 die Einrichtung in einem anderen Zustand vorfindet als dem, in dem das FMS-System 10 die Einrichtung erwartet hat, dann weiß das FMS-System 10, daß eine Änderung vorgenommen wurde, die nicht mit der Transaktionsdatenbank 200 des FMS-Systems 10 in Abstimmung gebracht wurde. (Die Vorgänge, nach denen Änderungen in eine Transaktionsdatenbank 200 eingebracht und damit in Abstimmung gebracht werden, werden nachstehend im einzelnen beschrieben.) In diesem Fall gibt das FMS-System 10 eine Transaktionsaufzeichnung 202 in die Transaktionsdatenbank 200 ein, die die Änderung darstellt, die an der Einrichtung vorgenommen werden sollte, um den Zustand der Einrichtung von dem Zustand, der von dem FMS- System 10 erwartet wurde, in den tatsächlichen Zustand zu ändern, in dem das FMS-System 10 die Einrichtung vorgefunden hat. Das FMS-System 20 speichert auch eine Null (oder einen anderen geeigreten "falschen" Wert) in dem Expected-Feld 213 für die dieser Änderungen entsprechende Transaktionsaufzeichnung 202, um anzuzeigen, daß die Änderung unerwartet war. Das Expected-Feld 213 wird von einem FMS-System 10 (wie etwa einem primären FMS) verwendet, um Transaktionsaufzeichnungen 202 von sekundären FMS und/oder mobilen Kommunikatoren 46 in dem primären FMS- System 10 in Einklang zu bringen, wie noch im einzelnen in Verbindung mit den Fig. 9 und 10 beschrieben wird.
Das ParamKind-Feld 207, Das ValueMode-Feld 208, das ParamDataType-Feld 209 und das ParamDataSize-Feld 210 einer Transaktionsaufzeichnung 202 sind in die Transaktionsaufzeichnung 202 einfach deshalb aufgenommen, um die Verarbeitung der in dem ParamData-Feld 211 der Transaktionsaufzeichnung 202 gespeicherten Daten und des Parameterobjekts, das dem Parameter P insgesamt entspricht, zu erleichtern. Wie oben gesagt, können es Standardbetriebsabläufe der Anlage, gesetzliche Vorschriften oder Anwenderpräferenzen erforderlich machen, jede andere geeignete Information wie etwa den Namen der Person, die die Änderung vorgenommen hat, den Grund für die Vornahme der Änderung oder jede andere Information in den Transaktionsaufzeichnungen 202 der Transaktionsdatenbank 200 zu speichern. Alternativ kann diese zusätzliche Information in einer zweiten Datentabelle ähnlich der Transaktionsdatenbank 200 gespeichert werden und kann Transaktionserkennungsinformation (z. B. die BlockKey-, TimeKey- und ParamName-Felder 204, 205 und 206) zusammen mit zusätzlichen Feldern für die zusätzliche Information aufweisen. Das FMS-System 10 greift dann auf die zusätzliche Information für jede Änderung durch. Verweis auf die zweite Datentabelle unter Nutzung der die Transaktion identifizierenden Felder in der jeweiligen Transaktionsaufzeichnung 202 zu, die die Änderung in der Transaktionsdatenbank 200 darstellen.
Die von dem FMS-System 10 in bezug auf die Transaktionsdatenbank 200 durchgeführten Datenbankfunktionen werden nachstehend im einzelnen beschrieben. Im allgemeinen verwendet das FMS-System 10 die Transaktionsdatenbank 200 zur Unterhaltung von historischen Aufzeichnungen von Änderungen, die an intelligenten Einrichtungen vorgenommen wurden, z. B. an den Einrichtungen 16, 18, 20, 22 in dem Prozeß 12; zur Speicherung von aktuellen Werten von Parametern in den verschiedenen Feldeinrichtungen; und zur Speicherung von Aufzeichnungen von zukünftigen Änderungen, die an diesen Einrichtungen vorzunehmen sind. Das FMS-System 10 kann in bezug auf die Transaktionsdatenbank 200 mehrere spezielle Funktionen ausführen.
Die erste Funktion ist, daß dann, wenn das FMS-System 10 (das hier manchmal als das primäre FMS-System bezeichnet wird) selbst eine Änderung an einem Parameter einer Einrichtung oder, um genauer zu sein, an einem bestimmten Block der Einrichtung vornimmt, das FMS-System 10 eine Aufzeichnung 202 zu der Datenbank 200 hinzufügt, die die gesamte oben beschriebene Information in bezug auf diese Änderung enthält. BlockKey, die von dem FMS-System 10 dem Block zugeordnet wird, in dem die Änderung vorgenommen wird, wird in dem BLockKey-Feld 204 gespeichert. TimeKey entsprechend dem Zeitpunkt, zu dem die Änderung vorgenommen wird, wird in dem TimeKey-Feld 205 gespeichert. Der Name des Parameters, dessen Wert geändert wird, wird in dem ParamName-Feld 206 gespeichert. Die Art dieses Parameters wird in dem ParamKind-Feld 207 gespeichert. Der Modus des Werts des Parameters wird in dem ValueMode-Feld 208 gespeichert. Der Typ von Daten, die von dem Parameter gespeichert werden, wird in dem DataType-Feld 209 gespeichert. Die Größe der Daten, die von dem Parameter gespeichert werden, wird in dem ParamDataSize-Feld 21 gespeichert. Der in dem Parameter gespeicherte neue Wert wird in dem ParamData-Feld 211 gespeichert. Das Archived- Feld 212 wird natürlich auf Null gesetzt, weil die Transaktionsaufzeichnung 202, da sie ja neu ist, noch nicht archiviert werden konnte. Schließlich wird, weil das FMS- System 10 selbst die Änderung an der Einrichtung vorgenommen hat, das Expected-Feld 213 auf Eins gesetzt, was anzeigt, daß die Änderung eine erwartete Änderung ist: Die Änderung ist offensichtlich "erwartet", weil das FMS-System 10 die Änderung autorisiert und selbst vorgenommen hat.
In vielen Installationen ist das FMS-System 10 nicht ständig mit allen intelligenten Einrichtungen in dem Prozeß 12 verbunden, weil solche permanenten Verbindungen typischerweise teuer zu installieren sind, auch wenn sie Vorteile hinsichtlich der leichten Konfiguration der Einrichtungen durch das FMS-System 10 bieten, mit dem die Einrichtungen permanent verbunden sind. Es kann eine sogenannte Übergangs- oder Kurzzeitverbindung zwischen dem FMS-System 10 und einer intelligenten Einrichtung, die mit dem FMS-System 10 nicht permanent verbunden ist, hergestellt werden, so daß das FMS-System 10 eine gewünschte Änderung in der intelligenten Einrichtung vornehmen kann. Alternativ kann ein sekundäres FMS-System 46 zuerst mit dem primären FMS-System 10 verbunden werden und Anweisungen empfangen, welche Änderung vorzunehmen ist, und das sekundäre FMS- System 46 kann dann von dem primären FMS-System 10 getrennt und statt dessen mit der intelligenten Einrichtung verbunden werden, so daß das sekundäre FMS-System 46 die von dem primären FMS-System 10 angewiesene Änderung vornehmen kann.
Wenn das primäre FMS-System 10 Anweisungen an ein sekundäres FMS-System 46 sendet, um eine Änderung durchzuführen, sendet das primäre ENS-System 10 auch den "erwarteten" Zustand der Einrichtung zusammen mit Anweisungen für die vorzunehmende Änderung (d. h. den Namen des Parameters, der geändert werden soll, und den neuen Wert für diesen Parameter) an das sekundäre FMS-System 46.
Nachdem das sekundäre FMS-System oder der Laptop-Computer 46 mit Änderungsanweisungen von dem primären FMS-System beladen ist, nimmt ein Techniker das sekundäre FMS-System 46 mit ins Feld und verbindet es mit den intelligenten Feldeinrichtungen 16, 18, 20 und/oder 22 usw. des Prozesses, an denen Änderungen durchzuführen sind, und führt die nachstehende Änderungsoperation aus (Fig. 7).
Fig. 7 ist ein Flußdiagramm, das zeigt, wie ein FMS-System 10 mit der Transaktionsdatenbank 200 in Dialog tritt, wenn eine Änderung an einer intelligenten Einrichtung 16, 18, 20 oder 22 in dem Prozeß 12 durchgeführt wird. Selbstverständlich kann das FMS-System 10 eine Einrichtung nur dann ändern, wenn es mit der Einrichtung entweder elektrisch oder über eine andere geeignete Kommunikationsart verbunden ist. Wie oben gesagt, kann ein FMS-System 10 eine permanente Verbindung oder eine Übergangsverbindung mit einer Feldeinrichtung haben. Eine Übergangsverbindung zwischen einem sekundären FMS-System 46 und dem FMS-System 10 ist durch eine Strichlinie 47 in Fig. 1 gezeigt, und eine weitere derartige Verbindung ist zwischen einem sekundären FMS-System 46 (das zusätzlich oder alternativ einen mobilen Kommunikator 46 darstellen kann) und einer Feldeinrichtung 20 dargestellt. Wenn ein FMS-System 10 permanent mit einer Feldeinrichtung verbunden ist, kann es selbst Änderungen an der Feldeinrichtung vornehmen. Wenn die Einrichtung nicht permanent mit dem FMS-System 10 verbunden ist, kann das FMS- System 10 verwendet werden, um auf zwei mögliche Arten eine Änderung in der Feldeinrichtung vorzunehmen. Erstens kann die Feldeinrichtung zu dem Ort des FMS-Systems 10 transportiert und über eine Übergangsverbindung an eine serielle Schnittstelle oder einen anderen Port des FMS- Systems 10 angeschlossen werden, so daß wiederum das FMS- System 10 selbst die Änderung vornehmen kann. Zweitens kann, wenn die direkte Ankopplung der Einrichtung an das FMS- System 10 impraktikabel oder umständlich ist, ein sekundäres FMS-System 46 (Fig. 1) kurzzeitig mit dem FMS-System 10 verbunden oder in Dialog gebracht und von dem FMS-System 10 angewiesen wenden, die erforderlichen Änderungen vorzunehmen. Das sekundäre FMS-System 46 wird dann von dem FMS-System 10 getrennt und von einem Feldtechniker zu jeder entfernten Feldeinrichtung gebracht, in der eine Änderung vorzunehmen ist. Der Techniker schließt das sekundäre FMS- System 46 an die Feldeinrichtung an, und das sekundäre FMS- System 46 nimmt die Änderung ebenso vor, wie dies das FMS- System 10 tun würde.
Nachstehend werden der Einfachheit halber das FMS-System 10 und das sekundäre FMS-System 46 gelegentlich als das primäre FMS-System bzw. das sekundäre FMS-System bezeichnet. Es ist zu beachten, daß diese Bezeichnungen nur willkürliche Bezeichnungen sind und daß Struktur und Funktion des primären und des sekundären FMS-Systems äquivalent sein können oder daß das sekundäre FMS-System im Vergleich mit dem primären FMS-System reduzierte Funktionalität haben kann, falls das gewünscht wird.
Der Ablauf, nach dem ein FMS-System (primär oder sekundär) eine oder mehrere Änderungen an einem oder mehreren Parametern in einer intelligenten Feldeinrichtung wie etwa den HART-Einrichtungen 16, 18, 20 oder der Fieldbus- Einrichtung 22 (Fig. 1) vornimmt, wird nachstehend unter Bezugnahme auf Fig. 7 im einzelnen beschrieben.
Der Vorgang der Durchführung einer Änderung beginnt an einem Block 220, an dem das FMS-System 10 oder 46 mit der intelligenten Feldeinrichtung verbunden wird, an der eine Änderung vorzunehmen ist, und den aktuellen Zustand dieser Einrichtung abruft durch Erhalten von Werten von der Einrichtung für sämtliche Parameter des speziellen Blocks, an dem die Änderung vorgenommen werden soll. Ein Block 222 vergleicht dann den aktuellen Zustand der Einrichtung mit dem erwarteten Zustand der Einrichtung, der, wie oben beschrieben, in dem FMS-System 10 gespeichert wurde, bevor das FMS-System 10 mit der Einrichtung verbunden wurde. Wenn das primäre FMS-System 10 ein sekundäres FMS-System 46 anweist, eine Änderung an einer Ein richtung vorzunehmen, übermittelt das primäre FMS-System 10 den erwarteten Zustand dieser Einrichtung an das sekundäre FMS-System 46.
Wenn der Block 222 bestimmt, daß der aktuelle Zustand der Einrichtung gleich dem erwarteten Zustand ist, veranlaßt ein Block 224 das FMS-System 10, die nächste Änderung an der Einrichtung vorzunehmen, und ein Block 226 fügt eine Aufzeichnung dieser Änderung zu der Transaktionsdatenbank 200 hinzu (Fig. 5). Wenn der Block 222 bestimmt, daß der aktuelle Zustand der Einrichtung nicht gleich dem erwarten Zustand der Einrichtung ist, dann berechnet ein Block 228, bevor der Block 224 die Änderung an der Einrichtung vornimmt, eine "unerwartete" Änderung und fügt eine Aufzeichnung der unerwarteten Änderung zu der Transaktionsdatenbank 200 hinzu, so daß die Transaktionsdatenbank 200 den momentanen Zustand der Einrichtung, wie er vorliegt, bevor das FMS-System 10 die Änderung vornimmt, exakt wiedergibt.
Dabei ist die unerwartete Änderung die Änderung, die (ohne Wissen des FMS-Systems 10) notwendigerweise erfolgt sein muß, um den Zustand der Einrichtung von dem Zustand, in dem das FMS-System 10 die Einrichtung erwartete, in den aktuellen Zustand zu ändern, in dem das FMS-System 10 die Einrichtung vorgefunden hat. Nachdem die Aufzeichnung der "unerwarteten" Änderung der Transaktionsdatenbank 200 hinzugefügt worden ist, erlaubt ein Block 230 dem Bediener des FMS-Systems 10, zusätzliche Änderungen an der Einrichtung vorzunehmen, und wenn irgendwelche derartigen zusätzlichen Änderungen vorgenommen werden, speichert das FMS-System 10 Transaktionsaufzeichnungen in seiner Transaktionsdatenbank 200, die die zusätzlichen Änderungen darstellen. Diese zusätzlichen Änderungen werden in der Transaktionsdatenbank 200 als "erwartete" Änderungen gekennzeichnet.
Danach geht die Steuerung zu dem Block 224, der, wie oben beschrieben, die nächste Änderung an die Einrichtung führt. Nachdem eine Aufzeichnung dieser Änderung zu der Transaktionsdatenbank 200 des FMS-Systems 10 durch den Block 226 hinzugefügt ist, bestimmt ein Block 232, ob das FMS- System 10 weitere Änderungen an der Einrichtung, mit der es verbunden ist, vornehmen muß. Wenn das so ist, erfolgt Rücksprung der Steuerung zu Block 222, um den vorstehenden Ablauf für die nächste Änderung zu wiederholen; andernfalls endet der Ablauf von Fig. 7.
Zusätzlich dazu, daß das primäre FMS-System 10 ein sekundäres FMS-System anweist, Änderungen vorzunehmen, kann es auch Änderungsanweisungen an einen mobilen, eigensicheren Kommunikator 46 herunterladen, etwa den Kommunikator Modell 275-HC HART, der von Fisher-Rosemount Systems, Inc. hergestellt wird. Ein solcher mobiler Kommunikator 46 wird von einem Techniker im Feld verwendet, um Änderungsinformation zu einer HART-Feldeinrichtung zu bringen, die sich in einer Region, die von dem primären FMS- System entfernt ist, und/oder in einer Gefahrenzone befindet, in der eigensichere Instrumente erforderlich sind (sekundäre (Laptop)FMS-Systeme sind in solchen Gefahrenzonen nicht brauchbar). Der Bediener kann den mobilen Kommunikator 46 mit der intelligenten HART-Feldeinrichtung verbinden, um die Änderungen vorzunehmen.
Der Prozeß, nach dem eine Änderung an einer intelligenten Feldeinrichtung unter Verwendung eines mobilen Kommunikators 46 (Fig. 1) vorgenommen wird, wird nachstehend im einzelnen in Verbindung mit Fig. 8 beschrieben.
Zuerst wird, wie Fig. 1 zeigt, ein mobiler Kommunikator 46 mit dem FMS-System 10 verbunden, und das FMS-System 10 speichert eine Konfiguration für eine bestimmte Einrichtung in dem Speicher des mobilen Kommunikators 46, wie ein Block 240 zeigt (Fig. 8). Natürlich können nach Wunsch in dem mobilen Kommunikator 46 eine Vielzahl von Konfigurationen für eine Vielzahl von Einrichtungen gespeichert werden. Außerdem kann der mobile Kommunikator 46 Konfigurationsinformation von einem sekundären FMS-System 46 auf die gleiche Weise empfangen, wie er Konfigurationsinformation von dem primären FMS-System 10 entsprechend Fig. 1 empfängt.
Nachdem Konfigurationsinformation für eine oder mehrere intelligente Feldeinrichtungen 16, 18, 20, 22 in den mobilen Kommunikator 46 geladen wurde, wird der mobile Kommunikator 46 mit einer der intelligenten Einrichtungen verbunden, und der Kommunikator 46 führt die neue Konfiguration für diese Einrichtung an die Einrichtung, wie Block 242 zeigt.
Eine Konfiguration umfaßt insgesamt die gleiche Information wie eine Änderung, die oben in Verbindung mit dem primären und sekundären FMS-System 10 und 46 angegeben wurde. Außerdem kann eine Konfiguration neue Werte entweder für einen (partielle Konfiguration) oder alle (volle Konfiguration) Parameter einer Einrichtung aufweisen. Der Unterschied zwischen einer Konfiguration und einer Änderung ist einfach, daß eine Konfiguration im Gegensatz zu einer Änderung keine. Zeitangabe enthält. Der Grund für diesen Unterschied ist, daß Kostenbeschränkungen bei mobilen Kommunikatoren. 46 und der Wunsch, daß sie sehr einfach zu verwenden sind, verhindern, daß sie eine Zeitkontrollfunktion ermöglichen. Daher ist der Ablauf von Fig. 8, nach dem ein mobiler Kommunikator 46 eine Änderung an einer Einrichtung vornimmt, im Vergleich mit dem Ablauf von Fig. 7, nach dem ein FMS-System 10 eine solche Änderung vornimmt, recht einfach. Infolgedessen sind jedoch die Operationen, die von einem mobilen Kommunikator ausgeführt werden können, recht anspruchslos im Vergleich mit den Operationen eines FMS-Systems 10.
Fakultativ kann der mobile Kommunikator 46, wie ein Block 244 in Strichlinien in Fig. 8 zeigt, den Gesamtzustand der Einrichtung, mit der er verbunden ist, Kontrollesen und diesen Zustand an das primäre FMS-System 10 (oder ein sekundäres FMS-System 46) rückmelden, so daß das FMS-System 10 oder 46 den neuen Zustand der Einrichtung mit der Transaktionsdatenbank 200 des FMS-Systems in Einklang bringen kann. Typischerweise kann eine Anlage diese Vorgehensweise als Teil eines Standardbetriebsablaufs in Situationen verlangen, in denen es wichtig ist sicherzustellen, daß die Änderungen, deren Durchführung durch einen mobilen Kommunikator 46 ein FMS-System 10 befiehlt, tatsächlich ausgeführt werden. Es ist ferner wichtig, daß dann, wenn ein FMS-System 10 eine Konfiguration an einen mobilen Kommunikator 46 übermittelt, das FMS-System 10 eine Transaktion in seine Transaktionsdatenbank 200 einfügt, um die der Konfiguration entsprechende Änderung wiederzugeben. Die Transaktionsaufzeichnung wird als eine erwartete Änderung bezeichnet, weil das FMS-System 10 davon ausgeht, daß der mobile Kommunikator 46 die Änderung tatsächlich ausführt.
Wie oben beschrieben wird, kann eine Vielzahl von FMS- Systemen miteinander verbunden werden, so daß die Daten in ihren jeweiligen Transaktionsdatenbanken 200 vereinigt werden können, um eine konsistente Gesamtansicht der Anlage zu bilden, die von der Vielzahl von FMS-Systemen bedient wird. Diese Fähigkeit erleichtert die Betrachtung von historischer Information über den Betrieb einer Anlage etwa durch Auditoren, die dafür verantwortlich sind, daß die Anlage den gesetzlichen Bestimmungen verschiedener Regierungsbehörden entspricht, wie oben beschrieben wurde, und auch den Richtlinien oder Regeln folgt, die von Sicherheitsgruppen der Anlagen aufgestellt wurden.
Fig. 9 ist ein Flußdiagramm, das einen Ablauf zeigt, nach dem die Transaktionsdatenbank 200 eines FMS-Systems (z. B. eines sekundären FMS-Systems 46) mit der Transaktionsdatenbank 200 eines anderen FMS-Systems (z. B. eines primären FMS-Systems 10) vereinigt wird. Wie bereits gesagt wurde, kann jedes FMS-System als ein primäres oder sekundäres System dienen, aber die Bezeichnung "primäres FMS" bezieht sich typischerweise auf ein ortsfestes System; sekundäre FMS-Systeme befinden sich typischerweise in Laptops, die nicht immer leicht zugänglich sind, wenn sie etwa für ein Übereinstimmungs-Audit benötigt werden. In der nachstehenden Beschreibung beziehen sich die Bezeichnungen FMS1 und FMS2 auf die Transaktionsdatenbanken 200 des primären bzw. des sekundären FMS-Systems.
Zuerst beurteilt ein Block 250, ob in dem sekundären FMS- System 46 irgendwelche nicht abgestimmten Transaktionsaufzeichnungen vorhanden sind. Wenn nicht, oder wenn alle nichtabgestimmten Transaktionen in dem sekundären FMS-System 46 abgestimmt wurden, ist der Ablauf von Fig. 9 beendet. Wenn in dem sekundären FMS-System 46 nichtabgestimmte Transaktionen verbleiben (d. h. Transaktionsaufzeichnungen, die noch nicht mit der Transaktionsdatenbank 200 des primären FMS-Systems 10 abgestimmt wurden), lädt ein Block 252 die nächste nichtabgestimxrte Transaktionsaufzeichnung (nachstehend als TR bezeichnet) aus dem Speicher des sekundären FMS-Systems 46 in den Speicher des primären FMS-Systems 10. Ein Block 254 prüft dann die Transaktionsaufzeichnung TR, um zu beurteilen, ob die durch diese Transaktionsaufzeichnung dargestellte Änderung eine erwartete Änderung ist. Wenn ja, dann beurteilt ein Block 256, ob die Transaktionsaufzeichnung RT die gleiche Änderung wie eine Änderung darstellt, die in der primären FMS- Transaktionsdatenbank FMS1 bereits vorhanden ist, jedoch als eine "unerwartete" Änderung in FMS1 bezeichnet ist. Wenn die durch die Transaktionsaufzeichnung TR dargestellte Änderung nicht mit einer unerwarteten Änderung in FMS1 übereinstimmt, dann wird die Transaktionsaufzeichnung TR in chronologischer Folge in die primäre FMS-Transaktionsdatenbank FMS1 eingefügt, und es erfolgt Rücksprung der Steuerung zu Block 250, um zu beurteilen, ob weitere nichtabgestimmte Transaktionsaufzeichnungen in dem sekundären FMS-System 46 verbleiben. Wenn die durch die Transaktionsaufzeichnung TR dargestellte Änderung mit einer in der Transaktionsdatenbank FMS1 vorhandenen unerwarteten Änderung übereinstimmt, was durch Block 256 bestimmt wird, dann ersetzt ein Block 260 diese unerwartete Änderung durch die Transaktionsaufzeichnung TR (die eine erwartete Änderung ist), und es erfolgt Rücksprung der Steuerung zu Block 250.
Wenn andererseits der Block 254 beurteilt, daß die Transaktionsaufzeichnung TR eine nicht erwartete Änderung darstellt, geht die Steuerung zu einem Block 262, der beurteilt, ob die primäre FMS-Transaktionsdatenbank FMS1 eine Transaktionsaufzeichnung enthält, die die Zuordnung des gleichen Werts zu dem gleichen Parameter wie die durch die Transaktionsaufzeichnung TR dargestellte Änderung repräsentiert, und ob diese Transaktionsaufzeichnung einen TimeKey (Feld 205, Fig. 6) trägt, der dem TimeKey der Transaktionsaufzeichnung TR annähernd innerhalb einer vorbestimmten akzeptablen zeitlichen Toleranz entspricht. Wenn keine solche Transaktionsaufzeichnung in FMS1 vorhanden ist, fügt ein Block 264 die Transaktionsaufzeichnung TR an das Ende der primären FMS-Transaktionsdatenbank FMS1 an und bezeichnet die durch diese Transaktionsaufzeichnung dargestellte Änderung als "unerwartet" durch entsprechendes Setzen des Expected-Felds 213 der Aufzeichnung 202, die dieser Änderung entspricht, in der FMS-Transaktionsdatenbank FMS1. Danach erfolgt Rücksprung der Steuerung zu Block 250, um nach weiteren nichtabgestimmten Transaktionsaufzeichnungen 202 in dem sekundären FMS-System 46 zu suchen. Wenn der Block 262 beurteilt, daß eine Änderung, die der unerwarteten Änderung gleicht, die durch die Transaktionsaufzeichnung TR dargestellt ist, bereits in der primären EMS-Transaktionsdatenbank FMS1 erscheint, verwirft ein Block 266 die Transaktionsaufzeichnung TR insofern, als die der unerwarteten Transaktionsaufzeichnung TR entsprechende tatsächliche Änderung bereits durch eine Transaktionsaufzeichnung 202 in der Transaktionsdatenbank FMS1 repräsentiert ist. Wiederum erfolgt Rücksprung der Steuerung zu Block 250, um weitere nichtabgestimmte Transaktionen in dem sekundären EMS-System 46 zu suchen.
Nachstehend werden mehrere Beispiele der Anwendung der FMS- Transaktionsdatenbank 200 im einzelnen in Verbindung mit den beigefügten Tabellen beschrieben. In dem ersten Beispiel weist ein primäres FMS-System 10 (P_FMS) ein sekundäres FMS- System 46 (S_FMS) an, eine zukünftige Änderung CF (d. h. eine Änderung, für die noch keine Zeit angegeben ist) an einer bestimmten intelligenten Feldeinrichtung vorzunehmen (siehe die Tabelle mit der Bezeichnung "Beispiel 1"). Dieses Beispiel zeigt, was an dem primären und dem sekundären FMS- System und an der Einrichtung geschieht, wenn diese Anweisung ausgeführt wird und das Ergebnis von dem sekundären FMS-System 46 an das primäre FMS-System zurück berichtet wird. Beispiel 1
Die erste Reihe der obigen Tabelle beschreibt das primäre und das sekundäre FMS-System in der Feldeinrichtung zu einem willkürlichen Zeitpunkt i. Zum Zeitpunkt i ist der Istzustand der Einrichtung S(i), und dieser Zustand spiegelt sich exakt in den Transaktionsdatenbanken 200 des primären FMS-Systems 10 und des sekundären FMS-Systems 46 wider.
Zu einem späteren Zeitpunkt i + 1 weist das primäre FMS-System 10 das sekundäre FMS-System 46 an, eine zukünftige Änderung an der Einrichtung vorzunehmen. Daher bleibt zu diesem Zeitpunkt die Einrichtung in dem Zustand S(i). Weiterhin fahren die primäre und die sekundäre FMS- Transaktionsdatenbank P_FMS und S_FMS fort, exakt wiederzugeben, daß der Istzustand der Einrichtung S(i) ist, aber die Transaktionsdatenbank 200 des sekundären FMS- Systems 46 hält nun eine Transaktionsaufzeichnung 202, die die zukünftige Änderung CF darstellt.
Zu einem noch späteren Zeitpunkt wird das sekundäre FMS- System 46 mit der Einrichtung verbunden und versucht, die zukünftige Änderung, die mit C(i + 1) bezeichnet ist, an der Einrichtung vorzunehmen. Da das sekundäre FMS-System 46 detektiert, daß der vorherige Istzustand S(i) der Einrichtung mit dem Zustand S(i) übereinstimmt, den das sekundäre FMS-System 46 für die Einrichtung erwartete, nimmt das sekundäre FMS-System 46 die Änderung an der Einrichtung vor und zeichnet in seiner Transaktionsdatenbank S_FMS eine Transaktionsaufzeichnung 202 entsprechend der Änderung auf. Da die Änderung an der Einrichtung vorgenommen wurde, ist die Einrichtung nunmehr in dem Zu stand S(i + 1), und die Transaktionsaufzeichnung für diese Änderung (die im übrigen als eine erwartete Änderung in der Transaktionsdatenbank 200 bezeichnet ist) ist der erwartete Zustand der Einrichtung, der sich in der Transaktionsdatenbank 200 des sekundären FMS-Systems 46 widerspiegelt, und wird ebenfalls zu S(i + 1) aktualisiert. Da jedoch das primäre FMS-System 10 noch nicht informiert würde, daß das sekundäre FMS 46 die zukünftige Änderung CF mit Erfolg durchgeführt hat, hält das primäre FMS-System 10 S(i) als den erwarteten Zustand für die Einrichtung.
Wenn das sekundäre FMS-System 46 zum Zeitpunkt i + 3 mit dem primären FMS-System 10 verbunden wird und die Transaktionsaufzeichnung, die der Änderung C(i + 1) entspricht, an das primäre FMS-System 10 übermittelt, stimmt das primäre FMS-System 10 diese Transaktionsaufzeichnung mit seiner primären FMS-Transaktionsdatenbank 200 ab, wie oben in Verbindung mit dem Ablauf von Fig. 9 beschrieben wird. Weil die ankommende Transaktionsaufzeichnung als eine erwartete Änderung bezeichnet war und weil die Änderung noch nicht in die primäre FMS-Transaktionsdatenbank 200 als eine unerwartete Änderung eingegeben war (wobei angenommen wird, daß sie wirklich keine solche war), wird die Transaktionsaufzeichnung für die Änderung C(i + 1) in die primäre FMS-Transaktionsdatenbank 200 in chronologischer Folge durch den Block 258 eingefügt (Fig. 9), so daß der erwartete Zustand der Einrichtung, wie er nunmehr durch die Transaktionsdatenbank 200 des primären FMS-Systems 10 wiedergegeben wird, exakt dem Istzustand der Einrichtung, nämlich S(i + 1), entspricht.
Wenn statt dessen, als die die Änderung C(i + 1) darstellende Transaktionsaufzeichnung mit der primären FMS- Transaktionsdatenbank 200 abgestimmt wurde, bestimmt wurde, daß eine passende unerwartete Änderung in der primären FMS- Transaktionsdatenbank 200 vorhanden war, dann wäre die Transaktionsaufzeichnung für die erwartete Änderung C(i + 1) anstelle der Transaktionsaufzeichnung 202 für die entsprechende unerwartete Änderung in die primäre FMS- Transaktionsdatenbank 200 aufgenommen worden.
Ein weiteres Beispiel, das die Abstimmung einer Transaktionsaufzeichnung 202 in der FMS- Transaktionsdatenbank 200 verdeutlicht, die eine "unerwartete" Änderung darstellt, wird nachstehend im einzelnen unter Bezugnahme auf die folgende Tabelle "Beispiel 2" beschrieben. Beispiel 2
In diesem Beispiel zeigen ein primäres FMS-System 10 und zwei sekundäre FMS-Systeme 46 exakt den Istzustand S(i) einer Einrichtung zu einem Anfangszeitpunkt i.
Zu einem späteren Zeitpunkt i + 1 weist das primäre FMS-System 10 das erste sekundäre FMS (FMS1) an, eine Änderung C(i + 1) an einer Einrichtung vorzunehmen. Ebenfalls zu diesem Zeitpunkt weit das primäre FMS-System 10 das zweite sekundäre FMS (FMS2) an, an derselben Einrichtung eine zukünftige Änderung CF vorzunehmen. Daher zeigen zum Zeitpunkt i + 1 die Transaktionsdatenbanken 200 des primären FMS-Systems und des ersten und zweiten sekundären FMS-System exakt den Istzustand S(i + 1) der Einrichtung an. Außerdem wird eine Aufzeichnung der Änderung C(i + 1) in dem ersten sekundären FMS-System 46 gespeichert, und eine Aufzeichnung der zukünftigen Änderung CF wird in dem zweiten sekundären FMS-System 46 gespeichert.
Zu einem späteren Zeitpunkt i + 2 nimmt FMS1 die Änderung C(i + 1) an der Einrichtung entsprechend dem Ablauf vor, der oben in Verbindung mit Fig. 7 beschrieben wird. Somit zeigt zu diesem Zeitpunkt FMS1 exakt den Istzustand S(i + 1) in seiner Transaktionsdatenbank 200, während das primäre FMS P_FMS und das sekundäre FMS FMS2 weiterhin den vorherigen Zustand S(i) der Einrichtungen in ihren jeweiligen Transaktionsdatenbanken 200 zeigen. Außerdem hält FMS2 noch eine Transaktionsaufzeichnung für die zukünftige Änderung CF, die noch nicht vorgenommen wurde.
Zu einem späteren Zeitpunkt i + 3 versucht FMS2, die zukünftige Änderung CF an der Einrichtung vorzunehmen, und detektiert, daß die Einrichtung sich in einem unerwarteten Zustand S(i + 1) befindet (d. h. einem anderen Zustand als dem Zustand S(i), den die Transaktionsdatenbank 200 von FMS2 zeigt). FMS2 berechnet daher die unerwartete Änderung CU, die vorgenommen worden sein muß, um den Einrichtungszustand von S(i) (erwartet von FMS2) zu S(i + 1) (den Istzustand der Einrichtung) zu ändern. FMS2 macht dann eine Transaktionsaufzeichnung entsprechend der unerwarteten Änderung CU in seiner Transaktionsdatenbank 200 und nimmt dann die zukünftige Änderung CF an der Einrichtung vor und erstellt eine Transaktionsaufzeichnung entsprechend der Änderung CF gemeinsam mit einem aktuellen TimeKey in der Transaktionsdatenbank 200 von FMS2. Daher zeigt die Transaktionsdatenbank 200 von FMS2 nunmehr exakt den aktuellen Zustand S(i + 2) der Einrichtung, und die Transaktionsdatenbank 200 von FMS2 enthält ferner eine Aufzeichnung der unerwarteten Änderung CU, von der FMS2 erkannt hat, daß sie an der Einrichtung vorgenommen wurde.
Noch später zu einem Zeitpunkt i + 4 wird das sekundäre FMS- System FMS2 mit dem primären FMS-System 10 verbunden und berichtet die unerwartete Änderung CU und die nunmehr vorgenommene autorisierte Änderung C(i + 2) an das primäre FMS-System 10. Die Transaktionsaufzeichnungen für diese beiden Änderungen werden dann von dem primären FMS-System 10 in seiner Transaktionsdatenbank entsprechend dem Ablauf von Fig. 9 in Abstimmung gebracht, so daß die Transaktionsdatenbank 200 des primären FMS-Systems 10 den Istzustand S(i + 1) der Einrichtung genau zeigt und Transaktionsaufzeichnungen aufweist, die den Änderungen CU und C(i + 2) entsprechen. Das sekundäre FMS1 zeigt noch, daß es für die Einrichtung einen Zustand S(i + 1) erwartet, während das sekundäre FMS2 den Istzustand S(i + 1) der Einrichtung exakt wiedergibt.
Zu einem noch späteren Zeitpunkt i + 5 wird FMS1 mit dem primären FMS-System 10 verbunden und berichtet die Änderung C(i + 1). Das primäre FMS-System 10 bringt die Transaktionsaufzeichnung für die Änderung C(i + 1) in seiner Transaktionsdatenbank 200 in Abstimmung und stellt fest, daß C(i + 1) mit der unerwarteten Änderung CU übereinstimmt, die während der Zeit i + 4 in die Transaktionsdatenbank 200 des primären FMS-Systems 10 eingestellt wurde. Entsprechend dem Block 260 (Fig. 9) ersetzt daher die Transaktionsaufzeichnung für die Änderung C(i + 1) die Transaktionsaufzeichnung für die unerwartete Änderung CU in der Transaktionsdatenbank 200 des primären FMS-Systems 10. Daher sind zu diesem Zeitpunkt sämtliche offenen Transaktionsaufzeichnungen 202 in der Transaktionsdatenbank 200 des primären FMS-Systems in Abstimmung gebracht, die nunmehr den tatsächlichen Istzustand S(i + 2) der Einrichtung und außerdem, was sehr wichtig ist, eine vollständige historische Darlegung der Konfigurationshistorie der Einrichtung (d. h. eine Einrichtungs-Konfigurationshistorie) genau wiedergibt.
Die Funktionalität des Schnittstellenblocks 58 wird nachstehend im einzelnen beschrieben. Wie oben gesagt, ruft im Betrieb die aktuelle Anwendung 56 den Schnittstellenblock 58 auf, um eine oder mehrere bestimmte Steuerungen zu initialisieren, die danach alle Operationen, die mit dem Dialog zwischen dem Windows-Betriebssystem 46, den intelligenten Einrichtungen innerhalb des Prozesses 12 und/oder der FMS-Datenbank 40 in bezug auf eine Einrichtung, einen Block oder einen Parameter, der dem Prozeß 12 zugeordnet ist, automatisch managen. Der Schnittstellenblock 58 kann auch die Zeiteigenschaft des Root-Objekts, das in dem Speicher des Servernetzes 66 gespeichert ist, ändern, um Anzeigen auf eine vorteilhafte Weise zu steuern.
Jede Steuerung des Schnittstellenblocks 58 zeigt und aktualisiert Information, die eine Einrichtung, einen Block, einen Parameter oder einen Zeitpunkt auf dem Display 30 betrifft, und kommuniziert mit den intelligenten Einrichtungen, der Datenbank 40 und dem Servernetz 66 in Abhängigkeit von Anwender- oder Anwendungseingaben zum Abruf von Daten aus oder zum Schreiben von Daten zu den DDS 72, den intelligenten Einrichtungen, der Datenbank 40 oder dem Root-Objekt in dem Servernetz 66, ohne daß die aktuelle Anwendung 56 weiter damit befaßt ist. Dabei ist sehr wichtig, daß eine Steuerung, nachdem sie etabliert ist, im allgemeinen anscheinend unabhängig von der aktuellen Anwendung 56 und anderen Steuerungen, die vielleicht etabliert sind, abläuft.
Wie Fig. 11 zeigt, weist der Schnittstellenblock 58 eine Mastersteuerroutine 300 auf, die zur Implementierung von Steuerfunktionen verwendet werden kann, die Steuerfunktionen umfassen, die eine Einrichtung, einen Block oder einen Parameter, die mit dem Prozeß 12 assoziiert sind, betreffen. Der Schnittstellenblock 58 umfaßt ferner eine Masterzeitplansteuerroutine 301, die zur Implementierung von Steuerfunktionen wie Lese- und Schreibzeiten von dem Root- Objekt und Ändern von Zeitwerten von der Datenbank 40 dienen kann.
Wenn die aktuelle Anwendung 56 den Schnittstellenblock 58 zur Implementierung einer Einrichtungs-, Block-, Parameter- oder Zeitplansteuerung aufruft, wird eine der Mastersteuerroutinen 300 oder 301 tatsächlich kopiert und in eine bestimmte Steuerroutine oder Steuerung umgewandelt. Solche bestimmten Steuerungen sind in Fig. 11 als eine Einrichtungssteuerung 302, eine Blocksteuerung 304, eine Parametersteuerung 306 und eine Zeitplansteuerung 308 dargestellt. Die bestimmten Steuerungen 302, 304, 306 und 308 managen danach automatisch Funktionen, die mit der Kommunikation zwischen dem Windows-Betriebssystem 46, der aktuellen Anwendung 56, der Datenbank 40 (durch die DCI 60), dem DDS 72 (durch die DCI 60) und den intelligenten Online- Einrichtungen (durch die DCI 60) zusammenhängen, da diese Kommunikationen die bestimmten Einrichtungen, Blöcke, Parameter oder Zeitpläne betreffen, für die die Steuerungen geschaffen werden. Nachdem sie erstellt sind, ist jede der Steuerungen 302, 304, 306, 308 kontinuierlich und unabhängig von den übrigen Steuerungen und der aktuellen Anwendung 56 wirksam. Jede Anzahl der gleichen und/oder verschiedenen Steuerungstypen kann implementiert werden, um gleichzeitig wirksam zu sein.
Fig. 11 zeigt zwar die Steuerungen 302, 304, 306 und 308 als separate Routinen, die Kopien von einer der Mastersteuerroutinen 300 oder 301 sind, aber die Steuerungen 302, 304, 306, 308 können auch die Daten enthalten, die erforderlich sind, um eine bestimmte Einrichtungs-, Block-, Parameter- oder Zeitplansteuerung unter Nutzung einer der Mastersteuerroutinen 300 oder 301 zu implementieren.
Fig. 12 zeigt allgemein die Schritte, die beispielsweise von der aktuellen Anwendung 56 durchgeführt werden sollten, um eine Steuerung einschließlich jeder der in Fig. 11 gezeigten Steuerungen zu implementieren. Ein Block 310 definiert die Art der Steuerung, beispielsweise eine Einrichtungs-, eine Block-, eine Parameter- oder eine Zeitplansteuerung, durch Versehen des Schnittstellenblocks 58 mit einem eindeutigen Moniker, der auf das OLE-Objekt innerhalb der Hierarchie der Fig. 3 und 4 verweist, mit dem die Steuerung assoziiert ist. Da konzeptuell eine Instanzierung der Hierarchie der Fig. 3 und 4 für jede für die FMS-Anwendung verfügbare Zeit existiert, bezeichnet die Zeitplansteuerung das Root-Objekt einer bestimmten Hierarchie, indem sie beispielsweise die Zeit und Ansicht des Root-Objekts bezeichnet, mit dem die Steuerung assoziiert ist.
Ein Block 311 definiert die Benutzeroberflächenattribute, was beispielsweise einschließt: die Schriften, Größen usw. von Displayzeichen, den Stil, in dem die Information anzuzeigen ist, den Ort des Displaybildschirms, an dem die Steuerinformation anzuzeigen ist, die ursprüngliche Fenstergröße der Steueranzeige, wenn die Größe einer Steueranzeige von dem Anwender änderbar ist, und die sogenannte "Sichtbarkeit" der Steuerung. Die Steuerungssichtbarkeit definiert, ob die Steuerung tatsächlich auf dem Bildschirm angezeigt oder sichtbar ist. Eine unsichtbare Steuerung ist zwar immer noch wirksam, um Daten von ihrem zugeordneten OLE-Objekt abzurufen, und kann diese Information an die aktuelle Anwendung 56 liefern, aber die die Benutzeroberfläche betreffenden Operationen dieser Steuerung sind einfach desaktiviert.
Ein Block 312 definiert die Auffrischrate der Steuerung (d. h. die Rate, mit der die Steuerung Information von ihrem zugeordneten OLE-Objekt in einem periodischen Lesevorgang empfängt). Tatsächlich verbindet der Block 312 die Steuerung mit einem bestimmten Root-Objekt der Hierarchie der Fig. 3 und 4, und das Root-Objekt definiert die Rate, mit der das OLE-Objekt Daten äls Reaktion auf eine periodische Leseoperation auffrischt.
Fig. 13 zeigt die allgemeine Operation einer Steuerroutine, die für die Einrichtungssteuerung, die Blocksteuerung, die Parametersteuerung und die Zeitplansteuerung von Fig. 11 angewandt werden kann. Ein Block 313 wird verbunden bzw. stellt eine Verbindung her mit dem richtigen OLE-Objekt gemäß der Definition durch die Hierarchie der Fig. 3 und 4 und dem Moniker, der von der aktuellen Anwendung 56 bereitgestellt wird. Dabei sendet die Steuerung einen Befehl durch die DCI 60 an das Servernetz 66, Information wie beispielsweise die Eigenschaften des OLE-Objekts zu lesen, das der Steuerung zugeordnet ist. Bevorzugt ist dieser Befehl ein periodisches Lesen, das dem OLE-Objekt wie etwa einem Einrichitungs-, einem Block- oder einem Parameterobjekt mitteilt, daß es die angeforderten Daten periodisch an die Steuerung senden soll.
Als Reaktion auf das Lesen stellt das Servernetz 66 eine Verbindung mit dem OLE-Objekt durch Abrufen von dessen Daten von dem DDS 72, den intelligenten Einrichtungen und/oder der Datenbank 40 her und speichert diese Daten als das OLE- Objekt in einem Servernetzspeicher. Zur Durchführung dieser Lesefunktion muß das Servernetz 66 jedoch in seinem Speicher auch die Daten speichern, die die Einrichtungs- und/oder Blockobjekte über dem angeforderten OLE-Objekt gemäß der Definition durch die Hierarchie der Fig. 3 und 4 betreffen. Nach Speicherung in dem Serverspeicher werden die angeforderten OLE-Objektdaten an die DCI 60 und dann zu dem Schnittstellenblock 58 übermittelt, wo diese Daten in einem Speicher oder Steuercache, der dem Schnittstellenblock 58 zugeordnet ist, gespeichert werden können.
Ein Block 314 etabliert oder initialisiert dann einen Benutzeroberflächenbildschirm an dem Display 30 für die spezielle Steuerung gemäß der Definition durch die Benutzeroberflächenattribute, die an die Steuerung von dem Block 311 von Fig. 12 übermittelt wurden. Die Displayattribute können so konfiguriert sein, daß Steuerinformation auf jede gewünschte Weise unter Anwendung von Windows-Standardaufrufen und Windowsformaten angezeigt wird. Ein beispielhafter Bildschirm für jede der Einrichtungs-, Parameter-, Block- und Zeitplansteuerungen ist in den Fig. 20-22 gezeigt.
Als nächstes fragt ein Block 315 ab, ob von der Anwendung, der Benutzeroberfläche über das Windows-Betriebssystem 46 oder einen OLE-Block durch die DCI 60 irgendwelche Meldungen empfangen wurden. Wenn keine solchen Meldungen empfangen wurden, führt der Block 315 kontinuierlich eine erneute Prüfung auf solche Meldungen durch. Wenn der Block 315 eine Meldung empfängt, wird die Steuerung entsprechend den Kennzeichnungen 1, 2 und 3 übertragen.
Fig. 14 zeigt die Operation einer Steuerung als Reaktion auf eine Meldung von der aktuellen Anwendung 56. Ein Block 316 interpretiert die Meldung, die einer von drei allgemeinen Typen sein kann, und zwar eine OLE-Objektdaten-Lesen- Meldung, eine Parameterobjektwert-Ändern-Meldung oder eine Root-Objektwert-Meldung und eine Benutzeroberfläche-Ändern- Meldung. Aufgrund einer OLE-Objektdaten-Lesen-Meldung liest ein Block 318 die angeforderten Daten aus dem entsprechenden OLE-Objekt der Fig. 3 und 4. Beispielsweise kann eine Einrichtungssteuerung die DeviceID-Eigenschaft oder die "Tag"-Sammlung eines Device-Objekts lesen, während eine Blocksteuerung die Name-Eigenschaft oder die "Param"- Sammlung eines Blockobjekts liest. Eine Parametersteuerung könnte Parametereigenschaften wie den Wert oder den Namen eines VariableParameter-Objekts lesen. Eine Zeitplansteuerung kann Root-Objekteigenschaften lesen und von der Datenbank 40 eine Liste von Zeiten erhalten, in denen Root-Objekte in der Vergangenheit existieren. Danach erfolgt Rücksprung der Steuerung von Block 318 zu Block 315.
Als Reaktion auf eine Parameter-Ändern-Meldung oder Root- Objektwert-Meldung implementiert ein Block 320 eine Änderung an dem bezeichneten Parameterobjekt, beispielsweise dem VariableParameter-Objekt, dem RecordParameter-Objekt oder dem ArrayParameter-Objekt von Fig. 4, und die Steuerung springt zu Block 315 zurück. Als Reaktion auf eine Benutzeroberfläche-Ändern-Meldung implementiert ein Block 322 eine Änderung der Benutzeroberfläche, und die Steuerung springt zu Black 315 zurück.
Fig. 15 zeigt eine Routine 324, die von einer Steuerung während eines OLE-Objektdaten-Lesen-Ablaufs implementiert wird. Dabei sendet ein Block 326 eine Meldung durch die DCI 60 an das der Steuerung zugeordnete OLE-Objekt, um Daten von diesem OLE-Objekt abzurufen. Danach beurteilt ein Block 328, welche Art vor. Lesemeldung empfangen wurde. Wenn eine nichtblockierende, nichtperiodische oder eine nichtblockierende periodische Lesemeldung empfangen wurde, erfolgt Rücksprung der Steuerung von Block 328 zu dem Block, von dem die Routine 324 aufgerufen wurde. Eine nichtblockierende Leseoperation betrifft eine solche, bei der die Steuerung eine Lesemeldung an das der Steuerung zugeordnete OLE-Objekt sendet und nicht auf eine Antwort von dem OLE-Objekt wartet, bevor sie mit anderen Funktionen fortfährt. Eine nichtperiodische Leseoperation ist eine Anforderung für eine einzelne, einmalige Leseoperation von dem der Steuerung zugeordneten OLE-Objekt. Eine periodische Leseoperation weist das OLE-Objekt an, die Steuerung periodisch über Änderungen zu informieren, die an Daten innerhalb des OLE-Objekts auftreten, und zwar mit einer Rate, die innerhalb des dem OLE-Objekt zugeordneten Root- Objekts definiert ist.
Wenn jedoch die Leseoperation eine blockierende Leseoperation war, die immer eine nichtperiodische Leseoperation ist, wartet ein Block 330 auf die Rückdaten, die von dem OLE-Objekt angefordert wurden. Als nächstes speichert ein Block 332 die empfangenen OLE-Objektdaten in dem Steuercache. Erforderlichenfalls ändert ein Block 334 die Benutzeroberfläche durch Aufruf einer Benutzeroberfläche-Änderungsroutine, die noch beschrieben wird, um die durch die Leseoperation erhaltenen neuen Daten wiederzugeben. Ein Block 336 informiert die aktuelle Anwendung 56, wenn die Anwendung angezeigt hat, daß sie Meldungen oder Datenänderungen von OLE- Objektdatenleseoperationen beispielsweise während der Initialisierung der Steuerung empfangen möchte. Danach erfolgt Rücksprung der Steuerung zu dem jeweiligen Block, der die Routine 324 aufgerufen hat.
Fig. 16 zeigt eine Routine 338, die von einer Steuerung während einer Änderung eines Parameter- oder Rootwerts eines OLE-Parameterobjekts (etwa des VariableParameter-Objekts) oder eines Root-Objekts implementiert wird. Ein Block 340 beurteilt, ob der Parameter- oder Rootwert, der geändert werden soll, schreibbar ist. Im wesentlichen sendet der Block 340 eine Meldung zum Lesen der Verwaltungseigenschaften des OLE-Objekts und bestimmt, ob der Parameterwert schreibbar ist. Wenn der Block 340 beurteilt, daß der Parameter- oder Rootdatenwert nicht schreibbar ist, informiert ein Block 342 den Anwender oder die aktuelle Anwendung 56, daß der Parameter- oder Rootwert nicht schreibbar ist, indem beispielsweise die unten beschriebene Benutzeroberflächen-Änderungsroutine aufgerufen wird. Danach erfolgt Rücksprung der Steuerung zu dem Block, der die Routine 338 aufgerufen hat.
Wenn andererseits der Block 340 beurteilt, daß der Parameter- oder Rootwert schreibbar ist, beurteilt ein Block 344, ob der neue Parameterwert (oder Rootwert) ein akzeptierter Wert ist. Zur Durchführung dieser Funktion liest der Block 344 beispielsweise die Wertcharakteristiken des der Steuerung zugeordneten Parameterobjekts wie etwa den Minimalwert, den Maximalwert und die Art von akzeptiertem Wert, die beispielsweise eine Variable, eine Aufzählungsmenge usw. sein kann. Wenn danach der Block 344 beurteilt, daß der neue Wert außerhalb des Bereichs liegt oder vom falschen Typ ist, kann ein Block 346 eine Meldung an die Anwendung senden und/oder kann die Benutzeranzeige ändern und anzeigen, daß ein nichtakzeptabler Wert eingegeben wurde. Danach erfolgt Rücksprung der Steuerung zu dem Block, der die Routine 338 aufgerufen hat.
Wenn der Block 344 beurteilt, daß der neue Wert ein akzeptierter West für ein Parameter- oder Root-Objekt ist, sendet ein Block 348 eine Meldung an das richtige OLE- Parameter- oder Root-Objekt durch die DCI 60. Der neue Wert wird dann in dem OLE-Objekt geändert, was natürlich zu einer entsprechenden Änderung in einer intelligenten Einrichtung oder in der Datenbank 40 führen kann.
Ein Block 350 wartet auf eine Rückmeldung, und ein Block 352 decodiert die Rückmeldung, um zu beurteilen, ob die Schreiboperation erfolgreich war. Wenn die Schreiboperation erfolgreich war, kann ein Block 354 der Anwendung und/oder dem Anwender über die Benutzeroberfläche anzeigen, daß die Änderung vorgenommen wurde (beispielsweise durch Ändern der Hintergrundfarbe der Daten auf dem Bildschirm).
Wenn der Block 352 beurteilt, daß die Schreiboperation nicht erfolgreich war, zeigt ein Block 356 der Anwendung und/oder dem Anwender über die Benutzeroberfläche an, daß die Änderung nicht vorgenommen wurde (beispielsweise durch Ändern der Daten auf dem Bildschirm in ihren Originalzustand). Im übrigen sind die einem OLE-Objekt zugeordneten Antwortcodes ständig für eine Anwendung verfügbar, so daß der Grund für die Zurückweisung bestimmt und/oder für den Anwender angezeigt werden kann.
Wenn der Block 352 beurteilt, daß die Änderung zwar durchgeführt wurde, aber eine Schreibbedingung besteht, ruft ein Block 358 einen Antwortcode von dem OLE-Objekt durch spezielle Angabe einer richtigen Leseoperation von dem OLE- Objekt ab. Ein Block 360 zeigt dann der Anwendung und/oder, falls gewünscht, dem Anwender an, daß die Änderung vorgenommen wurde, aber eine Schreibbedingung besteht. Der Block 360 kann mich die Art von Bedingung anzeigen, die besteht (z. B. daß die OLE-Objekteigenschaft auf den nächstverfügbaren möglichen Wert eingestellt war). Jeder der Blöcke 354, 356 und 360 gibt die Steuerung an den Block zurück, der die Routine 338 aufgerufen hat.
Fig. 17 zeigt eine Routine 362, die von einer Steuerung zur Änderung des Benutzeroberflächendisplays implementiert wird. Ein Block 364 ändert die Displayattribute der Oberfläche im Zusammenhang mit neuen Attributen, die von der aktuellen Anwendung 56 vorgesehen werden, oder nach Maßgabe einer Menge von Attributen, die vorher von der Steuerung für die nunmehr existierende Bedingung definiert wurden. Diese vorher definierten Attribute können in einem der Steuerung zugeordneten Speicher wie etwa dem Steuercache gespeichert sein. Ein Block 366 frischt das Anwenderdisplay unter Verwendung der neuen Anwenderdisplayattribute und der Daten in dem Steuercache, die anzuzeigen sind, auf. Danach erfolgt Rücksprung der Steuerung zu dem Block, von dem aus die Routine 362 aufgerufen wurde.
Fig. 18 zeigt die Operation einer Steuerung als Antwort auf eine Meldung von der Benutzeroberfläche. Ein Block 370 beurteilt, ob die Anwenderaktion eine Bedeutung hat. Der Block 370 kann beispielsweise beurteilen, ob der Anwender die richtige Taste der Maus angeklickt hat oder ob der Zeiger (d. h. der Cursor oder Pfeil) innerhalb eines Bereichs des Steuerungsdisplays war, in dem die Steuerung die Aktionen des Anwenders als Anforderungen für eine Aktion erkennt. Wenn die Anwenderaktion bedeutungslos ist, ignoriert ein Block 372 einfach die Anwenderaktion oder zeigt irgendwie an, daß die Aktion ignoriert wird (z. B. durch Auffrischen des Anwenderdisplays mit den gleichen Displayoberflächenattributen). Danach erfolgt Rücksprung der Steuerung zu dem Block 315.
Wenn dagegen die Anwenderaktion bedeutsam ist, interpretiert ein Block 374 die Meldung von der Benutzeroberfläche. Wenn die Meldung von der Benutzeroberfläche anzeigt, daß der Benutzer einen Parameterwert oder einen Rootwert ändern möchte, ruft ein Block 376 die Parameteränderungs- /Rootwertänderungsroutine 338 auf, und dann erfolgt Rücksprung der Steuerung zu dem Block 315. Falls gewünscht, kann der Block 376 auch die Benutzeroberfläche beispielsweise so ändern, daß eine Farbänderung des Hintergrundfelds implementiert wird, das die zu schreibenden Daten umgibt. Bei Empfang einer Anzeige einer erfolgreichen Schreiboperation kann der Block 376 auch die Hintergrundfarbe in ihren Originalzustand zurückbringen, um anzuzeigen, daß der Wert geschrieben worden ist (wenn die Routine 338 dies nicht bereits erledigt hat).
Wenn andererseits der Block 374 beurteilt, daß der Anwender eine Änderung in der Benutzeroberfläche anfordert, ruft ein Block 378 die Benutzeroberfläche-Ändern-Routine 362 auf, und es erfolgt Rücksprung der Steuerung zu dem Block 315.
Fig. 19 zeigt die Operation einer Steuerung als Antwort auf eine Meldung von der DCI 60, d. h. von einem OLE-Objekt innerhalb der Hierarchie der Fig. 3 und 4. Ein Block 380 beurteilt zuerst, ob die Meldung von der DCI 60 eine nichtblockierende Leserückmeldung ist oder ob die Meldung irgendeine andere Änderung oder eine geänderte Bedingung innerhalb des entsprechenden OLE-Objekts der OLE-Hierarchie bedeutet. Eine Bedingung-Ändern-Meldung kann beispielsweise eine FMS-Blockiermeldung aufweisen, die Vielfachanwender daran hindert, auf einen bestimmten Block innerhalb einer Einrichtung eines Prozesses gleichzeitig zuzugreifen. Wenn beispielsweise Zugriff auf einen Block durch einen anderen Anwender über einen mobilen Kommunikator oder ein anderes FMS-System, das an der Einrichtung angebracht ist, erfolgt, identifiziert das OLE-Objekt diese Bedingung durch die DCI 60 an die Steuerung. Danach kann die Steuerung für den Anwender anzeigen, daß die Daten dieses Blocks nicht mehr schreibbar sind, indem beispielsweise auf dem Bildschirm ein grauer Hintergrund angezeigt wird, der einen normalerweise schreibbaren Wert umgibt.
Im Fall einer nichtblockierenden Leserückmeldung beurteilt ein Block 382, ob der rückgemeldete Wert sich geändert hat. Wenn das so ist, speichert ein Block 384 diesen neuen Wert in dem Steuercache. Der Block 384 und, wenn keine Änderung der in dem Steuercache gespeicherten Daten erfolgt ist, auch der Block 382 geben die Steuerung an einen Block 386 weiter. Der Block 386 wird ebenfalls implementiert, wenn der Block 380 beurteilt, daß die Meldung von dem OLE-Objekt sich auf eine Änderung bezieht, die nicht auf eine nichtblockierende Leseoperation bezogen ist.
Der Block 386 beurteilt, ob eine Änderung an der Benutzeroberfläche benötigt wird, wenn etwa die geänderten Daten oder die neue Bedingung oder der neue Status auf dem Bildschirm anzuzeigen ist. Wenn ja, ruft ein Block 390 die Benutzeroberfläche-Ändern-Routine 362 auf, um die geänderten Daten oder die geänderte Bedingung für den Anwender anzuzeigen. Wenn jedoch der Block 386 beurteilt, daß die geänderten Daten oder die Bedingung nicht angezeigt zu werden braucht, oder wenn der Block 390 diese geänderten Daten oder die Bedingung für den Anwender angezeigt hat, beurteilt ein Block 392, ob die Anwendung über die geänderten Daten oder Bedingung entsprechend vorher geschriebenen Anweisungen informiert werden sollte. Wenn ja, sendet ein Black 394 eine Meldung an die aktuelle Anwendung 56, die die geänderten Daten oder die Bedingung anzeigt. Danach erfolgt. Rücksprung der Steuerung zu dem Block 315.
Im allgemeinen kann Information, auf die von einer Einrichtungs-, einer Block-, einer Parameter- oder einer Zeitplansteuerung zugegriffen wird, auf einem Bildschirm auf jede gewünschte Weise angezeigt werden, was umfaßt: (1) den EDIT-Stil, bei dem sich die Steuerung ähnlich wie eine normale Microsoft Windows Edit-Steuerung verhält, (2) den COMBO-Stil, bei den sich die Steuerung ähnlich wie eine normale Microsoft Windows Combo Box Steuerung verhält (d. h. als Dropdown-Menü), (3) den LIST-Stil, bei dem sich die Steuerung ähnlich einer normalen Microsoft Windows List Box Steuerung verhält (d. h. so, daß jedes Element in der Aufzählung durch einen Listenboxeintrag dargestellt ist), (4) den GROUP-Stil, bei dem sich die Steuerung ähnlich wie eine normale Microsoft Windows Group Box Steuerung verhält, oder (5) den PANEL-Stil, bei dem die Steuerung entweder ein erhabenes oder ein vertieftes Feld anzeigt, und/oder jeden anderen gewünschten Stil oder jedes andere gewünschte Format.
Fig. 20 zeigt Steuerdisplays 400 und 402, die zwei Einrichtungssteuerungen zugeordnet sind. Jedes der Einrichtungssteuerdisplays 400 und 402 umfaßt ein Bild oder eine digitale Momentaufnahme der Einrichtung (die gewöhnlich vom Hersteller einer Einrichtung oder dem DDS-Provider bereitgestellt wird), die in einem der aktuellen Anwendung zugehörigen Speicher gespeichert ist. Statt dessen kann diese Momentaufnahme in der Datenbank 40 gespeichert sein, so daß sie für die OLE-Objekte zugänglich ist.
Die Steuerdisplays 400 und 402 können jede andere gewünschte Information über eine Einrichtung aufweisen, beispielsweise den Namen (in Fig. 20 gezeigt), Kennzeichen, Moniker usw. einer Einrichtung, oder jede andere gewünschte einrichtungsspezifische Information. Außerdem können Menüs für die Einrichtung in einem Drop-down-Fenster, das den Steuerdisplays 400 und 402 der Einrichtung zugeordnet ist, vorgesehen sein. Diese Menüs können einer Einrichtung zugeordnete Dateien aufweisen, beispielsweise die Namen der Sammlungen, die einem Device-Objekt für die Einrichtung zugeordnet sind, Methoden, die an der Einrichtung implementiert werden können, einschließlich Kalibrier-, Rücksetz- und Selbsttestmethoden, Blöcke, die der Einrichtung zugeordnet sind, eine der Einrichtung zugeordnete Liste von Parametern, Hilfe für die Einrichtung, Wartungsbemerkungen für die Einrichtung usw. Sonstige Informationen über eine Einrichtung, die angezeigt werden können, umfassen die Inhalte jeder Variablen jedes Parameters in einer Einrichtung, die Frontplatteninfdrmation einer Einrichtung, den Betriebszustand der Einrichtung, was beispielsweise umfaßt, ob innerhalb der Einrichtung ein Fehler aufgetreten ist, und eine Nebeneinanderstellung beispielsweise der Werte von Variablen von einem oder mehreren Parametern einer Einrichtung, wie sie existieren oder zu bestimmten Zeiten existierten.
Fig. 21 zeigt ein allgemeines Parametersteuerdisplay 406 zusammen mit speziellen Parametersteuerdisplays 408, 410 und 412, die drei bestimmten Parametersteuerungen für die Parameter einer Einrichtung zugeordnet sind. Jedes der Parametersteuerdisplays 406 bis 412 befindet sich an einem anderen Bereich eines Bildschirms, und insbesondere befindet sich das Parametersteuerdisplay 406 am oberen Ende des Bildschirms, während die Parametersteuerdisplays 408, 410 und 412 nacheinander unter dem Parametersteuerdisplay 406 liegen.
Das Parametersteuerdisplay 406 zeigt, daß ein Parametersteurdisplay drei Felder haben kann, umfassend ein Etikettfeld, das Information in bezug auf die Art der gezeigten Information liefert, beispielsweise "Druck", "Temperatur" oder "Modus", ein Wertefeld, das den Wert eines Parameters zeigt, und ein Einheitenfeld, das die Einheiten zeigt, in denen der Wert ausgedrückt wird. Der Wert eines Parameters kann eine ganze Zahl, eine Dezimalzahl (Parametersteuerdisplays 408 und 410) oder ein Aufzählungswert sein, der aus einem von einer aufgezählten Menge von Werten besteht, die in einem dem Parametersteuerdisplay 412 zugeordneten Drop-down-Menü aufgeführt sind. Das Parametersteuerdisplay 412 umfaßt keine Einheitenvariable, weil eine solch Variable nicht auf die damit assoziierte Aufzählungsmenge anwendbar ist.
Fig. 22 zeigt zwei Blocksteuerdisplays 414 und 416, die Blocksteuerungen zugeordnet sind. Ebenso wie ein Einrichtungssteuerdisplay umfaßt ein Blocksteuerdisplay typischerweise ein Bild oder eine andere Darstellung eines Blocks und/oder irgendwelche gewünschte Information, die sich auf einen Block und/oder die Einrichtung bezieht, in der sich der Block befindet, beispielsweise, ob ein Block ein Eingangs-, ein Ausgangs- oder ein Steuerblock (oder Schnittstellenblock) ist.
Fig. 23 zeigt zwei Zeitplansteuerdisplays 420 und 422, die dazu dienen, die Zeit- und Ansichtseigenschaften von OLE- Root-Objekten zu steuern und zu ändern, mit denen weitere Steuerungen wie etwa Einrichtungs-, Block- und Parametersteuerungen verbunden sein können. Jede der Zeitplansteuerungen, die den Displays 420 und 422 zugeordnet sind, kann den Zeitwert ihres jeweiligen Root-Objekts zu jeder der früheren Zeiten, für die Root-Objekte verfügbar sind, ändern, was typischerweise die früheren Zeiten umfaßt, zu denen Änderungen an dem System vorgenommen wurden und für die Transaktionsaufzeichnungen 202 in der Transaktionsdatenbank 200 (Fig. 5) der FMS-Datenbank 40 (Fig. 1) gespeichert sind. Ferner können die den Steuerdisplays-, 420 und 422 zugeordneten Zeitplansteuerungen die Ansicht eines Root-Objekts zwischen einer früheren, einer derzeitigen oder einer zukünftigen Einstellung ändern.
Jedes Zeitplansteuerdisplay umfaßt gewöhnlich, wie Fig. 23 zeigt, einen Gleiter 424, der anzeigt, welche von der früheren, derzeitigen und zukünftigen Ansicht gewählt ist, sowie eine Combobox 426, die einem Anwender erlaubt, aus einer Menge von historischen Zeiten eine Auswahl zu treffen, wobei jede davon beispielsweise ein Datum und eine Zeit hat.
Durch Ändern des Zeitplansteuergleiters 424 weist der Anwender die Zeitplansteuerung an, die dieser Zeitplansteuerung zugeordnete Root-Objektansichteigenschaft zu ändern. Durch Ändern der Combobox 426 der Zeitplansteuerung weist der Anwender die Zeitplansteuerung an, den Root-Objektzeitwert auf eine bestimmte Zeit zu ändern.
Wenn eine Zeitplansteuerung die Zeit oder Ansicht eines Root-Objekts ändert, werden alle anderen Steuerungen wie etwa Parameter-, Einrichtungs- oder Blocksteuerungen, die diesem Root-Objekt zugeordnet sind, automatisch als Reaktion auf Änderungsmeldungen, die von den OLE-Objekten erzeugt werden, aktualisiert. Diese Änderungsmeldungen werden von den OLE-Objekten erzeugt, wenn die OLE-Objekte innerhalb derselben Hierarchie wie das Root-Objekt neue Daten abrufen, die die neue Zeit oder neue Ansicht betreffen, die dem Root- Objekt nunmehr zugeordnet ist.
Fig. 23 zeigt auch Temperatur- und Druckparameter- Steuerdisplays 430 und 432, die mit demselben Root-Objekt wie die Zeitplansteuerung verbunden sind, die dem Zeitplansteuerdisplay 420 zugeordnet ist. Ebenso sind Temperatur- und Druckparameter-Steuerdisplays 440 und 442 mit demselben Root-Objekt wie die Zeitplansteuerung verbunden, die dem Zeitplansteuerdisplay 422 zugeordnet ist. Da die Zeitplansteuerdisplays 420 und 422 auf verschiedene Zeiten eingestellt sind, d. h. eine frühere Zeit (Steuerdisplay 420) und die momentane Zeit (Steuerdisplay 422), sind die Werte der Temperaturparameter 430 und 440 verschieden, und die Werte der Druckparameter 432 und 442 sind verschieden. Eine Liste von solchen Parametersteuerdisplays kann auf dem Bildschirm konfiguriert werden, um eine oder mehrere komplette Konfigurationen für eine Einrichtung, einen Block usw. anzuzeigen. Einrichtungs- und Block- und/oder andere Parametersteuerungen können auch demselben Root-Objekt als Zeitplansteuerungen zugeordnet sein und können genutzt werden, um ein Konfigurationsdisplay zu zeigen, das eine Konfiguration einer Einrichtung, eines Blocks oder eines Parameters zu verschiedenen Zeiten nebeneinander oder anders aufgeteilt auf einem Bildschirm zeigt. Eine Zeitplansteuerung kann ebenfalls in Verbindung mit anderen Steuerungen auf einem Display verwendet werden, um durch die Einstellungen oder Werte von Einrichtungen, Blöcken oder Parametern oder eine Gruppe solcher Einrichtungen, Blöcke oder Parameter zu rollen. Es ist ersichtlich, daß jede gewünschte Kombination von Zeitplan-, Einrichtungs-, Block-, Parameter- und/oder anderen Steuerungen verwendet werden kann, um jede gewünschte frühete und/oder derzeitige Information für einen Anwender anzuzeigen, was beispielsweise Information in bezug auf Online-Einrichtungen zum derzeitigen Zeitpunkt, d. h. Onlinedaten, und Information in bezug auf Online- Einrichtungen in der Vergangenheit oder Zukunft sowie Offline-Einrichtungen in der Vergangenheit, Gegenwart oder Zukunft, d. h. Offlinedaten, umfaßt. Wie ferner in bezug auf Fig. 23 zu sehen ist, können die gleichen Daten, beispielsweise die gleichen Parameterwerte für eine Einrichtung, für unterschiedliche Zeiten unter Anwendung von Zeitplansteuerungen verdeutlicht werden, und falls gewünscht, können Routinen implementiert werden, um die Unterschiede zwischen den Gruppen von Werten anzuzeigen.
Die Zeitplansteuerung ändert die Time-Eigenschaft des Root- Objekts auf eine bestimmte Zeit (nachstehend als ViewTime bezeichnet), die der Anwender unter Anwendung der Zeitplansteuerung benennt. Infolgedessen werden die Zeitattribute für sämtliche Objekte an der Abstromseite des Root-Objekts in der OLE-Hierarchie geändert, um mit der ViewTime übereinzustimmen, wie oben beschrieben wird. Außerdem werden die Werte von anderen Eigenschaften dieser Objekte auf die dieser ViewTime entsprechenden Werte aktualisiert.
Für ein spezielles Blockobjekt wird der Zustand des entsprechenden Blocks zu jedem gewünschten Zeitpunkt (z. B. die ViewTime, die unter Anwendung der Zeitplansteuerung angegeben wurde) erhalten unter Nutzung der oben beschriebenen Transaktionsdatenbank 200 (Fig. 5). Insbesondere werden die Werte der Parameter des Blockobjekts zu der ViewTime (d. h. die Werte der Value-Eigenschaften der Parameter-Objektes des Blockobjekts zum Zeitpunkt der ViewTime) erhalten durch Durchsuchen der Transaktionsdatenbank 200 in umgekehrter chronologischer Folge, beginnend mit der ViewTime, um die Werte zu finden, die den Parametern zuletzt zugeordnet waren, die diesen Parameter-Objekten zu oder vor der ViewTime entsprechen. Dieser Vorgang wird nachstehend unter Bezugnahme auf das Flußdiagramm von Fig. 24 im einzelnen beschrieben.
Fig. 24 ist ein Flußdiagramm, das zeigt, wie ein Zustand eines bestimmten Blocks aus der oben beschriebenen Transaktionsdatenbank 200 rekonstruiert werden kann. Zuerst initialisiert ein Block 450 eine "Setz"-Typ-Variable {S} auf Null. Die gesetzte Variable {S} wird genutzt, um die Werte ab der ViewTime der Parameter des Blocks, dessen ViewTime- Zustand zu rekonstruieren ist, zu sammeln. Ein Block 452 setzt dann eine Zeit, die dem Setzzustand {S} zugeordnet ist, gleich der ViewTime. Danach beurteilt ein Block 454, ob die gesetzte Variable {S} einen Wert für jeden Parameter des Block-Objekts aufweist. Wenn das so ist, ordnet ein Block 456 den zusammengesetzten Zustand {S} als den Zustand des Blocks zur ViewTime zu, und die Ausführung der Zustandsrekonstruktionsroutine von Fig. 24 endet.
Wenn der Block 454 beurteilt, daß der gesammelte Zustand (d. h. der Inhalt der gesetzten Variablen {S}) nicht für jeden Parameter in dem Block Werte aufweist, identifiziert ein Block 458 den nächsten Parameter P, für den ein aktueller Wert nicht in dem gesammelten Zustand {S} enthalten ist. Ein Block 460 durchsucht dann die Transaktionsdatenbank 200 in umgekehrter chronologischer Folge, beginnend mit ViewTime, um die neueste Änderung TR zu finden, die bei oder vor ViewTime vorgenommen wurde. Ein Block 462 fügt dann den Parameter P, wobei der Wert des Parameters P durch die Änderung eingestellt ist, die durch die Transaktion TR dargestellt ist, zu dem gesammelten Zustand {S} hinzu, und dann erfolgt Rücksprung der Steuerung zu dem Block 454, wo erneut geprüft wird, ob nunmehr Werte aller Parameter in dem Block in dem Zustand {S} gesammelt sind.
Die Einrichtungs-, Block-, Parameter- und Zeitplansteuerungen sind zwar hier gezeigt und beschrieben, aber andere Steuerungen gemäß der vorliegenden Erfindung könnten konstruiert werden, um andere Eigenschaften oder Daten zu zeigen, die durch DDL verfügbar sind, einschließlich Daten innerhalb jedes der OLE-Objekte, die in den Fig. 3 und 4 gezeigt sind.

OLE-OBJEKT-DDL-ÄQUIVALENTE

Die folgende Tabelle erläutert die Übereinstimmung zwischen der oben beschriebenen OLE-Hierarchie und den darauf bezogenen Konstrukten in der DDL. In der Tabelle bedeutet der Ausdruck "Hauptrechner" ein FMS-System oder eine FMS-Anwendung. Ferner können die tatsächlichen Schlüsselbegriffe, die von einer bestimmten DDL verwendet werden, variieren, und die richtigen Schlüsselwörter für eine bestimmte DDL findet man in der für diese DDL vorhandenen Beschreibung. Die nachstehende Tabelle basiert auf der Fieldbus-Einrichtungsbeschreibungssprache, die gleich wie die HART-Einrichtungsbeschreibungssprache ist.

OLE-OBJEKT (untere Hierarchie) DDL-ÄQUIVALENT

ArrayParameter-Objekt Das DDL-Äquivalent ist ein Array, was eine logische Gruppe von Werten ist. Jeder Wert oder jedes Element ist von dem Datentyp einer DDL- Variablen. Auf ein Element kann von anderswo in der Einrichtungsbeschreibung über den Arraynamen und den Elementindex Bezug genommen werden. Aus der Perspektive der Kommunikation werden daher die Einzelelemente des Arrays nicht als individuelle Variablen, sondern einfach als Einzelwerte behandelt.
Block-Objekt Das DDL Äquivalent ist ein Block, der die äußeren Charakteristiken eines DDL-Blocks definiert.
Collection-Objekt
Dieses OLE-Objekt repräsentiert ein spezielles Objekt in dem Collections- Collectionobjekt (siehe Collections) Das DDL-Äquibvalent ist eine Sammlung, was eine logische Gruppe von Elementen ist. Jedem Element in der Gruppe ist ein Name zugeordnet. Auf die Elemente kann in der Einrichtungsbeschreibung durch Verwendung eines Sammlungsnamens und eines Elementnamens Bezug genommen werden.
CollectionItems-Sammelobjekt ("Element") Das DDL-Äquivalent ist eine Sammlung, was eine logische Gruppe von Elementen ist. Jedem Element in der Gruppe ist ein Name zugeordnet. Auf die Elemente kann in der Einrichtungsbeschreibung Bezug genommen werden unter Verwendung eines Sammlungsnamens und eines Elementnamens.
Collections-Sammelobjekt ("Collection") Das nächstkommende DDL-Äquivalent ist eine Sammlung, was eine logische Gruppe von Elementen (in diesem Fall Sammlungen) ist. Jeder Sammlung in der Gruppe ist ein Name zugeordnet. Auf die Sammlungen kann in der. Einrichtungsbeschreibung durch Verwendung des Sammlungsnamens und des Namens der Sammlung von Sammlungen Bezug genommen werden.
DatabaseParameters-Sammelobjekt ("Database") Es gibt kein DDL-Äquivalent für dieses OLE-Sammelobjekt, das nur in der FMS-Datenbank existiert. Dieses Objekt betrifft eine Sammlung von Parametern, die in einer Datenbank gespeichert sind.
DatabaseParameter-Objekt Es gibt kein DDL-Äquivalent für dieses OLE-Objekt, das nur in der FMS-Datenbank existiert. Dieses Objekt betrifft einen in einer Datenbank gespeicherten Parameter.
EditDisplay-Objekt Das DDL-Äquivalent ist ein Edit Display, das definiert, wie Daten einem Anwender von einem Hauptrechner präsentiert werden. Es wird verwendet, um Elemente während des Editierens zusammen zu gruppieren.
EditDisplayItems-Sammelobjekt ("DispLay" und "Edit") Das DDL-Äquivalent ist eine Sammlung von Editelementen, die eine Menge von Blockparametern und Elementen von Blockparametern sind, die vom Anwender zu editieren sind. Die Displayelemente sind vorgesehen, um dem Anwender zu ermöglichen zu entscheiden, was die Werte der Editelemente sein sollten.
EditDisplays-Sammelobjekt ("EditDisplay") Das DDL-Äquivalent ist eine Sammlung von Editdisplays, die definieren, wie Daten einem Anwender von einem Hauptrechner präsentiert werden. Sie dienen zur Gruppierung von Elementen während des des Editierens.
Elements-Sammelobjekt ("Element") Das DDL-Äquivalent ist eine Sammlung oder Gruppe von Elementen, die ein Item (etwa eine Variable oder ein Menü) in der Gruppe bezeichnen, und ist von einer Gruppe von vier Parametern (Index, Item, Beschreibung und Hilfe) definiert.
EnumerationValue-Objekt Das DDL-Äquivalent ist eine Variable vom Aufzählungstyp. Solche Variablen umfassen aufgezählte Variablen, die vorzeichenlose ganze Zahlen sind, die eine Textfolge haben, die einigen oder allen Werten zugeordnet ist (nützlich beispielsweise zur Definition von Tabellen), und bit-aufgezählte Variablen, die vorzeichenlose ganze Zahlen sind, die eine Textfolge haben, die einigen oder allen Bits zugeordnet ist (nützlich für die Definition von Status-Oktetts).
EnumerationValues-Sammelobjekt ("Enum") Das DDL-Äquivalent ist eine Sammlung von Variablen vom Aufzählungstyp.
ItemArray-Sammelobjekt ("IndexedItemArray") Das DDL-Äquivalent ist eine Sammlung von Itemarrays.
ItemArray-Objekt Das DDL-Äquivalent ist ein Itemarray, was eine logische Gruppe von Items wie etwa von Variablen oder Menüs ist. Jedem Item in der Gruppe ist eine Zahl zugeordnet, die als Index bezeichnet ist. Auf die Items kann von anderswo in der Einrichtungsbeschreibung über den Itemarraynamen und die Itemnummer Bezug genommen werden. Itemarrays sind einfach Gruppen von DDL-Items und haben keine Beziehung zu Kommunikationsarrays ("ARRAY" vom Itemtyp). Kommunikationsarrays sind Arrays von Werten.
ItemArrayItems-Sammelobjekt ("Element") Das DDL-Äquivalent ist ein Element, ein Attribut eines Itemarrays, das Elemente des Itemarrays identifiziert. Jedes Iternarrayelement bezeichnet ein Item (wie etwa eine Variable oder ein Menü) in der Gruppe und ist durch eine Gruppe von vier Parametern (Index, Item, Beschreibung und Hilfe) definiert.
ItemArrays-Sammelobjekt ("ItemArray") Das DDL-Äquivalent ist eine Sammlung von Itemarrays.
Members-Sammelobjekt ("Member") Das DDL-Äquivalent ist eine Sammlung von Elementen, die Variablen, Aufzeichnungen und/oder Arrays sind.
Menu-Objekt Das DDL-Äquivalent ist ein Menü, das Parameter, Methoden und andere Items, die in der DDL bezeichnet sind, in eine hierarchische Struktur organisiert. Eine Hauptrechneranwendung kann die Menüitems nutzen, um für den Anwender Information auf eine organisierte und gleichbleibende Weise anzuzeigen.
MenuItems-Sammelobjekt ("MenuTtem") Das DDL-Äquivalent ist eine Sammlung von Menüitems. Die Items eines Menüs bezeichnen die Items, die dem Menü zugeordnet sind, plus einen optionalen Qualifier.
Menus-Sammelobjekt ("Menu") Das DDL-Äquivalent ist eine Sammlung von Menüs.
Method-Objekt Das DDL-Äquivalent ist eine Methode, die die Ausführung von komplexen Dialogen beschreibt, die zwischen Haupteinrichtungen und einer Feldeinrichtung erfolgen müssen.
Methods-Sammelobjekt ("PreEdit", "PostEdit" und "Method") Das DDL-Äquivalent ist eine Sammlung von Methoden.
NamedConfig-Objekt Es gibt kein DDL-Äquivalent für ein NamedConfig-Objekt, weil diese Objekte Blöcken entsprechen, die in der FMS-Datenbank und nicht in Feldeinrichtungen gespeichert sind.
Parameters-Sammelobjekt ("Param") Das DDL-Äquivalent ist eine Sammlung von Parametern, die Aufzeichnungen, Arrays oder Variablen sein können.
RecordParameter-Objekt Das DDL-Äquivalent ist eine Aufzeichnung (record), die eine logische Gruppe von Variablen ist. Jede Variable kann einen anderen Datentyp haben. Auf die Variablen kann von anderswo in der Einrichtungsbe schreibung über den Aufzeichnungsnamen und den Elementnamen Bezug genommen werden. DDL- Aufzeichnungen beschreiben Kommunikationsaufzeichnungsobjekte. Aus einer Kommunikationsperspektive werden daher die einzelnen Elemente der Aufzeichnung nicht als einzelne Variablen, sondern einfach als eine Gruppe von Variablenwerten behandelt.
RefreshRelaticmn-Objekt Das DDL-Äquivalent ist eine Auffrischbeziehung (refresh relation), ein spezieller Typ von Beziehung, die dem Hauptrechner erlaubt, Entscheidungen in bezug auf einen Parameterwert konsistent zu treffen, wenn sich ein Parameterwert ändert. Sie bezeichnet eine Menge von Blockparametern, die eventuell aufgefrischt werden müssen (erneut aus der Einrichtung gelesen werden müssen), wann immer ein Blockparameter von einer anderen Menge modifiziert wird. Ein Blockparameter kann eine Auffrischbeziehung mit sich selbst haben, was bedeutet, daß der Blockparameter nach dem Schreiben gelesen werden muß.
Gelegentlich wird durch das Schreiben eines Blockparameters zu einer Feldeinrichtung die Feldeinrichtung veranlaßt, die Werte von anderen Blockparametern zu aktualisieren. Wenn die zusätzlichen aktualisierten Blockparameter dynamisch sind, gibt es keinen Konflikt, weil der Hauptrechner die Parameterwerte von einer gestörten Einrichtung jedesmal neu lesen sollte, wenn die Werte gebraucht werden. Es kann aber sein, daß Hauptrechner die Werte von statischen Blockparametern zwischenspeichern. Damit also Hauptrechner die richtigen Werte aller statischen Blockparameter aufrechterhalten, müssen sie wissen, wenn die Feldeinrichtung ihre Werte ändert.
RefreshRelations- Sammelobjekt ("Refresh") Das DDL-Äquivalent ist eine Sammlung von Auffrischbeziehungen.
RelationItems-Sammelobjekt ("Units", "Members", "Left" und "Right") Das DDL-Äquivalent ist eine Sammlung von Parametern, die Variablen, Aufzeichnungen und/oder Arrays sein können.
ResponseCode-Objekt Das DDL-Äquivalent ist response codes (Antwortcodes), was die Werte bezeichnet, die eine Feldeinrichtung als anwendungsspezifische Fehler zurücksenden kann. Jede Variable, Aufzeichnung, jedes Array, jedes Variablenliste, jedes Programm oder jede Domäne kann ihre eigene Menge von Antwortcodes haben, weil jedes für FMS-Services verfügbar ist.
ResponseCodes-Sammelobjekt ("RespCode") Das DDL-Äquivalent ist eine Sammlung von Antwortcodes.
UnitRelation-Objekt Das DDL-Äquivalent ist eine Einheitsbeziehung (unit relation), was einen Einheitencodeparameter und die Blockparameter mit diesen Einheiten bezeichnet. Wenn ein Einheitencodeparameter modifiziert wird, sollten die Blockparameter, die diesen Einheitencode haben, aufgefrischt werden. In dieser Beziehung ist eine Einheitsbeziehung genau das gleiche wie eine Auffrischbeziehung. Wenn ferner ein Blockparameter mit einem Einheitencode angezeigt wird, wird auch der Wert seines Einheitencodes angezeigt.
UnitRelations-Sammelobjekt ("Unit") Das DDTh-Äquivalent ist eine Sammlung von Einheitsbeziehungen.
VariableParameter-Objekt Das DDL-Äquivalent ist eine Veriable, die in einer Einrichtung enthaltene Daten beschreibt.
WriteAsOneRelation-Objekt Das DDL-Äquivalent ist eine Write- as-one-Beziehung, die den Hauptrechner informiert, daß eine Gruppe von Blockparametern als eine Gruppe modifiziert werden muß. Diese Beziehung bedeutet nicht unbedingt, daß die Blockparameter gleichzeitig zu der Feldeinrichtung geschrieben werden müssen. Nicht alle Blockparameter, die gleichzeitig zu der Feldeinrichtung übermittelt werden, sind notwendigerweise Teil einer Write-as-one-Beziehung. Wenn eine Feldeinrichtung die Prüfung und Modifizierung bestimmter Blockparameter für einen ordnungsgemäßen Betrieb verlangt, ist eine Write- as-one-Beziehung erforderlich.
WriteAsOneRelations-Sammelobjekt ("WAO") Das DDL-Äquivalent ist eine Sammlung von Write-as-one- Beziehungen.

OLE-OBJEKTDEFINITIONEN

Die folgenden Tabellen zeigen die Eigenschaften und Methoden der verschiedenen OLE-Objekte und Sammelobjekte in der in Fig. 4 gezeigten unteren Hierarchie. Die verschiedenen Eigenschaften dieser Objekte und Sammelobjekte sind in der nachstehenden Tabelle nicht enthalten, aber diese Eigenschaften entsprechen den Attributen der DDL-Objekte, die Äquivalente der Objekte sind. Die DDL-Äquivalente der OLE-Objekte und Sammelobjekte sind in der Tabelle der OLE-Objekt-DDL-Äquivalente bezeichnet und sind in dem ISP Fieldbus DDDL-Beschreibungsdokument, das hier summarisch eingeführt wird, vollständig beschrieben.
Die nachstehenden Tabellen verwenden die folgenden Symbole, um die folgende Information zu bezeichnen:
(R) Zugriff auf die Eigenschaft über die Schreib/Lese- und Hol/Setz-Methoden.
( ) Schreiben/Lesen
( ) Schreiben/Lesen in Einrichtungen unter Rev. 5; ansonsten nur Lesen
(M) Diese Methode laufen lassen durch Ausführen der OLE- Methode mit Namen "Method" oder "CallMethod"
(N) Nicht implementiert
(C) Zugriff auf diese Eigenschaft über eine OLE-Eigenschaft. Holmethode oder Leseanforderung, die nur diese Eigenschaft enthält.
Die in der Rücksendetyp-Spalte bezeichneten Werte geben die folgenden VARIANT-Typen an:
VT_EMPTY Verwendet, wenn kein Wert verfügbar ist.
VT_I4 Verwendet für ganzzahlige Werte und Boolesche Werte.
VT_R4 Verwendet für die meisten Gleitkomma-Feldmeßwerte.
VT_R8 Verwendet für Doppelpräzisionsmeßwerte.
VT_DATE Verwendet für Daten und Zeiten unter Anwendung von Doppelpräzision.
VT_BSTR Verwendet für Zeichenfolgen.
VT_ERROR Verwendet für Fehlercodes.
VT_ARRAY Verwendet für Binärwerte.
Alle in dieser Tabelle definierten Objekte haben die Gruppe von unten angegebenen Standardeigenschaften. Standard-Eigenschaften ArrayParameter-Objekt Block-Objekt BlockTag-Sammlung Collections-Sammlung CollectionsItems-Sammlung CollectionItem-Objekt Collection-Objekt DatabaseParameter-Objekt DatabaseParameters-Sammlung DeviceID-Sammlung Device-Objekt DeviceTag-Sammlung EditDisplayItems-Sammlung EditDisplays-Sammlung EditDisplay-Objekt Elements-Sammlung EnumerationValue-Objekt EnumerationValues-Sammlung HIU-Sammlung Interchange-Objekt ItemArray-Objekt ItemArrays-Sammlung ItemArrayItem-Objekt ItemArrayItems-Sammlung Members-Sammlung MenuItems-Sammlung MenuItem-Objekt Menu-Objekt Menus-Sammlung Methods-Sammlung Method-Objekt Modem-Sammlung NamedConfigs-Sammlung NamedConfig-Objekt Net-Sammlung NetNode-Objekt Parameters-Sammlung PhysicalTag-Sammlung Port-Sammlung RecordParameter-Objekt RefreshRelation-Objekt RefreshRelations-Sammlung ResponseCode-Objekt RelationItems-Sammlung ResponseCodes-Sammlung Root-Objekt Tag-Sammlung UnitRelation-Objekt UnitRelations-Sammlung VariableParameter-Objekt WriteAsOneRelation-Objekt WriteAsOneRelations-Sammlung

Claims

1. Schnittstellensteuerung (58), die zum Gebrauch mit einem Verwaltungssystem (10) ausgebildet ist, das folgendes aufweist: eine Benutzeroberfläche (30), eine Datenbank (40) und ein Kommunikationsnetzwerk (66), das mit der Datenbank (40) kommuniziert, eine Feldeinrichtung (12) und eine Einrichtungsbeschreibung (76), die der Feldeinrichtung (12) zugeordnet ist, wobei die Feldeinrichtung (12), die Einrichtungsbeschreibung (76) und die Datenbank (40) eine Vielzahl von Gruppen logisch miteinander in Beziehung stehender Elemente von Einrichtungsdaten speichern, wobei die Schnittstellensteuerung (58) folgendes aufweist:

Einrichtungen (300, 301) zum Implementieren einer bestimmten Schnittstellensteuerung (302, 304, 306, 308) für eine bezeichnete Gruppe der Vielzahl von Gruppen logisch miteinander in Beziehung stehender Elemente von Einrichtungsdaten, die aufweist:

eine Einrichtung (324), die das Kommunikationsnetzwerk (66) anweist, die Elemente von Einrichtungsdaten, die der bezeichneten Gruppe zugeordnet sind, aus wenigstens einer von der Feldeinrichtung (12), der Einrichtungsbeschreibung (76) und der Datenbank (40) zu lesen, um eine Menge von Elementen von abgerufenen Einrichtungsdaten für die bezeichnete Gruppe zu erzeugen, und

eine Einrichtung (322) zur Anzeige der Menge von Elementen von abgerufenen Einrichtungsdaten für die bezeichnete Gruppe über die Benutzeroberfläche (30) in einem vordefinierten Format,

eine Einrichtung (310) zum Identifizieren einer der Vielzahl von Gruppen logisch miteinander in Beziehung stehender Elemente von Einrichtungsdaten als die bezeichnete Gruppe, und

eine auf die Identifizierungseinrichtung ansprechende Einrichtung (300), die die Implementierungseinrichtungen auffordert, die bestimmte Schnittstellensteuerung (302, 304, 306, 308) für die bezeichnete Gruppe zu schaffen.

2. Schnittstellensteuerung (58) nach Anspruch 1, wobei die Implementierungseinrichtungen (300, 301) ferner eine auf die Benutzeroberfläche (30) ansprechende Einrichtung aufweisen, die das Kommunikationsnetzwerk (66) anweist, eine Änderung an einem der Elemente von Einrichtungsdaten, die der bezeichneten Gruppe zugeordnet sind, zu implementieren, wenn das eine der Elemente von Einrichtungsdaten in der Feldeinrichtung (12) oder der Datenbank (40) gespeichert wird.

3. Schnittstellensteuerung (58) nach Anspruch 2, wobei die Anweisungseinrichtung aufweist: eine Einrichtung, die bestimmt, ob die Änderung an dem einen der Elemente von Einrichtungsdaten, die der bezeichneten Gruppe zugeordnet sind, zulässig ist, und eine Einrichtung, die über die Benutzeroberfläche (30) anzeigt, daß die Änderung unzulässig ist, wenn die Bestimmungseinrichtung bestimmt, daß die Änderung unzulässig ist.

4. Schnittstellensteuerung (58) nach Anspruch 3, wobei die Bestimmungseinrichtung ferner aufweist: eine Einrichtung, die das Kommunikationsnetz (66) anweist, eine Bereichsangabe, die dem einen der Elemente von der bezeichneten Gruppe zugeordneten Einrichtungsdaten zugeordnet ist, von einer von der Einrichtungsbeschreibung (76), der Feldeinrichtung (12) und der Datenbank (40) abzurufen, und eine Prüfeinrichtung, um zu bestimmen, ob die Änderung an dem einen der Elemente von der bezeichneten Gruppe zugeordneten Einrichtungsdaten in den von der abgerufenen Bereichsangabe definierten Bereich fällt.

5. Schnittstellensteuerung (58) nach Anspruch 2, wobei die Anweisungseinrichtung aufweist: eine Einrichtung, die bestimmt, ob die Änderung an dem einen der Elemente von der bezeichneten Gruppe zugeordneten Einrichtungsdaten abgeschlossen ist, und eine Einrichtung, die über die Benutzeroberfläche (30) anzeigt, daß die Änderung an dem einen der Elemente von der bezeichneten Gruppe zugeordneten Einrichtungsdaten abgeschlossen ist.

6. Schnittstellensteuerung (58) nach Anspruch 1, wobei die Implementierungseinrichtung ferner aufweist: eine Einrichtung, die mit dem Kommunikationsnetzwerk (66) gekoppelt ist, um eine Änderung in einem der Elemente von der bezeichneten Gruppe zugeordneten Einrichtungsdaten, wie sie in der Feldeinrichtung (12) oder der Datenbank (40) gespeichert sind, zu erkennen, und eine auf die Erkennungseinrichtung ansprechende Einrichtung, die die Änderung des einen der Elemente von der bezeichneten Gruppe zugeordneten Einrichtungsdaten über die Benutzeroberfläche (30) anzeigt.

7. Schnittstellensteuerung (58) nach Anspruch 1, wobei die Menge von Elementen von abgerufenen Einrichtungsdaten für die bezeichnete Gruppe Daten aufweist, die die Feldeinrichtung (12) betreffen, und wobei ein erstes von der Menge von Elementen von abgerufenen Einrichtungsdaten eine bildliche Darstellung (400, 402) der Feldeinrichtung (12) aufweist.

8. Schnittstellensteuerung (58) nach Anspruch 7, wobei ein zweites von der Menge von Elementen von abgerufenen Einrichtungsdaten eine Anzeige von dem Typ der Feldeinrichtung (12) aufweist.

9. Schnittstellensteuerung (58) nach Anspruch 8, wobei ein drittes von der Menge von Elementen abgerufener Einrichtungsdaten eine Anzeige des Orts der Feldeinrichtung (12) in bezug auf ein System aufweist, in dem die Feldeinrichtung (12) verwendet wird.

10. Schnittstellensteuerung (58) nach Anspruch 9, wobei ein viertes von der Menge von Elementen abgerufener Einrichtungsdaten eine Liste von Information aufweist, die die Feldeinrichtung (12) betrifft.

11. Schnittstellensteuerung (58) nach Anspruch 1, wobei die Menge von Elementen abgerufener Einrichtungsdaten für die bezeichnete Gruppe Daten aufweist, die einen Block (414, 416) der Feldeinrichtung (12) betreffen, der eines von einem Eingang, einem Ausgang oder einer Steuerfunktion aufweist, die der Feldeinrichtung (12) zugeordnet ist, und wobei ein erstes von der Menge von Elementen von abgerufenen Einrichtungsdaten eine bildliche Darstellung (414, 416) des Blocks aufweist.

12. Schnittstellensteuerung (58) nach Anspruch 11, wobei ein zweites von der Menge von Elementen abgerufener Einrichtungsdaten eine Anzeige von dem Typ des Blocks aufweist.

13. Schnittstellensteuerung (58) nach Anspruch 12, wobei ein drittes von der Menge von Elementen abgerufener Einrichtungsdaten eine Anzeige von der Art aufweist, bei der der Block einem System zugeordnet ist, in dem der Block verwendet wird.

14. Schnittstellensteuerung (58) nach Anspruch 11, wobei die Menge von Elementen abgerufener Einrichtungsdaten für die bezeichnete Gruppe Daten aufweist, die einen Parameter betreffen, der Feldeinrichtung (12) zugeordnet ist, und wobei ein ersten von der Menge von Elementen abgerufener Einrichtungsdaten eine Marke des Parameters aufweist und ein zweites von der Menge von Elementen von abgerufenen Einrichtungsdaten einen Wert des Parameters aufweist.

15. Schnittstellensteuerung (58) nach Anspruch 14, wobei ein drittes von der Menge von Elementen abgerufener Einrichtungsdaten eine Einheitsbezeichnung aufweist, die dem Wert des Parameters zugeordnet ist.

16. Schnittstellensteuerung (58) nach Anspruch 14, wobei der Wert des Parameters einen von einer Aufzählungsliste von potentiellen Werten aufweist.

17. Schnittstellensteuerung (58) nach Anspruch 11, wobei die Menge von Elementen abgerufener Einrichtungsdaten für die bezeichnete Gruppe Konfigurationsdaten aufweist, die mit der Konfiguration der Feldeinrichtung (12) zu einem bestimmten Zeitpunkt in Beziehung stehen, und wobei die Implementierungseinrichtung eine Einrichtung zum Ändern des der Menge von Elementen von abgerufenen Einrichtungsdaten zugeordneten bestimmten Zeitpunkts aufweist.

18. Schnittstellensteuerung (58) nach Anspruch 17, wobei die Änderungseinrichtung ferner aufweist: eine Einrichtung, die eine Darstellung eines Schiebers (424) über die Benutzeroberfläche (30) anzeigt, und eine Einrichtung, die eine Manipulation des Schiebers zum Ändern der bestimmten Zeitpunkt zuläßt.

19. Schnittstellensteuerung (58) nach Anspruch 17, wobei die Änderungseinrichtung ferner aufweist: eine Einrichtung zum Ändern des bestimmten Zeitpunkts zwischen einem von einer Vielzahl von Zeitpunkten in der Vergangenheit, einem gegenwärtigen Zeitpunkt und einem zukünftigen Zeitpunkt.

20. Schnittstellensteuerung (58) nach Anspruch 1, wobei die Menge von Elementen abgerufener Einrichtungsdaten für die bezeichnete Gruppe Konfigurationsdaten aufweist, die mit zwei Konfigurationen der Feldeinrichtung (12) zu zwei bestimmten Zeitpunkten in Beziehung stehen, und wobei die Displayeinrichtung eine Einrichtung zum Ändern des bestimmten Zeitpunkts aufweist, der den Elementen von abgerufenen Einrichtungsdaten für die bezeichnete Gruppe zugeordnet ist, die mit einer der zwei Konfigurationen in Beziehung stehen.

21. Steuerung (58) nach Anspruch 1, die an eine Vielzahl von Feldeinrichtungen (12) gekoppelt werden kann, wobei jede eine ihr zugeordnete Einrichtungsbeschreibung (76) hat, wobei die Steuerung ferner folgendes aufweist:

eine Einrichtung zum Kommunizieren mit der Vielzahl von Feldeinrichtungen (12) und den Einrichtungsbeschreibungen (76), um eine Kommunikation in bezug auf eine Vielzahl von Gruppen logisch miteinander in Beziehung stehender Elemente von Einrichtungsdaten, die in der Vielzahl von Feldeinrichtungen (12) und den Einrichtungsbeschreibungen (76) gespeichert sind, herzustellen, und

wobei die Anweisungseinrichtung eine Einrichtung (324) aufweist, die die Kommunikationseinrichtung so steuert, daß sie die Elemente von Einrichtungsdaten innerhalb der bestimmten einen von der Vielzahl von Gruppen logisch miteinander in Beziehung stehender Elemente von Einrichtungsdaten abruft, um eine abgerufene Gruppe von Elementen von Einrichtungsdaten zu erzeugen.

22. Steuerung (58) nach Anspruch 21, wobei die Implementierungseinrichtung (300, 301) ferner eine auf die Benutzeroberfläche (30) ansprechende Einrichtung aufweist, welche die Kommunikationseinrichtung anweist, eines der Elemente von Einrichtungsdaten innerhalb der bestimmten einen von der Vielzahl von Gruppen von logisch miteinander in Beziehung stehenden Elementen von Einrichtungsdaten zu ändern.

23. Steuerung (58) nach Anspruch 22, wobei die Anweisungseinrichtung aufweist: eine Einrichtung, die bestimmt, ob die Änderung an dem einen der Elemente von Einrichtungsdaten zulässig ist, und eine Einrichtung, die über die Benutzeroberfläche (30) anzeigt, daß die Änderung unzulässig ist, wenn die Bestimmungseinrichtung bestimmt, daß die Änderung unzulässig ist.

24. Steuerung nach Anspruch 22, wobei die Kommunikationseinrichtung eine Einrichtung aufweist, die erkennt, wenn sich ein weiteres der Elemente von Einrichtungsdaten in ein geändertes Element von Einrichtungsdaten ändert, und wobei die Implementierungseinrichtung ferner eine auf die Erkennungseinrichtung ansprechende Einrichtung aufweist, die über die Benutzeroberfläche (30) die Änderung an dem weiteren einen der Elemente von Einrichtungsdaten automatisch anzeigt, wenn das weitere eine der Elemente von Einrichtungsdaten innerhalb der bestimmten einen der Vielzahl von Gruppen von logisch miteinander in Beziehung stehenden Elementen von Einrichtungsdaten ist.

25. Steuerung (58) nach Anspruch 21, wobei das Verwaltungssystem (10) ferner eine Datenbank (40) aufweist, die Elemente von Einrichtungsdaten speichert, wobei die Kommunikationseinrichtung ferner eine Einrichtung zur Kommunikation mit der Datenbank (40) aufweist und wobei die Implementierungseinrichtung ferner eine Einrichtung aufweist, welche die Kommunikationseinrichtung so steuert, daß sie als Teil der abgerufenen Gruppe von Elementen von Einrichtungsdaten die Elemente von Einrichtungsdaten abruft, die der bestimmten einen der Vielzahl von Gruppen von logisch miteinander in Beziehung stehenden Elementen von Einrichtungsdaten zugeordnet und in der Datenbank (40) gespeichert sind.

26. Steuerung (58) nach Anspruch 25, wobei die abgerufene Gruppe von Elementen von Einrichtungsdaten Daten aufweist, die eine von der Vielzahl von Feldeinrichtungen (12) betreffen, und wobei ein erstes Element der abgerufenen Gruppe von Elementen von Einrichtungsdaten eine bildliche Darstellung (400, 402) der einen der Vielzahl von Feldeinrichtungen (12) aufweist.

27. Steuerung (58) nach Anspruch 25, wobei die abgerufene Gruppe von Elementen von Einrichtungsdaten Daten aufweist, die einen Block (414, 416) betreffen, der eines von einem Eingang, einem Ausgang oder einer Steuerfunktion aufweist, die einer von der Vielzahl von Feldeinrichtungen (12) zugeordnet ist, und wobei ein erstes Element der abgerufenen Gruppe von Elementen von Einrichtungsdaten eine bildliche Darstellung (400, 402) des Blocks aufweist.

28. Steuerung (58) nach Anspruch 25, wobei die abgerufene Gruppe von Elementen von Einrichtungsdaten Daten aufweist, die einen Parameter betreffen, der einer von der Vielzahl von Feldeinrichtungen (12) zugeordnet ist, und wobei ein erstes Element der abgerufenen Gruppe von Elementen von Einrichtungsdaten eine Marke des Parameters aufweist und ein zweites Element der abgerufenen Gruppe von Elementen von Einrichtungsdaten einen Wert des Parameters aufweist.

29. Steuerung (58) nach Anspruch 25, wobei die abgerufene Gruppe von Elementen von Einrichtungsdaten Konfigurationsdaten aufweist, die mit der Konfiguration einer von der Vielzahl von Feldeinrichtungen (12) zu einem bestimmten Zeitpunkt in Beziehung stehen, und wobei die Implementierungseinrichtung eine Einrichtung (424) aufweist, die es einem Benutzer erlaubt, den den Konfigurationsdaten zugeordneten bestimmten Zeitpunkt zu ändern.

30. Steuerung (58) nach Anspruch 25, wobei die abgerufene Gruppe von Elementen von Einrichtungsdaten Konfigurationsdaten aufweist, die mit der ersten und der zweiten Konfiguration in Beziehung stehen, die einer oder zwei von der Vielzahl von Feldeinrichtungen (12) zu zwei individuellen Zeitpunkten zugeordnet sind, und wobei die Implementierungseinrichtung eine Einrichtung (424) aufweist, die es einem Benutzer erlaubt, den individuellen Zeitpunkt, der den Konfigurationsdaten zugeordnet ist, die mit der ersten Konfiguration in Beziehung stehen, zu ändern.