SOE Filtering Speed for Specific Alarms (Citect 2018 R2)

Hi Community,

We were planning on using the SOEEventAdd() function to provide the plant operators with a method of attaching a 'note' (ie. a simple string) to a selected piece of equipment, and have this viewable/editable on a faceplate when that piece of equipment is selected.  Using the SOE (alarm summary) would also provide for a history of attached notes and the inbuilt archiving functionality of the standard alarm database.

Unfortunately, whilst the above functionality all works, the time it takes to filter for a specific alarm tag is a cause for concern, and may lead to the functionality being scrapped.  Our current calculations show that filtering on a specific alarm tag (see below) will only process summary events at the rate of about 25,000 records per second.  If our (small) plant generates 5 summary events per minute, then it will have generated over 100,000 events in 2 weeks.  Using such a filter will take 4sec to return any data.  Longer periods appear to scale linearly (eg. 4 weeks of events takes 8 sec to filter).

iHndl = AlarmFilterEditOpen(hAn);

IF iHndl <> BAD_HANDLE THEN

AlarmFilterEditSet(iHndl, "TAG=" + sEquipment + "_Note");

AlarmFilterEditCommit(iHndl);

AlarmFilterEditClose(iHndl);

END

The above code is very much derived from the SA_Include\InfoAlarm.ci function called InfoAlarm_EquipmentFilterTask, with the exception that this is a Summary Alarm list (type 15).

My question (after this exceptionally long preamble) is, are there any optimized methods of extracting lists of specific SOE events from the alarm summary?

 

Some other things I've tried (and have just resulted in very slow alarm list display; category and priority 73 were specific to the operator notes):

   // AlarmFilterEditSet(iHndl, "CATEGORY=73");
   // AlarmFilterEditAppend(iHndl, ";EQUIPMENT=" + sEquipment);

   // AlarmFilterEditSet(iHndl, "PRIORITY=73");
   // AlarmFilterEditAppend(iHndl, ";EQUIPMENT=" + sEquipment);

   // AlarmFilterEditSet(iHndl, "EQUIPMENT=" + sEquipment);
   // AlarmFilterEditAppend(iHndl, ";TAG=" + sEquipment + "_NoteLog");

The only thing that really works is a hard date/time limit, but that sort of defeats the purpose of the whole thing.

   AlarmFilterEditSet(iHndl, "TAG=" + sEquipment + "_NoteLog");
   AlarmFilterEditAppend(iHndl, ";DATE>=" + IntToStr(TimeCurrent()-14*86400));

 

Parents
  • Hi Steve,

    You cannot really force the operator notes into a separate stream. This is based on the underlying unique object Id generated at object creation. Only sort of way to achieve this is to add them "later" (so compile - start - run once without the alarm notes and then add them, so they get appended after blocking them all together). Based on your remark JnI00104-JnI00112 this is hat sort of happened anyway.

    When you say query takes 17 sec, I reckon this is measuring using the AlarmDsp or AlarmListCreate functions.
Reply
  • Hi Steve,

    You cannot really force the operator notes into a separate stream. This is based on the underlying unique object Id generated at object creation. Only sort of way to achieve this is to add them "later" (so compile - start - run once without the alarm notes and then add them, so they get appended after blocking them all together). Based on your remark JnI00104-JnI00112 this is hat sort of happened anyway.

    When you say query takes 17 sec, I reckon this is measuring using the AlarmDsp or AlarmListCreate functions.
Children
No Data