4.1.4 RULES

Features are often at the center of the design constraints upon which formability depends. These constraints are expressed as rules representing human expertise, practice standards, and even proprietary information. The rules, encoded for expert system use, reside in knowledge bases. Most rules are focussed to avoid features which create situations likely for defects to occur. By avoiding certain constraint violations in this phase, ensuing manufacturing aberrations will also be avoided.

Reiterating a previous example, a concern of injection molding is that of uneven shrinkage during the cooling of a part, causing a depression in the surface known as a sink. Avoidance of the sink may be due to functional or cosmetic reasons. Sinks occur on the base where the concentration of material is greater at one point than at points around it, producing non-uniform heat transfer during cooling. The point of concentration is inevitably around some feature. Heuristics are developed which assess the relationship between the base thickness and thickness of the protruding feature and identify conditions indicating potential sink defects.

Figure 16 Sink Detection Based on Feature Property Ratios

Figure 16 illustrates the ratio or rib thickness T to base thickness B, as compared to a critical value perhaps dependent on the plastic's property. The intent is to detect a ratio of base to feature thickness that indicates a poor design. An informal representation of this rule is that of Figure 17.

Figure 17 Expert's Constraint-Violation Model: Manufacturability Heuristic for Sink Detection

PIMES encodes its heuristics as rules in a production system. A production consists of conditions and actions. Only when every condition of the production is satisfied are its actions taken. While any condition is not satisfied, then no action is taken. A production system is a collection of these productions. When a production is "fired", all its conditions have been met and its actions are taken. In turn, one of these actions may satisfy a condition of another rule and consequently fire that one. The overall behavior of the system is a manifestation of the firing of the rules.

Rules are structured as clauses in a proof-theoretic approach, where relations are represented as basic predicates in a collection of formulas known as integrity constraints [Ozkarahan 90]. Figure 18 illustrates the formalization of the heuristic of Figure 17 into a format usable by the computer. Figure 18 (a) is the depiction of a construct of propositions, which is a deductive law, or rule. It consists of a left hand side called a body and a left hand side called the head. The equation reads as an "if" statement: if the body is satisfied, the head is true. Figure 18 (b) is how Figure 17's rule is formalized in this manner.[3]

Figure 18 Proof-Theoretic Model of Expert Sink Detection Heuristic

Production systems may be visualized as conditions and actions. As illustrated in Figure 19, conditions make up the Left Hand Side (LHS) of a rule; actions make up the Right Hand Side (RHS). When all the conditions of the LHS are true, the actions of the RHS are taken. When just one of the conditions of the LHS is false, the RHS is ignored. This is similar to the IF-THEN programming construct in that IF the conditions are all true, THEN the actions are taken.

Figure 19 Simple Production Model

Under the LHS/RHS of productions, forward inferences can be conceptualized as occurring in left-to-right fashion. Satisfying the LHS conditions of one rule could permit action to be taken which satisfies the LHS conditions of another rule. Figure 20 demonstrates the logic propagation of determining fashion accessories for the day. In Rule 1, the condition "Is_Raining" is true, therefore the action sets the "Roads_Wet" value to true. Rule 2's condition is "Roads_Wet", which is true, and the action sets "Wear_Boots" to true.

Figure 20 Forward Inferencing

Under this production model, forward inferencing can be seen as a cascading effect of the LHS actions of some rules upon the RHS conditions of other rules. Backward inferencing works in the opposite direction of forward inferencing. Given a hypothesis, conditions are examined to indicate whether or not that hypothesis is true. Backward inferencing requires the addition of a third element, that of the Hypothesis, to the simple production model of Figure 19. A hypothesis is part of the RHS and is similar to an action: a Hypothesis is set to true or false or remains unknown based on the LHS conditions.

A Hypothesis of one rule can be used as a condition in another rule. In the simple production model, one rule affects another only when one rule's actions explicitly sets one or more conditions found in the other. With the Hypothesis, rules can be tied together more explicitly when the Hypothesis of one rule is found as a condition of another. When RHS conditions make a rule true or false, the Hypothesis is set accordingly, while in addition, actions are taken. In forward inferencing there is little difference between the Hypothesis being set automatically or some action explicitly setting the same variable.

Figure 21 Hypothesis Production Model

Backwards inferencing works across a rule from the right to the left. Given a particular hypothesis, the conditions are checked to verify the truth or falsity of the hypothesis. If a condition is the hypothesis of another rule, the conditions of this other rule are checked as well. Backwards inferencing can extend back through several rules with hypothesis as conditions.

Backward inferencing also provides a less expensive approach than forward inferencing in that facts are sourced only when needed by the system. Forward inferencing depends on the facts already being present and there may be some expense in acquiring these facts.

Invocation of a rule, in which evaluation of the conditions is forced, can take place by invoking the rule's hypothesis for evaluation. The Hypothesis can be considered as a convenient notation for a global variable. More than one rule can use the same Hypothesis. And the same Hypothesis can be used in the LHS of more than one rule. This comprehensive use of the hypothesis is depicted in Figure 22.

The setting of the hypothesis is more than a conveniently automated action that could be done explicitly in the RHS of a rule. Whereas the RHS may or may not be invoked, the hypothesis variable is always set automatically to true or false when the rule is evaluated.

Figure 22 Hypothesis as Independent Variable

It important to note that productions require programming techniques distinct from 3GLs. Namely, there is no OR operator, which would allow code to be compacted greatly when a condition can be confirmed by any of a number of values. Each unique variation on any condition requires representation by a different rule. For example the following single expression:

if (x==1 or x==3) then type = "odd"

requires the following two productions:

x==1 --> type = odd

x==3 --> type = odd

There is literature that human cognition may be appropriately modeled by the symbol processing of production systems [Simon 79][Larkin & Simon 87] These generally avoid implications that the human mind actually uses such techniques. But what is brought forth is a computational system which proves to be effective in modeling the heuristics used in manufacturing while also utilizing symbols which can be understood by both man and machine.