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

Abstract

The product lifecycle management (PLM) is the process of managing the entire lifecycle of a product from the idea generation, through the design, development and manufacturing to service and disposal of the product. Testing often is considered to be an activity to perform during the product design and development phase. However, the information about how a product is designed and tested is useful for designing the maintenance and the monitoring and maintenance data can provide useful information in developing the next generation of a new product. The main objective of this chapter is to understand how testing process in integrated into the product lifecycle. This chapter reports a case study in a UK based manufacturing company and based on that develops a framework to highlight the importance of testing. Also, proposes a conceptual model of how testing activities can be managed in the product lifecycle management process.

1. Introduction

During a product development process, information becomes available to, and is requested by, many partners, design teams and organisations. Information about properties and performance of components and subsystems is the basis of decisions made in the development process. This information has many sources ranging from mathematical models, simulations, testing of physical models and prototypes and customer use data. It has many destinations, in the primary design phase and then through the product life in operations of maintenance, refit and redesign. Product Lifecycle Management (PLM) is primarily concerned to create product 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 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 useful insights into the relationship between the product models of PLM [1, 2] and the process models [6] in product development.

This chapter applies the results of this research to integrate testing and design more widely in the product lifecycle. Section 2 introduces some background and literature of PLM with particular reference to testing. Testing is considered from a general perspective as activities which analyse properties and performance of designs. A short review of existing research on the relationship between testing and PLM in Section 3 covers the mixes of testing activities at various stages of the product lifecycle based on some industry observations. Section 4 extends the proposition, first proposed by Tahera et al. [3] for testing and design, and reviews a three-way mix of testing types comprising simulation, use data (from embedded product monitoring) and physical testing. Further, wider implications of these methods are drawn in Section 5, especially in how PLM systems coordinate product models generated through design, testing and product monitoring activities. Section 6 discusses the tentative nature of these findings, the requirements for further research and the potential benefits for PLM systems. In particular, the refinements in process models recognise testing activities explicitly and their close integration with other processes in product development. Changes in process models drive changes to product models and PLM. This research does not cover the latter stages [as referred as End of life (EOL)] of product lifecycle.

2. PLM data and descriptions

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.

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.

Figure 1.

Iterative updating of product and performance descriptions.

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

Figure 2.

Development process model (taken from [1]).

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.

Figure 3.

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

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, 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].

3. Testing across product lifecycle: an industry example

This section outlines testing and associated activities at various stages of the product lifecycle as observed in a major international company which designs and manufactures automotive diesel engines. First, the company-based product lifecycle management process model is described. Next, types and sequencing of testing in the product development process of the company is examined. The scope of testing is then broadened to include other aspects of PLM, especially maintenance and new generation product design.

It is a UK based diesel engine design and manufacturing company, that offers a wide range of diesel and gas engines and power packages from 8.2 kW to 1886 kW and has the capacity to produce up to 800,000 units per year. There are product families with different power ranges to meet the requirements from different markets. Products also vary in families depending on the number of cylinders, aspiration and control mechanism. Figure 4 shows the series of engines in the company’s product range. Eighteen semi-structured interviews were carried out at the company premises from February 2011 to February 2014. Eight engineers including a senior engineer, a development engineer, a business manager, a verification and validation manager and a validation team leader were interviewed. The case studies involved a series of interviews ranging from 40 to 180 minutes in duration.

Figure 4.

Company’s product range (taken from [4]).

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 development. Although, this chapter will only discuss the product design and development activities but it is important to highlight that development of the company’s product support starts in parallel with product design and development. Further, to aid support, the product is monitored by the company during its operation and up to its disposal.

Figure 5.

Product lifecycle management process model.

3.1. PLM process model

The company’s product development process mainly comprises two wide-ranging processes; the New Technology Introduction (NTI) process and the New Product Introduction (NPI) process. The general research and development exercise occurs through New Technology Induction (NTI) process in their research and Development (R&D) department before the NPI process starts. Emission-related legislation is a key driver in technology development for this company. New technology, for instance, an after-treatment system that will reduce engine emission, would be developed in the NTI stage, and this system would be integrated with the engine through NPI process. This chapter focuses on the NPI process as most directly aligned with generic product development and PLM. However, it is noted that the background processes of NTI critical in product lifecycle especially as new technologies come on stream during life, enabling redesign and retrofitting of new components and subsystems.

As shown in Figure 6, this NPI process in the company has seven stages starting from the identification of market needs to the review of a product’s performance in the field, i.e. “Requirements” to the “Review of Market Performance” (see Tahera [4] for further details of the company processes). Each stage leads to a formal gate review. Based on prescribed criteria, a product must pass through review at the gateways (GW1, GW2,…GW7) before the product development project proceeds to the next stage.

Figure 6.

Stage-gate process for new product introduction in a company study.

Testing and the key activities of design, computer aided design and engineering (CAE), and procurement of prototypes are considered in this study. The latter is a major activity since these need specialist design and manufacturing expertise, often involving new manufacturing processes, materials and technologies. A more detailed flow diagram of these stages is presented in Figure 6 to show the integration of the key activities.

As the diesel engine is a mature product and design changes happen incrementally, engineers in the company start with an existing analysis of the previous generation of products. For a new product introduction (NPI) programme, product objectives are checked against a current product issues (CPI) database. The CPI database provides information about failure modes and effects of current products, which will need special attention for next generation products. This process is carried out by lead team members who are the technical specialists, component owners, design owners and the verification and validation managers.

The NPI process starts in the requirement gathering phase, and should be finished before Gateway 1 (GW1), i.e. before the concept demonstration phase, however spread across the SD phase. Initially, the design alternatives are included in the analysis, because selection of a design is made based on the risk with that particular design and the associated time and cost of its validation program. All design options are considered during this phase. These help to analyse the trade-offs that can be made across different design options. If this analysis identifies high risks in design decisions, CAE analysis and design changes are undertaken until the risk is reduced to an acceptable level to proceed with the project. These CAE analyses typically fall into three main areas: structural analysis, mechanism or dynamic analysis and thermo-fluid-flow dynamics. They result in the determination of parameters like material properties, geometric idealisation, and physics, which help to define the scope of the design activity. When the overall risks are assessed, design verification and validation actions are decided and planned to mitigate risk. Verification and validation activities can range from design changes, further CAE analysis to testing.

Ideally, most of the development related testing should start after the requirements have been identified i.e. after the Gateway 1 (GW1) and continue till the product is validated, i.e. until Gateway 5 (GW5), after which the engine is released to production. However, as depicted in Figure 6, these testing activities can spread further across subsequent stages of the process. At each stage, functional tests include the performance and emission (P&E) tests and mechanical tests for durability and reliability. Performance testing measures engines properties. For example, power and fuel consumption of an engine may be measured given a regulated fuel and air intake into the engine cylinder under steady state conditions of constant speed and load. While ensuring the performance, engines need to satisfy legislative conditions, for instance, the chemical constitution of the exhaust gases. The durability and reliability tests are conducted in peak harshness and tougher condition for a reasonably short period of time, called accelerated tests, forcing components or engine to fail/pass. For example, a gross thermal test procedure specifies the test cycle for determining the thermal fatigue resistance of core engine components. Typically, performance and emission related tests are performed before the mechanical durability and reliability testing.

Testing occurs at different levels of the product. Component level testing happens primarily at suppliers of components, although the case study company also carries out testing to investigate areas of design concern. Engine level testing involves standalone engines on a test bed. Machine level testing involves engines mounted in a machine or vehicle to reproduce expected conditions of use. Figure 7 indicates how engine level and machine level testing are mainly conducted in parallel in the three consecutive stages, for different purposes in the product development and PLM. The stages are characterised by the type of testing activity. Stage 2 has Concept/System Demonstration (SD), stage 3 has Design Verification (DV), stage 4 has Product Validation (PV) and stages 5 and 6 focus on Certification.

Figure 7.

Flow diagram of testing and associated activities in diesel engine design and manufacture (adapted from [4]).

Concept/system demonstration (SD) testing is primarily to demonstrate ‘performance capability’. It shows that the technology can deliver the required performance. Alternative concepts are analysed and evaluated at this phase. A combination of old and new parts are built into an engine called a MULE. This MULE engine is tested to verify the performance of new parts.

Design verification (DV) is primarily to develop optimal performance and validate hardware at the optimised performance. The aim is to ensure that design outputs meet the given requirements under different use conditions. At this stage, testing focuses on the verification of a chosen design, through detailed analysis and testing of stress, strength, heat transfer and thermodynamics etc. This stage validates the hardware prior to commitment to expensive production tooling.

Product validation (PV) checks the effect of production variability on performance and any remaining hardware variation. This phase performs hardware testing which is limited to late design changes and emissions conformance testing. In this phase, detailed testing for reliability and durability occurs and the intended product is validated. The mandatory tests required for compliance usually occur during PV phases.

Testing for certification happens in stages 5 and 6 before product is released to customers. Global emission regulations for diesel engine manufacturers provide requirements for the testing and evaluation of new components and new engine designs. It is an imperative for certification that the company follows the standard regulations during product development in terms of how a product needs to build and tested during validation for certification. For instance, to meet the in-use compliance, the company needs to demonstrate that the engine will meet specific levels of particulate emissions that will be detected and measured at the end of the useful life of the product.

The case study company considers that testing of their product continues into use. As one senior engineer in the company remarked “in fact, real tests start when products are in use”. Their engines are equipped with a remote monitoring system that allows them to capture and collect field data. They have special user groups and they have established close relationship with consumers who help to collect more reliable data. The data consists of equipment characteristics identification data, usually the unique numbers, operating data (engine on/off and physical variables), event data (failure and maintenance history) and environmental and condition data. These field data are useful for several reasons:

1. to monitor: how a product is used by a specific customer groups to identify any inappropriate and misuse,

2. to monitor the current health of the product to plan and design their aftermarket service, i.e. repairs and maintenance services.

3. to feedback to the beginning of the lifecycle as the product health monitoring data are the key input for designing the next generation of the product. This enables a reliable specification for the design phase and the development of a product description.

To help deliver these benefits the company creates two descriptions for monitoring and new product development in addition to the PLM descriptions mentioned in Section 2 for product, design and performance:

1. Current product governance—during product in operation/ field data to help new product development,

2. Product support development—during product development to help product monitoring.

3.2. Current product governance: field data and new products

In the diesel engine company, the ‘voice of the customer’ (VOC) is captured in many ways: directly, through discussions, interviews and workshops with customers, and indirectly through analysing customer specifications, warranty data, and field reports etc. and through dealers and distributor channels. Quality Functional Deployment (QFD) is applied to identify critical technical requirements of the design which will need verification and validation by testing.

The company uses Failure Modes and Effects Analysis (FMEA) to evaluate a potential design for possible failures and to prevent them by proactively changing the design rather than reacting to adverse events after failures have occurred. This emphasis on prevention may reduce risk of failure in field. FMEA is particularly useful in evaluating a New Product Introduction programme prior to implementation as well as in assessing the impact of a proposed change to an existing design. More details about FMEA and steps of FMEA analysis can be found in [21]. FMEA is one of the most widespread methods used in determining priorities for technical risks in the PD process especially during the testing phase [22].

To identify the potential effects, the company reviews documents, including historical data, warranty documents, field service data, and customers’ complaints. The company rates the severity of the effects of a failure mode. Any failure occurring in the field is considered as a high risk. Issues identified in use significantly drive next generation product development and testing procedures. The company continuously monitors and captures a product’s performance and durability when engines are used in a field. For a new product development, the company uses information from the ‘use in the field’ to assess how the product is performing and from the ‘use of the customer’ (how customers are using the product) to judge when a potential failure is likely to occur.

Field data is particularly valuable as it consists of information about failures and repair actions that have been taken place under real operating conditions. This enables the acquisition of statistically significant reliability and repair data [23]. Issues in recording field incidents are addressed by Smith [23] particularly how reliance on people means that recording is subject to errors, omissions and misinterpretation.

