Beschleunigtes Verfahren: TOYOTA erleidet eine Niederlage vor US-Gericht

[taue2512]

Die Meldungen über Autos der Firma TOYOTA, die in der Vergangenheit wie von Geisterhand plötzlich beschleunigten kamen zuerst vereinzelt in die Medien und die betroffenen Fahrer wurden zumeist hierzulande als unfähige Amerikaner belächelt.

Nach einem Todesfall bei einer solchen unerklärlichen „Geisterfahrt“ kam die Unfallserie aber schließlich, wie zu erwarten war, doch noch vor ein US-Gericht und schnell kristallisierte sich eine mögliche Ursache für diese unerklärlichen Vorfälle heraus: Qualitätsmängel in der Software des Motorsteuergeräts.

Das Motorsteuergerät – auch Engine Control Module (ECM) genannt – ist vereinfacht ausgedrückt ein kleiner Computer mit allen Komponenten, die man zuhause auch in einem Notebook vorfinden würde. Natürlich läuft darauf auch Software, die wie es sich herausstellte wohl entgegen aller Kunst und guten Praktiken anscheinend bei TOYOTA oder einem seiner Zulieferer nur mit einer heißen Nadel zusammengeschustert wurde.

Ich selber komme ja aus dem IT-Bereich und beschäftige mich zudem privat mit dem CAN-Bus und Steuergeräten. Ich möchte hier mal hier versuchen auch für Laien verständlich das Kernproblem zu eruieren und mit Falschen wiedergegebenen Tatsachen in den Medien ausfzuräumen.

Eines ist klar: Wenn die gefundenen Ansatzpunkte mangelhaften Designs wirklich der Realität entsprechen und Gehör finden, so kann auf TOYOTA und auch andere Autohersteller demnächst eine immense Kostenwelle durch Schadenersatzansprüche, teure Rückrufe und Nachbesserungen zurollen.

Programmcode, der auf solchen Steuergeräten ausgeführt wird nennt sich auch "Embedded Code". Dieser wird im Allgemeinen mit gängigen Tools und bekannten Programmiersprachen wie C oder Assembler vom Aufbau her von Softwarearchitekten designt und von Softwareentwicklern entsprechend den Anforderungen geschrieben und nach Fertigstellung durch die QA getestet.

Selbst so einfache Vorgänge und Prozesse, wie eben die Einbindung und Abfrage des Gaspedalsensors in einem Echtzeit-OS (Real-time operating system - RTOS) umfasst nicht selten zehntausende Zeilen an Programmcode. Sobald eine Funktion als Sicherheitskritisch bekannt ist, steigt der Integrationsaufwand durch höhergestellte überwachende Prozesse (Watchdogs) und die damit zusammenhängende Komplexität um ein vielfaches –Entwicklungszeit und Tests werden umfangreicher und kosten somit zusätzlich Zeit und Geld in der Entwicklung.

Sicherlich kann man als verantwortlicher Hersteller gängige Empfehlungen und Entwicklungsstandards ignorieren und einfach über Bord werfen, um seine eigenen laxeren Regeln zu definieren, zum Beispiel um diese Kosten zu senken – aber auf die Dauer sinkt die Qualität und Zuverlässigkeit des eigenen Produktes. Das führt wiederum zu Imageschäden, teuren Nachbesserungen und Reparaturen und aber leider auch zum Verlust von Menschenleben.

Was der vom US-Gericht in Oklahoma bestellte Sachverständige in puncto TOYOTA’s Motorsteuergerät nun ans Tageslicht gebracht hat ist beinahe ein Musterbeispiel dessen, wie man es tunlichst nicht angehen sollte und könnte fast als abschreckendes Beispiel für fast jede Branche dienen, die sich mit der Entwicklung sicherheitskritischer Steuergeräte und deren Software befassen, egal ob nun in der Automobilindustrie, im medizinischen Bereich, der Luftfahrt oder wo auch immer.

Zu den am meisten bemängelten Designschwächen gehörten:

TOYOTA’s elektronisches Gaspedal-Steuersystem, auch Electronic Throttle Control System (ETCS) ist kurz gesagt mangelhaft. Der Quellcode ist sehr löchrig und enthält viele Fehler, die unter gewissen Umständen ungewollte Beschleunigungen (Unintended accellerations - UA) auslösen können. Qualitätsmessungen lassen weitere grundsätzliche Fehler vermuten. Die von TOYOTA eingebauten Schutzmechanismen sind mangelhaft und unzureichend (vor Gericht wurde von einer „Kartenhaus-Architektur“ gesprochen). Fehlverhalten des TOYOTA ETCS-Systems sind mögliche Grundursache für Fälle ungewollter Beschleunigung.

Hardware

