|
This category contains EnterpriseSMS software modules that provide intelligent control over the processing of transactions within
EnterpriseSMS and, where multiple AMM are required, the synchronization of transactions between the multiple servers. Two modules make up this category.
The Alarm Management Module (AMM)
This module is the transaction processing engine of EnterpriseSMS. It processes transactions received from SIMs and stations in
accordance with rules established by data within the EnterpriseSMS database instance. (See Database Support Module for details.)
There are two types of transactions: Control and Command. Control transactions do not involve human activities and are automatically
implemented according to the pre-programmed functionality supported by the EnterpriseSMS software. Command transactions
are generated as a result of human intervention with the system. Nearly all command transactions arrive at the AMM from command
type user stations although subsystems also generate command transactions.
Understanding the distinction between command and control transactions is useful when planning or customizing a system response to a specific event. Planners usually define
pre-programmed actions (control transactions) to be activated by commands. Command type user stations either transmit custom
commands or standard commands from standard icons to cause a specific control response from the system.
All command type user stations and SIMs require network connection to an AMM for complete operation. The AMM receives transactions
from these modules, evaluates them, and reacts to them in accordance with the pre-established rules contained in the AMM
data files. The AMM and DSM work through their connection to ensure that the AMM data files are always 'in sync" with the
EnterpriseSMS data base instance. It is the AMM that sends to the DSM records of system activity for retention in the system event log.
Another important AMM function is the arbitration of requests for limited system resources or ownership of system data. For example,
only one operator may acknowledge or control an alarm event at a time. Acknowledgement is regulated by a first come, first serve rule.
However, knowledge about activity relating to the alarm event is available to all. Thus, the AMM implements commands relating to
alarm events and by applying rules for determining, in the case of multiple requests, which takes priority. The rules determining this
arbitration may be modified by changing data values in the EnterpriseSMS data base, and represents the core of control over event handling within EnterpriseSMS.
Another responsibility of AMM is to transmit commands to subsystems based on commands received. This is a contention
management function. Multiple users may issue commands to a single pan-tilt-zoom operator of a CCTV camera. Who gets control
and how is it released? This functionality is supported within AMM.
Thus, the functionality of AMM is essential to any system. In systems where there are multiple AMMs, some means must be
available to synchronize the data files which control the operation of the AMMs. This is required in the case of redundant systems.
The Command and Control Module (CCM)
The Command and Control Module (CCM) manages the relationship between multiple AMMs. Redundant and, in some cases,
host-subhost systems, require a CCM. The CCM is an additional layer of software that provides routine synchronization of AMM data
files which are not derived from the EnterpriseSMS data base instance which supports AMM. Usually, this is limited to current,
off-normal event state information and current transactions.
The CCM also controls the operation of multiple AMMs. It determines the need for an AMM, starts and stops AMMs, and
provides a means for users to control a multiple-AMM environment. In a redundant system, each server has an AMM and a CCM installed. The CCM controls the AMM.
Typical System Configurations
The typical system requires both the proper Database Support Module and an AMM for processing transactions. While other
modules are required for a minimally functional system, the other modules are not fixed and are subject to change or substitution
based on system needs. Thus, the AMM and DBM form a special case, and are often referred to as the host or host processes. Their
division into two independent categories of modules is due to their distinct nature; they are implemented as separate modules in order
to locate them in different environments, if necessary.
In typical system configurations (simplex, single server) both the AMM and DBM will be located on a single PC computer configured as
a server. This PC computer will usually be called the host or the server.
Our Definition: The Host or Host Processes are names applied to the two modules, the DSM and AMM of any system, taken in
combination. They are called the host or host processes because of their special role in servicing and routing transactions, managing
contention over limited resources, and maintaining control over all data.
The AMM and CCM are not available independently. The basic product packages System 1, System 5, and System 10 bundle an appropriate DSM and AMM, along with other essential components, to make a complete, workable basic system that may then be
further customized to meet specific user requirements. The DSM and AMM of a System 5 or basic System 10 must be on the same server.
|
