Das zentrale Gateway ist das Steuergerät, an dem jeder interne Bus hängt — der Knotenpunkt, der die getrennten CAN-Netzwerke des Fahrzeugs miteinander verbindet. Während Head-Unit, T-Box und Kombiinstrument vollwertige Linux-/Android-Rechner sind, ist das Gateway ein einzelner Mikrocontroller mit Bare-Metal-Echtzeitfirmware — kein Betriebssystem, kein Dateisystem. Es ist das erste Steuergerät, das ein Diagnosegerät erreicht (UDS-Adresse 0x700). Den Gesamtzusammenhang findest du unter Architektur.

• MCU — ein Infineon SAK-XC2268N-40F80LR: Familie XC2000, 16-bit-Kern C166SV2, LQFP-100, mit 256 KB Programm-Flash + 64 KB Daten-Flash. Kein Betriebssystem: eine kleine Routing-/Netzwerkmanagement-Firmware läuft direkt auf der Hardware. (Frühere Fassungen dieser Seite nannten „Renesas RH850, G3-Kern“. Das war falsch — es war aus der Hardware-Versionskennung G3SR01Bx00 geraten. Der Aufdruck auf dem Bauteil klärt die Frage.)
• I/O — das MultiCAN-Modul des XC2268N stellt 6 CAN-Knoten bereit; auf der Platine sind fünf davon auf diskrete NXP TJA1044 Transceiver geführt, ein sechster High-Speed-CAN-Transceiver ist im System Basis Chip Infineon TLE9263 integriert, der auch den LIN-Transceiver mitbringt. Automotive Ethernet / DoIP gibt es in diesem Fahrzeug nicht; alles, was das Gateway tut, läuft über CAN und LIN.
• Neu programmierbar — die Firmware ist im Feld über den Diagnosebus aktualisierbar: eine kleine Flash-Programmierroutine wird ins RAM geladen und schreibt den Code-Flash neu (der übliche UDS-Download-Ablauf, hinter Security Access).

Fotos eines geöffneten Gateways. Auf der Bestückungsseite sitzen der Mikrocontroller, der System Basis Chip, das EEPROM und ein 8-MHz-Quarz; auf der Lötseite liegt die Reihe der CAN-Transceiver — einer pro Bus, und damit das anschaulichste Bild davon, was dieses Steuergerät ist: ein kleiner Rechner mit sechs Netzwerk-Ports und einer Routing-Tabelle.

Die Sendetabelle der Firmware passt zur Hardware: Sie sendet zyklische Botschaften auf fünf Bus-Indizes (2–6) — 26 Botschaften auf Bus 2, zwei auf Bus 3 (Karosserie), vier auf Bus 4 (Infotainment), je fünf auf Bus 5 und 6. Der sechste Kanal ist mit hoher Wahrscheinlichkeit der Diagnose-CAN, auf dem kein zyklischer Verkehr läuft, weil das Gateway dort nur auf Anfragen antwortet — wahrscheinlich, aber noch nicht verifiziert.

Das Gateway ist der Mittelpunkt eines Sterns aus getrennten Bussen — Antrieb, Fahrwerk, Karosserie/Komfort, Infotainment, Telematik, dazu ein eigener Diagnose-CAN und langsamere LIN-Subbusse. Es hat fünf Aufgaben:

1. Selektives Routing (eine Firewall, keine Brücke). Es leitet zwischen den Bussen nur die Botschaften weiter, die eine feste Routing-Tabelle erlaubt. Deshalb kannst du über den OBD-II-Anschluss jedes Steuergerät abfragen, dort aber nie den laufenden Verkehr mitlesen — das Gateway lässt die Broadcasts eines Funktionsbusses nicht auf den Diagnose-CAN durch. Um echten Verkehr zu sehen, musst du direkt an einem Funktionsbus abgreifen. Siehe CAN-Bus.
2. Signal-Regatewaying. Manche Werte werden auf andere Busse weitergesendet, oft mit einer anderen CAN-ID — z. B. die Fahrzeuggeschwindigkeit vom Antriebsbus, die so auch dem Karosserie- und dem Infotainment-Bus zur Verfügung steht.
3. Diagnose-Gateway. Es leitet Diagnoseanfragen (UDS) von der OBD-Seite an das Ziel-Steuergerät auf dessen Heimatbus weiter und gibt die Antwort zurück, und es erzwingt Security Access für alles, was den Zustand ändert — Codierung, Stellgliedtests, Flashen.
4. Verteilung von Updates. Bei einem Firmware-Update ist es der Routing-Einstiegspunkt, der die Flash-Daten über die Busse zu jedem Ziel-Steuergerät bringt.
5. Netzwerkmanagement. Es koordiniert Schlafen/Aufwecken über alle Busse hinweg und überwacht die erwarteten zyklischen Botschaften; fehlt eine, legt es einen Fehler „Kommunikation verloren / Botschafts-Timeout“ ab (die U…-Codes, z. B. die Netzwerk-Timeouts 0x195 und 0x37F). Die Aufwach-/Schlaf- und die Unterspannungsseite davon übernimmt der Basis-Chip TLE9263; sein eigener Speicherfehler (U240141, „EEPROM check“) bezieht sich auf das kleine ST 95160.

Das Gateway ist der eine Engpass zwischen allen Subsystemen. Deshalb ist der OBD-Anschluss eine verschlossene Tür, die nur Anfrage/Antwort zulässt, und kein offenes Fenster; deshalb bedeutet echten Verkehr mitlesen oder einspeisen, sich in einen Funktionsbus einzuschleifen; und deshalb muss jeder Tausch und jede Codierung eines Steuergeräts unter Security Access durch das Gateway.

Stand des Wissens. Wird fortgesetzt.