Tod durch Softwarefehler

[Klaus Bahner]

On 28-10-2013 16:50, Frank Buss wrote:

Durch fehlerhafte Software in der Firmware von Toyota ist mindestens
eine Person gestorben:

[snip]

Bevor wir uns hier in wilde Diskussionen Bit-Flips u.a. vertiefen:

Mir ist nach dem was ich gelesen habe nicht klar, ob es sich bei den
Aussagen der Experten um *moegliche* Fehlerszenarioes (also letztendlich
Spekulation) oder *tatsaechlich* nachgewiesenes Versagen handelt.

Der NASA-Bericht spekuliert ja auch darueber, dass Tin-Whisker am
Potentiometer eine Fehlerquelle sein koennten, wohlweisslich ohne zu
sagen, dass das die Ursache war.

Rein technich halte ich es fuer interessant zu diskutieren ob so ein
System wirklich ein mission-critical ist wie z.B. bei einem Flugzeug.
Man sollte doch annehmen koennen, dass eine Vollgassituation vom Fahrer
kontrollierbar ist - z.B. durch auskupplen/N-waehlen, Zuendung
abschalten oder bremsen (alos letztlich 3 redundante Overrides)

Wenn man sagt, dass das mission-critical ist, warum war es dan
jahrzehntelang OK die Rueckstellung von Drosselklappen durch *eine*
Feder zu gewaehrleisten. Die Feder konnte brechen, wenn man zum Beispiel
das Gaspedal durchtrat und blieb dann im Vollgasstellung stehen (selbst
erlebt).

gruebelt
Klaus

 

[Frank Buss]

Klaus Bahner wrote:

On 28-10-2013 16:50, Frank Buss wrote:
Durch fehlerhafte Software in der Firmware von Toyota ist mindestens
eine Person gestorben:

[snip]

Bevor wir uns hier in wilde Diskussionen Bit-Flips u.a. vertiefen:

Mir ist nach dem was ich gelesen habe nicht klar, ob es sich bei den
Aussagen der Experten um *moegliche* Fehlerszenarioes (also letztendlich
Spekulation) oder *tatsaechlich* nachgewiesenes Versagen handelt.

Das war mir auch nicht ganz klar. Aber auf Seite zwei wird auf diesen
Artikel verwiesen:

http://www.huffingtonpost.com/2012/12/26/toyota-settlement_n_2366720.html

Scheint also ein häufigeres Problem zu sein. Daher auch meine Vermutung,
daß es ein Softwareproblem war und nichts mit Bit-Flips zu tun hat. Wenn
ein Stack Overflow unter bestimmten Umständen auftritt und z.B. lokale
Variablen durch eine Return-Adresse überschrieben werden, dann würde
derselbe Fehler immer wieder auftreten.

Fragt sich nur, soll man jetzt keine Toyota Autos mehr kaufen, oder
gerade deswegen, weil die Firma hoffentlich daraus gelernt hat und
andere Hersteller noch unendeckte Fehler haben?

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

 

[Marc Santhoff]

Joerg <invalid@invalid.invalid> schrieb:

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


http://www.dspace.de/ftp/papers/dspace_El25_0312_d_f28.pdf

Zitat "Damit ist die Zielgruppe, auf welche sich der Standard bezieht,
recht klar definiert: der Mensch als Software-Entwickler"

Du zitierst aus einem Artikel, der einen Standard, den Du nicht kennst,
kritisiert. Mit unabhängiger Meinungsbildung hat das nichts mehr zu tun.

Das ist wohl ziemlich daneben. Es kommt nicht ein einziges Mal das
^^^^ Genau, Du rätst ohne Wissen.

> Wort "Ausfall" vor.

Wundert mich nicht, ist ja auch ein Artikel, der sich mit der Anwendung
des Standards bezieht. Lies den Standard oder laß es.

Du schriebst, Du hättest wenig Hoffung ...
Da lagst Du falsch.

Ich weiß ja, daß auf der anderen Seite des Teichs das Gras vieeel
grüner ist, aber das ist keine Diskussionsgrundlage.

Marc

 

[Michael Eggert]

Joerg <invalid@invalid.invalid> wrote:

Moin!

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.

Laufen da auf 5 unterschiedlichen CPUs 5 Programme von 5 Entwickler-
teams, die mit 5 Compilern übersetzt wurden?

