Freitag, 20.09.2019
 
Seit 05:05 Uhr Informationen am Morgen
StartseiteComputer und KommunikationFehlersuche mit System07.07.2007

Fehlersuche mit System

"Computer Aided Verification" spürt Programmierfehler auf

<strong>In Berlin tagen zur Zeit rund 300 Experten einer Informatik-Disziplin, denen vermutlich nie die Arbeit ausgehen wird. Denn die Wissenschaftler beschäftigen sich mit der computergestützten Prüfung von Hard- und Software. Ihr Ziel: Programmierfehler systematisch zu verhindern.</strong>

Von Wolfgang Noelke

Fehler in digitalen und programmierten Minisystemen können gravierende Folgen nach sich ziehen. (AP)
Fehler in digitalen und programmierten Minisystemen können gravierende Folgen nach sich ziehen. (AP)

An der extrem nüchtern gestalteten Webseite sieht man es, dass die Veranstalter der nicht zu werben brauchen. Für die 300 nach Berlin gereisten Entwickler von Hard und Software ist die Teilnahme an diesem Kongress Pflicht. Sie gehören quasi zum harten Kern und diskutieren seit Dienstag erstmals in Deutschland. Wolfgang Noelke hat die heute in Berlin endende Konferenz für uns besucht.

Das Ziel der zur 19. Internationalen Tagung für computergestützte Verifikation von Hard und Software nach Berlin gereisten mehr als 300 Wissenschaftler aus dem universitären und industriellen Bereich ist, diese Tagung überflüssig zu machen, denn sie diskutieren über die Herstellung fehlerfreier Hardware und Software. Doch sie kommen ihrem Ziel nur in kleinen Schritten näher. Klassischer Auslöser für diese Tagung war ein Konstruktionsfehler des ersten Pentium Prozessors:

"Interessanterweise war der Fehler nicht die Hardware, sondern die Software, nämlich ein kleines Programm, was benutzt wurde, um die Tabelle zu füllen, die als Tabelle dann in Silicon gegossen wurde, also in Chips gegossen wurde. In diesem Programm, das die Tabelle hat gab's einen Fehler."

Professor Dr. Holger Hermanns, Inhaber des Lehrstuhls für verlässliche Systeme an der Universität des Saarlandes erklärt, wie man solchen Fehlern auf die Schliche kommt:

"Vieles von dem, was hier gemacht wird, ist Code Mining. Heute Vormittag hatten wir eine Sitzung, da ging es darum, wie man Treiber, die zugeliefert werden zu Microsoft Windows, wie man daraus die Programmstruktur erzeugt, die man zu analysieren hat. Es geht also viel darum, irgendwelche Listen abzulaufen und die zusammenzufassen, denn man will nicht die ganze Liste sehen, sondern man will nur den Anfang oder das Ende sehen. Das sind typische Fragestellungen."

Fragestellungen, die bereits zu Beginn der Konstruktion einer Hardware gelöst sein müssten - und wenn dies nicht der Fall ist, dann sollte wenigstens das Betriebssystem auf die möglichen Eventualitäten abgestimmt sein, wie in diesem Beispiel:

"In so einem Laptop hat man ein Betriebssystem und das guckt hin und wieder nach, ob es ein paar neue Töne abspielen muss und es guckt hin und wieder nach, ob jemand den USB Stick herausgezogen hat. Und wenn das in einer schlechten Reihenfolge gefragt wird, dann kann es sein, dass wenn man den USB Stick zu einem Zeitpunkt heraus zieht, wo man ihn vielleicht doch nicht hätte rausziehen sollen - was man aber nicht weiß - dass das System einfach stehen bleibt. Im Programmkode kann man das dann erkennen. Aber das schwierige ist, solche Programmkodes sind sehr kompliziert. Das heißt, die Softwareentwickler, die dann daran arbeiten, das sind ja Gruppen von 20 Leuten oder 100 Leuten, die kriegen das nicht raus und dafür wird dann hinterher nachgeschaut. Das ist an Debugging, ein sehr hochwertiges Debugging."

