DE10011661B4 - Prozeßsteuersystem mit Prozeßsteuerroutinen unter Verwendung von indirekter Referenzierung - Google Patents

Prozeßsteuersystem mit Prozeßsteuerroutinen unter Verwendung von indirekter Referenzierung Download PDF

Info

Publication number
DE10011661B4
DE10011661B4 DE10011661A DE10011661A DE10011661B4 DE 10011661 B4 DE10011661 B4 DE 10011661B4 DE 10011661 A DE10011661 A DE 10011661A DE 10011661 A DE10011661 A DE 10011661A DE 10011661 B4 DE10011661 B4 DE 10011661B4
Authority
DE
Germany
Prior art keywords
phase
unit
alias
routine
class
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE10011661A
Other languages
English (en)
Other versions
DE10011661A1 (de
Inventor
William G. Irwin
Robert B. Havekost
Dennis L. Stevenson
David L. Deitz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fisher Rosemount Systems Inc
Original Assignee
Fisher Rosemount Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fisher Rosemount Systems Inc filed Critical Fisher Rosemount Systems Inc
Publication of DE10011661A1 publication Critical patent/DE10011661A1/de
Application granted granted Critical
Publication of DE10011661B4 publication Critical patent/DE10011661B4/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/04Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/05Programmable logic controllers, e.g. simulating logic interconnections of signals according to ladder diagrams or function charts
    • G05B19/056Programming the PLC
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/04Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/05Programmable logic controllers, e.g. simulating logic interconnections of signals according to ladder diagrams or function charts
    • G05B19/052Linking several PLC's
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/418Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS], computer integrated manufacturing [CIM]
    • G05B19/4185Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS], computer integrated manufacturing [CIM] characterised by the network communication
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99944Object-oriented database structure
    • Y10S707/99945Object-oriented database structure processing
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99948Application of database or data structure, e.g. distributed, multimedia, or image

Abstract

Prozesssteuersystem zur Verwendung bei der Steuerung eines Prozesses, der mehrere Einheitenklassen (50, 52) hat, von welchen jede ein oder mehrere Einheitenmodule (54, 64) enthält mit:
einer Steuereinrichtung (12);
einem Speicher (20, 22);
einer generischen Steuerroutine, die einen Aliasnamen verwendet; und
eine Alias-Auflösungstabelle (60) für jedes der Einheitenmodule (54, 64) einer der Einheitenklassen (50, 52), wobei jede Alias-Auflösungstabelle (60) eine Aliasdefinition für den Aliasnamen hat;
wobei die generische Steuerroutine in dem Speicher (20, 22) gespeichert ist,
dadurch gekennzeichnet, dass,
wenn die Steuerung eines bestimmten Einheitenmoduls (54, 64) erforderlich ist, die Steuereinrichtung (12) unter Verwendung der Alias-Auflösungstabelle (60) für das bestimmte Einheitenmodul (54, 64) eine diesbezüglich konkretisierte Version der generischen Steuerroutine für das bestimmte Einheitenmodule (54, 64) erstellt und das bestimmte Einheitenmodul (54, 64) steuert, indem die diesbezüglich konkretisierte Version der generischen Steuerroutine ausgeführt wird,
wobei
die generische Steuerroutine so ausgelegt ist, dass...

