# Presentation: 923619

## Training Booster for General UsersTom FiliaggiLate Winter, 2009

- GUARDIAN

- General User Alert Display Panel

**Training Booster for General Users****Tom Filiaggi****Late Winter, 2009**

## Agenda

**Operational Concept**
**Basic Components**
**Message components**
**Message Responses**
**Graphical User Interfaces**
**Popup GUI**
**Main GUI**
**Configuration GUI**
**What you ****can**** do**
**Configuration Summary**
**Script and command line usage**
**What you ****cannot**** do**
**Forced Responses**

**Notes:**
Remove Note?

## Operational Concept

- Guardian auto-starts upon login to the AWIPS LX and XT machine desktops
- Guardian’s presence is *persistent* and *unobtrusive* (depending on desktop configuration)
- Various AWIPS Software sends various messages to Guardian, using standard AWIPS Inter-process Communication methods
- Guardian responds, based on message attributes sent and current response configuration
- The configuration has a machine default, but can be customized
- By each individual user
- By Task
- The customization can control many aspects of Guardian’s responses

**Notes:**
Remove Note?

## Text of Message
Text composed by the sender application
Source of Message
Sender application
Must be defined in Guardian
Priority of Message
Determined by sender application
The goal is to have both the sender and receiver define Priorities the same.  This is impossible, but the closer we get, the more mutual understanding we have.
Category of Message
Determined by sender application
Determines Text Section
Some special Categories:
LOCAL	Response only for one machine
MONITOR	Response targeted to a Monitor 	Button
GDN_ADMIN	Internally used by Guardian for 	administrative purposes
Optional: Machine specific
Can send a message to a single, specified machine.

- Text composed by the sender application
**Source** of Message
- Sender application
- Must be defined in Guardian
**Priority** of Message
- Determined by sender application
- The goal is to have both the sender and receiver define Priorities the same.  This is impossible, but the closer we get, the more mutual understanding we have.
**Category** of Message
- Determined by sender application
- Determines Text Section
- Some special Categories:
**LOCAL**	Response only for one machine
**MONITOR**	Response targeted to a Monitor 	Button
**GDN_ADMIN****	**Internally used by Guardian for 	administrative purposes
- Optional: Machine specific
- Can send a message to a single, specified machine.

**Basic Components:****Message Components**

| Priority Definitions |  |
| --- | --- |
| Priority | Definition |
| 0 | Critical: Information that must be acted upon immediately and must not be ignored!  This would include “emergency” information. |
| 1 | Significant: Due to significant importance, the software developer suggests the use of a pop-up, or some other significant emphasis.  This may not be an “emergency”, but it still very important. |
| 2 | In between Medium and Significant – perhaps information that is ‘WFO-required’ or linked to policy requirements. |
| 3 | Medium: Fairly important, but not crucial. |
| 4 | A step above informational.  ‘Suggested reading’, but not ‘required’. |
| 5 | Informational: Perhaps not even important enough for a notice of any kind.  Informational. |
| NOTE:
Priorities may have specific uses and definitions, when relative to a MONITOR, which do not conform to the definitions above! |  |

## Basic Components:Message Responses

**Text**
- In Text Sections of GUI
- Configurable Text Section Layout
- Background and foreground colors
- Blink: user defined duration
**Pop-up**
- Sometimes called “red-banners” (but they don’t have to be red anymore)
- Background and foreground colors
- Image: ie: gif, bitmap (default is Guardian logo)
- Small vs. large pop-up
**Audio**
- System beep
- Specified sound file
- User defined repetition duration
**Action**
- Launch an executable (with standard AWIPS environment)

**Notes:**
Remove Note?

## Basic Components:User Interfaces

**Main GUI**

**Config GUI**

**Pop-up GUI**

## Graphical User Interfaces:Pop-up GUI

**Pop-up size*******
**Normal**
**expanded**
**Text**** ****of Message**
**May contain *******
**Source**
**Priority**
**Category**
**Log will show details**
**Time-stamp**
**Image*******
**Default is Guardian logo**
**Taking cursor focus**
**This is controlled by the desktop.  KDE mouse control should be set to:**
**Focus Under Mouse ****OR**
**Focus Strictly Under Mouse**
**Acknowledgement**
**Last message**
**All # (with confirmation)**
******* = configurable**

