DE112004001716B4

DE112004001716B4 - Verfahren zur Freigabe von Softwareobjekten zur Verwendung in einem sicherheitsgerichteten System und Freigabesystem für Softwareobjekte zur Verwendung in einem Prozesssteuersystem mit einem Prozessor

Info

Publication number: DE112004001716B4
Application number: DE112004001716.5T
Authority: DE
Inventors: Gary K. Law; David L. Deitz; Trevor Duncan Schleiss; Julian K. Naidoo
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2003-09-19
Filing date: 2004-01-16
Publication date: 2021-02-04
Anticipated expiration: 2024-01-17
Also published as: US20040243260A1; WO2005038544A3; CN1846206A; GB0604560D0; JP2007518145A; DE112004001716T5; JP4672663B2; WO2005038544A2; US7076312B2; GB2421332A

Abstract

Verfahren zur Freigabe von Softwareobjekten zur Verwendung in einem sicherheitsgerichteten System, wobei das Verfahren Folgendes umfasst:Erhalt von elektronischer Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, deren Freigabe vor der Implementierung eines Softwareobjekts in einem sicherheitsgerichteten System als Reaktion auf eine in einer Softwareobjekt-Entwicklungs-umgebung an dem Softwareobjekt vorgenommen Änderung erforderlich ist, wobei der Erhalt der elektronischen Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, die Bestimmung eines Sicherheitsgewährleistungs-Pegels aus einem bei Erhalt der elektronischen Identifikationsinformationen bestimmten Risikoreduktionsfaktor einschließt und die Auswahl der Entitätengruppe aufgrund des Sicherheitsgewährleistungs-Pegels einschließt;elektronische Übertragung einer Prüfanforderung zum Softwareobjekt an jede der Entitäten in der Entitätengruppe;Empfang einer elektronischen Angabe bezüglich der Freigabe oder Nichtfreigabe des Softwareobjekts von jeder Entität in der Entitätengruppe; undVerhinderung der Implementierung des Softwareobjekts im sicherheitsgerichteten System, bis jede Entität in der Entitätengruppe eine elektronische Angabe zur Freigabe des Softwareobjekts bereitstellt.

Description

ZUSAMMENHÄNGENDE ANMELDUNGEN
TECHNISCHES GEBIET
Die vorliegende Anmeldung behandelt Freigabesysteme für und Verfahren zur Freigabe von Softwareobjekten und insbesondere zur Verwendung in einem Prozesssteuersystem mit einem Prozessor und zur Verwendung in einem sicherheitsgerichteten System.
HINTERGRUND
Prozesssteuersysteme enthalten üblicherweise zahlreiche Gruppen von Einrichtungen, die zur Ausführung von Fertigungs- und anderen Steuerprozessen verwendet werden. Die Einrichtungsgruppen sind mit Steuerungen verbunden, die Prozesssteuer-Softwareanweisungen zur Beeinflussung der Einrichtungen auf bestimmte Weise enthalten, um sich auf die Fertigungs- oder Steuerprozesse auszuwirken. Prozesssteuersoftware kann durch in der Steuerung (oder in einem anderen Computer) ausgeführte Softwareobjekte implementiert sein, um eine Vielzahl von Steuerfunktionen auszuführen. Beispielsweise können in einigen Prozesssteuersituationen Softwareobjekte zur Implementierung unterschiedlicher Phasen eingerichtet sein, die generell auf verschiedene Arten von Prozessschritten bezoger sind. Insbesondere kann ein Softwareobjekt, das eine Mischphase implementiert, Hardware zugeordnet sein, die einen Mischschritt eines Prozesses ausführt. Es wird als verständlich vorausgesetzt, dass jedes Softwareobjekt, das eine Phase implementiert, bestimmte eigenständige Funktionen ausführt und zur Implementierung eines komplexeren Steuerverfahrens mit anderen Objekten kommuniziert.
Bei der Festlegung oder Entwicklung eines Steuerverfahrens, beispielsweise zur Verwendung in einem Batch-Prozess, kann ein Entwickler mit Template-Softwareobjekten beginnen, die generische Steuerlogik zur Implementierung einer bestimmten Funktion enthalten, wie z.B. einer Phase im Batch-Prozess. Wegen der generischen Natur dieser Template-Softwareobjekte müssen die Softwareobjekte vor der Verwendung in einer bestimmten Prozesssteuerumgebung auf der Grundlage der Besonderheiten des Schritts, den sie ausführen sollen, abgeändert bzw. angepasst werden. Beispielsweise muss eine Mischphase, die allgemein zum Betrieb von Mischeinrichtungen eingerichtet ist, so angepasst werden, dass eine bestimmte Mischeinrichtung über festgelegte Zeiträume mit festgelegten Geschwindigkeiten betrieben wird. Zur Anpassung bzw. Änderung von Phasen werden normalerweise Rezepturen verwendet. Wie der Name andeutet, enthalten Rezepturen Anweisungsgruppen, die heruntergeladen werden, um Steuerhardware zur Ausführung spezifischer Aufgaben zu bearbeiten, wie z.B. für die Herstellung von Keksen, die Produktion von Pharmazeutika oder die Steuerung anderer Prozesse. Rezepturen sind normalerweise spezifischer als Phasen, und zwar ist in ihnen die Verwendung von Phasen enthalten. Eine Rezeptur zum Backen von Keksen kann einen Mischschritt enthalten, der durch eine Mischphase ausgeführt werden könnte. Im Gegensatz zur Mischphase gibt aber die Rezeptur zum Backen von Keksen die Dauer und die Geschwindigkeit an, die für die Mischung gelten sollen. Dementsprechend gibt die Rezeptur die Parameter vor, die den Betrieb der Mischphase festlegen.
Auf ähnliche Weise können Softwareobjekte zur Verwendung in sicherheitsgerichteten Systemen angelegt werden, die zur Bereitstellung von Sicherheits- oder Abschaltprozeduren oder anderen sicherheitsbezogenen Funktionen in einer von einem separaten Prozesssteuersystem kontrollierten verfahrenstechnischen Anlage verwendet werden. Normalerweise kann ein sicherheitsgerichtetes System eine oder mehrere Sicherheitssteuerungen haben, die unter Verwendung von sicherheitsbezogenen Softwareobjekten zur Erkennung von schädlichen, gefährlichen oder unerwünschten Bedingungen in der verfahrenstechnischen Anlage und zur Ausführung bestimmter Vorgänge programmiert sind, wie z.B. des Abschaltens des Prozesses, der Verfahrensflussumleitung innerhalb des Prozesses, der Abschaltung von Energie usw., wenn eine derartige Bedingung erkannt wird.
Wie unmittelbar verständlich ist, kann die Änderung einer von einem Prozesssteuersystem ausgeführten Rezeptur oder die Änderung eines Softwareobjekts eines Sicherheitssystems den Betrieb des Prozesssteuersystems bzw. des Sicherheitssystems drastisch beeinflussen. Beispielsweise kann das Herunterladen einer Rezeptur, die versehentlich geändert oder sonstwie auf nicht autorisierte Weise bearbeitet wurde, die Ausgabe einer verfahrenstechnischen Anlage negativ beeinflussen, mit der Folge, dass die Produkte nicht den Produktspezifikationen entsprechen und demzufolge zu Gewinnverlust führen. Während die Änderung einer Rezeptur (die als Softwareobjekt implementiert sein kann) für Produkte wie beispielsweise Kekse Backwaren ergeben kann, die offensichtlich fehlerhaft sind (z.B. nicht ausreichend gebacken, ohne ausreichende Schokoladenstückchen usw.), führen nicht alle Rezepturänderungen zu Produkten mit unmittelbar erkennbaren Defekten. Beispielsweise sind Kekse mit zu viel Salz möglicherweise nicht leicht während des Produktionsprozesses zu erkennen. Doch die Verbraucher können den Salzgehalt der Kekse bemerken und sich beim Hersteller beschweren, der dann bestimmen kann, dass die Rezeptur der Kekse in inakzeptabler Weise geändert war, was zu einem Rückruf der Kekse führt. Während bei Fällen wie der Keksherstellung die nicht autorisierte Änderung der Rezeptur schlimmstenfalls zu einer Unzufriedenheit der Verbraucher führt, kann die nicht autorisierte Änderung von Rezepturen beispielsweise bei der Produktion von Pharmazeutika schwerwiegendere Auswirkungen haben. Insbesondere kann eine Rezepturänderung, die die Mengen oder die Zusammensetzung eines Arzneimittels ändert, das daraus entstehende Arzneimittel unwirksam oder toxisch machen. Zudem ist die Änderung der Zusammensetzung von Arzneimitteln, anders als bei der Menge von Schokoladenstückchen in Keksen, nicht leicht zu erkennen, da das Arzneimittel äußerlich die gleiche Farbe und Konsistenz wie ein nicht abgeändertes bzw. korrekt hergestelltes Arzneimittel haben kann.
Auf ähnliche Weise kann die nicht autorisierte oder inkorrekte Änderung von in Sicherheitssystemen eingesetzten Softwareobjekten dazu führen, dass eine Gefahrenbedingung nicht erkannt wird oder dass als Reaktion auf eine Gefahrenbedingung ein ungeeigneter Vorgang ausgeführt wird, wodurch Beschäftigte oder Anlieger in der Nähe der Anlage einer Lebensgefahr ausgesetzt sein könnten, von Beschädigungen der Anlage selbst ganz abgesehen. Zusätzlich kann ein fehlerhaftes Softwareobjekt eines Sicherheitssystems fälschlich eine Gefahrenbedingung erkennen und das System abschalten, wenn tatsächlich gar keine Gefahrenbedingung vorliegt.
Da Produktionslinien in Anlagen normalerweise erhebliche Investitionen in Bezug auf Produktionskapazität, Zeit und/oder Material bedeuten, kann die Notwendigkeit, wegen einer fehlerhaften Rezeptur oder einer Fehlaktivierung des Sicherheitssystems eine laufende Produktion zu verwerfen, wesentliche negative finanzielle Auswirkungen für die den Produktionsbetrieb ausführende Entität wie auch für andere Entitäten, die auf den Eingang von beim Produktionsbetrieb erzeugten Produkten warten, haben. Beispielsweise erfordern Rezepturen zur Herstellung von Produkten, die eine Gärung beinhalten, wie z.B. Wein, Bier, Käse usw., oft eine wochen- oder monatelange Verarbeitungszeit sowie wesentliche materielle Investitionen.
Rezepturen für Prozesssteuersysteme sowie weitere Softwaremodule oder -objekte einschließlich Softwareobjekten in Sicherheitssystemen werden normalerweise von Ingenieuren oder Wissenschaftlern geschrieben, die von verschiedenen Bereichen wie z.B. von Forschungs- oder Produktionsgruppen die Freigabe der Rezeptur oder der Sicherheitssystem-Software anfordern, bevor diese in das Prozesssteuersystem oder das Sicherheitssystem geladen wird. Der Freigabeprozess für Prozesssteuersystem-Software wird jedoch normalerweise durch den Umlauf eines Memos oder einer Freigabeanforderung und in einigen Fällen durch die Anforderung einer Eingabe auf eher informelle Weise ausgeführt. Zudem gibt es, abgesehen von einer Sachkenntnis bezüglich des Prozesssteuersystems und der dort implementierten Rezepturen und sonstigen Softwareobjekte, selten einen Hinderungsgrund, um das Laden von nicht freigegebener Software in das Prozesssteuersystem oder das Sicherheitssystem zur Online-Verwendung in der verfahrenstechnischen Anlage zu verhindern.
In Einrichtungen, die sicherheitsgerichtete Systeme verwenden, wie z.B. in Öl- und Gasraffinerien, wurde versucht, Standardarbeitsanweisungen (Standard Operating Procedures/SOPs) zu implementieren, die das manuelle Abzeichnen der Freigabe von bestimmten Softwareteilen durch eine oder mehrere Personen in der Entität erfordern, bevor die Software in einem Produktionssystem ausgeführt werden kann. So fordert der Standardisierungsentwurf (Draft Standard) IEC 615511 eine solche Freigabe zusätzlich zur Definition unterschiedlicher Freigabestufen für unterschiedliche funktionale Sicherheitspegel (Safety Integrity Levels/SILs). Beispielsweise kann der Validierungsplan für eine Einrichtung SOPs umfassen, die Sicherheitsfunktionen erfordern, welche durch das sicherheitsgerichtete System ausgeführt werden sollen und bei einem SIL-Pegel von 2 oder niedriger durch einen gleich gestellten Mitarbeiter des gleichen Bereichs bzw. bei einem SIL-Pegel von 3 oder höher durch einen gleich gestellten Mitarbeiter eines anderen Bereichs freigegeben werden müssen.
Ein SIL-Pegel ist bekanntlich eine in der Norm IEC 61508 definierte Maßeinheit, die die Integrität eines Systems bezüglich der Frage definiert, wie verlässlich das System die dafür vorgesehenen Vorgänge zum dafür vorgesehenen Zeitpunkt ausführen wird. Insbesondere ist der SIL-Pegel durch die mittlere Versagenswahrscheinlichkeit (PFDavg) definiert. Der Risikoreduktionsfaktor, der zum Kehrwert des PFDavg-Werts in Beziehung steht, definiert den Unterschied zwischen dem Prozessrisiko vor dem Einsatz einer sicherheitsrelevanten Funktion und der „tolerierbaren Risikostufe“, die für den betreffenden Prozess oder Ausrüstungsgegenstand erreicht werden muss. Grundsätzlich ist der Risikoreduktionsfaktor das „uneingeschränkte Risiko“ ohne eine sicherheitsrelevante Funktion, geteilt durch das festgelegte „tolerierbare Risiko“. Sowohl der Risikoreduktionsfaktor als auch der SIL-Pegel sind für alle unterschiedlichen sicherheitsrelevanten Funktionen in einem Sicherheitssystem definiert, wobei für jedes Gefahrenszenario eine individuelle sicherheitsrelevante Funktion zur Angabe eines Bedarfs mit anschließender Ausführung vorgesehen ist, um das System in einen sicheren Zustand zu bringen.
In Einrichtungen, bei denen ein Freigabeprozess für sicherheitsrelevante Funktionen implementiert ist, werden Freigaben normalerweise mit einem der beiden möglichen Ansätze erteilt, nämlich dem manuellen Verfahren oder dem elektronischen Verfahren. Beim manuellen Verfahren wird eine gedruckte Ausfertigung des zur Freigabe anstehenden Softwareobjekts (d.h. eine gedruckte Version der Sicherheitsfunktionssoftware) manuell einem der Approver zur Prüfung vorgelegt, und alle Freigabeunterschriften werden manuell in Papierform gesammelt. Beim elektronischen Verfahren wird ein elektronisches Dokumentenmanagementsystem verwendet, um jedem der vorgesehenen Approver eine elektronische Version des Softwareobjekts (d.h. eine Reihe von Bildschirmmasken oder eine sonstige Dokumentation auf der Grundlage von Text und Grafik, die die Software beschreibt) zur Prüfung vorzulegen. In diesem Fall werden alle Freigabesignaturen in einem elektronischen Format erfasst.
Bei diesen beiden Verfahren gibt es jedoch schwerwiegende Unzulänglichkeiten. Insbesondere gibt es keine direkte Verknüpfung zwischen dem dokumentgestützten Freigabeprozess und dem sicherheitsrelevanten System, in dem die Software ausgeführt wird. Da der dokumentgestützte Freigabeprozess außerhalb des sicherheitsrelevanten Systems erfolgt, können die Approver das Softwareobjekt, dessen Freigabe von ihnen angefordert wird, nicht in seiner nativen Umgebung prüfen (d.h. innerhalb des sicherheitsrelevanten Systems), und dementsprechend kann es Probleme hinsichtlich der Genauigkeit des geprüften Dokuments geben. Da der dokumentgestützte Freigabeprozess außerhalb des sicherheitsrelevanten Systems bzw. des damit zusammenhängenden Entwicklungssystems erfolgt, gibt es ferner keine Mechanismen im sicherheitsrelevanten System, die gewährleisten könnten, dass ein nicht freigegebenes Softwareobjekt vor dem Vorliegen aller Freigaben nicht ausgeführt werden kann oder dass alle vorangegangenen Freigaben für ein Softwareobjekt widerrufen werden (d.h. dass die Software in den nicht freigegebenen Zustand übergeht), falls am Softwareobjekt eine Änderung vorgenommen wird.
Zusätzlich macht es ein separates System für Freigaben und Sicherheitsplanung für das System unmöglich, im Audit-Trail der Softwareentwicklung zum Softwareobjekt einen Datensatz der Freigaben zu erfassen. Da das Freigabesystem nicht mit dem sicherheitsrelevanten System verknüpft ist, müssen zudem beide Systeme unabhängig validiert werden, was zeitaufwendig und repetitiv ist.
Der Artikel „TÜV-Prüfung der Sicherheit und Fehlertoleranz elektronischer Steuerungen“ von Herrn Ekkehard Pofahl aus dem Magazin Automatisierungstechnik 50 (2002) 8 bezieht sich auf ein Änderungsmanagement-Verfahren. Hierbei muss jede Änderung z.B. von Anwenderprogrammen zunächst spezifiziert und dann formal abgenommen werden.
Die Druckschrift WO 01/88 757 A1 beschreibt ein Verfahren zur Durchsetzung des Workflow-Prozesses für die Entwicklung und Wartung von Websites. Die Entwicklung und Pflege einer Website kann die konzertierten Bemühungen mehrerer Personen umfassen. Damit die Arbeit vorhersehbar und geordnet verläuft, werden Aufgaben entsprechend einem Workflow zugewiesen und ausgeführt. Um einen bestimmten Workflow zu erzwingen, stellt die vorliegende Erfindung eine Umgebung bereit, die den Fortschritt der Arbeit gemäß dem Workflow einschränkt. Ein Administrator entwickelt eine Workflowdatei, die festlegt, wie die Bemühungen der Benutzer voranschreiten sollen. Dementsprechend hat der Webmaster die Kontrolle über die Prozesse, mit denen die Website entwickelt und aktualisiert wird, erhöht. Infolgedessen verläuft die Website-Entwicklung auch dann effizient, wenn viele Personen an den Bemühungen beteiligt sind.
Die Aufgabe der vorliegenden Erfindung ist den Schutz eines Maschinenbetriebs und des Bedienpersonals zu verbessern.
Hierzu wird zur Lösung dieser Aufgabe ein Verfahren nach Anspruch 1 sowie ein Freigabesystem nach Anspruch 20 bereitgestellt, die direkt zur Verbesserung der Sicherheit des Maschinenbetriebs und des Bedienpersonals beitragen.
ZUSAMMENFASSUNG
Im Detail wird ein Verfahren zur Freigabe von Softwareobjekten zur Verwendung in einem sicherheitsgerichteten System angegeben, wobei das Verfahren Folgendes umfasst:

Erhalt von elektronischer Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, deren Freigabe vor der Implementierung eines Softwareobjekts in einem sicherheitsgerichteten System als Reaktion auf eine in einer Softwareobjekt-Entwicklungs-umgebung an dem Softwareobjekt vorgenommen Änderung erforderlich ist, wobei der Erhalt der elektronischen Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, die Bestimmung eines Sicherheitsgewährleistungs-Pegels aus einem bei Erhalt der elektronischen Identifikationsinformationen bestimmten Risikoreduktionsfaktor einschließt und die Auswahl der Entitätengruppe aufgrund des Sicherheitsgewährleistungs-Pegels einschließt;
elektronische Übertragung einer Prüfanforderung zum Softwareobjekt an jede der Entitäten in der Entitätengruppe;
Empfang einer elektronischen Angabe bezüglich der Freigabe oder Nichtfreigabe des Softwareobjekts von jeder Entität in der Entitätengruppe; und
Verhinderung der Implementierung des Softwareobjekts im sicherheitsgerichteten System, bis jede Entität in der Entitätengruppe eine elektronische Angabe zur Freigabe des Softwareobjekts bereitstellt.

Hinsichtlich des Freigabesystems für Softwareobjekte zur Verwendung in einem Prozesssteuersystem mit einem Prozessor umfasst dieses:

ein computerlesbares Medium; und
auf dem computerlesbaren Medium gespeicherte und für die Ausführung durch den - Prozessor eingerichtete Software für folgende Aufgaben:
- Erhalt von elektronischer Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, deren Freigabe vor der Implementierung eines Softwareobjekts erforderlich ist, online im Prozesssteuersystem, nachdem in einer Softwareobjekt-Entwicklungsumgebung eine Änderung am Softwareobjekt vorgenommen wurde, wobei bei Erhalt der elektronischen Identifikationsinformationen, die die Gruppe von Entitäten repräsentiert, ein Sicherheitsgewährleistungs-Pegels aus einem bei Erhalt der elektronischen Identifikationsinformation bestimmten Risikoreduktionsfaktor bestimmt wird und
- die Entitätengruppe aufgrund des Sicherheitsgewährleistungs-Pegels ausgewählt wird;
- elektronische Übertragung einer Prüfanforderung zum Softwareobjekt an jede der Entitäten in der Entitätengruppe;
- Empfang einer elektronischen Angabe bezüglich der Freigabe oder Nichtfreigabe des Softwareobjekts von jeder Entität in der Entitätengruppe; und
- Verhinderung der Implementierung des Softwareobjekts im sicherheitsgerichteten System, bis jede Entität in der Entitätengruppe eine elektronische Angabe zur Freigabe des Softwareobjekts bereitstellt.

In Abhängigkeit vom Erhalt einer elektronischen Angabe, dass mindestens eine Entität aus einer Vielzahl von Entitäten das Softwareobjekt nicht freigegeben hat, oder falls das Softwareobjekt geändert oder auf sonstige Weise bearbeitet wurde, können das System und das Verfahren zur Freigabe von Softwareobjekten für die Verwendung in einem Prozesssteuer- oder Sicherheitssystem kann auch oder stattdessen bestimmen, dass ein Softwareobjekt nicht freigegeben ist. In Abhängigkeit vom Erhalt einer weiteren elektronischen Angabe, dass alle Entitäten der Vielzahl von Entitäten das Softwareobjekt freigegeben haben, können das System und das Verfahren anschließend bestimmen, dass das Softwareobjekt freigegeben ist, und nach dem Vorliegen dieser Freigabe können das System und das Verfahren das Laden des Softwareobjekts in das Prozesssteuer- oder Sicherheitssystem freigeben.
Figurenliste

1 ist ein partielles Blockdiagramm eines Prozesssteuersystems, das ein integriertes elektronisches Freigabesystem für Softwareobjekte enthält, um eines oder mehrere Steuersoftwareobjekte freizugeben, die die Steuerung von Prozessvorrichtungen ausführen.
2 ist ein Blockdiagramm einer Objektstruktur mit der Darstellung einer typischen logischen Hierarchie oder Konfiguration des in 1 wiedergegebenen Prozesssteuersystems.
3 ist ein detaillierteres Blockdiagramm mit der detaillierteren Darstellung eines Teilabschnitts der in 2 wiedergegebenen Objektstruktur.
4 ist ein Blockdiagramm eines Beispiels einer verfahrenstechnischen Anlage mit einem Sicherheitssystem, das mit einem Prozesssteuersystem integriert ist, wobei das Sicherheitssystem ein integriertes elektronisches Freigabesystem für Softwareobjekte enthält.
5A und 5B sind Beispiele von Ablaufdiagrammen einer Freigaberoutine.
6 ist ein Beispiel eines Ablaufdiagramms einer Editor-Routine für Softwareobjekte.
7 ist ein Beispiel eines Ablaufdiagramms einer Setup-Routine für die Autorisierung.
8 ist ein Beispiel einer Benutzerschnittstelle, die der in 7 wiedergegebenen Setup-Routine für die Autorisierung zugeordnet ist.
9 ist ein Beispiel eines Ablaufdiagramms einer Addierroutine.
10 ist ein Beispiel einer Benutzerschnittstelle, die der in 9 wiedergegebenen Addierroutine zugeordnet ist.
11 ist ein Beispiel eines Ablaufdiagramms einer Löschroutine.
12 ist ein Beispiel eines Ablaufdiagramms einer Änderungsroutine.
13 ist ein Beispiel einer Benutzerschnittstelle, die der in 12 wiedergegebenen Änderungsroutine zugeordnet ist.
14 ist ein Beispiel eines Ablaufdiagramms einer Autorisierungsroutine für Softwareobjekte.
15 ist ein Beispiel einer Benutzerschnittstelle, die der in 14 wiedergegebenen Autorisierungsroutine zugeordnet ist.
16 ist ein Beispiel eines Ablaufdiagramms einer Freigaberoutine.
17 ist ein Beispiel einer Benutzerschnittstelle, die der in 16 wiedergegebenen Freigaberoutine zugeordnet ist.
18 ist ein Beispiel eines Ablaufdiagramms einer Ablehnungsroutine.
19 ist ein Beispiel einer Benutzerschnittstelle mit der Darstellung des Status nicht freigegebener Softwareobjekte.
20 ist ein Beispiel eines Ablaufdiagramms einer Download-Routine.

