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.

[Standspurpirat38000]

Zitat:

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

Richtig, aber gerissene schon, was die Autos alles andere als schnell macht

Für 1,20DM gabs, bzw. 65ct gibts Ersatz im Fahrradladen

[BlackTM]

Alle Review-Prozesse erfordern das die Reviewer die gleichen oder bessere Fähigkeiten mitbringen wie der Autor.

Damit ist natürlich nicht jedes Chaos entschuldigt, aber um sich eine Meinung zu bilden muss man deshalb immer die Fakten kennen um die es geht.

Knifflig an dem Blogpost bzw. seiner Quelle ist imho das Kennzahlen in den Raum geworfen werden die ohne weitere Details recht wenig aussagen. Trotz aller Metriken liegen zudem weitere Schwachstellen im System wie etwa fehlende Redundanz an Sensoren oder Aktoren. Typische Fehler an Sensoren können auch stabile Software beeinträchtigen weshalb es immer Unterschiede zwischen Laborbedingungen und der Realität geben wird.

Für den Hersteller von Motorsteuergeräten rückt in dem konkreten Fall auch hauptsächlich die Anbindung an eine Diagnoseschnittstelle des Fahrzeugherstellers in den Fokus. Hier hätte noch ein Problem erkannt werden können bevor es zu ungewünschten Beschleunigung kommen könnte. Der Teil wird aber gewaltig außen vorgelassen.

Hier reden wir davon das eine Überwachung welche ständig passieren muss - weil es ja das Ergebnis einer während der Fahrt üblichen Regelung ist - plötzlich ausfällt _und_ die Regelung ausfällt - ohne das es jemandem im Laufe des ganzen Freigabeprozederes auffiel. Ein festgestellter Fehler bei den betroffenen Komponenten (Gaspedal und Drosselklappe) soll für ein Aussetzen des normalen Betriebs im Fehlerfall sorgen, ist aber nicht erfolgt.

[Standspurpirat38000]

Wie soll der Fehler im Labor oder im Werk auffallen, wenn er nicht in jedem Fahrzeug steckt und nicht jedes Modell des selben Typs unerwartet beschleunigt?

Langwierige Tests mit 0 Serien vor Serienstart gibt es nicht mehr, die werden nach Anlauf der Serie auf die Käufer abgewälzt.

[Spannungsprüfer20587]

Es gibt genügend Youtube-Videos, wo Amis unkontrolliert aufs Gas latschen und mit ihren Suffs aller Marken geparkte Autos überrollen. Ich halte diese Erklärung immer noch für wahrscheinlicher.

[touranfaq]

Zitat:

Wie soll der Fehler im Labor oder im Werk auffallen, wenn er nicht in jedem Fahrzeug steckt und nicht jedes Modell des selben Typs unerwartet beschleunigt?

Wir reden hier vom Camry, einem der meistverkauften Toyota-Modelle in den USA. Wenn, wie das Barr-Gutachten nahelegt, die Software buggy und die Redundanzmechanismen unzureichend sind, dann "steckt" dieser Fehler in jedem Camry und müsste wesentlich häufiger auftreten.

Außerdem (und da reite ich jetzt solange darauf herum bis endlich mal jemand Stellung dazu bezieht ) stellt sich nach wie vor die Frage wieso die Fälle von UA durch die Gaspedalmodifikation gestoppt wurden, obwohl der Fehler ja angeblich im ETCS zu suchen ist. Wenn Barr wirklich recht hatte, müssten auch heute noch massenhaft Camrys unkontrolliert über die amerikanischen Highways rasen...

[Goify]

Da wurden wohl heimlich Software-Updates durchgeführt. Eine andere Erklärung wäre unmöglich, wenn dieser Report stimmt.

[HaroldF]

