2.6 Trends in PDM

---

This chapter contains a short survey of trends in PDM research and development and of the use of PDM in industry.

2.6.1 Trends in research and development of PDM

PDM as a research field is not yet fully consistent. There are no unifying theories and the definitions are sometimes vague. This may be because the scope of PDM is wider than that of many other research areas. PDM aims at managing product development information throughout the entire PLC and intersects with several other disciplines, such as requirements management. It is difficult to develop theories and knowledge in a comprehensive domain, and few PDM researchers and developers use PDM systems on a daily basis for their ultimate purpose (i.e., to assist in the design of products).

Research in the field of PDM has a wide scope and has to cover more areas than information systems and data management methods only. How data is represented and structured is an important issue. To be able to discuss these matters, theories for the structuring of the things represented-the products-are needed. This has become a separate area of research, known as product models, dealing with how products should be represented by information models and represented in databases. This area and other important areas of research on PDM will be presented in the following section.

2.6.1.1 Deployment of PDM systems

The deployment of PDM systems is more than a question of technology. Sufficient knowledge of company-specific processes and what they require of PDM systems is crucial, as several processes in the PLC are affected by a PDM implementation. Research in this field mainly deals with the technical aspects of product data management, such as computer systems and data representation. More research is needed into the deployment of PDM systems, system strategies, and applications of PDM, such as CM and document management. This section lists some of the research into system deployment and strategies.

Pikosz et al. [20] discuss different strategies for the deployment of PDM systems. PDM can be introduced by beginning with limited functionality, implemented companywide across several projects, or as a complete PDM system introduced in a single project. Risks were observed with the introduction of a complete system. Many introductions are therefore now performed in a phased manner, with the functionalities implemented in steps, beginning with a few basic functions.

Companies using PDM have differing objectives. Some are operational, such as improved support for information management, but PDM solutions may also address business drivers, such as time to market, product quality, and product development cost. The operational effects of PDM are more evident than the effects on a company's business performance. Harris [21] states that there has been little research performed on the connection between PDM system strategies and a company's overall business strategy, either directly or through a higher level information system strategy.

PDM systems can play an important role in a high-level information system strategy through their integration capabilities. It has earlier been observed that PDM systems are mostly used by the design discipline [22]. This situation is likely to change, especially on the tool side. This is because the aim of PDM system suppliers is to support a larger part of the PLC, but the integrational capabilities of the PDM systems are not yet fully exploited. The main challenge in future research in this area will be to merge all local solutions used in the PLC phases using an integrated approach in supporting the entire life cycle. PDM technology will have a key role in such a system.

2.6.1.2 Collaboration

Ways that PDM can be applied to support collaboration was mentioned earlier in this chapter. Collaboration is supported not by adding new data management functionality to the system, but by packaging already existing functionalities together with methods for data access via Web interfaces (from inside and outside firewalls). The trend here is about applying standard functionalities and improving access possibilities, and then marketing these under the keyword collaboration. Commercial PDM systems of today support what is designated CPM or CPC.

2.6.1.3 Product structure management

Product structure management (PSM) plays a key role in product data management in the manufacturing industry, which uses product structures in both design and manufacturing activities. The aim of PDM with respect to PSM is similar to the overall aim of PDM: support for the complete PLC. The trend in product structure management is therefore to provide improved support for the various types of product structures used throughout the PLC, such as design structures, manufacturing structures, and delivery structures.

PSM research is focused on the support of manufacturing activities. The use of BOMs has been quite extensively covered [23-26]. One challenging problem is the handling of variants of products (see Section 2.5.3).

Another issue is the handling of domain-specific structures and views of structures. Various types of product structures are used by different disciplines in a company, each having different requirements with respect to the decomposition of the product structure. Designers are likely to prefer decomposition into systems and subsystems, while manufacturing uses an assembly decomposition of a structure [23]. Svensson and Malmqvist [26] discuss strategies for cooperation between systems containing different views of a product structure, concluding that the conflicting demands have led to a multisystem environment. All changes in a product structure must (automatically) propagate to all information systems containing this product structure, which calls for information system strategies that involve more than the PDM systems used.

