Synthetic CAN/UDS Diagnostic Case Study
An invented, product-neutral case connecting signal timeouts, inconsistent vehicle data, DTC evidence, and diagnostic reasoning without exposing proprietary information.
Engineering question
How should an engineer reason when an ADAS controller records a vehicle-data timeout, live data appears inconsistent, and the available DTC evidence does not identify a single root cause?
A communication DTC reports what one controller monitored. It does not automatically reveal whether the source ECU, network path, gateway, receiving ECU, power supply, timing, configuration, or diagnostic setup created the condition.
This case uses a fully invented network, fictional module names, synthetic signals, and synthetic fault labels. It separates ordinary ECU-to-ECU signal traffic from diagnostic client/server communication: CAN can carry vehicle network messages, while UDS defines diagnostic services at the application layer and can operate over DoCAN transport services.
The purpose is not to teach message injection, security bypass, proprietary identifiers, or vehicle modification. It is to demonstrate evidence preservation, time correlation, source-versus-destination comparison, and careful interpretation of fault status and live data.
System boundary and assumptions
Define what the model can—and cannot—support.
- A fictional gateway, vehicle-dynamics ECU, forward-assistance ECU, and authorized diagnostic tester
- Synthetic cyclic signals, UDS reads, DTC status, snapshots, and synchronized passive captures
- Reasoning about timeouts, inconsistent values, and cascaded evidence
- Non-invasive verification planning within authorized service access
- All identifiers, timing values, labels, and traces on this page are invented for education
- The tester is authorized and uses approved diagnostic access
- The network capture method is passive, safe, electrically suitable, and time-synchronized
- The synthetic model declares its own expected behavior; it is not a template for a real vehicle
- Real arbitration IDs, DIDs, security access, routines, keys, seed/key methods, or proprietary DTC definitions
- Instructions for transmitting, modifying, spoofing, fuzzing, or disabling vehicle communications
- A universal CAN timing rule or a real repair decision
- A claim that UDS data and raw network signals are always sampled, filtered, or updated identically
Original architecture / dependency diagram
Separate signal flow from diagnostic observation
The synthetic architecture has two evidence paths. Operational messages travel through the vehicle network; the tester separately requests diagnostic information from controllers.
- 01Source
Dynamics ECU — fictional
Produces synthetic VehicleSpeed_A and YawRate_A values with declared validity and counter information.
- 02Path
CAN segment
Carries cyclic operational messages. Wiring, termination, bus state, load, and other nodes can influence delivery.
- 03Route
Gateway — fictional
Routes or transforms selected signals between the source network and assistance-controller network.
- 04Consumer
Forward Assist ECU — fictional
Checks message freshness and plausibility, then stores a synthetic timeout or invalid-data condition.
- 05Observe
Authorized tester
Uses UDS diagnostic services to read status, snapshots, identification, and live data defined by the fictional model.
- 06Correlate
Engineering timeline
Aligns source traffic, routed traffic, receiving status, DTC transitions, voltage state, resets, and tester timestamps.
The fictional CAN signals are ECU-to-ECU data. They are conceptually distinct from the tester's UDS requests and responses.
UDS evidence reflects data and monitoring exposed by a server ECU. It may be filtered, latched, sampled, delayed, or represented differently from a raw capture.
Synthetic event timeline
A 1.8-second inconsistency with several plausible causes
The fictional model expects VehicleSpeed_A every 20 ms. The values below illustrate correlation logic only; they are not real specifications or traces.
| Synthetic time | Operational observation | Diagnostic observation | Interpretation boundary |
|---|---|---|---|
| 01T-2.0 s | Source and routed captures both show the declared 20 ms pattern; speed values agree within the fictional model. | Forward Assist ECU reports data valid; no current synthetic timeout. | Establishes a local baseline, not long-term network health. |
| 02T+0.0 s | Source segment continues; routed segment stops receiving VehicleSpeed_A while unrelated routed traffic remains. | No immediate DTC transition is yet visible. | Suggests a selective route/path/monitoring issue, but clock alignment and capture loss must be excluded. |
| 03T+0.12 s | Routed segment still lacks the signal; source counter continues. | Forward Assist ECU changes speed-valid state to false and records U1A20-SYN as pending. | Correlated observation supports receiver detection of stale data; it does not identify gateway hardware as the cause. |
| 04T+0.46 s | Signal resumes after a counter discontinuity on the routed side; source side shows no matching discontinuity. | Live speed remains at last value briefly, then updates; DTC becomes stored in the fictional model. | Could reflect routing interruption, receiver presentation delay, capture artifact, or separate clocks. |
| 05T+1.80 s | Both segments appear normal. | Current validity returns; stored DTC and synthetic snapshot remain. | Normal present data does not erase evidence of the earlier event or prove the cause is gone. |
Evidence and competing hypotheses
Keep alternatives visible until the evidence separates them.
The case becomes useful when each fact is paired with alternative explanations and a discriminating check. No single row below is a replacement instruction.
| Observation domain | Observed | Competing hypotheses | Evidence to discriminate | Conclusion boundary |
|---|---|---|---|---|
| 01Timeout reported by consumer | The fictional Forward Assist ECU stores U1A20-SYN: VehicleSpeed_A age exceeded its declared monitoring limit. | Source stopped; gateway stopped routing; receiving bus/path failed; receiver reset; power event; configuration mismatch; monitoring or diagnostic artifact. | Time-aligned source and destination captures, source counter, unrelated traffic, ECU reset/power status, gateway routing/configuration state, DTC status progression. | The receiving ECU identified stale input; it did not directly identify the failed element. |
| 02Live data disagrees | Tester display shows 42 units while a passive capture decodes 47 units at a nearby time. | Different timestamps; diagnostic update rate; filtering/scaling; last-valid hold; wrong signal definition; decode error; unsynchronized clocks; genuine inconsistency. | Definitions in the synthetic model, raw payload and counter, diagnostic response time, acquisition timestamps, scaling, update behavior, repeated controlled transitions. | Two displayed numbers are not inconsistent until source, meaning, unit, and time base are aligned. |
| 03Several modules store faults | Forward Assist, Cruise Control, and Cluster ECUs record related synthetic missing-data codes. | Shared source or route loss; common power event; gateway state; each receiver independently affected; secondary cascades after one module reset. | Network topology, first-fault timing, source presence, module uptime/reset data, voltage record, fault status bytes, snapshots, and recovery order. | Fault count is not a vote that condemns the named source module. |
| 04DTC cleared and does not return | After codes are cleared, the synthetic concern does not recur during a short stationary check. | Transient condition gone; trigger not reproduced; clearing changed state; intermittent harness/power issue; route only fails under load; original evidence was artifactual. | Preserved pre-clear report, authorized reproduction conditions, longer monitoring, power/load/temperature context, event history, and procedure-defined verification. | Non-recurrence during a different condition is not proof of repair. |
Verification approach
Turn a plausible explanation into a reviewable evidence path.
The verification goal is to locate where valid information ceases to be valid while protecting the network and preserving initial evidence. Active transmission is outside this educational case.
Preserve before clearing
Save the complete diagnostic report, DTC status, snapshots, module identification, mileage/time, complaint context, and any low-voltage or recent service history.
Draw the applicable topology
Using authorized information, identify the signal source, routes/gateways, receiving modules, power domains, network segments, and monitoring point represented by each code.
Validate the measurement system
Confirm approved connection, electrical loading, timestamps, clock alignment, channel placement, decode definitions, units, and capture continuity before interpreting a trace.
Compare source and destination
Observe the same declared information on both sides of the route where lawful and safe; compare counters, freshness, validity, related traffic, and module state.
Correlate power and resets
Check applicable power/ground evidence, module uptime/reset information, startup/shutdown state, and low-voltage history so a network symptom is not detached from its electrical cause.
Reproduce only under authority
Use the OEM diagnostic procedure and safe conditions. Do not inject traffic, bypass security, disturb safety functions, or create a road hazard to provoke the event.
Verify the repair claim
State the repaired element and causal evidence, then use procedure-defined checks and representative conditions. Retain pre- and post-repair records and remaining limitations.
Findings
What the reasoning model establishes.
These findings belong to the fictional model. They demonstrate reasoning patterns, not a diagnosis of any production vehicle.
The reporter is not automatically the source
A receiving controller can accurately report stale data while remaining healthy. Root cause may exist upstream, in a gateway, in power, or in the measurement setup.
Time alignment changes conclusions
Raw traffic, gateway traffic, UDS live data, DTC snapshots, and human notes can use different time bases and update rates. Correlation without synchronization can create false disagreement.
DTC status carries sequence information
Pending, current, stored, history, test-failed, and recovery behavior—when defined by the applicable system—can help reconstruct the event more effectively than text descriptions alone.
Present health is not event history
A network can look normal after recovery. Stored evidence, counters, reset information, and captured transitions remain necessary to understand an intermittent event.
Limitations
What this publication does not prove.
- 01
Every identifier, value, module, signal, and fault label is fictional; none should be searched for or applied to a real vehicle.
- 02
The case simplifies CAN arbitration, gateways, diagnostics, scheduling, error handling, security, timing, and ECU implementation.
- 03
It does not teach intrusive testing or establish that passive capture is permitted, safe, or sufficient on a specific vehicle.
- 04
ISO references describe protocol scope; this page does not reproduce their normative requirements or claim conformance.
Safe next action
Convert uncertainty into controlled work.
For learners
Recreate the logic with an offline synthetic trace or simulator. Practice clock alignment, source/destination comparison, DTC-state interpretation, and explicit uncertainty.
For real vehicle work
Use authorized service information, approved interfaces, qualified personnel, electrical safety practices, and a non-intrusive evidence plan. Escalate when access or expertise is insufficient.
For an intermittent safety-system concern
Preserve initial records, advise the driver according to the owner's information, avoid relying on the affected feature, and arrange qualified diagnosis rather than clearing evidence repeatedly.
Decision rule
Make the evidence earn the conclusion.
A strong engineering statement separates confirmed observations, reasonable hypotheses, verification evidence, unresolved uncertainty, and the authority governing the next vehicle-specific action.
“A communication diagnosis is strongest when the missing or invalid information is traced from source to consumer on a synchronized timeline and the proposed cause explains both failure and recovery.”
References
Author, date, and version history
Initial public release by Sainath Reddy Puchakayala: original architecture, evidence matrix, verification approach, findings, limitations, and safe-next-action framework.
The wording, organization, diagrams, matrices, synthetic examples, and reasoning framework on this page were created specifically for Project VISION ADAS. Public sources support factual context and are cited above. No OEM diagram, proprietary dataset, paid service information, or third-party illustration is reproduced.
This independent educational publication is not an OEM procedure, vehicle diagnosis, repair instruction, calibration specification, legal requirement, completed validation report, or certification of performance. Actual architectures and requirements vary. Current manufacturer information and qualified professional judgment control vehicle-specific decisions.