This is an old revision of the document!
Table of Contents
Architecture
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.
what's understood so far. To be continued
The modules
- 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 & OS.
- 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 TBox teardown and 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.
- 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 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.
- 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.
- 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.

