Is PLM Up to the Digital Thread Challenge?

At first glance, product lifecycle management (PLM) systems seem to be the perfect vehicle for creating and managing a digital thread and the corresponding digital twin. Viewed through the lens of the trend toward digitization, however, that assumption becomes less than certain.

The underlying factors contributing to this uncertainty lie in the metamorphosis of software and the fundamental nature of traditional PLM offerings. As a result of this uncertainty, software vendors and design engineers have begun to reevaluate PLM’s role in the digital thread toolchain. 

The question has become: Are these platforms the ultimate environment in which to pursue thread development, or is PLM just one element of a larger solution (Fig. 1)?

Catalysts for Change

To understand the question, it’s imperative to look at software’s new place in the hierarchy of design considerations. The proliferation of smart products and the emergence of the Internet of Things have turned the value proposition of products upside down. 

Software is quickly surpassing hardware’s dominance in the product development process, particularly in complex cyberphysical systems and industries such as automotive, aerospace, defense and medical devices. 

Today’s products heavily leverage software to drive functionality, improve user experience and enable continuous product refinement throughout the asset’s service life. This expanded ability to add value to a design has greatly altered the dynamic between software and hardware, making embedded code a defining factor in many a product’s success.

On the other hand, traditional PLM systems have long drawn their strength from hardware engineering competencies and their ability to support the physical design and manufacture of products. When these systems are required to manage software development processes, however, they fall short.

“PLM systems rooted in mechanical design structures and assumptions will fail because adaptation will require fundamental redesign of the platform’s core,” says Mark Reisig, director of product marketing at Aras.

Current demands find that traditional PLM platforms simply cannot meet all of the new challenges presented by digitization. For example, when the digital thread concept gained traction, many PLM systems were geared more toward playing the role of product data management systems, with emphasis on managing CAD files and revisions. 

Consequently, when engineers tried to adapt these systems to thread applications, they often ran into problems with sophisticated software use for many of today’s products.

“Traditional PLM systems typically manage software as a ‘part’ in the context of the product manufacturing process and have struggled with the management of software’s complex agile development processes,” says Mark Sampson, systems engineering expert, Siemens Digital Industries Software. 

“Software has its own distinct lifecycle—with different information that needs to be managed, different collaboration processes and methodologies, different specifications and items—a lifecycle that has historically been insufficiently addressed by traditional PLM systems,” Sampson adds. “As a result, software cannot successfully be developed and managed in a PLM system unless processes and methodologies are aligned.”

The Software Difference

Given these new conditions, the first step in determining PLM’s role in a digital thread is to see how software design and development techniques differ from those of hardware, and to understand how much software developers rely on specialized tools and practices. The differences come into focus when comparing the overarching perspectives of the two design domains.

“The development of software mainly focuses on the language used to code and evaluate the program and interface, while the actual parts development leans more on computer-aided design,” says Hedley Apperly, vice president of solutions management, Integrity, at PTC.

A case in point is 3D modeling. This technology works well with physical parts. Software, however, is intangible, so modeling languages such as the Unified Modeling Language are more applicable. Designers also use standardized development languages to automatically generate source code, in a conceptually similar way to the pairing of 3D modeling and 3D printing.

Software development also uses different practices. For instance, Agile software development methodologies leverage iterative regimens meant to help teams create faster, more efficient software development cycles. This work is accomplished by creating fundamental groups of professionals known as SCRUMs.

Each SCRUM works on a rapid development process called a sprint, which focuses on specific goals. Sprints commonly last 30 days. During this time, the SCRUM calculates its progress. Upon completion of the sprint, the engineers begin the next wave of software development. In many cases, sprints also focus on a minimum viable product to prove out a technology. The SCRUM then rapidly iterates the functionality though additional sprints to optimize the code.

“From a mechanical or electrical perspective, the Agile methodology largely fails to be useful,” says George Lewis, vice president of business development and strategy for Arena Solutions. 

“Where software development is simple from a logistical perspective, physical components require the consideration of logistics to assemble components and typically involve creating prototypes, often by an outside source,” Lewis says. “Generally speaking, the fundamental processes of Agile methodology fall apart in hardware development because the concept of a sprint cannot be reasonably accomplished, especially in the later stages of development.”

Timing Is Everything

The Agile methodology highlights a major point of contrast between software and hardware development—the fast pace of software development. The disparity between the two disciplines’ development rates has proven to be a major hurdle for integrated development projects and drives home the necessity of discipline-specific tools and practices.

