Conhecimento em engenharia
A3A Academy
Análise de risco
TONITRU Risk Assessment 
Como contratar Video Analytics no CFTV: arquitetura edge/servidor, GPU, licenças, estimativa de custos, RFQ, integração VMS, PoC e aceite.
Confira!
Um projeto de monitoramento com Video Analytics define como câmeras, algoritmos, eventos e operadores atuarão conjuntamente para detectar condições de interesse e executar procedimentos de resposta. Além de selecionar tecnologia e calcular GPU, rede, licenças e armazenamento, a engenharia deve estabelecer matriz de eventos por câmera, níveis de prioridade, fluxo de alarmes no VMS, responsabilidades da central, tempos de atendimento e critérios de aceite operacional. A plataforma só entrega a função contratada quando o evento correto chega à pessoa certa, no contexto da gravação, com procedimento e desempenho verificáveis.
Esta abordagem se concentra na especificação comercial e de engenharia de Video Analytics, incluindo arquitetura embarcada, central e híbrida; cálculo de recursos; estrutura do orçamento; matriz de fornecedores; prova de conceito; e condições de recebimento. Conceitos gerais sobre aprendizado de máquina e visão computacional permanecem nas páginas informativas existentes. Aqui, o foco é a decisão de contratação e implantação.
Definir o objeto antes de cotar licença por câmera
Os requisitos de cada caso de uso permitem selecionar analytics sem comprar funções ociosas e formar orçamento comparável.
O termo "analíticos de vídeo" pode designar funções profundamente diferentes. Detecção de movimento, classificação de pessoas, contagem de veículos, cruzamento de linha virtual, permanência indevida, análise de filas e pesquisa retrospectiva utilizam regras e recursos distintos. Um sistema capaz de gerar alarme de entrada em zona não necessariamente indexa atributos para investigar dias de gravação.
O projeto precisa relacionar cada caso de uso ao local, ao objeto de interesse, às condições ambientais e ao comportamento esperado do operador. A especificação deve distinguir funções de alerta em tempo real, pesquisa de evidência gravada e inteligência operacional, pois o custo e a tecnologia podem variar de forma relevante.
É recomendável começar com um catálogo de requisitos e separar obrigatórios, desejáveis e opcionais. Uma contratação que exige todos os recursos disponíveis no catálogo pode consumir orçamento sem resolver o problema prioritário. Ao contrário, uma proposta subdimensionada pode omitir servidores, licenças e integração necessários para a finalidade essencial.
Matriz de escopo por função
| Necessidade | Recurso a contratar | Indicador de aceite |
| Intrusão em área restrita | Detecção por objeto e região | Recall, falsos alarmes e tempo até aviso |
| Permanência indevida | Regra temporal em zona | Detecção por tempo e precisão |
| Gestão de fluxo | Contagem em linha ou área | Erro de contagem por período |
| Busca de ocorrência | Indexação e consulta retrospectiva | Recuperação correta e tempo de busca |
| Apoio ao operador | Eventos integrados ao VMS | Alarme, imagem e procedimento vinculados |
| Gestão por indicadores | Agregação e dashboard | Fonte, fórmula e dados auditáveis |
O contratante não precisa escolher a marca antes de conhecer quais funções realmente geram valor.
Diagnóstico da infraestrutura e viabilidade de imagem
A análise inicia por inventário de câmeras, resolução, FPS, lentes, iluminação, retenção, VMS, rede e servidores. É preciso avaliar se o analítico será executado na câmera, em servidor central ou em ambos. A presença de vídeo utilizável por um operador não garante que o algoritmo consiga distinguir objetos em condições adversas.
O white paper de IA da Axis apresenta fatores que influenciam desempenho: qualidade de imagem, distância de detecção, orientação, condições da cena, configuração e manutenção. Portanto, a solução precisa ser avaliada no ambiente real. Um algoritmo demonstrado com iluminação estável pode gerar desempenho inferior em uma portaria com contraluz, vegetação ou ocupação variável.
É importante estabelecer baseline de incidências e alertas. Se o objetivo é reduzir falsos alarmes, a organização precisa conhecer a situação anterior. Se deseja reduzir tempo de investigação, é necessário medir o processo manual. A engenharia não deve prometer ganho percentual sem dados de referência.
Arquiteturas de processamento e suas consequências comerciais
Edge analytics utiliza recursos embarcados na câmera. Pode gerar alertas localmente e reduzir parte do processamento central, mas limites de hardware, firmware e licenças precisam ser comprovados. Analytics de servidor utiliza CPU/GPU e permite concentrar modelos e gestão; em contrapartida, depende de rede, capacidade, energia, armazenamento e disponibilidade. A arquitetura híbrida distribui etapas conforme requisitos.
| Arquitetura | CAPEX predominante | Custos recorrentes e dependências |
| Borda | Câmeras e aplicativos | Atualização, suporte e reposição por unidade |
| Servidor | GPUs, servidores e licenças | Energia, suporte, hardware e versões |
| Nuvem | Interfaces e conectividade | Assinatura, tráfego, retenção e governança |
| Híbrida | Componentes distribuídos | Integração e manutenção multidisciplinar |
O fornecedor deve especificar exatamente que recurso executa em cada local e qual capacidade é garantida. Licença por câmera não constitui medida suficiente quando o custo efetivo depende de FPS analisado, resolução, quantidade de modelos e concorrência.
Memória de dimensionamento: câmera não é unidade de processamento homogênea
A memória de cálculo deve considerar carga, modelo, processamento, contingência e capacidade real, não apenas limite nominal de canais.
A carga de análise depende de número de streams, imagens por segundo examinadas, resolução e quantidade de inferências por quadro. Uma regra simples de detecção pode demandar recursos diferentes da análise com múltiplos modelos. O dimensionamento deve ser elaborado com parâmetros oficiais do produto e validado por teste quando a arquitetura for relevante.
Considere, didaticamente, 48 câmeras com 20 quadros por segundo. Há 960 quadros por segundo no conjunto, mas isso não significa que o servidor executará 960 inferências completas por segundo: alguns analíticos amostram quadros, compartilham processamento, operam por evento ou usam resoluções internas distintas. O fabricante deve explicar seu modelo de capacidade para a configuração escolhida.
O projeto separa carga normal e pior cenário relevante, aplica reserva justificada e considera failover. Se dois servidores dividem 80 canais, a perda de um pode exigir que o outro assuma funções críticas. Isso deve ser calculado e ensaiado; dois servidores instalados não demonstram, por si, redundância suficiente.
Como interpretar capacidade anunciada no datasheet
Uma plataforma pode anunciar "até 100 câmeras", mas o número depende de resolução, FPS, configuração e licenças. Se a capacidade foi demonstrada com detector simples em 720p e poucos FPS, não se pode presumir que se mantém com 4K, vários modelos e indexação contínua. O termo de referência deve exigir uma memória com cenários, parâmetros e limites.
Em sistemas corporativos, convém prever expansão por fases com espaço de processamento e licenciamento. Não é necessário comprar capacidade ociosa sem critério, mas a arquitetura deve mostrar quanto custará adicionar novos canais e quais componentes precisarão ser substituídos.
Fluxos e metadados: integração com VMS e outras aplicações
O ONVIF Profile M define interfaces para metadados e eventos analíticos; o Profile T trata de vídeo e funções relacionadas. A conformidade não garante que cada produto entregue todos os classificadores existentes, nem que o VMS implemente consulta avançada de todos os atributos. A integração precisa ser verificada por modelo, firmware, release de software e caso de uso.
É necessário identificar se a solução publica evento, metadado estruturado ou ambos. A central precisa conseguir vincular o resultado ao vídeo, confirmar a ocorrência e executar a resposta prevista. Integrar um alerta à lista de notificações não significa ter pesquisa forense retrospectiva.
Quando houver conexão com controle de acesso, intrusão ou automação, os fluxos precisam ser definidos por matriz de causa e efeito, permissões e segurança. Uma detecção probabilística não deve gerar automaticamente ação crítica sem a lógica e a autorização previstas.
Arquitetura funcional de contratação
Esse encadeamento deve ser materializado em projeto e na matriz de fornecimento. A distribuição das funções pode variar conforme solução, mas o teste precisa alcançar a atividade esperada do operador.
CAPEX e OPEX: o que entra na memória de custo
O orçamento deve separar levantamento e projeto, adequações de imagem, hardware, licenças de câmeras e VMS, processamento, rede, storage, integração, testes, treinamento e suporte. Contratar apenas "licença de analytics" pode esconder servidores, atualização de VMS ou capacidade de retenção que não estavam previstos.
O TCO deve considerar horizonte consistente, como cinco anos, e crescimento de canais. Licenças perpétuas podem exigir suporte e atualização; assinaturas possuem recorrência; câmeras embarcadas podem ter recursos incluídos ou cobrados por aplicativo. As propostas devem ser normalizadas para o mesmo conjunto de funções e período.
Exemplo de estrutura de custo
| Componente | Custo de implantação | Custo de operação |
| Projeto e diagnóstico | Levantamento, especificação e PoC | Revisões por mudança |
| Câmeras e óptica | Trocas e adequações necessárias | Limpeza, reposição e ajuste |
| Servidores/GPU | Hardware e implantação | Energia e manutenção |
| Licenças | Aquisição/ativação inicial | Renovação e atualização |
| Integração VMS | Conectores, API e configuração | Suporte e regressão |
| Segurança e governança | Implantação de controles | Monitoramento e auditoria |
| Treinamento e aceite | SAT e capacitação | Reciclagem de operadores |
Uma proposta com menor preço inicial pode ter TCO maior por requerer serviço customizado, atualização cara ou manutenção de hardware especializado.
Metodologia de prova de conceito
A PoC deve definir eventos reais e gabarito independente, incluindo cenas positivas e negativas em períodos representativos. Métricas de precision e recall ajudam a distinguir alarmes corretos de eventos não detectados. Em um teste com 100 ocorrências reais, uma solução que encontra 85 possui recall de 85%; se emite 110 alarmes, dos quais 85 corretos, a precision é cerca de 77,3%. São números didáticos, não indicativos de fabricante.
O contrato deve estabelecer quais classes e condições exigem desempenho mínimo. Uma câmera de perímetro pode operar satisfatoriamente de dia e ter falhas à noite, enquanto uma área interna apresenta estabilidade maior. Uma média global pode mascarar pontos críticos. O relatório deve apresentar resultados por tipologia e registrar limitações de generalização.
Matriz resumida de ensaio
| Ensaio | Condição | Evidência |
| Detecção de evento | Gabarito por cenário | Verdadeiro/falso positivo e negativo |
| Integração | Alarme chega ao VMS | Registro e gravação associados |
| Desempenho | Carga contratada de canais | Throughput, filas e recursos |
| Disponibilidade | Falha prevista e restauração | Cronologia e resultado |
| Segurança | Papéis e permissões | Acesso autorizado e negado |
| Regressão | Atualização ou mudança de versão | Funções mantidas |
| Operação | Usuário executa processo | Procedimento e evidência |
A PoC reduz risco antes do investimento principal, enquanto o SAT demonstra o comportamento do sistema efetivamente instalado.
Comparação de fornecedores e matriz de equivalência
A RFQ deve exigir descrição funcional, versões, arquitetura, BOM, licenças, limites de FPS e resolução, integrações, prazo de suporte, garantias, custo e teste de aceitação. Não é suficiente afirmar "possui inteligência artificial avançada". A equivalência entre plataformas deve ser demonstrada por funções e desempenho, evitando comparar soluções que só compartilham nome comercial.
O material BriefCam 2026 disponível no KB distingue Review para investigação, Respond para alerta e Research para análise operacional. Essa separação é exemplo útil de categorias de necessidade; não obriga a contratação dessa marca e não constitui garantia de que concorrentes ofereçam módulos idênticos. A matriz deve ser construída por caso de uso e resultado.
Governança, privacidade e operação após a entrega
Analíticos podem processar dados que identificam pessoas ou permitem inferências sobre movimentação. O projeto deve avaliar finalidades, bases legais, necessidade, retenção, perfis de acesso e segurança segundo a LGPD. Recursos biométricos exigem avaliação específica, distinta da mera detecção de pessoas e veículos.
A entrega deve incluir configurações, licenças, relatórios, parâmetros de regras, matriz de câmeras, versões, As Built e plano de manutenção. Quando a iluminação, lente ou posicionamento da câmera muda, a função analítica pode necessitar nova calibração e teste. Um sistema aceito no primeiro dia não permanece automaticamente conforme sem gestão de mudanças.
Contratação de engenharia especializada
Um estudo independente pode iniciar com diagnóstico, programa de necessidades e orçamento preliminar, seguindo para projeto executivo, RFQ, PoC e comissionamento. Esse trabalho evita adquirir recursos incompatíveis, superdimensionados ou desnecessários. A A3A Engenharia pode atuar na especificação, comparação técnica, gestão de interfaces e recebimento, conforme objeto contratado.
Estudo de viabilidade: quando o analytics se paga
A avaliação financeira deve partir de uma linha de base operacional. Se o problema é o excesso de alarmes, registre quantidade de eventos por hora, tempo de triagem, fração confirmada e ocorrências não detectadas. Se o objetivo é localizar fatos no histórico, meça tempo de busca e qualidade dos resultados. Se a necessidade é acompanhar ocupação, defina erro de contagem e periodicidade de consulta. Sem esses indicadores, a promessa de economia não terá referência verificável.
Considere uma central que recebe 240 alertas diários e gasta em média 25 segundos para avaliar cada um. O trabalho totaliza 6.000 segundos, cerca de 100 minutos por dia. Se, após PoC, o sistema reduzir a carga para 150 alertas sem prejudicar detecção de ocorrências relevantes, seriam aproximadamente 37,5 minutos diários de triagem potencialmente liberados. Isso é capacidade operacional, não redução automática de custo de pessoal; o benefício financeiro depende de uma despesa real evitada ou de outro ganho monetizável documentado.
O estudo também deve considerar custo de implantação, atualização, licença, servidores, operação assistida e manutenção. O documento Omdia 2024 sobre ROI em analytics, encomendado pela BriefCam, é útil para identificar categorias de retorno, mas não garante prazo de payback de determinado projeto. A evidência válida para contratação precisa ser obtida da operação do próprio empreendimento ou de premissas claramente justificadas.
Matriz de benefícios e efeitos mensuráveis
| Benefício pretendido | Indicador antes e depois | Ressalva |
|---|---|---|
| Menos alarmes indevidos | Alertas falsos por turno | Confirmar que recall não caiu |
| Investigação mais rápida | Minutos para localizar e exportar | Considerar validação de candidatos |
| Melhor controle de áreas | Ocorrências detectadas por cenário | Depende da amostra e iluminação |
| Informação gerencial | Erro da contagem e disponibilidade | Não confundir número com decisão |
| Otimização de operadores | Horas efetivas liberadas | Economia só quando despesa evitada |
| Continuidade de serviço | Indisponibilidade por função | Medir cadeia, não só servidor |
O parecer econômico deve explicitar quais benefícios são qualitativos, quais foram medidos e quais ainda dependem de confirmação. Uma estimativa preliminar de ROI precisa indicar incerteza e sensibilidade aos cenários de adoção.
O que deve entrar no orçamento paramétrico
Antes de solicitar preços firmes, o contratante pode preparar orçamento de ordem de grandeza com base na quantidade de câmeras elegíveis, processamento previsto, alternativas de arquitetura e escopo de serviços. Esse orçamento não deve fixar preços sem cotação; serve para organizar componentes e testar viabilidade econômica. A base do quantitativo deve ter origem rastreável, preferencialmente plantas e inventário.
Os componentes devem ser agrupados em investimento de equipamentos, software e implantação, mais operação e manutenção ao longo do tempo. Se a instituição pretende atender a novos sites, convém separar crescimento por unidade e necessidade de centralização. Licenciamento federado, conexão VPN, hospedagem, servidor central e retenção podem influenciar fortemente o custo final.
Os custos de engenharia também precisam aparecer: caracterização, programa de requisitos, cálculo, RFQ, matriz de conformidade, acompanhamento de integração, FAT, SAT e Data Book. O trabalho consultivo não é parte gratuita da licença quando representa atividade independente de especificação e responsabilidade técnica.
Dimensionamento em cenário corporativo de 80 câmeras
Considere um empreendimento hipotético com 80 câmeras IP, sendo 30 em perímetro, 25 em circulação, 15 em áreas de acesso e dez em setores de estoque. A organização deseja detecção perimetral em tempo real, contagem em acessos e pesquisa retrospectiva em um subconjunto. A arquitetura não precisa necessariamente executar todos os modelos em todos os canais.
A engenharia agrupa câmeras por função e condição ambiental. As de perímetro precisam de teste noturno e de alarmes produzidos por vegetação; as de acesso precisam de avaliação de oclusões; as de estoque dependem de horários e áreas restritas. O dimensionamento do servidor considera quais canais serão analisados ao mesmo tempo e em que perfis de resolução/FPS. A licitação ou RFQ discrimina quantidade por função e reserva de expansão.
A comparação entre embarcado e central deve contabilizar se as câmeras existentes já possuem analytics, se as licenças do VMS são suficientes e se há infraestrutura de GPU reutilizável. Um orçamento aparentemente menor por licença pode demandar troca de storage, upgrade de rede ou novo servidor. A avaliação de TCO revela esse efeito.
Exemplo de alocação de recursos por grupo
| Grupo | Câmeras | Análise solicitada | Questão de dimensionamento |
|---|---|---|---|
| Perímetro | 30 | Intrusão por pessoa/veículo | Simultaneidade e clima |
| Circulação | 25 | Eventos em zonas definidas | Regras por horário |
| Portarias | 15 | Contagem e alarmes de acesso | Precisão em pico |
| Estoque | 10 | Presença em área restrita | Oclusão e iluminação |
| Total | 80 | Funções diferenciadas | Licenças e processamento por uso |
O quadro ilustra a metodologia, não oferece benchmark de servidor ou preço de mercado. Para dimensionamento definitivo, é preciso documentação de fabricante e ensaio da configuração pretendida.
Análise de carga e cenários de falha
Mesmo que a GPU suporte a carga normal, o serviço pode perder capacidade durante atualização, falha de rede ou processamento retrospectivo simultâneo. O projeto deve demonstrar quais funções são mantidas em contingência e qual é o comportamento permitido quando uma fila cresce. Uma plataforma que simplesmente deixa de analisar streams sem registrar falha pode ser inadequada para função crítica.
Se existem dois servidores em alta disponibilidade, a equipe precisa verificar se o remanescente possui processamento suficiente para os canais prioritários. A solução pode reduzir temporariamente funções menos críticas, mas isso deve estar descrito no contrato e testado. A reserva de recursos só é útil se estiver demonstrada e não for consumida por cargas inesperadas.
Também devem ser verificados throughput da rede, taxas de gravação, consumo de memória, ocupação de filas e disponibilidade dos serviços de tempo. A integração de eventos perde confiabilidade quando os timestamps da câmera, motor analítico e VMS divergem.
Comparação técnica entre duas propostas
Suponha duas ofertas comerciais para o mesmo objeto. A proposta A utiliza analytics embarcado na maioria das câmeras e prevê poucos servidores adicionais. A proposta B oferece plataforma central e processamento em GPU para todo o parque. Não é possível concluir qual é melhor comparando custo de câmera com preço de licença. É necessário calcular custo de equipamentos, servidores, rede, licenças, suporte, atualização, consumo elétrico e futuras expansões.
A análise deve incluir também risco de integração. Uma câmera com função embarcada que só envia alarme simples ao VMS pode não atender requisito de pesquisa por atributos. Uma plataforma central pode ter funcionalidades mais amplas, mas falhar no desempenho de tempo real se o link ou a GPU forem insuficientes. A matriz identifica funções obrigatórias primeiro, compara arquitetura e custo total depois.
| Critério de comparação | Proposta A | Proposta B |
|---|---|---|
| Forma de processamento | Embarcado | Servidor |
| Custo de câmera | Pode ser superior | Depende dos modelos |
| Servidores | Menor demanda em alguns casos | Infraestrutura especializada |
| Eventos no VMS | Depende de integração | Depende de conector e licença |
| Pesquisa histórica | Exige verificação específica | Exige capacidade de indexação |
| Contingência | Distribuída por dispositivo | Depende de redundância central |
| Atualização | Firmware e aplicativos por câmera | Plataforma e modelos centralizados |
O quadro é qualitativo, não atribui nota comercial real. A proposta vencedora será aquela que demonstra os requisitos pelo custo e risco aceitáveis para o empreendimento.
Termo de referência, matriz de fornecimento e RFQ
O instrumento de contratação deve apresentar claramente o objeto: funcionalidades, quantidade de canais por caso de uso, infraestrutura disponível, interfaces, versões de software, licenciamento, desempenho, testes, documentação e suporte. Termos vagos como “IA avançada” ou “plataforma completa” são insuficientes para formar preço comparável.
Cada item da matriz de fornecimento precisa identificar responsabilidade e comprovação. Quando houver produto de referência, a comparação de equivalentes deve ocorrer por função, capacidade e documentação, e não por preço ou nomenclatura. É recomendável solicitar modelo, versão, licenças, hardware recomendado, limites de processamento e métodos de integração.
A análise de propostas precisa evitar aceitar declaração comercial de desempenho sem ensaio em ambiente representativo para os requisitos mais críticos. O julgamento técnico pode indicar conformidade, ressalvas, não atendimento e necessidade de diligência, documentando os fatos que sustentam cada classificação.
Aceitação técnica e indicadores de pós-implantação
O SAT deve comprovar que eventos chegam ao VMS, são registrados e permitem resposta de operador, conforme os requisitos. O ensaio testa falsas detecções e eventos não recuperados, além de verificar atraso, comportamento durante falha e restauração. A presença de uma lista de alarmes na interface não comprova sua validade operacional.
Após o aceite, a operação precisa monitorar mudanças da cena, falhas de câmera, atualização de firmware e alterações nas regras. Os indicadores podem incluir percentual de canais operacionais, qualidade dos alertas, tempo médio de resposta, uso efetivo da ferramenta e incidentes não detectados, com metodologia compatível. A organização deve atribuir responsáveis e periodicidade de revisão.
Um Data Book completo apresenta versões, licenças, topologia, regras por câmera, configuração, resultados de ensaio, pendências, limitações e procedimentos de recuperação. Essa documentação permite repetir testes após atualização e verificar que a plataforma mantém a função originalmente contratada.
Engenharia consultiva como instrumento de redução de risco
A contratação de projeto e revisão técnica independente é especialmente pertinente quando há múltiplos fornecedores, VMS legado, alto investimento em hardware de IA, integração com controle de acesso ou exigência de disponibilidade. O diagnóstico ajuda a definir alternativas antes de o fabricante direcionar o orçamento exclusivamente para sua arquitetura preferida.
A A3A Engenharia pode elaborar requisitos, memória de dimensionamento, matriz de concorrência e plano de PoC, além de acompanhar a implantação e o recebimento. O resultado esperado é contratar desempenho operacional comprovado, com custos e responsabilidades definidos, sem confundir recursos de catálogo com capacidade entregue.
Plano de implantação faseada e governança de resultados
Uma implantação corporativa pode começar por um piloto em uma área com casos de uso claramente definidos, seguido da expansão por tipologias. O projeto estabelece o que será medido em cada fase e quais resultados permitem avançar. Não se deve licenciar todo o parque apenas porque a primeira demonstração apresentou poucos falsos alarmes em uma câmera de teste.
O piloto identifica requisitos de câmera, processamento e operação. A fase seguinte verifica diferentes condições de iluminação, densidade de pessoas e tipos de ocorrência. A expansão adiciona infraestrutura, licenças e treinamento, com baseline de parâmetros por câmera. Se a operação modifica regras ou desloca dispositivos, as funções afetadas devem ser reensaiadas conforme matriz de mudanças.
Critérios de passagem entre fases
| Fase | Entrega de engenharia | Gate de aprovação |
|---|---|---|
| Diagnóstico | Inventário e casos de uso | Demanda e viabilidade caracterizadas |
| Piloto | PoC em cenas representativas | Performance e integração demonstradas |
| Projeto executivo | Memória, BOM e interfaces | Escopo e TCO aprovados |
| Implantação | Configurações, licenças e infraestrutura | Inspeções por grupo de canais |
| Comissionamento | Testes de carga, falhas e operação | Não conformidades impeditivas sanadas |
| Operação assistida | Treinamento e indicadores iniciais | Função incorporada aos processos |
Os gatilhos devem ser contratuais e mensuráveis. Uma métrica de taxa de acerto pode ser necessária, mas também importa que o VMS receba o evento, que o operador consiga agir e que o fornecedor entregue mecanismos de suporte. A tecnologia não deve ser considerada operacional apenas por produzir bounding boxes ou valores de confiança.
Responsabilidade técnica na integração entre fornecedores
Em contratação com vários lotes, a empresa de câmeras pode responder pela captura, o fabricante do analytics pelo processamento e a equipe de TI pelos fluxos de rede. O contratante precisa indicar quem é responsável pela cadeia funcional integrada. Caso contrário, uma falha em eventos pode ser atribuída sucessivamente ao vídeo, servidor, rede e VMS, sem solução verificável.
A matriz RACI pode estabelecer responsável pela execução, aprovador técnico, especialistas consultados e áreas informadas em cada entrega. Não é necessário criar burocracia excessiva: o objetivo é evitar interfaces sem proprietário e permitir que o plano de comissionamento cobre resultados completos. O contrato deve definir suporte para mudanças de firmware, APIs e licenças, inclusive durante o período de garantia.
A engenharia consultiva acompanha esses pontos com pareceres e relatórios de conformidade. O aceite deve documentar o que está plenamente atendido, o que requer correção e o que constitui funcionalidade adicional fora do objeto. Esse rigor reduz disputas, aditivos e investimento em recursos não essenciais.
Antes do aceite final, o contratante deve comparar a matriz original de requisitos com as configurações efetivamente implantadas. Cada função deve estar associada à câmera, servidor, licença, versão, regra e condição de teste. Quando algum requisito estiver atendido apenas parcialmente, o relatório precisa distinguir limitação de imagem, de algoritmo, de integração e de operação. Essa rastreabilidade ajuda a atribuir correções ao fornecedor adequado e permite avaliar futuras expansões sem repetir todo o processo de seleção. A comprovação do funcionamento do analytics deve permanecer separada da comprovação da capacidade de resposta da central, embora ambas façam parte do resultado operacional esperado.
Arquitetura operacional do projeto de monitoramento com Video Analytics
Um projeto de monitoramento não termina na definição de algoritmos e servidores. É necessário especificar como os eventos passam da câmera para a central e se transformam em providências: exibição ao operador, prioridade, confirmação, registro, escalonamento e encerramento. Sem essa cadeia, a instalação pode gerar milhares de alarmes que ninguém utiliza de forma consistente.
O primeiro documento operacional é a matriz de causa e efeito ou matriz de eventos e respostas. Para cada TAG de câmera e região, são registrados o evento, sua janela de funcionamento, severidade, condições de supressão, regra de apresentação no VMS, responsável pela triagem e procedimento. As ações automáticas devem obedecer a controles apropriados, sobretudo se envolverem acesso físico ou processos críticos.
| Evento | Prioridade de projeto | Tratamento previsto | Evidência para aceite |
|---|---|---|---|
| Intrusão em área de risco | Conforme criticidade | Alarme destacado, confirmação e escalonamento | Notificação vinculada ao vídeo |
| Movimento em área comum | Baixa ou informativa, conforme contexto | Registro ou filtro de triagem | Regras e supressão validadas |
| Permanência fora do horário | Condicional ao calendário | Aviso ao operador e verificação | Teste nos horários pertinentes |
| Contagem de fluxo | Indicador, não necessariamente alarme | Consolidação em relatório | Comparação com contagem de referência |
| Falha de câmera ou analytics | Falha técnica relevante | Abertura de chamado ou procedimento de contingência | Registro e recuperação observados |
A severidade não deve ser fixa para todas as organizações. Um evento aparentemente simples pode ser crítico em uma área sensível, enquanto outras instalações utilizam a mesma regra apenas para estatística.
Dimensionamento da equipe e prevenção da fadiga de alarmes
A capacidade de monitoramento envolve pessoas, não apenas GPU e vídeo. O projeto precisa estimar quantos alarmes relevantes poderão chegar por turno, qual duração média de triagem e como o operador continuará acompanhando a vigilância em paralelo. Uma arquitetura que identifica bem objetos, mas sobrecarrega a equipe, não atende ao objetivo operacional.
Para uma análise preliminar, suponha que o projeto estime 180 alertas por dia e tempo médio de confirmação de 40 segundos. A carga teórica de triagem é de 120 minutos por dia, sem incluir chamados, documentação ou picos. A distribuição horária pode ser mais importante que essa média; cinquenta alarmes concentrados em poucos minutos podem exigir regras de priorização, agregação ou reforço do procedimento de atendimento.
Reduzir alarmes sem critério também apresenta risco: aumentar demais a sensibilidade ao filtro pode excluir ocorrências verdadeiras. O ajuste deve confrontar precision, recall e o impacto da perda de eventos críticos. É recomendável testar horários e condições diferentes e registrar o compromisso entre carga operacional e confiabilidade.
Disponibilidade de ponta a ponta e monitoramento da própria plataforma
A existência de vídeo no VMS não prova que o motor analítico está funcionando. O desenho precisa monitorar perda de câmera, falha de processamento, atraso de eventos, interrupção de conectores, problemas de horário e impossibilidade de apresentação do alerta ao operador. Essas condições podem exigir alarmes técnicos separados dos alarmes de segurança.
A matriz de comissionamento deve prever testes de falha autorizados, como parada controlada do serviço analítico ou indisponibilidade de conexão, verificando a reação da central e o registro da condição. O tempo máximo de detecção, recuperação e comunicação deve ser definido por criticidade. Não há um SLA numérico único apropriado para todos os sistemas.
Entregáveis específicos do projeto de monitoramento
Além dos diagramas físicos e da memória de hardware, o projeto deve fornecer planta de cobertura com áreas analíticas, lista de câmeras e regras, matriz de eventos e respostas, interface VMS, perfis de operadores, requisitos de rede e energia, plano de contingência e procedimento FAT/SAT. O Data Book precisa conservar configurações por câmera e resultados dos testes, para que a equipe consiga identificar alterações e manter a baseline.
Um ensaio integrado deve iniciar com o evento na cena, confirmar detecção, registro, apresentação na central, providência do operador e encerramento. A validação por fornecedor deve abranger tanto métricas algorítmicas quanto a entrega do processo completo. Se a organização contratar apenas parte da cadeia, as interfaces e as responsabilidades restantes devem estar expressas, sem assumir que um componente já entregue garante o resultado global.
Esse enquadramento posiciona o serviço de engenharia como projeto de monitoramento orientado por desempenho, diferenciando-o de uma venda isolada de licenças de Video Analytics ou de um artigo introdutório sobre inteligência artificial em vídeo.
Considerações finais
A contratação de Video Analytics deve demonstrar compatibilidade entre o evento desejado, a imagem disponível, a arquitetura computacional e a integração operacional. Licenças, câmeras e servidores são meios para alcançar essa função, não o critério final de valor.
O projeto de engenharia transforma uma oferta genérica de IA em orçamento, requisitos, ensaios e responsabilidades verificáveis.
Os recursos contratados devem ser demonstrados em teste integrado e documentação de recebimento.
Referências técnicas
[1] AXIS COMMUNICATIONS. AI in Video Analytics: Considerations for analytics based on machine learning and deep learning. White paper, 2021. Acervo A3A Engenharia. Disponível em: https://www.axis.com/.
[2] ONVIF. Profile M: Metadata and Events for Analytics Applications. Disponível em: https://www.onvif.org/profiles/profile-m/.
[3] ONVIF. Profile T: Advanced Video Streaming. Disponível em: https://www.onvif.org/profiles/profile-t/.
[4] BRIEFCAM. BriefCam Video Analytics Software. Brochure 2026, módulos Review, Respond e Research. Acervo técnico A3A Engenharia. Disponível em: https://www.briefcam.com/.
[5] BRASIL. Lei nº 13.709/2018. Lei Geral de Proteção de Dados Pessoais. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm.
Perguntas frequentes
Por casos de uso, carga computacional, licenças, câmeras, integração, serviços, TCO e critérios de aceite.
Onde o processamento ocorre e como são distribuídos custos, latência, capacidade e dependência de rede.
Não necessariamente. É preciso verificar limites de hardware, algoritmos, integração, gravação e suporte.
Com parâmetros de streams, resolução, FPS analisado, modelos, GPU, consultas e cenários de falha.
Não automaticamente. Pesquisa retrospectiva requer indexação e interfaces específicas.
Define interfaces relevantes, mas não garante todos os recursos nem homologação entre quaisquer produtos.
Precision mede proporção de alarmes corretos; recall mede proporção de eventos reais identificados.
Pela matriz de requisitos, PoC, integração, limitações por versão, licenças e custo total.
Por caso de uso, criticidade, gabarito e ensaios em condições representativas.
Com geometria e imagem adequadas, configuração de regras, modelo compatível e teste contínuo.
Ensaios de eventos, integração, carga, segurança, falhas, exportação e documentação final.
Definir requisitos, alternativas, orçamento, comparação de propostas e validação técnica independente.
