Camera–Radar Diagnostic Evidence Matrix
A product-neutral method for separating obstruction, geometric state, electrical faults, network faults, and environmental limitations before naming a cause.
Engineering question
When a camera- or radar-supported feature becomes unavailable or behaves unexpectedly, what evidence can distinguish a physical obstruction, misalignment, electrical fault, network fault, or environmental limitation?
The same driver message can sit at the end of several very different causal paths. A disciplined diagnosis therefore begins with evidence domains, not a favorite component.
A blocked sensor face, a displaced bracket, low supply voltage, a missing network message, and a scene outside the sensor's useful operating conditions can all reduce feature availability. Their outward symptoms may overlap, but their evidence patterns should not be treated as interchangeable.
This matrix organizes the investigation around independent observations: physical condition, geometric relationship, electrical integrity, communication integrity, and operating context. It asks what would support each hypothesis, what would weaken it, and what still must be verified under current vehicle-specific service information.
System boundary and assumptions
Define what the model can—and cannot—support.
- Forward camera and radar as conceptual sensing paths
- Feature status, warnings, DTCs, live/status data, physical observations, and repair history
- Reasoning about five broad fault or limitation domains
- A product-neutral evidence-gathering sequence
- The investigator has lawful access, suitable training, and approved equipment
- Exact sensor roles and feature logic vary by make, model, configuration, and software level
- A current OEM procedure is available before testing, adjustment, or calibration
- Observations are time-stamped and tied to the same vehicle and complaint event
- Universal voltage, resistance, angle, distance, or target specifications
- Instructions to adjust, aim, calibrate, or road-test a specific vehicle
- A determination that a feature is safe or fully functional
- Replacement decisions based only on this educational matrix
Original architecture / dependency diagram
One symptom, five evidence branches
The branch structure prevents a visible condition or stored code from becoming an automatic root-cause statement. Each path must be tested against independent evidence.
- 01Observe
Define the event
Capture the exact message, feature state, timing, operating context, and recent service history.
- 02Separate
Open five domains
Consider obstruction, geometry, electrical integrity, communication integrity, and environmental limits in parallel.
- 03Discriminate
Seek unique evidence
Ask which measurements or observations would support one path while weakening plausible alternatives.
- 04Cross-check
Correlate the record
Align DTC status, data quality, physical condition, network timing, and event context.
- 05Conclude
State only what is supported
Name confirmed facts, remaining uncertainty, and the authorized next procedure without overreach.
Current OEM service information determines inspection points, prerequisites, tooling, procedures, and acceptance criteria.
Preserve initial scan data and event context before clearing codes, disturbing a mount, disconnecting power, or changing configuration.
Five-domain comparison
What changes across the evidence domains?
The table describes general evidence patterns. It deliberately avoids universal specifications because vehicle design and service requirements differ.
| Domain | Mechanism | Evidence that may support it | Evidence that may weaken it |
|---|---|---|---|
| 01Obstruction | Material or surface condition limits energy transmission or view of the scene. | Documented contamination, covering, ice, film, damage, or an OEM-recognized blocked-sensor status that corresponds to the event. | A clean surface after the event does not disprove a temporary obstruction; scene records and event timing are still needed. |
| 02Misalignment / geometry | The sensor-to-vehicle or sensor-to-world relationship differs from the design assumption. | Relevant impact or repair history, disturbed mounting, body or glass work, alignment-related work, physical displacement, or procedure-specific calibration evidence. | A bracket that looks straight is not geometric proof. Conversely, a calibration-related code does not by itself identify which physical condition caused it. |
| 03Electrical | Power, ground, connector, wiring, internal electronics, or thermal state interrupts reliable operation. | Applicable circuit measurements, connector evidence, module reset history, internal fault status, repeatable loss under defined conditions, or correlated power events. | Normal voltage at one moment or communication with a module does not prove circuit integrity across load, time, and temperature. |
| 04Network / data | Required information is missing, late, stale, implausible, misconfigured, or unavailable across a communication path. | Timeout or invalid-data evidence, synchronized traces, source-versus-destination comparison, gateway status, configuration records, or correlated multi-module faults. | A communication DTC may be secondary to power loss or a deliberate shutdown state. Code wording alone is not topology proof. |
| 05Environmental limitation | The scene or propagation conditions reduce useful sensing even though hardware may be functioning as designed. | Strong correspondence with glare, precipitation, spray, fog, low contrast, occlusion, unusual reflectivity, road geometry, or a documented temporary limitation state. | A difficult environment should not be used to dismiss a repeatable fault in ordinary conditions; reproduce and compare where safe and authorized. |
Evidence and competing hypotheses
Keep alternatives visible until the evidence separates them.
The matrix below starts from an observation and keeps multiple explanations alive until evidence separates them. The final column is intentionally conservative: it identifies what the current record cannot yet prove.
| Observation domain | Observed | Competing hypotheses | Evidence to discriminate | Conclusion boundary |
|---|---|---|---|---|
| 01Sensor blocked message | A temporary forward-sensor obstruction or visibility message appears during heavy spray and later clears. | Actual surface obstruction; propagation or contrast limitation; heater or circuit concern; software status logic; unrelated intermittent fault. | Time-aligned weather and scene notes, sensor-area condition before cleaning, DTC status, availability transition, repeatability, and applicable OEM status definitions. | Do not call the sensor defective—or proven healthy—solely because the message cleared. |
| 02Post-repair unavailability | A camera- or radar-supported feature is unavailable after glass, bumper, structural, suspension, or alignment-related work. | Required procedure not completed; mounting or geometric change; connector or harness issue; configuration change; unrelated pre-existing concern. | Repair chronology, pre- and post-repair scans, part and installation records, mounting inspection, alignment/calibration documentation, and current OEM requirements. | Chronology raises relevance but does not, by itself, prove workmanship or component failure. |
| 03Multiple communication codes | Several modules record loss-of-communication or invalid-data faults near the same time. | Shared power event; network segment issue; gateway or source-module loss; low-voltage event; diagnostic-session artifact; cascaded secondary faults. | Code status and timestamps where available, voltage history, topology, awake/asleep state, source signal presence, network trace, and known service events. | Do not replace the module named in the most codes without locating the missing source and confirming the path. |
| 04Camera/radar disagreement | One sensing path reports a plausible object while another has low confidence or no associated track. | Different fields of view; target reflectivity or visual ambiguity; time or coordinate mismatch; occlusion; mounting state; association logic; sensor fault. | Synchronized object data, timestamps, track history, relative geometry, host motion, scene record, calibration history, and sensor/module status. | Disagreement is evidence about the system state; it is not automatic proof that the lower-confidence sensor failed. |
| 05No DTC, poor behavior reported | A driver reports inconsistent feature behavior but no relevant DTC is currently stored. | Intermittent fault; intended operating limitation; unmet precondition; inaccurate complaint context; event not monitored by diagnostics; repaired or cleared history. | Precise complaint interview, event conditions, warning/status history, complete scan, service history, authorized reproduction plan, and objective measurements. | The absence of a DTC does not validate feature performance or disprove the report. |
Verification approach
Turn a plausible explanation into a reviewable evidence path.
Verification should narrow hypotheses without destroying the starting evidence. The exact procedure and acceptable results must come from the current OEM information for the identified vehicle.
Freeze the initial record
Record the complaint, exact warning language, mileage, environmental context, feature state, complete scan, and relevant history before changing the vehicle.
Confirm identity and configuration
Verify vehicle identifiers, installed equipment, software/configuration state where authorized, and which sensors and modules actually support the affected feature.
Inspect without disturbance
Document accessible sensor areas, mounting surroundings, connectors, repairs, and obvious conditions before cleaning, moving, unplugging, or adjusting anything.
Test the suspected domain
Use the applicable circuit, network, physical, or procedure-specific checks. Compare the suspected path with an independent source whenever possible.
Reassess competing explanations
Ask which hypotheses became stronger, which became weaker, and whether the evidence supports cause, correlation, or only an unresolved association.
Verify the authorized outcome
Follow the current OEM completion and verification process. Record results and limitations; do not substitute message disappearance for performance evidence.
Findings
What the reasoning model establishes.
These are findings from the reasoning model, not findings from a completed vehicle test.
Symptom overlap is normal
Feature unavailability can be the system's common response to very different internal or external conditions. The shared message should widen the early investigation, not collapse it.
Physical appearance has limited reach
A clean surface and an undamaged-looking bracket are valuable observations, but neither establishes optical/radar transparency, circuit integrity, geometric accuracy, data integrity, or full feature performance.
DTCs are relational evidence
A code identifies a monitored condition from one module's point of view. Topology, power state, timestamps, source data, and secondary effects determine how strongly it supports a root-cause claim.
Context can be causal evidence
Weather, glare, road geometry, target characteristics, and repair timing are not background decoration. When carefully recorded, they help distinguish a temporary performance limitation from a repeatable malfunction.
Limitations
What this publication does not prove.
- 01
This publication does not contain a make/model-specific topology, specification, calibration method, aiming target, scan sequence, or acceptance criterion.
- 02
Sensor blockage and limitation detection differ by vehicle; a warning label cannot be generalized across manufacturers.
- 03
A diagnostic conclusion may require measurements, protected service information, controlled testing, or equipment unavailable to the reader.
- 04
The matrix cannot establish functional safety, SOTIF conformity, repair quality, or real-world performance.
Safe next action
Convert uncertainty into controlled work.
For an active warning
Follow the owner's manual, maintain driver responsibility, avoid relying on the affected assistance feature, document the condition, and arrange qualified service.
For a service investigation
Preserve initial evidence, retrieve current OEM information, verify the system boundary, and refer or escalate when tooling, authority, environment, or competence is insufficient.
For a suspected calibration concern
Do not adjust a sensor or improvise a target. Establish the triggering event and prerequisites, then follow the applicable vehicle-specific procedure with approved equipment and conditions.
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.
“Name a cause only when the evidence explains the symptom, fits the system architecture, survives an independent cross-check, and is verified by the applicable procedure.”
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.