Versions Compared

Old Version 1

changes.mady.by.user Paul Scott

Saved on

compared with

New Version Current

changes.mady.by.user Nichole Boehnke

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


By default, current alarm data is only stored in memory, and a finite number of events are retained for each alarm. Fortunately, Ignition can easily be configured to store alarm data into a SQL database with an Alarm Journal Profile. The journal can store basic data about alarms that have occurred, such as their source and timestamp, 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, and can be accessed through scripting functions and direct database queries.

The Gateway can have more than one Alarm Journal.  Alarm Journals have options to filter which Alarms are stored in the journal, therefore, by having more than one alarm journal configured on the Gateway, it is possible to store some alarms in one journal, and different alarms in another journal. Once configured, the journal can be accessed by the Alarm Journal Table component, scripting functions, or direct database queries.

Alarm Journals can store data in one of three ways, and store data indefinitely unless a Data Pruning value is set: 

  • In a database, using an existing database connection from the Gateway
  • Remotely, using another Ignition Gateway's Alarm Journal profile
  • Internally, storing alarm information into the Ignition install directory

It is strongly encouraged to set a Data Pruning value for Internal Alarm Journal Profiles. Otherwise, it could cause your computer to run out of hard drive space.


Note
titleConfiguring an Alarm Journal
_friendly

You must have an Alarm Journal Profile created and have a valid database connectionto use the Alarm Journal Table.


Creating an Alarm Journal Profile

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 source and timestamp, along with associated data on the alarm, and the values of the alarm's properties at the time the event occurred. You can choose to store your alarm data on an external database or automatically send it to a remote gateway's Alarm Journal to be logged. Both options are described in the sections below.

Create a single Alarm Journal Profile to store all of your alarms, or create multiple journals to store alarms across multiple databases. Each journal stores alarms based on the filters you set up and can prune data automatically after a set time limit.

On_this_page


Scroll html ignore
Iulink
URLhttps://www.inductiveuniversity.com/videos/create-alarm-journal-profile/8.0
NameCreate Alarm Journal Profile



Create an Alarm Journal to Log Events to an External Database

  1. Go to the Config section of the Gateway webpage.
  2. Choose Alarming > Journal from the menu on the left.  

  3. Look for the blue arrow and click on Create new Alarm Journal Profile.... The Alarm Journal Profiles screen will be displayed.



  4. You have the option of logging alarm journal events to an external database, logging locally, or sending them to a remote gateway's Alarm Journal. In this example, select Database, and click Next. (Configuring alarm journal events to be sent to a remote gateway is addressed in Create an Alarm Journal to Log Events to a Remote Gateway section on this page.



  5. Enter the Name of your alarm journal profile. The default name is 'Journal.'  Most of the fields have default settings. Refer to the journal properties table below for setting descriptions, and update as necessary. Click the Create New Alarm Journal Profile button at the bottom of the page. Once completed, the tables will be created for you once an alarm event occurs. 




    Info
    titleUsing Multiple Alarm Journals
    Note_friendly

    If you only have one alarm journal specified on your Gateway, then you do not need to specify the journal name on the Journal Name property. Ignition will set this for you. If you have more than one alarm journal created, then you need to provide the name of the journal you'd like to query in the Journal Name component property of the Property Editor.

    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 is created. 
    Expand
    titleVerify the Alarm Journal tables were created.

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

    Image Removed

    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, 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. 
    Image Removed

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

    Image Removed

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

    Image Removed

    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.


New_in
Version8.0.7
Create an Alarm Journal to Log Events to a Remote Gateway

Remote Alarm Journal Profile

Utilizing the gateway network, remote alarm journal profiles allow one Ignition gateway to sent local alarm events to a remote gateway for journal logging. This type of profile is useful in cases where alarm events need to be recorded by multiple alarm journal profiles. In addition, this type of profile is useful in Hub and Spoke architectures as it allows the hub to record the alarm events from each spoke,

Creating a Remote Alarm Journal Profile

