CABEAMENTO ESTRUTURADO E REDE ELÉTRICA - DNIT — … · Aucon Tecnologia CNPJ: 09.058.526/0001-05 * Insc. Municipal 12011501 End. Fiscal: Av. Pedro Teixeira, nº. 1000 - Bl A -

Aucon Tecnologia CNPJ: 09.058.526/0001-05 * Insc. Municipal 12011501 End. Fiscal: Av. Pedro Teixeira, nº. 1000 - Bl A - Sl 48 - D. Pedro - CEP: 69040-000 Filial: Rua Norberto Wongal, nº 33 – Sl 3 – Redenção – Conj. Hiléia 1 – CEP: 69047-095 Fone: + 55 (92) 3082-9189 * 9983-3200 Fone/Fax: +55 (92) 3651-3452

E-mail: [email protected]

00 REVISÃO INICIAL 31/10/2013 Augusto Sérgio Osmar

REV MODIFICAÇÃO DATA PROJETISTA DESENHISTA APROVO

PROJETO:

CABEAMENTO ESTRUTURADO E REDE ELÉTRICA

LOCAL

DNIT-RN

AV. BERNARDO VIEIRA, 3656 – BAIRRO LAGOA NOVA – CEP 59.056-005 – NATAL/RN

TIPO DE DOCUMENTO

ESPECIFICAÇÃO TÉCNICA ESPECÍFICA - ETE

AUTOR:

CESAR AUGUSTO FARIA DE OLIVEIRA

CREA: 7742-TD/AM

TIPO DE SERVIÇO

PROJETO BÁSICO

REVISOR

ENG. OSMAR BRAGA DE FREITAS FILHO

CREA

11487-D/AM

N.º DE CONTROLE

014/2013-RN

APROVO

ENG. OSMAR BRAGA DE FREITAS FILHO

CREA

11487-D/AM

DATA:

31/10/2013



ÍNDICE

1 - OBJETIVO DESTE PROJETO BÁSICO ...............................................................................................3

1.1 - Objetivo: ..............................................................................................................................................3

2 - NORMAS E INSTRUÇÕES GERAIS ...................................................................................................3

2.1 - Normatização: .....................................................................................................................................3

3 - ESPECIFICAÇÕES TÉCNICAS ..............................................................................................................4

3.1 - Especificação dos Materiais de Infraestrutura .....................................................................................4

3.2 - Especificação dos Materiais de Cabeamento Estruturado ...................................................................5

3.3 - Especificação dos Materiais de Rede Elétrica ...................................................................................14

3.4 - Especificação dos Materiais de Backbone ........................................................................................21

3.5 - Especificação dos Materiais complementares de Cabeamento .........................................................24

3.6 - Especificação da plataforma de segurança unificando vídeo-monitoramento (VMS) e controle de acesso (SCA) .............................................................................................................................................27

4 - INTERVENÇÃO TÉCNICA NA SUBESTAÇÃO ................................................................................91

4.1 - Especificação dos Materiais e Serviços a serem aplicados na Subestação .......................................91

5 – GARANTIA ............................................................................................................................................92

6 – DESENHOS E ESQUEMAS ..................................................................................................................93

7 – ESTIMATIVA DE CUSTOS DE MATERIAIS, EQUIPAMENTOS E SERVIÇOS ............................94



1 - OBJETIVO DESTE PROJETO BÁSICO

1.1 - Objetivo:

Este memorial tem o objetivo de definir o escopo técnico para os Sistemas de Rede Elétrica e

Cabeamento Estruturado a serem instalados nas Superintendência Regional do DNIT no Estado do Rio

Grande do Norte.

2 - NORMAS E INSTRUÇÕES GERAIS

2.1 - Normatização:

A execução de todos os serviços ora especificados nesta Especificação Técnica deverão estar de

acordo com as partes aplicáveis das seguintes normas e documentos:

ABNT – Associação Brasileira de Normas Técnicas; ITU-T – International Telecommunications Union. ANATEL – Agencia Nacional de Telecomunicações. EIA / TIA – Cabeamento Estruturado. IEC – International Eletrical Code. ANSI – American National Standard. IEEE – Institut of Eletrical and Eletronic Engineers



3 - ESPECIFICAÇÕES TÉCNICAS

3.1 - Especificação dos Materiais de Infraestrutura

a. Eletrocalha

i. Quando utilizadas as eletrocalhas deverão atender às especificações abaixo:

As eletrocalhas não poderão possuir virola, devem ser lisas e com tampa, Devem obedecer as Normas NBR 7008, 7013 e NBR 6323, com 70μm de

revestimento de zinco para 3,0mm de espessura. A zincagem deverá ser por imersão a quente, ou, como é mais conhecida,

Galvanização a fogo. Os acessórios deverão ser formados por uma única peça, não possuindo

emendas por sistemas de solda, e deverão possuir as mesmas características técnicas das eletrocalhas.



b. Calha para distribuição secundária

i. A distribuição secundária do cabeamento estruturado horizontal, deverá ser feita com calhas de termoplástico auto-extinguível. As calhas deverão ser lisas de 150 x 50 mm, com tampa e septo divisor central em cada descida.

ii. As curvas e demais acabamentos devem ser feitos em fábrica, não sendo aceito

qualquer tipo de adaptação em campo.

iii. A fixação das canaletas, seja no piso ou alvenaria, deverá ser feita com buchas e parafusos, não sendo aceitos outro tipo de fixação.

c. Porta-equipamentos

i. Cada porta-equipamento para o cabeamento estruturado deverá possuir conexão para 2 (dois) conectores fêmea RJ-45.

ii. Cada porta-equipamento para a rede elétrica deverá possuir conexão para 2 (duas) tomadas padrão NBR 14136.

iii. Os porta-equipamentos devem ser fabricados em termoplástico auto-extinguível e

devem permitir o encaixe diretamente sobre a canaleta, dispensando o uso de caixas.

iv. Os porta-equipamentos devem ser da mesma cor das canaletas.

v. As caixas dos pontos deverão ser instaladas nas divisórias ou alvenarias, conforme o caso.

3.2 - Especificação dos Materiais de Cabeamento Estruturado

a. Todos os materiais necessários à execução dos serviços serão fornecidos pela empresa

contratada, sendo obrigatório a apresentação de catálogos ou folhas técnicas do fabricante do sistema de cabeamento estruturado para a comprovação das características dos produtos, marca e modelo, para cada um dos itens a seguir especificados.

b. Todos os produtos de conectividade e acomodação dos equipamentos de rede (patch panels, tomadas, patch cords, distribuidores ópticos, cordões ópticos, racks, organizadores horizontais e verticais) devem ser de um mesmo fabricante. O fabricante dos cabos deve ser o mesmo fabricante dos elementos de conectividade ou deve ser uma marca homologada pelo mesmo que permita que o canal tenha uma performance compatível com os requisitos da normas ANSI/TIA/EIA 568-B e ISO/IEC 11801 e que possibilite ao instalador fornecer uma garantia de no mínimo 25 anos do fabricante.

c. Gabinete de 36 Us



vi. Os gabinetes deverão ser de sobrepor, fabricados em metal. Deverão possuir porta frontal curvada com vidro de segurança, painéis removíveis nas laterais, e uma porta de fundos sólida, tudo com trancas 2433A.

vii. Deverão possuir cobertura com textura de poliéster com resistência excelente à

corrosão e arranhões Índice de proteção (resistente a intempéries) contra entrada de corpos sólidos e líquidos: IP 20. Índice de proteção contra impactos mecânicos: IK 08. Proporção de carga permitida: 3 kg/U (por exemplo, 48 kg para 16 U de Gabinetes).

viii. Os gabinetes devem seguir os seguintes padrões

ix. IEC 60529 e EN 60529: (NF C 20-010) Graus de proteção providenciada por

emenda (IP code)

x. IEC 62262 e EN 62262: (EN 50102, NF C 20-015) Graus de proteção providenciada por emenda para equipamento elétrico contra impacto mecânico externo (IK code).

xi. IEC 60950-1, EN 60950-1 e C 77-210-1: Equipamento de Tecnologia de

Informação – Segurança.

xii. EIA-310-D: Gabinetes, racks, painéis e equipamento associado (ANSI/EIA/310-D-1992).

xiii. Deverão ser fornecidos completos, incluindo kit de fixação, kit de parafusos e porcas

M5 e uma régua de tomadas com, no mínimo, quatro tomadas para cada rack.



d. Gabinete de 42 Us

i. Os gabinetes (racks) deverão ser auto-suportados, metálicos, planos reguláveis, fechados, padrão EIA de 19” (483 mm) ajustável para 23” (584 mm), 42U de altura útil, com dimensões exteriores de 800x600mm ou 800X800mm de base e 2200mm de altura, capacidade de carga distribuída de 450 Kg (1000 lbs), com guias de fixação verticais de perfil metálico galvanizado, com padrão de perfurações para porca gaiola com separação alternada ½”, com acesso de cabos pela parte superior ou pelo piso, sistema de conexão a terra, acabamento com pintura de textura de poliéster com alta resistência a aranhões.

ii. Os rack’s deverão possuir no mínimo as seguintes características:

Possuir índice de proteção contra o ingresso de objetos sólidos e líquidos, conforme IEC/EN 60529, mínimo de 20 (IP 20)

Possuir índice de proteção contra impactos mecânicos externos, conforme IEC/EN 62262, mínimo de 08 (IK 08)

Suportar no mínimo cargas distribuídas de 450Kg.

Possibilidade acessos para os cabos vindos do piso ou do teto;

Possuir na parte frontal 02 guias organizadoras de cabos verticais.

Possuir dispositivo reversível da portas fronta, permitindo que seja montada para abrir pela direita ou pela esquerda.

Os painéis de fechamento lateral devem possuir o mesmo fecho da porta frontal, permitindo ser abertos com a mesma chave.

A porta frontal deve ser de vidro temperado curvada.

Possuir disponibilidade (do mesmo fabricante) de organizadores frontais de 1U e 2U vazadosque possibilita ao mesmo tempo a organização na parte frontal e traseira. Ter também organizadores de cabo abertos com passa cabos de 1U e 2U;

Possuir disponibilidade do mesmo fabricante de acessórios como bandejas fixas e retráteis, suportes retráteis para teclado e mouse, kit de ventilação forçada, rodízios.

e. Organizador de Cabos

i. Para a organização dos cabos de manobra deverão ser utilizados organizadores horizontais de cabos do mesmo fabricante do material de cabeamento estruturado, de 19”x 2U, abertos, com anéis plásticos raiados para uma ótima proteção do patch Cord, respeitando os raios de curvatura. Estes organizadores deverão possuir ainda



sistema de fixação rápida no Rack, não sendo necessário o uso de parafuso e porcas gaiolas o que facilitará sua instalação e manutenção.

f. Cabo UTP Cat. 6

i. Cabo de par trançado não blindado de 4 pares, com condutores de cobre nú recozido rígido 24AWG – 100Ω, com isolação em polietileno de alta densidade, totalmente compatível com os padrões para Categoria 6, que possibilite taxas de transmissão de até 1 Gbps (Gigabit Ethernet / 1000BaseT) e ATM a 155 Mbps, para aplicação em Cabeamento Horizontal. Deverá atender às normas técnicas americanas ANSI/EIA/TIA 568-B e européias IEC/ISO 11801 em todos os seus aspectos (características elétricas, mecânicas, etc.).

ii. Dois condutores com encapamento de polietileno são trançados entre si para formar um par. Ao conjunto de 4 pares, separados entre si por um membro plástico central, se aplica uma capa externa de PVC retardante a chamas.

iii. A capa de PVC deverá atender aos parâmetros de testes de flamabilidade, conforme a Norma européia IEC 332-3 (CM), deverá ter números impressos indicando o comprimento em espaços de 1 metro, viabilizando a contagem exata do comprimento utilizado na instalação.

iv. Os cabos UTP devem observar as seguintes especificações mínimas:

Cabo deverá ser acondicionado em caixas, contendo lance nominal de 300m

no mínimo;

Possuir um separador interno central que mantenha os 4 pares de cabo separados em toda a extensão do cabo;

Operação full duplex sobre os quatro pares;

Atender os requisitos da norma ISO/IEC 11801 e ANSI/TIA/EIA 568-B Cat. 6;

Condutor de cobre de diâmetro 24 AWG (0,56 mm), com encapamento de polietileno;

Deverá ser apresentado através de catálogos, testes das principais características elétricas em transmissões de altas velocidades (valores típicos) de atenuação (dB/100m), NEXT (dB), PSNEXT(dB), SRL(dB), ACR(dB), para no mínimo freqüências de 100, e 250 MHz;

Delay Skew menor ou igual a 25ns/100m;

Deve apresentar atenuação máxima de 19,7 dB/100m à 100MHz e 32,6 dB/100m à 250MHz;

Deve apresentar perda por retorno “Return Loss” mínima de 22,5 dB/100m à 100MHz e 20,5 dB/100m à 250 MHz;



Deve apresentar PSNEXT “Power Sum Next” mínima de 43,3 dB/100m à

100MHz e 37,3 dB/100m à 250 MHZ;

Deve apresentar PS-ACR “Power Sum Attenuation Crosstalk Ratio” mínima de 23,6 dB/100m à 100MHz e 4,7 dB/100m à 250 MHz;

Deve apresentar ACR “Attenuation Crosstalk Ratio” mínima de 25,6 dB/100m à 100MHz e 6,7 dB/100m à 250 MHz;

Deve apresentar NEXT “Crosstalk” mínimo de 45,3 dB/100m à 100MHz e 39,3 dB/100m à 250 MHz;

Deve apresentar resistência máxima operando em 20ºC (Celsius) de 93,8 Ohm/km;

Deve apresentar ELFEXT mínimo de 28,8 dB/100m à 100MHz e 20,8 dB/100m à 250 MHz;

Deve apresentar PS-ELFEXT mínimo de 25,8 dB/100m à 100MHz e 17,8 dB/100m à 250MHz;

Deve ser próprio para aplicações Ethernet 100BaseTX, 1000BaseT, 1000BaseTX, ATM155 Mb/s, ATM 622 Mb/s, FDDI/CDDI 100Mb/s, 100Base VG;

Capa em PVC não propagante à chama CM com diâmetro nominal de 5,4mm na cor azul;

O cabo utilizado deverá possuir certificação Anatel impressa na capa externa;

g. Patch Panel Cat. 6

i. Os patch panels para o cabeamento horizontal deverão ser categoria 6, com 24 portas em linha em “1U” de altura, 8P8C, tipo RJ45, compostos de 04 blocos de 6 conectores, os conectores podem ser trocados um a um, sem causar danos aos demais, terminação IDC com crimpagem sem a necessidade do uso de ferramentas pela parte forntal do panel, terminações T568A/B, compatível para condutores de 22-24 AWG, fixação dos contatos IDC no circuito impresso livre de soldas, encapsulado ABS UL 94V-0, com tampa plástica para proteção dos contatos traseiros. Corpo construído em chapa de aço galvanizada para montagem em racks 19”, com 01U de altura, sistema de fixação rápida diretamente ao montante do Rack sem necessidade de porcas gaiolas e parafusos, com organizador de cabos traseiro possuindo mecanismo de fixação individual dos cabos dispensando abraçadeiras.

ii. Os patch panels deverão seguir a seguinte especificação mínima:

Construção “universal” aceitando conectorizações tipo T568A ou T568B;

Cumprir com as especificações de categoria 6 ANSI/TIA/EIA 568B.2;



Componentes comprovados por Laboratório independente com

reconhecimento Internacional – category 6;

Contatos IDC de baixa emissão com crimpagem dos cabos livre de ferramentas;

Dispor de espaços próprios para colocação de etiquetas cambiáveis não autocolantes;

Possuir integrado ao corpo guia traseira de cabos com sistema de fixação e suporte para os cabos que possibilite que seja feita a manutenção individual dos cabos sem a necessidade de separá-la do patch panel e que depois de feita a manutenção a mesma possa retornar a posição original sem desfazer a organização e amarração dos cabos;

Permitir o encaixe e remoção individual dos conectores pela parte frontal do painel;

Plenamente compatível com as categorias anteriores 3, 5, 5e e 6;

Lâmina metálica do patch panel: aço, com acabamento galvanizado eletrolítico;

Módulos de 6 conectores: estrutura fabricada com plástico de alto impacto;

Retardante a chamas UL 94V-0;

Os circuitos impressos devem estar confinados dentro de cada módulo, ou seja, o painel deve conter proteção para os circuitos impressos, evitando danos aos mesmos durante e depois do manuseio e processo de conectorização;

Contatos modulares: cobre-berílio com revestimento de níquel em toda a longitude do contato. Revestimento adicional de ouro de 1,27 mícron (50 micro-polegadas) na área de contato;

Contatos IDC: bronze-fósforo com revestimento de níquel em toda a longitude do contato. Revestimento adicional de chumbo-estanho na área de contato com o cabo. Suportar terminações de condutores entre 22 e 24 AWG;

A conexão dos contatos IDC com a placa de circuito impresso não pode ser feita com solda;

Cumprir com a parte 68, sub-parte F da FCC;

Suportar até 750 inserções do patch cord;

Exceder os requisitos de 100 gramas de força entre os contatos do plug e do jack, quando estão conectados;



h. Tomada RJ45 Cat. 6 fêmea

i. Os módulos de conexão para voz e dados deverão ser Categoria 6 modulares, 8P8C, do tipo RJ45, com padrão de encaixe universal Keystone, terminação IDC sem necessidade do uso de ferramentas de impacto, com possibilidade de conexão T568A/B, compatível para condutores de 22-24AWG, fixação dos contatos IDC no circuito impresso livre de soldas, encapsulado ABS UL 94V-0, com corpo plástica para proteção dos contatos traseiros que possibilite gabaritar as distâncias de decapamento e destrançamento adequados.

ii. Para aplicação nas estações de trabalho. Deve suportar taxas de transmissão de até 1 Gbps (Gigabit Ethernet / 1000BaseT) e ATM a 155 Mbps. Deve atender às normas técnicas americanas ANSI/EIA/TIA-568-B e européias IEC/ISO 11801, em todos os seus aspectos (características elétricas, mecânicas, etc.), possuindo as seguintes especificações mínimas:

Cumprir com as especificações de componentes categoria 6 ANSI/TIA/EIA

568B.2-1;

Componentes comprovados por laboratório independente de reconhecimento Internacional to Components to ANSI/TIA–568-B.2-1 – category 6;

Contatos IDC de baixa emissão;

Devem permitir a inserção em espelhos, caixas de superfície pela parte frontal; caixas de piso e mobiliário pela parte traseira.

Compatível com as categorias 3, 5, 5e e 6;

Estrutura fabricada com plástico de alto impacto;


Contatos modulares: de cobre-berílio com revestimento de níquel em toda a longitude do contato. Revestimento adicional de ouro de 1,27 mícron (50 micro-polegadas) na área de contato;

Contatos IDC: bronze-fósforo com revestimento de níquel em toda a

longitude do contato. Revestimento adicional de chumbo-estanho na área de contato com cabo. Suportar a terminação de condutores entre 22 e 24 AWG;

Os circuitos impressos devem estar totalmente confinados dentro de cada

módulo, ou seja, o conector deve conter proteção para os circuitos impressos, evitando danos aos mesmos durante e depois do processo de conectorização;

Crimpagem livre de impactos e que possibilite o fácil reaproveitamento;





Classificados para 750 inserções do patch cord;

Exceder o requisito de 100 gramas de força entre os contatos do plugue e

jack, quando conectados;

i. Cabo de Manobra Cat. 6 (Patch Cord)

i. Os patch cords e user cords deverão ser Categoria 6, tipo RJ45/RJ45, 8P8C, com cabo UTP de 4 pares, multifilar, 100Ω, 24 AWG, T568A/B, com septo interno para a separação dos pares, bota de proteção de tamanho reduzido e proteção à lingueta de travamento, manufaturados e testados em fábrica.

ii. Os cabos (Patch Cords) destinados à interligação dos equipamentos de rede aos patch panels e das estações de trabalho aos pontos de rede, deverão ser do tipo não blindado, constituídos por oito condutores isolados individualmente, compondo quatro pares trançados de condutores de cobre (UTP), com capa de proteção externa, montados em fábrica, e atender inteiramente aos requisitos físicos e elétricos da norma ANSI/EIA/TIA 568-B, para categoria 6. Deverão possuir a seguinte especificação mínima:

Possuir elemento plástico interno ao conector RJ45 macho (plugue) para

manter a integridade dos pares trançados do cabo até o ponto de terminação no Plugue RJ45 macho;

Componentes comprovados por laboratório independente reconhecido internacionalmente (to ANSI/TIA–568-B.2 – category 6);

Dever ser disponível no comprimentos de 1m, 2m, 3m, 5m, 8m, 12m e 20m

Testados em fábrica para um rendimento categoria 6;

Contatos arranjados em pares e em dois níveis;

Construído com cabos multifilares (flexível) de 4 pares;

Compatíveis com conectorizações de rede tipo T568A e T568B;

As capas plásticas do plugues RJ45 devem ajudar a evitar a curvatura excessiva dos cabos;

Compatíveis com as categorias 3, 5, 5e e 6;

Estrutura do plugue: policarbonato transparente UL 94V-0;

Contatos do plugue: cobre com recobrimento de ouro de 1,27 mícron (50 micro-polegadas) nas superfícies de contato;

Cabo: cabo multifilar categoria 6, 4 pares, 24 AWG, capa externa de PVC;



Classificados para 750 inserções;

Plugue e terminação cumprem com a parte 68 da FCC;

j. Cabo de Manobra Cat5e (Patch Cord para voz)

i. Os patch cords e user cords deverão ser Categoria 5e, tipo RJ45/RJ45, 8P8C, com cabo UTP de 4 pares, multifilar, 100Ω, 24 AWG, T568A/B, bota de proteção de tamanho reduzido e proteção à lingueta de travamento, manufaturados e testados em fábrica com a distribuição dos contatos por níveis.

ii. Os cabos (Patch Cords) destinados à interligação dos equipamentos de rede aos patch panels e das estações de trabalho aos pontos de rede, deverão ser do tipo não blindado, constituídos por oito condutores isolados individualmente, compondo quatro pares trançados de condutores de cobre (UTP), com capa de proteção externa, montados em fábrica, e atender inteiramente aos requisitos físicos e elétricos da norma ANSI/EIA/TIA 568-B, para categoria 5e. Deverão possuir a seguinte especificação mínima:

Componentes comprovados através de testes de canal executados por

laboratório independente com reconhecimento internacional (ANSI/TIA–568-B.1, ASTM D4566-98 e ISO/IEC 11801 – category 5e);

Testados em fábrica para um rendimento categoria 5e;

Dever ser disponível no comprimentos de 1m, 2m, 3m, 5m, 8m

Contatos arranjados em pares e em dois níveis;

Construído com cabos multifilares (flexível) de 4 pares;

Compatíveis com conectorizações de rede tipo T568A e T568B;

As capas plásticas do plugues RJ45 devem ajudar a evitar a curvatura excessiva dos cabos;

Compatíveis com as categorias 3, 5 e 5e;

Estrutura do plugue: policarbonato transparente UL 94V-0;

Contatos do plugue: cobre com recobrimento de ouro de 1,27 mícron (50 micro-polegadas) nas superfícies de contato;

Cabo: cabo multifilar categoria 5e, 4 pares, 24 AWG, capa externa de PVC;

Classificados para 750 inserções;

Plugue e terminação cumprem com a parte 68 da FCC;



3.3 - Especificação dos Materiais de Rede Elétrica

a. Quadro de Distribuição Elétrica (QDE)

i. Os quadros elétricos deverão ser compostos de caixa metálica, com porta, dobradiça e chave mestra. Deverá ser construído de chapas de aço 14 MSG, com pintura epóxi, próprio para instalação aparente, montagem sobrepor com dimensões mínimas de 600 x 400 x 200mm.

ii. Estes quadros deverão possuir chave geral em seu alimentador para desligamento

em caso de manutenção. Deverá possuir 24 postos para saídas para alimentadores diversos, sendo estas monofásicas para alimentação das estações de trabalho e do rack na sala de equipamentos.

iii. Os postos não utilizados ficarão disponíveis para futuras ampliações, com suas

partes condutivas encapadas por material termo-retrátil que permitam a instalação de novos disjuntores sem a necessidade de remoção das barras de cobre.

iv. Todas as partes sob tensão e ao alcance do operador deverão ser protegidas por

barreiras conforme estabelecido na NBR IEC 60439-1.

v. As barreiras de proteção deve ser construídas em materiais não propagante à chamas, a exemplo do policarbonato.

vi. Nas faces superior e inferior do invólucro devem ser previstas, preferencialmente,

chapas removíveis para passagem de cabos. As chapas removíveis devem ocupar toda a extensão da face correspondente do invólucro.

vii. Os barramentos devem ser trifásicos, com barras de neutro e terra independentes,

