Startseite > Automotive > Software + Tools > Funktionale Sicherheit von Embedded-Systemen

Sichere Software ist Pflicht

Funktionale Sicherheit von Embedded-Systemen

13. März 2019, 10:30 Uhr | Von Mark Hermeling

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Echte Fehler und Fehlalarme

Nur professionelle Analysewerkzeuge kommen mit den komplexeren, weil nicht rein auf syntaktische Elemente fokussierten Regeln zurecht. Ein typisches Beispiel dafür ist Regel 2.2, die sogenannten Dead Code verbietet. Unter totem Code versteht man jegliche Operation, deren Ergebnis das Verhalten eines Programms nicht beeinflusst – im Gegensatz zu unerreichbarem Code, der durch keinen möglichen Kontrollfluss erreichbar ist und deswegen das Verhalten eines Programms nicht beeinflusst. Um toten Code aufzuspüren, muss das Analyse-Tool die Semantik aller möglichen Ausführungen des Programms verstehen. Dabei ist es fast unmöglich, wirklich alle Instanzen toten Codes zu finden, ohne dass es zu False Positives kommt.

Die Zuverlässigkeit, ob sicher alle Regelverstöße ohne False Positives erkannt werden, ist die zweite Kategorie, in die die MISRA-Regeln unterteilt werden: entscheidbar (decidable) und unentscheidbar (undecidable). Regeln sind entscheidbar, wenn es für ein Werkzeug möglich ist, alle Regelverletzungen ohne Fehlalarm zu finden. Die meisten Regeln zu überflüssiger Syntax fallen in diese Kategorie. Unentscheidbar bedeutet im Vergleich dazu, dass es für ein Analyse-Tool grundsätzlich nicht möglich ist, alle Verstöße ohne irgendwelche False Positives aufzudecken. Besonders unentscheidbare Regeln jedoch sind die wichtigsten, sie adressieren die häufigsten Quellen für schwerwiegende Fehler wie Probleme bei der Nebenläufigkeit. Professionelle Analysewerkzeuge suchen deswegen die richtige Präzisionsbalance

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Damit ist die statische Analyse realistisch betrachtet in der Lage, die Fehlerquote signifikant zu minimieren. Durch die explizite Ausrichtung von MISRA C an der Überprüfbarkeit aller Regeln durch die statische Analyse entsteht so durch den Einsatz eines fortschrittlichen Analyse-Tools ein kontrollierbarer und anerkannter Entwicklungsansatz, der den in IEC 61508 und ISO 26262 gestellten Anforderungen gerecht werden kann. Zudem ist es möglich und sinnvoll, die statische Analyse weitgehend automatisiert innerhalb der SDLC als integralen Bestandteil der Werkzeugkette zu verankern. Durch eine möglichst durchgängige Automatisierung der Entwicklung (Bild 3) und vor allem der Qualitätssicherung lassen sich die Risiken, die von einem sicherheitskritischen System ausgehen, signifikant reduzieren. Denn jeder manuelle Eingriff stellt eine potenzielle Fehlerquelle dar.

Dieser Effekt steigt mit der Risikoklasse signifikant an. Dabei kann ein Werkzeug wie CodeSonar (Bild 4) von GrammaTech direkt am Arbeitsplatz des Entwicklers zum Einsatz kommen, um Fehler in den täglichen Integrationen noch vor dem lokalen Test-Build zu erkennen und zu beheben. Gleichzeitig kann die statische Analyse in das Build-System eingefügt werden und dort eine zusätzliche Schicht zur Fehlerminimierung bilden. Hier ist die statische Code-Analyse dem dynamischen Testing vorgelagert. Gleichzeitig hilft die statische Analyse bei den unverzichtbaren Reviews, die über den Lebenszyklus eines Embedded-Systems hinweg gemacht werden müssen.

Ein weiterer wichtiger Aspekt ist, dass durch die statische Analyse die korrekte Anwendung von MISRA C innerhalb des SDLC dokumentiert und transparent gemacht wird. So erfüllt die statische Analyse zwei zentrale Anforderungen der IEC 61508 und der ISO 26262: Fehler so gut wie möglich zu vermeiden und gleichzeitig die Einhaltung der in der Norm beschriebenen Verfahren und Methoden zuverlässig zu dokumentieren. Dabei muss allerdings klar sein, dass der Einsatz eines Tools zur statischen Analyse für sich genommen noch keine Compliance erzeugt. Das Werkzeug dient vielmehr dazu, die Compliance nachzuweisen. Im Falle der ISO 26262 etwa adressiert die statische Analyse zahlreiche Anforderungen aus Abteilung 6 der Norm, die sich mit der funktionalen Sicherheit auf Software-Level befasst. Zum Nachweis der Compliance ist es hilfreich, wenn das entsprechende Analysewerkzeug für die Verifizierung von Software in sicherheitsrelevanten Systemen nach den höchsten Sicherheitsanforderungen von IEC 61508 und ISO 26262 zertifiziert wurde.

Fehler im Code erkennen

Die Entwicklung von Embedded-Software für sicherheitskritische Anwendungen erfordert einen strengen Ansatz. Best Practices wie MISRA C, die sowohl Programmstandards als auch -prozesse umfassen, haben sich zur Verbesserung der Software-Qualität bewährt. Durch Tools zur statischen Code-Analyse können diese Standards automatisiert als integraler Bestandteil des SDLC und der späteren Revisionen etabliert werden. Die Umsetzung von Standards, Regeln und Richtlinien ist so durchgängig sichergestellt, der Compliance-Nachweis wird signifikant vereinfacht.

Wichtiger ist jedoch, dass die statische Analyse dabei hilft, Fehler im Code zu erkennen, die durch andere Methoden der Qualitätssicherung unentdeckt bleiben können. In Verbindung mit Ansätzen wie Testing entsteht eine vollständige Sicht auf die Software, die auch Komponenten von Drittherstellern wie Windowing-Toolkits oder Bibliotheken mit einschließt. So können die unvermeidbaren Risiken, die bei sicherheitsrelevanten Systemen immer vorhanden sind, reduziert werden – und gleichzeitig die Time to Market, da Fehler frühzeitig innerhalb des SDLC erkannt werden. Denn je früher ein Fehler beseitigt wird, desto günstiger und schneller kann das erfolgen.

Der Autor

Mark Hermeling

studierte Computerwissenschaften an der University of Technology in Eindhoven. Seit 2017 ist er als Senior Director Product Marketing bei GrammaTech tätig. Vor seinem
Eintritt ins Unternehmen war Mark Hermeling acht Jahre bei Wind River beschäftigt.