Software-Entwicklung: Wo kommen bloß die Fehler her?

Software-Fehler können weitreichende Konsequenzen haben, wie der Absturz eines A400M im Mai diesen Jahres in Sevilla bewies.
Software-Fehler können weitreichende Konsequenzen haben, wie der Absturz eines A400M im Mai diesen Jahres in Sevilla bewies.

Bei Software scheint der Stand der Technik darin zu bestehen, dass man sich damit abgefunden hat, dass Software nun mal Fehler hat. Wo kommen sie eigentlich immer wieder her, die Fehler – trotz der vielen Werkzeuge, die angeblich alles finden? Und wie kann man ihre Entstehung verhindern?

Dass Autos bei jedem Werkstattbesuch ein Software-Update für die Steuergeräte bekommen, ist schon Standard. Seit es E-Bikes gibt, sind auch Radfahrer davor nicht mehr gefeit. Eine frühe Generation des Bosch-Antriebs meldete ein Temperaturproblem im Diagnose-Protokoll, das aber in Wirklichkeit gar nicht aufgetreten war. Viele Kunden ließen diesen Fehler durch ein Software Update beheben. Dumm nur: Bosch hatte gleichzeitig die Motorsteuerung modifiziert und das Drehmoment abgesenkt, um Retouren aufgrund gebrochener Kunststoff-Zahnräder im Getriebe zu reduzieren. Kunden, die ihr Rad aus der Werkstatt holten, waren nun zwar den Software-Fehler los, beklagten sich aber über ein komplett verändertes Fahrverhalten. Weniger harmlos ist der Absturz eines Airbus A400M im Mai 2015 in Sevilla.

Die fabrikneue Maschine, die das erste Mal abhob, bekam nicht genug Schub und ging kurz nach dem Start wieder nieder. Vier Besatzungsmitglieder starben, zwei wurden schwer verletzt. Laut Airbus waren drei der vier Triebwerke „eingefroren“, ihre Schubkraft ließ sich nicht erhöhen – aufgrund eines Software-Fehlers. Warum es einfach nicht gelingt, Software-Fehler auszuschalten, darüber sprach Elektronik-Redakteur Joachim Kroll mit dem Sicherheitsexperten Dan Smith.

Elektronik: Rückrufaktionen aufgrund von Software-Fehlern sind in den Nachrichten. Jüngst stürzte ein Airbus-Militärtansporter ab – vermutlich wegen eines Software-Fehlers. Warum ist es so schwer, fehlerfreie Software zu produzieren?

Dan Smith: Software kann ungeheuer komplex sein. Und Embedded-Software hat die Tendenz, nochmal komplexer als typische Desktop-Software zu sein, weil sie auf ressourcenbeschränkten Systemen läuft und zeitliche Randbedingungen unter verschiedensten externen Einflüssen einhalten muss, um richtig zu funktionieren. Außerdem wird Embedded-Software von Mitarbeitern unterschiedlicher Qualifikation entwickelt: Elektroingenieure, Informatiker, machmal auch von Mechanikern oder anderen Technikern. Einige von denen haben die Software-Entwicklung vielleicht nur im „Training on the job“ erlernt und gehen nicht mit der notwendigen ingenieursmäßigen Systematik vor, die für sicherheitskritische Software erforderlich ist. Und schließlich: Je größer die Teams werden, je weiter sie verstreut sind, je enger der Zeitplan und je knapper die Budgets werden, desto schwieriger wird es mit der Einhaltung von Qualitätsstandards.

Elektronik:Aber es gibt „Best Practices“, Software-Tools, bewährte Prozesse und Zertifizierungen, die sicherstellen sollen, dass Software nichts anderes macht als das, was sie soll.

Dan Smith: Ja, richtig, aber es gibt auch viele Möglichkeiten, wie sich Fehler einschleichen können. Zum Beispiel: Der Code wird von einem neuen Entwickler gewartet, der den Code nicht kennt oder nicht über die internen Prozesse und Entwicklungswerkzeuge in der Firma informiert wurde. Manche Fehler ergeben sich, wenn die Hardware geändert wird, einfach so, obwohl die Software unverändert bleibt. Und manche Probleme wie Race Conditions oder Hardware-Störungen sind außerordentlich schwer zu erkennen, wenn man nicht gerade über sehr teure Entwicklungs- und Testwerkzeuge verfügt.

Elektronik: Sehen Sie Zusammenhänge zwischen funktionaler und IT-Sicherheit? Sind funktional unsichere Systeme leichter angreifbar und umgekehrt?

Dan Smith: Da gibt es ganz klar einen Zusammenhang, obwohl beides unterschiedliche Dinge sind. Entwickler von sicherheitskritschen Systemen wenden Methoden wie die Fehlermöglichkeits- und -einflussanalyse und die Fehler­baum­analyse an, um problembehaftete Bereiche ausfindig zu machen. Damit stellen sie nicht nur sicher, dass das System sich funktional korrekt verhält, sondern auch, dass Störungen sicher abgefangen werden. Ein Security-Ingenieur hat andere Sorgen und wird Techniken wie Threat Modeling anwenden, um Sicherheitslücken zu identifizieren und zu entscheiden, welche Gegenmaßnahmen geeignet sind.

