Firmware für Medizinprodukte, IEC-62304-Dokumentation entsteht parallel zur Entwicklung

Ja. Zunächst prüfen wir Code, Dokumente und Entwicklungsprozess in einer Gap-Analyse. Anschließend leiten wir die fehlenden Dokumente aus dem vorhandenen Code ab.

Ja. Zuerst gliedern wir die Firmware in testbare Module und ergänzen einen Simulationsmodus, soweit die Hardwareabhängigkeiten dies zulassen. So prüft die CI jede Änderung, bevor sie auf das Board gelangt. Die abschließende Release-Verifizierung erfolgt auf dem Zielsystem.

Wir verwenden signierte Images und einen Bootloader, der nach fehlgeschlagenen Updates das zuvor freigegebene Image wiederherstellt. Ein Sicherheitszähler verhindert Downgrades auf ältere, verwundbare Images. Auch nach unterbrochenen Updates kann die Firmware wiederhergestellt werden. Alle diese Funktionen berücksichtigen wir in der Risikomanagementakte und im Bedrohungsmodell.

Ja. Wir testen auf Hardware-in-the-Loop-Testständen, die auf Ihr Board abgestimmt sind. Zusätzlich prüfen wir jede Änderung in der Simulation.

Ja. Firmware, begleitende App und Cloud-Backend können wir nach einem gemeinsamen Entwicklungsplan entwickeln.

Wir entwickeln direkt für die Hardware. Unsere Embedded-Entwickler programmieren Mikrocontroller in C und C++, sowohl auf Bare Metal als auch mit RTOS. Wir übernehmen Board Bring-up, Treiber, Hardware-Abstraktionsschicht, Steuerlogik und Bedienoberflächen am Gerät.

Ja. Unsere Entwickler haben mit Nordic nRF52 und dem nRF Connect SDK auf Zephyr gearbeitet. Weitere Erfahrungen umfassen STM32 mit FreeRTOS, ESP32 und Bare-Metal-Zielsysteme.

Wir entwickeln Software der Klassen A, B und C. Die Sicherheitsklasse jedes Softwareelements bestimmt, welche Aktivitäten nach IEC 62304 erforderlich sind. Für die Klassen B und C gehört dazu beispielsweise die Verifizierung der Software-Einheiten, für Klasse C zusätzlich das detaillierte Design. Maßnahmen zur Risikobeherrschung verknüpfen wir rückverfolgbar mit der Risikomanagementakte nach ISO 14971 innerhalb Ihres ISO-13485-Qualitätsmanagementsystems.

Ja. Wir erstellen die Unterlagen entsprechend dem von der FDA geforderten Documentation Level, Basic oder Enhanced gemäß der Software-Guidance von 2023. Dieser Level wird unabhängig von der Sicherheitsklasse nach IEC 62304 festgelegt. Dazu gehören Architektur, gegebenenfalls Software Design Specification, Anforderungen, Rückverfolgbarkeit und Verifizierungsspezifikationen. Außerdem erstellen wir SOUP-Liste, Bedrohungsmodell, Cybersicherheitsrisikobewertung und SBOM. Wir leiten die Dokumente aus dem vorhandenen Code ab und bereiten sie für die eSTAR-Einreichung auf. Bei einem Cyber Device nach Section 524B dokumentieren wir zusätzlich den Plan für das Schwachstellenmanagement nach dem Inverkehrbringen und die SBOM. Fehlen Protokolle ausgeführter Tests, benennt die Gap-Analyse die Tests, die vor der Einreichung noch durchzuführen sind.

Zephyr und Anbieter-SDKs gelten als SOUP, wenn für sie kein Entwicklungsnachweis nach IEC 62304 vorliegt. Jede Komponente, die in die Firmware eingeht, erfassen wir in der SBOM. Fehlt der Entwicklungsnachweis nach IEC 62304, erfassen wir sie zusätzlich in der SOUP-Liste. Dort dokumentieren wir Version, bekannte Anomalien und Risikobewertung. Updates steuern wir über Change Control. Einen Bootloader oder ein Modul, das wir nach IEC 62304 entwickeln, behandeln wir als Softwareelement und nicht als SOUP.

Ja. Wir entwickeln GATT-Design, Pairing, Bonding, verschlüsselte Verbindungen, automatische Wiederverbindung, Datenpufferung und Low-Power-Betrieb. Bei Bedarf entwickeln wir auch die begleitende App.

Eine Gap-Analyse beginnen wir innerhalb von zwei Wochen nach Auftragserteilung. Ein Entwicklungsteam kann innerhalb von zwei bis drei Wochen nach Vertragsunterzeichnung starten. Sie erhalten ein individuelles Angebot, sobald wir Code und Dokumente erstmals gesichtet haben.

Ja. Wir setzen MCUboot als sicheren Bootloader für signierte Firmware-Updates ein. Nach fehlgeschlagenen Updates stellt er das zuvor freigegebene Image wieder her. Ein Sicherheitszähler schützt vor Downgrades. MicroPython verwenden wir auf Mikrocontrollern wie dem ESP32, beispielsweise in Labor- und Forschungsinstrumenten. Als Bedienoberfläche dient dabei eine separate Python-Anwendung auf dem PC.