# 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](connector-opcua-server)); los dos comparten la
identidad de aplicación de la estación, pero confían en sus pares por separado.

## El dispositivo {#device}

| Campo | Significado | Valor inicial |
| --- | --- | --- |
| **Host o IP** | Nombre DNS, dirección IPv4 o IPv6 del servidor. Se puede pegar la URL del endpoint tal como la muestra un cliente OPC UA (`opc.tcp://192.168.0.10:4841/UA/Server`): `opc.tcp://` se descarta, el puerto pasa al campo del puerto y la ruta a la ruta del recurso. Una dirección de otro protocolo se rechaza, con el motivo debajo del campo. | vacío: el dispositivo no se conecta hasta que se indica uno |
| **Puerto** | Puerto TCP del endpoint, de 1 a 65535. Un campo vacío muestra 4840 en gris y al dispositivo se le marca por él, que es también como se lee un dispositivo guardado con 0. | 4840 |
| **Ruta del recurso** | La ruta del endpoint que algunos servidores exigen después del host y el puerto, y que produce `opc.tcp://host:puerto/ruta`. Déjela vacía cuando el servidor conteste en la raíz. | vacía |
| **Seguridad de la sesión** | Desactivada, la sesión va firmada y cifrada y un equipo que no ofrece nada mejor se rechaza. **Permitir una sesión sin seguridad** la abre de todos modos, sin cifrar, para un equipo que no anuncia ningún endpoint seguro. | desactivada |
| **Nombre de usuario** / **Contraseña** | La identidad de usuario de la sesión. Un nombre de usuario vacío significa una sesión anónima. La contraseña se protege en reposo con la DPAPI de Windows por usuario y solo se puede leer en la máquina y en la cuenta de Windows que la capturaron. | anónima |
| **Intervalo de sondeo (ms)** | El ritmo de sondeo predeterminado para los tags que no lo invaliden. | 1000 |

## Preparar el servidor {#prepare-the-server}

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:

| Ajuste en el servidor | Lo que pide | Sin él |
| --- | --- | --- |
| Confianza en el certificado de esta estación | El servidor confía en el certificado de aplicación que presenta esta estación, el mismo que presenta el [servidor OPC UA](connector-opcua-server) integrado. La estación lo guarda como un archivo `.der` en su carpeta de datos, en `ua\pki\own\certs`. | El servidor rechaza el canal seguro (`BadSecurityChecksFailed` o `BadCertificateUntrusted`) o lo cierra durante el intercambio inicial, y no se abre ninguna sesión. |
| Un usuario que acepte | El acceso anónimo permitido en el servidor, o un **Nombre de usuario** y una **Contraseña** en el dispositivo que el servidor conozca. | El servidor rechaza la sesión (`BadIdentityTokenRejected`, `BadIdentityTokenInvalid` o `BadUserAccessDenied`). |

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

| Servidor | Dónde |
| --- | --- |
| Un servidor que guarda los certificados rechazados en carpetas, como el SDK de la OPC Foundation y muchos servidores basados en él | El certificado rechazado espera en su carpeta `rejected`: muévalo a `trusted/certs`, o copie ahí el archivo de la estación. |
| KEPServerEX | Haga clic derecho en el icono **Administration** del área de notificación y elija **OPC UA Configuration**; en la pestaña Trusted Clients, seleccione el certificado y haga clic en Trust, o haga clic en **Import...** y elija el archivo; después, **Reinitialize** desde el mismo icono. |
| Siemens S7-1500, en TIA Portal | Importe el archivo en **Global security settings > Certificate manager**, pestaña **Device certificates**; en las Properties de la CPU, en **OPC UA > Server > Security > Secure Channel**, agréguelo a la lista Trusted clients con `<Add new>`; luego cárguelo en la CPU. |

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 {#security-and-certificates}

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](#prepare-the-server) 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](#equipment-access) 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](connector-opcua-server), 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 {#session-behavior}

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](connector-tags#the-live-value-card). 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 {#tag-addressing}

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:

| Ejemplo | Significado |
| --- | --- |
| `ns=2;s=Temperature` | Identificador de texto en el índice de espacio de nombres 2 |
| `ns=2;g=5f2c7a1e-8b3d-4c9a-9e61-2d4b7f0a3c58` | Identificador GUID en el índice de espacio de nombres 2 |
| `ns=3;i=1042` | Identificador numérico en el índice de espacio de nombres 3 |
| `nsu=urn:vendor:app;s=Line1.Speed` | La forma expandida, que nombra el espacio de nombres por URI en lugar de por índice: robusta frente a los cambios de índice entre reinicios |

El tag lee y escribe el atributo **Value** del nodo.

### Los tipos de valor {#value-types}

| Tipos ofrecidos |
| --- |
| Boolean, Byte, Int16, Int32, Int64, Float, Double y String |

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 {#writes}

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](connector-value-pipeline) se deshace antes de que se envíe el
valor bruto.

## El descubrimiento {#discovery}

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](#value-types) 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](connector-discovery#discovering-a-devices-tags)).

## Límites que conviene conocer {#limits-worth-knowing}

- 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 {#equipment-access}

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](connector-opcua-client-access), 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 {#what-a-waiting-device-does-in-the-connector}

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-devices), 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 {#waiting-for-approval}

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.

| Comando | Qué hace | Atenuado cuando (situación) |
| --- | --- | --- |
| Aprobar | Mueve el certificado a Equipos aprobados y refresca el validador vivo: "`<name>` queda aprobado. El Connector empieza a leer en su próximo intento." | Por la regla de arriba. |
| Bloquear | Lo mueve a Equipos bloqueados y lo sigue rechazando: "`<name>` está bloqueado. La estación seguirá rechazando este certificado." | Por la regla de arriba. |
| Descartar todos los certificados pendientes (en la cabeza del grupo) | Pregunta "¿Descartar el certificado que espera revisión?" o "¿Descartar los N certificados que esperan revisión?" ("Con esto no se aprueba nada ni se bloquea nada: las solicitudes se quitan y la lista vuelve a tener espacio. Un equipo al que el Connector llame después de esto aparece aquí como una solicitud nueva."), con **Descartar** y **Mantener la lista**. | Por la regla de arriba. |

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 {#approved-equipment}

"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."

| Comando | Qué hace | Atenuado cuando (situación) |
| --- | --- | --- |
| Importar un certificado (en la cabeza del grupo) | Abre un selector de archivos para el certificado público del equipo (`.der`, `.cer`, `.crt` o `.pem`, hasta 64 KB) y lo aprueba antes de la primera conexión: "`<name>` queda aprobado desde `<file>`. Verifique la huella digital de abajo con la que figura en la documentación del equipo." Un archivo más grande: "`<file>` es más grande que un certificado de equipo. Importe el archivo del certificado público (.der, .cer o .pem), no un archivo comprimido." | Por la regla de arriba. |
| Retirar la aprobación (en la fila, en tinta de peligro) | Pregunta "¿Retirar la aprobación de `<name>`?": "La sesión actual con este equipo se cierra y la estación deja de leerlo. El certificado vuelve a la lista de revisión, así que la próxima conexión le vuelve a preguntar.", con **Retirar** y **Mantener la aprobación**. Después: "Se retiró la aprobación de `<name>`. Su sesión se cerró y vuelve a estar a la espera de revisión." | Por la regla de arriba. |

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 {#blocked-equipment}

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 {#where-the-decisions-live}

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](settings-backups) de la configuración.

### Lo que esta sección no hace {#what-this-section-does-not-do}

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](connector-devices)), 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](connector-opcua-client-access).