# OPC UA

> Un client OPC UA per server di terze parti, con fiducia governata dai certificati, indirizzamento per id di nodo e rilevamento dello spazio degli indirizzi.

Il driver OPC UA è un **client** per server OPC UA di terze parti (PLC, gateway,
archivi storici, altri sistemi SCADA) su `opc.tcp`. È la controparte in uscita del
server OPC UA integrato che pubblica lo spazio degli indirizzi di questa stazione
(descritto in [Server OPC UA](connector-opcua-server)); i due condividono l'identità
applicativa della stazione ma decidono di chi fidarsi in modo indipendente.

## Dispositivo {#device}

| Campo | Significato | Predefinito |
| --- | --- | --- |
| **Indirizzo host** | Nome DNS, indirizzo IPv4 o IPv6 del server. Si può incollare l'URL dell'endpoint così come la mostra un client OPC UA (`opc.tcp://192.168.0.10:4841/UA/Server`): `opc.tcp://` viene tolto, la porta va nel campo della porta e il percorso nel percorso della risorsa. Un indirizzo di un altro protocollo viene rifiutato, con il motivo sotto il campo. | vuoto: il dispositivo non viene collegato finché non se ne inserisce uno |
| **Porta** | La porta TCP dell'endpoint, da 1 a 65535. Un campo vuoto mostra 4840 in grigio e il dispositivo viene chiamato su di essa; un dispositivo salvato con 0 si legge allo stesso modo. | 4840 |
| **Percorso della risorsa** | Il percorso di endpoint che alcuni server richiedono dopo host e porta, e che produce `opc.tcp://host:port/path`. Lascialo vuoto quando il server risponde alla radice. | vuoto |
| **Sicurezza della sessione** | Disattivata, la sessione viaggia firmata e cifrata e un'apparecchiatura che non offre nulla di meglio viene rifiutata. **Consenti una sessione senza sicurezza** la apre lo stesso, in chiaro, per un'apparecchiatura che non annuncia alcun endpoint sicuro. | disattivata |
| **Nome utente** / **Password di accesso** | L'identità dell'utente per la sessione. Un nome utente vuoto significa sessione anonima. La password è protetta a riposo con la DPAPI di Windows per utente e si può leggere solo sulla macchina e sull'account Windows che l'hanno inserita. | anonimo |
| **Intervallo di interrogazione (ms)** | La cadenza di interrogazione predefinita per i tag che non la ridefiniscono. | 1000 |

## Preparare il server {#prepare-the-server}

La maggior parte dei server OPC UA respinge di fabbrica un client nuovo, per due
impostazioni proprie, entrambe fatte sul server:

| Impostazione sul server | Che cosa chiede | Senza di essa |
| --- | --- | --- |
| La fiducia nel certificato di questa stazione | Il server si fida del certificato di applicazione che questa stazione presenta, lo stesso che presenta il [server OPC UA](connector-opcua-server) integrato. La stazione lo conserva come file `.der` nella sua radice dei dati, in `ua\pki\own\certs`. | Il server rifiuta il canale sicuro (`BadSecurityChecksFailed` o `BadCertificateUntrusted`) o lo chiude durante l'handshake, e nessuna sessione si apre. |
| Un utente che accetta | L'accesso anonimo consentito sul server, oppure un **Nome utente** e una **Password di accesso** sul dispositivo che il server conosce. | Il server rifiuta la sessione (`BadIdentityTokenRejected`, `BadIdentityTokenInvalid` o `BadUserAccessDenied`). |

Dove i server più comuni si fidano del certificato di un client:

| Server | Dove |
| --- | --- |
| Un server che conserva i certificati rifiutati in cartelle, come l'SDK della OPC Foundation e molti server costruiti su di esso | Il certificato rifiutato aspetta nella sua cartella `rejected`: spostalo in `trusted/certs`, oppure copiaci il file della stazione. |
| KEPServerEX | Fai clic destro sull'icona **Administration** nell'area di notifica e scegli **OPC UA Configuration**; nella scheda Trusted Clients, seleziona il certificato e fai clic su Trust, oppure fai clic su **Import...** e scegli il file; poi **Reinitialize** dalla stessa icona. |
| Siemens S7-1500, in TIA Portal | Importa il file in **Global security settings > Certificate manager**, scheda **Device certificates**; nelle Properties della CPU, in **OPC UA > Server > Security > Secure Channel**, aggiungilo all'elenco Trusted clients con `<Add new>`; poi carica nella CPU. |

