Versions Compared

Old Version 6

changes.mady.by.user Simone De Kleermaeker

Saved on

compared with

New Version 7

changes.mady.by.user Simone De Kleermaeker

Saved on

Key

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

...

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

From logging to Alarmmodule

Van logmelding naar alarmmodule

De werking van deze functionaliteit is als volgt:

  • De alarmen module instance controleert alle opgegeven tijdreeksen en logged een alarm in de FEWS logging tabel. Op de FSS logging is het volgende zichtbaar:

Image Removed

 

  • Als je in de FEWS Admin Interface de pagina “System Status”en vervolgens “View Logs” opent kan je dezelfde logging informatie vinden.

Image Removed

 

  • Ook in de FEWS OC System Monitor komen deze log meldingen door.

Image Removed

In de FEWS Admin Interface en in de FEWS OC System Monitor is te zien dat alle alarm log meldingen een Event code hebben die begint met “IWP.”. Nu is in de Admin Interface een actie geconfigureerd die uitgevoerd wordt wanneer er log meldingen met “IWP.” gelogged worden. Deze configuratie bestaat uit drie onderdelen:

  1. Een Event and Action Configuration
  2. Een Event Action Mapping
  3. Een Geschedulde Workflow
  • In de Event and Action configuration moet een Action ID opgezet worden

Image Removed

Achter de action ID “Alarmmodule.alarm” hangt het volgende configuratie bestand.

...

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:

Image Added

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

Image Added

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

Image Added

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:

  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. 

Image Added

<?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>

...

 

Dit betekent dat er een eenmalige actie “Alarmmodule.alarm” zal worden uitgevoerd. Deze actie genereert een TAG “ALARM_MODULE”, die niet vaker dan 1 keer per 60 seconden mag worden gedraaid. Deze tijd kunnen we ook op 10 minuten of langer zetten. Dat betekend dat momenteel de log meldingen niet vaker dan 1 keer per minuut naar de Alarm module gestuurd worden.

...

...
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.
Image Added
Scheduled Tasks (fixed alert)
Here we link the workflow MC_SystemAlerter to the Event Action by means of a Tag. In the example 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>
Image Removed
Dit betekent dat wanneer er een log melding “IWP.*” voorbij komt de actie “Alarmmodule.alarm” zal worden uitgevoerd. Door het gebruik van de “*” hoef je niet alle individuele Event codes op te geven.
 
  • In de Scheduled Tasks geef je op dat de Systeem workflow “MC_SystemAlerter” moet draaien wanneer de TAG “ALARM_MODULE” gegenereerd wordt.
Image Removed
De eigenschappen van deze geschedulde taak zijn als volgt:
...
In the fixed alert scenario, the alert is entered as part of the taskproperties task properties of the scheduled MC_SystemAlerter task in <alarmDiagLine>. This can be used to send regular or one-off alerts and will probably mostly be used for testing purposes.
Image Added
 
 Code Block
xml
xml
<?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>Test IWP<description>IWP_0_TEST Alarm</description>
            <workflowId>MC_SystemAlerter</workflowId>
            <taskSelection>
                <scheduledTask><singleTask>
                    <schedulingPeriod>
                        <startDate>2010-12-20T13:28<time0>2011-08-23T09:05:00.000Z</startDate>
                        <endDate>3010-12-20T13:28:00.000Z</endDate>
   time0>
                 </schedulingPeriod>
                    <schedulingInterval unit="minute" multiplier="30"/></singleTask>
                </scheduledTask>
            </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"/>
					</alarmModuleAlert>
				</alerts>
			</mcSystemAlerter>
        </taskProperties>
    </task>
</taskList>

...
Scheduled Tasks (template alert)
The alert with the template is intended to be used as a suspended task which can be triggered through event-action configurations to trigger a single task, in that case, the log messages triggering the alert will be added to the task, if in the template, the following tags are used:
...
 Code Block
xml
xml
<?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-09-21T12:43                <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>
						<alarmDiagTemplateLine code="%EVENT_CODE%" description="%LOG%" source="%MC_ID%" level="1"/>
					</alarmModuleAlert>
				</alerts>
			</mcSystemAlerter>
        </taskProperties>
    </task>
</taskList>