Forschung und Lehre Safely Embedded Software im Auto

Autor / Redakteur: Prof. Dr. Jürgen Mottok* / Martina Hafner

Im Auto werden mit mechatronischen Komponenten und/oder elektronischen Steuergeräten Fail-safe und Fault-tolerante Architekturen mit Hardware-Redundanzen realisiert. In Kontrast zu diesem bisherigen Ansatz wird im Absicherungsverfahren Safely Embedded Software Safety durch einen diversitären Softwarekanal erzielt. Dieser wird durch spezifisch codierte Software mit dem Framework Safely Embedded Software realisiert.

Firmen zum Thema

Die non-funktionale Anforderung Safety spielt eine zunehmende Rolle in der Automobil Industrie und insbesondere bei den Embedded-Systemen. Zwei Safety-Kategorien lassen sich unterscheiden: Das Ziel der aktiven Sicherheit ist die Unfallvermeidung. Typische Beispiele sind Electronic Stability Control (ESC), Lane Departure Warning System (LDWS), Adaptive Cruise Control (ACC) und das Anti-lock Braking System (ABS). Wenn ein Unfall nicht mehr vermieden werden kann, werden in Systemen der passiven Sicherheit geeignete Reaktionen eingeleitet. Beispiele sind hier front, side, curtain, and knee airbag Funktionen, die das Unfallrisiko deutlich reduzieren.

Typischerweise werden die Safety-Funktionen in einem Steuergerät/Electronic Control Unit (ECU) implementiert. Im Unterschied zu nicht-sicherheitsrelevanten Funktionen erfordern die sicherheitsrelevanten Funktionen zusätzliche Maßnahmen, wie zum Beispiel codierte Verarbeitung [1] auf einer ECU. Der Industrie Safety Standard IEC 61508 [1] wird für Safety Funktionen in der Automobiltechnik angewandt. Zukünftig wird der Automotive Safety Standard ISO/WD 26262 verfügbar sein.

Bildergalerie
Bildergalerie mit 6 Bildern

In diesem Artikel wird das Absicherungsverfahren Safely Embedded Software dargestellt. Die dieser Absicherung zugrunde liegende Idee wird Vital Coded Monoprocessor genannt. Am „Laboratory for safe and secure systems“ (LaS3) der Hochschule Regensburg wurde das Absicherungsverfahren Safely Embedded Software zusammen mit der TU München für die Programmiersprache C entwickelt. Es ermöglicht durch Implementierung eines diversen redundanten Softwarekanals auf Hardware-Redundanz zu verzichten bzw. diese zu reduzieren. Damit kann eine höhere Flexibiltät in der Gestaltung software-intensiver Automobil-Embedded-Systeme erreicht werden.

Der Vital Coded Processor [2] wurde 1988 veröffentlicht und war darauf ausgerichtet bestimmte Daten (vital data) und Operatoren auf nicht-redundanter Hardware und Software zu verarbeiten. Das Verfahren findet Anwendung bei der Pariser U-Bahn Linie A.

Der ED4I-Ansatz [3] gehört, zur Kategorie der AN-Code basierten Verfahren. Die Fehlerüberwachung gelingt durch diverse Daten und einen einen zweiten Berechnungskanal in der Hochsprache C. Die Codierungstechniken MASK, SWIFT-R und TRUMP werden in Assemblersprache in [7,8] diskutiert. Zufällige Fehler den Programmfluss betreffend können mit Techniken der Programmflussüberwachung [4] aufgedeckt werden.

Konzept des Safely Embedded Software

Die sicherheitskritische Funktion benötigt eine Sicherung der Daten und der Operationen. Es ist so möglich, zufällige Fehler sicher zu erkennen und geeignete Gegenmaßnahmen einzuleiten und somit die funktionale Sicherheit des Systems zu garantieren. Das Konzept geht davon aus, dass die sicherheitskritischen und -relevanten Funktionen korrekt erstellt wurden, und nur noch zufällige Fehler wie beispielsweise Bitfehler zu einer gefährlichen Fehlreaktion des Steuergerätes (ECU) führen können. Die dieser Absicherung zugrunde liegende Idee wird Vital Coded Monoprocessor oder Coded Processing genannt.

