DE102007017039A1

DE102007017039A1 - Robuste Prozessmodellidentifikation bei modellbasierten Steuerungstechniken

Info

Publication number: DE102007017039A1
Application number: DE102007017039A
Authority: DE
Inventors: Wilhelm K. Austin Wojsznis; Ashish Round Rock Mehta; Dirk Austin Thiele
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2006-04-13
Filing date: 2007-04-11
Publication date: 2007-11-22
Anticipated expiration: 2027-04-12
Also published as: US7840287B2; JP5933485B2; CN101055468A; GB2437099B; GB2437099A; JP2007287153A; CN105259763A; CN105259763B; US20070244575A1; GB0707141D0; JP5783664B2; CN101055468B; JP2013211053A; DE102007017039B4; HK1109465A1

Abstract

Ein robustes Verfahren der Erzeugung von Prozessmodellen zur Verwendung in der Erzeugung von Steuerungen wie beispielsweise bei der Erzeugung von MPC-Steuerungen fügt den Prozessdaten Rauschen hinzu, die in dem Prozess der Modellerzeugung gesammelt und verwendet werden. Insbesondere sammelt ein robustes Verfahren zur Erzeugung eines parametrischen Modells zuerst Prozessausgaben auf der Grundlage bekannter Testeingabesignale oder Sequenzen, fügt den gesammelten Prozessdaten Rauschen hinzu und verwendet sodann eine Standard- oder bekannte Technik, um ein Prozessmodell aus den gesammelten Prozessdaten zu bestimmen. Im Gegensatz zu bestehenden Techniken zur Beseitigung von Rauschen, die sich auf die Eliminierung von zufälligem Rauschen vor dem Erzeugen eines Prozessmodells konzentrieren, ermöglicht das Hinzufügen zufälligen Rauschens mit dem Erwartungswert Null zu den Prozessdaten in vielen Fällen die Erzeugung eines akzeptablen parametrischen Prozessmodells in Situationen, in denen auf andere Weise keine Konvergenz der Prozessmodellparameter erhalten wurde. Darüber hinaus haben mittels dieser Technik erzeugte Prozessmodelle allgemein größere Konfidenzintervalle und liefern somit ein Modell, das in vielen Prozesssituationen adäquat arbeitet, ohne dass die Notwendigkeit besteht, das Modell manuell oder grafisch zu verändern.

Description

