-
Diese Anmeldung steht in Verbindung mit der zugleich anhängigen US-Patentanmeldung Nr. 09/420 182 mit dem Titel „Version Control and Audit Trail in a Process Control System”, deren gesamter Offenbarungsgehalt hiermit Teil dieser Anmeldung ist.
-
Die Erfindung betrifft Prozesssteuerungssysteme und insbesondere eine Freigabe von Softwareobjekten für die Verwendung in Prozesssteuerungssystemen.
-
Prozesssteuerungssysteme weisen typischerweise vielfältige Sätze von Einrichtungen auf, welche verwendet werden, um bestimmte Herstellungs- oder andere Steuerungsprozesse durchzuführen. Die Sätze von Einrichtungen sind mit Reglern bzw. Steuerungen verbunden, welche Softwareanweisungen für die Prozesssteuerung aufweisen, um die Einrichtungen in bestimmter Weise zu bedienen und somit die Herstellung oder den Steuerungsprozess zu bewirken. Prozesssteuerungssoftware kann in Phasen bzw. Abschnitte gegliedert sein, welche im Allgemeinen mit verschiedenen Arten von Prozessschritten in Verbindung stehen können. Beispielsweise kann einer Mischungsphase Hardware zugeordnet sein, die einen Mischungsschritt eines Prozesses durchführt.
-
Wegen der allgemeinen Eigenschaften von Phasen müssen Phasen jedoch basierend auf den Einzelheiten des Schrittes modifiziert oder angepasst werden, den sie ausführen sollen. Beispielsweise muss eine Mischungsphase, welche allgemein darauf ausgelegt ist, Mischungseinrichtungen zu bedienen, angepasst werden, um eine bestimmte Mischungseinrichtung für bestimmte Zeitdauern bei bestimmten Geschwindigkeiten zu bedienen. Gewöhnlich werden Rezepte verwendet, um Phasen anzupassen oder zu modifizieren. Wie der Name impliziert, sind Rezepte Instruktionssätze, welche auf Prozesssteuerungshardware heruntergeladen werden, um bestimmte Aufgaben durchzuführen, wie beispielsweise Kekse herstellen, Pharmazeutika produzieren oder andere Prozesse steuern. Rezepte sind typischerweise spezifischer als Phasen und schließen tatsächlich die Verwendung von Phasen in sich ein. Beispielsweise kann ein Rezept zur Keksherstellung einen Mischungsschritt aufweisen, welcher von einer Mischungsphase durchgeführt werden könnte. Im Gegensatz zu der Mischungsphase spezifiziert jedoch das Rezept für die Herstellung von Keksen die Dauer und die Geschwindigkeit, mit welcher das Mischen ausgeführt werden soll. Das Rezept spezifiziert also die Parameter, die den Arbeitsvorgang der Mischungsphase definieren.
-
Wie leicht zu erkennen ist, kann eine Änderung des Rezeptes, das von einem Prozesssteuerungssystem ausgeführt wird, den Arbeitsablauf des Prozesssteuerungssystems drastisch beeinflussen. Beispielsweise kann die Änderung eines Rezeptes für Kekse mit Schokoladensplittern die Anzahl der Schokoladensplitter, die in dem Keksteig verwendet werden, die Konsistenz des Keksteiges oder die Backzeit für die Kekse beeinflussen. Entsprechend kann das Herunterladen eines Rezeptes, welches versehentlich modifiziert oder sonst in einer unautorisierten Weise verändert wurde, das Ergebnis eines Prozesssteuerungssystems nachteilig beeinflussen, was zu nicht den Produktspezifikationen entsprechenden Produkten und im Ergebnis zu einem Verlust an Gewinnen führt.
-
Während die Änderung eines Rezeptes für Produkte wie beispielsweise Kekse zu Keksen führen kann, die offensichtlich fehlerhaft sind (beispielsweise nicht sorgfältig durchgebacken, nicht genügend Schokoladensplitter, etc.), werden nicht alle Rezeptänderungen zu Produkten mit sofort erkennbaren Fehlern führen. Beispielsweise können Kekse mit zuviel Salz während des Produktionsprozesses nicht leicht erkannt werden. Konsumenten jedoch können die Salzigkeit der Kekse bemerken und können sich beim Hersteller beschweren, womit dann festgestellt werden kann, dass das Rezept für die Kekse in einer nicht akzeptablen Weise geändert wurde. Trotz der Tatsache, dass einige Konsumenten verärgert sein können, sind die Konsequenzen einer unautorisierten Veränderung eines Keksrezeptes nicht lebensbedrohlich.
-
Während in einigen Fällen wie der Keksproduktion eine unautorisierte Rezeptveränderung schlimmstenfalls zur Unzufriedenheit der Konsumenten führen kann, kann beispielsweise die Veränderung von Rezepten in der pharmazeutischen Produktion schwerwiegendere Folgen haben. Eine Rezeptänderung, welche die Mengen oder die Bestandteile eines Medikamentes verändert, kann das entstandene Medikament unwirksam oder giftig machen. Zudem ist eine Änderung der Bestandteile von Medikamenten im Gegensatz zu der Anzahl von Schokoladensplittern in einem Keks nicht leicht erkennbar, weil das Medikament dieselbe Farbe und Konsistenz wie ein nicht verändertes oder ordnungsgemäß hergestelltes Medikament haben kann.
-
Weiterhin benötigen viele Rezepte erhebliche Investitionen an Produktionskapazität, Zeit und/oder Material, und deshalb kann die Notwendigkeit, ein bereits eingesetztes Rezept auszumustern, einen wesentlichen nachteiligen finanziellen Einfluss auf die Entität (z. B. Person, Unternehmen) haben, welche das Rezept ausführt, und ebenso auf jede andere Entität, die das Produkt zu erhalten erwartet, das durch die Ausführung des Rezeptes ausgegeben wird. Beispielsweise brauchen Rezepte für die Herstellung von Produkten, die eine Fermentierung einschließen, wie beispielsweise Wein, Bier, Käse oder Ähnliches oftmals Wochen oder Monate an Prozesszeit sowie erhebliche Materialinvestitionen.
-
Typischerweise werden Rezepte für Prozesssteuerungssysteme, wie auch für andere Softwaremodule oder Objekte, wie beispielsweise Einheiten, Phasen oder Ähnliches von einem Ingenieur oder Wissenschaftler geschrieben, der verschiedene Entitäten wie beispielsweise Forschungs- oder Produktionsgruppen auffordert, das Rezept oder die andere Software freizugeben, ehe sie auf das Prozesssteuerungssystem heruntergeladen wird. Der Freigabeprozess von Software für Prozesssteuerungssysteme ist jedoch typischerweise bestenfalls als Umlauf eines Memorandums oder als ein Freigabeantrag oder im schlimmsten Fall noch informeller realisiert.
-
Dokument
US 6 385 494 B1 offenbart ein System und ein Verfahren zur Bereitstellung von Produktionssteuerungssoftware für eine Vielzahl von elektronischen Steuerungsmodulen. Dabei kann ein Benutzer neue Produktionssteuerungssoftware überprüfen, verändern und genehmigen.
-
Dokument
US 6 381 698 B1 offenbart ein System und Verfahren zur Bereitstellung einer Versicherung für einen Host-Computer, dass ein bestimmtes Software-Modul eine bestimmte Eigenschaft aufweist.
-
Dokument
US 4 827 423 offenbart ein Computer-integriertes Herstellungssystem. Dabei ist eine Vielzahl von Computersteuerungs-Levels vorgesehen, die die Information zur Steuerung von Einkaufsboden-Level-System organisieren und verbreiten.
-
Dokument
US 6 314 425 B1 offenbart eine Vorrichtung und ein Verfahren zur Verwendung von Zugriffs-Token in einem Internet Dokument Management System.
-
Gegenüber diesem Stand der Technik ist es eine Aufgabe der Erfindung, ein Prozesssteuerungssystem und ein Verfahren anzugeben, bei denen das Herunterladen von nicht freigegebener Software auf das Prozesssteuerungssystem verhindert wird.
-
Zur Lösung dieser Aufgabe werden ein Prozesssteuerungssystem gemäß Anspruch 1 und ein Verfahren zur Freigabe von Softwareobjekten gemäß Anspruch 10 sowie ein Verfahren zum Herunterladen eines Softwareobjekts auf ein Prozesssteuerungssystem gemäß Anspruch 19 angegeben.
-
Gemäß einem ersten Aspekt erzeugt ein System und ein Verfahren zur Freigabe von Softwareobjekten zur Verwendung in einem Prozesssteuerungssystem elektronische Identifizierungsinformationen, die eine Gruppe von Entitäten bilden, deren Freigabe vor der Implementierung eines Softwareobjekts innerhalb des Prozesssteuerungssystems benötigt wird. Zusätzlich kann das System und das Verfahren von jeder Entität, die innerhalb der Identifizierungsinformationen repräsentiert ist, ein elektronisches Zeichen erhalten, welches die Freigabe des Softwareobjektes betrifft, und kann eine erste Softwareroutine verwenden, um das Prozesssteuerungssystem daran zu hindern, das Softwareobjekt zu implementieren, bis jede innerhalb der Identifizierungsinformationen repräsentierte Entität das Softwareobjekt freigibt. Weiterhin kann das System und das Verfahren eine zweite Softwareroutine verwenden, um dem Prozesssteuerungssystem selektiv zu ermöglichen, das Softwareobjekt auf Grund der elektronischen Angaben zu implementieren.
-
Gemäß einem weiteren Aspekt stellt ein System und ein Verfahren zur Freigabe von Softwareobjekten für die Verwendung in einem Prozesssteuerungssystem fest, ob ein Softwareobjekt von einer Gruppe von Entitäten freigegeben ist und implementiert das Softwareobjekt innerhalb des Prozesssteuerungssystems, wenn das Softwareobjekt von der Gruppe von Entitäten freigegeben ist.
-
Gemäß einem weiteren Aspekt stellt ein System und ein Verfahren zur Freigabe von Softwareobjekten zur Verwendung in einem Prozesssteuerungssystem als Antwort auf den Empfang eines elektronischen Zeichens fest, dass mindestens eine aus einer Vielzahl von Entitäten das Softwareobjekt nicht freigegeben hat, dass das Softwareobjekt nicht freigegeben ist. Das System und das Verfahren kann auch als Antwort auf den Empfang einer anderen elektronischen Angabe, dass jede einzelne aus der Vielzahl von Entitäten das Softwareobjekt freigegeben hat, festlegen, dass das Softwareobjekt freigegeben ist.
-
Zusätzlich kann das System und das Verfahren das Herunterladen von Softwareobjekten in das Prozesssteuerungssystem erlauben, wenn das Softwareobjekt freigegeben ist.
-
Die Erfindung wird nachstehend nur beispielhaft anhand von Ausführungsformen und unter Bezugnahme auf die beigefügten Zeichnungen beschrieben. Die Zeichnungen zeigen in:
-
1 ein Blockdiagramm eines Prozesssteuerungssystems, das eine oder mehrere Steuerungsroutinen verwendet, die Aliasnamen und/oder dynamische Referenzparameter haben, um die Steuerung der Prozesseinrichtungen durchzuführen;
-
2 ein Blockdiagramm einer Objektstruktur, welche die logische Hierarchie oder die Konfiguration des Prozesssteuerungssystems gemäß 1 darstellt;
-
3 ein etwas detaillierteres Blockdiagramm eines Teils der Objektstruktur gemäß 2;
-
4 ein Beispiel für ein Flussdiagramm einer Editorroutine für ein Rezept;
-
5 ein Beispiel für ein Flussdiagramm einer Initialisierungsroutine für eine Autorisierung;
-
6 ein Beispiel für ein der Initialisierungsroutine für die Autorisierung gemäß 5 zugeordnetes User-Interface (Benutzerschnittstelle);
-
7 ein Beispiel für ein Flussdiagramm einer Hinzufügen-Routine;
-
8 ein Beispiel für ein der Hinzufügen-Routine gemäß 7 zugeordnetes User-Interface;
-
9 ein Beispiel für ein Flussdiagramm einer Löschroutine;
-
10 ein Beispiel für ein Flussdiagramm einer Modifizierungsroutine;
-
11 ein Beispiel für ein der Modifizierungsroutine gemäß 10 zugeordnetes User-Interface;
-
12 ein Beispiel für ein Flussdiagramm einer Autorisierungsroutine für ein Rezept;
-
13 ein Beispiel für ein der Autorisierungsroutine des Rezeptes gemäß 12 zugeordneten User-Interface;
-
14 ein Beispiel für ein Flussdiagramm für eine Freigaberoutine;
-
15 ein Beispiel für ein der Freigaberoutine gemäß 14 zugeordnetes User-Interface;
-
16 ein Beispiel für ein Flussdiagramm einer Zurückweisungsroutine;
-
17 ein Beispiel für ein User-Interface, welches den Status der nicht freigegebenen Rezepte darstellt; und
-
18 ein Beispiel für ein Flussdiagramm einer Herunterladen-Routine.
-
Die Verfahren und Systeme zur Steuerung der Freigabe und des Herunterladens von Softwareobjekten wie beispielsweise Rezepten in Prozesssteuerungssystemen, wie im Folgenden genauer beschrieben wird, kann verwendet werden, um einem Autor von Softwareobjekten zu ermöglichen, die Personen oder die Gruppen von Prüfern oder Unterzeichnern zu spezifizieren, die ein Softwareobjekt autorisieren müssen, ehe das Objekt auf das Prozesssteuerungssystem heruntergeladen oder darin implementiert wird. Die Prüfer und Unterzeichner können durch eine Anzahl verschiedener Techniken benachrichtigt werden und das Softwareobjekt nach der Benachrichtigung prüfen und das Softwareobjekt dann freigeben oder zurückweisen. Wenn jeder der Prüfer das Softwareobjekt freigibt, kann das Softwareobjekt für das Herunterladen auf das Prozesssteuerungssystem verfügbar gemacht werden. Zusätzliche Funktionalität kann vorsehen, verschiedenen Personen oder Entitäten (beispielsweise Prüfern, Autoren, Geschäftsgruppen oder anderen) zu erlauben, den Freigabestatus des Softwareobjektes zu prüfen.
-
Während das System und das Verfahren für die Freigabe von Softwareobjekten im Folgenden beispielhaft für die Verwendung für die Freigabe und das Herunterladen von Rezepten, die ein oder mehrere Softwareobjekte aufweisen können, innerhalb eines Prozesssteuerungssystems beschrieben wird, kann das hier beschriebene System und Verfahren auch vorteilhaft für andere Arten von Softwareobjekten verwendet werden, wie beispielsweise Einheiten, Phasen, Grafiken etc. Weiterhin kann das hier beispielhaft beschriebene System und das Verfahren zur Freigabe von Softwareobjekten verwendet werden, um ein einzelnes Softwareobjekt zu einem Zeitpunkt und/oder Gruppen von verwandten oder nicht verwandten Softwareobjekten gleichzeitig freizugeben und herunterzuladen.
-
Wie leicht zu erkennen ist, kann das hierin beschriebene System und Verfahren zur Freigabe von Softwareobjekten zusätzlich vorteilhaft in Verbindung mit Versionskontrollsoftware verwendet werden. Eine beispielhafte Art von Versionskontrollsoftware ist in der Patentanmeldung mit dem Titel „Version Control and Audit Trail in a Process Control System” offenbart, die am 18. Oktober 1999 eingereicht und der die US-Nr. 09/420 182 zugewiesen wurde und die dem Anmelder der vorliegenden Anmeldung gehört.
-
Wie nun unter Bezugnahme auf 1 erläutert, weist ein Prozesssteuerungssystem 10 Steuerungen bzw. Regler 12 auf, die über eine Ethernetverbindung 15 mit einer Vielzahl von Workstations 14 verbunden sind. Die Regler 12 sind auch über einen Satz von Übertragungsleitungen oder einen Bus 18 mit Geräten oder Einrichtungen verbunden, die einem Prozess zugeordnet sind (allgemein mit dem Bezugszeichen 16 bezeichnet). Die Regler 12, die beispielsweise DeltaVTM-Regler sein können, vertrieben von der Fisher-Rosemount Systems Inc., sind in der Lage, mit anderen Steuerelementen, wie beispielsweise Feldgeräten und Funktionsblocks innerhalb von Feldgeräten, die über dem Prozess 16 verteilt sind, um eine oder mehrere Prozesssteuerungsroutinen durchzuführen und die bevorzugt unter Verwendung von objektorientierten Programmiertechniken implementiert sind, und somit mit Softwareobjekten zu kommunizieren, um hierbei die gewünschte Steuerung des Prozesses 16 zu implementieren. Die Workstations 14 (die beispielsweise Personal Computer sein können) können von einem oder mehreren Ingenieuren oder anderen Benutzern verwendet werden, um Prozesssteuerungsroutinen oder Softwareobjekte zu entwerfen, die von den Reglern 12 ausgeführt werden, oder um mit den Reglern 12 zu kommunizieren, um derartige Prozesssteuerungsroutinen oder Softwareobjekte herunterzuladen und während des Ablaufes des Prozesses 16 Informationen zu empfangen und darzustellen, die zu dem Prozess 16 gehören. Jede der Workstations 14 weist einen Speicher 20 für die Speicherung von Applikationen auf, wie beispielsweise Konfigurationsdesign-Applikationen, und um Daten zu speichern, wie beispielsweise Konfigurationsdaten, die zu der Konfiguration des Prozesses 16 gehören. Jede der Workstations 14 weist außerdem einen Prozessor 21 auf, der die Applikation ausführt, um einem Benutzer zu ermöglichen, Prozesssteuerungsroutinen oder Softwareobjekte zu entwerfen und/oder zu modifizieren und um diese Prozesssteuerungsroutinen oder Softwareobjekte auf die Regler 12 herunterzuladen. Ähnlich weist jeder der Regler 12 einen Speicher 22 zur Speicherung von Konfigurationsdaten und Prozesssteuerungsroutinen auf, um für die Steuerung des Prozesses 16 verwendet zu werden, und weist einen Prozessor 24 auf, der die Prozesssteuerungsroutinen ausführt, um eine Prozesssteuerungsstrategie zu implementieren. Wenn die Regler 12 DeltaV-Regler sind, können sie einem Benutzer über eine der Workstations 14 eine graphische Darstellung der Prozesssteuerungsroutinen innerhalb der Regler 12 zur Verfügung stellen, welche die Steuerungselemente innerhalb der Prozesssteuerungsroutine und die Weise darstellt, in der diese Steuerungselemente konfiguriert sind, um für die Steuerung des Prozesses 16 zu sorgen.
-
Das System kann auch ein Netzwerk 30 aufweisen, mit dem eine oder mehrere der Workstations 14 verbunden sind. Das Netzwerk 30 kann unter Verwendung von einem geeigneten Netzwerk implementiert sein, wie beispielsweise dem Internet, einem Intranet, einem LAN (Local Area Network bzw. Lokales Netz) einem WAN (Wide Area Network bzw. Fernnetz) oder jedem anderen geeigneten Netzwerk. Obwohl das Netzwerk 30 mit festverdrahteten Verbindungen dargestellt ist, ist offensichtlich, dass ein solches Netzwerk auch ein Funknetz (wireless network) oder ein Netzwerk mit sowohl festverdrahteten wie auch drahtlosen Bereichen sein kann.
-
Eine Anzahl von Terminals 32 kann ebenfalls über das Netzwerk 30 mit den Workstations 14 verbunden sein. Jedes der Terminals 32 kann einen Speicher 34 aufweisen, der mit einem Prozessor 36 verbunden ist, der darauf ausgelegt ist, die in dem Speicher 34 gespeicherten Instruktionen auszuführen. In einer beispielhaften Ausführungsform können die Terminals 32 Personal Computer oder ähnliche Verarbeitungsanlagen sein, welche dieselbe oder eine größere Verarbeitungsleistung bzw. einen Speicher haben, als er in den heute bekannten herkömmlichen Personal Computern zur Verfügung steht.
-
Um auf die Beschreibung des Abgleichs des Prozesssteuerungssystems 10 gemäß 1 zurückzukommen: Die Regler 12 sind kommunikativ über den Bus 18 mit drei Sätzen von ähnlich konfigurierten Reaktoren verbunden, die als Reaktor_01, Reaktor_02 und Reaktor_03 bezeichnet werden. Reaktor_01 weist einen Reaktorbehälter 100, zwei Einlassventile 101 bzw. 102, die mit Steuerungsfluideinlassleitungen verbunden sind, welche den Reaktorbehälter 100 mit Fluid versorgen, und einem Auslassventil 103 verbunden, das mit einem Steuerfluidausfluss des Reaktorbehälters 100 über eine Auslassfluidleitung verbunden ist. Eine Einrichtung 105, die ein Sensor wie beispielsweise ein Temperatursensor, ein Drucksensor, ein Fluidpegelmesser etc. oder ein anderes Gerät wie beispielsweise eine elektronische Heizung oder eine Dampfheizung sein kann, ist in oder nahe dem Reaktorbehälter 100 angeordnet. Ähnlich weist Reaktor_02 einen Reaktorbehälter 200, zwei Einlassventile 201 und 202, ein Auslassventil 203 und eine Einrichtung 205 auf. Gleichermaßen weist Reaktor_03 einen Reaktorbehälter 300, zwei Einlassventile 301 und 302, ein Auslassventil 303 und eine Einrichtung 305 auf. Wie in 1 erläutert, sind die Regler 12 über den Bus 18 kommunikativ mit den Ventilen 101–103, 201–203 und 301–303 und mit den Einrichtungen 105, 205 und 305 verbunden, um den Ablauf dieser Elemente zu steuern, um einen oder mehrere Abläufe bezüglich der Reaktoreinheiten durchzuführen. Solche Abläufe können beispielsweise ein Befüllen der Reaktorbehälter, ein Heizen des Materials innerhalb der Reaktorbehälter, ein Entleeren der Reaktorbehälter, ein Reinigen der Reaktorbehälter etc. einschließen.
-
Die Ventile, Sensoren und anderen Geräte, die in 1 dargestellt sind, können jede gewünschte Art oder jeder Typ von Geräten einschließlich beispielsweise Feldbus-Einrichtungen, Standard-4–20 mA-Einrichtungen, HART-Einrichtungen etc. sein und können mit den Reglern 12 unter Verwendung jedes bekannten oder gewünschten Kommunikationsprotokolls wie beispielsweise dem Feldbusprotokoll, dem HART-Protokoll, dem 4–20 mA-Analogprotokoll etc. kommunizieren. Weiterhin können auch andere Arten von Einrichtungen mit den Reglern 12 verbunden und von ihnen gesteuert sein. Ebenso können auch andere Regler mit den Reglern 12 und den Workstations 14 über eine Ethernetkommunikationsverbindung 15 verbunden sein, um andere Einrichtungen oder dem Prozess 16 zugehörige Bereiche zu steuern, und der Ablauf von derartigen zusätzlichen Reglern kann mit dem Ablauf der in 1 dargestellten Regler 12 in jeder gewünschten Weise abgestimmt sein.
-
Allgemein gesagt, kann das Prozesssteuerungssystem 10 gemäß 1 verwendet werden, um Batchprozesse zu implementieren, in denen beispielsweise eine der Workstations 14 oder die Regler 12 eine Batchausführungsroutine ausführen, die eine High-Level-Steuerungsroutine ist, die den Ablauf von einer oder mehreren der Reaktoreinheiten (wie auch von anderen Geräten) steuert, um eine Reihe von verschiedenen Schritten (allgemein als Phasen bezeichnet) durchzuführen, die für die Produktion eines Produktes benötigt werden, wie beispielsweise ein Nahrungsprodukt, ein Medikament oder ein anderes pharmazeutisches Produkt etc. Die Schritte oder Phasen sind typischerweise unter Verwendung von Softwareobjekten implementiert, die von einem oder mehreren der Prozessoren 21 und 24 innerhalb des Systems 10 instantiiert und ausgeführt werden können.
-
Um verschiedene Phasen zu implementieren, verwendet die Batchausführungsroutine etwas, das allgemein als ein Rezept bezeichnet wird, welches ein Softwareobjekt ist, das die durchzuführenden Schritte, die zu den Schritten gehörenden Mengen und Zeiten und die Abfolge der Schritte spezifiziert. Die Schritte für ein Rezept können beispielsweise das Befüllen eines Reaktorbehälters mit den entsprechenden Materialien oder Zutaten, das Mischen der Materialien innerhalb des Reaktorbehälters, das Heizen der Materialien innerhalb des Reaktorbehälters auf eine bestimmte Temperatur für eine bestimmte Zeitdauer, das Entleeren des Reaktorbehälters und das anschließende Reinigen des Reaktorbehälters als Vorbereitung für den nächsten Batchlauf einschließen. Jeder der Schritte bildet eine Phase des Batchlaufes, und die Batchausführungsroutine innerhalb der Regler 12 wird für jede einzelne dieser Phasen einen unterschiedlichen Steuerungsalgorithmus ausführen. Natürlich können die spezifischen Materialien, die Mengen an Materialien, die Heiztemperaturen und Zeiten etc. für unterschiedliche Rezepte unterschiedlich sein, und deshalb können sich diese Parameter von Batchlauf zu Batchlauf in Abhängigkeit von dem herzustellenden oder zu produzierenden Produkt und dem verwendeten Rezept ändern. Dem Fachmann ist klar, dass während hier Steuerungsroutinen und Konfigurationen für Batchläufe in den in 1 dargestellten Reaktoreinheiten beschrieben sind, Steuerungsroutinen falls gewünscht auch verwendet werden können, um andere gewünschte Einrichtungen zu steuern, um irgendwelche anderen gewünschten Batchprozessläufe durchzuführen oder um einen durchgehenden Prozesslauf durchzuführen.
-
Auf einer übergeordneten Ebene, in einem relevanten Bereich des Ablaufes, kann eine Person oder Entität an einer der Workstations 14 Rezepte oder andere Softwareobjekte erstellen oder modifizieren und kann die Freigabe von verschiedenen Autorisierungsentitäten wie beispielsweise der Produktion, der Entwicklung, der Qualitätssicherung oder dem Management anfordern. Die Autorisierungsentität kann die Workstations 14 oder die Terminals 32 verwenden, um das Rezept und/oder die anderen in Frage kommenden Softwareobjekte zu prüfen und das Rezept und/oder die anderen Softwareobjekte freizugeben oder zurückzuweisen. Die Freigabe oder Zurückweisung der in Frage stehenden Softwareobjekte kann der Person oder Entität kommuniziert werden, welche die Freigabe der Objekte angefordert hat. Sobald ein Softwareobjekt von allen Entitäten freigegeben wurde, von denen eine Freigabe angefordert wurde, kann das Softwareobjekt auf einen der Regler 12 innerhalb des Prozesssteuerungssystems 10 für die Implementierung oder Ausführung heruntergeladen werden.
-
Die gleichen Phasen oder Schritte eines Batchprozesses können auf jedem der verschiedenen Reaktoreinheiten gemäß 1 gleichzeitig oder zu unterschiedlichen Zeiten implementiert werden. Weiterhin können, weil die Reaktoreinheiten gemäß 1 allgemein dieselbe Anzahl und Art von Einrichtungen aufweisen (d. h. sie gehören zu derselben Einheitenklasse), dieselben generischen Phasensteuerungsroutinen für eine bestimmte Phase verwendet werden, um jede der verschiedenen Reaktoreinheiten zu steuern, bis auf dass diese generischen Phasensteuerungsroutinen modifiziert werden müssen, um die zu verschiedenen Reaktoreinheiten gehörende verschiedene Hardware oder Einrichtungen zu steuern. Um beispielsweise eine Befüllungsphase für Reaktor_01 zu implementieren (während der die Reaktoreinheit befüllt wird) öffnet die Befüllungssteuerungsroutine eines oder mehrere der Einlassventile 101 oder 102 für eine bestimmte Zeitdauer, beispielsweise bis der Fluidpegelmesser 105 feststellt, dass der Behälter 100 voll ist. Dieselbe Steuerungsroutine kann jedoch auch verwendet werden, um eine Füllphase für Reaktor_02 zu implementieren, indem lediglich die Zuweisung der Einlassventile auf die Ventile 201 oder 202 anstatt der Ventile 101 oder 102 geändert wird und indem die Zuweisung des Fluidpegelmessers auf den Fluidpegelmesser 205 anstatt des Fluidpegelmessers 105 geändert wird.
-
Der Objektbaum gemäß 2 stellt spezifische Objekte, die unter Verwendung von Softwareroutinen implementiert sind, als Rechtecke dar, während allgemeine Kategorien von Objekten (oder Objekttypen) in dem Baum oberhalb der Objekte ohne ein Rechteck bezeichnet sind. Wie in 2 dargestellt, weist ein Prozesssteuerungssystem 10 einen oder mehrere Bereiche (Areas) auf, die beispielsweise Gebäude oder andere geographische Bereichsbezeichnungen innerhalb eines Prozesssteuerungswerkes sein können. In dem Objektbaum gemäß 2 hat der Prozess 16 drei Bereichsobjekte mit dem Namen Gebäude_01, Gebäude_02 und Gebäude_03. Jedes Bereichsobjekt kann in Prozesszellen unterteilt werden, deren jede einem unterschiedlichen Aspekt des Prozesses entspricht, der in dem Bereich durchgeführt wird. Das Bereichsobjekt Gebäude_01 gemäß 2 ist mit zwei als Zelle_01 und Zelle_02 bezeichneten Prozesszellobjekten dargestellt. Zelle_01 kann sich beispielsweise auf die Herstellung einer Komponente eines Produktes beziehen, welche in Zelle_02 verwendet wird. Jedes Zellobjekt kann keine oder mehrere Einheitenklassen aufweisen, die unterschiedliche Kategorien oder Gruppen von in den Prozesszellen verwendeter Hardware bezeichnen. Allgemein gesagt ist eine Einheitenklasse ein benanntes Objekt, das eine allgemeine Konfiguration von einem Satz von zugehörigen Einrichtungen festhält und ist insbesondere eine Sammlung von Einheiten, die sehr ähnliche, wenn nicht gleiche Prozessausstattung haben, deren jede eine sehr ähnliche, wenn nicht gleiche Funktion innerhalb eines Prozesses durchführt. Einheitenklassenobjekte sind typischerweise so benannt, dass sie die Art von Einheiten innerhalb des Prozesssteuerungssystems beschreiben, zu dem sie gehören. 2 zeigt eine Einheitenklasse Mischungsbehälter, eine Einheitenklasse Reaktor und eine Einheitenklasse Zufuhrbehälter. Natürlich werden in den meisten Prozesssteuerungssystemen oder Netzwerken viele andere Arten von Einheitenklassen vorgesehen oder definiert sein, einschließlich beispielsweise Trocknungseinheiten, Zuführungseinheiten und anderen individuellen oder logischen Gruppierungen von Hardware.
-
Wie für die Einheitenklasse Reaktor gemäß 2 dargestellt, kann jedes Einheitenobjekt zugehörige Einheitenmodulobjekte und Phasenklassenobjekte haben. Einheitenmodulobjekte spezifizieren im Allgemeinen bestimmte Instanzen von wiederholt auftretender Hardware innerhalb der benannten Einheitenklasse, während Phasenklassen im Allgemeinen die Phasen spezifizieren, die auf die der Einheitenklasse zugehörigen Einheitenmodule angewandt werden können. Genauer ist ein Einheitenmodulobjekt ein benanntes Objekt, das alle Variablen und Einheitenphasen (weiter unten definiert) für eine einzelne Prozesseinheit festhält und typischerweise so benannt ist, dass sie die spezifischen Prozesseinrichtungen identifiziert. Beispielsweise hat die Einheitenklasse Reaktor gemäß 2 Einheitenmodule Reaktor_01, Reaktor_02 und Reaktor_03, die den in 1 dargestellten Reaktor_01, Reaktor_02 bzw. Reaktor_03 entsprechen. Die Einheitenklasse Mischungsbehälter und die Einheitenklasse Zuführungsbehälter hat in ähnlicher Weise bestimmte Einheitenmodule, die bestimmter Hardware oder Einrichtungen innerhalb des Prozesses 16 entsprechen. Der Einfachheit halber ist jedoch keine der den Einheitenklassen Mischungsbehälter oder Zuführungsbehälter zugeordneten Einrichtungen in 1 dargestellt.
-
Eine Phasenklasse ist ein benanntes Objekt, das die allgemeine Konfiguration für eine Phase festhält, die auf mehrfachen zu derselben Einheitenklasse gehörigen Einheiten und auf mehrfachen unterschiedlichen Einheitenklassen ablaufen kann. Im Wesentlichen ist jede Phasenklasse eine unterschiedliche Steuerungsroutine (oder Phase), die von den Reglern 12 erstellt und verwendet wird, um Einheitenmodule innerhalb derselben oder verschiedenen Einheitenklassen zu steuern. Typischerweise ist jede Phasenklasse entsprechend einem Verb benannt, das die auf einem Einheitenmodul durchgeführte Aktion beschreibt. Beispielsweise hat, wie in 2 dargestellt, die Einheitenklasse Reaktor eine Phasenklasse Befüllen, die zum Befüllen von einem der Reaktorbehälter 100, 200 oder 300 gemäß 1 verwendet wird, eine Phasenklasse Heizen, die zum Heizen von einem der Reaktorbehälter 100, 200 oder 300 gemäß 1 verwendet wird, eine Phasenklasse Entleeren, die zum Entleeren von einem der Reaktorbehälter 100, 200 oder 300 gemäß 1 verwendet wird und eine Phasenklasse Reinigen, die zur Reinigung von einem der Reaktorbehälter 100, 200 oder 300 gemäß 1 verwendet wird. Natürlich kann es eine andere Phasenklasse geben, die zu dieser oder irgendeiner anderen Einheitenklasse gehört. Die Phasenklasse Befüllen gehört sowohl zu der Einheitenklasse Reaktor als auch zu der Einheitenklasse Zuführungsbehälter und kann somit sowohl verwendet werden, um Befüllungsfunktionen der Einheitenmodule Reaktor als auch der Einheitenmodule Zuführungsbehälter durchzuführen.
-
Eine Phasenklasse kann man sich generell als eine Softwareroutine oder ein Objekt vorstellen, das von der Batchausführungsroutine aufgerufen wird, um eine in einem Gesamtbatchprozess benötigte Funktion durchzuführen, wie sie das Rezept für diesen Batchprozess definiert. Eine Phasenklasse kann Folgendes aufweisen: Keinen oder mehrere Phaseneingangsparameter, die im Wesentlichen die von der Phasenklassensoftwareroutine oder dem Objekt übergebenen Eingänge von der Batchausführungsroutine oder einer anderen Phasenklasse sind; keinen oder mehrere Phasenausgangsparameter, die im Wesentlichen die Ausgänge der Phasenklassenroutine sind, die der Batchausführungsroutine oder einer anderen Phasenklasse zurückgegeben werden; keine oder mehrere Phasennachrichten, die dem Benutzer anzuzeigende Nachrichten sein können, welche den Ablauf der Phasenklasse betreffen, oder Information, die sich auf andere Phasenklassen bezieht, mit denen die Phasenklasse in einer Weise in Beziehung steht; und keine oder mehrere Phasenalgorithmusparameter, welche die Erzeugung von Parametern in Phasenlogikmodulen (PLM) oder Einheitenphasen bewirken, die auf dieser Phasenklasse basieren. Diese Phasenalgorithmusparameter werden als temporäre Speicherorte oder Variablen während der Ausführung einer Phase verwendet und sind für den Benutzer oder für die Batchausführungsroutine nicht notwendig sichtbar. Die Phasenklasse weist eine oder mehrere Phasenalgorithmusdefinitionen auf (phase algorithm definitions bzw. PDA), die allgemein gesagt die Steuerroutinen sind, die für die Implementierung der Phase verwendet werden. Die Phasenklasse hat außerdem eine Liste von Verweisen auf keine, eine, zwei oder mehr Einheitenklassen, und diese Liste definiert diejenigen Einheitenklassen, auf die diese Phasenklasse und demnach die PAD der Phasenklasse angewendet werden kann. Die Liste von Verweisen der Phasenklasse Befüllen weist sowohl die Einheitenklasse Reaktor als auch die Einheitenklasse Zuführungsbehälter auf.
-
3 stellt eine detailliertere Version von einigen der in 2 dargestellten Objekte und den Beziehungen zwischen diesen Objekte dar. Zwei Einheitenklassen sind in 3 dargestellt, nämlich eine Einheitenklasse Reaktor 50 und eine Einheitenklasse Zuführungsbehälter 52. Die Einheitenklasse Reaktor 50 hat ein Einheitenmodul 54, nämlich Reaktor_01. Obwohl es weitere geben kann, sind sie in 3 lediglich nicht dargestellt. Das Einheitenmodul 54 definiert einige der Reaktorparameter, die der Einheitenklasse Reaktor 50 zugeordnet sind, nämlich dass die Kapazität von Reaktor_01 300 ist und dass Reaktor_01 kein Rührwerk aufweist. Gleichermaßen sind der Einheitenklasse Reaktor 50 zwei Phasenklassen zugeordnet, die eine Phasenklasse Befüllen 56 und eine Phasenklasse Entleeren 58 aufweisen. Die Phasenklasse Befüllen 56 umfasst ein PAD (graphisch an ihrer rechten Seite als Ablaufdiagramm dargestellt), das unter Verwendung von zwei Aliasnamen entworfen wurde, nämlich #EINLASSVENTIL# und #STUFE#. Diese Aliasnamen werden tatsächlich innerhalb der Rechtecke verwendet, die in der PAD der Phasenklasse Befüllen 56 verwendet werden, können aber alternativ irgendwo anders innerhalb der Logik der PAD werden. Die Phasenklasse Befüllen 56 weist außerdem einen als ZIELSTUFE definierten Eingang und einen als ABSCHLUSSSTUFE definierten Ausgang auf. Obwohl die Aliasnamen gekennzeichnet werden, indem sie mit einem Doppelkreuz (#) abgegrenzt oder markiert werden, kann jede andere Kennzeichnung verwendet werden, um einen Aliasnamen zu definieren, der bei der Instantiierung einer Phase ersetzt werden muss. Gleichermaßen weist die Phasenklasse Entleeren 58 eine PAD auf, die an ihrer rechten Seite in graphischer Form dargestellt ist, die Aliasnamen #AUSLASSVENTIL# und #STUFE#, einen als RATE definierten Eingang, einen als ABSCHLUSSSTUFE definierten Ausgang und einen als TATSÄCHLICHE_RATE definierten Algorithmusparameter (der von dem PAD verwendet wird) auf, der während der Ausführung der PAD als temporärer Speicherplatz genutzt werden kann.
-
Wie in 4 erläutert, beginnt eine Rezepteditorroutine 400, die von einem oder mehreren der Prozessoren 21 der Workstations 14 ausgeführt werden kann, die Ausführung bei einem Block 402, bei dem ein Benutzer oder ein Anwender ein Rezept für die Verwendung in dem Prozesssteuerungssystem 10 erstellt oder modifiziert, wobei die Modifikation von zugehörigen Softwareobjekten darin eingeschlossen sein kann. Offensichtlich kann ein Benutzer Rezepte oder andere Softwareobjekte unter Verwendung der in den 1–3 beschriebenen Techniken oder unter Verwendung von irgendeiner anderen geeigneten Technik erstellen oder modifizieren. Nachdem das Rezept erstellt oder geeignet modifiziert worden ist, geht die Steuerung von Block 402 auf Block 406 über. Wie unten im Zusammenhang mit den 5–11 noch genauer diskutiert, kann eine Initialisierungsroutine 404 für die Autorisierung (5) zumindest einmal vor der Ausführung der Rezepteditorroutine 400 ausgeführt werden, oder auch zu irgendeiner anderen Zeit vor der Modifizierung und/oder dem Herunterladen eines Rezeptes oder eines anderen Softwareobjektes auf das System 10. Im Allgemeinen kann die Initialisierung der Autorisierung, ohne darauf beschränkt zu sein, das Spezifizieren von Personen oder Entitäten (beispielsweise Unterzeichnern) oder das Löschen oder Modifizieren der Unterzeichner einschließen, deren Freigabe für die Implementierung eines Rezeptes oder eines anderen Softwareobjektes benötigt wird.
-
Beim Block 406 wird von jedem der während der Initialisierung der Autorisierung spezifizierten Unterzeichner eine Freigabe erbeten, um das bei Block 402 erstellte oder modifizierte Rezept freizugeben. Das Erbitten der Freigabe kann, ohne darauf beschränkt zu sein, das Versenden einer E-Mail an die Unterzeichner, die für die Prüfung des Rezeptes in Verbindung mit der Initialisierungsroutine 404 für die Autorisierung spezifiziert worden sind, die Erzeugung eines Berichtes, welcher den Freigabestatus für jeden der spezifizierten Unterzeichner anzeigt, das sofortige Senden einer Nachricht an diejenigen Unterzeichner, die das Rezept prüfen sollen, oder das Senden einer Benachrichtigung an diese Unterzeichner über irgendeine andere geeignete Kommunikationsmethode einschließen. Nachdem die Freigabe bei Block 406 von jedem Unterzeichner erbeten worden ist, beendet die Rezepteditorroutine 400 die Ausführung oder gibt die Steuerung an eine andere Routine zurück, welche die Rezepteditorroutine 400 aufgerufen hat.
-
Weitere Details der Initialisierungsroutine 404 für die Autorisierung wird nun in Verbindung mit den 5 und 6 beschrieben, die ein Flussdiagramm bzw. die Anzeige eines User-Interfaces (einer Benutzerschnittstelle) für die Initialisierungsroutine 404 der Autorisierung darstellen. Auch wenn die Initialisierungsroutine 404 für die Autorisierung typischerweise einmal beim Hochfahren des Systems ausgeführt wird, kann die Initialisierungsroutine 404 für die Autorisierung bei Bedarf statt dessen auch mehr als einmal ausgeführt werden. Wie in 5 dargestellt, kann ein Benutzer beim Abbrechen/OK-Block 410 wählen, die Ausführung der Routine abzubrechen, sobald die Initialisierungsroutine 404 für die Autorisierung einmal ausgeführt worden ist. Alternativ kann der Benutzer bei Blocks 412, 414 oder 416 wählen, Rezeptunterzeichner hinzuzufügen, zu löschen bzw. zu modifizieren. Nach dem Hinzufügen, dem Löschen oder dem Modifizieren von Unterzeichnern geht die Kontrolle von den Blocks 412, 114 oder 416 weg und ermöglicht dem Benutzer die Auswahl, die Bedienung der Initialisierungsroutine 404 für die Autorisierung abzubrechen oder zu beenden oder wiederum unter Verwendung der Blocks 412–416 Unterzeichner hinzuzufügen, zu löschen oder zu modifizieren. Wenn der Benutzer bei Block 410 wählt, die Initialisierungsroutine 404 für die Autorisierung abzubrechen oder zu beenden, endet die Initialisierungsroutine 404 für die Autorisierung.
-
Wie in 6 dargestellt, weist ein User-Interface 420 einen Reiter 422 für die Initialisierung der Rezeptautorisierung auf, der es einem Benutzer erlaubt, Knöpfe 424, 426 oder 428 zum Hinzufügen, Modifizieren oder Löschen von Unterzeichnern auszuwählen. Die Hinzufügen-, Modifizieren- und Löschen-Knöpfe 424–428 entsprechen den (und können ausgewählt werden, um die dadurch ausgeführten Funktionen aufzurufen) Hinzufügen-, Löschen- und Modifizieren-Blöcken 412–416, die in 5 gezeigt sind. Weitere Details jedes der Blocks 412–416 und damit implizit der Knöpfe 424–428 werden unten in Verbindung mit den 7–11 gegeben. Während Unterzeichner hinzugefügt, modifiziert oder gelöscht werden, wird der Status der Unterzeichner in einer Textbox 430 angezeigt. Wie in 6 dargestellt, weist die Textbox 430 eine Spalte 432 zur Beschreibung des Unterzeichners auf, welche die Namen der Unterzeichner auflistet, welche die Namen von Personen oder Entitäten sein können, und weist außerdem eine Spalte 434 mit Funktionskennungen auf, welche die Funktionskennungen auflistet, welche die zugehörigen Unterzeichner haben müssen, und somit wird der Zugang zu einer Freigabe kontrolliert. Wie in 6 dargestellt, muss das Rezept beispielsweise von der Entwicklung, der Produktion und der Qualitätssicherung geprüft und freigezeichnet werden, was den Funktionskennungen REZEPT_FREIGABE_01 bis REZEPT_FREIGABE_03 entspricht.
-
In 6 sind auch zwei Ankreuzfelder 436 und 438 dargestellt, welchen das Ermöglichen der Rezeptautorisierung und das Ermöglichen der Freigabeweiterleitung an eingebundene Rezepte (d. h. Unterrezepte) entspricht. Wenn im Betrieb das Ankreuzfeld 436 angekreuzt ist, sind die Features zur Ermöglichung der Rezeptautorisierung des Systems eingeschaltet und der Initialisierungsprozess für die Autorisierung ist ermöglicht. Das Ankreuzfeld 438 zeigt an, wenn es nicht angekreuzt ist, dass der Benutzer nicht die Option zur Freigabeweiterleitung hat. Wenn das Ankreuzfeld 438 umgekehrt angekreuzt ist, hat der Benutzer die Option für die Weiterleitung von Freigaben von Unterrezepten. Beispielsweise kann ein Hauptrezept zwei oder mehr Unterrezepte eingebunden haben oder aus ihnen bestehen, an die eine dem Hauptrezept zugeordnete Freigabe automatisch weitergeleitet wird. Eine solche automatische Weiterleitung von Freigaben für Rezepte kann natürlich zu erheblichen Zeiteinsparungen führen, insbesondere bei Rezepten, die eine große Anzahl von Unterrezepten aufweisen.
-
Das User-Interface 420 weist auch Abbrechen- und OK-Knöpfe auf, die mit Bezugszeichen 440 bzw. 442 bezeichnet sind. Die Knöpfe 440 und 442 entsprechen dem Abbrechen/OK-Block 410 in 5 und ermöglichen dem Benutzer, die Initialisierungsroutine 404 für die Autorisierung zu verlassen. Obwohl beide Knöpfe 440 und 442 dem Benutzer ermöglichen, die Initialisierungsroutine 404 für die Autorisierung zu verlassen, beendet der Abbrechen-Knopf 440 die Initialisierungsroutine 404 für die Autorisierung, ohne die Änderungen der Initialisierung der Rezeptautorisierung einzufügen. Umgekehrt erlaubt der OK-Knopf 442 dem Benutzer das Beenden der Initialisierungsroutine 404 für die Autorisierung und speichert die Änderungen an der Initialisierung der Autorisierung, die während der Verwendung des User-Interfaces 420 vorgenommen wurden.
-
Anhand von 7 werden nun weitere Details des Blocks 412 beschrieben, der eine Hinzufügen-Routine darstellt. Die Hinzufügen-Routine 412 startet die Ausführung bei einem Block 450, welche die von dem Benutzer vorgegebene Auswahl der Funktionskennung empfängt. Wie in 8 dargestellt, kann ein graphisches User-Interface oder ein Pop-Up-Fenster 452 eine Box 454 für die Funktionskennung für die Freigabe aufweisen, in die der Benutzer den Namen für die Funktionskennung für die Freigabe eingeben kann. Wie in 8 dargestellt, kann die Box 454 beispielsweise eine Anzeige aufweisen, dass die Auswahl der Funktionskennung für die Freigabe REZEPT_FREIGABE_03 ist.
-
Wie wiederum in 7 erläutert, empfängt nach dem Empfang der Auswahl der Funktionskennung des Blockes 450 ein Block 460 eine von dem Benutzer vorgegebene Beschreibung des Unterzeichners. Wie in dem User-Interface 452 in 8 dargestellt, kann der Benutzer beispielsweise eine Beschreibung für einen Unterzeichner in einem Block 462 eingeben. Beispielhaft ist in dem Block 462 die Beschreibung „Teamleitung” dargestellt, was anzeigt, dass der Benutzer die Teamleitung als einen Unterzeichner hinzufügen möchte, der die Funktionskennung REZEPT_FREIGABE_03 für die Freigabe hat.
-
Nachdem die Auswahl der Funktionskennung und die Beschreibung des Unterzeichners bei den Blöcken 450 bzw. 460 empfangen worden ist, geht die Steuerung auf einen Block 466 über, welcher festlegt, ob entweder die Funktionskennung oder die Beschreibung des Unterzeichners fehlt oder ob die in 8 mit den Bezugszeichen 470 bzw. 472 dargestellten Abbrechen- bzw. OK-Knöpfe ausgewählt worden sind. Wenn die Kennung oder die Beschreibung fehlt, geht die Steuerung von dem Block 466 zu dem Block 450 über. Wenn alternativ der Block 466 feststellt, dass der Abbrechen- oder der OK-Knopf 470 bzw. 472 von dem Benutzer ausgewählt worden ist, beendet die Hinzufügen-Routine 412 ihre Ausführung und gibt die Steuerung an die Initialisierungsroutine 404 für die Autorisierung gemäß 5 zurück. Wie mit Bezug auf das User-Interface 420 von 6 beschrieben, bewirkt die Betätigung des Abbrechen-Knopfes 470 der Hinzufügen-Routine 412, dass ihre Ausführung ohne ein Speichern der während der Ausführung gemachten Änderungen erfolgt. Umgekehrt bewirkt, wie zuvor beschrieben, die Betätigung des OK-Knopfes 472, dass die Hinzufügen-Routine 412 beendet wird und während der Ausführung der Hinzufügen-Routine 412 vorgenommene Änderungen gespeichert werden. Wenn ein neuer Freigabeberechtigter oder Unterzeichner mit Hilfe der Hinzufügen-Routine 412 hinzugefügt wird, werden irgendwelche zuvor freigegebenen Rezepte (d. h. solche Rezepte, für die alle ursprünglich benötigten Freigaben bereits empfangen worden sind) automatisch auf unautorisiert gesetzt, bis eine Freigabe von dem neu hinzugefügten Unterzeichner empfangen worden ist.
-
Weitere Details der Löschen-Routine 414 werden im Zusammenhang mit 9 beschrieben, die in Verbindung mit dem User-Interface 420 gemäß 6 abläuft. Genauer startet die Ausführung der Löschen-Routine 414 bei einem Block 480, der die Auswahl der zu löschenden Beschreibung des Unterzeichners empfängt. Der Benutzer kann eine solche Auswahl vornehmen, indem er eine Beschreibung des Unterzeichners auswählt, die in der Textbox 430 des User-Interfaces 420 gemäß 6 dargestellt ist. Nachdem der Benutzer die zu löschende Beschreibung ausgewählt hat, betätigt der Benutzer dann den Löschen-Knopf 428, um seine Absicht zu erklären, die ausgewählte Beschreibung des Unterzeichners oder den Unterzeichner zu löschen. Nachdem Block 480 die Ausführung beendet hat, geht die Steuerung auf einen Block 482 über, der eine Löschbestätigung empfängt, die von dem Benutzer angefordert wird. Wenn beispielsweise ein Benutzer die zu löschende Beschreibung des Unterzeichners auswählt und den Löschen-Knopf 428 betätigt, kann die Löschen-Routine 414 von dem Benutzer fordern, seine Absicht zu bestätigen, die ausgewählte Beschreibung des Unterzeichners zu löschen, indem dem Benutzer eine User-Interface Graphik auf einem Anzeigeschirm dargestellt wird. Eine solche Graphik kann OK- oder Abbrechen Knöpfe umfassen, wobei die Betätigung (d. h. die Auswahl über ein Maus, eine Tastatur etc.) des OK-Knopfes die Absicht des Benutzers bestätigt, die ausgewählte Beschreibung des Unterzeichners zu löschen, und der Abbrechen-Knopf bricht das Löschen der ausgewählten Beschreibung ab. Nachdem die Bestätigung für das Löschen von dem Block 482 empfangen worden ist, beendet die Löschen-Routine 414 ihre Ausführung und gibt die Steuerung an die Initialisierungsroutine 404 für die Autorisierung zurück.
-
Weitere Details der Modifizieren-Routine 416 gemäß 5 werden im Folgenden in Verbindung mit den 10 und 11 beschrieben. Die Modifizieren-Routine 416 beginnt die Ausführung bei einem Block 484, der von dem Benutzer eine Auswahl der zu modifizierenden Beschreibung des Benutzers empfängt. Beispielsweise kann der Benutzer den Unterzeichner mit dem Namen Qualitätssicherung in 6 auswählen und kann dann den Modifizieren-Knopf 426 betätigen. Nach der Betätigung des Modifizieren-Knopfes 426 kann dem Benutzer ein User-Interface wie beispielsweise das in 11 dargestellte User-Interface 486 angezeigt werden, das eine Box 488 für die Beschreibung des Unterzeichners und eine Box 490 für die Funktionskennung für die Freigabe aufweisen kann. Das User-Interface 486 kann auch OK- und Abbrechen-Knöpfe 492 und 494 aufweisen. Nachdem die Modifizieren-Routine 416 eine Auswahl der zu modifizierenden Beschreibung des Unterzeichners empfangen hat (in diesem Fall ist der Unterzeichner Qualitätssicherung für die Modifizierungen ausgewählt worden), geht die Kontrolle von dem Block 484 zu einem Block 496 über. Der Block 496 empfängt die Modifizierungen für die Beschreibung des Unterzeichners wie beispielsweise Änderungen des Unterzeichnernamens, der Funktionskennung für die Freigabe oder irgendwelche andere geeigneten Änderungen. Nachdem beispielsweise der Benutzer im Block 488 eine Beschreibung eines Unterzeichners vorgegeben hat, kann der Benutzer den Namen des Unterzeichners modifizieren oder kann die im Block 490 dargestellte Funktionskennung für die Freigabe modifizieren und kann dann einen der beiden OK- oder Abbrechen-Knöpfe 492 und 494 auswählen. Wie oben beschrieben, speichert die Betätigung des OK-Knopfes 492 die an der Beschreibung des Unterzeichners vorgenommene Modifizierung. Umgekehrt beendet die Betätigung des Abbrechen-Knopfes 494 die Modifizieren-Routine 416 ohne ein Speichern der vorgenommenen Änderungen. In jedem Fall beendet die Betätigung sowohl des Knopfes 492 als auch 494 die Ausführung der Modifizieren-Routine 416 und gibt die Steuerung an die Intialisierungsroutine 404 für die Autorisierung gemäß 5 zurück. Wie bei der Hinzufügen-Routine 412 führt das Modifizieren eines Unterzeichners oder eines Freigabeberechtigten automatisch dazu, dass zuvor freigegebene Rezepte unautorisiert werden, welche die Freigabe dieses Unterzeichners benötigen.
-
Bisher wurde eine Beschreibung des Hinzufügens, Löschens und Modifizierens von Unterzeichnern oder Rezeptprüfern oder Freigabeberechtigen angegeben. Die beschriebenen Routinen oder solche Routinen, welche die im Zusammenhang mit diesen Routinen beschriebene Funktionalität aufweisen, können innerhalb irgendeiner der Workstations 14 und/oder der Terminals 32 gemäß 1 implementiert werden.
-
Während sich die vorhergehenden Figuren und die Beschreibung auf die Spezifikation von Unterzeichnern bezogen hat, beziehen sich die 12–16 auf die Prüfungs-, Freigabe- oder Zurückweisungsprozesse, die von den Unterzeichnern durchgeführt werden können. Insbesondere können die einen oder mehreren Speicher 20 und 34 Befehle speichern, die von dem einen oder mehreren Prozessoren 21 und 36 ausgeführt werden können, um den Blocks entsprechende Abläufe in den Routinen auszuführen.
-
Wie in 12 erläutert, startet eine Rezeptautorisierungsroutine 500 die Ausführung bei einem Block 502, der auf das zu prüfende Rezept bezogene Unterzeichner- und Statusinformationen anzeigt. Beispielsweise kann das in 13 dargestellte User-Interface 504 eine Text-Box 506 aufweisen, die eine Anzahl von Spalten 508–518 aufweist, welche die Identität des Unterzeichners, den Status, die Art des Benutzers, die Zeit, einen Kommentar und einen Knoten repräsentieren. Die Unterzeichnerspalte 508 listet die für die Freigabe des Rezeptes benötigten Unterschriften und die Statusspalte 510 listet den Zustand der Unterschriften für jeden Unterzeichner auf. Beispielsweise kann der Unterschriftenstatus leer oder offen, freigegeben oder zurückgewiesen sein, wobei ein leerer oder offener Status anzeigen kann, dass der Unterzeichner das Rezept nicht geprüft hat. Die Benutzerspalte 512 listet die Art des Benutzers auf, der für die am kürzesten zurückliegende Unterschriftsänderung verantwortlich ist. Die Zeitspalte 514 listet die Zeit auf, zu der diese am kürzesten zurückliegende Veränderung der Unterschrift vorgenommen wurde. Die Kommentarspalte 516 listet irgendwelche Kommentare auf, die der Unterzeichner gemacht hat, als er das Rezept freigegeben oder zurückgewiesen hat, und der Knoten 518 stellt den Systemknoten dar, an dem der Unterzeichner das Rezept freigegeben oder zurückgewiesen hat. Beispielsweise kann der Knoten eines der Terminals 32 und/oder eine der Workstations 14 gemäß 1 sein. Zusätzlich zu dem Textblock 506 kann das User-Interface 504 Schließen-, Freigeben-, Widerrufen- und Entfernen-Knöpfe 520–526 aufweisen, die unten in Verbindung mit der Rezeptautorisierungsroutine 500 gemäß 12 beschrieben werden.
-
Nachdem der Block 502 die Unterzeichner- und Statusinformationen angezeigt hat, empfängt ein Block 530 die Auswahl des Unterzeichners, was von dem Benutzer dadurch bekundet werden kann, dass er einen der Knöpfe 520–526 auswählt. Wenn insbesondere der Benutzer den Schließen-Knopf 520 betätigt, geht die Steuerung der Rezeptautorisierungsroutine 500 von dem Block 530 zu einem Block 540 über, welcher das User-Interface 504 schließt, die Ausführung der Rezeptautorisierungsroutine 500 beendet und die Steuerung einer Routine zurückgibt, welche die Rezeptautorisierungsroutine 500 aufgerufen hat.
-
Wenn alternativ der Benutzer den Freigeben-Knopf 522 betätigt, geht die Steuerung von dem Block 530 zu einem Block 550 über, der eine Freigeben-Routine repräsentiert. Wie in 14 dargestellt, startet die Freigaberoutine 550 die Ausführung bei einem Block 552, der einen von dem Benutzer vorgegebenen Benutzernamen und ein Passwort empfängt. Ein User-Interface 554, von dem ein Beispiel in 15 dargestellt ist, kann Benutzernamen- und Passwort-Boxen 556 und 558 aufweisen, in die der Benutzer seinen Benutzernamen und sein Passwort eingeben kann.
-
Nachdem der Block 552 seine Ausführung beendet hat, geht die Steuerung zu einem Block 560 über, welcher Kommentare des Benutzers empfängt, die während der Freigabe gemacht wurden. Beispielsweise kann das User-Interface 554 gemäß 15 eine Textbox 562 aufweisen, in welche Kommentare eingegeben werden können. Nachdem der Block 560 seine Ausführung beendet hat, entscheidet ein Block 561, ob der Benutzer autorisiert ist. Der bei Block 561 durchgeführte Autorisierungstest kann bestätigen, dass der Benutzernahme und/oder das Passwort gültig ist, das bei Block 552 empfangen wurde, und/oder ob der diesen Benutzernamen und Passwort zugehörige Benutzer für eine derartige Freigabe autorisiert ist. Wenn bei Block 561 festgestellt wird, dass der Benutzer autorisiert ist, geht die Steuerung auf eine Block 566 über. Block 566 aktualisiert die Statusinformationen, um die Freigaben zu berücksichtigen. Beispielsweise steht in der Textbox 562 der Textkommentar „Fertig für die Produktion.”, der auch in 13 als derjenige Kommentar dargestellt ist, den der Unterzeichner für die Produktion gemacht hat, wenn das Rezept nach der Ausführung des Blocks 566 freigegeben ist. Wenn bei Block 561 festgestellt wird, dass der Benutzername oder das Passwort oder beides nicht autorisiert ist, das bei Block 552 empfangen wurde, endet die Freigabe-Routine 550.
-
Wie schon im Zusammenhang mit vielen der vorigen User-Interface-Anzeigen beschrieben, weist das User-Interface 554 gemäß 15 OK- und Abbrechen-Knöpfe 568 und 570 auf, welche verwendet werden können, um die Ausführung der Freigaberoutine 550 zu beenden, wobei die während der Ausführung der Routine vorgenommenen Änderungen entweder gespeichert oder verworfen werden. Wie in 15 dargestellt, kann zusätzlich ein Auswahlfeld 572 vorgesehen sein, welches dem Benutzer ermöglicht, sich für eine Weiterleitung der Freigabe an etwaige eingeschlossene oder Unterrezepte zu entscheiden.
-
Wie ein Rückblick auf die 12 und 13 zeigt, geht die Steuerung von dem Block 530 auf einen Block 580 der Rezeptautorisierungsroutine 550 über, wenn der Benutzer den Zurückweisen-Knopf 524 gemäß 13 betätigt. Block 580 repräsentiert eine Zurückweisen-Routine, deren Details in 16 dargestellt sind. Wie in 16 dargestellt, beginnt die Ausführung der Zurückweisen-Routine 580 bei einem Block 582, wo der Benutzer einer Benutzernamen und ein Passwort eingibt, bevor die Steuerung auf eine Block 584 übergeht. Beim Block 584 kann der Unterzeichner Kommentare eingeben, die während des Prozesses der Zurückweisung des Rezeptes gemacht wurden. Die Abläufe der Blocks 582 und 584 ist ähnlich den Abläufen der Blocks 552 und 560 der Freigabe-Routine 550, die in 14 dargestellt ist, außer dass die Blocks 582 und 584 in Verbindung mit der Zurückweisung des Rezeptes verwendet werden. Nachdem der Block 584 die Ausführung beendet hat, geht die Steuerung auf einen Block 585 über, der einen Autorisierungstest durchführt, der ähnlich zu dem ist, der bei dem in 15 gezeigten Block 561 durchgeführt wird. Wenn bei Block 585 entschieden wird, dass der Benutzer autorisiert ist, geht die Steuerung auf einen Block 586 über.
-
Der Block 586 aktualisiert die Statusinformationen, um die Zurückweisung des Rezeptes durch den Benutzer zu berücksichtigen. Der Block 586 für die Aktualisierung der Statusinformation kann Informationen erzeugen, die auf dem User-Interface 504 gemäß 13 berücksichtigt werden, um die Tatsache zu berücksichtigen, dass der Unterzeichner ein Rezept zurückgewiesen hat. Wenn auch nicht in den Figuren dargestellt, kann die Zurückweisungsroutine 580 auch ein graphisches User-Interface ähnlich dem User-Interface 554 gemäß 15 verwenden, das für die Freigabe von Rezepten verwendet wird.
-
Wie nochmals unter Rückgriff auf die 12 und 13 erläutert, geht die Steuerung von dem Block 530 auf einen Block 590 der Rezeptautorisierungsroutine 500 über, wenn ein Benutzer den Entfernen-Knopf 526 gemäß 13 betätigt. Der Block 590 kann verwendet werden, um eine Unterschrift zu entfernen. Beispielsweise kann einer der in 13 dargestellten Unterzeichner von einem Benutzer ausgewählt und unter Verwendung des Knopfes 526 entfernt werden. Wenn jedoch ein Rezept einmal für die Ausführung von beispielsweise dem Regler 12 (1) oder der Workstation 14 (1) heruntergeladen worden ist, kann der Effekt einer Freigabeunterschrift nicht mehr widerrufen werden. Mit anderen Worten kann eine Unterschrift (d. h. eine Freigabe) nicht entfernt oder widerrufen werden, sobald ein Rezept (oder ein anderes Softwareobjekt) heruntergeladen worden ist.
-
Während sich die vorstehende Beschreibung auf die Auswahl von Unterzeichnern und auf die Prüfung von Rezepten bezieht, kann ein User-Interface 600, wie es in 17 dargestellt ist, verwendet werden, um über den Status von Rezepten innerhalb des Prozesssteuerungssystems 10 zu berichten. beispielsweise kann das User-Interface 600 eine Reihe von Spalten 602–610 aufweisen, die jeweils den Rezeptnamen, die Produktion, die Entwicklung, die Qualitätssicherung und die Teamleitung repräsentieren. Kurz gesagt listet die Rezeptnamensspalte 602 alle nicht freigegebenen Rezepte auf, und die Spalten 604–610 listen den Status jedes Rezeptes bezüglich eines jeden Prüfers oder einer jeden Prüfungsentität auf. Beispielsweise ist das Rezept mit dem Namen „OP_LADEN” in allen Bereichen Produktion, Entwicklung, Qualitätssicherung und Teamleitung offen. Im Gegensatz dazu haben Produktion, Entwicklung und Teamleitung das Rezept „PR_MALEN” freigegeben, aber es ist noch nicht von der Qualitätssicherung freigegeben worden. Dementsprechend ist das Rezept „PR_MALEN” immer noch nicht freigegeben. Das User-Interface 600 kann auch Schließen- und Drucken-Knöpfe 612 und 614 aufweisen, die verwendet werden können, um das User-Interface 600 zu schließen oder um das User-Interface auszudrucken, um die in den Spalten 602–610 enthaltenen Informationen anzuzeigen.
-
Ist ein Rezept einmal von allen Unterzeichnern geprüft und freigegeben, kann das Rezept auf einen oder mehrere der Regler 12 heruntergeladen oder dort implementiert werden, wie in 1 dargestellt. Eine Herunterladen-Routine 630, wie in 18 dargestellt, ist ein Verfahren, wie das Herunterladen ausgeführt werden kann. Die Herunterladen-Routine 630 beginnt die Ausführung bei einem Block 632, der ein Skript für das Herunterladen erzeugt. Nachdem das Skript für das Herunterladen bei dem Block 632 erzeugt worden ist, geht die Kontrolle auf einen Block 634 über, welcher festlegt, ob das Rezept nicht ausgecheckt ist (d. h. es ist eingecheckt) oder ob der Benutzer einen Schlüssel angegeben hat, der das Herunterladen eines Rezeptes auch dann erlaubt, wenn das Rezept ausgecheckt ist. Software für die Versionskontrolle wie die Software, die in „Version Control and Audit Trail in a Process Control System” offenbart ist, kann in Verbindung mit der Herunterladen-Routine 630 verwendet werden. Wenn der Block 634 feststellt, dass das Rezept ausgecheckt ist und dass kein Schlüssel angegeben wurde, geht die Steuerung auf einen Block 636 über, der das Herunterladen abbricht und die Ausführung der Herunterladen-Routine 630 abbricht. Wenn andererseits das Rezept nicht ausgecheckt ist oder der Schlüssel angegeben wurde, geht die Steuerung von dem Block 634 auf einen Block 638 über, welcher feststellt, ob das Rezept freigegeben ist oder ob der Benutzer einen speziellen Schlüssel angegeben hat, der das Herunterladen von nicht autorisierten Rezepten erlaubt. Die Autorisierung eines Rezeptes kann einschließen, dass sichergestellt wurde, dass alle Unterzeichner das Rezept freigegeben haben, ist aber darauf nicht beschränkt. Wenn der Block 638 festlegt, dass das Rezept nicht autorisiert ist und dass der Schlüssel nicht angegeben wurde, geht die Kontrolle auf den Block 636 über, der das Herunterladen abbricht, bevor er die Herunterladen-Routine 630 beendet. Wenn alternativ der Block 638 festlegt, dass das Rezept autorisiert ist oder dass der Schlüssel angegeben wurde, geht die Steuerung auf einen Block 640 über, der einen Herunterladen-Kennsatz erzeugt. Der Herunterladen-Kennsatz kann eine oder mehrere Kommentaraussagen oder eine ähnliche Textinformation sein, die an die heruntergeladenen Elemente angefügt wird und die Zeit, das Datum, die Version und den Initiator (oder Benutzer) des Herunterladens einschließt. Zusätzlich umfasst der Herunterladen-Kennsatz eine detaillierte Liste der einzelnen Elemente (d. h. Rezepte) auf, die heruntergeladen worden sind. Das Rezept wird anschließend bei einem Block 642 auf das Laufzeit- bzw. Produktivsystem geschickt, welches als die Regler 12 gemäß 1 ausgeführt sein kann. Nach der Ausführung des Blocks 642 beendet die Herunterladen-Routine 630 die Ausführung und gibt die Steuerung an die Routine zurück, die sie aufgerufen hat.
-
Aus dem Vorstehenden geht hervor, dass ein aktuell nicht freigegebenes Softwareobjekt nicht auf das System 10 heruntergeladen oder darauf implementiert werden kann, ehe alle diesem Softwareobjekt zugeordneten Unterzeichner oder Freigabeberechtigten das Softwareobjekt freigegeben haben. Deshalb muss ein neues Softwareobjekt oder Rezept beispielsweise von einer festgelegten Liste oder Gruppe von Personen und/oder anderen Entitäten freigegeben werden (d. h. eine Liste von Personen und/oder anderen Entitäten, die von der Initialisierungsroutine 404 für die Autorisierung gemäß 5 erzeugt worden sind). Zusätzlich wird ein bereits freigegebenes Softwareobjekt oder Rezept, welches modifiziert worden ist, automatisch nicht autorisiert und muss daher von allen zugehörigen Unterzeichnern oder Freigabeberechtigten erneut freigegeben werden, damit das modifizierte Softwareobjekt oder Rezept heruntergeladen wird, wie beispielhaft in den Blocks 638 und 640 gemäß 18 dargestellt.
