Modern vehicle diagnostics increasingly require the integration of heterogeneous information: diagnostic trouble codes (DTCs), OBD-II parameters, CAN-bus messages, service manuals, wiring diagrams, technical service bulletins, repair procedures, component specifications, sensor behavior, historical maintenance records, vehicle configurations, and real-time observations.

A conventional Large Language Model (LLM) is poorly suited to this problem when used alone. Automotive diagnostic knowledge is highly domain-specific, continuously changing, relational, and dependent on vehicle configuration and operating conditions. A conventional vector Retrieval-Augmented Generation (RAG) system improves grounding but can still struggle when the diagnostic problem requires connecting multiple entities and relationships across documents.

Agentic GraphRAG for OBD-AI

A Knowledge-Graph and Agent Architecture for Intelligent Automotive Diagnostics-Research White Paper

Strategic Technology Framework for OBD-AI, KeenComputer.com, IAS-Research.com, and KeenDirect.com

Abstract

Modern vehicle diagnostics increasingly require the integration of heterogeneous information: diagnostic trouble codes (DTCs), OBD-II parameters, CAN-bus messages, service manuals, wiring diagrams, technical service bulletins, repair procedures, component specifications, sensor behavior, historical maintenance records, vehicle configurations, and real-time observations.

A conventional Large Language Model (LLM) is poorly suited to this problem when used alone. Automotive diagnostic knowledge is highly domain-specific, continuously changing, relational, and dependent on vehicle configuration and operating conditions. A conventional vector Retrieval-Augmented Generation (RAG) system improves grounding but can still struggle when the diagnostic problem requires connecting multiple entities and relationships across documents.

This paper proposes an Agentic GraphRAG architecture for OBD-AI in which an AI diagnostic agent combines:

  1. Large Language Models;
  2. Vector retrieval;
  3. Knowledge graphs;
  4. Graph traversal;
  5. Structured diagnostic reasoning;
  6. Agentic query planning;
  7. Real-time OBD/CAN data;
  8. Service-manual retrieval;
  9. Vehicle-specific configuration;
  10. Human-in-the-loop verification.

The architecture is informed particularly by Essential GraphRAG by Tomaž Bratanič and Oskar Hane, which describes the combination of vector retrieval, hybrid search, Text2Cypher, Agentic RAG, LLM-based knowledge-graph construction, Microsoft GraphRAG, and RAG evaluation.

The second supplied reference, Electronic System Level Design: An Open-Source Approach, provides an important complementary engineering perspective. It emphasizes abstraction, reuse, automation, exploration, hardware/software co-design, SystemC/TLM, platform modeling, debugging, and virtual prototyping.

Together, these concepts provide a foundation for an OBD-AI system that does not simply "chat about cars," but builds an evidence-grounded diagnostic reasoning environment connecting vehicle electronics, software, diagnostic data, engineering knowledge, and AI agents.

1. Introduction

1.1 From chatbot to diagnostic engineering system

Automotive diagnostics is fundamentally a knowledge-integration problem.

A technician may begin with:

"Check engine light is on and the vehicle reports P0171."

That apparently simple observation can require investigation of:

  • engine configuration;
  • fuel system;
  • oxygen sensors;
  • mass-airflow sensor;
  • manifold pressure;
  • intake leaks;
  • fuel pressure;
  • injector operation;
  • exhaust leaks;
  • ECU strategy;
  • freeze-frame data;
  • short-term fuel trim;
  • long-term fuel trim;
  • engine temperature;
  • vehicle speed;
  • load;
  • RPM;
  • previous repairs;
  • service history;
  • technical service bulletins.

A text-only LLM does not inherently possess this vehicle-specific state.

A conventional RAG system improves the situation by retrieving relevant service-manual passages.

A GraphRAG system goes further by representing relationships such as:

Vehicle | +-- has ECU | +-- has Engine | +-- has Sensor | +-- reports DTC | +-- exhibits Symptom | +-- has Repair History | +-- covered by Service Manual

An Agentic GraphRAG system adds an intelligent control layer capable of deciding which information should be retrieved, which graph relationships should be traversed, which measurements should be requested, and when the evidence is sufficient to produce a diagnostic hypothesis.

2. Research Foundation

2.1 Essential GraphRAG

The supplied Essential GraphRAG reference describes GraphRAG as an approach for improving LLM accuracy, performance, and traceability by combining structured and unstructured information. It explicitly identifies vector similarity search, hybrid retrieval, Text2Cypher, Agentic RAG, knowledge-graph construction, Microsoft GraphRAG, and application evaluation as major components.

The book identifies several fundamental LLM limitations:

  • knowledge cutoff;
  • outdated information;
  • hallucination;
  • lack of private information;
  • inconsistent responses;
  • prompt injection vulnerabilities.

It describes RAG as a mechanism for connecting an LLM to an external knowledge base and emphasizes that Knowledge Graphs can connect structured and unstructured information.

This is highly applicable to automotive diagnostics.

A service manual is primarily unstructured or semi-structured knowledge.

An OBD data stream is structured.

A vehicle configuration is structured.

A diagnostic narrative is unstructured.

A graph provides the common semantic layer.

3. Why GraphRAG Matters for Automotive Diagnostics

3.1 Conventional vector RAG

A conventional RAG architecture can be represented as:

User Question | v Embedding Model | v Vector Database | v Relevant Documents | v LLM | v Answer

For example:

"What causes P0171?"

The vector database might retrieve passages discussing:

  • lean mixture;
  • fuel trim;
  • vacuum leaks;
  • MAF sensors;
  • fuel pressure.