Feld der Erfindung
Die vorliegende Patentschrift bezieht sich im Allgemeinen auf Prozesssteuerungssysteme und im Besonderen auf die Entwicklung von Prozessmodellen zur Verwendung in erweiterten bzw. fortschrittlichen Steuerungsroutinen wie beispielsweise modellprädiktive Steuerungsroutinen und Steuerungsroutinen in Form neuronaler Netzwerke, die in Prozesssteuerungssystemen verwendet werden.
Beschreibung der entsprechenden Technik
Prozesssteuerungssysteme wie beispielsweise verteilte oder skalierbare Prozesssteuerungssysteme der Art, wie sie in Prozessen in der Chemie-, Petroleum- und anderen Industrien eingesetzt werden, weisen typischerweise eine oder mehrere Prozesssteuerungen auf, die über analoge, digitale oder kombinierte analoge/digitale Busse miteinander und mit mindestens einer Host- oder Bedienerstation und einem oder mehreren Feldgeräten kommunikativ verbunden sind. Die Feldgeräte, bei denen es sich beispielsweise um Ventile, Ventilsteller, Schalter und Geber (beispielsweise Temperatur-, Druck- und Strömungsgeschwindigkeitssensoren) handeln kann, erfüllen innerhalb des Prozesses bestimmte Funktionen wie beispielsweise Öffnen oder Schließen von Ventilen und Messung von Prozessparametern. Die Prozesssteuerung empfängt Signale, die von den Feldgeräten durchgeführte Prozessmessungen und/oder andere Informationen im Zusammenhang mit den Feldgeräten repräsentieren, verwendet diese Information zur Durchführung einer Steuerungsroutine und erzeugt sodann Steuerungssignale, die über die Busse zu den Feldgeräten übertragen werden, um den Ablauf des Prozesses zu steuern. Die von den Feldgeräten und von der Steuerung kommenden Informationen werden typischerweise einer oder mehreren Anwendungen zur Verfügung gestellt, die von der Bedienerstation ausgeführt werden, damit ein Bediener beliebige gewünschte Funktionen in Bezug auf den Prozess durchführen kann. Dies kann beispielsweise die Betrachtung des aktuellen Status des Prozesses, eine Anderung des Prozessablaufs etc. sein.
In der Vergangenheit wurden konventionelle Feldgeräte verwendet, um analoge Signale (beispielsweise 4 bis 20 mA) über einen analogen Bus oder analoge Leitungen zur Prozesssteuerung zu senden und von dieser zu empfangen. Diese 4- bis 20-mA-Signale waren insoweit von ihrer Natur her begrenzt, als sie von der Einrichtung vorgenommene Messungen oder Steuersignale repräsentierten, die von der zur Steuerung des Betriebs der Einrichtung erforderlichen Steuerung erzeugt wurden. In letzter Zeit haben sich in der Prozesssteuerungsindustrie jedoch in zunehmendem Maß intelligente, einen Mikroprozessor und einen Speicher aufweisende Feldgeräte durchgesetzt. Neben der Ausführung einer primären Funktion innerhalb des Prozesses speichern intelligente Feldgeräte sich auf die Einrichtung beziehende Daten, kommunizieren mit der Steuerung und/oder anderen Geräten unter Verwendung eines digitalen oder eines kombinierten digitalen und analogen Formats und führen sekundäre Aufgaben wie beispielsweise Selbstkalibrierung, Identifizierung, Diagnose etc. aus. Um den gemeinsamen Einsatz intelligenter Feldgeräte unterschiedlicher Hersteller innerhalb desselben Prozesssteuerungsnetzwerks zu ermöglichen, wurden diverse Standard- und Open-Standard-Gerätekommunikationsprotokolle wie beispielsweise das HART^®-, PROFIBUS^®-, WORLDFIP^®,- Device-Net^®- und CAN-Protokoll entwickelt.
Darüber hinaus gibt es in der Prozesssteuerungsindustrie einen Trend zur Dezentralisierung von Prozesssteuerungsfunktionen. Beispielsweise verwendet das von der Fieldbus Foundation unter der Bezeichnung FOUNDATION^TM Feldbus (nachstehend "Feldbus") vertriebene, vollständig digitale 2-Draht-Busprotokoll in unterschiedlichen Feldgeräten angeordnete Feldgeräte für die Durchführung von Steuerungsoperationen, die zuvor innerhalb einer zentralen Steuerung ausgeführt worden waren. Insbesondere ist jedes Feldbus-Feldgerät in der Lage, einen oder mehrere Funktionsblöcke aufzuweisen und auszuführen, die sämtlich Eingaben von anderen Funktionsblöcken empfangen und/oder Ausgaben zu anderen Funktionsblöcken bereit stellen (sowohl innerhalb derselben Einrichtung als auch innerhalb unterschiedlicher Einrichtungen), und führt diverse Prozesssteuerungsoperationen wie beispielsweise Messung oder Erkennung eines Prozessparameters; Steuerung einer Einrichtung oder Durchführung einer Steuerungsoperation wie beispielsweise die Implementierung einer Proportional-Integral-Differential- (PID-) Steuerungsroutine durch. Die unterschiedlichen Funktionsblöcke innerhalb eines Prozesssteuerungssystems werden konfiguriert, um (beispielsweise über einen Bus) miteinander zu kommunizieren, um einen oder mehrere Prozesssteuerungskreise zu bilden, deren einzelne Operationen über den gesamten Prozess verteilt und mithin dezentral sind.
Prozesssteuerungen sind typischerweise so programmiert, dass sie für jeden einer Anzahl unterschiedlicher Steuerungskreise, die für einen Prozess definiert bzw. in einem Prozess enthalten sind wie beispielsweise Durchflusssteuerungskreise, Temperatursteuerungskreise, Drucksteuerungskreise etc., einen unterschiedlichen Algorithmus, eine unterschiedliche Subroutine oder einen Steuerungskreis ausführen. Allgemein gesagt, weist jeder derartige Steuerungskreis einen oder mehrere Eingabeblöcke wie beispielsweise einen Analogeingabe- (AE-) Funktionsblock, einen Steuerungsblock mit einer einzigen Ausgabe wie beispielsweise einen Proportional-Integral-Differential- (PID-) oder einen Fuzzy-Logik-Steuerungsfunktionsblock sowie einen einzelnen Ausgabeblock wie beispielsweise einen Analogausgabe- (AE-) Funktionsblock auf. Diese Steuerungskreise führen typischerweise eine Steuerung mit einem einzelner Eingabe/einzelnen Ausgabe aus, da der Steuerungsblock eine einzelne Ausgabe erzeugt, die der Steuerung einer einzelnen Prozesseingabe wie beispielsweise einer Ventilposition etc. dient. In bestimmten Fällen ist jedoch die Verwendung einer Anzahl unabhängig arbeitender Steuerungskreise mit einer einzelnen Eingabe/einzelnen Ausgabe nicht sehr effizient, da die gesteuerten Prozessvariablen von mehr als einer einzelnen Prozesseingabe bewirkt werden und da tatsächlich jede Prozesseingabe den Zustand vieler Prozessausgaben bewirken kann. In diesen Fällen kann die Verwendung von Steuerungskreisen mit einer einzelnen Eingabe/einzelnen Ausgabe dazu führen, dass die Prozessausgaben schwanken, ohne jemals einen stabilen Zustand bzw. einen eingeschwungenen Zustand zu erreichen, was nicht wünschenswert ist.
In der Vergangenheit wurden modellprädiktive Steuerungen oder andere Arten erweiterter Steuerungen eingesetzt, um in derartigen Situationen Steuerungsfunktionen auszuführen. Allgemein gesagt, ist die modellprädiktive Steuerung eine Steuerungsstrategie mit multiplen Eingaben/multiplen Ausgaben, wobei die Auswirkungen einer Veränderung einer jeden einer Anzahl von Prozesseingaben auf jede einer Anzahl von Prozessausgaben gemessen und diese gemessenen Reaktionen sodann verwendet werden, um ein Modell des Prozesses zu erzeugen. Das Modell des Prozesses wird mathematisch invertiert und sodann innerhalb einer Steuerung mit multiplen Eingaben/multiplen Ausgaben benutzt, um die Prozessausgaben auf der Grundlage von Veränderungen der Prozesseingaben zu steuern. In einigen Fällen weist das Prozessmodell für jede der Prozesseingaben eine Prozessausgabe-Antwortkurve auf oder ist aus einer Prozessausgabe-Antwortkurve für jede der Prozesseingaben entwickelt, wobei diese Kurven beispielsweise auf der Grundlage pseudozufälliger Sprungänderungen an jedem der Prozesseingänge erzeugt werden können. Diese Antwortkurven können auf bekannte Weise zur Modellierung des Prozesses verwendet werden. Die modellprädiktive Steuerung ist in der Fachwelt bekannt und wird daher hier nicht im Detail beschrieben. Eine allgemeine Beschreibung der modellprädiktiven Steuerung findet sich jedoch bei Qin, S., Joe und Thomas A. Badgwell in "An Overview of Industrial Model Predictive Control Technology" [Übersicht über die industrielle modellprädiktive Steuerungstechnologie], AIChE-Konferenz 1996.
Darüber hinaus wurden die Erzeugung und Verwendung erweiterter Steuerungsroutinen wie beispielsweise von MPC-Steuerungsroutinen in den Konfigurierungsprozess für eine Steuerung für eine Prozessanlage integriert. So beschreiben beispielsweise Wojsznis et al., U.S. Patent Nr. 6,445,963 mit dem Titel "Integrated Advanced Control Blocks in Process Control Systems" [Integrierte erweiterte Steuerungsblöcke in Prozesssteuerungssystemen], dessen Offenlegungsschrift hiermit durch Verweis ausdrücklich zum Bestandteil der vorliegenden Beschreibung gemacht wird, ein Verfahren zur Erzeugung eines erweiterten Steuerungsblocks wie einer erweiterten Steuerung (beispielsweise einer MPC-Steuerung oder einer neuronalen Netzwerksteuerung) mittels Daten, die während der Konfigurierung der Prozessanlage aus dieser gesammelt wurden. Spezifischer beschreibt das U.S. Patent Nr. 6,445,963 ein Konfigurierungssystem, das einen erweiterten Steuerungsblock mit multiplen Eingaben und multiplen Ausgaben innerhalb eines Prozesssteuerungssystems auf eine Axt und Weise erzeugt, die in das Erzeugen und Herunterladen anderer Steuerungsblöcke mittels eines spezifischen Steuerungsparadigmas wie beispielsweise des Feldbus-Paradigmas integriert ist. In diesem Fall wird der erweiterte Steuerungsblock initiiert, indem ein Steuerungsblock erzeugt wird, der gewünschte Eingaben und Ausgaben aufweist, die mit Prozessausgaben bzw. Prozesseingaben zu verbinden sind, um einen Prozess zu steuern. Der Steuerungsblock weist eine Datensammlungsroutine und einen dieser zugeordneten Wellenformgenerator auf und kann Steuerungslogik aufweisen, die nicht eingestellt oder auf sonstige Weise unentwickelt ist, weil diese Logik nicht über zu implementierende Abstimmparameter, Matrixkoeffizienten oder andere Steuerungsparameter verfügt. Der Steuerungsblock befindet sich innerhalb des Prozesssteuerungssystems mit den definierten Eingaben und Ausgaben, die kommunikativ mit dem Steuerungssystem dergestalt verbunden sind, dass diese Eingaben und Ausgaben verbunden würden, wenn der erweiterte Steuerungsblock zur Steuerung des Prozesses verwendet würde. Während einer Testprozedur irritiert sodann der Steuerungsblock systematisch jede der Prozesseingaben über die Ausgaben des Steuerungsblocks mittels Wellenformen, die vom Wellenformgenerator erzeugt wurden, der eigens zur Verwendung bei der Entwicklung eines Prozessmodells konstruiert wurde. Über die Eingaben des Steuerungsblocks koordiniert der Steuerungsblock sodann die Sammlung von Daten, die zur Antwort einer jeden der Prozessausgaben auf jede der erzeugten Wellenformen, denen jede der Prozesseingaben ausgesetzt wurde, gehören. Diese Daten können beispielsweise an einen Daten-Historienspeicher zur Speicherung gesendet werden. Nachdem ausreichend Daten für jedes der Prozesseingabe-/Ausgabepaare gesammelt wurden, wird eine Prozessmodellierungsroutine ausgeführt, in der beispielsweise mittels jeder bekannten oder gewünschten Modellerzeugungsroutine eines oder mehrere Prozessmodelle aus den gesammelten Daten erzeugt werden. Als Bestandteil dieser Modellbestimmungsroutine entwickelt eine Modellparameterbestimmungsroutine die Modellparameter wie beispielsweise Matrixkoeffizienten, Totzeit, Verstärkung, Zeitkonstanten etc., die von der Steuerungslogik für die Steuerung des Prozesses zu verwenden sind. Die Parameter der Steuerungslogik und, falls erforderlich, das Prozessmodell werden sodann in den Steuerungsblock heruntergeladen, um die Bildung des erweiterten Steuerungsblocks abzuschließen, damit der erweiterte Steuerungsbock mit den darin enthaltenen Modellparametern und/oder dem darin enthaltenen Prozessmodell zur Steuerung des Prozesses verwendet werden kann.
Während diese Technik des Erzeugens und Herunterladens einer Prozesssteuerung innerhalb einer Prozessanlage zwar nützlich ist, hängt sie jedoch in starkem Maße von der Fähigkeit der Modellerzeugungssoftware ab, ein Prozessmodell aus den Daten erzeugen oder generieren zu können, die während der Testphase aus der Prozessanlage gesammelt wurden. So ist tatsächlich die Entwicklung eines Prozessmodells die wichtigste Stufe beispielsweise bei der Implementierung einer MPC-Steuerung und die Qualität des Modells bestimmt zum überwiegenden Teil den Erfolg der Anwendung. Der Prozess des Erzeugens und Validierens des Prozessmodells, das zur Verwendung im erweiterten Steuerungsblock generiert wurde, ist mithin von größter Bedeutung.
Allgemein gesagt, kann Software zur Erzeugung von Prozessmodellen unterschiedliche Typen von Modellen erzeugen einschließlich nichtparametrischer Modelle wie beispielsweise finite Impulsantwortmodelle (FIR) und parametrische Modelle wie beispielweise autoregressive Modelle mit externen Eingaben (ARX). Während die FIR-Modellerzeugungsroutine generell in der Lage ist, ein FIR-Modell zu erzeugen, haben FIR-Modelle wegen der Größe des für die Definition des Modells benötigten Speicher und der Anzahl der für die Modellentwicklung benötigten Berechnungen generell Nachteile in MPS-Steuerungen. Während ARX- und andere parametrische Modelle weniger Speicher für die Definition von Modellen und weniger Berechnungen benötigen, gibt es zahlreiche Situationen, in denen Software zur Erzeugung parametrischer Modelle nicht in der Lage ist, überhaupt ein parametrisches Prozessmodell zu erzeugen, weil diese Software nicht in der Lage ist, eine Lösung für die Modellparameter zu entwickeln. So ist insbesondere bekannt, dass auf regressiven Algorithmen basierende Modellerzeugungstechniken wie beispielsweise Kleinste-Quadrate-Techniken Probleme haben, eine Lösung zu entwickeln. In diesem Fall mögen die ermittelten Modellparameter zwar mathematisch akkurat sein, sind jedoch nicht repräsentativ für die wahren Parameter. Da ARX- und andere parametrische Modelle typischerweise keine exakte Schätzung der Totzeit des Prozesses erzeugen, sind sie für derartige Probleme anfälliger, was zur Unfähigkeit, ein Modell zu erzeugen, oder zu einem Modell, dessen Parameter numerisch ungültig sind, führt.
In beiden Fällen erzeugt die Unfähigkeit der Modellerzeugungssoftware zur Erzeugung eines parametrischen Modells ein Problem, da der Entwickler der Steuerung sodann manuelle Schritte ausführen muss, um ein zur Verwendung adäquates oder geeignetes parametrisches Modell zu bestimmen. In der Vergangenheit haben Anwender beispielsweise in dem Versuch, die Software zur Erzeugung eines parametrischen Modells in die Lage zu versetzen, einen Satz von Modellparametern zu entwickeln, den zur Erzeugung des Modells verwendeten Prozessdaten weitere Daten hinzugefügt, in stärkerem Maß die Spezifikation verschiedener Parameter wie beispielsweise der Totzeit oder einer oder mehrerer Zeitkonstanten versucht oder die Größenordnung der Sprünge in den zur Erzeugung der Prozessdaten verwendeten Prozessirritationssignalen verändert. Bedauerlicherweise eignet sich keiner dieser Schritte auch nur näherungsweise gut oder sonderlich konsistent, um konvergierende Modellparameter eines parametrischen Modells zu ermöglichen. Darüber hinaus verlangt die Ausführung manueller Schritte zur Veränderung der Modellerzeugungsumgebung, dass der Steuerungsentwickler über das entsprechende Wissen und Erfahrung in Bezug auf den gesteuerten Prozess sowie über die geeigneten Analysewerkzeuge zur Bestimmung eines geeigneten Modells verfügt. In vielen Situationen fehlt eines oder beide dieser Elemente, was den Steuerungsentwickler dazu führt, einen anderen Steuerungsformattyp zu wählen.
Wenn aus den Daten tatsächlich ein Modell erzeugt wird, kann eine Uberprüfung und Validierung des Prozessmodells durchgeführt werden, um die Genauigkeit des Prozessmodells zu prüfen und eine gute Aussage hinsichtlich der geforderten Robustheit der Steuerung zu erhalten. Wenn das Modell beispielsweise eine signifikante Fehlanpassung an den Prozess zeigt, sollte die Steuerung robuster sein. Eine typische Modellidentifizierungsprozedur beinhaltet die Durchführung einer qualitativen Validierung der Modellvorhersagen, das Verifizieren und Editieren der Modellparameter, die Durchführung einer statistischen Modellvalidierung sowie die Durchführung einer Modellsimulation. Insbesondere verwendet die Simulationssoftware während der qualitativen Validierung des Modellvorhersageschritts reale Prozesseingabedaten als Modelleingaben und trägt die tatsächlichen Ausgaben des Prozesses gegen die vorhergesagte Ausgabe für einen bekannten Datensatz auf.
Während des Verifizierungsschritts führt ein Anwender eine visuelle, beispielsweise grafische, Prüfung der einzelnen Sprungantworten) für das/die Prozessmodelle) auf der Grundlage der Kenntnis des Prozesses durch, um zu verifizieren, dass diese Sprungantworten im erwarteten Bereich sind. Bekannte Tools, die einen Anwender in die Lage versetzen, eine Sprungantwort numerisch und grafisch zu konzipieren und zu editieren, ermöglichen es dem Anwender, das Modell auf der Grundlage (1) der Kenntnis des Prozesses, (2) von durch Beobachtung von Messungstrends und Simulationen erhaltenen Informationen sowie (3) des erhaltenen Prozessmodells zu korrigieren.
Sodann wird während einer statistischen Modellvalidierungsphase die Modellunsicherheit mittels statistischer Techniken quantifiziert. Diese statistischen Techniken können die Berechnung von Validierungsfehlern zwischen tatsächlichen und vorhergesagten Ausgaben wie beispielsweise den Effektivwert etc. beinhalten. Bei den unbefriedigenden Modellen ist der mittlere quadratische Fehler recht hoch (beispielsweise 2,4 Prozent pro Scan). Als Faustregel mag gelten, dass im Falle eines durchschnittlichen Ausgabefehlers von mehr als einem Prozent pro Scan die entsprechenden Sprungantworten genauer überprüft werden sollten. Eine weitere statistische Technik, die genutzt werden kann, ist eine Korrelationsanalyse der Validierungsfehler oder Reste, die die Autokorrelation der Reste und/oder die Kreuzkorrelation zwischen Resten und den Prozesseingaben untersucht. Darüber hinaus können Frequenzübertragungsfunktionen von Prozessmodell und Resten berechnet und Unsicherheitsgrenzen in der Frequenzdomäne benutzt werden, um die Qualität des Modells über den betrachteten Frequenzbereich anzugeben.
Ein nützlicher Weg der Definition der Modellqualität auf der Grundlage der entwickelten Modellparameter nutzt das Konzept der Modellkonfidenzintervalle, die einen Bereich der Parameterwerte eines spezifischen Modells innerhalb einer vorher definierten Wahrscheinlichkeit, üblicherweise 95 %, angeben. Dies bedeutet, dass Konfidenzintervalle den Bereich der Modellparameterwerte definieren, innerhalb dessen die Parameterwerte mit der vorher definierten Wahrscheinlichkeit vorhersagegemäß liegen werden. Konfidenzintervalle bieten insoweit sehr wichtige implizite Informationen über die Modellidentifizierung, als größere Konfidenzintervalle ein weniger genaues Modell implizieren. Es ist daher allgemein akzeptiert, dass enge Konfidenzintervalle wünschenswerter sind. Andererseits implizieren größere Konfidenzintervalle eine bessere Konvergenz der Modellparameter, was beispielsweise dann wünschenswert ist, wenn die Ordnung des Modells nicht der Komplexität des Prozesses entspricht oder wenn ein lineares Modell zur Modellierung von Prozessen mit signifikanter Nichtlinearität verwendet wird. Während Konfidenzintervalle einem Anwender helfen, ein Modell zu verifizieren, unterstützen sie ihn jedoch nicht beim Verändern des Modells, um das Modell besser oder genauer zu machen.
Nach der grafischen Betrachtung und einem eventuellen Editieren des Prozessmodells und der Antworten des Prozessmodells liefert abschließend eine MFC-Simulation mittels des Prozessmodells dem Anwender eine Vorstellung der Fehlanpassung des Prozessmodells. Darüber hinaus bietet die Simulationen eine "Was-wäre-wenn"-Analyse vor Inbetriebnahme der Steuerung.
Diese Techniken werden zwar routinemäßig beim Auschecken des MPC-Modells verwendet, weisen jedoch inhärente Nachteile auf. So sind sowohl visuelle Beobachtungen der Vorhersagequalität und berechnete Validierungsfehler (Effektivwerte, Reste etc.) lediglich ein Indiz dafür, dass die Ausgabevorhersage fragwürdig sein kann. Darüber hinaus liefert ein auf eine Modellfehlanpassung hinweisender Simulationsfehler keine Informationen, die zur Verbesserung des Modells genutzt werden können. Entsprechend beweisen numerische und grafische Tools zum Entwickeln und Editieren von Sprungantworten ihre Eignung nur in Verbindung mit fachkundiger Kenntnis des Prozesses. Während Sprungantworten mithin zur Validierung von Verstärkungsparametern untersucht werden können, sind andere wichtige Informationen wie beispielsweise Dynamik, Größe der Verstärkung und Zeitkonstanten, die erheblichen Einfluss auf die resultierende Steuerung haben, nicht unbedingt für den Anwender erkennbar. Eine häufige Quelle von Ungenauigkeiten ist beispielsweise die Prozesstotzeit. Dieser Parameter ist dem Anwender im Allgemeinen nicht exakt bekannt und ist daher in Modellentwicklungs- und Editierprozess nicht leicht zu berücksichtigen.
Weiterhin wurden rauschbehaftete Daten, ungenügende Prozesserregung sowie eine zu kurze Testzeit für die Datensammlung als Probleme erkannt, die zu einem Modell führen können, das für Steuerungszwecke nicht befriedigend ist. Gleichwohl kann es vorkommen, dass die Anlagenbedingungen keinen besseren Test zulassen. Darüber hinaus haben statistische Auswertungen wie beispielsweise Autokorrelation und Kreuzkorrelation, auch wenn diese für die Bereitstellung quantitativer Modellinformationen nützlich sind, dasselbe Problem, d.h. nichtspezifische Informationen.
Trotz Kenntnis der Modellungenauigkeit ist es mithin schwierig, Abhilfemaßnahmen zu bestimmen oder umzusetzen. Diese Tatsache erfordert oftmals eine Neuidentifizierung des Modells mittels eines anderen oder eines unterschiedlichen Datensatzes, obwohl lediglich ein kleiner Teil des Modells die Ursache für die Fehlanpassung sein kann. Die Situation wird dadurch noch weiter erschwert, dass die bestimmbaren Modellfehlanpassungsinformationen in dem Prozess der Erzeugung der Steuerung tatsächlich nicht widergespiegelt werden. Die wahre Qualität des Modells ist daher erst dann bekannt, wenn die Steuerung in Betrieb genommen und ihre Leistung gemessen wurde. Dies führt zu erheblichen Verlusten an Zeit, Geld und Ressourcen und schreckt Anlagenpersonal von der Verwendung der MPC-Technologie ab.
Insoweit ist der Ausdruck von Konfidenzintervallen in der Zeitdomäne eine viel versprechende anzuwendende Technik, da sie Spezifika der Modellqualität in Form konkreter Parameter für einzelne Sprungantworten liefert. Diese Technik führt auch zu einer Neuidentifikation und/oder Korrektur lediglich eines spezifischen Teils des Modells. Gleichemaßen wichtig ist, dass die Kenntnis der Fehler spezifischer Parameter die Auswahl derjenigen Einstellungen bei der Erzeugung der MPC-Steuerung erleichtert, die zu einer robusten Steuerung führen. Darüber hinaus beseitigt die Darstellung in der Zeitdomäne die Komplexität der Verwendung einer derartigen Qualitätsvariablen.
Während die Verwendung von Konfidenzintervallen in der Zeitdomäne zwar bei der Auswertung eines erzeugten Prozessmodells nützlich ist, ist es jedoch nach wie vor wünschenswert, zunächst eine robuste Methode zur Erzeugung eines Prozessmodells wie beispielsweise bei der Erzeugung einer MPC-Steuerung bereitzustellen, statt Tests mit unzureichender Erregung, kurzen Zeitrahmen für die Datensammlung, Modelleinschränkungen wie beispielsweise Modell- und Prozesskomplexitätsfehlanpassung (beispielsweise entspricht die Ordnung des Modells nicht der Komplexität des Prozesses oder ein lineares Modell wird verwendet, um Prozesses mit signifikanter Nichtlinearität zu modellieren) durchzuführen.
Zusammenfassung
Es wurde überraschenderweise festgestellt, dass ein robustes Verfahren zur Erzeugung von Prozessmodellen zur Anwendung bei der Erzeugung von Steuerungen wie beispielsweise der Erzeugung einer MPC-Steuerung und insbesondere bei der Erzeugung parametrischer Prozessmodelle erhalten wird, wenn den Prozessdaten, die vom Prozess gesammelt und im Prozess der Modellgenerierung verwendet werden, tatsächlich Rauschen hinzugefügt wird. Insbesondere sammelt ein robustes Verfahren zur Erzeugung eines Prozessmodells wie beispielsweise eines parametrischen Prozessmodells Prozessausgaben auf der Grundlage bekannter Testeingabesignale oder Sequenzen, fügt den gesammelten Prozessdaten Rauschen wie beispielsweise zufälliges Rauschen hinzu und verwendet sodann eine Standard- oder bekannte Technik, um ein Prozessmodell aus den gesammelten Prozessdaten zu bestimmen. So wurde tatsächlich im Gegensatz zu früheren Verfahren, bei denen versucht wurde, vor Erzeugung eines Prozessmodells Rauschen zu säubern oder aus den Prozessdaten zu entfernen, festgestellt, dass ein Hinzufügen von Rauschen zu den Prozessdaten in vielen Fällen die Erzeugung eines akzeptablen Prozessmodells in Situationen ermöglicht, in denen ohne Hinzufügen von Rauschen kein akzeptables Prozessmodell desselben Typs erzeugt werden konnte. Weiterhin wurde festgestellt, dass mittels dieser Technik erzeugte Prozessmodelle allgemein größere Konfidenzintervalle haben und somit ein Modell bereitstellen, dass sich in erweiterte Konfidenzintervalle einfügt, die zahlreichen Prozesskomplexitäten Rechnung tragen, ohne dass es erforderlich ist, das Modellerzeugungsumfeld manuell oder grafisch zu verändern.
In einer Anwendung dieser Technik erzeugt eine Routine zur Erzeugung eines erweiterten Steuerungsblock mittels einer Routine zur Erzeugung eines robusten Prozessmodells einen Block mit multiplen Eingaben/multiplen Ausgaben wie beispielsweise eine modellprädiktive Steuerung, einen ein neuronales Netzwerk modellierenden Block oder einen Steuerungsblock etc. innerhalb eines Prozesssteuerungssystems. Der erweiterte Steuerungsblock kann initiiert werden, indem ein Steuerungsblock erzeugt wird, der gewünschte Eingaben und Ausgaben aufweist, die mit Prozessausgaben bzw. Prozesseingaben zu verbinden sind, um einen Prozess zu steuern. Der Steuerungsblock kann dazu dienen, letztlich beispielsweise eine komplette modellprädiktive Steuerung zu beinhalten, weist anfänglich jedoch eine Datensammlungsroutine und einen dieser zugeordneten Wellenformgenerator auf. Falls gewünscht, kann der Steuerungsblock eine Steuerungslogik aufweisen, die nicht eingestellt oder auf sonstige Weise unentwickelt ist, weil diese Logik nicht über Abstimmparameter, Matrixkoeffizienten oder andere Modellparameter verfügt, die für die Implementierung der Steuerung erforderlich sind. Der Steuerungsblock befindet sich innerhalb des Prozesssteuerungssystems mit den definierten Eingaben und Ausgaben, die kommunikativ mit dem Steuerungssystem dergestalt verbunden sind, dass diese Eingaben und Ausgaben verbunden würden, wenn der erweiterte Steuerungsblock zur Steuerung des Prozesses verwendet würde. Während einer Testprozedur irritiert der Steuerungsblock systematisch jede der Prozesseingaben über die Ausgaben des Steuerungsblocks mittels Wellenformen, die vom Wellenformgenerator erzeugt wurden, der eigens zur Verwendung bei der Entwicklung eines Prozessmodells konstruiert wurde. Der Steuerungsblock koordiniert die Sammlung von Daten, die zur Reaktion einer jeden der Prozessausgaben auf jede der erzeugen Wellenformen, denen jede der Prozesseingaben ausgesetzt wurde, gehören. Diese Daten können beispielsweise an einen Daten-Historienspeicher zur Speicherung gesendet werden.
Nachdem ausreichend Daten gesammelt wurden, wird eine Prozessmodellierungsroutine ausgeführt, in der den gesammelten Prozessausgabedaten Rauschen hinzugefügt wird. Dieses Rauschen kann beispielsweise gleichmäßig verteiltes Rauschen mit dem Erwartungswert Null mit einer maximalen Amplitude von ca. 0,20 bis ca. 0,5 Prozent der Bandbreite der Größenordnung der Prozessausgabedaten und bevorzugt gleichmäßig verteiltes Rauschen mit dem Erwartungswert Null mit einer maximalen Amplitude von ca. 0,4 Prozent der Bandbreite der Größenordnung der Prozessausgabedaten sein. Ein Prozessmodell wie beispielsweise ein parametrisches Prozessmodell wird sodann mittels einer Routine zur Erzeugung eines modellprädiktiven Steuerungsprozessmodells wie beispielsweise einer Routine zur Erzeugung eines ARX-Modells aus den gesammelten (und rauschbehafteten Daten) erzeugt. Anschließend erzeugt oder entwickelt eine Steuerungsblocklogik die Parameter, die von der Steuerungslogik zu verwenden sind, um den Prozess zu steuern. Falls gewünscht, kann das erzeugte Prozessmodell validiert werden und die Validierungsergebnisse können für den Anwender in Form eines Konfidenzplots angezeigt werden, der eine oder mehrere Konfidenzregionen für das Modell darstellt. Falls gewünscht, können die Konfidenzplots zeitdomänebasierte Konfidenzplots sein, die den Anwender in die Lage versetzen zu bestimmen, wo das Modell nicht mit der Prozessantwort übereinstimmt, und den betreffenden Teil des Modells erforderlichenfalls zu verändern.
Nach dem Testen oder Betrachten des sich ergebenden Prozessmodells werden die Parameter der Steuerungslogik und das Prozessmodell sodann in den Steuerungsblock heruntergeladen, um die Bildung des erweiterten Steuerungsblocks abzuschließen, damit der erweiterte Steuerungsbock mit den darin enthaltenen Parametern der erweiterten Steuerungslogik und/oder dem darin enthaltenen Prozessmodell zur Steuerung des Prozesses verwendet werden kann.
Kurzbeschreibung der Zeichnungen
1 ist ein Blockdiagramm/ein schematisches Diagramm eines Prozesssteuerungssystems, in dem ein erweiterter Steuerungsblock mittels einer in dieser Offenlegungsschrift beschriebenen Technik zur Erzeugung eines robusten Prozessmodells erzeugt werden kann.
2 ist ein Flussdiagramm, das den Betrieb und die Erzeugung eines erweiterten Steuerungsblocks innerhalb des Prozesssteuerungssystems in 1 darstellt;
3 ist ein Blockdiagramm eines modellprädiktiven Steuerungsblocks, der mit einer Prozesssteuerungsroutine zur Steuerung eines Prozesses verbunden ist;
4 ist ein Beispiel einer Bildschirmanzeige, die einem Anwender während des Prozesses der Erzeugung einer MPC-Steuerungsroutine präsentiert werden kann und die den Anwender in die Lage versetzt, gesammelten Prozessdaten Rauschen hinzuzufügen, bevor eines oder mehrere Prozessmodelle aus den gesammelten Prozessdaten erzeugt werden;
5 ist ein Flussdiagramm einer ersten robusten Methode zur Erzeugung eines Prozessmodells aus einem Satz von Testdaten, die aus einem Prozess mittels Hinzufügung von zufälligem Rauschen gesammelt wurden;
6 ist ein Flussdiagramm einer zweiten robusten Methode zur Erzeugung eines parametrischen Prozessmodells aus einem Satz von Testdaten, die aus einem Prozess mittels Hinzufügung von zufälligem Rauschen gesammelt wurden;
7–9 zeigen Konfidenzintervallplots, die die Ergebnisse eines nichtparametrischen und eines parametrischen Modells zeigen, die mittels der in dieser Offenlegungsschrift beschriebenen robusten Technik zur Modellidentifizierung erzeugt wurden, und
10–20 zeigen die Ergebnisse einer Technik zur Erzeugung eines Prozessmodells mittels Prozessdaten, denen Rauschen sowohl für ein FIR-Modell als auch für ein ARX-Modell für diverse unterschiedliche Testdaten hinzugefügt wurde.
Detaillierte Beschreibung
Wie in 1 dargestellt, weist ein Prozesssteuerungssystem 10 eine Prozesssteuerung 11 auf, die mit einem Daten-Historienspeicher 12 und mit einer oder mehreren Host-Workstations oder Computern 13 (wobei es sich um jeden beliebigen Typ von Personal Computer, Workstation etc. handeln kann) verbunden ist, die jeweils einen Bildschirm 14 besitzen. Die Steuerung 11 ist weiterhin über die Eingabe/Ausgabe- (E/A-) Karten 26 und 28 mit den Feldgeräten 15–22 verbunden. Der Daten-Historienspeicher 12 kann jeder gewünschte Typ von Datensammlungseinheit mit jedem gewünschten Speichertyp und jeder gewünschten oder bekannten Software, Hardware oder Firmware zur Speicherung von Daten sein und kann (wie in 1 dargestellt) von den Workstations 13 getrennt oder Bestandteil einer der Workstations 13 sein. Die Steuerung 11, die beispielsweise die von Emerson Process Management vertriebene DeltaV-Steuerung sein kann, ist beispielsweise über eine Ethernet-Verbindung oder jedes andere gewünschte Kommunikationsnetzwerk kommunikativ mit den Host-Computern 13 und dem Daten-Historienspeicher 12 verbunden. Die Steuerung 11 ist ebenfalls mittels jeder gewünschten Hardware und Software beispielsweise in Verbindung mit Standard-4-20-mA-Geräten und/oder jedem intelligenten Kommunikationsprotokoll wie beispielsweise dem Feldbus-Protokoll, dem HART-Protokoll etc. kommunikativ mit den Feldgeräten 15–22 verbunden.
Die Feldgeräte 15–22 können jeder Typ von Gerät wie beispielsweise Sensoren, Ventile, Geber, Steller etc. sein, während die E/A-Karten 26 und 28 jeder Typ von E/A-Gerät sein können, das jedem gewünschten Kommunikations- oder Steuerungsprotokoll entspricht. In der in 1 dargestellten Ausführung handelt es sich bei den Feldgeräten 15–18 um Standard-4-20-mA-Geräte, die über analoge Leitungen mit der E/A-Karte 26 kommunizieren, während es sich bei den Feldgeräten 19–22 um intelligente Geräte wie beispielsweise Feldbus-Feldgeräte handelt, die über einen digitalen Bus per Feldbus-Protokollkommunikation mit der E/A-Karte 28 kommunizieren. Allgemein gesagt, ist das Feldbus-Protokoll ein vollständig digitales, serielles, bidirektionales Kommunikationsprotokoll, das eine standardisierte physikalische Schnittstelle für einen 2-Draht-Kreis oder -Bus darstellt, der zur Verbindung von Feldgeräten dient. Das Feldbus-Protokoll stellt letztlich ein lokales Netzwerk für Feldgeräte innerhalb eines Prozesses dar und versetzt diese Feldgeräte in die Lage (unter Verwendung von entsprechend dem Feldbus-Protokoll definierten Funktionsblöcken), an über eine Prozessanlage verteilten Orten Prozesssteuerungsfunktionen auszuführen und vor und nach der Ausführung dieser Prozesssteuerungsfunktionen miteinander zu kommunizieren, um eine übergeordnete Steuerungsstrategie zu implementieren. Selbstverständlich könnten die Feldgeräte 15–22 jedem anderen gewünschten Standard oder allen anderen gewünschten Standards oder Protokollen einschließlich aller künftig entwickelten Standards oder Protokolle entsprechen.
Die Steuerung 11 implementiert oder überwacht eine oder mehrere Prozesssteuerungsroutinen, die Steuerungskreise aufweisen können, die darin enthalten oder auf sonstige Weise damit verbunden sind, und kommuniziert mit den Geräten 15– 22, den Host-Computern 13 und dem Daten-Historienspeicher 12, um einen Prozess auf jede gewünschte Weise zu steuern. Es ist darauf hinzuweisen, dass, falls gewünscht, Teile jeder hier beschriebenen Steuerungsroutine oder jedes hier beschriebenen Elements von verschiedenen Steuerungen oder anderen Einrichtungen implementiert oder ausgeführt werden können. Entsprechend können die hier beschriebenen, innerhalb des Prozesssteuerungssystems 10 zu implementierenden Steuerungsroutinen oder Elemente jede Form einschließlich Software, Firmware, Hardware etc. annehmen. Ein Prozesssteuerungselement kann für die Zwecke dieser Erfindung jeder Teil eines Prozesssteuerungssystems einschließlich beispielsweise einer Routine, eines Blocks oder eines Moduls sein, die in jedem beliebigen computerlesbaren Medium gespeichert sind. Steuerungsroutinen, die Module oder jeder beliebige Teil einer Steuerungsprozedur wie beispielsweise eine Subroutine, Teile einer Subroutine (wie beispielsweise Codezeilen) etc. sein können, können in jedem gewünschten Softwareformat implementiert werden, beispielsweise unter Verwendung von Leiterlogik, Ablaufsprache, Funktionsblockdiagrammen oder unter Verwendung jeder anderen Software-Programmiersprache oder jedes anderen Konstruktionsparadigmas. Entsprechend können die Steuerungsroutinen beispielsweise in einen oder mehrere EPROMs, EEPROMs, anwendungsspezifische integrierte Schaltungen (ASICs) oder beliebige andere Hardware- oder Firmware-Elemente hardcoded werden. Weiterhin können die Steuerungsroutinen mittels beliebiger Entwicklungstools einschließlich grafischer Entwicklungstools oder jeder beliebigen anderen Art von Software-/Hardware/Firmware-Programmierung oder Entwicklungswerkzeugen entwickelt werden. Die Steuerung 11 kann mithin konfiguriert werden, um eine Steuerungsstrategie oder Steuerungsroutine auf jede gewünschte Weise zu implementieren.
In einer Ausführung implementiert die Steuerung 11 eine Steuerungsstrategie mittels allgemein so genannter Funktionsblöcke, wobei jeder Funktionsblock ein Teil (beispielsweise eine Subroutine) einer umfassenden Steuerungsroutine ist und (über als Verbindungen bezeichnete Kommunikationswege) in Verbindung mit anderen Funktionsblöcken arbeitet, um Prozesssteuerungskreise innerhalb des Prozesssteuerungssystems 10 zu implementieren. Funktionsblöcke führen typischerweise eine der folgenden Funktionen aus: eine Eingabefunktion, die beispielsweise mit einem Geber, einem Sensor oder einem anderen Gerät zur Messung eines Prozessparameters verbunden ist, eine Steuerungsfunktion, die beispielsweise mit einer Steuerungsroutine verbunden ist, die eine PID-, Fuzzy-Logik- oder eine andere Steuerungsfunktion ausführt, oder eine Ausgabefunktion, die den Betrieb einer Einrichtung wie beispielsweise eines Ventils steuert, um eine physikalische Funktion innerhalb des Prozesssteuerungssystems 10 auszuführen. Selbstverständlich existieren hybride und andere Arten von Funktionsblöcken. Funktionsblöcke können in der Steuerung 11 gespeichert und von dieser ausgeführt werden, was typischerweise der Fall ist, wenn diese Funktionsblöcke für Standard-4-20-mA-Geäte und einige Typen von intelligenten Feldgeräten wie beispielsweise HART-Geräte verwendet werden oder mit diesen verbunden sind, oder sie können in den Feldgeräten selbst gespeichert und von diesen implementiert werden, was bei Feldbus-Geräten der Fall sein kann. Während die Beschreibung des Steuerungssystems hier anhand einer Funktionsblock-Steuerungsstrategie erfolgt, könnten die Steuerungsstrategie oder die Steuerungskreise oder Module auch mit anderen Konventionen wie beispielsweise Leiterlogik, Ablaufsprache etc. oder mittels jeder anderen gewünschten Programmiersprache oder jedes anderen gewünschten Paradigmas implementiert oder entwickelt werden.
Wie durch den in Explosionsdarstellung gezeigten Block 30 in 1 dargestellt, kann die Steuerung 11 eine Anzahl von Ein-Kreis-Steuerungsroutinen, die als Routinen 32 und 34 dargestellt sind, und, falls gewünscht, einen oder mehrere erweiterte bzw. fortschrittliche Steuerungskreise, dargestellt als Steuerungskreis 36, aufweisen.
Jeder derartige Kreis wird typischerweise als Steuerungsmodul bezeichnet. Die Ein-Kreis-Steuerungsroutinen 32 und 34 führen, wie dargestellt, eine Signalkreissteuerung mittels eines Fuzzy-Logik-Steuerungsblocks mit einer einzelnen Eingabe/einer einzelnen Ausgabe und eines PID-Steuerungsblocks mit einer einzelnen Eingabe/einer einzelnen Ausgabe aus, die mit entsprechenden analogen Eingabe- (AE) und analogen Ausgabe- (AA) Funktionsblöcken verbunden sind, die mit Prozesssteuerungsgeräten wie beispielsweise Ventilen, mit Messgeräten wie beispielsweise Temperatur- und Druckgebern oder mit jedem beliebigen anderen Gerät innerhalb des Prozesssteuerungssystems 10 verbunden sein können. Selbstverständlich können die Ein-Kreis-Steuerungsroutinen 32 und 34 alle anderen Typen von Steuerungsblöcken einschließlich modellbasierter Steuerungsblöcke aufweisen. Der erweiterte Steuerungskreis 36 weist entsprechend der Darstellung einen erweiterten Steuerungsblock 38 auf, der Eingänge besitzt, die kommunikativ mit mehreren AE-Funktionsblöcken und Ausgaben verbunden sind, die kommunikativ mit einem oder mehreren AA-Funktionsblöcken verbunden sind, wobei die Eingaben und Ausgaben des erweiterten Steuerungsblocks 38 jedoch auch mit beliebigen anderen gewünschten Funktionsblöcken oder Steuerungselementen verbunden werden können, um andere Typen von Eingaben zu empfangen und andere Typen von Steuerungsausgaben zu liefern. Der erweiterte Steuerungsblock 38 kann jeder Typ eines Steuerungsblocks mit multiplen Eingaben/multiplen Ausgaben sein, der zur Steuerung von zwei oder mehr Prozessausgaben verwendet wird, indem er Steuerungssignale für zwei oder mehr Prozesseingänge zur Verfügung stellt. Während in dieser Beschreibung der erweiterte Steuerungsblock 38 zwar einen modellprädiktiven Steuerungsblock (MPC) verwendet, könnte der erweiterte Steuerungsblock 38 jeder andere Block mit multiplen Eingaben/multiplen Ausgaben wie beispielsweise ein ein neuronales Netzwerk modellierender oder ein Steuerungsblock, ein Steuerungsblock in Form einer Fuzzy Logik mit multiplen Variablen, ein Echtzeit-Optimiererblock etc. sein. Es versteht sich, dass die in 1 dargestellten Funktionsblöcke einschließlich des erweiterten Steuerungsblocks 38 und der Steuerungsblöcke mit einer Eingabe und einer Ausgabe von der Steuerung 11 ausgeführt werden können oder alternativ in einer beliebigen anderen Verarbeitungseinrichtung wie beispielsweise einer der Workstations 13 oder sogar einem der Feldgeräte 19–22 enthalten sein und von diesen ausgeführt werden können.
Wie in 1 dargestellt, weist eine der Workstations 13 eine Steuerungsblock-Erzeugungsroutine 40 auf, die dazu dient, den erweiterten Steuerungsblock 38 auf eine in dieser Offenlegungsschrift ausführlicher beschriebene Weise zu erzeugen, herunterzuladen und zu implementieren. Während die Steuerungsblock-Erzeugungsroutine 40 in einem Speicher innerhalb der Workstation 13 gespeichert und von einem dort enthaltenen Prozessor ausgeführt werden kann, kann, falls gewünscht, diese Routine (oder jeder Teil davon) zusätzlich oder alternativ in einer anderen Einrichtung innerhalb des Prozesssteuerungssystems 10 gespeichert und von dieser ausgeführt werden. Allgemein gesagt, weist die Steuerungsblock-Erzeugungsroutine 40 eine Steuerungsblock-Erzeugungsroutine 42 auf, die einen erweiterten Steuerungsblock erzeugt und diesen erweiterten Steuerungsblock in das Prozesssteuerungssystem hinein verbindet, eine Prozessmodellierungsroutine 44, die ein Prozessmodell für den Prozess oder einen Teil des Prozesses auf der Grundlage von Daten, die vom erweiterten Steuerungsblock gesammelt wurden, erzeugt, sowie eine Routine 46 zur Erzeugung von Steuerungslogikparametern, die Steuerungslogikparameter für den erweiterten Steuerungsblock aus dem Prozessmodell erzeugt und die diese Steuerungslogikparameter zur Verwendung bei der Steuerung des Prozesses im erweiterten Steuerungsblock speichert oder in diesen herunterlädt. Es ist ersichtlich, dass die Routinen 42, 44 und 46 aus einer Reihe verschiedener Routinen bestehen können wie beispielsweise einer ersten Routine, die ein erweitertes Steuerungselement erzeugt, das Steuerungseingaben aufweist, die konfiguriert sind, Prozessausgaben zu empfangen, und das Steuerungsausgaben aufweist, die konfiguriert sind, Signale für Prozesseingaben bereitzustellen, und einer zweiten Routine, die einen Anwender in die Lage versetzt, das erweiterte Steuerungselement innerhalb der Prozesssteuerungsroutine (wobei es sich um jede gewünscht Konfigurierungsroutine handeln kann) kommunikativ zu verbinden, einer dritten Routine, die das erweiterte Steuerungselement verwendet, um Erregungs-Wellenformen für jede der Prozesseingaben bereitzustellen, einer vierten Routine, die das erweiterte Steuerungselement verwendet, um Daten zu sammeln, die der Antwort jeder der Prozessausgaben auf die Erregungs-Wellenformen entsprechen, einer fünften Routine, die ein Prozessmodell aus den gesammelten Daten erzeugt, einer sechsten Routine, die erweiterte Steuerungslogik-Parameter aus dem Prozessmodell entwickelt, sowie einer siebten Routine, die die erweiterte Steuerungslogik und, falls erforderlich, das Prozessmodell innerhalb des erweiterten Steuerungselements anordnet, um das erweiterte Steuerungselement in die Lage zu versetzen, den Prozess zu steuern. Während die Steuerungsblock-Erzeugungsroutine 40 nach der Beschreibung in dieser Offenlegungsschrift verwendet wird, um einen Steuerungsblock mit multiplen Eingaben/multiplen Ausgaben zu erzeugen, könnte die Steuerungsblock-Erzeugungsroutine 40 verwendet werden, um einen Steuerungsblock mit einer einzigen Eingabe/einer einzigen Ausgabe, einen Steuerungsblock mit multiplen Eingaben/einer einzelnen Ausgabe oder einen Steuerungsblock mit einer einzelnen Eingabe/multiplen Ausgaben oder einen anderen Typ eines Blocks wie beispielsweise einen Modellierungsblock etc. zu erzeugen.
In 2 veranschaulicht ein Flussdiagramm 50 die Schritte des Erzeugens und Verwendens eines modellbasierten Steuerungsblocks und insbesondere eines MPC-Steuerungsblocks innerhalb eines Prozesssteuerungssystems wie beispielsweise des Prozesssteuerungssystems 10 in 1 auf eine Weise, die eine robuste Erzeugung eines oder mehrerer Prozessmodelle zur Verwendung im Steuerungsblock beinhaltet. "Robuste Generierung eines Prozessmodells" bedeutet hier, in der Lage zu sein, ein Prozessmodell zu erzeugen, das eine oder mehrere statistische Parameter für eine Prozessanpassung an den Prozess erfüllt, um einen akzeptablen Betrieb des Steuerungsblocks trotz der Anwesenheit verschiedener Faktoren zu bieten, die typischerweise die Fähigkeit zur Erzeugung eines solchen Prozessmodells beschränken, wie beispielsweise minimale Prozessdaten, Prozessmodell-Fehlanpassung und Prozesskomplexitäts-Fehlanpassung etc. Während das Flussdiagramm 50 in 2 die Erzeugung eines MPC-Blocks oder – Moduls darstellt, könnten dieselben oder ähnliche Schritte durchgeführt werden, um jeden anderen modellbasierten Block wie beispielsweise einen Block mit multiplen Eingaben/multiplen Ausgaben wie beispielsweise einen ein neuronales Netzwerk modellierenden oder einen Steuerungsblock, einen Fuzzy-Logik-Steuerungsblock mit multiplen Variablen etc. zu erzeugen und zu verwenden.
Zu einem Anfangszeitpunkt (Block 52) erfolgt eine Entscheidung, durch Implementierung einer MPC-Prozedur die Steuerung innerhalb des Prozesssteuerungssystems 10 zu verbessern oder vorzusehen. Die Entscheidung kann zum selben Zeitpunkt erfolgen, zu dem das Prozesssteuerungssystem 10 erstmals eingerichtet wird, oder zu einem späteren Zeitpunkt, nachdem sich beispielsweise herausgestellt hat, dass andere Steuerungsroutinen wie beispielsweise Ein-Kreis-Steuerungsroutinen eine unzureichende Steuerung leisten. Am Block 52 führt ein Bediener oder ein anderer Anwender die MPC-Block-Erzeugungsroutine 40 aus, um die Schritte des Erzeugens eines MPC-Moduls oder Steuerungskreises innerhalb des Prozesssteuerungssystems zu beginnen. Als Teil dieses Prozesses wählt der Bediener die Prozesseingaben aus, mit denen die Ausgaben des in der Entwicklung befindlichen MPC-Blocks zu verbinden sind, sowie die Prozessausgaben, mit denen die Eingaben des in der Entwicklung befindlichen MPC-Blocks zu verbinden sind. Während der MPC-Block jede beliebige Anzahl von Eingaben und Ausgaben aufweisen kann, weist jeder MPC-Block allgemein drei Arten von Eingaben einschließlich Eingaben gesteuerter Parameter auf, die die Prozessvariablen oder Parameter sind, die auf einem Sollwert (oder innerhalb eines eingestellten Bereichs) zu halten sind, begrenzte Eingaben, die die Prozessvariablen sind, die beispielsweise aufgrund physikalischer Einschränkungen in Verbindung mit dem Prozess auf eine bestimmte Grenze oder einen bestimmten Bereich beschränkt sind und die der MPC-Block nicht auf einen Wert außerhalb des begrenzten Bereichs oder jenseits der Grenze zwingen darf, sowie Prozessstörparametereingaben, die andere Prozessvariablen wie beispielsweise Prozesseingaben sind, von denen bekannt ist, dass sie bei einer Änderung zu Änderungen der gesteuerten Parameter führen. Der MPC-Block verwendet die Prozessstörparametereingaben, um Änderungen der gesteuerten Parameter (d.h. der gesteuerten Prozessausgaben) vorherzusehen und um die Auswirkungen dieser Änderungen zu begrenzen, bevor sie eintreten. Weiterhin können auch weitere Eingaben für den MPC-Block vorgesehen werden wie beispielsweise eine Rückmeldung von einem Gerät oder einem anderen gesteuerten Prozesselement, die den MPC-Steuerungsblock in die Lage versetzt, eine effektivere Steuerung dieser Elemente durchzuführen. Entsprechend können die Ausgaben des MPC-Blocks verbunden werden, um jede gewünschte Prozessvariable oder jede andere Prozesseingabe einschließlich Steuerungskreiseingaben, Gerätesteuerungseingaben etc. zu steuern. Die Routine, die entwickelt wird, indem der MPC-Block mit anderen Steuerungselementen verbunden wird, wird in dieser Offenlegungsschrift als MPC-Modul bezeichnet. Während der Anwender einen MPC-Funktionsblock erzeugen kann, kann der Anwender auch einen initialen Funktionsblock aus einem Speicher wie beispielsweise einer Bibliothek von Funktionsblöcken erhalten und diesen Funktionsblock verwenden oder eine Instanz dieses Funktionsblock zur Verwendung im Prozesssteuerungssystem erzeugen. Gleichermaßen kann ein Anwender oder anderer Anbieter einen Funktionsblock oder ein anderes Steuerungselement auf jede andere gewünschte Weise bereitstellen.
An einem Block 54 erzeugt der Bediener ein MPC-Modul mit einem MPC-Block (der noch nicht über sämtliche Informationen verfügt, die erforderlich sind, um eine modellprädiktive Steuerung bereitzustellen), wobei die spezifizierten Eingaben und Ausgaben kommunikativ mit dem Prozesssteuerungssystem verbunden sind, und lädt den Block oder das Modul in die entsprechende Steuerung oder ein anderes Gerät herunter, die bzw. das das MPC-Modul implementiert. Als Teil dieses Prozesses konfiguriert der Bediener das Prozesssteuerungssystem 10, um den MPC-Block zu implementieren, indem die Ausgaben des MPC-Blocks kommunikativ mit den entsprechenden Prozesseingaben und die Eingaben des MPC-Blocks kommunikativ mit den entsprechenden Prozessausgaben gekoppelt werden.
3 zeigt einen MPC-Block 56, der mit einem Prozess 58 verbunden ist. Der MPC-Block 56 ist ein 3 × 3-Steuerungsblock mit drei Eingaben EIN₁–EIN₃ und drei Ausgaben AUS₁–AUS₃, während der Prozess 58 die Eingaben X₁–X₅ und die Ausgaben Y₁–Y₆ aufweist. Selbstverständlich könnten der MPC-Block 56 und der Prozess 58 jede andere Anzahl von Eingaben und Ausgaben aufweisen. Während der MPC-Block 56 allgemein ein gleichzahliger Block sein kann, d.h. dieselbe Anzahl von Eingaben und Ausgaben aufweist, ist diese Konfiguration nicht notwendig und der MPC-Block 56 kann unterschiedlich viele Eingaben und Ausgaben aufweisen. Wie in 3 dargestellt, verbindet der Bediener die Prozessausgaben Y₁–Y₃ kommunikativ mit den MPC-Blockeingaben EIN₁–EIN₃ und die MPC-Blockausgaben AUS₁–AUS₃ kommunikativ mit den Prozesseingaben X₁–X₃. Selbstverständlich können beliebige der Eingaben und Ausgaben des Prozesses 58 mit anderen Steuerungskreisen oder mit anderen Elementen innerhalb anderer Steuerungsroutinen verbunden sein, die mit dem Prozesssteuerungssystem 10 verbunden sind (wie in 3 durch unterbrochene, mit den Prozesseingaben und -ausgaben verbundene Linien dargestellt). Allgemein sagt, werden der MPC-Block 56 und die anderen Blöcke, die Steuerungseingaben für den Prozess 58 liefern können (wie durch unterbrochene, mit den Prozesseingaben X₁–X₃ verbundene Linien dargestellt), über einen Schalter der einen oder anderen Art verbunden, wobei diese Schalter durch die Quadrate 59 in 3 dargestellt sind. Die Schalter 59 können Hardware- oder Softwareschalter und, falls gewünscht, so ausgeführt sein, dass die unterschiedlichen Steuerungseingangssignale an die verschiedenen Eingaben eines Funktionsblocks wie beispielsweise eines Feldbus-Funktionsblocks gesendet werden, der sodann auf der Grundlage der Betriebsart des die beiden Signale empfangenden Funktionsblocks zwischen dem Steuerungssignal vom MPC-Block 56 und einem Steuerungssignal von einem anderen Funktionsblock wie beispielsweise von einem PID-Funktionsblock wählen kann.
Selbstverständlich kann der Bediener den MPC-Block 56 mit dem Prozess 58 auf jede gewünschte Weise verbinden und verwendet, allgemein gesagt, dieselbe Steuerungskonfiguration oder dasselbe Entwicklungsprogramm, das der Bediener verwendet, um andere Steuerungskreise wie beispielsweise Ein-Kreis-Steuerungsroutinen innerhalb des Prozesssteuerungssystems 10 zu erzeugen. So kann der Bediener beispielsweise jede gewünschte grafische Programmierungsroutine verwenden, um die Verbindungen zwischen dem MPC-Block 56 und den Prozesseingaben und -ausgaben zu definieren. Auf diese Weise wird der MPC-Block 56 auf dieselbe Weise wie andere Steuerungsblöcke, Elemente oder Routinen unterstützt, wodurch das Konfigurieren und Verbinden des MPC-Blocks 56 und die Unterstützung dieses Blocks innerhalb des Steuerungssystems 10 nicht schwieriger sind als das Konfigurieren, Verbinden und Unterstützen der anderen Blöcke innerhalb des Systems. In einer Ausführung sind der MPC-Block 56 sowie die anderen Blöcke innerhalb des Steuerungssystems 10 Funktionsblöcke, die so konstruiert sind, dass sie mit Feldbus-Funktionsblöcken identisch oder diesen ähnlich sind. In dieser Ausführung kann der MPC-Block 56 dieselben oder ähnliche Typen von Eingaben, Ausgaben etc. haben, wie diese im Feldbus-Protokoll spezifiziert oder vorgesehen sind, und er kann beispielsweise von der Steuerung 11 mittels Kommunikationsverbindungen implementiert werden, die mit den vom Feldbus-Protokoll spezifizierten Kommunikationsverbindungen identisch oder diesen ähnlich sind. Ein Verfahren zur grafischen Erzeugung von Prozesssteuerungsroutinen und Elementen solcher Routinen ist in Dove et al. in U.S. Patent Nr. 5,838,563 mit dem Titel "System for Configuring a Process Control Environment" [System zum Konfigurieren einer Prozesssteuerungsumgebung] beschrieben, das hiermit durch Verweis ausdrücklich zum Bestandteil der vorliegenden Beschreibung gemacht wird. Selbstverständlich können auch andere Strategien für die Entwicklung von Steuerungsschleifen oder Steuerungsmodulen eingesetzt werden einschließlich Strategien, die andere Typen von Funktionsblöcken oder andere Routinen, Subroutinen oder Steuerungselemente innerhalb eines Paradigmas zum Konfigurieren von Prozesssteuerungen verwenden.
Bei Verwendung eines auf der Verbindung von Funktionsblöcken wie beispielsweise den vom Feldbus-Funktionsblockparadigma bereitgestellten Funktionsblöcken basierenden Steuerungssystems kann der MPC-Block 56 direkt mit anderen Funktionsblöcken innerhalb der Prozesssteuerungsroutine verbunden werden. So kann der MPC-Block 56 beispielsweise direkt mit anderen Steuerungsgeräten wie beispielsweise Ventilen etc. verbunden werden, indem eine Steuerungsausgabe des MPC-Blocks 56 mit einem dem gesteuerten Gerät zugeordneten Ausgabeblock (wie beispielsweise einem AA-Block) verbunden wird. Ebenso kann der MPC-Block 56 Funktionsblöcken innerhalb anderer Steuerungskreise wie beispielsweise dem Eingang anderer Steuerungsfunktionsblöcke Steuerungssignale bereitstellen, um den Betrieb dieser Steuerungskreise zu steuern oder um deren Steuerung außer Kraft zu setzen.
Wie ersichtlich und ausführlicher in U.S. Patent Nr. 6,445,963 beschrieben, können die Prozesseingaben X₁–X₃, mit denen die Ausgaben des MPC-Steuerungsblocks 56 in 3 verbunden sind, alle gewünschten Prozesseingaben einschließlich Eingaben für Steuerungskreise sein, die innerhalb einer existierenden Steuerungsstrategie definiert sind, oder Eingaben zu Ventilen oder anderen Geräten, die mit dem Prozess verbunden sind. Gleichermaßen können die Prozessausgaben Y₁–Y₃, die mit den Eingaben des MPC-Blocks 56 verbunden sind, alle gewünschten Prozessausgaben einschließlich Ausgaben von Ventilen oder anderen Sensoren, Ausgaben von AA- oder AE-Funktionsblöcken oder Ausgaben anderer Steuerungselemente oder Routinen sein.
Wie in Schritt 54 in 2 dargestellt, wird; sobald der Bediener ein Steuerungsmodul erzeugt hat, das einen initialen MPC-Block beinhaltet, dessen Eingaben und Ausgaben mit den gewünschten Prozessausgaben bzw. -eingaben verbunden sind, das den initialen MPC-Block enthaltende Steuerungsmodul in das betreffende Gerät wie beispielsweise die Steuerung 11 oder eine der Workstations 13 zur Ausführung heruntergeladen. Sodann weist der Bediener in einem Schritt 99 den initialen MPC-Block an, damit zu beginnen, den Prozess auf bekannte Arten anzuregen und Prozesseingabe- und Ausgabedaten zu sammeln, während der Prozess erregt wird.
Wie in 3 dargestellt, weist der initiale MPC-Block 56 eine Datensammlungsroutine 100, einen Wellenformgenerator 101, generische Steuerungslogik 102 und einen Speicher zur Speicherung von Steuerungsparametern 103 sowie ein Prozessmodell oder Modellparameter 104 auf. Die generische Logik 102 kann beispielsweise eine generische MPC-Routine sein, die Koeffizienten oder andere Steuerungsparameter benötigt, um in einem bestimmten Fall eine Steuerung ausführen zu können. In einigen Fällen kann die generische Logik 102 auch ein Prozessmodell oder Modellparameter für den gesteuerten Prozess benötigen, um den betreffenden Prozess zu steuern. Nachdem der initiale MPC-Block 56 beispielsweise in die Steuerung 11 heruntergeladen wurde, wird dieser über die MPC-Erzeugungsroutine 42 angewiesen, die nächste Phase der Entwicklung des MPC-Blocks 56 zu beginnen, während derer für jede der Prozessausgaben Daten zur Verwendung bei der Erzeugung eines Prozessmodells gesammelt werden. Insbesondere beginnt der Wellenformgenerator 101 des MPC-Blocks 56 auf entsprechende Anweisung des Bedieners (oder zu einer beliebigen anderen gewünschten Zeit), eine Reihe von Wellenformen an den Ausgängen AUS₁–AUS₃ des MPC-Blocks 56 erzeugen, um Erregungswellenformen an jedem der Prozesseingänge X₁– X₃ zu erzeugen. Zwar können, falls gewünscht, diese Wellenformen dem Generator 101 von Software innerhalb der Bedienerworkstation 13 bereitgestellt werden, jedoch werden diese vorzugsweise vom Generator 101 erzeugt. Die vom Wellenformgenerator 101 erzeugten Wellenformen sind vorzugsweise so beschaffen, dass sie den Prozess veranlassen, über die unterschiedlichen Eingabebereiche zu arbeiten, die während des normalen Betriebs des Prozesses erwartet werden. Um ein Prozessmodell für eine MPC-Steuerungsroutine zu entwickeln, kann der Wellenformgenerator 101 jeden der Prozesseingänge X₁–X₃ mit einer Reihe unterschiedlicher Sätze von Impulsen beaufschlagen, wobei die Impulse innerhalb jedes der Sätze von Impulsen dieselbe Amplitude, jedoch pseudo-zufällige Längen haben und wobei die Impulse innerhalb der verschiedenen Sätze von Impulsen unterschiedliche Amplituden aufweisen. Eine derartige Serie von Sätzen von Impulsen kann für jeden der verschiedenen Modelleingänge X₁–X₃ erzeugt und sodann sequenziell auf jeweils einen der verschiedenen Prozesseingänge X₁–X₃ gegeben werden. Während dieser Zeit sammelt die Datensammlungseinheit 100 innerhalb des MPC-Blocks 56 die Daten oder koordiniert auf sonstige Weise die Sammlung der Daten, die die Antwort der Prozessausgaben Y₁–Y₃ auf jede der vom Wellenformgenerator 101 erzeugten Wellenformen angeben, und kann die Daten, die sich auf die erzeugte Erregung beziehen, sammeln oder deren Sammlung koordinieren. Diese gesammelten Daten können im MPC-Block 56 gespeichert werden; bevorzugt werden sie jedoch automatisch zum Daten-Historienspeicher 12 zur Speicherung und/oder zur Workstation 13 übertragen, wo diese Daten auf dem Bildschirm 14 angezeigt werden können.
Statt zu versuchen, den Prozess 58 mittels einer erweiterten Steuerungslogik (die noch nicht vollständig entwickelt ist) zu steuern, sendet der MPC-Block 56 zuerst einen Satz von Erregungs-Wellenformen an den Prozess 58 und misst die Antwort des Prozesses auf diese Erregungs-Wellenformen. Selbstverständlich können die vom Generator 101 erzeugten Wellenformen alle gewünschten Wellenformen sein, die entwickelt werden, um ein Prozessmodell zu erzeugen, das für die Erzeugung von Steuerungslogikparametern für jede modellbasierte Steuerungsroutine nützlich ist. In diesem Beispiel erzeugt der Wellenformgenerator 101 jeden Satz von Wellenformen, von dem bekannt ist, dass er bei der Entwicklung eines Prozessmodells für eine modellprädiktive Steuerung nützlich ist, und diese Wellenformen können jede heute bekannte oder zukünftig zu diesem Zweck entwickelte Form annehmen. Da Wellenformen, die zur Erregung eines Prozesses verwendet werden, um Daten zur Entwicklung eines Prozessmodells für eine modellprädiktive Steuerung zu sammeln, bestens bekannt sind, werden diese Wellenformen hier nicht weiter beschrieben. Entsprechend können vom Generator 101 alle anderen oder alle gewünschten Typen von Wellenformen zur Verwendung bei der Entwicklung von Prozessmodellen für andere erweiterte Steuerungsanwendungen (einschließlich Modellierungsanwendungen) wie beispielsweise neuronale Netzwerke, Fuzzy-Logik mit multiplen Variablen etc. erzeugt werden.
Es ist darauf hinzuweisen, dass der Wellenformgenerator 101 jede gewünschte Form annehmen und beispielsweise in Hardware, Software oder einer Kombination von beidem implementiert werden kann. Bei einer Implementierung in Software kann der Generator 101 einen Algorithmus, der zur Erzeugung der gewünschten Wellenformen verwendet werden kann, sowie digitale Repräsentationen der zu erzeugenden Wellenformen speichern oder jede andere Routine oder gespeicherte Daten zur Erzeugung derartiger Wellenformen verwenden. Bei Implementierung in Hardware kann der Wellenformgenerator 101 beispielsweise die Form eines Oszillators oder Rechteckwellen-Generators annehmen. Falls gewünscht, kann der Bediener aufgefordert werden, bestimmte Parameter einzugeben, die für die Gestaltung der Wellenformen benötigt werden oder die hierfür nützlich sind, wie beispielsweise die ungefähre Antwortzeit des Prozesses, die Schrittgröße der Amplitude der an die Prozesseingänge zu übergebenden Wellenformen etc. Der Bediener kann zur Eingabe dieser Informationen aufgefordert werden, wenn der MPC-Block 56 erstmals erzeugt wird oder wenn der Bediener den MPC-Block 56 anweist, den Prozess zu irritieren oder zu erregen und Prozessdaten zu sammeln. In einer bevorzugten Ausführung sammelt die Datensammlungseinheit 100 Daten (oder stellt auf andere Weise die Sammlung von Daten sicher) in Reaktion auf jede der Erregungswellenformen für das Drei- oder Fünffache der vom Bediener eingegebenen Antwortzeit, um zu gewährleisten, dass ein vollständiges und exaktes Prozessmodell entwickelt werden kann. Daten können jedoch für jede andere Zeitspanne gesammelt werden.
Der MPC-Steuerungsblock 56 arbeitet vorzugsweise so lange, bis der Wellenformgenerator 101 die Beaufschlagung jedes der Prozesseingänge X₁–X₃ mit allen erforderlichen Erregungswellenformen abgeschlossen hat und bis die Datensammlungseinheit 100 Daten für die Prozessausgaben Y₁–Y₃ gesammelt hat. Selbstverständlich kann der Betrieb des MPC-Blocks 56 unterbrochen werden, wenn dies während dieses Datensammlungsprozesses gewünscht oder erforderlich ist.
Wie in 4 dargestellt, versetzt eine Bildschirmanzeige 118, die dem Bediener auf einem der Bildschirme 14 von der Steuerungslogik-Erzeugungsroutine 40 präsentiert wird, einen Bediener in die Lage, die verschiedenen Schritte des Erzeugens eines erweiterten Steuerungsblocks auszuführen. Insbesondere weist die Bildschirmanzeige 118 einen Datenanzeigebereich 120 sowie vier Schaltflächen 121, 122, 123 und 124 auf, die verwendet werden können, um verschiedene Teile der Steuerungsblock-Erzeugungsroutine 40 zu initiieren (1). Die Schaltfläche "Initiiere Test" 121 versetzt den Bediener in die Lage, den initialen MPC-Block 56 zu veranlassen, Erregungssignale an den Prozess 58 zu senden und Eingabe- und Ausgabedaten zur Übergabe an den Daten-Historienspeicher 12 zu sammeln. Die Schaltfläche 121 kann beispielsweise die verbleibende Zeit für die Ausführung der Erregungsroutine angeben, d.h. die Zeit, die der MPC-Steuerungsblock 56 benötigt, um sämtliche Erregungs-Wellenformen zu erzeugen und die als Antwort auf diese Wellenformen erzeugten Prozessdaten zu sammeln. Vor Betätigung der Schaltfläche 121 kann der Bediener eine Antwortzeit eingeben, die eine typische Zeit angibt, die der Prozess benötigt, um auf eine Eingabe zu reagieren, und der Bediener kann die Schrittgröße angeben oder spezifizieren, die vom MPC-Block 56 verwendet wird, um die Erregungs-Wellenformen zu erzeugen, wobei diese Daten dem Wellenformgenerator 101 des MPC-Blocks 56 übergeben werden können. Nach Betätigen der Schaltfläche 121 können die vom MPC-Block 56 gesammelten Daten auch im Datenanzeigebereich 120 angezeigt werden und der Anwender kann, wenn gewünscht, Daten (beispielsweise mittels Linien oder Balken) markieren, die nicht zur Erzeugung eines Prozessmodells verwendet werden sollten oder die aus den zur Erzeugung eines Prozessmodells verwendeten Daten ausgeschlossen werden sollten. Es ist darauf hinzuweisen, dass die Datensammlungseinheit 100 Daten sammeln kann, indem sie sicherstellt, dass diese Daten an den Daten-Historienspeicher 12 oder an ein anderes Speichergerät zur Speicherung gesendet werden.
Nach dem Sammeln der Prozessdaten kann der Bediener an einem gewissen Punkt entscheiden, die nächste Phase der Entwicklung des MPC-Blocks durchzuführen, indem eine oder mehrere Prozessmodelle aus den gesammelten Prozessdaten erzeugt werden, die in der MPC-Steuerung oder einem anderen modellbasierten Steuerungsblock zu verwenden sind. Vor dieser Prozedur oder als Bestandteil dieser Prozedur kann der Bediener einen Block 125 in 2 initiieren, der den gesammelten Prozessdaten Rauschen und vorzugsweise gleichmäßig verteiltes zufälliges Rauschen mit dem Erwartungswert Null hinzufügt, um diese Daten auf eine Weise vorzuverarbeiten, die eine robustere Erzeugung eines Prozessmodells aus diesen Daten ermöglicht. Der Bediener kann dieses Rauschen den gesammelten Daten hinzufügen (was im Bereich 120 der Bildschirmanzeige 118 in 4 dargestellt werden kann), indem er die in 4 dargestellte Schaltfläche 122 anwählt. Zu diesem Zeitpunkt kann der Bediener die gewünschte Amplitude des hinzuzufügenden Rauschens wählen. Allgemein gesagt, wurde festgestellt, dass die Verwendung zufälligen, gleichmäßig verteilten Rauschens mit dem Erwartungswert Null mit einer maximalen Amplitude zwischen ca. 0,2 Prozent und 0,5 Prozent des normalisierten Bereichs der Prozessdaten (d.h. des Bereichs der Amplitude der gesammelten Prozessdaten) für eine Routine zur Erzeugung eines robusten Prozessmodells gut funktioniert. Noch bevorzugter wurde festgestellt, dass die Verwendung gleichmäßig verteilten, zufälligen Rauschens mit dem Erwartungswert Null mit einer maximalen Amplitude von ca. 0,4 Prozent des Bereichs der Prozessdaten besonders gut funktioniert. Andere Typen von Rauschen können jedoch ebenso verwendet werden einschließlich nicht-zufällgen Rauschens sowie andere Rauschverteilungen wie beispielsweise eine Normalverteilung (Gaußverteilung) und andere Amplituden einschließlich Amplituden von weniger als 0,2 Prozent oder mehr als 0,5 Prozent des Datenbereichs.
Darüber hinaus könnte, falls gewünscht, die Größe oder Amplitude des Rauschens automatisch auf der Grundlage anderer Faktoren im Prozesstest wie beispielsweise der Größe des zur Irritation des Prozess verwendeten Stufensignals, der Änderung der Prozessdaten als Reaktion auf den Test etc. ausgewählt werden. Allgemein gesagt, kann die Amplitude des Rauschens mithin automatisch als Funktion der gesammelten Prozessdaten oder des Prozesseingabesignals eingestellt werden. Lediglich beispielhaft kann die Amplitude des Rauschens als Funktion eines statistischen Wertes der gesammelten Prozessdaten wie beispielsweise des Bereichs der gesammelten Prozessdaten, des Mittelwertes der gesammelten Prozessdaten oder einer Standardabweichung der gesammelten Prozessdaten oder als Funktion eines Prozesseingabesignals wie beispielsweise eines Faktors der Größe des zur Erzeugung der gesammelten Prozessdaten verwendeten Eingangs-Prozessirritationssignals bestimmt werden. In einem spezifischen Beispiel kann das Rauschen, wenn sich die Prozessdaten im Testzyklus um 2 % ändern, eine Größe von 0,2 % haben, während die Größe des Rauschens 0,5 % betragen kann, wenn die Größe der Testsignaleingabe zum Prozess 5 % beträgt. Selbstverständlich kann ein anderer Multiplikator (d.h. ein anderer Multiplikator als 10 Prozent) verwendet werden, um die Größe des Rauschens zu anderen im Test verwendeten Faktoren in Beziehung zu setzen. Weiterhin ist ersichtlich, dass bei der Bestimmung multipler Prozessmodelle oder bei der Bestimmung eines Prozessmodells aus multiplen Eingaben zum Prozess und/oder multiplen Prozessausgaben die Amplitude oder der Typ des zu den gesammelten Prozessdaten hinzugefügten Rauschens für jeden Satz gesammelter Prozessausgabedaten unterschiedlich sein kann. Die Amplitude des Rauschens kann mithin für jedes unterschiedliche Prozessirritationssignal und/oder für jeden Satz gesammelter Daten, die einer anderen Prozessausgabe zugeordnet sind, unterschiedlich eingestellt sein.
Nachdem den Prozessdaten vom Block 125 in 2 Rauschen hinzugefügt wurde, können diese Daten im Daten-Historienspeicher 12 gespeichert oder direkt an die Modellerzeugungsroutine 44 übergeben werden (1). Insbesondere kann der Anwender an einem Block 126 in 2 die Prozessmodellierungsroutine 44 ausführen, die auf die gesammelten und künstlich rauschbehafteten Daten aus dem Daten-Historienspeicher 12 zugreift, und jede bekannte Routine zur Erzeugung eines Prozessmodells ausführen, um aus den gesammelten und künstlich rauschbehafteten Daten ein Prozessmodell zu zeugen. (In dieser Offenlegungsschrift bezeichnet der Begriff "künstlich rauschbehaftete Daten" Daten, denen bewusst Rauschen in einer gewissen Form hinzugefügt wurde.) Allgemein gesagt, kann der Bediener diese Phase initiieren, indem er die Schaltfläche "Erzeuge Steuerung" 123 in der Bildschirmdarstellung in 4 anwählt.
Falls gewünscht, kann die Prozessmodellierungsroutine 44 eine Datenüberprüfungsprozedur für die gesammelten Daten ausführen. Diese Datenprüfungsprozedur kann die gesammelten Daten auf Ausreißer und andere offensichtlich fehlerhafte Daten prüfen und andere mit den gesammelten Daten in Verbindung stehende Werte wie beispielsweise mit den gesammelten Daten in Verbindung stehende Status- und Grenzwerte prüfen, um festzustellen, ob die Daten von einem Funktionsblock, der sich in einem schlechtem oder fehlerhaftem Zustand befindet, erzeugt wurden, ob die Daten an einer Grenze lagen, ob die Daten zu einer Zeit erzeugt wurden, zu der ein Funktionsblock oder ein anderes Element in einem fehlerhaften Betriebszustand war, oder ob die Daten auf andere Weise unter abnormalen oder unerwünschten Prozessbedingungen erzeugt wurden. So beinhalten beispielsweise im Feldbus-Kommunikationsprotokoll von Funktionsblöcken erzeugte Daten auch eine Status-, eine Grenz- und eine Betriebsartenangabe, die zusammen mit den Daten im Daten-Historienspeicher 12 gespeichert und zur Überprüfung der Daten verwendet werden können. Falls gewünscht, kann die Datenüberprüfungsroutine die gesammelten Daten dem Bediener im Datenanzeigebereich 120 in 4 anzeigen und den Bediener in die Lage versetzen, auf der Grundlage seiner Kenntnis der Prozessbedingungen die zu überprüfenden oder zu eliminierenden Daten zu markieren, indem diese Daten beispielsweise hervorgehoben oder auf sonstige Weise identifiziert werden. Auf diese Weise können Daten, die vom MPC-Block 56 zu einer Zeit gesammelt wurden, als der Prozess 58 offline war, als der Prozess 58 nicht ordnungsgemäß gesteuert wurde, als der Prozess 58 repariert wurde, als ein Sensor oder ein anderes Gerät innerhalb des Prozesses 58 fehlerhaft war oder repariert wurde etc., ausgewählt und aus den zur Erzeugung eines Prozessmodells zu verwendenden Daten eliminiert werden. Selbstverständlich kann dieser Schritt der Datenüberprüfung vor oder nach dem Block 125 in 2 oder als Bestandteil dessen ausgeführt werden und somit in Verbindung mit und/oder als Bestandteil des Prozesses des Hinzufügens zufälligen Rauschens zu den gesammelten Prozessdaten ausgeführt werden.
Wie in 4 dargestellt, kann ein Trend im Anzeigebereich 120 angezeigt werden, der die MPC-Eingaben und -Ausgaben als Trendplot enthält. Der Plot kann auf der Grundlage der Werte der Eingaben und Ausgaben automatisch skaliert werden.
Weiterhin beträgt der Zeitrahmen des Teils des Plots, der angezeigt wird, vorzugsweise das Doppelte der spezifizierten Reaktionszeit. Mittels eines Schiebereglers 127 kann das Zeitfenster verändert werden, um Werte anzuzeigen, die eine gewisse Zeit in die Vergangenheit reichen wie beispielsweise die letzten beiden Tage. Um die Sammlung guter Daten über den Betrieb der Anlage zu ermöglichen, kann ein automatisches Testmerkmal hinzugefügt werden. Durch Anwahl der Schaltfläche "Iniziiere Test" 121 werden die Prozesseingaben, die vom MPC-Block manipuliert werden, in einer pseudozufälligen Sequenz über die spezifizierte Antwortzeit um die spezifizierte Schrittgröße angestoßen. Weiterhin können bei Anwahl der Schaltfläche "Iniziiere Test" 121 in der Datenanzeige automatisch Anfangs- und End-Trennbalken gesetzt werden, um den Anfang und das Ende des automatischen Tests zu markieren, und der MPC-Block 56 kann die Steuerung der manipulierten Ausgaben übernehmen, indem er die pseudozufällige Sequenz von Ausgabesignalen als Erregungs-Wellenformen an den Prozess 58 sendet.
Die Zeitbalken oder das Datenfenster im Bereich 120 können auch verwendet werden, um die Daten auszuwählen, die für die Entwicklung des Prozessmodells zu verwenden sind. Ein Bediener kann einen der Trennbalken anwählen und diesen auf die gewünschte Anfangs- oder Endzeit ziehen, um den Zeitrahmen zu verändern, der für die Identifizierung des Prozessmodells berücksichtigt wird. Wenn ein Teil der Zeit zwischen dem Anfangs- und dem Endbalken nicht für den normalen Betrieb der Anlage repräsentativ ist, kann der Anwender oder Bediener diesen Zeitabschnitt spezifizieren, um Datenwerte auszuwählen, die während des Prozesses der Identifizierung des Prozessmodells zu ignorieren sind. Als Reaktion kann der ausgewählte Bereich mit einer dunkleren Hintergrundfarbe angezeigt oder auf eine andere Weise kenntlich gemacht werden und wird bei der Erzeugung des Prozessmodells automatisch ausgenommen.
Nach Überprüfung der Daten und Hinzufügen zufälligen Rauschens zu den Daten erzeugt die Prozessmodellierungsroutine 44 ein Prozessmodel aus den ausgewählten Daten. Wie bereits angemerkt, kann die Prozessmodellierungsroutine 44 jeden gewünschten oder bekannten Typ einer Prozessmodellierungsanalyse durchführen, um ein Prozessmodell aus den gesammelten und überprüften Daten zu entwickeln, und das entwickelte Prozessmodell kann jede Form wie beispielsweise die eines mathematischen Algorithmus, einer Folge von Antwortkurven etc. annehmen.
Wenn die Prozessmodellierungsroutine 44 ein Problem bei der Bestimmung des Prozessmodells hat, kann in einem Statusbereich einer Bedieneranzeige ein Hinweis auf das Problem beispielsweise in der in 4 dargestellten Art gegeben werden. Ein Problem, das dort angezeigt werden kann, ist, dass nicht genügend Proben bzw. Messwerte vorliegen, um ein Prozessmodell zu identifizieren oder zu erzeugen. Eine Nachricht wie beispielsweise "Für die definierte Konfiguration sind mindestens XXX Proben/Messwerte erforderlich. Die Datei enthält lediglich XXX Proben/Messwerte" kann erzeugt werden, um den Bediener auf dieses Problem hinzuweisen. Ein weiteres Problem, das erkannt werden kann, ist, dass keine ausreichende Erregung der Prozesseingaben erfolgt ist. Wenn ein derartiges Problem auftritt, kann eine dahingehende Nachricht für den Bediener und eine Angabe der Namen der Signalmarker wie beispielsweise "MarkerX", "MarkerY" etc. sowie eine Angabe der mindestens erforderlichen Veränderungen der Erregungshöhe erfolgen.
Falls gewünscht, kann der Anwender auf der Grundlage der Bedingungen, die es verhindert haben, dass ein erfolgreiches Modell identifiziert wurde, den Zeitrahmen ändern, während dessen die Prozessmodellierung durchgeführt wird, oder Prozesseingaben verändern, damit die in der Prozessmodellierungsroutine 44 verwendeten Daten gültig sind. Das identifizierte Prozessmodell kann automatisch in jeder gewünschten Datenbank gesichert werden, die zur späteren Verwendung zugänglich sein soll. Erfahrenere Anwender wollen möglicherweise das identifizierte Prozessmodell prüfen oder editieren. Durch Anwahl der Schaltfläche "Erweitert" 124 in dem Bildschirm in 4 kann dem Anwender die Wahl gegeben werden, eine MFC-Steuerung aus einem ausgewählten Modell und der aktuellen MPC-Funktionsblockkonfiguration zu erzeugen oder ein spezifisches Modell zu editieren und das sich ergebende Modell als neues Modell zu sichern, das zum Erzeugen einer MPC-Steuerungslogik zu verwenden ist. Wenn die Option "Erzeuge Steuerung" gewählt wird, kann dem Anwender ein Dialog angezeigt werden, aus dem er ein Modell auswählen kann, das zuvor für den MPC-Block in dem MPC-Modul gesichert wurde, das gerade editiert wird. Durch Anwahl der Option "Editieren" kann dem Anwender eine Liste der Modelle angezeigt werden, die für das betreffende MPC-Modul entwickelt wurden. Nach Auswahl eines Modells kann dem Anwender eine Bildschirmdarstellung angezeigt werden, die eine Übersicht der Prozesssprungantwort anzeigt, sowie andere Bildschirmdarstellungen entsprechend der folgenden Beschreibung, um Prozesssprungantworten zu editieren, um ein neues oder geändertes Modul zu erzeugen.
An einem Punkt im Prozess kann die Routine 46 zur Erzeugung von Logikparametern ausgeführt werden, um die (in den Variablen innerhalb des MPC-Blocks 56 zu speichernden) Parameter zu erzeugen, die von der generischen Logik 102 des initialen MPC-Blocks 56 benötigt werden, um eine modellprädiktive Steuerung auszuführen. Diese Steuerungsparameter, die beispielsweise Matrix- oder andere MPC-Koeffizienten für eine MPC-Logik, Abstimmparameter, Parameter eines neuronalen Netzwerks (für ein neuronales Netzwerk), Skalierungsfaktoren (für eine Fuzzy-Logik mit multiplen Variablen) oder alle anderen gewünschten Parameter sein können, werden in der Regel auf der Grundlage des erzeugten Prozessmodells bestimmt. Die Routine 46 zur Erzeugung von Logikparametern kann jede gewünschte oder bekannte Prozedur zum Erzeugen der Parameter aus einem Prozessmodell ausführen. Allgemein gesagt, umfasst dieser Prozess die Invertierung des Prozessmodells in ein Matrixformat. Es könnte jedoch jede andere gewünschte Routine zum Erzeugen von Logikparametern verwendet werden. Da die Spezifika des Erzeugens eines Prozessmodells aus Daten für einen Prozess und des Erzeugens von MPC- oder anderen Steuerungslogikparametern aus diesem Prozessmodell in der Technik bekannt sind, werden diese Prozeduren in dieser Offenlegungsschrift nicht weiter beschrieben. Es ist jedoch darauf hinzuweisen, dass der Bediener bei Erzeugung der Steuerungslogikparameter für den MPC-Block 56 eine gewisse Eingabe haben kann. So kann der Bediener beispielsweise aufgefordert werden oder auf sonstige Weise die Möglichkeit erhalten, die Werte bestimmter Variablen zu spezifizieren, die typischerweise verwendet werden, um eine MPC-Steuerung zu erzeugen. So kann der Bediener beispielsweise die Sollwerte und Grenzen einer jeden der eingeschränkten Eingaben zum MPC-Block, den Zeitrahmen, während dessen Steuerungsänderungen vorzunehmen sind, d.h. den Sollwerttrajektorienfilter und die diesem Filter zugeordneten Zeitkonstanten, die maximale oder minimale Bewegung (Geschwindigkeitsgrenze) einer MPC-Ausgabe oder einer Prozessausgabe spezifizieren oder, vorgeben, ob irgendwelche der gesteuerten Parameter auf integrierte Weise reagieren, oder MPC-Optimierungsfaktoren, Variablen- oder Abstimmparameter, den Horizont des MPC-Steuerungsblocks, d.h. um wie viele Vorwärtsschritte Berechnungen durchzuführen sind, um auf einen gewünschten Zustand zu regeln, die Bereiche der technischen Einheiten für jede der Eingaben und Ausgaben des MPC-Blocks 56 spezifizieren oder weiterhin bestimmen, welche der Zielgrößen von Stellgrößen überschritten werden dürfen oder nicht, wenn eine der Einschränkungen verletzt wird, sowie auch eine Beschreibung und/oder Bezeichnung für jede der MPC-Block-Eingaben und -Ausgaben, den Wert aller Optimierungsvariablen, die gesetzt werden können, sowie den Wert von Variablen in Bezug auf die Aggressivität oder Robustheit des MPC-Blocks etc. festlegen. Falls gewünscht, kann die Steuerungslogik-Erzeugungsroutine 46 Defaultwerte für einige oder sämtliche dieser Variablen oder Einstellungen speichern und diese Defaultwerte zur Erzeugung der MPC-Logik verwenden. Der Bediener oder andere Anwender kann jedoch in der Lage sein, diese Einstellungen über die Bedieneranzeige 14 zu ändern.
Auf jeden Fall wird die Routine 46 zur Erzeugung von MPC-Logikparametern unter Verwendung dieser Informationen und aller anderen Informationen, die zur Erzeugung von MPC- (oder anderen) Steuerungslogikparametern wie beispielsweise MPC-Koeffizienten erforderlich sein können, ausgeführt. Die Schaltfläche "Erzeuge Steuerung" 123 auf der Bildschirmanzeige 118 kann anzeigen, ob die Erzeugung eines Prozessmodells und von Steuerungslogikparametern erfolgreich war oder nicht.
Nachdem die MPC-Steuerungslogikparameter erzeugt wurden, können in einem Schritt 128 in 2 die MPC-Steuerungslogikparameter oder -Koeffizienten mittels eines Prozesssimulationsblocks getestet werden. Dieser Simulationsblock kann allgemein aus dem für den Prozess erzeugten Prozessmodell entwickelt und in einer Testumgebung der in U.S. Patent Nr. 6,445,963 beschriebenen Art mit einem MPC-Block verbunden werden, um zu testen, ob die erzeugte MPC-Steuerungslogik im normalen Betriebsbereich des Prozesses zufriedenstellend arbeitet. Wenn die MPC-Logik nicht zufriedenstellend ist, können beliebige oder sämtliche der Schritte 54, 99, 125, 126 und 128 wiederholt werden, um eine andere MPC-Steuerungslogik zu entwickeln. Wenn die MPC-Steuerungslogik jedoch zufriedenstellend ist, können die MPC-Steuerungslogikparameter und das Prozessmodell in einem Schritt 130 in den MPC-Block 56 heruntergeladen werden, um im Prozessparameterspeicher 103 und im Prozessmodellspeicher 104 zur Verwendung zur Steuerung des Prozesses 58 gespeichert zu werden. Auf diese Weise werden die von der MPC-Steuerungslogik benötigten Parameter dem MPC-Block 56 zur Verfügung gestellt und in diesem gespeichert und der MPC-Block 56 kann in Betrieb genommen werden, um tätig zu werden oder tatsächlich die Steuerung innerhalb des Prozesses entsprechend der MPC-Steuerungslogik 102 auszuführen. Selbstverständlich kann die tatsächliche MPC-Logik 102 zusammen mit den dafür benötigten Parametern in der Workstation 13 erzeugt und in den MPC-Block 16 heruntergeladen werden. Darüber hinaus kann, falls gewünscht, der erzeugte MPC-Steuerungsblock oder das Modell an einem Block oder Schritt 135 (2) einer Workstation oder einem anderen Computergerät zur Verfügung gestellt werden, um als Teil einer Simulationsumgebung verwendet zu werden.
Sobald das MPC-Modul oder die Schleife mit dem darin enthaltenen MPC-Block 56 heruntergeladen und von der Steuerung 11 ausgeführt wurde, kann das MPC-Modul oder die Schleife mit dem darin enthaltenen MPC-Block 56 auf dieselbe Weise wie andere Blöcke oder Elemente innerhalb der Steuerungsroutine Berichtsfunktionen ausführen, da, wie oben erwähnt, der MPC-Block 56 und das diesen Block enthaltende Steuerungsmodul mittels desselben Programmierungsparadigmas wie die anderen Steuerungsblöcke innerhalb des Prozesssteuerungssystems 10 entwickelt wurden. In einer Ausführung können dem MPC-Block oder Modul grafische Aussichten zugeordnet sein, die einem Anwender oder Bediener beispielsweise über einen der Bildschirme 14 einer oder mehrerer der Workstations 13 angezeigt werden können, wobei diese Sichten Daten anzeigen, die den Blöcken innerhalb des MPC-Steuerungsmoduls zugeordnet sind, und diese Daten auf eine zuvor definierte oder spezifizierte Weise anzeigen.
Während das Verfahren des Erzeugens eines Prozessmodells aus gesammelten Daten, das den gesammelten Prozessdaten Rauschen hinzufügt, in dieser Offenlegungsschrift so beschrieben ist, dass es in Verbindung mit der Erzeugung eines MPC-Steuerungsblocks implementiert wird, der während der Konfigurierung der Prozessanlage in eine Steuerung einer Prozessanlage heruntergeladen wird, ist darauf hinzuweisen, dass das Konzept des Hinzufügens von Rauschen zu gesammelten Prozessdaten vor dem Erzeugen eines Prozessmodells aus diesen Daten in jedem anderen Zusammenhang oder in jeder anderen Umgebung für jeden gewünschten Typ von Prozessmodell implementiert werden kann. Dieses Merkmal kann mithin beim Erzeugen von Prozessmodellen für MPC-Steuerungsanwendungen, bei der Modellierung von neuronalen Netzwerken und/oder von Steuerungsanwendungen oder in jeder anderen Situation verwendet werden, in der für einen Prozess ein Prozessmodell aus gesammelten Prozessdaten erzeugt werden muss. Darüber hinaus kann das Merkmal des Hinzufügens von Rauschen zu den gesammelten Prozessdaten vor dem Erzeugen eines Prozessmodells aus diesen Daten in einer Steuerung mit einer einzelnen Eingabe und einer einzelnen Ausgabe oder in einer Steuerung mit einer einzelnen Eingabe und multiplen Ausgaben oder in einer Steuerung mit multiplen Eingaben und multiplen Ausgaben oder in einer Steuerung mit multiplen Eingaben und einer einzelnen Ausgabe oder in Modellierungssituationen oder anderen Nicht-Steuerungsanwendungen wie beispielsweise in Modellierungs- und Vorhersageanwendungen verwendet werden. Gleichermaßen können die Prozessdaten, denen Rauschen hinzugefügt wird, auf jede Weise einschließlich jeder anderen Weise als der in dieser Offenlegungsschrift beschriebenen Weise vom Prozess gesammelt werden. Gleichermaßen können, während das tatsächliche Modell, das aus den gesammelten, mit Rauschen vorverarbeiteten Prozessdaten entwickelt wurde, ein finites Impulsantwortmodell (finite impulse response) (FIR) oder ein parametrisches Modell wie beispielsweise ein autoregressive Modell mit externen Eingaben (ARX) (entsprechend der detaillierteren Beschreibung in dieser Offenlegungsschrift) sein kann, anstatt dieser Typen von Modellen oder zusätzlich zu diesen alle anderen Typen von Prozessmodellen aus diesen Daten erzeugt werden.
Wie in 5 dargestellt, wird somit ein generalisiertes robustes Verfahren 150 zum Erzeugen eines Prozessmodells aus Prozessdaten oder Testdaten dargestellt. Das Verfahren 150 beinhaltet allgemein die Erfassung eines Satzes von Prozesstestdaten an einem Block 152 und die Durchführung einer Datennormalisierung für die Prozesstestdaten an einem Block 154. Selbstverständlich können die Prozesstestdaten auf jede Weise mittels aller gewünschten Prozessirrotationstechniken oder Wellenformen erfasst werden. Darüber hinaus können alle bekannten Datennormalisierungstechniken für die Testdaten ausgeführt werden. An einem Block 156 können die normalisierten Prozesstestdaten vorverarbeitet oder überprüft werden, um beispielsweise Ausreißer zu eliminieren, Abschnitte der Daten zu löschen oder auszuschließen, die zu Zeiten eines abnormalen Prozessbetriebs oder in Anwesenheit einer anderen Störung im Prozess, die keinem Standardbetrieb des Prozesses entspricht, etc. erfasst wurden. Sodann wird in einem Block 158 Rauschen wie beispielsweise zufälliges Rauschen mit dem Erwartungswert Null den vorverarbeiteten, normalisierten Daten hinzugefügt. Wie weiter oben ausgeführt, kann zufälliges Rauschen mit dem Erwartungswert Null in einer Größenordnung von 0,2 bis 0,5 Prozent des normalisierten Bereichs den normalisierten und vorverarbeiteten Testdaten hinzugefügt werden, obwohl statt dessen auch andere Größen von Rauschen verwendet werden können. Ein Block 160 verwendet sodann die vom Block 158 produzierten, rauschbehafteten Prozesstestdaten, um mittels jeder bekannten oder gewünschten Modellerzeugungstechnik eines oder mehrere Prozessmodelle aus den Daten zu erzeugen.
Während 5 zeigt, dass das Rauschen den normalisierten Prozesstestdaten hinzugefügt werden kann, nachdem diese Daten vorverarbeitet oder überprüft wurden, ist es nicht in allen Fällen erforderlich, die Prozesstestdaten zu normalisieren oder diese Prozesstestdaten vorzuverarbeiten oder zu überprüfen, um beispielsweise Ausreißer oder andere unbrauchbare Daten zu entfernen, die von einem Anwender oder mittels eines statistischen Verfahrens definiert wurden. Während 5 weiterhin zeigt, dass das Rauschen den Prozesstestdaten hinzugefügt wurde, nachdem diese Daten erzeugt wurden, wurde festgestellt, dass das Rauschen den zum Erzeugen der Prozesstestdaten verwendeten Signalwellenformen hinzugefügt werden kann, um auf diese Weise den gesammelten Prozesstestdaten Rauschen hinzuzufügen. In diesem Fall wird davon ausgegangen, dass nicht rauschbehaftete Prozessirritationssignal- oder Signalwellenformen zur Erzeugung der gesammelten (und mithin rauschbehafteten) Prozesstestdaten verwendet wurden, als diese Daten zum Zwecke der Erzeugung eines Prozessmodells ausgewertet wurden.
Weiterhin wurde festgestellt, dass die Technik des Hinzufügens von Rauschen zu Prozessdaten in der Tat gut funktioniert, um zunächst auf robuste Weise Prozessmodelle bei Vorliegen rauschbehafteter Prozesstestdaten zu finden, da das Hinzufügen von zufälligem Rauschen mit dem Erwartungswert Null zu rauschbehafteten Daten das Rauschniveau in den Daten tatsächlich nicht über die Höhe des hinzugefügten Rauschens hinaus erhöht. Insbesondere erhöht das hinzugefügte Rauschen, da das hinzugefügte Rauschen nicht mit dem bereits in den gesammelten Testdaten enthaltenen Rauschen korreliert ist, das Niveau des Rauschens der Daten nicht über das Niveau des hinzugefügten Rauschens hinaus. Bei Hinzufügen über rauschbehaftete und nicht rauschbehaftete Daten beispielsweise bei der Entwicklung multipler Prozessmodelle für denselben Prozess kompensiert das Hinzufügen von Rauschen sogar die Höhe des Rauschens innerhalb der von verschiedenen Quellen innerhalb des Prozesses gesammelten Daten und ergibt auf diese Weise einen besseren oder stärker korrelierten Satz von Prozessmodellen für den Prozess.
Weiterhin wurde festgestellt, dass die Technik des Hinzufügens von Rauschen zu den Prozesstestdaten allgemein besser funktioniert, wenn ein parametrisches Modell wie beispielsweise ein ARX-Modell und nicht ein nichtparametrisches Modell wie beispielsweise ein FIR-Modell bestimmt wird. Allgemein gesagt, verwenden parametrische Modelle bei der Suche nach einer besten Beschreibung einen endlich dimensionalen Parametervektor, während die beste Beschreibung in einem nichtparametrischen Modell einen unendlich dimensionalen Parametervektor erfordert. Der zentrale Unterschied zwischen dem parametrischen und dem nichtparametrischen Modelltyp ist, dass ein parametrisches Modell weitaus kompakter ist und weniger Parameter benötigt als ein nichtparametrisches Modell, um dasselbe dynamische Verhalten zu beschreiben. In der Literatur wird FIR als nichtparametrisches Modell bezeichnet, während Formen wie beispielsweise ARX, ARMAX, Box-Jenkins und Output Error [Ausgabefehler] (OE) etc. als parametrische Modelle bezeichnet werden. Der Begriff "nichtparametrisch" soll nicht besagen, dass derartige Modelle überhaupt keine Parameter aufweisen; Anzahl und Natur der Parameter sind vielmehr flexibel und bestimmen den Grad der Verzweigung. So bestimmt beispielsweise in einem FIR-Modell die Anzahl der zur Definition des Modells verwendeten Scans den dynamischen Bereich des Modells. Nichtparametrische Modelle werden gelegentlich auch als verteilungsfrei bezeichnet.
Wie bekannt ist, sind parametrische Modelle niedriger Ordnung allgemein nicht in der Lage, eine gute oder gültige Schätzung der Totzeit eines Prozesses zur Verwendung im Prozessmodell zu erzeugen, während FIR-Modelle allgemein gute Schätzungen für die Prozesstotzeit erzeugen. Als Ergebnis ist ein sehr nützliches Verfahren zur Bestimmung eines parametrischen Modells wie beispielsweise eines ARX-Modells durch das Flussdiagramm 170 in 6 dargestellt. Insbesondere werden an einem Block 172 zuerst Prozesstestdaten für den Prozess bestimmt. An einem Block 174 können dieses Prozesstestdaten normalisiert und überprüft werden, um Ausreißer, schlechte Daten etc. zu entfernen. Sodann wird an den Blöcken 175 und 176 eine Schätzung der Totzeit des Prozesses aus den Prozesstestdaten bestimmt. In einem Beispiel erzeugt der Block 175 zuerst ein nichtparametrisches Modell wie beispielsweise ein FIR-Modell des Prozesses aus den Prozesstestdaten und der Block 176 bestimmt sodann die Prozesstotzeit aus diesem nichtparametrischen Prozessmodell. Allgemein gesagt, kann die Schätzung der Prozesstotzeit als die Zeit ermittelt werden, die vergeht, bis die Ausgabe einer modellierten FIR-Prozessantwort die auf Null normalisierte Schwelle überschreitet. Während jedoch die Bestimmung einer Schätzung der Prozesstotzeit durch Erzeugen eines FIR- oder eines anderen nichtparametrischen Modells aus den gesammelter Prozessdaten durchgeführt werden kann, können die Blöcke 175 und 176 durch jedes andere bekannte oder gewünschte Verfahren zur Bestimmung der Prozesstotzeit einschließlich solcher Verfahren, die kein Prozessmodell erzeugen, ersetzt werden.
Im Anschluss daran kann an einem Block 178 zufälliges Rauschen mit dem Erwartungswert Null mit einer gewünschten Amplitude den Prozesstestdaten hinzugefügt werden. An einem Block 180 kann das Prozesstesteingabesignal zeitlich verschoben werden, um der ermittelten Prozesstotzeit Rechnung zu tragen, um auf diese Weise die Prozesstotzeit aus den gesammelten und künstlich rauschbehafteten Prozessdaten zu entfernen. Selbstverständlich ist die Reihenfolge der Operationen der Blöcke 178 und 180 nicht wichtig und die Operationen können in umgekehrter Reihenfolge oder gleichzeitig ausgeführt werden. An einem Block 182 kann eine Routine zur Erzeugung eines parametrischen Modells verwendet werden, um ein parametrisches Prozessmodell aus den künstlich rauschbehafteten und verschobenen Prozessdaten zu erzeugen, indem auf jede bekannte Weise Werte für die Parameter des parametrischen Prozessmodells bestimmt werden. Selbstverständlich kann das Verschieben der Prozesseingabedaten auf der Grundlage der ermittelten Prozesstotzeit während des Prozesses der Bestimmung des parametrierten Prozessmodells erfolgen und mithin einen integralen Bestandteil der bei der Bestimmung des Prozessmodells durchgeführten Berechnungen bilden.
Allgemein vergrößert der Prozess des Hinzufügens von Rauschen zu den gesammelten Prozessdaten die Standardabweichung der Prozessdaten, was die Routine zur Erzeugung des parametrischen Modells im Wesentlichen in die Lage versetzt, einen Satz von Modellparametern unter Verwendung der rauschbehafteten Daten in den Fällen zu entwickeln, in denen die Routine nicht in der Lage ist, dies auf der Grundlage der (nicht rauschbehafteten) Rohdaten durchzuführen. Weiterhin glaubt man, dass das Hinzufügen von Rauschen zu den Prozessdaten die Daten auf eine Weise aufbereitet, die eine Routine zur Erzeugung eines parametrischen Modells in die Lage versetzt, einen Satz von Modellparametern zu entwickeln, der im Wesentlichen den Prozess ebenso gut oder mit so großer Genauigkeit wie Modellparameter, die aus den Rohdaten ermittelt worden wären, schätzt, aber auch hierzu oftmals in der Lage ist, wenn die Software zur Erzeugung eines parametrischen Modells nicht in der Lage gewesen wäre, unter Verwendung der Rohdaten tatsächlich einen Satz von Modellparametern zu entwickeln.
Es existieren mehrere grundlegende Techniken der Prozessmodellvalidierung, mit denen es möglich ist, die Robustheit des zur Erzeugung von Prozessmodellen verwendeten Prozesses und insbesondere die Verbesserung der Konvergenz der Modellparameter zu messen. Wie weiter oben beschrieben, wurde festgestellt, dass die Konfidenzintervalle in enger Beziehung zum Rauschen stehen und dass die Konfidenzintervalle (die in enger Beziehung zur Standardabweichung der Daten stehen) mithin erweitert werden können, indem den Testdaten ein geringes Rauschen überlagert wird. Wie oben festgestellt, ermöglicht diese Technik die Erzeugung eines parametrischen Modells aus Daten, die zuvor keine Konvergenz der Modellparameter ergeben haben. Als Ergebnis wird die Robustheit der Modellentwicklungstechnik signifikant erhöht.
Die Entwicklung eines zufriedenstellenden Prozessmodells ist das Kernelement der Technologie der modellprädiktiven Steuerung (MPC). Während in der MPC verschiedene Typen von Modellen verwendet werden, sind das FIR- und das ARX-Modell vermutlich die in der industriellen Praxis am häufigsten verwendeten Modelle. Eine kurze Darstellung von Modelltypen und deren Eigenschaften findet sich in Zhu, Arrieta, R. Butoyi und Cortes, F. "Parametric Versus Nonparametric Models in MPC Process Identification," [Parametrische Modelle gegenüber nichtparametrischen Modellen in der MPC-Prozessidentifizierung] Hydrocarbon Processing, Februar 2000. Wie oben dargestellt, ist eines der Hauptkriterien für die Modellbeurteilung die Verwendung von Konfidenzintervallen bei in der Frequenz- oder Zeitdomäne ausgeführten Rechnungen und für dieses Maß sind niedrige Konfidenzniveaus wünschenswert. Ein weiteres Merkmal zur Modellidentifizierung, die Robustheit, ist jedoch nicht so klar definiert. Allgemein gesagt, führt das Modellidentifizierungsproblem jedoch zu einem Optimierungsproblem, das durch Kleinste-Quadrate-Techniken oder Größte-Wahrscheinlichkeit-Techniken oder Abwandlungen dieser Techniken gelöst wird. Während zahlreiche bekannte Verfahren zuverlässige nominale Modelle und entsprechende akzeptable Unsicherheiten liefern, ist aufgrund der unterschiedlichen Ansätze ein aussagekräftiger Vergleich der jeweiligen Robustheit der Modellidentifzierungsprozeduren schwierig. Zusammenfassend tolerieren robuste Identifizierungstechniken jedoch strukturelle Modellfehler und liefern sowohl ein Modell als auch eine Schätzung der Unsicherheit, wie sie von der Entwicklung einer robusten Steuerung verlangt werden.
Während zahlreiche theoretische Modellierungstechniken existieren, sind Modellidentifizierungstechniken, die in technischer Software verwendet und eingesetzt werden, um eine Identifizierung in komplexen industriellen Prozessen durchzuführen, allgemein für leichten Gebrauch entwickelt und bieten mithin weniger Optionen für die Auswahl der Modellierungstechniken oder die Ordnung der Modellierungsgleichungen als typische Forschungs-/wissenschaftliche Software. In Fällen, in denen die Prozessdynamik signifikant komplexer als das angenommene Modell ist, sollte das angenommene, zu identifizierende Modell daher größere Unsicherheitsintervalle für die Modellparameter aufweisen. Wie oben festgestellt, wird die durch Konfidenzintervalle definierte Modellunsicherheit durch das Niveau des zufälligen Rauschens in den Daten ermittelt oder steht zu diesem in Beziehung. Wenn das Rauschniveau nicht ausreicht, um Unsicherheitsbereiche zu erzeugen, die groß genug sind, um akzeptable Parameterwerte zu beinhalten (dieser Zustand existiert oftmals, wenn ein Prozess mit signifikanter Nichtlinearität identifiziert wird, im Falle einer kaskadierten MPC oder bei simulierten Prozessen und in Fällen, in denen das Niveau des zufälligen Rauschens sehr gering ist oder überhaupt nicht vorhanden ist), kann es daher in vielen Fällen vorkommen, dass sich die Identifizierungsprozedur nicht den akzeptablen Modellparametern annähert.
Aus diesem Grund beinhaltet der Begriff "robuste Identifizierung" in seiner Verwendung in dieser Offenlegungsschrift die Prozedur der Bereitstellung eines zuverlässigen Verfahrens, um ein Prozessmodell für die angenommene Modellkomplexität aus schlechten und unzuverlässigen Daten in Bezug auf die Konvergenz der Modellparameter zu erhalten. Die Analyse der Konfidenzintervalle wird mit der Absicht verwendet und, wie in dieser Offenlegungsschrift dargestellt, belegen die Testergebnisse, dass das Hinzufügen von zufälligem Rauschen die Robustheit der Identifizierung durch Vergrößerung der Konfidenzintervalle der identifizierten Modelle verbessert.
Zur besseren Verständlichkeit wird jedoch das Konzept der Konfidenzniveaus nachfolgend detaillierter beschrieben. Insbesondere ist die Modellierung von Sprungantworten, deren Effizienz in DMC-Anwendungen nachgewiesen ist, die üblichste Form der Modellrepräsentation für MPC, da die Modellierung von Sprungantworten die Vorhersage von Prozessausgaben explizit verfügbar macht. Die Vorhersage der Zukunft wird benutzt, um den vorhergesagten Fehlervektor als Eingabe für die MPC-Steuerung zu berechnen.
Die tatsächlichen Formen des Sprungantwortmodells sind bekannt. Bei Betrachtung eines Prozesses mit einer einzelnen Eingabe und einer einzelnen Ausgabe ist das Differential-FIR-Modell:
mit p als Vorhersagehorizont und h_i als den identifizierten Modellkoeffizienten. Typischerweise sind 30 bis 120 Koeffizienten für eine Impulsantwort erforderlich, um die Dynamik eines einfachen Prozesses erster Ordnung plus Totzeit zu beschreiben. Die Identifizierung der Sprungantwort mit dem vollen Vorhersagehorizont und einer großen Zahl von Koeffizienten wie beispielsweise 120 führt jedoch (insbesondere im Falle multiplex Eingaben und multiplex Ausgaben) zu einer Überfrachtung und verursacht eine signifikante Parameterunsicherheit, die bei FIR-Kennzeichnern ein übliches Problem darstellt. Ein ARX-Modell weist signifikant weniger Koeffizienten als das FIR-Modell auf und kann ausgedrückt werden als:
wobei A und V die autoregressiven beweglichen durchschnittlichen Ordnungen des ARX-Modells sind, d die Totzeit bezeichnet und a_i, b_i die Modellkoeffizienten sind. Es wurde beobachtet, dass eine Ordnung von vier den meisten praktischen Anwendungen genügt. Wie in Bezug auf 6 oben dargestellt, kann die Totzeit durch Verwendung eines kurzen FIR-Horizonts identifiziert und sodann bei der Bestimmung des ARX-Modells verwendet werden. Für Prozesse mit multiplen Eingaben und multiplen Ausgaben erfolgt eine Überlagerung jeder Eingabe (additive Aktion) auf jeder Ausgabe. Abschließend wird ein Einheitsschritt auf einer der Eingaben ausgeführt und das identifizierte ARX-Modell wird verwendet, um Sprungantworten für diese Eingabe zu erhalten.
Verallgemeinernd kann die Identifizierung des Prozessmodells als Auftragen des Messdatensatzes Z 0 / N auf einen Modellparameterschätzungssatz θ ^0N = (θ ^(1), ...,θ ^(k), ...θ ^(m)), der im Parametersatz D_N[4] enthalten ist, dargestellt werden: Z0N → θ ^0N ∊ DN (3)
In den obigen Darstellungen des FIR- und ARX-Modells ist θ ^(i) gleich (h_i,) bzw. (a_i, b_i). Ein sehr wichtiges Merkmal jeder Identifizierungstechnik ist die Konvergenz von θ ^0N , wenn die Anzahl der Proben N gegen unendlich geht. Fehler des Datensatzes Z 0 / N haben zufällige Komponenten. Als Ergebnis ist der Satz θ ^0N nicht die einzige Realisierung des wahren Modellparametersatzes θ⁰. Tatsächlich existieren unendlich viele mögliche Realisierungen θ ^0N , θ ^1N , θ ^∞N des wahren Parametersatzes θ⁰, die aus hypothetischen Parametersätzen Z 0 / N, Z 1 / N, ..., Z ∞ / N entwickelt wurden. Daher tritt die Parameterschätzung θ ^1N mit einer gewissen Wahrscheinlichkeit auf. Aus praktischer Sicht ist es interessanter, die Wahrscheinlichkeitsverteilung der Differenzθ ^iN –θ0 zu kennen, als zu wissen, dass die Verteilung quantitative Unsicherheiten der Schätzung θ ^iN erzeugt.
Die Aufgabe besteht daher darin, θ ^iN –θ0 zu schätzen, ohne θ⁰ zu kennen.
Es ist nachgewiesen, dass bei großem N jeder Parameter aus der Schätzung θ ^iN –θ0 sich asymptotisch (mit einem Konfidenzniveau a) der Normalverteilung annähert, wobei die Dichtefunktion lautet:
Wie aus Gleichung (4) ersichtlich, ist P (kk) / θ die Varianz der Parameterschätzung θ ^(k) – θ(k)·P(kk)θ ist das k,k-Element der Kovarianzmatrix P_θ. Die Gleichung für die Schätzung der Kovarianzmatrix lautet: Pθ =(Z0TN Z0N )–1Z0TN eeTZ0N ((Z0TN Z0N )–1)T (5)
Hier ist Z 0 / N der Datensatz, der auf dieselbe Weise angeordnet ist wie für die Identifizierung (FIR oder ARX in diesen Beispielen); Z 0T / N ist die Transponierte von Z 0 / N und e ist der Satz von Fehlern zwischen Prozessausgaben und Modellausgaben.
Die Anwendung der Gleichung (5) erfordert jedoch zuerst eine Berechnung des Prozessmodells, um den Fehlersatz zu entwickeln. Alternativ kann die Kovarianzmatrix P_θ direkt aus der Einheitswertzerlegung (SVD) der Datenmatrix definiert werden: Z0N = USVT (6)
Die Matrizen U, S, V sind Produkte der SVD. Sodann
Hierbei sind V_ji Elemente der V-Matrix und w_i Elemente der diagonalen Matrix S; M ist die Dimension der Matrix S.
Die Standardabweichung der Modellparameter ist definiert als:
Dieses Maß präsentiert die Information zur Modellqualität in besser verwendbarer Form als die oben dargestellte Fehlerwahrscheinlichkeitsverteilung. Standardabweichungen der Modellparameter bestimmen den Bereich des Parameterwerts mit einer zuvor definierten Wahrscheinlichkeit. So bedeutet beispielsweise eine Konfidenzregion von 95 %, dass der tatsächliche Parameterwert mit einer Wahrscheinlichkeit von 95 % in der Region liegt. Unter der Annahme einer Normalverteilung von Fehlern definiert der Bereich von 2σ(a_j) um den identifizierten Parameterwert herum das 95-%-Konfidenzintervall, der Bereich von 3σ ergibt das 99-%-Konfidenzintervall und so weiter.
Aus diesen Parameterstandardabweichungen σ(a_j) können Sprungantworten auf ähnliche Weise wie aus Modellparametern erzeugt werden. Die Konfidenzregionen werden über den Vorhersagehorizont erhalten und liefern mithin den Bereich der Antwortparameter wie beispielsweise Verstärkung und Totzeit. Die Grenzen des 95-%-Konfidenzintervalls werden durch die doppelte Standardabweichung definiert und der Vergleich kann erfolgen, indem die Sprungantwort errechnet und der ursprünglichen Sprungantwort sowohl in der positiven als auch in der negativen Richtung überlagert wird. Für 99-%-Konfidenzintervalle wird die dreifache Standardabweichung verwendet, um das obere und das untere Konfidenzintervall zu definieren.
Ein Beispiel für Konfidenzintervalle für eine in Matlab aus simulierten Daten durch Anwendung der SVD entwickelte Sprungantwort ist in 7 dargestellt. Die 95-%- und 99-%-Konfidenzregionen (Kurve 200 bzw. 202) über die identifizierte Sprungantwort 204 sind dargestellt. Natürlich wird die Region für eine größere Wahrscheinlichkeit größer und umgekehrt. Für MPC-Modelle wird ein Konfidenzintervall von fünfundneunzig Prozent für zufriedenstellend erachtet. Eine nützliche Interpretation dieser Information besteht darin, Bereiche der Sprungantwortparameter aufzustellen. So hat beispielsweise für die Antwort in 7 die Verstärkung einen Bereich zwischen 1,4 und 2,05 bei einer Konfidenz von 95 % und zwischen 1,25 und 2,2 bei einer Konfidenz von 99 %. Diese Informationen werden für die Schätzung der Parameter für die Erzeugung einer robusten Steuerung verwendet. Wenn Konfidenzintervalle für jede Sprungantwort im Prozessmodell zur Verfügung stehen, ist es möglich, nicht nur Fehler der Modellausgabe zu erkennen, sondern auch spezifische Sprungantworten zu identifizieren, die am meisten zu Vorhersagefehlern beitragen können.
Nach der Beschreibung des Vorgehens zur Definition der Konfidenzintervalle zeigt 8 nunmehr eine Anzahl von erzeugten, durch Konfidenzintervalle definierten Modellvalidierungsspezifika. Wie sich aus der vorangehenden Diskussion und insbesondere aus den Gleichungen (6) bis (9) ergibt, sind die Konfidenzintervalle vom Rauschniveau der für die Entwicklung des Modells verwendeten Daten abhängig. Um jedoch Modellparameter innerhalb von Konfidenzintervallen zu erhalten, ist es erforderlich, eine adäquate Modellgleichungsordnung zu wählen. Während dieser Schritt leicht zu identifizieren ist, ist es eine Aufgabe, die insbesondere in Prozesssteuerungssituationen mit komplexer Prozessdynamik nicht immer realisierbar oder nicht immer leicht realisierbar ist. Grundsätzlich erfordert die Auswahl des Typs und der Ordnung der Modellgleichung ein erhebliches Maß an Sachkunde des Themas, die typischerweise weit über die eines normalen Industrieanwenders hinausgeht. Während die Auswahl einer höheren als der benötigten Modellordnung ein nützliches Modell liefern kann, verlängert dies automatisch und unnötig die Programmlaufzeit, die im Bereich von Minuten oder sogar Stunden liegen kann. Andererseits verlangen Mehr-Ebenen-Steuerungssysteme in der Regel Gleichungen einer höheren Ordnung, als ein typischer Anwender vermuten kann. Für die Prozesse mit signifikanter Nichtlinearität kann die Auswahl einer höheren Modellordnung jedoch negative Auswirkungen auf die Prozessidentifizierung haben, da es kein exaktes lineares Modell für einen nichtlinearen Prozess gibt. Die Annahme eines Modells einer hohen Ordnung mit den von den Daten definierten schmalen Konfidenzintervallen führt möglicherweise nicht zur Erzeugung irgendeines Modells überhaupt, da die Modellparameter nicht in den schmalen Bereich konvergieren. Dieser Prozesstyp mit Nichtlinearität kann realistischer durch Verwendung eines Modells niedrigerer Ordnung mit breiteren Konfidenzintervallen modelliert werden. Diese Auswahl steht in voller Übereinstimmung mit der Anwendung gesunden Menschenverstands in der technischen Logik, d.h. wenn ein Prozess nichtlinear ist, ist es besser anzunehmen, dass sich die Prozessverstärkung innerhalb eines breiteren Bereichs verändert, als eine Dynamik höherer Ordnung zu wählen. Die Schlussfolgerung ist, dass es für praktische Anwendungen und insbesondere bei Prozessen mit Nichtlinearität von Nutzen ist, angemessene Konfidenzintervalle statt Modelle höherer Ordnung zu verwenden. In vielen Fällen tritt diese Situation automatisch ein, da das Datenrauschniveau adäquat ist. Wie oben jedoch ausgeführt, kann, um unter vielen oder den meisten Umständen eine Modellkonvergenz zu garantieren, nach dem Sammeln und Vorverarbeiten der Testdaten den Prozessausgabedaten zufälliges Rauschen hinzugefügt werden, d.h. eine Normalisierung und Entfernen von Mittelwerten zur Vergrößerung der Konfidenzintervalle.
Der Effekt des Hinzufügens zufälligen Rauschens zu den Prozessdaten wird sehr deutlich in einem Simulationstest demonstriert, bei dem es ein Hinzufügen von Rauschen mit einer Amplitude von 0,25 Prozent zu den Daten ermöglicht, ein gutes Modell zu entwickeln, während es mit rauschlosen Daten nicht möglich war, überhaupt ein Modell zu entwickeln. So zeigt 8 beispielsweise eine fast perfekte Übereinstimmung zwischen einem FIR-Modell 210 und einem ARX-Modell 212, nachdem Rauschen mit dem Erwartungswert Null und einer maximalen Amplitude von 0,25 Prozent den Prozessdaten hinzugefügt wurde, zusammen mit den 95-Prozent- Konfidenzintervallen 214. 9 zeigt die Ergebnisse, die erhalten werden, wenn man Rauschen mit dem Erwartungswert Null und einer maximalen Amplitude von 0,25 Prozent lediglich 120 Proben von insgesamt 919 nicht rauschbehafteten Proben hinzufügt, was die Konvergenz des ARX-Modells 212 wiederum verbesserte, obwohl die Übereinstimmung mit dem FIR-Modell 210 nicht perfekt war. Ähnliche Ergebnisse wurden erhalten, wenn Rauschen mit einer maximalen Amplitude von 0,1 Prozent sämtlichen nicht rauschbehafteten Proben hinzugefügt wurde, was immer noch zu einer verbesserten Konvergenz des ARX-Modells führte.
Bei der Validierung des in dieser Offenlegungsschrift beschriebenen Konzepts zum Erzeugen eines robusten Modells wurde festgestellt, dass die Fehlerempfindlichkeit in den Totzeitschätzungen allgemein mit der Amplitude des Rauschens abnimmt. Eine Anzahl spezifischer Tests, die die Wirkungen des Hinzufügens von Rauschen veranschaulichen, werden jetzt nachfolgend beschrieben. Insbesondere verwendeten diese Tests einen Ein-Kreis-Prozess, der definiert ist als Prozess zweiter Ordnung mit Verstärkung = 1, DT = 2, T₁= T₂= 20 (wobei DT die Totzeit ist und T₁ und T₂ die Zeitkonstanten erster und zweiter Ordnung des parametrischen Modells sind). In diesen Tests wurde eine Zeit bis zum stabilen Zustand T_ss von 240 während der Modellidentifizierung verwendet. Die im Test verwendeten Daten sind in 10 im Auswahlbereich 220 zwischen 9:21 Uhr und 9:52 Uhr, d.h. Daten über einen Zeitraum von 31 Minuten, dargestellt. Ohne Hinzufügen von Rauschen zu den Daten lieferte die Prozedur zur Identifizierung des ARX-Modells keine Zeitkonstante zweiter Ordnung und bestimmte eine zu kleine Verstärkung sowie eine zu große Totzeit. Während die Prozedur zur Bestimmung eines FIR-Modells ein FIR-Modell bestimmte, war die Totzeit des FIR-Modells null, was nicht korrekt ist. In dem Versuch, diese Probleme zu beseitigen, wurde nach dem früheren Stand der Technik versucht, die Zahl der Parameter manuell zu erhöhen, mehr Prozessdaten manuell hinzuzufügen und die Schrittgröße der Prozessirritationseingabe manuell zu vergrößern, was jedoch generell keine signifikante Verbesserung in der Modellidentifizierung erbrachte.
Bei Hinzufügen von künstlichem Rauschen zu den Prozessdaten nach dem Prozessirritationstest wurden jedoch signifikante Verbesserungen der Modellqualität beobachtet. Tatsächlich sind die Ergebnisse des Hinzufügens gleichmäßig verteilten Rauschens von 0,3 %, 0.4 % und 0,5 % (maximale Amplitude) zu den Daten in 11 bis
13 sowohl für das FIR-Modell 230 als auch für das ARX-Modell 232 dargestellt. Wie gezeigt werden wird, stellt es sich so dar, dass eine maximale Amplitude des Rauschens von 0,4 % der Skala in diesem Fall optimal erscheint, da dies die engste Übereinstimmung zwischen dem FIR-Modell und dem ARX-Modell liefert.
Weiterhin wurde festgestellt, dass Rauschen zu den Prozesseingaben statt zu den vom Prozessirritationstest gesammelten Daten hinzugefügt werden konnte. Insbesondere wurden signifikante Verbesserungen bei der Identifizierung des parametrischen Modells festgestellt, wenn ein Testzyklus ausgeführt wurde, bei dem Rauschen zur Ausgabe des Signalgenerators hinzugefügt wurde, der zur Irritation des Prozesses zur Durchführung des Prozesstests verwendet wurde. 14 zeigt das gewünschte Prozessirritationssignal 240, dem zufälliges, gleichmäßig verteiltes Rauschen mit dem Erwartungswert Null und einer maximalen Amplitude von 0,4 Prozent hinzugefügt wurde, sowie die gesammelten Prozessausgabedaten 242, die aus diesem rauschbehafteten Testsignal resultieren. 15 zeigt die Ergebnisse des FIR-Modells 244 und die Ergebnisse des ARX-Modells 246 auf der Grundlage der mittels des rauschbehafteten Prozessirritationssignals gesammelten Prozessdaten.
Gleichermaßen wurde festgestellt, dass das Hinzufügen von zufälligem, gleichmäßig verteiltem Rauschen mit dem Erwartungswert Null und einer maximalen Amplitude von 0,4 Prozent zu Prozessdaten, die bereits 0,4 % echtes Rauschen enthielten, ein fast identisches Ergebnis in Bezug auf die Modellidentifizierung erzeugt. Weiterhin wurde allgemein festgestellt, dass signifikante Mengen von Prozessdaten von der Verwendung bei der Erzeugung des Modells ausgenommen werden können, wenn den verbleibenden Daten Rauschen hinzugefügt wird, und dass es dann immer noch möglich ist, adäquate Modelle zu erzeugen. Insbesondere funktionierte die Routine zum Erzeugen des ARX-Modells wie erwartet ungeachtet dessen, wo sich die fehlenden Daten befanden, und während die Routine zum Erzeugen des FIR-Modells zuerst versagte, war sie gleichwohl noch in der Lage, auch bei Fehlen einiger Daten Modelle zu erzeugen. Die linke Kurve in 16 zeigt einen in diesem Test verwendeten kompletten Testdatensatz 250, während die sich ergebenden Modellergebnisse für das FIR-Modell (252) und das ARX-Modell (254) im rechten Teil von 16 dargestellt sind. Man erkennt, dass das FIR-Modell 262 lediglich über ca. 60 Scans berechnet wurde, um die zum Erzeugen dieses Modells erforderlichen Berechnungen zu reduzieren. 17 bis 20 veranschaulichen den Effekt auf die Ergebnisse des FIR- und des ARX-Modells (252 bzw. 254), wenn Testdaten ausgeschlossen werden, wie dies in den ausgeschlossenen Bereichen 260 im linken Teil dieser Figuren dargestellt ist. In jedem dieser Fälle wurde gleichmäßig verteiltes, zufälliges Rauschen mit dem Erwartungswert Null und einer maximalen Amplitude von 0,4 % den Prozessausgabetestdaten hinzugefügt, die im linken Teil dieser Figuren dargestellt sind. Man erkennt, dass das FIR-Modell 252 insbesondere dann zuerst versagte, wenn Daten aus multiplen, nicht zusammenhängenden Regionen des Datensatzes ausgeschlossen wurden, dass jedoch signifikante Mengen von Daten aus dem Test ausgeschlossen werden könnten und es gleichwohl immer noch möglich war, Prozessmodelle zu entwickeln.
Ähnliche Tests wurden mit Prozessen mit multiplen Variablen mit denselben allgemeinen Schlussfolgerungen durchgeführt, d.h. dass bessere Modellidentifizierungsergebnisse erhalten wurde, wenn zufälliges Rauschen mit dem Erwartungswert Null zu den Prozesstestdaten hinzugefügt wurde, dass die Fehlerempfindlichkeit in den Totzeitschätzungen mit der Amplitude des Rauschens abnahm, dass Schätzungen der Prozessverstärkung allgemein besser waren (wobei die Erzeugung des FIR-Modells allgemein bessere Verstärkungsschätzungen als die Erzeugung des ARX-Modells erbrachte) und dass eine signifikante Menge von Prozessdaten einschließlich Daten in der Mitte des Datensatzes aus dem Test ausgeschlossen werden kann und es nach wie vor möglich ist, ein Prozessmodell zu erzeugen (wobei die Erzeugung des ARX-Modells toleranter gegenüber fehlenden Daten ist als die Erzeugung des FIR-Modells). Weiterhin ist festzustellen, dass die Technik des Hinzufügens von Rauschen zu den Testdaten die entwickelten FIR-Modelle zwar nicht signifikant verbesserte und sie in Abhängigkeit von der Größe des hinzugefügten Rauschens geringfügig verschlechtert haben kann, sie jedoch die Genauigkeit der FIR-Modelle so lange nicht signifikant reduzierte, bis der zur Erzeugung des Modells verwendete Datensatz schwerwiegend eingeschränkt wurde. Es wurde jedoch festgestellt, dass das Hinzufügen von zufälligem Rauschen zu den Testdaten die Fähigkeit der Routine zur Erzeugung des ATX-Modells zu konvergieren und dadurch einen kompletten Satz von Modellparametern zu bestimmen, signifikant erhöhte und dadurch diese Routine zur Erzeugung eines Prozessmodells robuster machte.
Somit stehen, wie vorstehend beschrieben, die Konfidenzintervalle in einer engen Beziehung zum Rauschen. Daher können Konfidenzintervalle problemlos erweitert werden, indem ein geringes Niveau zufälligen Rauschens den Testdaten überlagert wird. Die Beobachtung führt zu einer Technik zur Verbesserung der Konvergenz der Modellparameter durch Erweiterung der Konfidenzintervalle und führt zu einer Technik, die in der Lage ist, ein Modell aus Daten zu entwickeln, die zuvor zu keiner Konvergenz der Modellparameter geführt hatten, und dies mit vergrößerten Konfidenzintervallen zu leisten. Als Ergebnis wurde die Robustheit der Prozessmodellentwicklung signifikant erhöht.
Wie zu erkennen ist, versetzen die in dieser Offenlegungsschrift beschriebenen Routinen und Verfahren zur Erzeugung der MPC- oder erweiterten Steuerungslogik einen Anwender in die Lage, erweiterte Steuerungsblöcke wie beispielsweise MPC-Steuerungsblöcke, neuronale Netzwerke modellierende Blöcke oder Steuerungsblöcke etc. zu erzeugen, ohne sonderlich umfassende Fachkenntnisse darüber zu besitzen, wie diese Blöcke erzeugt werden, und sie versetzen einen Bediener in die Lage, einen erweiterten Steuerungsblock zu erzeugen und zu verwenden, ohne eine umfangreiche Neuprogrammierung des Prozesses durchzuführen, um eine erweiterte Steuerung zu realisieren, und ohne dass generell die Notwendigkeit besteht, den Prozesstestaufbau zu verändern, um ein adäquates Prozessmodell zu bestimmen.
Während die erweiterten Steuerungsblöcke, die Prozesssimulationsblöcke und die dazu gehörigen Erzeugungs- und Testroutinen in dieser Offenlegungsschrift dergestalt beschrieben sind, dass sie in Verbindung mit Feldbus- und Standard-4-20-mA-Geräten verwendet werden, können sie selbstverständlich unter Verwendung jedes anderen Prozesssteuerungskommunikationsprotokolls oder jeder anderen Programmierungsumgebung implementiert und mit allen anderen Typen von Geräten, Funktionsblöcken oder Steuerungen verwendet werden. Weiterhin ist darauf hinzuweisen, dass die Verwendung des Ausdrucks "Funktionsblock" in dieser Offenlegungsschrift nicht auf das beschränkt ist, was das Feldbus-Protokoll oder das DeltaV-Steuerungsprotokoll als Funktionsblock bezeichnen, sondern dass dieser Ausdruck jeden anderen Typ von Block, Programm, Hardware, Firmware etc. umfasst, die mit jedem beliebigen Typ von Steuerungssystem und/oder Kommunikationsprotokoll verbunden sind, die für die Implementierung einer beliebigen Prozesssteuerungsfunktion verwendet werden können. Während weiterhin Funktionsblöcke typischerweise die Form von Objekten innerhalb einer objektorientierten Programmierungsumgebung annehmen, braucht dies nicht der Fall zu sein.
Obwohl die in dieser Offenlegungsschrift beschriebenen erweiterten Steuerungsblöcke, die Routinen zur Erzeugung des Prozessmodells, die Prozess simulationsblöcke und die dazu gehörigen Erzeugungs- und Testroutinen vorzugsweise in Software implementiert werden, können sie in Hardware, Firmware, etc. implementiert und von jedem anderen mit einem Prozesssteuerungssystem verbundenen Prozessor ausgeführt werden. Die in dieser Offenlegungsschrift beschriebene Routine 40 kann mithin in einer Standard-Universal-CPU oder auf spezifisch entwickelter Hardware oder Firmware wie beispielsweise ASICs, falls gewünscht, implementiert werden. Die Software kann, wenn in Software implementiert, in jedem computerlesbaren Speicher wie beispielsweise auf Magnetplatte, Laser-Disk, optischer Disk oder einem anderen Speichermedium, in einem Arbeitsspeicher oder in einem Nurlesespeicher eines Computers oder Prozessors etc. gespeichert werden. Entsprechend kann diese Software einem Anwender oder einem Prozesssteuerungssystem mittels jeder bekannten oder gewünschten Übergabemethode wie beispielsweise auf einer computerlesbaren Diskette oder einem anderen transportablen Computer-Speichermedium übergeben oder moduliert und über einen Kommunikationskanal wie beispielsweise eine Telefonleitung, das Internet etc. gesendet werden (wobei diese als identisch oder austauschbar mit der Übergabe der betreffenden Software mittels eines transportablen Speichermediums betrachtet wird).
Während somit die vorliegende Erfindung zwar unter Bezugnahme auf spezifische Beispiele beschrieben wird, die lediglich der Veranschaulichung dienen und diese Erfindung nicht einschränken sollen, ist es jedoch für den technisch Versierten offenkundig, dass Änderungen, Ergänzungen oder Streichungen an den dargestellten Ausführungen vorgenommen werden können, ohne vom Geist und Umfang der Erfindung abzuweichen.

