Software

Test Driven Design in der Mechatronik – Teil 1

Milan Marinov, Jivka Ovtcharova, Ramez Awad Karlsruhe

Abbildung 1 zeigt die Einbindung der Test Driven Development Methodik (TDD) im V-Modell.
In der Entwicklung mechatronischer Systeme spielen Tests eine wichtige Rolle, was auch die VDI-Richtlinie 2206 (V-Modell) widerspiegelt. Tests werden auf verschiedenen Ebenen durchgeführt. Die Testentwicklung erfolgt selten methodisch, sondern es werden meist Daten aus einer Vielzahl von Quellen wie etwa Anforderungsspezifikation oder Lastenheft herangezogen. Diese Quellen sind nicht immer strukturiert, was eine fehlerfreie Interpretation erschwert. Die Testentwicklung wird zudem meist intuitiv durchgeführt und erfordert ein hohes Maß an Kreativität von dem Verantwortlichen. Aus diesen Gründen sind Testspezifikationen oft lückenhaft und Fehler werden später entdeckt, als es durch eine lückenlose Testspezifikation möglich gewesen wäre. Dadurch entstehen unnötige Entwicklungskosten und die Markteinführung wird verzögert.

In diesem Artikel werden die Grundlagen zu einer testgetriebenen Entwicklung mechatronischer Systeme dargestellt. Tests werden mit Hilfe der Funktionsstruktur des mechatronischen Produkts entwickelt, um so die Komponenten- und Testentwicklung besser zu verzahnen und die Objektivität der Testerstellung zu steigern. Großer Vorteil dabei ist, dass die Funktionsstruktur als eine rechnerverarbeitbare Spezifikation des mechatronischen Produkts über Abteilungs- und Unternehmensgrenzen hinweg verwendet werden kann, was zu einer besseren Verteilung der Verantwortlichkeiten in der verteilten Produktentwicklung führt.

Anzeige

Es wird zudem eine Umgebung vorgestellt, welche eine testgetriebene Produktentwicklung unterstützt. Wesentliches Merkmal der Umgebung ist die Kopplung mit bestehenden Werkzeugen wie Catia und Altium, so dass die vertraute Arbeitsumgebung des Entwicklers optimal verwendet werden kann. Die Nutzung der Umgebung wird anhand von Industrieszenarien erläutert. Die Testgetriebene Softwareentwicklung (engl. Test Driven Development, kurz TDD) ist ein fester Bestandteil der agilen Softwareentwicklungsmethodik »Extreme Programming« (XP) und wurde im Rahmen dieser populär. Die Methodik soll helfen, Risiken bei der Softwareentwicklung, wie zum Beispiel einer hohen Fehlerrate, zu reduzieren, indem bei jeder Änderung sowohl aus der Perspektive des Programmierers als auch des Kunden getestet wird. XP besteht aus den sich wiederholenden, vier grundlegenden Arbeitsschritten: Programmieren, Testen, Zuhören und Designentwurf. [1] Hier wird dem Testen besondere Aufmerksamkeit geschenkt.

Es wird in XP zwischen Modultest (Unit-Test) und Systemtest unterschieden. Die Modultests werden von den Programmierern selbst geschrieben, um sich zu vergewissern, dass die einzelnen Module einer Funktion richtig programmiert wurden. Sie beziehen sich auf die kleinsten Programmeinheiten. Die Systemtests dagegen sollten vom dem Kunden selbst beziehungsweise in deren Auftrag geschrieben werden, um sich zu überzeugen, dass eine Funktion als ganzes so arbeitet wie sie es soll. [1] Da sie vom Auftraggeber definiert wurden, können Sie als Abnahmetest für die Vertragserfüllung herangezogen werden. Es ist wichtig, dass sie die Sprache des Kunden sprechen und von Ihm geändert und erweitert werden können.

