Silos changing: PLM and ALM for Smart Products

Posted on 22 Aug 2012 by The Manufacturer

This week, Mike Evans, Cambashi research director, discusses the business initiatives that respond to consumer and business demand for smart products and devices.

Experts at industry analyst and market consulting firm Cambashi contribute a regular blog for TM titled Silos Changing exploring how new software applications enable manufacturers to implement business initiatives for the new economy.

Engineers designing products understand good practice is to first design a product architecture and then design modular sub-systems for each element of the architecture.

By re-using the architecture they decentralise the design. And that enables parallel working which reduces lead times yet incorporates the latest and best version of each sub-system. 

But the arrival of smart products has made a complex issue more challenging. 

An extra discipline, software engineering, is added to the mix. Also, as the product advances, a particular function is often implemented in a different technology.

The design team have to tie together requirements; functions that implement those requirements; and test cases that verify that requirements are met.

This is hard in any circumstances.  When the implementation discipline – mechanical; electrical; software; or electronic; of a particular function changes, then maintaining these relationships becomes a critical challenge.

Until now, software engineers have tended to use their own design management tools such as Rational DOORS for requirements management; Rational ClearCase for Software Configuration Management and HP Quality Center for Testing. 

These tools are often bundled together as the Application Lifecycle Management (ALM) category.  Physical product design teams for the other disciplines have used Product Lifecycle Management (PLM) tools for design management such as: Autodesk PLM; Dassault Systèmes Enovia; Siemens PLM’s Teamcenter; and PTC’s Windchill.

Several leading adopters designing smart products are executing on a business initiative to rationalise their design workflow to cope with the increasing importance of software. This is enabled by selecting a single set of tools for design management of all the artefacts in the product, PLM and ALM. 

We can confidently say that no single vendor provides every design management and design development tool needed in a single suite. That means there will have to be a best of breed approach.

There are several issues to consider. 

Where is the master of the product requirements maintained? Should the change management of software and physical artefacts be combined in a single system? How will derived requirements such as signals and dependencies between software and hardware components be managed? How will product variants be handled? 

The key decision is whether to have the PLM solution manage the requirements and change management or whether to run two tightly coupled PLM and ALM systems.

PTC’s purchase of MKS and its Integrity product line provides, for the first time, a single vendor PLM and ALM solution.

Growing integration of solutions combining Windchill and Integrity means requirements and change management can be in a single environment. Integrations like this allow controlled use of best of breed point solutions for specific design tasks.

Siemens PLM is focused on Teamcenter as the master system for requirements and change management. Integrations with partners for software specific tools treat each software module as a ‘part’ allowing the use of all the Teamcenter functionality.

Both approaches allow software engineers to continue to use tools such as Sparx Systems Enterprise Architect for modelling and The MathWorks Matlab/Simulink for simulation and verification.

An increasing proportion of the product value is in the software, and an increasing proportion of the designers are software rather than mechanical, electrical and electronics engineers.

Defining a clear design workflow and deciding about the supporting toolset is important. However, we suspect that the critical success factor is to understand the current situation in the various development teams and plot a clear transition process from as-is to where you want to be. 

In future blogs, we will go on to write about other potential deployments that respond to these business initiatives to address consumer and business demand for smart products and devices.