This chart illustrates the operation of an event-driven exception handler used for exception identification, management, alarming, adjustment and reporting.

Legend

  Solid lines denote run-time operation
  Dotted lines denote design-time operation

Exception are detected based on operational protocols, defined by the admin station, and by analysis of the events received from the state control.

The handler includes modules for supporting common operational activities of troubleshooting, alarming and reporting about the need for design changes. An exception handler may consist of five processes:

• An exception control unit, which is part of the admin station, is used to adjust the alarm thresholds, in order to improve the Signal/Nuisance ration, and to fake measurements for testing.
• A state control unit is used to continuously compress the measurements received from sensors, and convert them to states, based on scenario information. The compression is based on thresholds defined by the exception control, operated by the exception designer  .
• An exception detector, triggered by scenario changes, checks the scenario compliance with the operational protocols. A hazard is detected if the scenario does not comply with any of the protocols included in the design scope.
• A threat recognizer, used to provide an estimate of the risks, to guide the operators with the troubleshooting and to set the proper operation mode (automation in safe mode).
• An alarm control unit used to generate alarms for the operators about new threats. The operator's response to the alarm is used compute alarm scores. The alarm scores are used as input for the exception control, to modify the alarm thresholds.
• A reporter used to generate reports for the exception designers about the detected threats. Based on the reports, the exception designers may recommend to change the protocols or the add-ons ( sensors and thresholds).

Updated on 18 Jun 2017.