4 Bewertungen

Designtools & Software Codefehler schneller finden

Bild: Halfpoint, iStock
07.06.2016

Die Anforderungen an die Entwickler von Embedded-Software steigen ständig: Wachsende Komplexität, Zeitdruck, Vernetzung oder Integration fremder Programme. Damit einher gehen immer mehr potentielle Fehlerquellen. Statische Analysetools helfen, Probleme frühzeitig auszuräumen und kostspielige Nachbesserungen zu vermeiden.

194 Milliarden US-Dollar – auf dieses Volumen soll der weltweite Markt für Embedded-Systeme bis 2018 anwachsen. Das meinen die Marktforscher von VDC. Angetrieben wird dieses Wachstum von Software-Innovationen und von der Nachfrage aus Märkten wie Automotive, Medizintechnik oder Industrieautomatisierung. Viele Anwendungen in diesen Märkten steuern sicherheitskritische und lebenswichtige Aufgaben. Das macht die Qualität und Sicherheit von Embedded-Anwendungen zum Goldstandard der Software-Programmierung.

Zudem lässt der Trend zur Vernetzung die Sicherheitsrisiken weiter steigen. Programmierer müssen daher strengere Leistungsstandards einhalten als ihre Kollegen aus anderen Branchen. Im Unterschied zu stark regulierten Branchen entstehen die meisten Embedded-Anwendungen in einer extrem von Wettbewerb bestimmten Umgebung mit kurzen Durchlaufzeiten. Und damit wächst das Risiko für Fehler im Code.

Beim Programmieren laufend neuer Funktionen stehen Entwickler nicht nur unter Zeit- und Budgetdruck, sondern haben auch eine Vielzahl von Herausforderungen zu bewältigen. Dazu gehören fremdentwickelter Code, Multicore-Hardware, Sicherheit und Vernetzung. Sie sollen die Risiken der Embedded-Sprachen berücksichtigen und dabei die Standards für Codequalität und Sicherheit, etwa DO-178B/C, MISRA und ISO einhalten. Dabei werden die Freigabezyklen immer kürzer. Nach Einschätzungen der Branche wächst die Code-Basis von Embedded-Anwendungen pro Jahr um fast 30 Prozent – parallel dazu steigen Komplexität und Fehlerrisiko. Dazu kommt, dass die Embedded-Sprachen C und C++ besondere Risiken für die Entwickler bergen: Mängel und Unklarheiten in der Sprach-Spezifizierung können unerwünschtes und unerwartetes Verhalten in der Ausführung bewirken.

Frühzeitig Fehler erkennen spart Zeit und Geld

Diese Faktoren haben zur Übernahme von formalen Kodier- und Testpraktiken durch Embedded-Entwickler geführt. Zusätzlich zum standardmäßigen QA-Test (Quality Assurance) können automatisierte Tools den Quellcode und die Ausführung einer Anwendung schon früh in der Entwicklung prüfen, wenn Fehler noch einfacher zu korrigieren sind.

Wie wertvoll ist eine möglichst frühe Fehleridentifizierung tatsächlich für die Ausführung und Leistungsfähigkeit des Codes? Von allen Tools und Strategien zur Programmierung von Embedded-Software bietet die automatisierte Quell-/Binär-Analyse mit die höchsten ROI-Werte (Return on Investment). Sie ist nicht nur effizienter als die manuelle Bearbeitung, sondern erspart vor allem aufwendige Reparaturen zu einem späteren Termin. Eine Studie des US-amerikanischen NIST (National Institute of Standard Technology) ergab bereits 2002: Während das Eliminieren eines einzelnen Fehlers in der Entwicklung rund fünf Stunden dauerte, war der Aufwand bei einem Fehler in der Produktionsumgebung durchschnittlich dreimal so hoch. Die automatisierte Codeanalyse ist deshalb eine der kosteneffizientesten Investitionen – sie bewirkt kürzere Freigabezyklen und eine höhere Produktivität der Entwickler.

Anforderungen an die automatisierte Analyse

Das statische Code-Analysetool Codesonar hat über eine Milliarde Codezeilen mit Null-Fehler-Toleranz verarbeitet in Anwendungen wie Herzrhythmusmanagementsysteme von Boston Scientific, NASA Mars Curiosity Rover, Kfz-Systeme. Basierend auf seinen Erfahrungen mit Embedded-Software empfiehlt Grammatech bestimmte Schlüssel-Fähigkeiten, die automatisierte Code-Analysetools besitzen sollten:

Integrierte Sicherheit: Der Trend zur Vernetzung von Embedded-Systemen vergrößert die potenziellen Angriffsflächen für Hacker. Bei Code-Injektionen speist der Angreifer spezielle Daten über einen Eingangskanal (zum Beispiel Netzwerkport) in ein Programm ein, das diese ungeprüft an einen sensitiven Teil weiterleitet. Solche Angriffe können Programmierer abwehren, indem sie dafür sorgen, dass Eingangsdaten validiert werden, bevor die Anwendung damit arbeiten darf.

