Tipps für die Softwareentwicklung
Medizinproduktehersteller haben oft Probleme bei der Erstellung adäquater Softwaredokumentation. Mögliche Ursachen sind, dass die Entwicklungsabteilungen
- neu zusammengesetzt wurden und/oder die Mitarbeiter keine Erfahrungen in der Regulatorik von Medizintechnik haben,
- anstatt dediziert die Ursache zu beheben lediglich die Entwicklungsprozesse und Dokumente verkomplizieren.
Hintergrund der Regulierung
Will die Behörde mittels Normen, Standards und Regularien die Entwicklungsabteilungen mit unnötiger Dokumentation ärgern oder gar die Abteilungen stilllegen und damit Neuentwicklungen und Innovation ausbremsen? Nein, der Hintergrund für das Regelwerk ist, dass Hersteller in die Lage versetzt werden, strukturiert zu arbeiten und dass die Entwicklungsergebnisse
- Sicher (im Sinne von security und safety) und
- Wartbar (die Software hängt nicht nur an wenigen ‚key‘-Mitarbeitern)
sind.
Wie kann die Dokumentation möglichst effektiv – aber trotzdem konform - aufgebaut werden?
Diese Frage steht im Mittelpunkt dieses Blogbeitrags. Ziel ist es, eine Dokumentationsstrategie vorzustellen, die den regulatorischen Anforderungen in Audits standhält, ohne die Entwicklungsabteilungen durch unnötigen Aufwand zu belasten oder gar zu behindern.
Darüber hinaus bietet der Beitrag konkrete Anregungen, wie bereits zu Beginn einer Neuentwicklung die richtigen Weichen gestellt werden können – mit dem Ziel, spätere Aufwände und Nacharbeiten zu minimieren.
Für die USA gibt es FDA-Guidance Dokumente. Diese sind zwar formal unverbindliche Empfehlungen, geben aber die Erwartungshaltung der Behörde wieder. In der Praxis wird eine Einhaltung dringend empfohlen, sofern keine gleichwertigen Alternativen detailliert begründet und dokumentiert werden.
- Gute Dokumentationspraxis (Good documentation practice (GDP))
- Objective Evidence
- High Level Architektur
- Systemanforderungen
- Traceability (Rückverfolgung)
- Traceability oben vs. unten
- Traceability rechts vs. links (V-Modell)
- Traceability SW Release vs. Dokumentation
- Traceability zu Hardwareständen
- Impact Analyse
- Systemarchitektur
- SW-Architektur
- Geeignete SW-Architekturen – vertikale Architektur
- Segregation
- Detailliertes Design
- Unit Tests
- SOUP vs. OTS Evaluierung
Gute Dokumentationspraxis (Good documentation practice (GDP))
Die amerikanische Zulassungsbehörde FDA legt auf GDP einen sehr hohen Wert. Es werden schnell Abweichungen reklamiert , sobald Inkonsistenzen oder verschiedene Stile entdeckt werden.
Was versteht man unter GDP?
Darunter ist zu verstehen, dass Dokumente nach einheitlichen Kriterien erstellt und verwaltet werden. Bei folgenden Kriterien haben Hersteller oft Probleme:
Datumsformat
Im deutschsprachigen Raum ist es typisch ein Datum im deutschen statt im amerikanischen Format zu schreiben, d.h DD.MM.YYYY statt MM/DD/YYYY. Teilweise werden die Jahre auch nur zweistellig angegeben. Dagegen sind automatisch erzeugte Reports dann mit einem anderen Zeitstempelformat versehen. Damit kann schnell Unklarheit über das Datum auftreten, wann eine Spezifikation bzw. ein Report unterzeichnet wurde, z.B. 12.10.11. Damit kann der Auditor / Prüfer nicht mehr eindeutig zuordnen, in welcher Reihenfolge die Spezifikation und Reports erzeugt wurden.
Hinweis
Vor dem Hintergrund der Internationalisierung und Zulassung in verschiedenen Ländern, ist es empfehlenswert die Norm ISO 8601 im gesamten Unternehmen als Standard anzuwenden, welche das Datumsformat DD-MM-YYYY definiert.
Leerfelder / Leere Zellen
Nicht relevante Felder innerhalb von Tabellen müssen als nicht relevant markiert werden. Ein Auditor fordert eine Begründung, warum diese Felder nicht relevant sind. Daher bietet sich ein ‚N/A – [Begründung]‘ an.
Kürzel Mitarbeiter
In mittleren und größeren Unternehmen werden oft Kürzel eingeführt, um Mitarbeitern in Dokumenten, Systemen oder Prozessen eindeutig, kurz und effizient zu identifizieren. Es besteht meist aus einer Kombination von Buchstaben (z. B. Initialen des Vor- und Nachnamens) und manchmal Zahlen oder anderen Codierungen. Dabei muss im Unternehmensprozess und idealerweise durch validierte Softwaretools sichergestellt werden, dass Kürzel eineindeutig sind. Das bedeutet, dass Mitarbeiter mit denselben Initialen nicht dieselben Kürzel verwenden. Dies gilt auch in Bezug zu ehemaligen Mitarbeitern – Kürzel dürfen NICHT wiederverwendet werden!
Abkürzungen
Jedes Unternehmen verwendet Abkürzungen, um die Verwendung von längeren Begriffen zu reduzieren und den Informationsfluss zu beschleunigen. Diese Abkürzungen sind für Neueingestellte, Außenstehende und teilweise innerhalb der Firma nicht ersichtlich und nicht eindeutig. Daher bietet sich ein globales Glossar an, was alle Abkürzungen enthalten sollte.
Objective Evidence
Hinter dem etwas sperrigen Begriff ‚objektiver Nachweis‘ steht die Anforderung nachzuweisen, dass
- die einzelnen Tests wirklich durchgeführt wurden, und
- das Testobjekt (SUT / DUT = Software / Device under Test) eindeutig identifizierbar ist.
Was muss dafür dokumentiert werden?
Testobjekt:
Es soll eindeutig hervorgehen, welches das SUT / DUT (Software / Device under Test) ist. Idealerweise wird ein Foto / Snapshot der in dem User interface (UI) angezeigten oder über das Dateninterface übermittelten Softwareversion aufgenommen und dokumentiert. Dies kann der initiale Testfall sein oder immer die erste Aktion vor dem eigentlichen Test sein.
Bei Unittests ist es deutlich schwieriger, die verwendete Softwareversion / Revision zu dokumentieren – ggfs. über die SVN Properties oder Dokumentation des logs des Checkouts.
Dokumentation von Tests
Bei einzelnen Tests stellt sich oft die Frage, was genau dokumentiert werden soll und ob überhaupt eine Aufzeichnung o.ä. erforderlich ist. Bei Gesamtsystemtests mit Performance-Anforderungen macht es Sinn, ein Video aufzuzeichnen (z.B. Schließen einer elektrischen Klemme aufgrund von Blasendetektion im Schlauch). Bei Unittests bzw. SW-Tests sind Videoaufzeichnungen selten nötig. Trotzdem sollte
der Nachweis so gestaltet sein, als würden die Testergebnisse extern offengelegt – mit dem Ziel, Manipulationen auszuschließen. Beispiel: Beim Prüfen eines spezifischen, blinkenden Alarms genügt ein Foto, welches zeigt, dass der Alarm tatsächlich angezeigt wurde. Es kann auch ein Automatismus eingebaut werden, welcher automatisiert nach jedem Testschritt Snapshots anfertigt.
Die detaillierten Informationen finden Sie hier:
- FDA Guidance Dokument: “Content of Premarket Submissions for Device Software Functions”
- IEC 62304:2006+A1:2015 “Medical device software. Software life-cycle processes”
- FDA-Guideance: “General Principles of Software Validation”
High Level Architektur
Damit Softwareentwickler, Auditoren, Behörden und andere Abteilungen (Qualitätsmanagement, Regulatory Affairs) die Software schnell verstehen, empfiehlt es sich, ein High-Level Architekturdokument zu erstellen, welches folgende Punkte enthält:
- Überblick der verschiedenen SW-Systeme
- Eine kurze Beschreibung (auf high-level) der gesamten Software und der einzelnen Softwaresysteme
- Software-Klassifizierung nach IEC 62304 (Klasse A, B, C) jedes Softwaresystems.
- Level of concern nach FDA Guidance ‘Content of Premarket Submissions for Device Software Functions’
Hinweis
- In diesem Dokument kann auch die Evaluierung der SW-Klasse und Level of concern stattfinden.
- Es ist ratsam, für jeden Mikrokontroller jeweils ein SW-System zu definieren. Damit ist die Segregation nach IEC 62304 Kapitel 5.3.5 ‚…that such segregation is effective‘ leichter nachweisbar. Bei Stand-Alone Software ist oft ein einziges Softwaresystem zu definieren.
Das High-Level-Architekturdokument wird idealerweise vor dem Start der Softwareentwicklung durch die Systemarchitekten erstellt und entspricht formal einem Systemarchitekturdokument.
Systemanforderungen
Dieser Abschnitt widmet sich dem Input für die Software-Systemanforderungen. Hintergrund ist, dass teilweise die Einbindung von Stakeholdern und die Erstellung von Spezifikationen ‚vergessen‘ werden, und somit die Softwareanforderungen unvollständig oder ungültig sind.
Die gesammelten Anforderungen an ein Softwaresystem werden abgeleitet aus
- Systemanforderungen,
- Systemarchitektur,
- Benutzerschnittstelle (UI-Spezifikation) sowie
- Elektronik
Bei der Erstellung von Systemanforderungen werden regelmäßig die die beispielsweise Anforderungen für
- Debugschnittstellen
- Programm-Logbücher (z.B. zum Speichern von Abstürzen inkl. Trace)
benötigen.
Abbildung 1 Quellen von SW-Systemanforderungen
Auf der anderen Seite sollte die Elektronikgruppe mit der Softwaregruppe (und anderen) idealerweise zusammen entwickeln. Die Entwicklungsergebnisse müssen dokumentiert werden. Bestandteile sind unter anderem:
- Power up and down Mechanismus
- Eigenschaften und Parameter von Reglern
Diese Ergebnisse sollten in Architektur- und Designanforderungen einfließen, wovon Softwareanforderungen abgeleitet werden können.
Zu allen Parametern empfiehlt es sich, eine Begründung zu dokumentieren und was die Trade-offs (erkauften Nachteile) sind (z.B. Überschwingverhalten von Reglern oder Totzeiten). Diese Begründungen sind wichtig für zukünftige Entwicklergenerationen bzw. für die Wartung der Medizinprodukte.
Traceability (Rückverfolgung)
Hinter dem Begriff „Traceability“ steht die systematische Dokumentation der Beziehungen zwischen den einzelnen Entwicklungsergebnissen – mit dem Ziel, jeden Input eindeutig bis zum zugehörigen Output nachvollziehen zu können.
Abbildung 2 Mögliche Beziehungen auf SW-Systemebene
Abbildung 3 Traceability SW-Dokumentenversionen zu SW-Releases
Traceability oben vs. unten
Die Forderung ist, dass
- die Anforderungen von übergeordneten Anforderungen abgeleitet sein sollten (Beispiel: SW-Anforderungen müssen von Systemanforderungen, Architektur und Spezifikationen abgeleitet sein).
- High-Level Anforderungen auf SW-Anforderungen verweisen
Traceability rechts vs. links (V-Modell)
Die Beziehungen zwischen Anforderungen, Testfällen und Testergebnissen sind folgende:
- Testfälle müssen von Anforderungen abgeleitet sein.
- Testergebnisse müssen von Testfällen herrühren.
- Anforderungen müssen auf Testfälle verweisen.
Traceability SW Release vs. Dokumentation
Normalerweise ist die Softwareentwicklung eine inkrementelle Entwicklung, sodass im Laufe des Projektes mehrere Softwarereleases erzeugt werden. Auch wird die Software während des Betriebes weiterentwickelt. Somit werden im Leben des Medizinproduktes mehrfach Softwareversionen erstellt. Das gleiche trifft für die Dokumentation zu, aber nicht jedes Dokument wird angepasst. Daher ist es wichtig, dass bereits vor der Entwicklung definiert wird, welche Dokumente zu welchem Softwarerelease gehören:
- Es muss ersichtlich sein, welche Dokumente und Dokumentenversionen zu welchem SW-Release gehören.
- Testreports müssen zu einem SW-Release bzw. zu einer Version der Unit identifizierbar sein. Ein objektiver Nachweis (Evidence) ist in diesem Fall zu erbringen.
Traceability zu Hardwareständen:
Die Softwareentwicklung ist wesentlich volatiler als die Elektronikentwicklung. In der Wartungsphase sind Wechsel von Elektronikbauteilen aufgrund Abkündigungen an der Tagesordnung. Daher wird die Software -auch im Feld- auf verschiedene Hardware treffen. Daher ist es wichtig, dass
- bei Testreports erkenntlich ist, welches die verwendete Hardware und Hardwareversion ist,
- eine Evaluierung stattfindet, welchen Impact eine Softwareänderung auf bestehende Hardware hat und
- eine Evaluierung stattfindet, welchen Impact eine Hardwareänderung auf bestehende Software hat.
Impact Analyse:
Es muss vor der eigentlichen Entwicklungsarbeit eine Impact Analyse erstellt werden, welche Auswirkungen bei der Änderung zu evaluieren sind. Dabei sind unter anderem folgende Auswirkungen zu betrachten und zu dokumentieren:
- bestehende Anforderungen
- bestehende Testfälle
- die SW Einheiten (im folgenden „Units“
- die Risikoakte
- die SW Klassifizierung
- die Security
- die Gebrauchsanweisung / Instruction for use
- Serviceanweisung / Service Manual
- die Produktion
- die Hardware
- bestehende Hardwareversionen
Es ist ratsam, einen Nachweis der Umsetzung dieser geplanten Aktivitäten zu erbringen.
Fazit
Bereits vor dem Start der Entwicklung sollte sich über die Traceability und deren Aspekte Gedanken gemacht werden und ein erstes grobes Konzept erstellt werden, welches im Laufe der Entwicklung verfeinert wird. Bei Änderungen (Changes) und Bugfixes ist das Erstellen einer Impact Analyse vor der Implementierung unabdingbar.
Systemarchitektur
Eine Systemarchitektur ist oft fokussiert auf Aspekte wie die Anforderungen der IEC 60601-1 (Nachweis der funktionalen Sicherheit, Erstfehlersicherheit, wesentliche Leistungsmerkmale usw.). Dabei werden die Softwareaspekte leider vergessen. Daher muss eine gute Systemarchitektur für die Software folgendes leisten:
- Die Aufteilung von Programmable Electrical Medical System (PEMS) und Programmable Electrical Subsystem (PESS). Dabei ist es hilfreich, ein PESS auch als Software System zu deklarieren. Wenn mehrere Mikrokontroller auf einem PESS sind, so ist es besser, für jeden Mikrokontroller ein Softwaresystem zu deklarieren.
- Deklaration, was einem Softwaresystem entspricht.
- Definition des Interfaces zwischen Softwaresystemen (inkl. Laufzeitverhalten). Obwohl die Softwareentwicklung die Interfaces spezifiziert, so sind diese jedoch Bestandteil der Systemarchitektur
- Definition, was ein Softwaresystem leisten soll bzw. für welche (Teil-)Aufgaben dieses (high level) verantwortlich ist
Software Architektur
Oft ist der Entwicklungsabteilung unklar, was sich hinter der durch die IEC 62304 geforderten SW-Architektur verbirgt.
In der Praxis entstehen dann häufig umfangreiche, schwer wartbare Dokumente, die nicht einmal die Mindestanforderungen der Norm erfüllen.
- Wir wollen daher kompakt erläutern, welche Architekturelemente ein Softwarearchitekturdokument enthalten muss – mit dem Ziel, den tatsächlichen Aufwand transparent und überschaubar zu machen.Damit die Architektur nicht an ihrem eigentlichen Ziel vorbeigeht, sollten folgende Fallstricke vermieden werden …Die Dokumente erläutern das Zusammenspiel von Klassen, anstatt eine übergeordnete Systemstruktur abzubilden.
- Die Dokumente enthalten Prozessschritte, obwohl diese nicht Teil der Architektur sind.
- Bunte Bilder, die weder einer standardisierten Sprache (z.B. UML) noch Erklärung der verschiedenen Farben, Symbole und Striche enthalten.
- Nicht lesbare Bilder:
- Schrift ist zu klein
- Diagramm ist überfüllt
Was macht eine gute Architektur aus?
- Stellt die im Standard IEC62304 geforderten Komponenten ‚SW-System‘, ‚SW-Item‘ bis ‚SW-Unit‘ richtig dar (mit genau diesen Begriffen)
- Schnittstellen zwischen SW-Systemen, -Items und -Units sind beschrieben (z.B. in einem referenzierten Dokument)
- Kurze (high-level) Erklärung, was die Aufgabe der Komponente ist
- Design-Entscheidungen sollten verfügbar sein – idealerweise separat). Dazu zählen auch bewusst nicht umgesetzte oder verworfene Alternativen.Eine Begründung hilft in der Wartungsphase bzw. im Folgeprodukt den Entwicklern.
- Eine formalisierte Sprache kann die Lesbarkeit und Verifizierbarkeit unterstützen
- Jedes Diagramm enthält
- einen Kontext, damit einordbar ist, worum es geht
- eine Legende, wenn spezielle Syntax / Farben verwendet werden
- Erklärung für die Verwendung von Entwurfsmustern einschließlich Begründung, warum genau dieses Muster gewählt wurde und nicht andere (dies unterstützt zukünftigen Entwicklern in der Wartungsphase)
- Gedanken über Aufspüren von Fehlerursachen - auch während der Betriebsphase des Medizinproduktes.
- Verwendung von Off-the-shelf-Software / SOUP (Software mit unbekannter Herkunft)
Hinweis
Den Umfang der Units in Abhängigkeit von der Risikoklasse des Softwaresystems wählen. Bei kritischeren Systemen ist empfohlen, die Architektur auf eine feinere Ebene herunterzubrechen - also kleinere, dafür mehr Units zu definieren. So kann Arbeit für die Dokumentation gespart werden und es ist für die Behörde ersichtlich, warum dort gespart wurde.
Es ist zu beachten, dass die IEC 62304 eine Verifizierung der Architektur fordert. Daher muss VOR der ersten Version der Architektur ein Verifizierungsplan festgelegt werden (idealerweise im SW-Entwicklungsprozess bzw. SW-Entwicklungsplan). Eine Checkliste ist eine mögliche Variante für die Verifizierung der SW-Architektur.
Geeignete Architekturen
Die Softwareentwicklung orientiert sich oft an der Schichtenarchitektur. Diese Art der Architektur ist gekennzeichnet durch sehr breite Interfaces zwischen den einzelnen Schichten. Dagegen sind die einzelnen Funktionen innerhalb einer Schicht oft nur schwach verbunden. Das Bilden von Units nach IEC62304 ist hier sehr aufwändig, da viele Interfaces berücksichtigt und gleichzeitig viele Funktionen realisiert werden müssen.
Als Alternative bietet sich eine vertikale Architektur an, die vollständige funktionale Einheiten bildet, welche sich durch alle Schichten ziehen, ohne große Abhängigkeiten zu anderen funktionalen Einheiten.
Vorteil der vertikalen Architektur im Rahmen der IEC62304: eine oder mehrere zusammenhängende funktionale Einheiten der vertikalen Architektur bilden eine Unit, was folgende Vorteile bietet:
- Begrenzte Anzahl von Interfaces
- Funktion ist in übergeordneter Spezifikation bereits beschrieben. Nur die Interfaces müssen angepasst werden. Das bedeutet, dass Unittests schon ein Großteil der Funktionen des gesamten Systems abprüfen, was ein frühes Aufdecken von Fehlern ermöglicht.
Zusätzlich ist
- eine spätere Ergänzung der Funktionalität leicht möglich – die Wartbarkeit wird vereinfacht.
- Software-Integrationstests (gefordert in der IEC62304) sind leicht möglich: es werden mehrere Units ausgeführt.
Abbildung 4 Beispiel eines Schichtenmodells. Die Schnittstellen einzelner Schichten sind oft sehr breit.
Abbildung 5 Beispiel einer vertikalen Softwarearchitektur
Segregation
Die IEC 62304 fordert für unterschiedliche Softwareklassen eine dokumentierte Segregation, also eine logische oder funktionale Trennung der entsprechenden Softwareelemente. Diese muss in der Systemarchitektur oder einem adäquaten Dokument evaluiert werden.
Es ist dagegen weitaus schwieriger, Komponenten welche auf gleichem Mikrokontroller / Server / Prozessor laufen, unterschiedlich zu klassifizieren. Es muss eine saubere Segregation argumentativ und architektonisch gefunden werden. So ist es nicht möglich, eine Komponente (z.B. Logging) der Klasse A zuzuweisen, wenn parallel auf demselben Mikrokontroller eine Klasse B oder C Softwarekomponente.
Warum? Die Software der Klasse A wird weitaus geringer verifiziert (auf Unit-Ebene gar nicht – außer im FDA Kontext). Ein Beispiel: Ein Pointerfehler in der Logging-Komponente könnte unbemerkt Speicherbereiche sicherheitskritischer Klasse B/C-Komponenten überschreiben – mit potenziell gefährlichen Auswirkungen.
Kann man trotzdem Klasse A Komponenteparallel mit Komponenten der Klasse B oder C im Softwaresystem platzieren?
Prinzipiell ist dies möglich, wenn die Segregation der einen Software von der anderen sichergestellt ist.
Welche Möglichkeiten der Segregation bieten sich an?
- Räumliche Segregation:
Diese wird erreicht, wenn Komponenten auf unterschiedlichen Mikrokontrollern laufen, und die Speicherbereiche getrennt sind.
Alternativ kann räumliche Segregation auch durch den Einsatz von Betriebssystemen auf leistungsfähigen Prozessoren realisiert werden, die eine saubere Trennung der Komponenten ermöglichen.
Typische Beispiele sind:- Hypervisoren (bekannt aus Cloud- und Rechenzentrumsumgebungen)
- Container-Technologien
- Virtualisierungslösungen
Hinweis
Die räumliche Segregation ist ideal für die Risikominimierung von Cybersecurity-Schwachstelle
- Zeitliche Segregation:
Diese Segregationsmethode kann nur z.B. vor dem Starten der Applikation (Bootloader) und Post-Anwendungen aufgeführt werden, wenn ausgeschlossen ist, dass die Applikation und die Klasse A Funktion datentechnisch interagieren.
Detailliertes Design
Die IEC 62304 fordert unter Kapitel 5.4 für Klasse C Software Units ein detailliertes Design. Falls eine Zulassung in den USA angestrebt wird, so ist das detaillierte Design so zu erstellen, dass keine ad-hoc Entscheidungen durch den Entwickler getroffen werden:
„A complete software design specification will relieve the programmer from the need to make ad hoc design decisions“
(FDA Guidance, General Principles of Software Validation , Kapitel 5.2.3).
Des Weiteren fordert die FDA, dass es eine Traceability zwischen den Unittests und dem detaillierten Design geben muss. (FDA Guidance, General Principles of Software Validation, Kapitel 5.2.5)
Empfehlungen
- Das detaillierte Design sollte als Anforderung geschrieben werden.
- Das detaillierte Design wird über die Interfaces der Unit beschrieben.
- Verwendung einer standardisierten Sprache, um u.a. Laufzeitverhalten zu beschreiben (z.B. UML).
- Unittests decken die Anforderungen des detaillierten Designs ab.
Hinweis
Sobald innerhalb einer Unit weitere Anforderungen, interne Logik (z. B. Zustandsautomaten) oder Komponenten spezifiziert werden, gilt die Unit gemäß IEC 62304 als geöffnet und wird zu einem Item (Komponente). In diesem Fall ist eine vollständige Dokumentation aller untergeordneten Units erforderlich.
Abbildung 6 Prinzip der Architektur
Unit Tests
Traceability
Unittests sollten wie alle Softwaretests automatisiert durchgeführt werden. Falls der US-Markt potentiell Zielland des Medizinproduktes ist, so ist das etwas ältere FDA Guidance Dokument ‚General Principles of Software Validation‘ im Kapitel 5.2.5 zu entnehmen, dass eine Traceability zwischen dem Detaillierten Design und den Unit-Testfällen erbracht werden muss:
- Test Planning
- Structural Test Case Identification
- Functional Test Case Identification
- Traceability Analysls - Testing
- Unit (Module) Tests to Detailed Design
- Integration Tests to High Level Design
- System Tests to Software Requirements
- Unit (Module) Test Execution
- Integration Test Execution
- Functional Test Execution
- System Test Execution
- Acceptance Test Execution
- Test Results Evaluation
- Error Evaluation/Resolution
- Final Test Report
Ausschnitt aus FDA Guidance Dokument ‚General Principles of Software Validation‘ Kapitel 5.2.5
Testabdeckung (Code Coverage)
Des Weiteren müssen Unittests eine 100% Testabdeckung erreichen:
“… ‚Use of the term “coverage” usually means 100% coverage‘... ”
[FDA Guidance Dokument ‘General Principles of Software Validation’, Kapitel 5.2.5.]
Bei defensiver Programmierung ist eine 100% Testabdeckung nicht erreichbar. Soll daher auf die defensive Programmierung verzichtet werden? Muss der Quellcode so umgebaut werden, dass 100% Testabdeckung möglich ist? Oder sollten Monate ins Land fließen, damit die letzten 10-20% Testabdeckung erreicht werden?
Nein! Das ist nicht die Lösung.
Mit einem normalen Testentwicklungsaufwand können für Unittests eine vernünftige Testabdeckung erreicht werden (ca. 80% ist realistisch, Treiber bilden eine Ausnahme). Dabei sollten möglichst Black-Box Tests der Unit verwendet werden.
Anschließend sollte der Quellcode geöffnet und durch Whitebox-Tests gezielt die Abdeckung weiter erhöht werden. Diese Whitebox-Tests sind natürlich nicht auf Anforderungen ableitbar – sind aber als Regressionstests für zukünftige Testausführungen sehr wertvoll. Bis zur Vervollständigung der 100% Testabdeckung sind dann Codereviews im SW-Entwicklungsplan zu definieren und natürlich auch durchzuführen.
Abbildung 8 Testverfahren zum Erzielen von 100% Code coverage.
Eine weitere Herangehensweise ist die des risikobasierten Ansatzes, um kritische Units tiefer und breiter zu testen. Dabei muss im Vorhinein festgelegt sein, für welches Risiko welche Testabdeckung minimal gefordert wird.
Hinweis
Da bei moderner Softwareentwicklung der Quellcode sowieso einem Codereview im Rahmen der Entwicklung unterliegt (ein Beispiel ist der git merge requests), kann immer argumentiert werden, dass damit bereits eine rudimentäre Prüfung stattfand. Eine Aufnahme in die Prozesslandschaft (z.B. Softwareentwicklungsplan) ist dabei zwingend erforderlich.
Testabdeckung – Typen
Im FDA Guidance Dokument General Principles of Software Validation (Kapitel 5.2.5) werden verschiedene Arten von Testabdeckung beschrieben. Im Folgenden sind drei der wichtigsten Abdeckungsarten gelistet:
Anweisungsabdeckung (Statement coverage):
Im FDA Guidance Dokument steht konkret, das statement coverage als ungenügend angesehen wird ‘its achievement is insufficient to provide confidence in a software product's behavior’.
Zweigabdeckung (decision coverage):
Die Zweigüberdeckung wird als Kriterium für die Testabdeckung für die meisten Softwareprodukte als akzeptabel angesehen: ‘It is considered to be a minimum level of coverage for most software products, but decision coverage alone is insufficient for high-integrity applications’.
Bedingungsabdeckung (condition coverage)
Es empfiehlt sich, eine MC/DC Modified condition/decision coverage (Mehrfach-Bedingungs-Entscheidungsüberdeckung) zu verwenden.
SOUP vs. OTS Evaluierung
Nutzung 3rd party software
Für die Softwareentwicklung bietet es sich an, auf Bibliotheken, Betriebssysteme und vorhandenen Sourcecode zu setzen, damit die Entwicklung vereinfacht und beschleunigt werden kann.
Vor der Verwendung der 3rd party software ist formal eine Evaluierung durchzuführen, welche Software verwendet werden sollte. Dabei sind die Anforderungen aufzustellen, die die Softwareentwicklung an die 3rd party Software hat und mögliche Varianten aufzulisten. Im deeply embedded Umfeld kann auch als Alternative ein Bare-Metal (also ohne jegliches Betriebssystem) als Variante der Entwicklung dienen.
Ein wichtiger Aspekt bei der Auswahl des Betriebssystems ist die Möglichkeit zum Debugging und Logging, sodass die Softwareentwicklung und spätere Fehleranalyse von Software bzw. Geräten im Feld einfach und zügig verlaufen.
SOUP vs. OTS-Software
Für Software, welche nicht für Medizinprodukte entwickelt wurde, unterscheiden sich die Anforderungen der IEC 62304 und FDA (USA).
SOUP bedeutet: Software of Unknown Provenance (deutsch: Software unbekannter Herkunft)
OTS bedeutet: Off-the-Shelf [Software] (deutsch: Software von der Stange)
Die beiden Begriffe scheinen äquivalent zu sein, im Detail gibt es doch kleinere Unterschiede:
Abbildung 9 SOUP vs. OTS-Software mit einer großen Schnittmenge.
Trotzdem deckt die Obermenge den größten Teil der Software ab, welche in einem Medizinprodukt (auch Stand-Alone) verwendet wird.
Die Unterschiede liegen in den Aufwänden, die für die Evaluierung -und damit der internen Freigabe zur Verwendung in einem Medizinprodukt- aufgewendet werden müssen.
Die FDA fordert – abhängig von der Kritikalität der jeweiligen Software – Maßnahmen, die im Extremfall bis zu einem Audit beim Hersteller der OTS-Software reichen können.
In der Praxis ist dies jedoch in den meisten Fällen – z. B. bei Herstellern wie Microsoft oder Google – kaum umsetzbar, da diese Anbieter in der Regel weder Einblick in ihre Entwicklungs- und Qualitätsprozesse gewähren noch individuelle Audits von Medizingeräteherstellern zulassen würden.
Die IEC 62304 fordert (Liste unvollständig) für SOUP Komponenten:
- Konfigurationsmanagement
- Risiko & Anforderungen von SOUP spezifizieren & verifizieren
- Prüfung der Systemvoraussetzungen (RAM, CPU,…)
Im FDA-Guidance Dokument: „Off-The-Shelf Software Use in Medical Devices“) wird folgendes von den Herstellern erwartet (Liste unvollständig):
- Basierend auf dem ‚Level of concern’ (basic oder enhanced) wird im enhanced level ein Audit bei dem Hersteller der OTS-Software verlangt „[…] this may include a review of the OTS software developer’s design and development methodologies […]” [Abschnitt III.D.1]
- OTS Evaluation Report inkl.
- Risikobewertung
- Konfigurationsmanagement
- Aufstellen und Prüfen der Anforderungen an OTS
- Beschreibung und Life-cycle des OTS
Empfehlung:
Bei der Auswahl des SOUP / OTS, gibt es teilweise die Möglichkeit, Testprotokolle und ähnliche Dokumente des Herstellers der Software zu erhalten. Dies ermöglicht eine leichtere OTS Evaluierung (Beispiel: SafeRTOS anstatt FreeRTOS) .
Alternativ kann durch Risikokontrollmaßnahmen die Klassifizierung der OTS gesenkt werden, sodass ein Audit beim Hersteller nicht mehr notwendig ist.
Fazit:
Der Aufwand einer OTS Evaluierung ist um einiges höher als eine SOUP Evaluierung. Da die FDA im Rahmen einer US-Zulassung grundsätzlich eine OTS-Evaluierung fordert, empfiehlt es sich, diese Anforderungen frühzeitig zu berücksichtigen und bereits im Softwareentwicklungsprozess zu integrieren.
Ein sauberes Risikomanagement kann helfen, die Kritikalität zu reduzieren und damit ermöglichen, 3rd party Software einzusetzen.
Auch sollte evaluiert werden, ob wirklich die Bibliotheken / ein Betriebssystem notwendig sind oder die Entwicklung z.B. auf Bare Metal speziell für deeply embedded realisiert werden kann.
Unser Newsletter „qonzentrat“
kompakt, professionell und präzise
Profitieren Sie von unserem Fachwissen.
Jetzt anmelden
