**2. PLM data and descriptions**

models to cover the full range of processes, operations and activities required to support a product through its lifecycle. A critical and current issue is the extent that these product models provide the basis for generating corresponding process models particularly dynamically so that process models continuously reflect the current state of the product models [1]. One aim is to enhance through improvements in workflow for planning product development processes, the significant gains that PLM systems have delivered over a period of 25 years in reducing both the duration and costs of product development [2]. Research by the authors [3, 4] has concentrated on the processes of testing and their ubiquity through product development. Critical testing processes such as field testing ([2], for example) are identified in these workflows, which deliver product development. However, the way that these testing processes form a critical part of all the processes from start to finish of the product lifecycle, whether as inputs, as drivers for iteration, for establishing alignment to regulations or for confirmation of completion of a satisfactory design, has received limited consideration in the literature. Tests are long and expensive activities and most product development activities and tasks depend on the results of test, whether, physical test, simulations or field data gathered during customer operations. This chapter examines methods to integrate testing more closely with other product development processes as well as to improve the planning of the processes of testing so that testing activities are scheduled optimally. Further, the chapter examines how the results of tests can be applied to assist other product development processes. Critically, it analyses how preliminary test results can be of significant assistance to these other processes, speeding their completion. Previous research by the authors has addressed two particular issues. First, combining information from both physical and virtual testing (simulation) can bring forward in time the availability of a workable product model suitable for the next design stage [3]. This helps planning a design process in an iterative cycle of proposal, test and redesign through developing a method to analyse the overlap between steps in this cycle and optimise this overlap to reduce overall development time. In particular, the long duration of some physical tests, which are necessary to ensure performance and conformance to regulations and standards, are a bottleneck in product development. Starting downstream design activities dependent on these tests before the tests are completed can ease this bottleneck. Essentially, the proposed method applies information from two distinct product models, simulation and physical test to change the process model, allowing significant overlap between activities. The method

74 Product Lifecycle Management - Terminology and Applications

relies on observing the degree of convergence between simulation and test data.

The second piece of research [4, 5] examines more closely how testing activities can be explicitly integrated into the product development process for complex engineering products. This research highlights the mismatch between several models of product development which tend to relegate testing to be an activity late in the design process or primarily concerned with quality issues. In fact, examination of practice shows that testing is integrated throughout. The misconception in product development process models has possibly arisen because the long duration of physical tests means that the results of testing are not available until later stages, although the activity itself necessarily starts early in the process. This research therefore points to a significant reappraisal of appropriate process models resulting from how data is available in product models. Both strands of previous research have focused on testing for design, rather than wider product development through lifecycle. However, they provide Two observations are relevant when considering testing in product lifecycle. First, testing is a continuing activity, whether physical or virtual, throughout lifecycle. Testing data sets up maintenance schedules and product use data assists in updating these schedules. Periodic refit and redesign may emerge from testing new materials, components and subsystems to track upgrades and changes to customer requirements.

Second, testing supplies information which becomes part of a product description. PLM systems handle several product descriptions [7, 8] and a major challenge is maintaining consistency and integrity of multiple descriptions In the simple case this might mean ensuring that changes to a design in one description, perhaps CAD geometry, are propagated accurately to descriptions for manufacture and assembly such as BoMs and tolerancing schemes. Results of testing update these multiple descriptions in PLM systems. As observed above, testing takes place continuously through product development and product use. However, the schedules for physical testing activities have long duration.

Product performance data is gathered over a range of use conditions and longitudinally over time. Data of two types is relevant in testing. Special tests can be set to investigate particular characteristics such as thermal dynamics of an engine which formed one of the areas of previous research [3]. Other data is gathered from product monitoring in the field. Increasingly the latter data, which may include component wear, degradation in performance or replacement of components, for determining preventative maintenance or redesign of failing components, is well established for complex products such as aerospace [9]. However, quick and effective use of this testing data depends on levels of confidence when only partial data is available. A similar situation to testing in the initial stages [3] occurs throughout lifecycle, where reliable decisions on maintenance, retrofit and redesign when taken early can reduce operational product cost to customers as well as more speedily remove potential causes of failure.

really question the assumed relationship between design (generally interventions in product such as design, maintenance or retrofit) and testing (generally derived data from analysis, simulation, physical test, or product use monitoring). Previous research [3] has examined the relationship between design and testing in their narrow senses and concluded that rebalancing leads to a more feasible and realistic model of process. Data from testing (in the wider sense throughout lifecycle) is expensive and time consuming to provide. How and when it is used is a critical part of process models. Conversely these descriptions of performance and functionality derived from testing require support from PLM alongside descriptions of prod-

