Value-Added Services

Apart from the core vehicle functions already discussed, additional value-added services are also playing an important role in shaping the evolution of the connected vehicle. In the following section, we will discuss these services and also look at the various forms this generic platform is likely to take.

eCall

eCall is an EU initiative aimed at leveraging vehicle connectivity in order to shorten the time required to direct emergency services to the scene of an accident. According to some estimates, eCall services could shorten emergency response times by 40 per cent in urban areas and 50 per cent in rural areas [EC1], potentially saving 2,500 lives a year [EC2].

Using various sensor inputs, from embedded acceleration sensors as well as devices such as airbags and belt tensioners (connected via the local CAN bus), eCall can detect potential crashes before they occur. It interacts with the backend using a combination of data and voice services. In the event of a crash, the GPS position and vehicle ID (VID) are transmitted to the backend via data service. The voice service is activated automatically to initiate interaction with the passengers. As Tim Kornherr, Head of Mobility Services for Automotive at Bosch, explains: “For our customers, it is important that they can talk to an agent in their native language – particularly in a stressful situation like an accident. This has to happen regardless of the country they are traveling in. Our eCall solution has access to the driver’s language preferences and can thus route incoming distress calls to a call center agent with the right language skills.”

Following an assessment of the situation – determined based on feedback from the passengers via the voice service, or the lack thereof in the event that the passengers are unconscious, the system will inform the relevant emergency services. In the EU, this is managed through a PSAP (Public-Safety Answering Point). PSAPs are municipal call centers that handle local emergency calls and are capable of notifying and directing emergency services.

The figure below shows the Asset Integration Architecture for an eCall system. Note that the first line of communication (data and voice receivers) generally depends on telecom carrier interfaces and can be provided either by the OEM or by the eCall platform operator.

The introduction of eCall as a mandatory service within the EU has had to be postponed numerous times. Commenting on the reasons for this delay, Dr. Christoph Schillo, Peiker’s Head of Product Strategy explains: “In our opinion, the main reason for this delay is that the complexity of the eCall service was underestimated. The eCall service requires technical standardization and legislative rules for a significant number of systems and interfaces, including on-board hardware, telecom carrier services, call center services, and PSAPs. And all of this applies across multiple countries in the EU. National interests play an important role too. For example, France and the UK already had their own eCall systems. By the way, the French system is based on SMS text messages – good luck if you have an accident on New Year’s Eve! Also, some carriers didn’t see a business model in it for themselves. So what happened was that a number of OEMs such as BMW and Mercedes went ahead and simply defined their own systems. Mercedes started their rollout in 2012 with 9 countries, adding 10 more in 2013. This was only possible because these OEMs were able to manage the entire project themselves, or find the right partners for the required sub-systems.”

The EU has now finally agreed that the eCall system will be mandatory for all new vehicles sold in the EU from 2018 onwards [EC2].

bCall

An interesting variation of the eCall service is the bCall breakdown service. When a vehicle breakdown occurs, the driver is usually required to press a button to manually activate this service and be connected through to a call center.

Advanced versions of the bCall service don’t just transmit basic data like vehicle ID and position, they also allow the call center agent to access real-time diagnostics data in the car. This is done using an on-board component of the bCall service that accesses the required data via an ODB II or similar interface [OB1]. Armed with this information, the call center’s first-level support team can make a better initial assessment of the situation and decide on the next steps to be taken. For example, they may decide to send a service car with the right spare parts to the site of the breakdown.

Stolen Vehicle Recovery

Another interesting development in the area of connected vehicle services relates to recovery systems for stolen vehicles such as those provided by LoJack, Tracker, and OnStar.

These systems often use a small radio transceiver that is hidden within the car. The location of this transceiver is usually different for every car, in order to prevent it from being found easily by a potential hijacker. Once installed, the tracker ID and vehicle ID (VIN) are registered in a tracking system, together with additional information such as the vehicle make and model, license plate, and color. The car-tracking system can also integrate with the IT systems of law enforcement agencies, such as the NCIC (National Crime Information Center) system in the US. In the event of theft, the vehicle owner reports the incident and the tracking system activates the tracking device, which will send out a signal to help locate the stolen vehicle.

Usage-Based Insurance

The last value-added service for connected vehicles that we will look at is usage-based insurance (UBI), also known as “Pay-as-you-drive” or “Pay-how-you-drive” schemes. The basic idea is that insurance companies get access to driving performance data, and in return offer customers insurance policies based on car usage (time), distance covered, areas visited, and driving behavior.

Conventional car insurance premiums are calculated using demographic metrics and are therefore not individualized. UBI is promising to change this. Current driving behavior is tracked using devices installed in the vehicle to capture behaviors, such as how far and how fast they drive, how often they brake hard or swerve, driving patterns like night driving/weekend driving, etc. Along with the conventional demographic metric, this data is then used to create a unique risk profile for each driver, which in turn forms the basis for calculating a customized premium for each insured driver. According to some studies, annual UBI premiums for “good drivers” can be up to 30% lower than with conventional policies [LN1].

For the highly competitive car insurance sector, UBI has the potential to become a market-changing differentiator for a number of different reasons:

• Lower premiums incentivize potential converts, particularly better drivers
• Drivers are incentivized to drive safely in order to keep their premiums low
• The degree of risk covered by the insurer is reduced
• Claims should be lower, increasing profitability for the insurer

Many insurance companies have started to add UBI offerings to their portfolio. In the US, for example, Progressive, Allstate, State Farm, Travelers, Esurance, the Hartford, Safeco, and GMAC have all opted for this route [UBI1].

For several reasons – not least privacy and general availability issues – uptake on the consumer side was slow initially. However, this now seems to be changing. According to research firm Towers Watson, 8.5 per cent of US drivers held a UBI policy as of July 2014, up from 4.5 percent in February 2013 [UBI2].

To support UBI on a large scale, specialized UBI management systems are required. One provider of such a solution is Tech Mahindra. The Tech Mahindra solution consists of three main components: The UBI vehicle tracking device, the connectivity & device manager, and the UBI insurance application. The Asset Integration Architecture (AIA) for the Tech Mahindra UBI solution is shown below.

The UBI vehicle tracking device is installed in the customer’s car. It connects to the car’s controls via a standard OBD II adapter [OBD1]. Through this interface, the device can read data such as engine RPM, vehicle speed, positional information (latitude, longitude & altitude), date, time, battery voltage, and engine parameters. It can also read data relating to driving events such as hard cornering, hard breaking, and aggressive acceleration which, from a UBI perspective, is particularly interesting. The GPRS/GSM modem within the device transfers the data to the backend. The OBD data is augmented with positional data acquired through the GPS receiver before being sent to the server.

The M2M application consists of two main components – the device management module and the UBI business application. The device management module manages device activation and connectivity. The devices themselves can be configured remotely through a web application or SMS interface.

The backend UBI application leverages this basic vehicle data and a Hadoop cluster is used to manage the large amounts of incoming vehicle data. The application provides business functionality such as user management, event management, advanced analytics, and driver score card features. The event-management module manages incoming notifications from the vehicle and can also initiate responses. Communication with users is handled through SMS and email-based notifications.  Advanced analytics like moving averages for hard breaking, cornering, acceleration, speeding, average speed by location, and driver score card trend analysis are useful for insurance companies. The application is also integrated with public data sources (to provide real-time contextual information) and backend systems such as a GIS system and the insurance companies’ existing record and claim management systems.

Data aggregation plays an important role in calculating UBI tariffs and managing contracts. The figure below provides an overview of the data aggregation model designed by Tech Mahindra. This model allows insurers to aggregate driver data in a structured way and use it to dynamically calculate a driver’s insurance tariffs.

For many, the basic value proposition of UBI sounds interesting, at least at first glance. It’s little wonder that UBI was picked out as an early poster child for M2M/IoT business cases. As with many innovations, uptake has been slower than anticipated. However, based on some of the research out there, it appears that UBI is finally gaining traction as a viable insurance model [LN1].

So, Why No Open Car App Platform (Yet)?

When you look at the examples of value-added car services previously discussed – from eCall to UBI – one question arises: Why is the development of value-added services so complex? It is complex because each solution provider has to install their own hardware in the car, establish their own telecommunications link to the backend, and implement their own data collection and event management systems in the backend before they can even begin to develop a single line of business logic!

The massive innovation potential of an open (or at least semi-open) app ecosystem has already been validated by smartphone players like Apple, Samsung, and Google. Most major app stores now feature tens of thousands of applications, many of which leverage sensors embedded in modern smartphones via controlled APIs offered by the smartphone OS.

Granted, if a smartphone app malfunctions or breaks the sandbox mechanisms used by the smartphone OS to secure the system, the worst that can happen is that the phone stops working or uses up more bandwidth than it’s supposed to. A malfunctioning car app could actually endanger lives, which is a much bigger risk to take.

As we have already seen in our dashboard discussion, there are a number of ongoing initiatives aimed at combining smartphone apps with car infotainment systems. However, most of these initiatives focus on infotainment only, and do not look at achieving deeper levels of integration, as provided by the app link approach described above. Yet, apps such as UBI and eCall will require deeper integration with core car functionality, even if just at a read-only level. More advanced systems such as the Digital Horizon system, discussed below, will require actual write access to the car’s controls in order to function most efficiently. For OEMs, the act of handing over control to an external application understandably carries a huge risk, which is why most OEMs still require intensive and lengthy certification processes before allowing new applications into their car ecosystems.

Nevertheless, in order to generate the type of exponential growth seen in smartphone app ecosystems, OEMs will have to be much more open about how external applications can access core car functions.

Perhaps the first step in creating such an open car app ecosystem should focus less on what’s inside the car, and more on what’s outside the car, i.e. in the cloud.

Many car-related application services don’t actually require an execution environment within the car itself. Take our eCall and UBI examples. Both could be easily built on a cloud-based application platform that provides access to the data they need. For these types of applications, there is little value-add to be gained from being directly embedded in the car, or from having to deal with backend car data management systems. A cloud-based, open car application platform with an efficient subscription mechanism for accessing car data would be fully sufficient here.

It will be interesting to see what this corner of the IoT will deliver in the coming decade. There are exciting times ahead!