Entwickler prüft eine Build-Pipeline und Testergebnisse

Branchen · Entwicklungspartner und Auftragsfertiger

Auftragsfertiger, die das komplette Gerät einschließlich Software liefern.

Kunden verlangen das komplette Gerät, von der Mechanik über die Elektronik und Fertigung bis zur Software. Die Softwaredokumentation muss sowohl das Audit Ihres Kunden als auch Ihr eigenes bestehen. Wir entwickeln Firmware und Anwendungssoftware, verifizieren sie und erstellen die Dokumentation nach IEC 62304. Dabei arbeiten wir als benannter Unterauftragnehmer oder als White-Label-Partner unter Ihrem Namen und nach Ihrem Qualitätsmanagementsystem für die EU MDR und die FDA. Benötigt das Projekt auch Elektronik- oder Mechanikentwicklung, beziehen wir Partner ein, mit denen wir seit Jahren zusammenarbeiten.

30-minütiges Gespräch buchen Schreiben Sie uns

Lieferform: Unterauftrag oder White Label
Normen: IEC 62304 · ISO 13485 · ISO 14971 · IEC 62366-1
Erster Schritt: Kostenloses 30-minütiges Gespräch mit der Entwicklung

Der Weg der Software

Ein Geräteprojekt vom Angebot bis zur Designübergabe.

Angebot

Ein Kunde fragt nach dem kompletten Gerät. Mechanik, Elektronik und Fertigung übernehmen Sie selbst, aber Ihrem Team fehlen Softwareentwickler.

VerbesserungWir entwickeln die Software, damit Sie das komplette Gerät anbieten können.

Plan und Sicherheitsklasse

Die Sicherheitsklasse wird festgelegt, bevor die Risikoanalyse des Geräts vorliegt.

VerbesserungWir erstellen den Plan gemeinsam mit Ihrem Hardware- und Risikoteam. Die Sicherheitsklasse leiten wir aus den Risiken des Geräts ab.

Anforderungen und Schnittstelle

Ein inzwischen ausgeschiedener Entwickler hat die Prototyp-Firmware geschrieben. Es fehlen Anforderungen und ein Architekturdokument.

VerbesserungMit einer Gap-Analyse und bei Bedarf einem Refactoring machen wir aus dem Prototyp testbaren Code.

Entwicklung

Firmware, Anwendung und Backend werden von verschiedenen Personen gebaut, ohne gemeinsame SOUP-Liste (Software unbekannter Herkunft, also Code von Drittanbietern, der im Gerät verwendet wird).

VerbesserungWir entwickeln alle drei im selben Entwicklungszyklus und erstellen die SOUP-Liste in den ersten Wochen.

Verifizierung

Tests müssen bis zur nächsten Prototypenserie warten. Firmware, die alle Tests bestanden hat, funktioniert auf einer neuen Platinenrevision nicht mehr.

VerbesserungWir führen Tests mithilfe einer Simulationsschicht durch. Hardware-in-the-Loop-Tests laufen auf den Platinen, die Sie bereitstellen.

Cybersecurity-Dokumentation

Erst kurz vor der Einreichung wird die Cybersicherheit geprüft. Dann lässt sich eine Schwachstelle im Hardwaredesign nicht mehr beheben.

VerbesserungWir analysieren Sicherheitsrisiken bereits bei der ersten Architektur, solange wir Hardware und Software noch ändern können, um Schwachstellen zu schließen.

Design-Transfer

Die Benannte Stelle (die unabhängige Organisation, die ein Produkt nach der EU MDR zertifiziert) Ihres Kunden liest die Softwareakte, als hätte der Kunde sie selbst geschrieben, und die Lücken fallen auf Sie zurück.

VerbesserungWir erstellen die Dokumentation von Anfang an nach dem Qualitätsmanagementsystem Ihres Kunden. So ist sie für die Übergabe vorbereitet.

Das Ziel

Ein vollständiges Gerät und eine Softwaredokumentation, die zwei Audits besteht.

Für Ihr Unternehmen

Ein Angebot für das komplette Gerät einschließlich Software
Softwareentwicklungskapazität, die sich dem Umfang der Arbeitspakete anpasst
Eine Dokumentation, die sowohl das Audit Ihres Kunden als auch Ihr eigenes besteht

Für das Gerät

Firmware, die wir auf Ihren Platinen und in der Simulation testen
Eine SOUP-Liste mit Versionen, bekannten Anomalien und einer Begründung, warum jedes Element akzeptabel ist
Dokumentation zur Cybersicherheit, bevor das Platinendesign feststeht

