Traditional testing practices are outdated and should be reformed to intensify software development, believes the ex-chief vehicle engineer and CTO.
Overall vehicle development timing plans or master schedules are defined by what Americans call the ‘longest poles in the tent’ – the long-lead-time development activities that define the critical path
from project kick-off to the final, joyous day of start of production or job one. And those tests have not evolved much over the decades – they are still generally in one of three categories: ‘critical’ tests that must be carried out on prototypes before launching production tools; long duration by their very nature; or dependent on specific seasons.
Crash tests are the best example of the first category. For many years, crash test results were so unpredictable that manufacturers would build fully soft-tooled vehicles and slam them into various barriers before being confident enough to pull the trigger on production tooling. There are many examples of long-duration tests – vehicle durability, UV exposure to validate paint and plastics, even powertrain ‘tuning’ or calibration programs. And of course, the best-known example of seasonal testing is the mandatory sliding-around-the-frozen-lake ABS and ESP calibration that has become a fixture in every vehicle program.
For years, vehicle chief engineers or program line directors – or whatever title the big engineering cheese carries – have constructed and signed off vehicle program timings based on these time-honored tests and the critical paths they generate.
But I’d like to put it to you that it’s time to rewrite the master schedule playbook.
Why? Well, first, the ‘traditional’ tests above rarely drive the true critical paths of modern vehicle development. Crash structure simulation has advanced to a point where there are few surprises anymore
in the physical test stage. This is arguably less true for durability tests, but it’s still rare these days for a program to encounter a major unexpected mechanical durability failure late in testing. I will push my point now by venturing onto dangerous ground, to suggest that even the sacrosanct two-winters-on-the-frozen lake might be less justifiable now than it was 20 years ago – a combination of simulation and testing on other low-µ surfaces can probably set a car up well enough to replace even this immutable event on the automotive calendar.
So, what are the true critical paths these days? Achieving the very high modern consumer expectations of perceived quality or craftsmanship is undoubtedly one, but here I’d like to concentrate on another – one that poses a real management challenge as well as a technical one.
The modern longest-pole-in-the-tent is a very complex pole indeed, capable not only of poking a hole in the tent fabric if carelessly handled, but of bringing the whole construction crashing to the ground. It is software – or more precisely, inter-system software quality. We all know the mind-boggling statistics about the number of lines of code in a modern car. We know about the challenges and opportunities presented by OTA technology. But many vehicle manufacturers still get it wrong – regularly, and publicly. The mighty VAG dropped the ball very publicly indeed with “massive” software issues delaying its much-awaited ID.3 last year. Ford had a similarly embarrassing problem at the launch of Mach-E. But VW and folk need not blush. I’m confident that every OEM runs late these days due to late software issues. The weeks, days and even hours up to SOP of every new car launch are a desperate scramble to track down and patch the latest rash of bugs, and I would suggest that it’s probably the same in every automotive manufacturer and every production plant in the world.
I don’t have the space – or, frankly, the expertise – to speculate here on how this should be solved. But I would suggest one, exceedingly difficult measure. Chief engineers and program directors need to let go. Most of us are forty- or fiftysomething males. Most of us are not software engineers. I am slightly unusual in that I am an electronics engineer, but the last complex lines of code I wrote personally were in Fortran (ask your dad, or Google it)! We understand the ‘traditional’ critical paths very well, through decades of experience. But let’s be honest with ourselves: We simply do not understand the software challenge. We are not ‘digital natives’ and have not had the opportunity to understand the vast power and complexity of modern software systems through designing them ourselves. So, we must do something very difficult for us alpha-male leaders: Let go. Delegate. We have to find a way to trust the up-and-coming generation of engineers who simply have a better grasp of the technology. So, let’s try to stop building master schedules around winter testing and durability cycles, and instead ask our young and brilliant software folk to help us trace out the true critical paths.
