-
Die vorliegende Erfindung betrifft
allgemein Prozesssteuersysteme und insbesondere Verfahren und Vorrichtungen
zum Zugriff auf verteilte Daten für Prozesssteuersysteme.
-
Prozesssteuersysteme, wie sie beispielsweise
bei chemischen, Erdöl
verarbeitenden oder anderen Prozessen verwendet werden, enthalten
typischerweise eine oder mehrere zentrale Prozesssteuereinrichtungen,
die über
analoge, digitale oder kombinierte analog/digitale Busleitungen
in Kommunikationsverbindung mit mindestens einem Hauptrechner oder
einer Bedienerworkstation stehen. Die Anlageneinrichtungen, bei
denen es sich beispielsweise um Ventile, Ventilpositioniereinrichtungen,
Schalter und Übertragungseinrichtungen
(beispielsweise Temperatur-, Druck- und Durchflussmengensensoren)
handeln kann, führen
Funktionen innerhalb des Prozesses durch, wie etwa das Öffnen oder
Schließen
von Ventilen und das Messen von Prozessparametern. Die Prozesssteuereinrichtung
empfängt
Signale, die von den Anlageneinrichtungen durchgeführte Prozessmessungen
und/oder andere, die Anlageneinrichtungen betreffenden Informationen
anzeigen, verwendet diese Informationen, um eine Steuerroutine umzusetzen,
und erzeugt dann Steuersignale, die über die Busleitungen oder andere
Kommunikationsleitungen an die Anlageneinrichtungen gesendet werden,
um den Prozessablauf zu regeln bzw. zu steuern. Informationen von
den Anlageneinrichtungen und den Steuereinrichtungen können einer
oder mehreren Anwendungen zur Verfügung gestellt werden, die von
der Bedienerworkstation ausgeführt werden,
um eine Bedienungsperson in die Lage zu versetzen, gewünschte prozessbezogene
Funktionen durchzuführen,
wie etwa den gegenwärtigen Prozesszustand
zu betrachten, den Prozessablauf zu modifizieren etc.
-
Ein Prozesssteuersystem arbeitet
typischerweise in einem Unternehmen, das mehrere Prozesssteueranlagen,
Komponenten und/oder Dienstleistungslieferanten und Kunden enthalten
kann, die alle über
ein großes
geografisches Gebiet oder in einigen Fällen über die ganze Welt verteilt
sein können.
Die Prozesssteueranlagen, Lieferanten und Kunden können miteinander
unter Verwendung einer Vielzahl von Kommunikationsmedien und -techniken
oder -plattformen kommunizieren, wie etwa das Internet, Satellitenverbindungen,
drahtlose terrestrische Übertragungen,
Telefonleitungen etc. Selbstverständlich wurde das Internet zu
einer bevorzugten Kommunikationsplattform für viele Unternehmen, da es
eine bestehende Kommunikationsinfrastruktur bietet und damit die
Kosten der Kommunikationsinfrastruktur für ein Unternehmen minimiert
beziehungsweise reduziert. Zusätzlich
sind die zur Kommunikation von Informationen über das Internet verwendeten
Techniken bekannt, stabil, sicher etc.
-
Jede Prozesssteueranlage innerhalb
eines Unternehmens kann ein oder mehrere Prozesssteuersysteme sowie
eine Reihe von weiteren prozessbezogenen oder Informationstechnologiesystemen enthalten,
die für
die Unterstützung
oder Aufrechterhaltung des gesamten Betriebes des Prozesssteuersystems
erforderlich sind oder dieses ergänzen. Allgemein können die
Informationstechnologiesysteme, die zu einer Prozesssteueranlage
gehören,
Herstellungsdurchführungssysteme,
wie z. B. ein Wartungsverwaltungssystem enthalten, und können ferner Unternehmensressourcenplanungssysteme
enthalten, beispielsweise Planungs-, Buchhaltungs- und Beschaffungssysteme.
Obgleich diese Informationstechnologiesysteme physisch innerhalb
oder nahe bei einer Anlage angeordnet sein können, können in einigen Fällen einige
wenige oder möglicherweise
all diese Systeme in Bezug auf die Anlage entfernt angeordnet sein
und unter Verwendung des Internet oder einer beliebigen anderen
geeigneten Kommunikationsverbindung, die jede gewünschte Kombination von
drahtlosen und/oder drahtgebundenen Kommunikationsmedien und -techniken
verwendet, mit der Anlage kommunizieren.
-
Jeder Prozesssteueranlage innerhalb
eines Unternehmens kann ferner Benutzerinteraktive Anwendungen enthalten,
die auf einem Server oder einer Workstation ausgeführt werden
können,
die mit einem oder mehreren Servern, Workstations oder anderen Computern
in Kommunikationsverbindung steht, welche die Aktivitäten des
Prozesssteuersystems innerhalb der Anlage koordinieren oder ausführen. Derartige
Benutzer-interaktive Anwendungen können Kampagnenverwaltungsfunktionen,
Verwaltungsfunktionen für
Stammdaten, Betriebsmittelverwaltungsfunktionen, Stapelverwaltungsfunktionen etc.
ausführen.
Zusätzlich
kann jedes der Prozesssteuersysteme Prozessverwaltungsanwendungen enthalten,
die beispielsweise die Kommunikation von Alarm- und/oder anderen
Prozessereignissen verwalten und Informationen darüber bereitstellen
können,
Informationen oder Daten bezüglich
des Prozesses oder der Prozesse bereitstellen, die von der Prozesssteueranlage
durchgeführt
werden, Informationen oder Daten bezüglich des Zustands oder der Leistung
von zu der Prozesssteueranlage gehörenden Ausrüstungsgeräten bereitstellen, etc. Insbesondere
können
Prozessverwaltungsanwendungen Vibrationsüberwachungsanwendungen, Echtzeitoptimierungsanwendungen,
Expertensystemanwendungen, vorhersagende Wartungsanwendungen, Regelkreisüberwachungsanwendungen
oder beliebige andere Anwendungen enthalten, wie sich auf die Steuerung, Überwachung
und/oder Aufrechterhaltung eines Prozesssteuersystems bzw. einer
-anlage beziehen.
-
Ferner können eine Prozesssteueranlage oder
ein Unternehmen eine oder mehrere Kommunikationsanwendungen enthalten,
die dazu verwendet werden können,
Informationen von dem Prozesssteuersystem oder der -anlage über eine
Vielzahl von unterschiedlichen Kommunikationsmedien und -plattformen
zu einem Benutzer zu kommunizieren. Diese Kommunikationsanwendungen
können
beispielsweise E-Mail-Anwendungen,
Personenrufanwendungen, Sprachmitteilungsanwendungen, Dateibasierende
Anwendungen etc. einschließen,
die alle Informationen über
drahtlose oder drahtgebundene Medien zu einem Desktop-Computer,
einem Laptop-Computer, einem Personal Data Assistant, einem Mobiltelefon
oder einem Personenrufgerät oder
jeder anderen Art von Geräte-
oder Hardwareplattform senden können.
-
Allgemein ausgedrückt ist es äußerst schwierig, die Kommunikation
zwischen Informationstechnologiesystemen, Benutzer-interaktiven
Anwendungen, Prozessverwaltungsanwendungen und Kommunikationsanwendungen
innerhalb eines Unternehmens zu ermöglichen und zu integrieren,
da diese Systeme und Anwendungen typischerweise über das gesamte Unternehmen
verteilt sind und in einigen Fällen
geografisch weit verstreut sind. Ferner können viele der vorstehend genannten
Systeme und Anwendungen über
handgehaltene oder portable Hardwareplattformen, wie z. B. Laptop-Computer, Mobiltelefone,
Personenrufgeräte,
Personal Data Assistants etc. ausgeführt werden, die vielfach so
konfiguriert sind, dass sie eine Betriebsumgebung schaffen, die
zur Ausführung
von komplizierten Client-Anwendungen
oder Software geeignet ist, darunter beispielsweise Webbrowser oder
dergleichen, die Kommunikationsfunktionen ausführen.
-
Zusätzlich erfordern diese Systeme
und Anwendungen typischerweise die Entwicklung einer kundeneigenen
Kommunikationsschnittstelle oder eines Softwaretreibers, der die
unterschiedlichen Systeme und Anwendungen in die Lage versetzt,
miteinander zu kommunizieren. Das hat zur Folge, dass dann, wenn
sich ein System, eine Anwendung, eine Einrichtung oder eine Komponente
innerhalb des Unternehmens auf Grund beispielsweise eines Firmware-Upgrades,
Geräteaustausches
etc. ändert, auch
die kundeneigene Kommunikationsschnittstelle bzw. der Kommunikationstreiber
für dieses
System, die Einrichtung oder die Komponente möglicherweise geändert werden
muss. Offensichtlich führt
die große
Anzahl der erforderlichen kundeneigenen Treiber zu einem beträchtlichen
Ausmaß von
zeitaufwendiger Treiberwartung, was zu hohen Unternehmenswartungskosten
führt.
Ferner erfordert das Hinzufügen
eines Systems oder einer Anwendung zu einem Unternehmen oder einer
Prozesssteueranlage oftmals einen enormen Programmieraufwand, da
eine Vielzahl von kundeneigenen Kommunikationstreibern oder Schnittstellen
entwickelt werden müssen, um
das neue System oder die Anwendung in die Lage zu versetzen, mit
den anderen Systemen und Anwendungen innerhalb des Unternehmens
zu kommunizieren. Derartige kundeneigene Kommunikationsschnittstellen
nutzende Systeme sind somit nicht sehr flexibel oder skalierbar
und erleichtern beispielsweise nicht die Integration eines Prozesssteuersystems
mit anderen Systemen und Anwendungen, die von dem Hersteller des
Prozesssteuersystems und/oder durch einen Dritthersteller oder Entwickler bereitgestellt
werden können.
-
Jüngere
Entwicklungen, die auf die Verbesserung der Flexibilität und der
Skalierbarkeit von Systemen innerhalb von Unternehmen gerichtet
sind, sind von der Entwicklung und dem Ausbau von verbesserten Betriebssystemen,
wie z. B. Windows XP®, Microsoft.NETTM etc., und Verbesserungen von Kommunikationsprotokollen,
wie z. B. Ethernet, Voice over Internet Protokoll (IP), Streaming
Video etc. begleitet. Zusätzlich
wurden verbesserte Informations- oder Datenübertragungseinrichtungen und
zentrale Datenspeichereinrichtungen und -techniken, wie z. B. die
von Extensible Markup Language (XML), Simple Object Access Protocol
(SOAP), Universal Description, Discovery and Integration (UDDI)
etc. geschaffenen, verbesserte Orchestrierungssysteme oder Server,
wie z. B. Biztalk®, verbesserte Programmiersprachen,
die unabhängig
von den ausführenden
Plattformen sind, wie z.B. Java, und eine Reihe von weiteren verbesserten
Kommunikations- und/oder Datenverwaltungs-Toolprogrammen, -standards, -protokollen,
-Programmiersprachen etc. entwickelt.
-
Während
es durch viele der jüngeren
Entwicklungen einfacher wurde, eine Vielzahl von Systemen, die ein
Unternehmen aufweist, so zu konfigurieren, dass sie miteinander
kommunizieren, hat sich die gesamte Systemarchitektur, innerhalb
welcher diese Systeme zusammenwirken, gegenüber den bekannten Client-Server-Architekturen nicht
wesentlich geändert.
Bei vielen bekannten Client-Server-Architekturen senden Clients erfasste
Daten oder Informationen zu einem Server und empfangen verarbeitete
Resultate von dem Server, die angezeigt und/oder anderweitig von
einem Systembediener verwendet werden können. Zusätzlich enthält und implementiert oder führt der
Server typischerweise Geschäfts-
oder Datenbankregeln für
den Betrieb oder von einem oder mehreren Clients empfangene Prozessdaten
aus.
-
Unglücklicherweise ist die Verwendung
von bekannten Client-Server-Architekturen innerhalb eines Unternehmens,
einer Prozesssteueranlage oder eines Prozesssteuersystems, das eine
Vielzahl von verteilten Systemen hat, die über ein oder mehrere Kommunikationsnetze
kommunizieren, relativ ineffizient, da der Server typischerweise
die Prozessablauflogik, Datenbankregeln und/oder andere datenintensive
Verarbeitungsvorgänge
enthält
und ausführt. Als
Resultat müssen
die Clients sich typischerweise mit einer großen Zahl von umlaufender Kommunikation
mit dem Server beschäftigen
(d. h. Anfragen an den Server nach Informationen oder Daten und
die Ausführung
von Prozesslogik senden und Antwortkommunikationsvorgänge von
dem Server empfangen). Eine große
Anzahl von Umlaufkommunikationsvorgängen innerhalb eines auf bekannten
Client-Server-Architekturen basierenden verteilten Systems kann
ein beträchtliches
Maß der
begrenzten und damit wertvollem Kommunikationsnetz- oder Kanalbandbreite
einnehmen. Beispielsweise ist im Fall von drahtlosen Kommunikationsverbindungen
(beispielsweise zellulären
Verbindungen und Satellitenverbindungen) die Kanalbandbreite relativ
teuer und somit sind die Kosten pro Paket, Bit, etc. relativ hoch. Zusätzlich kann
die Kommunikationskanallatenz (d.h. die Umlaufübertragungszeit) zu beträchtlichen Zeitverzögerungen
führen,
die für
viele prozessorientierte Funktionen, insbesondere Echtzeit-Prozesssteuerfunktionen,
nicht akzeptabel sein können.
-
In jedem Fall werden die Ineffizienz
oder die Schwierigkeiten der Kommunikation auf Grund von Bandbreitenbeschränkungen,
Kosten, Kommunikationskanallatenz etc. in Situationen verstärkt, in
welchen Clients an prozessorientierten Funktionen beteiligt sind
und/oder wenn Server prozessorientierte Prozesslogik implementieren,
da diese prozessorientierten Funktionen und vom Server ausgeführte Prozesslogik
häufige
Datenanfragen und Ausführungen von
Regeln erfordern und somit häufige
Umlaufkommunikationsvorgänge.
Gleichermaßen
sind Clients und/oder Server, die an Verarbeitungsaktivitäten auf Unternehmensebene,
wie beispielsweise Optimierungsaktivitäten des Unternehmens, teilnehmen,
typischerweise ebenfalls an der häufigen Koordination und Kommunikation
von großen
Informations- oder Datenmengen beteiligt. Somit verstärken derartige Aktivitäten auf
Unternehmensebene in ähnlicher
Weise die Schwierigkeiten und Schwächen der Kommunikation bei
bekannten Client-Server-Architekturen (beispielsweise beschränkte Bandbreite,
hohe Datenübertragungskosten,
Kommunikationskanallatenz etc.).
-
Um die an Kommunikationskanäle innerhalb eines
Prozesssteuersystems, einer Anlage und/oder eines Unternehmens gestellten
Anforderungen zu reduzieren (sowie die damit verbundenen Implementierungs-
und Wartungskosten), haben einige Systeme bekannte oder herkömmliche
Client-Server-Architekturen beibehalten, aber haben beträchtliche
Mengen von Daten, Prozesslogik, Datenbankregelausführung und
Datenverarbeitungslogik von den Servern zu den Clients verschoben.
Allgemein werden alle Informationen oder Daten und Regeln, die potenziell
von den Clients verwendet werden könnten, zu einer mit diesen
Clients verbundenen lokalen Speichereinrichtung verlagert. Auf diese
Weise können
die Clients lokal auf benötigte
Informationen, Daten, Regeln etc. zugreifen, um ihre Aktivitäten auszuführen, wodurch das
Ausmaß der
dafür erforderlichen
Netzkommunikation reduziert oder minimiert wird.
-
Unglücklicherweise führt das
Verschieben derartiger beträchtlicher
Mengen von Daten, Regelausführungen
und anderer Verarbeitungsverantwortlichkeiten in die Clientsysteme
hinab zu "umfangreichen" Clients, die schwierig
zu installieren und zu verwalten sind. Ferner führt ein auf der Verwendung derartiger
umfangreicher Clients basierendes System innerhalb eines gemäß bekannten
Client-Server-Architekturen konfigurierten Systems zu Systemen,
die relativ unflexibel sind und nicht ohne weiteres skalierbar sind.
Insbesondere stützen
sich viele Systeme, die vorhandene Client-Server-Architekturen nutzen,
sehr stark auf Ad-hoc-Clientlogik und Datentransportformate. Mit
anderen Worten kann jede der Clientanwendungen ihre eigenen Versionen
von Regeln und Datenbankstrukturen implementieren. Als Resultat
kann eine einfache Datenbankänderung oder
eine Änderung
an einer von mehr als einem Client benutzten Regel eine unabhängige und
zeitaufwändige
Rekonfiguration einer großen
Anzahl von Clientanwendungen erfordern, die möglicherweise die Datenbank
und/oder Regel verwenden könnten. Das
ferner die Clients auf unterschiedlichen Systemtypen basieren können, die
zur verschiedenen Herstellern, Entwicklungsteams etc. gehören können, kann
die spezielle Art und Weise, in der eine gegebene Regel implementiert
werden muss, von Client zu Client beträchtlich variieren, wodurch
Systemwartungsaktivitäten
(beispielsweise Modifikation oder Verbesserungen) sehr kompliziert
und teuer werden. Ferner kann das Hinzufügen eines Clients oder eines Servers
zu einem derartigen vorhandenen Systemen eine zeitaufwendige Konfiguration
des Clients erfordern, um es zu ermöglichen, dass der Client eine oder
mehrere Regeln in gewünschter
Weise ausführt und
um andere Clients und/oder Server innerhalb des Systems in die Lage
zu versetzen, mit dem hinzugefügten
Client oder Server zusammenzuarbeiten. Unglücklicherweise kann der für bereits
existierende Clientanwendungen entwickelte Ad-hoc-Code nicht zur Verwendung
mit neuen Clientanwendungen adaptiert (d.h. wiederverwendet) werden.
Als Resultat führt
das Hinzufügen
einer Clientanwendung zu einem derartigen System typischerweise
zur Entwicklung von zusätzlicher
neuer Ad-hoc-Software oder -Code.
-
Es ist die Aufgabe der Erfindung,
den vorstehend beschriebenen Problemen, die beim Stand der Technik
auftreten, abzuhelfen.
-
Die Lösung der Aufgabe ergibt sich
aus den Patentansprüchen.
Unteransprüche
beziehen sich auf bevorzugte Ausführungsformen der Erfindung, wobei
auch andere Kombinationen von Merkmalen als die beanspruchten möglich sind.
-
Gemäß einem Aspekt senden Systeme
und Verfahren zum Zugriff auf eine zu einem Prozesssteuersystem
gehörende
Datenbank eine Informationsabfrage von einer Clientanwendung an
einen Zwischendatenserverprozess und stellen fest, ob die Information
in einer zu dem Zwischendatenserverprozess gehörenden Datenquelle gespeichert
ist. Die aufgezeigten Systeme und Verfahren können auch eine Informationsabfrage
von dem Zwischendatenserverprozess zu einem anderen Prozess senden, wenn
die Information nicht in der Datenquelle gespeichert ist, und können auf
die Datenbank zugreifen, um die Information abzurufen, nachdem der
andere Prozess die Informationsabfrage empfängt.
-
Gemäß einem weiteren Aspekt enthält ein Prozesssteuersystem
eine Vielzahl von in Kommunikationsverbindung stehenden Zwischendatenservern,
eine Vielzahl von Clientanwendungen, die in Kommunikationsverbindung
mit einem oder mit mehreren der Zwischendatenserver stehen können, und eine
Informationen enthaltende Datenbank, die zumindest Daten und Regeln
enthält,
die zu dem Prozesssteuersystem gehören. Die Zwischendatenserver
sind so ausgelegt, dass sie in jeweiligen lokalen Datenquellen eine
Teilmenge der Informationen in Übereinstimmung
mit den Informationsbedürfnissen mindestens
einiger der Clientanwendungen in Zusammenwirkung auslesen und speichern.
-
Nachfolgend wird die Erfindung unter
Bezug auf die Zeichnung im Detail beschrieben.
-
1 ist
ein Blockdiagramm eines Abschnitts eines Beispielunternehmens, in
dem die hierin beschriebene Vorrichtung und Verfahren umgesetzt
werden können.
-
2 ist
eine schematische Darstellung eines Beispieldatenbankschemas, das
auf einer bekannten Objekthierarchie basiert und das zur Umsetzung
der aufgezeigten Vorrichtung und der Verfahren verwendet werden
kann.
-
3 ist
eine schematische Darstellung einer Beispielobjektkonfiguration,
die mit der aufgezeigten Vorrichtung und den Verfahren verwendet werden
kann.
-
4 ist
ein Blockdiagramm, das ein Beispielsystem darstellt, das eine Vielzahl
von Zwischendatenservern zeigt, die zum Zugriff auf eine Datenbank
zusammenwirken.
-
5 ist
eine detaillierte schematische Ansicht, die ein Beispiel einer Art
und Weise darstellt, in der Clientanwendungen auf Informationen
oder Daten zugreifen können,
die innerhalb einer Datenquelle gespeichert sind, die zu einem Zwischendatenserver
gehört.
-
6 ist
ein Blockdiagramm eines Beispielsystems, das eine Vielzahl von Verarbeitungssystemen
hat, die Zwischendatenserver zum Zugriff auf eine Datenbank nutzen.
-
1 ist
ein Blockdiagramm eines Beispielunternehmens 10, das die
hierin beschriebene verteilte Datenvorrichtung und die Verfahren
verwenden kann. Wie 1 zeigt,
enthält
das Unternehmen 10 ein Prozesssteuersystem 12 mit
einer Steuereinrichtung 14, einer Bedienungsstationen 16 und
Workstations 18 und 20, die alle über einen
Bus oder ein lokales Datennetz (LAN) 22 in Kommunikationsverbindung
stehen können,
was allgemein als ein Anwendungssteuernetz (ACN) bezeichnet wird.
Die Workstations 18 und 20 können als Anwendungsstationen konfiguriert
sein, die eine oder mehrere Informationstechnikanwendungen, Benutzer-interaktive
Anwendungen und/oder Kommunikationsanwendungen ausführen. Beispielsweise
kann die Anwendungsstation 18 so konfiguriert sein, dass
sie hauptsächlich auf
die Prozesssteuerung bezogene Anwendungen ausführt, wohingegen die Anwendungsstation 20 so konfiguriert
sein kann, dass sie hauptsächlich
Kommunikationsanwendungen ausführt,
die das Prozesssteuersystem 12 in die Lage versetzen, mit
anderen Vorrichtungen oder Systemen unter Verwendung von beliebigen
gewünschten
Kommunikationsmedien (beispielsweise drahtlos, drahtgebunden etc.)
und Protokollen (beispielsweise HTTP, SOAP etc.) zu kommunizieren.
Selbstverständlich
können
die Bedienungsstationen 16 und die Workstations 18 und 20 unter
Verwendung einer oder mehrerer Workstations oder eines beliebigen
anderen geeigneten Computersystems oder Verarbeitungssystems implementiert
werden. Beispielsweise könnten
die Bedienungsstationen und/oder Workstations 18 und 20 unter
Verwendung von Einzelprozessor-Personalcomputern, Einzel- oder Multiprozessor-Workstations
etc. implementiert sein.
-
Das LAN 22 kann unter Verwendung
jedes gewünschten
Kommunikationsmediums und -protokolls implementiert sein. Beispielsweise
kann das LAN 22 auf einem drahtgebundenen oder drahtlosen Ethernet-Kommunikationsschema
basieren, das bekannt ist und hier somit nicht im Detail beschrieben wird.
Wie jedoch vom Durchschnittsfachmann ohne weiteres zu erkennen ist,
könnte
jedes andere geeignete Kommunikationsmedium und -protokoll verwendet
werden. Obgleich ferner nur ein einzelnes LAN gezeigt ist, können mehr
als ein LAN und geeignete Kommunikationshardware innerhalb der Bedienungsstationen 16 und
der Workstations 18 und 20 verwendet werden, um
redundante Kommunikationswege zwischen diesen Systemen zu schaffen.
Die Steuereinrichtung 14 kann mit einer Vielzahl von intelligenten
Anlageneinrichtungen 24, 26 und 28 über einen
digitalen Datenbus 30 und eine Eingabe/Ausgabeeinrichtung
(I/O) 32 verbunden sein. Die intelligenten Anlageneinrichtungen 24–28 können Fieldbus-konforme
Ventile, Betätigungseinrichtungen, Sensoren
etc. sein, und in diesem Fall kommunizieren die intelligenten Anlageneinrichtungen 24–28 über den
digitalen Datenbus 30 unter Verwendung des bekannten Fieldbus-Protokolls.
Selbstverständlich
können
an Stelle dessen andere Arten von intelligenten Anlageneinrichtungen
und Kommunikationsprotokollen verwendet werden. Beispielsweise können die
intelligenten Anlageneinrichtungen 94-28 an Stelle dessen Profibus- oder
HART-konforme Einrichtungen sein, die über den Datenbus 30 unter
Verwendung des bekannten Profibus- oder HART-Kommunikationsprotokolls
kommunizieren. Zusätzliche I/O-Einrichtungen
(ähnlich
der oder identisch mit der I/O-Einrichtung 32) können mit
der Steuereinrichtung 14 verbunden sein, um zusätzlichen
Gruppen von intelligenten Anlageneinrichtungen, bei denen es sich um Fieldbus-Einrichtungen,
HART-Einrichtungen etc. handeln kann, die Kommunikation mit der
Steuereinrichtung 14 zu ermöglichen.
-
Zusätzlich zu den intelligenten
Anlageneinrichtungen 24–28 können eine
oder mehrere nicht intelligente Anlageneinrichtungen 34 und 36 mit
der Steuereinrichtung 14 in Kommunikationsverbindung stehen.
Die nicht intelligenten Anlageneinrichtungen 34 und 36 können beispielsweise
herkömmliche 4–20 Milliampere
(mA)- oder 0–10
Volt Gleichstrom (VDC)- Einrichtungen sein, die mit der Steuereinrichtung 14 jeweils über drahtgebundene
Verbindungen 38 und 40 kommunizieren.
-
Die Steuereinrichtung 14 kann
beispielsweise eine DeltaVTM-Steuereinrichtung
sein, die von Fisher-Rosemount Systems, Inc. vertrieben wird. Es kann
jedoch jede andere Steuereinrichtung an Stelle dessen verwendet
werden. Während
in 1 nur eine Steuereinrichtung
gezeigt ist, können
ferner zusätzliche
Steuereinrichtungen jedes gewünschten Typs
oder jeder Kombination von Typen mit dem LAN 22 verbunden
werden. In jedem Fall kann die Steuereinrichtung 14 eine
oder mehrere zu dem Prozesssteuersystem 12 gehörende Prozesssteuerroutinen ausführen, die
von einem Systemtechniker oder einem anderen Systemoperator unter
Verwendung der Bedienungsstation 16 erzeugt wurden und
die in die Steuereinrichtung 14 heruntergeladen und darin
instanziert wurden.
-
Wie 1 zeigt,
kann das Unternehmen 10 ferner eine Workstation 42 enthalten,
die über
eine Kommunikationsverbindung 44, das LAN 46 und
die Workstations 18 und 20 mit dem Prozesssteuersystem 12 in
Kommunikationsverbindung steht. Die Workstation 42 kann
so konfiguriert sein, dass sie Funktionen auf Unternehmensebene
ausführt,
kann zu einem anderen Prozesssteuersystem (nicht dargestellt) gehören und
so konfiguriert sein, dass sie hauptsächlich Prozesssteuerungsfunktionen
ausführt,
kann so konfiguriert sein, dass sie eine oder mehrere Kommunikationsfunktionen
durchführt,
etc. Des weiteren kann die Workstation 42 geografisch entfernt
angeordnet sein, und in diesem Fall handelt es sich bei der Kommunikationsverbindung 44 beispielsweise
um eine drahtlose Kommunikationsverbindung, ein auf dem Internet
basierendes oder ein anderes Teilnehmer-Kommunikationsnetz auf Paketbasis,
Telefonleitungen (beispielsweise digitale Teilnehmerleitungen) oder
eine Kombination daraus.
-
Das Beispielunternehmen 10 ist
vorgesehen, um einen Typ eines Systems zu erläutern, in dem die nachfolgend
im Detail beschriebenen Datenverteilungsverfahren sowie die Vorrichtung
in vorteilhafter Weise verwendet werden können. Die hierin beschriebene
Datenverteilungsvorrichtung sowie die Verfahren können jedoch
auf Wunsch in vorteilhafter Weise in anderen Systemen mit größerer oder
geringerer Komplexität
als das in 1 gezeigte
Beispielunternehmen und/oder in Systemen verwendet werden, die in
Zusammenhang mit Prozesssteuerungsaktivitäten, Unternehmensverwaltungsaktivitäten, Kommunikationsaktivitäten etc.
genutzt werden.
-
Die hierin beschriebenen Datenverteilungsvorrichtungen
und die Verfahren verwenden ein hierarchisches Objekt-orientiertes
Datenbankschema in Verbindung mit einer Vielzahl von miteinander
verbundenen oder in Kommunikationsverbindung stehenden Zwischendatenservern,
um die Effizienz zu maximieren, mit der Clientanwendungen auf Daten und/oder
Regeln zugreifen können,
die in einer gemeinsamen Datenbank gespeichert sind. Genauer ausgedrückt können die
Zwischendatenserver Informationen nutzen, die mit den erwarteten
oder vorbestimmten Informations- oder Datenanforderungen von Clientanwendungen
in Zusammenhang stehen, um selektiv Informationen oder Daten aus
einer Datenbank auszulesen und diese selektiv abgerufenen Informationen
oder Daten lokal zu speichern, um die Clientanwendungen in die Lage
zu versetzen, rascher und effizienter auf die Daten oder Informationen
zuzugreifen.
-
Zusätzlich zu den lokal gespeicherten
Daten können
die Zwischendatenserver auch Prozess- oder Datenbankregeln nach
Bedarf lokal speichern und ausführen.
Auf diese Weise können
die Zwischendatenserver, wenn sie einmal mit den von den lokalen
Clientanwendungen benötigten
Informationen oder Daten geladen wurden, das Ausmaß der Umlaufkommunikation
(und der Zeit) beträchtlich
reduzieren, die zur Durchführung
der Aktivitäten
der Clientanwendungen erforderlich sind. Mit anderen Worten speichern
die Zwischendatenserver lokal (beispielsweise durch cachen) eine
ausreichende Menge an Informationen und der zugehörigen Regeln.
Diese Informationen und Regeln sind typischerweise eine Teilmenge
der Informationen und Regeln, die aus einer Unternehmensdatenbank
ausgelesen werden, wodurch lokale Clientanwendungen in die Lage
versetzt werden, rasch auf benötigte
Informationen und Regeln zuzugreifen und eine Vielzahl von aufeinanderfolgenden
Operationen durchzuführen, bevor Änderungen
an die Datenbank zurück
festgeschrieben werden. Als Resultat können die Clientanwendungen
das Ausmaß der
Datenlatenz (auf Grund der Kommunikationskanallatenz) minimieren,
die in die Ausführung
von Clientanwendungen eingeführt wird,
die den Zugriff auf Informationen, Daten und/oder Regeln benötigen, die
ursprünglich
von einer zentralen oder gemeinsamen Datenbank stammen (beispielsweise
eine Datenbank auf Anlagenebene oder Unternehmensebene). Die durch
eine derartige Verteilung von Daten und zugehörigen Regeln gewonnenen Verarbeitungsgeschwindigkeitseffizienzen
sind beträchtlich,
insbesondere in solchen Fällen,
in denen auf den zentralen Datenverwahrungsort oder die Datenbank
durch eine große
Anzahl von Systemen zugegriffen wird, die über ein gesamtes Unternehmen
verteilt sind, und in denen die Kommunikationsverbindungen zwischen
den Clientanwendungen und der Datenbank stark belastet sind (d.
h. nahe an oder über
ihrer Eigenkapazität
sind, um die von den mit den Verbindungen verbundenen Systemen angeforderten
Informationen zu liefern).
-
2 ist
eine schematische Ansicht eines Beispieldatenbankschemas, das auf
einer bekannten Objekthierarchie basiert und das verwendet werden kann,
um die hierin beschriebene Datenverteilungsvorrichtung und die Verfahren
zu implementieren. Allgemein ausgedrückt ist das in 2 gezeigte Beispieldatenbankschema als
ein Netz von hierarchisch in Beziehung stehenden Objekten strukturiert.
Mit anderen Worten ist das in 2 gezeigte
Datenbankschema so strukturiert, dass es Informationen in elementarer
Weise darstellt, sodass praktisch jedes Informationsstück innerhalb
der Hierarchie als separates Objekt dargestellt ist. Das in 2 gezeigte spezielle Beispiel
ist typisch für
ein Schema, das verwendet werden kann, um die Steuersystemaspekte
eines Prozesssteuersystems oder eines Unternehmens, wie etwa des
Unternehmens 10 und des Steuersystems 12 in 1 darzustellen. Selbstverständlich ist das
Datenbankschema aus 2 nur
ein Beispiel und an Stelle dessen könnten viele andere Schemata verwendet
werden. Beispielsweise können
die Implementierungen der Schemata in Abhängigkeit davon variieren, ob
ein bestimmtes Schema während
der Laufzeit, für
Offline-Editier- oder Konfigurationsaktivitäten oder für einen anderen Zweck verwendet
werden soll.
-
Wie die Beispielhierarchie in 2 zeigt, ist ein Standortobjekt 50 (STANDORT),
das eine physische Werksanlage darstellt, die ein Teil eines Unternehmens
oder ein gesamtes Unternehmen, wie etwa das in 1 gezeigte Unternehmen 10 sein
kann, aus einer Vielzahl von Bereichsobjekten 52 und 54 (BEREICH
A und BEREICH B) zusammengesetzt. Die Bereichsobjekte der 52 und 54 gehören zu bestimmten
physischen Bereichen innerhalb der von dem Standortobjekt 50 dargestellten
Anlage. Beispielsweise kann das Bereichsobjekt 52 zu einem
bestimmten Abschnitt eines Produktionsprozesses an einem bestimmten
physischen Ort einer Anlage gehören
und das Bereichsobjekt 54 kann zu einem anderen Abschnitt
dieses Produktionsprozesses (oder eines anderen Produktionsprozesses)
gehören,
der an einem anderen physischen Ort der von dem Standortobjekt 50 dargestellten
Anlage positioniert sein kann.
-
Die Bereichsobjekte 52 und 54 sind
aus jeweiligen Steuermodulen 56 (MOD A), 58 (MOD
B), 60 (MOD B) und 62 (MOD C) zusammengesetzt. Steuermodule
enthalten Steuerroutinen, die instanziert und ausgeführt werden
können,
um Steuerfunktionen oder Aktivitäten
durchzuführen,
die zu ihren jeweiligen Anlagenbereichen gehören. Genauer ausgedrückt kann
jedes der Steuermodule 56–62 zu
einem oder mehreren Stücken
der physischen Geräte oder
Einrichtungen gehören
und kann somit verwendet werden, dieses Gerät oder diese Einrichtungen zu überwachen
und/oder zu steuern. Obgleich die Beispielhierarchie aus 2 die Bereiche 52 und 54 jeweils
so darstellt, dass sie zwei Steuermodule haben, könnten zu
jedem der Bereiche 52 und 54 ein einzelnes oder
mehr als zwei Steuermodule gehören.
-
Jedes der Module 56–62 kann
aus weiteren Objekten und Unterobjekten zusammengesetzt sein. Zum
Zweck der Erörterung
sind derartige Objekte und Unterobjekte nachfolgend nur in Verbindung
mit dem Modul 58 (MOD B) beschrieben. Wie 2 zeigt, kann das Modul 58 mit
einem oder mehreren Attributen 64 und 66 (ATTR2
und ATTR1) und einem oder mehreren Funktionsblöcken 68 und 70 (BLOCK 1
und BLOCK 2) in Zusammenhang stehen. Die Attribute 64 und 66 können Parameter
sein, wie beispielsweise Eingabevariable, Ausgabevariable oder dergleichen,
die zu den physischen und/oder Steuerungsbedingungen innerhalb einer
Anlage oder eines Unternehmens gehören. Die Funktionsblöcke 68 und 70 können jeweils
eine oder mehrere mathematische Funktionen (beispielsweise Summierungsoperationen, Multiplikationsoperationen,
Divisionsoperationen etc.), logische Funktionen oder Ausdrücke (beispielsweise
logische ODER-Verknüpfungen, UND-Verknüpfungen
etc.) oder jede andere gewünschte
Funktion enthalten. Jeder der Funktionsblöcke 68 und 70 kann
auch mit einem oder mit mehreren Attributen 72 und 74 in
Zusammenhang stehen.
-
Zusätzlich zu Attributen und Funktionsblöcken können die
Module 58 ferner mit einem Algorithmus 78 in Zusammenhang
stehen, der aus einer oder mehreren Softwareroutinen zusammengesetzt
sein kann, die eine Abfolge von mathematischen und/oder logischen
Operationen durchführen.
Ferner kann die in 2 gezeigte
Beispielhierarchie ein oder mehrere Drahtobjekte 80 (DRAHT)
enthalten, die grafischen Darstellungen von Drähten entsprechen, die in Verbindung
mit der grafischen Darstellung der gesamten, durch das Beispiel
in 2 dargestellten Steuerhierarchie
verwendet werden.
-
Ein Objekthierarchie- und Datenbankschema
wie das in dem Beispiel in 2 gezeigte
versetzt einen Benutzer oder einen Systemoperator in die Lage, über eine
grafische Benutzerschnittstelle oder dergleichen jede gewünschte Ebene
an Details oder Informationen über
die Konfiguration einer Anlage und ihrer Steuersysteme freizulegen,
die durch diese Objekthierarchie dargestellt sind. Mit anderen Worten
kann ein Benutzer oder Systemoperator die Hierarchie durchlaufen
(d. h. sich durch die Hierarchie bewegen), und zwar von einem Objekt
zu einem oder mehreren zugehörigen
Unterobjekten, um jede beliebige benötigte Detailebene freizulegen.
Nachdem er beispielsweise die zu dem Bereichsobjekt 52 (BEREICH
A) gehörenden
Informationen oder Daten freigelegt hat, kann ein Benutzer die Hierarchie durchqueren,
um die zu dem Modul 58 (MOD B) gehörenden Informationen oder Daten
freizulegen, und dann wiederum eines der Objekte 64–80,
die zu dem Modul 58 gehören.
-
3 ist
eine detailliertere schematische Ansicht einer Beispielobjektkonfiguration 100,
die mit den hierin beschriebenen Verfahren und der Vorrichtung verwendet
werden kann. Die in 3 gezeigte Beispielobjektkonfiguration
kann verallgemeinert werden und als zu Grunde liegende Struktur
oder Schablone zum Aufbau jedes der in 2 gezeigten Objekte und Unterobjekte
verwendet werden. Wie 3 zeigt, enthält die Objektkonfiguration 100 einen
Hauptobjektabschnitt 102 und einen zugehörigen Objektabschnitt 104.
Der Hauptobjektabschnitt 102 enthält ein zugehöriges Objekt 106,
Eigenschaften 108 und eine Rolle 110. Das zugehörige Objekte 106 kann
unter anderen Informationen oder Daten den Namen des durch den Hauptobjektabschnitt 102 dargestellten
Objekts sowie eine eindeutige Identifikation enthalten. Die Eigenschaften 108 können Charakteristika
des Typs des zugehörigen
Objekts 106 enthalten, wie z. B. eine Beschreibung und
eine Abtastrate in dem Fall, in dem der Hauptobjektabschnitt 102 ein
Modul ist.
-
Die Rolle 110 charakterisiert
die Verbindung zwischen dem zugehörigen Objekt 106 und
einem oder mehreren zugehörigen
Objekten 112 und 114 innerhalb des zugehörigen Objektabschnitts 104.
Die Rolle 110 charakterisiert die Verbindung (d. h. Straddle
oder Schnittstelle) zwischen dem zugehörigen Objekt 106 und
den zugehörigen
Objekten 112 und 114 in Vorwärts- und Rückwärtsrichtung. Diese Charakterisierung
kann beispielsweise Informationen enthalten, die die zulässige Multiplizität und die
zulässige
Propagation von Operationen zwischen dem zugehörigen Objekt 106 und
den zugehörigen
Objekten 112 und 114 betreffen. Beispielsweise
kann ein Objekt des Modultyps mehrere Instanzen eines bestimmten
Blockobjekts haben. Jede einzelne dieser Verwendungen kann jedoch
nur zu einem einzelnen Modul gehören.
Wenn zusätzlich
die Verwendung eines Blockobjekts gelöscht wird (beispielsweise über eine
Benutzerschnittstelle), werden alle Attribute und Blöcke innerhalb
dieses Blockobjekts (d. h. die davon abhängigen Attribute und Blöcke) ebenfalls
gelöscht. Es
kann jedoch erwünscht
sein, das Löschen
eines Knotens (beispielsweise eines Bereichs oder eines Standorts)
zu verhindern, wenn dieser Knoten gegenwärtig zugewiesene Module hat.
-
In einem bestimmten Beispiel kann
der Hauptobjektabschnitt 102 beispielsweise dem Modul 58 (d.
h. MOD B) entsprechen, und somit können die Eigenschaften 108 dann
einer Beschreibung und einer Abtastrate entsprechen. Die Rolle 110 kann
das Modul 58 (d. h. das zugehörige Objekt 106) mit
den Attributen 64 und 66 (d. h. den zugehörigen Objekten 112 und 114)
verbinden und kann ferner festlegen, dass die Attribute in Vorwärtsrichtung
(d. h. von den zugehörigen
Objekten 112 und 114) zu dem zugehörigen Objekt 106 zu
propagieren sind und dass Löschungen
von dem zugehörigen
Objekt 106 zu den zugehörigen
Objekten 112 und 114 (d. h. von dem Modul 58 zu
den Attributen 64 und 66) zu propagieren bzw.
weiterzuleiten sind.
-
Die in 2 und 3 gezeigte und vorstehend beschriebene
Beispiel-Objekthierarchie und Objektstruktur ermöglicht es einem Benutzer oder
Systemoperator, eine Datenbank zu schaffen, die die Konfigurationsinformationen
(beispielsweise Steuerkonfigurationsinformationen, physische Konfigurationsinformationen
etc.) eines Prozesssteuersystems, einer Anlage oder eines Unternehmens
enthält.
Eine derartige hierarchische Datenbank kann ohne weiteres durchquert
oder durchwandert werden, um jede gewünschte Art und jede Menge an
Details freizulegen, die sich auf Aspekte des durch die Datenbank
dargestellten Systems beziehen.
-
Frühere oder bekannte Systeme
unterhielten typischerweise eine Objektstruktur wie die in 2 und 3 gezeigte in einer zentralen Verwahrungsstelle oder
einem Server, der eine Datenbank aufrechterhielt, die durch eine
oder mehrere Clientanwendungen oder andere Geräte durch ein Kommunikationsnetz
zugreifbar war. Ferner wurden zu den Informationen in der Datenbank
gehörende
Regeln typischerweise innerhalb der Datenbank gespeichert und von dem
Server für
die Clientanwendungen ausgeführt. Somit
haben sich Clientanwendungen in bekannten Systemen für ihre Datenerfordernisse,
Regelverarbeitungserfordernisse etc. auf einen zentralen Server gestützt. Als
Folge nimmt mit der wachsenden Komplexität von Unternehmen oder anderen
Systemen die Menge der über
das Kommunikationsnetz, welches die Clients und die Server miteinander
verbindet, transportierten Kommunikationsvorgänge dramatisch zu, wodurch
die Ausführungsgeschwindigkeit
und die Verarbeitungseffizienz der Clientanwendungen beträchtlich
vermindert wird.
-
Die nachfolgend als Beispiel beschriebenen Zugriffsverfahren
und Vorrichtungen für
verteilte Daten nutzen einen oder mehrere Zwischendatenserver, um
Informationen und Regelinformationen für den lokalen Zugriff und die
Ausführung
durch Clientanwendungen zu verteilen. Mit anderen Worten kann eine
objektbasierte hierarchische Datenbank, wie etwa eine in einer dem
Beispiel aus 2 ähnlichen oder
identischen Weise aufgebaute, innerhalb einer zentralen Datenverwahrungsstelle
(beispielsweise einem Server) resident sein und die Zwischendatenserver
können
Ladeabschnitte dieser Datenbank zusammen mit den zugehörigen Regeln
gemäß dem Bedarf
von Clientanwendungen, die in Bezug auf die Zwischendatenserver
lokal sind, anfordern. Obgleich Daten und Regeln nach Anforderung
gemäß dem Bedarf
durch Clientanwendungen geladen werden können, können einige oder alle Daten
und/oder Regeln vor der Ausführungszeit
in den lokalen Speicher geladen werden. Beispielsweise können der
gleiche Satz oder die gleichen Regeln unter Verwendung einer gemeinsamen
Gruppe von .net assemblies (beispielsweise DLLs) an jedem der Client-Orte
lokal geladen werden. Wenn in diesem Fall angeforderte Daten während der
Ausführungszeit
an einem bestimmten Client-Prozess ankommen, werden die Daten automatisch
unter Verwendung des lokal gespeicherten Regelsatzes in eine geeignete
hierarchische Datenstruktur umgewandelt.
-
In jedem Fall können die hierin beschriebenen
Beispiele von Datenzugriffsverfahren und Vorrichtungen Datenbankinformationen
und zugehörige Regeln
an Zwischendatenserver verteilen, die für Clientanwendungen lokal oder
naheliegend sind, im Gegensatz zu dem Erfordernis, dass alle Clientanwendungen
für ihre
Informationsbedürfnisse
und Regelverarbeitungsbedürfnisse
eine Schnittstelle mit einer einzigen zentralen Datenbank bilden
müssen,
die in einem Server resident ist. Somit können die hierin beschriebenen
Datenverteilungsvorrichtungen und die Verfahren verwendet werden,
um das Ausmaß der
Netzkommunikation (beispielsweise Umlaufkommunikationsvorgänge) zu
reduzieren oder zu minimieren, die erforderlich sind, um die Clientanwendungen
in die Lage zu versetzen, auf benötigte Daten zuzugreifen und
ihre Funktionen durchzuführen,
was zu rascheren Ausführungszeiten
für die
Clientanwendungen und zu verbesserter Aktualität der Anwendungen führt.
-
4 ist
ein Blockdiagramm, das ein Beispielsystem 120 darstellt,
das eine Vielzahl von in Kommunikationsverbindung stehenden Datenserverprozessen 122 und 124 hat,
die zusammenwirken, um auf eine Datenbank 126 zuzugreifen.
Der Datenserverprozess 122 ist ein Zwischendatenserverprozess,
der in einer Workstation oder einem Prozessorsystem (beispielsweise
einer der Workstations 18, 20 und 42 aus 1) durchgeführt werden
kann und der in der Nähe
einer oder mehrerer Clientanwendungen 128 und 130 ist
und mit diesen in Kommunikationsverbindung steht. Die Clientanwendungen 128 und 130 können innerhalb
der gleichen Workstation oder des gleichen Prozessorsystems wie
der Zwischendatenserverprozess 122 instanziert sein und/oder
einer anderen Workstation oder einem anderen Prozessorsystemen,
das mit den Clientanwendungen 128 und 130 in Kommunikationsverbindung
steht.
-
Der Zwischendatenserverprozess 122 enthält einen
Zwischendatenserver 132 und eine Session 134,
die den Austausch von Informationen oder Daten zwischen einer lokalen
Datenquelle 136 und einer Datenbankverbindung 138 koordiniert.
Allgemein ausgedrückt
durchläuft
dann, wenn der Zwischendatenserver 132 eine Datenabfrage
von einer oder mehreren der Clientanwendungen 128 und 130 empfängt, der
Zwischendatenserver 132 die Datenquelle 136 über die
Session 134, um zu bestimmen, ob die abgefragten Informationen
oder Daten lokal verfügbar
sind (d. h. innerhalb der Datenquelle 136 des Zwischendatenserverprozesses 122 verfügbar sind).
Eine detailliertere Beschreibung der Art und Weise, in der die Session 134 die
Datenquelle 136 durchläuft,
wird nachfolgend in Verbindung mit 5 gegeben.
-
Obgleich in 4 nicht dargestellt, kann jede der Clientanwendungen 128 und 130 jeweils
eine Session, eine Datenquelle und eine Datenbankverbindung enthalten,
die identisch mit oder ähnlich
der Session 134, der Datenquelle 136 und der Datenbankverbindung 138 sind,
die in Verbindung mit dem Zwischendatenserverprozess 122 dargestellt
ist. Auf diese Weise können
die Clientanwendungen 128 und 130 direkt mit dem
Datenserverprozess 124 kommunizieren (d. h., die Clientanwendungen 128 und 130 müssen nicht
durch den Zwischendatenserverprozess 122 mit dem Datenserverprozess 124 kommunizieren).
-
Wenn die von den Clientanwendungen 128 oder 130 angeforderte
Information von der Datenquelle 136 nicht lokal verfügbar ist,
veranlasst die Session 134 die Datenbankverbindung 138,
eine Informationsanforderung an den Zwischendatenserver 124 über eine
Kommunikationsverbindung 140 zu senden. Zusätzlich oder
alternativ in dem Fall, dass die Clientanwendung 130 Daten
angefordert hat, die in der Datenbank 126 resident sind,
könnte
die Clientanwendung 130 diese Daten oder Informationen direkt
von dem Datenserverprozess 124 über eine Kommunikationsverbindung 141 anfordern.
Selbstverständlich
könnte
die Clientanwendung 128 ebenfalls Informationen direkt
von dem Datenserverprozess 124 über ihre eigene Verbindung
(nicht dargestellt) anfordern. In jedem Fall können die Kommunikationsverbindungen 140 und 141 unter
Verwendung jeder gewünschten Kombination
von drahtlosen oder drahtgebundenen Medien implementiert werden
und können
jede gewünschte
Kombination von Kommunikationsprotokollen oder -techniken verwenden.
Beispielsweise können
die Kommunikationsverbindungen 140 und 141 Telefonleitungen
und/oder ein Paketvermittlungs-Kommunikationsnetz (beispielsweise
das Internet) einschließen.
Die über
die Kommunikationsverbindungen 140 transportierten Daten
oder Informationen werden vorzugsweise, jedoch nicht notwendigerweise,
unter Verwendung einer Extensible Markup Language (XML) formatiert
und unter Verwendung eines Transportmechanismus übertragen, der beispielsweise
auf dem bekannten Transmission Control Protocol (TCP) oder dem Hypertext Transport
Control Protocol (HTTP) basiert. Zusätzlich kann in Verbindung mit
Informationen, die unter Verwendung von HTTP gesendet werden, ein
Mitteilungscodierungsprotokoll, wie z. B. das Simple Object Accesss
Protocol (SOAP) verwendet werden.
-
Der Datenserverprozess 124 enthält einen Zwischendatenserver 142,
einen Sessionsprozess 144, eine Datenquelle 146 und
einen Datenbankaccessor 148, der für den Zugriff auf die Datenbank 126 verwendet
wird. Der Zwischendatenserver 142 empfängt Anforderungen von Informationen
oder Daten von dem Zwischendatenserverprozess 122 über die Kommunikationsverbindung 140 und/oder
von einer oder mehreren der Clientanwendungen 128 und 130 beispielsweise über die
Kommunikationsverbindung 141. Wie vorstehend beschrieben
werden derartige Anforderungen von Daten oder Informationen durch einen
Sessionsprozess koordiniert und über
eine Datenbankverbindung in dem Fall befördert, in dem der Sessionsprozess
die Datenquelle durchläuft
und bestimmt, dass die angeforderte Information oder die Daten lokal
nicht zur Verfügung
stehen (beispielsweise innerhalb des lokalen Zwischendatenserverprozesses
gecached sind). Der Zwischendatenserver 142 verwendet seinen
Sessionsprozess 144, um seine lokale Datenquelle 146 zu
durchlaufen, um zu bestimmen, ob die angeforderte Information (d.
h. die ursprünglich
von einer oder mehrerer der Clientanwendungen 128 und 130 angeforderte
Information) lokal verfügbar
ist (beispielsweise in dem Zwischendatenserverprozess 124 gecached).
Wenn der Sessionsprozess 144 feststellt, dass die angeforderte
Information oder die Daten innerhalb der Datenquelle 146 nicht
verfügbar
sind, liest der Sessionsprozess 144 die angeforderte Information
oder die Daten aus der Datenbank 126 über den Datenbankaccessor 148 aus.
Der Datenbankaccessor 148 kann jeder gewünschte Datenbankserverprozess
sein, der in einer hierarchisch arrangierten, Objekt-orientierten
Datenbank, wie etwa der in 2 gezeigten
Beispieldatenbankstruktur, gespeicherte Informationen oder Daten freigibt.
-
Sobald die angeforderten Informationen
oder Daten aus der Datenbank 126 ausgelesen wurden, werden
die Informationen oder Daten von dem Zwischendatenserverprozess 124 über die
Kommunikationsverbindung 140 zu dem Zwischendatenserverprozess 122 transportiert
und/oder direkt zu einer oder mehreren der Clientanwendungen 128 und 130 beispielsweise über die
Verbindung 141 transportiert. In dem Fall, dass der Zwischendatenserverprozess 122 die
abgerufenen Informationen oder Daten über die Datenbankverbindung 138 empfängt, transportiert
er die abgerufenen Informationen oder Daten zu den Clientanwendungen 128 und 130 die
ursprünglich
die Informationen oder Daten über
den Sessionsprozess 134 und den Zwischendatenserver 132 angefordert
haben.
-
Somit verwendet der Zwischendatenserverprozess 122 seine
lokale Datenquelle 136 (beispielsweise einen lokalen Cache),
um Informationen oder Daten zu speichern, die von den Clientanwendungen 128 und 130 benötigt werden,
wenn derartige Informationen von den Clientanwendungen 128 und 130 benötigt werden
(d. h. auf Anfrage). In dem Fall, dass der Zwischendatenserverprozess
am gleichen Ort oder nahe an einer Clientanwendung ist, die Informationen
oder Daten anfordert (beispielsweise eine der Clientanwendungen 128 und 130),
und der lokale Datenserverprozess 122 die angeforderten
Informationen gegenwärtig
nicht in seiner lokalen Datenquelle verfügbar hat (beispielsweise der
Datenquelle 136), kann eine Anforderung für diese
Informationen oder Daten durch einen oder mehrere andere Zwischendatenserverprozesse
(beispielsweise den Zwischendatenserverprozess 124) zu
einem Server oder anderem Prozess weitergeleitet werden, der schließlich Zugriff
auf eine Datenbank (beispielsweise die Datenbank 126) hat,
welche die gesamte Konfigurationsdatenbank enthält, die zu dem Unternehmen
(beispielsweise dem Unternehmen 10) oder dem anderen System,
in dem die Clientanwendung arbeitet, gehört.
-
Obgleich das in 4 gezeigte Beispiel zwei Zwischendatenserverprozesse
darstellt, die miteinander verkettet sind, könnten auf Wunsch mehr als zwei
Zwischendatenserverprozesse miteinander verkettet werden. in diesem
Fall könnte
der Datenbankaccessor 148 an Stelle dessen eine andere
Datenbankverbindung sein (d. h. ähnlich
oder identisch mit der Datenbankverbindung 138), die in
Kommunikationsverbindung mit einem weiteren Zwischendatenserverprozess
und schließlich
einer Datenbank, wie etwa der Datenbank 126 steht. Da die
Clientanwendungen 128 und 130 ebenfalls ihre eigenen
jeweiligen Sessionen, Datenquellen und Datenbankverbindungen haben
können,
könnten
diese Anwendungen 128 und 130 direkt auf den Datenserverprozess 124 oder
jeden anderen ähnlichen
oder identischen vorstehend beschriebenen Datenserverprozess, falls
dies erwünscht
ist. In einigen Fällen
kann ein derartiger direkter Zugriff auf den Datenserverprozess 124 durch
die Clientanwendungen 128 und 130 nach Möglichkeit
vermieden werden (d. h., wenn die angeforderten Daten beispielsweise
bei dem Zwischendatenserverprozess 122 lokaler verfügbar sind),
um die Kommunikationsanforderungen an die zentrale Datenbank 126 zu
minimieren.
-
Die Informationen oder Daten, die
in der Datenbank 126 gespeichert sind und die über die
Zwischendatenserverprozesse 123 und 124 zur Verwendung
durch die Clientanwendungen 128 und 130 transportiert
werden können,
enthalten alle Informationen oder Daten, die ein objektorientiertes
Konfigurationsmodell für
ein Unternehmen aufbauen. Beispielsweise können alle zu den hierarchisch
angeordneten Objekten gehörenden
Informationen, einschließlich
Attributwerte, Datenbankregeln oder Verbindungen etc. nach Bedarf
(oder im Fall von Regeln vor der Ausführungszeit, falls erwünscht) von
der Datenbank 126 zu einer der Clientanwendungen 128 und 130 transportiert
und lokal gespeichert (beispielsweise in der Datenquelle 136)
und im Fall von Regeln und dergleichen lokal ausgeführt werden.
Sobald die Informationen oder Daten, die von den Clientanwendungen 128 und 130 benötigt werden,
in der Datenquelle 136 lokal gespeichert sind, führen nachfolgende
Anforderungen für
die gleichen Informationen durch die Clientanwendungen 128 und 130 nicht
zu einer Kommunikation über
die Kommunikationsverbindungen 140 und 141. Als
Resultat ermöglicht
es das in 4 gezeigte
Beispielsystem 120, dass die innerhalb einer komplexeren
hierarchischen objektorientierten Konfigurationsdatenbank für ein Unternehmen
oder anderes System enthaltenen Informationen lokal verteilt und gespeichert
werden, wo sie benötigt
werden und wenn sie benötigt
werden, wodurch die Gesamtmenge der für die Unterstützung der
Informationsbedürfnisse
der Clientanwendungen, die das Unternehmen oder das andere System bilden,
erforderlichen Netzkommunikation reduziert wird.
-
Die Zwischendatenserverprozesse 122 und 124 können in
physisch getrennten Workstations oder Verarbeitungssystemen instanziert
werden, die über
die Kommunikationsverbindung 140 in Kommunikation stehen,
die ein Teil eines Kommunikationsnetzes sein kann. Die Zwischendatenserverprozesse 122 und 124 könnten jedoch
alternativ innerhalb der gleichen Workstations oder innerhalb des
gleichen Verarbeitungssystemes instanziert werden.
-
Die in dem Beispielsystem 120 in 4 gezeigten Funktionsblöcke können als
Objekte, Prozesse etc. unter Verwendung jeder gewünschten
Kombination von Software, Firmware und Hardware implementiert werden.
Beispielsweise können
ein oder mehrere Mikroprozessoren, Microcontroller, anwendungsspezifische
integrierte Schaltungen (ASICs) etc. auf Instruktionen oder Daten
zugreifen, die auf maschinen- oder
prozessorlesbaren Speichermedien gespeichert sind, um die hierin
beschriebenen Vorrichtungen und Verfahren zu implementieren. Die Speichermedien
können
jede beliebige Kombination von Einrichtungen und/oder Medien einschließen, wie
z. B. Festkörperspeichermedien
einschließlich Direktzugriffsspeicher
(RAM), Nurlesespeicher (ROM), elektrisch löschbare programmierbare Nurlesespeicher
(EEPROM) etc., optische Speichermedien, magnetische Speichermedien
etc. Zusätzlich kann
jede Software oder Firmware, die zur Implementierung der in 4 gezeigten Funktionsblöcke verwendet
wird, zusätzlich
oder alternativ zu dem Prozessor oder zu einer anderen Einrichtung
oder Einrichtungen, die die Software ausführen, über das Internet, Telefonleitungen,
Satellitenkommunikationsverbindungen etc. abgegeben und auf diese
zugegriffen werden.
-
5 ist
eine detaillierte schematische Ansicht, die ein Beispiel der Weise
zeigt, in der Clientanwendungen auf Informationen oder Daten zugreifen
können,
die in einer Datenquelle eines Zwischendatenserverprozesses gespeichert
sind. Im einzelnen wird der Status für Clientanwendungen von einem
oder mehreren Clientroots 200 und 202 aufrechterhalten.
Die Clientroots 200 und 202 sind Fenster auf eine
Datenquelle 204.
-
Eine Session 206 verwaltet
die Wechselwirkungen zwischen den Clientroots 200 und 202 und der
Datenquelle 204. Beispielsweise können die Clientroots 200 und 202 den
Status für
die jeweiligen Clientanwendungen 128 und 130 (4) enthalten, die Datenquelle 204 kann
der Datenquelle 136 entsprechen und die Session 206 kann
der Session 134 entsprechen. Auf diese Weise müssen die
Clientanwendungen 128 und 130 nicht direkt auf
die Datenquelle 136 zugreifen und können an Stelle dessen den jeweiligen
Anwendungsstatus (entsprechend den Clientroots 200 und 202)
beibehalten, auf den rasch und wiederholt nach Daten zugegriffen
werden kann, die gegenwärtig
lokal innerhalb des Zwischendatenserverprozesses 122 gespeichert
sind. Wenn beispielsweise die zu dem Clientroot 200 gehörende Clientanwendung
zu einem Modulobjekt 208 (MOD A) gehörende Daten benötigt, kann
die Session 206 das Clientroot 200 und ein Standortobjekt 210 durchlaufen,
um die benötigten
Informationen von dem Modulobjekt 208 abzurufen. Wenn andererseits
die zu dem Clientroot 200 gehörende Clientanwendung zu einem
Attribut 212 (ATTR 1) gehörende Informationen benötigt, durchläuft der
Sessionsprozess 206 die Datenquelle 204, um die zu dem
Attribut 212 gehörende
Information abzurufen, und sendet diese Informationen, die zu dem
Anwendungsstatus, der zu dem Clientroot 200 gehört, hinzuzufügen sind.
Wenn ferner die zu dem Clientroot 200 gehörende Clientanwendung
Informationen benötigt,
die nicht lokal gespeichert sind (d. h. die nicht bereits in die
lokale Datenquelle 204 geladen oder in dieser gespeichert sind),
kann der Sessionsprozess 206 diese Informationen von einem
Zwischendatenserverprozess 214 abrufen. Der Zwischendatenserverprozess 214 kann beispielsweise
dem in 4 gezeigten Zwischendatenserverprozess 124 entsprechen.
Obgleich in 5 zwei Clientroots
gezeigt sind, können
ein oder mehr als zwei Clientroots an Stelle dessen verwendet werden.
-
Wie vorstehend allgemein unter Bezug
auf 4 und 5 beschrieben, können von
Clientanwendungen benötigte
Informationen (beispielsweise Objektdaten, die Attributwerte, Regeln
etc. einschließen)
nach Bedarf geladen werden (d. h. von einer Datenbank abgerufen
und nach Erfordernis lokal gecached werden). Während die hierin beschriebenen Vorrichtungen
und die Verfahren es ermöglichen,
Informationen auf elementarer Basis bedarfsgerecht zu laden (d.
h. ein Objekt auf einmal), kann weitere Kommunikationseffizienz
durch das Erkennen von Datenbankzugriffsmustern und das bedarfsgerechte Laden
von etwas mehr Informationen als genau von einer Anwendung angefordert,
erzielt werden. Mit anderen Worten können Datenbankzugriffsmuster
verwendet werden, um vorwegzunehmen, welche Informationen wahrscheinlich
auf die Anforderung eines bestimmten Informationsgegenstandes durch
eine Anwendung folgend benötigt
werden. Wenn beispielsweise eine Clientanwendung von einem Modulobjekt
zu einer Attributrolle durchläuft
(d. h. die Clientanwendung fordert die Attributrolleninformation von
einem anderen Datenserver an), folgt gewöhnlich eine nachfolgende Anforderung
der Attributwerte, da diese Informationen gewöhnlich zusammen mit dem Attributnamen
und -typen angezeigt werden. Um die Kommunikationseffizienz zu steigern
(d. h. die Gesamtmenge der Netzkommunikation zu reduzieren), können Attributwerte
stets zusammen mit Attributrolleninformationen gesendet werden.
Allgemein ausgedrückt
kann die Effizienz der Kommunikation erzielt werden, indem die charakteristischen
Informationsanforderungsmuster vorweggenommen werden, die für Anwendungen
typisch sind, und dann die Informationen in einer Weise gebündelt werden, die
mit diesen Zugriffsmustern übereinstimmt,
um die Netzwerkkommunikation zu minimieren (d. h. die Anzahl der
Umlaufkommunikationsvorgänge,
die zum Erhalten der von den Clientanwendungen benötigten Informationen
erforderlich sind).
-
In dem Fall, dass eine Clientanwendung
Offline-Zugriff auf eine Systemdatenbank benötigt (wenn beispielsweise eine
Offline-Editiersession gewünscht
wird), kann der gesamte Inhalt der Datenbank (d. h. alle Regeln
und Daten) angefordert und lokal gecached werden. Auf diese Weise
kann eine Clientanwendung einen Systembenutzer in die Lage versetzen,
eine vollständige
Editiersession Offline auszuführen.
Da alle Regeln lokal verfügbar
sind, kann während
einer derartigen Offline-Editiersession eine lokale Regelüberprüfung verwendet
werden, um nachfolgende Datensynchronisierungs- und Abstimmungsaktivitäten beim
Wiederherstellen des Anschlusses der Clientanwendungen an die zentrale Datenbank
zu erleichtern (d. h. bei Beendigung der Offline-Editiersession).
Derartige Datensynchronisierungs- und Abstimmungsaktivitäten können unter Verwendung
der nachfolgend beschriebenen beispielhaften Objektänderungshandhabungstechniken implementiert
werden.
-
Clientanwendungen (beispielsweise
die Clientanwendungen 128 und 130) können auf
Informationen zugreifen, die in einer lokal gespeicherten oder gecacheten
Datenquelle (beispielsweise die Datenquelle 136) gespeichert
sind und können
diese Informationen modifizieren oder verändern. Beispielsweise kann
die Clientanwendung 128 (4)
dem Clientroot 200 (5)
entsprechen und kann den Clientroot 200 durchlaufen, um
auf zu dem Modul 208 gehörende Informationen zuzugreifen.
Wenn die Client Anwendung 128 versucht, Informationen (beispielsweise
Rollen und/oder Eigenschaften) in dem Modul 208 innerhalb
des Kontextes einer Transaktion den Datenbankregeln unterliegend
(d. h. unter Prüfung der
Regeln) zu modifizieren, wird ein "verfälschtes" Objekt erzeugt,
um die versuchten Modifikationen zu speichern. Wenn eine Transaktion
verschachtelt ist und somit weitere Versuche auftreten, dem Modul 208 zugehörige Informationen
zu verändern
oder zu modifizieren, wird ein weiteres verfälschtes Objekt erzeugt, und
dieser weiteren Änderungen
zu speichern. Zusätzliche
verfälschte
Objekte können
erzeugt werden, wenn zusätzliche
innere verschachtelte Transaktionen ausgeführt werden. Sobald die innerste
verschachtelte Transaktion festgeschrieben wurde, werden die in
dem innersten verfälschten
Objekt wiedergegebenen Veränderungen
auf das verfälschte
Objekt übertragen,
das zu der nächstäußeren Transaktion
gehört.
Die Übertragung
der veränderten
Informationen der verfälschten
Objekte von einer inneren Transaktion zu der nächstäußeren Transaktion wird fortgeführt, wenn
die inneren Objekte festgeschrieben werden, bis alle Veränderungen
auf das verfälschte
Objekt übertragen
wurden, das zu der äußersten
Transaktion gehört.
Die Festschreibung der äußersten
Transaktion führt
dazu, dass die Veränderungen
permanent werden, wodurch ein Zurückziehen der Veränderungen
(d. h. die Umkehrung der Veränderungen
in den Zustand der Anwendungen vor dem Beginn der Transaktion) verhindert
wird.
-
Wie vorstehend beschrieben versetzen Transaktionen
(und verschachtelte Transaktionen) Anwendungen in die Lage, Veränderungen
an Objektinformationen innerhalb ihrer jeweiligen Clientroots zu
bewirken oder aufzuzeichnen. Clientanwendungen können jedoch zusätzlich Objektveränderungen in
eine Datenbank schreiben beziehungsweise darin aufzeichnen (beispielsweise
die Datenbank 126), wodurch alle Zwischendatenserver, die
mit dieser Datenbank verbunden sind, in die Lage versetzt werden,
die veränderten
Informationen bei Bedarf an ihre jeweiligen Clientanwendungen abzugeben.
Vorzugsweise, jedoch nicht notwendigerweise, können permanente Veränderungen
an Objektinformationen durch eine Clientanwendung ansprechend auf
eine automatische Anweisung von der Clientanwendung und/oder ansprechend
auf eine Anweisung von einem Systembenutzer oder Operator in die
Datenbank (beispielsweise die Datenbank 126 aus 4) zurückgeschrieben werden.
-
Zunächst werden in einem Clientroot
(beispielsweise dem Clientroot 200) festgeschriebene (d. h.
dauerhaft gemachte) Veränderungen
in eine zu dem Clientroot gehörende
Datenquelle (beispielsweise die Datenquelle 204) über einen
Sessionsprozess (beispielsweise den Sessionsprozess 206)
geschrieben. Der Sessionsprozess propagierte dann alle an den Clientroot
durchgeführten
Veränderungen
zu der Datenquelle (beispielsweise der Datenquelle 204 einschließlich aller
Objekte, mit denen sie verbunden ist). Der Sessionsprozess 206 sendet
dann die veränderten
Datenquelleninformationen an einen Zwischendatenserver, der mit
der Datenbank verbunden ist. In dem Fall, in dem zwei oder mehr
eingreifende Zwischendatenserver zwischen der zentralen Datenbank
und der die veränderten
Informationen sendenden Datenquelle sind, werden die Veränderungen von
Datenserver zu Datenserver gesendet, bis sie die Datenbank erreichen.
Um die Unabhängigkeit von
Plattformen zu erleichtern und die gesamte Systemflexibilität zu steigern,
werden die Informationen vorzugsweise, jedoch nicht notwendigerweise
zwischen den Zwischendatenservern in Form eines XML-Dokuments transportiert.
Die Datenbank setzt Datenbankregeln durch, und wenn eine der an
die Datenbank abgegebenen Informationen (beispielsweise innerhalb
empfangener XML-Dokumente) nicht diesen Regeln entspricht, weist
die Datenbank die Veränderungen
zurück
(d. h. zeichnet sie nicht auf).
-
Von der Datenbank empfangene und
akzeptierte Veränderungen
können
dann durch einen oder mehrere Zwischendatenserver an alle zu einem
Unternehmen gehörende
Datenquellen weitergeleitet werden. Beispielsweise kann ein XML-Dokument, das
eine umfassende Liste aller Veränderungen
enthält,
die von der Datenbank empfangen und gespeichert wurden, asynchron
zurück
zu dem Client weitergeleitet werden, von dem die Veränderung stammt,
und/oder zu einigen oder allen Zwischendatenservern innerhalb des
Unternehmens oder Systems. In ähnlicher
Weise können
Veränderungen,
die innerhalb der Datenbank auftreten und die nicht das Resultat
der Weiterleitung von veränderten
Informationen herauf zu der zentralen Datenbank durch eine oder
mehrere Clientanwendungen sind, asynchron als ein Veränderungsbenachrichtigungsmechanismus
hinunter zu den Datenservern und somit den Datenquellen, die das
Unternehmen bilden, weitergeleitet werden. Derartige Veränderungsbenachrichtigungen
können
beispielsweise unter Verwendung eines XML-Dokuments implementiert
werden, das in hierarchischer Weise angeordnete Daten enthält, um die effiziente
Nutzung der Daten durch die Datenquellen zu ermöglichen. Eine Datenquelle,
die ein derartiges XML-Dokument empfängt, kann Objekte innerhalb des
Dokuments überspringen,
die zuvor nicht geladen wurden, und ein neues reduziertes XML-Dokument
produzieren, das nur diejenigen Veränderungen enthält, die
den oder die Clients betreffen, die mit dieser Datenquelle verbunden
sind.
-
6 ist
ein Blockdiagramm eines Beispielsystems 300, das eine Vielzahl
von Verarbeitungssystemen 302, 304, 306 und 307 hat.
Die Verarbeitungssysteme 302, 304 und 306 benutzen
jeweilige Zwischendatenserver 308, 310 und 312 für den Zugriff
auf eine Datenbank 314. Die Verarbeitungssysteme 304 und 307 verwenden
zusätzlich
jeweilige Zwischendatenserver 315 und 316 zum
Zugriff auf einen Ablaufserver 317. Das System 302 kann
beispielsweise eine Anwendungsstation (beispielsweise eine der Workstations 18, 20 und 42 aus 1) sein, die eine oder mehrere
Clientanwendungen 318 auf Windows®-Basis
ausführt.
Die Anwendungen 318 können
Clientroots 319 und 320 enthalten, die mit einer
Datenquelle 323 verbunden sind. Die Datenquelle 323 kann
mit der Datenbank 314 über
den Zwischendatenserver 312 über einen Datenbank-Server 324 verbunden
sein. Das System 302 kann ferner einen Web-Client 326 enthalten,
der mit dem System 304 in Kommunikationsverbindung steht,
wie nachfolgend im Detail erläutert
wird.
-
Das System 304 kann beispielsweise
ein Webserver sein (der unter Verwendung einer Workstation oder
eines beliebigen anderen Verarbeitungssystems implementiert sein
kann), der einen Internetserverprozess 328 ausführt, der
einen oder mehrere Sessionsstatus 330 hat (die analog zu
Anwendungsstatus sind). Die Sessionsstatus 330 enthalten
Clientroots 332 und 334 und jeweilige Datenquellen 336 und 338,
die mit den Zwischendatenservern 310 und 315 in
Kommunikationsverbindung stehen. Somit können die Sessionsstatus 330 auf
Informationen (beispielsweise Daten, Regeln etc.) zugreifen, die
innerhalb der Datenbank 314 und/oder dem Ablaufserver 317 gespeichert
sind. Das System 304 kann ferner einen Webclient 340 enthalten,
der in Kommunikationsverbindung mit dem Internetserverprozess 328 steht.
Auf diese Weise können
die Webclients 326 und 340 jeweils einem der Sessionstatus 330 (d. h.
einem der Clientroots 332 und 334) entsprechen und
können
mit den Zwischendatenservern 310, 312, 315 und 316 zusammenwirken,
um Informationen mit der Datenbank 314 und/oder dem Laufzeitserver 317 unter
Verwendung der hierin beschriebenen Verfahren auszutauschen.