Since the early days of the appearance of vehicles, people have constantly improved them. Naturally, along with improved performance, came additional complexity. In the first place, the vehicle was a purely electronic-mechanical device. Shortly after the start of the rapid improvement, computer systems and software were added to it, respectively.
This article covers the topic of the evolution of autonomous vehicles to software-defined vehicles, the intricacies of the process of the transition from one to another, and safety and security implications.
The Role of Software in the Evolution of Autonomous Vehicles
At the very beginning of the vehicle development journey, hardware was dominant in the industry. However, the state-of-the-art machines imply a much more convoluted system: it includes an increasing number of vehicle functions in the areas of vehicle control, body and security, Active Safety, and other comfort, convenience, and connectivity services. As a rule, it is a convergence of hardware and software functionality.
Thereby, electrical/electronic architecture, or E/E, is the essential component when it comes to the automotive industry. Nowadays, the architecture of controllers and software is moving towards centralised control, meaning that most OEMs (original equipment manufacturers) are now in 4th generation — Domain-centralised E/E architecture. Historically, there are 5 levels of E/E architecture, from the latest one to the first:
How Software-Defined Vehicles Are Disrupting Traditional Automotive Design
If looking closer into hardware-defined vehicles, the functions of their architecture are determined by the properties and capabilities of the hardware strictly. As one can see in the table, the first-generation vehicles work according to the simple scheme: 1 device = 1 function, without the possibility of improving the functions of previously released vehicles. This leads to the fact that a vehicle released, say, 5 years ago is significantly inferior in functionality to a newly released one, even if their hardware is capable of the same performance.
With software-defined vehicles, on the contrary, their functions are determined by the installed firmware of the vehicle, which in turn allows adding new functions or improving previously installed functions on previously released vehicles without changing the hardware.
Examining Safety and the Security Implications of Software-Defined Vehicles
However, despite all the advantages of a Software-Defined approach to automotive manufacturing, like any other technology, it can be prone to illegal violations that demand corresponding Safety and Security regulations. Here are some examples of such violations that have happened in the last decade and a half:
- 2010: Ex-Employee of dealership Texas Auto Center remotely disables 100 vehicles by triggering their immobiliser. The dealership used a Webtech Plus system as a means of repossessing vehicles that have not been paid for. The employee allegedly wanted to take revenge for his dismissal.
- 2015: Hackers take remote control of the Jeep vehicle. Two researchers managed to remotely hack a car on the highway, turning on the wipers, blasting the radio, and disabling the engine to spot the vehicle.
- 2018: University researchers circumvent key fobs of Tesla Model S and can unlock/start the vehicles in 2 seconds. By figuring out its encrypted codes, they were able to crack the key fob.
- 2019: Researchers extract personal data from a Tesla Model 3. By accessing the particular car’s computers, they managed to find 11 driver phonebooks complete with numbers, email addresses and calendar entries.
- 2022: Researcher manages to hack Toyota's Global Supplier Preparation Information Management System gaining read/write access to the global user directory containing 14k+ users.
For certain, these cases have encouraged particular actions to be taken in terms of security. According to the 2023 State of Automotive Software Development Report issued by Perforce and Automotive IQ, “30% of those surveyed cited safety as their top concern in automotive software development”, meaning that the comparison to the last year’s report revealed several notable shifts:
- The top concern is directed at demonstrating functional safety compliance.
- Suppliers are aimed more at meeting ISO 26262 requirements rather than just complying with a coding standard.
However, coordinating safety requirements can be a challenge, especially in cases where some suppliers are new to this area, given the increasing number of contractors supplying components.
In this sense, there is another option for how to deal with Functional Safety and Cyber Security. The 2022 NHTSA Guidelines assert that “the automotive industry should follow a robust product development process based on a systems-engineering approach with the goal of designing systems free of unreasonable safety risks, including those from potential cybersecurity threats and vulnerabilities”. How do we define what risks are reasonable and what are unreasonable?
A day-to-day interpretation and a legal interpretation may differ. Engineering does not perform a legal interpretation but follows Enterprise Risk Management Frameworks and analyses the risk based on state-of-the-art methodologies.
What must be clear, is that there are no vehicles without any cybersecurity risk. There are no actions that completely eliminate all cybersecurity risks at the vehicle level. However, this does not mean that one is free to accept the risk if this risk is found unreasonable. Therefore one must:
- Evaluate the risk of each system and the vehicle in total;
- Define and implement mitigation actions in the areas where this risk was found unreasonable.
To implement these actions, it is necessary to execute a Cybersecurity Risk Assessment over any system using state-of-the-art methodologies. Currently, synch methodologies for Threat Analysis and Risk Assessment (TARA) in vehicle cybersecurity are defined by ISO/SAE 21434.
The Opportunities and Challenges of Upgrading Software in Vehicles
The possibilities that open up with updating the software are the following:
- Dynamic improvement of product functions even after the sale of the vehicle. This is an important marketing advantage.
- The ability to eliminate problems or errors found after production, including those affecting safety. It is important to note that even some HW problems are subject to correction, since in software-defined vehicles, HW flaws can be mitigated by modifying programme functions which in turn affect the behaviour of the vehicle’s HW devices.
As for the difficulties, the remote software update is definitely the most dangerous feature of the vehicle, since the impact of an error is enormous in every sense and can lead to the:
- Mass failure of functions, including turning the vehicle into a bucket of bolts while moving.
- Mass violation of Functional Safety.
- Additional opportunity to violate Cyber Security.
All of the above can happen to tens of thousands of vehicles at the same time.
The trend towards software-defined vehicles manifests itself in every corner of the nowadays automotive industry, but as with any new technology, a clear, well-thought-out control of implemented innovations at all stages of their application is essential and inescapable.
Top comments (0)