-
Die Erfindung betrifft ein System und Verfahren zur
Verbesserung von Fehlerbeherrschungsmassnahmen insbesondere in
Automatisierungssystemen
-
Zur Reduzierung eines Risikos für Mensch oder Umwelt müssen
häufig Sicherheitsfunktionen realisiert werden, wie z. B. die
Abschaltung einer Maschine nach Drücken eines Not-Aus-
Tasters. Dafür werden zunehmend fehlersichere
Automatisierungssysteme eingesetzt. Im Allgemeinen gibt es einen
sicheren Zustand, der unmittelbar durch Abschaltung,
beispielsweise einer Maschine, erreichbar ist, d. h. eine Gefahr für
Mensch oder Umwelt kann durch eine unmittelbare Abschaltung,
beispielsweise einer Maschine, durch das fehlersichere
Automatisierungssystem sicher vermieden werden. Diese Erfindung
bezieht sich auf derartige Anwendungen. Wenn das
fehlersichere Automatisierungssystem wegen eines aufgetretenen Fehlers
die eigentliche Sicherheitsfunktion nicht mehr ausführen
kann, muss eine Fehlerreaktionsfunktion ausgeführt werden,
welche üblicherweise alle Ausgänge der Sicherheitsfunktionen
abschaltet. Im Allgemeinen ist der sichere Zustand der
Ausgänge durch den energielosen Zustand gekennzeichnet, so dass
die Ausgänge bei Abschaltung energielos werden
(deenergizeto-trip). Bei manchen Ausgängen ist der sichere Zustand
jedoch der energiereiche Zustand, so dass diese Ausgänge so
realisiert werden, dass sie sich bei "Abschaltung" umgekehrt
verhalten (energize-to-trip).
-
Bekannte fehlersichere Systeme werden u. a. in Normen
beschrieben, z. B. der IEC 61508 "Functional Safety of
Electrical/Electronic/Programmable Electronic Safety-Related
Systems". Nach IEC 61508 müssen in einem fehlersicheren
Automatisierungssystem Maßnahmen zur Fehlervermeidung und
Fehlerbeherrschung mit einer dem Safety Integrity Level
entsprechenden Wirksamkeit getroffen werden. Die in Standard-
Automatisierungs-geräten getroffenen Maßnahmen - insbesondere
zur Fehlerbeherrschung - sind i. a. nicht ausreichend. Daher
wurden spezielle fehlersichere Automatisierungssysteme
entwickelt, z. B. von HIMA, Honeywell SMS, Pilz, Siemens und
Triconex. Die an den Sicherheitsfunktionen beteiligten Komponenten
dieser Automatisierungssysteme - insbesondere die CPUs
(Central Processing Unit) - mussten fehlersicher sein. Um das
Safety Integrity Level 3 (SIL 3) nach IEC 61508 zu erreichen,
waren bisher redundante CPUs erforderlich.
-
Aus EP 1 043 641 A2 ist ein fehlersicheres
Automatisierungssystem mit einer Standard-CPU auf der sich Software,
bestehend aus Betriebssystem und Anwenderprogrammen befindet,
bekannt, bei dem das Betriebssystem der CPU unverändert oder
höchstens mit minimalen Erweiterungen verwendet werden kann,
wobei Fehlerbeherrschungsmaßnahmen in das Anwenderprogramm
integriert sind. Fehlerbeherrschungsmaßnahmen sind dabei
- 1. Sicherheitsprotokoll
- 2. Zeitliche Programmlaufkontrolle
- 3. Logische Programmlauf- und Datenflusskontrolle
- 4. Datensicherung durch Informationsredundanz
- 5. Diversitäre Verarbeitung
- 6. Selbsttests innerhalb der Prozessfehlertoleranzzeit, wobei
Befehle, die nicht diversitär realisiert werden können,
innerhalb der Prozessfehlertoleranzzeit getestet werden.
-
Außerdem müssen zur Erkennung von Mehrfachfehlern innerhalb
der Mehrfehlereintrittszeit Hintergrundtests durch das
Betriebssystem der CPU durchgeführt werden.
-
Nachteile sind:
- - Das Sicherheitskonzept bestehend aus den, in der EP 1 043 641 A2
offenbarten Fehlerbeherrschungsmaßnahmen ist
prozessorabhängig, wodurch ein Diagnostic Coverage von
mindestens 99% bei komplexen Prozessoren auf Basis einer
Failure-Mode-Effect-Analysis (FMEA) des Prozessors nicht mehr
praktikabel ist. Das gilt sowohl für den Nachweis für die
diversitären Operationen als auch für den Nachweis für die
Selbsttests nicht diversitär realisierbarer Operationen.
Um das Safety Integrity Level 3 (SIL 3) nach IEC 61508 zu
erreichen, ist dieser Nachweis jedoch erforderlich.
Bei dem in der EP 1 043 641 A2 verwendeten Prozessor kann
dieser Nachweis mit vertretbarem Aufwand geführt werden,
da der dort verwendete ASIC den Code direkt abarbeitet und
aufgund der geringen Komplexität der ASICs analysiert
werden konnte. Bei der Verwendung von anderen Standard-CPUs
kann der entsprechende Code nicht direkt ausgeführt
werden, so dass der Compiler zur Umsetzung des entsprechenden
Codes auf den Maschinencode ebenfalls analysiert werden
muss und durch die Verwendung von anderen Standard-CPUs
die Komplexität von CPU und Betriebsystem deutlich
zunimmt.
- - Zur Erkennung von Mehrfachfehlern sind hardwarenahe
Hintergrundtests erforderlich. Diese sind in Standard-CPUs
i. a. nicht oder nicht mit ausreichender Wirksamkeit
implementiert, d. h. diese müssen bei Verwendung einer Standard-
CPU extra implementiert werden.
-
Aus Form, P.: "Vital coded microprocessor principles and
application for various transit systems" in Perrin, J. P.:
Control, Computers, Communications in Transportation.
Selected Papers from the IFAC/IFIP/IFORS Symposium, Pergamon,
Oxford, UK, 1990, p. 79-84. Ist ein fehlersicheres System
bekannt, bestehend aus
- - fehlersicheren Eingangsbaugruppen, die die Eingangssignale
codieren
- - einer Standard-CPU (Coded Monoprocessor), die aus den
codierten Eingangssignalen durch codierte Operationen
codierte Zustands- und Ausgangssignale berechnet. Aus den
codierten Ausgangssignalen wird eine Signatur berechnet.
- - einem fehlersicheren Dynamic Controller, der die von der
Standard-CPU berechnete Signatur überprüft und im
Fehlerfall die Ausgangsbaugruppen abschaltet.
-
Bei der Codierung werden verschiedene Verfahren kombiniert:
- - arithmetische Codierung (Multiplikation mit Primzahl A)
- - Signaturverfahren (statische Signatur, dynamische
Signatur)
-
Bei diesem Verfahren kann der Diagnostic Coverage ohne eine
Failure-Mode-Effect-Analysis (FMEA) der CPU - insbesondere
des Prozessors - rein rechnerisch bestimmt werden durch die
Formel 1 - 1/A, mit A ist eine Primzahl.
-
Nachteile sind,
- 1. dass die codierten Operationen sehr viel Laufzeit kosten.
Daher wurde in der 2. Generation ein eigens dafür
entwickelter ASIC für die codierten Operationen eingesetzt.
- 2. dass, insbesondere durch die Signaturverfahren, die
Codegenerierung sehr aufwendig wird. Dafür wird ein eigenes
Signature Prediction Tool (OPS) eingesetzt.
-
Aufgabe der vorliegenden Erfindung ist es ein Verfahren zur
Verbesserung von Fehlerbeherrschungsmaßnahmen bei
sicherheitskritischen Funktionen in Automatisierungssytemen
anzugeben.
-
Aufgabe der vorliegenden Erfindung ist es ein
Automatisierungssystem mit verbesserten Fehlerbeherrschungsmaßnahmen
hinsichtlich sicherheitskritischen Funktionen anzugeben.
-
Bei der vorliegenden Erfindung wird das Safety Integrity
Level 3 (SIL 3) nach IEC 61508 ebenfalls mit einer einzigen,
nicht redundanten Standard-CPU erreicht. Neben speziellen
fehlersicheren Baugruppen für die Schnittstelle zum Prozess
sind keine weiteren speziellen fehlersicheren Baugruppen
erforderlich.
-
Basis der vorliegenden Erfindung ist ein
Automatisierungssystem, wie in der Patentanmeldung EP 1 043 641 A2 beschrieben,
gekennzeichnet durch:
- - die Hardware-Architektur des fehlersicheren
Automatisierungssystems,
- - die Software-Architektur der CPU und
- - die Kombination der Maßnahmen zur Fehlerbeherrschung und
Fehlervermeidung,
wobei ein neues Verfahren zur Verbesserung von
Fehlerbeherrschungsmaßnahmen eingesetzt wird, das aus einer Kombination
aus diversitärer Verarbeitung und codierter Verarbeitung
gebildet wird.
-
Nachfolgend wird zunächst die Hardware-Architektur des
fehlersicheren Automatisierungssystems und die Software-
Architektur der CPU skizziert und dann die Kombination aus
diversitärer Verarbeitung und codierter Verarbeitung
beschrieben.
-
Die Hardware-Architektur des fehlersicheren
Automatisierungssystems besteht aus:
- - wenigstens einer Standard-CPU-Baugruppe (CPU) zur
Verarbeitung von Sicherheitsfunktionen
- - wenigstens einer fehlersicheren Peripheriebaugruppen
(F-SM, speziell bei Ausgaben: F-DO-SM) zur fehlersicheren
Eingabe vom Prozess und fehlersicheren Ausgabe an den
Prozess und
- - einem oder mehreren Kommunikationskanälen
(Kommunikationsmedien und ggf. Kommunikationsbaugruppen) zur
Kommunikation zwischen der Standard-CPU-Baugruppe und der
fehlersicheren Peripheriebaugruppe und/oder zwischen den Standard-
CPU-Baugruppen.
-
Die fehlersicheren Peripheriebaugruppen sind Rechner, deren
Sicherheitsfunktion in der fehlersicheren Eingabe vom Prozess
und/oder der fehlersicheren Ausgabe an den Prozess sowie der
sicherheitsgerichteten Kommunikation mit einer oder mehreren
CPUs besteht. Ihre Fehlersicherheit wird durch bekannte
Prinzipien erreicht und ist nicht Gegenstand dieser
Erfindungsmeldung.
- - Optional verarbeiten die CPUs auch nicht
sicherheitsgerichtete Funktionen. Zur Eingabe vom Prozess und Ausgabe
an den Prozess werden auch nicht fehlersichere Standard-
Peripheriebaugruppen eingesetzt. Die nicht
Sicherheitsgerichtete Kommunikation zwischen nicht
sicherheitsgerichteten Funktionen der CPUs und nicht fehlersicheren Standard-
Peripheriebaugruppen sowie zwischen nicht
sicherheitsgerichteten Funktionen auf verschiedenen CPUs erfolgt über
dieselben oder andere Kommunikationskanäle wie oben
beschrieben.
- - Optional wird durch eine Redundanz von CPUs,
Peripheriebaugruppen und Kommunikationskanälen die Verfügbarkeit
und/oder Sicherheit erhöht.
- - Optional haben die CPUs eine Schnittstelle, über die
Software in die CPU geladen werden kann (Programmier-
Schnittstelle), z. B. eine serielle Schnittstelle oder eine
Schnittstelle für ein Speichermodul.
-
Die Software der Standard-CPU bzw. Standard-CPUs des
fehlersicheren Automatisierungssystems besteht aus Betriebssystem
und wenigstens einem Anwenderprogramm.
-
Das Anwenderprogramm besteht aus:
- - F-Anwenderprogramm zur Realisierung von
Sicherheitsfunktionen
sowie optional:
- - Standard-Anwenderprogramm zur Realisierung von nicht
sicherheitsgerichteten Funktionen
-
Das Anwenderprogramm wird mit Hilfe einer Erstellsoftware
erzeugt.
-
Fehlerbeherrschungsmaßnahmen werden in das
F-Anwenderprogramm integriert, dadurch kann das Betriebssystem der CPU
unverändert oder höchstens mit minimalen Erweiterungen
verwendet werden
-
Gegenstand der vorliegenden, offenbarten Erfindung ist ein
Verfahren zur Verbesserung von Fehlerbeherrschungsmaßnahmen,
das aus einer Kombination aus diversitärer Verarbeitung und
codierter Verarbeitung gebildet wird und im folgenden
detailliert beschrieben wird.
-
Unter diversitärer Verarbeitung wird die folgende Art der
Verarbeitung der Sicherheitsfunktionen auf der CPU
verstanden:
die betroffenen Berechnungen und/oder Operationen werden
wiederholt und/oder überprüft unter Verwendung anderer Teile der
CPU oder unter verschiedenartiger Verwendung derselben Teile
der CPU, beispielsweise durch eine andere Berechnungsmethode
der Ergebnisse die dann miteinander verglichen werden (z. B.
a × b = c; c : b = a). Eine Berechnung gilt dann als diversitär,
wenn die gegenseitige Rückwirkungsfreiheit der Teile der CPU,
die für die Berechnungen herangezogen werden, bzw. die
gegenseitige Rückwirkungsfreiheit der verschiedenartigen
Verwendung derselben Teile der CPU verifiziert ist. Zu einem
solchen Nachweis sind HW-Tests notwendig, die auf die verwendete
HW, insbesondere die verwendete Standard-CPU speziell
angepasst sein müssen, also HW-abhängig sind.
-
Durch den Vergleich diversitär ermittelter Ergebnisse werden
sowohl Fehler bei der Berechnung als auch Verfälschungen der
Daten erkannt, wenn sie sich auf das Ergebnis auswirken. Im
Allgemeinen genügt es, die Endergebnisse, die an den Prozess
ausgegeben werden, zu vergleichen. Bei starker
Informationsreduzierung können auch Zwischenergebnisse verglichen werden.
Zum Vergleich kann die komplette Information eines
Ergebnisses verwendet werden (z. B. das Ergebnis selbst oder dessen
Komplement) oder eine reduzierte Information, z. B. eine
Prüfsumme über das Ergebnis. Der Vergleich wird intern und/oder
extern durchgeführt:
Interner Vergleich
-
Der Vergleich wird von derselben Hardware wie die
diversitären Berechnungen durchgeführt, d. h. von derselben CPU. In
diesem Fall ist es schwierig, nachzuweisen, dass ein Fehler
nicht sowohl das Ergebnis des Vergleichs und das übernommene
Ergebnis der Berechnungen gefährlich verfälscht (Common-
Cause-Fehler), d. h. dass auch der Vergleich der Ergebnisse
und die Berechnung des übernommenen Ergebnisses diversitär
sein muss.
Externer Vergleich
-
Der Vergleich findet in einer anderen Hardware wie die
diversitären Berechnungen statt. Eine elegante Möglichkeit besteht
darin, den externen Vergleich durch den Empfänger der
Ergebnisse durchführen zu lassen, d. h. beispielsweise die
Peripheriegruppen. bzw. F-Anwenderprogramme auf anderen CPUs.
-
In diesem Fall werden beispielsweise die Nutzdaten des
gesendeten Sicherheitstelegramms aus den Ergebnissen gebildet, der
CRC (Cyclic Redundancy Check), also die entsprechende
Prüfsumme des Sicherheitstelegramms wird aus den diversitär
ermittelten Ergebnissen berechnet. Der Vergleich der diversitär
ermittelten Ergebnisse erfolgt dann durch die Überprüfung der
CRC-Prüfsummen durch den Empfänger.
-
Bei der codierten Verarbeitung kann und wird dagegen immer
dieselbe Vorschrift zur Codierung aller unterschiedlichen
Datentypen verwendet. Bei Verwendung einer solchen echten
Codierung muss die Rückwirkungsfreiheit der verwendeten
Komponenten nur einmal nachgewiesen werden. Ist dies geschehen,
ist damit nachgewiesen, dass durch Anwendung einer solchen
Codierung die prinzipielle Rückwirkungsfreiheit aller
betroffenen Komponenten gewährleistet ist, d. h. durch die Codierung
der Daten und/oder Operatoren liefert eine Weiterverarbeitung
der codierten Daten und/oder Operatoren diversitäre, also
unabhängige Ergebnisse zu den Ergebnissen, die durch
Weiterverarbeitung der uncodierten Daten und/oder Operatoren geliefert
werden. Dazu sind keine HW-Tests notwendig. Dadurch ist die
Anwendung der codierten Verarbeitung völlig HW-unabhängig und
damit auch unabhängig von der verwendeten Standard-CPU. Dies
gilt insbesondere auch für die Erkennung von Mehrfachfehlern,
für die bei der reinen diversitären Verarbeitung aufwendige
HW-Hintergrundtests notwendig wären.
-
Bei der vorliegenden Erfindung wird das folgende zweikanalige
Verfahren, eine Kombination aus diversitärer Verarbeitung und
codierter Verarbeitung offenbart:
In der verwendeten Standard-CPU werden alle
sicherheitsrelevanten Daten sowohl uncodiert als auch codiert diversitär,
also in verschiedenen Speicherblöcken bzw. Teilen der CPU
gespeichert.
-
Die Verarbeitung der Daten erfolgt durch Operationen mittels
Operatoren, beispielsweise durch Addition, Invertierung,
Multiplikation, etc.
-
Codierte Daten, beispielsweise xc und yc werden dabei durch
arithmetische Codierung aus uncodierten Daten, beispielsweise
xf und yf gewonnen. Das uncodierte Ergebnis zf wird aus einer
uncodierten Operation, beispielsweise Addition, mit
uncodierten Daten, beispielsweise xf und yf erhalten. Das codierte
Ergebnis zc wird aus einer codierten Operation,
beispielsweise einer Addition, einer Kombination aus Subtraktion und
Inversion, etc. mit codierten Daten beispielsweise xc und yc
erhalten. Die codierte Operation ist dabei beliebiger Natur,
kann also neben arithmetrischen Operationen auch nicht
arithmetrische Operationen umfassen.
-
Zur Vermeidung von Common-Cause-Fehlern durch Stuck-at-0
aller Bits sind Codierungsvorschriften der Form AN + B
vorteilhaft, bei der A eine beliebige Konstante, N eine beliebige
Variable, beispielsweise vom Datenyp Integer oder Boolean,
etc. und B einen beliebigen Offset darstellt.
-
Die zur Verarbeitung der uncodierten Daten verwendeten
Operationen werden vom Anwender programmiert und werden uncodiert
verwendet. Die zur Verarbeitung der codierten Daten
verwendeten Operationen werden dagegen codiert, wobei dies mittels
eines Compilers automatisch geschieht.
-
Jede Operation hat seine eigene Abbildungsvorschrift, aber es
sind verschiedene Implementierungen pro Operation denkbar,
d. h. für jede Operation können verschiedene
Abbildungsvorschriften gefunden werden. Für die Umsetzung der
Abbildungsvorschrift für Operationen ist ein spezieller Compiler oder
Codeumsetzer notwendig
-
Die hier verwendete, spezielle Variante der oben erwähnten
Codierungsvorschrift ist die folgende, nach der das codierte
Datum xc aus dem uncodiertem Datum xf berechnet wird:
xc = INV(A.xf) = -A.xf - 1. Mit A ist eine beliebige Primzahl
und INV ist der Invertierungsoperator.
-
Man spricht deshalb auch von einem invertierten AN-Code.
-
Die Verarbeitung der Daten erfolgt zweikanalig diversitär und
codiert
- - In der CPU werden einerseits die uncodierten Operationen
mit den uncodierten Daten ausgeführt.
- - In der CPU werden andererseits die codierten Operationen
mit den codierten Daten ausgeführt.
-
In einem nächsten Schritt werden die so erhaltenen
diversitären Ergebnisse CPU-intern miteinander verglichen. Dies
geschieht beispielsweise durch Vorwärtsrechnen des uncodierten
Ergebnisses zf unter Verwendung der Codiervorschrift. Ist das
so erhaltene Ergebnis identisch mit zc, ist kein Fehler
aufgetreten, das Ergebnis ist also sicher und kann
weitergeleitet werden. Ist das so erhaltene Ergebnis von zc verschieden,
ist ein Fehler aufgetreten und es wird eine Fehlerreaktion
ausgelöst. In diesem Fall wird beispielsweise die CPU
angehalten und/oder die Ausgabe der Daten an den Prozess
und/oder die angeschlossenen Peripheriegeräte werden in einen
sicheren Zustand versetzt.
-
Zusätzlich kann noch eine externe Überwachung und/oder ein
zweiter unabhängiger Abschaltweg angeschlossen werden. Dabei
wird einerseits das uncodierte Ergebnis selbst,
beispielsweise zf, das aus der uncodierten Operation mit den uncodierten
Daten, beispielsweise xf und yf erhalten wurde verwendet.
Andererseits wird das codierte Ergebnis, beispielsweise zc, das
aus der codierten Operation mit den codierten Daten,
beispielsweise xc und yc erhalten wurde, auf Basis der
verwendeten Codierungsvorschrift konvertiert, aus dem konvertierten
Ergebnis die Prüfsumme CRC gebildet und zusammen mit dem
uncodierten Ergebnis in einem Sicherheitsdatentelegramm an die
Empfänger, beispielsweise die fehlersicheren
Peripheriebaugruppen, gesendet, die aus dem Vergleich dieser beiden Daten
im Falle der Nichtübereinstimmung ebenfalls eine
Fehlerreaktion auslösen, beispielsweise die Verwendung von sicheren
Ersatzwerten anstelle der erhaltenen Daten und/oder Ausgabe
einer Fehlermeldung, etc.
Ausführungsbeispiel (s. Fig. 3)
-
Die beiden uncodierten Integer-Zahlen xf und yf sollen
addiert werden. Das Ergebnis ist zf:
zf = xf + yf
-
Die Integer-Zahlen werden durch einen invertierten AN-Code
(beispielsweise mit der Primzahl A = 31541) codiert, d. h.:
xc = INV(A.xf) = -A.xf - 1
yc = INV(A.yf) = -A.yf - 1
zc = INV(A.zf) = -A.zf - 1
-
Bei der "codierten Addition" wird zc aus xc und yc berechnet:
zc = INV(A.zf) = -A.zf - 1 = -A.(xf + yf) - 1 = xc + yc +
1
-
Vor der Ausgabe von zc an die Peripheriegruppen oder andere
CPUs über ein Sicherheitsprotokoll wird überprüft, ob das
Ergebnis zc = INV(A.zf) ist. Dabei wird für zf das Ergebnis
eingesetzt, das aus der uncodierten Addition mit den uncodierten
Integer-Zahlen xf und yf erhalten wurde.
-
Falls dies nicht der Fall ist, erfolgt als Fehlerreaktion
eine Blockade der Ausgabe und ein STOP der CPU.
-
Indem der CRC der gesendeten Sicherheitstelegramme auf Basis
der codierten Daten berechnet wird, können die Empfänger
Fehler erkennen und darauf reagieren.
-
Die offenbarte Erfindung hat folgende Vorteile:
- - Das Sicherheitskonzept ist unabhängig von der verwendeten
CPU. Weder der Prozessor noch der Compiler zur Umsetzung
des verwendeten Codes in Maschinencode müssen analysiert
werden. Der Diagnostic Coverage ist durch die
Eigenschaften des arithmetischen Codes und der codierten Operationen
bestimmbar. Dies bedeutet, dass eine kostenintensive
Portierung auf andere Systeme, insbesondere andere Standard-
CPUs überflüssig ist, wodurch ebenfalls der Wartungs- bzw.
Kompatibilitätsaufwand enorm sinkt.
- - Zur Erkennung von Mehrfachfehlern sind keine hardwarenahen
Hintergrundtests erforderlich, da durch Verwendung des
arithmetischen Code auch Mehrfachfehler erkennbar sind,
wodurch keine HW-Abhängigkeit entsteht.
- - Die Hardware-Architektur mit skalierbarer Verfügbarkeit
und Sicherheit ist flexibler, wodurch der Kostenaufwand
eingeschränkt wird, da nicht für jeden Einzelfall eine
spezielle Hardware-Architektur aufgebaut werden muss.
-
Gegenüber dem in Form, P.: "Vital coded microprocessor
principles and application for various transit systems" in
Perrin, J. P.: Control, Computers, Communications in
Transportation. Selected Papers from the IFAC/IFIP/IFORS Symposium,
Pergamon, Oxford, UK, 1990, p. 79-84 beschriebenen Coded
Monoprozessor ergeben sich folgende Vorteile:
- - Die Signaturverfahren sind u. a. wegen der Kombination mit
der diversitären Verarbeitung nicht erforderlich. Die
Erstellsoftware wird dadurch weniger aufwendig und die
Laufzeit der Erstellungssoftware als auch der Applikation wird
reduziert.
- - Die Realisierung der verwendeten Operationen ist
flexibler, beispielsweise kann eine Division einfacher gestaltet
werden, was den Implementierungs- und Berechnungsaufwand
ermöglicht bzw. verringert.
-
Im Weiteren werden bevorzugte Ausführungsbeispiele der
Erfindung mit Bezugnahme auf die Zeichnungen näher erläutert. Es
zeigen:
-
Fig. 1 Schema der Erstellung sicherer Applikationssoftware,
-
Fig. 2 Gegenüberstellung von uncodierter und codierter
Operation und
-
Fig. 3 Ausführungsbeispiel für die Kombination aus
diversitärer und codierter Verarbeitung:
Fig. 1 zeigt das Schema der Erstellung sicherer
Applikationssoftware. Dabei kann der Anwender in einem beliebigen
Programmeditor, beispielsweise mit der Sprache FUP
(Funktionsplan) oder der Sprache KOP (Kontaktplan) ohne Einschränkung
ein uncodiertes Anwenderprogramm programmieren. Bei Bedarf
kann der Anwender beispielsweise automatisch durch Ausführung
einer im Programmeditor realisierten Funktion, beispielsweise
durch Klick auf einen entsprechenden Button, das uncodierte
Anwenderprogramm in ein fehlersicheres Anwenderprogramm
umwandeln. Natürlich sind andere Ausführungsgestaltungen
möglich. Durch Ausführung dieser Funktion wandelt ein
Sicherheitscompiler unter Verwendung des offenbarten Verfahrens das
uncodierte Anwenderprogramm in ein codiertes Anwenderprogramm
um, welches danach vom Standard-Compiler in ein ausführbares
fehlersicheres Programm übersetzt und an die Standard-
Verarbeitungseinheit, beispielsweise eine Standard-CPU,
übergibt. Der Sicherheitscompiler kann dabei optional auf eine
Datenbank und/oder Bibliothek von vorgefertigten
Sicherheitsbausteinen zugreifen und diese zur Codierung des uncodierten
Anwenderprogramms verwenden.
-
Fig. 2 zeigt die Gegenüberstellung von uncodierter und
codierter Operation
-
Fig. 3 zeigt ein bevorzugtes Ausführungsbeispiel für die
Kombination aus diversitärer und codierter Verarbeitung.
-
Für eine beispielhafte Addition der Integerzahlen 127 und 1
wird zunächst die diversitäre Speicherung mit invertiertem
AN-Code gezeigt:
Dabei sind auf der linken Seite die Abfolge der uncodierten
Daten und uncodierten Operationen (Anwenderdaten,
beobachtbar)und auf der rechten Seite die Abfolge der codierten Daten
und codierten Operationen (mit der Abbildungsvorschrift xc =
INV(A.xf) mit A = 31541)dargestellt.
-
Daran anschliessend wird die diversitäre Verarbeitung auf der
linken Seite der vom Anwender programmierten uncodierten
Operationen mit den uncodierten Daten ausgeführt, während auf
der rechten Seite die vom F-Compiler ergänzten codierten
Operationen mit den codierten Daten ausgeführt wird.
-
Bei Vergleich 1 wird ein CPU-interner Vergleich der
erhaltenen Ergebnisse durchgeführt, der bei Nichtübereinstimmung zu
einer Fehlerreaktion, beispielsweise Blockierung der Ausgabe,
und Stop der CPU führt. Dabei werden die erhaltenen
diversitären Ergebnisse CPU-intern miteinander verglichen. Dies
geschieht beispielsweise durch Vorwärtsrechnen des uncodierten
Ergebnisses zf unter Verwendung der Codiervorschrift. Ist das
so erhaltene Ergebnis identisch mit zc, ist kein Fehler
aufgetreten, das Ergebnis ist also sicher und kann
weitergeleitet werden. Ist das so erhaltene Ergebnis von zc verschieden,
ist ein Fehler aufgetreten und es wird eine Fehlerreaktion
ausgelöst. In diesem Fall wird beispielsweise die CPU
angehalten und/oder die Ausgabe der Daten an den Prozess
und/oder die angeschlossenen Peripheriegeräte werden in einen
sicheren Zustand versetzt.
-
Bei Vergleich 2 erfolgt eine externe Überwachung und ein
zweiter unabhängiger Abschaltweg, der durch die Empfänger der
Sicherheitstelegramme (F-DOs, andere F-CPUs) durchgeführt
wird.
-
Dabei wird einerseits das uncodierte Ergebnis selbst,
beispielsweise zf, das aus der uncodierten Operation mit den
uncodierten Daten, beispielsweise xf und yf erhalten wurde
verwendet. Andererseits wird das codierte Ergebnis,
beispielsweise zc, das aus der codierten Operation mit den codierten
Daten, beispielsweise xc und yc erhalten wurde, auf Basis der
verwendeten Codierungsvorschrift konvertiert, aus dem
konvertierten Ergebnis die Prüfsumme CRC gebildet und zusammen mit
dem uncodierten Ergebnis in einem Sicherheitsdatentelegramm
an die Empfänger, beispielsweise die fehlersicheren
Peripheriebaugruppen, gesendet. die im Falle der
Nichtübereinstimmung ebenfalls eine Fehlerreaktion. Aus dem Vergleich dieser
beiden Daten erfolgt bei Nichtübereinstimmung auch hier eine
Fehlerreaktion, beispielsweise Ausgabe und/oder Verwendung
sicherer Ersatzwerte und/oder eine Fehlermeldung.