Blog: Open Telematics API: NMFTA’s Fix for Companies at Risk of Vendor Lock

Laptop with unreadable language displayed in rows

Share This...

By: NMFTA’s Senior Cybersecurity Research Engineer Ben Gardiner

Just over two years ago, Rand McNally had an issue with its ELD service. When the service was not able to return, fleets who had integrated their back ends into the Rand McNally servers were forced to go back and rebuild everything from scratch.

This is an extreme example of what can happen to a company that finds itself in “vendor lock.” Being completely reliant on one telematics service provider (TSP) leaves you tremendously vulnerable if that TSP crashes or otherwise becomes unavailable.

NMFTA does not want its member companies to face that type of jeopardy, which is why we have developed an Open Telematics API designed to protect against such a risk.

The purpose of the Open Telematics API is to free fleet operators to do their integrations one time, knowing that it would not be difficult to change TSPs if that became necessary.

It’s a very simple process. Fleet operators can simply keep their code base and switch to a different TSP if they ever need to do so. TSPs can extend the API in ways that will be backward- and forward-compatible.

Our team at NMFTA did all the hard work. We wrote the API in consultation with fleets and TSPs – enumerating all the different integrations to cover maintenance, operations, compliance, coaching and other department features. All these use cases are laid out step-by-step and have references to the necessary API end points in the documentation.

We know a great deal about how LTL trucking companies use TSPs, and what the TSPs are being asked to provide. But we added a questionnaire that fleets can send to their TSPs at the outset of the process, in order to have a full evaluation of just how much of the API they support.

Because we want as much of the industry as possible to benefit from the Open Telematics API, we have asked the American Trucking Associations Technology & Maintenance Council (TMC) to establish it as a recommended practice for the industry. That request is now under consideration.

But regardless of if or when it becomes an officially recommended practice, it is an excellent way for any company to protect itself against the risk of vender lock, and it’s available now.

Any company that wants to take this step can access the information from NMFTA’s GitHub and give the spec – either in the machine-readable form or the rendered HTML – to its developers so they can determine which pieces of the API they need to use. Developers may also benefit from the Software Development Kits (SDKs) and prototypes available there too.

By taking those pieces of the API and the questionnaire answers from their TSP, they can determine exactly how many pieces of the API integration they need to implement.

Rest assured, NMFTA is a security-first organization, so you will find considerable security material up front – including sections on authentication and authorization. Each end point has access controls for various roles, including one that is PII-free so as to avoid California- and European-style privacy regulations on systems wherever possible.

There is also a security manifest that states which of the NIST 800-53 controls are satisfied by the design of the API, as well as security requirements for those who implement the server as well as for those who implement the clients.

The bottom line is that we want the industry to be protected against the risks of vendor-lock. We also want the solution to be highly secure and easy to use. That’s what we have accomplished with the Open Telematics API. We look forward to the entire industry benefiting from it.