2.6.1.4 CM

PDM systems offer possibilities that are not fully exploited by existing CM methods. Traditional CM is a coarse-grained document management, while PDM enables product-centric, fine-grained CM [12], in which configuration identification and control is directly on the product level.

An important part of CM is configuration control, also referred to as engineering change management (ECM). Even if a company does not perform CM in accordance with the standards, companies need to control the changes in their products. PDM technology offers fine-grained ECM and allows changes to be effected at the finest grained object/attribute level. The impact of changes can be identified through relationships, minimizing the overall disruption of a change. This is one example of the possibilities of PDM systems that can be exploited more effectively.

ECM is a part of CM that has been subject to research (e.g., Wright [27] has performed a thorough review of research into ECM). One of the questions asked was how engineering changes drive incremental and stepwise design in different types of companies. While engineering changes can be seen as a source of expense from a manufacturing perspective, they can actually have a positive impact on the product design process. Pikosz and Malmqvist [28] have made a comparative study of ECM to find companyspecific factors in the performance of ECM.

2.6.1.5 Product configurators

A product configurator is used to solve complex problems. It should be able to configure and optimize a product despite restrictions that may be contradictory. In the 1980s, artificial intelligence was a popular approach to the solution of the configuration problem. The problem to be solved has since broadened and now includes knowledge management. To configure a product, the ability to handle both the process of configuring the product and the data and knowledge associated with it is essential [25]. Product configurators are often in-house-developed software and are difficult to update with new products and rules. Mesihovic and Malmqvist [29] suggest that the information needed for configuration could be handled by the PDM system during the development phase. Configuration data would then be available to all needing, it and it would be easier to change data.

In manufacturing, the problem is associated with production control issues and forecasting. The BOM must be able to manage variants. A generic BOM [25, 24] is a BOM capable of managing variants of a product in a single structure, which simplifies the work of keeping structures up to date when a change occurs. Forecasting is another issue that is complicated by variety in products. It is difficult to plan the component if it is difficult to predict which variants of product customers will order. The manufacturing planning system must therefore be able to work on the basis of aggregate information [24].

2.6.1.6 Product models ^[1]

Until relatively recently, an engineer's view of product modeling has been of a purely technical nature, concerned with the problems of creating a robust geometric model in a CAD or CAE system. However, as CAD and CAE environments have developed further and data management systems facilitated the distribution of data, new problems have emerged.

In order to generate a sound product model, it is important to have a clear idea of how to decompose a product. The science of engineering design has created elegant theories, such as the Theory of Technical Systems (TTS) [31], describing the correct structuring of product models, but these are hardly, if ever, used in industry. A more widely implemented technique used to organize and structure information is systems engineering [32, 33]. It was initially created to support the development of complex systems, while the TTS is the result of European research into engineering design. Sharing some features with TTS, system engineering is more concerned with analysis and life cycle management and has been formalized in at least two standards, IEEE 1220 and EIA 632. The European design research has a more product-oriented view, decomposing a specification into a component structure using a so-called chromosome model of a product [34].

These techniques are concerned with high-level structuring of product data. At a more detailed level, interest is increasing in techniques for formalizing engineering know-how, often referred to as knowledge-based engineering (KBE). KBE has been in use a number of years; one of the best-known systems is iCAD, which dates from the mid 1980s.

The need for a systematic way to describe products is clearly increasing in importance as product models now include complex constructs such as rules, variants, requirements, and product configuration possibilities.

2.6.1.7 Product data representation and modeling

Product modeling theory deals only with the structuring of the product, not its representation, for which we need some kind of language. The capabilities of representation have evolved with the development of object-oriented techniques. The capabilities have progressed from lists of values defined by text documents to product models that also take care of the semantics and internal relations within the model. The modeling language that describes the product model must therefore also be able to define these semantics. It is important that both humans and computers can interpret the modeling language to avoid misunderstandings and misuse.

