DE10204434A1

DE10204434A1 - Hierarchisches Fehlermanagement für Prozesssteuersysteme

Info

Publication number: DE10204434A1
Application number: DE10204434A
Authority: DE
Inventors: Robert B Havekost; David L Deitz; Dennis L Stevenson; William Irwin; Michael G Ott
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2001-02-05
Filing date: 2002-02-04
Publication date: 2002-10-31
Anticipated expiration: 2022-02-05
Also published as: JP2014056575A; JP6009629B2; GB2374431B; HK1051413A1; JP2015215917A; US20020108077A1; JP4189527B2; JP5819368B2; JP2002312028A; DE10204434B4; JP2008243210A; GB0202626D0; JP2014002784A; GB2374431A; US6871299B2

Abstract

Es wird eine hierarchische Fehlermanagementtechnik offenbart, die eine integrierte Gerätehierarchie verwendet, um automatisch Fehlerinformation von Steuermodulen zu Moduleinheiten zu übermitteln. Jedes Steuermodul sammelt Fehlerinformation und erzeugt einen zusammengesetzten Fehlercode durch mathematische Verknüpfung der Fehlerinformation, die durch dieses Modul gesammelt wurde. Module, die aktuell von einer Phase der Moduleinheit benötigt werden, um einen Prozess auszuführen, senden automatisch entsprechende Fehlercodes an die Moduleinheit. Die Moduleinheit wählt den schlechtesten Fehlercode aus der Liste der Fehlercodes in der Moduleinheit aus und vergleicht den ausgewählten schlechtesten Fehlercode mit einem vorbestimmten Schwellwert, um zu bestimmen, ob der Prozess angehalten werden soll.

Description

Die Erfindung betrifft im Allgemeinen Prozesssteuersysteme und insbesondere eine Technik, die eine integrierte Geräte hierarchie verwendet, um automatisch Fehlerinformation in einem Prozesssteuersteuersystem zu managen bzw. zu verwal ten.

Prozesssteuersysteme, beispielsweise diese, die Stapelpro zesstechniken verwenden, um große Mengen von pharmazeuti schen Produkten, chemischen Produkten, Getränkeprodukten, Farbprodukten oder jedes andere Produkt herstellen, weisen im Allgemeinen ein oder mehrere zentralisierte Prozesssteue rungen auf, die kommunizierend mit einem oder mehreren Feldgeräten gekoppelt sind, die beispielsweise Ventilreg ler, Schalter, Sensoren (beispielsweise Temperatur-, Druck- und Durchflusssensoren) etc. sein können. Diese Feldgeräte, die mit Steuergeräten, beispielsweise Ventilen, Pumpen, Mischeinheiten etc., assoziiert sein können, können physi kalische Steuerfunktionen (beispielsweise Öffnen oder Schließen eines Ventils, An- und Ausschalten einer Pumpe oder einer Mischeinheit, etc.) in einem Prozesssteuersystem durchführen, sie können Messungen in dem Prozesssteuersys tem zur Verwendung bei der Steuerung des Prozessbetriebes durchführen oder sie können jede andere gewünschte Funktion in dem Prozesssteuersystem ausführen. Allgemein gesagt er halten die Prozessteuerungen Messungen anzeigende Signale, die durch ein oder mehrere Feldgeräte gemacht wurden, und/oder andere die Feldgeräte betreffende Informationen und verwenden diese Informationen, um eine Steuerroutine zu implementieren und Steuersignale zu erzeugen, die über Sig nalleitungen oder Busse an die Feldgeräte gesendet werden, um den Betrieb des Prozesssteuersystems zu steuern.

Weiterhin sind die Prozesssteuerungen im Allgemeinen über eine Datenautobahn, beispielsweise einen Ethernet-Bus, mit einer oder mehreren Workstations und anderen Vorrichtungen gekoppelt. Auf den anderen Vorrichtungen laufen andere Ap plikationen oder Programme, die die Information verwenden, die von der einen oder von mehreren Steuerungen geliefert werden, um andere Prozesssteuerungen bereitzustellen, bei spielsweise Bereitstellen einer Benutzerschnittstelle zu der Steuerroutine, Ermöglichen einer Modifikation oder ei nes Updates der Steuerroutine, Anschließen von Feldgeräten über Schnittstellen, Speichern historischer Prozesssteuer daten, Steuern oder Einschränken des Benutzerzugriffs etc. In einigen großen Prozesssteuersystemen können eine oder mehrere Workstations, die an einem entfernten Ort angeord net sind, mit einer Datenautobahn mittels einem weiteren Kommunikationsnetzwerk gekoppelt sein, beispielsweise einer Internetverbindung, einer Satelliten- oder Mobilfunkverbin dung, einer Funkverbindung (wie sie in drahtlosen Ethernet- Verbindungen verwendet wird) etc.

Prozesssteuersysteme weisen üblicherweise eine Fehlerüber wachungslogik auf, die Prozesssteuerfehler und Vor richtungs- oder Gerätefehler (beispielweise einen defekten Sensor, ein blockiertes Ventil, etc.) dem Systembetreiber berichtet. In einigen Prozesssteuersystemen können Prozess steuerfehler, Gerätefehler oder jede andere Fehlerinforma tion beispielsweise dem Betreiber mittels einer graphischen Nutzerschnittstelle angezeigt werden. In diesen Prozess steuersystemen kann der Systembetreiber eine Abbildung in der graphischen Nutzerschnittstelle sehen, die anzeigt, dass eine technische Vorrichtung ausgefallen ist oder dass einige Prozessvariablen aus einem akzeptablen Betriebsbe reich heraus abweichen. Als Antwort auf diese angezeigten Fehler kann der Systembetreiber wählen, einzugreifen, um den Prozess vor einer Fortsetzung anzuhalten, und er kann weitere Schritte unternehmen, um den Fehler zu untersuchen, sodass eine geeignete, korrigierende Aktion durchgeführt werden kann. Im Fall eines Prozesssteuersystems, dass einen Stapelprozess ausführt, kann es notwendig sein, den Prozess anzuhalten, um das System an einer Produktion eines gering wertigen und/oder eines gefährlichen Produktstapels zu hin dern.

In einigen anderen Prozesssteuersystemen kann ein komplexe res Fehlermanagementschema verwendet werden, um eine manu elle Überwachung und das Eingreifen durch den Systembetrei ber- oder Nutzer zu ergänzen oder zu ersetzen. Beispiels weise in einem Prozesssteuersystem, das pharmazeutische Produkte herstellt, können die Sensoren, Stellglieder und andere Vorrichtungen, die im ganzen System verteilt sind, kontinuierlich überwacht werden und, wenn einer der Senso ren oder der zugeordneten Steuerparameter außerhalb eines akzeptablen Betriebsbereiches fällt, kann das Prozesssteu ersystem den Prozess automatisch anhalten. Als Antwort auf einen automatischen Stopp des Prozesses kann der System betreiber Schritte zur Untersuchung des Fehlers vornehmen und, wenn der Fehler nicht kritisch ist oder nicht in ande rer Weise die Produktion eines akzeptablen Endproduktes be einträchtigt, der Betreiber kann auf das System einwirken, damit die Ausführung des Prozesses fortgesetzt wird. Alter nativ kann der Betreiber, wenn der Betreiber bestimmt, dass der Fehler eine Reparatur, eine Eichung oder eine andere korrigierende Aktion benötigt, das Losschicken eines Feld technikers oder einer Wartungsperson anfordern, um dem Feh ler abzuhelfen, bevor die Ausführung des Stapelprozesses fortgesetzt wird.

Auf Grund einer großen Anzahl von Eingaben, Ausgaben, Pro zesssteuervariablen etc., die üblicherweise durch ein Pro zesssteuersystem verwendet werden, ist die Software, die den Betrieb eines Prozesssteuersystems steuert, üblicher weise unter Verwendung von Softwareobjekten implementiert, die üblicherweise unter Verwendung bekannter objektorien tierter Programmiertechniken erzeugt wurden. Diese Soft wareobjekte können unter Verwendung eines hierarchischen Modells des Prozesssteuersystems entwickelt werden, das die Erzeugung eines höher komplexen Prozesssteuerroutine oder Rhythmus vereinfacht, durch das Prozesssteuersystem ausge führt wird. Beispielsweise verwendet ein übliches hierar chisches Modell Moduleinheiten und Steuermodule. Eine Mo duleinheit oder Einheit stellt üblicherweise ein Teilstück eines physikalischen Gerätes in einem Prozesssteuersystem dar. Beispielsweise ein Mischkessel mit einer Vielfalt von Einlassventilen, Auslassventilen, Niveausensoren bzw. Füll standsensoren, Mischern, etc. die die Ausführung verschie dener Aktionen in dem Tank ermöglichen. Im Gegensatz dazu stellt ein Steuermodul üblicherweise eine Steuersoftware (d. h. Subroutinen, Objekte etc.) dar, die installiert sein können, um Regel- und Steuerfunktionen der unteren Ebene oder von einer oder mehreren Einheiten geleitete Aktionen auszuführen.

Obwohl das vorstehende hierarchische Modell für ein Pro zesssteuersystem die Entwicklung eines komplexen Prozess steueralgorithmus erleichtern kann, stellt dies übliche hierarchische Modell unglücklicherweise keine Laufzeitkom munikationsbeziehung zwischen Moduleinheiten und Steuermo dulen her. Daraus folgt, dass eine Moduleinheit üblicher weise nicht weiß, welche Steuermodule dieser Moduleinheit untergeordnet sind. Weiterhin liefert dies übliche hierar chische Modell keinen Mechanismus zum automatischen Aus breiten von Fehlerinformation (d. h. Ausstattungsfehler, Gerätefehler, Steuerparameterfehler etc.) von untergeordne ten Steuermodulen zu übergeordneten Moduleinheiten. Weiter hin liefert dies übliche hierarchische Modell keinen Mecha nismus, durch den Moduleinheiten ein Interesse registrieren oder im Gegensatz dazu spezifische Typen von Fehlerinforma tion von einem oder mehreren Steuermodulen zu bestimmten Zeiten ignorieren (beispielsweise wenn diese Steuermodule nicht benötigt werden, um den Teil des Prozesssteueralgo rithmus, der geradeaus geführt wird, auszuführen).

Das Fehlen der Laufzeitkommunikationsbeziehung zwischen Mo duleinheiten und Steuermodulen, das im Prozesssteuersystem auf Grundlage des vorstehenden gewöhnlichen hierarchischen Modells gefunden wird, zwingt die Systementwickler dazu, relativ komplexe Fehlermanagementroutinen mit ausführenden Funktionen der höheren Ebene oder Einheitenebene-Funktionen zu verwenden, die Zugriff auf die im Prozesssteuersystem verteilte Fehlerinformation haben. Üblicherweise befinden sich diese komplexen Fehlermanagementroutinen in einer Sta pelausführungsfunktion oder einer Einheitenprozedur und verwalten direkt eine enorme Menge von Fehlerinformation, die von hunderten von Vorrichtungen geliefert werden, die üblicherweise in einem Prozesssteuersystem verteilt sind.

