ONVIF en control de acceso: diferencias entre Profiles A, C y D, interoperabilidad, conformidad oficial, funciones device/client y pruebas FAT/SAT.
¡Descúbrelo!
ONVIF en control de acceso es el uso de interfaces estandarizadas de ONVIF para permitir la interoperabilidad entre dispositivos y clientes de sistemas electrónicos de acceso basados en IP. En este ámbito, los perfiles centrales son ONVIF Profile A, orientado a la configuración de credenciales, horarios y reglas de acceso; ONVIF Profile C, orientado al control de puertas y la gestión de eventos; y ONVIF Profile D, orientado a periféricos como lectores, cerraduras, sensores, teclados y dispositivos biométricos.
Este enfoque es diferente del uso más conocido de ONVIF en videovigilancia. El término ONVIF está ampliamente asociado a cámaras y plataformas VMS, pero los Profiles A, C y D tratan específicamente el ecosistema de acceso físico. En diseño, la presencia del logotipo ONVIF o la afirmación genérica “compatible con ONVIF” no es suficiente: es necesario verificar qué profile, qué función desempeña el producto como device o client, qué funciones son obligatorias o condicionales, qué versión de firmware/software figura en la base oficial de conformidad y si el conjunto de funciones exigidas por el proyecto está realmente cubierto.
ONVIF no es un protocolo único ni una garantía genérica de compatibilidad
ONVIF es una iniciativa de estandarización de interfaces para productos de seguridad física basados en IP. Las funcionalidades se organizan en especificaciones y profiles. Cada profile reúne un conjunto fijo de capacidades que los dispositivos y clientes conformes deben implementar en los niveles definidos por ONVIF.
Esto significa que la pregunta “¿el equipo tiene ONVIF?” es incompleta. Dos productos pueden ser conformes con ONVIF y aun así soportar profiles diferentes, destinados a funciones diferentes. Un lector Profile D y un software Profile A, por ejemplo, no son automáticamente equivalentes ni desempeñan el mismo papel en el sistema.
El artículo general ¿Qué es ONVIF? debe seguir siendo la referencia para el concepto amplio. Aquí, el foco es la aplicación específica al control de acceso físico y la diferencia funcional entre Profiles A, C y D.
Profiles A, C y D cubren capas diferentes del control de acceso
ONVIF debe especificarse por función: profile, papel device/client, features y versión conforme. “Compatible con ONVIF” por sí solo no define interoperabilidad.
ONVIF describe los tres perfiles como complementarios:
| Profile | Enfoque principal | Ejemplos de funciones |
| Profile A | configuración del control de acceso | credenciales, horarios, reglas y privilegios |
| Profile C | control de puertas y eventos | sitio, puertas, puntos de acceso, eventos y alarmas |
| Profile D | periféricos de control de acceso | lectores, biometría, teclados, sensores, cerraduras y pantallas |
Esta separación es importante porque la interoperabilidad debe especificarse por función. Un proyecto que exija únicamente “ONVIF” sin declarar el profile y la función esperada deja margen para productos formalmente compatibles con ONVIF en otra área, pero inadecuados para la integración de acceso contratada.
ONVIF Profile A está orientado a la configuración de acceso
ONVIF Profile A fue definido para funciones de configuración en sistemas electrónicos de control de acceso. Según ONVIF, cubre la concesión y revocación de credenciales, la creación de horarios y la asignación de reglas de acceso.
Un dispositivo conforme con Profile A puede proporcionar información, estado y eventos, y permitir la configuración de entidades como reglas, credenciales y horarios. Un cliente Profile A puede proporcionar estas configuraciones y recibir eventos estandarizados relacionados con el acceso.
Desde la perspectiva de ingeniería, esto acerca el profile a las funciones que normalmente pertenecen a la capa de gestión de identidades físicas: quién posee qué credencial, en qué horarios y bajo qué privilegios. Esto no significa que Profile A sustituya integraciones corporativas con RR. HH. o IAM; significa que estandariza interfaces específicas dentro del dominio ONVIF.
Profile A es especialmente relevante para sistemas multivendor
En entornos donde el software de gestión y los dispositivos de acceso provienen de fabricantes diferentes, una interfaz estandarizada reduce la dependencia de drivers propietarios para las funciones cubiertas por el profile.
La ventaja de ingeniería está en la posibilidad de especificar resultados de interoperabilidad en lugar de una única combinación de marcas. Sin embargo, es necesario verificar el conjunto efectivo de features obligatorias y condicionales. Un requisito que dependa de una función fuera del profile puede seguir requiriendo una API, SDK o integración específica.
Por ello, “Profile A conformant” debe tratarse como evidencia de cobertura de un conjunto estandarizado, no como promesa de que cualquier función avanzada de cualquier plataforma será intercambiable.
ONVIF Profile C trata puertas, puntos de acceso y eventos
ONVIF Profile C está dirigido a productos de sistemas electrónicos de control de acceso y cubre información del sitio, control de puertas y gestión de eventos y alarmas.
En la práctica, es el profile más directamente relacionado con el comportamiento operativo de las puertas y los puntos de acceso. Puede participar en escenarios en los que un cliente necesita conocer el estado de una puerta, controlar funciones básicas y recibir eventos estandarizados.
Esto es especialmente relevante en la integración con plataformas de seguridad. En lugar de que cada fabricante represente puerta, acceso y alarma mediante una interfaz completamente propia, Profile C establece un vocabulario y servicios comunes para las funciones previstas en su especificación.
Profile C no debe confundirse con “Profile C” de otros fabricantes o denominaciones comerciales
La letra C forma parte del sistema de profiles de ONVIF. No representa una “clase C” de seguridad ni un nivel de desempeño de puerta. El diseño debe citar explícitamente ONVIF Profile C y, cuando sea necesario, las funciones del profile exigidas.
Tampoco basta con encontrar la expresión Profile C en material comercial. La conformidad oficial debe verificarse en la base de productos conformes de ONVIF para el modelo y la versión de firmware/software correspondientes.
ONVIF Profile D lleva la estandarización hasta los periféricos
ONVIF Profile D fue creado para interfaces de periféricos de control de acceso. ONVIF incluye en este universo lectores de tokens y tarjetas, credenciales móviles, lectores biométricos, cámaras utilizadas para reconocimiento, teclados, sensores, cerraduras, pantallas y LED.
La arquitectura es importante: un dispositivo Profile D captura un identificador o una solicitud de acceso y la envía a un client ubicado en una capa segura, como una unidad de control o software de gestión. El client mantiene reglas, horarios y credenciales, toma la decisión y puede devolver una acción al periférico.
Esta separación ayuda a mantener la decisión de acceso en un componente o aplicación apropiados, en lugar de suponer que todo periférico de borde almacena toda la política de acceso.
Profile D no convierte cualquier lector en una controladora autónoma
La propia especificación de Profile D diferencia el periférico de una unidad de control de acceso. Un dispositivo Profile D no necesita almacenar localmente reglas, horarios ni todas las credenciales; puede enviar identificadores al client responsable de la decisión.
Esto es relevante para el diseño porque “lector IP ONVIF” puede significar arquitecturas diferentes. El ingeniero debe definir dónde se toma la decisión, qué ocurre cuando se pierde la comunicación con el client, qué funciones locales existen y cómo se comporta la puerta en contingencia.
El profile estandariza la interfaz prevista; no elimina la necesidad de una arquitectura funcional y un análisis de disponibilidad.
A, C y D son complementarios, no versiones sucesivas del mismo recurso
No es correcto interpretar Profile D como “más nuevo y mejor” que Profile C, ni Profile A como sustituto integral de C. Los tres tienen objetivos distintos y pueden coexistir en el mismo sistema.
Una solución puede utilizar Profile A para configuración de políticas, Profile C para puertas y eventos y Profile D para periféricos. La combinación necesaria depende de los papeles de cada producto y de los flujos definidos en el diseño.
ONVIF también indica que los sistemas de control de acceso pueden utilizar otros profiles, como Profile M en determinados escenarios de metadatos y eventos. Esto no cambia el enfoque de este artículo: A, C y D constituyen el núcleo directamente orientado a configuración, control de puertas y periféricos de acceso.
Device y client deben soportar el mismo profile para la función correspondiente
La interoperabilidad ONVIF presupone papeles compatibles. Un device expone servicios; un client consume esos servicios. Para que la función estandarizada opere, ambos deben ser conformes con el profile relevante e implementar los requisitos aplicables.
Esto evita una interpretación común, pero incorrecta: “el hardware es ONVIF, por lo tanto cualquier software ONVIF funcionará”. La compatibilidad depende del profile y de la función. Un client de vídeo Profile T no sustituye un client Profile C para control de puertas solo porque ambos pertenecen al ecosistema ONVIF.
En la matriz de integración, el proyecto debería identificar al menos:
- producto o función que actúa como device;
- producto o función que actúa como client;
- profile ONVIF requerido;
- features necesarias para el caso de uso;
- funciones fuera del profile que dependerán de integración adicional;
- versión de firmware/software validada.
“Compatible con ONVIF” no es lo mismo que ser ONVIF conformant
ONVIF mantiene una base oficial de Conformant Products y declara que es la fuente autoritativa para verificar la conformidad. Un producto solo se considera oficialmente conforme cuando supera el proceso definido y está registrado con el profile correspondiente.
Además, la conformidad está vinculada a la versión específica de firmware/software registrada. Verificar únicamente el modelo y el fabricante no es suficiente cuando la versión instalada difiere de la listada.
Esta verificación debe formar parte de la revisión de submittals, análisis de equivalencia, FAT o commissioning cuando la conformidad ONVIF sea un requisito contractual.
La base oficial debe formar parte del análisis de equivalencia
Si el pliego, la especificación o el diseño exige Profile A, C o D, el proveedor debe demostrar que el modelo ofertado y la versión aplicable aparecen en la base oficial para el profile solicitado.
La simple condición del fabricante como miembro de ONVIF no demuestra conformidad de todos sus productos. La propia ONVIF advierte que la membership y las afirmaciones comerciales no sustituyen la inclusión oficial del producto.
Una matriz de conformidad puede registrar fabricante, modelo, firmware/software, profile, papel device/client, URL de la lista oficial, features condicionales relevantes y observaciones de prueba.
Los profiles definen un nivel base de interoperabilidad, no toda la solución
Los sistemas de acceso incluyen funciones que pueden estar fuera del alcance de un profile: recursos específicos de biometría, workflows de visitantes, políticas avanzadas de IAM, dashboards, funciones analíticas, automatizaciones propietarias o integraciones con ERP.
El diseño debe separar tres capas:
- funciones cubiertas por el profile ONVIF exigido;
- funciones estandarizadas por otra interfaz o norma;
- funciones que dependen de API/SDK propietario.
Esta separación reduce el riesgo de prometer una interoperabilidad que el profile no cubre y ayuda a identificar futuros puntos de vendor lock-in.
ONVIF puede reducir la dependencia de integraciones propietarias, pero no elimina el vendor lock-in por sí solo
Un profile estandarizado mejora la portabilidad en la capa que cubre. Sin embargo, el sistema completo aún puede depender de bases de datos, licencias, workflows, recursos de gestión, formatos de credenciales y extensiones específicas del fabricante.
Por ello, ONVIF debe utilizarse como criterio de arquitectura, no como eslogan de independencia tecnológica. El diseño debe mapear qué interfaces están estandarizadas y cuáles continúan siendo propietarias.
En futuras migraciones, esta documentación permite evaluar qué componentes pueden conservarse y qué integraciones deberán rehacerse.
OSDP y ONVIF actúan en capas diferentes
OSDP es un protocolo ampliamente utilizado en la comunicación entre lector y controladora mediante un enlace de campo. ONVIF trabaja con interfaces IP entre devices y clients para funciones estandarizadas de seguridad física.
Por lo tanto, un diseño puede utilizar OSDP Secure Channel entre lector y controladora y ONVIF en otra capa entre controlador, periférico IP o software de gestión. No son competidores directos.
Esta distinción evita especificaciones del tipo “OSDP u ONVIF” para la misma interfaz sin comprender la arquitectura. El criterio debe indicar qué enlace se está especificando y qué función necesita ser interoperable.
ONVIF y la integración con videovigilancia pueden coexistir en el mismo ecosistema
Las interfaces ONVIF pueden reducir integraciones propietarias, pero deben coordinarse con VMS, red, ciberseguridad y demás sistemas físicos.
El origen histórico y la amplia adopción de ONVIF en vídeo hacen natural la integración entre acceso y videovigilancia. La propia ONVIF describe combinaciones entre profiles de acceso y profiles de vídeo.
En el diseño, esto puede permitir correlacionar eventos de puerta con vídeo mediante interfaces estandarizadas en partes de la arquitectura. Sin embargo, la integración completa entre VMS y control de acceso puede requerir funciones adicionales más allá de los profiles individuales.
El artículo Videovigilancia y control de acceso: integración, VMS y criterios de diseño aborda esta integración desde la perspectiva funcional; este contenido trata específicamente la interoperabilidad ONVIF.
La ciberseguridad sigue siendo un requisito de diseño
La estandarización de interfaces no elimina los riesgos de red. Los dispositivos ONVIF son equipos IP y deben tratarse dentro de la arquitectura de seguridad: segmentación, autenticación, credenciales administrativas, TLS cuando corresponda, actualización de firmware, hardening, gestión de certificados y monitorización.
El profile define interoperabilidad para determinadas funciones, no una política completa de ciberseguridad de la instalación. ONVIF mantiene requisitos y mecanismos de seguridad en sus especificaciones, pero el nivel global de seguridad también depende de la configuración y de la arquitectura implementada.
Cómo especificar ONVIF en control de acceso sin crear un requisito vacío
Una especificación no debería limitarse a decir “compatible con ONVIF”. Puede exigir:
- conformidad oficial con Profile A, C o D según la función del componente;
- identificación clara del papel device/client;
- modelo y firmware/software listados en la base oficial de productos conformes;
- soporte de las features obligatorias y de las condicionales necesarias para el caso de uso;
- documentación de las funciones que permanecen propietarias;
- comportamiento ante pérdida de comunicación;
- requisitos de seguridad de la interfaz IP;
- evidencia de interoperabilidad en FAT y SAT;
- entrega de la matriz de conformidad y de las versiones probadas.
Este formato permite competencia sin convertir “ONVIF” en una palabra decorativa dentro de la especificación.
El FAT debe probar funciones, no solo el descubrimiento del dispositivo
Encontrar un equipo en la red o recibir una respuesta ONVIF no demuestra que las funciones necesarias para el proyecto sean interoperables. El FAT debe ejecutar casos de uso asociados al profile requerido.
Para Profile A, puede ser necesario validar la configuración de credenciales, horarios o reglas. Para Profile C, puertas, estados, comandos y eventos. Para Profile D, el intercambio entre periférico y client en las funciones contratadas.
La prueba debe registrar modelos, versiones de firmware/software, client, device, profile, función ensayada, resultado y posibles limitaciones.
El SAT debe confirmar la integración en el entorno real
En campo, la red, VLAN, firewalls, certificados, latencia, controladoras, puertas y aplicaciones reales pueden revelar problemas no observados en banco. El SAT debe repetir las funciones críticas en la topología instalada.
También es necesario verificar las actualizaciones. Si la conformidad está asociada a una versión de firmware/software y una actualización modifica componentes del sistema, el proceso de gestión de cambios debe considerar el impacto sobre la compatibilidad.
Cuándo deben incluirse Profiles A, C y D en el Diseño de Control de Acceso
Los profiles deben considerarse cuando la estrategia de interoperabilidad busque reducir la dependencia de interfaces propietarias entre componentes o plataformas que efectivamente soporten ONVIF en este ámbito.
El Diseño de Sistema de Control de Acceso debe decidir en qué interfaces la estandarización aporta valor, qué profiles son necesarios, qué funciones continúan fuera del alcance y cómo se demostrará la conformidad. Esto permite utilizar ONVIF como requisito técnico verificable y no como sustituto genérico de una arquitectura de integración.
Consideraciones finales
ONVIF en control de acceso es más específico que la expresión genérica “producto ONVIF”. Profile A trata la configuración de reglas, credenciales y horarios; Profile C, puertas, puntos de acceso, eventos y alarmas; Profile D, periféricos de acceso.
La interoperabilidad depende de profiles compatibles, papeles device/client, features necesarias y versiones realmente conformes. Cuando estos elementos se incorporan a la especificación y al FAT/SAT, ONVIF puede reducir integraciones propietarias y ampliar la libertad arquitectónica sin crear una promesa de compatibilidad más allá de lo que el estándar realmente cubre.
La conformidad oficial y la interoperabilidad funcional deben demostrarse en el FAT y confirmarse en el SAT con los modelos y versiones efectivamente instalados.
Referencias técnicas
[1] ONVIF. ONVIF Profiles — concepto de profiles e interoperabilidad. Disponible en: https://www.onvif.org/profiles/
[2] ONVIF. Profile A — For access control configuration. Disponible en: https://www.onvif.org/profiles/onvif-profile-a/
[3] ONVIF. Profile C — For door control and event management. Disponible en: https://www.onvif.org/profiles/onvif-profile-c/
[4] ONVIF. Profile D — For access control peripherals. Disponible en: https://www.onvif.org/profiles/profile-d/
[5] ONVIF. Conformant Products — base oficial de productos ONVIF conformes. Disponible en: https://www.onvif.org/conformant-products/
[6] ONVIF. Conformance Process — requisitos de conformidad por profile y versión de firmware/software. Disponible en: https://www.onvif.org/profiles/conformance/
[7] IEC. IEC 60839-11-1:2013 — Electronic access control systems — System and components requirements. Disponible en: https://webstore.iec.ch/en/publication/3662
Preguntas frecuentes
Los principales son Profile A para configuración de credenciales, horarios y reglas; Profile C para control de puertas y eventos; y Profile D para periféricos como lectores, sensores, cerraduras y dispositivos biométricos.
No. Son complementarios. Profile C trata el control de puertas y eventos; Profile D trata la interfaz de periféricos de acceso. Una solución puede utilizar ambos.
No. ONVIF considera oficialmente conformes los productos registrados en su base Conformant Products para el profile y la versión de firmware/software correspondientes.
No. OSDP normalmente actúa en la comunicación de campo entre lector y controladora, mientras ONVIF estandariza interfaces IP entre devices y clients para funciones específicas. Pueden coexistir en la misma arquitectura.
FAT y SAT deben ejecutar las funciones exigidas por el profile, registrando device, client, modelo, firmware/software, profile, caso de uso y resultado. Descubrir el dispositivo en la red no demuestra por sí solo la interoperabilidad funcional.
Materiales técnicos complementarios
Servicios relacionados
- Diseño de Sistema de Control de Acceso
- Diseño de Sistema Integrado de Seguridad Electrónica
- Commissioning de Ingeniería
