BriefCam — Análise de Vídeo, Busca Forense e Inteligência

BriefCam é uma plataforma de video analytics utilizada para transformar vídeo gravado e ao vivo em informação pesquisável, alertas operacionais e dados quantitativos. A plataforma trabalha sobre vídeo proveniente de VMS ou arquivos e organiza suas capacidades em módulos de investigação, resposta em tempo real e inteligência operacional.

O valor do BriefCam aparece quando a quantidade de vídeo supera a capacidade de revisão manual. Em vez de procurar ocorrências assistindo sequencialmente às gravações, a operação passa a consultar objetos, atributos, trajetórias, eventos e padrões extraídos do conteúdo processado.

Na engenharia da solução, BriefCam deve ser tratado como uma camada analítica conectada ao ecossistema de videomonitoramento. Câmeras, VMS, rede, servidores de processamento, GPUs, armazenamento, retenção de metadados, usuários, integrações e critérios de privacidade condicionam desempenho e escala.

Condição observada	Risco ou limitação	Resposta de engenharia
Grande volume de gravações para investigação	Tempo excessivo até localizar pessoas, veículos ou eventos	Estruturar ingestão, processamento, filtros e fluxo de REVIEW
Necessidade de alertas com múltiplos atributos	Regras simples do VMS não representam o evento desejado	Definir classes, atributos, área, tempo e fluxo de RESPOND
Uso de vídeo para indicadores operacionais	Dados ficam restritos à investigação pontual	Modelar métricas, dashboards, retenção e uso de RESEARCH
Múltiplos sites independentes	Visão fragmentada de alertas e indicadores	Avaliar arquitetura multi-site com BriefCam Nexus, Hub e Sites
Analytics sem critérios de retenção e privacidade	Excesso de dados, risco de governança e baixa previsibilidade de storage	Definir ciclo de vida de vídeo, metadata, BI e evidências

REVIEW, RESPOND e RESEARCH

A arquitetura funcional atual do BriefCam é organizada em três módulos principais. REVIEW atende investigação sobre vídeo gravado; RESPOND trabalha com alertas e situational awareness; RESEARCH transforma dados extraídos do vídeo em indicadores, tendências e dashboards.

REVIEW para investigação e busca forense

REVIEW permite pesquisar gravações por classes e atributos de objetos, refinar resultados por velocidade, direção, áreas e outros critérios e organizar casos de investigação. O VIDEO SYNOPSIS® resume visualmente objetos detectados em diferentes momentos, reduzindo o tempo necessário para revisar grandes janelas de vídeo.

A investigação pode combinar múltiplas câmeras, mapas, bookmarks, objetos de interesse e exportação de resultados. O ganho operacional depende da qualidade da ingestão e do metadata disponível; câmeras mal posicionadas, baixa resolução útil ou sincronismo inadequado continuam limitando a investigação mesmo quando a busca é rápida.

RESPOND para alertas em tempo real

RESPOND cria alertas a partir de combinações de classificação, atributos e condições de cena. Os eventos podem apoiar detecção operacional e ser integrados ao VMS, PSIM ou outros mecanismos de notificação conforme a arquitetura disponível.

A regra precisa estar vinculada a uma ação. Sensibilidade elevada sem procedimento de resposta produz excesso de alertas; filtros excessivos podem reduzir ocorrências indevidas e simultaneamente eliminar eventos relevantes. O tuning deve ser validado com cenários positivos e negativos.

RESEARCH para indicadores e inteligência operacional

RESEARCH utiliza os dados analíticos produzidos pelo processamento do vídeo para criar dashboards e análises quantitativas. Fluxos, ocupação, permanência, interações e outros indicadores podem ser acompanhados ao longo do tempo, permitindo utilizar o vídeo também como fonte de informação operacional.

Na versão 2025 R1, a plataforma reforçou o uso de dashboards agregados para retenção de longo prazo, reduzindo consumo de storage e memória em comparação com dados detalhados mantidos indefinidamente. Isso evidencia uma decisão importante de arquitetura: granularidade analítica e horizonte de retenção precisam ser definidos em conjunto.

Arquiteturas Standalone, distribuída e Multi-Site

BriefCam pode operar em uma instalação all-in-one, em arquitetura distribuída por função ou em Multi-Site com BriefCam Nexus. A escolha não é apenas de escala: ela define domínios de falha, fluxo de vídeo, tráfego entre servidores, capacidade de GPU, operação durante perda de conectividade e modelo de administração.