Da darüber hinaus übliche Prozesssteuersysteme nicht ermög lichen, dass Fehlerinformation automatisch von den Steuer modulen zu Moduleinheiten übermittelt wird, überwachen üb liche Fehlermanagementtechniken kontinuierlich hunderte von Vorrichtungen, die im Prozesssteuersystem verteilt sind, unabhängig ob eine überwachte Vorrichtung zu einer bestimm ten Zeit, oder zu irgendeiner Zeit von dem Prozesssteueral gorithmus, der ausgeführt wird, benötigt wird oder nicht. Beispielsweise kann ein Prozesssteuersystem, das pharmazeu tische Produkte herstellt, eine große Anzahl von Vorrich tungen aufweisen, beispielsweise Sensoren, Stellglieder, die in verschiedener Kombination verwendet werden können, um eine Anzahl von verschiedenen pharmazeutischen Produkten herzustellen. Für jedes bestimmtes pharmazeutisches Pro dukt, das unter Verwendung eines bestimmten Stapelprozesses hergestellt werden kann, kann jedoch nur eine Teilmenge al ler verfügbaren Vorrichtungen benötigt sein (das heißt ei nige Vorrichtungen brauchen überhaupt nicht benutzt wer den). Auf jeden Fall erzeugt die kontinuierliche Überwa chung aller im Prozesssteuersystem verteilten Vorrichtungen eine enorme Menge von Fehlerinformation. Daraus folgt, dass die Entwicklung von Fehlermanagementlogik, die die enorme Menge von Fehlerinformation verarbeitet und die automatisch auf Grundlage einer oder mehrerer Fehlerbedingungen Aktio nen durchführen kann (beispielsweise einen Stapelprozess anhalten und Benachrichtigen des Systembetreibers von den Fehlern), sehr komplex und zeitaufwendig wird, um in ein Prozesssteuersystem mit einem moderaten Komplexität imple mentiert zu werden.

Zusätzlich antworten übliche Fehlermanagementtechniken auf Fehlerinformation, die anzeigt, dass ein Fehler auftrat, durch Anhalten des Prozesses und Warten auf den System betreiber, um geeignete, korrigierende Aktionen durchzufüh ren, unabhängig von der Natur oder Bewertung des Fehlers. Üblicherweise wird der Stapelprozess wieder aufgenommen, wenn der Systemoperator anzeigt, dass die zum Fehler füh renden Bedingungen behoben sind, und dem System bestätigt, den Betrieb wieder aufzunehmen.

Deshalb können übliche Fehlermanagementtechniken zu einem unnötigen Stopp des Prozesses führen, da Fehler, die mit Vorrichtungen assoziiert sind, die aktuell nicht benötigt werden oder die insgesamt durch den Prozess nicht benötigt werden, ein Anhalten verursachen können. Zusätzlich können unnötige Stopps resultieren, wenn eine oder mehrere Vor richtungen, die von dem Prozess verwendet werden, der aus geführt wird, eine Fehlerbedingung hervorbringen, die nicht kritisch für oder die keinen ungünstigen Einfluss auf das Ergebnis des Prozesses hat. Beispielsweise kann der Fehler von einem oder einem Paar von redundanten Sensoren zu einem unnötigen Anhalten des Prozesssteuersystems führen.

Eine hierarchische Fehlermanagementtechnik stellt Laufzeit kommunikationsbeziehungen zwischen Moduleinheiten und Steu ermodulen in einem Prozesssteuersystem her, sodass Fehler information automatisch von den Steuermodulen zu den Modul einheiten während der Ausführung des Prozesses übermittelt werden kann. Genauer, die hierin beschriebene hierarchische Fehlermanagementtechnik verwendet die Laufzeitkommunikati onsbeziehungen zwischen Moduleinheiten und Steuermodulen, um einer Moduleinheit zu ermöglichen, Interesse zu regis trieren und automatisch Fehlerinformation von den Steuermo dulen zu empfangen und zu verarbeiten, die von der Modul einheit benötigt werden, eine laufende Phase oder einen Schritt eines Prozesssteueralgorithmus auszuführen, und die Fehlinformation zu ignorieren, die mit Steuermodulen asso ziiert ist, die von der Moduleinheit aktuell nicht benötigt werden, eine Phase oder einen Schritt auszuführen.

Zusätzlich verwendet die hierin beschriebene hierarchische Fehlermanagementtechnik Steuermodule, die Fehlerinformation sammeln und daraus zusammengesetzte Fehlercodes erzeugen. Jeder dieser zusammengesetzten Fehlercodes kann beispiels weise eine gewichtete Summe der Betriebszustände oder Feh ler der verschiedenen Sensoren, Steuerschleifen, Geräte etc. darstellen, die von einem Steuermodul verwendet wer den, um seine Funktion auszuführen. Diese zusammengesetzten Fehlercodes können in Art und die Bewertung der Fehler in dem Steuermodul und/oder in den Vorrichtungen anzeigen, die von dem Steuermodul verwendet werden, um seine Funktion auszuführen. Jedes Steuermodul kann seinen zusammengesetz ten Fehlercode an eine Moduleinheit senden, die aktuelle Fehlerinformation von dem Steuermodul anfordert um dadurch der Moduleinheit zu ermöglichen, schnell zusammengesetzte Fehlercodes zu verarbeiten, um zu bestimmen, ob der Prozess fortgesetzt werden kann oder nicht, ob irgendeine Feldin spektion/Reparatur benötigt wird oder nicht, etc. Auf diese Weise vermeidet oder reduziert die hierin beschriebene hie rarchische Fehlermanagementtechnik den Bedarf an Modulein heiten oder Ausführungsfunktion der höheren Ebene in einem Prozesssteuersystem (beispielsweise eine Stapelausführung), um direkt und kontinuierlich Fehlerinformation von allen Vorrichtungen, Geräten etc. zu überwachen, die im Prozess steuersystem verteilt sind, wie es der Fall in früheren Fehlermanagementtechniken war. Stattdessen übermittelt die hierin beschriebene hierarchische Fehlermanagementtechnik automatisch eine relativ kleine Menge von zusammengesetzter Fehlerinformation von den Steuermodulen zu den Moduleinhei ten zu Zeiten, wenn die Fehlerinformation von den Modulein heiten benötigt wird. Die Moduleinheiten können dann bestimmen, auf Grundlage des Typs und der gesammelten Be wertung der Fehler, die Steuermodule beeinflussen, die be nötigt werden, und im Prozess wie von den beiden Modulein heiten geleitet auszuführen, ob eine Phase oder ein Schritt in einer Phase fortgesetzt werden kann, um dadurch unnöti ges Anhalten des Prozesses zu minimieren oder zu vermeiden.

Gemäß einem Effekt der Erfindung sammelt ein System und ein Verfahren in einem Prozesssteuersystem Fehlerinformation in jedem von mehreren Steuermodulen und erzeugt einen zusam mengesetzten Fehlercode in jedem der Steuermodule auf Grundlage der Fehlerinformation, die von dem Steuermodul gesammelt wurde. Zusätzlich senden das System und Verfahren automatisch eine Gruppe von zusammengesetzten Fehlercodes zu einer Moduleinheit und bestimmen, ob ein Prozess auf Grundlage der Gruppe der zusammengesetzten Fehlercodes an gehalten werden soll.

In Übereinstimmung mit einem anderen Aspekt der Erfindung sammelt ein Verfahren zum Fehlermanagement in einem Pro zesssteuersystem Fehlerinformation in einem Steuermodul und erzeugt einen zusammengesetzten Fehlercode in dem Steuermo dul auf Grundlage der Fehlerinformation, die von dem Steu ermodul gesammelt wurde. Zusätzlich sendet das Verfahren automatisch den zusammengesetzten Fehlercode zu einer Mo duleinheit und bestimmt, ob ein Prozess auf Grundlage des zusammengesetzten Fehlercodes angehalten werden soll.

In Übereinstimmung mit einem weiteren Aspekt der Erfindung weist eine Vorrichtung, die Fehler in einem Prozesssteuer system verwaltet, eine Steuerung mit einem Speicher und ei nem Prozessor auf, der kommunizierend mit dem Speicher ge koppelt ist. Die Steuerung ist dazu programmiert, zusammen gesetzte Fehlercodes zur Bestimmung zu verwenden, ob ein Prozess angehalten werden soll.

Fig. 1 ist ein schematisches Blockdiagramm eines Prozess steuersystems, das eine hierarchische Fehlermanagementtech nik verwendet, während ein Stapelprozess ausgeführt wird;

Fig. 2 ist ein Blockdiagramm eines hierarchischen Geräte modells, das zur Entwicklung eines komplexen Prozesssteuer algorithmus zur Ausführung durch ein in Fig. 1 gezeigtes Prozesssteuersystem verwendet werden kann;

Fig. 3 ist ein Blockdiagramm, das verschiedene Aktionsebe nen in einem komplexen Steueralgorithmus darstellt;

Fig. 4 ist ein beispielhaftes, schematisches Blockdia gramm, das die Laufzeit Kommunikationsbeziehungen zwischen Moduleinheiten, Steuermodulen, Phasen und Schritten in dem in Fig. 1 gezeigten Steuersystem illustriert;

Fig. 5 ist ein beispielhaftes Blockdiagramm, das eine Art und Weise illustriert, in der zusammengesetzte Fehlercodes automatisch von einem Steuermodul zu einer Moduleinheit durchlaufen;

Fig. 6 ist eine beispielhafte, graphische Abbildung der Art und Weise, in der eine zusammengesetzte Fehlercodeliste in einer Moduleinheit sich über die Zeit ändert;

Fig. 7 ist ein beispielhaftes Flussdiagramm, das eine Art und Weise abbildet, in der eine Moduleinheit eine Liste zu sammengesetzter Fehlercodes zur Bestimmung verarbeitet, ob ein Prozess fortgesetzt wird.

Obwohl hierin eine hierarchische Fehlermanagementtechnik in Verbindung mit einem Prozesssteuersystem beschrieben wird, das Stapelprozesse ausführt, kann die hierin beschriebene hierarchische Fehlermanagementtechnik vorteilhaft in einer Vielfalt von Prozesssteuersystemen verwendet werden, bei spielsweise einschließlich Prozesssteuersystemen, die im wesentlichen kontinuierliche Prozesse ausführen, beispiels weise Heizung und Belüftung, Gebäudesicherheit, Abwasser reinigung, Stromerzeugung etc.

Bevor die hierarchische Fehlermanagementtechnik im größeren Detail diskutiert wird, ist es wichtig, zu erkennen, dass übliche Fehlermanagementtechniken üblicherweise keinen Laufzeit- bzw. Runtime-Mechanismus einschließen, durch den Moduleinheiten automatisch Fehlerinformation von unterge ordneten Steuermodulen erhalten. Weiterhin bearbeiten diese üblichen Fehlermanagementtechniken normalerweise keine Feh lerinformation in irgendeiner Weise, bevor die Fehlerinfor mation von den Steuermodulen zu den Moduleinheiten gesendet wurde. Stattdessen benötigen diese üblichen Techniken einen Prozesssteuersystementwickler oder -anwender, um eine rela tiv komplexe Fehlermanagementroutine zu erzeugen, deren Herstellung schwierig und zeitaufwendig ist und die separat auf einer Workstation oder einer Steuerung instanziiert bzw. installiert werden muss. Normalerweise arbeiten die üblichen Fehlermanagementtechniken Fehlerinformation ab, die mit Steueraktivitäten und Vorrichtungen assoziiert sind, die durch das Prozesssteuersystem auf einer kontinu ierlichen Basis durchgehend angeordnet sind. In der Tat wird mit diesen üblichen Techniken Fehlerinformation übli cherweise abgearbeitet und das System wird normalerweise unabhängig davon angehalten, ob die Vorrichtungen, die mit der Fehlerinformation assoziiert sind, gerade von dem Pro zesssteuersystem benötigt werden oder nicht, um den Prozess durchzuführen, und unabhängig von der Natur oder Bewertung der zu Grunde liegenden Fehler. Deshalb können die üblichen Fehlermanagementtechniken ein unnötiges Anhalten eines Pro zesses als Reaktion auf Fehler eines Gerätes (beispielswei se ein Sensor) bewirken, der zum Vollenden des Prozesses nicht benötigt wird, oder als Reaktion auf einen Fehler mi nimaler Bewertung (beispielsweise ein fehlerhafter redun danter Sensor), der keine Auswirkung auf das Ergebnis des Prozesses hat.

