Blog Post

Why is ELD Software so Difficult to Write?

Stephen G. Eick
eick@vistracks.com
14-Dec-16

At VisTracks we do white label ELD software.  As the CTO of the company I’m often involved in talking with customers and prospective partners.  A common question is “ what makes ELD software so difficult?”  Over the last two weeks I was asked this question three different times.  Once by a prospective investor, a 2nd by channel partner, and a third time by a prospective partner whose internal development team was months behind on their internal ELD development program.  

Regulations are Dense

First, the regulations are difficult to understand.  The ELD mandate is 516 pages long and contains page after page of regulations, special cases, references to previous regulations, examples, etc.  It’s dense and beyond the reach of all but the most motivated readers.  As a software developer, our ELD software must comply with every regulation exactly including every edge case and exception.  The denseness and quantity of the regulations makes this a formidable task.

HOS Driving Rules are Complex

Second, the Hours of Service (HOS) driving rules are complex. In our application once per minute we recalculate all of the relevant driving rules, either federal, California or Texas Intrastate, or Canadian, for property or passenger, depending on which rules set is active for the driver.  A simple driving rule is that a driver must take a 30 minute break at least once every eight driving hours and that a driver must not drive more than 11 hours per day.  Even for this simple rule it quickly gets complicated.  Texas intrastate drivers no break is required.  Alaska drivers may drive 15 hours per day.  The driving limits for property carrying vehicles are different than for passenger carrying vehicles.  Drivers operating under the short-haul exemption are not required to take the 30 minute break.  Under adverse driving conditions the 11 driving hours is extended by two and under emergency conditions it is totally relaxed.  

As a software developer it’s challenging to implement all of the edge conditions around the driving rules.  The code is chocked full of special cases than handle all of the conditions.  And, to ensure that the rules are implemented correctly, there are hundreds of automated test cases that exercise every rule and combination.

Syncing is Hard

Third, the ELD must cache and sync HOS data with back office servers.  In our ELD implementation we write the ELD data to the SQLite database on the mobile device, either Android or iOS, and sync this information with our AWS servers.  Syncing a single table is not difficult.  However, for an ELD solution in our implementation we sync about 15 tables.  What makes this challenging is that there are relationships among the tables that have to be maintained through the sync process, how to handle errors when particular transactions fail to sync, if the syncing should occur in real-time or occur at specific time such as login or logout, whether it should take place on metered or just on non-metered networks, and what the retry algorithm should be when the sync fails.

Maintaining Integral Synchronization

Forth, the mandate requires that the ELD be “Integrally Synchronized” with the vehicle engine control unit (ECM).  For an ELD integral synchronization means that that ELD monitors the vehicle’s engine operation to automatically capture data including: the engine’s power status, vehicle’s motion status, miles driven, and engine hours.  The data items must be available within five seconds of the need.  In practice, what this means is that there is a device, which connects to the vehicle bus, that monitors bus traffic and transmits required data items to the ELD software.  At VisTracks we call these vbus devices and support devices that communicate using wifi, wifi-direct, Bluetooth classic, Bluetooth LE, and serial connections.  Integrally synchronized means that the vbus device must continuously monitor the vehicle to capture engine power status, vehicle motion status, miles driven value, and total engine hours.

The code to support a vbus device is rather tricky to write because it reading a continuous stream of events, processing those events on a background thread so it won’t interfere with driver’s experience with the mobile device UI and handling disconnects and reconnects.  In addition, FMCSA requires that the software monitor itself and must issue a diagnostic if a five second timing requirement is not met.  

 

To connect to the vehicle VisTracks supports both manual and automatic connections.  What this means is that a driver, for the mobile ELD, or an administrator, for a mounted ELD, may step through a sequence of menus to manually connect the mobile device to the vehicle.  After the connection is made the first time, our software remembers the connection parameters and for any subsequent connection it will connect automatically using the remembered parameters.


One test that we run is called the “walkaway test.”  For this test an engineer connects the mobile device to the vbus device in the vehicle and starts walking away until the connection is dropped.  Then he gradually walks back toward the vehicle and verifies that the connection re-establishes itself and that the data flow resumes.  Internally in our code when the connection is dropped the software goes into an infinite retry loop with a one second delay between re-attempts.

Running Background Tasks is Tricky

Fifth, in a well-written application the user interface must be responsive and not critical tasks should be performed in the background at a lower priority.  In our application we

  • ELD self-monitoring for diagnostics and malfunctions
  • Driver hours of service violation calculations
  • Position calculations and degraded reverse geocoding
  • Border crossing calculations for IFTA fuel tax reporting
  • Real-time processing of vbus data streams
  • Driver status processing for communicating driver hours to our back office servers and portal

Back Office and Web Services for APIs

Sixth, besides the software that runs on the mobile device in the vehicle, a complete ELD solution also contains a portal and back office servers.  The portal provides the fleet manager with real-time visibility to his driver and the server provides apis for IT system integration.  From the software developer’s perspective, there is just a lot of code to write, debug, and maintain.  


To create an ELD requires a serious development effort and a serious, team with many skill sets.  Our team has about 25 technical staff whose skillsets span Android, iOS, Portal Development, J2EE Server Development, and database systems.

Conclusion

Creating a robust ELD solution is very difficult and requires serious software and system expertise.  Many companies will not be successful in their development efforts.