Ford+VW: Argo AI - Robotaxi-Startup eingestellt

Brauchst Du nicht, es reicht, den Code auf dem Weg in die CPU oder bei der Vararbeitung in der CPU zu beeinflussen:

Und: EPROM und Maskenrom ist tot - Maskenrom gibt es maximal noch für on-chip-Bootloader, nahezu alles andere ist heute Flash. Wie will man sonst nach der ersten Auslieferung funktionierende Software nachliefern? ;-)

cu Michael

Das bedeutet ja, daß jede komplexe Software fehlerbehaftet sein _muß_!

Das liegt daran, daß fast alle Protagonisten irgendwie von den Hackern traumatisiert und in der Folge konditioniert sind. Dies wiederum liegt daran, daß die wenigsten Jahrzehnte lang komplexe Software entwickel(te)n.

Und die beliebig in allen Fällen verfahren kann, die nicht in den Anforderungen stehen. Das verschiebt den Test auf Fehlerfreiheit zur Spezifikation, die alle zu vermeidenden Fehler aufzählen müßte.

Abgesehen davon ist erfahrungsgemäß der einfachste Weg zu einem unbrauchbaren Programm die genaue Einhaltung der Spezifikation. Das macht dann garantiert keine Fehler, aber üblicherweise auch sonst nichts brauchbares.

Er *könnte*, wenn er einen Dummen fände, der so einen Auftrag annimmt. Möchtest Du der erste sein? Bis zu welchem Betrag der Vertragsstrafe könntest Du für die Fehlerfreiheit haften?

Es sollte eigentlich allgemein bekannt sein, daß die *Abwesenheit* von irgendwas nicht mit Sicherheit feststellbar ist. Dies gilt auch für die Abwesenheit von Fehlern. Wer das Gegenteil fehlerfrei beweisen kann bekommt den nächsten Nobelpreis etc.

Aber vielleicht hat ja schon ein Mathematiker bewiesen, daß der Beweis von Fehlerfreiheit unmöglich ist, z.B. Turing mit dem Halteproblem...

DoDi

Du mußt das ROM bzw. dessen Code nicht permanent verändern. Es reicht möglicherweise schon, die Programmausführung eines Microcontrollers einmal etwas aus der Bahn zu schubsen. Preisfrage: Wann "rebootet" denn so ein Kfz-Steuergerät typischerweise? Tip: Klemmenwechsel ist es schonmal nicht. Daher auch die Angst gewisser Regulars, lieber nicht die Batterie länger vom Bordnetz zu trennen.

Volker

Ja, und damit mehr als man meist hat. Solche Angriffe werden durchgeführt weil der Hersteller was verbergen will. Remote-Angriffe hingegen weil man Daten des Users rankommen will.

Ja, eben... zur Zeit von Masken-ROMs musste man sich bei der Programmierung noch Mühe geben. Selbst mit EPROMs war das noch nötig. Heute kann man Software behandeln wie Bananen, grün ausliefern und beim Kunden reifen lassen.

Gerrit

Nein, der Schluss ist falsch. Sie kann natürlich fehlerfrei sein. Aber das zu beweisen ist das Problem.

Dazu kommen noch mögliche Fehler im Compiler. Dein Sourcecode ist fehlerfrei, aber das was der Compiler draus macht nicht mehr.

Gerrit

Und welcher Teil des Steuergerätes rebootet? Das ist nicht nur ein µC drin zu finden.

Gerrit

Weniger oft als Menschen am Steuer die noch nicht mal Zeit haben eine Aktion einzuleiten.

Wenn nicht ist es schon so nah dran dass ein Mensch mit seinem starken Trieb was zu Retten noch nichts tun kann weil einfach die Reaktionszeit nicht kurz genug ist.

Dann ist es die Moral Machine die in diesem Fall sagen muss dass Ausweichen nach links wegen Gegenverkehr nicht gemacht werden sollte, waehrend sie ohne Gegenverkehr evtl Ausweichen anordnet sofern es moeglich ist ohne das Fahrzeug und / oder andere zu gefaehrden.

Dann bedeutet das dass der Abstand schon kleiner ist als 12.5m, da wuerde ein menschlicher Fahrer die Frau mit voller geschwindigkeit erwischen ohne etwas dagegen tun zu koennen. Das automatische Auto waere aber durch die Vollbremsung schon deutlich langsamer, das verbessert ihre Ueberlebenschance. Selbst wenn kein Gegenverkehr ist, koennte das Ausweichen unangebracht sein, siehe Elchtest.

