Operation Assignment
In this stage, the cost engine visits each node in the current part’s GCD hierarchy, attempting to assign it an operation sequence. For each GCD in the hierarchy, the cost engine picks an operation sequence that is associated (via operation templates) with that GCD’s type.
For each GCD, the cost engine expands its associated operation templates. It then considers several alternative sequences if necessary, and selects the first one that is successful in the following sense:
• All the operations in the sequence can be assigned a parent process or operation.
• All the sequence’s non-optional operations are feasible and can be assigned a tool (if appropriate)
• All children (if there are any) of the current GCD can successfully be assigned an operation sequence in the sense described here.
Note that the cost engine does not compare the costs of different candidate operation sequences as it does with candidate process routings; instead, it simply selects the first sequence that is successful in the above sense.
If no successful sequence is found, the GCD fails to cost, and the cost engine issues a warning to aPriori.
To make the assignments, the cost engine performs the following recursive procedure on each child GCD of the current part’s component GCD:
Expand the associated operation templates, and for each resulting operation sequence, do the following:
1 Parent assignment: Find an assignment of operations in the current sequence to processes in the current process routing (or to operations in the sequence currently assigned to the parent GCD of the current GCD) such that both the following hold:
o Each operation is an allowable child of its assigned process or operation (see the navigation pane of the CMWB).
o If one operation is earlier in the sequence than another, the first operation is assigned a parent that is the same or earlier than (in the process routing) the parent assigned to the other operation.
If no such assignment is possible, the cost engine issues an error message to the aPriori message tree, and moves on to the next operation sequence.
2 Feasibility and tool selection:
o For each node in the current operation sequence, evaluate the node’s optionality module.
o For each node in the current operation sequence:
- Evaluate the node’s feasibility module. If the module returns false and the node is non-optional, the current sequence as a whole is deemed infeasible, and the cost engine moves on to consideration of a new operation sequence. If the module returns false and the node is optional, the current node (together with any descendents) is removed from the sequence, and the cost engine proceeds to the next node of the current sequence, if there is one. If the module returns true or if there is no feasibility module, the cost engine proceeds to tool selection.
- Evaluate the node’s tool selection module. If the module fails to establish a non-null value for the CSL output tool, the current sequence is deemed infeasible, and the cost engine moves on to consideration of a new operation sequence. Otherwise, the value of tool is assigned to the current operation.
3 Child GCD operation assignment: Perform these steps (1, 2, and 3) recursively for the child GCDs (if there are any) of the current GCD. If the procedure succeeds, the cost engine selects the current operation sequence for the current GCD. If the procedure fails, the cost engine moves on to consideration of a new operation sequence.
Pseudo code for the procedure performed on each GCD might take the following form:
boolean assignOperations(GCD) {
Expand operation templates for GCD
for each operation sequence associated with the GCD {
Parent Assignment
if parent assignment was unsuccessful
continue (move on to the current GCD’s next operation sequence)
Feasibility and Tool Selection
if feasibility and tool selection were unsuccessful
continue (move on to the current GCD’s next operation sequence)
for each child GCD of GCD {
success = assignOperations(child GCD) // recursion
if !success break;
}
if !success
continue (move on to the current GCD’s next operation sequence)
else {
assign the current sequence to the current GCD
return true
}
}
return false
}
For process groups that have templates with zero-or-more nodes (see
Working with Templates, there is an additional step immediately before feasibility and tool selection (step 2, above, in this section). The cost engine evaluates a number of modules (such as precedence and compatibility modules), if present, in order to expand these nodes into zero or more individual operations.
This procedure is performed on the GCDs by performing up to four passes on the GCD hierarchy. This allows cost models such as machining to select operation sequences that minimize the number of different setup axes required to manufacture the current part. Pseudo code for these passes might take the following form:
// pass 1: CSL input passNumber has value 1
foreach non-axisymmetric child gcd of component {
assignOperations(gcd)
}
// pass 2: CSL input passNumber has value 2
foreach axisymmetric child gcd of component {
assignOperations(gcd)
}
// pass 3: CSL input passNumber has value 3
foreach unassigned non-axisymmetric child gcd of component {
assignOperations(gcd)
}
// pass 4: CSL input passNumber has value 4
foreach unassigned non-axisymmetric child gcd of component {
assignOperations(gcd)
}
During each pass, some operations are treated as if they are infeasible, so their consideration can deferred to a later pass:
• Pass 1: Only operation-sequence nodes with an ancestor whose value for the node attribute assignOpsWithActivePrimaryAxesFirst is true are treated as potentially feasible; all others are treated as infeasible.
• Pass 2: All hole-related and axigroove-related operations are treated as potentially feasible; all others are treated as infeasible.
• Pass 3: All surface-related operations are treated as potentially feasible; all others are treated as infeasible.
• Pass 4: Only nodes with an ancestor whose value for the node attribute runInFourthCostingPass is true are treated as potentially feasible; all others are treated as infeasible.
In addition, for all passes, operation feasibility modules can control which operations are considered feasible in a given pass by including rules that refer to the CSL input passNumber.
For passes 3 and 4, the GCDs are visited in order of descending size (based on the areaFinished GCD attribute), if some node of the current process routing has value true for the node attribute sortGcdsByFinishArea.
In summary, this stage involves evaluation of the following module types:
• Operation optionality
• Operation feasibility
• Tool selection
These types of modules are evaluated in the context of a process routing (and possibly a material stock), an assignment of machines to processes in the current routing, and a candidate operation sequence for the current GCD and all its ancestors. There are no candidate operation sequences for descendents of the current GCD. During any given evaluation, operation sequences for the current process routing have not yet been finalized, and no process has yet been costed.