Heads up: Our Ideas Factory has been refreshed, levelled up, and grown-up into Alphero Intelligence. Some of our old posts are pretty cool tho'. Check this one out.
- Modern cars have a way of accessing the data of their internal computers.
- We investigated ways we could use that and created a prototype for mileage logging.
- Reliability and testing are the main challenges given the slight differences between manufacturers.
If your car is less than 20 years old it’s likely it is peppered with little computers inside it. Thanks to California and its hippy attitude to life, since 1994 cars sold in the states have been mandated to expose the information from its computers for emission testing - the mandate was expanded to the whole of United States in 1996 and followed by many countries around the world, including Australia and New Zealand which promptly caught on the requirement 10 years later.
Called “On-Board Diagnostics” (OBD for short), the standard evolved through time as new capabilities were introduced to on-board computers. Today the protocol is on its second version called OBD2 and exposes around 300 codes, from speed and battery levels to the ever so important “commanded evaporative purge”.
The OBD2 port is usually hidden under the wheel or panel somewhere and vary from car to car. Mechanics are well acquainted with it as they usually connect specialised equipment during a WOF (Warrant of Fitness) to check if there are any error codes stored up in your car.
We heard about a company that taps into the OBD2 technology and decided to see for ourselves what we could do with it.
What can we do with it?
After clarifying to our accounting team why we needed to spend an exorbitant amount of money ($10) for “a thing”, we got to work.
To start with, we wanted to understand a few basic concepts around Bluetooth connectivity and reliability of data, and a simple app with a handful of readings got us going.
Given we didn’t have a car available inside the office (accounting considerations but also health and safety), we went full immersion and our lovely developer Tom spent some quality time working while sitting in his car — debugging in the production environment sometimes has its place.
In the end, we built a prototype that keeps track of the odometer information and prompts users to enter details about the trip so we can create a log.
The prototype worked well and, after reviewing it, we also considered using other information such as the mobile phone’s GPS data and camera to complement some of the data collected from the car’s systems.
The main challenge with OBD2 devices would be testing and hardening. Different cars use slightly different codes and differ on how they report information, which means having to build handling for all different scenarios. Bluetooth can also be a bit iffy at times, and we wouldn’t want something that requires attention from the user while they are driving. Most of all, depending on the manufacturer, reading information from the OBD2 port puts the car in “diagnostic mode”, which means some operations can be affected bringing several considerations of use into play.
The next step for us is using different OBD2 connectors to see how that plays in reliability and new uses and explore the applicability of this in other fields such as insurance and driver education.