Google koennte aus den Positionsdaten der Smartphones jede Umleitung die befahren wird erkennen und in eine digitale Karte eintragen, schon heute.

Wenn nicht muss ein Angestellter kommen und das Fahrzeug abholen, das kommt gelegentlich vor.

Helmut Schellong schrieb:

Nirgends sind Prognosen dermassen falsch (gewesen), wie auf dem Gebiet des Computing.

Ahnung vom Thema hilft da auch nichts.

Hallo Rupert,

Du schriebst am Tue, 20 Dec 2022 09:10:04 +0100:

Mit ausreichendem Aufwand schon. Dann verlagert sich das Problem aber auf den Bereich, der von den Anforderungen nicht abgedeckt ist. In dem "darf" sich diese Software dann beliebig undefiniert verhalten, weil das Verhalten dafür ja nicht festgelegt ist. Und das kann dann, wenn's dumm geht, auch die reguläre Benutzung beeinträchtigen.

...

Und damit sind wir wieder beim vorgenannten Gödel-Theorem.

...

an Geldmitteln zum Beschaffen, Erlernen und - neben dem für den avisierten Zweck Benutzen auch noch - Sicherstellen der korrekten Funktion der Software zur Überprüfung der erstellten Software, und

Als von der benutzten, evtl. vorgegebenen, Prüf-Software als sicher fehlerfrei deklarierten Software.

Was bei ein paar bis hunderte Millionen Programmzeilen für sog. "automotive Software" schon in die Größenordnung von 1€/Zeile oder gar darüber gehen kann.

Geht ganz einfach nicht. Denn da sind ja auch sämtliche denkbaren Verkettungen unglücklicher Umstände zu berücksichtigen.

Die Brownsche Molekularbewegung kennst du vermutlich. Betrachtest du einen Kubikmillimeter Luft, wirst du feststellen, dass sich die Luftmoleküle in diesem Kubikmillimeter öfters mal in eine bestimmte Ecke dieses Volumens verdrücken. Sowas kann grundsätzlich auch in großen und sehr großen Volumen passieren. Nun stelle dir mal einen Kubikmeter Luft vor. Du wirst lang drauf warten können, bis sich mal sämtliche Moleküle in eine Ecke des Volumens verziehen. Denkbar ist es. Aber halt extremst unwahrscheinlich. Ist der Fall also zu berücksichtigen?

Helmut Schellong schrieb:

Viele Fahrer überschätzen sich. Besonders in Kurven.

Der Mensch kann nicht alles und das, was er kann, nicht immer. Und er macht Fehler. Die Maschine auch, auch die muss man erst erziehen. Soweit möglich.

Ich habe vor vielen Jahren mal einen Bericht von Testfahrern eines deutschen Premium-Herstellers gelesen. Die Fahrer müssen oft sehr eintönige respektive repetitive Runden auf der hauseigenen Test/ Rennstrecke absolvieren.

Einer berichtete, wie bei einer langen Nachtfahrt plötzlich die Strasse gesperrt war. Er konnte aber locker rechtzeitig anhalten. Günstig war das grosse, stark selbstleuchtende Schild mitten auf der Fahrbahn. Nachdem er erst mal Luft geholt hat, klärte sich das Bild: Der Mond war aufgegangen. Im Nachhinein konnte er sich nicht erklären, warum er das nicht gleich erkannt hatte.

Ein anderer Fahrer hatte ein ähnliches Erlebnis, tagsüber. Da war die Fahrbahn auch plötzlich gesperrt, mit etwa acht weissen Fässern quer über die Fahrbahn. Auch er konnte rechtzeitig anhalten. Danach sah es so aus, als würden die Fässer langsam umkippen. Schliesslich sah er den Zebrastreifen, der schon immer da war.

Tausend mal ja, dann hakt es plötzlich aus. Ich frage mich, ob bei der KI ähnliches passiert, wäre interessant. Wie der Effekt, ob Gewohnheit abstumpft.

Christoph Müller schrieb:

