Connected VehicleCybersecurityVehicle Telematics

Building Connected Vehicle Platforms – A Practitioner’s Perspective

Vinod is an Industry Principal with Infosys Engineering Services, with over 22 years of industry experience. His research and focus area are Internet Of Things, and its application across Industrial, Consumer Electronics and Automotive domains. He has established and run innovation centers of excellence for clients to experiment and rapidly prototype new technologies to identify risks/challenges.

Suraj is a Senior Technology Architect with Infosys Engineering Services with over 20 years of industry experience. While he has executed multiple projects in the Internet Of Things domain over the years, his current area of focus has been Connected Vehicles, where he has worked with multiple leading car manufacturers and Tier1s in developing Connected Platforms.

2.   Abstract 

Traditional businesses were growing based on a linear value stream (Geoffrey, et al., 2017). In this model (visualize a pipe) there were upstream processes that were producing and delivering value downstream and the downstream functions were responsible for distributing the value to end consumers. The vehicle industry fits this model well in that the OEMs were producers and there were consumers who would buy and use the vehicles. There has been a significant shift in the automotive ecosystem accentuated by pervasive connectivity, hardware commoditization, and differentiation through software. Today’s consumers have a highly active digital lifestyle and connected services are a key influencer in the buying process. Hence, the ability to innovate rapidly, create and exchange value across diverse ecosystems to deliver personalized and contextual experiences to the end consumer.

The connected car driven by software platforms is transforming the value chain by bringing together multiple elements of the ecosystem to deliver amplified value to the consumer. The objective of this paper is to provide a practitioner’s viewpoint of defining the connected vehicle platform capabilities and architectural guiding principles to build a platform. The methodology and recommendations in the paper are based on experiential learnings of many implementation projects. A case study that describes the journey and technology decisions that were made has been outlined. We conclude by reiterating the importance of connected vehicle platform as a key competitive differentiator for auto makers to deliver newer experiences.

3.   Introduction

The vehicle being connected to the internet opens the possibilities to multiple services including safety, infotainment, telematics, vehicle diagnostics, driving behavior, driving assistance, remote services. The connectivity to the car has opened a parallel channel that allows disparate participants to create and exchange value throughout the entire journey of a vehicle. Features such as Over The Air (OTA) updates allow for constant innovation, value amplification and unlike the physical vehicle no depreciation. Orchestrating and delivering these services to the consumer in the car is performed by the connected platform. Building a connected vehicle platform is a multi-year journey that starts with business justification, defining the platform capabilities, outlining a roadmap, development, launch planning and operations. In this paper, we are focused on the platform build phase and not so much on the other phases

We firstly establish the need for a connected vehicle platform and derive platform capabilities based on stakeholder persona analysis. When analyzing the stakeholder personas existing and future use cases are considered and overlaid on journey maps to determine interactions. This leads to platform architectural requirements and recommendations. Our recommendations include a conceptual view of a typical connected vehicle platform architecture and traceability of recommendations to achieve the platform capabilities. We then tie it all together through engagements which is the uniqueness in our paper – the learnings are what have been shared through this paper. Every enterprise and their needs are unique, so it is challenging to develop recommendations for every single enterprise – we have not fallen into the trap of making it very generic. We have struck the right chord by balancing specificity in a broader sense so that the audience can tailor it as required. The uniqueness in our paper is that our recommendations are experiential of having worked on building such platforms for our clients. Irrespective of where the automaker is in the journey, we believe the recommendation and architectural frameworks that have been presented will be valuable

4.    Why do we need a platform?

Auto manufacturers (OEMs) have traditionally focused on building better, eco-friendly and value for money vehicles through improvised production processes, leveraging IT across the entire value chain.  With hardware commoditization, pervasive connectivity, rapid introduction of new services, owning the customer experience from purchase to transition and potential to integrate into the consumer’s digital lifestyle throughout the vehicle lifecycle using multiple channels, are some of the key drivers for a connected vehicle.

Service delivery platforms have been successfully leveraged by other industries such as Telecom operators to manage and sell services, increase the Average Revenue Per User (ARPU).  Platforms have helped them launch new services to market faster, integrate with a variety of 3rd party content providers, enable a vibrant developer community and lastly create newer revenue channels (Gerwig, 2009).. These drivers are truly relevant in the automotive industry as well – as vehicle manufacturers compete to launch new services, and onboard new partners.

In addition to influencing consumer buying behavior (Deloitte, 2014), there is a definite need to interface with multiple players in the vehicle ecosystem. For instance, transportation ecosystems to start providing mobility as a service through multiple transport modes. Consumers are now digital natives, that have multiple touchpoints such as smart homes, wearables, and many other lifestyle apps. Manufacturing processes that are embracing Industry 4.0 can now consume real time vehicle usage behavior. An ecosystem that is nurtured and expanding will soon become a competitive advantage

