8 Comments

API (on)Star in vehicle mobility

API

Web 2.0 has a great creative history of  acronyms, pseudonyms and synonyms used to provide a greater insight into the processes of the semantic web. Among these lists, the acronym API stands out as one of the most valuable assets to the web, but goes unheard by a standard internet user. API – an Application Programming Interface, is a platform used by an application program to communicate and facilitate with other similar applications or programs. The web as we know has evolved from, links connecting one site to another to sites connecting through data and functionality embedded in API’s.

The dynamic growth of API’s since 2000 has allowed various web applications to create value simply by assembling them in a novel or effective way or as Tim O’reily defines it “Innovation in Assembly“. This creative assembly to increase the value of a service is much more common these days with integrating different applications and services. The basic idea behind this integration is known as ‘mashups’ where services or applications can be ‘mashed-up’ to improve the quality of the service, hence innovation in assembly.

OnStar Corporation

One of the most recent web applications to build an API to its business model, is OnStar Corporation which is a subsidiary of General Motors. OnStar is a subscription based vehicle communication system which also provides in-car security, navigation and remote vehicle diagnostics.

OnStar has been monitoring the mobile web traffic and trends quite closely to understand the use of mobile apps  in vehicle mobility. It was concluded that the number of mobile application will double by 2013, hence the need for an API to improve the value of the application service was highlighted. Consequently, OnStar announced its OnStar API for the creation of vehicle specific and vehicle safe apps for OnStar equipped vehicles.

OnStar is giving selected app developers access to its API for OnStar products and vehicles.
(Credit: OnStar/GM)
Read more

According to the CIO at OnStar, one of the major reasons to release an API to partner applications is to keep their customers connected to the business model in ways beyond their imagination. This platform would allow OnStar to build customer trust and loyalty, creating a vast community. The OnStar API would also help the corporation to understand  customer use and the remix of data services surrounding the applications for vehicle use. Two of the most popular partner applications to develop from the OnStar API are RelayRides and RemoteLink.

RelayRides

RelayRides is the first in line to develop an app that takes advantage of the newly opened API.
(Credit: OnStar/GM) Read more

RelayRides is a peer-to-peer car sharing (renting) service that allows vehicle owners to rent out their vehicles to anyone. RelayRides will utilize OnStar’s location awareness, navigation, in-car security systems and other remote features through the API. The OnStar API’s supporting platform will allow those renting vehicles through the RelayRides app to remotely lock and unlock the vehicle after the rental.

RemoteLink

OnStar Remote link allow users to view real time data such as mileage, fuel in the gas tank, oil life and tire pressure of their vehicle, without being physically present. This creative, outside the box thinking has allowed OnStar to utilize it’s wireless services to control and manipulate vehicle data in new and innovative ways.

OnStar desires to further implement the innovation in assembly and provide advance services such as:

  • Automatic Crash Response
  • Stolen Vehicle Tracking
  • Advance Navigation
  • Roadside Assistance

The web has become an intermixed and a complex service provider to its users over the years, increasing the demand for API’s. Big organisations such as Google, Facebook and Twitter have developed more advanced API’s to harness the functionalities of multiple applications together. Although API’s consist of different features and functionality, it is fairly common for developers and business management to evolve business applications into lucrative business services. Consequently, more companies are implementing innovation in assembly to integrate the competition rather than competing with each other.

References

About these ads

