Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

The Rules Processing System is designed to provide a process engineer with an easy way to implement automated decision making on a process control system without requiring the engineer to write C/C++ code to execute on the system.  Instead, it allows the engineer to create a set of Operational Rules which are applied to the control system.  An Operational Rule is the combination of a set of criteria with a set of actions to be performed when those criteria are met.  For instance, an Operational Rule may specify that the resistance target of a given pot should be altered when that pot attains a specific pot age.  

The Operational Rules System consists of a supervisory process running on the control system that manages each of the operational rules, tests the criteria to determine if the rule is satisfied, and, if so, takes the appropriate actions.  A single control system may have any number of rules defined, each of which is independently evaluated by the rules manager process.  In addition, the Rules Processing System provides a user interface to allow the engineer to create, modify, and load Operational Rules on the control system, as well as to view the status of all installed rules.

Refer to the following sections for further details about the Rules Processing System.


Rule Specifications

 Default Rule Parameters

In general, each rule is specified by the following parameters:

Parameter Name

Description

Format

Name

Name of rule.

-

Description

Description of rule.

-

Enabled

Flag indicating if the rule should be processed.

True/False

NextEvalTime

Next time at which the criteria should be evaluated.

yyyy/mm/dd hh:mm:ss.nnn

EvalInterval

Interval at which the criteria should be evaluated.

dd hh:mm:ss.nnn

LockTimeOfDay

Flag indicating if the processing time should be locked to the time of day even across changes in daylight savings time (if true, then the test period will be extended or contracted across daylight savings time changes); for example: if a rule should be evaluated every day at 8 am, this flag should be set TRUE so that the system triggers on the new 8 am across daylight savings time changes.

True/False

EvalWindow

Window of time after a rule is supposed to be processed during which the rule is allowed to be processed, i.e. if the rules processing system is down at the time at which the rule is supposed to be processed, this value specifies how soon the rules processing system must come back up and still process this rule for this time period.

dd hh:mm:ss.nnn

RearmInterval

Interval after the rule criteria has been satisfied and actions have been performed before the rule is re-armed again for further processing.

dd hh:mm:ss.nnn

Criteria

Group of conditions logically AND’ed together to determine whether or not the rule is currently satisfied.  These are described in more detail below.

-

Actions

Group of actions executed when the rule criteria are satisfied.  These are described in more detail below.

-

In addition, there are several parameters associated with a rule to provide feedback to the user:

Parameter Name

Description

Format

Status

String description of current rule status.

-

Error

Current error code (0 = no error).

-

LastEvalTime

Last time that the rule criteria were evaluated

yyyy/mm/dd hh:mm:ss.nnn

LastActionTime

Last time that the rule criteria were satisfied and the rule actions were taken.

yyyy/mm/dd hh:mm:ss.nnn

LastVerifyTime

Last time that the rule was verified.

yyyy/mm/dd hh:mm:ss.nnn

LastErrorTime

Time that the last error occurred, or zero if there is no current error.

yyyy/mm/dd hh:mm:ss.nnn

LastModifyTime

Last time that the rule definition was modified; this does not include changes and updates to the rule status parameters listed in this table.

yyyy/mm/dd hh:mm:ss.nnn

 Criteria

In general, the rule criteria are the conditions that must be met before the rule actions can be taken.  Each of the Boolean statements specified in a criteria group must be satisfied in order to consider the criteria group completely satisfied and to trigger the output actions.  This is equivalent to saying that all of the Boolean statements contained in a criteria group are AND’ed together to produce the value of the entire expression.  This includes any sub-criteria groups that are contained within a parent criteria group.

However, the rule itself may contain multiple criteria groups.  Each of these root criteria groups are OR’ed together during evaluation of the rule to produce the final result.  Because any Boolean statement can be represented in Sum-Of-Products form (the logical-OR of groups of AND’ed statements), this criteria group structure is capable of storing any Boolean statement.

Currently, the only type of criteria that may be specified in an operational rule is a VariableCondition.

VariableCondition Criteria

A VariableCondition is an expression containing variables from global common and/or constant values.  The condition is considered true if the expression evaluates to a non-zero value, otherwise the condition is considered false.  A VariableCondition expression is formatted identically to a standard Variable Operation.

Following are examples of VariableConditions:

(mycommon.myfloat > 0)
(mycommon.mychar == ‘a’)
(mycommon.myfloat >= mycommon.myint)
(mycommon.mystring != “samplestring”)
(mycommon.myfloat > (mycommon.myint – 3.141))
((mycommon.myfloat > mycommon.myint) && (mycommon.mystring != “string”))
 Actions

In general, the rule actions are those instructions carried out when the rule criteria conditions are met.  The order of actions performed corresponds to the order in which they are specified in the rule definition.  Any action that cannot be performed due to improper formatting or variable types will be skipped and the following action performed.  In this case, a log entry will be generated to record the error event.

Currently, the only type of action that may be specified in an operational rule is a ModifyVariable statement. 

 

ModifyVariable Actions

  • A ModifyVariable action statement modifies the value of a variable in global common.  An assignment operation must be specified in the following form:

GlobalVariable = Expression

where:

GlobalVariable is the fully qualified name of variable in global common whose type is int, float, double, long, short, char, or char[].

Expression is any expression in a form identical to a standard Variable Operation.

 

The following special conditions apply:

  • Character array variables can only be set equal to expressions that are other character array variables or string constants.

 

Following are examples of valid expressions:

mycommon.myfloat = 3.141
mycommon.mychar = ‘a’
mycommon.mystring = “samplestring”
mycommon.myfloat = (mycommon.myint + 3.141)
mycommon.myfloat = (mycommon.myfloat * mycommon.myint)
 File Format

Rule definitions are stored on disk in an XML file format.  An example file containing a generic rule definition is shown below.

<?xml version="1.0" encoding="utf-8"?>
<OperationalRules>
  <Rule>
    <Name>Rule #1</Name>
    <Description>Rule #1 description</Description>
    <Enabled>True</Enabled>
    <NextEvalTime>2004/10/18 11:39:00</NextEvalTime>
    <EvalInterval>00:01:00</EvalInterval>
    <LockTimeOfDay>False</LockTimeOfDay>
    <EvalWindow>00:30:00</EvalWindow>
    <RearmInterval>08:00:00</RearmInterval>
    <Criteria>
      <VariableCondition>(mycommon.myvariable &gt; 5.0)</VariableCondition>
    </Criteria>
    <Actions>
      <ModifyVariable>mycommon.myothervariable = 0.0</ModifyVariable>
    </Actions>
    <Status>Rule Rule #1 active</Status>
    <Error>0</Error>
    <LastEvalTime>2004/10/18 11:38:00.0632904</LastEvalTime>
    <LastActionTime>2004/10/15 12:49:00.092576</LastActionTime>
    <LastVerifyTime>2004/10/15 12:47:23.5585345</LastVerifyTime>
    <LastErrorTime>0</LastErrorTime>
    <LastModifyTime>2004/10/15 12:47:08</LastModifyTime>
  </Rule>
</OperationalRules>

Rule definitions can be stored either with only one rule per file or with multiple rules in a single file. 

Class Libraries - Rules Processing System API

The Rules Processing System API consists of a set of hierarchical classes defined in the TSENTRY tpriNtRt C/C++ library.  See the tpriRps library documentation for more details about these classes.

  • No labels