Reference
Architecture
How the diagnostic engine, DoIP and UDS layers fit together.
Hanterill is a layered diagnostic stack with a native desktop shell. No part of it is a proprietary cloud API.
Layers
Text
Hanterill desktop application, Rust and Tauri v2
Diagnostic engine sessions, routines, decoders
ISO 14229 UDS unified diagnostic services
ISO 13400 DoIP diagnostics over IP
TCP / UDP sockets, discovery, routing activation
Ethernet passive ENET cable, RJ45
Vehicle gateway CEM / VGM on CMASession lifecycle
- UDP vehicle identification on port 13400 enumerates responders.
- A TCP connection opens to the vehicle on port 13400.
- Routing activation is sent and must be accepted before any diagnostic request.
- The engine opens an extended diagnostic session per ECU and issues reads.
- Responses are decoded against platform-specific maps.
- The session is held in memory and written to disk on export.
A single request travels the same path every time, and the response comes back along it:
requestread battery state of health
- Hanterilldiagnostic engine
- Ethernetpassive ENET cable
- Vehicle gatewayCEM / VGM, DoIP
- Target ECUBECM, extended session
response94.7 %, decoded from the raw value
Components
- Transport: async Rust sockets, one connection multiplexed across ECUs.
- UDS: request and response framing, negative-response handling, pending-response retries.
- Decoders: per-platform maps from data identifiers to typed values. CMA is complete; SEA and SPA2 are partial and flagged.
- Safety gate: any service that changes ECU state (clear, write by identifier, routine control, input/output control) checks a session-scoped write flag and fails closed.
- Interface: React and TypeScript, typed against the engine over Tauri commands. No bundled browser engine.
Why Rust and Tauri
The protocol work benefits from Rust's concurrency and error handling. Tauri keeps the binary small and avoids shipping a Chromium runtime, so the application feels native rather than like a web page in a window.