Here is one problem customers are encountering with our alarming philosophy, where we replace the existing alarm with a new one with the current alarm state: Because the alarm for exceeding hi-hi isn’t latched, operators are missing that MAOP was exceeded – which has regulatory considerations.
What do the regulations require to happen? What are the personas involved? What does the operator have to do? Just report that it happened? flag the event so that someone later can prepare the report? How often is the report needed? What is the final outcome/actions taken from the report?
i.e. is this in the control room or outside the control room? Can this be dealt with via alarm analytics?
Xcel and PG&E are two customers that have solved this problem with the use of user alarm limits:
integrate user-hi/user-lo into the hilo structure,
-
then we renamed all states and introduced 6 limits instead of 4.
renamed user alarms to hi-hi, and then used the hi-hi for MAOP.
If you want these latched you can leave them outside of the hilo structure and you will have separate persistent alarms reported for user alarms (or now MAPP limits)
In case it goes in and out of the user-hi state, you may have separate RTN alarm along with the Hi alarm
For the use case when the value goes normal->MAOP->Hi – you may end up with the point in the Hi state, and there being two flashing alarms – one RTN from MAOP and one for RTN from Hi.
It might be worth considering a new MAOP (or Max-HI) alarm type that can then contain its own logic and configuration. That way, we can configure it to be latched, and can never be supressed etc etc.
[Collin Heggerud] We might even want to consider going further than this. GRTgaz has seven levels of alarming on their existing system and they will come to us for the same in the new backend system. I don’t know what they all are, but imagine MAOP, then hi and hi-hi for measurement effectiveness (e.g. with a 1” orifice the meter’s measurement effectiveness is within a certain range), then hi and hi-hi for operational safety (presumably somewhat less than MAOP), and an operator temporary limit.
One thought I’ve had is that we change the text to indicate the worst state achieved. For instance, your RTN alarm might be:
Return to Normal (375.0 psi – worst unacked condition ‘hi-hi’ @ 549.0 psi)
2022-05-04 Notes from AGA Spring 2022
Customers must report on MAOP alarms, which are not the same as HIHI alarms. You can run the pipeline in a HIHI state without any regulatory impact. But as soon as you exceed MAOP there are several things that must happen, both immediately (operator must follow a procedure and make log entries etc) and long term (reporting and followup).
Using user-alarms for this is a workaround, but we should evolve are alarming to match the industry regulations.
