if rule changes (forward chaining).
initially rule is activated.
whenever rule.
focus or invoke action that names an object, object class, or rule category associated with the rule.
Based on the kinds of reasoning that you desire, you should develop rules that use the appropriate mechanisms for rule invocation.
if rules Forward chaining is a form of deductive reasoning. Your KB can use rules invoked using forward chaining to draw conclusions from other rules. Similarly, your KB can use forward chaining to initiate actions from conclusions drawn in other rules.
When forward chaining takes place, G2 identifies all rules whose antecedents refer to the changed value. If a rule concludes the new value, the rule must be able to cause forward chaining. The rules that refer to the value in their antecedents must be invocable via forward chaining. G2 invokes these rules in parallel, and schedules each for execution at its declared priority.
The following figure illustrates forward chaining by using an abstract example:
|
G2 invokes rules by using forward chaining when the value referenced in the antecedent changes for any reason, not just by concluding a value in another rule. Also, the value referenced in the antecedent can be an attribute, a variable, or a parameter. G2 only forward chains to rules when a variable or parameter referenced in the rule receives a new value that is different from its previous value; whereas, G2 forward chains to rules whenever an attribute referenced in the rule receives a new value, regardless of whether the value has changed.
if valve-is-broken of valve-1
then conclude that the temperature-is-too-hot of tank-1 is true
Temperature-is-too-hot of tank-1, G2 forward chains to any rule that 1) refers to the Temperature-is-too-hot of tank-1 in its antecedent, and 2) can be invoked using forward chaining. For example, G2 could forward chain to this rule:
if temperature-is-too-hot of tank-1
then invoke safety rules
Temperature-is-too-hot of tank-1, which is given by a logical variable that is declared to use forward chaining.
To use forward chaining in rules:
Options attribute:
may cause forward chaining
Options attribute:
invocable via forward chaining
Options attribute for the variable or parameter, whose value is obtained via forward chaining:
do forward chain
do forward chain in their Options attributes. Text and quantitative variables and parameters have the default setting do not forward chain in their Options attributes. You can edit these settings so that any variable or parameter in your KB can support or not support forward chaining. This figure illustrates how concluding a new value for an item in one rule causes forward chaining to other rules whose antecedents refer to that item. In this example,
Level-status is an attribute whose value is given by a symbolic variable.
 |
In general, forward chaining only works with
if rules. Although G2 never allows forward chaining to a whenever rule, you can potentially forward chain from a whenever rule. In this case, forward chaining can occur when a whenever rule concludes a value for a variable that is declared to participate in forward chaining. All other rules can be set to be invocable or not invocable by forward chaining. Ordering of Rules Invoked by Forward Chaining
When two or more rules are invocable due to forward chaining based on a change to the same attribute or current value of the same item, G2 does not specify the order in which those rules are invoked. Rule-priority attributes of the rules differently. When this has been done, G2 schedules the rules for invocation according to their priority. Implementing Loops Using Forward Chaining
A rule can potentially forward chain to itself. For example, given that the value of X is greater than zero, the first time the following rule is invoked it forward chains to itself many times within a second, until X equals 20:
if (x > 0 and x <= 19)
then conclude that x = x + 1
X equals 20. In contrast, the next rule can forward chain to itself repeatedly without stopping, thereby heavily loading G2's ability to run all the current activities:
if x > 0
then conclude that x = x + 1
The following figure illustrates backward chaining by using an abstract example:
 |
