OBD-II / CAN Asset Tracker: A Golioth Reference Design
Organizations that manage fleets of vehicles are increasingly turning to IoT solutions to enable real-time management and monitoring across their entire fleet. 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.
Golioth makes it easy to prototype, deploy, and manage vehicle telematics solutions: connect and secure devices, send vehicle data to the web, update device firmware Over-the-Air, and scale your fleet with our instant IoT cloud.
OBD-II / CAN Asset Tracker
This reference design provides an end-to-end “proof of concept” showing how to securely stream real-time vehicle location and speed data to the Golioth cloud. We also provide an example of how to use the Golioth REST API to display this data in an external online dashboard.
We started with our existing Cold Chain Tracker reference design and added a controller area network (CAN) interface, enabling the device to communicate on a vehicle’s CAN bus. We initially wanted to make a “generic” CAN asset tracker that could work with any vehicle. However, for passenger cars, each manufacturer defines its own standard for the higher-layer protocols used on the CAN bus. To decode the raw CAN bus data into physical values that could be displayed in an online dashboard, we would need to use a proprietary “DBC” database file, which are not typically published by the vehicle manufacturers.
Thankfully, most modern cars have a legally mandated on-board diagnostic interface known as OBD-II. Since 2008, a CAN-based protocol (defined in ISO 15765) has been the mandatory protocol for OBD-II in all cars sold in the US. Other standards (SAE J1979/ISO 15031-5) define a set of OBD-II Parameter IDs (PIDs) which are required to be supported across manufacturers. These PIDs provide a standardized way for diagnostic test equipment to monitor real-time data like the vehicle speed or engine RPM.
To enable the OBD-II / CAN Asset Tracker to work generically across vehicle manufacturers, the hardware port in a vehicle, and the firmware requests the “vehicle speed” PID via the OBD-II CAN protocol
any CAN-based protocol. This includes J1939 for heavy-duty vehicles, CANopen for industrial machinery, and NMEA 2000
Hardware
The OBD-II / CAN Asset Tracker 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. We designed this platform to demonstrate how it’s possible to quickly develop a proof-of-concept using widely available off-the-shelf modules.
It also includes the new Ostentus front panel that provides an ePaper display for sensor readings, back-lit LED indicators, and capacitive touch buttons.
For low-power cellular connectivity, we’re using the same SparkFun nRF9160 Thing Plus module used in other Golioth reference designs (such as the IoT Trashcan Monitor). 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
Check out the Project Page for the full parts list.
Firmware
The firmware for this reference design uses the Golioth Zephyr SDK to implement device management features. This includes device authentication, streaming sensor data to Golioth’s LightDB Stream time-series database, logging, and over-the-air (OTA) firmware updates.
The Golioth Settings Service is used to implement custom run-time configurable device settings that can be managed from the Golioth Cloud. Settings can be configured at the project or individual device level and can be managed via the web console or the REST API.
For example, the OBD-II / CAN Asset Tracker firmware implements a VEHICLE_SPEED_DELAY_S
setting that controls how often the vehicle speed is requested from the OBD-II port.
The firmware also uses the Golioth LightDB State service. We’re using this reference design at trade shows and for customer demos in conference rooms where it’s not always possible to get a GPS signal. As a fallback, we can set a “fake” GPS location in the Golioth Console, and the device will use that location when a real GPS location is not available.
Finally, the firmware implements the Golioth Remote Procedure Call (RPC) service. For example, the set_log_level
RPC command can be called to enable debug logging for a specific device.
Cloud
The Golioth Cloud provides a tightly integrated set of services specifically designed for managing fleets of IoT devices at scale:
- LightDB State: bidirectional real-time device state database
- LightDB Stream: database for storing time-series data
- Logging: centralized device log storage
- Settings: device settings management
- OTA: Over-the-Air firmware updates with one-click rollback
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.
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 that displays the vehicle location and speed sent by each device:
More Information
For more information about the OBD-II / CAN Asset Tracker reference design, check out the project page:
https://projects.golioth.io/reference-designs/can-asset-tracker/
Please contact [email protected] for access to the hardware design files and firmware source code for this and other Golioth reference designs. You can also drop us a note on our Forum or on our Discord if you would like to suggest ideas for other IoT reference designs you would like to see us build.
Start the discussion at forum.golioth.io