Verfahren zur Protokollierung einer Vielzahl von Ereignissen in einer codierten Tracer-Variablen in einem sicherheitsge- richteten Computerprogramm

Die Erfindung betrifft ein Verfahren zur Protokollierung ei- ner Vielzahl Ereignissen in einer codierten Tracer-Variablen in einem sicherheitsgerichteten Computerprogramm gemäß dem Oberbegriff des Patentanspruchs 1, eine Einrichtung zur Durchführung des Verfahrens gemäß dem Oberbegriff des Pa- tentanspruchs 9, und ein Computerprogrammprodukt zur Durch- führung des Verfahrens gemäß dem Oberbegriff des Patentan- spruchs 10.

In sicherheitsgerichteten Programmen für industrielle Anwen- dungen, die typischerweise auf eingebetteter Hardware wie z.B. Speicherprogrammierbaren Steuerungen (SPS) oder anderen industriellen Automatisierungskomponenten ablaufen, muss si- chergestellt werden, dass Bitfehler in Variablen erkannt wer- den und dass zur Abarbeitung in einem Zyklus vorgesehene Pro- grammteile auch tatsächlich vollständig durchlaufen werden.

Bei der Verarbeitung funktional sicherer Daten müssen interne Fehler der Sicherheitsfunktion erkannt werden und eine Si- cherheitsreaktion (z.B. Ausgabe sicherer Ersatzwerte oder ei- ner Warnmeldung) zur Folge haben. Dies wird klassischerweise durch Hardware-Replikation und Ergebnisvergleich erreicht. Eine Alternative ist die Kodierung der Sicherheitsfunktion mittels arithmetischen Kodes. Einfache arithmetische Kodes erkennen nicht alle Fehler und müssen geeignet ergänzt wer- den. Dies führt typischerweise zu erheblichem Aufwand und/oder schränkt die Verwendung ein.

In fortgeschritteneren sicherheitsgerichteten Lösungen wird eine Hardware-unabhängige Variante von Coded-Processing ver- wendet. In Coded-Processing erfolgt die Erfassung und Propa- gation von Fehlerinformation in jeder Variablen. Dies führt bisher dazu, dass komplexe Anwendungen oft nicht angemessen abgebildet werden können.

Es besteht also ein Bedarf für ein Verfahren mit linearer Komplexität zur Erfassung und Propagation von Fehlern in kom- plexen Softwaresystemen für die sicherheitsgerichtete Pro- grammierung mittels arithmetischer Codes.

Beispiele für komplexe Anwendungen:

• Asynchrone Änderung von Daten (z.B. Bedienungen durch HMI - Human Machine Interface)

• Remanente Daten

• Verschachtelte Programme (IF-THEN-ELSE, LOOP, ...)

• Globale Daten

• CIR (Change in Run - Programm- oder Ablaufänderungen zur Laufzeit)

• Cloud-basierte Safety-Anwendungen

Nach dem gegenwärtigen Stand der Technik gibt es folgende Lö- sungsstrategien:

• Redundanz/Diversität: Das Sicherheitsprogramm wird mehr- fach unabhängig ausgeführt, so dass „Common Causes" (gleiche Fehlerursachen) ausgeschlossen werden können. Dieser Ansatz erfordert abhängig von der Komplexität der Anwendung einen erheblichen Aufwand für die Synchronisa- tion der Abläufe und für die sichere Erfassung der Feh- ler. • Bei „Distributed Safety" wird auf Basis des HW-Modells zu den CPUs, auf denen das Sicherheitsprogramm abläuft, die tatsächlich zu erwartende Fehlerrate abgeschätzt. Die Abschätzung und die Festlegung des Modells müssen für jede HW gesondert erfolgen.

• Dynamische Signatur für jede Variable: Jede Variable er- hält eine dynamische Signatur. Diese Signatur wird bei jeder Änderung der Variable geändert. Der Aufwand für die Verwaltung der dynamischen Signatur wächst mit der Komplexität des Anwenderprogramms. Breits bei einzelnen Anwendungen hat sich der Aufwand für die Verwaltung durch kleine Änderungen in der Kontrollstruktur verdop- pelt.

Zusammenfassend kann man sagen, dass die Lösungsansätze nach dem Stand der Technik mit der aktuell stark wachsenden Kom- plexität der Anforderungen immer weniger als alleinige Lösung für neue Innovationen geeignet sind. Sie müssen um Maßnahmen zur Beherrschung der Komplexität ergänzt werden.

