Protocols (DoIP, UDS and CAN)

When Hanterill reads the car, messages travel through the cable to the car's gateway and then to the right control unit. The Ethernet connection, diagnostic requests and internal vehicle networks each have a different job. This guide explains how they fit together. The connection does not need a cloud service.

How the three protocols fit together#

You can think of the communication stack like sending a letter to a specific department inside an office building:

DoIP (Diagnostics over IP)

The addressed envelope and mailroom delivery system. It carries messages over the Ethernet cable to the car's central gateway, which routes them to the right control unit.

UDS (Unified Diagnostic Services)

The language written on the letter inside the envelope. It defines standard questions ('What is your software version?', 'Are any fault codes stored?') and maintenance commands.

CAN (Controller Area Network)

The internal wiring network inside the car that connects individual control units to the gateway and carries continuous real-time sensor signals between modules.

You can explore the physical wiring between every control unit and bus segment on the interactive CMA Network Explorer.

Standard protocols, direct connection.

Hanterill talks to the car's diagnostic network with the same protocols a dealer tool uses. Nothing in between is a proprietary cloud service.

1. HanterillDesktop application, Rust and Tauri
2. Diagnostic engineSessions, sweeps, decoders, scoring
3. ISO 14229 UDSUnified Diagnostic Services
4. ISO 13400 DoIPDiagnostics over IP
5. TCP / UDPSockets, discovery, routing activation
6. EthernetPassive ENET cable, RJ45
7. Vehicle gatewayCEM / VGM on CMA

Hanterill finds the car through the cable, opens a diagnostic connection and sends questions to its control units. Ordinary checks read information. Actions that can change the car are separate and ask for confirmation first.

UDP 13400

Vehicle identification and announcement

TCP 13400

Diagnostic message channel

Routing activation

Sent before any UDS request

Session control

Diagnostic session control

Identifier read

Read data by identifier

DTC read

Read DTC information

Periodic read

One on-demand periodic sample

Routine result

Outcome of a routine that already ran

The vehicle network around its gateway.

A simplified view of the CMA electric platform. Select any control unit to see its details.

Gateway

Routing and central control

• VGM
• CEM

Energy

High-voltage battery, charging and drivetrain

• VCU1
• BECM
• BMS
• OBC
• IHFA
• IEM
• ECM
• TCM
• DEM
• MVBM
• NRCM

Chassis

Steering, braking and motion sensing

• BCM2
• PSCM
• SAS
• SCL
• SUM
• EGSM
• IMS
• ASDM
• FLC2
• FLR
• WAM
• PAC
• SODL
• SODR

Cabin

Displays, comfort, telematics and restraints

• DIM
• CCM
• TCAM
• SRS
• IHU
• CSD
• AUD
• SWM
• DDM
• PDM
• POT
• RML
• RMR
• HCML
• HCMR
• PXMR
• PXML
• OHC
• PAKM
• WPC
• BBS
• ESM

BECM

Battery Energy Control Module

Domain

Energy

Part number

32290432

Diagnostics

UDS session

DTC support

Advertises DTCs

Full ECU reference

1. DoIP: How Ethernet connects to the car's gateway#

On CMA, SPA, and SEA1 vehicles, the primary diagnostic link is DoIP (ISO 13400). Instead of requiring an expensive proprietary translator box, the car has a standard Ethernet network card built into its Vehicle Gateway Module (VGM) or Central Electronic Module (CEM), wired directly to pins on the OBD-II port.

When you plug in an ENET cable and press Connect, five steps happen in less than a second:

1. Finding the car (Vehicle Discovery): Hanterill sends a discovery message over the local cable and listens for the car's gateway to announce its VIN and network address.
2. Opening the link: Hanterill opens a direct connection to the vehicle gateway.
3. Routing activation: Hanterill asks the gateway for permission to route diagnostic messages into the car's internal networks. Until the gateway accepts this routing request, no control unit will answer.
4. Addressing the target module: Every control unit inside the car has its own logical address (like an office phone extension). Hanterill puts the target module's address on the DoIP envelope and hands it to the gateway.
5. Receiving the reply: The gateway forwards the question to that control unit (even if that module sits on an internal CAN or FlexRay bus), collects the module's answer, wraps it in a DoIP envelope, and sends it back to your laptop.

Because a vehicle gateway can sometimes send a module's answer before its delivery receipt when traffic is fast, Hanterill tracks every message conversation carefully so replies are never mixed up or dropped.

