OpenCab is a simple, well-documented interface spec that lets commercial trucking apps share driver and vehicle information.
This makes it possible for devices like ELDs, sensors, and cameras to work together seamlessly, by having their proprietary apps communicate with each other through OpenCab.
Or keep reading to learn more…
OpenCab’s goal is to accelerate the development of in-cab technologies by eliminating custom SDKs. It provides an app-to-app communication protocol that the whole trucking industry can unify around.
OpenCab empowers vendors and fleets to create a superior in-cab driver experience, using a streamlined and accelerated development workflow.
By adopting a standardized integration pattern, solution providers can develop integrations with other providers much more easily, with lower up-front costs and less tech debt. Fleets, in turn, can assemble best-of-breed solutions with greater confidence, and spend less time on project management trying to get providers to work with each other.
The direct consumers of OpenCab are software developers—whether providers building in-cab driver-centric commercial trucking apps (e.g. telematics, HOS, workflow), or in-house developers at large fleets building custom line-of-business apps. But OpenCab also benefits the users of these apps: the carriers themselves, who need to integrate multiple complex systems—often each with their own mobile app or hardware—into a single, easy-to-learn tool for their drivers.
From both an engineering and a project implementation perspective, using OpenCab is simply the most efficient thing to do. It sets up vendors and fleets for success with future integrations.
Here are a few examples of what the OpenCab spec can be used for, and how it makes both drivers’ jobs much easier, and benefits fleets through increased efficiency and transparency.
An app responsible for driver HOS shares “drive time remaining” information with the app for planning routes. It can do this directly through OpenCab, even if the current HOS has not been delivered to an external server yet, or if the truck is in an area with no connectivity and can’t synchronize with home base. The route planner then finds appropriate rest areas within the legal driving duration, and displays them in the trip planner so the driver can choose an optimized route. Once his route is selected, the planning app sends it to the navigation app via OpenCab (so he can start navigating), and to dispatch (so they can appraise the receiver with an accurate ETA).
A turn-by-turn navigation app reads aloud (using TTS) a vehicle or trailer fault code that was detected by a separate telematics app and communicated through OpenCab. The driver can then determine whether the code is urgent, or whether it can wait until his next stop. (Which sure beats a single “something is wrong” dashboard light.)
A driver physically hooks up a smart trailer, and the app connected to it records the trailer identifier. It then submits this to the TMS and driver workflow app via OpenCab, without the driver having to re-type the number. If the number was not the expected ID for the load, the app can alert the driver when he returns to the cab that he may have picked out the wrong trailer from a bunch of identical-looking ones.
A freshly-installed app for a new vehicle device—a camera, perhaps, or a replacement accelerometer—uses OpenCab to perform a sign-on (SSO), based on the identity provided by an already-signed-in app. It automatically connects up to the truck systems, so the driver doesn’t have to manually log in to yet another app.
The driver’s navigation app talks to the truck’s fuel sensor through OpenCab. When it notices that fuel levels are low, it marks where on the route refueling will be required in order to minimize disruption to the load.
A workflow app tracking the driver’s whole day receives a harsh braking alert via OpenCab from an accelerometer. It notes the time and weather conditions, connects to the front- and rear-facing cameras using OpenCab so that it can take an instant snapshot, and then marks the spot on the map by communicating through OpenCab to the navigation app. Having done this, it flags the event for later review, and adds an entry in the driver manager’s agenda for the next day.
This is just a sampling of our vision for how OpenCab can improve driver and fleet workflows. There is really no limit to how vendors can use the spec to develop custom integrations with other apps. Surprise us!
OpenCab is developed and maintained by Eleos Technologies, the creator of the Eleos custom driver app platform. The spec emerged from working with many different partners to build best-in-class driver experiences. We have worked with vendors offering navigation functionality, workflow apps, HOS management, safety cameras, and more.
Our focus is on providing a single pane of glass for drivers—a unified app that can integrate all the functionalities they need to use in their jobs. Connecting the various systems and apps, and synthesizing this information, proved to be no simple task. When multiple providers were bringing different parts to the table, a great deal of custom integration work was required to get each app talking to the other.
We wanted to provide a compelling alternative to custom SDKs, which are a development and maintenance nightmare, and all-in-one platform solutions, which are typically characterized by vendor-lock-in, and often involve slow and clumsy integrations. So we created OpenCab.
You could go off and create your own way of doing things—or you can move much faster and enhance the value of your product by adopting the OpenCab standard. If you think that makes sense, why not join us?
If you’re interested in adopting OpenCab, in learning more about it, in extending it, or you’d just like to ask us questions, please get in touch:
