Examines each Condition for each defined state in order, and executes the IfTrue script for the first true condition.

A data point change will result in at most one IfTrue script being executed. This is useful when you want to perform an action on every point change, with the action depending on the point value.

Examines each Entry Condition for each defined state in order, and executes the OnEntry script for the first true condition. Once the state has been entered, no further scripts will be executed until the Exit Condition for that state is met, at which time the OnExit script is executed and then each Entry Condition will be examined again to possibly enter a new state.

A data point change will result in at most one OnExit script and one OnEntry script being processed. This is used for conditions that consist of multiple mutually-exclusive states, similar to OPC A&E conditions.

Examines the Condition for every defined state, and if that condition is true then executes the IfTrue script.

A single data change could result in multiple IfTrue events being triggered. This is used when you simply want to specify a condition/action that gets re-evaluated on every point change.

This is a form of Stateful template that also generates data points that implement the data point format for OPC A&E Conditions. The OPC A&E server feature uses these points to create and transmit OPC Conditions to connected OPC A&E clients. This template also monitors the OPC A&E acknowledgement point for each condition to respond to acknowledgements from external clients.

This is used when you want to generate and manage OPC A&E alarms from process data.

This is a form of Stateful template that also generates data points that implement OPC A&E Simple Events. This is used when you want to generate transient events from process data. Events will only be generated when there is a state change and an entry condition to a new state succeeds.

This is a form of Stateless template that also generates data points that implement OPC A&E Simple Events. This is used when you want to generate transient events from process data. Events will be generated any time a trigger causes one of the state entry conditions to succeed.

This is a form of Stateless template that monitors OPC A&E Condition points provided by external OPC A&E servers. When an A&E condition event occurs, this template will extract the condition information and make it available to the Condition and IfTrue scripts to allow notification based on the A&E information.

This is used when you want to send an email, SMS, etc. based on OPC A&E events from an external OPC A&E server.

This is a form of Stateless template that monitors OPC A&E event points provided by external OPC A&E servers. When an OPC A&E Simple or Tracking event occurs, this template will extract the event information and make it available to the Condition and IfTrue scripts.

This is used when you want to send an email, SMS, etc. based on OPC A&E events from an external OPC A&E server.

Notifications are based on the state of the system, which is determined by point values and possibly other factors.

Each state has a Name and typically an Entry Condition, as defined in State Properties, below. The states are evaluated in sequence from the top to the bottom of the list. You can use the Move Up and Move Down buttons to change the order of evaluation.

The state properties available depend on the Type defined for the template.

Some or all of the following properties are available for OPC A&E Condition and OPC A&E Event Types.

The script editor includes a list of common script formulas and fragments. You can position the edit cursor in the edit window, and then double-click any of the formulas to insert the text into the edit window. You can also make use of many classes and methods defined by the .NET framework.

You can test your script by entering values for the variables and pressing the Execute button. This will execute just this script, as if its trigger condition had been met, using the variable values that you enter into the Testing area. You must supply values for all variables. If your script has side effects, such as sending an email or SMS message, then those side effects will occur.

A binding definition is the set of all concrete values for a single instance of the action template. That is, each line of the Binding Definitions list specifies all the values for the variables in the template, and each line constitutes a distinct instance of the template. For example, if you want to generate a notification based on the water levels in Tank1 and Tank2, you would create a separate binding definition for each of Tank1 and Tank2. The template specifies how to handle notifications for tanks in general, and the two binding definitions then apply that to tanks 1 and 2.

Only the First Variable binding is displayed in this list to help you identify each binding definition.

Variables are bound by entering values according to each variable's Type (a DataHub point, integer, double, or string) defined previously.

The first variable in the binding definition is treated differently from the others. This variable can be defined as a regular expression instead of a simple string. This regular expression can match any number of data points, and each match will be treated as a distinct binding definition. This allows you to create a single binding definition that applies to all data points matching a pattern. Regular expressions use .NET Regex syntax. The comparison succeeds if the regular expression matches any part of the point name, so if you want a full string match ensure that the regular expression is bounded by the ^ and $ characters (start and end of string respectively).

For example, if we have 2 tanks, whose levels visible in the points Plant:Tank1.level and Plant:Tank2.level, then the pattern Plant:Tank[0-9]+\.level will match any point whose name is Plant:Tank followed by any sequence of digits, followed by the string .level. Thus, this one binding will apply to both tanks. If we later add a third tank, named Plant:Tank3.level, then this binding will apply automatically to it without any change to the notification configuration.

When the first variable binding is a regular expression, we may also want to make other variable bindings relate to that regular expression. For example, we may want to create a new point, Plant:Tank1.alarm, which has a value of 0 in normal operation and 1 when the level is too high. In that case, we would have two variables, named Input and Output where Input is Plant:Tank1.level, and Output is Plant:Tank1.alarm. The OnEnter and OnExit scripts in the notification template would write values of 0 or 1 to the Output variable as appropriate.

However, if we use a regular expression to match all tanks, then we need a way to say that Output is Plant:Tank1.alarm when Input is Plant:Tank1.level, but Output is Plant:Tank2.alarm when Input is Plant:Tank2.level, and so on. We can accomplish this with regular expression captures. A capture is a portion of the input string that matches a portion of the regular expression. Captures are denoted by parentheses in the regular expression.

For example, in our tank expression, Plant:Tank[0-9]+\.level we would like to identify the numeric sub-expression and use it to define Plant:TankN.alarm, where N is any number. We do this by adding parentheses around the numeric portion of the expression: Plant:Tank([0-9]+)\.level. This will result in a capture that contains only the digits after the word Tank. There can be multiple captures in the regular expression, and they will be numbered in order starting from zero.

Now, to construct an alarm point name that corresponds to the level point, we can define Output as Plant:Tank{0}.alarm. The {N} syntax tells the binding to substitute the Nth capture from the regular expression in the Input variable into that position in the binding of the Output variable. In this example we want the first capture, which is {0}. You cannot use the {N} syntax in the first variable binding, since that is the regular expression binding that produces the captures. Captures are strings, so numeric .NET format substitution qualifiers cannot be used.

An explanation of the use and syntax of .NET Regular Expressions can be found here. Please see Regular Expressions in the Making Notifications chapter for an example.

You can use the Regex Explorer to see how a regular expression will be implemented.

In the First Variable entry field, enter the name of a data point. If it meets the criteria of the regular expression, it will be displayed in the Value column. All other variables in the binding definition will be displayed, with the capture substitutions shown so you can verify that both the regular expression and its captures are what you intend.