Ein System kann funktional relativ sicher, aber IT-technisch unsicher sein und umgekehrt. Am besten ist natürlich, wenn beide Sicherheitsaspekte erfüllt sind, zumal derselbe Software-Fehler – z.B. ein Pufferüberlauf oder undefiniertes Verhalten – sowohl zu Sicherheitslücken als auch zu Funktionsaufällen führen kann. Wichtig ist, dass Software-Entwickler diese grundlegenden Probleme in den Griff bekommen, bevor sie sich um speziellere Sicherheitsfunktionen kümmern.

Elektronik: Sichere Software ist dort unverzichtbar, wo menschliches Leben oder die Gesundheit davon abhängt, genauso wie in Anwendungen, wo Fehlfunktionen große Schäden verursachen könnten. Sehen Sie durch die Allgegenwärtigkeit von Software weitere Gebiete, in denen die Software-Qualität wichtig ist, aber noch nicht genügend beachtet wird?

Dan Smith: Diese Frage berührt zwei Aspekte. Bezüglich Safety und Security würde ich sagen, dass Safety das ausgereiftere der beiden Software-Merkmale ist. Glücklicherweise hören wir kaum von Flugzeugen, die vom Himmel fallen, Raketen, die von selbst starten, oder medizinischen Geräten, die Patienten töten. Aber fast jede Woche – so kommt es mir jedenfalls vor – gibt es einen Router, der gehackt worden ist, stellen Smartphone-Apps unsichere Verbindungen her oder können Patienten- oder Kundendaten abgefischt werden, weil kleine IoT-Geräte nicht ausreichend abgesichert sind.

Der zweite Aspekt der Frage sind die unterschiedlichen Branchen. Hier sind viele betroffen, vor allem durch IT-Sicherheitslücken. In vielen Industriezweigen werden Geräte sorglos und ohne große Sicherheitsvorkehrungen mit dem Internet verbunden. Medizingeräte, von denen das Leben von Patienten abhängt, enthalten persönliche Daten und können mit Software Updates versorgt werden, in denen fast das gesamte Know-how des Herstellers steckt. Oder die Geräte sind mit nicht freigeschalteten Upgrade Features ausgestattet, die schon durch eine kleine Manipulation kostenlos freigeschaltet werden können. Andere Branchen wären die Energieversorger mit den Smart Grids, industrielle Automatisierung, Verkehrswesen – Automobil, Bahnen, Flugzeuge – oder die Zutrittskontrolle.

Alle diese Branchen werden zunehmend abhängig von der Embedded-Software und damit auch von Embedded Safety und Security. Ein typisches Automobil hat 50 Mikroprozessoren, ein High-End-Auto vielleicht 150. Da macht man sich dann weniger Sorgen um ausreichend PS oder Tankdiebe, sondern eher darum, ob das benachbarte Fahrzeug die eigenen Steuerfunktionen während der Fahrt beeinflussen kann. Sehr viele Sorgen machen uns bei der Barr Group Produkte mit Internet-Verbindung, bei denen niemand an die Sicherheit gedacht hat. Oft sind es Low-Cost-Produkte. Müssen ein Kühlschrank, ein Rauchmelder, ein Thermostat wirklich mit dem Internet verbunden sein? Klar, die Bequemlichkeit und Coolness sind toll, aber zu welchem Preis? Diese Dinge müssen sorgfältig abgewogen werden in unserem Bestreben nach Konnektivität.

Elektronik: Der Kunde setzt Software-Qualität einfach voraus und für den Entwickler ist es kein Feature, sondern ein Kos­tentreiber. Wie kann man fehlerfreie Software effektiv produzieren? Wie lassen sich die Kosten im Griff behalten?

Dan Smith: Richtig, Kunden fragen nur dann nach Software-Qualität, wenn sie nicht vorhanden ist. Aus meiner Sicht sind die drei größten Hemnisse: Kosten, Zeitplan und Erfahrung. Da Kosten- und Zeitdruck niemals verschwinden werden, setzt die Barr Group darauf, die Fähigkeiten, die Abläufe und die Werkzeuge bei den Entwicklern zu verbessern. Das erreichen wir durch eine Kombination aus Beratung und Training. In unseren Embedded-Software-Kursen unterrichten wir spezielle Fertigkeiten, bewährte Vorgehensweisen und Abläufe, die Defekte vermeiden und die Qualität steigern. Je später ein Fehler gefunden wird, desto teurer wird seine Beseitigung – bis hin zum Produktrückruf. Also konzentrieren wir uns darauf, wie man Fehler von Anfang an aus der Embedded-Software raushält. Zum Beispiel empfehlen wir dringend die Einführung eines Codierungsstandards, Code Reviews und statische Analyse-Tools. Das Ergebnis ist, dass Embedded-Software pünktlich und mit dem geplanten Budget fertig wird