Skip to main content

Software is at heart of safe vehicle connectivity, says Qt Group

Connected vehicle safety isn’t just under threat from malicious actors exploiting code – it’s also about avoiding software faults that could result in harm to people, says Patrick Shelly of Qt Group
September 15, 2023 Read time: 6 mins
Car safety isn’t just under threat from malicious actors exploiting code (© Creativeimpression | Dreamstime.com)

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

 

Related Content

  • June 18, 2024
    Crossing the line: managing traffic across jurisdictions
    The US will eventually have a fully-digitised transportation network, with traffic management devices talking to each other across massive distances. It’s really a question of pain points on the road to full deployment, explains Mark Talbot of Q-Free
  • September 28, 2020
    The benefit of Lidar: touch, don’t look
    The benefits of Lidar as a safety device for automobiles rather than as an enabler for AVs are easy to overlook – but Dr Jun Pei of Cepton Technologies tells Adam Hill why that would be a big mistake
  • September 30, 2016
    Connected-car security market expected to reach US$759 million in seven years
    With nearly 112 million vehicles now connected around the world, the global market for automotive cybersecurity is expected to grow exponentially – to US$759 million in 2023, according to a new report, Automotive Cyber-security and Connected Car, from IHS Automotive, part of business information provider IHS Markit. Connected cars are defined as those that have a connection to the internet, through telematics, an onboard modem or a paired device in the vehicle, such as a mobile phone or other device. One
  • August 20, 2019
    Aptiv: we need overhaul of AV nervous system
    Autonomous vehicles are changing a lot of things: Aptiv’s Christian Schäfer suggests that we need to look again at traditional approaches to vehicle architecture to find viable options for the future