1. Foren
  2. Kommentare
  3. Sonstiges
  4. Alle Kommentare zum Artikel
  5. › Media Control Unit: Totgeschriebener…

Design Fail

  1. Thema

Neues Thema Ansicht wechseln


  1. Design Fail

    Autor: /mecki78 23.10.19 - 12:55

    Bei einem Auto, egal ob einem Stromer oder einen Verbrenner, ist grundsätzlich immer Strom vorhanden, wenn man mal davon absieht, dass die Sicherung durchbrennen kann, denn jedes Auto hat einen Akku und der fällt nicht einfach mal so auf 0% Ladung. Sollte der Akku schwach und kurz vor dem Ende stehen, dann merkt das ein Auto und zeigt das ja dem Fahrer an (selbst vor 40 Jahren hatten Autos ein Lämpchen dafür).

    Deswegen ist es nicht nötig Logs direkt in statischen Speicher zu schreiben. Logs sollten bei Embedded Systemen immer zuerst nur in RAM geschrieben und dann auch im RAM komprimiert werden und nur wenn eine bestimmte Menge an Daten erreicht wurde (das System hat ja begrenzt RAM) oder im Falle bestimmter Ereignisse, sollten dann die komprimierten Logs einmalig in statischen Speicher geschrieben werden, damit sie nicht verloren gehen, sollte doch mal jemand den Akku abklemmen oder eine Sicherung ziehen. Bei einem Auto wäre so ein Ereignis z.B. wenn man den Wagen abstellt.

    RAM ist nicht so teuer, man kann auch Embedded Systeme mit ein paar GB RAM bestücken. Ich meine, wir sprechen hier von Autos, die 90'000¤ und mehr kosten! Und das bringt extrem viel, weil schreibt man nur komprimierte Logs, dann werden von Haus aus viel weniger Daten geschrieben und außerdem gibt es auch so viel weniger Schreiboperationen, da SSD immer nur ganze Speicherzellen schreiben kann, d.h. auch wenn ich nur ein paar Byte in so eine Zelle schreiben will, dann muss die SSD die ganze Zelle in ihren Cache lesen, dort verändern, dann die alte Zelle im Flash löschen und den geänderten Inhalt in eine neue Zelle schreiben. Das gleiche passiert dann wieder für die nächsten paar Bytes, die ich dran hänge, usw. Bei einem Log kann so eine Zelle am Ende 10x geschrieben worden sein, schreibt man nur fertige Logs, dann wird sie hingegen nur genau einmal geschrieben.

    /Mecki

  2. Re: Design Fail

    Autor: gadthrawn 23.10.19 - 13:21

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > RAM ist nicht so teuer, man kann auch Embedded Systeme mit ein paar GB RAM
    > bestücken.

    Ja. 8 GB sind ja bei den ausfallenden Systemen schon drin. Jetzt stell dir vor, dass das System jede Bedienung abspeichert, gewechselter Sender, Multimedia etc.pp.
    Warum außer vielleicht zu Debugzwecken? Auf der Strasse eher overkill... egal ob 8 oder 32 GB Speicher.

  3. Re: Design Fail

    Autor: bofhl 23.10.19 - 13:26

    Mal zur Klarstellung: das sind Systemlogs des Linux-Systems (der MCU) und absolut ungenutzt! Die werden nie - unter keinen Umständen! - ausgelesen. Das ist schlicht ein Fehler in der Software-Build-Erstellung. Die eigentlichen Logs des Fahrzeugs, die die einzelnen Komponenten während des Betriebs erstellen, werden auf einen entfernbaren Stick gespeichert und können Remote ausgelesen werden.

  4. Re: Design Fail

    Autor: June 23.10.19 - 13:30

    Es gibt Normen und Vorschriften die das verhindern. Ich habe Steuergeräte für PKW entwickelt und die "Logfiles" also der Fehlerspeicher muss alle paar Sekunden dauerhaft gespeichert werden. Es muss im Fehlerfall nachgewiesen werden wie sich das Steuergerät verhalten hat. Sonst kann man bei einem Unfall nicht nachweisen, dass das Steuegrät nicht ursächlich war. Übrigens braucht es keinen kompletten Netzausfall. Schon bei 11 Volt stellen viele Steuergeräte ihren normalen Dienst ein. Die Anzahl der Schreibzyklen bei den Speichern ist ein Wert der nicht für 100% der Chips gelten kann. Es gibt immer noch zig Teslas die keine Probleme haben. Die Steuergeräte die wir gebaut haben, sind auf eine Lebensdauer von mindestens 8 Jahren ausgelegt. Trotzdem fangen die ersten schon fürher an auszufallen.

  5. Re: Design Fail

    Autor: GregorMaier 23.10.19 - 15:06

    June schrieb:
    --------------------------------------------------------------------------------
    > Es gibt Normen und Vorschriften die das verhindern. Ich habe Steuergeräte
    > für PKW entwickelt und die "Logfiles" also der Fehlerspeicher muss alle
    > paar Sekunden dauerhaft gespeichert werden. Es muss im Fehlerfall
    > nachgewiesen werden wie sich das Steuergerät verhalten hat. Sonst kann man
    > bei einem Unfall nicht nachweisen, dass das Steuegrät nicht ursächlich war.
    > Übrigens braucht es keinen kompletten Netzausfall. Schon bei 11 Volt
    > stellen viele Steuergeräte ihren normalen Dienst ein. Die Anzahl der
    > Schreibzyklen bei den Speichern ist ein Wert der nicht für 100% der Chips
    > gelten kann. Es gibt immer noch zig Teslas die keine Probleme haben. Die
    > Steuergeräte die wir gebaut haben, sind auf eine Lebensdauer von mindestens
    > 8 Jahren ausgelegt. Trotzdem fangen die ersten schon fürher an auszufallen.

    Die Logs werden aber sicherlich keine hunderte MBs ausmachen, Daten von vor 5min sind bei einem Unfall nicht wirklich relevant. Zudem kann man die Daten komprimieren bzw. schreibt nur wichtige Daten raus, notfalls lädt man die in die Cloud. Falls wir hier nur vom Fehlerspeicher reden der über OBD ausgelesen werden kann, dann ist die Datengröße keine Erwähnung Wert (reden hier von ein paar kB). Bei Unter- und Überspannung funktionieren die SG in der Regel, die Fehlererkennung wird dann aber eingestellt.

  6. Re: Design Fail

    Autor: zonk 23.10.19 - 15:09

    Der Design Quark beginnt dabei, dass das Entertainment System das macht!

    Und dann kommen noch so viele Punkte die Himmelschreiend sind.

    Ich kann mich erinnern ich hab schon 14 Jahren auf einer Konferenz einen Vortragenden "ausgelacht", weil er Flash kaputt geschrieben hat.

  7. Re: Design Fail

    Autor: /mecki78 23.10.19 - 16:05

    gadthrawn schrieb:
    --------------------------------------------------------------------------------
    > Jetzt stell dir
    > vor, dass das System jede Bedienung abspeichert, gewechselter Sender,
    > Multimedia etc.pp.

    Wäre nicht tragisch, denn da das immer die gleichen Aktionen sind, lassen sich diese hervorragend komprimieren, da immer wieder die gleichen Bytefolgen im Log auftauchen werden und genau so etwas liebt ein Kompressor.

    /Mecki

  8. Re: Design Fail

    Autor: /mecki78 23.10.19 - 16:14

    bofhl schrieb:
    --------------------------------------------------------------------------------
    > Die werden nie - unter keinen Umständen! - ausgelesen.

    Also wenn das System regelmäßig nicht so funktioniert wie es soll, dann sollte man die schon auslesen, denn dort steht dann ggf. die Ursache oder zumindest was das System kurz davor getan hat, was zu dieser Fehlfunktion hätte führen können. Die Embedded Systeme, die bei uns in der Arbeit die Hauselektronik steuern, arbeiten alle so, dass /var/log eine RAM Disk ist und nur wenn die voll läuft bzw. einmal alle x Stunden werden die Logs dort komprimiert und dann die komprimierten Logs woanders hin verschoben. Das passiert natürlich auch beim herunter fahren der Systeme und im Falle eines Stromausfalls fahren diese Systeme automatisch herunter; damit das funktioniert hat jedes einen eigenen Stützakku, der das System auch einige Zeit komplett ohne Stromquelle versorgen kann (nur kurz, aber die sollen ja dann auch nur noch sauber herunter fahren). Bevor wir das so gemacht haben, waren die SSDs teilweise schon nach einem Jahr durch. Wie lange sie jetzt halten weiß ich nicht, denn seit der Umstellung haben alle bis heute durchgehalten.

    /Mecki

  9. Re: Design Fail

    Autor: gadthrawn 23.10.19 - 16:27

    bofhl schrieb:
    --------------------------------------------------------------------------------
    > Mal zur Klarstellung: das sind Systemlogs des Linux-Systems (der MCU) und
    > absolut ungenutzt! Die werden nie - unter keinen Umständen! - ausgelesen.
    > Das ist schlicht ein Fehler in der Software-Build-Erstellung. Die
    > eigentlichen Logs des Fahrzeugs, die die einzelnen Komponenten während des
    > Betriebs erstellen, werden auf einen entfernbaren Stick gespeichert und
    > können Remote ausgelesen werden.

    Das stimmt nicht ganz. In den Logs landen alle Eingaben am Touchscreen etc.pp.
    Den entfernbaren Stick (mal abgesehen davon dass es ne Karte ist) gibt es erst seit der dritten Iteration der MCU - und der enthält auch nur eine Kopie von Teilen der Daten...

  10. Re: Design Fail

    Autor: /mecki78 23.10.19 - 16:46

    June schrieb:
    --------------------------------------------------------------------------------
    > Sonst kann man
    > bei einem Unfall nicht nachweisen, dass das Steuegrät nicht ursächlich war.

    Wie soll das Entertainment-System ursächlich für einen Unfall sein? Ich behaupte mal, dass das Entertainment-System in den meisten Autos nicht mal im Ansatz so viele Logdaten erzeugt, falls es überhaupt welche erzeugt.

    > Übrigens braucht es keinen kompletten Netzausfall. Schon bei 11 Volt
    > stellen viele Steuergeräte ihren normalen Dienst ein.

    Wie gesagt, das Auto weiß wann der Akku schwach wird; sobald ein derartiges Versagen also kurz bevor steht, kann er ja die Log Strategie verändern. Auch ist es kein Problem so einer Steuereinheit einen eigenen Stützakku zu geben, der selbst dann, wenn man einfach so im laufenden Betrieb den Akku abklemmen würde oder die Sicherung flöten geht, das System noch lange genug am Leben halten kann, damit es sauber herunter fahren und alle Logdateien weg speichern kann. Auch im Falle eines Unfalls könnte er so die Logs noch sichern, außer der Unfall zerstört das System, aber dann sind sowieso meistens die Logs verloren, denn auch der Flash speicher ist nicht in einer unzerstörbaren, feuerfesten Box untergebracht.

    > Die
    > Steuergeräte die wir gebaut haben, sind auf eine Lebensdauer von mindestens
    > 8 Jahren ausgelegt.

    Lächerliche Lebenszeit für ein Auto. Mein letzter Benziner kam aus zweiter Hand und wurde nach 15 Jahren an die dritte Hand abgegeben.

    /Mecki

  11. Re: Design Fail

    Autor: Quantium40 24.10.19 - 01:38

    /mecki78 schrieb:
    > Wäre nicht tragisch, denn da das immer die gleichen Aktionen sind, lassen
    > sich diese hervorragend komprimieren, da immer wieder die gleichen
    > Bytefolgen im Log auftauchen werden und genau so etwas liebt ein
    > Kompressor.

    Dem Flash ist das egal, wie toll da komprimiert wird. Der schreibt bzw. löscht trotzdem nur blockorientiert, so dass auch ein 10 Byte-Eintrag im Log z.B. 512 Byte an Schreibvorgang auslöst.

  12. Re: Design Fail

    Autor: bigm 24.10.19 - 08:24

    Und schon sind wir bei Themen wie man auch Elektroautos nach Zeit X/Y in eine geplante "ruhepause" ;) schicken kann bzw. Reparaturaufträge auslösen kann.

    Bei Benzinern sind es Zahnriemen die immer getauscht werden müssen, Bei Benzinern mit Kette ist es die Kettenlängung die den Motor zerstört bei Reparaturverweigerern... usw.. usw..

    Bei e-Autos ist es jetzt ein winziges Bauteil was wegen der Vernetzung das ganze Auto lahmlegt.
    Dabei sind Fehler in der Akkusteuerung oder des internen Ladegerätes ja noch gar nicht berücksichtigt.

    Trotzdem ist Model S wohl das "haltbarste" Auto was gerade so zu bekommen ist und im Langstreckeneinsatz wohl auch das billigste da keine Kosten außer Reifen und Versicherung anfallen. Strom an den SuperChargern ist ja kostenlos.

    Anderseits muss man auch sagen wenn das Bauteil nach 300-400TKM kaputt geht oder nach 5-10 Jahren (da dürfte eher die Betriebszeit in Stunden das Leben beenden also vielfahrer (Autobahn) und wenigfahrer (Kinderkutsche) dürften eher weniger betroffen sein als der kleine Mann der sein Leben im Stau verbringt ..

    Andersherum was sind da schon 2000¤ ?Reparaturen nach keine Ahnung 3000/4000/5000 Betriebsstunden? nix.. was da ein Verbrenner schon verbraucht hat ist das x Fache.... (man kann natürlich alles irgendwie schön rechnen)

  13. Re: Design Fail

    Autor: ulink 24.10.19 - 10:35

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > schreiben. Logs sollten bei Embedded Systemen immer zuerst nur in RAM
    > geschrieben und dann auch im RAM komprimiert werden und nur wenn eine
    > bestimmte Menge an Daten erreicht wurde (das System hat ja begrenzt RAM)
    > oder im Falle bestimmter Ereignisse, sollten dann die komprimierten Logs
    > einmalig in statischen Speicher geschrieben werden, damit sie nicht
    > verloren gehen,

    Kann man so machen, muss man aber nicht. Ich schreibe bei meinen embedded Geraeten (ein paar 1000) das Log auch direkt aufs FLASH. Das ist auch gar kein Problem, weil ein Log ja gerade inhaerent sequentiell ist und Schreibaufrufe (Bits von 1 auf 0) dem FLASH nichts tun, nur das Loeschen (Bits von 0 auf 1). Und das geschieht nur blockweise.

    Kann man alles gut ausrechnen (vielleicht hat TESLA das versaeumt LOL) und ich bin z.B. bei meinen Geraeten auf etwa 1000 Jahre gekommen, bis die garantierte (nicht typische!) Loeschgrenze erreicht wird. Da ist das FLASH lange vorher schon an Alterschwaeche gestorben (es gibt auch eine kalendarische Alterung bei FLASH).

  14. Re: Design Fail

    Autor: ulink 24.10.19 - 10:39

    Quantium40 schrieb:
    --------------------------------------------------------------------------------
    > Der schreibt bzw.
    > löscht trotzdem nur blockorientiert, so dass auch ein 10 Byte-Eintrag im
    > Log z.B. 512 Byte an Schreibvorgang auslöst.

    Das stimmt nicht, schreiben kann i.a. byteweise oder zumindest in kleinen Mengen erfolgen (in jedem Fall VIEL kleiner als die Loeschblockgroesse) und belastet das FLASH nicht. Logging ist auch immer sequentiell (kommt immer nur neues dazu, bestehendes wird nicht geaendert) und passt daher sehr gut zu diesem Verhalten des FLASH.
    Das loeschen erfolgt blockweise und belastet das FLASH.

  15. Re: Design Fail

    Autor: ulink 24.10.19 - 10:41

    zonk schrieb:
    --------------------------------------------------------------------------------
    > Der Design Quark beginnt dabei, dass das Entertainment System das macht!

    Was soll daran falsch sein, dass das Entertainment-System das Entertainment macht? Und wo sonst als auf dem Bildschirm soll man Einstellungen aendern?
    Mit dem Fahren an sich hat die MCU nichts zu tun.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. AKDB Anstalt für kommunale Datenverarbeitung in Bayern, Regensburg
  2. Landeshauptstadt München, München
  3. i22 Digitalagentur GmbH, Bonn
  4. über duerenhoff GmbH, Hannover

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-62%) 7,50€
  2. 52,99€
  3. 1,99€
  4. 4,98€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Starlink: SpaceX steht zwischen Flaute und Rekordjagd
Starlink
SpaceX steht zwischen Flaute und Rekordjagd

Die nächsten 60 Starlink-Satelliten stehen zum Start bereit, nachdem in diesem Jahr ungewöhnlich wenige Raketen gestartet sind - nicht nur von SpaceX. Die Flaute hat SpaceX selbst verursacht und einen Paradigmenwechsel in der Raumfahrt eingeläutet.
Von Frank Wunderlich-Pfeiffer

  1. Raumfahrt SpaceX testet Notfalltriebwerke des Crew Dragon
  2. Starship Mit viel Glück nur 6 Monate bis zum ersten Flug ins All
  3. SpaceX Das Starship nimmt Form an

Ryzen 9 3950X im Test: AMDs konkurrenzlose 16 Kerne
Ryzen 9 3950X im Test
AMDs konkurrenzlose 16 Kerne

Der Ryzen 9 3950X ist vorerst die Krönung für den Sockel AM4: Die CPU rechnet schneller als alle anderen Mittelklasse-Chips, selbst Intels deutlich teurere Modelle mit 18 Kernen überholt das AMD-Modell locker.
Ein Test von Marc Sauter

  1. Zen-CPUs AMD nennt konkrete Termine für Ryzen 3950X und Threadripper
  2. Castle Peak AMDs Threadripper v3 sollen am 19. November erscheinen
  3. OEM & China AMD bringt Ryzen 3900 und Ryzen 3500X

