OPC DA frente a OPC UA: diferencias y migración

Al sustituir un historiador o HMI OPC DA por uno OPC UA, una instalación descubre que el cliente nuevo no puede abrir el servidor antiguo. Hace falta un componente que traduzca entre ambos. Su elección determina si, después del cambio, siguen siendo necesarios un equipo Windows y un servidor COM en la instalación.

OPC DA (Data Access) utiliza COM de Microsoft en un mismo equipo y DCOM entre equipos. La conexión empieza en TCP 135, el asignador de endpoints RPC, y continúa por un puerto asignado dinámicamente. En Windows Vista, Windows Server 2008 y posteriores, el intervalo predeterminado va de 49152 a 65535. Una suscripción DA también devuelve datos del servidor al cliente, de modo que el cortafuegos debe permitir DCOM en ambos sentidos.

El refuerzo de seguridad DCOM de Microsoft para CVE-2021-26414 (KB5004442) exige ahora autenticación con integridad de paquetes (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY) para activar DCOM. Está activado por defecto desde el 14 de junio de 2022 y no puede desactivarse desde el 14 de marzo de 2023. Un cliente Windows actualizado eleva automáticamente su nivel. Un cliente en un equipo sin actualizar o con una implementación DCOM ajena a Windows no puede activar el servidor. El servidor registra el evento 10036 y el cliente el 10037 o el 10038. Los enlaces DA remotos que nunca se prepararon para este nivel dejaron de funcionar; es un motivo habitual para iniciar la migración.

OPC UA utiliza un protocolo binario por un único puerto TCP, 4840 por defecto, con certificados de aplicación X.509. Funciona en cualquier sistema operativo.

Qué incluye OPC Classic

Cada especificación Classic tiene su propio espacio de direcciones y servicios. OPC UA reúne las tres en un espacio de direcciones con un único conjunto de servicios (OPC 10000-1, cláusula 4.3).

Enumere cuáles utiliza el sistema actual. Un adaptador DA traslada solo valores actuales. No traslada confirmaciones de alarmas ni consultas históricas.

A&E requiere especial atención. El anexo D de la parte 9 asocia categorías de eventos A&E con tipos de eventos UA cuando el adaptador conoce su significado. Por ejemplo, una condición Level llamada HI HI puede convertirse en NonExclusiveLevelAlarmType. El anexo no define una correspondencia genérica para subcondiciones A&E: configure el adaptador para cada categoría de alarma que utilizan los operadores y compruebe el resultado.

Tres formas de migrar

OPC Foundation publica componentes de muestra COM UA Wrapper y COM UA Proxy (parte 8, A.1). Los productos comerciales usan esos términos sin precisión. Un «túnel OPC», por ejemplo, suele transportar DA entre dos equipos sin DCOM, pero entrega DA en ambos extremos: resuelve DCOM sin proporcionar un servidor UA. Documente las funciones de cliente y servidor a ambos lados de cada producto.

Un adaptador mantiene las dependencias antiguas: equipo Windows, servidor DA y licencia, cuentas de servicio y orden de arranque. Instálelo en el mismo equipo que el servidor DA. Así COM permanece local y no cruza la red tráfico DCOM. Asigne un responsable al equipo y un calendario de actualizaciones.

Pruebe el orden de arranque. Tras reiniciar Windows, el servicio del adaptador puede arrancar antes de que esté listo el servidor DA. Algunos adaptadores no reintentan la conexión y sus puntos permanecen Bad hasta que alguien reinicia el adaptador.

La versión DA del servidor antiguo determina qué puede hacer el adaptador (parte 8, A.3.3 y A.3.4). Con DA 2.05a, cada UA Read consulta el dispositivo y el adaptador ignora maxAge. Una escritura UA con código de estado o marca temporal falla con Bad_WriteNotSupported. Con DA 3.0, una lectura puede venir del dispositivo o de la caché del servidor, según maxAge. Una escritura puede incluir valor, calidad y marca temporal juntos.

Asocie los puntos DA con nodos UA

Construya la correspondencia punto por punto:

La parte 8, A.3.1.5 describe tres formas de construir un NodeId. Un adaptador que navega por todo el espacio DA y conserva una copia sin conexión puede usar ItemID como identificador. Otro que divide cada ItemID según un separador configurado puede hacer lo mismo, pero solo si los ItemID del servidor son rutas. Un tercer tipo codifica juntos ItemID y nombre del punto en el NodeId; entonces deja de coincidir con ItemID y resulta difícil relacionarlos manualmente.

Por ejemplo, el punto DA BoilerA.Flow puede convertirse en ns=2;s=BoilerA.Flow. El 2 es una posición en NamespaceArray del servidor, no un nombre fijo. El índice puede cambiar con la configuración del adaptador, pero la URI del espacio de nombres permanece. Guarde la URI y el identificador de cada punto y resuelva el índice cada vez que el cliente se conecte. La guía de identidad de nodos lo explica. Incluya la configuración del adaptador en el paquete de reversión: si se reconstruye con otros identificadores, fallan todos los consumidores.

Compruebe los tipos de datos de la tabla A.2 de la parte 8. La mayoría corresponden directamente, como VT_R4 a Float y VT_I4 a Int32. VT_DATE se convierte en Double, no en DateTime. Por eso una fecha DA llega como número de días desde el 30 de diciembre de 1899, y un consumidor que espera una marca temporal muestra un número como 46289,5.

Un punto con propiedades High EU y Low EU se convierte en AnalogItemType con EURange y EngineeringUnits. Compruebe la escala de extremo a extremo. Un caudal de 21,7 m³/h no debe convertirse en 2,17 porque el nuevo recopilador repite una conversión que ya hizo el servidor DA.

Calidad y hora

Un valor DA tiene un código de calidad de 16 bits. El byte bajo adopta la forma QQSSSSLL: dos bits de calidad principal, cuatro de subestado y dos bits de límite. El byte alto es específico del fabricante. Son valores habituales del byte bajo 0xC0 (Good), 0x40 (Uncertain) y 0x00 (Bad).

Un valor UA tiene un StatusCode de 32 bits. Los dos bits superiores indican la gravedad: 0x00000000 es Good, 0x40000000 Uncertain y 0x80000000 Bad. La parte 8, A.3.2.3 asigna la calidad principal DA a la gravedad, el subestado al subcódigo y los bits de límite a los bits de límite. Descarta el byte del fabricante.

Dos filas requieren atención. Primero, se pierde el byte del fabricante. Si un servidor DA marca un valor introducido a mano mediante un bit del byte alto, por ejemplo calidad 0x80C0, el valor adaptado llega como Good sin esa indicación. Segundo, la tabla A.3 asigna «último valor conocido» de DA a Bad_OutOfService. Un consumidor que interpreta OutOfService como «desactivado intencionadamente» informa entonces de un fallo de comunicación como si fuera una parada prevista. La parte 8, A.1 permite correspondencias específicas del fabricante: consulte también la documentación del adaptador. Si una aplicación usa el byte del fabricante, acuerde otra forma de transportarlo o acepte por escrito su pérdida.

Para la hora, el adaptador usa la marca temporal DA como SourceTimestamp UA y establece ServerTimestamp en el momento en que comenzó la lectura (parte 8, A.3.2.4). Normalmente la marca DA corresponde a cuando el servidor DA recibió por última vez el valor del dispositivo; no es la hora de muestreo del sensor salvo que el sistema de origen la defina así.

El adaptador puede ofrecer un estado UA detallado que el siguiente recopilador descarta. Compruebe el registro en el historiador o sistema analítico, no solo en el adaptador. Decida antes del cambio cómo afectan los valores obsoletos, ausentes y no válidos a gráficas, totales y alarmas.

Frecuencias de actualización y bandas muertas

Un cliente DA configura una frecuencia de actualización y una banda muerta porcentual para cada grupo. El servidor llama al cliente cuando cambia un valor. En el adaptador de OPC Foundation, un MonitoredItem UA crea la suscripción DA. SamplingInterval y la banda muerta UA configuran esas notificaciones DA (parte 8, A.3.5).

El adaptador solo admite el filtro PercentDeadband. Una banda muerta porcentual se calcula sobre EURange, por lo que requiere un punto con High EU y Low EU en el servidor DA. Si no existen, no hay EURange y no puede aplicarse el filtro.