Beck [1] vertritt die Auffassung, dass es unmöglich sei »absolut alles zu testen, wenn die Tests nicht genauso kompliziert und fehleranfällig wie der Code werden sollen.« Testen soll daher effizient erfolgen. Zum Beispiel ein Code, der sich in der Praxis als fehlerfrei gezeigt hat, benötigt kein so aufwändiges Testen wie Code, der zum ersten Mal dem Kunden ausgeliefert wird.

TDD lässt sich jedoch auch außerhalb von XP für andere Entwicklungsmodelle einsetzten. Die Grundidee bei TDD besteht darin, vor der Implementierung einer Funktion zuerst die Testfälle zu erstellen, die das korrekte Verhalten dieser abprüfen sollen und danach erst die gewünschte Komponente zu programmieren. Daher wird das Verfahren auch als Test-First Ansatz bezeichnet. [4] Hintergrund für TDD war die Erfahrung, dass Software in der Praxis viel zu wenig getestet wurde, was zu vielen Fehlern und teuren Fehlerbehebungskosten führte. [1]

Vor Beginn der eigentlichen Programmiertätigkeit erstellt der Programmierer für das zu programmierende Modul die dazugehörigen automatisierten Unit-Tests. Das Modul wird anschließend programmiert und zuerst gegen den Unit-Test getestet. Der geschriebene Code wird solange verbessert (Refactoring) bis die Unit-Tests erfolgreich absolviert werden. Durch die häufigen Tests erhält der Programmierer ein ständiges, unmittelbares Feedback zur Qualität seines Codes. Sind die Unit-Tests erfolgreich durchlaufen worden, gibt der Erfüllungsstand der Systemtests einen Einblick zum Projektstatus und -Fortschritt. Die Systemtests werden erst zu Ende des Projekts zu hundert Prozent erfolgreich durchlaufen. [4]

Durch die häufigen Tests wird die funktionale Qualität des Codes zur Funktionalität und Fehlerfreiheit gesichert. Durch das Refactoring des Codes wird das Programm immer in einer einfachen Form gehalten und somit die strukturelle Qualität gesichert. Die strukturelle Qualität bezieht sich auf das Design und die Codestruktur und ermöglicht eine problemlose Weiterentwicklung und Wartbarkeit.

Durch die Anwendung von TDD wird das Testen zu einem festen und zentralen Bestandteil im Entwicklungsprozess. Die Integration von TDD in das V-Modell zeigt Abbildung 1. Ausgehend vom Systementwurf, veranlasst jede Spezifikationsinstanz den Entwurf der Testfälle, die notwendig sind um bei der Absicherung das Vertrauen zu erlangen, dass die Anforderungen durch das Produkt erfüllt und eingehalten werden.

Durch den Einsatz von TDD werden die Testfälle tatsächlich geschrieben, was bei klassischen Vorgehensmodellen nicht immer der Fall ist. Die Testfälle stellen sowohl eine Baseline zu den Anforderungen als auch eine Dokumentation des entwickelten Systems dar. Ein Status über den aktuellen Projektstand und -Fortschritt auf Komponentenebene ist damit immer möglich. Das Projektmanagement des Auftraggebers erhält einen Einblick in die Qualität weit bevor die Steuergeräte vom Lieferanten übergeben werden. Eskalationsmaßnahmen sind somit viel früher möglich. Zwischen dem Lieferant und dem Auftraggeber können die Testfälle zur Kommunikation über die zu entwickelnden Komponenten benutzt werden. Anforderungen können an konkreten Beispielen geklärt werden.

Spezifikationsprobleme können früher als bisher erkannt werden, da jeder Entwicklungsschritt durch mindestens einen Testfall abgesichert wird. Probleme werden früher bei der Entwicklung erkannt und behoben. Unter Annahme der zehner Regel für Problembehebungskosten, fallen die Kosten geringer aus. Ferner berücksichtigt die Anwendung von TDD die Tatsache, dass Qualität nicht nachträglich in ein System hineingetestet werden kann. [6]