Das ist der Standard-Spruch der Manager. Das mag auch gelten für die Blumentopffabrik Kötzschenbroda. Fällt da einer am Fliessband aus, wird ein neuer fliegend angelernt.

Hier geht es aber um leading edge top notch beyond state of the art etc. Software. Da darf man nicht so denken. Geht der beste Programmierer zu Google, ist die Abteilung tot. Coder sind eher ersetzbar.

Theoretisch gibt es keinen Unterschied zwischen Theorie und Praxis....

Was die Manager auf ihren Symposien¹ so alles lernen...

Hallo Helmut,

Du schriebst am Tue, 20 Dec 2022 00:32:21 +0100:

Wobei allerdings auch neue Maschinen Defekte enthalten können, aus unterschiedlichsten Ursachen.

Beweise das Gegenteil, widerlege Gödel.

Und? Das gibt höchstens 4 Millionen weitgehend widersprüchlicher Sonderbehandlungen.

Dann ist das Projekt schon tot.

Diese Software ist aber allein für sich zu keiner Funktion fähig. Sie _BENÖTIGT_ eine ausführende Hardware, und üblicherweise stützt sich ihre funktion sogar auf eine bestimmte Ausführung dieser ab.

Inkonsistent - hier definierst Du "Maschine" als Software, oben schlossest Du genau das aus und wolltest den Begriff nur für die hardware verwendet sehen.

Was ausschließt, daß sie eine Wirkung in der physischen Welt ausüben kann.

Nehme zwei beliebige, miteinander interagierende Programme und weise das für beliebige Abfolgen ihrer Befehle nach. Wenn Du damit Deine Behauptung belegen kannst, kannst Du recht haben, Genaugenommen müßte das aber für _alle_ _Kombinationen_ solcher Programme gemacht werden. Solche Konstellationen sind bei komplexen Systemen, wie z.B. den "autonomen Autos", der Regelfall. Und da arbeiten nicht nur zwei interagierende Programme parallel (pseudo.-parallel wie beim "klassischen" Multitasking oder richtiggehend asynchron als separate Maschinen oder Multi-CoreProzessoren), sondern richtig viele.

In einem engbegrenzten Rahmen, gegeben durch Spezifikationen, deren Vollständigkeit, Widerspruchsfreiheit und Korrektheit wiederum separat sichergestellt werden müßte. (Schönen Gruß von Herrn Gödel, R.I.P.)

"Testen kann nur die Existenz von Fehlern nachweisen, niemals deren Abwesenheit".

Mit Zylinderlinsen kann man mit EINEM Laserstrahl die ganze Szenerie ausleuchten.

Licht auch.

Vgl. Immersionsöl in der Mikroskopie. Soo abwegig ist der Gedanke nicht.

Gerrit Heitsch schrieb:

Du meinst, beim Start des Projekts war es ahnbar, dass a) für die erkennbaren Probleme noch keine Lösungen fixfertig sind und dass b) noch weitere Probleme auftauchen könnten?

Nun, das ist ja die Definition von "Projekt". Ansonsten wäre es ein Vorhaben. Plan B muss halt zwingend vorhanden sein. Dem Kunden muss das klar kommuniziert werden, insbesondere was mit "geplantem Fertigstellungsdatum" gemeint ist.

Es kommt auch drauf an, was das Projekt überhaupt betrifft. Wenn wirklich was neuartiges angestrebt wird, womöglich Richtung KI, ist nichts sicher. Statistiken über IT-Projekte wurden hier ja schon gezeigt.

Offenbar ist es so, dass in der IT immer wieder die gleichen Planungsfehler gemacht werden. Auch und gerade von Firmen mit angeblich jahrzehntelanger Erfahrung.

Kommt vor, ja. Wird aber ungerne gehört.

Könnte unter anderem daran liegen, daß man die falschen Leute fragt wie lange es dauern wird.

Gerrit

Dann wird die Auswertung komplexer, denn du musst ja, damit du von LIDAR was hast, nicht nur die Entfernung messen (über time of flight) sondern auch die genaue Richtung kennen aus der das jeweilige Echo kommt. Bei einem LIDAR mit mechanischem Scanner ist das einfach.

Einen Blinker möchte man hingegen innen eher trocken haben.

Gerrit

"per Stichproben beweisen"? Echt?

Hatten wir diese Diskussion nicht schonmal?

Thomas Prufer