OPC UA

Un cliente OPC UA para servidores de terceros, con confianza gobernada por certificado, direccionamiento por id de nodo y descubrimiento del espacio de direcciones.

El driver OPC UA es un cliente para servidores OPC UA de terceros: PLC, puertas de enlace, historiadores, otros sistemas SCADA, sobre opc.tcp. Es la contraparte saliente del servidor OPC UA integrado que publica el espacio de direcciones propio de esta estación (descrito en Servidor OPC UA); los dos comparten la identidad de aplicación de la estación, pero confían en sus pares por separado.

El dispositivo

Preparar el servidor

La mayoría de los servidores OPC UA rechazan de fábrica a un cliente nuevo, por dos ajustes propios, los dos hechos en el servidor:

Dónde confían los servidores comunes en el certificado de un cliente:

Cuando el servidor rechaza por cualquiera de los dos motivos, la página del dispositivo dice cuál en un aviso que ocupa el lugar del estado del servidor. Para el certificado da su nombre y su huella digital (SHA-1, la que muestran los servidores), cada uno con un botón para copiar, y el archivo con un botón que abre su carpeta. Para el usuario dice si el servidor no acepta sesiones anónimas o si rechazó al usuario, y remite al Nombre de usuario y la Contraseña del dispositivo. El aviso desaparece solo en cuanto se abre una sesión, y el registro y el agente leen la misma indicación. Esta estación emite un certificado nuevo cuando cambia su nombre de aplicación o su nombre de red, y entonces el servidor tiene que confiar en el nuevo.

La seguridad y los certificados

Conectarse empieza por la lista de endpoints del servidor: el cliente elige el endpoint más seguro que anuncia el servidor y autentica la aplicación con el certificado propio de esta estación, la misma identidad de aplicación OPC UA que usa el servidor integrado. Muchos servidores exigen que ese certificado sea de confianza de su lado antes de aceptar la sesión: Preparar el servidor dice dónde.

Un equipo que no anuncia nada mejor que un endpoint sin seguridad se rechaza, y el dispositivo dice por qué. Esa sesión llevaría las lecturas y las credenciales sin cifrar y no probaría la identidad del equipo, así que solo se abre donde usted la pidió en ese dispositivo: Seguridad de la sesión, Permitir una sesión sin seguridad, en la tarjeta de conexión. La elección pertenece a ese dispositivo, viaja en su dirección como ?security=none y vale tanto para la sesión de lectura como para el recorrido del descubrimiento. Activarla nunca rebaja a un equipo que sí ofrece seguridad: se sigue tomando el endpoint más seguro anunciado.

En el otro sentido, la confianza es cerrada por omisión y explícita. El certificado del equipo se verifica antes de que se abra la sesión:

• Un certificado que esta estación nunca ha aprobado se rechaza, se registra para revisarlo, y el panel del dispositivo muestra un aviso que nombra la aprobación que está esperando: el dispositivo no está "sin conexión", está esperando una decisión.
• Los certificados se revisan en la tarjeta Acceso a los equipos de esta página, la mitad saliente de la confianza por certificado: un certificado registrado se queda en A la espera de aprobación hasta que usted presione Aprobar (entonces se pueden abrir sesiones nuevas) o Bloquear (se rechaza sin levantar avisos repetidos). Esta es la lista de los equipos; Acceso de clientes, en el panel del Servidor OPC UA, es el otro sentido, quién puede conectarse hacia dentro, al servidor propio de esta estación.
• Retirar la aprobación, en una fila aprobada, cierra las sesiones vivas que corren sobre ese certificado y lo devuelve a la lista de revisión, para que la siguiente conexión le vuelva a preguntar.
• Un equipo que no presenta ningún certificado no prueba nada sobre quién respondió, así que no hay nada que aprobar y la sesión se rechaza, con su dirección escrita en el diario. Solo se conecta bajo ese mismo Permitir una sesión sin seguridad, que pasa a hacer las veces de la aprobación.

