The Java OBDII Scan Tool Project
See the history below for updated info
Welcome to the Java OBDII Scan Tool Project. As you probably have figured
out, this project is about designing a software tool capable of talking
to your car's engine control unit and getting all sorts of data from it,
in particular trouble codes. Since the mid '90, virtually all manufacturers
conform to the On-Board Diagnostic (OBD) regulations enforced by the U.S.
government and thus make it easier for technicians to assess the state
of the engine control system. The fun part is that dull mortals can also
have access to the same information, provided they get their hands on a
scan tool. But why pay for it (> $250 US) when you can build one ? The
catch is that the scan tool needs a hardware module to talk to the car.
Cars now have all their electronic sensors and actuators linked together
as a local area network (LAN), so the scan tool should also get onto the
network using the same network protocol from the electronics as well as
software point of view (just like a PC that needs an ethernet card - the
electronics - and software - e.g. TCP/IP protocol - for network communication).
The primary goal of the project is not to focus on the electronics but
to take care of the software side in such a manner that users with their
own electronic interface would easily modify the code to make it work with
their device. So the keyword here is portability, in order to reach as
many users as possible (be they using a desktop PC, a laptop or even a
PalmPilot), and that explains the choice of Java as programming language.
On top of that, the object-oriented nature of Java facilitates modifications
by the users.
Here are the ideas I toying with to get the project on track. If developers
are interested to give their input, they can post their comments / suggestions
to the project's forum.
There is an SAE specification aimed at standardizing the way scan tools
should communicate with the user, and in the long run the Java tool should
also be compliant.
However, the first version should at least provide the first three "diagnostic
modes" (including basic powertrain data such as engine RPM, vehicle speed,
air temp., etc., as well as diagnostic trouble code reading). These are
probably the top useful feature for most people.
For the physical interface, I bought myself a device from Multiplex Engineering
that can translate requests / responses between a PC and the engine control
unit. The PC talks to the device through an RS-232 port. That's convenient.
Note however that the whole design does not revolve around this particular
device: it is made generic enough so that the tool could talk to other
types of devices (even home-made devices as a result of some projects under
way somewhere on the Web).
Communication with the device would be made possible by using the Java
communications API that provides the appropriate classes and services.
Small problem: the API is available for the Windows and Solaris/x86 platforms,
so by the time Sun releases the API for other platforms, native code would
probably have to be written. Update: The Solaris version runs under linux
provided you install some package named rxtx. I'll eventually post some
information about this.
Sept. 04, 2002 -- It's been a while, eh? Spring and summer have been slow
(lots of thing to do at work and around the house :-), but I'm back to
work now! The prototype can now read Trouble codes (from P0100 to P0700),
fuel system status + oxygen sensor(s) data are displayed, the last remaining
major functionality to add is the freeze frame data pane. Stay tuned...
Feb. 28, 2002 -- Roughly 3000 lines of code later (~6000 lines total),
the prototype looks great. Another developer (bubbler) put in a lot of
UI code and built a simulator for testing. I expect a release some time
in April or May, once the 'Trouble Codes' functionality is ready...
Nov. 13, 2001 -- Been a bit behind schedule as far as progress report is
concerned, but the reason is simple: the prototype is progressing really
well. All basic classes that take care of communication and message management
are implemented as well as the basic user interface (close to 3000 lines
of Java code so far). In fact, before the end of next week, I should be
able to talk to a car and ask some data in real time such as RPM, vehicle
speed, etc. (see screenshot below). Check back soon...
Sept. 22, 2001 -- First 'milestone' reached: I implemented the basic classes
that take care of the communication aspect between the application and
some device (simulated by another PC with a NULL modem cable). In this
iteration, the implemented classes are drawn yellow in the class diagram
(Note: the documentation section hasn't been updated; this should be fixed
soon). Next iteration: designing and implementing msg management classes.
For those who care, the design tool I'm using is Poseidon.
August 12, 2001 -- Back to work (July was vacation time). The forum is
quiet but I'm busy doing the OOA based on part of the proposed UI. I'm
working toward a very preliminary version of the system with a rather complete
communication module and a message panel showing the msgs being sent and
received. Progress isn't as fast as expected due to my very limited experience
June 7, 2001 -- Things are starting to move! There has been activity in
the project's forum and two participants have expressed interest in contributing
to the project. And last week, I posted the documentation for the requirements
specifications, which includes the class diagram of the domain, the user
interface snapshots and scenarios for using the tool. The next big step
is the object-oriented analysis, which requires a fairly stable user interface,
so I'll let people take a look at it and comment on it.
May 7, 2001 -- I've almost completed the user interface (I'm using JBuilder
to do it). If everything goes well, snapshots should be available before
the end of next week. I've also started doing the analysis but I expect
to spend at least a month on it...
April 18, 2001 -- I had a course about the UML and the Rational Unified
Process last month and I'm trying to make use of my 'acquired knowledge'.
As of now, I'm at the requirements specification level; class diagram (domain)
is done as well as the use cases and I'm writing the scenario of each use
case. In addition, the layout of the interface is progressing well, so
I should be moving to the analysis stage soon (my biggest problem is finding
a decent *and* free UML diagramming tool :-)
Resources - links
The OBD-II Home Page
(provides native I/O libraries [Linux, Mac...] for the Java Comm API)
Poseidon, from Gentleware
(free UML tool)
Last modified: Sept. 22, 2001