|By Kevin Benedict
|April 17, 2014 08:28 PM EDT
|Author Peter Rogers|
· Safety first considerations (like driver distraction)
· Long sales and car vendor app approval process
· Car vendor led UX and ideation processes
· Low risk strategies for selecting apps
· Deal negotiation skills requirement
· Massive market fragmentation.
The analogy VisionMobile offers is one that I remember vividly myself. That of running a small mobile games company (back before the days of iOS and Android App Stores around ) and trying to get a deal with a telecommunications operator in order to convince them to distribute your app on their private App Store. Often games and applications were embedded into the mobile devices and so you also had the option of trying to get a deal with a mobile phone company (which was equally as hard).
With the lack of portability of Java ME, mobile device fragmentation and not having the right business skills to win a decent contract meant that the mobile app market was on its last legs before Apple saved the day with the App Store. This is sadly an analogous state of affairs with apps today designed for the automotive industry.
There are 5 ways to develop Apps for vehicels:
- Run Apps in the In-Vehicle entertainment systems (Blackberry QNX CAR, Windows Embedded Automotive, Linux Genivi and Android)
- Use a link to a smartphone (Airbiquity, OpenCar, CloudCar, SmartDeviceLink / AppLink, MirrorLink, Apple CarPlay, Google Open Automotive Alliance and Windows in the Car)
- Remote access to the vehicle through an API (OnStar, General Motors API, Ford Remote API, Airbiquity, reverse engineering of vehicle protocols)
- Access to data through the On Board Diagnostics port called OBD-II (Dash Labs, Mojio, Carvoyant and MetroMile)
- New and emerging initiatives (W3C Automotive and Web Platform Business Group and OpenXC)
Apple, Google and Microsoft are all making a strong play for a link between the vehicle and their smartphones (#2 above), and effectively using the car as a third party accessory. This actually has the strong benefit that you can upgrade both the hardware and the software easily. It also makes testing easier because you can test on mobile hardware using stubs for the in-vehicle APIs, as opposed to requiring test hardware for the In-Vehicle entertainment systems.
If we look at the Insurance sector then we can see that remote access through an API or access through OBD-II is going to get better diagnostics for initiatives like pay-as-you-drive insurance (MetroMile). The W3C have a new HTML5 for Automotive initiative (http://www.w3.org/community/autowebplatform/) which doesn’t seem to have produced a specification yet. OpenXC is a hardware module which gives access to vehicle data much like OBD-II but it also offers pluggable open hardware modules. I also wanted to mention Carvoyant (http://www.carvoyant.com/) which reads data from OBD-II using a Bluetooth dongle and then sends it to a smartphone which in turns sends it to their Backend-as-a-Service. “Carvoyant is a middleware platform providing development tools enabling connected car applications to become a reality for all the cars on the road today. In plain speak, that means we provide the back end tools helping developers and businesses alike to take advantage of the opportunities a connected car promises to deliver. Carvoyant services developers creating connected car applications (i.e. apps enhancing how cars interact with the world around us via an internet connection). Additionally, our platform serves businesses using the connected car to better communicate their offers to their customers. As a Backend-as-a-Service platform Carvoyant breaks down the data silos inherent in the auto industry. Our system collects data from all makes and models of vehicles built since 1996 across a wide variety of hardware devices and sources. This data is normalized and provided to our customers via our API. Today developers are utilizing this data to create the most robust array of apps and services for the connected car. ”
There are five main routes to markets for vehicle apps:
The first two options require a deal with a vehicle manufacturer. The third option requires a deal with a vehicle manufacturer if you intend to use their private APIs. Only the fourth and fifth options enable you to avoid explicit approval from a vehicle manufacturer but that also means you won't get access to their marketing resources.
- Pre-installation into a vehicle
- Through the vehicle manufacturer’s App Store
- Write an app that runs on a smartphone and integrates with a vehicle through their private SDK
- Write an app that uses OBD-II and requires users to purchase an OBD-II Bluetooth dongle and distribute via a standard App Store
- Write an app that uses OBD-II and piggy-backs on top of an over-the-top platform like Dash or Carvoyant
I like the idea of using an OBD-II dongle in the vehicle to talk with the smartphone. This in turn talks to a cloud service. If Carvoyant / Dash start to see great success with this over-the-top model then hopefully they can grow the ecosystem.
If the dark age before the Apple and Android App Stores have taught us anything it is that developers are the key to success and history does have a habit of repeating itself.
Senior Analyst, Digital Transformation, EBA, Center for the Future of Work Cognizant
***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.