Automatic is a great product passes data from your cars computer to your phone, and onto the servers for analysis. Insurance companies like Progressive and eSurance have also picked up on this to offer their customers discounts for responsible driving. The same technology has been used extensively in transportation and logistics by companies such as FedEx.
This is reposted on the Kaazing Open Source Blog.
On the insurance and smart driving fronts, these products tend to operate in a batch mode. They give helpful analytics over the long-term, but are not particularly designed for real-time. Real-time offerings exist for transportation and logistics, but these systems can be very costly. With the advances in microcomputing, IoT (Internet of Things), and real-time connectivity, you can now deliver the same experiences on the cheap using off the shelf hardware.
On-Board Diagnostics System
Pretty much every vehicle manufactured since 1995 has an on-board computer. These computers offer a number of services to the vehicle itself, but can also be tapped into by third parties through a protocol referred to as OBD (on-board diagnostics). If you take your car into the shop, they will likely use this interface to take a peek under the hood, without having to manually check every system.
The OBD port is generally located under the driver-side dashboard. It is a fairly blocky looking thing, that is more narrow on one side than the other. As it turns out, there are a variety of adapters made to plug into these ports. The one we chose to use was an ELM-327 unit that communicated via Bluetooth. These units also come in wi-fi and USB flavors.
Technically the OBD protocol is an ISO standard but there are many other variations. You effectively open the serial port to your OBD connector, and then issue a series of commands. Many of these commands have been well documented by the community, and you can find libraries for languages such as Java and Node.js. A typical exchange looks something like the following snippet.
atz // OBD protocol > ELM327 v1.3a atrv // Vehicle voltage > 12.5V atsp0 // Protocol level > OK 0100 // Current data > 41 00 BF 9F A8 93 010c // Engine RPM > 41 0C 0E 96
As Kaazing Gateway provides a Java client, this was our stack for this project. The Java OBD library expects an InputStream and OutputStream to work. Serial Java communications is not yet standardized, but we like the jSSC (Java Simple Serial Connector) project. The problem with jSSC is that it does not expose InputStream or OutputStream projects, but rather works off an event-based approach. In the end, we rolled our own lightweight, hardly complete, OBD protocol implementation on top of jSSC.
You can find all the code for this project, including our jSSC-based implementation of OBD in my Kaazing GitHub repository under "iot/cars/java".
Most ECUs (engine control units) have access to on-board GPS systems, but these are generally exposed under vendor-specific OBD commands that are not well documented (if at all). To address this, we used a third-party USB GPS module. GPS units talk using NMEA (National Marine Electronics Association) data, which is also well documented. It is effectively a string of comma-separated values.
$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47 Which means: - Fix taken at 12:35:19 UTC - Latitude 48 deg 07.038' N - Longitude 11 deg 31.000' E - Fix quality: 1 = GPS fix - 8 satellites being tracked - 0.9 horizontal dilution of position - 545.4,M altitude in meters above mean sea level - 46.9,M height of mean sea level - (empty field) time in seconds since last update - (empty field) station ID number - *47 checksum data
I was initially worried that jSSC would only allow access to a single USB port at a time, but it turns out that it can support multiple ports at once. Our Java program then pulls OBD data and GPS data, and merges the information. The merged information is stored locally for playback or batch processing, but also published through Kaazing Gateway using AMQP (Advanced Message Queing Protocol).
Because we are using a publish-subscribe architecture, any number of systems could be listening for this telemetry data. This might be an insurance company, the vehicle manufacturer, government highway safety, etc. This decoupling of data from client is a big step forward over traditional request-response approaches. For our project, we simply received the information in a web browser.
The result is real-time vehicle telemetry across devices and clients - and at a total cost of about $100 USD. In this case we used a MacBook Pro as our computer, which was then in turn wirelessly connected to a mobile hotspot from a smartphone. A Raspberry Pi would be equally effective for this purpose, and provide a much small footprint. If you are looking for something more industrial in nature, Intel makes an IoT Gateway product, which includes a GSM radio.
With modern web standards, there is no reason that your IoT data should be delivered in a batch approach. Most developers look to batch processing with request-response because that is what is most comfortable to them. The information loss however, especially in industrial applications, can be significant. Finding out that a refrigerated freight vehicle has blown it's compressor could mean valuable loss of cargo at an extreme cost to the vendor, customer, and freight companies.
If real-time seems intimidating, I would encourage you to take a look at my Kaazing chat tutorial.