.svg){kind=small}
From its conception, HMKit was designed and built to be used with other protocols besides the Auto API - the car data protocol which is used throughout our platform - to enable data to be read from cars on the road both now and in the future, irrespective of the data formats employed.
Right now, HMKit provides a container for several parameters. However, one of the key components of the HMKit is the Auto API. Ever since launching the first iteration of the Auto API back in 2014, our team of developers at High Mobility has been upgrading and expanding its capabilities. Now, the Auto API can be used to read vehicle data from production cars on the road. To understand the structure of HMKit a little better, take a look at the graphic below. As you can see, HMKit is built in a modular fashion:
Standardisation
Right now, the standardisation of vehicle protocols is becoming increasingly important, as well as a much-discussed topic. We can already see that in the future additional standards for communications with connected vehicles will be introduced. For example, the following three organisations are already working on new vehicle data format specifications: The World Wide Web Consortium (W3C), Connected Car Consortium (CCC), and Sensoris.
Fortunately HMKit is prepared for this eventuality and, when the time comes, it will be possible to use it with protocols besides just the Auto API. If the car industry comes up with another, better, standard, the HMKit libraries can evolve to use these protocols in addition to the Auto API. In fact, in the future it will be possible to use HMKit with any other data format.
At High Mobility we view this as a really positive trend for vehicle data format specifications. Ideally the eventual impact of these specifications will include external APIs and as a result will support better adoption among independent service providers.
Open-source libraries and future flexibility
High Mobility’s innovative and forward-thinking vehicle data platform and simulation environment have evolved and expanded hugely over the last five years. Today, it is possible to develop applications using a variety of programming languages, test them against emulated vehicles, build simulations and then deploy the applications for use with millions of vehicles already on the road.
Should a manufacturer or other entity want to use a different data protocol, they can be certain it can be made to function with HMKit. As our technology continues to support the ever-growing network of connected car owners, manufacturers, and application developers, flexibility in the future is also guaranteed.
In the beginning of 2020 we decided to open source our SDKs and the Auto API. In reality, the Auto API has an array of parsing libraries that have been open source since the beginning, including Swift, Java and Elixir. With the release of the Auto API’s 11th revision, we decided to publish the protocol definition as well. The 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.
Explore for yourself
You’ll find all our libraries on GitHub. Take a look!
- HMKit for iOS: https://github.com/highmobility/hmkit-swift
- HMKit for Android: https://github.com/highmobility/hmkit-android
- HMKit for Node.js: https://github.com/highmobility/hmkit-node
- Auto API: https://github.com/highmobility/auto-api
- Explore all libraries: https://github.com/highmobility
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!
