Nachweisbare Tests für funktionale Sicherheit auf Serienhardware durchführen

Um die funktionelle Sicherheit von Embedded Software unter Feldbedingungen nachweisen zu können, bedarf es neben modellbasierten Methoden auch komplett neue ganzheitliche Ansätze auf Systemebene. Voraussetzung hierfür ist die Möglichkeit einer nahtlosen Kopplung verschiedener Tools, die unterschiedlichste Zielstellungen abdecken.

Anbieter zum Thema

Axivion GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

PLS Programmierbare Logik & Systeme GmbH

Modellbasierte Tests bieten heutzutage erfreulicherweise die Möglichkeit, eingebettete Software schon vor der Verfügbarkeit der realen Hardware auf ihre funktionale Korrektheit zu überprüfen. Ein Verfahren, das grundsätzlich durchaus Zeit und Kosten sparen hilft. Aber irgendwann kommt der Zeitpunkt der Wahrheit: der Test auf echter Hardware. Vor allem in echtzeit- und sicherheitskritischen Anwendungen muss gewährleistest sein, dass für den Test genau die gleichen Bedingungen wie auch später im Feld vorherrschen, also keine Code-Instrumentierung mehr vorliegt.

Testwerkzeuge sind dafür ausgelegt, die Verwaltung von Testfällen und die Testdokumentation vorzunehmen. Den Zugang zum Zielsystem, welcher für den Test auf der echten Hardware unter Serienbedingungen notwendig ist, muss durch den Debugger bereitgestellt werden. Die enge Kopplung beider Werkzeuge ist daher von essentieller Bedeutung (Bild 1).

Bildergalerie

Das typische Testsystem

Schauen wir uns zunächst einmal das Time Partitioning Testing (TPT) der Firma PikeTec als ein typisches Beispiel für Testsysteme an. Hinter TPT verbirgt sich ein modellbasiertes Testverfahren, mit dem sowohl Matlab/Simulink- oder ASCET-Modelle als auch C-Applikationen getestet werden können und das auf parallel arbeitende Automaten zurückgreift (Bild 2).

Sogenannte Variationspunkte ermöglichen dabei die Modellierung einer großen Anzahl von Testfällen für einen gemeinsamen Automaten. So bleibt auch bei komplexen Tests mit einer Vielzahl von Testfällen die Übersichtlichkeit gewährleistet. Die Kopplung von TPT mit dem Anforderungsmanagement und der integrierten Testauswertung ermöglicht einen durchgängig automatisierten Prozess, angefangen von der Anforderungsspezifikation über die Testmodellierung und -durchführung bis zur Testauswertung und Dokumentation.

Testfall unter echten Einsatzbedingungen

Richtig interessant wird es bei beiden Verfahren erst, wenn die Tests auf der echten Hardware, etwa auf einem Motorsteuergerät in einer Labcar-Umgebung, ausgeführt werden. Nur bei solchen Tests wird das System nämlich unter vergleichbaren Bedingungen wie später beim Kunden im Feld gestresst.

Um die Unterschiede zwischen Theorie und Praxis zu verdeutlichen, werfen wir zunächst einen Blick auf den ausgeführten Code. Durch dessen Kompilierung für eine bestimmte Prozessorarchitektur bzw. den im Steuergerät verbauten Controllertypen hat der verwendete Compiler natürlich erheblichen Einfluss auf die funktionale Korrektheit der Applikation. Nicht nur echte Compiler-Bugs, auch ungünstig gewählte Optimierungseinstellungen können hier mitunter zu erheblichen Problemen führen.

Aus einer ganzen Reihe von dokumentierten Fällen an dieser Stelle nur ein Beispiel dafür; Der Compiler eliminiert automatisch mehrfache Lese-/Schreibzugriffe auf Speicher, die aus seiner Sicht den Wert nicht verändern. Dies ist aber im Embedded-Bereich oft nicht zulässig, da sich hinter Speicherlokationen beispielsweise auch I/O-Register verbergen können, der Wert sich also durchaus zwischen zwei aufeinanderfolgenden Leseoperationen ändern kann. Der jeweilige Entwickler muss sich diesem Umstand bewusst sein und bereits im Vorfeld entsprechende Vorkehrungen treffen.

Der zu testende Code sollte natürlich auch identisch zum Seriencode im Steuer-gerät sein. Mitunter benötigen die Testwerkzeuge aber instrumentierten Code, also zusätzlichen Testroutinen, um damit beispielsweise Testvektoren zu injizieren und Ergebnisse abzugreifen. Damit ändert sich nicht nur das Laufzeitverhalten und die Codegröße, sondern gegebenenfalls auch das Speicherlayout. Dies wiederum kann sich insbesondere bei sicherheitskritischen Anwendungen oder Systemen mit hohen Echtzeitanforderungen als überaus kritisch erweisen.

Um dieser Zwickmühle zu entkommen, bieten sich zwei Optionen an. Eine Variante wäre, die Instrumentierung auch im Seriencode beizubehalten. Dies würde zumindest gewährleisten, dass Seriencode und zu testender Code und damit auch das Laufzeitverhalten im Test und im Feld identisch sind. Oder man nimmt gleich den Debugger zu Hilfe. Er kann dann genau die Aufgaben übernehmen, die eigentlich der Code-Instrumentierung obliegen: die Injektion der Testvektoren und das anschließende Abholen der Ergebnisse.

(ID:45087348)