Em um ambiente compacto, banco, web services, processamento, integração VMS, storage e módulos podem coexistir em poucos hosts. Conforme a carga cresce, a documentação técnica recomenda separar componentes como Rendering, RESEARCH, Database, Storage e Processing Servers, permitindo dimensionar cada função pelo seu perfil de CPU, RAM, GPU, I/O e disponibilidade.

Modelo	Organização	Questão de engenharia
All-in-one / Standalone	Vários componentes concentrados no mesmo host	Menor complexidade, porém maior domínio comum de falha e competição por recursos
Distribuído	Serviços, banco, RESEARCH, processamento e storage separados	Permite escalar recursos e disponibilidade por função
Nexus Multi-Site	Sites locais conectados a um Hub central	Preserva processamento local e agrega RESPOND/RESEARCH corporativamente

No BriefCam Nexus, cada Site mantém sua própria instalação e suas fontes de vídeo. O Hub recebe alertas RESPOND e dados agregados de RESEARCH, apresenta o estado dos Sites e permite navegar para REVIEW de cada ambiente. Isso significa que o Hub centraliza visibilidade, mas não substitui a infraestrutura local necessária para obter vídeo, processar regras e conservar dados.

A conectividade Site–Hub deve ser tratada como interface operacional. O guia Multi-Site define keepalive, registro de Site, publicação de alertas e exportação de BI, além de requisitos de NGINX e comunicação entre gateways. Perda de comunicação precisa ser detectável e a recuperação deve verificar se regras, alertas e indicadores voltaram a alimentar a visão corporativa sem lacunas silenciosas.

Time zone também é uma dependência de arquitetura. Em ambientes distribuídos, câmeras e Sites precisam manter referência temporal coerente para que alertas, vídeo original, dashboards e investigação possam ser correlacionados. A documentação do Nexus recomenda manter Site e câmeras no mesmo fuso sempre que possível.

Edições da plataforma e estratégia de implantação

O portfólio atual da BriefCam diferencia edições conforme fonte de vídeo, módulos disponíveis e perfil de uso. PROTECT combina REVIEW, RESPOND e RESEARCH com ingestão por VMS e arquivos; INSIGHTS também trabalha com os três módulos em cenários orientados a VMS; INVESTIGATOR é voltado principalmente à investigação sobre arquivos, em formato individual ou para equipes.

Edição	Ingestão	Módulos	Uso típico
PROTECT	Arquivos e VMS	REVIEW, RESPOND e RESEARCH	Segurança, investigação, alertas e inteligência operacional
INSIGHTS	VMS	REVIEW, RESPOND e RESEARCH	Analytics contínuo sobre infraestrutura de videomonitoramento
INVESTIGATOR	Arquivos	REVIEW	Investigação forense sobre conjuntos de vídeo específicos

A edição não deve ser escolhida apenas pelo nome comercial. O projeto precisa verificar ingestão requerida, quantidade de usuários, módulos necessários, infraestrutura OX5/OX6, integrações e crescimento previsto. Migrar de investigação pontual para analytics contínuo altera substancialmente processamento, storage e operação.

Arquitetura interna, microservices e fluxo de processamento

Internamente, BriefCam utiliza uma arquitetura de microservices orientada a tarefas. Grande parte dos fluxos é assíncrona: solicitações são registradas em banco e filas, e serviços especializados assumem tarefas conforme disponibilidade. Esse desenho permite escalar horizontalmente determinadas funções e, em alguns componentes, substituir uma instância indisponível por outra saudável.

Componente	Função principal	Dependência relevante
Web Services	Web client, Admin e APIs	Banco e storage compartilhado; pode operar atrás de load balancer
VSServer	Agendamento, watchdog, tarefas RESPOND e outbound alerts	Banco, VMS e serviços de processamento
Fetching Service	Obtém trechos de vídeo do VMS	VMS, rede e storage local do BriefCam
Processing / Alert Processing	Decodifica vídeo e executa analytics on-demand ou real-time	CPU/GPU, engine e integração VMS
Filtering Service	Filtra objetos em memória para REVIEW, RESPOND e RESEARCH	CPU e leituras de banco
Rendering Service	Gera VIDEO SYNOPSIS, visual layers, exports e artefatos	Storage, CPU/GPU e dados processados
BI Rule Engine	ETL do metadata para o modelo de RESEARCH	PostgreSQL e camada Qlik