This is useful.

However, the diagnostic question may actually be:

"Given P0171, high positive LTFT, normal MAF at idle, elevated STFT under load, engine temperature of 92°C, and no other DTCs, what diagnostic paths should be investigated first?"

This is a multi-dimensional reasoning problem.

4. GraphRAG Architecture

A GraphRAG architecture adds explicit relationships.

+----------------------+ | LLM / VLM | +----------+-----------+ | Diagnostic Agent | +--------------+--------------+ | | Vector Retrieval Graph Retrieval | | Service Manuals Neo4j Knowledge Graph | | +--------------+--------------+ | Evidence Fusion | Diagnostic Reasoning | Human Verification

Microsoft's GraphRAG documentation describes a structured, hierarchical approach in which a knowledge graph is extracted from source material, community structures are generated, summaries are produced, and those structures are used for retrieval.

The Microsoft implementation should therefore be viewed as one architectural pattern rather than the only GraphRAG implementation. Its current repository describes the project as largely being in maintenance mode, making it particularly important to distinguish the GraphRAG methodology from any single software implementation.

5. The OBD-AI Knowledge Graph

The proposed OBD-AI graph should model automotive knowledge as interconnected entities.

5.1 Core entities

A possible ontology is:

Vehicle ├── VehicleModel ├── Engine ├── ECU ├── Sensor ├── Actuator ├── Network ├── CANMessage ├── DiagnosticParameter ├── DTC ├── Symptom ├── Fault ├── Component ├── TestProcedure ├── RepairProcedure ├── ServiceManual ├── TechnicalBulletin ├── Specification ├── Tool └── RepairEvent

5.2 Relationships

Examples include:

Vehicle ──HAS_ENGINE──> Engine Vehicle ──HAS_ECU──> ECU ECU ──MONITORS──> Sensor Sensor ──GENERATES──> DiagnosticParameter ECU ──REPORTS──> DTC DTC ──ASSOCIATED_WITH──> Symptom DTC ──MAY_INDICATE──> Fault Fault ──MAY_INVOLVE──> Component Component ──TESTED_BY──> TestProcedure TestProcedure ──DEFINED_IN──> ServiceManual Fault ──RESOLVED_BY──> RepairProcedure Vehicle ──HAS_HISTORY──> RepairEvent

This graph transforms isolated pieces of information into a connected diagnostic model.

6. Agentic GraphRAG

6.1 From retrieval pipeline to reasoning loop

Traditional RAG:

Question ↓ Retrieve ↓ Generate

Agentic RAG:

Question ↓ Interpret ↓ Plan ↓ Retrieve ↓ Evaluate Evidence ↓ Retrieve Again if Necessary ↓ Graph Traversal ↓ Generate Hypothesis ↓ Request Additional Data ↓ Validate ↓ Answer

Hugging Face's current smolagents documentation describes agents as multi-step systems capable of using tools, with CodeAgent and ToolCallingAgent architectures.

Its Agentic RAG example explicitly identifies iterative retrieval, query reformulation, reasoning over retrieved material, and self-correction as advantages over a single retrieval step.

These capabilities map naturally to vehicle diagnostics.

7. OBD-AI Agent Architecture

A proposed OBD-AI agent can contain specialized tools.

OBD-AI Diagnostic Agent | +---------------------+----------------------+ | | | OBD Tool Graph Tool RAG Tool | | | Read PID Cypher Query Manual Search Read DTC Graph Traversal TSB Search Freeze Frame Relationship Search Repair Procedure CAN Data Vehicle Ontology Specification | | | +---------------------+----------------------+ | Evidence Engine | Diagnostic Hypothesis | Verification Agent

8. Proposed OBD-AI Agent Roles

8.1 Vehicle Identification Agent

Responsibilities:

  • VIN-related metadata where legally and technically available;
  • year;
  • make;
  • model;
  • engine;
  • transmission;
  • ECU;
  • market;
  • configuration;
  • emissions configuration.

Its purpose is to ensure that diagnostic evidence applies to the actual vehicle.

8.2 DTC Interpretation Agent

Input:

P0171

Output should not immediately be:

"Replace the oxygen sensor."

Instead:

DTC ↓ Definition ↓ Vehicle applicability ↓ Known associated systems ↓ Possible causes ↓ Required observations ↓ Diagnostic tests

This distinction is essential.

A diagnostic AI should differentiate between:

DTC meaning

and

root cause hypothesis.

9. CAN and OBD Data Agent

The OBD-AI platform can use an OBD-II interface to obtain:

  • DTCs;
  • engine RPM;
  • vehicle speed;
  • coolant temperature;
  • throttle position;
  • calculated load;
  • fuel trims;
  • intake-air information;
  • oxygen-sensor-related parameters;
  • other supported PIDs.

For CAN-oriented development, the architecture can additionally represent:

CAN Bus | +-- CAN Frame | +-- CAN ID +-- Signal +-- Bit Position +-- Length +-- Scaling +-- Unit +-- ECU

These become graph entities rather than merely raw data fields.

10. Diagnostic Knowledge Graph Example

Consider:

DTC: P0171

The graph may contain:

P0171 | +-- indicates --> System Lean | +-- affects --> Fuel Control | +-- associated_with --> Fuel Trim | +-- associated_with --> Intake System | +-- associated_with --> MAF | +-- associated_with --> Fuel Pressure | +-- associated_with --> Oxygen Sensor | +-- diagnostic_procedure --> Intake Leak Test | +-- diagnostic_procedure --> Fuel Pressure Test | +-- diagnostic_procedure --> MAF Evaluation

