-
Die vorliegende Erfindung betrifft ein Stapelverarbeitungssystem und ein Verfahren zur Steuerung eines Stapelprozesses.
-
Stapelverarbeitung
-
Es existieren viele Typen von industriellen Prozessen. Einige laufen fortwährend, bis sie angehalten werden, wobei in typischer Weise sehr große Mengen an Produkten zwischen dem Start und dem Abstellen erzeugt werden. Andere industrielle Prozesse arbeiten an Gruppen von Teilen, wobei die Gruppe sich als eine Einheit zwischen Workstations bewegt, wobei jedoch jeder Teil eine eigene einzigartige Identität beibehält.
-
Ein dritter Typ eines Industrieprozesses ist der Stapelprozeß, der das Unterwerfen von Rohmaterialien unter Verarbeitungsschritten involviert, und zwar unter Verwendung von einem oder mehreren Teilen der Ausrüstung, um einen ”Stapel” (”batch”) des Produkts zu erzeugen. Kochen ist ein Beispiel eines Stapelprozesses, der zu Hause praktiziert wird. Es wird ein rohes Nahrungsmittel vorbereitet, in eine Pfanne gelegt, für eine vorbestimmte Zeitdauer gekocht oder gebacken, die durch ein Rezept spezifiziert ist, und endet dann als ein Gericht oder ”Stapel”, der zum Essen bereit ist.
-
Die Herstellung von Polyvinylchlorid ist ein Beispiel, welches in einem industriellen Maßstab praktiziert wird. Polyvinylchlorid wird dadurch hergestellt, indem sehr viel kleinere Moleküle des Vinylchlorids polymerisiert oder ”aneinandergefügt” werden. Dies wird dadurch erreicht, indem ein Beschickungsreaktor bis zu einer geeigneten Höhe mit einer Mischung aus Vinylchlorid, einem Lösungsmittel und einem Polymerisationsinduzierer gefüllt wird, die Mischung dann in dem Reaktor erhitzt wird und die resultierende Füllung abgekühlt wird, die Füllung oder Charge gereinigt wird, indem verbliebene Ausgangsmaterialien entfernt werden.
-
Dies sind lediglich ein paar Beispiele von Stapelprozessen. Im Allgemeinen gibt es sehr viele unterschiedliche Arten von Stapelprozessen. Diese können beispielsweise die Produktherstellung, Verteilung und Testen als auch verschiedene andere Produkt- und nicht-produktorientierte Prozesse umfassen.
-
Stapelprozeßsteuerung
-
Allgemein gesagt, ist es wichtig, einen Stapelprozeß zu steuern. In Verbindung mit einem Beispiel wird beispielsweise ein Gericht, welches zu lange während des Kochens oder Backens auf dem Ofen belassen wurde, verbrennen und die resultierende Füllung oder Nahrungsmitteleinsatz wird ruiniert. Wenn gemäß einem anderen Beispiel eine Reaktionsmischung aus Vinylchlorid nicht ausreichend lang einer Reaktion unterzogen wird, ist die Ausbeute des Vinylchlorids aus einem Prozeß ungenügend und es wird Geld verloren. Die Steuerung eines Stapelprozesses kann dort kritisch werden, wo ein Produkt aus gefährlichen chemischen Stoffen oder vergleichbaren Größen involviert ist.
-
Ein Weg, einen Stapelprozeß zu steuern, ist die Handsteuerung. Das heißt, ein oder mehrere Arbeiter erhalten den Auftrag, alle Aspekte des Stapelprozesses zu beobachten, um sicher zu sein, daß alles nach Plan verläuft. Dies ist jedoch eine mühsame Aufgabe und es können sich Fehler unbemerkt einschleichen.
-
Aus diesen und anderen Gründen haben Arbeiter auf dem Gebiet der Stapelsteuerung für einige Zeit versucht, die Steuerung der Stapelbearbeitungen durch Verwendung elektronischer Vorrichtungen zu automatisieren. Computer, programmierbare Kontroller und vergleichbare elektronische Vorrichtungen wurden in Verbindung mit intelligenten Bereichsvorrichtungen verwendet (das heißt intelligenten Sensoren und steuerbaren Ventilen), und zwar durch eine Anzahl von Stapelsteuersystemzulieferern, um die Steuerung der Stapelprozesse zu automatisieren.
-
Es wird ein intelligenter Sensor in typischer Weise an einem Teil der Ausrüstung plaziert und berichtet über die Ausrüstungsbedingungen oder Zustände zu einem zentralen Steuerraum in der Anlage. Ein steuerbares Ventil steuert in typischer Weise die Eingabe zu, die Ausgabe von einem Teil der Ausrüstung und kann von einem zentralen Steuerraum aus gesteuert werden, und zwar häufig basierend auf Informationen, die von einem intelligenten Sensor empfangen wurden.
-
Anstrengungen in bezug auf die automatische Stapelverarbeitung haben zur Entstehung von Standardkomitees durch Mitglieder der Industrien geführt, die in der Stapelverarbeitung involviert sind und auch durch Zulieferer einer Stapelverarbeitungsausrüstung unter anderen. Der allgemeine Zweck dieser Standardkomitees bestand darin, einheitliche Standards für die automatisierte Stapelverarbeitung festzulegen.
-
Ein solcher Standard wurde durch die Internationale Gesellschaft für Messung und Steuerung vorgeschlagen, einer internationalen Organisation, die sich mit Herausgaben betreffend die Prozeßsteuerungen befaßt. Dieser Standard trägt den Titel ”Batch Control Part 1: Models and Terminology” (Modelle und Terminologie) und wird häufig als der ISA S88.01-1995-Standard bezeichnet (oder als ”S88” zum Zwecke dieser Anmeldung).
-
Der S88.01-Standard definiert Modelle der Ausrüstung und Prozeduren für die Verwendung in automatisierten Stapelprozessen als auch die Terminologie für die Verwendung einer Bezugnahme auf solche Modelle und deren Elemente. Der S88.01-Standard definiert einen ”Stapelprozeß” als einen Prozeß, der zu dem Produkt führt, und zwar gemäß endlicher Mengen des Materials, indem Mengen von Eingabematerialien einem geregelten Satz von Verarbeitungsaktivitäten unterworfen werden, und zwar über eine endliche Zeitdauer hinweg, unter Verwendung von einem oder mehreren Teilen der Ausrüstung. Eine ”Füllung” (”batch”) ist als das Material definiert, welches herzustellen ist, oder durch eine einzelne Ausführung eines Füllprozesses (batch process) hergestellt wurde.
-
Prozedurmodell
-
Eine Füllungs- oder Charge-Herstellungsausrüstung (das heißt ein steuerbares Element, wie beispielsweise Ventile, Heizvorrichtungen, Mischvorrichtungen usw.) wird gemäß den Prozeduren zur Herstellung einer Füllung oder Charge (batch) betrieben. Zum Zwecke der vorliegenden Anmeldung wird jegliche solche Ausrüstung synonym als Ausrüstung, Ausrüstungsmodul, Verarbeitungsausrüstung oder physikalisches Element bezeichnet. Die Prozeduren, um solche physikalischen Elemente zu betreiben, werden häufig durch den S88.01-Standard als das ”Prozedurmodell” bezeichnet. Gemäß dem S88.01-Standard ist das Prozedurmodell als ein hierarchischer Ordnungsverlauf der Prozeduren strukturiert, wobei die höchste Ebene jede der niedrigeren Ebenen umschließt, die nächsthöchste Ebene jede der Ebenen unterhalb dieser umschließt usw. Die Ebenen des S88.01-Prozedurmodells von praktischem Interesse für die vorliegende Anmeldung sind in absteigender Reihenfolge:
- – die ”Prozedur”
- – die ”Einheitsprozedur”
- – die ”Operation”
- – die ”Phase”
-
Der Ausdruck ”Prozedurelement” wird in dieser Anwendung dazu verwendet, um irgendeine Ausführungsform oder Implementierung von irgendwelchen dieser Ebenen des S88.01-Prozedurmodells zu bezeichnen, nicht jedoch solche der ”Prozedur”-Ebene oder irgendeiner anderen einzelnen Ebene des Prozedurmodells.
-
Das Prozedurelement der höchsten Ebene, die hier interessiert, wird als eine Prozedur bezeichnet, die aus einer oder aus mehreren Einheitsprozeduren aufgebaut ist. Jede Einheitsprozedur ist ihrerseits wieder aus einer oder aus mehreren Operationen hergestellt, die jeweils ihrerseits aus einer oder aus mehreren Phasen gebildet sind. Das S88.01-Prozedurmodell schließt die Definition nicht aus oder auch nicht die Verwendung anderer hierarchischer Ebenen, noch erfordert dieses, daß jede Ebene in bestimmten Anwendungen vorhanden sein muß. Vielmehr zielt der Standard darauf ab, ein breites standardisiertes Modell zum Beschreiben der Prozeduren zu schaffen, die bei der automatisierten Stapelprozeßsteuerung verfolgt werden.
-
8 greift grafisch die hierarchische Beziehung der Prozedurelemente heraus, die durch die S88.01-Standards definiert sind. Eine Prozedur 800 besteht aus einer oder aus mehreren Einheitsprozeduren 802. Jede Einheitsprozedur 802 besteht aus einer oder aus mehreren Operationen 804. Jede Operation 804 umfaßt eine oder mehrere Phasen 806. Wie oben angegeben wurde, steht jede Phase im allgemeinen in Kommunikation mit einer oder mit mehreren Einheiten 820 (eine Sammlung von physikalischen Elementen der Prozeßausrüstung), die kollektiv als eine Prozeßzelle 825 bezeichnet werden, um die gewünschte Steuerung eines Stapelprozesses oder Beschickungsprozesses zu bewirken. Wie ebenfalls oben dargelegt wurde, bilden andere Elemente einer höheren Ebene des Prozedurmodells allgemein Abstraktionen der Elemente niederer Ebene (das heißt Operationen sind Abstraktionen von einer oder mehreren Phasen usw.).
-
Verknüpfung der physikalischen und Prozedurelemente
-
Im allgemeinen werden Prozedurelemente als Computerprogramme implementiert, die durch und innerhalb von datenverarbeitenden Vorrichtungen ausgeführt werden, inklusive Personalcomputern, Workstations und programmierbaren Kontrollern. Die Ausführung eines typischen Prozedurelements führt zu einer elektrischen oder optischen Ausgabe aus der datenverarbeitenden Vorrichtung, die dazu verwendet werden kann, ein physikalisches Element zu steuern, indem in typischer Weise eine Ausgangsgröße der datenverarbeitenden Vorrichtung direkt mit dem physikalischen Element verbunden wird oder direkt über ein örtliches Bereichs- oder weitläufiges Bereichsnetzwerk verbunden wird.
-
Ein Prozedurelement führt den ihm zugewiesenen Auftrag dadurch aus, indem die ”Grundsteuerung” in bezug auf wenigstens ein physikalisches Element aufgerufen wird. Dieser Typ der Steuerung ist dafür prädestiniert, um einen spezifischen gewünschten Zustand des physikalischen Elements herzustellen und aufrechtzuerhalten. Die Grundsteuerung startet beispielsweise oder hält aufrecht eine Strömung des Materials in einem Speicherbehälterelement oder das Erhitzen von Ausgangsmaterialien in einem Polyvinylchlorid-Reaktorelement.
-
In der Praxis führen die niedrigeren Ebenen des Prozedurmodells (nämlich die Phasen) die tatsächlichen Kommunikationen mit den tatsächlichen physikalischen Elementen durch, wobei die Grundsteuerung aufgerufen oder durchgeführt wird. Die höheren Ebenen des Prozedurmodells sind im wesentlichen Abstraktionen, um die Organisation und die Struktur des Prozedurmodells zu verbessern und auch des physikalischen Modells.
-
Prozedurelemente und das Zustandsmaschinenmodell
-
Ein Zustandsmaschinenmodell besteht aus einer logischen Konstruktion, die gemeinsam dazu verwendet wird, um den Zustand eines Prozesses oder einer Aktivität zu beschreiben. Das Modell beschreibt oder definiert eine Anzahl von Prozeßzuständen zusammen mit Aktionen, welche Übergänge zwischen solchen Zuständen verursachen. Ein Zustandsmaschinenmodell eines Prozesses wird somit als ein spezieller Zustand bezeichnet, und zwar entsprechend einem früheren Übergang in diesen Zustand. Wenn ein bestimmtes Ereignis auftritt oder ein bestimmter Status erfaßt wird, führt das Zustandsmaschinenmodell einen Übergang zu einem anderen Zustand durch entsprechend dem bestimmten Ereignis oder erfaßten Status.
-
Ein Zustandsmaschinenmodell bildet eine nützliche Technik, um die Operation eines Prozedurelements eines Stapelprozesses zu definieren und zu implementieren. Ein Prozedurelement, welches als eine Zustandsmaschine definiert und implementiert ist, initialisiert eine Aktion beispielsweise dann, wenn deren zugeordnete Zustandsmaschine einen Übergang von einem alten Zustand in einen neuen Zustand durchführt.
-
Der S88.01-Standard erlaubt die Definition und Implementierung von Prozedurelementen in Einklang mit einem Standardzustandsmaschinenmodell. Während der S88.01-Standard diese Annäherung nicht fordert, wurde dieser doch in weitem Sinn für die Prozeßsteuerindustrie angepaßt, um einen höheren Grad der Inter-Betriebsfähigkeit unter den Produkten verschiedener Vertreiber zu ermöglichen (wie dies im folgenden erläutert wird). Eine momentane wirtschaftliche Anwendung des S88.01-Standards mit Prozedurelementen, die gemäß einem Zustandsmaschinenmodell definiert und implementiert sind, ist das Open-BatchTM-Produkt von PID, Inc. in 2429 West Desert Cove Avenue, Phoenix, Arizona 85029.
-
In dem OpenBatch läuft ein Serverprogramm auf der Datenverarbeitungsvorrichtung, welche die Prozedurelemente ausführt. Das Serverprogramm koordiniert die Ausführung der Prozedurelemente in Einklang mit einem oder mit mehreren Zustandsmaschinenmodellen. Prozeduren, entsprechende Einheitsprozeduren, entsprechende Operationen und entsprechende Phasen werden durch deren jeweilige Schritte durch das Serverprogramm sequentialisiert.
-
Wenn eine Phase durch das Serverprogramm beispielsweise initialisiert wird, so überträgt die Phase die Einleitungsanfrage zu dem logischen Phaseninterface innerhalb eines programmierbaren Kontrollers. Der programmierbare Kontroller führt dann die aktuelle Zustandslogik aus, und zwar für die Phase, und liefert die erforderliche Prozeßsteuerung über Kommunikationen zu der Prozeßausrüstung.
-
6 zeigt eine typische Phasenkommunikation mit einem oder mehreren typischen physikalischen Elementen, wie sie momentan bekannt ist. Die Phase 704 ist innerhalb eines Stapelserverprogramms 702 auf einer Datenverarbeitungsvorrichtung 700 betreibbar. Das Zustandsmaschinenmodell 706 ist innerhalb der Phase 704 betreibbar, um die Operation der Phase in Einklang mit einem Standardzustandsmodell zu steuern. Die Phase 704 kommuniziert mit einem oder mit mehreren programmierbaren Kontrollern 710 über einen Kommunikationspfad 750. Programmierbare Befehle in dem programmierbaren Kontroller 710 erzeugen ein oder mehrere logische Phaseninterfaces 712, und zwar eines für jede Phase, die den programmierbaren Kontroller 710 verwendet.
-
Jedes logische Phaseninterface 712 erzeugt ein aufgezeichnetes Register-Kommunikationsinterface für den Austausch von Informationen mit einer Phase 704. Das aufgezeichnete Register-Kommunikationsinterface, welches weiter unten erläutert wird, enthält eine Anzahl von Registern 718 und einen Plan 720 der Zuordnung der Register. Die Informationen, die über die aufgezeichneten Register 718 ausgetauscht werden, werden durch die Phasenlogik 714 verwendet, um die gewünschten Steuerfunktionen in Zuordnung zu der Zustandsmaschine 706 zu implementieren, die mit der Phase 704 arbeitet. Mit anderen Worten ist die Phasenlogik 714 so konstruiert oder ausgelegt und wird durch den Steueringenieur so implementiert, daß die Operation der Zustandsmaschine in der Datenverarbeitungsvorrichtung gespiegelt wird. Logische Zustandssequenzen 716, die mit der Phasenlogik 714 integriert sind, führen die aktuellen Steuersequenzen durch, die zum Steuern des Stapelprozesses erforderlich sind.
-
Die
DE 197 17 343 A1 zeigt eine Steuervorrichtung mit einer Fernab-PLC-Vorrichtung bei der die Datenübertragung nicht durch die Verarbeitungsleistung der PLC-Berechnungsvorrichtung in der Steuervorrichtung, noch durch die Übertragungsfähigkeit der Kommunikationsleitung begrenzt ist.
-
Die
EP 0 825 506 A2 zeigt ein System für Prozesssteuerung mit einem digitalen Server-Datenprozessor und einem digitalen Client-Datenprozessor, die über ein Netzwerk gekoppelt sind. Der digitale Server-Datenprozessor ist auch noch an einem Gerät zur Steuerung der Prozessausrüstung gekoppelt. Der digitalen Client-Datenprozessor steuert über ein Applet und der Kommunikation über das Netzwerk das Gerät zur Steuerung der Prozess-Ausrüstung, mit Hilfe des digitalen Server-Datenprozessors.
-
Die
DE 41 39 179 A1 zeigt ein Verfahren zur automatischen Steuerung von Chargenprozessen mittels einer Prozesssteuerung bei der Automatikprogramme (Ablaufprogramme für Teilrezepturen od. Phasen) auf Einzelablaufsteuerungen zugreifen. Dabei werden die in den Teilrezepturen oder Phasen des Rezepturprogramms enthaltenen Steueranweisungen und Parameterdefinitionen für die Ansteuerung, Verriegelung und Einschaltsperre von Aktoren im Feld in einer separaten Programmebene gespeichert und die Steueranweisungen und Parameterdefinitionen für jeden anzusteuernden Aktor werden aktorweise zusammengefasst und gegebenenfalls logisch verknüpft.
-
Es ergeben sich Probleme, wenn jeder Hersteller eine unterschiedliche Einrichtung und Verfahren implementiert, um die Abrufinformationen zwischen der Datenverarbeitungsvorrichtung und einem programmierbaren Kontroller zu übertragen. Aufgrund dieser Tatsache können Kommunikationen zwischen einer Phase in der Datenverarbeitungsvorrichtung und dem logischen Phaseninterface in dem programmierbaren Kontroller sehr verschieden von den Kommunikationen sein, die für eine andere Marke von programmierbarem Kontroller erforderlich sind, obwohl beide programmierbaren Kontroller im wesentlichen die gleiche Funktion ausführen.
-
Das Ergebnis besteht darin, daß der eine Prozeßsteuerung konstruierende Ingenieur ein großes Volumen von Anwendersoftware konstruieren, implementieren und aufrechterhalten muß, um die Möglichkeit zu bieten, daß eine bestimmte Phase mit beispielsweise einem Allen-Bradley-programmierbaren Kontroller kommuniziert, und gleichzeitig ein vollkommen getrenntes Volumen von Anwendersoftware konstruieren, implementieren und aufrechterhalten muß, um zu ermöglichen, daß die Phase mit beispielsweise einem programmierbaren Kontroller von Fisher-Rosemount-Systems, Inc. mit der Bezeichnung PROVOX kommunizieren kann. Diese Überlappung einer Bestrebung oder Anstrengung ist uneffizient und vergeudend.
-
Ferner besteht ein gemeinsames Kommunikationsinterface, welches auf dem vorliegenden Gebiet bekannt ist und auf eine Anzahl von Ausrüstungsherstellern zurückgeht, aus einem Registermodell. Das logische Phaseninterface präsentiert sich selbst dem Prozedurelement als ein großer Satz von Registern – lesbaren und/oder beschreibbaren Speicherstellen zum Austausch von Informationen zwischen der Phase innerhalb der Datenverarbeitungsvorrichtung und dem logischen Phaseninterface in dem programmierbaren Kontroller. Die Register sind örtlich durch den Steueringenieur registriert oder aufgezeichnet, und zwar gemäß den erforderlichen Aspekten der Steuerung für eine Phase. Eine Logik, die Funktionen entspricht und durch den Steueringenieur für jedes Register einer Phase definiert wird, ist in dem logischen Phaseninterface des programmierbaren Kontrollers durch den Steueringenieur implementiert. Die Abbildung oder Speicherabbildung der Register, wie sie durch eine bestimmte Phase verwendet werden, wird durch den Steueringenieur aufbewahrt. Obwohl Werkzeuge existieren, um die Dokumentation der Abbildung der Register für eine Phase zu unterstützen, verbleibt die Aufgabe oder Auftrag weitreichend eine manuelle Aufgabe oder Auftrag und unterliegt der Verantwortlichkeit des Steueringenieurs.
-
Wenn sich ein Stapelprozeß ändert und evolviert, muß die Dokumentation für die Registerabbildung oder Aufzeichnung aufrechterhalten werden und erneuert werden – also ein anderer hauptsächlich von Hand ausführbarer Prozeß für den Steueringenieur. Ferner verwendet dort, wo eine Vielzahl von Phasen in einem Stapelprozeß auftreten, jede Phase eine Anzahl solcher logisch abgebildeter Register, um die Grundsteuerung für diese Phase zu implementieren. Es ist in Verbindung mit umfangreichen komplexen Stapelprozessen üblich, hunderte, wenn nicht sogar tausende der Phasen zu definieren, die in der Produktion eines Stapels oder Charge involviert sind. Die Aufgabe oder Auftrag, eine verwendbare Aufzeichnungs- oder Abbildungsdokumentation zu erzeugen und beizubehalten, und zwar für jede Phase und die entsprechenden Register, die dazu verwendet werden, Abrufsteuerungen durchzuführen, muß eine entmutigende sein.
-
Es ist beispielsweise für eine Phase in einem programmierbaren Kontroller typisch, angenähert 15 Register zu verwenden, um die erforderlichen Steuersequenzen für eine einzelne Phase zu implementieren. Ein typischer Stapelprozeß kann angenähert 100 Phasen enthalten, um die Verarbeitung eines Stapels durchzuführen. Der Steuer- oder Regelingenieur ist daher dafür verantwortlich, zu Beginn eine Abbildung oder Speicherabbildung zu definieren und beizubehalten, die angenähert 1500 Register beschreibt. Dort, wo mehrere programmierbare Kontroller für einen größeren Stapelprozeß verwendet werden und dort, wo mehr Phasen erforderlich sind, und zwar für komplexere Stapelprozesse, kann die Zahl der Register, die abzubilden sind, sehr stark anwachsen.
-
Ferner müssen Aspekte des Zustandsmaschinenmodells einer Phase zwischen der datenverarbeitenden Vorrichtung, welche die Phase durchführt, und dem programmierbaren Ausrüstungskontroller des entsprechenden Ausrüstungsmoduls übertragen werden. Im Endeffekt müssen Abschnitte des Zustandsmaschinenmodells des Serverprogramms verstanden werden und innerhalb des programmierbaren Kontrollers gespeichert werden. Dies kompliziert weiter den Programmiervorgang und die ingenieurmäßigen Aufgaben, da diese Funktionen häufig nicht gut durch die Prozeßsteuer- oder Regelingenieure verstanden werden. Zusätzlich sind die Steuersprachen, die innerhalb der meisten programmierbaren Kontroller implementiert werden, im allgemeinen nicht gut für die Implementierung der Zustandsmaschinenlogik geeignet und sie sind im allgemeinen nicht zwischen programmierbaren Kontrollern, die von verschiedenen Herstellern entwickelt werden, transportierbar. Obwohl einige der Programmbefehle zum Nachvollziehen des Zustandsmaschinenmodells dazu kopiert werden können, um die Steuerlogik für jede Phase zu implementieren, benötigen die abgerufenen Kodesequenzen noch einen Test. Jede der Befehlssequenzen erfordert einen detaillierten Test, um einen sicheren Betrieb des Stapelprozesses in jedem Zustand für jede Phase sicherzustellen, die in dem logischen programmierbaren Kontroller implementiert ist.
-
Es ergeben sich noch weitere Probleme in der gegenwärtigen Technik dahingehend, daß dann, wenn ein Fehler in der Verarbeitung einer Phase auftritt, es keine Standardtechniken gibt, um geeignete Fehlerverarbeitungsinformationen zwischen der datenverarbeitenden Vorrichtung, welche die Phase durchführt, und dem programmierbaren Kontroller, der die abgerufene Grundsteuerung durchführt, auszutauschen. Vielmehr war auch hier der Steuer- oder Regelingenieur für die Konstruktion und Aufrechterhaltung eines einzigartigen Fehlerverabeitungsverfahrens und zugeordneter Programmbefehle und Kommunikationspfade verantwortlich, um die Steuerinformationen hinsichtlich des Fehlers auszutauschen.
-
Bei den herkömmlichen Techniken ergibt sich noch ein anderes Problem dort, wo die Verarbeitung einer Phase die Verarbeitung innerhalb einer Nicht-Standard-Vorrichtung erfordert. Beispielsweise kann eine Phase bestimmte Formen der Anwender(Betreiber-)Eingaben erfordern, um deren Phasenverarbeitung durchzuführen. Die Aufrufeingangsgröße kann von einer Anwendereingabevorrichtung, wie beispielsweise einem Keyboard, einer Anzeige oder einem Strichkodeleser erhalten werden. Solche Vorrichtungen verwenden im allgemeinen nicht Registermodellkommunikationsstandards, die gemeinsam beim Austauschen von Informationen zwischen einer Phase in einer datenverarbeitenden Vorrichtung und einem logischen Phaseninterface des programmierbaren Kontrollers ausgetauscht werden. Gegenwärtige Techniken erfordern daher noch eine andere Form der Kommunikation und der Verarbeitung in Verbindung mit der Phase, um solch eine Phasenverarbeitung zu implementieren.
-
Es ergibt sich, daß ein Bedarf nach einem verbesserten Verfahren und Vorrichtung für die Kommunikation von Phasensteuerinformationen und zur sichereren Programmierung der Vorrichtung existiert.
-
Diese Aufgabe wird durch die Vorrichtung nach Anspruch 1 und das Verfahren nach Anspruch 6 gelöst.
-
Insbesondere löst die vorliegende Erfindung die oben angegebenen und weitere Probleme, um dadurch den nutzbaren Stand der Technik voranzubringen, indem die Verfahren und Struktur geschaffen werden, um ein Interface zwischen einem Prozedurelement (einer Phase) in der datenverarbeitenden Vorrichtung und der Phasenlogik zu standardisieren, die in dem programmierbaren Kontroller ausgeführt wird. Spezifischer gesagt, schaffen die Verfahren und die Struktur der vorliegenden Erfindung den Betrieb für die physikalischen Elemente in Einklang mit einem Zustandsmaschinenmodell, welches parallel mit demjenigen der Phase und im wesentlichen identisch mit demjenigen der Phase ist, die in der datenverarbeitenden Vorrichtung betreibbar oder abarbeitbar ist.
-
Der Phasenlogikmodul (PLM) implementiert das Zustandsmaschinenmodell innerhalb eines programmierbaren Kontrollers. Dieser PLM erzeugt ein konsistentes Interface zwischen der Phase in der datenverarbeitenden Vorrichtung der Phasenlogik in dem programmierbaren Kontroller. Ferner verwendet das Kommunikationsinterface zwischen der Phase und dem PLM eine objektorientierte Softwarekonstruktion, wodurch die Phase und der PLM durch den Namen und/oder die ID zugeordnet sind. Es werden Attribute des PLM-Objekts dazu verwendet, um Abrufsteuerinformationen zwischen der Phase und dem PLM zu übertragen. Einzelheiten des Kommunikationsprotokolls werden im folgenden festgehalten. Dieser Aspekt der vorliegenden Erfindung eliminiert die Forderung, daß ein Steuer- oder Regelingenieur zu Beginn eine Registerabbildung (register map) definiert und aufrechterhält, die eine potentiell große Anzahl von Registern für jede einer potentiell großen Anzahl von Phasen in einem Stapelprozeß beschreibt.
-
Der PLM innerhalb des programmierbaren Kontrollers enthält eine Zustandsmaschine, die das Zustandsmaschinenmodell der Phase in die datenverarbeitende Vorrichtung spiegelt. Der Steuer- oder Regelingenieur braucht daher nicht wiederholt programmierte Befehle in den programmierbaren Kontroller implementieren, um die momentanen Zustandsmaschineninformationen zu verfolgen, die durch die Phase in der datenverarbeitenden Vorrichtung erzeugt werden. Vielmehr werden diese Befehle einmal im voraus bei der Systemkonstruktion des Steueringenieurs implementiert, und zwar in einer standardisierten Weise, und werden lediglich für jeden PLM abgerufen, entsprechend einer Phase.
-
Bedeutsamer ist, daß der Steueringenieur keine spezifische Logik mehr zu entwickeln braucht, um die Zustandsmaschinensequenz des Serverprogramms zu spiegeln. Vielmehr ist der Zustandsmaschinenaspekt des PLM vorbestimmt und feststehend und braucht nicht implementiert zu werden noch voll durch den Steueringenieur verstanden zu werden. Vielmehr konstruiert der Steuer- oder Regelingenieur lediglich die Abrufsteuersequenz, die zum Steuern des Stapelprozesses erforderlich ist, und zwar für jeden Übergang zwischen den Zuständen in dem Standardzustandsmaschinenmodell. Solche Steuersequenzen werden in typischer Weise unter Verwendung von sequentiellen Funktionsplänen oder Grafikdarstellungen (SFCs), einer Kontaktlogik (ladder logic) strukturiertem Text oder anderen Werkzeugen und Techniken, die den Steueringenieuren gut bekannt sind, konstruiert.
-
Der standardisierte Abschnitt des PLM, der das Zustandsmaschinenmodell implementiert, wird nicht für jeden PLM reproduziert. Vielmehr ist das einzelne Standardzustandsmaschinenmodell auf einer Vielzahl von Objekten lauffähig, von denen jedes die spezifische Verarbeitung repräsentiert, die für einen bestimmten Zustand einer bestimmten Phase erforderlich ist. Die Testanforderungen für die Stapelprozesse, die in Einklang mit der vorliegenden Erfindung implementiert werden, sind daher aufgrund der Reduzierung der Programminstruktionen oder Programmbefehle reduziert. Die Programminstruktionen oder Programmbefehle, welche die Zustandsmaschine implementieren, sind als ein Standardmodul konstruiert und implementiert, die nicht für jeden seiner Betriebspunkte oder Betriebsmomente verifiziert werden müssen.
-
Die Phase, die in der datenverarbeitenden Vorrichtung durch ein Serverprogramm lauffähig ist, kommuniziert mit dem PLM unter Verwendung eines Protokolls einer hohen Ebene, welches die Prozedurelementverarbeitung beschreibt. Die Zustandsübergänge und andere Parameter, die den Stapelprozeß betreffen, die normalerweise für das Prozedurelement vorgesehen werden, und zwar durch die höheren Ebenen des Prozedurmodells, so wie in dem Serverprogramm implementiert, werden im wesentlichen in ihrer Gesamtheit zu dem physikalischen Element hin übertragen.
-
Ein Aspekt der vorliegenden Erfindung erlaubt die Implementierung der PLMs, die in Einklang mit einer Zustandsmaschine zum Implementieren der Phasenverarbeitung in Vorrichtungen, anders als den programmierbaren Kontrollern, lauffähig sind (das heißt Anwenderinteraktionsphasen, wie oben angegeben). Solche Phasen werden hier als ”Softphasen” bezeichnet und ein PLM, der hier als ein ”Soft-PLM” bezeichnet wird, arbeitet in einer ähnlichen Weise zu derjenigen, die oben beschrieben ist und innerhalb der Vorrichtung liegt. Ein Soft-PLM ist in Einklang mit einer Zustandsmaschine lauffähig oder betreibbar, im wesentlichen identisch derjenigen der Serverprogrammprozedurelemente. Wie im Falle von Hart-PLMs (die in einem programmierbaren Kontroller arbeiten können), tauschen Soft-PLMs die Zustandsübergänge und andere Parameter mit dem Serverprogramm aus.
-
Spezifischer ausgedrückt, arbeiten sowohl die Hard- als auch Soft-PLMs in Einklang mit einer Zustandsmaschine, die im wesentlichen identisch mit derjenigen ist, die in den Prozedurelementen des Serverprogramms implementiert ist. Ferner kommunizieren die PLMs gemäß der vorliegenden Erfindung mit Prozedurelementen in dem Server in einer einfacheren Weise, verglichen mit dem Registermodell herkömmlicher Techniken. Ein Stapelsteueringenieur konstruiert Anwendermodule, welche die gewünschte Grundsteuerung innerhalb des PLM für jeden der Standardbetriebszustände implementieren. Die Standardzustandsmaschine selbst und der Ingenieur (Anwender) führt Elemente zu, welche die gewünschten Steueraufträge bewirken, und diese umfassen in Kombination die PLM und sind innerhalb eines programmierbaren Kontrollers oder innerhalb einer datenverarbeitenden Vorrichtung betreibbar, welche die Soft-PLM implementiert. Alle erforderlichen Zustands- und Parameterinformationen, die zum Bewirken der gewünschten Verarbeitung erforderlich sind, werden über Nachrichtenverbindungen mit dem Serverprogramm empfangen.
-
Die oben angegebenen und weitere Ziele, Aspekte und Merkmale und auch Vorteile der vorliegenden Erfindung ergeben sich aus der folgenden Beschreibung und den anhängenden Zeichnungen.
-
1 ist ein Blockschaltbild, welches die Grundsteuerbeziehung zwischen einer einzelnen Phase und einem Ausrüstungsmodul gemäß der vorliegenden Erfindung veranschaulicht, wobei ein eingebetteter PLM in Einklang mit einer Zustandsmaschine betreibbar ist.
-
2 ist eine Zustandsmaschinendiagramm, welches den Betrieb eines Prozedursteuerelements in Einklang mit den S88.01-Standards beschreibt und in Einklang mit dem momentan bekannten besten Modus zur praktischen Ausführung der Erfindung steht.
-
3 ist ein Blockschaltbild, welches ein Zustandsmaschinenmodell gemäß einem Stapelserverprogramm herausgreift, und zwar in Kommunikation mit einem Zustandsmaschinenmodell, welches in einem PLM innerhalb eines programmierbaren Kontrollers betreibbar ist.
-
4 ist ein Blockschaltbild, welches die Konstruktion eines PLM zeigt, wie in 3 veranschaulicht, wobei die von dem Anwender hinzugefügten Elemente dazu vorgesehen sind, um die Logik innerhalb jedes der Standardzustände des Zustandsmaschinenmodells zu implementieren.
-
5 ist ein Ausschnitt eines typischen sequentiellen Funktionsplans, wie dieser dazu verwendet werden kann, um dem Anwender zugeführte Zustandslogik in dem PLM zu beschreiben, wie in 4 gezeigt ist.
-
6 ist ein Blockschaltbild, welches die Grundsteuerbeziehung zwischen einer einzelnen Phase und einer Softphase in Einklang mit der vorliegenden Erfindung zeigt, wobei ein eingebetteter PLM in Einklang mit einer Zustandsmaschine betreibbar ist.
-
7 ist ein Blockschaltbild, welches die Grundsteuerbeziehung zwischen einer einzelnen Phase und einem entsprechenden Ausrüstungsmodul veranschaulicht, wie dies auf dem vorliegenden Gebiet momentan praktiziert wird.
-
8 ist ein Blockschaltbild, welches die hierarchischen Ebenen der Elemente des S88-Prozedurmodells und die hierarchischen Ebenen der Elemente des S88-physikalischen Modells veranschaulicht.
-
Detaillierte Beschreibung der bevorzugten Ausführungsformen
-
Obwohl die Erfindung vielfältigen Modifikationen und alternativen Ausführungsformen zugänglich ist, wurde eine spezifische Ausführungsform der Erfindung anhand eines Beispiels in den Zeichnungen dargestellt und soll hier nun im Detail beschrieben werden. Es sei jedoch darauf hingewiesen, daß nicht beabsichtigt ist, die Erfindung auf die erläuterte bestimmte Form einzuschränken, sondern daß im Gegenteil die Erfindung alle Modifikationen, Äquivalente und Alternativen umfaßt, die in den Rahmen der Erfindung, wie durch die anhängenden Ansprüche definiert, fallen.
-
Verteilte Stapelverarbeitung – Übersicht
-
Eine Übersicht der Erfindung dieser Anwendung ist in den 1 und 6 herausgegriffen. 1 ist ein Blockschaltbild, welches eine Phase 610 (ein Prozedurelement) herausstellt, welches Zustandsinformationen gemäß einer hohen Ebene über den Pfad 660 für den PLM 100 vorsieht, der innerhalb des programmierbaren Kontrollers 103 betreibbar ist. Spezifischer gesagt, ist die Phase 610 in Einklang mit der Zustandsmaschine 170 betreibbar, während der PLM 100 innerhalb des programmierbaren Kontrollers 103 in Einklang mit der Zustandsmaschine 102 betreibbar ist. Wie oben dargestellt ist, ist die Zustandsmaschine 102 im wesentlichen identisch der Zustandsmaschine 170. Die zwei Zustandsmaschinen kommunizieren über den Pfad 660 aufgrund des Austausches von Zustandsinformationen einer hohen Ebene oder Schicht, wie dies auch noch weiter unten beschriebe wird.
-
Verglichen mit den herkömmlichen Techniken, begegnet der PLM 100 von 1 dem Bedarf nach einer umfangreichen Dokumentation, um eine große Anzahl von Registern abzubilden, die für die Kommunikation zwischen früheren Ausrüstungsmodulen und den entsprechenden Phasen verwendet werden. Statt dessen wird eine standardisierte Befehlsstruktur gemäß einer hohen Ebene oder Schicht verwendet und diese wird im folgenden noch in Einzelheiten erläutert.
-
Zusätzlich, verglichen mit den herkömmlichen Techniken, schafft der PLM 100 einen Standard, eine Einzelimplementierung der Zustandsmaschine 102. Die Einzelimplementierung der Zustandsmaschine 102 ist auf einer oder mehreren Zustandslogiksequenzen 716 betreibbar. Mit anderen Worten, arbeitet jeder PLM 100 in Einklang mit einer einzelnen Zustandsmaschine 102. Jeder logische Phasenmodul enthält jedoch eine einmalige Zustandslogiksequenz 716, die durch den Steueringenieur festgelegt wird, um die erforderliche Steuerung für jede Standardzustand einer entsprechenden Phase 610 zu implementieren.
-
Wenn der programmierbare Kontroller 103 unter der Leitung der Zustandsmaschine 102 in dem PLM 100 arbeitet, kommuniziert dieser mit dem programmierbaren Kontroller I/O 675, und zwar über den Pfad 670, der seinerseits mit der Prozeßausrüstung 685 über den Pfad 680 kommuniziert, um die gewünschte Grundsteuerung zu bewirken.
-
Wie oben festgehalten ist, werden die logischen Zustandssequenzen 716 in bevorzugter Weise als sequentielle Funktionsgrafiken (function charts) (SFCs), strukturierter Text, Kettenlogik (ladder logic) oder anderen programmierbaren Kontrollersprachen, wie sie dem Fachmann auf dem vorliegenden Gebiet gut bekannt sind, implementiert. Die einzelne Standardzustandsmaschine 102 innerhalb des PLM 100 arbeitet anstelle von einem oder mehreren logischen Zustandselementen 716, um die Verarbeitung für alle Phasen zu bewirken, die bei dem programmierbaren Kontroller 103 implementiert sind. Dies begegnet der Forderung, eine Vielzahl von ähnlichen noch unabhängigen Implementierungen eines Zustandsmaschinenmodells zu testen, wie dies früher beim Stand der Technik erforderlich war.
-
6 zeigt ein Blockschaltbild, welches eine Phase 610 (ein Prozedurelement) herausgreift, welches Zustandsinformationen einer hohen Ebene über den Pfad 112 zu dem Soft-PLM 106 liefert, der innerhalb der Softphase betreibbar ist. Spezifischer gesagt, ist die Phase 610 in Einklang mit der Zustandsmaschine 170 betreibbar, während der Soft-PLM 106 innerhalb des Datenverarbeitungselements 104 in Einklang mit der Zustandsmaschine 108 betreibbar ist. Wie oben beschrieben ist, ist die Zustandsmaschine 108 im wesentlichen identisch der Zustandsmaschine 170. Die zwei Zustandsmaschinen kommunizieren über den Pfad 112 entsprechend einem Austausch von Zustandsinformationen einer hohen Ebene, wie dies im folgenden näher beschrieben wird.
-
Wie oben unter Hinweis auf 1 dargelegt wurde, schafft der Soft-PLM 106 der 6 eine einzelne Standardimplementierung der Zustandsmaschine 108. Die Einzelimplementierung der Zustandsmaschine 108 ist auf einer logischen Zustandssequenz 716, die einmalig für jeden Soft-PLM 106 ist, betreibbar. Bei der datenverarbeitenden Vorrichtung 104 von 6 sind die logischen Zustandssequenzen 716 in bevorzugter Weise als Standard-Softwareelemente implementiert, wie dies dem Fachmann auf dem vorliegenden Gebiet gut bekannt ist. Die einzelne Standardzustandsmaschine 108 innerhalb jedes Soft-PLM 106 arbeitet in Einklang mit den logischen Zustandselementen 716, um die Verarbeitung von allen Phasen zu bewirken, die mit der datenverarbeitenden Vorrichtung 104 implementiert sind. Dies begegnet der Forderung, eine Vielzahl von ähnlichen noch unabhängigen Implementationen eines Zustandsmaschinenmodells zu testen, wie dies beim Stand der Technik früher bekannt war. Die Datenverarbeitungsvorrichtung 104 kommuniziert dann mit den datenverarbeitenden Eingangs-/Ausgangsvorrichtungen 322 über den Pfad 360, um die Verarbeitung zu bewirken, die durch den Soft-PLM 106 gefordert wird.
-
3 greift ein exemplarisches System 300 heraus, welches in Einklang mit den Lehren der vorliegenden Erfindung betreibbar ist, um eine Stapelsteuerung durchzuführen. Der Prozeßingenieur oder andere Anwender initialisiert die Verarbeitung des Stapels von einer datenverarbeitenden Vorrichtung 324 aus, und zwar durch interaktive Aktion mit einem Stapel-Clientprogramm 304. Das Stapel-Clientprogramm 304 bildet ein geeignetes Anwenderinterface, welches (das heißt ein grafisches Anwenderinterface oder GUI) dem Anwender die Möglichkeit schafft, die Verarbeitung für einen Stapel zu initialisieren und die Verarbeitung des Stapels bis hin zu Vervollständigung zu steuern.
-
Das Stapel-Clientprogramm 304 kommuniziert mit einem Stapelserverprogramm 306 über einen Inter-Prozeßkommunikationspfad 356. Das Stapelserverprogramm 306 ist auf der datenverarbeitenden Vorrichtung 302 betreibbar oder lauffähig und ist für das Initialisieren und Überwachen der Prozedurelemente verantwortlich, die für das Erzeugen des Stapels, der von dem Stapel-Clientprogramm 304 angefragt wurde, verantwortlich sind. Wie dies auf dem Gebiet bekannt ist, enthält das Stapelserverprogramm 306 Elemente, die eine oder mehrere Phasen 307 implementieren, um die erforderlichen Verarbeitungsschritte zum Erzeugen des angefragten Stapels zu verarbeiten. Jede Phase 307 ist in Einklang mit einer Zustandsmaschine 308 betreibbar. Ferner kann eine Vielzahl von Stapelserverprogrammen 306 innerhalb einer Herstellungsgesellschaft oder eines anderen vernetzten Prozeßsteuerunternehmens verteilt sein. Jedes Stapelserverprogramm 306 kann in solch einer verteilten Umgebung für einen bestimmten untergeordneten Satz von Stapelprozessen oder Stapelherstellungen innerhalb der Gesellschaft verantwortlich sein.
-
Wie in 3 gezeigt ist, kann eine Vielzahl von solchen Stapel-Clientprogrammen 306 auf der datenverarbeitenden Vorrichtung 324 betreibbar sein (auch allgemein als eine Workstation oder Personalcomputer oder einfach Computer genannt). Auch kann der Fachmann unmittelbar erkennen, daß die Stapel-Clientprogramme 304 auch an anderen entfernten Workstations (nicht gezeigt) betreibbar sind, die über ein gut bekanntes Netzwerk und verteilte Computertechniken kommunizieren. Alternativ können die Stapel-Clientprogramme 304 an einer einzelnen datenverarbeitenden Vorrichtung mit dem Stapelserverprogramm 306 zusammen residieren. Die spezifische Verteilung solcher Client- und Serverprogramme in verteilten Client-/Serveranwendungen ist weitläufig irrelevant, wie der Fachmann auf dem Gebiet weiß, und es sind viele äquivalente Topologien von verteilten Programmen und von datenverarbeitenden Vorrichtungen in Verbindung mit der vorliegenden Erfindung verwendbar.
-
Ein Fachmann kann ferner viele gut bekannte Interprozeßkommunikationstechniken einbeziehen, welche den Pfad 356 verwenden, um Client-/Serverkommunikationen zwischen dem Stapel-Clientprogramm 304 und dem Stapelserverprogramm 306 zu erlauben. Solche Interprozeßkommunikationen sind betreibbar, und zwar ungeachtet der physikalischen Nähe oder Nachbarschaft der Client-/Serverprogramme oder der Netzwerktopologie, auf der die Stapel-Clientprogramme 304 und das Stapelserverprogramm 306 verteilt sind.
-
Verteilte Stapelverarbeitung – logische Phasenmodule
-
Der programmierbare Kontroller 315 erzeugt eine physikalische Steuerung für den Stapelherstellungsprozeß in Einklang mit Prozedurdirektiven, die von dem Stapelserverprogramm 306 empfangen werden, welches innerhalb der Anwenderworkstation 302 lauffähig ist. Gemäß der vorliegenden Erfindung enthält der programmierbare Kontroller 315 einen eingebetteten PLM 316. Ebenfalls gemäß der vorliegenden Erfindung ist der PLM 316 in Einklang mit einer Zustandsmaschine 318 betreibbar oder lauffähig. Speziell ist die Zustandsmaschine 318 im wesentlichen identisch der Zustandsmaschine 308, die innerhalb des Stapelserverprogramms 306 betreibbar ist.
-
Ferner tauscht in Einklang mit der vorliegenden Erfindung die Zustandsmaschine 308 innerhalb des Stapelserverprogramms 306 Zustandsübergangs- und andere Parameterinformationen, welche die Verarbeitung eines Stapels betreffen, mit der Zustandsmaschine 318 über den Pfad 350 aus.
-
Der PLM 316 innerhalb des programmierbaren Kontrollers 315 arbeitet in Einklang mit der Zustandsmaschine 318, um der Forderung zu begegnen, daß Prozeßingenieure umfangreiche Anwenderprogrammierung durchführen müssen oder erzeugen müssen, und zwar lediglich für den Zweck, Zustandsinformationen zu überwachen und zu verfolgen, und zwar in der Ausführung der Grundsteuersequenzen. Vielmehr werden gemäß der vorliegenden Erfindung, wie dies auch unten noch beschrieben wird, logische Zustandsmodule mit dem programmierbare Kontroller 315 integriert, um die gewünschte Grundsteuerung entsprechend der bestimmten Phase innerhalb des PLM 316 durchzuführen. Es werden dann Grundsteuerbefehle einer niedrigeren Ebene zu dem programmierbaren Kontrollerprozeß-I/O 320 über den Pfad 352 und dann zu der Prozeßausrüstung 340 über den Pfad 362 gesendet.
-
Wie in 3 gezeigt ist, kann eine Vielzahl von PLMs 316 innerhalb eines einzelnen programmierbaren Kontrollers 315 eingebettet sein. Jeder einer solchen Vielzahl von PLMs 316 arbeitet in Einklang mit einer Zustandsmaschine 318, die im wesentlichen identisch der Zustandsmaschine 308 innerhalb des Stapelserverprogramms 306 ist. Ferner enthält jeder einer solchen Vielzahl von PLMs 316 von einem Anwender hinzugefügte logische Zustandsmodule, wie dies im folgenden noch beschrieben wird, um spezifische Grundsteuersequenzen für deren jeweiligen Phasen zu implementieren.
-
Bei der momentan bekannten besten Art die Erfindung zu praktizieren, wird der programmierbare Kontroller 315 dafür programmiert, um die Grundsteueraufträge durchzuführen. Die Grundsteueraufträge, die durch den programmierbaren Kontroller 315 durchgeführt werden, sind in Einklang mit den vom Anwender hinzugefügten logischen Zustandselementen mit der Zustandsmaschine 318 in dem PLM 316 integriert. Die Sequenzierung solcher Aufträge erfolgt ebenfalls in Einklang mit der Zustandsmaschine 318 in dem PLM 316.
-
Die Soft-PLMs 310, die auf der datenverarbeitenden Vorrichtung 326 betreibbar sind, sind in ihrer Konstruktion ähnliche den PLMs 316, die innerhalb des programmierbaren Kontrollers 315 betreibbar sind. Sie sind in dem Sinn ähnlich als die Soft-PLMs 310 in Einklang mit der Zustandsmaschine 312 betreibbar sind, die wiederum ihrerseits identisch der Zustandsmaschine 308 des Stapelserverprogramms 306 ist. Die Soft-PLMs 310 unterscheiden sich von den PLMs 316 hinsichtlich des Typs der Funktionen und der Steuerungen, die durch diese ausgeführt werden. Insbesondere schaffen die PLMs 316, wie oben angegeben, eine physikalische Grundsteuerung, welche die physikalischen Eigenschaften und Attribute des Stapelmaterials (Chargenmaterial) und einen Prozeß zur Herstellung desselben betrifft. Im Gegensatz dazu implementieren Soft-PLMs 310 Phasen, die allgemein indirekt auf die physikalischen Eigenschaften in den Attributen des Stapels (Charge) und den zugeordneten Herstellungsprozeß bezogen sind. Ein Beispiel solch einer Soft-Phase ist eine Phase, die eine Anwendereingabe erfährt, um bestimmte Attribute oder Eigenschaften zu bestimmen, die automatisch durch den Stapelsteuerprozeß nicht erhalten oder erzielt werden. Allgemeiner gesagt, sind Soft-Phasen betreibbar, um vom Anwender zugeführte Informationen zu verifizieren und zu sammeln, die den Stapel (Charge) und den Prozeß zur Herstellung desselben betreffen. Soft-PLMs 310 und die jeweiligen eingebetteten Zustandsmaschinen 312 interagieren daher mit der Anwenderinterfaceausrüstung 322 über den Pfad 360 in Einklang mit Befehlen und Parametern, die über den Pfad 358 mit dem Stapelserverprogramm 306 ausgetauscht werden.
-
Der Fachmann auf dem vorliegenden Gebiet erkennt, daß die Soft-PLMs 310 an einer verteilten Computervorrichtung betreibbar sind, die von dem Stapelserver entfernt sind, wie dies in 3 gezeigt ist, oder zusammen mit dem Stapelserverprogramm vorhanden sein können. Gut bekannte Zwischenprozeß-Kommunikationstechniken ermöglichen solch eine Kommunikation ungeachtet der physikalischen Nähe der verschiedenen Prozesse und ungeachtet der Topologie der datenverarbeitenden Vorrichtungen, über die die Prozesse verteilt sein können.
-
Logische Phasenmodulzustandsmaschine
-
2 zeigt ein Zustandsmaschinendiagramm, welches ein bevorzugtes Zustandsmaschinenmodell in Einklang mit der vorliegenden Erfindung beschreibt. Die Zustandsmaschine, die in 1 herausgegriffen ist, steht in Einklang mit der beispielhaften Zustandsmaschine, wie sie durch die ISA S88.01-Standards geschaffen wird. Wie in den ISA S88.01-Spezifikationen aufgeführt ist, ist kein spezielles Zustandsmaschinenmodell aufgrund des Standards erforderlich. Vielmehr wird das Zustandsmaschinenmodell, welches in dem S88.01-Standard beschrieben ist, als ein adäquates Modell zum Beschreiben irgendwelcher nützlicher Stapelprozesse vorgeschlagen. Der Standard erlaubt das Hinzufügen oder Weglassen von Zuständen in dem Modell als auch Übergänge zwischen verschiedenen Zuständen.
-
Wie oben dargelegt ist, ist das Zustandsmaschinenmodell von 2 sowohl innerhalb des Stapelserverprogramms 306 von 3 als auch innerhalb der PLMs 316, die in dem programmierbaren Kontroller 315 eingebettet sind, implementiert und eingebettet, wobei der genannte Kontroller ebenfalls in 3 gezeigt ist. Ferner sind, wie oben erwähnt, die Soft-PLMs 310 (oder 102 von 6) ebenfalls in Einklang mit einer im wesentlichen ähnlichen Zustandsmaschine 312 (oder 108 von 6) betreibbar.
-
Einzelheiten des Betriebes der Zustandsmaschine, die in 2 gezeigt ist, sind in der Zustandsübergangstabelle (Tabelle 1) weiter unten festgehalten. Die Zustandsübergangstabelle listet jeden der Zustände in der Zustandsmaschine in Reihen der Tabelle auf und auch die Befehle, die Übergänge bewirken, in Spalten der Tabelle auf. Die Schnittstellen von jeder Reihe mit jeder Spalte zeigen an, welcher neue Zustand, wenn überhaupt, die Zustandsmaschine erreicht, und zwar nach dem Empfang des entsprechenden Befehls. Dort, wo kein neuer Zustand aufgelistet ist, führt die Zustandsmaschine keinen Übergang zu einem neuen Zustand durch.
-
Im allgemeinen wird das Zustandsmaschinenmodell 200 in dem Leerlaufzustand 202 initialisiert und auf diesen zurückgestellt. Übergänge erfolgen zu anderen Zuständen, basierend auf im allgemeinen Befehlen, die eine vorzunehmende Aktion angeben. Solche Befehle werden von verschiedenen Quellen empfangen, inklusive beispielsweise dem Stapel-Clientprogramm 304 im Falle der Zustandsmaschine 308, die innerhalb des Stapelserverprogramms 306 betreibbar ist. Spezieller gesagt, werden in bezug auf die Zustandsmaschinen 312 und 318, die in Einklang mit der vorliegenden Erfindung innerhalb der PLMs 310 und 316 betreibbar sind, Befehle und andere Parameter über den Pfad 350 von dem Stapelserverprogramm 306 innerhalb der datenverarbeitenden Vorrichtung 302 empfangen.
-
Ein Startbefehl verursacht einen Übergang in den laufenden Zustand 204. In dem laufenden Zustand 204 führt die Zustandslogik, die durch den Anwender zugeführt wurde, geeignete Steuersequenzen einer niedrigeren Ebene (das heißt Grundsteuerung) aus, um zu bewirken, daß das Chargenmaterial in Einklang mit den gewünschten Parametern hergestellt wird. Während des laufenden Zustandes 204 bewirkt ein Abbruchbefehl einen Übergang in einen Abbruchzustand 206 und eventuell den abgebrochenen Zustand 218. In ähnlicher Weise bewirkt ein Stoppbefehl einen Übergang in den Anhaltezustand 208 und eventuell in den angehaltenen Zustand 216. Der Haltebefehl bewirkt einen Übergang in das Halten des Zustandes 220 und eventuell den gehaltenen Zustand 222. Die Vervollständigung der gewünschten Verarbeitung einer Charge in dem laufenden Zustand 204 bewirkt einen Übergang in den Vervollständigungszustand 210.
-
Der Vervollständigungszustand
210, der abgebrochene Zustand
218 und der angehaltene Zustand
216 sind alle Terminalzustände in solcher Weise, daß ein Rückstellbefehl erforderlich ist, um den Übergang zurück in den Leerlaufzustand
202 zu bewirken, gemäß einer Bereitschaft, einen anderen Stapelprozeß zu initialisieren. Der gehaltene Zustand
222 ist ein Zwischenzustand derart, daß das Verarbeiten des Stapels (Charge) fortgeführt werden kann, indem in den laufenden Zustand
204 zurückgekehrt wird. Spezifisch bewirkt ein Wiederstartbefehl aus dem gehaltenen Zustand
222 heraus einen Übergang in den wieder gestarteten Zustand
224 und eventuell in den laufenden Zustand
204.
| | (keine) | START | STOPP | Ausfall /Halten | Wiederstart | Abbruch | Rückstellung |
| Leerlauf | | laufend | | | | | |
| laufend | vervollständigt | | Anhalten | halten | | abbrechen | |
| vervollständigt | | | | | | | Leerlauf |
| halten | gehalten | | Anhalten | | | abbrechen | |
| gehalten | | | anhalten | | wieder starten | abbrechen | |
| wieder starten | laufen | | anhalten | halten | | abbrechen | |
| anhalten | angehalten | | | | | abbrechen | |
| angehalten | | | | | | | Leerlauf |
| Abbrechen | abgebrochen | | | | | | |
| Abgebrochen | | | | | | | Leerlauf |
TABELLE 1
-
In der oben angegebenen Zustandsmaschinentabelle schlagen die ISA S88.01-Standards die folgende semantische Interpretation der Befehle vor, die über dem oberen Ende der Tabelle aufgelistet sind, und zwar als Spalten der Tabelle:
Start – ordnet an, daß das Prozedurelement damit beginnt, die normale laufende Zustandslogik auszuführen.
Stopp – ordnet an, daß das Prozedurelement die Anhaltezustandslogik ausführt.
Ausfall/Halten – ordnet an, daß das Prozedurelement die Haltezustandslogik ausführt.
Wiederstart – ordnet an, daß das Prozedurelement die Wiederstartzustandslogik ausführt, um sicher in den laufenden Zustand zurückzukehren.
Abbruch – ordnet an, daß das Prozedurelement die Abbruchzustandslogik ausführt.
Rückstellung – dieser Befehl bewirkt den Übergang von einem Terminalzustand in den Leerlaufzustand, um die Initialisierung der Verarbeitung eines neuen Stapels (batch) zu erlauben. Es ist keine vom Anwender zugeführte Zustandslogik diesem Befehl oder den zugeordneten Zustandsübergängen zugeordnet.
-
Bei der oben erwähnten Zustandsmaschine der bevorzugten Ausführungsform der vorliegenden Erfindung wurden einige Zustände und Übergänge eliminiert, um das Zustandsmaschinenmodell zu vereinfachen, wobei jedoch trotzdem innerhalb des Rahmens der ISA S88.01-Standards und Vorschläge verblieben wurde. Die semantische Interpretation der Befehle, die verbleiben, ist so, wie sie oben in bezug auf die Tabelle 1 beschrieben ist. Der zusätzliche Ausfallbefehl wird in identischer Weise zu einem Haltebefehl behandelt, wie dies oben festgehalten ist. Ein Ausfallbefehl repräsentiert das Erfassen eines Fehlerzustandes in der Verarbeitung der Stapelphase. Ein Ausfall oder Fehler wird daher in der gleichen Weise behandelt wie eine Anwenderanfrage, die Verarbeitung zu halten, so daß keine weitere Verarbeitung in bezug auf den Prozedur-PLM auftritt, der die Zustandsmaschine implementiert.
-
Jeder Übergang in einen neuen Zustand in der Zustandsmaschine, die innerhalb jedes PLMs implementiert ist, kann bewirken, daß Grundsteueraufträge ausgeführt werden, um die Verarbeitung des Stapels (Charge) fortzusetzen oder zu initialisieren. Vom Anwender zugeführte logische Zustandselemente, die den verschiedenen oben beschriebenen Zuständen zugeordnet sind, definieren die bestimmte Verarbeitung, die auszuführen ist, wenn ein Übergang in den entsprechenden Zustand vorgenommen wird.
-
4 ist ein Blockschaltbild, welches zusätzliche Details der Konstruktion der PLMs 310 und 316 und der Zustandsmaschinen 312 und 318, die darin jeweils eingebettet sind, liefert. Wie oben angegeben wurde, sind die Soft-PLMs 310 und PLMs 316 in der Konstruktion oder Struktur ähnlich, was auch für deren jeweilige Zustandsmaschinen 312 und 318 zutrifft. Wie ferner oben angegeben wurde, implementieren die Zustandsmaschinen 312 und 318 ein Zustandsmaschinenmodell, welches im wesentlichen identisch ist mit der Zustandsmaschine 308 innerhalb des Stapelserverprogramms 306. Die Soft-PLMs 310 tauschen Informationen mit dem Stapelserverprogramm 306 über den Pfad 358 und dem Serverkommunikationselement 400 aus. In ähnlicher Weise kommuniziert der PLM 316 mit dem Stapelserverprogramm 306 über den Pfad 350 und dessen jeweiligem Serverkommunikationselement 400.
-
Das Serverkommunikationselement 400 erzeugt alle notwendigen Kommunikationsprotokolle und Informationen, die für eine Interprozeßkommunikation zwischen den PLM-Zustandsmaschinen 312 und 318 und der Zustandsmaschine 308 innerhalb des Stapelserverprogramms 306 erforderlich sind. Weitere Einzelheiten des spezifischen Protokolls und der kommunikationsbezogenen Informationen werden im folgenden geliefert.
-
Die von dem Stapelserverprogramm 306 über das Serverkommunikationselement 400 empfangenen Informationen werden zu dem Zustandsmaschinensteuerelement 402 übertragen. Das Zustandsmaschinensteuerelement 402 erzeugt eine grundlegende Zustandsmaschinensteuerung und Verarbeitung, um das bevorzugte Zustandsmaschinenmodell zu implementieren, welches oben in bezug auf die Tabelle 1 beschrieben ist. Die vom Anwender zugeführten oder hinzugefügten logischen Zustandsmodule 404 bis 414 liefern die spezifische Phasen-/Zustandsverarbeitung, die bei jedem einer Vielzahl von speziellen Zuständen des Zustandsmaschinenmodells der Tabelle 1 auszuführen ist.
-
Bei der bevorzugten Ausführungsform liefert ein Anwender/Ingenieur einen programmierten Modul, der eine Verarbeitung gemäß einer niederen Ebene durchführt, was erforderlich ist, wenn ein Übergang in einen entsprechenden Zustand durchgeführt wird. Speziell wird ein vom Anwender zugeführter Laufzustandslogikmodul 404 durch die Zustandsmaschinensteuerung oder Steuereinheit 402 ausgeführt, während die Zustandsmaschine sich in dem Laufzustand 204 von 2 befindet bzw. in diesem arbeitet. Ein vom Anwender hinzugefügter Haltezustandslogikmodul 406 wird durch die Zustandsmaschinensteuerung 402 ausgeführt, während sich die Zustandsmaschine in dem Haltezustand 220 befindet bzw. arbeitet. Ein vom Anwender hinzugefügter logischer Wiederstartmodul 408 wird durch die Zustandsmaschinensteuerung 402 ausgeführt, während sich die Zustandsmaschine in dem Wiederstartzustand 224 befindet bzw. in diesem arbeitet. Ein vom Anwender hinzugefügter logischer Stoppmodul 410 wird durch die Zustandsmaschinensteuerung 402 ausgeführt, während sich die Zustandsmaschine in dem Anhaltezustand 208 befindet. Ein vom Anwender hinzugefügter logischer Abbruchmodul 412 wird durch die Zustandssteuerung 402 ausgeführt, während sich die Zustandsmaschine in dem Abbruchzustand 206 befindet. Schließlich wird ein vom Anwender hinzugefügter Fehlerüberwachungslogikmodul 414 durch die Zustandsmaschinensteuerung 402 ausgeführt, während sich die Zustandsmaschine in irgendeinem Zustand befindet bzw. in irgendeinem Zustand arbeitet. Mit anderen Worten ist der Fehlerüberwachungslogikmodul 414 fortlaufend betreibbar oder betriebsfähig, ungeachtet dem momentanen Zustand der Zustandsmaschine 312 oder 319. Der Fehlerüberwachungslogikmodul 414 ist betreibbar, um zu bestimmen, wann ein Fehlerzustand während des Betriebes des jeweiligen PLM 310 oder 316 auftritt.
-
Die logischen Zustandsmodule 404 bis 414 werden durch einen Prozeßkonstruktionsingenieur in Form der Software von anderen programmierbaren Modulen zugeführt. Diese sind in typischer Weise unter Verwendung sequentieller Funktionskarten, einer Kettenlogik (ladder logic), strukturiertem Text oder anderen Werkzeugen und Techniken konstruiert, wie sie den Steueringenieuren bekannt sind. Zusätzlich können irgendeine von mehreren gut bekannten Programmiersprachen inklusive C, C++, Visual C++, Visual Basic, Pascal, Ada usw. dazu verwendet werden, um die anwenderdefinierte Zustandslogik für die Soft-PLMs zu konstruieren.
-
5 greift ein Beispiel eines von einem Anwender hinzugefügten ”Lauf”-Zustandslogikmoduls 404 heraus. 5 zeigt den Laufzustandslogikmodul 404, der in Ausdrücken einer sequentiellen Funktionsabbildung oder Grafik beschrieben ist. Speziell repräsentiert das Element 500 die Verarbeitung, um ein Einlaßventil zu öffnen, während das Element 502 eine Verarbeitung repräsentiert, um auf eine Statusanzeige zu warten, die einen offenen Zustand für das Einlaßventil wiedergibt. Als nächstes repräsentieren die Elemente 504 und 506 die Verarbeitung zum Starten einer Einlaßpumpe und zum Warten auf einen Zustand, der anzeigt, daß die Einlaßpumpe am Laufen ist. Die Elemente 508 und 510 repräsentieren das Verarbeiten, um auf die Vervollständigung des Ladens eines Tanks zu warten, der mit der Einlaßpumpe in Verbindung steht bzw. dieser zugeordnet ist, und zwar bis zum Erreichen eines vorbestimmten Ladungsfüllstandes. Die Elemente 512 und 514 repräsentieren dann die Verarbeitung, um die Einlaßpumpe anzuhalten und auf einen Status zu warten, der den angehaltenen Zustand der Einlaßpumpe anzeigt. Die Elemente 516 und 518 repräsentieren dann das Verarbeiten zum Schließen des Einlaßventils und zum Warten auf einen Zustand, der das erfolgreiche Schließen anzeigt. Schließlich repräsentieren die Elemente 520 und 522 die Verarbeitung, um die sequentielle Funktionsabbildung oder Grafik dadurch zu vervollständigen, indem der aktuelle Stand oder Füllstand der Ladung berichtet wird, der in dem Tank erreicht worden ist, welcher der Einlaßpumpe zugeordnet ist. Solche sequentiellen Funktionspläne oder Grafiken sind dem Fachmann der Stapel- oder Prozeßsteuerung oder Regelung gut bekannt. Solche sichtbaren Repräsentationen der Sequenz der Steuerelemente werden durch im Handel erhältliche Computer- und Softwarewerkzeuge in Befehle und Instruktionen übersetzt, die innerhalb des PLM 310 oder 316 betreibbar sind oder lauffähig sind, indem darin jeweils die Zustandsmaschine 312 oder 318 ausgeführt wird.
-
Der Fachmann erkennt hier, daß die sequentielle Funktionsgrafik oder Abbildung, die in 5 herausgegriffen ist, lediglich als ein Beispiel von irgendeiner Programmiersprache oder einem anderen Werkzeug dient, welches nützlich ist, um die vom Anwender hinzugefügten logischen Zustandsmodule 404 bis 414 von 4 zu definieren. Irgendeine Sequenz der Steueroperationen kann durch den Ingenieur in die logischen Zustandsmodule 404 bis 414 zugeführt werden. Ferner kann irgendeine von mehreren gut bekannten Programmiertechniken durch den Konstruktionsingenieur dazu verwendet werden, um die Sequenz der Sequenzfunktionen für einen bestimmten logischen Zustandsmodul zu programmieren.
-
Server-/Phasenlogikmodulprotokoll
-
Ein Kommunikationsprotokollaspekt der vorliegenden Erfindung trägt dem Austausch von Informationen zwischen im wesentlichen identischen Zustandsmaschinen, die innerhalb des Stapelserverprogramms und innerhalb der PLMs arbeiten, Rechnung. Im wesentlichen schafft das Protokoll eine Kommunikation auf einer hohen Ebene oder Schicht zwischen den Zustandsmaschinen des Stapelserverprogramms und der PLMs. Das Stapelserverprogramm benachrichtigt über die geforderten Zustandsübergänge vermittels Befehlen und einem Status, die zu der Zustandsmaschine gesendet werden, welche innerhalb der PLMs vorherrschend ist. Es werden Status- und andere Informationen von dem PLM zu dem Stapelserverprogramm zurückgeleitet. Die Befehle zeigen im allgemeinen die Zustandsänderungen an, die durch die Stapelserverprogrammzustandsmaschine in Einklang mit der Eingabe einer Bedienungsperson oder einer anderen Steuereingabe und Parametern ausgeführt werden.
-
Die Informationen, die zwischen dem Stapelserverprogramm und dem PLM auszutauschen sind, werden durch Lesen und Schreiben von Werten in Attributen übermittelt. Attribute sind lediglich Örtlichkeiten, die durch das Serverprogramm oder den PLM gelesen oder geschrieben werden können, wie dies gefordert wird, um die erforderliche Kommunikation zu bewirken. Diese bevorzugte Ausführungsform ahmt eng die Registermodellstruktur nach, die den Steueringenieuren gut bekannt ist. Diese Struktur ist daher durch die Steueringenieure leicht erlernbar und verständlich, die mit den vorliegenden Techniken vertraut sind. Wie jedoch oben angegeben ist, erfordern die Verfahren und Strukturen der vorliegenden Erfindung nicht das Abbilden von hunderten oder tausenden von Eintragen für die Kommunikation zwischen dem Serverprogramm und dem programmierbaren Kontroller. Vielmehr dient ein einzelner Satz von vordefinierten Attributen diesem Zweck in Verbindung mit einer einzelnen Standardzustandsmaschine, die innerhalb des PLM des programmierbaren Kontrollers implementiert ist und betreibbar ist.
-
Jegliche Kommunikation zwischen dem Serverprogramm und dem PLM wird in bevorzugter Weise durch das Serverprogramm gesteuert. Die Informationen werden von dem Serverprogramm zu dem PLM gesendet, und zwar in der erforderlichen Weise, indem Attributwerte für die Verwendung durch den PLM geschrieben werden. Status- und andere Informationen, die von dem PLM zurückgeleitet werden, werden durch den PLM in geeignete Attribute umgeschrieben und werden durch das Serverprogramm gelesen. Das Serverprogramm wird (über die Kommunikationsschichten der Software) benachrichtigt, wenn die interessierenden Attributwerte innerhalb des PLM modifiziert werden.
-
Bei der momentan bekannten besten Art, die Erfindung zu praktizieren, werden die folgenden Attribute zwischen den Zustandsmaschinen des Stapelserverprogramms und dem PLM ausgetauscht:
-
BCOMMAND
-
Das BCOMMAND-Attribut wird durch das Stapelserverprogramm (SERVER) geschrieben, um einen Befehl zu dem PLM zu senden. Ein Abschnitt des Attributs (das heißt ein Byte einer niedrigen Ordnung) liefert den Befehlskode, während ein anderer Abschnitt (das heißt ein hohes Byte) eine Sequenzzahl liefert, die dazu verwendet wird, um eine verläßliche Kommunikation zwischen dem SERVER und dem PLM sicherzustellen.
-
Spezifischer gesagt, sendet der SERVER einen Befehl zu dem PLM mit einem tatsächlichen Befehlswert/Identifizierer in dem niedrigeren Byte und einen ID-Wert in dem oberen Byte. Der Befehl und die ID werden ”gesendet”, indem der Wert in dem BCOMMAND-Attribut gespeichert wird. Der PLM empfängt den Befehl und löscht das untere Byte auf Null in Form eines Flags zu dem SERVER, was anzeigt, daß der Befehl empfangen worden ist. Der SERVER detektiert eventuell, daß das niedrigere Byte von BCOMMAND gelöscht worden ist und er versteht dadurch, daß der PLM den Befehl empfangen und verarbeitet hat.
-
Beispielhafte Befehle umfassen: Abbruch, Halten, Stopp, Rückstellen, Wiederstart und Start. Andere Befehle können in dem Test und dem Austestvorgang der PLMs nützlich sein. Beispielsweise kann ein single step-Befehl zum Austesten eines vom Anwender hinzugefügten PLM-Zustandslogikmoduls mit einer Niedrigebenengrundsteuerung nützlich sein, die zu einem Zeitpunkt (oder einer anderen Niedrigebenendurchschreitung) ausgeführt wird. Oder es kann beispielsweise ein download-Befehl nützlich sein, um einen neuen PLM von einer Entwicklungsworkstation über den SERVER zu der PLM-Zustandsmaschine schnell downzuloaden. Wenn ein PLM einen Fehler oder Ausfall detektiert und ein Fehlerindexstatusattribut setzt (wie weiter unten definiert ist), kann der SERVER einen clrfail-Befehl aussenden, um den ”verriegelten” Fehlerstatus zu löschen. Noch andere Befehle, wie beispielsweise ackreq und clrreq können zwischen dem SERVER und dem PLM verwendet werden, um eine Protokoll-Handshake-Datenflußdosierung und Zuverlässigkeit vorzusehen.
-
BSTATUS
-
Das BSTATUS-Attribut wird durch den PLM geschrieben oder umgeschrieben, um den laufenden Zustand der PLM-Zustandsmaschine zu reflektieren. Der SERVER liest dieses Attribut, um den momentanen Zustand eines PLM zu bestimmen. Der in dem Attribut kodierte Zustand ist so, wie oben in Verbindung mit der Tabelle 1 beschrieben wurde.
-
REQUEST/REQDATA1-5
-
Die REQUEST- und REQDATA1-5-Attribute werden durch die PLM geschrieben, um Informationen oder Services von dem SERVER anzufragen. Wenn der SERVER auf die Anfrage geantwortet hat, löscht er das REQUEST-Attribut, um auf diese Weise die Vervollständigung der Anfrage anzuzeigen.
-
Bei der bevorzugten Ausführungsform fallen die Anfragen nach Dienstleistungen durch den PLM von dem SERVER in die folgenden allgemeinen Kategorien:
| REQUEST-Wert | Funktion |
| 1000–1999 | Download einiger oder aller Phasenparameter |
| 2000–2999 | Upload einiger oder aller Reportparameterwerte |
| 3000–3999 | Senden einer Nachricht zu einer Bedienungsperson |
| 4000–4999 | Anfordern oder Freigeben von Ressourcen |
| 5000–5999 | Phase-zu-Phase-Kommunikation (für die Synchronisation) |
| 6000 | Löschen aller ausstehender Anfragen |
-
Der Fachmann kann hier erkennen, daß unzählige andere Anfragen zu der oben angegebenen Tabelle hinzugefügt werden können als auch Modifikationen zu den obigen Angaben möglich sind.
-
FAIL_INDEX
-
Dieses Attribut wird durch den PLM geschrieben (das heißt der Anwender fügt einen Fehlerüberwachungszustandlogikmodul hinzu), um dem SERVER das Auftreten eines Fehlers bei der Verarbeitung des PLM anzuzeigen. Der SERVER sendet einen clrfail-Befehl, wie oben angegeben, um den Zustand in dem PLM zu löschen (und eventuell einen reset- oder anderen Befehl, um die PLM-Zustandsmaschine wieder zu initialisieren). Die speziellen Typen des Ausfalls oder Fehlers und der Kodes, die diesen repräsentieren, sind eine Sache der Designwahl für den PLM-Ingenieur.
-
UNIT
-
Das UNIT-Attribut wird durch den SERVER geschrieben, wenn dieser mit dem PLM ”verbindet”. Da eine Vielzahl von Servern einen bestimmten PLM verwenden können (das heißt, um die physikalische Modellausrüstung zu betreiben, um unterschiedlichen Chargen zu erzeugen), repräsentiert dieses Attribut eine ID des SERVERs, der momentan an den PLM angeschlossen ist.
-
OWNER
-
Dieses Attribut wird durch den PLM geschrieben, um den SERVER zu informieren, ob dieser SERVER oder ein anderer Anwender momentan diesen PLM verwendet (das heißt der BESITZER von).
-
STEP_INDEX
-
Dieses Attribut wird durch den PLM geschrieben, und zwar wenn dieser durch die Schritte aufeinanderfolgend verläuft, und zwar von den vom Anwender hinzugefügten Zustandslogikmodulen. Die speziellen Kodes, die dazu verwendet werden, um jeden Schritt zu identifizieren, sind eine Sache der Designwahl.
-
PAUSE
-
Dieses Attribut wird durch den SERVER geschrieben, um den PLM zu instruieren, bei seiner momentanen Verarbeitung eines Zustandes einer Phase eine Pause zu machen.
-
PAUSED
-
Dieses Attribut wird durch den PLM geschrieben, um dem SERVER anzuzeigen, daß die angefragte Pause tatsächlich bewirkt worden ist. Ein PAUSE-Attribut von dem SERVER kann bei einer nächsten Gelegenheit bewirkt werden, was im Gegensatz zu einer unmittelbar bewirkten Pause steht. Die Logik innerhalb des PLM bestimmt, wann es sicher ist, bei der Verarbeitung eine Pause einzulegen, basierend auf der spezifischen Verarbeitung, die durchgeführt wird.
-
SINGLE_STEP
-
Dieses Attribut wird durch den SERVER geschrieben, um den PLM zu instruieren, mit der Verarbeitung zu einem nächsten Schritt fortzufahren. Grenzen zwischen den ”Schritten” der Verarbeitung werden durch den PLM basierend auf der spezifischen Verarbeitung und den Sicherheitsanforderungen derselben bestimmt.
-
TIME
-
Dieses Attribut besteht aus einem numerischen Wert, der durch den PLM geschrieben wird, um die verstrichene Zeit anzuzeigen, seit sich der Phasenzustand von dem Leerlaufzustand aus geändert hat. Wenn der PLM in den vervollständigten Zustand überwechselt, wird der Inkrementierungsvorgang des Zeitwertes angehalten (wobei die Zeit, die durch die Phasenausführung verbraucht wurde, belassen wird). Ein Rückstellbefehl setzt das Attribut auf Null zurück.
-
START_TIME
-
Dieses Attribut wird durch den PLM geschrieben und wird inkrementiert, während sich der PLM in einem bestimmten Zustand befindet, wodurch die in dem momentanen Zustand verstrichene Zeit angezeigt wird.
-
BATCH_ID
-
Dieses Attribut wird durch den SERVER geschrieben und führt einen ID-Wert (das heißt Zeichenkette) ein, und zwar für die Charge (batch), die sich momentan in dem Prozeß befindet.
-
WATCHDOG
-
Der SERVER schreibt periodisch einen von Null verschiedenen Wert in dieses Attribut ein und der PLM löscht diesen auf Null, wenn er einen von Null verschiedenen Wert detektiert. Dieses Attribut schafft daher ein Überwachungsmerkmal für den SERVER, um einen ausgefallenen PLM (und umgekehrt zu detektieren).
-
XCOMMAND
-
Bei gewissen Umständen kann eine Phase, die unter der Direktion des PLM arbeitet, durch eine Bedienungsperson gesteuert werden (das heißt von Hand gesteuert), anstatt durch den SERVER. Um eine Interferenz mit der Verwendung durch den SERVER von BCOMMAND und des Sequenznummerbytes desselben zu vermeiden, wird das XCOMMAND-Attribut durch eine Bedienungsperson verwendet, um von Hand die Betriebsweise des PLM zu steuern.
-
Ein Fachmann erkennt, daß viele Abwandlungen und Zusätze bei dem oben beschriebenen bevorzugten Protokoll möglich sind, die eine ähnliche Funktionalität für die Kommunikation zwischen dem SERVER und dem PLM schaffen. Die oben beschriebene bevorzugte Ausführungsform wird in erster Linie insofern als vorteilhaft betrachtet als diese die Architektur der Registermodellkommunikationen neu anordnet, die den Steuer- oder Regelingenieuren bereits vertraut sind. Dieses Protokoll der vorliegenden Erfindung ist daher durch die Steuer- oder Regelingenieure, die mit den gegenwärtigen Techniken vertraut sind, leichter zu erlernen. Bezugszeichenliste:
| Nummer | Bezeichnung |
| 100 | logisches Phasenmodul (PLM) |
| 102 | Zustandsmaschine/Standardzustandsmaschine |
| 103 | Kontroller |
| 104 | Datenverarbeitungsvorrichtung/Datenverarbeitungselement/datenverarbeitende Vorrichtung |
| 106 | PLM/Soft-PLM |
| 108 | Zustandsmaschine/Standardzustandsmaschine |
| 112 | Pfad |
| 170 | Zustandsmaschine |
| 200 | Zustandsmaschinenmodell |
| 202 | Leerlaufzustand |
| 204 | laufender Zustand/Laufzustand |
| 206 | Abbruchzustand/Anhaltezustand |
| 210 | Vervollständigungszustand |
| 216 | angehaltener Zustand |
| 218 | abgebrochener Zustand |
| 220 | gehaltener Zustand/Haltezustand |
| 222 | gehaltener Zustand |
| 224 | wieder gestarteter Zustand/Wiederstartzustand |
| 300 | System |
| 302 | Anwenderworkstation/Vorrichtung |
| 304 | Stapel-Clientprogramm |
| 306 | Stapelserverprogramm |
| 307 | Phase |
| 308 | Zustandsmaschine |
| 310 | Soft-PLM |
| 312 | PLM-Zustandsmaschine |
| 315 | Kontroller |
| 316 | PLM |
| 318 | Zustandsmaschine |
| 320 | Kontrollerprozeß-I/O |
| 322 | Anwenderinterfaceausrüstung/Eingangs/Ausgangsvorrichtungen |
| 324, 326 | datenverarbeitende Vorrichtung |
| 340 | Prozeßausrüstung |
| 350 | Pfad |
| 352 | Pfad |
| 356 | Inter-Prozeßkommunikationspfad |
| 358 | Pfad |
| 360 | Pfad |
| 362 | Pfad |
| 400 | Serverkommunikationselement |
| 402 | Steuereinheit/Zustandssteuerung/Zustandsmaschinensteuerelement/Zustandsmaschinensteuerung |
| 404 | Laufzustandslogikmodul/logisches Zustandsmodul |
| 406 | Haltezustandslogikmodul |
| 408 | Wiederstartmodul |
| 410 | Stoppmodul |
| 412 | Abbruchmodul |
| 414 | Fehlerüberwachungslogikmodul |
| 500 | Element |
| 502 | Element |
| 504 | Element |
| 508 | Element |
| 512 | Element |
| 516 | Element |
| 520 | Element |
| 610 | Phase |
| 660 | Pfad |
| 670 | Pfad |
| 675 | I/O |
| 680 | Pfad |
| 685 | Prozessausrüstung |
| 716 | logisches Zustandselement/Zustandslogiksequenz |