Just like configuring alarm journal events to be logged into a database, it is done from the Gateway Webpage, Config > Alarming > Journal.

  1. To have your alarm journal events automatically sent to a remote gateway's alarm journal, select Remote, and click Next.


  2. A list of known Gateways will be displayed. If you don't see a gateway that you expected to see, check your Gateway Network settings to verify that the connections are valid. You also have the option to specify a gateway manually. This example selects a valid gateway. Click Next. 


  3. If an Alarm Journal exists on the remote gateway, the fields will autopopulateautomatically populate. The name of the gateway and the Alarm Journal Profile name will appear in the Name field prefaced with the alarm journal profile name,(i.e., Ignition_Test_Journal), as shown in the following example. Click Create New Alarm Journal Profile. 
    Image Removed

  4. You will receive a successful message stating your new Alarm Journal Profile was created.
    Image Added

Remote Gateway Alarm Journal Properties Table

Main

Name

The default name, is the name of the Remote Gateway and Alarm Journal.


Image Removed

Remote Gateway Alarm Journal Properties Table

Main

Name

The default name, is the name of the Remote Gateway and Alarm Journal.

Description

Description of the journal profile. Optional

Enabled

By default. The journal profile is enabled.

EnabledBy default. The journal profile is enabled.

Description

Description of the journal profile. Optional

Query Only
New_in
Version8.1.5


If set to true, allows the alarm journal to opt out of being used for storage. When set to true, all alarm events will be discarded by the given journal.

Remote Gateway

Gateway Name

Name of the Remote Gateway.

Alarm Journal

Name of the Alarm Journal on the Remote Gateway.

Advanced

Use Store and Forward

New_in
Version8.0.8
Version8.1.23


If enabled, audit events will be stored through the Store and Forward system. If not enabled, they will be stored directly against the remote Gateway. Default is true.


Create an Internal Alarm Journal to Log Events Locally