Now add live observations:

LTFT = +18% STFT = +12% MAF = expected range Coolant = normal RPM = 750

The agent can combine:

Live Data + Graph Relationships + Service Manual + Historical Evidence

before generating its next diagnostic action.

11. Graph + Vector Hybrid Retrieval

One of the strongest architectures for OBD-AI is hybrid Graph + Vector RAG.

Vector retrieval is useful for:

  • finding similar passages;
  • locating service-manual procedures;
  • retrieving textual explanations;
  • searching technical bulletins;
  • finding repair narratives.

Graph retrieval is useful for:

  • entity relationships;
  • vehicle configuration;
  • DTC/component relationships;
  • ECU relationships;
  • signal dependencies;
  • multi-hop reasoning;
  • causal or diagnostic paths.

Therefore:

User Question | Query Understanding | +-----------+-----------+ | | Vector Search Graph Search | | Textual Evidence Structured Evidence | | +-----------+-----------+ | Evidence Fusion | Diagnostic Agent

Neo4j's current GraphRAG Python package explicitly supports vector retrieval, graph retrieval, vector-database integration, knowledge-graph construction, and custom retrieval strategies.

12. Neo4j as the OBD-AI Graph Platform

A practical implementation can use Neo4j.

A simplified graph could be:

(:Vehicle) (:Engine) (:ECU) (:Sensor) (:DTC) (:PID) (:CANMessage) (:Component) (:Procedure) (:Manual) (:Symptom) (:Repair)

Relationships:

(:Vehicle)-[:HAS_ENGINE]->(:Engine) (:Vehicle)-[:HAS_ECU]->(:ECU) (:ECU)-[:READS]->(:Sensor) (:ECU)-[:REPORTS]->(:DTC) (:DTC)-[:ASSOCIATED_WITH]->(:Component) (:Component)-[:TESTED_BY]->(:Procedure) (:Procedure)-[:DOCUMENTED_IN]->(:Manual)

Neo4j's current GraphRAG library provides a GraphRAG abstraction with retrievers and LLM interfaces, while also supporting Text2Cypher retrieval.

13. Text2Cypher for OBD-AI

Text2Cypher enables a natural-language diagnostic question to be transformed into a graph query.

Example:

"Which sensors are associated with P0171 for this engine?"

Conceptually:

MATCH (d:DTC {code:"P0171"}) MATCH (d)-[:ASSOCIATED_WITH]->(c:Component) MATCH (c)-[:IS_SENSOR]->(s:Sensor) RETURN s

However, an automotive production system should not blindly execute arbitrary LLM-generated database queries.

The architecture should include:

LLM-generated Cypher ↓ Schema validation ↓ Query allow-list / policy ↓ Read-only transaction ↓ Result validation ↓ Evidence returned to agent

Neo4j's documentation explicitly notes that generated Text2Cypher queries are not guaranteed to be syntactically correct, reinforcing the need for validation and controlled execution.

14. Knowledge-Graph Construction Pipeline

The OBD-AI knowledge base may ingest:

  • OEM service manuals;
  • aftermarket manuals;
  • publicly available technical documentation;
  • diagnostic standards;
  • DTC databases;
  • wiring documentation;
  • sensor specifications;
  • CAN databases where licensed;
  • technical service bulletins;
  • user-provided repair records.

A knowledge-graph pipeline can be:

PDF / HTML / Database / CSV | v Document Loader | v Text Extraction | v Chunking | v Entity Extraction | v Relationship Extraction | v Schema Validation | v Entity Resolution | v Graph Database | v Vector Indexes

Neo4j's current knowledge-graph builder documentation identifies components including data loading, text splitting, optional embeddings, schema construction, lexical graph construction, entity/relation extraction, and graph pruning.

15. Hugging Face Framework

Hugging Face can form an important part of the OBD-AI AI/ML layer.

15.1 Model layer

Potential components include:

  • Transformers;
  • Sentence Transformers;
  • Hugging Face Hub;
  • Datasets;
  • PEFT;
  • TRL;
  • smolagents;
  • inference services;
  • local Transformer models.

The architecture should avoid coupling the system permanently to one LLM.

OBD-AI | Model Abstraction | +---------+----------+ | | | HuggingFace Ollama API Models | | | +---------+----------+ | Agent Layer

Hugging Face's smolagents is explicitly model-agnostic and can integrate models from the Hub, APIs, Transformers, Ollama, and other providers.

16. Hugging Face smolagents

smolagents is particularly relevant to the proposed architecture because it supports:

  • multi-step agents;
  • tool calling;
  • code agents;
  • custom tools;
  • MCP-based tools;
  • Hub tools;
  • local models;
  • API models;
  • sandboxed execution options.

For OBD-AI, custom tools could include:

read_dtc() read_pid() read_freeze_frame() read_can_frame() query_vehicle_graph() search_service_manual() search_tsb() run_diagnostic_test() lookup_component() get_vehicle_configuration() validate_diagnosis()

The agent should not directly control vehicle actuators without explicit safety controls.

17. Hugging Face Training Framework

Fine-tuning should not be the first solution to every knowledge problem.

The architecture should distinguish:

Knowledge problem

Use:

RAG GraphRAG Knowledge Graph

Behavioral problem

Use:

Supervised fine-tuning PEFT / LoRA

Agent behavior optimization

Potentially use:

TRL DPO GRPO other reinforcement-learning techniques

Hugging Face TRL currently provides trainers and workflows covering SFT, DPO, GRPO, reward modeling and related post-training approaches.

