OPC UA

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

El controlador OPC UA es un cliente de servidores OPC UA de terceros (autómatas, pasarelas, historiadores, otros sistemas SCADA) sobre opc.tcp. Es la contrapartida 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 interlocutores por separado.

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.

Seguridad y certificados

Conectar empieza por la lista de endpoints del servidor: el cliente elige el endpoint más seguro que el servidor anuncia 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 esté aprobado en 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 explícita y cerrada por defecto. El certificado del equipo se comprueba antes de que se abra la sesión:

• Un certificado que esta estación nunca ha aprobado se rechaza, se anota para revisarlo, y el panel del dispositivo muestra un aviso que nombra la aprobación que espera: 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 anotado se queda en A la espera de aprobación hasta que usted pulse Aprobar (ya pueden abrirse sesiones nuevas) o Bloquear (se rechaza sin volver a preguntar una y otra vez). 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 con ese certificado y lo devuelve a la lista de revisión, así que la próxima conexión le vuelve 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 mantienen almacenes separados a propósito.

El comportamiento de la sesión

Los tags se sondean: cada lectura pregunta al servidor por el valor actual del nodo. El veredicto del propio servidor viaja con cada muestra: un valor sellado como Malo o Incierto se rechaza y el tag se lee con mala calidad, así que un origen dudoso nunca se blanquea en una lectura buena. Un nodo que ya no existe en el servidor se lee como sin valor, en lugar de tumbar el dispositivo entero.

El sello del servidor también viaja con la muestra: el SourceTimestamp que dio a un valor bueno se convierte en 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 es siempre el instante en que la estación recibió la lectura.

La sesión se supervisa con mensajes de mantenimiento; tras tres de ellos perdidos, el cliente arranca una reconexión automática y sigue adelante. El bucle de reintento en segundo plano de la aplicación es el dueño de la conexión inicial, así que un servidor inalcanzable no cuesta nada en el arranque.

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 OPC UA estándar:

El tag lee y escribe el atributo Value del nodo.

Tipos de valor

Los valores son solo escalares: las matrices, las estructuras y otros valores complejos se rechazan como 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 él. Una cadena vacía es un valor, no un fallo. Los tipos que quedan fuera del conjunto ofrecido no están disponibles como tipo de un tag en este controlador: 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 vale para la lectura y 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 otra clase 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.

Una exploración de un servidor ofrece, por tanto, menos canales de los que el servidor tiene: se queda fuera un nodo que declara una lista de valores o que contiene una cuando la exploración lo lee, y también un nodo cuyo tipo queda fuera del conjunto ofrecido. 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 la exploración lo lee, y se ofrece salvo 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 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 la exploración 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 envía 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. Pero no se descartan en silencio. La exploración 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 vez de un valor.", para que una lista corta se lea como una lista corta y no como un autómata pelado.

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

Escrituras

Un tag con escritura escribe el atributo Value del nodo por el servicio Write de OPC UA. La respuesta del servidor es el veredicto: una escritura rechazada aflora como un fallo, y el valor en caché solo avanza si se acepta. Como en todas partes, 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.

Descubrimiento

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

1. Endpoints: se pregunta al servicio de descubrimiento estándar del destino y toda URL de descubrimiento anunciada se convierte en un endpoint candidato. Los puertos y las rutas de servidor personalizados van y vuelven hacia 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 toda variable legible se lista como un tag candidato con su tipo y su acceso, salvo los nodos que 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 delante los menos nombres de los nodos de arriba que basten 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 queda en la tarjeta del candidato, en una segunda línea bajo el nombre, para que se 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 rejilla 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 elección del endpoint más seguro, el mismo rechazo de una sesión sin seguridad y la misma puerta 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 igualmente añadible con cero tags: añádalo, ponga las credenciales y la seguridad de la sesión en el dispositivo y configure los tags a mano. Nada se guarda hasta que se pulsa Añadir 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 la cabecera 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 allí 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 la exploración 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 controlador no crea suscripciones en el servidor remoto.
• Solo valores escalares: un tag no puede direccionar un elemento de una matriz ni un campo de una estructura.
• La puerta de aprobación se aplica por certificado: un equipo que rota su certificado vuelve a la lista de revisión y espera una decisión nueva.

