Functions of KEDB Product Information Manager 1.0: A Test bed for Product Information Management
in place August 28, 2000 last modified August 31, 2000

- Contents -

KEDB Product Information Manager (KEDB PIM or PIM) 1.0 is a product information management system (or a product data management system, so called PDM). We started the KEDB PIM project to provide a test bed of the advanced IT for the product information management and the realization of the conceptual articles in KEDB (the KEDB articles). This article introduces the main functions of PIM and an example that illustrates them.

OVERVIEW of MAIN FUNCTIONS

KEDB PIM has the function of engineering change management in addition to that of product structure management. It follows the basic concept of the *KEDB product data representation. The concept provides data structure of the PIM and this section describes the main operations on the structure implemented in KEDB PIM. The followings are the description of each function:

Option/Part Master Management

There are two kinds of operations in KEDB PIM: one is a set of operations for the management of part master and the other is a set of operations for the product structure management. The operations on the part master includes create, update, and delete operations.

Structure Change Management

Based on the part master, a designer can create a product structure with add, replace and cut operations. The add operation attaches the copied part to the selected part as its sub part. In another word, it creates a constituent relationship between the two parts. The replace will replace the constituent relationship between the selected part and its parent part. It will change the old constituent relationship to the new one with copied part. The cut removes the selected part from the product structure. With an Engineering Change(EC) object, the change can be recorded and distributed as an engineering change notice(ECN). These operations also can be applied to the constituent relationship between the options and the parts.

Engineering Change Management

In the product structure, the change of a part causes the changes of product structure. The operations for the structure change should be managed consistently, since EC is strongly related other department including suppliers and customers. Engineers can retrieve and manage the history with EC objects provided by KEDB PIM. One of them implemented is ECN at form of comparison table between the old and new parts. The ECs can be organized to reuse the history and to manage EC information consistently. The effectivity of the EC, data shows when the change will be applied to the product, also can be specified to the **options and parts. Exploration of the product structure with a specific effectivity is also supported.

AN EXAMPLE

This section illustrates the described functions though an engineering change of a material handling machine. We borrowed the example machine and product structure from [Sarttory,1988] and modify it for our purpose.

Product Structure

The figure 1 shows the product structure of the material handling machine. There are two end-products, MODEL A and MODEL B and each model has three options. MODEL A is specified with BASE, 20 FEET STRUT and DIESEL ENGINE. MODEL B is specified with BASE, 8 FEET STRUT and ELECTRIC MOTOR. ELECTRIC MOTOR option is about to be introduced in the current product line (The current product line consists of MODEL A.). Designers will change the product structure to introduce the new model and the following sections will describe operations through the process of the engineering change.

Fig 1. The product structure of the material handling machine

In PIM environment designers can create parts and construct the product structure with them. The figure 2 shows the window of PIM that displays the completed product structure of the option, 1100, BASE.

Fig 2. The window of completed option structure of the example

An Engineering Change

Introduction of new electric motor that replaces the diesel engine needs the change of the chassis in addition of the new option of the motor. Designers redesign the current chassis to adapt both the existing engine and the new option. The change of the chassis causes the change of its assembly part, 16500100 --- cart, so the EC of the assembly structure begins with making a new version of the cart (see Fig. 3). Then they also version up the chassis and redesign it (The new part is 16500110 --A).

Fig 3. Version up of the cart, 16500100 ---

The new part 16500100 --A has same assembly structure as the original part 16500100 ---. Now, designers will replace the existing chassis part of the version up part with the new one (16500110 --A) that is redesigned for ELECTRIC MOTOR option.

Fig. 4 shows the replace operation. First designers explode the part structure of the new version of the assembly and replaced the target part in the sub assembly with the new version. The same pattern of the replacement should be repeated from the top of assembly to the end part that causes the change. In the example, designers version up the end part, the chassis, because it is interchangeable with the old one. If the two parts are not interchangeable, a different part number should be used. Before the operation of the product structure change, an EC object should be created and activated to record the change history. The detailed description of the EC is prepared in the 'Engineering Change History' section.

Fig 4. Replace operation on 16500100 ---

Fig. 5 shows the result of the EC at the assembly level. The designers build a new assembly that has new chassis and share the part body with its old version.

Fig 5. The result of the engineering change at the assembly level

Option Management

Now the changed assembly should be applied to the related options. The change is not effective until it is applied to the options. Other groups of designers and those of manufacturing or customer support departments could not notice the change without completion of the engineering change at option level. The change at the option level is different from that at assembly level in that there are effectivities that determine a specific product structure. Since the option is a kind of variants, designers should specify effectivities that can specify a unique product structure, a configuration, after the ECs.

EC object is also used to record the change history of options, but different type of EC object, EC of option is used. The detailed description on the EC is also provided in the 'Engineering Change History' section.

In the example, designers will change the option, BASE 1100, using the completed EC of assembly. The 16500100 --- part will be replaced by the completed part 16500100 --A in the product structure of option 1100 BASE. Initially the designers create and tune on an EC object, EC 8 in fig 6, to record the structure change.

Fig 6. Create and Turn on an EC for Recording EC History

Then, they copy the 16500100 --A and replace 16500100 --- on the product structure of option 1100. The fig 7 shows the product structure after the replacement.

Fig 7. The Changed Product Structure of Option 1100

Different from the case of assembly level EC, the structure also has the old product structure, the structure of 16500100 --- in addition to new one. This is because that the option is a variant. Designers should therefore specify effectivities to determine a specific product structure. The change will be applied to the Model A (Diesel Engine Model) from the 155th product. So the designers specify the effectivity on the replaced constituent relationship and set another effectivity that inform the applicable product serial number for the new chassis. The figure 8 shows the effectivity icon on the constituent relationship between CONFIG and PART entities (the small box on the edge line is the effectivity Icon).

Fig 8. Effectivity Icon on the Constituent Edge between CONFIG and PART

The figure 9 shows the effectivity specified to the new edge between option 1100 to part 16500100 --A. The engineering change can be applied to both the 156th product of Model A and the first product of Model B. Now designers can specify a product structure with a model name and its serial number.

Fig 9. Effectivity on The New Product Structure

Engineering Change History

In the previous EC operations the designers create two EC entities, EC7 at assembly level and EC8 at option level. Figure 10 shows the information of EC 8. The EC stores managerial data (eq. EC identifier, date, description and EC type) and history of product structure change. The history of product structure consists of the changed part information including the part number, version, name, parent part, and applied operations. They are valuable information for engineers and other departments whose job is related to the product structure and its changes.

Fig 10. EC history of EC 8

KEDB PIM allows designers to manage and reuse the EC consistently. We propose a model for the engineering change management in *the KEDB Product Data Representation.

REFERENCES

  • [Sattory, 1988] Sattory, L. G., Manufacturing Information Systems, Addison-Wesley Publishing Company, 1988.

* An article that describes the KEDB product data representation will be published soon.
** The option is a kind of variant in a product structure that can specify a product structure between end-product and conventional parts.



Korean Engineering Databases (c) copyright Namchul Do, 2000