You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »


Contents

Introduction

Starting with release 2011.02, a task for the MC_SytemAlerter workflow can be configured to send an alert to the Alarmmodule, developed by Imtech for the IWP system. The alert sending has been implemented as an invocation of the Alarm module via a SOAP call (also know as a Webservice call). This page how to describe the FEWS-related part of the implementation. Currently these tasks can only be scheduled using the in the Admin interface. The uploaded XML configuration should conform to the taskList.xsd schema. For examples see below. The Alarm module alert part is defined in the referenced mcSystemAlerter.xsd schema.

Configuration

The following documents play a role in the generation of alerts.

  • ModuleConfigFiles\<secondaryValidation>.xml
    Contains the secondary validation rules that will generate logEventCodes that become visible in the logging when rules are exceeded. The log messages generated are defined in this file as well by means of <logEventCode>. It makes sense to choose sensible logEventCodes, for example all log messages used together with the Alarmmodule might start with "Alert.", see also the next section on this. File name is free to choose, secondaryValidation refers to the xsd that is used.
  • RegionConfigFiles\ all three threshold configuration files. See also the wiki page on this: 09 Thresholds
    • RegionConfigFiles\Thresholds.xml
      Defines the level for each threshold with <levelThreshold>. These thresholds can be used to change colors and the use of Flags in the Displays
    • RegionConfigFiles\ThresholdValueSets.xml
      Links timeSeriesSets to <thresholdValueSets>
    • RegionConfigFiles\ThresholdWarningLevels.xml
      Can be used to define the overlays and colors used when <thresholdWarningLevels> are exceeded, both up and down..
  • DisplayConfigFiles\<scadaDisplay>.xml
    Defines the scada display in which alerts can be used by means of <shapeComponentBehaviourDefinition>. File name is free to choose, scadaDisplay refers to the xsd that is used.

Logging examples

The configured secondaryValidation monitors the configured timeSeriesSets and logs an exceedance in the FEWS logging tabel. Below are examples of a log file at an FSS, the same log messages as shown in the FEWS Admin Interface page (via “System Status” and “View Logs”) and in the FEWS OC System Monitor as well.

Please note that these screenshots come from a test system. All alerts are created for test purposes only and do not relate to actual events.

Event action set-up

These screenshots show the IWP system, where all log messages related to the Alarmmodule start with “IWP.”. This commonality makes it easier to set up the Alarmmodule. In this case, an action has been configured in the Admin Interface that comes into action whenever a log messages starting with “IWP.” is logged. The configuration of this action consists of three parts (see also 04 Setting Up Event-Action Configuration):

  1. Workflows and FSSs >Event and Action Configuration, see also Event and Actions
  2. Forecast Tasks > Scheduled Tasks, see also Scheduled Tasks - Overview

Event and Action configuration

Here we set up an Action ID (in this example Alarmmodule.alarm) and link it to an <actionxml> configuration file, see the example below. In this example the logEventCode triggers a workflow with has the tag Alarmmodule.alarm. This action is a one off, meaning it will run only once after triggering, opposed to scheduled tasks that run at a fix schedule. Furthermore, this action can't be triggered more that once every 60 seconds. Please note that the Action ID and tag are the same. This is not required by FEWS, but makes it a lot easier for the operator to follow what's going on. 


<?xml version="1.0" encoding="UTF-8"?>
<actionxml type="task">
    <oneoff>
        <cardinaltime interval="60" reference="2004-01-01T00:00:00.000+00:00"/>
        <tag name="Alarmmodule.alarm"/>
    </oneoff>
</actionxml>

Event Action Mappings

Here we link the Action ID to a logEventCode. In this example all log messages starting with IWP.* are linked to the Action ID Alarmmodule.alarm. By using the wildcard symbol *, we don't have to specify each and every single eventCode separately. All log messages starting with IWP. will trigger the action we described in the previous secion.



Scheduled Tasks (fixed or template alert)