Safely Embedded Software (SES) realisiert Diversität der Daten mit einem AN+B-Code. Das Verfahren benutzt die Transformationsvorschrift xc := xf * A + Bx + D des Vital Coded Monoprocessors, wobei die Variable xf des Originalraumes in die entsprechende Variable xc des Bildraumes unter Benutzung einer statischen Signatur Bx für jede Variable und einer dynamischen Signatur D für jeden Taskzyklus codiert wird. Zusätzlich wird ein lokales und globales Programmfluss-Monitoring unter Verwendung der codierten Daten eingesetzt. In Abbildung 1 findet sich die vereinfachte Codierung für xc := xf * A.

Die Primzahl A bestimmt wichtige Safety-Charakteristiken, wie den Hammingabstand und die Restfehlerwahrscheinlichkeit P=1/A des Codes. Die statische Signatur garantiert die Korrektheit der Speicheradresse der benutzten Variablen. Die dynamische Signatur kann mit einem Clock-Zähler oder direkt durch den Task-Scheduler ermittelt werden. Die Anweisungen werden derart codiert, dass am Ende eines jeden Taskzyklus, zum Beispiel bevor eine Ausgabe an einen Aktuator erfolgt, ein Komparator die Ergebnisse des diversitären Berechnungskanals zc == zf * A + Bx + D? überprüft. Alternativ kann der codierte Berechnungskanal direkt mit der Modulofunktion überprüft werden: (zc-Bx-D) mod A ==0? Damit können verfälschte Daten erkannt werden.

Die Addition ist die einfachste der vier grundlegenden arithmetischen Operationen. Folgender Zusammenhang ergibt sich nach Anwendung der Transformationsvorschrift für die Additionsoperation im Bildraum:

Die verbleibenden arithmetischen Operatoren werden ähnlich errechnet.

Auch die logischen Operatoren erhalten im Bildraum eine komplexere Struktur. Beispielsweise wird für den Grösser-Gleich-Operator Geqzc (xc) folgende Darstellung [6] gefunden:

(1) IF xc umodA = Bx + D THEN xf _ 0.

(2) ELSE IF xc umodA = (Bx + D + (2n mod A)) mod A THEN xf ‹ 0.

(3) ELSE xc is not a valid code word.

Safety Code Weaving in der Hochsprache C

Im vorhergehenden Kapitel wurde ein Teil der SES Transformationen motiviert. Der vollständige Satz an Transformationen für Daten, arithmetische Operatoren und boolsche Operatoren ist einer C-Bibliothek zugeordnet. Safety Code Weaving fügt einen zweiten, diversitären Berechnungskanal zu einem gegebenen funktionalen ersten Berechnungskanal hinzu (Abbildung 2).

Safety Code Weaving fordert eine Folge von Arbeitsschritten. Hierzu zählen die Bildung diverser Daten, das Einfügen diverser Operationen, der regelmäßige Update der dynamischen Signaturen, das Absichern der Kontrollstrukturen (über Bedingungen, die durch das Verweben von Orignal- und Bildraumkanal erhältlich sind), eine globale Programmflussüberwachung und das Einfügen der Komparatorfunktionen.

Der folgende C-Quellcode zeigt die Codierung eines if-Konstruktes, wobei TRUEC und FALSEC codierte boolsche Werte darstellen.

int af; int ac;

int xf; int xc;

int tmpf; int tmpc;

cf = 152; /* begin basic block 152 */

af = 1; ac = 1*A + Ba + D; //coded 1

xf = 5; xc = 5*A + Bx + D; //coded 5

tmpf = ( xf >= 0 ); tmpc = geqz_c( xc ); // greater/equal zero operator

if ( cf != 152 ) { ERROR } /* end basic block 152 */

if ( tmpf )

{

cf = 153; /* begin basic block 153 */

if ( tmpc - TRUE_C ) { ERROR }

af = 4; ac = 4*A + Ba + D; //coded 4

if ( cf != 153 ) { ERROR } /* end basic block 153 */

}

else

