Process and Operation Optionality

For optional processes and operations, optionality modules can help determine whether the cost engine considers the process or operation to be required in order for the current process routing or operation sequence to make the current part or GCD. Here is how being required affects routing:

• If a process or operation is not required, it is removed from the current routing or sequence.

• If a process or operation is required and feasible, it is included in the current routing or sequence.

• If a process or operation is required and not feasible, the current routing or sequence fails.

A process or operation is required if and only if it is not user-excluded (see the aPriori User Guide) and any of the following is true of it:

• Is user included (see the aPriori User Guide).

• Has a taxonomy module whose evaluation yields no results.

• Has an optionality module that returns true.

• Has at least one required (in the sense described here) child in the process-operation hierarchy (see Cost Engine Details).

The code in an optionality module should specify the conditions under which the associated process or operation is required to be included in a process routing or operation sequence in order for that routing or sequence to successfully create a given part or GCD (assuming there are no required children of the process or operation—if there are required children, the process or operation is required, regardless of what its optionality module returns).

Only an optional node can have an optionality module.

When you navigate to the CSL modules for a node (see Navigating from the Template Graph to the Data for a Given Node), if the node has an optionality module, the module’s Type Name field is set optionalProcess or optionalOperation, and the label optionalProcess or optoinalOperation appears next to the folder icon.

Optionality module names start with opt and end with .csl.

This section includes the following subsections:

 Context of Evaluation

 Example