Database

I valori che un sistema della fabbrica tiene in una tabella di database (SQL Server, PostgreSQL, MySQL e MariaDB, SQLite, o qualsiasi database tramite ODBC) letti come tag, e riscritti dove un tag lo chiede: le schede Connessione al database e Accesso, un tag che legge una cella per tabella, colonna e riga oppure esegue una query propria, i due modi in cui un tag scrive, la scansione che propone un tag per colonna, quattro esempi completi e ciò che il driver non fa.

Il driver Database legge i valori che un sistema della fabbrica tiene in una tabella di database: l'ordine di produzione che il MES conserva, la ricetta o il setpoint che l'ERP tiene, il risultato che un altro sistema di prova ha registrato. Ogni tag legge un valore di una tabella, e i suoi valori arrivano dove arrivano quelli di ogni altro tag: in Logic, sulle dashboard, nelle prove di un banco di collaudo di Process. Dove un tag lo chiede, il driver scrive anche all'indietro: nella cella che il tag legge, oppure con un comando proprio del tag.

SQL Server, PostgreSQL, MySQL e MariaDB, e SQLite si raggiungono senza installare nulla sul computer. Ogni altro database (Oracle, Access, Firebird e altri) si raggiunge tramite il suo driver ODBC, che deve essere installato sul computer nella versione a 64 bit.

La lettura è l'uso principale, e il suo percorso è breve: un dispositivo dice dove si trova il suo database e come la stazione vi accede, la scansione propone un tag per colonna delle sue tabelle, e ogni tag nasce in sola lettura. Ciò che riguarda la scrittura compare su un tag solo dopo che il suo accesso lascia scrivere la stazione.

Un dispositivo di questo driver è un database: due database dello stesso server sono due dispositivi. I dispositivi stanno sotto il driver e possono essere archiviati in cartelle, Driver → Cartella → Dispositivo → Tag, come sotto ogni driver senza linea seriale né broker.

La pagina del driver

La riga sotto l'intestazione dice « Ogni dispositivo legge un database. Aggiungere un dispositivo, inserire dove si trova il suo database e come la stazione vi accede, poi scansionarlo per aggiungerne le colonne come tag. » Per Configurare il connector, la pagina porta la scheda Ambito della scansione propria del driver, con il dispositivo di cui la scansione legge il database (vedi Rilevamento). Sotto si trova la tabella Dispositivi di ogni driver (vedi La tabella dei dispositivi), che cresce con Aggiungi dispositivo, a destra del suo titolo; vuota, dice « Nessun dispositivo. » La barra del driver porta Rileva, in grigio finché la scheda Ambito della scansione non è completa. Il driver sta sotto File e database, accanto al driver File.

Dispositivo

Un dispositivo di questo driver non ha la scheda Connessione: al suo posto c'è la scheda Connessione al database, seguita dalla scheda Accesso su ogni database tranne SQLite, che non ha accesso. L'Intervallo di interrogazione (ms) della scheda Dispositivo, 1000 per impostazione predefinita, dice ogni quanto i tag leggono il database, e ogni tag può sostituirlo come in ogni driver.

Un dispositivo nuovo è un SQL Server senza server: dice « Server non ancora inserito », la sua pagina dice « La stazione non raggiunge questo dispositivo finché non dice dove si trova il suo database, quindi non ne viene ancora letto nulla e non c'è alcun errore da mostrare. Inserirlo nella scheda Connessione al database qui sotto (il server e il nome del database, il file o l'origine dati) e la stazione vi si connette. » e non si legge nulla finché non lo dice. La Base URI che mostra l'intestazione è l'indirizzo di esecuzione, che non contiene mai l'utente né la password: database://sqlserver?server=mes-sql&instance=SQLEXPRESS&database=MES per un'istanza di SQL Server, database://sqlite?file=C%3A%5CData%5Crecipes.db per un file SQLite, database://odbc?source=ERP per un'origine dati ODBC.

La scheda Connessione al database

Un campo che il tipo scelto non legge non viene mostrato, e conserva il suo valore per quando lo leggerà. Scegliere un altro tipo svuota una porta rimasta sulla porta propria del database precedente, così che il nuovo si raggiunga sulla sua. Il campo Server del database separa ciò che gli strumenti di database scrivono insieme:

Finché la scheda non dice dove si trova il database, il dispositivo viene salvato così com'è e attende, con il punto grigio, senza leggere nulla e senza mostrare errori:

Un'impostazione che la scheda non accetta viene detta sotto le schede, e il dispositivo non viene salvato finché non è corretta:

Il salvataggio segue le stesse regole, e il registro delle azioni lo dice quando ne rifiuta una: « Il dispositivo 'MES' ha un'impostazione di database che il suo driver non può usare. Aprirlo e correggere il campo che il pannello segnala. »

La scheda Accesso

Ogni database tranne SQLite porta la scheda Accesso, con l'utente con cui la stazione accede.

PostgreSQL e MySQL non hanno il campo Crittografia: la loro connessione è crittografata ogni volta che il server lo offre. Un SQL Server con un certificato proprio, come spesso ha un server di fabbrica, rifiuta la connessione con le parole del database su una catena di certificati emessa da un'autorità non attendibile: Crittografata, qualsiasi certificato accettato è la scelta che quel server chiede.

Sotto i suoi campi, la scheda dice quale utente chiedere: « Chiedere all'amministratore del database un utente con i soli permessi di cui la stazione ha bisogno: la lettura, e la scrittura solo nelle tabelle che i suoi tag cambiano. » La stazione legge e scrive i dati di un altro sistema con tutto ciò che il suo utente può fare, quindi quell'utente è il vero limite di ciò che la stazione può cambiare. Ogni scrittura viene annotata nel diario tecnico, come in ogni driver.

Un server a cui si accede con un utente, senza utente ancora inserito, dice invece « Inserire l'utente con cui la stazione accede. Fino ad allora la stazione non collega questo dispositivo. » Non è un rifiuto: il dispositivo viene salvato, e il suo errore dice che nessun utente del database è ancora inserito, finché l'utente non c'è.

Online, in attesa e offline

Ogni dispositivo ha una connessione propria, aperta quando si collega e mai condivisa né tenuta in un pool, quindi una connessione che un server ha chiuso non viene mai riusata.

Preparare il server

I tre database di rete arrivano chiusi a un altro computer nelle installazioni comuni. Ognuna di queste impostazioni si fa sul server, da chi lo amministra; la stazione non ne cambia nessuna.

