Introduction
Application Server 2014 enables you to Historize alarms and events using Historian. The new storage procedure for Historical alarms and events starts at the Area level as opposed to the Galaxy level in the previous versions. Alarms and events are captured from the Notification Distributor of each Area. Then they are sent to Event Historization Service (EHZ) and then to the Historian.
This Tech Note demonstrates the new functionality.
The following topics are covered in this Tech Note:
Storage Process
Selecting Alarm/Event Categories to Historize
Configuring the Engine and Application Object
Configuring the Alarm Client and Demonstrating Runtime Behavior
Failing Over from the Primary to the Secondary Historian
Assumptions
This Tech Note assumes that you have already configured a redundant Historian. For information on configuring redundant Historian, refer to Tech Note 987 Configuring AppServer to Store Data in Primary and Partner Historians.
Application Versions:
Wonderware Application Server 2014 (version 4.0) or later
Wonderware InTouch 2014 (version 11.0) or later
Wonderware Historian Server 2014 (version 11.5) or later
Storage Process
1. The Alarms and Events are stored in the new A2ALMDB database located in the Historian with the same schema as existingStoring Application Server 2014 Alarms and Events Using Historian WWALMDB.
2. Events and process data follow the same route through HCAL (Historian Client Access Layer) to Historian.
3. Existing Alarm and Event message flow is not altered. They can still be sent to Alarm Manager and historized to WWALMDB.
4. Alarms, Events and Process Data share the same historian configuration such as historian node; store/forward path etc. “Enable storage to historian” must be enabled to historize process data and events.
5. Similar to process data, Alarm and Events historization also support store/forward, application engine fail-over and dual Historians.
Selecting Alarm/Event Categories to Historize
Choose the alarm and event categories that you would like to historize by using the Alarm Priority Mapping applet.
To open Alarm Priority Mapping, go to Galaxy\Configure\Alarm Priority Mapping. Figure 1 (below) shows the default settings of Alarm Priority Mapping in a new Galaxy.
FIGURE 1: ALARM AND EVENT PRIORITY MAPPING APPLET
Note: In a migrated Galaxy, the Historize option is not enabled by default.
Checking/unchecking the Historize checkbox against each category determines whether or not you would like to historize them.
Modifying the Historize option does not require you to deploy changes.Storing Application Server 2014 Alarms and Events Using Historian
For this example, the Low Alarm Severity level (default from priority 751 to priority 999) is unchecked (Figure 2 below). For more
details about Alarm Priority Mapping, please refer to Application Server User’s Guide.
FIGURE 2: LOW ALARM SEVERITY LEVEL IS UNCHECKED
Configuring the Engine and Application Object
Setting up the Engine
At the Engine level, select the Enable storage to historian and Enable Tag Hierarchy. Then select the Primary Historian node for the
Historian source.Storing Application Server 2014 Alarms and Events Using Historian
FIGURE 3: ENABLE STORAGE TO HISTORIAN
Note: The Historian above (AI08R2SP1H1) has a partner Historian (AI08R2SP1H2).Storing Application Server 2014 Alarms and Events Using Historian
Object Setup
For this example, create a simple Application Object Template and configure it with with the following:
A Discrete field attribute (Alm1) with a State alarm of 500 priority.
FIGURE 4: DISCRETE ALARM WITH PRIORITY 500
A Discrete field attribute (Alm2) with a State alarm of 800 priority.Storing Application Server 2014 Alarms and Events Using Historian
FIGURE 5: DISCRETE ALARM WITH PRIORITY 800
A Discrete field attribute (Evt1) with Generate event upon change checked.Storing Application Server 2014 Alarms and Events Using Historian
FIGURE 6: DISCRETE EVENT
Deploy an instance of this template and change the Alarm states of its three attributes to True.
Configuring the Alarm Client and Demonstrating Runtime Behavior
1. Create a new Archestra Graphic and insert an Alarm Client Control.
2. Select the following for the properties:
a. Historical Alarms and Events
b. Authentication Mode: Windows Integrated
c. Server Name: Primary Historian Server Name (AI08R2SP1H1)
d. Database Name: A2ALMDBStoring Application Server 2014 Alarms and Events Using Historian
FIGURE 7: ARCHESTRA GRAPHIC
3. Test the Connection.Storing Application Server 2014 Alarms and Events Using Historian
FIGURE 8: TEST THE DB CONNECTION
4. For illustration purposes ONLY, create another ArchestrA graphic with an Alarm Client to show the Current Alarms.Storing Application Server 2014 Alarms and Events Using Historian
FIGURE 9: CURRENT ALARMS
5. Embed the two ArchestrA graphics demonstrated above into a managed InTouch application.
6. Go to Runtime.Storing Application Server 2014 Alarms and Events Using Historian
FIGURE 10: RUNTIME ALARM STATES
While the State alarms for Alm1 and Alm2 are in the Current Alarms client (the top viewer), only the alarm for Alm1 is in the Historical client (the bottom viewer). This is because the Alarm category containing Alm2 wasn’t selected for historization as
mentioned above.
Failing Over from the Primary to the Secondary Historian
One advantage of using Historian to store the alarms and events of Application Server is that you can make use of the redundant Historian feature. In other words, when the primary Historian becomes unavailable, the Alarm Client fails over to the secondary Historian automatically.
The following graphics demonstrate this:
The Primary Historian (AI08R2SP1H1) is available as shown in the Status Bar (Figure 10 below).
FIGURE 11: PRIMARY HISTORIAN IN STATUS BAR
When the Primary becomes unavailable, the Alarm client fails over automatically to the Secondary Historian (AI08R2SP1H2) as shown in the Status bar (Figure 12 below).Storing Application Server 2014 Alarms and Events Using Historian
FIGURE 12: SECONDARY HISTORIAN IN STATUS BAR
Note: After failover, the Alarm Client stays connected to the Secondary Historian even if the Primary becomes available. The Alarm Client connects back to the Primary Historian only when the Secondary fails.