Das Akronym FPGA steht für Field Programmable Gate Array. FPGA sind programmierbare integrierte Schaltkreise, die auch in der Medizintechnik Anwendung finden. Lesen Sie hier, welche regulatorischen Anforderungen Sie bei FPGA erfüllen sollten.
FPGA in der Medizintechnik
Implementierung in Hardware oder Software?
Hersteller von aktiven Medizinprodukten führen bei der Entwicklung eine Dekomposition der Systeme durch. D.h. sie zerlegen das gesamte Produkt in einzelne Komponenten,
- an die sie Anforderungen stellen,
- die sie stückweise entwickeln und schließlich
- zum fertigen Produkt – hier einem PEMS (programmierbaren elektrischen medizinischen System) – zusammensetzen.
Einige dieser Komponenten sind programmierbare elektrische Subsysteme (PESS). Die Hersteller stehen nun vor der Wahl, in welchen Anteilen sie die Anforderungen und damit die spezifische Funktionalität durch Software oder Hardware implementieren.
Im einen Extrem nutzen die Hersteller eine Standard-Hardware z.B. PC-basierte Systeme bzw. generische Mikrocontroller, für die sie eine Software entwickeln, die die spezifische Funktionalität bereitstellt.
Im anderen Extrem entwickeln die Hersteller eine hochspezifische Hardware/Elektronik, um die Funktionalität zu implementieren.
Beide Varianten haben Vor- und Nachteile:
| Aspekt | Implementierung in Software | Implementierung in Hardware |
| Entwicklungsgeschwindigkeit, Flexibilität | Hoch | Niedrig (Änderungen bedürften neuer Hardware) |
| Produktkosten | Höher, da Hardware oft mehr bereitstellt, als benötigt wird.
Allerdings vergleichsweise niedrige Kosten, weil Standard-Hardware in hohen Stückzahlen produziert wird. |
Niedrig, weil genau die benötigten (meist preisgünstigen) Bauteile verwendet werden.
Allerdings sind Kosten für Änderungen hoch. |
| Leistungsfähigkeit | Niedrig | Hoch (da darauf optimierbar) |
| Typische Kompetenzanforderungen | Software-Entwickler | Elektro-Ingenieure |
Implementierung mit FPGA
Als dritte Möglichkeit bieten sich FPGA an, die auch eine Programmierung erlauben, allerdings nicht wie bei normaler Software der zeitlichen und logischen Abläufe, sondern der Funktionsstruktur dieser Baustein.
FPGA vereinen in gewisser Weise viele Vor- und Nachteile der anderen Lösungen:
Vorteile
- Hoch performante Bauteile
- Niedrige Hardwarekosten
- Schnelle Entwicklung (Prototypen bedürfen beispielsweise nicht regelmäßiger Änderungen von Platinen)
Nachteile
- Änderungen nicht so schnell und kostengünstig möglich wie bei Software (durch Update)
- Entwickler muss sich in Hard- und Software gut auskennen
- Regulatorische Anforderungen (s.u.)
Regulatorische Anforderungen an FPGA
Anwendbarkeit der IEC 62304
Die schlechte Nachricht vorweg: Die IEC 62304 fühlt sich für die FPGA anwendbar. Das macht der Anhang I:2015 nochmals klar. Jede Anweisung an einen Prozessor betrachtet man als Software und damit im Anwendungsbereich der Norm.
Damit müssen FPGA – genauer gesagt deren Programmierung – die Anforderungen der IEC 62304 erfüllen.
Anforderungen der IEC 62304
Damit müssen Hersteller – abhängig von der Sicherheitsklasse – alle Anforderungen der Norm erfüllen:
- Entwicklungsplan erstellen
- Software-Anforderungen spezifizieren
- Software-Architektur und detailliertes Design beschreiben
- Akzeptanzkriterien an Software-Einheiten bestimmen und überprüfen
- Integrations– und Software-Systemtests durchführen
- Software freigeben
Normative Anforderungen bei FPGA erfüllen
Auch wenn sich die Norm für FPGA zuständig fühlt: Die IEC-62304-Autoren scheinen sich nur bedingt Gedanken darüber gemacht haben, wie man die Anforderungen der Norm in der Praxis erfüllen kann. Teilweise geht das gar nicht. Daher hier unsere Vorschläge:
| Forderung der IEC 62304 | Umsetzung bei FPGA |
| Entwicklungsplan erstellen | Legen Sie den Prozess, die Methoden und Werkzeuge fest. Diese Forderung können Sie problemlos umsetzen. |
| Software-Anforderungen spezifizieren | Wie immer beschreiben Sie Anforderungen als Spezifikation einer Blackbox. D.h. Sie beschreiben, wie sich der FPGA über die Schnittstellen (I/O) verhalten. Dazu zählen auch Pegelstandards, Timing, Terminierung und Taktung. |
| Software-Architektur und detailliertes Design beschreiben | Das wesentliche Element Ihrer „Architektur“ ist das Planungsdokument in einer Beschreibungssprache (z.B. VHDL). Auch bestehende oder wiederverwendete Elemente wie DSP, FlipFlops könnten zumindest genannt werden. |
| Akzeptanzkriterien an Software-Einheiten bestimmen und überprüfen | Eine Form der Überprüfung kann ein Review der Planungsdokumente sein – auch wenn das genauso als Verifizierung der „Architektur“ dient. |
| Integrations- und Systemtests durchführen | Integrationstests werden in der Regel nicht gelingen. Die Software-Systemtests sind nicht auf reinem Software-Level möglich. Der Systemtest wird ein Test des gesamten FPGA-Bausteins sein. Das ergibt auch Sinn, weil Sie dafür die Anforderungen spezifiziert haben. |
| Software freigeben | Dieser finale Schritt gelingt genau wie bei „normaler“ Software. |
Das automatisierte Regressionstesten bei einem FPGA wird nicht (so einfach) wie bei einer standalone Software gelingen. Sie benötigen dazu entweder die physische Hardware oder/und einen Simulator.
FPGA und FDA
Die FDA möchte ebenfalls ihre Anforderungen an die Software-Entwicklung auch bei FPGA erfüllt wissen. Damit sollten Sie die in der Tabelle genannten Empfehlungen auch in einem FDA-Kontext beachten. Übrigens: Der Level-of-Concern bestimmt nicht die Menge der zu erstellenden Dokumentation, sondern nur die Menge der einzureichenden.
Hallo Herr Johner,
können Sie nochmal genauer erklären an welcher Stelle die 62304 für die FPGA anwendbar ist? Ich habe die Stelle(n) nicht auf Anhieb gefunden.
Liebe Grüße,
Philipp
Die 62304 erwähnt nicht die FPGAs wörtlich, sagt aber, dass sie für Software anwendbar sei „which executes on a processor“. Die Autoren sprechen auch von Prozessoranweisungen, die die FPGAs 62304-relevant machen würden.
Wie geschrieben: Die Umsetzbarkeit der Norm kann kritisch hinterfragt werden. Daher hoffe ich, dass meine Tipps nützlich sind.
Hallo Herr Johner,
ich möchte noch ein Kommentar dazu abgeben, und eine damit in Verbindung stehende Frag an Sie richten.
Sollte de FPGA sw schon vor inkraft treten der 6203 entwickelt worden sein. Kann die sw doch nach meiner Meinung auch als SOUP deklariert werde, oder?
FPGA ist in der Regel kein Teil einer Software, sondern ein Software-System für sich. Daher kann man die neuen Regeln bezüglich Legacy Software anwenden.
Im EU Bereich ist es generell möglich, dass man alte SW als SOUP kapselt. Aber im FDA Kontext geht das nicht. OTS ist anders definiert als SOUP.
Hallo,
wie ist Ihre Einschätzung bzgl. CPLDs?
analog
Hallo
Software ist definiert als etwas was auf einem Prozessor abläuft. Ein FPGA kann hingegen doch reine Logik sein, wo nie ein Instruktions-Set abgearbeitet wird (im einfachsten Fall ein And-Gatter). In solch einem Fall würde das FPGA nicht unter die 62304 fallen, richtig?
Danke für Ihre Rückmeldung
Offizielle Antwort: FPGA ist Software, IEC 62304 ist offiziell anwendbar — praktisch natürlich kaum.
Mein Tipp: Schlagen Sie es der Hardware zu und „verkaufen“ Sie es als Spezial-Chip, wenn jemand fragt — und nur dann.
Die Diskussionen mit Auditoren, die von FPGA keine Ahnung haben, sind oft nur schwer zu ertragen und selten zu gewinnen.
Ich kann mich Herrn Seidenberg nur anschliessen, „which executes on a processor“ trifft für ein reines FPGA (kein SoC, Zynq oder ähnliches und kein FPGA mit einen SoftProzessor, wie MicroBlaze oder Nios) nicht zu, es gibt keinen Prozessor in einem reinen FPGA oder CPLD, „nur“ Look-Up Tabellen und Register. In meinen bisherigen Projekten aus dem Luftfahrt- und Automotive-Umfeld wurde das FPGA auch immer als Hardware betrachtet.
Sehr geehrter Herr Professor Johner,
eigentlich trifft „which executes on a processor“ nicht unbedingt auf ein FPGA zu (ein FPGA ist nicht zwingend eine Turingmaschine, kann aber durchaus als solche programmiert werden). In der Luftfahrt gibt es hier auch immer wieder die gleiche Diskussion (DO-254 / DO-178B).
Ich wuede das anders begruenden und m.E. sollte es auch so normativ erfasst werden: Fuer die Erzeugung des FPGA-Codes bedarf es eines Compilers. Selbst wenn dieser syntaktischen Fehler erkennt kann ein semantischer Fehler (durch den Programmierer, z.B ist in Verilog if … then … und if … then … else syntaktisch korrekt, im ersten Falle entsteht normalerweise ein Register, im zweiten normalerweise ein Multiplexer) durchaus zu einer aehnlichen Gefaehrdung fuehren wie die Fehlfunktion einer Software, die auf einem Prozessor laeuft. Die Anwendung der IEC 62304 ist also m.E. fuer Prozessoren und FPGAs anzuraten. Ich haette hier die Art der Generierung des ausfuehrbaren Codes – egal ob Prozessor oder FPGA – in den Vordergrund gestellt.
Sehr geehrter Herr Johner,
wie stellt sich die Sachlage bei CPLDs dar, die bspw. festgebrannt werden (d.h. z.B. Fuse oder Anti-Fuse Technology). Diese sind meinem Empfinden nach näher an einem ASIC oder einem zukaufbaren IC als einem softwarebasierten System ?
VG
ergänzend dazu noch:
Gedanke zielte in Richtung Verifizierbarkeit ab.
Wenn es sich um ein einfaches System handelt, dass bpsw. komplett durch äußere Tests (Hardware in the Loop oder funktional) prüfbar ist.
Sehr geehrter Herr Marterstock,
ich teile Ihre Meinung: Ich würde das der Hardware zuschlagen. Ein „vernünftiger“ und isolierter Software-Test ist kaum möglich, das Testen auf der Zielhardware bleibt meist die einzig gangbare Option.
Besten Dank und viele Grüße (nach SW, D15??)
Christian Johner
nach SW 🙂
Beste Grüße