Software developers will soon be the new car mechanics as the automotive software market explodes - expected to balloon up to roughly $80bn by 2030. Like many other industries, the automotive industry is experiencing unprecedented levels of innovation, technological advancement, and competition. Infotainment, connectivity, and third party companion apps and devices will soon become commonplace in our vehicles. And what that means is that the battle for car manufacturers to stay profitable will be won, not over mechanical parts, but over lines of code.
You can get a sense of this seismic shift from the ever-increasing involvement of big tech players Google, Amazon, Apple and Microsoft in the automotive industry in the last few years. Even though most of us in the 2010s probably thought we’d be travelling in autonomous cars by now, lots of progress has still been made in the space, as evident by driverless ride-hailing tech in major US cities from Google-owned Waymo. The UK Government even asserts that by 2025, AVs will be commonplace on UK roads.
While the quality of that code is obviously going to impact the usability of car features, you can’t talk about any software today without talking about security. And the security implications for the connected vehicles of the future are enormous - both in terms of how bad actors could exploit code vulnerabilities but also how bad code could result in unintended breakdown of critical functions.
Just how safe are AVs from bad actors?
Questions have already started to emerge about the safety of AVs. However, this is really just a taster of what future concerns might look like as cars become increasingly connected. Being software-driven (no pun intended) means code security is going to receive extremely close scrutiny under the microscope.
Just a few years ago, security researchers stunned the automotive industry by hacking into an insecure Jeep being operated by (consenting) Wired reporter Andy Greenberg. It was a warning shot to the industry that led Jeep’s parent company Fiat Chrysler to recall 1.4 million vehicles. The National Highway Traffic and Safety Administration even issued a fine of $105 million.
“The security implications for the connected vehicles of the future are enormous”
Did this scare cancel or slow down development of AVs? Of course not. Development of AVs will accelerate. But without a clearly defined regulatory landscape, coupled with exceedingly strong pressures from consumers and competitors alike to deliver to market, there’s inevitably a risk that we’re going to see human error lead to deployment of unhealthy code.
The potential cost to human lives alone is one thing, but as the Jeep incident shows, there are financial losses too: data breaches cost businesses an average of $4.35 million in 2022. And with that comes reputational damage, not to mention slowed delivery of products and services as issues get rectified.
The attack surface is getting wider too. We’ve seen with the rise of attacks in open-source software how even the critical vulnerability exploitation of the Apache Log4j library found in innumerable software products could affect devices or properties found in or used for cars. These include chargers, in-vehicle infotainment systems and ‘digital remotes’ for opening cars.
Cyberattacks aren’t the only threat to car safety
Car safety isn’t just under threat from malicious actors exploiting code. Code quality and its reliability matters just as much when it comes to avoiding software faults that could result in unacceptable harm to people. We call this functional safety.
Consider that a single car built today can have as many as 150 electronic control units (ECUs). In other words, the ECU is a small computer that controls a particular function in a car. Before ECUs, mechanical systems used ignition timing, fuel, air and engine rotation to control the vehicle, but now it’s all programmed inside the ECU.
Of course, the last thing you want when driving is for a bug to cause your car’s dashboards, navigation and safety systems, or worse - the brakes and engines - to fail in the middle of a highway. And if we’re going to avoid these nightmarish situations, in addition to ensuring the best functionality and usability, car manufacturers must treat software testing with the same rigour they apply to testing mechanical parts and systems.
Testing and validation
Now, traditional automotive testing of parts has typically been costly, time consuming, and not exactly easily repeatable, but on the software front, things are a little different. In fact, there are some great solutions developers use in the sector: namely Software in the Loop (SIL) and Hardware in the Loop (HIL) testing. And these are being incorporated into the modernised approaches to software development that are seen with the new software-defined vehicle (SDV) initiatives.
SIL is an approach through which code can be tested periodically as each segment of a program is completed, rather than waiting for the final build. It separates software from hardware development so software developers can continue to innovate beyond the hardware industry’s pace. Tests can be automated, even run simultaneously, and it’s easily scalable and far faster than manual testing.
HIL, on the other hand, is a method of testing and validation related to the pieces of hardware in a vehicle. It more or less simulates models of the final product, to then be thoroughly tested before connecting the real ECU to the test system. HIL test benches emulate actual car engine and vehicle dynamics through real-time execution of mathematical models, using data input from devices like cameras and radars. This is generally done after SIL testing because HIL is more costly and time consuming.
“Software needs to be designed with safety in mind from the beginning”
Each product’s function in any vehicle (safety critical, mechanical, aesthetic, etc.) will require bespoke amounts of safety testing. For example, OEMs producing braking systems may need complex HIL testing, whereas, infotainment or navigation systems may only require SIL testing. But regardless of which function it is, developers are absolutely going to have to make sure they’re keeping up with best practices in software testing, no matter the product.
More to the point, manufacturers will have to enforce more repeatable, consistent ways of doing things. You don’t create safe software if you’re a cowboy coder, and regulations around testing on both hardware and software components of a vehicle have become much more rigorous of late. See for example, the main legislative requirement for automotive safety: ISO 26262: Road vehicles — Functional safety, which applies to mass-produced passenger cars, as well as provides guidance on E/E systems in buses, trucks, trailers and semi-trailers. But equally, there’s ISO 21434, which focuses on cybersecurity in the design and development of automotive software and subsystems.
Safety requirements must be tackled
At the end of the day, software needs to be designed with safety in mind from the beginning. It’s not only extremely difficult, but no longer acceptable in today’s age, to try to build a truly safe system by addressing safety as an afterthought. Ahead of the connected car revolution, manufacturers must tackle safety requirements at the architectural and design stage, not at the end of the product life cycle.
ABOUT THE AUTHOR:
Patrick Shelly is Qt Group senior director, solutions engineering and design