Es ist ersichtlich, dass die Qualität des Systems von der Qualität der Tests abhängt. Eine große Herausforderung besteht darin, Testfälle zu spezifizieren, die möglichst alle Eingabeparameter der Funktion überprüfen. Mangelnde oder unklare Arbeitsteilung zwischen Entwicklung und Testerstellung vermindert die Qualität der Tests: Fehlinterpretationen der Anforderungen durch den Entwickler resultieren in falsche Tests, beziehungsweise falsche Umsetzung der Anforderungen des Kunden. [6] Die Intuition und Erfahrung der Beteiligten stehen in TDD bei der Erstellung der Testfälle im Vordergrund. Diejenigen Personen, die das ursprüngliche System entwickelt haben, nehmen in der Praxis oftmals nach einer gewissen Zeit andere Aufgaben wahr, beziehungsweise können das Unternehmen verlassen. Somit geht das Wissen über ein entwickeltes System verloren, da eine explizite, produktlebenszyklusorientierte Dokumentation dieses Wissens nicht existiert.

Mit zunehmender Projektgröße und damit auch einer größeren Anzahl an beteiligten Personen am gesamten Entwicklungsprozess ist deswegen eine verbindliche Dokumentation des Wissens unumgänglich. Besonders vor dem Hintergrund einer Weiterentwicklung eines mechatronischen Systems im Kontext mehrerer nachfolgenden Produktgenerationen [3], ist eine Ergänzung des TDD um eine explizite Darstellung des Wissens über dem erstellten System notwendig.

Wie ein Anwendungsbeispiel zeigt, erzeugen Photovoltaikanlagen umweltfreundlich elektrischen Strom – und das ohne Lärm, Abgase oder Verschleiß. Die Photovoltaikanlage aus Abbildung 2 hat einen jährlichen Ertrag von circa 1.300 MWh. Allerdings stellt die Überwachung und Steuerung einer Solaranlage ohne die entsprechende Automatisierung eine Herausforderung dar. Fernüberwachungssysteme, wie sie beispielsweise von der Firma Iplon GmbH hergestellt werden, schaffen in diesem Bereich eine Abhilfe. Solche Systeme melden und protokollieren die Erträge der Photovoltaikanlage, aber können auch zusätzliche, kundenspezifische Funktionen erfüllen. Das Fernüberwachungssystem des Herstellers sendet per Modem regelmäßig Statusmeldungen an einen zentralen Server, was ein schnelles Eingreifen im Störungsfall ermöglicht.

Die Benutzerschnittstelle des Photovoltaikanlagenmanagementsystems bildet das Portal, welches Funktionalitäten zur Überwachung, Bewertung und Verwaltung von Photovoltaik-Anlagen bereitstellt. Abbildung 4 zeigt die Ertragsüberwachung einer Solaranlage. Das Portal empfängt Daten wie Alarm-/Fehlermeldungen und aufgezeichnete Daten von Wechselrichtern, Zählern und Sensoren per GPRS oder Ethernet von dem Herzstück des Systems: Der Schaltschrank iBox Standard, beziehungsweise iBox Premium. Ein Überblick über das Photovoltaikanlagenmanagementsystem des Herstellers zeigt die Abbildung 3.

Der Schaltschrank aus Abbildung 5 dient zum Überwachen einer Photovoltaik Anlage mit integriertem Web-Server und Datenübertragung per GSM oder GPRS. Der Schaltschrank verfügt über ein Gateway, der das Mappen der Daten vom Wechselrichter mit RS 485 Schnittstelle auf die GPRS Schnittstelle ermöglicht. Die zentrale Komponente der iBox ist das iGate: Ein Linux-basiertes Steuergerät, welches von Iplon speziell für die Überwachung von Photovoltaikanlagen entwickelt wurde. Der Hauptunterschied zwischen iBox Standard und iBox Premium ist, dass Letztere ein zusätzliches IO-Modul besitzt. Das IO-Modul wird benutzt, um zusätzliche Sensoren und Aktoren analog oder digital an der iBox anzuschließen. Dadurch wird eine Reihe von neuen, kundenspezifischen Anwendungen ermöglicht.