segundo o esquema TN-S da NBR-5410 da ABNT. As barras devem ser de cobre eletrolítico e encapadas com material termo-retrátil (LVR) ou tinta epóxi. Todos os componentes devem ser montados na parte interna do painel.

viii. Os quadros devem atender na íntegra os itens desta especificação, bem como aos

detalhes existentes nas pranchas de cada unidade.

b. Disjuntor

i. Os disjuntores devem ser do tipo mini-disjuntores, equipados com disparadores termomagnéticos fixos, curva C. Devem atender a Norma IEC 947-2.

c. Cabos elétricos

i. Os Cabos deverão possuir isolação de 0,6 / 1 kV;

ii. Deverão ser compostos de condutores monopolares;

iii. Os condutores deverão ser de cobre nu, têmpera mole, com encordoamento extraflexível (classe 5);



iv. Deve possuir isolação por composto termofixo em dupla camada de borracha HEPR

(EPR/B - Alto módulo);

v. O enchimento deve ser composto por material não halogenado.

d. Tomadas elétricas

i. As tomadas elétricas deverão ser de 10A – 250V de acordo com a NBR-14136.

ii. As tomadas elétricas deverão atender seguinte especificação mínima:

Possuir etiqueta de identificação de tensão; Possuir fundo móvel, evitando o acúmulo de poeira;

Permitir a utilização de tampa.

e. Materiais de aterramento

i. A CONTRATADA será responsável pelos materiais de aterramento, tais como hastes, cabos de cobre nu, caixas de inspeção, soldas exotérmicas, plugues e conectores, além dos demais materiais necessários à instalação do aterramento.

ii. A CONTRATADA deverá ainda prover toda a infraestrutura necessária para que o

cabo de aterramento chegue até o ponto de equipotencialização, bem como ao QDE.

f. Unidade de aquisição de dados

i. Cada unidade remota fornecida deverá atender, no mínimo, as características abaixo:

Monitorar e controlar equipamentos e infraestruturas através de comunicação

remota;

Permitir variados meios de comunicação, tal como: Linha telefônica fixa ou móvel, GPRS, Rede IP, Internet banda larga, satélite e rádios.

Transmitir os dados de telemetria de forma periódica ao servidor de

telemetria.

Possuir histórico operacional de todas as ações monitoradas e executadas com resolução menor ou igual a 01s de amostragem e armazenamento.

Capacidade de armazenamento interna do histórico operacional de pelo menos 01 ano de todas as medidas;

O armazenamento do histórico operacional deve ser feito em mídia de estado sólido removível para que possibilite leitura direta em computadores.



Possibilitar acionamentos remotos através de telecomando.

Possuir a capacidade de até 32 portas de telecomandos configuráveis;

Permitir telecomandos através de contato de relé (disponíveis NA / NF) e potência de 60W por comando;

Permitir o acionamento de dispositivos sonoros e luminosos, assim como capacidade de realizar acionamento de máquinas e outros equipamentos diversos através de telecomandos atuando sobre chaves ON / OFF;

Possuir a capacidade de até 32 portas de leitura digital configuráveis;

Possuir entradas digitais com isolação óptica melhor que 1kV;

Possuir a capacidade de até 16 portas de leitura analógica;

Possuir a capacidade de até 12 portas PWM configuráveis;

Deve permitir a integração com diversos sensores para monitorações de grandezas específicas, como temperatura, movimento, invasão, energia elétrica, fumaça entre outros;

Possuir arquitetura de funcionamento em rede, possibilitando o acesso simultâneo de diversos servidores a cada unidade;

Deve possuir sistema microcontrolado com processador RISC de 16 bits;

Não deve utilizar tecnologia de sistema operacional embarcado, visando evitar travamentos e inoperâncias.

Deve sincronizar automaticamente seu horário interno de acordo com o horário do servidor de telemetria.

Deve possuir conexão SMA para antena 3G/GPRS.

Deve permitir o escalonamento de unidades para atender sites com maior número de medidas e ou comandos, sem limite de escalonamento;

Deve permitir de forma nativa e sem adaptações, a instalação em rack 19;

Deve possuir no mínimo 02 interfaces seriais RS232. Deve possui no mínimo 01 interface ethernet 10/100mbps auto MDI/MDX.

Possuir bateria interna para perfeito funcionamento do relógio interno

persistido em tempo real;

Possuir sistema de watchdog por hardware a fim de garantir o funcionamento ininterrupto da unidade.



Ser completamente integrável ao sistema de gerenciamento existente. Esta compatibilidade deverá ser comprovada através de documento do fabricante dos equipamentos propostos, informando como se dará essa compatibilidade;

ii. Cada Unidade Remota deverá possuir o mínimo de 16 (dezesseis) entradas

analógicas, 32 (trinta e duas) entradas digitais/saída de telecomandos configuráveis e estar acompanhada de módulos / interfaces para monitorar os itens abaixo descritos:

Tensão de entrada e saída do NoBreak por fase (RST);

Corrente na entrada e saída do NoBreak por fase (RST);

Detecção de abertura de porta;

Detecção de movimento no ambiente;

Temperatura do ambiente;

Informar qual dos equipamentos de ar-condicionado está ligado, permitindo

que estes sejam ligados ou desligados remotamente, caso haja dois ou mais equipamentos;

iii. Permitir a configuração das portas de entradas analógicas para operar como entradas digitais emuladas.

iv. Permitir a configuração das portas de os telecomandos por acionamento automático

por tomada de decisão autônoma na unidade remota a partir de limites pré-configurados para os valores medidos;

v. Cada unidade remota deve estar acompanhada de um modem GPRS ou outro

equipamento para conexão à unidade Central.

vi. Sistema de software Cliente/Servidor

Os elementos que compões a solução de software do sistema devem atender, no mínimo, as características abaixo:

o Sistema de visualização customizável, permitindo a criação de

diversas camadas, permitindo a visualização desde o cenário macro até a identificação específica do alarme em camadas distintas;

o Sistema de customização de telas de monitoramento, permitindo configuração de temas, cores e posicionamento dos controles;

o Sistema de monitoramento deve permitir a exibição das telas de maneira a se ajustar automaticamente a resolução do monitor, efetuando o escalonamento automático de todos os elementos visuais.

o O sistema servidor deve suportar resolução de nomes para serviços DDNS.



o O sistema servidor deve possuir módulo de gestão de usuários, permitindo a criação de grupos de usuários e o controle de permissões de acesso e controle aos grupos.

o O sistema deve permitir a visualização de diversas informações de telemetria em modo pretérito em um único gráfico de histórico.

o Possuir sistema integrado de alerta com vários níveis (sonoro, visual, envio de SMS para celulares programados, envio de e-mails);

o Permitir o agendamento de tarefas de execução periódica;

o Possuir arquitetura de funcionamento CLIENTE / SERVIDOR, possibilitando o acesso simultâneo de vários usuários clientes ao sistema;

o Permitir o registro de todos os eventos de auditoria do sistema em logs no banco de dados;

o Permitir a configuração de aviso de término de alarme;

o Permitir configuração de alarme independente para cada entrada analógica, permitindo programação para limites percentuais máximos e mínimos de cada parâmetro monitorado;

o Permitir a programação de telecomandos retentivos (acionado / não acionado) ou não retentivos (telecomandos temporizados);

O sistema servidor deve armazenar os dados de telemetria em banco de

dados de alta disponibilidade padrão SQL.

O sistema deve possuir banco de dados centralizado nos servidores, sendo que a informação não deve ser persistida nos clientes.

O sistema deve permitir a consulta aos eventos de logs através de filtros manuais de texto.

O sistema deve possuir táticas inteligentes de persistência de dados de

telemetria em banco de dados a fim de minimizar o uso de disco, evitando o armazenamento cíclico de dados redundantes.



g. Nobreak Tipo I

i. Os Nobreaks do Tipo I devem atender as especificações abaixo descritas: Potência mínima – 80 kVA

Tensão de Entrada: 220V +/- 15% - Trifásico.

Tensão de saída: 220/127V +/- 1% - Trifásico.

Nobreak On-Line Senoidal e Dupla Conversão.

Inversor 100% sincronizado com a rede.

Proteção do inversor contra sobrecarga.

Fator de Potência de saída 0,8;

Rendimento a plena carga ( DC / AC ): 92%;

Distorção harmônica THD (carga resistiva ): < 3%

Frequência de rede: 60Hz +/- 4%

Fator de crista 3:1;

Nível de ruído máximo: ≤ 60 dB;

Grau de Proteção: IP20;

Inversor sincronizado com a rede;

Proteção do inversor contra sobrecarga;

Display inteligente mostrando informações sobre o status do sistema.

Acionamento do By-pass em caso de falha ou sobrecarga no inversor

(automático).

By-pass manual (manutenção).

Saída Isolada de rede (isolação galvânica).

Proteção contra descarga total das baterias.

Alarmes Audiovisuais;

Recarga automática de baterias.

Proteção contra surtos de tensão.



Interação com o display através do teclado.

Tensão de Barramentos de 384Vcc.

Autonomia: 15 (quinze) minutos a plena carga h. Nobreak Tipo II

i. Os Nobreaks do Tipo II devem atender as especificações abaixo descritas: Potência mínima – 1,2 kVA

Tensão nominal de saída: 120V

Tipo de Forma de Onda de Saída: Senoidal aproximada, 4 (quatro) Conexões

de Saída NBR14136;

Tensão nominal de entrada 120/230V sistema bivolt automático;

Estabilizador interno integrado;

Frequência de entrada 60 Hz +/- 3 Hz;

Tipo de Conexão de Entrada: NEMA 5-15P;

Comprimento do Cabo 1.8 m;

Intervalo de tensão de entrada ajustável: 95-135 / 190-240 V;

Bateria interna tipo selada Chumbo-Acido livre de manutenção;

Tempo de autonomia típico com carga de 100W: 23 minutos;

Porta de interface: USB;

Display de LED de status com indicadores de estado para: On-line / Em Bateria / Troca de Bateria / Sobrecarga;

Classe de surto de energia: Mínima de 420 Joules;

Proteção RJ-11 Modem/Fax/DSL (linha simples de dois fios);

Auto reinicialização;



3.4 - Especificação dos Materiais de Backbone


contratada, sendo obrigatório a apresentação de catálogos ou folhas técnicas do fabricante do sistema de backbone para a comprovação das características dos produtos, marca e modelo, para cada um dos itens a seguir especificados.


c. Gabinete de 42 Us

i. Os gabinetes (racks) deverão ser auto-suportados, metálicos, planos reguláveis, fechados, padrão EIA de 19” (483 mm) ajustável para 23” (584 mm), 42U de altura útil, com dimensões exteriores de 800x600mm ou 800X800mm de base e 2200mm de altura, capacidade de carga distribuída de 450 Kg (1000 lbs), com guias de fixação verticais de perfil metálico galvanizado, com padrão de perfurações para porca gaiola com separação alternada ½”, com acesso de cabos pela parte superior ou pelo piso, sistema de conexão a terra, acabamento com pintura de textura de poliéster com alta resistência a aranhões.

ii. Os rack’s deverão possuir no mínimo as seguintes características:

Possuir índice de proteção contra o ingresso de objetos sólidos e líquidos, conforme IEC/EN 60529, mínimo de 20 (IP 20)

Possuir índice de proteção contra impactos mecânicos externos, conforme IEC/EN 62262, mínimo de 08 (IK 08)

Suportar no mínimo cargas distribuídas de 450Kg.

Possibilidade acessos para os cabos vindos do piso ou do teto;

Possuir na parte frontal 02 guias organizadoras de cabos verticais.

Possuir dispositivo reversível da portas frontais, permitindo que seja montada para abrir pela direita ou pela esquerda.

Os painéis de fechamento lateral devem possuir o mesmo fecho da porta frontal, permitindo ser abertos com a mesma chave. A porta frontal deve ser de vidro temperado curvada.

Possuir disponibilidade (do mesmo fabricante) de organizadores frontais de 1U e 2U vazados que possibilita ao mesmo tempo a organização na parte



frontal e traseira. Ter também organizadores de cabo abertos com passa cabos de 1U e 2U;

Possuir disponibilidade do mesmo fabricante de acessórios como bandejas fixas e retráteis, suportes retráteis para teclado e mouse, kit de ventilação forçada, rodízios.

d. Cabo de fibra óptica multimodo

Deve ser fabricado em Fibra Óptica MM (Multimodo) 62,5/125 µm; Ser do tipo “loose”, possuindo núcleo geleado; Ser composto por 06 fibras (3 pares); Possuir proteção anti-roedor; Possuir certificação ANATEL.

e. Gabinete de fibras ópticas (DIO’s)

i. Os Gabinetes de Fibras Ópticas deverão ser metálicos, pivotantes, para montagem em rack padrão 19” com 01U de altura e acabamento com pintura de alta resistência na cor preta, fechamento rápido por meio de travamento automático, guias internas para armazenamento de sobras de fibras ópticas e para fixação dos cabos, deve conter acessórios para a entrada dos cabos no gabinete do tipo passa cabos e prensa cabos, com capacidade para até 36 módulos acopladores SC distribuídos em 03 painéis de 06 (seis) módulos de encaixe rápido SC duplos e tampas de proteção em ambos os lados dos acopladores, tampa cega para os espaços vazios.

ii. Os DIO´s deverão possuir no mínimo as seguintes características:

Bandeja pivotante;

Suportar 03 (três) painéis de montagem rápida;

Disponibilidade de adquirir múltiplas configurações com as trocas dos painéis;

Possibilidade de encaixe SC, ST, LC

O gabinete deve ser fornecido na cor preta;

Possibilidade de terminação de até 36 fibras em 1U;

Deve permitir o encaixe de cassetes de fibra óptica pré-terminada que façam uso de conectores tipo MPO;

Deve permitir a remoção da tampa superior;

Deve possuir entrada de cabos em ângulo de 45o na parte traseira do gabinete;

Deve possibilitar a fixação em racks de 19” ou de 23”;



f. Cordões ópticos

i. Os cordões ópticos deverão seguir a seguinte especificação mínima:

Conectores: SC;

Polimentos: PC (Physical Contact);

Comprimentos: 2 metros

Tipos de fibra: 62,5/125µm

Duplex (duas vias);



3.5 - Especificação dos Materiais complementares de Cabeamento


contratada, sendo obrigatório a apresentação de catálogos ou folhas técnicas do fabricante dos materiais complementares para a comprovação das características dos produtos, marca e modelo, para cada um dos itens a seguir especificados.


c. Voice Panel 50 portas

i. Os patch panels para o cabeamento de distribuição de voz deverão possuir alta densidade, com 50 portas, 8P8C, tipo RJ45, terminação IDC padrão 110, compatível para condutores de 24-26 AWG, fixação dos contatos IDC no circuito impresso livre de soldas, encapsulado ABS UL 94V-0, com tampa plástica para proteção dos contatos traseiros. Construídos em placas de alumínio para montagem em racks 19” com 01U, acabamento com pintura de alta resistência na cor preta, com organizador de cabos posterior e metálico compondo o conjunto.

ii. Os patch panels deverão seguir a seguinte especificação mínima:

Dispor de espaços próprios para colocação de etiquetas cambiáveis não autocolantes;

Incluir guia metálica de cabos (barra), traseira para suporte dos cabos e que possa ser ajustada para que seja feita manutenção sem a necessidade de separá-la do patch panel e que depois de feita a manutenção a mesma possa retornar a posição original sem desfazer a amarração dos cabos;

Lâmina metálica do patch panel: alumínio de 2,4 mm (0,094 polegadas), com pintura a pó;

Módulos de 6 conectores: estrutura fabricada com plástico de alto impacto;


Os circuitos impressos devem estar totalmente confinados dentro de cada módulo, ou seja, o painel deve conter proteção para os circuitos impressos, evitando danos aos mesmos durante e depois do processo de conectorização;

Contatos modulares: bronze-fósforo com revestimento de níquel em toda a longitude do contato. Revestimento adicional de ouro de 1,27 mícron (50 micro-polegadas) na área de contato;



Contatos IDC: bronze-fósforo com revestimento de níquel em toda a longitude do contato. Revestimento adicional de chumbo-estanho na área de contato com o cabo. Suportar terminações de condutores entre 22 e 24 AWG;


Compatíveis com ferramentas de impacto tipo 110;


Suportar até 750 inserções do patch cord;

Exceder os requisitos de 100 gramas de força entre os contatos do plug e do jack, quando estão conectados;

Listado UL 1863;

d. Caixa de Distribuição Multimídia

i. As caixas de distribuição multimídia deverão ser do tipo modular, fornecidas descarregadas, podendo ser equipadas com até 12 conectores tipo RJ 45 blindados ou não com saída simples ou duplicada, tendo espaço para 02 blocos modulares. Corpo construído em termoplástico para montagem em piso elevado, no forro ou fixada sobreposta às paredes, possui entrada de cabos com acessório anti-poeira e possibilita a amarração individual dos cabos. Viabilizar a centralização das conexões (ponto de consolidação ou MUTOA) garantindo flexibilidade e evolução à instalação.

ii. As caixas de Distribuição deverão seguir a seguinte especificação mínima:

Dispor de acabamentos com espaços próprios para colocação de etiquetas cambiáveis não autocolantes;

Possuir integrado ao corpo guia traseira de cabos com sistema de fixação e suporte para os cabos que possibilite que seja feita a manutenção individual dos cabos sem a necessidade de separá-la do patch panel e que depois de feita a manutenção a mesma possa retornar a posição original sem desfazer a organização dos cabos

Corpo em termoplástico não propagante a chama

Permitir o encaixe e remoção individual de blocos modulares e ou dos conectores pela parte frontal do painel;

Possuir a possibilidade de ser equipado com blocos modulares das seguintes funções:

o Blocos de 06 conectores RJ 45 cat 6A, cat6 e cat5E blindados ou não;

o Bloco para voz;



o Blocos de Fibra Ótica;

o Bloco Injetor POE MidSpan

o Bloco de Difusão de Vídeo;

o Bloco Switch Ethernet 100 Mbits/s

o Bloco de Conversão cobre/fibra;

o Blocos Obturadores para Acabamento.



II. SCA

3.6 - Especificação da plataforma de segurança unificando vídeo-monitoramento (VMS) e

controle de acesso (SCA)

a. A PSU deverá suportar a perfeita unificação de sistemas de controle de acesso IP (SCA),

sistema de gerenciamento de vídeo IP (VMS) e o sistema de reconhecimento de placa (LPR) em uma única plataforma de segurança. As aplicações de interface de usuários do PSU deverá apresentar uma interface unificada de segurança para gerenciamento, configuração, monitoramento e relatórios dos sistemas de SCA, VMS e sistemas de LPR e dispositivos de borda suportados (câmeras, encoders, leitores, controladoras, placas de IO, etc.).

b. A PSU deverá disponibilizar as seguintes funcionalidades:

i. Configuração de sistemas unificados, tais como SCA, LPR, e sistemas VMS.

ii. Monitoramento de eventos ao vivo.

iii. Monitoramento de vídeo ao vivo e reprodução de vídeo gravado.

iv. Gerenciamento de alarmes.

v. Geração de relatórios, incluindo a criação de modelos de relatórios personalizados e relatórios de incidentes

vi. Federação de vigilância global, geração de relatórios e gerenciamento de alarmes de múltiplos sistemas remotos e independentes de SCA e/ou sistemas VMS espalhados por múltiplas instalações e áreas geográficas.

vii. Gerenciamento global de usuários em várias instalações e áreas geográficas, cada um com seu próprio sistema SCA independente.

viii. Integração com o Microsoft Active Directory para sincronização de contas de usuário da PSU e de usuários de cartões do SCA.

ix. Integração de dispositivos de intrusão e painéis de alarmes (monitoramento ao vivo, geração de relatórios e armar/desarmar).

x. Integração com sistemas de terceiros e bases de dados através de plug-ins (controle de acesso, análise de vídeo, pontos de venda, e muito mais).

xi. Visualização dinâmica de mapas gráficos.

xii. Integração com sistema de gestão de ativos. c. A PSU deverá ser implantada em um ou mais dos seguintes tipos de instalações:

i. Acesso unificado, LPR, e plataforma de vídeo, e qualquer combinação entre estes.



ii. Controle de acesso independente, ou LPR, ou plataforma de vídeo.

iii. Plataforma de acesso e vídeo unificados que federa múltiplos SCA e VMS remotos.

iv. Plataforma de vídeo independente que federa vários VMS remotos independentes.

v. Controle de acesso independente que federa vários SCA remotos independentes.

d. A PSU deverá possibilitar as seguintes formas de licenciamento:

i. Uma única licença central deverá ser aplicada de forma centralizada no servidor de

configuração.

ii. Não deverá haver necessidade de aplicar uma licença em cada computador servidor ou estação de trabalho cliente.

iii. Com base nas opções selecionadas, um ou mais sistemas unificados deverão ser ativado ou desativados.

e. Requisitos de Hardware e Software

i. A PSU e demais sistemas unificados (vídeo, reconhecimento de placas, controle de acesso) deverão ser projetados para rodar em uma plataforma padrão baseada em PC, carregada com um sistema operacional Windows:

ii. O modulo de software servidor (MSS) deverá ser compatível com sistemas operacionais 32-bit e 64-bit, incluindo Windows Vista, Windows XP, Windows 7, Windows 8, Windows Server 2003, Windows Server 2008, e Windows Server 2012.

iii. Os módulos cliente deverão rodar em Windows XP, Windows Vista, Windows 7 ou Windows 8.

iv. O núcleo cliente/servidor do software deverá ter sido construído em sua totalidade usando Microsoft .NET framework e linguagem de programação C# (C-Sharp).

v. O servidor de banco de dados da PSU deverá ser construído no SQL Server 2005, SQL Server 2008, SQL Server 2012, incluindo o SQL Server 2005/2008/2012 Express Editions da Microsoft. Todas as versões e pacotes da PSU deverão poder ser executadas em SQL 2005/2008 Express Edition. Os serviços e aplicativos específicos de LPR deverão suportar apenas SQL Server 2008.

vi. A PSU deverá ser compatível com ambientes virtualizados, incluindo VMware 5.0.

vii. A PSU deverá usar a interface do usuário (UI) mais recente com tecnologias de desenvolvimento e programação como o Microsoft WPF (Windows Presentation Foundation), linguagem de dados XAML, e framework de software NET.

III. DESCRIÇÃO DO SOFTWARE DE GERENCIAMENTO E GRAVAÇÃO DE IMAGENS a. Características Gerais



i. O sistema de vídeo vigilância deverá ser uma solução de nível corporativo, baseada em software, altamente escalável e capaz de gerenciar dezenas de milhares de câmeras.

ii. O sistema deverá permitir fácil adição de novas câmeras, novos usuários, servidores de armazenamento locais e remotos, ou até novos sistemas de monitoramento completos.

iii. O sistema deverá ser capaz de gravar, exibir, recuperar, e processar os vídeos obtidos a partir das câmeras de vídeo monitoramento.

iv. O sistema a ser utilizado para visualização e armazenamento das imagens, deverá oferecer entradas / saídas sem restrição de local físico e com possibilidade de ser gerenciado por múltiplos locais. Além disso, deve oferecer escalabilidade com possibilidade de inclusão de novas câmeras IP em bases de 1 em 1, novos encoders, servidores de gerenciamento, servidores de gravação, servidores de análise inteligente de vídeo, estações de monitoramento e subsistemas de armazenamento, novos Centros de Monitoramento Remoto e até novos sistemas independentes.

v. O sistema deverá considerar os seguintes componentes:

Aplicação “Servidor de Diretório Principal”

O sistema deverá possuir componentes de software para computador que

permitam o gerenciamento de todos os componentes de hardware e software do sistema de CFTV e gerenciamento de alarmes.

Aplicação “Servidor de Diretório Principal de Contingência”


permitam o gerenciamento de todos os componentes de hardware e software do sistema de CFTV e gerenciamento de alarmes, pronto para assumir todas as funções do Servidor de Diretório Principal caso este pare de funcionar em decorrência de qualquer problema.

Aplicação “Servidor de Gravação de Imagens”


permitam o gerenciamento de todos os streams de vídeo e áudio a serem gravados pelo sistema de CFTV

Aplicação “Servidor de Gravação de Contingência de Imagens”


permitam o gerenciamento de todos os streams de vídeo e áudio a serem gravados pelo sistema de CFTV, pronto para assumir todas as funções do Servidor de Gravação Principal caso este pare de funcionar em decorrência de qualquer problema.

Aplicação “Servidor de Gravação Redundante de Imagens”



O sistema deverá possuir componente de software para computador que permitam o gerenciamento de todos os streams de vídeo e áudio a serem gravados pelo sistema de CFTV, que manterá uma base de dados igual aos Servidores de Gravação Principais.

Aplicação “Servidor Para Análise Inteligente de Vídeo”


permitam a integração com sistemas de terceiros para o processamento das imagens capturadas pelo sistema de CFTV, e delas, extrair eventos comportamentais através algoritmos especialistas, e a partir desses eventos, tomar ações automatizadas ou requerer ações por parte dos usuários.

