DR. FACTORY(TM) AND CAUSE-MIC:
A MANUFACTURING CONSULTANT ASSISTANT
AND ITS MODULAR BAYESIAN BELIEF NETWORK DEVELOPMENT AND EXECUTION ENVIRONMENT

T. TOTH-FEJEL, S. J. CLARK and J. D. KINDRICK
Industrial Technology Institute
P. 0. Box 1485
Ann Arbor, Michigan 48106

Ergonomics of Hybrid Automated Systems II
W. Karwowski and M. Rahimi (Editors)
Elsevier., 1990
pp. 323-330

SUMMARY

This paper describes Dr. Factory, a knowledge-based system designed to assist manufacturing consultants in their diagnosis of problems and opportunities in relation to plant-level technology and associated business and management practices. This paper " describes Cause-MIC (Cause Modeling, Inference, and Construction), Dr. Factory's underlying knowledge representation, knowledge engineering interface and engine. Instead of using IF-THEN rules as in traditional expert systems, Dr. Factory's Knowledge Base is expressed in terms of a Bayesian Belief Network, which captures uncertain causal and evidential relations between various descriptors in a coherent manner strictly consistent with the axioms of probability theory.

APPLICATION

Using Cause-MIC, a modular Bayesian Belief Network development and execution environment developed at the Industrial Technology Institute (ref. 1), we have built Dr. Factory', a prototype knowledge-based system which is designed to operate as an intelligent assistant to a manufacturing consultant, specifically with respect to the identification of problems and opportunities in durable goods supplier firms. The knowledge base is composed of a set of descriptors representing the structure and components of the manufacturing firm, and the causal relationships between these descriptors. The descriptors include observations and evidential beliefs about phenomena as varied as customer satisfaction, employee training, scrap rate, and WIP level.

The knowledge base has both theoretical and empirical sources. The theoretical source is a synthesis of conceptual models found in a literature search. The empirical source consists of case studies in the Frostbelt region, specifically small metal-cutting automotive supplier firms. These cases were examined by a panel of university and industry-based manufacturing consultants who explained their diagnoses with causal justification. This work resulted in an initial "vocabulary of discourse" containing 400 observables (input descriptors) and 60 problem/opportunities (output descriptors).

THEORETICAL FRAMEWORK

As yet, there is no such thing as an 'expert system". True expertise involves producing a high quality result when faced with a difficult intellectual task; reasoning analogically, deductively, inductively, and abductively; reasoning from first principles

When faced with new situations; explaining how a conclusion was reached with fundamental domain principles as justifications; and learning from experience (ref. 2). No system today has such capabilities. Neverless, knowledge-based systems have important advantages over conventional software, in terms of significantly improved performance (i.e. more "intelligence"), flexibility, constructability, and maintenance.

What's Wrong with Rules? In the overhyped world of "expert systems", the most popular knowledge representation is in the form of IF-TBEN production rules. The power of rules is in their modularity, which gives the system locality (i.e. "regardless of other things") and detachment (i.e. "regardless of how it was derived"). But this representation has a number of inherent problems (ref. 3, 4):

1. There is no difference between cause and evidence. In other words, the rule "IF observe fire THEN there exists smoke" is completely different from "IF observe smoke THEN there exists fire", even though they really mean the same thing.

2. There is no strong mathematical, logical, or epistemological foundation for handling uncertainty. Rules use an extensional approach to uncertainty, attaching generalized truth values to propositions which are then combined with other truth values in some ad hoc manner to propagate uncertainty through a knowledge base.

3. Retraction is very difficult. For example, the problem with the rule "IF ground wet THEN it rained" is that increasing the certainty that the ground is wet shouldn't necessarily increase the certainty that it rained. This is because there might be other propositions that might affect it, like "neighbor's grass is dry" or "sprinkler was on".

4. Detachment can ruin the plausibility of reasoning chains. For example, there may be two innocent rules in a system: "IF sprinkler on TBFN ground wet" and "EF ground wet THEN it rained". Forward chaining from "sprinkler on" results in the implausible deduction that "it rained" when the opposite conclusion would be more reasonable.

