the part of the product development process that needs attention, much like .... process is adopted here as an example to demonstrate the application of ODC.
Intelligent Orthogonal Defect Classification (ODC) towards Manufacturing Nonconformance Tracking and Diagnostic Recovery Wei Liu, S. Hossein Cheraghi Department of Industrial and Manufacturing Engineering Wichita State University Wichita, KS 67260-0035, USA Extended Abstract Tracking, diagnosis and recovery of the nonconformance in a manufacturing system is a time consuming and tedious process, which could result in substantial delays in the production process. Therefore it is imperative to develop an intelligent system that can track the nonconformance and provide timely diagnostic recovery. Since the current analysis techniques are either qualitative or quantitative, this paper describes a novel approach that bridges the gap between the qualitative and quantitative techniques based on a method called Orthogonal Defect Classification (ODC). The key concept in ODC is that the nonconformances are categorized into classes that collectively point to the part of the product development process that needs attention, much like characterizing a point in a Cartesian system of orthogonal axes by its (x, y, z) coordinates. The proposed system provides a basic capability to extract nonconformance signatures, infer the health of the product development process and recommend diagnostic recovery.
Keywords Orthogonal Defect Classification Nonconformance diagnosis
(ODC),
Nonconformance
attributes,
Nonconformance
signatures,
1. Introduction A manufacturing system involves the transformation of raw materials into finished products that meet a predetermined set of specifications with the use of 4M’s (Man, Material, Money and Method). As a consequence of the dynamic nature of such systems, some of these transformations may result in products that do not conform to a given set of specifications and cause nonconformance (defect). Nonconformance is “A departure of a quality characteristic from its intended level or state that occurs with a severity sufficient to cause an associated product or service not to meet a specification requirement” [1]. The nonconformance needs to be tracked and the causes should be identified based on which corrective actions have to be taken. The tracking/diagnosis and recovery of nonconformance is an expensive process due to the time lost in production and the time it takes to track and diagnose the problem. In a general production environment, when a nonconformance problem has been identified and a remedial action suggested, the diagnosis and correction applied to this nonconformance is recorded and information is stored in a database, and occasionally a report is generated. However, the information recorded is seldom used in the correction of a new occurrence of a similar nonconformance due to the lack of a system that will allow a quick search and retrieval of the pertinent information. Most of the time, the activities of finding a remedy would start from scratch, which would cost the company unnecessary recourses. There are also situation where the procedures to identify the real cause are quite abstract and are based on the skill of the investigator. For unfamiliar fault events, the investigator has to rely on analytical reasoning. However, insufficient system state data may prevent the inference of nonconformance symptoms. In addition, a time lag between nonconformance occurrence and nonconformance detection makes it even harder to trace nonconformance causes. Besides the information overload on the human, the system complexity also places a barrier for the human to fully understand system functioning. Many methods have been proposed for the nonconformance diagnosis. Typically they can be divided into two categories: qualitative (causal analysis) [2, 3] and quantitative (statistical model) [4]. The goal of qualitative method is to locate the root cause of the nonconformances and initiate actions to eliminate the source of the nonconformances. The goal of quantitative method is to predict the reliability of the product or the production process. In the quantitative method the nonconformance is measured by criteria such as the failure rate of the product and the short-term nonconformance rate [5]. Although both the qualitative and the quantitative methods work well under certain circumstances, there is a wide gap between these two methods. At one extreme, the quantitative methods clearly define the generic cause-effect structure of a manufacturing system, which provides a
comprehensive basis to cope with many unanticipated nonconformance events. However, the computational complexity involved in the exhaustive search for fault causes limits the application of this technique to diagnostic problems of real-world size. Meanwhile, the quantitative methods do not provide timely feedback to the process engineer. At the other extreme, the qualitative methods employ heuristic knowledge to make a diagnostic decision. While explicit and well-planned heuristic knowledge may not be available for less-recognized, ill-defined fault situations, it is difficult to quantity the production process. Therefore, it is desirable to have a method that can provide timely feedback while abstract from the production process details to quantify the related data. Orthogonal Defect Classification (ODC) is the methodology that can bridge the gap between the qualitative and the quantitative methods. It enables fast in-process feedback to software developers by extracting signatures on the development process from nonconformance. ODC was first proposed around 1990 and has evolved since then. It has been used by the engineers in IBM and is currently practiced in several products spread across 12 IBM locations worldwide [5]. So far, no research on the application of ODC to diagnose the nonconformance in the production process has been reported. The purpose of this paper is to investigate the use of ODC to the nonconformance diagnosis in the manufacturing area. An airplane door development process is adopted here as an example to demonstrate the application of ODC. Since the data related to the airplane door development process cannot be presented in this paper, we will only focus on the discussion of ODC’s methodology and its implementation issues. The content of this paper is organized as follows. The next section, Section 2, gives a brief introduction to ODC. Section 3 discusses the issues about implementing ODC and finally conclusions are drawn in Section 4.
2. Orthogonal Defect Classification (ODC) ODC is used to extract key information from classified nonconformance attributes. The key concept in ODC is that the nonconformances are categorized into classes that collectively point to the part of the product development process that needs attention, much like characterizing a point in a Cartesian system of orthogonal axes by its (x, y, z) coordinates [6]. The methodology of ODC can be divided into three steps: attribute definition, information capturing and information exploitation. 2.1 Attribute Definition Different from the cause-effect analysis, ODC uses a set of attributes to capture the nonconformance information. Currently IBM adopts four attributes: nonconformance type, nonconformance trigger, source and impact [5]. Their definitions are given below: v Nonconformance type: A classification of nonconformance that occurs in the product development process. v Nonconformance trigger: The environment or condition that makes the nonconformance surface. v Source: The origin of the nonconformance. v Impact: The effect of the nonconformance on the system. The nonconformance attributes should be carefully designed so that they are orthogonal or distinct, which means that no confusion will be caused when linking nonconformance attributes with actual nonconformance. In addition, the nonconformance types should span the entire possible nonconformance, so that all the nonconformances can easily fit into one of the categories. 2.2 Information Capturing Once the attributes are defined, the nonconformance information can be captured. This is accomplished by linking the nonconformance with the corresponding nonconformance attributes. In order to facilitate the information capturing process, a set of nonconformance capturing tools need be designed based on the nonconformance attributes defined above. These kinds of tools can be a paper form or software. With the popularity of computer and many available computer program development tools, software is more preferred and highly recommended. 2.3 Information Exploitation After the nonconformance information is captured, it will be analyzed to diagnose the process. The analysis is performed by displaying the nonconformance attributes in a graph. For example, nonconformance type usually changes over the product development process. Thus it is possible to get the process signature based on the nonconformance type distribution and infer the health of the process.
3. Implementation of ODC in the Manufacturing Area The novel characteristics of ODC offer the possibility of diagnosing nonconformance in the manufacturing area. An airplane door development process is adopted here as an example to demonstrate the application of ODC. Due to the
nature of the airplane manufacturing industries, the actual data related to the airplane door development process cannot be presented in this paper. The following sections outline some key implementation issues and steps. 3.1 Attributes Definition We adopt the nonconformance attributes defined by Chillarege [5] and add two new attributes called “cause” and “development phase”. v Cause: The cause of the nonconformance v Development phase: the development phase in which the nonconformance was found. Table 1 illustrates the major nonconformance attributes proposed for the airplane door development process. The various causes for the manufacturing noncornformances in the airplane door fabrication process shown in the table are taken from Tadayon [7]. Nonconformance Type: 1. Performance 2. Component function 3. Interface 4. Assembly 5. Documentation Impact: 1. Usability 2. Performance 3. Instability 4. Maintainability 5. Documentation 6. Unknown
Table 1. Nonconformance attributes Nonconformance Trigger: Source: 1. Design conformance 1. Bought out component 2. Field test 2. In-house component 3. Document consistency and 3. Unknown completeness 4. Operation Development Phase: Cause: 1. Engineering design 1. Component design 2. Planning 2. Process planning 3. Process/Setup 3. Machining 4. Inspection and Measurement 4. Assembly 5. Tooling 5. Inspection and performance test 6. Machining 6. Long term operation 7. People 8. Environment 9. Materials 10. Unknown
Besides the above six major attributes, we also have several auxiliary attributes that are used to help track the nonconformances such as nonconformance ID, submitter’s ID, nonconformance found date, nonconformance fixed date, description of unknown attribute, corrective actions and notes. 3.2 Information Capturing As we mentioned before, a set of computerized tools need to be developed in order to assist the nonconformance information capturing process. A good information-capturing tool should possess the following characteristics: v Have user-friendly interface. v Reduce human cognitive workload involved. v Provide on-line help. v Be easily integrated with existing software systems. v Be easily modified to suit other products. v Support diverse platforms v Support divers languages Figure 1 depicts a web-based information capturing tool. The two general structures of deploying web applications are called fat client and thin client. A fat client architecture is one in which a program resident on each client machine interacts with a server. It is called “fat” because the client application is usually large, and makes substantial use of client-side services for its application. By contrast, a thin client architecture is one in which the most application logic resides on a server. The client is only responsible for the data verification and client-side calculation. In this study, the thin client structure is adopted and implemented by a three-tier model (Figure 2). In the three-tier model, commands are sent to a "middle tier" of services, which then sends the commands to the DBMS server. The DBMS server processes the commands and sends the results back to the middle tier, which then sends them to the client. The three-tier model is very attractive because the middle tier makes it possible to maintain control over access. Another advantage is that it simplifies the deployment of web applications. Finally, in many cases, the three-tier architecture can provide performance advantages.
Figure 1. Web-based nonconformance information capturing tool
Client machine
Web browser HTTP, RMI, CORBA or other calls
Web Server machine
Web Server DBMS proprietary protocol
DBMS Server machine
DBMS
Figure 2. A three-tier architecture for web application deployment. 3.3 Information Exploitation 3.3.1Exploiting Nonconformance Type The nonconformance type is designed as orthogonal so that each nonconformance type is related with a distinct development phase. When charting the number of nonconformances of each type found in a given phase, we can get a profile of the nonconformance distribution that implies the signature of the process. The change in the distribution
of types from one phase to another gives us fast feedback on the development process. It takes time and efforts to collect historical data to calibrate the change in distribution within a specific development phase. However, once the process is calibrated, it can be used as a trend model to diagnose the current production process. For example, if the nonconformance distribution in the assembly phase is significantly different from the trend model, then we can infer that there is something wrong with the airplane door development process. The nonconformance distribution not only signifies the problem, but also recommends the possible causes by checking the nonconformance type that makes the distribution different from the expected. Once the offending nonconformance is identified, the recovery actions can be retrieved from the historical data. The information inside the nonconformance can also be extracted by building a model based on a 3-D tree (Figure 3). Each nonconformance type corresponds to a specific 3-D tree. The root of the tree is an auxiliary node, which has no special meaning. The levels of the tree represent the product development process from component design to long term operation. The edges represent whether there are too few (Low), many (Medium) or too many (High) nonconformance types in that phase (designated on the graph as L, M and H respectively). For example, the edge labeled L that links CD and PP implies that are only few nonconformance in the component design stage. The criteria for Low, Medium and High can be determined by experience. Once the construction of the 3-D tree is done, inferences about the process can be drawn by building a path from the root to the leaf node. For instance, L®L®L® L®L® L may imply a good process while L®L®H® L®L® L implies that the machining process needs attention.
L
M
CD L PP
M PP
H
CD H
L PP
M
PP
CD H
PP
L PP
PP
M
H
PP
PP
M Ma M A M IPT L LPT
LPT
M LPT
H LPT
LPT
Notes: L: Low, M: Medium, H: High. CD: Component design, PP: Process planning, Ma: Machining, A: Assembly, IPT: Inspection and performance test, LPT: Long term operation. Figure 3. A 3-D tree structure for nonconformance type 3.3.2 Exploiting Nonconformance Trigger Nonconformance trigger is the environment or condition that must exist in order for a dormant nonconformance to surface [8]. Trigger is the catalyst without which the nonconformance would have continued in its dominant state. While the nonconformance type gives feedback on the product development process, the nonconformance trigger correspondingly gives feedback on the inspection and performance test phase. If the nonconformance trigger distribution after product release differs greatly from the nonconformance trigger distribution during the inspection
and performance test phase, then the test process is not focusing on the correct types of tests and some modification to the test phase needs to be taken.
4. Conclusions This paper investigates the application of ODC to the airplane door development process. We proposed a set of nonconformance attributes for an airplane door development process, developed a web-based tool to capture the nonconformance information and designed a 3-D tree structure to exploit the nonconformance data. ODC is a methodology used to capture the nonconformance and extract key information from classified nonconformances. It bridges the gap between current qualitative and quantitative methods, and it can be understood that ODC is an appealing technology for the nonconformance diagnosis in the manufacturing area. However, several points need to be addressed when applying ODC to diagnose manufacturing nonconformance: v The successful implementation of ODC depends on the quality of the calibrated profile of nonconformance distribution. Therefore a lot of historical data is needed in order to calibrate the nonconformance distribution and it is a time consuming process. v ODC uses a large population of nonconformance data to get the process signature and infer the health of the process. It cannot provide fast response to a single nonconformance. v The current development phase classification method implies that ODC can only diagnose the product development process as a whole. However, each development phase can be divided into several sub-phases in order to diagnose a specific process. v ODC can be applied not only to the nonconformance diagnosis, but also to the nonconformance prediction and prevention. Stewart [9] proposed a proactive method based on a fuzzy Bayesian methodology to reduce the amount of scrap and rework activities for large manufacturing systems, which is called Fuzzy Defect Avoidance System (FDAS). The combination of ODC and the fuzzy Bayesian methodology is a promising research area for the nonconformance prediction, prevention as well as diagnosis. v Cause is an important attribute with which the nonconformance recovery can be recommended. However, uncertainty and fuzziness always accompany the cause attribute because of the complexity of the actual manufacturing system. In addition, the submitter’s knowledge about the nonconformance also affects the quality of the captured information. Thus the integration of ODC with expert system and fuzzy set theory will be our future work.
References 1. 2. 3. 4. 5. 6. 7. 8. 9.
Griffith, G. K., (eds.), 1996, The Quality Technician’s Handbook, Premtice-Hall Inc., New Jersey. Hinkley, C. M., and Barkan, P., 1996, “Selecting the Best Defect Reduction Methodology”, Quality and Reliability Engineering International, 12(6), 411-420. Lyonnet, P., 1991, Tools of Total Quality: An Introduction to Statistical Process Control, Chapman & Hall. Angeli, C., and Atherton, D., 2001, “A Model-based Method for an Online Diagnostic Knowledge-based System”, Expert Systems, 18(3), 150-158. Chillarege, R., and Biyani, S., 1994, “Identifying Risk-using ODC Based Growth Models”, Proc. of the fifth International Symposium on Software Reliability Engineering, November 6-9, Monterey, California, 282-288. Chillarege, R., Bhandari, I. S., Chaar, J. K, Halliday, M. J., Moebus, D. S, Ray, B. K., and Wong, M., 1992, “Orthogonal Nonconformance Classification-A Concept for In-process Measurements”, IEEE Transactions on Software Engineering, 18(12), 943-956. Tadayon, F., 1995, Root Cause Identification for Assembly Misfit, Ph.D. Dissertation, Department of Industrial and Manufacturing Engineering, Wichita State University. Bassin, K. A., and Santhanam, P., 1997, “Use of Software Triggers to Evaluate Software Process Effectiveness and Capture Customer Usage Profiles”, Proc. of the eighth International Symposium on Software Reliability Engineering, November 2-5, Albuquerque, New Mexico, 103-114. Stewart, D. A., Mlazahn, D., and Cheraghi, S. H., 1999, “Continuous Quality Improvement Using Fuzzy Bayesian Inferencing”, Proc. of the third International Conference on Engineering Design and Automation, August 1-4, Vancouver, Canada, 885-892.
