The Java OBDII Scan Tool Project

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.

History

• 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 with UML...
• 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

Last modified: Sept. 22, 2001