Bayesian Belief Networks (BBNs), or Probability Inference Nets are a recent development in AI (ref. 2,4,7). In this representation, the knowledge base consists of descriptors connected by causal relationships, with bayesian probability governing the propagation of uncertainty.

Descriptors represent any observable or hypothetical data that can assume a qualitative state value. For example, a descriptor in Dr. Factory' is "Rework Rate" and has states "Too High" or "Acceptable". The knowledge engineer must first compile a list of important descriptors in a domain, and then assign possible states to each one. Once this structured list is produced, there remain two difficulties: recognizing and disregarding the ignorable facts, while combining the relevant ones under uncertainty. Networks are very useful for the former difficulty, while bayesian probability is used for the latter.

Networks form a very natural way of making relevant relationships explicit while excluding items that do not matter. In BBNS, the links themselves represent cause-effect relationships between descriptors, capturing the influence one phenomenon may exert over another. This representation allows reasoning to occur in both directions, not only syntactically as in rule-based forward and backward chaining, but also semantically. For example, the representation of "fire causes smoke" is identical to the representation of "smoke is evidence of fire".

Uncertainty may exist about the particular state of descriptors, but the existence of causal and evidential links is certain, just like the states and descriptors. For example, our certainty in the current phase of the moon, or the number of words in this paper, may be quite low. At the same time, however, we can be quite certain that there is no direct causal link between the two. It is difficult to combine multiple influences in the presence of uncertainty, but Bayesian probability provides the best choice, being based on solid mathematical, logical, and philosophical foundations (ref. 4, 6, 7).

Unfortunately, there are a number of problems with BBNS:

1. Difficult to build. Experimental evidence (ref. 7) shows that building Bayesian Belief networks is more difficult and time-consuming than building rule-based systems, primarily because the paradigm is more rigorous. First, it requires that the knowledge engineer explicitly declare all influences. Then, for every descriptor with T states linked to N causes, each cause being another descriptor with S states, he/she must completely fill out an N+l dimensional link matrix of rank (T,Sl ... Sn) that defines the bayesian equation for that descriptor.

2. Every problem requires a custom network. Many domains, including factory diagnosis, require different networks for each problem, even though each problem shares many common subproblems. For example, two metal stamping factories would need different networks if they were identical in every way except that they had a different number of stamping presses.

One approach towards solving this problem is to build powerful network browsers and editors (ref. 2). Cause-MIC uses these tools, but it also makes it possible to modularize the network into common subproblems, and reduce the building problem with copy-and-edit and instantiate-and-link approaches. There are certain areas of any domain that are more densely interconnected than other areas. The idea is to subdivide the causal network into these smaller, denser subnetworks, keeping track of the connection points, and then to copy and edit these subnetworks, and/or generalize them into classes of subnetworks and then instantiate and link them as necessary.

IMPLEMENTATION