Aplicação “Cliente de Visualização e Configuração” (para operadores e

administrador)

O sistema deverá possuir componentes de software para computador que permitam a administração, operação, e a manutenção de parâmetros do sistema de CFTV;

Sistemas Compactos de Vídeo Monitoramento em Rede

O sistema deverá possuir solução própria de vídeo monitoramento em rede

para pequenos sites com total autonomia em relação aos demais sites, com capacidade de gerenciamento de até 16 câmeras e conexão de até 5 estações cliente para vídeo monitoramento. A solução deverá ser composta por hardware servidor compacto, sistema operacional embarcado no servidor, software de gerenciamento e gravação embarcados no servidor, com capacidade de armazenamento local e independente. Estes sistemas compactos deverão ser capazes de serem integrados a um sistema de gerenciamento principal formando uma grande rede de sistemas de vídeo monitoramento. Estes sistemas deverão disponibilizar imagens ao vivo, por demanda, sempre que estiverem conectados a um ponto da rede, via qualquer meio de conexão (cabos metálicos, cabos óticos, conexão sem fio, conexão telefônica, etc.). As imagens sempre deverão ser gravadas no servidor compacto, mas quando o servidor estiver em comunicação com o centro de comando e controle, o sistema deverá possibilitar, mediante parametrização de opções de seleção do vídeo e horários de transferência, que as imagens gravadas possam ser descarregadas automaticamente no sistema central, através de funções próprias do sistema de vídeo monitoramento;

b. Sistema Central de Integração de Múltiplos Sistemas (Federação)

i. O sistema deverá possuir uma camada de software de integração de múltiplos

sistemas independentes de vídeo monitoramento, sendo que cada sistema independente deverá ter capacidade de gerenciamento de 1 a 50.000 câmeras;

ii. Câmeras IP O sistema deverá ser capaz de gerenciar dispositicos que permitam a captura

de imagens em formato digital e transmitam streams de vídeo ao vivo em H.264 e áudio bidirecional através da rede de dados;



iii. Codificadores de Vídeo O sistema deverá ser capaz de gerenciar dispositicos que permitam a

conversão de imagens capturadas por câmeras analógicas para o formato digital e transmitam streams de vídeo ao vivo em H.264 e áudio bidirecional através da rede de dados;

iv. Infraestrutura de rede IP

O sistema deverá ser capaz de trafegar e gerenciar informações através de redes de dados com comunicação por cabeamento estruturado, ou wireless, utilizando ativos de comutação e roteamento.

c. O sistema deverá ter sido projetado para incorporar as seguintes funcionalidades:

i. A tecnologia de compressão deverá ser baseada no padrão internacional H.264. A

tecnologia de compressão poderá ser integrada a transmissores (encoders) conectados a câmeras analógicas ou incorporadas na própria câmera, ou seja, câmera IP. Com isso, o vídeo poderá ser visualizado por vários usuários através da “Aplicação Cliente de Visualização” instalada nas estações de monitoramento. Os servidores de gravação rodando em ambiente operacional Windows deverão ser capazes de gravar o vídeo e o áudio comprimidos pelas câmeras IP ou pelos transmissores (encoders).

ii. A aplicação “Servidor de Gerenciamento Central” deverá ser o responsável pela

operação da matriz virtual do sistema, incluindo vídeo e áudio ao vivo, controles de PTZ, reprodução de vídeo e áudio gravados, gerenciamento de alarmes, seqüências, rondas de segurança e servidores de gravação.

iii. Todos os usuários do sistema deverão ser registrados em um banco de dados central,

que será gerenciado pelo administrador da aplicação “Servidor de Gerenciamento Central”. O administrador do sistema deverá poder atribuir privilégios a usuários, configurar e manter o sistema.

iv. O sistema deverá estar apto a dar suporte à detecção de movimento de vídeo de

forma natural, podendo ser configuradas várias áreas de detecção na mesma imagem, com possibilidade de sobreposição de áreas. Essa função também deverá estar disponível no codificador de vídeo (encoder) ou na Câmera IP. A habilitação da detecção de movimento de vídeo deverá ser realizada como segue:

v. Em bases contínuas,

vi. Programadas para horários, datas, dias, meses, etc, em particular,

vii. Áreas de interesse definidas através de uma interface de usuário de fácil utilização,

usando ferramentas de edição simples,

viii. Por níveis de sensibilidade parametrizados.

ix. O sistema deverá possibilitar de forma simultânea, gravar vídeo, exibir o vídeo ao vivo, visualizar vídeo gravado, obter áudio e possibilitar a interação do operador com cada ponto de câmera via áudio (bidirecional) e controle de relés, usar detecção de movimento para gravar vídeo e gerar alarmes, executar análises de objeto com



geração de alarmes, e transferir dados de vídeo, áudio e alarmes para dispositivos de armazenamento de longo prazo.

x. O sistema deverá possibilitar que sejam exibidos vídeo sob demanda, sem

interrupção do processo de gravação.

xi. O sistema deverá permitir que as exibições de vídeo, áudio e alarmes sejam obtidas através do uso de monitores analógicos e/ou digitais padrões de mercado.

xii. Arquitetura do sistema

d. A arquitetura do sistema deverá ser baseada em uma plataforma de vídeo sobre IP (Internet

Protocol).

e. O sistema deverá ter uma arquitetura aberta e flexível, baseada em padrões de marcado, independente de fabricantes de equipamentos, e que facilite a integração com as infraestruturas de TI existente.

f. O sistema deverá ter sua arquitetura baseada em uma plataforma verdadeiramente aberta e

flexível sobre IP, que permita a utilização de encoders, câmeras IP, equipamentos de rede, servidores de gerenciamento, servidores de gravação, estações de monitoramento e subsistemas de armazenamento padrões de mercado, fornecidos por diversos fabricantes. O sistema não deverá obrigar o uso de equipamentos ou PC’s proprietários para processamento e armazenamento das imagens. A capacidade de armazenamento não poderá ser limitada por um dispositivo especifico de armazenamento, podendo ser ampliada gradativamente com a alocação de novos locais de armazenamento na rede ou inclusão de novos sistemas de armazenamento. Os únicos hardwares proprietários aceitos serão aqueles utilizados nos pontos de captura ou conversão do vídeo analógico para digital: encoders e câmeras IP.

g. O sistema deverá ter capacidade de gerenciar as imagens gravadas em dispositivos de

armazenamento embarcado na própria câmera. A câmera deverá gerenciar a gravação e armazenamento interno do vídeo, eliminando a necessidade do envio constante dos streams de vídeo para o servidor de gravação. O sistema deverá possibilitar a transferência seletiva dos streams de vídeos gravados dentro da câmera para o servidor de armazenamento.

h. O sistema deverá ter possibilidades de interligar-se a sistemas de controle de acesso e outras

aplicações verticais através de módulos de interface (plug-ins) ou através de desenvolvimentos específicos com utilização de kits de desenvolvimento de software (SDK).

i. O sistema deverá ser composto por aplicações “servidores para gerenciamento e gravação

de imagens” e “aplicações cliente para monitoramento”. Ambas as aplicações deverão rodar em ambiente Windows® XP Professional com Service Pack 3, Windows® Vista Service Pack 1, Windows® 7, Windows® 8, Windows® 2003 Server, Windows® 2008 Server ou Windows® 2012 Server. Ambas as aplicações poderão ser instaladas na mesma estação de monitoramento ou em estações de monitoramento separadas. Ambas as aplicações deverão ser capazes de funcionar em redes separadas.

j. As aplicações do sistema deverão enviar as informações de vídeo, áudio e alarmes, em

pacotes IP através de Rede Local (LAN – Local Área Network) ou Rede de Longa Distância (WAN – Wide Area Network) para manter canais de comunicação abertos e para



permitir que as estações de monitoramento e servidores de gravação fiquem alojadas em diferentes locais, incluindo configurações multi-locais.

k. O sistema deverá possuir um módulo interno de supervisão de funcionamento (watchdog)

para detectar e recuperar os serviços a partir da improvável ocorrência de travamento do sistema.

l. O sistema deverá permitir configurações de fuso horário para cada câmera conectada nos

codificadores de vídeo (encoders) ou câmeras IP, e para cada módulo servidor de gerenciamento e gravação.

m. O sistema deverá ser capaz de receber atualizações de uma versão para outra, sem a

necessidade de desinstalação da versão anterior.

n. Vídeo sobre IP

i. Todos os streams de vídeo provenientes das câmeras analógicas e/ou câmeras IP deverão ser codificados em formato digital utilizando as tecnologias de compressão de vídeo Wavelet, JPEG2000, MJPEG, MPEG-2, MPEG-4 ou H.264, e gravados simultaneamente em tempo real.

ii. Todos os streams de áudio provenientes das câmeras analógicas ou câmeras IP

deverão ser codificados digitalmente em formato de compressão g711 (ulaw), g721, g723 ou AAC, e gravados simultaneamente em tempo real.

iii. O sistema deverá ser uma solução completa de vídeo digital capturando vídeo de

câmeras IP ou analógicas e convertendo-o em vídeo digital através de codificadores inteligentes (encoders) e transmitindo essas informações aos servidores de gravação e estações de monitoramento utilizando protocolo IP (Internet Protocol).

iv. As larguras bandas de rede a serem utilizadas na transmissão dos streams de vídeo

controladas pelos encoders deverão variar de acordo com a resolução da imagem (CIF), com a velocidade de transmissão da imagem (FPS) e com a tecnologia de compressão de vídeo utilizada por cada fabricante dos encoders e câmeras IP.

v. Considerando que o hardware a ser ofertado disponibilizará vários streams de vídeo

a partir da mesma fonte (câmera IP ou encoder), o sistema deverá possibilitar que as configurações dos parâmetros de taxas de transmissão (Kbps/Mbps), velocidade de imagem (FPS) e resolução da imagem (CIF) possam ser feitas de forma independente para cada um desses streams de vídeo, e a alteração desses parâmetros não deverá afetar os parâmetros dos streams de visualização e gravação das demais câmeras, mesmo que os streams sejam gerados com tecnologias de compressão diferentes (Wavelet, JPEG2000, MJPEG, MPEG-2, MPEG-4 ou H.264).

o. Armazenamento

i. O sistema deverá armazenar vídeo e áudio digitais capturados a partir de câmeras IP

ou a partir de câmeras analógicas e convertidas em digital através de codificadores inteligentes (encoders). O sistema deverá fazer esse armazenamento em uma estrutura de dados própria e proteger todos esses arquivos de áudio/vídeo armazenados como também o banco de dados do sistema contra acessos não autorizados via rede, e contra acessos de usuários não administradores. O sistema



deverá assinar digitalmente os vídeos armazenados usando criptografia de alta segurança.

ii. O sistema deverá utilizar uma base de dados de eventos e seus indicadores de tempo

de gravação para permitir buscas avançadas em arquivos de áudio e vídeo armazenados.

iii. O sistema deverá ter uma arquitetura de armazenamento de dados abrangente com

tolerância a falhas e que os dados possam simultaneamente ser armazenado em outro local, caso seja identificada uma falha de comunicação com o servidor de gravação original. A arquitetura do servidor distribuído deverá permitir que cada subsistema opere de maneira independente, sem afetar a gravação ou a exibição de vídeo. A gravação dos dados deverá ter possibilidade de armazenamento redundante, usando dois servidores separados, podendo os mesmos serem instalados em locais diferentes. O banco de dados replicado deverá ser inicialmente e continuamente sincronizado com o banco de dados do servidor principal para garantir que esteja sempre atualizado e pronto para assumir a sistema em decorrência de falha de comunicação.

iv. O sistema deverá fornecer opção de armazenamento baseada em situações de pré-

alarmes e pós-alarmes.

v. O sistema deverá fornecer funcionalidades de armazenamento de streams de vídeo e áudio baseados em disparo automático causados por vários tipos de eventos.

vi. As configurações para armazenamento de vídeo e áudio do sistema são:

Interna ou externa IDE organizadas ou não em configuração RAID,

Interna ou externa SCSI/Fiber Channel organizadas ou não em configuração

RAID,

Deverá ser possível também o armazenamento em sistemas de armazenamento em discos em PC’s externos localizados em uma LAN ou WAN;

Em sistemas de armazenamento (storage) NAS em uma LAN ou WAN;

p. Em sistemas de armazenamento (storage) SAN.

i. O sistema não deverá limitar a capacidade de armazenamento atual configurada por servidor de gravação, podendo essa ser reconfigurada e expandida a qualquer tempo de acordo com as necessidades e disponibilidade de espaço para armazenamento ou até incluir novos sistemas de armazenamento.

ii. O sistema deverá permitir o acoplamento de subsistemas de armazenamento de

longo prazo através de qualquer unidade de backup em fita suportada pelo sistema operacional Windows.

iii. O sistema deverá possibilitar a transferência seletiva dos streams de vídeos gravados

dentro das câmeras para o servidor de gravação. O sistema deverá possibilitar que sua própria ferramenta de configuração possa criar filtros de seleção e agendamentos



para que apenas streams de vídeos específicos possam ser transferidos e que isso possa ser feito em horários quando o tráfego da rede esteja com baixa utilização. Esta característica deverá suportar câmeras e encoders de vários fabricantes, que tenham capacidade de armazenamento interno.

q. Independência de Hardware

i. O sistema não deverá obrigar o uso de equipamentos ou PC’s proprietários para

processamento e armazenamento das imagens e nem exigir hardwares multiplexadores ou equipamentos com tecnologia de divisão de tempo para gravação e visualização de vídeo ou áudio.

ii. O sistema deverá ser capaz de recuperar e definir a posição atual de câmeras PTZ,

utilizando as coordenadas XYZ,

iii. O sistema deverá ter capacidade de gerenciar simultaneamente codificadores de vídeo (encoders, decoders), codificadores de áudio e Entradas/Saídas digitais (encoders) e câmeras IP fixas e móveis de no mínimo 50 fabricantes.

iv. O sistema deverá ter capacidade para suportar padrões da indústria para interface

com produtos de segurança física baseado em IP, tais como: ONVIF Versão 1.02 ou superior.

v. O sistema deverá ter capacidade de gerenciar múltiplos protocolos de PTZ,

suportando acima de 80 protocolos de diversos fabricantes.

vi. O sistema deverá ter capacidade de gerenciar também outros tipos de protocolos especializados de câmeras PTZ, tais como: câmeras térmicas, infravermelho, etc.

vii. O sistema deverá ter capacidade de suportar múltiplos teclados de CFTV para

controle de PTZ, suportando no mínimo 15 protocolos de diversos fabricantes.

viii. O sistema deverá ter capacidade de suportar hardwares de matrizes analógicas de CFTV, possibilitando controlar suas câmeras como se estivessem conectadas a encoders.

ix. O sistema deverá ter capacidade de suportar hardwares e sistemas de controle de

acesso de terceiros e seus respectivos protocolos de comunicação, tais como:

Pelco 9760-Data Translator GE Picture Perfect Hirsch Velocity Lenel OnGuard RBH Axiom V Software House C-Cure 9000 Verex Monitor xL

r. O sistema deverá possuir integração com sistemas de visualização analógica (vídeo walls),

tais como: i. Barco,

ii. Mauell.



s. Protocolos e Compatibilidades

i. O sistema deverá ser capaz de utilizar teclados de CFTV de vários fabricantes, conectados diretamente a conversores de vídeo (encoders / decoders) via porta serial e possibilitar a visualização e controle de PTZ de imagens ao vivo utilizando um PC.

t. O sistema deverá possibilitar que os usuários possam acionar todos os controles de

visualização ao vivo (PTZ), utilizando um teclado padrão de PC, mouses de PC´s e controladores de jogos padrão joystick. Todos os controles padrões de chaveamento e automação de câmeras, através de um teclado de CFTV, deverão estar disponíveis usando um teclado padrão de PC.

u. O sistema deverá ser compatível com múltiplos teclados de controle de CFTV para

operação das câmeras e suas funcionalidades PTZ, suportando vários protocolos de controle de câmeras PTZ e vários protocolos de teclados de CFTV. O sistema não deverá limitar a utilização de câmeras e controladores de diferentes fabricantes (exemplo: controles de teclado Pelco e câmeras Axis ou vice-versa).

v. O sistema deverá suportar eventos de análise inteligente de vídeo do tipo “objetos cruzando

uma linha virtual”, “detecção de movimento”, etc., detectados diretamente pela câmera, quando estas oferecerem estas funcionalidades e forem compatíveis com o sistema. Esses eventos deverão ser armazenados juntamente com o vídeo que os gerou.

w. O sistema deverá suportar eventos de análise inteligente de vídeo de reconhecimento de

objetos e análise comportamental, através da integração com sistemas de terceiros, como segue:

i. Reconhecer pessoas, veículos ou outros objetos em movimento a partir de um fundo

estático.

ii. Reconhecer a velocidade de objetos em movimento.

iii. Detectar eventos como:

Objetos aparecidos em cena. Ex. um submarino emergindo.

Objetos desaparecidos da cena. Ex. um submarino submergindo.

Objetos separados. Ex. um objeto separado em dois.

Objetos agrupados. Ex. dois objetos transformados em um.

Objetos abandonados.

Objetos removidos.

Objetos parados. Ex. um objeto que está em movimento e para repentinamente.

Intrusão. Ex. objetos ultrapassando uma cerca virtual.

Objetos entrando em uma área pré-definida.



iv. Deverá ser capaz de evidenciar vários objetos detectados no vídeo, colocando uma

moldura em torno de cada objeto, e seguir seus movimentos. x. O sistema deverá possuir integração com sistemas de análise inteligente de vídeo, como por

exemplo: Agent VI; Bosch; IBM S3; ioimage; iOmniScient 3.0; Keeneo; Lumenera; Mango DSP; ObjectVideo VEW 5.0; Panasonic; Pelco; Phoenix e Sony.

i. Conectividade

Todas as aplicações do sistema deverão suportar qualquer forma de

conectividade de redes IP, incluindo: LAN, WAN, VPN, Internet e tecnologias sem fio (WiFi e celular).

y. O sistema deverá usar protocolos de comunicação de rede UDP/TCP/IP sobre LANs e

WANs, com a largura de banda configurável. z. Todas as aplicações deverão suportar streams de vídeo IP Multicast (UDP) e Unicast (TCP

ou UDP). aa. As aplicações Cliente de Visualização poderão ser configuradas em multicast via servidor,

mesmo que a rede esteja trabalhando em unicast. bb. Todas as aplicações deverão se adaptar automaticamente à topologia de rede e usar o

melhor método disponível para receber os streams de vídeo. cc. Certificação Digital e Segurança dd. O sistema deverá assinar digitalmente os vídeos armazenados, utilizando criptografia RSA

de chave público-privada de pelo menos 248 bits, e possibilitar ao usuário fazer a substituição das chaves de criptografia.

ee. O sistema deverá criptografar o canal de controle dos serviços de vídeo sobre IP usando o

padrão SSL (Secure Sockets Layer). ff. As aplicações de servidores do sistema deverão transmitir todos os comandos e mensagens

de controle usando o protocolo de comunicação TCP/IP e usar chaves de criptografia baseadas em protocolo SSL V.3.0 quando comunicando com os codificadores de vídeo (encoders / decoders) de forma a prevenir acessos não autorizados através da rede de comunicação, violação, ou falsificação de mensagens.

gg. O sistema deverá suportar o protocolo HTTPS (Hypertext Transfer Protocol Secure) quando

comunicando com câmeras IP e codificadores de vídeo (encoders / decoders) que tenham estas características suportadas pelo sistema.

hh. Aplicativos: ii. O sistema deverá possuir os seguintes aplicativos, cujas especificações estão detalhadas nas

seções seguintes deste documento:

i. Aplicações de Servidores de Vídeo Digital



ii. Servidor de Diretório Principal do Sistema

iii. Diretório de Contingência do Sistema (standby)

iv. Gerenciador de Canais de Comunicação (Gateway)

v. Servidor de Integração de Múltiplos Sistemas (Federação)

vi. Servidor de Gravação (local e remoto)

vii. Servidor de Gravação de Contingência (standby)

viii. Servidor de Gravação Redundante (local e remoto)

ix. Servidor de Gravação Auxiliar

x. Módulo de Restauração de Imagens Arquivadas

xi. Módulo Gerador de Imagens para Publicação (Media Gateway)

xii. Módulo Gerador de Metadados

xiii. Matriz Virtual

xiv. Matriz Virtual de Contingência

xv. Módulo Interno de Supervisão de Operação (Watchdog)

xvi. Servidor de Administração

jj. Aplicações Clientes (Estações de Monitoramento)

i. Ferramenta de Configuração

ii. Monitor de Visualização ao Vivo

iii. Monitor de Visualização de Vídeos Gravados

iv. Monitor Web de Visualização ao Vivo

v. Monitor Web de Visualização de Vídeos Gravados

vi. Editor de Macros

vii. Visualizador de Relatórios kk. Aplicações Compactas de Vídeo Digital em Rede – Aplicações Estacionárias

i. Aplicações Servidores Embarcados em Hardwares Específicos: Servidor de Diretório Principal do Sistema



Gerenciador de Canais de Comunicação (Gateway) Servidor de Gravação (local) Módulo de Restauração de Imagens Arquivadas Matriz Virtual Módulo Interno de Supervisão de Operação (Watchdog) Servidor de Administração

ii. Aplicações Cliente Embarcadas em Hardwares Específicos:

Ferramenta de Configuração Monitor de Visualização ao Vivo Monitor de Visualização de Vídeos Gravados Monitor Web de Visualização ao Vivo Monitor Web de Visualização de Vídeos Gravados Visualizador de Relatórios

ll. Aplicações de Servidores de Vídeo Digital

i. Características Gerais

Os servidores de vídeo deverão ser compostos pelos seguintes módulos: Servidores de Diretório Principal e contingência; Módulos de Gerenciamento de Canais de Comunicação entre os componentes do sistema; Servidor de Gerenciamento de Integração de Múltiplos Sistemas (Federação); Servidores de Gravação Local, Remota e Contingência; Servidores de Gravação Redundante (Local e Remoto); Servidores de Gravação Auxiliar; Módulo de Restauração de Imagens Arquivadas; Módulo de Geração de Imagens para Publicação; Módulos de Gerenciamento de Geração de Metadados; Matriz Virtual e contingência; Módulo Interno de Supervisão de Operação (Watchdog) e Servidor de Administração

Os módulos de serviços e servidores devem ser possíveis de serem instalados

em múltiplos computadores, permitindo o armazenamento e gestão distribuída de imagens em ambientes de rede LAN ou WAN.

O sistema não deverá limitar número de computadores PC´s que poderão

estar conectados em rede para formarem um sistema distribuído de servidores de gravação (sistema de armazenamento distribuído).

Os módulos dos servidores deverão ser possíveis de funcionar em servidores

virtuais usando o sistema de virtualização: VMware ESX/ESXi 3.x. 4.x e 5.x.

mm. Servidor de Diretório Principal

i. O servidor de diretório principal do sistema (Servidor Principal do Sistema) deverá manter um catálogo das configurações em um banco de dados de configurações, de todos os componentes do sistema: Softwares Servidores, Softwares de Aplicações Clientes e codificadores de vídeo (encoders e decoders) ou câmeras IP.



ii. O servidor de diretório principal deverá possibilitar que os softwares de aplicações clientes possam dinamicamente criar conexões entre todos os diferentes codificadores de vídeo (encoders e decoders) ou câmeras IP conectados em toda a rede, através de um stream individual (áudio, vídeo, portas seriais e entradas e saídas digitais).

iii. O servidor de diretório principal deverá possibilitar a visualização de todos os

codificadores de vídeo (encoders) ou câmeras IP conectados na rede, ainda que eles estejam direcionados a diferentes servidores de gravação.

iv. O servidor de diretório principal deverá ser capaz de detectar a perda do sinal de

vídeo de uma câmera e alertar o administrador do sistema para a tomada de decisão.

v. O servidor de diretório principal deverá receber todos os eventos gerados no sistema, tais como eventos de alarmes, eventos de aplicações, eventos de câmeras, eventos de alarmes de áudio, eventos de módulos de Entrada/Saída, etc., e tomar as ações apropriadas baseadas nos eventos / ações definidas pelo usuário para cada evento individualmente.

vi. O servidor de diretório principal deverá ser capaz de gerenciar individualmente

todos os streams disponíveis no sistema (áudio, vídeo, portas seriais e entradas e saídas digitais). O servidor principal deverá criar ainda, alarmes e manter registros de eventos de alarmes tais como, a perda de sinal de vídeo de alguma câmera, bem como os eventos de alarme (detecção de movimento, disparos de entradas digitais e relês externos de saída), iniciando ações apropriadas de acordo com os parâmetros de ações definidas pelo usuário para cada evento individualmente.

vii. O servidor de diretório principal deverá possibilitar que a Organização tenha um

sistema integrado de gerenciamento de usuários através da sincronização da base de usuários com o Microsoft Active Directory existente na empresa.

viii. O servidor de diretório principal deverá ainda ter as funções de:

