Vehicles as smart mobile devices

Building adaptive ecosystems of connected things

Any picture of a "true connected car system" that works seamlessly is, by definition, incomplete. Much as a computer can accommodate a programmer's chosen software language and development process, so connected vehicles must be designed to adapt to changing consumer desire and incorporate their content, applications and services. An initial challenge is to consider the connected vehicle as a platform for content and service delivery, rather than a branded expression of content or application determinism.

The connected vehicle must chart a path similar to progressive consumer electronics technologies, in that the vehicle can be adapted to the driver's desire for his/her specific content, applications and services. Original equipment manufacturers (OEMs) relying on designer-selected content, applications or services are likely to find limited consumer satisfaction. Consumer content, applications and services are increasingly hyper-personalized expressions of one's digital self. Building a vehicle that can be customized to the individual, yet still perform within a given set of safety and usability parameters, is no simple task.

For the sake of argument, our baseline is an internal combustion engine vehicle platform that is currently planned for market introduction by 2015. This vehicle platform will span geographic and cultural markets and be used across several brands and models -- and target multiple market segments, including luxury, mid-market and value. At a high level, the vehicle platform must be localized to the driver and market, integrate the driver's smart device, apps and content, integrate driver's cloud-based services, and be governed by the OEM. This last item is significant: If the OEM enables distracting content and services within the vehicle, then the OEM has a responsibility to ensure driver and passenger safety while enabling service consumption.

The ecosystem to design and deliver this infotainment experience contains several key players. The OEM maintains design authority over all aspects of the hardware and software platforms and the services portfolio. The head unit supplier will be invaluable to the solution, and will likely be a top-tier supplier for the program. On a program like this there are likely to be several head unit suppliers, with components targeting specific markets, models and uses. Each head unit supplier has its own technical team that determines the hardware and software elements of the head unit: memory needs, drive space, operating system, virtual machines, etc. These ecosystem participants -- head unit supplier and operating system -- are hugely influential in enabling a successful program, as they create the art of the possible. Approximately five to eight different head units from three different suppliers, each with its own service capabilities, is a typical estimate.

For each market and segment, the OEM is likely to have ideas about content or service elements within the overall brand value proposition. OEM-selected partners each need to be integrated into the service delivery framework. Assuming three to five service partners per market and segment and modest overlap, that's 15-45 different content and service providers that must be incorporated within the service delivery framework.

Within each market and segment, leading market research firms forecast consumer top preferences for content, apps and services. The 40 or so most popular relevant applications and services would need to be incorporated into the infotainment experience in order to satisfy a broad demand set and maintain brand positioning against distracted driving. Since there will be variations across geographies and markets, as well as across different handsets and operating systems, this adds nearly 100 different vendors to the service mix.

OEMs have differing perspectives on whether the connectivity would be built-in or brought-in, or both. Let's assume that connectivity for OEM-specific services, such as vehicle diagnostics and driver behavior, is built-in by the OEM. Several reasons exist why a hybrid approach of built-in connectivity makes sense, including removing the concept of vehicle connection to OEM infrastructure through a brought-in data connection as a "tethered" connection, which increases consumer cost. A mobile provider for the OEM connection in each geography adds complexity to the design. Moreover, many of the mobile operators have a strategy of positioning their application store for OEM use, which is yet additional connectivity complexity.

Maintaining a one-to-any connection from the vehicle without a middleware layer, sometimes called a service enablement layer or a service delivery layer, is technically challenging -- so one or more vendors must also be included. An open, flexible and extensible middleware layer is required to govern a program of this scope and scale. From this middleware layer, the OEM can monitor and control connections to/from the vehicle and performance of services within the vehicle. Good service management reasons exist for this layer as well, because the middle layer can see in each direction (to/from car, to/from service entity) and provides monitoring and management capabilities that expedite accurate service troubleshooting. The middleware layer also enables the OEM to future-proof the service proposition, maintaining concurrency with both fickle consumers and dynamic developers.

Lastly, add to this ecosystem the number of OEM resources and groups necessary, both in central groups, who are likely to determine architecture and some services, and in the regions where services targeting specific market segments might be determined. In some cases, the OEM will have external development partners, such as system integrators, adding additional participants to the ecosystem. For simplicity's sake, let's assume the OEM has the infrastructure for comprehensive CRM. In reality, though, this would be handled by several of the ecosystem participants, with one having design and experience leadership.

The dominant reason behind a vehicle platform is to share component costs as widely as possible. Incorporating services that address specific geographic or cultural market requirements adds marginal costs to the overall program, but is invaluable to the consumer market the OEM hopes to reach.

This picture creates an ecosystem, however complex, that enables the OEM to cost-efficiently address the widest possible market while maintaining a high degree of market customization per vehicle line, type or segment. The optimal connected vehicle ecosystem is one that can be abstracted from the hardware and software platforms, to whatever extent possible. This enables an OEM to identify market attributes and tendencies that, when positioned as service adjuncts to a transportation purchase, create a winning impression on the consumer and enhance the brand.

About Airbiquity
Airbiquity is at the forefront of change in the automotive industry, integrating advances in software, communications technology and wireless services with vehicles. Its connected vehicle solutions offer automakers a flexible platform for delivering innovative applications and services that help automobiles adapt to the driver's digital lifestyle.

ArticleTools