Developing connected vehicles requires a two-pronged technology strategy. First, you have to master the integration of apps, devices, data and APIs to suit the connective services of the next few years. Second, you have to clear a path for the evolution of automation.
To make this happen, OEMs must develop user-centered connected-vehicle architectures that orchestrate:
- People — employees, customers and vendors
- Technologies — devices, applications and services
- Content — infotainment, navigation and commerce
You can’t just wave a baton and bring all these elements into harmony, of course. But the right kind of system architecture can provide the framework to meet the challenge
Addressing Near-Term Demands
In the short term, you have to integrate internal, in-vehicle and external technologies and services to meet the demands of today’s connected drivers. This table is a snapshot of all the sources that must share data effectively to guarantee safe and enjoyable connected driving experiences:
|manufacturing, R&D, marketing, sales, warranty, dealers||infotainment, telematics, user authentication, commerce||development partners, service providers, mobile apps, devices|
A robust system architecture is like an ecosystem that keeps everything in balance. Information from the vehicle flows into the enterprise, enabling services like predictive maintenance and sales projections. Data and services from third parties flow into the car, keeping the driver current on changing traffic patterns, parking access and nearby hospitality services.
Eventually, advances in data science and artificial intelligence will bring more automation to these technologies. Even if we never see fully autonomous vehicles on our streets and highways, connected vehicles will be increasingly complex mobile computing platforms.
Eliminating the Point-to-Point Integration
Today, the bane of connected-vehicle development is the point-to-point integration. It works like this: A telematics or infotainment provider connects directly into an in-vehicle network. In an ideal world, the provider’s open API stack connects to a multitude of connected-vehicle services without a hitch.
In the real world, OEMs manage a tangle of technologies, some of which may be decades old. These kinds of apps are not always well-suited to the API-powered age we live in today.
Moreover, the point-to-point integration represents a chokepoint in the system architecture. Any failure in the third-party provider’s API could shut down a host of connected services.
To avoid these chokepoints and keep using legacy technologies, you need an orchestration layer in your system architecture. You also need to maintain ownership of your APIs rather than farm them out to third parties.
The goal: Building an architecture that makes it easy to provision new services that arrive on the marketplace and deprovision services that suffer system crashes or become obsolete.
Keeping an Eye on the Long Horizon
A year ago, DMI developed CATE (Connected Autonomous Transportation Ecosystem) to provide a framework for the future of connected-vehicle development. Since then, the heady optimism about the potential of self-driving vehicles has given way to sobering questions, among them:
- Who is liable when an autonomous vehicle crashes?
- Will fully autonomous vehicles encourage overuse of highways and streets?
- Can computers, sensors and networks ever get smart enough to automate all the cognitive processes people use while driving?
No matter how our society addresses these kinds of questions, the march of automation will go on. New tools and services will enable ever-richer driving experiences. An open system architecture with a well-thought-out orchestration layer will give OEMs the best chance of adapting to this evolving ecosystem.
— Brian Drury, director connected-vehicle practice