Das war mir auch nicht ganz klar. Aber auf Seite zwei wird auf diesen Artikel verwiesen:
formatting link
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
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 :-(
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.
Also 2010 hat die Verkehrssicherheitsbehörde NHTSA noch behauptet, das seien keine Elektronikprobleme:
formatting link
Aber das Problem ist nicht neu. Ein SPIEGEL-Artikel von 1986:
formatting link
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
formatting link
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.
Das ist nicht richtig. Man kann das automatisieren. Und angesichts des grauenhaften Zustands der Computersicherheit bleibt uns vielleicht auch nichts andere übrig.
formatting link
Ich finde, dieser Ansatz klingt sehr vielversprechend.
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.
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. ;)
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.
Geht ganz einfach. Man(n) muss zB nur Interrupts im Interrupt zulassen, wie das auf einigen modernen Kernen geht. Dann steigt nämlich der Kompiler nicht mehr durch, wie viel Stack wirklich verbraucht wird.
Auch bei rtOS(en) ist es für die Kompiler nicht mehr ersichtlich, wie viel Stack verbraucht wird. Dort wird dann meistens die Brachialmethode verwendet: Wenn die Magic-Bytes im RAM übrschrieben werden, wird in der Entwicklung der Stack vergrößert und im Release ein Reset gemacht.
Letztendlich läuft es auf das eigentliche Problem hinaus: Stack-Overflows zu finden dauert sehr lange, weil man den Programmablauf systematisch versuchen muss in jede Race-Condition zu treiben. (Ggf sogar duch modifizierten Code). Das dauert aber. Und dafür hat die Automotive kein Geld. Man muss ja Features generiern...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.