Startseite > Medizintechnik > Systeme & Anwendungen > Den Robo-Arm über Ozeane hinweg testen

MedTech-Entwickung in globalen Teams

Den Robo-Arm über Ozeane hinweg testen

7. November 2023, 15:50 Uhr | Elizabeth Tran, Senior Test Automation Engineer, MedAcuity

Die Digitalisierung und Globalisierung verändert nicht nur die Medizintechnik ansich, sondern auch die MedTech-Entwicklung. Für die Remote-Steuerung eines Roboterarms bietet sich in geografisch verteilten Teams der Einsatz von RTI Connext mit einer Python-API an.

▶ Diesen Artikel anhören

Damit Entwicklungsprojekte in der Medizintechnik eine schnelle Time-to-Market erreichen, wird es in global agierenden Unternehmen und zwischen Entwicklungspartnern immer wichtiger, dass funktionsübergreifende Teams über große Entfernungen hinweg kooperieren und neue Angebote oder Funktionen testen können. Damit die Zusammenarbeit mit geografisch verteilten Teams wie geplant funktioniert, sind jedoch oft neue, intelligente Konnektivitätslösungen erforderlich, die mit der Präzision und dem Tempo der Innovation Schritt halten können. Parallel dazu erfordern moderne medizinische Geräte eine komplexe Konnektivität zwischen Sensoren, Aktoren, Kontrollsystemen und Schnittstellen. Sie müssen zur gleichen Zeit anspruchsvolle Anforderungen an Interoperabilität, Sicherheit und Zuverlässigkeit, Cybersicherheit und Leistung erfüllen.

Konnektivitäts-Framework für das Gesundheitswesen

Moderne Datenmanagement-Lösungen wie RTI Connext ermöglichen die Konvergenz von datengesteuerten Technologien und beschleunigen so die Entwicklung von vernetzten medizinischen Geräten. Connext basiert auf dem DDS-Standard und rationalisiert die Konnektivität komplexer und skalierbarer Systeme mit einem verteilten und Echtzeit-Software-Kommunikationsrahmen. Als Besonderheit bilden bei diesem Framework die Daten die Schnittstelle zu anderen Systemen und Anwendungen. Damit lassen medizinische Systeme und Subsysteme um einen virtuellen Datenbus herum entwerfen und dezentralisierte und modulare Architekturen entwickeln, die man an sich verändernde Anforderungen von Programmen und Produktlinien anpassen kann.

Projekt Remote Test eines medizinischen Roboterarms

Wie Connext in der Praxis funktioniert, zeigt ein Projekt mit MedAcuity - ein medizinischer Roboterarm ist aus der Ferne zu testen. Zunächst wurde ein nutzerdefiniertes Tool - der DDS-Emulator - mithilfe von Connext und der Connext Python API¹ entwickelt. Für die Connext Python API hatte sich das Unternehmen bewußt entschieden - wegen der ausführlichen Dokumentation und Beispielskripte, mit denen bereits viele der ersten funktionalen Skripte programmiert wurden. Connext enthält eine Fülle von Funktionalitäten für eine schnellere Entwicklung, so dass das Team bei MedAcuity mehrere Hardwarekomponenten zeitnah und automatisiert aus der Ferne testen konnte.

Entwicklung eines Testtools

Das Projekt besteht aus zwei medizinischen Roboterarmen, die in der Bauchchirurgie eingesetzt werden. Um sicherzustellen, dass das System wie geplant funktioniert, suchte man eine Möglichkeit, die Roboter, die Benutzerschnittstelle (UI), die Steuerungssysteme und das Videosystem immer wieder zu testen. Eine schwierige Aufgabe, denn das komplette System war nur an wenigen Standorten verfügbar, und die über verschiedene Standorte verteilten Entwicklungs- und Testteams hatten nur eingeschränkten Zugang zu den einzelnen Komponenten. Die Lösung lautete: Entwicklung eines DDS-Emulators, der im Wesentlichen als Basis für automatisierte Tests dienen sollte, wobei ungewiss war, ob der Zugang zur gesamten notwendigen Hardware zum benötigten Zeitpunkt gegeben wäre.

