DE10230895A1

DE10230895A1 - Transaktions-Datenkommunikation für Prozesssteuersysteme

Info

Publication number: DE10230895A1
Application number: DE10230895A
Authority: DE
Inventors: Trevor D Schleiss; Mark J Nixon; Neil J Peterson; Grant Wilson; Christopher Felts
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2001-07-10
Filing date: 2002-07-09
Publication date: 2003-03-06
Also published as: CN1416070A; JP2003216228A; US7162534B2; GB2380833B; GB0215860D0; JP4093820B2; CN1297926C; HK1053183A1; GB2380833A; US20030014500A1

Abstract

Es wird ein Transaktions-Datenkommunikationssystem und ein Verfahren offenbart, das Information in einem Unternehmen mit einem Prozesssteuersystem und einer Mehrzahl von Informationstechnologiesystemen kommuniziert, die kommunikativ mit dem Prozesssteuersystem über eine Webdienste-Schnittstelle mit einem Transktions-Informationsserver gekoppelt sind. Das System und Verfahren erzeugt Transaktions-Prozesssteuerinformation und formatiert die Transaktions-Prozesssteuerinformation auf Basis eines erweiterbaren Markup-Sprache-Eingabeschemas, um formatierte Transaktions-Prozesssteuerinformationen zu bilden. Das System und Verfahren sendet die formatierte Transaktions-Prozesssteuerinformation an den Transaktions-Informationsserver über die Webdienste-Schnittstelle und bildet die formatierte Transaktions-Prozesssteuerinformation auf ein erweiterbares Markup-Sprache-Ausgabeschema ab, das einem aus der Mehrzahl der Informationstechnologiesysteme zugeordnet ist, um abgebildete Transaktions-Prozesssteuerinformationen zu bilden. Das System und Verfahren sendet die abgebildete Transaktions-Prozesssteuerinformation an eines aus der Mehrzahl der Informationstechnologiesysteme.

Description

Gebiet der Erfindung

Die vorliegende Erfindung betrifft im allgemeinen Prozesssteuersysteme und insbesondere die Kommunikation von Transaktions-Prozesssteuerinformation in einem Unternehmen.

Beschreibung des Standes der Technik

Prozesssteuersysteme wie solche, die in chemischen, petrochemischen oder anderen Prozessen verwendet werden, weisen üblicherweise ein oder mehrere zentralisierte Prozesssteuerungen auf, die zumindest mit einer Host- oder Bedienerworkstation und mit einem oder mehreren Feldgeräten über analoge, digitale oder kombinierte analogdigitale Busse kommunikativ gekoppelt sind. Die Feldgeräte, die beispielsweise Ventile, Ventilpositionierer, Schalter und Übertrager (beispielsweise Temperatur-, Druck- und Durchflusssensoren) sein können, führen Funktionen in dem Prozess wie Öffnen oder Schliessen von Ventilen und Messen von Prozessparametern durch. Die Prozesssteuerung empfängt Signale, die von den Feldgeräten durchgeführten Prozessmessungen und/oder die Feldgeräte betreffende Informationen anzeigen. Die Prozesssteuerung verwendet diese Informationen, um eine Steuerroutine zu implementieren, und erzeugt anschliessend Steuersignale, die über den Bus oder andere Kommunikationsleitungen zu den Feldgeräten gesendet werden, um den Betrieb des Prozesses zu steuern. Informationen von den Feldgeräten und den Steuerungen kann einer oder mehreren Anwendungen zur Verfügung stehen, die durch die Bedienerworkstation durchgeführt werden, um einem Bediener zu ermöglichen, gewünschte Funktionen in Bezug auf den Prozess auszuführen, beispielsweise das Betrachten des aktuellen Prozessstatus, das Modifizieren des Prozessbetriebes, etc.

Üblicherweise arbeitet ein Prozesssteuersystem in einem Geschäftsunternehmen, welches verschiedene Prozesssteueranlagen, Komponenten- und/oder Dienstezulieferer und Kunden aufweist, die alle über einen großen geographischen Bereich, oder in einigen Fällen weltweit, verteilt sind. Die Prozesssteueranlagen, Zulieferer und Kunden können miteinander unter Verwendung einer Vielfalt von Kommunikationsmedien und Technologien kommunizieren, beispielsweise über Internet, Satellitenverbindungen, bodenbasierte drahtlose Verbindungen, Telefonleitungen, etc. Natürlich wurde das Internet eine bevorzugte Kommunikationsplattform für viele Geschäftsunternehmen, da die Kommunikationsinfrastruktur eingerichtet ist, wodurch die Kommunikationsinfrastrukturkosten für ein Unternehmen nahe Null sind, und die zur Kommunikation von Information über das Internet verwendete Technologien sind gut verstanden, stabil, sicher, etc.

Jede Prozesssteueranlage in einem Unternehmen kann ein oder mehrere Prozesssteuersysteme, sowie eine Anzahl von anderen geschäftsbezogenen oder informationstechnologischen Systemen aufweisen, die unterstützt und gewartet werden müssen, oder die komplementär für den Betrieb der Prozesssteuersysteme sind. Im allgemeinen können die Informationstechnologiesysteme in einer Prozesssteueranlage Produktionsausführungssysteme, beispielsweise ein Wartungsmanagementsystem, und Unternehmensbetriebsmittel-Planungssysteme aufweisen, beispielsweise Planungs-, Buchführungs- und Beschaffungssysteme. Obwohl diese Informationstechnologiesysteme physikalisch in oder nahe einer Anlage angeordnet sein können, können in einigen Fällen einige wenige oder möglicherweise alle dieser Systeme in Bezug auf die Anlage entfernt angeordnet sein und mit der Anlage unter Verwendung des Internets oder jeder anderen geeigneten Kommunikationsverbindung kommunizieren. Um den Gesamtbetrieb eines Unternehmens zu verbessern oder zu optimieren, waren auf jeden Fall einige jüngere Entwicklungsbemühungen derart ausgerichtet, schnellere und effizientere Kommunikationen zu fördern und eine vollständigere Integration zwischen Prozesssteuersystemen und Informationstechnologiesystemen in einem Unternehmen zu ermöglichen.

Allgemein ausgedrückt, erfordert eine erfolgreiche Unternehmensoptimierung eine Integration von Prozesssteuersystemen und Informationstechnologiesystemen. Informationstechnologiesysteme weisen üblicherweise Unternehmensbetriebsmittel-Planungssysteme und Produktionsausführungssysteme auf, die in einem Unternehmen verteilt sind. Die vollständige Integration von Informationstechnologiesystemen und Prozesssteuersystemen würde beispielsweise einem Unternehmen ermöglichen, in Antwort auf einen Kundenauftrag für ein Produkt zu erkennen, dass zusätzliche Teile zur Herstellung des Produktes benötigt werden, und automatisch Aufträge an einen oder mehrere Zulieferer für bestimmte Mengen dieser Komponenten zu erzeugen und zu verwenden. Deshalb würde die Integration von Informationstechnologiesystemen und Prozesssteuersystemen einem Unternehmen ermöglichen, wirksam informiertere Geschäfts- und Produktionsentscheidungen zu treffen. Ferner würde eine derartige Integration Geschäfts- und Produktionsentscheidungen genauer und schneller machen, da in vielen Fällen die Notwendigkeit für menschliches Eingreifen vermieden werden kann, und viele vormals manuelle Aktivitäten (das sind von einem menschlichen Bediener durchgeführte Aktivitäten), beispielsweise Teile-Bestellung, automatisiert werden können.

Unglücklicherweise ist die Integration von Prozesssteuersystemen und Informationstechnologiesystemen aufgrund der Tatsache kompliziert, dass Prozesssteuersysteme beide, sowohl Echtzeitdaten als auch Transaktionsdaten erzeugen und verwenden. Echtzeitdaten werden üblicherweise in einer regelmäßigen periodischen oder synchronen Weise kommuniziert, beispielsweise die Kommunikation von kontinuierlichen Druckablesungen, die von einem Drucksender geliefert werden. Auf der anderen Seite sind Transaktionsdaten ereignisgesteuert und sie werden spärlich in einer asynchronen Weise erzeugt. Eine Art von häufig in einem Prozesssteuersystem verwendeten Transaktionsdaten ist von einem Gerät erzeugte Warn- oder Alarminformation. Beispielsweise ist ein Alarm, der aus der Anforderung resultiert, Wartung und/oder Teile zu bestellen, die von dem Prozesssteuersystem benötigt werden, um ein problematisches Gerät zu reparieren von Natur aus transaktional. Eine andere Art von Transaktionsdaten resultiert aus Produktionsplanungsaktivitäten. Beispielsweise kann eine Produktionsplanungstransaktion zur Stapelausführung einer Rezeptur ein Datum, einen Zeitpunkt, eine Materialart- und menge, eine Materialgüte, eine Rohstoffart- und menge, eine Katalysatorart- und menge, etc. aufweisen. Eine weitere Art von Transaktionsdaten kann ein computerisiertes Wartungsmanagementsystem einbeziehen, dass Informationen verwendet, beispielsweise ein Etikett bzw. TAG, einen Zeitpunkt, ein Datum, eine Warnung (beispielsweise Fehler-, Wartungs-, Empfehlungswarnung, etc.), eine Beschreibung, eine Priorität bzw. Wertung, eine empfohlene Aktion (beispielsweise ein Gerät zu ersetzen), ein Gerätestatus (beispielsweise Fehlerstatus), etc.

Ein bevorzugter Kommunikationsfluss zwischen den verschiedenen Prozesssteuer- und Informationstechnologiesystemen, die üblicherweise in einem Unternehmen gefunden werden, ist durch das ISA S95-Modell definiert. Im Allgemeinen, ist das ISA S95-Modell ein internationaler Standard, der die Interaktionen zwischen Produktions- oder Prozesssteuersystemen, Unternehmensbetriebsmittel- Planungssystemen und Produktionsausführungssystemen definiert, um die Integration dieser Systeme zu erleichtern. Genauer, das ISA S95-Modell definiert allgemein die Interaktion oder Kommunikationsflüsse zwischen einem Prozesssteuersystem und Bestellausführungssystemen, Buchhaltungssystemen, Produktversendungsverwaltungssystemen, Produktlagersteuersystemen, Qualitätssicherungssystemen, Wartungsmanagmentsystemen, Materialbeschaffungssystemen, Material- und Energiesteuersystemen, Produktionsplanungssystemen, etc. Obwohl das ISA S95-Modell im allgemeinen Kommunikationsflüsse zwischen den Systemen in einer Anlage oder einem Unternehmen definiert, definiert dieser Standard keinen spezifischen Mechanismus, durch den diese Kommunikationsflüsse ausgeführt werden können.

Um die Kommunikationsflüsse zwischen den Systemen eines Unternehmens wie von dem ISA S95-Standard spezifiziert zu implementieren, wurde üblicherweise ein spezieller Kommunikationssoftwaretreiber entwickelt, um jedes Gerät oder System in einer Prozesssteueranlage miteinander zu verbinden. Mit anderen Worten, für jedes Gerät oder System in einem Unternehmen wird üblicherweise ein speziell entwickelter Kommunikationssoftwaretreiber benötigt, um dem Gerät oder System zu ermöglichen, mit einem anderen Gerät oder System zu kommunizieren. Daraus folgt, wenn ein System, Gerät oder Komponente in dem Unternehmen aufgrund beispielsweise eines Firmware-Upgrades bzw. Aufrüstung, Austausch, etc. ausgewechselt wird, muss ebenfalls der Treiber für das System, das Gerät oder die Komponente ausgetauscht werden. Es ist klar, dass die große Anzahl von benötigten Kundentreibern zu einer eine Menge Zeit verbrauchende Treiberwartung führt, die anschließend zu hohen Unternehmenswartungskosten führt. Aus praktischen Gründen können Systementwickler selektiv Kundenkommunikations-Schnittstellen entwickeln, um Kommunikationen zwischen einer relativ kleinen Untergruppe von Systemen, Geräten oder Komponenten in einem Unternehmen zu ermöglichen, was dazu führt, dass einige Paare von Systemen, Geräten oder Komponenten keine Information austauschen können.