{

cf = 154; /* begin basic block 154 */

if ( tmpc - FALSE_C ) { ERROR }

af = 9; ac = 9*A + Ba + D; //coded 9

if ( cf != 154 ) { ERROR } /* end basic block 154 */

Fallstudie: vereinfachter Sensor-Aktuator-Zustandsautomat

In der Fallstudie wurde ein vereinfachter Sensor-Aktuator-Zustandsautomat genutzt. Die beiden klassischen Implementierungsvarianten nested switch und tabellengestützter Zustandsautomat wurden verifiziert. Die Performance und die Filegrösse der Zustandsautomaten wurden gemessen und gegen die entsprechenden Grössen des uncodierten Originalcodes verglichen. Für die nested-switch-Implemenierungsvariante wurde ein Faktor 4,56 in der Laufzeit und ein Faktor 5,75 in der Filegrösse ermittelt. Die tabellengestützte Implementierungsvariante benötigt etwa 2,5 mal mehr Laufzeit und Filesize als die nested switch Variante. Diese Zunahme lässt sich durch die zusätzlichen Absicherungsmaßnahmen die Tabelle selbst betreffend erklären.

Auch das Update der dynamischen Signaturen stellt einen Overhead für die tabellengestützte Variante dar. Der ausführbare Code wurde generiert für einen Testcomputer mit einem Intel(R) Pentium(R) 4 CPU 1.60 GHz processor. Die benutzte IDE war Dev-C++ 4.9.9.2 mit dem Compiler GCC (MinGW) 3.4.2 und dem Linker GNU ld version 2.15.91 20040904. Die verwendete Compilerkonfiguration wurde hinsichtlich der Optimierungsflags überprüft. SES Code wurde nicht wegoptimiert. Für den NEC Fx3 V850ES Microcontroller und den Freescale S12X Microcontroller wurden ebenfalls Messungen der Runtime und der Filesize für den genannten nach SES codierten Zustandsautomaten publiziert [6].

Zusammenfassung und Ausblick: Safely Embedded Software stellt eine Programmierrichtlinie in der Hochsprache C zur Beherrschung zufälliger Hardwarefehler in Software dar. Gleichermaßen gibt Safely Embedded Software eine Safety-Architektur im Konzept zweier verwobener zueinander diversitärer Berechnungskanäle vor. In der vorliegenden Darstellung lässt sich mit dem SES Ansatz eine Fail-safe-Architektur gestalten. Werden jedoch zwei mit unterschiedlicher Primzahlen A1 und A2 codierte Brechnungskanäle verwendet kann eine Fault-tolerant-Architektur aufgebaut werden, wenn die Komparator-Funktion auf einer unabhängigen Verarbeitungseinheit (Watchdog, Monitor) bereitgestellt wird. Das Framework Safely Embedded Software soll im Forschungsprojekt S3OP auf die objektorientierte Programmiersprache C++ übertragen werden.

Referenzen

[1] International Electrotechnical Commission (IEC): Functional Safety of Electrical / Electronic / Programmable Electronic Safety-Related Systems. 1998.

[2] Forin, P.: Vital Coded Microprocessor Principles and Application for Various Transit Systems. IFAC Control, Computers, Communications, Paris, pp. 79-84, 1989.

[3] Oh, N., Mitra, S., McCluskey, E.J.: ED4I:Error Detection by Diverse Data and Duplicated Instructions. IEEE Transactions on Computers, 51, pp. 180-199, 2002.

[4] Leaphart, E.G., Czerny, B.J., D‘Ambrosio, J.G., Denlinger, C.L., Littlejohn, D.: Survey of Software Failsafe Techniques for Safety-Critical Automotive

[5] Hummel, M., Egen R., Mottok, J., Schiller, F., Mattes, T., Blum, M., Duckstein, F.: Generische Safety-Architektur für KFZ-Software. Hanser Automotive, 11, Munich, pp. 52-54, 2006.

[6] Mottok, J., Schiller, F., Zeitler, T.: Safely Embedded Software for State Machines in Automotive Applications. submitted to: Journal of Systems and Software, 2008.

[7] Siemers, C. Soft Errors durch Störenfriede aus dem Mikro- und Makro-Kosmos, Embedded Software Engineering Report, Vogel Verlag, München, Januar 2008. [8] Siemers, C., Drei Methoden zum Schutz von Soft Errors, Embedded Software Engineering Report, Vogel Verlag, München, April 2008.

(ID:290861)