Deliverable D_MT_4.1_1. Konzept zum Test medizinisch-technischer Systeme am Beispiel des Notrufsystems für hilfsbedürftige Menschen, Phase 1

Transkript

1 Deliverable D_MT_4.1_1 Konzept zum Test medizinisch-technischer Systeme am Beispiel des Notrufsystems für hilfsbedürftige Version 1.0 Projektbezeichnung SPES 2020 Verantwortlich Dr. Hans-Werner Wiesbrock QS-Verantwortlich Erstellt am

2 Zuletzt geändert :54 Freigabestatus Vertraulich für Partner X Projektöffentlich Öffentlich Bearbeitungszustand in Bearbeitung Vorgelegt X fertig gestellt Zuletzt geändert: :18 2/14

3 Weitere Produktinformationen Erzeugung Mitwirkend Hans-Werner Wiesbrock (HWW) Sadegh Sadeghipour (Sad) Änderungsverzeichnis Änderung Nr. Datum Version Geänderte Kapitel Beschreibung der Änderung Autor Zustand Alle Initiale Produkterstellung HWW Alle Allgemeine Überarbeitung Sad

4 Kurzfassung Dieses Dokument präsentiert die erste Phase der MT-Task 4.1 Hardware-in-the-Loop Testumgebung für mobile Body Area Networks (Deliverable D_MT_4.1_1). Es dokumentiert das Testkonzept des Fallbeispiels Notrufsystem für hilfsbedürftige Menschen. Das Notrufsystem für hilfsbedürftige Menschen umfasst mehrere, heterogene Komponenten mit verschiedenartigen Aufgaben. Nach einer groben Beschreibung der Systemarchitektur werden die verschiedenen Teststrategien aufgezeigt, die zur analytischen Qualitätssicherung eingesetzt werden sollen. Zuletzt geändert: :18 4/14

5 Inhalt 1 Einordnung und Kurzbeschreibung Motivation und Einordnung Management Summary Überblick Einleitung Informelle Beschreibung des Notrufsystems Grobarchitektur des Notrufsystems Testkonzept und -strategien Systemtest Komponententests Integrationstest Zusammenfassung Literaturverzeichnis Zuletzt geändert: :18 5/14

6 1 Einordnung und Kurzbeschreibung Ein Ziel des Arbeitspakets MT-AP 4 (Sicherheit, Zertifizierung und Zulassung von Embedded Medical Devices) ist es, die Konzepte und Ansätze der zentralen Arbeitspakete in den Bereichen des Anforderungsmanagements und der Systemmodellierung auf ihre Anwendbarkeit und Vollständigkeit zu überprüfen, gerade hinsichtlich der sich ergebenden Testaspekte. Das Fallbeispiel Notrufsystem für hilfsbedürftige Menschen, das als ein neues System im Rahmen dieses Arbeitspakets entwickelt wird, berührt alle Phasen der Systementwicklung. Das Fallbeispiel kann sich auf die niedrigste Ebene der Sicherheitsanforderungen beschränken, da es sich nicht um ein diagnostisches, sondern um ein unterstützendes System handelt. Trotzdem sind natürlich auch hier Standards der analytischen Qualitätssicherung einzuhalten. Dazu wird in dieser Arbeit ein Testkonzept inkl. der entsprechenden Teststrategie präsentiert. Frühzeitige Validierung von Anforderungen mit Hilfe von Prototypen und Simulationsmodellen ist eine bewährt und erprobte Vorgehensweise und wird auch im Fallbeispiel eingesetzt. Sie wird jedoch im Folgenden nicht weiter betrachtet. In dieser Arbeit konzentrieren wir uns auf die analytische Qualitätssicherung der Implementierung und Integration der Komponenten zu einem Gesamtsystem. 1.1 Motivation und Einordnung Das Ziel dieses Dokuments ist die Beschreibung eines Konzepts zum Test des Fallbeispiels Notrufsystem für hilfsbedürftige Menschen in verschiedenen Testphasen. 1.2 Management Summary Dieses Dokument präsentiert die erste Phase der MT-Task 4.1 Hardware-in-the-Loop Testumgebung für mobile Body Area Networks (Deliverable D_MT_4.1_1). Es dokumentiert das Testkonzept des Fallbeispiels Notrufsystem für hilfsbedürftige Menschen (Sadeghipour & Wiesbrock, 2009). Das Notrufsystem für hilfsbedürftige Menschen umfasst mehrere, heterogene Komponenten mit verschiedenartigen Aufgaben. Nach einer groben Beschreibung der Systemarchitektur werden die verschiedenen Teststrategien aufgezeigt, die zur analytischen Qualitätssicherung eingesetzt werden sollen. Die Entwicklung des Testkonzepts erfolgt entlang der Entwicklung eines immer feiner differentierenden Architekturentwurfes. So erfolgt eine parallele Entwicklung der analytischen Konzepte zu konstruktiven Aktivitäten. Die einzusetzenden Teststrategien in den verschiedenen Testphasen (System-, Komponenten- und Integrationstest) werden beschrieben. Eine Teststrategie umfasst die Definition der zu testenden Objekte (Komponenten, Module, Funktionen), der einzusetzenden Testumgebungen (MiL, SiL, HiL) und der entsprechenden Testarten (Black-Box-Test, White-Box-Test, Robustheitstest, Stresstest,...). 1.3 Überblick Im Kapitel 2 wird die Funktion und die Grobarchitektur des Fallbeispiels Notrufsystem für hilfsbedürftige Menschen beschrieben. Kapitel 3 präsentiert das Konzept für Zuletzt geändert: :18 6/14

