Posted by Tom De Schutter on May 31, 2015
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.
Patrick Sheridan is responsible for Synopsys' system-level solution for virtual prototyping. In addition to his responsibilities at Synopsys, from 2005 through 2011 he served as the Executive Director of the Open SystemC Initiative (now part of the Accellera Systems Initiative). Mr. Sheridan has 30 years of experience in the marketing and business development of high technology hardware and software products for Silicon Valley companies.
Malte Doerper is responsible for driving the software oriented virtual prototyping business at Synopsys. Today he is based in Mountain View, California. Malte also spent over 7 years in Tokyo, Japan, where he led the customer facing program management practice for the Synopsys system-level products. Malte has over 12 years’ experiences in all aspects of system-level design ranging from research, engineering, product management and business development. Malte joined Synopsys through the CoWare acquisition, before CoWare he worked as researcher at the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany.
Tom De Schutter
Tom De Schutter is responsible for driving the physical prototyping business at Synopsys. He joined Synopsys through the acquisition of CoWare where he was the product marketing manager for transaction-level models. Tom has over 10 years of experience in system-level design through different marketing and engineering roles. Before joining the marketing team he led the transaction-level modeling team at CoWare.