Für Patienten

Ein komplettes Gerät, das mit verifizierter Software rechtzeitig auf den Markt kommt
Fehlerkorrekturen, die schnell auf Ihrem Gerät ankommen
Ein Gerät, das der Hersteller auch Jahre nach der Übergabe noch warten kann

Probleme und Lösungswege

Was wir hören und was wir dagegen tun

Unsere Kunden fragen nach dem kompletten Gerät. Für die Software fehlt uns jedoch das Personal.

Wir entwickeln Firmware und Anwendungssoftware, verifizieren sie und erstellen die Dokumentation nach IEC 62304. Wir arbeiten als Ihr benannter Unterauftragnehmer oder als White-Label-Partner unter Ihrem Namen.

Wie wir arbeiten

Die Softwaredokumentation muss sowohl das Audit unseres Kunden als auch unser eigenes bestehen.

Wir erstellen die Dokumente nach Ihren Vorlagen, Ihrer Nummerierung und Ihren Change-Control-Verfahren. Dabei richten wir uns von Anfang an nach dem Qualitätsmanagementsystem Ihres Kunden. Ihr Einkauf bewertet Silurus Software als Lieferanten nach ISO 13485 Abschnitt 7.4. Eine Qualitätssicherungsvereinbarung regelt die Zuständigkeiten für Designvorgaben, Change Control und Release.

QA, Compliance und Regulatorik

Wir können ein eigenes Firmware-Team zwischen den Projekten nicht auslasten.

Wir stellen ein Team passend zum Arbeitspaket zusammen oder ergänzen Ihr Projektteam während einer Designphase oder der Verifizierung um Entwickler. Die ersten Entwickler beginnen zwei bis drei Wochen nach der Unterzeichnung.

Teamerweiterung

Für unsere Prototyp-Firmware fehlen Anforderungen, Tests und ein Architekturdokument.

Wir beginnen mit einer Gap-Analyse (eine Prüfung, was gegenüber der Norm fehlt) nach IEC 62304 von Code, Dokumenten und Prozess. Wo die Struktur keine Tests zulässt, überarbeiten wir zuerst den Code und schreiben dann die Akte. Die Firmware wird umstrukturiert und dokumentiert, bevor sie in die Design Controls eintritt.

Modernisierung und Übernahme von Altsystemen

Firmware-Tests müssen bis zur nächsten Prototypenserie warten.

Wir entwickeln eine Simulationsschicht, damit die meisten Tests ohne Hardware laufen. Anschließend führen wir Hardware-in-the-Loop-Tests auf den von Ihnen bereitgestellten Platinen durch, auch auf jeder neuen Platinenrevision.

Embedded- und Firmware-Entwicklung

Unser Name steht auf dem Liefergegenstand. Wir befürchten, die Kontrolle darüber zu verlieren.

Unsere Entwickler arbeiten in Ihren Repositories mit Ihren Werkzeugen und berichten an Ihre Projektleitung. Bei Reviews und Releases halten sie sich an Ihre Verfahren. Das Design History File bleibt in Ihrem System.

Wie wir arbeiten

Fragen zur Cybersicherheit kommen erst auf, wenn das Hardwaredesign bereits feststeht.

Wir schreiben das Threat Model (eine strukturierte Analyse, wie das Gerät angegriffen werden könnte) und die SBOM (Software Bill of Materials, die Liste aller Softwarekomponenten im Build) mit der ersten Architektur. Der Schwachstellenprozess deckt IEC 81001-5-1 und FDA Abschnitt 524B ab.

Cybersecurity für Medizinprodukte

Arbeitsergebnisse

Was in Ihre Designdokumentation geht, und die Normen dahinter.

