Member Avatar for Superstar288

Hi every thanks for taking the time to read my thread. anyway i had an idea of doing a car diagnostic program which would then store results and act as a car library for my final year project but im not sure if this is possible and if it is where to start. i was just wondering if anyone had done this before or if you have any documents that i could read. i would like to do this in java. also do you think this would keep me going for the year?

im seriously struggling to find a project lol

Edited by Superstar288 because: n/a
  • 2 Contributors
  • 2 Replies
  • 327 Views
  • 9 Hours Discussion Span
  • Latest Post Latest Post by Superstar288

Dani AI

Generated

Good call on exploring hardware, , and fair point from about scope — full commercial diagnostic suites are large. Treat this as three manageable layers: the vehicle interface (adapter + protocol), the parser/logic that decodes responses and DTCs, and the persistence/UI that stores and presents results. Start with a tight, demonstrable workflow before widening scope.

Make a minimal viable product first: support one vehicle (or family), read a handful of live parameters, capture timestamped snapshots, decode and store trouble codes, and build a searchable “car library” of sessions. Add export (CSV) and a simple trend chart for one sensor. That gives a complete pipeline to demonstrate without trying to match dealer software.

Database-design notes to make development easier: separate metadata from time-series data. Core tables could be Vehicles, Sessions, Readings, DTC_Codes and Repairs/Notes. Store raw device responses alongside parsed values so parsing bugs can be diagnosed later. Index by (vehicle_id, timestamp) and by session_id. If readings are high-frequency, keep high-rate samples in a time-series store or compressed table and use the relational DB for metadata and summaries. Define sensor/PID as data-driven rows so new items can be added without code changes.

Implementation and troubleshooting tips: implement the adapter reader as a background thread that appends raw frames to a queue; parse in worker threads and write asynchronously to the DB to avoid dropped frames. Log raw frames, timestamps and parser errors. Develop against an emulator or a known-good vehicle first. Keep a short milestone plan (MVP + two feature sprints) and include protocol handling, test logs and demo scenarios in the final deliverables — that structure will make a solid final-year project.

Recommended Answers

All 2 Replies

Member Avatar for jwenting

Oh, just about every car manufacturer and no doubt the larger groups of maintenance shops have created such software (as well as the associated hardware to plug it into the cars' electronics).

Given that those are professional organisations with large teams of developers, it's probably a good guess that anyone writing it alone would have quite the job of it.

Member Avatar for Superstar288

hey jwenting ive looked into the obd2 cable i think i will buy it and see how it works first. just found some more information on it aswell it could be a nice project to do.

if anyone else has done something similar to this please let me know what it was like

thanks

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.