Fig. 1 ist ein beispielhaftes, schematisches Blockdiagramm eines Prozesssteuersystems 10, das eine hierarchische Feh lermanagementtechnik verwendet, um automatisch zusammenge setzte Fehlercodes von Steuermodulen zu Moduleinheiten zu senden. Lediglich als Beispiel ist das Prozesssteuersystem 10 dazu ausgebildet, Stapelprozesse auszuführen und insbe sondere Stapelprozesse, die Farbladungen produzieren. Es ist jedoch klar, dass die hierin beschriebene Fehlermanage menttechnik in jeder anderen Stapelverarbeitungsapplikation und allgemein in jedem anderen Prozesssteuersystem verwen det werden kann, das jeden anderen Stapelprozess oder jeden kontinuierlichen Prozess ausführt.

Das Prozesssteuersystem 10 weist Workstations 12 und 14 und einen Server 16 auf, die kommunizierend über einen System ebenen-Datenbus 18 gekoppelt sind, der ein Ethernet- Datenbus oder jeder andere zur Datenübertragung geeignete Datenbus sein kann. Die Workstations 12 und 14 können auf einer Personal-Computer-Plattform oder jeder anderen geeig neten Prozessplattform angeordnet sein, und können eine Vielfalt von bekannten Prozesssteuerfunktionen durchführen. Beispielsweise kann die Workstation 12 eine Routine 20 auf weisen, die in einem Speicher 21 gespeichert ist und durch einen Prozessor 22 ausgeführt wird, die Sicherheitsfunktio nen durchführt, die den Anwenderzugang auf andere Funktio nen und Information in dem Prozesssteuersystem 10 steuern. In ähnlicher Weise kann die Workstation 14 Routinen 23 und 24 aufweisen, die in einem Speicher 25 gespeichert sind und die von einem Prozessor 26 ausgeführt werden, um Funktionen zur Datenhistorie und Stapelausführung bereitzustellen. Stapelausführungsfunktionen, beispielsweise die Stapelaus führungsfunktion, die durch die Workstation 14 durchgeführt wird, ermöglichen einem Prozesssteuersystem, komplexe Se quenzen von Steueraktionen auszuführen, um Stapel- bzw. La dungen von einer oder mehreren Arten von Produkten herzu stellen. Beispielsweise ermöglicht die von der Workstation 14 durchgeführte Stapelausführungsfunktion einem System betreiber, einen Stapelprozess zu erzeugen und zu instal lieren, der eine oder mehrere Ladungen von Farbe in dem Prozesssteuersystem 10 herstellt.

Allgemein gesagt, stellt das Prozesssteuersystem 10 Runtime Beziehungen zwischen Moduleinheiten und Steuermodulen her, die aus der Ausführung einer vorbestimmten Sequenz von Er eignissen oder Aktionen in dem Prozesssteuersystem 10 re sultieren. Insbesondere können, wie nachfolgend im größeren Detail diskutiert wird, Informationen oder Routinen von Mo duleinheiten und Steuermodulen zu einer oder mehreren Steu erungen und/oder Feldgeräten herunter geladen werden, die durchgehend in dem Prozesssteuersystem 10 verteilt sind. Ein Teil oder alle der herunter geladenen Information in der Richtung der Stapelausführung kann in der geeigneten Sequenz zur geeigneten Zeit installiert werden, um die ge wünschten Stapelprozessaktionen durchzuführen. Weiter kön nen, wie ebenfalls nachstehend im größeren Detail disku tiert wird, die Stapelausführungsfunktionen eine Fehlerma nagementlogik in den Moduleinheiten aufweisen oder diesen ausgesetzt sein, die auf Grundlage des Zustandes von einem oder mehreren Feldgeräten, Steuerparametern etc. in dem Prozesssteuersystem 10 bestimmt, ob die stapelausführenden Aktivitäten angehalten werden sollen.

Der Server 16 kann eine Workstation mit einem Prozessor 27 sein, der eine oder mehrere Softwareroutinen 28 ausführt, die in einem Speicher 30 gespeichert sind, um einen Teil oder die gesamte hierin beschriebene hierarchische Fehler managementtechnik durchzuführen. Der Server 16 kann mit den Clients 32 und 34 über den Systemebenen-Datenbus 18 oder alternativ hierzu über jede andere geeignete Kommunikati onsverbindung kommunizieren, beispielsweise eine satelli ten-gestützte drahtlose Verbindung, einer Modemverbindung, etc. In ähnlicher Weise kann der Server 16 mit einem Client 33 an einem anderen Knoten oder System mittels eines Daten busses 35 kommunizieren, der ebenfalls ein Ethernet- Datenbus oder jeder andere geeignete Datenbus sein kann. Die Clients 32 bis 34 können auf jeder Art von Hardware- Plattformen laufen, beispielsweise in einer Workstation, einem Personal-Data-Assistent (PDA), einem Laptop-Computer, etc., die mit dem Server 16 kommunizieren können. Selbst verständlich können auch andere Vorrichtungen, beispiels weise Datenspeichervorrichtungen, zusätzliche Nutzer schnittstellen etc. (nicht gezeigt), ebenfalls mit dem Sys temebenen-Datenbus 18 und/oder dem Datenbus 35 verbunden sein, der mit dem anderen Knoten oder System assoziiert ist.

Das Prozesssteuersystem 10 weist ferner eine erste und zweite Steuerung 36 und 38 auf, die Steuerungen vom Typ der verteilten Steuersysteme (distributed control system DTS) sein können, beispielsweise Delta V-Steuerungen, die von der Fisher-Rosemount-System, Incorporation, erhältlich sind oder von jedem anderen Typ von Steuerungen. Die Steuerungen 36 und 38 können kommunikativ mit den Systemebenen-Datenbus 18 unter Verwendung entweder eines proprietären Kommunika tionsprotokolls oder jedes anderen geeigneten Kommunikati onsprotokolls gekoppelt sein. Die Steuerungen 36 und 38 kommunizieren mit Feldgeräten 40 bis 44 bzw. 46 bis 50 mit tels ersten bzw. zweiten Ein-/Ausgabe (I/O)-Geräten 52 bzw. 54 und Steuerungsdatenbussen 56 bzw. 58. Wie in Fig. 1 ge zeigt, sind die Feldgeräte 40 bis 50 intelligente Feldgerä te, die auf das Prozesssteuersystem 10 bezogene Information durch Senden von Nachrichten über die Steuerungsdatenbusse 56 und 58 kommunizieren. Es ist bekannt, dass intelligente Feldgeräte verwendet werden, um einen oder mehrere Prozess steuerschleifen entweder in Verbindung mit oder unabhängig von einer Steuerung auszuführen. Die intelligenten Feldge räte 40 bis 50 können beispielsweise Fieldbus-Geräte sein, wobei in diesem Fall die Steuerungsdatenbusse 56 und 58 nicht-proprietäre Protokolldatenbusse sind, die das Founda tion-Fieldbus-Signalprotokoll verwenden. Andere Typen vor Geräten und Protokollen, beispielsweise das HART, PROFIBUS, WORLDFIP, Device-Net, CAN und AS-Schnittstellenprotokoll können jedoch genauso gut verwendet werden. Zusätzlich kön nen die Steuerungen 36 und 38 direkt mit üblichen (d. h. nicht intelligenten) Feldgeräten (beispielsweise Feldgeräte mit einer üblichen analogen Schnittstelle, beispielsweise 4 bis 20 mA oder 0 bis 10 VDC) verbunden sein. Als Beispiel ist die erste Steuerung 36 mit einem üblichen nicht intel ligenten Feldgerät 60 und die zweite Steuerung 38 mit einem nicht intelligenten Feldgerät 61 verbunden.

Die Feldgeräte 40 bis 50, 60 und 61 sind mit den Geräten 62 bis 71 verbunden. Insbesondere sind die nicht intelligenten Feldgeräte 60 bzw. 61 mit Mischkesseln 62 bzw. 71 verbun den. Das Feldgerät 42 ist mit einem ersten Farbgrundstoff spender 63, das Feldgerät 40 mit einem ersten Mischer 64 und das Feldgerät 44 mit einem ersten Färbemittelspender 66 verbunden. Das Feldgerät 46 ist mit einem zweiten Mischer 70, das Feldgerät 50 mit einem zweiten Färbemittelspender 68 und das Feldgerät 48 mit einem zweiten Farbgrundstoff spender 69 verbunden. Obwohl in der Fig. 1 nicht gezeigt, kann das Prozesssteuersystem 10 zusätzliche Steuerungen, Feldgeräte und Geräte nach Bedarf aufweisen, um Farbladun gen zu produzieren.

In Betrieb kann Fehlerinformation bei einem oder mehreren der Feldgeräte 40 bis 50, 60 und 61 als Antwort auf einen Steuerungsparameter erzeugt werden, der aus einem gewünsch ten oder benötigten Betriebsbereich herausfällt, als Ant wort auf einen Fehler eines Gerätes zur Ausführung einer Aktion oder als Antwort auf jede andere abweichende oder nicht akzeptable Bedingung in dem Feldgerät. Beispielsweise kann das Feldgerät 60 ein Niveausensor sein, der das Niveau einer Farbmischung im Mischkessel 62 erfasst. Wenn das ge messene Niveau der Farbmischung im Kessel 62 ein vorbe stimmtes maximales Niveau erreicht, erhält die Steuerung 36 automatisch Fehlerinformation von dem Feldgerät 60, die an gibt, dass die Farbmischung in Kessel 62 das vorbestimmte maximale Niveau erreicht hat. Beispielsweise kann ferner das intelligente Feldgerät 44 ein Ventil sein, das dem Fär bemittelspender 66 ermöglicht, kontrollierte Mengen von ei nem oder mehreren Färbemitteln dem Mischkessel 62 zuzutei len. Das Feldgerät 44 kann Sensorvorrichtungen und eine Steuerungslogik (beispielsweise Bestätigungslogik) aufwei sen, die Fehlerinformation als Antwort auf den Fehler des Färbemittelspenders 66 erzeugen, um geeignet auf Befehle und/oder Steuerungssignale zu antworten, die von dem Feld gerät 44 gesendet wurden. Beispielsweise wenn das Feldgerät 44 ein Signal an den Färbemittelspender 66 sendet, ein Ven til im Spender 66 zu öffnen, und das Feldgerät 44 detek tiert (über Drähte, Kommunikation etc.), dass das Ventil nicht geöffnet wurde oder das Ventil blockiert, dann kann das Feldgerät 44 eine geeignete Fehlerinformation erzeugen, die zu der Steuerung 36 durchläuft.

