Kerga Endris
email: endris.kerga@mail.polimi.it

Taisch Marco
email: marco.taisch@polimi.it

Terzi Sergio
email: sergio.terzi@unibg.it

Manufacturing Process Planning in Set-Based Concurrent Engineering Paradigm

Keywords: Product Development (PD), Set-Based Concurrent Engineering (SBCE), Manufacturing Process Planning

The integration of manufacturing planning activities into early design decisions is paramount. Manufacturing constraints and opportunities should be investigated early in a product development (PD) stages to launch products successfully. Set-based concurrent engineering (SBCE) paradigm is pronounced in literature and believed to form the foundation of lean thinking in PD. In SBCE, alternative product-subsystems are explored simultaneously and weak design choices are progressively eliminated as more knowledge about manufacturability becomes known. However, there is a methodological gap on how to execute SBCE in practice and integrate manufacturing process planning. This paper aims at conceptualizing the requirements to start manufacturing planning in the realm of SBCE paradigm. At the same time, the paper proposes a dialogue mechanism through which designers and manufacturing process planners are able to explore and evaluate alternative conceptual designs and process plans in parallel. Moreover, the methodology enables design and process knowledge to be effectively integrated for a better decision making.

Introduction to Set-based Concurrent Engineering (SBCE)

The traditional approach to develop a product concept, shown in the left part of Figure 1, typically starts with breaking the product down into subsystem, defining detailed requirements for each module and deriving a small number of alternative solutions which are suited to meet the initial requirements. Engineers then quickly assess the solutions and select the most promising one to be pursued in the further PD process.

For the selected solution they develop drafts, build prototypes and conduct tests to more and more specify the particular alternative. This process, however, rarely turns out to be linear in nature. Usually, when specifying the module, engineers discover that the particular specification chosen does not meet the requirements formulated at the beginning because of manufacturability and other uncertainties. They then go through iterative loops to either modify the concept until it satisfies their particular need or start the process over by selecting a completely different alternative. Because of its iterative nature where engineers move from point to point in the realm of possible designs, this paradigm has been termed point-based concurrent engineering (PBCE) [START_REF] Ward | The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster[END_REF] and [START_REF] Sobek | Toyota's Principles of Set-Based Concurrent Engineering[END_REF].

Fig. 1. Comparison between Point and Set-Based Concurrent Engineering

An alternative to the PBCE is set-based concurrent engineering (SBCE), the general systematic of which is depicted in the right part of Figure 1. SBCE was first used by Toyota [START_REF] Ward | The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster[END_REF]. Like PBCE, SBCE starts with dividing the product into small subsystems and modules. However, unlike in PBCE, no detailed requirements are defined for these subsystems. Instead, engineers only identify broad targets for every module.

Based on these general objectives, a much larger number of alternative solutions for every component are developed early in the process. Designers design, test and analyze multiple solutions for every subsystem in parallel [START_REF] Morgan | The Toyota Product Development System: Integrating People, Process, and Technology[END_REF]. Unless designers have sufficient knowledge to eliminate an alternative, it will be kept for further investigation. SBCE is more advantageous compared to PBCE. First, it is a known fact that design reworks increase as a project approaches production launch, once resources have already been committed. Therefore, front-loading the PD process by exploring alternatives early in the process instead of iterating in later stages is likely to reduce the overall cost of PD [START_REF] Ward | Lean Product and Process Development[END_REF]. Second, late engineering changes cause disruption in the overall schedule of the project, and cause unpredictability in the downstream activities [START_REF] Rossi | Proposal of a method to systematically identify wastes in New Product Development Process[END_REF]. SBCE's principle of delaying decision makes sense for designers to avoid disruptions of process flow. Third, quality and innovation level improved by adopting SBCE. Exploring alternative design solutions and studying the feasibilities using proven data and knowledge at early stages support engineers to find more innovative and robust solutions compared to PBCE [START_REF] Ward | The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster[END_REF], [START_REF] Sobek | Toyota's Principles of Set-Based Concurrent Engineering[END_REF], and [START_REF] Ward | Lean Product and Process Development[END_REF].

To explore alternative design solutions and converge into an optimal, manufacturability knowledge should be integrated systematically into SBCE process. However, there is still no formal methodology aimed at integrating SBCE paradigm and manufacturability. Among others, questions that need to be answered include: How can designers be made aware of manufacturing capabilities and constraints in SBCE paradigm? How manufacturing planning can be executed in parallel with SBCE process?

This paper first tries to set the requirements of SBCE to start manufacturing planning (Section 2). Then, in Section 3, process planning literature has been explored to gain insight on how process planning can be executed in early phase of design. In Section 4, a methodological proposal is presented to answer the questions posed before. The proposed methodology is aimed at creating a dialogue mechanism through which product designers and manufacturing planners exchange knowledge about alternative designs and process plans. Besides, the methodology will be a support to choose an optimal solution from design and manufacturing perspectives. Finally, conclusion and future plans are briefed in section 5.

SBCE Requirements to start Manufacturing Process Planning

After investigating extensively the Toyota's product development process, Sobek et.al. [START_REF] Sobek | Toyota's Principles of Set-Based Concurrent Engineering[END_REF], summarized the principles of SBCE as shown in Figure 2. ─ Map Design space "Map the design space" is how Toyota develops and characterizes sets of alternatives used in the SBCE process. In PD, Toyota applies this principle at component, subsystem and full product levels. Basically, the principle states that different functions involved in a PD should explore set of possible design alternatives from their own perspectives. Further, functions should communicate their feasible designs to other functions. The example in Figure 3 illustrates the key characteristics of SBCE. In Part A, the design and manufacturing functions define broad sets of feasible solutions from their respective areas of expertise.

─ Evaluate concept sets progressively through integration

Once the feasible regions from different functions are defined, this principle states that functions should eliminate solutions which are proved to be infeasible from other functions' perspectives. However, unless there are sufficient data or knowledge to eliminate an alternative design it should be kept as an alternative. This principle makes SBCE different from PBCE. In the latter case, designers quickly select only one solution they think it is feasible without having sufficient data and knowledge to do so. Once that design proved to be infeasible late in a process, rework and process disruption emerges (as usually happens in practice [START_REF] Rossi | Lean Product Development: Fact Finding Research in Italy[END_REF]). In contrast, SBCE advocates delaying such decisions till enough knowledge is gathered through testing, simulations, and integrations. In Part B of Figure 3, for example, design engineers smoothly refines the set over time by eliminating ideas not feasible from manufacturing perspective and vice versa. And, only feasible solutions will be taken for further development.

─ Concept convergence

As a design process matures and weak design solutions are eliminated through time, other functions should have also continually eliminate their infeasible plans in parallel. At a more detail phase, keeping wide design space is not recommendable both for efficiency and communication reasons. Keeping alternative designs can causes extra costs for the company to develop those concepts which might be not feasible in the future. Moreover, it helps other functions to base their planning activities on a robust design concept. Therefore, there should be a point at which optimal designs should be selected. As shown in Part C and D of Figure 3, although some uncertainty remains at latter phase of SBCE, design and manufacturing functions can agree on a rough design concept and a process plan.

The three principles of SBCE taken from Toyota PD sound logical and efficient. Moreover, among the many reasons for the outstanding performance records of Toyota PD, SBCE is mentioned as one of the key strategy [START_REF] Ward | The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster[END_REF], [START_REF] Sobek | Toyota's Principles of Set-Based Concurrent Engineering[END_REF], [START_REF] Morgan | The Toyota Product Development System: Integrating People, Process, and Technology[END_REF], and [START_REF] Ward | Lean Product and Process Development[END_REF]. To execute SBCE in practice though a formal procedure of exchanging information and knowledge between functions is required. Since manufacturability information is critical to execute SBCE, this paper focuses on formalizing the integration between SBCE design process with manufacturing process planning. A methodological approach is also suggested to dialogue both functions to effectively explore and converge into an optimal design and a process plan.

Based on the above principles, we identified the following key requirements that are needed to integrate design and manufacturing under SBCE paradigm:  Integration between design and manufacturing should start at concept phase of design,  Explore multiple set of solutions from design and manufacturing perspectives,  Early communication about sets, based on preliminary design information,  Impose minimum constraints to manufacturing and deliberately delaying specifications,  Narrow sets gradually while increasing details until an optimal design and manufacturing plan are found. These requirements have significant implications for manufacturing process planning activities. Traditionally, process planning starts late in PD process or at detail design stages once a CAD model is finished. As a consequence, manufacturability problems then emerge causing delays and additional costs. Moreover, because design decisions are already been made, process planners traditionally cannot explore potential process alternatives as early as possible [START_REF] Sobek | Toyota's Principles of Set-Based Concurrent Engineering[END_REF], [START_REF] Ashby | Selection strategies for materials and processes[END_REF]. Therefore, the integration of SBCE design strategy demands a new look on how process planning activities are done. Furthermore, a new methodology is needed that enables designers and process planers to explore and converge into optimal solution at early phase of design.

