This article is an excerpt from Telematics-Driven Transformation, available for free download here.
In Part Five of this series, we discussed several use cases for generating value from ELD investments, including reducing detention, improving utilization, dispute reduction and resolution, analytics, and enabling digital and autonomous supply chain capabilities. Here in Part Six, we look at what characteristics to look for when selecting an ELD platform, devices, and applications.
To implement the use cases described in Part Four and Part Five of this series, and gain the value discussed there, it is important to select the right ELD solution. This requires assessing not only the device itself, but also the software platform, driver app, other value-add applications and services, and key characteristics of the solution provider. We start with the platform characteristics first, as these are key and are one way to narrow the field quickly.
Platform Characteristics
Cloud-based solution
Most of the value-add use cases require central retention of information. To achieve that, it is quicker and easier to implement a cloud-based SaaS1 solution than to host your own on-premise server. With a SaaS solution, you always have the latest revision, security patches, and upgrades. With an on-premise approach, you will have to pay for and install your own upgrades. The cloud provider takes responsibility for uptime, security, and system management. With an on-premise system, you have to do all of that yourself.
Open Platform/Evolvability
Virtually all of the use cases require integration with one or more other systems, such as ERP, CRM, billing, supply chain control towers, and BI/analytics applications. Look for solutions that provide a well-thought-out set of APIs (Application Programming Interfaces), a robust SDK (Software Development Kit), and ease of integration. Look for a ‘future-proof’ system, with a flexible architecture, and the ability to evolve the system and devices as needs or regulations change.
Security2
The system should encrypt all data transmitted and stored. You should have complete control over your account and access rights. Try to find a provider with good physical security at the data center, rigorous background checks, security training and ongoing testing for all employees, and a strong technology infrastructure security.3 Ask what type of security audits the solution provider has done, how often and whether or not they are SSAE 18 Type 2 certified.
Scalability and Availability
Find out what kinds of volumes the platform is currently handling and what kind of stress testing the solution provider has done to test scalability. If you can talk to a reference, ask if they have had any performance or availability issues. Regarding availability, a good SaaS provider will guarantee at least 99.9% uptime (that is downtime of about nine hours per year) in their Service Level Agreement. You should ask if they can share records of their actual uptime performance.
Data Ownership
Make sure you are granted full control over the data generated by your ELDs. The data should not be shared with anyone else without your permission. There should be no extra charges for you to access or share your own data. Some providers may want to use aggregated data for analytics to provide value-add services, such as benchmarking. In most cases that is OK, provided you get something out of it, such as being able to benchmark yourself against peers.
ELD Device and Driver App Characteristics
It is critical to do your homework when selecting an ELD device. In the US, manufacturers are allowed to self-certify their ELD. As a result, even though a device is on the FMCSA’s list of registered ELDs, it in fact may be non-compliant. The FMCSA itself has been encouraging ELD buyers to check for frequently reported issues4 before purchasing a device. Canada is trying to avoid these issues by mandating that ELDs are certified by an
approved third-party tester.
All devices must provide functionality mandated by the ELD rule, such as interfacing with the engine, automated capture of each duty status change, capturing location at least every 60 minutes when the vehicle is in motion, record engine-on/off, a graphical grid of duty status changes, auto-change of status when vehicle has been in motion for five consecutive minutes, telematic or local communications, resistance to tampering, and identification of sensor failures.
There are a number of other things to consider when selecting an ELD device, such as:
Price
The most expensive device is not necessarily the best one. The average price for an ELD is around $500, with some costing over $1,000. However, there are some excellent ELDs for around $200 that meet virtually all of the criteria described here. Some providers have many extra hidden charges not included in the upfront charge or base monthly fee, so it is a good idea to probe and find out all of the fees you may be liable for.
Telematics vs. Local
Devices may transfer data using either telematics or local methods, as described on the FMCSA site. It is strongly recommended to select a device with telematics capabilities, as most of the value-add uses are dependent on a real- time remote connection. A device may provide a remote connection using Bluetooth connected to the driver’s phone. However, that requires use of the driver’s private phone (which drivers might rightfully resist) and adds a layer of complexity and possibilities for things to go wrong as the driver tries to pair their phone with the ELD. Therefore, telematics support in the device should be a requirement.
Vehicle remote diagnostics
The device should provide immediate remote (online) visibility into engine faults when they occur. It should be able to interpret and normalize manufacturer’s proprietary fault codes. Both driver and dispatcher should be provided with a fault code action plan, and map tools for locating nearby towing services, repair services, and hotels.
Device security
Devices and server software should mutually authenticate, to ensure that only authorized software is connecting to only authorized devices
Vehicle data collected
By law, all ELDs must interface with the CMV’s Engine Control Module (ECM) to automatically capture engine power status, vehicle motion status, miles driven, and engine hours.
• See if the device collects at least fuel usage, voltage, coolant, and engine temperature as well.
• Check which manufacturer’s proprietary engine codes the device can capture, and whether the system is capable of mapping/normalizing those into a standard set of diagnostic codes.
Pub/Sub5 Data Gathering
The device should proactively generate and send events as they occur, rather than having to be polled by software to find out the status.
Device UI
The interface on the ELD must be very user friendly, requiring near zero training. Features to look for:
• Familiar android or iOS interface.
• Support for NFC key fob or NFC cell phone driver identification and login.
• Simple intuitive interface, with large buttons.
• Spoken voice alerts for warning the driver of aggressive driving or geofence departure.
Collision detection and warning
Some ELDs provide optional forward collision alarm, safe distance warning, and lane departure warnings.
Device form factor and installation
Look for a small device form factor that works well for all of your vehicles. It should be as plug-&-play as possible. Try to find out the expected time, cost, and expertise required for installation of the ELDs, as these can vary considerably. Installation should take less than 30 minutes. Some devices require external antennas, which adds significant installation time and cost.
Device warranty and reliability
Look for at least a one-year warranty. Better yet, some ELDs offer life-time warranties. Ask for statistics on device failure rates, such as MTBF (mean time between failures).
Troubleshooting and firmware upgrade
Look for a device that has simple troubleshooting and supports remote diagnostics and simple firmware upgrade for the ELD. Inquire about remote support, and RMA and replacement processes.
IoT Support
Since a telematics ELD already has cellular service, look for devices that can leverage that to share IoT information from the vehicle. This could include reefer temperature and humidity readings, shock and vibrations, tire pressure, asset tracking, camera/video, trailer door alarm, and collision warnings.
Driver Communications
Some ELDs provide driver-dispatcher messaging and voice communications.
In the Seventh and final article in this series, we examine what to look for in an ELD/telematics solution provider, as well as the value-add applications and services they provide.
_______________________________________________________
1 SaaS = Software-as-a-Service, i.e. a cloud-based application. — Return to article text above
2 A good article on telematics security is 15 Security Recommendations for Building a Telematics Platform Resilient to Cyber Threats. — Return to article text above
3 An excellent set of resources on what to look for in security from a SaaS provider can be found at the Cloud Security Alliance website, including guidance on assessing and ensuring cloud security (free registration required). — Return to article text above
4 Issues they warn about include erroneous fields in the ELD output file, device not preconfigured with the FMCSA’s email address or web service endpoints, complete set of data transfer options not supported, event time formats incorrect. The FMCSA is also maintaining a list of revoked ELDs. — Return to article text above
5 Pub/Sub is short for the publish and subscribe messaging pattern, a type of software communications architecture.. — Return to article text above
To view other articles from this issue of the brief, click here.