Wir von ITPower Solutions haben in einem Kundenprojekt ein medizintechnisches Gerät für die mechanische Herzunterstützung mithilfe von automatisierten Modul- und Systemtest abgesichert. In diesem sicherheitskritischen Umfeld gelten naturgemäß hohe Ansprüche an die Qualität und Zuverlässigkeit. Der Test von Komponenten und Gesamtsystem ist daher ein wichtiger Bestandteil des Entwicklungsprozesses und Qualitätsnachweises.
Das im Projekt entwickelte Herzunterstützungssystem bestand aus mehreren Modulen– Kommunikationsvermittler, Steuerrechner, Antriebe, Regelung (Subkomponente des Antriebs) und Ladegerät (Abbildung 1). Das Testobjekt kommuniziert mit seiner Umgebung über etwa 30 Hardware-Signale, 5 serielle Schnittstellen und 2 Busse (CAN und I²C). Die Teststrategie bestand darin, die verschiedenen Module einzeln, im Verbund und anschließend das System als Ganzes zu testen.
ContinoProva basiert auf einer Client-Server Architektur. Es integriert verschiedene Hard- und Softwarewerkzeuge für den automatisierten Test. Ein ideales Einsatzgebiet von ContinoProva sind Anwendungsfälle, bei denen bereits für den manuellen Test genutzte Tools in die Testumgebung eingebunden und weiterverwendet werden sollen. Dadurch können die Erfahrungen und das Know-how der Mitarbeiter zum Umgang mit den Tools weiterhin genutzt werden. Diese Architektur ermöglicht es, von einzelnen Benutzer- und Programmierschnittstellen zu abstrahieren und ein einheitliches Frontend zur Testspezifikation und Toolsteuerung zu verwenden. So kann der Benutzer über Toolgrenzen hinweg Tests spezifizieren und automatisch ausführen.
Während eines Testdurchlaufs mit ContinoProva werden gemäß der im Frontend definierten Testspezifikation schrittweise von einzelnen eingebunden Tools Dienste angefordert, z. B. Senden von Busbotschaften durch das Buswerkzeug oder Lesen von Signalen am Ausgang des Testobjekts durch das Oszilloskop. Es können eine beliebige Anzahl von Servern, Services und Tools eingebunden werden. Die Client-Server Architektur erleichtert den Signalaustausch zwischen und die Steuerung von angebundenen Tools. Die lokale Verteilung der Tools bietet erhebliche Vorteile hinsichtlich der Performanz bei der Testausführung (Abbildung 2).
Diese Architektur setzt voraus, dass die angebundenen Tools über entsprechende Application Program Interfaces (API) verfügen. ContinoProva setzt keine bestimmte Form der Testspezifikation voraus. Es ist in der Lage, die durch die Testspezifikation definierten Testschritte sequenziell zur Ausführung zu bringen und die Ausführungsergebnisse wieder in den Testablauf einfließen zu lassen.
ContinoProva Client und Server bestehen jeweils aus einzelnen Softwaremodulen. Der Client enthält ein Modul genannt Test Control, das die Daten des aktuellen Testschritts der Testspezifikation entnimmt und daraus eine ausführbare Code-Einheit generiert. In einem weiteren Modul namens Test Execution werden die an einem bestimmten Testschritt beteiligten Tools koordiniert.
Die Trennung von Test Control und Test Execution ermöglicht eine leichtere Anpassung der Implementierung an verschiedene Testspezifikationsarten. Dem Modul Test Execution steht serverseitig das Modul Execution Provider gegenüber. Um eine leichte Austauschbarkeit von Tools zu ermöglichen, wird die Kommunikation mit der jeweiligen Tool-API in ein Extramodul namens Tool Adapter eingekapselt.
Das Testen der Module des Testobjekts erforderte die Aufteilung des zu prüfenden Gesamtsystems in funktional sinnvolle Einheiten. Um die Funktionalität eines Moduls testen zu können, wurden seine Schnittstellen an die Testumgebung angebunden und ein Modell erstellt, das die Umgebung des Testobjektes mit hinreichendem Abstraktionsgrad simuliert.
Zur Anbindung der zu testenden Module an ContinoProva wurden Adaptoren, sogenannte Services, entwickelt. Sie integrieren externe Werkzeuge in ContinoProva und stellen deren Funktionen wie z.B. das Stimulieren oder Lesen von Schnittstellen in Form von Services zur Verfügung. Durch die Integration von externen Werkzeugen über Services war es möglich, in kurzer Zeit modulspezifische Adaptoren mit wenig Aufwand zu implementieren und anzupassen. Auf diese Weise stand eine flexible Testumgebung zur Verfügung, die für mehrere Module einsetzbar war.
Ein weiterer Vorteil bestand darin, eine Testspezifikation in verschiedenen Testumgebungskonstellationen mit unterschiedlichen externen Werkzeugen wiederverwenden zu können. Dies ist durch überlegte Definition der Schnittstellen und geschickte Strukturierung und Schachtelung von generischen und toolspezifischen Services möglich. In diesem Fall wurden für die CAN-Buskommunikation unterschiedliche Bussimulatoren eingesetzt, die CAN-Nachrichten lesen und schreiben.
Für den Systemtest kamen ein Hardware-in-the-Loop-System (HiL) der Firma dSpace und weitere externe Komponenten wie z.B. PCAN und steuerbare Relais-Boxen zum Einsatz. Diese wurden über Services an ContinoProva angebunden, so dass hier die ContinoProva Benutzeroberfläche als Frontend für die Testspezifikation verwendet werden konnte. Wie beim Modultest wurden Funktionen, die im Umgebungsmodell hätten simuliert werden müssen, in ContinoProva Services umgesetzt. Als wertvoll erwies sich an dieser Stelle die in ContinoProva implementierte Akku-Simulation für verschiedene Ladezustände und andere Akku-Eigenschaften. Dadurch konnte die Testlaufzeit erheblich reduziert und Testressourcen gespart werden.
Es zeigte sich, dass die Service-Implementierung weniger Aufwand verursachte als die Entwicklung bzw. Erweiterung des Umgebungsmodells in der HiL-Umgebung und somit die effizientere Lösung darstellte. Teile des Umgebungsmodells wurden in modular aufbaubaren Services mit leicht verständlicher Programmiersprache (C# und .NET) entwickelt. Die Testumgebung war somit nach kurzer Zeit produktiv im Einsatz. Die Kapselung werkzeugspezifischer Adaptoren in Services ermöglichte zudem eine einfache Testbarkeit, eine hohe Wiederverwendbarkeitsrate von Testartefakten sowie eine einfache Fehleranalyse. Für das Projekt wurden insgesamt ca. 10 Services zur Implementierung von Schnittstellen und Simulation des Umgebungsverhaltens entwickelt.
Feedback der Produktentwickler: Die Entwickler und Tester von Berlin Heart profitierten von der einfachen Bedienbarkeit und Verständlichkeit des Testspezifikationsformats, so dass nur eine kurze Einarbeitungszeit notwendig war, um mit dem produktiven Testen zu starten.
Sinnvolles Ziehen von Grenzen zwischen Modul und Umgebung: Eine genaue Analyse des Moduls und seiner Schnittstellen ist erforderlich, um die Grenzen zwischen Modul und Umgebung sinnvoll zu setzen. Dies beeinflusst Anzahl und Arten der Außenschnittstellen des Testobjekts.
Simulation vs. Implementierung: Eine Testautomatisierung wirft zwangsläufig die Frage auf, welche Teile des Testsystems simuliert und welche durch implementierte (reale) Systeme umgesetzt werden sollen. Die Antwort darauf muss berücksichtigen, dass durch implementierte Systeme verstärkt Querwirkungen auftreten können. Dies erschwert unter Umständen die Ursachenanalyse bei Auftreten von Fehlern.
Erst Modultests, dann sinnvolle Integrationstests: Das Testen auf verschiedenen Teststufen ist notwendig, um Fehler frühzeitig aufdecken und lokalisieren zu können. Den Integrationstests sollte eine wohlüberlegte, dem Testziel und Testobjekt angepasste Integrationsstrategie zugrunde liegen.
Ich bin Ihr vertrieblicher Ansprechpartner und berate Sie gerne zu allen Fragen rund um unsere Dienstleistungen und Produkte! Melden Sie sich oder vereinbaren Sie einfach einen Termin für ein kostenloses Beratungsgespräch.
Sebastian Stritz
E-Mail: sebastian.stritz@itpower.de
Telefon: +49 (0)30 6098501-17