Persistence on SCADA Point State Alarms on Analogs

[rlao]

So this has been an issue I'm trying to tackle for a good part of the year, and one I've tried a few solutions for but ultimately none of which I've been completely satisfied with yet. So I'm asking for some guidance from those of you more experienced than I am.

Basically I'm looking to implement persistence on point state alarms from analog points. For example, if I have a well level reported by a SCADAPack (ranged 0-100%) and it has an alarm on the '1 Low' state of say 30% with an Enabled Unsolicited RTU event. I want to be able to set a persistence time on it for say 5 minutes. This means if the well level goes from 33% to 28% and does not rise back up past 30% within the next 5 minutes, I want ClearSCADA to raise an alarm. However, if the well level goes from 33%->28%->32% within the span of say 2 minutes, I don't want ClearSCADA to raise an alarm on that point at all.

Some solutions I have explored:

Setting Persistence Into Alarm

My understanding is this delays the RTU from generating an event for the point state change from 'Normal' to '1 Low' and if the point returns to the normal state within the persistence delay, it does not even generate the point state change event at all.

My experience with this is that it seems to work great for binary points (after getting some forum help) but not so much for analog points. The reason is the change in analog value that triggers the alarm is usually large enough to surpass the event deviation. So the RTU will generate an unsolicited event regardless, not for the actual state change but for the value change. ClearSCADA processes this value change event and updates the point value, immediately raising an alarm despite the delay on 'Persistence Into Alarm'.

I've abandoned this approach for now but if there is a way to make it work, I'm all ears.

Implement persistence as RTU code and the actual alarm as a separate binary point

Probably the most robust solution, however I am concerned about the increase in point count as this would mean every analog point will need to be accompanied by one or multiple digital points to store each alarm. If it is to be integrated in a SCADA template, it would mean a lot of extra digital points that need to be created for each possible alarm that could appear on the analog.

Using 'pending severities' and alarm redirection

This is currently where I'm at. I've made some dummy 'pending alarm' severities and used alarm redirection to escalate them (after a delay) to actual alarm severities that the operators can visibly see and act upon.

The main issue with this is the pending alarm needs to be somehow acknowledged if it doesn't get escalated into an actual alarm, otherwise the point will just stay in an unack-cleared state. The only way I can see to fix this is to write some logic that's called via redirection on alarm clear to auto-acknowledge that pending alarm.

However, my roadblock here is that there does not appear to be an easy way to selectively acknowledge alarms on a CAlarmObject. So if I call the Accept() method via logic, it will acknowledge every alarm on that point rather than only the pending alarm. I think setting a dedicated alarm condition for the pending alarm might be the way to fix this?

However I just want to check if this whole approach is really recommended for what I'm trying to achieve here before I put more effort into refining it.

[Hardin4019]

I think you are on the right path with using a Redirection.

A few thoughts. 

"The main issue with this is the pending alarm needs to be somehow acknowledged if it doesn't get escalated into an actual alarm, otherwise the point will just stay in an unack-cleared state. The only way I can see to fix this is to write some logic that's called via redirection on alarm clear to auto-acknowledge that pending alarm."

For Trigger State, are you using "Uncleared - Unacknowledged" ? You could try using just "Uncleared" with an Abort State of "Cleared".

"However, my roadblock here is that there does not appear to be an easy way to selectively acknowledge alarms on a CAlarmObject. So if I call the Accept() method via logic, it will acknowledge every alarm on that point rather than only the pending alarm. I think setting a dedicated alarm condition for the pending alarm might be the way to fix this?"

It is possible to make a redirection that Acknowledges an alarm condition using a "Alarm Redirection Method Action" and passing along the %ASource% or %OFullName%. Example: Execute( '%ASource%', '%ACondName%', '%ASeverity%') . I use %ASeverity% in mine to make sure that my Redirections can only Acknowledge one particular severity of "pre-alarm" that my operators cannot see.

[BevanWeiss · Accepted solution]

@rlao The way that I normally implement this is using separate RTU/PLC logic for the Analog inputs, since often there is additional logic that applies anyway (e.g. a low flow alarm should only be generated when a pump is running, likewise with a low current alarm etc etc).

If it's possible that such an alarm will perform a site control action also (e.g. Low Low Flow will likely result in the pump being considered faulted after some time, High High Level will likely be an interlock against pumping into the tank etc etc), then you would need to have such alarm generation within the RTU/PLC anyway.