DETAILLIERTE BESCHREIBUNG
Im Folgenden werden ausführlich Verfahren und Systeme zur elektronischen Steuerung der Freigabe und des Ladens von Softwareobjekten beschrieben, wie z.B. von Rezepturen in Prozesssteuersystemen oder Softwareroutinen, die dazu verwendet werden können, um es einem Autor eines Softwareobjekts zu ermöglichen, automatisch und/oder elektronisch die Freigabe der Personen oder der Prüfergruppen zu erhalten, die ein Softwareobjekt autorisieren müssen, bevor das Objekt in das Prozesssteuersystem oder das sicherheitsrelevante System geladen bzw. dort implementiert wird. Diese Verfahren und Systeme ermöglichen den Prüfern die Prüfung des Softwareobjekts in der Umgebung, in der es verwendet wird, sodass das geprüfte Softwareobjekt möglichst genau ist. Da das Freigabesystem mit der Prozesssteuersystem- oder Sicherheitssystem-Planungsumgebung integriert ist, kann das Freigabesystem ferner einen Mechanismus bereitstellen, um zu gewährleisten, dass ein nicht freigegebenes Softwareobjekt nicht ausgeführt werden kann, bis alle Freigaben vorliegen, und dass vorangegangenen Freigaben für ein Softwareobjekt widerrufen werden (d.h. dass die Software in den nicht freigegebenen Zustand übergeht), falls am Softwareobjekt eine Änderung vorgenommen wird. Zusätzlich ermöglicht das integrierte Freigabesystem für Softwareobjekte dem Prozesssteuer- oder Sicherheitssystem, im Audit-Trail der Softwareentwicklung zum Softwareobjekt einen akkuraten Datensatz der Freigaben zu erfassen.
Bei Bedarf können die Prüfer oder Unterzeichner eines Softwareobjekts über eine Anzahl unterschiedlicher Verfahren benachrichtigt werden, und sie können nach der Benachrichtigung das Softwareobjekt prüfen und das Softwareobjekt freigeben oder ablehnen. Wenn jeder der Prüfer das Softwareobjekt freigibt, kann das Softwareobjekt zum Download in das Prozesssteuersystem oder das sicherheitsrelevante System freigegeben werden. Ein zusätzlicher Funktionsumfang kann es verschiedenen Personen oder Entitäten (z.B. Prüfern, Autoren, Business-Gruppen oder anderen) ermöglichen, den Freigabestatus eines Softwareobjekts zu prüfen; die Autorisierung automatisch zu entfernen, falls die Software geändert wurde; die Version des Softwareobjekts bei der Vornahme von Änderungen automatisch zu ändern, usw.
Das Freigabesystem und -verfahren für Softwareobjekte wird anhand des folgenden Beispiels beschrieben mit Bezug auf die Freigabe und den Download von Rezepturen in einem Prozesssteuersystem bzw. auf die Freigabe und den Download von Softwareobjekten in einer Sicherheitssystemumgebung. Das beschriebene System und das Verfahren können jedoch vorteilhaft auch für andere Arten von Softwareobjekten verwendet werden, wie z.B. für Einheiten, Phasen, Grafiken usw. in anderen Prozesssteuerumgebungen. Weiter kann das als Beispiel beschriebene Freigabesystem und -verfahren für Softwareobjekte zur Freigabe und zum Download von jeweils einzelnen Softwareobjekten und/ oder von Gruppen aus zusammenhängenden oder nicht zusammenhängenden Softwareobjekten zum gleichen Zeitpunkt oder zu unterschiedlichen Zeiten verwendet werden.
Wie unmittelbar ersichtlich ist, könnte das beschriebene Freigabesystem und - verfahren für Softwareobjekte auch vorteilhaft in Verbindung mit Versionskontrollsoftware verwendet werden. Ein Beispiel eines Typs einer Versionskontrollsoftware ist beschrieben im US-Patent Nr. 6,449,624 mit dem Titel „Version Control and Audit Trail in a Process Control System“, dessen gesamte Beschreibung hiermit ausdrücklich als Bestandteil der vorliegenden Anmeldung übernommen wird.
In 1 enthält ein Beispiel eines Prozesssteuersystems 10 Steuerungen 12, die über eine Ethernet-Verbindung 15 mit einer Vielzahl von Workstations 14 verbunden sind. Die Steuerungen 12 sind ebenfalls über eine Gruppe von Kommunikationsleitungen oder einen Bus 19 mit einem Prozess zugeordneten Einrichtungen oder Vorrichtungen verbunden (allgemein durch die Kennziffer 16 angegeben). Die Steuerungen 12, die rein beispielsweise von Emerson Process Management vertriebene Delta V^TM Steuerungen sein könnten, können mit über den Prozess 16 verteilten Steuerelementen wie z.B. Feldgeräten und Funktionsblöcken in Steuerelementen kommunizieren, um eine oder mehrere Prozesssteuerroutinen oder Softwareobjekte auszuführen, die vorzugsweise unter Verwendung von objektorientierten Programmiertechniken implementiert sind, um somit die gewünschte Steuerung des Prozesses 16 zu implementieren. Die Workstations 14 (die beispielsweise Personal Computer sein können) können Entwicklungssoftware 17 enthalten, die von einem oder mehreren Programmierern oder sonstigen Benutzern verwendet wird, um Prozesssteuerroutinen oder Softwareobjekte für die Ausführung durch die Steuerungen 12 zu implementieren und um mit den Steuerungen 12 zu kommunizieren, um die Prozesssteuerroutinen oder Softwareobjekte herunterzuladen und während des Betriebs des Prozesses 16 Informationen zum Prozess 16 zu empfangen und anzuzeigen. Zusätzlich kann die Freigabesoftware 18 zur Kommunikation mit der Entwicklungssoftware 17 verbunden und darin integriert sein, um die Freigabe von beliebigen Rezepturen oder sonstigen Prozesssteuerroutinen oder Objekten bereitzustellen, mit der Entwicklungssoftware 17 entwickelt oder abgeändert wurden.
Jede der Workstations 14 enthält einen Speicher 20 für das Speichern von Anwendungen wie Konfigurationsplanungsanwendungen und zum Speichern von Daten, wie z.B. Konfigurationsdaten zur Konfiguration des Prozesses 16. Jede der Workstations 14 enthält auch einen Prozessor 21, der die Anwendungen 17 und 18 ausführt, um es einem Benutzer zu ermöglichen, Prozesssteuerroutinen oder Softwareobjekte zu entwickeln und/oder zu ändern und diese Prozesssteuerroutinen oder Softwareobjekte in die Steuerungen 12 zu laden. Entsprechend enthält jede der Steuerungen 12 einen Speicher 22 zum Speichern von Konfigurationsdaten und Prozesssteuerroutinen, die zur Steuerung des Prozesses 16 verwendet werden, und sie enthält einen Prozessor 24, der die Prozesssteuerroutinen zur Implementierung einer Prozesssteuerstrategie ausführt. Wenn die Steuerungen 12 Delta V^TM Steuerungen sind, können sie eine grafische Darstellung der Prozesssteuerroutinen in den Steuerungen 12 für einen Benutzer über eine der Workstations 14 bereitstellen, die die Steuerelemente in der Prozesssteuerroutine sowie die Art wiedergibt, in der diese Steuerelemente für die Ausführung der Steuerung des Prozesses 16 konfiguriert sind.
Das in 1 wiedergegebene System 10 kann auch ein Netzwerk 30 umfassen, mit dem eine oder mehrere der Workstations 14 verbunden sind. Das Netzwerk 30 kann unter Verwendung eines beliebigen geeigneten Netzwerks implementiert sein, wie z.B. über das Internet, ein Intranet, ein lokales Netzwerk (LAN), ein Wide-Area-Network (WAN) oder ein beliebiges anderes geeignetes Netzwerk. Obwohl das Netzwerk 30 mit fest verdrahteten Verbindungen dargestellt ist, ist es unmittelbar ersichtlich, dass ein derartiges Netzwerk ein drahtloses Netzwerk oder auch ein Netzwerk mit sowohl fest verdrahten als auch drahtlosen Teilabschnitten 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 enthalten, der mit einem Prozessor 36 verbunden ist, der für die Ausführung von im Speicher 34 gespeicherten Anweisungen eingerichtet ist. Bei einer beispielhaften Ausführungsform können die Terminals 32 Personal Computer oder beliebige ähnliche Verarbeitungseinrichtungen sein, die im Vergleich zu bei heute bekannten konventionellen Personal Computern verfügbaren Werten die gleiche oder eine größere Rechenleistung und Speicherkapazität enthalten können.
Mit Verweis auf die Beschreibung des in 1 wiedergegebenen Prozesssteuersystems 10 sind die Steuerungen 12 zur Kommunikation über einen Bus 19 mit drei Gruppen ähnlich konfigurierter Reaktoren verbunden, die als Reaktor_01, Reaktor_02 und Reaktor_03 gekennzeichnet sind. Reaktor_01 enthält einen Reaktorkessel 100, zwei Eingangsventile 101 und 102, die mit Eingangsleitungen für Steuerflüssigkeit verbunden sind, die Flüssigkeit zum Kessel 100 leiten, sowie ein Ausgangsventil 103, das über eine Ausgangsflüssigkeitsleitung mit dem Ausfluss der Steuerflüssigkeit aus dem Reaktorkessel 100 verbunden ist. Eine Einrichtung 105, die ein Sensor wie eine Temperatursonde, ein Druckwächter, ein Flüssigkeitspegelmesser usw. oder eine sonstige Einrichtung wie eine elektrische Heizung oder eine Dampfheizung sein kann, ist im oder in der Nähe des Reaktorkessels 100 angeordnet. Auf ähnliche Weise enthält der Reaktor_02 einen Reaktorkessel 200, zwei Eingangsventile 201 und 202, ein Ausgangsventil 203 und eine Einrichtung 205. Entsprechend enthält der Reaktor_03 einen Reaktorkessel 300, zwei Eingangsventile 301 und 302, ein Ausgangsventil 303 und eine Einrichtung 305. Wie in 1 dargestellt ist, sind die Steuerungen 12 über den Bus 19 zur Kommunikation mit den Ventilen 101-103, 201-203 und 301-303 und mit den Einrichtungen 105, 205 und 305 verbunden, um den Betrieb dieser Elemente zur Ausführung von einem oder mehreren Vorgängen bezüglich der Reaktoreinheiten zu steuern. Diese Vorgänge können beispielsweise das Füllen der Reaktorkessel, das Aufheizen von Material in den Reaktorkesseln, das Entleeren der Reaktorkessel, das Reinigen der Reaktorkessel usw. umfassen.
Die Ventile, Sensoren und sonstigen in 1 wiedergegebenen Einrichtungen können beliebige gewünschte Arten von Einrichtungen sein, einschließlich z.B. Fieldbus-Einrichtungen, standardmäßigen 4-20-mA-Einrichtungen, HART-Einrichtungen usw., und sie können über beliebige bekannte oder gewünschte Kommunikationsprotokolle wie das Fieldbus-Protokoll, das HART-Protokoll, das analoge 4-20-mA-Protokoll usw. mit den Steuerungen 12 kommunizieren. Weiter können anderen Arten von Einrichtungen mit den Steuerungen 12 verbunden und durch sie gesteuert werden. Ebenfalls können andere Steuerungen über die Ethernet-Kommunikationsverbindung 15 mit den Steuerungen 12 und den Workstations 14 verbunden sein, um andere Einrichtungen oder Bereiche zu steuern, die dem Prozess 16 zugeordnet sind, und der Betrieb dieser zusätzlichen Steuerungen kann mit dem betrieb der in 1 wiedergegebenen Steuerungen auf eine beliebige gewünschte Weise koordiniert sein.
Allgemein ausgedrückt, kann das in 1 wiedergegebene Prozesssteuersystem 10 zur Implementierung von Batch-Prozessen verwendet werden, bei denen beispielsweise eine der Workstations 14 oder der Steuerungen 12 eine Batch-Ausführungsroutine 40 ausführt, die eine Steuerroutine höherer Ordnung ist, die den Betrieb von einer oder mehreren der Reaktoreinheiten (sowie weiterer Vorrichtungen) zur Ausführung einer Reihe unterschiedlicher Schritte leitet (üblicherweise als Phasen bezeichnet), die zur Herstellung eines Produkts, wie z.B. eines Nahrungsmittelprodukts, eines Arzneimittels oder eines sonstigen pharmazeutischen Produkts, benötigt werden. Die Schritte oder Phasen sind normalerweise unter Verwendung von Softwareobjekten implementiert, die in einen oder mehrere der Prozessoren 21 und 24 im System 10 geladen und von dort eingeleitet und ausgeführt werden können.
Zur Implementierung unterschiedlicher Phasen verwendet die Batch-Ausführungsroutine 40 ein normalerweise als Rezeptur bezeichnetes Softwareobjekt, das die auszuführenden Schritte und die den Schritten zugeordneten Mengen und Zeiten sowie die Abfolge der Schritte angibt. Schritte für eine Rezeptur können beispielsweise das Füllen eines Reaktorkessels mit den benötigten Materialien oder Komponenten, das Mischen der Materialien im Reaktorkessel, das Aufheizen der Materialien im Reaktorkessel auf eine bestimmte Temperatur über eine bestimmte Zeit, die Entleerung des Reaktorkessels und die anschließende Reinigung des Reaktorkessels zur Vorbereitung für den folgenden Batch-Vorgang umfassen. Jeder der Schritte definiert eine Phase des Batch-Vorgangs, und die Batch-Ausführungsroutine 40 bewirkt, dass die Steuerungen 12 für jede dieser Phasen einen unterschiedlichen Steueralgorithmus ausführen. Selbstverständlich können die spezifischen Materialien, Materialmengen, Aufheiztemperaturen und -zeiten usw. für verschiedene Rezepturen unterschiedlich sein, und dementsprechend können sich diese Parameter in Abhängigkeit vom bearbeiteten oder produzierten Produkt und der verwendeten Rezeptur von Batch-Vorgang zu Batch-Vorgang ändern. Für Fachleute auf diesem Gebiet ist es ersichtlich, dass, während die Beschreibung Steuerroutinen und Konfigurationen für Batch-Vorgänge in den in 1 wiedergegebenen Reaktoreinheiten behandelt, Steuerroutinen zur Steuerung von anderen gewünschten Einrichtungen verwendet werden können, um beliebige andere gewünschte Batch-Prozessvorgänge oder bei Bedarf auch kontinuierliche Prozessabläufe ausführen zu können.
Auf einem höheren Niveau kann in einem relevanten Teilabschnitt des Vorgangs eine Person oder Entität an einer der Workstations 14 die Entwicklungssoftware 17 verwenden, um Rezepturen oder andere Softwareobjekte anzulegen oder zu ändern, und die Freigabesoftware 18 kann elektronisch die Freigabe von verschiedenen Autorisierungsentitäten anfordern, wie z.B. von den Bereichen Produktion, Planung, Qualitätssicherung oder Management. Die Autorisierungsentitäten können die Workstations 14 oder die Terminals 12 verwenden, um die Rezeptur und/oder die sonstigen betreffenden Softwareobjekte zu prüfen, und die Rezeptur und/oder die anderen Softwareobjekte freigeben oder ablehnen. Die Freigabe oder Ablehnung der betreffenden Softwareobjekte kann der Person oder Entität mitgeteilt werden, die die Freigabe der Objekte angefordert hatte, oder sie kann zur Freigaberoutine 18 zurückgeleitet werden, die zurückverfolgen kann, wer das Softwareobjekt freigegeben bzw. nicht freigegeben hat. Nachdem ein Softwareobjekt von allen Entitäten freigegeben wurde, deren Freigabe angefordert worden war, (bzw. von beliebigen vorbestimmten Untergruppen, die eine Entitätengruppe definieren), kann die Freigaberoutine 18 den Download des Softwareobjekts in eine der Steuerungen 12 oder in die Batch-Ausführungsroutine 40 zur Implementierung oder Ausführung im Prozesssteuersystem 10 freigeben.
Der in 2 wiedergegebene Objektbaum zeigt Beispiele von Softwareobjekten, die mit der Entwicklungssoftware 17 im Zusammenwirken mit der Freigabesoftware 18 angelegt und geladen werden können. Die in 2 wiedergegebenen Softwareobjekte sind lediglich als Beispiele von Softwareobjekten (zusätzlich zu den oben beschriebenen Rezepturen) dargestellt, die unter Verwendung des beschriebenen integrierten elektronischen Freigabesystems angelegt und freigegeben werden können, wobei als selbstverständlich vorausgesetzt wird, dass auch andere Softwareobjekte unter Verwendung dieses Systems angelegt und freigegeben werden können. Die in 2 wiedergegebenen Softwareobjekte, die unter Verwendung von Softwareroutinen implementiert sind, werden mit Kästchen dargestellt, während allgemeine Objektkategorien (oder Objekttypen) im Baum über den Objekten ohne Kästchen wiedergegeben sind. Entsprechend der Darstellung in 2 enthält das Prozesssteuersystem 10 einen oder mehrere Bereiche, die beispielsweise Gebäude oder andere geografische Bereichsbezeichnungen in einer Prozesssteueranlage sein können. Bei dem in 2 wiedergegebenen Objektbaum hat der Prozess 16 drei Bereichsobjekte mit der Bezeichnung Gebäude_01, Gebäude_02 und Gebäude_03. Jedes Bereichsobjekt kann in Prozesszellen unterteilt sein, von denen jede einem unterschiedlichen Aspekt des in dem Bereich ausgeführten Prozesses entspricht. Das in 2 wiedergegebene Bereichsobjekt Gebäude_01 ist so dargestellt, dass es zwei Prozesszellenobjekte mit den Bezeichnungen Zelle_01 und Zelle_02 enthält. Zelle_01 kann beispielsweise mit der Erstellung einer Komponente eines in Zelle_02 verwendeten Produkts verknüpft sein. Jedes Zellenobjekt kann null oder mehrere Einheitenklassen enthalten, die unterschiedliche Kategorien oder Gruppierungen von in der Prozesszelle verwendeter Hardware identifizieren. Allgemein ausgedrückt, ist eine Einheitenklasse ein benanntes Objekt, das eine gemeinsame Konfiguration einer Gruppe dazugehöriger Vorrichtungen aufnimmt, und insbesondere ist es eine Zusammenstellung von Einheiten mit sehr ähnlicher oder identischer Prozessausstattung, wobei jede Einheit in einem Prozess eine sehr ähnliche oder identische Funktion ausführt. Objekte von Einheitenklassen sind normalerweise benannt, um die dazugehörigen Einheitentypen im Prozesssteuersystem zu benennen. 2 enthält eine Einheitenklasse Mix_Tank, eine Einheitenklasse Reaktor und eine Einheitenklasse Tank_Zufuhr. Selbstverständlich sind bei den meisten Prozesssteuersystemen oder Netzwerken viele andere Typen von Einheitenklassen vorhanden oder definiert, einschließlich beispielsweise Trocknereinheiten, Feedheader-Einheiten und andere individuelle oder logische Hardware-Gruppierungen.
Entsprechend der Darstellung für die in 2 wiedergegebene Reaktor-Einheitenklasse kann jedes Einheitenklassen-Objekt zugeordnete Einheitenmodul-Objekte und Phasenklassen-Objekte haben. Einheitenmodul-Objekte geben allgemein bestimmte Fälle von replizierter Hardware in der benannten Einheitenklasse an, während Phasenklassen allgemein die Phasen angeben, die auf die der betreffenden Einheitenklasse zugeordneten Einheitenmodulen angewandt werden können. Insbesondere ist ein Einheitenmodul-Objekt ein benanntes Objekt, das alle Variablen und Einheitenklassen (entsprechend der folgenden Definition) für eine einzelne Prozesseinheit aufnimmt, und es ist normalerweise benannt, um spezifische Prozessvorrichtungen zu identifizieren. Beispielsweise hat die in 2 wiedergegebene Reaktor-Einheitenklasse Einheitenmodule Reaktor_01, Reaktor_02 und Reaktor_03, die Reaktor_01, Reaktor_02 bzw. Reaktor_03 entsprechend der Darstellung in 1 entsprechen. Die Einheitenklasse Mix_Tank und die Einheitenklasse Tank_Zufuhr haben auf ähnliche Weise bestimmte Einheitenmodule, die bestimmter Hardware oder bestimmten Vorrichtungen im Prozess 16 entsprechen. Im Interesse der Vereinfachung ist aber keine der Mix_Tank oder Tank_Zufuhr zugeordneten Vorrichtungen in 1 dargestellt.
Eine Phasenklasse ist ein benanntes Objekt, das die gemeinsame Konfiguration für eine Phase aufnimmt, die an den mehreren zur gleichen Einheitenklasse gehörenden Einheiten sowie an mehreren unterschiedlichen Einheitenklassen eingesetzt werden kann. Praktisch ist jede Phasenklasse eine unterschiedliche Steuerroutine (oder Phase), die von den Steuerungen 12 eingerichtet und verwendet wird, um Einheitenmodule in der gleichen oder in unterschiedlichen Einheitenklassen zu steuern. Normalerweise ist jede Phasenklasse entsprechend dem Verb, das einen an einem Einheitenmodul ausgeführten Vorgang beschreibt, benannt. Bei der Darstellung in 2 hat beispielsweise die Reaktor-Einheitenklasse eine Füll-Phasenklasse, die zum Beschicken eines beliebigen Reaktorkessels 100, 200 oder 300 in 1 verwendet wird, sowie eine Heiz-Phasenklasse, die zum Aufheizen eines beliebigen Reaktorkessels 100, 200 oder 300 in 1 verwendet wird, eine Leer-Phasenklasse, die zum Entleeren eines beliebigen Reaktorkessels 100, 200 oder 300 in 1 verwendet wird, und eine Reinigen-Phasenklasse, die zum Reinigen eines beliebigen Reaktorkessels 100, 200 oder 300 in 1 verwendet wird. Selbstverständlich können beliebige andere Phasenklassen dieser oder einer beliebigen anderen Einheitenklasse zugeordnet sein. Die Füll-Phasenklasse ist sowohl der Reaktor-Einheitenklasse als auch der Tank_Zufuhr-Einheitenklasse zugeordnet und kann daher sowohl für die Ausführung von Füllvorgängen bei Reaktor-Einheitenmodulen als auch bei Tank_Zufuhr-Einheitenmodulen benutzt werden.
Eine Phasenklasse kann allgemein als Softwareroutine oder Objekt betrachtet werden, das von der Batch-Ausführungsroutine aufgerufen wird, um in einem Batch-Gesamtprozess benötigte Funktionen entsprechend der Definition in der Rezeptur für den betreffenden Batch-Prozess auszuführen. Eine Phasenklasse kann null oder mehrere Phasen-Eingangsparameter haben, die im Wesentlichen die von der Batch-Ausführungsroutine oder einer anderen Phasenklasse für die Phasenklasse-Softwareroutine oder für das Objekt bereitgestellten Eingaben sind; und sie kann null oder mehrere Phasen-Ausgangsparameter haben, die im Wesentlichen zur Batch-Ausführungsroutine oder zu einer anderen Phasenklasse zurückgeleiteten Ausgaben der Phasenklasse-Routine sind; und sie kann null oder mehrere Phasenmeldungen enthalten, wobei dies Meldungen sein können, die dem Benutzer mit Bezug auf den Betrieb der Phasenklasse angezeigt werden sollen, oder Informationen zu anderen Phasenklassen, denen die betreffende Phasenklassen auf bestimmte Weise zugeordnet ist; und sie kann null oder mehrere Phasenalgorithmus-Parameter enthalten, die auf der Grundlage der betreffenden Phasenklasse das Anlegen von Parametern in Phasenlogikmodulen (PLMs) oder Einheitenphasen bewirken. Diese Phasenalgorithmus-Parameter werden als temporäre Speicherpositionen bzw. Variablen während der Ausführung der Phase verwendet, und sie sind für den Benutzer oder für die Batch-Ausführungsroutine nicht notwendigerweise sichtbar. Die Phasenklasse enthält eine oder mehrere Phasenalgorithmus-Definitionen (PADs), die allgemein ausgedrückt die zur Implementierung der Phase verwendeten Steuerroutinen sind. Die Phasenklasse hat ferner eine Zuordnungsliste für null, eine, zwei oder mehrere Einheitenklassen, und diese Liste definiert die Einheitenklassen, bei denen die betreffende Phasenklasse und damit die PAD der Phasenklasse angewandt werden können. Die Zuordnungsliste der Füll-Phasenklasse enthält sowohl die Reaktor-Einheitenklasse als auch die Tank Zufuhr-Einheitenklasse.
3 stellt eine detailliertere Version von einigen der in 2 wiedergegebenen Objekte und die wechselseitigen Beziehungen dieser Objekte dar. Zwei Einheitenklassen sind in 3 dargestellt, und zwar eine Reaktor-Einheitenklasse 50 und eine Tank_Zufuhr-Einheitenklasse 52. Die Reaktor-Einheitenklasse 50 hat ein Einheitenmodul 54 mit der Bezeichnung Reaktor_01. Andere Module können vorhanden sein, sind aber in 3 zur Vereinfachung nicht dargestellt. Das Einheitenmodul 54 definiert einige der Reaktorparameter, die der Reaktor-Einheitenklasse 50 zugeordnet sind, und zwar, dass die Kapazität von Reaktor_01 300 beträgt und dass Reaktor_01 kein Rührwerk umfasst. Auf ähnliche Weise sind der Reaktor-Einheitenklasse 50 zwei Phasenklassen zugeordnet, mit einer Füll-Phasenklasse 56 und einer Leer-Phasenklasse 58. Die Füll-Phasenklasse 56 enthält eine PAD (rechts davon grafisch als SFC wiedergegeben), die unter Verwendung der beiden Aliasnamen #INLET_VALVE# und #LEVEL# eingerichtet ist. Diese Aliasnamen werden dann in den in der PAD der Füll-Phasenklasse 56 wiedergegebenen Kästchen verwendet, können aber alternativ dazu an beliebiger Stelle in der PAD-Logik verwendet werden. Die Füll-Phasenklasse 56 enthält auch eine als ZIEL_PEGEL definierte Eingabe und eine als END_PEGEL definierte Ausgabe. Während die Aliasnamen mit Begrenzung bzw. Markierung durch ein Rautenzeichen (#) wiedergegeben sind, kann eine beliebige andere Kennzeichnung zur Definition eines Aliasnamens verwendet werden, der bei der Einleitung einer Phase ersetzt werden muss. Auf ähnliche Weise enthält die Leer-Phasenklasse 58 eine rechts davon grafisch dargestellte PAD mit den Aliasnamen #OUTLET_VALVE# und #LEVEL#, einer als RATE definierten Eingabe, einer als END_PEGEL definierten Ausgabe und einem (von der PAD verwendeten) Algorithmusparameter, der als IST_RATE definiert ist und der während der Ausführung der PAD als temporäre Speicherposition benutzt werden kann.
Während 1-3 ein Prozesssteuersystem wiedergeben, wobei Softwareobjekte angelegt und zur Ausführung traditioneller Prozesssteuerfunktionen verwendet werden können, ist 4 eine Darstellung eines integrierten Prozesssteuersystems und sicherheitsrelevanten Systems, das integrierte Entwicklungs- und Freigabesoftware enthält, die zum Anlegen, Ändern und Freigeben der gleichen oder anderer Softwareobjekte im Prozesssteuersystem, im sicherheitsrelevanten System oder in beiden Systemen eingesetzt werden kann. Entsprechend der Darstellung in 4 enthält eine verfahrenstechnische Anlage 110 insbesondere ein mit einem Sicherheitssystem 114 (durch gestrichelte Linien angegeben) integriertes Prozesssteuersystem 112, das allgemein als Safety Instrumented System (SIS) zur Überwachung und zur Umgehung der vom Prozesssteuersystem 112 bereitgestellten Steuerung betrieben wird, um dadurch den Betrieb der verfahrenstechnischen Anlage 110 mit Sicherheitswahrscheinlichkeit zu maximieren. Die verfahrenstechnische Anlage 110 enthält auch eine oder mehrere Host-Workstations, Computer oder Benutzerschnittstellen 116 (wobei dies beliebige Arten von Personal Computern, Workstations, PDAs usw. sein können), die für das Anlagenpersonal zugänglich sind, wie z.B. für Prozesssteuerbediener, Wartungspersonal, Sicherheitsbeauftragte usw. Bei dem in 4 wiedergegebenen Beispiel sind zwei Benutzerschnittstellen 116 dargestellt, die über eine gemeinsame Kommunikationsleitung oder einen Bus 122 mit zwei separaten Prozesssteuer-/Sicherheitssteuer-Knoten 118 und 120 und mit einer Konfigurationsdatenbank 121 verbunden sind. Das Kommunikationsnetzwerk 122 kann mit beliebiger Hardware auf Bus-Basis oder auf Nicht-Bus-Basis implementiert sein und eine beliebige gewünschte fest verdrahtete oder drahtlose Kommunikationsstruktur und ein beliebiges gewünschtes bzw. geeignetes Kommunikationsprotokoll, wie z.B. ein Ethernet-Protokoll, verwenden.
Allgemein ausgedrückt, enthält jeder der Knoten 118 und 120 der verfahrenstechnischen Anlage 110 sowohl Prozesssteuersystem-Einrichtungen als auch Sicherheitssystem-Einrichtungen, die über eine Busstruktur miteinander verbunden sind, welche an einer Backplane-Rückwand bereitgestellt sein kann, an die die unterschiedlichen Einrichtungen angeschlossen sind. Der Knoten 118 ist in 4 mit einer Prozesssteuerung 124 dargestellt (die aus einem redundanten Paar von Steuerungen bestehen kann), sowie mit einer oder mehreren Prozesssteuersystem-Eingangs/Ausgangs-(I/O)-Einrichtungen 128, 130 und 132, während der Knoten 120 mit einer Prozesssteuerung 126 (die aus einem redundanten Paar von Steuerungen bestehen kann) sowie mit einer oder mehreren Prozesssteuersystem-I/O-Einrichtungen 134 und 136 dargestellt ist. Jede der Prozesssteuersystem-I/O-Einrichtungen 128, 130, 132, 134 und 136 ist zur Kommunikation mit einer Gruppe von prozesssteuerrelevanten Feldgeräten verbunden, die in 4 als Feldgeräte 140 und 142 dargestellt sind. Die Prozesssteuerungen 124 und 126, die I/O-Einrichtungen 128-136 und die Steuerungsfeldgeräte 140 und 142 bilden allgemein das in 4 wiedergegebene Prozesssteuersystem 112.
Auf ähnliche Weise enthält der Knoten 118 eine oder mehrere sicherheitsgerichtete Logic-Solver-Einrichtungen 150, 152, während der Knoten 120 die sicherheitsgerichteten Logic-Solver-Einrichtungen 154 und 156 umfasst. Jeder der Logic Solver 150-156 ist eine I/O-Einrichtung mit einem Prozessor 157, der in einem Speicher 179 abgelegte Sicherheitslogikmodule 158 ausführt und der kommunikativ zur Bereitstellung von Steuersignalen an die bzw. zum Empfang von Signalen von den Sicherheitsssystem-Feldgeräte(n) angeschlossen ist. Zusätzlich enthält jeder der Knoten 118 und 120 eine MPD-Einrichtung 170 oder 172 zur Meldungsweiterleitung, die über eine Busverbindung 174 des Ringtyps (nur teilweise in 4 dargestellt) kommunikativ miteinander verbunden sind. Die sicherheitsgerichteten Logic Solver 150-156, die Sicherheitssystem-Feldgeräte 160 und 162, die MPD-Einrichtungen 170 und 172 und der Bus 174 bilden allgemein das in 4 wiedergegebene Sicherheitssystem 114.
Die Prozesssteuerungen 124 und 126, die lediglich als Beispiel von Emerson Process Management vertriebene Delta V^TM Steuerungen oder beliebige andere Typen von Prozesssteuerungen sein können, sind für die Bereitstellung von Prozesssteuerfunktionen programmiert (unter Verwendung von üblicherweise als Steuermodule bezeichneten Einrichtungen) und verwenden die I/O-Einrichtungen 128, 130 und 132 (für die Steuerung 124), die I/O-Einrichtungen 134 und 136 (für die Steuerung 126) und die Feldgeräte 140 und 142. Insbesondere implementiert bzw. überwacht jede der Steuerungen 124 und 126 eine oder mehrere darin gespeicherte oder auf sonstige Weise zugeordnete Prozesssteuerroutinen (die Softwareobjekte sind und aus einer Zusammenstellung von untereinander verbundenen Softwareobjekten bestehen können) und kommuniziert mit den Feldgeräten 140 und 142 und den Workstations 114, um den Prozess 110 oder einen Teil des Prozesses 110 auf eine gewünschte Weise zu steuern. Die Feldgeräte 140 und 142 können Feldgeräte eines beliebigen gewünschten Typs sein, wie z.B. Sensoren, Ventile, Geber, Positionierer usw., und sie können beliebigen gewünschten offenen, proprietären oder sonstigen Kommunikations- oder Programmierprotokollen entsprechen, einschließlich beispielsweise des HART- oder des 4-20-mA-Protokolls (entsprechend der Darstellung für die Feldgeräte 140), eines beliebigen Fieldbus-Protokolls wie des FOUNDATION® Fieldbus-Protokolls (entsprechend der Darstellung für die Feldgeräte 142) oder der CAN-, Profibus-, AS-Interface-Protokolle, um nur einige wenige aufzuführen. Entsprechend können die I/O-Einrichtungen 128-136 beliebige bekannte Arten von Prozesssteuerungs-I/O-Einrichtungen sein, die beliebige geeignete Kommunikationsprotokolle verwenden.
Die in 4 wiedergegebenen sicherheitsgerichteten Logic Solver 150-156 können Sicherheitssystem-Steuereinrichtungen beliebiger Art sein, die die einen Prozessor 157 enthalten sowie einen Speicher, der Sicherheitslogikmodule 158 speichert, die für die Ausführung im Prozessor 157 eingerichtet sind, um Steuerfunktionen in Zusammenhang mit dem Sicherheitssystem 114 unter Verwendung der Feldgeräte 160 und 162 bereitzustellen. Selbstverständlich können die Sicherheits-Feldgeräte 160 und 162 Feldgeräte beliebiger Art sein, die einem beliebigen bekannten oder gewünschten Kommunikationsprotokoll, wie z.B. den vorstehend aufgeführten Protokollen, entsprechen oder dieses verwenden. Insbesondere können die Feldgeräte 160 und 162 sicherheitsgerichtete Feldgeräte der Art sein, die üblicherweise von einem separaten dedizierten sicherheitsgerichteten Steuersystem gesteuert wird. Bei der in 4 wiedergegebenen verfahrenstechnischen Anlage 110 sind die Sicherheits-Feldgeräte 160 so dargestellt, dass sie ein dediziertes bzw. Punkt-zu-Punkt-Kommunikationsprotokoll wie das HART- oder das 4-20-mA-Protokoll verwenden, während die Sicherheits-Feldgeräte 162 so dargestellt sind, dass sie ein Bus-Kommunikationsprotokoll wie z.B. das Fieldbus-Protokoll verwenden. Die Sicherheits-Feldgeräte 160 können beliebige gewünschte Funktionen ausführen, wie z.B. die Funktion eines Abschaltventils, einer Abschalteinrichtung usw.
Ein gemeinsamer Backplane 176 (durch die gestrichelte Linie durch die Steuerungen 124, 126, die I/O-Einrichtungen 128-136, die sicherheitsgerichteten Logic Solver 150-156 und die MPD-Einrichtungen 170 und 172 dargestellt) wird in jedem der Knoten 118 und 120 verwendet, um die Steuerungen 124 und 126 mit den Prozesssteuerungs-I/O-Karten 128, 130 und 132 oder 134 und 136 zu verbinden, sowie mit den sicherheitsgerichteten Logic-Solver-Einrichtungen 150, 152, 154 oder 156 und den MPD-Einrichtungen 170 oder 172. Die Steuerungen 124 und 126 sind ebenfalls kommunikativ verbunden und arbeiten als Bus-Arbitrator für den Bus 122, um jeder der I/O-Einrichtungen 128-136, jedem der Logic Solver 150-156 und jeder der MPD-Einrichtungen 170 und 172 die Kommunikation mit einer beliebigen Workstation der Workstations 116 über den Bus 122 zu ermöglichen.
Es ist ersichtlich, dass jede der Workstations 116 einen Prozessor 177 und einen Speicher 178 umfasst, und mindestens eine der Workstations speichert eine oder mehrere Konfigurations-, Freigabe-, Diagnose- und/oder Anzeigeanwendungen, die für die Ausführung durch den Prozessor 178 [sic] eingerichtet sind. Eine Konfigurationsanwendung 180, eine Freigabeanwendung (oder -routine) 181 und eine Anzeigeanwendung 182 sind in einer Explosionsdarstellung in 4 so wiedergegeben, dass sie in einer der Workstations 116 gespeichert sind, während eine Diagnoseanwendung 184 so wiedergegeben ist, dass sie in einer anderen Workstation 116 gespeichert ist. Bei Bedarf können diese und andere Anwendungen jedoch in unterschiedlichen Workstations der Workstations 116 oder in anderen der verfahrenstechnischen Anlage 110 zugeordneten Computern gespeichert und ausgeführt werden. Allgemein ausgedrückt, liefert die Konfigurationsanwendung 180 einem Sicherheitsbeauftragten Konfigurationsinformationen, und sie ermöglicht dem Sicherheitsbeauftragten die Konfiguration (Planung) von einigen oder allen Elementen der verfahrenstechnischen Anlage 110 und die Speicherung dieser Konfiguration in der Konfigurationsdatenbank 121. Als Teil der von der Konfigurationsanwendung 180 ausgeführten Konfigurationsvorgänge kann der Sicherheitsbeauftragte Steuerroutinen oder Steuermodule (d.h. Softwareobjekte) für die Prozesssteuerungen 124 und 126 anlegen oder ändern, und er kann Sicherheitslogik-Softwaremodule 158 für beliebige der sicherheitsgerichteten Logic Solver 150-156 anlegen (einschließlich der Einrichtung und Programmierung von Eingabe-, Voter- und sonstigen Funktionsblöcken zur Verwendung in den sicherheitsgerichteten Logic-Solver-Einrichtungen 150-156 oder auch in den Steuerungen 124 und 126), und er kann diese unterschiedlichen Steuer- und Sicherheitsmodule nach dem Eingang einer korrekten diesbezüglichen Autorisierung durch die Freigaberoutine 181 über den Bus 122 und die Steuerungen 124 und 126 in die zuständigen Einrichtungen aus den Prozesssteuerungen 124 und 126 und den sicherheitsgerichteten Logic Solvern 150-156 laden. Auf ähnliche Weise kann die Konfigurationsanwendung 180 verwendet werden, um andere Programme und Logiken nach dem Eingang einer korrekten diesbezüglichen Autorisierung durch die Freigaberoutine 181 anzulegen und in die I/O-Einrichtungen 128-136, beliebige der Feldgeräte 140, 142, 160 und 162 usw. zu laden. Bei Bedarf kann für jedes Prozesssteuersystem 112 und für das Sicherheitssystem 114 jeweils eine separate Gruppe von Konfigurations- und Freigaberoutinen vorliegen, um dadurch die Planungsvorgänge dieser Systeme voneinander zu trennen.
Die Anzeigeanwendung 182 kann verwendet werden, um für einen Benutzer, wie z.B. einen Prozesssteuerungsbediener, einen Sicherheitsbediener usw., eine oder mehrere Anzeigen bereitzustellen, die Informationen zum Status des Prozesssteuersystems 112 und zum Sicherheitssystem 114 bei Bedarf entweder in getrennten Ansichten oder in der gleichen Ansicht umfassen. Beispielsweise kann die Anzeigeanwendung 182 eine Alarmanzeigeanwendung sein, die die Alarmangaben empfängt und einem Bediener anzeigt. Bei Bedarf kann eine derartige Alarmanzeigeanwendung die Form übernehmen, die beschrieben ist im US-Patent Nr. 5,768,119 mit dem Titel „Process Control System Including
Alarm Priority Adjustment“ und in der US-Patentanmeldung Nr. 09/707,580 mit dem Titel „Integrated Alarm Display in a Process Control Network“, die beide für den Inhaber dieses Patents erteilt wurden und die hiermit ausdrücklich als Bestandteil der vorliegenden Anmeldung übernommen werden. Es ist jedoch ersichtlich, dass die Alarmanzeige bzw. die Alarmmeldung dieser Patente Alarme sowohl vom Prozesssteuersystem 112 als auch vom Sicherheitssystem 114 in einer integrierten Alarmanzeige empfangen und anzeigen kann, da die Alarme von beiden Systemen 112 und 114 unter Ausführung der Alarmanzeigeanwendung zur Bedienerworkstation 114 übertragen werden und als Alarme von unterschiedlichen Einrichtungen erkennbar sind. Entsprechend kann ein Bediener Sicherheitsalarme, die in einer Alarmmeldung angezeigt werden, auf die gleiche Weise wie Prozesssteuerungsalarme behandeln. Beispielsweise kann der Bediener oder Benutzer über die Alarmanzeige Sicherheitsalarme bestätigen, Sicherheitsalarme abschalten usw., wobei über Kommunikationsverbindungen über den Bus 122 und den Backplane 176 Meldungen zur zuständigen Prozesssteuerung 124, 126 im Sicherheitssystem 114 übertragen werden, um den entsprechenden Vorgang bezüglich des Sicherheitsalarms auszuführen. Auf ähnliche Weise können andere Anzeigeanwendungen Informationen oder Daten sowohl vom Prozesssteuersystem 112 als auch vom Sicherheitssystem 114 anzeigen, da diese Systeme die gleichen Typen und Arten von Parametern, Sicherheits- und Bezugsangaben verwenden können, sodass beliebigen Daten aus einem der Systeme 112 und 114 in eine traditionell für ein Prozesssteuersystem bereitgestellte Anzeige oder Ansicht integriert werden können. Entsprechend können geänderte oder neue derartige Anzeigeanwendungen (die Softwaremodule sind) angelegt und implementiert werden, nachdem über den im Folgenden detaillierter beschriebenen elektronischen Signaturprozess eine diesbezügliche Autorisierung eingegangen ist.
In jedem Fall können die Anwendungen 180, 181, 182 und 184 sowie alle anderen Anwendungen separate Konfigurations- und sonstige Signale an jede der Prozesssteuerungen 124 und 126 und sie von diesen Prozesssteuerungen wie auch von jedem sicherheitsgerichteten Logic Solver 150-156 empfangen. Diese Signale können prozesssteuerungsbezogene Meldungen umfassen, die die Steuerung der Betriebsparameter der Prozessfeldgeräte 140 und 142 betreffen, und sie können sicherheitsgerichtete Meldungen enthalten, die die Steuerung der Betriebsparameter der sicherheitsbezogenen Feldgeräte 160 und 162 betreffen. Während die sicherheitsgerichteten Logic Solver 150-156 so programmiert sein können, dass sie sowohl die Prozesssteuermeldungen als auch die Sicherheitsmeldungen erkennen, können die sicherheitsgerichteten Logic Solver 150-156 zwischen den beiden Meldungstypen unterscheiden, und sie können nicht durch prozesssteuerungsbezogene Konfigurationssignale programmiert oder beeinflusst werden. Bei einem Beispiel können die zu den Einrichtungen des Prozesssteuersystems übertragenen Programmiermeldungen bestimmte Felder oder Adressen enthalten, die von den Einrichtungen des Sicherheitssystems erkannt werden und die verhindern, dass diese Signale zur Programmierung der Einrichtungen des Sicherheitssystems verwendet werden.
Bei Bedarf können die sicherheitsgerichteten Logic Solver 150-156 das gleiche oder ein anderes Hardware- bzw. Softwaredesign verwenden wie das Hardware- und Softwaredesign für die Prozesssteuerungs-I/O-Karten 128-136. Die Verwendung alternativer Technologien für die Einrichtungen im Prozesssteuersystem 112 und die Einrichtungen im Sicherheitssystem 114 kann aus üblichem Grund auftretende Hardware- oder Softwaredefekte minimieren oder ausschließen. Weiter können die Einrichtungen des Sicherheitssystems einschließlich der Logic Solver 150-156 beliebige gewünschte Isolier- und Sicherheitstechniken verwenden, um die Möglichkeit von nicht autorisierten Änderungen an den dadurch implementierten sicherheitsgerichteten Funktionen zu reduzieren oder auszuschließen. Beispielsweise können die sicherheitsgerichteten Logic Solver 150-156 und die Konfigurationsanwendung 180 fordern, dass eine Person mit einer bestimmten Autorisierungsstufe oder eine an einer bestimmten Workstation tätige Person Änderungen an den Sicherheitsmodulen in den Logic-Solver-Einrichtungen 150-156 vornehmen, wobei sich diese Autorisierungsstufe oder Position von der Autorisierungs- bzw. Zugangsstufe oder der Position unterscheidet, die für die Vornahme von Änderungen an den von den Steuerungen 124 und 126 und von den I/O-Einrichtungen 128-136 vorgenommenen Änderungen erforderlich ist. In diesem Fall sind nur die Personen, die in der Sicherheitssoftware angegeben sind oder die an zur Vornahme von Änderungen am Sicherheitssystem 114 autorisierten Workstations eingesetzt sind, zur Änderung von sicherheitsbezogenen Funktionen autorisiert, wodurch die Möglichkeit einer Beeinträchtigung des Betriebs des Sicherheitssystems 114 minimiert wird. Wie ersichtlich ist, bewerten die Prozessoren in den sicherheitsgerichteten Logic-Solver-Einrichtungen 150-156 zur Implementierung dieser Sicherheitsmerkmale die eingehenden Meldungen hinsichtlich der korrekten Form und der Sicherheit, und sie wirken als Pförtner bei an den Sicherheitssteuermodulen 158 vorgenommenen Änderungen, die in den sicherheitsgerichteten Logic-Solver-Einrichtungen 150-156 ausgeführt werden.
Auf ähnliche Weise kann die in 4 wiedergegebene Freigaberoutine 181 implementiert werden, um die Vornahme von Änderungen an Softwareobjekten im Prozesssteuersystem 112 oder im Sicherheitssystem 114 oder in beiden Systemen ohne ordnungsgemäße Autorisierung von anderen Personen, deren Autorisierung (aufgrund einer namentlichen Benennung oder der hierarchischen Position) erforderlich ist. Insbesondere kann die Freigaberoutine 181 Änderungen erkennen, die an Softwaremodulen in den Konfigurations-, Anzeige- oder Wiedergabemodulen vorgenommen werden, und das Laden dieser Module in das Prozesssteuersystem 112 oder das Sicherheitssystem 114 ohne die vorgesehene Autorisierung oder Freigabe durch die dafür bestimmten Personen verhindern.
Die Verwendung des Backplanes 176 in jedem der Knoten 118 und 120 ermöglicht den sicherheitsgerichteten Logic Solvern 150 und 152 und den sicherheitsgerichteten Logic Solvern 154 und 156 die lokale wechselseitige Kommunikation und die Koordinierung von Sicherheitsfunktionen, die von jeder dieser Einrichtung implementiert werden, um Daten untereinander zu übertragen oder um sonstige integrierte Funktionen auszuführen. Andererseits bewirken die MPD-Einrichtungen 170 und 172, dass Teilabschnitte des Sicherheitssystems 114, die an gänzlich unterschiedlichen Standorten der Anlage 110 angeordnet sind, weiterhin miteinander kommunizieren können, um einen koordinierten Sicherheitsbetrieb an unterschiedlichen Knoten der verfahrenstechnischen Anlage 110 bereitzustellen. Insbesondere ermöglichen die MPD-Einrichtungen 170 und 172 in Verbindung mit dem Bus 174 den unterschiedlichen Knoten 118 und 120 der verfahrenstechnischen Anlage 110 zugeordneten sicherheitsgerichteten Logic Solvern die kommunikative Reihenschaltung, um die Reihenschaltung von sicherheitsbezogenen Funktionen in der verfahrenstechnischen Anlage 110 gemäß einer zugeordneten Priorität zu ermöglichen. Alternativ dazu können zwei oder mehr sicherheitsbezogene Funktionen an unterschiedlichen Positionen in der verfahrenstechnischen Anlage 110 miteinander verbunden oder angeschlossen sein, ohne eine dedizierte Leitung zu individuellen sicherheitsgerichteten Feldgeräten in den separaten Bereichen oder Knoten der Anlage 110 betreiben zu müssen. Anders ausgedrückt, ermöglicht es die Verwendung der MPD-Einrichtungen 170 und 172 und des Busses 174 einem Sicherheits beauftragten, ein Sicherheitssystem 114 zu entwickeln und zu konfigurieren, das physisch über die verfahrenstechnische Anlage 110 verteilt ist, das aber fünf unterschiedliche Komponenten hat, die kommunikativ verbunden sind, um die erforderliche interaktive Kommunikation der getrennten sicherheitsbezogenen Hardware zu ermöglichen. Dieses Merkmal ergibt auch die Skalierbarkeit des Sicherheitssystems 114, da zusätzliche sicherheitsgerichtete Logic Solver zum Sicherheitssystem 114 hinzugefügt werden können, wenn sie benötigt werden oder wenn neue Prozesssteuerknoten zur verfahrenstechnischen Anlage 110 hinzugefügt werden.
Bei einer Ausführungsform können die Logic-Solver-Einrichtungen 150-156 zur Ausführung von Steuervorgängen bezüglich der Sicherheitseinrichtungen 160 und 162 unter Verwendung eines Funktionsblock-Programmierparadigmas programmiert sein. Wie in einer erweiterten Darstellung eines der (im Speicher 179 gespeicherten) Sicherheitsmodule 158a des Logic Solvers 154 wiedergegeben ist, kann ein Sicherheitssteuermodul insbesondere eine Reihe von kommunikativ miteinander verbundenen Funktionsblöcken (von denen jedes ein Softwareobjekt ist) umfassen, die zur Implementierung während des Betriebs des Prozesses 110 angelegt und in den Logic Solver 154 geladen werden können. Entsprechend der Darstellung in 4 enthält das Steuermodul 158a zwei Voter-Funktionsblöcke 192 und 194 mit Eingängen, die kommunikativ mit weiteren Funktionsblöcken 190 verbunden sind, die z.B. Analogeingangs-(AI)- oder Digitaleingangs-(DI)-Funktionsblöcke oder sonstige Funktionsblöcke sein können, die für die Übertragung von Signalen zu den Voter-Funktionsblöcken 192 vorgesehen sind. Bei den Voter-Funktionsblöcken 192 und 194 ist mindestens ein Ausgang mit einem oder mehreren anderen Funktionsblöcken 191 verbunden, die Analogausgänge (AO), Digitalausgänge (DO), „Ursache- und-Wirkung“-Logik implementierende „Cause and Effect“-Funktionsblöcke oder Steuer- und Diagnose-Funktionsblöcke usw. sein können, die Ausgangssignale von den Voter-Funktionsblöcken 192 und 194 empfangen können, um den Betrieb der Sicherheitseinrichtungen 160 und 162 zu steuern. Selbstverständlich kann das Sicherheitssteuermodul 158a auf beliebige gewünschte Weise programmiert sein, sodass beliebige Typen von Funktionsblöcken enthalten sind, die in beliebiger bzw. sinnvoller Weise für die Ausführung beliebiger gewünschter Funktionen konfiguriert sind. Zusätzlich oder alternativ dazu können andere Funktionsblöcke wie z.B. AI- oder DI-Funktionsblöcke direkt mit Sicherheitssystemlogik verbunden sein, um ein Sicherheitslogik-Steuermodul bereitzustellen, das auf von den AI- oder DI-Blöcken erkannte Ereignisse reagiert, indem beim Auftreten von einem oder mehreren dieser Ereignisse eine oder mehrere Abschalteinrichtungen aktiviert werden. Es ist ersichtlich, dass das Steuermodul 158a und jeder der darin enthaltenen Funktionsblöcke separate Softwareobjekte sind, die in das Sicherheitssystem 112 geladen und bei Bedarf während des Betriebs geändert werden können. Bevor diese Einrichtungs- bzw. Änderungsvorgänge implementiert werden können, müssen diese Softwareobjekte jedoch möglicherweise eine Autorisierung über die Freigaberoutine 181 empfangen, was im Folgenden detailliert beschrieben wird.
Insbesondere ist die Freigaberoutine 181 in die Konfigurationsanwendung 180 (oder in andere in der verfahrenstechnischen Anlage verwendete Anwendungen) integriert bzw. kommunikativ damit verbunden, um zu gewährleisten, dass für jedes neue oder geänderte Softwareobjekt, das eingerichtet oder geändert wird, die korrekte Autorisierung oder Prüfung erfolgt, bevor das Softwareobjekt in einem Online-Verfahren tatsächlich geladen oder auf sonstige im Prozesssteuersystem 112 oder im Sicherheitssystem 114 implementiert wird.
Wie ersichtlich ist, ist die Freigaberoutine 181 für Softwareobjekte eng in das sicherheitsgerichtete System (oder in das Prozesssteuersystem) integriert, und demzufolge kann die Freigaberoutine 181 die Sicherheit des sicherheitsgerichteten Systems nutzen. Da die Freigaberoutine 181 in der gleichen Umgebung ist wie die Planungs- bzw. Konfigurationssoftware 180 für die Prozesssteuerung oder das Sicherheitssystem, können die Prüfer ferner zur Prüfung des zur Freigabe anstehenden Softwareobjekts die gleichen Tools verwenden, die zu seiner Entwicklung eingesetzt wurden. Dadurch gibt es keine Probleme hinsichtlich der Genauigkeit des geprüften Softwareobjekts. Weiter verhindert die Freigaberoutine 181, dass Softwareobjekte, die einer Freigabe bedürfen, in die Steuer- oder Sicherheitsumgebung geladen werden, bevor alle erforderlichen Freigaben erteilt sind. Damit kann die Prozesssteuerung bzw. das sicherheitsgerichtete System gewährleisten, dass nur freigegebene Softwareobjekte ausgeführt werden. Bei Bedarf kann die Freigaberoutine 181 aber einen Sicherheitsschlüssel enthalten (z.B. speichern), der für Benutzer, die diesen Schlüssel besitzen, die Möglichkeit bereitstellt, die Durchsetzung dieser Forderung zu umgehen und ein nicht freigegebenes Softwareobjekt zu laden.
Im Betrieb kann die Freigaberoutine 181 an Softwareobjekten vorgenommene Änderungen erkennen und veranlassen, dass an einem freigegebenen Softwareobjekt vorgenommene Änderungen dazu führen, dass die Versionsnummer des Softwareobjekts heraufgesetzt wird. Wenn die Versionsnummer des Softwareobjekts heraufgesetzt ist, wird weiter der Status des Softwareobjekts durch die Freigaberoutine 181 automatisch in einen nicht freigegebenen Status geändert. Demzufolge kann die neue Version des Software-objekts nicht in das Prozesssteuersystem geladen oder dort auf sonstige Weise implementiert werden, bevor alle Freigaben an der neuen Version des Softwareobjekts erneut ausgeführt sind.
Zusätzlich kann die Freigaberoutine 181 alle Freigaben und/oder Zurückweisungen eines bestimmten Softwareobjekts in einem dem Softwareobjekt zugeordneten Audit-Trail der Konfiguration aufzeichnen. Als Ergebnis dieser Merkmale erfolgt die Validierung des Softwareobjekts als Bestandteil der Validierung der Prozesssteuerung bzw. des sicherheitsgerichteten Systems.
5A zeigt ein Ablaufdiagramm 185 mit der Darstellung von Schritten, die von der Freigaberoutine 181 unter Verwendung der gleichen oder unterschiedlicher Softwareroutinen implementiert werden können, um Freigabefunktionen in der Prozesssteuerung und/oder im Sicherheitssystem bereitzustellen. Bei einem Block 186 überwacht die Freigaberoutine 181 die Softwareentwicklungsanwendung (z.B. die Konfigurationsroutine 180) oder die Konfigurationsdatenbank, um zu bestimmen, ob und wann an Änderungen an Softwareobjekte vorgenommen worden sind. Der Block (bzw. die Routine) 186 kann bestimmen, dass eine Änderung an einem Softwareobjekt vorgenommen worden ist, indem Änderungen eines bestehenden Softwareobjekts, die Einrichtung eines neuen Softwareobjekts oder auch der Eingang einer Anforderung bezüglich der Implementierung des Freigabeprozesses, beispielsweise durch einen Softwareobjekt-Entwickler, erkannt werden. Selbstverständlich kann der Block 186 vor der Implementierung des Freigabeprozesses warten, bis alle Änderungen am Softwareobjekt entsprechend der Angabe beispielsweise des Softwareentwicklers erfolgt sind, wobei dieser durch die Betätigung einer Schaltfläche in der Entwicklungsanwendung angibt, dass die Änderungen vollständig sind. Beim Erkennen einer an einem Softwareobjekt vorgenommenen Änderung oder etwas später kann ein Block 187 in jedem Fall automatisch oder nach Aufforderung durch einen Entwickler ein Freigabeverfahren einleiten.
Während des Freigabeverfahrens kann ein Block 188 (beispielsweise in der Freigaberoutine 181) eine Gruppe von Entitäten (die eine oder mehrere Personen umfassen können) bestimmen, und als Teil dieses Vorgangs kann er auf der Grundlage von durch einen Benutzer oder auf sonstige Weise bei der Konfiguration der Prozesssteuerung oder des Sicherheitssystems bereitgestellten Informationen die Anzahl und Arten (wie z.B. die hierarchische Position) von Signaturen bestimmen, die für die Freigabe erforderlich sind. Bei einer Ausführungsform kann der Block 188 den von einem Benutzer oder einem Konfigurationsbeauftragten (wie z.B. dem Konfigurationsbeauftragten für das Sicherheitssystem) eingegebenen Risikoreduktionsfaktor (RRF) verwenden, um die Arten und die Anzahl der erforderlichen Freigaben zu bestimmen. In diesem Fall kann der Benutzer den gewünschten RRF, der für eine bestimmte Funktion oder ein Softwareobjekt erzielt werden soll, und der Block 188 verwendet diesen RRF zur Bestimmung des erforderlichen SIL-Pegels. Der Block 188 kann dann, zum Beispiel unter Verwendung einer Suchtabelle (LUT), den SIL-Pegel verwenden, um die Art der erforderlichen Signaturen zu bestimmen (z.B. die Anzahl von Signaturen, ob die Signaturen aus der gleichen oder aus unterschiedlichen Abteilungen kommen müssen, den Pegel oder den Typ der Tätigkeit oder Position, die der Prüfer ausübt usw.). Es ist anzumerken, dass jede einzelne sicherheitsgerichtete Funktion einen ihr zugeordneten SIL-Pegel hat und dass somit ein bestimmter SIL-Pegel für eine sicherheitsgerichtete Funktion spezifisch ist und sich bei unterschiedlichen Sicherheitsfunktionen ändern kann.
In jedem Fall bestimmt anschließend ein Block 189 die eigentlichen Personen, an die dann das Softwareobjekt zur Freigabe weitergeleitet wird. Bei Bedarf können die Namen, die elektronischen Adressen oder sonstige elektronische Kontaktinformationen für die Prüfer in der ausgewählten Gruppe aus einer entsprechenden Suchtabelle erhalten werden. Zusätzlich oder alternativ dazu können die Prüfergruppe und die dazugehörigen elektronischen Kontaktinformationen über ein Anzeige-Terminal direkt vom Konfigurationsbeauftragten, von der Person, die die Änderung am Softwareobjekt vornimmt, oder von beliebigen anderen geeigneten Personen erhalten werden. Als Teil dieses Vorgangs kann der Block 189 eine gespeicherte Liste möglicher Namen oder Dienststellen bewerten (sowie die dazugehörigen elektronischen Adressen usw.) und auf beliebige gewünschte oder vorbestimmte Weise mit oder ohne Hilfe des Softwareobjekt-Entwicklers aus dieser Liste die Auswahl treffen. Alternativ dazu kann der Block 189 über eine Benutzerschnittstelle bestimmte Aufsichtspersonen auffordern, die einzelne(n) Person(en) auszuwählen, die den geforderten Stufen und Abteilungen für den Freigabevorgang entsprechen.
Nach der Auswahl der eigentlichen Prüfer leitet ein Block 190 anschließend das eingerichtete bzw. geänderte Softwareobjekt an die ausgewählten Prüfer weiter und wartet auf die Rückmeldungen der Prüfer, ob das angelegte bzw. geänderte Softwareobjekt freigegeben ist oder nicht. Ein Block 191 kann die Antworten der Prüfer überwachen, um zu bestimmen, (ob und) wann alle Freigaben eingegangen sind, und, falls alle Prüfer (oder eine vorbestimmte Anzahl von Prüfern) das geänderte Softwareobjekt freigeben, kann ein Block 192 das Softwareobjekt als ladefähig markieren. Falls aber nicht von alle Prüfern Antworten eingegangen sind oder falls einer der Prüfer das Softwareobjekt zurückgewiesen hat, markiert die Freigaberoutine 181 das Softwareobjekt nicht zum Download, sodass die Verwendung des Softwareobjekts in der Prozesssteuerung oder im Sicherheitssystem verhindert wird.
Selbstverständlich kann die Freigaberoutine 181 in einer Schleife verweilen, bis alle Antworten eingegangen sind, und dem Entwickler oder Benutzer die Antworten auf beliebige gewünschte Weise zur Verfügung stellen. Falls der Block 191 ermittelt, dass eine bestimmte Anzahl von Zurückweisungen eingegangen ist, kann der Block 193 das Softwareobjekt so markieren, das es einer Änderung oder der Neuvorlage bei den Prüfern bedarf, um dadurch den Download des Softwareobjekts freizugeben.
Selbstverständlich können alle Blöcke in der Freigaberoutine 181 die Änderungen des Softwareobjekts wie auch die Zusammenstellung von dem Softwareobjekt zugeordneten Freigaben und Zurückweisungen und alle sonstigen Informationen zum Freigabevorgang in der Konfigurationsdatenbank oder dem Audit-Trail, der dem Softwareobjekt zugeordnet ist, protokollieren. Weiter kann die Freigaberoutine 185 Informationen zum Status des Prüfvorgangs, wie z.B. die Identität der Prüfer, welcher Prüfer geantwortet hat, welche Prüfer das neue bzw. geänderte Softwaremodul freigegeben und/oder welche es zurückgewiesen haben usw., verfolgen und bei Bedarf dem Entwickler (oder auch den anderen Prüfern) anzeigen. Bei Bedarf kann der Block 191 an Prüfer, die nicht geantwortet haben, Erinnerungen senden.
Zusätzlich kann die Freigaberoutine 185 nach der erfolgten Freigabe eines Softwaremoduls in einem Online-Verfahren, d.h. während des Betriebs der Prozesssteuerung oder des Sicherheitssystems, in dem sich das Softwareobjekt befindet, den RRF verwenden, um zu bestimmen, ob die dem Softwareobjekt zugeordnete Sicherheitsfunktion bzw. Betriebsweise noch den Planungskriterien entspricht. Insbesondere kann ein Konfigurationsbeauftragter bestimmen, welches Element der Sicherheitsfunktion periodisch getestet werden muss, welcher Testzeitraum gelten soll und wie sich der Test auf den RRF-Gesamtwert für die Sicherheitsfunktion auswirkt. Diese Details werden normalerweise zum Zeitpunkt der Entwicklung bestimmt und sind somit dem Konfigurationsbeauftragten bei der Implementierung der Funktion bekannt.
Entsprechend der Darstellung in 5B enthält ein Online-Überwachungsabschnitt 194 der Freigaberoutine einen Block 195, der den Test der Elemente überwacht. Falls das periodische Testintervall für ein spezifisches Softwareobjekt abgelaufen ist, was von einem Block 196 ermittelt wird, bestimmt ein Block 197 den erzielten Ist-RRF (auf der Grundlage der ausgebliebenen Ausführung des Tests der Sicherheitsfunktion) und zeigt diesen geänderten RRF einem Benutzer, wie z.B. einem Supervisor oder Bediener des Sicherheitssystems, an. Ein Block 198 kann auch diesen geänderten RRF mit dem Vorgabe-RRF vergleichen und einen Alarm erzeugen, wenn der Vorgabe-RRF nicht mehr eingehalten wird. Bei Bedarf kann ein Block 199 die Informationen in der SIL nutzen, um automatisch einen Arbeitsauftrag zu erzeugen (beispielsweise unter Angabe eines auszuführenden Tests), und zwar vor dem Testintervall oder nach dem Ablauf des Testintervalls, um den RRF auf oder über dem geplanten Vorgabewert zu halten oder um den RRF so schnell wie möglich zu seinem geplanten Wert zurückzubringen.
Es ist ersichtlich, dass, obwohl in 1 eine einzelne Freigaberoutine 18 und in 4 eine einzelne Freigaberoutine 181 dargestellt ist, Komponenten dieser Routinen in anderen Computern oder Workstations gespeichert sein können, sodass die Prüfer an anderen Workstations als der Entwickler positioniert sein können. In diesem Fall würde in jedem Terminal einer Gruppe von Prüfterminals (wie den in 1 dargestellten Prüfterminals 32), die kommunikativ mit dem Entwicklungsterminal verbunden sind, ähnliche oder sich ergänzende Software installiert, um es den Prüfern zu ermöglichen, Freigabemeldungen von der Routine 18 bzw. 181 am Entwicklungsterminal zu empfangen und Software in der Prozesssteuerung oder im Sicherheitssystem aufzurufen, um das zu prüfende Softwareobjekt zu analysieren und mit einer Freigabe oder einer Zurückweisung und beliebigen Kommentaren, die der Prüfer eingeben möchte, zu antworten.
Weiter können die Freigaberoutinen 18 bzw. 181, wie im Folgenden detailliert beschrieben wird, eine beliebige Anzahl von Komponenten haben, die unterschiedliche Funktionen ausführen, wie z.B. die Auswahl von Prüfern, die Änderung von Softwareobjekten usw. Einige dieser Komponenten werden in Zusammenhang mit 6-20 detailliert beschrieben, doch es ist ersichtlich, dass stattdessen oder alternativ dazu andere Routinen den Freigabe- oder Entwicklungsroutinen zugeordnet sein können. Ferner ist ersichtlich, dass, obwohl eine Anzahl von Subroutinen bei 6-20 bezüglich der Freigabe einer in einem Prozesssteuersystem verwendeten Rezeptur beschrieben ist, diese Routinen auch für die Freigabe anderer Softwareobjekte, wie z.B. von Softwareobjekten in einem Sicherheitssystem, verwendet werden können.
In 6 beginnt eine Rezeptureditor-Routine 400, die durch einen oder mehrere Prozessoren 21 der Workstations 14 ausgeführt werden kann, mit der Ausführung eines Blocks 402, bei dem ein Benutzer oder Bediener eine Rezeptur zur Verwendung im Prozesssteuersystem 10 einrichtet oder ändert, wobei dies die Änderung der dafür zugeordneten Softwareobjekte beinhalten kann. Wie leicht ersichtlich ist, kann ein Benutzer Rezepturen oder andere Softwareobjekte unter Verwendung der in Zusammenhang mit 1-5 beschriebenen Verfahren oder von beliebigen anderen geeigneten Verfahren einrichten oder ändern. Nachdem die Rezeptur angelegt oder in geeigneter Weise geändert wurde, geht die Steuerung von Block 402 zu Block 406 über. Wie im Folgenden in Zusammenhang mit 7-13 detailliert beschrieben ist, kann eine Setup-Routine 404 für die Autorisierung (7) mindestens einmal vor der Ausführung der Rezeptureditor-Routine 400 oder zu einem beliebigen anderen Zeitpunkt vor der Änderung und/oder dem Download einer Rezeptur oder anderer Softwareobjekte im System 10 ausgeführt werden. Allgemein kann das Autorisierungs-Setup, ohne darauf beschränkt zu sein, die Angabe von Personen oder Entitäten (z.B. Unterzeichner), deren Freigabe erforderlich ist, um eine Rezeptur oder ein anderes Softwareobjekt zu implementieren, sowie das Entfernen oder Ändern von Unterzeichnern umfassen.
Bei Block 406 wird von jedem der beim Autorisierungs-Setup angegebenen Unterzeichner die Freigabe der bei Block 402 eingerichteten oder geänderten Rezeptur angefordert. Die Freigabeanforderung kann, ohne darauf beschränkt zu sein, den Versand von elektronischer Post an die Unterzeichner, die in Zusammenhang mit der Setup-Routine 404 für die Autorisierung zur Prüfung der Rezeptur angegeben sind, umfassen sowie die Erstellung eines Reports mit der Angabe des Freigabestatus für jeden der angegebenen Unterzeichner, den Versand einer Sofortnachricht an die Unterzeichner, die die Rezeptur prüfen sollen oder den Versand einer Benachrichtigung an die Unterzeichner über ein beliebiges anderes geeignetes Kommunikationsverfahren. Nach der Anforderung der Freigabe von jedem Unterzeichner bei Block 406 beendet die Rezeptureditor-Routine 400 die Ausführung oder gibt die Steuerung an eine andere Routine zurück, die die Rezeptureditor-Routine 400 aufgerufen hatte.
Weitere Details der Setup-Routine 404 für die Autorisierung sind in Zusammenhang mit 7 und 8 angegeben, die ein Ablaufdiagramm bzw. eine Benutzerschnittstelle für die Setup-Routine 404 für die Autorisierung darstellen. Obwohl die Setup-Routine 404 für die Autorisierung normalerweise einmal beim Systemstart ausgeführt wird, könnte die Setup-Routine 404 für die Autorisierung stattdessen bei Bedarf mehr als einmal ausgeführt werden. Allgemein kann ein Benutzer entsprechend der Darstellung in 7 nach der Ausführung der Setup-Routine 404 für die Autorisierung beim „Abbruch/OK“-Block 410 entscheiden, die Ausführung der Routine abzubrechen. Alternativ dazu kann der Benutzer bei den Blöcken 412, 414 oder 416 entscheiden, Rezepturunterzeichner hinzuzufügen, zu entfernen bzw. zu ändern. Nach dem Hinzufügen, Entfernen oder Ändern von Unterzeichnern geht die Steuerung von den Blöcken 412, 414 oder 416 weiter und ermöglicht einem Benutzer bei Block 410 die Entscheidung, die Setup-Routine 404 für die Autorisierung abzubrechen oder zu beenden, oder erneut unter Verwendung der Blöcke 412-416 Unterzeichner hinzuzufügen, zu entfernen oder zu ändern. Falls der Benutzer bei Block 410 entscheidet, die Setup-Routine 404 für die Autorisierung abzubrechen oder zu beenden, endet die Setup-Routine 404 für die Autorisierung.
Eine Benutzerschnittstelle entsprechend der Darstellung in 8 enthält eine Registerkarte 422 „Rezepturautorisierungs-Setup“, die einem Benutzer die Auswahl von Interface-Schaltflächen 424, 426 oder 428 zum Hinzufügen, Ändern bzw. Entfernen von Unterzeichnern ermöglicht. Die Interface-Schaltflächen 424-428 zum Hinzufügen, Ändern bzw. Entfernen entsprechen den in 7 wiedergegebenen Blöcken 412-416 zum Hinzufügen, Entfernen und Ändern (und können zum Aufruf der dadurch ausgeführten Funktionen aufgerufen werden). Weitere Details zu jedem der Blöcke 412-416 und damit zusammenhängend der Interface-Schaltflächen 424-428 sind in Zusammenhang mit 9-13 angegeben. Beim Hinzufügen, Ändern oder Entfernen von Unterzeichnern wird der Status der Unterzeichner in einem Textfeld 430 angezeigt. Entsprechend der Darstellung in 8 enthält das Textfeld 430 eine Spalte 432 „Unterzeichnerbeschreibung“, in der die Namen der Unterzeichner aufgeführt sind, wobei dies Namen von Personen oder Entitäten sein können, und es enthält auch eine Spalte 434 „Funktionssperre“, die die Funktionssperren aufführt, über welche die entsprechenden Unterzeichner verfügen müssen, um damit den Zugang zu einer Freigabe zu steuern. Bei dem in 8 wiedergegebenen Beispiel soll die Rezeptur von den Bereichen Engineering, Produktion und Qualitätssicherung, denen die Funktionssperren REZEPTURFREIGABE_01 entsprechen, geprüft und abgezeichnet werden.
In 8 sind auch zwei Checkboxen 436 und 438 dargestellt mit den Bezeichnungen „Rezepturautorisierung freigeben“ und „Weitergabe der Freigabe auf enthaltene Rezepturen erlauben“ (d.h. auf Subrezepturen). Wenn im Betrieb die Checkbox 436 aktiviert ist, werden die Systemmerkmale zur Freigabe der Rezepturautorisierung und der Setup-Vorgang für die Autorisierung freigegeben. Wenn die Checkbox 438 nicht aktiviert ist, gibt dies an, dass der Benutzer nicht die Möglichkeit hat, Freigaben weiterzugeben. Ist dagegen die Checkbox 438 aktiviert, hat der Benutzer die Möglichkeit, Freigaben an Subrezepturen weiterzugeben. Eine Hauptrezeptur kann beispielsweise aus zwei oder mehr Subrezepturen zusammengesetzt sein oder sie enthalten, auf die eine der Hauptrezeptur zugeordnete Freigabe automatisch ausgedehnt werden kann. Selbstverständlich kann diese automatische Weitergabe von Freigaben für Rezepturen zu einer signifikanten Zeitersparnis führen, und zwar insbesondere bei Rezepturen, die eine große Anzahl von Subrezepturen enthalten.
Die Benutzerschnittstelle 420 enthält auch Interface-Schaltflächen „Abbrechen“ und „OK“, die mit den Kennziffern 440 bzw. 442 bezeichnet sind. Die Interface-Schaltflächen 440 und 442 entsprechen dem Block 410 „Abbruch/OK“ aus 7, und sie ermöglichen einem Benutzer das Verlassen der Setup-Routine 404 für die Autorisierung. Während beide Interface-Schaltflächen 440 und 442 einem Benutzer das Verlassen der Setup-Routine 404 für die Autorisierung ermöglichen, beendet die Interface-Schaltfläche „Abbrechen“ die Setup-Routine 404 für die Autorisierung, ohne die Änderungen zu übernehmen, die an der Setup-Routine 404 für die Autorisierung vorgenommen wurden. Dagegen ermöglicht die Interface-Schaltfläche 442 „OK“ dem Benutzer das Verlassen der Setup-Routine 404 für die Autorisierung und erhält die bei der Verwendung der Benutzerschnittstelle 420 am Autorisierungs-Setup vorgenommenen Änderungen.
In 9 werden anschließend weitere Details des Blocks 412, der eine Routine zum Hinzufügen darstellt, wiedergegeben. Die Addierroutine 412 beginnt die Ausführung bei Block 450, der die vom Benutzer erfolgte Auswahl der Funktionssperre empfängt. Entsprechend der Darstellung in 10 kann eine grafische Benutzerschnittstelle bzw. ein Popup-Fenster 452 eine Box 454 „Funktionssperre Freigabe“ enthalten, in die ein Benutzer den Namen für die Funktionssperre für die Freigabe eingibt. Entsprechend der Darstellung in 10 kann die Box 454 beispielsweise eine Angabe enthalten, dass die ausgewählte Funktionssperre für die Freigabe REZEPTURFREIGABE_03 ist.
Zurück in 9, empfängt der Block 460 nach dem Eingang der Auswahl der Funktionssperre bei Block 450 eine vom Benutzer bereitgestellte Unterzeichnerbeschreibung. Entsprechend der Darstellung in der in 10 wiedergegebenen Benutzerschnittstelle 452 kann der Benutzer beispielsweise eine Unterzeichnerbeschreibung bei einem Block 462 eingeben. Als Beispiel ist in Block 462 die Beschreibung „Teamleiter“ wiedergegeben, die angibt, dass der Benutzer als Unterzeichner Teamleiter mit einer Funktionssperre für die Freigabe REZEPTURFREIGABE_03 hinzufügen möchte.
Nachdem die Auswahl der Funktionssperre und die Unterzeichnerbeschreibung bei Block 450 bzw. 460 eingegangen sind, geht die Steuerung zu Block 466 über, der bestimmt, ob die Funktionssperre oder die Unterzeichnerbeschreibung fehlt oder ob die in 10 mit den Kennziffern 470 bzw. 472 bezeichneten Interface-Schaltflächen „Abbruch“ oder „OK“ betätigt worden sind. Falls die Sperre oder die Beschreibung fehlt, geht die Steuerung von Block 466 zu Block 450 über. Falls alternativ dazu der Block 466 ermittelt, dass die Interface-Schaltfläche 470 „Abbruch“ oder 472 „OK“ vom Benutzer betätigt worden ist, beendet die Addierroutine 412 die Ausführung und gibt die Steuerung an die Setup-Routine 404 für die Autorisierung aus 7 zurück. Entsprechend der Beschreibung mit Bezug auf die Benutzerschnittstelle 420 aus 8 bewirkt die Betätigung der Interface-Schaltfläche 470 „Abbruch“, dass die Addierroutine 412 die Ausführung beendet, ohne während der Ausführung der Routine vorgenommene Änderungen zu sichern. Wie vorstehend erwähnt, bewirkt die Betätigung der Interface-Schaltfläche 472 „OK“ dagegen, dass die Addierroutine 412 beendet wird und während der Ausführung der Addierroutine 412 vorgenommene Änderungen gesichert werden. Falls von der Addierroutine 412 ein neuer Approver oder Unterzeichner hinzugefügt wird, werden alle zuvor freigegebenen Rezepturen (d.h. Rezepturen, zu denen alle ursprünglich erforderlichen Freigaben eingegangen sind) automatisch zu „nicht autorisiert“, bis die Freigabe durch den neu hinzugefügten Unterzeichner erhalten worden ist.
Weitere Details der Löschroutine 414, die in Zusammenhang mit der in 8 wiedergegebenen Benutzerschnittstelle 420 ausgeführt wird, sind in Zusammenhang mit 11 dargestellt. Insbesondere beginnt die Löschroutine 414 die Ausführung bei Block 480, der die Auswahl der zu löschenden Unterzeichnerbeschreibung empfängt. Der Benutzer kann diese Auswahl bereitstellen, indem er eine im Textfeld 430 der Benutzerschnittstelle 420 aus 8 angezeigte Unterzeichnerbeschreibung auswählt. Nachdem der Benutzer die zu löschende Beschreibung gewählt hat, betätigt der Benutzer die Interface-Schaltfläche 428 „Löschen“, um seine Absicht zum Entfernen der ausgewählten Unterzeichnerbeschreibung bzw. des Unterzeichners zu erklären. Nachdem der Block 480 die Ausführung abgeschlossen hat, geht die Steuerung zu Block 428 über, der die Bestätigung des vom Benutzer angeforderten Löschens empfängt. Nachdem ein Benutzer die zu löschende Unterzeichnerbeschreibung ausgewählt und die Interface-Schaltfläche 428 „Löschen“ betätigt hat, kann die Löschroutine 414 den Benutzer auffordern, seine Absicht zum Löschen der ausgewählten Unterzeichnerbeschreibung über eine Benutzerschnittstellen-Grafik zu bestätigen, die dem Benutzer über einen Anzeigebildschirm vorgelegt wird. Eine derartige Grafik kann Interface-Schaltflächen „OK“ oder „Abbrechen“ enthalten, wobei die Betätigung (z.B. durch Auswahl mittels Maus, Tastatur usw.) der Interface-Schaltfläche „OK“ die Absicht des Benutzers zum Löschen der ausgewählten Unterzeichnerbeschreibung bestätigt und die Interface-Schaltfläche „Abbrechen“ zum Abbruch des Löschens der ausgewählten Beschreibung führt. Nachdem die Bestätigung des Löschens bei Block 482 eingegangen ist, beendet die Löschroutine 414 die Ausführung und gibt die Steuerung an die Setup-Routine 404 für die Autorisierung zurück.
Weitere Details der Änderungsroutine 416 aus 7 sind in Zusammenhang mit 12 und 13 dargestellt. Die Änderungsroutine 416 beginnt die Ausführung bei Block 484, der vom Benutzer eine Auswahl der zu ändernden Unterzeichnerbeschreibung empfängt. Der Benutzer kann beispielsweise den in 8 mit der Bezeichnung „Qualitätssicherung“ wiedergegebenen Unterzeichner auswählen und dann die Interface-Schaltfläche 426 „Ändern“ betätigen. Nach der Betätigung der Interface-Schaltfläche 426 „Ändern“ kann dem Benutzer eine Benutzerschnittstelle wie z.B. eine in 13 dargestellte Benutzerschnittstelle 486 vorgelegt werden, die ein Feld 488 „Unterzeichnerbeschreibung“ und ein Feld 490 „Funktionssperre Freigabe“ enthalten kann. Die Benutzerschnittstelle 486 kann auch Interface-Schaltflächen 492 „OK“ und 494 „Abbrechen“ enthalten. Nachdem die Änderungsroutine 416 eine Auswahl der zu ändernden Unterzeichnerbeschreibung erhalten hat (in diesem Fall wurde der Unterzeichner „Qualitätssicherung“ für die Änderung ausgewählt), geht die Steuerung vom Block 484 zum Block 496 über. Der Block 496 empfängt Änderungen der Unterzeichnerbeschreibung, wie z.B. Änderungen des Unterzeichnernamens, der Funktionssperre für die Freigabe oder andere geeignete Änderungen. Nachdem der Benutzer bei Block 488 eine Unterzeichnerbeschreibung vorgegeben hat, kann der Benutzer beispielsweise den Namen des Unterzeichners ändern, oder kann die in Block 490 angezeigte Funktionssperre für die Freigabe ändern, und er kann eine der Interface-Schaltflächen 492 „OK“ oder 494 „Abbrechen“ wählen. Wie vorstehend beschrieben, sichert die Betätigung der Interface-Schaltfläche 492 „OK“ die an der Unterzeichnerbeschreibung vorgenommenen Änderungen. Dagegen beendet die Betätigung der Interface-Schaltflächen 494 „Abbrechen“ die Änderungsroutine 416, ohne vorgenommene Änderungen zu sichern. In jedem Fall beendet die Betätigung von einer der Interface-Schaltflächen 490 oder 492 die Ausführung der Änderungsroutine 416 und gibt die Steuerung zur Setup-Routine 404 für die Autorisierung aus 7 zurück. Wie bei der Addierroutine 412 führt die Änderung eines Unterzeichners oder Approvers automatisch dazu, dass alle zuvor freigegebenen Rezepturen, für die die Freigabe des betreffenden Unterzeichners erforderlich ist, zu „nicht autorisiert“ werden.
Bis hierher wurde eine Beschreibung des Hinzufügens, Löschens und Änderns von Unterzeichnern oder Rezepturprüfern oder Approvern gegeben. Die beschriebenen Routinen oder die Routinen, die den in Zusammenhang mit diesen Routinen beschriebenen Funktionsumfang enthalten, können in beliebigen der Workstations 14 und/oder der Terminals 32 aus 1 oder in beliebigen der in 4 dargestellten Workstations 116 implementiert sein.
Während die vorstehenden Figuren und Beschreibungen die Spezifikation von Unterzeichnern behandeln, beziehen sich 14-18 auf die Prüf-, Freigabe- oder Zurückweisungsvorgänge, die von Unterzeichnern ausgeführt werden können. Die in 14-18 wiedergegebenen Routinen und Benutzerschnittstellen können auf den Terminals 32 und/oder den Workstations 14 aus 1 oder auf beliebigen der in 4 dargestellten Workstations 116 implementiert sein. Insbesondere können der eine oder die mehreren Speicher 20 und 34 Anweisungen speichern, die von einem oder mehreren der Prozessoren 21 und 36 ausgeführt werden können, um Vorgänge, die die Blöcke in den Routinen wiedergeben, auszuführen.
In 14 beginnt eine Rezepturautorisierungsroutine 500 die Ausführung bei Block 502, der Unterzeichner- und Statusinformationen zu der in Prüfung befindlichen Rezeptur anzeigt. Beispielsweise kann eine in 15 dargestellte Benutzerschnittstelle 504 ein Textfeld 506 mit einer Anzahl von Spalten 508-518 enthalten, die die Identität des Unterzeichners, den Status, den Benutzertyp, die Zeit, den Kommentar und den Knoten wiedergeben. Die Unterzeichnerspalte 508 listet die für die Freigabe der Rezeptur erforderlichen Signaturen auf, und die Statusspalte 510 gibt für jeden Unterzeichner den Status der Signatur wieder. Beispielsweise kann der Signaturstatus leer sein oder „Warten“, „Freigegeben“ oder „Abgelehnt“ lauten, wobei ein leerer Status oder ein Status „Warten“ angeben können, dass der Unterzeichner die Rezeptur nicht geprüft hat. Die Benutzerspalte 512 führt den für die zuletzt vorgenommene Signaturänderung verantwortlichen Benutzertyp auf. Die Zeitspalte 514 listet den Zeitpunkt der zuletzt vorgenommenen Signaturänderung auf. Die Kommentarspalte 516 gibt mögliche Kommentare wieder, die der Unterzeichner bei der Freigabe oder Zurückweisung der Rezeptur eingeben kann, und der Knoten 518 bezeichnet den Systemknoten, an dem der Unterzeichner die Rezeptur freigegeben oder zurückgewiesen hat. Beispielsweise kann der Knoten ein beliebiges der Terminals 32 und/oder eine beliebige der Workstations 14 aus 1 oder der in 4 wiedergegebenen Workstations 116 sein. Zusätzlich zum Textblock 506 kann die Benutzerschnittstelle 504 Interface-Schaltflächen 520-526 („Schließen“, „Freigeben“, „Ablehnen“ und „Löschen“) haben, die in Zusammenhang mit der in 14 dargestellten Rezepturautorisierungsroutine 500 beschrieben werden.
Nachdem der Block 502 Unterzeichner- und Statusinformationen angezeigt hat, empfängt der Block 530 die Unterzeichnerauswahl, die vom Benutzer über die Auswahl einer der Interface-Schaltflächen 520-526 mitgeteilt werden kann. Insbesondere geht, falls der Benutzer die Interface-Schaltfläche 520 „Schließen“ betätigt, die Steuerung der Rezepturautorisierungsroutine 500 vom Block 530 zum Block 540 über, wodurch die Benutzerschnittstelle 504 geschlossen wird, die Ausführung der Rezepturautorisierungsroutine 500 beendet wird und die Steuerung zu einer beliebigen Routine zurückgeht, die die Rezepturautorisierungsroutine 500 aufgerufen hatte.
Nachdem der Block 552 die Ausführung abgeschlossen hat, geht die Steuerung zum Block 560 über, der bei der Freigabe vom Benutzer eingegebene Kommentare empfängt. Die in 17 wiedergegebene Benutzerschnittstelle kann beispielsweise ein Textfeld 562 enthalten, in das Kommentare eingegeben werden können. Nachdem der Block 560 die Ausführung abgeschlossen hat, ermittelt der Block 561, ob der Benutzer autorisiert ist. Die bei Block 561 vorgenommene Autorisierungsprüfung kann feststellen, dass der Benutzername und/oder das Passwort, die bei Block 552 eingegangen sind, zulässig sind und/oder ob der dem Benutzernamen und Passwort zugeordnete Benutzer zur Erteilung einer derartigen Freigabe autorisiert ist. Falls bei Block 561 ermittelt wird, dass der Benutzer autorisiert ist, geht die Steuerung zum Block 566 über. Block 566 aktualisiert die Statusinformationen, um die Freigabe wiederzugeben. Beispielsweise enthält das Textfeld 562 den Kommentartext „Fertig für die Produktion“, der auch in 15 als von einem Unterzeichner der Produktion bei der Freigabe der Rezeptur nach der Ausführung von Block 566 eingegebener Kommentar wiedergegeben ist. Falls bei Block 561 ermittelt wird, dass der Benutzername oder das Passwort oder beide in Block 552 eingegangene Angaben nicht autorisiert sind, wird die Freigaberoutine 550 beendet.
Wie in Zusammenhang mit vielen der vorangegangenen Benutzerschnittstellenanzeigen beschrieben wurde, enthält die in 17 wiedergegebene Benutzerschnittstelle 554 Interface-Schaltflächen 568 „OK“ und 570 „Abbrechen“, die zum Beenden der Ausführung der Freigaberoutine 550 verwendet werden können, während die bei der Ausführung der Routine vorgenommenen Änderungen entweder gesichert oder verworfen werden. Entsprechend der Darstellung in 17 kann zusätzlich eine Checkbox 572 vorhanden sein, um einem Benutzer die Entscheidung für die Weitergabe der Freigabe an eventuell enthaltene Subrezepturen zu ermöglichen.
Wiederum mit Bezug auf 14 und 15 geht die Steuerung, falls ein Benutzer die Interface-Schaltfläche zur Zurückweisung betätigt, vom Block 530 zum Block 580 der Rezepturautorisierungsroutine 550 über. Der Block 580 stellt eine Zurückweisungsroutine dar, die detaillierter in 18 wiedergegeben ist. Entsprechend der Darstellung in 18 beginnt die Ausführung der Zurückweisungsroutine 580 bei Block 582, wobei der Benutzer einen Benutzernamen und ein Passwort eingibt, bevor die Steuerung zu Block 584 übergeht. Bei Block 584 kann ein Unterzeichner während des Vorgangs der Rezepturzurückweisung abgegebene Kommentare eingeben. Die Vorgänge der Blöcke 582 und 584 ähneln den Vorgängen der Blöcke 552 und 560 der in 16 wiedergegebenen Freigaberoutine 550, mit der Ausnahme, dass die Blöcke 582 und 584 in Zusammenhang mit der Zurückweisung der Rezeptur verwendet werden. Nachdem der Block 584 die Ausführung abgeschlossen hat, geht die Steuerung zu Block 585 über, der eine Autorisierungsprüfung ähnlich der bei dem in 17 wiedergegebenen Block 561 ausgeführten Prüfung vornimmt. Falls bei Block 585 ermittelt wird, dass ein Benutzer autorisiert ist, geht die Steuerung zum Block 586 über.
Der Block 586 aktualisiert die Statusinformationen, um die Zurückweisung der Rezeptur durch den Benutzer wiederzugeben. Der Block 586 zur Aktualisierung der Statusinformationen kann Informationen erzeugen, die über die in 15 wiedergegebene Benutzerschnittstelle 504 wiedergeben werden, um den Vorgang auszudrücken, dass ein Unterzeichner eine Rezeptur zurückgewiesen hat. Obwohl dies in den Figuren nicht dargestellt ist, kann die Zurückweisungsroutine 580 auch eine grafische Benutzerschnittstelle verwenden, die der in 17 wiedergegebenen und für die Freigabe von Rezepturen verwendeten Benutzerschnittstelle 554 ähnelt.
Mit Bezug wiederum auf 14 und 15 geht die Steuerung, falls ein Benutzer die in 15 wiedergegebene Interface-Schaltfläche 526 „Löschen“ betätigt, von Block 530 zu Block 590 der Rezepturautorisierungsroutine 500 über. Der Block 590 kann zum Löschen einer Signatur verwendet werden. Beispielsweise kann einer der in 15 dargestellten Unterzeichner von einem Benutzer ausgewählt und unter Verwendung der Interface-Schaltfläche 526 gelöscht werden. Nachdem aber eine Rezeptur beispielsweise zur Ausführung durch die Steuerung 12 (1) oder die Workstation 14 (1) heruntergeladen worden ist, kann die Auswirkung einer Freigabesignatur nicht zurückgezogen werden. Anders ausgedrückt, kann eine Signatur (d.h. eine Freigabe) nicht gelöscht oder zurückgewiesen werden, nachdem eine Rezeptur (oder ein beliebiges anderes Softwareobjekt) geladen worden ist.
Während die vorstehende Beschreibung die Auswahl von Unterzeichnern und die Prüfung von Rezepturen behandelt, kann eine Benutzerschnittstelle 600 entsprechend der Darstellung in 19 zur Erfassung des Status von Rezepturen im Prozesssteuersystem 10 verwendet werden. Beispielsweise kann die Benutzerschnittstelle 600 eine Anzahl von Spalten 602-610 enthalten, die jeweils den Rezepturnamen, die Bereiche Produktion, Engineering, Qualitätssicherung und den Teamleiter wiedergeben. Verkürzt ausgedrückt, listet die Spalte für den Rezepturnamen 602 alle nicht freigegebenen Rezepturen auf, und die Spalten 604-610 geben den Status jeder Rezeptur bei jedem Prüfer bzw. jeder Prüfentität wieder. Beispielsweise ist die Rezeptur mit der Bezeichnung „OP_CHARGE“ bei Produktion, Engineering, Qualitätssicherung und Teamleiter jeweils im Wartezustand. Dagegen haben die Kategorien Produktion, Engineering, Qualitätssicherung [sic] und Teamleiter jeweils die Rezeptur „PRC_PAINT“ freigegeben, wogegen diese Rezeptur vom Bereich Qualitätssicherung nicht freigegeben worden ist. Dementsprechend ist die Rezeptur „PRC_PAINT“ noch nicht freigegeben. Die Benutzerschnittstelle 600 kann auch Interface-Schaltflächen 612 „Schließen“ und 614 „Drucken“ enthalten, die zum Schließen der Benutzerschnittstelle 600 oder zum Drucken der Benutzerschnittstelle 600 benutzt werden können, um die in den Spalten 602-610 enthaltenen Informationen anzuzeigen.
Nachdem eine Rezeptur von allen Unterzeichnern geprüft und freigegeben worden ist, kann die Rezeptur in einer oder mehreren der in 1 wiedergegebenen Steuerungen 12 oder den in 4 dargestellten Steuerungen 176 heruntergeladen oder implementiert werden (oder andere Softwareobjekte können in den in 4 wiedergegebenen Sicherheitslogikmodulen 150-156 oder in beliebigen Feldgeräten, in denen diese Objekte möglicherweise geladen werden müssen, heruntergeladen werden). Eine Download-Routine 630 entsprechend der Darstellung in 20 ist ein Verfahren für die Durchführung des Downloads. Die Download-Routine 630 beginnt die Ausführung bei Block 632, der ein Download-Script erzeugt. Nachdem das Download-Script bei Block 632 erzeugt worden ist, geht die Steuerung zu Block 634 über, der ermittelt, ob die Rezeptur nicht abgemeldet ist (d.h. ob sie angemeldet ist) oder ob der Benutzer einen Schlüssel eingegeben hat, der den Download einer Rezeptur freigibt, auch wenn die Rezeptur abgemeldet ist. Versionskontrollsoftware wie die im US-Patent Nr. 6,449,624 beschriebene Software kann in Verbindung mit der Download-Routine 630 verwendet werden. Falls der Block 634 ermittelt, dass die Rezeptur abgemeldet ist und der Schlüssel nicht bereitgestellt wurde, geht die Steuerung zum Block 636 über, der den Download abbricht und die Ausführung der Download-Routine 630 beendet. Alternativ dazu geht die Steuerung, falls die Rezeptur nicht abgemeldet ist oder der Schlüssel bereitgestellt worden ist, vom Block 634 zum Block 638 über, der ermittelt, ob die Rezeptur autorisiert ist oder ob der Benutzer einen speziellen Schlüssel eingegeben hat, der den Download von nicht autorisierten Rezepturen freigibt. Die Rezepturautorisierung kann, ohne darauf beschränkt zu sein, die Sicherstellung enthalten, dass alle Unterzeichner die Rezeptur freigegeben haben. Falls der Block 638 ermittelt, dass die Rezeptur nicht autorisiert ist und der Schlüssel nicht bereitgestellt wurde, geht die Steuerung zum Block 636 über, der den Download vor dem Abschluss der Download-Routine 630 abbricht. Alternativ dazu geht die Steuerung, falls der Block 638 ermittelt, dass die Rezeptur autorisiert ist, oder falls der Schlüssel bereitgestellt wurde, zum Block 640 über, der ein Download-Label vorgibt. Das Download-Label kann aus einer oder mehreren Angaben oder anderen ähnlichen Textinformationen bestehen, die zu den heruntergeladenen Objekten hinzugefügt werden und Zeit, Datum, Version und Initiator (oder Benutzer) des Downloads enthalten. Zusätzlich enthält das Download-Label eine detaillierte Liste der individuellen heruntergeladenen Objekte (z.B. Rezepturen). Die Rezeptur wird anschließend bei Block 642 zum Runtime-System gesandt, das beispielsweise aus den in 1 wiedergegebenen Steuerungen 12 bestehen kann. Nach der Ausführung von Block 642 wird die Ausführung der Download-Routine 630 beendet, und die Steuerung geht zu der Routine zurück, die die Download-Routine 630 aufgerufen hatte.
Der vorstehenden Beschreibung kann entnommen werden, dass ein Softwareobjekt, das aktuell nicht freigegeben ist, nicht durch das Prozesssteuerungs- oder Sicherheitssystem heruntergeladen oder implementiert werden kann, bevor nicht alle dem betreffenden Softwareobjekt zugeordneten Unterzeichner oder Approver das Softwareobjekt freigegeben haben. Daher muss ein neues Softwareobjekt oder eine neue Rezeptur beispielsweise von einer vorbestimmten Liste oder Gruppe von Personen und/oder anderen Entitäten freigegeben werden (e.B. einer von der Setup-Routine 404 für die Autorisierung (7) erzeugten Liste von Personen und/oder anderen Entitäten). Zusätzlich wird ein zuvor freigegebenes Softwareobjekt oder eine Rezeptur nach einer Änderung automatisch zu „nicht autorisiert“ und muss somit von allen dazugehörigen Unterzeichnern oder Autorisierungsbeauftragten freigegeben werden, um das geänderte Softwareobjekt oder die Rezeptur entsprechend der Darstellung am Beispiel der in 20 wiedergegebenen Blöcke 638 und 640 herunterzuladen zu können.
Obwohl bestimmte erfindungsgemäß konstruierte Vorrichtungen beschrieben worden sind, ist der Umfang dieses Patents nicht darauf beschränkt. Dieses Patent deckt im Gegensatz dazu alle Ausführungsformen der Lehren der Erfindung ab, die entweder wörtlich oder nach dem Äquivalenzgrundsatz in angemessener Weise in den Schutzbereich der beigefügten Patentansprüche fallen.