Super Beitrag von taue2512. Fundiert und logisch nachvollziehbar, wenn man sich einigermaßen in Hard- und Software Technik auskennt. Zur Zeit kämpfe ich mit meiner A-Klasse mit diesen Fehlerteufeln. Das Auto hat zwar von sich aus noch nie "Vollgas" gegeben, ist aber während der Fahrt mit kurzer Vorwarnung auch schon ausgegangen (Totalverweigerung). Kann genauso brenzlig werden, wie plötzlich Vollgas. Bei diesen elektronischen Helferlein wird einem ja Angst und Bange, wenn man plötzlich keine Kontrolle mehr über das Fahrzeug hat. Bei einem alten Käfer, den ich vor Urzeiten mal hatte, riß der Gaszug und die Drosselklappe verklemmte sich in Stellung Vollgas, gerade als ich in eine Kreuzung einfahren wollte, habe sofort die Zündung ausgeschaltet, sonst hätte ich wahrscheinlich eine Gruppe Fußgänger umgenietet, oder wäre an einer Hauswand zerschellt. Ob bei heutigen Autos so eine Maßnahme noch helfen würde .... Schlüssel rum und aus?

[touranfaq]

Zitat:

Da wurden wohl heimlich Software-Updates durchgeführt.

Na klar. Toyota wurde von der NHTSA zu Millionenstrafen verdonnert, weil sie das Gaspedalproblem angeblich verheimlich haben, dann machen sie einen öffentlichen Rückruf für die Gaspedale, nur um heimlich noch die ECU upzudaten? Ganz davon abgesehen dass es Kunden gab, die die Gaspedalreparatur verfolgt haben und denen sofort aufgefallen wäre, wenn das Auto zusätzlich noch an den Tester gehangen wurde?

Mal ganz abgesehen vom logistischen Aufwand, für alle vom Gaspedalrückruf betroffenen Modelle (da war ja fast jedes Toyota-Modell dabei) mal eben über 100 neue Softwarevarianten zu schreiben, zu testen und zu verteilen?

Sorry, aber das hört sich sehr nach Verschwörungstheorie an.

[Goify]

Hast du eine bessere Erklärung?

[HaroldF]

Bei den Amis muss man alles mit Vorsicht genießen .... War da nicht mal der Fall, wo McD verklagt wurde auf Schadensersatz bzw. Schmerzensgeld in Millionenhöhe, weil ein Gast sich am heißen Kaffee den Mund verbrannt hat? Oder auch nur Verschwörungstheorie? Ich weiß nur, dass in USA die Mietwagen innen über und über mit Sicherheitshinweisen zugepflastert sind. Das ist schon fast wie Entmündigung.

Toyota müßte wohl den Warnhinweis anbringen: Vorsicht, der Wagen kann urplötzlich enorm beschleunigen.

[Reachstacker]

Zitat:

War da nicht mal der Fall, wo McD verklagt wurde auf Schadensersatz bzw. Schmerzensgeld in Millionenhöhe, weil ein Gast sich am heißen Kaffee den Mund verbrannt hat? Oder auch nur Verschwörungstheorie? Ich weiß nur, dass in USA die Mietwagen innen über und über mit Sicherheitshinweisen zugepflastert sind. Das ist schon fast wie Entmündigung.

Das war Dieser Fall der Kaffee fiel in den Schoss der Klaegerin beim fahren. Die Mietwagen die ich jeden Monat benutze sind nicht von unten bis oben mit Warnungsschildern "zugepflastert.... Es ist die uebliche Airbag Warnung am Sonnenschild und meist ein "no Smoking" Aufkleber irgendwo am Cockpit. Der ist in der Regel nicht mehr als 30mm Durchmesser.

Wie schon erwaehnt, es handelt sich hier um eine Schadenersatzklage und NICHT um Rechtssprechung in einem Amtsgericht im Hinterland. Man scheint in D Schwierigkeiten zu haben die Zwei auseinander zu halten... Ausserdem wurde das Verfahren durch einen Vergleich "kurzgeschlossen"... Das heisst im rechtlichen Sinne existiert kein Urteil, aber die Rechtsanwaelte haben ihr Stueck Fleisch gekriegt.

Aus dieser Situation einen Software Fehler fuer Millionen von Camry konstruieren zu wollen ist hanebuechen.!!! Daren glauben nur die Leute die auch glauben das die Mondlandung in einem UFA Studio in Berlin erfolgte...

Und wo ist der entsprechende Rueckruf?

Gruss, Pete (Ami vom Dienst)

[Reachstacker]

@ Goify

Nur weil IHR keine Erklaerung habt ist es aber keine Mistery...

