Software-defined: an industry U-turn
Vehicles are becoming more connected, autonomous, shared and electric (the famous CASE acronym). While customers expect new features and upgradability, the software and hardware components enabling such innovations require a different system architecture to function.
This is a major change for the automotive industry as it requires new software skills, methodologies and business models. At the same time, automotive manufacturers need to adhere to complex and strict industry standards, and uphold safety-critical functions. In this post, we will focus on the different challenges the industry is facing in terms of hardware and software complexity, cybersecurity and safety. We will also discuss how Original Equipment Manufacturers (OEMs) can learn from software companies to survive this transition towards software-defined vehicles and succeed.
Increasing hardware complexity in automotive
Historically, OEMs have handled a large number of vehicle variants which themselves generate huge component, platform and configuration variants. These include region-specific constraints, customer customisations and product options that raise the appeal of the vehicle model or brand.
Previously, vehicles weren’t connected (or had basic connected services). Continuous updates and feature enhancements led to the current situation: OEMs are struggling to maintain their existing systems while developing new platforms that usually don’t rely on the previously developed ones.
In order to improve this complex situation, they first need to reduce hardware and software dependencies. This approach has been applied in the cloud and smartphone worlds. Take the iPhone for example; the same iOS version can run on multiple generations of iPhones. Moreover, the same iPhone will be able to benefit from the updates of multiple versions of iOS throughout its lifetime.
Removing these dependencies is hard though. After all, decorrelating hardware development cycles from software development implies a change in business models, sourcing and ways of working. On top of that, the industry is suffering from the lack of clear standards, which would allow for an easier interface between the vehicle’s hardware and software.
Software complexity and solutions
Currently, when there is a redundant software component or feature, most OEMs find that the existing software can’t be reused as it would imply porting on a completely different configuration. This would result in additional work and potential compatibility issues. To add to the complexity, Electronic Control Units (ECUs) were historically built using a silo approach; each of them had their own hardware and software (including middleware, operating system (OS) and service set).
To solve this problem, a common abstraction layer can be introduced throughout the vehicle, allowing existing software to be reused. Doing so would drastically simplify complex hardware and software configurations. This is part of what constitutes the software-defined vehicle (SDV) approach.
Not only would the SDV allow for easier updates and compatibility, it would also pave the way for more future-proof electrical/electronic (E/E) architectures, moving away from siloed and dedicated ECUs to zonal and central high performance computing (HPC) focused architectures.
As vehicles increasingly resemble computers on wheels, having additional embedded software also means having more potential vulnerabilities. OEMs generally rely on multiple different suppliers working on common platforms and developing on different tools. Often due to confidentiality issues, said tools and developments are rarely shared throughout the industry. This makes it difficult to cooperate on shared solutions to address vulnerabilities.
On top of this, regulations are becoming very strict, forcing OEMs to provide patches and fixes to common vulnerabilities and exposures (CVE). Taking into account the previously detailed system complexity, it is becoming increasingly necessary to move towards a software-defined holistic context. Only a software-defined approach can provide the required flexibility and scalability that allows companies to comply with regulatory requirements while providing UX updates and handling hardware complexity.
Of course, cybersecurity never only relies on software. Hardware vulnerabilities can also occur and usually lead to even worse consequences. Some hardware issues can be patched via software, but usually these CVEs remain valid throughout the system’s lifetime. For example, Meltdown and Spectre, two of the most widespread hardware vulnerabilities in the world, are still present and affecting tons of devices. This means that during hardware conception, cybersecurity must be taken into account in the specifications and system architecture in order to limit these vulnerabilities.
Then there’s the matter of safety. Advanced Driver Assistance Systems (ADAS) are included by default in most new vehicles. These systems have access and control of critical functions such as acceleration, braking, steering, etc. In order to keep the vehicle’s occupants safe, OEMs are asked to comply with a certain level of functional safety.
The goal of functional safety is to limit the risks and dangers due to a malfunctioning component or system. With Autonomous Driving (AD), safety may become the key differentiating factor when choosing a vehicle.
Put into perspective with the previously mentioned themes, safety-related systems will need to be continuously certified as safety compliant. Moreover, any new service or feature will have to be evaluated for any interference or impact on safety systems.
Preparing for the road ahead
We tackled some of the complexity that the automotive industry will have to focus on when moving towards software-defined vehicles in this blog post, but there are many more intricacies that need to be addressed.
If you want to learn more about these challenges, read our guide to SDVs. You will get an analysis of this momentous industry shift, from new business models to functional safety, development cycle improvements and software reuse.