7 die Testphasen System-, Komponenten- und Integrationstest und Kapitel 4 fasst die Inhalte des Berichts zusammen. 2 Einleitung Eine Teststrategie umfasst die Definition der zu testenden Objekte (Komponenten, Module, Funktionen), der einzusetzenden Testumgebungen (MiL, SiL, PiL, HiL) und der entsprechenden Testarten (Black-Box-Test, White-Box-Test, Robustheitstest, Stresstest,...). Insbesondere leitet sich aus der gewählten Strategie ab, in welcher Phase was getestet werden soll. Durch die Teststrategie werden ebenfalls der benötigte Testaufwand und folglich die Testkosten bestimmt. Ihr Ziel ist es, ein optimales Verhältnis von Test- und Fehlerkosten zu erreichen. In der Medizintechnik sind weitere Aspekte in die Teststrategie mit einzubeziehen, insbesondere die Risikoanalyse. Für das Fallbeispiel Notrufsystem beschränken wir uns jedoch auf die niedrigste Risikoebene, da hierbei sich nicht um ein diagnostisches, sondern unterstützendes System handelt. In den folgenden zwei Abschnitten wird eine grobe Übersicht des Notrufsystems und dessen Architektur gegeben 2.1 Informelle Beschreibung des Notrufsystems Es soll ein Notrufsystem entwickelt werden, welches bei Eintreten eines gesundheitlich bedingten Notfalls oder auch Haushaltunfalls automatisch einen Hilferuf abschickt. Dieser wird von einer Notstelle aufgefangen, bewertet und ggfs. mit zusätzlichen Informationen an einen Arzt weitergeleitet. Ein Notfall wird charakterisiert durch: Die Person liegt längere Zeit auf dem Boden. Verschiedene Körperfunktionen (Atmung, Herzschlag,...) sind anormal. Die Person soll permanent durch das System überwacht werden (Abbildung 1). Abbildung 1 Anwendungsfälle des Notrufsystems 2.2 Grobarchitektur des Notrufsystems Um den Zustand eines Patienten zu erfassen, werden mobile, am Körper zu tragende Sensoren eingesetzt. Andererseits werden u.a. zur Lageerfassung auch Referenzknoten fest im Raum installiert. Um das System flexibel und skalierbar zu halten, wird ein Gateway eingesetzt, welches mit einem Telematikmodul verbunden ist und über den ein Notruf zentral abgesetzt werden kann (Abbildung 2). Zuletzt geändert: :18 7/14

8 Abbildung 2 Aufbau des Notrufsystems Die körpernahen Sensoren werden allgemein als mobile Sensorknoten bezeichnet, die festinstallierten Locatoren als stationäre Sensorknoten (Abbildung 3). Da wir uns hier auf die analytische Qualitätssicherung von Software konzentrieren, ist der Um- stand, ob die Sensorik bewegt wird oder nicht, unwesentlich. Lediglich für gewisse Funktionstests sind entsprechende Vorrichtungen vorzusehen. Wesentlich jedoch für das Testkonzept ist die Funktion eines einzelnen Sensors. Abhängig von den techni- schen Möglichkeiten und Voraussetzungen sind hier entsprechende Strategien zu entwerfen. Abbildung 3 Grobarchitektur des Notrufsystems 3 Testkonzept und -strategien Für die Entwicklung des Testkonzepts folgen wir der Entwicklung eines immer feiner differentierenden Architekturentwurfes. rentwurfes. So erfolgt eine parallele Entwicklung der ana- lytischen Konzepte zu konstruktiven Aktivitäten. Zuletzt geändert: :18 8/14