I'm with you in regards to the point count increase unfortunately, and I do often generate alarms purely in the SCADA (I really like Time Profiles configured against Alarm Limits for certain 'derived alarms'... like for excessive/insufficient pump runs).  But for standard High / Low alarms where I'm relatively certain that a time delay will be needed then I do this entirely within the RTU and disable the alarms on the Analog Point itself.

It does take the point count from 1 (Analog value) -> lots (Analog value, Transmitter fault, Low Alarm, Low SP, Low Delay SP, Low Low Alarm, Low Low SP, Low Low Delay SP, High Alarm, High SP, High Delay SP, High High Alarm, High High SP, High High Delay SP).. but there's not much that can be done about that.  Having a collection of templates for each 'type' can be helpful to keep the point count a little lower... e.g. often things like Turbidity won't need Low / Low Low alarms, so they can be removed.  Often times there won't be a need for High High / Low Low, and just High / Low will suffice..

Using alarm severities for delaying alarms in this manner is likely going to be incredibly difficult to maintain.

Even things like Animations will be tougher, since you won't just be able to look at AlarmState to see if an alarm is active, since it will be, so you'll always need to look at the AlarmSeverity also.

And doing audits on Alarm Severities will be even harder than it currently is, since not only will you need to look at all the different possible Alarm Severity fields on the different objects, but you'll need to look at the alarm redirections, since the as configured severities would only be placeholders for the real severity.

I believe an upcoming version of GeoSCADA was going to have some additional settings around delaying alarms.  But I'm unsure how this will be implemented, and I suspect it will be driver dependent also... which might introduce additional weird behaviour like for the SCADAPack points (where doing a Class 0 integrity poll renders any delayed reporting of 'alarm state' moot).

[du5tin]

If you are looking for votes on the solution to use I suggest the RTU logic method... will be the most robust and doesn't rely on data getting to or not getting to ClearSCADA. 

I have done the pending alarm severity method before and it isn't great.... To "auto-ack" the alarms you can create a Method object, set it to acknowledge the alarm on the point. Then attach a delayed redirection on the point that will run the method if the alarm isn't escalated after some time. e.g. Auto redirect to accept method object if severity = pending, delay for 15M, only act on Unack'd, Uncleared. It is a bit klugey though and may not be very robust. 

[BevanWeiss]

@du5tin Do you run into issues with the point license aspect?

I often see it being a problem, since it really multiplies the point numbers quickly.

i.e. for 20 analog inputs you end up with 280 licensed points... 20x(Value, Tx Fault, High High SP, High High Delay SP, High High Alarm, High SP, High Delay SP, High Alarm, Low SP, Low Delay SP, Low Alarm, Low Low SP, Low Low Delay SP, Low Low Alarm).

The Pending Alarm Severity system is pretty terrible though.

Once an alarm is raised in Geo SCADA, I think it's handling of it is pretty good, the alarm raise conditioning needs a little work however (and I think alarm persistence, to mask out rapid spurious alarms, is already upcoming).

I also think that a realignment of certain terminology (and perhaps tweaks to behaviour) might be warranted.

e.g. alarm Disable likely warrants a renaming (or aliasing) to include the term 'shelf'/'shelve' to better align with the ISA-18.2 requirements.  And some counterpoint for the Remove Alarms function.  Like if I accidentally 'remove' the wrong alarm... how do I undo that action?

They probably also want to contact the process type people.. like exida, and start getting some more visibility into the Process Industry... I note GeoSCADA Expert isn't referenced here... it could have been good 'advertising'

https://www.exida.com/ebooks/alarm-shelving-exida-ebook.pdf

[du5tin]

We absolutely hit that limit all the time. Clients that do this type of setup are into the 10,000+ point license count on a regular basis for even small systems. 

We recently did a project that worked with Allen Bradley Plant PAX and the point list is exactly what you describe. A single analog in the PLC could be over a hundred points in Geo SCADA if we brought over everything. We got our template dialed in to under 30 points. Different mentality designed for a different platform and different data transfer. The alarming is a pain though. You cannot alarm on the analog process variable anymore inside ClearSCADA. You have to use the PLC derived alarms only otherwise it causes operator confusion. 

In this case, because the alarm action is so specific and it sounds like persistence isn't doing the trick using on site logic might be a good route.  

[BevanWeiss]

10k points license... you're living the dream.  I'm doing a project with a 5k point license right now... I have a sphincter tightening experience everytime I add a single point that it might be the straw that breaks the camel's back...

Things like... 'ohh we want the monthly runtime and starts for each pump' (and we want low / high alarms on them).. just two points... but then across like 60 pumps... they're big multiples when you're only a few hundred points from your license limit.