Hallo Herr Dr. Kuhn, wann haben Sie sich persönlich zum letzten Mal über einen Softwarefehler geärgert?

Gerade eben. Wir wollten bei einem Kundengespräch Simulationsmodelle nutzen, die aber nicht richtig funktioniert haben. Letztlich war es ein Schnittstellenproblem, das wir vor allem deshalb als ärgerlich empfunden haben, weil es Zeit gekostet hat.

Sie sind zuständig für das Software Quality Lab »360° Diagnostics Center« des Fraunhofer-Institut für Experimentelles Software Engineering IESE. Könnten Sie mit Ihrer Arbeit bei solchen Problemen Abhilfe schaffen?

Ja, natürlich. Aber Schnittstellenproblematiken gehören nicht zum Schwerpunkt unserer Aufgaben. Bei uns geht es beispielsweise darum, die Architektur eines bestehenden Systems zu analysieren, um ein Re-Engineering durchzuführen.

Systeme sollen fit gemacht werden, um weitere Komponenten problemlos integrieren zu können.

Richtig, wir wollen zu einer »continuous integration« kommen, um die künftige Qualität eines Programms zu steigern. Dafür muss aber nicht das Gesamtsystem neu gebaut werden. Es reicht, wenn beispielsweise alle zehn Sekunden automatisiert Tests laufen, um zu prüfen, ob eine vorgenommene Änderung wirklich nur das Geplante bewirkt. Diese Vorgehensweise wollen wir auch im Bereich eingebetteter Systeme etablieren.

Um derartige Tests durchzuführen, müssen Unternehmen Sie an ihre Systeme aber auch ranlassen.

Wir arbeiten in einem sensiblen Feld, aber den Unternehmen ist bewusst, dass derartige Tests notwendig sind. Außerdem verfügt das Fraunhofer IESE über genug Renommee und Referenzen, um mit dieser Aufgabe betraut zu werden.

Es geht um Tests beispielsweise für die Steuerung von Fahrzeugmotoren.

Die Funktionen von Steuergeräten in einem Fahrzeug übernehmen Programme, die mittlerweile ausgesprochen komplex sind. Sie müssen einerseits einwandfrei und hoch zuverlässig arbeiten. Andererseits können Sie die Software nicht einfach testen. Denn es geht nicht nur um die Funktionssicherheit der Software an sich, sondern auch um das Zusammenspiel mit den physikalischen Prozessen, die sie steuern. Systeme wie diese können also nur geprüft und nachhaltig optimiert werden, wenn auch die Umgebung – in diesem Fall das fahrende Fahrzeug – mit einbezogen beziehungsweise simuliert wird. Künftig werden wir hier sogar noch einen Schritt weitergehen. Dann werden Programme in einem Fahrzeug unter Umständen kaum noch Entscheidungen treffen. Stattdessen wird die Infrastruktur – also die Straße und der Schwarm anderer Fahrzeuge – intelligent agieren und Entscheidungen weitergeben. Um das zu testen, brauchen wir eine neue Qualität in der Prüfumgebung.

Daran arbeiten Sie schon heute?

Ja, allerdings stehen wir erst am Beginn dieser Entwicklung. Generell gilt, dass das Testen und Optimieren von Software anhand unterschiedlicher, realistischer Situationen immer bedeutender geworden ist …

... ein Notbremsassistent muss bei Regen oder Nebel genauso funktionieren wie bei Stau oder extremen Straßenverhältnissen. Sie brauchen also variable Testumgebungen für die Simulation.

Genau das bietet unser Software Quality Lab. Wobei wir eigentlich von Simulatorkopplungen sprechen sollten, statt von einzelnen Simulationen. Die Systeme sind so kompliziert, dass ein einzelner Simulator ihnen kaum mehr gerecht werden kann. Wir brauchen also einen Simulator für das Getriebe, einen anderen für das Fahrzeugnetz und einen, der die Ausführplattform, also den Prozessor simuliert – und das unter unterschiedlichsten Verhältnissen. Diese Simulationsumgebungen vollständig zu erstellen ist eine der zentralen Kompetenzen des 360° Diagnostics Center.

Was sind weitere Kompetenzschwerpunkte?

Zum einen Sicherheitskonzepte. Nehmen wir an, eine klassische Fernsteuerung für eine Hebebühne soll durch eine Smartphone-App ersetzt werden. Wir können feststellen, ob diese neuartige Steuerung absolut zuverlässig und auch im Fehlerfall zuverlässig funktioniert, so dass die Maschine niemanden Schaden zufügt.

