Nicht kapitulieren, sondern automatisieren

Es ist überall das Gleiche: Wer hohe Anforderungen an seine Produkte und auch an die integrierte Software zu erfüllen hat, muss einigen Aufwand in die Entwicklung stecken. Das gilt für die Luft- und Raumfahrt genauso wie für die Energie-, Automotive- und Automatisierungstechnik wie auch für die Medizintechnik-Branche. Wenn aber alle mit den gleichen Problemen zu kämpfen haben, liegt der Gedanke nahe, ein branchenübergreifendes und modellbasiertes Vorgehen zu entwerfen, mit dem sich insbesondere Embedded Systems sicher entwickeln lassen.

Dieses Ziel hatte sich die nationale Innovationsallianz „Softwareplattform Embedded Systems 2020“ gesetzt und bereits eine Sammlung von integrierten Modellierungstechniken erstellt. 21 Partner aus Wirtschaft und Wissenschaft haben dabei ihre unterschiedlichen Sichten und Erfahrungen ausgetauscht und die Lösungen definiert.

Ein Teilprojekt ist auch im Bereich Medizintechnik angesiedelt. Die Partner haben hier die Software-Fragen anhand einer Fallstudie betrachtet: Sie arbeiten bis Januar 2012 an der Entwicklung eines Notfallsystems für den Heimgebrauch. Es besteht aus mehreren körpernahen und stationären Sensoren, also einem Body Area Network, kurz BAN. Gemeinsam erkennen diese beispielsweise einen Sturz oder unregelmäßige Herzfunktionen und melden den Vorfall an eine Notrufzentrale.

Zur Sicherung der Qualität solch eines Systems, in dem zahlreiche Komponenten zusammenspielen, sind ausgiebige Tests notwendig, die vor allem aus Kostengründen am besten automatisch entworfen, ausgeführt und dokumentiert werden. Da es sich bei dem Notfallsystem um ein dezentrales und verteiltes System handelt, stellt das Testen aber eine Herausforderung dar.

Nun ist so eine Aufgabe zwar seit der Zusammenschaltung der ersten Computer zu einem Netzwerk bekannt. Trotzdem gab es bisher keine zufriedenstellende Lösung. In gemeinschaftlicher Arbeit entwickelten Mitarbeiter des Fraunhofer First, von IT Power Consultants und Tecnet daher eine Methodik für den effizienten Test verteilter Systeme.

Dabei steht die Integration der Systeme im Mittelpunkt. Denn selbst wenn jedes für sich genommen fehlerlos erscheinen mag, ist die reibungsfreie Zusammenarbeit damit noch nicht garantiert. Die Systeme können auf so vielfältige Art und Weise miteinander kommunizieren, dass das Testen aller Möglichkeiten eine schier unlösbare Aufgabe zu sein scheint. Das war einer der Beweggründe, die die Entwickler dazu brachten, ein neues Vorgehen zu beschreiben, mit dem man automatisch eine repräsentative Menge von Testfällen für ein verteiltes System entwerfen kann.

Ausgangspunkt für die automatische Generierung der Testfälle ist ein Modell. Modellierungsexperten leiten es aus den Anforderungen ab, die für das Produkt – hier das Notfallsystem – beschrieben wurden. Modellbasiertes Testen (MBT) ist heute gängige Praxis, da es schneller zu Ergebnissen führt als koventionelle Verfahren wie manuelles Testen oder Keyword-Driven-Testing. Nur gab es bisher viele Einschränkungen für MBT, sobald es um verteilte Systeme geht.

Im Modell der Projektpartner wird für das MBT nun zunächst festgelegt, wie umfangreich die Tests sein müssen und welche Mittel verwendet werden. Das hängt von der Risikobewertung der Komponenten ab. Eine geeignete Strategie entwickelt ein Mensch – der Testmanager.

Diese Strategie wird für den automatisierten Teil des Testsystems, den so genannten Testfallgenerator, hinterlegt. Solange es keine realen Testergebnisse gibt, werden manuell erzeugte Daten als Basis genommen. Daraus entsteht eine abstrakte Testfallspezifikation: Darin sind alle Details beschrieben, die für einen Test relevant sind.

Um ein Testframework – also das Herzstück beim automatisierten Testen – damit zu füttern, muss die Beschreibung noch in ein Testskript übersetzt werden. Da es eine Vielzahl von Frameworks gibt, die mit unterschiedlichen Skriptsprachen arbeiten, geht man hier stufenweise vor und erstellt zunächst nur eine Testfallspezifikation, die alle Schritte durchläuft.

Das BAN wird nach diesem Verfahren derzeit mit zwölf Sensorknoten getestet. Ob sich diese Art des Testens skalieren, also auf größere Systeme übertragen lässt, soll noch untersucht werden. Anwendbar wäre ein entsprechendes Modell für verteilte Systeme im Automobil, für deren Tests derzeit ein sehr hoher Aufwand betrieben wird.

Auch für massiv-verteilte Systeme, die aus mehr als hundert Einzelsystemen bestehen, könnte der neue Ansatz interessant sein. Angewendet werden solche Lösungen bereits zur Waldbranderkennung in den USA. Erdbebenfrühwarnsysteme sind ein weiterer Einsatzbereich – ebenso das vernetzte Klinikum, in dem zum Beispiel Röntgengeräte ihre Aufnahmen direkt in die Patientenmappe übertragen. Auch hierfür ist das exakte Zusammenspiel aller Geräte vom Sensor bis zum Server erforderlich, wie es am Beispiel des BAN derzeit untersucht wird.