Hallo,
ich implementiere im Moment eine sicherheitskritische Software für ein
Produkt, bei welchem Menschen im schlimmsten Fall durch sehr heißes
Wasser zu Verbrühungen kommen kann.
Die Software ist soweit fertig und auch alle Tests des
Sicherheitskonzepts werden erfüllt.
Das ganze läuft in einem AVR und ist mit WinAVR in C geschrieben.
Jetzt der Knackpunkt: darf man für solche Software überhaupt den GCC
verwenden!? Bin ich verpflichtet einen wie auch immer gearteten
zertifizierten Compiler zu verwenden? Der Herr vom TÜV der die
technische Sicherheit des Produktes überprüft konnte keine klare Aussage
dazu treffen.
Habt Ihr schon mal sicherheitskritische Software mit dem GCC
implementiert und seit auf die gleiche Problematik gestoßen?
Gruß
Stefan
was ich noch von früher weiss, dass es solche Compiler gibt, aber die
kann sich kaum eine Firma leisten. Ist bei dir eigentlich
Codeoptimierung eingeschaltet?
Der AVG-GCC ist betriebserprobt. Ich weiss, dass er in Firmen teilweise
für Anwendungen mit SIL4 verwendet wird.
Entscheident ist, dass es noch weitere Sicherungen gibt. Hierzu gehört
z.B. das das System 2-Kanalig ausgelegt und diversitär programmiert
wurde.
Software-Sicherheit ist immer relativ. Deshalb werden bei wichtigen
Sachen auch 3 unabhänige Systeme verbaut. Wenn es nur um einen WW-Boiler
geht, würde ich eine zusätzliche unabhängige Übertemperatursicherung
einplanen.
Bei Sicherheitsrelevanten Sachen sollte man mind. 2 Prozessoren
verwenden, die die Ergebnisse jeweils am besten noch mit
unterschiedlichen Code (sprich A und B Code, von 2 Entwicklern)
berechnen und die Ergebnisse vergleichen. Fällt dieses positiv aus, kann
das Programm fortfahren, wenn nicht, muss die Einrichtung einen sicheren
Zustand einnehmen.
Auch gewisse Programmierrichtlinien sind einzuhalten (z.B. ist
dynamische Speicherreservierung verboten).
Vor allen musst du nachweisen können, ob deine Software in allen Fällen
unkritisch ist, d.h. wenn, dann immer zu sicheren Seite ausfällt, in
deinen Fall darf es also auf keinen Fall vorkommen, dass Menschen zu
Schaden kommen können.
Als Beispiel Bahn AG: Es darf nicht vorkommen, dass bei Rechnerausfall
ein Signal auf Fahrt geht, die Lokomotive auf Vollgas geht, usw.
Rogie schrieb:> Vor allen musst du nachweisen können, ob deine Software in allen Fällen> unkritisch ist, d.h. wenn, dann immer zu sicheren Seite ausfällt, in> deinen Fall darf es also auf keinen Fall vorkommen, dass Menschen zu> Schaden kommen können.
Bei manchen Anwendungen ist es aber sehr schwierig oder unmöglich, solch
einen sicheren Fall zu definieren, z.B. bei einem lebenserhaltenden
System wie einem Beatmungsgerät oder einer Herz-Lungen-Maschine. Da muss
man eher sicherstellen, dass das Gerät nach einem Fehlerzustand
schnellstmöglich wieder funktionsfähig wird. Eine Sicherheitsabschaltung
würde hingegen den sicheren Tod des Patienten bedeuten.
... schrieb:> ich glaube Codeoptimierung ist auch tabu, weil man nicht weiss, was> genau wegoptimiert wird
Man sollte während der Testphase (ohne Gefährdungspotential!) jedoch mit
verschiedenen Optimierungseinstellungen herumspielen, um dadurch
versteckte Programmierfehler aufzudecken.
Rogie schrieb:> Als Beispiel Bahn AG:
... oder Toyota ...
> Es darf nicht vorkommen, dass bei Rechnerausfall ein Signal auf Fahrt> geht, die Lokomotive auf Vollgas geht, usw.Andreas Schweigstill schrieb:> Eine Sicherheitsabschaltung würde hingegen den sicheren Tod des> Patienten bedeuten.
Na dann ist es doch ziemlich sicher ;-)
SCNR ... hab heute wohl meinen gehässigen Tag.
Stefan schrieb:> Der Herr vom TÜV der die> technische Sicherheit des Produktes überprüft konnte keine klare Aussage> dazu treffen.
Was ich mich schon länger frage:
Wie prüft jemand etwas, von dem er keine Ahnung hat?
Ich vermute mal, irgend jemand erstellt ne Checkliste und ein anderer
hakt sie ab und dann ist die Sache gegessen.
Peter
Peter Dannegger schrieb:> Was ich mich schon länger frage:> Wie prüft jemand etwas, von dem er keine Ahnung hat?
Danke, Peter ;-)
Dazu kommt noch die Frage, wer ein Sicherheitskonzept erstellt, bei der
nach Fertigstellung des Produktes solche Fragen auftauchen.
Also: Gelbe Seiten. Such dir jemanden, der sich damit auskennt.
Und sollte es für dein Produkt keine verbindlichen Sicherheitsnormen
geben (was durchaus sein kann), tja, dann wirst du im Falle eines Falles
vor Gericht erfahren, was du hätttest noch beachten können müssen.
Oliver
Peter Dannegger schrieb:> Was ich mich schon länger frage:> Wie prüft jemand etwas, von dem er keine Ahnung hat?
Derjenige prüft, ob bestimmte Formalismen eingehalten wurden. Der
Zeitbedarf für deren Einhaltung geht natürlich von der
Projektarbeitszeit ab, so dass es auf Grund des höheren Zeitdrucks sogar
zu einer erheblichen Verschlechterung der Produktqualität kommen kann.
Bei einem Kundenprojekt habe ich solch einen Evaluierungsprozess
mitgemacht. Da gab es Unmengen zu erfüllender Anforderungen, die zum
Teil völlig unsinnig waren. Es wurde beispielsweise überprüft, ob der
Raum mit den Netzwerkdruckern gegen unbefugten Zugang abgesichert war,
damit Dritte keinen Blick auf Programmlisting werfen konnten. Dabei
wurde nicht berücksichtigt, dass es sich bei der zu entwickelnden
Software eh um (auf Grund der GPL) offenlegungspflichtige Quellen
handelte. In den anzuwendenden Prüfvorschriften war so etwas jedoch nie
berücksichtigt worden.
Insgesamt stelle ich immer wieder fest, dass bei sicherheitskritischer
Software in einem erstaunlichen Maße Wert auf Geheimhaltung gelegt wird,
was ja völliger Humbug ist. Gerade die wirklich unfähigen Entwickler
finden solche Regelungen wiederum ganz toll, weil sie dadurch eine
Argumentationshilfe gegen ein Review ihrer eigenen Quelltexte bekommen.
Stefan schrieb:> darf man für solche Software überhaupt den GCC> verwenden!?
Natürlich, grundsätzlich darf man das.
Wichtig ist ja nicht, dass die Software niemals niemals niemals abstürzt
(das glaubt dir eh keiner), sondern dass das Gesamtkonzept sicher genug
ist und dass auch bei einem Softwareabsturz (oder bei einem anderen
zufälligen Fehler) niemand zu Schaden kommen kann.
Peter Dannegger schrieb:> Ich vermute mal, irgend jemand erstellt ne Checkliste und ein anderer> hakt sie ab und dann ist die Sache gegessen.
So in etwa läuft es ab. Die Norm wird von anderen Leuten erstellt, als
diejenigen die Schlussendlich Punkt für Punkt die beschriebenen Absätze
abklopfen.
Oliver schrieb:> Dazu kommt noch die Frage, wer ein Sicherheitskonzept erstellt, bei der> nach Fertigstellung des Produktes solche Fragen auftauchen.
Das erstellte Sicherheitskonzept hat als letztendlich offene Frage, ob
ein auf open source basierender Compiler Verwendung finden darf. Dieser
Punkt wurde von mir nicht erkannt.
Asche auf mein Haupt! Wer müsste von uns da nicht an und an die Gelben
Seiten konsultieren?
Oliver schrieb:> Und sollte es für dein Produkt keine verbindlichen Sicherheitsnormen> geben (was durchaus sein kann), tja, dann wirst du im Falle eines Falles> vor Gericht erfahren, was du hätttest noch beachten können müssen.
Genau das ist der Puntk. Es existiert keine vorhandene Norm, in die das
Produkt vollends hineinkatalogisiert werden kann und somit in diese oder
jene Norm gepresst wird.
Aber das ist alles ja auch nicht die Frage gewesen, die da lautet:
GCC genutzt, diese Art von Software erstellt und Probleme damit an
entsprechender Stelle bekommen.
Und was nützt einem der tollste "zertifizierte" Compiler, den eigentlich
nur eine winzige Zahl von Entwicklern benutzt und der durch keine
öffentlichen Reviews gegangen ist?
GCC hingegen enthält zwar auch einige Bugs, aber man darf auch nicht
vergessen, dass er auf um Größenordnungen mehr Plattformen eingesetzt
und damit auch getestet wird.
Der einzige Vorteil eines "zertifizierten" Compilers besteht darin, dass
man im Falle eines Fehlers bessere Chancen hat, eine Mitschuld einem
Dritten in die Schuhe zu schieben.
Wenn es dann wiederum dem Compilerhersteller gelingen sollte,
nachzuweisen, dass man in seinem Programm nicht strikt konform war zu
dem vom Compiler unterstützten Sprachstandard (ANSI C Version x, MISRA C
Version y), dann ist auch der Hersteller wieder aus der Haftung.
Aber das ganze ist wieder einmal "typisch deutsch". Wie häufig erlebe
ich es, dass gerade Entscheider in Projektbesprechungen überhaupt nicht
versuchen, ein Projekt erfolgreich umzusetzen, sondern lieber von
vornherein einen Schuldigen für ein eventuelles Scheitern des Projektes
festlegen wollen. Gerne bedienen sie sich dabei auch eines externen
Mitarbeiters/Dienstleisters, der plötzlich die Missstände der letzten
hundert Jahre verkorkster Entwicklung ausbaden soll.
Andreas Schweigstill schrieb:> Aber das ganze ist wieder einmal "typisch deutsch".
Na ja, nicht ganz. Der Nachweis, nach geltende Normen und nach bestem
Wissen und Gewissen alles für die Sichereheit des Produktes
erforderliche getan zu haben, rettet am Ende im Falle eines Falles die
eigene Existenz. Da geht es weniger darum, im Vorfeld Schuldige zu
suchen, sondern darum, im Ernstfall unbegründete Anschuldigungen
widerlegen zu können.
Oliver
Sonst bleibt nur: die Kiste in ein "anerkanntes Prüflabor" zu geben,
damit man einen Stempel mehr bekommt als Nachweis.
Ob der Compiler zugelassen ist oder nicht: ich kenne kaum ein Stück
Software was jahrelang ohne Update absolut fehlerfrei arbeitete. Damit
hast Du Wochen später das nächste Elend oder die nächste "Aufgabe".
Oliver schrieb:> Da geht es weniger darum, im Vorfeld Schuldige zu> suchen, sondern darum, im Ernstfall unbegründete Anschuldigungen> widerlegen zu können.
Oh, da habe ich als Dienstleister schon ganz andere Erfahrungen gemacht,
und zwar unabhängig davon, ob es sich um ein neues Projekt handelt oder
eines, das durch jahrelanges Herumgepfusche schon am Abgrund steht.
Teilweise wird durch entsprechend verklausulierte Vertragsbedingungen
versucht, eine vollständige Risikoübertragung auf den Dienstleister
durchzuführen. In anderen Fällen sind Kunden einfach nur blauäugig,
indem sie meinen, durch den Zukauf eines Fremdproduktes oder einer
Fremdleistung auch Probleme gelöst zu bekommen, die kein Teil der
Beauftragung sind. Besonders stutzig werde ich auch dann, wenn Kunden
einen Nachweis darüber verlangen, dass man eine ausreichende Liquidität
besitzt, um ein Scheitern des gesamten Projektes bezahlen zu können.
Leider muss ich auch feststellen, dass Anfragen für die genannte Art von
Projekten mittlerweile nicht mehr die Ausnahme sind, sondern die
Mehrheit darstellen.
Natürlich kann man nicht daraus folgern, dass das auch für die Mehrheit
aller überhaupt durchgeführter Projekte zutrifft. Externe
Projektunterstützung wird eben selten angefragt, solange noch alles im
grünen Bereich ist, sondern häufig erst in Krisensituationen.
Einen gewissen Anteil an Kunden muss ich jedoch von o.a. Vorwürfen
freisprechen! Das sind solche, deren eigene Entwickler manchmal nicht
mehr den Wald vor lauter Bäumen sehen, ein spezifisches technisches
Problem haben und rechtzeitig externe Unterstützung - i.A. auch nur
für einige Stunden oder Tage - anfordern. Interessanterweise sind das
aber auch die eher kompetenten Entwickler.
Also bei Flugnavigationssoftware etc. brauchst du zertifizierte
Compiler, bei Haushaltsgeräten nicht, da verbrüht man sich ja schon an
einem simplen Kochtopf.
Wenn aber das Haus abbrennt, weil dein uC ständig geheizt hat, zahlst du
Schadenersatz. Es ist also immer ein unabhängig von Software arbeitender
Sicherheitsmechanismus notwendig.
Mal 'ne andere Frage: Wie wahrscheinlich schätzt ihr einen
Compilerfehler als Fehlerursache im Vergleich zu einem Softwarefehler
oder gar zum Hardwarefehler in diesem konkreten Fall ein? Genau.
Außerdem ist der Hersteller immer in der Produkthaftung. Wenn man ihm
nicht grobe Fahrlässigkeit oder gar Vorsatz nachweist, ist seine
Haftpflicht dran. Bzw. die wird evtl. erstmal zahlen und ihn dann in
Regress nehmen. Viel wichtiger bei einer solchen Entwicklung ist, daß
man die geltenden Normen und den Stand der Technik berücksichtigt hat,
vernünftige Riskoanalysen mit entsprechenden Konsequenzen nachweisen
kann (z.B. komplett separater Sicherheitschaltkreis zur Überwachung
kritischer Parameter/Fehlerzustände), entsprechende Tests gemacht wurden
und auch sonst ein "professionelles" (angemessenes) Vorgehen nachweisbar
ist, wie z.B. nutzen der selben Compilerversion auch für eventuelle
Updates (nicht nur im Produkt, hier unwahrscheinlich, sondern auch bei
einer neuen Fertigungsreihe, nach dem Motto "baut auf 3-jähriger und
600-fach bewährter Basissoftware auf.
Haftung ist, wie gesagt, klar, nur die anderen Punkte sind zivil- und
vor allem strafrechtlich die ausschlaggebenden Punkte.
Lutz schrieb:> Mal 'ne andere Frage: Wie wahrscheinlich schätzt ihr einen> Compilerfehler als Fehlerursache im Vergleich zu einem Softwarefehler> oder gar zum Hardwarefehler in diesem konkreten Fall ein?
Genaugenommen ist es egal wieviele Fehler ein Compiler hat.
Was letztendlich zählt, ist der Code, der schlussendlich auf der
Maschine laufen wird. Und das ist nicht C-Code, nicht Ada-Code, nicht
Assembler-Code, und auch nicht Object-Code, sondern fertig gelinkter und
lokatierter Maschinencode, der in einer bestimmten Ausführungsumgebung
läuft (Wait-States für Speicherzugriff, Caching-Effekte,
Pileline-Effekte, ...). Letztere sind für AVR allerdings nicht
bedeutsam.
Praktisch jede sicherheitskritische Software muss echtzeitfähig sein,
und um wasserdichte WCET-Analysen zu erhalten, müssen die Analysetools
auf den Hex-Files arbeiten. Vieles können die Tools selbständig
ableiten, aber eben nicht alles, und dann muss jemand, der sich mit der
Software und der Hardware auskennt, dem Tool unter die Arme greifen
(etwa bei indirekten Funktionsaufrufen, Obergrenze von
Schleifeniterationen, ...)
Wahr ist allerdings, daß ein fehlerfreier, nicht-optimierender Compiler
das Entwicklerleben deutlich vereinfacht oder sogar vorgeschrieben wird,
welcher Compiler wie zu verwenden ist (Version, Zertifizierung,
Verschalterung, Bugtracking, ...).
Neben der eigentlichen Software die laufen wird und der Hardware gehört
allerdings auch das Entwicklungsumfeld zur Erstellung solcher Software,
und es ist nicht ungewöhnlich, daß an den Entwicklungsprozeß selbst
anforderungen gestellt werden, um eine Zertifizierung zu erhalten wie
bestimmtes Qualitätsmanagement, Coding-Rules à la MISRA, etc.
Hallo Johann.
> Neben der eigentlichen Software die laufen wird und der Hardware gehört> allerdings auch das Entwicklungsumfeld zur Erstellung solcher Software,> und es ist nicht ungewöhnlich, daß an den Entwicklungsprozeß selbst> anforderungen gestellt werden, um eine Zertifizierung zu erhalten wie> bestimmtes Qualitätsmanagement, Coding-Rules à la MISRA, etc.
Richtig. Und zertifiziert ist alles SAUTEUER und BÜROKRATISCH.
Wir werden im Moment auf Sicherheit angefixt wie auf Heroin. Wenn wir
aber international mithalten wollen, müssen wir irgendwann von unseren
hohen Standards RUNTER auf den von Entwicklungs und Schwellenländern.
Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.dl0dg.de
>zertifiziert ist alles SAUTEUER und BÜROKRATISCH
Muß aber nicht besser sein, wenn man dann die Fehler wegen irgendeiner
Zertifizierung nicht so einfach beseitigen kann.
Wichtiger als irgenwelche Stempelchen scheint mir, daß sich die Software
an bestimmten Stellen selbst auf Plausibilität prüfen kann. Damit erhöht
die Qualität. Durch Updates oder neue Compiler eingeschlichene
Veränderungen werden dann evtl. vor der Katastrophe bemerkt.
Stefan schrieb:> Jetzt der Knackpunkt: darf man für solche Software überhaupt den GCC> verwenden!? Bin ich verpflichtet einen wie auch immer gearteten> zertifizierten Compiler zu verwenden? Der Herr vom TÜV der die> technische Sicherheit des Produktes überprüft konnte keine klare Aussage> dazu treffen.
Zuerst sollte mal geklärt werden, welchen Normen und Gesetzen Dein
Produkt bzw. dessen Inverkehrbringen genügen muss. Sind dort keine
klaren Regeln für Deine Frage beschrieben, läuft es wohl auf "Stand der
Technik" und "proven in use" hinaus. Das heißt, es sind in dem Bereich
allgemein übliche und verwendete technische Maßnahmen anzuwenden. Eine
klare Antwort diesbezüglich gibt es also nicht, weil das vom konkreten
Fall abhängt.
Als Beispiel die Automobiltechnik: Hier werden in der Regel
"qualifizierte" Compiler eingesetzt. Ob deren Fehlerrate aber wirklich
unterhalb der Rate vom gcc liegt, bezweifle ich. Das Entwicklungsmodell
solcher Compiler kann meines Erachtens nach nicht mit einer offenen
Entwicklung mithalten. Aber in die üblichen Prozesse passt eben ein
qualifizierter Compiler besser.
Zusätzlich zu den Compilern stellt sich auch noch die Frage nach der
Implementierung selber. Also die Programmierung (in der Automobiltechnik
sind die MISRA-Regeln maßgebend), das im Design liegende
Sicherheitskonzept (also im Fehlerfall soll das System in einen sicheren
Zustand gehen) und evtl. irgendwelche zusätzlichen
Sicherheitseinrichtungen, die Fehlerzustände erkennen und das System in
einen sicheren Zustand versetzen. Wie oben schon beschrieben empfehlen
sich da schon mehrstufige und evtl. parallele oder eigenständige
Sicherheitseinrichtungen.
Eine gute Idee ist meines Erachtens auch, dass man die gesamte
Sicherheitsstrategie gut dokumentiert und mit dem Kunden (wenn nicht
gerade Endkunde) abspricht bzw. zum Teil der Abnahme macht.
Gastino G. schrieb:> Eine gute Idee ist meines Erachtens auch, dass man die gesamte> Sicherheitsstrategie gut dokumentiert und mit dem Kunden (wenn nicht> gerade Endkunde) abspricht bzw. zum Teil der Abnahme macht.
Technisch sinnvoll, um auch Jahre später noch brauchbare Unterlagen zu
haben. Es sollte nur kein Rechtsverdreher gegen Dich verwenden können.
oszi40 schrieb:> echnisch sinnvoll, um auch Jahre später noch brauchbare Unterlagen zu> haben. Es sollte nur kein Rechtsverdreher gegen Dich verwenden können.
Genau die Rechtsverdreher sind ja Ziel einer solchen Maßnahme. Macht man
das Sicherheitskonzept zum Teil der Abnahme durch den Kunden (wenn nicht
Endkunde!), verteilt man die Verantwortung schon mal auf mehrere
Schultern. Die Systemverantwortung trägt ja, wenn es um eine Art
Zuliefererverhältnis und nicht um Lieferungen an Endkunden geht, ohnehin
der OEM. Hinzu kommt, dass eine vernünftige Dokumentation der
Sicherheitsstrategie bei späteren Prozessen durchaus hilfreich sein
kann, um nachzuweisen, dass man sich mit dem Thema beschäftigt hat und
das zu diesem Zeitpunkt technisch und wirtschaftlich Machbare getan hat.
Natürlich ist das alles keine Garantie gegen Prozesse und Kosten, aber
allemal besser als dann mit leeren Händen dazustehen.
Andreas Schweigstill schrieb:> Bei manchen Anwendungen ist es aber sehr schwierig oder unmöglich, solch> einen sicheren Fall zu definieren, z.B. bei einem lebenserhaltenden> System wie einem Beatmungsgerät oder einer Herz-Lungen-Maschine. Da muss> man eher sicherstellen, dass das Gerät nach einem Fehlerzustand> schnellstmöglich wieder funktionsfähig wird. Eine Sicherheitsabschaltung> würde hingegen den sicheren Tod des Patienten bedeuten.
Da geht man dann über Redundanz, z.B. sind im Flugzeug mehrere Systeme
für ein und diesselbe Aufgabe vorhanden, meines wissens nach mind. 3.
Wenn 2 das richtige Ergebnis liefern und eins nicht, so wird das
fehlerhafte System ausgeschaltet und die restlichen zwei Systeme
übernehmen dann die Aufgabe. Fällt dann noch eins aus: Keine Ahnung, wie
dann verfahren wird.
Rogie schrieb:> Da geht man dann über Redundanz, z.B. sind im Flugzeug mehrere Systeme> für ein und diesselbe Aufgabe vorhanden, meines wissens nach mind. 3.> Wenn 2 das richtige Ergebnis liefern und eins nicht, so wird das> fehlerhafte System ausgeschaltet und die restlichen zwei Systeme> übernehmen dann die Aufgabe. Fällt dann noch eins aus: Keine Ahnung, wie> dann verfahren wird.
Ich würde mal sagen, dass dann der Bediener übernehmen muss. Im Flugzeug
wird es laut klingeln, um die Piloten wieder zu wecken und soweit ich
weiß, gibt es bei der Herz-Lungen-Maschine auch einen Handbetrieb. Da
wird der Kardiotechniker dann in's Schwitzen kommen. :D
Rogie schrieb:> Da geht man dann über Redundanz, z.B. sind im Flugzeug mehrere Systeme> für ein und diesselbe Aufgabe vorhanden, meines wissens nach mind. 3.
Über die Syteme im A380 war mal ein Artikel in der c't. Da sind alle
kritischen Syssteme dreifach vorhanden, und zwar alle nach der selben
Spezifikation erstellt, aber unterschiedliche Hardware und unabhängig
von einander geschriebene Software verwenden.
So vermeidet man Situationen, in denen derselbe Fehler (Prozessor-Bug,
Schaltungs-Fehler, Software-Fehler, Compiler-Fehler, ...) bei allen drei
Systemen gleichzeitig zuschlägt.
> übernehmen dann die Aufgabe. Fällt dann noch eins aus: Keine Ahnung, wie> dann verfahren wird.Gastino G. schrieb:> Ich würde mal sagen, dass dann der Bediener übernehmen muss.
Es handelt sich aber um Systeme, die zwischen Bediener und den Rudern
der Maschine sind. Fallen die aus, müßte der Bediener schon rausgehen
und die Ruderklappen mit der Hand in die Zielstellung drücken.
Ob TS Stefan nun für seine neue Wärmflasche wirklich 3 unabhängige
Systeme braucht?
Als ich zur Steinzeit der Computer mal einen kleinen Compiler-Test
gemacht habe, hatte ich hinterher statt 3 Zeilen Code stattliche 12k
Code, die nicht mal das selbe taten. Wieso sind wir da heute
optimistischer?
Ich würde dazu sagen:
110% Dokumentation für alles, von PC-Konfiguration, Tools-Konfiguration,
..., Risikoanalyse bis Projekt selber - "... wenn Geschwindigkeit >
110, eine rote Lampe brennt ..." und ein Link auf „Blockdiagramm“. Von
hier wieder ein Link auf den Code (alles machbar mit DOORS):
if (speed > 110)
RedLamp = true;
Für die Tests: funktionale Tests (Unit Tests) und Code Coverage (MCDC,
Branch coverage). Man sollte auch ein „Language Subset“ verwenden, d.h.
z.B. MISRA und einen „amtlich“ anerkannten MISRA Checker (Q&C, …). Ab
IEC 61508 SIL3 eine statische Codeanalyse durchzuführen (die Norm sagt
"Highly reccomended"). Für alles am besten „Qualified“ Werkzeuge
einsetzen (noch besser Certified, die aber nicht existieren oder
unbezahlbar sind). Man kann auch ne gcc selber qualifizieren. Es sind
50-100 Seiten Beschreibung und ~10.000 Tests Patterns.
Es ist alles machbar, aber praktisch als Einzelperson nicht bezahlbar.
Unsere Firma verkauft ein „Qualifikation Kit“, wo schon 75% fertig ist
für ~10k €. Aber ohne der Vorkenntnisse mit TÜV & Co. immer noch seeeehr
schwierig.
Apropos: in SIL2 sind Einzelpersonen verletzt, in SIL3 sind mehrere
Personen betroffen.
Rogie schrieb:> Wenn 2 das richtige Ergebnis liefern und eins nicht, so wird das> fehlerhafte System ausgeschaltet
Für Verkehrsflugzeuge ist es Vorschrift, existentielle Systeme 3-fach
redundant vorzuhalten. Aber automatisch abgeschaltet wird da gar nichts,
daß müssen die Flugzeugführer schon selbst tun. Es wird (zumindest
wurde) noch nicht einmal ein Plausibilitätstest der 3 Systeme
untereinander im Betrieb durchgeführt. Sonst wäre z.B. Birgen Air nicht
in die Karibik geknallt: Ein Fahrtmesser zeigte eine viel zu hohen
Wert an. Unglücklicher Weise wurde dieser Fahrtmesser des Pilot Flying
auf den Autopiloten geschaltet und der Schub durch diesen so weit
verringert, daß die Maschine einen Strömungsabriß bekam. Paradoxer Weise
alarmierten andere Systeme zeitgleich und absolut widersprüchlich: MACH
TRIM SPEED (Overspeed) und STALL WARNING (zu langsam, Strömungsabriss)
sowie der Stickshaker (Vibrieren des Steuerknüppels) kamen. Das
verwirrte die Piloten. Hätten die allerdings schon beim Start richtig
reagiert, wäre nix passiert. Der nicht fliegende Pilot glotzt da nämlich
nur auf die Instrumente und macht Ansagen. U.a. sagt er, wenn sein
Fahrtmesser 80 Knoten anzeigt, dies an. In dem Moment glotzt der Pilot
Flying auf seinen und bestätigt dies (üblicherweise). Und hier sagte er
"check ..., äh, doch nicht)" ... . Ich schweife ab.
Oder auch bei Lauda-Air: Mitten im Flug kommt der Umkehrschub bei einem
Triebwerk ... . Mit Plausibilitätstests wär das alles nicht passiert.
> Wie wahrscheinlich schätzt ihr einen Compilerfehler> als Fehlerursache im Vergleich zu einem Softwarefehler> oder gar zum Hardwarefehler in diesem konkreten Fall ein?
Compilerfehler kommen vor, sie waren z.B. der Grund warum wir von
Borland C zu Microsoft C gewechselt sind (Microsfot C wurde für VIEL
mehr Implementationen verwendet und war wohl deswegen fehlerfreier),
aber auch unter Microsoft C und diversenen anderen sind uns Fehler
begegnet, teils im erzeugten Code (die man dann durch herunterstufen der
Optimierungen loswerden konnte) teils in der Implementation der
Standardbibliothek (die man durch nicht-verwenden der fehleraften
Funktionen umgehen konnte) und bei Mainframe-Copmilern auch gnadenlos
durch Fehlinterpretation von gültigen Sprachkonstrukten (*i++ ging
nicht). Compilerfehler sind also gar nicht so selten, und ncht alle
fallen in Tests auf (weil man ja gar nicht so genau weiss, auf welche
Grenzfälle man testen soll).
Hardwarefehler im CPU Chip sind eher selten geworden, aber daß
Schaltungen wegen Störungen aussteigen, gibt's öfters.
Natürlich sind die allermeisten Fehler von den Programmierern
verursacht. Die sind aber wenigstens behebbar.
Ich schrieb:> Der AVG-GCC ist betriebserprobt. Ich weiss, dass er in Firmen teilweise> für Anwendungen mit SIL4 verwendet wird.grmpf Nachdem ich gestern auch selbst noch auf die Erprobtheit des GCC
verwiesen hatte, wurde ich gestern höchstpersönlich eines besseren
belehrt...
Ein Fehler, der schon seit längerem bei einem bestimmten Softwarestand
unseres Projektes bekannt war und den ich mir selbst durch wiederholten
scharfen Blick auf den Quellcode nicht erklären konnte, bestand in
fehlerhaftem Code, den der WinAVR-100110 erzeugt hat. Eventuell war es
auch der Linker. Feststellen konnte ich den Fehler nur, weil ich im
Disassembler-Listing jede C-Instruktion auf Übereinstimmung hin
kontrolliert hatte.
Der Fehler bestand darin, dass im generierten Code die Adresse einer
Variable falsch berechnet wurde. Dadurch wurde eine Bitmaske falsch
berechnet. Nein, ich habe keine Typecasts mit unüberschaubaren
Seiteneffekten verwendet.
Schon minimale Modifikationen des Quellcodes lassen den Fehler
verschwinden.
Andreas Schweigstill schrieb:> bestand in> fehlerhaftem Code, den der WinAVR-100110 erzeugt hat. Eventuell war es> auch der Linker.
Gibt es dazu ein nachvollziehbares Beispiel?
Oliver
Andreas Schweigstill schrieb:> Der Fehler bestand darin, dass im generierten Code die Adresse einer> Variable falsch berechnet wurde.
Bitte unbedingt gucken, ob's dafür schon einen Bugreport gibt,
ansonsten berichten. Bugs, bei denen warnungslos falscher Code
erzeugt wird, sollten eigentlich eine hohe Priorität erhalten.
Oliver schrieb:> Gibt es dazu ein nachvollziehbares Beispiel?
Ich habe heute versucht, diesen Fehler nachzustellen, indem ich exakt
den Versionsstand der Quellcodes ausgecheckt habe, in dem der Fehler
auftrat. Selbstverständlich habe ich auch dieselbe Toolchain-Version auf
demselben Rechner verwendet.
Leider lässt sich das Verhalten nicht reproduzieren. Es ist jedoch vor
mehreren Wochen und vor einigen Tagen definitiv aufgetreten.
Somit kann ich derzeit leider keine Hinweise für die Fehlerkorrektur des
GCC geben. :-(
Wenn deine Software sicherheitsrelevant ist, dann lautet die
Fragestellung nicht darf ich den GCC verwenden ! Laut deiner Aussage ist
die Software eh fertig, d.h. die Frage hätte vor der Implementierung
gestellt werden müssen !
Vielmehr lautet die Frage : Wonach bzw. wie muss die Software geprüft
bzw. zertifiziert werden ?
Wenn die Software einer Norm etc. unterliegt, dann gibt es auch eine
Richtlinie hierfür ! Solltest du diese erst noch in Erfahrung bringen
müssen, dann hast du ein riesen großes Problem. Da ich mir nicht
vorstellen kann, dass du beim Programmieren so gut geraten hast um die
Richtlinie zu erfüllen. In der Richtlinie steht evtl. auch eine
Anmerkung zum Compiler bzw. zur Optimierung.
Generell gilt : Bei sicherheitsrelevanter Software muss man seine
Hausaufgaben VOR der Codeumsetzung machen, da hier das Gesamtkonzept
stimmen muss !!!
...also hier die Antwort vom TÜV:
> grundsätzlich besteht kein Problem [...bei der Verwendung des GCC]. Der> Kunde sollte sich aber für eine Version entscheiden (wie Sie ja schon> geschrieben haben), die Einsatzbedingungen kennen, Erfahrung damit haben> und die bug list beachten.
Ich muss zugeben: ich bin erleichtert!
Werde den teilweise gefallenen Ratschlägen in Zukunft mehr Beachtung
schenken.
Gruß
Stefan
Andreas Schweigstill schrieb:> scharfen Blick auf den Quellcode nicht erklären konnte, bestand in> fehlerhaftem Code, den der WinAVR-100110 erzeugt hat.
Unter uns Klosterschwestern:
Ich lese ja jetzt schon eine ganze Weile hier im Forum mit. Aber was
sich da im Laufe der Zeit an Bugs im WinAVR offenbart haben ... lies mir
ehrlich gesagt manchmal die Haare zu Berge stehen.
Manchmal war ich schon schwer am zweifeln, ob ich die Aussage 'Geh davon
aus, dass ein Laufzeitfehler zu >99% im Usercode und nicht im Compiler
seine Ursache hat' noch aufrecht halten soll.
Aber das sag ich nur unter vorgehaltener Hand :-)
Karl heinz Buchegger schrieb:> Aber was> sich da im Laufe der Zeit an Bugs im WinAVR offenbart haben ... lies mir> ehrlich gesagt manchmal die Haare zu Berge stehen.
Allerdings war bisher keiner dabei, der sich nicht reproduzieren liess.
Diese Sorte Bug wäre nämlich ganz übel.
Oliver
Karl heinz Buchegger schrieb:> Manchmal war ich schon schwer am zweifeln, ob ich die Aussage 'Geh davon> aus, dass ein Laufzeitfehler zu >99% im Usercode und nicht im Compiler> seine Ursache hat' noch aufrecht halten soll.
Die 99 % werden schon noch stimmen, nur die Masse ist mittlerweile
einfach größer geworden, sodass das 1 % häufiger mal zuschlägt.
@ Karl heinz Buchegger (kbuchegg) (Moderator)
>sich da im Laufe der Zeit an Bugs im WinAVR offenbart haben ... lies mir>ehrlich gesagt manchmal die Haare zu Berge stehen.
Beispiele?
Oliver schrieb:> Allerdings war bisher keiner dabei, der sich nicht reproduzieren liess.> Diese Sorte Bug wäre nämlich ganz übel.
Noch übler, wenn's garkein Bug ist ;-)
Ich hatte neulich das erste Mal das "Vergnügen", einem Bitkipper von der
sporadischen (also nicht mit einem Defekt verbundenen) Sorte bzw. dessen
Auswirkungen durch Zufall quasi "live" zuzugucken.
Ein Cronjob, der alle 5 Minuten ein paar Dateien aus einer Datenbank
generiert, hat einmalig einen Output generiert, der sich in genau einem
Bit vom vorherigen unterschied, 5 Minuten später (nach dem nächsten
Lauf) war alles wieder zurück zum alten. An der Datenbank selbst hat
sich natürlich nachweislich in der fraglichen Zeit nichts geändert.
Derartige Fehler treten bei einem durchschnittlichen Rechner mit
Nicht-ECC-Speicher AFAIK inzwischen alle paar Tage auf, je nachdem
welche Zelle genau kippt, kann das von einem kompletten Non-Event bis
hin zu dauerhaft verfälschten Daten alles bedeuten. Auch Fehler, die
nach ein paar Stunden oder Tagen von alleine auf Nimmerwiedersehen
verschwinden sind da möglich, wenn z.B. ein Bit in der Cache-Kopie des
gcc-Binaries gekippt ist, wirkt sich das solange aus, bis die fragliche
Page irgendwann mal zufällig aus dem Cache geworfen und neu von der
Platte geladen wird (wenn der gcc häufig benutzt wird und der Rechner
durchläuft, kann das durchaus ein paar Tage dauern!).
Andreas
Hallo!
Andreas Schweigstill schrieb:> Leider lässt sich das Verhalten nicht reproduzieren. Es ist jedoch vor> mehreren Wochen und vor einigen Tagen definitiv aufgetreten.Andreas Ferber schrieb:> Ich hatte neulich das erste Mal das "Vergnügen", einem Bitkipper von der> sporadischen (also nicht mit einem Defekt verbundenen) Sorte bzw. dessen> Auswirkungen durch Zufall quasi "live" zuzugucken.
Ich habe weiterhin versucht, das von mir aufgeführte Problem zu
reproduzieren, aber das ist mir bislang nicht gelungen. Ich habe
mittlerweile sogar Backups meiner Arbeitskopie von Tagen zurückgespielt,
an denen ich dachte, dass dort der Fehler vorhanden gewesen sein konnte.
Nun habe ich jedoch noch ein programmiertes Gerät herumliegen, bei dem
der beschriebene Fehler vorliegt. Ich kann ggf. noch versuchen, sein
Flash auszulesen.
Ich kann jedoch definitiv ausschließen, dass der Fehler beim
Programmieren des ATtiny verursacht wurde, da er an einem Tag auch im
AVR-Simulator zu beobachten war.
Hmmm...
Andreas Ferber schrieb:> Ich hatte neulich das erste Mal das "Vergnügen", einem Bitkipper von der> sporadischen (also nicht mit einem Defekt verbundenen) Sorte bzw. dessen> Auswirkungen durch Zufall quasi "live" zuzugucken
Habe mir darüber noch nie wirklich Gedanken gemacht, aber bin neugierig:
Woher weißt du dass es nicht ein (zugegeben: ungewöhnlicher)
Softwarefehler war? Sind "Bitkipper" ernstzunehmende Probleme im
Mikrocontroller Bereich? Jemand da Erfahrungen ?
Falk Brunner schrieb:> @ Karl heinz Buchegger (kbuchegg) (Moderator)>>>sich da im Laufe der Zeit an Bugs im WinAVR offenbart haben ... lies mir>>ehrlich gesagt manchmal die Haare zu Berge stehen.>> Beispiele?
Ich finde jetzt dir entsprechenden Threads nicht mehr.
Aber gab es da nicht letztes Jahr mal irgendwas mit Floating Point?
Vom (ich glaube) PeDa kann ich mich erinnern, wurde berichtet, dass der
gcc HighByte und LowByte durcheinander geworfen hat.
Es waren schon ein paar Versionen dabei, die kurze Zeit später wegen (im
Grunde sogar einfachen) Bugs durch neue ersetzt wurden.
klaus schrieb:> Woher weißt du dass es nicht ein (zugegeben: ungewöhnlicher)> Softwarefehler war?
Zu 100% weiss ich es natürlich nicht, dazu sind heutige Systeme einfach
zu komplex. Aber zu 99%, (auch) wegen Occam's Razor.
Es war ein einzelnes Zeichen mitten in einem String falsch (und zwar ein
"e" (0x65) durch ein "a" (0x61) ersetzt, also ein Bit Unterschied), der
aus der Datenbank abgefragt und unverändert ausgegeben wird. Der Rest
des Strings war OK, ebenso alle anderen Datensätze davor und danach, die
in einer Schleife und damit alle vom gleichen Code ausgegeben werden.
Die Datenbank wurde wie gesagt definitiv nicht verändert (die letzte
Änderung war ein paar Tage vor dem Ereignis), das Script ist in Perl
geschrieben (sprich stray pointer oder buffer overflows bei der
Stringverarbeitung quasi ausgeschlossen), das Script läuft seit Jahren
ohne Änderung und ohne Probleme alle 5 Minuten, es trat nur ein einziges
Mal auf, und noch diverse andere Details, die alle zu dem Schluss
führten, dass ein solcher Softwarefehler derart obskur wäre, dass ein in
der Hardware gekipptes Bit die naheliegendere Erklärung ist.
Andreas
@ Karl heinz Buchegger (kbuchegg) (Moderator)
>> Beispiele?>Ich finde jetzt dir entsprechenden Threads nicht mehr.
Tja, und genau HIER gehts nämlich los. Hier trennt sich die Spreu vom
Weizen, Wissenschaft von Dummfang, Forensmalltalk von Substanz.
Entweder, man kann einen Fehler klar belegen und reproduzieren, oder es
bleibt bei einer lauen Vermutung.
In dubio pro reo.
Das Gleich gilt für Andreas Ferber (aferber). Solche "ach was, jetzt
find ich die Version nicht mehr, aber jetzt geht alles, alles komplex"
nützt niemandem was. Das ist Stammtischgeschwätz. Entweder das
reproduzierbare Problem, oder wenigsten der vermutlich fehlerhafte Code,
auf den Tisch oder Sendepause.
MFG
Falk
Falk Brunner schrieb:> Das Gleich gilt für Andreas Ferber (aferber). Solche "ach was, jetzt> find ich die Version nicht mehr, aber jetzt geht alles, alles komplex"> nützt niemandem was.
Das habe ich nicht geschrieben.
> Entweder das> reproduzierbare Problem, oder wenigsten der vermutlich fehlerhafte Code,
Das ist doch genau der Punkt. Der Fehler ist belegbar (die generierten
Dateien werden wenn sich etwas geändert hat in ein Subversion-Repository
eingecheckt), aber definitiv nicht reproduzierbar (der Fehler trat 5
Minuten vorher und 5 Minuten nachher bei unveränderten Inputdaten und
unverändertem System nicht auf). Und ja, ich weiss exakt mit welcher
Version des Scriptes das auftrat, die läuft nämlich bis heute immer noch
alle 5 Minuten fehlerfrei ;-)
Einen (obskuren) Fehler im Script selbst kann ich ausschliessen, bei
einem kurzen Perl-Script, das eine SQL-Abfrage abfeuert und das Ergebnis
formatiert ausgibt kann man nicht so wahnsinnig viel falsch machen, vor
allem nichts, was bei identischem Input einmalig zu einem einzelnen
geänderten Zeichen im Output führt. Bleiben theoretisch Perl, MySQL,
Subversion und das Linux, auf dem das ganze läuft, als mögliche Quellen
für einen richtig merkwürdigen Softwarefehler. Diese Millionen Zeilen
Code (deshalb "komplex") habe ich nicht genauer untersucht, deshalb
kann ich einen Softwarefehler eben nur zu 99% und nicht zu 100%
ausschliessen.
Dass sporadische Bitkipper bei DRAM vorkommen ist ein Fakt, es ist nur
ungewöhnlich, das mal so direkt zu sehen.
Andreas
Andreas Ferber schrieb:> Dass sporadische Bitkipper bei DRAM vorkommen ist ein Fakt
Naja, klassisch traten diese auf, wenn ein alpha-Teilchen einen
Speicherkondensator getroffen hat. Das kann nicht mehr passieren,
seit dRAMs nicht mehr in Keramikgehäusen sitzen, denn bereits 50 µm
Polymerschicht genügen, um herumfliegende alpha-Teilchen sicher
auszubremsen. Die Vergussmasse heutiger Gehäuse ist viel dicker.
Wenn heute also noch Bitkipper auftreten, dann deutet das eher auf
ein schlechtes Design der Schaltung, schlechte Abblockung etc. hin.
Jörg Wunsch schrieb:> Naja, klassisch traten diese auf, wenn ein alpha-Teilchen einen> Speicherkondensator getroffen hat. Das kann nicht mehr passieren,> seit dRAMs nicht mehr in Keramikgehäusen sitzen, denn bereits 50 µm> Polymerschicht genügen, um herumfliegende alpha-Teilchen sicher> auszubremsen. Die Vergussmasse heutiger Gehäuse ist viel dicker.
Stichwort C14. Die Gehäusemasse selbst ist Quelle von ionisierender
Strahlung, zwar Beta-Strahlung, aber auch die ist energiereich genug um
bei einem "Volltreffer" einen Speicherkondensator zu entladen. Ausserdem
können natürlich auch Alphastrahler in geringen Mengen bei der
Produktion ins Gehäusematerial gelangen.
Woher die Speicherfehler genau kommen ist hier aber auch erstmal egal.
Von Google gibt's ein Paper dazu, wo sie mal über 2,5 Jahre die
Speicherfehler auf ihren Systemen (bekanntlich eine gewaltige Menge)
gesammelt und statistisch ausgewertet haben, durchaus lesenswert:
http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf
Andreas
@ Andreas Ferber (aferber)
>Und ja, ich weiss exakt mit welcher>Version des Scriptes das auftrat, die läuft nämlich bis heute immer noch>alle 5 Minuten fehlerfrei ;-)
Dann poste den AVR Code und das Script. Es kann druchaus ein böser
sporadischer Fehler sein, welcher durch Race Conditions in unsauber
gehandhabten Interrupts auftritt. Stichwort atomar und volatil.
Das Bitkippen ist zwar eine einfache, meistens aber falsche Erklärung.
MFG
Falk
Falk Brunner schrieb:> Dann poste den AVR Code und das Script. Es kann druchaus ein böser> sporadischer Fehler sein, welcher durch Race Conditions in unsauber> gehandhabten Interrupts auftritt.
Wo schrieb ich, dass sich ein AVR auch nur im gleichen Raum befand, als
mein Fehler auftrat? Ich heisse zwar auch Andreas, aber der Nachname ist
anders als bei dem mit dem AVR-Problem ;-)
Noch einmal kurz: MySQL-Datenbank (unverändert), Perl-Script (ohne
Nebenläufigkeit etc., einfach gerade runter SQL-Abfrage -> Schleife mit
Ausgabe), Output einmalig verändert. Race Conditions ausgeschlossen, es
lief definitiv nichts anderes, was zu dem Zeitpunkt auf die Datenbank
zugegriffen hat.
Andreas
Falk Brunner schrieb:> @ Karl heinz Buchegger (kbuchegg) (Moderator)>>>> Beispiele?>>>Ich finde jetzt dir entsprechenden Threads nicht mehr.>> Tja, und genau HIER gehts nämlich los. Hier trennt sich die Spreu vom> Weizen, Wissenschaft von Dummfang, Forensmalltalk von Substanz.
Im Gcc Forum gibt es ein paar Threads, die letztendlich auf der
Gcc-Bugliste gelandet sind.
Beitrag "Bug in WinAVR oder liegts an mir?"Beitrag "GCC: code funktioniert bei -O, funktioniert nicht bei -Os"
Ich bin jetzt nur 1 Jahr zurückgegangen und hab sicherlich noch ein paar
andere Threads übersehen. Aber insbesondere der erste der genannten Bugs
ist einer, der nicht passieren darf.
Falk Brunner schrieb:> Das Bitkippen ist zwar eine einfache, meistens aber falsche Erklärung.
Prinzipiell gebe ich dir da BTW auch recht, und wenn der Fehler während
der Entwicklung aufgetreten wäre, hätte ich auch ein bisschen intensiver
nach anderen Ursachen gesucht.
Nur wenn bei einem seit Jahren problemlos laufenden, recht einfach
aufgebautem (Perl, MySQL, Linux an sich aussen vor) Stück Software
einmalig ein derartiger Fehler auftritt, kann es eben auch mal die
einfache Erklärung sein. Und wenn er in drei Jahren nochmal auftritt, so
what. An dem Ding hängen keine Menschenleben.
Andreas