Auf Grund einer großen Anzahl von Feldgeräten und Steuerpa rametern, die normalerweise mit einem Prozesssteuersystem assoziiert sind, haben die Stapelausführungsfunktionen und/oder die Moduleinheiten möglicherweise eine unpraktisch große Menge von Fehlerinformationen abzuarbeiten und zu verwalten, die von der relativ großen Anzahl von Vorrich tungen, Steuerschleifen etc. gesammelt werden, die überall im Prozesssteuersystem verteilt sind. Beispielsweise benö tigen übliche Systeme die Stapelausführungs- oder eine an dere Fehlermanagementroutine (beispielsweise eine Fehlerma nagementlogik in einer Einheitsphase), um gleichzeitig den Betriebszustand jedes Feldgerätes zu überwachen, das mögli cherweise von dem System verwendet wird, um einen Stapel prozess auszuführen, unbeachtlich ob ein bestimmtes Gerät durch den Prozess (oder Phase) benötigt wird, das gerade ausgeführt wird. In der Praxis ist die Verwaltung einer solch großen Menge von Fehlerinformation durch höhere Ebe nenfunktionen, beispielsweise der Stapelausführungsfunktion oder Moduleinheiten, sehr schwierig. Daraus folgt, dass viele Systementwickler/Betreiber vorziehen, im Wesentlichen die Anzahl der Geräte in einem Prozesssteuersystem zu redu zieren, das die Stapelausführungen überwacht oder das jede Moduleinheit überwacht, wodurch das Risiko gesteigert wird, dass ein geringwertiges und/oder gefährliches Produkt un wissentlich durch das System hergestellt wird (das heißt, Fehler in nicht überwachten Geräten werden nicht erfasst). Alternativ ziehen Systementwickler vor, fast nahezu jedes Gerät und Steuerparameter in einem Prozesssteuersystem zu überwachen, wodurch die Häufigkeit stark anwächst, in der ein Prozess als Antwort auf einen Fehler beendet wird, der andererseits keinen Einfluss auf die Qualität des von dem System produzierten Produktes hat.

Wie noch nachstehend im größeren Detail diskutiert witd, reduziert die hierin beschriebene hierarchische Fehlermana gementtechnik die Menge der Fehlerinformation, die die Sta pelausführungsfunktion (und/oder die Fehlermanagementlogik in einer Einheitsphase) zu jeder gegebenen Zeit während der Ausführung eines Stapelprozesses abarbeiten muss. Genauer, die hierin beschriebene Fehlermanagementtechnik beinhaltet Funktionsblöcke in den Steuermodulen (die in der Modulebene der Gerätehierarchie sind), die zusammengesetzte Fehlerco des erzeugen und die diese zusammengesetzten Fehlercodes zu der Einheitenebene der Gerätehierarchie automatisch zu den Zeiten senden, wenn die zusammengesetzten Fehlercodes zu Modulen gehören, die gerade durch eine Einheitsphase benö tigt werden, um einen ausgeführten Prozess durchzuführen. Die Moduleinheiten (die in der Einheitenebene sind) bein halten Funktionen, die ferner diese zusammengesetzten Feh lercodes abarbeiten, um zu bestimmen, ob ein gerade ausge führter Stapelprozess fortgesetzt wird oder der Stapelpro zess angehalten werden soll. Auf diese Weise kann eine Moduleinheit eine relativ einfache Steuerlogik verwenden, die relativ wenige zusammengesetzte Fehlercodes abarbeitet, um zu bestimmen, ob ein Stapelprozess fortgesetzt oder der gerade ausgeführte Stapelprozess angehalten werden soll. Natürlich kann ein Teil oder die gesamte Fehlerinformation, die in der Einheitenebene abgearbeitet wird, auch zu der Stapelausführungsfunktion hochlaufen. Die Stapelausfüh rungsfunktion kann dann diese Information verwenden, um ei ne unabhängige Bestimmung vorzunehmen, ob ein Prozess fort gesetzt oder ob Geräte erneut zugeordnet werden sollen, um eine fehlerhafte Vorrichtung zu umgehen und um ein Anhalten des gerade ausgeführten Stapels zu verhindern. Da ferner jeder der zusammengesetzten Fehlercodes auf Grundlage einer großen Anzahl von Gerätezustandsbedingungen und Steuer schleifenparameterbedingungen gebildet werden kann, darf ein Systementwickler oder Systembetreiber nicht auf die Überwachung von Geräten und/oder Steuerparametern verzich ten, um die Implementierung von Fehlermanagementlogik in einem komplexen Prozessteuersystem praktikabel zu machen. Die Konsolidierung der Fehlerinformation in zusammen gesetzten Fehlercodes ermöglicht im Gegenteil das Prozess steuersystem dazu, eine relativ große Menge von Fehlerin formation wirksamer zu verwalten. Da weiterhin die hierin beschriebene hierarchische Fehlermanagementtechnik zusam mengesetzte Fehlercodes zu der Einheitenebene (und falls gewünscht zur Stapelausführung) hochsendet, die mit einer gerade ausgeführten Phase oder einem Schritt in einer Phase des Stapelprozesses assoziiert sind, führt die hierin be schriebene Fehlermanagementtechnik eine wirksame Zeitfilte rung von Fehlerinformation durch, wodurch die Menge der Fehlerinformation erheblich reduziert wird, die die Fehler managementlogik zu jeder gegebenen Phase oder jedem Sehritt (das heißt zu jedem Zeitintervall) während der Ausführung eines Prozesses abarbeiten muss.

Bevor speziellere Aspekte der hierarchischen Fehlermanage menttechnik diskutiert werden, wird eine kurze Diskussion der hierarchischen Beziehungen zwischen der physikalischen Ausstattung in einem Prozesssteuersystem und den verschie denen Abstraktionsebenen, die mit dem Prozesssteueralgo rithmus assoziiert sind, der durch das System 10 ausgeführt wird, in Verbindung mit den Fig. 2 und 3 gegeben. Fig. 2 ist ein Blockdiagramm, das ein hierarchisches Ausstat tungsmodell 100 abbildet, welche die physikalischen Bezie hungen zwischen den verschiedenen Steuerungsebenen und phy sikalischen Aktivitäten in dem Prozesssteuersystem 10 dar stellt. Das in Fig. 2 gezeigte Modell basiert auf der be kannten SP-88-Ausstattungshierarchie, obwohl stattdessen andere Hierarchiemodelle verwendet werden können, ohne den Rahmen und den Sinn der Erfindung zu verlassen.

Auf der höchsten Ebene des hierarchischen Modells 100 sind Bereiche 105 und Prozesszellen 110. Die Bereiche 105 und Prozesszellen 110 sind notwendigerweise geografischer Natur und entsprechend physikalischen Orten in dem Prozesssteuer system 10. Üblicherweise sind Bereiche 105 mit einem Gebäu de oder einer Anlage assoziiert, wohingegen die Prozesszel len 110 mit Orten in einem Gebäude oder einer Anlage asso ziiert sind, die eine bestimmte Art eines Produktes her stellen. Beispielsweise kann das in Fig. 1 gezeigte System 10 physikalisch zu einem Bereich gehören, der eine Farbpro duktionsfabrik einschließlich einer Menge von Steuerungen sein kann, von denen einige in der Fig. 1 (d. h. die Steu erungen 36 und 38) und einige von denen nicht gezeigt sind, in einer Mehrzahl von Feldgeräten, verschiedene Teile der Ausstattung, Client-stations etc. Die Steuerungen 36 und 38 sowie die Feldgeräte 40 bis 50, 60 und 61, die Ein-/Aus gabegeräte 52 und 54 und die Ausstattung 62 bis 71 kön nen zusammen auf der anderen Seite zu einer Prozesszelle gehören, die eine oder mehrere Ladungen von Farbe mischt.

Moduleinheiten 115 in dem hierarchischen Modell 100 ent sprechen üblicherweise einem bestimmten Teil der Ausstat tung, zusammen mit einigen Sensoren, Stellgliedern usw., die in Verbindung mit der Ausstattung funktionieren. Bei spielsweise können die Steuerungen 36 (Fig. 1), die damit verbundenen Feldgeräte 40 bis 44 und 60, der Mischkessel 62, der Mischer 64 (der den Inhalt des Kessels 62 mischt), der Grundstoffspender 63 und der Färbemittelspender 66 (der eine oder mehrere Färbemittel zu der Mischung in den Kessel hinzufügen kann) zusammen einer Moduleinheit oder einer Einheit (das heißt einer Mischungseinheit) zugehören. Glei chermaßen können die Steuerungen 38, die Feldgeräte 46 bis 50 und 61, der Mischkessel 71, der Mischer 70, der Grund stoffspender 69 und der Färbemittelspender 68 zusammen zu einer anderen Einheit gehören.

Steuermodule 120 in dem hierarchischen Modul 100 gehören üblicherweise zu Regelsteuerfunktionen der unteren Ebene, beispielsweise Proportional-, Integral-, und/oder Differen zial-Steuerfunktionen. Obwohl Steuermodule, zumindest be grifflich, primär funktionaler Natur sind, empfangen die Steuermodule Eingaben von Sensoren und/oder anderen Modulen (die üblicherweise verwendet werden, um ein Rückführungs signal zu liefern, um eine geschlossene Steuerschleife zu vollenden) und die Steuermodule bearbeiten diese Eingaben, um gewünschte Steuerschleifenbedingungen (beispielsweise einen Einstellwert) unter Verwendung eines vorbestimmten Steueralgorithmus zu erhalten, der geeignete Ausgaben für Stellglieder, Heizer, Motoren etc. liefert. Beispielsweise können unter Bezug auf Fig. 1 das Feldgerät 60 (welches ein Niveausensor sein kann), der Grundstoffspender 63 und das Feldgerät 42 mit einem Steuermodul zusammen wirken, um das Niveau der Farbgrundstoffmischung zu steuern, welches durch den Grundstoffspender 63 in den Mischkessel 62 hinzu gefügt wird. Der mit diesem Steuermodul assoziierte Steuer algorithmus kann in dem intelligenten Feldgerät 42 oder al ternativ in der Steuerung 36 installiert sein. Da natürlich die Steuermodule 120 abstrakt sind, können die entsprechen den physikalischen Komponenten der Steuermodule 120 in der Praxis überlappen, sodass beispielsweise ein Teil der Aus stattung mit mehreren Steuermodulen oder einer Vielzahl von Steuermodulen wechselwirkt, die benötigt werden, um ein einzelnes Teil der Ausstattung zu betreiben.

Das in der Fig. 2 gezeigte hierarchische Ausstattungsmo dell 100 kann verwendet werden, um die Entwicklung ver schiedener Softwareobjekte zu erleichtern, die, wenn auf den Workstations 12 und 14, den Steuerungen 36 und 38 und/oder in den intelligenten Feldgeräten 40 bis 50 instal liert sind, dem Prozesssteuersystem 10 ermöglichen, Ladun gen von Farbe zu produzieren. Es ist bekannt, objektorien tierte Programmiertechniken zu verwenden, um einen hochkom plexen Steueralgorithmus in einer modularen Weise zu entwi ckeln, sodass individuelle Objekte oder Module unabhängig entwickelt werden können. Es ist bekannt, dass diese Module oder Softwareobjekte miteinander durch Austausch von Para meterwerten kommunizieren können und dass sie ineinander verschachtelt sein können, um hochkomplexe Steuerfunktionen oder Steuerprozeduren zu bilden.

