How will car software be maintained successfully for 20 years?

From a car being sold to the end of its service life, the lifespan of a car model can easily be 15-25 years. This is very different from industries that have driven software evolution required to work at much higher clock speeds.

Looking at traditional products’ development lifecycle in different industries, the maintenance phase is often presented as the final phase of system development. The primary responsibility of maintenance has been to make sure that the product is safe to use and works as originally intended until the end of its lifespan while keeping the required changes to the product at minimum.

Modern complex software products, automotive included, are no longer like this. Vehicles are connected to a larger ecosystem, with features being added, removed or rendered useless by changes in the external systems required for the features to function. Updates are a fact of life, and not a major cost issue to be avoided if possible.

Vehicle safety demands add maintenance complexity

When automotive safety is in the news for safety-related recalls, the reason is a system that doesn’t function as expected in certain conditions. It doesn’t matter if the root cause is hardware or software. There is no exception for software related issues when it comes to responsibility for vehicle safety.

Connectivity brings new security challenges. Vehicles are a constant target for hacking attempts and finding vulnerabilities, as physical access to the vehicle is no longer required.

As an example, security researchers identified and published a hack on a Jeep model that allowed them to remotely control any of those vehicles, and thus making all of them unsafe. The vehicle owners started a class-action lawsuit against FCA, the manufacturers of Jeep. FCA’s argument against the lawsuit wasn’t that safety responsibility does not cover software, but that none of the vehicle owners were directly affected by the hack, and that the hacked systems were promptly updated with a fix before anyone was affected.

Older vehicles are especially interesting for finding vulnerabilities. Any vulnerability may end up as the reason for the next class action lawsuit if it hasn’t been taken seriously and it leads to an actual hack and danger to the customers/owners of the vehicles. Not to mention the potential for lost sales due to the vehicle being labelled unsafe.

What should automotive companies do to cope with the long-term maintenance challenge?

The automotive industry tries to solve this challenge via platform selection and over-the-air software updates. However, one core solution is how the software maintenance function is being integrated into the product planning process through the entire product life-cycle.

With connected, always up-to-date software products, maintenance is no longer a single separate stage happening in isolation after development. The maintenance is on-going product development, sharing the same requirements.

Despite the unique requirements in automotive industry, there are good lessons to learn from consumer electronics, MedTech and telecom industries that have already made the transformation from hardware to software-driven.

Combining experience from these industries and having automotive industry’s specific needs in mind, there are five success factors to keep in mind to cope with very long-term software maintenance challenge:

1. Treat maintenance as part of the product planning from start to end
2. Ensure that system architecture enables updates and maintenance
3. Use codeline management practices and DevOps processes
4. Use software suppliers and partners cleverly to manage the product lifecycle
5. Manage hardware dependencies

Tietoevry has decades of experience in acting as a strategic software R&D partner in the telecom and smartphone area. The learnings are resonating well into automotive R&D partnerships.

Please learn more about the five success factors mentioned above by reading the Whitepaper: Mastering Very Long Automotive Software Life Cycle