Aprobar el servidor de un equipo nunca autoriza a ese certificado a conectarse hacia dentro, al servidor propio de esta estación: los dos sentidos guardan almacenes separados a propósito.

El comportamiento de la sesión

Los tags se sondean: cada lectura le pregunta al servidor el valor actual del nodo. El veredicto propio del servidor viaja con cada muestra: un valor sellado como Bad o Uncertain se rechaza y el tag se lee con mala calidad, así que una fuente dudosa nunca se lava para convertirla en una lectura buena. Un nodo que ya no existe en el servidor se lee como sin valor, en lugar de hacer fallar a todo el dispositivo.

El sello del servidor también viaja con la muestra: el SourceTimestamp que le dio a un valor bueno se vuelve la Marca de tiempo de origen del tag en la página del tag. Un servidor puede conservar ese sello hasta que cambien el valor o su calidad, así que un valor estable puede mostrar un sello anterior a la Marca de tiempo de la aplicación, que siempre es el instante en que la estación recibió la lectura.

La sesión se supervisa con keep-alives; después de tres keep-alives perdidos, el cliente arranca una reconexión automática y sigue adelante. El lazo de reintentos en segundo plano de la aplicación se encarga de la conexión inicial, así que un servidor inalcanzable no cuesta nada al arrancar.

El direccionamiento del tag

Un tag se direcciona por su ID de nodo, escrito como texto libre y enviado tal cual. Las formas aceptadas son las notaciones estándar de OPC UA:

El tag lee y escribe el atributo Value del nodo.

Los tipos de valor

Los valores son solo escalares: los arreglos, las estructuras y los demás valores complejos se rechazan por ilegibles en lugar de aplanarse en un número engañoso, y el tag se lee con mala calidad. Un tag así falla por su cuenta; los demás tags del dispositivo siguen leyendo, y nada se reconecta por su causa. Una cadena vacía es un valor, no una falla. Los tipos fuera del conjunto ofrecido no están disponibles como tipo de un tag en este driver: SByte, los anchos sin signo distintos de Byte (UInt16, UInt32, UInt64), DateTime, Guid y ByteString.

Un tag de un tipo distinto al del nodo se convierte por su número, nunca se vuelve a leer a través de sus bytes, y la misma regla aplica a la lectura y a la escritura. Un real va a un real (Float y Double), y un entero a un entero de otro ancho cuando el valor cabe; un tag Boolean sobre un nodo entero lee 0 y 1 como apagado y encendido y los escribe como 0 y 1. Un valor que no cabe, o un nodo que contiene otro tipo de valor (un real para un tag entero, un número para un tag de texto), se rechaza solo en ese punto, y una escritura rechazada así nunca se envía al servidor.

Por eso un escaneo de un servidor ofrece menos canales de los que el servidor contiene: un nodo que declara una lista de valores o que contiene una cuando el escaneo lo lee, y un nodo cuyo tipo está fuera del conjunto ofrecido, se quedan fuera. Muchos servidores dejan abierta la forma declarada de una variable (un ValueRank de Any o ScalarOrOneDimension) aunque nunca contenga más que un valor, así que un nodo así se juzga por el valor que contiene cuando el escaneo lo lee, y se ofrece a menos que ese valor sea una lista. Si más adelante contiene una lista, ese tag falla por su cuenta en sus propias lecturas, como con cualquier valor que un tag no puede contener, y los demás tags del dispositivo siguen leyendo. El tipo de un nodo es el tipo básico del que deriva el tipo que declara: un nodo declarado como VersionTime contiene un UInt32 y uno declarado como UtcTime, un DateTime, así que los dos se quedan fuera, mientras que uno declarado como Duration contiene un Double y sí se ofrece. Los servidores que dejan abierta la forma suelen dejar abierto también el tipo declarado (BaseDataType, o Number, Integer o UInteger, tipos con los que ningún valor viaja), así que un nodo así toma el tipo del valor que contiene cuando el escaneo lo lee, y se ofrece o se queda fuera por ese tipo. Un nodo así cuya lectura no trae ningún valor no muestra tipo y se queda fuera. Si más adelante el servidor manda un valor de otro tipo, ese valor se lee con la regla de conversión de arriba, y ese tag solo falla donde la regla lo rechaza. Aun así no se descartan en silencio. El escaneo los cuenta y su mensaje de cierre dice cuántos y de qué tipo, por ejemplo "Se dejaron fuera 5 canales: 3 de tipo UInt32, 2 que contienen una lista de valores en lugar de un valor.", así que una lista corta se lee como una lista corta y no como un controlador pelón.