For OBD-AI, fine-tuning should therefore be reserved for tasks such as:

  • diagnostic language normalization;
  • structured output;
  • tool-selection behavior;
  • automotive terminology;
  • standardized diagnostic explanations;
  • controlled report generation.

The actual service-manual knowledge should generally remain retrievable rather than being permanently embedded into model weights.

18. Embedding Architecture

A semantic embedding model can convert:

Service Manual Diagnostic Procedure DTC Description Repair Note CAN Signal Description

into vectors.

The system can then support:

Semantic Search + Keyword Search + Graph Search + Metadata Filtering

A useful OBD-AI retrieval architecture is therefore:

Query | Query Classification | +----------+----------+ | | | Semantic Keyword Graph Retrieval Search Retrieval | | | +----------+----------+ | Reranking | Evidence Set

19. Agentic Diagnostic Loop

A central OBD-AI research contribution can be the following diagnostic loop.

Step 1 — Observe

Collect:

DTCs PIDs CAN data Vehicle configuration Symptoms History

Step 2 — Interpret

Translate raw information into semantic entities.

Step 3 — Retrieve

Search:

Vector database Knowledge graph Service manuals Technical bulletins Historical records

Step 4 — Hypothesize

Generate one or more possible diagnostic paths.

Step 5 — Identify missing evidence

The agent asks:

What additional observation would most effectively distinguish these hypotheses?

Step 6 — Acquire evidence

Use an approved tool.

Step 7 — Re-evaluate

Update the diagnostic graph/state.

Step 8 — Verify

Compare against:

  • manufacturer procedure;
  • engineering specifications;
  • observed measurements;
  • known constraints.

Step 9 — Explain

Return:

Observed Evidence ↓ Reasoning Path ↓ Possible Causes ↓ Recommended Diagnostic Test ↓ Expected Result ↓ Next Step

20. Diagnostic State Graph

The agent should maintain a diagnostic state rather than treating each user message independently.

Example:

DiagnosticSession | +-- Vehicle | +-- Symptoms | +-- DTCs | +-- Measurements | +-- Hypotheses | +-- Tests | +-- TestResults | +-- Evidence | +-- TechnicianObservations | +-- RepairHistory | +-- FinalDiagnosis

This provides an auditable diagnostic history.

21. Evidence-Based Diagnostic Reasoning

A critical design principle is:

The AI should distinguish evidence from inference.

For example:

Evidence

P0171 detected. LTFT = +18%.

Retrieved evidence

Service documentation associates lean-condition diagnosis with fuel-delivery, intake, MAF and exhaust-related checks.

Hypothesis

An intake leak is one possible cause.

Test

Perform an appropriate intake-leak test.

Result

No leak detected.

Updated hypothesis

Reduce probability of intake-leak hypothesis. Investigate other supported paths.

This is much safer than:

"The MAF sensor is bad."

22. Applying Electronic System Level Design

The supplied Electronic System Level Design reference provides an important engineering foundation for OBD-AI.

It identifies abstraction, reuse, automation and exploration as important approaches for managing electronic-system complexity.

The book also emphasizes:

  • unified hardware/software representation;
  • transaction-level modeling;
  • platform-based design;
  • hardware/software co-design;
  • performance evaluation;
  • power evaluation;
  • debugging;
  • virtual prototyping.

These principles can be transferred into OBD-AI.

23. SystemC/TLM and OBD-AI

SystemC/TLM can provide a research environment for modeling:

ECU | +-- CPU +-- Memory +-- CAN Controller +-- Sensor Interfaces +-- Diagnostic Stack +-- AI Edge Processor

The AI system can then be evaluated against a virtual vehicle platform.

Conceptually:

Virtual Vehicle | +------------+------------+ | | ECU Model Sensor Models | | +------------+------------+ | CAN/TLM | OBD-AI Agent | GraphRAG | AI Diagnosis

The supplied ESL reference explicitly describes executable architectural models, hardware/software partitioning, TLM, post-partition analysis and virtual prototyping.

This creates an opportunity to investigate OBD-AI not only as an application but as a hardware/software/AI co-design research platform.

24. Edge AI Architecture

OBD-AI can eventually be divided into edge and cloud/local infrastructure.

Edge

Vehicle | OBD-II / CAN | STM32 / ARM | Data filtering | Feature extraction | Secure transmission

Local AI gateway

Raspberry Pi / x86 / Industrial PC | MQTT | Local database | Local inference | GraphRAG

Research/cloud layer

Knowledge Graph Vector Database Model Training Analytics Fleet Learning Research Dataset

This enables privacy-sensitive processing while preserving centralized knowledge management where appropriate.

25. MQTT Event Architecture

A possible architecture:

OBD Adapter | v CAN/OBD Collector | v MQTT Broker | +---+-------------------+ | | v v Time-Series DB AI Pipeline | +-------+-------+ | | Vector DB Graph DB | | +-------+-------+ | Agentic RAG

MQTT is particularly suitable for asynchronous vehicle telemetry and distributed diagnostic environments.

26. OBD-AI Software Architecture

A proposed software stack:

Layer

Candidate Technology

Vehicle interface

OBD-II / CAN

Embedded

STM32 / ARM

RTOS

FreeRTOS

Embedded Linux

Yocto

Messaging

MQTT

Data processing

Python / C++

AI models

Hugging Face / Ollama / API models

Agent framework

smolagents / LangGraph-style orchestration

Embeddings

Sentence Transformers / other embedding APIs

Graph

Neo4j

GraphRAG

Neo4j GraphRAG / custom

Vector DB

