Protocolo Contact ID

O Contact ID ´e um protocolo de comunica¸c˜ao digital amplamente utilizado em sis- temas eletrˆonicos de seguran¸ca monitorados. Ele ´e um protocolo padr˜ao de mercado, adotado por muitos fabricantes para prover a compatibilidade de seus equipamentos com equipamentos de terceiros (SOUSA et al., 2009a). Foi desenvolvido integralmente pelo Grupo Ademco e seu padr˜ao documentado pela SIA - Security Industry Association (SIA, 1999). Para transmitir mensagens de alarme, via linha telefˆonica convencional, o Contact ID utiliza o padr˜ao de tons DTMF - Dual Tone MultiFrequential (SCHULZRINNE, 2006). S˜ao utilizados pares de tons DTMF (baixos e altos) para representar um determinado d´ı- gito que, no padr˜ao do protocolo, pode variar entre 0 e 9, e B e F (d´ıgitos hexadecimais). A tabela 2.2 apresenta o conjunto dos tons e respectivos valores utilizados pelo protocolo. Os pares de tons s˜ao sincronizados por um circuito espec´ıfico, como o TCM 5087 Tone Encoder (TEXAS, 2009), gerando frequˆencias que correspondem a respectivos valores. A composi¸c˜ao de uma mensagem no formato do protocolo Contact ID ´e dada por:

ACCT QZXY GG CCC

onde, ACCT identifica o n´umero da conta (ou cliente) que originou a mensagem, Q identifica o tipo de evento (1: novo evento ou abertura, 3: restaura¸c˜ao ou fechamento, 6: reportagem), ZXY identifica o c´odigo do evento (dentre uma lista de 631 eventos), GG identifica o grupo ou parti¸c˜ao monitorada pela central de alarmes, e CCC identifica a zona de prote¸c˜ao ou usu´ario que originou o evento. Al´em dos campos descritos, existem

Tabela 2.2: Pares de tons DTMF e respectivos valores utilizados pelo Contact ID D´ıgito Tons baixos Tons altos Valor

0 941Hz 1336Hz 10 1 697Hz 1209Hz 1 2 697Hz 1336Hz 2 3 697Hz 1477Hz 3 4 770Hz 1209Hz 4 5 770Hz 1336Hz 5 6 770Hz 1477Hz 6 7 852Hz 1209Hz 7 8 852Hz 1336Hz 8 9 852Hz 1477Hz 9 B 941Hz 1209Hz 11 C 941Hz 1477Hz 12 D 697Hz 1633Hz 13 E 770Hz 1633Hz 14 F 852Hz 1633Hz 15

ainda valores impl´ıcitos que comp˜oem uma mensagem em Contact ID, como por exemplo, a data e a hora em que o evento ocorreu. Uma lista completa com a descri¸c˜ao de todos os c´odigos de eventos pode ser encontrada na documenta¸c˜ao do protocolo (SIA, 1999).

A seguir s˜ao apresentados alguns exemplos de mensagens em Contact ID:

Exemplo 1) A conta 1234 est´a reportando uma mensagem de Viola¸c˜ao de Per´ımetro na zona 4 da parti¸c˜ao 1.

Mensagem: 1234 1131 01 004

1234 = n´umero da conta (cliente)

1131 = tipo de evento (1) que caracteriza uma abertura (novo evento), seguido do c´odigo do evento de Viola¸c˜ao de Per´ımetro (131) 01 = n´umero da parti¸c˜ao (1)

004 = n´umero da zona (borne)

No exemplo 1, o tipo de evento 1 indica que a zona de prote¸c˜ao 4 est´a com o circuito aberto, ou seja, que o sensor fisicamente ligado ao conector da respectiva zona detectou uma mudan¸ca de estado. Assim, a mensagem em Contact ID foi formulada com base na

programa¸c˜ao da central, onde foi definida a zona 4 como uma zona de per´ımetro.

Exemplo 2) A conta 1234 est´a reportando uma mensagem sobre restaura¸c˜ao de Vio- la¸c˜ao de Per´ımetro na zona 4 da parti¸c˜ao 1.

Mensagem: 1234 3131 01 004

No exemplo 2, o tipo de evento 3 (que precede o c´odigo do evento 131) indica que a zona de prote¸c˜ao 4 passou de circuito aberto para fechado, ou seja, que o sensor fisicamente ligado ao conector da respectiva zona foi restaurado. A restaura¸c˜ao da zona foi a ´unica mudan¸ca (diferen¸ca) relacionada ao exemplo anterior.