Wenn ein Systementwickler ein Prozesssteuerungssystem, bei spielsweise das System 10 aus Fig. 1, unter Verwendung der in Fig. 2 gezeigten hierarchischen Struktur 100 erstellt, kann er in einfacher Weise hierarchisch-bezogene Software objekte entwickeln, die zu verschiedenen Steuermodulen, Mo duleinheiten, Prozesszellen etc. gehören, die das Prozess steuersystem bilden. Wenn beispielsweise das System aus Fig. 1 im Hinblick darauf betrachtet wird, kann der System entwickler erkennen, dass ein Modul zum Öffnen eines Ven tils für eine bestimmte Zeitdauer benötigt wird, beispiels weise Ventile in den Färbemittelspendern 66 und 68. Hier kann der Systementwickler ein Objekt entwickeln, dass Para meter empfängt, beispielsweise Ventilöff nungs/Schließzustand, Öffnungsdauer, Ventilidentifizierung etc., und das als Antwort auf die von diesen Parametern empfangenen Werte einer Ausgabe liefert, die bewirkt, dass ein bestimmtes Ventil für eine spezifizierte Zeitdauer öff net, um dadurch eine vorbestimmte Menge eines spezifischen Färbemittels zu spenden. Selbstverständlich kann dieses Ventilöffnungsobjekt verwendet werden, um die Funktion je des anderen Steuermoduls in dem Prozesssteuersystem 10 durchzuführen, das eine zeitliche Aktivierung eines Ventils benötigt. Ferner kann der Systementwickler erkennen, dass ein Einheitenebenensoftwareobjekt benötigt wird, um das Ventilöffnungsobjekt aufzurufen. Dieses Einheitenebenen softwareobjekt kann Parameter erhalten, die die Menge des Färbemittels, den Färbemitteltyp etc. (beispielsweise von einer Stapelausführung) angeben, um eine Färbemittelspende funktion auszuführen. Das Färbemittelspendeobjekt kann der Reihe nach das Ventilöffnungsobjekt aufrufen und den geeig neten Ventilzustand, die Öffnungszeit und Ventilidentifika tionsparameter liefern, sodass der geeignete Typ und die geeignete Menge des Färbemittels in den Mischkessel 62 hin zugegeben wird. Auf jeden Fall kann aus der vorstehenden Diskussion gesehen werden, dass das in Fig. 2 gezeigte hierarchische Modell 100 verwendet werden kann, um die Ent wicklung einer Hierarchie von modularen Softwareobjekten zu erleichtern, die zusammenwirken, um einen komplexen Steuer prozess auszuführen.

Fig. 3 zeigt ein Blockdiagramm 150, das verschiedene Abs traktionsebenen in einem komplexen Stapelprozesssteueralgo rithmus darstellt. Allgemein ausgedrückt, ein Stapelpro zesssteueralgorithmus ist ein Programm der höheren Ebene, das, wenn es durch eine Stapelausführung ausgeführt wird, eine geordnete Installation von Softwareobjekten bewirkt, die mit Moduleinheiten und Steuermodulen assoziiert sind, die benötigt werden, um Stapelbefehle höherer Ebenen auszu führen. Beispielsweise unter Bezug auf Fig. 1 kann eine Stapelprozedur zur Herstellung von etwa 455 Liter (100 Gal lonen) einer mitternachtsblauen Latexfarbe das Hinzufügen von etwa 0,57 Liter (1 Pint) eines bestimmten Blaufärbemit tels zu dem Mischkessel 62 spezifizieren. Während der Aus führung des Stapelprozesses kann die Stapelausführung bei spielsweise ein ADD COLORANT-Objekt in der Steuerung 36 die in der Einheiten-ebene der Ausstattungshierarchie ist, in stallieren und Parametern zu den ADD COLORANT-Objekten in der Steuerung 36 geben, die das Blaufärbemittel und die Menge des Blaufärbemittels spezifizieren, die hinzugefügt werden. Das ADD COLORANT-Objekt kann der Reihe nach ein VALVE_OPEN-Objekt aufrufen, das in dem intelligenten Feld gerät 44 installiert sein kann, und kann Parameter zu dem VALVE_OPEN-Objekt übermitteln, die die Ventilidentifikation spezifizieren, dass das Ventil geöffnet werden soll, und die Dauer, für die das Ventil geöffnet werden soll. Als Antwort auf den Erhalt der Parameter von dem ADD COLORANT- Objekt bewirkt das VALVE_OPEN-Objekt in dem Feldgerät 44, dass das Feldgerät 44 eine Ausgabe an den Färbemittelspen der 66 sendet, der ein Ventil in dem Färbemittelspender 66 öffnet, um die gewünschte Menge des gewünschten Blautonfär bemittels in den Mischkessel 62 zu spenden.

In der Praxis kann die Ausführung einer Stapelprozedur suk zessive Installation von hierarchisch bezogenen Softwareob jekten betreffen. Wie in Fig. 3 genauer gezeigt wird, kann eine Stapelprozedur 155 eine oder mehrere Einheitenprozedu ren 160 und Einheitenoperationen 165 aufrufen, die Soft wareobjekte sind, die üblicherweise in der Einheitenebene (beispielsweise eine Steuerung) eines Prozesssteuersystems installiert sind. Allgemein gesagt sind Einheitenprozeduren und Operationen Objekte, die auf den Betrieb und/oder Steu erung eines bestimmten Typs der Ausstattung bezogen sind. Im Gegensatz dazu sind Phasen 170 im Allgemeinen auf eine Art von Aktion bezogen, die ein bestimmtes Teil der Aus stattung ausführen kann. Beispielsweise können Phasen, die mit der Herstellung einer Ladung von Farbe assoziiert sind, ADD COLORANT, MIX, STIR, BLEND, FILL_BASE, etc. sein. Jede dieser Phasen kann der Reihe nach in einem oder mehreren Schritten 175 zusammengefügt sein, die in geordneter Weise gemäß eines Algorithmus ausgeführt wird. Die Schritte 175 befinden sich auf der Steuermodulebene der Systemhierarchie und jeder Schritt ruft üblicherweise ein Softwareobjekt oder -objekte auf, die mit einem Steuermodul assoziiert sind. Beispielsweise kann eine MIX-Phase ein oder mehrere Schritte aufweisen, die bewirken, dass einer der Blender 64 und 70 in einer vorbestimmten Weise (das heißt gemäß dem Algorithmus) an- und ausgestellt werden kann, um eine wirk same Mischung der Farbe in den Mischkesseln 62 und 71 zu leisten.

Wenn die Phasen 170 und die Schritte 175 in den Phasen 170 durch das Prozesssteuersystem 10 ausgeführt werden, können Eingaben von Sensoren benötigt sein, kann Ausstattung zur Ausführung von Aktionen benötigt sein, können Steuerparame ter in einem gewünschten Zielbereich benötigt sein etc., bevor der Steuerprozess fortfährt. Deshalb können Sensor fehler, die von einer fehlenden Eingabe oder einer unakzep tablen ungenauen Eingabe herrühren, der Fehler der Ausstat tung, um eine benötigte Aktion auszuführen, und/oder der Fehler von Steuerparametern die innerhalb eines akzeptablen Bereiches fallen, ein Anhalten des Prozesses benötigen, um die Beschädigung der Ausstattung, die Produktion eines ge ringwertigen oder gefährlichen Produktes zu verhindern, und/oder um einem Systembetreiber zu ermöglichen, eine Ab hilfe des Fehlers vor der Fortsetzung des Prozesses bereit zustellen.

Das in Fig. 1 gezeigte Prozesssteuersystem 10 verwendet eine vollständig integrierte Gerätehierarchie (wie allge mein in den Fig. 2 und 3 dargestellt), um automatisch zusammengesetzte Fehlerinformation zu übermitteln, die Ge rätefehler und Steuerfehler oder jede andere Fehlerinforma tion enthalten, die von der Steuermodulebene hoch zu der Moduleinheitenebene der Systemhierarchie gesendet werden. Die integrierte Hierarchie ermöglicht einer Moduleinheit, die verschiedenen Steuermodule zu registrieren, die unter geordnet zu dieser Moduleinheit sind (oder zu jedem anderen Steuermodul im System 10 das nicht untergeordnet zu dieser Moduleinheit ist), um automatisch Fehlerinformation von diesen Steuermodulen zu erhalten. Daraus folgt, dass ein Phasenablauf in einer Moduleinheit automatisch Fehlerinfor mation erhalten kann, die mit den Steuermodulen assoziiert ist, die Schritte dieser Phase ausführen, oder mit Steuer modulen, die der Phase nicht untergeordnet sind, aber die auf die Ausführung von Phasenschritten eine Auswirkung ha ben können. Die Phase kann dann die Fehlerinformation bear beiten, um zu bestimmen, ob der Prozess fortgesetzt werden kann (d. h. ob der laufende Schritt und/oder weitere Schritte ausgeführt werden können). Natürlich wird die Feh lerinformation, die von Phasen innerhalb einer Moduleinheit abgearbeitet wird, hoch zu der Stapelausführung übermit telt, die auf der Workstation 14 läuft, und die Stapelaus führung kann die Fehler dem Systembetreiber, beispielsweise über eine graphische Nutzer-Schnittstelle berichten. Zu sätzlich kann die Stapelausführung weitere Aktionen unter nehmen, um erneut Geräte anzuordnen, um den Fehler zu umge hen, und/oder die Stapelausführung kann weitere Instruktio nen von dem Systembetreiber vor der Fortsetzung abwarten.

Fig. 4 ist ein schematisches Blockdiagramm, das im größeren Detail die Art und Weise darstellt, in der die Phasen und Schritte eines Prozesssteueralgorithmus auf den Moduleinheiten- und Steuermodulebenen eines Prozesssteuersystems 10 (Fig. 1) wechselwirken können. Insbesondere wird in Fig. 4 eine Farb mischeinheit 200 gezeigt, die mit der Steuerung 36 (Fig. 1) assoziiert ist. Während der Ausführung eines Stapelprozesses kann die Stapelausführungsfunktion eine Einheitenprozedur/- operation aufrufen, um den Mischkessel 62 mit einer vorbestimm ten Menge eines Farbgrundstoffes zu befüllen. Üblicherweise, aber nicht notwendigerweise, ist die Einheitenprozedur in Steu erung 36 installiert. Die Einheitenprozedur ruft der Reihe nach eine FILL_BASE-Phase 204, die üblicherweise ebenfalls in der Steuerung 36 installiert ist, durch Übermittlung von Parame tern, beispielsweise Grundstofftyp und Grundstoffmenge, an die FILL_BASE-Phase 204 auf. Wie in Fig. 4 gezeigt, kann die FILL_BASE-Phase 204 einen oder mehrere Schritte 206 aufweisen, von denen jeder durch Aufrufen einer oder mehrerer Steuermodule 208 bis 212 ausgeführt werden kann. Beispielsweise kann die FILL_BASE-Phase 204 einen Schritt aufweisen, der ein Ventil in dem Grundstoffspender 63 für eine vorbestimmte Zeitdauer öff net, sodass eine gewünschte Menge eines bestimmten Grundstoffes dem Mischkessel 62 zugefügt wird. Dieser Schritt kann Parame ter, beispielsweise Ventilidentifikation, geöffne ter/geschlossener Zustand und die Dauer, an das VALVE_OPEN- Modul 208 (das in dem Feldgerät 42 installiert sein kann) über mitteln, um die gewünschte Aktion auszuführen. Insbesondere kann das VALVE_OPEN-Modul 208 das Feldgerät 42 bewirken, eine Ausgabe zu liefern, das ein geeignetes der Ventile 218 und 219 in dem Grundstoffspender 63 für eine geeignete Zeitdauer öff net, sodass der gewünschte Farbgrundstoff dem Mischkessel 62 zugefügt wird.