Raumfahrt: Mehr Geld für die Raumfahrt reicht nicht aus
Raumfahrt
Mehr Geld für die Raumfahrt reicht nicht aus

Eine mögliche leichte Senkung des deutschen Beitrags zur Esa bringt nicht die Raumfahrt in Gefahr. Deren heutige Probleme sind Resultat von Fehlentscheidungen, die hohe Kosten und Ausgaben nach sich ziehen. Zuerst braucht es Reformen statt noch mehr Geld.
Ein IMHO von Frank Wunderlich-Pfeiffer

  1. Space Rider Neuer Anlauf für eine eigene europäische Raumfähre
  2. Vega Raketenabsturz lässt Fragen offen

  1. GPU-Beschleunigung: Nvidia baut ARM-Referenzplattform
    GPU-Beschleunigung
    Nvidia baut ARM-Referenzplattform

    Gemeinsam mit Partnern hat Nvidia eine Referenzplattform entworfen, um die eigenen Tesla-V100-Grafikmodule mit ARM-Prozessoren zu kombinieren. Passend dazu gibt es Cuda X als Software-Stack und Magnum I/O, um Netzwerk sowie Storage per GPU zu beschleunigen.

  2. Cherry Keys ausprobiert: Cherry stellt Software für Tastatur- und Maus-Remapping vor
    Cherry Keys ausprobiert
    Cherry stellt Software für Tastatur- und Maus-Remapping vor

    Mit Cherry Keys hat der Tastaturhersteller eine einfache Möglichkeit vorgestellt, auf bestimmte Tasten einer Tastatur oder einer Maus neue Funktionen zu programmieren. Nutzer können beispielsweise die F-Tasten mit Systemfunktionen, dem Start von Anwendungen oder Makros belegen.

  3. Linux: Google will Einheits-Kernel für alle Android-Geräte
    Linux
    Google will Einheits-Kernel für alle Android-Geräte

    Bisher nutzen die Android-Geräte verschiedene, speziell angepasste Versionen des Linux-Kernel. Google will stattdessen künftig ein einheitliches Image mit stabiler API für Hardware-Treiber nutzen.


  1. 15:08

  2. 14:47

  3. 14:20

  4. 13:06

  5. 12:40

  6. 12:29

  7. 12:04

  8. 12:00