O processo de comunica¸c˜ao, quando ´e realizado via linha telefˆonica convencional, segue um conjunto de regras e conven¸c˜oes caracter´ısticas do protocolo Contact ID. S˜ao definidos tons espec´ıficos de uma sess˜ao de comunica¸c˜ao, controle de erros de transmiss˜ao, intervalos de tempo entre tons, tolerˆancias a erros de frequˆencia e de tempo, e sinais espec´ıficos para a valida¸c˜ao de mensagens. Uma sess˜ao de comunica¸c˜ao do transmissor (central de alarmes) para o receptor (equipamento da empresa de vigilˆancia) ´e composta pelos seguintes elementos b´asicos:

ˆ Handshake Tone: ´e um tom produzido pelo receptor com o prop´osito de sinalizar ao transmissor que o canal de comunica¸c˜ao est´a pronto. A sinaliza¸c˜ao deve demorar um intervalo de pelo menos 0.5 segundos, mas normalmente n˜ao deve ser superior a 2.0 segundos. Este tempo possibilita o chaveamento de conex˜ao de rede do sistema de telefonia antes que a transmiss˜ao comece (figura 2.10). A sequˆencia de tons do Handshake, consiste de uma rajada6 de 1400 Hz (± 3%) com uma dura¸c˜ao de 100 ms (± 5%), uma pausa de 100 ms (± 5%) e uma rajada de 2300 Hz (± 3%) com uma dura¸c˜ao de 100 ms (± 5%). Os transmissores aceitar˜ao um erro de frequˆencia de 5% para compatibilidade com receptores mais antigos.

ˆ Kissoff Tone (Acknowledgement): ´e um tom usado pelo receptor para informar ao transmissor que a mensagem foi recebida com sucesso. A frequˆencia do tom ´e de

6

Figura 2.10: Composi¸c˜ao do Handshake.

1400 Hz (± 3%) e dever´a ser enviada pelo receptor em no m´ınimo 750 ms e no m´aximo 1 segundo. O transmissor tem que detectar o tom em no m´ınimo 400 ms para considerar o kissoff v´alido (figura 2.11). Transmissores devem aceitar um erro

Figura 2.11: Kissoff tone.

de frequˆencia de 5% para assegurar compatibilidade com receptores mais antigos.

espa¸cos. Um bloco de mensagem ´e enviado pelo transmissor para cada mensagem na fila de mensagens do transmissor (buffer da central). Cada bloco de mensagem cont´em dados suficientes para informar um evento ocorrido no sistema. A figura 2.12 ilustra o processo de envio de message blocks. O primeiro bloco de mensagem ´e

Figura 2.12: Message blocks.

enviado inicialmente em 250 ms (m´ınimo 250, m´aximo 300) ao final de um Handshake ou um Kissoff (Acknowledgement Tone), e o atraso ´e cronometrado ao t´ermino do tom.

ˆ Tempo de valida¸c˜ao da mensagem: depois de enviar uma mensagem, o transmis- sor dever´a esperar 1,25 segundos pelo in´ıcio de um Kissoff Tone do receptor. Se o in´ıcio do Kissoff for detectado, o transmissor ter´a que continuar a cronometragem do tom, mesmo se o tempo de comunica¸c˜ao expirar. A figura 2.13 ilustra o pro- cesso de valida¸c˜ao da mensagem. O transmissor dever´a detectar o Kissoff Tone em no m´ınimo 400 ms para considerar o recebimento v´alido. Se Kissoff ´e detectado, o transmissor dever´a esperar o fim do tom e ent˜ao esperar 250 ms (m´ınimo 250, m´aximo 300) antes de come¸car a pr´oxima mensagem. Se nenhum Kissoff Tone ´e recebido, o transmissor dever´a repetir a mensagem depois de expirado um intervalo de 1,25 segundos de comunica¸c˜ao.

Figura 2.13: Tempo de valida¸c˜ao da mensagem.

O transmissor dever´a fazer at´e 4 tentativas de entrega da mensagem antes de desco- nectar e tentar novamente. O contador de tentativas ´e reajustado toda vez que um sinal de Kissoff v´alido ´e recebido. O n´umero de tentativas de conex˜ao depende das caracter´ısticas e da programa¸c˜ao da central de alarmes.

O m´odulo de comunica¸c˜ao Viaweb Ethernet (VIAWEB, 2009), que possibilita a co- nectividade de uma central de alarmes em redes TCP/IP (se¸c˜ao 2.3.3), tamb´em utiliza o protocolo Contact ID. Esta caracter´ıstica faz com que o Viaweb seja compat´ıvel com qualquer central de alarmes que trabalhe com este protocolo. Maiores detalhes sobre o Viaweb Ethernet ser˜ao discutidos na fase de valida¸c˜ao e testes (cap´ıtulo 5).