Schließlich dürften 5 identische Systeme bei identischen Eingangs-
variablen auch alle einstimmig zur gleichen Zeit nen Stack overflow
produzieren.

Gruß,
Michael.

 

[Gerrit Heitsch]

On 10/28/2013 07:42 PM, Michael Eggert wrote:

Joerg <invalid@invalid.invalid> wrote:

Moin!

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.

Laufen da auf 5 unterschiedlichen CPUs 5 Programme von 5 Entwickler-
teams, die mit 5 Compilern übersetzt wurden?

Schließlich dürften 5 identische Systeme bei identischen Eingangs-
variablen auch alle einstimmig zur gleichen Zeit nen Stack overflow
produzieren.

Wobei schon 2 verschiedene CPU-Architekturen sich unterschiedlich
verhalten dürften.

Gerrit

 

[Frank Buss]

Michael Eggert wrote:

Laufen da auf 5 unterschiedlichen CPUs 5 Programme von 5 Entwickler-
teams, die mit 5 Compilern übersetzt wurden?

Ja, siehe die von Jörg zitierte Powerpoint-Präsentation:

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

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

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

 

[Klaus Bahner]

On 28-10-2013 19:24, Frank Buss wrote:

Klaus Bahner wrote:
On 28-10-2013 16:50, Frank Buss wrote:
Durch fehlerhafte Software in der Firmware von Toyota ist mindestens
eine Person gestorben:

[snip]

Bevor wir uns hier in wilde Diskussionen Bit-Flips u.a. vertiefen:

Mir ist nach dem was ich gelesen habe nicht klar, ob es sich bei den
Aussagen der Experten um *moegliche* Fehlerszenarioes (also letztendlich
Spekulation) oder *tatsaechlich* nachgewiesenes Versagen handelt.

Das war mir auch nicht ganz klar. Aber auf Seite zwei wird auf diesen
Artikel verwiesen:

http://www.huffingtonpost.com/2012/12/26/toyota-settlement_n_2366720.html

Scheint also ein häufigeres Problem zu sein. Daher auch meine Vermutung,

Nicht unbedingt. Dass Toyota Vergleiche eingegangen ist, bedeutet nicht
zwingend, dass das ein haeufiges Problem ist. Das bedeutet erst mal nur,
dass ca. 100 Leute *behaupten* sie haetten das Problem gehabt. Es kann
auch eine oekonomische Ueberlegung Toyotas sein. Die Vergleichssumme
kann deutlich geringer ausfallen als mit einer gewissen
Wahrscheinlichkeit (US-Rechtssystem) in so und soviel Prozent der Faelle
hoehere Summen zahlen zu muessen :-(

Klaus

 

[Joerg]

Marc Santhoff wrote:

Joerg <invalid@invalid.invalid> schrieb:

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

http://www.dspace.de/ftp/papers/dspace_El25_0312_d_f28.pdf

Zitat "Damit ist die Zielgruppe, auf welche sich der Standard bezieht,
recht klar definiert: der Mensch als Software-Entwickler"

Du zitierst aus einem Artikel, der einen Standard, den Du nicht kennst,
kritisiert. Mit unabhängiger Meinungsbildung hat das nichts mehr zu tun.

Das ist wohl ziemlich daneben. Es kommt nicht ein einziges Mal das
^^^^ Genau, Du rätst ohne Wissen.

Wort "Ausfall" vor.

Wundert mich nicht, ist ja auch ein Artikel, der sich mit der Anwendung
des Standards bezieht. Lies den Standard oder laß es.

Ich gehe davon aus, dass Thomas Thomsen (der Autor) weiss, wovon er
schreibt.

Du schriebst, Du hättest wenig Hoffung ...
Da lagst Du falsch.

Noe. Den Standard gibt es seit 1998 und verbessert hat sich seitdem ... nix.

Ich weiß ja, daß auf der anderen Seite des Teichs das Gras vieeel
grüner ist, aber das ist keine Diskussionsgrundlage.

Ist nicht gruener. KFZ-Elektronik ist hier ebenfalls schlecht. Man muss
noch einen Ozean weiter, da ist sie besser.

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Hartmut Kraus]

Am 28.10.2013 16:50, schrieb Frank Buss:

Durch fehlerhafte Software in der Firmware von Toyota ist mindestens
eine Person gestorben:

http://www.eetimes.com/document.asp?doc_id=1319903
(Cookies ausschalten, wenn man alle drei Seiten ohne Anmeldung lesen will)

