OPC DA (OPC Data Access) es la especificación de OPC clásico que permite a una aplicación leer y escribir valores de proceso en tiempo real desde servidores instalados en Windows. Se apoya en COM/DCOM de Microsoft, entrega cada valor con marca de tiempo y calidad, y es el predecesor directo de OPC-UA.
Dónde se encuentra OPC DA en planta
OPC nació en 1996 como capa de interoperabilidad sobre tecnologías Windows, y OPC DA fue durante dos décadas la forma estándar de que un SCADA, un historian o una aplicación de negocio leyeran valores de un PLC sin escribir un driver por marca. Junto a DA, la familia clásica incluye HDA para datos históricos y A&E para alarmas y eventos; cuando alguien dice «OPC» a secas suele referirse a DA. En planta se encuentra allí donde hay sistemas instalados entre finales de los noventa y la década de 2010: prácticamente todos los SCADA de esa época incorporan servidor OPC DA, y los fabricantes de autómatas distribuyeron sus drivers en ese formato. El patrón típico es un PC dedicado, con una versión antigua de Windows, que nadie toca porque de él cuelga la captura de toda una línea.
El modelo de datos es plano: el servidor expone items en un espacio de nombres jerárquico y el cliente los agrupa en groups, cada uno con su periodo de actualización y su banda muerta. La entrega puede ser por lectura directa o por notificación asíncrona cuando el valor cambia. Cada valor llega acompañado de tres cosas: el dato, la marca de tiempo y un código de calidad que distingue lectura buena, mala e incierta.
OPC DA frente a OPC-UA
La diferencia no es de versión sino de arquitectura. OPC-UA abandona COM/DCOM: funciona sobre TCP en un único puerto conocido, es multiplataforma y corre en PLCs, pasarelas Linux o servidores en nube. Incorpora seguridad en el propio estándar (certificados, firmado y cifrado de mensajes, autenticación de usuario) mientras que OPC DA delega toda la seguridad en la configuración de Windows. Y sustituye la lista plana de items por un modelo de información con tipos, unidades, jerarquía y relaciones, de modo que el consumidor sabe qué está leyendo sin una tabla de mapeo externa. La migración no es automática: los dos protocolos no se entienden entre sí. El puente habitual es un envoltorio que presenta un servidor DA existente como servidor UA, o el camino inverso, para que las aplicaciones antiguas sigan funcionando durante la transición.
Los problemas prácticos de OPC DA vienen todos de DCOM. Las notificaciones exigen que el servidor llame de vuelta al cliente, así que ambas máquinas tienen que autenticarse mutuamente: en un dominio se resuelve con cuentas comunes y, sin dominio, obliga a replicar usuarios locales con la misma contraseña en los dos equipos. El tráfico usa el mapeador de extremos en el puerto 135 más un rango dinámico de puertos altos, que ningún cortafuegos serio deja abierto y que la traducción de direcciones rompe. La detección de caída es lenta: cuando el enlace se pierde, los tiempos de espera de DCOM se miden en minutos, no en segundos. Y desde el 14 de marzo de 2023, el endurecimiento de DCOM asociado a CVE-2021-26414 impone como mínimo el nivel de autenticación de integridad de paquete, sin clave de registro que lo desactive: los clientes que no lo solicitan dejaron de conectar, lo que dejó fuera de servicio integraciones OPC clásicas que llevaban años funcionando.
Extraer datos de OPC DA hacia una capa de datos
La primera cautela es la resolución real. El periodo de actualización que se configura en el grupo OPC no acelera la captura: el servidor DA sondea el equipo con su propio ciclo de driver, así que pedir 100 ms sobre un driver que interroga el PLC cada segundo devuelve el mismo valor repetido diez veces. Antes de prometer una resolución hay que mirar el ciclo del driver y el del propio autómata, no la configuración del cliente.
La segunda es la marca de tiempo. Muchos servidores DA sellan el valor con el reloj del PC en el momento de la lectura, no en el origen; si hay varios servidores y sus relojes no están sincronizados por NTP, correlacionar eventos entre líneas deja de ser posible. La tercera, y la que más daño hace en silencio, es el código de calidad: hay que propagarlo hasta el destino. Descartar los valores malos o inciertos sin marcarlos convierte una caída de comunicaciones en una línea plana en el histórico, que después se lee como un proceso estable.
En cuanto al despliegue, el patrón que mejor envejece es evitar DCOM por completo: instalar el colector en la misma máquina Windows que aloja el servidor DA, de forma que la conversación sea local, y publicar desde ahí hacia arriba por OPC-UA o MQTT. Cuando eso no es posible, la alternativa es un túnel que sustituya DCOM por una única conexión TCP entre dos agentes, en lugar de abrir un rango dinámico de puertos entre planta y oficinas. Leer a través de un servidor DA existente no toca el proceso ni obliga a parar la línea; el riesgo está en el equipo Windows, porque instalar software en un PC de captura que lleva una década en servicio exige una imagen de respaldo previa. Conviene además restringir la escritura: OPC DA la permite, y la restricción tiene que fijarse en los permisos del servidor y en la red. Ese trabajo de puente entre sistemas heredados y capa de datos es el objeto de la integración OT/IT.
Relación con otros términos
OPC DA es el antecesor de OPC-UA y sigue siendo la vía de salida de muchos SCADA heredados hacia el historian. Su sustitución o encapsulado forma parte de cualquier proyecto de convergencia OT/IT, y en arquitecturas mixtas se resuelve con un gateway industrial que aísla el protocolo antiguo del resto del sistema.