ix. Criar e manter trilhas de auditoria de eventos e atividades dos usuários;

x. Gerenciar dinamicamente o uso da largura de banda de rede;

xi. Autenticar os usuários e dar-lhe acesso ao sistema de acordo com uma relação de

direitos pré-definidos;

xii. Deverá ter a capacidade de limitar o máximo número de conexões simultâneas de um determinado usuário;

xiii. Deverá ter a capacidade de gerenciar o tempo de validade das senhas de usuários, e forçar com que elas sejam trocadas após um período de tempo definido pelo administrador do sistema.

xiv. O servidor de diretório principal deverá receber e armazenar diversos eventos, tais

como:

Eventos de Alarmes – disparo, ativação, reativação, redirecionamento, adiamento, reconhecimento do alarme (padrão, alternativa e customizada).



Eventos de Alarmes de Áudio - disparo, ativação, reativação,

redirecionamento, adiamento, reconhecimento do alarme (padrão, alternativa e customizada).

Eventos de aplicações – aplicação conectada ou perdida.

Eventos de Gravação - fila de gravação cheia, parada de gravação, limite de câmeras excedido, início do processo de backup, conclusão do processo de backup com sucesso, falha no processo de backup, impossibilidade de gravação em alguma unidade de disco, impossibilidade de gravação em uma localização específica, perda do banco de dados, recuperação do banco de dados, disco cheio, carga do disco acima de 80%, chaves usuárias de criptografia invalidas, insuficiência de espaço em disco para armazenamento de log’s, parâmetro de proteção de vídeo excedido.

Eventos de câmeras – parada de gravação, arquivo excluído, inclusão de lembrete em visualização de vídeo ao vivo, inclusão de lembrete em visualização de vídeo gravado, detecção de movimento ligada, detecção de movimento desligada, perda de conexão na rede, recebimento de pacotes RTP a partir de múltiplas fontes, gravação iniciada por alarmes, gravação encerrada por alarmes, gravação iniciada por agendamento parametrizado, gravação encerrada por agendamento parametrizado, gravação iniciada por ação programada, gravação encerrada por ação programada, gravação iniciada através de detecção de movimento, gravação encerrada através de detecção de movimento, gravação iniciada pelo usuário, gravação encerrada pelo usuário, perda de pacotes RTP, perda de sinal, recuperação de sinal.

Eventos de entradas digitais – Contatos de entradas digitais abertos, contatos de entradas digitais fechados.

Eventos de Diretório – Conexão perdida com o banco de dados de alarmes, conexão recuperada com o banco de dados de alarmes, coordenador de diretório de contingência não sincronizado, espaço insuficiente em disco para armazenamento de log.

Eventos de encoders e câmeras IP – Configuração inválida no dispositivo, perda de sinal, recuperação de sinal, recuperação da conexão da unidade, perda de conexão da unidade.

Eventos de Federação/Gateway – Redirecionamento iniciado, redirecionamento encerrado.

Eventos de macros – erro de macro, macro iniciada, macro encerrada.

Eventos de módulos de interfaces (plugin) – erro de módulo de interface, módulo de interface iniciado, módulo de interface encerrado, banco de dados fora do espaço do disco.

Eventos de PTZ – Ativação de PTZ, zoom de PTZ por usuário, zoom de PTZ encerrado por usuário, PTZ travado, PTZ encerrado.



Eventos de usuários – conexão de usuário, desconexão de usuário.

xv. O servidor de diretório principal deverá ser capaz de executar quaisquer das seguintes ações em respostas aos eventos citados anteriormente:

Ações para eventos de Gravação – iniciar gravação, parar gravação, adicionar um lembrete em algum momento da gravação, alteração manual da qualidade de gravação, alteração da qualidade de gravação com parâmetros cadastrados no evento, qualidade de gravação como configuração padrão, iniciar a aplicação da proteção de vídeo, parar a aplicação da proteção de vídeo.

Ações para eventos de monitoramento – bloquear uma câmera, desbloquear uma câmera, visualizar uma câmera em um monitor analógico, visualizar uma câmera no módulo de visualização ao vivo, visualizar uma câmera em uma janela livre do módulo de visualização ao vivo, visualizar um mapa no módulo de visualização ao vivo, mostrar o endereço web (URL) no módulo de visualização ao vivo.

Ações para eventos de PTZ – ir para uma posição pré-definida (preset), executar uma ronda padrão (pattern), configurar um PTZ auxiliar, limpar um PTZ auxiliar, ir para a posição inicial.

Ações de notificação de usuários – enviar uma mensagem, enviar um alerta sonoro, enviar um e-mail, disparar um alarme.

Ações de relês de saída – configurar um relê de saída para inverter o estado padrão, configurar um relê de saída para voltar ao seu estado padrão, ligar um relê de saída, desligar um relê de saída, configurar um relê de saída para pulsar (pulso deve ser configurável).

Ações de controle de dispositivos – enviar uma string de informações via porta serial, reiniciar o encoder ou câmera IP.

Ações de macros – executar uma macro.

xvi. O servidor de diretório principal deverá suportar um gerenciamento avançado de alarmes, o qual deverá possibilitar:

Definir alarmes e procedimentos pré-definidos para um usuário específico ou

para um grupo de usuários.

Redirecionar alarmes para usuários de hierarquia superior, caso o alarme não tenha sido reconhecido pelo usuário de destino no tempo pré-configurado.

Possibilitar aos usuários o enfileiramento de alarmes e visualizar o histórico de alarmes.

Mostrar em monitor analógico ou em uma Estação de Monitoramento, um alarme composto por streams de vídeo ao vivo, streams de vídeo gravados ou uma seqüência de imagens do alarme. A combinação dessas opções de



informações a serem mostradas, deverá ser configurável para cada tipo de alarme.

Configurar múltiplas câmeras a serem mostradas na ocorrência de um alarme.

Mostrar alarmes em bloco, salvo ou em modo simples.

Permitir ao administrador definir a prioridade de cada tipo de alarme em intervalo de 1 a 30.

Mostrar um alarme agrupado com alarmes antigos e dados associados. nn. Servidor de Diretório Principal de Contingência

i. O sistema deverá possuir a opção de contingência do servidor de diretório principal, atuando como um substituto do servidor de diretório principal, em estado de prontidão, e preparado para assumir todas as funções em caso de falhas físicas e lógicas do primeiro servidor. Esta operação deverá ocorrer automaticamente em menos de 1 minuto e não deverá requerer qualquer ação por parte dos usuários.

ii. O sistema deverá suportar múltiplos servidores de diretório principal de

contingência, preparados para assumir em cascata as funções do servidor de diretório principal.

iii. Os servidores de diretório principal de contingência deverão manter seus bancos de

dados de configurações sincronizados com o servidor de diretório principal.

iv. O servidor de diretório de contingência deverá estar apto a atuar como um servidor de diretório principal de contingência ou como um servidor de diretório local de contingência.

v. O servidor de diretório principal de contingência será aquele que poderá assumir toda a carga de atribuições do servidor de diretório principal.

vi. O servidor de diretório local de contingência tem como finalidade assumir apenas parte da carga de atribuições do servidor principal, tipicamente aplicações dentro da mesma rede local LAN. Neste cenário, quando o servidor de diretório principal falhar, todos os servidores de diretórios locais de contingência deverão iniciar simultaneamente com cada um assumindo parte da carga total.

vii. O sistema deverá aceitar configurações com ambas as características de servidor de diretório principal de contingência e servidor de diretório local de contingência.

viii. Cada local que contar com um servidor de diretório local de contingência deverá ser capaz de operar independentemente dos demais.

oo. Gerenciador de Canais de Comunicação (Gateway)

i. O gerenciador de canais de comunicação deverá funcionar como uma porta de entrada de todas as aplicações clientes e servidores de vídeo para o servidor de



diretório principal do sistema, independente de onde eles foram conectados, seja na mesma rede (LAN), ou redes remotas (LAN), ou via Internet.

ii. O sistema deverá permitir o uso de múltiplos gerenciadores de canais de comunicação para aumentar a disponibilidade de serviços em grandes sistemas de forma a propiciar um balanceamento de carga automático ou controlado manualmente.

iii. Cada gerenciador de canais de comunicação deverá ser capaz de assumir a carga dos demais, se um deles ficar indisponível. Essa transferência deverá ser transparente para as aplicações clientes e servidores.

pp. Servidor de Integração de Múltiplos Sistemas (Federação)

i. O servidor de integração de múltiplos sistemas deverá ser a ponte para agrupar múltiplos e independentes sistemas agrupando-os de forma a montar um grande sistema de vídeo monitoramento.

ii. O servidor de integração de múltiplos sistemas deverá possibilitar que os usuários do servidor principal possam visualizar simultaneamente câmeras de outros sistemas independentes, membros da federação, como se essas câmeras pertencessem ao mesmo sistema.

iii. O servidor de integração de múltiplos sistemas deverá possibilitar o agrupamento de vários sistemas rodando diferentes versões de software simultaneamente.

iv. O servidor de integração de múltiplos sistemas deverá possibilitar a visualização de vídeo ao vivo ou vídeo gravado de qualquer um dos sistemas agrupados.

v. O servidor de integração de múltiplos sistemas possibilita que o servidor principal possa receber os eventos gerados por qualquer encoder ou câmera IP pertencentes aos demais sistemas agrupados.

qq. Servidor de Gravação

i. O servidor de gravação deverá utilizar uma base de dados de eventos e seus indicadores de tempo de gravação para permitir buscas avançadas em arquivos de áudio e vídeo gravados. Esta base deverá ser compatível com sistemas Microsoft SQL 2005, Microsoft SQL 2008 ou Microsoft SQL 2000 Enterprise Server com Service Pack 4.

ii. O servidor de gravação deverá armazenar vídeo em base de dados própria e proteger todos os arquivos de áudio/vídeo gravados e o banco de dados do sistema contra acessos não-autorizado via rede, e contra acessos de usuários não administradores.

iii. O servidor de gravação deverá assinar digitalmente os vídeos armazenados usando criptografia RSA de chave pública/privada de 248 bits, possibilitando o usuário a troca da chave de criptografia.

iv. O servidor de gravação deverá oferecer serviços de localização de hardware do tipo plug-and-play, capaz de:



v. Descobrir automaticamente as unidades no momento em que se conectam à rede,

vi. Descobrir as unidades em segmentos de redes diferentes incluindo Internet, através de roteadores com ou sem capacidade de tradução de endereço de rede (NAT).

vii. O servidor de gravação deverá fornecer opção de armazenamento baseado em situações de pré-alarmes e pós-alarmes os quais podem ser configurados em intervalos de 1 segundo a 5 minutos, sendo esta configuração individual por câmera.

viii. O servidor de gravação deverá fornecer funcionalidades de armazenamento de streams de vídeo e áudio baseados em disparo automático causados por eventos com:

Detecção de movimento digital; Ativação através de entrada digital; Através de macros; Através de aplicações de gravação utilizando SDK.

ix. O servidor de gravação deverá realizar detecção de movimento em vídeo sobre

imagens individuais de câmeras baseados em uma grade de 1320 blocos de detecção de movimento. O servidor de gravação deverá permitir que todas as configurações de detecção de movimento para gravação possam ser parametrizadas por agendamento, por dias da semana e horários, podendo ser parametrizados vários dias da semana e vários horários por dia. O servidor de gravação deverá possuir um padrão de sensibilidade global, de forma a reduzir a detecção falsa de movimentos onde exista sinal vídeo com muito ruído ou a incidência de falsas movimentações. O servidor de gravação deverá possibilitar a configuração de detecção de movimento pelos seguintes modos:

x. Tela Cheia – o servidor de gravação deverá disponibilizar todos os 1320 blocos de detecção ativados, onde as configurações de detecção de movimento deverão ser configuradas formando um padrão de sensibilidade geral para a tela cheia, e quando este padrão de detecção for alcançado, deverá disparar a gravação e um evento de movimento, ou um evento de usuário;

xi. Tela Cheia no encoder – deverá tratar a detecção de movimento conforme definido para a “Tela Cheia” porem a detecção ocorre no encoder ou na câmera IP.

xii. Zonas de Detecção - o Servidor de Gravação deverá possibilitar mais que cinco zonas detecção com possibilidade de sobreposição, as quais poderão ser definidas utilizando os 1320 blocos da tela. Cada zona de detecção deverá possuir seu próprio padrão de sensibilidade configurável individualmente, e quando algum deles for sensibilizado, deverá ter possibilidades de disparar uma gravação, um evento de detecção de movimento, ou um evento de usuário. Com o disparo de eventos de cada zona de detecção deverá permitir a configuração de detecção de movimentos direcionais e outras lógicas complexas de detecção de movimento.

xiii. Zonas de Detecção no encoder – deverá tratar a detecção de movimento conforme definido para as “Zonas de Detecção”, porém a detecção deverá ocorrer no encoder ou câmera IP e pelo menos uma zona de detecção deverá ser suportada.

xiv. Desativada – Não deverá ser feita detecção de movimento no encoder ou câmera IP.



xv. O servidor de gravação deverá permitir a definição de múltiplos agendamentos de gravação de vídeo, para uma única câmera. Cada agendamento poderá ser criado a partir dos seguintes parâmetros:

xvi. Parâmetros relativos ao modo de gravação: Contínuos Na ocorrência de alarmes/detecção de movimento Manual Desabilitado Parâmetros relativos à recorrência de padrões: Uma vez em dias específicos Dias específicos parametrizados anualmente Dias específicos parametrizados mensalmente Dias específicos parametrizados semanalmente Diariamente Parâmetros relativos a tempo de cobertura Todo o dia Períodos específicos de tempo Diurno ou noturno baseado nos horários de nascer e pôr do sol, calculado

automaticamente a partir do período do ano e da localização geográfica. Deverão ser dadas algumas informações para compensar o nascer ou pôr do sol em mais ou menos 3 horas.

xvii. O servidor de gravação deverá permitir que cada fonte de vídeo (câmera IP ou

encoder) seja comprimida múltiplas vezes no mesmo ou em diferentes formatos de vídeo (MPEG-4, MPEG-2, MJPEG, H.264, Wavelet ou JPEG2000), limitado apenas a capacidade de cada encoder ou câmera IP.

xviii. Quando múltiplos streams de vídeo estiverem disponíveis a partir da mesma câmera

ou encoder, os usuários deverão estar livres para utilizar qualquer um deles baseados em suas definições de uso. Os usos padrões de vídeos deverão ser:

Visualização ao vivo Gravação Remoto Baixa Resolução Alta Resolução

xix. O servidor de gravação deverá permitir que a qualidade de vídeo possa variar de

acordo com agendamentos pré-definidos. Tais agendamentos deverão ter a mesma flexibilidade de configuração conforme mencionado anteriormente para agendamentos de gravação. A qualidade de vídeo poderá ser baseada nos parâmetros seguintes, porém não limitada aos mesmos:

Taxa máxima de transmissão (bit rate) Velocidade máxima de imagem (frame rate) Qualidade de imagem Intervalo do “Key Frame”

xx. O servidor de gravação deverá ter a capacidade de aumentar automaticamente a

qualidade do stream de gravação baseando-se em eventos específicos:

xxi. Quando a gravação for iniciada manualmente pelo usuário



xxii. Quando a gravação for disparada por uma macro, um alarme ou detecção de

movimento.

xxiii. O servidor de gravação deverá ter a capacidade de se comunicar com os encoders e câmeras IP usando uma criptografia SSL (Secure Sockets Layer) de 128 bits.

xxiv. O servidor de gravação deverá ter a capacidade de se comunicar com os encoders e câmeras IP usando protocolo de segurança HTTPS (Hypertext Transfer Protocol Secure).

xxv. Em topologias de rede que restringem o envio de streams de vídeo multicast UDP a partir do encoder, o servidor de gravação deverá redirecionar os streams de vídeo / áudio para ativarem as estações de monitoramento na rede usando multicast UDP.

xxvi. O servidor de gravação deverá capacitar o administrador com um completo grupo de opções de ferramentas de gerenciamento de disco:

O servidor de gravação deverá permitir que o administrador escolha os discos a serem usados para armazenamento de vídeo e definir o máximo de área a ser usada em cada disco.

xxvii. O servidor de gravação deverá permitir que o administrador espalhe o armazenamento de diferentes câmeras em diferentes grupos de discos (grupos de discos controlados pela mesma controladora), então o armazenamento poderá ocorrer em paralelo em múltiplos discos.

xxviii. O servidor de gravação deverá oferecer as seguintes opções de limpeza de arquivos velhos, individualmente por câmera:

Após uma quantidade pré-definida de dias

Deletando primeiramente os arquivos mais velhos quando o disco ultrapassou a área definida

Parar o armazenamento quando o disco estiver cheio.

xxix. O servidor de gravação deverá permitir a proteção de seqüências importantes de vídeo contra rotinas normais de limpeza de disco.

xxx. Os usuários deverão ter as seguintes opções de proteção de seqüências de vídeo

Até uma data específica Por uma quantidade específica de dias Indefinidamente, até que a proteção seja removida explicitamente.

xxxi. O servidor de gravação deverá permitir que o administrador coloque um limite de

porcentagem de espaço de armazenamento ocupado por vídeos protegidos.

xxxii. O servidor de gravação deverá manter um log e estatísticas organizadas sobre o uso de espaço em disco.

xxxiii. As estatísticas deverão estar disponíveis por grupo de discos ou de todo o servidor de gravação



xxxiv. As estatísticas deverão mostrar a porcentagem de vídeo protegido sobre o total de

espaço de disco usado.

xxxv. O servidor de gravação deverá ter a capacidade de agendar cópias de segurança (backups) de vídeos armazenados com seus respectivos bancos de dados de eventos em drives locais ou em qualquer drive mapeado na rede.

xxxvi. O servidor de gravação deverá ter a capacidade de reduzir a velocidade de

transmissão dos streams de vídeo para economia de armazenamento em disco, com as seguintes opções:

Para streams MPEG-4 as opções são: todos key frames, 1 fps, 2 seg/frame, 5 seg/frame, 10 seg/frame, 15 seg/frame, 30 seg/frame. 60 seg/frame 120 seg/frame

Para streams MPEG-2 as opções são: 5 fps, 2 fps, 1 fps, 2 seg/frame, 5 seg/frame, 10 seg/frame, 15 seg/frame, 30 seg/frame, 60 seg/frame 120 seg/frame

Para streams MJPEG as opções são: 15 fps, 10 fps, 5 fps, 2 fps, 1 fps, 2 seg/frame, 5 seg/frame, 10 seg/frame, 15 seg/frame, 30 seg/frame, 60 seg/frame 120 seg/frame

Para streams H.264 as opções são: todos key frames, 1 fps, 2 seg/frame, 5 seg/frame, 10 seg/frame, 15 seg/frame, 30 seg/frame. 60 seg/frame 120 seg/frame

xxxvii. O servidor de gravação deverá suportar encoders e câmeras IP com capacidade de

armazenamento interno e fornecer as seguintes funcionalidades:

xxxviii. Visualizar os vídeos gravados internamente em diferentes velocidades;

xxxix. Transferir os vídeos gravados internamente na câmera e/ou encoder para sua base de dados de imagens, de forma seletiva por agendamento, por evento ou manualmente;

xl. Filtrar os vídeos gravados internamente na câmera e/ou encoder a serem transferidos usando um ou múltiplos filtros:

Intervalo de tempo; Solicitações de vídeo gravado; Eventos de análise inteligente de vídeo; Eventos de detecção de movimento; Lembretes; Alarmes; Eventos de entradas digitais; Eventos de unidade desconectada.

rr. Servidor de Gravação de Contingência

i. O servidor de gravação de contingência deverá atuar como um servidor de contingência de gravação, ativo e pronto para assumir as funções do servidor de



gravação primário. Em caso de falhas do servidor de gravação primário, o servidor de gravação de contingência deverá assumir todas as funções em menos de 1 minuto e nenhuma ação por parte dos usuários deverá ser requerida.

ii. Cada encoder ou câmera IP conectado no sistema deverá ter sua própria lista de servidores de contingência, chamada de lista de servidores de contingência. Quando o servidor de gravação padrão do encoder ou câmera IP falhar, o próximo servidor de gravação de contingência da lista deverá assumir o comando e o controle do encoder ou câmera IP.

iii. Deverá ser possível que um único servidor de gravação atue como servidor de gravação contingência para múltiplos servidores de gravação simultaneamente. Também deverá ser possível que um único servidor de gravação tenha vários servidores de gravação de contingência como contingência.

iv. O sistema deverá possibilitar que qualquer servidor de gravação possa ser definido como servidor de gravação contingência para outros servidores de gravação.

v. O sistema deverá permitir múltiplas camadas de armazenamento de contingência, através das quais se um servidor de gravação falhar, outro assumirá automaticamente o comando e o controle dos encoders ou câmeras IP, e iniciará a gravação dos dados de vídeo e todos os eventos associados daquele ponto no servidor de gravação de contingência. Qualquer servidor de gravação no sistema poderá ter as atribuições do servidor de gravação de contingência.

ss. Servidor de Gravação Redundante

i. O servidor de gravação de contingência deverá ter a possibilidade de atuar como um servidor de armazenamento redundante.

ii. O servidor de gravação redundante deverá manter uma cópia exata de tudo que foi armazenado pelo servidor de gravação padrão, como arquivos de vídeo/áudio, eventos, lembretes, e alarmes.

iii. A parametrização de redundância deverá ser configurada para cada câmera individualmente.

iv. O servidor de gravação redundante deverá utilizar para gravação, os streams de vídeo ao vivo disponibilizados pelos encoders ou câmeras IP em Multicast e não deverá requerer nenhuma conexão adicional com esses encoders ou câmeras IP.

v. O servidor de gravação redundante deverá usar as capacidades de redirecionamento dos streams e de balanceamento de carga da rede de dados através dos serviços de canais de comunicação disponíveis (Gateways).

tt. Servidor de Gravação Auxiliar

i. O servidor de gravação auxiliar deverá ser usado para produzir arquivos redundantes de vídeo, eventos e lembretes de qualquer câmera conectada no sistema, sendo que as câmeras deverão ser utilizadas caso a caso.



ii. O servidor de gravação auxiliar deverá ser capaz de armazenar streams de vídeo de uma câmera em agendamentos diferentes aos do servidor de gravação.

iii. O servidor de gravação auxiliar deverá ser capaz de armazenar qualquer um dos streams de vídeo disponíveis, como por exemplo: stream para visualização ao vivo, stream para gravação, stream remoto, stream de baixa resolução e stream de alta resolução.

iv. Módulo de Restauração de Imagens Armazenadas

v. O módulo de restauração de imagens armazenadas deverá ter a capacidade de realizar a restauração de arquivos de vídeo a partir de cópias de segurança, recuperando a base de dados de vídeo e toda a informação relacionada a ela, e possibilitar que todas as informações das cópias de segurança fiquem disponíveis para o sistema original ou para qualquer outro sistema.

vi. O módulo de restauração de imagens armazenadas deverá ter a opção de restaurar parcialmente uma cópia de segurança.

vii. Módulo Gerador de Imagens para Publicação

O módulo gerador de imagens para publicação deverá disponibilizar os streams de vídeo do sistema para um servidor de mídia externo, permitindo a publicação do vídeo via broadcast em um formato padrão. O módulo gerador de imagens para publicação deverá converter os streams de vídeo em um formato suportado pelo Windows Media Server.

O módulo gerador de imagens para publicação deverá permitir a

configuração da resolução e possuir um gerador de caracteres para inclusão de textos sobre o vídeo.

viii. Módulo Gerador de Metadados

O módulo gerador de metadados deverá expandir as funcionalidades do

sistema através do uso de módulos de interface de geração metadados desenvolvidos para integração com aplicações de terceiros.

Os módulos de interface de geração de metadados deverão dar ao sistema a capacidade de processar as seguintes funcionalidades:

o Interface com softwares de reconhecimento de objetos o Interface com softwares de reconhecimento de placas de veículos o Interface com softwares geradores de relatórios de incidentes o Interface com sistemas de controle de acesso o Interface com softwares de ponto de venda.

O módulo de interface de geração de metadados deverá ter o mapeamento

dos encoders, câmeras IP ou outros dispositivos do sistema, e extrair / coletar desses dispositivos mapeados, as informações pertinentes as necessidades de cada processo, chamadas de metadados.



O módulo de interface de geração de metadados deverá criar eventos de metadados que possam ser consultados e mostrados nas linhas de tempo dos arquivos de vídeo.

Os metadados coletados pelo módulo de interface de geração de metadados a partir das câmeras do sistema deverão ser mantidos em um banco de dados. Os critérios usados para consultas aos metadados deverão estar relacionados a cada tipo de módulo de interface de geração de metadados.

As execuções dos módulos de interface de geração de metadados deverão ser controladas por agendamentos. Os agendamentos deverão definir um padrão de recorrência e um período de cobertura, conforme definido anteriormente.

O administrador deverá ter possibilidade de controlar o período de retenção dos metadados de cada módulo de interface de geração de metadados independente dos demais.