Neo4j / Qdrant / Weaviate / other

Relational data

PostgreSQL

Workflow

n8n

APIs

FastAPI

Containers

Docker Compose

Simulation

SystemC/TLM

Knowledge management

Git + document repository

Observability

OpenTelemetry / logging / metrics

Neo4j's current GraphRAG package supports external vector databases including Qdrant, Pinecone and Weaviate, as well as sentence-transformer embeddings and multiple LLM providers.

27. Proposed OBD-AI Microservices

obd-service can-service vehicle-service diagnostic-service knowledge-service graph-service embedding-service retrieval-service agent-service evaluation-service report-service authentication-service

Each service should have a clear responsibility.

This reduces coupling and enables components to evolve independently.

28. Agent Tools

The diagnostic agent can be given a controlled toolset.

Vehicle tools

get_vehicle() get_engine() get_ecu() get_configuration()

Diagnostic tools

read_dtcs() read_pid() read_freeze_frame() clear_dtc()

Knowledge tools

search_manual() search_tsb() search_graph() query_component() query_dtc()

Engineering tools

lookup_signal() decode_can() simulate_ecu() compare_measurement()

Safety tools

validate_action() require_human_confirmation() log_action()

29. Human-in-the-Loop Architecture

For automotive applications, the agent should not automatically convert uncertainty into physical action.

The recommended model is:

AI Observation ↓ AI Hypothesis ↓ Recommended Diagnostic Test ↓ Technician Confirmation ↓ Test ↓ Measured Result ↓ AI Reassessment

For operations capable of changing vehicle state, stronger authorization should be required.

30. Safety Architecture

The system should distinguish:

Informational operations

Examples:

  • read DTC;
  • read PID;
  • search manual;
  • retrieve specifications.

Diagnostic operations

Examples:

  • run supported test;
  • activate a diagnostic procedure.

State-changing operations

Examples:

  • clear DTC;
  • command actuator;
  • write ECU configuration.

The architecture should implement increasing authorization requirements:

Read ↓ Analyze ↓ Recommend ↓ Confirm ↓ Execute

This is particularly important when an AI agent has access to vehicle interfaces.

31. Cybersecurity

An OBD-AI system creates a new attack surface.

Threats include:

  • malicious diagnostic data;
  • prompt injection through documents;
  • malicious service-manual content;
  • compromised APIs;
  • unauthorized CAN access;
  • malicious MCP tools;
  • poisoned knowledge graphs;
  • compromised model artifacts;
  • credential leakage;
  • unauthorized vehicle commands.

The GraphRAG reference itself identifies prompt injection as a limitation of LLM applications.

Therefore:

Untrusted Data ↓ Sanitization ↓ Trust Classification ↓ Retrieval ↓ Agent Policy ↓ Tool Authorization ↓ Execution

32. Knowledge Provenance

Every diagnostic conclusion should ideally maintain provenance.

For example:

Hypothesis H1 | +-- Evidence E1 | └── OBD measurement | +-- Evidence E2 | └── Service manual | +-- Evidence E3 | └── Technical bulletin | +-- Evidence E4 └── Knowledge graph relationship

This creates an explainable diagnostic chain.

The supplied GraphRAG book specifically emphasizes accurate, reliable and explainable RAG systems and the value of structured knowledge for connecting information.

33. Diagnostic Knowledge Graph Ontology

A more mature OBD-AI ontology could contain:

Vehicle

VIN Make Model Year Engine Transmission Market Trim

ECU

ECU ID Software Version Hardware Version Network Address

Sensor

Sensor Type Range Unit Sampling Rate ECU

DTC

Code Description Severity System Conditions

Diagnostic Test

Test ID Input Conditions Procedure Expected Result Failure Interpretation

Repair

Repair ID Component Procedure Tools Parts Time

34. Multi-Agent OBD-AI

A future architecture can use several specialized agents.

Supervisor Agent | +-----------------+------------------+ | | | Diagnostic Agent Knowledge Agent Vehicle Agent | | | | | | Test Planning GraphRAG Live OBD/CAN | +-----------------+ | Verification Agent | Human Technician

Potential agents:

Vehicle Agent

Understands vehicle configuration.

Diagnostic Agent

Builds diagnostic hypotheses.

Knowledge Agent

Searches manuals and technical documents.

Graph Agent

Traverses the knowledge graph.

CAN Agent

Decodes and interprets CAN signals.

Simulation Agent

Interacts with SystemC/TLM or virtual vehicle models.

Verification Agent

Checks whether conclusions are supported.

Report Agent

Produces technician-readable documentation.

35. Strategic Research Framework

The OBD-AI project can be organized into five research layers.

Layer 1 — Data

OBD CAN DTC PID Manuals TSBs Repair Data

Layer 2 — Knowledge

Ontology Knowledge Graph Vector Index Metadata Provenance

Layer 3 — Intelligence

LLM Embeddings Agent Reasoning Retrieval

Layer 4 — Engineering

SystemC TLM ARM RTOS Embedded Linux Simulation

Layer 5 — Application

Technician App Mobile App Web Dashboard Diagnostic Reports Fleet Analytics

36. Development Framework

A practical development roadmap is:

Phase 1 — Digital Knowledge Base

Build:

PDF ingestion Chunking Embedding Vector search Basic RAG

Goal:

Answer service-manual questions with citations.

Phase 2 — Knowledge Graph

Build:

Vehicle ECU DTC Sensor Component Procedure Manual

Goal:

Connect automotive entities.

Phase 3 — Hybrid GraphRAG

Combine:

Vector retrieval + Graph retrieval

