What is the best approach for organizing Alarms and Event logging in Ignition Perspective?


I've been using the alarm and event logging features in Ignition Perspective. I'm using SCADA for a large number of tags, well over 1.5 million, in the renewables industry. For a long time, I've been using these functionalities in a very basic way, and I would like to improve their performance by addressing some issues I've noticed.

Current Situation: I have configured alarms for the tags with all necessary conditions and required bindings. The AlarmStatusTable component is responsible for displaying these alarms. To ensure proper historical logging of alarms, an Alarm Journal Profile with the appropriate Datasource has been added. Its settings can be considered default, with only the Prune Age modified to one month. All tags are divided into several providers corresponding to PV objects, and filtering is done by passing the provider parameter to the table.

This approach has led to several problems:

  • As the number of alarms and tags increased, I noticed that the Alarm and Event tables were becoming slower.
  • With the growing number of tags and, consequently, alarms and events, the alarm and event table stopped working. Opening the screen with the table doesn't display any information.
  • For an unknown reason, filtering sometimes fails, meaning alarms and events from other providers are displayed in the table despite providing the provider parameter for table filtering.

I suspect that cramming such a massive amount of information into a single location is negatively affecting the performance of these features. Therefore, I would like to request advice on how to improve this situation.

I have conducted research on these features, and it seems that dividing alarms from Tag Providers into different logs using Data Filters in these logs could be a viable solution. Another option is to redirect incoming data to other tables by configuring their names in the advanced options. I've also considered filtering using Associated Data and thought about creating a variable there to store the tag provider name, filtering data based on this variable rather than the path.

I couldn't find any information on separating alarms; it seems like there may not be an option to do so, meaning all alarms are in one pool without division into what we could call Alarm providers or something similar.

I'm very keen on improving the performance of these features, so I'm reaching out to experienced designers for ideas on enhancing their operation, making them more efficient and organized. How would you approach this situation if you were in my place, and what could be the root causes of the issues I've mentioned?

Best regards,
Michał Góralczyk

Before anything else, make sure you have proper indices on the DB tables. That is, indices on t_stamp and id and eventid and propname.

1 Like

We created indexes but for fewer properites. We will test the creation of indexes for the properties you hopped and check the effect on performance. Thank you for your advice I will come back to this.

It may be worth telling your DB to log complete queries for a little while so you can get a sample of the WHERE clauses Ignition is using to support the alarm journal components. If either table is consistently getting hit with queries with more than one criteria (using AND), a composite index on the targeted columns might be better than individual column indices.