Fig. 3. Example of integration between design and manufacturing in SBCE paradigm [START_REF] Sobek | Toyota's Principles of Set-Based Concurrent Engineering[END_REF] 3

Manufacturing Process Planning at Conceptual Design Phases

A manufacturing process planning is a method of selecting primary and secondary processes such as shaping, joining, or finishing a material. Also include selection of supporting processes such a fixture scheme, cutting conditions, etc. It is important to choose the right process-route at an early stage in the design before the cost-penalty of making changes becomes large [START_REF] Ashby | Selection strategies for materials and processes[END_REF]. A single component might go through several of those manufacturing processes (process-chains) to be finished. However, choosing the right process chains is not an easy task at conceptual phase of design. Because, only preliminary design information are available about the material, configuration, shape, etc. Therefore, at conceptual design stage there are many unpredictable factors in manufacturability, quality, reliability, serviceability [START_REF] Boothroyd | Product Design for Manufacture and Assembly[END_REF]. As a result, process evaluation for a design is usually taken place at latest stages of a design and development process using computer aided process planning (CAPP) [START_REF] Hassan | Conceptual process planning-an improvement approach using QFD,FMEA, and ABC methods[END_REF]. In order to start manufacturing planning at conceptual stage, rough methodological approaches have been suggested. Ashby's constrained based approach is the most prevalent one. Alternative process-chains are screened out based on process related parameters such as material types, shape, size, tolerance, etc. [START_REF] Esawi | Computer-based selection of manufacturing processes: Methods, software and case studies[END_REF], [START_REF] Esawi | Cost estimates to guild pre-selection of process[END_REF]. Compatible process alternatives are then evaluated based on a rough cost estimation such as resource based costing [START_REF] Esawi | Computer-based selection of manufacturing processes: Methods, software and case studies[END_REF], [START_REF] Esawi | Cost estimates to guild pre-selection of process[END_REF]. Detail costing methods, such as ABC costing [START_REF] Tornberg | Activity-based costing and process modeling for cost-conscious product design: A case study in a manufacturing company[END_REF], are not applicable at conceptual stages since such methods require detail data about the design [START_REF] Esawi | Computer-based selection of manufacturing processes: Methods, software and case studies[END_REF], [START_REF] Esawi | Cost estimates to guild pre-selection of process[END_REF]. In terms of process planning for quality, the classical capability index, which is defined as the ratio of dispersion to tolerance (i.e. C p =T/6σ), is not suitable during conceptual stages. The C p is only suitable for medium and large batch production modes when standard deviations (σ) can be determined [START_REF] Chin | A hybrid rough-cut process planning for quality[END_REF]. Composite process capability (CCP) index has been suggested to be used during early phase of design and when data are not sufficiently available [START_REF] Chin | A hybrid rough-cut process planning for quality[END_REF]. The details of CCP will be introduced in Section 4.

In SBCE paradigm, there are alternative set of conceptual designs. For each alternative design, there are alternative process chains that should be investigated to be feasible from manufacturability perspective. Here the challenges and questions are: a) how designers and process planner can exchange knowledge about the potential solutions? b) how alternative designs and processes can be evaluated in parallel in SBCE paradigm to reach optimality?

Taking cost and quality as key criteria for process planning, the following section outlines the steps of the proposed methodology.

Proposed Methodology to start Manufacturing Process Planning in SBCE Paradigm

The proposed methodology is shown in Figure 4. The methodology includes four steps: a) identification of key quality characteristics for alternative set of designs, b) planning for process quality using an integrated Quality Function Deployment (QFD) approach and a Process Failure Mode and Effect Analysis (P-FMEA), c) assessment of process quality and cost for each set of designs using CCP index and resource based costing, d) build a decision matrix relating conceptual design alternatives with respect to process-chain alternatives.

The methodology is designed assuming that designers are following a SBCE paradigm, and have already explored alternative set of conceptual designs. Moreover, at the start of the methodology, process planners already have important elements of manufacturing process alternatives to produce the conceptual designs. Let's take a scenario to exemplify the steps of the methodology.

XYZ is a company developing and manufacturing ball bearings in a large scale, but also offering customized solutions for the automotive industry. XYZ is asked to supply a new ball bearing for a new automobile model. The designers of XYZ come up with three alternative bearing concepts: A1, A2 and A3 (see Figure 4). The design team argue that to investigate the feasibilities of the alternative bearings and select the optimal one, they need the manufacturability information of the alternatives. At the same time, the management wants to start designing the manufacturing process in parallel with the product development to avoid late changes. Manufacturing process planners roughly identified key process elements required to produce the bearing, such as, Machining method (MM), Machining tool (MT), and Fixture scheme (FS).

For each process elements they identified process alternatives: Finish or Semifinished turning for machining (MM1 or MM2), Vertical or Horizontal lathes for machining tool (MT1 or MT2), and Final or Outer-clamping (FS1 or FS2) for fixture scheme respectively. Therefore, in this case we have 3 alternative design concepts and 8 (2X2X2 )alternative process-routes (process-chains) to evaluate.

Fig. 4. Steps of the proposed methodology ─ Identification of key quality characteristics

Once the sets of alternative of designs and process routes are identified, defining key design quality characteristics is necessary. Quality characteristics are requirements specified to fulfill defined customer values. For a specific component or module, key quality characteristics can be identified either taking similar component family (similar inheritation) or through expert negotiation (interactive identification). For instance, co-axiality, contourness of spoke and equilibrium of revolutions are the common quality characteristics of the ball bearings introduced in the XYZ scenario.

─ Planning for quality

The task of this step is to relate the defined quality characteristics of the conceptual design sets into process elements and their target levels. To roughly determine the capability of process alternatives, a team consists of designers, process planners, and quality engineers should be organized.

Product designers determine the weights of each quality characteristics based on their experiences about customer needs and design specifications. Using QFD as a tool to represent the voice of customers, designers can assign the importance of each quality characteristics. For the scenario mentioned above, assume that the designers assigned weights of V[0.3, 0.3, 0.4] for the three quality characteristics defined: coaxiality, contourness of spoke and equilibrium of revolutions respectively.

Process planners and quality engineers can use P-FMEA to estimate the quality impact of each process elements on the quality characteristics. Based on past experience and knowledge from historical comment, they can estimate O (Occurrence), S (Severity), and Detectability (D) of process failures relating a specific quality characteristics and a process element. Then, an aggregate RNP (risk priority num-ber=O*S*D) value can be obtained from P-FMEA. Depending on the RNP value, the relationship between process elements and quality characteristics can be scaled on a QFD matrix from 1-10 (1 very weak relationship and 10 highly related), see Figure 5. The relative weight of each process elements (W) can be determined using the normal QFD algorithm [START_REF] Ginn | The QFD/FMEA interface[END_REF]. This weight matrix relates the importance of each process elements (Machining method, fixture scheme etc.) with the defined key quality characteristics. For each process element the quality measure and level should be defined on the QFD matrix. For example, the process element measure of machining method is precision grade. And, for each alternative machining methods the element level can be defined accordingly. For example, finish and semi-finish turning have precision grade of 7 and 7.21 IT respectively. Therefore, using the integrated QFD and P-FMEA the team can prepare all the parameters to determine the composite process capability index (CCP) for each process alternatives.

─ Assessment of process quality and cost

Cost estimation at conceptual stage is already a matured concept in academia and industry. Using resource based costing one can determine the process cost of each design alternatives [START_REF] Esawi | Computer-based selection of manufacturing processes: Methods, software and case studies[END_REF], [START_REF] Esawi | Cost estimates to guild pre-selection of process[END_REF]. Therefore, in this paper, process cost values are assumed to be given. However, the step to determine the quality level of process alternatives are not well prevalent, and can be explained as follows:

Step 1. Estimate the capability of process alternatives

( j Ce )                    Min j Max j j j j X X X X Ce 0 + 1 (1)
where j Ce is the capability index of the j th process alternative of a process element. are the quality measure, the standard or benchmark, the upper and lower limits of the j th process alternative respectively. The standard process alternative is generally either an enterprise standard or a straightforward process alternative with which the team members are very familiar. It can also be a successfully available process alternative, or an earlier generation of the manufacturing process.

Step 2. Estimate the capability of the quality characteristics

( i Cp ) j n j ij Ce w Cpi .   (2)
Where i Cp is the capability of the i th quality characteristics, ij w is the weight of process elements that relate the i th quality characteristic with the j th process element. And, n is the number of process elements available.

Step 3. Estimate the composite process capability indexes (CCP) of alternative process routes

     m i V i i Cp CCP 1 (3)
Where m is the number of quality characteristics available and Vi is the weight of the ith quality characteristics.

If we consider the XYZ company scenario again, using step1 it is possible to determine the C ej indexes of alternative process plans, as shown in Table 1.