Auch wenn die Untersuchung vor Gericht sich vornehmlich auf Softwareaspekte fokussierte, so sind es auch Hardwareprobleme, die eine Rolle bei den Vorfällen spielen: TOYOTA zum Beispiel gab an, das ab Modelljahr 2005 ausnahmslos alle verbauten Camry Prozessorplatinen mit sogenannten Fehlerkorrektur- und Prüfsummen-Chips (EDAC) auf den Speicherbausteinen bestückt seien. Das waren sie aber nicht! Dabei sind ECC- oder Paritätscheck-Speicherbausteine eine der günstigsten hardwareseitigen Absicherungsmöglichkeiten für sicherheitskritische Systeme. Ein paar Fälle von UA wurden anfangs noch durch fehlerhaft gesetzte Lötstellen im Pedalsensor erklärt – aber in der vor Gericht verhandelten UA mit fatalem Ausgang war dies nicht die Ursache.

Software

Die Motorkontroller-Steuersoftware im ECM war das Hauptziel der Untersuchungen. Hier eine Aufstellung aller bemängelten Elemente:

Spiegelung (Mirroring) von wichtigen Schlüsseldaten und Variablen wird nicht konsequent betrieben. Besonders im Hinblick auf Stack-Overflows, die im Betrieb schon mal aufgrund von inkohärenten Werten auftreten können ein sehr riskantes Unterfangen. TOYOTA gab an, das nur 41% des für Stack-Fehler zugewiesenen Speicherbereichs überhaupt ausgenutzt werden, was bedeuten würde das die Codequalität gar nicht mal so schlecht ist. Tatsächlich ergaben Messungen im Betrieb aber eine Nutzungsquote von 94% dieses Platzes. Zudem fand man heraus das sogenanntes „Stack-Killing“ und weitere nicht empfehlenswerte programmiertechnische Maßnahmen und Kniffe entgegen des von der MISRA-C (Motor Industry Software Reliability Association) fixierten Regelwerks für Softwareentwicklung in den Quellcode eingebaut sind.

Der Hauptprozessor verfügt ferner nicht über geschützten adressierbaren Speicher, um Stack-Overflows aktiv zu verhindern. Zwei besonders wichtige Werte wurden nicht gespiegelt im Speicher abgelegt, zum einen systemkritische interne Datenstrukturen des Echtzeit-OS und zum anderen das wichtigste Byte im diesem Zusammenhang überhaupt: Die gemessene aktuelle Gaspedalstellung.

Auch wenn TOYOTA eine Analyse des Stacks durchlaufen hat, blieben viele Ursachen einfach auf der Strecke und unbeachtet. Prozessaufrufe durch sogenannte Pointer, Bibliotheken und Funktionen der Assembly (rund 350 verschiedene Events) blieben fast gänzlich unbehandelt – sogar die RTOS-Benutzung beim Umschalten des aktiven Prozesses und die permanente Überwachung der Stacks im Betrieb. Das TOYOTA ETCS basiert auf einer erweiterten Version von OSEK, einem in der Automobiltechnik weit verbreiteten Echtzeit-Betriebssystem mit einer gut beschriebenen Schnittstelle (API), aus welchem Grund auch immer war die verwendete OS-Version nicht vom Hersteller für den verwendeten Prozessor zertifiziert und vollkompatibel.

Ungewollte Prozessabbrüche im OS waren als mögliche Quelle ungewollter Beschleunigungen im Zentrum des Interesses. Gerade weil einzelne Bits im Speicher ganze Prozesse steuern und beeinflussen, können Fehler an der Hardware oder Software zu ungewollten Prozessabbrüchen oder auch umgekehrt zu ungewollten Prozessaufrufen führen.

Tests an Fahrzeugen führten zu der Erkenntnis das der Absturz nur eines einzigen bestimmten Prozesses zur Verlust der gesamten Kontrolle über die Gaspedalstellung führen kann, und das in diesem Fall der Fahrer zuerst den Fuß komplett von der Bremse nehmen muss, um bei ungewollter Beschleunigung die fehlerhaften Gaspedalwerte nach einem Prozessneustart zu korrigieren. Total verkehrte Welt also.

Und so verwundert es den Sachverständigen auch nicht weiter das noch viel mehr Fehler gefunden wurden, wie Puffer-Überläufe, ungültige Prozeduraufrufe und duplizierte Tasks, die gegeneinander arbeiten und sich blockieren können.

Insgesamt existieren im Camry ETCS Quellcode über 11.000 Variablen. Der Sachverständige umschrieb ihn als „Wirrwarr“. Mittels gängiger Sourcecode-Qualitätsmeßkriterien erzielten 67 Funktionen sehr hohe Negativwerte von 50 Punkten und gelten damit eigentlich als „untestbar“, während allein die Routine für die Auswertung der Gaspedalstellung einen Wert von 100 erzielte, was immerhin als „unwartbar“ bezeichnet wird.