Fluxo on-demand em REVIEW e RESEARCH

Em processamento sob demanda, uma solicitação de vídeo gera tarefas para o intervalo requerido. O Processing Server solicita os segmentos necessários; o Fetching Service obtém o vídeo no VMS e grava os trechos no archive local; a engine decodifica e processa o conteúdo; metadata e artefatos visuais são persistidos para posterior busca, filtragem, synopsis e BI.

Esse fluxo explica por que a performance não depende somente da GPU. Um VMS lento, fetching congestionado, storage com I/O insuficiente ou banco sobrecarregado pode limitar throughput mesmo quando existe capacidade de processamento analítico disponível.

Fluxo real-time em RESPOND

Em RESPOND, a regra é persistida e convertida em uma tarefa de processamento ao vivo. O Alert Processing Server decodifica o stream, a engine extrai objetos e metadata e o Video Processing Gateway organiza os resultados e executa cálculos necessários para correspondência de regras, face matching ou LPR quando aplicável.

Quando a condição é satisfeita, o alerta pode chegar ao Web Client, ser encaminhado ao VMS integrado, disparar um Respond Outbound API ou alimentar outra infraestrutura. Portanto, o aceite de RESPOND precisa testar a cadeia completa — stream, processamento, regra, notificação, sistema receptor e vídeo original.

OX5 e OX6: engines, GPU e processamento Next-Gen

O acervo técnico diferencia a engine Windows-based OX5 e a engine Linux-based OX6. A OX6 introduz uma arquitetura de processamento em containers Linux gerenciados por Kubernetes, com serviços específicos para engine, gateway e visual assets, enquanto componentes Windows continuam participando de integração, administração e determinados fluxos.

No desenho OX6, o Task Management Service distribui tarefas, o VMS Adapter atua como ponte entre plugins/SDKs Windows e os streams RTSP esperados pela engine Linux, e um message broker baseado em MQTT participa da troca de mensagens. NGINX exerce papel de load balancing em componentes da arquitetura.

Esse modelo permite adicionar instâncias de engine e GPUs de maneira mais horizontal, mas aumenta a importância de rede, DNS, portas, storage e orquestração. A documentação de implantação recomenda rede de alta capacidade e SSD em cenários OX6; a necessidade real deve ser confirmada pelo sizing da versão e pelo volume de processamento.

OX5 e OX6 também processam frames de maneira diferente. Por isso, não é tecnicamente correto dimensionar a solução apenas com o FPS configurado na câmera. A engine, o tipo de workload, o número de workers, a resolução e a complexidade da cena determinam quanto vídeo será efetivamente processado e com que latência.

Alta disponibilidade, backup e domínios de falha

O whitepaper de alta disponibilidade da BriefCam utiliza dois padrões: Active-Active, em que múltiplas instâncias trabalham simultaneamente, e Active-Passive, em que uma instância aguarda para assumir em caso de falha. Nem todos os serviços seguem o mesmo modelo.

Web Services podem operar em Active-Active atrás de NGINX. Diversos serviços baseados em fila ou cluster — como Processing, Alert Processing, Fetching, Filtering, Rendering e serviços de matching — podem ganhar capacidade e resiliência com múltiplas instâncias. O VSServer, por outro lado, é documentado em modelo Active-Passive.

Banco de dados, Qlik, storage e licença possuem domínios próprios. O desenho de referência utiliza replicação master-standby para PostgreSQL, arquitetura multi-node para Qlik e redundância do storage fornecida pela própria infraestrutura de armazenamento. Um license server separado evita amarrar licenças aos hosts BriefCam, mas continua sendo um ponto que precisa ser considerado na análise de disponibilidade.

Backup também precisa ser decomposto. O guia administrativo inclui PostgreSQL, ServerData, dados Qlik/RESEARCH, MongoDB em determinados ambientes, arquivos de licença e configurações como NGINX e PostgreSQL. Em sistemas 24×7 ou de alta atividade, o próprio fabricante alerta que backups automáticos podem introduzir timeout de banco, recomendando planejamento de janela ou replicação.

