Admin Alarm Service

Distributed Network Architecture
ALARM SERVICE
(ALSERV)
ADMINISTRATORS GUIDE
PROPRIETARY INFORMATION
THE CONTENT OF THIS DOCUMENT IS PROPRIETARY INFORMATION OF
INSTEP SOFTWARE,LLC (ISS) AND SHALL NOT BE RELEASED IN ANY FORM TO
ANY THIRD PARTY WITHOUT THE EXPRESS WRITTEN CONSENT OF ISS.
200 W. Jackson Blvd.

28th Floor
www.instepsoftware.com Chicago, IL 60606
T: 312.894.7837/ F: 312.894.7840
i
User Welcome
Dear eDNA User,
Thank you for selecting the eDNA Alarm Service from InStep Software, LLC to fulfill your real
time computing needs.
We appreciate your business and are confident that you will be fully satisfied. Should you have
any comments on ways we could improve the eDNA Alarm Service, we would appreciate hearing
from you.
Thank you once again.
The ISS eDNA Team
How to Contact Us
Please feel free to contact your ISS representative at any time using the contact
information provided:
General contact information
Phone 312.894.7837 InStep Main

Fax 312.894.7840
Internet support@instepsoftware.com
WWW www.instepsoftware.com
US Mail 200 W. Jackson Blvd., 28th Floor
Chicago, IL 60606
ii
eDNA Alarm Service Administrators Guide
Rights to Use
eDNA Alarm Service
The software described in this document is furnished under a license agreement

and may be used only in accordance with the terms of the agreement.
This document may not, in whole, or in part, be copied, photocopied, reproduced,

translated, or reduced to any electronic medium or machine readable form without prior
consent in writing from InStep Software, LLC.
Every effort has been made to ensure the accuracy of this document. However, InStep
Software, LLC makes no warranties with respect to this documentation and disclaims any
implied warranties of merchantability and fitness for a particular purpose. InStep
Software shall not be liable for any errors or for incidental or consequential damages in
connection with the furnishing, performance, or use of this manual or the examples
herein. The information in this document is subject to change without notice.
Copyright 2007 InStep Software LLC, or its subsidiaries.

All rights are reserved.
Trademarks:
Windows, Windows XP, Windows 2000, Windows NT, Windows 98, Windows 95,
Microsoft Office, Access, Excel, and Word are registered trademarks of the Microsoft
Corporation.
Other product and brand names may be trademarks or registered trademarks of their
respective companies and remain the sole property of their respective manufacturer. All
rights are reserved.
For information regarding duplication and additional use of this document contact:
InStep Software, LLC

200 W. Jackson Blvd., 28th Floor, Chicago, Illinois 60606
312.894.7837
InStep Software, LLC iii

The content of this document is the proprietary information of InStep Software, LLC (ISS) and shall not be released in any form to
any third party without the express written consent of ISS
Contents
1.0 INTRODUCTION.................................................................................... 1
1.1 Alarm Service Documentation ................................................................................................ 1
2.0 ALARM SERVICE FORM AND FUNCTION ....................................... 2
2.1. Overview .................................................................................................................................. 2
3.0 ALARM SERVICE ADMINISTRATION .............................................. 3
3.1. Overview .................................................................................................................................. 3
3.2. Ancillary Services .................................................................................................................... 6
3.3 Files .......................................................................................................................................... 7
3.4. Starting and Stopping the Service .......................................................................................... 10
3.5. Service Screens....................................................................................................................... 11
3.6 Recovery ................................................................................................................................. 14
3.7. Maintenance ........................................................................................................................... 14
InStep Software, LLC iv

