Alarm Journal

An alarm journal stores historical information about alarms in a database. It can store basic data about alarms that have occurred, such as their source and timestamp, along with associated data on the alarm, and the values of the alarm's properties at the time the event occurred. The alarm journal is used by the Alarm History Component, and can be accessed through scripting functions and direct database queries.

Alarm journals can be created by going to Alarming>Journal in the Ignition gateway, and selecting "Create new...". The only required setting is the Datasource, which must be a valid database connection.

The minimum priority and store shelved events options filter what time of alarm events are stored in the journal. "Shelved" events are alarms that have been temporarily silenced by operators. Though they are not displayed to users, these events continue to be generated, and can be stored if the journal settings permit it. When stored, they will have a special flag indicating that they were shelved at the time.

If enabled, the alarm events will go through the Store and Forward system. This system protects data from being lost due to temporary database connectivity issues.

Alarm events consist of two main types of data: the primary information about the alarm, such as transition state, time, etc, and the "event data". These settings specify what type of event data is stored:

If enable, the system will periodically delete data older than the specified timeframe. Note that since the data is stored directly in a database, an administrator is free to manually delete data at any time.

These settings allow you to specify your own table names. This is especially useful when trying to use multiple alarm profiles within a single database (not common, but can happen, especially with multiple systems sharing a single database).

The alarm journal system will automatically create the necessary tables for you, and scripting functions can be used to query the system without having to know about the table structure. However, understanding the structure of the alarm journal tables can be useful for accessing the data in situations where SQL queries are more convenient.

This table stores the core data for each event that occurs. An event is a transition for an alarm between active, cleared, or acknowledged. Additionally, other events may be stored in this table that aren't directly related to an alarm, such as a system shutdown event. This table defines a primary key "id", that is used as a foreign key by the Alarm Event Data table, which stores additional information for each event.

Column Name	Data Type	Description
id	integer	A unique integer id for each event entry.
eventid	string	The UUID of the alarm event that this individual event is related to. Each "alarm event" (one particular active/clear/ack cycle of a defined alarm) receives a unique id in order to distinguish it from other events from the same source.
source	string	The qualified path of the entity that generated the alarm event. See below for more information about qualified paths.
display path	string	The value set for the "Display Path" of the alarm. Generally a user defined, friendlier version of the source.
priority	integer	The priority or severity of the alarm: 0: Diagnostic 1: Low 2: Medium 3: High 4: Critical
eventtype	integer	The type of transition represented by this event: 0: Active 1: Clear 2: Acknowledgement
eventflags	integer	A numeric bitmask flag field providing additional information about the event. Bit 0: System Event - See below for more information Bit 1: Shelved Event - The alarm was "shelved" at the time that the event occurred. Shelving alarms does not prevent execution, so if the journal is configured to store shelved events, they will be stored even if they're not sent to the notification system, or shown to users. Bit 2: System Acknowledgement - When the "live event limit" (defined in general alarm settings) is exceeded, the system will automatically acknowledge overflow events, and the acknowledgment event will have this flag set.
eventtime	datetime	The time of the event.

This table stores the properties associated with an alarm event. The individual event is referenced through the "id" column, against the alarm event table.

Column Name	Data Type	Description
id	integer	The id that corresponds to the alarm event in the alarm_events table.
propname	string	The name of the property. May be one of the common alarm properties (a configuration setting), or the name of an associated data property.
dtype	integer	The data type of the property, indicating which data column should be used: 0: Integer 1: Float 2: String
intvalue, floatvalue, strvalue	integer, float (double), string	The corresponding value columns for the property. Unused columns will receive "null" values.

Note: Although the dtype column indicates which data column should be used, since null will be stored in the unused columns, using "coalesce(intvalue, floatvalue, strvalue)" provided by most databases is an effective way to query the value.

System events are stored in the journal to record actions that aren't directly related to a particular alarm. Currently the following events are stored:

A qualified path in Ignition is a path to an object, described by various annotated components. Each component has a type identifier, and a value, separated by a colon (":"), and each component is separated by colon-foward slash (":/"). For example, an alarm is identified by "alm:Alarm Name". It usually exists under a tag, in which case its fuller path would be "tag:Path/To/Tag:/alm:Alarm Name". Paths can be built up further depending on the level of specificity required by the situation.