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
  • Erik,

    Yep; once I figured how the journal streams were being created, I deliberately modified the note alarms to push them to the end of the journal blocks. If the test had worked then I might have been tempted to go back to support and ask them to journal specific* SOE alarms into separate blocks (eg. JnZ00001->), but the server's doing something else, so no point.
    * probably based on the SOE alarm classification

    Steve
Reply
  • Erik,

    Yep; once I figured how the journal streams were being created, I deliberately modified the note alarms to push them to the end of the journal blocks. If the test had worked then I might have been tempted to go back to support and ask them to journal specific* SOE alarms into separate blocks (eg. JnZ00001->), but the server's doing something else, so no point.
    * probably based on the SOE alarm classification

    Steve
Children
No Data