Hallo zusammen,
ich hoffe, dass ich hier in den richtigen Forenbereich poste.
Der Kern meiner Frage ist:
Kann man mit den Boardmitteln die Xilinx im Vitis/SDK (2020.2)
mitliefert, eine Standalone/Bare Metal Application für den Medizin
Bereich ICE 62304 konform entwickeln? Gibt es Erfahrungen dazu?
FreeRTOS ist zwar ein Bestandteil der Tool-Chain, jedoch nicht ohne
Aufwand ICE 62304 konform.
Die passende Version wäre SafeRTOS, die jedoch nicht in den Kostenrahmen
passt.
https://www.highintegritysystems.com/embedded-rtos-for-medical-devices/
Danke + Gruß
Andre
Vitis heisst doch neurales Netz?! Da sollte man sich genau überlegen, ob
man das überhaupt verifizieren kann, oder irgendwelcher
körperverletzender Scheiß u.U. 'antrainiert' wird.
https://www.johner-institut.de/blog/iec-62304-medizinische-software/validierung-von-machine-learning-libraries/
Bewährt hat sich, man verwendet eine etablierte Software wie Vidado und
Nicht-Vitis. Ansonsten mal bei der lokalen bennanten Stelle, die den
Kram ohnehin abschliessend zu zertifizieren hat, nachfragen.
Ansonsten ist ICE 62304 hauptsächlich Qualitätsmanagment, das kann man
auch mit den etablierten Software-Engenieerung tools (Versionscontrolle,
Bugtracking,Änderungsverfolgung etc. pp.) hinbacken. Auf eventuell
mitgelieferte 'Ersatztools' zur Versionsverwaltung sollte man sich nicht
verlassen.
Ach ja eine der wichtigen Sicherheitsregeln heisst KISS - Keep It
Simple, Stupid - Nach der regel sollte man Betriebssystem nur einsetzen
wo unkritisch, und die kritischen behandlungsschritte von 'dummer
Elektronik' machen lassen. Und natürlich redundant mit Vergleicher.
Aus persoenlicher Erfahrung kann ich dir versichern, dass das problemlos
moeglich ist.
Das Stichwort das die suchst ist SOUP (Software of unknown provenance)
und die darfst du in allen Medizinklassen (A bis C) verwenden, du musst
nur entsprechende Kritierien dokumentieren und validieren. Siehe z.B.:
https://www.johner-institut.de/blog/tag/soupAndre schrieb:> FreeRTOS ist zwar ein Bestandteil der Tool-Chain, jedoch nicht ohne> Aufwand ICE 62304 konform.
Der Aufwand haelt sich allerdings in Grenzen. Und selbst bei SAFERTOS
musst du dokumentieren und begruenden. Ganz geschenkt bekommst du die
Zulassung hierfuer auch nicht.
Medizinzulassungen sind in meinen Augen auch viel Schall und Rauch und
der leidtragende ist der Patient. Es werden weder harte
Softwarelebenszyklen Modelle vorgeschrieben, noch Teststrategien. Was
und wie du machst musst du dokumentieren und begruenden. Das wars schon,
ganz abstrakt reduziert sich das auf: Du musst dir einen
Entwicklungsprozess ausdenken und dokumentieren. Und dokumentieren wie
du ihn einhaelst. Ob der Sinn macht oder nicht, ist kein Bestandteil der
IEC 62304. Leider. :-(
Ludwig Lustlos schrieb:> Vitis heisst doch neurales Netz?!
Nein!
Vitis ist der neue Name für das gesamte Xilinx-Besteck, das hat erstmal
überhaupt nichts mit machine learning zu tun.
Seit Ende 2019/ Anfang 2020 ist alles unter dem Namen Vitis Unified
Software Platform zusammengeführt was vorher das Xilinx SDK, SDSoC oder
SDAccel war. Auch Vivado HLS heißt jetzt Vitis HLS.
Nur das Kern-Vivado heißt auch weiter Vivado.
Danke für eure Beiträge.
Tobias B. schrieb:> Aus persoenlicher Erfahrung kann ich dir versichern, dass das problemlos> moeglich ist.>> Das Stichwort das die suchst ist SOUP (Software of unknown provenance)> und die darfst du in allen Medizinklassen (A bis C) verwenden, du musst> nur entsprechende Kritierien dokumentieren und validieren. Siehe z.B.:
Ok, ist doch mal gut zu lesen.
Folgenden Situation:
Man erstellt mit Vivado das FPGA Design, und erstellt aufbauend darauf
ein HelloWorld Projekt im Vitis/SDK.
Fällt dann der generierte Code z.B. für UART oder GPIO des BSPs auch
unter Soup?
Ich vermute, dass diese Treiber durch Unit-Tests abgesichert werden
müssen, bevor mit dem Applikations-Code begonnen werden kann.
Tobias B. schrieb:> Andre schrieb:>> FreeRTOS ist zwar ein Bestandteil der Tool-Chain, jedoch nicht ohne>> Aufwand ICE 62304 konform.>> Der Aufwand haelt sich allerdings in Grenzen. Und selbst bei SAFERTOS> musst du dokumentieren und begruenden. Ganz geschenkt bekommst du die> Zulassung hierfuer auch nicht.
Das ist wahr, jedoch wird bei SafeRTOS der Großteil der Dokumentation
mit geliefert, da SafeRTOS nach IEC 61508-3 SIL3 und ISO 26262-6 ASIL D
vom TÜV SÜD vorzertifiziert ist. Natürlich hast du recht, dass man
trotzdem Anpassungen machen müsste. (Quelle:
https://www.highintegritysystems.com/safertos/)
Tobias B. schrieb:> Medizinzulassungen sind in meinen Augen auch viel Schall und Rauch und> der leidtragende ist der Patient. Es werden weder harte> Softwarelebenszyklen Modelle vorgeschrieben, noch Teststrategien. Was> und wie du machst musst du dokumentieren und begruenden. Das wars schon,> ganz abstrakt reduziert sich das auf: Du musst dir einen> Entwicklungsprozess ausdenken und dokumentieren. Und dokumentieren wie> du ihn einhaelst. Ob der Sinn macht oder nicht, ist kein Bestandteil der> IEC 62304. Leider. :-(
Um so mehr ich mich in diese Thematik einlesen, um so mehr bleibt der
Eindruck, dass viel Spielraum für Interpretation besteht.
L. I. schrieb:> Seit Ende 2019/ Anfang 2020 ist alles unter dem Namen Vitis Unified> Software Platform zusammengeführt was vorher das Xilinx SDK, SDSoC oder> SDAccel war. Auch Vivado HLS heißt jetzt Vitis HLS.> Nur das Kern-Vivado heißt auch weiter Vivado.
Gut zusammengefasst!
Ludwig Lustlos schrieb:> Ansonsten ist ICE 62304 hauptsächlich Qualitätsmanagment, das kann man> auch mit den etablierten Software-Engenieerung tools (Versionscontrolle,> Bugtracking,Änderungsverfolgung etc. pp.) hinbacken. Auf eventuell> mitgelieferte 'Ersatztools' zur Versionsverwaltung sollte man sich nicht> verlassen.
Was wären solche Ersatztools?
Ludwig Lustlos schrieb:> Ach ja eine der wichtigen Sicherheitsregeln heisst KISS - Keep It> Simple, Stupid - Nach der regel sollte man Betriebssystem nur einsetzen> wo unkritisch, und die kritischen behandlungsschritte von 'dummer> Elektronik' machen lassen. Und natürlich redundant mit Vergleicher.
Das wäre eine der sicheren Varianten, jedoch lässt das die
Entwicklungskosten steigen. Der Entwicklungsansatz von Xilinx ist schon
gut. Dieser lässt aber die Grenzen der zwischen 'klassischer' Software
und Elektronik verschwimmen. Das macht sich bei der Umsetzung von Normen
gut bemerkbar.
VG
Eins vorweg. Ich bin kein Auditor, daher kann ich allein aus Erfahrung
berichten. Im Zweifel wuerde ich einfach mal ein Kurs beim Johner
Institut buchen, das ist wirklich sehr lehrreich und die Kohle empfand
ich als super angelegt!
Andre schrieb:> Ok, ist doch mal gut zu lesen.> Folgenden Situation:> Man erstellt mit Vivado das FPGA Design, und erstellt aufbauend darauf> ein HelloWorld Projekt im Vitis/SDK.> Fällt dann der generierte Code z.B. für UART oder GPIO des BSPs auch> unter Soup?> Ich vermute, dass diese Treiber durch Unit-Tests abgesichert werden> müssen, bevor mit dem Applikations-Code begonnen werden kann.
Genauso wurde das in den Projekten in denen ich beteiligt war
gehandhabt. Diese generierten Codes wurde als SOUP behandelt und es
wurden Testroutinen definert um die Eignung im Softwaresystem zu
validieren. Idealerweise machst du das automatisiert in entsprechenden
Containern und laesst dir die Doku gleich mitliefern. Falls du/ihr
hierzu Hilfe brauchst, kannst du mich gerne auch mal privat anschreiben
(falls noetig mit NDA), dann kann ich auch ein bisschen
projektspezifischer beraten. Sorry fuer die Eigenwerbung, aber manchmal
ist einfach nicht ganz praktisch in der Oeffentlichkeit ueber ein
Projekt zu quatschen.
Andre schrieb:> Das ist wahr, jedoch wird bei SafeRTOS der Großteil der Dokumentation> mit geliefert, da SafeRTOS nach IEC 61508-3 SIL3 und ISO 26262-6 ASIL D> vom TÜV SÜD vorzertifiziert ist. Natürlich hast du recht, dass man> trotzdem Anpassungen machen müsste. (Quelle:> https://www.highintegritysystems.com/safertos/)
Ich mein ich hab vorhin beim stoebern auch IEC62304 gefunden:
https://www.highintegritysystems.com/embedded-rtos-for-medical-devices/
Aber theoretisch hast bei SOUPs eh ziemlich wenig zu machen um eine
Zulassung zu bekommen. Du solltest den Hauptaugenmerk immer auf das Wohl
des Patienten legen, dahingehend deine Risikoanalyse machen und dann
hast auch schon alles zusammen um das zu bewerten und zu dokumentieren.
SOUPs sind formal eher deine Freunde. ;-)
Andre schrieb:> Um so mehr ich mich in diese Thematik einlesen, um so mehr bleibt der> Eindruck, dass viel Spielraum für Interpretation besteht.
Damit hast du den Nagel auf den Kopf getroffen. :-) Im Prinzip ist es eh
egal was du machst, die Auditoren haben zuwenig technisches
Verstaendnis. Daher kannst du praktisch machen was du willst, hauptsache
deine Zulassungsdokumente sind formal korrekt und insich nicht
widerspruechlich.
Tobias B. schrieb:> Eins vorweg. Ich bin kein Auditor, daher kann ich allein aus Erfahrung> berichten. Im Zweifel wuerde ich einfach mal ein Kurs beim Johner> Institut buchen, das ist wirklich sehr lehrreich und die Kohle empfand> ich als super angelegt!
Es geht ja hier allein um Erfahrungsaustausch :).
Ich kann nur zustimmen: Die Publikationen die das Johner Institut, auf
den verschiedenen Plattformen, veröffentlicht hat geben einen guten
Einblick in den Themenbereich.
Tobias B. schrieb:> Genauso wurde das in den Projekten in denen ich beteiligt war> gehandhabt. Diese generierten Codes wurde als SOUP behandelt und es> wurden Testroutinen definert um die Eignung im Softwaresystem zu> validieren. Idealerweise machst du das automatisiert in entsprechenden> Containern und laesst dir die Doku gleich mitliefern. Falls du/ihr> hierzu Hilfe brauchst, kannst du mich gerne auch mal privat anschreiben> (falls noetig mit NDA), dann kann ich auch ein bisschen> projektspezifischer beraten. Sorry fuer die Eigenwerbung, aber manchmal> ist einfach nicht ganz praktisch in der Oeffentlichkeit ueber ein> Projekt zu quatschen.
Danke für diesen Input.
Ab einer bestimmten Detailtiefe ist die Eigenwerbung verständlich:)
Komme gerne darauf zurück.
Für jemanden, den das Thema interessiert, hier etwas zum Lesen:
https://www.xilinx.com/support/documentation/white_papers/wp511-risk-mgmt.pdf
VG
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten