DE102006063100B3 - Prozessmodellidentifizierung in einem prozesssteuersystem - Google Patents

Abstract

Verfahren zur Steuerung eines Prozesssteuersystems mit einer Vielzahl von Steuerungsroutinen, wobei das Verfahren Folgendes umfasst:Erfassung von Daten zu Betriebsbedingungen während der Implementierung der Vielzahl von Steuerungsroutinen;Erkennen eines Ereignisses, das eine Prozessänderung angibt, in Verbindung mit einer Steuerungsroutine aus der Vielzahl von Steuerungsroutinen, die der Prozessänderung zugeordnet ist;Identifizieren eines Prozessmodells für die Steuerungsroutine, die der Prozessänderung zugeordnet ist; undSpeicherung von Daten, die das erzeugte Prozessmodell angeben, mit dem Aufbau einer Prozessmodellhistorie für die Steuerungsroutine, die der Prozessänderung zugeordnet ist.

Description

• TECHNISCHES GEBIET
• Die Erfindung betrifft allgemein Prozesssteuersysteme bzw. Prozesssteuerungssysteme und insbesondere die Identifizierung und Anwendung von Prozessmodellen in Prozesssteuersystemen.
• BESCHREIBUNG DES DIESBEZÜGLICHEN STANDS DER TECHNIK
• Prozesssteuersysteme wie z. B. verteilte oder skalierbare Prozesssteuersysteme, wie sie in der Chemie-, Erdöl- und weiteren Industrien verwendet werden, enthalten üblicherweise eine oder mehrere Prozesssteuerungen, die kommunikativ über analoge, digitale oder kombinierte analog-digitale Busleitungen an wenigstens einen Host oder eine Bediener-Workstation angeschlossen sind. Die Feldgeräte, die z. B. Ventile, Ventilpositionierer, Schalter und Transmitter (z. B. Temperatur-, Druck- und Durchflusssensoren) sein können, führen innerhalb des Verfahrens Funktionen wie das Öffnen und Schließen von Ventilen und die Messung von Verfahrensparametern aus. Die Prozesssteuerung empfängt Signale, die von den Feldgeräten vorgenommene Prozessmessungen und/oder sonstige Informationen in Zusammenhang mit den Feldgeräten wiedergeben, und sie verwendet diese Informationen zur Implementierung einer Steuerungsroutine und erzeugt anschließend Steuersignale, die über die Busleitungen zu den Feldgeräten übertragen werden, um den Prozessbetrieb zu steuern. Informationen von den Feldgeräten und der Steuerung werden üblicherweise für eine oder mehrere von der Bediener-Workstation ausgeführte Anwendungen verfügbar gemacht, um es einem Bediener zu ermöglichen, beliebige gewünschte Funktionen bezüglich des Verfahrens auszuführen, wie z. B. die Ansicht des aktuellen Prozessstatus, die Änderung des Prozessbetriebs usw.
• Einige Prozesssteuersysteme wie z. B. das von Fisher Rosemount Systems, Inc. mit Sitz in Austin (US-Bundesstaat Texas) vertriebene DeltaV®-System verwenden Funktionsblöcke oder als Module bezeichnete Gruppen von Funktionsblöcken, die in der Steuerung oder in unterschiedlichen Feldgeräten angeordnet sind, zur Ausführung von Steuerungsvorgängen. In diesen Fällen kann die Steuerung oder sonstige Einrichtung ein(en) oder mehrere Funktionsblöcke oder Module umfassen und ausführen, wobei jeder Funktionsblock bzw. jedes Modul Eingaben von anderen Funktionsblöcken (in der gleichen Einrichtung oder in unterschiedlichen Einrichtungen) empfängt und/oder dafür bereitstellt und bestimmte Prozessvorgänge ausführt, wie z. B. die Messung oder Erkennung eines Prozessparameters, die Steuerung einer Einrichtung oder die Ausführung eines Steuerungsvorgangs, wie z. B. die Implementierung einer Proportional/Integral/Derivative-(PID)-Steuerungsroutine. Die unterschiedlichen Funktionsblöcke und Module in einem Prozesssteuersystem sind allgemein für die Kommunikation untereinander konfiguriert (z. B. über einen Bus), um einen oder mehrere Prozessregelkreise zu bilden.
• Prozesssteuerungen sind üblicherweise zur Ausführung von unterschiedlichen Algorithmen, Subroutinen oder Regelkreisen (die alle Steuerungsroutinen sind) für jeden Regelkreis einer Anzahl von unterschiedlichen Regelkreisen programmiert, die in einem Prozess enthalten sind, wie z. B. Strömungsregelkreise, Temperaturregelkreise, Druckregelkreise usw. Allgemein ausgedrückt, enthält jeder dieser Regelkreise einen oder mehrere Eingangsblöcke wie z. B. einen Analogeingangs-(AI)-Funktionsblock, einen Einzelausgangs-Steuerungsblock, wie z. B. einen Proportional/Integral/Derivative-(PID)- oder einen Fuzzy-Logic-Steuerungsfunktionsblock, und einen Ausgangsblock wie z. B. einen Analogausgangs-(AO)-Funktionsblock.
• Steuerungsroutinen und die Funktionsblöcke, die derartige Routinen implementieren, wurden gemäß einer Anzahl von Steuerungsverfahren konfiguriert, einschließlich PID-Steuerungs-, Fuzzy-Logic-Steuerungs- und modellorientierten Verfahren wie z. B. einer Smith-Predictor- oder Model-Predictive-Control-(MPC)-Steuerung. Bei modellorientierten Steuerungsverfahren basieren die in den Routinen verwendeten Parameter zur Bestimmung der Regelungsreaktion mit geschlossener Rückführung auf Änderungen der behandelten oder gemessenen Störungen, die als Prozesseingaben dienen. Eine Darstellung dieser Prozessreaktion auf Änderungen bei Prozesseingaben kann als Prozessmodell charakterisiert werden. Beispielsweise kann ein parametrisiertes Prozessmodell erster Ordnung Werte für Proportionalbeiwert (Gain), Totzeit und Zeitkonstante des Prozesses angeben.
• Ein modellorientiertes Model-Predictive-Control-(MPC)-Verfahren umfasst eine Anzahl von Schritt- oder Impulsreaktionsmodellen, die zur Erfassung der dynamischen Beziehungen zwischen Prozesseingaben und -ausgaben entwickelt wurden. Bei MPC-Verfahren wird das Prozessmodell direkt zur Erzeugung der Steuerung eingesetzt. Bei Verwendung in Verbindung mit Prozessen, bei denen große Änderungen der Prozesstotzeit, der Prozessverzögerung usw. auftreten, muss die MPC-Steuerung unter Verwendung der Modelle automatisch regeneriert werden, um dem aktuellen Prozessstatus zu entsprechen. In solchen Fällen wurde dementsprechend bei jeder einzelnen aus einer Anzahl von Betriebsbedingungen ein Prozessmodell angegeben. Die Einführung von Mehrfachprozessmodellen und die erforderliche automatische Erzeugung der Steuerung zur Anpassung an den aktuellen Prozessstatus hat die Komplexität des Prozesssteuersystems in unerwünschter Weise erhöht.
• Prozessmodelle wurden auch zur Vorgabe von Einstellparametern von PID- und anderen Steuerungsschemen unter Verwendung adaptiver Steuerungsverfahren eingesetzt, wobei die Einstellung der PID- (oder der sonstigen) Steuerung im Allgemeinen infolge von Änderungen des Prozessmodells und einer vom Benutzer ausgewählten Einstellregel aktualisiert wird. Siehe hierzu z. B. die US-Patentveröffentlichung Nr. 2003/0195641 A1 mit dem Titel „State Based Adaptive Feedback Feedforward PID Controller“ und das US-Patent Nr. 6 577 908 B1 mit dem Titel „Adaptive Feedback/Feedforward PID Controller“, wobei die dort enthaltenen Offenbarungen in ihrer Gesamtheit ausdrücklich als Bestandteil dieser Anmeldung übernommen werden.
• Trotz des Versprechens einer verbesserten Steuerungsleistung war die Verwendung von adaptiven Steuerungsverfahren in den verfahrenstechnischen Industrien insofern eingeschränkt, als die Verfahren in der Praxis oft schwer zu implementieren waren. Auf praktischer Ebene war die Modellidentifizierung normalerweise Teil eines speziellen, spezifisch für die adaptive Steuerung entwickelten Funktionsblocks. Unglücklicherweise ist es oft schwierig, zu bestimmen, welche Prozessregelkreise aus der Implementierung der adaptiven Steuerung Nutzen ziehen, d. h. welche Schleifen für die adaptive Steuerungsfähigkeit ausgewählt werden sollen. Ein Grund hierfür betrifft die reine Anzahl (z. B. hunderte) von Regelkreisen und Instrumenten (z. B. tausende), die in einer typischen Anlage überwacht werden. Doch ungeachtet der Größe oder Komplexität der Anlage unterstützen konventionelle Prozesssteuersysteme normalerweise nicht die Erzeugung von Prozessmodellen für alle Regelkreise in der Anlage. Erschwert wird dies zudem dadurch, dass das zur Identifizierung neuer Prozessmodelle für alle Regelkreise erforderliche manuelle Testen möglicherweise nicht praktikabel ausgeführt werden kann. Beispielsweise kann das Testen die Anwendung von einer oder mehreren Störungen umfassen, die mit einem Online-Prozess nicht kompatibel sind.
• Im Betrieb haben adaptive Steuerungsverfahren eingeschränkte Diagnosefähigkeiten ergeben. Wenn die adaptiven Steuerungsschemen in der Prozesssteuerung selektiv praktisch eingesetzt werden, wird insbesondere die identifizierte Prozessreaktion im Allgemeinen nur zur Bestimmung der Einstellung des Regelkreises verwendet. Demzufolge kann das Prozesssteuersystem möglicherweise keine Angabe eines abnormen Zustands in dem Prozess oder der Gerätschaft bereitstellen, der/die die Beeinträchtigung der Steuerungsleistung verursacht.
• Die Druckschrift DE 103 41 762 A1 offenbart, dass adaptive und nicht adaptive Steuerungsroutinen nebeneinander verwendet werden. Die Druckschrift DE 100 48 360 A1 offenbart, dass Prozessmodelle für Steuerungsroutinen aufgrund erfasster Daten erzeugt und erfasste Daten und Prozessmodelle gespeichert werden.
• ZUSAMMENFASSUNG DER OFFENBARUNG
• Nach einem Aspekt der Offenbarung ist ein Verfahren sinnvoll zur Regelung eines Prozesssteuersystems mit einer Vielzahl von Regelkreisen. Das Verfahren umfasst die Implementierung einer Vielzahl von Steuerungsroutinen zur Steuerung des Betriebs der Vielzahl von Regelkreisen bzw. der Vielzahl von Steuerungsroutinen, wobei mindestens eine nicht adaptive Steuerungsroutine enthalten ist, die Daten zum Betriebszustand in Verbindung mit dem Betrieb jedes Regelkreises der Vielzahl von Regelkreisen erfasst und die aus den für jeden Regelkreis der Vielzahl von Regelkreisen erfassten jeweiligen Daten zum Betriebszustand für jeden Regelkreis der Vielzahl von Regelkreisen ein entsprechendes Prozessmodell identifiziert.
• In einigen Fällen umfasst das Verfahren ferner die Speicherung von Daten mit Angaben zu den jeweiligen identifizierten Prozessmodellen in einer dazugehörigen Prozessmodellhistorie für jeden Regelkreis der Vielzahl von Regelkreisen. Das Verfahren kann auch die Prüfung der Daten zum Betriebszustand umfassen, um eine Änderung darin zu erkennen, sowie das Triggern der Prozessmodellidentifizierung, wenn die Änderung erkannt worden ist.
• Bei einigen Ausführungsformen kann die Identifizierung als Reaktion auf einen Befehl des Benutzers zur Berechnung des Prozessmodells auf der Grundlage der erfassten Daten zum Betriebszustand ausgeführt werden. Die erfassten Daten zum Betriebszustand können dann eine Reaktion auf eine infolge des Befehls des Benutzers angewandte Änderung eines eingeführten Parameters angeben.
• Die Daten zum Betriebszustand können den Online-Betrieb eines über den Betrieb der Vielzahl von Regelkreisen gesteuerten Prozesses angeben.
• Das Verfahren kann weiter die Überwachung der jeweiligen für jeden Regelkreis identifizierten Prozessmodelle umfassen, um die Performance der Regelkreise zu bewerten. Alternativ oder zusätzlich dazu kann das Verfahren auch die Analyse der jeweiligen für jeden Regelkreis identifizierten Prozessmodelle umfassen, um zu bestimmen, welche Regelkreise ein adaptives Steuerungsschema verwenden sollen. Alternativ oder zusätzlich dazu kann das Verfahren ferner die Analyse der jeweiligen für jeden Regelkreis identifizierten Prozessmodelle umfassen, um eine Diagnose von Steuerungsproblemen vorzunehmen.
• Nach einem weiteren Aspekt der Offenbarung umfasst ein Verfahren zur Regelung eines Prozesssteuersystems mit einer Vielzahl von Steuerungsroutinen das Erfassen von Daten zum Betriebszustand während der Implementierung der Vielzahl von Steuerungsroutinen, wobei ein Ereignis erkannt wird, das eine Prozessänderung in Zusammenhang mit einer der Prozessänderung zugeordneten Steuerungsroutine der Vielzahl von Steuerungsroutinen angibt, und wobei ein Prozessmodell für die der Prozessänderung zugeordnete Steuerungsroutine angegeben wird, und wobei Daten mit Angaben zum erzeugten Prozessmodell bei der Entwicklung einer Prozessmodellhistorie für die der Prozessänderung zugeordnete Steuerungsroutine gespeichert werden.
• In einigen Fällen umfasst das Verfahren ferner die automatische Erfassung von Daten zum Identifizierungsschritt bei der Erkennung des Ereignisses.
• Das Verfahren kann auch die Identifizierung von entsprechenden Prozessmodellen für jede Steuerungsroutine der Vielzahl von Steuerungsroutinen umfassen. Die Vielzahl von Steuerungsroutinen kann eine Steuerungsroutine umfassen, die ein nicht adaptives Steuerungsschema implementiert.
• Figurenliste
• Zum besseren Verständnis der Offenbarung ist auf die folgende detaillierte Beschreibung und die beigefügten Figuren der Zeichnungen Bezug zu nehmen, wobei gleiche Kennziffern entsprechende Elemente in den Figuren identifizieren. Gezeigt wird Folgendes:
• 1 ist eine schematische Darstellung eines Prozesssteuersystems mit einer Steuerung, die mit einer oder mehreren Steuerungsroutinen nach einem Aspekt der Offenbarung konfiguriert ist.
• 2 ist eine schematische Darstellung der in 1 wiedergegebenen Steuerung gemäß einer Ausführungsform mit einer Modellidentifizierungsroutine in Kommunikation mit einer Anzahl von Funktionsblöcken.
• 3 ist eine schematische Darstellung der in 1 wiedergegebenen Steuerung gemäß einer Ausführungsform, wobei die Steuerung zur Modellidentifizierung unter Verwendung von Trend- oder anderen historischen Daten mit einer Workstation kommuniziert.
• 4 ist eine schematische Darstellung eines adaptiven Steuerungsfunktionsblocks der in 1 wiedergegebenen Steuerung gemäß einer Ausführungsform, wobei der adaptive Steuerungsfunktionsblock die Einstellung gemäß gespeicherter Modelle und Informationen zum Betriebszustand ändert.
• 5 ist eine schematische Darstellung eines adaptiven MPC-Funktionsblocks der in 1 wiedergegebenen Steuerung gemäß einer Ausführungsform, wobei der MPC-Funktionsblock einen bedarfsweisen Test der Modellidentifizierung implementiert.
• 6 ist eine schematische Darstellung der in 1 wiedergegebenen Steuerung gemäß einer Ausführungsform, wobei identifizierte Modelle in Zusammenhang mit historischen Ereignisinformationen in einer Datenbank gespeichert sind.
• 7 ist eine schematische Darstellung einer alternativen Ausführungsform des in 1 wiedergegebenen Prozesssteuersystems, wobei eine Workstation in Kommunikation mit einer Steuerung über einen OPC-Server oder eine andere Schnittstelle eine Modellidentifizierungsroutine implementiert.
• 8 ist eine schematische Darstellung einer Ausführungsform des in 1 wiedergegebenen Prozesssteuersystems, wobei eine Workstation eine beispielhafte Suite von Anwendungen implementiert, die zusammen eine Überwachung der Steuerungs-Performance und eine Umgebungsverwaltung mit zugeordneten Funktionalitäten wie u. a. Schleifen- und Modellanalyse, Diagnose, Einstellung und MPC- und adaptiver Steuerung bereitstellen.
• 9 ist eine vereinfachte Darstellung einer durch eine Ausführungsform der in 8 wiedergegebenen Workstation erzeugten beispielhaften Anzeigeoberfläche mit einer Anwendung zur Performance-Überwachung zur Bereitstellung von Übersichtsinformationen zur Steuerungs-Performance.
• 10 ist eine vereinfachte Darstellung einer durch eine Ausführungsform der in 8 wiedergegebenen Workstation erzeugten beispielhaften Anzeigeoberfläche mit einer Anwendung zur Performance-Überwachung zur Bereitstellung von Informationen zur Regelkreis-Performance für ein ausgewähltes System, einen Bereich oder eine andere Gruppe von Regelkreisen.
• 11 ist eine vereinfachte Darstellung einer durch eine Ausführungsform der in 8 wiedergegebenen Workstation erzeugten beispielhaften Anzeigeoberfläche mit einer Anwendung zur Performance-Überwachung zur Bereitstellung von Performance-Informationen für einen ausgewählten Regelkreis.
• 12 ist eine vereinfachte Darstellung einer durch eine Ausführungsform der in 8 wiedergegebenen Workstation erzeugten beispielhaften Anzeigeoberfläche mit einer Diagnose- oder sonstigen Analyseanwendung zur Überwachung und Verwaltung der Regelkreis-Performance, der Qualität des adaptiven Modells und anderer Diagnoseparameter in Bezug auf einen Regelkreis.
• 13 ist eine vereinfachte Darstellung einer durch eine Ausführungsform der in 8 wiedergegebenen Workstation erzeugten beispielhaften Anzeigeoberfläche mit einer Anwendung zur Konfiguration, Anpassung und Verwaltung der Modellidentifizierungsprozedur für einen Regelkreis.
• 14 ist eine vereinfachte Darstellung einer durch eine Ausführungsform der in 8 wiedergegebenen Workstation erzeugten beispielhaften Anzeigeoberfläche zur Darstellung von identifizierten Prozessmodellen für unterschiedliche Betriebsbedingungen, die durch die Eingabe eines Zustandsparameters angegeben werden.
• 15 und 16 sind jeweils vereinfachte Darstellungen von durch eine Ausführungsform der in 8 wiedergegebenen Workstation erzeugten beispielhaften Anzeigeoberflächen mit einer Einstellungsanwendung zur Unterstützung und Verwaltung der Verwendung von Prozessmodellen zur Einstellung von Steuerungsfunktionsblöcken, z. B. für die Implementierung von Fuzzy-Logic- oder MPC-Steuerungsschemen.
• Obwohl das offenbarte System und Verfahren Ausführungsformen in verschiedenen Ausgestaltungen haben kann, sind in den Zeichnungen (und in der folgenden Beschreibung) spezifische Ausführungsformen der Erfindung dargestellt, wobei gelten soll, dass die Offenbarung zur Veranschaulichung dienen soll und die Erfindung nicht auf die darin beschriebenen und dargestellten spezifischen Ausführungsformen beschränken soll.
• BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
• Hier offenbart wird ein Prozesssteuersystem und -verfahren, das einen Vorgang implementiert, der automatisch Prozessmodelle für Regelkreise im Prozesssteuersystem identifiziert, die nicht notwendigerweise zum aktuellen Zeitpunkt ein Prozessmodell für adaptive Steuerung verwenden. Die Prozessmodelle werden daher aus anderen Gründen als zur Implementierung einer adaptiven Steuerung (oder zusätzlich dazu) angelegt. Beispielsweise wird die Entscheidung darüber, bei welchen Regelkreisen eine adaptive Steuerung angewandt werden soll, durch die Bewertung der über das offenbarte Verfahren identifizierten Prozessmodelle vereinfacht.
• In einigen Fällen wird die Identifizierung von Prozessmodellen auf alle Regelkreise im Prozesssteuersystem erweitert. Auf diese Weise können für jeden Knoten des Prozesssteuersystems Prozessmodelle erzeugt werden. Doch ungeachtet des Umstands, ob für jeden Regelkreis oder Knoten in spezifischen Ausführungsformen des offenbarten Systems Prozessmodelle identifiziert werden, hat die Erweiterung der Prozessmodellidentifizierung auf nicht adaptive Regelkreise eine Reihe von Vorteilen, wie z. B. die bedarfsweise Steuerungseinstellung und die Überwachung und Diagnose abnormer Zustände.
• In einigen Fällen werden Prozesssteuerungsdaten erfasst, um eine Anzahl von Prozessmodellen für einen Regelkreis anzugeben und dadurch eine Historie von Prozessmodellen zu erzeugen. Die Prozessmodelldaten, die die Prozessmodellhistorie bilden, können während des, in Zusammenhang mit dem und infolge des täglichen Betriebs des Prozesses erzeugt werden. In diesen Fällen stellt die sich ergebende Prozessmodellhistorie eine Darstellung der gerade erfolgten Online-Performance des Regelkreises bereit. Spezielle Tests oder Testprozeduren sind dann nicht erforderlich.
• Wenn der Regelkreis ein adaptives Steuerungsschema implementiert (z. B. eine adaptive PID-Steuerung), kann die Prozessmodellhistorie angeben, ob die adaptive Steuerung für die aktuellen Betriebsbedingungen oder allgemeiner für den Regelkreis selbst geeignet ist. Umgekehrt kann die Prozessmodellhistorie für einen nicht adaptiven Regelkreis auch angeben, dass ein adaptives Steuerungsschema vorteilhaft sein kann.
• In bestimmten Fällen können die Prozessmodelle durch eine Routine identifiziert (d. h. erzeugt) werden, die in die die Steuerungsroutinen implementierende Prozesssteuerung eingebettet ist. Hierzu kann die Steuerung durch Prozessänderungen getriggert werden, um Prozesssteuerungsdaten zur Unterstützung der Erzeugung des/der Prozessmodells/Prozessmodelle zu speichern. Prozessänderungen oder andere Ereignisse, die als Trigger wirken, können eine Sollwertänderung, eine automatisch in die Steuerungsausgabe eingeführte Störung oder eine beliebige andere Änderung des offenen oder geschlossenen Regelkreises umfassen. Auf diese und andere Weisen kann eine Routine zur Prozessmodellidentifizierung kontinuierlich von der Steuerung (oder von anderen Elementen des Systems) implementiert werden, um die Prozesssteuerungsdaten im Verlauf des täglichen Betriebs zu erfassen. Weiter können die Prozessmodelle somit automatisch bei der Erkennung der Prozessänderung (oder eines anderen Trigger-Ereignisses) identifiziert werden, wobei alle Berechnungen im Hintergrund erfolgen, während der Prozess online bleibt.
• Nach der erfolgten Identifizierung und/oder Speicherung kann/können das/die Prozessmodell(e) analysiert, verarbeitet oder sonstwie verwendet werden, um eine Reihe von Prozesssteuerungsaufgaben zu unterstützen, die in Zusammenhang mit der Verwaltung des Prozesssteuersystems implementiert sind, einschließlich der Performance-Überwachung, der bedarfsweisen Einstellung, der Empfehlungen für Steuerungsalgorithmen, der Simulation der Regelkreisreaktion, der Prozessüberwachung, der Steuerungsdiagnose und der adaptiven Steuerung. Beispielsweise können die Prozessmodelle entsprechend der folgenden Beschreibung zur Berechnung eines modellorientierten Performance-Index für den Regelkreis, für den sie identifiziert worden sind, verwendet werden.
• Während die über das offenbarte Verfahren identifizierten Prozessmodelle auch als Basis für die Implementierung von modellorientierten Steuerungsschemen (z. B. einer adaptiven Steuerung) verwendet werden können, ist die Implementierung des offenbarten Verfahrens nicht auf einen bestimmten Typ eines Regelkreises, einer Prozesssteuerung, eines Prozesssteuersystems oder einer Prozesssteuerungs-Netzwerkarchitektur beschränkt. Zudem kann das offenbarte Verfahren durch eine Reihe von Elementen des Prozesssteuersystems entweder individuell oder in verteilter Weise und auf einer oder mehreren Ebenen (z. B. der Prozesssteuerungsebene, Regelkreisebene usw.) implementiert werden. Weiter ist das offenbarte Verfahren nicht auf einen bestimmten Prozessmodelltyp beschränkt, und es kann beispielsweise ein beliebiges parametrisiertes dynamisches Modell des Prozesses verwenden.
• Mit Bezug auf 1 umfasst ein Prozesssteuersystem 10 eine Prozesssteuerung 11, die mit einem Data Historian 12 und mit einer oder mehreren Host-Workstations oder Computern 13 verbunden ist (die ein beliebiger Typ von Personal Computern, Workstations usw. sein können), die jeweils einen Anzeigebildschirm 14 haben. Die Steuerung 11 ist über Eingangs-/Ausgangs-(I/O)-Karten 26 und 28 auch mit Feldgeräten 15-22 verbunden. Der Data Historian 12 kann eine Datenerfassungseinheit eines beliebigen gewünschten Typs sein, die einen Speicher eines beliebigen gewünschten Typs und beliebige gewünschte oder bereits bekannte Software, Hardware oder Firmware zur Datenspeicherung hat. Der Data Historian 12 kann (entsprechend der Darstellung in 1) von den Workstations 13 getrennt oder Teil einer dieser Workstations sein. Die Steuerung 11, die beispielsweise der von Fisher-Rosemount Systems, Inc. vertriebene DeltaV-Controller sein kann, ist beispielsweise über eine Ethernet-Verbindung oder ein beliebiges anderes gewünschtes Kommunikationsnetzwerk kommunikativ mit den Host-Computern 13 und dem Data Historian 12 verbunden. Die Steuerung 11 ist auch unter Verwendung beliebiger gewünschter Hardware und Software, die beispielsweise standardmäßigen 4-20-mA-Geräten und/oder einem beliebigen intelligenten Kommunikationsprotokoll wie z. B. dem FOUNDATION-Fieldbus-Protokoll, dem HART-Protokoll usw. zugeordnet ist, kommunikativ mit den Feldgeräten 15-22 verbunden.
• Die Feldgeräte 15-22 können Einrichtungen beliebigen Typs sein, wie z. B. Sensoren, Ventile, Transmitter, Positionierer usw., während die I/O-Karten 26 und 28 I/O-Einrichtungen beliebigen Typs sein können, die einem beliebigen gewünschten Kommunikations- oder Steuerungsprotokoll entsprechen. Bei der in 1 wiedergegebenen Ausführungsform sind die Feldgeräte 15-18 standardmäßige 4-20-mA-Geräte, die über analoge Leitungen mit der I/O-Karte 26 kommunizieren, während die Feldgeräte 19-22 intelligente Einrichtungen sind wie z. B. Fieldbus-Einrichtungen, die über einen digitalen Bus unter Verwendung von Fieldbus-Kommunikationsvorgängen mit der I/O-Karte 28 kommunizieren. Selbstverständlich könnten die Feldgeräte 15-22 beliebigen anderen gewünschten Standards oder Protokollen entsprechen, einschließlich beliebiger künftig zu entwickelnder Standards oder Protokolle.
• Die Steuerung 11 umfasst einen Prozessor 23, der eine oder mehrere Prozesssteuerungsroutinen (in einem Speicher 24 gespeichert) implementiert oder kontrolliert, wobei diese darin gespeicherte oder auf andere Weise zugeordnete Regelkreise enthalten können, und der mit den Einrichtungen 15-22, den Host-Computern 13 und dem Data Historian 12 kommuniziert, um einen Prozess auf eine beliebige gewünschte Weise zu steuern. Es wird darauf hingewiesen, dass bei beliebigen hier beschriebenen Steuerungsroutinen oder Modulen Teile davon bei Bedarf von unterschiedlichen Steuerungen oder anderen Einrichtungen implementiert oder ausgeführt werden können. Entsprechend können die hier beschriebenen, im Prozesssteuersystem 10 zu implementierenden Steuerungsroutinen oder Module eine beliebige Form annehmen, einschließlich Software, Firmware, Hardware usw. Zum Zweck dieser Offenbarung kann ein Prozesssteuermodul ein beliebiger Teil oder Abschnitt eines Prozesssteuersystems sein, einschließlich beispielsweise einer Routine, eines Elements oder eines Teils davon, der auf einem beliebigen computerlesbaren Medium gespeichert ist. Steuerungsroutinen, die Module oder beliebige Teile von Steuerungsprozeduren sein können wie z. B. Subroutinen, Teile einer Subroutine (wie Codezeilen) usw., können in einem beliebigen gewünschten Softwareformat implementiert sein, wie z. B. unter Verwendung von objektorientierter Programmierung, Ladder Logic, Ablaufsprache (SFC), Funktionsblockdiagrammen oder unter Verwendung einer beliebigen anderen Software-Programmiersprache oder eines beliebigen anderen Design-Paradigmas. Entsprechend können die Steuerungsroutinen in beispielsweise einem oder mehreren EPROMs, EEPROMs, anwendungsspezifischen integrierten Schaltungen (ASICs) oder beliebigen anderen Hardware- oder Firmware-Elementen fest codiert sein. Weiter können die Steuerungsroutinen unter Verwendung beliebiger Design-Tools entwickelt werden, einschließlich grafischer Design-Tools oder beliebiger anderer Arten von Software-/Hardware-/Firmware-Programmier- und Design-Tools. Die Steuerung 11 kann somit auf beliebige gewünschte Weise zur Implementierung einer Steuerungsstrategie oder Steuerungsroutine konfiguriert werden.
• Bei einigen Ausführungsformen implementiert die Steuerung 11 eine Steuerungsstrategie unter Verwendung von gemeinhin als Funktionsblöcke bezeichneten Elementen, wobei jeder Funktionsblock ein Objekt oder ein sonstiger Teil (z. B. eine Subroutine) einer Gesamtsteuerungsroutine ist und (über als Links bezeichnete Kommunikationsleitungen) in Verbindung mit anderen Funktionsblöcken arbeitet, um die Prozessregelkreise im Prozesssteuersystem 10 zu implementieren. Funktionsblöcke führen normalerweise eine Eingangsfunktion aus, wie z. B. die einem Transmitter, einem Sensor oder einer anderen Messeinrichtung für Prozessparameter zugeordnete Eingangsfunktion, oder eine Steuerungsfunktion, wie z. B. die einer Steuerungsroutine, welche PID-, Fuzzy-Logic-Steuerung usw. ausführt, zugeordnete Steuerungsfunktion, oder sie führen eine Ausgangsfunktion aus, die den Betrieb bestimmter Einrichtungen steuert, wie z. B. den Betrieb eines Ventils, um bestimmte physische Funktionen im Prozesssteuersystem 10 auszuführen. Selbstverständlich existieren hybride und andere Arten von Funktionsblöcken. Funktionsblöcke können von der Steuerung 11 gespeichert und ausgeführt werden, wobei dies typischerweise der Fall ist, wenn diese Funktionsblöcke für standardmäßige 4-20-mA-Einrichtungen und einige Typen intelligenter Feldgeräte wie z. B. HART-Feldgeräte verwendet oder diesen zugeordnet werden, oder sie können in den Feldgeräten selbst gespeichert und von ihnen implementiert werden, was bei Fieldbus-Geräten eintreten kann. Während die Beschreibung des Steuerungssystems hier unter Verwendung einer Funktionsblock-Steuerungsstrategie wiedergegeben ist, können die offenbarten Verfahren und das System auch unter Verwendung anderer Konventionen implementiert oder entwickelt werden, wie z. B. von Ladder Logic, Ablaufsprache (SFC) usw., oder unter Verwendung beliebiger anderer gewünschter Programmiersprachen oder Paradigmen.
• Entsprechend der Darstellung durch den in 1 wiedergegebenen aufgebrochenen Block 30 kann die Steuerung 11 eine Reihe von Einzelschleifen-Steuerungsroutinen umfassen, die als Routinen 32 und 34 dargestellt sind, und sie kann bei Bedarf einen oder mehrere erweiterte Regelkreise implementieren, die als Regelkreis 36 dargestellt sind. Jeder derartige Regelkreis wird üblicherweise als Steuerungsmodul bezeichnet. Die Einzelschleifen-Steuerungsroutinen 32 und 34 sind so dargestellt, dass sie eine Einzelschleifenregelung unter Verwendung eines Fuzzy-Logic-Steuerungsblocks mit Einzeleingang und Einzelausgang und eines PID-Blocks mit Einzeleingang und Einzelausgang ausführen, die jeweils mit entsprechenden Analogeingangs-(AI)- bzw. Analogausgangs-(AO)-Funktionsblöcken verbunden sind, welche Prozesssteuerungseinrichtungen wie z. B. Ventilen, Messeinrichtungen wie Temperatur- und Druck-Transmittern oder beliebigen anderen Einrichtungen im Prozesssteuersystem 10 zugeordnet sein können. Der erweiterte Regelkreis 36 ist so dargestellt, dass er einen erweiterten Steuerungsblock 38 mit Eingängen umfasst, die kommunikativ mit einem oder mehreren AI-Funktionsblöcken verbunden sind, sowie mit Ausgängen, die kommunikativ mit einem oder mehreren AO-Funktionsblöcken verbunden sind, obwohl die Eingänge und Ausgänge des erweiterten Steuerungsblocks 38 mit beliebigen anderen gewünschten Funktionsblöcken oder Steuerungselementen verbunden sein können, um andere Arten von Eingaben zu empfangen und andere Arten von Steuerungsausgaben bereitzustellen. Der erweiterte Steuerungsblock 38 kann ein beliebiger Typ eines Model-Predictive-Control-(MPC)-Blocks, eines Modellier- oder Steuerungsblocks für neuronale Netzwerke, eines Fuzzy-Logic-Steuerungsblocks mit mehreren Variablen, eines Echtzeit-Optimierblocks usw. sein. Es ist ersichtlich, dass die in 1 wiedergegebenen Funktionsblöcke einschließlich des erweiterten Steuerungsblocks 38 durch die Steuerung 11 ausgeführt werden oder alternativ dazu in beliebigen anderen Verarbeitungseinrichtungen angeordnet sein und von ihnen ausgeführt werden können, wie z. B. in einer der Workstations 13 oder auch in einem der Feldgeräte 19-22.
• Mit Bezug auf 2 kann die Steuerung 11 eine beliebige Anzahl von Steuerungsmodulen 50, 52 und 54 haben, die dazugehörige Steuerungsroutinen definieren und implementieren, um den Online-Prozess zu steuern. Somit können die Steuerungsmodule 50, 52 und 54 in Verbindung mit einer von einem Modul 56 gesteuerten Betriebsumgebung oder einem Modus implementiert und allgemein der normalen, geplanten bzw. planmäßigen Prozesssteuerung zugeordnet sein. Entsprechend der vorstehenden Beschreibung kann jedes Steuerungsmodul 50, 52 und 54 eine beliebige Anzahl von Funktionsblöcken einschließlich Steuerungsfunktionsblöcken haben.
• Gemäß einigen Ausführungsformen des offenbarten Verfahrens werden Parameterwerte und andere Daten zum Betriebszustand von den Steuerungsmodulen 50, 52 und 54 zu einer Datenerfassungsfunktion 58 einer Routine oder eines Moduls 60 zur Modellidentifizierung geleitet. Allgemein ausgedrückt, werden die Parameterwerte und die anderen Daten zum Betriebszustand während der Ausführung der Steuerungsmodule 50, 52 und 54 und ihrer Funktionsblöcke verfügbar gemacht (oder auf andere Weise kommuniziert). Da diese Ausführung während der geplanten Prozesssteuerungsaktivitäten im Wesentlichen kontinuierlich ist, kann auch die Kommunikation der Parameterwerte und der anderen Daten zum Betriebszustand kontinuierlich sein.
• Wie die Funktionsblöcke kann auch die Datenerfassungsfunktion 58, ohne dass dies zwingend erforderlich wäre, in objektorientierter Weise als Objekt(e) (oder als Objektentität) implementiert sein. Ungeachtet ihrer Struktur kann die Datenerfassungsfunktion 58 eine oder mehrere Routinen umfassen, die die bei der Datenerfassung zu implementierenden Prozeduren definieren, einschließlich beliebiger Datenbehandlungsprozeduren. Die Routinen der Datenerfassungsfunktion 58 können somit die Speicherung der erfassten Daten beispielsweise in einem oder mehreren Registern 62 oder anderen Speichern koordinieren, unterstützen oder implementieren. Die von der Datenerfassungsfunktion 58 ausgeführten Prozeduren können die Bestimmung einschließen, wann die Daten entsprechend der folgenden Beschreibung von den Steuerungsmodulen 50, 52 und 54 erfasst werden sollen.
• Allgemeiner ausgedrückt, kann die Datenerfassungsfunktion 58 eine oder mehrere Routinen zur Unterstützung der automatischen Erfassung, Sammlung, Eingabe oder sonstigen Behandlung der Parameter und anderen Daten zum Betriebszustand umfassen. Im Umfang der von der Datenerfassungsfunktion 58 implementierten automatischen Erfassung oder sonstigen Behandlung der Parameter und Daten werden das Modul 56, die Steuerungsmodule 50, 52 und 54 und beliebige ihrer Steuerungsblöcke mit geringeren Rechenanforderungen belegt. Infolge dieser Trennung der Modellidentifizierungsprozedur von den Steuerungsfunktionsblöcken bleiben die Anforderungen an den Funktionsblockspeicher und die Ausführung ungeachtet des Umstands, ob die Modellidentifizierung aktiviert oder deaktiviert ist, gleich. Ferner wird die Anzahl der Parameter und der zugeordneten Speicheranforderungen, die für die Unterstützung der Adaptation (d. h. die adaptive Steuerung) hinzugefügt werden, minimiert.
• Die Trennung der Module 56 und 60 ermöglicht einigen Ausführungsformen auch die Bereitstellung einer Option zur Deaktivierung des Modellidentifizierungsmoduls 60 und somit der Datenerfassungsfunktion 58. Die Deaktivierung der Modellidentifizierung kann beispielsweise sinnvoll sein, wenn ermittelt wird, dass die Steuerung 11 unzureichende Speicherkapazität oder Zeit für die Berechnungen und anderen Verarbeitungsvorgänge hat. In diesem Zusammenhang kann die Verwendung der identifizierten Modelle zur Bereitstellung der adaptiven Steuerung auch auf der Ebene einer Schleife, eines Bereichs, eines Systems oder einer Steuerung aktiviert oder deaktiviert werden.
• Separate Modellidentifizierungsfunktionalität unterstützt auch die Koordinierung von Änderungen der Prozesseingaben. Diese Koordinierung wird ermöglicht, da die Modellidentifizierung in der Steuerung in einem Prozess zentralisiert ist. Wenn beispielsweise keine Sollwertänderungen vorgenommen werden, kann das Modellidentifizierungsmodul 60 (oder ein anderes Element oder eine andere Routine) automatisch Änderungen in die Steuerungsausgabe eingeben.
• Diese Änderungen können so koordiniert werden, dass die Auswirkungen auf den Prozessbetrieb minimiert werden. Diese Änderungen können somit im Zeitverlauf verteilt werden.
• Separate Modellidentifizierung bedeutet auch, dass die Datenverarbeitung für die Modellidentifizierung in der unbelegten oder deaktivierten Zeit der Steuerung 11 oder während einer beliebigen anderen von der Steuerung 11 als geeignet betrachteten Zeit ausgeführt werden kann. Demzufolge verhindert die Implementierung der Modellidentifizierungsverarbeitung die negative Beeinflussung der Funktionalität der geplanten Steuerung, die beispielsweise vom Modul 56 bereitgestellt wird. Infolgedessen kann das Modellidentifizierungsmodul 60 bei einigen Ausführungsformen von der Steuerung 11 im Hintergrund implementiert werden, während der Prozess online ist, sowie zu strategisch vorteilhaften Zeitpunkten während der geplanten Steuerung und anderen von anderen Modulen oder Komponenten der Steuerung 11 vorgenommenen Aktivitäten.
• Bei alternativen Ausführungsformen kann die Funktionalität der Modellidentifizierung in die Steuerungsfunktionsblöcke selbst integriert sein.
• Bei einigen Ausführungsformen werden die Parameter und anderen Daten von den Steuerungsmodulen 50, 52 und 54 automatisch zur Datenerfassungsfunktion 58 geleitet, wenn ein Steuerungsblock ausgeführt wird. In diesem Zusammenhang kann das Datenerfassungsmodul 58 kontinuierlich implementiert werden, um die Datenerfassungsprozedur jederzeit während des Prozessbetriebs zu unterstützen. Während der Zeiten, in denen die Ausführung der Steuerung nicht geplant ist, kann die Datenerfassungsfunktion 58 dann die erfassten Daten prüfen, um zu bestimmen, ob ein Prozessmodell erzeugt (d. h. angelegt oder identifiziert) werden soll. Bei alternativen Ausführungsformen kann die Steuerung 11 die erfassten Daten periodisch oder auf eine andere geplante Weise prüfen oder auf andere Weise verarbeiten. Bei weiteren alternativen Ausführungsformen kann die Datenerfassungsfunktion 58 selbstverständlich nicht durch die Steuerung 11 oder als Teil davon implementiert sein, um beispielsweise die Rechenanforderungen zu minimieren, oder aus einem beliebigen anderen gewünschten Grund. Weitere Einzelheiten zu Beispielen, bei denen diese Verarbeitung möglicherweise nicht in die Steuerung 11 eingebettet ist, sind im Folgenden in Zusammenhang mit Ausführungsformen erläutert, bei denen das offenbarte Verfahren ein bereits bestehendes Prozesssteuersystem überlagert (oder auf sonstige Weise darin integriert ist).
• Die von der Datenerfassungsfunktion 58 erfassten Daten können allgemein Werte für die Prozesseingaben und -ausgaben oder den Betriebssollwert für einen bestimmten von der Steuerung 11 (oder allgemeiner ausgedrückt vom Prozesssteuersystem 10) implementierten Regelkreis enthalten. Für jeden dieser Parameter werden Werte erfasst und über einen Zeitraum gespeichert, der vor einem Trigger-Ereignis beginnt und bis zum Erreichen eines stationären Zustands andauert. In einigen Fällen kann das Trigger-Ereignis die Erkennung von beispielsweise einer Änderung der Prozesseingabe oder des Sollwerts durch die Datenerfassungsfunktion 58 einbeziehen.
• In einigen Fällen kann die Definition, was ein Trigger-Ereignis darstellt, vom Betriebsmodus des Regelkreises abhängen. Wenn sich ein Regelkreis in einem „automatischen“ Betriebsmodus befindet, passt die Schleife kontinuierlich die Steuerungsausgabe an (d. h. die manipulierte Prozesseingabe), um eine Prozessausgabe (d. h. den geregelten Parameter der Schleife) auf einem vom Bediener vorgegebenen Sollwert zu halten. Im automatischen Modus bildet eine Sollwertänderung somit einen Trigger für die Analyse der Änderung bei Prozesseingaben und -ausgaben und damit für die Entwicklung eines Modells. Wenn der Bediener den Sollwert nie (oder selten) ändert und die Schleife im automatischen Modus bleibt, kann eine geringfügige Änderung in die Steuerungsausgabe eingeführt werden, sodass es einen Trigger für die Erzeugung eines Modells gibt.
• Wenn sich die Schleife in einem „manuellen“ Modus befindet, wird die Steuerungsausgabe vom Bediener vorgegeben, d. h. dass der Steueralgorithmus nicht die Ausgabe anpasst. Beim manuellen Modus bildet eine vom Bediener eingeführte Änderung der Ausgabe somit einen Trigger für die Analyse der Prozesseingaben und - ausgaben zum Erhalt eines Modells.
• Die drei vorstehend beschriebenen Trigger-Ereignisse können für die Entwicklung von Rückkopplungs-(Feedback)-Modellen verwendet werden. Bei der Vorkopplungs-(Feedforward)-Modellidentifizierung kann das Trigger-Ereignis eine Änderung des Vorkopplungs-Eingabewerts sein.
• Nach dem Erkennen des Trigger-Ereignisses kommunizieren die Module 56 und 58 auf beliebige gewünschte Weise, um die Datenerfassung zu unterstützen. Bei einigen Ausführungsformen wird die Datenerfassung durch das Modul 56 erleichtert, das auch die Erkennung eines Trigger-Ereignisses angeben kann. Insbesondere können die durch die Steuerungsmodule 50, 52 und 54 implementierten Regelkreise kontinuierlich den Zugriff auf die Daten bereitstellen oder die Daten auf andere Weise verfügbar machen. Demzufolge können in einem Zeitraum vor dem Trigger-Ereignis erfasste Daten ebenfalls zur Bestimmung des Prozessmodells analysiert werden. Beispielsweise kann ein PID-Regelkreis, für den Daten erfasst werden, den Zugriff auf die aktuellen Datenwerte für die Prozessvariable bereitstellen, die bei der Ausführung des Blocks verwendet wird (z. B. PV), sowie für den Ausgabewert des Blocks (z. B. OUT), den Vorkopplungs-Steuerungseingabewert (z. B. FF_VAL), den Sollwert und einen oder mehrere beliebige Parameter, die den Betriebsmodus des Regelkreises angeben. Alternativ oder zusätzlich dazu kann das Modellidentifizierungsmodul 60 einen oder mehrere Konfigurationslistenblöcke 64 enthalten, die bestimmen, welche Parameter erfasst werden müssen. Zu diesem Zweck kann der Konfigurationslistenblock 64 einen Datenspeicher oder einen anderen Speichermechanismus für die Listendaten umfassen. Zusammen mit den identifizierten Parametern kann eine Liste oder sonstige Identifizierung der Steuerungsblöcke oder - module gespeichert werden, für die die Modelle erzeugt werden sollen.
• Nach einer bestimmten Zeit im Anschluss an die Datenerfassung in Zusammenhang mit einem Trigger-Ereignis kann das Modellidentifizierungsmodul 60 einen Modellidentifizierungsalgorithmus oder eine Berechnungsroutine 66 implementieren. Die Modellberechnungsroutine 66 kann zusätzlich zur reinen Ausführung der Berechnungen auch die berechneten Modelle analysieren. Diese Analyse kann eine Prozess- und/oder Steuerungsdiagnose umfassen, um unter anderem die Qualität des Modells zu bestimmen. Die berechneten Modelle können anschließend zu einem Speicher oder zu einem anderen Block 68 weitergeleitet werden, der die letzten identifizierten Modelle für jeden Regelkreis aufnimmt. In einigen Fällen kann ein Regelkreis zwei gespeicherte Modelle haben, um beispielsweise sowohl die Rückkopplungssteuerung als auch die Vorkopplungssteuerung zu unterstützen. Entsprechend der Darstellung in 2 werden die berechneten Modelle nach der Modelldiagnose der Routine 66 und in Abhängigkeit von der dabei bestimmten Qualität des Modells zum Bock 68 geleitet.
• Die Qualität des Modells kann auch ausschlaggebend dafür sein, ob das Modell zu den Steuerungsfunktionsblöcken der Steuerungsmodule 50, 52 und 54 weitergeleitet wird. Bei der in 2 wiedergegebenen beispielhaften Ausführungsform umfasst jedes der Steuerungsmodule 50, 52 und 54 mindestens einen Regelkreis mit adaptiver Steuerung, und es empfängt dementsprechend wie in der Darstellung gezeigt Prozessmodelle von der Modellidentifizierungsroutine 60. Die berechneten und auf andere Weise vom offenbarten Verfahren identifizierten Modelle können jedoch auf der Grundlage der wie vorstehend erwähnt vom Block 66 bestimmten Qualität des Modells und in einigen Fällen auf der Grundlage des Betriebszustands des Steuerungsfunktionsblocks, der das neue Modell empfängt, verarbeitet und bereitgestellt werden.
• Mit Bezug auf 3 kann ein Benutzer einer der Workstations 13 die Erzeugung eines Prozessmodells initiieren, indem er Echtzeit- oder historische Daten auswählt, die über eine Einstellungs- bzw. Tuning- oder sonstige Anwendung 70, die auf der Workstation 13 implementiert ist, bereitgestellt werden. Eine derartige vom Benutzer initiierte Prozessmodellerzeugung kann zusätzlich zu der in Verbindung mit 2 beschriebenen Verarbeitung erfolgen. So umfasst bei der in 3 wiedergegebenen beispielhaften Ausführungsform die Steuerung 11, zu der das von der Einstellungsanwendung 70 erzeugte Modell ebenfalls weitergeleitet wird, die Modellidentifizierungsroutine 60 und deren Bestandteile, d. h. die Datenerfassungsfunktion 58, die Modellberechnungsroutine 66 usw.
• Neben der Quelle der Parameterwerte und anderer Daten zum Betriebszustand, die zur Erzeugung des Prozessmodells verwendet werden, kann die Workstation 13 auch die gleichen oder ähnliche Schritte für die Erzeugung des Prozessmodells implementieren. Beispielsweise kann die Workstation 13 ein Modellberechnungs- und Diagnosemodul oder einen Block 72 ähnlich dem Block 66 der Steuerung 11 umfassen. Der Modellberechnungsblock 72 kann auf entsprechende Weise vor der Weiterleitung des Blocks an die Steuerung 11 und an den Speicherblock 68 wie dargestellt die Qualität und andere Aspekte des erzeugten Blocks bestimmen.
• Bei einigen Ausführungsformen kann die Workstation 13 zusätzliche oder alternative Anwendungen haben, die ähnliche Funktionalität bereitstellen. In einem Fall kann die andere Anwendung eine oder mehrere Anzeigeschnittstellen bereitstellen, die die Analyse und/oder Inspektion der über die offenbarten Verfahren identifizierten Prozessmodelle unterstützen. Weitere Informationen zu dieser Anwendung sind im Folgenden wiedergegeben. In Verbindung mit der Erzeugung der zusätzlichen Prozessmodelle können diese Workstation-Anwendungen jedoch ein Trendfenster oder eine Trend-Anzeigeschnittstelle erzeugen, die eine Möglichkeit bereitstellt, Prozessdaten zur Verwendung bei der Modellerzeugung auszuwählen. Durch die Verwendung dieser Trendfenster oder anderen Schnittstellen kann ein Benutzer die Daten einschließlich des Zeitfensters auswählen. In diesen Fällen kann die Zeit bis zum stationären Zustand dementsprechend über das vom Benutzer gewählte Zeitfenster bestimmt werden. Alternative Ausführungsformen können andere Mechanismen zur manuellen oder automatischen Auswahl des Zeitfensters bereitstellen.
• Der Einsatz des offenbarten Verfahrens ist nicht auf eine in der Steuerung 11 oder in der Workstation 13 des Prozesssteuersystems 10 angeordnete Modellidentifizierungsroutine beschränkt. Allgemeiner ausgedrückt, können die hier beschriebenen Modellidentifizierungsprozeduren entweder individuell oder in verteilter Weise in anderen Einrichtungen oder Systemen implementiert werden, wobei unterschiedliche Grade des Zusammenwirkens und/der Kommunikation mit den Regelkreisen vorliegen, aus denen die zugrunde liegenden Parameter oder Daten erfasst werden. In einigen Fällen können die Modellidentifizierungsprozeduren beispielsweise auf remote Weise und/oder durch ein System implementiert werden, das über eine OPC- oder eine andere Schnittstelle ein Prozesssteuersystem überlagert.
• Entsprechend der vorstehenden Beschreibung ist der Einsatz des offenbarten Verfahrens nicht auf Systeme beschränkt, die adaptive Steuerungsroutinen implementieren. Die Identifizierung von Prozessmodellen über die offenbarten Verfahren kann jedoch bei Bedarf zur Unterstützung derartiger Routinen verwendet werden.
• Wie in 4 dargestellt ist, kann ein adaptiver Steuerungsfunktionsblock 74 zur Verwendung in Verbindung mit dem offenbarten Verfahren einen oder mehrere Datenspeicher oder andere Speichermechanismen 76 umfassen, um eine vorgegebene Anzahl von Prozessmodellen (z. B. fünf), die wie vorstehend beschrieben identifiziert worden sind, zu sichern oder zu speichern. Im Betrieb kann dann eines der im Speicher 76 gespeicherten Prozessmodelle über einen Logikblock 78 in Abhängigkeit von einem oder mehreren Parametern für die Verwendung ausgewählt werden. Bei der in 4 wiedergegebenen beispielhaften Ausführungsform wählt der Block 78 das Prozessmodell auf der Grundlage eines ausgewählten oder auf sonstige Weise bestimmten Prozesszustandsparameters aus, der über einen Eingang 80 bereitgestellt wird. Zwei weitere Parameter 82 und 84 können bei der Bestimmung ebenfalls berücksichtigt werden, und sie können Rückkopplungs- und/oder Vorkopplungsregeln bzw. einer Einstellung entsprechen, die die Anpassung des Betriebszustands an veränderliche Bedingungen ermöglicht.
• Die Prozessmodelle für den Funktionsblock 74 können, müssen aber nicht, Betriebsbereichen zugeordnet sein (z. B., wie dargestellt, Region 1, Region 2 usw.). Die Prozessmodelle können entsprechend dem Steuerungsschema des Funktionsblocks auch paarweise identifiziert werden. In diesem beispielhaften Fall bestimmt jede Region zwei Prozessmodelle zur Unterstützung sowohl der Rückkopplungs-(FB)- als auch der Vorkopplungs-(FF)-Verarbeitung. Bei Auswahl der Region kann das Paar der Rückkopplungs- und Vorkopplungsmodelle vom Block 78 verwendet werden, um Rückkopplungs- bzw. Vorkopplungs-Einstellparameter zu berechnen. In dem in 4 wiedergegebenen beispielhaften Fall werden die Vorkopplungs-Einstellparameter für einen dynamischen Kompensationsblock 88 bereitgestellt, der auch auf einen Vorkopplungs-Steuerungseingangswert (z. B. FF_VAL) z. B. für Totzeit und dynamische Lead-Lag-Kompensation reagiert. Die Ergebnisse der dynamischen Kompensation können zusammen mit den Rückkopplungs-Einstellparametern zu einem Block oder einer Routine 88 weitergeleitet werden, die die Implementierung der Steuerungsalgorithmen für den Funktionsblock übernimmt. In diesem Fall ändern die Rückkopplungs- und Vorkopplungsparameter PID- und Fuzzy-Logic-Algorithmen, doch beliebige Steuerungsschemen oder Kombinationen von Steuerungsschemen können verwendet werden.
• Der Funktionsblock 74 umfasst auch einen Block oder eine Routine 90 zur Unterstützung bedarfsweiser Änderungen der Regelkreiseinstellung. Hierzu kann der Block 90 auf einen Befehl des Benutzers reagieren, der über die Steuerung 11, die Workstation 13 oder ein beliebiges anderes Element des Prozesssteuersystems 10 oder einer damit kommunizierenden Einrichtung eingegeben wird. Allgemein kann das Modell, das für den Regelkreis automatisch identifiziert worden ist, bedarfsweise mit einer ausgewählten Einstellregel zur Vorgabe der Regelkreiseinstellung verwendet werden. Falls zuvor kein Modell identifiziert worden ist, kann ein benutzerseitiger Befehl eine Relaisoszillation oder ein anderes Verfahren zum Einführen von Änderungen in die Steuerungsausgabe initiieren. Das entstehende Prozessmodell, das aus der Reaktion des Prozesses auf die Änderung der Steuerungsausgabe entwickelt wird, kann anschließend mit einer ausgewählten Einstellregel verwendet werden, um die Regelkreiseinstellung vorzugeben oder um Einstellempfehlungen bereitzustellen.
• In einigen Fällen können die über den Block 90 oder infolge eines Trigger-Ereignisses (z. B. eine Änderung des Sollwerts oder eines anderen Parameterwerts) erzeugten Prozessmodelle vor dem Download zur Steuerung 11 oder zum Funktionsblock 74 zunächst zur Betrachtung verbleiben. Derartige Modelle können beispielsweise als „nicht freigegebene Modelle“ klassifiziert werden, bis die Analyse über eine Benutzerschnittstelle die Freigabe für die Implementierung geliefert hat. Bei einigen Ausführungsformen kann diese Freigabe alternativ oder zusätzlich dazu automatisch über Diagnose- oder andere Funktionalitäten in der Steuerung 11 oder in der Workstation 13 bereitgestellt werden.
• 5 zeigt eine Grundstruktur eines adaptiven Blocks in Zusammenhang mit dem adaptiven MPC-Steuerungsblock 92, wobei auch eine Anzahl unterschiedlicher Betriebsbereiche (Regionen) unterstützt wird. In diesem Zusammenhang kann wiederum eine Vielzahl von Prozessmodellen, die über die Modellidentifizierungsroutine 60 identifiziert worden sind, wie dargestellt zu einem Datenspeicher oder Speicher 94 (ähnlich dem in 4 wiedergegebenen Speicher 76) weitergeleitet werden, doch die Modellparameter können vor der Implementierung im Funktionsblock 92 durch eine MPC-Steuerungserzeugungsroutine 96 verarbeitet werden. Insbesondere kann die Routine 96 auf der Grundlage der identifizierten Modelle eine entsprechende MPC-Steuerung zur Speicherung in einem Speicher 98 erzeugen. Ein Logikblock 100 kann anschließend auf der Grundlage von Änderungen eines Zustandsparameters und anderer über Eingänge oder Speicher 102, 104 und 106 wie dargestellt bereitgestellter Parameter die Modelle auswählen bzw. wechseln, die zur Erzeugung der MPC-Steuerung verwendet werden sollen.
• Die dem ausgewählten Prozessmodell zugeordnete MPC-Steuerung kann anschließend für einen MPC-Steuerungsblock 108 zur Implementierung im Online-Prozess bereitgestellt werden. Der MPC-Steuerungsblock 108 kann das automatisierte bedarfsweise Testen der ausgewählten MPC-Steuerung unterstützen, das durch die Einführung einer Störeingabe 110 oder bei Bedarf auf andere Weise initiiert werden kann.
• In einigen Fällen unterstützen die in 4 und 5 wiedergegebenen beispielhaften adaptiven Steuerungsfunktionsblöcke (sowie andere Blöcke zur Verwendung mit dem offenbarten Verfahren) allgemein drei Betriebsmodi: einen Lernmodus, einen Planungsmodus und einen adaptiven Modus. Im Lernmodus können Prozessmodelle erfasst werden, die aber nicht automatisch zur Bestimmung der Regelkreiseinstellung verwendet werden. Im Planungsmodus können neue Prozessmodelle erfasst werden, und die freigegebenen Modelle werden automatisch zur Bestimmung der Parameter für die Regelkreiseinstellung verwendet. Im Fall eines adaptiven MPC-Blocks werden diese freigegebenen und angewandten Modelle dann entsprechend dem aktuellen Betriebsbereich bei der Steuerungserzeugung verwendet, da die Steuerungen automatisch mit dem aktuellen Betriebsbereich wechseln. Im adaptiven Modus werden Prozessmodelle erzeugt, automatisch freigegeben und anschließend automatisch zur Bestimmung der Parameter der Regelkreiseinstellung verwendet. Während die standardmäßig vorgegebene Einstellung für jeden Funktionsblock der Lernmodus sein kann, können die Anzeigeschnittstellen, die beispielsweise über eine der in den Workstations 13 implementierten Anwendungen bereitgestellt sein können, bei Bedarf eine Möglichkeit der Einstellung bereitstellen.
• Mit Bezug auf 6 stellen eine oder mehrere durch die Workstations 13 implementierte Anwendungen die Performance-Überwachung, die Analyse, die Verwaltung und die diesbezüglichen Funktionalitäten für die Regelkreise und die über das offenbarte Verfahren identifizierten Prozessmodelle bereit. Beispielsweise können die Funktionen zur Performance-Überwachung die Erzeugung einer Prozessmodellhistorie einschließen, in der zur späteren Verwendung oder Analyse Daten eingegeben werden, die Angaben zu den identifizierten Prozessmodellen liefern. Weitere Einzelheiten bezüglich der Erzeugung und Verwendung einer Prozessmodellhistorie sind im Folgenden wiedergegeben. Auf einer Ebene können die Historiendaten die Prozessmodellparameter angeben (z. B. Totzeit, Zeitkonstante und Proportionalbeiwert (Gain)), die jedes durch die offenbarten Verfahren identifizierte Prozessmodell vollständig definieren. Unter Zugrundelegung dieser historischen Daten kann eine Reihe von Analysen bezüglich des Regelkreises, seiner Einstellung, des Steuerungsschemas (z. B. adaptiv oder nicht adaptiv) usw. durchgeführt werden.
• Bei einigen Ausführungsformen ist ein Aspekt der Prozessmodellhistorie auf die Erzeugung einer Ereignischronik für die identifizierten Prozessmodelle gerichtet. Immer wenn ein Prozessmodell entweder automatisch in der Steuerung 11 (2) oder bedarfsweise aus Echtzeit- oder historischen Daten (3) identifiziert wird, kann die Modellidentifizierungsroutine 60 insbesondere einen Hinweis (oder eine andere Meldung) an ein Ereignischronik- oder Tracking-Modul 112 senden. Das Ereignischronikmodul 112 reagiert auf den Hinweis mit der Erzeugung von Daten, die die Zeit und das Datum der Modellidentifizierung neben beliebigen anderen Daten angeben, um die Zuordnung des Modells zu dem bestimmten Regelkreis, der Einrichtung, dem Anlagenbereich usw. zu ermöglichen. Bei der in 6 wiedergegebenen beispielhaften Ausführungsform enthalten die für jedes Ereignis gespeicherten Daten einen Tag-Namen für die dem Knoten oder Regelkreis zugeordnete Einrichtung, einen Datums-/Zeitstempel, einen Modelltyp (z. B. über die Identifizierung von Parametern wie Totzeit, Zeitkonstante und Proportionalbeiwert (Gain)), einen Regelkreistyp (z. B. Funktionsblock), eine Anlagenbereichsnummer, eine Einstellregel und eine Diagnoseangabe für die Steuerungs-Performance. Die vorstehenden (oder andere) Daten können als Teil der Prozessmodellhistorie in einer Datenbank 114 gespeichert werden, nachdem sie von einer Anwendung 116 verarbeitet worden sind, die beispielsweise eines oder mehrere Elemente zur Datenmenge hinzufügen kann. Die Anwendung 116 kann einer oder mehreren Routinen entsprechen, die auf die Überwachung und/oder Verwaltung der Einstellung jedes Regelkreises ausgerichtet sind.
• Die Datenbank 114 kann derartige historische Daten für Regelkreise speichern, die sich in mehreren Steuerungen 11 im System 10 befinden, und sie muss nicht auf den Einsatz mit einem bestimmten Steuerungstyp beschränkt sein. Die Datenbank 114 kann beispielsweise derartige Daten für Steuerungen von Fremdanbietern speichern.
• Allgemeiner ausgedrückt und entsprechend der Darstellung bei der in 7 wiedergegebenen beispielhaften Ausführungsform, kann die Implementierung des offenbarten Systems und der Methode und Verfahren bei Altsystemen oder Prozesssteuersystemen von Fremdanbietern angewandt werden. Anders ausgedrückt, können die offenbarten Systeme und Verfahren auf den Altsystemen oder anderen Prozesssteuersystemen „überlagert“ implementiert werden.
• In diesen Fällen (und bei anderen alternativen Ausführungsformen) umfasst die Workstation 13 allgemein die vorstehend beschriebene, auf andere Weise in der Steuerung 11 implementierte Modellidentifizierungsfunktionalität. Die Workstation 13 kann beispielsweise ein Modellidentifizierungsmodul 118 mit einer Datenerfassungsfunktion 120, einem Konfigurationslistenmodul 122, einer Modellberechnungsroutine 124 und einem Speicher 126 zum Speichern des/der letzten identifizierten Modells/Modelle umfassen. Zusätzlich zu den Elementen, die den Elementen des Modellidentifizierungsmoduls 60 der vorstehend beschriebenen Steuerung 11 entsprechen, kann die Workstation 13 auch eine virtuelle Steuerung 128 für das Steuersystem aufrechterhalten, für das die Prozessmodule identifiziert werden. Die virtuelle Steuerung 128 kann beispielsweise Module umfassen und speichern, die die aktuelle Konfiguration jedes Regelkreises neben einer Identifizierung der diesbezüglichen Parameter wiedergeben. Das heißt, dass die über das offenbarte Verfahren erzeugten Modell- und Diagnoseinformationen automatisch in einem für den betreffenden Knoten erzeugten Modul gespeichert werden. Auf diese Weise kann die virtuelle Steuerung 128 zur Präsentation von Informationen über Einstellung, Diagnose usw. auf genau die gleiche Weise verwendet werden, wie dies in Verbindung mit in der Steuerung 11 implementierten Regelkreisen der Fall wäre. Falls die Benennungskonventionen des Steuerungssystems von denen der Workstation 13 abweichen, können Definitionen zur Korrelation der Parameter über den Schnittstellenkonfigurationsblock 134 oder ein anderes Element der Workstation 13 erfolgen.
• Zur Unterstützung der breiten Anwendung des offenbarten Verfahrens kann die Workstation 13 eine OPC-(Open Process Control)- oder eine andere Client-Schnittstelle 132 umfassen, die über einen Block 134 zum Zugriff auf dynamische Regelkreisparameter konfiguriert ist. Allgemein ausgedrückt, kann die Kommunikationsverbindung zwischen der Workstation 13 und dem Altsystem oder dem Steuersystem eines Fremdanbieters durch die Identifizierung eines dazugehörigen OPC-Servers 136 festgestellt werden und in einigen Fällen über die Identifizierung anderer Kommunikationseinstellungen, wie z. B. über eine Identifizierung von einer oder mehreren Steuerungen 138, die in den Modellidentifizierungsprozess einbezogen sind. Um das Öffnen vieler (z. B. unnötiger) Kommunikations-Ports zu vermeiden, können diese OPC-Verbindungen unter Verwendung von Tunneler-Software hergestellt werden.
• Weitere Einzelheiten bezüglich der über die Workstation 13 bereitgestellten Anwendungen (entweder in einem Altsystem oder in einem standardmäßigen integrierten Zusammenhang) zur Steuerung und Verwaltung der Implementierung des offenbarten Verfahrens werden nun bereitgestellt. Die Anwendungen unterstützen allgemein die Identifizierung von Prozessmodellen entsprechend der vorstehenden Beschreibung, und sie stellen auch die Funktionalität in Zusammenhang mit der Verwendung der identifizierten Modelle bereit. Wie vorstehend beschrieben, müssen die Prozessmodelle nicht für die ausschließliche Verwendung in Verbindung mit einem adaptiven Steuerungsschema erzeugt werden. Die Identifizierung von Prozessmodellen gemäß dem offenbarten Verfahren wird ungeachtet des Umstands implementiert, ob die Steuerungsroutine eine adaptive Steuerungsroutine ist. Die Identifizierung von Prozessmodellen für alle Regelkreise - sowohl adaptiv als auch nicht adaptiv - stellt allgemein die Möglichkeit bereit, eine Reihe unterschiedlicher Analysen des Prozesses, des Prozesssteuersystems und spezifischer diesbezüglicher Elemente ausführen zu können. Das bedeutet in einigen Fällen, dass das offenbarte System eine Option über ein Dialogfeld, ein Fenster, eine Frontblende (Faceplate) oder eine andere Anzeigeschnittstelle bereitstellen kann, um die Modellidentifizierung auf knotenweiser (oder schleifenweiser) Basis zu deaktivieren. Die Anzeigeschnittstelle kann eine aus einer Reihe von Anzeigeschnittstellen sein, die über die Implementierung der auf den Workstations 13 ausgeführten Anwendungen erzeugt werden. Beispiele derartiger Anzeigeschnittstellen sind in 9-16 wiedergegeben.
• Wiederum mit generellem Bezug auf 1 umfassen die Workstations 13 (individuell, verteilt oder auf beliebige andere Weise) eine Suite von Benutzerschnittstellenanwendungen und andere Datenstrukturen 140, auf die jeder autorisierte Benutzer (z. B. ein Konfigurationsingenieur, Bediener usw.) zugreifen kann, um Funktionalität bezüglich der Einrichtungen, Einheiten usw., die in der verfahrenstechnischen Anlage [sic] 10 angeschlossen sind, abzurufen und bereitzustellen. Die Suite von Benutzerschnittstellenanwendungen 140 ist in einem Speicher 142 der Workstation 13 gespeichert, und jede der Anwendungen oder Entitäten in der Anwendungssuite 140 ist für die Ausführung auf einem entsprechenden Prozessor 144, der jeder Workstation 13 zugeordnet ist, eingerichtet. Während die gesamte Anwendungssuite 140 so dargestellt ist, dass sie in der Workstation 13 gespeichert ist, können einige dieser Anwendungen oder anderen Entitäten in anderen Workstations oder Computereinrichtungen gespeichert und ausgeführt werden, die sich im System 10 befinden oder die ihm zugeordnet sind oder die damit kommunizieren. Weiter kann die Anwendungssuite 140 Anzeigeausgaben auf einem Anzeigebildschirm 146, der der Workstation 13 zugeordnet ist, oder auf einem beliebigen anderen gewünschten Anzeigebildschirm oder einer Anzeigeeinrichtung bereitstellen, einschließlich Handheld-Geräten, Laptops, anderer Workstations, Druckern usw. Entsprechend können die Anwendungen in der Anwendungssuite 140 aufgeteilt und auf zwei oder mehreren Computern oder Vorrichtungen ausgeführt werden, und sie können für den Betrieb in Verbindung miteinander konfiguriert sein.
• 8 zeigt eine beispielhafte Workstation 13 ausführlicher in Verbindung mit der Implementierung des offenbarten Systems, der Methode und der Modellidentifizierungsverfahren. Insbesondere kann die Anwendungssuite 140 eine Reihe von Anwendungen, Routinen, Modulen und anderen verfahrenstechnischen Elementen umfassen, die auf die Implementierung von modellorientierter Überwachung und Verwaltung des Steuersystems 10 entsprechend dieser Beschreibung ausgerichtet sind. Die Anwendungen, Routinen, Module und Elemente können über eine beliebige Kombination von Software, Firmware und Hardware implementiert werden, und sie sind nicht auf die in 8 wiedergegebene beispielhafte Anordnung beschränkt. Beispielsweise können eine oder mehrere Anwendungen in einem beliebigen gewünschten Ausmaß integriert werden.
• Die Anwendungssuite kann eine Historian-Anwendung 148 umfassen, die für die Unterstützung der Registrierung von Prozessmodelldaten (z. B. Parametern) vorgesehen ist, wenn die Modelle über die vorstehend beschriebenen Verfahren identifiziert werden. Hierzu kann die Historian-Anwendung 148 mit der Historian-Datenbank 12 oder mit einem beliebigen anderen Datenspeicher oder Speichermechanismus kommunizieren. Wie vorstehend beschrieben, können die Prozessmodelldaten in Verbindung oder in Zusammenhang mit Daten gespeichert werden, die die Identifizierung des Prozessmodells (oder die dazu führende Datenerfassung) aufzeichnen. Die Historian-Anwendung 148 kann auch Analysefunktionalität bereitstellen, wie z. B. die Berechnung von Summen, Mittelwerten und anderen Werten für ausgewählte Modellparameter. Die Historian-Anwendung 148 kann den Abruf dieser berechneten Werte sowie der zugrunde liegenden gespeicherten Daten über eine oder mehrere Anzeigeschnittstellen ermöglichen.
• Eine Schnittstellenanwendung 150 eines Fremdanbieters kann bereitgestellt sein, um entsprechend der Beschreibung in Zusammenhang mit 7 eine Kommunikationsverbindung mit einem übernommenen älteren oder von einem Fremdanbieter gelieferten Prozesssteuersystem zu unterstützen und aufrechtzuerhalten. Hierzu kann die Anwendung 150 eine Reihe von Anzeigeschnittstellen erzeugen, um die Konfiguration der Kommunikationsverbindung zu ermöglichen, und sie kann die virtuelle Steuerung 128 aufrechterhalten und verwenden und die Schnittstelle auf andere Weise unterstützen.
• Weitere Anzeigeschnittstellen können von einer auf die Unterstützung von Kommunikationsvorgängen mit der Steuerung 11 ausgerichteten Anwendung 152 bereitgestellt werden. Derartige Kommunikationsvorgänge können die Konfiguration und Wartung von adaptiven Steuerungsroutinen einbeziehen oder umfassen, die in der Steuerung 11 ausgeführt werden. Wie in der gesamten Anwendungssuite können die Anzeigeschnittstellen eine beliebige Form annehmen, einschließlich und ohne diesbezügliche Einschränkung Dynamos, Faceplates (Frontblenden), Detailanzeigen, Dialogfelder und Fenstern, und sie können für die Anzeige auf unterschiedlichen Anzeigetypen konfiguriert werden.
• Die Anwendungssuite kann eine Anwendung 154 enthalten, die für die Verwendung der Prozessmodellinformationen in Verbindung mit der Einstellung vorgesehen ist. Als Ergebnis der vorstehend beschriebenen Modellidentifizierungsverfahren ist die Einstellanwendung 154 auf die Verbesserung der Prozesssteuerungs-Performance durch die automatische Berechnung von Einstellparametern infolge von normalen täglich anfallenden Änderungen in der Anlage oder nach bedarfsweise durchgeführten Einstellungstests ausgerichtet. Die Einstellungsergebnisse können sowohl für „open-loop“-Empfehlungen als auch für die „closed-loop“-adaptive Steuerung verwendet werden.
• Insbesondere kann die Einstellanwendung 154 eine Reihe von Anzeigeschnittstellen zur Unterstützung der Performance von kontinuierlichen Einstellungsberechnungen für alle Regelkreise entweder im Open-loop- oder im Closed-loop-Betrieb erzeugen. Die Einstellungsberechnungen unterstützen sowohl die Standard- als auch die adaptive Steuerung bei PID-, Fuzzy-Logic- und MPC-Steuerungen und stellen somit Einstellungsempfehlungen für die Rückkopplungssteuerung und für die Vorkopplungssteuerung bereit. Die Einstellanwendung 154 kann auch unter Verwendung von Relaisoszillation oder einer anderen Prozedur eine bedarfsweise Einstellung entsprechend der vorstehenden Beschreibung bereitstellen.
• Die Einstellanwendung 154 kann auf die in der Historian-Datenbank 12 (oder bei Bedarf an anderer Stelle) gespeicherten Prozessmodell-Historiendaten zugreifen, und sie kann somit unter Verwendung historischer Prozessmodelldaten eine optimierte Einstellung berechnen. Hierzu können die Anzeigeschnittstellen Tools bereitstellen oder umfassen, um die Historie einfach zu durchsuchen, um die für die Einstellungsberechnungen geeigneten Daten zu suchen und zu verwenden. Dieser Aspekt der von der Einstellanwendung 154 erzeugten Anzeigeschnittstelle(n) ermöglicht einem Benutzer die Änderung von Modellparametern (z. B. Zeit bis zum stationären Zustand, Ereignis-Triggerschwellwert) und die erneute Identifizierung von Modellen oder die Identifizierung von Modellen für Regelkreise, die zuvor nicht für die automatische Modellidentifizierung aktiviert waren.
• Die Einstellanwendung kann auch eine Schnittstelle zur Unterstützung der Analyse einer Historie von Einstellberechnungsergebnissen bereitstellen. Diese Fähigkeit kann die Analyse von adaptiven Steuerungsmöglichkeiten und die Verbesserung von adaptiven Steuerungskonfigurationen erleichtern.
• Wie vorstehend beschrieben, kann die Einstellanwendung 154 eine Schnittstelle zur Unterstützung der Einführung von Steuerungs-„Störungen“ bereitstellen, die die Identifizierung der Steuerungseinstellung erleichtern, wenn wenige manuelle Änderungen des Prozesses vorliegen (z. B. automatische Einführung in die Steuerungsausgabe). Über die Schnittstelle kann eine Option zur Deaktivierung von Störungen bereitgestellt werden, nachdem eine gute Einstellung berechnet worden ist. Wenn mehrere Regelkreise gestört werden, können die Vorgänge synchron erfolgen, um die Prozessstörung zu verteilen und zu minimieren.
• Die Einstellanwendung 154 kann auf Prozesszustände und andere Statusangaben reagieren, sodass alle Rechenergebnisse dementsprechend identifiziert werden. Auf diese Weise vermeidet das offenbarte System die Verwendung von berechneten Informationen im falschen Zustand oder mit ungeeigneten Prozessdaten. Hierzu können die modellorientierten Berechnungen gegebenenfalls mit Erläuterungen angeben, ob die Ergebnisse verlässlich, ungeeignet oder nicht verfügbar sind.
• Die Einstellanwendung 154 kann auch Zusammenfassungs-Reports erzeugen, um unter anderem Informationen zu Einstellungsempfehlungen und ein Benutzerprotokoll zu übermitteln, das Einstellungsänderungen und eventuelle Einstellungsanalysen der adaptiven Steuerung dokumentiert.
• Weitere Einzelheiten mit Bezug auf die von der Einstellanwendung 154 (entweder individuell oder in Verbindung mit anderen Anwendungen) erzeugten Anzeigeschnittstellen werden in Verbindung mit 12-16 wiedergegeben, wobei allgemein die Ansichten der Prozessmodelle und Regelkreise dargestellt sind, die für einen Benutzer bereitgestellt werden, um die vorstehend beschriebene Funktionalität zu ermöglichen.
• Wiederum mit Bezug auf 8 ist eine Anwendung 156 allgemein auf die automatische Überwachung der Steuerungs-Performance ausgerichtet, wobei die über das offenbarte Verfahren identifizierten Prozessmodelle verwendet werden. Die Anwendung 154 ist insbesondere auf die Verbesserung der Prozesssteuerungs-Performance über die Ermöglichung oder automatische Implementierung von Folgendem ausgerichtet: (i) Identifizierung von Möglichkeiten der Steuerungsverbesserung, (ii) Analyse und Diagnose der Quelle von Steuerungsproblemen und (iii) Erzeugung aussagekräftiger Performance-Reports für das Bedienungs-, Überwachungs- und Wartungspersonal. Hierzu kann die Anwendung 156 einen auf den Prozessmodellen basierenden Steuerungs-Performance-Index erzeugen. Dieser „modellbasierte“ Index stellt einen besseren Benchmark zur Identifizierung von Regelkreisen bereit, die erneut eingestellt werden müssen. Der neue Index misst die Verbesserungsmöglichkeit der Steuerung auf der Grundlage von Faktoren, wie z. B. der Prozessvariabilität, des identifizierten Prozessmodells und der vorliegenden Steuerungseinstellung. Diese Performance-Überwachung kann gegebenenfalls Einheitenzustände berücksichtigen und Performance-Berechnungen ausschließen, wenn der Regelkreis in einem ungeeigneten Einheitenzustand ist oder wenn andere Statusangaben (z. B. Fieldbus-Status) oder I/O-Kommunikationsvorgänge ungeeignet sind. Auch Ventil-Haftreibung, -Gegenschlag und andere Ventildiagnoseindizes können für alle Ventile bereitgestellt werden.
• Unter Verwendung der Prozessmodelle kann von der Anwendung 156 wiederum ein Oszillationsindex erzeugt werden, um oszillierende Regelkreise zu identifizieren. Insbesondere kann ein Oszillationsanalyse-Tool andere Regelkreise mit der gleichen Oszillationsperiode identifizieren, die mit dem primären Regelkreis interagieren können. Diese Informationen können anschließend zur Identifizierung von Prozessinteraktionen und möglichen Designempfehlungen benutzt werden.
• Von der Anwendung 156 bereitgestellte Diagnoseinformationen können von einer Angabe der erwarteten Ursache einer schlechten Steuerungs-Performance begleitet werden. Beispielsweise kann die Diagnose angeben, ob eine schlechte Steuerungs-Performance durch Instrumentationsfehler, Ventil-Haftreibung oder - Gegenschlag, Prozessinteraktionen oder die Steuerungseinstellung verursacht wird.
• Allgemein ausgedrückt, können die Überwachungsinformationen der Steuerungs-Performance in einer beliebigen gewünschten Form bereitgestellt werden, einschließlich einer Reihe von individuell angepassten Anzeigeschnittstellen und Reports. Historische Performance-Reports können bereitgestellt werden, um anzuzeigen, wie ein Regelkreis über einen vom Benutzer angegebenen Zeitraum funktioniert hat. Vorgegebene Standardzeiträume für derartige Reports umfassen die letzte Stunde, die letzte Schicht (8 Stunden), den letzten Tag, die letzte Woche, den letzten Monat. Für den Benutzer kann eine Option bereitgestellt werden, um Zusammmenfassungs-Reports zu vertiefen und auf detaillierte Regelkreisinformationen zuzugreifen. Die Reports oder Schnittstellen können für Management-Zusammenfassungen individuell angepasst werden und z. B. einen gewichteten Gesamt-Performance-Index für anlagenweite und individuelle Prozesseinheiten, Trends und/oder Tabellen zum Vergleich des aktuellen Zeitraums mit zurückliegenden Zeiträumen sowie Listen von Regelkreisen mit höchster Priorität mit einer dazugehörigen Performance-Messung umfassen. Wartungs-Reports können Regelkreis-Performance-Indizes wiedergeben und für Arbeitsobjekte auf der Grundlage ihrer jeweiligen Bedeutung für den Anlagenbetrieb Prioritäten setzen. Andere Reports können Statistiken bereitstellen mit Daten für den Steuerungs-Performance-Index, der Standardabweichung, dem Oszillationsindex, dem Prozessmodell (sofern verfügbar), der Auto- und Kreuzkorrelation, einem Histogramm, einem Leistungsspektrum usw.
• Weitere Einzelheiten bezüglich der von der Anwendung 156 bereitgestellten Informationen werden über die in 9-12 wiedergegebenen beispielhaften Anzeigeschnittstellen dargestellt.
• Die Anwendungssuite kann auch eine separate Regelkreis-Analyseanwendung 158 enthalten. Bei einigen Ausführungsformen wird die Anwendung 158 über die von der Anwendung 156 erzeugte(n) Anzeigeschnittstelle(n) zur Verfügung gestellt. In jedem Fall unterstützt die Anwendung 158 die Analyse von Historian- oder Echtzeitdaten, die in Verbindung mit den vorstehend beschriebenen Modellidentifizierungsverfahren erfasst wurden. Die Daten können über eine Schnittstelle wiedergegeben werden, die die Untersuchung von Änderungen in der Steuerung durch nicht gemessene Störungen und Messrauschen ermöglicht. Beispielsweise können die über die Anwendungen 154 und 156 identifizierten Probleme unter Verwendung der Analyseanwendung 158 zur Diagnose weiter untersucht werden. Hierzu kann die dadurch erzeugte Anzeigeschnittstelle Optionen bereitstellen, um das Leistungsspektrum, die Autokorrelation und Histogrammdaten bereitzustellen.
• Ein Ratgeberanwendung 160 kann allgemein Funktionalität bereitstellen, die die identifizierten Modelle in Verbindung mit Diagnose verwendet, um abnorme Bedingungen oder Verbesserungsmöglichkeiten für das Steuerungsschema durch Änderungen der Einstellung oder der Algorithmen zu erkennen. Die von der Ratgeberanwendung 160 bereitgestellten Informationen können auf Anzeigeschnittstellen beliebigen Typs bereitgestellt werden, einschließlich einer Faceplate, die über die Workstation 13, die Steuerung 11 oder ein beliebiges anderes mit dem System 10 kommunizierendes Element erzeugt wird. In einem spezifischen Beispiel kann die Anzeigeschnittstelle ein Flag zur Angabe der Anzeige einer neuen Hinweismeldung wie z. B. „Einstellung prüfen“ haben.
• Allgemeiner ausgedrückt, kann die Ratgeberanwendung 160 Empfehlungen bereitstellen, die als Ergebnis einer Analyse oder Diagnose erzeugt werden, die von einer beliebigen Anwendung in der Suite durchgeführt worden ist. Ferner müssen die Empfehlungen nicht durch eine von der Ratgeberanwendung erzeugten Anzeigeschnittstelle bereitgestellt werden, sondern sie können von einer oder mehreren der Anwendungen in der Suite zur Anzeige gesandt werden. Damit können Empfehlungen und Meldungen wie z. B. „Neue Einstellung verfügbar“, „Prozess prüfen - signifikante Prozessänderung wurde erkannt“, „Ventil prüfen - Totzone/Hysterese groß“, „Einstellung prüfen - Schleife instabil“ und „Steuerung konnte mit MPC/Adapt nicht verbessert werden“ generell über die Workstation 13 oder andere mit dem Prozesssteuersystem 10 kommunizierende Einrichtungen bereitgestellt werden. Zusätzlich zur Anzeige der Meldung oder Empfehlung können Einzelheiten bezüglich der zugrunde liegenden Bedingung als Historie oder als anderer Parameter für den Regelkreis gespeichert werden. Der spätere Zugriff auf, oder die Verwendung von, Daten, die für den Regelkreis gespeichert sind, kann dann bewirken, dass die Einzelheiten oder die zugeordnete Meldung für einen Benutzer der Ratgeberanwendung bzw. der anderen Anwendung in der Suite angezeigt werden.
• Andere Anwendungen, die auch die Implementierung der offenbarten Verfahren unterstützen, umfassen eine Steuerungsstudioanwendung 162, um die Navigation im Prozesssteuersystem 10 zu erleichtern, und eine Report-Erzeugungsanwendung 164 zur Erzeugung der vorstehend erwähnten Reports. Schließlich können auch ein oder mehrere Speicher oder Datenbanken 166 als Teil der Anwendungssuite bereitgestellt sein.
• 9 gibt eine beispielhafte Anzeigeschnittstelle 168 wieder, die von der Überwachungsanwendung für die Performance 156 (oder alternativ dazu von einer oder mehreren beliebigen der anderen Anwendungen) erzeugt werden kann, um Überblickinformationen wiederzugeben, die sich aus der Inspektionsanalyse des Prozessmodells ergeben. In diesem spezifischen Beispiel gibt die Anzeigeschnittstelle 168 Informationen wieder, die den Zustand der Steuerungsroutinen oder -module im gesamten Prozesssteuersystem 10 oder in einem beliebigen, über eine Hierarchiebaum-Struktur 170 ausgewählten Bereich davon angeben. Die Steuerungs-Performance kann über Kategorien wie „Falscher Modus“ („Incorrect Mode“), „Steuerung eingeschränkt“ („Limited Control“), „Ungewisse Eingabe“ („Uncertain Input“) und „Große Variabilität“ („Large Variability“) in einer Diagrammanzeige 172 angegeben und zusammengefasst werden. Die Einordnung oder Klassifikation eines Steuerungsmoduls, eines Funktionsblocks oder einer Routine in eine dieser Kategorien wird generell durch die über die offenbarten Verfahren identifizierten Prozessmodelle aktiviert und kann unter ihrer Verwendung automatisch implementiert werden. Die Anzeigeschnittstelle 168 umfasst auch eine Hinweisdiagrammanzeige 174 zur Wiedergabe statistischer Informationen zur Anzahl der Assets, von denen angenommen wird, dass sie ausgefallen sind, baldige Wartung erfordern, einen Ratschlaghinweis gesetzt haben oder mit Kommunikationsfehlern behaftet sind.
• 10 gibt eine beispielhafte Anzeigeschnittstelle 176 wieder, die ebenfalls von der Überwachungsanwendung für die Performance 156 erzeugt werden kann. Auch die Anzeigeschnittstelle 176 gibt generell Informationen zur Steuerungs-Performance wieder, jedoch auf einer detaillierteren Ebene. Bei diesem Beispiel werden Performance-Informationen für jeden Regelkreis oder jedes Modul in einem in der Hierarchiebaum-Struktur ausgewählten Bereich wiedergegeben. Jede für einen bestimmten Regelkreis erkannte abnorme Bedingung kann in einer Tabelle registriert werden, die zwischen Problemen unterscheidet, die einem abnormen Modus, einer eingeschränkten Steuerung, einem Eingabestatus, hoher Variabilität oder einer inaktiven diesbezüglichen Einrichtung zugeordnet sind. Eine Prioritätsstufe und eine Angabe, ob ein Report mit der Beschreibung der abnormen Bedingung erzeugt worden ist, können ebenfalls angezeigt werden.
• 11 gibt eine beispielhafte Anzeigeschnittstelle 178 wieder, die ebenfalls von der Überwachungsanwendung für die Performance 156 erzeugt werden kann. Die Anzeigeschnittstelle 178 ähnelt der in 10 wiedergegebenen Anzeigeschnittstelle 176, und sie unterscheidet sich davon durch die Steuerungsebene, auf der die Performance-Informationen wiedergegeben werden. In diesem Fall wird über die Struktur 170 ein Modul oder ein Regelkreis ausgewählt, und Performance-Informationen werden für jeden Funktionsblock davon wiedergegeben. Auf Diagnoseinformationen für einen bestimmten Block kann anschließend über die Auswahl des in der Tabelle angezeigten Blocknamens (z. B. durch Klicken mit der rechten Maustaste) zugegriffen werden.
• 12 gibt eine beispielhafte Anzeigeschnittstelle 180 wieder, die von einer oder mehreren der Anwendungen erzeugt werden kann, einschließlich der Einstellanwendung 154 und der Überwachungsanwendung für die Performance 156. Allgemein ausgedrückt, ermöglicht die Anzeigeschnittstelle 180 die Prüfung der Ergebnisse von Diagnoseberechnungen für ein ausgewähltes Steuerungselement (z. B. PID1). Über die Berechnungen abgeleitete Grenzwerte für die Statistik werden zum Vergleich und bei Bedarf zur Änderung durch den Benutzer ebenfalls angezeigt. Ist ein Grenzwert überschritten, kann ein Alarm den zugeordneten Zustand angeben. Allgemeiner ausgedrückt, geben die in der Anzeigeschnittstelle 180 angezeigten Informationen und die zugrunde liegenden Berechnungen an, wie als Ergebnis der hier offenbarten Verfahren zur Prozessmodellidentifizierung die Stabilität des Regelkreises kontinuierlich überwacht wird.
• 13 gibt eine beispielhafte Anzeigeschnittstelle 182 wieder, die die Einrichtung eines Regelkreises für die automatische Prozessmodellidentifizierung sowie für die bedarfsweise Modellidentifizierung ermöglicht. Eine Reihe von Anzeigen ist über die Schnittstelle 182 bereitgestellt, um Trigger, Ereignis-Trigger, Triggerereignis-Ebenen, Höchstwerte für Parameteränderungen usw. anzugeben. Auf diese Weise ermöglicht die Anzeigeschnittstelle 182 einem Benutzer die individuelle Anpassung der Prozessmodell-Identifizierungsprozedur auf knotenweiser oder schleifenweiser Basis.
• 14 gibt allgemein das Verfahren wieder, mit dem ein Benutzer die gespeicherten Prozessmodelle einsehen kann, um unter anderem zu bestimmen, wie viele Bereiche erforderlich sind. Insbesondere umfasst eine Anzeigeschnittstelle 184 ein Anzeigefeld 186, das Informationen zur Prozessmodellhistorie auflistet, und ein Anzeigefeld, das über entsprechende horizontale Linien die freigegebenen Modellwerte und über die Punkte die Parameter der identifizierten und in der Historiendatenbank gespeicherten Prozessmodelle wiedergibt. Wie vorstehend beschrieben, können die dazugehörigen Modelle für eine Anzahl von Bereichen (z. B. fünf) freigegeben werden, und die Varianz der Modellparameter kann die Identifizierung der Bereiche ermöglichen und anderweitig die Einstellungsempfehlungen unterstützen.
• 15 und 16 geben Prozessmodellinformationen für ein kürzlich identifiziertes Modell in Verbindung mit einem Fuzzy-Logic-Steuerungsblock bzw. einem MPC-Block wieder. Hierzu stellen die Anzeigeschnittstellen 190 und 192 entsprechende grafische Darstellungen des Prozessmodells mit einer Reihe von Anzeigen 192, 194, 196 und 198 bereit, um das Testen, die Einstellungsberechnungen, die Vorgaben der Steuerungsparameter, die Einstellungssimulation und die Auswahl der Einstellung zu ermöglichen.
• Die Begriffe „identifizieren“, „Identifizierung“ und beliebige Ableitungen davon werden hier in einem allgemeinen Sinn in Verbindung mit der Verwendung von Prozessmodulen benutzt, um die Erzeugung, das Anlegen sowie die anderweitige Verarbeitung zur Erzielung von einem gesamten Prozessmodell, von einem oder mehreren Parametern zu seiner Definition oder von beliebigen anderen, das Prozessmodell definierenden Eigenschaften zu umfassen.
• Beliebige der vorstehend beschriebenen Anwendungen können als Routinen, Module oder andere Komponenten von einer oder mehreren integrierten Anwendungen implementiert werden. Die offenbarte Zusammenstellung von Anwendungsfunktionalität wird lediglich zur besseren Veranschaulichung bereitgestellt und ist keine Angabe des breiten Umfangs der Arten, auf die die Funktionalität für einen Bediener oder sonstigen Benutzer bereitgestellt werden kann. Weiter können die vorstehend beschriebenen Anwendungen in Abhängigkeit vom Benutzerprofil, vom Zusammenhang und von anderen Parametern bei Bedarf in unterschiedlicher Form bereitgestellt werden. Beispielsweise können sich die für einen Benutzertyp (z. B. Engineering) erzeugten Ansichten der Anzeigeschnittstelle im Inhalt und auf andere Weisen von den für einen anderen Benutzertyp (z. B. Wartung) erzeugten Ansichten unterscheiden.
• Bei der Implementierung kann beliebige hier beschriebene Software in einem beliebigen computerlesbaren Speicher gespeichert werden, wie z. B. auf einer Magnetplatte, einer Laser-Disk oder auf einem anderen Speichermedium, in einem RAM oder ROM eines Computers oder Prozessors usw. Auf ähnliche Weise kann diese Software einem Benutzer, einer verfahrenstechnischen Anlage oder einer Bediener-Workstation unter Verwendung eines beliebigen bereits bekannten oder gewünschten Übergabeverfahrens zur Verfügung gestellt werden, wie beispielsweise auf einem computerlesbaren Datenträger oder einem anderen transportablen Computerspeichermechanismus oder über einen Kommunikationskanal wie eine Telefonleitung, das Internet, das World Wide Web, ein beliebiges anderes LAN-Netz (Local Area Network) oder WAN-Netz (Wide Area Network) usw. (wobei dies als bezüglich der Bereitstellung derartiger Software über ein transportables Speichermedium gleichwertig oder austauschbar angesehen wird). Ferner kann diese Software direkt ohne Modulation oder Verschlüsselung bereitgestellt werden, oder sie kann vor der Übertragung über einen Kommunikationskanal unter Verwendung einer beliebigen geeigneten Modulations-Trägerfrequenz und/oder eines Verschlüsselungsverfahrens moduliert und/oder verschlüsselt werden.
• Während die Erfindung mit Bezug auf spezifische Beispiele beschrieben ist, die nur der Veranschaulichung dienen und die die Erfindung nicht einschränken sollen, ist es für Fachleute auf diesem Gebiet ersichtlich, dass an den offenbarten Ausführungsformen Abänderungen, Ergänzungen oder Streichungen vorgenommen werden können, ohne vom Umfang und Schutzbereich der Erfindung abzuweichen.
• Die bevorzugten Aspekte der vorliegenden Erfindung lassen sich wie folgt zusammenfassen:
1. 1. Verfahren zur Steuerung eines Prozesssteuersystems mit einer Vielzahl von Regelkreisen, wobei das Verfahren die folgenden Schritte umfasst:
   • Implementierung einer Vielzahl von Steuerungsroutinen zur Steuerung des Betriebs der Vielzahl von Regelkreisen (Steuerkreisen) bzw. der Vielzahl von Steuerungsroutinen mit mindestens einer nicht adaptiven Steuerungsroutine; Erfassung von Daten zu Betriebsbedingungen in Verbindung mit dem Betrieb jedes Regelkreises der Vielzahl von Regelkreisen; und Identifizierung eines entsprechenden Prozessmodells für jeden Regelkreis der Vielzahl von Regelkreisen aus den jeweiligen für jeden Regelkreis der Vielzahl von Regelkreisen erfassten Daten zu Betriebsbedingungen.
