Frage:
Würde ein CD-Laufwerk in einem fahrerlosen Auto ein Sicherheitsrisiko darstellen?
Jake Wickham
2016-10-11 17:18:39 UTC
view on stackexchange narkive permalink

Hacker sind schlau. Könnten sie ein selbstfahrendes Auto durch sein CD-Laufwerk hacken? Soweit ich weiß, könnte bösartiger Code per CD auf das fahrerlose Auto hochgeladen werden, um Zugang zu Bremsen, Scheibenwischern, Sensoren usw. zu erhalten (die alle dazu verwendet werden könnten, möglicherweise einen Mord zu begehen oder das Lösegeld des Autos zu halten) / p>

Jedes System könnte theoretisch von jedem Eingabemittel gehackt werden.Dies bedeutet jedoch nicht, dass das System nicht auf eine einigermaßen sichere Weise implementiert werden konnte.
Oder, wissen Sie, bauen Sie das System einfach so auf, dass der CD-Player von allem, was kritisch ist, völlig getrennt ist?
Die meisten Systeme, die ich gesehen habe, haben normalerweise direkten Zugriff über den SD-Kartensteckplatz, um Karten zu aktualisieren.Ich würde mich mehr darum kümmern als um eine CD.In den meisten Systemen der heutigen Umgebung überspringt der CD-Player alles, was nicht .WAV (Raw) oder ein codiertes Format ist, das er versteht.Das bedeutet nicht, dass es nicht als DOS verwendet werden kann. Ich hatte einen CD-Player in einem älteren Mazda, den wir mit ein paar hunderttausend Dateinamen erstellt hatten, und er würde so hängen bleiben, dass Sie ihn nicht einmal auswerfen könntenScheibe.Ich musste das Laufwerk herausnehmen und die manuelle Auswurfstiftmethode verwenden.
Ein Angriff über einen CD-Player erfordert physischen Zugriff.Ich nehme an, das Sprichwort über den physischen Zugang zu Computern kann auf Autos ausgedehnt werden (fahrerlos oder nicht).
Was ist Ihr Bedrohungsmodell?Ohne ein Bedrohungsmodell können Sie Sicherheitsrisiken nicht messen.Denken Sie bei Ihrem letzten Satz darüber, dass Sie nicht davon überzeugt sind, dass sie in Sicherheit sind, daran, dass Sie möglicherweise morgen früh aus der Tür gehen und von einem Schurken-Müllwagen angefahren werden.Bedeutet das, dass Sie Ihr Haus nie verlassen?Außerdem könnte eine skrupellose Person Ihre Bremsleitungen mit oder ohne CD-Player im Auto durchtrennen.
@CortAmmon Aber mit einem CD-Player im Auto konnte er seine Lieblingsmusik hören, während er die Bremsleitungen durchtrennte.Das wäre angenehmer, also würde er es eher tun.Daher sind CD-Player ein Sicherheitsrisiko.
Warum sollten Sie einen CD-Player in ein fahrerloses Auto stecken?Es würde niemanden geben, der es hören könnte.
@emory Die Passagiere können es hören.
Ist diese Frage nicht etwa 5 Jahre zu spät?CD, wirklich?
Ich würde mir mehr Sorgen um Bedrohungen ohne Zugriff machen, wie zum Beispiel den WLAN-Hotspot im Auto oder das Bluetooth-System.
Ist "Hacker sind schlau" die gesamte Grundlage für Ihr Anliegen?Wäre eine verifizierte Angriffsroute nicht ein besserer Grund für eine Frage?
Siehe [Schutz des ausführbaren Speicherplatzes - Wikipedia] (https://en.wikipedia.org/wiki/Executable_space_protection).Diese Beschreibung ist nicht ganz richtig, aber es gilt das allgemeine Konzept.Moderne Prozessoren und Betriebssysteme erlauben es Anwendungen auf Benutzerebene nicht, Daten auszuführen, die nicht als ausführbar bezeichnet sind.Autos sind nichts Besonderes;Die Konzepte sind die gleichen.Dinge wie Google Play sind wichtig, da sie Daten liefern, die später ausgeführt werden.
Woher wissen Sie, dass das CD-Laufwerk kein vollständig separater Computer mit eigener Stromversorgung ist?Wenn Sie mit diesem bestimmten System hacken können ... dann können Sie entweder über Geräte springen (was an sich schon erstaunlich wäre) oder Sie können irgendwie durch die Macht hacken (auch unglaublich)
@VirtualAnomaly Als CD-Player noch Standard waren, mussten sie * * in alles integriert werden, da System- oder Navigationsaktualisierungen per CD erfolgen mussten.Das System zu entkoppeln war damals keine Option und wird es jetzt wahrscheinlich nicht sein, da die Leute vermutlich in der Lage sein werden, es über das Bordsystem ihres Autos zu steuern.
Sechs antworten:
paj28
2016-10-11 18:42:25 UTC
view on stackexchange narkive permalink

Nicht in einem gut gestalteten Auto

Der CD-Player ist Teil des Mediensystems. Es ist wahrscheinlich, dass das Mediensystem eine Reihe von Sicherheitslücken aufweist und eine schädliche CD möglicherweise die Kontrolle über das Mediensystem übernehmen kann. Es wäre schwierig, dies zu beheben, ohne die Kosten stark zu erhöhen oder deren Funktionalität einzuschränken.

Die Fahrzeugsteuerungssysteme - der CAN-Bus - sollten stark von den Mediensystemen getrennt sein. Bei früheren Angriffen wie Jeep-Hacking konnten Angreifer vom Mediensystem zum CAN-Bus übergehen. Dies stellt jedoch ein schlechtes Design und eine schlechte Implementierung dar. Die beiden Systeme sollten getrennt gehalten werden - oder zumindest eine stark eingeschränkte Schnittstelle haben - und dies ist zu angemessenen Kosten möglich.

Ob zukünftige fahrerlose Autos gut konstruiert sein werden, bleibt abzuwarten.

* "Ob zukünftige fahrerlose Autos gut gestaltet sein werden, bleibt abzuwarten." *
Sie sollten Ihre Antwort auf "Ja, aber bei einem gut gestalteten Auto nicht" ändern.Immer wieder sehen wir, dass diese Art von Hack stattfindet.Ich bin mit diesen Systemen nicht vertraut, aber angesichts der aktuellen Trends bezweifle ich, dass sie einen "Luftspalt" zwischen den Systemen verwenden.
@David - Das war eine Art Punkt im letzten Absatz.Übrigens, Sie möchten wahrscheinlich keinen vollständigen Luftspalt. Es gibt einige Gründe für die Verbindung, z. B. Parksensoren, die über die Stereolautsprecher ertönen.Die Schnittstelle sollte jedoch stark eingeschränkt sein.
Obwohl ich denke, dass dies eine echte Antwort ist, ist es eine Art Tautologie.Wenn ich umschreiben darf: "Der CD-Player ist sicher, solange das Auto so konstruiert ist, dass der CD-Player sicher ist."Alle Autos, die so verbunden sind, dass ein Hacker die Kontrolle übernehmen kann, werden automatisch als "nicht gut designt" gekennzeichnet. Es ist also ein bisschen Betrug.
@CortAmmon - Touché!Fairerweise erkläre ich, wie man es sicher macht, also hoffe ich, dass meine Antwort für jemanden nützlich ist.
Im Chrysler-Hack haben die beiden Systeme _did_ eine stark eingeschränkte Schnittstelle.Aber nicht stark genug eingeschränkt.Siehe [diese Präsentation von DEF CON 23] (https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20video%20and%20slides/DEF%20CON%2023%20Conference%20-%20Charlie% 20Miller% 20-% 20Remote% 20exploitation% 20of% 20an% 20unverändert% 20passenger% 20vehicle% 20-% 20Video% 20und% 20Slides.mp4).
@MichaelHampton: Die geeignete Art der Einschränkung der Schnittstelle wäre der Datenfluss nur in eine Richtung (auf physischer nicht nur logischer Ebene, d. H. Kein Senden von Leseanforderungen oder Flusskontrolle).Obwohl es eine Menge Spionage gibt, die durch das Senden von Fahrzeuginformationen an das Media Center ermöglicht werden könnte, wird es niemals möglich sein, die Kontrolle über das Fahrzeug zu übernehmen.
@BenVoigt - Over-the-Air-Updates sind ein Grund für den Datenfluss von den Medien zur Fahrzeugsteuerung.Ich weiß, dass dies in früheren Hacks gezielt wurde.Es ist jedoch möglich, signierte Updates gut durchzuführen, und die Vorteile von drahtlosen Updates sind erheblich.Außerdem würde ein fahrerloses Auto Routeninformationen benötigen, um vom Media Center zum Autopiloten zu gelangen.
Selbst wenn es in der Software vollständig isoliert ist, müssen Sie auch die Hardware richtig einstellen, sonst wird es auch ausgenutzt.Z.B.indem Sie in der Nähe befindliche medienbezogene Drähte pulsieren lassen, um ein unerwünschtes Signal in Ihrem CAN-Bus oder etwas anderem zu induzieren
Mein Auto verfügt über zwei CD-Laufwerke - eines für Audio-CDs und das andere für Navigationskarten.
@el.pescado Ist das die Werkskonfiguration?Ich frage mich, warum sie nicht einfach einen physischen Schalter hinzufügen, um den Anschluss zwischen Audio- und Navigationssystem umzuschalten.
Ja, das ist die Werkskonfiguration (es ist ein 2007er Opel Vectra).Ich denke, der Grund ist, die Navigation beim Musikhören zuzulassen - also eher Benutzerfreundlichkeit als Sicherheit.
J.A.K.
2016-10-11 17:23:59 UTC
view on stackexchange narkive permalink

Ja, das würde es.

Forscher von der UC San Diego haben tatsächlich einen Angriff über diesen Vektor implementiert:

„Wir haben einen Fehler in einem CD-Player in unserem Auto gefunden ," er sagte. "Sie könnten ein Lied auswählen und es so codieren, dass es gut funktioniert, wenn Sie es auf Ihrem PC spielen. Wenn Sie es jedoch in Ihrem Auto spielen, übernimmt es es."

http://www.sandiegouniontribune.com/news/education/sdut-ucsd-professor-cyber-hacking-2015aug28-story.html

Höchstwahrscheinlich ist dies der Fall durch eine Sicherheitsanfälligkeit bezüglich Speicherbeschädigung in den Metainformations-Tags in der Audiodatei. Dadurch konnten sie wahrscheinlich Befehle an das CAN-System weiterleiten, das das Auto reguliert.

Aber Sie brauchen nicht einmal eine CD; Im schlimmsten Fall kann dies über Mobilfunknetze aus der Ferne geschehen

Angenommen, dies wäre, gelinde gesagt, eine Unannehmlichkeit für den Angreifer ... Vermutlich sind wir in Sicherheit * klatscht *
Mit Ausnahme des Teils über das Hacken aus der Ferne über Mobilfunknetze;
"Würde" ist zu stark."Könnte" wäre korrekter.Es gibt keine Garantie dafür, dass ein CD-Player entweder Schwachstellen aufweist oder mit anderen Subsystemen verbunden ist. Daher ist es falsch zu sagen, dass dies definitiv ein Sicherheitsrisiko darstellt.
Das Verteilen der Medien auf einem Online-Dateifreigabedienst würde dies auch bei einem nicht zielgerichteten Angriff erreichen.
Es stört mich, dass C-Compiler-Autoren die Vorstellung, dass Programme, denen ungültige Eingabedaten gegeben werden, beliebige Ausgabedaten erzeugen dürfen, nicht als alltägliche Anforderung erkennen, aber das Ausgabeformat und andere Verhaltensweisen müssen definiert bleiben.Wenn es Programmierern egal ist, welche Pixel- oder Audio-Samples aus einer ungültigen Datei generiert werden, können die Programmierer unter den oben genannten Einschränkungen nicht nur Sicherheitslücken schaffen, wenn Programmierer dies nicht tun, sondern auch die Leistung beeinträchtigenwenn sie es tun (im Gegensatz dazu, dass Compiler mehr Freiheit haben).
@supercat - Schauen Sie sich [Rust] an (https://www.rust-lang.org/en-US/)
@paj28: Gibt es noch ARM-Cross-Compiler-Unterstützung?Zuletzt habe ich überprüft, dass sowohl D als auch Rust interessante Sprachen zu sein schienen, aber keine ist für mich ohne Unterstützung für die ARM-Cross-Compilation überhaupt nützlich.
@supercat - Ich weiß nichts über Cross-Compiling, aber ARM [wird unterstützt] (https://github.com/warricksothr/RustBuild).Ich denke, Sie können sich auf mindestens einen Raspberry Pi strecken, um Ihre Kompilierung durchzuführen?
@paj28: Cool.Auf der Seite, die Sie zuvor auf den ersten Blick verlinkt haben, schienen nur PC-bezogene Downloads verfügbar zu sein.Ich muss sehen, ob Rust für ARM machbar ist.
@paj28 "Threads ohne Datenrennen"?Also erlaubt Rust keine gemeinsamen Variablen?
@JAB - Ich kenne die Details nicht, aber [dieser Blog] (http://manishearth.github.io/blog/2015/05/30/how-rust-achieves-thread-safety/) sieht interessant aus
@paj28 Okay, Rust hindert Sie nicht daran, Rennbedingungen einzuführen, wenn Sie es wirklich versuchen. Es bietet nur bessere Tools, um diese zu vermeiden.
@supercat: Ein C-Compiler konnte möglicherweise nicht die Last übernehmen, das "Ausgabeformat und andere Verhaltensweisen" für fehlerhafte Programme beizubehalten.Selbst um herauszufinden, welches Ausgabeformat das richtige ist, müsste der Compiler die Gedanken des Programmierers lesen.Selbst weitaus sicherere Sprachen wie Rust oder Haskell können diese Garantie nicht übernehmen.
@supercat Der Compiler kann eine Funktion so kompilieren, dass er ungültige Ausgabedaten bei ungültigen Eingabedaten ohne weitere Nebenwirkungen erzeugt.Die Ausgabe dieser Funktion wird dann jedoch als Index für eine Tabelle mit Funktionszeigern verwendet, wodurch beispielsweise die Funktion "send_command_to_engine" anstelle der Funktion "play_music" aufgerufen wird.
@immibis: Bei vielen Arten der Programmierung muss nachverfolgt werden, welche Daten bereinigt wurden und welche nicht.Compiler hatten traditionell zugelassen, dass viele Operationen mit nicht bereinigten Daten sicher durchgeführt werden konnten, ohne sie zuvor zu bereinigen, vorausgesetzt, dass die Ergebnisse dieser Operationen als unanitisiert behandelt wurden.Was Killer ist, ist, dass Compiler beobachten, dass der Compiler, da ein Teil des Codes x << y berechnet hat (in einem Szenario, in dem die Ausgabe als nicht bereinigt betrachtet wird), an anderer Stelle `if (y <40) -Funktionen [y] (was auch immer) übernehmen kann.; `und lassen Sie die Bereichsprüfung aus, da y" nicht "über 32 sein kann.
@user2357112: Die Anforderungen für viele reale Programme umfassen einige Teile, die für alle Eingaben erfüllt werden müssen, und einige, die nur für gültige Eingaben erfüllt werden müssen.Wenn eine Funktion "int32a * int32b
... die Berechnung entweder durch Berechnen eines 32-Bit-Produkts und Vorzeichenerweiterung, Berechnen eines 64-Bit-Produkts und direktes Verwenden oder durch alles andere, was in Fällen funktioniert, in denen das Ergebnis in ein 32-Bit-Int passt"und ergibt in allen anderen Fällen eine 0 oder 1?Mein Punkt ist, dass Programmierer die Möglichkeit haben sollten, Grenzprüfungen in Fällen zu verwenden, in denen sie die Aktionen des Programms beeinflussen sollten, und sie in Fällen wegzulassen, in denen dies nicht erforderlich sein sollte, ohne dass Compiler das Weglassen von Grenzprüfungen in einigen Fällen als Aufforderung behandeln, sie wegzulassenaus allen Fällen.
pjc50
2016-10-12 01:59:48 UTC
view on stackexchange narkive permalink

Egal, welcher CD-Player, Ihre Reifen verschwören sich gegen Sie

"Sicherheitslücken in drahtlosen Netzwerken im Auto: Eine Fallstudie zum Reifendrucküberwachungssystem"

Wir haben auch festgestellt, dass aktuelle Implementierungen offenbar nicht den grundlegenden Sicherheitspraktiken entsprechen. Nachrichten werden nicht authentifiziert und das Fahrzeug-Steuergerät scheint auch keine Eingabevalidierung zu verwenden. Wir konnten gefälschte Meldungen einspeisen und die Warnleuchten für niedrigen Reifendruck bei einem Auto aufleuchten, das mit Autobahngeschwindigkeit von einem anderen nahe gelegenen Auto aus fährt, und es gelang uns, die TPMS-ECU zu deaktivieren, indem wir die Paket-Spoofing-Funktion zum wiederholten Ein- und Ausschalten von Warnleuchten nutzten. P. >

MSalters
2016-10-12 01:21:36 UTC
view on stackexchange narkive permalink

Ich spreche aus persönlicher Erfahrung hier, keine Chance für Schneebälle in der Hölle.

Ich war Teil eines Teams, das 2008 einen völlig neuen Gerätestapel für ein Infotainmentsystem für die Automobilindustrie geschrieben hat. Vor einiger Zeit Aber selbst dann haben wir die entscheidende Notwendigkeit verstanden, unseren Software-Stack zu schützen.

Unser Problem wurde verschlimmert, weil das System unter Linux lief (und läuft). Und wir haben die GPL 2-Bedingungen vollständig eingehalten, was bedeutet, dass Sie einen selbst entwickelten Code eingeben können und das Auto dies akzeptieren würde.

Dies war jedoch ausdrücklich kein Sicherheitsrisiko, da das Auto ein digitales Signatursystem verwendet. Ihr eigener Code würde ausgeführt, aber das Auto weigerte sich einfach, mit Ihrer Software zu sprechen. Und es hörte sowieso nicht zu - das Infotainmentsystem hatte bestenfalls schreibgeschützten Zugriff auf einen kleinen Satz von aufgezählten Datenelementen wie die Fahrzeuggeschwindigkeit.

Ich weiß, dass unser System zu dieser Zeit auf dem neuesten Stand der Automobiltechnik war und der bereits erwähnte Jeep-Hack später stattfand. Das ist nicht wirklich überraschend. Es gibt einiges an Vermächtnis, Neugestaltungen von sauberen Blättern sind nicht so üblich. Jeep ist natürlich eine kleine Marke eines kämpfenden Unternehmens, daher ist es keine große Überraschung, dass sie hinterherhinken. Aber das wäre keine Marke, von der man erwarten würde, dass sie zuerst ein fahrerloses Auto produziert - die Hauptverdächtigen würden gesündere Unternehmen (könnte Mercedes sein, könnte Toyota sein und natürlich Tesla)

Betreff: "Keine Schneeballchance in der Hölle".Das OP fragte nicht nach "Ihrem CD-System", ich denke, sie meinten jedes System.Sie scheinen dann Ihren Kommentar zu widerlegen, indem Sie Fälle auflisten, in denen Probleme aufgetreten sind, und diese abweisen, als gäbe es in der fahrerlosen Autoindustrie keine solchen Unternehmen.Während ein System zwar sicher ist, ist es nur gegen die Dinge sicher, vor denen die Entwickler schützen konnten.Ich hoffe, Ihr Prozessor wurde nicht in China gebaut, sonst wer weiß, welche Hintertüren darauf warten, genutzt zu werden.
War Ihr Sicherheitsmodell dazu da, die Fahrzeugsteuerungs- und Infotainmentsysteme zu verbinden und das Infotainmentsystem zu härten?Klingt so, als hätten Sie die Sicherheit ernst genommen, aber ich denke immer noch, dass dies ein riskantes Design ist.Die Perimeter-Angriffsfläche ist massiv und enthält vermutlich Dinge wie MP3-Decoder, die eine hohe Leistung benötigen.
Ich würde @paj28 zustimmen - "keine Chance für Schneebälle in der Hölle" ist eine ziemlich harte Behauptung.Digitale Signaturen hängen von Kryptographie-Implementierungen ab, und Krypto-Algorithmen selbst werden mit der Zeit als schwach und ausnutzbar befunden, ganz zu schweigen davon, dass ihre Implementierungen häufig auch Fehler aufweisen.Dann gibt es alle Seitenkanalangriffe (wie Timing-Angriffe) usw. Der schreibgeschützte Zugriff kann möglicherweise auch zum Schreiben über Fehler (z. B. in Zugriffskontrollen selbst - wie Kernel, Hypervisoren) oder in der Hardware selbst (erinnern Sie sich an Rowhammer?) Ausgenutzt werden.
@Dunk: Angesichts der Tatsache, dass der Prozessor nur signierte Kernel booten musste und es sich um ein Automobilprodukt handelt, können Sie davon ausgehen, dass es sich nicht um ein zufälliges chinesisches Bit handelt.Ja, dort ist ein Sicherheitsmodul "vor dem Betriebssystem versteckt" - das ist der ganze Grund, warum wir die digitale Signatur erzwingen können.
@paj28: Das Modell sollte das Infotainmentsystem nicht "härten".Das Modell sollte es standardmäßig als kompromittiert betrachten - wer weiß, welche Art von nicht signiertem Code es möglicherweise ausführt?Bis auf die Treiber war die gesamte Kernelquelle verfügbar.Dies verengt die Angriffsfläche erheblich.
@MatijaNalis: Tatsächlich wird der Code nicht einmal ausgeführt, wenn die Signaturen überprüft werden, und der gesamte Prozess der Signaturprüfung ist nicht beobachtbar (tief eingebettet).Das ist keine Sicherheit für sich, aber jeder mit dem erforderlichen physischen Zugriff kann einfach zusätzliche Hardware ersetzen oder hinzufügen.
@MSalters-The Die US-Regierung erlaubt nicht einmal, bestimmte hochkritische Arten von Produkten für sie zu bauen, deren Teile aus diesem Grund in China hergestellt wurden.Die digitale Signatur kann nicht helfen, zu erkennen, dass der Hersteller dem Silizium zusätzliche Transistoren hinzugefügt hat, mit denen Mechanismen ausgelöst werden können, mit denen das System ausgenutzt werden kann.
@Dunk: Das Gute ist, wenn Sie jährlich eine Million Chips für eine Anwendung mit relativ geringem Risiko kaufen, hat der Anbieter einen guten Grund, Sie nicht zu verarschen.Das Problem der US-Regierung ist, dass sie 1000 Chips für Anwendungen mit hohem Risiko kaufen.
0x1gene
2016-10-12 20:33:08 UTC
view on stackexchange narkive permalink

Sicherheit bei selbstfahrenden Autos wird zu einem Trendthema, da Autos immer mehr Software erhalten.

Je mehr Code und Hardware vorhanden sind, desto exponierter ist das System, da die Angriffsfläche größer ist. Das heißt, ich würde mir keine Sorgen um das CD-Laufwerk machen. Das neueste selbstfahrende Auto wird mit dem Internet verbunden, um verschiedene Daten zu erhalten (Wetter, Verkehr, Musik streamen, Synchronisierungskalender usw. usw.). Wenn eine Auto-CD ins Visier genommen würde, wäre eine CD keine gute Wahl, und wie Sie sagten, sind Hacker klug, sodass sie wahrscheinlich auf modernere und offenere Türen zur Außenwelt abzielen.

Das heißt, lassen Sie uns Stellen Sie sich vor, Ihr CD-Laufwerk ist im Fluss: Der Hacker müsste Sie dazu bringen, einen Song herunterzuladen, ihn auf eine CD zu brennen und dann hoffen, dass Sie ihn auf Ihrem selbstfahrenden Auto abspielen. Wenn Sie also nicht zwielichtig herunterladen Dateien ist für sie im Grunde unmöglich und definitiv nicht die Mühe wert ...

Eine letzte Sache, die hinzugefügt werden muss, ist, dass das Lied selbst dem Auto somme Sprachbefehle geben kann, wenn es kompatibel ist ( wie was Sie haben für Telefone getan). Auch hier müsste man den Song von einer zwielichtigen Quelle beziehen, und dies erlaubt nicht, etwas zu tun, das nicht für die Verwendung mit der Sprachschnittstelle ausgelegt ist. Es ist also ziemlich unwahrscheinlich, dass ein Song Ihrem Auto sagt, dass es kaputt gehen soll ...

Aus der Sicht der Entwickler denke ich, dass selbstfahrende Autos nicht 100% kugelsicher sind, aber sie werden es tun (und sind es bereits) viel viel sicherer als von Menschen betriebene Autos. Dies liegt nur daran, dass ein Computer eine kürzere Reaktionszeit hat, niemals betrunken, schläfrig oder abgelenkt ist und viel mehr Sinne hat. Wenn Sie sich auf ein optisches Sichtfeld von 200-220 ° verlassen, kann sich der Computer auf ein 360-Grad-Kamerasystem verlassen, das mit Fernradargeräten, Näherungssensoren usw. gekoppelt ist.

Seien wir ehrlich, wenn wir eine Rakete starten Es wird von einem Computer betrieben, nicht von einem Menschen. Dafür gibt es einen Grund.

Ich hoffe, es hat Ihnen geholfen, die Risiken besser zu verstehen und weniger Angst vor selbstfahrenden Autos zu haben.

Ich hätte ziemlich Angst vor einem fahrerlosen Auto, das von einem Computer mit einer ** langsameren ** Reaktionszeit gesteuert wird.Du meinst entweder schneller oder kürzer.
@AnthonyGrist ahah wahr das!Ich meinte kürzer danke :)
Wenn wir ein Flugzeug fliegen, wird es aus einem bestimmten Grund von einem Computer betrieben.Wenn wir ein Flugzeug landen, ist es nicht.
@WilliamKappler Sowohl Boeing als auch Airbus haben Computer-Landeflugzeuge (Wortspiel beabsichtigt) gesteuert.sowie kompletten Computerflug.Flug oder Bootfahren sind für einen Computer möglicherweise einfacher als der Bodentransport.
MikeP
2016-10-13 00:57:21 UTC
view on stackexchange narkive permalink

Wenn es mit den Systemen verbunden ist, die das Auto betreiben, ist alles möglich.
Wenn es nicht verbunden ist, z. es ist ein Discman, dann nein.



ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...