Ignition Gateways can now create an Internal Alarm Journal Profile that stores Journal entries locally.Go to the Gateway webpage, Config > Alarming > Journal tocreate the Internal alarm journal profile.

  • Click on the the Create new Alarm Journal Profile... link.
    • Select Internal to have your alarm journal events logged locally.
    Image Removed
    Enter the name of your alarm journal profile and update any settings as required, then click Next.
    Image Removed
    You will receive a successful message stating your new Alarm Journal Profile was created.

    Internal Alarm Journal Properties Table

    Main

    Name

    The default name, is the name of the Remote Gateway and Alarm Journal.

    Minimum PriorityOnly events equal to or greater than the specified priority will be stored.

    Description

    Description of the journal profile. Optional

    Stored Shelved EventsIf enabled, events generated by "shelved" alarms will still be written to the journal system. Default is false.

    Enabled

    By default. The journal profile is enabled.

    Third Party Accessibility

    Because the Alarm Journal uses a SQL database to log alarm events, any application that has access to the database can retrieve journal data. Alarm events can be made freely available outside of Ignition, and integrated into other software packages. Additionally, other applications can write to the same tables, so Ignition applications can monitor activity in other systems.  

    Alarm Journal Component

    While a SQL query will return data from the journal, the Alarm Journal Table component will automatically do so without manually writing a query. The component can filter on both Display Path and Source Path, as well as Date Range. The component can be configured to a single Journal Profile, so multiple instances of the component in the same project may look at different profiles. 

    More information on this component can be found on the Alarm Journal Table Component page. 

    Image Removed

    Journal Properties

    Main

    NameThe default name is Journal

    create an Internal Alarm Journal Profile that stores Journal entries locally. Go to the Gateway webpage, Config > Alarming > Journal tocreate the Internal alarm journal profile.

    1. Click on the the Create new Alarm Journal Profile... link.
    2. Select Internal to have your alarm journal events logged locally.

      Image Added


    3. Enter the name of your alarm journal profile and update any settings as required, then click Next.

      Image Added


    4. You will receive a successful message stating your new Alarm Journal Profile was created.

    Internal Alarm Journal Properties Table

    Main

    Name

    The default name, is the name of the Remote Gateway and Alarm Journal.

    Minimum PriorityOnly events equal to or greater than the specified priority will be stored.

    Description

    Description of the journal profile. Optional

    Stored Shelved EventsIf enabled, events generated by "shelved" alarms will still be written to the journal system. Default is false.

    Enabled

    By default. The journal profile is enabled.

    Alarm Journal Component

    The Vision and Perspective modules feature built-in components that can automatically retrieve events recorded in an Alarm Journal. See Vision - Alarm Journal Table and Perspective - Alarm Journal Table for more information.

    Image Added


    Journal Properties

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

    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:    info

    Main

    NameThe default name is Journal.
    DatasourceEvents are stored to this datasource. (Only available on Database type profiles)
    EnabledBy default. the journal profile is enabled.
    DescriptionDescription of the journal profile.
    EnabledBy default. the journal profile is enabled.
    Datasource.
    Query OnlyWhen enabled, the alarm journal will not store alarm events. 
    Use Store and ForwardEnabled 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. (Only available on Database type profiles)

    Events


    Minimum PriorityOnly 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 EventsNot enabled by default. If enabled, events generated by "shelved" alarms will still be written to the journal system.
    Use Store and ForwardEnabled 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.

    Store Shelved Events

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


    Store Enabled & Disabled Events
    New_in
    Version8.1.8


    When enabled, enabling or disabling alarms will be stored as events in the journal. This includes cases where the Enabled property on an alarm is toggled, as well as cases where a Tag's Alarm Eval Enabled property is changed. 


    Event Data


    Static ConfigBy 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 ConfigIf 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 DataIf 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 DataIf selected, will store the values of dynamically bound associated data (properties created by the user) properties.

    Data Filters

    Anchor
    journalDataFilters
    journalDataFilters

    Note_friendly

    The following three properties interact via logical AND, meaning an alarm must meet the criteria for all three for it to be logged in the Journal. Thus, if you supply values for all three Data Filer properties, then an alarm must match the Filter by Alarm Source, Filter by Display Path, and Filter by Display Path or Source properties.

    Example: If a journal has values for all three properties, and an alarm only meets the requirements for Filter by Alarm Source and Filter by Display Path or Source, but not Filter by Display Path, then the alarm will not be logged to the Journal.

    If you want to filter on both the Display Path and Source Path, you would want to use only one of the two following approaches:

    • Filter by Alarm Source and Filter by Display Path
    • Only use Filter by Display Path or Source

    It is recommended to avoid using all three properties simultaneously on the same Journal.

    Filter by Alarm SourceOnly 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 PathOnly 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 SourceOnly 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

    If selected, data will be deleted after the specified time period as set by the Prune Age and Units below. Default is false.

    Note that since

    Note_friendly

    Since the data is stored directly in a database, an administrator is free to manually delete data at any time.


    Prune AgeThe number of Prune Age Units to store data for. i.e., 1 year, 5 hours, etc. The default is 1.
    Prune Age UnitsThe type of Prune Age Unit. Default is Years. You can choose the unit to be Milliseconds, Seconds, Minutes, Hours, Days, Weeks, Months, or Years.

    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 NameThe table name for the core event table. The default is alarm_events.
    Event Data Table Name

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


    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

    idintegerA unique integer id for each event entry event
    eventidstringThe 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 sourceof the alarm event.
    sourcestring

    The qualified path of the entity that generated the alarm event. See below for more information about qualified paths.

    display pathstring

    The value set for the "Display Path" of the alarm. Generally a user defined, friendlier version of the source.

    priorityinteger

    The priority or severity of the alarm:

    0: Diagnostic
    1: Low
    2: Medium
    3: High
    4: Critical

    eventtypeinteger

    The type of transition represented by this event:

    0: Active
    1: Clear
    2: Acknowledgement

    New_in
    Version
    1: Clear
    2: Acknowledgement
    8.1.8


    The following values were added in 8.1.8

    4: An alarm was enabled
    5: An alarm was disabled

    eventflagsinteger

    A numeric bitmask flag field providing additional information about the event.

    Bit 0: System Event - One of the designated system events. (System Startup, System Shutdown)
    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.
    Bit 3: Acknowledge Event - The event was acknowledged at the time of the event. For events that are cleared after being acknowledged.
    Bit 4: Cleared Event - The event was cleared at the time of the event. For alarms that are acknowledged after being cleared.


    New_in
    Version8.1.8


    The following bit was added in version 8.1.8:

    Bit 5: Enabled - Signifies that the enabled state on the alarm was changed. 

    eventtimedatetimeThe 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

    idintegerThe id that corresponds to the alarm event in the alarm_events table.
    propnamestringThe name of the property. May be one of the common alarm properties (a configuration setting), or the name of an associated data property.
    dtypeintegerThe 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.

    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.

    next_link