Application & Product Lifecycle Management: An Integration Path

If you’ve noticed a higher number of recalls making the news, you aren’t alone: manufacturers are also noticing it. Many recalls are due to software issues which are the result of the increased product complexity and the combination of software and hardware. This trend isn’t going away, so what can companies do to reduce or prevent product defects that lead to recalls?

In my series about integrating application lifecycle management (ALM) with product lifecycle management (PLM), I explore why this rapid advance of software-enabled products is contributing to increased product recalls. In part one, I explained why companies can no longer use only ALM or only PLM to manage increased product complexity.

Here, I’ll discuss why ALM integration with PLM is the best solution to manage product complexity and the five factors companies must include to achieve full ALM and PLM integration.

In today’s complex product development environments, ALM and PLM play important roles in the development process. Each has its strengths and weaknesses, but each complements the other well.

PLM systems manage, link and relate objects or information as parts. ALM manages software files and relates information based on those files; this includes software code, change requests, builds, test cases and comments.

Software exists in the PLM world as a single part, but the level of management frequently ends there. This is because PLM systems typically don’t provide configuration management for software files and any changes made to them throughout the software lifecycle.

Hardware and software development teams frequently employ different development methodologies. Hardware teams frequently employ a “V-model”, Waterfall or Spiral methodology where content it defined and processes for verification and validation are executed somewhat sequentially. Software teams frequently employ an Agile methodology takes advantage of varying requirements and supports the rapid delivery of incremental features.

Hardware and software also have different lifecycles. A product’s lifecycle can span several years with relatively infrequent modifications that can take a few months to over a year; maintenance and service cycles can last for many years. The software lifecycle typically spans several months to a couple of years. It includes frequent modification cycles that last a few days or weeks; the maintenance and service cycle may only last a few years. Because there’s such a difference, hardware and software components must be linked and managed to ensure long-term compatability – which effective ALM and PLM integration does.

PLM deals with hundreds or thousands of product options or variants, so configuration management is an extremely complex undertaking. In the ALM world of software management, there are generally only a few branches or versions to configure. When hardware and software are combined there are so many variants and options that it’s difficult to understand, manage and verify them all without good ALM integration with PLM.

A good example of this is when a salesperson I know purchased a new vehicle. A warning indicator started chiming after a few days; it was detecting the failure of a vehicle option that wasn’t even installed on his vehicle. The software on his vehicle detected an error code on the electrical control unit (electronics) because the wire-harness connector (electrical) wasn’t attached to the hardware for that option. The vehicle’s product configuration hadn’t been fully understood, tested and verified. Had the ALM and PLM processes been fully integrated, all viable hardware and software configurations could’ve been understood and validated, thus eliminating this error.

How to Implement True ALM Integration with PLM

What’s necessary for a truly integrated ALM and PLM solution that helps companies reduce or prevent product defects? Effectively embedding software in any product requires ALM integration with PLM rather than trying to expand each solution’s definition to include the other’s capabilities.

To efficiently develop embedded systems, a truly integrated solution can:

• • Reduce costs by incorporating your chosen tools, data and processes.

• • Increase productivity by understanding product relationships, avoiding hardware or software integration issues and enable the user to work in a familiar context.

• • Improve quality by intelligently assessing how software and hardware dependencies would impact changes across the product.

• • Accelerate delivery by establishing an efficient closed-loop “Define-Model-Develop-Build-Test-Release” process for continuous multi-domain delivery.

True ALM integration with PLM requires and supports five factors.

An open approach to tool and process integration. This approach enables hardware and software teams to use the tools they need for their job functions, enabling both design groups to share data and gain product visibility.

Work in a familiar context. Engineers and product managers must be able to use the tools and environment they prefer to author, search, view and edit data or execute workflows and hardware/software development processes. They must be able to define and manage calibration and configuration-related software parameters for multiple products to use or re-use. They must also manage the released binaries the same way as other multi-domain design data.

Link and trace. Engineering must have the ability to trace and link software and hardware objects across domains. To deliver testable, high-quality systems, design teams must fully understand the product’s requirements and dependencies across all domains, including mechanical, electronic and software. It must ensure bi-directional referencing needed for verifying software requirements satisfy product requirements and vice-versa.

Assess and quickly respond to change. Linking and tracing design objects is critical to being able to assess and having quick responses to change. A complete multi-domain change management process should identify all the affected software and hardware objects; that way, you can assess them in the ALM or PLM environment and delegate to the appropriate ALM or PLM team.

Continuous multi-domain delivery of tested and verified software and hardware. When the design is complete, or changes incorporated, you must be able to manage the constant delivery, across multiple domains, of software and hardware that has been tested and verified. This requires streamlining operations to iteratively and automatically create software builds, run the right test procedures, track defects discovered during the test and automatically deploy software to the factory floor or service center.

Managing change and compatibility across the matrix of dependent software and hardware components can reduce design-to-deliver cycle times and provides higher product quality. This ability gives manufacturers a better way to correct or prevent product defects.

This concludes part two of the series on how ALM integration with PLM helps companies manage increasingly complex systems. In part three, I’ll provide examples of current auto OEMs that show what the future holds if you understand how software and hardware work together.

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.