Die FILL_BASE-Phase 204 kann also explizit ein Interesse an nicht untergeordneten Modulen registrieren, die nicht implizit benötigt werden, um Aktionen für die Schritte 206 (d. h. für die Steuermodule 208 bis 212) auszuführen, die aber dennoch ei ne Auswirkung auf die Ausführung der FILL_BASE-Phase 204 haben können. Beispielsweise kann die FILL_BASE-Phase 204 ein Inte resse an einem SPILL_Modul 220 registrieren, das fortlaufend den Bereich des Anlagenbodens überwacht, der die Einheit 200 umgibt, um zu bestimmen, ob eine relativ große Menge von Farbe (oder eines Farbbestandteils), beispielsweise aufgrund eines Leitungslecks, Ventils, Tanks etc. ausgeflossen ist. Obwohl die Schritte der FILL_BASE-Phase 204 das SPILL-Modul 220 durch Sen den von Parametern an dieses nicht steuern oder aufrufen, kann ein Systementwickler spezielle sicherheitsbezogene und/oder Alarmschritte in der FILL_BASE-Phase 204 einfügen, die auf das SPILL-Modul 220 antworten. Wenn beispielsweise die FILL_BASE- Phase 204 über das SPILL-Modul 220 bestimmt, dass eine große Menge von Farbe ausgeflossen ist, kann die FILL_BASE-Phase 204 unverzüglich alle gerade geöffneten Ventile schließen und einen Alarm an den Systembetreiber senden, der den aufgetretenen Aus fluss anzeigt.

Zusätzlich zur Ausführung von Aktionen, die durch Phasen schritte oder durch Lieferung explizit angeforderter Zu standsinformation aufgerufen wurden, können die Module 208 bis 212 und 220 entsprechende Logiken 222 bis 226 aufwei sen, die den Betriebszustand der Ausstattung, die von jedem Modul gesteuert wird, die Werte der Prozessvariablen im Vergleich zu einem vorbestimmten Betriebsbereich (bei spielsweise einem Stellwert oder Steuerbereich) oder jede andere gewünschte Fehlerinformation überwachen. Da die Ausstattungshirachie des Prozesssteuersystems 10 vollstän dig integriert ist, kann die Fehlerinformation, die von je dem der Module 208 bis 212 und 220 gesammelt wird, falls gewünscht, sich automatisch über diese Einheit 200 ausbrei ten. Deshalb kann jede Phase auf einer schrittweisen Basis die Fehlerinformation bearbeiten, die mit dem Modul oder den Modulen assoziiert ist, die diesen Schritt ausführen, um zu bestimmen, ob der Schritt fortgesetzt werden kann. Auf diese Weise braucht weder die Phase noch die Stapelaus führung die gesamte Fehlerinformation auf einer systemwei ten Basis direkt überwachen oder bearbeiten, wie es in frü heren Systemen der Fall war. Stattdessen kann jede Phase für jeden Schritt bestimmen, ob der Prozess fortgesetzt werden kann, durch Abarbeiten lediglich der Fehlerinforma tion, die zu dem Fehler zu der Zeit gehört, wenn der Schritt ausgeführt wird (oder kurz vor der Zeit zu der der Schritt ausgeführt wird). Die Stapelausführung kann dann beispielsweise eine Nachricht von der Phase erhalten, dass der Prozess angehalten wurde, oder kann alternativ eine Nachricht erhalten, um andere Aktionen durchzuführen, wenn ein Fehler erkannt wurde, aber der Prozess aufgrund des Fehlers nicht beendet wurde.

Fig. 5 ist ein beispielhaftes, schematisches Blockdia gramm, dass die Art und Weise illustriert, in der Steuermo dule Fehlerinformation zu den Einheitenphasen verbreiten, und die Art und Weise, in der die Einheitenphasen diese Fehlerinformation weiter verarbeiten, um zu bestimmen, ob der aktuell ausgeführte Stapelprozess angehalten werden soll oder nicht oder ob eine andere Aktion durch den Sys tembetreiber durchgeführt werden soll. Wie in Fig. 5 ge zeigt, sind mehrere Steuermodule 300 bis 304 mit einer Pha se assoziiert, die in einer Einheit 306 läuft. Die Schritte der Phase können Parameter (in einer bestimmten Reihenfolge zu bestimmten Zeiten) zu einem oder mehreren der Steuermo dule 300 bis 304 senden, die der Einheit 306 untergeordnet sind, um die Module 300 bis 304 zu zwingen, Aktionen (bei spielsweise einen Teil der Geräte zwingen, eine Aktion aus zuführen) auszuführen, die den gewünschten Stapelprozess ausführen. Alternativ oder zusätzlich kann die Phase expli zit Interesse an einem oder mehreren der Steuermodule 300 bis 304 registrieren, die der Einheit 306 nicht untergeord net sind, die jedoch die Ausführung von einen oder mehreren Phasenschritten beeinflussen. Auf jeden Fall kann jedes der Steuermodule 300 bis 304 automatisch Informationen, bei spielsweise angeforderte Fehlerinformation, an die Einhei tenphasen übermitteln. Insbesondere enthalten die Steuermo dule 300 bis 304 entsprechende Listen von Fehlerinformation 308 bis 312. Jede der Listen 308 bis 312 enthält Fehlerin formationen bezüglich Sensoren, Ausstattung, Prozesssteuer variablen etc., die von einem entsprechenden der Steuermo dule 300 bis 304 bei Ausführung ihrer Funktion benötigt werden. Beispielsweise können die Listen der Fehlerinforma tion 308 bis 312 eine Angabe enthalten, dass ein Sensor nicht mehr funktioniert, dass ein Ventil geöffnet oder ge schlossen blockiert ist, dass ein Steuerparameter auserhalb einem vorbestimmten Bereich von Werten herausfällt, oder jede andere Information, die den Betriebszustand eines Teils der Ausstattung und/oder einer Steuerschleife be trifft, die benötigt wird, um Modulfunktionen auszuführen.

Es ist wesentlich, dass die Steuermodule 300 bis 304 ferner entsprechende Logiken 314 bis 318 aufweisen, die die Feh lerinformation verarbeiten, die in den Listen 308 bis 312 enthalten ist, um einen zusammengesetzten Fehlercode für jedes der Steuermodule 300 bis 304 zu bilden. Allgemein ge sprochen werden die zusammengesetzten Fehlercodes gebildet und von jedem der Steuermodule 300 bis 304 zu der Einheit 306 gesendet, wenn die Einheitenphase einen Schritt beginnt oder dabei ist, einen Schritt zu beginnen, der das bestimm te Steuermodul benötigt, (d. h. implizit das Modul benötigt um Aktionen auszuführen, oder explizit das Modul für Siche rungszwecke oder jeden anderen Zweck benötigt), so dass die Einheitenphase schneller und einfacher die zusammengesetzte Fehlerinformation verarbeiten kann, die mit einer relativ großen Anzahl von Geräten, Ausstattung, etc. assoziiert ist.

Die zusammengesetzten Fehlercodes können unter Verwendung einer Vielfalt von Techniken erzeugt werden. Beispielsweise kann jeder Eintrag in den Listen der Fehlerinformation 308 bis 312 einem numerischen Wert zugeordnet sein, der den Typ und die Bewertung der bestimmten Fehlerinformation wieder gibt. Die numerischen Werte in jeder der Listen 308 bis 312 können dann mathematisch verbunden werden, um einen zusam mengesetzten Fehlercode für dieses Modul zu bilden. Bei spielsweise können die numerischen Werte in den Listen 308 bis 312 unter Verwendung von Gewichtungskoeffizienten auf summiert werden, falls so gewünscht. Alternativ oder zu sätzlich können die numerischen Werte multipliziert, sub trahiert und/oder unter Verwendung jeder gewünschten linea ren Funktion, nicht-linearen Funktion, nicht zusammenhän gender Funktion etc. verarbeitet werden. Natürlich kann die Fehlerfunktion in jeder Liste in jeder anderen Weise ver bunden werden, um einen zusammengesetzten Fehlercode zu er zeugen, ohne den Rahmen und den Sinn der Erfindung zu ver lassen.

Ferner können einige Arten von Fehlern größere oder kleine re numerische Werte auf Grundlage des Vorhandenseins oder der Abwesenheit von anderen Fehlern in der Liste ergeben. In dem Fall eines Paares von redundanten Sensoren kann der Fehler beispielsweise von einem des Sensorpaares einen nu merischen Wert ergeben, der in der Liste dem fehlerhaften Sensor zugeordnet ist, wo hingegen der Fehler von beiden Sensoren einen höheren numerischen Wert bewirkt, um beiden Fehlern in der Liste zugeordnet zu werden. Weiterhin kann der jedem Fehler zugeordnete numerische Wert auf der Pro duktart basieren, das von dem Prozesssteuersystem herge stellt wird. In dem Fall eines Prozesssteuersystems, das Farbladungen produziert, können beispielsweise allgemein niedrige Fehlerwerte Fehlern in den Listen 308 bis 312 zu geordnet werden, wo hingegen in dem Fall eines Prozesssteu ersystems, das pharmazeutische Produkte herstellt, in all gemeinen höhere numerische Werte den Fehlern in den Listen 308 bis 312 zugeordnet werden.

Die Fehlercodes, die von jedem der Steuermodule 300 bis 304 erzeugt werden, werden der Einheit 306 übermittelt, und in einer dynamischen Fehlercodeliste 320 in der Einheit 306 verwaltet. Die gerade in der Einheit 306 ausgeführte Phase führt die Einheit 306 dazu, in der Fehlercodeliste 320 nur diese Fehlercodes von Modulen aufzunehmen, die implizit be nötigt werden, einen Schritt der Phase auszuführen, und die Fehlercodes von Modulen, die der Anwender während eines Schrittes der Phase explizit zur Überwachung anfordert. Die Phase weist eine Fehlermanagementlogik 322 auf, die bei spielsweise in Verbindung mit Fig. 7 nachfolgend beschrie ben wird und die die Fehlercodes in der Fehlercodeliste 320 verarbeitet, um zu bestimmen, ob der ausgeführte Prozess fortgesetzt werden soll oder ob eine andere Aktion statt finden soll.

Fig. 6 bildet beispielhaft die Art und Weise ab, in der die Fehlercodeliste 320 in der Einheit 306, gezeigt in Fig. 5, sich in der Zeit verändert (d. h. als ein fort schreitender Prozess). Wie in der Fig. 6 ersichtlich, ver wendet der zum Zeitpunkt t1 durch die Einheitenphase ausge führte Schritt nur Modul 1 (M1). Deshalb weist die Fehler codeliste 320 der Einheit nur den aktuellen zusammengesetz ten Fehlercode (der beispielhaft mit einem numerischen Wert von 500 dargestellt ist) für M1 auf. Ähnlicherweise wech selt der Inhalt der Fehlercodeliste 320 der Einheit zu den Zeitpunkten t2, t3 und t4 dynamisch, so dass Module, die aktuell nicht durch die Phase benötigt werden, nicht in der Fehlercodeliste 320 enthalten sind. Beispielsweise verwen det zum Zeitpunkt t2 die Einheitenphase Module 1, 2 und 3 (d. h. M1, M2 und M3) und die Fehlercodeliste 320 der Ein heit weist die entsprechenden zusammengesetzten Fehlercodes 750, 250 und 1000 auf. Wie in der Fig. 6, ersichtlich ver ändert sich die Gruppe der Module mit zusammengesetzten Fehlercodes in der Fehlercodeliste 320 der Einheit mit der Zeit. Ferner kann ein numerischer Wert des zusammengesetz ten Fehlercodes, der durch ein bestimmtes Modul geliefert wird, im Laufe der Zeit sich ändern. Beispielsweise ist M1 ein Mitglied der Gruppe von Modulen mit zusammengesetzten Fehlercodes in der Fehlercodeliste 320 der Einheit zu den Zeitpunkten t1 bis t4, der numerische Wert allerdings des zusammengesetzten von M1 gelieferten Fehlercode reicht von 250 bis 750 über die Zeiten t1 bis t4.

