Hallo, wir arbeiten an einem medizinischen Gerät, das unter Anderem einen MSP drin hat. zur Programmierung wollen wir den MSPGCC verwenden, jedoch habe ich gestern in einem Gespräch gehört, dass man den MSPGCC für solche Anwendungen nicht verwenden darf, da er bei der Kompilierung ein paar Fehler machen könnte. Das war mir völlig neu, ein gcc Compiler der Fehler enthalten soll? Die Gcc-Famieleie ist doch viel besser dokumentiert als alle anderen kommerziellen Kompiler, oder nicht? Wenn da schon jemand mit Erfahrung hat, würde ich mich über eine Kontaktaufnahme freuen. MfG Oliver
Jeder Compiler kann Fehler machen. Software ist praktisch niemals fehlerfrei. Die kommerziellen Hersteller haben für solche Fälle dann üblicherweise einen Disclaimer, mit dem sie sich dagegen absichern, daß man sie für entsprechende Fehler nicht haftbar machen kann. Eine ähnliche Absicherung findest Du in der GPL natürlich ebenfalls. Inwiefern es natürlich wahrscheinlich ist, daß Du über einen Compilerfehler stolperst und ,,nicht nur'' über Deine eigenen Bugs, ist eine ganz andere Frage. ;-)
Es kann durchaus sein, daß für lebenswichtige Anwendungen alle verwendeten Tools (auch Software) bestimmte Zertifizierungen (ISO 9000 usw.)haben müssen. Auch sind ganz andere Programmierrichtlinien einzuhalten. Ein Videorekorder sollte Fehler vertuschen, also nach einem Absturz allein wieder hochfahren. Ein Medizingerät muß dagegen, sobald ein nicht erwarteter Zustand eintritt sofort Alarm schlagen, das es fehlerhaft arbeitet und ausgetauscht werden muß. Aber Medizintechnik ist ja ein weites Feld. Die Software in einem Schrittmacher ist z.B. viel kritischer als in einem Fieberthermometer. Peter
Vielen Dank, Fehlerbehandlung und Alarme sind schon im Pflichtenheft. :-) Da es sich um ein Beatmungsgerät handelt, gibts da schon so einiges zu beachten. Ich hab mich mal versucht auf der HP von MSPGCC schlau zu machen, aber da habe ich keinen ISO9000 Hinweis gefunden, soll das heissen, das der Compiler nicht dieser Norm genügt, oder haben die das einfach auf der HP unterschlagen? MfG Oliver
Hast Du schon mal eine ISO 900x Zertifizierung gemacht? Dann weißt Du, was es bedeutet, und warum ein Opensource-Projekt sowas praktisch nicht machen kann. Andererseits, was bedeutet ISO 900x eigentlich? Es bedeutet doch weiter nichts, als daß die Bugs nicht zufällig da drin sind, sondern reproduzierbar. ;-) Viele andere Anforderungen dieser Normen dürften ebenfalls erfüllt werden (bspw. ein Bugtracking-System, das auch funktioniert -- schon viele Jahre bevor es ISO 900x gab übrigens ;-), nur für die Zertifizierung (und regelmäßige Re-Zertifizierung) blätterst Du so viel Geld und Aufwand hin, daß der im Rahmen von Opensource selbst in aller Regel nicht gestemmt werden wird.
Ein ISO 900x Statement sehe ich übrigens nichtmal bei IAR.
Also bei beim MSPGCC könnten sich mehrere Firmen zusammenschließen um den Compiler (+Präprozessor usw.) zu zertifizieren, so dass ich da nicht weniger Chanchen sehe als bei einem propietären wie dem von IAR. Zudem hat der IAR-Compiler etliche Bugs und bringt nur wenig Fehlermeldungen, so dass der praktisch keine Chance für eine Zertifizierung hat ( http://compiler-tests0.sourceforge.net/testlist.txt ). Dazu kommt noch, dass der IAR-Compiler einigen nicht-ANSI-C-Code klaglos compiliert und ANSI-C-Code nicht richtig compiliert; beispielsweise werden Warteschleifen mit nicht-volatile-Variablen nicht wegoptimiert und sscanf von unsigned short int funktioniert einfach nicht. Dass bei IAR auch ignoriert wird, dass der letzte ANSI-C-Standard (C99) alle vorherigen nicht nur ersetzt sondern auch für ungültig erklärt, ist da nur eine Kleinigkeit am Rande. Die IAR-Compiler sind nur dominant, weil a) IAR gut mit den Hardware-Herstellern kooperiert, b) die Compiler von IAR die ersten oder einige der ersten waren und c) mittelmäßig kleiner Code produziert wird. Bezüglich ANSI-C-Kompatibilität und Sicherheit sowie Vollständigkeit der IDE ist IAR Schlußlicht; es fehlen selbstverständliche Header-Dateien wie stdint.h, der Editor ist ärmlich und es fehlt beispielsweise ein Prettyprinter.
Sorry, aber Du hast keine Ahnung, was eine ISO 900x Zertifizierung wirklich bedeutet. Damit wird kein Produkt auf Einhaltung eines bestimmten Qualitätsstandards oder gar Fehlerfreiheit zertifiziert (letzteres wäre bei Software ohnehin praktisch so gut wie unmöglich). Es wird lediglich für eine bestimmte Organisation zertifiziert, daß die Qualitäts*sicherung* bestimmten Standards genügt. Im Wesentlichen bedeutet daß, daß bei gleichbleibender ,,Eingabe'' davon ausgegangen werden kann, daß ein gleichartiges Ergebnis erhalten wird. Verläßlichkeit für den Kunden ist das Stichwort. Beispielsweise bekommst Du eine Zertifizierung für vertriebliche Abläufe, wenn Du diese nicht ,,auf Zuruf'' handhabst, sondern sauber mit Anfrage, Angebot, Bestellung (deren Eingang vermerkt wird), Lieferung, die mit Lieferschein bestätigt wird, daraufhin wird eine Rechnung versandt. Als Kunde kannst Du Dich drauf verlassen, daß Du nicht z. B. was berechnet bekommst, was Du gar nicht geliefert bekommen hast (Du hast ja einen Lieferschein unterschrieben), oder daß Du nicht 1 Jahr auf die Rechnung warten mußt (und solange das Geld bereithalten). Für Dienstleistungen bekommst Du die Zertifizierung, wenn sich die Supportcalls nicht mal in einem ungeordneten Papierstapel auf dem Schreibtisch des 1. Bearbeiters ausdrücken, in einer Gehirnsecke des 2. Bearbeiters notiert sind, oder ggf. vom 3. Bearbeiter komplett verschrummst werden, weil er kurz nach Annahme des ersten Calls einen zweiten dringlicheren erhalten hat. Stattdessen gibt es einen dokumentierten (und durch die Mitarbeiter zu befolgenden) Ablauf, wie solche Calls aufgenommen und bearbeitet werden. Damit ist auch klar, daß selbst ein Compiler, der 23 bekannte Bugs hat, die dem C-Standard widersprechen, durchaus von einer Firma kommen kann, die eine ISO 900x Zertifizierung hat. Allerdings sollte der Compiler sich nicht zufällig bei jedem Quellcode mit anderen Bugs melden :), und wenn Du die Bugs berichtest, sollte zumindest deren Bearbeitung irgendwo festgehalten werden, so daß sie vielleicht eventuell ja mal beseitigt werden können. Letzteres hat der GCC wie gesagt schon deutlich länger, als es ISO 900x gibt. Ich kann mich dran erinnern, daß ich vor weit über 10 Jahren meinen ersten GCC-Bug berichtet hatte und dann doch recht erstaunt war, einige Monate später eine automatisierte Rückmeldung zu erhalten, daß der Bugfix dafür jetzt eingearbeitet ist. Die haben damals schon GNATS benutzt, so daß die Angelegenheit eben nicht in Vergessenheit geraten ist.
Jörg hat Recht, ich hab sowas leider auch mal mitmachen müssen. ISO900x sagt nix über die Qualität, sie kann auch sauschlecht sein, muss nur dokumentiert werden. Da kam auch die Frage wie ich die Funktionsfähigkeit meiner Software kontrolliere. Du wirst auch in fast allen Datenblättern zu den Bauteilen, ganz unten, ganz klein geschrieben einen Disclaimer finden, dass das Teil nicht für medizinische oder sonst wichtige Dinge verwendet werden darf. Renduntante Systeme helfen auch nicht unbedingt, da sie ja die selben Softwarefehler haben.
Hallo Oliver, Software in sicherheitsrelevanter Technik ist ein weites Feld. Zum Beispiel ist der Einsatz von Compilern in der Eisenbahnsignaltechnik nur zulässig, wenn dieser im benutzten Release a) betriebsbewährt oder b) validiert ist. In der Eisenbahnsignaltechnik ist da die Norm EN 50128 maßgeblich. Allgemein wird ähnliches auch in EN 61508-3 gefordert. Dort sich auch Sicherheits-Integritätslevel(SIL) bzw. Sicherheitsanforderungsstufen festgelegt.Für die Medizintechnik wird es sicherlich spezielle Normen geben, die auf der EN 61508 basieren. An die in den Normen geforderten Methoden und Arbeitstechniken sollte sich jeder richten, der Software macht, die bei Fehlfunktion Menschenleben oder Sachschäden zur Folge haben könnte. Zu den beiden oben genannten Möglichkeiten: a) Zur Argumentation, ob ein Compiler betriebsbewährt ist sollte folgendes berücksichtigt werden: - Ist genau der zu verwendende Compilerausgabestand (Release, Version) schon in anderen sicherheitsrelevanten Bereichen erfolgreich eingesetzt worden? Gibt es dazu eine Referenzliste des Herstellers? - Pflegt der Hersteller eine Bugliste und legt diese dem Anwender offen, so daß Workarounds zur Bugvermeidung möglich sind? Die Wordarounds sind notwendiger Bestandteil der zu erstellenden Programmierregeln! b) Zur Compilervalidation (oder auch Zertifizierung) gibt es z.B. von der Fa. Plumhall (http://www.plumhall.com/) Testsuites um zu Prüfen, ob der Compiler auch das macht, was er soll. Diese Programme sind kostspielig, genauso wie die Arbeit des eigentlichen Validierens. Vielleicht findet sich eine Version des MSPGCC, welche schon mal validiert worden ist und die Ergebnisse unter Kostenbeteiligung weitergegeben werden? Oder Du suchs Dir weitere Firmen / Abteilungen die auch eine MSPGCC-Validierung benötigen zum Kostenteilen. Vielleicht hat jemand aus diesem Forum Erfahrungen mit der Validierung von Compilern und kann weitere Ratschläge geben? Hilf das weiter? Viele Grüße von Marcus
Erfahrung habe ich nicht, aber dazu fällt mir ein, das es Firmen gibt, die ANSI-C-Konformitität prüfen und eine Compiler-Testsuite gibt's anscheinend nur beim gcc.
Eine medizinische Zertifizierung, bei der einiges mehr als nur Dokumentation und "wie immer" gemacht werden muß, steht auch in der Firma an, in der ich derzeit arbeite. Mal sehen, ob da was zum Compiler gefordert wird. Falls ja, wird wohl erstmal der Code so erweitert, dass man ihn unter IAR wie unter MSPGCC compilieren kann, denn das habe ich schon bei zwei Projekten gemacht und so einige Fehler/Abweichungen vom ANSI-Standard gefunden.
"Mal sehen, ob da was zum Compiler gefordert wird." Wenn eine Fehlfunktion der Software den Patienten in's Aus kicken kann, dann wird sicher etwas gefordert. Ich bin überzeugt, daß es in der Medizintechnik ähnlich strenge Richtlinie gibt, wie in der Eisenbahnsignaltechnik! Für die Software ist sicher ein SIL>0 ermittelt worden und schon sind sehr sehr gute Begründungen notwendig, um von den als "mandatory" oder "highly recommended" eingestuften Methoden und Arbeitsweisen abzuweichen. Auch der unabhängige Gutachter muß der Argumentation folgen und diese dann mittragen! "Falls ja, wird wohl erstmal der Code so erweitert, dass man ihn unter IAR wie unter MSPGCC compilieren kann, denn das habe ich schon bei zwei Projekten gemacht und so einige Fehler/Abweichungen vom ANSI-Standard gefunden." Diversität ist nicht ungeschickt! "Erfahrung habe ich nicht, aber dazu fällt mir ein, das es Firmen gibt, die ANSI-C-Konformitität prüfen" Compilervalidierungen sind beliebte Auftragsarbeiten und richtig teuer! "und eine Compiler-Testsuite gibt's anscheinend nur beim gcc." Jeder Compiler kann mit einer solchen Testsuite auf ANSI-Konformität geprüft werden. Aber das ist nur eine Teilaufgabe der Testsuite und auch nur ein Teil der Validierung. Wichtiger ist noch die Prüfung, ob die Hochsprachenkonstrukte auch korrekt umgesetzt werden. Viele Grüße von Marcus
Medizinprodukte und im speziellen "programmierbare elektrische Medizinische Geräte" = PEMS sind ein extrem komplexes Thema, dabei ist die Diskussion der obigen Compiler nur ein winziger Teilsapekt. Ich arbeite in einer Firma, die Medizingeräte entwickelt. Ich bin kein Experte dieses Themas, versuche aber einmal grob das ganze anzureissen. (Das ist jetzt sicherlich off topic ...) Man kann nicht einfach sagen "ich bau/entwickel das Geräte unter ISO900xxxx". In Deutschland bzw. der EU gibt es das Medizinprodukte- gesetzt (MPG) bzw. die Medizinprodukterichtlinie. Dieses Gesetz befasst sich sehr allgemein mit Geräten/Software/Stoffen zur "Erkennung/Verhütung/Überwachung/Linderung von Krankheiten/Behinderungen....." also z.B. - Herzschrittmachern, EKGs, - Hörgeräte, Pulsmesser ... aber auch - Spritzen, Pflaster, Verhütungsmittel und vieles mehr Da ein kaputtes Verhütungsmittel vermutlich weniger Schaden anrichtet ;-) als ein defekter Herzschrittmacher, werden dies Produkte in Klassen unterteilt. Dafür gibt es Regeln im Anhang des Gesetzes. Als Hersteller muss man die gesetzlichen Anforderungen erfüllen. Um das "Nachzuweisen" nutzt man EU harmonisierte Normen. Das Produkt soll später gemäß der Produktdoku gebaut werden, weshalb ein QM-System nötig ist. Das ist nicht nur die ISO9001 sondern seit neuestem bei Medizinprodukten die ISO13485. <... OK Schnitt, das wird zu komplex ...> Eine wichtige Norm für PEMS ist die IEC (bzw. EN) 60601-1-4 für programmierbare elektrische Medizinische Geräte. Dabei geht es unter anderem um - ein Entwicklungsmodell (Lebenszyklus des Gerätes) - Verifizierung und Validierung - Risikoanalyse (die bei Herzschrittmachern beliebig komplex werden kann...) <... OK Schnitt, das wird zu komplex ...> Was ich damit sagen will: Die Materie ist ohne Expertenwissen nicht bewältigbar. Die Normenreihe 60601 enthält zig Fachnormen zu unterschiedlichen Geräeten, unter anderem auch für Beatmungsgeräte. Noch kurz zu Open Source Software Nutzung bei Medizingeräten Marcus Else schreibt es oben gut; Softwaretools für Medizinprodukte müssen validiert sein, das gilt aber nicht nur für die Compilertools. Auch die Tools zum Testen, Archivieren .... müssten streng genommen validiert sein. Wir nutzen hier z.B. CVS als Versionsverwaltungssystem und haben durch ein Seminar erfahren, dass dass eigentlich nicht "erlaubt" ist, da keine CVS Version validiert wurde, und das bei einem System, dass sicherlich bei tausenden von Firmen genutzt wird... Ich hoffe ich hab euch nicht zu sehr mit BlahBlah genervt.... Klaus
Also das mit dem Validieren kann man auch übertreiben, denn man müsste ja auch z. B. jedes Netzteil jedes verwendeten PCs validieren, weil bei Spannungsschwankungen Fehler auftreten können, nur registered ECC RAM verwenden usw.. Da gibt's genaugenommen kein Ende. Wichtiger als das Netzteil wäre auch erstmal das verwendete Betriebssystem, aber das geht schonmal nicht, wenn das von Microsoft kommt. Wie gut "validiert" das ist, was von M. kommt, sieht man z. B. beim IIS: Es ist bekannt, dass der Server durch ein immer noch unbekanntes Sicherheitsloch übernommen werden kann und genutzt werden kann jedem einen Trojaner zu installieren, der auch nur eine Seite des IIS benutzt: http://www.heise.de/newsticker/meldung/48589 CVS ist doch eines der zuverlässigsten Versionsverwaltungssysteme; welche sollen denn validierter sein?
"welche sollen denn validierter sein?" Man sollte dabei nicht vergessen, dass "validiert" nicht beduetet, es funktoniert ganz gut, weil seit 10 Jahren 1000e gut damit fahren. Validieren ist ja eher sowas wie die nächste Stufe nach der Verifikation: Wenn etwas verifiziert ist, habe ich getestet, dass es funktioniert, wenn ich es validiere habe ich "bewiesen" das es funktionieren muss. Das kann man zwar so nicht sagen :), aber es sollte mehr oder weniger den Kern der Sache treffen. Ansonsten: Darf man in der Branche überhaupt (ANSI) C benutzen? In der Autmobilbranche z.B. wird doch wenn überhaupt meist MISRA C eingesetzt (quasi ein Subset von C mit 127 (?) Regeln/Verboten die eingehalten werden müssen) MfG Sebastian
nobodyoweb.de schrieb: > Also das mit dem Validieren kann man auch übertreiben, > denn man müsste ja auch z. B. jedes Netzteil jedes > verwendeten PCs validieren... OK, auch ich habe übertrieben. Die Geschichte mit der Validierung des Versionierungssystem kam nicht von der europäischen Seite, sondern von der amerikanischen UL. > CVS ist doch eines der zuverlässigsten Versionsverwaltungssysteme; > welche sollen denn validierter sein? M.soft's VSS ist anscheinend auch nicht validiert, es gibt wohl nicht viele validierte Systeme... Ich habe mal ein bischen gegoogelt und fand eine interessante Diplomarbeit zum Thema "richtlinienkonforme Softwareentwicklung von Medizinprodukten" in der schon einiges zum Thema beschrieben ist. Zwar hat sich in den letzten 3 Jahren noch ein bischen was getan, aber als Wegweisser gut zu gebrauchen... http://www4.in.tum.de/lehre/da/DA_Harboeck.pdf Klaus
Interessant. @Sebastian: Verifiziert bedeutet bewiesen, also so sicher nachgewiesen wie 2+2=4. Das ist ziemlich aufwendig und bei Microcontrollern besonders schwer, weil einige Verfahren ein Terminieren voraussetzen, also einen kontrollierten Absturz des MCs! Validiert heißt nur bewertet (d. h. bei 2 Experten gibt's 3 Meinungen = Bewertungen). Und von MISRA C habe ich noch nix gehört. Ich verwende ANSI-C-Kompiler, bezw. Compiler in diesem Modus und den ANSI-Standard habe ich mir mal gekauft (www.ansi.org, rd. 14 EUR) u. komplett durchgelesen (so wie auch die C-FAQs). Dass der ANSI-Standard einiges offen läßt und die C-FAQs einige Bugs haben ist ja bekannt, aber weil man für spezielle Sache ohnehin Assembler braucht, ist C sowieso nicht ausreichend. Außerdem sind reine Software-Verifikationen/Validierungen nur Luftnummern; denn Software ist nur die Eigenschaft von Hardware und deshalb zuerst muß diese Verifiziert/Validiert werden. Ich muß nämlich allein beim MSP430 jedes Jahr ein Software-Workaround um Hardware-Bugs machen und beim s3c2410 sieht es nicht besser aus, obwohl beide seit Jahren auf dem Markt sind und in "Massproduction" sind. Sachen wie der erste Pentium-Bug sind bekannter, aber bei MCs ist das fast Alltag. Dazu kommt, dass bei der Verifikation/Validierung häufig falsche Voraussetzungen verwendet werden. Beispielsweise bei der Flugzeugsteuerung, dass der Rückschub (zum Bremsen) erst bei nachgewiesenem Bodenkontakt der Räder aktiviert wird. Da war der Fehler, dass das bei Aquaplaning nicht funktioniert. Deshalb gab's trotz Verifikation u. Valdierung einige Tote (mit einer Lufthansa-Maschine auf dem Warschauer Flughafen).
Hallo, Ich möchte ein Bischen über Verifikation und Validierung klären: Normalerweise benutzt man verschiedene Prozessmodelle zur Entwicklung vom Software. Z.B. Wasserfallmodell, V-Modell, Spiralmodell usw. Diese Prozessmodelle haben verschiedene Phasen, die mit der Anforderungsphase anfangen und mit der Validierungsphase beenden(Sogenannte Abnahme-Prüfung). Verifikation ist die Überprüfung eines Software-Produkt am Ende einer Entwicklungs-Phase gegen vorgegebene Anforderungen, üblich gegen die Ergebnisse der vorgehenden Phase. Validation (Validierung) handelt es um die Frage, ob ein Software-Produkt seinen Anforderungen gerecht wird. Nun ISO-9000 ist ein Standard für Qualität und die Focus ist der Entwicklungsprozess. Wenn es um Sicherheitsfragen geht, kann man diese Standard vergessen. Außerdem Qualitätsstandards sind allgemein freiwillig oder nur von Auftraggebern verlangt (Autoindustrie). Sicherheitsstandards sind in industriellen Länder von Behörden reguliert und für alle obligatorisch (USA ist eine Ausnahme).
Naja, manche dehnen den Begriff Verifikation sehr weit; ich kenne es aus dem Informatik-Studium als mathematischen Beweis, dass das Programm genau das macht was es soll (nicht mehr aber auch nicht weniger) und nicht eine Überprüfung, die mehr oder minder ungenau ist und mehr oder minder lückenhaft durchgeführt wird. Nach einer Verifikation hat eine Software keine Fehler mehr! Deshalb (und auch weil es teuer ist) wird eine richtige Verifikation nur bei der NASA und ein paar ganz wenigen anderen Organisationen gemacht und auch dort nur für wichtiges wie Lageregelung oder Flugsteuerung. Was Firmen wie Microsoft machen, ist sehr weit davon entfernt und daran ändern Normen wie ISO 9000 nichts; diese Normen beschreiben wie aus Fehlern gelernt werden soll, aber nicht wie sie verhindert werden sollen. Das ist eine ganz andere Vorgehensweise.
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.