O módulo gerador de metadados deverá assinar digitalmente os metadados armazenados usando criptografia RSA de chave pública / privada de 512 bits, possibilitando o usuário a troca da chave de criptografia.

O sistema deverá aceitar a execução de múltiplas instâncias de módulo

gerador de metadados.

O módulo gerador de metadados deverá suportar módulo de interface de geração de metadados de reconhecimento de objetos e análise comportamental, através da integração com sistemas de terceiros, com as seguintes funcionalidades:

o Reconhecer pessoas, veículos ou outros objetos em movimento a partir de um fundo estático.

o Reconhecer a velocidade de objetos em movimento. o Detectar eventos como: o Objetos aparecidos em cena. Ex. um submarino emergindo. o Objetos desaparecidos da cena. Ex. um submarino submergindo. o Objetos separados. Ex. um objeto separado em dois. o Objetos agrupados. Ex. dois objetos transformados em um. o Objetos abandonados. o Objetos removidos. o Objetos parados. Ex. um objeto que está em movimento e para

repentinamente. o Intrusão. Ex. objetos ultrapassando uma cerca virtual. o Objetos entrando em uma área pré-definida. o Deverá ser capaz de evidenciar vários objetos detectados no vídeo,

colocando uma moldura em torno de cada objeto, e seguir seus movimentos.

O módulo gerador de metadados deverá suportar módulo de interface de

geração de metadados para controle de acessos.

ix. Matriz Virtual

A matriz virtual deverá ter a capacidade de criar seqüências de câmeras com as seguintes funcionalidades:



Cada seqüência deverá poder ter até 500 câmeras;

Cada uma das câmeras na seqüência deverá ter seu tempo de permanência

individual, programável de 1 a 999 segundos;

Cada unidade da seqüência deverá ser capaz de disparar pré-sets de câmeras, rotas padrões ou funções auxiliares;

Múltiplos usuários deverão ter capacidade de visualizar simultaneamente a mesma seqüência de câmeras. Os usuários deverão ter capacidade de parar uma seqüência sem afetar outros usuários que estão visualizando essa mesma seqüência.

A Matriz Virtual deverá ser capaz de executar macros em VBScript (ou outras linguagens de script) na ocorrência de eventos ou por agendamentos pré-definidos. Um agendamento deverá definir um padrão de recorrência e um tempo de cobertura, conforme definido anteriormente.

A Matriz Virtual deverá ser capaz de executar módulos de interface de geração de metadados de terceiros, baseado em agendamentos pré-definidos. Um agendamento deverá definir um padrão de recorrência e um tempo de cobertura, conforme definido anteriormente.

A Matriz Virtual deverá ser capaz de ter interface com sistemas de “video walls” através de um teclado de CFTV conectado a um decoder.

A Matriz Virtual deverá possibilitar que os usuários do sistema controlem as câmeras conectadas a uma matriz analógica de CFTV como se essas câmeras estivessem conectadas aos encoders.

O sistema deverá ter a capacidade visualizar uma seqüência de vídeo gravado em um monitor analógico na ativação de um alarme ou evento. O tamanho da seqüência de visualização deverá ser configurável e poder incluir pré e pós-vídeo.

x. Matriz Virtual de Contingência

A Matriz Virtual de Contingência deverá atuar como um substituto das

aplicações de servidores de vídeo, ativo e pronto assumir as funções da Matriz Virtual primária. Em caso de falhas, a Matriz Virtual de Contingência deverá assumir automaticamente todas as funções em menos de 1 minuto e nenhuma ação por parte dos usuários deverá ser requerida.

Cada dispositivo conectado no sistema controlado pela Matriz Virtual (Macros, Seqüência de Câmeras, Matriz Analógica de CFTV, Teclado de CFTV), deverá ter sua própria lista de Matriz Virtual de Contingência chamada de lista de contingência. Quando a Matriz Virtual padrão do dispositivo falhar, a próxima Matriz Virtual de Contingência da lista deverá assumir o comando e o controle do dispositivo.



Deverá ser possível que uma única Matriz Virtual atue como Matriz Virtual de Contingência para múltiplas Matrizes Virtuais simultaneamente. Também deverá ser possível que uma única Matriz Virtual tenha várias Matrizes Virtuais de Contingência como contingência.

Qualquer Matriz Virtual no sistema deverá poder ser definida com Matriz Virtual de Contingência das demais.

Módulo Interno de Supervisão de Funcionamento (watchdog)

O módulo interno de supervisão de funcionamento deverá ter a capacidade de monitorar o funcionamento de todos os serviços dos softwares servidores de vídeo e reinicializá-los em caso de mal funcionamento. Em casos extremos, quando o módulo de supervisão não conseguir reiniciar o sistema, ele deverá ser capaz de reinicializar o próprio equipamento (PC).

xi. Servidor de Administração

O servidor de administração dos recursos do sistema deverá ter a capacidade

de configurar o ambiente de processamento de todos os módulos dos servidores de vídeo, tais como:

o Servidor de Banco de Dados; o Discos de armazenamento; o Tamanhos de arquivos de armazenamento; o Certificados SSL (Secure Sockets Layer); o Chaves de Criptografia; o Opções de Localização dos encoders, decoders e câmeras IP; o Modos de Conexão da Rede; o Endereços e Portas de Conexão da Rede.

xii. Aplicações Clientes (Estações de Monitoramento)

Características Gerais

o A aplicação cliente deverá ser composta pelos seguintes módulos: aplicação de ferramenta de configuração, aplicação de visualização ao vivo, aplicação de Visualização de vídeo gravado, aplicação web de visualização ao vivo, aplicação web de visualização de vídeo gravado, aplicação para edição de macros, e aplicação de geração de relatório de eventos.

o A aplicação cliente deverá ser capaz de executar simultaneamente as seguintes aplicações, sem interferência com nenhuma das operações das aplicações dos servidores de vídeo (gravação, alarmes, etc.):

i. Visualização de câmeras ao vivo em uma Estação de

Monitoramento;

ii. Visualização de câmeras ao vivo em um monitor analógico;



iii. Visualização de seqüências de câmeras ao vivo em uma Estação de Monitoramento;

iv. Visualização de seqüências de câmeras ao vivo em um monitor analógico;

v. Controle de câmeras PTZ; vi. Visualização de vídeo gravado em uma Estação de

Monitoramento;

vii. Visualização de vídeo gravado em um monitor analógico;

viii. Recuperação de vídeo gravado;

ix. Replay instantâneo de vídeo ao vivo em uma Estação de Monitoramento;

x. Replay instantâneo de vídeo ao vivo em um monitor analógico;

xi. Uso de mapas;

xii. Uso de procedimentos pré-definidos;

xiii. Parametrização das configurações do sistema;

xiv. Execução de macros do sistema;

xv. Visualização e gerenciamento de alarmes em uma Estação de Monitoramento;

xvi. Visualização e gerenciamento de alarmes em um monitor analógico;

xvii. Criação e impressão de fotos extraídas de uma fonte de vídeo ao vivo;

xviii. Criação e impressão de fotos extraídas de uma fonte de vídeo gravado;

xix. Bloqueio de câmeras para usuários menos privilegiados;

xx. Desbloqueio de câmeras.

Cada estação de monitoramento rodando as aplicações cliente, exceto as baseadas em ambiente web, deverá estar apta para usar um teclado de CFTV, um teclado de PC, um mouse, ou um controlador de jogos padrão joystick que podem controlar todo o conjunto de câmeras através do sistema, mesmo que o sistema seja composto por câmeras motorizadas produzidas por diversos fabricantes.



Todas as aplicações cliente deverão permitir rodar simultaneamente múltiplas instâncias por um ou vários usuários. O numero de instâncias das aplicações “Visualizador de Vídeo ao Vivo”, “Visualizador de Vídeo Gravado”, “Visualizador Web de Vídeo ao Vivo” e “Visualizador Web de Vídeo Gravado” deverão ser limitadas apenas pelo numero de licenças disponíveis e capacidade da estação de monitoramento (PC).

xiii. Gerenciamento

Todas as aplicações deverão fornecer um mecanismo de autenticação para

verificar a validade do usuário. O administrador, que terá todos os direitos e privilégios, deverá poder definir os direitos de acesso de cada usuário no sistema, tais como:

o Definir horário de conexão baseado em agendamentos o O horário quando o acesso ao sistema será permitido o O horário quando o acesso ao sistema será negado o Definir direitos de acesso aos locais de monitoramento o Locais de monitoramento deverão poder formar agrupamentos

lógicos de câmeras e outros recursos do sistema o Locais de monitoramento deverão poder formar hierarquias o Proibir acesso a um local de monitoramento que deverá negar acesso

a todos os recursos agrupados sob esse local. o Permitir ou negar acesso a determinados tipos de aplicações o Visualização de vídeo ao vivo o Visualização de vídeo gravado o Ferramenta de configuração o Editor de macros o Visualização web de vídeo ao vivo o Visualização web de vídeo gravado o Gerador de imagens para publicação (Media Gateway) o SDK o Definir prioridades e limitações o Sobre a visualização de câmeras o Sobre o controle de PTZ o Sobre o vídeo gravado (limitação a uma quantidade de dias no

passado). o Administração do controle de privilégio de usuários o Criação, exclusão e configuração de locais de monitoramento o Criação e exclusão de encoders e câmeras IP no sistema e atualização

de firmwares o Configuração dos parâmetros de qualidade de vídeo, gravação e

detecção de movimento de câmeras o Configuração de monitores analógicos o Configuração de áudio o Configuração de portas seriais o Configuração de PIN de entrada / saída o Criação, exclusão e configuração de PTZ o Criação, exclusão e configuração de hardware matriz analógica o Criação, exclusão e configuração de agendamentos o Criação, exclusão e configuração de eventos e ações de usuários o Criação, exclusão e configuração de alarmes e exclusão instâncias de

alarmes



o Criação, exclusão e configuração de macros o Criação, exclusão e configuração de seqüências de câmeras o Criação, exclusão e configuração de teclados de CFTV o Criação, exclusão e configuração de sistemas de controle de acesso o Criação, exclusão e configuração de grupo de monitores o Criação, exclusão e configuração de grupo de câmeras o Criação, exclusão e configuração de layouts de visualização o Operadores de cópias de segurança (backup) o Modificação de ID’s lógicos o Criação, exclusão e configuração de módulos de interface de geração

de metadados o Visualização de conexões de aplicações – visualização de conexões

de vídeo; o Privilégios de Visualização de vídeo gravado - Exportação de

arquivos de vídeo; o Privilégios de Visualização de vídeo ao vivo: o Troca das entidades visualizadas: o Trocar do conteúdo da janela de visualização; o Trocar do conteúdo da janela de visualização armado; o Armar / desarmar as janelas de visualização; o Trocar o padrão de janela de visualização; o Trocar a seleção de layouts; o Editar e salvar as configurações de layouts. o Iniciar e parar um ronda; o Editar o tempo de parada da câmera em uma ronda; o Reconhecimento de alarmes; o Redirecionamento de alarmes; o Retardar alarmes; o Comunicação de áudio (ouvir/falar); o Acessar zoom digital; o Fazer um replay instantâneo; o Executar macros; o Trocar teclas de atalho para macros; o Fazer gravação local; o Fazer gravação manual. o Controle de PTZ o Executar operações básicas; o Trocar configurações de foco e íris; o Editar e usar presets; o Editar e usar padrões de rotas; o Editar e usar funções auxiliares; o Usar menus; o Travar PTZ; o Sobrepor PTZ travado. o Outros privilégios o Adicionar, editar e excluir lembretes relacionados aos vídeos; o Visualizar câmeras em um monitor analógico; o Bloquear câmeras; o Enviar mensagens; o Enviar sons; o Enviar e-mails; o Enviar informações em portas seriais;



o Executar ações personalizadas; o Salvar e imprimir fotos extraídas de uma fonte de vídeo; o Disparar um alarme manualmente; o Iniciar uma aplicação cliente em um diretório remoto; o Controlar seqüências de câmeras; o Trocar senhas (password); o Proteger vídeo contra exclusão; o Remover proteção de vídeo; o Excluir arquivos de vídeo; o Trocar opções de aplicações; o Trocar visualização de usuários.

xiv. A aplicação cliente deverá possibilitar o agrupamento de direitos de acessos e

privilégios comuns a vários usuários, definindo um Grupo de Usuário. Os membros de um grupo de usuários deverão herdar os direitos e privilégios do Grupo de Usuários a quem estão subordinados. O agrupamento de usuários deverá ser permitido.

xv. Todas as aplicações cliente deverão suportar o mecanismo de acesso supervisionado,

o qual requer dois usuários (o supervisor e o supervisionado) para entrarem com suas identificações e senhas e assim o usuário supervisionado tenha acesso a aplicação.

xvi. Todas as aplicações cliente, exceto as baseadas em ambiente web, deverão manter

uma área para recebimento de avisos do tipo pop-up para mensagens do sistema que não forem reconhecidas dentro de 10 segundos. Os usuários deverão ter permissão para ler estas mensagens e excluí-las de acordo com sua conveniência.

xvii. A aplicação cliente deverá permitir aos administradores terem a capacidade de

bloquearem streams de vídeo aos usuários de mais baixo nível. A aplicação cliente deverá ter capacidade de configurar 10 ou mais diferentes níveis de usuários, sendo que os usuários com prioridade mais alta poderão bloquear informações de vídeo ao vivo aos usuários com prioridade inferior.

uu. Ferramenta de Configuração

i. A aplicação cliente deverá possuir uma ferramenta de configuração que permita ao administrador ou usuários com privilégios apropriados fazer alterações nas configurações do sistema.

ii. A ferramenta de configuração deverá ter no mínimo as seguintes capacidades:

iii. Deverá proporcionar a administração descentralizada de todo o sistema a partir de qualquer ponto conectado na rede;

iv. Os layouts de câmeras deverão estar disponíveis para todos os usuários do sistema e deverão estar armazenados no diretório principal e habilitados a todas as aplicações cliente de “Visualização de Vídeo ao Vivo” conectadas naquele diretório;

v. Deverá possibilitar a alteração dos parâmetros de qualidade de vídeo (CIF), largura de banda (Mbits) e velocidade da imagem (FPS) individualmente para cada stream de vídeo da câmera tanto para “Visualização de Vídeo ao Vivo” como “Visualização de Vídeo ao Gravado”;



vi. Deverá ter a capacidade de definir acessos e privilégios por grupo de usuários ou por

usuários individualmente;

vii. Deverá proporcionar a capacidade de configurar brilho, contraste e tonalidade de imagem de cada câmera conectada no encoder ou câmera IP;

viii. Deverá proporcionar a capacidade de habilitar a gravação de áudio a partir das unidades encoder ou câmera IP que suportam áudio;

ix. Deverá proporcionar a capacidade de alterar os parâmetros de configuração de áudio, porta serial e dispositivos de entrada/saída de cada unidade encoder ou câmera IP;

x. Deverá proporcionar a capacidade de trocar os nomes de todas as câmeras IP e encoders baseadas na topologia do sistema e adicionar informações descritivas para cada câmera IP ou encoder;

xi. Deverá proporcionar a capacidade de reagrupar câmeras específicas, restringir ou liberar direitos de acesso para esse grupo, podendo isso também ser feito de forma individual para cada usuário;

xii. Deverá proporcionar a capacidade de configurar agendamentos e modos de gravação para cada câmera individualmente, podendo o modo de gravação ser: contínuo, por detecção de movimento e manual, somente manual, desabilitado;

xiii. Deverá fornecer uma ferramenta de ajuda para a criação de macros complexas que podem ser ativadas na ocorrência de um evento. A ferramenta de ajuda deverá estar disponível a partir de uma aba na “Ferramenta de Configuração” da aplicação cliente e deverá permitir que o usuário escolha dentro de uma variedade de comandos comuns e complexos para a criação da macro;

xiv. Deverá suportar a criação de agendamentos para os quais algum dos seguintes aspectos funcionais possa ser anexado:

Definição da qualidade do vídeo para cada um dos streams disponibilizados

por cada câmera; Definição da gravação por câmera;

Definição de detecção de movimento para cada uma das zonas de detecção

criadas na câmera;

Brilho, contraste, tonalidade para cada câmera;

Eventos / ações;

Acessos de usuários;

Execução de seqüências de câmeras;

Execução de macros;



Ocorrência de alarmes.

xv. Deverá suportar a criação de ilimitados agendamentos de gravação e alocar qualquer câmera para qualquer agendamento;

xvi. Deverá detectar e alertar os usuários sobre qualquer conflito dentro dos agendamentos alocados;

xvii. Deverá fornecer ferramentas para definir ações automáticas a serem tomadas em resposta a eventos internos / externos;

xviii. Deverá proporcionar a capacidade de configurar um protocolo de PTZ para a porta serial de um encoder específico e possibilitar o manuseio de um conjunto de domes de vários fabricantes dentro do sistema;

xix. Quando uma nova unidade for adicionada ao sistema, esta deverá ser reconhecida com um nome padrão de dispositivo pré-definido;

xx. Deverá proporcionar a capacidade de configurar câmeras PTZ para retornar a uma função padrão inicial, após um período de inatividade pré-definido. Este período de inatividade deverá ser configurável entre 1 a 7200 segundos.

xxi. Deverá possibilitar copiar as configurações de qualidade de vídeo de uma câmera “de origem”, para uma seleção de todas as câmeras “de destino”, e o software deverá filtrar em quais das câmeras de destino selecionadas, tais configurações são aplicáveis. A aplicação não deve obrigar que as câmeras “de destino” sejam do mesmo tipo da câmera “de origem”.

xxii. Deverá possibilitar habilitar/desabilitar a função “IR-cut filter” das unidades que suportam esta característica no sistema, a partir de um menu em uma janela contextual do visualizador de vídeo ao vivo. Também deverá disponibilizar uma opção automática quando o usuário desejar que a unidade ligue e desligue o filtro automaticamente.

xxiii. Deverá possibilitar habilitar/desabilitar a função de “auto-tracking” de câmeras PTZ que suportam esta característica no sistema, a partir de uma janela de diálogo do visualizador de vídeo ao vivo.

vv. Visualizador de Vídeo ao Vivo

i. O visualizador de vídeo ao vivo da aplicação cliente deverá permitir a visualização de vídeo ao vivo e a comunicação ao vivo através do áudio de cada câmera IP ou encoder individualmente.

ii. O visualizador de vídeo ao vivo deverá ter no mínimo as seguintes características:

iii. Deverá disponibilizar a visualização ao vivo de 1 até 16 streams de vídeo

simultâneos em um monitor 1024 x 768;

iv. Deverá suportar tantos quantos monitores a placa de vídeo do PC for capaz de gerenciar. Cada monitor deverá ser capaz de visualizar de 1 a 16 streams de vídeo simultâneos;



v. Deverá permitir que os operadores possam escolher dentre um possível número de

padrões de visualização de câmeras, de 1 a 16 janelas de visualização simultâneas;

vi. Deverá mostrar todas as câmeras conectadas no sistema e todas as câmeras dos sistemas integrados via servidor de integração de múltiplos sistemas (Federação);

vii. Deverá mostrar todas as seqüências de câmeras criadas no sistema e todas as seqüências de câmeras dos sistemas integrados via servidor de integração de múltiplos sistemas (Federação);

viii. Deverá permitir que os operadores possam controlar as seqüências de câmeras (parar, visualizar, avançar visualização, retroceder visualização), sem afetar as funcionalidades dos demais operadores para visualizar e controlar a mesma seqüência de câmeras;

ix. Deverá mostrar todos os monitores analógicos conectados no sistema;

x. Deverá mostrar todas as câmeras, seqüências de câmeras e monitores analógicos em uma árvore lógica de acesso. O sistema deverá disponibilizar ferramentas que facilite a localização rápida de qualquer câmera com a utilização de parte do seu nome ou de uma descrição;

xi. Deverá possibilitar que o operador possa ser capaz de clicar em uma câmera da árvore lógica de acesso e a arraste para dentro de uma janela de visualização ou para o ícone de um monitor analógico para visualização ao vivo;

xii. Deverá possibilitar que o operador seja capaz de clicar em uma seqüência de câmera da árvore lógica de acesso e a arraste para dentro de uma janela de visualização ou para o ícone de um monitor analógico para visualização ao vivo;

xiii. Deverá possibilitar que streams de vídeo possam ser alocados para janelas de visualização que não estejam visíveis no momento na rota padrão que está sendo visualizada;

xiv. Deverá dar suporte às funções de mapa, de forma que mapas digitais possam ser usados para representar a localização física das câmeras e outros dispositivos através do sistema de monitoramento. Os mapas deverão ter a capacidade de conter hyperlinks que possibilitem a criação de uma hierarquia de mapas interligados. A funcionalidade de mapas deverá ter capacidade de importar mapas de um software gráfico que suporte os formatos de imagem BMP, JPEG e/ou formato de imagens GIF.

xv. Deverá dar suporte ao uso de mapas dinâmicos e interativos, através de integração com softwares de terceiros;

xvi. O operador deverá ter a possibilidade de clicar e arrastar uma câmera de um mapa para uma janela de visualização ao vivo;

xvii. O operador deverá ter a possibilidade de clicar em um ícone de câmera no mapa para iniciar um posicionamento pré-programado da câmera (preset), executar uma rota padrão ou enviar um stream de entrada/saída;



xviii. Deverá dar suporte às funções de procedimentos pré-definidos, que possam ser disparados para execução durante um determinado evento e possam ser usados para fornecer detalhes de instruções para o operador quanto a ações a serem tomadas;

xix. Deverá suportar a tecnologia “touch screen” e permitir ao operador otimizar o monitor para explorar este recurso;

xx. Deverá suportar zoom digital em streams de vídeo ao vivo;

xxi. Deverá suportar rondas de visualização (seqüenciamento automático de layouts de câmeras) com tempos de permanência de imagens pré-definidos através de monitores de visualização (por exemplo: rotação de layouts de 4 imagens para 16 imagens para 1 imagem de tela cheia em intervalos de tempo especificados);

xxii. Deverá possibilitar que os usuários possam escolher qualquer um dos streams de vídeo da câmera para visualização ao vivo;

xxiii. Cada visualizador ao vivo deverá ter um ícone indicando o número de alarmes enfileirados e que estão alocados para o usuário que está na aplicação cliente. Os alarmes também poderão ser mostrados em um painel de alarmes na parte inferior da tela do software. O painel de alarmes deverá mostrar os alarmes ativos, bem como os alarmes reconhecidos pelos operadores, auto-reconhecidos pelo sistema, transferidos e retardados;

xxiv. Deverá habilitar o usuário e realizar uma das seguintes ações na ocorrência de um alarme:

Reconhecer (método padrão); Reconhecer (método alternativo); Reconhecer (método customizado); Retardar (por uma quantidade de segundos pré-definida); Transferir para outro usuário no sistema; Mostrar os procedimentos pré-definidos associados ao alarme; Mostrar o histórico de um alarme; Iniciar o visualizador de vídeo gravado para rever alarmes antigos;

xxv. Deverá habilitar o usuário para disparar um alarme espontaneamente, baseado em

alguma coisa que ele vê na imagem câmera. A imagem da câmera de interesse deverá ser enviada como parte do alarme ao usuário selecionado;

xxvi. Deverá permitir a comunicação de áudio através dos encoders ou câmeras IP. O operador devera ter a opção de utilizar modo full duplex ou half duplex de comunicação, atuando como um sistema de intercomunicação IP. O áudio deverá ser armazenado na mesma base de dados que os vídeos das câmeras;

xxvii. Deverá possibilitar que o operador possa navegar facilmente entre as aplicações cliente bastando posicionar o cursor sobre a funcionalidade e um simples click, dependendo apenas dos direitos de acesso;

xxviii. xxix. Deverá possibilitar que os operadores sejam capazes de controlar PTZ, íris, foco,

relê das domes, rotas padrões, posicionamentos pré-definidos e menus de configurações das domes;



xxx. Deverá possibilitar que os operadores sejam capazes de definir um número ilimitado de rotas padrões e posicionamentos pré-definidas;

xxxi. Deverá habilitar os usuários a controlarem funções de PTZ com:

Teclados padrões de CFTV conectados diretamente a conversores de vídeo (encoders / decoders) via porta serial,

Controladores de jogos padrão joystick conectados ao PC,

Teclado padrão PC,

Mouses de PC´s, e

Posicionando o cursor diretamente sobre a imagem da câmera.

O sistema deverá habilitar as funções pan, tilt e zoom simultaneamente de uma câmera PTZ exibida em uma estação de monitoramento, utilizando um painel específico com os controles PTZ na tela de monitoração e pressionando o mouse com o cursor nos setores direcionais e de controle de zoom.

xxxii. O sistema deverá habilitar as funções pan, tilt e zoom simultaneamente de uma câmera PTZ exibida em estação de monitoramento, utilizando o cursor sobre a imagem da câmera e movimentando o mouse nas direções desejadas.