Un nodo al que el servidor responde sin ningún valor también se queda fuera, y no se cuenta: no contiene nada, e importado nunca leería. Un nodo cuyo valor regresa como Bad se sigue ofreciendo, a menos que declare una lista, o declare un tipo abierto y no traiga ningún valor del cual tomarlo: ese estado solo dice que el equipo que está detrás todavía no responde, o que la sesión anónima del escaneo no puede leerlo, y el dispositivo inicia sesión con sus propias credenciales.

Las escrituras

Un tag escribible escribe el atributo Value del nodo por el servicio Write de OPC UA. La respuesta del servidor es el veredicto: una escritura rechazada sale a la vista como una falla, y el valor en caché avanza solo cuando se acepta. Como en todos lados, el campo de escritura toma el valor de ingeniería y la cadena de conversión se deshace antes de que se envíe el valor bruto.

El descubrimiento

El comando Descubrir toma un destino en el campo que está a su lado: una dirección de servidor OPC UA como opc.tcp://plc-host:4840. El escaneo tiene dos etapas, y la línea de progreso nombra la que está corriendo:

1. Endpoints: se consulta el servicio de descubrimiento estándar del destino y cada URL de descubrimiento anunciada se convierte en un endpoint candidato. Los puertos y las rutas de servidor propios se conservan en los campos de conexión del candidato.
2. Canales: el espacio de direcciones de cada candidato se recorre desde la carpeta Objects hacia abajo, y cada variable legible se lista como un tag candidato con su tipo y su acceso, salvo los nodos que Los tipos de valor deja fuera. Las áreas de diagnóstico del servidor se saltan.

Un tag candidato recibe el nombre de su propio nodo (su BrowseName), con al frente la menor cantidad de nombres de los nodos de arriba que baste para distinguirlo de los demás canales que ofrece el servidor: Level en lugar de Devices.Simulated.Tank.Level en el servidor de otra estación, y Line1.Speed junto a Line2.Speed solo donde dos nodos llamados Speed coincidirían. Dos nombres que aun así se leerían igual, distintos solo en mayúsculas y minúsculas o en la puntuación, se distinguen con un número. La ruta completa del recorrido se queda en la tarjeta del candidato, en una segunda línea bajo el nombre, para que usted sepa qué nodo lee cada tag. El tag lee su ID de nodo, así que el nombre es solo cómo se llama: en la cuadrícula de tags y al final de su dirección (Connector.OpcUa.Peer.Level).

El recorrido inicia sesión de forma anónima (con la misma selección del endpoint más seguro, el mismo rechazo de una sesión sin seguridad y la misma compuerta del certificado del equipo). Un servidor que rechaza las sesiones anónimas, un servidor que no anuncia ningún endpoint seguro, o un recorrido que falla por cualquier motivo, deja el endpoint igual de agregable con cero tags: agréguelo, ponga las credenciales y la seguridad de la sesión en el dispositivo, y configure los tags a mano. Nada se guarda hasta que usted presione Agregar en un candidato, y cancelar conserva los candidatos que ya estaban completos.

