-
Die
vorliegende Erfindung bezieht sich auf ein Verfahren, ein Computerprogrammprodukt
und ein Computersystem für
sicherheitskritische Anwendungen in Maschinen, Geräten und/oder
Anlagen.
-
Es
sind Verfahren und Systeme zum Steuern, Regeln und/oder Überwachen
sicherheitskritischer Prozesse in Maschinen oder Anlagen bekannt. Diese
Verfahren stellen jedoch hohe Anforderungen an die benötigten Systemressourcen.
Des weiteren benötigen
die Personen, die mit der Erstellung der Verfahren bzw. Anwendungen
beschäftigt
sind, einen hohen Grad an Spezialwissen im sicherheitstechnischen
Bereich.
-
Die
Druckschrift
DE 197
45 438 A1 beschreibt ein Verfahren zur Fehlerprüfung von
echtzeitfähiger
Systemsoftware. In dem beschriebenen Verfahren werden Prüfprozesse
für eine
Systemsoftware diversitär
durchgeführt,
um Aussagen über
die Richtigkeit der Prüfergebnisse
machen zu können.
-
Die
Druckschrift
DE 196
36 443 A1 werden Vergleichsgrößen mit Hilfe physikalischer
Größen ermittelt.
Insbesondere wird ein Verfahren zur Überwachung von Sensoren beschrieben,
die unterschiedliche physikalische Größen repräsentieren. Die Verarbeitung
der diversitären
Sensorsignale erfolgt hierbei in einem Steuergerät.
-
Es
ist somit eine Aufgabe der vorliegenden Erfindung, ein einfaches
und kostengünstiges
Verfahren, ein einfaches und kostengünstiges Computerprogramm, ein
Speichermedium mit darauf gespeichertem Computerprogramm und ein
einfaches und kostengünstiges
Computersystem für
sicherheitskritische Anwendungen in Maschinen, Geräten und/oder
Anlagen bereitzustellen.
-
Dies
Aufgabe wird gemäß der Erfindung durch
ein Verfahren mit den in Anspruch 1 angegebenen Merkmalen, ein Computerprogramm
mit den in Anspruch angegebenen Merkmalen, ein Speichermedium mit
den in Anspruch angegebenen Merkmalen und ein Computersystem mit
den in Anspruch angegebenen Merkmalen gelöst. Bevorzugte Ausführungsformen
der Erfindung sind in den Unteransprüchen definiert.
-
Vozugsweise
weist die erste Verarbeitungsumgebung eine zu der zweiten Verarbeitungsumgebung
verschiedene Hardware-Struktur und/oder Laufzeitumgebung und/oder
ein zu der zweiten Verarbeitungsumgebung verschiedenes Betriebssystem auf.
-
Bevorzugt
weist die erste Verarbeitungsumgebung eine zu der zweiten Verarbeitungsumgebung verschiedene
Software-Struktur auf.
-
Vorzugsweise
ist die Laufzeitumgebung eine virtuelle Maschine, welche eine in
sich abgeschlossene Daten- bzw. Softwareverarbeitungsmaschine ist,
die einen standardisierten Befehlssatz und definierte Ressourcen
zur Verfügung
stellt, so daß die auf
ihr laufende Software unabhängig
von der aktuellen Hardware- und Betriebssystemumgebung ist.
-
Bevorzugt
erfolgt der Schritt des Aufrufens des Anwendungsprogramms in den
zumindest zwei Verarbeitungsumgebungen zeitdiversitär und/oder datendiversitär bzw. läuft zeitdiversitär und/oder
datendiversitär
ab.
-
Durch
die zeitdiversitäre
Verarbeitung, d. h. die Bearbeitung von gleichen oder ähnlichen
Algorithmen zu verschiedenen Zeitpunkten, kann eine gleichartige
Beeinflussung eines Regel- bzw. Steuer- bzw. Überwachungsvorgangs durch zeitbedingte Störer, wie
z. B. elektromagnetische Störer,
verhindert bzw. verringert werden.
-
Des
weiteren kann durch die datendiversitäre Verarbeitung, d. h. die
Bearbeitung von gleichen oder ähnlichen
Algorithmen mit verschiedenen Daten oder Datentypen, z. B. ganze
Zahlen bzw. Integer Zahlen und Gleitkomma Zahlen bzw. Flogt Zahlen, eine
gleichartige Beeinflussung des Regel- bzw. Steuer- bzw. Überwachungsvorgangs
durch Fehler der Verarbeitungsumgebung verhindert bzw. verringert
werden.
-
Das
erfindungsgemäße Verfahren
wird bevorzugt zur Automatisierung, Regelung, Steuerung und/oder Überwachung
sicherheitskritischer Prozesse bzw. Anwendungen in Maschinen, verfahrenstechnischen
Anlagen oder in der Medizintechnik eingesetzt.
-
Durch
das erfindungsgemäße Verfahren können die
Kernfunktionen, die benötigt
werden, um das Anwendungsprogramm sicher ablaufen zu lassen, abgesichert
werden.
-
Vorzugsweise
ist das Anwendungsprogramm in den zumindest zwei Verarbeitungsumgebungen
gleich. Somit muß bei
der Programmierung des Anwendungsprogramms nur ein Anwendungsprogramm
erstellt werden, welches auf allen Verarbeitungsumgebungen abgearbeitet
wird. Werden mehr als zwei Verarbeitungsumgebungen eingesetzt, ist
es ferner denkbar, daß das
Anwendungsprogramm nur für
eine bestimmte Anzahl von Verarbeitungsumgebungen gleich ist.
-
Bevorzugt
ist der für
die Verarbeitung verwendete Verarbeitungsalgorithmus in der ersten
Verarbeitungsumgebung verschieden zu dem verwendeten Verarbeitungsalgorithmus
in der zweiten Verarbeitungsumgebung. Vorzugsweise wird in der ersten Verarbeitungsumgebung
ein genauer, häufig
ausgeführter
Regelalgorithmus und in der zweiten Verarbeitungsumgebung eine ungenauerer,
seltener ausgeführter Überwachungsalgorithmus
verwendet. Jedoch kann ein beliebige Kombination der Verarbeitungsalgorithmen
eingesetzt werden.
-
In
einer bevorzugten Ausführungsform
der Erfindung umfaßt
das Verfahren ferner einen Schritt der selbsttätigen Einbindens neu angeschlossener Einheiten,
bevorzugt Dateneingabeeinheiten, Datenausgabeeinheiten und/oder
Verarbeitungsumgebungen, und/oder einen Schritt des dynamischen Änderns der
bestehenden Struktur vorhandener Einheiten. Somit kann die Struktur
bzw. Konfiguration des erfindungsgemäßen Systems ohne Eingriff einer
Bedienperson geändert
werden.
-
In
einer bevorzugten Ausführungsform
der Erfindung wird der Schritt des Aufrufens eines Anwendungsprogramms
in zumindest einer Verarbeitungsumgebung zyklisch gestartet. Hierbei
kann sichergestellt werden, daß der
Schritt des Verarbeitens zumindest einmal innerhalb eines bestimmten
Zeitraums aufgerufen bzw. angestoßen bzw. durchlaufen wird.
-
Bevorzugt
wird der Schritt des Aufrufens eines Anwendungsprogramms in zumindest
einer Verarbeitungsumgebung Ereignis-gesteuert gestartet. Somit
kann die Verarbeitung vorteilhaft auch mit Empfang neuer Daten angestoßen werden,
so daß die
neuen Daten sicherheitstechnisch zufriedenstellend verarbeitet werden
können.
-
Vorzugsweise
wird der Schritt des Aufrufens eines Anwendungsprogramms bei Überschreiten
eines Schwellwerts gestartet, wobei der Schwellwert in der ersten
Verarbeitungsumgebung bevorzugt verschieden ist zu dem Schwellwert
der zweiten Verarbeitungsumgebung. Bevorzugt ist der Schwellwert ein
Daten-bezogener Schwellwert. Somit kann gewährleistet werden, daß die Verarbeitung
angestoßen
wird, wenn sich beispielsweise die Daten des sicherheitskritischen
Prozesses in einem bestimmten Maß ändern. Des weiteren kann der
Schwellwert bevorzugt ein zeitlicher Schwellwert sein.
-
In
einer bevorzugten Ausführungsform
sind die für
die Verarbeitung verwendeten Datentypen und/oder die verwendete
Genauigkeit der Daten in der ersten Verarbeitungsumgebung verschieden
zu den verwendeten Datentypen und/oder der verwendeten Genauigkeit
der Daten in der zweiten Verarbeitungsumgebung. Bevorzugt wird diese
Art der Datendiversität
dadurch erreicht, in der ersten Verarbeitungsumgebung Daten mit
doppelter Genauigkeit bzw. Double Precision und in der zweiten Verarbeitungsumgebung
Daten mit einfacher Genauigkeit bzw. Single Precision verwendet
werden.
-
In
einer bevorzugten Ausführungsform
der vorliegenden Erfindung ist die Art der Verarbeitung in der ersten
Verarbeitungsumgebung verschieden zu der Art der Verarbeitung in
der zweiten Verarbeitungsumgebung. Vorzugsweise wird in der ersten Verarbeitungsumgebung
eine Implementierung mittels eine schnellen Hardware Floating Point
Prozessors verwendet, wohingegen in der zweiten Verarbeitungsumgebung
eine langsame Sofware Floating Point Library Implementierung eingesetzt
wird.
-
Vorzugsweise
ist die erste Verarbeitungsumgebung räumlich getrennt von der zweiten
Verarbeitungsumgebung angeordnet. Somit kann erreicht werden, daß nachteilige
externe Einflüsse
sich jeweils nur auf die Verarbeitung in einer Verarbeitungsumgebung
auswirken. Als Folge kann ein gleichzeitiges Auftreten fehlerhafter
Verarbeitungen in beiden Verarbeitungsumgebungen verhindert bzw.
verringert werden.
-
Weiter
bevorzugt führt
die erste Verarbeitungsumgebung eine Regelung bzw. Steuerung und/oder
eine Überwachung
und die zweite Verarbeitungsumgebung eine Überwachung durch. Bevorzugt
hat die zweite Verarbeitungsumgebung eine Art „Kontrollfunktion” für die erste
Verarbeitungsumgebung, d. h. die Ergebnisse der ersten Verarbeitungsumgebung
werden durch die Ergebnisse der zweiten Verarbeitungsumgebung verifiziert.
Durch diese funktionale Diversität
kann weiter das Auftreten von Fehlern verhindert bzw. verringert
werden.
-
In
einer bevorzugten Ausführungsform
umfaßt
des erfindungsgemäße Verfahren
ferner einen Schritt des Synchronisierens der Zeitgeber der zumindest
zwei Verarbeitungsumgebungen.
-
Bevorzugt
umfaßt
das erfindungsgemäße Verfahren
ferner einen Schritt des Erstellens eines Ausgabeprotokolls auf
Basis der Ergebnisse der Verarbeitungen in den zumindest zwei Verarbeitungsumgebungen.
Weiter bevorzugt werden die Ergebnisse zumindest teilweise codiert
und nachfolgend konkatteniert bzw. nacheinandergeschaltet bzw. -geknüpft, um
das Ausgabeprotokoll zu erstellen.
-
Durch
das Zusammenfügen
der Ergebnisse der zumindest zwei Verarbeitungsumgebungen zu einem
Ausgabeprotokoll kann eine funktionale Diversität erreicht werden. Dies bedeutet,
daß Ergebnisse, welche
von verschiedenen Verarbeitungsumgebungen bzw. durch verschiedene
Verarbeitung bzw. unter Verwendung unterschiedlicher (Computer-)Funktionen
erhalten wurden, verwendet werden, um die Ausgabe zu erhalten.
-
Vorzugsweise
umfaßt
das erfindungsgemäße Verfahren
ferner einen Schritt des Überprüfens den
Ausgabeprotokolls durch eine externe, bevorzugt sicherheitsgerichtete
Ausgabeeinheit. Somit kann ermittelt werden, ob die Verarbeitung
korrekt durchgeführt
wurde, oder ob Fehler aufgetreten sind.
-
In
einer bevorzugten Ausführungsform
der Erfindung umfaßt
das Verfahren ferner einen Schritt der Eingabe sicherheitsrelevanter
Daten, bevorzugt durch eine Bedienperson.
-
Vorzugsweise
umfaßt
der Schritt der gesicherten Dateneingabe die folgenden Schritte:
- – Eingeben
der Daten mittels einer Eingabeeinheit durch die Bedienperson;
- – Ausgeben
einer visuellen Darstellung der Daten;
- – Ausgeben
einer gesprochenen Darstellung der Daten;
- – Ausgeben
eines gesprochenen Komprimierungscodes der Daten;
wobei zumindest
einer der Ausgabeschritte auf der ersten Verarbeitungsumgebung erfolgt
und zumindest ein anderer Ausgabeschritt auf der zweiten Verarbeitungsumgebung
erfolgt, und
das Verfahren ferner einen Schritt der Datenquittierung
umfaßt,
wobei der Schritt der Datenquittierung die folgenden Schritte umfaßt:
- – Eingeben
des gesprochenen Komprimierungscodes mittels einer Eingabeeinheit.
-
Dadurch,
daß die
eingegebenen Daten auf verschiedene Arten ausgegeben werden und
die Bedienperson die Eingabe der Daten quittieren muß, kann
die Fehlerhäufigkeit
bei der Dateneingabe verringert werden.
-
Bevorzugt
umfaßt
das Verfahren einen Schritt der Ausgabe sicherheitsrelevanter Daten und/oder Überwachungsergebnisse
-
Weiter
bevorzugt umfaßt
das Verfahren einen Schritt der Fehlerüberprüfung, und ferner, falls ein
Fehler ermittelt wird, einen Schritt der Fehlerausgabe. Bevorzugt
wird eine Fehlerüberprüfung auf Fehler
durchgeführt,
die der Art sind, daß vorgegebene
Schwellwerte überschritten
wurden oder vorgegebene Zeiten abgelaufen sind.
-
Vorzugsweise
umfaßt
der Schritt der Ausgabe die folgenden Schritte:
- – Ausgeben
einer visuellen Daten- und/oder Fehlermeldung;
- – Ausgeben
einer akustischen Meldung; und
- – Ausgeben
eines gesprochenen Datenkomprimierungs- und/oder Fehlercodes;
wobei
zumindest einer der Ausgabeschritte auf der ersten Verarbeitungseinheit
erfolgt und zumindest ein anderer Ausgabeschritt auf der zweiten Verarbeitungseinheit
erfolgt, und
das Verfahren ferner einen Schritt der Quittierung umfaßt, wobei
der Schritt der Fehlerquittierung die folgenden Schritte umfaßt:
- – Eingeben
des gesprochenen Datenkomprimierungs- und/oder Fehlercodes mittels
einer Eingabeeinheit.
-
Alternativ
kann an Stelle des Eingebens des gesprochenen Fehlercodes, die Auswahl
eines Musters, das dem Fehlercode entspricht, verwendet werden.
-
Dadurch,
daß die
Bedienperson die Ausgabe durch Eingeben des gesprochenen Codes mittels
einer Eingabeeinheit quittieren muß, kann sichergestellt werden,
daß die
Bedienperson den richtigen Daten erfaßt bzw. wahrgenommen hat.
-
Gemäß der Erfindung
wird ferner ein Computerprogramm bereitgestellt, welches wenn auf
einem Computer geladen, geeignet ist, das Verfahren gemäß der vorliegenden
Erfindung oder gemäß einer bevorzugten
Ausführungsform
davon durchzuführen.
-
Gemäß der Erfindung
wird ferner ein Speichermedium mit einem darauf gespeicherten Computerprogramm
bereitgestellt, welches wenn auf einem Computer geladen, geeignet
ist, ein Verfahren gemäß der vorliegenden
Erfindung oder gemäß einer bevorzugten
Ausführungsform
davon durchzuführen.
-
Das
erfindungsgemäße Computersystem kann
in die zu steuernde bzw. zu regelnde bzw. zu überwachende Maschine, Gerät bzw. Anlage
integriert werden. Alternativ kann das erfindungsgemäße Computersystem
auch getrennt bzw. extern angeordnet werden.
-
Das
erfindungsgemäße Computersystem
ist bevorzugt derart ausgelegt, um ein Verfahren gemäß der Erfindung
oder einer bevorzugten Ausführungsform
davon auszuführen.
-
Weitere
Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung werden
aus der beispielhaften Beschreibung einer bevorzugten Ausführungsform
mit Bezug auf die Zeichnungen ersichtlich, in welchen zeigt:
-
1 eine
Gesamtansicht eines Computersystems gemäß einer bevorzugten Ausführungsform der
vorliegenden Erfindung;
-
2 eine
teilweise Detailansicht des in 1 gezeigten
Computersystems;
-
3A und 3B Flußdiagramme,
die den Ablauf der Verarbeitung gemäß einer bevorzugten Ausführungsform
der vorliegenden Erfindung zeigen;
-
4A und 4B Flußdiagramme,
die den Ablauf des Erstellens eines Ausgabeprotokolls gemäß einer
bevorzugten Ausführungsform
der vorliegenden Erfindung zeigen;
-
5A und 5B Flußdiagramme,
die den Ablauf des Synchronisierens der Zeitgeber gemäß einer
bevorzugten Ausführungsform
der vorliegenden Erfindung zeigen;
-
6 eine
Ansicht, die eine Alarmbearbeitung gemäß einer bevorzugten Ausführungsform
der vorliegenden Erfindung zeigt.
-
1 zeigt
eine Gesamtansicht eines Computersystems für sicherheitskritische Prozesse
bzw. Anwendungen in Maschinen oder Anlagen gemäß einer bevorzugten Ausführungsform
der vorliegenden Erfindung.
-
Das
erfindungsgemäße Computersystem wird
bevorzugt zur Automatisierung, Regelung, Steuerung und/oder Überwachung
sicherheitskritischer Prozesse bzw. Anwendungen in Maschinen, verfahrenstechnischen
Anlagen oder in der Medizintechnik eingesetzt.
-
Das
Computersystem gemäß einer
bevorzugten Ausführungsform
der vorliegenden Erfindung umfaßt
einen Rechner bzw. Personal Computer bzw. PC 10, eine Rechner-Komponente
bzw. -Bestandteil bzw. Personal Computer Komponente bzw. PCIX 12 und
sicherheitsgerichtete Eingabe- und Ausgabebaugruppen bzw. Supplier 14.
In einer bevorzugten Ausführungsform
können
andere Sicherheitssysteme 16 zusätzlich oder alternativ zu den
sicherheitsgerichteten Eingabe- und Ausgabebaugruppen 14 vorhanden
sein. Es ist ferner denkbar, daß das
erfindungsgemäße Computersystem
mehrere PCs 10 und/oder mehrere PCIXs 12 umfaßt. Zusätzlich zu den
sicherheitsgerichteten Eingabe- und Ausgabebaugruppen bzw. Suppliern 14 können weitere
Partnergeräte
vorhanden sein. Diese Partnergeräte
umfassen bevorzugt nicht-sicherheitsgerichtete Eingabe- und Ausgabebaugruppen,
Feldgeräte
für Prozessdaten,
nicht-sicherheitsgerichtete Einrichtungen und/oder weitere Computersysteme
gemäß der vorliegenden
Erfindung.
-
Der
PC 10 und PCIX 12 tauschen miteinander und mit
den sicherheitsgerichteten sowie nicht sicherheitsgerichteten Partnergeräten Daten
aus. Hierbei tauschen PC 10 und PCIX 12 über eine
beliebige bi- oder multidirektionale Datenverbindung bzw. mittels
eines beliebigen Protokolls, vorzugsweise UDP (User Datagram Protocol)
oder TCP/IP over Ethernet, Informationen aus. Der Datenaustausch
mit den Suppliern 14 erfolgt über ein beliebiges Daten- bzw. Feldbussystem 19.
Hierbei kann der Datenaustausch zwischen dem PC 10 und
den Suppliern 14 oder zwischen dem PCIX 12 und
den Suppliern 14 erfolgen. In der dargestellten Ausführungsform
besteht die physikalische Verbindung zu den anderen Partnergeräten, insbesondere
den Eingabe- und Ausgabebaugruppen 14 über den PC 10. Jedoch
kann die physikalische Verbindung auch über den PCIX 12 laufen. Der
Datenaustausch mit anderen sicherheitsgerichteten Partnergeräten kann über ein
beliebiges Sicherheitsprotokoll erfolgen.
-
Für die sicherheitsgerichtete Übertragung wird
bevorzugt ein Ressource Sicherheitsprotokoll verwendet. Hierbei
werden die Daten bevorzugt mit einem Hash-Code bzw. CRC (cyclic redundancy check)
codiert. Der Hash-Code ist eine eindeutige mathematische Summe eines
Datenpaketes, die sich mit der kleinsten Änderung des Paketinhalts ebenfalls ändert. Der
Hash-Code ist der sog. elektronische Fingerabdruck eines Datenpaketes.
Das Ressource Sicherheitsprotokoll umfaßt weiter bevorzugt einen Sequenzzähler, der
sicherstellt, daß sich
das Ressource Sicherheitsprotokoll ständig ändert, und zwar auch bei über einen
längeren
Zeitraum unveränderten
Nutzdaten.
-
Der
PC 10 umfaßt
bevorzugt eine Benutzerschnittstelle 18, welche (Multimedia-)Aus-
und Eingabeeinheiten, wie Bildschirm, Tastatur, graphisches Zeigeinstrument,
beispielsweise Maus, sowie Lautsprecher umfaßt.
-
Des
weiteren verwendet der PC 10 bevorzugt eines der Betriebssysteme
aus der WindowsTM Familie oder ein beliebiges
anderes. Anforderungen an das verwendete Betriebssystem sind vorzugsweise,
daß es über folgende
Eigenschaften verfügt:
- (1) Mechanismus zur plattformübergreifenden Programmierung,
wie beispielsweise JAVA oder .NET;
- (2) Kommunikationsfunktionen inkl. Protokolle für den Datenaustausch
mit dem PCIX 12 und Ein-/Ausgabeeinheiten 14;
- (3) ggf. Einbindung des gewählten
Feldbussystems 19.
-
Das
PCIX 12 umfaßt
vorzugsweise eine minimierte PC Hardware Plattform, sowie ein Betriebssystem,
das bevorzugt die folgenden Anforderung erfüllt:
- (1)
verschieden vom Betriebssystem des PC 10, wobei das verwendete
Betriebssystem bevorzugt ein vom Betriebssystem des PC 10 verschiedenes
Design aufweist und bevorzugt von einem Entwicklungsteam entwickelt
wurde, welches von dem Entwicklungsteam des Betriebssystems des PC 10 verschieden
ist;
- (2) einen, dem PC 10 entsprechenden Mechanismus zur
plattformübergreifenden
Programmierung, wobei die Implementierung des Mechanismus von einem verschiedenen
Entwicklungsteam erfolgen mußte;
- (3) Kommunikationsfunktionen inkl. Protokolle für den Datenaustausch
mit dem PC 10;
- (4) vorzugsweise Unterstützung
einer softwaretechnischen Sprachausgabe, beispielsweise über eine
kommerziell verfügbare Text-to-Speech(TTS)-Softwarekomponente;
- (5) ggf. Einbindung des gewählten
Feldbussystems 19.
-
In
einer bevorzugten Ausführungsform
umfaßt
das PCIX 12 nur einen sog. Boot Loader und wird vom PC 10 über die
Busverbindung mit der gesamten Software einschließlich Anwenderprogramm geladen.
Ein Boot Loader ist ein kleines in einem Festwertspeicher abgelegtes
Programm, das dazu dient, nach Initialisierung der Hardware ein
größeres Programm, üblicherweise
von einem Festplattenspeicher oder über Netzwerk nachzuladen. Die
Integrität
der geladenen Software Teile wird beispielsweise über CRC
(cyclic redundancy check) und ggf. Sicherheitsalgorithmen gewährleistet.
-
Bevorzugt
sind der PC 10 und PCIX 12 räumlich getrennt angeordnet.
-
2 zeigt
eine teilweise Detailansicht des in 1 gezeigten
Computersystems gemäß der vorliegenden
Erfindung.
-
Der
PC 10 umfaßt
bevorzugt zumindest einen Verbraucher bzw. Consumer 20,
welcher eine Anwendungs- bzw. Applikationseinheit bzw. Verarbeitungsumgebung 22 und
eine Konfigurationseinheit 24 umfaßt. Der Consumer 20 verwendet
die zugeführten
Objekte und Daten. Die Anwendungseinheit 22 führt die
Regel- bzw. Steuer- bzw. Überwachungsanwendung
bzw. -applikation aus. In der Konfigurationseinheit 24 ist
die Konfiguration der jeweiligen Anwendung bzw. Applikation hinterlegt.
-
Ferner
umfaßt
der PC 10 eine Objektverwaltungseinheit bzw. einen Object
Manager bzw. OM 26. Der Object Manager 26 beschafft
alle für
die jeweilige Anwendung nötigen
Daten und Objekte, bewertet bzw. verwirft bevorzugt redundante Objekte (sog. „Voting” von redundanten
Objekten bzw. Daten) und verwaltet Ereignisse, die sich auf die
Objekte beziehen, wie beispielsweise Fehlermeldungen. Das „Voting” wird vorteilhafterweise
verwendet, da in der Sicherheitstechnik häufig mehrere Sensoren bzw.
Supplier 14 den gleichen physikalischen Wert messen. Diese
Meßwerte
bzw. Objekte bzw. Daten müssen bewertet
werden, welche korrekt sind. Dieser Vorgang wird als „Voting” bezeichnet.
-
Objekte
umfassen bevorzugt Daten, Methoden diese Daten zu verändern, sog.
Dienste, und zugehörige
Attribute von Daten, welche von externen Supplieren 14 zugeführt werden.
Attribute der Daten sind beispielsweise die Quelle der Daten, die
Scanzeit, die Sicherheitszeit und/oder Schwellwerte. Eine einfache
Objektdefinition enthält
einen Objektnamen bzw. Tagname, erwartete bzw. benötigte Dienste bzw.
Services und die Sicherheitsrelevanz, Sicherheitseigenschaften des
Objekts und andere Eigenschaften des Objekts.
-
Der
PC 10 umfaßt
des weiteren zumindest einen Datenquellenverwalter bzw. Ressource
Handler 28. Der Ressource Handler 28 verwaltet
die Kommunikation zwischen dem Supplier 14 und dem Object
Manager 26 des PC 10.
-
Die
Funktionsweise des Object Manager 26 und Ressource Handler 28 werden
später
im Detail beschrieben.
-
Ferner
umfaßt
der PC 10 einen Quellenfinder bzw. Ressource Finder 30 und
einen Diensthändler bzw.
Service Broker 32. Der Ressource Finder 30 hört den Feldbus 19 ab
und scannt bzw. sucht nach verfügbaren
Suppliern 14. Der Service Broker 32 sucht nach
Quellen, die die benötigten
Objekte zur Verfügung
stellen, erstellt Ressource Handler 28 und informiert den
Object Manager 26 von dem Vorhandensein eines Ressource
Handlers 28. Des weiteren verwaltet bzw. erfaßt der Service
Broker 32 Ereignisse, die mit den Objekten in Verbindung
stehen, wie z. B. Verbindungsaufbau, Entfernung von Einheiten oder
Breakdown bzw. Zusammenbruch.
-
Ferner
umfaßt
der PCIX 12 ebenfalls eine Anwendungs- bzw. Applikationseinheit bzw.
Verarbeitungsumgebung 42 und eine Konfigurationseinheit 44.
Die Anwendungseinheit 42 führt die Regel- bzw. Steuer-
bzw. Überwachungsanwendung
bzw. -applikation aus. In der Konfigurationseinheit 44 ist die
Konfiguration der jeweiligen Anwendung bzw. Applikation hinterlegt.
-
Der
PCIX 12 umfaßt
ebenfalls eine Objektverwaltungseinheit bzw. einen Object Manager
(OM) 46. Der Object Manager 46 erfüllt die
selben Aufgaben wie der Object Manager 26 des PC 10.
-
Ferner
umfaßt
der PCIX 12 einen Bestätiger bzw.
Confirmer 48, der das Sicherheitsprotokoll, insbesondere
den Hash-Code, von dem und für
den Supplier verifiziert und/oder erstellt.
-
Des
weiteren umfaßt
der PCIX 12 einen Diensthändler bzw. Service Broker 50.
Der Service Broker 50 kommuniziert mit dem Service Broker 32 des
PC 10, erstellt Confirmer 48 und informiert den Object
Manager 26 von dem Vorhandensein des Confirmer 48.
Des weiteren verwaltet bzw. erfaßt der Service Broker 32 Ereignisse,
die mit den Objekten in Verbindung stehen, wie z. B. Verbindungsaufbau, Entfernung
von Einheiten oder Breakdown bzw. Zusammmenbruch.
-
Ein
PC 10 kann zu einem oder mehreren PCIX 12 Verbindung
aufnehmen. Ebenso kann ein PCIX 12 mehreren PCs 10 dienen.
Die jeweiligen Anwendungsprogramme inkl. Konfigurationen können gesichert
auf dem PC 10 oder einem nicht sicherheitsgerichteten Datei-
bzw. Fileserver liegen, und werden beim Laden in PC 10 und
PCIX 12 geprüft.
-
Die
Anwendungsprogramme im PC 10 und PCIX 12 führen die
tatsächliche
Steuerung bzw. Regelung bzw. das Überwachen durch und sind somit von
der jeweiligen Anwendung abhängig.
In der hier beschriebenen bevorzugten Ausführungsform umfaßt der PC 10 eine
Regel- bzw. Steueranwendung und eine Überwachungsanwendung, wohingegen der
PCIX 12 lediglich eine Überwachungsanwendung
ausführt.
Jedoch ist es denkbar, jede beliebige andere Konfiguration der Anwendungen
vorzusehen. Beispielsweise können
nur Überwachungsanwendungen
vorgesehen sein. Die Programmierung der Anwendungsprogramme wird
später
beschrieben.
-
Bevorzugt
sind die Anwendungsprogramme in PC 10 und PCIX 12 grundsätzlich im
wesentlichen gleich. Jedoch ist die Verarbeitung der Anwendungsprogramme
in PC 10 und PCIX 12 verschieden.
-
In
der vorliegend bevorzugten Ausführungsform
der Erfindung geschieht die Verarbeitung der Anwendungsprogramme
in PC 10 und PCIX 12 zeitdiversitär. Dies
bedeutet, daß die
Verarbeitung zu verschiedenen Zeitpunkten erfolgt. Dadurch können Beeinflussungen
der Verarbeitung durch zeitlich begrenzte Störer verringert bzw. vermeiden
werden. Hierbei kann beispielsweise die Verarbeitung im PC 10 häufiger angestoßen werden
als die Verarbeitung im PCIX 12. Dies kann bevorzugt durch
unterschiedliche Abtastzeiten und/oder Schwellwerte erreicht werden.
-
Alternativ
oder ergänzend
hierzu erfolgt die Verarbeitung datendiversitär, d. h. mit verschiedenen Daten
oder Datentypen. Beispielsweise kann die Verarbeitung im PC 10 mit
doppelter Genauigkeit bzw. double precision erfolgen wohingegen
die Verarbeitung im PCIX 12 nur mit einfacher Genauigkeit
erfolgt. Weiter bevorzugt kann die Datencodierung bzw. das Datenformat
in PC 10 und PCIX 12 unterschiedlich sein. Insbesondere
kann im PC 10 eine Gleitkomma- bzw. floating-point-Zahlendarstellung
und im PCIX 12 eine bianär-codierte Dezimalzahldarstellung bzw.
BCD-Zahlendarstellung vorgesehen sein.
-
Des
weiteren kann die Verarbeitung der Daten im PC 10 eine
bevorzugt schnelle Verarbeitung sein, wohingegen die Verarbeitung
im PCIX 12 langsamer erfolgt.
-
Des
weiteren kann die Verarbeitung an sich bzw. die Art der Verarbeitung
im PC 10 und PCIX 12 unterschiedlich sein. Bevorzugt
erfolgt die Verarbeitung im PC 10 mittels einer Implementierung
eines Hardware Floating Point Prozessors und die Verarbeitung im
PCIX 12 mit Hilfe einer Software Floating Point Bibliothek
bzw. Software Floating Point Library Implementierung.
-
Ferner
können
die Verarbeitungsalgorithmen im PC 10 und PCIX 12 verschieden
sein. Beispielsweise kann im PC 10 ein genauer, häufig ausgeführter Regel-
bzw. Steueralgorithmus und im PCIX 12 ein seltener ausgeführter Überwachungsalgorithmus vorgesehen
sein.
-
Durch
die vorstehend beschriebene diversitäre Verarbeitung kann das Auftreten
von sog. Common Cause Fehlern, d. h. ein gleichartiger Ausfall gleichartiger
Systeme vermindert bzw. verhindert werden.
-
Nachfolgend
wird bezugnehmend auf 2 der Aufbau der Verbindung
zu einem oder mehreren Suppliern 14 beschrieben. Der Aufbau
der Verbindung wird bevorzugt selbsttätig durch das System durchgeführt und
im wesentlichen ohne einen Eingriff einer Bedienperson. Hierbei
werden neu hinzugekommene bzw. neu angeschlossene Supplier 14 selbsttätig durch
das System erkannt und an das System angeschlossen bzw. die Konfiguration
des Systems wird entsprechend angepaßt.
-
Ein
Supplier 14 stellt ein oder mehrere Prozessdaten, z. B.
verschiedene Meßdaten
(z. B. Temperatur, etc.), einschließlich der zugehörigen Objekte zur
Verfügung.
Ein neu angeschlossener Supplier 14 kann sich selbsttätig beim
Ressource Finder 30 anmelden.
-
Jede
Applikation kennt durch Konfiguration die Services und Daten bzw.
Objekte, die sie von außerhalb
für ihre
erfolgreiche Abarbeitung benötigt. Wird
eine neue Applikation geladen und gestartet, so fordert der Object
Manager 26 den Service Broker 32 und dieser den
Ressource Finder 30 auf, alle notwendigen Objekte zu finden,
und eine Kommunikation zu deren Suppliern 14 aufzubauen.
Dabei prüft
der Ressource Finder 30,
- (1) welche
Objekte bzw. Ressource Handler 28 im PC 10 bereits
aktiv sind,
- (2) welche Objekte über
Service Broker anderer erreichbarer erfindungsgemäßer Computersysteme
und
- (3) welche Supplier 14 auf den angeschlossenen Feldbussen 19 verfügbar sind.
Kann ein (oder mehrere) Supplier 14 das Objekt liefern,
so sendet er seine Objektdefinition.
-
Der
Ressource Finder 30 überprüft ob die gelieferte
Objektdefinition mit der angefragten Definition übereinstimmt. Der Service Broker 32 setzt
dann für
die akzeptierten Supplier 14 die zugehörigen Ressource Handler 28 auf,
und stellt die Verbindung zwischen ihnen und dem Object Manager 26 her.
Der Ressource Handler 28 umfaßt die Routinen zur Kommunikation
mit dem Supplier 14 und innerhalb des Sicherheitssystems.
-
Nun
wird weiter mit Bezug auf 2 der Aufbau
der Verbindung zu einem oder mehreren PCIX 12 beschrieben.
-
Der
Object Manager 46 im PCIX 12 beauftragt seinen
Service Broker 50 seine geforderten Objekte bei Service
Broker(n) 32 eines oder mehrerer verfügbarer PC(s) 10 zu
finden. Hat er ein Objekt gefunden, kreiert bzw. generiert er einen
Confirmer 48. Der Confirmer 48 umfaßt die Routinen
zur sicheren Kommunikation mit dem Supplier 10, sog. Ressource Sicherheitsprotokolle,
und innerhalb des Sicherheitssystems. Das Ressource Sicherheitsprotokoll
ist bevorzugt ein industrielles Sicherheitsprotokoll, z. B. ProfiSafe,
das auf einem industriellen, nicht-sicherheitsgerichteten Kommunikationsprotokoll
aufbaut. Der Confirmer 48 prüft und erzeugt das Ressource Sicherheitsprotokoll.
-
Nachfolgend
wird der Ablauf des Verfahrens gemäß einer bevorzugten Ausführungsform
der vorliegenden Erfindung beschrieben. 3A zeigt
den Ablauf der Verarbeitung im PC 10 und 3B zeigt den
Ablauf der Verarbeitung im PCIX 12.
-
Zunächst wird
der Ablauf der Verarbeitung im PC 10 beschrieben (3A).
-
Der
Object Manager 26 des PC 10 überprüft im Schritt S10, ob für die jeweiligen
Daten („For
each data”)
die Abtast- bzw. Scanzeit abgelaufen ist („Data's Scan Time elapsed?”). Die Scanzeit ist hierbei die
Zeit, innerhalb welcher periodisch Daten abgerufen werden (später beschrieben).
Wenn die Scanzeit noch nicht abgelaufen ist („No” im Schritt S10), wird dieser
Vorgang wiederholt.
-
Wenn
die Scanzeit abgelaufen ist („Yes” im Schritt
S10), gibt der Object Manager 26 eine Anweisung an den
Ressource Handler 28 des PC 10, daß dieser
Daten holt. Dies wird im Schritt S12 („fetch data”) durchgeführt. Es
ist jedoch auch möglich,
daß im Ressource
Handler 28 Daten spontan empfangen werden im Schritt S14
(„wait
for spontaneous data”). Im
Schritt S16 empfängt
der Ressource Handler 28 neue Daten („New Data”).
-
Im
Schritt S18 werden die empfangenen Daten an den PCIX 12 geschickt.
(„send
raw data to PCIX”).
Hierbei werden die „rohen” bzw. unveränderten
bzw. unverarbeiteten Daten verschickt. Im Schritt S20 decodiert
der Ressource Handler 28 die Daten mit einem nachfolgend
beschriebenen Coder Object („decode
data with coder object (safety time limited validity)”). Im Schritt
S22 wird hierbei den decodierten Daten die Nummer des jeweiligen
PC Sicherheitszeitintervalls hinzugefügt („PC safety time interval”). Die Sicherheitszeit
bzw. Fehlertoleranzzeit eines technischen Prozesses ist die Zeitspanne,
in der ein Prozeß durch
fehlerhafte Signale beeinträchtigt
werden kann, ohne daß ein
gefährlicher
Zustand eintritt. In der vorliegend bevorzugten Ausführungsform
ist die Sicherheitszeit die maximale Zeit, die für die jeweilige Anwendung verstreichen
darf, bis eine Applikation gestartet werden muß. Vorzugsweise ist die Scanzeit höchstens
die Hälfte
der Sicherheitszeit und bevorzugt in etwa ein Zehntel der Sicherheitszeit.
-
Das
Coder Object dient im PC 10 der Prüfung und Erzeugung des Hash-
bzw. CRC-Code für das jeweilige
Sicherheitsprotokoll der Feldgeräte oder
anderer Sicherheitssysteme. Das Coder Object ist so ausgelegt, daß es dazu
die aktuellen Sicherheitszeitintervalle des PCIX 12 und
PC 10 benötigt. Das
aktuelle Sicherheitszeitintervall des PCIX 12 wird ihm
bei Generierung mitgegeben. Damit kann der PC 10 für die Dauer
eines Sicherheitszeitintervalls ohne Mitwirkung des PCIX 12,
Sicherheitsprotokolle für
die Feldgeräte
oder anderen Sicherheitssysteme erzeugen. Dies kann beispielsweise
dadurch erreicht werden, daß ein
Tabellenverfahren zur CRC Berechnung verwendet wird, und jeder Tabellenwert bei
der Generierung im PCIX 12 um das aktuelle Sicherheitszeitintervall
erhöht
wurde, so daß der
PC 10 den jeweiligen Tabellenwert um sein Sicherheitszeitintervall
erniedrigen muß.
Außerdem
kann der PCIX 12 dem Coder Object eine begrenzte Anzahl
an gültigen
Sequenzzähler-
bzw. Sequence Counter Werten mitgegeben, wie sie für bekannte
Sicherheitsprotokolle erforderlich sind.
-
Die
dekodierten Daten werden an den Object Manager 26 zurückgegeben.
Im Object Manager 26 wird im Schritt S24 die Regel- bzw.
Steuerapplikation gestartet („start
control application”).
Des weiteren wird im Schritt S26 die Sicherheitsapplikation gestartet
(„start
safety application”).
Die Zeitablaufplanung bzw. Reihenfolgeplanung bzw. das Scheduling
des Starts der beiden Applikationen kann hierbei beliebig sein.
Beispielsweise können
beide gleichzeitig gestartet werden. Des weiteren ist es auch denkbar, daß ein zeitlicher
Versatz zwischen dem Start der beiden Applikationen liegt. Ferner
ist jedes weitere komplexere Scheduling denkbar.
-
Parallel
zu dem Start der Applikationen werden im Schritt S28 Attribute für die jeweiligen
Daten ausgewählt
(„select
attributes for that data”).
-
Im
Schritt S30 wird überprüft, ob die
Sicherheitszeit der Daten abgelaufen ist („data's safety time elapsed?”). Ist
die Sicherheitszeit nicht abgelaufen („No” im Schritt S30) wird im Schritt
S32 überprüft, ob die
Daten einen Sicherheitsschwellwert überschritten haben („beyond
data's safety threshold?”). Der
Sicherheitsschwellwert ist hierbei der maximale Wert, den die Daten
erreichen dürfen,
um einen sicheren Betrieb der Anwendung zu gewährleisten. Wenn der Sicherheitsschwellwert überschritten
ist („Yes” im Schritt
S32) wird die Sicherheitsapplikation des PC 10 im Schritt
S34 gestartet, falls dies noch nicht geschehen ist („Start
Safety Application, if not yet started”). Wenn im Schritt S30 ermittelt
wurde, daß die Sicherheitszeit
abgelaufen ist („Yes” im Schritt
S30) wird direkt übergegangen
zu Schritt S34. Des weiteren wird im Schritt S36 sichergestellt,
ob die Sicherheitsapplikation im PCIX 12 laufen soll („PCIX safety application
should run?”).
-
Nun
wird bezugnehmend auf 3B die Verarbeitung PCIX 12 beschrieben.
-
Der
Confirmer 48 des PCIX 12 wartet im Schritt S40
auf neue Daten („Wait
for new data”).
Im Schritt S42 werden neue Daten gelesen („Read new data”). Dies
sind insbesondere die Daten des PC 10, welche im Schritt
S18 gesendet wurden. Die empfangenen Daten werden im Schritt S44
mit einem Coder Object dekodiert („decode data with coder object”). Hierbei
wird im Schritt S46 den Daten das jeweilige PCIX Sicherheitszeitintervall
hinzugefügt
(„PCIX safety
time interval”).
-
Im
Schritt S48 wird überprüft, ob die
Daten korrekt sind („Data
correct?”).
Hierbei wird überprüft, ob der
jeweilige Hash-Code zu den Daten paßt. Wenn die Daten nicht korrekt
sind („No” im Schritt S48),
wird im Schritt S50 überprüft, ob die
Sicherheitszeit der Daten abgelaufen ist („Data's safety time elapsed?”). Wenn
die Sicherheitszeit der Daten nicht abgelaufen ist („No” im Schritt
S50) geht der Confirmer zu Schritt S40 zurück. Ist die Sicherheitszeit
der Daten abgelaufen („Yes” im Schritt
S50), wird im Schritt S52 eine Fehlermeldung aufgegeben und das System
wird angehalten („Error & Shutdown”). Wenn die
Daten korrekt sind („Yes” im Schritt
S48) werden im Schritt S54 die Daten an den Object Manager 46 des
PCX 12 gegeben.
-
Nachfolgend
wird die Verarbeitung der Daten im Object Manager 46 beschrieben.
-
Im
Schritt S60 erhält
der Object Manager 46 neue Daten („new data”). Im Schritt S62 werden, ähnlich wie
im Schritt 28 im PC 10, Attribute für die Daten ausgewählt („Select
attributs for that data”).
Im Schritt S64 wird überprüft, ob die
Sicherheitszeit der Daten abgelaufen ist („data's safety time elapsed?”). Wenn die
Sicherheitszeit nicht abgelaufen ist („No” im Schritt S64) wird im Schritt
S66 überprüft, ob der
Sicherheitsschwellwert der Daten überschritten wurde („beyond
data's safety threshold”?). Hierbei
ist der Sicherheitsschwellwert im PCIX 12 bevorzugt verschieden
von dem Sicherheitsschwellwert im PC 10. Jedoch ist es
ebenfalls denkbar, daß die
Schwellwerte gleich sind. Wenn der Sicherheitsschwellwert der Daten überschritten
wurde („Yes” im Schritt
S66) wird im Schritt S68 die Sicherheitsapplikation gestartet („start safety
application (optionally delayed)”). Der Start der Sicherheitsapplikation
kann sofort erfolgen oder mit einer gewissen Verzögerung.
Wenn die Sicherheitszeit der Daten abgelaufen ist („Yes” im Schritt
S64) wird direkt zu Schritt S68 übergegangen.
-
Die
vorstehend beschriebene zeitdiversitäre Bearbeitung der Applikationsprogramme
in PC 10 und PCIX 12 erfordert eine Erstellung
eines Ausgabeprotokolls („eine
intelligente Synchronisation der Ausgaben”). Andernfalls würden die
Nutzdaten vom Applikationsprogramm 22 des PC 10 nicht
mit dem Hash Code und Sequenzzähler
vom Applikationsprogramm 42 bzw. Confirmer 48 des
PCIX 12 übereinstimmen.
-
Nachfolgend
wird bezugnehmend auf 4A und 4B der
Ablauf des Erstellens eines Ausgabeprotokolls gemäß einer
bevorzugten Ausführungsform
der vorliegenden Erfindung beschrieben.
-
Zunächst wird
bezugnehmend auf 4A der Ablauf im PC 10 beschrieben.
-
Im
Schritt S110 werden die Ausgabedaten der Regel- bzw. Steuerapplikation,
welche im Schritt S24 gestartet wurde, im Object Manager 26 empfangen
(„Output
data from Control Application”).
Parallel dazu werden im Schritt S112 die Ausgabedaten der Sicherheitsapplikation,
welche in im Schritt S26 oder S34 gestartet wurde, empfangen („Output
data from Safety Application”).
Im Schritt S114 wird die Angabe von Schritt S36 übernommen, ob die Sicherheitsapplikation
im PCIX 12 laufen soll oder nicht („from previous diagram”).
-
Im
Schritt S116 wird überprüft, ob die
Sicherheitsapplikation im PCIX 12 laufen sollte oder nicht („PCIX Safety
App. Should run?”).
Wenn ermittelt wurde, daß die
Sicherheitsapplikation im PCIX 12 nicht laufen sollte („No” im Schritt
S116), werden die Ausgabedaten der Sicherheitsapplikation mit dem Coder
Object im Schritt S118 im Ressource Handler 28 codiert
(„encode
with coder object (safety time limited validity)”). Hierbei wird im Schritt
S120 das PC Sicherheitszeitintervall hinzugefügt („PC safety time interval”). Im Schritt
S122 werden die codierten Daten den eigenen Daten hinzugefügt bzw.
angehängt, um
ein Sicherheitsprotokoll zu erstellen („concatanate own data to resource
safety protocol”).
Wenn im Schritt S116 ermittelt wurde, daß die Sicherheitsapplikation
im PCIX 12 hätte
laufen sollen („Yes” im Schritt
S116), werden die codierten Daten des PCIX 12 empfangen
im Schritt S124 („Receive
Ecoding”). Der
Ablauf der Codierung der Daten im PCIX 12 wird später mit Bezug
auf 4B beschrieben. Nachfolgend wird zu Schritt S122 übergegangen.
-
Nachdem
im Schritt S122 das Sicherheitsprotokoll erstellt worden ist, werden
die Ausgabedaten der Regel- bzw. Steuerapplikation dem Sicherheitsprotokoll
hinzugefügt
und das Protokoll wird im Schritt S126 zur Datenquelle zur Steuerung
bzw. Regelung dieser zurückgeschickt
(„Send
protocol to Ressource”).
-
Nun
wird bezugnehmend auf 4B der Ablauf im PCIX 12 beschrieben.
-
Im
Schritt S130 erhält
der Object Manager 46 des PCIX 12 Ausgabedaten
der Sicherheitsapplikation („output
data from safety application”).
Im Confirmer 40 des PCIX 12 wird im Schritt S132 überprüft, ob gültige Ausgabedaten
des PCIX 12 vorliegen („Valid PCIX Output Data?”). Wenn
gültige
Daten des PCIX 12 vorliegen („Yes” im Schritt S132) werden im Schritt 134 die
Daten mit dem Coder Object codiert („Encode with Coder Object & invalid PCIX
data”), wobei
das Sicherheitszeitintervall des PCIX 12 hinzugefügt wird
(Schritt S136, „PCIX
Safety Time Interval”).
Des weiteren werden im Schritt S134 die PCIX Daten ungültig gesetzt.
Im Schritt S138 werden die codierten Daten an den PC 10 geschickt
(„Send
Encoding”),
welcher diese im Schritt S124, wie oben beschrieben, empfängt.
-
Wenn
im Schritt S132 ermittelt wurde, daß die Ausgabedaten des PCX 12 nicht
gültig
sind („No” im Schritt
S132) wird im Schritt S140 überprüft, ob die Sicherheitszeit
abgelaufen ist (safety time elapsed?”). Wenn die Sicherheitszeit
abgelaufen ist („Yes” im Schritt
S140) wird im Schritt S142 eine Fehlermeldung ausgegeben und das
System wird angehalten („error
and shut down”).
Wenn im Schritt S140 ermittelt wurde, daß die Sicherheitszeit nicht
abgelaufen ist („No” im Schritt
S140) wird zu Schritt S132 zurückgekehrt.
-
Die
Speicherung von sicherheitsrelevanten Objekten oder Mengen von Objekten
erfolgt in gleicher Weise wie das zuvor beschriebene Empfangen und
Senden von Daten, wobei eine Datenbank oder ein Filesystem des PC 10 oder
einer anderen Einheit den Supplier 14 darstellt.
-
Nachfolgend
wird bezugnehmend auf 5A und 5B die
Synchronisierung der Zeitgeber bzw. Uhren im PC 10 und
PCIX 12 beschrieben.
-
Zunächst wird
die Aktualisierung und Synchronisierung der Zeitgabe im PC 10 mit
Bezug auf 5A beschrieben.
-
Im
Schritt S210 wird die interne Zeitgabe bzw. Clocktick des PC 10 empfangen.
(„clock
tick”). Dann
wird im Schritt S212 der eigene Zeitgeber bzw. Timer aktualisiert
(„update
own timer”).
Nachfolgend wird im Schritt S214 die eigene Zeit an den PCIX 12 gesendet
(„send
own time”).
Parallel dazu wird im Schritt S216 die Zeit des PCIX 12 empfangen
(„receive
PCIX timer”).
-
Im
Schritt S218 wird die Differenz der beiden Seiten des PC 10 und
des PCIX 12 gebildet und es wird überprüft, ob die Zeitdifferenz in
Ordnung ist, d. h. ob ein bestimmter Schwellwert überschritten
worden ist oder nicht („timer
difference ok?”).
Wenn im Schritt S218 ermittelt wurde, daß die Zeitdifferenz nicht in
Ordnung ist, d. h. daß ein
Schwellwert überschritten
wurde („No” im Schritt
S218), wird im Schritt S220 eine Fehlermeldung ausgegeben und das
System wird angehalten („error
and shutdown”).
-
Wenn
im Schritt S218 ermittelt wurde, daß die Zeitdifferenz in Ordnung
ist („Yes” im Schritt S218),
wird im Schritt S222 die Langzeitdifferenz der Zeiten ermittelt
(„Iongterm
difference filter”).
Hierbei ist die Langzeitdifferenz, die Differenz der Timer, die sich über einen
längeren
aufbauen kann. Die Timer können
kaum merklich auseinanderlaufen, so daß die Differenz innerhalb eines
kurzen Betrachtungszeitraums nicht außerhalb der zugelassenen Toleranz
liegt. Jedoch kann sich über
einen längeren
Zeitraum eine unzulässige
Abweichung aufbauen.
-
Dann
wird im Schritt S224 abgefragt, ob die Langzeitabweichung in Ordnung
ist („Iongterm
drift ok?”).
Wenn die Langzeitabweichung nicht in Ordnung ist („No” im Schritt
S224) wird zum Schritt S220 übergegangen.
Wenn hingegen im Schritt S224 ermittelt wurde, daß die Langzeitabweichung
in Ordnung ist („Yes” im Schritt
S224), werden im Schritt S226 die Attribute für die Daten ausgewählt („Select attributs
for each data”).
Nachfolgend wird abgefragt, ob die Sicherheitszeit der Daten abgelaufen
ist (Schritt S228, „Data's Safety Time elapsed?”). Wenn die
Sicherheitszeit der Daten nicht abgelaufen ist („No” im Schritt S228) wird zu
Schritt S226 zurückgekehrt.
Wenn die Sicherheitszeit hingegen abgelaufen ist („Yes” im Schritt
S228), wird im Schritt S230 das Coder Object von dem PCIX 12 empfangen
(„Receive
Coder Object from PCIX”)
und nachfolgend wird zu Schritt S226 zurückgekehrt.
-
Nun
wird bezugnehmend auf 5B der Zeitservice (Timer Service)
im PCIX 12 beschrieben.
-
Im
Schritt S240 wird der interne Clock Tick des PCIX 12 empfangen
(„clock
tick”).
Nachfolgend wird im Schritt S242 der eigene Zeitgeber aktualisiert („update
own timer”).
Im Schritt S244 wird die eigene Zeit an den PC 10 gesendet
(„send
own time”).
Parallel hierzu wird im Schritt S246 die Zeit des PC 10 empfangen
(„receive
PC timer”).
Im Schritt S247 wird der eigene Timer aktualisiert („Update
own Timer”).
-
Im
Schritt S248 wird nun ähnlich
dem Schritt S218 im PC 10 ermittelt, ob die Zeitdifferenz
in Ordnung ist („timer
difference ok?”).
Wenn die Zeitdifferenz nicht in Ordnung ist („No” im Schritt S248), wird im
Schritt S250 eine Fehlermeldung ausgegeben und das System wird angehalten
(„error
and shut down”). Wenn
im Schritt S248 ermittelt wird, daß die Zeitdifferenz in Ordnung
ist („Yes” im Schritt
S248) wird die Langzeitdifferenz überprüft (Schritt S252, „Iongterm difference
filter”).
Im Schritt S254 wird überprüft, ob die
Langzeitabweichung in Ordnung ist („Iongterm drift ok?”). Wenn
die Langzeitabweichung nicht in Ordnung ist („No” im Schritt S254), wird zu
Schritt S250 übergegangen.
Wenn die Langzeitabweichung in Ordnung ist („Yes” im Schritt S254), werden
im Schritt S256 die Attribute für
die Daten ausgewählt („select
attribute for each data”).
-
Im
Schritt S258 wird abgefragt, ob die Sicherheitszeit der Daten abgelaufen
ist („data's safety time elapsed?”). Ist
die Sicherheitszeit der Daten nicht abgelaufen („No” im Schritt S258), wird zu Schritt
S256 zurückgekehrt.
Wenn hingegen die Sicherheitszeit der Daten abgelaufen ist („Yes” im Schritt
S258) wird ein neues Coder Object erstellt im Schritt S260 („create
new coder object (safety time limited validity)”). Hierbei wird das Sicherheitszeitintervall
des PCIX 12 als Eingabe verwendet (Schritt S262, „PCIX safety
time interval”).
Im Schritt S264 wird das Coder Object an den PC 10 und
an den PCIX 12 geschickt („send coder object to PC and PCIX”). Nachfolgend
wird zu Schritt S256 übergegangen.
-
Die
beschriebene Vorgehensweise ermöglicht,
daß die
Sicherheitsanwendungen in PC 10 und PCIX 12 für den Zeitraum
der Gültigkeit
des Coder Object (i. a. die Dauer eines Sicherheitszeitintervalls) bevorzugt
unabhängig
laufen und Daten an die Peripherie ausgeben können.
-
Nachfolgend
wird der Ablauf der Fehlerbehandlung beschrieben mit Bezug auf 6 beschrieben.
-
Wie
zuvor beschrieben, lesen und verarbeiten PC 10 und PCIX 12 Daten
und Objekte von Suppliern 14. Die Verfahren in PC 10 und
PCIX 12 können
bei unerwünschten
Zuständen
der automatisierten bzw. überwachten
Anlage, Alarme auslösen.
Diese Zustände
werden der Bedienperson von den Object Managern 26, 46 bevorzugt
am Bildschirm des PC 10 oder mittels einer Alarmlampe 60 und über eine
akustische Ausgabe am PCIX 12, bevorzugt mittels einer
Sirene bzw. Buzzer 62 gemeldet.
-
Die
Bedienperson kann die akustische Warnung zeitbegrenzt durch eine
einfache Handlung, z. B. Knopfdruck, an der Benutzerschnittstelle 18 unterdrücken (sog.
muting). Nach dem Unterdrücken
erfolgt über
einen Lautsprecher 64 eine Sprachausgabe eines im PCIX 12 vorzugsweise
vorkonfigurierten, eindeutigen Alarmnamens und der Alarminformation, sowie
einer kurzen Signatur bzw. Fehlercodes. Der Fehlercode ist bevorzugt
ein Hash-Code, der sich aus der Art des Alarms bzw. Fehlers und
des Zeitpunkts ergibt.
-
Alternativ
kann eine Anweisung, ein bestimmtes Muster aus einer Anzahl von
Musterfeldern auf dem Bildschirm zur Alarmquittierung auszuwählen, ausgegeben
werden. Das auszuwählende
Muster sowie die anderen Musterfelder ergeben sich aus der Signatur,
die vorzugsweise aus der Alarmbedeutung, dem Alarmnamen, der Alarminformation und/oder
dem Alarmzeitpunkt abgeleitet ist. Die Sprachausgabe am PCIX 12 kann
auch durch eine, zum PC 10 diversitäre, alphanumerische oder graphische
Anzeige ersetzt werden.
-
Die
Sprachausgabe kann direkt vom PCIX 12 oder bevorzugt über den
PC 10 erfolgen. Die Quittierung des Alarms erfolgt durch
die Bedienperson über
die Eingabe des zugehörigen
Fehler- bzw. Hash-Codes an der Benutzerschnittstelle 18 des
PC 10. Der PC 10 und PCIX 12 prüfen unabhängig den Code
und setzen bei positivem Prüfungsergebnis
die akustische Alarmierung zurück.
Durch das Rücklesen
des alarmspezifischen Hash-Codes wird geprüft, daß die Bedienperson bewußt den richtigen
Alarm quittiert hat, während
er sich an der Benutzerschnittstelle 18 befand. Dadurch
wird sichergestellt, daß die Bedienperson
den korrekten Fehler zur Kenntnis genommen hat.
-
Des
weiteren kann die Bedienperson Alarmgrenzen an der Benutzerschnittstelle 18 ändern. Die Object
Manager 26, 46 übernehmen den vom Anwender über die
Benutzerschnittstelle 18 eingegebenen neuen Grenzwert.
Der PC 10 stellt den neuen Wert bevorzugt mit Farbumschlag
am Bildschirm der Benutzerschnittstelle 18 dar. PCIX 12 löst eine Sprachausgabe
des vorkonfigurierten Alarmnamens und des neuen Alarmgrenzwertes
zusammen mit dem oben beschriebenen Fehler- bzw. Hash-Code aus.
Die Eingabequittierung erfolgt wiederum über Eingabe des Codes nach
Kontrolle der angezeigten und gesprochenen Alarminformation.
-
Wie
zuvor beschrieben, lesen und verarbeiten PC 10 und PCIX 12 Objekte
von Object Suppliern 14. Die Object Manager 26, 24 bzw.
die Anwenderprogramme 24, 44 in PC 10 und
PCIX 12 können
diese Daten dem Benutzer zur Kenntnis bringen. Der Object Manager
auf dem PC 10 löst
eine graphische Darstellung am Bildschirm der Benutzerschnittstelle 18.
Klickt der Benutzer mit der Maus auf den Prozesswert, löst PCIX 12 unabhängig eine
Sprachausgabe des vorkonfigurierten, eindeutigen Datennamens und
des aktuellen Datenwertes aus.
-
Ferner
kann die Bedienperson sicherheitsrelevante Datenwerte an der Benutzerschnittstelle 18 ändern. Die
Object Manager 26, 46 übernehmen den vom Anwender über die
Benutzerschnittstelle 18 eingegebenen neuen Datenwert.
Der PC 10 stellt den neuen Wert mit Farbumschlag am Bildschirm
der Benutzerschnittstelle 18 dar. PCIX 12 löst eine
Sprachausgabe des vorkonfigurierten Objektnamens und des neuen Datenwertes
zusammen mit dem oben beschriebenen Hash-Code aus. Die Eingabequittierung
erfolgt wiederum über
Eingabe des Codes nach Kontrolle der angezeigten und gesprochenen
Objektinformation.
-
In
gleicher Weise wie die Bedienperson sicherheitsrelevante Datenwerte ändern kann,
kann sie auch Abschaltgrenzen (vorübergehend) außer Kraft
setzen (sog. Override).
-
Nachfolgend
wird eine beispielsweise Programmierung der Anwendungs- bzw. Applikationsprogramme
auf dem erfindungsgemäßen Computersystem
beschrieben.
-
Die
sicherheitsrelevante Programmierung des PC 10 durch den
Anwender erfolgt über
den plattformübergreifenden
Programmiermechanismus. Der Mechanismus umfaßt bevorzugt sowohl den Codegenerator
und die Bibliotheken für
das Anwenderprogramm als auch eine Laufzeitumgebung für die jeweilige
Hardware und Betriebssystemplattform. Eine derartige Laufzeitumgebung
wird auch Virtual Machine, Execution Engine oder Managed Execution
Environment genannt.
-
Der
Anwender kann im PCIX 12 das gleiche, sicherheitsrelevante
Anwenderprogramm auf der Basis des plattformübergreifenden Programmiermechanismus
verwenden, der erhöhte
Sicherheit verglichen mit üblichen
Programmiersprachen wie C und C++ gewährleistet.
-
Das
Anwendungsprogramm kann auf dem erfindungsgemäßen Computersystem selber oder auf
einem getrennten Engineering System erstellt werden. Das Anwendungsprogramm
in PC 10 und PCIX 12 ist bevorzugt grundsätzlich im
wesentlichen gleich. Die Unterschiede von PC 10 und PCIX 12 werden
für den
Anwendungsprogrammierer durch die Sicherheitsbibliothek bzw. Safety
Library verdeckt. Die Sicherheit der Anwenderprogrammierung wird
durch ein Test Framework sowie durch die Verwendung von Programmiermechanismen,
wie JAVA und .NET unterstützt.
-
Die Übersetzung
der Anwendungsprogramme erfolgt in zwei diversitären Entwicklungssystemen (z.
B. mittels unterschiedlicher Compiler). Dies umfaßt auch
die diversitäre
Implementierung der von den Codegeneratoren und den Laufzeitumgebungen genutzten
Software Bibliotheken.
-
Nach
der Übersetzung
im Entwicklungssystem wird der resultierende Code gesichert, beispielsweise
durch CRC, und in den Ablaufbereich des PC 10 geladen.
Der PC 10 sendet den Code an die PCIX 12. Diese
prüft die
Integrität
des Codes anhand des Sicherungscodes. Die Codegenerierung kann durch PC 10 und
PCIX 12 getrennt und diversitär (z. B. mittels unterschiedlicher
Compiler) in den ausführbaren bzw.
Executable Code erfolgen. Alternativ zur Compilierung können PC 10 und
PCIX 12 ihre Programme getrennt und diversitär interpretieren.
Der Executable Code oder Teile davon werden in den Speicher geladen.
Der PC 10 gibt am Bildschirm eine während der Entwicklung hinterlegte
eindeutige Kennung (Programmnamen, Revision) am Bildschirm aus.
PCIX 12 gibt einen Hash-Code abgeleitet aus Programmkennung
und Sicherungscodes über
die Sprachausgabe aus. Der Anwendungsprogrammierer muss die angezeigte
Kennung prüfen
und den gesprochenen Hash-Code zur Quittierung wieder eingeben.
PC 10 und PCIX 12 prüfen die zurückgegebenen Code.
-
Die
Sicherheit der Anwenderprogrammierung wird durch ein Test Framework
insbesondere für die
Sicherheitsfunktionen der Anwendung entscheidend erhöht. Während der
Anwendungsentwicklungstests protokolliert das Test Framework automatisch
die Test- und Ergebnisvektoren.
-
Eine
Teilmenge der während
der Entwicklung des Sicherheitsanwendungsprogramms definierten Tests
wird bevorzugt auch während
des Betriebs ausgeführt
(Online Test). Dies hilft zum einen die Hardware Plattform zu prüfen, und
zum anderen die korrekte Funktion der Laufzeitumgebung sowie wichtiger
Funktionen der Bibliotheken und die Codegenerierung zu prüfen. Damit
können
die Anforderungen an den Nachweis der diversitären Implementierung der Third-Party
Hardwarekomponenten sowie Softwarekomponenten wie Betriebssysteme,
Virtual Machines und Bibliotheken niedrig gehalten werden.
-
Die
Online Tests werden von PC 10 und PCIX 12 während des
Betriebs durch Teststimuli bevorzugt gegenseitig angestoßen und
deren Ergebnisse gegenseitig überprüft und mit
den Erwartungswerten aus den Tests während der Entwicklung verglichen
-
Eine
Teilmenge der während
der Entwicklung des Sicherheitsanwendungsprogramms definierten Tests
des Safety Test Frameworks wird während des Betriebs (Online)
ausgeführt.
Die Online Tests werden von PC 10 und PCIX 12 durch
Teststimuli gegenseitig angestoßen
und deren Ergebnisse gegenseitig überprüft und mit den Erwartungswerten aus
den Test während
der Entwicklung verglichen.
-
- 10
- PC
- 12
- PCIX
- 14
- Eingabe-/Ausgabebaugruppen
- 16
- andere
Sicherheitssysteme
- 18
- Benutzerschnittelle
- 19
- Feldbus
- 20
- Consumer
- 22
- Applikationseinheit
- 24
- Konfigurationseinheit
- 26
- Object
Manager
- 28
- Ressource
Handler
- 30
- Ressource
Finder
- 32
- Service
Broker
- 40
- Consumer
- 42
- Applikationseinheit
- 44
- Konfigurationseinheit
- 46
- Object
Manager
- 48
- Confirmer
- 50
- Service
Broker
- 60
- Alarmlampe
- 62
- Sirene
- 64
- Lautsprecher