Ihr habt eh alle Maerchenland Vorstellungen ueber die USA.

Pete

[Goify]

Zitat:

@ Goify

Ihr habt eh alle Maerchenland Vorstellungen ueber die USA.

Wenn du dich da mal nicht täuschst.

Mir ist auch ziemlich egal, warum der Unfall passierte. Mir reicht die logische Erklärung, dass es auf Unvermögen seitens der Fahrer zurückzuführen ist.

[touranfaq]

Zitat:

Hast du eine bessere Erklärung?

Ja. Das Problem war ein rein mechanisches (klemmendes Gaspedal), und die Reparatur mit den Metallplättchen hat das Problem nachhaltig abgestellt. Und die ECU/ETCS hat mit den UA-Problemen nichts zu tun.

P.S.: Wirf einfach mal einen Blick in die oben verlinkte Aussage von diesem Barr. Einen Beweis, dass die ECU/ECTS tatsächlich ursächlich für die UA waren, hat er nämlich nicht geliefert.

Er hat (sinngemäß) nur gesagt, dass unter der Annahme des gleichzeitigen Zusammentreffens mehrerer Umstände ("Bitflip" durch Störung von extern im Zusammenspiel mit Sensoren, die unplausible Werte liefern) eine UA auftreten kann und dies experimentell nachgewiesen.

[Reifenfüller133663]

Also wenn ich mir die Summary hier ansehe

http://www.nhtsa.gov/staticfiles/nvs/pdf/NHTSA_report_execsum.pdf

Dann steht da, dass es an den Fahrern lag und nicht an Toyota.

NASA did not find an electronic cause of large throttle openings that can result in UA incidents. NHTSA did not find a vehicle-based cause of those incidents in addition to those causes already addressed by Toyota recalls.

Den Full Report habe ich nicht gelesen. Stehen dort die Infos drin, die du hier im Beitrag zusammengeschrieben hast?

Wenn der Code so schlecht wäre, dann würden die das doch als Ursache hinstellen

[Reachstacker]

@ Goify

Ihr habt eh alle Maerchenland Vorstellungen ueber die USA.

Zitat:

Wenn du dich da mal nicht täuschst.

Wohl kaum. Ich lese ja hier genug davon, da erkenne ich meist mein eigenes Land nicht mehr.

Pete

[Goify]

Vielleicht solltest du mal vom PC weg gehen und einen Schritt vor deine eigene Tür machen?

[Reachstacker]

Ich wandere wahrscheinlich mehr durch die Gegend wie Du (Profile angucken oder touranfaq fragen)

Pete

[Goify]

Ich finde es sehr erstaunlich, was du alles über mich scheinbar weißt. Richtig unheimlich, aber leider fast alles total daneben.

BTT: Wie finden wir denn nun raus, was die tatsächliche Ursache war? Gutachten gibt es ja nun zu Genüge und trotzdem ist unklar, was genau in den letzten Sekunden vor dem Aufprall passierte.

[Reachstacker]

@ Goify

Ich finde es sehr erstaunlich, was du alles über mich scheinbar weißt. Richtig unheimlich, aber leider fast alles total daneben

Nebenbei das kam von Dir:

Zitat:

Vielleicht solltest du mal vom PC weg gehen und einen Schritt vor deine eigene Tür machen?

Pete

[touranfaq]

Zitat:

Wie finden wir denn nun raus, was die tatsächliche Ursache war?

Indem wir kurz in uns gehen und nachdenken:

1) Die Ursachenanalyse des Herstellers hat ergeben, dass ein mechanischer Defekt im Gaspedal ursächlich für die UA-Phänomene ist

2) Der Hersteller hat für die betroffenen Fahrzeuge einen Rückruf durchgeführt und das mechanische Problem behoben

3) Seitdem sind keine Fälle von UA mehr aufgetreten (die es aufgrund der Brisanz des Themas sicher in die Presse geschafft hätten)

Ergo: Die klemmenden Gaspedale waren die tatsächliche Ursache

Bestärkt wird diese Schlußfolgerung durch die oben bereits verlinkte Untersuchung durch NASA/NHTSA, die neben den klemmenden Pedalen keine weiteren Ursachen für UA-Phänomene feststellen konnten.

