[00:00] In this lesson, I'll demonstrate how to create an alarm journal profile. By default, Ignition will capture current alarm data in memory. However, it will only capture a finite amount of events for each alarm, and this information is lost upon a gateway shutdown. Fortunately, an alarm journal can be created for long-term storage of alarm data. A journal can store basic information about alarms that have occurred such as their source and timestamp, associated data on the alarm, and value of the alarm properties at the time of the alarm event. We can set up these alarm journals via the gateway webpage. If we navigate to Config > Alarming > Journal and click create new alarm journal profile. We have a couple options here for our alarm journal. The database option will send alarm event data to an external database for storage. This option requires that we have a valid database connection created, which I've already set up before recording. The remote option will send alarm event data to a remote gateway's alarm journal to be logged.

[01:02] This can be useful in hub and spoke architectures where the hub stores alarm events for each spoke. Finally, the internal option allows you to store alarm event data in the Ignition install directory on the gateway, and this can be useful if you don't have an external database to connect to. I'll pick the database option since I have a valid connection and I'll click next. I'll give this journal a name and then I'll be asked to pick a data source where alarm data will be sent. I'll click the dropdown and choose my SQLServer connection. The "query only" option is new to 8.1.5 and can be used to opt this journal out of storing events. Any events that will be sent to this journal will be discarded. I'll leave this set to false so that it will store alarm events. The "use store and forward" option, new to 8.1.23, is enabled by default and sends events through the store and forward system to protect against any temporary database connectivity issues where events might otherwise be lost. Moving down to the events properties, we can set the minimum priority for an event before it's allowed to be stored in this journal.

[02:03] So if I were to change this to high, only events that are high or critical priority would be stored. I can also check these boxes to store shelved events or events for enabling or disabling an alarm event. Data properties are where you can choose what kind of event data gets stored. The built-in alarm properties fall under the config umbrella and you can specify whether or not properties should be stored if they're static, and not bound to anything, or if they're dynamic, and they are bound. Then user created properties are the associated data, and these can also be stored based on whether or not they're static or dynamic. Data filters can be added to decide which alarms are stored by specifying alarm sources, display paths, or by filtering on both. Adding a filter means that only alarms that match the filter will be stored. For example, if I were to add a display path filter for "pump alarm", only alarms with that specific display path would be stored in this journal. Leaving these blank means that nothing will be filtered based on these fields. The three filters together interact via a logical AND, meaning iIf there is a filter for alarm source and display path, an alarm has to match both of them exactly in order to store.

[03:09] All of the filters will accept a wild card symbol and can accept multiple comma separated values. The next set of properties have to do with data pruning. Enabling this means that alarm event data will be deleted after a specific time period you can specify with the age and unit properties. Data pruning may be especially useful for internal alarm journals to avoid the gateway running out of hard drive space. If I click show advanced properties, there are a couple more settings here that allow me to specify the name of the tables that will be created in the database. By default, the core table will be named alarm_events and the table for the event data will be alarm_event_data. Since I'm happy with my settings, I'll go ahead and click create new alarm journal profile, and now I'm ready to store alarm journal events on my gateway.