Absolute Fehlerfreiheit ist illusorisch

Das mangelnde Bewusstsein für Safety ist umso erstaunlicher, wenn man die möglichen Konsequenzen bedenkt. Ein unzufriedener Kunde mag zu einem wirtschaftlichen Schaden führen. Auch das kann zu einem ernsthaften Problem werden, ist aber relativ harmlos im Vergleich zu einem Fall, bei dem aufgrund mangelnder Betriebssicherheit Menschen zu Schaden kommen. Hier muss auch der Entwickler mit drastischen Konsequenzen rechnen, wenn er Anforderungen nicht erfüllt hat. Umgekehrt macht es eine umfassende Dokumentation von Entwicklung und Test leicht, entsprechende Vorwürfe zu entkräften. „Entwicklern ist oft nicht bewusst, dass die Safety-Standards den Stand unserer Technik widerspiegeln und unsere Arbeit – wenn wir diesen Standards nicht gerecht werden – handwerklich mangelhaft ist“, erklärt Dr. Günter Glöe.

Da Normen für Entwickler schwer interpretierbar sind, ist es wichtig, die entsprechenden Auditoren frühzeitig in den Entwicklungsprozess einzubeziehen. „Sicherheitsstandards sind Kochrezepte für Elektronik und Software, die dem Stand der Technik entsprechen“, führt Günter Glöe aus. „So wie man Kochrezepte für die eigene Küche anpassen muss, muss man auch die Standards an den eigenen Bedarf anpassen.“ Und eine absolute Fehlerfreiheit ist nahezu illusorisch. „Zero Defects sind zwar wünschenswert, aber physikalisch nicht zu erreichen“, erklärt Prof. Dr. Jürgen Mottok, Scientific Head of Laboratory for Safe and Secure Systems in Regensburg. „Die Betriebssicherheit eines technischen Systems versteht sich als die Reduktion des Risikos auf ein (wirtschaftlich) vertretbares Maß. Damit verbleiben tolerierbare Restfehler in unseren technischen Systemen. Geeignete Fehlererkennung und -reaktionen müssen umgesetzt werden.“

Prüfarbeiten müssen parallel zur Entwicklung laufen

Aber wie kann man als Entwickler sichere und qualitativ gute Software entwickeln? Zunächst einmal muss man sich darüber im Klaren sein, dass Sicherheit und Qualität keine Zufallsprodukte sind – sie sind das Ergebnis gezielter Maßnahmen während des gesamten Entwicklungsprozesses. Man kann nicht am Ende des Prozesses Qualität hineintesten. Aufgrund der geforderten Sicherheitsstufe sollten in jeder Phase des Projekts (zum Beispiel Anforderungsanalyse, Design, Implementierung, Unit-Test, Integrationstest, Systemtest, Inbetriebnahme) geeignete Maßnahmen ergriffen werden, die einerseits die Erfüllung der Qualitätsanforderungen sicherstellen und andererseits durch geschickte Kombination dazu dienen, den Gesamtaufwand zu minimieren. „In fast allen Projekten ist die fehlende Verzahnung der Teststufen ein Problem“, erläutert Christian Nachreiner, Geschäftsführer Intence Automotive Electronics. „Dadurch können weiße Flecken in der Testabdeckung entstehen, die in einem Safety-Projekt nicht akzeptabel sind. Abhilfe schafft ein projektübergreifendes Testkonzept. Leider ist in vielen Unternehmen keine Rolle in der Entwicklung besetzt, welche die Tests auf allen Ebenen von der Implementierung bis zum Prüflabor betrachtet.“ Auch Dr. Günter Glöe sieht in mangelnder Planung des Testens eines der größten Probleme: „Ingenieurstätigkeiten unterscheiden sich vom Basteln auch dadurch, dass sie geplant ablaufen. Die Planung der Prüfarbeiten muss parallel mit der Entwicklung des Arbeitsproduktes laufen, gegen das geprüft wird.“

Embedded-Softwareentwicklung hinkt hinter Hardwareentwicklung her

„Sicherheit und andere Qualitätmerkmale müssen bereits Bestandteil des Systementwurfs sein“, so Peter Siwon. „Das fängt bei der Anforderungsanalyse an. Es geht weiter beim Design, wo geprüft werden muss, ob die Architektur überhaupt die Sicherheitsanforderungen abbilden kann. Es gibt Designs, bei denen man an der Struktur erkennen kann, dass die Sicherheitsanforderungen nicht erfüllbar sind.“ Auch bei der Implementierung müssen bestimmte Regeln eingehalten werden, um die Sicherheit zu garantieren. Es ist sinnvoll, in jeder Prozessphase darüber nachzudenken, wie man die Sicherheitsanforderungen erfüllbar machen kann. In vielen Fällen wird zu sehr implementierungsorientiert gedacht. Phasenorientierte Prüfschritte verzögern zwar die Implementierung, reduzieren aber gleichzeitig den Aufwand für große Korrekturschleifen, die sich durch den gesamten Entwicklungsprozess ziehen. Man sollte den Drachen nicht erst versuchen zu bändigen, wenn er bereits groß und stark ist. „In Bezug auf Sicherheit und Qualität hinkt die Softwareentwicklung noch hinter der Hardwareentwicklung her“, so Peter Siwon. „Viele Entwickler glauben, man könne in der Software schnell mal nachträglich etwas ändern, aber dafür sind viele Systeme bereits zu komplex.“

 

Lesen Sie auf der nächsten Seite, wie alle Projektbeiteiligten qualifiziert und informiert werden können.

Seite 2 von 3123