Alert profiles

[aorange]

We are looking at creating an interface between WinCC-OA and an event recognition system to detect water leaks, pipe bursts, etc. and I am looking for information on how we can implement alert profiles.

I need to be able to change the limits of an alert during runtime at 15 minute intervals, now I know that this can be achieved using CTRL scripts but I need to be able to scale the system up to 10000 dataloggers providing us with approximately 20000 discrete readings... also, to use CTRL scripts to change alert limits the _alert_hdl of each DPE needs to be inactivated first which could potentially lead to missed alerts?

If I am not mistaking, I remember reading that alert profiles were supported in PVSS 3.8 & 3.9 from the ITT of a previous project. Would anyone be able to point me in the right direction?

I will forward this request directly to ETM support as well but thought that other users could benefit from the answer and hence I am posting it here as well.

Many thanks in advance

[mweber]

Hello Jonathan,

afaik there is no standard feature in 3.8 or following that copes with your demands of changing the alert limits during runtime without deactivating the alert.

When you want to change the alert ranges with scripts you have to do the same as the powerconfig is doing.
Acknowledge the alert, switch it off, change the setting, switch it back on.

Please note that if there is an alert pending at the moment of changing the limits, you will get a new alert instance created with a new timestamp.

1.) optinal you could read the current values first before changing (it depends to you alert handler how many ranges you want to modify)

dpGet($DPE+":_alert_hdl.1._u_limit",minAlert,
$DPE+":_alert_hdl.2._u_limit",maxAlert,
$DPE+":_alert_hdl.._active",alertActive);

2.) to change the limits do the following (again note that the detail reflects the different alert ranges:

dpSetTimedWait(0, $DPE+":_alert_hdl.._ack", 2); // acknowledge
dpSetTimedWait(0, $DPE+":_alert_hdl.._active", 0); // deativate alert
dpSetTimedWait(0, $DPE+":_alert_hdl.._ack", 2); // acknowledge again - just in case
dpSetTimedWait(0, $DPE+":_alert_hdl.1._u_limit",minAlert,
$DPE+":_alert_hdl.2._l_limit",minAlert,
$DPE+":_alert_hdl.2._u_limit",maxAlert,
$DPE+":_alert_hdl.3._l_limit",maxAlert); // set the desired values for the limits - please note, that the upper limit of the range n should be equal to the lower limit of the range n+1
err = getLastError(); if (dynlen(err) > 0){ throwError(err);}
dpSetTimedWait(0, $DPE+":_alert_hdl.._active", alertActive); // activate the alert again (or leave it switched off...)


If you do a change of those parameters very often (every 15min) it will lead to an overflow of the parameter history of the RAIMA database (sooner or later) because it is limited in size (16 million entries, or something like that)
To overcome that, there is following workaround:
using dpSetTimedWait with the "0" time (null time of the database) the change of this parameter will not be entered in the parameter history of the RAIMA (this workaround is only done for the alert handler config)


--- other implementation ---
If you want to change the limits without de- / activating the alert handler you could maybe consider a implementation like this:
I assume that there is an analoge value with 3 ranges to the alert handler (warning and alarm)
then instead of doing an alert handler directly on the floeat dpe you could define two boolean dpes (one for warning and one for the alert each with an alert handler)
on that new dpes you could have a dp function that is setting the element if some condition is violated (one line of script).
now you could change the dpfct config during runtime without even touching the alert handler.

drawback:
-) additional dpes with additional configs (will add to the memory footprint of the project)
-) a lot of datapoint functions - be aware that the dp function is a script worked inside the event (thus slowing it down!)

(of course you could also have a control script that is doing that instead of the datapoint functions - would be recommended in bigger projects - but one change every 15min should not be too much workload)



best regards

Markus

[aorange]

Hi Markus,

Thanks a lot for your reply, it seems we have a number of options to achieve this... another alternative that I came across whilst searching the help file would be to use the OPC-UA driver and generate the alerts elsewhere.

The event-recognition tool that we are looking at is already capable of generating alerts based on some very clever computations (using Bayesian logic and neural networks to determine probability), I am thinking that we might be able to transfer both the alert status and the probability that the event is a true abnormal situation to WinCC-OA using one or two extra DPE's for each discrete value. It has the same drawback of what you suggested however in that it will increase the memory footprint of the project but at least it shouldn't load up the event manager too much.

We will be doing some scalability tests in the coming weeks to assess which option is the most suitable and may require further advice to make sure that we get it right... 3 extra DPE's for each discrete signal on a system with 20000 floats quickly adds another 60000 DPE's to the system (and potentially I/O's).

Thanks again

[Gertjan van Schijndel]

Since 3.10 it is possible to use multi-instance alerts, which use be useful for this purpose.

On a multi-instance alert you can create multiple alerts with their own alert class, priority, value and alert text. The event-recognition tool will need to set these values at the additional values.

[mweber]

Hello Jonathan,

as I understand from your previous post there is an external program that does a whole lot of things and the only thing left now is to bring this alert events to WinCC OA.
For that it would really be best to use the multi instance alerts. You will only need one (ore some) dpes that work as a gateway for your alarm messages created by the external program.

You could write an API manager that is interfacing with this third party application and then writing to the dpe with the multi instance alert.
(as an example our BAC net driver is using the exact same feature, or also the S7 driver when interfacing with AlarmS or AlarmP function blocks)
In this case you will spare all of the dpes that, for normal, would hold an individual alert handler, instead you use only one template and all information like priority or text and so on will be set by the API.

You will find additional information about multi instance alerts in the online help - if you need more info feel free to contact me.


best regards

Markus

[aorange]

I will look closer at using multi instance alerts... thanks for the advice

[aorange]

Right.. things have moved on a bit and we have done some really interesting work recently. We decided as an interim solution to calculate the predicted good range for each of our flow and pressure readings at 15 minute intervals in PVSS and we are currently displaying these on a trend (see picture). We anticipate that this approach will allows us to detect leaks and bursts in our network much earlier as we give consideration to diurnal patterns. e.g. nightly flows are invariably lower compared to daily flows, the high alarm limit for a night flow could therefore safely be much lower than that of the daily equivalent.

Presently we are using fixed ranges to alarm on these signals (depicted by the curve marking on the trend) but we would like to use the diurnal pattern instead to detect if a signal is operating in its "good" range. So I have two questions;

- Is it possible to have different alarm limits for a discrete signal depending on the time of the day?
- Is it possible to pass two dyn_floats to the Trend widget to display a "dynamic" curveMarking?

[Gertjan van Schijndel]

It is possible to have different alarm limits depending on state bits for discrete values.
A driver plugin or control script can (re)set the userbit to indicate the time of day.

[aorange]

Thanks Gertjan, I am having a look at the alert handling of discrete values but I am not 100% sure it could satisfy our requirements; the behaviour that we are after would essentially move the 'good' range depending on the time of the day.

Time__________Min__Max
00:00 - 00:15____1.0__3.0
00:00 - 00:30____1.1__3.1
00:00 - 00:45____1.2__3.2
00:00 - 01:00____1.2__3.2
00:00 - 01:15____1.3__3.3
00:00 - 01:30____1.3__3.4
00:00 - 01:45____1.2__3.2
00:00 - 02:00____1.2__3.2
... and so on...

As long as the original value remains within that moving threshold, then the value is considered healthy. It is pretty much like the 3-ranges alert handling of continuous values with the difference that we want the thresholds to move.