Journal Properties and Tables

Alarm Journal

In Ignition, 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 Journal Table component that can be accessed through scripting functions and direct database queries.

To create a new Alarm Journal profile

  1. Go to the Configure section of the Gateway.

  2. Choose Alarming > Journal from the menu on the left.
    The Alarm Journal Profiles page is displayed.

  3. Look for the blue arrow and click on Create new Alarm Journal Profile....
    The New Alarm Journal Profiles page is displayed.

    images/download/attachments/6046381/Configure_Alarm_Journal_2.png

  4. Fill in the fields and click the Create Journal button at the bottom of the page.
    Once completed, the tables will be created for you once an alarm event occurs. It’s a good idea to trigger a test alarm and verify that Ignition automatically created the tables in the database after your Alarm Journal Profile was created.

    Verify the Alarm Journal tables were created.

    You can easily verify the Alarm Journal tables from the Ignition Designer. Open it and go to the menu bar and select Tools > Database Query Browser.

    images/download/attachments/6046381/Alarm_Journal_Component_-_DB_Query_Browser_1.png

    The two tables that Ignition automatically creates are the alarm_events and alarm_event_data. 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. If you don’t see these two tables in your database, you need to make an alarm occur after the Alarm Journal Profile is created. Make the alarm Active, take it back to Clear, Acknowledge it, and you will start seeing information come into these tables.

    images/download/attachments/6046381/Alarm_Journal_Component_-_DB_Query_Broswer_Data_2.png

    Double click on the alarm_events, to see all the events that occurred when the alarms are Active, Cleared, and Acknowledged.

    images/download/attachments/6046381/Alarm_journal_Component_-_DB_Events_Data_3.png

    The alarm_event_data is all the associated data that is associated with each alarm.

    images/download/attachments/6046381/Alarm_Journal_Component_-_DB_Alarm_Event_Data_4.png

    You will want to look into the Database Query Browser to simply verify that the information is there. Once the information is there, close the Database Query Browser.

    Note: if the tables were not created, check the Gateway console page for any errors.

Reference

Journal Options

Main

Name

The default name is Journal.

Enabled

By default the journal profile is enabled.

Datasource

This is the ONLY required setting which must be a valid database connection, events are stored to this datasource.

Minimum Priority

Only events equal to or greater than the specified priority will be stored. The default is Low. You can set the priority to be: Diagnostic, Low, Medium, High, and Critical.

Store Shelved Events

Not enabled by default. If enabled, events generated by "shelved" alarms will still be written to the journal system.

Use Store and Forward

Enabled by default, which means the alarm journaled events will be stored through the Store and Forward system. If not enabled, they will be stored directly against the database. This system protects data from being lost due to temporary database connectivity issues.

Stored Event Data
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 . The following settings specify what type of event data is stored:

Static Config

By default, it is not selected. If selected, will store the values of static alarm configuration. That is, the alarm properties that are not bound. These do not change during evaluation, only when a user modifies them in the Designer, and so they are not stored by default.

Dynamic Config

If selected, will store the values of dynamically bound alarm configuration properties. The value of these properties can change at any time, and the values at the time of the alarm are captured on the alarm event.

Static Associated Data

If selected, will store the values of non-bound associated data (properties created by the user) properties on alarm that do not change during execution.

Dynamic Associated Data

If selected, will store the values of dynamically bound associated data (properties created by the user) properties.

Data Filters

Filter by Alarm Source

Only events matching the source will be stored. Multiple sources to match can be comma separated. Leave blank to store events from all sources.

Filter by Display Path

Only events matching the display path will be stored. Multiple display paths to match can be comma separated. Leave blank to store events from all display paths.

Filter by Display Path or Source

Only events matching the display path, if defined, will be stored. Multiple matches can be comma separated. If no display path is defined, only events matching the source will be stored. Leave blank to store all events.

Data Pruning

Enable Data Pruning

Default is not enabled. If selected, data will be deleted after the specified time period as set by the Prune Age and Units below. Note that since the data is stored directly in a database, an administrator is free to manually delete data at any time.

Prune Age

The number of Prune Age Units to store data for. IE: 1 year, 5 hours, etc. The default is 1.

Prune Age Units

The default is YEAR. You can choose the unit to be MS, SEC, MIN, HOUR, DAY, WEEK, MONTH, and YEAR.

Advanced
These settings let you 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).

Table Name

The default is alarm_events. The table name for the core event table.

Event Data Table Name

The default is alarm_event_data. The table name for event data associated with alarms.

Table Definitions

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.

Alarm Events ( alarm_events )

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 event

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.

Alarm Event Data (alarm_event_data)

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.

About System Events

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 in the journal:

  • System Startup

  • System Shutdown

  • Alarms Shelved

  • Alarms Unshelved

Qualified Paths

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-forward 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.

Similar Topics ...