1.0 INTRODUCTION
The Distributed Network Architecture (eDNA) Alarm Service (AlServ) maintains
lists of data points in alarm that can be provided for viewing and acting upon. The
Alarm Service typically functions in conjunction with the DNA Alarm Client (see
document DNA Alarm Client Users Guide (“User Alarm Client.doc”).
Each point in your eDNA system has a value, time and status field. The status field
indicates the condition of the value. It indicates conditions like the reliability of the
value, if the value is outside of normal (or safe) operating limits and the like.
The Real-Time and Alarm Services work together to maintain point status
information. The Real-Time Service assigns and maintains status for all of its
points. The Alarm Service receives status changes from the Real-Time Service. The
eDNA Alarm Service maintains lists of status information for DNA points. System
users on the enterprise are able to view the alarm information. Operators and
administrators can acknowledge and clear the alarms. Various options are available
for displaying and categorizing alarms. The Alarm Service provides this
categorization.
1.1 Alarm Service Documentation

The Alarm Service (AlServ) Administrators Guide is intended to help
administrators start, stop, and maintain the Alarm Service. This section covers the
arrangement of the document and how to get help.
1.1.1 Layout
This document is divided into three major sections, In Introduction, Alarm Service
Form and Function, and Alarm Service Administration.
Is this section and contains information

Introduction
about the document.
Alarm Service Form and Function Explains Alarm Service functionality
Discusses direct administrative interaction
Alarm Service Administration
with the service.
1
2.0 ALARM SERVICE FORM AND FUNCTION
2.1. Overview
The Distributed Network Architecture (eDNA) Alarm Service acts as a bulletin
board for Real-Time Service point alarm information. It is a convenient place for
Real-Time Services to post their point’s status and state information. An Alarm
Service can receive information from many Real-Time Services, but a Real-Time
Service can only send information to one Alarm Service.
Typically, a site or system has only a single Alarm Service and all of the Real-Time
Services in that system send alarms to the Alarm Service. Users wanting to view all
of the alarms in a system need only look at a single Alarm Service. The majority of
functionality associated with DNA alarms is accomplished within Real-Time
Services. The Alarm Service simply maintains lists for convenience.
If a Real-Time Service is to process acknowledgements from operators interacting

with point status, the Real-Time Service must have an associated Alarm Service.
Real-Time Services that do not have associated Alarm Services maintain point
status but do not:
• maintain point state

• process acknowledgements from operators.
A Real-Time Service is associated with an Alarm Service when the name of the
Alarm Service is added to the Real-Time Service’s Service Configuration File. For
more information on Real-Time Service’s Service Configuration Files, refer to the
administrator documentation for that Real-Time Service.
The primary client tools used to view and interact with the Alarm Service are:
• AlarmView
• AlarmClient.
AlarmView allows users to view lists of alarms but does not allow any interaction
(i.e. acknowledgement).
AlarmClient allows operators to both view and interact with alarms.
2
3.0 ALARM SERVICE ADMINISTRATION
3.1. Overview
The Alarm Service supports the alarm function of Real-Time Services in much the
same way a History Service supports the archival function of Real-Time Services.
The Alarm Service maintains lists of alarms that it receives from Real-Time
Services.
3.1.1. Basic Concepts

3.1.1.1. Real-Time Services, Configuration Manager and the Alarm Service
eDNA is a distributed system. Functional responsibilities are shared among

multiple processes often running on multiple systems. Alarm processing is
distributed across Real-Time Services, the Configuration Manager, and the
Alarm Service. Each point identified throughout an eDNA system is configured
in a Configuration Manager. The Configuration Manager maintains information
about the point’s attributes, including alarm information. Alarm range level and
alarm priority are set using the Configuration Manager. The Configuration
Manager sends point configurations to Real-Time Services.
Real-Time Services collect (or generate), analyze, and maintain current values
for points throughout the eDNA system.
After collecting real-time values, the Real-Time Service uses a combination of

configuration information and value information from the interfacing system to set
alarm conditions. The value and status are added to the Real-Time Service’s table
of current values. The Real-Time Service also sends the value and status to the
eDNA Alarm Service.
The Alarm Service is passive - it does not collect information. Point status
information is sent to the Alarm Service by Real-Time Services. The Alarm
Service receives value and status information, logs the information and adds the
information to tables of current and history alarms. The Alarm Service also
receives and maintains operator acknowledgments received and processed by
the Real-Time Service.
3
3.1.1.2. Alarm Status and State
An eDNA real-time point’s alarm condition is a combination of two values, the

status and state.
Alarm Status refers to the disposition of the alarming point and is identical to the
status assigned by the Real-Time Service. It provides additional information about a
point’s values, like the value’s reliability and alarm level range.
Alarm State describes the condition of a point as it is being monitored in the Alarm
Service. The alarm state is determined as a combination of status and
acknowledgment by an operator or administrator.
Monitored data points have five possible alarm states:
1. Not in alarm – the status of the point indicates no alarm;
2. In alarm and unacknowledged – the real-time status of the point indicates an

alarm and the point has yet to be acknowledged by an operator or
administrator;
3. In alarm and acknowledged – the real-time status of the point indicates an

alarm and the point has been acknowledged by an operator or administrator;
4. Alarm reset and acknowledged – the real-time status was in alarm but has
reset and the point has been acknowledged by an operator or administrator;
and
5. Alarm reset and not acknowledged – the real-time status was in alarm but has
reset and the point has not been acknowledged by an operator or
administrator.
States 4 and 5 are optional states and will be discussed later in this section.
InStep Software, LLC 4

3.1.1.3. Latching Alarms
The eDNA alarm processing can be handled in either of two ways:
1. latched
2. unlatched.
When alarms are processed as latched, resets require operator acknowledgement

before they can be cleared out of the system.
In unlatched operation, alarms are ready to be cleared as soon as they reset; no

acknowledgement is required for resets.
In order for the Alarm Service to process alarms correctly, it must know which
method is to be used. Administrators configure the method in the Service
Configuration File by including or excluding the ACKNOWLEDGE_RESETS
parameter.
3.1.2. Alarm Lists
The alarm service maintains three primary lists of alarms:
1. Current
2. History
3. Cutout.
Two secondary lists are:
1. System Specific Alarms

2. Prioritized Alarms.
3.1.2.1. Current Alarm List
The Current Alarm List is a list of all of the current points that have entered
alarm and have not been acknowledged and reset.
3.1.2.2. History Alarm List
The Recent History Alarm List maintains a list of the most recent 1000 alarms.
The Alarm Service’s History Alarm List is not intended to be a permanent
archive. Alarm information is logged along with other point information in the
DNA History Service.

3.1.2.3. Cutout Alarm List
Operators and administrators choosing to ignore certain alarms can add those
alarms to the Cutout Alarm List. When a point goes to the Cutout Alarm List, its
alarm information is no longer available on any of the other lists.
3.1.2.4. System Specific Alarm List
The System Specific Alarm List maintains a list of all current alarms organized
by system. Typically the system field is not used in DNA installations, so this
List is not often used.
3.1.2.5. Prioritized Alarm List
The Prioritized Alarm List displays current alarms organized by priority rather
than by the time they entered the system.
3.2. Ancillary Services

The Alarm Service relies on a number of other services for successful operation,
primarily Real-Time Services.
Other ancillary services include the Boot Operate Supervisory Service (BOSS)
and the Services Directory.
• When it is desirable to control a service remotely, the service can be started

up under a BOSS.
• The Services Directory is the DNA "yellow pages" of services. In order for
applications to communicate with the Alarm Service, it must be registered
with the Services Directory.

3.3 Files
The Alarm Service relies on two configuration files and creates two data files.
The configuration files are:
1. Service Configuration File AlServ.cfg
2. The local configuration file CONFIG.DAT.
The two data files are:
1. ALARM.REC
2. IGNORE.REC.
3.3.1.1. Service Configuration File (AlServ.CFG)
The service configuration file gives the Alarm Service all of the information it
needs to start. The service configuration file must be located in the same directory
from which the service process is launched. The administrator is responsible for
generating and maintaining the service configuration file. Instructions for a service
configuration file are given on a single line. They consist of a keyword followed by
a separator (space or equal sign) and a list of zero or more parameters. Parameters
are distinguished by separators (spaces or comma's). The pound sign (#) keyword
indicates a comment.
The allowable keywords are:
KEYWORD DESCRIPTION
SERVICE The eDNA site.service name of this service
SECURITY_SERVICE The eDNA site.service name of security service
SECURITY_APPLICATION The eDNA site.security, security application name
ACKNOWLEDGE_RESETS Requires acknowledgement of alarm resets. Default-
AutoAcknowledge
AUTO_CLEAR Service automatically clears reset alarms
ACKNOWLEDGE_ALARMS Requires acknowledgement of alarm. Default-
AutoAcknoweldge
USER_ID The user name to use for auto acknowledging
SERVICE_IP_ADDRESS The IP address
SERVICE_PORT The IP port
FIREWALL_IP_ADDRESS The firewall IP address
EVENT_LOG_SERVICE The eDNA site.service name of the event service
ADMIN_LIST_FILE The file name for the Alarm Super Users

WRITE_TO_TRACE_FILE Output to trace file

ALARM_LIST_SIZE The size of the alarm list (default = 5000)
HISTORY_LIST_SIZE The size of the history list (default = 10000)
NOTE: SERVICE, MAP_PATH and POINT_FILE are required keywords.

The following is a typical example of an Alarm Service, Service Configuration File.
# AlServ Example Config File
SERVICE DEMO.ALARM
SECURITY_SERVICE DEMO.SEC URITY
SECURITY_APPLICATION ALARM
ACKNOWLEDGE_RESETS
3.3.1.2. Local Configuration File (CONFIG.DAT)
The Alarm Service maintains a Local Configuration File, CONFIG.DAT. Users do

not interact directly with the Local Configuration File. The Alarm Service
manipulates this configuration file based on configuration messages sent to it.
3.3.1.3. Data Files (ALARM.REC and IGNORE.REC)
The Alarm Service maintains two data files for tracking current, historical and
cutout alarms. These files cannot be manipulated manually. They are managed
by the Alarm Service.
3.3.1.4. List Sizes
The Alarm Service maintains internal historical lists of current and historical
alarms. The length of these lists can be adjusted by using the configuration
parameters: ALARM_LIST_SIZE and HISTORY_LIST_SIZE. The following
table shows default, minimum and maximum lengths for each.
Default Minimum Maximum

ALARM_LIST_SIZE 5000 5000 50000
HISTORY_LIST_SIZE 10000 10000 65000

3.4. Starting and Stopping the Service
3.4.1. Starting
Before starting the Alarm Service, verify that all of the required files exist in the
correct locations.
3.4.1.1. Installing a New Alarm Service
If installing a new Alarm Service you need the application (AlServ.EXE) and the
Service Configuration File (AlServ.CFG). For information on creating a service
configuration file, see Service Configuration File (AlServ.CFG). You should not
have the Local Configuration File (CONFIG.DAT) or either of the data files
(ALARMS.REC and IGNORE.REC). The Alarm Service will create these files
during normal operation.
3.4.1.2. Starting an Existing Alarm Service
If you are starting an existing Alarm Service you may want the Local Configuration
File and the data files. None of these files are required, but they maintain
information previously set in the Service.
The Alarm Service can be started or caused to display information about its Service
Configuration File.
• To start the Alarm Service, simply enter the program name (AlServ) without
command line parameters.
• To cause the Service to display its Service Configuration File structure

information, enter the program name followed by a trailing question mark
(AlServ ?).
When the Alarm Service is started with a trailing question mark, it prints the
following:
The following are the accepted keywords for the configuration File for this service. Keywords prefaced
with a '*' are required to be present. The configuration file is named: [radserv.cfg].
*SERVICE The eDNA site.service name of this service

*SECURITY_SERVICE The eDNA site.service name of security service
*SECURITY_APPLICATION The eDNA security application
ACKNOWLEDGE_RESETS Requires Acknowledgement of alarm resets

3.4.2. Stopping
The Alarm Service’s data files are sensitive to unexpected disruption. It is important
that administrators assure the Alarm Service is only shutdown in an orderly fashion.
In the event of a disorderly shutdown the Alarm Service will recover, as described
in Section 3.6 Recovery.
Orderly shutdowns can be performed from a BOSS or at the console.
To stop the Alarm Service through the BOSS, use the BOSS client, BOSSCfg. In
the Control Service menu, select STOP.
To stop the Alarm Service from the console, return it to its main screen. The Alarm
Service will return to its main screen when you press function key 1, F1 . At the
main screen, type STOP. The Alarm Service will close its files, disconnect from
other services, and terminate.
3.5. Service Screens

When running, the Alarm Service displays information about itself through a series
of screens.
The Alarm Service has five screens. All of the Alarm Service’s screens have a
common header displaying the Service's most basic information. The header
contains information describing the service, the service name, and the service start
time.
A typical header will look like the following:
Distributed Network Architecture - Network Solutions (TM)

Alarm Service V ersion 2.12
InStep Software, LLC 312.894.7870
DNA Name: DNA_DEMO.ALARM Start: Fri Jul 02 10:45:54 1999

3.5.1. Main Screen
On startup, the service goes to the Main Screen. You can access all other screens
from the main screen. If you are standing at the server, you can stop the service
from the Main Screen by typing STOP.
Information on the Main Screen includes the number of messages received by the
service, the number of messages sent by the service, and the name of the associated
Security Service. The Main Screen also contains instructions for accessing the other
screens.
A typical Main Screen appears as follows:
Messages In: 1461

Messages Out: 1461
Security Service: DEMO.SECURITY
F2: View System Messages

F3: View Net Messages
F4: View Trace of Program
F5: View Alarm Messages
'STOP' to exit
3.5.2. System Messages
The System Messages Screen is accessed from the Main Screen by pressing
Function Key 2 (F2).
The System Messages Screen displays message text lines deemed important to
the service. Information messages are displayed in low intensity (dull) white,
reset messages are displayed in light blue, warning messages are displayed in
yellow, and error messages are displayed in red. If the messages have scrolled
off the screen, you can use the Page-Up and Page-Down keys to view the 1000
most recent messages.

3.5.3. Network Messages

The Network Messages Screen in accessed from the Main Screen by Pressing
The Network Messages Screen displays message text lines that relate to network
communications. The colors of the messages are the same as for System Messages.
3.5.4. Trace Messages

The Trace Messages Screen in accessed from the Main Screen by Pressing Function
Key 4 (F4).
The Trace Messages Screen displays message text lines that provide programmatic
information. Often the Trace Messages mimic the System Messages and provide
more information. The Trace Message screen contains numerous information
messages including messages indicating the points added, removed, or updated in
the service. The colors of the messages are the same as
for System Messages.
3.5.5. Alarm Messages

The Alarm Messages Screen is accessed from the Main Screen by pressing
The Alarm Messages Screen displays message text lines showing a trace of alarms
received. The colors of this screen are the same as for System Messages.

3.6 Recovery
If the Alarm Service becomes corrupted or its files get damaged, you will have to
restore the application (AlServ.EXE) and Service Configuration File (AlServ.CFG).
It is a recommended that you maintain copies of these files in a safe location.
If the system has become corrupted, destroy the Local Configuration File
(CONFIG.DAT) and data files (ALARMS.REC and IGNORE.REC).
The Alarm Service will automatically re-build the files.
3.7. Maintenance
The Alarm Service requires no formal, routine maintenance. As with all eDNA
Services, an administrator should periodically check the service screens for error
messages and verify that the current alarms are current.
It is recommended that the administrator keep copies of the application

(AlServ.EXE), the Service Configuration File (AlServ.CFG), and, optionally,
the Local Configuration File (CONFIG.DAT).


Admin Alarm Service

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Admin Alarm Service

Uploaded by

Copyright:

Available Formats

Distributed Network Architecture

200 W. Jackson Blvd.

Thank you once again.

The ISS eDNA Team

General contact information

Phone 312.894.7837 InStep Main

The software described in this document is furnished under a license agreement

This document may not, in whole, or in part, be copied, photocopied, reproduced,

Copyright 2007 InStep Software LLC, or its subsidiaries.

InStep Software, LLC

InStep Software, LLC iii

InStep Software, LLC iv

1.1 Alarm Service Documentation

Is this section and contains information

If a Real-Time Service is to process acknowledgements from operators interacting

• maintain point state

AlarmClient allows operators to both view and interact with alarms.

3.1.1. Basic Concepts

eDNA is a distributed system. Functional responsibilities are shared among

After collecting real-time values, the Real-Time Service uses a combination of

3.1.1.2. Alarm Status and State

An eDNA real-time point’s alarm condition is a combination of two values, the

Monitored data points have five possible alarm states:

1. Not in alarm – the status of the point indicates no alarm;

2. In alarm and unacknowledged – the real-time status of the point indicates an

3. In alarm and acknowledged – the real-time status of the point indicates an

InStep Software, LLC 4

3.1.1.3. Latching Alarms

The eDNA alarm processing can be handled in either of two ways:

When alarms are processed as latched, resets require operator acknowledgement

In unlatched operation, alarms are ready to be cleared as soon as they reset; no

3.1.2. Alarm Lists

The alarm service maintains three primary lists of alarms:

Two secondary lists are:

1. System Specific Alarms

3.1.2.1. Current Alarm List

3.1.2.2. History Alarm List

InStep Software, LLC 5

3.1.2.3. Cutout Alarm List

3.1.2.4. System Specific Alarm List

3.1.2.5. Prioritized Alarm List

3.2. Ancillary Services

• When it is desirable to control a service remotely, the service can be started

InStep Software, LLC 6

1. Service Configuration File AlServ.cfg

2. The local configuration file CONFIG.DAT.

The two data files are:

3.3.1.1. Service Configuration File (AlServ.CFG)

The allowable keywords are:

InStep Software, LLC 7

WRITE_TO_TRACE_FILE Output to trace file

InStep Software, LLC 8

The following is a typical example of an Alarm Service, Service Configuration File.

# AlServ Example Config File

3.3.1.2. Local Configuration File (CONFIG.DAT)

The Alarm Service maintains a Local Configuration File, CONFIG.DAT. Users do

3.3.1.3. Data Files (ALARM.REC and IGNORE.REC)

3.3.1.4. List Sizes

Default Minimum Maximum

InStep Software, LLC 9

3.4. Starting and Stopping the Service

3.4.1.1. Installing a New Alarm Service

3.4.1.2. Starting an Existing Alarm Service

• To cause the Service to display its Service Configuration File structure