Un cliente que consulta periódicamente mediante el servicio UA Read no utiliza nada de esto. Obtiene un valor por punto en cada consulta. Con un servidor DA 2.05a detrás del adaptador, cada consulta también lee el dispositivo; dimensione el intervalo según la carga del servidor DA y su red de campo.

Seguridad en ambos lados

En el lado UA, configure el endpoint con SignAndEncrypt y una política vigente, como Basic256Sha256, Aes128_Sha256_RsaOaep o Aes256_Sha256_RsaPss. No acepte None aunque el adaptador lo ofrezca. Configure la confianza de certificados de aplicación en ambos sentidos y dé al usuario del cliente solo las operaciones necesarias. La parte 2 describe este modelo.

Los certificados tienen periodo de validez y por eso importan los relojes. Un certificado caducado, o todavía no válido por un reloj incorrecto, provoca Bad_CertificateTimeInvalid. El cliente deja de leer hasta que se renueva o se corrige el reloj. Incluya el vencimiento de cada certificado de aplicación en el plan de mantenimiento.

En el lado DA, COM DA no tiene una identidad de usuario propia (parte 8, A.2). Un adaptador puede aceptar usuario y contraseña UA y suplantar a ese usuario Windows antes de conectarse al servidor DA. Muchos adaptadores se conectan con su propia cuenta de servicio. Registre qué cuenta Windows ve el servidor DA y qué puede escribir. Si un enlace DA sigue siendo remoto, debe cumplir la exigencia de integridad de paquetes DCOM anterior.

No resuelva un problema de puesta en marcha desactivando la seguridad ni convirtiendo una cuenta de lectura en una cuenta con permiso de escritura.

Pruebe el cambio

Pruebe un punto de cada tipo de datos antes de migrar el resto. Incluya un valor analógico escalado, uno booleano, una cadena y, si existen en el proyecto, una matriz y una fecha. Para cada punto:

1. Registre la URI de espacio de nombres y el NodeId creados por el adaptador.
2. Lea el valor por DA y UA dentro de un mismo periodo de consulta DA y compárelos. Busque escalados duplicados.
3. Con autorización, detenga el dispositivo o su controlador. Registre la calidad DA, el StatusCode UA y lo que muestra el consumidor final. El último valor no debe aparecer como una muestra Good nueva.
4. Reinicie el equipo del adaptador. Confirme que los puntos vuelven a Good sin alterar la lista y mida cuánto tardan.
5. Intente leer un ItemID inexistente y escribir en un punto sin permiso. Espere Bad_NodeIdUnknown y Bad_NotWritable.

Después, mantenga las dos rutas en paralelo al menos durante un ciclo operativo completo, como un turno, un lote o una semana. Incluya un reinicio planificado del origen. La ruta DA informa de cambios con una banda muerta y el cliente UA puede consultar periódicamente, así que producirán cantidades distintas de mensajes. Compare los valores y la antigüedad del más reciente en cada momento. Acuerde la diferencia y el tiempo de recuperación permitidos antes de probar.

Mantenga separado el control. No permita que las rutas antigua y nueva envíen órdenes al mismo equipo a la vez, y compruebe el resultado físico de cada escritura. La guía de matrices de prioridades BACnet muestra cómo una orden compartida puede durar más que su responsable.

OPC UA con Edge

Edge en el Gateway ZGW-20 es un cliente OPC UA. Se conecta hasta a cinco endpoints opc.tcp, nativos o adaptados, pero no a OPC DA. Un sistema que solo ofrece DA necesita primero un adaptador.

Edge lee cada punto con el servicio Read según una programación, desde una vez por segundo hasta una vez al día. No crea suscripciones, por lo que no se aplican las reglas de bandas muertas anteriores. Marca cada valor con la hora de lectura programada del Gateway, no con SourceTimestamp. También aplica su propio multiplicador y desplazamiento por punto: configúrelos en 1 y 0 cuando el servidor DA ya haya escalado el valor.

Edge admite None, Sign y SignAndEncrypt, y cada nuevo endpoint comienza en None. Configure usted mismo SignAndEncrypt con Basic256Sha256 o una política Aes y mantenga correcto el reloj del Gateway para las comprobaciones de certificados.