[Reifenfüller133663]

Und das Pedal klemmte scheinbar nur wegen den Fußmatten?

Weiß jemand was Toyota bei dem Rückruf genau geändert hat?

[touranfaq]

Zitat:

Weiß jemand was Toyota bei dem Rückruf genau geändert hat?

Guggst Du .

[Reifenfüller133663]

Danke, hab mir schon fast gedacht, dass es so eine Placebo Aktion ist.

Hauptsache man zeigt den Leuten, dass man reagiert.

[touranfaq]

Zitat:

Danke, hab mir schon fast gedacht, dass es so eine Placebo Aktion ist.

...und wie erklärt es sich, dass nach der "Placebo-Aktion" keine Fälle von UA mehr aufgetreten sind?

[Reifenfüller133663]

Wie erklärt sich die Wirkung von Placebos? Sie wirken, obwohl sie nicht wirken dürften.

Es gab auch Fälle, wo Leute absichtlich ihren Toyota gegen die Wand gedonnert haben, um Toyota verglagen zu können. Ging aber nach hinten los und nach dem Rückruf versucht es natürlich keiner mehr.

Mal ehrlich, eine Unterlegscheibe von knapp über 1mm soll den Druck der Feder erhöhen? Der Unterschied ist kaum messbar und wenn das Pedal vorher geklemmt hatte, würde diese "Federdruckerhöhung" nichts daran ändern.

Es gab doch auch keinen Fall, wo ein Toyota Gaspedal vor der Aktion nachweislich geklemmt hatte.

[touranfaq]

Zitat:

Mal ehrlich, eine Unterlegscheibe von knapp über 1mm soll den Druck der Feder erhöhen?

Es wird nicht der Federdruck erhöht, sondern der ursprüngliche Abstand zwischen den "Zähnen" der beiden Kunstoffteile wiederherstellt. Deshalb gibt es auch unterschiedliche Plättchen, die dem jeweiligen Verschleißzustand angepasst eingesetzt werden. Hier auf den Bildern ist das ganz gut erklärt:

http://www.thetruthaboutcars.com/.../

http://www.thetruthaboutcars.com/.../

[mat619]

Hervorragender Artikel, Danke für die Schreibarbeit!

Da ich selbst mal im Embedded Software Development Bereich (wenn auch nicht Automotive) gearbeitet habe, konnte ich inhaltlich alles soweit nachvollziehen - und stellenweise wurde mir schlecht. Richtig, richtig schlecht. Will lieber gar nicht wissen, was in den Softwarekellern der Steuergeräte anderer Autohersteller da für Leichen liegen.

Über eine fachliche Sache bin ich allerdings gestolpet:

Zitat:

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

Ein CPU-Timer-Tick ist doch nicht unbedingt ein Interrupt, oder haben die einen globalen Timer Tick auf Interrupt Basis realisiert? Das wäre vom Designgedanken (jedenfalls aus meiner branchenfremden Sicht) ja erstmal keineswegs verkehrt.

Außerdem, ein rein timerbasierter Watchdog arbeitet doch eher nicht auf Interrupt-, sondern ganz klassisch auf stupider Pollingbasis... oder verstehe ich das falsch?

In einem Timerintervall die Prozesse mit dem Stock anzustupsen, um zu sehen, ob sie tot sind oder doch noch antworten, ist doch klassisches Polling.

Würden die zu überwachenden Prozesse in einem Timerintervall (oder auf Bedarf vorzeitig, z. B. bei Problemen) einen Interrupt an den Watchdog signalisieren, und dessen Interrupt Handling Routine aktiv darauf reagieren, würde ich von einem Interrupt-basierenden Watchdog sprechen. Dieser Mechanismus wäre auch mitnichten langsam und schwerfällig, da man Interrupthandling ja schön priorisieren kann. Es sei denn, Toyotas Software macht übermäßigen Gebrauch von Interrupts mit zu langen Handlingroutinen und unterscheidet zudem nicht fein genug zwischen der Dringlichkeit...?

[Federspanner40220]

Also mal ganz ehrlich: Wie kann man sowas in C und Assembler programmieren? Sowas ist doch ein Witz.