Goal:

Answer multi-hop diagnostic questions.

Phase 4 — Agentic RAG

Introduce:

Agent Tools Query planning Iterative retrieval Evidence evaluation

Goal:

Allow the system to determine what information is missing.

Phase 5 — Live OBD Integration

Connect:

OBD adapter CAN MQTT Diagnostic agent

Goal:

Combine static engineering knowledge with live vehicle observations.

Phase 6 — Simulation

Introduce:

SystemC/TLM Virtual ECU CAN simulation Synthetic diagnostic events

Goal:

Test diagnostic agents before deployment.

Phase 7 — Technician Platform

Create:

Mobile application Web dashboard Diagnostic reports Repair workflow

37. Evaluation Framework

An OBD-AI system should not be evaluated solely by asking:

"Does the answer sound good?"

Evaluation should include:

Retrieval accuracy

Did the system retrieve the relevant documentation?

Graph accuracy

Did it traverse the correct relationships?

Diagnostic accuracy

Did it identify plausible diagnostic paths?

Evidence grounding

Can every important claim be traced to evidence?

Tool accuracy

Did the agent use the appropriate diagnostic tool?

Safety

Did it avoid unauthorized actions?

Repeatability

Does the system behave consistently for the same evidence?

Human usefulness

Can a technician understand and act on the output?

38. Proposed OBD-AI Evaluation Metrics

A research benchmark could measure:

R@K Retrieval Recall P@K Retrieval Precision Graph-Hit Relevant Graph Path Citation Evidence Coverage Tool-Acc Correct Tool Selection Diag-Acc Diagnostic Accuracy False-Pos Incorrect Diagnosis Rate False-Neg Missed Diagnosis Rate Latency Diagnostic Response Time Cost Inference/Retrieval Cost Safety Unauthorized Action Rate

A particularly important metric should be:

Evidence-Supported Diagnostic Accuracy

because a technically correct answer without traceable evidence is insufficient for a professional diagnostic platform.

39. Synthetic Diagnostic Dataset

The OBD-AI research program can create a synthetic dataset containing:

Vehicle DTC Symptoms PID Data CAN Data Fault Expected Test Test Result Diagnosis Repair

Example:

{ "vehicle": "Vehicle-A", "dtc": ["P0171"], "rpm": 750, "coolant_temp": 91, "stft": 12.4, "ltft": 18.1, "hypothesis": [ "intake_leak", "fuel_delivery", "air_measurement" ], "test": "intake_leak_test", "result": "negative" }

Such data can be used for:

  • evaluation;
  • agent training;
  • simulation;
  • regression testing;
  • tool-selection evaluation.

40. Hugging Face Dataset Strategy

The Hugging Face ecosystem can support dataset development.

Possible datasets:

obd-ai-dtc obd-ai-pid obd-ai-can obd-ai-diagnostic-cases obd-ai-service-manual obd-ai-agent-traces

The dataset can include:

input context retrieved_evidence tool_calls diagnostic_reasoning expected_action expected_output

This enables systematic evaluation of the agent.

41. Fine-Tuning Strategy

Fine-tuning should be incremental.

Stage 1

No fine-tuning.

Use:

RAG + GraphRAG + prompting

Stage 2

Fine-tune structured automotive terminology.

Stage 3

Fine-tune tool selection.

Stage 4

Fine-tune diagnostic report generation.

Stage 5

Evaluate whether specialized models improve measurable performance.

This avoids unnecessarily embedding rapidly changing service information into model weights.

42. Strategic Role of IAS-Research.com

IAS-Research.com can function as the research and architecture organization.

Its potential responsibilities include:

AI research

  • Agentic RAG;
  • GraphRAG;
  • knowledge graphs;
  • LLM evaluation;
  • model experimentation.

Embedded AI research

  • ARM;
  • TinyML;
  • RTOS;
  • embedded Linux;
  • edge inference.

System engineering

  • SystemC/TLM;
  • architecture modeling;
  • simulation;
  • hardware/software co-design.

Research publications

  • white papers;
  • technical reports;
  • benchmark datasets;
  • reference architectures;
  • research prototypes.

Technology evaluation

IAS-Research can compare:

Neo4j Qdrant Weaviate Hugging Face Ollama LangGraph-style orchestration smolagents n8n MCP SystemC/TLM

The role is therefore fundamentally research, architecture, experimentation and intellectual-property development.

43. Strategic Role of KeenComputer.com

KeenComputer.com can serve as the engineering, integration and commercialization partner.

Its role can include:

Software engineering

  • Python;
  • C++;
  • APIs;
  • Docker;
  • databases;
  • web applications.

AI infrastructure

  • RAG;
  • GraphRAG;
  • LLM deployment;
  • model serving;
  • vector databases.

DevOps

  • Docker Compose;
  • Linux;
  • VPS/cloud;
  • CI/CD;
  • monitoring;
  • backups;
  • security.

Application development

  • mobile application;
  • web dashboard;
  • technician portal;
  • fleet management interface.

Integration

Vehicle ↓ OBD/CAN ↓ Edge Gateway ↓ MQTT ↓ AI Platform ↓ GraphRAG ↓ Technician Application

KeenComputer can therefore turn IAS research prototypes into deployable engineering systems.

44. Strategic Role of KeenDirect.com

KeenDirect.com can provide the hardware and technology supply layer.

Potential products include:

  • OBD-II adapters;
  • CAN interfaces;
  • STM32 development boards;
  • ARM boards;
  • embedded computers;
  • diagnostic cables;
  • sensors;
  • test equipment;
  • networking equipment;
  • edge-AI hardware.