Acceso a los equipos

La página del controlador OPC UA termina con su tarjeta Acceso a los equipos: la mitad saliente de la confianza en los certificados. Cuando el Connector llama al servidor OPC UA de un equipo, 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 cabecera 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 comprobado 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, bajo la cabecera: "No se lee nada de un equipo que usted no haya aprobado. Un dispositivo cuyo certificado espera aquí se queda callado y lo dice en el Connector. Aprobarlo pone en marcha la lectura; retirar la aprobación cierra la sesión y vuelve a preguntarle. Los nombres de los certificados los declara el propio equipo; la identidad que hay que verificar es la huella digital SHA-256."

La tarjeta tiene a propósito la misma forma que Acceso de clientes, con las mismas palabras siempre que la idea es la misma, y la misma regla sobre quién puede decidir: un navegador de otro dispositivo ve "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 ya en curso rechazan cada uno con su propia frase. Todos los desenlaces aterrizan en la barra de estado.

Qué hace en el Connector un dispositivo que espera

La primera vez que el Connector llama a un dispositivo OPC UA, el certificado del equipo se rechaza, se anota aquí como a la espera, y el dispositivo no lee nada. En la página del dispositivo, el 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 la salud del dispositivo nombra el mismo estado en el árbol. El fallo propio del controlador dice el motivo en lugar de un error de negociación 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 controlador 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 controlador OPC UA." El recorrido de descubrimiento pasa por la misma puerta antes de abrir su sesión.

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

A la espera de aprobación

Se dibuja mientras hay al menos un certificado esperando, encabezado por "Estos dispositivos no se leen hasta que usted decida." con el recuento. Cada fila muestra un punto ámbar, el nombre que declara el certificado, "Identidad de equipo declarada", la huella digital, "<dirección> · Último intento <fecha y hora> · N intentos de conexión", y un desplegable de Detalles del certificado con Sujeto, Emisor, URI de la 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 se marca como "Seleccionado para revisión" y se desplaza a la vista.

La lista guarda como mucho 100 certificados. Mientras está llena, un certificado más se sigue rechazando pero no se conserva, 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 añadirse aquí, así que puede que el equipo que espera no aparezca nunca. Descarte los certificados que esperan revisión para hacer sitio.", con el recuento de rechazos desde que se llenó en cuanto hay alguno. Cada uno de esos rechazos se anota en el diario.

Equipos aprobados

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

La indicación de debajo de la cabecera: "¿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. Compruebe la huella digital que añade con la que figura en la documentación del equipo." Un equipo suele venir con su certificado, y por eso este lado tiene la importación por delante. Importar un certificado bloqueado levanta el bloqueo. Retirar la aprobación devuelve el certificado a la revisión, no a un bloqueo: usted pidió que le volvieran a preguntar.

Equipos bloqueados

Un desplegable contraído, "Equipos bloqueados" con el recuento, dibujado solo mientras existe al menos uno. Cada fila muestra un punto rojo, el nombre declarado, "Identidad de equipo declarada · Bloqueado por <usuario> el <fecha y hora>", la huella digital, y Desbloquear, que lo devuelve a la lista de revisión sin aprobarlo: "<nombre> está desbloqueado y ha vuelto a la lista de revisión." Un certificado bloqueado no vuelve nunca 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 recuentos de intentos y las decisiones en equipment-access.json. Están separados de los almacenes entrantes, así que el certificado de un equipo no puede convertirse nunca en permiso para que una aplicación se conecte al propio servidor de la estación, ni aparecer como una petición entrante. No forman parte de una copia de seguridad de la configuración.

Lo que esta sección no hace

No se aprueba nada automáticamente, y no hay ningún ajuste que lo desactive. La tarjeta no configura el dispositivo en sí (la dirección, las credenciales y el sondeo están en el Connector), no muestra los valores en tiempo real del equipo, y no decide sobre las aplicaciones que llaman a esta estación, que es Acceso de clientes.