Software-defined: an industry U-turn
With the advent of software-defined vehicles (SDVs), cars are rapidly evolving to become more connected, autonomous, shared, and electric. These four features have eventually become so prominent that everyone in the industry can recognise them as the popular acronym CASE.
Constantly growing customer expectations also drive the SDV concept and impose challenges both on automotive hardware and software. To accommodate CASE trends and consumer needs, traditional vehicle architectures need revisiting and redesigning. Along with many other requirements, the new architecture must ensure upgradability, performance, and security.
This is a major change for the automotive industry that 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.
What are software-defined vehicles (SDV)?
We all know what cars are and have a certain understanding of how they work, the engine, the fuel, wheels, etc. Now imagine a car that can change its suspension settings or acceleration capabilities through its lifecycle, prompted by an over-the-air software update. It’s obvious that this would add to the complexity of the car. But these features are actually already possible today!
In the same way your smartphone can gain low-light picture optimisations following a software update, your vehicle could benefit from engine performance boosts or battery consumption improvements thanks to the use of better algorithms deployed via a software update. That’s why cars are called computers on wheels nowadays.
The SDV challenges and benefits for Manufacturers
Traditionally, OEMs use electrical/electronic (E/E) architectures with hundreds of ECUs designed for specific tasks, causing vendor dependence and reducing scalability across different car models.
Updating these platforms involves substantial expenses and leads to wasted resources spent maintaining these model-specific software components rather than improving software that could be used throughout the OEM’s carline. On top of that, customers are expecting regular updates to their cars with not only security patches but also new features and services.
In order to satisfy these customer demands, OEMs recognise the necessity to shift from a hardware-focused vehicle structure to a software-driven one, capable of managing over-the-air updates and inter-component interactions.
Software-Defined Vehicles (SDVs) represent a paradigm shift in the automotive industry. SDVs leverage software-based systems to improve performance and enable a more efficient use of resources. OEMs need to move away from multiple complex components towards a limited number of systems that can be easily managed.
Key benefits of software-defined vehicles include:
- reduced complexity and cost
- faster time to market
- improved product quality
- hardware and software flexibility
With a strong focus on features and software-based services, SDVs can also enable better security and user experience. To achieve this, the entire value creation process needs to be redesigned around software.
Increasing hardware complexity in automotive
With vehicle design becoming more software-centric, manufacturers will have to contend with hardware-specific challenges.
Historically, OEMs have handled a large number of vehicle variants which themselves generate huge component, platform and configuration variants. These are influenced by region-specific constraints, customer customisations and product options that raise the appeal of the vehicle model or brand.
Jeremy Bezanger on Unsplash
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.
Cybersecurity concerns
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.Security and real-time Linux in a shifting automotive world
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.
Safety considerations
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.
Functional safety aims 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.
Considering 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 many more intricacies 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.
- Want to learn more about Software Defined Vehicles? Download our guide!
- Contact Us
- Check out our webpage
- Learn about EB corbos Linux – built on Ubuntu!
