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); os dois compartilham a identidade de aplicação da estação, mas confiam nos seus pares de forma independente.

Dispositivo

Preparar o servidor

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

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

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

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 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 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, é 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

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

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:

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

Tipos de valor

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

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 é revertida antes de o valor bruto ser enviado.

Descoberta

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

Limites que vale conhecer

• 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

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, 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

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

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.

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

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

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

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

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 de configuração.

O que esta seção não faz

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), 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.