Dynamische Softwareanalyse
Sicher trotz COTS-Software
Fortsetzung des Artikels von Teil 2
Ziel der Analyse
Dynamische Codeanalyse kann sowohl intrusiv als auch nicht-intrusiv erfolgen. Ein intrusiver Test fügt Prüfcodefragmente (Zähler oder Funktionsaufrufe) in den zu analysierenden Code ein. Diese Codefragmente sammeln Daten über die Prozessausführung und legen Historien zum Programmablauf an. Für die Gültigkeit der Analyse ist es wichtig sicherzustellen, dass die Prüfcodefragmente die Funktion des instrumentierten Codes nicht verändern. Weiterhin muss man üblicherweise auch nachweisen, dass der eingefügte Prüfcode keine Schwächen des Compilers offenlegt. Dazu kann man eine Compiler-Validation-Suite verwenden (eine Sammlung von Quellcodeabschnitten, die extra zum Nachweis der korrekten Arbeit des Compilers entworfen wurden) und zeigen, dass die Instrumentierung die Integrität des Compilers nicht beeinträchtigt.
Ein nicht-intrusives System ermittelt die gleichen oder ähnliche Daten wie ein intrusives System, bezieht diese aber direkt vom Prozessor. Das Werkzeug für dynamische Analyse setzt dann diese Low-Level-Informationen wieder in Beziehung zur ursprünglichen Darstellung des Programms (Hochsprache oder Assembler). Leider ist eine eindeutige Zuordnung aus vielerlei Gründen (z.B. Optimierung durch den Compiler) nicht immer möglich.
Ziel der Analyse
Das Ziel besteht insgesamt nicht darin, nachzuweisen, dass die Software komplett fehlerfrei ist, sondern darin, Nachweise für eine Abschätzung der Verlässlichkeit der Software zu liefern. Insbesondere wenn in unserem System SOUP zum Einsatz kommt, kann die strukturelle Überdeckungsanalyse nachweisen, dass es keinen nicht verwendeten oder überflüssigen Code gibt (Bild 3), wie es zum Beispiel ANSI/AAMI/IEC TIR80002-1:2009 in Tabelle B.2 fordert: »Verwenden Sie nur die benötigten SOUP-Features und entfernen Sie alle übrigen.«
Eine der schwierigsten Fragestellungen bei jeder Systemvalidierung ist die Entscheidung, wann man ausreichend getestet hat. Diese Entscheidung sollte im Kontext der Anforderungen an die Verlässlichkeit des Systems fallen. Letztlich hängt es von der IEC 62304 und der Sicherheitsklassifizierung des Medizingeräts durch die Zulassungsstellen ab. Überdeckungskenndaten helfen bei der Abschätzung, wie umfassend die dynamischen Tests waren und wie viel Testarbeit noch zu tun bleibt. Diese Kenndaten sind unter anderem:
- Anweisungsüberdeckung: Anteil der ausgeführten Anweisungen am Gesamtsystem.
- Bedingungs-/Entscheidungsüberdeckung: Anteil der abgedeckten Zweige im Programmablauf. Im Mittel wird jede Anweisung und jede Funktion doppelt so oft ausgeführt wie bei der Anweisungsüberdeckung.
- Modifizierter Bedingungs-/Entscheidungsüberdeckungstest (MC/DC Coverage): MC/DC-Überdeckung ist erfüllt, wenn jeder Einsprungs- und Aussprungspunkt des Programms einmal aufgerufen wurde, bei einer Entscheidung im Programmablauf jede Bedingung mindestens einmal alle möglichen Werte angenommen hat und die Atomarität der Bedingungen gezeigt wurde, das heißt, dass jede Bedingung das Ergebnis der Entscheidung unabhängig beeinflusst.
Ein nicht-intrusives System ermittelt die gleichen oder ähnliche Daten wie ein intrusives System, bezieht diese aber direkt vom Prozessor. Das Werkzeug für dynamische Analyse setzt dann diese Low-Level-Informationen wieder in Beziehung zur ursprünglichen Darstellung des Programms (Hochsprache oder Assembler). Leider ist eine eindeutige Zuordnung aus vielerlei Gründen (z.B. Optimierung durch den Compiler) nicht immer möglich.
Ziel der Analyse
Das Ziel besteht insgesamt nicht darin, nachzuweisen, dass die Software komplett fehlerfrei ist, sondern darin, Nachweise für eine Abschätzung der Verlässlichkeit der Software zu liefern. Insbesondere wenn in unserem System SOUP zum Einsatz kommt, kann die strukturelle Überdeckungsanalyse nachweisen, dass es keinen nicht verwendeten oder überflüssigen Code gibt (Bild 3), wie es zum Beispiel ANSI/AAMI/IEC TIR80002-1:2009 in Tabelle B.2 fordert: »Verwenden Sie nur die benötigten SOUP-Features und entfernen Sie alle übrigen.«
- Sicher trotz COTS-Software
- Was sind »COTS«, »SOUP« oder »clear SOUP«?
- Ziel der Analyse
- Anforderungen an ein COTS-Betriebssystem
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Video Entwicklerforum Medizinelektronik
Steigender Software-Anteil und Sicherheit sind wichtige Trends
Elektronische Patientenakte am Intensivbett
Mehr Zeit für die Therapie
Systementwicklung
Medizin wird agil
Normengerechte Entwicklung
COTS-Software für medizinische Geräte?
Software-Lifecycle-Management für medizinische…
Updates - Alarmstufe Rot!
