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

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

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”))

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)

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. 

In general, a rules manager process runs periodically (i.e. every 5 seconds) in the background on the host control system.  It is responsible for the following tasks:

• Monitor rules configuration files for changes to any rule definitions.

• Monitor each rule to determine if it is time to evaluate the criteria and, if the criteria are satisfied, perform the specified output actions.

• Write operating data to the rules configuration file so that processing of rules can continue seamlessly across any system restarts.

• Perform diagnostic tests for debugging rules on a development system.

• Log all activity to the NtRtMgr console.

A manager process is not provided with TSENTRY.  Custom implementations of a rules processing system can either use the default tpriRpsProcessor class to create a rules processor object or they can extend the tpriRpsProcessor class to customize the rules processor object.  All that is required then within the manager process is to create and initialize the tpriRpsProcessor or tpriRpsProcessor‑derived object and then periodically call the ProcessRules() member function to perform rules processing.

A rules manager process is configured by a single file containing the list of rules defined in the system.  This single file contains all information about all defined rules and is fully maintained by the process itself.  That is, the manager process periodically re-writes this file with the latest configuration and status information as the rules are processed; for instance, every time a rule is evaluated the NextEvalTime parameter for that rule must be updated, since the next time that the rule should be evaluated has changed.  Because this file contains all of the latest configuration information, when the rules system is stopped and restarted it can easily restore itself to the exact configuration it was in before shutdown.

Requests for various operations on the system, such as to activate or deactivate a rule, are sequenced into the manager using command files.  A command file directory is specified during rules processor initialization, and this directory is periodically monitored for any files with specific file extensions.  The defined extensions are:

This directory is typically exposed via a network share so that Rules Processing System HMI screens can write command files to this directory.  Both the share permissions and the underlying NTFS file permissions for this directory must allow read and write access to the local tpriHmi user on the host system for access by the user interface.

In addition, the rules processing system periodically copies the current configuration file to this command file directory so that it can be shared with the HMI.  The HMI therefore periodically checks this directory for updated configuration files so that it can update its display of the current rules status.

In general, the user interface for a rules processing system is responsible for the following tasks:

Provide graphical user interface to allow users to create new rules, modify existing rules, and activate and deactivate rules on the host.

Provide feedback to the user about the current status of rules running on the host.