Die für die 300 Wissenschaftler interessanten Themen dieser Tagung sind die Eigenschaften und das Zusammenwirken komplexer Systeme, wie beispielsweise in der Verkehrstechnik und im Verkehrsmanagement bereits vorhanden:

"Im Moment heiß sind eingebettete Systeme, also die Software, die in Zügen, im Auto steckt. Das sind Systeme, wo Komponenten ausfallen können, die dann eventuell repariert werden oder nicht. Aus Messungen nehmen wir dann die so genannten Ausfallwahrscheinlichkeiten über die Zeit. Das ist sozusagen eine Kurve, wo die Zeit aufgetragen ist, mit welcher Wahrscheinlichkeit etwas ausfällt. Und das baut man dann zusammen, mit vielen einzelnen Komponenten. Sie können es sich vorstellen: Wenn sie ein Auto haben, dann können Sie sagen: das linke Vorderrad kann mit einer gewissen Wahrscheinlichkeit kaputtgehen, das Reserverad wahrscheinlich nicht. Vielleicht altert es aber auch und ist irgendwann hin und so weiter. Und aus diesen ganzen Teilen baut man dann die Wahrscheinlichkeit zusammen, dass dieses Auto die nächsten 5000 Kilometer überlebt. Wir machen daraus mathematische Modelle. Wenn Sie wollen, kann man das simulieren, aber am Ende sind es nun Matrizen, die wir durch unsere Rechner jagen, um Zahlen auszurechnen."

Die Ergebnisse garantieren, dass Software und Hardware unter allen nur möglichen Bedingungen zusammen arbeiten, beispielsweise, dass die Steuerungselemente in Zügen mit der gesamten Signaltechnik zusammenarbeiten. Bei der Konstruktion von Komponenten wäre es ein Fehler, zu glauben, dass eine unter Höchstbelastung einwandfrei arbeitende Komponente auch unter niedriger Belastung problemlos funktioniert. Mit einer solchen analogen Herangehensweise würden Entwickler digitaler Komponenten latente Fehlerquellen einbauen. Darin unterscheiden sich digitale von physikalischen Systemen:

"Wenn man ein physikalisches System hat, wie zum Beispiel einen Zug oder ein Auto, und man fährt das Auto mit 20 Stundenkilometern gegen die Wand und man fährt mit 50 Stundenkilometern gegen die Wand, sollte man meinen, dass bei 50 Stundenkilometern mehr kaputt ist als bei 20 Stundenkilometern. Man sollte auch meinen, dass wenn der Airbag bei 20 ausgelöst hat, dann würde auch bei 50 auslösen. Oder wenn er, sagen wir mal bei 70 ausgelöst hat und bei 20, dann würde er bei allen Geschwindigkeiten dazwischen auch auslösen. Aber das kann eventuell nicht der Fall sein, weil diese Rechner, die rechnen ja nur mit Nullen und Einsen. Es ist nicht stetig. Er kann es sein, dass für bestimmte Geschwindigkeiten, weil irgend ein Sensor falsch programmiert ist, der Airbag nicht explodiert. Und das gilt genauso für den Zug. Und das ist einfach ein Fehler im Programm."

Ganz vermeiden ließen sich solche Programmfehler wohl auch künftig nicht, aber minimieren, sagt Professor Hermanns, der, wie seine anderen Kollegen auch, in den Messergebnissen regelmäßig menschliche Faktoren entdeckt:

"Wenn man das dann klassifiziert und rauskriegt, dass zum Beispiel Software, die am Freitag geschrieben wird mehr Fehler hat, als die, die am Dienstag geschrieben wird, das ist dann schon interessant."

Das könnte sie auch interessieren

Entdecken Sie den Deutschlandfunk