Fig. 7 ist ein beispielhaftes Flussdiagramm, dass eine Art und Weise darstellt, in der die Fehlermanagementlogik 322 der in Fig. 5 gezeigten Phase die Fehlercodes in der Feh lercodeliste 320 verarbeitet. Block 400 wählt den schlech testen Fehlercode aus der Fehlercodeliste 320. Der schlech teste Fehlercode ist in diesem Beispiel der Fehlercode mit dem größten numerischen Wert, da in diesem Beispiel Module derart konfiguriert sind, dass sie höhere numerische Werte größeren Fehlern zuordnen. Alternative Prozesstechniken können jedoch den Fehlercode mit dem kleinsten numerischen Wert auswählen, in dem Fall, wenn Module niedrigere numeri sche Werte größeren Fehlern zuordnen. Auf jeden Fall be stimmt Block 404, ob der schlechteste Fehlercode niedriger als ein erster Schwellwert (TH1) ist. Wenn der schlechteste Fehlercode niedriger als der erste Schwellwert ist, dann geht die Fehlermanagementlogik 320 in den Block 408 und be stimmt, dass der Prozess fortgesetzt werden kann. Anderen falls, wenn der schlechteste Fehlercode größer als der ers te Schwellwert ist, geht die Fehlermanagementlogik 322 zum Block 412. Block 412 bestimmt, ob der schlechteste Fehler code geringer als ein zweiter Schwellwert (TH2) ist und, falls der schlechteste Fehlercode geringer als der zweite Schwellwert ist, geht die Fehlermanagementlogik 322 zum Block 416. Block 416 zeigt an, dass der Prozess fortgesetzt werden kann, aber der zusammengesetzte Fehlercode ist genü gend groß, dass er weiteren Nachforschungen durch den Sys tembetreiber Wert ist. Es ist wichtig zu erkennen, dass die Einheit 306 die Notwendigkeit für Nachforschung an die Sta pelausführung berichten kann, die der Reihe nach geeignete Instruktion über eine graphische Benutzerschnittstelle dem Systembetreiber anzeigen kann. Anderenfalls, wenn der schlechteste zusammengesetzte Fehlercode nicht geringer als der zweite Schwellwert ist, dann geht die Fehlermanagement logik 322 zum Block 418. Block 418 bestimmt, ob der schlechteste zusammengesetzte Fehlercode geringer als ein dritter Schwellwert (TH3) ist und, wenn der schlechteste Fehlercode geringer als der dritte Schwellwert ist, geht die Fehlermanagementlogik 322 zum Block 422. Block 422 zeigt an, dass die Ausführung des Stapelprozesses fortge setzt werden kann, aber dass der zusammengesetzte Fehlerco de genügend groß ist, um zur Losschickung einer Wartungs person zur Fehlernachforschung Wert zu sein. Wenn der schlechteste zusammengesetzte Fehlercode größer als der dritte Schwellwert ist, dann geht die Fehlermanagementlogik 322 zum Block 426 und beendet automatisch das Ausführen des Stapels.

Die numerischen Werte für den ersten bis zum dritten Schwellwert, die in der Fig. 7 gezeigt, können auf Grund lage des Produkttypes, dass hergestellt wird, die Parameter des Prozesssteuersystems, der Produktqualitätszielen etc. ausgewählt werden. Beispielsweise kann die Produktion von pharmazeutischen Produkten und Hochqualitätsfarbprodukten im allgemeinen niedrigere Schwellwerte benötigen, um zu ga rantieren, dass schon relativ geringe Probleme zu einem An halten eines Stapels führen. Auf der anderen Seite können Farbprodukte niedrigerer Qualität beispielsweise höhere Schwellwerte ermöglichen, um die Häufigkeit eines Anhaltens zu minimieren, um die Produktionskosten niedrig zu halten. Obwohl ferner in Verbindung mit der Fig. 7 drei Schwell werte diskutiert wurden, können stattdessen mehr oder weni ger Schwellwerte verwendet werden, ohne den Rahmen und den Sinn der Erfindung zu verlassen. Weiterhin können Störungs beseitigungsinstruktionen/Nachforschungsvorschläge etc. beliebig variiert werden, um einer bestimmten Applikation zu entsprechen.

Obwohl die in Verbindung mit Fig. 7 beschriebene Fehlerma nagementlogik 322 als in der Einheit 306 ausgeführt be schrieben wird, kann die Stapelausführungsfunktion (die in diesem Beispiel auf der in Fig. 1 gezeigten Workstation 14 läuft) alternativ einige oder alle der Fehlermanagementak tivitäten durchführen. Alternativ oder zusätzlich können einige oder alle der Fehlermanagementaktivitäten bei einer oder mehreren Softwareroutinen durchgeführt werden, die auf dem Server 16 laufen. Auf jeden Fall berichtet, wenn die Einheit 306 die Fehlermanagementaktivitäten durchführt, die Einheit 306 vorzugsweise, aber nicht notwendigerweise der Stapelausführungsfunktion. Wenn beispielsweise die Fehler managementlogik 322 der Einheit bestimmt, das weitere Nach forschungen zur Bestimmung des Grundes eines Fehlers mit hohem Wert nötig ist, wird eine derartige Bestimmung der Stapelausführung berichtet, die dann die Nachricht dem Sys tembetreiber über die Benutzerschnittstelle übermitteln kann.

Die hierin beschriebene hierarchische Fehlermanagementtech nik übermittelt automatisch Fehlerinformation von Steuermo dulen an Einheiten zu einer Zeit, wenn diese Information durch die Einheit benötigt wird, um zu bestimmen, ob der aktuell ausgeführte Prozess fortgesetzt werden kann oder nicht. Weiterhin erzeugt die hierarchische Fehlermanage menttechnik zusammengesetzte Fehlercodes auf der Ebene der Steuermodule, die an Einheiten übermittelt werden, um durch die Fehlermanagementlogik in den Einheiten verarbeitet zu werden. Diese zusammengesetzten Fehlercodes ermöglichen, dass eine relativ große Menge von Fehlerinformation verwen det wird, um schnell auf der Ebene der Einheiten zu bestim men, ob ein Prozess fortgesetzt werden kann oder nicht. Weiterhin minimiert die hierin beschriebene hierarchische Fehlermanagementtechnik oder sie verhindert das Erscheinen von unnötigen Prozessstops als Antwort auf nichtkritische Fehler oder als Antwort auf Fehler in Verbindung mit Gerä ten und/oder Ausstattung, die aktuell nicht benötigt wird, um gerade ausgeführte Phasen des Prozesses auszuführen.

Falls in Software implementiert können die hierin disku tierten funktionalen Blöcke und Routinen in jedem computer lesbaren Speicher, beispielsweise in einem magnetischen, optischen oder anderen Speichermedium, in einem RAM oder ROM eines Computers, einer Steuerung, eines Feldgerätes etc. abgespeichert werden. Gleichermaßen kann diese Soft ware auf einen Träger abgestimmt oder einem Gerät mittels jeder bekannten oder gewünschten Zustellmethode zugestellt werden, einschl. beispielsweise über ein Kommunikationska nal, beispielsweise über eine Telefonleitung, das Internet etc.

Obwohl die Erfindung unter Bezug auf spezifische Beispiele beschrieben wurde, die nur der Erläuterung dienten und die Erfindung nicht einschränken, ist es für Fachleute offen sichtlich, dass Veränderungen, Hinzufügungen oder Weglas sungen an den offenbarten Ausführungsformen vorgenommen werden können, ohne den Sinn und den Rahmen der Erfindung zu verlassen.

Claims

1. Fehlermanagementverfahren zur Verwendung in einem Prozess steuersystem mit einer Moduleinheit und mehreren Steuermo dulen, die kommunizierend mit der Moduleinheit gekoppelt sind, um einen Prozess auszuführen, wobei das Verfahren folgende Schritte umfasst:
Sammeln von Fehlerinformation in jedem Steuermodul; Erzeugen eines zusammengesetzten Fehlercodes in jedem Steuermodul auf Grundlage der Fehlerinformation in jedem Steuermodul;
automatisches Senden einer Gruppe zusammengesetzter Feh lercodes an die Moduleinheit; und
Bestimmen, ob der Prozess auf Grundlage der Gruppe von Fehlercodes angehalten werden soll.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Sammelns der Fehlerinformation in je dem Steuermodul den Schritt des Erzeugens einer Feh lerliste in jedem Steuermodul aufweist.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Schritt des Erzeugens der Fehlerliste den Schritt des Speicherns von Fehlerinformation aufweist, die mit einem oder mehreren einer Steuerschleife, eines Sen sors oder Stellgliedes assoziiert ist, welche Aktionen für die Steuermodule ausführen.

4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Erzeugens des zusammengesetzten Feh lercodes in jedem Steuermodul auf Grundlage der Feh lerinformation in jedem Steuermodul den Schritt des mathematischen Verknüpfens der Fehlerinformation in jedem Steuermodul aufweist.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass der Schritt des mathematischen Verknüpfens der Fehler information den Schritt des Berechnens einer gewichte ten Summe unter Verwendung der Fehlerinformation auf weist.

6. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des automatischen Sendens der Gruppe von zusammengesetzten Fehlercodes an die Moduleinheit den Schritt des Auswählens der Gruppe der zusammengesetz ten Fehlercodes auf Grundlage einer Phase der Modul einheit aufweist.

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass der Schritt des Auswählens der Gruppe der zusammenge setzten Fehlercodes auf Grundlage der Phase der Modul einheit den Schritt des Auswählens der Gruppe der zu sammengesetzten Fehlercodes auf Grundlage einer lau fenden Phase der Moduleinheit aufweist.

8. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass der Schritt des Auswählens der Gruppe der zusammenge setzten Fehlercodes auf Grundlage der aktuellen Phase der Moduleinheit den Schritt des Auswählens eines zu sammengesetzten Fehlercodes aufweist, der mit einem nicht untergeordneten Steuermodul assoziiert ist.

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass der Schritt des Auswählens des zusammengesetzten Feh lercodes, der mit einem nicht untergeordneten Steuer modul assoziiert ist, den Schritt des Auswählens eines Fehlercodes auf Grundlage einer expliziten Anforderung aufweist, das nicht untergeordnete Modul in die lau fende Phase der Moduleinheit einzuschließen.

10. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt der Bestimmung, ob der Prozess auf Grund lage der Gruppe von zusammengesetzten Fehlercodes an gehalten werden soll, die Schritte des Auswählens ei nes zusammengesetzten Fehlercodes aus der Gruppe der zusammengesetzten Fehlercodes und des Vergleichens des einen ausgewählten Fehlercodes mit einem ersten vorbe stimmten Schwellwert aufweist, der mit einer Bestim mung assoziiert ist, ob der Prozess gestoppt werden soll.

