Tod durch Softwarefehler

Edzard Egberts wrote:

Beim GCC hatte ich Fall, dass die Optimierung das Programm zermurkst
hat.
Click to expand...

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...
 
Marc Santhoff wrote:
Joerg <invalid@invalid.invalid> schrieb:
Was Software angeht, z.B. den Standard RTCA/DO-178 besorgen und danach
arbeiten. Ich lebe fast nach solchen Standards, man gewoehnt sich
dran. Doch es gibt im Bereich KFZ-Elektronik (m.W.) nichts
vergleichbares, ausser Vorschriften einzelner Hersteller.

Ich hege wenig Hoffnung, dasss sich im Bereich Automotive in dieser
Hinsicht viel bessert. Ergo bevorzuge ich Vehikel mit sowenig
Elektronik wie moeglich.

https://de.wikipedia.org/wiki/MISRA-C
Click to expand...

MISRA-C funktioniert nicht.

http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2008-017.pdf

"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
 
Gerrit Heitsch wrote:
On 10/29/2013 05:04 PM, Thomas Stanka wrote:
Am Montag, 28. Oktober 2013 17:39:15 UTC+1 schrieb Frank Buss:
Marc Santhoff wrote:
Ich denke das beste wäre wohl, wenn sowohl Flash, als auch RAM per ECC
abgesichtert wäre und beim einem Fehler dort dann von der Hardware per

Wird man zwar im Regelfall auch bei Flash so machen, aber meines
Wissens ist die eigentliche Zelle nach dem Schreiben im Flash relativ
sicher gemessen am restlichen System,

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.
Click to expand...

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
 
Lutz Schulze wrote:
Am Tue, 29 Oct 2013 08:09:26 +0100 schrieb Edzard Egberts:
Beim GCC hatte ich Fall, dass die Optimierung das Programm zermurkst
hat.

Was ist da konkret passiert? Bei mir stellten sich in Betracht gezogene
'Compilerfehler' nach genauerer Untersuchung eigentlich immer wieder als
eigene Denkfehler heraus.
Click to expand...

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
 
Frank Buss wrote:
Wie kann man Stack Overflow Fehler bei so kritische Software übersehen?
In jeder besseren IDE, z.B. die CodeWarrior Reihe, bekommt man eine
automatisch generierte Analyse des Call-Trees angezeigt, mit Ausnutzung
des Stacks (kann der GCC glaube ich auch mit Zusatzprogrammen, die die
Intermediate-XML-Dateien auswerten).
Click to expand...

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
 
On 10/29/2013 08:13 PM, Stefan Reuther wrote:
(Aber Layer-8-Probleme
sind deutlich häufiger.)
Click to expand...

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

Gerrit
 
Am 29.10.2013 20:25, schrieb Gerrit Heitsch:
On 10/29/2013 08:13 PM, Stefan Reuther wrote:
(Aber Layer-8-Probleme
sind deutlich häufiger.)

Layer-9-Probleme sind auch nicht selten. ;)
Click to expand...

Du meinst den auf der Cloud?


CNR, Dieter
 
On 10/29/2013 08:31 PM, Dieter Wiedmann wrote:
Am 29.10.2013 20:25, schrieb Gerrit Heitsch:
On 10/29/2013 08:13 PM, Stefan Reuther wrote:
(Aber Layer-8-Probleme
sind deutlich häufiger.)

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

Du meinst den auf der Cloud?
Click to expand...

Nein... Layer-9 ist der Chef von Layer-8.

Gerrit
 
Stefan Reuther wrote:
Marc Santhoff wrote:
Joerg <invalid@invalid.invalid> schrieb:
Was Software angeht, z.B. den Standard RTCA/DO-178 besorgen und danach
arbeiten. Ich lebe fast nach solchen Standards, man gewoehnt sich
dran. Doch es gibt im Bereich KFZ-Elektronik (m.W.) nichts
vergleichbares, ausser Vorschriften einzelner Hersteller.

Ich hege wenig Hoffnung, dasss sich im Bereich Automotive in dieser
Hinsicht viel bessert. Ergo bevorzuge ich Vehikel mit sowenig
Elektronik wie moeglich.
https://de.wikipedia.org/wiki/MISRA-C

