Como planejar a arquitetura de um sistema de CFTV/VSS conforme a ABNT NBR IEC 62676: requisitos operacionais, arquitetura funcional, rede IP, desempenho, redundância, storage, integrações, documentação e critérios de aceite.
Confira!
O planejamento da arquitetura de um sistema de CFTV não deve começar pela escolha de câmeras, servidores ou software. A lógica correta é partir do requisito operacional, definir as funções que o sistema precisa cumprir, estabelecer desempenho, disponibilidade, integridade e condições ambientais e, somente depois, materializar essas exigências em uma arquitetura lógica e física. É essa mudança de raciocínio que torna a série ABNT NBR IEC 62676 especialmente relevante para projetos de videomonitoramento.
A ABNT NBR IEC 62676-1-1:2019 trata o sistema de videomonitoramento, ou VSS (Video Surveillance System), como um conjunto de unidades funcionais e relações entre funções, e não como uma lista de dispositivos. A norma organiza o VSS em ambiente de vídeo, gerenciamento do sistema e segurança do sistema. Já a ABNT NBR IEC 62676-1-2:2019 aprofunda o desempenho da transmissão de vídeo e o projeto da rede IP, incluindo sincronismo de tempo, latência, jitter, perda de pacotes, capacidade, redundância e monitoramento das interconexões.
Na prática, essa abordagem permite transformar uma necessidade de segurança em requisitos verificáveis: o que deve ser observado, como a imagem será capturada, transmitida, armazenada, analisada e apresentada, quem poderá acessar cada função, como falhas serão detectadas, quais registros devem existir e qual desempenho mínimo a rede precisa sustentar. O projeto deixa de ser uma composição de produtos e passa a ser uma engenharia de requisitos, funções, interfaces e desempenho.
A edição internacional IEC 62676-4:2025 complementa esse raciocínio ao tratar de planejamento, projeto, instalação, testes, comissionamento e manutenção do VSS. Como a adoção brasileira da série possui sua própria edição e escopo, este artigo distingue claramente os requisitos das ABNT NBR IEC 62676-1-1 e 1-2:2019 das diretrizes internacionais mais recentes da Parte 4.
O que a ABNT NBR IEC 62676 realmente organiza no planejamento de CFTV
Um dos problemas do texto antigo era atribuir à Parte 1-1 funções que ela própria declara não cobrir. A ABNT NBR IEC 62676-1-1 estabelece requisitos funcionais e de desempenho a serem acordados no requisito operacional, mas não pretende, isoladamente, substituir uma metodologia completa de projeto, instalação, ensaio, operação ou manutenção. Para o projetista, isso não reduz sua importância; ao contrário, define a base de requisitos que o projeto precisa materializar.
A série deve ser lida por função. No planejamento de arquitetura, cada parte responde a uma pergunta distinta.
| Documento | Pergunta de engenharia que ajuda a responder | Aplicação no projeto |
| ABNT NBR IEC 62676-1-1:2019 | Quais funções, requisitos de segurança, integridade, gerenciamento e documentação o VSS precisa cumprir? | OR, arquitetura funcional, requisitos do VMS, armazenamento, níveis de acesso, alarmes, logs, integridade e ambiente |
| ABNT NBR IEC 62676-1-2:2019 | Que desempenho a transmissão de vídeo e a rede IP precisam sustentar? | topologia, capacidade, latência, jitter, perda, redundância, multicast, sincronismo e monitoramento |
| Série IEC 62676-2 | Como estruturar protocolos e interoperabilidade de transmissão de vídeo? | interfaces de transmissão, controle, descoberta, eventos e integração entre dispositivos |
| Série IEC 62676-3 | Como tratar interfaces de vídeo analógicas e digitais? | compatibilidade e requisitos de interface quando aplicáveis |
| IEC 62676-4:2025 | Como planejar, projetar, instalar, testar, comissionar e manter o VSS? | metodologia de aplicação, verificação e ciclo de entrega |
O ponto central é que conformidade não significa copiar uma lista de equipamentos da norma. A própria Parte 1-1 evita definir dispositivos individuais porque a tecnologia evolui rapidamente. O projeto deve traduzir os requisitos normativos em uma arquitetura que permaneça tecnicamente válida mesmo quando modelos e fabricantes mudem.
Essa leitura também ajuda a evitar especificações excessivamente proprietárias. Se o documento técnico define apenas modelos, mas não registra objetivos, funções, desempenho, interfaces e critérios de aceite, a solução pode até funcionar na implantação inicial, porém se torna difícil de comparar, fiscalizar, expandir ou substituir.
Do risco ao requisito operacional: onde a arquitetura realmente começa
Uma arquitetura de CFTV bem definida transforma requisitos operacionais, desempenho, cobertura, rede, gravação e integrações em documentos verificáveis antes da contratação.
Conheça o serviço de Projeto de CFTV IP e Videomonitoramento
A ABNT NBR IEC 62676 utiliza o conceito de OR — Operational Requirement, ou requisito operacional — como referência para acordar o desempenho e as funcionalidades do VSS. Em engenharia, isso significa que o projeto precisa registrar o problema antes de desenhar a solução.
O requisito operacional deve consolidar, em linguagem verificável, pelo menos a finalidade do sistema, os ambientes supervisionados, eventos relevantes, forma de resposta, criticidade, retenção de evidências, usuários, integrações e restrições de operação. A profundidade varia conforme o porte e o risco, mas a lógica não muda.
Um bom OR evita perguntas tardias. Em vez de descobrir durante a implantação que determinada câmera deveria permitir identificação de uma pessoa, que uma ocorrência precisa ser preservada por prazo específico ou que o operador necessita receber eventos priorizados, essas condições são transformadas em requisitos ainda na fase de planejamento.
Requisitos operacionais precisam ser mensuráveis
Expressões como “imagem de boa qualidade”, “rede de alta velocidade”, “sistema redundante” ou “integração completa” não são critérios de engenharia. O projeto precisa traduzir essas expectativas em parâmetros mensuráveis ou em comportamentos verificáveis.
| Necessidade operacional | Formulação fraca | Formulação de projeto verificável |
| monitorar acesso | câmera de alta resolução | definir cena, objetivo de vigilância, iluminação, área de interesse e qualidade necessária para a tarefa |
| operação remota | acesso remoto ao VMS | definir usuários, níveis de privilégio, funções permitidas, autenticação, auditoria e desempenho esperado |
| gravação confiável | storage suficiente | definir canais, bitrate de referência, retenção, simultaneidade, margem, comportamento em falha e exportação |
| continuidade | sistema redundante | identificar funções críticas, pontos únicos de falha, estratégia de failover e critérios de recuperação |
| integração | integrar ao controle de acesso | definir eventos, origem, destino, dados trocados, prioridade, direitos de acesso e comportamento de contingência |
A arquitetura passa a ser consequência desses requisitos. Esse princípio é especialmente importante em projetos públicos, industriais e de missão crítica, nos quais a documentação precisa permitir comparação objetiva entre propostas e posterior fiscalização do fornecimento.
Arquitetura funcional: projetar funções antes de projetar equipamentos
A Seção 4 da ABNT NBR IEC 62676-1-1 apresenta uma ideia particularmente poderosa: o VSS deve ser entendido como blocos funcionais. A norma não assume que cada função corresponde a um dispositivo específico. Uma câmera IP, por exemplo, pode capturar imagem, realizar análise, armazenar localmente e transmitir dados; um servidor pode concentrar gravação, análise, gerenciamento e apresentação.
A decomposição funcional apresentada pela norma pode ser traduzida para projeto da seguinte forma.
| Domínio funcional | Funções principais | Exemplos de materialização no projeto |
| Ambiente de vídeo | captura de imagem | câmeras, sensores de imagem, ótica, iluminação associada |
| Ambiente de vídeo | interconexões | Ethernet, fibra, enlaces, switches, roteamento, protocolos de transporte |
| Ambiente de vídeo | manipulação de imagem | análise, gravação, reprodução, exportação, apresentação |
| Gerenciamento do sistema | gerenciamento de dados | VMS, bases de dados, metadados, retenção, índices |
| Gerenciamento do sistema | gerenciamento de atividades | eventos, alarmes, filas, prioridade, ações do operador |
| Gerenciamento do sistema | interfaces com outros sistemas | controle de acesso, intrusão, PSIM, BMS, sistemas externos |
| Segurança do sistema | integridade do sistema | supervisão de falhas, alimentação, interconexões, tamper, recuperação |
| Segurança do sistema | integridade dos dados | autenticação, autorização, logs, proteção da gravação, exportação e trilha de auditoria |
Esse diagrama não é uma topologia física. Ele é uma arquitetura funcional: mostra o que o sistema precisa fazer. A topologia física vem depois, quando o projetista decide onde cada função será executada, em qual equipamento, com que redundância e por quais interfaces.
Essa separação melhora a documentação de duas maneiras. Primeiro, permite especificar por desempenho e função, evitando que um produto de referência se transforme indevidamente no requisito. Segundo, facilita analisar equivalência: duas soluções físicas diferentes podem atender à mesma arquitetura funcional, desde que cumpram os requisitos definidos.
Graus de segurança e classes ambientais: impacto real na arquitetura
A Parte 1-1 classifica requisitos de acordo com graus de segurança e também estabelece classes ambientais. O erro comum é tratar esses conceitos como rótulos comerciais. Eles devem influenciar diretamente o nível de supervisão, proteção, integridade e resistência exigido do sistema.
Os graus de segurança elevam progressivamente as exigências. A norma associa requisitos distintos, por exemplo, a redundância de armazenamento, backup, monitoramento de interconexões, detecção de violação, controle de acesso e registro de eventos. Por isso, o grau não deve ser selecionado depois de a solução estar desenhada; ele precisa participar da definição do requisito operacional.
| Tema normativo | O que muda quando a criticidade aumenta | Consequência de projeto |
| armazenamento | maior necessidade de redundância e proteção contra falhas | RAID, espelhamento, failover ou estratégia equivalente conforme requisito |
| interconexões | supervisão e tempos de detecção mais rigorosos | monitoramento ativo da conectividade e geração de falha |
| captura | maior necessidade de detectar violação da câmera e da cena | supervisão de perda de vídeo, mudança de campo de visão, obscurecimento e tamper |
| usuários | controle de acesso mais estruturado | perfis, privilégios, autenticação e segregação de funções |
| registros | maior abrangência de eventos auditados | logs de falhas, acessos, exportações, alterações e ações operacionais |
| recuperação | maior exigência de continuidade | cópia/restauração de configuração, alimentação reserva e recuperação controlada |
As classes ambientais, por sua vez, descrevem o ambiente no qual o componente deve operar. A Parte 1-1 diferencia ambientes internos controlados, internos mais severos e aplicações externas com diferentes níveis de exposição. Isso deve ser refletido na seleção do invólucro, proteção mecânica, temperatura, umidade, exposição e instalação.
É importante não confundir classe ambiental da norma com apenas o grau IP de um equipamento. IP e IK podem ser parte da solução, mas o projeto precisa considerar o ambiente completo. A própria norma, ao tratar de proteção contra violação de dispositivos de captura em determinados graus de segurança, relaciona requisitos mecânicos e de proteção do invólucro.
Qualidade de imagem e objetivo de vigilância
Uma arquitetura de CFTV somente é válida quando a imagem entregue é adequada à tarefa operacional. A resolução nominal da câmera, isoladamente, não define essa qualidade. Campo de visão, lente, distância, altura, iluminação, movimento, compressão, bitrate, taxa de quadros, WDR, ruído, posição da câmera e condições ambientais interferem no resultado.
No planejamento, cada ponto deve possuir um objetivo de vigilância. A câmera não é “4 MP” ou “8 MP” como objetivo; essas são características de um componente. O requisito é a informação visual necessária na área de interesse.
| Pergunta de projeto | O que precisa ser definido |
| Qual evento deve ser percebido? | intrusão, passagem, aproximação, permanência, ação específica, leitura de placa ou outra finalidade |
| Que informação visual o operador precisa? | visão geral, características da pessoa/objeto, detalhe, identificação ou evidência |
| Onde está a área de interesse? | polígono, faixa, acesso, perímetro, corredor, portaria, doca, estacionamento |
| Em quais condições? | dia/noite, contraluz, baixa iluminação, chuva, reflexos, movimento, faróis |
| Como será comprovado? | teste de campo e critério de aceite associado à tarefa operacional |
A definição de densidade de pixels e critérios como DORI pode apoiar esse processo, mas deve ser usada como ferramenta de engenharia e não como substituto da análise da cena. O projeto precisa vincular o critério numérico ao objetivo real e prever validação em campo.
A rede IP faz parte do VSS, não é infraestrutura genérica
A ABNT NBR IEC 62676-1-2 é particularmente útil porque trata a transmissão de vídeo como uma função crítica do sistema e estabelece uma metodologia explícita para planejar a rede digital. Isso evita uma prática comum: dimensionar câmeras e servidores detalhadamente e tratar a rede apenas como “Gigabit Ethernet”.
A norma recomenda mapear conexões lógicas, definir topologia, planejar redundância, estabelecer tráfego de referência, simular fluxos, calcular demanda média e de pico, considerar simultaneidade, identificar taxa necessária em acesso/distribuição/core, localizar gargalos, prever crescimento e documentar a capacidade utilizada e máxima.
Essa sequência pode ser traduzida para uma matriz de projeto.
| Etapa | Saída de engenharia |
| mapear conexões lógicas | matriz origem-destino dos fluxos de vídeo, controle e metadados |
| definir topologia | diagrama L2/L3, VLANs, segmentos, enlaces e caminhos |
| planejar redundância | caminhos alternativos, dual-homing, equipamentos redundantes quando aplicável |
| estabelecer tráfego de referência | bitrate por perfil, câmera e cenário |
| simular tráfego | cenário normal, alarmado, playback, exportação e falha |
| definir simultaneidade | quantidade média e máxima de fluxos concorrentes |
| dimensionar camadas | carga em acesso, distribuição, core, WAN e links críticos |
| identificar gargalos | portas, uplinks, WAN, CPU de switches/roteadores, storage e interfaces de servidores |
| prever expansão | headroom de portas, PoE, throughput, processamento e endereçamento |
| documentar | capacidade instalada, utilizada, reservada e máxima |
Capacidade não é apenas soma de bitrates
A Parte 1-2 orienta que a rede deve suportar a aplicação existente somada ao tráfego de vídeo e adota, em seu método de planejamento, uma margem para tráfego de sobrecarga e gerenciamento. A regra apresentada na edição brasileira limita o requisito calculado de um enlace a 75% da taxa total disponível, reservando capacidade para protocolos, verificações e tráfego adicional.
No projeto, o dimensionamento deve considerar pelo menos:
- bitrate médio e máximo por stream;
- múltiplos streams por câmera quando gravação e visualização usam perfis diferentes;
- gravação contínua e gravação por evento;
- clientes simultâneos;
- playback;
- exportação;
- análise centralizada;
- metadados;
- sincronismo e controle;
- replicação, failover ou backup quando aplicável;
- demais aplicações da rede compartilhada.
Em um sistema corporativo, o pico mais relevante pode não ocorrer durante a gravação normal. Um incidente pode provocar abertura simultânea de múltiplas câmeras, acionamento de videowall, gravação em qualidade superior, analytics, exportação e acesso remoto. O cenário de dimensionamento precisa considerar a condição operacional mais exigente plausível, não somente a média diária.
Latência, jitter, perda de pacotes e sincronismo precisam virar requisitos
A Parte 1-2 deixa claro que vídeo IP é sensível a atraso, variação de atraso e perda. Esses parâmetros influenciam diretamente operação ao vivo, PTZ, análise e qualidade percebida.
A latência total não nasce somente da rede. Ela pode acumular tempo de codificação, transmissão, encaminhamento, processamento, buffering, decodificação e apresentação. Por isso, testar apenas ping não comprova desempenho de vídeo.
A norma apresenta classes de desempenho para diferentes funções. Um exemplo é a latência unidirecional máxima para transmissão ao vivo, que se torna progressivamente mais rigorosa nas classes superiores.
| Classe de transmissão | Latência unidirecional máxima indicada pela ABNT NBR IEC 62676-1-2 |
| S1 | 600 ms |
| S2 | 400 ms |
| S3 | 200 ms |
| S4 | 100 ms |
Esses valores não devem ser copiados automaticamente para todo projeto. A própria lógica da norma permite que diferentes funções tenham classes diferentes. Uma câmera utilizada para acompanhamento PTZ pode precisar de resposta mais rigorosa do que um fluxo destinado somente à gravação histórica.
O jitter é a variação do atraso. Buffers podem compensá-lo, mas aumentam a latência. A perda de pacotes, por sua vez, pode causar congelamento, macroblocos, artefatos, queda de taxa de quadros e propagação de erros em codecs dependentes de quadros anteriores. O projeto precisa equilibrar capacidade, QoS quando aplicável, topologia, equipamentos e buffers para que o operador não seja prejudicado.
O sincronismo de tempo é igualmente crítico. A Parte 1-2 relaciona o serviço de tempo à integridade de gravações, eventos e logs. Em ambientes com múltiplos servidores, câmeras, controle de acesso e sistemas integrados, inconsistência de tempo destrói a capacidade de reconstruir uma ocorrência de forma confiável.
Redundância e disponibilidade: localizar o ponto único de falha antes da obra
A norma associa disponibilidade ao requisito operacional e trata explicitamente de redundância de rede. O princípio de projeto é simples: identificar qual falha isolada impede o VSS de cumprir uma tarefa necessária.
A redundância não significa duplicar tudo. Ela deve ser proporcional à função, risco e requisito operacional. Em alguns sistemas, perder temporariamente uma estação cliente não compromete a gravação; em outros, a perda de um switch de distribuição pode desconectar dezenas de câmeras e interromper uma função essencial.
| Camada | Pergunta de disponibilidade | Exemplos de resposta de arquitetura |
| captura | a perda de uma câmera elimina completamente a cobertura crítica? | sobreposição de campos de visão, câmera reserva funcional ou estratégia operacional |
| acesso | a falha de um switch derruba uma zona inteira? | segmentação, distribuição de carga, alimentação adequada, spare ou dual-homing quando tecnicamente justificável |
| backbone | existe caminho único entre acesso e core? | enlaces redundantes, caminhos físicos distintos, protocolos de convergência |
| VMS | a falha do serviço de gerenciamento impede gravação ou somente administração? | separar funções e definir failover conforme arquitetura do VMS |
| gravação | a falha do servidor/storage provoca perda de evidência? | failover de gravação, RAID, edge storage ou replicação conforme requisito |
| energia | UPS ou alimentação única vira ponto de falha? | UPS, circuitos, fontes e autonomia coerentes com a criticidade |
Um projeto de alta disponibilidade precisa ainda definir tempo de detecção, tempo de comutação, perda aceitável e comportamento na recuperação. “Possui redundância” não é critério de aceite.
Gravação centralizada, distribuída e edge: decisão de arquitetura
A Parte 1-2 reconhece arquiteturas centralizadas e descentralizadas para gravação e análise de conteúdo. O texto normativo já aponta o trade-off: centralizar simplifica gestão e expansão, mas pode concentrar tráfego e pontos de falha; distribuir reduz dependência de um segmento central, porém aumenta quantidade de componentes e complexidade operacional.
| Arquitetura | Vantagem | Risco/limitação | Quando analisar |
| gravação centralizada | gestão, expansão e administração mais simples | exige rede e core robustos; centralização pode ampliar impacto de falhas | campus com backbone confiável e data center adequado |
| gravação distribuída | falha de um segmento não necessariamente afeta os demais | mais appliances, manutenção e capacidade distribuída | sites remotos, múltiplas edificações ou zonas independentes |
| edge storage | mantém gravação junto à câmera em determinados eventos de falha | capacidade local limitada e gestão de reconciliação | proteção contra perda de enlace e arquitetura de recuperação |
| híbrida | combina gestão central e resiliência local | maior complexidade de regras e sincronização | sistemas críticos ou multisite |
A decisão precisa considerar não só armazenamento, mas também analytics. Análise centralizada consome rede e processa vídeo já codificado; análise no edge pode reduzir tráfego de eventos e distribuir processamento, mas exige gestão de versões, capacidade e interoperabilidade de metadados.
Storage deve ser dimensionado como função do VSS
A ABNT NBR IEC 62676-1-1 trata armazenamento, backup, exportação e recuperação como funções do sistema. Para projeto, isso significa que a capacidade em terabytes é apenas uma consequência.
O dimensionamento deve registrar:
- número de streams gravados;
- resolução e taxa de quadros;
- codec e perfil;
- bitrate de projeto;
- gravação contínua, por evento ou híbrida;
- retenção;
- margem operacional;
- RAID e overhead;
- capacidade durante falha/rebuild;
- exportação simultânea;
- playback simultâneo;
- expansão futura.
A norma exige que a gravação configurada seja preservada mesmo durante visualização, backup ou exportação. Isso é relevante porque um storage dimensionado somente por volume pode não sustentar IOPS, throughput ou concorrência necessários.
Também é necessário projetar a evidência. A Parte 1-1 aborda extração, cópia, exportação, identificação da fonte, marcação temporal e manutenção da integridade do original. Logo, o teste de aceite não deve se limitar a “a câmera está gravando”; deve provar que uma ocorrência pode ser localizada, reproduzida e exportada com as informações necessárias.
Eventos, alarmes, metadados e logs fazem parte da arquitetura
A Parte 1-1 diferencia dados solicitados pelo operador daqueles gerados por eventos e estabelece requisitos para priorização e tratamento de alarmes. Isso aproxima o projeto de CFTV de uma arquitetura operacional, e não apenas de vídeo.
Um VMS moderno pode receber eventos de vídeo, analytics, controle de acesso, intrusão ou outros sistemas. O projeto precisa definir o que acontece depois do evento.
| Elemento | Definição necessária no projeto |
| origem | câmera, sensor, VMS, servidor, controle de acesso ou sistema integrado |
| tipo | alarme, falha, violação, perda de vídeo, evento analítico, acesso etc. |
| prioridade | regra de classificação e ordem de atendimento |
| ação automática | gravação, popup, preset PTZ, mudança de layout, envio de notificação |
| ação do operador | reconhecer, classificar, despachar, registrar, escalar |
| evidência | vídeo anterior/posterior, metadados, logs e dados correlacionados |
| auditoria | quem reconheceu, alterou, exportou ou executou determinada ação |
A norma também trata metadados como parte do gerenciamento de informação. Eles podem identificar câmera, localização, horário, dados externos, eventos e resultados de análise. Em projetos atuais, metadados deixam de ser acessório e passam a influenciar investigação, busca forense e automação.
Integração não pode criar um atalho de segurança
Quando CFTV, controle de acesso, intrusão e outros subsistemas precisam compartilhar eventos e comandos, a integração deve nascer do projeto — com interfaces, direitos de acesso e comportamento de contingência definidos.
A ABNT NBR IEC 62676-1-1 estabelece um princípio importante para interfaces com outros sistemas: quando um sistema externo acessa ou controla o VSS, ele deve ser tratado como um usuário do VSS, sujeito aos direitos de acesso correspondentes. A integração não deve permitir contornar os controles de segurança do sistema.
Esse ponto deve aparecer explicitamente em projetos que integram CFTV com controle de acesso, intrusão, PSIM, BMS, sistemas de automação ou plataformas corporativas.
A especificação de integração deve definir:
- direção da integração;
- eventos disponibilizados;
- comandos permitidos;
- objetos e metadados trocados;
- protocolo/API/interface;
- autenticação;
- autorização;
- sincronismo de tempo;
- comportamento em indisponibilidade;
- logs e auditoria;
- recuperação após reconexão.
A interoperabilidade também precisa ser tratada antes da contratação. A Parte 1-2 dedica atenção a protocolos de transmissão, formatos padronizados, descoberta, eventos e documentação de formatos proprietários. O projeto deve favorecer interfaces padronizadas e exigir documentação suficiente quando houver extensões proprietárias.
Níveis de acesso e segregação de funções
A Parte 1-1 estrutura níveis de acesso do VSS. Em termos de projeto, isso deve ser convertido em uma matriz de perfis e privilégios.
| Nível funcional | Interpretação de projeto | Exemplos de função |
| Nível 1 | funções sem restrição quando previstas | visualização pública ou função especificamente liberada |
| Nível 2 | operação sem alterar configuração estrutural | operador, reconhecimento de alarmes, playback conforme política |
| Nível 3 | administração do sistema | configuração, usuários, políticas e parâmetros |
| Nível 4 | manutenção/fabricante | intervenções técnicas profundas e manutenção autorizada |
O projeto não precisa copiar literalmente essa tabela para o produto final, mas deve garantir que a solução possua níveis coerentes de acesso e que as funções sejam atribuídas segundo a política da organização. Um VMS que concentra operador, administrador e manutenção em uma única credencial contraria a lógica de segregação requerida para sistemas mais críticos.
Cibersegurança do VSS começa na arquitetura
Embora a Parte 1-1 use principalmente os conceitos de integridade do sistema e dos dados, sua lógica converge com práticas atuais de cibersegurança: impedir acesso não autorizado, registrar alterações, proteger interconexões, preservar evidências e detectar falhas ou violações.
A arquitetura deve prever segmentação de rede, controle de acesso administrativo, serviços estritamente necessários, atualização segura, proteção de credenciais, logs, sincronismo, backup de configuração e canais seguros de administração. Em sistemas críticos, deve-se ainda definir como as integrações externas atravessam fronteiras de confiança.
É recomendável separar pelo menos os planos de vídeo, gerenciamento e acesso administrativo quando a arquitetura e o porte justificarem. A separação pode ser lógica ou física conforme o risco, mas deve ser documentada.
Documentação técnica: o projeto precisa permitir construir, testar e operar
A Parte 1-1 dedica seção própria à documentação do sistema. O planejamento de arquitetura deve converter os requisitos normativos em um conjunto documental rastreável.
| Entregável | Conteúdo mínimo recomendado |
| Programa de necessidades / OR | objetivos, riscos, usuários, eventos, operação, integrações e restrições |
| Memorial descritivo | conceito da solução, arquitetura, funções e premissas |
| Planta de pontos | localização, identificação e objetivo de cada câmera |
| Matriz de pontos | ID, cena, função, requisitos visuais, gravação, analytics e integração |
| Diagrama funcional | funções do VSS e relações entre elas |
| Diagrama lógico | VLANs, segmentos, servidores, fluxos e interfaces |
| Diagrama físico | equipamentos, racks, enlaces, fibras, portas e alimentação |
| Memória de cálculo de rede | bitrates, simultaneidade, cargas por enlace, margens e gargalos |
| Memória de cálculo de storage | canais, bitrate, retenção, RAID, margem e concorrência |
| Matriz de integração | eventos, comandos, dados, direção, protocolo e comportamento de falha |
| Matriz de usuários | perfis, privilégios e responsabilidades |
| Especificações técnicas | requisitos de desempenho e interfaces dos componentes |
| Planilha de quantitativos | quantidades vinculadas aos desenhos e especificações |
| Plano de testes | critérios de verificação e evidências requeridas |
Essa estrutura faz diferença no procurement. Um projeto bem documentado permite comparar propostas por aderência técnica, em vez de comparar listas de marcas ou depender de interpretações posteriores do integrador.
Como transformar a Parte 1-2 em uma memória de cálculo de rede
Uma boa memória de cálculo não deve apresentar somente um total em Mbps. Ela precisa demonstrar de onde o tráfego vem e por onde ele passa.
Uma metodologia prática é criar uma matriz com cada fonte e seus perfis de vídeo, mapear destinos e depois consolidar por enlace. Para cada câmera, registrar stream principal de gravação, stream de visualização, analytics quando centralizado e eventual gravação por evento. Depois adicionar clientes, videowall, exportação e acesso remoto.
A análise por enlace pode seguir uma lógica como:
- calcular o tráfego contínuo esperado;
- calcular o cenário de pico operacional;
- adicionar tráfego de serviços e gerenciamento;
- aplicar margem de capacidade;
- verificar portas e uplinks;
- avaliar oversubscription;
- simular falhas que redirecionem tráfego para um caminho alternativo;
- verificar se o caminho redundante também suporta o cenário resultante.
Esse último passo é frequentemente esquecido. Uma rede pode suportar perfeitamente o tráfego em condição normal e entrar em congestionamento justamente durante o failover.
Topologias hierárquicas e pontos de concentração
A Parte 1-2 apresenta exemplos de redes pequenas, multicast, hierárquicas e redundantes. O valor desses exemplos não está em copiá-los, mas em compreender os efeitos de concentração.
Em uma arquitetura hierárquica, o tráfego tende a crescer em direção às camadas de distribuição e core. Se gravação e VCA forem centralizados, os links agregadores precisam transportar os streams continuamente. Se o projeto inclui operadores distribuídos e videowall, também haverá tráfego no sentido de apresentação.
O desenho deve mostrar claramente:
- switches de acesso e seus pontos atendidos;
- uplinks e capacidade nominal;
- agregação por distribuição;
- core e servidores;
- caminho para storage;
- caminho para clientes;
- WAN ou enlaces entre prédios;
- caminhos redundantes;
- fronteiras de L2/L3;
- dependência de multicast quando utilizado.
O diagrama de rede precisa ser acompanhado de memória de cálculo. Um desenho sem cargas não demonstra capacidade; uma planilha sem topologia não demonstra por onde a carga passa.
Multicast, múltiplos streams e prioridade de tráfego
A Parte 1-2 considera redes com unicast e multicast e estabelece requisitos para dispositivos que suportam multidifusão. Em projetos grandes, multicast pode reduzir duplicação de streams em determinados cenários de visualização, mas exige configuração correta de switches, querier e mecanismos como IGMP snooping.
Da mesma forma, múltiplos streams devem ser utilizados de maneira planejada. A norma reconhece que visualização ao vivo e gravação podem exigir qualidades diferentes e que gravação normal e por alarme podem demandar configurações distintas.
Isso influencia câmera, VMS, banda e processamento. O projeto precisa definir quais perfis existem e para qual finalidade cada um será utilizado. Permitir que cada operador selecione livremente o stream principal de dezenas de câmeras pode inviabilizar uma rede que foi calculada para streams secundários de visualização.
Da arquitetura ao comissionamento: o requisito precisa sobreviver até o aceite
A arquitetura só se encerra quando os requisitos podem ser testados. Critérios de desempenho, failover, gravação, exportação e integração precisam chegar ao plano de comissionamento.
A ABNT NBR IEC 62676-1-1 fornece requisitos funcionais e de desempenho, mas seu próprio escopo não pretende cobrir integralmente projeto, instalação, ensaio, operação e manutenção. Para fechar o ciclo, a edição internacional IEC 62676-4:2025 trata explicitamente de planejamento, projeto, instalação, testes, comissionamento e manutenção de VSS.
Na prática de engenharia, isso significa que o projeto deve ser escrito de forma que cada requisito relevante possua um método de verificação.
| Requisito de projeto | Exemplo de evidência de aceite |
| cobertura visual | teste de cena e registro fotográfico/visual conforme objetivo definido |
| latência operacional | medição ponta a ponta no cenário especificado |
| retenção | comprovação de capacidade e consulta ao período requerido |
| exportação | extração de ocorrência, reprodução externa e verificação de metadados |
| perda de vídeo | interrupção controlada e comprovação do alarme/log |
| falha de enlace | teste de caminho redundante e tempo de recuperação |
| perfis de usuário | teste de permissões positivas e negativas |
| integração | roteiro de evento, comando, retorno, timeout e recuperação |
| sincronismo | comparação de timestamps entre dispositivos e sistemas integrados |
O comissionamento não deve inventar critérios no final da obra. Ele deve comprovar requisitos que já estavam definidos no OR, memorial, especificações, diagramas e matrizes.
Erros recorrentes no planejamento de arquitetura de CFTV
Começar pelo catálogo de câmeras. A escolha do componente antecede o requisito. O resultado costuma ser uma coleção de recursos sem vínculo claro com a tarefa operacional.
Usar megapixels como sinônimo de qualidade. Resolução é uma variável. Cena, lente, densidade, luz, movimento, compressão e posicionamento determinam se a informação necessária será obtida.
Dimensionar rede pela soma nominal das câmeras. Ignora múltiplos streams, visualização, eventos, exportação, failover, overhead, tráfego compartilhado e picos.
Chamar RAID de alta disponibilidade. RAID protege contra determinados modos de falha de disco; não substitui redundância de servidor, serviço, rede, energia ou site.
Não definir OR. Sem requisito operacional, qualquer solução que “mostre imagem” pode parecer aceitável, mesmo sem atender à finalidade real.
Desenhar integração sem comportamento de falha. O diagrama mostra setas, mas não define timeout, reconexão, fila, perda de evento, prioridade ou auditoria.
Não documentar perfis de usuário. Operador, supervisor, administrador e manutenção acabam compartilhando privilégios excessivos.
Confundir redundância com duplicação. Duplicar equipamentos sem eliminar o mesmo caminho, fonte de energia ou serviço comum preserva o ponto único de falha.
Não vincular projeto e aceite. Requisitos não verificáveis viram discussões subjetivas durante a entrega.
Checklist executivo para revisar uma arquitetura de VSS
Antes de liberar o projeto para contratação ou implantação, a equipe deve conseguir responder objetivamente:
- existe requisito operacional documentado?
- cada ponto possui objetivo de vigilância?
- as funções do VSS estão mapeadas independentemente de fabricante?
- a topologia lógica e física está documentada?
- os fluxos e bitrates estão calculados por enlace?
- há margem de capacidade e cenário de pico?
- os pontos únicos de falha foram identificados?
- retenção, gravação, playback e exportação estão dimensionados?
- eventos e alarmes possuem comportamento definido?
- metadados e integrações possuem interface documentada?
- perfis e níveis de acesso estão definidos?
- logs, sincronismo e auditoria estão previstos?
- condições ambientais foram consideradas?
- especificações técnicas traduzem função e desempenho em requisitos?
- cada requisito crítico possui critério de teste e aceite?
Se várias dessas respostas ainda forem “depende do fornecedor”, a arquitetura provavelmente não está suficientemente definida para uma contratação técnica madura.
Considerações finais
A principal contribuição da ABNT NBR IEC 62676 para o planejamento de CFTV é mudar a unidade de análise: o sistema não é uma lista de equipamentos, mas um conjunto de funções, requisitos, interfaces, dados e relações operacionais. Captura, transmissão, manipulação de imagem, gerenciamento, integridade e segurança precisam ser projetados como um todo.
A Parte 1-1 fornece a estrutura funcional, os requisitos de sistema, graus de segurança, integridade, gerenciamento, armazenamento, eventos, acesso e documentação. A Parte 1-2 transforma a transmissão IP em disciplina de engenharia, exigindo atenção a capacidade, sincronismo, latência, jitter, perda, redundância e monitoramento. A Parte 4 internacional atual fecha o ciclo ao tratar de aplicação, testes e comissionamento.
Quando esses elementos são convertidos em OR, diagramas, matrizes, memórias de cálculo, especificações e planos de teste, o projeto deixa de depender de decisões improvisadas durante a obra. A organização passa a conseguir comparar propostas, validar equivalência, fiscalizar a implantação e aceitar o sistema com critérios objetivos — que é precisamente o papel de uma arquitetura de engenharia bem definida.
Em sistemas existentes, uma Due Diligence técnica permite levantar a arquitetura instalada, identificar gargalos, pontos únicos de falha, documentação ausente e riscos antes da modernização.
Referências técnicas
[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR IEC 62676-1-1:2019 — Sistemas de videomonitoramento para uso em aplicações de segurança — Parte 1-1: Requisitos de sistema — Generalidades. Rio de Janeiro: ABNT, 2019.
[2] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR IEC 62676-1-2:2019 — Sistemas de videomonitoramento para uso em aplicações de segurança — Parte 1-2: Requisitos de sistema — Requisitos de desempenho para transmissão de vídeo. Rio de Janeiro: ABNT, 2019.
[3] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62676-4:2025 — Video surveillance systems for use in security applications — Part 4: Application guidelines. Geneva: IEC, 2025. Disponível em: https://webstore.iec.ch/en/publication/83425
[4] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62676-1-1:2013 — Video surveillance systems for use in security applications — Part 1-1: System requirements — General. Geneva: IEC, 2013. Disponível em: https://webstore.iec.ch/en/publication/7347
Perguntas frequentes
A Parte 1-1 define requisitos mínimos e recomendações para o VSS, incluindo arquitetura funcional, gerenciamento, integridade, segurança, armazenamento, acesso, eventos e documentação. A Parte 1-2 trata do desempenho da transmissão de vídeo e do projeto da rede IP. Esses requisitos precisam ser convertidos pelo projeto em arquitetura, especificações e critérios de aceite.
Não. O próprio escopo da Parte 1-1 informa que ela estabelece requisitos funcionais e de desempenho, mas não pretende cobrir integralmente projeto, planejamento, instalação, testes, operação ou manutenção. A IEC 62676-4 trata das diretrizes de aplicação e sua edição internacional atual é de 2025.
Porque a ABNT NBR IEC 62676-1-2 trata capacidade, latência, jitter, perda de pacotes, sincronismo, redundância e monitoramento como requisitos da transmissão de vídeo. Uma rede que possui conectividade, mas não sustenta esses parâmetros, pode comprometer gravação, operação ao vivo, PTZ, analytics e evidência.
É a definição documentada das necessidades operacionais que o sistema deve atender, como finalidade, eventos, usuários, resposta, desempenho, retenção, integrações e criticidade. Ele serve de base para acordar requisitos e orientar a arquitetura e os testes.
Primeiro devem ser identificadas as funções críticas e os pontos únicos de falha. Depois são definidos caminhos, equipamentos ou serviços redundantes de forma proporcional ao risco, sempre acompanhados de critérios de detecção, comutação e recuperação. Duplicar componentes sem eliminar a dependência comum não garante alta disponibilidade.
Cada requisito crítico deve ter um método de verificação definido antes da implantação. Exemplos incluem teste de cobertura visual, latência, perda de vídeo, failover, retenção, exportação, permissões de usuário, integração, sincronismo e recuperação após falha.
Materiais técnicos complementares
Conteúdos principais sobre o tema
- Guia Completo sobre Sistemas de CFTV
- Guia Completo sobre Sistemas de Segurança Eletrônica
- Cibersegurança em Sistemas de CFTV: arquitetura, hardening e gestão de riscos
- Estrutura Funcional de um Sistema de Videomonitoramento (VSS) segundo as Normas Técnicas de Segurança
Conteúdos técnicos correlatos
- Infraestrutura de CFTV IP: rede, PoE, switches, VMS, storage e backbone
- Como Dimensionar Storage para CFTV e VMS Corporativo
- Central de Monitoramento: arquitetura, sistemas e requisitos de projeto