Zwar befolgte TOYOTA die MISRA-Empfehlungen ansatzweise, aber man fand insgesamt über 80.000 Regelverletzungen. Nach eigenen Angaben setzt TOYOTA nur 11 der MISRA-C Regeln um und prüft diese, wobei aber ob dieser Tatsache 5 davon im betroffenen Code fehlerhaft implementiert waren. Die Ausgabe MISRA-C:1998, die gültig war als der betreffende Code geschrieben wurde, umfasst 93 verpflichtend und 34 optional umzusetzende Code-Designempfehlungen. TOYOTA berücksichtigt leider nur 6 davon und die Qualität des Codes erlaubt weitere Rückschlüsse, die darauf hindeuten das es keine interne Codeabnahme im Vier-Augen-Prinzip oder gar ein automatisiertes Bug-Tracking-System gab.

Sogar die amerikanische Weltraumbehörde NASA war anfangs in den Audit der 5 integrierten kritischsten  Sicherheitsroutinen eingebunden und kam zu dem Ergebnis, das die 3 Notbetriebs-Stufen (Humpelbetrieb, Drehzahlbegrenzer und der finale Motorstopp) lediglich von einem einzigen Prozess überwacht werden. Was also passiert wenn eben dieser Prozess abbricht oder sonst wie Probleme hat?

Fast alle sogenannten „Embedded-Systems“ haben Überwachungs-Timer (Watchdogs) um hängende Prozesse aufzuspüren und gegebenenfalls neu zu starten. In sicherheitskritischen Umgebungen sind diese Watchdogs somit Pflichtprogramm. Aber wenn das zu überwachende System immer komplexer wird, steigt auch die Komplexität der Watchdog-Prozesse. Die beste Lösung in einem Multitasking-System ist, dass sich jeder startende Prozess beim Watchdog anmeldet. Im TOYOTA ECTS begnügte sich der Watchdog-Prozess mit einem simplen CPU-Timer-Tick, dem sogenannten Interrupt. Dieser Interrupt ist recht langsam und sehr schwerfällig, bis zu 1.5 Sekunden könnte bei CPU-Voll-Last ein Prozess mit einem fehlerhaften Status hängen oder beliebig den Speicher vollschreiben, ohne dass dieser zurückgesetzt würde.

Zusätzlich wurden Fehlercodes vom OS vollständig bei der Fehlerbehandlung außen vor gelassen, was definitiv gegen die MISRA-C Richtlinien ist.

TOYOTA’s Motorsteuergerät besitzt einen weiteren Prozessor, um den Hauptprozessor zu überwachen. Dieser Zusatzprozessor kommt aber von einem Dritthersteller, zudem läuft darauf eine Firmware, die bei TOYOTA vollkommen unbekannt ist und vermutlich ohne Kenntnis des Hauptprozessorcodes entwickelt wurde. Nüchtern betrachtet ist dieser Umstand etwas sehr positives, denn man hätte so hardwareseitig eine unabhängige Kontrollinstanz. Der Chip kommuniziert mit dem Hauptprozessor allerdings nur über eine serielle Verbindung und besitzt allerdings auch denselben Baustein des Hauptprozessors, der die Gaspedalstellung in digitale Werte umsetzt. Jeder vernünftige Mensch würde nun diesen zweiten Analog/Digital-Wandler parallel direkt ansprechen, um eine erhöhte Ausfallsicherheit zu erreichen, falls der Wandler im Hauptprozessor aus welchem Grund auch immer einmal ausfallen sollte.

Im vorliegenden Design macht nur der Wandler im Hauptprozessor die ganze Arbeit allein.

Alle Systemüberwachungsprozesse dieses zweiten Chips sind von einem vor dem Gericht wegen Sicherheitsbedenken nur „Task X“ genannten Prozess auf dem Hauptprozessor direkt abhängig. Quasi eine Eierlegendewollmilchsau von Task, der neben der Gaspedalstellung, die Motordiagnostik, Systemausfall-Überwachung und vieles anderes mehr gleich miterledigt. Dieser „Task X“ ist also eine weitere kritische mögliche Fehlerquelle.

Lösungen

Es sollten Rückschlüsse aus dem Hard- und Softwaredesign gezogen werden. Die Entwickler und Architekten sollten sich gängiger Methoden bedienen, Peer-Code-Reviews, Tools zum Messen der Codequalität einsetzen, rigorose Dokumentation und Umsetzung von Richtlinien einfordern. In solch komplexen Systemen ist es zwar unmöglich die Gesamtheit aller Szenarien zu testen, aber zumindest kann man vieles am Reißbrett ausschalten wenn das Produkt von der Architektur her in Teilen bereits redundant ausgelegt ist. Einer entwickelt, ein anderes Team testet – 4 Augen sehen mehr als 2.

Aber ob diese Erkenntnisse dem verstorbenen Unfallopfer und seiner Nachkommen im Nachhinein wirklich nützlich sind, bleibt zu bezweifeln.

[Ascender]

Das mag ja alles sein, aber wieso traten diese Fahrer nicht (stark) auf die Bremse? Die Bremskraft ist im Zweifelsfall stärker als ein durchgetretenes Gaspedal.