Was meinen Sie mit: »Im Fehlerfall zuverlässig funktioniert«?

Es ergibt wenig Sinn, wenn sich ein System im Zweifelsfall einfach komplett abschaltet. Bei der Hebebühne kann ein Mensch darunter arbeiten und eingeklemmt sein. Ein anderes Beispiel ist ein ESP, dass bei einem Ausfall trotzdem nicht zu einem Versagen des gesamten Fahrzeugs führen darf. Wir brauchen eine »graceful degradation«, also das Aufrechterhalten der einzelnen, verbundenen Systeme auch bei unerwarteten Ereignissen oder Teilausfällen. Aber wir müssen eben sicher sein, wie sich – in unserem Beispiel das Fahrzeug oder auch autonomous transport vehicles in Fabrikhallen – dann verhalten.

Fahrzeuge und ihre Software scheinen ein Schwerpunkt der Arbeiten des 360° Diagnostics Center zu sein?

Automobile und Nutzfahrzeuge wie zum Beispiel Landmaschinen sind in der Tat ein wichtiger Faktor. Das liegt vielleicht auch daran, dass hier – im Gegensatz zu vor 20 Jahren – Assistenzsysteme und damit auch der Faktor Software marktentscheidend geworden sind.

Dabei geht es aber vermutlich nicht nur um Tests, sondern auch um Forschungen?

Eine Hauptkategorie ist der digitale Wandel in der Produktion. Also das, was wir unter Industrie 4.0 subsumieren. Hier leiten wir unter anderem nationale Referenzprojekte und erstellen eine Open Source Middleware, die zum Beispiel Komponenten für digitale Zwillinge bereitstellt. Es geht aber auch um eine durchgängige Digitalisierung. Damit meine ich die Möglichkeit, Geräte unterschiedlicher Hersteller miteinander zu verknüpfen und die Kompatibilität der unterschiedlichen Datenmodelle der Hersteller zu gewährleisten. Ein konkretes Ziel ist dabei beispielsweise eine automatische Synchronisierung der Wartungszyklen von Maschinen: Wir wollen erreichen, dass eine Maschine weiß, dass sie demnächst gewartet werden muss und mit anderen Maschinen einen sinnvollen Wartungszyklus aushandelt. Ein zweiter, prägender Forschungsaspekt ist der Bereich »sichere KI«. Wir gehen der Frage nach, wie Systeme, die mithilfe künstlicher Intelligenz arbeiten, auch tatsächlich sicher laufen.

Normalerweise führt man in so einem Fall eine Analyse des Systems durch und erzeugt Zustände, die zu unerwünschtem Verhalten führen könnten.

Bei traditionellen Systemen ist das immer noch der gängige Modus. Aber bei einer KI geht das nicht mehr, weil es zu viele Zustände geben kann, als das wir sie vorhersehen könnten. Deshalb forschen wir nach weiterführenden Ansätzen, um KI-basierte Systeme abzusichern.

Sie beschäftigen sich auch intensiv mit adaptiven Systemen.

Es geht dabei um die Frage, wie Systeme sich zu bestimmten Zeiten dynamisch miteinander verbinden können. Beispielsweise, um eine bestimmte Aufgabe gemeinsam zu lösen und sich danach wieder mit anderen Systemen zu verbinden. Diese dynamischen Allianzen brauchen unter anderem einen sicheren Datenaustausch. Sie müssen einander zuverlässig »verstehen«.

Glauben Sie, dass Sie auch in fünf oder zehn Jahren an Aspekten wie diesen arbeiten werden?

Natürlich werden sich die Anforderungen, die etwa mit Industrie 4.0 verbunden sind, weiter ausdifferenzieren. Aber wir schauen auch heute schon über den Horizont und bereiten uns beispielsweise darauf vor, Fragen zur autonomen Produktion zu beantworten. Ziel ist eine Fabrik, bei der im Idealfall nur noch das Endprodukt definiert ist und die selbst entscheidet, wie sie zu dem gewünschten Ergebnis kommt. Und das alles unter der Prämisse sicher und vorhersagbar zu arbeiten. Die Aufgaben werden also nicht weniger und definitiv auch nicht weniger kompliziert werden.

(aku)