# OPC UA

> Um cliente OPC UA para servidores de terceiros, com confiança condicionada a certificado, endereçamento por node id e descoberta do espaço de endereços.

O driver OPC UA é um **cliente** para servidores OPC UA de terceiros (CLPs, gateways,
historiadores, outros sistemas SCADA) sobre `opc.tcp`. Ele é a contraparte de saída do
servidor OPC UA embutido que publica o espaço de endereços desta estação (descrito em
[Servidor OPC UA](connector-opcua-server)); os dois compartilham a identidade de aplicação da
estação, mas confiam nos seus pares de forma independente.

## Dispositivo {#device}

| Campo | Significado | Padrão |
| --- | --- | --- |
| **Host ou IP** | Nome DNS, endereço IPv4 ou IPv6 do servidor. Dá para colar a URL do endpoint como um cliente OPC UA a mostra (`opc.tcp://192.168.0.10:4841/UA/Server`): o `opc.tcp://` sai, a porta vai para o campo da porta e o caminho para o caminho do recurso. Um endereço de outro protocolo é recusado, com o motivo embaixo do campo. | vazio: o dispositivo não é conectado até um ser informado |
| **Porta** | Porta TCP do endpoint, de 1 a 65535. Um campo vazio mostra 4840 em cinza e o dispositivo é chamado nela, que é também como se lê um dispositivo salvo com 0. | 4840 |
| **Caminho do recurso** | O caminho de endpoint que alguns servidores exigem depois do host e da porta, produzindo `opc.tcp://host:port/path`. Deixe vazio quando o servidor responde na raiz. | vazio |
| **Segurança da sessão** | Desligada, a sessão vai assinada e criptografada e um equipamento que não oferece nada melhor é recusado. **Permitir sessão sem segurança** abre a sessão mesmo assim, em claro, para um equipamento que não anuncia nenhum endpoint seguro. | desligada |
| **Usuário** / **Senha** | A identidade de usuário da sessão. Usuário vazio significa sessão anônima. A senha fica protegida em repouso pela DPAPI do Windows por usuário e só pode ser lida na máquina e na conta do Windows que a digitaram. | anônima |
| **Intervalo de leitura (ms)** | Taxa de leitura padrão para as tags que não a sobrepõem. | 1000 |

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

A maioria dos servidores OPC UA recusa de fábrica um cliente novo, por dois ajustes
próprios, os dois feitos no servidor:

| Ajuste no servidor | O que pede | Sem ele |
| --- | --- | --- |
| Confiança no certificado desta estação | O servidor confia no certificado de aplicação que esta estação apresenta, o mesmo que o [servidor OPC UA](connector-opcua-server) embutido apresenta. A estação guarda esse certificado como um arquivo `.der` na raiz de dados dela, em `ua\pki\own\certs`. | O servidor recusa o canal seguro (`BadSecurityChecksFailed` ou `BadCertificateUntrusted`) ou o fecha durante o handshake, e nenhuma sessão abre. |
| Um usuário que ele aceite | O acesso anônimo permitido no servidor, ou um **Usuário** e uma **Senha** no dispositivo que o servidor conheça. | O servidor recusa a sessão (`BadIdentityTokenRejected`, `BadIdentityTokenInvalid` ou `BadUserAccessDenied`). |

Onde os servidores mais comuns confiam no certificado de um cliente:

| Servidor | Onde |
| --- | --- |
| Um servidor que guarda os certificados recusados em pastas, como o SDK da OPC Foundation e muitos servidores feitos sobre ele | O certificado recusado espera na pasta `rejected` dele: mova-o para `trusted/certs`, ou copie o arquivo da estação para lá. |
| KEPServerEX | Clique com o botão direito no ícone **Administration** da área de notificação e escolha **OPC UA Configuration**; na aba Trusted Clients, selecione o certificado e clique em Trust, ou clique em **Import...** e escolha o arquivo; depois, **Reinitialize** no mesmo ícone. |
| Siemens S7-1500, no TIA Portal | Importe o arquivo em **Global security settings > Certificate manager**, aba **Device certificates**; nas Properties da CPU, em **OPC UA > Server > Security > Secure Channel**, acrescente-o à lista Trusted clients com `<Add new>`; depois faça o download para a CPU. |