3.3. Product support development: design for maintainability

Maintainability is characterised as the ease of retaining or restoring a product in effective use conditions by using specific procedures and resources [24]. It is an important factor in the economic success of an engineering system. “Design for maintainability requires an evaluation of the accessibility and reparability of the inherent systems and their related equipment in the event of failure, as well as of integrated systems shutdown during planned maintenance” [25]. Maintainability procedures and techniques not only avoid and fix failures they also consider how a system might fail. Three types of maintenance can be distinguished: breakdown maintenance (corrective maintenance), preventive maintenance, and predictive maintenance (condition-based maintenance).

Condition monitoring and fault diagnosis techniques are used for predictive maintenance [26]. Product health monitoring is a research area that covers failure detection, current health assessment and remaining useful life prediction [26, 27]. According to Fu et al. [28], most failures do not occur instantaneously. There is degradation and associated symptoms before the actual failure. The main objective of the predictive maintenance is to reliably identify these degradation processes so that maintenance can be affected before the actual breakdown. Predictive maintenance is based on the product’s performance and condition monitoring data. For example, in well-established methods, vibration data is analysed to find the frequency responses to identify the type of fault present in the equipment [27].

At the design and development design stage the main characteristics of a product are determined and product performance is evaluated. Therefore, design for maintainability should be considered during the product development. However, according to Coulibaly et al. [29], there is lack of an efficient tool for considering maintainability and serviceability at the early design. Also, there is limited research on how information from design, CAE and tests can support product maintenance.

Kiritsis et al. [30] have commented that clear definition of the information for maintenance is required if appropriate and adequate information is to be collected. Usually, data collected during Middle of Life (MOL) phase of product is for maintenance management purposes and may not be appropriate for feeding back to the Beginning of Life (BOL) phase to redesign or improve a product. Although people involved in this process often have a clear understanding of the required information, it is not straightforward to define or determine exactly what information will be required.

A baseline performance description would allow degradation over a period of use to be assessed. As mentioned before, advanced engineering products such as the diesel engines studied here are equipped with instruments such as sensors, meters, controllers, and computational devices and have the processing capacity to self-detect/ predict certain problems. Next section proposes a conceptual model to facilitate this process. Design and testing data from the EOL stages can be a useful reference point for comparing with monitoring data for predictive maintenance. Also, this model can help to clearly define the information required to be collected to comparison.

4. Extending the proposition: testing data for predictive maintenance

This section extends a method for managing the iteration of design and testing during the product development stage [3] to predictive maintenance during the product use phase. First, the previous work will be described briefly, then how the work can be extended for the purpose of the predictive maintenance will be explained.

In an iterative design and testing process, testing results usually drive the subsequent re(design) activities. A control system analogy can be used to describe an iterative design and testing process. A control system monitors, compares and adjusts at a sequence of time points. A monitoring device makes a measurement, and reports it to the comparator, which compares it with the pre-determined desired value. A decision rule uses the result from the comparator to adjust an effector. Similarly, in a test, actual measurements of a parameter are taken and compared with pre-determined values identified in design analysis to identify if the design is satisfactory.

During a lengthy durability test, for example in a “Deterioration Factor” test, intermediary test measurements are taken at a sequence of time points between start t_s and finish t_f (t_s, t₁, t_2…t_n…t_f), as in Figure 7. Engineers know that the performance of an engine will change over the time and they allow an acceptable margin for each time point. This is illustrated in Figure 8 with a range of expected values specified by design and CAE prior to the test. Engineers will know how much they expect the product to deteriorate after say 200 or 500 hours of running the test. If the product deteriorates below an allowable limit, or margin, at that time, then it is deemed under-designed. If an engine performs above the margin then it is assumed to be over-designed. Therefore, if the engine produces any value under or above the expected values (including margins) then these deviations are not acceptable (see Figure 8) and indicate that redesign is required. ‘Deviation’ is the difference between the expected value of a parameter and an actual measurement of that parameter, at the time of an assessment (e.g. test).