During software development, code changes rapidly and revisions occur frequently. In fact, engineers continually push the envelope in this area using specialized tools for automated compilation, building, integration and testing. These technologies all seek to improve software engineering productivity.

This clash of cycle times also requires tools that provide a high level of integration of the two development processes. 

“To manage software development successfully, a tool must align the release cadence and requirements between the software and hardware teams,” says Josh Turpen, chief product officer at Jama Software. 

“This can be difficult because for software the cycle time between deliverables is incredibly fast by hardware standards,” Turpen adds. “Coordinating these disparate cycle times is critical to the success of a joint release. Idle time between the two units is not only costly, but an invitation for requirements drift that will cause testing delays and, eventually, delivery delays.”

Adding to the Mix

Upon reviewing the ways software development differs from its hardware cousin, it becomes clear that another toolset must be used with PLM to effectively handle the software side of digital threads and digital twins.

A likely candidate for this role is application lifecycle management (ALM). In many ways, these software tools can be viewed as PLM for software. For example, similar to PLM, ALM encompasses the entire software development lifecycle, from requirements management through development, testing and maintenance of software products. Application project and portfolio management, integrated data management, design and use-case analysis, build and release management, collaboration, traceability and reuse—these aspects are all incorporated in an ALM solution. However, these standardized tools and systems have specific software management capabilities (Fig. 2). 

Using ALM systems for software is similar to using product data management vaults for work-in-process, mechanical designs, or a component library for electrical design purposes. Each is a point tool that serves specific engineering design teams and makes for a logical endpoint where data can be transitioned to PLM once ready for an extended product team discussion and final approval.

It seems that the best approach to managing software development is through something like an ALM solution. What is less clear, however, is how to best integrate the two systems (Fig. 3). Depending on the company’s perspective, there is more than one way to reach this goal.

“We recommend one of two approaches,” says Lewis. “Companies can connect the two systems through manual integration when code is published, or use an automated integration that can synchronize the released code. In either case, the responsible teams can collaborate around design, quality and bug-related issues that require synergy across the software and mechatronic teams—not just the software design team.”

Playing to PLM’s Strengths

Whichever integration approach a development team adopts, it should ensure that all design domains are tightly woven into a single fabric, driven by a cross-domain product architecture that acts as the blueprint for collaborating on hardware and software development. To do this, the system or approach must cover several key facets.

For example, ALM and PLM need links to a single source of higher-level system design and to the requirements for those designs. Furthermore, all lifecycles must run in parallel so that interfaces connect and changes can be assessed and applied as the designs evolve. 

In addition to the testing of the individual parts, designers should also be able to test the whole product to verify that it works in its intended environment. This includes ensuring that the integrated system provides for ongoing maintenance, servicing and upgrades.

One way to implement these features is to leverage PLM’s inherent capabilities. 

“PLM is best suited to take the finished designs from each design team’s system of choice and marry them together in a single system of truth,” says Lewis. “While engineering teams create, review and approve designs in ALM, CAD and EDA [electronic design automation] applications, these systems are not intended for use by the larger product teams outside of engineering. 

“This is where PLM comes into play, to not only provide a single system to evaluate the entire design but also a single system that enables interaction via the cloud among internal teams—like quality control, procurement and manufacturing—and external design partners, suppliers and contract manufacturers,” Lewis adds.

Additionally, problems that span hardware and software design need a unified PLM system that allows the evaluation of interoperability, identification of issues and updating of designs in ALM, CAD or EDA tools as ongoing changes are introduced throughout the product lifecycle.

The typical linkage between ALM and PLM occurs at points where firmware or software is married to the rest of the electrical and mechanical design in PLM. This holistic view is necessary to ensure interoperability of all designs and provide a complete multi-tiered assembly of parts that can be passed to the manufacturing teams, partners and enterprise resource planning systems to plan and produce the finished product in volume.

PLM providers contend that their platforms remove the complexity barrier of entry, making it easier for all teams and partners to view, review and collaborate regardless of the technical aptitudes of those using the system.

The other typical synergy between ALM and PLM occurs in bug tracking and requests for change. A system like PLM can provide a holistic view of these workflows, allowing appropriate individuals to see the issues or enhancements, especially in cases where they exist at the crossroads of software development and product development.

“Today, organizations spend as much as half their program schedules doing system integration,” says Sampson. “A tight integration of the software development processes into the overall product lifecycle is required to survive the system integration experience.”

More Aras Coverage

More Arena Solutions Coverage

More Jama Software Coverage

More PTC Coverage

More Siemens Digital Industries Software Coverage