Es ist somit eine Aufgabe der vorliegenden Erfindung,
ein einfaches und kostengünstiges
Verfahren, ein einfaches und kostengünstiges Computerprogrammprodukt,
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 Computerprogrammprodukt
mit den in Anspruch 22 angegebenen Merkmalen, ein Computerprogramm
mit den in Anspruch 23 angegebenen Merkmalen, ein Speichermedium
mit den in Anspruch 24 angegebenen Merkmalen und ein Computersystem
mit den in Anspruch 25 angegebenen Merkmalen gelöst. Bevorzugte Ausführungsformen der
Erfindung sind Gemäß der Erfindung
wird ein Verfahren für
sicherheitskritische Prozesse bzw. Anwendungen in Maschinen, Geräten und/oder
Anlagen bereitgestellt, welches die folgenden Schritte umfaßt:
- – Empfangen
von Daten dem sicherheitskritischen Prozeß;
- – Aufrufen
eines Anwendungsprogramms zum Verarbeiten der empfangenen Daten
in zumindest zwei Verarbeitungsumgebungen;
- – Ausgeben
der verarbeiteten Daten;
wobei die zumindest zwei Verarbeitungsumgebungen
(22, 42) einen zeitdiversitären und/oder datendiversitären Aufruf
und/oder Ablauf eines Anwendungsprogramms ermöglichen.
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. Flouat
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.
In einer weiteren bevorzugten Ausführungsform
der vorliegenden Erfindung weist die erste Verarbeitungsumgebung
eine zu der zweiten Verarbeitungsumgebung verschiedene Hardware-Struktur und/oder
Software-Struktur auf.
Bevorzugt weist die erste Verarbeitungsumgebung
eine zu der zweiten Verarbeitungsumgebung verschiedene Laufzeitumgebung
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.
Weiter bevorzugt weist die erste
Verarbeitungsumgebung ein zu der zweiten Verarbeitungsumgebung verschiedenes
Betriebssystem auf.
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 ein 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 veringert werden.
Bevorzugt umfaßt das Verfahren einen Schritt
der Ausgabe sicherheitsrelevanter Dateb und/oder Überwachungsergebnisse.
Weiter bevorzugt umfaßt das Verfaahren
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 abgelaaufen 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 Endung wird ferner ein
Computerprogrammprodukt für
sicherheitskritische Prozesse bzw. Anwendungen in Maschinen, Geräten und/oder
Anlagen bereitgestellt, welches Programmteile zur Durchführung des
vorstehend beschriebenen Verfahrens aufweist.
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.
Gemäß der Erfindung wird ferner
ein Computersystem fürsicherheitskritische
Prozesse bzw. Anwendungen in Maschinen, Geräten und/oder Anlagen, bevorzugt
nach dem Verfahren gemäß der Erfindung
oder einer bevorzugten Ausführungsform
hiervon, bereitgestellt, welches umfaßt
- – eine Empfangseinrichtung
zum Empfangen von Daten der sicherheitskritischen Anwendung, –
- – zumindest
zwei Verarbeitungsumgebungen zum Verarbeiten der empfangenen Daten,
und
- – eine
Ausgabeeinrichtung zum Ausgeben der verarbeiteten Daten,
wobei
die zumindest zwei Verarbeitungsumgebungen einen zeitdiversitären und/oder
datendiversitären
Aufruf und/oder Ablauf eines Anwendungsprogramms ermöglichen.
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 Endung 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 klienes 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. Zusammenbruch.
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 22, 42 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. floatingpoint-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 Handle 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
Objekte liefern, so sendde 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
Handlex 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 Saftey 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
PCX12 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 PCX12 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
Figs. 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 akualisiert („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
(„longterm
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 („longterm 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 timen"). 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, „longterm difference
filter"). Im Schritt
S254 wird überprüft, ob die
Langzeitabweichung in Ordnung ist („longterm 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.