Smart Products Highlight Complex Defects!

I recently purchased my first new vehicle in several years. I’ve got to tell you, it’s a technological marvel. It has a touch-sensitive display and controls, cameras, sensors, collision avoidance, dynamic cruise control, an infotainment system and heated and cooled seats. It included everything but a navigation system, which I didn’t think was necessary because I have an iPhone with the Google Maps app.

My wife drove the new truck a few times, and I’d get a frantic call each time she left with it: she was lost, again. My wife doesn’t have a great sense of direction. So I took my vehicle back to the dealer, and for a few hundred dollars, the technicians flashed the navigation software on it.

To test the system while I was at the dealer, I programmed it with my home address. It worked perfectly and took me right to our driveway. Then I pressed the button on the overhead console to open the garage door, but it didn’t open. I thought the power was out or the door opener stopped working. I saw the lights on in the house, so I knew we hadn’t lost power. I hit the garage door button in the house and the door opened. But when I got back in the truck and hit the door opener button on the console – nothing.

Something went wrong during the flash process and the door-opener button had been disabled. The other infotainment settings were fine, it was only the opener that didn’t work. These were items I didn’t think were related. But for performance or communication reasons, these items became examples of how software functions spread across a number of seemingly unrelated processors have become interdependent.

What’s Behind the Rise in Product Defects and Recalls?

Software-driven electronics is quickly infringing on hardware’s dominance in the product development process, so my story isn’t that unusual. Virtually all products today are software-enabled products, and things are rapidly advancing. Within 15 years, between 15 and 20 percent of all vehicles on the vehicle on the road could be fully autonomous, according to Strategy Analytics. Advanced Driver Assistance Systems is also one of the fastest growing segments in automotive electronics.

These developments make life better now than it has been at any other time in history. But the news isn’t all roses. The year 2015 was a record year for product recalls, and a high percentage of those recalls focused on software issues.

According to the U.S. National Highway Traffic Safety Administration, the auto industry recalled almost 50 million vehicles in 2014, and the recalls in 2015 have surpassed 2014’s record. Financial advisory firm Stout Risius Ross has discussed this ongoing surge in vehicle recalls. The firm says that there are likely a number of factors contributing to this rise in recalls, and “a larger factor at play may very well be the increase in vehicle technology and component complexity.”

What Can Companies Do to Prevent Product Defects?

This increase in recalls should concern companies. What can these companies do to prevent product defects? Is product lifecycle management, or PLM the answer? Yes, and no. Is application lifecycle management, or ALM, the answer? Yes, and also no.

Let me explain. When you think about product failures or recalls stemming from software, it’s important to understand there’s really no such thing as a “software-only product.” All software needs hardware to run, and most of today’s products have software embedded into electronics processors that control other hardware actions. It’s the Why do software Bugs Continue to Plague Productsthat increases product complexity and contributes to the rising number of recalls.

There’s also an increase in multi-system, multi-domain dependencies. There are multiple design domains, controls and interfaces spanning multiple sub-systems and functions many of which are developed by suppliers that must be integrated. Because of this increase in complexity, there’s a greater need to enable extensible architectures and leverage variant-aware design processes, which spans the hardware and software boundary and necessitates cross-domain testing, verification, and validation.

So what’s the best way to address these challenges? You need more than PLM – you also need ALM. PLM, or Product Lifecycle Management, manages a product’s entire lifecycle, including its inception, design, manufacture, maintenance, service and disposal.

To handle your software, you need ALM. ALM is the PLM of application software. It encompasses requirements management, software architecture, computer programming, software testing, change management, project management, release management, software maintenance and delivery; enabling manufacturers to define, build, test, manage and deliver complex software systems more efficiently and effectively.

PLM and ALM both offer valuable and necessary capabilities, but neither can address these challenges with increasing complexity on their own. Integration of the two is what we’ll talk about in this blog series.

This concludes part one of our series on integrating PLM and ALM to address increasingly complex systems. In part two, I’ll discusses how ALM and PLM complement each other and what companies must do to achieve true ALM and PLM integration to reduce and prevent product defects. Stay tuned.

About the Author

Dennis George is a marketing manager for Siemens PLM Software’s Teamcenter PLM software. He has more than 30 years of experience in managing software products, electronics packaging and marketing of Electronic Design Automation tools. Dennis has held marketing management positions at Magma Design Automation and Silicon Metrics Corporation, where he was responsible for marketing characterization and analysis tools used in the development of semiconductors. As a marketing manager at Xynetix, he managed a suite of tools used for semiconductor packaging, printed circuit board layout, data verification and assembly. At Zenith Data Systems, he was responsible for electronics packing. Through his involvement with a number of market segments, Dennis has gained valuable insight into the issues, flows, and processes employed in the design and manufacturing of software-driven electronic systems and components. He has a B.S. degree from Eastern Michigan University and an MBA in marketing and computer science from the University of Rochester.