Claims

Verfahren zur Freigabe von Softwareobjekten zur Verwendung in einem sicherheitsgerichteten System, wobei das Verfahren Folgendes umfasst: Erhalt von elektronischer Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, deren Freigabe vor der Implementierung eines Softwareobjekts in einem sicherheitsgerichteten System als Reaktion auf eine in einer Softwareobjekt-Entwicklungs-umgebung an dem Softwareobjekt vorgenommen Änderung erforderlich ist, wobei der Erhalt der elektronischen Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, die Bestimmung eines Sicherheitsgewährleistungs-Pegels aus einem bei Erhalt der elektronischen Identifikationsinformationen bestimmten Risikoreduktionsfaktor einschließt und die Auswahl der Entitätengruppe aufgrund des Sicherheitsgewährleistungs-Pegels einschließt; elektronische Übertragung einer Prüfanforderung zum Softwareobjekt an jede der Entitäten in der Entitätengruppe; Empfang einer elektronischen Angabe bezüglich der Freigabe oder Nichtfreigabe des Softwareobjekts von jeder Entität in der Entitätengruppe; und Verhinderung der Implementierung des Softwareobjekts im sicherheitsgerichteten System, bis jede Entität in der Entitätengruppe eine elektronische Angabe zur Freigabe des Softwareobjekts bereitstellt.
Verfahren nach Anspruch 1, wobei die elektronische Übertragung der Prüfanforderung zum Softwareobjekt die elektronische Benachrichtigung jeder Entität in der Entitätengruppe über ein Kommunikationsnetzwerk einschließt.
Verfahren nach Anspruch 2, wobei die elektronische Übertragung der Anforderung den Versand einer E-Mail-Nachricht an jede Entität in der Entitätengruppe einschließt.
Verfahren nach Anspruch 1, wobei die Verhinderung der Implementierung des Softwareobjekts im sicherheitsgerichteten System, bis jede Entität in der Entitätengruppe eine elektronische Angabe zur Freigabe des Softwareobjekts bereitstellt, die Freigabe des Softwareobjekts für den Download in das sicherheitsgerichtete System einschließt, falls jede Entität in der Entitätengruppe das Softwareobjekt freigibt.
Verfahren nach Anspruch 1, wobei der Erhalt der elektronischen Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, die Bestimmung der Anzahl von Personen in der Entitätengruppe aus dem Sicherheitsgewährleistungs-Pegel einschließt.
Verfahren nach Anspruch 1, wobei der Erhalt der elektronischen Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, die Bestimmung der hierarchischen Positionen der Personen in der Entitätengruppe aus dem Sicherheitsgewährleistungs-Pegel einschließt.
Verfahren nach Anspruch 1, wobei weiter die Protokollierung der von einer oder mehreren Entitäten in der Entitätengruppe empfangenen elektronischen Angabe zur Freigabe oder Nichtfreigabe eingeschlossen ist.
Verfahren nach Anspruch 1, wobei der Erhalt der elektronischen Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, deren Freigabe erforderlich ist, die Anforderung der elektronischen Identifikationsinformation von einem Entwickler einschließt.
Verfahren nach Anspruch 1, wobei der Erhalt der elektronischen Identifikations-information, die eine Gruppe von Entitäten repräsentiert, deren Freigabe erforderlich ist, die Bestimmung der Anzahl von Personen in der Entitätengruppe einschließt.
Verfahren nach Anspruch 1, wobei die Verhinderung der Implementierung des Softwareobjekts die Verhinderung des Downloads des Softwareobjekts in eine Steuerungs-umgebung einschließt.
Verfahren nach Anspruch 1, wobei die Verhinderung der Implementierung des Softwareobjekts im sicherheitsgerichteten System die Speicherung eines Ausschlussschlüssels einschließt und wobei es einem Benutzer ermöglicht wird, den Ausschlussschlüssel zu verwenden, um das Softwareobjekt in das sicherheitsgerichtete System zu laden, bevor jede Entität in der Entitätengruppe eine elektronische Angabe zur Freigabe des Softwareobjekts bereitgestellt hat.
Verfahren nach Anspruch 1, wobei weiter die Erkennung eingeschlossen ist, wann die Änderung am Softwareobjekt in der Softwareobjekt-Entwicklungsumgebung erfolgt.
Verfahren nach Anspruch 12, wobei die Erkennung, wann die Änderung am Softwareobjekt in der Softwareobjekt-Entwicklungsumgebung erfolgt, die Änderung einer dem Softwareobjekt zugeordneten Versionsnummer einschließt, wenn die Änderung am Softwareobjekt erfolgt.
Verfahren nach Anspruch 12, wobei die Erkennung, wann die Änderung am Softwareobjekt in der Softwareobjekt-Entwicklungsumgebung erfolgt, die Erkennung einschließt, wann ein neues Softwareobjekt in der Softwareobjekt-Entwicklungsumgebung angelegt wird.
Verfahren nach Anspruch 12, wobei die Erkennung, wann die Änderung am Softwareobjekt in der Softwareobjekt-Entwicklungsumgebung erfolgt, die Erkennung einschließt, wann ein Benutzer ein Freigabeverfahren in der Softwareobjekt-Entwicklungs-umgebung einleitet.
Verfahren nach Anspruch 1, wobei weiter die Überwachung eines Softwareobjekts zu Testzwecken eingeschlossen ist, um zu bestimmen, wann ein Test bezüglich des Softwareobjekts überfällig ist.
Verfahren nach Anspruch 16, wobei die Bestimmung, wann ein Test bezüglich des Softwareobjekts überfällig ist, die Berechnung eines neuen Risikoreduktionsfaktors für das Softwareobjekt, nachdem der Test bezüglich des Softwareobjekts überfällig geworden ist, sowie den Vergleich des neuen Risikoreduktionsfaktors mit dem ursprünglichen Risikoreduktionsfaktor für das Softwareobjekt einschließt.
Verfahren nach Anspruch 16, wobei weiter die Erzeugung eines an einen Benutzer zu sendenden Alarmsignals eingeschlossen ist, wenn der Test bezüglich des Softwareobjekts überfällig ist.
Verfahren nach Anspruch 16, wobei weiter die Erzeugung eines an einen Benutzer zu sendenden Arbeitsauftrags eingeschlossen ist, wenn der Test bezüglich des Software-objekts überfällig ist.
Freigabesystem für Softwareobjekte zur Verwendung in einem Prozesssteuersystem mit einem Prozessor, wobei das Freigabesystem für Softwareobjekte Folgendes umfasst: ein computerlesbares Medium; und auf dem computerlesbaren Medium gespeicherte und für die Ausführung durch den -Prozessor eingerichtete Software für folgende Aufgaben: Erhalt von elektronischer Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, deren Freigabe vor der Implementierung eines Softwareobjekts erforderlich ist, online im Prozesssteuersystem, nachdem in einer Softwareobjekt-Entwicklungsumgebung eine Änderung am Softwareobjekt vorgenommen wurde, wobei bei Erhalt der elektronischen Identifikationsinformationen, die die Gruppe von Entitäten repräsentiert, ein Sicherheitsgewährleistungs-Pegels aus einem bei Erhalt der elektronischen Identifikationsinformation bestimmten Risikoreduktionsfaktor bestimmt wird und die Entitätengruppe aufgrund des Sicherheitsgewährleistungs-Pegels ausgewählt wird; elektronische Übertragung einer Prüfanforderung zum Softwareobjekt an jede der Entitäten in der Entitätengruppe; Empfang einer elektronischen Angabe bezüglich der Freigabe oder Nichtfreigabe des Softwareobjekts von jeder Entität in der Entitätengruppe; und Verhinderung der Implementierung des Softwareobjekts im sicherheitsgerichteten System, bis jede Entität in der Entitätengruppe eine elektronische Angabe zur Freigabe des Softwareobjekts bereitstellt.
Freigabesystem für Softwareobjekte nach Anspruch 20, wobei die Software eine Anforderung elektronisch überträgt, indem eine E-Mail-Nachricht an jede Entität in der Entitätengruppe gesandt wird.
Freigabesystem für Softwareobjekte nach Anspruch 20, wobei die Software eine elektronische Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, über die Bestimmung der Anzahl von Personen in der Entitätengruppe aufgrund des Sicher-heitsgewährleistungs-Pegels erhält.
Freigabesystem für Softwareobjekte nach Anspruch 20, wobei die Software eine elektronische Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, über die Bestimmung der hierarchischen Positionen der Personen in der Entitätengruppe aufgrund des Sicherheitsgewährleistungs-Pegels erhält.
Freigabesystem für Softwareobjekte nach Anspruch 20, wobei die Software die von einer oder mehreren Entitäten in der Entitätengruppe empfangene elektronische Angabe zur Freigabe oder Nichtfreigabe des Softwareobjekts protokolliert.
Freigabesystem für Softwareobjekte nach Anspruch 20, wobei die Software eine elektronische Identifikationsinformation, die eine Gruppe von Entitäten repräsentiert, erhält, indem die elektronische Identifikationsinformation von einem Entwickler angefordert wird.
Freigabesystem für Softwareobjekte nach Anspruch 20, wobei die Software erkennt, wann die Änderung am Softwareobjekt in der Softwareobjekt-Entwicklungsumgebung erfolgt.
Freigabesystem für Softwareobjekte nach Anspruch 26, wobei die Software erkennt, wann die Änderung am Softwareobjekt in der Softwareobjekt-Entwicklungsumgebung erfolgt, indem erkannt wird, wann ein neues Softwareobjekt in der Softwareobjekt-Entwicklungsumgebung angelegt wird.
Freigabesystem für Softwareobjekte nach Anspruch 26, wobei die Software erkennt, wann die Änderung erfolgt, wenn ein Benutzer ein Freigabeverfahren in der Software-objekt-Entwicklungsumgebung einleitet.
Freigabesystem für Softwareobjekte nach Anspruch 26, wobei die Software eine dem Softwareobjekt zugeordnete Versionsnummer ändert, wenn die Software erkennt, dass die Änderung am Softwareobjekt in der Softwareobjekt-Entwicklungsumgebung erfolgt ist.
Freigabesystem für Softwareobjekte nach Anspruch 20, wobei die Software einen Ausschlussschlüssel speichert und es einem Benutzer ermöglicht, den Ausschlussschlüssel zu verwenden, um das Softwareobjekt in das Prozesssteuersystem zu laden, bevor jede Entität in der Entitätengruppe eine elektronische Angabe zur Freigabe des Softwareobjekts bereitgestellt hat.
Freigabesystem für Softwareobjekte nach Anspruch 20, wobei die Software weiter zu Testzwecken das Softwareobjekt überwacht, wenn das Softwareobjekt in das Prozesssteuersystem geladen wird, um zu bestimmen, wann ein Test bezüglich des Softwareobjekts überfällig ist.
Freigabesystem für Softwareobjekte nach Anspruch 31, wobei die Software bestimmt, wann ein Test bezüglich des Softwareobjekts überfällig ist, indem ein neuer Risikoreduktionsfaktor für das Softwareobjekt berechnet wird, nachdem der Test bezüglich des Softwareobjekts überfällig geworden ist, und der neue Risikoreduktionsfaktor mit dem ursprünglichen Risikoreduktionsfaktor für das Softwareobjekt verglichen wird.
Freigabesystem für Softwareobjekte nach Anspruch 32, wobei die Software weiter ein an einen Benutzer zu sendendes Alarmsignal erzeugt, wenn ein Test bezüglich des Softwareobjekts als überfällig ermittelt worden ist.
Freigabesystem für Softwareobjekte nach Anspruch 32, wobei die Software weiter einen an einen Benutzer zu sendenden Arbeitsauftrag erzeugt, wenn ein Test bezüglich des Softwareobjekts als überfällig ermittelt worden ist, und wobei der Arbeitsauftrag einen für das Softwareobjekt auszuführenden Test angibt.
Freigabesystem für Softwareobjekte nach Anspruch 20, wobei das Softwareobjekt ein Sicherheitssystem-Softwareobjekt ist, das zur Implementierung von Sicherheitsverfahren im Prozesssteuersystem verwendet werden soll.
Freigabesystem zur Verwendung in einem Prozesssteuersystem oder einem sicherheitsgerichteten System in einer verfahrenstechnischen Anlage mit einem oder mehreren Prozessoren, wobei das Freigabesystem Folgendes umfasst: ein computerlesbares Medium; eine auf dem computerlesbaren Medium gespeicherte erste Routine, die für die Ausführung durch den einen oder die mehreren Prozessoren zur elektronischen Übertragung einer Prüfanforderung für das Softwareobjekt an jede Entität in der Entitätengruppe als Reaktion auf eine am Softwareobjekt vorgenommene Änderung eingerichtet ist; eine zweite auf dem computerlesbaren Medium gespeicherte Routine, die für die Ausführung durch den einen oder die mehreren Prozessoren eingerichtet ist, um Implementierung des Softwareobjekts im Prozesssteuersystem oder im sicherheitsgerichteten System verhindert, bis jede Entität in der Entitätengruppe eine elektronische Angabe zur Freigabe des Softwareobjekts bereitstellt; und eine dritte auf dem computerlesbaren Medium gespeicherte Routine, die für die Ausführung durch den einen oder die mehreren Prozessoren eingerichtet ist, um eine elektronische Identifikationsinformation zu erhalten, die die Gruppe von Entitäten repräsentiert, deren Freigabe vor der Implementierung eines Softwareobjekts im Prozesssteuersystem oder im sicherheitsgerichteten System erforderlich ist, wobei die dritte Routine zum Erhalt der elektronischen Identifikationsinformation über die Bestimmung eines Sicherheitsgewährleistungs-Pegels aus einem bei Erhalt der elektronischen Identifikationsinformation bestimmten Risikoreduktionsfaktors zur Auswahl der Entitätengruppe auf der Grundlage des ermittelten Sicherheitsgewährleistungs-Pegels eingerichtet ist.
Freigabesystem nach Anspruch 36, wobei die dritte Routine zum Erhalt der elektronischen Identifikationsinformation, die die Gruppe von Entitäten repräsentiert, über die Bestimmung der Anzahl von Personen in der Entitätengruppe auf der Grundlage des Sicherheitsgewährleistungs-Pegels eingerichtet ist.
Freigabesystem nach Anspruch 36, wobei die dritte Routine zum Erhalt der elektronischen Identifikationsinformation, die die Gruppe von Entitäten repräsentiert, über die Bestimmung der hierarchischen Positionen der Personen in der Entitätengruppe auf der Grundlage des Sicherheitsgewährleistungs-Pegels eingerichtet ist.
Freigabesystem nach Anspruch 36, wobei die erste Routine zur elektronischen Übertragung einer Anforderung über den Versand einer E-Mail-Nachricht an jede Entität in der Entitätengruppe eingerichtet ist.
Freigabesystem nach Anspruch 36, wobei die zweite Routine zur Protokollierung der von einer oder mehreren Entitäten in der Entitätengruppe empfangenen elektronischen Angabe zur Freigabe oder Nichtfreigabe des Softwareobjekts eingerichtet ist.
Freigabesystem nach Anspruch 36 mit einer dritten Routine, die für die Ausführung durch den einen oder die mehreren Prozessoren eingerichtet ist, um eine elektronische Identifikationsinformation zu erhalten, die die Gruppe von Entitäten repräsentiert, deren Freigabe erforderlich ist, indem die elektronische Identifikationsinformation von einer Person angefordert wird.
Freigabesystem nach Anspruch 36, wobei die zweite Routine zur Speicherung eines Ausschlussschlüssels eingerichtet ist und wobei es einem Benutzer ermöglicht wird, den Ausschlussschlüssel zu verwenden, um das Softwareobjekt in das sicherheitsgerichtete System der Prozesssteuerung zu laden, bevor jede Entität in der Entitätengruppe eine elektronische Angabe zur Freigabe des Softwareobjekts bereitgestellt hat.
Freigabesystem nach Anspruch 36 mit einer dritten auf dem computerlesbaren Medium gespeicherten Routine, die für die Ausführung durch den einen oder die mehreren Prozessoren eingerichtet ist, um zu erkennen, wann die Änderung am Softwareobjekt vorgenommen wird.
Freigabesystem nach Anspruch 43, wobei die dritte Routine für die Änderung einer dem Softwareobjekt zugeordneten Versionsnummer eingerichtet ist, wenn die erste Routine eine Änderung am Softwareobjekt erkennt.
Freigabesystem nach Anspruch 43, wobei die dritte Routine zur Erkennung einer am Softwareobjekt vorgenommenen Änderung eingerichtet ist, wenn in einer Softwareentwicklungsumgebung ein neues Softwareobjekt angelegt wird.
Freigabesystem nach Anspruch 43, wobei die dritte Routine zur Erkennung einer am Softwareobjekt vorgenommenen Änderung eingerichtet ist, wenn ein Benutzer ein Freigabeverfahren in einer Softwareentwicklungsumgebung einleitet.
Freigabesystem nach Anspruch 36, wobei weiter eine dritte für die Ausführung durch den einen oder die mehreren Prozessoren eingerichtete Routine eingeschlossen ist, um ein online im Prozesssteuersystem oder im sicherheitsgerichteten System ausgeführtes Softwareobjekt zu Testzwecken zu überwachen, um zu bestimmen, wann ein Test bezüglich des Softwareobjekts überfällig ist.
Freigabesystem nach Anspruch 43, wobei die dritte Routine zur Bestimmung eingerichtet ist, wann ein Test bezüglich des Softwareobjekts überfällig ist, indem ein neuer Risikoreduktionsfaktor für das Softwareobjekt berechnet wird, nachdem der Test bezüglich des Softwareobjekts überfällig geworden ist, und indem der neue Risikoreduktionsfaktor mit einem ursprünglichen Risikoreduktionsfaktor für das Softwareobjekt verglichen wird.
Freigabesystem nach Anspruch 48, wobei die dritte Routine zur Erzeugung eines an einen Benutzer zu sendenden Alarmsignals eingerichtet ist, wenn der neue Risikoreduktionsfaktor vom ursprünglichen Risikoreduktionsfaktor um einen bestimmten Betrag abweicht.
Freigabesystem nach Anspruch 48, wobei die dritte Routine zur Erzeugung eines an einen Benutzer zu sendenden Arbeitsauftrags eingerichtet ist, wenn der neue Risikoreduktionsfaktor vom ursprünglichen Risikoreduktionsfaktor um einen bestimmten Betrag abweicht, und wobei der Arbeitsauftrag einen für das Softwareobjekt auszuführenden Test angibt.