====== Zentrales Gateway (GW) ======

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 [[:de:hardware|Head-Unit]], [[de:hardware:tbox|T-Box]] und [[de:hardware:ip|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 [[:de:architecture|Architektur]].

===== System =====

  * **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).

^ Merkmal ^ Wert ^
| Teilenummer Baugruppe | ''861983101A'' |
| Software-Teilenummern | ''861975021 / 022 / 023'' (Build **017** im Fahrzeug) |
| Hardware-Version | ''G3SR01Bx00'' |
| UDS-Adresse | **0x700** |
| Haupt-MCU | Infineon ''SAK-XC2268N-40F80LR'' (C166SV2, 6 CAN-Knoten) |
| System Basis Chip | Infineon ''TLE9263QX'' (LDOs, LIN + CAN, Watchdog, Aufwecken) |
| CAN-Transceiver | 5 × NXP ''TJA1044'' |
| EEPROM | ST ''95160'' (16 kbit SPI) |
| Platinenhersteller | UAES (United Automotive Electronic Systems) |

===== Ein Blick ins Gehäuse =====

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.

{{ :gateway:gw_pcb_top_overview.jpg?600 |Bestückungsseite: Infineon XC2268N (rechts), TLE9263 SBC und EEPROM (unten links), Fahrzeugsteckverbinder oben}}

{{ :gateway:gw_mcu_xc2268n.jpg?450 |Der Haupt-Mikrocontroller: Infineon SAK-XC2268N-40F80LR, C166SV2-Kern}}
{{ :gateway:gw_sbc_tle9263.jpg?450 |Infineon TLE9263 System-Basis-Chip: Spannungsversorgungen, Watchdog, Wake-Logik, LIN + CAN}}

{{ :gateway:gw_pcb_bottom_overview.jpg?600 |Lötseite: fünf NXP TJA1044 CAN-Transceiver in einer Reihe, einer pro Bus}}

{{ :gateway:gw_can_transceiver_tja1044.jpg?450 |Einer der fünf CAN-Transceiver, NXP TJA1044}}

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//.

===== Was es tut =====

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:

  - **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 [[:de:obd2|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 [[:de:canbus|CAN-Bus]].
  - **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.
  - **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.
  - **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.
  - **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.

===== Warum es wichtig ist =====

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.//