For information about other types of rules, see Guidelines for Implementing Rule-Based Processing.
Using "Whenever" Rules to Detect Events
Often, your application needs to detect and respond to events. For example, you might need to detect an event such as a tank overheating or a network connection dropping. Based on detecting the event, you might trigger a method on a class, which would invoke some type of sequential processing.
Each time an event occurs that causes a rule to be invoked, G2 creates a new process, which executes independently of any other process. For example, if you have a rule that detects the event of a user moving an item on a workspace, G2 creates a new independent process.
The Five Types of "Whenever" Rule Events
You use "whenever" rules to compute and infer data based on these types of triggering events:
Example of Event Detection
The most common form of event detection is a rule that detects an event and initiates some form of procedural processing, as this figure illustrates:
|
For example, you might create this rule:
whenever the connection-status of any server S = the symbol offline
start diagnose (S, the symbol offline)
start action that explicitly invokes the method.
You implement data-driven processing by creating a series of "if" rules that test data values and trigger other "if" rules based on the outcome of the test. G2 triggers the "if" rule whenever the data value changes, by using a mechanism called forward chaining. When G2 detects a change in the value of a piece of data, it forward chains to any "if" rule that refers to the data value in its antecedent.
Each time G2 forward chains to a rule, it creates a new process. Thus, if you have a series of "if" rules that implement some kind of decision-making, G2 creates a separate process for each "if" rule in the chain each time a specific data value changes.
While forward chaining represents a powerful way of representing complex decision-making logic in an application, forward chaining can also be the source of a great deal of unnecessary complexity. An application that has a large number of "if" rules that follow a complex path of execution is much harder to debug, test, and maintain because the number of possible outcomes is so vast. Thus, you need to be thoughtful in the way you use forward chaining in your application, and you should always consider whether you can implement the same type of decision-making more efficiently by using a method.
 |
for any server S1
if the connection-data of S1 = the symbol offline then
conclude that the connection-status of S1 = the symbol failing
for any server S1
if the connection-status of S1 = the symbol failing then
in order
start report-connection-status(S1) and
conclude that the status-reported of S1 = true and
conclude that the start-auto-system-shutdown = true
for any server S1
if the connection-status of S1 = the symbol failing and
the start-auto-system-shutdown of S1 then
start auto-system-shutdown
| Symbolic and Logical | Numeric and Text | |
|---|---|---|
|
Parameter
|
do forward chain
|
do not forward chain
|
|
Variable
|
do forward chain
|
do not forward chain
|
To override the default forward chaining options for a variable or parameter:
Create a subclass of the desired type of variable or parameter and specify Attribute-initializations for the Options-for-variable or Options-for-parameter system attribute.
Summary of When Attributes, Parameters, and Variables Forward Chain
Typed attributes, variables, and parameters have different behavior for forward chaining to "if" rules, which this table summarizes:
Using Backward Chaining
If the application does not know the value of a variable that is required to invoke a rule via forward chaining or event detection, G2 uses another form of chaining called backward chaining to determine its value. In backward chaining, when G2 requires a value for a piece of data, G2 invokes any rule that concludes the data value in its consequent. For example, G2 might use backward chaining to obtain additional data values that support the diagnosis of a failure.
Detecting When the Value of a Variable Changes
If you are detecting changes in the value of a variable, you can either use data-driven processing ("if" rules) or event detection ("whenever" rules). Depending on the type of rule you choose and whether or not the value of the variable changes, G2 invokes the rules differently, as this table describes:
Thus, if your variable does not specify a validity interval, it is generally more efficient to use an "if" rule as opposed to a "whenever" rule to detect changes in the value of a variable.
When Different Types of Rules Initiate New Processes
This table lists the various types of rule-based processing and when G2 creates a new process:
For example, suppose you have a set of "if" rules that implement some sort of decision-making. Each time G2 forward chains to an "if" rule, it creates and schedules a new process.
if-then statements. If the method maintains a single thread of processing, G2 only creates and schedules two processes: one for the event detector and one for the method. Thus, using a "whenever" rule to invoke a single processing thread to perform decision-making is usually more efficient than using a set of "if" rules.
Note: In addition to these forms of rule-based processing, G2 also creates new processes under these circumstances: each time you use a start action; each time G2 computes a generic or specific formula; each time G2 updates a display by evaluating an expression, for example, to update a chart, readout table; and each time G2 evaluates an expression when a user clicks a button or user menu choice.
For more information, see the references in this table:
Guidelines for Implementing Rule-Based Processing
Given the relatively limited need for rules in an application, you should follow these guidelines when creating rules. Emphasize "Whenever" Rules Over "If" Rules
In general, you should use "whenever" rules to implement event detection. You should only use "if" rules and forward chaining when you cannot implement the decision-making by using some other technique, such as by creating a method. Encapsulate the Consequent of a "Whenever" Rule
You use the consequent of a "whenever" rule to invoke methods and procedures that implement sequential processing based on the initial triggering event. The consequent of the "whenever" rule should invoke only a small number of methods or procedures. If the consequent of the "whenever" rule becomes too large, or if you need to control the order in which the processing occurs, you should encapsulate the consequent into a smaller number of methods or procedures. Avoid Scanning Rules
You can invoke "if" rules by scheduling periodic processing. This technique of rule invocation is called scanning and is a feature that only rules support.Scan-interval for the rule.
Scan-interval, and then concluding its value back to none. For example, you might use this technique to scan certain safety rules under alarm conditions.
for prefix in the rule or by referring directly to the generic class within the body of the rule. This type of rule is called a generic rule, because it applies generically to a wide set of instance of a class at a particular level in the class hierarchy. For example, these two rules are equivalent:
whenever any widget W becomes located-at any robot R
for any widget W
for any robot R
whenever W becomes located-at R
To control the startup behavior of different modules reliably, use the startup objects that the G2 Foundation Resources (GFR) utility module provides. This object allows you to control the exact order in which each startup procedure in each module executes.
For more information on controlling startup behavior, see the G2 Foundation Resources User's Guide.
For guidelines on using backward chaining, see Guidelines for Using Variables.
Narrow the Scope of Rules to Minimize Rule Invocations
G2 allows you to use these features to narrow the scope of any rule:
- A symbol associated with particular rules, which you specify in the Categories attribute of the rule
invoke action, for example,
invoke safety rules
Focal-classes attribute of the rule
focus on action, for example:
focus on every server connected to every network
Focal-objects attribute of the rule
focus on action, for example:
focus on server-1
Main Menu > Run Options > Highlight Invoked Rules. When this option is enabled, each rule that G2 invokes highlights for about 0.2 seconds, which is enough time to perceive the color change as a flash. During that time, no other activities take place within G2. Therefore, every rule that invokes when highlighting is enabled takes up about 20% of the available CPU. If you use this option during development, do not forget to disable it in the deployed KB.