In this post, we’ll briefly discuss the automotive software industry outlook, recent automotive software advancements, legislative regulations around automotive software testing, and how companies with products that contain GUIs can use automotive software testing to remain competitive in an increasingly unstable and challenging market.
The automotive software market is expected to grow rapidly by 2030, with projections showing it will increase from $31 billion (2019) to approximately $80 billion. This translates to a CAGR of over 9% across the market, and more specifically, 9.1% for Infotainment, connectivity, security, and connected services.
This means that the automotive industry, like many others, is experiencing unprecedented levels of innovation, technological advancement, and in turn — competition. And while the manufacturers of vehicles and their parts race to stay profitable and at the top of the curve, the battle is being won in the background, over lines of code.
When most people think of automotive testing, images of crash tests, speed tests, and other mechanical interventions come to mind. Though, in reality, most automotive testing happens long before car parts come together.
A single car has about 30,000 parts, which are supplied by dozens of Original Equipment Manufacturers (OEMs) that collaborate together to create the vehicle. Each part, whether hardware or software, is tested hundreds of thousands of times before the final assembly of the car, and even more before it hits the road.
The cars on the road today, both your standard sedans and top-of-the-range performance vehicles, are driven by software. For a vehicle built in 2022, it’s possible to have as many as 150 Electronic Control Units installed.
An Electronic Control Unit (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 complete functions. Now, everything that needs to happen is programmed into the chip inside the ECU.
Some examples of ECUs you can find in a car include critical-function ECUs like the engine control module (ECM) and brake control module (BCM) or non-critical ECUs like the ones inside the car’s info-navigation system, or in the general electronic module (GEM) that controls functions like locking and unlocking doors, opening windows or controlling the air conditioning.
Considering that each Electronic Control Unit is functionally a tiny computer, rigorous software testing must be conducted to ensure its functionality, usability and safety.
The reality is that traditional automotive testing is expensive, time consuming and not easily repeatable — so of course, we have technology to thank for an answer to the problem: Hardware-in-the-loop (HIL) and Software-in-the-Loop (SIL) testing.
Software-in-the-Loop testing tests and validates software’s code in a simulation to squish bugs, improve code quality and significantly reduce build time.
As car brands and OEMs continue to innovate to gain a competitive edge, the real battle is won over lines of code. Regardless of the type of product (safety, dashboards, navigation systems, or others) software must be tested extensively before being approved for use in a vehicle.
Some benefits of SIL include:
HIL testing is, as it sounds, a method of testing and validation related to the pieces of hardware in a vehicle. These simulators are more or less models of the final product, which are then thoroughly tested before connecting the real ECU to the test system.
HIL test benches emulate actual car engine dynamics through the execution of mathematical models in real time, using data input from devices like cameras and radars. Generally, HIL testing is more costly and time consuming than SIL testing, so it’s done after SIL testing.
Automotive software testing is important for reasons other than purely on-road safety — for example: cyber security, OEM trust and reliability, and car brand health and image.
Naturally, the regulations around testing on both hardware and software components of a vehicle are rigorous.
The main legislative requirement for automotive safety is 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.
ISO 21434 is a follow-on standard based on ISO 26262, except it specifically focuses on cyber security in the design and development of automotive software and subsystems. Topics covered in this standard include risk management and mitigation, risk assessment, continued security, security management and more.
AUTOSAR stands for AUTomotive Open System Architecture, “a worldwide development partnership of vehicle manufacturers, suppliers, service providers and companies from the automotive electronics, semiconductor and software industry”. The aim of AUTOSAR is to create a worldwide open and standardized software architecture for automotive ECUs. While OEMs and manufacturers are not required to participate in or comply with AUTOSAR architecture, many of the world’s leading companies do.
MISRA is an automotive safety organisation made up of suppliers, engineering consultancies, static code analysts and OEM manufacturers. First published in 1998, their coding guidelines now cover systems build on C and C++ coding languages. Again, while MISRA is a non-mandatory set of standards, it is widely adopted across many industries as it facilitates the development of safe, secure, and portable code for safety and security critical systems.
While the product’s function in the vehicle (safety critical, mechanical, aesthetic) impacts the level of safety testing required, best practices in software testing are consistently applied, no matter the product.
What does need to be considered on a case-by-case basis is what tool is right for the job. For example, OEMs that produce braking systems may need complex HIL-testing, while infotainment or navigation systems may need only SIL-testing.
Squish is an automated GUI testing tool for cross-platform desktop, mobile, embedded and web applications. In terms of automotive testing, Squish is generally used for testing navigation systems, touch panels, dashboards and front panels.
User interfaces are getting more and more animated, with graphics moving fast with incredible levels of animation. In this way, testing from the GUI perspective is challenging because everything is constantly changing, and you need to ensure the state of the application and your test are synchronized.
If we consider the animations as a human, testers would need to manually take a screenshot, then compare if an indicator is in the correct place, right colour, being animated at the correct speed (if it is intended to move)
With Squish, our goal is to emulate end-user behaviour. Squish automatically interacts with the application exactly the way the end user would do (click, drag, drop, touch). Squish can also take screenshots to check the current state of the application, and if the images are rendered the way the design and development teams intended.
Squish features that mitigate risk include image-based testing, that use multiple verification points that check if the visual appearance is as expected. It also supports Optical Character Recognition (OCR) engines that help verify if text and numbers are displayed on the screen as intended.
Want to see Squish up close? Get your free trial right here.