Sie sind hier: HomeRubrikenEmbedded Systeme

News, Produkte, Fachartikel zur KFZ-Elektronik: Motorsteuerungen, Infotainment, Telematik, Fahrwerkselektronik.

Softwareentwicklung nach EN 62304: Teil 1: Normkonformes Design

Mit dem steigenden Anteil der durch Software realisierten Funktionalität in medizinischen Geräten sowie der zunehmenden Interoperabilität zwischen den Geräten wird es immer schwieriger, ihre Sicherheit nachzuweisen. Das gilt insbesondere für die Software selbst

Auch die Softwar muss Norm erfüllen. Bildquelle: © Pixabay

Auch die Software muss Normen erfüllen.

In einer freien Interpretation der EU-Richtlinie ist ein Medizingerät, ein Produkt – Instrument, Apparat, Software, Material, etc. – das zur Diagnose, Behandlung, Überwachung, Untersuchung oder Kompensation von Krankheiten, Verletzungen sowie Behinderungen angewendet wird. Mit Ausnahme von Medikamenten schließt eine solche Definition nahezu den gesamten Markt an Medizinprodukten ein – inklusiver Software. Deren Zuverlässigkeit und die mit der zunehmenden Anzahl an technischen Geräten einhergehend Risiken sind zu einem lebenswichtigen Aspekt geworden.

Als Reaktion hierauf wurde im Jahr 2006 die Funktionssicherheits-Norm IEC 62304  (Medizingeräte-Software – Software-Lebenszyklus-Prozesse) herausgegeben. Sie legt einen Rahmen für die Lebenszyklus-Prozesse (Bild 1) von Medizingeräte-Software fest, die innerhalb eines und zwischen verschiedenen Projektteams verstanden und geteilt werden können. Konkret werden fünf Themenbereiche adressiert: Entwicklung, Wartung, Risikomanagement, Konfigurationsmanagement und Problemlösung. Die Norm gilt für Software, die selbst ein Medizingerät ist, die als Komponente, Teil oder Zubehör genutzt wird oder in der Produktion eines Medizingeräts zum Einsatz kommt.

Definition der Sicherheitsklassen

Die IEC 62304 verlangt vom Hersteller, dass er die Software einer Sicherheitsklasse zuordnet. Die Norm unterscheidet dabei drei Software-Sicherheitsklassifizierungen: Es sind keine Verletzungen oder gesundheitlichen Schäden möglich (Klasse A), es sind keine ernsten Verletzungen möglich (Klasse B) und es sind ernste Verletzungen oder Tod möglich (Klasse C). Wie das Projekt eingestuft wird, wirkt sich auch auf den Codeentwicklungs-Prozess aus – von der Planung über die Entwicklung, das Testen und die Verifikation bis zur Freigabe und darüber hinaus. Somit liegt es im Interesse der Medizingeräte-Hersteller, gleich im ersten Anlauf alles richtig zu machen, um teure und zeitaufwändige Nacharbeiten zu vermeiden.

In der Praxis wird jedes Unternehmen die Verifikation, die Integration und das Testen bei jeder Software anwenden – unabhängig von ihrer Sicherheitseinstufung. Die Gründlichkeit, mit der diese Aktivitäten durchgeführt werden, variiert jedoch erheblich. Zum Beispiel besagt die Norm: »Der Hersteller hat für jedes Modul des Softwarebausteins ein detailliertes Design zu entwickeln und zu dokumentieren«. Das gilt jedoch nur für Codes der Klasse C, nicht aber für die Klassen A und B.

Bild 1. Softwareentwicklungs-Prozesse und -Aktivitäten im Überblick Bildquelle: © LDRA

Bild 1. Softwareentwicklungs-Prozesse und -Aktivitäten im Überblick