Differences

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

--- architecture [2026/08/08 00:47] – created - external edit 127.0.0.1
+++ architecture [2026/08/10 01:14] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-====== How the car is built ======
+====== Architecture ======
-The Aiways U5 is not one computer but several, wired together over a **CAN bus**. Knowing which box
+The Aiways U5 consists of some Microcontrollers and Computers, wired together via a **CAN bus**. Knowing which box talks to which and how and what is the key to everything else.
-talks to which — and over what link — is the key to everything else on this wiki.
 {{ :architecture.png?940 |Aiways U5 module architecture }}
-//Reverse-engineered; a few links (the OBD gateway, exactly which ECUs sit on which bus segment) are
+//what's understood so far. To be continued//
-still being confirmed.//
-===== The pieces =====
+===== The modules =====
-  * **Head unit (infotainment)** — a Freescale **i.MX6** running **Android 4.4.2**, paired with a
+  * **[[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]].
-    **Renesas RL78** MCU. The SoC runs the UI; the MCU is the gatekeeper to the vehicle. They talk over
+  * **[[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]].
-    a serial **UART**. This is the computer these pages mostly work on — see [[hardware|Hardware & OS]].
+  * **[[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.
-  * **TBox (telematics)** — the always-on cellular gateway: a **Quectel AG35** LTE modem plus an
+  * **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.
-    **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]].
-  * **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. See
-    [[displays|Cluster display]].
   * **OBD-II port** — sits behind a **diagnostic gateway**, isolated from the live internal bus.
-===== How data flows =====
-Everything the head unit knows about the car arrives the same way — a value is broadcast on the
-**CAN bus**, picked up by the **RL78 MCU**, and passed over **UART** to **Android**, where an app reads
-it. State-of-Charge, for example: **BMS → CAN → MCU → UART → Android → MQTT** (see [[canbus|CAN bus]]
-and [[cansignals|the signal reference]]).
-Commands travel the other way — **Android → MCU → CAN** — which is how, for instance, the A/C is
-switched on (see [[control|Vehicle control]]).
+===== 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.