Ich habe zwar nicht den 800-Seiten Bericht gelesen (falls der überhaupt
öffentlich zugänglich ist), aber der Titel des Artikels ist etwas
missverständlich, da ich es für unwahrscheinlich halte, daß der Unfall
durch einen Bit-Flip zustande kam, sondern eher weil in der Software
tatsächlich Stack Overflow und Race-Condition Fehler waren.

Wie kann man Stack Overflow Fehler bei so kritische Software übersehen?

Indem man die Software nicht genügend austestet, das kommt doch alle
Tage vor. Je komplexer das Programm, um so mehr Fehlermöglichkeiten.

 

[Frank Buss]

Hartmut Kraus wrote:

Am 28.10.2013 16:50, schrieb Frank Buss:
Durch fehlerhafte Software in der Firmware von Toyota ist mindestens
eine Person gestorben:

http://www.eetimes.com/document.asp?doc_id=1319903
(Cookies ausschalten, wenn man alle drei Seiten ohne Anmeldung lesen
will)

Ich habe zwar nicht den 800-Seiten Bericht gelesen (falls der überhaupt
öffentlich zugänglich ist), aber der Titel des Artikels ist etwas
missverständlich, da ich es für unwahrscheinlich halte, daß der Unfall
durch einen Bit-Flip zustande kam, sondern eher weil in der Software
tatsächlich Stack Overflow und Race-Condition Fehler waren.

Wie kann man Stack Overflow Fehler bei so kritische Software übersehen?
Indem man die Software nicht genügend austestet, das kommt doch alle
Tage vor. Je komplexer das Programm, um so mehr Fehlermöglichkeiten.

Durch testen findet man Stack Overflow Fehler nicht sicher, besonders
nicht in Multithreaded Programmen wie es scheinbar hier der Fall war.

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

 

[Joerg]

Frank Buss wrote:

Michael Eggert wrote:
Laufen da auf 5 unterschiedlichen CPUs 5 Programme von 5 Entwickler-
teams, die mit 5 Compilern übersetzt wurden?

Ja, siehe die von Jörg zitierte Powerpoint-Präsentation:

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

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

Dabei sollten auch intensive Design Reviews laufen und man darf
letztendlich ein System nicht auf den Glitch eines von dreien oder fuenf
Signalisierungssystemen reagieren lassen. Wenn doch, dann kann es boese
ausgehen wie hier:

http://www.atsb.gov.au/media/3532398/ao2008070.pdf

(File Groesse ueber 5MB)

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Gerrit Heitsch]

On 10/28/2013 08:52 PM, Hartmut Kraus wrote:

Am 28.10.2013 16:50, schrieb Frank Buss:
Durch fehlerhafte Software in der Firmware von Toyota ist mindestens
eine Person gestorben:

http://www.eetimes.com/document.asp?doc_id=1319903
(Cookies ausschalten, wenn man alle drei Seiten ohne Anmeldung lesen
will)

Ich habe zwar nicht den 800-Seiten Bericht gelesen (falls der überhaupt
öffentlich zugänglich ist), aber der Titel des Artikels ist etwas
missverständlich, da ich es für unwahrscheinlich halte, daß der Unfall
durch einen Bit-Flip zustande kam, sondern eher weil in der Software
tatsächlich Stack Overflow und Race-Condition Fehler waren.

Wie kann man Stack Overflow Fehler bei so kritische Software übersehen?
Indem man die Software nicht genügend austestet, das kommt doch alle
Tage vor. Je komplexer das Programm, um so mehr Fehlermöglichkeiten.

Kein nicht-triviales Programm kann zu 100% verifiziert oder getestet
werden. Man kann nur versuchen möglichst viel von dem, was von der
Realität vorkommen kann mit den Tests abzudecken.

Und jedesmal wenn eine Konfiguration an die man nicht dachte im realen
Einsatz Fehler zeigt hat man wieder was dazugelernt und erweitert seine
Testsuite hoffentlich entsprechend.

Gerrit

 

[Hanno Foest]

Am 28.10.2013 19:24, schrieb Frank Buss:

Mir ist nach dem was ich gelesen habe nicht klar, ob es sich bei den
Aussagen der Experten um *moegliche* Fehlerszenarioes (also letztendlich
Spekulation) oder *tatsaechlich* nachgewiesenes Versagen handelt.

Das war mir auch nicht ganz klar. Aber auf Seite zwei wird auf diesen
Artikel verwiesen:

