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

Compare with Current View Page History

« Previous Version 8 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 Alarmmodule 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 "Upload task(s) from file" functionality in the Admin interface. The uploaded XML configuratio should conform to the taskList.xsd schema. For examples see below. The Alarmmodule alert part is defined in the referenced mcSystemAlerter.xsd schema.

Configuration

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

  • ModuleConfigFiels\<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\TresholdValueSets.xml
      Links timeSeriesSets to <thresholdValueSets>
    • RegionConfigFiles\TresholdWarningLevels.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

The configured secondaryValidation monitors the configured timeSeriesSets and logs an exceedance in the FEWS logging tabel. A log file at an FSS might look like this:

The same log messages can be viewed in the FEWS Admin Interface page, via “System Status”and “View Logs”:

They are displayed in the FEWS OC System Monitor as well:

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 Admin Interface - Workflows and FSSs - Event and Action Configuration
  2. Workflows and FSSs > Event Action Mapping, see also Admin Interface - Workflows and FSSs - Event Action Mappings
  3. Forecast Tasks > Scheduled Tasks, see also Admin Interface - Forecast Tasks - Scheduled Tasks (from 2009.01)

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 link "Upload Task(s) from File"). 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>
  • 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>

Demonstration of the entire workflow

Om nu te zien wat de FEWS Server allemaal doet bij het detecteren van “IWP.*” logmeldingen moet goed in de logging van de Admin Interface gekeken worden. Nadat de log meldingen op de FSS zijn gegenereerd en opgeslagen in de centrale FEWS database ziet de Admin Interface dat er nieuwe meldingen zijn.

 

De code “MC_EVENT_PROCESSOR..” geeft aan dat er 4 nieuwe log entries zijn gevonden, dat klopt met de eerdere log meldingen die we gezien hebben. Vervolgens is er een melding “MC_Alerter_..” die aangeeft dat er contact is geweest met de alarm module. Wanneer de melding in de kolom Text wordt geselecteerd worden de volgende meldingen getoond:

 

Deze log melding geeft aan dat er 3 meldingen correct naar de Alarm module zijn gestuurd en dat er 1 melding dubbel is gestuurd.

Om nu te controleren of de alarm meldingen goed doorkomen in de Alarm Module wordt de Alarm Module GUI geopend.

 

Aanmelden met admin/admin geeft het volgende scherm.

 

Aan de datum-tijd van de meldingen is te zien dat dit dezelfde meldingen zijn als eerder in de FEWS Admin Interface en FEWS OC System Monitor te zien was. De meldingen zijn dus goed doorgekomen in de Alarm Module.

Welke meldingen er te zien zijn in de Alarmmodule, hangt af van de configuratie van de Alarm Module. Als voorbeeld wordt de alarm code voor Schabbert genomen. In FEWS wordt de volgende log event code gegenereerd “IWP.Schabbert>AW”. In de Alarm Module GUI is een Alarm Definitie opgegeven:

De alarm is aan de Watercoordinatoren groep toegekend, die zal deze melding dus ontvangen. Om de meldingen in de Alarm Module te kunnen zien is de admin gebruiker toegevoegd tot de groep Watercoordinatoren.

Meer informatie over het opzetten van de koppeling met de Alarm Module kan gevonden worden op de FEWS WIKI:

http://publicwiki.deltares.nl/display/FEWSDOC/07+Setting+up+alerts+for+the+Alarmmodule

 

Meer informatie over de Alarm Module kan gevonden worden in de Alarm Module Handleiding, of opgevraagd bij Imtech.

  • No labels

Disclaimer