To illustrate with a simple example, suppose the following rule is invoked by scanning:
if valve-is-broken of valve-1
then focus on repair rules for valve-1
Valve-is-broken has no current value, then G2 backward chains to any rule that 1) concludes a value for the Valve-is-broken attribute of valve-1, and 2) can be invoked using backward chaining. For example, G2 could backward chain to this rule:
for any valve V
if valve-is-closed of V and tank-is-overflowing of the tank connected to V
then conclude that valve-is-broken of V
Valve-is-broken of valve-1, which is given by a logical variable that is declared to use backward chaining. To evaluate the antecedent of this rule, G2 might be required to backward chain to other rules that provide values for
Valve-is-closed and Tank-is-overflowing, which are also variables. G2 continues to backward chain to other rules until it can fully evaluate the antecedents of each invoked rule.
To use backward chaining in rules:
Options attribute:
may cause data seeking
invocable via backward chaining
Formula attribute of the variable. Such a variable cannot be used in the consequent of a rule, but can be used in the antecedent. For further information, see Variables, Parameters, and Rules and Obtaining Values for Variables.
The following figure shows another example of backward chaining. Note that a rule cannot backward chain to a
when rule, because when rules do not support backward chaining.
 |
Using Breadth-First Backward Chaining
If you have a set of rules that provide a new current value for a variable, you can organize the set of rules to be invocable by using breadth-first backward chaining.
To use breadth-first backward chaining:
Options attribute for the variable whose value is obtained via backward chaining:
breadth first backward chain
In the following figure, in the rule on the right, suppose the
Direction of robot-arm-1 is given by a variable. If the variable declares breadth-first backward chaining, G2 invokes each rule that can provide a value for that variable.
 |
Note: When G2 invokes rules that can conclude a value for a variable that declares breadth-first backward chaining, G2 does not cancel the invocation of the same rules invoked due to some other rule, procedure, or function.
Using Depth-First Backward Chaining
Often, rules provide different techniques for determining the value of a single variable. These techniques are called heuristics. When more than one rule provides a value for a variable via backward chaining, you might want to specify the order in which G2 executes each rule by specifying a precedence. This is called depth-first backward chaining.
To use depth-first backward chaining:
Options attribute for the variable whose value is obtained via backward chaining:
depth first backward chain
Depth-first-backward-chaining-precedence attribute in each rule that concludes a value for the variable in its consequent.
ok, high, or overflowing. You might use distinct rules, each implementing a different heuristic, to set the Level-status attribute of the valve. This figure shows three rules that implement heuristics for determining the
Level-status of a valve. The precedence order is shown in the figure and indicates the likelihood of finding a result.
 |
