Warum FPGAs in Medizinprodukten zunehmend in den Fokus von Software-Audits geraten und wie Sie regulatorische Risiken frühzeitig vermeiden.
Wenn programmierbare Logik plötzlich im Software-Audit landet, kann es schnell ungemütlich werden, wenn der Auditor Sie fragt: „Wo ist Ihre IEC-62304-Dokumentation für den FPGA?“
Diesen Satz hören MedTech-Teams immer häufiger und oftmals überraschend spät im Projekt oder sogar erst im Audit. Die erste Reaktion ist dann meist:
„Das ist doch Hardware.“
„Da läuft kein Code.“
„Der FPGA ist nicht updatefähig.“
Und technisch betrachtet ist das völlig richtig. Dennoch entsteht genau an dieser Stelle regelmäßig zähe Diskussionen in Medizintechnik-Projekten: Ist ein FPGA Software oder nicht?
Ein FPGA (Field Programmable Gate Array) ist ein programmierbarer Logikbaustein, der digitale Schaltungen flexibel in Hardware abbilden kann. Anders als klassische Mikrocontroller oder Prozessoren arbeitet ein FPGA nicht mit sequenziell ausgeführtem Software-Code, sondern mit parallel aufgebauter Logik. Dadurch eignen sich FPGAs besonders für Anwendungen mit hoher Geschwindigkeit, geringster Latenz und deterministischem Echtzeitverhalten.
In der Medizintechnik werden FPGAs häufig für sicherheitskritische Funktionen, Signalverarbeitung, Überwachungslogik oder schnelle Datenverarbeitung eingesetzt. Typische Einsatzbereiche sind bildgebende Systeme, Patientenmonitoring, Diagnostikgeräte oder Steuerungssysteme mit hohen Echtzeitanforderungen.
Da FPGAs komplexe Entscheidungen und sicherheitsrelevante Funktionen übernehmen können, rücken sie zunehmend auch regulatorisch in den Fokus – insbesondere durch IEC 62304 und der Softwarebewertung von Medizinprodukten.
Goran Madzar
Systems Engineer & CEO @MEdtech Ingenieur
Warum FPGAs in der Medizintechnik regulatorisch relevant werden
FPGAs, CPLDs und andere programmierbare Logikbausteine werden in modernen Medizinprodukten gezielt dort eingesetzt, wo hohe Performanz, deterministisches Echtzeitverhalten und komplexe logische Entscheidungen erforderlich sind.
Typische Gründe für den Einsatz von FPGAs/PLDs in der Medizintechnik sind insbesondere:
- hohe Performanz und geringe Latenz
- echte Parallelverarbeitung
- deterministisches Echtzeitverhalten
- komplexe logische Entscheidungen
- State-Machines
- Überwachungs- und Plausibilitätslogik
- zeitkritische Signalverarbeitung
- Filter, Trigger, Codierung/Decodierung
- architektonische Trennung
- unabhängige Safety-Layer
- Überwachung der Firmware
- Determinismus
- kein Scheduling
- keine Interrupt-Kaskaden
- kein Betriebssystem
Genau diese Eigenschaften machen FPGAs attraktiv für sicherheitskritische Funktionen – und das ist der eigentliche Grund, warum sie regulatorisch ins Blickfeld geraten. IEC 62304, FDA-Guidance und Benannte Stellen schauen dabei weniger auf die verwendete Technologie, sondern auf die systematische Funktion, die ein Element im Gesamtsystem übernimmt. Nicht wie etwas implementiert ist, steht im Fokus, sondern was es tut. Und sobald diese funktional „softwareähnlich“ ist, rückt IEC 62304 unweigerlich in den Fokus.
FPGA und IEC 62304: Ingenieur-Sicht vs. Auditoren-Sicht
Aus Sicht der Entwicklung ist die Lage meist klar:
- Der FPGA wird einmalig programmiert
- Er ist im Feld nicht rekonfigurierbar
- Er verhält sich deterministisch wie eine fest verdrahtete Logik
- VHDL/Verilog beschreibt Struktur, keine Ablaufsteuerung
- Es gibt keinen Prozessor, keine Instruktionen, kein Betriebssystem
All diese Punkte sind technisch korrekt und wichtig. Die regulatorische Sicht setzt jedoch an einer anderen Stelle an. Sie fragt nicht nach der Programmiersprache, sondern nach der Verantwortung im System:
- Trifft der FPGA Entscheidungen?
- Bewertet er Zustände oder Grenzwerte?
- Löst er sicherheitsrelevante Aktionen aus?
Wenn die Antwort „ja“ lautet, landet der FPGA zwangsläufig in der Software-Diskussion, unabhängig davon, ob er mit C-Code oder HDL beschrieben wird.
Wann ein FPGA als Software betrachtet wird
In der Praxis entsteht die kritische Diskussion meist dann, wenn der FPGA:
- sicherheitsrelevante Grenzwerte überwacht
- Zustände bewertet oder klassifiziert
- Abschaltungen oder Not-Halt-Signale auslöst
- unabhängig von der Firmware Entscheidungen trifft
Dass der FPGA in VHDL programmiert ist und nicht in C spielt dabei keine Rolle. Je mehr sicherheitsrelevante Logik in den FPGA verlagert wird, desto stärker erwarten Auditoren und Behörden eine strukturierte, nachvollziehbare Entwicklungs- und Dokumentationsstrategie.
Konkrete Praxis: IEC 62304-Dokumentation für FPGA-Projekte
Für die Praxis lassen sich einige klare Lehren ziehen:
- Die Einordnung des FPGA sollte früh im Projekt erfolgen
- Architekturentscheidungen müssen sauber dokumentiert sein
- Die Risikoargumentation darf kein nachträglicher „Audit-Fix“ sein
- Normen sollten als Werkzeug genutzt werden und nicht als Zwangsjacke
Wer diese Punkte berücksichtigt, reduziert den Dokumentationsaufwand erheblich und vermeidet unangenehme Überraschungen im Audit oder kurz vor der Zulassung.
FPGA-Gap-Analyse für regulatorische Sicherheit
Wenn ein FPGA sicherheitsrelevante Funktionen übernimmt, stellt sich schnell die Frage, wie er sinnvoll und auditfest in die IEC 62304-Dokumentation eingebunden werden kann – ohne unnötigen Overhead, aber mit regulatorischer Sicherheit.
Ein bewährter erster Schritt ist eine IEC 62304-Gap-Analyse, um:
- die Rolle des FPGA im System klar einzuordnen
- relevante Normanforderungen strukturiert zu bewerten
- Dokumentationslücken frühzeitig zu erkennen
- den tatsächlichen Aufwand realistisch abzuschätzen
Mehr Informationen dazu finden Sie auf unserer Seite zur IEC-62304 Gap Analyse: