AXIS Loitering Guard — Detecção de Permanência em Áreas Monitoradas

AXIS Loitering Guard é um aplicativo de análise de vídeo embarcado em dispositivos Axis compatíveis, desenvolvido para detectar objetos que permanecem em movimento dentro de uma área por tempo superior ao limite configurado. O evento pode ser utilizado para iniciar gravação, gerar alarmes, acionar dispositivos ou alimentar um software de gerenciamento de vídeo.

A aplicação é particularmente útil em áreas de baixo fluxo nas quais a permanência prolongada representa uma condição de interesse, como cercas, estacionamentos, pátios e zonas restritas fora do horário normal. O desempenho depende da geometria da cena, perspectiva, tamanho aparente dos objetos, filtros e tempo de permanência adotado.

O Loitering Guard deve ser tratado hoje também como uma solução de ciclo de vida. A Axis mantém o aplicativo para dispositivos e versões compatíveis, mas recomenda AXIS Object Analytics em câmeras compatíveis com firmware 10.2 ou superior; além disso, a migração para AXIS OS 13 remove Motion Guard, Fence Guard e Loitering Guard, substituindo suas funções pelo Object Analytics. Portanto, compatibilidade de câmera e estratégia de atualização fazem parte da decisão de engenharia.

Condição observada	Risco ou limitação	Resposta de engenharia
Permanência prolongada em área de baixo fluxo	Evento relevante pode não ser percebido pelo operador em tempo útil	Definir área, tempo, filtros e ação associada ao evento
Vegetação, sombras ou pequenos animais na cena	Alarmes indevidos e perda de confiança no analytics	Ajustar filtros, perspectiva e área de interesse
Objeto permanece parado após entrar na área	Comportamento pode diferir do caso de uso esperado	Validar a condição de detecção e, quando necessário, avaliar cenário Time in area ou Occupancy no AXIS Object Analytics
Câmera prevista para atualização ao AXIS OS 13	O aplicativo legado deixa de estar disponível após a atualização	Planejar migração e revalidação para AXIS Object Analytics antes do upgrade
Evento sem integração ou procedimento operacional	Detecção ocorre, mas não produz resposta nem evidência útil	Relacionar evento, gravação, VMS, notificação e procedimento de resposta

Arquitetura e funcionamento da detecção de permanência

O AXIS Loitering Guard executa na borda, diretamente na câmera ou no codificador compatível. A análise acompanha objetos em movimento dentro de áreas configuradas e mede o tempo em que a condição permanece válida. Quando o limite é atingido, o aplicativo gera um evento que pode ser consumido pelo próprio dispositivo ou por sistemas externos.

A aplicação trabalha com perfis independentes. Cada perfil pode possuir área, condição, tempo e filtros próprios, o que permite diferenciar, por exemplo, uma regra para horário diurno e outra para período noturno ou tratar áreas distintas da mesma cena.

O Loitering Guard oferece duas condições temporais distintas, Individual e Group. A escolha precisa corresponder ao caso de uso porque as duas abordagens medem fenômenos diferentes e produzem respostas diferentes quando vários objetos entram, saem ou se aproximam entre si.

Condição Individual e condição Group

Na condição Individual, o aplicativo acompanha o tempo de cada objeto detectado. A contagem começa quando o objeto entra na área de inclusão e é reiniciada quando ele sai. Quando dois ou mais objetos se aproximam a ponto de serem tratados como um único objeto, o objeto resultante pode herdar o maior tempo de permanência já acumulado, comportamento que precisa ser conhecido em cenas com grupos ou fluxos próximos.

Na condição Group, o tempo é associado à presença de atividade na área, e não a uma identidade individual persistente. Enquanto houver objetos em movimento na área, a condição pode continuar acumulando tempo; depois de um período sem objetos, a contagem é reiniciada. Esse modo é adequado quando o evento relevante é a ocupação persistente da região, mesmo que os objetos mudem ao longo do intervalo.

As duas condições não são ativadas simultaneamente dentro do mesmo perfil. Quando uma aplicação precisa observar comportamento individual e de grupo na mesma cena, a configuração deve utilizar perfis distintos e regras de evento separadas, permitindo critérios, ações e evidências independentes.

Perfis, horários e posições PTZ

Perfis permitem criar configurações diferentes para dia e noite, regiões distintas da cena, múltiplas áreas de inclusão ou respostas operacionais diferentes. Cada perfil gera seus próprios alarmes e pode ser associado a regras de evento específicas, inclusive combinadas com schedules do dispositivo.

Em câmeras PTZ, um perfil pode ser associado a uma posição preset. Cada mudança de preset exige recalibração do analytics por alguns segundos, razão pela qual guard tours contínuos não são uma boa condição de operação para Loitering Guard. Se várias posições precisam ser monitoradas, o projeto deve prever presets estáveis, perfis correspondentes e tempo suficiente para a recalibração após cada movimento.

Área de interesse, perspectiva e filtros

A área de interesse deve abranger somente a região em que a permanência possui significado operacional. Incluir vias de passagem, vegetação ou regiões sem relevância aumenta a quantidade de objetos processados e pode gerar eventos sem valor para a operação.

A perspectiva é crítica porque o tamanho aparente do mesmo objeto varia conforme a distância da câmera. Em cenas com profundidade, a aplicação pode utilizar calibração de perspectiva para relacionar o tamanho do objeto na imagem ao tamanho físico esperado. Essa calibração é particularmente importante para o filtro de objetos pequenos, pois evita aplicar o mesmo limiar de pixels a um objeto próximo e a outro distante.

Quando a cena possui diferenças significativas de elevação, uma única calibração pode não representar adequadamente todo o plano observado. Nesses casos, a própria Axis recomenda dividir a cena em regiões e usar perfis distintos, cada um com sua área de inclusão e sua calibração de perspectiva. Em vistas superiores ou cenas nas quais a perspectiva não pode ser estimada de modo confiável, o filtro de pequenos objetos pode operar sem profundidade, utilizando dimensões diretamente ajustadas na imagem.

As áreas de exclusão permitem retirar regiões problemáticas de dentro da área de inclusão, como vegetação, reflexos ou equipamentos móveis. Quando um objeto entra em uma área de exclusão, sua contagem de permanência é pausada e pode continuar quando ele retorna à área válida. Por isso, áreas de exclusão não devem ser usadas sem compreender o efeito sobre a lógica temporal do evento.

Elemento de configuração	Função	Implicação de engenharia
Include area	Define onde a permanência pode gerar alarme	Deve excluir vias e fluxos normais próximos que possam invadir parcialmente a região monitorada
Exclude area	Ignora regiões internas problemáticas	Pausa a contagem do objeto enquanto ele permanece na área excluída
Small objects	Ignora objetos abaixo do tamanho configurado	Em cenas profundas, requer perspectiva calibrada; em cenas sem profundidade, usa tamanho diretamente na imagem
Swaying objects	Ignora objetos que se deslocam apenas uma pequena distância	Valor excessivo pode eliminar eventos válidos; deve começar pequeno e ser aumentado somente quando necessário
Loitering time	Define o tempo máximo antes do alarme	Precisa ser derivado do comportamento normal e do tempo aceitável de resposta

Os filtros são aplicados aos objetos detectados pela aplicação e devem ser usados com parcimônia. A recomendação do fabricante é ajustar primeiro as áreas, depois habilitar poucos filtros, um de cada vez, verificando visualmente o resultado antes de acrescentar outro. A redução de alarmes não pode ocorrer às custas da supressão dos objetos que deveriam ser detectados.

O tempo de permanência também é uma decisão de engenharia. Um limite curto aumenta sensibilidade, mas pode classificar como loitering comportamentos normais de passagem ou espera. Um limite longo reduz alarmes indevidos, porém aumenta o tempo até a geração do evento. O valor deve ser definido a partir do processo observado e do tempo aceitável de resposta.

Condições de cena e instalação da câmera

O desempenho começa antes da configuração do aplicativo. Chuva intensa ou neve podem afetar a detecção; iluminação insuficiente reduz a qualidade das informações disponíveis ao analytics; vibração excessiva da câmera pode ser interpretada como movimento na cena. O ponto de instalação precisa, portanto, oferecer estabilidade mecânica e condições de imagem compatíveis com a função pretendida.

Objetos pequenos ou muito distantes podem não ser detectados. Objetos que se aproximam diretamente do eixo óptico também precisam percorrer uma distância maior antes de produzir movimento suficiente no plano da imagem, quando comparados a objetos que atravessam lateralmente a cena. A orientação da câmera deve considerar o sentido real de aproximação das pessoas ou veículos monitorados.

Em áreas externas, alterações sazonais de vegetação, sombras, iluminação noturna e reflexos podem modificar o comportamento do cenário. Uma configuração aceita em determinado período não deve ser presumida permanente: mudanças que alterem o padrão de movimento ou o contraste da cena podem exigir novo tuning e novo teste.

Integração com VMS, gravação e resposta operacional

O evento produzido pelo analytics pode alimentar um VMS, regras locais do dispositivo ou outros sistemas compatíveis. A engenharia deve definir o que acontece quando o evento é gerado: iniciar ou marcar uma gravação, apresentar alarme ao operador, acionar áudio, iluminação, saída digital ou outro procedimento previsto.

O evento precisa manter contexto suficiente para investigação. Câmera, perfil, área, horário, gravação e ação associada devem ser identificáveis. Sem sincronismo de tempo ou sem gravação correspondente, o alerta pode perder valor como evidência.

Em sistemas com grande quantidade de câmeras, nomenclatura e severidade dos perfis devem seguir padrão comum. Isso facilita busca, auditoria e manutenção e reduz a possibilidade de regras com nomes semelhantes produzirem respostas diferentes sem documentação.

No próprio dispositivo Axis, cada perfil pode ser utilizado como condição de uma regra de evento. A ação pode iniciar gravação em cartão SD, acionar uma saída, reproduzir áudio ou executar outra função suportada pelo equipamento. Quando a mesma ação deve responder a qualquer perfil, a regra pode utilizar a condição agregada correspondente; quando cada área possui resposta diferente, os perfis devem permanecer separados.

Em dispositivos compatíveis, o alarm overlay pode desenhar uma caixa ao redor do objeto que gerou o evento. Esse overlay é incorporado permanentemente ao stream selecionado e não pode ser removido posteriormente da gravação. Por isso, sua utilização deve ser uma decisão consciente: ele pode facilitar investigação e diagnóstico, mas também altera a evidência visual armazenada.

A integração com VMS deve ser testada no stream efetivamente utilizado pela operação. Se o evento aciona gravação, é necessário verificar montagem do storage, perfil de stream, disponibilidade de pré-condições e resultado no playback. Se aciona operadores, deve-se verificar fila de alarmes, nomenclatura, câmera associada e procedimento de resposta.

Validação visual, test alarm e ajuste fino

Durante a configuração, a função de visual confirmation permite observar quais objetos estão sendo detectados e acompanhar a evolução do tempo de permanência. Contornos indicam os objetos acompanhados e a barra de progresso permite confirmar se a contagem está coerente antes que o perfil seja colocado em produção.

Essa visualização é uma ferramenta de engenharia de configuração, não um modo permanente de operação. Ela pode adicionar latência e carga durante o ajuste e é desativada automaticamente após determinado período. Em PTZ, a visualização só reaparece depois da recalibração associada à mudança de preset.

O Test alarm permite verificar a cadeia posterior sem depender de uma ocorrência real de loitering. Ele deve ser usado para confirmar regras de evento, gravação, VMS e ações conectadas ao perfil. Depois desse teste funcional, ainda é necessário executar testes reais de permanência para validar a lógica temporal e os filtros.

Compatibilidade, AXIS Object Analytics e migração de ciclo de vida

O AXIS Loitering Guard continua disponível para dispositivos compatíveis e permanece associado à família Guard Suite. Na página de produto atual, a Axis informa suporte em câmeras e codificadores compatíveis com AXIS OS 7.10 a 12.11 e disponibiliza a versão 2.3.8 do aplicativo. A combinação entre modelo, versão do sistema operacional e analytics deve ser verificada antes de instalar, atualizar ou migrar.

Para câmeras compatíveis com firmware 10.2 ou superior, a própria Axis recomenda migrar para o AXIS Object Analytics. O cenário Time in area do Object Analytics adiciona classificação de objetos e uma arquitetura de analytics mais atual, mas a migração não deve ser tratada como simples troca de aplicativo: áreas, tempos, filtros, ações e integrações precisam ser revalidados.

A mudança se torna obrigatória quando a estratégia de atualização envolve AXIS OS 13. A Axis anunciou a remoção dos aplicativos Motion Guard, Fence Guard e Loitering Guard nesse track, com substituição funcional pelo Object Analytics. Antes de atualizar câmeras que ainda dependem dessas regras, é necessário inventariar aplicativos instalados, APIs consumidas pelo VMS, configurações existentes e critérios de aceite para a solução substituta.

Limitações e modos de falha

O Loitering Guard não deve ser tratado como classificador semântico equivalente aos analytics atuais baseados em classificação de pessoas e veículos. Sua lógica é orientada ao movimento e ao tempo dentro da área, portanto objetos de fundo que produzam movimento podem exigir filtragem adequada.

O desempenho também pode se degradar quando objetos ficam ocluídos, aparecem muito pequenos, atravessam áreas parcialmente fora do enquadramento ou quando a câmera sofre alterações de foco, posição ou perspectiva. Mudanças físicas na cena precisam ser consideradas como mudança de configuração.

Outro modo de falha ocorre fora do analytics: o evento pode ser corretamente gerado, mas não chegar ao VMS, não iniciar a gravação esperada ou não produzir a ação operacional prevista. Por isso, o teste precisa percorrer toda a cadeia até a resposta final.

Quando aparecem alarmes de objetos fora da área pretendida, a primeira ação não deve ser aumentar filtros indiscriminadamente. É preferível revisar o enquadramento e redesenhar a include area para criar distância de vias, calçadas ou fluxos próximos. Exclude areas são úteis quando o problema está dentro da área necessária, mas não substituem uma área de inclusão mal definida.

Depois de qualquer alteração em filtros, a aplicação precisa recalibrar e os objetos já presentes podem levar algum tempo para serem detectados novamente. Esse comportamento deve ser considerado durante tuning e comissionamento para evitar interpretar o período de recalibração como falha de detecção.

Verificação, comissionamento e critérios de aceite

O comissionamento deve ser executado por perfil e por área. Para cada cenário, é necessário produzir uma permanência conhecida, confirmar a contagem de tempo, verificar o disparo, observar a ação associada e registrar a gravação ou evidência correspondente.

Também devem ser executados testes negativos: passagem rápida, objeto fora da área, pequenos movimentos de fundo e outras condições que não deveriam gerar alarme. O objetivo é verificar simultaneamente sensibilidade e capacidade de rejeitar eventos irrelevantes.

O aceite deve registrar dispositivo, versão do aplicativo, perfil, área, parâmetros, filtros, ação configurada, integração e resultado dos testes. Alterações posteriores de câmera, cena ou software podem exigir recomissionamento.

Documentação e rastreabilidade

Perfis configurados devem ser documentados com nome, finalidade, área monitorada, tempo, filtros, horários e ações. Essa informação permite reconstruir a intenção da regra e evita que ajustes futuros sejam feitos sem conhecer o critério original.

Em ambientes que serão migrados para Object Analytics, a documentação também funciona como baseline para comparação. O novo cenário deve ser aceito pela função que precisa executar, e não pela tentativa de reproduzir cada parâmetro interno do aplicativo antigo.

Considerações de Engenharia

Menos alarmes não significa automaticamente melhor detecção

Filtros excessivos e tempos muito longos podem reduzir falsos positivos ao custo de perder eventos relevantes. O tuning deve buscar aderência ao caso de uso, não apenas diminuir a quantidade de alarmes.

Compatibilidade de hoje não garante ciclo de vida futuro

Uma câmera que executa Loitering Guard no AXIS OS 12 pode exigir migração antes de entrar no track 13. Firmware e analytics precisam ser planejados como uma combinação, principalmente quando o VMS consome eventos ou APIs específicas do aplicativo.

Migração precisa ser revalidada pelo caso de uso

AXIS Object Analytics oferece uma função substituta mais atual, mas a mudança de mecanismo de detecção altera premissas. A validação deve confirmar comportamento, tempo, classes de objeto e integração antes de aposentar a regra anterior.

Serviços que materializam a solução

O posicionamento da câmera, definição de cobertura, integração com VMS e requisitos de gravação podem ser estruturados pelo Projeto de CFTV IP e Videomonitoramento. Quando o evento de permanência participa de uma arquitetura de segurança mais ampla, o Projeto de Segurança Eletrônica Integrada relaciona o analytics a alarmes, procedimentos e demais subsistemas.

A validação de regras, integrações e respostas pode ser executada por Ensaios e Testes Técnicos e Comissionamento de Equipamentos. Em sistemas existentes, mudanças de firmware ou migração para Object Analytics podem justificar recomissionamento seletivo.