We have implemented the Bayesian Belief Network representation paradigm with appropriate software tools which take advantage of both modularization approaches. We have identified four levels of interaction with Cause-MC: Implementer (that's us), Builder (a knowledge engineer who creates and links descriptors), Tuner (a knowledge engineer who fills out the probability link matrices), and End User (a manufacturing consultant who makes the observations on a particular case that get entered into the descriptors). The paragraphs below describe the more important components and capabilities.

Observables Data Input Menu

Done

Abort

Restart

Help

Dr. Factory Observables on Bridgeport NC Mill of Metal Grinding

Process Material Flow What is the quality of the process and material flow?

Good

Bad

Unknown

Evidence

Inventory Buildup Is there an inventory buildup at this process point?

Yes

No

Unknown

Evidence

Production Bottleneck Is there a production bottleneck at this process point?

Present

Absent

Unknown

Evidence

Expedited Order What percentage of orders are expedited?

Acceptable

Too High

Unknown

Evidence

Numeric

Figure 1: The Data Input Menu

Copyright @ 1989, 1990 Industrial Technology Institute - Reprinted with permission

The Data Input Menu is simple because descriptors have simple structure. Shown in figure 1, it allows the user to enter qualitative information about descriptors. In the event the user has directly observed which state a descriptor is in, he/she simply mouses over that button. The state of other descriptors may not be as well known, and this uncertainty requires an additional step -- the assignment of relative probabilities to each state with a comment to explain the source of causal evidence. Since there may be more than one source of evidence, it is possible to add additional ones by mousing on "Relative Likelihood" and filling out the row, as shown in figure 2.

Evidence Menu
Done		Abort	Restart		Help
Evidence for: Expedited Orders. What percentage or orders are expedited?
Relative Likelihoods
1		Acceptible	5		Too High	1		Comment: Reliable source thought it was acceptible.
Outside Evidence
1		Acceptible	.02		Too High	0.999		Comment: The invoice for "Expedite" Stickers was $2000!

Figure 2: Evidence Menu
Copyright @ 1989, 1900 Industrial Technology Institute - Reprinted with permission

On the other hand, what if the Builder forgot to include a relevant descriptor, but the User required that descriptor? There is no need to panicl The user can simulate the missing descriptor by describing outside influences as if they were additional partial evidence, thus capturing the causal influence it has in the real world.

Subnetwork Modules collect related descriptors. Powerful network browsers allow the knowledge engineer to create, edit and link descriptors into these modules. An example of the plant-wide "Company Type" module and its descriptors is shown in figure 3. Causality flows from left to right, so "PPIC Adequacy" affects "Expedited Orders", which in turn affects "Customer Delivery'. Conversely, evidence flows from right to left. The gray box signifies that the descriptor lies outside the module, and additionally, dotted lines signify causal or evidential links to descriptors in other modules.

Figure 3: "Company Type" Subnetwork
Copyright @1989, 1990 Industrial Technology Institute - Reprinted with permission

This subnetwork is not used directly by the end user, but is a template that gets instantiated when appropriate. For example, in one use of Dr. Factory, the metal stamping process (for which there is a subnetwork module) is instantiated three times, but the plastic extrusion process (for which there is another subnetwork module) is not instantiated at all, reflecting the processes actually in the plant under consideration. These instances would be automatically linked to the other instantiated subnetworks.

Specializations are useful when the subnetwork modules don't describe a particular situation exactly. In this case, it is possible for the knowledge engineer to 'copy and edit' the module; i.e. specialize it. This edited version may include new descriptors, different links, or it may have fewer descriptors. The only constraint on this specialization is that its causal links to the rest of the network must be the same, so that it remains "plug-compatible". For example, the "Process" module may be specialized into "Metal Working" and "Plastic Working" as shown by the dashed lines in figure 4. Specializations are a really just subnetwork modules with parents, and may in turn be specialized.

Figure 4: Meta-Model with Specializations of a Process
Copyright @ 1989, 1990 Industrial Technology Institute - Reprinted with permission

The Meta-Model collects the subnetwork modules into a single hierarchical framework. It can be seen from figure 4 that Dr. Factory' has three modules, Factory Type (of which there is one specialization), Niche (of which there are two specializations), and Process (of which there are four specializations). The relationship between these modules at this level is arbitrarily decided by the knowledge engineer, and is drawn as a solid line. In the case of Dr. Factory, the relationship is a compositional one; i.e. a niche is a "part-of" a factory, and a process is also a "part-of" a factory.

Classification has little to do with causal reality, which is why it helps organize modules in a manner orthogonal to causality. For example, figure 5 displays the classification of the Process module in Dr. Factory.

The Model is a collection of all the instantiated subnetworks, and is the actual structure over which reasoning (i.e. uncertainty propagation) is done. It is the instantiation of the Meta-Model, linking together all the instantiated modules.

Propagation spreads causal and evidential influence through BBNs with three methods for handling cycles: Clustering, Stochastic Simulation, and Conditioning.

Figure 5: Process Classification
Copyright (g) 1989, 1990 Industrial Technology Institute - Reprinted with permission

Clustering was ruled out because it is difficult to do automatically, and requires exponentially increasing time to complete as the size of the network grows. Stochastic Simulation was easily implemented, though Conditioning was not. Pearl (ref. 4) describes all three methods. Figure 6 shows what a portion of the model finally looks like after the data has been propagated.

Figure 6: The Model after Propagation
Copyright 1989,1990 Industrial Technology Institute - Reprinted with permission

CheckListing decides what needs to be known about the factory in order to make accurate and dependable diagnosm of problems and opportunities. The current vision of Dr. Factory usage is as follows: A consultant conducts telephone interviews of factory personnel to obtain preliminary data on the factory. From this data, the appropriate company type, niche and process modules are instantiated, and known descriptor. state values are chosen and propagated through the network. Checklisting measures the entropy near output descriptors, searching through their causal and evidential neighbors, with some consideration of the cost of observation. The manufacturing consultant takes the checklist on his/her plant visit, and circles the appropriate states on it as he/she observes them. After the plant trip, he/she plugs the observations into Dr. Factory' and propagates the new information. Before the consultant can use checklisting, the knowledge engineer must make value judgements on certain states of appropriate descriptors; for example, it is undesirable for the "WIP Level" to be in state "Too High". Using the mouse and graphical menus, he/she must also specify which descriptors are important outputs with respect to the final diagnosis, and which descriptors are easy observations (i.e. low-cost inputs). Below is a partial example listing:

5. Quality Perception of camshafts
Customer's perception of the quality of this company
(Poor) (Good)

The Diagnostic Output is a list of output descriptors for which there is a high probability of being in undesired states, with an explanation traced back to the user's input. Below is a partial example listing:

CURRENT STATUS AND FUTURE WORK

All the capabilities described above have been implemented on Sun workstations in Xerox InterLisp and Loops. The InterLisp environment is an extremely powerful development environment, allowing us to prototype the knowledge representation and create elegant interfaces that save typing, provide appropriate help without getting in the way, and change dynamically as the user makes choices.

Future plans include implementing specialization, integrate the current help facility into a hypertext format, finding a way to handle sequential processes, building tools to help tune the link matrixes.

Other applications are also planned, such as implementing HI-TOP, a procedure for examining the impact of Advanced Manufacturing Technology (AMT) on an organization and its individual members, with the objective of taking full advantage of a particular new technology (such as CAD, flexible manufacturing cells, or CNC) while ameliorating any negative effects.

CONCLUSION

Decision support software tools such as Dr. Factory can have a significant role in assisting manufacturing consultants, especially in the areas in which they may be weak. Because Cause-NHC models domains at higher levels of abstraction, while keeping the rigorous foundation of bayesian probability for propagating uncertainty, it is a good vehicle for capturing this difficult domain.

REFERENCES

1. J. D. Kindrick, S.J. Clark, and T.T. Toth-Fejel, Cause-MIC: Model-Based Probabilistic Inference Networks, submitted for publication to AAAI 90.

2. S.K. Andersen, et. al., HUGIN - A Shell for Building Bayesian Belief Universes for Expert Systems, Proceedings of the Eleventh International Joint Conference on Artificial Intelligence, August 20-25, 1989, Detroit, Michigan, AAAI, pp. 1080-1085.

3. R.J. Brachman, et. al., "What are Expert Systems", Building Expert Systems, F. Hayes-Roth, D.A- Waterman, and D.B. Lenat, eds., Addison-Wesley Publishing, Reading, Massachusetts, 1983, p 41-50.

4. J. Pearl, Probabilistic Reasoning in Intelligent Systems: Networks of Plausible Inference, Morgan Kaufmann Publishers, Inc., San Mateo, California, 1988.

5. J.C. Ferguson, Beyond Rules: The Next Generation of Expert Systems, Proceedings of the Air Force Workshop on Al Applications for Integrated Diagnostics, May 1987.

6. T. Bayes, An Essay Towards Solving a Problem in the Doctrine of Chances, in: Phil. Trans. 3:370-418, 1763.

7. R.T. Cox, Probability, Frequency, and Reasonable Expectation, American Journal of Physics, January-February 1946, V14 Nl, pp.1-13.

8. M. Henrion and D.R. Cooley, An Experimental Comparison of Knowledge Engineering for Expert Systems and for Decision Analysis, Proceedings of the Sixth National Conference on Artificial Intelligence, Seattle, Washington, AAAI, 1987, pp. 471-476.