Differences

This shows you the differences between two versions of the page.

--- architecture [2026/08/08 23:21] – external edit 127.0.0.1
+++ architecture [2026/08/10 01:14] (current) – external edit 127.0.0.1
@@ Line 10: / Line 10: @@
   * **[[hardware:mainboard|Head unit]] (infotainment)** — a Freescale **i.MX6** running **Android 4.4.2**, paired with a **Renesas RL78** MCU. The SoC runs the UI; the MCU is the gatekeeper to the vehicle. They talk over a serial **UART**. This is the computer these pages mostly work on — see [[hardware|Hardware & OS]].
-  * **[[hardware:tbox|TBox]] (telematics)** — the always-on cellular gateway: a **Quectel AG35** LTE modem plus an **NXP S32K144** MCU. It reaches the head unit over **USB/IP**, taps the CAN bus, and used to phone home over cellular — see [[hardware:tbox|TBox teardown]] and [[connectivity|Connectivity]].
+  * **[[hardware:tbox|TBox]] (telematics)** — the always-on cellular gateway: a **Quectel AG35** LTE module (which runs its own embedded **Linux** and hosts the telematics software) paired with an **NXP S32K144** MCU. The same split as the head unit repeats here — the Linux side never touches the CAN bus itself; it hands commands to the MCU over a **serial link**, and only the MCU is wired to the vehicle CAN transceiver. It reaches the head unit over **USB/IP**, and used to phone home over cellular — see [[hardware:tbox|TBox teardown]] and [[connectivity|Connectivity]].
   * **[[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** — 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.
+===== 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/response but never //sees// the live broadcasts on any functional bus. To sniff or inject real traffic you have to tap a functional bus directly. See **[[obd2|OBD-II diagnostics]]**.
+A few consequences worth knowing:
+  * The **instrument cluster** is its own ECU — it //displays// values (SoC, outside temperature, warning lamps) that other modules broadcast. If the module feeding it goes quiet, a value can look **stuck** on the last/substituted reading.
+  * 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 "Ready". This blocks //driving//, not diagnostics or preconditioning.
+  * Swapping any control module needs **online coding** with a manufacturer tool — the main obstacle to keeping an orphaned car serviceable.
+===== Diagnostics: the dealer tool & VCI =====
+The workshop diagnostic system ("IVHM") follows the standard automotive stack — a chain from a PC, through a communication box, into the car's gateway. Nothing exotic on the wire.
+{{:diag_ivhm.png?440|How the Aiways diagnostic system is wired}}
+  * **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" into the actual **UDS** commands. It reaches the car only through the VCI.
+  * **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/listen-only or active), **ISO-TP + UDS**, and **DoIP** (diagnostics over IP). It connects to the PC as a network device over USB-Ethernet; the PC drives it with the standard **D-PDU API (ISO 22900)**.
+  * **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 ''0x27''). So the port is a **locked diagnostic door, not an open window** — which is why passively listening on it reveals almost nothing.
+  * **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**: it sits on the CAN bus and can do remote health reporting, diagnostics and firmware updates over the mobile network, independent of the workshop tool.
+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's **Security Access** and the vehicle-specific **ODX** data.