Mit Standards zu besserer Software

Beinahe jede Branche hat Standards entwickelt, um über sichere und zuverlässige Software zu verfügen. Je kritischer der Einsatzbereich, desto strenger sind die Normen. Und desto größer ist der Aufwand, bis aus dem Entwicklungsprojekt ein marktreifes Produkt entsteht. Kritische Infrastrukturen, Flugzeuge, Automobile oder medizinische Geräte verlangen von den Entwicklern besondere Prozesse und Dokumentationen, bevor die Device in der Praxis eingesetzt werden darf. Je mehr Embedded Devices die Geschäftsmodelle und das Leben jedes Einzelnen bestimmen, desto wichtiger wird es auch außerhalb der hochkritischen Bereiche, eine hohe Software-Qualität sicherzustellen. In vielen Einzelbereichen kann die Überprüfung der Software auf Einhaltung der Normen und Standards automatisiert werden, etwa bei der Code-Analyse. Diese Möglichkeiten sollten genutzt werden, um Time-to-Market und Entwicklungskosten zu minimieren.

DO-178 C

CodeSonar erlaubt durch Visualisierung einen anderen Blick auf den Code, mit dem sich viele potenzielle Probleme frühzeitig erkennen lassen. (Quelle: Grammatech)

Mit die vielleicht strengsten Vorgaben hat die Avionik-Norm DO-178C (Software Considerations in Airborne Systems and Equipment Certification), die von EUROCAE komplett als ED-12C übernommen wurde. In Kapitel 6 befasst sich der Standard mit dem Verifizierungsprozess für Software. Einige der in den Kapiteln 6.3 und 6.4 aufgestellten Forderungen können mit geeigneten Tools wie GrammaTech CodeSonar weitgehend automatisiert und ohne große Aufwände überwacht werden. So etwa bei der unter Punkt 6.3.3 in DO-178 aufgestellten Forderung, dass sichergestellt sein muss, dass es keinen Konflikt zwischen der Software-Architektur und den High-Level-Anforderungen geben darf. Dabei werden besonders Funktionen wie Partitionierungsschemata hervorgehoben. Indem die Architektur durch das Analyse-Tool visualisiert wird, können die Entwickler interaktiv die Struktur der Software untersuchen. Die APIs von CodeSonar erlauben es zudem, automatisierte und individuell angepasste Checks zu integrieren.

Eine weitere Forderung in DO-178 ist, dass Partitionen isoliert sein müssen und Speicherlecks zu verhindern sind. Diese Anforderung sollte eigentlich in jedem Entwicklungsprojekt Standard sein. Um dieses auch zu gewährleisten, müssen sowohl der Daten- als auch der Control-Fluss exakt in allen möglichen Zuständen des Programms nachvollzogen werden. Unter anderem sollten sich dabei folgende Fragen beantworten lassen:

  • Können Daten aus Bereich A die Verarbeitung in Bereich B beeinflussen?
  • Gibt es einen Ausführungspfad zwischen Bereich C und Bereich D?
  • Welches sind die Caller der Funktion F?

Ein Analyse-Tool kann die Partitionssicherheit automatisch analysieren und zudem bei möglichen Problemen wichtige Lösungshinweise geben.

Neben diesen beiden Beispielen enthält die Avionik-Norm noch zahlreiche weitere Vorgaben, wie Software in einem hochkritischen Bereich sicher gestaltet werden kann. Für die meisten Entwicklungsprojekte ist es unsinnig, sich komplett an einem derart strengen Standard zu orientieren. Man sollte ihn vielmehr als Sammlung von Hinweisen betrachten: Welche davon auf das jeweilige Unternehmen und Entwicklungsprojekt passen, sollte im Vorfeld bereits evaluiert werden, um die Möglichkeiten zur Automatisierung bei der statischen Analyse optimal zu nutzen.

MISRA-C

Ganz ähnlich verhält es sich mit dem weit verbreiteten Standard MISRA-C, der aus dem Automotive-Bereich stammt und auch vor allem dort zum Einsatz kommt. Bei MISRA-C geht es weniger darum, Fehler zu verhindern, sondern um einen Regelsatz für die Entwicklung zur Verfügung zu stellen. Die Richtlinien befassen sich zum Beispiel mit dem Umgang mit Sprachkonstrukten, die nicht eindeutig definiert sind und so bei verschiedenen Compilern zu verschiedenen Ergebnissen führen können. Um die Einhaltung zu gewährleisten, setzt MISRA-C unter anderem den Einsatz von statischer Analyse voraus.