9 3.1 Systemtest Da die einzelnen Komponenten in der HiL-Umgebung nicht ohne Weiteres einzeln, unabhängig voneinander mit Testdaten beaufschlagt werden können, wird folgendes Vorgehen vorgeschlagen: Abbildung 4 Netzwerk Protokolltests Vorab wird validiert, ob die verschiedenen eingesetzten Kommunikationsprotokolle den Anforderungen entsprechen (Abbildung 4). Dazu werden Simulationstechniken und Model Checking eingesetzt. Es wird die Funktionsweise der einzelnen Komponenten getestet, sowie die korrekte Implementierung der diversen Schnittstellen mitsamt ihrer Performanz. Insbesondere sollten hier auch spezielle Grenzwertanalysen durchgeführt werden (Abbildung 5). Darüber erhalten wir Vertrauen in die Einhaltung gewisser Randbedingungen durch die einzelnen nen Komponenten. Abbildung 5 Komponententest Nun testen wir, ob die Netzprotokolle mit den empirisch ermittelten Randbedingun- gen robust laufen. Dazu werden die einzelnen Knoten simuliert, genauer, Simulati- onsszenarien in die SW Komponenten eingespielt und deren Reaktion so simuliert (hier ist anzumerken, dass dazu ein spezieller Testmodus auf den einzelnen Knoten implementiert werden sollte, siehe 3.2.1).. Zusätzlich addieren wir Störungen auf diese Simulationen, mit denen wir Fehlerinjektionen und auch Performanzgrenzen abdas Gesamtsystem auch mit bilden. Auf diese Weise kann abgesichert werden, dass Hardware- bedingten Reaktionsabweichungen klar kommt. Das Gateway, als zentra- le Verbindung der Sensorknoten zum Absetzen eines potentiellen Notrufes über das Telematikmodul wird in diesem Test als Hardware eingebunden. Zusätzlich wird das Gesamtsystem durch funktionale Tests abgesichert (Abbildung 6). Zuletzt geändert: :18 9/14

10 Abbildung 6 Systemtest (Gateway HiL + Sensorknotensimulation) Die folgende Tabelle gibt einen Überblick über die Teststrategien auf der Ebene des Systemtests. Testobjekt System Testumgebung HiL (Gateway) HiL (Gateway) Testart Black-Blox-Test Robustheitstests Grenzwertanalysen / Negativtests HiL (Gateway) Testendekriterium 100 % Anforderungsüberdeckung, Ausfallrate < 10^-6 Geeignete Kombinationsüberdeckung Geeignete Abdeckung der Grenzwerteingaben und deren Überschreitungen Vorgehen Es werden typische Anwendungsszenariund Fehlerfälle über Markov- Automaten generiert und Fehlverhalten des Systems detektiert. Die Grenzwerte in den Eingabemöglichkeiten, sowie die Robustheit bei Übertretungen werden über- en prüft. 3.2 Komponententests In diesem Kapitel wird ein Testkonzept für die einzelnen Komponenten beschrieben Sensorknoten In einem Sensorknoten werden die vom Sensor ermittelten Daten aufbereitet, ggfs. mit Daten anderer Sensorknoten verglichen und bewertet und anschließend an das Gateway weitergeleitet. Der einzelne Sensorknoten wird angelehnt an Service Oriented Architecture (SOA) implementiert. Zuletzt geändert: :18 10/14

11 Abbildung 7 Logischer Aufbau eines Sensorknoten Die Sensorknoten sind zugekauft und werden für das Notrufsystem programmiert. Das Ziel des Tests ist deshalb nicht die Prüfung korrekter Arbeitsweise der Hardware-Sensorik. Die Sensorknoten kommunizieren untereinander über ZigBEE/Bluetooth. Testumgebung MiL/SiL/ HiL Algorithmen Datenaufbereitung Testobjekt MiL/SiL/ HiL MiL Testart Black-Box- Test Black-Box- Test mit Debugger, Schnittstellentest Konformitätstest SOA Interface Testendekriterium 100 % Anforderungsüberdeckung X % Strukturüberdeckung, Äquivalenzklassen Überdeckung Konformitätsklassen Überdeckung Anmerkungen Für die Tests sind auch Sensordaten anderer Knoten einzuspielen. Abhängig von den Möglichkeiten (offener Datenport zur Software) können eventuell Algorithmentests auch auf dem HiL-Stand durchgeführt werden. Falls die Datenports unzugänglich sind, ist ein Testmodus zu implementieren. Da man nicht auf die Datenports zugreifen kann, werden hier Testmodi implementiert. Auf diese Weise ist die Datenweitergabe zum Netz hin auch mit HW-Netzwerkport zu testen. Einzusetzen ist hier auch Testdatengenerierung aus Modellen, die dann über das Evaluationsboard auf den Messdaten RAM gespielt werden. Da der HiL-Stand nicht in der Lage ist, zwei Sensorknoten unabhängig mit Testdaten über Hardware-Ansteuerung zu bedaten, wird hier die SOA Schnittstelle nur in MiL Zuletzt geändert: :18 11/14