Un servidor que ya tiene lee más de sus nodos desde la propia página de su dispositivo: Descubrir tags, en el encabezado de la tarjeta de tags, recorre el endpoint de ese dispositivo iniciando sesión como lo hace la propia sesión del dispositivo, con su nombre de usuario, su contraseña y la seguridad de su sesión, así que ahí también un servidor que rechaza las sesiones anónimas muestra sus nodos. Solo ofrece los nodos que ningún tag del dispositivo lee todavía, comparados mediante la tabla de espacios de nombres del servidor: un tag escrito con el índice de su espacio de nombres (ns=2;s=Level) lee el nodo que el recorrido nombra con la URI de su espacio de nombres (nsu=…;s=Level), así que ese nodo no se ofrece otra vez. Un servidor que rechaza la sesión termina el escaneo con la causa que da la propia sesión del dispositivo (vea Descubrir los tags de un dispositivo).

Límites que conviene conocer

• Las lecturas son sondeos del atributo Value; el driver no crea suscripciones en el servidor remoto.
• Solo valores escalares: un tag no puede direccionar un elemento de un arreglo ni un campo de una estructura.
• La compuerta de aprobación se aplica por certificado: un equipo que rota su certificado regresa a la lista de revisión y espera una decisión nueva.

Acceso a los equipos

La página del driver OPC UA termina con su tarjeta Acceso a los equipos: la mitad saliente de la confianza en los certificados. Cuando Connector marca a un servidor de equipo OPC UA, ese servidor demuestra quién es con un certificado, y la estación no lee nada de un equipo cuyo certificado usted no haya aprobado. La cabeza de la tarjeta lo dice: "Cuando el Connector llama al servidor OPC UA de un equipo, ese servidor demuestra quién es con un certificado. Apruebe solo una huella digital que haya verificado con quien puso en marcha el equipo." Ver Connector lee la tarjeta; Configurar Connector decide, y las decisiones se toman en el escritorio de la propia estación.

El principio que va bajo la cabeza: "No se lee nada de un equipo que usted no haya aprobado. Un dispositivo cuyo certificado está esperando aquí se queda callado y lo dice en Connector. Aprobarlo arranca la lectura; retirar la aprobación cierra la sesión y le vuelve a preguntar. Los nombres de los certificados los dice el equipo; la huella digital SHA-256 es la identidad que hay que verificar."

La tarjeta tiene, a propósito, la misma forma que Acceso de clientes, con las mismas palabras dondequiera que la idea sea la misma, y la misma regla sobre quién puede decidir: a un navegador de otro dispositivo le sale "El acceso a los equipos solo se puede cambiar en la aplicación de escritorio de la estación." y el aviso "Abra la aplicación de escritorio para cambiar el acceso a los equipos"; a un rol sin Configurar Connector no se le dibujan los botones, y una unidad en marcha y un cambio que ya está en curso rechazan cada uno con su propia frase. Todo desenlace aterriza en la barra de estado.

Qué hace en Connector un dispositivo en espera

La primera vez que Connector marca a un dispositivo OPC UA, el certificado del equipo se rechaza, se registra aquí como en espera, y el dispositivo no lee nada. En la página del dispositivo, Connector muestra un aviso de precaución, Esperando la aprobación del certificado, con un botón Revisar el certificado que abre esta sección en la fila de ese dispositivo, y el estado de salud del dispositivo nombra ese mismo estado en el árbol. La falla propia del driver dice el motivo en lugar de un error de saludo sin nombre: "El certificado de este equipo (los primeros 16 caracteres de la huella digital) espera su aprobación en Acceso a los equipos, en la página del driver OPC UA. La lectura empieza en cuanto lo apruebe." Uno bloqueado dice "…está bloqueado en esta estación. Revíselo en Acceso a los equipos, en la página del driver OPC UA." El recorrido de descubrimiento pasa por esa misma puerta antes de que abra su sesión.

