Fire-Lite IPDACT, Руководство по установке

Страница: 8 / 51

IPDACT Module - Introduction
I-5
Doc. Dm373-I
Rev. 2.0
since the last check) an alarm is generated. This is a 350 code alarm from
the Contact-ID protocol (
Communication trouble ) which is received in SwAut.
In order to prevent the Teldat VisorALARM from sending hundreds or
thousands of communication failure alarms when faced with a situation of
general failure of IP traffic reception, the device itself monitors the network
access through echo ICMP packets (ping) to a known address: if the echo
ICMP packets (ping) towards this address fail then a code 356 alarm is
generated from the Contact-ID protocol (
Loss of central polling ).
Apart from the above codes, the VisorALARM also generates others related
to network backup. For further information on this, please see manual Dm
298-I “VisorALARM Installation Manual”.
I - 1.2.2. Alarm sending
When the IPDACT has connectivity with the Teldat VisorALARM , the former
intercepts the telephone line and processes all the incoming and outgoing
calls taking place.
The supported alarm sending protocol is Contact-ID. This format sends
alarms through DTMF digits complying with the following format:
AAAA MM QEEE GG CCC S
where AAA is the client number, MM the type of message, Q an event
qualifier, EEE the type of alarm, GG the group or partition number, CCC the
zone number and lastly S is the frame validation digit.
When the panel opens to send an alarm, the IPDACT provides power and
emits the dialing tone. When the control panel dials the alarm center
telephone number, it issues the Contact-ID
handshake and receives the alarm
frame. From this point, the IPDACT sends this alarm to the VisorALARM .
The control panel is not given the frame sent acknowledgement ( kissoff ) until
the said acknowledgement is received from the Teldat VisorALARM . If the
IPDACT does not receive the acknowledgement within 2 seconds, this carries
on resending a configured number of times after which connection with the
Teldat
VisorALARM is assumed lost and the control panel sends the alarm
over the telephone line. From this point, the IPDACT tries to re-establish
communication with the
VisorALARM as previously described. In cases
where the network backup functionality is operative, a failure in sending an
alarm to the main
VisorALARM changes into an attempt to establish
communications with the backup VisorALARM and to send the alarms to this
second device. If this attempt also fails, then the control panel takes over the
process of sending the alarms.
It’s essential that the total time, in which the IPDACT deactivates in
cases where communications fail with both the IP receivers, is
greater than the control panel’s highest retry time.
The IP VisorALARM receiver on receiving an alarm from an IPDACT stores
this in a non-volatile internal memory. When the operation has successfully