User Tools

Site Tools


architecture

This is an old revision of the document!


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.

Aiways U5 module architecture

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.

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.

architecture.1786267909.txt.gz · Last modified: by 127.0.0.1