Claims

Verfahren zur Erzeugung eines Prozessmodells für einen Prozess, aufweisend: Sammeln von den Prozessablauf repräsentierenden Prozessdaten vom Prozess; Hinzufügen von Rauschen zu den Prozessdaten zur Erzeugung aufbereiteter Prozessdaten und Bestimmen eines Prozessmodells aus den aufbereiteten Prozessdaten.
Verfahren nach Anspruch 1, wobei das Sammeln der Prozessdaten ein Irritieren des Prozesses mittels eines bekannten Prozessirritationssignals und das Sammeln von Prozessdaten beinhaltet, die für eine Prozessantwort auf das Prozessirritationssignal repräsentativ sind.
Verfahren nach Anspruch 2, wobei das Hinzufügen von Rauschen zu den Prozessdaten das Hinzufügen von Rauschen zu einem Prozessausgabesignal beinhaltet, das für die Prozessantwort auf das Prozessirritationssignal repräsentativ ist.
Verfahren nach Anspruch 2, wobei das Hinzufügen von Rauschen zu den Prozessdaten das Hinzufügen von Rauschen zu dem Prozessirritationssignal beinhaltet, bevor der Prozess mittels des Prozessirritationssignals irritiert wird, um auf diese Weise Rauschen zu Daten hinzuzufügen, die als die gesammelten Prozessdaten gesammelt werden.
Verfahren nach Anspruch 1, wobei die Bestimmung des Prozessmodells die Bestimmung eines oder mehrerer Parameter eines parametrischen Prozessmodells beinhaltet.
Verfahren nach Anspruch 5, wobei die Bestimmung des Prozessmodells die Bestimmung eines oder mehrerer Parameter eines autoregressiven Prozessmodells mit externen Eingaben beinhaltet.
Verfahren nach Anspruch 1, wobei die Bestimmung eines Prozessmodells die Bestimmung eines nichtparametrischen Prozessmodells beinhaltet.
Verfahren nach Anspruch 7, wobei die Bestimmung des Prozessmodells die Bestimmung eines finiten Impulsantwort-Prozessmodells beinhaltet.
Verfahren nach Anspruch 1, wobei das Hinzufügen von Rauschen zu den Prozessdaten zur Erzeugung der aufbereiteten Prozessdaten das Hinzufügen zufälligen Rauschens zu den Prozessdaten beinhaltet.
Verfahren nach Anspruch 9, wobei das Hinzufügen zufälligen Rauschens zu den Prozessdaten das Hinzufügen von Rauschen mit dem Erwartungswert Null zu den Prozessdaten beinhaltet.
Verfahren nach Anspruch 10, wobei das Hinzufügen von zufälligem Rauschen zu den Prozessdaten das Hinzufügen gleichmäßig verteilten zufälligen Rauschens mit einer maximalen Amplitude zwischen 0,2 und 0,5 Prozent des Bereichs der gesammelten Prozessdaten beinhaltet.
Verfahren nach Anspruch 10, wobei das Hinzufügen von zufälligem Rauschen zu den Prozessdaten das Hinzufügen gleichmäßig verteilten zufälligen Rauschens mit einer maximalen Amplitude von ca. 0,4 Prozent der Bandbreite der gesammelten Prozessdaten beinhaltet.
Verfahren nach Anspruch 1, wobei das Bestimmen des Prozessdatenmodells aus den aufbereiteten Prozessdaten eine Schätzung einer Prozesstotzeit für den Prozess aus den gesammelten Prozessdaten sowie die Verwendung der Totzeit und der aufbereiteten Prozessdaten zur Bestimmung des Prozessmodells beinhaltet.
Verfahren nach Anspruch 13, wobei die Schätzung der Prozesstotzeit das Erzeugen eines weiteren Prozessmodells aus den gesammelten Prozessdaten sowie die Bestimmung einer Schätzung der Prozesstotzeit aus dem weiteren Prozessmodell beinhaltet.
Verfahren nach Anspruch 14, wobei das Erzeugen des weiteren Prozessmodells die Bestimmung eines finiten Impulsantwortmodells beinhaltet.
Verfahren nach Anspruch 1, weiterhin beinhaltend die Filterung der gesammelten Prozessdaten oder der aufbereiteten Prozessdaten vor Erzeugung des Prozessmodells aus den aufbereiteten Prozessdaten.
Verfahren nach Anspruch 1, wobei das Hinzufügen von Rauschen zu den Prozessdaten die Bestimmung einer Amplitude des Rauschens als Funktion der gesammelten Prozessdaten beinhaltet.
Verfahren nach Anspruch 17, wobei das Bestimmen einer Amplitude des Rauschens die Bestimmung einer Amplitude des Rauschens als Funktion der Bandbreite der gesammelten Prozessdaten, eines Mittelwerts der gesammelten Prozessdaten oder einer Standardabweichung der gesammelten Prozessdaten beinhaltet.
Verfahren nach Anspruch 1, wobei das Hinzufügen von Rauschen zu den Prozessdaten die Bestimmung einer Amplitude des Rauschens als Funktion eines Prozesseingabesignals beinhaltet, das zur Erzeugung der den Prozessablauf repräsentierenden Prozessdaten verwendet wird.
Modellerzeugungssystem zur Erzeugung eines Prozessmodells aus einem Prozess in einer Prozessumgebung, die einen oder mehrere Prozessoren und einen computerlesbaren Speicher aufweist, wobei das Modellerzeugungssystem aufweist: eine erste Routine, die in dem computerlesbaren Speicher gespeichert und angepasst ist, um auf mindestens einem des einen oder der mehreren Prozessoren ausgeführt zu werden, um vom Prozess den Prozessablauf repräsentierende Daten für zumindest einen Teil des Prozesses zu sammeln; eine zweite Routine, die in dem computerlesbaren Speicher gespeichert und angepasst ist, um auf mindestens einem des einen oder der mehreren Prozessoren ausgeführt zu werden, um zu den Prozessdaten Rauschen hinzuzufügen, um aufbereitete Prozessdaten zu erzeugen, und eine Modellerzeugungsroutine, die in dem computerlesbaren Speicher gespeichert und angepasst ist, um auf mindestens einem des einen oder der mehreren Prozessoren ausgeführt zu werden, um ein Prozessmodell aus den aufbereiteten Prozessdaten zu erzeugen.
Modellerzeugungssystem nach Anspruch 20, wobei die Modellerzeugungsroutine eine Routine zur Erzeugung eines parametrischen Modells ist, die ein parametrisches Modell durch Bestimmung einer oder mehrerer Parameter des parametrischen Modells aus den aufbereiteten Prozessdaten erzeugt.
Modellerzeugungssystem nach Anspruch 21, wobei die Modellerzeugungsroutine eine autoregressive Prozessmodellerzeugungsroutine mit externen Eingaben ist.
Modelleerzeugungssystem nach Anspruch 21, wobei die Modellerzeugungsroutine eine Prozessparameterroutine aufweist, die eine Totzeit des Prozesses schätzt, sowie eine Modellparameterschätzungsroutine, die den einen oder die mehreren Parameter des parametrischen Modells aus den aufbereiteten Prozessdaten und der Schätzung der Prozesstotzeit bestimmt.
Modellerzeugungssystem nach Anspruch 23, wobei die Prozessparameterroutine ein nichtparametrisches Modell für den Prozess erzeugt und die Prozesstotzeit aus dem nichtparametrischen Modell bestimmt.
Modellerzeugungssystem nach Anspruch 24, wobei die Prozessparameterroutine ein finites Impulsantwortmodell als nichtparametrisches Modell erzeugt.
Modellerzeugungssystem nach Anspruch 20, weiterhin aufweisend eine dritte Routine, die in einem computerlesbaren Speicher gespeichert und angepasst ist, um auf mindestens einem des einen oder der mehreren Prozessoren ausgeführt zu werden, um eine Prozesssteuerung zu erzeugen, die das Prozessmodell verwendet.
Modellerzeugungssystem nach Anspruch 26, wobei die Prozesssteuerung eine auf modellprädiktiver Steuerung basierende Steuerung ist.
Modellerzeugungssystem nach Anspruch 20, wobei die erste Routine einen Signalgenerator aufweist, der ein bekanntes Prozessirritationssignal erzeugt, um den Prozess zu irritieren, sowie eine Sammlungsroutine, die Prozessdaten sammelt, die eine Prozessantwort auf das Prozessirritationssignal repräsentieren.
Modellerzeugungssystem nach Anspruch 28, wobei die zweite Routine angepasst ist, um den Prozessdaten Rauschen hinzuzufügen, indem dem Prozessirritationssignal Rauschen hinzugefügt wird, sodass die die Prozessantwort repräsentierenden gesammelten Prozessdaten die aufbereiteten Prozessdaten sind.
Modellerzeugungssystem nach Anspruch 29, wobei die zweite Routine angepasst ist, um zufälliges Rauschen mit dem Erwartungswert Null zum Prozessirritationssignal hinzuzufügen.
Modellerzeugungssystem nach Anspruch 30, wobei die zweite Routine angepasst ist, um es einem Anwender zu ermöglichen, eine Größenordnung in Verbindung mit dem dem Prozessirritationssignal hinzuzufügenden zufälligen Rauschen mit dem Erwartungswert Null zu wählen.
Modellerzeugungssystem nach Anspruch 20, wobei die zweite Routine angepasst ist, um zufälliges Rauschen mit dem Erwartungswert Null zu den Prozessdaten hinzuzufügen.
Modellerzeugungssystem nach Anspruch 32, wobei die zweite Routine angepasst ist, um es einem Anwender zu ermöglichen, eine Größenordnung in Verbindung mit dem den Prozessdaten hinzuzufügenden zufälligen Rauschen mit dem Erwartungswert Null zu wählen.
Modellerzeugungssystem nach Anspruch 32, wobei die zweite Routine angepasst ist, um gleichmäßig verteiltes zufälliges Rauschen mit einer maximalen Amplitude zwischen 0,2 und 0,5 Prozent der Bandbreite der Prozessdaten hinzuzufügen.
Modellerzeugungssystem nach Anspruch 32, wobei die zweite Routine angepasst ist, um gleichmäßig verteiltes zufälliges Rauschen mit einer maximalen Amplitude von ca. 0,4 Prozent der Bandbreite der Prozessdaten hinzuzufügen.
Modellerzeugungssystem nach Anspruch 20, wobei die zweite Routine eine Amplitude des Rauschens bestimmt, das den Prozessdaten als Funktion der Prozessdaten hinzugefügt wird.
Modellerzeugungssystem nach Anspruch 36, wobei die zweite Routine die Amplitude des Rauschens als Funktion einer Bandbreite oder eines Mittelwerts oder einer Standardabweichung der Prozessdaten bestimmt.
Modellerzeugungssystem nach Anspruch 20, wobei die zweite Routine eine Amplitude des Rauschens bestimmt, das den Prozessdaten als Funktion eines Prozesseingabesignals hinzugefügt wird, das zur Erzeugung der Prozessdaten verwendet wird.
Verfahren zur Erzeugung eines Steuerungs- oder Simulationsblocks zur Steuerung oder Simulation mindestens eines Teils eines Prozesses, aufweisend: Übergabe eines bekannten Prozessirritationssignals an den Prozess, um den Prozess zu veranlassen, eine Veränderung zu erfahren; Sammeln von Prozessdaten aus dem Prozess, die eine Antwort auf das Prozessirritationssignal repräsentieren; Hinzfügen von Rauschen zu den Prozessdaten, um aufbereitete Prozessdaten zu erzeugen, und Bestimmen eines Prozessmodells aus den aufbereiteten Prozessdaten und Erzeugen des Steuerungs- oder Simulationsblocks mittels des bestimmten Prozessmodells.
Verfahren nach Anspruch 39, wobei das Hinzufügen von Rauschen zu den Prozessdaten das Hinzufügen von Rauschen zu dem Prozessirritationssignal beinhaltet, bevor das Prozessirritationssignal an den Prozess übertragen wird, um auf diese Weise Rauschen zu den gesammelten Prozessdaten hinzuzufügen.
Verfahren nach Anspruch 39, wobei die Bestimmung des Prozessmodells die Bestimmung eines oder mehrerer Parameter eines parametrischen Prozessmodells beinhaltet.
Verfahren nach Anspruch 41, wobei die Bestimmung des Prozessmodells die Bestimmung eines oder mehrerer Parameter eines autoregressiven Prozessmodells mit externen Eingaben beinhaltet.
Verfahren nach Anspruch 39, wobei die Bestimmung des Prozessmodells die Bestimmung eines nichtparametrischen Prozessmodells beinhaltet.
Verfahren nach Anspruch 39, wobei das Hinzufügen von Rauschen zu den Prozessdaten zur Erzeugung von aufbereiteten Prozessdaten das Hinzufügen zufälligen Rauschens zu den Prozessdaten beinhaltet.
Verfahren nach Anspruch 44, wobei das Hinzufügen zufälligen Rauschens zu den Prozessdaten das Hinzufügen von Rauschen mit dem Erwartungswert Null zu den Prozessdaten beinhaltet.
Verfahren nach Anspruch 45, wobei das Hinzufügen von Rauschen zu den Prozessdaten das Hinzufügen gleichmäßig verteilten zufälligen Rauschens mit einer maximalen Amplitude zwischen 0,2 und 0,5 Prozent der Bandbreite der Prozessdaten beinhaltet.
Verfahren nach Anspruch 45, wobei das Hinzufügen von zufälligem Rauschen zu den Prozessdaten das Hinzufügen gleichmäßig verteilten zufälligen Rauschens mit einer maximalen Amplitude von ca. 0,4 Prozent der Bandbreite der Prozessdaten beinhaltet.
Verfahren nach Anspruch 39, wobei das Bestimmen des Prozessdatenmodells aus den aufbereiteten Prozessdaten eine Schätzung einer Prozesstotzeit für den Prozess aus den Prozessdaten sowie die Verwendung der geschätzten Totzeit und der aufbereiteten Prozessdaten zur Bestimmung des Prozessmodells beinhaltet.
Verfahren nach Anspruch 48, wobei die Schätzung der Prozesstotzeit das Erzeugen eines weiteren Prozessmodells aus den Prozessdaten sowie die Bestimmung einer Schätzung der Prozesstotzeit aus dem weiteren Prozessmodell beinhaltet.
Verfahren nach Anspruch 39, weiterhin beinhaltend die Filterung der Prozessdaten oder der aufbereiteten Prozessdaten vor Erzeugung des Prozessmodells aus den aufbereiteten Prozessdaten.
Verfahren nach Anspruch 39, wobei die Erzeugung des Steuerungs- oder Simulationsblocks mittels des bestimmten Prozessmodells die Erzeugung eines modellprädiktiven Steuerungsblocks beinhaltet.
Verfahren nach Anspruch 51, wobei die Erzeugung des modellprädiktiven Steuerungsblocks die Erzeugung einer Steuerung mit multiplem Eingängen und multiplen Ausgängen beinhaltet.
Verfahren nach Anspruch 39, wobei die Erzeugung des Steuerungs- oder Simulationsblocks mittels des bestimmten Prozessmodells die Erzeugung eines Steuerungsblocks mit einem einzigen Eingang und einem einzigen Ausgang beinhaltet.
Verfahren nach Anspruch 39, wobei die Bestimmung eines Prozessmodells aus den aufbereiteten Prozessdaten die Bestimmung eines Prozessmodells mit einem einzigen Eingang und einem einzigen Ausgang beinhaltet.
Verfahren nach Anspruch 39, weiterhin beinhaltend die Filterung der Prozessdaten oder der aufbereiteten Prozessdaten vor Erzeugung des Prozessmodells aus den aufbereiteten Prozessdaten.
Verfahren nach Anspruch 39, wobei das Hinzufügen von Rauschen zu den Prozessdaten die Bestimmung einer Amplitude des Rauschens als Funktion der Prozessdaten beinhaltet.
Verfahren nach Anspruch 56, wobei das Bestimmen einer Amplitude des Rauschens die Bestimmung einer Amplitude des Rauschens als Funktion der Bandbreite der Prozessdaten, eines Mittelwerts der Prozessdaten oder einer Standardabweichung der Prozessdaten beinhaltet.
Verfahren nach Anspruch 39, wobei das Hinzufügen von Rauschen zu den Prozessdaten die Bestimmung einer Amplitude des Rauschens als Funktion eines Prozessirritationssignals beinhaltet.