Einige der Regeln in MISRA-C sind im Rahmen einer automatischen Analyse einfach umzusetzen. Diese Regeln werden im Standard als „Decidable“ (Entscheidbar) bezeichnet, hier kann eine eindeutige Falsch/Richtig-Entscheidung getroffen werden. Das Verbot von Trigraphen, also der mit ?? beginnenden Drei-Zeichen-Ketten, gehört zu dieser Kategorie. Diesen Teil des Standards grundsätzlich in die eigene Entwicklung zu übernehmen, ist auf jeden Fall sinnvoll. Etwas komplexer wird es bei den als „System“ bezeichneten Regeln von MISRA-C, da hierbei mehrere Elemente des Codes gleichzeitig betrachtet werden müssen. Darunter fällt zum Beispiel die Forderung, das externe Identifier immer unterscheidbar sein müssen. Auch diese Regel ist zwar entscheidbar, aber nur, wenn das Analyse-Tool alle Code-Bereiche durchforstet und die gefundenen Identifier vergleicht. Manuell ist das kaum zu leisten, auch die Automatisierung dieser Prüfung gestaltet sich ziemlich schwierig. In der Praxis hat es sich als sehr effektiv erwiesen, das Analyse-Tool mit dem Build-System als vertrauenswürdige Quelle zu integrieren. Dann können auch diese Checks ohne größere Hürden in den eigenen Entwicklungsstandard übernommen werden.

Allerdings verfügt MISRA-C auch über Regeln, deren Einhaltung als „unentscheidbar“ bezeichnet wird. Es wird hierbei davon ausgegangen, dass es keine Methode gibt, die Einhaltung der jeweiligen Regel zu verifizieren oder zu falsifizieren. Das Verbot von direkten oder indirekten Rekursionen gehört in diese Kategorie. Um hierfür einen Checker zur automatischen Analyse zu entwickeln, muss man die Balance zwischen False Postives und False Negatives finden, um zu sinnvollen Ergebnissen zu gelangen. Hier gilt es, die einzelnen Regeln für die eigene Software-Entwicklung zu priorisieren. Denn nur sehr ausgereifte Analyse-Tools können hier wirkliche Hilfestellung bieten.

DIN EN 50128

Auch die DIN EN 50128 befasst sich mit der Entwicklung sicherer Software und kann, obwohl sie eigentlich für den Eisenbahnverkehr entwickelt wurde, in vielen Projekten Anregungen bieten. Die Norm ist im Kern eine Spezialversion der recht allgemeinen EN 61508. DIN EN 50128 bezieht sich zum Teil explizit auf MISRA-C und fordert neben Modularität komponenten-, struktur- und objektorientierte Programmierung. Der Einsatz eines Tools zur statischen Analyse ist explizit vorgesehen. Konkrete Forderungen umfassen zum Beispiel eine Begrenzung der Komplexität von Funktionen und Methoden, den Verzicht auf dynamische Variablen oder die Analyse von Steuer- und Datenfluss. Alle diese Faktoren können unter Verwendung von CodeSonar automatisiert abgebildet und somit relativ einfach in den eigenen Entwicklungsprozess integriert werden.

Die Fülle an Normen und Standards hat sicher ihre Berechtigung, doch verstellt sie auch gerne den Blick auf das Wesentliche: Allen Vorgaben gemein sind Best Practices, wie Software sicherer und zuverlässiger gemacht werden kann. Das ist zum einen im Interesse der Kunden und Anwender. Es ist aber auch im ureigensten Interesse der eigenen Unternehmen. Eine enge Anlehnung an diese Standards sorgt für transparente Prozesse, eine dokumentierte Vorgehensweise und klare, interne Regeln für die Entwicklung. Eine schnellere Time-to-Market, geringere Wartungsaufwände und Folgekosten sowie zufriedene Kunden sind der Lohn dieser Mühe.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.