The impact of connected vehicle initiatives on the automotive industry can’t be overstated. A KPMG survey of auto executives found that 85% of executives agreed that the digital ecosystem of connected vehicles will generate higher revenues than the hardware of the car itself. To establish a leadership position in this fundamentally new market, car makers and those who provide supporting services need to understand the opportunities that exist, the challenges they face, and how to overcome them.
In this piece I’ll explain all three, starting with the fundamental building blocks, or steps along the path, on which custom value can be built.
The three kinds of information connected vehicles create and consume
Before looking at the ways to build connected vehicle value, let’s look at three kinds of information connected vehicles generate and consume.
- Drive data. Connected vehicle systems can generate helpful information about not only the location and speed of the vehicle, but also the position of the accelerator, brake pedal, steering wheel, and turn signals, along with streaming data about fuel consumption, for example.
- Diagnostics data. This includes periodic measurements taken to ascertain things like the battery charge status, fluid levels, and tire pressure, along with pressure and temperature readings from the engine, transmission and other systems.
- Instructional data. This kind of information in connected vehicle scenarios flows the other way. The ability to send commands that affect the behavior of vehicles, such as remotely locking or unlocking the car, changing the color of LEDs, or displaying a vehicle-specific alert, offers tremendous value.
Building blocks of connected vehicle value
Now let’s look at how you can leverage those three kinds of information to build value for drivers.
The first building block of potential value in connected vehicle initiatives is offline, after-the-fact analytics and reporting. By that I mean collecting data from vehicles not in real-time from anywhere, but when they are parked at home, for example. The goal of such services is to look at everything that happened to the connected car, what was done about it, and what actions might have led to a better outcome.
The next level of value is achieved when you can implement real-time monitoring and interactions. By that I mean getting a real-time view of what’s happening with a given vehicle, and having the ability to improve outcomes this time by remotely controlling some aspect of the vehicle’s operation and/or alerting a 3rd party of a situation, such as a flat tire, in which a driver may need assistance.
The third step is to move beyond mere monitoring and into the realm of event-driven alerting and even the ability to predict problems before they occur. The power to predict and proactively address component degradation or failures before they affect the efficiency or operation of the vehicle gives vehicle makers a powerful way to keep customers happy. An example could be the prediction of a component failure within the next 100 miles, which triggers pro-active communication and assistance to replace/repair said component.
The fourth building block of connected vehicle value lies in the ability to federate information and events across an ecosystem of companies that provide services in areas such as entertainment, navigation, maintenance, breakdown assistance, insurance and more.
Creating the value framework
As with any transformational and innovation project, connected vehicle initiatives demand that you create a strategic roadmap that defines what will be done by which department to what end. In this case, a roadmap for the requisite cooperation between the hardware and software engineering teams working on the vehicle itself, the digital services division, the IT divisions delivering the applications, and the production and post-sales divisions.
This roadmap should clearly communicate the vision and strategy, the phases of the project, and the approach and goal of each phase. It’s equally important to understand where the value is generated in the journey of building a connected vehicle platform. The following figure shows such a value framework, combining value creation phases with business services and underlying IT building blocks.
This Connected Vehicle Initiative Value Framework example combines the four levels described earlier with increasing value delivered from left to right. Note also that as soon as the level Interactive is reached, information flow must become real-time and the vehicle must always be connected.
To augment our understanding of the various phases further, let me offer a set of simple questions each phase is trying to address:
- Reactive: what happened and what can we do better next time?
- Interactive: how can I remotely control the operations of a vehicle?
- Predictive & Proactive: what is happening right now and what may happen next?
- Federated: how can I federate data and events across the ecosystem to create the best possible outcomes for the vehicle owner/driver?
Overcoming infrastructure challenges
Connected vehicle initiatives present considerable challenges. You’re dealing with massive numbers of complex machines being operated at high speed and in close quarters by drivers of varying skill levels, on roadways of varying quality, and in all kinds of weather conditions.
Putting in place an infrastructure that can handle the efficient, event-driven, real-time data distribution it takes to add connected vehicle value to that chaos isn’t easy, but it is possible.
Vehicle
First, let’s look at the vehicle itself. The most obvious challenge is the number of cars you’ll want to connect, usually measured in the millions. The second challenge, then, is that many interactions with connected vehicles require low latency. If somebody tries to unlock their car door with the app on their phone, for example, their patience will be measured in seconds.
Complicating the need to connect many vehicles with low latency is the fact that because cars are frequently on the move, they experience varying levels of connectivity – including periods of complete disconnection. Your job is twofold: manage connections in such a way that you can a) send and receive low-latency communications to and from vehicles whenever possible, and b) deal with slow connections and disconnectedness in a way that ensures the eventual delivery of critical data, alerts and instructions.
The final challenge at the vehicle end of the equation is security. I’m not just talking about the security of the vehicle itself, but your ability to ensure the security and safety of drivers and passengers. This entails collecting and acting on important events in a timely manner, and making sure information about the location and operation of every vehicle is kept private. A fine-grained trust framework must be established for each type of information, and the owner of that data must have full control over the sharing of said data to ensure only authorized parties can see and process it.
Regional edge network
I refer to the network of edge nodes that vehicles connect to as a regional edge network. These edge nodes are geographically distributed and are placed as close as possible to the actual vehicles to minimize latency and connectivity issues. Each node manages a certain number of connections and aggregates connections within a region. A region could be U.S. Northeast, southern Germany, etc. These nodes aggregate connections and messages from a subset of the global vehicle fleet and are responsible for routing events, data and instructions to and from the IT applications and individual vehicles.
It’s essential that these nodes can handle millions of concurrent connections and the volume of messages that entails, and deal with the recurring connect and disconnect behavior caused by the mobile networks’ availability.
Let’s imagine a tunnel – vehicles lose connectivity when they enter the tunnel, and must instantly reconnect when they emerge. When you think about all the vehicles entering and exiting each tunnel, and the number of tunnels, this alone generates a lot of disconnect/reconnect behavior.
Application platforms
In a globally connected vehicle system, applications and services may be deployed within the edge network, datacenters and any number of public clouds. The regional edge nodes now need to be wired up to be able to distribute data and events to each of these applications, wherever they are deployed.
In my experience, as the platform evolves and value is created through its phases, applications are added, removed, duplicated and re-deployed as and where the need for efficiency and latency requires it. Hence, these wirings from edge nodes to applications must be able to handle the aggregation of potentially all messages and events from all vehicles, and do so dynamically – i.e., automatically routing data to wherever there is a consumer without the need to re-wire the entire infrastructure.
So the routing challenges move from individual vehicles to the ability to aggregate massive numbers of events and data, and route them globally to distributed applications deployed across hybrid cloud infrastructure that includes public cloud, private cloud and on-premises environments.
Ecosystem edge network
To achieve the highest level of value creation, the platform must also federate data and events across a network of service providers. This ecosystem is, by its nature, heterogeneous from a deployment model and technology perspective, which means it must support diverse APIs and protocols and integration with established SaaS providers. This introduces the need for edge nodes that are seamlessly interconnected to the application services regardless of deployment location.
However, this is not the main challenge. Our goal is to create value for the owner and driver of the vehicles, and this can only be achieved by creating a trust framework that balances the need to a) share data with complete transparency and b) respect individual privacy. Without a verifiable and auditable data flow combined with a detailed consent framework, trust cannot be established.
From a technology perspective, this requires the infrastructure to handle identities of not only vehicles, organizations, and individuals but also of data items. And access to each data item must be managed and controlled at scale – including granting of access as well as revoking of access, and reporting thereof. Of course, metering and billing records complement data federation to monetize external service provisions.
A great example of the complexity of data sharing is the ‘delivery to the trunk’ scenario. Here, a consumer chooses their car as the delivery address for their purchases. This implies a very tight control & access framework across the entire value chain of the process: the e-commerce company shares the car information with the delivery company that, in turn, shares it with the delivery driver. However, the driver may only have access to open the trunk when a) they are close to the car, e.g., within a geo-fence of 10m, and b) within the specified delivery time range. Access control here is dynamic, where authorization by the owner of the car is given only under certain ‘situational’ conditions.
The following figure summarizes the four swim lanes, the different requirements in each, and the need for end-to-end routing:
Developing valuable connected vehicle solutions
There are two key elements to developing connected vehicle solutions. The first is bridging the gap between the world of applications and the world of automobiles, i.e., building bridges between the two environments so information and events can flow seamlessly between vehicles and the applications and cloud services they increasingly rely on for connected vehicles services.
The second is putting in place the data distribution infrastructure that leverages that integration to efficiently route massive amounts of information to and from connected vehicles. Let’s take a closer look at each of these requirements.
Integrating the application and automotive landscapes
Connected vehicle programs need to integrate many components and layers ranging from the enterprise IT landscape to the IoT-based world of connected vehicles themselves. This includes the following kinds of systems, sensors and devices:
- Business applications: maintenance, fleet management, insurance, maps
- Integration: APIs and protocols, streaming APIs
- Data infrastructure: reference data, time series data, streaming analytics, machine learning, location services
- Management infrastructure: remote management, security and access, ID/entitlements, privacy
- Connected vehicles: cars, buses, trucks, trains
Meeting the data distribution needs of connected vehicle programs
The data distribution infrastructure for large-scale connected vehicle deployments needs to meet the following four requirements:
- It must be a flexible, self-learning system that intelligently routes information along the network path to ensure prompt, reliable delivery to its destination.
- It must enable the easy integration of legacy and emerging technologies by supporting all kinds of communications protocols (e.g., AMQP, JMS, MQTT, REST and WebSocket) and link systems running in diverse cloud and on-premises computing environments.
- It must facilitate the centralized deployment and management of hundreds or thousands of nodes to support massive scale, and do so with enterprise-grade performance, robustness and scalability.
- The system must offer the required access and control of data flows to create the required trust as well as the auditing, metering and billing ‘hooks’ to monetize the offerings.
The only technology that meets these requirements is what I call a hybrid IoT event mesh – an infrastructure layer that enables a connected vehicle platform to evolve along the discussed value framework.
Summary
In this article I have defined a roadmap using a value framework to articulate how value, services, the ecosystem, and technology work hand-in-hand to create a successful connected vehicle initiative. I have broken it down into a set of infrastructure challenges within the four swim lanes: the vehicle, the regional edge network, the application platform, and the ecosystem edge network. I have offered an initial assessment of how a trust framework can be established to make people comfortable with the platform. Finally, I described how an event mesh is the ideal foundation for a connected vehicle platform.
When choosing the underlying technology for your connected vehicle initiative, consider the following questions:
- Is it dynamic? Does it support dynamic routing so it can easily scale up and down, and adapt to outages?
- Is it open? Does it support open APIs, communications protocols and integration capabilities?
- Is it simple? Can you easily manage, scale and secure an event mesh consisting of hundreds or thousands of nodes?
If you can answer all three questions with an emphatic Yes!, you’re on the right path.
Explore other posts from category: Use Cases