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
  • Thanks for the response Erik.

    Interesting idea about running two alarm clusters. We'll have to look into the ramifications of splitting the system, as it was (mostly) designed to handle multiple clusters but has never been tested in such a configuration.

    Your comment about the journaling structure (streamsize) was interesting though. I had imagined that if I could force the operator note alarms into different journal files than the standard alarm summary events that this might affect the query response time. Unfortunately, this does not appear to be the case. My test system has 113 directories for journal history files (JnI00000 to JnI00112), and I've generated (overnight) 300,000 standard alarm summary events that fall into JnI00082. The operator note alarms fall into JnI00104-JnI00112, and yet a query for a specific tag lying in one of those journals takes over 17sec to return.

    It would be nice to know quite a bit more information about how the alarm sever works and whether there are any optimisations inherent in the system that we could lever off to get the performance that we require.
Reply
  • Thanks for the response Erik.

    Interesting idea about running two alarm clusters. We'll have to look into the ramifications of splitting the system, as it was (mostly) designed to handle multiple clusters but has never been tested in such a configuration.

    Your comment about the journaling structure (streamsize) was interesting though. I had imagined that if I could force the operator note alarms into different journal files than the standard alarm summary events that this might affect the query response time. Unfortunately, this does not appear to be the case. My test system has 113 directories for journal history files (JnI00000 to JnI00112), and I've generated (overnight) 300,000 standard alarm summary events that fall into JnI00082. The operator note alarms fall into JnI00104-JnI00112, and yet a query for a specific tag lying in one of those journals takes over 17sec to return.

    It would be nice to know quite a bit more information about how the alarm sever works and whether there are any optimisations inherent in the system that we could lever off to get the performance that we require.
Children
No Data