Using the relative weight found using QFD and P-FMEA, a weight matrix W ij can be defined as shown in Table 2. Next, using step 2 the team can determine the C pi indexes of the quality characteristics as shown in Table 3. The output of this step shows the capability of each process alternatives (routes or chains) for the defined key quality characteristics. Since we have 8 possible process chains (2X2X2), each quality characteristics has 8 possible values of C p , as shown in Table 3. For example, a design can go through MM1-MT1-FS1 or MM1-MT1-FS2 possible process chains. Moreover, using step 3 the aggregate process capability index of alternative process chains can be determined, assuming the importance of each quality characteristics as V i [0.3, 0.3, 0.4], see Table 4.

MM1- MT1- FS1 MM1- MT1- FS2 MM1- MT2- FS1 MM1- MT2- FS2 MM2- MT1- FS1 MM2- MT1- FS2 MM2- MT2- FS1 MM2- MT2- FS2 Coaxiality

─ Build decision matrix

A decision matrix that relates alternative designs and process chains help designers and process planners to dialogue while practicing a SBCE process. Since each conceptual product design has particular quality performance and cost structure, the team should follow the above procedures a, b and c to determine the CCP and cost values of alternative process chains for each design. Finally, at this stage a decision matrix can be built to visually represent design and planning spaces, and the team can utilize to decide an optimal design in parallel with an optimal process plan, as shown in Table 5.

Alternative Process Chains

MM1-MT1-FS1 MM1-MT1-FS2 MM1-MT2-FS1 MM1-MT2-FS2 MM2-MT1-FS1 MM2-MT1-FS2 MM2-MT2-FS1 MM2-MT2-FS2

Conclusion and Future Plan

This paper aims at developing a formal methodology to integrate designers and process planners to execute SBCE. Extensive literature review has been made to outline key manufacturing requirements of SBCE, to understand the key intercept points of design and manufacturing in SBCE paradigm. The new methodology is based on the combination of the two prevalent tools, QFD and P-FMEA. The methodology enables both parties to exchange knowledge about designs and processes in parallel. Moreover, using CCP and cost indexes, design and process-chain alternatives can be evaluated systematically.

The methodology is under validation in a real case. The next step is to apply it in a specific SBCE environment.

Fig. 2 .

 2 Fig. 2.Principles of Toyota's SBCE, modified from[START_REF] Sobek | Toyota's Principles of Set-Based Concurrent Engineering[END_REF]

Fig. 5 .

 5 Fig. 5. An illustration of process planning for quality with a hybrid approach (QFD and Process-FMEA)

Table 1 .

 1 Ce j indexes of alternative processes

		Machining methods (MM)	Machine tool (MT)	Fixture scheme (FS)
		MM1=1.49	MT1=1.11	FS1=1.54
	C e Values	MM2=1.3432	MT2=1.2	FS2=1.55

Table 2 .

 2 W ij indexes of process elements

	W ij	Machining methods (MM)	Machine tool (MT)	Fixture scheme (FS)
	Coaxiality	0.3	0.2	0.5
	Contourness of	0.3333	0.3333	0.333
	spoke
	Equilibrium of	0.3	0.3	0.4
	revolution

Table 3 .

 3 C p -capabilities of quality characteristics

	Cp

Table 4 .

 4 CCP values of alternative process chains

	CCP	MM1-	MM1-	MM1-	MM1-	MM2-	MM2-	MM2-	MM2-
		MT1-FS1	MT1-FS2	MT2-FS1	MT2-FS2	MT1-FS1	MT1-FS2	MT2-FS1	MT2-
									FS2
		1.40	1.39	1.43	1.37	1.32	1.32	1.35	1.36

Table 5 .

 5 Final decision matrix or dialoguing mechanism between designers and process planners

Acknowledgements

This work was partly funded by the European Commission through the LeanPPD Project (NMP-2007-214090, www.leanppd.eu). The authors wish to acknowledge their gratitude and appreciation to the rest of the project partners for their contributions during the development of various ideas and concepts presented in this paper.


Michael W Grieves
email: mgrieves@ameritech.net

Virtually Indistinguishable: Systems Engineering and PLM *

Keywords: Product Lifecycle Management, PLM, Systems Engineering, Model-based Engineering, MBSE, Product Development Lifecycle Management. Cocoa Beach, FL: Space Coast Press

This paper proposes that Systems Engineering and Product Lifecycle Management are closely related. In fact, the contention is that one of the threads that has led to the formation of Product Lifecycle Management is Systems Engineering. Product Lifecycle Management extends Systems Engineering and uses many of its methodologies and processes. However, this connection between these two areas has not gotten the proper attention from either industry or academia. Cross-pollinating Product Lifecycle Management and Systems Engineering would benefit both disciplines.. The paper is based on the author's observation and work at large organizations with significant Systems Engineering disciplines, such as NASA, the United States' Department of Defense, Boeing Corporation, Lockheed Martin, and others. The discrepancy between Systems Engineering claims of being involved in the entire product lifecycle versus the reality of Systems Engineering ending its involvement with the product at requirement verification informs the perspective of this paper.

Introduction

Systems Engineering (SE) and Product Lifecycle Management (PLM), as will be argued in this paper, have a great deal in common. What serves to distinguish PLM from SE is the utilization of virtual products and virtual environments. However, System Engineering, as a concept, substantially overlaps (or in keeping to the thematic thread of my recent book is "virtually indistinguishable" from) PLM in a great many ways. This paper is a preliminary effort to connect PLM with SE and to explore what they have in common and where they differ. Both PLM and SE should substantially benefit from this connection.

Systems Engineering, as a discipline, has been in existence for at least forty years, with some dating its genesis back to World War II. Others date it to the advent of the Space Program. However, Systems Engineering has a much stronger presence in industry than in academia. The most likely explanation is that Systems Engineering, by its multi-discipline nature is not well suited to the narrower, single-discipline orientation of academia. There are recent, although hardly widespread, appearances of Systems Engineering departments.

The literature has tended to be comprehensive explanations of Systems Engineering, starting with Wymore [START_REF] Wymore | A mathematical theory of systems engineering: the elements[END_REF] and continuing with recent offerings [START_REF] Blanchard | System engineering management[END_REF][START_REF] Kossiakoff | Systems engineering principles and practice[END_REF]. The International Council on Systems Engineering (INCOSE) has supported a Systems Engineering journal. Industry publications have tended to be in the form of handbooks, with NASA's Handbook of Systems Engineering [4], as a prominent example.

While not originating until literally the 21 st century, Product Lifecycle Management has an even less body of work. One of the first papers defining PLM as a new paradigm was my 2005 paper [START_REF] Grieves | Product Lifecycle Management: the new paradigm for enterprises[END_REF]. The two seminal books defining and explaining PLM are generally considered to be Stark [START_REF] Stark | Product lifecycle management : 21st century paradigm for product realisation[END_REF] and Grieves [START_REF] Grieves | Product Lifecycle Management: Driving the Next Generation of Lean Thinking[END_REF]. The advances in PLM have been primarily driven by PLM software providers and their industry users, with the literature confined primarily to conference papers. Again, the lack of take-up in the academic community can be attributed to PLM's multi-domain and multi-phase orientation.

With the paucity of literature on both these disciplines, it is unsurprising that there are few papers linking Systems Engineering with PLM, but none proposing that PLM and Systems Engineering are closely related.

PLM and Systems Engineering

From a review of the literature, Product Lifecycle Management is literally a 21 st century concept. However, PLM did not burst on the scene fully formed. Instead, it had its technological predecessors. I had proposed that the threads that made up Product Lifecycle Management were: Computer-Aided Design (CAD), Engineering Data Management (EDM), Product Data Management (PDM), and Computer Integrated Manufacturing (CIM) [7, pgs. 45-54] In retrospect, I realize that this perspective was one of an information systems perspective and that that there was a major conceptual thread that I had ignored. That conceptual thread is Systems Engineering (SE).

Having minored in Systems Engineering as an undergraduate, I have long felt that there was commonality between Systems Engineering and Product Lifecycle Management. My work with NASA, where the scale and complexity of systems do not come much bigger, allowed me to think through the connections between SE and PLM [START_REF] Caruso | Product Lifecycle Management and the Quest for Sustainable Space Explorations[END_REF]. I suspect that Systems Engineering and PLM will get closer over time as PLM begins to manage product information that was previously "managed" as documents. A major example of this is the requirements of a system whose management consisted of engineers keeping in mind a series of "shall" statements contained in a systems requirements document.

At the risk of overreaching, I will, in this paper, make a fairly good argument that PLM extends Systems Engineering and that PLM needs to incorporate Systems Engineering as a major methodological component. PLM adds a dimension of virtuality to Systems Engineering in order to trade off information for wasted physical resources.