MISRA-C funktioniert nicht.

http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2008-017.pdf

"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 {}.
Click to expand...

Hoert sich aehnlich an wie ISO-9000. Wenn man sauber dokumentiert, wie
man eine Klippe runterfahren soll, das dann auch genau anhand diese
Dokumentes tut und unten in einem Feuerball zerschellt, dann ist die
Norm erfuellt.

--
Gruesse, Joerg

http://www.analogconsultants.com/
 
Am 29.10.2013 20:35, schrieb Gerrit Heitsch:
On 10/29/2013 08:31 PM, Dieter Wiedmann wrote:
Am 29.10.2013 20:25, schrieb Gerrit Heitsch:
On 10/29/2013 08:13 PM, Stefan Reuther wrote:
(Aber Layer-8-Probleme
sind deutlich häufiger.)

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

Du meinst den auf der Cloud?

Nein... Layer-9 ist der Chef von Layer-8.
Click to expand...

Klar, der auf der Cloud.


Gruß Dieter
 
Am 29.10.2013 20:48, schrieb Dieter Wiedmann:
Am 29.10.2013 20:35, schrieb Gerrit Heitsch:
On 10/29/2013 08:31 PM, Dieter Wiedmann wrote:
Am 29.10.2013 20:25, schrieb Gerrit Heitsch:
On 10/29/2013 08:13 PM, Stefan Reuther wrote:
(Aber Layer-8-Probleme
sind deutlich häufiger.)

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

Du meinst den auf der Cloud?

Nein... Layer-9 ist der Chef von Layer-8.

Klar, der auf der Cloud.
Click to expand...

Also, nach heutiger Logik, die NSA.

--
hdw
 
Joerg <invalid@invalid.invalid> wrote:

Scheinbar gibt es dort nichtmal in-house Standards fuer Design History
oder Verifizierung. Vermutlich nichtmal richtige Design Reviews. <grusel
Click to expand...

Ja, kommt einem alles ziemlich übel vor.


-ras

--

Ralph A. Schmid

http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/ http://www.kabuliyan.de/
 
Am 29.10.2013 21:03, schrieb horst-d.winzler:
Am 29.10.2013 20:48, schrieb Dieter Wiedmann:
Am 29.10.2013 20:35, schrieb Gerrit Heitsch:
On 10/29/2013 08:31 PM, Dieter Wiedmann wrote:
Am 29.10.2013 20:25, schrieb Gerrit Heitsch:
On 10/29/2013 08:13 PM, Stefan Reuther wrote:
(Aber Layer-8-Probleme
sind deutlich häufiger.)

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

Du meinst den auf der Cloud?

Nein... Layer-9 ist der Chef von Layer-8.

Klar, der auf der Cloud.


Also, nach heutiger Logik, die NSA.
Click to expand...

Nee, aber die klaut.


Gruß Dieter
 
Joerg wrote:
Stefan Reuther wrote:
Marc Santhoff wrote:
Joerg <invalid@invalid.invalid> schrieb:
Was Software angeht, z.B. den Standard RTCA/DO-178 besorgen und danach
arbeiten. Ich lebe fast nach solchen Standards, man gewoehnt sich
dran. Doch es gibt im Bereich KFZ-Elektronik (m.W.) nichts
vergleichbares, ausser Vorschriften einzelner Hersteller.

Ich hege wenig Hoffnung, dasss sich im Bereich Automotive in dieser
Hinsicht viel bessert. Ergo bevorzuge ich Vehikel mit sowenig
Elektronik wie moeglich.
https://de.wikipedia.org/wiki/MISRA-C

MISRA-C funktioniert nicht.

http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2008-017.pdf

"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 {}.


Hoert sich aehnlich an wie ISO-9000. Wenn man sauber dokumentiert, wie
man eine Klippe runterfahren soll, das dann auch genau anhand diese
Dokumentes tut und unten in einem Feuerball zerschellt, dann ist die
Norm erfuellt.
Click to expand...

Nun ja, ist eben nur eine Menge von Regeln, die hauptsächlich das
Programmieren mit C sicherer machen soll, da es einem die Sprache von
Haus aus ziemlich leicht macht Fehler einzubauen.

Andere Sprachen sind aber auch nicht perfekt. Immer wieder nett zu lesen
und viel wahres dran:

http://www.m5p.com/~pravn/foot.html

Ich denke ein Schritt in die richtige Richtung wären schon Sprachen und
Tools, mit denen man formal beweisen kann, daß ein Programm eine
Spezifikation erfüllt, wie bei Spark ADA. Sowas erhöht bestimmt auch die
Wahrscheinlichkeit bessere Programmierer zu bekommen, die vielleicht
auch eher Ungereimtheiten in der Spezifikation entdecken, da schlechte
Programmierer, die MISRA-C problemlos erfüllen können, sowas erst gar
nicht verstehen :)

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
 
Am 29.10.2013 14:57, schrieb Joerg:

Klar. Bei uns war es ein Triebwerk (von zweien) einer Boeing 767,
das ueber dem Atlantik graetschte. Dann muss das andere bis zum
Festland reichen, und das tat es auch. Selbst wenn die normale
Reiseflughoehe nicht gehalten werden konnte.
Click to expand...
"...versuchen das Festland zu erreichen. Sollte uns dies nicht gelingen
wird die Sicherheitsgebühr selbstverständlich zurückerstattet."



Butzo
 
On Mon, 28 Oct 2013 09:25:58 -0700, Joerg wrote:

Man muss lediglich bei den Flugzeugbauern nachsehen. Viele kritische
Systeme muessen redundant vorhanden sein, z.B. dreifach mit
Mehrheitsentscheidung. Patzt einer der Computer, muss gemeldet und
gelandet werden. Ganz heisse Sachen sind fuenffach vorhanden, weil man
auf Reiseflughoehe schlecht anhalten und auf den ADAC Abschleppdienst
warten kann. Hier einige Grundzuege am Beispiel Airbus:

http://exoaviation.webs.com/pdf_files/Airbus%20flight%20control%20system.pdf

Zitat "Therefore, quintuple redundancy is supported".

Was Software angeht, z.B. den Standard RTCA/DO-178 besorgen und danach
arbeiten. Ich lebe fast nach solchen Standards, man gewoehnt sich dran.
Doch es gibt im Bereich KFZ-Elektronik (m.W.) nichts vergleichbares,
ausser Vorschriften einzelner Hersteller.
Click to expand...

Natuerlich gibt es automotive Vorgaben und Standards nach denen
entwickelt werden sollte/muss (da mittlerweile alle Kunden selbige
voraussetzen):

Fuer SW:
http://de.wikipedia.org/wiki/Automotive_SPICE

http://de.wikipedia.org/wiki/FMEA (VDA und AIAG)
http://de.wikipedia.org/wiki/Fehlerbaumanalyse

und seit 2011 http://de.wikipedia.org/wiki/ISO_26262

(Die englischen Pendants sind ausfuehrlicher)

Natuerlich sind die Kundenerwartungen und Terminplaene fuer eine
serioese Durchfuehrung der obigen Massnahmen nicht immer
zweckdienlich. Aber es wird fuer einen Supplier recht schnell ziemlich
eng wenn er sich nicht an diese Vorgaben haelt.

Ich hege wenig Hoffnung, dasss sich im Bereich Automotive in dieser
Hinsicht viel bessert. Ergo bevorzuge ich Vehikel mit sowenig Elektronik
wie moeglich.
Click to expand...

Keine Angst, es gibt Bestrebungen einzelne ECU's in Zukunft zu
clustern um die Anzahl zu reduzieren. Mittels Autosar gibt es auch
bereits entsprechende Ansaetze zur Interoperabilitaet.

Gruss

Fritz
 
On Tue, 29 Oct 2013 12:43:10 -0700, Joerg wrote:
Hoert sich aehnlich an wie ISO-9000.
Click to expand...

Wieso moechte man ISO 9000 implementieren (Grundlagen und Begriffe)?
Oder meinst Du ISO 9001:2008?

Wenn man sauber dokumentiert, wie
man eine Klippe runterfahren soll, das dann auch genau anhand diese
Dokumentes tut und unten in einem Feuerball zerschellt, dann ist die
Norm erfuellt.
Click to expand...

