800xA Alarm storage configuration Auto-function, and Alarm storage in MI.
I would like to know more in detail how the Auto-function is working in Alarm Storage Configuration. Say we have Max number to 10000. We have reserved 1000 for System Alarms. Our 3 remaining categorys have Auto, so they share the rest of 9000 alarms? How are they spread? What happens if we get total 9000 alarms in these categorys, and then 100 more? Will the oldest alarm dissapear so we can see the new 100 alarms? Or will our new alarm not come in at all, so we loose them? Or will they come in when any of the first 9000 alarms goes back to normal state? Any priority in the row order?
Another question about Alarm storage in Multisystem Integration:
In manual 3BSE037410-510 D it says "The Alarm Server is capable to save the 10000 (default) most recent alarms."
-"capable" sounds like this is the limit? Or can you increase it? I think I read it is recommended to leave it unchanged. But that leads to my third question:
The MI-manual 3BSE037076-600 B says "Make sure that Alarm Storage in the subscriber system is large enough to hold both the local alarms and the remote alarms. If for example the subscriber system is connected to one provider system, the size should be double and so on.".
-Does this mean it is okay to increase max value to 50000 if we have 5 provider systems? Or actually 60000 if you count 5 providers+1 subscriber.
Voted best answer
Auto = FIFO sharing with other categories set with auto in main storage (default 10.000 alarms)
Manual setting = separate storage "outside" main storage, not shared with any other category.
11.000 is the total number of alarms stored if one category is set with 1000 and the others with auto.
When/if capacity in main or separate storage is reached, the oldest alarm (in that pool) will vanish and its Alarm Global Properties will return to normal as if no alarm is present.
By avoiding "Make new alarm each time a condition gets active" and defining noisy categories with separate storage, overflow will become less likely.
The ListAlarmSize operation in applog on the Alarm Manager will tell how much space is in use.
No formal tests have been made AFAIK. I believe "sane" increases are OK, but its more than just setting a number. The performance is also dependent on number of clients, number of active alarm filters, number of Alarm List and Alarm Global Properties in use, depth of descendant lists in use, etc, etc.
Hard to tell. Please file an official support case with your regional ABB service organisation.