Object - oriented databases for quality function deployment and Taguchi methods

Computers ind. Engng Vol. 19, Nos 1-4, pp. 285--289, 1990 Printed in Great Britain. All rights reserved

0360-8352/90 $3.00+0.00 Copyright © 1990 Pergamon Press plc

O B J E C T - O R I E N T E D D A T A B A S E S FOR Q U A L I T Y F U N C T I O N D E P L O Y M E N T AND T A G U C H I M E T H O D S

Vedaraman

Srlraman, Phadhana Tosirisuk and Hsing Wel Chu

Department

of Industrial Engineering Lamar University Beaumont, TX 77710

ABSTRACT In this paper, Object-Orlented Databases are proposed as being a new tool for Quallty Function Deployment (QFD) and Taguchl Methods. Quallty Function Deployment can help identify key product or process concerns with respect to customer requirements. Taguchi Methods, such as using Design of Experiments (DOE), can help identify what product or process relationships truly exist, their relative strengths and the nature of the relationship. In order to implement these two powerful quality control techniques for assuring that customer requirements are consistently met, a well organized information is required. Object-Oriented Databases are able to store, organize and manipulate both, the customer requirements and the product information for the performance of QFD and DOE. INTRODUCTION There exists considerable difference in Quality Control (QC) as it was practiced in the 60's and today. In the past, quality control mostly implied the use of statistical techniques to maintain product quality within specified limits. Thus, Qc was chiefly the production department's concern. Today there is an increased awareness that design, on account of its being the first step in manufacturing, is an important activity with considerable impact on the quality of the finished product. This awareness has resulted in the emergence of Design for Manufacturing, the primary philosophy of which is that, in today's market, quality products at low prices cannot be dellvered as long as design and manufacturing activities are performed in isolation [1]. These developments brought forth a continuous llnk is maintained between the [2]. This quallty clrcle besides unifying manufacturing, also considers the customer the design and the product.

new quality circle wherein a customers, designers and makers the initiatives of design and who would be affected by both,

Quality Function D e p l b ~ e n t (QFD) is a technique which is used to relate the design or control parameters to the customer's requirements. The author's contention that, object-orlented programming is an convenient means with which to perform QFD, forms the later sections of this paper. QUALITY FUNCTION DEPLOYMENT AND TAGUCHI METHODS QFD is basically a means by which the customer's concern about quality can be brought into harmony with those of the organization. This involves connecting the customer's expectation of the product performance to the variables of the production processes. This is done through the use of QFD matrices. Ultimately, designed experiments determine the nature and extent of the relevance of the process variables to the product quality. To start with, QFD employs matrices to depict a hierarchy of relationships. The matrices first relate the voice of the customer (VOC) to the various systems of the product. Next the systems are broken down 285

286

Proceedings of the 12th Annual Conference on Computers & Industrial Engineering

into parts that constitute each system. Each part has several characteristics, which may be physlcal or functional. This then constitutes the next rung in the hierarchy. Part characteristics are influenced by the variables of the processes that produce it. So process variables form the last level of the hierarchy of relations. Figure I illustrates the use of QFD matrix for a fuel system. After the matrix has been constructed, the next step is to determine how the process variables should be changed so as to meet the VOC. This is accomplished through the design of experiments. Design of experiments amounts to a set of statistical procedures that are used to determine, first , how experiments are to be conducted to understand the variable's effects on product quality. This having been determined, the second step is to experiment and apply statistical techniques to determine the manner in which the variables are to be manipulated so that the voc is heard. Taguchi techniques are applicable to product and process design as well. Environmental factors like temperature, humidity etc., affect product performance. Taguchl philosophy is to design such parameters, which will render the product insensitive or resistant to these environmental factors. Parameter design, again is dependent on carefully designed experiments. From the foregoing discussion on QFD, the requirements of a programming environment that would be necessary to implement QFD are established to be: * First, a means whereby a hierarchy of entities can be effectively represented. * Second, the basic units of representation should be capable of handling factual and procedural information in a coherent body (since both of these are required for any analysls). * Finally, it is desirable that the means of representation allow for economy of expression. Object-orlented programming which is being proposed as a means for performing QFD, forms the subject matter of the following section. V.O.C.