2. 2. Verfahren nach Aspekt 1, wobei weiter der Schritt der Speicherung von Daten enthalten ist, die die jeweiligen identifizierten Prozessmodelle in einer entsprechenden Prozessmodellhistorie für jeden Regelkreis der Vielzahl von Regelkreisen angeben.
3. 3. Verfahren nach Aspekt 1, wobei weiter die folgenden Schritte enthalten sind:
   • Prüfung der Daten zu Betriebsbedingungen, um eine Änderung daran zu erkennen; und Auslösen des Identifizierungsschritts der Prozessmodelle, wenn die Änderung erkannt worden ist.
4. 4. Verfahren nach Aspekt 1, wobei der Identifizierungsschritt als Reaktion auf einen Benutzer-Befehl zur Berechnung des Prozessmodells auf der Grundlage der erfassten Daten zu Betriebsbedingungen ausgeführt wird.
5. 5. Verfahren nach Aspekt 4, wobei die erfassten Daten zu Betriebsbedingungen eine Reaktion auf eine eingeführte Parameteränderung angeben, die infolge des Benutzer-Befehls angewandt wurde.
6. 6. Verfahren nach Aspekt 1, wobei die Daten zu Betriebsbedingungen den Online-Betrieb eines über den Betrieb der Vielzahl von Regelkreisen gesteuerten Prozesses angeben.
7. 7. Verfahren nach Aspekt 1, wobei weiter zur Bewertung der Regelkreis-Performance der Schritt der Überwachung der jeweiligen für jeden Regelkreis identifizierten Prozessmodelle enthalten ist.
8. 8. Verfahren nach Aspekt 1, wobei weiter zur Bestimmung, welche Regelkreise ein adaptives Steuerungsschema verwenden sollen, der Schritt der Analyse der jeweiligen für jeden Regelkreis identifizierten Prozessmodelle enthalten ist.
9. 9. Verfahren nach Aspekt 1, wobei weiter zur Diagnose von Steuerungsproblemen der Schritt der Analyse der jeweiligen für jeden Regelkreis identifizierten Prozessmodelle enthalten ist.
10. 10. Verfahren zur Steuerung eines Prozesssteuersystems mit einer Vielzahl von Steuerungsroutinen, wobei das Verfahren Folgendes umfasst:
    • Erfassung von Daten zu Betriebsbedingungen während der Implementierung der Vielzahl von Steuerungsroutinen;
    • Erkennen eines Ereignisses, das eine Prozessänderung angibt, in Verbindung mit einer Steuerungsroutine aus der Vielzahl von Steuerungsroutinen, die der Prozessänderung zugeordnet ist;
    • Identifizieren eines Prozessmodells für die Steuerungsroutine, die der Prozessänderung zugeordnet ist; und
    • Speicherung von Daten, die das erzeugte Prozessmodell angeben, mit dem Aufbau einer Prozessmodellhistorie für die Steuerungsroutine, die der Prozessänderung zugeordnet ist.