Wieso nicht die Zündung ausschalten, oder eine neutrale Stufe/den Leerlauf einlegen?

Insofern werfe ich den Fahrern dieser Unglücksfahrzeuge schon eine gewisse Grunddämlichkeit vor.

Es sei denn alle diese Systeme werden ebenfalls elektronisch gesteuert und die NSA hatte Zugriff darauf.

Ansonsten gebe ich dir natürlich recht. Solche Sicherheitsrelevanten Steuerungssysteme sollten nicht zusammengespart werden. Die Autos werden ja auch immer komplizierter. Je mehr dranhängt, desto mehr Programmcode.

[Standspurpirat38000]

Zitat:

Insofern werfe ich den Fahrern dieser Unglücksfahrzeuge schon eine gewisse Grunddämlichkeit vor.

Es sei denn alle diese Systeme werden ebenfalls elektronisch gesteuert und die NSA hatte Zugriff darauf

Bisher haben die Amerikaner nur vorgemacht, was noch auf die deutschen und Europäer zukommt.

Eine gewisse Form von Grunddämlichkeit zeichnet sich leider auch schon in Europa ab.

Das ist nicht nur an manchen Hinweisen in Bedienungsanleitungen und an manchen Entwicklungen von Produkten für alltägliches zu erkennen.

Dinge die kein Mensch braucht, der 2 gesunde Hände hat, aber reissenden Absatz finden..

Die NSA hat bestimmt auch ein Interesse daran, mitzulesen, was innerhalb der Steuergeräte erzählt wird, aber der Zugang ist nicht so leicht herzustellen, wie ins deutsche Fest- und Mobilfunknetz.

[Glitti]

Schön mal einen Bericht zu lesen der sich an IT'ler richtet!

Das ist ja echt eine kriminelle Nummer die sich Toyota da leistet.

Danke für den umfassenden Bericht dazu!

[PIPD black]

Stand der Technik

....im Automobilbau....und wenn es das noch nicht ist, dann wird er es eben.

Man spart wo man kann. Und die Entwicklungskosten eines neuen Autos sind nunmal die höchsten in der Produktion. Da man auch an der Prüfung der Hardware spart, ist es im Prinzip auch nachvollziehbar, wenn man auch entsprechend bei der Software verfährt......für mich zumindest nachvollziehbar.

Von den gefahrenen Softwareupdates, die die Werkstätten während der Wartung eines Fahrzeugs machen, bekommt der Endkunde gar nix mit.....alles still und leise.....

[Goify]

Sehr informativ, auch wenn mir nicht alle Begriffe geläufig sind. Erinnert mich ein wenig an die Binäruhr mit Überlauf.

Was folgern wir daraus? Toyota ist Schuld an den Unfällen, die Fahrer hätten sie aber leicht verhindern können.

[der_Derk]

Gut geschrieben .

Leider wird man in den Quellcode als Normalsterblicher keinen Einblick nehmen können, insofern sind die Aussagen zu den Programmierverfehlungen leider nicht nachprüfbar... Deshalb: Gute Zusammenfassung, aber wo ist die Quelle? .

[Käfer1500]

Berufsbedingt habe ich die Toyota Geschichte auch in technischem Detail verfolgt. Die Reports lassen sich ja frei downloaden (http://www.nhtsa.gov/UA), "Michael Barr" als einer der technischen Analysten ist dabei ein gutes Suchschlagwort und er sollte hier auch lobend erwähnt werden.

Mit den MISRA Regeln muß ich mich auch täglich befassen, daß Toyota nur 11 der 128 MISRA C:1998 Regeln umsetzt, und diese nicht mal vollständig erfüllt, ist schon sehr befremdlich und definitiv nicht mehr Stand der Technik!

Setzt man gar "functional safety" Maßstäbe an, ist die Summe der Verletzungen fundamentaler embedded System Entwicklungsvorgaben schon haarsträubend - jede dieser Verletzung allein könnte für den Verantwortlichen in einem Gerichtsprozeß schon einige Zeit hinter Gittern rechtfertigen! Und so hart es klingt: nicht nur wegen der Opfer würde ich mir wünschen, daß hier hart geurteilt wird, sondern auch für einige schludrig arbeitende Kollegen hier, die dann endlich mal den "Präzedenzfall" hätten, den sie in "functional safety" Diskussionen immer wieder fordern und mit dessen Fehlen sie ihre geringen eigenen Qualitätsansprüche noch verteidigen.

Wobei ich auch in einem Projekt mit einem anderen japanischen OEM mitarbeite, der definitiv höhere Software Qualitätsanforderungen hat und deren Nachweise auch regelmäßig einfordert und durch sehr gute interne Spezialisten überprüft.

[Federspanner136107]

Nun der Bericht ist hier völlig falsch - Du hättest dazu schreiben sollen nur für Computer Fuzzis interessant :-))