Für soche Rechenoperationen bietet sich einzig und allein Perl an. Warum? Weil damit die Kursk (versunkenes, russisches U- Boot und erfolgreich geborgen) gehoben wurde. Und weil es die einzige, bewährte und schnelle Programmiersprache ist, die überhaupt schnell genug auf Sensorik-Werte reagieren kann. Wer sowas in C/ Assambler programmiert gehört ausgepeitscht.

[mat619]

Das meinst du nicht ernst, oder?

Assembler ist so nah an blankem Maschinencode, wie es nur geht. Was soll denn noch schneller sein?

Wäre C als Sprache für lebenskritische Embeddedsysteme derart ungeeignet wie du meinst, wären wir vermutlich längst alle tot; gemessen daran, wie weit C in dem Bereich seit jeher verbreitet ist.

[Federspanner40220]

Klar meine ich das im Ernst! Die Sprachen wurden alle, im Zuge der Begung der Kursk, unter die Lupe genommen. Und keine der Sprachen (C+, Assembler...) war in der der Lage die Vielzahl der Kräne zuverlässig symetrisch zu steuern.

Grundbedingung war: Eine einfache , verlässliche Programmierung zu erstellen die in Echtzeit in der Lage ist die vielen sensorischen Daten zu erfassen und darauf in Echtzeit zu reagieren. Kannst du alles im Netz nachlesen!

Letztendlich wurde das Projekt mit PERL zuverlässig und erfolgreich beendet.

Natürlich ist Assembler eine reine Maschinensprache und zur Steuerung (Output) derselben ausgelegt.

Bei C+ hängt vieles vom Programmierer ab wie sicher das Programm ist. Aber wenn es um Sensorik (Input/Output in Echtzeit) geht sind beide nicht zu gebrauchen. Zu langsam, zu fehlerbehaftet und für Echtzeitanwendungen einfach nicht zu gebrauchen.

[mat619]

Zitat:

Natürlich ist Assembler eine reine Maschinensprache und zur Steuerung (Output) derselben ausgelegt.

Warum bitte nur "Output"? Embeddedsysteme, die GPIO Pins haben, besitzen natürlich auch entsprechende Befehle zur Verarbeitung von Input. Sonst wäre die Hardware ja komplett nutzlos.

Zitat:

Bei C+ hängt vieles vom Programmierer ab wie sicher das Programm ist. Aber wenn es um Sensorik (Input/Output in Echtzeit) geht sind beide nicht zu gebrauchen. Zu langsam, zu fehlerbehaftet und für Echtzeitanwendungen einfach nicht zu gebrauchen.

Keine ausgereifte Programmiersprache ist per default fehlerbehaftet, sondern höchstens der Code des Programmierers, der sie verwendet. Daraus ergibt sich auch die Sicherheit der resultierenden Software.

Und Assembler soll zu langsam und nicht für Echtzeitanwendungen zu gebrauchen sein?!

Sehr gute Compiler von Hochsprachen erreichen div. Fallstudien zufolge mittlerweile (im Idealfall, wohlgemerkt) die gleiche Geschwindigkeit wie sorgfältig geschriebener, perfekt effizienter Assembler Code - dieser ist immer noch der Benchmark, an dem sich Compiler messen müssen.

Doch anderhersum "langsamer" oder gar "nicht für Echtzeitanwendungen zu gebrauchen"? Niemals; nur wenn der den Assembler Code schreibende Programmierer sein Handwerk nicht beherrscht!

Mit Assembler kann ich im Gegensatz zu allen anderen Sprachen Daten von Eingangspins direkt aus den Registern des Chips abgreifen, auf einen FIFO-Stack werfen, verarbeiten und direkt in das Register der Ausgabepins schreiben - ohne nennenswerte Zwischenschritte zur Selbstverwaltung. Jede High-Level Sprache erzeugt bei einer solchen Operation etwas Overhead (wenn auch mal mehr, mal weniger) sodass die Latenzen fast immer nach oben gehen.

Während meiner Softwareentwicklungszeit habe ich so etwas mal auf extrem performanter Hardware (einem Texas Instruments DSP Board für Mobilfunkbasisstationen) evaluieren sollen, in Assembler, C und C++. Das Ablaufschema des Testscenarios, dessen Ziel die Verkürzung der Latenzen gegenüber der bisherigen Verarbeitungslogik war, lautete in etwa wie folgt:

1) Lese aktuelle Daten von allen acht AD-Wandlern (an denen Antennenreceiver hingen) und allen vier seriellen Kommunikationsports (Board-to-Board-Communication)

2) Lege diese Daten jeweils auf einem Hive ab

3) Setze das Flush-Bit der Empfangsregister, damit diese derweil mit neuen Werten gefüllt werden können

4) Zerlege die 16 Bit Werte von den Seriellen Ports in 4 Bit Segmente

5) Lege diese nach Segmentursprung geordnet ab

6) Zerlege die 16 Bit Werte der AD-Wandler in 8 Bit Segmente, wobei die upper und lower half von je zwei AD-Wandlern aufaddiert wird

7) Lege diese separat ab

8) Schreibe einen Initialisierungsblock und die gesammelten Segmentwerte je unter Anwendung einer Bitmaskierung, die definiert, welche Daten zu welchem seriellen Ausgang hinausgehen, zu selbigen hinaus, gefolgt von je zwei der 8 Bit Segmente der AD-Wandlerergebnisse plus vordefiniertem Signalisierungsblock zum Ende der Übertragung.

Obwohl der C/C++ Code so sauber wie nur möglich war, lief das Programm in Assembler fast doppelt so schnell!

Perfekt sauber geschriebener Assemblercode ist oft schneller - aber niemals langsamer - als jeder Code, den der Compiler einer High-Level Sprache ausspuckt, und dabei ist es völlig egal ob C, C++ oder Perl. Das Problem ist nur, dass diese Perfektion extrem mühsam zu erreichen ist. Die Nachbildung eines simplen 100-Zeilers an Code in einer Hochsprache, den man binnen 45 Minuten geschrieben und fehlerfrei kompiliert bekommt, kann optimiert in Assembler schlimmstenfalls (je nach Komplexität des Instruction Sets der CPU) bis zu 1-2 Tage dauern. Es ist danach unfassbar effizient, aber zu welchem Preis in puncto Arbeitszeit...

Daher sind solche Vergleichsergebnisse wie das Anwendungsscenario der Bergung der Kursk, auf das du dich stützt, immer unmittelbar vom Können und der Geduld des durchführenden Programmierers, sowie vor den im Rahmen des Projekts veranschlagten Anzahl an Manntagen abhängig.

[Reifenfüller133663]

Oh man hier ist wohl ein Perl Fan dabei?

Perl selbst ist in C geschrieben und ist nur ein Interpreter der Scriptsprache perl. Hier können zahlreiche Fehler dazu kommen für die man als "Schreiber" des Perl Codes gar nichts kann, weil der Interpreter selbst Bugs hat. Siehe dazu zahlreiche Bugfixes von Perl.

Der Vorteil von Perl ist, dass es sehr sehr sehr viel einfacher als Assembler ist und auch deutlich einfacher als C.

Wenn jemand allerdings C oder gar Assembler gut beherrscht, dann sind die beiden Sprachen um Größenordnungen schneller und sogar zuverlässiger als Perl.

[martins42]

Ich kann nur als Perl-Hater dienen.

Ich habe immer wieder mal versucht mein Programmiersprachen-Portfolie damit zu erweitern. Immer wieder zu Weihnachten nehme ich diesen Standard-Schinken denn es da gibt - ist auch schon 20 Jahre alt - und an der Stelle wo dann steht, dass man bei objektorientierten Vorgehen am Ende des Konstruktors das Objekt mit "bless" mit der korrespondierenden Klasse verheiraten muss, feuere ich das Buch in die Ecke.

Das ist rubbish, Scripting-Mist von langhaarigen Unix-Freaks.

Wer Perl einfacher als C findet, hält auch regulärer Ausdrücke für gut lesbar und frisst kleine Kinder.

[Reifenfüller133663]

Ich würde Perl auch nicht für große, objekt-orientierte Programme nutzen. Aber für mal eben schnell als Problemlösung ein bisschen Scripten ist es gut.

Ich fresse auch keine kleinen Kinder