Logging Alarm Activations, deactivations, and Acknowledgments

[Davidd]

Lookout 5.1

I have a need to be able to execute an event on alarm events when they become active, inactive, and are acknowledged.  Management wants an up to date record of when an alarm comes in, how long that alarm is on, how long it takes operations personnel to respond to the alarm, etc...  I see that I can use the $Alarm block to produce a list of when the alarm is activated, but don't see any method of allowing me to capture when that alarm goes inactive, or when the alarm is acknowledged.

Does such a capability exist, or is management stuck yet again?

David

[Doug M]

David,
I am not aware of a way to generate an event when an alarm is acknowledged, but there are several ways you can get this information.  First of all, all of this information is logged to the Citadel database for every alarm -- when the alarm first occurred, when it was acknowledged, and when it was deactivated, and this is easily accessible in MAX by creating an Alarms and Events View.  You can export this data to an html report or a .csv file and then do further manipulation with time stamps etc to get the amount of time it takes to acknowledge or deactivate alarms and do other types of statistical analysis.

From within Lookout, you could have a push button that would acknowledge an alarm and also create an event that you would log.  For deactivation you could set up expressions that monitor the value of a datamember to learn a when value changes out of alarm state.  These ideas seem a little hackish to me and I think exporting the data from MAX to a spreadsheet is the best way to extract this type of information.

[Davidd]

Is this information available through the SQL interface (weak as it is)?

Management is looking for a real-time (or close to) display showing what alarms are active, how long they have been active, what alarms went inactive before being acknowledged, how long it's been since the alarm occurred/became inactive, etc....

In the future, they plan on providing the plant personnel pagers and have them paged when an alarm hasn't been taken care of soon enough.  I don't see any way to do this in the current version of Lookout, told them so, but they want me to pursue it anyway.

David

[Doug M]

David,
There is not an easy way to access the alarm database.  Alarms are stored in the MSDE database, and you are free to try to access this database via OBDC (in a 3rd party environment or from Lookout) but the tables aren't published and it is not a supported method of accessing alarm information.  Oh, you are using Lookout 5.1 which stores alarms in the Citadel db.  In any case, you could try using OBDC to import alarms into a datatable.  This may be easier than in Lookout 6.0 but I don't know the structure of the tables -- you'd be on your own there.  Here are a few other ideas:

Have you used the ActiveX AlarmBrowser object? This embeds the same Alarm Browser you use in MAX right into your Lookout Panel.  This gives you all the information you are asking for (timestamp for when the alarm occured, when it was acknowledged, when it became inactive) and color codes the four alarm states: active unacknowleged, active acknowledged, inactive acknowledged, and inactive unacknowledged.  Now, it just presents the timestamps, not a running amount of time the alarms have been active, etc, and you can't really do anything besides acknowledge the alarms from it, but it does present the information you are referring to.

If you actually want to programmatically do things with alarms, you can use either the $alarm object built into every process, or create your own Alarm objects.  Alarm objects have an 'active' datamember that you could work with to create different types of timers with.  As far as knowing when individual alarms are acknowledged programmatically, the only thing I can think of would be to create a separate alarm area for each alarm, then you can use the $alarm object and check which alarms are active and/or acknowledged. With some creative uses of timer objects, the $alarm object, and expressions, you may be able to do what you are thinking about.  Hope this helps!

Message Edited by Doug M on 12-20-2005 03:44 PM

[Davidd]

Think I'll just take the "politically correct" path, and tell management "Its not supported".  If they want such a thing, its time to switch to a SCADA package that can do it.  I've got way too many alarms (over 4 or 5 thousand individual alarms) to be managing a bunch of Alarm blocks, or coming up with some other "unsupportable" archetecture.  I could probably manage to do such a thing for a few alarms, but not that many.

David

[Davidd]

Before I give up on this, let me ask one question.

Are the fields in the I/O devices event driven, or do they continuously report data with no regard to it changing?

What I mean is for instance, we use the Modbus driver here extensively.

If I define an I/O tag is the driver, and the driver polls the device itself every 10 seconds, does that I/O tag receive a new data value every 10 seconds, or only when the data changes?  If possible, I think I'd like to come up with some way of directly updating my current historical SQL database by adding a process variable table.  If I could somehow come up with a method of updating that table when the PLC value changes, I would be able to implement my own alarm system on the SQL server.  We don't use Citadel anymore for historical data storage, as we couldn't ever get the thing to run reliably for over a few days without crashing Lookout.  Without the Citadel server running, the Lookout system will run a month or so, and normally I just routinely reboot the thing on the first of the month.

I could probably talk management into me handling the alarm generation logic 'outside' of Lookout if I can move the alarms out of Lookout.  If I spin that right, I might be able to make everyone happy.

David

[Doug M]

The hardware drivers are poll-driven -- the datamembers are updated according to the poll rate you specify.  Other expression and objects are event driven -- when one of the variables in the expression changes the expression is re-evaluated.

Yeah, if your setup works, you probably don't want to change it, but Citadel 5 (Lookout 6.0) is much more robust and stable than previous versions.  Like I mentioned, in Citadel 5 all alarms and events are stored to a Microsoft SQL database (MSDE), while trace data is stored to the Citadel database.

Message Edited by Doug M on 12-20-2005 05:46 PM

[Davidd]

After all the fighting and troubles we've had with 5.0, and 5.1, and 2 years to get it stable enough to run the plant for even a short while, I think management would throw more of a fit (and probably throw me out too), if I even suggested that the "solution" to our problem was to update to a new version of a software package with an already troubled history.

It may be the greatest thing in the world, but it'd be a mistake for me to even suggest that.

Can Lookout 5.1 be upgraded into Citadel 5?  I understand that it is only for Lookout 6.  Is a upgrade easy, or does it require a 'conversion effort'?  Please understand that we have developed our own internal methods of creating the graphics (which is essentially all we use Lookout for, anyway - operator interface and alarms - everything else is handled externally).  Most of the actual programming we do now has actually been converted into doing direct '.lks' source itself.  We (well... me) have generated software programs and databases that allow the direct production of the .lks file, without using the GUI editor - which when you're dealing with a system the size of this - the GUI is about the SLOWEST way to create a control strategy I've ever come across.  Thats why I think I may be able to implement alarms the way I said - all I think I'd have to do is to create a process that handles one, and then duplicate it as much as I need to, for all the values I need - and I can just tag those in the database.

Ashamed that you don't publish anything on the .lks format itself.  The parts I've managed to decode (which is only a small part of the total) have proven to be immensely useful, and although the compiler isn't exactly forgiving - once you get it right (and software makes that easier to manage), you can really do some amazing things with it.

David Dudley

[Doug M]

David,
Lookout 5.1 cannot be upgraded to use Citadel 5.  There is a process to convert Citadel 4 databases to Citadel 5 databases, but it is fairly straightforward.  Many hardware driver objects have an 'update' datamember that goes TRUE when they poll the hardware -- this could possibly be of use if you want to log to your own database.  I am not sure why the lks file format has nothing published on it -- my guess is that because self modifying it is not something that is "officially supported" there is no public documentation for it.  If I find anything out otherwise I will post it.