Testing and PLM: Connecting Process and Product Models in Product Development

http://dx.doi.org/10.5772/intechopen.80364

77

uct components, configurations and architectures derived from design activities [13].

Dynamic process models have been identified as critical to delivering the benefits of PLM systems [1, 14]. Methods to construct evolving process models from PLM product models use Design Structure Matrices and workflow networks. This research theme presents a new framework for PLM systems so that they can support these evolving process models. Conversely, process models which highlight the balance (and integration) of design and testing (in their wider senses outlined above) assist in the construction of product models in PLM systems.

**Figure 2** presents a generic sequential process model [1] of the stages of a product's lifecycle from identifying market needs to recycling. This also represents the overall information flows

Another view of information flow within product lifecycle is presented in **Figure 3** adopted from [15], which consists of three main phases: beginning of life (BOL) includes idea generation, product development and production, middle of life (MOL), includes use, service and

At every stage of the product lifecycle, information such as design specification, Computer Aided Design (CAD) drawings, Computer aided Engineering (CAE), physical test results and technical documents are generated [16]. These pieces of information are captured, stored, managed, and transferred between different people and application system during product lifecycle management. In general, PLM includes the planning, execution, control, and documentation of all processes in the product lifecycle [17]. Information flow from the BOL phase to other phases is managed through several information systems, such CAD tools, product data management (PDM) and knowledge management (KM). However, the information flow from/to MOL and EOL is not well supported or managed through current tools and information systems, therefore the critical information from these phases about product use data often do not adequately feedback to the BOL phase [17]. This may cause the decision- making

Different descriptions make up a product model in PLM. These are created during stages of the product lifecycle to facilitate the next stage of the process. The descriptions of product,

maintenance and end of life (EOL) comprises of reuse, recycle and disposal.

process in the product lifecycle to be inaccurate and incomplete.

**Figure 2.** Development process model (taken from [1]).

in product lifecycle.

The broader challenge for PLM systems with their multiple decisions of different aspects of a product is two-fold. **Figure 1** indicates these two broad challenges as updating performance and product descriptions iteratively. The first is to ensure that testing data updates performance and operational user descriptions consistently. The second occurs, when testing or use monitoring data prompts component or subsystem redesign. The underlying configurational product descriptions such as (Bill of materials) BoMs for manufacture and assembly will change accordingly, and updating these new product descriptions consistently is critical. With the focus of this chapter on the interplay of simulations, physical testing and monitoring data, it is noted that simulations depend on design descriptions and that inconsistent descriptions will reduce the accuracy of simulations leading to slower alignment between the results of simulations and the results from physical test. PLM has a design focused view in which the processes of product development effectively 'call for' testing and monitoring to validate and verify a design proposal. A critical circumstance in product lifecycle is the incorporation of new technologies in components and systems. Testing is often mandatory to meet regulations before new components can be fitted and operated, especially for complex products in the automotive and aerospace sectors which have a long service life. Conversely it is suggested here that a testing and use data view of PLM can drive design. It is argued that testing and design are equal partners in the product development process and promoting closer integration through PLM will give competitive advantage. This chapter explores how product development teams can reduce redesign iteration cycle time at several points in the product lifecycle. Incremental reductions in product cost and improvements in customer service at each cycle accumulate as the number of cycles increases yielding a significant benefits over the whole lifecycle.

Several pieces of research have examined how early availability of data from testing can reduce overall design duration [10–12]. However, these methods generally take an abstract perspective looking at optimising a given set of design and testing activities. However, they do not

**Figure 1.** Iterative updating of product and performance descriptions.

really question the assumed relationship between design (generally interventions in product such as design, maintenance or retrofit) and testing (generally derived data from analysis, simulation, physical test, or product use monitoring). Previous research [3] has examined the relationship between design and testing in their narrow senses and concluded that rebalancing leads to a more feasible and realistic model of process. Data from testing (in the wider sense throughout lifecycle) is expensive and time consuming to provide. How and when it is used is a critical part of process models. Conversely these descriptions of performance and functionality derived from testing require support from PLM alongside descriptions of product components, configurations and architectures derived from design activities [13].

Dynamic process models have been identified as critical to delivering the benefits of PLM systems [1, 14]. Methods to construct evolving process models from PLM product models use Design Structure Matrices and workflow networks. This research theme presents a new framework for PLM systems so that they can support these evolving process models. Conversely, process models which highlight the balance (and integration) of design and testing (in their wider senses outlined above) assist in the construction of product models in PLM systems.