Here we link the workflow MC_SystemAlerter to the Event Action by means of a Tag. This task is not added manually (through the link "Schedule New Task"), but is uploaded from file (through the "Upload task(s) from file" functionality). In the example file below, the workflow has the tag Alarmmodule.alarm, which is the same tag we defined in the eventAction configuration file. Thus, this workflow will be run when a log message starting with IWP.* is generated. Please note that it is essential this scheduled task has the following properties:

  • Status is suspended, or <taskStatus>S</taskStatus>
  • Tag is Alarmmodule.alarm, or <taskTag>Alarmmodule.alarm</taskTag>
    Note: the screenshot of the Admin Interface doesn't match the example, but shows the tag ALARM_MODULE
  • Interval is One-off task, or <taskSelection><singleTask><time0>2011-08-23T09:05:00.000Z</time0></singleTask></taskSelection>
  • Configure webserviceURL of the Alarmmodule, or <webserviceURL>http://localhost:8989/AlarmModuleManager/webservices/alarmService</webserviceURL>
    This is an example based on the IWP system. The webservice of the <alarmModuleAlert> is the URL of the webservice of the alarm module that has been set-up according to the specifications of Imtech.
  • Alert message is configured as part of the task properties of the scheduled MC_SystemAlerter task, this can be either a
    • Fixed alert message, or <alarmDiagLine code="IWP_0_TEST" description="Test Alert from FEWS" source="MC01" level="1"/>, or a

    • Template alert message, or <alarmDiagTemplateLine code="%EVENT_CODE%" description="%LOG%" source="%MC_ID%" level="1"/>, in which

      • %LOG% will be replaced by the message part of log entry that triggered the Event Action
      • %EVENT_CODE% will be replaced by the event code of the log entry that triggered the Event Action
      • %MC_ID% will be replaced by the MasterController ID creating the log entry that triggered the Event Action


<?xml version="1.0" encoding="UTF-8"?>
<taskList
    xsi:schemaLocation="http://www.wldelft.nl/fews http://fews.wldelft.nl/schemas/version1.0/taskList.xsd"
    xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <task>
        <taskStatus>S</taskStatus>
		<taskTag>Alarmmodule.alarm</taskTag>
		<runOnFailOver>false</runOnFailOver>
        <taskProperties>
            <description>IWP_0_Alarm</description>
            <workflowId>MC_SystemAlerter</workflowId>
            <taskSelection>
                <singleTask>
                    <time0>2011-08-23T09:05:00.000Z</time0>
                </singleTask>
            </taskSelection>
            <forecastPriority>Normal</forecastPriority>
            <makeForcastCurrent>false</makeForcastCurrent>
            <makeStateCurrent>false</makeStateCurrent>
            <mcSystemAlerter>
				<alerts>
					<alarmModuleAlert>
						<webserviceURL>http://localhost:8989/AlarmModuleManager/webservices/alarmService</webserviceURL>
						<alarmDiagLine code="IWP_0_TEST" description="Test Alert from FEWS" source="MC01" level="1"/>
						<!-- <alarmDiagTemplateLine code="%EVENT_CODE%" description="%LOG%" source="%MC_ID%" level="1"/> -->
			</alarmModuleAlert>
				</alerts>
			</mcSystemAlerter>
        </taskProperties>
    </task>
</taskList>



Follow a log message from FEWS to the Alarm module

The logging of the Admin Interface shows us what the FEWS Server does, when detecting a logEventCode starting with “IWP.*” After the log message is generated on a FSS and stored in the Central DataBase they become visible in the Admin Interface (see Figure 1). The log message with Code “MC_EVENT_PROCESSOR..” tells us 4 new log entries have been detected. Next, the log message iwth code “MC_Alerter_..” indicates the alarm module has been contacted. When you click on the message in the Text column, it brings you to a separate page with more logging information (see Figure 2). Here we see that 3 messages have been sent to the Alarm module correctly, but 1 message has been sent twice. To check whether alert messages are send through correctly in the Alarm module, we open the Alarm Module GUI in a browser. After logging in, we see an overview display showing the date-time of all alert messages (see Figure 3). We see the same log messages we saw previously in the Admin Interface and FEWS OC System Monitor. This means the messages are sent through to the Alarm module correctly. It depends on the configuration of the Alarm module which messages are displayed. In this example we'll look at the alarm code for Schabbert. In FEWS this log message is generated “IWP.Schabbert>AW”. In the Alarm module GUI the following Alarm Definition is defined (see Figure 4).This alarm is linked to groups of people, who will receive the alarm message. The members of each group can be configured in the Alarm module as well.

Please note that these screenshots come from a test system. All alerts are created for test purposes only and do not relate to actual events.

Figure 1:

Figure 2:

Figure 3:

Figure 4:

More information

For more information the reader is referred to the manual of the Alarm module itself, or to the creators of the module at Imtech.

  • No labels

Disclaimer