A Sentinel test evaluates source data using a defined process, and raises events when the state changes. The states resulting from a test can trigger specified actions.
Every monitor has a collection of one or more tests. All tests run concurrently, as defined by the monitor trigger, and each test uses its own process.
The tests all belong to the same category, which is defined in the monitor.
A test may also have actions assigned to it. These are actions that are defined in the monitor, and may be assigned to any of the monitor tests.
You may also duplicate a Sentinel test, within the same monitor, giving the new test a unique name.
The following screen image shows a monitor with three separate tests:
The test details, as well as the process that each test uses, are listed in the Tests panel of the monitor.
A test has the following components:
Test Details
The name and description of the test. The test details are added when the test is set up, and may be edited. The test details are displayed in a grid in the Tests panel of a monitor, and should clearly identify the test.
Test Suppression
This is where a planned suppression of the test is defined. If you select Time Suppression, the test is suppressed between the specified start and end times; a notification email can be sent to specified recipients, at a predefined interval before the time suppression ends.
Source
The source data for the test is defined in this panel.
Precondition
While a test is running, any input values are evaluated for the periods when the precondition is true. This precondition may be the state or value of one or more entities. For the periods that the precondition fails (and optionally for a stated period thereafter), the test monitor item goes into a suppressed state.
Process
The process that is used by a test.
State Configuration
Exceeded limits, as defined in the process, raise various states. In this panel you can configure the possible state outcomes with a severity level, and you can override the standard state description. You can also add notes giving a reason for the state, the potential impact, and the recommended action to take.
If Case Management is enabled, this is where you can configure Sentinel to raise a case for a state, and whether to defer actions until the case is confirmed.
Auxiliary Data
The values of any auxiliary data defined in the test are saved with the event details. Auxiliary data is displayed in the Events History table, and also in the Associated Event Data in an email action. Auxiliary data can be displayed in the content of an email or SMS action, and it can be assigned to fields in a Case Form when a case is raised.
Actions
In this panel you assign various monitor actions to the test.
Source
This is where the test source data is defined, and where the sampling details are specified.
The most common source for a test is Explorer. The source may be an entity or a hierarchy. If it is an entity type, then you can look up various entities in the Data Dictionary, and add these as separate monitor items. These can be tags or general entities.
If you are using a hierarchy source type, then you will select a hierarchy from the Data Dictionary. The hierarchy will have a starting point, and you will be able to select which template to use.
When defining a source you need to specify the following:
Source
The most common source for a test is Explorer (also known as Server).
Type
There are three source types to choose from:
Entity: With an entity type, you are able to select individual entities to monitor.
Tag: With a tag type, you are able to select individual tags to monitor.
Hierarchy: With a hierarchy type you can monitor all the entities from a starting point from a hierarchy that exists in the Data Dictionary.
Note: There is an option to only include entities for which the selected template is set as the primary template.
Sample Methods for Data
A sample method must be defined for the input data. Separate sample methods can be defined for preconditions (where applicable), as well as for the process parameter data, and auxiliary data.
Sample Method: The sample method you choose to fetch the data. Choose from Raw, Average, Linear Interpolate, or Last Known Value. The default and the available sample methods depend on the process that is used.
Sample Interval: The regular interval between trigger periods to collect sample data. At every sample interval, the collected data is prepared according to the sample method used, and then evaluated in the process. You can specify the sample interval in seconds, minutes, hours, days, or weeks. The default sample interval is 30 seconds.
Delay
By setting this option, you cause a delay before the sample data is collected. This option is useful in cases such as when a historian is writing data at a similar time to when Sentinel is reading data.
Precondition
You can specify a precondition for a test. For each entity during the processing period, Sentinel will evaluate the precondition rules to determine the periods when the data will be processed. The precondition data may be an attribute of the source entity, either as it is, or as part of a calculation, or it may be the attribute of another entity. If the source type is Tag, the precondition data can be the source tag or a calculation using the source tag.
For the periods that the precondition fails, the test monitor item goes into a suppressed state. During the suppression periods, no data is processed.
The standard precondition is made up of a single condition, Condition 1, with two optional extra conditions, Condition 2 and Condition 3. In addition to the conditions that make up the precondition, you may set an Out of Suppression Delay. After a test monitor item emerges from the suppressed state caused by the precondition, it will enter a new suppressed state for the duration of the out of suppression delay.
Event State
The event state is the state that is reached to raise an event for a test. The event state is displayed in the event grid on an event page.
The various states in a particular test process can be assigned a severity.
During processing, an event is raised when the monitor item value exceeds defined limits, or when the monitor item moves to a particular, defined state. Every new event causes a state to be reached.
Each state, for a test, has a severity assigned to it; this is defined when the test is added to the monitor. The default severity for all states is None.
State Severity
The severity for a particular state outcome should be configured in accordance with what is being monitored.
For example, if a process has a High value that is exceeded during the test, then this raises a High Exceeded event. If this is considered to be a severe outcome for this particular test, then a severity of High should be assigned to the state.
However, if the High Exceeded state for this test is considered to be of a medium or low severity, then a Medium or Low severity configuration is more appropriate for this outcome.
The available severity levels are displayed as colours:
Grey
Blue
Yellow
Orange
Red
In the Sentinel charts, and in the event notification in the workspace, the colours used are based on the highest severity encountered in the grouping.
Note: There could be more than one event notification label, if you have cleared the option Combine severities into a single count in the Event Display Options.
Examples:
If the highest severity reached for all events for tests running under a workspace is of Medium severity, then the event notification label for the workspace is coloured in orange, the colour for Medium severity.
If the highest severity is Low, then the event notification label for the workspace is coloured in yellow, the colour for Low severity.
This is explained in the section on Viewing Events. The same principle applies to the colours shown in the asset reports.
State Override
There is also a State Override option, for each state outcome of a test. This can be used when a more specific description of the state is required. Where a state override is used, the standard label for a state is replaced by the state override text. The new label displays in all the reports.
The different states for a test outcome can be configured.
State Comments
State comments are all added when the test is set up, and can be included as tokens in email, SMS or web service actions, making it easier and quicker for notification recipients to understand possible causes and take remedial action.
Each state has three comment panels:
Reason for State: Used for stating the most likely reason for this state outcome, for the particular test.
Potential Impact: Used for outlining the potential impact of the test reaching this state.
Recommended Action: Used for elaborating on what actions to take following this state outcome.
If Case Management is enabled in Sentinel, there is a fourth comment panel:
Override Case Comment: This optional comment can be used to override the test’s Case Comment for a specific state.
Case Management
If Case Management is enabled in Sentinel, each state can be configured for case management.
Manage Case:
If this is selected, a case is raised for this state outcome of a test (this also depends on Sentinel’s configuration for cases and the test’s Case Options).
Note: If Aggregate Cases is enabled for the monitor’s category, and there are open cases for the category, then Sentinel will not raise this case; instead, a comment is added to the most recent open case of the category.
Defer Actions:
Any actions linked to this state are deferred until the related case is confirmed. A case is confirmed by a user in Explorer, in the case details. If the case is rejected, the actions do not happen at all.
Case Options
If Case Management is enabled in Sentinel, there is a Case Options panel for configuring how a case is managed for a test.
Case Title: A default title can be set up in the Sentinel Configuration file, and can be edited for a test. This is the title that Sentinel generates when a case is raised with an event, and appears in the case details in Explorer. The case title can contain tokens.
Case Description: A default description can be set up in the Sentinel Configuration file, and can be edited for a test. This is the description that Sentinel generates when a case is raised with an event, and appears in the case details in Explorer. The case description can contain tokens.
Case Comment: A default comment is set up in the Sentinel Configuration file, and can be edited for a test. The case comment can contain tokens.
Case Form: A case form is a Case Entry Form that has been configured and assigned a category in Explorer. The category of the monitor the test belongs to is used to filter the list of case forms able to be raised as a test state outcome when Manage Case is selected in the configuration.
Default Assigned User: Default user assigned to the case.
Only create new Cases if event state was previously severity of none: If this option is selected, cases are only raised if there has been a severity of None since the last case was raised for the test.
If the OnlyCreateCasesDefaultOption setting is set to True in the Sentinel configuration file, the check box is selected by default.
Automatically close Cases when Deferred Actions are complete: This relates to cases by state where the Defer Actions check box is selected. Deferred actions are carried out by the system as soon as a case is confirmed. With this option selected, the case is automatically closed after the actions are complete.
If the AutoCloseCasesAfterConfirmation setting is set to True in the Sentinel configuration file, the check box is selected by default.
Case Form Fields: These fields are additional fields that are specific to the selected Case Form. They can be assigned a token, auxiliary data, or a value.
Auxiliary Data
You can add auxiliary data to a Sentinel test. Auxiliary data is not monitored, but is saved with other event details when one of the test’s monitored assets raises an event. For example, your test may be monitoring pressure; if you have temperature selected as auxiliary data this is recorded when pressure raises an event.
Sentinel Tests
ON THIS PAGE:
A Sentinel test evaluates source data using a defined process, and raises events when the state changes. The states resulting from a test can trigger specified actions.
Every monitor has a collection of one or more tests. All tests run concurrently, as defined by the monitor trigger, and each test uses its own process.
The tests all belong to the same category, which is defined in the monitor.
A test may also have actions assigned to it. These are actions that are defined in the monitor, and may be assigned to any of the monitor tests.
You may also duplicate a Sentinel test, within the same monitor, giving the new test a unique name.
The following screen image shows a monitor with three separate tests:
The test details, as well as the process that each test uses, are listed in the Tests
panel of the monitor.
A test has the following components:
If Case Management is enabled, this is where you can configure Sentinel to raise a case for a state, and whether to defer actions until the case is confirmed.
Source
This is where the test source data is defined, and where the sampling details are specified.
The most common source for a test is Explorer. The source may be an entity or a hierarchy. If it is an entity type, then you can look up various entities in the Data Dictionary, and add these as separate monitor items. These can be tags or general entities.
If you are using a hierarchy source type, then you will select a hierarchy from the Data Dictionary. The hierarchy will have a starting point, and you will be able to select which template to use.
When defining a source you need to specify the following:
Note: There is an option to only include entities for which the selected template is set as the primary template.
Precondition
You can specify a precondition for a test. For each entity during the processing period, Sentinel will evaluate the precondition rules to determine the periods when the data will be processed. The precondition data may be an attribute of the source entity, either as it is, or as part of a calculation, or it may be the attribute of another entity. If the source type is Tag, the precondition data can be the source tag or a calculation using the source tag.
For the periods that the precondition fails, the test monitor item goes into a suppressed state. During the suppression periods, no data is processed.
The standard precondition is made up of a single condition, Condition 1, with two optional extra conditions, Condition 2 and Condition 3. In addition to the conditions that make up the precondition, you may set an Out of Suppression Delay. After a test monitor item emerges from the suppressed state caused by the precondition, it will enter a new suppressed state for the duration of the out of suppression delay.
Event State
The event state is the state that is reached to raise an event for a test. The event state is displayed in the event grid on an event page.
The various states in a particular test process can be assigned a severity.
During processing, an event is raised when the monitor item value exceeds defined limits, or when the monitor item moves to a particular, defined state. Every new event causes a state to be reached.
Each state, for a test, has a severity assigned to it; this is defined when the test is added to the monitor. The default severity for all states is None.
State Severity
The severity for a particular state outcome should be configured in accordance with what is being monitored.
For example, if a process has a High value that is exceeded during the test, then this raises a High Exceeded event. If this is considered to be a severe outcome for this particular test, then a severity of High should be assigned to the state.
However, if the High Exceeded state for this test is considered to be of a medium or low severity, then a Medium or Low severity configuration is more appropriate for this outcome.
The available severity levels are displayed as colours:
In the Sentinel charts, and in the event notification in the workspace, the colours used are based on the highest severity encountered in the grouping.
Note: There could be more than one event notification label, if you have cleared the option Combine severities into a single count in the Event Display Options.
Examples:
This is explained in the section on Viewing Events. The same principle applies to the colours shown in the asset reports.
State Override
There is also a State Override option, for each state outcome of a test. This can be used when a more specific description of the state is required. Where a state override is used, the standard label for a state is replaced by the state override text. The new label displays in all the reports.
The different states for a test outcome can be configured.
State Comments
State comments are all added when the test is set up, and can be included as tokens in email, SMS or web service actions, making it easier and quicker for notification recipients to understand possible causes and take remedial action.
Each state has three comment panels:
If Case Management is enabled in Sentinel, there is a fourth comment panel:
Case Management
If Case Management is enabled in Sentinel, each state can be configured for case management.
Manage Case:
If this is selected, a case is raised for this state outcome of a test (this also depends on Sentinel’s configuration for cases and the test’s Case Options).
Note: If Aggregate Cases is enabled for the monitor’s category, and there are open cases for the category, then Sentinel will not raise this case; instead, a comment is added to the most recent open case of the category.
Defer Actions:
Any actions linked to this state are deferred until the related case is confirmed. A case is confirmed by a user in Explorer, in the case details. If the case is rejected, the actions do not happen at all.
Case Options
If Case Management is enabled in Sentinel, there is a Case Options panel for configuring how a case is managed for a test.
Case Title: A default title can be set up in the Sentinel Configuration file, and can be edited for a test. This is the title that Sentinel generates when a case is raised with an event, and appears in the case details in Explorer. The case title can contain tokens.
Case Description: A default description can be set up in the Sentinel Configuration file, and can be edited for a test. This is the description that Sentinel generates when a case is raised with an event, and appears in the case details in Explorer. The case description can contain tokens.
Case Comment: A default comment is set up in the Sentinel Configuration file, and can be edited for a test. The case comment can contain tokens.
Case Form: A case form is a Case Entry Form that has been configured and assigned a category in Explorer. The category of the monitor the test belongs to is used to filter the list of case forms able to be raised as a test state outcome when Manage Case is selected in the configuration.
Default Assigned User: Default user assigned to the case.
Only create new Cases if event state was previously severity of none: If this option is selected, cases are only raised if there has been a severity of None since the last case was raised for the test.
If the OnlyCreateCasesDefaultOption setting is set to True in the Sentinel configuration file, the check box is selected by default.
Automatically close Cases when Deferred Actions are complete: This relates to cases by state where the Defer Actions check box is selected. Deferred actions are carried out by the system as soon as a case is confirmed. With this option selected, the case is automatically closed after the actions are complete.
If the AutoCloseCasesAfterConfirmation setting is set to True in the Sentinel configuration file, the check box is selected by default.
Case Form Fields: These fields are additional fields that are specific to the selected Case Form. They can be assigned a token, auxiliary data, or a value.
Auxiliary Data
You can add auxiliary data to a Sentinel test. Auxiliary data is not monitored, but is saved with other event details when one of the test’s monitored assets raises an event. For example, your test may be monitoring pressure; if you have temperature selected as auxiliary data this is recorded when pressure raises an event.