Today is my car’s birthday. Since I brought it home, my little Honda has gone over 150,000 miles in seven years of service – much to the disbelief of friends who know my checkered past of vehicle ownership. I remember buying my car – at the time, it was the nicest thing I’d ever owned. Brand new, shiny and the peak of technology. Well, except for its manual transmission, a singular point of pride.
For me, one of the Honda’s main selling points was its i-VTEC engine. The i-VTEC, or Intelligent Variable Valve Timing and Lift Electronic Control engine, was pretty revolutionary – electrical controls integrated with the mechanical engine to help it perform better. Don’t get me wrong, the redhead in the driver’s seat just heard, “More power, less fuel.” But if you ARE interested in how the VTEC actually works (adjusting the camshaft in response to rpm ranges), there are some pretty cool explanations here and here (with animation).
To celebrate my car’s birthday, I MAY have done a little research into a new car – I plead the fifth on that one. In any case, it’s an interesting comparison between what was cutting edge seven years ago, and what’s possible in automotive engineering today. My classic mechatronics example of the circa 2005 VTEC engine seems a far cry from complexity in the current world – where new vehicles can have millions of lines of embedded software code on 50 or so ECUs.
And it’s not just cars that are becoming more complex – as explored in recent posts on embedded software in our daily lives and technology-enabled products. Our very definition of “product” is changing – as more and more functionality is derived from connections to external systems and independent applications. Even tractors aren’t just tractors anymore – they are now high-tech, connected agricultural farming solutions.
With integrated hardware, software, and electrical systems, product complexity means the potential for some amazing benefits to us consumers on the buying side. But product complexity also means increased product development complexity for manufacturers. And with that complexity comes a host of new challenges.
Take change management as an example. Change management is an integral part of both software and hardware development – but how this process is executed in each discipline varies greatly. While I’m not calling mechanical engineers slow (despite my friend Geoff Hedges, editor of PTC’s Creo blog, informing me that, at least to the British, insults are a sign of affection), software design has a frequency of testing and iteration that is off the charts in comparison. A software engineer might change the same five lines of code 20 or more times – testing at each change. Multiply that by a few million lines of code and suddenly a few dozen design versions in a 24 hour stretch seems sorta reasonable, right?
So how do you make sure that changes are communicated between software and mechanical engineering, without overwhelming mechanical engineers or under serving software engineers? How do you make sure that at any given time, suppliers and partners know that the version of the model they’re working on is the absolute latest and up-to-date?
If product complexity makes the product development process more challenging it also makes it more critical. Complex products can make even diagnosing product defects exponentially more difficult – like hunting for a needle that could be in any NUMBER of haystacks.
As Develop3D’s Al Dean explains for our benefit:
Complexity has always been part of the product development process, but today’s world is seeing ever more complex products brought to market. The clichéd example is the cell phone. It’s not just a phone anymore: it’s a camera, it’s a wireless computing device, it’s a GPS and mapping system. It just happens to make phone calls as well. And a lot of its functionality is provided via a discreet supply chain: Bluetooth chips from one source, display and input technology from another – Rinse. Repeat. All need to work together in a tight form factor. And if something goes wrong, tracking down the source of that failure is nightmarish at best. Is there a mismatch between two sub-systems? Has there been a thermal event that caused an electronic failure? Are the PCB traces fractured? Add in the software element and there’s a dramatically larger potential for error than the humble home telephone of yesteryear. Complexity is becoming overwhelming. And that isn’t likely to change any time soon.
So in a complex system, it’s not only really hard to design the product, it’s also really hard to figure out what the issue is when something goes wrong (although in Al’s scenario, it’s most likely that his phone’s just been watered with the tomatoes). Think about this – when the NHTSA was evaluating concerns about Toyota braking systems, they needed to solicit help from NASA. I’m pretty sure NASA deals with…um…rocket science, which puts that complexity into perspective. And for the buyer with a product issue difficulty in diagnosing issues equates to time waiting for the problem to be solved. That’s not just a problem for the buyer – that’s a problem for the brand. Waiting causes frustration, and with the advent of social media, today’s buyer has a forum to voice that frustration.
So with great innovation comes… great responsibility? Or something like that. In any case, I’m excited to see what’s around the corner. Especially if it makes my car go faster.
I’d love to hear from you – what do you think are the biggest impacts of product complexity on product development? What are the biggest challenges when combining software system lifecycle management and mechanical design? And what Honda should I get next?