Figure 8.

A schematic of expected and measured value and associated deviations at different times during a test.

Figure 9 shows a schematic, which presents a simplified case of Figure 8 in which the expected value is a single value rather than a range. In practice this might be the mean of the distribution of expected values and is represented as the upper straight line (in red). The lower line (in green) represents the measured values. A physical test starts at t_s and finishes at t_f. Since the design meets specification based on the best knowledge available at t_s, (or rather there is no information to indicate that it does not) the red and green line meet at t_s. During the testing process, test measurements are taken and the actual value of a parameter at any point is identified.

Figure 9.

A simplified model of deviations between expected and measured values during a test.

Deviation, at a time point, is identified as the difference between test measurements and expected value. The magnitude of the deviation is shown with a double-headed arrow in Figure 10 which depicts a case of under-design, with measured product performance gradually degrading and the deviation increasing monotonically. This considerable simplification is an assumption of the model developed here. The sloping line represents the evolution of test results over time, which tends to show increases in deviation of the design from expected performance. The deviation does not, in practice, decline linearly.

Figure 10.

Comparison of CAE and test data with field data to identify product’s performance level.

The difference between test measurements at different times, can reveal the ‘degree of evolution’ [12], i.e. how fast the deviation is changing in approach to the final value of the deviation at t_f. Details can be found in [12].

A similar proposition can be used for predictive maintenance. The design stage identifies the expected product performance in use, i.e. a range of expected values of a parameter can be specified by design, CAE and tests during the development stages. Product’s health measurements are taken at a sequence of time points between start t_s and finish t_f (t_s, t₁, t₂ …..t_n….t_f), as in Figure 9. Using a similar approach as explained above, the “amount of deviation” and the ‘degree of evolution’ can identified.

Once, these two factors are identified, i.e. how fast and how much within a time interval a product is degrading can be determined, an effective maintenance plan can be made.

5. Implications of the proposed method in PLM

The extension to include user and service data, combined with CAE simulations and test data to the latter stages of the product lifecycle in maintenance schedules and the refit of critical components is straightforward. As noted above the user and service data of previous products is used extensively in initial new product development, especially in FMEA and QFD processes. With a product currently in service, a history of user data will be accumulating. This serves several purposes. First to help specify and tune the maintenance schedules. Statistically significant data will be available from a large population of products about the behaviour, performance profiles and probabilities of failure of critical components in the product. This data is at the core of establishing service schedules and swop outs for potentially failing components.

Second, failing components can be identified for redesign and refitting. The use conditions and the causes of failure may be clear from the data. The cycle of product development will be repeated with simulation, physical test, often necessary for regulation conformance, and redesign. The methods of Section 4 which allowed convergence of simulation and virtual test results with those of emerging physical tests will enable a quicker time to redesign and replacement of the failing component with corresponding significant improvements in product performance and customer satisfaction.

Third, the emergence of new technologies at high technology readiness levels means that designs which were not feasible originally, because of the risks associated with low TRL can now be incorporated into the product. The purpose is to reduce costs, both to manufacturer and to consumer of the product. This process is frequently complicated by the dependence of the product developer on the processes of a specialist supplier. The advantages of the new and now mature technologies can be assessed against the use and service data. This will determine the benefits to all parties of the new technology and thus the business and engineering pressures on timescales. With an intense pressure on speed of product improvement through new technologies, there is considerable advantage in being able to overlap test and simulation of the performance of new technology. It is noted that as these processes continue further use data is continually made available. Using targeted use data in the mix of virtual and physical testing can assist in tuning the overlap, indeed there is the opportunity to install prototype new technology components in the current product and monitor use. This may help the convergence of simulation, test and use data.

Fourth, and consequential on the third, are the benefits of retrofitting. With a new technology embedded in a redesigned component, the opportunity may arise for variants, tailored to a range of use conditions. Which variant to retrofit and the associated programme of retrofit integrated with new maintenance schedules will depend on (i) performance characteristics of the variants from test and simulation and (ii) the specialised use data to match variant to user. This integration of test and use data, can assist the optimal choice of variants.

