Go read OnStar gives Volt owners what they want: their data, in the cloud, by Sean Gallagher, in Ars Technica. It’s a VRM story. The vendor is Chevrolet, the vended product is the Volt, and the relationship management is a DIY hack by one customer. The story begins,
You probably don’t think of your car as a developer platform, but Mike Rosack did. A few days after buying his Chevy Volt, Rosack started slowly mining his driving data. But he eventually revved up his efforts and created a community platform for drivers to track their own efficiency. Today more than 1,800 Volt owners compare stats with each other, jockeying for position on Rosack’s Volt Stats leader board.
The Volt uses OnStar, a GM subsidiary known through its advertising for providing a way for drivers to call for roadside assistance; but which is actually a sophisticated cell-based data system through which cars communicate constantly with the mother ship’s cloud. While OnStar generously shares data back to customers through an app called RemoteLink, much more can be done with it, since it’s data and comes out through an API. Now here is where the story gets VRooMy:
Rosack initially wanted to do more with his own driving data than just view it on his phone. So he built what eventually became Volt Stats to capture this data, then started sharing it with other Volt owners. There was just one small problem: Volt Stats relied on Rosack’s reverse engineering of an interface for OnStar’s RemoteLink mobile application (iOS and Android). When OnStar moved to shut down the Web services interface Rosack had plugged into in mid-October, Volt Stats arrived at a screeching halt.
Rather than leaving Volt Stats stalled on the roadside, GM and OnStar accelerated efforts to give developers a new public Web API to create services on top of OnStar data. The companies even worked with Rosack to get him onboard and get Volt Stats re-launched. Now, Volt Stats is back online and other would-be car data hackers will soon be able to connect their Web applications to GM owners’ vehicle data (provided, of course, that they have privacy policies that meet with the approval of GM and OnStar lawyers).
OnStar had already developed an API for GM partners such as the car-sharing service RelayRides, who need to get access to some of the remote control and telematics elements of the service. But this new interface takes advantage of technologies such as OAuth and JAX-RS and it’s a step toward turning OnStar into a broader platform for the “Internet of things.” It’s also a way to give car enthusiasts a new kind of access to something they’ve always thought of as their own—their cars’ data.
Now come the VRM questions:
- Where and how might customers store that data? Are current PDS (personal data stores) compatible and ready for it?
- How might customers use that data — especially outside and between multiple vendors’ apps, APIs and relationship silos?
- Might we see an ⊂ (r-button) on the dashboards of car? How might that work? And if it does, how do we make it standard?
- What usage and new market-driving scenarios might we start to imagine here?
- How might customers assert their own privacy policies and terms as demand begins to drive supply?
- What other interfaces do cars have that might be brought into the picture?
- How can what happens here model what we do with the rest of the “Internet of things?”
- What are the meshy wireless things we can do among ourselves and our cars, outside any vendor’s box? (Would love Robin Chase‘s thinking here.)
These are questions especially for VRM developers. Look for answers (and more questions) here and on various blogs.
Many of the largest car manufacturers already have platforms to develop on. Alison Chaiken has done some good talks about this area.
https://lwn.net/Articles/476202/
http://www.slideshare.net/chaiken/laaos-april11-chaiken#btnNext
http://automotivelinuxsummit2012.sched.org/event/e4ce1cbe70b639098fb0934286d3d1c1#.ULONkhC-YvE
The entire article is an interesting read. I can’t tell if individual owners can access the API or only “partners”. In any event, a VRM partner could access the API in order to bring the data into the customer’s personal data store for use in other areas.
However, I find the idea of control more compelling than data. Unlocking doors, etc. is a pretty cool. I’d love to get this into a personal cloud and let people start writing apps against it.
You ask how customers might assert their own privacy policies and terms. Imagine that you have your car hooked to a personal cloud (your agent) and you take it in for service at a non-GM service center. Your cloud is now in control of the data and what gets shared with the service center.
This is the first time in a LONG time I’ve wanted to own a GM car. 🙂
-phil-
I think there are tons of ideas for what (live) car data can be used for, from more or less serious and useful analyses, to playing games with the guy in the car next to you while you’re both stuck in traffic.
Of course the right thing to do would be to wrap an XDI/KRL layer around such cars 🙂
BTW, in Austria, a high-level diplomat recently suggested in a newspaper that all cars should be equipped with 360-degree cameras in order to be to able to reconstruct accidents. I think you can imagine the reaction that followed such a proposal.
I can’t edit my earlier comment, so I’ll leave another. I wanted to add some resources for people who might want to know more about what I mean when I say “personal cloud”.
A personal cloud is more than a personal data store and more than a place to sync your addresses. A personal cloud is a virtual computer that is always running on your behalf in the cloud. Because it’s always on and running apps you install, it’s a perfect way to implement many VRM scenarios.
First, the talk I recently gave at Defrag is a good intro to our thinking around personal clouds and what they do: http://wnd.li/vWDyW1
Second, for those who want more detail, a white paper I wrote last April provides a deeper look: http://wnd.li/DCOXTr
Third, we built an entire intentcasting scenario out using personal clouds. Unfortunately, the only screencast I have of it is *very* terse. Still, it might give you an idea: http://wnd.li/bmyGHz
I hope to do a longer version of the intentcasting screencast later that gives the viewer a little time to think and take it all in. There’s a lot going on.
We’re contemplating building personal clouds for cars for a client now (as a way to record maintenance in a way that the owner of the car controls). So the Onstar API really caught my attention. Imagine if your car were talking to something you controlled instead of just sending all the data to GM. Now *you* can chose where to get the car serviced next and they have the benefit of all the data that the car has generated. That would be pretty cool.
–phil–
Thanks, Phil, Don and Markus.
Phil, not sure why you can’t edit your first comment. I see you’re coming from the same email address, so it must be a WordPress setting on this end. I’ll get on it while I’m on the train tomorrow.
I have read about a certain VRM API, I just set it up 🙂