Quando il server respinge per l'uno o l'altro motivo, la pagina del dispositivo dice
quale in un avviso che prende il posto dello stato del server. Per il certificato ne dà
il nome e l'impronta (SHA-1, quella con cui i server lo elencano), ciascuno con un
pulsante per copiarlo, e il file con un pulsante che ne apre la cartella. Per l'utente
dice se il server non accetta sessioni anonime o se ha rifiutato l'utente, e rimanda a
**Nome utente** e **Password di accesso** del dispositivo. L'avviso scompare da solo
appena si apre una sessione, e il registro e l'agente leggono la stessa indicazione.
Questa stazione emette un nuovo certificato quando cambiano il suo nome di applicazione
o il suo nome di rete, e il server deve allora fidarsi di quello nuovo.

## Sicurezza e certificati {#security-and-certificates}

La connessione parte dall'elenco di endpoint del server: il client sceglie
l'**endpoint più sicuro che il server annuncia** e autentica l'applicazione con il
certificato proprio di questa stazione, la stessa identità applicativa OPC UA che usa
il server integrato. Molti server pretendono che quel certificato sia considerato
attendibile dalla loro parte prima di accettare la sessione: [Preparare il server](#prepare-the-server)
dice dove.

Un'apparecchiatura che non annuncia nulla di meglio di un **endpoint senza sicurezza**
viene rifiutata, e il dispositivo dice perché. Quella sessione porterebbe le letture e le
credenziali in chiaro e non dimostrerebbe l'identità dell'apparecchiatura, quindi si apre
solo dove è stata chiesta su quel dispositivo: **Sicurezza della sessione**, **Consenti una
sessione senza sicurezza**, nella scheda di connessione. La scelta appartiene a quel
dispositivo, viaggia nel suo indirizzo come `?security=none` e vale sia per la sessione di
lettura sia per il percorso della ricerca. Attivarla non declassa mai un'apparecchiatura che
la sicurezza la offre: viene preso comunque l'endpoint più sicuro annunciato.

Nell'altra direzione la fiducia è **esplicita e chiusa in caso di dubbio**. Il
certificato dell'apparecchiatura viene controllato prima che la sessione si apra:

- Un certificato che questa stazione non ha mai approvato viene rifiutato, registrato
  per la verifica, e il pannello del dispositivo mostra una nota che nomina
  l'approvazione che sta aspettando: il dispositivo non è « non connesso », sta
  aspettando una decisione.
- I certificati si verificano nella scheda [Accesso delle apparecchiature](#equipment-access) di questa pagina, la
  metà in uscita della fiducia sui certificati: un certificato registrato sta sotto
  **In attesa di approvazione** finché non lo **Approva** (le sessioni nuove si possono
  aprire) o non lo **Blocca** (rifiutato senza sollevare richieste ripetute). Questo è
  l'elenco delle apparecchiature; **Accesso dei client**, nel pannello del [Server OPC UA](connector-opcua-server), è
  l'altra direzione, cioè chi può connettersi in entrata al server proprio di questa
  stazione.
- **Ritira l'approvazione**, su una riga approvata, chiude le sessioni vive che girano
  su quel certificato e lo riporta nell'elenco di verifica, così la connessione
  successiva lo chiede di nuovo.
- Un'apparecchiatura che non presenta **alcun certificato** non dimostra nulla su chi ha
  risposto, quindi non c'è nulla da approvare e la sessione viene rifiutata, con il suo
  indirizzo scritto nel diario. Si connette solo sotto lo stesso **Consenti una sessione
  senza sicurezza**, che a quel punto fa le veci dell'approvazione.

Approvare il server di un'apparecchiatura non autorizza mai quel certificato a
connettersi in entrata al server proprio di questa stazione: le due direzioni tengono
archivi separati di proposito.

## Il comportamento della sessione {#session-behavior}

I tag vengono **interrogati**: ogni lettura chiede al server il valore attuale del
nodo. Il giudizio del server viaggia con ogni campione: un valore marcato Bad o
Uncertain viene rifiutato e il tag legge cattiva qualità, così una sorgente dubbia non
viene mai ripulita e spacciata per una lettura buona. Un nodo che sul server non
esiste più si legge come nessun valore, invece di far fallire tutto il dispositivo.

Anche la marca temporale del server viaggia con il campione: il SourceTimestamp che ha dato a un valore buono diventa la **Marca temporale dell'origine** del tag nella [pagina del tag](connector-tags#the-live-value-card). Un server può tenere quella marca finché il valore o la sua qualità non cambiano, così un valore stabile può mostrare una marca precedente alla **Marca temporale dell'applicazione**, che è sempre l'istante in cui la stazione ha ricevuto la lettura.

La sessione è sorvegliata con i keep-alive; dopo tre keep-alive mancati il client
avvia una riconnessione automatica e prosegue. La connessione iniziale appartiene al
ciclo di ritentativi in secondo piano dell'applicazione, quindi un server
irraggiungibile non costa nulla all'avvio.

## Indirizzamento dei tag {#tag-addressing}

Un tag viene indirizzato dal suo **ID nodo**, scritto a testo libero e inviato tale
e quale. Le forme accettate sono le notazioni standard di OPC UA:

| Esempio | Significato |
| --- | --- |
| `ns=2;s=Temperature` | Identificatore di stringa nell'indice di spazio dei nomi 2 |
| `ns=2;g=5f2c7a1e-8b3d-4c9a-9e61-2d4b7f0a3c58` | Identificatore GUID nell'indice di spazio dei nomi 2 |
| `ns=3;i=1042` | Identificatore numerico nell'indice di spazio dei nomi 3 |
| `nsu=urn:vendor:app;s=Line1.Speed` | Forma estesa che nomina lo spazio dei nomi per URI invece che per indice: resistente ai cambi di indice tra un riavvio e l'altro |

Il tag legge e scrive l'attributo **Value** del nodo.

### Tipi di valore {#value-types}

| Tipi offerti |
| --- |
| Boolean, Byte, Int16, Int32, Int64, Float, Double e String |

I valori sono **soltanto scalari**: gli array, le strutture e gli altri valori
complessi vengono rifiutati come illeggibili invece di essere appiattiti in un numero
fuorviante, e il tag legge cattiva qualità. Un tag così fallisce da solo; gli altri tag
del dispositivo continuano a leggere, e per lui non viene riconnesso nulla. Una
stringa vuota è un valore, non un fallimento. I tipi fuori dall'insieme offerto non
sono disponibili come tipo di un tag su questo driver: SByte, le larghezze senza segno
diverse da Byte (UInt16, UInt32, UInt64), DateTime, Guid e ByteString.

Un tag di tipo diverso da quello del nodo viene convertito tramite il suo numero, mai riletto
attraverso i suoi byte, e la stessa regola vale in lettura e in scrittura. Un reale va in un
reale (Float e Double), e un intero in un intero di un'altra larghezza quando il valore ci sta;
un tag Boolean su un nodo intero legge 0 e 1 come spento e acceso e li scrive come 0 e 1. Un
valore che non ci sta, o un nodo che contiene un altro genere di valore (un reale per un tag
intero, un numero per un tag di testo), viene rifiutato su quel solo punto, e una scrittura
rifiutata così non viene mai inviata al server.

Una scansione di un server offre quindi meno canali di quanti il server ne tenga: un
nodo che dichiara un elenco di valori o che ne contiene uno quando la scansione lo legge,
e un nodo il cui tipo è fuori dall'insieme offerto, restano fuori. Molti server lasciano
aperta la forma dichiarata di una variabile (un ValueRank Any o ScalarOrOneDimension) anche
quando non contiene mai più di un valore; un nodo così viene quindi giudicato dal valore
che contiene quando la scansione lo legge, e viene offerto a meno che quel valore non sia
un elenco. Se più avanti contiene un elenco, quel solo tag fallisce sulle proprie letture,
come per qualunque valore che un tag non può contenere, e gli altri tag del dispositivo
continuano a leggere. Il tipo di un nodo è il tipo di base da cui deriva il tipo che
dichiara: un nodo dichiarato come VersionTime contiene un UInt32 e uno dichiarato come
UtcTime un DateTime, quindi restano fuori entrambi, mentre uno dichiarato come Duration
contiene un Double e viene offerto. I server che lasciano aperta la forma spesso lasciano
aperto anche il tipo dichiarato (BaseDataType, oppure Number, Integer o UInteger, tipi con cui
nessun valore viaggia); un nodo così prende quindi il tipo del valore che contiene quando la
scansione lo legge, e viene offerto o resta fuori in base a quel tipo. Un nodo così la cui
lettura non riporta alcun valore non mostra alcun tipo e resta fuori. Se più avanti il server
invia un valore di un altro tipo, quel valore viene letto secondo la regola di conversione
qui sopra, e quel tag fallisce soltanto dove la regola lo rifiuta.
Non vengono però lasciati cadere in silenzio. La scansione li
conta e il suo messaggio di chiusura dice quanti sono e di che genere, per esempio
« 5 canali sono stati lasciati fuori: 3 di tipo UInt32, 2 che contengono un elenco di
valori invece di un valore solo. », così un elenco corto si legge come un elenco corto
e non come un controllore spoglio.

Resta fuori anche, senza essere contato, un nodo a cui il server risponde senza alcun
valore: non contiene nulla, e importato non leggerebbe mai. Un nodo il cui valore torna
Bad viene invece offerto, a meno che non dichiari un elenco, o non dichiari un tipo aperto
senza riportare alcun valore da cui ricavarlo: quello stato dice soltanto che la sua sorgente non ha ancora
risposto, o che la sessione anonima della scansione non può leggerlo, e il dispositivo
accede con le proprie credenziali.

## Scritture {#writes}

Un tag scrivibile scrive l'attributo Value del nodo attraverso il servizio Write di
OPC UA. La risposta del server è il giudizio: una scrittura rifiutata affiora come un
fallimento, e il valore in cache avanza solo quando viene accettata. Come dappertutto,
il campo di scrittura prende il valore ingegneristico e la [catena di conversione](connector-value-pipeline) viene
percorsa all'indietro prima che il valore grezzo parta.

## Rilevamento {#discovery}

Il comando **Rileva** prende un bersaglio nel campo accanto: un indirizzo di server
OPC UA come `opc.tcp://plc-host:4840`. La scansione ha due fasi, e la riga di
avanzamento nomina quella in corso:

1. **Endpoint**: viene interrogato il servizio di rilevamento standard del bersaglio e
   ogni URL di rilevamento annunciato diventa un endpoint candidato. Le porte e i
   percorsi di server personalizzati tornano dentro i campi di connessione del
   candidato.
2. **Canali**: lo spazio degli indirizzi di ogni candidato viene percorso a partire
   dalla cartella Objects, e ogni variabile leggibile viene elencata come tag
   candidato, con il suo tipo e il suo accesso, tranne i nodi che
   [Tipi di valore](#value-types) lascia fuori. Le aree di diagnostica del server
   vengono saltate.

Un tag candidato prende il nome del proprio nodo (il suo BrowseName), preceduto da tanti
nomi dei nodi sopra di lui quanti bastano a distinguerlo dagli altri canali che il server
offre, e non di più: `Level` invece di `Devices.Simulated.Tank.Level`
sul server di un'altra stazione, e `Line1.Speed` accanto a `Line2.Speed` solo dove due
nodi chiamati Speed si incontrerebbero. Due nomi che si leggerebbero ancora uguali, diversi
solo per maiuscole e minuscole o per la punteggiatura, vengono distinti da un numero. Il
percorso completo resta sulla scheda del candidato, su una seconda riga sotto il nome, così
sai quale nodo legge ogni tag. Il tag legge il suo ID nodo, quindi il nome è solo come si
chiama: nella griglia dei tag e alla fine del suo indirizzo (`Connector.OpcUa.Peer.Level`).

Il percorso accede in modo anonimo (con la stessa scelta dell'endpoint più sicuro, lo
stesso rifiuto di una sessione senza sicurezza e lo stesso controllo sul certificato
dell'apparecchiatura). Un server che rifiuta le sessioni anonime, un server che non
annuncia alcun endpoint sicuro, o un percorso che fallisce per un qualunque motivo, lascia
comunque l'endpoint aggiungibile con zero tag: aggiungilo, imposta le credenziali e la
sicurezza della sessione sul dispositivo e configura i tag a mano. Nulla viene reso durevole finché non
**Aggiungi** un candidato, e l'annullamento conserva i candidati già completi.

Un server che c'è già legge altri suoi nodi dalla pagina del suo dispositivo: **Rileva tag**, nell'intestazione della scheda dei tag, percorre l'endpoint di quel dispositivo accedendo come accede la sessione stessa del dispositivo, con il suo nome utente, la sua password e la sicurezza della sua sessione, così anche un server che rifiuta le sessioni anonime vi mostra i suoi nodi. Offre solo i nodi che nessun tag del dispositivo legge ancora, confrontati attraverso la tabella degli spazi dei nomi del server: un tag scritto con l'indice del suo spazio dei nomi (`ns=2;s=Level`) legge il nodo che il percorso nomina con l'URI del suo spazio dei nomi (`nsu=…;s=Level`), quindi quel nodo non viene offerto di nuovo. Un server che rifiuta la sessione chiude la scansione con la causa che dà la sessione stessa del dispositivo (vedere [Rilevare i tag di un dispositivo](connector-discovery#discovering-a-devices-tags)).

## Limiti da conoscere {#limits-worth-knowing}

- Le letture sono interrogazioni dell'attributo Value; il driver non crea
  sottoscrizioni sul server remoto.
- Soltanto valori scalari: un tag non può indirizzare un elemento di array o un campo
  di struttura.
- Il controllo di approvazione vale per ogni certificato: un'apparecchiatura che
  ruota il proprio certificato torna nell'elenco di verifica e aspetta una nuova
  decisione.

## Accesso delle apparecchiature {#equipment-access}

La pagina del driver OPC UA termina con la sua scheda **Accesso delle apparecchiature**: la metà uscente dell'attendibilità dei certificati. Quando il Connector chiama un server OPC UA di apparecchiatura, quel server dimostra la propria identità con un certificato, e la stazione non legge nulla da un'apparecchiatura il cui certificato non è stato approvato. La testa della scheda lo dice: "Quando il Connector chiama un server OPC UA di apparecchiatura, quel server dimostra la propria identità con un certificato. Approvare solo un'impronta verificata con chi ha messo in servizio l'apparecchiatura." Visualizzare Connector legge la scheda; Configurare Connector decide, e le decisioni si prendono sul desktop proprio della stazione.

Il principio sotto la testa: "Da un'apparecchiatura non approvata non viene letto nulla. Un dispositivo il cui certificato è in attesa qui resta muto e lo dichiara nel Connector. Approvandolo inizia la lettura; ritirando l'approvazione la sessione si chiude e la domanda viene posta di nuovo. I nomi dei certificati sono dichiarati dall'apparecchiatura; l'impronta SHA-256 è l'identità da verificare."

La scheda ha deliberatamente la stessa forma di [Accesso dei client](connector-opcua-client-access), con le stesse parole ovunque l'idea sia la stessa, e la stessa regola su chi può decidere: un browser su un altro dispositivo vede "L'accesso delle apparecchiature può essere cambiato solo nell'applicazione desktop della stazione." e l'avviso "Aprire l'applicazione desktop per cambiare l'accesso delle apparecchiature"; a un ruolo senza Configurare Connector i pulsanti non vengono disegnati, e un'unità in prova e una modifica già in corso rifiutano ciascuna con la propria frase. Ogni esito arriva nella barra di stato.

### Che cosa fa nel Connector un dispositivo in attesa {#what-a-waiting-device-does-in-the-connector}

La prima volta che il Connector chiama un dispositivo OPC UA, il certificato dell'apparecchiatura viene rifiutato, registrato qui come in attesa, e il dispositivo non legge nulla. Nella [pagina del dispositivo](connector-devices) il Connector mostra un avviso di attenzione, **In attesa dell'approvazione del certificato**, con un pulsante **Verifica il certificato** che apre questa sezione sulla riga di quel dispositivo, e lo stato di salute del dispositivo nomina lo stesso stato nell'albero. Il fallimento proprio del driver dice il motivo invece di un errore di handshake senza nome: "Il certificato di questa apparecchiatura (i primi 16 caratteri dell'impronta) attende la vostra approvazione in Accesso delle apparecchiature, nella pagina del driver OPC UA. La lettura inizia appena lo approvate." Uno bloccato legge "…è bloccato presso questa stazione. Verificarlo in Accesso delle apparecchiature, nella pagina del driver OPC UA." Anche l'esplorazione del rilevamento passa dallo stesso controllo prima che la sua sessione si apra.

Una volta approvato, il Connector inizia a leggere al tentativo successivo. Un'apparecchiatura che stava leggendo e che comincia a presentare un certificato diverso allo stesso indirizzo smette di essere letta e solleva una scheda persistente, "Certificato cambiato: `<nome>`": "L'apparecchiatura all'indirizzo `<indirizzo>` leggeva con un certificato approvato da questa stazione e ora ne presenta uno diverso (…), quindi non viene letto nulla da essa. Verificare l'impronta con chi gestisce l'apparecchiatura, poi approvarla.", con **Verifica**, più una notifica di Windows per una finestra nascosta. Un dispositivo che si sta registrando in questo momento non viene annunciato così: chi lo registra sta già guardando il Connector.

### In attesa di approvazione {#waiting-for-approval}

Disegnata mentre almeno un certificato aspetta, intestata "Questi dispositivi non vengono letti fino alla decisione." con il conteggio. Ogni riga mostra un punto ambra, il nome che il certificato dichiara, "Identità dichiarata dall'apparecchiatura", l'impronta, "`<indirizzo>` · Ultimo tentativo `<data e ora>` · N tentativi di connessione", e una scheda a scomparsa **Dettagli del certificato** con Soggetto, Emittente, URI dell'applicazione, Nomi di dominio, Valido da, Valido fino al e Visto la prima volta. La riga a cui ha portato un pulsante Verifica è segnata "Selezionato per la verifica" e portata in vista scorrendo.

| Comando | Che cosa fa | In grigio quando (situazione) |
| --- | --- | --- |
| Approva | Sposta il certificato in Apparecchiature approvate e aggiorna il validatore dal vivo: "`<nome>` è approvato. Il Connector inizia a leggere al tentativo successivo." | Per la regola qui sopra. |
| Blocca | Lo sposta in Apparecchiature bloccate e continua a rifiutarlo: "`<nome>` è bloccato. La stazione continuerà a rifiutare questo certificato." | Per la regola qui sopra. |
| Scarta tutti i certificati in attesa (sulla testa del gruppo) | Chiede "Scartare il certificato in attesa di verifica?" oppure "Scartare i N certificati in attesa di verifica?" ("Con questo non si approva né si blocca nulla: le richieste vengono rimosse e l'elenco torna ad avere spazio. Un'apparecchiatura che il Connector chiama dopo compare qui come nuova richiesta."), con **Scarta** e **Mantieni l'elenco**. | Per la regola qui sopra. |

L'elenco tiene al massimo 100 certificati. Mentre è pieno, un ulteriore certificato resta rifiutato ma non viene conservato, e la scheda lo dice: "L'elenco di verifica qui sotto è pieno. Finché lo è, un nuovo certificato viene rifiutato senza essere aggiunto qui, quindi l'apparecchiatura attesa potrebbe non comparire mai. Scartare i certificati in attesa di verifica per fare spazio.", con il conteggio dei rifiuti da quando si è riempito, una volta che ce ne sono. Ogni rifiuto del genere viene annotato nel diario tecnico.

### Apparecchiature approvate {#approved-equipment}

"Certificati con cui il Connector può aprire sessioni.", con il conteggio. Ogni riga mostra un punto neutro, il nome dichiarato, "Identità dichiarata dall'apparecchiatura · Approvato da `<utente>` il `<data e ora>`" (oppure "presso questa stazione"), l'impronta e una scheda a scomparsa di dettagli con Indirizzo, Soggetto, Emittente, URI dell'applicazione, Valido fino al e Visto l'ultima volta. Con nessuna: "Nessun certificato di apparecchiatura approvato."

| Comando | Che cosa fa | In grigio quando (situazione) |
| --- | --- | --- |
| Importa certificato (sulla testa del gruppo) | Apre un selettore di file per il certificato pubblico dell'apparecchiatura (`.der`, `.cer`, `.crt` oppure `.pem`, fino a 64 KB) e lo approva prima della prima connessione: "`<nome>` è approvato a partire da `<file>`. Confrontare l'impronta qui sotto con quella riportata nella documentazione dell'apparecchiatura." Un file più grande: "`<file>` è più grande di un certificato di apparecchiatura. Importare il file del certificato pubblico (.der, .cer o .pem), non un archivio." | Per la regola qui sopra. |
| Ritira l'approvazione (sulla riga, inchiostro del pericolo) | Chiede "Ritirare l'approvazione per `<nome>`?": "La sessione in corso con questa apparecchiatura viene chiusa e la stazione smette di leggerla. Il certificato torna nell'elenco di verifica, quindi alla connessione successiva la domanda viene posta di nuovo.", con **Ritira** e **Mantieni approvato**. Poi: "Approvazione ritirata per `<nome>`. La sua sessione è stata chiusa ed è di nuovo in attesa di verifica." | Per la regola qui sopra. |

Il suggerimento sotto la testa: "Il certificato pubblico dell'apparecchiatura è già disponibile? Importarlo qui per approvarlo prima della prima connessione, invece di lasciar fallire una volta la connessione. Confrontare l'impronta che aggiunge con quella riportata nella documentazione dell'apparecchiatura." Un'apparecchiatura arriva di solito con il proprio certificato, ed è per questo che su questo lato l'importazione viene prima. Importare un certificato bloccato toglie il blocco. Ritirare l'approvazione rimanda il certificato alla verifica, non a un blocco: si è chiesto di essere interrogati di nuovo.

### Apparecchiature bloccate {#blocked-equipment}

Una scheda a scomparsa chiusa, "Apparecchiature bloccate" con il conteggio, disegnata soltanto mentre ne esiste almeno una. Ogni riga mostra un punto rosso, il nome dichiarato, "Identità dichiarata dall'apparecchiatura · Bloccato da `<utente>` il `<data e ora>`", l'impronta e **Sblocca**, che la riporta nell'elenco di verifica senza approvarla: "`<nome>` è sbloccato ed è tornato nell'elenco di verifica." Un certificato bloccato non torna mai da solo.

### Dove vivono le decisioni {#where-the-decisions-live}

Gli archivi delle apparecchiature stanno sotto `ua\pki\southbound` nella radice dei dati della stazione (`pending`, `trusted`, `blocked` e il `rejected` dell'SDK), con l'indirizzo a cui ogni certificato è stato visto, i conteggi dei tentativi e le decisioni in `equipment-access.json`. Sono separati dagli archivi in entrata, così un certificato di apparecchiatura non può mai diventare il permesso per un'applicazione di connettersi al server proprio della stazione, né comparire come richiesta in entrata. Non fanno parte di un [backup](settings-backups) della configurazione.

### Ciò che questa sezione non fa {#what-this-section-does-not-do}

Non viene approvato nulla automaticamente, e nessuna impostazione disattiva questa regola. La scheda non configura il dispositivo in sé (indirizzo, credenziali e interrogazione ciclica stanno nel [Connector](connector-devices)), non mostra i valori dal vivo dell'apparecchiatura e non decide sulle applicazioni che chiamano questa stazione, che sono in [Accesso dei client](connector-opcua-client-access).