Pelco Developer Network (PDN)

Alarm Array Configuration

Description:

The AlarmArrayConfiguration service allows multiple alarms to be evented from a single service. Each alarm in the service is individually identified by an alarmID, which in essence is an index into the array. Each AlarmArrayConfiguration service should be wrapped up by an AlarmArray device, much like an AlarmControl service is wrapped up by an Alarm device.

Use Case:

A user connects to a device, retrieves the current alarm states and configuration, resets the configuration, and subsequently sets the alarm state and configuration.

Target Namespace:

urn:schemas-pelco-com:service:AlarmArrayConfiguration:1

Transport protocol:
SOAP over HTTP
Operations:
  • GetAlarmStates
  • GetArraySize
  • GetConfiguration
  • ResetConfiguration
  • SetAlarmState
  • SetConfiguration

 For detailed information, please refer to the AlarmArrayConfiguration web service reference.

Operations Supported by Video Management Systems:

Products operating on Sarix firmware are not represented in the table below, as any products operating on Sarix firmare that support this web service support all of the operations within this service.

 

 

Product
Type
Product
GetAlarmStates
GetArraySize
GetConfiguration
ResetConfiguration
SetAlarmState
SetConfiguration
EnduraNET5402R      
VCD5202      
NSM5200      
SM5000
/ SM5200
      
Endura
Express
EE500      
Digital
Sentry
DS-SRV
/ DS-NVs
 XXX X
DXDX4700HD XXX X
DX4800HD XXX X

Introduction

For display purposes, there are several values associated with each alarm point consisting, but not limited to the following:

  • severity
  • friendlyName
  • location
  • comments

For AlarmControl services, these associated values are kept as attributes in the System Manager. The System Manager allows name/value pairs to be associated with devices by the UDN of the device. Since there is a one to one correspondence, one AlarmControl service to each Alarm device, this makes for a convenient mechanism to quickly retrieve data associated to alarms.

In the case of an alarm array, there is a single UDN, that of the AlarmArray device, with which to associate an attribute. For this reason, it is necessary to append the index (alarmID) of the alarm to the name of the value being stored as an attribute in the System Manager. For instance, the severity associated with alarm0 and alarm5 within an AlarmArray would be stored in the System Manager as attributes severity0 and severity5, respectively.

This service is written to allow for the reporting of mass changes of alarms with a single notification. The reporting mechanism, through the state variables (alarmStates and stateChanges) is meant to 'gather' changes into arrays that represent all alarms within the service.

In order for this service to work efficiently alarms should be gathered for reasonable periods of time before initiating a notification to all subscribers. This means that when a single alarm is triggered, it should be written to the alarmStates array, and the corresponding stateChanges should be set to "1". When an appropriate interval occurs, a notification should be formed if and only if there are any "1"s in the stateChanges string. Note that a notification should immediately be formed and sent if stateChanges is already one, then the new information can be saved.

If speed is of the essence, this service allows for reporting of a single alarm at a time as well. The first state variable indicates the alarmID of the first alarm being reported in the alarmStates string, which would only contain the state of the alarm in question.