Kundenspezifische Anwendungen werden meist durch zusätzliche Hardware (Sensoren, Aktoren) und Software (Skripts) umgesetzt. Ein Großteil des Aufwands bei der Entwicklung kundenspezifischer Anwendungen wird durch das Testen der Interaktion des Basisprodukts mit den Zusatzmodulen verursacht. Die hohe Anzahl an Kombinationen zwischen Software und Hardwarekomponenten erschwert insbesondere die effiziente Definition einer optimalen Testkonfiguration. An dieser Stelle wurde von Iplon ein erhebliches Einsparpotential erkannt. In Zusammenarbeit mit dem IMI wurde im Rahmen des EU-Projekts Importnet (EU Förderkennzeichen: FP6-2005-IST-033610) eine automatisierte, funktionsbasierte Unterstützung der Testkonfiguration als Ergänzung des TDD entwickelt und im Multi Domain Engineering Tool (MDET) integriert. -sg-


Literaturquellen

[1] Beck, Kent: Extreme Programming Explained: Embrace Change, Addisson-Wesley, Boston 2003

  1. G., Ein Beitrag zur Funktionsstrukturentwicklung innovativer Produkte, Dissertation RPK, Shaker Verlag, 2000
  2. M., Schubert, P., Funktionsorientiertes Change-Management, CADCAM Report, Dressler Verlag, Ausgabe 09/08, pp.40-43, 2008
  3. Andreas; Linz, Tilo: Basiswissen Softwaretest, 3. Auflage, dpunkt Verlag, Heidelberg 2005
  4. 2206, Entwicklungsmethodik für mechatronische Systeme, Düsseldorf, VDI-Verlag, 2004
  5. M.: Auswertung von Testergebnissen für die Vervollständigung von Testcases im Hinblick auf die testgetriebene Produktentwicklung anhand ausgewählter Beispiele, Diplomarbeit IMI, 2007

Institute for Information Management in Engineering (IMI), Karlsruhe Tel. 0721/608-6634, http://www.imi.uni-karlsruhe.de

Anzeige

Das könnte Sie auch interessieren

Anzeige

Software

Test Driven Design in der Mechatronik Teil 2

Milan Marinov, Jivka Ovtcharova, Ramez Awad KarlsruheIn der Entwicklung mechatronischer Systeme spielen Tests eine wichtige Rolle, was auch die VDI-Richtlinie 2206 (V-Modell) widerspiegelt. Tests werden auf verschiedenen Ebenen durchgeführt.

mehr...
Anzeige

Simulation

FluiDyna stärkt Altair

Altair hat die in Deutschland ansässige FluiDyna GmbH, ein auf NVIDIA CUDA und GPU-basierende Strömungsmechanik und numerische Simulation spezialisiertes Unternehmen, übernommen.

mehr...

IT-Solutions

Vereinfachter Konstruktionsprozess

Das neue Engineeringtool von Item ist intuitiv zu bedienen und vereinfacht den Konstruktionsprozess im Maschinen- und Betriebsmittelbau. Die Software unterstützt Anwender dabei von der 3D-Konstruktion über den CAD-Entwurf, die Montageanleitung und...

mehr...

Autonomes Fahren

Neue Simulationslösung von Siemens

Siemens hat auf dem Siemens U.S. Innovation Day in Chicago eine wegweisende Lösung für die Entwicklung autonomer Fahrzeuge angekündigt. Als Teil des Simcenter-Portfolios verringert die neue Lösung nicht nur den Bedarf an umfangreichen physikalischen...

mehr...

Newsletter bestellen

Immer auf dem Laufenden mit dem SCOPE Newsletter

Aktuelle Unternehmensnachrichten, Produktnews und Innovationen kostenfrei in Ihrer Mailbox.

AGB und Datenschutz gelesen und bestätigt.
Zur Startseite