Alerts : logical diagram
Created: |
12/12/2005 5:28:27 PM |
Modified: |
7/26/2010 2:13:19 PM |
Project: |
|
Author: |
Administrator |
Version: |
1.0 |
Advanced: |
|
ID: |
{C37E6991-B4AB-4573-84C7-46D723A86F6F} |
A set of AlertRegions will be associated with a specific OutPort. The value associated with the AlertRegion set is the one contained in the DataEvent being output.<br /><br />When the value contained in a DataEvent activates an AlertRegion the DataEvent will contain a NumAlert associated to the AlertRegion along with the time of occurance stored in the lastTrigger. In a condition-based monitoring system, the following DataEvents from that OutPort will have new values and new times. However, the NumAlert will remain the same while in that region. This includes the lastTrigger time which may be used as an indicator of how long a particular region has been in effect.<br /><br />When a Region is first entered it gives the specific DataEvent an "Alert Status". For CBM modules supporting "Alert Status" <br />functionality, the output can be suppressed to output only when an alert trigger occurs. This mechanism requires one of <br />the connected type interfaces.<br /><br />(RegionId, OutPort handle) can be the identifier used by a higher module to control threshold levels via a user defined ControlVector. Future versions of the standard will begin to create a standard UML/XML form for this control.<br /><br />The simplest method of use is to have a single set of alertRegions for an output and a direct set of alert types for those regions. The system should be set up so that AlertTypes and AlertRegions are all unique to the system and within the system. Then only a single int is needed to identify a code, the RegionId and the AlertTypeCode respectively.<br /><br />The Alert classes are based on the MIMOSA OSA EAI CRIS. Substitute the term Alert for Alarm. The OSA-CBM version <br />has a few extra parameters like those for hysterisis and hiSideAlert indicator.<br /> <br />The main principles for optional arguments are:<br />For those terms that are primary keys in CRIS: if they are not used, then they should be elsewhere in the information schema, <br />i.e. if Site is not specified use the site found in DataEventSet. For those terms that are not primary keys, like name, they may <br />simply be expected to be found in a database. In short, assume that they are not needed for an operational monitoring system and would only make the system less efficient.