Quando o servidor recusa por um dos dois motivos, a página do dispositivo diz qual num
aviso que fica no lugar do status do servidor. Para o certificado, ele dá o nome e a
impressão digital (SHA-1, a que os servidores listam), cada um com um botão de copiar, e
o arquivo com um botão que abre a pasta dele. Para o usuário, diz se o servidor não
aceita sessão anônima ou se recusou o usuário, e aponta para o **Usuário** e a **Senha**
do dispositivo. O aviso some sozinho assim que uma sessão abre, e o diário e o agente
leem a mesma instrução. Esta estação emite um certificado novo quando o nome de
aplicação ou o nome de rede dela muda, e o servidor então tem que confiar no novo.

## Segurança e certificados {#security-and-certificates}

Conectar começa pela lista de endpoints do servidor: o cliente escolhe o **endpoint mais
seguro que o servidor anuncia** e autentica a aplicação com o certificado da própria
estação, a mesma identidade de aplicação OPC UA que o servidor embutido usa. Muitos
servidores exigem que esse certificado seja confiável do lado deles antes de aceitarem a
sessão: [Preparar o servidor](#prepare-the-server) diz onde.

Um equipamento que não anuncia nada melhor do que um **endpoint sem segurança** é recusado,
e o dispositivo diz por quê. Aquela sessão levaria as leituras e a identificação em claro e
não provaria a identidade do equipamento, então ela só abre onde você pediu isso naquele
dispositivo: **Segurança da sessão**, **Permitir sessão sem segurança**, no cartão de
conexão. A escolha pertence àquele dispositivo, viaja no endereço dele como
`?security=none` e vale tanto para a sessão de leitura quanto para a navegação da
descoberta. Ligá-la nunca rebaixa um equipamento que oferece segurança: o endpoint mais
seguro anunciado continua sendo o escolhido.

No outro sentido, a confiança é **fechada por padrão e explícita**. O certificado do
equipamento é conferido antes de a sessão abrir:

- Um certificado que esta estação nunca aprovou é recusado, registrado para revisão,
  e o painel do dispositivo mostra um aviso nomeando a aprovação que ele espera:
  o dispositivo não está "offline", ele está esperando uma decisão.
- Você revisa certificados no cartão [Acesso a equipamentos](#equipment-access) desta página,
  a metade de saída da confiança em certificados: um certificado registrado fica em
  **Esperando aprovação** até você **Aprovar** (sessões novas podem abrir) ou **Bloquear**
  (recusado sem levantar avisos repetidos). Esta é a lista de equipamentos; o
  **Acesso de clientes**, no painel do [Servidor OPC UA](connector-opcua-server), é o outro
  sentido, quem pode conectar de fora ao servidor da própria estação.
- **Retirar a aprovação**, numa linha aprovada, encerra as sessões vivas que rodam sobre
  aquele certificado e o devolve à lista de revisão, para que a próxima conexão pergunte
  de novo.
- Um equipamento que apresenta **nenhum certificado** não prova nada sobre quem respondeu,
  então não há o que aprovar e a sessão é recusada, com o endereço dela escrito no diário.
  Ele só conecta sob o mesmo **Permitir sessão sem segurança**, que passa a ser o que faz
  as vezes da aprovação.

Aprovar o servidor de um equipamento nunca autoriza aquele certificado a conectar de fora
ao servidor da própria estação: os dois sentidos mantêm depósitos separados de propósito.

## Comportamento da sessão {#session-behavior}

As tags são **lidas ciclicamente**: cada leitura pergunta ao servidor o valor atual do nó. O
veredito do próprio servidor viaja com toda amostra: um valor carimbado como Bad ou
Uncertain é recusado e a tag lê qualidade ruim, então uma origem duvidosa
nunca é lavada e transformada numa leitura boa. Um nó que não existe mais no servidor
lê como sem valor, em vez de fazer o dispositivo inteiro falhar.

O carimbo do servidor também viaja com a amostra: o SourceTimestamp que ele deu a um valor bom vira o **Carimbo de tempo da origem** da tag na [página da tag](connector-tags#the-live-value-card). Um servidor pode manter esse carimbo até o valor ou a qualidade mudar, então um valor estável pode mostrar um carimbo anterior ao **Carimbo de tempo do aplicativo**, que é sempre o instante em que a estação recebeu a leitura.

A sessão é supervisionada por keep-alives; depois de três keep-alives perdidos, o
cliente inicia uma reconexão automática e segue em frente. O laço de tentativas em segundo
plano da aplicação é dono da conexão inicial, então um servidor inalcançável não custa nada na
inicialização.

## Endereçamento da tag {#tag-addressing}

Uma tag é endereçada pelo **ID do nó** dela, digitado como texto livre e enviado literalmente.
As formas aceitas são as notações padrão do OPC UA:

| Exemplo | Significado |
| --- | --- |
| `ns=2;s=Temperature` | Identificador de texto no índice de namespace 2 |
| `ns=2;g=5f2c7a1e-8b3d-4c9a-9e61-2d4b7f0a3c58` | Identificador GUID no índice de namespace 2 |
| `ns=3;i=1042` | Identificador numérico no índice de namespace 3 |
| `nsu=urn:vendor:app;s=Line1.Speed` | Forma expandida, que nomeia o namespace por URI em vez de índice, robusta contra mudanças de índice entre reinícios |

A tag lê e escreve o atributo **Value** do nó.

### Tipos de valor {#value-types}

| Tipos oferecidos |
| --- |
| Boolean, Byte, Int16, Int32, Int64, Float, Double, String (oito ao todo) |

Os valores são **apenas escalares**: vetores, estruturas e outros valores complexos são
recusados como ilegíveis em vez de achatados num número enganoso, e a
tag lê qualidade ruim. Uma tag assim falha sozinha; as outras tags do dispositivo
seguem lendo, e nada é reconectado por causa dela. Um texto vazio é um valor, não
uma falha. Tipos fora do conjunto oferecido não estão disponíveis como tipo de uma
tag neste driver: SByte, as larguras sem sinal além de Byte (UInt16, UInt32, UInt64),
DateTime, Guid e ByteString.

Uma tag de tipo diferente do nó é convertida pelo número, nunca relida pelos bytes, e a mesma
regra vale para leitura e escrita. Um real vai para um real (Float e Double), e um inteiro para
um inteiro de outra largura quando o valor cabe; uma tag Boolean sobre um nó inteiro lê 0 e 1
como desligado e ligado e os escreve como 0 e 1. Um valor que não cabe, ou um nó que guarda
outro tipo de valor (um real para uma tag inteira, um número para uma tag de texto), é recusado
só naquele ponto, e uma escrita recusada assim nunca é enviada ao servidor.

Uma varredura de um servidor, portanto, oferece menos canais do que o servidor guarda: um nó
que declara uma lista de valores ou que guarda uma quando a varredura o lê, e um nó cujo
tipo está fora do conjunto oferecido, ficam de fora. Muitos servidores deixam aberta a forma
declarada de uma variável (um ValueRank Any ou ScalarOrOneDimension) mesmo quando ela nunca
guarda mais que um valor; um nó assim é julgado pelo valor que guarda quando a varredura o
lê, e é oferecido a menos que esse valor seja uma lista. Se mais tarde ele guardar uma lista,
aquela tag falha sozinha nas próprias leituras, como acontece com qualquer valor que uma tag
não consegue guardar, e as outras tags do dispositivo seguem lendo. O tipo de um nó é o tipo
básico do qual deriva o tipo que ele declara:
um nó declarado como VersionTime guarda um UInt32 e um declarado como UtcTime, um
DateTime, então os dois ficam de fora, enquanto um declarado como Duration guarda um
Double e é oferecido. Servidores que deixam a forma aberta muitas vezes deixam aberto também
o tipo declarado (BaseDataType, ou Number, Integer ou UInteger, tipos com que nenhum valor
viaja); um nó assim assume o tipo do valor que guarda quando a varredura o lê, e é oferecido
ou fica de fora por esse tipo. Um nó assim cuja leitura não traz valor nenhum não mostra tipo
e fica de fora. Se mais tarde o servidor mandar um valor de outro tipo, esse valor é lido pela
regra de conversão acima, e aquela tag só falha onde a regra o recusa.
Eles não são descartados em silêncio, porém. A varredura os conta e
a mensagem final dela diz quantos e de qual tipo, por exemplo "5 canais
ficaram de fora: 3 do tipo UInt32, 2 que guardam uma lista de valores em vez de um
valor único.", para que uma lista curta seja lida como uma lista curta, e não como um controlador vazio.

Um nó que o servidor responde sem valor nenhum também fica de fora, e não é contado:
ele não guarda nada, e importado nunca leria. Um nó cujo valor volta como Bad continua
sendo oferecido, a menos que declare uma lista, ou declare um tipo aberto e não traga valor
nenhum de onde tirar um: esse status só diz que o equipamento por trás dele ainda não respondeu,
ou que a sessão anônima da varredura não pode lê-lo, e o dispositivo se autentica com as
próprias credenciais.

## Escritas {#writes}

Uma tag gravável escreve o atributo Value do nó pelo serviço Write do OPC UA.
A resposta do servidor é o veredito: uma escrita rejeitada aparece como
falha, e o valor cacheado só avança quando ela é aceita. Como em todo lugar, o
campo de escrita recebe o valor de engenharia e a [cadeia de valor](connector-value-pipeline) é
revertida antes de o valor bruto ser enviado.

## Descoberta {#discovery}

O comando **Descobrir** recebe um alvo no campo ao lado dele: um endereço de servidor
OPC UA como `opc.tcp://plc-host:4840`. A varredura tem dois estágios, e a
linha de progresso nomeia o que está rodando:

1. **Endpoints**: o serviço de descoberta padrão do alvo é consultado e toda
   URL de descoberta anunciada vira um endpoint candidato. Portas e caminhos de
   servidor personalizados vão e voltam nos campos de conexão do candidato.
2. **Canais**: o espaço de endereços de cada candidato é navegado a partir da pasta
   Objects para baixo, e toda variável legível é listada como tag candidata com
   o tipo e o acesso dela, exceto os nós que [Tipos de valor](#value-types) deixa de
   fora. As áreas de diagnóstico do servidor são puladas.

Uma tag candidata recebe o nome do próprio nó (o BrowseName dele), com na frente só os
nomes dos nós acima dele que bastam para distingui-la dos outros canais que o servidor
oferece: `Level` em vez de `Devices.Simulated.Tank.Level` no servidor
de outra estação, e `Line1.Speed` ao lado de `Line2.Speed` só onde dois nós chamados Speed
se encontrariam. Dois nomes que ainda se leriam iguais, diferentes só em maiúsculas e
minúsculas ou na pontuação, são separados por um número. O caminho inteiro da navegação
continua no cartão do candidato, numa segunda linha abaixo do nome, para você saber qual nó
cada tag lê. A tag lê o ID do nó dela, então o nome é só como ela se chama: na grade de tags
e no fim do endereço dela (`Connector.OpcUa.Peer.Level`).

A navegação entra anonimamente (com a mesma escolha do endpoint mais seguro, a mesma
recusa de uma sessão sem segurança e a mesma condição do certificado do equipamento). Um
servidor que recusa sessões anônimas, um servidor que não anuncia nenhum endpoint seguro,
ou uma navegação que falha por qualquer motivo, ainda deixa o endpoint disponível para
adicionar, com zero tags: adicione-o, defina as credenciais e a segurança da sessão no
dispositivo e configure as tags à mão. Nada é persistido até você **Adicionar** um candidato, e cancelar mantém
os candidatos que já estavam completos.

Um servidor que você já tem lê mais nós dele pela página do dispositivo dele: **Descobrir tags**, no cabeçalho do cartão de tags, navega pelo endpoint daquele dispositivo entrando como a própria sessão do dispositivo entra, com o usuário, a senha e a segurança da sessão dele, então ali até um servidor que recusa sessões anônimas mostra os nós dele. Só oferece os nós que nenhuma tag do dispositivo lê ainda, comparados pela tabela de namespaces do servidor: uma tag escrita com o índice do namespace dela (`ns=2;s=Level`) lê o nó que a navegação nomeia pela URI do namespace (`nsu=…;s=Level`), então esse nó não é oferecido de novo. Um servidor que recusa a sessão encerra a varredura com a causa que a própria sessão do dispositivo dá (veja [Descobrir as tags de um dispositivo](connector-discovery#discovering-a-devices-tags)).

## Limites que vale conhecer {#limits-worth-knowing}

- As leituras são consultas cíclicas ao atributo Value; o driver não cria
  assinaturas no servidor remoto.
- Só valores escalares: uma tag não consegue endereçar um elemento de vetor nem um campo
  de estrutura.
- A condição de aprovação vale por certificado: um equipamento que troca o certificado
  volta à lista de revisão e espera por uma decisão nova.

## Acesso a equipamentos {#equipment-access}

A página do driver OPC UA termina com o cartão **Acesso a equipamentos**: a metade de saída da confiança em certificados. Quando o Connector disca para um servidor de equipamento OPC UA, aquele servidor prova quem ele é com um certificado, e a estação não lê nada de um equipamento cujo certificado você não aprovou. O topo do cartão diz isso: "Quando o Connector disca para um servidor OPC UA de equipamento, esse servidor prova quem é com um certificado. Aprove apenas uma impressão digital que você conferiu com quem comissionou o equipamento." Ver Connector lê o cartão; Configurar Connector decide, e as decisões são tomadas no desktop da própria estação.

O princípio sob o topo: "Nada é lido de um equipamento que você não aprovou. Um dispositivo cujo certificado está esperando aqui fica em silêncio e diz isso no Connector. Aprová-lo começa a leitura; retirar a aprovação fecha a sessão e pergunta a você de novo. Os nomes de certificado são declarados pelo equipamento; a impressão digital SHA-256 é a identidade a verificar."

O cartão de propósito tem a mesma forma do [Acesso de clientes](connector-opcua-client-access), com as mesmas palavras onde a ideia é a mesma, e a mesma regra para quem pode decidir: um navegador em outro dispositivo vê "O acesso a equipamentos só pode ser mudado no aplicativo instalado na estação." e o aviso "Abra o aplicativo da estação para mudar o acesso a equipamentos"; um papel sem Configurar Connector não recebe os botões desenhados, e uma unidade em execução e uma mudança já em curso recusam cada uma com a frase própria. Todo desfecho aparece na barra de status.

### O que um dispositivo à espera faz no Connector {#what-a-waiting-device-does-in-the-connector}

Na primeira vez que o Connector disca para um dispositivo OPC UA, o certificado do equipamento é recusado, registrado aqui como esperando, e o dispositivo não lê nada. Na [página do dispositivo](connector-devices) o Connector mostra um aviso de atenção, **Esperando a aprovação do certificado**, com um botão **Revisar o certificado** que abre esta seção na linha daquele dispositivo, e a saúde do dispositivo nomeia o mesmo estado na árvore. A falha do próprio driver diz a razão em vez de um erro de handshake sem nome: "O certificado deste equipamento (os primeiros 16 caracteres da impressão digital) espera a sua aprovação em Acesso a equipamentos, na página do driver OPC UA. A leitura começa assim que você aprová-lo." Um bloqueado diz "…está bloqueado nesta estação. Revise-o em Acesso a equipamentos, na página do driver OPC UA." A varredura de descoberta passa pelo mesmo portão antes de a sessão dela abrir.

Uma vez aprovado, o Connector começa a ler na tentativa seguinte. Um equipamento que estava lendo e passa a apresentar um certificado diferente no mesmo endereço deixa de ser lido e levanta um cartão grudado, "Certificado mudou: `<nome>`": "O equipamento em `<endereço>` estava lendo com um certificado que esta estação aprovou e agora está apresentando um diferente (…), então nada é lido dele. Confira a impressão digital com quem mantém o equipamento e então aprove-a.", com **Revisar**, mais uma notificação do Windows para uma janela escondida. Um dispositivo que está sendo registrado neste momento não é anunciado assim: quem o registra já está olhando para o Connector.

### Esperando aprovação {#waiting-for-approval}

Desenhado enquanto ao menos um certificado espera, encabeçado por "Estes dispositivos seguem sem ser lidos até você decidir." com a contagem. Cada linha mostra um ponto âmbar, o nome que o certificado declara, "Identidade declarada do equipamento", a impressão digital, "`<endereço>` · Última tentativa `<data e hora>` · N tentativas de conexão", e um detalhamento **Detalhes do certificado** com Emitido para, Emitido por, Application URI, Nomes de domínio, Válido de, Válido até e Visto primeiro em. A linha a que um botão Revisar levou é marcada com "Selecionado para revisão" e trazida à vista.

| Comando | O que ele faz | Esmaecido quando (situação) |
| --- | --- | --- |
| Aprovar | Move o certificado para os Equipamentos aprovados e atualiza o validador ao vivo: "`<nome>` está aprovado. O Connector começa a ler na próxima tentativa." | Pela regra acima. |
| Bloquear | Move o certificado para os Equipamentos bloqueados e continua recusando-o: "`<nome>` está bloqueado. A estação vai continuar recusando este certificado." | Pela regra acima. |
| Descartar todos os certificados pendentes (no topo do grupo) | Pergunta "Descartar o certificado que aguarda revisão?" ou "Descartar os N certificados que aguardam revisão?" ("Nada é aprovado nem bloqueado com isso: os pedidos são removidos e a lista abre espaço de novo. Um equipamento para o qual o Connector discar depois disso aparece aqui como um pedido novo."), com **Descartar** e **Manter a lista**. | Pela regra acima. |

A lista guarda no máximo 100 certificados. Enquanto ela está cheia, um certificado a mais continua recusado mas não é retido, e o cartão diz isso: "A lista de revisão abaixo está cheia. Enquanto estiver, um certificado novo é recusado sem ser acrescentado aqui, então o equipamento que você espera pode nunca aparecer. Descarte os certificados que aguardam revisão para abrir espaço.", com a contagem de recusas desde que ela encheu, assim que houver alguma. Toda recusa dessas é registrada no diário.

### Equipamentos aprovados {#approved-equipment}

"Certificados com os quais o Connector pode abrir sessões.", com a contagem. Cada linha mostra um ponto neutro, o nome declarado, "Identidade de equipamento declarada · Aprovado por `<usuário>` em `<data e hora>`" (ou "nesta estação"), a impressão digital, e um detalhamento com Endereço, Emitido para, Emitido por, Application URI, Válido até e Visto por último em. Sem nenhum: "Nenhum certificado de equipamento aprovado."

| Comando | O que ele faz | Esmaecido quando (situação) |
| --- | --- | --- |
| Importar certificado (no topo do grupo) | Abre um seletor de arquivos para o certificado público do equipamento (`.der`, `.cer`, `.crt` ou `.pem`, até 64 KB) e o aprova antes da primeira conexão: "`<nome>` está aprovado a partir de `<arquivo>`. Confira a impressão digital abaixo com a que está na documentação do equipamento." Um arquivo maior: "`<arquivo>` é maior que um certificado de equipamento. Importe o arquivo do certificado público (.der, .cer ou .pem), não um pacote compactado." | Pela regra acima. |
| Retirar a aprovação (na linha, tinta de perigo) | Pergunta "Retirar a aprovação de `<nome>`?": "A sessão atual com este equipamento é encerrada e a estação para de ler dele. O certificado volta para a lista de revisão, então a próxima conexão pergunta de novo.", com **Retirar** e **Manter aprovado**. Depois: "Aprovação retirada de `<nome>`. A sessão dele foi encerrada e ele voltou a aguardar revisão." | Pela regra acima. |

A dica sob o topo: "Já tem o certificado público do equipamento? Importe-o aqui para aprová-lo antes da primeira conexão, em vez de deixar a conexão falhar uma vez. Confira a impressão digital que ele acrescenta com a que está na documentação do equipamento." Um equipamento costuma vir com o certificado dele, e é por isso que este lado tem a importação em primeiro lugar. Importar um certificado bloqueado levanta o bloqueio. Retirar a aprovação manda o certificado de volta para a revisão, não para um bloqueio: você pediu para ser perguntado de novo.

### Equipamentos bloqueados {#blocked-equipment}

Um detalhamento recolhido, "Equipamentos bloqueados" com a contagem, desenhado só enquanto existe ao menos um. Cada linha mostra um ponto vermelho, o nome declarado, "Identidade de equipamento declarada · Bloqueado por `<usuário>` em `<data e hora>`", a impressão digital, e o **Desbloquear**, que o devolve à lista de revisão sem aprová-lo: "`<nome>` foi desbloqueado e voltou para a lista de revisão." Um certificado bloqueado nunca volta sozinho.

### Onde as decisões moram {#where-the-decisions-live}

Os repositórios de equipamento ficam sob `ua\pki\southbound` na raiz de dados da estação (`pending`, `trusted`, `blocked` e o `rejected` do SDK), com o endereço em que cada certificado foi visto, as contagens de tentativa e as decisões em `equipment-access.json`. Eles são separados dos repositórios de entrada, então um certificado de equipamento nunca pode virar permissão para um aplicativo conectar ao servidor da própria estação, nem aparecer como um pedido de entrada. Eles não fazem parte de um [backup](settings-backups) de configuração.

### O que esta seção não faz {#what-this-section-does-not-do}

Nada é aprovado automaticamente, e nenhuma configuração desliga isso. O cartão não configura o próprio dispositivo (o endereço, as credenciais e a leitura cíclica estão no [Connector](connector-devices)), não mostra os valores ao vivo do equipamento, e não decide sobre aplicativos que discam para esta estação, o que é o [Acesso de clientes](connector-opcua-client-access).