Das Team erhielt mit Connext eine Sammlung von Python-Beispielskripten, die sich bei der schnellen Entwicklung des DDS-Emulators sehr hilfreich erwiesen. Vorteilhaft war zudem, dass die Produkte von Connext unkompliziert und einfach zu bedienen sind. Die Python-API von Connext ist sehr umfangreich und bietet viele Methoden zur Implementierung und Anpassung des DDS-Emulators. Connext basiert auf dem OMG Data Distribution Service (DDS)-Standard und wird in der Medizinrobotik vor allem wegen seiner Fähigkeit eingesetzt, Echtzeitkommunikation über komplexe Systeme hinweg sicher zu verarbeiten.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Um sicherzustellen, dass der Roboter die notwendigen Funktions-, Sicherheits- und Leistungsanforderungen erfüllt, müssen zahlreiche elektromechanische und Steuerungsfunktionen gemessen und getestet werden. Bei der Entwicklung der Skripte für den DDS-Emulator zeigte sich schnell, dass sie sich auch zur Unterstützung bei der Ausführung von Testfällen eignen. Wenn es möglich wäre, die Nachricht direkt zu versenden, könnte das erwartete Verhalten überprüft werden, insbesondere in Situationen, die mit dem Gesamtsystem schwer zu reproduzieren sind. Treten beispielsweise Hardwarefehler auf, die der Roboterarm während der Bewegung melden muss, aber nicht kann, so könnten die Fehlermeldungen direkt an die Anwendung gesendet werden, die ihrerseits prüfen könnte, ob die Anwendung in den richtigen Fehlerzustand übergegangen ist.

Alles, was für die Kommunikation mit dem System benötigt wird, findet sich in den XML- und IDL-Dateien, die mit dem RTI Connext System Designer erstellt wurden. Mit dem RTI Code Generator ist es möglich, die IDL-Datei in eine XML-Datei umzuwandeln, die von der Connext Python API verwendet werden kann. Der DDS Emulator wurde so konfiguriert, dass er Änderungen an den Dateien dynamisch über die Connext Python API anzeigte. Von da an nutzte der DDS Emulator die Informationen aus den XML-Dateien, um die zu veröffentlichende Nachricht zu erstellen oder die Nachrichten aus dem ausgewählten Topic zu drucken.

Die Einrichtung und Konfiguration des DDS-Emulators erwies sich als zeitaufwändig. Darum kann der PyInstaller zum Einsatz, um die Phyton-Skripte, Pip-Bibliotheken und Connext in eine leichtgewichtige, ausführbare Datei zu packen, die ohne weitere Konfiguration mit der Anwendung kommunizieren kann. Ein Build-Skript konvertierte die neuesten IDL-Dateien in XML-Dateien, bündelte sie mit dem DDS-Emulator, fügte sie der Pipeline hinzu und stellte sie der zu testenden Anwendung zur Verfügung.

DDS testet über Ozeane hinweg

Das verteilte Entwicklungsteam von MedAcuity nutzte den DDS-Emulator an drei Standorten auf zwei Kontinenten um seine Software während des agilen Entwicklungsprozesses auf Einheitlichkeit und Integration zu testen – das war sehr hilfreich, wenn das System oder Labor nicht verfügbar waren. So konnten die Teams die Entwicklung von Funktionen mit begrenzter Hardware vorantreiben und Leistungsprobleme diagnostizieren und beheben, bevor die Integrationsmeilensteine erreicht wurden.

Weil es sich beim Roboterarm um ein medizinisches Gerät handelt, muss die Benutzerschnittstelle der Roboteranwendung sehr restriktiv sein, um mögliche Risiken für den Benutzer und den Patienten zu minimieren. Im bestehenden Projekt wurde sie so konfiguriert, dass sie nur bei Empfang einer bestimmten Nachricht von der Hardware zum nächsten Bildschirm wechselt. Zum Beispiel musste die Komponente des Roboterarms der Benutzerschnittstelle mitteilen, dass sie eingeschaltet und bereit ist, bevor sie zum nächsten Bildschirm übergehen konnte. Aus Sicherheitsgründen konnte das Entwicklungsteam nicht über den Startbildschirm hinausgehen, ohne dass die Roboterarm-Komponente die Bereitschaftsmeldung gesendet hatte. Remote-Teams, die andere Funktionen implementieren und testen wollten, konnten den DDS-Emulator verwenden, um die Bereitschaftsmeldung zu senden und den Startbildschirm mit eingeschränktem Hardwarezugriff zu überspringen. Es war möglich zu überprüfen, dass die Anwendung nicht verwendet werden konnte, solange die Hardwarekomponenten nicht eingeschaltet waren und die Kommunikation nicht zustande kam.