http://www.huffingtonpost.com/2012/12/26/toyota-settlement_n_2366720.html

Scheint also ein häufigeres Problem zu sein. Daher auch meine Vermutung,
daß es ein Softwareproblem war und nichts mit Bit-Flips zu tun hat.

Also 2010 hat die Verkehrssicherheitsbehörde NHTSA noch behauptet, das
seien keine Elektronikprobleme:

http://www.berliner-zeitung.de/archiv/elektronik-probleme-in-keinem-fall-festgestellt-us-behoerde-entlastet-toyota-nach-unfallserie,10810590,10735850.html

Aber das Problem ist nicht neu. Ein SPIEGEL-Artikel von 1986:

http://www.spiegel.de/spiegel/print/d-13518910.html

Damals hat es Audi getroffen - ist wohl lediglich eine Frage, um welchen
Sündenbock die öffentliche Meinung gerade gravitiert:

"Das US-Verkehrsministerium erklärte zwar sofort, daß ihm solche Fälle
ungewollten Beschleunigens nicht nur von Wagen des deutschen Herstellers
bekannt seien. Ihre Techniker untersuchten auch Automatik-Modelle von
General Motors, Ford, American Motors, Nissan und Toyota. Doch nach der
Fernsehsendung Mitte März, in der nur Fahrzeuge aus Ingolstadt zu sehen
waren, bekam Fischer das rapide gesunkene Vertrauen schnell zu spüren."

Interessanterweise sind mir diese Probleme nur aus den USA bekannt (wenn
man mal von diesem

http://www.spiegel.de/auto/aktuell/eine-stunde-lang-vollgas-angst-meines-lebens-a-321452.html

Fall absieht, dessen Umstände allerdings recht seltsam sind), so daß wir
uns anno 1986 recht einig waren, daß die Amis lediglich zu doof zum
Autofahren sind. Nach Occam ist das zumindest die wahrscheinlichere
Theorie, verglichen mit der, daß Autos, die in die USA exportiert
werden, plötzliche Anfälle unkontrollierter Beschleunigung erleiden.

Hanno

 

[Hanno Foest]

Am 28.10.2013 21:06, schrieb Gerrit Heitsch:

Kein nicht-triviales Programm kann zu 100% verifiziert oder getestet
werden.

Das ist nicht richtig. Man kann das automatisieren. Und angesichts des
grauenhaften Zustands der Computersicherheit bleibt uns vielleicht auch
nichts andere übrig.

http://media.ccc.de/ftp/pub/pub/congress/27c3/mp4-h264-HQ/27c3-4123-en-defense_is_not_dead.mp4

Ich finde, dieser Ansatz klingt sehr vielversprechend.

Hanno

 

[Gerrit Heitsch]

On 10/28/2013 09:28 PM, Hanno Foest wrote:

Am 28.10.2013 21:06, schrieb Gerrit Heitsch:

Kein nicht-triviales Programm kann zu 100% verifiziert oder getestet
werden.

Das ist nicht richtig. Man kann das automatisieren.

Ja, man kann Tests und Suche nach den üblichen Verdächtgen wie buffer
overruns automatisieren, aber du kannst ein nicht-triviales Programm
nicht in alle möglichen Zustände (und die Übergänge dazwischen) bringen
weil es einfach zuviele sind.

Gerrit

 

[Hanno Foest]

Am 28.10.2013 21:37, schrieb Gerrit Heitsch:

Kein nicht-triviales Programm kann zu 100% verifiziert oder getestet
werden.

Das ist nicht richtig. Man kann das automatisieren.

Ja, man kann Tests und Suche nach den üblichen Verdächtgen wie buffer
overruns automatisieren, aber du kannst ein nicht-triviales Programm
nicht in alle möglichen Zustände (und die Übergänge dazwischen) bringen
weil es einfach zuviele sind.

Du kannst die Verifikation automatisieren, da bleibt dann kein Platz
mehr für Fehler.

Hanno

 

[Hartmut Kraus]

Am 28.10.2013 20:59, schrieb Frank Buss:

Hartmut Kraus wrote:
Am 28.10.2013 16:50, schrieb Frank Buss:
Durch fehlerhafte Software in der Firmware von Toyota ist mindestens
eine Person gestorben:

http://www.eetimes.com/document.asp?doc_id=1319903
(Cookies ausschalten, wenn man alle drei Seiten ohne Anmeldung lesen
will)