Platforms help business scale through network effects, leveraging data, delivering experiences. The need for a connected platform (Lamarre, et al., 2017) can be summarized to provide:

  1. Ability to provide a consistent, seamless, contextual and integrated experience across all user channels, anytime and anywhere.
  2. Ability to create and exchange value across multiple ecosystems such as the consumer’s digital ecosystem, larger transportation ecosystems, smart cities
  3. Ability for developers, and innovators to focus on systems of differentiation by providing foundational services that can be consumed easily
  4. Ability for the business to innovate at speed to address rapidly changing market conditions in a highly competitive market.

1. What is a connected vehicle platform?

A broad definition of a connected platform is that it is a software solution that provides for managing devices, handling the data, integrate with internal and external systems, leverage analytics and facilitate development of consumer applications. However, the challenge lies in narrowing the definition to determine the platform capabilities. A practical approach that we have employed in our engagements is to identify key stakeholder personas, identify their interaction expectations and then derive the platform capabilities (Gibbons, 2017). The approach combined with architectural principles and patterns provides comprehensive technology requirements that can be used to define what should the platform be and how should it behave.

Our approach to identify stakeholders is based on their persona that determines similarities of usage, attributes and being part of an ecosystem. A stakeholder persona-based approach facilitates innovation and generalizes the platform expectations. The stakeholder personas and their expectations are captured in the table. For instance, with the growth of smart communities and smart transportation use cases such as finding parking spots, ability to plan integrated journeys across multi-modal transport means will be expectations. Voice based assistants are extremely popular in the digital lifestyles and as an extension consumer expect it in their interaction with their cars as well (Abuelsamid, 2019). Some of the futuristic use cases include in-vehicle payments for fuel, productivity applications such as email and collaboration tools (Thiyagarajan, et al., 2018), in-vehicle delivery being piloted by e-commerce and logistics providers (2019). 

Stakeholder PersonaDescriptionStakeholder Expectations
ConsumerEnd users who consume the connected servicesPersonalized, contextual experience integrated into their digital lifestyles
Auto OEMsAuto companies that manufacture, distribute and service vehiclesEnable rapid innovation while owning the end to end experience
Value chain playersTraditional value chain players such as dealers, service operators and new age players such as content generatorsUse real time feedback to understand consumer behavior and improve their products and stay relevant.
Platform usersUsers in various capacities such as system administrators, support, business teams, and developersFocus on differentiation, seamless and simple platform interfaces
Transportation ecosystemPublic transit companies, multi-modal transport players who provide end to end journey related servicesEncourage shared mobility services by integrating into the platform to deliver end to end mobility services
Community ecosystemSmart communities, smart grids that deliver utility servicesSimplified integration to the platform to encourage and nurture community services
Allied services ecosystemFinance, Insurance companies that provide services to the consumerWeave into the consumer journey seamlessly to enhance experience
Manufacturing ecosystemVehicle manufacturing supply chain including the Tier 1s, and suppliersReal time feedback on vehicle usage to optimize manufacturing processes
Regulatory bodiesGovernment and industry bodies that define standardsAbility to audit usage, adherence to standards as outlined by the standards bodies

Table 1: Stakeholder persona analysis

Figure 3: Stakeholder Persona and Expectations

A common technique that is used to detail out the expectations are end to end journey maps and careful investigation will provide discrete platform capabilities. The journey maps lead to platform roadmaps and help in prioritization since the value curve follows the journey maps. Another benefit of these journey maps is its ability to identify intersection points that share common attributes of experience and architecture with other personas. A summary of platform capabilities based on the above analysis is presented below

  1. Launch new connected services rapidly with innovative business models
  2. Real time personalization and contextualization for consumers through the entire journey
  3. Engage consumers through Omni-channel with context continuity
  4. Leverage data science to churn value from lots of data
  5. Think globally while allowing for regional customization
  6. Encourage open innovation – allow the ecosystem to create and deliver value
  7. Emphasize customer privacy and security

1.    Architectural Principles to build a Connected Vehicle Platform

A Connected Vehicle Platform is a composite of multiple services that combine to provide an end solution. Services on the platform serve as a sink of data from the vehicle (TCUs, infotainment systems, OBDII based after-market device, connected smart phones etc.), enterprise systems (dealer systems, system of records) and third-party content to provide seamless exchange of information across telematics, infotainment and diagnostics.

