The Requirement Specification should identify the operational requirements for Alarm management

The following are suggestions

Alarm limits and priorities should not be pissible for an operator to change.

operators shoulld be able to Disabling alarms

A list of disabled alarms should be automatically generated by the system

Operators should have a tool to configure alerts for themselves. E.g. an operator is emptying a tank and wants a warning when it is almost empty. This tool allows us to let alarms be alarms being “timely notification that operator action is required” or maybe even “interlocks involving manual action”.

6. All changes should be logged and the system should be scanned regularly for unauthorized changes (e.g. by comparing the database with a previous version).

The list of shelved alarms should in deed be reviewed as part of the shift handover. I guess most of the systems provide an automatic "un-shelving" optin, e.g. the shelved alarm is re-activated after a configurable period of time. Of course his can be bypassed as well by just re-schelving it agin, and again, and again. So in addition to the review of the shelved alarms by the new shift, there also should be some statistical analysis by the maintenance team, process engineer, shift supervisor or simular

Note - some of this has been derived from a long dialog on the LinkedIn  Automation & Control Engineering forum

This web is  funded by advertising, but the advertisers have no influence on the web site. Please visit them.

 

Enter your search terms

Submit search form