Systems theory is mathematically based [START_REF] Bertalanffy | An Outline of General System Theory[END_REF]. Systems Engineering is a rich and robust concept, with mathematical underpinnings. It has been crucial in organizing major engineering projects. The description of it here will be by necessity cursory, keying in on elements that will be relevant to the discussion of Product Lifecycle Management. Rather than getting buried in the details of Systems Engineering, the purpose here is to focus on the major aspects that will highlight the linkages to Product Lifecycle Management.

Defining Systems

The idea of systems is that they are not monolithic things, but consist of components that are connected together to produce results that the individual components could not produce by themselves. This means that there is more than one component within the system rectangle that operates on the inputs and that are linked together. One such representation is shown in Figure 1.

Fig. 1. Systems Definition Model

There are numerous definitions of systems, both tangible and intangible. I would like to propose the following definition of a system for the purposes of this discussion on Systems Engineering and PLM:

A system is two or more components that combine together to produce one or more results from one or more inputs.

Products such as airplanes, power plants, and medical scanners fulfill this definition. However, these are systems within a system. Airplanes are in themselves fantastic systems, but they are also part of a larger system that consists of airports, air traffic control, refueling trucks, and other systems that make up our air transport system. PLM originally dealt with only the isolated product. PLM was concerned with the makeup and changes in the product itself. The mental view of PLM was of a series of the isolated product suspended in virtual space, reflecting the changes as the product progressed throughout its life. However, as PLM rapidly evolved, it began concerning itself with simulating the product in its environment. PLM now can be said to involve the interaction of the product and the environment that the product operates in. This makes PLM not only about the isolated product. It makes PLM also about the environment it finds itself in. PLM concerns itself with how inputs affect the product and what effects the product has on its environment. In other words, PLM is about product systems.

Defining Product Lifecycle Management and Systems Engineering

My definition of Product Lifecycle Management is:

Product Lifecycle Management (PLM) is an integrated, information-driven approach comprised of people, processes/practices, and technology to all aspects of a product's life and its environment, from its design through manufacture, deployment and maintenance-culminating in the product's removal from service and final disposal.

This definition, while slightly changed over time, goes back to 2003 and first appeared in an early executive article on PLM [START_REF] Stackpole | There's a New App in Town[END_REF]. This definition of PLM and derivations of it, both attributed and unattributed, are widely used. The definition emphasizes a product-focused perspective throughout the product lifecycle rather than a functional area perspective, e.g., engineering, manufacturing, etc.

The NASA Systems Engineering Handbook [4] defines Systems Engineering as "a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of the system." This definition has a great deal in common with the definition of Product Lifecycle Management. These two definitions move even closer when I update my definition of Product Lifecycle Management, as I did in my recent book [11, pg. 28] that PLM is involved not only with the product but also with its environment. A product and its environment can certainly classify as a system.

The NASA handbook goes on to describe a system as a collection of different elements that deliver functionality that could not be gotten from the individual elements by themselves. Much like Product Lifecycle Management, Systems Engineering also views that the system is not simply the physical product or artifact, but that it is also composed of the surrounding environmental aspects including people, facilities, and processes that produce the functionality that the system intends to deliver.

Systems Engineering looks at the parts of a system in a holistic, integrative way as opposed to looking at each of the parts individually. Systems Engineering primarily concerns itself with two major elements. First, Systems Engineering concerns itself with the system that needs to be created to provide a desired functionality. Second, Systems Engineering concerns itself with the development lifecycle phases that enable the creation of this system. While Systems Engineering professes to be concerned with the entire lifecycle of the system, the reality is that it primarily focuses on the development phase of the system.

Systems Engineering starts with a view that a system needs to produce certain functionality. As shown in Figure 1, the view of a system is that of having inputs (arrows from the left), actions (rectangles), and an output (arrow on the right). The output is the functionality of the system, and it is defined as the requirement that the system must meet. The task of Systems Engineering is to determine what inputs are available and what types of devices it can create that will use those inputs in order to produce the actions that will create the required output.

For example, if we want to move an airframe through the air, we have earth's atmosphere as an input. Therefore, we can drive this airplane with either a propeller that creates the action of pulling the airplane through the air or a jet engine that creates the action of pushing the airplane through the air. However, if we want to travel in outer space, we no longer have air as an input, so therefore we have to create a different kind of mechanism, a rocket, in order to create the action that we need.

The premise behind Systems Engineering is that a system can be decomposed into its components and that these components have to interact interdependently in order to produce the requirements that we desire. Systems Engineering decompose the overall system into smaller and smaller units until it gets to individual items called parts that then must come together in order to produce the desired requirements results.

Systems Engineering therefore is about breaking down systems such as a pacemaker, automobile, or space shuttle into more and more discrete levels, and at each of these levels duplicating the system of inputs, actions, and outputs. In addition to simply cascading these system diagrams as the system components get more granular, Systems Engineering has created a number of different representations to reflect this drilling down of system behavior.

The twofold problem that Systems Engineering wrestles with is that in order to obtain specific individual requirements the system has to be decomposed into finer and finer components. At the same time these components have to be coordinated with each other in order to produce the overall system behavior that the Systems Engineering people desire.

Requirements to Verification and Validation

Systems Engineering begins with a list of requirements that the system must meet. These requirements are generally expressed as a series of "shall" statements, as in "the system shall exhibit this particular behavior." Matching up to these "shall" statements are validations and verifications [START_REF] Grady | System validation and verification[END_REF] that sufficiently demonstrate that the designed system meets these requirements.

This issue always is that the only way to be completely comfortable that the requirements of the system are really met is to observe how the system performs throughout its entire life. That, obviously, is not feasible, so preparing validations and verifications that will test for the behaviors that are the outcome of our requirements is our proxy for observing the system over its life.

In order to adequately define and perform these validation and verification tests, the requirements must be defined with enough specificity to judge whether or not the system met its requirements. Requirements that an automobile be safe or an airplane be fuel efficient is inadequate. There must be measurable specificity to requirements.

There are a number of common issues that arise. The major issue is that the verifications and validations are either not appropriate or not exhaustive enough to demonstrate that the actual system will meet its requirements in use. That has been a flaw in classical Systems Engineering. While Systems Engineering brought a much more systematic approach to design and engineering, the document-based nature of SE meant that verification and validation was often confined to the usual suspects and siloed within sub-systems. As discussed below, PLM can make this richer and much more robust through simulation.

In addition, the lessons learned from the performance of the system in actual use were not fed back into the requirements and/or validations and verifications. As a result, system engineers made preventable errors over and over again, wrongly believing that their requirements translated into actual performance.

As a final note, there are constraints on requirements that must be taken into consideration. It is rare that system engineers have a completely blank sheet of paper on which they can start to set out their requirements. System engineers are generally constrained in the design phase by the technology, subsystem, or platform they select or are required to use. The manufacturing systems that they have available may constrain what they can actually build. The support network may constrain how the product can be sustained. This is not necessarily bad in that there is a history that the requirements can be met with the corresponding verification and validation tests.

Models, System Engineering, and PLM

The term model has at least two meanings that are in play with Systems Engineering and PLM. A model is an abstract representation that helps us visualize and understand something that we cannot directly observe, such as a process for doing product design or something we want to distill down to key aspects, such as a product's behavior. These are two types of logical, abstract models that we will look at: things that we do to realize products, process models, and things that products do, behavior models. A model can also mean a mathematical representation of a physical object, such as a CAD model. This type of model is a spatial model. Systems Engineering uses models in the first way, while PLM uses the word in both meanings.

Given the era that Systems Engineering was developed in, it did not require a reliance on computing technology in order to enable it. Thus, Systems Engineering models are of the atom-based, two-dimensional, static kind. More informally, Systems Engineering models consist of documents, blueprints, and flow charts. When Systems Engineering requires three-dimensional, dynamic models, it relies on building physical prototypes.

Process Models

Figure 2 shows the different representations, which are referred to as a Waterfall representation, Vee representation, and a Spiral representation. These representations are all reflective about the idea that the system is deconstructed into ever more discreet components until it reaches the most basic component which is then designed. These basic components are then assembled up the hierarchy until they become the entire system.

Fig. 2. Systems Definition Model

There are both similarities and differences between the Systems Engineering model and the Product Lifecycle Management models. On the similarity side, the Waterfall model of Systems Engineering does deal with the entire product lifecycle, even though the Vee model and the Spiral model do not. While the PLM model, as shown in Figure 3, does deal with the product development phase, the Vee model and the Spiral model deal more extensively with product development, as illustrated by the activities their models describe. The PLM model is an integrated model. The functional areas are arrayed around an inner core of information about the product that the functional areas either populate or consume. There is also a natural sequence to the create, build, support, and dispose nature of the product lifecycle. However, also implicit in the circular arrangement is the idea that functions can occur concurrently with each other as the information becomes available. Manufacturing, for example, can begin to design its build processes as the design of the product takes shape.

Systems Engineering, in spite of what might be its actual messy practices, has a logical, sequential flow about it models. Product Lifecycle Management, on the other hand, has a concurrency in terms of activities that take place surrounding the product.

