Dependability in der Medizintechnik

Zuverlässige Systeme sind branchenübergreifend für alle von uns von enormer Bedeutung. Sei es in der Medizintechnik, der Automobilindustrie, der Luftfahrt, Bahn- oder auch der Prozessindustrie – wir verlassen uns täglich auf technische Systeme – wir nennen das „Zuverlässigkeit“ („Dependability“). Das beinhaltet den Verbund aus sicherer Funktionalität, Ausfallsicherheit, Verfügbarkeit und Security. Speziell in der Medizintechnik sind oft ohnehin schon hilfsbedürftige Personen auf die Zuverlässigkeit von Produkten angewiesen – denken wir z. B. an Beatmungsgeräte oder Herzschrittmacher.
Regelmäßige Schlagzeilen zu sicherheitsrelevanten Systemen lehren uns aber auch, dass diese vom Kunden erwarteten Eigenschaften keinesfalls selbstverständlich erreichbar sind, denken wir z. B. an:

  • Boing 737 Max Unglücke [1]
  • Toyota Selbstbeschleuniger [2]
  • Medtronic Pacemaker mit Security-Lücken [3]

Neben den damit verbundenen Unglücken und Opfern sind die genannten Firmen finanziellem Risiko und nicht zuletzt erheblichen Imageschäden ausgesetzt. Zuverlässigkeit sollte somit an der Spitze der Produktziele stehen.

Grundkonzepte

Wie aber entwickelt man systematisch ein zuverlässiges Produkt? Ist es hinreichend ein Produkt „gut“ zu testen? Was heißt „gut“ testen? Ein sichereres System wird in der Regel als „frei von unzumutbarem Risiko“ definiert. Betrachtet man die typischen Ursachen für Fehler in nachfolgender Abbildung, wird klar, dass die Fehlerursachen weitaus vielfältiger sind, als dass sie sich allein durch Testen abdecken lassen. Auch sieht man, dass typische Fehlerursachen nur zu einem Bruchteil aus der eigentlichen Implementierung stammen.

Abbildung 1: Verteilung von typischen Fehlerursachen [4]

Normen wie die ISO 26262 für funktionale Sicherheit in der Automobilindustrie stellen dazu ein umfassendes Arbeitsmodell bereit, das den gesamten Entwicklungslebenszyklus abdeckt. Wenn auch über mehrere Standards verteilt (z. B. IEC 62304, IEC 60601, ISO 14791 und weitere) und nicht immer explizit formuliert, existieren ähnliche Anforderungen ganz klar auch in der Medizintechnik. Ziel ist es damit, die „bekannten Fehlerursachen“ umfassend zu berücksichtigen.
Im Folgenden werden nur einige ausgewählte Grundkonzepte vorgestellt, die in der Medizintechnik von Bedeutung sind.

  • Safety Management
    Systematisches Planen und Verfolgen von Safety-Aktivitäten muss Teil jeder Entwicklung eines sicherheitsrelevanten Systems sein. Neben selbstverständlichen Aktivitäten wie der regelmäßigen Planung von Reviews, müssen dabei auch evtl. weniger intuitive Aspekte wie Kompetenzmanagement oder die Planung einer verteilten Entwicklung berücksichtigt werden. Allen voran gilt aber: Safety ist kein Feature und muss über den gesamten Entwicklungslebenszyklus berücksichtigt werden. Folgende Abbildung zeigt dabei ein mögliches Vorgehen, um sich auf abstrakter Weise der Lösung zu nähern:

    Abbildung 2: Iteratives Vorgehensmodell

  • Risikomanagement
    In der Medizintechnik ist das Risikomanagement ein zentraler Bestandteil im Sicherheitslebenszyklus. Da sich Risiken immer nur auf der Top-Level-Systemebene auswirken, empfehlen wir die Durchführung einer Risikobewertung auf Systemebene und darauf aufbauend die Ableitung dedizierter Sicherheitsanforderungen entlang der sicherheitsrelevanten Wirkketten. (Anmerkung: Bei sehr komplexen und verteilten Systemen kann es durchaus sinnvoll sein, die Risikobewertung hierarchisch aufzubauen.)
  • Safety – Kultur
    Die Förderung und Pflege einer entsprechenden Kultur in einer Firma scheint auf den ersten Blick zunächst ein nebensächliches Thema für die Produktentwicklung zu sein. Man muss allerdings nur nachfolgende Beispiele für eine gute und schlechte Safety – Kultur betrachten, um zu sehen, dass damit sehr wohl Produkteigenschaften zum Guten oder Schlechten verändert werden können.
    Die folgende Tabelle enthält nur einige Beispiele für eine gute und schlechte Safety – Kultur.

    Beispiele für schlechte Safety – KulturBeispiele für gute Safety – Kultur
    Zeitplan und Kosten sind das höchste Ziel einer Produktentwicklung.Sicherheit hat höchste Priorität
    Prozesse werden „Adhoc“ oder implizit definiertEin definierter, tracebarer und kontrollierter Prozess wird auf allen Ebenen gelebt. (Management, Entwicklung, Verifikation, u. A. …)
    Entscheidungen werden über „Mehrheit“ getroffenEntscheidungen gehen saubere technische Analysen voraus und können objektiv getroffen werden
    Entscheidungen werden nur in Besprechungen ohne ausreichende Vorbereitung getroffen

    Ziel sollte es immer sein eine gute Safety – Kultur im Unternehmen zu etablieren. Objektiv vorhandene Fehler zu finden muss erlaubt und gewünscht sein. Dazu müssen Maßnahmen und Mechanismen etabliert werden diese effektiv aufzudecken und zu vermeiden.

  • Fehlervermeidung, Fehlererkennung und Fehlerbehandlung
    Über die Risikobewertung und die systematische Ableitung von Sicherheitsanforderungen wird die Grundlage für Vermeidung, Erkennung bzw. Behandlung von Fehlern auf verschiedenen Abstraktionsebenen gelegt. Schlagwort hier ist das Thema Erstfehlersicherheit.
    An dieser Stelle sollen insbesondere aber die Transitionen zwischen Fehlerursache („Fault“), Abweichung („Error“) und Ausfall („Failure“) betrachtet werden. Die folgenden Abbildungen veranschaulichen diese Übergänge einmal mit und einmal ohne Sicherheitsmechanismus.

    Abbildung 3: Zusammenhang zwischen Fehlerursachen und Ausfällen (ohne Safety Mechanismus)

    Abbildung 4: Zusammenhang zwischen Fehlerursache und Safety Mechanismus mit Emergency Operation

    In den Abbildungen wird schon auf den ersten Blick deutlich, dass viele oft nicht triviale Abhängigkeiten entlang der Wirkketten in einem System berücksichtigt werden müssen – Sicherheitsmechanismen müssen dementsprechend gestaltet sein und „geschickt“ entlang dieser Wirkketten verteilt sein. So kann es auch vorkommen, dass ein und derselbe technische Mechanismus verschieden wirksam in verschiedenen Systemen ist, da unterschiedliche Fehlerursachen zugrunde liegen können.
    Auch wird damit deutlich, dass zuverlässige Systeme nur mithilfe einer guten Systematik entwickelt werden können.

  • Sicherheitsanalysen
    Aspekte, die während der Designphase spezifiziert und implementiert wurden sollten mithilfe von Sicherheitsanalysen aus einer „anderen Perspektive“ kontinuierlich unabhängig bewertet und systematisch hinterfragt werden. Wichtige Grundlage für derartige Analysen sind immer Architektur und Design die sowohl statische als auch dynamische Aspekte beinhalten müssen.
    Wir empfehlen dazu eine Kombination aus Top-Down- (z. B. FTA) und Bottom-Up-Analysen (z. B. FME(D)A).
  • Traceability (Nachverfolgbarkeit)
    Neben vielen anderen Eigenschaften zählt die Traceability zu einer der wichtigsten Eigenschaften für das Anforderungsmanagement. Für uns ist gut gelebte Traceability allerdings mehr: Neben dem formalen Aspekt der Traceability für das Anforderungsmanagement, sollte Traceability auch inhaltlich einer fundamentalen Bedeutung zukommen. Gut gelebte Traceability hilft damit nicht nur während der Designphase, sondern bietet auch die Möglichkeit eine tragfähige Sicherheitsargumentation auszubauen.