Across these processes for maintenance, refit and retrofit, the aggregated benefits of combining physical test, simulation and use data can be considerable. This can result in reducing time to introduction of revised maintenance schedules, to designing and fitting new technologies, as well as reduced costs to manufacturers and users. When all taken together the benefits to product lifecycle accumulate and make the argument for PLM systems to provide consistent and up to date information flows in supporting these processes.

In extending the model of overlapping test and design, using convergence between data sources, to these processes in the product lifecycle several additional descriptions arise in the PLM product model. These are driven by the necessity to manage the revised processes of product lifecycle which arise from the new data and new information flows, particularly in use and service data.

New process models and new product models develop hand in hand. This section has considered how product development and support through life cycle combines test, simulation and use data. Some general issues affecting PLM product models include how to compare this field data with simulation and test, the potential effects on information flows in the process models and the application of field data from one phase of product to the development process for next generation products, where fundamental analysis of the configuration and architecture of a product is undertaken over and above retrofitting new components and new technologies to the existing products.

Comparing field data with physical test is not straight forward. Usually, the case study company uses the accelerated testing methods in which tests are conducted in peak harshness and tougher condition for a reasonably short period of time. Most of the accelerated testing is to verify that the product will perform reliably during the useful life, until it starts to wear out. Physical test results might not be readily useful for comparing with the field data as the use conditions could be different, load cycle and sensor loading location could be different, for instance, CAE analysis and virtual testing can play an important role in comparing these test and field data. CAE analysis can model and control these conditions and can focus on individual parameters. The information of CAE analysis can be disaggregated into cycles, for example. Parameters can be analysed individually if required to support decision making. Analysis of these three data, i.e. CAE analysis, physical test and field data could provide useful information for predictive maintenance, as to analysis why and how a product might fail. This may also help to record/capture field data in an appropriate manner to be used by the design engineers for the next generation of the product.

The potential implications for PLM systems of the integration of design, test and field data in making information available in preliminary form to be used by PLM for dependent activities. This effectively overlaps activities previously linearly sequenced and reduces times and costs for customers and suppliers. However, such integration comes with a significant overhead. Increased numbers of cycles of revisions to the PLM descriptions is entailed as some preliminary information although sufficient to start subsequent activities may not be enough to finish them especially when on-site assurance and regulatory conformation are necessary before customer use.

6. Discussion and further research

PLM systems assemble and manipulate product descriptions, maintaining a product model. These descriptions come from many sources in the product development process including design, simulation, test and field data. To some extent the timely availability of descriptions is dependent on the process model used to organise and manage tasks. This chapter has addressed this issue through examining how a change to process models through integrating activities has an impact on PLM descriptions.

The main argument of this chapter is delineating further the relationship between the product models of PLM and the process models for planning product development. Karniel and Reich [1] make the case that product models of PLM, updated throughout product development, have the potential to drive the planning of adaptable and dynamic processes for product development. Along with other research (e.g. [14]), they develop methods and algorithms to derive dynamic process models from the updating product models of PLM. This view gives, in a sense, a priority to the product models of PLM. The ‘new paradigm’ of Karniel and Reich [1] provides a critical role for PLM in planning dynamic processes. Updated product models in PLM are used to update process models. Although, in many industry contexts, available information in PLM and other information systems is necessary for the management and organisation of the dynamic processes of product development, which are by nature contingent and dependent, it is not sufficient. There are imperatives and opportunities in managing processes can drive the modes and forms of information available to PLM.

This chapter has examined one aspect of this mutual dependency between product and process models. Making changes to process models through increasing the integration of test, simulation and acquiring field data, changes the requirements for product models and associated PLM systems. This research adds to the understanding of ways that process models drive the types of PLM systems necessary to support them. It complements the extensive body of research on the how PLM systems can drive dynamic and adaptable process models for product development. Considerable further research is required both in theoretical methods and in industry cases to optimise the costly and time consuming processes of testing, simulation and field data collection as well as integrating them with PLM systems.