Services on the platform can be categorized as follows –

  1. Customer Experience services serve customer requirements directly such as an eCall, Human Machine Interface (HMI) in the in-vehicle dash etc. An example of such a service would be one that listens for impact events from the TCU, records relevant information like time, impact, location etc. in the data store, correlates event with vehicle owner, number of occupants in the vehicle (from diagnostics) and notifies a Call Center interface of the incident.
  2. Business enabling services enable business services for instance SIM life cycle management of the vehicle’s eSIM in tandem with the mobile network service provider. An example of such a service would be one, that is used to temporarily disable/deactivate an eSIM via Service Provider interfaces, in a case where an owner has not paid subscription fees for connected features.
  3. Platform and Framework services built to support the overall platform requirements such as Notification Services, Platform Monitoring. An example of such a service would be that is designed to subscribe for messages on a message broker topic that it could forward as SMS messages to recipients.
Figure 4: Connected Vehicle Platform Logical Architecture

To achieve the above, the broad platform capabilities need to be met by a set of guiding architectural considerations for the platform. From our experience (Nair, et al., 2019) of having developed and maintained connected vehicle platforms, the following common philosophies apply irrespective of the connected vehicle segment being supported. When considered as a set of principles, they address the platform capabilities rather than a one-to-one traceability

Figure 5: Platform capabilities driving architectural principles
  1. Design a global architecture, provide for localization

Our experience with OEMs has been that, while regional businesses are allowed the autonomy to build solutions, the trend has been to leverage global platform architectures developed by other businesses, by incorporating localization opportunities. Localization is needed because (a) device specifications and device to platforms specifications differ across markets (b) enterprise integrations differ (c) regulation requirements (d) typical localization requirements around language, date-time, currency formats, country specific requirements.  Core of global platform architectures work on canonical data models generated via regional specific localized interfaces.

  • Leverage microservices

Microservices based architectures benefit platform implementation by breaking functional services into small independent units. A microservices based architecture comes with well-known benefits of being quicker to build, feature based scaling and higher availability of services. Unlike monolith architectures, it is not necessary that the same technology stack and implementation be used throughout the project.  This provides for newer technology and programming paradigm adoption without impacting the larger platform. Microservices enables adding new teams that work on independent pieces thereby increasing velocity of overall platform development. 

  • Be cloud vendor agnostic 

Building applications to be cloud agnostic, provides OEMs with the freedom to move workloads across multiple cloud providers easily based on existing or new strategic partnerships.  The pattern encourages using neutral APIs (instead of provider specific SDKs) to integrate with the provider’s managed services. Product Managers constantly analyze the flexibility of moving across cloud providers to exploit attractive price discounts, better uptimes or to support specific requirements of geographical markets (for example – GDPR related requirements around data residency.) However, it is important to analyze if the cost of engineering such capabilities into the system and the resulting opportunity cost (of not having spent this time to build new business features) does not outweigh the benefits of moving across providers.

  • Use standard messaging infrastructure

In a microservices based platform, the device interfacing service consumes messages from the device and publishes events (and data) of interest on the message bus.  Upstream services subscribed to this data can consume and process events of interest.  Thus, a publish-subscribe model (instead of a point to point integration model) enables newer microservices to consume data and events of interest without impacting existing services. Standard message formats also help in service orchestration to compose and deploy new services rapidly

  • Embrace an Automation-first engineering approach

            An automation first engineering approach is crucial to microservices based platform development. The approach enables independent and quicker deployments coupled with early test injection, health checks, continuous quality inspection. The automation first based thinking is critical for development, testing, deployment, operations, monitoring, infrastructure setup, scaling for performance so that the engineering team is focused on developing what’s best for the platform.  Automation deployments are backed with a notification framework that informs necessary responders of the path traversed from pushing code in repository to ultimate deployment.

  • Provide value by enabling APIs

APIs are a key enabler to innovation and for fostering new ways for customers and partners to interact with each other. Connected Platforms enable creating experiences from ecosystems by consuming and exposing APIs. By making relevant data and features available to third parties to create value, automotive companies can expand their addressable market and commercialize implementations. To achieve an external facing API, the implementation would need to orchestrate among multiple backend services and systems of records to achieve the desired feature. API Management would need to be used to securely expose APIs to consumers.

  • Platform Integration with Enterprise Systems

A Connected Platform would require access to a system of records maintained by Enterprises to extract more relevant context. Complexity of integrating platforms with such systems (some of which may be legacy) needs to be thoroughly understood. Solution should involve combinations of cloud and on-premise integrations, API or messaging broker-based mechanisms of exchanging data etc.

  • Leverage data for analytics

Massive amounts of event, customer, vehicle, location, preferences data is streamed into the connected vehicle platform from various sources in the vehicle ecosystem. To ingest, store and process data, big data infrastructure needs to be built that is scalable to current and future requirements.  The infrastructure should be able to accept real-time, batch and variable workloads of data streams with analytics and machine learning algorithms that can transform engineering data to meaningful content. Necessary interfaces must be available for multiple audiences to access data – including data scientists, business partners, external partners etc. T

  • Develop a unified security solution

