Validation of Connected Vehicle Solutions

adminMarch 19, 2021

8 minutes read

Validation of Connected Vehicle Solutions

Auto industry is going through massive disruption because of the exponential developments in Connected, Autonomous, Shared, and Electrified (CASE) technologies. Customer expectations are changing and new players are entering the market offering value propositions beyond what the traditional vehicle offers. The markets are clearly seeing this trend as driving future growth in the industry. For instance, Tesla’s market cap is now more than the 9 largest automakers combined; and just the speculations about Apple Car is influencing the market cap of traditional players like a Hyundai or Kia by 15% to 20%.

While each element of CASE is a big technology shift in itself, the “Connected” aspect is going to be pivotal in amplifying the value of the other elements – Autonomous, Shared and Electrified. This is not just in terms of technology, and user experience but also in terms of the business models in both the passenger and commercial vehicle markets. A Mckinsey perspective shows that the connectivity powered recurring businesses could be worth $1.5 trillion, a 30% additional revenue potential, over the traditional car sales and aftermarket revenue streams.

The data from the passenger and commercial vehicles would be used in very interesting ways to provide differentiated value to different customer personas.

Software intelligence powered by AI, rule engines, and 3rd parity integrations spanning across the vehicle and the cloud would continue to evolve as the key differentiator between different vehicle models and services, making connected vehicles one of the cutting edge IoT systems that leverage every possible development in technology including 5G, Blockchain, Top end AI, etc.

While these are exciting developments, vehicles are now much more complex and are part of an interconnected system that is changing all the time.

All aspects of web/mobile software development like faster iterations, regular software updates over the air, security, backward compatibility, end of life decisions etc., now have to be handled in the context of connected vehicles. But this time around the participating actors in the systems aren’t just users but also the physical things – the car as a whole, the battery, the tire, etc.., the environmental data from sensors. In addition to that various vehicle models with varied capabilities and services attached to them to be supported over many years of the vehicle lifetime. This presents a new risk – will the vehicle and these new service function and perform reliably every time? Remember a Ctrl+Alt+Del is not an option when you are on the road.

While mastering a successful product launch with respect to time, cost and quality is a key capability of every organization, product launch delays and recalls have rapidly increased in the recent years in the auto industry. Failure in any of these parameters could lead to financial, branding, reputational losses and also have the potential to impact the market competitiveness of a company.

The key focus of this article is the validation of software components related to the connected offerings. Assumption here is that the architecture of the connected offerings would be overlaid on top of the systems in the vehicle domain that would evolve independently, and those including the hardware support required for the connectivity related offerings would continue to get commoditized as they mature.

Key Challenges in Validating Connected Offerings:

Architecture, development, quality assurance, and maintenance of these connected vehicle features are different and are extremely complicated compared to traditional software considering that

These systems interact with the physical world and could have numerous combinations of data scenarios
Algorithms would need to operate on data streams instead of a point in time data
Sensor fusion to account for uncertainties in measurements and also to be able to make proper decisions in certain scenarios
Varied network conditions that a vehicle experiences
Sensor measurement faults driven by the environment, as simple as that of the unavailability of continuous GPS fix
Performance requirements of different parts of the system at the scale of millions of vehicles
Multiple teams with varied competencies are involved, and they don’t necessarily understand each other’s constraints well given the backgrounds
Agile software development methodologies coming into play considering the competitive nature of the software
Parallel development of vehicle and cloud software

Testing becomes all the more important to handle the inherent risks that come with this complexity. But that’s easier said than done when it comes to Connected features or critical enabler features like FOTA that impact even the features that aren’t directly connected. The current set of tools and techniques available to testers are either inadequate, costly, or time-consuming and there is a huge reliance on the field tests to thoroughly validate the connected software.

Given the situation, the following are some of the general realities that we see day in day out when talking to our customers:

Miles and miles of repeated field tests as the software continues to evolve with more and more functionalities.
Last-minute surprises in the field test much later in the development cycle delaying the launch.
Test execution isn’t controlled and repeatable making the results from different rounds of testing to be unpredictable rather being incremental.
Cost overruns on the software programs because of the inability to rightly model the costs involved in getting the validations done
Performance challenges as the scale go up, in spite of using popular cloud platforms and elastic architectures
Uncontrolled OPEX costs associated with the connected assets in terms of the compute, network, and storage resources required to deliver the functionalities.

Case 1:

Consider a ‘tractor as a service’ solution that’s envisioned to be the core of the business model transformation for an OEM -i.e. from selling just the vehicles to services charged on usage. The decisions that this system would take based on the telemetry data from the vehicles would become the core of this business model, and hence these business critical functionalities in the software need to be validated thoroughly.

Validation of this service isn’t easy from a technical perspective. The algorithms use multiple parameters like the vehicle movement identified by GPS information, geo-fences, the speed & RPM of the vehicle, fuel consumption, shape and size of the field, size of the tractor and implement attached to it and so on. The algorithms need to be tested against all the possible permutations and combinations of these parameters

On top of this are the complexities of measurement errors, network unavailability, GPS unavailability, etc., which are handled by basing the decisions on streams of data that came in the last few minutes instead of the point in time data. It’s also important to make sure that things like fuel pilferage don’t happen by looking at the telematics data to avoid operational losses. In addition to these, there are also the aspects like FOTA that need to be validated to make sure that the rollout is smooth and is backward compatible with the different versions of software that’s out there on the field already. How would one validate this system and sign off with confidence every time there is a code change for defect fixes or enhancements?

Case 2:

Now consider the scale and performance issues. Connected vehicle platforms are expected to handle millions of vehicles and high data rates without compromising on the SLAs for alerts or response times, as more and more vehicles get sold. Architects approach this problem with horizontally scalable event-driven micro-services pipelines – managed services or otherwise. But the catch is that these systems and services come with their own set of configurations that need to be tuned in an orchestrated manner to get the required performance, often times the tunings fix one problem and open up other problems.

Most of these tend to be cloud-based deployments so that they can scale elastically whenever required based on a certain set of rules. This means the developers could eventually tune the system for the best performance while inadvertently throwing more than planned resources and get the job done. This impacts the unit economics of the connection which just not the hardware BOM anymore and also includes the OPEX costs associated with the cloud, connectivity, data storage, etc., At scale, even small cost variations caused by these deviations could be staggering.

*Figure 1 Impact of changes in unit economics of device level OPEX*

These are just two examples to illustrate the magnitude of challenges involved in bringing connected vehicles to market. The complexity only goes up as we push more and more towards a seamless V2X coupled with autonomy. The first step in solving any problem is recognizing there is one.

What are the options?

Components to be validated are on the cloud as well as on the vehicle, and those have to be validated in isolation as well as an integrated system under various network conditions. The application workflows generally include the TCU/CCU, Head unit on the vehicle, Mobile and Web applications.

*Figure 2 Software Components under Test*

Validating these systems using protocol simulators, test bench or even real vehicle test are inadequate, costly, time consuming and aren’t precisely repeatable in a controlled fashion. Doing these validations for every release with so much of constraints is a testing and project management nightmare.

The only option that comes close from a technical perspective is developing a custom test bench – SIL (Software-in-the-Loop)/HIL (Hardware-in-the-Loop) based approaches – to simulate the vehicle and have rest of the system on the edge and cloud tested either manually or through automation. An ideal test bed should facilitate the scenario simulations, virtualization of hardware, scalability and performance tests for hundreds of thousands of vehicles for different scenarios both through manual and automation testing.

Given the complexity, these options aren’t feasible and viable to build and maintain as the core product evolves sprint after sprint. And even if one attempts to build such a system it is very hard to deliver on all the expectations of the test bed including the network conditions, large scale scenario testing, etc., easily including the requirement for an on-demand elastic infrastructure that needs approvals every time when the configuration changes. Last but not least, it is just not prudent to invest the resources in a non-core activity considering the scarcity of software engineering talent in the industry. The business might as well invest those talented resources on the core product offering.

But the good news is that the problem of validating connected offerings isn’t unique to auto industry and is applicable to all industries that are trying to leverage IoT for reinventing their offerings and business models. This is exactly the problem that IoT centric validation platforms like Doppelio are solving for the enterprises building connected vehicles and connected offerings mitigate the risk of failure, accelerate their time to market and also reduce the cost of quality.

References:

Author:

Rajesh K

Co-founder & Head of Products

Doppelio Technologies Pvt. Ltd.

Rajesh is passionate about connected and autonomous vehicles. He is Co-founder and Head of Products at Doppelio, a start-up that has launched a first-of-its-kind IoT Test Automation platform. Doppelio is being used by businesses across use cases like connected vehicles, connected supply chain, and connected buildings to ship products on time and with reduced risk of failure.

Published in Telematics Wire