architecture
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| architecture [2026/08/08 12:06] – 80.187.87.128 | architecture [2026/08/10 01:14] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 10: | Line 10: | ||
| * **[[hardware: | * **[[hardware: | ||
| - | * **[[hardware: | + | * **[[hardware: |
| * **[[canbus|Vehicle CAN bus]]** — the shared nervous system. The real ECUs live here: **VCU** (vehicle control), **BMS** (the HV battery), **BCM** (body), **HVAC**, **TPMS**, and more. | * **[[canbus|Vehicle CAN bus]]** — the shared nervous system. The real ECUs live here: **VCU** (vehicle control), **BMS** (the HV battery), **BCM** (body), **HVAC**, **TPMS**, and more. | ||
| - | * **[[displays|Displays]]** — four panels, but only two are driven by the head unit: the **centre touchscreen** (LVDS) and the **right driver panel** (HDMI). The **main instrument cluster** and left panel are a **separate ECU** that reads the CAN bus directly — the head unit cannot draw on them. See [[displays|Cluster display]]. | + | * **Displays** — four panels, but only two are driven by the head unit: the **centre touchscreen** (LVDS) and the **right driver panel** (HDMI). The **main instrument cluster** and left panel are a **separate ECU** that reads the CAN bus directly — the head unit cannot draw on them. |
| * **OBD-II port** — sits behind a **diagnostic gateway**, isolated from the live internal bus. | * **OBD-II port** — sits behind a **diagnostic gateway**, isolated from the live internal bus. | ||
| + | |||
| + | |||
| + | |||
| + | ===== The CAN network ===== | ||
| + | |||
| + | The modules are not all on one wire. A central **gateway** is the hub of a star of **five separate CAN buses** (plus slower LIN sub-buses), and it is the only thing that bridges them: | ||
| + | |||
| + | * **Powertrain CAN** — VCU (vehicle control), BMS (HV battery), motor controller, on-board charger, DC-DC converter, gear selector. | ||
| + | * **Chassis CAN** — ABS/ESP, electric power steering, brake booster, airbag, steering-angle sensor, cameras and parking radars. | ||
| + | * **Body / comfort CAN** — body control module, A/C control module, PTC heater and compressor, seat heaters, power tailgate, pedestrian low-speed warning. | ||
| + | * **Infotainment CAN** — the head unit, the instrument cluster, around-view and driver-monitor. | ||
| + | * **Telematics CAN** — a dedicated point-to-point link to the TBox. | ||
| + | * **LIN sub-buses** (hung off the body control module) — windows, sunroof, door handles, headlamps, steering-column lock, rain/light and 12 V battery sensors. | ||
| + | |||
| + | The gateway **routes** selectively between buses — it is a **firewall, not a simple bridge**. This is why the **OBD-II port** (which lands on a dedicated diagnostic CAN into the gateway) can //reach// every ECU by request/ | ||
| + | |||
| + | A few consequences worth knowing: | ||
| + | |||
| + | * The **instrument cluster** is its own ECU — it // | ||
| + | * The car keeps its **general-purpose computers one hop away from the live CAN bus** — twice over. The head unit's Android side and the TBox's Linux side both talk to the vehicle only through a dedicated microcontroller (RL78, S32K144) sitting between them and the wire. Neither general-purpose OS has a direct CAN connection of its own. | ||
| + | * **Drive-enable is gated by an immobilizer** — the body control module and the motor controller authenticate each other at power-on, and only then can the car reach " | ||
| + | * Swapping any control module needs **online coding** with a manufacturer tool — the main obstacle to keeping an orphaned car serviceable. | ||
| + | |||
| + | ===== Diagnostics: | ||
| + | |||
| + | The workshop diagnostic system (" | ||
| + | |||
| + | {{: | ||
| + | |||
| + | * **Workshop PC** — runs the **IVHM tester** (a Java application built on DSA's diagnostic platform). It holds the **ODX** data (the machine-readable description of every ECU's services, fault codes and coding) and turns a request like "read fault memory" | ||
| + | * **WDI2 VCI** — the box that plugs into the OBD-II socket. It is a small **PowerPC computer running Linux** that does the real bus signalling: **4 CAN channels** (each can be passive/ | ||
| + | * **OBD-II → central gateway** — the important part: the connector is **not** a passive tap on the internal buses. A central **gateway** sits behind it and **routes** diagnostic requests to the target ECU. Anything that changes state (clearing faults, coding, actuator tests, flashing) is protected by **Security Access** (a seed/key challenge, UDS service '' | ||
| + | * **ECUs** — VCU, BMS (HV battery), BCM (body), HVAC, TPMS and more, each reached through the gateway. | ||
| + | * **TBox** — the car's telematics unit is the **on-board counterpart**: | ||
| + | |||
| + | Because the diagnostics are plain **UDS / ISO-TP over CAN (plus DoIP)**, the same language could in principle be spoken by any standards-compliant interface. The two things that gate real access are the gateway' | ||
architecture.1786183610.txt.gz · Last modified: by 80.187.87.128