Una vez aprobado, Connector arranca la lectura en su siguiente intento. Un equipo que estaba leyendo y que empieza a presentar un certificado distinto en la misma dirección deja de leerse y levanta una tarjeta persistente, "Certificado cambiado: <name>": "El equipo de <address> estaba leyendo con un certificado que esta estación aprobó y ahora presenta uno distinto (…), así que no se lee nada de él. Verifique la huella digital con quien mantiene el equipo y después apruébelo.", con Revisar, más una notificación de Windows cuando la ventana está escondida. Un dispositivo que se está registrando en este momento no se anuncia así: quien lo registra ya está mirando Connector.

A la espera de aprobación

Se dibuja mientras al menos un certificado espera, con el título "Estos dispositivos no se leen hasta que usted decida." y el conteo. Cada fila muestra un punto ámbar, el nombre que el certificado dice tener, "Identidad de equipo declarada", la huella digital, "<address> · Último intento <date and time> · N intentos de conexión", y un desplegable Detalles del certificado con Sujeto, Emisor, URI de aplicación, Nombres de dominio, Válido desde, Válido hasta y Visto por primera vez. La fila a la que llevó un botón Revisar queda marcada como "Seleccionado para revisión" y se desplaza a la vista.

La lista guarda como máximo 100 certificados. Mientras está llena, un certificado más se sigue rechazando pero no se retiene, y la tarjeta lo dice: "La lista de revisión de abajo está llena. Mientras lo esté, un certificado nuevo se rechaza sin llegar a agregarse aquí, así que puede que el equipo que espera no aparezca nunca. Descarte los certificados que esperan revisión para hacer espacio.", con el conteo de rechazos desde que se llenó, en cuanto haya alguno. Cada uno de esos rechazos queda registrado.

Equipos aprobados

"Certificados con los que el Connector puede abrir sesiones.", con el conteo. Cada fila muestra un punto neutro, el nombre declarado, "Identidad de equipo declarada · Aprobado por <user> el <date and time>" (o "en esta estación"), la huella digital, y un desplegable de detalles con Dirección, Sujeto, Emisor, URI de aplicación, Válido hasta y Visto por última vez. Cuando no hay ninguno: "No hay ningún certificado de equipo aprobado."

La ayuda que va bajo la cabeza: "¿Ya tiene el certificado público del equipo? Impórtelo aquí para aprobarlo antes de la primera conexión, en vez de dejar que la conexión falle una vez. Verifique la huella digital que agrega con la que figura en la documentación del equipo." Un equipo suele venir con su certificado, y por eso de este lado la importación va primero. Importar un certificado bloqueado levanta el bloqueo. Retirar la aprobación manda el certificado de regreso a la revisión, no a un bloqueo: usted pidió que se le volviera a preguntar.

Equipos bloqueados

Un desplegable plegado, "Equipos bloqueados" con el conteo, dibujado solo mientras existe al menos uno. Cada fila muestra un punto rojo, el nombre declarado, "Identidad de equipo declarada · Bloqueado por <user> el <date and time>", la huella digital, y Desbloquear, que lo regresa a la lista de revisión sin aprobarlo: "<name> está desbloqueado y volvió a la lista de revisión." Un certificado bloqueado nunca regresa por su cuenta.

Dónde viven las decisiones

Los almacenes de equipos están bajo ua\pki\southbound en la raíz de datos de la estación (pending, trusted, blocked y el rejected del SDK), con la dirección en la que se vio cada certificado, los conteos de intentos y las decisiones en equipment-access.json. Están separados de los almacenes de entrada, así que un certificado de equipo nunca puede volverse permiso para que una aplicación se conecte al propio servidor de la estación, ni aparecer como una solicitud de entrada. No son parte de una copia de seguridad de la configuración.

Lo que esta sección no hace

Nada se aprueba de forma automática, y no hay ningún ajuste que apague eso. La tarjeta no configura el dispositivo en sí (la dirección, las credenciales y el sondeo están en Connector), no muestra los valores en vivo del equipo, y no decide sobre las aplicaciones que marcan a esta estación, que es Acceso de clientes.