|
Anzeige
|
Embedded-Linux im Automotive-Bereich
Gast
#4195389
Hallo, mich würde mal interessieren, ob Linux bereits im Automotive-Bereich eingesetzt wird und ob es bereits praktische Einsatzmöglichkeiten dafür gibt? Bei Google finde ich vieles zum Infotainment aber wären auch klassische Steuergeräte (ABS, Body-Controller etc.) durch Linux ersetzbar???
Gast
#4195391
Nein wären/sind sie nicht.
Gast
#4195405
im Multimedia Bereich ist es durchaus verbreitet und wird auch benutzt. Nicht nur embedded Linux,siehe dazu http://www.dragtimes.com/blog/tesla-model-s-ethernet-network-explored-possible-jailbreak-in-the-future "Klassische Steuergeräte" mit Sicherheit nicht, weil: - Linux zu inperformant, selbst mit Echtzeiterweiterung - du bei "klassischen Steuergeräten" ein Echtzeitbetriebssystem brauchst (OSEK) - du in der Regel OS und Applikation statisch zusammen kompilierst -> das alles wird mit Linux nix Linux hat seine Stärken im Netzwerk und einer Interaktion mit Benutzern - das ist nicht das, was man sich für eine z.B. Motorelektronik wünscht bzw. brauchen kann. Hier ist beinharte Echtzeit gefragt und direkter Zugriff auf Sensoren und Steuerausgänge - von Sicherheit und Plausibilitätsprüfungen mal ganz abgesehen. Ist Linux nach ASIL D? https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level Irgendwo auf einer Mailingliste las ich mal was über "Linux-AP" (Automotive Products), wo daran gearbeitet wurde, dass auch in kritischen Bereichen einzusetzen. Finde ich gerade nicht mehr, wurde wahrscheinlich fallengelassen. Warum nicht Linux: - Hat nicht die Ausfallsicherheit im Kernel (Mirroring von kritischem Zeug etc) - Hat keine harte, garantierte Echtzeit - Riesige Codebase, wahrscheinlich viel zu teuer für die Audit und Zertifizierungsprozesse - Viel zu mächtig - Viel zu groß (in ECUs arbeiten kleine Prozessoren / große Mikrocontroller, Größenordnung ein paar dutzend MHz, paar dutzend kB RAM)
Gast
#4195431
Marian B. schrieb: > (in ECUs arbeiten kleine Prozessoren / große > Mikrocontroller, Größenordnung ein paar dutzend MHz, paar dutzend kB > RAM) sind schon ein paar duzend mehr: ein aktueller in Serie befindlicher Prozessor TC1783 hat 200 MHz. Der neueste Schrei sind Infineon Aurix Prozessoren. 3 Kerne * 200MHz, 8MB Flash 2,7 MB RAM. http://www.infineon.com/cms/en/product/microcontroller/32-bit-tricore-tm-microcontroller/aurix-tm-family/aurix-tm-family-%E2%80%93-tc29xtx/channel.html?channel=db3a30434422e00e014426454e2b3d81 Gruß Anja
Gast
#4195572
Tach, Marian B. schrieb: > Irgendwo auf einer Mailingliste las ich mal was über "Linux-AP" > (Automotive Products), wo daran gearbeitet wurde, dass auch in > kritischen Bereichen einzusetzen. Finde ich gerade nicht mehr, wurde > wahrscheinlich fallengelassen. > Eher nicht: https://www.automotivelinux.org/ Da tut sich momentan einiges, es gibt auch schon längst die Zertifizierung für Multimedia/Front-End controller. Einige Kamera- und Sensorik-Lösungen im Automotive-Bereich basieren sogar auf uClinux (ohne MMU also). > > Warum nicht Linux: > - Hat nicht die Ausfallsicherheit im Kernel (Mirroring von kritischem > Zeug etc) Das ist oft nicht mal die Anforderung. Harte und kritische Steuerungen macht man eh mit FPGAs, da sind die Zertifizierungsprozesse einfacher. > - Hat keine harte, garantierte Echtzeit Hat es inzwischen, man kann sich einiges aussuchen (Preempt, Xenomai, ..). Wenn garantierte Latenz im uS-Bereich (je nach Interface) reichen... > - Riesige Codebase, wahrscheinlich viel zu teuer für die Audit und > Zertifizierungsprozesse Offenbar hat sich das wer angetan :-) Aber hat was, der Code ist ein Chaos, ich finde es sinnvoller, RTEMS oder ähnlich etablierte Systeme aufzubohren. > - Viel zu mächtig > - Viel zu groß (in ECUs arbeiten kleine Prozessoren / große > Mikrocontroller, Größenordnung ein paar dutzend MHz, paar dutzend kB > RAM) Auch nicht mehr so ein Thema, wo das RAM nix mehr kostet. Automotive von heute kann sich sogar leisten, sich eine Chipvariante exklusiv zu konfigurieren (so konkret beim oben genannten Multimediasystem geschehen). Anja schrieb: > Der neueste Schrei sind Infineon Aurix Prozessoren. > 3 Kerne * 200MHz, 8MB Flash 2,7 MB RAM. > Soll wohl mal wieder Antiwerbung für Infineon sein? Tut mir leid für die böse Kritik, aber das TriCore-Zeug ist einfach nur "broken by design" verglichen mit Blackfin oder MIPS. Fitzebutze schrieb: > Anja schrieb: >> Der neueste Schrei sind Infineon Aurix Prozessoren. >> 3 Kerne * 200MHz, 8MB Flash 2,7 MB RAM. >> > > Soll wohl mal wieder Antiwerbung für Infineon sein? > Tut mir leid für die böse Kritik, aber das TriCore-Zeug ist einfach nur > "broken by design" verglichen mit Blackfin oder MIPS. Dann nenne doch bitte Alternativen in Form von tatsächlich erwerbbaren, automotive tauglichen Prozessoren mit den entsprechenden Funktionseinheiten um den Anforderungen der Steuergeräte (z.B. MSG, GSG, ESC etc.) gerecht zu werden. Ach ja, und bitte kein JDP (FreeScale / ST) - die haben bereits erfolgreich bewiesen, dass sie es noch viel weniger hin bekommen... Fitzebutze schrieb: > Eher nicht: https://www.automotivelinux.org/ Haben die sich einfach umbenannt, kein Wunder, dass ich da nichts gefunden habe. Danke! :) Die Frage nach einem "richtigen" Betriebssystem stellt sich bei solchen Steuergeräten eigentlich nicht, denn die brauchen kein Dateisystem oder Ähnliches. Bei solchen Steuergeräten hat man in aller Regel nur ein paar Regler laufen, plus jede Menge Code um verkorkste Busprotokolle zu sprechen. Ein "richtiges" Betriebssystem mit Dateisystem, nachladbarem Code und Hardwareabstraktion bringt einem da in aller Regel keine Vorteile. Deshalb beschränkt man sich da auf relativ simple "Taskswitcher" welche mehrere gleichzeitige Ablauffäden erlauben oder schreibt gleich alles direkt. Antwort schreiben |
Anzeige
|