**Figure 2** presents a generic sequential process model [1] of the stages of a product's lifecycle from identifying market needs to recycling. This also represents the overall information flows in product lifecycle.

Another view of information flow within product lifecycle is presented in **Figure 3** adopted from [15], which consists of three main phases: beginning of life (BOL) includes idea generation, product development and production, middle of life (MOL), includes use, service and maintenance and end of life (EOL) comprises of reuse, recycle and disposal.

At every stage of the product lifecycle, information such as design specification, Computer Aided Design (CAD) drawings, Computer aided Engineering (CAE), physical test results and technical documents are generated [16]. These pieces of information are captured, stored, managed, and transferred between different people and application system during product lifecycle management. In general, PLM includes the planning, execution, control, and documentation of all processes in the product lifecycle [17]. Information flow from the BOL phase to other phases is managed through several information systems, such CAD tools, product data management (PDM) and knowledge management (KM). However, the information flow from/to MOL and EOL is not well supported or managed through current tools and information systems, therefore the critical information from these phases about product use data often do not adequately feedback to the BOL phase [17]. This may cause the decision- making process in the product lifecycle to be inaccurate and incomplete.

Different descriptions make up a product model in PLM. These are created during stages of the product lifecycle to facilitate the next stage of the process. The descriptions of product,


use of this testing data depends on levels of confidence when only partial data is available. A similar situation to testing in the initial stages [3] occurs throughout lifecycle, where reliable decisions on maintenance, retrofit and redesign when taken early can reduce operational

The broader challenge for PLM systems with their multiple decisions of different aspects of a product is two-fold. **Figure 1** indicates these two broad challenges as updating performance and product descriptions iteratively. The first is to ensure that testing data updates performance and operational user descriptions consistently. The second occurs, when testing or use monitoring data prompts component or subsystem redesign. The underlying configurational product descriptions such as (Bill of materials) BoMs for manufacture and assembly will change accordingly, and updating these new product descriptions consistently is critical. With the focus of this chapter on the interplay of simulations, physical testing and monitoring data, it is noted that simulations depend on design descriptions and that inconsistent descriptions will reduce the accuracy of simulations leading to slower alignment between the results of simulations and the results from physical test. PLM has a design focused view in which the processes of product development effectively 'call for' testing and monitoring to validate and verify a design proposal. A critical circumstance in product lifecycle is the incorporation of new technologies in components and systems. Testing is often mandatory to meet regulations before new components can be fitted and operated, especially for complex products in the automotive and aerospace sectors which have a long service life. Conversely it is suggested here that a testing and use data view of PLM can drive design. It is argued that testing and design are equal partners in the product development process and promoting closer integration through PLM will give competitive advantage. This chapter explores how product development teams can reduce redesign iteration cycle time at several points in the product lifecycle. Incremental reductions in product cost and improvements in customer service at each cycle accumulate as the number of cycles increases yielding a significant benefits

Several pieces of research have examined how early availability of data from testing can reduce overall design duration [10–12]. However, these methods generally take an abstract perspective looking at optimising a given set of design and testing activities. However, they do not

product cost to customers as well as more speedily remove potential causes of failure.

76 Product Lifecycle Management - Terminology and Applications

over the whole lifecycle.

**Figure 1.** Iterative updating of product and performance descriptions.

**Figure 3.** Levels of information flow achieved between the different product lifecycle phases [15].

design and performance are particularly relevant for PLM management. The definitions for these descriptions vary and for this research the following definitions are adopted.

*Product description* is the explicit result of a design process, which is the information for defining the product [18] usually in the form of drawings and CAD models. Design information is of two types. First, background information, such as the design requirements, design methods and design standards and second foreground information on the details of the product. The latter is the product description. *Design description* covers the information from which the product can be manufactured [19]. *Performance description* is the realistic system-level performance description. This can be based on several different physical models. For example, heterogeneous models covering mechanical, fluid and electronic dimensions are needed to describe the performance of complex products [20].

manager and a validation team leader were interviewed. The case studies involved a series of

Testing and PLM: Connecting Process and Product Models in Product Development

http://dx.doi.org/10.5772/intechopen.80364

79

**Figure 5** presents the view of the diesel engine company on their product lifecycle management process model. The top layer of the model shows key stages of the product lifecycle from the business strategy to the disposal of the product. The beginning, middle and end of life (BOL, MOL, EOL) classification, introduced in Section 2, is shown on the bottom layer. The middle layers show key activities that are undertaken during the stages of product

interviews ranging from 40 to 180 minutes in duration.

**Figure 4.** Company's product range (taken from [4]).

**Figure 5.** Product lifecycle management process model.
