If I’m understanding correctly, an alarm journal with no filters setup will store any alarm generated anywhere and there is no way to tell a project to store alarms to a specific alarm journal. Any differentiation must be done by setting up filters on the journal side.
Is there a recommended best practice in regards to storing alarms? Is it generally best to have a single alarm journal which stores all alarms, and then filter on display path and/or source when using a alarm journal table component? Or is it considered better to set up an alarm journal per project and use the journal filters to be sure of only storing alarms from that project?
What are the pros and cons of the various setups?
Great question.
The answer is it depends.
Do you want the people using the system to be able to see all alarms from every project at the same time? Then I would have no filters setup.
Do you want people to go to the different projects to see the journal of the alarms?
Then I would set up separate journals.
Pros/Cons:
Combined journal:
Pros = Easy to view all alarms in one journal. Use of filters on alarm journal component will allow specific areas to be viewed.
Cons = If alarm management is not good, then the flat alarm journal table will fill up fast, especially if pruning is not enabled
Separate journals:
Pros = It is easy to tell one journal apart from another. This is especially useful if the systems are totally separate and operations will never want to see the alarm history all together. By the way, the alarms can be combined via scripting by doing some fairly straightforward queries to the different alarm journal tables.
Cons = The alarm journal component no longer shows all of the alarm history. A custom solution (i.e. power table driven by script) has to be made to combine all alarm history in one place
Hope that helps.
1 Like