Monitoring of Connected Car Platform: Challenges and Perspectives in building an ideal solution

Connected car has been flourishing in the recent times, especially in the emerging markets. In recent times, connected car has become less of a novelty and more of a default system offered by the car manufacturers. Traditional monitoring requires huge investment in terms of setting of service centers and customer service. Traditional monitoring systems take care of issues which are reported by customer, with response of the overall ecosystem being slow due to manual intervention requirements. Advent of connected car solutions has begun to change this aspect, with live data being available from the vehicle, monitoring of traditional as well as advanced systems and response becomes faster. 

On the other aspect of user experience, customers now have a mobile application which can monitor his/her vehicle. This involves the entire connected ecosystem to be up and running with no downtime. The performance matrix of all mechanical systems of a vehicle are finalized on the Product Development drawing board, but the performance of a connected car solution is not. The user has been in the Android/ iOS ecosystem for so long, that the performance expected is at par with the traditional social media applications build by IT industry which has been doing so for that last 10-15 years in mobile application development and more than 20 years in case of web applications.

This is where the real problem for automotive industry comes in, where we are competing not only with other vehicles in the market, but more importantly the social media and delivery applications available for all to benchmark. Building a highly available and low latency system is one thing, which can be done while architecting the system, but maintaining it at the same remains a challenge. IT industry generally has their own operations team for fulfil this part of the puzzle. Also, it works for them as control of the entire solution is in the hands of a single organization. Connected car however has multiple operational stakeholders even if the final product is being delivered by single OEM.

Connected car as a derivative of IOT solutions, can be different definitions from different stake holders. However, from perspective of the complexity, i have always found the most complicated is the one of OEMs.

Connected car from perspective of an OEM can be converted into 5 broad architectural perspectives:

1. Telematics Gateway (Part of the vehicle)

2. Telecommunication Network Service Providers

3. Native Cloud Services (Indigenously developed for core connected car features)

4. Dependent Cloud Services (Developed for non-native use cases by either 3rd party or indigenous developer, not necessarily for connected car but is adapted to be used for connected car features)

5. Mobile application services (Developed to be integrated with native cloud services or dependent cloud services) 

Monitoring of services must cover all 5 architectural components individually as well as combination of interaction between 2 or 3 of the architectures. Very important information to always keep in mind is that a single unprecedented event can make the entire solution unavailable.

Telematics Gateway

Telematics Gateway includes modem and an application processor primarily as well as specific business logic build onto it. Network configurations for each device should be working. The use of MNOs or multi profile SIMs increases the variability of data. Also, involved is the vehicle specific and gateway specific configuration at the End-Of-Line for manufacturers. Ensuring the proper data is being configured requires a data stream to local servers or remote servers for verification for all the configurations that is being fed into the gateway on a live basis. 

Telecommunication Network Service Providers

Telecommunication Network Service Providers or more commonly NSPs are the backbone of any connected car /IOT solution. As we all know in India, there is a limit on the number of IP addresses it can connect to for M2M SIMs as per DOT regulations, monitoring each of the IPs remains critical. As the whitelisting of the IP can be domain based, URL based as well as IP based. The solution needs to keep checking if the communication is getting established for the same set whitelisting. Furthermore, with OEM bringing in different platforms in the connected domain, network parameters seem to differentiate as per the customer requirements, parameter such as Access Point Name (APN). From the Network service provider perspective, they follow the global monitoring standards what are applicable for consumers SIMs as well.

However, from OEM perspective, this becomes a challenge. There are a lot of stake holders and lot of processes which needs simultaneous monitoring such as activation of SIMs, data connections, IP address allocations, LTE equipment placement etc. At an industrial scale, automotive industry is new to such processes. As the production numbers keep on increasing, the traditional portal-based monitoring starts to reduce effectivity. Higher level of integration with NSP servers and automated update of SIM status can help in reducing downtime. 

One aspect which we need to keep in mind with telecommunication networks, is that they don’t always have consistent performance, even if the environmental factors remain constant, they tend to wary. Any organisation tends to keep such variability away from the production lines, especially the automotive world where the number of parts to be assembled is ginormous; need to adapt to avoid variability. Performing long term studies in production locations help create a manageable threshold within which all the customer requirements can be fulfilled. Also, setting up stations to monitor network parameters such as network strength, signal to noise ratios, data bandwidth availability for the location helps in predicting future failures.

5G is only going to increase such uncontrollable factors. As NSPs are modernizing their backend infrastructure for release of 5G solutions, this is going to start becoming a more complex monitoring. Even a single change from NSPs in their configurations may or may not workout in terms of compatibility with the telematics gateway, ultimately leading to solution availability to the customer. 

Native Cloud Services

Native cloud services can be built on different cloud solutions, including AWS, Microsoft Azure, GCP platform or on specific clouds solution available from automotive solution providers. Monitoring such systems seem easier as compared to others as we can follow the playbook of the IT industry which has been doing so since the advent of cloud.

However, setting up resources for the same and establishing similar infrastructure remains a costly proposition. This is because the IT industry can do monitoring/ operations for multiple solutions at single established Operational centres, which for automotive Connected seems to the unique. Also, building joint expertise in the domain of automotive and IT take time and experience. Mobile applications being part of the cloud content delivery network and with Firebase and apple providing a good framework on notification side makes monitoring a lot easier. Also, they provide native support for such monitoring via statistics portal, which can then be utilized without any additional investment.