Neue Entwicklungen haben einen wirksameren Austausch von Echtzeit- Prozesssteuerinformationen zwischen den verschiedenen Systemen, Geräten und Komponenten in einem Prozesssteuersystem oder zwischen Prozesssteuersystemen ermöglicht. Objektverbindung und -einbettung zur Prozesssteuerung (OPC) liefert einen Mechanismus, der die Notwendigkeit für individuelle Kundenkommunikations-Softwaretreiber eliminiert, die Echtzeit- Prozesssteuerdaten zwischen den Systemen, Geräten und Komponenten eines Prozesssteuersystems fördern. Es ist bekannt, das OPC auf der Objektverbindungs- und Einbettungstechnologie (OLE) von Microsoft basiert, die eine gemeinsame Schnittstelle für die verschiedenen Systeme, Geräte und Komponenten bereitstellt, die ein Prozesssteuersystem ausmachen. Üblicherweise weist jedes dieser Systeme, Geräte und Komponenten des Prozesssteuersystems eine OPC-Kommunikationsschicht auf und spricht deshalb eine gemeinsame, standardisierte Sprache zum Zweck von Echtzeitinformationsbeförderung. Auf diese Weise kann die Kommunikation von Echtzeitdaten in einem Prozesssteuersystem in einer effizienten Weise stattfinden und Auswechseln von irgendwelchen der Systeme, Geräte oder Komponenten benötigt kein Auswechseln von einem Softwaretreiber.

Obwohl OPC ein Industriestandardmechanismus zur Kommunikation von Echtzeit- Prozesssteuerdaten in einem Prozesssteuersystem oder zwischen Prozesssteuersystemen wurde, unterstützt OPC aktuell nur Kommunikationen, die Echtzeitdaten einbeziehen. OPC ermöglicht es beispielsweise einem Prozesssteuersystem nicht, Transaktionsdaten oder Information an ein Bestellausführungssystem zu fördern, um eine Bestellung von Rohmaterial, eines Austauschteiles, etc. zu initiieren, da OPC nicht die Übertragung von Daten mit mehr Struktur (d. h. mehr Struktur als Echtzeitprozesssteuerdaten) unterstützt, beispielsweise Daten, die Zeitinformation, Materialinformation, Mengeninformation, etc. darstellen. Da weiterhin OPC auf einer Netzwerktechnologie von Microsoft basiert, die Kommunikationen erzeugt, die nicht gut über Internet übertragen werden, ist es sehr schwierig, wenn nicht unmöglich, OPC zur Übertragung von Information von einem Prozesssteuersystem über dem Internet zu beispielsweise einer entfernt angeordneten Bestellausführungseinrichtung, Zulieferereinrichtung, etc. zu verwenden. Die Schwierigkeit beim Verwenden von OPC um Informationen über das Internet zu Versenden, ist ferner mit der Tatsache verbunden, dass es sehr schwierig ist, OPC-basierte Kommunikation durch Schutzwälle bzw. Firewalls zu konfigurieren, die weit verbreitet verwendet werden, insbesondere im Fall von Internetbasierten Kommunikationen von Geschäftseinheiten.

Deshalb kann der Austausch von Transaktions-Information oder -Daten zwischen den Systemen, Geräten oder Komponenten eines Unternehmens unter Verwendung von OPC praktisch nicht ausgeführt werden. Beispielsweise im Fall einer Transaktion, die ein computerisiertes Wartungsmanagementsystem einbezieht, unterstützt OPC nicht die Übertragung der Arten von Information (beispielsweise TAG, Zeit, Alarm, etc.) die notwendigerweise an das Wartungsmanagementsystem befördert werden müssen, um dem Wartungsmanagementsystem zu ermöglichen, geeignete korrigierende Aktionen durchzuführen, Alarminformation einem Anwender anzuzeigen, etc. Selbst wenn eine derartige Transaktions-Information an das Wartungsmanagementsystem unter Verwendung von OPC befördert werden kann, kann OPC zusätzlich nicht verwendet werden, um die notwendige Information über das Internet an einen Zulieferer zu befördern, um beispielsweise ein Austauschteil zu bestellen, dass von dem Wartungsmanagementsystem benötigt wird. Um erfolgreich derartige Transaktionsdaten mit zur Zeit erhältlichen Systemen zu kommunizieren, wäre es notwendig, Kundenkommunikationsschnittstellen für jedes der Systeme, Geräte, etc. zu entwickeln, die integriert werden müssen, um jede Art von Transaktions- Datenaustausch auszuführen.

Zusammenfassung der Erfindung

Die hierin beschriebene Transaktions-Datenkommunikationstechnik erleichtert den Austausch von Transaktions-Information oder -daten zwischen den Geräten, Systemen und anderen Einrichtungen die ein Geschäftsunternehmen ausmachen. Gemäß einem Aspekt der Erfindung kann ein System und ein Verfahren zur Kommunikation von Information in einem Unternehmen mit einem Prozesssteuersystem und einer Mehrzahl von Informationstechnologiesystemen Transaktions-Prozesssteuerinformation erzeugen und kann die Transaktions- Prozesssteuerinformation eines ersten erweiterbaren Markup-Sprachschemas formatieren, um formatierte Transaktions-Prozesssteuerinformationen zu bilden. Das System und das Verfahren können ebenfalls die formatierte Transaktions- Prozesssteuerinformation an einen Transaktions-Informationsserver über eine Webdienste-Schnittstelle senden und können die formatierte Transaktions- Prozesssteuerinformation auf ein zweites erweiterbaren Markup-Sprachschema abbilden (mapping), das einem aus der Mehrzahl der Informationstechnologiesysteme zugeordnet ist, um abgebildete Transaktions- Prozesssteuerinformationen zu bilden. Ferner können das System und das Verfahren die abgebildete Transaktions-Prozesssteuerinformation an ein erstes der Mehrzahl von Informationstechnologiesystemen senden. Zusätzlich können das System und Verfahren ein XML-Eingabeschema verwenden, um die formatierte Transaktions-Prozesssteuerinformation zu bilden, und sie können die formatierte Transaktions-Prozesssteuerinformation auf einem XML- Ausgabeschema abbilden, das einer Anwendung zugeordnet ist, die in einem aus der Mehrzahl der Informationstechnologiesysteme ausgeführt wird.

Gemäß einem weiteren Aspekt der Erfindung kann ein System zur Anwendung in einem Unternehmen mit einer Mehrzahl von Informationstechnologiesystemen ein Prozesssteuersystem aufweisen, das dazu ausgebildet ist, Transaktions- Prozesssteuerinformationen auf Basis einer erweiterbaren Markup-Sprache und einer Mehrzahl von Eingabeschemata zu formatieren. Jedes der Mehrzahl von Eingabeschemata kann einem Typ von Transaktions-Prozesssteuerinformation zugeordnet sein. Das System kann ferner eine Webdienste-Schnittstelle aufweisen, die kommunikativ mit dem Prozesssteuersystem gekoppelt ist. Das System kann ebenfalls einen Transaktions-Datenserver aufweisen, der kommunikativ mit der Webdienste-Schnittstelle und der Mehrzahl von Informationstechnologiesystemen gekoppelt ist. Der Transaktions-Datenserver kann dazu ausgebildet sein, um Transaktions-Prozesssteuerinformation zuzuordnen, die auf Basis der erweiterbaren Markup-Sprache und der Mehrzahl von Eingabeschemata auf eine Mehrzahl von Ausgabeschemata formatiert wird. Jedes aus der Mehrzahl der Ausgabeschemata kann einer Anwendung zugeordnet sein, die in einem der Mehrzahl der Informationstechnologiesysteme ausgeführt wird, und der Transaktions-Datenserver kann ferner dazu ausgebildet sein, um abgebildete Transaktions-Prozesssteuerinformationen an eines aus der Mehrzahl der Informationstechnologiesysteme zu senden.

Gemäß einem anderen Aspekt der Erfindung, kann ein Verfahren zur Verarbeitung von Transaktions-Prozesssteuerdaten die Schritte Einhüllen der Transaktions- Prozesssteuerdaten in eine XML-Hülle, um XML-eingehüllte Transaktions- Prozesssteuerdaten zu bilden, und Senden der XML-eingehüllten Transaktions- Prozesssteuerdaten über eine Webdienste-Schnittstelle und einem Kommunikationsnetzwerk an einen XML-Datenserver aufweisen. Das Verfahren kann die XML-eingehüllten Transaktions-Prozesssteuerdaten auf ein XML- Ausgabeschema abbilden, das einem aus der Mehrzahl der Informationstechnologiesysteme zugeordnet ist, die kommunikativ über das Kommunikationsnetzwerk gekoppelt sind, um zugeordnete XML-Transaktions- Prozesssteuerdaten zu bilden. Zusätzlich kann das Verfahren den Schritt des Sendens der zugeordneten XML-Transaktions-Prozesssteuerdaten an eines aus der Mehrzahl der Informationssysteme über das Kommunikationsnetzwerk aufweisen.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein beispielhaftes, schematisches Blockdiagramm eines Unternehmens, das einem Prozesssteuersystem ermöglicht, Transaktions-Prozesssteuerdaten mit einer Mehrzahl von Informationstechnologiesystemen auszutauschen;
Fig. 2 ist ein detaillierteres beispielhaftes, schematisches Blockdiagramm des in Fig. 1 gezeigten Prozesssteuersystems;
Fig. 3 ist ein detaillierteres Funktionsblockdiagramm des in Fig. 1 gezeigten XML- Servers;
Fig. 4 ist ein beispielhaftes Eingabeschema für einen Gerätealarm, das in dem in Fig. 1 gezeigten System verwendet werden kann;
Fig. 5 ist eine beispielhafte, diagrammartige Ansicht, die eine Art und Weise illustriert, in der ein Eingabeschema auf ein Ausgabeschema abgebildet werden kann; und
Fig. 6 ist eine beispielhafte, diagrammartige Ansicht, die eine Art und Weise illustriert, in der in Fig. 1 und 2 gezeigte Prozesssteuersystem konfiguriert sein kann.

Beschreibung der bevorzugten Ausführungsformen

