Key points
- ECUs exchange data over dedicated networks such as CAN, CAN FD, LIN and Automotive Ethernet.
- Gateways connect separate network domains and control which messages are routed between them.
- Communication includes cyclic status data, events, commands, diagnostics and network-management messages.
- Timing, bus load, sleep states and security controls affect whether a system behaves correctly.
- Every decoded message should be validated against real vehicle behaviour.
1. What is ECU communication?
An Electronic Control Unit, or ECU, is an embedded computer responsible for one or more vehicle functions. Engine control, transmission control, braking, steering, body electronics, infotainment and advanced driver-assistance systems all depend on ECUs exchanging information.
ECU communication is the structured transfer of data between those controllers. Messages may contain physical values such as engine speed or wheel speed, commands such as activating a relay, status information, diagnostic requests, fault codes or network-management instructions.
The communication is not a single unified stream. Modern vehicles contain several network domains selected according to bandwidth, cost, determinism, topology and safety requirements.
2. Vehicle communication networks
Each protocol has a different role. CAN remains widely used for robust control communication, LIN serves low-cost local subsystems, and Ethernet is increasingly used where high bandwidth is required.
| Network | Typical speed | Communication model | Common applications |
|---|---|---|---|
| CAN | Up to 1 Mbit/s | Multi-master, message based | Powertrain, chassis, body and diagnostics |
| CAN FD | Higher data-phase rates | Multi-master, larger payload | ADAS, gateways and newer control systems |
| LIN | Up to 20 kbit/s | Single master, scheduled | Doors, seats, mirrors, lighting and HVAC actuators |
| FlexRay | Up to 10 Mbit/s | Time triggered and event triggered | Deterministic chassis and safety systems |
| Automotive Ethernet | 100 Mbit/s and above | Switched, packet based | Cameras, infotainment, diagnostics and central computing |
These networks are complementary. A radar ECU may publish object information over CAN FD or Ethernet, while a body controller may command a local LIN actuator and forward selected status data to another domain.
3. Gateways and vehicle domains
A gateway ECU connects network segments that would otherwise remain isolated. It receives messages from one bus, applies routing and security rules, and forwards selected information to another bus or domain.
Gateways may separate powertrain, chassis, body, infotainment and ADAS networks. This reduces unnecessary traffic, limits fault propagation and provides a controlled diagnostic entry point.
| Gateway function | Engineering purpose |
|---|---|
| Message routing | Forwards approved signals between network domains. |
| Protocol translation | Maps information between CAN, LIN, Ethernet or diagnostic transports. |
| Filtering | Prevents irrelevant or unauthorised traffic from crossing domains. |
| Diagnostic access | Routes tester requests to the target ECU. |
| Network management | Coordinates wake-up, sleep and communication states. |
| Security enforcement | Applies authentication, firewall and access-control policies. |
4. Message types and purposes
Not all ECU traffic behaves in the same way. Understanding message purpose helps determine how to capture, filter and validate it.
- Cyclic messages: transmitted at a fixed period, often carrying status and sensor values.
- Event-driven messages: transmitted when a state changes or a specific event occurs.
- Commands: request another ECU or actuator to perform an action.
- Responses: confirm a command, report a result or provide requested data.
- Diagnostic messages: carry tester requests, ECU responses, fault information and programming services.
- Network-management messages: control wake-up, sleep, availability and communication state.
- Integrity information: counters, checksums, freshness values or authentication data used to detect invalid traffic.
5. Diagnostic communication
Vehicle diagnostics normally use standardised application services, with UDS being common in modern vehicles. UDS can run over CAN using ISO-TP or over Ethernet using DoIP.
| Diagnostic function | Typical purpose |
|---|---|
| Read data by identifier | Retrieve measurements, status values or ECU information. |
| Read diagnostic trouble codes | Obtain stored faults and related status information. |
| Clear diagnostic information | Erase supported fault-memory records after repair or testing. |
| Routine control | Start a calibration, self-test or ECU-specific procedure. |
| Security access | Unlock protected diagnostic services after authentication. |
| ECU programming | Download and activate firmware under controlled conditions. |
Diagnostic access does not expose every internal signal. Reverse engineering may still be required when an integration depends on normal operating traffic or undocumented values.
6. Timing, latency and synchronisation
Correct values alone are not sufficient. Control systems also depend on when data arrives, how often it is updated and whether related signals are synchronised.
- Message period: the expected interval between cyclic frames.
- Latency: the delay between an event and the resulting message or action.
- Jitter: variation in message timing.
- Bus load: the proportion of available network capacity being used.
- Timeout: the period after which an ECU considers data missing or invalid.
- Time synchronisation: a shared time reference used by logging, ADAS and distributed systems.
During analysis, timestamps should be captured with enough resolution to reveal message periods, request-response delays and state transitions.
7. Security and access control
Modern ECU communication increasingly includes security mechanisms. These may restrict diagnostic services, authenticate messages or isolate external interfaces from safety-relevant networks.
Common mechanisms include diagnostic security access, secure gateways, message authentication codes, freshness counters, encrypted Ethernet communication and signed firmware.
Engineering work should respect access controls and avoid active transmission until message purpose, network state and potential vehicle impact are understood.
8. Analysing ECU communication
A repeatable analysis workflow reduces false conclusions and produces documentation that can be reused by firmware, validation and integration teams.
- Map the available networks, connectors, ECUs and gateway paths.
- Capture raw traffic with accurate timestamps and error frames enabled.
- Record a baseline before changing any vehicle state.
- Perform one controlled action at a time and document the exact conditions.
- Group traffic by identifier, period, source domain and observed behaviour.
- Identify candidate bytes and bits, then determine scaling and units.
- Test request-response relationships and gateway routing where relevant.
- Validate every candidate value or command on the real vehicle.
- Document confidence, limitations and the conditions under which the result is valid.
9. Common ECU communication issues
| Symptom | Possible cause | Recommended check |
|---|---|---|
| Missing messages | Sleeping ECU, gateway filtering, wiring fault or incorrect bus connection. | Confirm ignition state, network activity and gateway route. |
| Intermittent communication | Voltage drop, connector fault, high bus load or module reset. | Log power, network errors and timestamps simultaneously. |
| Valid frame but incorrect value | Wrong byte order, signedness, scale or multiplexing assumption. | Compare several operating points and test alternative encodings. |
| Diagnostic request rejected | Wrong session, security locked, timing violation or unsupported service. | Review negative response code and required preconditions. |
| Communication stops after testing | Network-management state changed or active traffic disturbed timing. | Return the vehicle to a known state and inspect wake/sleep behaviour. |
10. Engineering best practices
- Preserve original raw captures before filtering or conversion.
- Use hardware timestamps and record error frames.
- Document ignition state, supply voltage, operating mode and test action.
- Separate passive observation from active transmission testing.
- Account for gateways, multiplexing, counters, checksums and security data.
- Validate values across minimum, maximum and intermediate operating points.
- Confirm behaviour across repeated sessions and vehicle restarts.
- Record message source, destination, period, scaling, units and confidence level.
- Do not treat a correlation as a confirmed signal until it has been independently validated.
11. Typical project deliverables
A professional ECU communication project should provide structured engineering outputs rather than only raw captures. Typical deliverables include:
- Vehicle network and gateway architecture.
- ECU inventory and observed network roles.
- Message and signal database with scaling, units and timing.
- Diagnostic service map and supported sessions.
- Request-response and gateway-routing documentation.
- Annotated logs and validation evidence.
- DBC or project-specific signal definitions.
- Integration requirements for embedded gateways, APIs or test systems.
FAQ
Frequently asked questions
How do ECUs communicate in a vehicle?
ECUs exchange messages over vehicle networks such as CAN, CAN FD, LIN, FlexRay and Automotive Ethernet. Gateways route selected information between those networks.
What is the role of a vehicle gateway ECU?
A gateway connects separate vehicle networks, filters and routes messages, enforces access rules and may translate between protocols or diagnostic domains.
Can ECU communication be reverse engineered?
Yes. Communication can be captured, grouped by network and identifier, correlated with controlled actions and validated to identify messages, signals, diagnostics and timing behaviour.
Engineering support
Need help analysing ECU communication?
Idesoftbcn Automotive Lab supports vehicle-network capture, ECU analysis, signal decoding, diagnostics, gateway investigation, embedded development and real-vehicle validation.
Discuss your projectContinue reading