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

• 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 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 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 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.
• 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.

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.