G2 invokes a rule with the next lower precedence only if rules with higher precedence have completed without concluding a new value for the variable. G2 waits for a rule to complete before invoking the rule with the next lower precedence, even if that rule must backward chain to other rules. After each rule is invoked, G2 schedules it for execution at its declared priority.
Note: The precedence for a rule for depth-first backward chaining differs from its priority. Precedences determine the order in which G2 invokes a set of rules that provide a new value for the same variable. Priorities determine which tasks can wait if G2 is fully loaded with activities to perform in a particular G2 clock tick.
Activating the Parent Workspace of a Rule
G2 invokes an initially rule each time the parent KB workspace of a rule is activated. For a description of initially rules, see the section Initially Rules.
When G2 starts the current KB, G2 activates all enabled top-level workspaces. Next, G2 activates in turn all enabled KB workspaces that are in the workspace hierarchy below the activated top-level workspaces. However, when G2 starts the current KB, G2 does not automatically activate subworkspaces that are configured as activatable subworkspaces.
Detecting Events
G2 can invoke certain rules after detecting an event. This mechanism is called event detection. whenever rules after detecting the event specified in the antecedent of a rule. For example:
whenever the temperature of tank-1 receives a value
then start update-maximum-temperature (tank-1)
whenever rule in response to these events:
Scanning Rules
For rules that contain a value in the Scan-interval attribute, G2 invokes rules once per the specified time interval. This mechanism is called scanning, because G2 invokes rules due to the passage of time, as opposed to based on the state of knowledge in your KB.
To invoke a rule by scanning:
Specify a time interval in the Scan-interval attribute of the rule.
the temperature of tank-4 every five minutes, you can assign a Scan-interval of 5 minutes for the following rule:
if the temperature of tank-4 > 40 F
then inform the operator that "Tank-4 is overheating."
Scan-interval attribute for an initially or whenever rule. Minimum-scheduling-interval attribute of the Timing Parameters system table. G2 cannot perform rule scanning more often than the minimum scheduling interval, when this value is a number. This means that you must determine which time interval is most significant for your KB processing: the
Minimum-scheduling-interval attribute, which affects all activities that G2 performs for your KB, or the Scan-interval attribute of a scanned rule. If some scanned rule must be invoked more often than the minimum scheduling interval, you must either decrease the setting of the Minimum-scheduling-interval attribute or increase the Scan-interval setting for the most frequently scanned rule or rules. To determine the rate at which G2 must service scanned rules, you should first identify those rules. Next, determine which of those rules has the shortest time interval (that is, the smallest value) in its
Scan-interval attribute. This value represents the slowest rate that the G2 scheduler can schedule its activities and still invoke scanned rules.
Scan-interval attribute of a rule to a time interval shorter than (smaller than) the time interval found in the Minimum-scheduling-interval attribute of the Timing Parameters system table. If G2 scans many rules, in some circumstances, the performance of the KB might be constrained. An important goal of analyzing your application is to identify the objects whose knowledge directly depends upon the passage of a fixed time interval. Only those objects should be manipulated due to invoking scanned rules.
Your application will be easier to understand and maintain, and will perform with less overhead, if you define the majority of the objects in your application so that they respond to events other than the passage of a fixed time interval. For more information, see Detecting Events.
Scanning Generic Rules
Avoid coding generic rules that are invoked via scanning. For each generic rule that is scanned, at the beginning of that rule's scan interval, G2 invokes one copy of that rule for each item or value in the set identified in the generic reference expressions in the antecedent. For more information, see Determining the Number of Generic Rules That are Invoked.
Focusing on Rules and Invoking Rules by Category
If the majority of your rules are generic, you can invoke these rules so that they apply only to a particular item or set of items. This is called focusing. G2 supports two mechanisms for invoking rules by focusing:
focus action names as its argument a focal object or focal class of objects. Executing the focus action causes G2 to invoke all rules that are associated with that focal object or focal class.
To associate a rule with a focal object:
Specify one or more objects in the Focal-objects attribute of the rule.
To associate a rule with a focal class:
Specify one or more object class in the Focal-classes attribute of the rule.
When G2 invokes a generic rule due to focusing, G2 applies the rule to each object that is an argument of the
focus action. For example, suppose you have this generic rule, which specifies
TANK in the Focal-class attribute of the rule:
if the status of any tank T is ready
then change the background-region of T to the ready-color of T
water-tank-1:
focus on water-tank-1
TANK as the focal class, which is a superior class of water-tank-1.The
focus action can also act upon a set of objects. For example, when G2 executes the following action, G2 invokes the rule above and applies it to each water tank upon the parent workspace of the item that specifies this focus action:
focus on every water-tank upon this workspace
invoke action takes as its argument one or more rule categories. This action causes G2 to invoke all rules that are associated with the named category.
To associate a rule with a rule category:
Specify one or more symbols in the Categories attribute of the rule.
Categories attribute of any enabled rule. safety and quality in its Categories attribute:
if any tank T is overheated
then inform the operator that
"The tank [the name of T] is hot."
safety rule category, you capture the knowledge that an overheated tank is unsafe. By associating this rule with the quality rule category, you capture the knowledge that an overheated tank reduces the quality of the product that passes through that tank. Executing the following action causes G2 to invoke all rules that are associated with the
safety rule category, all rules that name tank-1 as a focal object, and all rules that name TANK (or any superior class of TANK) as a focal class:
invoke safety rules for tank-1
invoke action whose argument is a set of objects, G2 invokes one copy of the rule for each named rule category and for each object in the set. For example, executing the following action causes G2 to invoke one copy of each rule associated with the
safety and quality rule categories for each object upon the parent KB workspace of the item that contains the action:
invoke safety and quality rules for any object upon this workspace
invoke action causes G2 to invoke a generic rule, G2 invokes one copy of that rule for each object in the set of objects named as the argument to the invoke action.