xxxiii. Deverá permitir que o operador tenha atribuição de prioridades de um PTZ entre 1 e 255. Isto deverá possibilitar a priorização entre operadores que determinará qual operador terá preferência no comando de câmera;

xxxiv. O sistema deverá permitir que os usuários possam ter a possibilidade de bloquear e restringir o controle de PTZ de qualquer câmera. Usuários com maior prioridade de controle de PTZ poderão desbloquear PTZ’s de outros usuários com menor prioridade;

xxxv. Deverá permitir que os operadores possam registrar lembretes em eventos importantes para facilitar sua localização futura em qualquer vídeo gravado das câmeras. Os operadores deverão poder dar nomes a esses lembretes para facilitar futuras pesquisas;

xxxvi. Deverá possibilitar que o operador seja capaz de iniciar e parar manualmente a gravação de qualquer câmera no sistema bastando um click em um simples botão, desde que esta esteja configurada para gravação manual;

xxxvii. Deverá possibilitar que o operador seja capaz de ativar e desativar a visualização de todos os eventos do sistema assim que eles ocorram;

xxxviii. Deverá possibilitar que o operador visualize um replay instantâneo de vídeo de qualquer câmera que esteja sendo gravada. O operador deverá ter a possibilidade de definir a quantidade de tempo que ele quer retroceder (ilimitado). O operador deverá ter a possibilidade de controlar essa visualização instantânea de vídeo gravado com:



Pausa;

Travamento de velocidade;

Avançar visualização a: 1x, 2x, 4x, 6x, 8x, 10x, 20x, 40x, 100x;

Retroceder visualização a: I-frame por I-frame;

Retrocesso de visualização rápido a: -1x, -4x, -10x, -20x, -40x, -100x;

Avanço de visualização lenta a: quadro-a-quadro, 1/8x, 1/4x, 1/3x, 1/2x, 1x.

Loop de visualização de um trecho do vídeo gravado para replay instantâneo.

O trecho do vídeo deve ser delimitado por duas marcações de horário;

xxxix. A função de visualização de replay instantâneo de vídeo deverá possibilitar a visualização do vídeo no mesmo instante em que o alarme for ativado na janela de visualização de alarmes. Deverá ter uma representação gráfica de linha de tempo, de forma que o usuário seja capaz de controlar o período que ele está olhando. O painel de replay instantâneo deverá poder ser retirado da posição original da tela para permitir o redimensionamento da janela de visualização do replay instantâneo;

xl. Deverá possibilitar que o operador seja capaz de extrair uma foto a partir de fontes de vídeo ao vivo e salvá-la ou imprimi-la.

xli. Deverá possibilitar que o operador seja capaz de adicionar um lembrete ou visualizar seu replay instantâneo no visualizador de vídeo gravado, bastando um simples click em um botão do painel de replay instantâneo;

xlii. Deverá possibilitar que o operador seja capaz de escolher e disparar uma ação a partir de uma lista de ações;

xliii. Deverá possibilitar que o operador seja capaz de executar as macros mais freqüentes a partir de um painel ou uma tecla de função na janela de visualização ao vivo;

xliv. Deverá possibilitar que o operador seja capaz de visualizar a mesma câmera múltiplas vezes em diferentes janelas de visualização do layout;

xlv. Deverá possibilitar que os usuários sejam capazes de armazenar streams de vídeo ao vivo localmente na Estação de Monitoramento, sem que seja obrigatória a instalação de aplicação servidor de vídeo na Estação de Monitoramento. A gravação poderá ser ativada ou terminada manualmente pelo usuário. Deverão existir no mínimo dois métodos de gravação diferentes disponíveis ao usuário:

xlvi. Gravação de uma janela de visualização – Gravação do vídeo que está sendo visualizado em uma janela de visualização, podendo as câmeras ser trocadas dentro de cada janela;

xlvii. Gravação de um layout – Gravação de todos os streams de vídeo que estão sendo visualizados em todas as janelas de visualização do layout, podendo as câmeras ser trocadas dentro de cada janela.



xlviii. Deverá possibilitar que os usuários sejam capazes de mostrar um layout de streams

de vídeo em um monitor de PC removendo todos os componentes gráficos que não fazem parte do vídeo, deixando apenas uma linha delimitadora entre as janelas de visualização, com no máximo dois pixels de largura.

xlix. Deverá habilitar os usuários trocarem facilmente o modo de operação de simples para avançado. No modo simples, somente os comandos mais comuns deverão estar disponíveis.

l. Os usuários deverão ter o controle total sobre as aplicações na área de trabalho do PC, podendo:

Mostrar / ocultar painéis de visualização; Mostrar / ocultar menus e barras de ferramentas; Mostrar / ocultar informações sobrepostas no vídeo; Redimensionar diferentes painéis; Escolher layout ou janela de visualização para mostrar rota padrão.

li. O visualizador de vídeo ao vivo deverá capacitar o administrador congelar a área de

trabalho para determinados usuários que não poderão alterá-la.

lii. Deverá possibilitar que o usuário local, que tenha permissões, possa controlar remotamente a área de trabalho de outro visualizador de vídeo ao vivo no sistema.

ww. Visualizador de Vídeo Gravado

i. O sistema deverá possibilitar a visualização sincronizada de imagens arquivadas,

mesmo em servidores de gravação com fusos horários diferentes. Os usuários deverão ter a possibilidade de fazer pesquisas de vídeo por: hora local da câmera; hora local do servidor; hora local da Estação de Monitoramento do usuário; hora GMT; ou outro fuso horário.

ii. O visualizador de vídeo gravado da aplicação cliente deverá permitir a reprodução

de vídeo e áudio gravados. A aplicação cliente de visualização de vídeos gravados deverá ter as seguintes funcionalidades mínimas:

Suportar a visualização de vídeo e áudio de qualquer intervalo de tempo; Suportar a visualização de até 16 seqüências simultâneas de vídeo gravado

de uma só vez;

iii. Deverá permitir que os operadores possam escolher dentre um possível número de padrões de visualização de câmeras, de 1 a 16 quadros simultâneos;

iv. Deverá permitir que os operadores possam selecionar visualizações sincronizadas, selecionando os streams de vídeo desejados, permitindo que os operadores possam visualizar eventos de múltiplos ângulos ou por diversos campos da imagem da câmera, ou visualizações não sincronizadas de vídeos gravados;

v. Deverá permitir que os operadores possam visualizar simultaneamente a mesma câmera em múltiplas janelas em diferentes intervalos de tempo;

vi. Deverá possibilitar que o operador controle a visualização de vídeo gravado com: Pausa; Travamento de velocidade;



Avançar visualização a: 1x, 2x, 4x, 6x, 8x, 10x, 20x, 40x, 100x; Retroceder visualização a: I-frame por I-frame; Retrocesso de visualização rápido a: -1x, -4x, -10x, -20x, -40x, -100x; Avanço de visualização lenta a: quadro-a-quadro, 1/8x, 1/4x, 1/3x, 1/2x, 1x. Loop de visualização de um trecho do vídeo gravado. O trecho do vídeo deve

ser delimitado por duas marcações de horário;

vii. Deverá mostrar uma linha de tempo simples para todos os streams de vídeo ou uma linha de tempo para cada stream de vídeo selecionado, com a qual o operador poderá navegar dentro da seqüência de vídeo simplesmente clicando em qualquer ponto da linha de tempo;

viii. Deverá mostrar o nível de movimento em qualquer ponto da linha de tempo;

ix. Deverá mostrar claramente os lembretes e eventos de metadados sobre a linha de tempo;

x. Deverá permitir pesquisar vídeos gravados de um ou múltiplos servidores de armazenamento de vídeo utilizando vários critérios de pesquisa, incluindo, mas não limitando a: horário, data, câmera, local de monitoramento e alarmes antigos;

xi. Deverá mostrar o drive no qual o arquivo está localizado, a resposta deverá ser mostrada em um painel de resultado quando a pesquisa for feita na aplicação cliente;

xii. Deverá fornecer uma ferramenta de pesquisa de vídeo e seus respectivos áudios, através de eventos definidos pelos usuários ou parâmetros de detecção de movimento;

xiii. Deverá possibilitar que os operadores definam uma área no campo de vídeo (imagem) no qual será feita a pesquisa para detecção de movimento, bem como definir a quantidade de movimento que irá disparar os resultados da pesquisa. O visualizador de vídeo gravado então deverá disponibilizar todos streams de vídeo gravado os quais contêm os movimentos que coincidem com os parâmetros de pesquisa. Deverá existir uma linha de tempo gráfica onde o tempo de cada pesquisa deverá estar indicado;

xiv. Deverá possibilitar que o operador faça consultas através de uma lista de todos os lembretes criados no sistema e selecione algum evento com lembrete para visualização;

xv. Deverá possibilitar que os operadores revejam os vídeos saltando rapidamente entre o próximo e prévio lembrete;

xvi. Deverá possibilitar que o operador seja capaz de adicionar lembretes em vídeos previamente gravados para facilitar futuras consultas e recuperações de vídeo;

xvii. Deverá permitir que o operador seja capaz de editar e excluir lembretes;

xviii. Deverá possibilitar que o usuário proteja seqüências importantes de vídeo, contra exclusões durante a execução de rotinas normais de limpeza de discos, executadas pelo servidor de gravação;



xix. Deverá possibilitar que o operador valide se uma seqüência de vídeo assinado digitalmente foi violada ou não;

xx. Suportar zoom digital na visualização de streams de vídeo gravado;

xxi. Deverá possibilitar que um operador com direitos, possa excluir arquivos de vídeo;

xxii. Deverá possibilitar a exportação de imagens em formato JPEG e BMP com data e hora impressa na imagem;

xxiii. Deverá fornecer ferramentas para exportação de seqüências de vídeo para vários tipos de media como CD-ROM, com seu respectivo reprodutor de vídeo embutido;

xxiv. Deverá fornecer ferramentas para exportação de seqüências de vídeo em formatos padrões tais como AVI e ASF;

xxv. Deverá possibilitar a proteção de arquivos previamente exportados através de criptografia;

xxvi. Deverá possibilitar que os operadores carreguem arquivos de vídeo exportados previamente a partir do seu computador ou da rede;

xxvii. Deverá possibilitar a exportação de seqüências de vídeo menores, a partir de uma seqüência de vídeo previamente exportada;

xxviii. Suportar a reprodução de vídeos gravados para monitores analógicos padrão NTSC tanto para visualização como para gravação em vídeo cassetes;

xxix. Deverá possibilitar que o operador com direitos de acesso, possa navegar facilmente entre esta aplicação e as demais aplicações cliente bastando posicionar o cursor sobre a funcionalidade e um simples click;

xxx. Deverá possibilitar que determinadas consultas possam ser salvas ao fechar o visualizador de vídeo gravado e que reapareçam quando a aplicação for reaberta.

xx. Visualizador Web de Vídeo ao Vivo

i. O visualizador web de vídeo ao vivo da aplicação cliente deverá permitir a visualização de vídeo ao vivo e a comunicação ao vivo através do áudio de cada câmera IP ou encoder individualmente.

ii. O visualizador web de vídeo ao vivo deverá ter no mínimo as seguintes

características:

Deverá disponibilizar a visualização ao vivo de 1 até 16 streams de vídeo simultâneos em um monitor 1024 x 768;

Deverá permitir que os operadores possam escolher dentre um possível número de padrões de visualização de câmeras, de 1 a 16 janelas de visualização;



Deverá mostrar todas as câmeras conectadas no sistema e todas as câmeras dos sistemas integrados via servidor de integração de múltiplos sistemas (Federação);

Deverá mostrar todas as seqüências de câmeras criadas no sistema e todas as seqüências de câmeras dos sistemas integrados via servidor de integração de múltiplos sistemas (Federação);

Deverá permitir que os operadores possam controlar as seqüências de câmeras (parar, visualizar, avançar visualização, retroceder visualização), sem afetar as funcionalidades dos demais operadores para visualizar e controlar a mesma seqüência de câmeras;

Deverá mostrar todos os monitores analógicos conectados no sistema;

Deverá mostrar todas as câmeras, seqüências de câmeras e monitores analógicos em uma árvore lógica de acesso;

Deverá possibilitar que o operador possa ser capaz de clicar em uma câmera da árvore lógica de acesso e a arraste para dentro de uma janela de visualização ou para o ícone de um monitor analógico para visualização ao vivo;

Deverá possibilitar que o operador seja capaz de clicar em uma seqüência de câmera da árvore lógica de acesso e a arraste para dentro de uma janela de visualização ou para o ícone de um monitor analógico para visualização ao vivo;

Deverá possibilitar que streams de vídeo possam ser alocados para janelas de visualização que não estejam visíveis no momento na rota padrão que está sendo visualizada;

Deverá dar suporte às funções de mapa, de forma que mapas digitais possam ser usados para representar a localização física das câmeras e outros dispositivos através do sistema de monitoramento. Os mapas deverão ter a capacidade de conter hyperlinks que possibilitem a criação de uma hierarquia de mapas interligados. A funcionalidade de mapas deverá ter capacidade de importar mapas de um software gráfico que suporte os formatos de imagem BMP, JPEG e/ou formato de imagens GIF;

O operador deverá ter a possibilidade de clicar e arrastar uma câmera de um mapa para uma janela de visualização ao vivo;

O operador deverá ter a possibilidade de clicar em um ícone de câmera no mapa para iniciar um posicionamento pré-programado da câmera (preset), executar uma rota padrão ou enviar um stream de entrada/saída;

Deverá dar suporte às funções de procedimentos pré-definidos, que possam ser disparados para execução durante um determinado evento e possam ser usados para fornecer detalhes de instruções para o operador quanto a ações a serem tomadas;

Deverá suportar zoom digital em streams de vídeo ao vivo;



Deverá suportar rondas de visualização (seqüenciamento automático de layouts de câmeras) com tempos de permanência de imagens pré-definidos através de monitores de visualização (por exemplo: rotação de layouts de 4 imagens para 16 imagens para 1 imagem de tela cheia em intervalos de tempo especificados);

Deverá possibilitar que os usuários possam escolher qualquer um dos streams de vídeo da câmera para visualização ao vivo;

Cada visualizador web de vídeo ao vivo deverá ter um ícone indicando o número de alarmes enfileirados e que estão alocados para o usuário que está na aplicação cliente. Os alarmes também poderão ser mostrados em um painel de alarmes na parte inferior da tela do software. O painel de alarmes deverá mostrar os alarmes ativos, bem como os alarmes reconhecidos pelos operadores, auto-reconhecidos pelo sistema, transferidos e retardados;

Deverá habilitar o usuário e realizar uma das seguintes ações na ocorrência de um alarme:

o Reconhecer (método padrão); o Reconhecer (método alternativo); o Reconhecer (método customizado); o Retardar (por uma quantidade de segundos pré-definida); o Transferir para outro usuário no sistema; o Mostrar os procedimentos pré-definidos associados ao alarme; o Mostrar o histórico de um alarme; o Iniciar o visualizador de vídeo gravado para rever alarmes antigos;

iii. Deverá habilitar o usuário para disparar um alarme espontaneamente baseado em

alguma coisa que ele vê na imagem câmera. A imagem da câmera de interesse deverá ser enviada como parte do alarme ao usuário selecionado;

iv. Deverá possibilitar que o operador possa navegar facilmente entre as aplicações cliente web bastando posicionar o cursor sobre a funcionalidade e um simples click, dependendo apenas dos direitos de acesso;

v. Deverá possibilitar que os operadores sejam capazes de controlar PTZ, íris, foco, relê das domes, rotas padrões, posicionamentos pré-definidos e menus de configurações das domes;

vi. Deverá possibilitar que os operadores sejam capazes de definir um número ilimitado

de rotas padrões e posicionamentos pré-definidas;

vii. Deverá permitir que o operador tenha atribuição de prioridades de um PTZ entre 1 e 255. Isto possibilitará a priorização entre operadores que determinará qual operador terá preferência no comando de câmera;

viii. O sistema deverá permitir que os usuários possam ter a possibilidade de bloquear e restringir o controle de PTZ de qualquer câmera. Usuários com maior prioridade de controle de PTZ poderão desbloquear PTZ’s de outros usuários com menor prioridade;

ix. Deverá permitir que os operadores possam registrar lembretes em eventos importantes para facilitar sua localização futura em qualquer vídeo gravado das



câmeras. Os operadores deverão poder dar nomes a esses lembretes para facilitar futuras pesquisas;

x. Deverá possibilitar que o operador seja capaz de iniciar e parar manualmente a gravação de qualquer câmera no sistema bastando um click em um simples botão;

xi. Deverá possibilitar que o operador seja capaz de ativar e desativar a visualização de todos os eventos do sistema assim que eles ocorram;

xii. Deverá possibilitar que o operador visualize um replay instantâneo de vídeo de qualquer câmera que esteja sendo gravada. O operador deverá ter a possibilidade de definir a quantidade de tempo que ele quer retroceder (ilimitado). O operador deverá ter a possibilidade de controlar essa visualização instantânea de vídeo gravado com:

Pausa; Travamento de velocidade; Avançar visualização a: 1x, 2x, 4x, 6x, 8x, 10x, 20x, 40x, 100x; Retroceder visualização a: I-frame por I-frame; Retrocesso de visualização rápido a: -1x, -4x, -10x, -20x, -40x, -100x; Avanço de visualização lenta a: quadro-a-quadro, 1/8x, 1/4x, 1/3x, 1/2x, 1x. Loop de visualização de um trecho do vídeo gravado para replay instantâneo.

O trecho do vídeo deve ser delimitado por duas marcações de horário;

xiii. A função de visualização de replay instantâneo de vídeo deverá possibilitar a visualização do vídeo no mesmo instante em que o alarme for ativado na janela de visualização de alarmes. Deverá ter uma representação gráfica de linha de tempo, de forma que o usuário seja capaz de controlar o período que ele está olhando. O painel de replay instantâneo deverá poder ser retirado da posição original da tela para permitir o redimensionamento da janela de visualização do replay instantâneo;

xiv. Deverá possibilitar que o operador seja capaz de extrair uma foto a partir de fontes de vídeo ao vivo e salvá-la ou imprimi-la.

xv. Deverá possibilitar que o operador seja capaz de adicionar um lembrete ou visualizar seu replay instantâneo no visualizador de vídeo gravado, bastando um simples click em um botão do painel de replay instantâneo;

xvi. Deverá possibilitar que o operador seja capaz de visualizar a mesma câmera múltiplas vezes em diferentes janelas de visualização do layout;

yy. Visualizador Web de Vídeo Gravado

i. O visualizador web de vídeo gravado da aplicação cliente deverá permitir a reprodução de vídeo e áudio gravados. A aplicação cliente de visualização web de vídeos gravados deverá ter as seguintes funcionalidades mínimas:

ii. Suportar a visualização de vídeo e áudio de qualquer intervalo de tempo;

iii. Suportar a visualização de até 16 seqüências de vídeo gravado de uma só vez;

iv. Deverá permitir que os operadores possam escolher dentre um possível número de padrões de visualização de câmeras, de 1 a 16 quadros;



v. Deverá permitir que os operadores possam selecionar visualizações sincronizadas, selecionando os streams de vídeo desejados, permitindo que os operadores possam visualizar eventos de múltiplos ângulos ou por diversos campos da imagem da câmera, ou visualizações não sincronizadas de vídeos gravados.

vi. Deverá permitir que os operadores possam visualizar simultaneamente a mesma câmera em múltiplas janelas de visualização em diferentes intervalos de tempo;

vii. Deverá possibilitar que o operador controle a visualização de vídeo gravado com: Pausa; Travamento de velocidade; Avançar visualização a: 1x, 2x, 4x, 6x, 8x, 10x, 20x, 40x, 100x; Retroceder visualização a: I-frame por I-frame; Retrocesso de visualização rápido a: -1x, -4x, -10x, -20x, -40x, -100x; Avanço de visualização lenta a: quadro-a-quadro, 1/8x, 1/4x, 1/3x, 1/2x, 1x. Loop de visualização de um trecho do vídeo gravado. O trecho do vídeo deve

ser delimitado por duas marcações de horário;

viii. Deverá mostrar uma linha de tempo simples com a qual o operador poderá navegar dentro da seqüência de vídeo simplesmente clicando em qualquer ponto da linha de tempo;

ix. Deverá mostrar o nível de movimento em qualquer ponto da linha de tempo;

x. Deverá mostrar claramente os lembretes e eventos de metadados sobre a linha de tempo;

xi. Deverá permitir pesquisar vídeos gravados de um ou múltiplos servidores de armazenamento de vídeo utilizando vários critérios de pesquisa, incluindo, mas não limitando a: horário, data, câmera, local de monitoramento e alarmes antigos;

xii. Deverá mostrar o drive no qual o arquivo está localizado, a resposta deverá ser mostrada em um painel de resultado quando a pesquisa for feita na aplicação cliente;

xiii. Deverá fornecer uma ferramenta de pesquisa de vídeo e seus respectivos áudios, através de eventos definidos pelos usuários ou parâmetros de detecção de movimento;

xiv. Deverá possibilitar que os operadores definam uma área no campo de vídeo

(imagem) no qual será feita a pesquisa para detecção de movimento, bem como definir a quantidade de movimento que irá disparar os resultados da pesquisa. O visualizador web de vídeo gravado então deverá disponibilizar todos streams de vídeo gravado os quais contêm os movimentos que coincidem com os parâmetros de pesquisa. Deverá existir uma linha de tempo gráfica onde o tempo de cada pesquisa deverá estar indicado;

xv. Deverá possibilitar que o operador faça consultas através de uma lista de todos os lembretes criados no sistema e selecione algum evento com lembrete para visualização;

xvi. Deverá possibilitar que os operadores revejam os vídeos saltando rapidamente entre o próximo e prévio lembrete;



xvii. Deverá possibilitar que o operador seja capaz de adicionar lembretes em vídeos

previamente gravados para facilitar futuras consultas e recuperações de vídeo. xviii. Deverá permitir que o operador seja capaz de editar e excluir lembretes.

xix. Deverá possibilitar que o usuário proteja seqüências importantes de vídeo, contra

exclusões durante a execução de rotinas normais de limpeza de discos, executadas pelo servidor de gravação;

xx. Deverá possibilitar que o operador valide se uma seqüência de vídeo assinado digitalmente foi violada ou não;

xxi. Suportar zoom digital na visualização de streams de vídeo gravado;

xxii. Deverá possibilitar a exportação de imagens em formato JPEG e BMP com data e hora impressa na imagem;

xxiii. Deverá fornecer ferramentas para exportação de seqüências de vídeo para vários

tipos de media como CD-ROM, com seu respectivo reprodutor de vídeo embutido;

xxiv. Deverá fornecer ferramentas para exportação de seqüências de vídeo em formatos padrões tais como AVI e ASF;

xxv. Deverá possibilitar a proteção de arquivos previamente exportados através de criptografia;

xxvi. Deverá possibilitar que os operadores carreguem arquivos de vídeo exportados previamente a partir do seu computador ou da rede;

xxvii. Deverá possibilitar a exportação de seqüências de vídeo menores, a partir de uma seqüência de vídeo previamente exportada;

xxviii. Suportar a reprodução de vídeos gravados para monitores analógicos padrão NTSC tanto para visualização como para gravação em vídeo cassetes;

xxix. Deverá possibilitar que o operador com direitos de acesso, possa navegar facilmente entre esta aplicação e as demais aplicações cliente bastando posicionar o cursor sobre a funcionalidade e um simples click;

zz. Editor de Macros

i. O editor de macros deverá ser um ambiente integrado de desenvolvimento para a criação de macros para o sistema.

ii. O editor de macros deverá possuir no mínimo as seguintes capacidades:

iii. Deverá fornecer um editor de código com avisos de sintaxe;

iv. Deverá fornecer um ambiente de execução independente, sem a necessidade de

instalação de qualquer aplicação servidor de vídeo;



v. Deverá gerar relatórios de sintaxe e erros de execução, além de indicar a posição do erro no código fonte.

vi. Deverá estar apto para importar e exportar códigos de macros para arquivos. aaa. Visualizador de Relatórios

i. O aplicativo gerador de relatórios de eventos deverá fornecer relatórios das atividades de sistema;

ii. Os eventos de sistema deverão ser armazenados em uma base de dados Microsoft SQL Server;

iii. O gerador de relatórios de eventos deverá estar equipado com modelos padrões para: Relatórios de atividades dos usuários; Relatórios de funcionamento do sistema; Relatórios de eventos / ações.

iv. O aplicativo deverá disponibilizar esquemas de bancos de dados para a geração de

relatórios personalizados.

bbb. Aplicações Compactas de Vídeo Digital em Rede

i. Características Gerais

As características gerais das aplicações compactas de vídeo digital em rede deverão ser as mesmas dos sistemas principais, exceto quantos as restrições normais do hardware e respecitivo sistema embarcado.

Arquitetura do Sistema: Deverá ser baseada em redes utilizando Sistema

Operacional Windows-7 embarcado em hardware compacto. Conexão de estações de trabalho deverá ser através de redes LAN / WAN.

Vídeo sobre IP: Os sistemas compactos deverão utilizar as mesmas tecnologias de compressão de vídeo utilizadas pelos sistemas principais.

Armazenamento: As tecnologias de armazenamento de vídeo e áudio internas e externas deverão ser as mesmas utilizadas pelos sistemas principais.

Independência de Hardware: Os sistemas compactos deverão manter as mesmas compatibilidades de hardwares de CFTV (câmeras IP e conversores de vídeo) que os sistemas principais. A restrição deverá ser apenas quanto ao tipo de servidor de gerenciamento e gravação a ser utilizado, pois o sistema compacto deverá ser embarcado em um PC compacto.

Protocolos e Compatibilidades: Os sistemas compactos deverão suportar os mesmos protocolos utilizados pelos sistemas principais e deverão manter as mesmas compatibilidades com os demais equipamentos através de tais protocolos.



Conectividade: Os sistemas compactos deverão suportar as mesmas formas de conectividade de redes IP, incluindo: LAN, WAN, VPN, Internet e tecnologias sem fio (WiFi e celular). Os demais compenente de conectividade, tais como protocolos de comunicação de rede UDP/TCP/IP sobre LANs e WANs, e tipos de tráfegos de rede IP Multicast (UDP) e Unicast (TCP ou UDP), também deverão ser utilizados.

Certificação Digital: Os mesmos tipos de assinatura digital, criptografia de canais de controle de serviços, controles de chaves de criptografia e suporte a protocolo HTTPS (Hypertext Transfer Protocol Secure), também deverão se utilizados.

As aplicações compactas de vídeo digital em rede deverão ser compostas pelos seguintes módulos de servidores: Servidores de Diretório Principal; Módulos de Gerenciamento de Canais de Comunicação entre os componentes do sistema; Servidores de Gravação Local; Matriz Virtual; Módulo Interno de Supervisão de Operação (Watchdog) e Servidor de Administração

As aplicações compactas de vídeo digital em rede deverão ser compostas pelos seguintes módulos de clientes: aplicação de ferramenta de configuração, aplicação de visualização ao vivo, aplicação de Visualização de vídeo gravado, aplicação web de visualização ao vivo, aplicação web de visualização de vídeo gravado, e aplicação de geração de relatório de eventos.

Tanto os módulo de servidores, como os módulos de clientes que compõem as aplicações compactas de vídeo digital, deverão possuir as mesmas funcionalidas das aplicações correspondentes que compõem os sistemas principais.

A aplicação cliente deverá ser capaz de executar simultaneamente todas as sua aplicações, sem interferência com nenhuma das operações das aplicações dos servidores de vídeo embarcados.

ccc. Conjunto de Ferramentas para Desenvolvimento de Software (SDK)

i. O SDK deverá fornecer a capacidade de embarcar as aplicações de monitoramento e visualização de vídeo gravado em aplicações de terceiros.

ii. O SDK deverá ter no mínimo as seguintes características:

Suportar Windows XP/Vista/2003/2008; Suportar processamento de soluções baseadas em web em ambiente Internet

Explorer 6.0 ou acima; Suportar visualização ao vivo de mais que uma câmera na mesma aplicação; Suportar a visualização de vídeo gravado por um determinado intervalo de

tempo; Suportar a exportação de uma seqüência de vídeo por um determinado

intervalo de tempo; Suportar Linguagens de Desenvolvimento de alto nível como JScript,

VBScript, Visual Basic, Java, C, C++ e C1;



Suportar diferentes topologias de redes IP como: LAN, WAN, VPN, Internet, Wireless e Celular;

Suportar a transmissão de streams Multicast sobre LAN e WAN; Suportar funcionalidades que possibilita o envio de streams de vídeo e áudio

através de NATs e Firewalls.

IV. DESCRIÇÃO DO SOFTWARE DE CONTROLE DE ACESSO a. Geral

i. O Sistema de Controle de Acesso (SCA) deverá ser uma solução de software de controle de acesso IP de classe empresarial. Deverá ser totalmente incorporado dentro de uma Plataforma de Segurança Unificada (PSU). A PSU deverá permitir a unificação perfeita dos sistemas SCA com um sistema de gerenciamento de vídeo IP (VMS).

ii. O SCA deverá ser altamente escalável para suportar configurações com milhares de portas com instalações abrangendo várias áreas geográficas.

iii. O SCA deverá apoiar um número ilimitado de registros e transações históricas (eventos e alarmes) com o limite máximo definido apenas pela quantidade de espaço disponível no disco rígido.

iv. O SCA deverá suportar uma variedade de funcionalidades de controlo de acesso, incluindo, mas não limitados a:

v. Gerenciamento da Unidade Controladora, gerenciamento de porta, gerenciamento de elevador, e gerenciamento da área;

vi. Gerenciamento usuários e grupo usuários, gerenciamento de crachás e gerenciamento de regra de acesso;

vii. Impressão de crachá e criação de layouts padrões;

viii. Gerenciamento de visitantes;

ix. Contagem de pessoas, rastreamento de presença em uma área e revista de pessoas;

x. Oferecer uma estrutura para integração de hardware de terceiros, como scaneamento de cartão e assinatura.

b. Gerenciamento de Acesso

i. O SCA deverá basear-se em uma arquitetura aberta capaz de suportar vários fabricantes de hardware de controle de acesso. O SCA deve ser capaz de integrar-se com vários módulos não-proprietários de interface e controladores, leitores de acesso, e outras aplicações de terceiros.

ii. O SCA deverá ser uma solução IP nativa. Toda a comunicação entre o SCA e os controladores de hardware deve ser baseado no padrão de protocolo TCP/IP.



iii. Função de Gerenciamento de Acesso:

iv. A função de Gerenciamento de Acesso será o servidor que sincroniza todas as unidades de hardware de controle de acesso sob seu controle, como controladores de portas e módulos de IO. Deverá também ser capaz de validar e registrar todas as atividades de acesso e eventos quando os controladores de portas e módulos de IO estiverem online.

v. A Função de Gerenciamento de Acesso deverá manter o link de comunicação com os controladores de hardware sob o seu controle. Deverá também monitorar continuamente se os controladores estão online ou offline.

vi. A sincronização das unidades de hardware deverá ser automatizada e transparente aos usuários e deverá ocorrer em segundo plano. Deverá também ser possível sincronizar as unidades manualmente ou baseado em agendamentos.

vii. A Função de Gerenciamento de Acesso deverá ser capaz de gerenciar portas e controladores localizados em uma ou mais instalações. O servidor de acesso deverá ser capaz de gerenciar um mínimo de 200 leitores por computador.

viii. O servidor de acesso deverá armazenar todos os eventos de acesso associados com as portas, áreas, zonas de hardware (pontos de entrada de hardware), elevadores, e os controladores sob seu controle direto.

c. Gerenciamento Global de Usuários de Cartões

i. O SCA deverá suportar o gerenciamento global de usuários e a sincronização entre um site independente central e os sites independentes remotos, os quais podem ter seu próprio diretório e bancos de dados.

ii. Deverá ser possível sincronizar as seguintes entidades e seus dados de configuração: Os usuários de cartão (incluindo campos personalizados) Grupos do usuários de cartões Credenciais Modelos de crachás.

iii. Os usuários de cartões e outras entidades sincronizadas deverão poder ser

adicionadas centralizadamente e sincronizados em locais remotos para o gerenciamento global de usuários.

iv. Os usuários de cartões e outras entidades sincronizados deverão poder ser adicionados em sites remotos e sincronizado com o site central e outros sites remotos.

v. O SCA deverá ser capaz suportar um único cartão por usuário em todos os sites de uma organização.

vi. O SCA deverá suportar sincronização manual e por agendamento. d. Lista de Compatibilidade de Hardware



i. O SCA deverá ter uma arquitetura aberta que suporta a integração de controladores de portas e módulos de IO de terceiros baseados em IP. O SCA deverá suportar simultaneamente configurações mistas de hardware de controle de acesso de múltiplos fornecedores.

ii. O SCA deverá suportar vários tipos de dispositivos de hardware: controladores com 1-leitor, controladores com 2-leitores, controladores com 1 a 64 de leitores, leitores integrados e controladores de porta, controladores de portas com Power-over-Ethernet (PoE) nativo.

iii. O SCA deverá suportar a maioria dos leitores de cartão padrão da indústria que fornecem dados de saída do cartão usando o protocolo Wiegand e Clock-and-Data.

iv. O SCA deverá suportar os seguintes controladores IP nativos:

Master Controller, que deverá suportar os seguintes módulos de interface de dados:

o VertX V100 módulo de interface de leitor o VertX V200 módulo de entrada o VertX V300 módulo de saída o Mercury MR52 módulo de interface de leitor o Mercury MR16OUT módulo de saída o Mercury MR16IN módulo de entrada o STid LXS W33-E/PH5 7AA o DDS AS34/TPL4

HID Corporation

o VertX V2000 interface de leitor/gateway de rede o VertX V2000 Evo interface de leitor/gateway de rede o iCLASS EdgeReader leitor integrado e controlador (PoE) o iCLASS EdgeReader EVO leitor integrado e controlador (PoE) o EdgePlus controlador de porta (PoE) o Edge EVO controlador de porta (PoE) o EVO Hi-O módulo de interface o VertX V1000 gateway de rede o VertX V1000 EVO gateway de rede o VertX V100 módulo de interface de leitor o VertX V200 módulo de entrada o VertX V300 módulo de saída

Os seguintes leitores USB de cadastro deverão ser suportados:

o RF Ideas pcProx HID USB leitor USB para cadastro de cartões de proximidade

o RF Ideas AIR ID Enroll iCLASS ID# leitor USB para cadastro de cartões iCLASS da HID

o RF Ideas AIR ID Enroll 14443/15693 CSN leitor USB para cadastro de cartão MIFARE usando o CSN (número de série do cartão)

o RF Ideas AIR ID Enroll pcProx Plus w/iCLASS leitor de proximidade para cadastrar cartões iCLASS

o STid STR-W35-E/PH5-5AA e. Funcionalidades do Software SCA



i. O SCA deverá ter uma perfeita unificação com o sistema de gerenciamento de vídeo

IP (SGV)

ii. Através da PSU (Plataforma de Segurança Unificada), o SCA deverá suportar a integração com um sistema de vídeo vigilância IP ou SGV. A integração com um sistema de vídeo vigilância IP deverá permitir ao usuário visualizar o vídeo ao vivo e gravado ao mesmo tempo que visualiza os eventos do controle de acesso.

iii. O usuário deverá ser capaz de associar uma ou mais câmeras de vídeo aos seguintes tipos de entidades, entre outros: portas, elevadores, e zona de hardware (pontos de entrada).

iv. A interface do usuário deverá apresentar uma verdadeira interface de segurança unificada para controle de acesso e vídeo vigilância. Uma visualização avançada de vídeo ao vivo e reprodução de vídeo gravado deverão ser acessíveis através da interface de vigilância.

v. Deverá ser possível ver vídeo associado a eventos de controle de acesso ao visualizar um relatório.

vi. O SCA deverá suportar o gerenciamento de controladores (unidade)

vii. O SCA deverá suportar o reconhecimento, configuração e gerenciamento de

controladores IP nativos e módulos de IO (unidades de hardware). O usuário deverá ter permissão para adicionar, excluir ou modificar um controlador se ele tiver os privilégios apropriados.

viii. O SCA deverá suportar automáticamente o reconhecimento da unidade. O usuário deverá poder definir as configurações para as portas que forem reconhecidas e tipos de unidades reconhecidas e o SCA deverá detectar automaticamente todos os dispositivos conectados.

ix. O SCA deverá possuir um utilitário de substituição unidade que possibilite trocar uma controladora existente por uma nova controladora. O utilitário de substituição de unidade deve evitar a reprogramação do sistema sempre que uma unidade for substituída. Todos os logs e eventos da unidade antiga deverão ser mantidas.

x. O SCA deverá suportar a pré-configuração do sistema antes da instalação do hardware físico.

xi. O SCA deverá suportar o gerenciamento de Usuário de Cartão e Grupo de Usuário de Cartões

xii. O SCA deverá suportar a configuração e gerenciamento de usuários e grupos de usuários de cartões. Um usuário deverá ser capaz de adicionar, excluir ou modificar um usuário ou grupo de usuários de cartões, se ele tiver os privilégios apropriados.

xiii. O SCA deverá suportar campos personalizados para usuários e grupos de usuários de cartões.



xiv. O SCA deverá permitir as seguintes opções de ativação/expiração para o perfil de um usuário: ativação retardada do perfil do usuário, expiração baseada na data do primeiro uso da cartão, ou expiração em uma data definida pelo usuário.

xv. Deverá ser possível associar uma foto ao perfil do usuário do cartão. A foto deverá ser importada de um arquivo, capturadas com uma câmera digital, ou capturada de uma câmera de vídeo vigilância. Quando um evento de usuário ocorrer, a foto do usuário do cartão deverá ser exibida na interface de monitoramento do operador do sistema. O SCA deverá suportar vários formatos padrões de fotos.

xvi. O SCA deverá possibilitar o agrupamento de usuários para facilitar mudanças em massa das configurações do sistema. Deverá ser possível atribuir regras de acesso a grupos de usuários de cartões, evitando, assim, a atribuição da mesma regra de acesso a cada usuário individualmente.

xvii. Deverá ser possível pesquisar por associação de imagem, campos personalizados e nomes.

xviii. Deverá ser possível selecionar múltiplos usuários de cartões para imediata desativação ou reativação.

xix. O SCA deverá possibilitar a sincronização de usuários e grupo usuários de cartões através do Active Directory incluindo credenciais e imagem dos usuários.

xx. O SCA deverá suportar o gerenciamento de credenciais xxi. O SCA deverá suportar a configuração e gerenciamento de credenciais, por

exemplo, cartões de acesso e senhas via teclado. Um usuário deve ser capaz de adicionar, excluir ou modificar uma credencial desde que ele tenha os privilégios apropriados.

xxii. O usuário deverá ter a possibilidade de adicionar campos personalizados (campos definidos pelo usuário) nas credenciais do usuário. Deverá ser possivel criar uma nova credencial manualmente ou automaticamente.

xxiii. A criação automática deverá possibilitar ao usuário criar uma entidade credencial apresentando uma credencial a um leitor selecionado. O SCA deverá ler os dados do cartão e associá-los à entidade credencial. Deverá ser possível cadastrar automaticamente qualquer formato de cartão (128 bits ou menos).

xxiv. O SCA deverá suportar múltiplas credenciais por usuário de cartão, sem a necessidade de duplicar a informação do usuário do cartão. O SCA deverá detectar automaticamente e impedir tentativas de registrar uma credencial já registrada.

xxv. O SCA deverá suportar o cadastramento de credenciais em lotes.

xxvi. O SCA deverá fornecer um fluxo de trabalho para a emissão de crachá e solicitações de cartões.

xxvii. O SCA deverá suportar o Formatos Personalizados de Cartões

xxviii. O SCA deverá possuir uma funcionalidade que permita ao administrador adicionar formatos personalizados adicionais utilizando uma ferramenta intuitiva dentro da



interface do usuário para configuração. A ferramenta de formato de cartão personalizado, deve ser flexível nas seguintes maneiras:

xxix. Uma vez cadastrados, os novos formatos de cartões personalizados, os mesmos deverão aparecer nas listas de formato de cartão para cadastro manual de cartões.

xxx. O SCA deverá possibilitar a adição de um número ilimitado de formatos de cartões personalizados adicionais.

xxxi. O administrador deverá ter a possibilidade de configurar as seguintes opções ao definir um novo formato:

xxxii. A ordem em que os campos do cartão aparecem na interface do usuário ou SCA.

xxxiii. Se um campo é escondido, ou visível para o operador.

xxxiv. Se um campo é modificável ou só lido por um operador.

xxxv. Esquemas de verificação complexas de paridade.

xxxvi. A ordem e a localização dos dados de um campo. A localização deverá poder ser definido bit-por-bit.

xxxvii. O SCA deverá possuir uma ferramenta para desenhar crachás

xxxviii. A ferramenta para desenhar crachás deverá permitir a criação de modelos de crachás que definam o conteúdo e formato de apresentação do crachá de um usuário de cartão para ser impresso.

xxxix. A produção de crachás deverá consistir em selecionar a credencial, o modelo de crachá, e clicar em Imprimir.

xl. O SCA deverá possibilitar a impressão em lote de cartões.

xli. O conteúdo de um modelo de crachá deverá poder incluir: nome do usuário do cartão, sobrenome, foto, campos personalizados, gráficos em bitmap, linhas, ovais, retângulos, rótulos de texto dinâmicos vinculados a campos personalizados e rótulos de texto estático, códigos de barras (2 de 5 intercalado, , Extended Code 39).

xlii. O SCA deverá disponibilizar opções de copiar e colar objetos de modelo de crachá.

xliii. Deverá ser possível definir a espessura da borda, cor da borda, cor de preenchimento de objetos do crachá (conteúdo), e as cores dos rótulos de texto.

xliv. O SCA deverá disponibilizar configurações como a transparência do objeto, orientação do texto, e auto-dimensionamento de texto ou que esta função seja transparentes para o usuário.

xlv. O SCA deverá suportar os seguintes formatos de crachás (retrato e paisagem): CR70 (2,875 "x 2,125"), CR80 (3.37 "x 2.125"), CR90 (3.63 "x 2.37"), CR100 (3.88 "x 2.63") e tamanhos de cartões personalizados.



xlvi. O SCA deverá suportar crachás de duas faces.

xlvii. O SCA deverá possuir função de importação e exportação de modelos crachás e para permitir o compartilhamento de modelos de crachá entre SCA’s distintos ou independentes.

xlviii. O SCA deverá suportar chromakey.

xlix. O SCA deverá suportar o gerenciamento de portas

l. O SCA deverá suportar a configuração e gerenciamento de portas. O usuário deverá ser capaz de adicionar, excluir ou modificar uma porta, se ele tiver os privilégios apropriados.

li. O SCA deverá permitir múltiplas regras de acesso a serem associadas a uma porta.

lii. O SCA deverá suportar as seguintes formas de autenticação: apenas cartão, cartão ou teclado (PIN), ou cartão e teclado (PIN). Deverá ser possível definir um agendamento para quando os modos de autenticação de somente cartão ou cartão e teclado deverão ser necessários.

liii. O SCA deverá suportar tempo prolongado de abertura de porta. Deverá ser possível definir um tempo prolongado de abertura individualmente para cada porta, além do tempo padrão de abertura da porta. Deverá ser possível incluir a opção de usar o tempo de abertura prolongado nas propriedades do usuário do cartão. Quando portadores de cartões marcados com estea opção solicitar acesso, a porta deverá ser desbloqueada durante o tempo de abertura prolongado em vez do tempo de abertura padrão.

liv. O SCA deverá suportar portas que não usam leitores de cartões.

lv. O SCA deverá suportar portas configuradas somente com um fechadura, um botão de abertura do tipo REX, e um contacto de porta, mas sem leitores.

lvi. O SCA deverá possibilitar a implantação de uma porta sem utilização de leitores de cartões, utilizando hardwares padrões de acesso módulos IO. Não deverá ser obrigatório de hardware externo, como timers.

lvii. O SCA deverá possibilitar agendamentos de desbloqueios para portas que não utilizam leitores de cartões.

lviii. O SCA deverá possibilitar a criação de relatórios de atividades padrões de portas que não utilizam leitores de cartões.

lix. O SCA deverá possibilitar associação de agendamentos de desbloqueio e exceções de desbloqueio para uma porta. Um agendamento de desbloqueio deve determinar quando uma porta deverá ser automaticamente desbloqueada. O SCA também deverá suportar o uso de um agendamento específico de desbloqueio quando a porta não estiver conectada ao sistema. O SCA deverá possibilitar o uso de agendamentos de exceções de desbloqueio para definir períodos de tempo durante os quais os horários padrões de desbloqueio não devem ser usados, por exemplo, durante as férias regulares.



lx. O SCA deverá suportar uma ou mais câmeras por porta. Os vídeos deverão ser então

associados a eventos de acesso das portas, por exemplo, “acesso concedido” ou “acesso negado”.

lxi. O SCA deverá suportar o gerenciamento de elevadores

lxii. O SCA deverá suportar a configuração e gerenciamento de elevadores. Um usuário deve ser capaz de adicionar, excluir ou modificar um elevador, se ele tem os privilégios apropriados.

lxiii. O SCA deverá ser capaz de controlar o acesso a andares específicos, utilizando um

leitor de cartões dentro da cabina de elevador. O SCA deverá disponibilizar o controle através do uso de uma controladora com uma interface para leitor de cartões e com vários módulos de saída com relés.

lxiv. A seleção dos andares no elevador, deverão ser rastreadas ustilizando uma controladora com interface para vários módulos de entrada. O rastreamento de andares deverá estar disponível através de um relatório de actividades de elevador.

lxv. Caso a comunicação entre o elevador e o SCA falhe, o módulo de controle do elevador deverá continuar funcionando em modo desconectado. O SCA deverá suportar uma ou mais câmeras por cabine de elevador. Os vídeos deverão ser associados a eventos de acesso ao elevador, por exemplo, “acesso concedido” ou “acesso negado”.

lxvi. O SCA deverá suportar o gerenciamento de visitantes

lxvii. O SCA deverá suportar a configuração e gerenciamento de visitantes. Um usuário deverá ser capaz de cadastrar ou remover um visitante se ele tiver os privilégios apropriados. O SCA deverá suportar o “registro de entrada” e o “registro de saída” de visitantes através da interface de usuários de monitoramento.

lxviii. O SCA deverá possuir um assistente de “registro de entrada” para facilitar o processo de cadastramento, o que permitirá que o usuário registrar informações específicas do visitante.

lxix. O SCA deverá permitir as seguintes opções de credenciais durante o “registro de entrada” do visitante:

lxx. Usar uma credencial existente

lxxi. Criar automaticamente uma nova credencial

lxxii. Criar manualmente uma nova credencial

lxxiii. O SCA deverá suportar a criação antecipada de um conjunto de credenciais de visitante. O SCA deverá possibilitar a atribuição de credenciais de visitantes existentes a um novo visitante durante o processo de “registro de entrada”.



lxxiv. O SCA deverá permitir que grupos de usuários de cartão possam ser designado como "visitantes autorizados". Os usuários deverão ser capazes de definir com antecedência, os privilégios de acesso para os grupos de usuários de cartões (grupos de usuários de cartões de visitantes). Durante o “registro de entrada”, o usuário deverá selecionar o grupo usuários de visitantes se associar com um visitante. Todos os privilégios de acesso do grupo de usuários de cartões de visitantes deverão ser automaticamente transferidos para o visitante. Este recurso deverá permitir a criação de vários tipos de grupos de visitantes e privilégios associados (para prestadores de serviços, pessoas importantes, visitantes diários, etc.). Os visitantes adicionados ao grupo de usuários visitantes na interface de monitoramento, deverão ser atualizados automaticamente na tela de interface de configuração de grupos de usuários.

lxxv. O SCA deverá suportar a modificação em tempo real das informações de um visitante após este ter finalizado seu “registro de entrada”.

lxxvi. O SCA também deverá fornecer um abrangente rastreamento de visitantes e relatórios de visitantes. O SCA deverá possibilitar a geração de relatórios de atividades de visitantes em tempo real e listagem históricos de visitantes, através do recurso de rastreamento em tempo real, na interface de usuário de monitoramento. O SCA também deverá gerar relatórios específicos de visitantes que fornecem listas detalhadas de visitantes, bem como detalhes completos sobre a sua movimentação.

lxxvii. O SCA deverá possibilitar isentar um visitante de qualquer regra de antipassback vigente.

lxxviii. O SCA deverá possibilitar que o operador tenha possibilidade de improimir crachás de visitantes durante o processo de “registro de entrada”. O SCA deverá suportar a impressão de crachás em papel (visitante sem uma credencial associada) e credenciais vigentes.

lxxix. O SCA também deverá suportar o gerenciamento de visitantes e emissão de relatórios através do usuários Web.

lxxx. O SCA deverá possibilitar a localização de informações ou perfil de um visitante lendo o cartão do visitante em um leitor de cartões USB.

lxxxi. O SCA deverá suportar a contagem de pessoas e o rastreamento de presença em uma área

lxxxii. O SCA deverá suportar a contagem de pessoas (ou rastreamento de presença em uma área). O SCA deverá ser capaz de monitorar e informar o número de usuários de cartões em uma área em tempo real e como também para todas as áreas. O monitoramento deverá ser baseada em toda uma infra-estrutura de controle de acesso, nas áreas locais e em áreas geograficamente distantes. A contagem de pessoas também poderá ser usada para reunir pessoas.

lxxxiii. O SCA deverá apresentar a contagem de presença de uma área na interface do usuário de monitoramento. O rastreamento de presença em uma área, deverá rastrear dinamicamente o número total de usuários de cartões em uma determinada área. Os dados apresentados deverão ser atualizadas dinamicamente.



