Levels 1 to 10 — The Auto API

High Mobility
Apr 17, 2020 · 4 min read

We are often asked what makes the Auto API so powerful when compared to the solutions offered by other, similar platforms. The short answer is we have refined our data protocol over a number of years using a combination of our own work and crowd-sourcing.

In this article we’ll be taking a longer look at the evolution of HIGH MOBILITY’s standardised protocol for connected cars, a standardised connected car API called the Auto API. But before we do that, let’s have a quick look at what you can do with the Auto API today.

Today, applications that use the Auto API are compatible with millions of cars already on the road in Europe — and literally thousands of new compatible cars hit the road every day. With the car owner’s consent, it is possible for an application to read vehicle data using our standardised API. Slowly but surely the aftermarket hardware, still used by most independent service providers, is becoming a thing of the past.

The Auto API is a binary protocol and was designed from the outset to work in a mature IoT world. During its creation and evolution our team never lost sight of the fact that it would need to work in embedded IoT solutions, meaning it would have to work on low-computing power devices at a sensor level. At the same time, the HIGH MOBILITY platform needed to — and still needs to — support both the pulling and pushing of data (even though pushing data into the vehicles is not yet allowed) which is why we’ve made sure that the architecture allows vehicle data to be pushed to applications on a protocol level.

Levels 1–4

Ever since launching the first iteration of the Auto API in 2014, our team of developers has been upgrading and expanding its capabilities. The very first proof of concept was quite simple, and used Bluetooth to connect to a car from a few meters away. It was performed using Auto API Level 1, which we used to lock and unlock the doors of a car using an iOS-compatible version of our SDK, HMKit.

Over the next two years, we developed the next three versions of the Auto API — named Level 2, Level 3, and Level 4 — which saw the addition of an Android SDK for improved device compatibility, as well as the first additional capabilities, which included Trunk Access, Charging State, and Diagnostics. In 2016, we introduced telematics connectivity in the SDKs alongside Bluetooth. This was a crucial development for the Auto API; at this point it was able to communicate with stock vehicles using their on-board SIM cards and telematics systems.

Levels 5–7

In 2017, we released Level 5, HMKit Node.js, and opened the platform up to developers. To encourage developers around the world to explore the new features, we held our first competition with Mercedes-Benz called the Digital Challenge. Participants used our new car emulator technology and Simulations function to prototype innovative applications.

In 2018, we introduced Levels 6 and 7 and debuted the REST API. We also noticed that the online hackathon format worked really well in combination with our browser-based car emulators. In 2018 we established a collaboration with Porsche and debuted their open innovation platform — called the Next OI Competition. Together with Porsche we added Race and Offroad APIs into our data protocol and emulators. At this point, the Auto API already had hundreds of data points, and could allow an application to read almost anything about the status of a vehicle. Additionally, in Develop Mode it became possible to “write” to many data points, including Ignition, Chassis Settings, and Honk Horn / Flash Lights.

Levels 8–10

In 2019 new capabilities were added like Historical, MultiCommand, Usage and more. The same year we launched as a go-live partner Neutral Server for Mercedes-Benz. BMW and MINI adapter followed suit after a few months.

Level 11

With the release of the Auto API’s 11th revision, we have made the protocol definition open source. As all car manufacturers use their own proprietary data formats, we have been refining the Auto API for years to remove the fragmentation. The Auto API has an array of parsing libraries that have been open source since the beginning, including Swift, Java and Elixir.

The now open sourced definition is documented in YAML, and includes almost 300 vehicle-specific data points. The protocol is specified on a binary level and is applicable to any environment.

You’ll find all our libraries on GitHub. Take a look!

We hope these open source libraries will further simplify the way you work with car data and vehicle APIs. Let us know what you think!

Want to learn more about building connected car applications? Head over to high-mobility.com or post a question in our forum or in the dedicated Slack group.

High Mobility

Food for thoughts – the future of cars & data driven connected mobility services