The vision of M2M services in the connected car is both compelling and reasonably well understood. The OnStar service, launched by GM as long ago as 1996, has provided a template for communication services for both car and driver that has proven both stable and capable of extension.
The opportunity to connect cars has sometimes seemed like a match made in heaven for both telcos and automotive OEMs. But as with all fairy-tale weddings, the celebration is threatened by the presence of a bad fairy, in the shape of the smartphone. The connected car vision is supposed to be realised through the sale of new cars. But with around 9% of vehicles replaced every year, it is going to take quite a while before most cars on the road are connected.
In the meantime, there are lots of drivers sitting in lots of cars, with highly capable smartphones in their pockets. As a result, they are being used to provide services to drivers of precisely the kind that have until now been thought of as the proper province of embedded vehicle platforms.
The most striking example is navigation services. Every Android smartphone that is sold includes Google Maps, which now supports turn-by-turn navigation functionality that is at least as good as that provided on a built-in display unit (Apple and Windows devices, and Blackberries, have different map and navigation services bundled in, but the functionality is more or less equivalent).
It’s true that the user interface for built-in units is designed with in-car circumstances taken into account, so that there is less reliance on touch-screens and more use of dedicated knobs and buttons that can be used with both eyes on the road. But it’s also true that the voice search capabilities of smartphones are better than they were and it’s often an acceptable substitute.
Smartphones already support streaming media services like Spotify, Pandora, Aupeo and so on; in most cases the services were initially designed to run on these and were added to in-car platforms as part of a special arrangement.
The main roadside assistance providers offer smartphone apps which provide much of the functionality offered by the embedded platform implementations, including communicating the location of the breakdown to the assistance provider, and providing regular updates to the driver as to the progress of the assistance patrol.
There are smartphone eco-driving apps, which use measurements from the phone’s accelerometers, cross-referenced with time-stamped GPS readings, to provide a driving score based on hard braking, cornering and accelerating, plus compliance with speed limits and other road restrictions.
A similar approach allows smartphones to be support Usage Based Insurance (UBI). The cost of products based on ‘black boxes’ has been prohibitive, which has meant that UBI has been restricted to the highest risk drivers (mainly new young drivers), who graduate on to mainstream insurance products in a few years. Now, though, there are UBI services based entirely on smartphone-calculated driving scores, which are cheaper to provide and thus can serve the mass market of drivers. There are also hybrid models emerging, such as the DropTag product developed by Cambridge Consultants, which combines measurements collected by a low-cost screen-mounted device with a smartphone app and a cloud platform.
Smartphones have also been deployed in the role of an Advanced Driver Assistance System (ADAS). For the most part these are based on front-facing cameras and LIDAR systems connected to the car’s on board computer; but the iOnRoad application now offered as a free download by auto-electronics specialist Harman shows that the camera on a dashboard-mounted smartphone is capable of delivering a comparable level of functionality, including collision detection warnings and lane departure notification. A similar solution is offered by Israeli start-up I4Drive.
The relationship between applications delivered via embedded platform and those delivered via a smartphone is not only adversarial. The huge efforts going into Android Auto, Apple’s CarPlay, and MirrorLink, are premised on a paradigm whereby the vehicle’s head unit becomes a ‘dumb interface’ to applications, content and services delivered via the smartphone and its associated cloud platforms like the Apple Store and the Google Play Store.
And of course there are some applications that won’t ever be provided by smartphones. Stolen vehicle tracking absolutely requires that some sort of device is fixed into the vehicle. Remote diagnostics of engine and other sub-systems requires access to data from the car of the kind typically provided either by the CAN bus or, as a minimum, by the OBD2 diagnostic port. The levels of security around these data flows are unlike anything with which smartphone application developers are likely to be familiar. Messing about with this information could trash the car’s internal systems or even cause it to crash. No automotive OEM is likely to allow direct access over the internet to this any time soon.
In conclusion, the paradigm for connected car services is shifting and becoming more multivariate. Ten years from now most cars on the road will have an embedded, connected computer on board. In the meantime, though, there will be other ways of providing connected services, and some of these will become sufficiently well-established as to be hard to displace.