Sobald die Kommunikation hergestellt war, verwendete die Anwendung ein Thema, um »Heartbeats« zu verfolgen, d.h. Nachrichten, die alle 3 Sekunden gesendet werden, um sicherzustellen, dass alle Hardwarekomponenten während der Nutzung des Systems noch verbunden sind. Wenn eine Hardware-Komponente keine Heartbeat-Nachricht sendet, zeigt die Benutzeroberfläche der Anwendung einen Fehler oder eine Warnung an und bietet Optionen für eine sichere Vorgehensweise. Mit der Administrationskonsole von Connext ließen sich zwar alle Daten im System anzeigen und visualisieren, aber die Fehlersuche in den einzelnen Sequenzen war zu komplex. Weil diese Implementierung viele Fehler bzw. Warnungen für Systeme anzeigte, die nicht über die gesamte Hardware oder remote Entwicklungsumgebungen verfügten, musste der DDS-Emulator eine Option bereitstellen, die kontinuierlich alle 3 Sekunden einen Heartbeat-Nachricht für jede Hardwarekomponente sendet, um die Anwendung fortzusetzen.

Neue Features testen Robo-Bewegung

Mit fortschreitender Entwicklung kamen neue Funktionen hinzu, die Connext nutzten und die Möglichkeiten zum Testen von Roboterbewegungen erweiterten. So musste sich das Team in einer Situation auf einen Test vorbereiten, der über Nacht lief und bei dem regelmäßig Nachrichten gesendet wurden, um den Roboterarm einige Sekunden lang in verschiedene Richtungen zu bewegen. Dazu wurde der Benutzeroberfläche eine Schaltfläche hinzugefügt, die kontinuierlich Nachrichten in der angegebenen Reihenfolge sendet, bis entweder die Schaltfläche »Stop« angeklickt wird oder die Zeit abläuft. Mit dem Befehl »Roboterarm bewegen« wurde ein Programm erstellt, das eine Nachricht aussendet, um den Roboterarm in eine Richtung zu bewegen und einige Sekunden später in die andere Richtung. Die Schleife lief stundenlang, so dass der Test über Nacht ohne menschliches Eingreifen durchgeführt werden konnte.

In einem weiteren Test wollte das Team Nachrichten schnell versenden, um zu überprüfen, ob das System doppelte Nachrichten korrekt verarbeiten kann. Mit Hilfe der Connext-API erstellte der DDS-Emulator zwei Editoren für dasselbe Thema und verschickte die Nachricht zur Sicherheit zweimal. Nachdem sichergestellt war, dass die Anwendung die doppelten Nachrichten erhalten hatte, wurde der Befehl nur einmal verarbeitet. Connext trennte die doppelten Anwendungsnachrichten (Befehle) transparent von den doppelten Paketen.

DDS, Phyton und Connext für Design und Entwicklung

Auch wenn die Idee, anpassbare Dev-Tools zu entwickeln, in der Theorie verlockend klingt, zeigt sich ihr wahrer Wert oft erst während der Design- und Entwicklungsphase eines Projekts, wenn spezifische Bedürfnisse und Anforderungen auftauchen. Nach der Entwicklung des DDS-Emulators erwiesen sich die Flexibilität von Python, die Leistungsfähigkeit von DDS und seines Datenmodells sowie die umfassende Python-API von RTI Connext als vorteilhaft, um auf Änderungen und zusätzliche Funktionen für ein Tool zu reagieren, das eigentlich gar nicht geplant war. Der DDS-Emulator ermöglichte es den verteilt arbeitenden Teams auch bei begrenzten Hardwareressourcen Probleme zu identifizieren und zu beheben sowie Funktionstests durchzuführen. Komplexe Probleme erfordern nicht immer komplexe Lösungen, sondern vielmehr die Leistungsfähigkeit eines flexiblen und anpassbaren Tools. (uh)

_{* Hinweis: Die in diesem Artikel beschriebene Python-Connector-Funktionalität ist jetzt direkt in der neuesten Version von RTI Connext 7.1 verfügbar. Für Python wurde Unterstützung für rtiddsgen hinzugefügt, so dass die Verwendung von Dynamic Data und XML durch generierten Code ersetzt werden kann. In dieser Version bietet die RTI Admin Console direkte Unterstützung für das Veröffentlichen (über Python).}