Ich bin mal sehr gespannt, wie es hier weitergeht.
Dass fehlerfreie Software nicht existiert, ist unbestritten. Die Art und Weise, wie mit Fehlern umgegangen wird, ist der entscheidende Punkt. In allen mit funktionaler Sicherheit beschäftigten Normen (61508, 13849, 26262 im Automotive-Bereich oder Do-178 bei den Fliegern) ist immer das Ziel, Fehler dergestalt zu beherrschen, dass ein Ausfall möglichst immer durch Diagnosesysteme im Vorhinein erkannt wird und es durch entsprechende Behandlung einen "sicheren Ausfall" gibt. Das ist bei Autos oder Fluggeräten bei weitem nicht so einfach wie bei Industrieanlagen. Bei letzteren kann man meist einfach alles ausschalten. Ist im Flugzeug in einer Fehlersituation selten eine gute Idee.
Was mich folgerichtig hier stört, ist, dass es
a) den Fehler gab, aber
b) scheinbar keine in die Software integrierte Diagnose exitstiert und
c) die Tests im Vorhinein unzureichend waren.
Weiter oben gab es schonmal den Hinweis, dass Boeing sicher eine gute Code-Coverage und sicher auch Branch-Coverage vorweisen könne. Größer 99% und so. Aus eigener Erfahrung weiß ich, dass selbst 100% C1-Coverage nicht heißt, dass die Software nicht vor Fehlern strotzen kann. Das hängt nämlich vom Tester ab. Wenn der seine Testfälle so lange passend frickelt, bis alles durchgewunken wird, hat er zwar sein Coverage-Ziel erreicht, aber noch lange nicht nachgewiesen, dass die Software tut, was sie soll.
Das Grundproblem ist hier meiner Meinung nach in den Prozessen und in der Einstellung der verantwortlichen Entwickler und Tester bei Boeing zu suchen. Erfahrungsgemäß passiert sowas immer dann, wenn man sich selbst überschätzt, zu wenig Zeit einplant, oder das Management Druck macht, weil es die nächste Rechnung schreiben will. Schade, weil vermeidbar!
