Tod durch Softwarefehler

Am 29.10.2013 08:30, schrieb Gerrit Heitsch:

Ausserdem kann die CPU später kaputt gehen, da treten ggf. die unmöglichsten Effekte auf die die Software wieder abschiesst.

Bernd

--
Meine Glaskugel ist mir leider unvorhersehbarerweise vom Balkon gefallen. 
P.Liedermann in defa

Ein Bekannter hatte mal mit Steuergeräteentwicklung zu tun, so als Projektmanager, der daherkommt, wenn die Kacke am Dampfen ist.

Er wußte durchaus von Begebenheitenm zu berichten, die bedenklich stimmen. Zwei Teams hocken auf dem selben Flur, entwickeln jeweils ein Steuergerät, sehen sich täglich auf dem Flur und in der Kantine, und paar Tage vor Projektende werden die zwei Geräte erstmalig verbunden - nichts funktioniert. Hat eines der Teams die specs der Telegramme anders aufgefaßt als das andere Team, großer Streit, großes Chaos, Kunde not amused, mein Bekannter muß mit ran und vermittelnd wirken, man raucht die Friedenspfeife, strickt wild in Nachtschichten herum, und zum Tag x funktiniert der Krempel. Irgendwie halt. Nicht wirklich geprüft, nicht wirklich erprobt, aber der Kunde ist zufrieden, Hauptsache, das Zeug läuft, die Dinger kommen in die Prototypen, und wenig später in Serie. Ohne daß nochmal einer nachgebessert hätte, den code aufgeräumt und verifiziert - warum auch, läuft ja.

Geht ja offenbar fast immer dennoch irgendwie gut, aber ein Gschmäckle bleibt da schon, zumal solche Begebenheiten nict die Ausnahme sind. Und das waren große, bekannte Namen, deutsch und nordeuropäisch...

-ras

--

Ralph A. Schmid 

http://www.schmid.xxx/ http://www.db0fue.de/ 
http://www.bclog.de/ http://www.kabuliyan.de/

Martin Schoenbeck schrieb:

Um mir eine genauere Definitionen des Begriffs "Fehler" zu sparen, nenne ich das einfach mal "Ereignis". Damals habe ich gelernt, dass solche Ereignisse durch Optimierungen über Stufe 02 verursacht werden. Seitdem liefere ich mit Stufe 02 aus, was mir auch als völlig ausreichend erscheint - Software, die sowieso schon klein und schnell genug ist, wird damit möglicherweise robuster, was den Betrieb auf unterschiedlichen Systemen angeht.

Den Link zum Artikel, im dem allgemein empfohlen wird, diese Optimierungen möglichst zu vermeiden, finde ich aber nicht mehr - wenn es jemand wirklich noch genauer wissen muss, sollte der nach de.comp.os.unix.programmer fuppen.

Ich nehme mal an, die CPU-Hersteller tun jetzt schon was geht, ganz in ihrem eigenen Interesse. Ausserdem kenne sie die problematischen Pfade und passen auf die genau auf. Trotzdem sind heutige CPUs leider nicht

100% verifizierbar und eine neue Architektur dürfte sich nicht durchsetzen können. x86/x64 funktioniert gut genug.

Gerrit

Am 29.10.2013 14:27 schrieb Gerrit Heitsch:

Das ist auch der Grund, warum keine Anstrengungen bzgl. verifizierbarer Software unternommen werden: Es funktioniert gut genug, und für die Fälle, wo es das nicht tut, gibt es Versicherungen.

Es funktioniert aber auch schlecht genug, so daß man den Leuten dauernd was neues verkaufen kann. Und obendrein müßte Software zur automatischen Verifikation quelloffen sein und das geht ja nun gar nicht.

Ich will mich dennoch nicht solchen Marktzwängen unterwerfen müssen.

Hanno

Scheinbar gibt es dort nichtmal in-house Standards fuer Design History oder Verifizierung. Vermutlich nichtmal richtige Design Reviews.

Inzwischen kostet es aber einen Preis, denn das hat sich in der (hiesigen) Pannenstatistik gezeigt. Wer ein solides Auto braucht, sollte ein japanisches kaufen. Weiss hier jedes Kind. Wer "was darstellen" moechte, muss natuerlich eine europaeische Nobelkarosse haben. Doch auch da broeselt es, Leute desertieren zu Lexus oder Infinity. Kunden, die blieben, verlangen jetzt ellenlange Rundum-Garantien, inklusive Leihwagen.

--
Gruesse, Joerg 

http://www.analogconsultants.com/

Schön... Aber der Zug dürfte abgefahren sein. Oder wo bleibt das komplett verifizierbare OS mit ähnlichem Funktionsumfang wie es heute erwartet wird?

Gerrit

Am 29.10.2013 15:19 schrieb Gerrit Heitsch:

