ONVIF em controle de acesso: diferenças entre Profiles A, C e D, interoperabilidade, conformidade oficial, device/client e testes FAT/SAT.
Confira!
ONVIF em controle de acesso é o uso das interfaces padronizadas da ONVIF para permitir interoperabilidade entre dispositivos e clientes de sistemas eletrônicos de acesso baseados em IP. Nesse domínio, os perfis centrais são o ONVIF Profile A, voltado à configuração de credenciais, agendas e regras de acesso; o ONVIF Profile C, voltado a controle de portas e gerenciamento de eventos; e o ONVIF Profile D, voltado a periféricos como leitores, fechaduras, sensores, teclados e dispositivos biométricos.
Esse recorte é diferente do uso mais conhecido do ONVIF em CFTV. O termo ONVIF é amplamente associado a câmeras e VMS, mas os Profiles A, C e D tratam especificamente do ecossistema de acesso físico. Em projeto, a presença do logotipo ONVIF ou a afirmação genérica “suporta ONVIF” não basta: é necessário verificar qual perfil, qual papel do produto como device ou client, quais funções são obrigatórias ou condicionais, qual versão de firmware/software consta na base oficial de conformidade e se o conjunto de funções exigidas pelo projeto está efetivamente coberto.
ONVIF não é um protocolo único nem uma garantia genérica de compatibilidade
ONVIF é uma iniciativa de padronização de interfaces para produtos de segurança física baseados em IP. As funcionalidades são organizadas em especificações e em profiles. Cada profile reúne um conjunto fixo de recursos que dispositivos e clientes conformantes precisam implementar nos níveis definidos pela ONVIF.
Isso significa que a pergunta “o equipamento tem ONVIF?” é incompleta. Dois produtos podem ser ONVIF conformant e ainda suportar profiles diferentes, destinados a funções diferentes. Um leitor Profile D e um software Profile A, por exemplo, não são automaticamente equivalentes nem executam o mesmo papel no sistema.
O artigo geral O que é ONVIF? deve continuar sendo a referência para o conceito amplo. Aqui, o foco é a aplicação específica em controle de acesso físico e a diferença funcional entre Profiles A, C e D.
Profiles A, C e D cobrem camadas diferentes do controle de acesso
ONVIF precisa ser especificado por função: profile, papel device/client, features e versão conformante. “Compatível com ONVIF” sozinho não define interoperabilidade.
A ONVIF descreve os três perfis de forma complementar:
| Profile | Foco principal | Exemplos de funções |
| Profile A | configuração de controle de acesso | credenciais, agendas, regras e privilégios |
| Profile C | controle de portas e eventos | site, portas, pontos de acesso, eventos e alarmes |
| Profile D | periféricos de controle de acesso | leitores, biometria, teclados, sensores, fechaduras e displays |
Essa separação é importante porque a interoperabilidade precisa ser especificada por função. Um projeto que exige apenas “ONVIF” sem declarar o profile e a função esperada deixa margem para produtos formalmente compatíveis com ONVIF em outra área, mas inadequados para a integração de acesso contratada.
ONVIF Profile A é voltado à configuração de acesso
O ONVIF Profile A foi definido para funções de configuração em sistemas eletrônicos de controle de acesso. Segundo a ONVIF, ele cobre concessão e revogação de credenciais, criação de agendas e atribuição de regras de acesso.
Um dispositivo conformante com Profile A pode disponibilizar informações, status e eventos e permitir configuração de entidades como regras, credenciais e agendas. Um cliente Profile A pode fornecer essas configurações e receber eventos padronizados relacionados ao acesso.
No contexto de engenharia, isso aproxima o profile das funções que normalmente pertencem à camada de gestão de identidades físicas: quem possui qual credencial, em quais horários e sob quais privilégios. Isso não significa que Profile A substitua integrações corporativas com RH ou IAM; significa que padroniza interfaces específicas dentro do domínio ONVIF.
Profile A é particularmente relevante para sistemas multivendor
Em ambientes em que software de gestão e dispositivos de acesso vêm de fabricantes diferentes, uma interface padronizada reduz a dependência de drivers proprietários para funções cobertas pelo profile.
O ganho de engenharia está na possibilidade de especificar resultados de interoperabilidade em vez de uma combinação única de marcas. Entretanto, é preciso verificar o conjunto efetivo de features obrigatórias e condicionais. Um requisito que depende de uma função fora do profile pode continuar exigindo API, SDK ou integração específica.
Por isso, “Profile A conformant” deve ser tratado como evidência de cobertura de um conjunto padronizado, não como promessa de que qualquer função avançada de qualquer plataforma será intercambiável.
ONVIF Profile C trata de portas, pontos de acesso e eventos
O ONVIF Profile C é direcionado a produtos de sistemas eletrônicos de controle de acesso e cobre informações do site, controle de portas e gerenciamento de eventos e alarmes.
Na prática, é o profile mais diretamente relacionado ao comportamento operacional de portas e pontos de acesso. Ele pode participar de cenários em que um cliente precisa conhecer estado de porta, controlar funções básicas e receber eventos padronizados.
Isso é especialmente relevante em integração com plataformas de segurança. Em vez de cada fabricante representar porta, acesso e alarme por uma interface completamente própria, Profile C estabelece um vocabulário e serviços comuns para as funções previstas em sua especificação.
Profile C não deve ser confundido com Profile C de outros fabricantes ou nomenclaturas comerciais
A letra C é parte do sistema de profiles da ONVIF. Ela não representa “classe C” de segurança nem um nível de desempenho de porta. O projeto deve citar explicitamente ONVIF Profile C e, quando necessário, as funções do profile exigidas.
Também não basta encontrar a expressão Profile C em material comercial. A conformidade oficial precisa ser verificada na base de produtos conformantes da ONVIF para o modelo e versão de firmware/software correspondentes.
ONVIF Profile D leva a padronização até os periféricos
O ONVIF Profile D foi criado para interfaces de periféricos de controle de acesso. A ONVIF inclui nesse universo leitores de tokens e cartões, credenciais móveis, leitores biométricos, câmeras usadas para reconhecimento, teclados, sensores, fechaduras, displays e LEDs.
A arquitetura é importante: um dispositivo Profile D captura um identificador ou uma solicitação de acesso e a envia para um client localizado em camada segura, como uma unidade de controle ou software de gestão. O client mantém regras, agendas e credenciais, toma a decisão e pode retornar uma ação ao periférico.
Essa separação ajuda a manter a decisão de acesso em componente ou aplicação apropriada, em vez de pressupor que todo periférico de borda armazene toda a política de acesso.
Profile D não transforma qualquer leitor em controladora autônoma
A própria especificação do Profile D diferencia o periférico de uma unidade de controle de acesso. Um dispositivo Profile D não precisa armazenar localmente regras, agendas ou todas as credenciais; ele pode encaminhar identificadores ao client responsável pela decisão.
Isso é relevante para projeto porque “leitor IP ONVIF” pode significar arquiteturas diferentes. O engenheiro precisa definir onde ocorre a decisão, o que acontece quando a comunicação com o client é perdida, quais funções locais existem e como a porta se comporta em contingência.
O profile padroniza a interface prevista; ele não elimina a necessidade de arquitetura funcional e análise de disponibilidade.
A, C e D são complementares, não versões sucessivas do mesmo recurso
Não é correto interpretar Profile D como “mais novo e melhor” que Profile C, nem Profile A como substituto integral de C. Os três têm objetivos distintos e podem coexistir no mesmo sistema.
Uma solução pode usar Profile A para configuração de políticas, Profile C para portas e eventos e Profile D para periféricos. A combinação necessária depende dos papéis de cada produto e dos fluxos definidos no projeto.
A ONVIF também indica que sistemas de controle de acesso podem utilizar outros profiles, como Profile M em determinados cenários de metadados e eventos. Isso não altera o foco deste artigo: A, C e D constituem o núcleo diretamente orientado à configuração, controle de portas e periféricos de acesso.
Device e client precisam suportar o mesmo profile na função correspondente
Interoperabilidade ONVIF pressupõe papéis compatíveis. Um device expõe serviços; um client consome esses serviços. Para a função padronizada operar, ambos precisam ser conformantes com o profile relevante e implementar os requisitos aplicáveis.
Isso evita uma leitura comum, mas incorreta: “o hardware é ONVIF, então qualquer software ONVIF funcionará”. A compatibilidade depende do profile e da função. Um client de vídeo Profile T não substitui um client Profile C para controle de portas apenas porque ambos pertencem ao ecossistema ONVIF.
Na matriz de integração, o projeto deveria identificar pelo menos:
- produto ou função que atua como device;
- produto ou função que atua como client;
- profile ONVIF exigido;
- features necessárias ao caso de uso;
- funções fora do profile que dependerão de integração adicional;
- versão de firmware/software validada.
“Suporta ONVIF” não é o mesmo que ser ONVIF conformant
A ONVIF mantém uma base oficial de Conformant Products e declara que essa é a fonte autoritativa para verificar conformidade. Um produto só é considerado oficialmente conformante quando passa pelo processo definido e é registrado com o profile correspondente.
Além disso, a conformidade está vinculada à versão específica de firmware/software registrada. Verificar apenas modelo e fabricante não é suficiente quando a versão instalada diverge daquela listada.
Essa verificação deve fazer parte de submittal, análise de equivalência, FAT ou comissionamento quando a conformidade ONVIF é requisito contratual.
A base oficial precisa fazer parte da análise de equivalência
Se o edital, especificação ou projeto exige Profile A, C ou D, o fornecedor deve demonstrar que o modelo ofertado e a versão aplicável aparecem na base oficial para o profile solicitado.
A simples presença do fabricante como membro da ONVIF não comprova conformidade de todos os produtos. A própria ONVIF alerta que membership e alegações comerciais não substituem a listagem oficial do produto.
Uma matriz de conformidade pode registrar fabricante, modelo, firmware/software, profile, papel device/client, URL da listagem oficial, features condicionais relevantes e observações de teste.
Profiles definem um piso de interoperabilidade, não toda a solução
Sistemas de acesso possuem funções que podem estar fora do escopo de um profile: recursos específicos de biometria, workflows de visitantes, políticas avançadas de IAM, dashboards, funções analíticas, automações proprietárias ou integrações com ERP.
O projeto deve separar três camadas:
- funções cobertas pelo profile ONVIF exigido;
- funções padronizadas por outra interface ou norma;
- funções que dependem de API/SDK proprietário.
Essa separação reduz o risco de prometer interoperabilidade que o profile não cobre e ajuda a identificar pontos futuros de vendor lock-in.
ONVIF pode reduzir dependência de integrações proprietárias, mas não elimina vendor lock-in sozinho
Um profile padronizado melhora portabilidade na camada que ele cobre. Contudo, o sistema completo ainda pode depender de banco de dados, licenciamento, workflows, recursos de gestão, formatos de credencial e extensões específicas de fabricante.
Por isso, ONVIF deve ser usado como critério de arquitetura, não como slogan de independência tecnológica. O projeto precisa mapear quais interfaces são padronizadas e quais continuam proprietárias.
Em migrações futuras, essa documentação permite avaliar quais componentes podem ser preservados e quais integrações precisarão ser refeitas.
OSDP e ONVIF atuam em camadas diferentes
OSDP é um protocolo amplamente aplicado à comunicação entre leitor e controladora em um enlace de campo. ONVIF trabalha com interfaces IP entre devices e clients para funções padronizadas de segurança física.
Portanto, um projeto pode utilizar OSDP Secure Channel entre leitor e controladora e ONVIF em outra camada entre controlador, periférico IP ou software de gestão. Eles não são concorrentes diretos.
Essa distinção evita especificações do tipo “OSDP ou ONVIF” para a mesma interface sem compreender a arquitetura. O critério deve indicar qual enlace está sendo especificado e qual função precisa ser interoperável.
ONVIF e integração com CFTV podem coexistir no mesmo ecossistema
Interfaces ONVIF podem reduzir integrações proprietárias, mas precisam ser coordenadas com VMS, rede, cibersegurança e demais sistemas físicos.
A origem histórica e a adoção ampla do ONVIF em vídeo tornam natural a integração entre acesso e videomonitoramento. A própria ONVIF descreve combinações entre Profiles de acesso e profiles de vídeo.
No projeto, isso pode permitir que eventos de porta sejam correlacionados a vídeo por interfaces padronizadas em partes da arquitetura. Entretanto, a integração completa entre VMS e controle de acesso pode exigir funções adicionais além dos profiles individuais.
O artigo CFTV e controle de acesso: integração, VMS e critérios de projeto trata essa integração pela ótica funcional; este conteúdo trata especificamente da interoperabilidade ONVIF.
A cibersegurança continua sendo requisito de projeto
Padronização de interface não elimina riscos de rede. Dispositivos ONVIF são equipamentos IP e precisam ser tratados dentro da arquitetura de segurança: segmentação, autenticação, credenciais administrativas, TLS quando aplicável, atualização de firmware, hardening, gestão de certificados e monitoramento.
O profile define interoperabilidade de determinadas funções, não uma política completa de cibersegurança da instalação. ONVIF mantém requisitos e mecanismos de segurança em suas especificações, mas o nível global de segurança depende também da configuração e da arquitetura implementada.
Como especificar ONVIF em controle de acesso sem criar requisito vazio
Uma especificação não deveria dizer apenas “compatível com ONVIF”. Ela pode exigir:
- conformidade oficial com Profile A, C ou D conforme a função do componente;
- identificação clara do papel device/client;
- modelo e firmware/software listados na base oficial de produtos conformantes;
- suporte às features obrigatórias e às condicionais necessárias ao caso de uso;
- documentação de funções que permanecem proprietárias;
- comportamento diante de perda de comunicação;
- requisitos de segurança da interface IP;
- evidência de interoperabilidade no FAT e SAT;
- entrega da matriz de conformidade e versões testadas.
Esse formato permite concorrência sem transformar “ONVIF” em palavra decorativa na especificação.
FAT deve testar funções, não apenas descoberta de dispositivo
Encontrar um equipamento na rede ou receber uma resposta ONVIF não prova que as funções necessárias ao projeto são interoperáveis. O FAT deve executar casos de uso associados ao profile exigido.
Para Profile A, pode ser necessário validar configuração de credenciais, agendas ou regras previstas. Para Profile C, portas, estados, comandos e eventos. Para Profile D, intercâmbio entre periférico e client nas funções contratadas.
O teste deve registrar modelos, versões de firmware/software, client, device, profile, função exercitada, resultado e eventuais limitações.
SAT precisa confirmar a integração no ambiente real
No campo, rede, VLANs, firewalls, certificados, latência, controladoras, portas e aplicações reais podem revelar problemas não vistos em bancada. O SAT deve repetir funções críticas na topologia instalada.
Também é necessário verificar upgrades. Se a conformidade está associada a versão de firmware/software e uma atualização muda componentes do sistema, o processo de gestão de mudanças precisa considerar impacto de compatibilidade.
Quando Profiles A, C e D devem entrar no Projeto de Controle de Acesso
Os profiles devem ser considerados quando a estratégia de interoperabilidade exige reduzir dependência de interfaces proprietárias entre componentes ou plataformas que efetivamente suportam ONVIF nesse domínio.
O Projeto de Controle de Acesso deve decidir em quais interfaces a padronização agrega valor, quais profiles são necessários, quais funções continuam fora do escopo e como a conformidade será comprovada. Isso permite usar ONVIF como requisito técnico verificável, e não como substituto genérico para uma arquitetura de integração.
Considerações finais
ONVIF em controle de acesso é mais específico do que a expressão genérica “produto ONVIF”. Profile A trata de configuração de regras, credenciais e agendas; Profile C, de portas, pontos de acesso, eventos e alarmes; Profile D, de periféricos de acesso.
A interoperabilidade depende de profiles compatíveis, papéis device/client, features necessárias e versões efetivamente conformantes. Quando esses elementos entram na especificação e no FAT/SAT, o ONVIF pode reduzir integrações proprietárias e ampliar liberdade arquitetural sem criar uma promessa de compatibilidade além do que o padrão realmente cobre.
Conformidade oficial e interoperabilidade funcional devem ser demonstradas no FAT e confirmadas no SAT com os modelos e versões efetivamente instalados.
Referências técnicas
[1] ONVIF. ONVIF Profiles — conceito de profiles e interoperabilidade. Disponível em: https://www.onvif.org/profiles/
[2] ONVIF. Profile A — For access control configuration. Disponível em: https://www.onvif.org/profiles/onvif-profile-a/
[3] ONVIF. Profile C — For door control and event management. Disponível em: https://www.onvif.org/profiles/onvif-profile-c/
[4] ONVIF. Profile D — For access control peripherals. Disponível em: https://www.onvif.org/profiles/profile-d/
[5] ONVIF. Conformant Products — base oficial de produtos ONVIF conformantes. Disponível em: https://www.onvif.org/conformant-products/
[6] ONVIF. Conformance Process — requisitos de conformidade por profile e versão de firmware/software. Disponível em: https://www.onvif.org/profiles/conformance/
[7] IEC. IEC 60839-11-1:2013 — Electronic access control systems — System and components requirements. Disponível em: https://webstore.iec.ch/en/publication/3662
Perguntas frequentes
Os principais são Profile A para configuração de credenciais, agendas e regras; Profile C para controle de portas e eventos; e Profile D para periféricos como leitores, sensores, fechaduras e dispositivos biométricos.
Não. Eles são complementares. Profile C trata de controle de portas e eventos; Profile D trata da interface de periféricos de acesso. Uma solução pode utilizar ambos.
Não. A ONVIF considera oficialmente conformantes os produtos registrados em sua base de Conformant Products para o profile e a versão de firmware/software correspondentes.
Não. OSDP normalmente atua na comunicação de campo entre leitor e controladora, enquanto ONVIF padroniza interfaces IP entre devices e clients em funções específicas. Eles podem coexistir na mesma arquitetura.
FAT e SAT devem executar as funções exigidas pelo profile, registrando device, client, modelo, firmware/software, profile, caso de uso e resultado. Apenas descobrir o dispositivo na rede não comprova interoperabilidade funcional.