Ich habe zwar nicht den 800-Seiten Bericht gelesen (falls der überhaupt
öffentlich zugänglich ist), aber der Titel des Artikels ist etwas
missverständlich, da ich es für unwahrscheinlich halte, daß der Unfall
durch einen Bit-Flip zustande kam, sondern eher weil in der Software
tatsächlich Stack Overflow und Race-Condition Fehler waren.

Wie kann man Stack Overflow Fehler bei so kritische Software übersehen?
Indem man die Software nicht genügend austestet, das kommt doch alle
Tage vor. Je komplexer das Programm, um so mehr Fehlermöglichkeiten.

Durch testen findet man Stack Overflow Fehler nicht sicher, besonders
nicht in Multithreaded Programmen wie es scheinbar hier der Fall war.

Dann möchte man sich eine andere "Programmier- und Testweise"
angewöhnen, mal ganz einfach ausgedrückt. Sicherheitsrelevante Systeme
möchten gefälligst auch sicher sein, nicht erst durch Redundanz
"fehlerunwahrscheinlicher" gemacht werden können.

Da fällt mir doch immer wieder die Bemerkung damals zum "Elchtest" ein:
Das ESP war eigentlich dafür gedacht, ein gut durchkonstruiertes Auto
noch sicherer zu machen - nicht, es überhaupt erst fahrfertig zu machen.

 

[Hartmut Kraus]

Am 28.10.2013 21:37, schrieb Gerrit Heitsch:

On 10/28/2013 09:28 PM, Hanno Foest wrote:
Am 28.10.2013 21:06, schrieb Gerrit Heitsch:

Kein nicht-triviales Programm kann zu 100% verifiziert oder getestet
werden.

Das ist nicht richtig. Man kann das automatisieren.

Ja, man kann Tests und Suche nach den üblichen Verdächtgen wie buffer
overruns automatisieren, aber du kannst ein nicht-triviales Programm
nicht in alle möglichen Zustände (und die Übergänge dazwischen) bringen
weil es einfach zuviele sind.

Man kann aber ein "nichttriviales" System in "triviale" (beherrschbare)
aufteilen bzw. nicht erst zusammenpropfen. Also nicht den Fall erst
testen müssen, ob beim Betätigen des Zigarettenanzünders der Airbag auslöst.

 

[Gerrit Heitsch]

On 10/28/2013 09:47 PM, Hanno Foest wrote:

Am 28.10.2013 21:37, schrieb Gerrit Heitsch:

Kein nicht-triviales Programm kann zu 100% verifiziert oder getestet
werden.

Das ist nicht richtig. Man kann das automatisieren.

Ja, man kann Tests und Suche nach den üblichen Verdächtgen wie buffer
overruns automatisieren, aber du kannst ein nicht-triviales Programm
nicht in alle möglichen Zustände (und die Übergänge dazwischen) bringen
weil es einfach zuviele sind.

Du kannst die Verifikation automatisieren, da bleibt dann kein Platz
mehr für Fehler.

Leider wird die bei einem nicht-trivialen Programm nicht mehr fertig
bevor das Universum zum nächsten Big Bang wieder zusammengefallen ist.

Gerrit

 

[Gerrit Heitsch]

On 10/28/2013 09:55 PM, Hartmut Kraus wrote:

Am 28.10.2013 21:37, schrieb Gerrit Heitsch:
On 10/28/2013 09:28 PM, Hanno Foest wrote:
Am 28.10.2013 21:06, schrieb Gerrit Heitsch:

Kein nicht-triviales Programm kann zu 100% verifiziert oder getestet
werden.

Das ist nicht richtig. Man kann das automatisieren.

Ja, man kann Tests und Suche nach den üblichen Verdächtgen wie buffer
overruns automatisieren, aber du kannst ein nicht-triviales Programm
nicht in alle möglichen Zustände (und die Übergänge dazwischen) bringen
weil es einfach zuviele sind.
Man kann aber ein "nichttriviales" System in "triviale" (beherrschbare)
aufteilen bzw. nicht erst zusammenpropfen.

Ist leider bei aktueller Software die mit anderen Modulen per IPC oder
gar Netzwerk kommuniziert nicht mehr so einfach wie sich die Idee anhört.

Einfachere Software bietet nicht die heute gewünschten Möglichkeiten,
sonst wäre man ja dabei geblieben.

Gerrit