Du schreibst zu viel und man muß alles lesen um zu begreifen die Programmierung war schuld am Versagen. Interessant fande ich es trotzdem, weil ich schon 20 Jahre versuche zu programieren - ich weiß immer noch nicht was ich nach der 1. Zeile schreiben soll. Du könntest gut erklären was man wissen sollte um zu vermitteln was ein Programm enthalten sollte.

Es gab Freaks die sind über die Luftdruckmessung in den Computer gekommen und konnten Licht einschalten usw. Die Luftdruckmessung funktioniert anscheind mit wlan.

Autos sollen eines Tages von selbst fahren, die Google-Steuerung ist da extrem erfolgreich.

Wenn die TOYOTA-Autos von selbst fahren, dann ist das echt übel - Toyota kann auf das Gaspedal anzusteuern nicht verzichten, sonst verbauen sie sich die Zukunft.

Echtzeit Betriebsysteme finde ich faszinierend. QNX war eins. Letzte Version läuft leider nur mit IDE im BIOS, mit ACPI läufts nicht auf dem PC.

Ich sah das man Echtzeit-Betriebsysteme auch in der Medizin verwendet.

Die Frage bleibt halt was wir wollen? Wollen wir Autos die von selbst fahren???

In anderen Ländern fahren Züge alleine und die Deutschen würden sich vielleicht ungern in ein ferngesteuerten Zug setzen.

Wenn es eine ganz neue Stadt gebe, auf der grünen Wiese gebaut und die Autos würden nur 30 fahren, würden sich die Leute dann Google-Autos und Mercedes kaufen??

Zuviel Elektronik kann manchmal zu viel sein und ein Rückschritt bedeuten.

[der_Derk]

Der freie Download sieht anhand der Softwareuntersuchung aber dann so aus - komplett geschwärzt, sobald eine Zeile Code oder ein interessanter Sachverhalt in Sicht kommt... Aber trotzdem Danke für den Link

[achjaso]

Gaszug, Kupplung, fertig.

Ich würde jetzt mal gerne noch wissen wie diese Codes bei anderen Herstellern aussehen. Und dann würde ich mir überlegen, ob ich nochmal in so ein hochgezüchtetes Auto steige. Wobei?

Natürlich würde ich das.

Interessant zu diesem Thema:

http://...informationisbeautiful.net/.../

Die "Car-Software" wird mit 100 Mio Zeilen angegeben und führt die Grafik an...

[Standspurpirat38000]

Das Computer Fehler produzieren ist nichts neues, schon während der ersten Mondlandung wurde die Besatzung der Landefähre angwiesen den Computer zu ignorieren..

Statt simple oder vielleicht auch komplizierte funktionierende Mechanik weiter zu entwickeln, setzt man auf die EDV, weil es keinen mehr gibt, der noch weiss, wie man einen Gasabowdenzug verlegt, der nur einen Bruchteil der, mehr oder weniger sinnfreien, Mess und Regeltechnik im Fahrzeug kostet.

Virtuelle oder echte Fehler ohne sinnvolle Beschreibung werden irgendwo gespeichert, für deren Löschung und Behebung hat der Verbraucher zu zahlen, ohne das er sicher sein kann, das der Fehler auch behoben ist.

Der Kunde freut sich darüber, was sein Auto alles hat und kann kann, wehe es schleicht sich ein Fehler ins System oder es hat von Anfang an einen drin..

[xHeftix]

Obs die Technik war oder nicht. Ich trau den Amis immer noch zu, dass sie einfach zu dämlich oder faul waren, den Fuß vom Gas zu nehmen und auf die Bremse zu stellen...

[Gorgeous188]

ISO 26262

ASIL Level

IEC 61508

Automotive SPICE

IEC 15504 Level

Gibt ja noch nicht genug Normen dafür.

[7406]

Ich will nicht meckern, aber widerspricht das ganze nicht:

http://www.motor-talk.de/.../...icht-schuld-am-unfalltod-t4713245.html

Als Softi verstehe ich natürlich nichts von Jurestei, aber sind die andere Gerichte in keinster Weise an das erste Urteil aus L.A. gebunden?

[Roland0815]

Tja, mit einer Drosselklappe von einem Bowdenzug zun einem echten Gas-Pedal gesteuert wäre das nicht passiert.

[dodo32]

Zitat:

Selbst so einfache Vorgänge und Prozesse, wie eben die Einbindung und Abfrage des Gaspedalsensors in einem Echtzeit-OS (Real-time operating system - RTOS) umfasst nicht selten zehntausende Zeilen an Programmcode. Sobald eine Funktion als Sicherheitskritisch bekannt ist, steigt der Integrationsaufwand durch höhergestellte überwachende Prozesse (Watchdogs) und die damit zusammenhängende Komplexität um ein vielfaches –Entwicklungszeit und Tests werden umfangreicher und kosten somit zusätzlich Zeit und Geld in der Entwicklung.