**Notes:**
Remove Note?

## Graphical User Interfaces:Main GUI

## Graphical User Interfaces:Config GUI

## What You Can Do: Summary

- Almost all of Guardian’s responses are under **your** control:
- Text: blink, colors, include message attributes, targeted Text Section of Main GUI
- Pop-up: colors, size, embedded image, include message attributes
- Audio: duration, default system beep, custom audio file
- Action: anything in the environment’s command path
- But these responses are predicated upon the message attributes sent from the client applications:
- Priority
- Source
- Category
- Some limitations:
- Both software developers and Guardian users need to have the same definitions of the Priorities to help with more useful configurations
- The old ANNOUNCER is still only one Source in Guardian, though it should be eliminated to allow all of its client applications to become Guardian clients instead.  Thus, the ANNOUNCER is a sort of bottleneck.
- The full suite of Guardian capabilities has yet to be realized in operations.  Task-based configurations would likely be impossible until the ANNOUNCER is removed

**Notes:**
Remove Note?

## What You Can Do: Local Apps

- Currently, the biggest strength of Guardian is to allow the WFOs to set up your own messages and responses
- Examples: NIMNAT, Meso alarms, text triggers, forecast reminders
- Can create your own Sources and Categories, if need be
- Command line, to send a message to Guardian:
**sendMsgToGuardian *****source priority category “text” (local machine)***
***local machine*** is optional, do not use parentheses
***text*** should be encapsulated in quotes
***source*** and ***categor***y must be defined in Guardian
***priority*** must have an integer value from 0 to 5
- Usage in a script, must have the proper AWIPS environment defined.  Here is an example of defining the proper environment in a tcsh script:
**#!/bin/tcsh**
**setenv FXA_HOME /awips/fxa**
**source $FXA_HOME/bin/readenv.csh**
**$FXA_HOME/bin/sendMsgToGuardian *****args***** **

**Notes:**
Remove Note?

## What You Cannot Do

- Forced Responses
- There are some situations where your current Guardian configuration can be overridden.
- Those in your office with ‘fxa’ access can define Forced Responses in Guardian.
- This can be applied to all potential responses to a given message, or only a few (or one)
- Details for overriding are on the GUARDIAN web page, though general users will not need to know the details

**Notes:**
Remove Note?

## What You Cannot Do

- The sender of the message cannot dictate a response.  The response is under the control of the receiver.
- ie: The sender cannot dictate that a certain sound file gets played
- ie: The sender cannot dictate that a pop-up gets presented
- etc
- You cannot turn Guardian completely off (though you can configure it to have no responses at all, but this is not recommended).
- You cannot minimize the Main GUI nor lower it in the window stack order.

**Notes:**
Remove Note?

## 
Main Developers
Tom Filiaggi		- MDL: Lead
	Tom.Filiaggi@noaa.gov

**Main Developers**
**Tom Filiaggi****	****	****- MDL: Lead**
- 	Tom.Filiaggi@noaa.gov

**Guardian Responsible Individuals**

## High Level Data Flow

## Forced Responses

**If the following file does not exist, create it**
**cd /data/fxa/workFiles/Guardian**
**touch GuardianForced.txt**
**chmod 644 GuardianForced.txt**
**Entries in the file should look like this:**
**SourceKey |  Priority# | Category | simple_text_match | SettingsList**
- All pipes are required, whether they contain any text or not
*SourceKey* and *Priority#* are required
*simple_text_string* does **not** represent a ‘regular expression’ and should **not** be encapsulated in quotes
*SettingsLis*t is one or more configuration settings, separated by commas, with the following format:
*attribute*:*value*
- Examples
**popup:1,background:yellow,text:0**
**Full details are available on the Guardian web page in the document “System Manager Overrides”**

***SourceKey |  Priority# | Category | simple_text_match | SettingsList***

**Notes:**
Remove Note?