A number of languages are capable of handling product information with semantics. The two languages most frequently used today are the lexical (the language is expressed in text, but can be visualized with the appropriate tools) language EXPRESS [35] and the visual (the language is expressed in graphics and has no lexical representation) language Unified Modeling Language (UML) [36]. Both of these languages are defined by international standards and are not based on any specific implementation technique or specific programming language.

The advantages of EXPRESS, as compared with UML, are its capacity to handle rules and the fact that it was specifically designed to describe product information. UML was originally designed to describe software development projects, but the general structure of the language also makes it suitable for describing product information. It also has the capability to describe processes and display different views of the product information.

2.6.1.8 Databases

Database technology has existed since the early 1960s [37] and is a mature area from both a practical point of view and a scientific point of view. However, handling product data in a database is different from other applications:

• Many different types of objects and attributes are needed to describe a product.

• Large hierarchical structures must be stored.

• The frequency of creation and change of data is high.

• The data models differ between companies.

Most databases used today are relational or object-relational databases, in which data is best stored when structured in lists. Hierarchical structures are best represented by object-oriented concepts. Object-oriented databases are a relatively mature technology but have not been successful to date, mainly because of performance problems.

2.6.2 Trends in industry

Many companies today consider the implementation of a PDM system to be of strategic importance. PDM investments (software and services) in industry increase continuously, from $1.1 billion in 1997 to $1.7 billion in 1999 [38]. Implementations have often been associated with problems and high costs, with services accounting for the greater part of the implementation cost. Even if there is strategic importance in PDM systems, PDM projects are today subject to more strict requirements for well-defined business cases and faster return on investment than they were previously. During recent years, more successful implementations have been achieved, partly as a result of better control of implementation projects, better applications and hardware, and the growing interest in PDM in industry, which results in a stronger commitment to the PDM projects.

In this section, the situation in two larger companies is described: Ford Motor Company and Boeing. The description is based on a report from a study visit to those companies by a group of researchers within the Swedish national graduate school ENDREA [39].

2.6.2.1 Ford Motor Company

Ford is a global company in the automotive industry, producing a wide range of cars: Lincoln, Ford, Mercury, Volvo, Mazda, Jaguar, Aston Martin, and Land Rover. About 60 car programs are developed in parallel. The PDM activities at Ford are mainly coordinated by a project called C3P (CAD, CAE, CAM, and PIM). Ford used an in-house-developed system to manage product data for many years, but finally decided to develop a new computersupported environment for product development, which also involves partners and suppliers. One year later, EDS was chosen as the provider of the CAD system I-DEAS, and the PDM system Metaphase. About four years after the decision, all new car programs were developed in C3P, and the first cars developed in the C3P environment were introduced on the market.

2.6.2.2 The goals of C3P

The vision of C3P is to obtain integration of Ford Enterprise Product Development through Global PIM and Advanced CAD, CAM and CAE functionality. The main forces behind this investment are the demands of concurrent SE and supply chain integration. The measurable targets of C3P were ambitious:

• Lead-time reduction from 50 to 36 months;

• Prototype cost reduced by 50%;

• Reuse of components increased by 30%;

• Late product changes reduced by 50%.

The time-to-market (TTM) goals of C3P have been achieved at both Ford and Mazda.

2.6.2.3 The C3P concept

C3P involves more than information technology. Both the tools and the way things are processed had to be changed. Changing existing working procedures was the big challenge and a large part of the introduction involved training people at Ford and its partners and suppliers. The concept is divided into four CAE views. Digital mock up (referred to at Ford as digital buck) represents the product definition, digital factory represents the production process, digital clay is the styling surfaces, and analytical prototypes are the simulation models. Digital mock up is the most mature area of the four. A digital mock up is a simplified representation of CAD geometry and is used to represent large assemblies, which cannot be displayed in their native format due to performance problems. Ford uses digital mock up to study the fitting together of parts, specifically project manager use it to follow up projects and to support decision making at meetings.