Alta disponibilidade não deve ser declarada apenas porque existem servidores duplicados. O comissionamento precisa testar falha de serviço, host, banco, storage, VMS e conectividade, observando capacidade remanescente, tempo de recuperação, perda de dados e retorno ao estado normal.

Integração com VMS, câmeras e modelo de licenciamento

BriefCam integra-se a diferentes plataformas de VMS por plugins e interfaces específicas. O Brochure 2026 relaciona, entre outras, Milestone, Genetec, Axis, Bosch, Exacq, Hanwha, Network Optix, Pelco e Qognify. A integração utilizada precisa ser compatível com a versão do VMS e com a função necessária: obtenção de vídeo gravado, stream real-time, geolocalização, alertas ou retorno ao vídeo original.

No Administrator Console, a integração é registrada como um diretório VMS com endereço, credenciais e plugin apropriado. O usuário utilizado no VMS precisa possuir acesso às câmeras expostas ao BriefCam. Em integrações como Milestone e Genetec, o acervo documenta parâmetros adicionais de RTSP para definir credenciais de streaming de maneira controlada.

A sincronização com o VMS atualiza nome, timezone e path das câmeras e desabilita fontes removidas. Nomes duplicados podem fazer a sincronização falhar. Substituição de câmera também precisa ser tratada cuidadosamente: manter o mesmo nome no VMS pode ajudar a preservar configuração, mas dados já processados e regras associadas à fonte anterior não devem ser presumidos automaticamente transferíveis para a nova origem.

Ativação de câmeras e canais RESPOND

O modelo de licenciamento documentado no acervo distingue camera activation e RESPOND channels. A ativação registra uma câmera para uso no sistema e consome capacidade licenciada; já os canais RESPOND limitam quantos streams podem ser processados simultaneamente em real time e funcionam como capacidade concorrente.

Essa diferença afeta expansão. Um ambiente pode possuir muitas câmeras ativadas e apenas uma fração delas processada simultaneamente em RESPOND. Portanto, câmera cadastrada, câmera habilitada, fonte processada sob demanda e canal real-time são grandezas diferentes e precisam aparecer separadamente no sizing.

Como termos de licenciamento mudam por edição e release, os números contratados devem ser confirmados na versão efetivamente adquirida. O ponto de engenharia permanente é separar capacidade de fontes cadastradas, processamento concorrente, usuários e infraestrutura física.

Developer tools e integrações de saída

O Brochure 2026 apresenta Unified Open API, Respond Outbound API e Systems Event API. Essas interfaces permitem aprofundar integração com aplicações de terceiros, enviar alertas RESPOND e publicar eventos de sistema, mas precisam de autenticação, rate limiting, versionamento e tratamento de indisponibilidade.

Integração externa deve ser tratada como produto de engenharia: endpoint, timeout, retry, ownership, credenciais, formato de payload, horário, correlação com câmera e comportamento de falha precisam ser documentados e testados.

Classes, atributos e características do vídeo de entrada

O Brochure 2026 relaciona classes de pessoas, veículos de duas rodas, outros veículos, animais e mudanças de iluminação, além de atributos como cor, direção, tamanho, velocidade, área, path, dwell e line crossing. Recursos adicionais incluem appearance similarity, face recognition, LPR, make/model recognition, people counting, crowd counting, proximity e custom classes em engines compatíveis.

A existência de um filtro não garante a mesma qualidade em qualquer câmera. A plataforma precisa receber uma imagem que contenha informação suficiente para a classe ou atributo desejado. Enquadramento, perspectiva, oclusão, densidade, contraste, movimento do fundo e compressão alteram tracking e classificação.

Parâmetro de vídeo	Referência do acervo	Implicação
Resolução	Brochure 2026: CIF até 4K	Deve ser escolhida pelo detalhe necessário, não pelo máximo suportado
Frame rate	Brochure 2026: 8–30 FPS; engines podem amostrar frames de modo diferente	FPS da câmera não equivale diretamente ao FPS efetivamente analisado
Bitrate	Evitar bitrate ilimitado; guideline 2024 cita 2,5–5 Mbps para 1080p como referência geral	Bitrate excessivo aumenta fetching, storage e carga sem ganho proporcional de analytics
Face recognition	Mínimo de 40×40 px no rosto, 20 px entre olhos ou 400 px/m	Cobertura e distância devem ser calculadas para a tarefa biométrica
Frame rate variável	Não recomendado para tracking/counting	Pode produzir movimento aparente irregular e reduzir previsibilidade

O guideline de características de vídeo diferencia ainda câmeras térmicas, infravermelhas, PTZ e overhead. Thermal/IR podem detectar pessoas, porém atributos detalhados e cor sofrem degradação. Em PTZ que se move continuamente, o background não permanece estável e o processamento se torna inadequado; presets que permanecem estáveis por períodos longos são um cenário diferente.

Para overhead e counting, o Administrator Guide possui modos específicos que alteram o comportamento da extração. Isso reforça que a mesma câmera não deve ser marcada genericamente como “compatível”: orientação, função analítica e configuração da fonte precisam ser conhecidas.

Custom classes, face recognition, LPR e outros recursos especializados devem ser validados separadamente. Uma câmera adequada para contagem pode não fornecer pixels suficientes para face matching; uma câmera de visão geral pode rastrear veículos corretamente sem permitir leitura confiável de atributos finos.

Capacidade, throughput, GPU e sinais de sobrecarga

O whitepaper de performance da BriefCam define throughput como horas de vídeo-fonte processadas por hora de processamento (Hs/H). Esse indicador é mais útil do que “número de câmeras” porque incorpora resolução, GPU, complexidade da cena, quantidade de objetos, frame rate e ruído de fundo.

O processamento é dividido em tarefas e workers paralelos. Tarefas mais longas favorecem aprendizado de background, distância, tamanho de objetos e ruído; mais tarefas em paralelo melhoram utilização da GPU. O material técnico utiliza blocos de aproximadamente quatro horas como referência de equilíbrio em OX5, mas o sizing definitivo deve seguir engine, hardware, release e workload reais.

Adicionar GPU pode elevar throughput, mas não resolve gargalos fora da engine. Fetching do VMS, rede, banco, storage e RESEARCH podem saturar antes do processamento visual. O dimensionamento precisa medir o pipeline inteiro.

Sintoma	Possível condição	Verificação
Solicitações on-demand ficam presas	Fila ou fetching saturado	Tempo de fetching, workers, VMS e rede
Gaps em REVIEW ou RESEARCH	Tarefas incompletas ou overload	Logs, tasks, GPU e processamento recorrente
GPU reinicia ou falha repetidamente	Memória insuficiente / workers excessivos	VRAM, resolução e paralelismo
Dashboards RESEARCH lentos	Volume detalhado excessivo em memória	DetailedLoadDays, agregação e intervalo de reload
Fetching de pequenos segmentos excede timeout	VMS, bitrate ou rede sobrecarregados	Bitrate, workers, chunk size e conectividade

RESEARCH merece análise própria porque recarrega objetos processados para atualizar dashboards. Manter muitos dias de dados detalhados pode elevar CPU e RAM e tornar a interface lenta. Dashboards agregados reduzem o volume carregado e permitem reter indicadores históricos por períodos maiores.

Processing schedule também é ferramenta de engenharia. Processamento recorrente pode ser deslocado para períodos de menor uso, preparando dados antes do turno operacional. Em ambientes 24×7, a estratégia precisa evitar competir simultaneamente com investigação on-demand, RESPOND real-time, backup e manutenção.

Identidade, permissões, hardening e proteção de dados

BriefCam possui camadas de permissão para câmeras, módulos e recursos. No guia administrativo 2024 M1, o grupo Everyone recebe por padrão acesso às câmeras até que a política seja refinada. Em um ambiente corporativo, essa condição inicial precisa ser revista para aplicar least privilege por grupo, função e Site.

Permissões de câmera distinguem leitura e escrita: leitura controla visualização da fonte e obtenção do vídeo; escrita permite criar entidades derivadas, como processing requests e sources. Acesso a RESPOND também pode ser concedido por usuário ou grupo. Em Multi-Site, permissões de Hub e Site precisam ser coordenadas — mesmo usuário e grupos equivalentes podem precisar existir em cada Site.

Hardening da plataforma

O whitepaper de hardening recomenda servidores enxutos, remoção de serviços desnecessários, patches atualizados e princípio do menor privilégio. NGINX pode ser utilizado como load balancer e terminação HTTPS; firewall deve liberar apenas portas requeridas; servidores BriefCam devem permanecer em rede privada protegida, evitando exposição desnecessária em DMZ.

Active Directory/LDAP, SAML e outros mecanismos de SSO reduzem contas independentes e permitem aplicar políticas corporativas de identidade. O Brochure 2026 lista LDAP/LDAPS, grupos e SAML. A configuração também deve considerar lockout, tempo de sessão, contas de serviço, API rate limiting e proteção de arquivos de storage.

Antivírus e ferramentas de segurança de endpoint podem ser utilizados, porém o material técnico alerta para impacto potencial de performance. Exclusões, scanning e política de atualização precisam ser validados sem desproteger o host nem comprometer throughput.

Data Protection e dados pessoais derivados do vídeo

BriefCam possui um grupo Data-Manager e funções para localizar, exportar e excluir dados derivados de pessoas e veículos. O mecanismo de exclusão pode remover metadata, artefatos internos, thumbnails, clips, bookmarks e trechos de vídeo original associados ao objeto. Isso precisa ser entendido antes de aplicar rotinas de exclusão em ambientes de investigação.

Em Nexus, Data Protection não é executado no Hub; a operação deve ser realizada nos Sites. Esse comportamento cria uma exigência de governança distribuída: política corporativa pode ser central, mas execução e evidência de exclusão permanecem vinculadas às instâncias que armazenam os dados.

Face recognition e LPR podem ser desabilitados conforme necessidade. A própria documentação ressalta que a disponibilidade técnica dessas funções não determina conformidade jurídica; finalidade, base legal, retenção, acesso e política de uso precisam ser definidos pela organização.

Retenção, manutenção, backup e ciclo de vida operacional

BriefCam executa manutenção automática para evitar crescimento indefinido de banco e storage. Retenção é parametrizada separadamente por módulo e tipo de artefato. Os valores abaixo são referências documentadas no Administrator Guide 2024 M1 e devem ser confirmados e ajustados conforme a versão e a política do projeto.

Dado / módulo	Default documentado	Observação
REVIEW — CaseRetentionDays	30 dias	Casos podem ser marcados para não serem eliminados pela manutenção
VideoArchiveExpirationDays	30 dias	Controla vídeo obtido do VMS e mantido no archive local
RESPOND — LiveRetentionDays	7 dias	Alertas antigos são removidos; bookmarks seguem lógica própria
RESEARCH — BIAssetsRetentionDays	30 dias	Retenção de assets/tabelas intermediárias de BI
RESEARCH — BITaskRetentionDays	3 dias	Metadata e visual assets temporários de tarefas RESEARCH
RESEARCH — DetailedLoadDays	30 dias em instalações atuais do guia	Controla volume detalhado carregado; agregados seguem política distinta

Desabilitar maintenance não é uma estratégia de retenção: o próprio guia alerta que o storage continuará enchendo. Em plataformas de alta atividade, maintenance, VACUUM/REINDEX de PostgreSQL, backup e reload de RESEARCH precisam ser planejados em janelas que não concorram com picos de processamento.

Backup é responsabilidade do ambiente e deve cobrir PostgreSQL, ServerData, Qlik/RESEARCH, bancos auxiliares quando utilizados, licença e arquivos de configuração. Mais importante do que gerar cópias é testar restauração e saber quais componentes precisam ser recompostos para recuperar REVIEW, RESPOND e RESEARCH.

Upgrade também é uma mudança de arquitetura. Novas versões podem alterar engine, serviços, drivers, banco, APIs e comportamento de módulos. Antes da atualização, devem ser registrados versão, integrações, VMS, GPU, banco, regras, classes, watchlists e parâmetros críticos; depois da mudança, a regressão deve cobrir os casos de uso realmente dependentes da plataforma.

Operação contínua exige monitoramento de services, eventos de maintenance, filas, fetching, GPU, storage, banco e dashboards. Sintomas como gaps de processamento, regras sem alertas, câmera indisponível após reconexão do VMS ou RESEARCH desatualizado devem ser tratados como condições observáveis com procedimento de diagnóstico, e não como falhas genéricas de “analytics”.

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

O comissionamento deve ser orientado por casos de uso e pela cadeia técnica que sustenta cada função. Não basta demonstrar que o Web Client abre: é necessário provar ingestão, processamento, filtros, regras, metadata, integração, retenção e recuperação.

Camada	Teste mínimo	Evidência esperada
VMS e câmera	Conexão, sync, timezone, vídeo gravado e live stream	Fonte acessível e correlacionada ao vídeo original
REVIEW	Processamento, filtros, VIDEO SYNOPSIS, case, bookmark e export	Objeto localizado e rastreável ao source
RESPOND	Regra positiva, regra negativa, notificação e outbound/VMS	Alerta correto, no tempo correto, com vídeo correspondente
RESEARCH	Source, dashboard detalhado/agregado e atualização	Indicador reproduzível para período conhecido
Performance	Fetching, workers, GPU, fila e carga simultânea	Throughput compatível com o sizing
HA / recuperação	Falha de serviço/host e restauração	Impacto, tempo de recuperação e perda de dados conhecidos

Em REVIEW, testes precisam combinar filtros simples e compostos, fontes de câmeras diferentes e retorno ao vídeo original. Em RESPOND, o cenário deve provar sensibilidade suficiente sem gerar uma quantidade operacionalmente inviável de falsos positivos. Em RESEARCH, dashboards devem ser confrontados com uma amostra conhecida para verificar se a leitura quantitativa corresponde ao fenômeno observado.

Câmeras especializadas exigem testes próprios. PTZ, overhead, thermal/IR, face recognition, LPR, counting e custom classes não devem ser aceitos por analogia com uma câmera fixa convencional. Cada função precisa de condição de cena, resolução e critério de teste coerentes.

Multi-Site acrescenta teste de perda e retorno do Hub/WAN, estado Connected/Disconnected, centralização de alertas e atualização de RESEARCH. Em arquitetura HA, deve-se provocar indisponibilidade real de componentes relevantes e registrar comportamento dos serviços remanescentes.

O aceite deve registrar hardware e software, fontes ativadas, canais real-time, versões, integrações, regras, grupos, retenção, serviços, throughput observado e limitações conhecidas. Pendências precisam possuir condição objetiva de encerramento.

Documentação, baseline e rastreabilidade

O as built precisa registrar a arquitetura efetivamente implantada: hosts, funções, serviços, GPUs, banco, Qlik, storage, NGINX, Sites, Hub, VMS, plugins, câmeras, licença, redes, portas, certificados e integrações externas. Em ambiente distribuído, a relação serviço–host–dependência é essencial para troubleshooting e failover.

Também devem ser documentados os elementos lógicos: usuários e grupos, permissões de câmera, regras RESPOND, watchlists, custom classes, sources RESEARCH, dashboards, schedules, APIs, parâmetros de retenção e políticas de maintenance. Esses elementos alteram comportamento mesmo quando nenhuma peça física muda.

A baseline precisa vincular cada caso de uso ao conjunto de câmeras e configurações que o sustentam. Isso permite saber, após um upgrade ou substituição de câmera, quais testes devem ser repetidos e quais outputs podem ter mudado.

Logs e evidências de comissionamento devem permanecer associados à versão testada. BriefCam possui múltiplos serviços e bancos; sem rastreabilidade, um problema de VMS, fetching, processing, filtering, BI ou integração pode ser tratado incorretamente como falha genérica da plataforma.

Considerações de Engenharia

Analytics não recupera informação que a câmera nunca registrou

Busca e classificação dependem do conteúdo visual disponível. Resolução insuficiente, oclusão ou enquadramento inadequado não são corrigidos simplesmente pelo processamento posterior.

Metadata e BI também precisam de política de retenção

Reduzir vídeo não significa eliminar crescimento de dados. Objetos, dashboards, artefatos e bancos possuem ciclo próprio e precisam de retenção coerente com uso, privacidade e capacidade.

Multi-site centraliza visibilidade, não substitui autonomia local

O Hub melhora governança e visão corporativa, mas cada Site continua dependendo de infraestrutura local para ingestão e processamento. WAN e Hub não devem se tornar pontos únicos para funções que precisam continuar locais.

Serviços que materializam a solução

A qualidade do analytics começa na arquitetura de vídeo. O Projeto de CFTV IP e Videomonitoramento define câmeras, enquadramento, VMS, rede e armazenamento; o Projeto de Segurança Eletrônica Integrada relaciona analytics, eventos e resposta aos demais subsistemas.

Durante a implantação, Ensaios e Testes Técnicos e Comissionamento de Equipamentos permitem validar buscas, alertas, dashboards, integrações e estados degradados. O Recebimento Técnico consolida evidências e pendências para aceite.