Persistence out of Alarm on SCADAPack point

[rlao]

I'm trying out the persistence out of alarm feature to help reduce alarm flooding from noisy signals.

For a digital point, if you have SeverityType of the alarmed state set to 'Alarm', is it required to have the SeverityType of the healthy state set to 'Event' in order to generate an unsolicited event for the signal returning to healthy state? Or is that a superfluous setting?

 I am finding having the healthy state as an event is interfering with the persistence out of alarm delay as it is causing the RTU to generate an event instantly on state change regardless of the delay timing.

I think even with SeverityType of the healthy state set to 'None', it should still be able to generate an event on exiting the alarm state. But with the added benefit that it will follow the Persistence out of Alarm delay. Is that correct?

[BevanWeiss · Accepted solution]

I think you might be confusing two things.

The SeverityType of Event means NOTHING in regards to an RTU, it does not mean generate an RTU unsolicited event, nor any such RTU related thing.  It is a Master station item ONLY.

You should NOT need to have any SeverityType configured on the state in which it would be leaving the alarm for the persistence setting to apply.  Once GeoSCADA Expert has received the updated state value from the driver process (indicating that the point value is no longer in an alarm state) then it would only remove the alarm condition when the persistence out of alarm time has expired.

You would ideally have the RTU generate an event for both the alarm condition, and the non-alarm condition transition.  This ensures that GeoSCADA would eventually have the appropriate timestamp value of both the into alarm state time, and the out of alarm state time (the point value, not the alarm value).

However as you say, if it's truly a noisy point then you wouldn't want excessive events reported (especially if they are configured for unsolicited).

In conclusion:

These particular settings (SeverityType, Persistence into / out of alarm here) do NOT influence RTU behaviour.

You do NOT need to configure the non-alarm state with a particular SeverityType for the persistence function to work.

The setting you want for generating events in the RTU relates to what Class you have assigned this point, and another tick box further down on this tab I believe called 'RTU Events'

[rlao]

Hey Bevan,

Sorry for the delay in follow up on this and thanks heaps for the clarifications.

Basically, SeverityType was pretty much a red herring in terms of managing alarm noise but it's good to have the healthy state generate an event anyway for accurate timestamping. But it wasn't the source of my issues - I had a closer look at the event logs during time of my testing and I think my problem was actually excessive polling of the RTU. This makes sense as Persistence settings don't affect polling for current data. With this in mind, I tested this persistence setting on a few other digital points and it works as I would expect. 

I encountered a different issue testing out alarm persistence on analog points which is noisy overrange and underrange alarms from instrumentation issues. The help files state that 'Persistence out of Alarm' does not work for overrange/underrange alarms by design. However, having an off-delay on range alarms would be very helpful to stem alarm floods, so what are some options that I can look into for those?

[BevanWeiss]

but it's good to have the healthy state generate an event anyway for accurate timestamping

You don't need to have the Healthy state configured to have an Event SeverityType to have this happen.  It kind of happens naturally since the other state (the not good one) has an Alarm SeverityType (which creates events on Into and Out of).

My personal preference is to really try to create as few CDBEventJournal entries as possible.  So make sure that each one that you generate is important.  It adds quite a lots of data (768bytes per record) to the disk writes.

Someone will say 768 bytes isn't much.  But that is 24x more than if it were just a Historic Entry (32 bytes).

My concept is, if it won't have a users name associated with it at some point, then it doesn't need an Event entry.

So that means that actions like Setpoint/Control changes, yep they get an Event (but this happens naturally from the Control aggregate).  And alarms should be acknowledged by an operator (or not acknowledged when an operator SHOULD have been able to acknowledge them) so that gets an Event (by having an Alarm SeverityType).

Things like a Pump going from Stopped->Running, or Running->Stopped... it's not deserving of a CDBEventJournal entry.  It should get a Historic Entry, which is more than enough for most things (determining what state it's in at a given time, identifying when it changed state, how long it's been in a state, how often it changed state, etc etc).

So... what does an Event Journal entry add?  I would argue nothing.. just a waste of disk space.

Overrange / Underrange is often a problem.  The most common hacky solution I see is for the Underrange / Overrange to be set wider than the real instrument.  i.e. if you have a 0-100 % gauge.. then the underrange is set to -1 %, and the Overrange to 101 %.  It looks horrible in the configuration though... but it's a 'solution'.  Best only used with floating point values however, which aren't scaled.  Since otherwise you need to make similar adjustments to the Raw Min/Max values, which then look very confusing.

There is another potential option.  And this applies with DNP3 objects.  On the Property Pane for them, there is a setting for 'Out of Range Check', you could change this from 'Both' to 'Outstation Only', in which case the Master (GeoSCADA Expert) will no longer perform its own Out of Range checks, and will instead trust the Outstation to perform this and reflect it in the DNP3 quality flags.  It might be a good / bad option.

a. I'm unsure exactly how often this particular feature is used, so you might end up finding bugs.

b. There are many situations when the RTU won't have particularly useful Underrange / Overrange flags.  On analog input points direct from IO this would typically be quite good (at least for a SCADAPack RTU).  But once you're dealing with other derived type of points... I think the Raw/EU settings tend to not be configured quite right... and it just works because a g30v5 value is passed straight through GeoSCADA to be shown to the user..