Fig. 1 ist ein beispielhaftes schematisches Blockdiagramm eines Geschäftsunternehmens 10, das eine Mehrzahl von kommunikativ gekoppelten Komponenten, Systemen und Geschäftseinrichtungen, etc. aufweist. Lediglich als Beispiel weist das in Fig. 1 gezeigte Unternehmen 10 eine lokale Prozesssteueranlage 12, entfernte Prozesssteueranlagen 14 bis 18, Komponenten- und/oder Materialzulieferer 20 und 22 und Kunden 24 und 26 auf, die alle wie gezeigt mit dem Internet 28 kommunikativ gekoppelt sind. Obwohl viele der Systeme, Geschäftseinrichtungen, etc. die innerhalb des Unternehmens 10 dargestellt sind, mit der lokalen Prozesssteueranlage 12 über das Internet 28 gekoppelt sind, sollte erkannt werden, dass jede andere geeignete Kommunikationsverbindung verwendet werden kann, ohne den Umfang und den Rahmen der Erfindung zu verlassen. Zusätzlich sollte erkannt werden, dass andere Geräte, Systeme und Einrichtungen als die speziell in Fig. 1 illustrierten kommunikativ mit der Anlage 12 über das Internet oder jede andere geeignete Kommunikationsverbindung gekoppelt sein können.
Die lokale Prozesssteueranlage 12 kann eine Mehrzahl von Unternehmensbetriebsmittel-Planungssystemen, Produktionsausführungssystemen, Prozesssteuersystemen, etc. aufweisen. Insbesondere weist die in Fig. 1 gezeigte lokale Prozesssteueranlage 12 ein Bestellausführungssystem 30, ein Buchhaltungssystem 32, ein Produktversendungs- und -Verwaltungssystem 34, ein Produktions- oder Prozesssteuersystem 36, ein Produktlagerbestandssteuersystem 38, ein Qualitätssicherungssystem 40, eine Wartungsmanagementsystem 42, ein Beschaffungssystem 44, ein Material- und Energiesteuersystem 46 und ein Produktionsplanungssystem 48 auf, die alle über einen Datenbus oder ein lokales Netzwerk (LAN) 50 kommunikativ gekoppelt sein können. Das LAN 50 kann auf Ethernet basieren oder es kann jede andere geeignete Kommunikationsverbindung verwenden. Obwohl die Betriebsmittelplanungssysteme, die Produktionsausführungssysteme, die Prozesssteuersysteme, etc. der Anlage 12 als über das LAN 50 kommunikativ gekoppelt dargestellt sind, können natürlich eines oder mehrere dieser Systeme alternativ oder zusätzlich mit dem Internet 28 kommunikativ gekoppelt sein. Auf jeden Fall können, wie weiter unten im Detail beschrieben wird, die Systeme 30 bis 48 in der Anlage 12 über einen XML-Server 52 kommunizieren. Wie in Fig. 1 dargestellt, ist der XML-Server 52 mit dem Internet derart kommunikativ gekoppelt, dass, falls gewünscht, eines oder mehrere der Systeme 30 bis 48 Informationen mit einem oder mehreren der Anlagen 14 bis 18, der Zulieferer 20 und 22 und der Kunden 24 und 26 austauschen können.
Da der XML-Server 52 die Kommunikation von Information zwischen jeweils zwei Systemen, Komponenten, Einrichtungen, etc. innerhalb des Unternehmens 10 ermöglicht, ist es für eine Aktion oder einem Zustand innerhalb beispielsweise des Prozesssteuersystems 36 möglich, Aktivitäten mit jedem anderen System, Komponente oder Einrichtung des Unternehmens 10 zu initiieren oder zu erwirken. Gleichfalls können die verschiedenen Systeme oder Einrichtungen in dem Unternehmen 10 Aktivitäten in dem Prozesssteuersystem 36 initiieren oder erwirken. Als Beispiel und weiter unten im größeren Detail beschrieben, kann eine Gerätewarnung- oder Alarminformation die von einem Gerät in dem Prozesssteuersystem 36 erzeugt wurde, an den XML-Server 52 gesendet werden, der anschließend Alarminformation an das Wartungsmanagementsystem 42 sendet, so dass Anlagen, Betriebs- und Wartungspersonal von dem Alarmzustand Notiz nehmen. Zusätzlich kann der XML-Server 52 auch Informationen an das Bestellausführungssystem 30 senden, um beispielsweise ein Austauschteil zu bestellen, das benötigt wird, um ein fehlerhaftes Gerät zu reparieren, das den Alarmzustand ausgelöst hat. Das Bestellausführungssystem 30 kann dann geeignete Informationen über den XML-Server 52 an den Zulieferer 20 senden, um automatisch das Austauschteil von dem Zulieferer zu bestellen.
Nun mehr unter Bezug auf Fig. 2 weist das Prozesssteuersystem 36 eine oder mehrere Prozesssteuerungen 112 auf, die mit Host-Workstations oder -Computern 114 und 115 (die jeder Art von Personalcomputer oder Workstation sein können) und mit Banken von Eingabe/Ausgabe (I/O)-Geräten 120 und 122 verbunden sind, von denen jede mit einem oder mehreren Feldgeräten 125 bis 139 verbunden ist. Die Steuerungen 112 können beispielsweise DeltaV^tm- Steuerungen sein, die von der Fisher-Rosemount-Systems Inc. vertrieben werden, und sie sind kommunikativ mit den Host-Computern 114 und 115 beispielsweise über eine Ethernetverbindung 140 oder jede andere geeignete Kommunikationsverbindung verbunden. Gleichfalls sind die Steuerungen 112 mit den Feldgeräten 125 bis 139 unter Verwendung jeder gewünschten Hardware und Software kommunikativ verbunden, die beispielsweise Standard 4-20 mA Geräten und/oder jedem intelligenten Kommunikationsprotokoll, beispielsweise dem Fieldbus- oder HART-Protokoll, zugeordnet sind. Einer oder mehrere der Computer 114 und 115 kann weiter als ein Server dienen, der es dem Prozesssteuersystem 36 ermöglicht, Daten mit anderen Prozesssteuersystemen (nicht gezeigt) und/oder mit den in Fig. 1 gezeigten XML-Server 52 auszutauschen.
Es ist allgemein bekannt, dass Steuerungen 112 Prozesssteuerroutinen implementieren oder überwachen, die darin gespeichert oder ihnen in anderer Weise zugeordnet sind, und das sie mit den Feldgeräten 125 bis 139 kommunizieren, um einen Prozess zu steuern, der von dem Prozesssteuersystem 36 in jeder gewünschten Weise ausgeführt wird. Die Feldgeräte 125 bis 139 können jede Art von Geräten, beispielsweise Sensoren, Ventile, Sender, Positionierer etc. sein, während die I/O-Karten in den Banken 120 und 122 von jedem Typ von I/O-Geräten sein können, die mit jedem gewünschten Kommunikations- oder Steuerungsprotokoll, beispielsweise HART, Fieldbus, Profibus etc., konform sind. In dem in Fig. 2 gezeigten beispielhaften Prozesssteuersystem 36 sind die Feldgeräte 125 bis 127 Standard 4-20 mA-Geräte, die über Analogleitungen mit der I/O-Karte 122a kommunizieren, die Feldgeräte 128 bis 131 sind HART-Geräte, die mit einem HART-kompatiblen I/O-Gerät 120a verbunden sind, und die Feldgeräte 132 bis 139 sind intelligente Geräte, beispielsweise Fieldbus-Feldgeräte, die über einen digitalen Bus 142 oder 144 mit den I/O-Karten 120b oder 122b unter Verwendung beispielsweise des Fieldbus- Kommunikationsprotokolls kommunizieren. Die Feldgeräte 125 bis 139 und die Banken der I/O-Karten 120 und 122 können natürlich konform mit jedem anderen gewünschten Standard oder Protokoll anstatt der 4-20 mA-, HART- oder Fieldbusprotokolle sein, einschließlich jeden Standards oder Protokolls die in der Zukunft entwickelt werden.
Jede der Steuerungen 112 ist konfiguriert, um eine Steuerstrategie unter Verwendung dessen zu implementieren, was gewöhnlich als Funktionsblöcke bezeichnet wird. Es ist bekannt, dass jeder Funktionsblock ein Teil (beispielsweise eine Subroutine) einer Gesamtsteuerroutine ist und in Verbindung mit anderen Funktionsblöcken (über als Verbindungen bezeichnete Kommunikationen) betrieben werden, um Prozesssteuerschleifen in dem Prozesssteuersystem 6 zu implementieren. Funktionsblöcke führen üblicherweise eine Eingabefunktion, beispielsweise diese, die einem Sensor oder einem anderen Prozessparametermessgerät zugeordnet ist, eine Steuerfunktion, beispielsweise diese, die einer Steuerroutine zugeordnet ist, die PID-Steuerung, fuzzy logic- Steuerung, etc. ausführt, oder eine Ausgabefunktion aus, die den Betrieb eines Gerätes, beispielsweise ein Ventil steuert, um eine physikalische Funktion in dem Prozesssteuersystem 36 auszuführen. Natürlich existieren auch Hybrid- oder andere Arten von Funktionsblöcken. Funktionsblöcke können in der Steuerung 112 gespeichert und durch diese ausgeführt werden, was üblicherweise der Fall ist, wenn Funktionsblöcke verwendet werden, oder Standard 4-20 mA-Geräte oder einigen Arten von intelligenten Feldgeräten zugeordnet sind, oder sie können in den Feldgeräten selber abgespeichert und durch diese implementiert sein, was bei Fieldbus-Geräten der Fall sein kann.
Bevor die Art und Weise diskutiert wird, in der die hierin beschriebene Transaktionsdatenkommunikationstechnik die Kommunikation von Prozesssteuerinformation ermöglicht, die in dem Prozesssteuersystem 36 erzeugt wurde, um über das Unternehmen 10 verteilt zu werden, wird nachfolgend eine Diskussion der Art und Weise geliefert, in der Alarm- und Ereignisinformation von dem Prozesssteuersystem 36 erzeugt wird. In dem in Fig. 2 gezeigten Prozesssteuersystem 36 arbeitet der Computer 114 als eine Bedienerworkstation und weist eine Alarm- oder Ereignisverarbeitungssoftware 150 darin gespeichert auf. Allgemein ausgedrückt, zeigt die Alarm- oder Ereignisverarbeitungssoftware 150 Informationen über das Prozesssteuersystem 36 angemessen auf das Verständnis des Bedieners oder die Fähigkeit, den aktuellen Betriebsstatus des Prozesses in Bezug auf die in dem System 36 vorhandenen Alarme zu betrachten. Beispielsweise kann die Alarm- oder Ereignisverarbeitungssoftware 150 ein Alarmbanner mit Alarmanzeigen darin und eine primäre Steueranzeige anzeigen, die einen Bereich des Prozesssteuersystems 36 darstellt, einschließlich der Geräte und anderer Ausrüstung, die den Bereich des Prozesssteuersystems 36 zugeordnet und relevant für einen der Alarme oder Ereignisse ist. Die primäre Steueranzeige kann Informationen über den aktuellen Status des Prozesssteuersystems 36 liefern, beispielsweise den Flüssigkeitsstand in einem Tank, die Fließcharakteristik eines Ventils und anderer Fluidleitungen, die Stellung von Ausrüstung, das Ablesen von Sensoren, etc.
Ein Bediener kann die Alarm- und Ereignisverarbeitungssoftware 150 verwenden, um unterschiedliche Teile des Prozesssteuersystems 36 oder Ausrüstung in dem Prozesssteuersystem 36 zu betrachten. Da selbstverständlich die Alarm- und Ereignisverarbeitungssoftware 150 mit der Steuerung 112 kommuniziert und, falls notwendig, mit den Feldgeräten 125 bis 139 jeden der Banken von I/O-Geräten 120, 122 oder mit irgend anderen Geräten, um die relevanten Werte, Einstellungen und Messungen zu erhalten, die dem Prozesssteuersystem zugeordnet oder von diesen erstellt werden, um den Schnittstellenbildschirm auf der Bedieneranzeige des Computers oder der Workstation 114 zu erzeugen.
Die Alarm- und Ereignisverarbeitungssoftware 150 kann konfiguriert sein, um Alarmnachrichten zu empfangen, die von Alarmerzeugungssoftware in einigen oder allen der Steuerungen 112, der I/O-Geräte 120 und 122 und/oder in den Feldgeräten 125 bis 139 erzeugt wurde. Diese Software ist in Fig. 2 dargestellt als Softwareelemente 151, 152 und 153. Im allgemeinen empfängt die Alarm- oder Ereignisverarbeitungssoftware 150 verschiedene Kategorien von Alarm- oder Ereignisnachrichten, einschließlich beispielsweise Prozessalarmen (die üblicherweise durch ein Prozesssteuer-Softwaremodul erzeugt wird, beispielsweise von solchen, die von kommunikativ verbundenen Funktionsblöcken gemeldet werden, die während der Laufzeit des Prozesses zur Bildung von Prozesssteuerroutinen verwendet werden), von Hardwarealarmen, beispielsweise Alarmen, die von den Steuerungen 112, den I/O-Geräten 120 und 122 oder den Workstations 114 und 115 erzeugt werden, die den Status oder Betriebszuständen dieser Geräte betreffen, und von Gerätealarmen, die durch einige oder alle der Feldgeräte 125 bis 139 erzeugt werden, um diesen Geräten zugeordnete Probleme anzuzeigen. Diese oder andere Kategorien von Alarmen oder Ereignissen können in jeder gewünschten Weise erzeugt werden. Beispielsweise ist es bekannt, Funktionsblöcke oder Softwaremodule aufzuweisen, die verwendet werden, die Prozesssteuerungsfunktionen implementieren, um Prozessalarme zu erzeugen und dass diese Prozessalarme üblicherweise in Form von Alarmnachrichten an die Bedienerschnittstellen zur Anzeige gesendet werden. Auch können neuere, intelligente Geräte, Steuerungen, I/O-Geräte, Datenbanken, Server, Workstations, etc. jede gewünschte proprietäre oder nichtproprietäre Software verwenden, um Probleme, Fehler, Wartungsalarme, etc. zu erfassen, und sie können Alarme oder Ereignisse senden, die diese Zustände an der Bedienerschnittstelle des Computers oder der Workstation 114 anzeigen. Insbesondere sind viele der heute erhältlichen Geräte, beispielsweise Steuerungen, I/O-Geräte und intelligente Feldgeräte, mit Software und/oder Sensoren ausgestattet, die Hardwareprobleme erfassen, beispielsweise einen blockierten Ventilstopfen, gebrochene Teile, Wartungsangelegenheiten, etc. und sie können Signale oder Nachrichten erzeugen, die diese Zustände anzeigen.
Im allgemeinen gibt es verschiedene Kategorien von Alarmen oder Ereignissen, die erzeugt und angezeigt werden können, einschließlich beispielsweise Prozessalarme, Gerätealarme und Hardwarealarme. Prozessalarme zeigen im allgemeinen ein Problem mit dem funktionellen Betrieb einer Prozesssteuersoftware an, das ist ein Problem mit der Prozesssteuerroutine selber, beispielsweise eine Außer-Band-Messung, anormale Abweichungen zwischen Prozessparametern und Sollwerten, etc. Prozessalarme sind üblicherweise von dem Anwender als Komponenten der Prozesssteuermodule konfiguriert und erscheinen in der Konfigurationsformation, die auf der Bedienerschnittstelle bereitgestellt wird, als ein Modul Namen zugeordnet. Einige Arten von Prozessalarmen weisen fehlerhafte Ein/Ausgabe Außer-Band- Messungen, überschrittene Schwellwerte, etc. auf. Da Prozessalarme im Stand der Technik bekannt sind, werden sie hierin nicht im Detail beschrieben.
Gerätealarme sind Alarme, die den Betrieb der Feldgeräte in dem Prozess zugeordnet sind, und können durch eine Software (beispielsweise die Software 153 in Fig. 2) in den Feldgeräten oder in anderen Geräten erfasst werden, die in dem Prozesssteuersystem 36 verbunden sind, um ein Problem oder einen Fehler mit dem Betrieb eines Feldgerätes anzuzeigen. Gerätealarme können auf der Bedienerschnittstelle des hierin beschriebenen Systems als einem bestimmten Gerät zugehörig erscheinen. Gerätealarme können beispielsweise anzeigen, dass der Druck in einem Ventil zu groß oder zu gering für einen geeigneten Betrieb des Ventils ist, dass der Motorstrom in dem Ventil zu hoch oder zu niedrig ist, dass die Spannungsniveaus eines Gerätes nicht synchronisiert sind, dass ein Ventilstopfen in einem Ventil blockiert ist, dass das Gerät ungenügend kommuniziert, dass das Gerät geplante Wartung benötigt, da beispielsweise ein bestimmter Zeitraum verstrichen ist oder da ein Ventilteil des Gerätes eine bestimmte Menge von Bewegungen seit der letzten Wartung durchgeführt hat, etc. Gerätealarme können in jeder gewünschten Weise erzeugt werden, einschließlich unter Verwendung von proprietärer oder nicht proprietärer Software, die auf dem Gerät selber oder in anderen Geräten angeordnet ist, die mit dem Gerät verbunden sind, für das der Alarm erzeugt wird, um spezifische Probleme in dem Gerät zu erkennen und zu erfassen, und einen Alarm mit Bezug darauf zu erzeugen. Wie oben aufgezeigt wurde, werden inzwischen viele intelligente Geräte produziert, um Gerätealarme zu erzeugen und zu kommunizieren.
Selbstverständlich gibt es verschiedene unterschiedliche Arten von Gerätealarmen, einschließlich beispielsweise Fehleralarme, die anzeigen, dass ein mißlungener oder fehlerhafter Zustand in einem Gerät existiert, Wartungsalarme, die anzeigen, dass Wartung von einem Typ stattfinden sollte, Kommunikationsalarme, die anzeigen, dass ein Gerät nicht geeignet oder überhaupt nicht kommuniziert, Vorschlagsalarme, etc. Ein Fehler (beispielsweise ein mißlungener) Alarm zeigt an, dass ein Gerät einen oder mehrere Zustände erfasst hat, die anzeigen, dass es eine kritische Funktion nicht ausführen kann und deshalb unverzüglich Aufmerksamkeit benötigt. Andererseits zeigt ein Wartungsalarm an, dass ein Gerät kritische Funktionen ausführen kann, aber dass es einen oder mehrere Zustände erfasst hat, die zu einem Fehler führen könnten, wenn sie unbeantwortet bleiben und deshalb sollte das Gerät bald eine Wartung erfahren. Ein Kommunikations- (beispielsweise ein "Nicht-Kommunikations") Alarm wird aktiv, wenn ein Gerät die Kommunikation beendet. Ein Vorschlagsalarm zeigt an, dass ein Gerät Zustände erfasst hat, die nicht in die anderen Alarmkategorien fallen. Üblicherweise ist ein Vorschlagsalarm ein Alarm, der von individuellen Geräten, insbesondere von der Art von Geräten liefert, beispielsweise eines Flussmessers, das die Veränderung des Fluss-Signals verfolgt. In diesem Fall kann das Gerät erkennen, dass eine Veränderung in einem dem Gerät zugeordneten Signal zu hoch oder zu niedrig ist, was bedeutet, das irgend etwas ungewöhnliches passiert ist und Nachprüfung erfordert. Geräteabhängig können Vorschlagsalarme mehr oder weniger dringend Aufmerksamkeit als Wartungsalarme erfordern und deshalb können Anwender die Priorität von Vorschlagsalarmen niedriger als die von Wartungsalarmen setzen. Fehler-, Wartungs- und Vorschlagsalarme können jedoch nicht von jedem Gerät unterstützt werden und ein einzelner, umfassender Alarm, beispielsweise ein "anormaler" Alarm für generische Geräte kann anstatt der Fehler-, Wartungs- und Vorschlagsalarme verwendet werden, was zu zwei totalen Alarmen führt, das sind Nicht-Kommunikations- und anormaler Alarm. Selbstverständlich können auch andere Arten von Gerätealarmen erzeugt oder verwendet werden anstatt oder zusätzlich zu einem der vorstehend diskutierten.
Wie vorstehend diskutiert, können Gerätealarme oder Warnungen anzeigen, dass ein Gerät einen Fehler aufweist, dass ein Gerät Wartung benötigt oder sie können von der Art eines Vorschlages sein. Zusätzlich kann detailliertere Information in Verbindung mit einem Gerätealarm bereitgestellt werden, beispielsweise können vorgeschlagene Aktionen bereitgestellt werden, um den Anwender, den Systembetreiber, eine Wartungsperson, etc. zu instruieren, was in Bezug auf einen bestimmten Alarmzustand zu tun ist.
In dem Fall von Geräten der Fieldbus-Stiftung können Gerätealarme oder Nachrichten Informationsfelder aufweisen, beispielsweise Datum, Zeit, TAG (das ist eine eindeutige Identifizierung für ein bestimmtes Gerät), Warnung (beispielsweise ob das Gerät fehlerhaft ist, eine Wartung braucht oder ob der Alarm ein Vorschlag ist), Beschreibung, Wertigkeitsniveau, empfohlene Aktion, Status (das ist ob die Alarmnachricht bestätigt wurde oder weiterhin unbestätigt ist).
Zusätzlich zur Verarbeitung von Alarmen und Ereignissen kann die Software 150 Ausrüstungsbedingungsinformation erzeugen und/oder verarbeiten und Bedingungsinformation verarbeiten. Weiterhin können ein oder mehrere zusätzliche Softwareprogramme in den Computern 114 und 115 ausgeführt werden, um eine Vielfalt von bekannten fortgeschrittenen Steuerungen und Bedingungsüberwachungsaktivitäten auszuführen. Beispielsweise können die Computer 114 und 115 Vibrationsüberwachungssoftware, Echtzeitoptimierungssoftware, Expertensystemsoftware, prädikative Wartungssoftware, Schleifenüberwachungssoftware oder jede andere gewünschte Software aufweisen, die Daten verarbeitet, die von dem Prozesssteuersystem erhalten wird.
Fig. 3 stellt ein detaillierteres, funktionales Blockdiagramm des in Fig. 1 gezeigten XML-Servers 52 dar. Wie vorstehend festgestellt, verwendet der XML-Server 52 eine erweiterbare Markup-Sprache, beispielsweise XML, um die Kommunikation von Transaktions-Informationen und insbesondere Transaktions- Prozesssteuerdaten (Alarmdaten oder Gerätealarme, Prozesszustandsdaten, Ausrüstungszustandsdaten, etc.) überall in dem Unternehmen 10 zu ermöglichen. Obwohl erweiterbare Markup-Sprachen, beispielsweise XML, bekannt sind, wird nachfolgend eine kurze Diskussion von XML geliefert, um das Verständnis der hierin beschriebenen Transaktions-Datenkommunikationstechnik zu erleichtern.
Im allgemeinen ermöglicht XML virtuell jeder Art von Daten oder Informationen (einschließlich Transaktionsdaten), mit einem Schema eingehüllt oder eingekapselt zu werden, das für die Information oder Daten eine Struktur (d. h. ein Format) definiert und bereitstellt. Es ist bekannt, dass XML eine selbstschreibende Sprache ist, in der die verschiedenen Elemente von jedem gegebenen Schema die eingekapselten oder eingehüllten Daten beschreiben. Es ist weiterhin bekannt, dass XML von dem gleichen Standard entwickelt wurde, der zur Entwicklung der heute vertrauten Hypertext-Markup-Sprache (HTML) führte, die ein Standard zur Übertragung von grafischer Anzeigeninformation über das Internet wurde. Obwohl XML-eingekapselte oder -eingehüllte Daten einfach über das Internet versendet werden können, wie es HTML-formatierte Daten können, ist XML grundlegend verschieden von HTML, da XML Definition und Struktur für die gesendeten Daten (im Gegensatz zu im wesentlichen Formatieren der Anzeige der transportierten Daten, was bei HTML der Fall ist) liefert. Daraus folgt, das XML der primäre Mechanismus wurde, durch den unterschiedliche Geschäftseinrichtungen Transaktions-Informationen über das Internet austauschen.
Als Beispiel bezieht die Bestellung von Konsumgütern über eine Einzelhändler- Website üblicherweise einen Austausch von Transaktionsdaten ein, die in ein XML- Schema eingekapselt oder eingehüllt wurden. Ebenfalls zieht eine Transaktion an einer automatisierten Schaltermaschine den Austausch von Transaktionsdaten ein, die eine XML-Kapsel oder -Hülle verwenden kann, um die Transaktionsdaten zu übertragen. In dem Fall der Beschaffung eines Produkts über eine Internetseite, kann der Inhaber der Einzelhändler- oder Hersteller-Website eine Auftragseingangsinformation (das sind Transaktionsdaten) von einem Kunden empfangen und in Antwort darauf den Lagerbestand und die Lieferzeit überprüfen. Wenn der Händler oder Hersteller entdeckt, dass der Vorrat aufgebraucht oder inakzeptabel niedrig ist, können zusätzliche Einheiten bestellt werden. Wenn ein geschätztes Versanddatum lieferbar ist, kann der Händler oder Hersteller eine Email oder jede andere Form von elektronischer Nachricht senden, um dem Kunden zu bestätigen, wann die bestellten Produkte versendet werden. Zusätzlich kann der Händler oder Hersteller eine Belastung auf eine Kredit- oder Zahlkartennummer eingeben, die von dem Kunden bereit gestellt wurde. Auf diese Weise können heutige Systeme, die Informationen unter Verwendung von XML- Schemata austauschen, verwendet werden, um wirksamer Transaktionsdaten oder Informationen über das Internet oder unter Verwendung jedes anderen Kommunikationsnetzwerkes oder Verbindung zu übermitteln. Wichtig ist, dass heutige XML-basierte Kommunikationssysteme die Übertragung von Transaktions- Prozesssteuerdaten zwischen den verschiedenen Komponenten oder Systemen eines Unternehmens nicht ermöglichen oder erleichtern. Auch ermöglichen diese konventionellen XML-basierten Systeme nicht die Übertragung von Transaktions- Prozesssteuerdaten von einer Geschäftseinrichtung zu einer anderen über ein Kommunikationsnetzwerk, beispielsweise das Internet.
Die hierin beschriebene Transaktions-Datenkommunikationstechnik ermöglicht es Transaktions-Informationen, beispielsweise Transaktions-Prozesssteuerdaten, zwischen verschiedenen Komponenten, Geräten und Geschäftseinrichtungen eines Unternehmens ausgetauscht zu werden. Insbesondere hüllt oder kapselt die hierin beschriebene Transaktions-Datenkommunikationstechnik Transaktions- Prozesssteuerdaten, beispielsweise Alarm- und Ereignissinformation, Prozesszustandsinformation, Ausrüstungszustandsinformation, etc. unter Verwendung eines XML-Schemas ein, das einfach zwischen verschiedenen Geräten, Komponenten und Systemen in dem Unternehmen übermittelt werden kann, unbeachtlich davon, ob die Kommunikationen das Internet, ein LAN oder jedes andere Kommunikationsmedium und -technologie verwenden. Zusätzlich verwendet die hierin beschriebene Transaktions-Datenkommunikationstechnik einen XML-Transaktionsserver, um die Kommunikation von XML-eingekapselter oder -gehüllter Transaktions-Prozesssteuerdaten zwischen den Systemen zu erleichtern, die ein Unternehmen ausmachen. Auf diese Weise können Prozesssteuersysteme in einem Unternehmen vollständig integriert mit den Informationstechnologiesystemen sein, die von dem Unternehmen verwendet werden.
Genauer, der XML-Server 52 kann unter Verwendung jedes geeigneten XML- Transaktionsservers implementiert sein. Beispielsweise werden kommerziell erhältliche XML-Transaktionsserver unter den Markenname Vignette, Data Junction, Ariba, Click Commerce und Microsoft Biztalk Server 2000 geliefert oder verkauft. Obwohl die folgende Diskussion die Transaktions- Datenkommunikationstechnik primär auf Basis des Microsoft Biztalk Server 2000 beschreibt, ist es klar, dass jeder andere existierende oder später zu entwickelnde XML-Transaktionsserver ähnlich ausgebildet ist, um die hierin beschriebene Transaktions-Datenkommunikationstechnik auszuführen, ohne den Rahmen und den Bereich der Erfindung zu verlassen.
Wie in Fig. 3 gezeigt, kann der XML-Server 52 eine Mehrzahl von funktionalen Blöcken und Datenbanken aufweisen. Insbesondere kann der XML-Server 52 einen Schemaeditor 200, einen Schemaabbildungsblock 202, einen "Orchestrierungsblock" 204, eine Schemadatenbank 206, eine Datenhandhabungsfunktions-Datenbank 208 und eine Geschäftsregeldatenbank 210 aufweisen. Der Schemaeditor 200 ermöglicht einem Anwender, Eingabe- und Ausgabeschemata für die Kommunikation von mit dem Prozesssteuersystem 36 erzeugte Transaktions-Prozesssteuerdaten zu definieren. Ein beispielhaftes Eingabeschema für eine Gerätewarnung oder -Alarm, die mit dem Prozesssteuersystem 36 erzeugt wurden, ist in Fig. 4 gezeigt. Wie in Fig. 4 gezeigt, sind die Informationen, Attribute oder Elemente, die üblicherweise in einem Gerätealarm (device alert) enthalten sind, beispielsweise ein Datum (date), eine Zeit (time), ein TAG, ein Alarm (alert) (beispielsweise Fehler-, Wartungs- oder Vorschlagsalarm), eine Beschreibung (describtion), eine Wertigkeit (priority), eine vorgeschlagene Aktion (action), ein Status (state), etc. eingehüllt oder eingekapselt in einem XML-Format, einschließlich spezifischer Trennzeichen, Zeichen, etc. die eine Verarbeitung des XML-formatierten Gerätealarms durch den XML-Server 52 ermöglichen. Der Schemaeditor 200 ermöglicht einem Anwender weiterhin, einen Namen für jedes Attribut oder Element zu definieren, ein Format für die jedem Elementnamen zugeordneten Daten zu definieren und zu definieren, ob jedes Element des Schemas für die Validierung des Schemas benötigt wird oder nicht. Obwohl das vorstehende Beispiel ein Schema für einen Gerätealarm illustriert, ermöglicht der Schemaeditor 200 einem Anwender, ein Eingabeschema für jede gewünschte Art von Transaktionsdaten zu definieren, die durch das Prozesssteuersystem 36 zu dem XML-Server 52 gesendet werden können. Wie im größeren Detail weiter unten beschrieben wird, muss das Prozesssteuersystem 36 dazu konfiguriert sein, Transaktions-Prozesssteuerdaten an den XML-Server 52 unter Verwendung des geeigneten Schemaformates (d. h. unter Verwendung eines geeigneten XML-Eingabeschemas) zu senden.
Der Schemaeditor 200 kann weiterhin verwendet werden, um verschiedene Ausgabeschemata zu erzeugen, von denen jedes mit einer bestimmten Anwendung korrespondiert, die auf einem der Systeme 30 bis 48, der Anlagen 14 bis 18 der Zulieferer 20 und 22, der Kunden 24 und 26 oder jeder anderen Komponenten, System, Einrichtung, etc. in dem in Fig. 1 gezeigten Unternehmen 10 läuft. Im allgemeinen definiert ein Ausgabeschema die Information, die von einer bestimmten Anwendung benötigt wird, um ihre Verarbeitungsaktivitäten auszuführen. Beispielsweise kann ein Ausgabeschema, das dem Bestellverarbeitungssystem 30 zugeordnet ist, Daten beispielsweise als eine Teilenummer, einen Zulieferernamen, eine Menge, etc. definieren. Natürlich kann jedes System Komponenten, Einrichtungen, etc. in dem Unternehmen 10 eine Mehrzahl von unterschiedlichen Schemata verwenden und, obwohl einige Ausgabeschemata von mehr als einem System in dem Unternehmen 10 verwendet werden können, ist das nicht notwendigerweise der Fall und in der Tat jedes System in dem Unternehmen 10 kann einen einzigartigen Satz von Ausgabeschemata aufweisen. Auf jeden Fall können die Eingabe- und Ausgabeschemata, die unter Verwendung des Schemaeditors 200 erzeugt wurden, in der Schemadatenbank 206 abgespeichert werden und es kann auf sie zugegriffen werden und sie können bei Bedarf durch den XML-Server 52 verwendet werden.
Weiterhin sollte erkannt werden, dass Eingabe- und Ausgabeschemata für jede Einrichtung, System, Komponente, etc. in dem Unternehmen 10 kreiert oder erzeugt werden kann. Deshalb können beide, Eingabe- und Ausgabeschemata, erzeugt werden, um Informationen oder Daten an oder von dem Prozesssteuersystem zu übermitteln. Gleichfalls können Eingabe- und Ausgabeschemata erzeugt werden für jedes andere System, beispielsweise das Produktionsausführungssystem, das Unternehmensbetriebsmittel-Planungssystem, etc. in dem Unternehmen 10, um Informationen an oder von diesen Systemen zu übermitteln. Der Schemaabbildungsblock 202 ermöglicht einem Anwender jedes Eingabeschema auf ein oder mehrere Ausgabeschemata abzubilden.
Beispielsweise kann ein Eingabeschema, das einem mit dem Prozesssteuersystem 36 erzeugten Gerätealarm zugeordnet ist, auf Ausgabeschemata abgebildet werden, die dem Wartungsmanagementsystem 42, dem Auftragsverarbeitungssystem 30, dem Zulieferer 20 oder jeder anderen Komponente, System oder Einrichtung in dem Unternehmen 10 zugeordnet sind. Gleichfalls können eine oder mehrere Eingabeschemata, die dem Wartungsmanagementsystem 42, dem Auftragsverarbeitungssystem 30, dem Zulieferer 20, oder jeder anderen Komponente, System oder Einrichtung in dem Unternehmen 10 zugeordnet sind, auf ein oder mehrere Ausgabeschemata abgebildet werden, die dem Prozesssteuersystem 6 zugeordnet sind. Beim Abbilden von Eingabeschemata auf Ausgabeschemata können eines oder mehrere der Datenelemente oder Attribute von jedem Eingabeschema auf ein oder mehrere Datenelemente oder Attribute von einem Ausgabeschema abgebildet werden. Da keine eins-zu-eins-Korrespondenz zwischen den Datenelementen der Eingabeschemata und Ausgabeschemata bestehen kann, kann die Datenzuordnung die unter Verwendung des Abbildungsblocks 202 durchgeführt wird, Zwischendatenhandhabungen einbeziehen. Diese Zwischendatenhandhabungen ermöglichen einem oder mehreren Eingabeschema- Datenelemente unter Verwendung von Datenhandhabungsfunktionen verarbeitet oder kombiniert zu werden, beispielsweise Reihenverknüpfungen, mathematische Operationen, Zahlenerzeugung, etc., die alle in der Datenhandhabungsfunktions- Datenbank 208 gespeichert sein können.
Wenn Eingabe- und Ausgabeschemata abgebildet werden, muss jedes benötigte Datenelement eines Ausgabeschemas auf mindestens einem korrespondieren Datenelement eines Eingabeschemas abgebildet werden. Da natürlich einige oder alle der Datenelemente eines bestimmten Eingabeschemas nicht während der Abbildung verwendet werden, und nicht alle Datenelemente eines Ausgabeschemas (d. h. die Datenelemente, die nicht benötigt werden) müssen auf Datenelemente eines Eingabeschemas abgebildet werden. Weiterhin können mehrere Datenelemente eines Eingabeschemas auf ein einzelnes Datenelement eines Ausgabeschemas unter Verwendung der vorstehend bezeichneten Datenhandhabungsfunktionen kombiniert oder in anderer Weise manipuliert und abgebildet werden.
Fig. 5 ist eine beispielhafte Diagrammansicht, die eine Art und Weise illustriert, in der die hierin beschriebene Transaktions-Datenkommunikationstechnik verwendet werden kann, um ein Eingabeschema auf ein Ausgabeschema abzubilden. Wie in Fig. 5 gezeigt, weist ein Eingabeschema 300, welches lediglich beispielhaft als das Gerätealarmschema aus Fig. 4 dargestellt wird, eine Mehrzahl von Attributen oder Datenelementen 302 auf. In diesem Beispiel ist das Eingabeschema 300 dem Prozesssteuersystem 36 zugeordnet. Alternativ kann das Eingabeschema 300 jedoch jeder anderen Einrichtung, System, Komponente, etc. in dem Unternehmen 10 zugeordnet sein. Eine oder mehrere Datenhandhabungsfunktion 304 können verwendet werden, um verschiedene der Attribute oder Datenelemente 302 zu kombinieren, um dadurch die Attribute oder Datenelemente 302 auf entsprechende Attribute oder Datenelemente 306 eines Ausgabeschemas 308 abzubilden. In dem Fall, in dem das Eingabeschema 300, was vorliegend ein Gerätealarm-Eingabeschema ist, dem Prozesssteuersystem 36 zugeordnet ist, kann das Ausgabeschema 308 Wartungsmanagementsystem 42 zugeordnet sein. Auf diese Weise können Transaktionsdaten, wie Alarmdaten von dem Prozesssteuersystem 36 zu dem Wartungsmanagementsystem 42, kommuniziert werden.
Erneut unter Bezug auf Fig. 3, ermöglicht der "Orchestrierungsblock" 204 einem Anwender, eine oder mehrere Geschäftsregeln, die in der Geschäftsregel- Datenbank 210 gespeichert sein können, als eine Antwort auf Ereignisse zu implementieren, die in dem Unternehmen 10 auftreten. Üblicherweise, aber nicht notwendigerweise wird der "Orchestrierungsblock" 204 verwendet, um gleichzeitig die Vervollständigung von verschiedenen Aktivitäten in Antwort auf ein Ereignis, beispielsweise ein Gerätealarm zu erleichtern, der in dem Prozesssteuersystem 36 auftritt. Die Geschäftsregeln können Komponenten, Abrufdaten aus den Datenbanken, Verknüpfungsaktionen zu Ereignissen, Verwaltungsaktionsaufträge, etc. speichern. Auf jeden Fall sind derartige Geschäftsregel- Orchestrierungsmechanismen im Stand der Technik bekannt und werden hier nicht weiter beschrieben.
Im Betrieb ermöglichen die Ergebnisse der Abbildung von Eingabeschemata auf Ausgabeschemata und die Orchestrierung von Aktionen in Antwort auf Ereignisse in dem Prozesssteuersystem 36, dass Transaktions-Prozesssteuerdaten, beispielsweise Gerätealarme oder Ereignisse, Prozesszustandsinformation und Ausrüstungszustandsinformation überall in dem Unternehmen 10 kommuniziert werden kann. Zusätzlich ermöglicht die Orchestrierungsfähigkeit des XML-Servers 52, dass Transaktions-Prozesssteuerdaten an verschiedene Orte gleichzeitig versendet werden können. Lediglich beispielhaft kann der "Orchestrierungsblock" 204 verwendet werden, um einen von dem Prozesssteuersystem 36 empfangenen Gerätealarm an einen Pager zu senden, der von einem Servicetechniker getragen wird, und er kann zur gleichen Zeit verwendet werden, um den Gerätealarm an eine Anwenderschnittstelle zur Anzeige zu leiten. Die von einer Orchestrierungsroutine definierten Aktionen, die auf Gerätealarmschemata reagieren, können beispielsweise auf Basis der empfangenen Arten von Gerätealarmen variieren. Es können zum Beispiel geeignete Aktionen durchgeführt werden, auf Basis, ob der Gerätealarm ein Wartungs-, Vorschlags- oder Fehleralarm ist. Natürlich kann der Gerätealarm ebenfalls mittels Eingabe- und Ausgabeschemata wie vorstehend beschrieben zugeordnet werden, um das Wartungsmanagementsystem 42 zu bewirken, in Antwort auf den Gerätealarm eine Arbeitsanweisung zu erzeugen.
Genauer, der Schemaeditor 200 kann verwendet werden, um ein Gerätealarm- Eingabeschema auf ein Ausgabeschema abzubilden, das einer Anwendung zugeordnet ist, die in dem Wartungsmanagementsystem 42 ausgeführt wird.
Daraus folgt, dass, wenn ein Gerätealarm in dem Prozesssteuersystem 36 auftritt, das Prozesssteuersystem 36 den Gerätealarm in einem geeigneten XML-Schema (d. h. unter Verwendung eines Formates, das durch einen in dem XML-Server 52 gespeicherten Gerätealarm-Eingabeschema spezifiziert ist) einkapselt oder einhüllt, und es sendet den XML-Gerätealarm an den XML-Server 52 zur Verarbeitung. Nach Erhalt bestimmt der XML-Server 52 ob der XML-Gerätealarm gültig ist (d. h. ob er alle benötigten Attribute oder Datenelemente aufweist) und bildet anschließend diesen XML-Gerätealarm auf ein Ausgabeschema ab, das dem Wartungsmanagementsystem 42 zugeordnet ist, unter Verwendung von Zuordnungsoperationen, die vorher durch den Schemaabbildungsblock 202 definiert wurden. Das Wartungsmanagementsystem 42 empfängt anschließend einen zugeordnete XML-Gerätealarm, der angezeigt, ausgedruckt oder auf andere Weise dem Systemwartungspersonal oder jedem anderen Betreiber übermittelt werden kann.
Zusätzlich kann der "Orchestrierungsblock" 204, wenn der XML-Server 52 den XML-Gerätealarm empfängt, basierend auf der Art des Gerätealarms (d. h. ob der Alarm ein "FAILED", "MAINTENANCE", oder "ADVISORY" anzeigt) verschiedene Aktionen initiieren und ausführen. Beispielsweise in dem Fall, dass der Gerätealarm anzeigt, dass eine Wartung erforderlich ist, kann der "Orchestrierungsblock" 204 auf Basis der in den Geschäftsregelndatenbank 210 gespeicherten Geschäftsregeln automatisch eine Page-Nachricht oder eine andere Kommunikation zur Sendung an einen Wartungstechniker bewirken, er kann einen Systembetreiber über eine grafische und/oder Textnachricht alarmieren, die auf einem Betreiberterminal angezeigt wird, er kann die Information senden, um sie auf einer Webpage anzuzeigen, etc.
Die hierin beschriebene Transaktions-Datenkommunikationstechnik kann also verwendet werden, um die Ausführung einer Stapelprozesskampagne in dem Unternehmen 10 zu erleichtern. In diesem Fall verwendet der Systembetreiber das Produktionsplanungssystem 48, um eine Stapelkampagne zu planen oder zu erzeugen. Ist die Stapelkampagne erzeugt, füllt das Produktionsplanungssystem 48 die Kampagneninformation (beispielsweise Stapel-ID, Rezeptur, Anzahl der benötigten Stapel, etc.) in ein geeignetes XML-Schema und sendet die XML- Kampagnenplanungsinformation an den XML-Server 52. Der XML-Server 52 bestimmt dann, ob die XML-Kampagneninformation ein gültiges Schema (d. h. ob es alle benötigten Datenfelder für ein Eingabeschema enthält) aufweist, und wenn das Schema gültig ist, bildet der XML-Server 52 das XML-Kampagnenschema auf ein geeignetes Ausgabeschema ab, das dem Prozesssteuersystem 36 zugeordnet ist. Der XML-Server 52 sendet anschließend die Kampagneninformation an das Prozesssteuersystem 36 in einem eingehüllten Kampagnenausgabeschema. Das Prozesssteuersystem 36 kann dann die Kampagneninformation aus diesem Ausgabeschema extrahieren und mit der Ausführung der Kampagne beginnen.
Fig. 6 ist eine beispielhafte Diagrammansicht, die eine Art und Weise darstellt, in der das in den Fig. 1 und 2 gezeigte Prozesssteuersystem 36 konfiguriert sein kann, um eine Kommunikation von Transaktions-Informationen oder Daten zwischen dem Prozesssteuersystem 36 und jeder anderen Einrichtung, System, Komponente, etc. des Unternehmens 10 zu ermöglichen. Die in Fig. 6 gezeigte Systemarchitektur weist einen Eingabe/Ausgabe (I/O) -Subsystemblock 400, einen Prozesssteuer-Subsystemblock 402, einen eingebetteten, erweiterten Steuer- und Zustandsüberwachungs-Block 404, einen Webdienste-Block 406 und eine Webdienste-Schnittstelle 408 auf. Der I/O-Subsystemblock 400 weist die Steuerungen 112, die Banken der I/O-Geräte 120 und 122 und die damit verbundenen Feldgeräte auf. Wohingegen der Prozesssteuer-Subsystemblock 402 vorzugsweise, aber nicht notwendigerweise, derart implementiert, ist eine oder mehrere Softwareroutinen zu verwenden, beispielsweise die Routine 150, die in einer oder mehreren der Workstations 114 und 115 ausgeführt werden kann. Beispielsweise kann der Prozesssteuer-Subsystemblock 402 Routinen aufweisen, die Steuerfunktionen, Betreiberschnittstellen-Funktionen, Alarm- und Ereignis- Verarbeitungsfunktionen, Echtzeitdaten-Verarbeitungsfunktionen oder jede anderen gewünschten Funktionen ausführen. Der eingebettete, erweiterte Steuer- und Zustandsüberwachungs-Block 404 kann derart implementiert sein, eine Mehrzahl von Routinen zu verwenden, die Daten und andere Informationen verarbeiten, die dem Betrieb, den Zuständen, etc. des Prozesssteuersystems 36 zugeordnet sind. Beispielsweise kann der eingebettete, erweiterte Steuer- und Zustandsüberwachungs-Block 404 Vibrationsüberwachungsroutinen, Echtzeitoptimierungsroutinen, Expertensystemroutinen, prädiktive Wartungsroutinen, Schleifenüberwachungsroutinen oder jede anderen gewünschten Datenanalyse- oder Datenverarbeitungsroutinen aufweisen. Eine oder mehrere der Routinen, die durch den eingebetteten, erweiterten Steuer- und Zustandsüberwachungs-Block 404 ausgeführt werden, können in dem gleichen Computersystem oder Workstation ausgeführt werden, die verwendet wird, um Routinen auszuführen, die dem Prozesssteuer-Subsystemblock 402 zugeordnet sind, oder alternativ können eine oder mehrere der Routinen, die dem eingebetteten, erweiterten Steuer- und Zustandsüberwachungs-Block 404 zugeordnet sind in jeder anderen Workstation oder Computersystem ausgeführt werden, das kommunikativ mit dem Prozesssteuer-Subsystemblock 402 gekoppelt ist.
Der Webdienste-Block 406 kann einen Alarm- und Ereignisschnittstellen-Block 410, einen Prozesszustandsüberwachungs-Block 412 und einen Ausrüstungszustandsüberwachungs-Block 414 aufweisen, die alle mit dem entsprechenden Webdienste-Listenerprogrammen 416, 418 und 420 kommunikativ gekoppelt sind. Zusätzlich kann der Wedienste-Block 406 einen Webdienste- Listenerprogrammblock 422 aufweisen, der direkt, wie in Fig. 6 gezeigt, mit dem Prozesssteuer-Subsystemblock 402 kommunikativ gekoppelt ist. Im allgemeinen ermöglicht der Webdienste-Block 406, dass Information oder physikalische Daten, die Alarmen oder Ereignissen, Prozesszuständen und Ausrüstungszuständen in dem Prozesssteuersystem 36 zugeordnet sind, an und von einer Mehrzahl von Informationstechnologiesystemen übertragen werden. Genauer, der Webdienste- Block 406 stellt einen Teil eines Webdienste-Gerüstes oder Architektur bereit, das Intra-Systemkommunikationen erleichtert, da konventionelle und üblich verwendete Transportprotokolle, beispielsweise Hypertext-Transportprotokoll (HTTP) und Datenformalprotokolle, beispielsweise XML und SOAP, verwendet werden können, um Prozesssteuerinformationen zwischen den Systemen eines Unternehmens zu übertragen. Wie weiter unten im Detail beschrieben wird, empfangen die Webdienste-Listenerprogramme 416 bis 422 einkommende Nachrichten, die Anforderungen für Dienste enthalten, analysieren diese einkommenden Nachrichten und senden die Anforderungen für Dienste an die geeigneten Verfahren, die in dem Webdienste-Block 406 zur Verfügung stehen. Vorzugsweise, aber nicht notwendigerweise, empfangen die Webdienste- Listenerprogramme 416 bis 422 Dienstanforderungen und liefern ebenfalls Dienstantworten. Weiterhin können die Listenerprogramme 416 bis 422 Verträge und andere Dokumente liefern, die dem Webdienst oder Diensten zur Kommunikation mit dem Listenerprogramm zugeordnet sind. Zusätzlich übertragen die Webdienste-Listenerprogramme 416 bis 422 vorzugsweise, aber nicht notwendigerweise, Alarm- und Ereignisdaten, Prozesszustandsdaten und Ausrüstungszustandsdaten unter Verwendung eines XML-Formates.
Die Webdienste-Schnittstelle 408 verwaltet Kommunikation zwischen den verschieden Webdiensten in dem Webdienste-Block 406 und den Systemen, Einrichtungen, Komponenten, etc. in dem Unternehmen 10, von denen eine oder mehrere mit dem Prozesssteuersystem 36 über den Webdienste- Schnittstellenblock 408 als ein Webclient kommunizieren können. Allgemein liefert der Webdienste-Schnittstellenblock 408 eine Host- oder Webserverumgebung (d. h. eine gewöhnliche Schnittstelle), die einer Mehrzahl von technisch relativ unterschiedlichen Informationstechnologiesystemen, beispielsweise Produktionsausführungssystemen, Unternehmensbetriebsmittel- Planungssystemen, etc. oder jedem anderen System, das einem entfernt angeordneten Prozesssteueranlage, Kunden, Zulieferer, etc. zugeordnet ist, ermöglichen, Prozesssteuerinformationen oder Daten an und von dem Prozesssteuer-Subsystemblock 402 und dem erweiterten, eingebetteten Steuer- und Zustandsüberwachungs-Block 404 des Prozesssteuersystems 36 zu senden und zu empfangen. Insbesondere ist die Webdienste-Schnittstelle 408 ausgebildet, auf einkommende HTTP-Anforderungen zu achten, Sicherheitschecks unter Einbeziehung von Nutzer, Authentifikation/Verifikation durchzuführen, Verbindungsinformation zu überwachen und authorisierte HTTP-Anforderungen an geeignete der in dem Webserviceblock 406 zur Verfügung stehenden Dienste weiter zu senden (eine Verbindung mit diesen zu etablieren), eine automatische Verwertung von Service, Host-Umgebung und Systemfehlern zu erleichtern, administrative Erleichterung einzusetzen, Überwachen und Steuern von Diensten und Verwalten von Betriebsmitteln, Bereitstellen von beispielsweise Prozessen, gereihten und geteilten Stati zum Nutzen von jedem Dienst.
Wie vorstehend bemerkt, kann die hierin beschriebene Transaktions- Datenkommunikationstechnik verwendet werden, um Ausrüstungszustands-Daten oder Informationen, Prozesszustands-Daten oder Informationen und Alarm-, Warnungs- oder jede andere Ereignisdaten oder Information zwischen dem Prozesssteuersystem 36 und einem oder mehreren der Informationstechnologiesystemen, Zulieferern, Kunden, entfernten Anlagen, etc. in dem Unternehmen 10 zu übertragen. Beispielsweise kann das Wartungsmanagementsystem 42 (Fig. 1) mit dem Prozesssteuersystem 36 über dem XML-Server 52 unter Verwendung von XML-formatierten Daten kommunizieren, die in einem HTTP-Paket eingekapselt sind. Auf diese Weise kann das Wartungsmanagementsystem 42 ein Interesse am Empfang registrieren (d. h. eine Aufforderung) für Gerätealarminformation von dem Prozesssteuersystem 36. In Antwort auf solche HTTP-basierten Anforderungen kann die Webdienste- Schnittstelle 408 das Wartungsmanagementsystem 42 als ein geeigneter Klient des Webdienste-Blocks 406 authentifizieren. Klient-Authentifizierung kann auf eine Identität eines Anwenders an dem Wartungsmanagementsystem 42, die Identität des Wartungsmanagmentsystems 42 selber, ein Terminalort in dem Wartungsmanagementsystem 42 oder auf jede andere geeignete Identifizierungstechnik basieren. Wenn das Wartungsmanagementsystem 42 als ein geeigneter Klient authentifiziert ist, etabliert die Webdienste-Schnittstelle 408 eine Verbindung mit einem geeigneten Webdienst in dem Webdienste-Block 406.
Da das Wartungsmanagementsystem 42 ein Interesse an der Gerätealarminformation registriert, kann die Webdienste-Schnittstelle 408 in diesem Fall eine Verbindung mit einem Webdienst etablieren, der dem Webdienste-Listenerprogramm 416 und den Alarm- und Ereignis- Schnittstellenblock 410 zugeordnet ist. Ist eine derartige Verbindung etabliert, kann jede Art von Prozesssteuerinformation, auf die der Webdienst zugreifen kann, zwischen den Anforderungen des Klienten und dem Prozesssteuersystem unter Verwendung von HTTP-Paketen kommuniziert werden, die XML-formatierte Daten enthalten.
Wenn ein Gerät in dem Prozesssteuersystem 36 einen Gerätealarm oder einen Alarm, beispielsweise einen Wartungsalarm erzeugt, sendet das Prozesssteuersystem 36 den Wartungsalarm an den Webdienste-Block 406 über die Alarm- und Ereignisschnittstelle 410. Anschließend konvertiert der Webdienst, der dem Webservicelistenerprogramm 416 und der Alarm- und Ereignisschnittstelle 410 zugeordnet ist, den empfangenen Wartungsalarm in ein XML-Format und sendet anschließend die XML-formatierte Alarminformation oder Daten an das Wartungsmanagementsystem 42 über den XML-Server 52.
Selbstverständlich müssen wie vorstehend beschrieben, geeigneten Eingabe- und Ausgabeschemata bereit stehen, um die Gerätealarminformation von dem Prozesssteuersystem 36 an das Wartungsmanagementsystem 42 geeignet zu übertragen und/oder jede benötigte Datenabbildungsfunktion oder Handhabung durchzuführen. Hat das Wartungsmanagementsystem 42 die abgebildeten und/oder manipulierten Alarmdaten oder Information empfangen, führt das Wartungsmanagementsystem 42 geeignete Aktionen durch, beispielsweise erzeugen eines Arbeitsauftrags, Bestellen eines Austauschteils, Senden einer Page-Nachricht an einen Wartungstechniker, etc. In einer ähnlichen Weise kann jedes andere System in dem Unternehmen 10 (falls authentifiziert) ein Klient von einem oder mehreren der Webdienste werden, die von dem Webdienste-Block 406 bereitgestellt werden, und kann Alarm- und Ereignisinformation, Prozesszustandsinformation und Ausrüstungszustandsinformation an und von dem Prozesssteuersystem 36 über den Webdienste-Schnittstellenblock 408 kommunizieren.
Es sollte erkannt werden, dass das von der Webdienste-Schnittstelle 408 und dem Webdienste-Block 406 bereit gestellte Webdienste-Gerüst oder Architektur jedem authentifizierten Klienten in dem Unternehmen 10 ermöglicht, Informationen oder Daten mit dem Prozesssteuersystem 36 unter Verwendung von XML-basierter Kommunikation auszutauschen, die in HTTP-Paketen eingekapselt sind. Deshalb kann jeder Klient, der eine Internetbrowseranwendung ausführen kann mit dem Prozesssteuersystem 36 über die Webdienste-Schnittstelle 408 und den Webdienste-Block 406 kommunizieren. Beispielsweise kann ein entferntes Terminal oder ein tragbarer Computer, die dazu ausgebildet sind, eine Browseranwendung auszuführen, mit dem Prozesssteuersystem 36 über das Internet 28 oder jede andere übliche oder geeignete Kommunikationsverbindung kommunizieren. Alternativ können solche entfernten Terminals, tragbaren Geräte, etc. statt dessen dazu ausgebildet sein, die Ausführung eines Browsers in dem Webdienste-Schnittstellenblock 408 aufzurufen. Auf jeden Fall benötigt, da der Webdienste-Schnittstellenblock 408 und der Webdienstblock 406 unter Verwendung von bekannten Web-basierten Protokollen und Datenformaten kommunizieren, das Etablieren von Kommunikationsverbindung zwischen dem Prozesssteuersystem 36 und anderen Einrichtungen kommender Systeme, Komponenten, etc. des Unternehmens 10 keine Entwicklung von mehreren Kundenkommunikations-Schnittstellen, wie es der Fall bei üblichen System ist.
Obwohl die Transaktions-Datenkommunikationstechnik unter Verwendung eines XML-basierten Server implementiert und beschrieben wurde, kann sie unter Verwendung jeder anderen geeigneten Transaktions-Datensprache auf jeder geeigneten Hardwareplattform implementiert sein. Obwohl die Transaktions- Datenkommunikationstechnik hierin vorzugsweise als Software implementiert beschrieben wurde, kann sie in Hardware, Firmware, etc. implementiert sein. Deshalb kann die hierin beschriebene Transaktions-Datenkommunikationstechnik in einem Standard-Vielzweck-Prozessor oder unter Verwendung spezifischer ausgebildeter Hardware oder Firmware, je nach Wunsch, implementiert sein. Wenn in Software implementiert, können die Softwareroutinen in jedem computerlesbaren Speicher, beispielsweise auf einer Magnetscheibe, einer Laserscheibe oder jedem anderen Speichermedium in einem RAM oder ROM eines Computerprozessors, etc. gespeichert werden. Jedenfalls kann die Software an einen Anwender oder ein Prozesssteuersystem über jedes bekannte oder gewünschte Lieferverfahren geliefert werden, einschließlich beispielsweise auf einer computerlesbaren Diskette oder jedem anderen Computerspeichermechanismus oder über einen Kommunikationskanal wie eine Telefonleitung, das Internet, etc. (die als das gleiche oder austauschbar zum Bereitstellen von Software über einem transportablen Speichermedium betrachtet werden.
Obwohl die vorliegende Erfindung im Bezug auf spezielle Beispiele beschrieben wurde, die nur der Erläuterung dienten, und nicht der Einschränkung der Erfindung, ist es dennoch für Fachleute offensichtlich, dass Änderungen, Zusätze oder Weglassungen an den offenbarten Ausführungsformen ohne Verlassen des Rahmens und des Umfanges der Erfindung vorgenommen werden können.

Claims

1. Verfahren zur Kommunikation von Information in einem Unternehmen mit einem Prozesssteuersystem und einer Mehrzahl von Informationstechnologiesystemen, das folgendes umfasst:
Erzeugen von Transaktions-Prozesssteuerinformation;
Formatieren der Transaktions-Prozesssteuerinformation auf Basis eines ersten Schemas einer erweiterbaren Markup-Sprache, um formatierte Transaktions- Prozesssteuerinformationen zu bilden;
Senden der formatierten Transaktions-Prozesssteuerinformation an einen Transaktions-Informationsserver über eine Webdienste-Schnittstelle;
Abbilden der formatierten Transaktions-Prozesssteuerinformation auf ein zweites Schema der erweiterbaren Markup-Sprache, das einem aus der Vielzahl der Informationstechnologiesysteme zugeordnet ist, um abgebildete Prozesssteuerinformationen zu bilden; und
Senden der abgebildeten Transaktions-Prozesssteuerinformation an ein erstes der Mehrzahl der Informationstechnologiesysteme.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Erzeugens der Transaktions-Prozesssteuerinformation den Schritt des Erzeugens einer Information aus der Gruppe Gerätealarminformation, Prozesszustandsinformation und Ausrüstungszustandsinformation aufweist.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Formatierens der Transaktions-Prozesssteuerinformation auf Basis des ersten erweiterbaren Markup-Sprach-Schemas, um formatierte Transaktionsprozesssteuerdaten zu bilden, den Schritt des Verwendens eines XML-Eingabeschemas aufweist, um die formatierte Transaktions- Prozesssteuerinformation zu bilden.

4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Sendens der formatierten Transaktions-Prozesssteuerinformation an den Transaktions-Informationsserver über eine Webdienste-Schnittstelle weiterhin den Schritt des Sendens der formatierten Transaktions- Prozesssteuerinformation über eine Verbindung aus der Gruppe lokales Netz, drahtlose Kommunikationsverbindung und Internet aufweist.

5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Zuordnens der formatierten Transaktions- Prozesssteuerinformation zu dem zweiten erweiterbaren Markup-Sprach- Schema, das einem aus der Vielzahl der Informationstechnologiesysteme zugeordnet ist, um abgebildete Transaktionssteuerinformation zu bilden, den Schritt des Abbildens der formatierten Transaktions-Prozesssteuerinformation auf ein XML-Ausgabeschema aufweist, das einer Anwendung zugeordnet ist, die in dem ersten aus der Vielzahl der Informationstechnologiesysteme ausgeführt wird.

6. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Abbildens der formatierten Transaktions- Prozesssteuerinformation an das zweite erweiterbare Markup-Sprach-Schema, das dem ersten aus der Vielzahl der Informationstechnologiesysteme zugeordnet ist, um abgebildete Transaktions-Prozesssteuerinformation zu bilden, den Schritt der Verwendung einer Datenhandhabungsfunktion aufweist, um ein erstes Attribut, das mit dem ersten erweiterbaren Markup-Sprach- Schema verknüpft ist, einem zweiten Attribut zuzuordnen, das mit einem zweiten erweiterbaren Markup-Sprach-Schema verknüpft ist, wobei das erste und zweite Attribut unterschiedlich sind.

7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Sendens der abgebildeten Transaktions-Prozesssteuerinformation an das erste aus der Mehrzahl der Informationstechnologiesysteme den Schritt des Sendens der abgebildeten Transaktions-Prozesssteuerinformation über eine Verbindung aus der Gruppe lokales Netz, drahtlose Kommunikationsverbindung und Internets aufweist.

8. Verfahren nach Anspruch 1, welches ferner den Schritt des Bestimmens in dem Transaktions- Informationsserver aufweist, ob die formatierte Transaktions- Prozesssteuerinformation mit einem gültigen Eingabeschema verknüpft ist.

9. Verfahren nach Anspruch 1, welches ferner den Schritt des Verwendens einer Geschäftsregel umfasst, um die abgebildete Transaktions-Prozesssteuerinformation an ein zweites aus der Mehrzahl der Informationstechnologiesysteme zu senden.

10. System zur Verwendung in einem Unternehmen mit einer Vielzahl von Informationstechnologiesystemen, das folgendes umfasst:
ein Prozesssteuersystem, das ausgebildet ist, um Transaktions- Prozesssteuerinformation auf Basis einer erweiterbaren Markup-Sprache und einer Mehrzahl von Eingabeschemata zu formatieren, wobei jedes aus der Mehrzahl der Eingabeschemata einer Art von Transaktions- Prozesssteuerinformation zugeordnet ist;
eine Webdienste-Schnittstelle, die kommunikativ mit dem Prozesssteuersystem gekoppelt ist; und
einen Transaktions-Datenserver, der kommunikativ mit der Webdienste- Schnittstelle und der Mehrzahl der Informationstechnologiesysteme gekoppelt ist, wobei der Transaktions-Datenserver dazu ausgebildet ist, Transaktions- Prozesssteuerinformation abzubilden, die auf Basis der erweiterbaren Markup- Sprache und der Mehrzahl von Eingabeschemata einer Mehrzahl von Ausgabeschemata formatiert ist, wobei jedes aus der Mehrzahl der Ausgabeschemata einer Anwendung zugeordnet ist, die in einem aus der Mehrzahl der Informationstechnologiesysteme ausgeführt wird, und wobei der Transaktions-Datenserver ferner dazu ausgebildet ist, abgebildete Transaktions- Prozesssteuerinformation an eines aus der Mehrzahl der Informationstechnologiesysteme zu senden.

11. System nach Anspruch 10, dadurch gekennzeichnet, dass das Prozesssteuersystem dazu ausgebildet ist, die Transaktions- Prozesssteuerinformation unter Verwendung von XML zu formatieren.

12. System nach Anspruch 10, dadurch gekennzeichnet, dass die Mehrzahl der Eingabeschemata ein Eingabeschema aufweist, das einer Bedingung aus der Gruppe Gerätealarm, Ausrüstungszustand und Prozesszustand zugeordnet ist.

13. System nach Anspruch 10, dadurch gekennzeichnet, dass die Vielzahl der Informationstechnologiesysteme über ein Kommunikationsnetz kommunikativ gekoppelt sind, das eine Verbindung aus der Gruppe lokales Netz und Internet aufweist.

14. System nach Anspruch 10, dadurch gekennzeichnet, dass der Transaktions-Datenserver ferner dazu ausgebildet ist, eine Datenhandhabungsfunktion zu verwenden, um ein erstes Attribut eines bestimmten Eingabeschemas auf ein zweites Attribut eines bestimmten Ausgabeschemas abzubilden, wobei das erste und das zweite Attribut unterschiedlich sind.

15. System nach Anspruch 10, dadurch gekennzeichnet, dass der Transaktions-Datenserver ferner dazu ausgebildet ist, eine Geschäftsregel zu verwenden, um die zugeordnete Transaktions-Prozesssteuerinformation an eines aus der Mehrzahl der Informationstechnologiesysteme zu senden.

16. System nach Anspruch 10, dadurch gekennzeichnet, dass der Transaktions-Datenserver ferner dazu ausgebildet ist, zu bestimmen, ob die Transaktions-Prozesssteuerinformation mit einem gültigen Eingabeschema verknüpft ist.

17. Verfahren zur Verarbeitung von Transaktions-Prozesssteuerdaten, das folgende Schritte umfasst:
Einhüllen der Transaktions-Prozesssteuerdaten in eine XML-Hülle, um eingehüllte XML-Transaktions-Prozesssteuerdaten zu bilden;
Senden der eingehüllten XML-Transaktions-Prozesssteuerdaten über eine Webdienste-Schnittstelle und ein Kommunikationsnetz an einen XML- Datenserver;
Abbilden der eingehüllten XML-Transaktions-Prozesssteuerdaten auf ein XML- Ausgabeschema, das einem aus der Mehrzahl der Informationssysteme zugeordnet ist, die kommunikativ mit dem Kommunikationsnetz gekoppelt sind, um abgebildete XML-Transaktions-Prozesssteuerdaten zu bilden; und
Senden der abgebildeten XML-Transaktions-Prozesssteuerdaten an eines aus der Mehrzahl der Informationssysteme über das Kommunikationsnetz.

18. Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass der Schritt des Einhüllens der Transaktions-Prozesssteuerdaten in die XML- Hülle, um eingehüllte XML-Transaktions-Prozesssteuerdaten zu bilden, den Schritt des Einhüllens von Transaktions-Prozesssteuerdaten aufweist, die Information enthalten, die einer Bedingung aus der Gruppe Gerätealarm, Ausrüstungszustand und Prozesszustand zugeordnet sind.

19. Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass der Schritt des Abbildens der eingehüllten XML-Transaktions-Prozesssteuerdaten auf ein XML-Ausgabeschema, das einem aus der Mehrzahl der Informationssysteme zugeordnet ist, um abgebildete XML-Transaktions- Prozesssteuerdaten zu bilden, den Schritt der Verwendung einer Datenhandhabungsfunktion aufweist, um ein erstes Attribut, das mit einem XML-Eingabeschema verknüpft ist, auf ein zweites Attribut abzubilden, das mit einem XML-Ausgabeschema verknüpft ist, wobei das erste und das zweite Attribut unterschiedlich sind.

20. Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass der Schritt des Sendens der abgebildeten XML-Transaktions-Prozesssteuerdaten an eines aus der Mehrzahl der Informationssysteme über das Kommunikationsnetz den Schritt des Sendens der abgebildeten XML- Transaktions-Prozesssteuerdaten an eines aus der Mehrzahl der Informationssysteme über eine Verbindung aus der Gruppe Internet und lokales Netz aufweist.

21. Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass der Schritt des Sendens der abgebildeten XML-Transaktions-Prozesssteuerdaten an eines aus der Mehrzahl der Informationssysteme über das Kommunikationsnetz den Schritt des Sendens der abgebildeten XML- Transaktions-Prozesssteuerdaten an ein System aus der Gruppe Auftragsverarbeitungssystem, Buchhaltungssystem, Produktversendungs- und Verwaltungssystem, Produktlagerhaltungs-Steuersystem, Qualitätssicherungssystem, Wartungsmanagementsystem, Beschaffungssystem, Materialenergie- und Steuersystem, Produktionsplanungssystem, Zulieferersystem, Kundensystem und Prozesssteueranlage aufweist.

22. Verfahren zur Verarbeitung von Transaktions-Prozesssteuerdaten, das folgende Schritte umfasst:
Einhüllen der Transaktions-Prozesssteuerdaten in eine Markup-Sprach-Hülle, um eingehüllte Transaktions-Prozesssteuerdaten zu bilden;
Senden der eingehüllten Transaktions-Prozesssteuerdaten über eine Webdienste-Schnittstelle und ein Kommunikationsnetzwerk an einen Markup- Sprach-Datenserver;
Abbilden der eingehüllten Transaktions-Prozesssteuerdaten an ein Ausgabeschema, dass einem System aus der Gruppe Unternehmensbetriebsmittel-Planungssystem und Produktionsausführungssystem zugeordnet ist, um abgebildete Transaktions- Prozesssteuerdaten zu bilden; und
Senden der abgebildeten Transaktions-Prozesssteuerdaten an ein System aus der Gruppe Unternehmensbetriebsmittel-Planungssystem und Produktionsausführungssystem.

23. Verfahren nach Anspruch 22, dadurch gekennzeichnet, dass der Schritt des Einhüllens der Transaktions-Prozesssteuerdaten in die Markup- Sprach-Hülle, um eingekapselte Transaktions-Prozesssteuerdaten zu bilden, den Schritt des Verwendens von XML aufweist, um die Transaktions- Prozesssteuerdaten einzukapseln.

24. Verfahren nach Anspruch 23, dadurch gekennzeichnet, dass der Schritt des Sendens der eingehüllten Transaktions-Prozesssteuerdaten über die Webdienste-Schnittstelle und das Kommunikationsnetz an den Markup- Sprach-Datenserver den Schritt des Sendens der eingehüllten Prozesssteuerdaten über eine Verbindung aus der Gruppe lokales Netz und Internet aufweist.

25. Verfahren nach Anspruch 22, dadurch gekennzeichnet, dass der Schritt des Abbildens der eingehüllten Transaktions-Prozesssteuerdaten an ein Ausgabeschema, das einem System aus der Gruppe Unternehmensbetriebsmittel-Planungssystem und Produktionsausführungssystem zugeordnet ist, um abgebildete Transaktions- Prozesssteuerdaten zu bilden, den Schritt der Verwendung einer Datenhandhabungsfunktion aufweist, die ein erstes Attribut, das mit den eingehüllten Transaktionsprozesssteuerdaten verknüpft ist, auf ein zweites Attribut abbildet, das mit dem Ausgabeschema verknüpft ist, wobei das erste und das zweite Attribut unterschiedlich sind.

26. Verfahren nach Anspruch 22, dadurch gekennzeichnet, dass der Schritt des Sendens der abgebildeten Transaktions-Prozesssteuerdaten an ein System aus der Gruppe Unternehmensbetriebsmittelplanungssystem und Produktionsausführungssystem den Schritt des Sendens der abgebildeten Transaktions-Prozesssteuerdaten über eine Verbindung aus der Gruppe lokales Netz und Internet aufweist.

27. Verfahren zur Kommunikation von Transaktions-Prozesssteuerdaten in einem Unternehmen, wobei das Verfahren folgende Schritte aufweist:
Formatieren der Transaktions-Prozesssteuerdaten auf Basis eines ersten erweiterbaren Markup-Sprach-Schemas, um formatierte Transaktions- Prozesssteuerinformation zu bilden;
Senden der formatierten Transaktions-Prozesssteuerinformation an einen Transaktions-Informationsserver;
Abbilden der formatierten Transaktions-Prozesssteuerinformation auf ein zweites erweiterbares Markup-Schema, das einem Prozesssteuersystem zugeordnet ist, um abgebildete Prozesssteuerinformationen zu bilden; und
Senden der abgebildeten Transaktions-Prozesssteuerinformation an das Prozesssteuersystem über eine Webdienste-Schnittstelle.

28. Verfahren nach Anspruch 27, dadurch gekennzeichnet, dass der Schritt des Formatierens der Transaktions-Prozesssteuerinformation auf Basis des ersten erweiterbaren Markup-Sprach-Schemas, um formatierte Transaktionsinformation zu bilden, den Schritt des Verwendens eines XML- Eingabeschemas aufweist, um die Transaktions-Prozesssteuerinformation zu formatieren.

29. Verfahren nach Anspruch 27, dadurch gekennzeichnet, dass der Schritt des Abbildens der formatierten Transaktions- Prozesssteuerinformation auf ein zweites erweiterbares Markup-Schema, das dem Prozesssteuersystem zugeordnet ist, um abgebildete Transaktions- Prozesssteuerinformationen zu bilden, den Schritt des Abbildens der formatierten Transaktions-Prozesssteuerinformation auf ein XML- Ausgabeschema aufweist.

30. Verfahren nach Anspruch 27, dadurch gekennzeichnet, dass der Schritt des Sendens der abgebildeten Transaktions-Prozesssteuerinformation an das Prozesssteuersystem über eine Webdienste-Schnittstelle ferner den Schritt des Sendens der abgebildeten Transaktions-Prozesssteuerinformation an das Prozesssteuersystem über eine Verbindung aus der Gruppe lokales Netz und Internet aufweist.

31. Verfahren zur Verarbeitung eines Gerätealarmes zur Anwendung in einem Unternehmen, das ein Prozesssteuersystem und ein Wartungsmanagementsystem aufweist, wobei das Verfahren folgende Schritte umfasst:
Formatieren des Gerätealarmes auf Basis eines XML-Eingabeschemas, um einen XML-Gerätealarm zu bilden;
Senden des XML-Gerätealarmes an einen XML-Transaktionsserver;
Abbilden des XML-Gerätealarmes auf ein XML-Ausgabeschema, das dem Wartungsmanagementsystem zugeordnet ist, um einen abgebildeten XML- Gerätealarm zu bilden; und
Senden des abgebildeten XML-Gerätealarmes an das Wartungsmanagementsystem.

32. Verfahren zur Verarbeitung einer Ausrüstungszustandsinformation zur Anwendung in einem Unternehmen, das ein Prozesssteuersystem und ein Informationstechnologiesystem aufweist, wobei das Verfahren folgende Schritte umfasst:
Formatieren der Ausrüstungszustandsinformation auf Basis eines XML- Eingabeschemas, um eine XML-Nachricht zu bilden;
Abbilden der XML-Nachricht auf ein XML-Ausgabeschema, das dem Informationstechnologiesystem zugeordnet ist, um eine abgebildete XML- Nachricht zu bilden; und
Senden der abgebildeten XML-Nachricht an das Informationstechnologiesystem.

33. Verfahren zur Verarbeitung von Prozesszustandsinformation zur Anwendung in einem Unternehmen, das ein Prozesssteuersystem und ein Informationstechnologiesystem aufweist, wobei das Verfahren folgende Schritte umfasst:
Formatieren der Prozesszustandsinformation auf Basis eines XML- Eingabeschemas, um eine XML-Nachricht zu bilden;
Abbilden der XML-Nachricht auf ein XML-Ausgabeschema, das einem Informationstechnologiesystem zugeordnet ist, um eine abgebildete XML- Nachricht zu bilden; und
Senden der zugeordneten XML-Nachricht an das Informationstechnologiesystem.