3.2

Behavior and Spatial Models I have elected to cover the behavioral and spatial models together. The reason for this is that the function and form of the product are closely interrelated. As the old adage goes, "form follows function."

Figure 4 divides spatial form information into two categories two-dimensional and three-dimensional. It also divides behavioral information into two aspects, static and dynamic. If we lay these out in a matrix, we can see where both Systems Engineering and Product Lifecycle Management fall in dealing with both form and functional product information.

Fig. 4. Systems Information Behavior and Representation

If we look at the quadrant for two-dimensional product information and static behavioral analysis, we see that both Systems Engineering and PLM deal with this information. This information is primarily document based. Two-dimensional spatial information is realized as drawings. Static behavioral information can be thought of as documents that deal with the results of analysis. The behavioral aspects of the product in static mode would be set out in requirements of formulas, analyses, and test results as captured in documents.

The line between static and dynamic behavior can be a little fuzzy. The analysis of a change in material deformation versus pressure applied over time would be dynamic in the sense that it would show changes over time. However, the Systems Engineering has typically dealt with this analysis as a series of computed points. PLM extends this with a continuous simulation that could stop and examine any point in time or any interval. Systems Engineering's analysis would be classified as static, while PLM's analysis is dynamic. Systems Engineering can be thought of dealing with a series of snapshots, while PLM deals with both snapshots and film.

Some in Systems Engineering will argue that they are now dealing with dynamic simulations. I would agree that this is the case since the advent of computers. However, Systems Engineering has a methodology that does not depend on it being enabled by technology. Because of that, I categorize Systems Engineering as being concerned with static analysis and PLM as being concerned with both static and dynamic analyses.

When it comes to dealing with three-dimensional spatial information, Product Lifecycle Management concerns itself with spatial models, while Systems Engineering does not. Again this may be a matter of definitional issues, in that System Engineering techniques and methodology may be applied to evaluating three-dimensional models. However, if we think of Product Lifecycle Management as extending Systems Engineering, then the Systems Engineering methodology becomes Product Lifecycle Management methodology.

The final quadrant, three-dimensional spatial models and dynamic behavioral models, are clearly the area of Product Lifecycle Management. As has been discussed extensively in my recent work, the use of simulation and virtual models in dynamic settings sets Product Lifecycle Management apart from its predecessors. It is in this quadrant that virtual products operate in independent virtual space.

Not only can the spatial elements of the product replace the use of expensive physical prototypes for visual purposes, virtual products can be put through extensive testing and simulation in order to determine what characteristics that the physical product will have. Again Product Lifecycle Management is not something entirely new. It takes the methodology of System Engineering in order to extend static, documentbased information and analysis into three-dimensional dynamic virtual simulation of products.

Model-Based Systems Engineering

This focus on the system as an abstract, logical model from a behavioral perspective developed into a sub-branch of Systems Engineering called Model-based Systems Engineering (MBSE) [START_REF] Estefan | Survey of Model-Based Systems Engineering (MBSE) Methodologies[END_REF]. MBSE has as its premise that a system that meets its defined requirements can be mathematically modeled. This is done by breaking down the system into its logical components and defining the behavior of these components and their relationship to other components.

Modeling languages were then created to do just that. One such modeling languages, called SysML [START_REF] Friedenthal | A practical guide to SysML : Systems Model Language[END_REF], was developed in order to provide a standard for the system modeling that Systems Engineering concerns itself with. Modeling languages for MBSE are not simply languages like computer languages, but they also incorporate diagrams to show the flow of the system.

The system modeling language is basically a much more sophisticated version of the system models shown in Figure 1. The intent of this modeling language is to model inputs, actions, and outputs of the discrete elements of the system and link these discrete elements together in order to have an accurate, albeit abstract, view of the system.

While subsequently, computer tools have been developed in order to automate this systems method, it still remains an abstract version of the system. While this is the useful representation of the system, there generally is a major leap between this abstract version of the system and the three-dimensional parts and components that need to be created in order to produce the system behaviors. An assumption with Systems Engineering was that physical prototypes would need to be built in order to provide the rich detail that would be needed in order to actually test out the system assumptions.

PLM Models

Product Lifecycle Management, on the other hand, has much richer system representations. Given the technology that enables it, PLM not only models abstract systems behavior and characteristics, but it can also model the actual geometric representation that will provide these characteristics and behaviors. The Systems Engineering model might show a box that represents the wing control surface. This control surface has as its inputs its current angle and the pilot's command to change that angle. The output is a number that represents the new angle of the surface.

Product Lifecycle Management's simulation shows a representation of the actual wing and control surface. It will simulate in a visual fashion the actual movement of the surface as a pilot issues his commands. In addition, the simulation can incorporate external variations such as horizontal and vertical airflows in order to show how the wing surface will actually react in its natural environment. While Systems Engineering models are relatively static, Product Lifecycle Management models are dynamic.

Systems Engineering does not deal with spatial models, except as two-dimensional documents, i.e., drawings. Product Lifecycle Management does deal with spatial models. It is these two different uses of the term "models" that is often confusing. Systems Engineering in MBSE uses "models" as an abstract, logical representation.

Product Lifecycle Management uses it to represent spatial models that incorporate the behavioral characteristics.

Systems Engineering produces numerical or logical representations as its reflection of systems performance. Product Lifecycle Management produces those same numerical or logical representations, but then transforms them into spatial representation of systems performance. However, because computing enables it, PLM produces its representation of systems performance in a much richer, more granular fashion. Using the example above, Systems Engineering might give the angle of the control surface as a specific number. A PLM simulation can show the entire length of the control surface and show that some areas of the surface might have a different angle than other areas because of material deformation, weight distribution, or other factors.

Figure 4 illustrates how Systems Engineering and Product Lifecycle Management would map out in a quadrant with spatial models and behavioral models. As illustrated here, Systems Engineering provides some complexity of behavioral models and little or no complexity of spatial models. Product Lifecycle Management, on the other hand, provides fairly high levels of both visual and behavioral models. This is not to say that Product Lifecycle Management replaces Systems Engineering, but is to say that Systems Engineering is the methodology that creates the complex models that Product Lifecycle Management maintains and uses.

Product Information Feedback Loops

While technically systems can operate perfectly well by taking required inputs, performing routines and operations on them, and delivering an output, most systems operate with what is called a feedback loop. The feedback loop is the idea that the output is looked at with respect to a desired goal, and then the inputs and/or routines are modified in order to change the output to close the gap between what the output is producing and what is desired. Sometimes the feedback loop is internal to the system, such as the governor on a motor. At other times, the feedback mechanism will be external to the system, like a driver who looks at the speed that the automobile is traveling at and adjusts his pressure on the gas pedal or brake. In either case the output is compared against the desired output and adjustments are made to either the inputs or the routines that the system is running.

While this idea of feedback is usually implicit in systems that Systems Engineering deals with, it is also an aspect of the Systems Engineering process itself. A set of requirements is set out for the system. An evaluation or test is defined to see if the system being designed meets those requirements. If it does, then the design is approved.

If it doesn't, either the system design is modified or the requirements are modified.

The issue with Systems Engineering is that the assumption is made that once the system passes these evaluation or test, then the system will actually perform in its usage so as to meet those requirements. Often times, Systems Engineering feels that they have done their job if the system passes the test, irrespective of whether the product can be actually manufactured, or if the product performs to those requirements in actual usage.

Figure 5 illustrates the difference between the Systems Engineering feedback loop and the PLM feedback loop. On left hand side, both Systems Engineering and PLM are in agreement that products are designed that meet requirements. Those designed products undergo verification and validation processes to insure that the designs indeed meet the desired requirements.

Fig. 5. PLM Feedback Loops

However, PLM goes on to do the same sort of feedback for the manufacturing and usage phases. In the manufacturing phase, the product is checked to see whether or not its physical form can meet the requirements set out for it. If it cannot, then that information is sent back to engineering in order to either adjust the requirements and/or develop a new methodology or manufacturing process in order to produce a product that meets those requirements.

In the support phase, the issue of meeting requirements goes from evaluations or tests that are a proxy for those requirements in the development phase to looking at the performance of the product and actual use in determining whether or not the product indeed met its design requirements. Again, if the product does not meet its design requirements in actual usage or if actual usage surfaces additional requirements, that information is then sent back to engineering. At that point in time, it may be too late to do much with the current product, but this should be fed back into a base of knowledge so that engineering can understand the gap between the requirements they thought could be fulfilled and what actually occurred. They then can adjust the requirements for future versions of the product.

Comparing Systems Engineering and PLM

There are currently some differences between Systems Engineering and PLM. Those differences are:

• Systems Engineering is product realization focused while PLM is product lifecycle focused; • Systems Engineering is functionally based versus Product Lifecycle Management which is lifecycle based; • Systems Engineering concerns itself primarily with physical products where PLM concern itself with both physical and virtual products; • Systems Engineering is document based, while PLM is digital based; • Systems Engineering is a much deeper discipline versus PLM, which is much broader.