Dependent Cloud Services

Now, let’s jump into the newer domains including Dependent cloud services which are SaaS being offered by service providers. Such solutions are easy to integrate however, the flow of usage of such solutions can create massive monitoring issues. If such solutions are integrated as a part of the chain, including 2 native services where 3^rd party service becomes an intermediary, the reliability of the system takes a hit and ensuring all the service providers are at same level of availability is difficult.

There is a new concept in the Cloud domain called multicloud. This involves building the entire solution as a combination of public servers and SaaS platforms. Such solutions are cheap as well as faster to build and deploy however, as all the entities are operated by different service providers, monitoring such systems need to integrate KPIs from all such vendors. Considering the fact the we need to keep track of each solution and also their DevOps cycle and downtime requirements. Cost of operations increase as separate Operation team are setup for each service provider, while the integrator also needs to setup their own Operations.  As the cloud industry sees huge cost benefits from these solutions, surely automotive industry which is quite price sensitive will try to adapt to such solution in future adding an additional level of challenge.

Automotive Cybersecurity

Moving towards the security domain, we are 3 major challenges from monitoring perspective.

1.Update of Cybersecurity Security Critical Assets – For implementation of cybersecurity requirements in telematics solutions, we need to maintain some cybersecurity assets such as Key Management System. These systems are critical for maintaining secure communications across the ecosystem. 

Building such systems indigenously generally involves cost and maintenance at a lower risk, integrating 3rd party solutions reduce cost while increasing risk. But both the solutions have a key monitoring aspect, as any denial of service at security end means the entire solution is unavailable. Expiry of certificates maintained by Root CAs is an additional work; depending on how we setup the CA and intermediaries can lead to additional efforts.

2. GDPR rules: Now these rules vary from country to country, so setting us a solution in different locations need separate DevOps and CI/CD pipelines.

Also, with respect to the rules, we need to modify our monitoring solutions, to comply to the same. two important aspects which GDPR bring in is data obfuscation for storage of vehicle critical and personal data and access of data only a need-to-know basis.

Data obfuscation needs to be addressed during architecting the solution, also when the solution is migrated from development environment to production environment. This is because while testing in the development environment at a fast pace all data access needs to be open and enabled for better monitoring and faster identification of issues. Access to data on a need-to-know basis, however, needs to be implemented on an operational level, while addressing live production environment concerns. As the impact of GDPR violation is both monetary as well as brand image, these monitoring solutions need special care during building, deployment as well as operations.

3. UN ECE R155/R156: These regulations have now mandated the setup of Cybersecurity Management System (CSMS) by individual OEMs for and setting us a process to handle critical situations and getting it approved by authorities. 

Such systems were already present for the IT industry for a long time, however with automotive industry it is a complex multi-stake holder solution, the same becomes more complicated to handle.

These regulations also mandate the sector to all to report vulnerabilities, which then needs to be addressed by the OEMs and Tier-1 suppliers. Again, an IT default practice, which needs to be adapted and generates a need for faster update cycle. The higher update cycles further create a monitoring requirement, to quantify the risk.

The advent of new ways of architecting the vehicle electronics architecture, has brought the idea of Software Defined Vehicle. This again as a concept is well integrated in Android, iOS and even Microsoft Windows Operating Systems and their ecosystem of products, however its new in automotive domain.

This being extremely beneficial from a customer point of view, where we provide new features till the end-of-life cycle of the vehicle, but from the operations point of view becomes a nightmare. Let’s compare it to an existing ecosystem, Android provides a maximum of 4 years of software update that too only by rare OEMs, Apple too provides updates till end of 4-5 years of the device launch.

But when we take into consideration that even if the software updates from Smartphone OEMs for OS itself is mandated the specific application do not follow the same, and where even an old flagship smart phone might not be compatible with new applications. Now coming back to automotive industry, the life cycle is 15 years, when the domain opens to such plethora of options, each vehicle will be unique. For monitoring the growing combination of features and feature updates need a refreshed thinking and roadmap towards viability and maintainability.

Ideal Solution

An ideal solution always tends to factor in high availability, high traceability, and high rate of detection. From a cost perspective a centralized solution seems to be the way to go, with data streams from all data entry points getting stream to that location. However, will such different use cases at the production lines, customer experience, network etc such a solution may not provide us with the best results. A more practical solution may be centrally located for computation purpose but should be placed at each point of data entry or exit. Network related parameters and native cloud services require more automated approach with low latency data ingest, while SIM activation and ECU related parameters require more manual approach with higher latency data stream. This will be a continuously evolving system, which should be developed in parallel with upgrade of software and cloud deployments. 

Even will all the challenges listed above, as has always been to case with automotive industry, i am sure they will rise to the occasion and deliver solutions on par with other industries.

Author:

He is an Electronics Engineer with a career span of 5 years in automotive industry. Worked in Functional Safety, Connected Car domain in Software and Cloud Cybersecurity Process and Penetration Testing. Being a tech enthusiast, his interest fields include IOT, electronics Hardware and software, data science. His hobbies include playing harmonium, playing chess, watching sci-fi and historical documentaries.

Published in Telematics Wire