PIM manages the information by means of Metaphase. The PIM installation is based on a tight integration with the CAD tool IDEAS and operates in a distributed environment. A team of designers (about 50) works with their CAD tools, which are connected to a team data manager (TDM). TDM is a miniature PDM system included in IDEAS. The CAD models in the TDM are grouped in master packages. These are copied to a central vault, to which other teams have access. The central vault is connected with the digital mock-up application. By means of this central vault, it is possible to visualize and analyze a complete vehicle, although developed by geographically dispersed teams. The product structure is not stored in Metaphase, only a list of the master packages representing the product. So far, release of parts is not supported in this Metaphase implementation and must be performed in another system.

2.6.2.4 Problem areas of C3P

PIM needs further development. The information infrastructure is causing problems. The connections with Eastern Europe (based on telephone lines) were too slow. Other performance problems were found in the TDMs, when large teams of designers worked with large assemblies. The release of product structures and integrations with legacy systems also need improvement.

2.6.2.5 Boeing

Boeing is in the aerospace industry with a variety of products, including commercial and military aircraft.

Boeing Military Aircraft has chosen to work toward the standardization of information instead of systems. STEP was chosen as the corporate standard for product data exchange and therefore Boeing Military Aircraft will only consider using products that comply with the STEP standard. The partners Boeing works with must be able to use STEP to exchange data.

Boeing Military Aircraft has to deal with a situation in which several CAD systems are used. Take an engine supplier as an example. It supplies engines to other customers, in addition to Boeing. It is not cost efficient for the engine supplier to remake the design for each customer with other preferences regarding the CAD tools used because it is a complex design. Boeing must therefore accept that suppliers use various CAD tools. To verify the complete product with fuselage, wings, and engine, a digital mock up is used, based on a neutral geometry format included in the STEP standard AP 203.

Boeing Military Aircraft uses several PDM systems: Metaphase, iMAN, Sherpa, and Windchill, among others. This does not conflict with the idea of having a single PDM system, but only if it fulfills Boeing's demands. No system available on the market is considered to do this. The use of STEP makes it easier to change or vary PDM systems.

Boeing Military Aircraft has tested the exchange of geometry, parts lists, and change data with STEP. The information is exchanged between engineering and manufacturing databases both within the company and between Boeing and its partners.

Boeing Commercial Airplanes improves the way it builds airplanes by implementing two critical initiatives, lean enterprise and define and control airplane configuration/manufacturing resource management (DCAC/MRM) [40]. Both activities will help Boeing meet its internal goals to reduce costs, cycle time, and defects, and consequently deliver more value to its customers. DCAC/MRM focuses on streamlining the way commercial airplanes are designed and built. The system support includes a PDM system (Metaphase), an ERP system, a product configurator, and a process-planning tool. Some facts about the implementation:

• A total of 39,250 users (July 2001), located in eight states, Canada, and Australia;

• Almost 1,000,000 part numbers in its databases;

• Twenty production databases ranging from 10 to 130 gigabytes in size;

• Estimated Boeing savings: $100M per month.

2.6.2.6 Problem areas and future work at Boeing A common objection to the use of neutral formats is that they do not keep up with the progress of the tools. It can take up to 6 years before a new functionality in a CAD tool is introduced into the standard. There is a trade off between neutral formats and a high degree of functionality of the tools.

A time plan has been formulated, which outlines the introduction of STEP in various areas. Boeing Military Aircraft's vision is that all product data should be stored in open formats. At Boeing Commercial Airplanes, the DCAC/MRM initiative is planned to increase its number of users further to 50,000 users.

^[1]Sections 2.6.1.6 and 2.6.1.7 are partially taken from a report [30] written by a group of researchers within the Swedish national graduate school Engineering Design Research and Education Agenda (ENDREA).

---