Ich erwarte keinen Funktionsumfang wie heute. Wenn du aber (innerhalb der Spec) beliebigen Code darauf ausführen kannst, dann kannst du auch beliebige Dinge damit machen.

Hanno

Also schrieb Heiko Nocon:

Man macht einfach Zwei-Bit-Redundanz, d.h. man korrigiert 1-Bit-Fehler und erkennt 2-Bit-Fehler. Für kritische Anwendungen (Bahn bspw.) ist auch noch höhere Redundanz gefordert. BTDT...

Korrigieren. Und dann die Kiste geordnet in einen definierten Failsafe-Modus bringen, wie auch immer der im Einzelfall aussieht (automatisches sanftes Bremsen, Motor aus, gefährliche Bewegung eines Anbauteils vulgo Baggerarms abstoppen, whatever...).

Ansgar

--
*** Musik! ***

Wird man zwar im Regelfall auch bei Flash so machen, aber meines Wissens is t die eigentliche Zelle nach dem Schreiben im Flash relativ sicher gemessen am restlichen System, was üblicherwiese "kippt" sind die Daten ausserhal b der Zelle z.b. beim Auslesen oder im Prozessor-Cache/Registerbank/Pipelin e/... oder aber die Daten während des Schreibzugriffs.

Hängt vom Flash ab. Aktuelles NAND-Flash (in SSDs benutzt) ist ohne ECC unbenutzbar weil zuviele Fehler drin sind. Die kleinen Flash, die man meist für Firmware nimmt sind problemloser.

Gerrit

Das lässt uns hoffen. ;)

ECHTE Fehler bei der Optimierung sind ziemlich selten, kommen aber tatsächlich schonmal vor.

Daß ein Programm nicht mehr funktioniert, wenn die Optimierung (vor allem auf hohen Stufen) eingeschaltet wird, kommt hingegen sehr viel häufiger vor.

Der Grund für die Differenz der beiden Mengen ist das Hauptproblem 25cm vor dem Monitor...

MISRA-C funktioniert nicht.

"Second, we observed a negative correlation between MISRA rule violations and observed faults. In addition, 29 out of 72 rules had a zero true positive rate. Taken together with Adams? observation that all modifications have a non-zero probability of introducing a fault [1], this makes it possible that adherence to the MISRA standard as a whole would have made the software less reliable."

Wenn ich jedes mal eine Kerbe in meinen Schreibtisch schnitzen würde, wenn ich in der Software einen Fehler finde, der entstanden ist, weil ein Analysetool gesagt hat "du musst hier XX machen", und der Entwickler dann gedankenlos einfach "XX" gemacht hat, bräuchte ich bald einen neuen.

MISRA-C ist so gedacht, dass man jede Regel brechen darf, wenn man es begründen kann. Der Entwickler, der in der Lage ist, eine solche Begründung zu formulieren, braucht aber keine Tool-Hilfe, um robusten Code zu entwickeln. All die anderen machen einfach die Violations raus und bauen damit Fehler ein. Und dann bleibt an halbwegs unstrittigem nur die Position der {}.

Stefan

NAND-Flash ist aber von Anfang an so spezifiziert. Den gab's nie ohne Bitfehlergarantie.

Bei NOR-Flash kommen wir erst langsam dahin. Mir hat zumindest schon ein Flash-Hersteller NOR-Flash angeboten "plug-in replacement für das Vorgängermodell", Fußnote "naja, bitweise schreiben solltest du nicht mehr, schreib mal lieber immer in 16-Byte-Brocken, sonst klappt das mit dem internen ECC nicht mehr".

Stefan

Compilerfehler gibt's genug. Wenn ich mich nicht verzählt habe, hab ich eine Handvoll bei Green Hills, eine Handvoll bei TI, eine Handvoll bei Borland und ein oder zwei bei gcc und MSVC erlebt.

Die grünen Zwerge haben mir z.B. mal in bool b = false; while (1) { if (!b) { bla(); b = true; } if (blub()) { b = false; } } die boolesche Variable wegoptimiert, da der Optimierer zuerst das erste if aus der Schleife gezogen hat, um die Bedingung wegzuoptimieren, um dann festzustellen, dass ja niemand mehr die Variable liest. In anderen Worten: ja, Compilerfehler gibt's tatsächlich. (Aber Layer-8-Probleme sind deutlich häufiger.)

Stefan

Diese Tools machen typischerweise an indirekten Aufrufen Schluss: Funktionspointer oder Klassen mit virtuellen Methoden. Und je größer die Software, desto höher die Wahrscheinlichkeit, dass sowas beteiligt ist.

Stefan

Layer-9-Probleme sind auch nicht selten. ;)

Gerrit

Du meinst den auf der Cloud?

CNR, Dieter