Description

  • Die vorliegende Erfindung betrifft ein Prozesssteuersystem nach dem Oberbegriff des Anspruch 1.
  • Prozeßsteuernetze, wie beispielsweise die in chemischen Prozessen, in Erdölverarbeitungsprozessen oder anderen Prozessen verwendeten, enthalten allgemein eine zentrale Prozeßsteuereinrichtung, die mit einer oder mehreren Anlageneinrichtungen in Kommunikationsverbindung steht, bei denen es sich beispielsweise um Ventilpositioniereinrichtungen, Schalter, Sensoren (wie z. B. Temperatur-, Druck- und Durchflußmengensensoren) etc. handeln kann. Diese Anlageneinrichtungen können physische Steuerfunktionen innerhalb des Prozesses (wie z. B. das Öffnen und das Schließen eines Ventils) durchführen, können Messungen innerhalb des Prozesses zur Verwendung bei der Regelung des Betriebsablaufes des Prozesses vornehmen oder können jede andere gewünschte Funktion innerhalb des Prozesses ausführen (vgl. DE 198 38 469 A1 ).
  • Prozeßsteuereinrichtungen waren bisher über eine oder mehrere analoge Signalleitungen oder Busleitungen mit Anlageneinrichtungen verbunden, welche beispielsweise 4–20 mA-Signale zu und von den Anlageneinrichtungen leiten können. In jüngerer Zeit hat die Prozeßsteuerindustrie jedoch eine Anzahl von standardisierten, offenen digitalen oder kombiniert digitalen und analogen Kommunikationsprotokollen entwickelt, wie z. B. das FOUNDATIONTM-FIELDBUS-(nachfolgend als ”Fieldbus” bezeichnet), HART®-, PROFIBUS®-, WORLDFIP®-, Device-Net® und CAN-Protokoll, welche verwendet werden können, um die Kommunikation zwischen einer Steuereinrichtung und Anlageneinrichtungen umzusetzen. Allgemein ausgedrückt empfängt die Prozeßsteuereinrichtung Signale, welche Messungen, die von einer oder mehreren Anlageneinrichtungen durchgeführt wurden, und/oder andere Informationen darstellen, die zu den Anlageneinrichtungen gehören, verwendet diese Informationen, um eine typischerweise komplexe Steuerroutine umzusetzen und erzeugt Steuersignale, die über die Signalleitungen oder Busleitungen zu den Anlageneinrichtungen gesendet werden, um dadurch den Betriebsablauf des Prozesses zu steuern (vgl. DE 100 21 698 A1 ).
  • Bestimmte Arten von Prozeßsteuernetzen, wie beispielsweise diejenigen, die in Stapelprozessen verwendet werden (vgl. US 5,727,128 A , enthalten typischerweise mehrere Garnituren von parallel angeordneten Geräten, die so gestaltet sind, daß sie dieselbe oder eine ähnliche Ausrüstung haben, welche im wesentlichen dieselbe Funktion innerhalb der Prozesse ausführt. Somit kann beispielsweise eine Fabrik zur Herstellung von Keksen mehrere Garnituren von Mischgeräten, mehrere Garnituren von Backgeräten und mehrere Garnituren von Verpackungsgeräten haben, wobei alle einzelnen Mischgeräte in der Lage sind, parallel zu arbeiten und so miteinander verbunden. werden können, daß sie in Reihe mit jedem der Backgeräte und jedem der Verpackungsgeräte arbeiten. In einem derartigen System ist es anstrebenswert, in der Lage zu sein, den selben Steueralgorithmus oder dieselbe Steuerroutine zu verwenden, um den Betrieb jeder bestimmten Garnitur von parallel vorhandenen Geräten zu steuern, um dadurch die Anzahl der Steuerroutinen zu reduzieren, die erstellt und innerhalb der Steuereinrichtung gespeichert werden müssen. Diese Steueralgorithmen müssen jedoch so geschrieben werden, daß sie bei der Ausführung die Ausrüstung einer bestimmten Einheit, die zu dieser Zeit verwendet wird, spezifizieren.
  • Bei einigen Systemen nach dem Stand der Technik wurde eine generalisierte Steuerroutine, welche Aliasnamen (das heißt nicht spezifizierte Variable) verwendete, um das spezifische Gerät zu bezeichnen, das von Paralleleinheit zu Paralleleinheit unterschiedlich war, in einer Workstation geschaffen (vgl. US 5,828,851 A ). Um eine Systemsteuereinrichtung in die Lage zu versetzen, die generalisierte Steuerroutine auf einer bestimmten Einheit auszuführen, wurde das generalisierte Programm unter Verwendung einer Alias-Auflösungstabelle, die für eine bestimmte Einheit geschaffen wurde, instantiiert. Eine derartige Alias-Auflösungstabelle enthielt eine Definition für jeden Aliasnamen, der in der generalisierten Steuerroutine verwendet wird, und wurde verwendet, um eine ausführbare Instanz der generalisierten Steuerroutine durch Substituieren der Werte in der Alias-Auflösungstabelle der bestimmten Einheit durch die Aliasnamen in der Steuerroutine zu schaffen. Diese diesbezüglich konkretisierte Steuerroutine wurde anschließend in die Steuereinrichtung heruntergeladen und in dieser gespeichert und daraufhin während der Laufzeit verwendet, um einen Steuervorgang (oder eine Steuerphase) in der bestimmten.
  • Einheit durchzuführen. Unter Verwendung dieses System mußte jedoch die Steuereinrichtung eine separate diesbezüglich konkretisierte (aufgelöste) Steuerroutine für jede der unterschiedlichen Paralleleinheiten speichern, was eine große Menge von Speicherplatz in der Steuereinrichtung erforderlich machte, insbesondere dann, wenn die Steuereinrichtung dafür verwendet wurde, eine große Anzahl von ähnlichen Einheiten zu steuern, und verwendet wurde, um eine große Anzahl von unterschiedlichen Operationen oder Phasen in jeder Einheit auszuführen (da separate diesbezüglich konkretisierte Steuerroutinen für jede Phase für jede Einheit erforderlich waren).
  • Bei einem anderen System nach dem Stand der Technik wurde die generalisierte Steuerroutine in der Steuereinrichtung gespeichert und während der Laufzeit verwendet, um die programmierte Operation oder Phase in einer der Paralleleinheiten, auf die sie angewandt wurde, durchzuführen. In diesem Fall wurden die Aliasnamen während der Laufzeit unter Verwendung der Alias-Auflösungstabelle für die bestimmte Einheit, die gesteuert wurde, aufgelöst. Bei dieser Konfiguration mußte jedoch dann, wenn eine Veränderung an der generalisierten Steuerroutine, welche gegenwärtig durch die Steuereinrichtung gefahren wurde, durchzuführen war, der Lauf dieser Routine unterbrochen werden, um es zu ermöglichen, daß eine neue generalisierte Steuerroutine in die Steuereinrichtung heruntergeladen wird. Dies führte zu Verlusten an Zeit, Material etc. im Zusammenhang mit dem abgebrochenen Lauf des Prozesses.
  • Ferner ermöglichte es keines dieser bekannten Systeme, eine einzelne generische Prozeßsteuerroutine mit Aliasnamen über mehrere oder unterschiedliche Klassen von Einheiten oder Geräten anzuwenden. Tatsächlich war bei diesen Systemen nach dem Stand der Technik eine Steuerroutine für eine Phase auf die Verwendung mit einer Einheitenklasse, das heißt einer bestimmten Art von Hardwareeinheit, wie z. B. Reaktoren oder Mischer etc., beschränkt. Als Resultat mußte zunächst eine generische Prozeßsteuerroutine geschaffen und gespeichert werden, um beispielsweise ein Reaktorgefäß zu füllen, während eine zweite generische Prozeßsteuerroutine geschaffen und gespeichert werden mußte, um Mischtanks zu füllen, und eine dritte geschaffen und gespeichert werden mußte, um Zuliefertanks zu füllen, was zu der Schaffung von vielen unterschiedlichen generischen Steuerroutinen zum Ausführen von im wesentlichen derselben Funktion an unterschiedlichen Arten von Hardware führte.
  • Entsprechend ermöglichte es keines dieser Systeme nach dem Stand der Technik der generischen Steuerroutine, Unterschiede zwischen den Geräten zu berücksichtigten, die zu den unterschiedlichen Modulen einer bestimmten Art einer Hardwareeinheit gehören. Wenn beispielsweise eine erste Reaktor-Einheit ein elektrisches Heizelement hatte und eine zweite Reaktor-Einheit ein Dampfheizelement, mußte eine unterschiedliche generische Steuerroutine zum Aufheizen jeder dieser Reaktor-Einheiten entwickelt werden, um die Unterschiede bei der Steuerung der elektrischen Heizung und der Dampfheizung zu berücksichtigen, obgleich der Prozeß nur erforderte, daß der Aufheizvorgang ausgeführt wurde, wobei die Art der Heizung irrelevant war. Dieses Problem tritt allgemein auf, wenn zusätzliche Einheiten oder Module (wie z. B. Reaktormodule) zu verschiedenen Zeiten zu einem Prozeßsteuersystem zugeführt werden und aus Gründen von Kosten, kürzlichen Fortschritten hinsichtlich der Hardware etc., die neu hinzugefügten Module, während sie so konstruiert sind, daß sie im wesentlichen dieselbe Funktion wie die vorhandenen Module ausführen, mit. geringfügig anderen Geräten ausgerüstet sind.
  • Ferner hatten diese Systeme nach dem Stand der Technik kein einfaches Verfahren zum Spezifizieren eines Parameters, der während der Laufzeit der Prozeßsteuerroutine für eine Phase eines Prozesses identifiziert werden sollte. Tatsächlich wurde bei den meisten Systemen nach dem Stand der Technik, die indirekte Referenzierung aufweisen, die Alias-Auflösungstabelle verwendet, um Aliasnamen aufzulösen, wenn die Prozeßsteuerroutine konfiguriert wurde und in maschinenlesbaren Code umgesetzt wurde, was vor der Laufzeit erfolgte. Um es zu ermöglichen, daß eine Variable während der Laufzeit geändert oder spezifiziert wurde, war bei einem System nach dem Stand der Technik ein Adressierschema, wie z. B. ein Adressenarray, vorgesehen, in welchem Referenzen oder Zeiger während der Laufzeit plaziert werden konnten, so daß dann, wenn das Steuerprogramm eine Instruktion erreichte, die auf eine der Adressen in dem Array verwies, das Programm zu der Einrichtung oder Position gehen würde, auf die durch den Inhalt der angegebenen Adresse verwiesen wurde. Es gab jedoch keine Möglichkeit, anzugeben, ob der Inhalt der Verweisadresse auf eine gültige Einrichtung oder eine ordnungsgemäße. Position innerhalb der Steuerroutine während der Laufzeit verwies. Wenn der Zeiger ungültig war, wird das Programm unterbrochen und nicht fortgeführt, was zu einem Produktionsstopp führt. Ferner war dieses Adressierschema komplex und schwierig in ordnungsgemäßer Weise zu verwenden, da es ein detailliertes Wissen über das Adressenarray, welches den Zeiger enthielt, und Kenntnisse, welche Adresse des Array von der Steuerroutine zu welcher Zeit verwendet wurde, erforderte. Somit war es sehr arbeitsaufwändig seitens der Programmierer und der Benutzer, sicherzustellen, daß ein korrekter Zeiger an der korrekten Adresse zur korrekten Zeit gespeichert war, um die Unterbrechung der Steuerroutine während der Laufzeit zu verhindern.
  • Die WO 98/13 737 A1 beschreibt demgegenüber ein Programm zur Steuerung eines Prozesses, wobei das Programm von einem Computersystem ausgeführt wird. Das Programm erlaubt einen dynamischen Zugriff auf Variablen zum Abfragen von Messdaten und zur Steuerung von Geräten. Für die dynamische Bindung ist ein gesondertes Modul vorgesehen, das mittels entsprechender Steuerbefehle im Programm angesprochen werden kann und die Auflösung der Referenzen übernimmt.
  • Das Erstellen eines derartigen Programms ist aufwändig und für Stapelprozesse ungeeignet, da man hier eine fast autonome Steuerung einzelner Garnituren anstrebt. Eine globale Steuerroutine ist unerwünscht, da sie die Flexibilität einschränkt.
  • Ausgehend von diesem Stand der Technik, ist es Aufgabe der vorliegenden Erfindung, ein flexibles und einfach anpassbares Prozesssteuersystem für Stapelprozesse bereit zu stellen.
  • Das Prozesssteuersystem nach Anspruch 1 löst diese Aufgabe.
  • Ein Prozeßsteuersystem enthält eine oder mehrere Prozeßsteuerroutinen, die eine indirekte Referenzierung unter Verwendung von Aliasnamen und/oder dynamischen Referenzparametern ermöglichen. Eine generische Prozeßsteuerroutine wird so geschrieben, daß sie Aliasnamen enthält, und diese generische Prozeßsteuerroutine wird in einer Steuereinrichtung gespeichert, die einen Prozeß steuert, der beispielsweise parallel vorhandene Ausrüstungen (parallel vorhandene Einheiten) aufweist. Vor der Ausführung einer Prozeßsteuerfunktion an einer bestimmten Einheit wird eine Instanz der generischen Routine, die diese Funktion steuert, geschaffen, in welcher die Aliasnamen in der generischen Steuerroutine durch Parameter ersetzt werden, die in einer Alias-Auflösungstabelle für die bestimmte Einheit definiert sind. Die Steuereinrichtung führt dann die diesbezüglich konkretisierte Version der generischen Routine aus, um den Betriebsablauf der Einheit zu steuern. Dies reduziert die Speichererfordernisse der Steuereinrichtung, da es der Steuereinrichtung erlaubt, nur die generische Routine und die instantiierten Versionen dieser Routine zu speichern, die gegenwärtig laufen, anstatt daß eine diesbezüglich konkretisierte Version der generischen Routine für alle Einheiten einzeln zu allen Zeiten gespeichert wird. Ferner ermöglicht dies, daß die generische Steuerroutine verändert wird, während eine Instanz derselben ausgeführt wird, ohne daß die in Ausführung befindliche Routine abgebrochen werden muß.
  • Falls erwünscht, können mit dem generischen Programm mehrere Algorithmen verbunden sein, wobei jeder der unterschiedlichen Algorithmen so gestaltet ist, daß er verschiedene Einheiten steuert, die geringfügig unterschiedliche Hardware haben, auch wenn diese unterschiedlichen Einheiten im wesentlichen dieselbe Funktion innerhalb des Prozeßsteuersystems ausführen. Wenn eine diesbezüglich konkretisierte Version des generischen Programms geschaffen wird, bestimmt die Steuereinrichtung, welcher der mehrfachen Algorithmen der generischen Routine zu verwenden ist, und zwar auf der Basis einer gespeicherten Angabe, welche die Hardwarekonfiguration der bestimmten Einheit identifiziert, für welche die diesbezüglich konkretisierte Steuerroutine geschaffen wird. Das System ermöglicht es ferner, eine Steuerroutine für mehrere Einheitenklassen oder unterschiedliche Arten von Hardware zu schaffen und an diesen anzuwenden, welche verwendet werden, um unterschiedliche Funktionen innerhalb des Prozeßsteuersystems auszuführen. In diesem Fall kann eine Konfigurationsroutine sicherstellen, daß eine Alias-Definition für jeden Aliasnamen in jeder Alias-Auflösungstabelle existiert, die zu den unterschiedlichen Klassen von Einheiten gehört, an welchen die generische Prozeßsteuerroutine angewendet werden soll.
  • Dies ermöglicht es, daß weniger generische Steuerroutinen geschrieben und in der Steuereinrichtung gespeichert werden, da eine einzelne generische Steuerroutine geschrieben und verwendet werden kann, um eine bestimmte Funktion an verschiedenen Arten von Geräten auszuführen, die für unterschiedliche Zwecke innerhalb des Prozeßsteuersystems verwendet werden.
  • Darüber hinaus kann die Prozeßsteuerroutine einen oder mehrere dynamische Referenzparameter verwenden, um es zu ermöglichen, daß ein Feld, eine Einrichtung, ein Parameter, etc. spezifiziert werden, nachdem das diesbezüglich konkretisierte ausführbare Programm erstellt wurde, das heißt, es zu ermöglichen, daß dynamisch ein Feld referenziert wird, und zwar zu der Zeit oder während der Zeit des Laufes. Der dynamische Referenzparameter hat mehrere Attribute, darunter beispielsweise ein Referenzattribut, das einen Zeiger, einen Pfad oder ein Identifizierungskennzeichen für die Einrichtung, das Feld bzw. den Parameter etc., die bzw. das referenziert wird, speichert, und ein Verbindungsattribut, das kennzeichnet, ob eine tatsächliche Verbindung zu dem Feld, das von dem Referenzattribut angegeben wurde, hergestellt werden kann, beispielsweise ob das Referenzattribut ein gültiges Feld innerhalb der Prozeßsteuersystemkonfiguration definiert. Der dynamische Referenzparameter kann ferner Attribute enthalten, die das Lesen aus und/oder Schreiben in das durch das Referenzattribut spezifizierten Feld als ein String oder als ein numerischer Wert erlauben. Ferner kann der dynamische Referenzparameter ein oder mehrere Attribute einschließen, die das Lesen eines oder mehrerer Statuswerte erlauben, die zu dem durch das Referenzattribut spezifizierten Feld gehören, darunter beispielsweise der Status dieses Feldes und der Status des letzten Schreibvorganges in dieses Feld.
  • Nachfolgend wird eine Ausführungsform der Erfindung unter Bezug auf die Zeichnung näher erläutert.
  • 1 zeigt eine teilweise als Blockdiagramm und teilweise als schematisches Diagramm ausgeführte Darstellung eines Steuernetzes, das eine oder mehrere Steuerroutinen verwendet, die Aliasnamen und/oder dynamische Referenzparameter zur Ausführung der Steuerung von Prozeßgeräten haben;
  • 2 ist ein Blockdiagramm einer Objektstruktur, die eine konzeptuelle Konfiguration des Prozeßsteuernetzes von 1 zeigt; und
  • 3 ist ein erweitertes Blockdiagramm eines Abschnitt der Objektstruktur von 2.
  • Wie 1 zeigt, enthält ein Prozeßsteuernetz 10 eine Prozeßsteuereinrichtung 12, die mit zahlreichen Workstations 14 über eine Ethernet-Verbindung 15 verbunden ist. Die Steuereinrichtung 12 ist ferner mit Einrichtungen oder Geräten innerhalb eines Prozesses (allgemein mit Bezugszeichen 16 bezeichnet) über eine Gruppe von Kommunikationsleitungen oder einen Bus 18 verbunden. Die Steuereinrichtung 12, die beispielsweise eine DeltaVTM-Steuereinrichtung sein kann, die von Fisher-Rosemont Systems, Inc. vertrieben wird, ist in der Lage, mit den Steuerelementen, wie z. B. Anlageneinrichtungen und Funktionsblöcken in Anlageneinrichtungen, zu kommunizieren, die über den Prozeß 16 verteilt sind, um eine oder mehrere Prozeßsteuerroutinen durchzuführen und dadurch die gewünschte Steuerung des Prozesses 16 umzusetzen. Die Workstations 14 (welche beispielsweise Personalcomputer sein können) können von einem oder mehreren Technikern oder Benutzern verwendet werden, um Prozeßsteuerroutinen zu gestalten, die von der Steuereinrichtung 12 auszuführen sind, um mit der Steuereinrichtung 12 zu kommunizieren, um derartige Prozeßsteuerroutinen herunterzuladen, und um Informationen zu empfangen und darzustellen, die zu dem Prozeß 16 während des Betriebsablaufs des Prozesses 16 gehören. Jede der Workstations 14 enthält einen Speicher 20 zum Speichern von Anwendungsprogrammen, wie z. B. Konfigurationsgestaltungsanwendungen, und zum Speichern von Daten, wie z. B. Konfigurationsdaten, die zu der Konfiguration des Prozesses 16 gehören. Jeder der Workstations 14 enthält ferner einen Prozessor 21, der die Anwendungen ausführt, um einen Benutzer in die Lage zu versetzen, Prozeßsteuerroutinen zu erstellen und diese Prozeßsteuerroutinen zu der Steuereinrichtung 12 herunterzuladen. Entsprechend enthält die Steuereinrichtung 12 einen Speicher 22 zum Speichern von Konfigurationsdaten und Prozeßsteuerroutinen, die zur Steuerung des Prozesses 16 zu verwenden sind, und enthält einen Prozessor 24, der die Prozeßsteuerroutinen ausführt, um eine Prozeßsteuerstrategie zu implementieren. Wenn die Steuereinrichtung 12 eine DeltaV-Steuereinrichtung ist, kann sie eine grafische Darstellung der Prozeßsteuerroutinen innerhalb der Steuereinrichtung 12 einem Benutzer über eine der Workstations 14 zur Verfügung stellen, welche die Steuerelemente innerhalb der Prozeßsteuerroutine und die Art und Weise, in der diese Steuerelemente konfiguriert sind, um die Steuerung des Prozesses 16 zu schaffen, dargestellt.
  • In dem in 1 gezeigten Prozeßsteuernetz 10 ist die Steuereinrichtung 12 über den Bus 18 mit drei Garnituren von ähnlich konfigurierten Reaktoren, die hierin als Reaktor_01, Reaktor_02 und Reaktor_03 bezeichnet werden, kommunikativ verbunden. Der Reaktor_01 enthält ein Reaktorgefäß 100, zwei Zulaufventile 101 und 102, die so angeschlossen sind, daß sie Fluideinlaßleitungen steuern, die Fluid in das Reaktorgefäß 100 abgeben, und ein Auslaßventil 103, das so angeschlossen ist, daß es einen Fluidfluß aus dem Reaktorgefäß 100 über eine Fluidauslaßleitung steuert. Eine Einrichtung 105, bei der es sich um einen Sensor, wie z. B. einen Temperatursensor, einen Drucksensor, eine Fluidpegelmeßeinrichtung oder eine andere Ausrüstung, wie z. B. eine elektrische Heizung oder eine Dampfheizung handeln kann, ist im oder nahe an dem Reaktorgefäß 100 angeordnet. In ähnlicher Weise enthält der Reaktor_02 ein Reaktorgefäß 200, zwei Zulaufventile 201 und 202, ein Auslaßventil 203 und eine Einrichtung 205, während der Reaktor_03 ein Reaktorgefäß 300, zwei Zulaufventile 301 und 302, ein Auslaßventil 303 und eine Einrichtung 305 enthält. Wie 1 zeigt, ist die Steuereinrichtung 12 mit den Ventilen 101103, 201203 und 301303 und den Einrichtungen 105, 205 und 305 über den Bus 18 in Kommunikationsverbindung, um den Betrieb dieser Elemente zu steuern und einen oder mehrere Betriebsabläufe der Reaktor-Einheiten auszuführen. Derartige Betriebsabläufe können beispielsweise das Füllen der Reaktorgefäße, das Erwärmen des Materials innerhalb der Reaktorgefäße, das Leeren der Reaktorgefäße, das Reinigen der Reaktorgefäße, etc. einschließen.
  • Die Ventile, Sensoren und weiteren Geräte, die in 1 dargestellt sind, können jede gewünschte Art oder jeden Typ von Geräten einschließen, darunter beispielsweise Fieldbus-Einrichtungen, Standard 4–20 mA-Einrichtungen, HART-Einrichtungen, etc. und können mit der Steuereinrichtung 12 unter Verwendung jedes bekannten oder gewünschten Kommunikationsprotokolls, wie z. B. des Fieldbus-Protokoll, des HART-Protokolls, des 4–20 mA-Analogprotokolls etc. kommunizieren. Ferner können weitere Typen von Einrichtungen gemäß den Prinzipien der vorliegenden Erfindung mit der Steuereinrichtung 12 verbunden und von dieser gesteuert werden. Ferner können wietere Steuereinrichtungen mit der Steuereinrichtung 12 und mit den Workstations 14 über die Ethernet-Kommunikationsleitung 15 verbunden sein, um andere Einrichtungen oder Bereiche zu steuern, die zu dem Prozeß 16 gehören, und der Betriebsablauf derartiger zusätzlichen Steuereinrichtungen kann mit dem Betriebsablauf der in 1 gezeigten Steuereinrichtung 12 in jeder gewünschten Weise koordiniert werden.
  • Allgemein ausgedrückt kann das Prozeßsteuersystem von 1 verwendet werden, um Stapelprozesse umzusetzen, in welchen beispielsweise eine der Workstations 14 oder die Steuereinrichtung 12 eine Stapelausführungsroutine ausführen, bei der es sich um eine Steuerroutine höherer Ebene handelt, welche den Betrieb einer oder mehrerer Reaktor-Einheiten (sowie anderer Einrichtungen) leitet, um eine Reihe von unterschiedlichen Schritten (allgemein als Phasen bezeichnet), die zur Herstellung eines Produkts, wie z. B. eines Lebensmittelprodukts, eines Arzneimittels etc. erforderlich sind. Um unterschiedliche Phasen zu implementieren, verwendet die Stapelausführungsroutine ein allgemein so bezeichnetes Rezept, das die auszuführenden Schritte, die Mengen und Zeiten, die zu den Schritten gehören, und die Reihenfolge der Schritte festlegt. Schritte für ein Rezept können beispielsweise das Füllen eines Reaktorgefäßes mit den geeigneten Materialien oder Inhaltsstoffen, das Mischen der Materialien in dem Reaktorgefäß, das Erwärmen der Materialien in dem Reaktorgefäß auf eine bestimmte Temperatur über eine bestimmte Zeitdauer, das Leeren des Reaktorgefäßes und anschließend das Reinigen des Reaktorgefäßes in Vorbereitung für den nächsten Stapelablauf einschließen. Jeder der Schritte definiert eine Phase des Stapelablaufes und die Stapelausführungsroutine innerhalb der Steuereinrichtung 12 führt für jede dieser Phasen einen unterschiedlichen Steueralgorithmus aus. Selbstverständlich können die bestimmten Materialien, Materialmengen, Erwärmungstemperaturen und Zeiten etc. für unterschiedliche Rezepte verschieden sein und folglich können diese Parameter von Stapelablauf zu Stapelablauf in Abhängigkeit von dem hergestellten Produkt und dem verwendeten Rezept geändert werden. Der Durchschnittsfachmann erkennt, daß hierin zwar Steuerroutinen und Konfigurationen für Stapelabläufe in den in 1 dargestellten Reaktor-Einheiten beschrieben werden, die Steuerroutinen jedoch zur Steuerung anderer gewünschter Einrichtungen zur Durchführung jedes anderen gewünschten Stapelprozeßablaufes oder zur Durchführung von kontinuierlichen Prozeßabläufen verwendet werden können, falls dies erwünscht ist.
  • Wie der Durchschnittsfachmann versteht, können dieselben Phasen oder Schritte eines Stapelprozesses an jeder der verschiedenen Reaktor-Einheiten in 1 gleichzeitig oder zu unterschiedlichen Zeiten implementiert werden. Da ferner die Reaktor-Einheiten in 1 allgemein dieselbe Anzahl und dieselbe Art von Geräten enthalten (das heißt sie gehören zur selben Einheitenklasse), kann dieselbe generische Phasensteuerroutine für eine bestimmte Phase verwendet werden, um jede der verschiedenen Reaktor-Einheiten zu steuern, mit der Ausnahme, daß diese generische Phasensteuerroutine modifiziert werden muß, um die verschiedene Hardware oder die unterschiedlichen Geräte, die zu den verschiedenen Reaktor-Einheiten gehören, zu steuern. Um beispielsweise eine Füllphase für den Reaktor_01 (während welcher die Reaktor-Einheit gefüllt wird) zu steuern, öffnet eine Füllsteuerroutine ein oder mehrere Zulaufventile 101 oder 102 für eine bestimmte Zeitdauer, beispielsweise bis der Fluidpegelmesser 105 feststellt, daß das Gefäß 100 voll ist. Dieselbe Steuerroutine kann jedoch verwendet werden, um eine Füllphase für den Reaktor_02 umzusetzen, indem nur die Bezeichnung der Zulaufventile so geändert wird, daß anstelle der Ventile 101 oder 102 die Ventile 201 oder 202 bezeichnet werden, und indem die Bezeichnung des Fluidpegelmessers so geändert wird, daß anstelle des Fluidpegelmessers 105 der Fluidpegelmesser 205 bezeichnet ist.
  • In bisher bekannten Systemen wäre eine generalisierte Steuerroutine geschaffen worden, um eine bestimmte Phase in jeder der Reaktor-Einheiten (Reaktor_01, Reaktor_02 oder Reaktor_03) unter Verwendung von Aliasnamen (das heißt allgemeinen Variablen) auszuführen, um bestimmte, noch nicht spezifizierte Parameter, wie z. B. die jeweilige Reaktor-Einheit oder die jeweiligen Ventile oder Sensoren einer Reaktor-Einheit, an welchen ein Befehl der Routine anzuwenden war, anzugeben. Auf diese Weise wäre eine generalisierte Steuerroutine (wie z. B. eine Füllroutine) geschaffen worden, die während der Füllphase jeder der Reaktor-Einheiten in 1 zu verwenden wäre, und anstatt daß bei der Erstellung der Steuerroutine ein bestimmtes Ventil festgelegt worden wäre, das zum Füllen eines bestimmten Reaktorgefäßes zu öffnen ist, wurde die generalisierte Steuerroutine so geschrieben, daß nur ein ”Zulauf_Ventil” als ein Alias für das tatsächlich zu verwendende Ventil angegeben war. Für diese Systeme wäre eine Alias-Auflösungstabelle für jede der Reaktor-Einheiten erstellt worden, an welchen die generalisierte Steuerroutine anzuwenden war. Die Alias-Auflösungstabelle für den Reaktor_01 könnte beispielsweise festlegen, daß das Alias ”Zulauf_Ventil” das Ventil 101 ist, während die Alias-Auflösungstabelle für den Reaktor_02 festlegen könnte, daß das Alias ”Zulauf_Ventil” das Ventil 201 ist, etc..
  • Wie vorstehend angegeben wurde bei einem System nach dem Stand der Technik das generalisierte Programm, das diese Aliasnamen verwendete, in einer Workstation erstellt und eine diesbezüglich konkretisierte Version dieses Programms wurde für jede Reaktor-Einheit (oder jedes andere Modul) unter Verwendung einer Alias-Auflösungstabelle für die bestimmte Reaktor-Einheit (oder das andere Modul) erstellt. Diese instantiierten Steuerroutinen wurden anschließend in die Steuereinrichtung heruntergeladen und darin gespeichert und anschließend während der Laufzeit verwendet, um die Phase in der bestimmten Einheit auszuführen, was großen Speicherplatz in der Steuereinrichtung erforderte. Bei einem anderen System nach dem Stand der Technik wurde die generalisierte Steuerroutine in der Steuereinrichtung gespeichert und während der Laufzeit verwendet, um den programmierten Betriebsablauf oder die Phase an einer der Einheiten, an der sie angewendet wurden, durchzuführen. In diesem Fall wurden die Aliasnamen fliegend während der Laufzeit unter Verwendung der Alias-Auflösungstabelle für die bestimmte Einheit, die gesteuert wurde, aufgelöst. Bei dieser Konfiguration mußte dann, wenn an einer generalisierten Steuerroutine, die gegenwärtig von der Steuereinrichtung abgearbeitet wurde, eine Veränderung vorzunehmen war, der Lauf dieser Routine unterbrochen werden, um es zu ermöglichen, eine neue generalisierte Steuerroutine in die Steuereinrichtung herunterzuladen.
  • Ferner erlaubte es keines dieser bekannten Systeme, daß eine einzige generische Prozeßsteuerroutine mit Aliasnamen an mehreren oder an unterschiedlichen Arten von Einheiten oder Hardwaresystemen angewandt wurde. Tatsächlich war bei diesen Systemen nach dem Stand der Technik eine Steuerroutine für eine Phase auf die Verwendung mit einer Einheitenklasse, das heißt einer bestimmten Art von Hardwareeinheit zur Durchführung einer Art von Funktion innerhalb des Prozeßsteuernetzes beschränkt. Als Folge mußte eine erste generische Prozeßsteuerroutine geschaffen und gespeichert werden, um Reaktor-Einheiten zu füllen, während eine unterschiedliche generische Prozeßsteuerroutine geschaffen und gespeichert werden mußte, um Mischtanks zu füllen und wiederum eine unterschiedliche Routine zum Füllen von Zulauftanks, was zu der Erstellung von vielen verschiedenen generischen Steuerroutinen zur Durchführung von im wesentlichen derselben Funktion an unterschiedlichen Arten von Hardwareinheiten führte.
  • Ferner setzte wie vorstehend angegeben keines dieser Systeme nach dem Stand der Technik die generische Steuerroutine in die Lage, kleinere Unterschiede zwischen den Geräten, die zu den unterschiedlichen Modulen einer bestimmten Art von Einheit oder Einheitenklassen gehörten, zu berücksichtigten. Im Gegenteil mußte eine unterschiedliche Phasenroutine geschrieben und an unterschiedlichen Modulen derselben Einheitenklasse verwendet werden, wenn diese unterschiedlichen Einheiten eine geringfügig verschiedene Hardware aufwiesen, wie z. B. eine elektrische Heizung in einem Fall oder eine Dampfheizung in einem anderen Fall. Dies machte es wiederum erforderlich, daß der Programmierer einen unterschiedlichen Prozeßsteueralgorithmus oder eine unterschiedliche Phasenklasse für unterschiedlichen Einheiten derselben Einheitenklasse verwendete, obgleich diese unterschiedlichen Einheiten im wesentlichen dieselbe Funktion innerhalb des Prozesses ausführten. Ferner hatten diese Systeme nach dem Stand der Technik kein einfaches Verfahren zum Spezifizieren eines Parameters, der während der Laufzeit der Prozeßsteuerroutine zu identifizieren war, und wenn eine derartige dynamische Referenz zulässig war, gab es keinen Weg, festzustellen, ob die dynamische Referenz einen gültigen Wert hatte, bevor versucht wurde, einen Befehl auf der Basis dieser Referenz auszuführen.
  • Die Vorgehensweise oder das System, das indirekte Referenzierung in Prozeßsteuerprogrammen oder -routinen wie hierin beschrieben verwendet, spricht einige der Probleme bei den vorstehend beschriebenen Systemen nach dem Stand der Technik an. Das hierin beschriebene System ermöglicht es, daß eine generische Prozeßsteuerroutine oder Phasensteuerroutine unter Verwendung von Aliasnamen geschrieben wird, daß diese jedoch weiterhin in der Steuereinrichtung unter Verwendung von kleinstem Speicherplatz gespeichert wird und in einer Weise ausgeführt wird, die es ermöglicht, daß die generische Phasensteuerroutine verändert wird, ohne daß veranlaßt wird, daß eine der gegenwärtig ablaufenden Routinen abgebrochen wird. Das hierin beschriebene System ermöglicht es ferner, daß eine Phasensteuerroutine für mehrere verschiedene Einheitenklassen oder unterschiedliche Hardwaretypen geschaffen und an diesen angewandt wird und verwendet eine Phasensteuerroutine, welche verifizierbare und leicht anwendbare dynamische Referenzen, das heißt Referenzen, die während der Laufzeit der Phasensteuerroutine eingebunden werden, enthalten kann.
  • Allgemein gesprochen basiert die Art, in der der Ablauf des Prozesses 16 in der Steuereinrichtung 12 verwaltet oder organisiert wird, auf der Wechselwirkung einer Anzahl von Objekten, von welchen jedes Attribute hat und zu dem eine oder mehrere Methoden gehören können. Jedes Objekt kann eine Anzahl von Subobjekten (oder Klassen) haben, die zu diesem gehören, wobei jedes Subobjekt Subobjekte haben kann und so fort. In einem generischen Sinn ist die Gesamtsteuerstrategie für den Prozeß 16 unter Verwendung eines objektorientierten Programmierparadigmas konfiguriert, was nach dem Stand der Technik bekannt ist und somit hier nicht im Detail beschrieben wird. 2 beschreibt ein Beispiel einer Objekthierarchie, welche die Beziehung zwischen einer Anzahl von Objekten darstellt, die zu dem Prozeßsteuernetz 10 in 1 gehören. Diese Hierarchie wird verwendet, um die Art zu erläutern, in der die Prozeßsteuerroutine auf beispielsweise einer der Workstations 14 erstellt wird und anschließend innerhalb der Steuereinrichtung 12 heruntergeladen und ausgeführt wird, und um den Kontext zu identifizieren, in dem diese Prozeßsteuerroutine arbeitet. Es versteht sich jedoch, daß die Art, in der die Prozeßsteuerroutinen erstellt und in der Steuereinrichtung 12 gespeichert werden, auf anderen Objekthierarchien basieren kann oder auf Objekthierarchien, die andere gewünschte Elemente oder Objekte enthalten.
  • In dem Objektbaum in 2 sind bestimmte Objekte mit Rahmen dargestellt, während allgemeine Kategorien von Objekten (oder Objekttypen) über den Objekten in dem Baum ohne Rahmen dargestellt sind. Wie 2 zeigt, enthält das Prozeßsteuernetz 10 ein oder mehrere Gebiete, die beispielsweise Gebäude oder andere geographische Bereichsbezeichnungen innerhalb einer Anlage sein können. In dem Objektbaum in 2 hat der Prozeß 16 drei Bereichsobjekte, die als Gebäude_01, Gebäude_02 und Gebäude_03 bezeichnet sind. Jedes Bereichsobjekt kann in Prozeßzellen eingeteilt sein, von welchen jede einen unterschiedlichen Aspekt des Prozesses kennzeichnet, der in dem Bereich durchgeführt wird. Das Bereichsobjekt Gebäude_01 in 2 ist so dargestellt, daß es zwei Prozeßzellenobjekte enthält, die mit Zelle_01 und Zelle_02 bezeichnet sind. Zelle_01 kann beispielsweise mit der Herstellung eines Bestandteils eines Produkts in Beziehung stehen, der in Zelle_02 verwendet wird. Jedes Zellenobjekt kann Null oder mehr Einheitenklassen enthalten, welche unterschiedliche Kategorien oder Gruppierungen von Hardware kennzeichnen, die in der Prozeßzelle verwendet werden. Allgemein ausgedrückt ist eine Einheitenklasse ein benanntes Objekt, das eine allgemeine Konfiguration einer Garnitur von parallel vorhandenen Geräten enthält, und ist insbesondere eine Sammlung von Einheiten, die eine sehr ähnliche, wenn nicht gar identische Prozeßinstrumentierung haben, von welchen jede eine sehr ähnliche, wenn nicht gar identische Funktion innerhalb eines Prozesses ausführt. Einheitenklassenobjekte sind typischerweise so benannt, daß sie die Arten von Einheiten innerhalb des Prozeßsteuersystems beschreiben, zu dem sie gehören. 2 enthält eine Misch_Tank-Einheitenklasse, eine Reaktor-Einheitenklasse und eine Zuliefer_Tank-Einheitenklasse. Selbstverständlich sind in den meisten Prozeßsteuernetzen viele andere Typen von Einheitenklassen vorgesehen oder definiert, wie beispielsweise Trocknereinheiten, Gießtrichtereinheiten und andere einzelne oder logische Gruppierungen von Hardware enthalten.
  • Wie bei der Reaktor-Einheitenklasse in 2 dargestellt, kann jedes Einheitenklassenobjekt Einheitenmodulobjekte und Phasenklassenobjekte haben, die zu diesem gehören. Einheitenmodulobjekte bezeichnen allgemein bestimmte Instanzen von parallel vorhandener Hardware innerhalb der benannten Einheitenklasse, während Phasenklassen allgemein die Phasen festlegen, die an den Einheitenmodulen angewandt werden können, die zu der Einheitenklasse gehören. Genauer ausgedrückt ist ein Einheitenmodulobjekt ein benanntes Objekt, das alle Variablen und Einheitenphasen (weiter unten definiert) für eine einzelne Prozeßeinheit enthält, und ist typischerweise so benannt, daß eine bestimmte Prozeßausrüstung bezeichnet ist. Beispielsweise hat die Reaktor-Einheitenklasse in 2 Reaktor_01-, Reaktor_02- und Reaktor_03-Einheitenmodule, die Reaktor_01, Reaktor_02 und Reaktor_03, welche in 1 dargestellt sind, jeweils entsprechen. Die Misch_Tank-Einheitenklasse und die Zuliefer_Tank-Einheitenklasse haben in ähnlicher Weise bestimmte Einheitenmodule, die der jeweiligen Hardware oder der jeweiligen Ausrüstung in dem Prozeß 16 entsprechen. Der Einfachheit halber ist jedoch keine Ausrüstung, die zu der Misch_Tank- oder der Zuliefer_Tank-Einheitenklasse gehört, in 1 dargestellt.
  • Eine Phasenklasse ist ein benanntes Objekt, das die allgemeine Konfiguration für eine Phase enthält, die auf den mehreren Einheiten ablaufen kann, die zu derselben Einheitenklasse gehören, und gemäß vorliegender Erfindung auf mehreren unterschiedlichen Einheitenklassen. Im wesentlichen ist jede Phasenklasse eine unterschiedliche Steuerroutine (oder Phase), die durch die Steuereinrichtung 12 erstellt und verwendet wird, um die Einheitenmodule innerhalb derselben oder innerhalb von verschiedenen Einheitenklassen zu steuern. Typischerweise ist jede Phasenklasse in Übereinstimmung mit dem Verb benannt, das eine Aktion beschreibt, die an einem Einheitenmodul ausgeführt wird. Beispielsweise hat, wie in 2 dargestellt, die Reaktor-Einheitenklasse eine Füllphasenklasse, die verwendet wird, um eines der Reaktorgefäße 100, 200 oder 300 in 1 zu füllen, eine Heizphasenklasse, die verwendet wird, um eines der Reaktorgefäße 100, 200 oder 300 aus 1 aufzuheizen, eine Entleerungsphasenklasse, die verwendet wird, um eines der Reaktorgefäße 100, 200 oder 300 in 1 zu entleeren, und eine Reinigungsphasenklasse, die verwendet wird, um eines der Reaktorgefäße 100, 200 oder 300 aus 1 zu reinigen. Selbstverständlich können beliebige andere Phasenklassen zu dieser oder jeder anderen Einheitenklasse gehören. Es sei angemerkt, daß die Füllphasenklasse sowohl zu der Reaktor-Einheitenklasse als auch der Zuliefer_Tank-Einheitenklasse gehört und so gemäß vorliegender Erfindung verwendet werden kann, um die Füllfunktion an den Reaktor-Einheitenmodulen sowie den Zuliefer_Tank-Einheitenmodulen zu vollziehen.
  • Eine Phasenklasse kann allgemein als eine Subroutine betrachtet werden, die durch die Stapelausführungsroutine aufzurufen ist, um eine in einem Gesamtstapelprozeß erforderliche Funktion gemäß der Definition durch das Rezept für den Stapelprozeß auszuführen. Eine Phasenklasse kann Null oder mehr Phaseneingabeparameter enthalten, welche im wesentlichen die Eingaben sind, die von der Stapelausführungsroutine oder einer anderen Phasenklasse an die Phasenklassen-Subroutine abgegeben werden, Null oder mehr Phasenausgabeparameter, welche im wesentlichen die Ausgaben der Phasenklassen-Subroutine sind, die zu der Stapelausführungsroutine oder eine anderen Phasenklasse zurückgeleitet werden, Null oder mehr Phasenmitteilungen, welche Mitteilungen sein können, die dem Benutzer bezüglich des Betriebsablaufes der Phasenklasse angezeigt werden können, Informationen in Bezug auf andere Phasenklassen, mit welchen diese Phasenklasse in irgendeiner Weise zusammengehört, und Null oder mehr Phasenalgorithmusparameter, welche veranlassen, daß in Phasenlogikmodulen (PLM) oder Einheitenphasen basierend auf dieser Phasenklasse Parameter geschaffen werden. Diese Phasenalgorithmusparameter werden als zeitweilige Speicherorte oder Variable während der Ausführung der Phase verwendet und sind nicht notwendigerweise für den Benutzer oder die Stapelausführungsroutine sichtbar. Wichtig ist, daß die Phasenklasse eine oder mehrere Phasenalgorithmusdefinitionen (PAD) enthält, welche allgemein ausgedrückt Steuerroutinen sind, die zum Implementieren der Phase verwendet werden. Ferner hat die Phasenklasse eine Liste von Zuordnungen zu Null, einer, zwei oder mehr Einheitenklassen und diese Liste definierte die Einheitenklasse, für welche diese Phasenklasse und folglich die PAD der Phasenklasse angewandt werden kann. Die Füllphasenklassenliste von Zuordnungen würde sowohl die Reaktor-Einheitenklasse als auch die Zuliefer_Tank-Einheitenklasse enthalten.
  • Die PAD ist ein unbenanntes Objekt, das die abstrakte oder generische Phasenlogik (Algorithmus) für eine Phasenklasse enthält und unter Verwendung jeder gewünschten Art von Programmierstruktur konfiguriert sein kann, wie z. B. einer impliziten Phasenlogik-Statusmaschine, sequentieller Flußdiagramm-Komposite (SFC), Funktionsblock-Komposite oder jeder anderen gewünschten Steuerprogrammierlogik, die durch die Steuereinrichtung 12 verwendet werden kann, um den Betriebsablauf des Prozesses 16 zu steuern. In einer Ausführungsform werden PADs unter Verwendung von SFC-Programmiertechniken definiert, in welchen eine Anzahl von Schritten zusammengebunden werden und die Aktionen innerhalb eines Schrittes ausgeführt werden, bis ein Übergangszustand wahr wird, und an diesem Punkt bewegt sich die Steuerung zu dem nächsten Schritt, der durchgeführt wird, bis der nächste Übergangszustand wahr wird, und so fort. Das SFC-Programmierprotokoll basiert auf den Normen IEC 848 und IEC 1131-3 für Programmiersprachen und ist nach dem Stand der Technik bekannt. Die PADs können jedoch jede andere gewünschte Art von Programmierstruktur verwenden, um den Betriebsablauf einer Phase zu definieren. Allgemein gesprochen schafft die PAD die grundsätzliche oder generische Steuerroutine, die von der Steuereinrichtung 12 während des Betriebsablaufes eines Stapelprozesses auszuführen ist.
  • Um es zu erlauben, daß eine generische PAD auf eine beliebige Anzahl von unterschiedlichen Einheitenmodulen innerhalb einer Einheitenklasse angewandt wird, wird die PAD so konfiguriert (unter Verwendung einer Konfigurationsanwendung in der Workstation 14 durch den Benutzer), daß sie jedes externe Modul oder I/O referenziert, das von Einheitenmodul zu Einheitenmodul unterschiedlich ist, sowie jede andere gewünschte Variable oder jeden anderen gewünschten Parameter, und zwar unter Verwendung eines Aliasnamen, das heißt eines generischen oder noch nicht spezifizierten Namens, der noch nicht mit einer bestimmten Hardware oder einem bestimmten Hardwareelement verbunden ist. Als Resultat ist die PAD in dem Sinn generisch, daß die PAD auf mehrere Einheitenmodule und auch in mehreren Einheitenklassen angewandt oder verwendet werden kann.
  • Jede der Phasenklassen von 2 enthält ein PAD-Objekt, mit der Ausnahme der Heizphase, die zwei PAD-Objekte enthält, welche es ermöglichen, daß dieselbe Phasenklasse auf Steuereinheiten (wie z. B. Reaktor-Einheiten) angewandt und von diesen verwendet wird, die geringfügig unterschiedliche Arten von Hardware oder Ausrüstung aufweisen, wie nachfolgend. im Detail beschrieben wird.
  • Wie anhand der Einheitenmodule in 2 gezeigt ist, enthält jedes Einheitenmodulobjekt Null oder mehr Einheitenkennzeichen (UT) oder Parameter, die Ausgangswerte haben. Diese Parameter können Einstellungen und Konfigurationsparametern der Geräte, die zu dem Einheitenmodul gehören, entsprechen. Ferner kann jedes Einheitenmodulobjekt Alarmsignale, Ressourcenidentifikationen, eine Kontrollanzeige (wie z. B. Mensch-Maschine-Schnittstellenbild), eine Liste der Ressourcen, die dieses Einheitenmodul benötigt, und Prozeßzelleninformationen aufweisen, die diesem zugeordnet sind. Dabei ist wichtig, daß jedes Moduleinheitenobjekt eine Alias-Auflösungstabelle (ART), Null oder mehr Einheitenphasenobjekte (UP) und eine Einheitenphasentabelle (UPT) aufweist, die zu diesem gehören. Die Alias-Auflösungstabelle ist ein unbenanntes Objekt, das eine Liste von Aliasnamen/Instanzendefinitionspaaren für das Einheitenmodul, zu welcher sie gehört, enthält. Die Liste der Aliasnamen in der Tabelle basiert auf den gültigen Aliasnamen, die für jede Einheitenklasse definiert sind, welche wiederum alle Aliasnamen einschließt, die in allen Phasenklassen verwendet werden, die zu der Einheitenklasse dieses Einheitenmoduls gehören. Mit anderen Worten enthält die Alias-Auflösungstabelle eines Einheitenmoduls eine Aliasdefinition für jedes Alias, das in jeder Phasenklasse verwendet wird, die an diesem Einheitenmodul implementiert werden kann. Der Benutzer konfiguriert die Instanzendefinition für Aliasnamen, die an jeder Einheit zur Zeit der Konfiguration basierend auf den Aliasnamen, die in den Phasenklassen verwendet werden, die zu der Einheitenklasse gehören, definiert werden sollten.
  • In einigen Instanzen ist es wünschenswert, einen speziellen Wert für eine Aliasinstanzendefinition zu schaffen, der bedeutet, einen bestimmten Aliasnamen zu IGNORIEREN. Der Effekt dieser Definition soll besagen, daß an diesem Einheitenmodul eine Phasenlogik, die diesen Aliasnamen verwendet, für das Herunterladen in die Steuereinrichtung 12 zugelassen werden sollte, obgleich dieses Einheitenmodul diesen Aliasnamen nicht braucht oder unterstützt. Die Ausführung während der Laufzeit verursacht, daß Schreibversuche in einen Parameter mit Alias der Phasenlogik, der mit einem Parameterpfadstring mit Alias spezifiziert wird und eine Aliasinstanzendefinition IGNORIEREN hat, unterdrückt werden, veranlaßt, daß Leseversuche aus einem Parameter mit Alias, der mit IGNORIEREN definiert ist, unterdrückt werden, oder sendet einen Nullwert oder einen anderen voreingestellten Wert zurück und verursacht möglicherweise, daß ein Alarm ausgelöst wird, um einen Benutzer in Kenntnis zu setzen, daß ein Problem vorliegt. Falls erwünscht, kann die IGNORIEREN-Definition als ein Attribut der Aliasdefinition gespeichert werden und kann während der Laufzeit unter Verwendung beispielsweise einer IF...THEN-Logik getestet werden.
  • Jedes Einheitenphasenobjekt ist ein bekanntes Objekt, das eine Instanz einer Phasenklasse darstellt, die zu einem bestimmten Einheitenmodul gehört oder für ein solches geschaffen wurde. In dem Konfigurationssystem (das heißt in einer der Workstations 14) stellt das Einheitenphasenobjekt eine Komponente eines Einheitenmoduls dar, die unabhängig geändert und heruntergeladen werden kann. In dem Laufzeitsystem (das heißt in der Steuereinrichtung 12) stellt das Einheitenphasenobjekt eine Phasenlogik dar, die durch die Steuereinrichtung 12 an einem Einheitenmodul unabhängig betrieben (gestartet, gestoppt, gehalten, unterbrochen, etc.) werden kann; möglicherweise parallel mit anderen Einheitenphasen, die gleichzeitig auf unterschiedlichen Einheitenmodulen aktiv sind. Im wesentlichen ist das Einheitenphasenobjekt die diesbezüglich konkretisierte Version einer der Phasenklassen, die unter Verwendung der Alias-Auflösungstabelle für das Einheitenmodul, zu welchem das Einheitenphasenobjekt gehört, aufgelöst wurde. Beispielsweise würde ein Einheitenphasenobjekt des Reaktors_02 in 1 unter Verwendung der generischen PAD für die Füllphasenklasse geschaffen, in welcher die Aliasnamen unter Verwendung der Alias-Auflösungstabelle für die Reaktor_02-Moduleinheit aufgelöst sind. Somit könnte das Alias Zulauf_Ventil in der PAD für die Füllphasenklasse als das Ventil 201 oder 202 in 1 in dem Fülleinheitenphasenobjekt für das Reaktor_02-Einheitenmodul definiert werden. Die Steuereinrichtung 12 führt tatsächlich das Einheitenphasenobjekt aus (das heißt die diesbezüglich konkretisierte Version der Phasenklasse während der Laufzeit) und beläßt die generische Version der Phasenklasse in dem Speicher 22.
  • Die Phasentabelle für ein Einheitenmodul ist ein unbenanntes Objekt, das Schlüsseleigenschaften für jede Einheitenphase enthält, die an dem Einheitenmodul verfügbar gemacht wird. Die Phasentabelle enthält eine Liste von Phasenklassennamen aller Phasenklassen, die zu der Einheitenklasse des Einheitenmoduls gehören. Für jede Phasenklasse sieht bzw. konfiguriert der Benutzer die Schlüsseleigenschaften, einschließlich des Einheitenphasennamens (String), einer Verifizierungsangabe, daß eine gültige Aliasinstanzendefinition in der Alias-Auflösungstabelle des Einheitenmoduls für jeden Aliasnamen vorhanden ist, der in der Phasenklasse verwendet wird, und daß jede andere obligatorische Phasenklassenverifizierungsprüfung bestanden wurde, sowie eine Download-Angabe, die den Programmgestalter oder Benutzer in die Lage versetzt, das Herunterladen der Einheitenphasenlogik für Phasenklassen zu unterdrücken. Beispielsweise würde eine Einheitenphase nicht heruntergeladen, wenn entweder die Verifizierungsangabe festlegt, daß die Verifizierung nicht vorgekommen ist, oder wenn die Download-Angabe durch den Benutzer auf NEIN gesetzt wurde. Die Phasentabelle kann ferner eine permanente (Ja/Nein) Identifizierung enthalten, die die Steuereinrichtung 12 benachrichtigt, wenn diese Einheitenphase als ”permanent” in dem Laufzeitsystem behandelt werden sollte. Wenn dies der Fall ist, wird die Einheitenphase stets instantiiert, so daß sie niemals aufgrund von Over-Commitment der Steuereinrichtungsspeicherressourcen nicht ablaufen kann. Andere Informationen können ebenfalls in der Einheitenphasentabelle vorgesehen sein, wie z. B. Eigenschaften, die von der Stapelausführungsroutine benötigt werden, Ressourcenidentifikationskennzeichen, benötigte Ressourcen, ein Ausführungsperioden-Teiler/Multiplikator für die Steuereinrichtung 12 und beliebige andere Eigenschaften, welche das Laufzeitverhalte einer Phase steuern würden.
  • 3 stellt eine detailliertere Version einiger der in 2 dargestellten Objekte dar und zeigt die Beziehungen zwischen diesen Objekten besser. Um die Prinzipien der vorliegenden Erfindung darzustellen, sind in 3 zwei Einheitenklassen dargestellt, nämlich eine Reaktor-Einheitenklasse 50 und eine Zuliefer_Tank-Einheitenklasse 52. Für die Reaktor-Einheitenklasse 50 ist ein Einheitenmodul 54 dargestellt, nämlich der Reaktor_01. Es können zwar auch andere vorhanden sein, die jedoch in 3 nicht dargestellt sind. Das Einheitenmodul 54 definiert einige der Reaktorparameter, die zu der Reaktor-Einheitenklasse gehören, nämlich daß die Kapazität des Reaktors_01 300 beträgt und daß der Reaktor_01 kein Rührwerk enthält. Entsprechend gehören zwei Phasenklassen zu der Reaktor-Einheitenklasse, darunter eine Füllphasenklasse 56 und eine Entleerungsphasenklasse 58. Die Füllphasenklasse 56 enthält eine PAD (als ein SFC in grafischer Form auf deren rechter Seite dargestellt), welche so gestaltet wurde, daß sie zwei Aliasnamen verwendet, nämlich #ZULAUF_VENTIL# UND #PEGEL#. Diese Aliasnamen werden tatsächlich in den in der PAD der Füllphasenklasse 56 dargestellten Rahmen verwendet, können jedoch alternativ irgendwo sonst innerhalb der Logik der PAD verwendet werden. Die Füllphasenklasse 56 enthält ferner eine Eingabe, die als SOLL_PEGEL definiert ist, und eine Ausgabe, die als END_PEGEL definiert ist. Während die Aliasnamen so angegeben sind, daß sie durch ein Nummernzeichen (#) begrenzt oder markiert sind, könnte jedes andere Identifizierungskennzeichen verwendet werden, um einen Aliasnamen zu definieren, der bei der Instantiierung einer Phase ersetzt werden muß. In ähnlicher Weise enthält die Entleerungsphasenklasse 58 eine PAD, die auf der rechten Seite derselben in grafischer Form dargestellt ist, welche die Aliasnamen #AUSLASS_VENTIL# und #PEGEL#, eine Eingabe, die als RATE definiert ist, eine Ausgabe, die als END_PEGEL definiert ist, und einen Algorithmusparameter (von der PAD verwendet) der als TATSÄCHLICHE_RATE definiert ist, hat, welche als eine vorübergehende Speicherposition während der Ausführung der PAD verwendet werden können.
  • Da die Füll- und Entleerungsphasenklassen 56 und 58 zu der Reaktor-Einheitenklasse 50 gehören, sollte das Reaktor_01-Einheitenmodul 54 (das ebenfalls zu der Reaktor-Einheitenklasse 50 gehört) so gestaltet sein, daß es die Aliasnamen unterstützt, die in den beiden Phasenklassen 56 und 58 verwendet werden, und zwar aus dem Grund, daß die Steuereinrichtung 12 versuchen kann, diesbezüglich konkretisierte Versionen der Phasenklassen 56 und 58 für das Reaktor_01-Einheitenmodul 54 während der Laufzeit zu schaffen. Als Resultat wird eine Alias-Auflösungstabelle 60 für das Reaktor_01-Einheitenmodul 54 geschaffen, um jeden der Aliasnamen #ZULAUF_VENTIL# (in der Füllphasenklasse 56 verwendet), #PEGEL# (sowohl in der Füllphasenklasse 56 als auch der Entleerungsphasenklasse 58 verwendet) und #AUSLASS_VENTIL# (in der Entleerungsphasenklasse 58 verwendet) zu definierten. Die Alias-Auflösungstabelle 60 enthält gültige Definitionen für #ZULAUF_VENTIL# und #PEGEL#-Aliase, enthält jedoch keine gültige Definition für das #AUSLASS_VENTIL#-Alias. Als Resultat bestimmt die von der Workstation 14 ausgeführte Konfigurationsroutine dann, wenn sie bestimmt, daß jede Phasenklasse innerhalb des Steuerschemas gültig definiert ist, daß ein Fülleinheitenphasenobjekt für das Reaktor_01-Einheitenmodul 54 geschaffen werden kann, da jeder der Füllphasenklassen-Aliasnamen in der Alias-Auflösungstabelle 60 für das Reaktor_01-Einheitenmodul 54 gültig definiert ist. Diese Konfigurationsroutine bestimmt jedoch, daß ein Entleerungseinheitenphasenobjekt für das Reaktor_01-Einheitenmodul 54 nicht geschaffen werden kann, da die Alias-Auflösungstabelle 60 keine gültige Definition für alle Aliasnamen aufweist, die von der Entleerungsphasenklasse 58 verwendet werden. Als Resultat zeigt eine Phasentabelle 62 für das Reaktor_01-Einheitenmodul 54 (welche durch die Konfigurationsanwendungen der Workstation 14 geschaffen wird) an, daß die Füllphase für das Reaktor_01-Einheitenmodul 54 aufgelöst ist und in die Steuereinheit 12 heruntergeladen werden kann, daß jedoch die Entleerungsphase für das Reaktor_01-Einheitenmodul 54 nicht aufgelöst ist und daher nicht in die Steuereinrichtung 12 heruntergeladen werden kann, und zwar bestimmt durch die ungültige Definition des #AUSLASS_VENTIL#-Alias in der Alias-Auflösungstabelle 60.
  • Es sei angemerkt, daß die in 3 gezeigte Füllphasenklasse 56 generisch ausreichend definiert ist, um auf eine zusätzliche Einheitenklasse anwendbar zu sein, nämlich die Zuliefer_Tank-Einheitenklasse 52, die in 3 so dargestellt ist, daß zu ihr ein Zuliefertank_06-Einheitenmodul 64 gehört. Als Resultat muß für die Füllphasenklasse, die zum Herunterladen in die Steuereinrichtung 12 definiert oder in ordnungsgemäßerweise unterstützt wird, das Zuliefertank_06-Einheitenmodul (sowie alle anderen Einheitenmodule der Zuliefer_Tank-Einheitenklasse 52) eine Alias-Auflösungstabelle haben, die eine Definition für die von der Füllphasenklasse 56 verwendeten Aliase gibt, nämlich #ZULAUF_VENTIL# und #PEGEL#. Wenn dies erfüllt ist, kann die Füllphasenklasse 56 verwendet werden, um Einheitenphasen für jedes Einheitenmodul entweder in der Reaktor-Einheitenklasse 50 oder der Zuliefer_Tank-Einheitenklasse 52 zu erzeugen.
  • Während der Konfiguration verwendet ein Systemgestalter, wie z. B. ein Techniker, ein Konfigurationsprogramm, das auf einer der Workstations 14 ausgeführt wird, um die Phasenklassen und Alias-Auflösungstabellen für jedes der Einheitenmodule innerhalb des Prozeßsteuernetzes 10 zu konfigurieren. Allgemein ausgedrückt definiert der Techniker die PADs für jede der Phasenklassen (wie z. B. die Füll-, Heiz-, Entleerungs- und Reinigungsphasenklasse in 2) unter Verwendung jeder gewünschten Programmiersprache oder -umgebung und unter Verwendung von Aliasnamen für bestimmte Variable oder Module, wie z. B. Einrichtungen, Modulparameter, Funktionsblöcke, etc., so daß die PADs verwendet oder angewandt werden können, um jedes der Einheitenmodule zu steuern, das zu einer Einheitenklasse gehört, zu welcher die Phasenklasse gehört. Die Konfigurationsanwendung kann den Techniker in die Lage versetzen, diese PADs in jeder gewünschten Weise zu importieren und kann den Techniker auffordern, jede erforderliche Information anzugeben, darunter beispielsweise eine Liste von Aliasnamen, die in den PADs für jede Phasenklasse verwendet werden.
  • Gemäß vorliegender Erfindung kann der Techniker mehrere PADs für jede bestimmte Phasenklasse definieren, um Unterschiede bei der Hardware oder den Geräten, die zu den unterschiedlichen Einheitenmodulen derselben (oder verschiedener) Einheitenklassen gehören, zu berücksichtigen. Somit kann der Techniker beim Erstellen der Heizphasenklasse für die Reaktor-Einheitenklasse eine erste PAD schaffen, welche ein Reaktorgefäß unter Verwendung einer elektrischen Heizausrüstung erwärmt, und eine zweite PAD, welche ein Reaktorgefäß unter Verwendung einer Dampfheizausrüstung erwärmt. Jeweils eine unterschiedliche dieser PADs wird verwendet, um das Einheitenphasenobjekt für unterschiedliche Einheitenmodule zu schaffen. Wenn beispielsweise das Reaktor_01-Einheitenmodul mit einer elektrischen Heizausrüstung versehen ist (beispielsweise die Einrichtung 105 in 1 ein elektrisches Heizelement ist) und der Reaktor_02 mit einer Dampfheizausrüstung versehen ist (beispielsweise die Einrichtung 205 in 1 ein Dampfheizelement ist), wird die erste PAD der Heizphasenklasse verwendet, um die Heizeinheitenphase für das Reaktor_01-Einheitenmodul zu erstellen, während die zweite PAD der Heizphasenklasse verwendet wird, um die Heizeinheitenphase für das Reaktor_02-Einheitenmodul zu schaffen. Um die Workstation 14 und die Steuereinrichtung 12 in die Lage zu versetzen, zu entscheiden, welche PAD einer Phasenklasse zu verwenden ist, wenn eine bestimmte Einheitenphasenklasse für eine Phasenklasse geschaffen wird, die mehrere PADs hat, enthält jedes Einheitenmodul, das eine Phasenklasse mit mehreren PADs unterstützt, eine Angabe, welche den Gerätetyp identifiziert, den dieses Einheitenmodul hinsichtlich der Unterscheidung zwischen den unterschiedlichen PADs hat. Dieses Kennzeichen kann in jeder gewünschten Weise gespeichert werden, so lang es für die Steuereinrichtung 12 verfügbar ist, wenn die Steuereinrichtung 12 eine Einheitenphase zur Ausführung erstellt. Beispielsweise hat das Reaktor_01-Einheitenmodul einen Identifizierungsparameter, der auf einen Wert gesetzt ist, der angibt, daß dieser Reaktor eine elektrische Heizung hat, während das Reaktor_02-Einheitenmodul denselben Identifikationsparameter hat, der auf einen Wert gesetzt ist, der angibt, daß dieser Reaktor eine Dampfheizung hat. Wenn die Steuereinrichtung 12 eine Einheitenphase für ein Einheitenmodul schafft, greift sie auf den Identifikationsparameter zu und verwendet basierend auf dem Wert des Identifikationsparameters die erste PAD (elektrische Heizung) oder die zweite PAD (Dampfheizung), wenn die Einheitenphase erstellt wird.
  • Anschließend erstellt der Techniker die Alias-Auflösungstabelle für jedes Einheitenmodul (wie z. B. die Alias-Auflösungstabelle 60 in 3) und sieht in jeder Alias-Auflösungstabelle eine Definition für jeden der Aliasnamen vor, die in jeder einzelnen Phasenklasse verwendet werden, die zu der Einheitenklasse gehören, zu welcher das Einheitenmodul gehört. Beispielsweise würde in der Objekthierarchie in 2 der Techniker eine Alias-Auflösungstabelle für jedes der Einheitenmodule Reaktor_01, Reaktor_02 und Reaktor_03 erstellen, die eine Definition für jeden der Aliasnamen enthält, die in der Füll-, Heiz, Entleerungs-, und Reinigungsphasenklasse verwendet werden. Da die Füllphasenklasse 56 auch zu der Zuliefer_Tank-Einheitenklasse 52 gehört, wie in 3 am besten zu erkennen ist, müßte der Techniker sicherstellen, daß die Alias-Auflösungstabelle für jedes Einheitenmodul, das zu der Zuliefer_Tank-Einheitenklasse gehört (wie z. B. das Zuliefer_Tank06-Einheitenmodul 64 in 3), Definitionen für jeden der Aliasnamen enthält, die in der Füllphasenklasse 56 sowie in jeder anderen Phasenklasse verwendet werden, die zu der Zuliefer_Tank-Einheitenklasse 52 gehört. Selbstverständlich können, wie vorstehend angemerkt, einige der Aliasnamen mit dem IGNORIEREN-Wert in einigen der Alias-Auflösungstabellen der Einheitenmodule definiert sein, da sie für den Betriebsablauf dieses bestimmten Einheitenmoduls irrelevant sind.
  • Vorzugsweise enthält die Konfigurationsanwendung in der Workstation 14 eine Aliasdefinitionsprüfroutine, die automatisch prüft, ob jeder Aliasname für jede Phasenklasse von der Alias-Auflösungstabelle für jedes Einheitenmodul unterstützt wird, das zu der Einheitenklasse gehört, zu welcher die Phasenklasse gehört. In einer Ausführungsform ergibt jede Einheitenklasse eine Liste von Aliasnamen, das jeden Aliasnamen enthält, der in jeder Phasenklasse verwendet wird, die zu dieser Einheitenklasse gehört. Die Prüfroutine kann anschließend bestimmen, ob eine gültige Aliasdefinition für jeden dieser Aliasnamen in jeder Alias-Auflösungstabelle existiert, die zu dieser Einheitenklasse gehört. Da mehrere Einheitenklassen eine Phasenklasse teilen können (wie für die Füllphasenklasse in 2 und 3 dargestellt), können dieselben Aliasnamen in unterschiedlichen Einheitenklassen verwendet werden, was es erfordert, daß Aliasnamen innerhalb des Systems global einzigartig sind. In einer weiteren Ausführungsform kann die Prüfroutine die Aliasnamen für eine bestimmte Phasenklasse bestimmen, die Einheitenklassen bestimmen, zu welchen die Phasenklasse gehört, und zwar basierend auf dem Einheitenklassenkennzeichen der Phasenklasse, und die Alias-Auflösungstabelle für jedes Einheitenmodul prüfen, das zu den identifizierten Einheitenklassen gehört, um zu bestimmen, ob diese Alias-Auflösungstabellen eine gültige Definition für jeden der Aliasnamen der Phasenklasse enthalten. Die Routine kann anschließend zu der nächsten Phasenklasse weitergehen und den Vorgang wiederholen, bis alle Phasenklassen geprüft wurden. Während dieses Prozesses kann die Prüfroutine die Phasentabelle für jedes Einheitenmodul ausfüllen und in der Phasentabelle angeben, ob jede Phase auflösbar, ist, und zwar basierend auf der Alias-Auflösungstabelle für dieses Einheitenmodul, und ob diese Phase, das heißt Phasenklasse, in die Steuereinrichtung 12 zur Verwendung beim Ablaufbetrieb heruntergeladen werden kann. Die Prüfroutine kann ferner bestimmen, ob eine Definition für jeden Aliasnamen in einer bestimmten Alias-Auflösungstabelle vorhanden ist und ob die angegebene Definition eine gültige ist, das heißt eine gültige Position oder Einrichtung innerhalb des Prozeßsteuersystems angibt. Diese Überprüfung wird erreicht, indem eine Konfigurationsdatenbank innerhalb der Workstation 14 verwendet wird, welche so eingerichtet wird, daß sie die Systemhardwarekonfiguration und die von der Steuereinrichtung 12 während der Laufzeit verwendete Datenbank spiegelt. Die Verwendung dieser Prüfroutine hilft dabei, es zu ermöglichen, daß eine Phasenklasse durch mehrere Einheitenklassen unterstützt wird.
  • Die Phasentabellen können von dem Techniker verwendet werden, um zu bestimmen, welche Phasenklassen nicht von jedem einzelnen Einheitenmodul unterstützt werden, an welchen die Phasenklassen während der Laufzeit angewandt werden können. Wenn eine Phasenklasse auch nur von einem Einheitenmodul nicht unterstützt wird (bedingt durch eine ungültige oder fehlende Aliasdefinition in der Alias-Auflösungstabelle für dieses Einheitenmodul), verhindert die Konfigurationsroutine vorzugsweise, daß diese Phasenklasse in die Steuereinrichtung 12 heruntergeladen wird, um zu verhindern, daß die Steuereinrichtung 12 versucht, basierend der Phasenklasse eine ausführbare Routine zu schaffen, welche aufgrund der nicht auflösbaren Aliasdefinition unterbrochen oder angehalten werden kann. Ferner kann die Konfigurationsroutine das Herunterladen einer Phasenklasse basierend auf der Einstellung der Herunterladeparameter innerhalb der Phasentabelle verhindern.
  • Wenn alle Phasenklassen und Alias-Auflösungstabellen ordnungsgemäß konfiguriert sind, werden sie in die Steuereinrichtung 12 heruntergeladen, um den Ablaufbetrieb basierend auf diesen Objekten zu erlauben. Allgemein ausgedrückt speichert die Steuereinrichtung 12 die Alias-Auflösungstabellen und die Phasenklassen, die die Aliasnamen enthalten, in den Speicher 22. Die Phasenklassen und die Alias-Auflösungstabellen können jedoch in dem Speicher 20 einer der Workstations 14 oder in jedem anderen Speicher gespeichert werden, wenn dies erwünscht ist. In jedem Fall schafft die Steuereinrichtung 12 keine ausführbare Einheitenphasenroutine, bevor eine derartige Routine tatsächlich benötigt wird oder von der Stapelausführungsroutine aufgerufen wird (welche in einer Workstation 14 oder der Steuereinrichtung 12 gespeichert sein kann und auf diesen ablaufen kann). Wenn die Stapelausführungsroutine einen Stapelablauf implementiert, schafft sie zunächst eine Instantiierung jeder Phasenklasse für jedes der einzelnen Einheitenmodule, auf welchen der Stapelprozeß ablaufen soll. Die Steuereinrichtung 12 (oder ein Programm in dieser) greift auf die Phasenklassen, die zu verwenden sind, zu und greift auf die Alias-Auflösungstabelle für das Einheitenmodul zu, auf welchem die Phase, die zu der Phasenklasse gehört, ablaufen soll. Unter Verwendung der Alias-Auflösungstabelle und der PAD für die Phasenklasse erstellt die Steuereinrichtung 12 eine ausführbare Einheitenphase, wobei die Aliasnamen in der PAD aufgelöst werden oder durch die Definition für diese Namen innerhalb der Alias-Auflösungstabelle ersetzt werden. Wenn die Phasenklasse mehr als eine PAD hat, verwendet die Steuereinrichtung 12 die PAD-Identifizierungsparameter des Einheitenmoduls, um zu bestimmen, welche PAD zu verwenden ist, um die Einheitenphase zu schaffen. Anschließend führt die Steuereinrichtung 12 die Einheitenphase entsprechend der Anweisung von der Stapelausführungsroutine durch (das heißt die diesbezüglich konkretisierte Version der Phasenklasse).
  • Weil die Steuereinrichtung 12 die Phasenklasse, welche die Aliasnamen enthält, in ihrem Speicher 22 speichert, muß die Steuereinrichtung 12 keine diesbezüglich konkretisierte ausführbare Version jeder Phasenklasse für jedes Einheitenmodul (das heißt alle Einheitenphasen) zu jeder Zeit haben, was die Speichererfordernisse der Steuereinrichtung 12 verringert. Tatsächlich muß gemäß vorliegender Erfindung die Steuereinrichtung 12 nur ausreichend Speicher verwenden, um jede der Phasenklassen und jede der instantiierten Einheitenphasen zu speichern, die gegenwärtig ablaufen. Nach der Ausführung einer Einheitenphase kann die Steuereinrichtung 12 die Einheitenphase entfernen, da die Steuereinrichtung 12 eine neue Einheitenphase für ein Einheitenmodul aus der gespeicherten Phasenklasse und der gespeicherten Alias-Auflösungstabelle für dieses Einheitenmodul erstellen kann. Selbstverständlich wird dann, wenn eine Einheitenphase für den Betriebsablauf der Steuereinrichtung 12 permanent instantiiert werden soll, wie von dem Benutzer in der Phasentabelle definiert, die Einheitenphase nicht entfernt, sondern in dem Steuereinrichtungsspeicher 22 gehalten, um sicherzustellen, daß für diese Einheitenphase stets Speicher verfügbar ist. In jedem Fall reduziert das Speichern der generischen, mit Alias versehenen Steuerroutinen (Phasenklassen), bis sie tatsächlich gebraucht werden, und das anschließende Erstellen einer ausführbaren Steuerroutine unter Verwendung der Alias-Auflösungstabelle die erforderliche Speichermenge gegenüber den Systemen nach dem Stand der Technik, bei welchen es erforderlich ist, daß eine Steuereinrichtung ein separates ausführbares Programm für jede Phasenklasse für jedes Einheitenmodul zu jeder Zeit speichert. Da jedoch eine separate ausführbare Steuerroutine (Einheitenphase) vor der Laufzeit geschaffen wird, erkennt die Steuereinrichtung 12, daß ein Auflösungsproblem zwischen der generischen Steuerroutine und der Alias-Auflösungstabelle vorliegt, bevor sie mit der Ausführung eines Stapelablaufs beginnt, was verhindert, daß der Stapelablauf begonnen wird und anschließend während seines Betriebes unterbrochen wird, bedingt durch einen nicht auflösbaren Aliasnamen, was bei dem System nach dem Stand der Technik ein Problem war, bei welchem eine generische Steuerroutine gespeichert und ausgeführt wurde, in welcher Aliasnamen fliegend während der Laufzeit aufgelöst wurden.
  • Da ferner eine ausführbare Einheitenphase vor der Laufzeit geschaffen wird und da diese Einheitenphase von der Steuereinrichtung 12 während der Laufzeit verwendet wird, ist die generische Phasenklasse stets verfügbar und somit kann diese Phasenklasse verwendet werden, um andere Einheitenphasen zu schaffen, während eine daraus geschaffene Einheitenphase abläuft. Entsprechend kann die generische Phasenklasse erweitert oder verändert werden, während eine aus dieser Phasenklasse entwickelte Einheitenphase abläuft, was bedeutet, daß der Benutzer eine neue Phasenklasse herunterladen kann, ohne daß gegenwärtig in Ausführung befindliche Routinen, die aus der früheren Phasenklasse entwickelt wurden, unterbrochen werden müssen. Dies ist vorteilhaft, da es die Erweiterung der Steuereinrichtung 12 ohne Unterbrechung des gegenwärtig ablaufenden Prozesses erlaubt.
  • Da darüber hinaus eine Phasenklasse mit mehr als einer Einheitenklasse verbunden sein kann, kann eine einzelne Phasenklasse gespeichert werden und für mehrere unterschiedliche Typen von Einheiten oder Hardware verwendet werden, was die Anzahl der innerhalb des Steuersystems erforderlichen Objekte weiter reduziert und die Speichererfordernisse der Steuereinrichtung 12 verringert. Da ferner eine Phasenklasse mehrere PADs haben kann, welche mit unterschiedlichen Geräten innerhalb derselben (oder verschiedenen) Einheitenklassen verwendet werden können, muß der Benutzer die Stapelausführungsroutine nicht so programmieren, daß die kleineren Unterschiede der Hardware berücksichtigt werden. Anstelle dessen berücksichtigt die Phasenklasse diese Unterschiede und somit kann die Stapelausführungsroutine dieselbe Phasenklasse verwenden oder aufrufen, um dieselbe Funktion an unterschiedlichen Einheitenmodulen durchzuführen, wenngleich auch die unterschiedlichen Einheitenmodule mit geringfügig unterschiedlicher Hardware ausgerüstet sind.
  • Die von dem Techniker entwickelten Prozeßsteuerroutinen können ferner bestimmte Parameter oder Variable enthalten, deren Wert angegeben werden kann, nachdem die diesbezüglich konkretisierte Prozeßsteuerroutine (das heißt die Einheitenphase) innerhalb der Steuereinrichtung 12 geschaffen wurde. Diese dynamisch gebundenen oder dynamisch aufgelösten Parameter sind nützlich, wenn beispielsweise einem Benutzer oder für die Stapelausführungsroutine innerhalb einer Phase eines Stapelablaufs auf einem bestimmten Einheitenmodul verschiedene Möglichkeiten zur Auswahl stehen. Beispielsweise kann eine Stapelausführungsroutine in Abhängigkeit von dem verwendeten Rezept entscheiden müssen, ob das Ventil 201 oder das Ventil 202 in dem Reaktor_02 in 1 geöffnet werden. Wenn beispielsweise der Stapelablauf die Herstellung eines mit Kohlensäure versetzten Getränks, wie z. B. Bier, betrifft, kann das Rezept die Herstellung von normalem Bier betreffen, in welchem Fall das Ventil 201 des Reaktors_02 während der Füllphase des Stapelprozesses geöffnet werden muß, oder das Rezept kann die Herstellung von Leichtbier betreffen, in welchem Fall das Ventil 202 des Reaktors_02 während der Füllphase des Stapelprozesses geöffnet werden muß. Anstatt daß zwei unterschiedliche Phasenklassen für diese unterschiedlichen Füllvorgänge (basierend auf dem Rezept) vorhanden sind, ist es nützlich, die Stapelausführung in die Lage zu versetzen, den Zulaufventilparameter dynamisch anzugeben, nachdem die Einheitenphase für das Reaktor_02-Einheitenmodul innerhalb der Steuereinrichtung 12 geschaffen wurde.
  • Wie vorstehend angeführt verwendeten Systeme nach dem Stand der Technik, welche dynamische Bindung ermöglichten, typischerweise ein Adressarray, in welchem unterschiedliche Zeiger an verschiedenen Adressen gespeichert werden konnten, welche innerhalb der Steuerroutine verwendet wurden, wobei zu jeder Adresse ein Zeiger gehörte. Es war jedoch schwierig, diese Adressen und die darin enthaltenen Zeiger zu verwalten und es gab keine Möglichkeit, dynamisch zu bestimmen, ob der Zeiger an einer Adresse gültig war, bevor versucht wurde, die dynamische Verbindung herzustellen. Wenn der Zeiger ungültig war, würde die Steuerroutine typischerweise unterbrochen, was insbesondere im Verlauf eines Stapelablaufs besonders unerwünscht war, da die Unterbrechung allgemein zum Verlust von Produktionszeit und -materialien führte und möglicherweise einen sehr schwierigen Eingriff der Bedienungspersonen erforderte, um den Stapelablauf fortzuführen.
  • Gemäß vorliegender Erfindung ist es bevorzugt, die Verwendung einer dynamisch gebundenen (dynamisch spezifizierten) Variablen oder eines entsprechenden Parameters (eines dynamischen Referenzparameters) in der Prozeßsteuerroutine für jede Phasenklasse zu ermöglichen. Mit anderen Worten ist es in einigen Fällen bevorzugt, einen dynamischen Referenzparameter in die PAD einer Phasenklasse zu setzen, wobei dieser dynamische Referenzparameter in die Einheitenphasen übertragen oder umgesetzt wird, wenn die ausführbare Einheitenphase aus der Phasenklasse geschaffen wird, wobei der Wert dieses dynamischen Referenzparameters spezifiziert werden kann, nachdem die Einheitenphase geschaffen wurde und auch nachdem die Ausführung der Einheitenphase begonnen hat (das heißt während der Laufzeit). Wie vorstehend angemerkt ist dieser Parameter nützlich, wenn beispielsweise die Auswahlentscheidung hinsichtlich des Wertes des Parameters auf einer Information basiert, die zum Zeitpunkt der Konfiguration nicht zur Verfügung steht, beispielsweise eine Auswahl, die auf einer Eingabe einer Bedienungsperson basiert, eine Auswahl, die auf einem Rezeptparameter basiert, der von der Stapelausführungsroutine weitergegeben wird, eine Auswahl, die auf Laufzeitwerten von Steuervariablen basiert, etc..
  • Der dynamische Referenzparameter zur Verwendung in der Prozeßsteuerroutine kann unter Verwendung von Konventionen definiert werden, die verwendet werden, um andere Hardware- oder Softwareparameter innerhalb des Prozeßsteuersystems zu definieren, mit der Ausnahme, daß der dynamische Referenzparameter in dem Speicher 22 der Steuereinrichtung 12 lokalisiert ist (oder einem anderen Speicher, falls erwünscht). Der dynamische Referenzparameter enthält vorzugsweise mehrere Attribute oder Felder, um die Ausführung von verschiedenen Operationen unter Verwendung des dynamischen Referenzparameters zu ermöglichen. Insbesondere kann der dynamische Referenzparameter die Felder oder Attribute enthalten, die in der folgenden Tabelle angegeben sind.
    Name Typ Konfigurierbar Lesbar Schreibbar
    DREF String Nein Lesen als String gibt den gegenwärtigen Referenzpfad wenn möglich mit aufgelösten Aliasnamen zurück. Nicht als Fließkomma, ganze Zahl, etc. lesbar. Schreiben als String schafft einen neuen Referenzpfad; veranlaßt idealerweise die Verbindung einer neuen externen Referenz. Nicht schreibbar als Fließkomma, ganze Zahl, etc.
    CONN ganze Zahl Nein Definiert den Verbindungsstatus der Referenz in dem DREF-Feld. Lesen als ganze Zahl: 0 bedeutet Referenz wurde hergestellt; –1 bedeutet Referenz wird niemals funktionieren; > 0 bedeutet Verbindung im Aufbau, erneute Überprüfung später empfohlen. Nein
    DRFV Fließ Nein Der Wert des referenzierten Feldes als ein Fließkommawert interpretiert. Wird in numerischen Ausdrücken verwendet. Wenn das referenzierte Feld nicht als ein Fließkommawert interpretiert werden kann (angenommen es ist ein Feld des String-Typs), ist der gelesene Wert MAX_Wert. Der Wert wird auch als MAX_Wert gelesen, wenn das CONN-Attribut nicht gleich 0 ist. Schreiben in dieses Attribut verursacht, daß der Wert des referenzierten Feldes als ein Fließkommawert asynchron geschrieben wird. Wird bei numerischen Ausdrücken verwendet. Wenn das referenzierte Feld nicht als ein Fließkommawert interpretiert werden kann (angenommen es ist ein Feld des StringTyps), ist die Schreiboperation nicht durchführbar. Kein Schreibversuch, wenn das CONN-Attribut nicht gleich 0 ist.
    DRSV String Nein Der Wert des referenzierten Feldes als String interpretiert. In String-Ausdrücken verwendet. Wenn das referenzierte Feld numerisch ist, wird der numerische Wert Schreiben in dieses Attribut verursacht, daß der Wert des referenzierten Feldes als String asynchron geschrieben wird. In String-Ausdrücken verwendet. Wenn das referenzierte Feld numerisch
    Kein Schreibversuch, wenn das CONN-Attribut nicht gleich 0 ist. in String-Form umgewandelt (sofern möglich). Ein leerer String wird zurückgegeben, wenn das CONN-Attribut nicht gleich 0 ist. ist, wird der String in die numerische Form umgewandelt (sofern möglich) und geschrieben.
    DRST ganze Zahl Nein Liest den Wert des Statusfeldes des referenzierten Parameters (sofern vorhanden). Dieses Attribut wird verwendet, um den Statuswert von dem dynamisch referenzierten Feld zu einem lokalen Parameterstatusfeld zur Verwendung in nachfolgenden statussensitiven Berechnungen zu kopieren. Auf den MAX_Wert gesetzt, wenn das CONN-Attribut nicht gleich 0 ist; auf einen ”gut”-Statuswert gesetzt, wenn das dynamisch referenzierte Feld kein Statusfeld hat. Nein
    WRST ganze Zahl Nein Liest den Statuswert des referenzierten Feldes und gibt den Erfolg des letzten Schreibvorganges in das dynamisch referenzierte Feld an. Werte könnte beliebige sein, die beispielsweise unterscheiden: ”in Ausführung”, ”erfolgreich”, ”keine Kommunikation”, ”schlecht”, etc.. Dieses Attribut wird auf einen Wert ”schlecht” rückgesetzt, wenn ein neuer Referenz-String in das DREF-Attribut geschrieben wird. Nein
  • Der Wert des DREF-Attributs (dynamische Referenz) ist der des Zeigers, des Kennzeichens oder des Pfades zu dem Parameter oder Feld, mit dem die dynamische Referenz gegenwärtig zugeordnet ist. In dem DeltaV-System ist dieser Zeiger ein String-Wert (wie z. B. ein Pfad), der auf ein Modul verweist, wie z. B. eine Einrichtung oder einen Modulparameter. Beispielsweise könnte ein dynamischer Referenzparameter ”AUSLASS_POS” einer String-Konstanten zugewiesen werden, so daß sie eine Referenz auf einen Parameter/ein Feld ist, beispielsweise unter Verwendung des Befehls
    Figure 00480001
    oder
    Figure 00490001
  • Selbstverständlich kann bei anderen Systemen der Wert des DREF-Feldes numerisch oder ein String sein, in Abhängigkeit von der Art, in der das System Geräte, Module, etc. spezifiziert. Allgemein ausgedrückt schafft die Verwendung einer DREF-Zuordnung einen neuen dynamischen Referenzparameter in der Steuereinrichtung 12, da die dynamischen Referenzen durch Zuordnen eines vollen Parameter-Referenzpfadstrings zu dem DREF-Feld eines dynamischen Referenzparameters geschaffen werden. Wenn eine dynamische Zielbestimmung von Steueroperationen erforderlich ist, muß der Benutzer einen dynamischen Referenzparameter für jeden Parameter schaffen, der nicht vor der Laufzeit bestimmt werden kann. Ein dynamischer Referenzparameter kann in jedem Kontext geschaffen werden, in dem jeder andere externe Referenzparameter in dem System geschaffen wird, einschließlich beispielsweise als eine Einheitenkennzeichenklasse, als Teil einer Einheitenklasse, als ein Phasenalgorithmusparameter in einer Phasenklasse und als ein Modullevelparameter in einem Phasenlogikmodul. Selbstverständlich kann der dynamische Referenzparameter in anderen Kontexten ebenso verwendet werden. Wie auch bei anderen benutzererstellten Parametern konfiguriert der Benutzer den Namen für den dynamischen Referenzparameter in der Weise, die den Parameternamenkonfigurationsregeln entspricht und die in dem lokalen Namensbereich einzigartig ist (das heißt er kann nicht den selben Namen wie andere Parameter, Blöcke oder Phasenklassennamen haben, die innerhalb derselben Ebene definiert sind). Das Schreiben eines String zu dem DREF-Attribut ist wahrscheinlich eine ”teure” Operation (die alle früheren externen Referenzobjekte zerstört und eine Bindung an einen neuen externen Parameter vollzieht) und sollte demnach allgemein nur in nicht wiederholten (Impuls) Ausdrücken ausgeführt werden. Das Schreiben eines neuen String in dem DREF-Attribut sollte unmittelbar veranlassen, daß die aus dem CONN-Attribut gelesenen Werte (und den anderen Attributen des dynamischen Referenzparameters) ”schlecht” werden (falls die Verbindung nicht unmittelbar geschaffen wird), so daß ein nachfolgender Ausdruck, der den Wert dieser Felder testet, zuverlässig arbeitet.
  • Die String-Zuordnung zu dem DREF-Attribut kann erreicht werden, indem jede gewünschte String-Operation einschließlich beispielsweise einer Verbindungsoperation (eine Verbindung von zwei oder mehr Strings), eine String-Auswahloperation (in der einer einer Vielzahl von möglichen Strings basierend auf dem Wert eines Operanden ausgewählt wird) oder jede andere String-Operation verwendet werden.
  • Das CONN-Attribut (Verbindung) schafft eine Angabe, ob der durch das DREF-Attribut angegebene Wert ein gültiges oder auflösbares Feld innerhalb des Kontexts des Steuersystems ist. Wenn das DREF-Attribut verändert oder gesetzt wird, testet die Steuereinrichtung 12 unmittelbar und automatisch dessen Wert, um zu sehen, ob das Kennzeichen oder der Pfad für dieses existieren und in der gegenwärtigen Konfiguration des Steuersystems 10 lokalisiert oder aufgelöst werden können. Wenn der Wert des DREF-Attributs gültig und auflösbar ist, wird das CONN-Attribut auf 0 gesetzt. Wenn jedoch der Wert des DREF-Attributs nicht auflösbar ist und niemals aufgelöst werden kann, da er beispielsweise innerhalb des Kontexts des Steuersystems nicht ordnungsgemäß ist oder einfach nicht existiert, wird das CONN-Attribut auf –1 gesetzt. Wenn die Steuereinrichtung 12 aktiv versucht, das DREF-Attribut aufzulösen, jedoch aufgrund von Wartezeiten bedingt durch Verbindungsoperationen etc. nicht in der Lage war, dies zu vollziehen, wird der Wert des CONN-Attributs auf größer als 0 gesetzt, was angibt, daß dieser Wert noch nicht aufgelöst ist, jedoch später aufgelöst werden kann. Es ist bevorzugt, daß nach einer Zeitüberschreitungsperiode der Wert des CONN-Attributs auf –1 gesetzt wird, wenn das DREF-Attribut noch nicht aufgelöst wurde. Das CONN-Attribut ist sehr nützlich, da es das Testen der dynamischen Referenz während der Laufzeit ermöglicht. Beispielsweise kann ein einfacher Befehl ”IF<Name des dynamischen Parameters>.CONN = 0, THEN <zu vollziehende Aktion>” verwendet werden, um eine Aktion nur dann zu vollziehen, wenn der DREF-Wert gültig definiert ist. Diese Fähigkeit erlaubt es, eine Steuerroutine zu schreiben, welche die dynamische Referenz verwenden kann, die jedoch nicht unterbrochen wird, wenn die dynamische Referenz während der Laufzeit ungültig ist. Selbstverständlich können andere Tests oder Befehle, welche das CONN-Attribut verwenden, verwendet werden, wie z. B. Verzweigungsbefehle, Halte- oder Abbruchbefehle etc.. Ferner kann das CONN-Attribut jeden anderen gewünschten Wert (abgesehen von 0, –1 und größer als 0) annehmen, um den Erfolg oder das Versagen der Verbindung anzugeben.
  • Das DRFV-Lese-/Schreibattribut (dynamischer Referenzfließkommawert) des dynamischen Referenzparameters wird verwendet, um das Lesen aus dem und Schreiben in das Feld, das durch das DREF-Attribut angegeben ist, als Fließkommawert oder ganzzahliger Wert zu ermöglichen. In einer Ausführungsform ist der Wert des DRFV-Attributs auf einen Maximalwert oder auf einen anderen spezifizierten Wert gesetzt, wenn das CONN-Attribut nicht 0 ist. Ferner verhindert in dieser Ausführungsform das DRFV-Attribut das Schreiben in das dynamisch referenzierte Feld, wenn das CONN-Attribut nicht 0 ist. Entsprechend wird das DRSV-Lese-/Schreibattribut (dynamischer Referenzstringwert) des dynamischen Referenzparameters verwendet, um das Lesen aus dem und Schreiben in das durch das DREF-Attribut als ein Stringwert spezifizierte Feld zu ermöglichen. In einer Ausführungsform ist das DRSV-Attribut so gesetzt, daß es ein leerer String ist, wenn das CONN-Attribut nicht 0 ist, und verhindert das Schreiben, wenn das CONN-Attribut nicht 0 ist. Dieses sind nützliche Attribute, da sie das Schreiben in das und Lesen aus dem dynamisch referenzierten Feld als entweder ein String- oder ein numerisches Feld oder als beides ermöglichen, wobei berücksichtigt wird, ob das dynamisch referenzierte Feld tatsächlich existiert oder gültig ist. Selbstverständlich könnten das DRVF- oder DRSV- oder andere spezifisch geschaffene Attribute verwendet werden, um Boolesche Werte oder Array-Werte (wie z. B. eine Gruppe von Werten, die in einem Array gespeichert ist) in dem durch das DREF-Attribut angegebenen Feld zu lesen und/oder zu schreiben.
  • Das DRST-Attribut (dynamischer Referenzstatus) ermöglicht das Lesen des Statusattributes, das zu dem von dem DREF-Attribut spezifizierten Feld gehört. In bestimmten Steuereinrichtungs- oder Kommunikationsprotokollen, wie z. B. dem DeltaV- und dem Fieldbus-Protokoll, enthalten einige Parameter oder Felder einen Wert und einen Status, der den Status des Wertes angibt, z. B. ob der Wert gut, schlecht, unsicher, etc. ist. Das DRST-Attribut ermöglicht den Zugriff auf diesen Statuswert für einen dynamischen Referenzparameter. Das WRST-Attribut (Schreibstatus) liest den Schreibstatuswert des durch das DREF-Attribut bezeichneten Feldes. Dieser Status gibt den Erfolg der letzten Schreiboperation in das von dem DREF-Attribut bezeichnete Feld an und gibt Zugriff auf den Schreibstatus des dynamisch referenzierten Feldes.
  • Selbstverständlich könnten nach Wunsch andere Attribute mit dem dynamischen Referenzparameter vorgesehen sein, um andere Operationen zu ermöglichen, wie z. B. das Lesen oder Schreiben in den Moduswert, Grenzwert oder in andere Statuswerte, die zu dem dynamisch referenzierten Feld gehören, oder die Durchführung jedes anderen Lese- oder Schreibvorganges in einem Attribut des dynamisch referenzierten Feldes. Entsprechend können die hierin identifizierten Attribute andere Namen oder Werte annehmen, um den Erfolg, das Versagen, etc. einer Verbindung oder eines Lese- oder Schreibvorganges anzugeben.
  • Wenn ein dynamischer Referenzparameter im Kontext eines Einheitenmoduls verwendet wird, das heißt bei der Schaffung einer Einheitenphase, die eine dynamische Referenz enthält, werden Strings, die in das DREF-Attribut geschrieben werden, auf Aliasnamen untersucht, und eventuell vorhandene Aliasnamen werden auf der Basis der gegenwärtigen Alias-Auflösungstabelle für das Einheitenmodul ersetzt. Als Resultat können dynamische Referenzen geschaffen werden, um Felder zu spezifizieren, welche Aliasnamen verwenden, und diese Aliasnamen werden trotzdem noch aufgelöst, wenn die Einheitenphase aus der Phasenklasse geschaffen wird. Dies ermöglicht es, dynamische Referenzparameter in breiterem Umfang in Prozeßsteuerroutinen zu verwenden, auch wenn die dynamische Referenz nicht vor der Laufzeit aufgelöst werden kann oder während der Laufzeit auf der Basis eines Schreibvorganges in das DREF-Attribut des dynamischen Referenzparameters aufgelöst wird.
  • Wenn SFC-Algorithmen verwendet werden, kann das Schreiben durch dynamische Referenzparameter auf mehrere Weisen erfolgen, in Abhängigkeit von der Gestaltung des SFC. Beispielsweise kann die Routine den gewünschten Wert als ein Statement in einem Schrittausdruck (unter der Annahme, daß die Bestätigung des Schreibvorganges, falls erforderlich, durch die Logik in späteren Teilen des SFC gehandhabt wird) zuordnen, die Routine kann eine Aktion des Impuls/Zuordnungstyps verwenden, mit der Bestätigung, einen Schreibvorgang auszuführen und anschließend zu pausieren, bis das WRST-Attribut einen anderen Wert annimmt als den Wert ”in Betrieb” oder die Routine kann eine Aktion des Nichtspeicherungs-/Zuordnungstyps verwenden, um den Wert wiederholt zu schreiben, bis der Übergangsausdruck erfaßt, daß der Wert erreicht wurde oder die Schrittzeit zu lang ist. Wenn somit SFC-Algorithmen verwendet werden, ist es bevorzugt, dynamische Referenzen durch die Verwendung von Aktionen des Impuls/Zuweisungstyps zu schaffen und zu verifizieren, mit einer Bestätigung, so daß der Aktionsausdruck den vollen dynamischen Referenzpfad auflöst und diesen dem DREF-Feld des entsprechenden dynamischen Referenzparameters zuweist (auf Modulebene oder Phasenebene), und so, daß der Bestätigungsausdruck prüft, ob der Wert des CONN-Attributs kleiner oder gleich 0 ist (verbunden oder Verbindung niemals möglich). Alternativ könnte bei dynamischen Referenzparametern, die gelesen werden sollen, der Wert des DRFV-Attributs gelesen und auf einen vernünftigen Wert (im Gegensatz zu dem MAX Wert) geprüft werden und der Bestätigungszeitüberschreitungswert könnte auf eine kleine Zahl von Sekunden (beispielsweise fünf Sekunden) gesetzt werden.
  • Wenn ferner verschiedene dynamische Referenzparameter an demselben Punkt in einem Algorithmus geschaffen werden können, ist es bevorzugt, eine Aktion für jeden in demselben SFC-Schritt zu schaffen. Anschließend könnte ein einzelner Term in dem nachfolgenden Ausdruck des SFC-Übergangs, wie etwa: ”'RESOLVE_STEP/PENDING_CONFIRMS.CV'=0” verhindern, daß der Algorithmus weiter abläuft, bis alle dynamischen Referenzparameter in ihrem Endzustand ”stabilisiert” sind. Wenn der Algorithmus Verbindungen mit fehlendem Alias oder Verbindungen mit Alias IGNORIEREN handhaben muß, könnten nachfolgende Ausdrücke das CONN-Attribut des individuellen dynamischen Referenzparameters testen, um die Ausführung des Algorithmus zu leiten.
  • Sobald eine dynamische Referenz geschaffen wurde (das heißt das DREF-Attribut geschrieben wurde) und die dynamische Referenz verifiziert wurde (das CONN-Attribut ist 0), können die DRFV-, DRSV- und DRST-Felder geschrieben werden, um Werte in den referenzierten Parametern zu setzen. In kontinuierlichen Algorithmen (wie z. B. ein kontinuierlich ablaufender FAIL_MONITOR-Verbundblock) könnte die empfohlene Vorgehensweise für das Schreiben durch einen dynamischen Referenzparameter (der bereits geschaffen wurde) die Form annehmen:
    Figure 00550001
    wodurch kontinuierlich versucht wird, den referenzierten Parameter auf den gewünschten Wert zu steuern, bis dies in einer Weise erreicht wurde, die das Schreiben vermeidet, wenn der letzte Schreibversuch noch abläuft.
  • Es versteht sich, daß die Prozeßsteuerroutinen unter Verwendung von Aliasnamen, die vor der Laufzeit aufgelöst werden, und von indirekten Referenzen, wie z. B. dynamischen Referenzparametern, die während der Laufzeit aufgelöst werden, innerhalb jeder gewünschten Prozeßsteuerprogrammierumgebung verwendet und implementiert werden können und in jedem Prozeßsteuersystem verwendet werden können, das jeden gewünschten Typ eines Prozeßsteuerkommunikationsprotokolls verwendet, und ferner verwendet werden können, um jede Art von Funktion bezüglich jeder Art von Einrichtung bzw. Einrichtungen oder Untereinheiten von Einrichtungen auszuführen. Prozeßsteuerroutinen, die indirekte Referenzierung verwenden, wie hierin beschrieben, werden vorzugsweise in Software implementiert die beispielsweise in einer Steuereinrichtung oder einer anderen Prozeßsteuervorrichtung gespeichert ist. Diese Routinen können jedoch alternativ oder zusätzlich in Hardware, Firmware, etc. nach Wunsch implementiert werden. Wenn sie in Software implementiert sind, können die hierin erörterten Prozeßsteuerroutinen in jedem computerlesbaren Speicher gespeichert werden, wie z. B. auf einer Magnetplatte, einer Laserplatte oder einem anderen Speichermedium, in einem RAM oder ROM eines Computers oder einer Steuereinrichtung einer Anlageneinrichtung, etc.. Entsprechend kann diese Software einem Benutzer oder einer Vorrichtung über jedes bekannte oder gewünschte Auslieferungsverfahren zugeführt werden, einschließlich beispielsweise über einen Kommunikationskanal, wie z. B. eine Telefonleitung, das Internet etc..

Claims (11)

  1. Prozesssteuersystem zur Verwendung bei der Steuerung eines Prozesses, der mehrere Einheitenklassen (50, 52) hat, von welchen jede ein oder mehrere Einheitenmodule (54, 64) enthält mit: einer Steuereinrichtung (12); einem Speicher (20, 22); einer generischen Steuerroutine, die einen Aliasnamen verwendet; und eine Alias-Auflösungstabelle (60) für jedes der Einheitenmodule (54, 64) einer der Einheitenklassen (50, 52), wobei jede Alias-Auflösungstabelle (60) eine Aliasdefinition für den Aliasnamen hat; wobei die generische Steuerroutine in dem Speicher (20, 22) gespeichert ist, dadurch gekennzeichnet, dass, wenn die Steuerung eines bestimmten Einheitenmoduls (54, 64) erforderlich ist, die Steuereinrichtung (12) unter Verwendung der Alias-Auflösungstabelle (60) für das bestimmte Einheitenmodul (54, 64) eine diesbezüglich konkretisierte Version der generischen Steuerroutine für das bestimmte Einheitenmodule (54, 64) erstellt und das bestimmte Einheitenmodul (54, 64) steuert, indem die diesbezüglich konkretisierte Version der generischen Steuerroutine ausgeführt wird, wobei die generische Steuerroutine so ausgelegt ist, dass sie angewandt wird, um Einheitenmodule (54, 64) zu steuern, die zu zwei oder mehr ausgewählten Einheitenklassen (50, 52) gehören, und die Alias-Auflösungstabelle (60) für jedes der Einheitenmodule (54, 64) für jede der ausgewählten Einheitenklassen (50, 52) eine Aliasdefinition für den Aliasnamen hat.
  2. Prozesssteuersystem nach Anspruch 1, dadurch gekennzeichnet, dass es ferner eine Konfigurations-Workstation (14) enthält, die mit der Steuereinrichtung (12) in Kommunikationsverbindung steht, wobei die Workstation (14) einen Workstation-Speicher (20) enthält, der eine Konfigurationsroutine speichert, und einen Prozessor (24), der die Konfigurationsroutine ausführt, wobei die Konfigurationsroutine eine Prüfroutine enthält, die bestimmt, ob die Alias-Auflösungstabelle (60) für jedes der Einheitenmodule (54, 64) für jede der ausgewählten Einheitenklassen (50, 52) eine gültige Aliasdefinition für den Aliasnamen enthält.
  3. Prozesssteuersystem nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass es ferner einen Indikator enthält, der zu der generischen Steuerroutine gehört und die ausgewählten Einheitenklassen (54, 64) angibt, für welche die generische Steuerroutine verwendet werden kann, um diesbezüglich konkretisierte Versionen der generischen Steuerroutine zu schaffen.
  4. Prozesssteuersystem nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass es ferner einen Indikator für jedes der Einheitenmodule (54, 64) von mindestens einer Einheitenklasse (50, 52) enthält, der eine Einheitenmoduleigenschaft angibt, die von Einheitenmodul (54, 64) zu Einheitenmodul (54, 64) variieren kann, wobei die generische Steuerroutine mindestens zwei Steueralgorithmen enthält, die alternativ zu verwenden sind, um unterschiedliche Einheitenmodule (54, 64) basierend auf der Einheitenmoduleigenschaft zu steuern, und wobei die Steuereinrichtung (12) den Indikator für das bestimmte Einheitenmodul (54, 64) verwendet, um einen der mindestens zwei Steueralgorithmen auszuwählen, wenn die diesbezüglich konkretisierte Version der generischen Steuerroutine für dieses bestimmte Einheitenmodul (54, 64) erstellt wird.
  5. Prozesssteuersystem nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Alias-Auflösungstabelle (60) für eines der Einheitenmodule (54, 64) eine Alias-Ignorieren-Definition für den Aliasnamen enthält, welche die Steuereinrichtung (12) veranlasst, den Aliasnamen zu ignorieren, wenn die diesbezüglich konkretisierte Version der generischen Steuerroutine für eines der Einheitenmodule (54, 64) ausgeführt wird.
  6. Prozesssteuersystem nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die generische Steuerroutine einen dynamischen Referenzparameter enthält, dessen Wert nach dem Erstellen der diesbezüglich konkretisierten Version der generischen Steuerroutine für das bestimmte Einheitenmodul (54, 64) zugeordnet werden kann.
  7. Prozesssteuersystem nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der dynamische Referenzparameter mehrere Attribute enthält, wobei eines der Attribute ein Referenzattribut ist, das einen Feldwert enthält, der ein Feld angibt, auf welches der dynamische Referenzparameter verweist.
  8. Prozesssteuersystem nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass ein weiteres der Attribute ein Verbindungsattribut ist, das eine Angabe bietet, ob der Feldwert des Referenzattributes ein gültiges Feld ist.
  9. Prozesssteuersystem nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass ein weiteres der Attribute ein Lese-/Schreibattribut ist, das in das von dem Referenzattribut angegebene Feld schreibt oder aus diesem liest.
  10. Prozesssteuersystem nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass ein weiteres der Attribute ein Statusattribut ist, das einen Status liest, der zu dem durch das Referenzattribut angegebenen Feld gehört.
  11. Prozesssteuersystem nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass das Statusattribut einen Schreibstatus liest, der einen Erfolg oder ein Versagen eines vorherigen Schreibvorganges in das von dem Referenzattribut angegebene Feld angibt.
DE10011661A 1999-03-12 2000-03-10 Prozeßsteuersystem mit Prozeßsteuerroutinen unter Verwendung von indirekter Referenzierung Expired - Lifetime DE10011661B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/267,431 US6385496B1 (en) 1999-03-12 1999-03-12 Indirect referencing in process control routines
US09/267,431 1999-03-12

Publications (2)

Publication Number Publication Date
DE10011661A1 DE10011661A1 (de) 2000-09-14
DE10011661B4 true DE10011661B4 (de) 2011-09-15

Family

ID=23018744

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10011661A Expired - Lifetime DE10011661B4 (de) 1999-03-12 2000-03-10 Prozeßsteuersystem mit Prozeßsteuerroutinen unter Verwendung von indirekter Referenzierung

Country Status (4)

Country Link
US (1) US6385496B1 (de)
JP (1) JP4707792B2 (de)
DE (1) DE10011661B4 (de)
GB (1) GB2348020B (de)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9046881B2 (en) 2002-10-22 2015-06-02 Fisher-Rosemount Systems, Inc. Updating and utilizing dynamic process simulation in an operating process environment
US9069344B2 (en) 2002-10-22 2015-06-30 Fisher-Rosemount Systems, Inc. Smart process modules and objects in process plants
US9904263B2 (en) 2002-10-22 2018-02-27 Fisher-Rosemount Systems, Inc. Smart process objects used in a process plant modeling system
US10878140B2 (en) 2016-07-27 2020-12-29 Emerson Process Management Power & Water Solutions, Inc. Plant builder system with integrated simulation and control system configuration
US11418969B2 (en) 2021-01-15 2022-08-16 Fisher-Rosemount Systems, Inc. Suggestive device connectivity planning

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7257523B1 (en) * 1999-05-06 2007-08-14 Fisher-Rosemount Systems, Inc. Integrated distributed process control system functionality on a single computer
US6865576B1 (en) * 1999-05-21 2005-03-08 International Business Machines Corporation Efficient schema for storing multi-value attributes in a directory service backing store
GB2351370A (en) * 1999-06-25 2000-12-27 Ibm Data processing with policed object union
JP3998372B2 (ja) * 1999-06-30 2007-10-24 株式会社東芝 半導体処理工程制御システム、半導体処理工程制御方法、及び、そのための処理を記録した記録媒体
US7020876B1 (en) * 2000-06-30 2006-03-28 Fisher-Rosemount Systems, Inc. Campaign management for batch processes
US6647315B1 (en) * 2000-09-29 2003-11-11 Fisher-Rosemount Systems, Inc. Use of remote soft phases in a process control system
DE10101746A1 (de) * 2001-01-16 2002-08-14 Siemens Ag Verfahren zum Betreiben eines Automatisierungssystems
JP3729251B2 (ja) * 2001-03-12 2005-12-21 オムロン株式会社 コントローラ及びシステム
US7047522B1 (en) * 2001-04-30 2006-05-16 General Electric Capital Corporation Method and system for verifying a computer program
US7802238B2 (en) * 2001-06-22 2010-09-21 Invensys Systems, Inc. Process control script development and execution facility supporting multiple user-side programming languages
US6993643B2 (en) * 2001-12-03 2006-01-31 International Business Machines Corporation Method and system of dynamic video driver selection on a bootable CD via symbolic links
US7076312B2 (en) * 2002-08-02 2006-07-11 Fisher-Rosemount Systems, Inc. Integrated electronic signatures for approval of process control and safety system software objects
US7424702B1 (en) * 2002-08-19 2008-09-09 Sprint Communications Company L.P. Data integration techniques for use in enterprise architecture modeling
GB2418031A (en) * 2002-10-22 2006-03-15 Fisher Rosemount Systems Inc Smart process modules and objects in process plants
US7865251B2 (en) * 2003-01-28 2011-01-04 Fisher-Rosemount Systems, Inc. Method for intercontroller communications in a safety instrumented system or a process control system
US7043311B2 (en) * 2003-02-18 2006-05-09 Fisher-Rosemount Systems, Inc. Module class objects in a process plant configuration system
US7526347B2 (en) * 2003-02-18 2009-04-28 Fisher-Rosemount Systems, Inc. Security for objects in a process plant configuration system
US7117052B2 (en) * 2003-02-18 2006-10-03 Fisher-Rosemount Systems, Inc. Version control for objects in a process plant configuration system
US7369912B2 (en) * 2003-05-29 2008-05-06 Fisher-Rosemount Systems, Inc. Batch execution engine with independent batch execution processes
DE10347972A1 (de) 2003-10-15 2005-05-19 Siemens Ag Steuerverfahren für eine Produktionsmaschine, insbesondere eine Werkzeugmaschine, durch eine der Produktionsmaschine zugeordnete Steuereinrichtung
US7635586B2 (en) 2003-11-26 2009-12-22 Broadley-James Corporation Integrated bio-reactor monitor and control system
US7435581B2 (en) 2003-11-26 2008-10-14 Broadley-James Corporation Integrated bio-reactor monitor and control system
DE102004007231B4 (de) * 2004-02-13 2011-07-28 Siemens AG, 80333 Verfahren zum Konfigurieren einer Automatisierungskomponente eines Automatisierungssystems und entsprechendes Automatisierungssystem
JP2007536634A (ja) * 2004-05-04 2007-12-13 フィッシャー−ローズマウント・システムズ・インコーポレーテッド プロセス制御システムのためのサービス指向型アーキテクチャ
US7729789B2 (en) * 2004-05-04 2010-06-01 Fisher-Rosemount Systems, Inc. Process plant monitoring based on multivariate statistical analysis and on-line process simulation
US7991602B2 (en) * 2005-01-27 2011-08-02 Rockwell Automation Technologies, Inc. Agent simulation development environment
US7457675B2 (en) * 2005-08-15 2008-11-25 Abb Inc. External status asset monitor
US7444191B2 (en) 2005-10-04 2008-10-28 Fisher-Rosemount Systems, Inc. Process model identification in a process control system
US8036760B2 (en) 2005-10-04 2011-10-11 Fisher-Rosemount Systems, Inc. Method and apparatus for intelligent control and monitoring in a process control system
US7738975B2 (en) 2005-10-04 2010-06-15 Fisher-Rosemount Systems, Inc. Analytical server integrated in a process control network
US8055358B2 (en) 2005-12-05 2011-11-08 Fisher-Rosemount Systems, Inc. Multi-objective predictive process optimization with concurrent process simulation
US7860589B2 (en) * 2006-03-02 2010-12-28 Rockwell Automation Technologies, Inc. Programmatic access to controller construct and variable names
US7742833B1 (en) 2006-09-28 2010-06-22 Rockwell Automation Technologies, Inc. Auto discovery of embedded historians in network
US7672740B1 (en) * 2006-09-28 2010-03-02 Rockwell Automation Technologies, Inc. Conditional download of data from embedded historians
US8181157B2 (en) * 2006-09-29 2012-05-15 Rockwell Automation Technologies, Inc. Custom language support for project documentation and editing
US7913228B2 (en) 2006-09-29 2011-03-22 Rockwell Automation Technologies, Inc. Translation viewer for project documentation and editing
US7848829B2 (en) * 2006-09-29 2010-12-07 Fisher-Rosemount Systems, Inc. Methods and module class objects to configure absent equipment in process plants
US7933666B2 (en) * 2006-11-10 2011-04-26 Rockwell Automation Technologies, Inc. Adjustable data collection rate for embedded historians
US7835806B2 (en) 2007-01-29 2010-11-16 Rockwell Automation Technologies, Inc. Method for indirect access to controller data using name stored in string tag
US20080255681A1 (en) 2007-04-10 2008-10-16 Cindy Alsup Scott Methods and apparatus to manage process plant alarms
US8046086B2 (en) * 2007-05-15 2011-10-25 Fisher-Rosemount Systems, Inc. Methods and systems for batch processing and execution in a process system
US7974937B2 (en) * 2007-05-17 2011-07-05 Rockwell Automation Technologies, Inc. Adaptive embedded historians with aggregator component
US20080294361A1 (en) * 2007-05-24 2008-11-27 Popp Shane M Intelligent execution system for the monitoring and execution of vaccine manufacturing
US8407716B2 (en) * 2007-05-31 2013-03-26 Fisher-Rosemount Systems, Inc. Apparatus and methods to access information associated with a process control system
US8369975B2 (en) 2007-09-21 2013-02-05 Fisher-Rosemount Systems, Inc. Online recipe synchronization in a real-time batch executive environment
US7930639B2 (en) 2007-09-26 2011-04-19 Rockwell Automation Technologies, Inc. Contextualization for historians in industrial systems
US7930261B2 (en) * 2007-09-26 2011-04-19 Rockwell Automation Technologies, Inc. Historians embedded in industrial units
US7917857B2 (en) * 2007-09-26 2011-03-29 Rockwell Automation Technologies, Inc. Direct subscription to intelligent I/O module
US7882218B2 (en) * 2007-09-27 2011-02-01 Rockwell Automation Technologies, Inc. Platform independent historian
US7962440B2 (en) * 2007-09-27 2011-06-14 Rockwell Automation Technologies, Inc. Adaptive industrial systems via embedded historian data
US20090089671A1 (en) * 2007-09-28 2009-04-02 Rockwell Automation Technologies, Inc. Programmable controller programming with embedded macro capability
US20090089247A1 (en) * 2007-09-28 2009-04-02 Terrence Lynn Blevins Methods and apparatus to standardize data properties in a process control environment
US8825189B2 (en) * 2007-11-13 2014-09-02 Fisher Rosemount Systems, Inc. Methods and apparatus to execute an auxiliary recipe and a batch recipe associated with a process control system
US8150541B2 (en) * 2007-11-13 2012-04-03 Fisher-Rosemount Systems, Inc. Methods and apparatus to modify a recipe process flow associated with a process control system during recipe execution
US8555206B2 (en) * 2007-12-21 2013-10-08 Fisher-Rosemount Systems, Inc. Methods and apparatus to present recipe progress status information
US8606379B2 (en) * 2008-09-29 2013-12-10 Fisher-Rosemount Systems, Inc. Method of generating a product recipe for execution in batch processing
US8881039B2 (en) 2009-03-13 2014-11-04 Fisher-Rosemount Systems, Inc. Scaling composite shapes for a graphical human-machine interface
US8825183B2 (en) * 2010-03-22 2014-09-02 Fisher-Rosemount Systems, Inc. Methods for a data driven interface based on relationships between process control tags
US10127504B2 (en) * 2010-12-16 2018-11-13 Siemens Industry, Inc. Method for linking control system inputs and outputs to symbolic controls
US9772617B2 (en) * 2011-06-30 2017-09-26 General Electric Company Systems and methods for function block instantiation
BR112015005462B1 (pt) 2012-09-14 2022-04-05 Global Life Sciences Solutions Usa Llc Aparelho e método para controlar a execução de uma tarefa de processo dentro de uma configuração de um sistema de controle de biorreator, e, meio de armazenamento acessível por máquina tangível
US9086688B2 (en) * 2013-07-09 2015-07-21 Fisher-Rosemount Systems, Inc. State machine function block with user-definable actions on a transition between states
DE102015213700A1 (de) * 2015-07-21 2017-01-26 Siemens Aktiengesellschaft Verfahren und System zur homogenen Integration von Speicherprogrammierbaren Steuerungen in ein Anlagenmodell
US10671038B2 (en) 2016-07-15 2020-06-02 Fisher-Rosemount Systems, Inc. Architecture-independent process control
US10678195B2 (en) * 2017-06-12 2020-06-09 Honeywell International Inc. Apparatus and method for identifying, visualizing, and triggering workflows from auto-suggested actions to reclaim lost benefits of model-based industrial process controllers
CN110892350B (zh) * 2017-06-12 2023-04-28 霍尼韦尔国际公司 用于识别、可视化和触发来自自动建议动作的工作流以回收基于模型的工业过程控制器的损失利益的装置和方法
CN109960495B (zh) * 2017-12-25 2022-04-15 紫石能源有限公司 一种设备控制处理方法及装置
AT521649B1 (de) * 2018-09-11 2020-08-15 Gerd Huebscher Verfahren zur Ermittlung von Prozessabläufen
US11604459B2 (en) 2019-07-12 2023-03-14 Emerson Process Management Power & Water Solutions, Inc. Real-time control using directed predictive simulation within a control system of a process plant
US11424865B2 (en) 2020-12-10 2022-08-23 Fisher-Rosemount Systems, Inc. Variable-level integrity checks for communications in process control environments

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0405829A2 (de) * 1989-06-30 1991-01-02 AT&T Corp. Objektorientierte Softwaresystembauweise
US5469361A (en) * 1991-08-08 1995-11-21 The Board Of Regents Acting For And On Behalf Of The University Of Michigan Generic cell controlling method and apparatus for computer integrated manufacturing system
EP0767424A2 (de) * 1995-10-02 1997-04-09 International Business Machines Corporation Prozessor mit vom kompilierer zugewiesener Zwischenspeicherung variabler Länge
US5727128A (en) * 1996-05-08 1998-03-10 Fisher-Rosemount Systems, Inc. System and method for automatically determining a set of variables for use in creating a process model
WO1998013737A1 (en) * 1996-09-24 1998-04-02 Honeywell Inc. Systems and methods for providing dynamic data referencing in a generic data exchange environment
DE19737658A1 (de) * 1996-10-18 1998-07-23 Nat Semiconductor Corp Befehlsdecoder für einen Mikroprozessor
EP0860773A1 (de) * 1997-02-21 1998-08-26 Alcatel Verfahren zur Erzeugung eines Rechnerprogrammes
US5828851A (en) * 1996-04-12 1998-10-27 Fisher-Rosemount Systems, Inc. Process control system using standard protocol control of standard devices and nonstandard devices
DE19838469A1 (de) * 1998-08-25 2000-03-02 Abb Research Ltd Prozeßsteuer- und Regelsystem mit verteilter Verarbeitung
DE10021698A1 (de) * 1999-05-06 2001-03-08 Fisher Rosemount Systems Inc Auf einem einzelnen Computer realisierte integrierende Funktionalität für ein verteiltes Prozessregelsystem

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4115853A (en) 1976-12-21 1978-09-19 Allen-Bradley Company Jump structure for a digital control system
DE3419559A1 (de) 1984-05-25 1985-11-28 Robert Bosch Gmbh, 7000 Stuttgart Steuervorrichtung fuer funktionen im kraftfahrzeug
US5892934A (en) 1996-04-02 1999-04-06 Advanced Micro Devices, Inc. Microprocessor configured to detect a branch to a DSP routine and to direct a DSP to execute said routine
US5838563A (en) 1996-04-12 1998-11-17 Fisher-Rosemont Systems, Inc. System for configuring a process control environment
US5768119A (en) 1996-04-12 1998-06-16 Fisher-Rosemount Systems, Inc. Process control system including alarm priority adjustment
US5801942A (en) 1996-04-12 1998-09-01 Fisher-Rosemount Systems, Inc. Process control system user interface including selection of multiple control languages
JPH11134010A (ja) * 1997-10-27 1999-05-21 Honda Motor Co Ltd プログラマブルコントローラにおけるプログラム実行方法
US5950006A (en) * 1997-11-05 1999-09-07 Control Technology Corporation Object-oriented programmable controller

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0405829A2 (de) * 1989-06-30 1991-01-02 AT&T Corp. Objektorientierte Softwaresystembauweise
US5469361A (en) * 1991-08-08 1995-11-21 The Board Of Regents Acting For And On Behalf Of The University Of Michigan Generic cell controlling method and apparatus for computer integrated manufacturing system
EP0767424A2 (de) * 1995-10-02 1997-04-09 International Business Machines Corporation Prozessor mit vom kompilierer zugewiesener Zwischenspeicherung variabler Länge
US5828851A (en) * 1996-04-12 1998-10-27 Fisher-Rosemount Systems, Inc. Process control system using standard protocol control of standard devices and nonstandard devices
US5727128A (en) * 1996-05-08 1998-03-10 Fisher-Rosemount Systems, Inc. System and method for automatically determining a set of variables for use in creating a process model
WO1998013737A1 (en) * 1996-09-24 1998-04-02 Honeywell Inc. Systems and methods for providing dynamic data referencing in a generic data exchange environment
DE19737658A1 (de) * 1996-10-18 1998-07-23 Nat Semiconductor Corp Befehlsdecoder für einen Mikroprozessor
EP0860773A1 (de) * 1997-02-21 1998-08-26 Alcatel Verfahren zur Erzeugung eines Rechnerprogrammes
DE19838469A1 (de) * 1998-08-25 2000-03-02 Abb Research Ltd Prozeßsteuer- und Regelsystem mit verteilter Verarbeitung
DE10021698A1 (de) * 1999-05-06 2001-03-08 Fisher Rosemount Systems Inc Auf einem einzelnen Computer realisierte integrierende Funktionalität für ein verteiltes Prozessregelsystem

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9046881B2 (en) 2002-10-22 2015-06-02 Fisher-Rosemount Systems, Inc. Updating and utilizing dynamic process simulation in an operating process environment
US9069344B2 (en) 2002-10-22 2015-06-30 Fisher-Rosemount Systems, Inc. Smart process modules and objects in process plants
US9904268B2 (en) 2002-10-22 2018-02-27 Fisher-Rosemount Systems, Inc. Updating and utilizing dynamic process simulation in an operating process environment
US9904263B2 (en) 2002-10-22 2018-02-27 Fisher-Rosemount Systems, Inc. Smart process objects used in a process plant modeling system
US9983559B2 (en) 2002-10-22 2018-05-29 Fisher-Rosemount Systems, Inc. Updating and utilizing dynamic process simulation in an operating process environment
US10878140B2 (en) 2016-07-27 2020-12-29 Emerson Process Management Power & Water Solutions, Inc. Plant builder system with integrated simulation and control system configuration
US11418969B2 (en) 2021-01-15 2022-08-16 Fisher-Rosemount Systems, Inc. Suggestive device connectivity planning

Also Published As

Publication number Publication date
JP4707792B2 (ja) 2011-06-22
US6385496B1 (en) 2002-05-07
JP2000311004A (ja) 2000-11-07
GB0001437D0 (en) 2000-03-08
GB2348020B (en) 2003-12-24
GB2348020A (en) 2000-09-20
DE10011661A1 (de) 2000-09-14

Similar Documents

Publication Publication Date Title
DE10011661B4 (de) Prozeßsteuersystem mit Prozeßsteuerroutinen unter Verwendung von indirekter Referenzierung
DE10049025B4 (de) Prozesssteuersystem, Verfahren zur Konfiguration eines Prozesssteuersystems
DE19940078B4 (de) Verteiltes Stapelverarbeitungssystem und Verfahren
DE102004025877A1 (de) Stapelausführungsmaschine mit unabhängigen Stapelausführungsprozessen
DE112004001716B4 (de) Verfahren zur Freigabe von Softwareobjekten zur Verwendung in einem sicherheitsgerichteten System und Freigabesystem für Softwareobjekte zur Verwendung in einem Prozesssteuersystem mit einem Prozessor
DE10335116B4 (de) Integrierte elektronische Authentifizierung für die Freigabe von Softwareobjekten für ein Prozesssteuerungssystem
DE10031671A1 (de) Dynamische Einheitsauswahl in einem Prozessregelsystem
DE102004007435A1 (de) Modulklassenobjekte in einem Prozessanlagenkonfigurierungssystem
DE10147115B4 (de) Verwendung von entfernt gelegenen Softphasen in einem Prozeßsteuerungssystem
DE102004038808A1 (de) Versionskontrolle für Objekte in einem Konfigurationssystem für Prozessanlagen
DE102007046572A1 (de) Flexible Eingabe-/Ausgabegeräte zur Verwendung in Prozesssteuerungssystemen
DE102007046642A1 (de) Verfahren und Modulklassenobjekte zur Konfiguration von fehlenden Einrichtungen in verfahrenstechnischen Anlagen
DE102004038807A1 (de) Sicherheit für Objekte in einem Konfigurationssystem für Prozessanlagen
DE10316217A1 (de) Individuelle Funktionsblöcke zur Verwendung in einem Prozesssteuerungssystem
DE102007046965A1 (de) Dynamische Modifikationsfunktionsblöcke zur Verwendung in einem Prozesssteuerungssystem
DE60209631T2 (de) Verfahren zur Programmierung einer Automatisierungsapplikation
DE102006062478B4 (de) Verfahren zum Betreiben eines objektbasierten Konfigurationssystems für Feldgeräte der Automatisierungstechnik
EP1638028A2 (de) Rechnergestützte Erzeugung und Änderungsmanagement für Bedienoberflächen
EP2407842A2 (de) Verfahren zur Inbetriebnahme von Maschinen oder Maschinen einer Maschinenserie und Projektierungssystem
EP1634130B1 (de) Vorrichtung und verfahren zur programmierung und/oder ausführung von programmen für industrielle automatisierungssysteme
DE10147050B4 (de) Bedienersperre in Steuersystemen von Batchprozessen
DE10208530A1 (de) Betriebseinheit, Peripheriegerät und Verfahren zum Betrieb eines Peripheriegeräts
BE1026842B1 (de) Integration mehrerer Anlagenmodule mit jeweils wenigstens einer prozesstechnischen Einheit zu einer modular aufgebauten Gesamtanlage
EP0860758B1 (de) Einrichtung zur Programmierung einer SPS
DE4212370C2 (de) Automatisierungsverfahren für eine verfahrenstechnische Anlage mit einem &#34;Wegenetz&#34;, Automatisierungsgerät zur Durchführung des Verfahrens und bevorzugte Verwendungen desselben

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
R018 Grant decision by examination section/examining division
R130 Divisional application to

Ref document number: 10066479

Country of ref document: DE

Effective date: 20110412

R020 Patent grant now final

Effective date: 20111216

R071 Expiry of right