Fazit

Die Entwicklung zuverlässiger Systeme ist ein komplexes Thema, das einer gesamtheitlichen Betrachtung entlang des ganzen Entwicklungslebenszyklus bedarf. Eine durchgängige Sicherheitsargumentation im Nachhinein einer schon bestehenden Entwicklung erstellen zu wollen ist in jedem Fall sehr riskant und wird nicht empfohlen. Abgeschlossene Entwicklungen sind zudem meist sehr starr und können nicht oder kaum verändert werden. Dadurch wird eine Sicherheitsargumentation entweder sehr kompliziert oder ist nur unter erheblichem kommerziellem Druck möglich.
Falls Sie an der Entwicklung sicherheitsrelevanter Systeme beteiligt sind, unterstützen unsere Experten von exida.com Sie gern – beginnend bei Gap-Analysen, Prozessmodellierungen, technischer Spezifikation und Sicherheitsanalysen bis hin zu Safety Assessments. Dabei bieten wie insbesondere auch Trainings an, die wir entweder in unseren eigenen Schulungsräumen oder auch in-house bei Ihnen durchführen können.

Links

[1] //www.seattletimes.com/business/boeing-aerospace/failed-certification-faa-missed-safety-issues-in-the-737-max-system-implicated-in-the-lion-air-crash/
[2] //www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware–Bad-design-and-its-consequences
[3] //www.medtronic.com/content/dam/medtronic-com/us-en/corporate/documents/REV-Medtronic-2090-Security-Bulletin_FNL.pdf
[4] “Out of Control: Why Control Systems go Wrong and How to Prevent Failure,” U.K.: Sheffield, Heath and Safety Executive, 1995

Auch interessant:

Requirements Engineering mit Enterprise Architect

Dieser Blog-Artikel soll allen helfen, die Anforderungsspezifikationen immer noch mit Word und Excel erstellen. Ich selbst habe auch lange den "Marktführer" für…

(Gast) Tim Jones

Herr Tim Jones ist als Functional Safety Consultant bei der exida.com GmbH tätig. Er verfügt über mehr als 10 Jahren Erfahrung in den Bereichen Systems und Software-Engineering, Signalverarbeitung und Projektmanagement für sicherheitsrelevante Produkte. Herr Jones studierte an der Fakultät für Elektrotechnik und Informationstechnik der TU Dresden. Nachdem er 2007 seine berufliche Laufbahn bei der Corscience GmbH & Co. KG in der Medizintechnik begonnen hatte, wechselte er 2013 als Experte für funktionale Sicherheit zur Elektrobit Automotive GmbH. Seit 2016 ist Herr Jones als Functional Safety Consultant bei der exida.com GmbH tätig. Sein Fokus liegt hier sowohl auf der Medizintechnik als auch der Automobilindustrie. Die exida.com GmbH ist Partner der MEDtech Ingenieur GmbH und unterstützt Kunden bei allen Fragen rund um sicherheitsrelevante Systeme.

Getagged mit: , , , , , , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.