lxxxiv. O SCA deverá ser capaz de gerar um relatório de presença em áreas, listando os usuários localizados em uma ou mais áreas, acessíveis através da interface do usuário de monitoramento. Deverá ser possível filtrar o relatório por área e período de tempo. O relatório também deverá incluir as atividades das sub-áreas (áreas agrupadas).

lxxxv. Através da contagem de pessoas, o SCA deverá ser capaz de gerar eventos de “primeira pessoa que entrou” e “última pessoa que saiu”. O evento de “primeira pessoa que entrou” deverá detectar quando o primeiro usuário de cartão entra em uma área vazia. O evento de “última pessoa que saiu” deverá detectar quando o último usuário de cartão deixa uma área. O SCA deverá possibilitar disparar ações de ambos os eventos, tais como o envio de uma mensagem ou acionar um alarme.

lxxxvi. O SCA deverá ser capaz de determinar a entrada de um usuário com base em um sensor dedicado.

lxxxvii. O SCA deverá suportar a utilização de campos personalizados (campos definidos pelo usuário)

lxxxviii. O SCA deverá permitir a criação de campos personalizados. O SCA deverá suportar a até 1.000 campos personalizados.

lxxxix. O SCA deverá suportar campos personalizados pelas seguintes entidades: usuários de cartão, grupos de usuários de cartões, credenciais e visitantes.

xc. Os campos personalizados suportados deverão ser nos seguintes formatos: texto, números inteiros, números decimais, datas, booleanos e imagens (gráficas).

xci. O SCA deverá permitir que um usuário seja capaz de definir um valor padrão para um campo personalizado.

xcii. O SCA deverá possibilitar que sejam criados novos campos personalizados. Os novos tipos de campos personalizados devem basear-se nos campos personalizados padrão suportados. O SCA deve suportar os valores definidos pelo usuário a partir dos quais o operador deverá fazer uma seleção.

xciii. O SCA deverá possibilitar que os administradores tenham capacidade de definir quais usuários podem visualizar e modificar campos personalizados específicos. O SCA deverá limitar o acesso aos dados de campos personalizados a usuários com privilégios pré-definidos. O SCA deverá suportar consultas e geração de relatórios usando campos personalizados.

xciv. O SCA deverá possibilitar que campos personalizados popossam ser agrupados e ordenados dentro destes grupos, como definido pelo usuário.

xcv. O SCA deverá possuir uma ferramenta para auxiliar na importação dos valores de campos personalizados.

xcvi. O SCA deverá deverá possuir uma ferramenta de importação de dados externos



xcvii. O SCA deverá suportar uma ferramenta de importação integrada para facilitar a importação de usuários existentes e dados da sua credencial. A importação de dados deverá ser através do uso de formato de arquivo CSV. A ferramenta deverá estar disponível na interface de configuração do usuário.

xcviii. A ferramenta de importação do SCA também deverá possibilitar a importação manual dos dados que foram exportados a partir de um banco de dados de terceiros, se fir em formato CSV.

A ferramenta de importação do SCA deverá permitir a importação dos seguintes dados:

o Nome do usuário do cartão, descrições, foto, email, e situação do usuário

o Informações sobre o grupo de usuários do cartão o Nome da credencial, situação da credencial, formato e o número do

cartão (incluindo credenciais com formatos personalizados) o Informações sobre partição o Campos personalizados

xcix. O SCA deverá possibilitar total flexibilidade na escolha dos campos de importação

durante uma sessão de importação.

c. A opção de usar uma chave única do usuário do cartão personalizado, deve ser especificado durante o processo de importação para garantir que os titulares com nomes duplicados não vai ter seus dados substituídos. Geração de chaves do titular do cartão deve ser automatizado. O usuário final terá a opção de selecionar quais campos serão usadas para criar esta chave única, por exemplo, número de credenciais, campos personalizados, nome do titular do cartão.

ci. O SCA também deverá suportar re-importação de um arquivo CSV contendo novas informações para atualizar as informações existentes no banco de dados do SCA. A re-importação deverá permitir alterações em massa para os dados de controle de acesso existentes.

cii. O SCA deverá suportar a utilização de clientes Web

ciii. O SCA deverá permitir acessos de cliente Web tais como: configuração, gerenciamento e geração de relatóriois de atividades do SCA.

civ. O cliente Web deverá ser acessível através do Microsoft Internet Explorer. O cliente Web deverá ser um cliente especifico para ambiente Web, não devendo exigir o carga de quaisquer arquivos ou executáveis específicos de SCA na estação de trabalho cliente.

cv. O cliente Web do SCA deverá disponibilizar as seguinte funcionalidades: Configuração e gerenciamento de usuários e grupos de usuários de cartão Configuração e gerenciamento de credenciais Configuração e gerenciamento de regras de acesso Impressão de crachás através da rede Designação de regras de acesso a portas e áreas Gerenciamento de visitantes, incluindo “registro de entrada” e “registro de

saída” de visitantes e geração de relatórios Geração de relatórios avançados



V. CÂMERAS E ACESSÓRIOS

COMPONENTES DE TECNOLOGIA DA INFORMAÇÃO a. Servidor de Gerenciamento do Sistema de CFTV (Diretório Principal)

(Padrão rack)

i. Processador: 02 (dois) processadores com núcleo de processamento compatível com Dual-

Core Xeon®; Velocidade mínima, de freqüência do clock de 3.00 Ghz, 1333 MHz FSB; Cache interno de no mínimo 8 MB (1 x 8 MB) de Nível 3 (L3); Potência 80w; Capacidade para segundo processador na mesma placa: Dual Processor (DP); Referencia: Intel® Xeon® Dual-Core Processor 5160, ou superior

ii. Placa Mãe:

Capacidade de multiprocessamento simétrico (SMP) para 02 (dois) processadores compatível com Dual-Core Xeon®, equipada com 02(dois) processadores;

Com dezoito soquetes de memória padrão DDR3 DIMM permitindo expansão no mínimo até 24 GB (vinte e quatro gigabytes), utilizando memória PC3-10600 DDR3 Unbuffered (UDIMM) operando à 1333MHz;

iii. BIOS:

Implementação em memória tipo Flash EPROM atualizável por software; Implementar o padrão DMl 2.0 nos padrões recomendados pelo DMTF; Armazenamento dos dados do setup em memória não volátil; Possuir capacidade de reconhecer características plug & play.

iv. Barramentos e Interfaces de I/O:

Arquitetura PCI-X ou PCI 64 Bits, com ao menos 02 (dois) slots PCIExpress;

01 porta mini-DIN para mouse padrão PS/2, e 01 para teclado padrão PS/2; Dispositivo de conexão USB 2.0 integrada com no mínimo 4 (quatro)

interfaces;

v. Placas instaladas: 01 controladora SAS 3.0 GB/s com cache para controladora, memória de

256MB e capacidade para (RAID 0/1/1+0/5). 02 (duas) interfaces de rede, padrão Gigabit Ethernet, com reconhecimento

automático de velocidade: 10/100/1000 Mbps, com conector RJ-45; Totalmente configuráveis por software; Suporte para os protocolos NetBEUI, IPX/SPX e TCP/IP; Implementada com os padrões IEEE 802.3x, 802.3z, 802.1p e 802.1Q;

Driver: 16x DVD+/- RW;

vi. Memória: Memória principal PC3-10600R (DDR3-1333) Registered DIMMs, com no

mínimo 08 GB (oito gigabytes);



Detecção/Correção de erros de memória ECC e SDDC implementado por hardware, com tolerância à falhas.

vii. Discos Rígidos:

(o Sistema Operacional e o Banco de Dados devem ser instalados em HD´s diferentes);

viii. HD p/ Sistema Operacional:

01 (ums) disco rígido SATA em RAID 1, 2.5”, 7200 RPM (ou superior), hot-plug/hot-Swap com capacidade de no mínimo 80 GB (Oitenta Gigabytes) (ou superior);

Capacidade interna de armazenamento na máquina para ao menos 04 (quatro) discos de 2,5”;

Suporte a RAID 0, 1, 5, 10;

ix. HD p/ Banco de Dados: 01 (ums) disco rígido SATA em RAID 1, 2.5”, 7200 RPM (ou superior), hot-

plug/hot-Swap com capacidade de no mínimo 80 GB (Oitenta Gigabytes) (ou superior);



x. Características Físicas de Operação:

Gabinete próprio para rack, altura máxima de 1U, com facilidade de ser aberto pela tampa superior ou lateral, sem a necessidade do uso de ferramentas e com sistema de fechadura, possuindo dois led’s frontais, indicando máquina ligada e acesso a disco rígido e com proteção frontal para o botão liga/desliga, ou em posição protegida;

Possuir, pelo menos, 02 (duas) fontes alimentação elétrica redundantes de troca dinâmica, com potência mínima suficiente para suprir o equipamento em sua configuração máxima e voltagem automática para 110/220VAC a 60Hz, com no máximo 460 Watts de potência, Hot-swap agregado com sistema energia de resfriamento, podendo ser externa;

Possuir sistema de arrefecimento redundante de troca dinâmica, com reconhecimento de parada de algum dos ventiladores;

Programas e drivers necessários à instalação, adequação e monitoração de todos os modos de funcionamento das placas, componentes internos e externos do Servidor;

Operar com as especificações EPA (Environmental Protection Agency, USA) e apresentar respectiva comprovação;

Possuir Certificado UL-1950, para garantir segurança quando operando em altas temperaturas e apresentar respectiva comprovação;

Possuir Certificado FCC e apresentar respectiva comprovação;

xi. Sistema Operacional:



Sistema Operacional Microsoft® Windows Server® 2008 Standard/Enterprise Edition R2 64-bit;

O sistema Operacional deve vir acompanhado de licença de uso; Deverão ser fornecidos os manuais de instalação e configuração, originais,

para futuras reinstalações;

xii. Softwares Instalados: O equipamento deve ser entregue com todos os softwares necessários ao

perfeito funcionamento da atividade para qual se destina, sendo: Software de Gerenciamento do Hardware (discos, memória, etc); Software de gerenciamento remoto através da porta RJ45 disponível no

servidor Software para executar diagnósticos, verificar configurações, carregar o

firmware mais recente, instalar correções, etc.

xiii. Garantia: O equipamento proposto deverá possuir garantia de 3 anos para reposição de

peças, mão de obra e atendimento no local.

xiv. Monitor LCD 17”

b. Servidor de Gerenciamento de Gravação do Sistema de CFTV (Padrão rack)

i. Processador:

02 (dois) processadores com núcleo de processamento compatível com Quad-Core Xeon®;

Velocidade mínima, de freqüência do clock de 2.66 Ghz, 1333 MHz FSB; Cache interno de no mínimo 8 MB (1 x 8 MB) de Nível 3 (L3); Potência 80w; Capacidade para segundo processador na mesma placa: Dual Processor (DP); Referencia: Intel® Xeon® Quad-Core Processor E5430, ou superior

ii. Placa Mãe:

Capacidade de multiprocessamento simétrico (SMP) para 02 (dois) processadores compatível com Quad-Core Xeon®, equipada com 02(dois) processadores;

Com dezoito soquetes de memória padrão DDR3 DIMM permitindo expansão no mínimo até 24 GB (vinte e quatro gigabytes), utilizando memória PC3-10600 DDR3 Unbuffered (UDIMM) operando à 1333MHz;

iii. BIOS:

Implementação em memória tipo Flash EPROM atualizável por software; Implementar o padrão DMl 2.0 nos padrões recomendados pelo DMTF; Armazenamento dos dados do setup em memória não volátil; Possuir capacidade de reconhecer características plug & play. Barramentos e Interfaces de I/O: Arquitetura PCI-X ou PCI 64 Bits, com ao menos 02 (dois) slots

PCIExpress; 01 porta mini-DIN para mouse padrão PS/2, e 01 para teclado padrão PS/2;



Dispositivo de conexão USB 2.0 integrada com no mínimo 4 (quatro) interfaces;

iv. Placas instaladas:

01 controladora SAS 3.0 GB/s com cache para controladora, memória de 256MB e capacidade para (RAID 0/1/1+0/5).

02 (duas) interfaces de rede, padrão Gigabit Ethernet, com reconhecimento automático de velocidade: 10/100/1000 Mbps, com conector RJ-45; Totalmente configuráveis por software; Suporte para os protocolos NetBEUI, IPX/SPX e TCP/IP; Implementada com os padrões IEEE 802.3x, 802.3z, 802.1p e 802.1Q;

Driver: 16x DVD+/- RW;

v. Memória: Memória principal PC3-10600R (DDR3-1333) Registered DIMMs, com no

mínimo 08 GB (oito gigabytes); Detecção/Correção de erros de memória ECC e SDDC implementado por

hardware, com tolerância à falhas.

vi. Discos Rígidos: (o Sistema Operacional e o Banco de Dados devem ser instalados em HD´s

diferentes);

vii. HD p/ Sistema Operacional: 01 (um) disco rígido SATA em RAID 1, 2.5”, 7200 RPM (ou superior), hot-




viii. HD p/ Banco de Dados: 01 (um) disco rígido SATA em RAID 1, 2.5”, 7200 RPM (ou superior), hot-




ix. Características Físicas de Operação:

Gabinete próprio para rack, altura máxima de 1U, com facilidade de ser aberto pela tampa superior ou lateral, sem a necessidade do uso de ferramentas e com sistema de fechadura, possuindo dois led’s frontais, indicando máquina ligada e acesso a disco rígido e com proteção frontal para o botão liga/desliga, ou em posição protegida;

Possuir, pelo menos, 02 (duas) fontes alimentação elétrica redundantes de troca dinâmica, com potência mínima suficiente para suprir o equipamento em sua configuração máxima e voltagem automática para 110/220VAC a 60Hz, com no máximo 460 Watts de potência, Hot-swap agregado com sistema energia de resfriamento, podendo ser externa;



Possuir sistema de arrefecimento redundante de troca dinâmica, com

reconhecimento de parada de algum dos ventiladores;

Programas e drivers necessários à instalação, adequação e monitoração de todos os modos de funcionamento das placas, componentes internos e externos do Servidor;

Operar com as especificações EPA (Environmental Protection Agency, USA) e apresentar respectiva comprovação;

Possuir Certificado UL-1950, para garantir segurança quando operando em altas temperaturas e apresentar respectiva comprovação;

Possuir Certificado FCC e apresentar respectiva comprovação;

x. Sistema Operacional:

Sistema Operacional Microsoft® Windows Server® 2008 Standard/Enterprise Edition R2 64-bit;

O sistema Operacional deve vir acompanhado de licença de uso;

Deverão ser fornecidos os manuais de instalação e configuração, originais, para futuras reinstalações;

xi. Softwares Instalados:

O equipamento deve ser entregue com todos os softwares necessários ao perfeito funcionamento da atividade para qual se destina, sendo:

Software de Gerenciamento do Hardware (discos, memória, etc);

Software de gerenciamento remoto através da porta RJ45 disponível no servidor

Software para executar diagnósticos, verificar configurações, carregar o firmware mais recente, instalar correções, etc.

xii. Garantia:

O equipamento proposto deverá possuir garantia de 3 anos para reposição de peças, mão de obra e atendimento no local.

xiii. Monitor LCD 17” c. Servidor Compacto de Gerenciamento e Gravação do Sistema de CFTV (Sites Remotos)

(Padrão gabinete Compacto)

i. Processador: 01 (um) processador com núcleo de processamento compatível com Intel

Atom Z530;



Velocidade mínima, de freqüência do clock de 1.6 Ghz; Chipset: Intel US15W

ii. Barramentos e Interfaces de I/O:

Dispositivo de conexão USB 2.0 integrada com no mínimo 4 (quatro) interfaces;

01 porta serial: RS-232; 02 portas USB 2.0; 02 portas Mini USB 2.0; 01 porta HDMI para monitor de saída: 1920x1080; 01 conector line-out 2.0: S/PDIF 5.1 channel stereo audio; 01 conector mic in, line-in; 02 conectores RJ-45, Base-T: Ethernet 1Gb; 01 conector de antena WiFi: 802.11b/g;

iii. Memória:

Memória principal 1 GB (um gigabyte) DDR2;

iv. Discos Rígidos: 01 (um) disco rígido SATA de 2,5” com capacidade de no mínimo 160 GB

(Cento e Sessenta Gigabytes) (ou superior);

v. Armazenamento Externo: Network Attached Storage (NAS);

vi. Características Físicas de Operação:

Gabinete compacto em alumínio, medindo 101mm x 115mm x 27mm e peso

aproximado de 370 gramas, possuindo três led’s frontais, indicando máquina ligada, acesso a disco rígido e acesso a rede;

Possuir uma fonte externa de alimentação elétrica com potência mínima suficiente para suprir o equipamento em sua configuração máxima e voltagem de 110/220VAC a 50Hz/60Hz 0,5 A para 12VDC, com potência entre 6 a 8 Watts;

Sem necessidade de sistema de resfriamento forçado (cooler);

Operar em temparaturas oscilando entre (-0°C a 45°C) com temperatura do HDD, e humidade ambiente variando entre 5% a 95% (não condensada);

Possuir Certificação CE Classe B, FCC Classe B, RoHs;

vii. Sistema Operacional: Sistema Operacional Microsoft® Windows Embedded Standard 7;

viii. Sistema Gerenciador de Banco de Dados:

Sistema Operacional Microsoft® SQL Express 2005;

ix. Softwares Instalados: O equipamento deve ser entregue com todos os softwares necessários ao

perfeito funcionamento da atividade para qual se destina, sendo:



Sistema Operacional; Sistema Gerenciador de Banco de Dados; Sistema de Gerenciamento e Gravação de Vídeo IP;

x. Garantia:

O equipamento proposto deverá possuir garantia de 2 anos para reposição de peças, mão de obra e atendimento no local.

xi. Monitor LCD 17”

4 - INTERVENÇÃO TÉCNICA NA SUBESTAÇÃO

4.1 - Especificação dos Materiais e Serviços a serem aplicados na Subestação

a. Manutenção preventiva em Transformardor de até 300 kVA, a qual deverá executar no

mínimo as seguintes atividades:

i. Substituição do óleo isolante tipo ""A"".

ii. Revisão nas chaves secas de média tensão.

iii. Limpeza e/ou substituição de isoladores, conforme necessidade.

iv. Manutenção preventiva em disjuntor eletromagnético, a qual deverá executar no mínimo as seguintes atividades: Desmontagem parcial; Inspeção visual criteriosa; Limpeza geral com produto especial isolante (isolação 26 KV); Verificação dos contatos principais e corta arcos; Verificação das peças isolantes; Verificação das câmaras de extinção; Verificação dos separadores de contatos; Verificação dos dispositivos de abertura; Verificação das travas de fechamento; Verificação de peças do conjunto de carregamento de molas; Verificação de circuitos auxiliares, motor, bobinas, micros, fiação, chaves

auxiliares, sinalização, comando/controle do disjuntor; Lubrificação das partes móveis e deslizantes; Reaperto de conexões elétricas e mecânicas; Ensaios de resistência ôhmica de contatos; Ensaios de resistência ôhmica de isolamento; Ensaios finais de funcionamento; Fornecimento de relatório técnico.

v. "Manutenção Preventiva em Quadro Geral, a qual deverá executar no mínimo as

seguintes atividades: Limpeza, reaperto e substituição de componentes Desmontagem parcial; Inspeção visual criteriosa; Limpeza geral com produto especial isolante (isolação 26 KV); Verificação dos contatos principais e corta arcos; Verificação das peças isolantes;



Verificação das câmaras de extinção; Verificação dos separadores de contatos; Verificação dos dispositivos de abertura; Verificação das travas de fechamento; Verificação de peças do conjunto de carregamento de molas; Verificação de circuitos auxiliares, motor, bobinas, micros, fiação, chaves

auxiliares, sinalização, comando/controle do disjuntor; Lubrificação das partes móveis e deslizantes; Reaperto de conexões elétricas e mecânicas; Ensaios de resistência ôhmica de contatos; Ensaios de resistência ôhmica de isolamento; Ensaios finais de funcionamento; Fornecimento de relatório técnico."

5 – GARANTIA

b. Os materiais de cabeamento estruturado fornecidos deverão ser de um único fabricante de modo a garantir as características de desempenho do sistema e a empresa instaladora (licitante) deverá ser habilitada pelo fabricante, e este, oferecer Garantia Estendida de Instalação no mínimo de 25 (vinte e cinco) anos, que deverá ser comprovada através de documento, emitido especificamente para este projeto e endereçado ao DNIT/RN. Em caso de fabricação em regime de OEM e/ou permissão de uso da marca, será permitida a utilização do produto desde que com anuência do fabricante de hardware de conexão, que passará a ser responsável pela garantia estendida de todo o sistema de cabeamento estruturado.

c. Os materiais de infraestrutura tais como calhas e eletrocalhas, devem ter garantia mínima de

2 (dois) anos.

d. Os demais materiais e equipamentos tem seu período de garantia mínima descrita no corpo dessa especificação.

e. Em casos onde não haja descrição de garantia, esta deverá ser de no mínimo 1 (um) ano.



6 – DESENHOS E ESQUEMAS

4.1 – Plantas:

a. São partes integrantes deste projeto, pranchas contendo os desenhos com a localização dos pontos de rede elétrica, cabeamento estruturado e segurança eletrônica;

b. A localização dos pontos nas plantas poderá sofrer alterações no decorrer da instalação, sem

que haja ônus adicional para o DNIT.



7 – ESTIMATIVA DE CUSTOS DE MATERIAIS, EQUIPAMENTOS E SERVIÇOS ITEM QUANT UNID DESCRIÇÃO VALOR SUBTOTAL

1 400 cj Materiais de Infraestrutura para Cabeamento Estruturado 396,99 158.796,00

2 400 cj Materiais de Infraestrutura para Rede Elétrica 396,99 158.796,00

3 400 cj Materiais de cabeamento estruturado 456,83 182.732,00

4 400 cj Materiais para instalação elétrica 168,16 67.264,00

5 1 cj Backbone de Telefonia 25.597,37 25.597,37

6 1 cj Backbone de Dados 16.211,90 16.211,90

7 4 cj Quadro QDE para 24 circuitos 5.777,41 23.109,64

8 4 cj Alimentador para quadro QDE 16.142,18 64.568,72

9 2 pç Unidade Remota de Sistema de Telemetria 49.379,55 98.759,10

10 1 pç Nobreak Tipo I - 80 kVA 167.890,47 167.890,47

11 10 pç Nobreak Tipo II - 1,2 kVA 1.030,03 10.300,30

12 13 m2 Piso elevado para Sala CPD com rampa de acesso 493,80 6.419,40

13 1 cj Automatizador de porta de correr 26.664,96 26.664,96

14 1 sw Sistemas Integrado de Vídeo Monitoramento em Rede e Controle de Acesso 124.792,00 124.792,00

15 3 cj Appliance (Servidor Compacto) Vídeo Monitoramento em Rede e Controle de Acesso com 500 GB 22.754,10 68.262,30

16 48 pç Câmera HD com infravermelho 15m 3.703,47 177.766,56

17 48 sw Licença do Sistema de Monitoramento em Rede por câmera 853,28 40.957,44

18 6 pç Leitor padrão MIFARE 1K 3.470,00 20.820,00

19 6 sw Licença de conexão para Leitor MIFARE para Sistema de Controle de Acesso 1.955,43 11.732,58

20 1 pç Gateway de rede para controle de acesso 7.515,96 7.515,96

21 3 pç Fechadura eletromagnética(completa) 1.755,44 5.266,32

22 2100 hh Engenheiro Eletricista ou Eletrônico ou Telecomunicações Pleno 165,67 347.907,00

23 2100 hh Encarregado de Instalações 98,76 207.396,00

24 2100 hh Técnico em Eletrotécnica 64,64 135.744,00

25 2100 hh Técnico em Telecomunicações 64,64 135.744,00

26 8400 hh Auxiliar Técnico 38,15 320.460,00

27 352 hh Engenheiro Eletrônico ou Telecomunicações Pleno 165,67 58.315,84

28 352 hh Encarregado de Instalações 98,76 34.763,52

29 352 hh Técnico em Eletrônica 64,64 22.753,28

30 352 hh Técnico em Telecomunicações 64,64 22.753,28

31 2112 hh Auxiliar Técnico 38,15 80.572,80

VALOR GLOBAL DE PRODUTOS E SERVIÇOS 2.830.632,74

Materiais de Rede Elétrica e Cabeamento Estruturado

Mão-de-obra para Rede Elétrica e Cabeamento Estruturado

Mão-de-obra para Vídeo Monitoramento em Rede e Controle de Acesso

Materiais de Vídeo Monitoramento em Rede e Controle de Acesso

Documents

CABEAMENTO ESTRUTURADO E REDE ELÉTRICA - DNIT — … · Aucon Tecnologia CNPJ: 09.058.526/0001-05 * Insc. Municipal 12011501 End. Fiscal: Av. Pedro Teixeira, nº. 1000 - Bl A -