OBD-II / CAN Asset Tracker
Overview
Analysis of the data provided by IoT telematics can provide valuable insights that can be used to improve operations efficiency, increase safety, and assist in maintaining regulatory compliance.
This OBD-II / CAN Asset Tracker Reference Design demonstrates how to read standardized vehicle sensor values and track vehicle location using the Golioth IoT platform. It connects to the on-board diagnostic (OBD-II) port in a vehicle and continuously records vehicle sensor values via the ISO 15765 (CAN bus) protocol.
Specifically, the following legislated OBD-II vehicle sensor "PIDs" are continuously monitored:
0x0D: Vehicle Speed Sensor (VSS)
The vehicle sensor values are combined with GPS location/time data and streamed back to the Golioth Cloud where the data is stored and can be made available to external services for visualization and analysis.
Although the firmware in this reference design has been tailored specifically for use with the OBD-II protocol in a vehicle, the same underlying hardware, Zephyr RTOS, and Golioth SDK can be used to build connected devices that support any CAN-based protocol. This includes J1939 for heavy-duty vehicles, CANopen for industrial machinery, and NMEA 2000 for maritime vessels.
Business Use Case
Organizations that manage fleets of vehicles are increasingly turning to IoT solutions to enable real-time management and monitoring across their entire fleet. For example, vehicle fleet managers can remotely monitor vehicle location and track routes, allowing them to optimize logistics in real-time. They can receive instant notifications if a vehicle is moved or stolen, enabling swift response and recovery. Real-time measurement of vehicle performance data and diagnostic trouble codes (DTCs) can enable proactive fleet maintenance and reduce downtime. For shared vehicles or rental fleets, data on mileage, fuel consumption, time of use, and location, can enable more efficient scheduling and billing. By analyzing usage data, businesses can understand which vehicles are underutilized so that they can be reallocated before buying additional assets.
Additionally, telematics data on driver behavior can be analyzed and used to coach drivers on safe driving practices. A 2014 study by the U.S. Department of Transportation demonstrated that telematics can be used to effectively monitor and improve safe driving behavior, leading to improved fuel economy in trucks. As unsafe driving behavior decreased, fuel economy improved by 5.4 percent for drivers of sleeper cabs and by 9.3 percent for drivers of day cabs.
Insurance companies can also utilize telematics data to offer personalized usage-based insurance policies. By analyzing driving behavior, including speed, acceleration, braking patterns, and location, insurance companies can assess risk more accurately and tailor insurance premiums to each driver. Safe drivers can be rewarded with lower rates, promoting responsible driving habits.
Golioth makes it easy to prototype, deploy, and manage CAN-based vehicle telematics: connect and secure devices, send vehicle data to the web, update firmware Over-the-Air, and scale your fleet with our instant IoT cloud.
Blog post
Read about the release of this reference design in the OBD-II / CAN Asset Tracker blog post.
How we built it
Modular Hardware
The reference design hardware is built using the Golioth Aludel Mini prototyping platform, which integrates an Adafruit Feather-compatible processor module and two MikroE Click sensor boards into a compact enclosure. It also includes the Ostentus front panel that features an ePaper display for sensor readings, back-lit LED indicators, and capacitive touch buttons. We designed this platform to demonstrate how it’s possible to quickly develop a proof-of-concept using widely available off-the-shelf modules. You'll find step-by-step instructions below showing how you can build a similar prototype yourself using widely-available development boards from our partners.
For low-power cellular connectivity, we’re using the same SparkFun nRF9160 Thing Plus module used in other Golioth reference designs. This feather-compatible module integrates the Nordic nRF9160 System-in-Package (SiP), featuring an Arm Cortex-M33 application processor, an integrated LTE modem, and a GNSS receiver for cellular-based location-tracking. The nRF9160 is fully supported in Zephyr, and has the highest level of support in the Golioth platform (Continuously Verified).
This reference design integrates two off-the-shelf MikroE Click sensor boards:
- GNSS 7 Click board with a u-blox NEO-M9N GNSS module
- CAN SPI Click 3.3V board with a Microchip MCP2515 CAN controller & TI SN65HVD230 CAN transceiver
ECU Simulator
For testing and demonstration purposes, we built an external ECU simulator that allows us to test the reference design firmware without having to connect to a real vehicle's OBD-II port.
Device Photos
Hardware Block Diagram
Open-source Firmware
The firmware source code and pre-built firmware images for this reference design are available on GitHub under a permissive Apache-2.0 license.
The OBD-II / CAN Asset Tracker firmware is based on the Golioth Reference Design Template. Changes from the upstream template are periodically pulled into new releases of this firmware. Check out the firmware CHANGELOG for a detailed list of changes included in each release.
Golioth SDK & Cloud Services
The OBD-II / CAN Asset Tracker firmware uses the Golioth Zephyr SDK to securely connect to the Golioth Cloud, which provides a tightly integrated set of services specifically designed for managing fleets of IoT devices at scale. This includes device authentication, device state and time-series data storage, fleet-wide settings, remote log storage, remote procedure call (RPC), and over-the-air (OTA) firmware updates. You can access these services by logging into the Golioth web console, or programmatically from an authenticated device via the REST API or the Command Line Tools.
Vehicle data is streamed back to Golioth Cloud endpoints and stored in the LightDB Stream time-series database. These readings can be captured as frequently as once-per-second, and can be sent immediately to the Golioth Cloud or sent in batches periodically. Furthermore, when the device is out of cellular range, the reference design firmware will cache the data locally and upload it later when connection to the cellular network is restored. The GPS time is used as the timestamp, so all records in the database will always have an accurate timestamp, even if they are cached on the device for an extended period of time. Using Output Streams, this data can seamlessly be made available to a growing list of external services.
The Settings Service is used to implement custom fleet-wide device settings that can be managed from the Golioth Cloud. Individual settings can be configured at the project or device level and can be managed via the web console or the REST API. For example, this reference design implements a GPS_DELAY_S setting that can be used to dynamically change the delay between GPS readings.
The OBD-II / CAN Asset Tracker firmware also implements Remote Procedure Call (RPC). For example, the get_network_info RPC command can be called to query and return network information for the device.
The Logging Service enables the firmware to send remote log messages from the device. Stored logs can be queried and filtered by timestamp, device, tag, module, and log level.
The device firmware also supports Golioth's Over-The-Air (OTA) Update Service to enable fleet-wide management of device firmware updates. The Golioth Cloud enables granular control over firmware updates, including support for staged rollouts and cohort management.
See the OBD-II / CAN Asset Tracker firmware README for a complete description of all services and settings supported by the device firmware.
Data Visualization
The Golioth REST API makes it easy for external applications or services to access the sensor data streamed from the devices to the LightDB Stream time-series database.
We created a Grafana dashboard for the OBD-II / CAN Asset Tracker that displays the vehicle speed and GPS location reported by each device:
Next Steps
Build it yourself
We provide follow-along guides showing how to build this reference design using widely available off-the-shelf development boards from our partners. We call this Follow-Along Hardware, and we think it's one of the quickest and easiest ways to get started building an IoT proof-of-concept with Golioth.
You will learn how to assemble the hardware, flash a pre-built firmware image onto the device, and connect to the Golioth cloud in minutes. The follow-along hardware runs the same open-source firmware as the custom Golioth hardware described above, and we provide instructions on how to build it yourself if you want to make changes for your specific application.
To get started, choose one of the follow-along guides below:
Request a demo
This OBD-II / CAN Asset Tracker reference design is a great starting point for building your own proof-of-concept. The next step is to integrate the components used in the follow-along hardware into your own custom hardware implementation and build a custom firmware image that connects your device to the Golioth Cloud.
If you would like a demo of this reference design, please contact [email protected].