Codesonar kann Schwachstellen aufspüren und meldet, was es als potenziell gefährlich (Tainted) einstuft. So lässt sich frühzeitig eine Sicherheitslücke schließen, die es einem Angreifer ermöglichen würde, beliebigen Code auf dem Server auszuführen.Riskante Fehler aufzufinden ist eine große Herausforderung, weil der Datenfluss über die gesamte Anwendung bis zum ursprünglichen Ausgangspunkt manuell nachverfolgt werden muss. Ein statisches Analysetool, das Daten automatisch nach potenziell gefährlichem Input untersucht, verkürzt diesen Vorgang enorm. Wichtig ist hier auch der Aspekt der rechtlichen Verantwortung, sollte kompromittierte Software den Endkunden erreichen.

Analyse von Binärdateien: In fast jeder Anwendung kommt extern geschriebener Code zum Einsatz. Weil der Zugriff auf dessen Quellcode fehlt, können ihn Entwickler nicht prüfen; ihnen bleiben nur Vermutungen hinsichtlich seiner Qualität und Sicherheit. VDC Research schätzt, dass es sich bei etwa 30 Prozent des Codes in Embedded-Anwendungen um kommerzielle 3rd-Party-Software handelt, für die der Quellcode oft nicht verfügbar ist. Ein automatisiertes Tool zur Anaylse von Binärdaten kann entsprechende Gefahrenstellen in Anwendungen finden und ausschalten.

Concurrency-Prüfung: Das Programmieren von Multithreaded-Anwendungen ist äußerst komplex – deshalb können sich auf diesem Weg Fehler einschleichen, die schwer aufzufinden sind. Moderne statische Analyselösungen können Concurrency-Probleme in C- und C++-Programmen beheben, aber speziell für Concurrent-Java-Programme gibt es bislang keine umfassende Lösung. Dabei arbeiten heute 28 Prozent der Entwickler mit Java, das damit nach C/C++ die dritt-populärste Sprache für Embedded-Systeme ist. Programmierer, die ihren Code nicht erfolgreich vor Fehlern wie Race Conditions und Deadlocks in C/C++ und Java schützen, werden unweigerlich mit Produktausfällen konfrontiert.

Native Unterstützung für Standards: Standards wie MISRA, DO-178B oder ISO 26262 und auch MISRA C setzen sich weltweit durch. Oft werden sie kombiniert in Industrien eingesetzt, die stark mit Embedded-Anwendungen arbeiten: Automotive, Aerospace, Medizingeräte und Industriesteuerungen. Unternehmen in diesen Märkten müssen gerüstet sein, um nicht nur Verstöße gegen die vordergründigen syntaktischen Regeln, sondern auch aus undefiniertem Verhalten entstandene ernste Bedrohungen zu identifizieren. Das schreibt etwa der Standard MISRA C:2012 vor. Nur die modernsten statischen Analysetools spüren die subtileren Ereignisse auf.

Werden Programmierstandards nicht eingehalten, können schwere Fehler in den Fertigungscode eindringen. Das Code-Beispiel in der Abbildung enthält eine vereinfachte Version des Codes mit dem Infinite Loop Bug, der im Zune-Musik-Player von Microsoft gefunden wurde. Am letzten Tag eines Schaltjahrs würde der Wert aus „days“ genau 366 betragen, der Loop würde nicht beendet. Weil Silvester 2008 der erste Tag nach der Vorstellung des Geräts war, setzte dieser Fehler viele Player außer Funktion.

Tiefgreifende Analyse: C und C++ sind wegen eigener Unzulänglichkeiten sehr anfällig für gefährliche Fehler. Trifft diese Eigenschaft auf eine Kombination aus Ziel-Hardware und Firmware, lässt sich unberechenbares Verhalten kaum verhindern. Hier hilft nur ein Tool, das tief in die Codebasis eindringt, dabei aber eine niedrige Rate an falschen Warnungen erzeugt. Tools, die mit Hilfe eines einheitlichen Datenflusses und der symbolischen Ausführungsanalyse ein gesamtes Programm untersuchen, finden mehr potenzielle Fehler und Schwachstellen. Außerdem können Teams mit einem solchen Tool, das Fehler visualisiert, das genaue Code-Verhalten in ihren Embedded-Anwendungen besser nachvollziehen.

Bildergalerie

  • Infinite Loop Bug (vereinfacht): Weil im Zune-Player von Microsoft am letzten Tag des Schaltjahrs der Wert aus „days“ 366 betrug, wurde der Loop nicht beendet. Viele Player wurden deshalb Silvester 2008 außer Gefecht gesetzt.

    Infinite Loop Bug (vereinfacht): Weil im Zune-Player von Microsoft am letzten Tag des Schaltjahrs der Wert aus „days“ 366 betrug, wurde der Loop nicht beendet. Viele Player wurden deshalb Silvester 2008 außer Gefecht gesetzt.

    Bild: Grammatech

Firmen zu diesem Artikel
Verwandte Artikel