architecture
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.
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.
architecture.1786267909.txt.gz · Last modified: by 127.0.0.1