fuel pump

Long lastlng (durability and reliability)

I

springs f u

m

P

s

1 P u

I fuel line

I diaphragm

fatigue life s P r i n g

e

carburetor

I cams

f a t i

ug

I rocker arm

I no.of coils

shot peening

I fuel tank

I active length

I wire drawing

I OD

I heat treatment intensity

time s h

o t

e

1 i f e

P e e n i n g

Figure I. QFD Matrix OBJECT-ORIENTED

PROGRAMMING

objects are data-structures that are capable of storing both procedural and declarative knowledge in a single unit. Declarative knowledge is factual information, i.e. names of variables and their properties. Procedural knowledge usually concerns with how declarative knowledge is to be manipulated. Object-orlented programming differs terms of how procedures are put to work.

from conventional programming in In conventional programs data and

Sriraman

et

al.: Object-oriented Databases

287

procedures are separated and usually data is sent to procedures to produce results. However, in object-orlented programming one sends the object a message, and a selector in the message specifies the kind of operation. Objects, upon receiving the message, determine what they have to speciflcally do using the selector. They then use their own procedures to perform the task. Thus, message sending supports an important principle in programming : data abstraction [3]. The prlnclple is that calllng programs should make no assumptions about the implementation and internal representation of data types they use. Thus the same message can be used with different objects. The selector then determines the operation. Classes and instances are another concept in object-orlented programming. A class represents a group of objects with something in common. An instance is an object belonging to this group. Thus class is a generic object, while instance is a specific one. For example, doctors are a class, whereas doctor A and doctor B are instances of this class. Inheritance is yet another important concept in object-oriented programming. Inheritance is used to describe objects that are similar to each other. This mechanism is important because it permits the specification of certain characteristics that are shared by multiple parts of a program. Therefore inheritance helps keep programs shorter and tightly organized. Figure 2 is the template of an object. object databases have a tree llke structure. The nodes of the tree form the objects. A typical node is usually connected to nodes above and below. Nodes above are called parents, while those below are called children of the particular object.

object parent I : p ~ r e n ~ parent 2 : p u r e n £

slot I slot E

~ame 1 nG2ne 2

: sLo~ nume 1 : sLo~ name Z

~L~e

Figure 2. Object Template Object name refers to the name of the partlcular object under consideration. Parent names are names of objects higher up in the hierarchy from which objects lower inherit information. Objects high in the hierarchy are usually generic objects (i.e. they represent a class). Objects lower are usually instance objects. Instance objects will inherit information from all their parents. This thus saves one from having to repeat a lot of redundant information. However exceptions can be redefined from within a lower object. Objects can also have their own pecullaritles which are then defined in their slots. Slots are a means by which variables, and their values and\or procedures, are defined within an object. In the next section we shall discuss how QFD may be achieved using object-orlented programming through the use of an example. QFD THROUGH THE USE OF OBJECT-ORIENTED

PROGRAMMING

To use object-orlented programming, we first need to depict the hierarchy of relations using the objects. VOC on account of its importance forms the first level. Making VOC the first parent ensures that, through inheritance, it will be heard in all of the lower objects. Also procedures required to design and interpret experiments (like say, D1, D2, D3, etc.) should be included in the slots of the VOC object. This ensures that through inheritance these procedures will be available in any other object. After the VOC object, we have objects representing the comprise the product. At the third level, there are the

systems objects

that that

288

Proceedings of the 12th Annual Conference on Computers & Industrial Engineering

