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/soup 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. 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
Andre schrieb: > Für jemanden, den das Thema interessiert, hier etwas zum Lesen: > https://www.xilinx.com/support/documentation/white_papers/wp511-risk-mgmt.pdf Danke fuer das WP, kannte ich noch nicht. Das werde ich mir in einer ruhigen Stunde mal gemuetlich reinziehen. :-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.