The Programmable Car: Apps, APIs, Data and Ecosystems Programmable Car Hello, welcome to todays webinar on the programmable car. My name is Brian Mulloy and you can follow me on Twitter. My handle is landlessness. A bunch of the content we talk about is on an active group on Google called api-craft, and another on app-craft, which is for the consumption side of APIs.
This article and all the articles we create on this webinar series are available on YouTube on our YouTube channel, which is youtube.comapigee, and the slides will be available on SlideShare on slideshare.netapigee. This is an exciting topic its one of my favorites. So, when you tell folks you are working on stuff thats related to cars, theres been so much abuse by the automakers that sometimes its like punching a Bozo clown right in the face. I think it started with Bill Gates when he compared software advances verses how the automobile is advancing in respect to technology.
I think that, after a decade in Silicon Valley and now two years in Detroit, thinking about connected car and programmable car applications, theres a different perspective that I think is compelling. Back in the day cars used to look like this this is how cars were built. And, I think for a lot of folks, when they think about how a car is created and the technology that they think it is just about how wheels are put on axels, and attaching the axels to the chassis but its really progressed quit a bit since then.
Cars are designed using virtual reality software. They are tested using simulators, which are made of a bunch of software as well. And, to an increasing degree, they are manufactured by the code that roboticists write, that power robots on the manufacturing floor. With the advent of electric cars, theres a lot of code that goes into making sure that the power train works like its supposed to. In fact, I heard a senior executive at a car maker describe that most people actually think they are driving their cars when, in reality, whats happening is that they are making gestures to the software and the software interrupts those gesture and figures out how to translate it to the automobile, whether its your how your breaking or steering.
And, of course, all the software thats in the infotainment center. This is an interesting time to be thinking about the automobile. In fact, recently had an awesome article I am just going to read a quote from it. The amount of software in the average vehicle has grown exponentiallya typical new car has about 100 million lines of codewith the advent of sophisticated, cloud-connected infotainment systems.
Software has become a competitive advantage as vital to General Motors or Toyota as it is to Apple of Google. Doug Newcomb, The Next Big OS War Is in Your Dashboard, Wired, December 3, 2012 Not to mention the cars that were used to today but theres a bunch of progress being made with autonomous vehicles. This is actually a Lexus at the Toyota Research Institute, just down the road from where we are in Detroit here this is in Ann Arbor. Once this happens, the cockpit of the car will transform pretty quickly into a focus on office productivity and personal entertainment.
For developers, who have been making apps for smartphones and there are quite a few folks doing that now whether its for the Android, iOS, or other platforms, and for people who are messing around with Open Source hardware like the very popular Arduino and others like Raspberry Pie, the car is sort of a dream platform to start hacking on and doing other cool things with. What Id like to do is just hope right into it and talk about things for a couple of perspectives. One is from the perspective of the app developer, who is going to build an app for an automobile and the other is from the perspective of the carmaker. And, at the end, make a couple of quick conclusions. This is sort of an introductory talk about the programmable, but we plan to do a few more discussion on this in the future.
There are three core use cases when it comes to building apps with respect to automobiles. The first one is about having a Smartphone app within the car. When you have your Smartphone and its in the car, and there is some sort of communication between the Smartphone and the vehicle. The second is, you have a Smartphone app and you are away from the car, like a remote application scenario.
And, the third case is a Head Unit App, where you build an app right on top of the vehicle and take advantage of all of the actuators and sensors that are in the car. So lets walk through each of these scenarios. The first is the Smartphone app within the car. Here is an example of this and is something that actually exists in the world today.
You want to use the cars infotainment display and controls to play music on a Smartphone app that you, as a developer have built. So if you are using Pandora on a Smartphone app inside of your vehicle. How does this work? Its usually pretty simple in terms of the logical architecture. You have a Smartphone you have an app thats been developed to run on the Smartphone, theres a serial connection, such as Bluetooth or USB that interacting with the head unit.
Were going to look at an example from on of the automakers. So well look at Fords app link. They provide both an Android and iOS SDK for app developers. For Android, the developer adds the .jar files that you can get from Ford to the app project. And for iOS, the developer imports Fords XCode project files and links them to the app project with Objective C. This is what this looks like for Android and iOS.
On the top line you see Android and on the bottom iOS. Smartphone, app within the car Use Case: The use case we want to accomplish is very simple. The idea is that I am looking at my Infotainment Center and I press the OK button, once I do that I want the audio to start playing from the Smartphone. You see we are doing a simple event listener onOnButtonPress and check to see that the button is labeled OK, and if it is we start the audio player. Its fairly simple to see how you can get in to make the Head Unit interact.
So to do the other more sophisticated stuff its just a matter of learning the rest of the API, which is well designed in the same way this software API is for the methods you see here. Smartphone, app outside the car Use Case: The idea here is you are creating a Smartphone app outside of the vehicle. So the use case could be youve just landed at the airport, youre waiting at baggage claim, you pull out your Smartphone, and start your vehicle while its parked outside at the airport parking lot. So how does that work?
The scenario is you have a Smartphone device that is talking to the cloud, using an HTTP API that the car company has provided. The car company is running the logic behind the API up in one of their centers somewhere. On the other side of that, once it gets a request to do something to the vehicle, in this case, start the car, it sends some sort of signal over the web to down to the vehicle.
This could be some sort of proprietary protocol, an SMS, or an MQTT, which is an emerging protocol to do small, embedded system stuff. GM provides a simple web API for developers to do this. So lets take a look at this. The developer registers at GMs developer portal and request an access token.
This works like any other Web API would work, from say Twitter or Facebook. You request your access token, and once you get that you are doing simple HTTP to actually make the method call, and you are using OAuth 2.0 to handle the authentication part of it. So you can see here, this is the actual GM Web API. Its a really nicely designed API they have the version number right there.
You provide your vehicle identification number, the VIN and then you issue the command. In this case, its start and then your car will have started. Head Unit, app inside the car Use Case: This is the case where you are not necessarily concerned about having a Smartphone involved, but you have an interesting idea for how an app could work inside the infotainment center.
This first method is a quick synchronous call to get the actual vehicle speed. The next to calls are asynchronous callbacks, where you have a success or failure function. The second one helps you access the radio info volume, channel setting, etc., and the third on allows you to get your Web service requests out to your backend.
For me, this is interesting stuff that somebody, who has enough savvy to build a Web app with the browser, can build an app that runs inside of the vehicle. The progress that we have today is tangible. The stuff that you see from Ford for the in-vehicle case, with the Smartphone connected to the car and the stuff that you see from GM running on the Head Unit and connected within the car remotely, is exciting stuff.
Weve come a long way in just the past few years since this space started heating up. What are the risks? Now were going to switch and talk about this from the perspective of the automakers. The risks are not insignificant. The folks we work with refer to this as the CNN moment this is the moment where you wake up in the morning, you are drinking your coffee, and you turn on the news to see that some hacker has unlocked every vehicle in a city that were then stolen.
Or, the driver was distracted by an app and an accident took place. So there are significant property and physical risks to the person around this kind of stuff over building a Facebook or Twitter platform. The risks here are inherently higher.
Not to mention that most of what we have traditionally done is in the app and Web world, and the auto industry is a highly regulated industry with a lot of hurdles to overcome by comparison. If we contrast the automaker platforms with the traditional software developer platforms, say a traditional Web API thats going to access as Web service and power some apps, we must account for two key vectors. The first is features because you have your API, theres a bunch of features laid out, and theres what the apps built upon the API platform are going to do. The second is around security, the authentication and the authorization for what the app, the app developer, and the app user all have access to. Now, weve solved this to some extent with three-legged auth standards, where you have the consumer in this case the driver of the vehicle to decide the apps that are put into the vehicle, an OEM like GM, Ford, Toyota, and Telsa, or the app developer, who is creating the app that they want to put inside of the Head Unit.
Some of this stuff is already there. In fact, GM uses OAuth 2.0, as already indicated. The important other issues is safety. An executive at Ford often talks about this as the 70 mile per hour problem, which is to say when you are operating apps and infotainment systems in the car, its all about physical safety.
Its a totally different scenario thats happening. The way to think of this from the carmakers perspective is that they have to build the ultimate sandbox, if they are going to make the platform story stick. They have to include this notion of physical safety. For example, we were just on a trip to Germany talking to some of the carmakers there.
Its really important that when you say you are going to control the way and app works running on your Smartphone, they want to encourage the app developer to as much control into the physical knobs and switches in your car because its easier to use those in a less distracted way than on navigating on the glass of a Smartphone. Its a significant undertaking and I dont envy the job of the folks who are trying to get this right. There is another inherent issue, which is fundamental to this market.
If you look at the typical price point of an automobile, it averages to $30,000. A washing machine is about $1,000, whereas, a Smartphone once subsidized by the Telco is $200. With that price point comes a certain amount of expectations around life expectancy.
Right now the average car life expectancy is about 10 years, as is the washing machine, whereas the Smartphone has a 21-month cycle. So we have a mismatch in between automobile technology and the consumer electronics world, where things can become obsolete in two years, and the automobile world with its high price point is moving at the speed of decades. So that mismatch between what the consumer expectation is and what the automobile will do is creating a lot of innovation for the platform, especially when it comes to updating the software in a way thats easy for the user to do. And not having to do the whole recall channel, where the vehicle gets sent back to the dealer to get software updates.
There is quite a bit there to make sure the frequency of the consumer expectations matches whats going to happen with the automobile. There is also the notion of culture. This is also an interesting issue. This is the value chain of the traditional software world for the Web and world of aps. check for more recent slide So, from a platform company, like Facebook, Twitter, or Amazon that puts out an API that they market to application developers.
The application developers take the Web API and the APIs from the device and they build apps. The apps go out from an App Store and ultimately are used by an app user. This is the world that many of us from software and the Web are comfortable with. The important point here is if you look between the platform company and the application user, the developer is in the middle.
That means that the platform company is comfortable going from a direct model to an indirect model, where there is an app developer who links to some sort of app store to get to the end user. The next step is what the traditional car company model looks like around the globe, which is more or less the same. The car company relies on a tier of suppliers, so you can think of the car company as the OEM and its supplies.
So often, the idea of an app developer talking about getting their app into the next car models, is a very difficult proposition because the app developer calling the car company directly is not one of the major tier one suppliers. So, thats the first step, how does the app developer get into the sort of situation where there is this hierarchical set of tiers. The other more interesting problem, from the perspective of the developer, is the Car, Car Company, and Car Dealer directly interfaces with the customer. There are no intermediate steps in this model. What this means is, that if you are in your vehicle and you inventoried all the parts and the companies that supply all those parts, its a staggering number of companies that provide the capabilities that make that car work.
If you notice though, there is typically only one brand on the product and thats the brand of the OEM. This is deeply ingrained in the way car companies work with their partners. There is one exception to this, which is the thing we need to crack here, so that the part of the value chain we find interesting the App Developer, App, and APIs can be sandwiched into this value chain so it looks more like the App value chain. There is one case where you can see a supplier in automobiles and thats in high-end luxury vehicles, you occasionally see this for the audio system on head unit or speakers. When we are pushing out how the app platform should work, this is the model that we need to follow.
We need to show that this type of approach can work. You see this from many of the car leaders now that when you have your Pandora app connected to vehicle through Fords app link, you will actually see the Pandora logo show up on the display. So things are moving in the right direction.
Another question is, should carmakers have an App Store? If the answer to that is no and some OEMs strongly say the answer is no and will strategically be no for a long time, then what you are left with is that the only apps that will ever make it into the car will already have proved themselves on Smartphones. Pandora, Radio, and Spotify are already in the car because they are successful on a Smartphone, but theres a whole other class of apps that might be interesting to the driver but it wouldnt make any sense that it go through the hurdles of the Smartphone world. If you are going to wrap the content of all of the sensors, actuators, and computing power of the vehicle around the customers context, then you have to unleash the ecosystem that the app developer community can provide.
And, then, the only way to deliver that is through some sort of App Store. It doesnt have to be as big as the App Store on iTunes but there needs to be some sort of expression of that app to meet the customers. For me, this is what the future looks like.
Now, to put it into a historical context, I wont claim to be an auto historian, I see, in terms of a skill set that needs to exist inside of a car making organization to be successful, it has changed over time. The companies that have been successful have put people in leadership positions within these companies at the right moment that had the right background. If you look at the entry of the car, the tinkering really happened in Southern Germany, in Stutggard and in Bavaria, where you had Benz, Daimler, and Mybach working as tinkerers, as inventors, creating the first car.
Ford came along, although he wasnt trained officially as a mechanical engineer, he used a very strong mechanical engineering sense. He applied a lot of science to the creation of mass production of the automobile, and he had smart people around him like William Knudsen to make that happen. Once mass production started, people from Porsche and Toyota came to Detroit to find out what the mass production model was all about since they were on the cutting edge of that. The next wave is the Kettering wave, among other things he invented the first electric starter. People used to have to break their arms using the crank starter, and because his training was in electrical engineering, to do that his company Delco became part of general motors.
General Motors rode that wave of strong, sophisticated features in their luxury brand Cadillac that found there way into their other vehicles. The next wave started with the Galvin brothers, whom created the Motorola Company that brought consumer electronics into the vehicle, which was a fairly profound idea at the time. And that sort of mindset of seeing whats around in consumer electronics has been around for about half the life of the automobile, for about 50 or 60 years. Motorola is also trying to bring another electronics component into the automobile, namely the telephone when they created the mobile phones.
So that has come full circle and is now driving the next wave of innovation. All automobile makers are sadly with leadership in this next phase where they have smart folks, who know how to do systems and process applications with electronics. The leading folks are leaning heavily into the consumer electronics space where they know how to do this well. But I think there is only one company thats inherently set up for the next wave, which is all about software platforms. Once you get the hardware right and you create a sophisticated sandbox, and you take care of the features, the security, and the physical safety, then all the lessons from the software world come in.
What I see in talking to car companies around the world is that they are bringing in the right people and putting them in the right positions to make this happen. But when you talk to Tesla, he is a software platform guy. He built PayPal, which is inherent in many everyday transactions. So, its in his DNA and hes the guy running the entire company. Its going to be interesting to see how that plays out.
Heres a quote I like that illustrates this point. APIs make cars a software platform, not just a hardware platform. That is where the high velocity innovation is going to happen. Running a platform is like running a small town.
A lot of it is about governance and policiesvery little is about the tech. The most valuable platforms provide a large audience, plus user acquisition, or unique data. Cars have the potential to offer both. Ryan Sarver, ProductBD, Platform Team, Twitter Running a developer platform is difficult. I like to give one example, which is especially for the carmakers on the phone about why running a developer platform is so difficult.
Its about winning the hearts and minds of app developers. As soon as you talk about winning someones heart it becomes an irrational exercise. Id like to show you something that just happened recently. This is a retweet that recently happened and became very popular.
It says, Nice, we can now hack cars! – Thanks TeslaMotors! Tesla Model S REST API docs.timdorr.apiary.io This happened back in February or 2013. When it comes to getting a developer fired up about an API, why would this happen with a car API? If you look at the data of Tesla vehicles sold 4,900 in Q1 2013 verses the number of GM vehicles sold 2,360,000 in the same quarter, there is no comparison regarding the leaderGM. If you are an app developer thinking rationally about, which vehicle platform you should target to build your app, you want to pick GM.
The heart though says, zOMG Tesla has an API, because developers love the Tesla brand. This is the lesson at Apigee we give to all of our fortune 500, Global 2000 customers, is that your brand, working with the developer is just as important as your brand working with consumers. Developers decide which brand they are going to work with as well. So my point here is, OMG Tesla has an API, except they really dont.
What happened is a developer reversed engineered an API used by looking at the HTTP calls of Teslas apps. Tesla hasnt launched and API, they dont have a developer portal, or any of the things that GM and Ford have had for over a year. If you are growing a developer program, this is exactly what you want to happen. This is how you win the heart of the developer and a lot of it comes back to understanding how your brand is going to resonate with the developer community.
This takes us back to the value chain, where its important if you are going to think in terms of a platform company, you are creating two sides of a market. You are creating a side that benefits a developer and one that benefits the consumer. Its important to put the developer between the car company and the consumer. I wasnt going to include this but it came up as I was preparing for this talk. The question is what is Apigees role in the programmable world.
Heres where Apigee fits in the world of the programmable car. Starting from the top, we stress that the most important person in the value chain is the application developer. So, we have a whole set of capabilities that we call the developer channel services that allows car companies to get app developers on board using their portal and get them excited about it. If you look at the GM developer program, that is something that is powered by Apigee and runs in the automakers data center.
With that, we have something called App Services. This is something that would be used when an app developer is building an app for a Smartphone or Head Unit and they want to store the data somewhere. They can use App Services as their mobile backend as a service, and they can use this in a couple of ways. They can let the app developer choose whatever backend they want or, as a carmaker, you could private label App Services and provide that as a sanctioned way that app developers can store data in the cloud. There will be plenty of privacy regulation that the government will put in place around storing sensitive vehicle and location data from within cars.
Throughout all of this, you are making requests through to the cloud and you are making a lot of API requests through the gateway and provide analytics on that. Another part of our offering is something called Mobile Analytics, which runs on iOS and Android. As things develop and get more sophisticated with the Head Unit, many automakers are planning to choose Android as the foundation.
And will also be able to run Mobile Analytics on the Head Unit, which will allow both the app developer and the carmaker to see how the app is being used. Questions? Creative Commons Attribution-Share Alike 3.0 United States License