Product development focused versus product lifecycle focused

Systems Engineering has primarily focused on the development phase of defining and creating the system or product. It breaks down the product development phase into a number of divisions, such as: Concept Studies, Concept and Technology Development, Preliminary Design and Prototyping, Testing, and Final Design. It then often lumps manufacturing, support, and disposal into an aggregate category.

The implicit assumption is that the system engineering work is pretty much done once the system is designed and meets the testing requirements. The rest of the lifecycle is simply an exercise in execution. System Engineering believes is has done the hard part of factoring the build, support, and dispose phases into its system view. The messy part of actually making those phases work is someone else's responsibility. Systems Engineering's view of the product lifecycle is much like the famous cartoon in the New Yorker Magazine [15] that showed a detailed view of Manhattan with the farther away from Manhattan the view was, the smaller and more insignificant the world appeared to New Yorkers. With System's Engineering, the create phase is the dominant view, with the other lifecycle phases being small and insignificant.

Product Lifecycle Management takes a more balanced view of the importance of the lifecycle phases, with primacy given to the usage phase. The ability of the system design to pass the required tests is not its definition of a product's success. The ability of the product to perform to the user's expectations over the time the product is in service determines whether a product is successful or not. This is not to invalidate the System Engineering perspective. On the contrary, the likelihood of the product to perform well in service is dependent on whether or not rigorous system engineering methodology is employed. However, the feedback loops between manufacturing and engineering and support and engineering need to occur for system engineering to have an accurate understanding of how well their system performed.

Systems Engineering is critical to getting the product lifecycle off to a strong start. However, under PLM, it needs to have more connection to the build, support, and dispose phases. It needs to collaborate in the development process more with those build and sustain phase experts in order to create a system that can actually be built and supported. Systems Engineers need feedback from those phases in order to validate that the system design actually performed to expectations.

Functional based versus lifecycle based

Systems Engineering, as even its name implies, is more about the engineering function than it is about the rest of the lifecycle. While system engineering does profess to concern itself with the rest of the product lifecycle, the build, sustain, and dispose phases, the reality is that Systems Engineering is more about getting a product that meets the defined requirements than it is about following that product through its lifecycle or to see if that it indeed fulfilled its functions in actual use.

In that respect Systems Engineering appears to be a bit siloed. The systems engineer finishes with a product that he or she deems has met the defined requirements, and then throws it over the wall to manufacturing. While Systems Engineering professes to concern itself with the support and sustainment phase, the reality is that the support and sustainment people are generally on their own when it comes to maintaining the product. If there is a major problem, the Systems Engineering staff gets dragged back in, but as a general rule they are done with the product when they hand it over to manufacturing.

Product Lifecycle Management on the other hand takes a broader view of the product. In fact, the product is not deemed to be successful unless it performs in the sustainment phase to the user's expectations. In addition, information from both the manufacturing and the sustainment phase are fed back into engineering to close the loop between what was theoretically possible with the product and what it actually did.

Physical product versus physical and virtual product

Systems Engineering generally concerns itself with the functioning of the product. It creates a set of requirements, and, if the product meets those requirements, the product is deemed to be successful. Systems Engineering does not concern itself with operations manuals, marketing collateral, repair manuals, or repair diagnostics.

Product Lifecycle Management does concern itself with these things and views them to be as important to the product as the actual functioning of the product itself. If a product can perform its requirements flawlessly, but the user does not know how to go about obtaining that functionality, then the product is not a successful or useful one.

5.4

Document-based versus Digital-based

At first glance, it might appear that the elements of PLM are people, process/practice, and technology, while Systems Engineering has as its elements only people and processes/practices. However, paper, pencil, binders, and blueprints are also technology.

The difference is that Systems Engineering is document based, while PLM is digital based. However, the difference is not simply the difference between information being represented in atoms or bits. Moving to digital technology represents a quantum jump in not only the representation of information, but in its handling.

Document-based technology is static, while digital technology is dynamic. If we wish to have a different view of a paper-based drawing, then we have to make a new drawing. If we wish a different view of a digital representation, then all we have to do is request it and the computer will rearrange the information.

Document-based technology requires that people follow the steps laid out in a process and methodology. If they choose not to follow those steps, only the active oversight of other people enforces those steps. Digital technology can enforce following process and methodology steps, both directly by requesting that people comply before allowing them to proceed or indirectly by inspecting the digital information to see if it complies with the process requirements. While people can and often do try to circumvent digital enforcement, it adds a layer of difficulty that simply ignoring documents does not have. In addition, digital oversight does not have to be active. The digital technology can simply produce alerts when there is a lack of compliance, allowing humans to take the appropriate action.

The dynamic aspect of PLM also means that product behavior can be simulated and not simply analyzed as with document-based, static information. Systems Engineering requires that products go to prototypes much earlier and at increased costs.

Deeper versus broader

Systems Engineering is more mature and has had the time to develop into a deeper concept. Systems Engineering has well developed procedures and methodologies concerning how we should go about creating products. Systems Engineering methodologies have evolved over time and have been built upon as issues have arisen and have been tackled.

Product Lifecycle Management is much broader as has been pointed out above. PLM is not only about making the product but is also about sustaining that product. PLM is not only about providing a detailed prescription in how to go about making the product. It is about what information about that product that needs to be captured, organized, and maintained.

6

Suggestions for future direction I would like to close out this paper by making some suggestions for future direction.

In addition to the obvious suggestion that there needs to be more collaboration between the people working on Systems Engineering and Product Lifecycle Management, and that the intersection between the two disciplines needs further fleshing out and investigation, I would like to make three suggestions as to the actions needed in order to meld Product Lifecycle Management with Systems Engineering. These prescriptive suggestions are:

• Organizations should deal with Systems Engineering and PLM together rather than separately, • Systems Engineering should be engaged across entire lifecycle, • PLM should more rigorously adopt Systems Engineering methodology.

Integrate dealings with Systems Engineering and Product Lifecycle Management

Even though Product Lifecycle Management generally starts as a design and engineering initiative, organizations deal with Product Lifecycle Management and Systems Engineering as two distinct disciplines. Systems Engineering standards and PLM processes are dealt with as two distinct things, when they should be considered from an integrated perspective. It is not uncommon to find organizations have two distinct policies and procedures for PLM and Systems Engineering, even as they overlap.

Systems Engineering spends a great deal of time and effort in developing "bluebooks". These bluebooks are the standards for addressing engineering practices and processes. Far too often, these bluebooks are developed at great expense, only to sit on the shelf of the engineer's cubicle. These bluebooks need to be made actionable, so that they are not simply a standard procedure that it is static, but are incorporated in the PLM design and development tools. This is but one example of combining Systems Engineering and Product Lifecycle Management.

Engage Systems Engineering across the lifecycle

As noted above, Systems Engineering often simply fades out in the phases beyond the product development phase. Part of that issue was that systems engineers have very little visibility of the product once it has left their siloed area in the engineering department. With Product Lifecycle Management, systems engineers can remain engaged with the product throughout the product lifecycle. As noted above, the feedback loops from manufacturing, support, and even disposal need to be enabled in order to provide Systems Engineering with the necessary visibility of further product lifecycles.

Systems engineers need to follow the product throughout its life in order to ascertain whether the work that they've done on the front end really did produce a system that performed as required and expected. Simply testing the requirements in the development phase is no longer acceptable. If the systems engineer is to be truly involved with the entire system, then they will have to stop limiting their engagement to the design and development phase.

Adopt Systems Engineering methodology within PLM

In a number of organizations, the information systems group provides the PLM processes and procedures. While that may be acceptable from an information systems standpoint, it often does not address the problems that systems engineers actually have. Information systems needs to be the enabler of this capability, but the Systems Engineering methodology should drive it.

As I noted above, making the engineering bluebook standards actionable is an example of incorporating Systems Engineering methodology within Product Lifecycle Management. PLM has done an excellent job in capturing and organizing product information. It has also begun to develop the workflow issues. It will provide real value when it can enable the Systems Engineering methodology, which up until now has been involved with more static information such as documents and reports.

There are going to be many other opportunities for Product Lifecycle Management and Systems Engineering to integrate and provide additional value to its users. The above suggestions are but an initial list of some obvious areas where this should occur. This area has been under-investigated by both Product Lifecycle Management and Systems Engineering researchers. I would hope that would change in the future.

Fig. 3 .

 3 Fig. 3. PLM Model -Source NASA MSFC


Tobias Bensiek
email: tobias.bensiek@hni.upb.de

Arno Kuehn
email: arno.kuehn@hni.upb.de

Maturity model for improving virtual engineering in small and medium-sized enterprises

Keywords: performance evaluation and improvement, process maturity models, product development process, virtual engineering

