Lazy Or Bored: The Outcome Might Be The Same

I recently talked to an engineering manager responsible for system validation at a major automotive company. The topic was the continuous growth of software content and how to reach the right software quality. He explained that for the part he is responsible for, most software is created by his suppliers. But because the carmaker is ultimately held responsible for any issue with the car, he has to define rigorous requirements that suppliers are required to meet. This applies to both the hardware and software that is delivered to him.

The suppliers need to provide a test report with every deliverable. The carmaker reviews the test report and asks clarifying questions to ensure that all requirements are met, plus his team performs additional tests, focusing on corner cases that they have learned about from past experiences.

While testing in general is something that most engineers dread, they understand that it is an important part of the overall development process. So a lot of time and effort goes into writing and running tests. But the problem is that not every piece of hardware or software is easy to test, especially when it comes to interfacing with people or with other sub-systems. In an effort to prevent issues from happening when the end product is used in its target environment and will be subject to inputs from people, engineers try to capture the most realistic scenarios possible. That typically means exercising scenarios by having it actually interact with persons or with other external stimuli. This makes for some important real-life testing.

But here’s the catch: People get lazy. Or maybe more accurately, people quickly get bored with doing the same thing over and over again. This is how the system validation manager at the automotive company described it to me: ‘When we need to have manual tests for a particular piece of hardware or software, we have to continuously rotate the engineers who perform the test.’ He had observed that after performing the same test more than two times, his engineers start to do things slightly differently. They assume that a particular piece of the test is less important because it worked yesterday and the software change was really not that big. All of us take shortcuts because we get lazy or bored. If something worked for the last 37 times, why wouldn’t it work for the 38th time? So the system validation manager’s goal is to automate all tests, as much as possible, and he asks his suppliers to do the same.

The problem is that not every test is that easy to automate. In automotive, as in other markets, first hardware is rare and expensive and it functionality typically cannot be fully automated. This was exactly why I was meeting the system validation manager at the automotive company in the first place, which brings us full circle. He was very excited about the fact that virtual prototypes can offer an alternative to the hardware, and as such enable earlier, broader and more automated software testing. Combining additional control and visibility capabilities with better scalability makes virtual prototypes the ideal “vehicle” to further automate tests for the vast amount of software that makes its way into our cars.

Car manufacturers and their supply chain are embracing virtual prototypes as a way to create more, better and above all automated test suites for the software in your future car. As an added bonus, this enables their engineers to focus on innovation instead of getting bored running the same tests over and over again manually. That is what I call progress.