Sicherlich kann man als verantwortlicher Hersteller gängige Empfehlungen und Entwicklungsstandards ignorieren und einfach über Bord werfen, um seine eigenen laxeren Regeln zu definieren, zum Beispiel um diese Kosten zu senken – aber auf die Dauer sinkt die Qualität und Zuverlässigkeit des eigenen Produktes. Das führt wiederum zu Imageschäden, teuren Nachbesserungen und Reparaturen und aber leider auch zum Verlust von Menschenleben.

Wie bereits erwähnt..., der ganze Aufwand nur um einen Gaszug zu ersetzen? Kann's nicht sein.

Darüber hinaus: geiler Bericht!

[Duftbaumdeuter272]

Zitat:

von Roland0815

"Tja, mit einer Drosselklappe von einem Bowdenzug zun echten Gas-Pedal gesteuert wäre nichts passiert."

Nee?

Kann wohl kein Bowdenzug hängen oder die Klappe klemmen?

Lustig solch Hinterwelts-Kommentare

[Federspanner135372]

Hier versuchen einige die Marke Toyota kaputtzureden. Da kann nur eine deutsche Marke dahinterstecken.

Um nicht falsch verstanden zu werden: Ich fahre übrigens auch eine deutsche Nobelmarke, muss aber gestehen, dass außer dem Image, nichts besser ist als an jedem Japaner. Und das ist ehrlich gemeint.

[touranfaq]

...bei der ganzen Geschichte beschäftigt mich eine einfache, aber sehr zentrale Frage:

Laut Toyota waren ja klemmende Pedale die Ursache für UA, und eben nicht Fehler in der ETCS. Im Zuge des Millionenrückrufs wurden nur die Gaspedale modifiziert (Einbau von Metallplättchen um die Rückstellkraft wiederherzustellen).

Warum hörten die Fälle von UA nach den Gaspedalmodifikationen schlagartig auf, wenn (wie die Untersuchung nahelegt) die tatsächliche Ursache im ETCS zu suchen ist?

[Reachstacker]

Das Kriminelle Gerichtsverfahren und das der NHTSA und NASA hat Toyota gewonnen.

Hier geht es um eine Zivilklage und Geld in einem kleinen Amtsgericht im Hinterland von Oklahoma.

Noch dazu ein Schoeffengericht.....

Und diese 12 Schoeffen wissen noch mehr ueber IT als der Blogbetreiber und haben den Software Fehler gefunden.

Ich glaub ich raste aus....

Das Verfahren wurde eingestellt bevor die Schoeffen abstimmen konnten, eben weil Toyota 3 Millionen auf den Tisch geblaettert hat und fertig.

Seitdem die Hexenjagd vorbei ist hat es keine ungewollten Beschleunigungen mehr gegeben. Anscheinend sind die Fehlerhaften und Verantwortungslosen Toyota ECU (ECM) Selbstheilend???

Selbst die Gaspedal-modification war reines Blendwerk das gemacht wurde um die Wogen zu glaetten und jeder hier (wo ich wohne) wusste das es Quatsch war.

Interessant geschrieben aber etwa genauso accurate wie die verschiedenen Theorien zur Ermordung von JFK.

PS: und welche Gremlins hat man in den selbst-rasenden Audi's der 80er gefunden?

Greetings from the Pine Barrens, Pete

[Duftbaumdeuter272]

@Reachstacker

so sieht's aus, volle Zustimmung

Schöne Abhandlung über Bits und Byts aber leider nicht zielführend weil ein Gaspedal ein Gaspedal ist und in der Sicherheitspriorität hinter dem Bremspedal steht und bei diesem immer noch eine mechanisch Übertragung vorhanden ist.

[pibaer]

Solche Audits, die sich auf "gängige Sourcecode-Qualitätskriterien" (Metriken) stützen, kann man zumindest in diesem Teil vergessen. Es gibt viele Versuche, solche Kriterien aufzustellen, aber alle, die ich bis jetzt gesehen habe, sind einfach Müll. Teilweise komplett widersprechende Anforderungen und Grenzwerte, die bei etwas komplexerer Algorithmik praktisch nicht einzuhalten sind. Man versucht, den sehr schweren Vorgang einer Software-Bewertung anhand von ein paar Regeln durchzuführen, die in der Regel jede für sich isoliert zwar scheinbar Sinn ergeben mögen, aber in Kombination hirnrissig sind. Die Aussagen solcher automatischen Bewertungen kann man daher direkt in die Tonne treten.

Insgesamt leidet diese Untersuchung auch an Mängeln, denn sie scheint sich vor allem in Details zu verlieren und sagt praktisch nichts über die Sicherheitsziele und nur sehr wenig über die Umsetzung dieser aus. Einfach nur ziellos zu schauen, was wo wie doppelt oder abgesichert gemacht wird, ist nicht zielführend, denn auch hier entscheidet die Kombination der Einzelmaßnahmen. Die müssen nämlich keinesfalls alle für sich allein sicher sein. Ohne Kenntnis des Konzepts ist kaum eine vernünftige Bewertung möglich.