2. UDS: How questions, sessions, and keep-alives work#

Inside each DoIP envelope is a UDS (ISO 14229) message. UDS is the universal language that modern control units understand, and almost everything Hanterill does uses six plain types of UDS messages:

Open a diagnostic session

Switches a module between its everyday default session and its extended diagnostic session so it can report its full set of sensors and status records.

Keep-alive heartbeat (Tester Present)

A quiet periodic signal that tells awake modules a scan is still running so they do not go to sleep in the middle of a multi-minute test.

Read a data value

Asks a module for one specific numbered measurement or identity record, such as battery voltage, cell temperature, odometer mileage, or software version.

Read fault codes

Asks a module for all stored, pending, or permanent Diagnostic Trouble Codes (DTCs) along with their freeze-frame snapshots.

Clear fault codes

Asks a module to erase its stored fault codes after a repair (always behind a confirmation prompt).

Run a maintenance routine

Starts or checks a built-in workshop routine on a module, such as parking brake service mode or sensor calibration (always behind a confirmation prompt).

Broadcast reads versus one-by-one requests#

DoIP and UDS support two ways of addressing modules inside the car:

• Targeted (physical) requests: Addressed to one specific control unit at a time.
• Broadcast (functional) requests: Sent once to a shared broadcast address so every awake module on the car can answer the same question at the same time.

Hanterill uses broadcast requests when checking which modules are awake or reading vehicle-wide identity records, because one broadcast can gather answers from dozens of modules in a fraction of a second.

However, opening an extended diagnostic session must always be done one module at a time. By design, the vehicle gateway ignores broadcast requests that try to change diagnostic sessions, so a tool cannot accidentally place every computer in the car into an extended mode at once.

Waking sleeping modules and letting the car sleep afterward#

When a car is parked with the ignition off, many secondary control units (such as climate, seat, or door modules on quieter internal buses) go to sleep to save the 12-volt battery.

If you need to scan a parked car without turning the ignition on, Hanterill's Wake-up sequence runs a five-step routine:

1. Broadcasts a wake-up pulse across the gateway.
2. Wakes the Central Electronic Module (CEM) and Vehicle Gateway Module (VGM) first.
3. Steps through the core drivetrain and chassis modules one by one so the gateway activates its internal sub-buses.
4. Sends a short keep-alive pulse so freshly woken modules finish booting.
5. Pauses briefly for all modules to settle before reading their data.

Just as importantly, as soon as your scan finishes or you disconnect, Hanterill stops sending keep-alive pulses so the car's computers can return to deep sleep naturally without draining the 12 V battery.

3. CAN: Internal vehicle buses and continuous live signals#

While Ethernet (DoIP) connects your laptop to the car's gateway, CAN (Controller Area Network) is the workhorse wiring network that connects the control units to one another inside the car. For example, CMA vehicles use eleven separate CAN segments running at up to 500 kbps to connect drivetrain, brake, steering, body, and climate modules.

CAN is used in two distinct ways during diagnostics:

Diagnostic questions over CAN (ISO-TP)#

When a vehicle's CAN pins are reached through a CAN interface, as some workshop tools do, the same UDS diagnostic questions travel over CAN instead of Ethernet. Because a single standard CAN frame holds only 8 bytes of data, a transport rule called ISO-TP (ISO 15765) automatically splits longer diagnostic messages (like a 17-character VIN or a list of fault codes) into a sequence of small numbered packets and reassembles them at the other end.

Passive CAN bus listening (continuous broadcast frames)#

There is an important difference between UDS diagnostic polling and native CAN bus traffic:

• UDS over DoIP is question-and-answer: A module only reports a value when Hanterill explicitly asks for it.
• Native CAN traffic is a continuous broadcast: While the car is awake, control units constantly broadcast live operating messages onto the internal CAN buses many times per second (such as wheel speeds, brake pressure, steering wheel angle, pedal positions, and ambient temperatures) so other modules can react instantly.

Because the car's gateway only forwards question-and-answer UDS traffic over the Ethernet cable, some fast real-time signals that travel continuously on the internal CAN buses are not exposed as individual UDS questions. Hanterill's desktop screens all read over the Ethernet link and add no traffic at all to the car's internal CAN buses.

Next#

• Connection: how the desktop app connects with an ENET cable.
• ECU reference: the control units across the car's networks.
• CMA Network Explorer: trace the Ethernet, CAN, LIN, and FlexRay buses visually.
• Safety: how Hanterill keeps diagnostic traffic safe for your vehicle.