This paper introduces the VPS-Benchmark -a maturity model for performance evaluation and improvement in small and medium-sized enterprises (SMEs) with a special focus on virtual engineering. By giving a brief overview on existing approaches for performance evaluation and improvement we point out the demand for a new maturity approach specialized on the requirements of SMEs. The new maturity model will then be introduced. After describing the basic concept of the model, we focus on the performance improvement strategy resulting from its application. The model offers a step by step performance improvement to SMEs. This improvement is based on a so called ACT-concept that motivates SMEs to deal more intensively with virtual engineering and to exploit its benefits by implementing concrete measures.

Introduction

Successful companies in mechanical engineering and related industrial sectors are characterized by efficient and effective processes. Particularly, the product development process is of special interest, as it determines the features of the future product and about 80% of product costs. Methods and tools of Virtual Prototyping and Simulation (VPS) become more and more accepted in these processes. Virtual prototyping means creating and analyzing computer models of products in development. This reduces the number of physical prototypes, improves communication in development processes and helps to avoid design errors. That way, companies save time and money [START_REF] Rix | Virtual Prototyping -Virtual Environments and the Product Design Process[END_REF], [START_REF] Gausemeier | Design and VR/AR-based Testing of Advanced Mechatronic Systems[END_REF].

In the past, lots of domain-specific methods and tools ,for VPS e.g. CAD (computer-aided design) and FEM (finite element method), emerged. The transition from a traditional product development, based on physical prototypes, to an integrated virtual engineering, based on VPS, is expensive and often characterized by costly failures. The integration of these tools into the processes and the PLM-infrastructure (product lifecycle management) of the company is a success factor in the development of complex technical systems [START_REF] Stark | Product Lifecycle Management -21st Century Paradigm for Product Realisation[END_REF]. However, especially small and medium sized enterprises (SMEs) often run isolated applications that are insufficiently integrated into the development process and the PLM-infrastructure. This means that only fractions of the benefits of virtual engineering are exploited.

In order to improve their product development processes, SMEs need support for planning and optimization of their product development processes. Key points of improvement are both, an objective evaluation of current performance as well as a coherent conception for improvement. Maturity models target at these points. [START_REF] Fraser | The use of maturity models/grids as a tool in assessing product development capability[END_REF] This paper starts with specific requirements arising out of the need for maturity models in SMEs. By giving a brief overview on existing approaches for performance evaluation and improvement we point out the demand for a new approach specialized on the requirements of SMEs. The new approach with its focus on an integrated virtual engineering will then be introduced. After describing the framework of this approach, we focus on the performance improvement strategy resulting from its application.

Requirements for maturity models in SMEs

SMEs not only lack the experience in VPS-technologies but also the knowledge about their potential benefits. Additionally, the introduction and integration of those technologies in terms of an integrated virtual engineering requires extensive planning and thus financial and human resources that are often missing. While large companies maintain own planning departments, SMEs have little time to perform process improvement initiatives in addition to the dominant day-to-day business [START_REF] Spur | Das virtuelle Produkt. Management der CAD-Technik[END_REF]. Out of these circumstances specific requirements arise for the application of maturity models in SMEs. These requirements were verified in several interviews with SMEs, vendors and consultants.

 Pragmatic performance evaluation with low effort: Time to investigate possible approaches and the extensive bureaucracy are barriers to use assessment tools for performance improvement [START_REF] Knoblinger | Requirements for product development self-assessment tools[END_REF]. SMEs neither have the time nor the money to get into complex models for performance evaluation and improvement. Thus, an easily learnable and practicable model is necessary. External experts should be at least to some extent unnecessary. Additionally, time for application should be as short as possible and not exceed a few days.  Consideration of performance improvement: Due to the lack of knowledge about potential benefits of VPS, SMEs need concrete recommendations for performance improvement. Thus, the approach has to support the interpretation of the performance evaluation.  Definition of a company-specific target state: Especially for SMEs, it must not be economical to achieve the highest performance level. Considering a SME with only a few engineers, the cost-benefit-ratio of implementing and maintaining a PDM-system is questionable. Ignoring other possible influences, managing data within well-organized file structures would be adequate. The example demonstrates that recommendations have to aim at an individual target state.  Based on best practices: Other barriers to use of assessment tools in industry are the general high resistance towards change and the missing interest of the senior management [START_REF] Knoblinger | Requirements for product development self-assessment tools[END_REF]. To achieve acceptance among the management and the employees, it is important to base all resulting performance improvement recommendations on proven practices from industry and science.

The model presented below has been created considering the guidance for developing maturity models of de Bruin [START_REF] De Bruin | Understanding the Main Phases of Developing a Maturity Assessment Model[END_REF], Christiansen [START_REF] Christiansen | Methode zur Klassifikation und Entwicklung reifegradbasierter Leistungsbewertungs-und Leistungssteigerungsmodelle[END_REF], Kohlegger [START_REF] Kohlegger | Understanding Maturity Models -Results of a Structured Content Analysis[END_REF] and Maier [START_REF] Maier | Developing maturity grids for assessing organisational capabilities: Practitioner guidance[END_REF].

Performance evaluation and improvement using maturity models

According to current estimates, more than 200 different maturity models are available [START_REF] Harmon | Process Maturity Models[END_REF]. Therefore, structuring the state of the art of performance evaluation and improvement is necessary.

Selecting an optimal model depends on two main factors. First, the model has to fit the area of interest. Existing models cover a wide spectrum of different applications. CMMI-DEV (Capability Maturity Model Integration for Development) e.g. focuses on product development, ITIL (IT Infrastructure Library) on IT management and SPICE (Software Process Improvement and Capability Evaluation) on software development [START_REF] Harmon | Process Maturity Models[END_REF]. Also for virtual engineering and PLM there are already existing models, such as "ENGINEERING produktiv!"1 or Batenburg [START_REF] Batenburg | PLM roadmap: stepwise PLM implementation based on the concepts of maturity and alignment[END_REF].

Second, the methodology of the maturity model must match the user's requirements. The methodology has an impact on features such as the consideration of performance improvement, the assessment system and the effort for training [START_REF] Christiansen | Methode zur Klassifikation und Entwicklung reifegradbasierter Leistungsbewertungs-und Leistungssteigerungsmodelle[END_REF].

Comparing CMMI-DEV and PEMM (Process and Enterprise Maturity Model) demonstrates that these features differ heavily between the available models. Introducing CMMI-DEV in a company requires intensive training of staff and involvement of different divisions [START_REF]CMMI® for Development, Version 1.2[END_REF], [START_REF] Chrissis | CMMI. Guidelines for Process Integration and Product Improvement[END_REF]. A complete implementation of CMMI-DEV often requires months (depending on company size). In contrast, PEMM is a very pragmatic approach that can be applied with minimal effort and without trained staff. In a selfassessment the maturity levels can be determined within days [START_REF] Hammer | The Process Audit[END_REF].

Due to the variety of these models, selecting an appropriate maturity model is difficult. Therefore, the Heinz Nixdorf Institute developed a classification of models for performance evaluation and improvement [START_REF] Christiansen | Methode zur Klassifikation und Entwicklung reifegradbasierter Leistungsbewertungs-und Leistungssteigerungsmodelle[END_REF]. Mettler [START_REF] Mettler | A Design Science Research Perspective on Maturity Models in Information Systems[END_REF] and Van Looy et al. [START_REF] Van Looy | Which Maturity Is Being Measured? A Classification of Business Process Maturity Models[END_REF] describe alternative classification approaches. One type of maturity models are selfassessments. Self-assessment tools allow to get a quick (a few days) impression about the current performance of a specific area of the company. They are interesting due to the low effort resulting from its pragmatic application. This tools best fit the requirements described in section 2.

The disadvantage of these models is the missing consideration of performance improvement. Röglinger et al. [START_REF] Röglinger | What makes a useful ma-turity model? A framework for general design principles for maturity models and its demonstration in business process management[END_REF], [START_REF] Röglinger | Maturity Models in Business Process Management[END_REF] describe the missing of a defined mechanism to select improvement measures and derive an improvement strategy. Most of these models only offer a visualization of results in diagrams, showing the current performance. Hence, deriving concrete measures to improve performance requires expert knowledge. As the SMEs often lack this knowledge, they are reliant on specialists supporting the development of a performance improvement strategy. Therefore, an approach is needed that on the one hand is based on a pragmatic self-assessment and on the other hand gives concrete measures for performance improvement. As already mentioned in section 2, the highest level of performance must not be the most economical one for a SME. Thus, the approach also has to support the definition of a company-specific target state.

A maturity model for process improvement in SMEs

In the following, we introduce the VPS-Benchmarka maturity model for performance evaluation and improvement focusing on virtual engineering. The model allows a quick and easy evaluation and identification of potential process improvements. Additionally, the strategic planning of VPS-usage is supported. The target group are SMEs in mechanical engineering and related industrial sectors. In section 4.1, we explain the basic concept of the maturity model. In section 4.2, we detail the application of the model and the performance improvement.

Basic concept of the maturity model