Wenn man die ISO 9001:2008 nicht begriffen hat dann sollte man auch
keinen Mehrwert erwarten. Leider gab und gibt es immer wieder Firmen
die meinen ein bisschen Prozesse dokumentieren erfuellt die Norm.
Wegen solchen Komplettausfaellen sollte man allerdings nicht die Norm
kritisieren. In der letzten Inkarnation von 2008 kommt sie recht
pragmatisch daher und eine Firma profitiert durchaus wenn sie sich
daran orientiert. Sehr viele Fragestellungen aus der Norm sind
durchaus eine Ueberlegung wert sobald man eine gewisse Azahl an
Mitarbeitern hat.
BTW, Automotive hat sogar noch eine verschaerfte Version, die
ISO/TS16949.

Gruss

Fritz
 
Am 29.10.2013 21:30, schrieb Dieter Wiedmann:
Am 29.10.2013 21:03, schrieb horst-d.winzler:
Am 29.10.2013 20:48, schrieb Dieter Wiedmann:
Am 29.10.2013 20:35, schrieb Gerrit Heitsch:
On 10/29/2013 08:31 PM, Dieter Wiedmann wrote:
Am 29.10.2013 20:25, schrieb Gerrit Heitsch:
On 10/29/2013 08:13 PM, Stefan Reuther wrote:
(Aber Layer-8-Probleme
sind deutlich häufiger.)

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

Du meinst den auf der Cloud?

Nein... Layer-9 ist der Chef von Layer-8.

Klar, der auf der Cloud.


Also, nach heutiger Logik, die NSA.

Nee, aber die klaut.
Click to expand...

Faktisch sind sie Diebe, die obendrein Vertrauen mißbrauchen. Keine
Frage. Da es sich aber um eine US BehĂśrde handelt und die USA nunmal
unsere Freunde sind, erweisen sie uns einen Freundschaftsdienst, wenn
sie Mutti abhĂśren. Mutti teilt doch ihrem Staatsvolk nicht mit, wenn sie
weider mal Lobbyarbeit verrichtet. Also alles im Dienst des Vetrauens.

--
mfg hdw
 
Also schrieb Hartmut Kraus:

Verschiedene CPUs, verschiedene Teams, sogar unterschiedliche
Computersprachen sollen eingesetzt worden sein.

Ja, kenne ich von Schmersal/Wuppertal. Die machen Sicherheitssteuerungen
u.a. für Aufzüge und Pressen. Da wurden wirklich 3 verschiedene uC,
Programmiersprachen und sowieso Teams genommen.
Die müssen wohl auch die Steuerung für den neuen Aufzug in unserem
Ärztehaus gebaut haben. Versuche nur mal als "Unkundiger", damit vom
Erdgeschoss in den 2. Stock zu kommen und da die Tür wieder
aufzukriegen. ;)
Click to expand...

Ich würde auch zu gerne mal die SPS unseres Aufzugs hier in die Finger
kriegen - um dann die Logik einzuspielen, die ich damals[tm] im Praktikum
während des Studiums programmiert habe. Die war komplett mit
Richtungspriorität und Langsamfahrstufe beim "Landen". Unser Lift hier
akzeptiert immer nur einen einzigen Ziel-Tastendruck vom inneren Tableau,
weitere Tastendrücke werden nicht mehr entgegengenommen. Außerdem ist die
Tür-Zu-Steuerung ziemlich dämlich. Nach dem ersten Öffnen wartet die Tür 5
s (oder so), aber sobald die Lichtschranke einmal unterbrochen war, geht
die Tür praktisch sofort zu (geschätzte 0,5 s). Wenn da noch einer
hinterherkommt, muss er schnell sein...

Ansgar

--
*** Musik! ***
 
Joerg schrieb:

>Stefan Reuther wrote:

[...]

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 {}.

Hoert sich aehnlich an wie ISO-9000. Wenn man sauber dokumentiert, wie
man eine Klippe runterfahren soll, das dann auch genau anhand diese
Dokumentes tut und unten in einem Feuerball zerschellt, dann ist die
Norm erfuellt.
Click to expand...

ich glaube, das hast Du nicht richtig verstanden. Stefan beschreibt
m.E. Situationen, wo Programmierer _wegen der Tools_ Fehler einbauen,
auf die sie ohne die Tools nie gekommen wären.

Servus

Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top