The strategic model becomes:

IAS-Research Research + Architecture | v KeenComputer Engineering + Software + Deployment | v KeenDirect Hardware + Components + Equipment

This creates a complete research-to-product pathway.

45. Three-Company Strategic Model

IAS-Research.com | Research / IP / Architecture | v KeenComputer.com | Engineering / AI / Software / DevOps | v KeenDirect.com | Hardware / Components | v OBD-AI | +---------------+----------------+ | | | Technician Fleet/Service Research Application Platform Platform

The three organizations therefore represent complementary stages:

Discover → Design → Build → Deploy → Supply → Improve

46. Commercialization Framework

A possible OBD-AI commercial model is:

Product 1 — OBD-AI Diagnostic Assistant

For independent technicians.

Product 2 — Professional Diagnostic Platform

For repair shops.

Product 3 — Fleet Diagnostic Platform

For fleet operators.

Product 4 — Engineering Knowledge Platform

For automotive engineering teams.

Product 5 — Embedded AI Development Platform

For OEM suppliers and embedded developers.

Product 6 — Research Platform

For universities and AI/automotive research laboratories.

47. Strategic Value Proposition

The combined platform can be positioned around:

Evidence-grounded automotive intelligence connecting vehicle data, engineering knowledge, knowledge graphs and AI agents.

The key differentiator is not simply:

"An AI chatbot for cars."

Instead:

An engineering knowledge system that connects live vehicle observations with structured automotive knowledge and documented diagnostic procedures.

48. OBD-AI Reference Architecture

USER / TECHNICIAN | Mobile / Web Interface | Diagnostic Agent | +-----------------+-----------------+ | | | OBD Tools Knowledge Tools Engineering Tools | | | OBD/CAN GraphRAG/RAG Simulation | | | +-----------------+-----------------+ | Evidence Orchestrator | +---------------+---------------+ | | Vector Layer Graph Layer | | Service Manuals Neo4j Knowledge Graph TSBs Vehicle Ontology Repair Documents DTC Relationships | | +---------------+---------------+ | LLM / AI Models | +-----------------+-----------------+ | | | Hugging Face Ollama/API Specialized Models | Evaluation Layer | Human Verification

49. Research Contribution

The proposed research program can contribute in several areas.

Contribution 1

A vehicle-specific knowledge graph ontology for diagnostic reasoning.

Contribution 2

A hybrid Vector + Graph retrieval architecture for automotive troubleshooting.

Contribution 3

An Agentic RAG architecture capable of iterative diagnostic investigation.

Contribution 4

Integration of live OBD/CAN observations into GraphRAG.

Contribution 5

SystemC/TLM-based virtual diagnostic environments.

Contribution 6

A benchmark dataset for automotive diagnostic agents.

Contribution 7

Evidence-based diagnostic evaluation metrics.

Contribution 8

Human-in-the-loop safety architecture for AI-assisted vehicle diagnostics.

50. Open Research Questions

Several research questions should remain open rather than being assumed to have predetermined answers.

RQ1

Does GraphRAG improve automotive diagnostic accuracy over vector-only RAG?

RQ2

How much does iterative Agentic RAG improve diagnostic-test selection?

RQ3

Can graph traversal reduce irrelevant service-manual retrieval?

RQ4

What ontology provides the best balance between engineering accuracy and maintenance cost?

RQ5

Can SystemC/TLM provide useful synthetic training environments for diagnostic agents?

RQ6

How should live CAN observations be represented in a persistent knowledge graph?

RQ7

What evidence threshold should be required before an AI system recommends a physical diagnostic action?

RQ8

How can model, graph and retrieval updates be validated without retraining the entire system?

51. Recommended Technology Development Stack

A practical research stack is:

Ubuntu / Kubuntu Docker Python C++ FastAPI PostgreSQL Neo4j Qdrant or Neo4j Vector Hugging Face Sentence Transformers smolagents Ollama MQTT n8n SystemC TLM STM32 ARM Git GitHub Jupyter

Neo4j's current GraphRAG implementation supports local models through Ollama as well as several hosted model providers, making it suitable for experiments ranging from local/private deployments to cloud-backed research.

52. Recommended Development Principle

The architecture should follow:

Open Standards + Open Source + Modular Architecture + Evidence Grounding + Human Verification + Hardware/Software Co-Design

This is consistent with the engineering philosophy of the supplied ESL reference, which emphasizes reusable components, automation, exploration, open-source tooling and unified hardware/software modeling.

53. From RAG to Engineering Intelligence

The evolution can be viewed as:

LLM | v RAG | v GraphRAG | v Agentic RAG | v Agentic GraphRAG | v Live Vehicle Agent | v Engineering Intelligence Platform

The final stage is not simply a more sophisticated chatbot.

It is an AI-assisted engineering system.

54. Strategic Partnership Framework

The three-company model can therefore be expressed as:

IAS-Research.com

Research the problem.

Research Architecture Algorithms Models Knowledge Graph Simulation Evaluation IP

KeenComputer.com

Engineer the solution.

Software AI Cloud DevOps Integration Cybersecurity Applications Deployment

KeenDirect.com

Supply the physical technology.

OBD Hardware CAN Hardware ARM STM32 Sensors Edge Computers Test Equipment Components

Together:

RESEARCH ↓ ARCHITECTURE ↓ PROTOTYPE ↓ ENGINEERING ↓ HARDWARE ↓ DEPLOYMENT ↓ COMMERCIALIZATION ↓ FIELD DATA ↓ RESEARCH

