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.
ich glaube Codeoptimierung ist auch tabu, weil man nicht weiss, was genau wegoptimiert wird
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.
Es gibt da einen kleinen Unterschied zwischen deutscher Wertarbeit und Vertragsgestaltung nach dem Motto "TÜV am Tag der Prüfung ok".
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
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.