Q&A: GM on the need for flexibility when designing app-based IVI

Q&A: GM on the need for flexibility when designing app-based IVI

As director of developer ecosystems, Pudar is responsible for driving future service evolution, overseeing developer relations and integration of new apps into GM vehicles. He spoke to TU's Jan Stojaspal about the need for flexibility when designing app-based in-vehicle infotainment (IVI) systems. Pudar was previously director of business development for OnStar, where he led the efforts behind smart grid solutions for electric vehicles and FMV, OnStar’s aftermarket product. He holds a Bachelor of Science degree in mechanical engineering from the General Motors Institute, now Kettering University, and a master’s degree in management from the Massachusetts Institute of Technology’s Sloan School of Management.

In January, GM announced a new application framework to entice third-party developers to create in-vehicle apps and to enable a more customized, updatable driving experience. What are you hoping to accomplish?

Historically, when a customer bought a vehicle, whatever the radio was able to do that was it. As long as the vehicle was on the road, that was all it could do. With our new flexible approach, customers will be able to continue to download new applications, new functionalities and new capabilities. And it’s broader than just the traditional music content. It’s going to be a broad range of entertainment information. There is going to be vehicle telemetry and vehicle diagnostic connections. There is going to be more location-based capabilities and navigation support tools.
In other words, we are talking about an automotive app store.

Yes, the working name for it, at the moment, is GM App Shop, and it will be an app shop customers can access in their vehicle. They will be able to see those apps that are available for their specific vehicle, and they will be able to download the ones they would like to have regular access to. Customers are now quite familiar with this concept in other parts of their lives, and it’s just a natural extension to have the same capability in vehicles. (For more on in-vehicle apps, see Telematics: What’s next for apps and services, part I and Telematics: What’s next for apps and services, part II.)
What are you plans in terms of release dates and numbers of apps?

We are targeting later this year on select vehicles. In terms of the number of apps, that’s really going to be up to the developers. We don’t believe our App Shop is ever going to be the same as the wide open spaces of smartphones’ app markets, where there are hundreds of thousands of apps. We are going to be more selective in the apps we approve for use in vehicles. But, really, it is up to developers how many we will have available. We see a broad interest among the developer community. There is well over a thousand developers that are already engaging with our SDK and basically testing how their concepts can play out in vehicles.
What is the enticement for them? When you write apps for the smartphone, you can reach millions of potential users. With the car, that number is far more limited.

One of the interesting things is that the opposite will very likely be true. Yeah, there are millions of new phones built and sold every single day. And yet, if a developer creates an app for the smartphone world, they are competing with nearly a million other apps. How does a customer even know that a new app came into existence?

If you look at the number of downloads that occurred last year divided by the 800,000 or so apps that are in existence, it turns out to be about a thousand downloads per app on average. And, if you exclude the blockbuster megahits like Angry Birds or the other handful of dominant apps, you are talking an even smaller number of downloads per app. 

So given the fact that the automotive app environment is going to be very uncluttered, there is a very high likelihood that a developer’s app will get downloaded hundreds of thousands of times, if not millions of times, in the course of the first couple of years. So the enticement for developers is that, paradoxically, a vehicle provides a much more ripe opportunity for them.
How will developers make money?

That is entirely up to the developer. We are going to provide the mechanisms for developers to monetize their apps however they see fit. You could imagine that some of the audio streaming, content-based apps might be free with embedded advertising. Paying for downloads is another mechanism. Some developers have premium versions of their apps, where you can pay a small subscription.
What’s in it for GM? How will you pay for it?

We are a car company. And we want to make better cars. If this helps us sell more cars, that’s great. However, this will enhance drivers’ and passengers’ infotainment options, and allow for their vehicles to get additional connectivity over time. It will improve our vehicles through  a better customer experience.
You are not the first to build an automotive app store. Ford is doing it. In Europe, there is Renault, for example. How is your approach different?

The entire industry is engaged in this space; that’s for sure. Still, there are some different approaches to how to execute it. The apps that our customers will use are going to be downloaded into the vehicle and will run from the vehicle. This enables a few advantages, such as ease of access or the ability to create apps that utilize personal vehicle information with the customers’ consent. Other approaches require that all the apps reside on the customer’s phone. This requires extra steps and friction for customers. We want to make as easy, convenient and seamless an approach as we can for our customers.

I like the word flexible in your description of the new application framework. Can you elaborate?

There are three main areas.
One is flexibility in development tools. We have built our framework around industry standards. We are using HTML5 and JavaScript as those are standard tools that developers are very comfortable, very familiar with. The framework itself in the vehicle is essentially a browser that allows these HTML5-, JavaScript-based apps to run. So from a developer’s perspective, it’s a minor departure from what they have been doing. (For more on HTML5, see Telematics and HTML5: Taking a closer look.)
Flexibility in customer options is another aspect. The customer may want to have the apps connect via an existing data plan. Or they can use the in-vehicle connectivity.
Finally, there is flexibility in terms of the nature of the connectivity that the developers’ apps may want to rely upon. We have two kinds of APIs that developers can have access to.

One kind, called In-Vehicle APIs,  directly connects to information on the electrical architecture of the vehicle. These are the apps that are accessed through the infotainment system. 

The other kind, called Remote APIs, leverages the existing OnStar connectivity, which is the remote connectivity, so that an app that resides on a smartphone, on a tablet or a company’s web server can reach through the secure OnStar connection and interact with the vehicle when the customer is not even at the vehicle.
A very obvious example of the latter is a customer communicating via social media with a friend, and they are agreeing to meet some place. In their social media system, there could be a function that they can invoke to automatically senda destination to the vehicle. So as soon as they get into their car, the navigation system is routing them right away.
How will the new application framework work with OnStar?

OnStar is a separate business model, separate product and service offering for our customers. There is no requirement for an OnStar subscription to access this new app environment. You can almost think of OnStar as a preexisting app that’s in the vehicle already. It is a premium, high-quality app that handles your emergency needs, your diagnostic needs, your connectivity needs and your navigation support needs. This new app framework that we are building is going to allow many more apps to be available to customers, some of them might even feel like little snippets of stuff that is OnStar-related. And there is going to be a broad range of things that just did not exist before.
Frankly, some of this may be the kinds of things that we had considered adding to OnStar over the years. But when you stacked up our business model against these niche things that some customers wanted, it never made sense in the past for us to be everything to everybody. Now, in an app-centric world, if I want something, developers will build it, and it will be available for me so I can customize and fine-tune what my vehicle is capable of doing.

Jan Stojaspal is the editor of Telematics Update.

For the latest on in-car apps and content, visit Content & Apps for Automotive Europe 2013 on June 18-19 in Munich and Telematics Munich 2013 on November 11-12

For all the latest telematics trends, check out V2V & V2I for Auto Safety USA 2013 on July 9-10 in Novi, MI, Insurance Telematics USA 2013 on September 4-5 in Chicago,Telematics Russia 2013 in September in Moscow, Telematics LATAM 2013 in September in Sao Paulo, Brazil, Telematics Japan 2013 on October 8-10 in Tokyo.

For exclusive telematics business analysis and insight, check out TU’s reports: Telematics Connectivity Strategies Report 2013The Automotive HMI Report 2013Insurance Telematics Report 2013 and Fleet & Asset Management Report 2012.

Leave a comment

Your email address will not be published. Required fields are marked *