Segurança De Shopping 3

O que funciona e o que não funciona na prática

A maioria das empresas que implanta segurança de shopping 3 começa errando na instalação dos sensores periféricos. Eu vi isso várias vezes. O problema não é o software em si, é que o hardware de cerco — câmeras com detecção de faixa de calçamento, sensores de presença nos estacionamentos, leitores de porteiras — precisa estar sincronizado com o sistema antes de qualquer coisa. Quando isso não é feito, o módulo de integração trava e você perde cerca de 40 minutos toda vez que reinicia o servidor.

Configurando segurança de shopping 3 do zero

Vamos direto ao ponto. O primeiro passo é baixar a versão mais recente do pacote de instalação no portal do fabricante. A URL costuma ser a que termina em /downloads/security-suite, mas isso muda conforme a versão. Verifique sempre se o checksum bate com o que está publicado na página, senão você pode terminar com uma DLL corrompida e perder meia tarde tentando debugar. Após a instalação, o assistente de configuração pede os dados do banco de dados. Use PostgreSQL 14 ou superior. MySQL ainda é suportado, mas tenho visto instabilidade com queries de geolocalização que o sistema faz automaticamente quando você ativa o mapa de calor de movimentação. Fique com PostgreSQL mesmo.

A parte mais crítica é o mapeamento das zonas. Cada loja, corredor, banheiro, área de entregadores e ponto de acesso veículos recebe um identificador único. Comece pelo estacionamento — é onde 60% dos incidentes são registrados. Se você pular essa etapa ou fizer rápido, o relatório noturno vai venir com buracos enormes e ninguém vai conseguir auditar nada. Depois das zonas, configure os perfis de acesso. O sistema vem com quatro níveis padrão: observador, operador, supervisor e administrador. Eu nunca distribuo o nível de supervisor para mais de duas pessoas por unidade. Quanto mais gente com esse nível, mais difícil fica rastrear quem alterou qual configuração. Já perdi dois dias inteiros só tentando entender quem desativou o registro de vídeo de uma câmera durante três horas num sábado à noite.

Integração com hardware existente

Aqui é onde a coisa fica interessante. Segurança de shopping 3 suporta protocolos ONVIF Profile S e T para câmeras, mas também tem um driver proprietário para fechaduras eletromagnéticas e barreiras infravermelhas que funciona melhor do que as integrações genéricas. O detalhe é que o driver proprietário exige uma placa de interface USB 2.0 dedicada. Se você tentar rodar por rede diretamente, a latência sobe para algo em torno de 800 milissegundos, o que é aceitável para monitoramento mas ruim demais para abrir e fechar portões em tempo real. Um problema bem específico que eu encontrei: quando há mais de 32 câmeras ONVIF conectadas, o módulo de gravação simultânea começa a dropping frames nas câmeras 29 a 32. A solução que encontrei foi dividir o streaming em dois grupos e usar dois servidores de gravação diferentes, cada um responsável por metade das câmeras. Isso adiciona complexidade na hora de revisar o histórico, mas resolve o gargalo completamente. Leva cerca de 25 minutos para configurar essa divisão.

Outro ponto que ninguém comenta nos manuais: o sistema não trata bem mudanças de horário de verão. A cada transição, os timestamps dos registros ficam desalinhados por uma hora. A workaround que uso é rodar um script Python simples que ajusta todos os metadados dos arquivos de vídeo após cada mudança de horário. O script leva uns 10 minutos pra rodar num banco de 500 GB e resolve o problema até a próxima transição.

O que o relatório padrão esconde

Os relatórios gerados automaticamente mostram movimentação por horário, incidentes categorizados e tempo médio de resposta das equipes. Parece completo, mas tem duas lacunas importantes. A primeira é que o sistema não consolida incidentes que acontecem em zonas adjacentes dentro de uma janela de cinco minutos. Se alguém entra na loja A e depois some na loja B contígua, o sistema gera dois registros separados em vez de um único evento de perseguição. Você precisa ativar manualmente a regra de correlação espacial, que fica escondida nas configurações avançadas sob o menu Processamento de Eventos. A segunda lacuna é mais grave: o módulo de análise de comportamento usa modelos treinados com dados de shoppings americanos. Padrões de comportamento no Brasil são diferentes — aglomerações em praças de alimentação, fluxo de pedestres em horários de pico diferentes, práticas de venda de rua que são tratadas como suspeitas pelo algoritmo. No início, eu tinha um índice falso positivo de cerca de 35%. Ajustei reduzindo a sensibilidade da detecção de aggregated crowd em 40% e configurando janelas de tempo específicas para cada região do mall. O índice caiu para algo entre 8 e 12%, que é muito mais razoável.

Limitações reais do sistema

Segurança de shopping 3 não é uma solução perfeita e é importante saber onde ela quebra. Primeiro, a licença é por câmara ativa. Se você tiver 120 câmeras e precisar adicionar mais 30 temporariamente num evento, vai ter que comprar 30 licenças extras ou operar sem cobertura nessas novas câmeras por no máximo 72 horas antes do sistema começar a flagrar irregularidades de compliance. Segundo, o suporte técnico responde em até 48 horas úteis, o que é problemático se algo parar num domingo à noite. Terceiro, o backup automático sobrescreve os arquivos dos últimos 14 dias sem aviso prévio. Se você precisa preservar evidências de um incidente específico, faça backup manual imediatamente. O sistema não tem um modo de preservação de evidências nativo. Para operações com mais de 200 câmeras, eu recomendo considerar também uma solução complementar de video management em camada separada. A combinação dos dois sistemas custia mais, mas a redundância vale a pena quando o shopping tem múltiplos turnos e a equipe de segurança não consegue acompanhar o volume de alertas que segurança de shopping 3 gera sozinho.

Dicas que vêm da prática, não do manual

Mantenha o servidor de aplicação em outro rack físico do que o servidor de banco de dados. Eu vi um caso em que um curto-circuito num dos racks derrubou ambos e o shopping ficou seis horas sem gravação. A perda foi de uma filmagem que posteriormente se revelou crucial para um processo judicial. Segundo, teste o plano de contingência todo trimestre. Desligue o servidor principal de propósito e veja quanto tempo leva para o sistema de failover entrar no ar. Na maioria das instalações que eu inspectei, o failover levava entre 12 e 18 minutos, o que é tempo demais para um incidente em andamento. Configure o heartbeat para disparar em no máximo 5 minutos. Por último, treine os operadores para diferenciar alerta de ocorrência. O sistema vai gerar alertas o dia todo — detecção de movimento após fechamento, porta de carga aberta por tempo prolongado, veículo parado em zona restrita. Nem tudo virou ocorrência. Se o operador marcar tudo como ocorrência, o banco de dados cresce sem controle e a revisão vira um pesadelo. Estabeleça um critério claro: alertas que não forem confirmados como reais em até 15 minutos devem ser arquivados automaticamente como falso positivo. Isso limpa o histórico e mantém os indicadores de performance confiáveis.