11. 11. Verfahren nach Aspekt 10, wobei weiter bei der Erkennung des Ereignisses der Schritt der automatischen Datenerfassung für den Identifizierungsschritt enthalten ist.
12. 12. Verfahren nach Aspekt 10, wobei weiter der Schritt der Identifizierung der jeweiligen Prozessmodelle für jede Steuerungsroutine aus der Vielzahl von Steuerungsroutinen enthalten ist.
13. 13. Verfahren nach Aspekt 12, wobei die Vielzahl von Steuerungsroutinen eine Steuerungsroutine umfasst, die ein nicht adaptives Steuerungsschema implementiert.
14. 14. Verfahren nach Aspekt 12, wobei weiter zur Bewertung der Steuerungsroutinen-Performance der Schritt der Überwachung der jeweiligen für jede Steuerungsroutine identifizierten Prozessmodelle enthalten ist.
15. 15. Verfahren nach Aspekt 12, wobei weiter zur Bestimmung, welche Steuerungsroutinen ein adaptives Steuerungsschema verwenden sollen, der Schritt der Analyse der jeweiligen für jede Steuerungsroutine identifizierten Prozessmodelle enthalten ist.
16. 16. Verfahren nach Aspekt 12, wobei weiter zur Diagnose von Steuerungsproblemen der Schritt der Analyse der jeweiligen für jede Steuerungsroutine identifizierten Prozessmodelle enthalten ist.