Ognuno richiede anche la porta del database consentita nel firewall del computer del server. Quando il server risponde in uno di questi modi, la pagina del dispositivo dice di quale impostazione si tratta, con questi passi e i valori di questo dispositivo (la porta, l'istanza, l'indirizzo di questa stazione come lo ha visto il server, la riga di pg_hba.conf e l'account MySQL, ciascuno con un pulsante per copiarlo), al posto dell'errore in inglese del database. L'avviso scompare da solo non appena il dispositivo si connette, o quando il server risponde in altro modo. Il registro e l'agente leggono gli stessi passi.

Indirizzamento del tag

Come legge un tag

Un tag di questo driver non ha un campo indirizzo proprio: la sua scheda Sorgente chiede come legge.

Un tag nuovo legge Tabella e colonna, tramite la sua chiave, come Double. I tipi offerti sono Boolean, Int32, Int64, Float, Double, String e DateTime. Nella lettura di una cella, un tag di numero intero rifiuta un valore con decimali invece di arrotondarlo (la scrittura fa il contrario, vedi Scrittura), e un testo si legge come numero solo quando lo è. Ogni tag nasce in Sola lettura; ciò che la scrittura aggiunge si trova in Scrittura.

Tabella e colonna

Un nome si legge come lo legge il database:

Il driver mette ogni parte di un nome tra le virgolette che il suo database accetta, quindi un nome non viene mai incollato in un'istruzione come testo. Un tag i cui campi non possono funzionare non viene salvato, e la sua pagina dice cosa manca:

La riga in sola lettura Indirizzo di origine (bus) mostra ciò che il driver riceve: row?table=dbo.ProductionOrders&column=Quantity&key=OrderNo&equals=4711 per una riga tramite la sua chiave, newest?table=recipe_setpoints&column=oven_temperature&by=updated_at per la riga più recente.

Query propria

La query si legge come la legge il database: ciò che sta dentro un testo tra virgolette, un nome tra virgolette o un commento non è una parola dell'istruzione. Una query che fa più che leggere viene rifiutata dove viene scritta:

L'indirizzo di bus di un tag di query è query?sql= seguito dalla query, codificata in percentuale.

Lettura

Una lettura fallita conserva l'ultima lettura del tag, che conta come fallita quando è più vecchia del suo intervallo di interrogazione più 10 s, come in ogni driver. Il database viene interrogato a ogni lettura: un cambiamento che fa un altro programma si vede alla lettura successiva, mai nell'istante in cui viene fatto.

Scrittura

Un tag scrive solo quando il suo Accesso è Lettura e scrittura o Sola scrittura. La sua scheda Sorgente aggiunge allora cosa fa una scrittura:

Un tag in Sola scrittura che esegue il suo comando di scrittura non legge nulla, quindi la sua scheda Sorgente contiene solo la scrittura.

Un comando che il driver non può eseguire viene rifiutato sulla pagina del tag:

I nomi con @@, le funzioni di SQL Server, e i nomi di argomento di un EXEC (@speed = @value) non sono valori e restano come sono scritti. Il salvataggio segue le stesse regole, e il registro delle azioni lo dice quando rifiuta un tag: « Il tag 'Order quantity' non dice dove si trova il suo valore nel database, oppure ha una query o un comando di scrittura che il suo driver rifiuta. Aprirlo e correggere il campo che il pannello del tag segnala. »

L'indirizzo di bus aggiunge la scrittura: row?table=recipes&column=setpoint&key=code&equals=R-100&write=cell per una cella, none?write=command&command= seguito dal comando per un tag in Sola scrittura che esegue il suo comando.

Rilevamento

La scheda Ambito della scansione

Per Configurare il connector, la pagina del driver porta la sua scheda Ambito della scansione, sotto la riga « Accede come fa il dispositivo e propone un tag per ogni colonna delle sue tabelle, alla riga più recente o alla riga della chiave più piccola. »

Un driver senza dispositivi contiene solo « Un database si scansiona tramite un dispositivo, che ne conserva l'accesso. Aggiungere un dispositivo di questo driver e dire dove si trova il suo database. » Ciò che ancora manca all'ambito viene detto in rosso sotto la scheda, e Rileva resta in grigio finché non è completo:

Quando il dispositivo da scansionare ha una modifica che non si può salvare, la scansione non parte: « Il rilevamento non è partito perché non è stato possibile salvare la modifica del dispositivo da scansionare. »

Cosa offre la scansione

La scansione accede come fa il dispositivo, legge l'elenco che il database stesso tiene delle sue tabelle e viste (escluse quelle di sistema) e delle loro colonne, e dice quale tabella legge, come « Lettura delle colonne di recipes… ». Propone un candidato, il dispositivo stesso, segnato come Già configurato: la sua scheda elenca, spuntate, le colonne che nessun tag del dispositivo legge ancora, e Aggiungi i tag, prima di Apri, aggiunge quelle spuntate al dispositivo, in sola lettura.

I tag prendono il nome dalla loro tabella e colonna (recipes.oven_temperature), il tipo dalla colonna, e ognuno è in Sola lettura. Una scansione legge al massimo 100 tabelle e 500 valori; una scansione interrotta lì dice « La scansione di Recipes si è fermata prima. Una scansione legge al massimo 100 tabelle e 500 valori: indicare un nome di tabella o un modello per vedere gli altri. » Il resto del comportamento della scansione si trova in Rilevamento.

La pagina stessa di un dispositivo fa lo stesso senza la pagina del suo driver: Rileva tag, nell'intestazione della sua scheda dei tag, si autentica come il dispositivo, scansiona il suo database così com'è salvato e offre solo le colonne per cui non ha ancora un tag (vedere Rilevare i tag di un dispositivo).

Esempio: un ordine di produzione da SQL Server

Il MES tiene i suoi ordini di produzione in SQL Server, nella tabella dbo.ProductionOrders del database MES, una riga per numero d'ordine:

1. Sulla pagina del driver, Aggiungi dispositivo; chiamarlo MES. Sulla scheda Connessione al database tenere SQL Server, inserire Server del database mes-sql (o mes-sql\SQLEXPRESS per un'istanza denominata), lasciare Porta vuoto e inserire Nome del database MES.
2. Sulla scheda Accesso inserire Nome utente station_reader e la sua Password di accesso, oppure attivare Accedere con l'account Windows della stazione. Per un server di fabbrica con un proprio certificato, scegliere Crittografata, qualsiasi certificato accettato.
3. Aggiungi tag Order quantity, Int32: Tabella dbo.ProductionOrders, Colonna del valore Quantity, Riga da leggere Tramite la sua chiave, Colonna chiave OrderNo, Valore chiave 4711. Il suo indirizzo di bus è row?table=dbo.ProductionOrders&column=Quantity&key=OrderNo&equals=4711.
4. Aggiungi tag Product, String, sulla stessa tabella e la stessa riga, Colonna del valore ProductCode: i due tag si leggono in una sola query.

Con gli strumenti:

device_upsert name=MES driver=Database databaseKind=SqlServer host="mes-sql\SQLEXPRESS" databaseName=MES username=station_reader password=<password> databaseEncryption=TrustServerCertificate
tag_upsert device=MES name="Order quantity" opcUaType=Int32 databaseTable=dbo.ProductionOrders address=Quantity databaseRow=Key databaseKeyColumn=OrderNo databaseKeyValue=4711
tag_upsert device=MES name=Product opcUaType=String databaseTable=dbo.ProductionOrders address=ProductCode databaseRow=Key databaseKeyColumn=OrderNo databaseKeyValue=4711

Esempio: un setpoint di ricetta da PostgreSQL

Il sistema delle ricette aggiunge una riga a recipe_setpoints ogni volta che un setpoint cambia, datata nella sua colonna updated_at:

1. Aggiungi dispositivo; chiamarlo Recipes, Tipo di database PostgreSQL, Server del database recipes-db, Porta vuoto (la 5432 di PostgreSQL), Nome del database recipes, poi Nome utente e Password di accesso sulla scheda Accesso.
2. Aggiungi tag Oven setpoint, Double: Tabella recipe_setpoints, Colonna del valore oven_temperature, Riga da leggere La più recente, Colonna data updated_at.

Ogni riga nuova si legge alla lettura successiva del tag. PostgreSQL legge un nome semplice in minuscolo, quindi una colonna creata con maiuscole, come OvenTemp, si scrive tra virgolette: "OvenTemp". Con gli strumenti:

device_upsert name=Recipes driver=Database databaseKind=PostgreSql host=recipes-db databaseName=recipes username=station password=<password>
tag_upsert device=Recipes name="Oven setpoint" opcUaType=Double databaseTable=recipe_setpoints address=oven_temperature databaseRow=Newest databaseDateColumn=updated_at

Esempio: una riga di risultato scritta con un INSERT

Il sistema qualità vuole una riga per pezzo misurato nella sua tabella test_results:

1. Sul dispositivo di quel database, Aggiungi tag Result, Double, Accesso Sola scrittura.
2. Una scrittura Esegue il suo comando di scrittura, e in Comando di scrittura scrivere INSERT INTO test_results (result, recorded_at) VALUES (@value, @now), che aggiunge la riga.

Ogni valore che Logic scrive in Result diventa una riga a sé, con accanto la data e l'ora della stazione; le scritture che si susseguono rapidamente vengono tutte tenute, in ordine, nessuna scartata per una più nuova. Un tag in Lettura e scrittura che legge una cella cambierebbe invece la sua unica riga a ogni scrittura. Con gli strumenti:

tag_upsert device=Quality name=Result opcUaType=Double accessType=WriteOnly databaseWriteMode=Command databaseCommand="INSERT INTO test_results (result, recorded_at) VALUES (@value, @now)"

Esempio: Access e Oracle tramite ODBC

Quando l'origine dati o il driver che un dispositivo indica esiste solo per i programmi a 32 bit (un Access di un Office a 32 bit, un'origine dati creata in Origine dati ODBC (32 bit)), oppure non esiste affatto su questo computer, il pannello del dispositivo dice quale dei due casi è, con il nome che il dispositivo ha dato, e dà l'istruzione completa finché il dispositivo è attivo e non si connette. L'errore del dispositivo dice lo stesso in inglese, e così driver_capabilities, nel prerequisite del driver Database (perDevice true):

L'avviso termina con i driver ODBC a 64 bit di questo computer, con il nome che prende Driver={...}. Un'origine dati o un driver che esiste a 64 bit e che fallisce comunque mostra l'errore proprio del gestore dei driver.

Tramite ODBC un nome semplice si legge come lo legge il database (in maiuscolo su Oracle) e un nome tra virgolette esattamente; date e ore vengono inviate al secondo intero, la precisione più fine che ogni driver ODBC accetta. Con gli strumenti:

device_upsert name="Plant book" driver=Database databaseKind=Odbc databaseOdbc="Driver={Microsoft Access Driver (*.mdb, *.accdb)};Dbq=C:\Data\plant.accdb"
device_upsert name=ERP driver=Database databaseKind=Odbc databaseOdbc=ERP username=STATION password=<password>

Strumenti dell'agente

driver_capabilities descrive questo driver sotto database: il percorso semplice, ogni database con i suoi campi e la sua porta propria, le scelte di crittografia, i due modi in cui un tag legge e i due in cui scrive, la regola per cui un valore entra in un'istruzione solo come @value o @now, i tipi, i tempi di attesa, il consiglio sull'utente del database, il rilevamento e quattro esempi completi. device_upsert driver=Database accetta databaseKind (SqlServer, il predefinito, PostgreSql, MySql, Sqlite o Odbc), e per un server host (un server\INSTANCE o server,port di SQL Server viene separato), port, databaseName, e su SQL Server databaseInstance, databaseWindowsSignIn e databaseEncryption (Verified, TrustServerCertificate o Off); databaseFile per SQLite, databaseOdbc per ODBC; username e password, che non viene mai restituita. Un dispositivo che restituisce porta database, con l'indirizzo e se il dispositivo attende ancora il suo utente. tag_upsert accetta la colonna del valore come address, databaseSource (Fields o Query), databaseTable, databaseRow (Key o Newest), databaseKeyColumn, databaseKeyValue, databaseDateColumn, databaseQuery, e quando l'accessType scrive, databaseWriteMode (Cell o Command) e databaseCommand; un tag nuovo è in sola lettura e Double a meno che opcUaType dica altro. device_discover driver=Database accetta databaseDevice, il nome di un dispositivo configurato del driver, e facoltativamente databaseTables, un nome di tabella o un modello con *; i tag che mancano al dispositivo si aggiungono con tag_upsert. connector_browse restituisce il databaseKind di ogni dispositivo. Gli altri strumenti si trovano in Strumenti dell'agente.

Limiti da conoscere

• Il driver legge e scrive i valori dei suoi tag, un valore per tag. Non registra le prove della stazione in un database: una riga per prova con il suo numero di serie, il suo verdetto e le sue misure non è qualcosa che questo driver scrive.
• Nessun driver ODBC viene fornito con il prodotto. Oracle, Access, Firebird e ogni database diverso dai quattro raggiunti direttamente hanno bisogno del loro driver ODBC a 64 bit installato sul computer; uno a 32 bit non viene visto.
• Il dispositivo non conserva nessuna password di Windows: l'accesso Windows a SQL Server, e un file SQLite su una condivisione di rete, usano l'account con cui gira la stazione, quindi il database o la condivisione devono lasciar entrare quell'account.
• Una query legge soltanto. Ciò che cambia il database è una scrittura, e una scrittura avviene solo su un tag il cui accesso scrive.
• Un valore non entra mai nel testo di un'istruzione: il valore scritto è sempre il parametro @value, la data e l'ora della stazione @now, e anche un valore chiave è un parametro. Un'istruzione che nomina qualsiasi altro valore viene rifiutata.
• Una scrittura di cella cambia esattamente una riga; un comando UPDATE ha bisogno del suo WHERE.
• Il database viene interrogato a ogni lettura: un cambiamento che fa un altro programma si vede alla lettura successiva, e un database con molti tag di una stessa riga viene interrogato una volta per passata per tutti.
• Una colonna binaria non viene letta.