Integration of Rule-based Process Selection with Virtual Machining for Distributed Manufacturing Planning
3.3 Knowledge-based Process Selection
3.3.2 Process Selection Rules
The process capability and precedence knowledge have been implemented into an XML file with process classes implemented inside the IMPlanner package. For example, edu.ohiou.implanner.processes.TwistDrilling is a Java class that represents the twist-drilling process. The segment of the knowledge-base XML file is shown in Figure 3.5. It is clear that process capability data that require individual feature dimensions (diameter and depth) are stored as formulas for direct use by inference engine. The figure shows process knowledge for twist drilling (Table 3.1 and Figure 3.4) and a few data items read as follows: twist drilling precedes boring, precision boring and reaming operations; the largest hole that can be made by twist drilling is 2 in (50.8 mm); parallelism tolerance that twist drilling can achieve depends on the hole dimension and is given by the formula (0.003 + 0.001*(l/d)3), and so on.
Figure 3.5. Process capability knowledge base in XML format
Information from the knowledge-base XML file is parsed using a Java SAX parser into memory representation as the process precedence graph and as attributes for each machining process.
10. Check boring for conditions not met by the core making processes. If this succeeds, list this as the process after core process in an alternate series and exit.”
Therefore, it appears very natural to use the same paradigm (rule-based systems) to implement the process selection reasoning into CAPP system. We have used rule- based production system approach [3.10] for developing and implementing process selection module RBPS. Rule-based programming is an AI approach for problem solving that separates reasoning from knowledge and data (Figure 3.6). Four major components of a rule-based system are: knowledge base (production memory1), data base (working memory), inference engine (algorithm), and knowledge acquisition.
Figure 3.6. Rule-based systems architecture
Production memory consists of a set of rules that are completely independent of each other; rule execution is controlled by data, not by program flow. Rules represent localised pieces of knowledge as shown in the above example. A rule is fired (executed) when all condition patterns match and at that point the right side of the rule (action) is executed, which usually results in modification of the working memory to allow other rules execution. Working memory is a set of facts that are subject of reasoning. Facts are used as patterns to satisfy rule conditions, and rule execution modifies working memory (rules may add, delete or modify facts). The inference engine is the component that controls the rule-based system execution. It is done through a match-select-execute loop, where the match step performs pattern matching from working memory into the LHS of rules in order to determine which rules can be fired, the select step orders rules that can be fired according to the control strategy and select the one to be executed, and the execute step performs an action from the RHS of the selected rule. After the selected rule is fired, the execution steps are repeated and the loop runs as long as there are rules to be fired.
The production memory or rule base for process planning is usually developed separately for each phase in process planning. These groups of rules are the following:
1 Terminology used in explaining production systems is usual in AI research.
1. Rules for relationships between features define precedence relations that determine which feature should be machined after which. These rules consider spatial, quality and tolerance relations between features and restrict their manufacturing order.
2. Rules for selection of processes define machining processes that may be used for manufacturing the feature, and create the corresponding operations.
3. Rules for selection of machines and tools use previously defined operations for the feature and knowledge-base that associate processes to machines and tools to select the appropriate machine and tool for a given operation.
4. Rules for selection of a resting face choose the appropriate orientation and corresponding faces of a part as the basis for fixture design by checking the machine toolhead orientation.
5. Rules for process sequencing define the order of machining based on feature precedence.
This chapter addresses the rules in groups 2 and 3, while group 1 belongs to feature recognition and modelling, and groups 4 and 5 belong to setup planning and sequencing, with all three of them being outside the scope of this chapter. The process selection knowledge described in Section 3.3.1 has been coded into a rule set using Jess language [3.11]. An example of rules developed to capture the process selection procedure is shown in Figure 3.7. This rule can be interpreted to execute the following reasoning: if there exists a fact of template feature in working memory with name ?f1 that is of type slot with status input, such that its quality is less than or equal to 30, then modify its (?f ) status to process and assert two new facts of template operation, one for the end-milling-slotting process and another for the side- milling process, link them with feature ?f1, make them mutually exclusive (options or) and require another processing due to high quality (cut is set to double).
Figure 3.7. Rule for selection of slot manufacturing processes
Implementation of such rules for all manufacturing process selection situations from groups 2 and 3 mentioned above results in the rule base for that task. We have implemented such a rule base (with a total of 32 rules for various feature/process/
tool/machine combinations) in the initial development of the system in order to verify all processing and reasoning requirements. However, such a rule base carries the knowledge about process capabilities in itself. For example, a value of 30 Pin for capability for slot quality is hard-coded in the above rule. Any change in knowledge, for example in cases where manufacturing improves (resulting in better capability), would require recoding of this rule. In order to accommodate further separation of knowledge and reasoning, the final rule-based prototype was extended such that
(defrule slot2.fine
?f <- (feature (name ?f1) (type slot) (status input) (quality ?quality&: (<= ?quality 30))) =>
(modify ?f (status process))
(assert (operation (feature ?f1) (process end-milling-slotting) (cut double) (options or))) (assert (operation (feature ?f1) (process side-milling) (cut double) (options or))) )
rules provide a general reasoning mechanism, and that knowledge is read from XML into working memory, and some reasoning is performed by supporting functions.
In the extended prototype, rules for the process selection have been grouped into the following groups:
1. Rules for process consideration, which, based on feature dimensions and tolerances, decide which processes to consider:
• If the hole has cast diameter, consider hole improving directly.
• If the hole requires tight true position tolerance, apply SpotDrilling first.
• If the slot is closed, consider only end milling; if it is open, consider both end and side milling.
2. Rules for capability testing, which test each individual tolerance requirement and decide if there is a complete match, a partial match or no match:
• If the match is partial, accept the process and create an in-process feature (with unsatisfied tolerances) with processes from precedence.
• If the match is complete, accept the process but do not expand the hole feature into an in-process feature.
• If there is no match, still create an in-process feature (for this case, logic may depend on the process, but further processing is not performed in the current prototype).
3. Rules for tool, machine and cutting parameter selection, which select the machine and tool appropriate for the process based on feature dimensions, and select cutting parameters from the database.
These improved rules have also been implemented in Jess language with an example shown in Figure 3.8. This rule for process complete match may be read in plain English language as: “For hole ?jh, process capability ?pc for process
?processName, and process/feature relation with status of 1 (COMPLETE MATCH), modify the process/feature relation status to 5 (SOLVED), create a new process instance of the ?processName class on feature ?jh, add this instance to the part ?part, and delete (retract) the in-process feature ?nf ”. The corresponding rules for the above-described situations have been implemented.
Figure 3.8. Rule for process complete match in extended RBPS
The procedure for process selection in Jess is illustrated on a single slot feature.
A rule-based engine requires data for slot and part in the form of facts given in
(defrule SelectHMProcessCompleteMatch
?jh <- (Hole (mayBeMachinedBy ?mbmb)(processes ?processList) (OBJECT ?o) (featureName ?fName) (partModel ?part))
?pc <- (ProcessCapability (name ?processName) (OBJECT ?pcObj))
?nf <- (Hole (OBJECT ?nfObj))
?do <- (ProcessFeatureRelation (oldFeature ?jh) (newFeature ?nf) (processCap ?pc) (status 1))
=>
(modify ?do (status 5))
(bind ?processInstance (createProcessInstance ?jh ?processName)) (addProcessToPart ?part ?processInstance)
(retract ?nf) )
Figure 3.9. Two facts are asserted, one for the part data giving the part material (carbon steel) and its stock dimensions (16u12u8 in), and another for the feature giving its type (slot), normal (z-pos), dimensions (width = 1.0, depth = 1.0 and length = 7.5), quality (50) and status (input).
Figure 3.9. Fact assertion for a slot feature
The feature status “input” triggers the rule execution (shown in Figure 3.10) that demonstrates that slot1.rough rule was executed for the feature creating two alternative processes (side-milling and end-milling-slotting), and reasoning for both processes is completed by selecting tool, machine, cutting parameters and calculating the processing time, as seen in the list of facts after execution.
Figure 3.10. Rule execution of process selection for slot 3.3.3 Knowledge Base/Database
Our database consists of three segments: (a) a machine database that includes information for machines available for process planning (the attributes needed for process planning are provided for each machine); (b) a tool database that includes available tools for manufacturing (we extended tools from the previous research prototype RTCAPP [3.12] by introducing more tools made of different tool materials to cover a variety of scenarios); and (c) a cutting-parameter database that includes suggested speed and feed data for the processes under consideration and
Jess> (run)
FIRE 1 MAIN::slot1.rough f-32
FIRE 2 MAIN::rule-mach f-32, f-31, f-34, f-1, f-0 FIRE 3 MAIN::tool-rule3 f-32, f-34, f-11
FIRE 4 MAIN::calc-mach-time-side-milling f-31, f-34, f-0, f-32, f-11, f-26 FIRE 5 MAIN::calc-mach-cost f-34, f-11, f-0
FIRE 6 MAIN::emsm-complete f-32, f-34, f-11 FIRE 7 MAIN::rule-mach f-32, f-31, f-33, f-4, f-0 FIRE 8 MAIN::tool-rule5 f-32, f-33, f-7
FIRE 9 MAIN::calc-mach-time-end-milling-slotting-slot f-31, f-33, f-0, f-32, f-7, f-28 FIRE 10 MAIN::calc-mach-cost f-33, f-7, f-0
FIRE 11 MAIN::ems-complete f-32, f-33, f-7 11Jess> (facts)
f-31 (MAIN::part (material CarbonSteel) (x-dim 16) (y-dim 12) (z-dim 8) (batch-size 1000.0)) f-32 (MAIN::feature (name rs12) (type slot) (quality 50) (tolerance nil) (normal z-pos)
(slope 0) (dim1 1.0) (dim2 1.0) (dim3 7.5) (diam03 0) (status process)) f-33 (MAIN::operation (feature rs12) (process end-milling-slotting) (cut single)
(options or) (machine ML100) (tool T510) (op-time 2.81) (cost 3.66)) f-34 (MAIN::operation (feature rs12) (process side-milling) (cut single) (options or)
(machine ML100) (tool T630) (op-time 0.72) (cost 0.94)) (assert (part (name scfdemo04) (material CarbonSteel) (batch-size 1000.0) (x-dim 16) (y-dim 12) (z-dim 8)))
(assert (feature (name rs12) (type slot) (normal z-pos) (dim1 1.0) (dim2 1.0) (dim3 7.5) (status input) (quality 50)))
combinations of part and tool materials. A small database has been implemented in XML format, but the system can also be connected to other databases.