Hallo, ich darf zum ersten Mal ein Medizintechnikprodukt entwickeln (ein tragbares Sauerstoffgerät). Was für besonderen Vorkehrungen muss ich hier beim Hardwareaufbau treffen? Sie soll per Netz- und Akkubetrieb funktionieren. Kann ich beim Hardwareaufbau "ganz normal" vorgehen, oder muss ich alles doppelt absichern? Wie sicher ist hier z.B. die SPI-Schnittstelle? Darf ich hier mehrere verschiedene Sensoren drüber laufen lassen, oder gibt es eine "sicherere" Möglichkeit?
Wenns um Menschenleben geht immer redundant. Was man noch so alles einhalten muss weiß ich nicht. Da gibts bestimmt tausende Seiten an Vorschriften.
Oo ohje. wenn du das nicht weißt lass es. und nenn mir die firma für die du arbeitest, damit ich im bedarfsfall KEIN SOLCHES gerät bekomme. spaß mal beiseite bei solch wichtigen geräten müssen spezialisten ran die wissen wie's gemacht wird. das ist kein hobbyprojekt mehr oder "mal einen versuch wert" - da darf einfach kein fehler passieren und selbst wenn einer passiert muß das ding weiter arbeiten können wenn ein leben davon abhängt. kurz gesagt so ein gerät muß verlässlich funktionieren. ein mensch läßt sich leider etwas schwerer neu starten als ein auto oder ein computer.
Danke für die hilfreichen Antworten, als ob ich dass nicht selbst wüsste. Doch was soll ich nun tun, wenn ich's machen darf und muss?
Besorg dir als erstes die EN60601!!! Sauerstoffgerät= Lebenserhaltend= Königsdisziplin!!! Viel Spass www.em-tec.de mal anschauen...
OK EN60601 hab ich. Weiß wer, ob es Sinn macht die ganze Hardware mit Hilfe eines 2.Prozessors zu kontrollieren?
macht keinen sinn, wenn dann brauchst du drei weil du sonst nicht rausbekommst welcher (von zweien) das falsche ergebnis abgeliefert hat.
Ben schrieb: > macht keinen sinn, wenn dann brauchst du drei weil du sonst nicht > rausbekommst welcher (von zweien) das falsche ergebnis abgeliefert hat. genau und blos nicht die selben, mit unterschiedlichen programmen^^
2. Controller macht immer Sinn. Sonst musst du nachweisen dass du 2 getrennte SW Pfade hast (und das ist nicht einfach). Und denke auch an 2 getrennte Hardwarepfade für die Signalgewinnung/Übermittlung. Ansonsten hol dir einen Spezialisten dazu (Bewertung der Risiken, Bewertung der Strategien, Doku, Entwicklungsprozess ...), alles in der Norm drin aber als Unbedarfter wirst du nicht viel ableiten können. Von dem lernst du dann ersteinmal die Basics. Ich hab das alles durch (von "wieviel Tote kann es geben", welche Fehler können auftreten und wann, ...). Da ist kein Spass. Du musst nach State of the Art entwickeln und auch nachweisen. Am Ende für dich: Du bist zivil und strafrechtlich haftbar (d.h. im Extremfall Gefängniss). JL
Für die Zulassung medizintechnischer Geräte sind Prüfstellen wie z.B. der TÜV zuständig. Der TÜV zumindest bietet auch praxisbezogene Beratung an, es lohnt, sich frühzeitig mit dem in Verbindung zu setzen und die eigenen Vorstellungen vom Gerät mit denen des Prüfers abzugleichen. Die Norm beschreibt zwar, was wie zu machen ist, aber auf sehr theoretischer Ebene; der TÜV-Prüfer aber weiß, welche Parameter er bei einem realen Gerät prüfen wird und sollte daher sinnvolle Hinweise geben können. In welchem Umfeld sollst Du (Threadstarter Matthias) denn dieses Gerät entwickeln? In einer Firma, die noch nie medizintechnische Geräte hergestellt hat? Als Selbständiger, der damit eine eigene Firma hochziehen will? Oder als Diplom-/Studien- oder sontwas-Arbeit?
Du mußt zuerst eine Risikoabschätzung vornehmen, d.h. was kann bei einem Ausfall passieren und welche Gegenmaßnahmen muß man treffen. Es könnte z.B. ein Sensor die Funktion überwachen und Alarm auslösen, um dann die Reserveflasche oder eine manuelle Steuerung zu benutzen. Es nützt auch nichts, wenn die Software super-duper ist, aber die Mechanik oder Elektronik fehleranfällig. Alle Komponenten müssen mit einbezogen werden. Peter
Die Firmware redundanter sicherheitsrelevanter Systeme mit drei verschiedenen uC muss auch von drei, (von einander unabhaengigen) Personen geschrieben werden. Also kannst und darfst es schon mal nicht alleine entwickeln.
Eben. Bevor Panik ausbricht: Informiere Dich Und zwar bei jemandem, der sich damit auskennt, nicht hier im Forum. Hier mag zwar der eine oder andere schon mal von medizintechnischen Geräten gehört haben, oder vage Vorstellungen haben, was das ist, oder vielleicht auch selber schon mal mit der Entwicklung von so etwas zu tun gehabt haben, aber in welche Kategorie die Antworten fallen, ist kaum sinnvoll auseinanderzuhalten. Lass' Dich von der zuständigen Zertifizierungsstelle beraten, dort weiß man, welche Normen für Dich und Deine Anwendung relevant sind und wie diese auszulegen sind. Ob beispielsweise Redundanz erforderlich ist, welche Dinge beachtet werden müssen, wenn das Gerät am Netz und am Patienten gleichzeitig betrieben werden soll (dank günstig zu erwerbender bereits zertifizierter Steckernetzteile ist das nicht mehr ganz so kritisch, wie es vor einigen Jahren noch war) etc. pp. Die Investition in ein solches Beratungsgespräch lohnt.
eine solche Zertifizierungsstelle wäre: http://www.slg.de.com/index.shtml oder halt TÜV Nord http://www.tuev-nord.de/de/ZERTIFIZIERUNG_412.htm?month=9&year=2009
Zertifizierungsstelle ist die Abfüllstelle für die Gasflasche, also z. B Messer Griesheim. Für den Notfall reicht eine 2 Liter-Flasche völlig aus.
Is ja geil ...
Da trollt ein Troll trolligst umher und wird auch noch gefüttert ...
Ich hab ja schon viel hier gelesen, aber dieser Schwachsinn ist echt der
Hammer (übrigens nicht nur die Aussagen vom Troll selbst)!!!
>>OK EN60601 hab ich.
So, so. Welche denn und wieviel hat das gekostet? Vergiß es, bitte nicht
antworten.
Das hat so den Charakter "Ich bin sowas von ahnungslos und will ein
Flugzeug bauen: Welche Sicherung muß ich für das WC-Licht vorsehen?"
Antwort: "Sie muß dafür geeignet sein. Und denk dran, daß der Bezug des
Cockpitsitzes auch schwer entflammbar ist."
Sorry, aber "Frage" und Antworten sind sowas von Weit von der
Wirklichkeit weg, daß ich das nicht im Ansatz ernst nehmen kann.
Frag mich wie du an diese Aufgabenstellung gekommen bist. Welchen Hintergrund hast du denn ? Wie lange arbeitest du in der Branche. Hier braucht es jede Menge Erfahrung und die hast du scheinbar nicht.
@ Lutz: Recht hast Du! @ Bernd: Du auch! @ Fhutdhb Ufzjjuz: Und Du auch! Bin selber seit 30 Jahren in der Branche und habe für Bergbau, Chemie und Verkehrstechnik gearbeitet. @ Matthias: Vergess' es einfach!
Frank schrieb: > Nachtrag: > @ Matthias: zum Segen aller... und auch zum eigenen: kommt es zu einem Personenschaden wegen nicht eingehaltener Sicherheitsbestimmungen, geht der Verantwortliche leicht mal in den Knast. Die Gerichte verstehen da noch viel weniger Spass als bei nicht angeschlossenen grüngelben Drähten o.Ä. Gruss Reinhard
@RK Sicher hast du recht. Aber dieses großkotzige Getue und dass plötzlich jeder Honk, der aus den Büschen springt, bereits Medizingerät entwickelt haben will kommt mir schon reichlich übertrieben vor. @Alle Darf man fragen woher ihr die Erfahrung genommen habt, vor allem beim ersten mal?
@ DAC, ja, darfst du, habe 7 Jahre in der Branche zugebracht. Das nennt man Berufserfahrung :-)
Was hackt ihr denn auf dem TE herum? Wie DAC schon bemerkt hat,er muß halt Erfahrung sammeln und das geht eben nur wenn man sich mit dem Thema beschäftigt. An die paranoiden Sicherheitsfanatiker: Kein medizinisches Gerät kommt in Umlauf ohne eine entsprechende Prüfung durch eine akkreditierte Prüfstelle. Trotzdem wäre für den Entwickler eine Betriebshaftpflichtversicherung ratsam ( wie man weiß, kann immer etwas unvorhergesehenes passieren). P.S. Entwickle und fertige schon seit 20 Jahren EEG/EMG Geräte. Grüße
Naja, seine Einführungserklärung klingt halt sehr naiv und ich stell mir die Frage wie kommt er an diese Aufgabenstellung. In seiner Fa. muß es Kollegen geben die ihn da heranführen. Ansonsten mag er entwickeln was er will. Daher die einfache Frage was für einen Hintergrund er hat.
@Bernd
>habe 7 Jahre in der Branche zugebracht. Das nennt man Berufserfahrung :-)
Also sieben Jahre, in denen Du nicht selbst (mit-)Entwickelt hast? Wie
bist du an die wichtigen Informationen über das Innenleben eurer Geräte
gekommen - im Kundendienst gearbeitet?
Ich weiß nicht, was ihr habt. Anfangen muss jeder. Niemand kommt mit mehrjähriger Erfahrung in dem Sektor auf die Welt. Wenn man nie sowas entwickelt, kann man auch nichts lernen und Erfahrung sammeln. Man muss sich natürlich ausführlich mit dem Thema beschäftigen und nicht einfach drauf hin "basteln". Auch als "Anfänger" kann man sich an eine Medizinprodukt probieren. Die anschließenden Tests werden zeigen, ob es funktioniert oder es ein Schlag ins Wasser ist. Nur sollte man sich, wenn das Gerät letztendlich wirklich eingesetzt wird, von einem erfahrenen alten Hasen beraten lassen (ist bei mehrfacher Sicherheit, die solche Geräte ggf haben müssen, sowieso notwendig).
>Nur sollte man sich, wenn das Gerät letztendlich wirklich eingesetzt wird, >von einem erfahrenen alten Hasen beraten lassen Genau, aber ist es nicht irgendwie traurig dass man nicht mal im Vorfeld einen fachlichen Austausch in diesem Forum suchen kann? Alle, die hier krakelend reingesprungen sind, sollten sich mal fragen aus welchem Grund sie einer sachlichen Diskussion den Riegel vorgeschoben haben. So viele interessante Themen finden sich hier nicht, wenn man nicht mit einer Blinke-LED ausgelastet ist. Ich finde es sehr schade, dass gerade die interessanten Themen von üblicherweise selbsterklärten Experten zerredet werden.
Das sehe ich genauso. Mich nervt es sehr, daß alles erstmal zertreten wird. Konstruktive Kritik gibt es nur selten.
Vielleicht sollte man es einfach nochmal versuchen, egal ob der TE noch mitliest oder nicht. Wie gesagt, es dürfte Viele interessieren. Also, wer hat denn Erfahrungen mit redundanter Absicherung? Nach welchen Kriterien wurden die MCU ausgewählt, etc.? Mich würds freuen wenn jemand wirklich dazu was sagen kann. Grüße an die wahren Experten
Stop: alle Aussagen die kamen waren immer die gleiche Aussage, hol dir sofort Hilfe von erfahrenen Leuten, die Norm alleine hilft nicht. Von denen lernt man dann entwicklungsbegleitend. Derartige Grundlagen in einem Forum zu erfragen kann nicht der richtige weg sein und muss scheitern. Vorallem kam es bei mir so an als wenn aus Kostengründen externe Hilfe von der Firma aus nicht erwünscht ist (das übliche an den MA: mach dich erstmal selber schlau bevor wir Geld ausgeben).Würde es um irgendein Consumerprodukt gehen, so kann man sich so herantasten. Im schlimmsten Fall ist ein Kunde verärgert weil es nicht richtig funktioniert. Aber bei Menschenleben sieht es anders aus. Was ist wenn der Patient durch Unterversorgung dauerhaft geistig behindert wird? Wer helfen kann wurde auch deutlich gemacht. JL PS: ich habe es auch langsam erlernen müssen, aber wir haben uns externe Hilfe geholt. Und trotzdem habe ich erst Jahre später in anderen Projekten den kompletten Umfang der notwendigen Massnahmen selber erkannt und kann sie jetzt auch vor meinem Management verteidigen.
OK, praktischeres: MCU: - eigentlich egal, jede ist fehlerträchtig - Signalverarbeitung und Entscheidungen sollten bei 2uCs unterschiedlich sein (eventuell auch nur eine Plausibilitätskontrolle durch den zweiten uC) - bei kommunikation zwischen den Controllern doppelt Datenübertragen, wenn möglich mit Zykluszähler, verschiedene Formatierung der daten, Checksumme Watchdog: - MCU intern als nicht existierend betrachten - immer einen externen zusätzlich einbauen Redundanz: - muss nicht immer ein dritter uC sein, oft reicht auch eine Hardware die den sicheren Zustand herstellt (or/and logic oder änderungen nicht zulässt). - immer die Signalgewinnung als Schwachpunkt mit einbeziehen, redundante Signalwege Grundlagen: - definieren von sicheren Zuständen, eventuell bedeutet das auch RESET bis zum Benutzereingreifen, ist immer von der Aufgabe abhängig - alle Fehlerpfade erkennen und bewerten (das ist der schwierigste Teil) SW: - tbc JL
>Stop: alle Aussagen die kamen waren immer die gleiche Aussage, hol dir >sofort Hilfe von erfahrenen Leuten, die Norm alleine hilft nicht. Von >denen lernt man dann entwicklungsbegleitend. Ja, das macht auch Sinn - keine Frage. Daher meine Aufforderung, die Thematik unabhängig vom TE zu diskutieren. Mal angenommen, ich hätte nächste Woche mein erstes Treffen mit dem Mentor, der mir entwicklungsbegleitend zur Seite steht. Ich hätte da gerne ein paar Aspekte bereit, über die ich mir vorher Gedanken machen kann. Auch das richtige Fragen will gelernt sein, dafür waren Web-Foren lange ein geeignetes Übungsumfeld. Es entsteht kein Schaden, wenn wir hier ein paar Dinge aus der med.Geräte-Entwicklung besprechen, oder? >Was ist wenn der Patient durch Unterversorgung dauerhaft geistig >behindert wird? So schlimm das wäre oder ist, sowas ist doch nicht von diesem Thread abhängig.
@JL Jetzt hatten wir eine Überschneidung in den Beiträgen. Schön, dass du bereits den Anfang gemacht hast. Da hätte ich dann gleich ein paar Fragen dazu: >MCU: >- eigentlich egal, jede ist fehlerträchtig >- Signalverarbeitung und Entscheidungen sollten bei 2uCs unterschiedlich >sein (eventuell auch nur eine Plausibilitätskontrolle durch den zweiten uC) Das könnte man in SW lösen. Siehst du Vorteile darin, zwei unterschiedliche Derivate, oder gar von unterschiedlichen Herstellern einzusetzen? (Gibt es einen unentdeckten Bug in der Perpiherie, kann dieser durchaus in mehreren Derivaten des gleichen Herstellers enthalten sein - ein Fehler möglicher würde also auf beiden Systemen eingebaut) >- bei kommunikation zwischen den Controllern doppelt Datenübertragen, >wenn möglich mit Zykluszähler, verschiedene Formatierung der daten, >Checksumme Ok, zum Teil würde das eine Gegenmaßnahme zum vorherigen Punkt darstellen. >SW: >- tbc Oh, klingt für mich wie eine Krankheit. Da werde ich mal eine Suchmaschine bemühen müssen...
Sowas interessiert mich auch vom Thema "Medizin" losgelöst. Redundante Auslegung kann auch dann wichtig sein, wenn es nichts mit Medizin zu tun hat. Wieso nicht aus diesem Bereich gute Ideen abkupfern? Auch im Hobbysektor könnte sowas gebraucht werden (zum Beispiel, wenn eine Hardware nicht oder nur unter großen Anstrengungen erreichbar ist). Oder im Modellbau (meine Hardware fliegt gerade durch die Luft und ein Fehler tritt auf). Was natürlich gesagt werden muß: Aussagen im Forum dürfen nicht (speziell dann, wenn "Leben" beteiligt ist) ohne Nachdenken übernommen werden. Hier ist IMMER die Begleitung eines Fachmannes notwendig.
@Christian: Dann würde ich vorschlagen, daß einer der Interessenten einen neuen aussagekräftigen Thread aufmacht, da dieser mehr als daneben ist.
Beschäftige dich mit dem Thema "Zweikanalig, einfehlersicher". Hierzu findet sich sicherlich einiges im www. MC's kannst du verwenden was du willst aber bei einem 2 kanaligen Aufbau in aller Regler 2 verschiedene Typen... z.B. nen 8051 mit nem AVR. Natürlich Temp. Bereich definieren, oft werden Notfall Geräte auch in erweiterten Temp. Bereichen eingesetzt. Externe Überwachung des Programmablaufs, Watchdog wurde erwähnt... IMMER extern, kann z.B. ein retriggerbares Monoflop sein. Dritten MC habe ich nie verwendet, es geht darum, dass Gerät in einen sicheren Zustand zu überführen. Stell dir vor du hast eine Infusionspumpe die plötzlich das falsche Volumen fördert. Das muß erkannt werden, das Gerät schaltet dann in den sicheren Zustand und löst einen Alarm aus. Nun kann das medizinische Personal eingreifen. Sollte eine falsche Volumenförderung unerkannt bleiben so hätte das fatale Folgen. Fehlerzustände zu definieren und zu Erkennen ist sehr komplex.
@ Lutz, gute Idee, nenn diesen Zweikanalig, einfehlersichere Schaltungen.
merkt ihr eigendlich, dass der Threadersteller nicht antwortet? Das sieht mir dann doch nach einem (geglückten) Trollversuch aus.
Vlad Tepesch schrieb:
> Das sieht mir dann doch nach einem (geglückten) Trollversuch aus.
Der hat dabei aber ein interessantes Thema aufgebracht ;-)
> Der hat dabei aber ein interessantes Thema aufgebracht ;-)
Du siehst aber doch,
daß es hier im Hobbyistenforum keinen Einzigen gibt,
der ihm mit fachlich fundierten Antworten weiterhelfen kann.
Abgesehen von der EN, die ihm auch sein Arbeitgeber wohl schon
auf den Tisch gelegt hat, kamen hier nur selbstüberhebliche
Kommentare von Leuten, denen es offenbar an know how mangelt.
Nicht mal Hinweise, daß z.B. Fett in Sauerstoff zu brennen
anfängt, und daher solche Geräte besonders auf Brennbarkeit
abgecheckt werden müssen, sind gefallen, stattdessen jede
Menge Geschwafel.
>Nicht mal Hinweise, daß z.B. Fett in Sauerstoff zu brennen >anfängt, und daher solche Geräte besonders auf Brennbarkeit >abgecheckt werden müssen, sind gefallen, stattdessen jede >Menge Geschwafel. Hätte ich sogar noch gewusst aus der Ausbildung. Wir haben uns in einen neuen Thread verlagert, da kannst du gerne dein Wissen einbringen. >merkt ihr eigendlich, dass der Threadersteller nicht antwortet? Ist mir eigentlich egal, bin jetzt das letzte mal in 'seinem' Thread. Beitrag "Zweikanalig, einfehlersichere Schaltungen" Grüße
Schoener Tag heute schrieb:
> Wer sagt, dass hier nur Hobbyisten sind ?
Natürlich nicht, aber Hobbyisten entwickeln nun mal keine
Medizinelektronik, und ich hoffe auch, dass das solange so bleibt wie
ich noch möglicherweise auf so ein Gerät angewiesen bin. Auch der
trickreichste Bastler kann hier nicht mit Ratschlägen hilfreich sein.
Natürlich muss jeder mal anfangen, ich hatte auch mal keine Ahnung und
bin deshalb im Lauf der Entwicklung mehrmals nach Köln zum TÜV Rheinland
gefahren, um abzustimmen, was genau gefordert wird. Die legen nämlich
die Anwendung der Normen aus, d.h. der TÜV hat sich nach den
Vorschriften zu richten und ich nach dem TÜV (oder entsprechenden
zugelassenen Prüfinstitutionen).
Es liegt also in der Natur der Sache, dass diejeneigen, die Ahnung
haben, auch Profis sind, d.h. für Geld (Pfui) arbeiten. Ebenso liegt es
in der Natur des Forums, dass jeder, der sich hier meldet, die Lösungen
umsonst haben will. Folglich kommt ein Thread heraus, bei dem die
meisten Beiträge vorsichtig formuliert nicht zur Lösung des Problems
beitragen. Die Entwicklung eines Medzingerätes ist in jedem Fall ein
Auftrag im Bereich 5 stelliger Summen, und ein ausgefeilter Vertrag ist
dabei sehr zu empfehlen. Das leistet ein solches Internetforum nicht.
Mir kamm die Anfrage im übrigen auch so vor, als ob ein Hersteller von
Aquariumpumpen zu seinem Hauskostrukteur sagt, mit der Technik könnten
wir doch auch Infusionspumpen bauen, die bringen viel mehr ein, also hol
dir doch mal im Internet das nötige Knowhow. So einfach funktioniert das
aber nicht.
Gruss Reinhard
>Die Entwicklung eines Medzingerätes ist in jedem Fall ein >Auftrag im Bereich 5 stelliger Summen Selbst das kommt mir noch ziemlich wenig vor. Das heisst es darf schon mal nur eine Person maximal ein Jahr lang daran arbeiten, denn irgendwo müssen ja auch noch Material und Lizenzen herkommen. Ein Gerät, dessen Entwicklung unter 100k Euro zu stemmen ist, kann kaum das Werk eines erfahrenen Entwicklerteams sein.
Ob z.B. Manfred von Ardenne all seine Erfindungen wie die Herz-Lungen-Maschine vorher zum TÜV geschleppt hat?? Am Anfang stand immer eine Idee und am Ende erst kommt der TÜV.
Hallo, nachdem ich mich nun doch noch alles durchgelesen habe, möchte auch ich mich wieder melden. Vielen Dank für die sinnvollen Beiträge mit Fakten/Begriffen, nach denen ich weiter suchen und mich weiterbilden kann! Auch vielen Dank für die aufbauenden Worte, die von manchen kamen!! Nach den ersten paar Beiträgen, dachte ich schon, dass ich alles hinschmeiße und war so deprimiert, dass ich gar nicht mehr in diesen Thread geschaut habe. @Bernd: Es wäre toll, wenn du mir mal deine Mailadresse schicken könntest! So nun wieder zum Thema: Ich bin Anfänger, ja... und es ist meine erste komplette Produktentwicklung. Ich habe eine Firma mit Leuten, die mit mir an diesem Projekt zusammenarbeiten bzw. mit kontrollieren. Zuvor wollte ich aber auch Einsatz zeigen und eigenen Ideen und Vorschläge einbringen. Ich habe ne ganze Menge Normen, nach denen ich arbeiten soll. Mein jetzige Baustellen sind 1. Hardwareaufbau 2. Softwareaufbau 3. Risikoanalyse Nach meinem Verständnis müsste ich eigentlich in folgender Reihenfolge vorgehen: 1. Softwarearchitektur mit dem konkreten Aufbau des Programms (evtl. in UML, ist dies sinnvoll (kleine Firma, noch keine Erfahrung, aber Willen zum Einlernen)) 2. Im Kopf den groben Hardwareaufbau -> Risikoanalyse 3. Konkreten Hardwareaufbau mit Bestimmung der Bauteile Meine Probleme dabei sind: -wie beschreibe ich die Software effektiv (Beispiele, Vorlagen?) -woher weiß ich ob 1 MC oder 2? 8bit, 16bit oder 32bit MC? (gibt es hier irgendwelche Kriterien, Einführungen im Netz? Ich muss noch nach "Zweikanalig, einfehlersicher" suchen!!) -... Tja, wie ihr sehen könnt bin ich im Moment etwas überfordert und hätte eigentlich nur den Rat gebraucht, wie ich am sinnvollsten und effektivsten Anfange und mich nicht verrenne. Ach ja, den Tipp mit dem TÜV hab ich gelesen und werde mich nun mal informieren.
Matthias schrieb: > > @Bernd: Es wäre toll, wenn du mir mal deine Mailadresse schicken > könntest! > Das wäre leicht mit einer PN an den Poster zu machen, jedoch: Dazu müßte wohl mindestens einer von Euch beiden offiziell im Forum angemeldet sein. Da weder Du noch Bernd...
Matthias schrieb: > Ach ja, den Tipp mit dem TÜV hab ich gelesen und werde mich nun mal > informieren. Brav. Das sollte möglichst früh passieren, weil es auch die Risikoanalyse betrifft: verbindlich ist die des Ingenieurs oder Gremiums, das das Ding zertifizieren soll, nicht deine. Das kann durchaus Abweichungen geben, z.B. werden die meisten Zulassungen in USA von UL durchgeführt, das sind die New Yorker Feuerwehrleute. Krass formuliert interessieren die sich traditionsgemäss eher dafür, ob die Klinik brennt, als ob der Patient erstickt. Ein TÜVler hat mal zu mir gesagt "UL ist einfach, die interessiert bloss brennt - brennt nicht". Sind keine Freunde. Es ist keine Schande, sich zum fertigen Produkt führen zu lassen, aber soviel Qualifikation muss sein, dass du dich an der Diskussion aktiv beteiligen kannst. Im übrigen gehört auch zu den Voraussetzungen, dass die Firma als Organsisation qualifiziert ist, so ein Produkt herzustellen und zu warten. Ohne Qualitätssicherung dürfte das schwer werden. Gruss Reinhard
Matthias schrieb:
> -wie beschreibe ich die Software effektiv (Beispiele, Vorlagen?)
Indem man die UML anwendet? Habt Ihr im Studium keine Vorlesung über
Software Engineering gehabt?
Ernsthaft, wenn man das nicht kann oder auch noch nie in einem konkreten
Software-Projekt gemacht hat (egal ob Medizintechnik oder etwas
anderes), dann sollte man diese Teilaufgabe vielleicht lieber jemandem
überlassen, der sich besser damit auskennt.
Was hier halt so bisschen durchklingt ist, Du hast nicht wirklich
Ahnung, willst aber was sehr Aufwändiges und Kritisches machen.
Natürlich ist es keine Schande noch unerfahren zu sein, jeder hat mal
klein angefangen. Aber man fragt sich halt schon: Wieso sind in diesem
Projekt nicht Leute mit viel mehr Erfahrung für die Dinge zuständig, die
Du hier nennst?
Die Rolle eines noch komplett Unerfahrenen (z.B. Berufseinsteiger,
frisch von der Hochschule) in einem solchen Projekt wäre eher die
Implementierung einzelner Software-Module, aber sicher nicht die
komplette Planung und Risikobewertung. Das ist für einen Anfänger meiner
Meinung nach einfach eine Nummer zu groß. Man wächst bekanntlich mit den
Aufgaben, und das heißt nun mal dass man als Neueinsteiger ohne
Erfahrung eher klein anfängt.
Wie sieht denn der Projektleiter, bzw. der Chef der Firma das?
>Ernsthaft, wenn man das noch nie in einem konkreten Software-Projekt >gemacht hat (egal ob Medizintechnik oder etwas anderes), dann sollte man >diese Teilaufgabe jemandem überlassen, der sich damit auskennt. Warum hast du denn konkret Angst dass hier ein Schaden entsteht, wenn man über Konzepte spricht? >jeder hat mal klein angefangen. Aber man fragt sich halt schon: Wieso sind >in diesem Projekt nicht Leute mit viel mehr Erfahrung für die Dinge >zuständig, die Du hier nennst? Diese Leute hatten aber das Glück, dass in Ihrem Umfeld nicht nur über Erfahrung schwadroniert wurde, sondern durch aktives forschen Erfahrungen gemacht wurden. Das halbe Forum stellt sich ja schon der theoretischen Betrachtung in den Weg, da frage ich mich: Wo sollte man so schöne und interessante Themen wie die Sicherheitstechnik erörtern, wenn nicht in einem fachlich sehr gut aufgestellten Forum?
Sorry, im letzten Satz fehlt ein Teil. Ich beziehe mich nur auf den Gesprächsbedarf, den man als Unerfahrener nun mal hat. Aktiv forschen sollte man natürlich dort, wo es sicher und produktiv möglich ist: Im Labor
Hallo Matthias, nun da ist ja dein Projekt ein richtige Herausforderung. Nun ich wäre mit der Risikoanalyse angefangen danach die Hardware und danach die Software. Aber wie gesagt die Gesundheit ist ein Hohes Gut. Wer weiss wo deine Geräte nachher eingesetzt werden. Die Erde und der Weltall ist gross. Die Rahmenbedingungen die Gesundheit des Menschen zeigen das dir den Weg. Es darf kein Schaden am Menschen geschehen. Gleich welche Termperatur, Umgebung, Alterungsprozess der Hardware, keine Bugs und Bauteile die ein leben Lang laufen und auch jederzeit verfügbar sind und die Hardware Spezifikationen einhalten und im Notfall konstengünstig und schnell repariert werden können ob nun in Afrika oder Europa, bei sonne oder Eis und schnee. Es gibt Väterchen Zeit und Mutter Natur, alle szum Wohle der Gesundheit des Menschen, keine Ausdünstungen vom Material, keine Verschleissmaterialien, Modularer Aufbau damit man Batterien jederzeit wechseln kann. Hygienisch gut also Steril mit viel Kuper und Edelstahl. Robust und leicht. Stand der Technik , Solarzellen zum Aufladen und wenig Stromverbrauch. Led Lampen mit Anzaige halten lange. Sensoren die in jeder Lage korrekt arbeiten, ob mun im All oder unter Wasser, Bei Feuer oder bei Kälte. In der Wüste oder im Schnee. Sprich made in Germany. Weltweit tauglich und frag mal die Kunden. Schau mal die alten Sauerstoffflaschen an und frag die Taucher, Feuerwehrleute, Ärzte, Krankenschwestern, Patienten, Amateurfunker, EDV Leute im Krankenhaus, Wartungs und Servicetechniker, Pflegebedürfige mit Sauerstofflasche und Rollator,Gartenpumpenhersteller und Akkubohererhersteller,Mikrobiologen und Apotheker bzw. TüV oder DARC als unabhänge nichtkommerzielle HF verein. Auf jden Fall alles zum Wohle des Eid des Hippokrates es geht heir um die Gesundheit des Benutzer oder Patienten . Also erst Nachdenken, keine Buchhalter sondern nur die Technik , Gesundheit, Querdenker, solide Arbeiten. Zum Abschluss einen Test machen und zwar von einem der Unabhängig ist. Der dir die Wahrheit sagt und uneingenommen das Ding als Patient trägt oder du selber wenn du deiner Arbeit vertraust. Denn auch du kannst mal als Patient dran hängen und von deiner eigenen Arbeit den Unterschied zwischen Leben und Tod sehen.
DAC schrieb: > Warum hast du denn konkret Angst dass hier ein Schaden entsteht, wenn > man über Konzepte spricht? Es entsteht dann ein Schaden, wenn Unerfahrene über Konzepte sprechen, von denen sie nichts verstehen, diese aber trotzdem umsetzen wollen, und ihnen kein Erfahrener zur Seite steht der ihnen zeigt wie man es richtig macht. > Diese Leute hatten aber das Glück, dass in Ihrem Umfeld nicht nur über > Erfahrung schwadroniert wurde, sondern durch aktives forschen > Erfahrungen gemacht wurden. Das halbe Forum stellt sich ja schon der > theoretischen Betrachtung in den Weg, da frage ich mich: Wo sollte man > so schöne und interessante Themen wie die Sicherheitstechnik erörtern, > wenn nicht in einem fachlich sehr gut aufgestellten Forum? Nach der bisherigen Schilderung über dieses Projekt habe ich so ein bisschen Zweifel, ob die Rollen richtig verteilt sind. "Learning by doing" ist super, wenn es um unkritische Dinge geht. Oder wenn man jemanden mit Erfahrung nebendran stehen hat, der einem die Fehler, die man verbockt, um die Ohren haut ;-)
@Bernd: Es wäre toll, wenn du mir mal deine Mailadresse schicken
könntest!
Wenn ich wüßte wohin ? :-)
>> Dazu müßte wohl mindestens einer von Euch beiden offiziell im Forum angemeldet
sein.
Mh, hab mich hier mal registriert, ich schau mal ob ich die mail finde.
Ich kann leider nicht mehr dazu beitragen, als ein paar Brocken in den Raum zu werfen: 1. Spezifikation erstellen 2. EN60601 am besten auswendig lernen. 3. Risikoanalyse erstellen 4. FMEA für die Schaltung machen. 5. Software-Achitekturplan erstellen 6. QM-System für Firma vorhanden? ISO 9001 und/oder 13485 7. CE Zulassung: EMV gerecht entwickelt. 8. Anforderungen verwalten ( Software Tool vorhanden?) 9. Risikoanalyse--> Tip hierzu: Alles was von der 60601 abgedeckt wird, kann bei der Risikoanalyse entfallen. 10. Checken, ob UL-Zertifizierung notwendig ist. 11. Checken, ob FDA-Zertifizierung notwendig ist. 12. Alle Dokumente vom "Notified Body" vorab checken lassen 13. Testplan erstellen 14. Testsheets erstellen 15. Testen, Testen, Testen, Testen 16. Alle Änderungen, Hardware, Software, Tests verwalten 17. Software Livetime Cycle 18. Marktbeobachtung 19. Hardware: Kann Compiler validiert werden? 20. Design-freeze, wenn alles geht, nichts mehr verändern 21. EMV-Labor raussuchen, festlegen, EMV machen 22. Tests: Achtung bei FDA nur von Hand ausfüllen, wegen Evidence... 23. Lieferanten Selbstauskunft, Lieferanten qualifizieren, Auditieren... 24. Kritische Komponenten Liste führen. 25. Schulungsnachweise?
>"Learning by doing" ist super, wenn es um unkritische Dinge geht. Oder >wenn man jemanden mit Erfahrung nebendran stehen hat, der einem die >Fehler, die man verbockt, um die Ohren haut ;-) Wir sind uns ja fast einig - nur finde ich sollten die Lehrmeister dann auch die Samthandschuhe ausziehen und ein paar 'Klatscher' rausholen, also vielleicht ein paar Beispiele darüber bringen, was man alles falsch machen kann. Ich für meinen Teil gehe mit Informationen (vor allem aus dem Internet/Foren) stets kritisch um, ich möchte ja was lernen. Wenn jeder Thread hier für den DAU weich gepolstert werden muss, wird das zunehmend schwieriger.
F: "woran ist er denn gestorben?" A: "R16 und T88 sind durchgebrannt."
DAC schrieb: > Wir sind uns ja fast einig - nur finde ich sollten die Lehrmeister dann > auch die Samthandschuhe ausziehen und ein paar 'Klatscher' rausholen, > also vielleicht ein paar Beispiele darüber bringen, was man alles falsch > machen kann. Ich für meinen Teil gehe mit Informationen (vor allem aus > dem Internet/Foren) stets kritisch um, ich möchte ja was lernen. Wenn > jeder Thread hier für den DAU weich gepolstert werden muss, wird das > zunehmend schwieriger. Ja, einverstanden. Ein Thread über "Fehler, die Ihr in Projekten selbst erlebt habt - und wie sie ausgebügelt wurden" wäre auch mal ne Idee... :-)
>So nun wieder zum Thema:
Ich bin Anfänger, ja... und es ist meine erste komplette
Produktentwicklung. Ich habe eine Firma mit Leuten, die mit mir an
diesem Projekt zusammenarbeiten bzw. mit kontrollieren.
Die Antworten dieses Threads laufen darauf hinaus, es entweder
seinzulassen, resp etwas Einfacheres zu versuchen, oder einen
aelteren erfahrernen Mitarbeiter ins Boot zu holen.
Die Hinweise bzw. Auflistung von ... Autor: privat (Gast) Datum: 12.11.2009 18:26 ... sind sehr gut. Ein Medizintechnikprodukt also. Hmmm. Damit kenne ich mich weniger aus. Aber ein bischen mit Automobil-Elektronik (Zulieferer). Da gibt es auch viele Normen, Regeln, Vorgehensweisen, die einzuhalten sind. Nach dem, was ich hier bisher gelesen habe, sage ich mal: Vermutlich ist der Kenntnisstand des Fragestellers hier noch nicht ausreichend. Als Automobilzulieferer würdest du damit ganz sicher durchfallen in der erstem Q-Auditierung. Nicht nur du, sondern die ganze Firma fällt durch, die auf die Idee kommt, sowas von einem "Neuling" erstellen zu lassen. Selbst für ein Produkt wie eine Aussenspiegelverstellung (z.B.). Es braucht hier ein kompetentes Entwicklungs-TEAM. Das kann niemals ein einzelner Mitarbeiter stemmen. Nichtmal wenn er alle Kenntnisse hätte, und unendlich Zeit. Nein, weil es einfach vorgeschrieben ist, unterschiedliche "Rollen" besetzt zu haben. Z.B. darf ein SW-Entwickler niemals seine eigene SW (bzw. das Produkt) selbst prüfen. Noch nicht einmal selbst die Prüfvorschrift erstellen. Das ist Stand der Technik in der Automobilindustrie. Bestimmt sind die Forderungen an Medizinprodukte eher höher. Erich
Hi So langsam sollte ich vielleicht auch mal meinen Senf dazutun, nachdem dies ein Thema ohne Ende wird. Dem Fragesteller kann ich nur den Rat geben, in die Vorschriften zu sehen. Wir kennen doch nicht das Produkt, das da entwickelt werden soll. Meizintechnik ist ein weites Gebiet, angefangen vom Pillendrehautomaten bis hin zum Herzschrittmacher. Die Firma, die solche Teile entwickelt, hat Richtlinien vorgegeben, wie sie in der Automobil-, Lebensmittel- und Stahl- Aluminium- und was wieß ich noch in welchen Industrien gelten. Natürlich sind die Richtlinien bewertet auf das verbundene Risiko, Bekanntschaft mit einem Staatsanwalt zu bekommen. Eine Produktentwicklung einem Neuling / Anfänger in die Hand zu drücken, warum nicht ? Er wird nix bauen und dann selbst ungeprüft auf irgendeinen Verkaufstresen legen. Hilfreiche Antworten sind hier nach wie vor der Hinweis, mit alten Hasen zu reden. Diese werden, wenn es gute Mitarbeiter sind, helfen und niemanden im Regen stehen lassen. Die Kollegen, die hinter vorgehaltener Hand unkooperativ sind oder gar Fehlinformationen geben, sind nix wert. Ich würde diesen Mitarbeitern sehr schnell die Tür in die Freiheit zeigen. Weiter hilfreich sind die zuständigen Prüfgremien. Das ist nicht immer die BG oder TÜV. Das sind nicht selten auch Universitäten, die Spezialgebiete abdecken. Also, Mut zur Lücke, entwickle dein Produkt, beachte Hinweise der Kollegen und schau, ob zu deinem Thema ein Spezialist existiert. Gruß oldmax
Ich werfe mal noch einen Begriff in die Runde, den ich hier noch gar nicht gelesen habe: Medizinproduktegesetz. Die Liste von privat (Gast) weiter oben trifft es schon ganz gut. Zusätzlich würde ich dem Threadersteller raten, wenn er denn wirklich bisher keine Ahnung von Medizintechnik hat, sich mal paar Bücher anzuschaffen und dort viel zu lesen. Amazon liefert zum Thema Medizintechnik da schon so Einiges. Ob das brauchbar ist, muss jeder selbst entscheiden. Bei mir im Studium hat das Thema Medizintechnik 3 Jahre von 5 Jahren Studium ausgemacht (die anderen zwei Jahre waren Grundlagen Elektrotechnik). Wir hatten eine eigene Vorlesung mit Seminar zum Thema Gerätenentwicklung. Ist also nicht irgendwas Triviales, was man sich in zwei Tagen aneignen kann... Gruß, Helge
Im Prinzip muss man doch bei der Entwicklung nur sicherstellen das die ganzen Regeln/Bestimmungen/Normen eingehalten werden. Und alles so robust bauen wie irgendmöglich und natürlich die Funktion möglichst genau verifizieren. Bis auf das ist es doch ne normale Produktentwicklung? (ausser das es halt durch oben genannte Dinge länger dauert) Ja natürlich sollte man schon ein paar Jahre Erfahrung beim entwickeln von Geräten im Allgemeinen haben würde ich sagen und nicht schon bei ner blinkenden LED lange überlegen müssen ;-)
huibu schrieb:
> Bis auf das ist es doch ne normale Produktentwicklung?
das ist eben der grundlegende Irrtum. Bei einem PC-Netzteil käme niemand
auf die Idee, für jeden Ausgang einen eigenen Überspannungsschutz
vorzusehen. In der Medizintechnik stellt sich dagegen die Frage, ob und
wie die Funktionsfähigkeit dieses Schutzes durch eine weitere
Überwachungsschaltung sichergestellt werden kann - das ist sozusagen
Paranoia in Silizium.
Du hast also nicht nur keine Ahnung, du kannst dir nicht einmal
annähernd vorstellen wie Ahnung aussieht.
Gruss Reinhard
> Bei einem PC-Netzteil käme niemand auf die Idee, für jeden Ausgang einen > eigenen Überspannungsschutz vorzusehen. Wäre aber sehr sinnvoll.
> PC-Netzteil
Von Consumer Elektronik alleine habe ich auch nicht geredet!
Bei Industrieelektronik wird auch an allen von aussen zugänglichen
Stellen Überspannungsschutz eingebaut. Oft auch intern bei
Kabelverbindungen im Gehäuse (z.B. zum Netzteil - ja vor ALLEM
Absicherung zum Netzteil hin, weil es nicht unwahrscheinlich ist das das
mal ausfällt... habe ich vor kurzem nen relativ teures Board so
ausgelegen müssen das da vom Netzteil her nix passieren kann). Völlig
normal.
Eine Überwachung dieser Schutzfunktionen ist dabei allerdings nicht
wichtig - da haste recht ;)
Eine Regel habet ihr noch vergessen: ********************************************** Die grosse Vorschriftenaufweichregel: Ein Medizinprodukt darf ruhig etwas gefährlich sein, es muss nur mehr nutzen, als schaden. ********************************************** Damit lässt sich viel abdecken!
huibu schrieb: > Eine Überwachung dieser Schutzfunktionen ist dabei allerdings nicht > wichtig - da haste recht ;) Hallo, die Argumentation ist (zutreffenderweise), dass der Überspannungsschutz ja nie anspricht und daher jahrelang defekt sein könnte, ohne dass es jemand merkt. Aber damit hört es ja nicht auf, das gleiche gilt für die Überwachungsschaltung. Erst auf mein Argument, dass das grundsätzlich in eine endlose Rekursion führen würde und ab einem bestimmten Punkt die zunehmende Komplexität der Überwachungen nur noch die Ausfallwahrscheinlich nach oben treiben würde, ist die schon angelaufene Diskussion über die Überwachung der Überwachung der Schutzschaltung nicht weitergeführt worden. Fand ich recht kulant. Gruss Reinhard
> die Argumentation ist (zutreffenderweise), > dass der Überspannungsschutz ja nie anspricht und daher > jahrelang defekt sein könnte, ohne dass es jemand merkt. Das stimmt allerdings! Wenn die Schutzschaltung ordentlich geplant und gefertigt wird ist es zwar sehr unwahrscheinlich das hier ein defekt vorkommt... bei med. tech. hast Du aber natürlich recht - da ist das Risiko nicht aktzeptabel. > Diskussion über die Überwachung der Überwachung der Schutzschaltung Hehe ja schönes Diskussionsthema :-)
also das MPG / 60601-1 sind die Grundlagen. aber ohne Erfahrungen von erfahrenen Entwicklern wirst du nicht weit kommen.... Wie kann so ein Projekt einem Neueinsteiger übertragen werden?
Hallo Matthias, also wenn du mich fragst sollten wir den uP noch über eine alternative Vebindung z.B. UART mit dem zweiten uP verbinden. Nur der SPI ist mir auch zu gefährlich. Die Sache mit dem DMA würd ich komplett lassen. Lieber langsamer aber dafür sicherer und einfacher zu testen. Wenn wir das wirklich alles C bekommen wollen muss der Gammel einfach werden. Aber den Rest sollten wir lieber nicht hier breit-tragen sondern wieder im Büro weiterführen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.