8 comments on “API (on)Star in vehicle mobility

  1. Hi Hasitha,
    Really quality stuff!

    It’s a good thing that there appears to be a real emphasis on safety and more to the point, the examples you quoted were applications that one would use before and after, rather than during the act of driving.

    My initial reaction to the ‘RelayRides’ app was ‘Who would let a stranger use their car like that?’ but then again when I think about it, if you don’t like the idea of renting out your car to strangers, it’s probably just not for you (or your car is shiny and expensive).

    I guess if you want to make a few dollars, and trust the system will always work, then it might be a good way to make some money, but I wonder about how much of an investment it would be until you started making some real money (although, given the nature of open APIs, companies like OnStar will leave that up to the public to figure out).

    Leaving a car to the mercy of anybody with a smart phone seems like it could be exploited somehow, but then again, just leaving a car on the street is inviting to a thief as well. Is there anything stopping someone from stealing a few details, walking up to one of these cars, renting it and disabling the on-board computer/gadgetry/magic?

    Time will tell whether it’ll work out or not. I seem to remember quite a similar service wherein people can rent out sleeping space in their homes.

    What are your thoughts about the potential disbenefits Hasitha? I imagine that OnStar have thought about it a lot.

    Cheers,

    Anthony Smith
    http://anthonysmith4it.wordpress.com

    • Yeah I think, RelayRides would be a controversial app that would have its on niche market and audience. I think it would definitely work better in the US market because of the market patterns and demand, as oppose to Australian standards of ownership of vehicles. These two apps works perfectly as examples of innovation in assembly as OnStar continually desire to improve its value of the service beyond its capabilities.

      I think as you said, one of the drawbacks of the RelayRides app would be as you said potential theft. But then again wouldn’t it be as much as easier for someone to break into a car and steal it? The only thing stopping someone stealing a vehicle with a OnStar is that they have to be quite familiar with the technology to tamper with it as any tampering would trigger security alarms.

      I did look into some drawbacks on this technology OnStar API services use. But it is yet unclear of some legal liabilities as there are no clear legislation on P2P vehicle sharing. On the other hand, as with any new technology there is going to be cases of hardware malfunctions and mishaps. Also I’d assume maintenance of OnStar hardware would be rather expensive for a low-income user.

  2. Very very detailed blog Hasitha.

    I have believe that Anthony has a very valid point. The following website has a very interesting points in relation to the risks of applications like RelayRides.

    http://www.caranddriver.com/features/can-your-car-be-hacked-feature

    Also as far as OnStar is concerned, I know that there was a heavy movement on the web of different people trying to gain access to the closed system.

    http://hackaday.com/2010/03/16/follow-up-hacking-onstar/

    Is one such website where hackers congregated to try and abuse the OnStar System.

    • Great links you’ve posted there Colin. It is pretty scary to see that how easy it is for a hacker to get in your car. But I think as it says in the article, just like the early days of web development, car networks haven’t really employed advanced security. But overtime you’ll be able to see some complex security systems for in-vehicle information systems.

      With regards to OnStar API, it is a closed API as of yet; where only exclusive programmers and developers will have access to it. I think that’s a main security strategy OnStar has adopted currently to keep the hackers out of the OnStar systems. Although Closed API’s sound limiting in theory, it allows you to maintain control over your data and resources. You can probably read more information about Closed and Open API’s here > http://www.apievangelist.com/2011/06/01/open-vs-closed-apis/

      • They’re all fair points, and I think it’s a good thing that hackers are openly trying to abuse the system in order to inspire OnStar to improve security. Another form of Crowdsourcing in a way.

        A closed API makes sense at the moment for a product that comes from a subsidiary of GM. They aren’t necessarily a Social Media Startup enterprise – they’re a car electronics company – utilising an open API to draw in customers isn’t traditionally their plan. The thing that holds it back is that it is a niche market at the moment. Moreover, IP is valuable to them and they don’t want hackers stealing it, let alone using it to steal cars. Baby steps should be expected.

        And it is as you say, it’s early days. There’s little security, but there’s probably a smaller minority willing to try and exploit it to try and steal a car, when they could just as easily steal any other car.

        On the other hand, somebody needs to make that first step. OnStar seem to be well on their way to pushing something like RelayRides into the mainstream.

        Cheers,

        Anthony Smith
        http://anthonysmith4it.wordpress.com

  3. Interesting information, and has definitely stirred up some conversation.

    The other consideration is that, are we having information overload? Because information can be gathered, combined and presented thanks to these API’s are we simply missing the point of why we are wanting to use particular content? Let’s use Facebook for example.

    Most major sites you go to now have some form of Facebook integration thanks to the API’s made available, allowing us to make comments and see what our friends are viewing on the site. That might be fantastic to see, however I think it sometimes distracts us from the point and the information which we went there get consume.

    • I think web services are walking on a fine line between proper data visualization and data overload. Then again I think the objectives of API’s have changed and have become more sales/market oriented for some API services. It is changing into a form of online advertising and targeting audiences for a specific service.

      As with the example you mentioned, most sites utilize facebook API’s to increase their network, hence increasing revenue. Just as any other form of advertising, it provides a consumer with a variety of options in either buying or networking. This so called ‘distraction’ is enticing consumers to try/use something else, just because their friends have used/tried it. And then we come circling around the web pattern that it is innovation in assembly, whereby a value of a service is increased by mashup/integration of other web applications.

      • The Facebook integration works fantastic, because like we’ve said it shows what your friends are doing or buying. As such we don’t want to be seen not joining the latest trend or being behind on what our friends have if it was fashion for example. You could call it ‘digital peer pressure’.

        Facebook itself doesn’t generate revenue for pages (I believe), however the value for the business is the interaction and being able to have that network to show.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: