The central gateway is the ECU every internal bus plugs into — the hub that ties the car's separate CAN networks together. Where the head unit, TBox and instrument cluster are full Linux/Android computers, the gateway is a single microcontroller running bare-metal real-time firmware — no operating system, no filesystem. It is the first ECU a diagnostic tool reaches (UDS address 0x700). See Architecture for the big picture.

• MCU — an Infineon SAK-XC2268N-40F80LR: XC2000-family, 16-bit C166SV2 core, LQFP-100, with 256 KB program flash + 64 KB data flash. No OS: a small routing/network-management firmware runs straight on the metal. (Earlier revisions of this page said “Renesas RH850, G3 core”. That was wrong — it was guessed from the G3SR01Bx00 hardware-version string. The part marking on the board settles it.)
• I/O — the XC2268N's MultiCAN module provides 6 CAN nodes; the board wires five of them to discrete NXP TJA1044 transceivers, with a sixth high-speed CAN transceiver integrated in the Infineon TLE9263 system-basis chip, which also supplies the LIN transceiver. There is no automotive Ethernet / DoIP in this car; everything the gateway does is over CAN and LIN.
• Reflashable — the firmware is field-updatable over the diagnostic bus: a small flash-programming routine is loaded into RAM and rewrites the code flash (the standard UDS download flow, behind Security Access).

Photos of an opened gateway. The component side carries the microcontroller, the system-basis chip, the EEPROM and an 8 MHz crystal; the solder side carries the row of CAN transceivers — one per bus, which is the clearest possible picture of what this ECU is: a small computer with six network ports and a routing table.

The firmware's own transmit table matches the hardware: it sends periodic messages on five bus indices (2–6) — 26 messages on bus 2, two on bus 3 (body), four on bus 4 (infotainment), five each on buses 5 and 6. The sixth channel is most likely the diagnostic CAN, which carries no periodic traffic because the gateway only answers requests there — likely, but not yet verified.

The gateway is the hub of a star of separate buses — powertrain, chassis, body/comfort, infotainment, telematics, plus a dedicated diagnostic CAN and slower LIN sub-buses. It has five jobs:

1. Selective routing (a firewall, not a bridge). It forwards only the messages a fixed routing table allows between buses. This is the reason you can poll every ECU through the OBD-II port but never sniff live traffic there — the gateway does not leak a functional bus's broadcasts onto the diagnostic CAN. To watch real traffic you must tap a functional bus directly. See CAN bus.
2. Signal re-gatewaying. Some values are retransmitted onto other buses, often with a different CAN ID — e.g. vehicle speed from the powertrain bus made available to the body and infotainment buses.
3. Diagnostic gateway. It routes diagnostic (UDS) requests from the OBD side to the target ECU on its home bus and relays the answer, and it enforces Security Access for anything that changes state — coding, actuator tests, flashing.
4. Update distribution. During a firmware update it is the routing entry point that carries the flash data to each target ECU across the buses.
5. Network management. It coordinates sleep/wake across the buses and watches for expected periodic messages; when one goes missing it records a “lost communication / message timeout” fault (the U… codes, e.g. the 0x195 and 0x37F network timeouts). The wake/sleep and undervoltage side of that is handled by the TLE9263 basis chip; its own memory fault (U240141, “EEPROM check”) refers to the little ST 95160.

The gateway is the single chokepoint between every subsystem. It is why the OBD port is a locked, request/response-only door rather than an open window; why sniffing or injecting real traffic means wiring into a functional bus; and why swapping or coding any control module has to pass through it under Security Access.

What's understood so far. To be continued.