Arbeitsergebnis	Normen	Was der Kunde erhält
Softwareentwicklungsplan und Sicherheitsklasse	IEC 62304 · ISO 14971	Wir erstellen den Plan gemeinsam mit Ihrem Hardware- und Risikoteam. Die Sicherheitsklasse leiten wir aus der Risikoanalyse des Geräts ab.
Schnittstelle zwischen Hardware und Software	IEC 60601-1 Abschnitt 14, programmierbare elektrische medizinische Systeme	Wir erstellen eine Schnittstellenspezifikation anhand Ihrer Schaltpläne, entwickeln eine Simulationsschicht und führen Hardware-in-the-Loop-Tests auf Ihren bereitgestellten Platinen durch.
SOUP-Liste	IEC 62304	RTOS, Hersteller-SDK, Laufzeitumgebung und Bibliotheken von Drittanbietern erfassen wir jeweils mit Version, Anforderungen, bekannten Anomalien und einer Begründung ihrer Akzeptabilität. Diese Angaben dokumentieren wir in den ersten Wochen. Wir erfassen Compiler und Build-Werkzeuge und qualifizieren sie als Entwicklungswerkzeuge.
Dokumentation zur Cybersicherheit	IEC 81001-5-1 · MDCG 2019-16 · FDA 524B für Cyber Devices	Bedrohungsmodell, SBOM und Umgang mit Schwachstellen.
Lieferantenlenkung	ISO 13485 Abschnitt 7.4	Wir berücksichtigen die Anforderungen Ihrer Lieferantenbewertung und vereinbaren Zuständigkeiten für Designvorgaben, Change Control, Problemlösung und Release-Entscheidungen in einer Qualitätssicherungsvereinbarung.
Design-Transfer-Paket	ISO 13485 Abschnitt 7.3.8 · IEC 62304	Entwicklungsplan, Anforderungen, Architektur, Verifizierungsnachweise, Rückverfolgbarkeitsmatrix, Release Notes und eine Build-Umgebung, mit der sich das freigegebene Binary reproduzieren lässt.

Eignung

Wann wir der richtige Partner sind

Sprechen Sie uns an, wenn

Sie das komplette Gerät einschließlich Software anbieten möchten
Sie aus Prototyp-Firmware ein Produkt unter Design Controls entwickeln möchten
Sie eine Softwaredokumentation benötigen, die auf das Audit Ihres Kunden, die Prüfung durch die Benannte Stelle und die FDA-Einreichung vorbereitet ist
Sie für eine Designphase oder die Verifizierung zusätzliche Firmware- oder Testingenieure benötigen

Sprechen Sie mit uns

Sagen Sie uns, woran Sie arbeiten.

Ein Geräteangebot, Prototyp-Firmware oder eine Verifizierungsphase. Schreiben Sie ein paar Zeilen oder buchen Sie ein kostenloses 30-minütiges Gespräch mit unseren Entwicklern.

30-minütiges Fachgespräch buchen

FAQ

Häufige Fragen.

Können Sie als White-Label-Partner unter unserem Firmennamen arbeiten?

Ja. Bei einem White-Label-Projekt tragen Dokumente, Repositories und Release Notes Ihren Namen. Ihr Kunde sieht nur einen Lieferanten. Als benannter Unterauftragnehmer wird Silurus Software in Ihren Dokumenten als Softwarelieferant genannt. Auf Wunsch nehmen unsere Entwickler an technischen Besprechungen mit Ihrem Kunden teil.

Arbeiten Sie nach unserem Qualitätsmanagementsystem gemäß ISO 13485?

Ja. Unsere Entwickler halten sich an Ihre Verfahren, Vorlagen und Design Controls. Ihr Einkauf bewertet Silurus Software als Lieferanten nach ISO 13485 Abschnitt 7.4. Eine Qualitätssicherungsvereinbarung regelt die Zuständigkeiten für Designvorgaben, Change Control und Release.

Unsere Prototyp-Firmware ist nicht dokumentiert. Kann daraus ein Produkt werden?

Ja. Wir beginnen mit einer IEC-62304-Gap-Analyse des Codes, der Dokumente und des Prozesses. Der Bericht dient als Grundlage für die Nachbesserung. Lässt die Codestruktur keine Tests zu, refaktorieren wir den Code zuerst und erstellen anschließend die Dokumentation.

Mit welchen Mikrocontrollern und Betriebssystemen arbeiten Sie?

Wir arbeiten mit den Komponenten Ihres Geräts: Mikrocontrollern und Applikationsprozessoren, mit RTOS, Embedded Linux oder Bare Metal sowie gängigen drahtgebundenen und drahtlosen Schnittstellen. Desktop- und Mobilanwendungen sowie das Cloud-Backend entwickeln wir im selben Entwicklungszyklus.

Wie viele Entwickler können Sie bereitstellen und wie schnell?

Vom einzelnen Spezialisten bis zum ganzen Team. Manche Projekte brauchen einen einzelnen Spezialisten, andere ein ganzes Team in der Organisation des Kunden. Die ersten Ingenieure starten innerhalb von zwei bis drei Wochen nach Vertragsunterzeichnung.

Was kostet ein erstes Projekt?

Das 30-minütige Gespräch ist kostenlos. Für jeden weiteren Schritt erstellen wir ein individuelles Angebot. Umfang, Ergebnis, Dauer und Preis vereinbaren wir schriftlich. Wir antworten innerhalb eines Werktags.

Weiterführend