The procedure of the VPS-Benchmark is structured in 3 parts (figure 1): performance evaluation, definition of target state and performance improvement. In the following, we describe the framework of the maturity model. Therefore, we use an intuitive example, the introduction of a PDM-system. The left wing, the performance evaluation, consists of 4 elements. These elements are closely related to the basic structure of typical maturity models as described in [START_REF] Christiansen | Methode zur Klassifikation und Entwicklung reifegradbasierter Leistungsbewertungs-und Leistungssteigerungsmodelle[END_REF].

 Areas of action categorize the area of interest according to superior criteria, such as organization and technology. They ensure that all relevant facets are considered without having a one-sided perspective. In the context of VPS we consider 5 areas of action. An example is data management.  Action elements are performance indicators for the particular area of action. For each area of action there are 20 to 50 action elements. An example is the application of a PDM-system. Action elements are formulated as questions, such as: "How do you manage your product data?"  Performance levels are the predetermined answers to the questions of the action elements. They indicate in which stage of development the action element is established. A low performance level would be well-organized file structures.  All performance levels are associated with maturity levels. Maturity levels express the performance of an organization in an objective and measureable manner. Consequently, a high maturity level means a high developed action element and thus a good performance in the particular area of action.

Beyond the current maturity level, the definition of the target state is required for deriving a strategy for performance improvement. A company-specific target state is defined in the right wing of the framework.

 Areas of influence are the equivalent to the areas of action in performance evaluation. They ensure that all relevant aspects are considered, which have an impact on the definition of the target state. Areas of influence in the context of VPS are the company, its products and its business environment.  Influences and its expressions indicate in which stage of development the action element should be established. Similar to the action elements and performance levels they are formulated as questions with predetermined answers. In the example, we win the information that the company has 20-40 engineers.  Out of the information given by the influences and its expressions, we can derive a recommendation for the target state expressed as target maturity level. In the example, the use of a PDM-system would be recommended to optimize the data management. The target maturity level is the equivalent to the maturity level in performance evaluation.

The bigger the difference between target maturity level and initial maturity level, the higher the need for action. The question arising is how to achieve the desired target state. This question is answered by the third part, the performance improvement.

 The comparison between target maturity level and initial maturity level provides recommendations for improvement in form of concrete measures. In case of the given example the measure would be introduce a PDM-system.  As there can be a lot of resulting measures, a strategy for their implementation is needed. This performance improvement strategy must include a prioritization of measures in terms of a cost-benefit-evaluation.

All results are collected in a so called benchmark-database. This database allows a benchmark between companies that underlie similar influences. Having enough data sets, the conclusion could be: 60% of the companies that underlie similar influences already use a PDM-system.

The basic concept of the model is described in figure 2. We differentiate between the development and the application of the maturity model. Both are interconnected by an interactive questionnaire, which will be available on an internet portal2 .

Fig. 2. Basic concept of the maturity model

The development of the maturity model is based on expert knowledge that is prepared and converted for the interactive questionnaire. The elements of the framework and their interrelations represent the expert knowledge. The knowledge is gathered in expert-workshops. We differentiate between three types of experts:

 Vendors are specialists for dedicated VPS-tools, such as CAD-, PDM-or CAEsystems. They know best about the functional range of their tool and its potential benefits.  Consultants can compare various product development processes and the advantageous application of VPS. They are specialists for optimal process integration.  Commendable SMEs provide best practices. They know best about their particular requirements.

The expert knowledge is prepared via matrices, profiles and lists. A detailed description of the preparation and analysis is given in [START_REF] Röglinger | Maturity Models in Business Process Management[END_REF].

Application of the maturity model

The SME applies the maturity model by answering the questionnaire. To cover all relevant facets of virtual engineering, the questionnaire should be completed in a team including representatives from engineering, sales, marketing, production and documentation. In a first step, the SME answers questions to various topics of VPS. Herewith, the current state expressed as maturity level is evaluated. In a second step, questions about the company, its products and its business environment are asked. This information determines a company-class and a company-specific target state. A comparison between current and target state delivers the need for action. To close this gap the SME has to ACT (acceptcomprehendtap). In figure 3 the path from identifying the need for action to improvement is described as the ACT-concept.

Fig. 3. ACT-concept to improve the performance of VPS in SMEs

The ACT-concept distinguishes three stages:

 First, accept the need for action: Process improvement always goes along with change. To accept this change, the company must be aware of the need for action. In this stage, intuitive diagrams visualize the need for action without being too detailed.  Second, comprehend the need for action: After accepting the need for action, the question will be what to change in detail. This is answered by showing the company's strengths and weaknesses for each action element.  Third, tap the need for action: Adequate measures are needed to overcome the weaknesses. Therefore company-specific measures are recommended. These measures are detailed in measure-profiles, which deliver the necessary background for the SME.

The ACT-concept motivates the SME to deal more intensive with VPS and to identify and exploit all benefits of virtual engineering. In the following we detail the three stages of ACT.

Fig. 4. Stage ACCEPT of the ACT-concept

Stage ACCEPT visualizes the need for action in diagrams (figure 4). The performance profile displays the user´s maturity level for each action field. This allows a quick overview of the current performance. In addition, the target state is displayed. The target state is determined individually from the company-class. From the distance between current state and target state the need for action can be derived. The benchmark radar chart shows the performance of the company in comparison to the performance of other companies. These striking visualizations should be used to convince the management of expanding the use of VPS.

Stage COMPREHEND details the need for action (figure 5). Therefore, the action elements in which the SME does not reach the recommended performance levels are displayed. Icons indicate whether the current state differs from the target state. Information from this stage is particularly relevant for persons, who are concerned with performance improvement in product development, e.g. the development manager. This group of people needs a thorough understanding of the strengths and weaknesses of the organization.

Fig. 5. Stage COMPREHEND of the ACT-concept

As SMEs should only aspire economically advantageous performance levels, it is important that the need for action is derived from the company's individual target state. We emphasize this with an example. Two times per year an SME is challenged by the integration of a dryer into his system. As the drying process is of crucial importance for product quality, the company decides to buy a suitable CFD 3 -tool and to simulate the process in-house. It quickly recognizes that the effort for practice is very high. In addition, the simulation results deviate from reality, because the boundary parameters are not defined properly. Simulating the second dryer a few months later, it can barely remember the operation of the CFD-tool. It decides to quit working with the tool. The investment in software and many staff hours are lost. Besides the economic loss also the trust in VPS suffers, since the SME now decides that CFD is too complex and unnecessary. In this case, the SME would have been more successful, if it would have started on a lower performance level. It should have engaged an external service provider for simulation. So it can gain experience in the field of CFD without taking risks.

The step TAP shows a possible way to close the gap to the target state (figure 6). The comparison between maturity level and target state allows deriving concrete measures for performance improvement. These measures are presented in measureprofiles. As most SMEs require a lot of measures, a simultaneous implementation of all measures often is neither economical nor organizational reasonable. Therefore, the cost-benefit-ratio allows a prioritization of measures.

Conclusion and Outlook

The paper started with a brief overview on existing approaches for performance evaluation and improvement. We pointed out that specific requirements arise out of the need for maturity models in SMEs. SMEs neither have the time nor the money to get into complex models for performance improvement, such as CMMI (Capability Maturity Model Integration). We introduced an approach for maturity based process improvement that is suitable for SMEs and focused on virtual engineering.

The approach achieves all the specific requirements that arise out of the need for maturity models in SMEs. The interactive questionnaire supports the performance evaluation and is easily applicable. Due to the fact that the questionnaire is internet based no special software is required. Additionally, only a short time for application is necessary. The questionnaire can be completed in not more than two days. Through the prepared expert knowledge it is based on best practices and no external consultants are necessary. The analysis of influences defines an economical companyspecific target state. Concrete measures for performance improvement are recommended.

The developed maturity model offers a step by step performance improvement to SMEs. The ACT-concept motivates the SME to deal more intensive with VPS and to exploit its benefits. In Future works, the maturity model will be validated in SMEs. Therefore we will compare the results of the VPS-Benchmark with the results of consultants.

Fig. 1 .

 1 Fig. 1. Framework of the maturity model

Fig. 6 .

 6 Fig. 6. Stage TAP of the ACT-concept

Internet portal of the initiative ENGINEERING produktiv!: http://www.engineeringproduktiv.de

The internet portal www.viprosim.de promotes the usage of VPS especially in SMEs.

Computational Fluid Dynamics (CFD) means the computer-aided simulation of fluid mechanics[START_REF] Wendt | Compuational Fluid Dynamicsan introduction[END_REF]

Acknowledgement. This contribution was developed in the course of the project "Virtual Prototyping and Simulation Benchmark: tools for analysing and optimizing the use of virtual prototyping and simulation in the product development process" funded by the Ziel-2 programme "Hightech.NRW" of North Rhine-Westphalia. This is a part of ERDF: European Regional Development Fund.