Trace the applicable data definition
Identify the relevant ECU variant and follow service, parameter, and conversion references for the diagnostic exchange being investigated. Preserve the source definition behind each interpretation.
Vehicle Diagnostics
Trace diagnostic behavior through ODX data
ODX analysis explains how supplied diagnostic descriptions map services, parameters, and coded responses to an ECU variant. I trace the definitions relevant to a concrete request or interpretation problem and document the data path that an application should use.
Discuss ODX AnalysisProblems I can investigate
Find the behavior behind the symptom
- 01
DID read failure
Trace whether a DID read issue is related to the diagnostic definition, service parameters, session context, or interpretation of returned data. Findings are documented against the supplied ODX or PDX content and available evidence.
- 02
Diagnostic application needed
Build a focused application when a team needs a repeatable way to work with ECU diagnostic services, interpret diagnostic data, or support a defined workflow from requirements.
What I can help with
Focused engineering work in Vehicle Diagnostics
Explain coded diagnostic responses
Map the request and response parameters to their diagnostic definitions, distinguishing a missing definition from a value that conflicts with the expected interpretation.
Transport and communication context
Relate diagnostic definitions to ISO-TP or DoIP communication context where those requirements are part of the supplied material or engineering question.
Tool-assisted engineering utilities
Use CANoe and CAPL where appropriate to examine, automate, or prototype a defined diagnostic workflow, including integration considerations for a DCM-based implementation.
What to send
Start with the evidence you already have
ODX
The ODX diagnostic-data description, including the scope and revision relevant to the analysis.
PDX
The packaged diagnostic data and related assets available for review.
Requirements
System, software, or stakeholder requirements defining the expected analysis, application behavior, or conversion result.
How the analysis works
From recorded data to engineering findings
- 01
Establish scope and evidence
Review the requirements and supplied ODX or PDX material, identify the diagnostic scope, and record questions where the available data is incomplete or ambiguous.
- 02
Parse and inspect the data
Extract the relevant diagnostic definitions and examine their relationships to services, DIDs, DTCs, sessions, routines, and security access.
- 03
Compare against the engineering need
Assess the parsed data against the stated workflow or failure scenario, with attention to interpretation, transport context, and assumptions that require confirmation.
- 04
Implement or generate the requested artifact
Produce the agreed analysis, diagnostic application, or data converter using a repeatable approach suited to the supplied requirements and data.
- 05
Review findings and hand over
Present evidence, limitations, and open points, then provide the resulting engineering artifact with practical guidance for verification.
What you receive
Deliverables matched to the investigation
Engineering analysis
A documented technical analysis with evidence, findings, assumptions, and open questions concerning the supplied ODX or PDX data.
Diagnostic application
Software for executing and interpreting ECU diagnostic services within the defined requirements and available diagnostic data.
Data converter
A repeatable utility that transforms the supplied automotive diagnostic data between the agreed representations.
Technologies & formats
Automotive data and analysis environments
- ODX
Open Diagnostic Data Exchange
An ASAM model for machine-readable ECU diagnostic data.
- PDX
Packed ODX Exchange
A distributable package containing related ODX documents and assets.
- UDS
Unified Diagnostic Services
ISO 14229 diagnostic services for communicating with vehicle ECUs.
- DID
Data Identifier
A UDS identifier addressing diagnostic data exposed by an ECU.
- DTC
Diagnostic Trouble Code
A coded diagnostic record identifying a detected fault condition.
- ISO-TP
ISO 15765-2 Transport Protocol
A segmented transport protocol for messages carried over CAN.
- DoIP
Diagnostics over Internet Protocol
Diagnostic transport over IP networks as defined by ISO 13400.
- Diagnostic Session
Diagnostic Session
An ECU diagnostic operating mode controlling service availability and timing.
- Routine Control
Routine Control
The UDS service used to start, stop, or request results from ECU routines.
- Security Access
Security Access
A diagnostic challenge-response mechanism that unlocks protected ECU services.
- CANoe
Vector CANoe
A development, simulation, test, and analysis environment for vehicle networks.
- CAPL
Communication Access Programming Language
Vector event-driven language for network simulation, testing, and automation.
- DCM
Diagnostic Communication Manager
The Classic AUTOSAR basic-software module handling diagnostic communication.
FAQ
Practical questions before an investigation
- How is ODX analysis different from an ODX review?
- Analysis answers a specific interpretation question, such as which variant definition and conversion apply to a returned parameter. A review checks the quality and consistency of a broader description package. For analysis, provide the relevant diagnostic exchange and the ODX or PDX version used by the application.
- What can an ODX analysis cover?
- It can cover structure, relationships, and consistency across ODX and PDX data, including definitions related to UDS services, DIDs, DTCs, diagnostic sessions, routine control, and security access.
- Can you investigate a DID read failure?
- Yes. The investigation can compare the DID definition, diagnostic context, available requirements, and reported behavior. The result distinguishes supported findings from assumptions that need further evidence.
- Can the work include a diagnostic application?
- Yes. A focused diagnostic application can be generated from defined requirements and supplied diagnostic data, with its scope limited to the ECU workflows that have been specified.
- Do I need to provide both ODX and PDX?
- No. The available input may be ODX, PDX, or both. Requirements and any relevant failure evidence help determine the most useful analysis scope.
Discuss the evidence
Discuss ODX Analysis
Share the relevant ODX or PDX data and requirements to define a focused analysis, application, or converter scope.