Forum: Compiler & IDEs Rechtliche Grundlagen für Einsatz von MSPGCC


von Oliver Rogasch (Gast)


Lesenswert?

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

von Jörg Wunsch (Gast)


Lesenswert?

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. ;-)

von Peter D. (peda)


Lesenswert?

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

von Oliver Rogasch (Gast)


Lesenswert?

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

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Jörg Wunsch (Gast)


Lesenswert?

Ein ISO 900x Statement sehe ich übrigens nichtmal bei IAR.

von nobody0 (Gast)


Lesenswert?

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.

von Jörg Wunsch (Gast)


Lesenswert?

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.

von Fritz Ganter (Gast)


Lesenswert?

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.

von Marcus Else (Gast)


Lesenswert?

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

von nobody0 (Gast)


Lesenswert?

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.

von nobody0 (Gast)


Lesenswert?

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.

von Marcus Else (Gast)


Lesenswert?

"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

von Klaus Hummel (Gast)


Lesenswert?

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

von nobody0 (Gast)


Lesenswert?

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?

von Sebastian (Gast)


Lesenswert?

"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

von Klaus Hummel (Gast)


Lesenswert?

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

von nobody0 (Gast)


Lesenswert?

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).

von Alejandro Lopez Hernandez (Gast)


Lesenswert?

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).

von nobody0 (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.