12 Netzwerk Treiber (Netzport) Netzwerk Treiber (Netzport) MiL/SiL/ HiL HiL Schnittstellentest, Protokolltests Performanz- und Lasttests u.a. SOA Schnittstelle, x % BAN Schnittstelle bzw. im Testmodus überprüft. Da die Schnittstelle über den Netzwerkport mit seiner Umgebung kommuniziert, dieser wiederum in einem HiL-Stand überprüft wird, ist davon auszugehen, dass auch die SOA Schnittstelle dann mit der Sensor- HW korrekt zusammenspielt. Testmodus Die Sensorknoten erlauben nicht den Zugriff auf die Kommunikationsports (DataPort). Um trotzdem die Sensorknoten mit ihren Netzports im HiL testen zu können, wird ein spezieller Testmodus auf den Sensorknoten implementiert. In diesem werden über geeignete Netzwerkprotokolle simulierte Sensormesswerte in geeignete RAM-Zellen des Sensorknotens gespielt, so dass realistische Testszenarien im HiL mit physikalischen Netzwerken unter Umgehung der Hardware-Sensorik möglich wird. Auf diese Weise lassen sich aufwendige Hardware-Teststände umgehen, um beispielsweise einen Sturz zu simulieren. Auf diese Weise kann, beginnend mit den niederen Diensten, die vorwiegend Sensordaten aufnehmen und weitergeben, auch im das Gesamtsystem stimuliert werden Gateway Das Gateway verbindet zum Einen die verschiedenen Sensorknoten mit dem Telematikmodul, zum anderen besitzt es auch eine eigene Auswertungskomponente. Letztere erlaubt komplexe Berechnungen, basierend auf mehreren Sensordaten, von verschiedenen Knoten und über der Zeit, die auf einem z.b. mobilen Sensorknoten mit seinen beschränkten Ressourcen nicht möglich ist. SOA Interface Testobjekt Algorithmen Testumgebung Testart Testendekriterium MiL/SiL/HiL Black-Box-Test 100 % Anforderungsüberdeck ung MiL Konformitätstest Konformitätsklassen Überdeckung Anmerkungen Für die Tests sind Sensordaten anderer Knoten auch einzuspielen. Diese werden über die getesteten Ports in das Gateway eingespielt. Es wird überprüft, ob ggfs. der Notruf korrekt an das Telematikmodul abgesetzt wird. Siehe Anmerkungen zum Testen von SOA bei der Sensorknotenkomponente. Zuletzt geändert: :18 12/14

13 Netzwerk Treiber (Netzport) Netzwerk Treiber (Netzport) MiL/SiL/HiL HiL Schnittstellentest, Protokolltests Performanz- und Lasttests RS 232 HiL Schnittstellentest u.a. SOA Schnittstelle, x % BAN Schnittstelle RS 232 HiL Performanz- und Lasttests Telematikmodul Das Telematikmodul wird bereits erfolgreich eingesetzt, so dass der Test dieser Komponente hier nicht weiter betrachtet wird. 3.3 Integrationstest Netzkommunikation Diese Tests lassen sich noch weiter unterteilen, je nach der übergeordneten Komponente. So könnte man zunächst nur die Kommunikation der mobilen Sensorknoten untereinander betrachten, anschließend zusammen mit den stationären usw. Da jedoch die grundsätzliche Problematik dieselbe ist, wird diese Unterscheidung hier nicht gemacht. Testart Black-Box- Test Model Checking Robustheitstest Testobjekt Netzwerk Kommunikationsprot okoll Netzwerk Kommunikationsprot okoll Netzwerk Kommunikationsprot okoll Testumgebung MiL MiL Testendekriterium 100 % Anforderungsüberdeckung Konform zum definierten Protokoll (BAN) Geeignete Kombinationsüberdeckung Anmerkungen Es wird ein Sensornetz simuliert, welches über das definierte Protokoll miteinander kommuniziert. Dazu werden in dem simulierten Sensornetzwerk stochastisch Abweichungen zu den Gutfällen (SW Implementierungen auf den einzelnen Sensorknoten) generiert, in Werten und in Zeiten. 4 Zusammenfassung Das Fallbeispiel Notrufsystem für hilfsbedürftige Menschen mit ihren heterogenen Komponenten und ihrer vielfältigen Kommunikation nötigt zu ausgefeilten Testkonzepten. In der vorliegenden ersten Version der Arbeit haben wir einige grundlegende Teststrategien skizziert. Zuletzt geändert: :18 13/14

14 5 Literaturverzeichnis Sadeghipour, S., & Wiesbrock, H.-W. (2009). Beschreibung der Fallstudie Notrufsystem für hilfsbedürftige Menschen. SPES-Deliverable. Zuletzt geändert: :18 14/14