Security in a connected ecosystem needs to be addressed at multiple levels. From a platform perspective, device authentication (at bootstrap and in regular communications), protection of data in motion (single or mutual SSL), protection data at rest in the platform, authentication, and authorization checks for consumers of this data on the platform (OpenID Connect, OAuth2.0) is paramount. Infrastructure needs to be protected by developing private networks of resources with focused network configuration. Runtime security vulnerability checks (Azure’s AzSK for example) on deployed infrastructure and applications must be budgeted as an essential requirement. Applications also need to adhere to OWASP principles for application security with static code security checks enforced as part of the automation pipeline.

1.    Case Study

Our experiences of helping multiple clients build connected vehicle platforms have been captured in this section. We are hoping that the reader will be able to relate to the platform capabilities and architectural requirements that have been described in preceding sections.

A leading auto manufacturer was using a third-party telematics platform for providing telematics services to their customers. Relying on a vendor for telematics services exposed constraints that were a deterrent to the OEM competing in the market – new service introduction in the market, turnaround time for enhancements and fixing defects was high, lack of clear communication on platform issues and their root causes, access to application logs was constrained etc. The auto manufacturer engaged in a strategic exercise that helped define a new connected vehicle platform roadmap through a stakeholder persona analysis of journey maps, assessing the future use cases and industry trends. As an outcome, the customer decided to invest in building a Connected Vehicle Platform that would enable launching services faster to the market, help the OEM own the data and also leverage their existing investments. The platform architecture had to be robust and future proof to accommodate emerging use cases and technology trends. In this context, the following key decisions were made from a platform architecture perspective

  1. Microservices based architecture enabled distributed development, independent technology stack upgrades, demonstrate continuous development progress, higher performance and scalability.
    1. Cloud provider agnostic interfaces and using container orchestration platform like Kubernetes helped move workloads across cloud providers and providing for auto-scale, continuous service uptime
    1. Automation first approach helped improve deployment frequency, ensure quality code, reduced cycle time between fixes.
    1. Service Virtualization minimized impact of dependencies on platform development schedule and enabled robustness by testing abnormal conditions/responses from virtualized services.
    1. Vehicle simulation (of ECUs) ensured that the platform was testable as development proceeded, enabled engaging product demos, simulated scale for performance and stress tests
    1. Building solution, platform, and infrastructure monitoring capabilities to enable troubleshooting, and faster time to recover
    1. Leverage existing investments on security, analytics by integrating them into the solution rather than building them grounds up.

2.   Conclusion

The connected vehicle platforms are here to stay and will continue to evolve in maturity. With the growth of Electric and Autonomous vehicles, we foresee the platform to be the fulcrum on which auto manufacturers can innovate, engage with ecosystems, and deliver newer services to end consumers. Building a robust and future proof platform is crucial as the connected use cases continue to explode. Automakers go through a journey of building the platform and leveraging existing investments in the technology landscape. Considering the liability associated with the auto industry, the curation, and stringent quality standards would have to be enforced by the automaker. The challenges of Build vs. Buy, choosing the right technology stack, Global vs. Regional, Security vs. Experience tradeoffs, technology stack decisions will have to be carefully analyzed on various parameters. The platform economy will continue to grow, and the automotive value chain has an incredible opportunity to democratize innovation to deliver next-generation mobility services to its consumers.

3.   References

Abuelsamid, Sam. 2019. Automotive World. [Online] 2019. https://www.automotiveworld.com/articles/digital-voice-assistants-are-the-future-of-in-vehicle-control/.

Deloitte. 2014. Global Automotive Consumer Study – Exploring consumers’ mobility choices. US : Deloitte, 2014.

Geoffrey, Parker, Van Alstyne, Marshall and Choudhary, Sangeet Paul. 2017. Platform Revolution – How Networked Markets are Transforming the Economy?and How to Make Them Work for You. 1st. New York : W. W. Norton & Company, 2017.

Gerwig, Kate. 2009. TechTarget. [Online] 2009. https://searchnetworking.techtarget.com/tip/Effective-service-delivery-platforms-Are-we-there-yet.

Gibbons, Sarah. 2017. Nielsen Norman Group. [Online] 2017. https://www.nngroup.com/articles/ux-mapping-cheat-sheet/.

2019. IOT for all. [Online] 2019. https://www.iotforall.com/internet-of-vehicles/.

Lamarre, Eric and May, Brett. 2017. Making sense of Internet Of Things Platform. Montreal : Digital McKinsey, 2017.

Nair, Suraj and Venkateswaran, Vinod. 2019. Authors experience. Bangalore : Infosys, 2019.

Thiyagarajan, Niranjan, Walton, Byrn and Hamilton, Jamie. 2018. Disruption in the automotive industry | Enhancing the customer experience through connectivity. UK : Deloitte, 2018.

Tags

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button
Close