This creates a feedback loop rather than a one-time product-development process.

55. Conclusion

Agentic GraphRAG provides a promising architectural direction for OBD-AI because automotive diagnosis is inherently relational, evidence-dependent and context-sensitive.

Traditional LLMs provide language and reasoning capabilities but do not inherently contain current vehicle-specific knowledge. RAG provides external evidence. Knowledge graphs provide relationships. GraphRAG combines these capabilities. Agentic RAG adds iterative planning, tool use, retrieval refinement and self-correction.

The supplied Essential GraphRAG reference provides the conceptual foundation for this transition from conventional RAG to graph-based and agentic retrieval.

The supplied Electronic System Level Design reference provides the complementary engineering foundation: abstraction, reuse, automation, exploration, hardware/software co-design, TLM, simulation, debugging and virtual prototyping.

Combining these ideas creates a broader research proposition:

OBD-AI should be designed as an evidence-grounded, agentic engineering intelligence platform rather than as a conversational automotive chatbot.

In this architecture:

IAS-Research.com provides research, architecture, AI/embedded-system experimentation and intellectual-property development.

KeenComputer.com provides software engineering, AI integration, infrastructure, cybersecurity, DevOps and commercialization.

KeenDirect.com provides the hardware and component supply chain required to connect AI research to physical automotive systems.

The resulting platform can evolve from a diagnostic assistant into a broader ecosystem connecting:

OBD-II CAN ARM STM32 RTOS Embedded Linux SystemC/TLM Knowledge Graphs GraphRAG Hugging Face LLMs Agentic AI Mobile Applications Cloud/Edge Computing

The long-term research opportunity is therefore not merely to answer:

"What does this diagnostic code mean?"

but to develop a system capable of asking:

What do we know, what evidence supports it, what information is missing, what test should be performed next, and how can the result be verified?

That distinction is central to building trustworthy AI-assisted automotive engineering.

References and Technology Resources

Supplied Research References

  1. Bratanič, Tomaž; Hane, Oskar. Essential GraphRAG. Manning MEAP.
    Topics represented in the supplied material include LLM limitations, RAG, vector and hybrid retrieval, Text2Cypher, Agentic RAG, knowledge-graph construction, Microsoft GraphRAG and RAG evaluation.
  2. Rigo, Sandro; Azevedo, Rodolfo; Santos, Luiz (eds.). Electronic System Level Design: An Open-Source Approach. Springer, 2011. DOI: 10.1007/978-1-4020-9940-3.
  3. The ESL reference emphasizes early design analysis, high-level modeling, simulation, performance and power analysis, functional verification, SystemC, TLM and open-source design infrastructure.

Current GraphRAG / AI Frameworks

  1. Neo4j GraphRAG for Python — official GraphRAG package for Python, including vector retrieval, graph retrieval, knowledge-graph construction and multiple LLM/embedding integrations.
  2. Neo4j GraphRAG User Guide — RAG pipelines, VectorRetriever, GraphRAG, Text2Cypher and custom model integration.
  3. Microsoft GraphRAG — structured/hierarchical GraphRAG methodology based on extracting knowledge graphs and community structures from source material.
  4. Hugging Face smolagents — open-source agent framework supporting CodeAgent, ToolCallingAgent, tools, MCP, Hub integration, local models and external model providers.
  5. Hugging Face Agentic RAG — demonstrates iterative retrieval, query reformulation, reasoning over retrieved material and self-correction.
  6. Hugging Face TRL — post-training framework supporting techniques including supervised fine-tuning, DPO and GRPO.
  7. Vaswani et al., "Attention Is All You Need." Transformer architecture underlying modern LLMs; also discussed in the supplied GraphRAG reference.

Recommended Research Areas

  1. Knowledge Graphs and graph databases — Neo4j
  2. Vector databases — Qdrant, Weaviate and related systems
  3. Hugging Face Transformers and Sentence Transformers
  4. Agentic RAG and tool-using AI
  5. Model Context Protocol (MCP)
  6. SystemC and Transaction-Level Modeling
  7. ARM embedded systems
  8. STM32 microcontrollers
  9. FreeRTOS and embedded Linux/Yocto
  10. MQTT and edge telemetry
  11. OBD-II and CAN diagnostic systems
  12. Automotive diagnostic standards and OEM service information
  13. AI evaluation, safety and human-in-the-loop engineering

Proposed OBD-AI Research Roadmap

Stage

Research Output

IAS-Research

KeenComputer

KeenDirect

1

OBD knowledge model

Ontology

Data pipeline

Hardware research

2

Vector RAG

AI research

RAG implementation

Edge hardware

3

Knowledge Graph

Graph ontology

Neo4j integration

Infrastructure

4

GraphRAG

Retrieval research

Platform engineering

Compute

5

Agentic RAG

Agent architecture

Agent implementation

Edge devices

6

OBD/CAN integration

Embedded research

MQTT/API integration

OBD/CAN products

7

SystemC/TLM

Simulation research

Tool integration

Development boards

8

Technician application

AI evaluation

Mobile/web application

Diagnostic hardware

9

Pilot deployment

Research analysis

Deployment/DevOps

Hardware supply

10

Commercial platform

IP/research

Productization

Product ecosystem

Core strategic proposition

IAS-Research.com → Research & Intellectual Property

KeenComputer.com → Engineering & Digital Implementation

KeenDirect.com → Hardware & Technology Supply

OBD-AI → Integrated Product and Research Platform

This creates a complete Research → Engineering → Hardware → Deployment → Data → Research ecosystem for intelligent automotive diagnostics.