Das Fahrerdisplay — die Instrumententafel hinter dem Lenkrad — ist ein eigenständiger Rechner, getrennt von der Head-Unit. Es ist das Modul, das Geschwindigkeit, Reichweite, Ladezustand, Fahrmodus und die Warnleuchten anzeigt. Anders als beim mittleren Touchscreen kann die Head-Unit nicht auf das Haupt-Kombiinstrument zeichnen: Das Kombiinstrument rendert sein Bild selbst und liest nur Werte, die andere Module auf dem CAN-Bus senden. Wo es im Gesamtaufbau sitzt, steht unter Architektur.

Das Kombiinstrument ist ein kleiner Embedded-Linux-Rechner mit einem Sicherheits-Mikrocontroller daneben — dieselbe Aufteilung „großer SoC + wachender MCU“ wie bei Head-Unit und T-Box.

• SoC — ein Applikationsprozessor NXP i.MX6 (Dual).
• OS — ein schlankes Buildroot Linux (Kernel 4.1.15) auf eMMC, gestartet von U-Boot. Kein Android.
• UI — eine eigene ARM-Grafikanwendung (Hersteller „xtd“), die in die Framebuffer des Displays zeichnet; alle Anzeigen, Leuchten, Fahrmodus-Grafiken und die Startanimation sind Bilddateien, die mit ihr ausgeliefert werden.
• Begleit-MCU — ein separater Sicherheits-Mikrocontroller stellt die gesetzlich vorgeschriebenen Kontrollleuchten dar. Das ist Absicht: Die Warnleuchten müssen weiterarbeiten, auch wenn die Linux-UI hängt, also darf die sicherheitskritische Ebene nicht am Applikationsprozessor hängen. Praktisch heißt das: Die „schöne“ Grafik liegt auf Linux, die vorgeschriebenen Warnungen liegen auf dem MCU.

Für ein vernetzt wirkendes Gerät ist das Kombiinstrument ungewöhnlich abgeschottet:

• Kein allgemeines Netzwerk. Es hat kein eigenes Ethernet und kein eigenes Wi-Fi — es gibt keine IP-Adresse, über die du es erreichen könntest.
• Fahrzeugdaten kommen über CAN, aber die Linux-Seite berührt den Bus nie direkt; das macht ihre Begleit-MCU und gibt die Werte nach oben weiter. Dasselbe Muster „einen Sprung vom CAN entfernt“ wie bei den anderen Modulen.
• Displayverbindung zur Head-Unit — die Head-Unit speist eines der Displays des Kombiinstruments über eine serialisierte Videoverbindung (FPD-Link). Wichtig: Diese Verbindung ist bidirektional; über ihren Rückkanal liefert die Head-Unit außer dem Videobild auch Firmware-Updates für das Kombiinstrument (siehe unten).

Die Firmware erreicht das Modul auf zwei Wegen, und keiner davon führt direkt über das Internet — das Kombiinstrument hat kein Netzwerk:

• Over-the-Air (im Feld): Die T-Box lädt das Update-Paket über Mobilfunk, die Head-Unit bekommt den Anteil für das Kombiinstrument und schiebt ihn über den FPD-Link-Rückkanal hinein — als einfache, in Rahmen verpackte und per Prüfsumme gesicherte Blockübertragung. Ein kleiner Updater-Dienst im Kombiinstrument nimmt sie an, prüft sie und installiert sowohl den Linux-UI-Teil als auch den Teil für die Begleit-MCU.
• Werkstatt: Das Händler-Diagnosegerät flasht es auf dem Standardweg — UDS über CAN durch das Gateway, hinter Security Access. Siehe OBD-II-Diagnose.

Die Update-Pakete sind verschlüsselte Archive, die das Kombiinstrument beim Start selbst entpackt und installiert. Die Integritätsprüfung darin ist eine einfache Prüfsumme und keine kryptografische Signatur.

Weil das Kombiinstrument eine normale (wenn auch kleine) Linux-Kiste ist, hat es die üblichen Embedded-Linux-Einstiegspunkte — eine serielle Konsole, eine USB-Schnittstelle, die das Werks-Flashwerkzeug nutzt, den oben beschriebenen Firmware-Update-Kanal und den Diagnoseweg über UDS. Jeder davon wurde untersucht und ist so weit verstanden, dass sich beschreiben lässt, wie das Modul startet, sich aktualisiert und instand gesetzt werden könnte. Die Details stehen nicht auf dieser Seite.

<WRAP center round important 60%> Das hier ist das Kombiinstrument des Fahrers — es zeigt Geschwindigkeit, Reichweite und sicherheitskritische Warnleuchten. Alles, was du hier machst, gilt nur für das eigene Fahrzeug und muss vorher außerhalb des Fahrzeugs abgesichert werden; ein fehlerhaftes Image kann das Kombiinstrument ohne funktionierende UI zurücklassen. </WRAP>

Stand des Wissens. Wird fortgesetzt.