11. Verfahren nach Anspruch 10, ferner gekennzeichnet durch den Schritt des Vergleichens des einen ausgewählten zusam mengesetzten Fehlercodes mit einem zweiten vorbestimm ten Schwellwert, der mit einer Bestimmung assoziiert ist, ob der Prozess fortgesetzt werden soll.

12. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass der Schritt des Auswählens des einen zusammengesetzten Fehlercodes aus der Gruppe der zusammengesetzten Feh lercodes den Schritt des Auswählens eines schlechtes ten zusammengesetzten Fehlercodes aufweist.

13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass der Schritt des Auswählens des schlechtesten zusammen gesetzten Fehlercodes den Schritt des Auswählens eines zusammengesetzten Fehlercodes mit dem höchsten numeri schen Wert aufweist.

14. Fehlermanagementverfahren zur Verwendung in einem Prozesssteuersystem mit einer Moduleinheit und einem Steuermodul, das kommunizierend mit der Moduleinheit gekoppelt ist, um einen Prozess auszuführen, wobei das Verfahren folgende Schritte umfasst:
Sammeln von Fehlinformation in dem Steuermodul;
Erzeugen eines zusammengesetzten Fehlercodes in dem Steuermodul auf Grundlage der Fehlerinformation in dem Steuermodul;
automatisches Senden des zusammengesetzten Fehlercodes zu der Moduleinheit; und
Bestimmen, ob der Prozess auf Grundlage des zusammen gesetzten Fehlercodes angehalten werden soll.

15. Verfahren nach Anspruch 14, dadurch gekennzeichnet, dass der Schritt des Erzeugens des zusammengesetzten Feh lercodes in dem Steuermodul auf Grundlage der Fehler information in dem Steuermodul den Schritt des mathe matischen Verknüpfens der Fehlerinformation in dem Steuermodul aufweist.

16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass der Schritt des mathematischen Verknüpfens der Fehler information den Schritt des Berechnens einer gewichte ten Summe unter Verwendung der Fehlerinformation auf weist.

17. Verfahren nach Anspruch 14, dadurch gekennzeichnet, dass der Schritt des Bestimmens, ob der Prozess auf Grund lage des zusammengesetzten Fehlercodes angehalten wer den soll, den Schritt des Vergleichens des zusammenge setzten Fehlercodes mit einem vorbestimmten Schwell wert aufweist.

18. Fehlermanagementsystem zur Verwendung in einem Prozesssteuersystem mit einem Prozessor, einer Modul einheit und mehreren Steuermodulen, die kommunizierend mit der Moduleinheit gekoppelt sind, wobei das System folgendes umfasst:
ein computerlesbares Medium;
eine erste auf dem computerlesbaren Medium abgespei cherte Routine, die dazu ausgebildet ist, von dem Pro zessor ausgeführt zu werden, der Fehlerinformation in jedem der Steuermodule sammelt;
eine zweite auf dem computerlesbaren Medium abgespei cherte Routine, die dazu ausgebildet ist, von dem Pro zessor ausgeführt zu werden, der einen zusammengesetz ten Fehlercode in jedem der Steuermodule auf Grundlage der Fehlerinformation in jedem Steuermodul erzeugt;
eine dritte auf dem computerlesbaren Medium abgespei cherte Routine, die dazu ausgebildet ist, von dem Pro zessor ausgeführt zu werden, der automatisch eine Gruppe von zusammengesetzten Fehlercodes an die Modul einheit sendet; und
eine vierte auf dem computerlesbaren Medium gespei cherte Routine, die dazu ausgebildet ist, von dem Pro zessor ausgeführt zu werden, der bestimmt, ob der Pro zess auf Grundlage der Gruppe der zusammengesetzten Fehlercodes angehalten werden soll.

19. System nach Anspruch 18, dadurch gekennzeichnet, dass die erste Routine ferner dazu ausgebildet ist, eine Fehlerliste in jedem Steuermodul zu erzeugen.

20. System nach Anspruch 19, dadurch gekennzeichnet, dass die erste Routine ferner dazu ausgebildet ist, Fehler informationen zu speichern, die mit einem oder mehre ren von einer Steuerschleife, einem Sensor und einem Stellglied assoziiert ist, die Aktionen für die Steu ermodule ausführen.

21. System nach Anspruch 18, dadurch gekennzeichnet, dass die zweite Routine ferner dazu ausgebildet ist, die Fehlerinformationen in jedem Steuermodul mathematisch zu kombinieren.

22. System nach Anspruch 21, dadurch gekennzeichnet, dass die zweite Routine ferner dazu ausgebildet ist, unter Verwendung der Fehlerinformation eine gewichtete Summe auszurechnen.

23. System nach Anspruch 18, dadurch gekennzeichnet, dass die dritte Routine ferner dazu ausgebildet ist, die Gruppe der zusammengesetzten Fehlercodes auf Grundlage einer Phase der Moduleinheit auszuwählen.

24. System nach Anspruch 23, dadurch gekennzeichnet, dass die dritte Routine ferner dazu ausgebildet ist, die Gruppe der zusammengesetzten Fehlercodes auf Grundlage einer laufenden Phase der Moduleinheit auszuwählen.

25. System nach Anspruch 18, dadurch gekennzeichnet, dass die vierte Routine ferner dazu ausgebildet ist, einen zusammengesetzten Fehlercode aus der Gruppe der zusam mengesetzten Fehlercodes auszuwählen und diesen einen zusammengesetzten Fehlercode mit einem ersten vorbe stimmten Schwellwert zu vergleichen, der mit einer Be stimmung assoziiert ist, ob der Prozess angehalten werden soll.

26. System nach Anspruch 25, dadurch gekennzeichnet, dass die vierte Routine ferner ausgebildet ist, den einen zusammengesetzten Fehlercode mit einem zweiten vorbe stimmten Schwellwert zu vergleichen, der mit einer Be stimmung assoziiert ist, dass der Prozess fortgesetzt werden soll.

27. System nach Anspruch 25, dadurch gekennzeichnet, dass die vierte Routine ferner ausgebildet ist, einen schlechtesten zusammengesetzten Fehlercode aus der Gruppe der zusammengesetzten Fehlercodes auszuwählen.

28. System nach Anspruch 27, dadurch gekennzeichnet, dass die vierte Routine ferner dazu ausgebildet ist, einen zusammengesetzten Fehlercode mit dem höchsten numeri schen Wert als den schlechtsten zusammengesetzten Feh lercode auszuwählen.

29. Fehlermanagementvorrichtung zur Verwendung in ei nem Prozesssteuersystem mit einer Moduleinheit und mehreren Steuermodulen, die kommunizierend mit der Mo duleinheit gekoppelt sind, um einen Prozess auszufüh ren, wobei die Vorrichtung folgendes umfasst:
eine Steuerung mit einem Speicher und einem Prozessor, der kommunizierend mit dem Speicher gekoppelt ist, wo bei die Steuerung dazu programmiert ist, zusammenge setzte Fehlercodes zur Bestimmung zu verwenden, ob der Prozess angehalten werden soll.

30. Vorrichtung nach Anspruch 29, dadurch gekennzeichnet, dass die Steuerung ferner zur Bestimmung programmiert ist, ob der Prozess auf Grundlage zusammengesetzter Fehler codes angehalten werden soll, die mit einem der Steu ermodule assoziiert sind, die aktuell durch die Modul einheit zur Ausführung des Prozesses benötigt werden.

31. Vorrichtung nach Anspruch 30, dadurch gekennzeichnet, dass die Steuerung ferner dazu programmiert ist, einen der zusammengesetzten Fehlercodes auszuwählen und den ei nen ausgewählten zusammengesetzten Fehlercode mit ei nem vorbestimmten Schwellwert zu vergleichen, um zu bestimmen, ob der Prozess angehalten werden soll.

32. Vorrichtung nach Anspruch 31, dadurch gekennzeichnet, dass die Steuerung ferner dazu programmiert ist, einen schlechtesten zusammengesetzten Fehlercode als den ei nen ausgewählten zusammengesetzten Fehlercode auszu wählen.

33. Prozesssteuersystem zur Ausführung eines Prozes ses, das folgendes umfasst:
mehrere Feldgeräte;
eine Steuerung, die kommunizierend mit den mehreren Feldgeräten gekoppelt ist und eine Moduleinheit um fasst, die zumindest einen Teil des Prozesses aus führt, wobei die Moduleinheit bewirkt, dass die Steue rung eine Gruppe von zusammengesetzten Fehlercodes verarbeitet, um zu bestimmen, ob der Prozess angehal ten werden soll.

34. Prozesssteuersystem nach Anspruch 33, dadurch gekennzeichnet, dass die Gruppe der zusammengesetzten Fehlercodes von meh reren Steuermodulen erzeugt wird.

35. Prozesssteuersystem nach Anspruch 34, dadurch gekennzeichnet, dass die mehreren Steuermodule in den mehreren Feldgeräten instanziiert sind.

36. Prozesssteuersystem nach Anspruch 34, dadurch gekennzeichnet, dass die mehreren Steuermodule in der Steuerung instanzi iert sind.

37. Prozesssteuersystem nach Anspruch 34, dadurch gekennzeichnet, dass jedes der Steuermodule eine Fehlerliste verwendet, um seinen entsprechenden zusammengesetzten Fehlercode zu erzeugen.

38. Prozesssteuersystem nach Anspruch 37, dadurch gekennzeichnet, dass die Liste der Fehler numerische Werte aufweist, die mit einem oder mehreren Fehlern assoziiert sind, und dass jedes der Feldgeräte die numerischen Werte in seiner entsprechenden Fehlerliste mathematisch ver knüpft, um seinen entsprechenden Fehlercode zu erzeu gen.

39. Prozesssteuersystem nach Anspruch 38, dadurch gekennzeichnet, dass jedes der Steuermodule die numerischen Werte in seiner entsprechende Fehlerliste durch Berechnung einer ge wichteten Summe der numerischen Werte mathematisch verknüpft.

40. Prozesssteuersystem nach Anspruch 33, dadurch gekennzeichnet, dass die Moduleinheit bewirkt, dass die Steuerung die Grup pe der zusammengesetzten Fehlercodes auf Grundlage ei ner laufenden Phase des Prozesses auswählt.

41. Prozesssteuersystem nach Anspruch 33, dadurch gekennzeichnet, dass jedes der Steuermodule automatisch seinen entsprechen den zusammengesetzten Fehlercode an die Steuerung sen det.

42. Prozesssteuersystem nach Anspruch 33, dadurch gekennzeichnet, dass die Steuerung die Gruppe der zusammengesetzten Fehler codes durch Auswählen eines schlechtesten Fehlercodes aus der Gruppe der zusammengesetzten Fehlercodes und durch Vergleichen der schlechtesten Fehlercodes mit einem vorbestimmten Schwellwert verarbeitet, der mit einer Bestimmung assoziiert ist, ob der Prozess angehalten werden soll.

43. Prozesssteuersystem nach Anspruch 42, dadurch gekennzeichnet, dass die Steuerung einen Fehlercode mit dem höchsten nume rischen Wert aus der Gruppe der zusammengesetzten Feh lercodes als den schlechtsten Fehlercode auswählt.