represent parts which make the several systems. Specifications for various parts forms the fourth level. The flnal level depicts the several processes that are required to produce the specifications. This level also shows what parameters the process is dependent on. Figure 3 shows the object database for the fuel pump shown in figure I. At each level of hierarchy, it can be seen that the object has a name which is written at the upper left corner (in bold print). A typical object has several parents from which it inherits information. Each object also either depends on certain factors and/or is made of other components. This information is displayed in the slots. The slot name (like made of, depends on, parent , procedure etc.) is shown in italics, while their values are shown in regular print. The VOC object also contains procedures llke D1, D2, etc., which are required for the design of experiments. From figure 3 it can be seen how inheritance permits great economy of expression. In this connection, class and instance objects can be put to good use. In the product range of several manufacturing concerns, many processes and components are parts of different systems. For example, consider the object casting. Castings may be involved in the manufacture of several components. So once we define a casting object (which then represents the class), castings found elsewhere will simply be instance variables. In each instance of the object casting, there will be some differences and these differences can be defined in the slots of the object. To put the database to use, the user scans it to identify the process parameters for the production specifications. These would be found in the objects of the lowest level of the hierarchy. Now, having identified these parameters, he would next have to design and perform experiments. The necessary procedures llke DI, D2, etc. are available in the slots of these objects through inheritance. Thus he can quickly perform analysis and take the necessary corrective actions on the shop floor. CONCLUSIONS we have remarked earlier that QFD presents a method with which to relate the customer's voice to the production requirements. These are achieved through the use of QFD matrices, we then determined the requirements of a programming environment that would support QFD. The requirements were the ability to represent a hierarchy of relations, procedural and declarative information and thereby pave the way for compact expressions. Object-oriented programming was identified to be such a means. Through the use of the example in figures 1 & 3 we have shown how object-oriented programming may be used to perform QFD. Another point that warrants mention is that the QC department need not spend its effort in building the database entirely. Such databases are usually built during the design of the product by the design engineers. This is then bettered by the process planning personnel who ensure the data is correct in terms of manufacturabillty. It is only after this stage that the Qc department may have to make some additions. Thus the advantage of this database is that it not only makes the work simpler for QC but the database is capable of supporting a variety of manufacturing control activities. Objects and frames which are similar to objects, have been used for data representation in several manufacturing applications such as design, manufacturabillty analysis, process planning, scheduling and total quality control (TQC). Reference [4] is an excellent example of the use of A.I. and frames for TQC. REFERENCES

[I] Billatos, S.B., "Guidelines for Productivity and Manufacturabillty Strategy", M a n u / a c ~ u r ~ n 8 R e v i e w , V I, n 3, 1988. [2] ROSS, P.J., "The Role of Taguchl Methods and Design of Experiments in QFD", O u a [ ~ L ~ Progress, June 1988. [3] Steflk, M., and Bobrow, D.G., "Object-Orlented Programming : Themes and Variations", The A[ Ha~az~ne. May 1988. [4] Ishlzu, S., and Furukawa, O., "Total Quality Control by the Use of Expert Systems", Proceedings of the ICQC , Tokyo, 1987.

Sriraman et al.: Object-oriented Databases

289

VOC mude of

fuel pump carburetor fuel llne fuel tank

made o/ made o/ made o/ property proper£~

i reliability 2 durability

pDocedtu'e i procedure E procedure 9

i

D1 D2 D3

I

I

[ Carburetor J

I

fuel pump

fuel

line

I

I

i

#

i

#

parenz

VOC

made o/

springs diaphragm cams rocker arm

made of m~zde of made of

#

i

Idi'p a0ml

Ir°cke~ arm

springs I

i

#

I

i

Ifuel tank

i

#

VOC fuel pump

p~ren~ p~ren£

#

d e p e n d s on fatigue life depends on n u m b e r of coils depends on active length d e p e n d s on OD

I

J

active length

I number of coils(

fatigue life

I

I

#

pur~ puren~ depends depends depends

#

VOC fuel pump springs

p~ren~

on shot p e e n i n g on wire drawing

on heat treatment

I

i wire drawingl

I

shot peening

lheat t r e a t ~ n t l

f

I

#

p~ren£ pczren~ paren~ parent depends depends

#

VOC fuel pump springs fatigue llfe on on

intensity time

.. independent

trees not shown here

Figure 3. Object Database

#

#