ALERT Driver
2nd parameter "0" = off-duty, "1" = on-duty (optional, 1 by default)
Example:
DDE command:
ValidUser <Tab> Bob <Tab> 0
Command line:
ALERT ValidUser Bob Object: Send a message to the operators defined with the console attribute (see § 5.1 "User ").
Parameters:
1st parameter alphanumerical message to transmit 2nd parameter message identifier (optional) The message identifier is used to identify the message upon acknowledgment (AckConsole). If this identifier is defined, the message will only be transmitted during the on call period of the remote console, this message being ho ld until that period. If the identifier is not defined (no 2 nd parameter), the message is systematically transmitted, whether or not the remote console is on call.
Example:
DDE command:
SendConsole <Tab> Battery fault (message forced) SendConsole <Tab> Battery fault <Tab> A001 (message transmit if on call)
Command line:
ALERT SendConsole "Battery fault" (message forced) ALERT SendConsole "Battery fault" A001 (message transmit if on call)
Object: Acknowledgment of a console message
Parameters:
1st parameter identifier of message to acknowledge
Example:
DDE command:
AckConsole <Tab> A001
Command line:
ALERT AckConsole A001
Object: Reinitialize the DDE and OPC links
Appendix
Parameters:
none
Example:
DDE command:
RestoreLinks
Command line:
ALERT RestoreLinks
Object: Acknowledgment of a console message
Parameters:
1st parameter display mode "0" Hide the Alert window "1" Display of the Alert window with normal size "2" Display of the Alert window as icon "3" Display of the Alert window as maximized (full screen) "4" Alert window always visible (topmost window)
Example:
DDE command:
ShowWindow <Tab> 2
Command line:
ALERT ShowWindow (set the ALERT window as icon)
Object: Synthesizes and plays a message on the local station (require TTS option)
Parameters:
1st parameter message to synthesize
Example:
DDE command:
PlayText <Tab> Full alert
Command line:
ALERT PlayText "Full alert"
Object: Transmits a string command to the Message Processor
Parameters:
1st parameter message to process
Example:
DDE command:
SendDataToScript <Tab> AAAA XXX ZZZZ
Command line:
ALERT SendDataToScript "AAAA XXX ZZZZ"
Appendix
The message processor is a specific mediator module of Alert. Its function is to deal with messages for alarm information extraction and triggering of consequent treatments (alarm set/reset, acknowledgment). Messages are any character strings, alphanumerical or binary, that can be issued from different sources:
- Serial link Messages are issued from an external system through a serial link (printer output of an external system for example). Messages can be either asynchronously received or required by the message processor (polling sequence). Acknowledgment can be transmitted.
- TCP/IP Messages are issued from an external system through a TCP/IP network, in connected mode (TCP) or as datagram (UDP). Messages can be either asynchronously received or required by the message processor (polling sequence). Acknowledgme nt can be transmitted.
- Alarm Messages are transmitted in the content of a string variable declared as event in Alert (DDE or OPC tag or tag written by a mediator).
- Short Messages (SMS) Messages are received from remote GSM modems under the form of sh ort messages (SMS). Short messages can also be sent back for acknowledgment.
- API / Command line Messages are transmitted through the programming interface (API) of the software (function <AlertSendDataToScript> or <AlertSendMessageToScript>) or by a com mand line (command <SendDataToScript>, see § 8.15.17).
- Other Messages are cyclically extracted from a file, a data base, or a mail box (email). The message processor is able to simultaneously process messages from different o rigin. Each treatment is described by a prototype which include a set of parameters that are saved in an initialization file (file <prototype>.ini) associated with a script (file <prototype>.prg). The script is a Basic type program which is executed by the message processor and which is designed to extract significant information from the messages and to trig the consequent Alert treatments. The script functioning can take in account external setup data (lists and translations) that are specific to the inst allation and saved in a text file ( <prototype>.csv). These external
configuration data define the associations to perform between information extracted from the received messages and the parameters of alarms to trig (group to call, message to send, priority ...). If information contained in the messages are rich enough, the script can dynamically create the alarms from reported information and defined translations then set (or reset) them. In this case, it will not be necessary to declare alarms in Alert, e xcepted if complementary information is needed (recorded voice message or text file). If information that is contained in messages is not sufficient (transmission of just an event identifier for example), alarms to treat will have to be prior declared in Alert. The script just will have to set and reset the declared alarms following received messages. From the version 3/6 revision 1, a new feature of dynamic importation filters allows a great simplification and standardization of script writing by externali zing the model of dynamic creation of alarms under the form of filters that can be configured at the application level. The script only has to update some environment variables ("filter" variables) in function of received information then to call the funct ion "ProcessEvent" that will process the defined filters to automatically import the alarms notified in the received information.
By default the message processor is not activated. To activate message processor , open the "Options" dialog box (menu Configuration, command Options...) then on the "General" page, select the check box "Message processor activation" (on the bottom of the page), then validate by OK. When the message processor is activated, an entry in the Configuration menu gives access to its configuration (command Message processor...).
The dialog box for configuration of the message processor allows the definition of prototypes to activate and the configuration of each of these prototypes. To edit, add, import or remove a prototype, click on the button ">" on the right of the drop-down list Prototype, then, in the displayed contextual menu, select the corresponding command (respectively Edit..., Add..., Import... or Remove). The importation of a prototype consists in selection of the initialization file of the wanted prototype (<prototype>.pro). If this file is not located in the current application directory, it is automatically recopied with all associated files (<prototype>.prg and <prototype>.csv). During the creation of a prototype, the following parameters have to be defined:
- an identifier : short name used as radical for the configuration files (initialization, script and application data).
- a name : explicit name for designation of the prototype.
- the interface type used by the prototype : serial link, TCP/IP, short message, API or other (file, data base, email, ...).