AXIS Fence Guard — Detecção de Intrusão e Proteção Perimetral

AXIS Fence Guard é um aplicativo de análise de vídeo embarcado para detecção de cruzamento de uma linha virtual em câmeras e codificadores Axis compatíveis. Ele integra a família legada AXIS Guard Suite e foi projetado para cenários de intrusão em áreas de baixo tráfego, especialmente perímetros e zonas monitoradas fora do horário de operação.

Hoje, a própria Axis recomenda AXIS Object Analytics nas câmeras compatíveis com AXIS OS 10.2 ou superior. O Fence Guard permanece relevante para parque instalado e equipamentos que não suportam Object Analytics, mas precisa ser tratado como tecnologia de transição: o AXIS OS 13 remove Fence Guard, Motion Guard e Loitering Guard.

Por isso, a engenharia da solução precisa responder a duas perguntas distintas: como manter e comissionar corretamente o Fence Guard existente e como planejar a migração para Object Analytics sem perder lógica de eventos, áreas, ações e critérios de detecção.

Condição observada	Risco	Resposta de engenharia
Equipamento em AXIS OS 7.10–12.11	Aplicação funciona, mas está em ciclo legado	Registrar versão, compatibilidade e estratégia de atualização
Upgrade para AXIS OS 13	Fence Guard é removido	Migrar lógica para AXIS Object Analytics antes do upgrade
Regra baseada apenas em movimento	Mais alarmes indevidos por objetos não relevantes	Avaliar classificação de humanos/veículos em Object Analytics
Cerca virtual sem procedimento operacional	Evento detectado sem resposta definida	Vincular evento, ação, VMS e responsável
Mudança de câmera, lente ou enquadramento	Linha virtual deixa de representar o perímetro	Reconfigurar e recomissionar o cenário

Como o AXIS Fence Guard funciona

O Fence Guard analisa o vídeo diretamente na borda e gera evento quando um objeto em movimento cruza uma linha virtual na direção configurada. Como o processamento ocorre no dispositivo, o evento pode ser utilizado pelo próprio mecanismo de regras da câmera ou encaminhado a um VMS compatível.

O aplicativo é baseado em movimento, não em classificação semântica. Isso significa que a condição principal é o cruzamento da linha por movimento detectado, independentemente de o objeto ser uma pessoa, veículo ou outro elemento. Filtros ajudam a reduzir alarmes indesejados, mas não transformam o algoritmo em classificador de objetos.

Esse ponto diferencia diretamente Fence Guard de AXIS Object Analytics, que utiliza detecção e classificação de objetos em câmeras compatíveis. A migração não é apenas uma mudança de interface; ela altera o mecanismo que decide o que constitui um evento relevante.

Linha virtual, direção e perfis

A regra é construída sobre uma linha virtual desenhada no campo de visão da câmera. A direção de disparo define de que lado para que lado o cruzamento deve gerar evento. O posicionamento da linha precisa representar o limite físico ou operacional que o projeto pretende proteger.

Fence Guard permite utilizar perfis diferentes, por exemplo para períodos do dia ou regiões específicas da cena. Isso é útil quando iluminação, fluxo ou finalidade operacional mudam ao longo do tempo.

Perfis não devem ser usados como forma de compensar uma cena mal projetada. Se a câmera possui perspectiva inadequada, vibração ou o perímetro está parcialmente ocluído, alternar parâmetros pode apenas mascarar a causa do problema.

Filtros e redução de alarmes indevidos

O aplicativo possui filtros para ignorar objetos pequenos e movimentos de curta duração ou comportamento semelhante a ruído visual, dependendo da versão e do dispositivo. A própria documentação recomenda utilizar esses mecanismos para reduzir alarmes causados por pequenos animais, faróis e sombras rápidas.

Filtros precisam ser ajustados conservadoramente. Um limite alto demais pode eliminar o intruso que o sistema deveria detectar; um limite baixo demais pode saturar a operação com alarmes. O ajuste correto depende da distância do objeto, perspectiva e geometria do campo de visão.

Como o algoritmo é orientado a movimento, fenômenos ambientais continuam relevantes. Vegetação, reflexos, sombras, chuva intensa, insetos próximos da lente e vibração da câmera podem produzir eventos que não representam intrusão real.

Arquitetura edge e integração com eventos

Por executar na própria câmera ou encoder, Fence Guard não exige servidor analítico central. O evento pode ser utilizado pelo mecanismo de regras do dispositivo para iniciar gravação, enviar notificação, acionar uma saída, reproduzir áudio, ligar iluminação ou chamar outra ação disponível no ecossistema Axis.

Também pode ser encaminhado ao VMS. Nesse caso, o projeto precisa validar nome do evento, camera ID, timestamp, pre-recording e comportamento de gravação para que a ocorrência possa ser investigada posteriormente.

Quando diferentes subsistemas respondem ao mesmo evento — por exemplo, VMS, áudio e iluminação — a lógica precisa definir prioridade, duração e comportamento de recuperação. O analytics apenas gera a condição; a automação operacional pertence ao sistema integrado.

Compatibilidade e ciclo de AXIS OS

A página atual da Axis informa compatibilidade do Fence Guard com dispositivos suportados em AXIS OS 7.10 a 12.11. Em câmeras com firmware 10.2 ou superior que suportam Object Analytics, a recomendação do fabricante é utilizar a aplicação mais nova.

O lifecycle guide do AXIS OS informa que Fence Guard, Motion Guard e Loitering Guard são removidos no AXIS OS 13. APIs associadas também deixam de existir, de modo que clientes ou integrações que esperam esses aplicativos podem apresentar erro após a atualização.

Isso transforma firmware em requisito de arquitetura. Um plano de atualização não deve considerar apenas vulnerabilidades e suporte do dispositivo: ele precisa mapear quais ACAPs estão instalados, quais eventos são consumidos e qual função deve substituí-los.

Migração para AXIS Object Analytics

AXIS Object Analytics substitui os casos principais de Motion Guard, Fence Guard e Loitering Guard em dispositivos compatíveis e adiciona classificação de humanos e veículos. Para o cenário equivalente a Fence Guard, o ponto de partida é normalmente Line crossing.

A migração não deve ser feita copiando apenas a posição da linha. É necessário redefinir objetos disparadores, direção, filtros, exclusões, comportamento de evento e ações do dispositivo. Uma regra antiga que disparava para qualquer movimento pode se tornar muito mais seletiva ao restringir a pessoas ou veículos.

Object Analytics também possui requisitos próprios de montagem, tamanho mínimo do objeto, iluminação, contraste e campo de visão. Portanto, a existência de uma câmera compatível não garante que a cena originalmente projetada para Fence Guard atingirá a mesma cobertura com classificação de objetos.

Fence Guard	Object Analytics	Impacto da migração
Crossing baseado em movimento	Line crossing com classificação	Permite restringir por humano/veículo
Filtros de movimento	Classes + filtros e condições	Tuning precisa ser refeito
Perfis da aplicação	Múltiplos cenários simultâneos	Arquitetura de regras pode ser reorganizada
Eventos Guard Suite	Eventos Object Analytics	VMS e automações precisam ser remapeados

Critérios de cena para a migração

Object Analytics depende de objetos suficientemente grandes e visíveis. A documentação atual recomenda, para reduzir risco de perda de detecção, altura mínima aproximada de 8% da imagem para humanos e 6% para veículos, embora condições ideais possam permitir valores menores.

Iluminação, contraste, oclusão e direção de movimento também importam. Pessoas parcialmente ocultas, veículos surgindo atrás de obstáculos, faróis, chuva e sombras podem reduzir classificação ou gerar alarmes indevidos.

Assim, uma migração tecnicamente correta começa por revisar a cobertura existente e não apenas por instalar o novo aplicativo.

Estratégia para parque instalado

Em parque legado, não é necessário substituir imediatamente toda ocorrência de Fence Guard. A prioridade deve ser identificar quais dispositivos podem permanecer em AXIS OS 12.11 dentro do ciclo de suporte aplicável, quais suportam Object Analytics e quais dependem de hardware antigo sem caminho de migração equivalente.

Essa matriz permite planejar upgrade por risco. Câmeras críticas podem ser migradas primeiro, enquanto equipamentos de baixa criticidade permanecem temporariamente na configuração existente com firmware e exposição de rede controlados.

Quando o hardware não suporta Object Analytics e a atualização de AXIS OS ou os requisitos de segurança exigem evolução, a substituição da câmera pode ser parte do lifecycle do sistema e não apenas uma decisão de analytics.

Verificação, comissionamento e aceite

No Fence Guard existente, o teste deve verificar linha, direção, filtros, evento e ação. Devem ser realizados cruzamentos válidos e situações que não deveriam disparar, incluindo movimento próximo ao limite e objetos pequenos.

Na migração para Object Analytics, os mesmos cenários precisam ser repetidos com classificação habilitada. O aceite deve registrar se o novo cenário reduz alarmes indevidos sem introduzir misses relevantes.

Upgrade de firmware também deve ser testado em laboratório ou amostra controlada quando houver integração com VMS ou automações dependentes das APIs antigas.

Documentação e rastreabilidade

O as built deve identificar câmeras ainda em Fence Guard, versão do aplicativo, AXIS OS, perfil, linha, direção, filtros e ações associadas. Também deve registrar quais dispositivos possuem plano de migração e qual cenário Object Analytics substituirá a regra existente.

Essa rastreabilidade é particularmente importante antes de atualizar para AXIS OS 13, porque a ausência de inventário pode transformar uma atualização de firmware em perda inesperada de função analítica.

Serviços que materializam a solução

O Projeto de CFTV IP e Videomonitoramento estrutura cobertura, câmera, VMS e eventos. Ensaios e Testes Técnicos permitem comparar o comportamento do Fence Guard e do cenário equivalente em Object Analytics.

Comissionamento de Equipamentos valida regras e ações após migração. O As-Built de Engenharia registra a baseline e o roadmap do parque remanescente.