Die "Lösung" klingt typisch nach "Prozesse und alles wird gut". Real passiert dann: "Prozesse und alles wird so richtig teuer."

[pibaer]

Zitat:

Tja, mit einer Drosselklappe von einem Bowdenzug zun einem echten Gas-Pedal gesteuert wäre das nicht passiert.

Stimmt, klemmende Gaszüge gab es ja noch nie.

Zitat:

Hier versuchen einige die Marke Toyota kaputtzureden. Da kann nur eine deutsche Marke dahinterstecken.

Eher nicht. Schließlich geht es um ein amerikanisches Gericht. Die Software mag auch wirklich nicht besonders gut sein (die Beschreibung deutet jedenfalls darauf hin, dass der Software-Entwicklungsprozess nicht besonders bürokratisch gewesen zu sein scheint ), aber ob sie in letzter Konsequenz auch wirklich an den Unfällen Schuld war oder ob im realen Betrieb trotzdem mit ausreichender Wahrscheinlichkeit eine funktionierende Absicherung gegeben war, kann der Bericht nicht beantworten. Interessant ist tatsächlich in der Beziehung, dass die Meldungen von selbstbeschleunigenden Toyotas nach einigen wenigen mechanischen Änderungen aufgehört haben...

Ehrlich gesagt bin ich froh, dass ich die Software im Flugzeug, in dem ich gerade sitze oder des Zuges oder Autos nicht so genau kenne. Genauso übrigens wie die Eigenschaften der mechanischen Komponenten, insbesondere was die Alterung betrifft. Sonst würde ich wohl mehr laufen.

[touranfaq]

...falls jemand Interesse hat die 286 Seiten zu lesen:

https://www.google.de/search?q=Bookout_v_Toyota_Barr_REDACTED.pdf

Noch eine interessante Frage, die man sich mal stellen sollte:

Ist es Zufall, dass sich UA-Fälle ausgerechnet in jenem Land häufen, wo die Produkthaftungsgesetze aus Geschädigten über Nacht Millonäre machen können?

Wenn die Software buggy und dadurch der Auslöser von UA ist, sollte dies doch auch in anderen Ländern auftreten, zum Beispiel auf dem Heimatmarkt Japan?

[dodo32]

Zitat:

Kann wohl kein Bowdenzug hängen oder die Klappe klemmen?

Lustig solch Hinterwelts-Kommentare

Bring mal Beispiele, bevor Du andere als Hinterwäldler titulierst. Dann reden wir weiter. Klar, Klappen klemmen "einfach mal so". Genau.

Ich kenne Beispiele, aber nicht aus der Großserie. Also, jetzt bist Du drann

[pibaer]

Zitat:

Bring mal Beispiele, bevor Du andere als Hinterwäldler titulierst. Dann reden wir weiter. Klar, Klappen klemmen "einfach mal so". Genau.

Ich kenne Beispiele, aber nicht aus der Großserie. Also, jetzt bist Du drann

http://www.apriliaforum.de/.../...mt-oder-am-drosselklappenk-rper.html

http://www.golf2-jetta2-forum.de/.../

http://www.gutefrage.net/frage/golf-3-gaszug-klemmt-warum

https://www.fiesta-ka-forum.de/fiesta-mk3-23/gaszug-klemmt-78607/

Könnte man fast endlos so weiter aufzählen.

Google bringt auf "drosselklappe klemmt gaszug" 7320 Ergebnisse.

Wenn man diese Google-Suche mal durchforstet und die Anzahl der Fälle und der Antworten (typisches Problem, bla...) ansieht, dann wird klar, dass praktisch schon die mieseste ECU-Lösung praktisch einen Quantensprung hinsichtlich funktionaler Sicherheit darstellen muss.

[Duftbaumdeuter272]

Ich habe Fahrzeuge bewegt die 40 mal so schwer waren wie dieser Toyota und ja da gab es eine mechanische Übertragung des Gaspedals zur EP und da gab es sehr oft das Problem, dass die Gestänge oder Umlenkböcke sich verklemmt haben und der Motor auf Abregeldrehzahl ging, aber da die Forderung eines jeden Fahrzeugherstellers in Bezug auf Bremsleistung>Antriebsleistung ist, so konnte man das Geschirre trotz Vollgas ausbremsen.

[dodo32]

Googeln nach alten Kisten bei denen der Gaszug nach 20 Jahren klemmt kann ich auch

Oder nach Hinterachsen die wegfallen, oder Federn die brechen, oder Bremsscheiben...

[pibaer]

Zitat:

Googeln nach alten Kisten bei denen der Gaszug nach 20 Jahren klemmt kann ich auch