Claims (7)

1. Verfahren zur Steuerung eines Prozesssteuersystems mit einer Vielzahl von Steuerungsroutinen, wobei das Verfahren Folgendes umfasst: Erfassung von Daten zu Betriebsbedingungen während der Implementierung der Vielzahl von Steuerungsroutinen; Erkennen eines Ereignisses, das eine Prozessänderung angibt, in Verbindung mit einer Steuerungsroutine aus der Vielzahl von Steuerungsroutinen, die der Prozessänderung zugeordnet ist; Identifizieren eines Prozessmodells für die Steuerungsroutine, die der Prozessänderung zugeordnet ist; und Speicherung von Daten, die das erzeugte Prozessmodell angeben, mit dem Aufbau einer Prozessmodellhistorie für die Steuerungsroutine, die der Prozessänderung zugeordnet ist.
2. Verfahren nach Anspruch 1, wobei weiter bei der Erkennung des Ereignisses der Schritt der automatischen Datenerfassung für den Identifizierungsschritt enthalten ist.
3. Verfahren nach Anspruch 1 oder 2, insbesondere Anspruch 1, wobei weiter der Schritt der Identifizierung der jeweiligen Prozessmodelle für jede Steuerungsroutine aus der Vielzahl von Steuerungsroutinen enthalten ist.
4. Verfahren nach einem der Ansprüche 1 bis 3, insbesondere nach Anspruch 3, wobei die Vielzahl von Steuerungsroutinen eine Steuerungsroutine umfasst, die ein nicht adaptives Steuerungsschema implementiert.
5. Verfahren nach einem der Ansprüche 1 bis 4, insbesondere nach Anspruch 3, wobei weiter zur Bewertung der Steuerungsroutinen-Performance der Schritt der Überwachung der jeweiligen für jede Steuerungsroutine identifizierten Prozessmodelle enthalten ist.
6. Verfahren nach einem der Ansprüche 1 bis 5, insbesondere nach Anspruch 3, wobei weiter zur Bestimmung, welche Steuerungsroutinen ein adaptives Steuerungsschema verwenden sollen, der Schritt der Analyse der jeweiligen für jede Steuerungsroutine identifizierten Prozessmodelle enthalten ist.
7. Verfahren nach einem der Ansprüche 1 bis 6, insbesondere nach Anspruch 3, wobei weiter zur Diagnose von Steuerungsproblemen der Schritt der Analyse der jeweiligen für jede Steuerungsroutine identifizierten Prozessmodelle enthalten ist.

Images