Ein Problem besteht darin, dass Zustände, Zustandsänderungen, Protokollinformation (insbesondere über den Programmlauf), Fehlerinformationen oder dergleichen, im Folgenden kurz „Er- eignisse" oder „Kriterien" genannt, die synchron bzw. zeitnah zueinander auftreten, oft nicht zeitnah oder zeitgleich in einer Protokollvariablen (im Folgenden „Tracer-Variable" ge- nannt) protokolliert werden. Das liegt oft daran, dass ent- sprechende in einem Source-Code zusammenhängende Befehle in einem Computerprogramm nach dem Compilieren zeitlich getrennt voneinander ausgeführt werden können, oder dass beispielswei- se zwischenzeitlich eine Unterbrechung (Interrupt) in der Programmausführung auftritt. Dadurch können inkonsistente Zu- stände, insbesondere für die Tracer-Variable und davon abhän- gige Strukturen (insbesondere Kontrollstrukturen), auftreten. Es ist also eine Aufgabe der vorliegenden Erfindung, die Pro- tokollierung von Ereignissen in Tracer-Variablen zu verbes- sern.

Die Aufgabe wird prinzipiell dadurch gelöst, dass die Absi- cherung analog zur arithmetischen Kodierung erfolgt. Inner- halb einer Tracer-Variablen werden mehrere Ereignisse („Kri- terien") unabhängig voneinander gespeichert. Für jedes Krite- rium ist der Wert arithmetisch kodiert im „Tracer" gespei- chert, wobei erfindungsgemäß mehrere Kriterien oder Ereignis- se zunächst zusammengefasst und dann in einem Rechenschritt und somit zeitgleich in der Tracer-Variablen gespeichert wer- den.

Die Aufgabe wird insbesondere durch ein Verfahren gemäß Pa- tentanspruch 1, eine Einrichtung gemäß Patentanspruch 9 und durch ein Computerprogramm gemäß Patentanspruch 10 gelöst.

Dabei wird ein Verfahren zur Protokollierung einer Vielzahl Ereignissen in einer codierten Tracer-Variablen in einem si- cherheitsgerichteten Computerprogramm vorgeschlagen, wobei jedes Ereignis in Form eines Wertes in der codierten Tracer- Variable protokolliert wird. Dabei wird für eine gleichzeiti- ge Protokollierung mehrerer Ereignisse aus den Werten für diese Ereignisse zuerst ein Gesamtwert errechnet, der danach in der codierten Tracer-Variable protokolliert wird. Das hat den Vorteil, dass eine gleichzeitige Verarbeitung mehrerer unabhängiger Konsistenzkriterien zur Erfassung und Propagati- on von Fehlern oder anderen Ereignissen möglich ist. Durch die Gleichzeitigkeit werden viele dynamische Effekte bei der Erfassung und Propagation von Fehlern / Ereignissen vermie- den. Dies ermöglicht die notwendige Reduktion der Komplexität von Sicherheitsprogrammen.

Außerdem wird zur Lösung der Aufgabe eine Einrichtung und ei- ne Computerprogrammprodukt zur Protokollierung einer Vielzahl Ereignissen in einer codierten Tracer-Variablen in einem si- cherheitsgerichteten Computerprogramm gelöst, wobei die Ein- richtung bzw. das Computerprogrammprodukt bei seiner Ausfüh- rung zur Durchführung des o.g. Verfahrens eingerichtet sind. Damit lassen sich die anhand des Verfahrens erläuterten Vor- teile erzielen.

Vorteilhafte Varianten des erfindungsgemäßen Verfahrens sind in den abhängigen Patentansprüchen angegeben, deren Merkmale und Vorteile sinngemäß auch für die erfindungsgemäße Einrich- tung und das Computerprogrammprodukt gelten.

In einer vorteilhaften Variante Verfahren wird zur Codierung der codierten Variablen eine AN-, ANB-, oder ANBD-Codierung verwendet. Diese Codierungen sind in sicherheitsgerichteten Computerprogrammen, insbesondere in solchen der der Automati- sierungstechnik, erfolgreich eingeführt.

In einer ersten vorteilhaften Variante werden die Ereignisse als codierter Wert in der codierten Tracer-Variable protokol- liert, während in einer weiteren vorteilhaften Variante die Ereignisse in einer Signatur der codierten Tracer-Variable protokolliert werden. Mischformen sind möglich, indem bei- spielsweise erste Ereignisse in der „Payload", also als Wert, und andere Ereignisse in der Signatur protokolliert werden.

Vorteilhaft wird für jedes Ereignis eine Konstante definiert, wobei diese Konstante den Wert für das Zutreffen des Ereig- nisses darstellt. So wird beispielsweise eine Boole'sehe In- formation (true/false) auf einen breiten Bitwert abgebildet, bei dem nur genau ein Wert dem „true" entspricht, was die Si- cherheit bei Bitfehlern erhöht.

In einer vorteilhaften Ausgestaltung wird durch das Computer- programm eine Konsistenzprüfung der Tracer-Variablen durchge- führt, wobei zumindest im Falle einer Inkonsistenz eine Fehlerbehandlung durchgeführt wird. So ist eine Fehlerbehand- lung möglich. Wenn jedes Ereignis oder ein jeder Typ eines Ereignisses mit einer eigenen Konstante codiert wird, wobei die Konstanten der verschiedenen Ereignisse bzw. der verschiedenen Typen zu- einander teilerfremd gewählt werden, können mehrere Ereignis- se oder Typen von Ereignissen in einer gemeinsamen codierten Variablen, der Tracer-Variablen (oder „Fehler-Variablen") protokolliert werden.

Vorteilhaft wird mit dem Ereignis jeweils ein Erwartungswert für das Ereignis in der codierten Tracer-Variable protokol- liert. Damit können Fehler, beispielsweise Programmlauf- Fehler, allein durch Auswertung der Tracer-Variablen festge- stellt werden, ohne einen Vergleich des Inhaltes der Tracer- Variablen mit extern gespeicherten Erwartungswerten vornehmen zu müssen.

Ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens wird nachfolgend anhand der Zeichnung erläutert. Es dient gleich- zeitig zur Erläuterung eines Ausführungsbeispiels einer er- findungsgemäßen Einrichtung und eines ebensolchen Computer- programmproduktes .

Dabei zeigt die einzige Figur die Sicherung einer Addition zu einer codierten Variablen und gleichzeitig die Sicherung der Abarbeitung eines Programmabschnittes.

Zur Kontrolle eines Programmlaufes und zur Protokollierung von Ereignissen aller Art werden im Stand der Technik Laufva- riablen, sog. Tracer-Variablen oder kurz "Tracer", einge- setzt, mit deren Inhalt der durchlaufene Programmpfad oder das Eintreffen von Kriterien, Ereignissen, Zuständen oder dgl. protokolliert und somit überprüft werden kann. Im vor- liegenden Beispiel wird die Tracer-Variable Tracer _c für die Absicherung einer Addition und für das gleichzeitige Abarbei- ten eines Programmabschnittes des Computerprogramms verwen- det.

Das vorliegende Beispiel zeigt dazu die codierte Variable x _c . Im vorliegenden Beispiel ist ohne Beschränkung der Allgemein- heit die Variable x _c nach einer Vorschrift ANBD-codiert in der Form: x _c :— X _f *A + B _x + D _x codiert.

Die Komplexität des Sicherheitsprogramms ist insbesondere ab- hängig von der Absicherung gegen Fehler im dynamischen Ver- halten des Sicherheitsprogramms.

Typische Absicherungsmaßnahmen sind:

1. Dynamische Signatur D _x

2. Tracer (Tracer-Variable)

3. Propagationsvariable

Die Erfassung einer neuen Information in einer dieser Signa- turen erfolgt typisch so, dass entweder eine Konstante oder eine Variable mit eindeutiger Erwartungshaltung addiert wird. Mischformen sind möglich. Beispielsweise kann die Tracer- Variable, deren Hauptzweck klassischer Weise die Protokollie- rung der durchlaufenen linearen Programmblöcke ist, gleich- zeitig zur Propagation von Fehlerinformationen oder Zu- standsinformationen (z.B. Ereignisse oder „Kriterien") ver- wendet werden.

Für die vollständige Absicherung ist häufig die gleichzeitige Änderung mehrerer unabhängiger Aspekte nötig. Diese Gleich- zeitigkeit muss auch im kompilierten Programmcode gesichert sein, wobei man also berücksichtigen muss, dass Compiler Op- timierungen vornehmen können, die im Allgemeinen für den Pro- grammablauf vorteilhaft sind, aber andererseits nicht garan- tieren, dass Anweisungen, die im Source-Code zusammenhängend programmiert sind, im ausführbaren Programm tatsächlich zeit- nah oder quasi-zeitgleich ausgeführt werden. Hierzu wird ak- tuell für jedes Problem eine eigene Lösung gesucht.

Die Absicherung bzw. sicherheitsgerichtete Protokollierung von Ereignissen oder Kriterien (Zustandsinformationen, Zu- standsänderungen, Trace-Informationen etc.) erfolgt analog zur bekannten arithmetischen Kodierung. Innerhalb einer Tra- cer-Variablen werden mehrere Kriterien K ₁ ...K _n unabhängig ge- speichert. Für jedes Kriterium K _i ist der Wert arithmetisch kodiert in Tracer _c gespeichert.

In einer ersten Variante werden die Kriterien kodiert abge- bildet. Das bedeutet, dass die arithmetisch im codierten Raum gebildete Summe die zu protokollierenden Informationen als codierter Wert der Tracer-Variablen, also als „payload", ge- speichert werden:

Tracer _c = A ⁱ *K _i + B _Tracer + D _Tracer , _i

Die vollständige Formel für eine Anzahl i von Kriterien lau- tet:

Tracer _c = (S ⁿ i=i A ⁱ *K _i ) + B _Tracer + D _Tracer

Wie man sieht, gilt:

DTracer,i = D _Tracer + (E ^± j=l A/*Kj) + (£ ⁿ j=i+l A/*Kj)

Wenn nun gleichzeitig K± um AK± und Kj um AKj geändert werden soll, dann ergibt dies eine Änderung von

ATracer = ΔK _i * A ¹ + ΔK _j * Ai.

Im Programm wird nun

Tracer Tracer _c + ΔTracer ausgeführt. In vielen Fällen handelt es sich bei AKi und AKj um Konstanten. In diesen Fällen ist auch ATracer eine Kon- stante. Wenn ein Wert AK± mit eindeutiger Erwartungshaltung AKi ^erwartet addiert werden soll, dann erfolgt dies durch die allgemeingültige Form:

ATracer = n*ΔK _i + ΔK _i ^erwartet * (A ^a -n) + AKj + m*AKj ^erwartet * (Ai- m)

Dabei werden n und m so gewählt, dass die Fehlerinformation, die durch die Kriterien definiert wird, sicher übertragen wird. Sonst gibt es keine Einschränkungen für die Wahl von n und m.

In einer zweiten Variante bilden die Kriterien die Signatur eines kodierten Wertes, werden also vorzugsweise in der dyna- mischen Signatur der Tracer-Variablen abgebildet:

Tracer _c = A _i *X + B _i + K _i

Für jedes Kriterium wird eine Konstante E± bestimmt, die den Wert 1 für dieses Kriterium darstellt:

• E _i MOD A _i = 1

• E _i MOD A _j = 0 falls i V j

Wenn nun gleichzeitig K _i um ΔK _i und K _j um ΔK _j geändert werden soll, dann ergibt dies eine Änderung von

ΔTracer = ΔK _i * E _i + ΔK _j * E _j .

Im Programm wird nun Tracer _c = Tracer _c + ATracer ausgeführt.

In vielen Fällen handelt es sich bei ΔKi und AKj um Konstan- ten. In diesen Fällen ist auch ATracer eine Konstante. Wenn ein Wert ΔKi mit eindeutiger Erwartungshaltung AKi ^erwartet ad- diert werden soll, dann erfolgt dies durch die allgemeingül- tige Form: ΔTracer = n*AK _i + AK _i ^erwartet * (E _i -n) + ΔK _j + m*AKj ^erwartet * (E _j - m)

Dabei werden n und m wieder so gewählt, dass die Fehlerinfor- mation, die durch die Kriterien definiert wird, sicher über- tragen wird. Sonst gibt es keine Einschränkungen für die Wahl von n und m.

In beiden Varianten kann nach dem Addieren eines ATracer eine zusätzliche Korrektur erfolgen, um systematische Fehler zu vermeiden. Beispielsweise können mit modulo-Operationen Über- läufe vermieden bzw. „entfernt" werden, die durch die mehrma- lige Addition von Informationen im codierten Bereich auftre- ten können.

Welche Kriterien konkret benötigt werden, ist nicht Teil die- ser Erfindung. Diese ergeben sich aus den Sicherheitsanforde- rungen im konkreten Anwendungsfall. Typische Kriterien (oder allgemein: Ereignisse) sind:

• Der Prgrammlauf ist korrekt: Dies kann mit einem Automaten mit einem Zustand je Basicblock geprüft werden.

• Der Wertverlauf der Ablaufbedingungen muss dem tat- sächlichen Ablauf entsprechen.

• Zeitstempel bzw. dynamische Signatur für die Daten

Prüfsignatur für eine Bedienung.

Der wesentliche Vorteil liegt in der gleichzeitigen Verarbei- tung mehrerer unabhängiger Konsistenzkriterien zur Erfassung und Propagation von Fehlern. Durch die Gleichzeitigkeit wer- den viele dynamische Effekte bei der Erfassung und Propagati- on von Fehlern vermieden. Dies ermöglicht die notwendige Re- duktion der Komplexität von Sicherheitsprogrammen.

In der Figur ist der Ablauf der kodierten Operation zu

Xf := Xf+1 dargestellt, wobei im rechten Teil der Figur die eigentliche Operation und im linken Teil der Figur die Protokollierung in der Tracer-Variablen dargestellt ist.

Folgende Werte werden festgelegt:

A = 13 und R = 7;

K _A = (£D _X ) mod A = 4 und K _R = D _Tracer = 10;

ΔK _A = 5 und ΔK _R = 3

Variante Modulare Kodierung:

D _Tracer mod 7 = 10 mod 7 = 3

E _A = 14 und E _R = 78

Tracer _c = (4*78 + 3*14) mod (7*13) = 17

ΔTracer = (ΔK _A * E _A + ΔK _R * E _R ) mod A*R = (5*14 + 3*78) mod 91 = 31

Es gilt:

(Tracer _c + ATracer) mod A = (K _A + ΔK _A ) mod A = 48 mod 13 = 9

(Tracer _c + ATracer) mod R (K _R + ΔK _R ) mod R = 48 mod 7 = 6

Variante ANBD-Codiert:

Tracep Für die Erfindung sind B _Tracer und D _Programm nicht relevant und werden daher auf 0 gesetzt.

→racer _c = 4*169+10*13 = 806

E _A = 13 ² = 169 und E _R = 13 ATracer = ΔK _A * E _A + ΔK _R * E _R

= 5*169 + 3*13

= 884

Da K _R + ΔK _R > 13 muss für K _R der Überlauf behandelt werden. Es muss E _R * A = 169 abgezogen werden.

ATracer = 715!

Es gilt:

((Tracer _c + ATracer) / A ² ) mod A = (K _A + AK _A ) mod A = 9

((Tracer _c + ATracer) / A) mod A = (K _R + AK _R ) mod A = 0

In der arithmetischen (codierten) Addition von 1 zu Xf wird die Zahl 1 durch 1*A repräsentiert, so dass zu x _c 1*A (= A) und zu der bisherigen dynamischen Signatur von x _c die Signa- tur der codierten 1 (nämlich K _A ) addiert wird.

Das erste Kriterium ist also durch die korrekte Addition ge- geben, wodurch die Tracer-Variable D _Tracer um den entsprechen- den vorher für eine korrekte Addition vorgesehenen Wert AK _A = 5 ergänzt wird.

Das zweite Kriterium ist z.B. eine dynamische Signatur (D- Signatur) und dient der Prüfung der korrekten Ablaufreihen- folge. Im vorliegenden Fall wird dazu gemäß vorheriger Fest- legung (ΔK _R = 3) also die Zahl 3 zu D _Tracer addiert.

Beide Änderungen müssen jedoch arithmetisch erfolgen; d.h., dass ΔK _A = 5 und AK _R = 3 in codierter Form zur Tracer- Variablen „addiert" werden müssen.

Daraus ergeben sich:

E _A = 14 und E _R = 78

ΔTracer (5*14 + 3*78) mod (7*13) 304 mod 91 31 Durch Addition der 31 zum ursprünglichen Wert 17 der Tracer- Variablen Tracer _c werden also zeitgleich, also in einem auch durch den Compiler oder Interrupts untrennbaren Schritt beide Kriterien in der Tracer-Variablen protokolliert.

Eine Konsistenzprüfung kann dann am Programmende erfolgen; dies ist im letzten Block auf der linken Seite der Figur dar- gestellt. Eine Möglichkeit besteht darin, durch modulo- Operationen die einzelnen Bestandteile wiederzugewinnen:

• Tracer _c mod A = 9

• Tracer _c mod R = 6

Diese können dann mit Erwartungswerten vergleichen werden.

• (Tracer _c - D _Tracer ) mod R = 0

• Tracer _c MOD A = (£D _X ) MOD A

Zur Vermeidung/Beherrschung von Überläufen kann Wert vom Tra- cer z.B. durch Tracer _c := Tracer _c MOD A*R begrenzt werden.

Die sichere Berechnung von D _Tracer erfolgt nach bekannten Ver- fahren im Coded Processing. Bei der Bildung von D _Tracer gehen dabei alle ablaufrelevanten Bedingungen direkt ein.

Nach einem negativen Resultat der Konsistenzprüfung kann eine entsprechende vorprogrammierte Reaktion bzw. Fehlerbehand- luchg erfolgen. In einem einfachen Fall wird dabei das zu- grunde liegende System in einen sicheren Zustand überführt (z.B. Not-Aus) und/oder eine Warnmeldung ausgegeben.