Und warum hast Du dann nach Beispielen gefragt? Woher nimmst Du denn die Weisheit, dass die Kisten alle 20 Jahre alt waren, als das Problem auftrat? Google zeigt sehr anschaulich, dass das Problem bei einer mechanischen Lösung noch viel, viel größer ist und eigentlich die ganze Toyota-Geschichte mehr oder weniger eine stark aufgebauschte Geschichte war.

[dodo32]

....jetzt hab ich doch die Golf und KA Links angeklickt und wie erwartet: das Poti. Hatten wir am Golf 2 auch, nur das ist ein hängendes Poti an der DK und das heißt nicht alle Parameter auf Volllast...

[Duftbaumdeuter272]

Ist doch sch..egal wie alt das Auto ist.

Es ändert doch nix an der Tatsache, dass es A nix neues ist das Drosselklappen oder deren mechanisch Übertragung klemmen können und B das man die Karre trotzdem zum stehen bringt.

[touranfaq]

Zitat:

Googeln nach alten Kisten bei denen der Gaszug nach 20 Jahren klemmt kann ich auch

Naja, bei zwei Jahre alten Kisten kann kein Gaszug mehr klemmen, deshalb wirst Du kaum aktuellere Beispiele finden

Aber Gaszüge sind auch nicht das Thema. Viel spannender ist doch die Frage, wie eine rein mechanische Maßnahme (Einbringen von Metallplättchen in das Gaspedal) ein Softwareproblem in der ECU lösen konnte

[dodo32]

...die Google Geschichte zeigt vor allem, dass es alte Fahrzeuge betrifft und sie zeigt, zumindest anhand Deiner Links die den Golf betreffen, dass es am Poti lag. Ich hatte das Problem auch schon und von "Vollgas" kann da in keiner Weise die Rede sein. Toyota hat Mist gebaut und das sollte man anerkennen. Gab es früher sicher auch, nur ist mir kein Fall bekannt in dem ein neuer VW mal kurz den Hahn aufgemacht hat und mit Volldampf von dannen gezogen ist. Kannst ja die 7000 Ergebnisse durchlesen und posten, ob Du einen Fall findest.

[pibaer]

Zitat:

Aber Gaszüge sind auch nicht das Thema. Viel spannender ist doch die Frage, wie eine rein mechanische Maßnahme (Einbringen von Metallplättchen in das Gaspedal) ein Softwareproblem in der ECU lösen konnte

Also das mechanische Einbringen von Metallplättchen in das ECU-Gehäuse hätte sicherlich alle Softwareprobleme gelöst.

[pibaer]

Zitat:

...die Google Geschichte zeigt vor allem, dass es alte Fahrzeuge betrifft und sie zeigt, zumindest anhand Deiner Links die den Golf betreffen, dass es am Poti lag.

Ja, und bei anderen war es rein mechanisch. Angesichts der Tatsache, dass neue Fahrzeuge mit Bowdenzug im PKW-Sektor praktisch ausgestorben sind, müssen die genannten Problemfälle heute demzufolge alt sein. Heißt aber nicht, dass es bis zum Auftreten des Problems lange gedauert haben muss und genauso wenig, dass in einer alten Karre plötzlich keine Sicherheitsanforderungen mehr gelten.

Zitat:

Kannst ja die 7000 Ergebnisse durchlesen und posten, ob Du einen Fall findest.

Wozu? Es ging einfach nur um den Nachweis, dass mechanische Lösungen ebenfalls solche Fälle hervorrufen können. Und angesichts der Anzahl der Fälle schon in deutschsprachigen Foren obwohl solche alten Karren in der Minderzahl sind, ist es recht offensichtlich, dass die mechanische Lösung selbst der angeblich so schrottigen Toyota-Software weit, weit unterlegen ist.

Zudem ist noch zu sagen, dass die (selbst gestellten) Sicherheitsanforderungen in den letzten Jahren deutlich härter geworden sind (die für solche Komponenten geltende ISO26262 ist noch sehr jung). Ein Blick in die Steuergeräte anderer Hersteller wird demzufolge womöglich nicht viel Besseres offenbaren und die mechanischen Lösungen von früher waren (siehe Google) da noch ein ganzes Stück lockerer in der Beziehung...

[Duftbaumdeuter272]

Naja irgendwie muss man Toyota ja vom Trohn der Nr. 1 stoßen und bis 2018 ist nicht mehr viel Zeit.

Die anderen Hersteller haben natürlich alle eine Software mit zig Rückfallebenen für alle Eventualitäten mit der man ohne mit der Wimper zu zucken völlig gefahrlos durch EMP's und bis zum Mars fliegen kann.

[dodo32]

Zitat:

Es ging einfach nur um den Nachweis, dass mechanische Lösungen ebenfalls solche Fälle hervorrufen können

Die Frage ist eben, nach welchem Zeitraum. Also: ab Werk oder nach 20 Jahren. Bei einem Golf 2 kann Dir auch der Tank wegfallen, wenn die Tankbänder verrostet sind.