Database

Les valeurs qu'un système de l'usine garde dans une table de base de données (SQL Server, PostgreSQL, MySQL et MariaDB, SQLite, ou toute base de données par ODBC) lues comme tags, et réécrites là où un tag le demande : les cartes Base de données et Connexion à la base, un tag qui lit une cellule par sa table, sa colonne et sa ligne ou exécute une requête propre, les deux façons dont un tag écrit, le balayage qui propose un tag par colonne, quatre exemples complets et ce que le pilote ne fait pas.

Le pilote Database lit les valeurs qu'un système de l'usine garde dans une table de base de données : l'ordre de fabrication que tient le MES, la recette ou la consigne que garde l'ERP, le résultat qu'un autre système d'essai a enregistré. Chaque tag lit une valeur d'une table, et ses valeurs arrivent là où arrivent celles de tout autre tag : dans Logic, sur les tableaux de bord, dans les essais d'un banc de test de Process. Là où un tag le demande, le pilote écrit aussi en retour : dans la cellule que lit le tag, ou par une commande propre au tag.

SQL Server, PostgreSQL, MySQL et MariaDB, et SQLite sont atteints sans rien installer sur l'ordinateur. Toute autre base de données (Oracle, Access, Firebird et d'autres) est atteinte par son propre pilote ODBC, qui doit être installé sur l'ordinateur dans sa version 64 bits.

La lecture est l'usage principal, et son chemin est court : un équipement dit où se trouve sa base de données et comment la station s'y connecte, le balayage propose un tag par colonne de ses tables, et chaque tag naît en lecture seule. Ce qui relève de l'écriture n'apparaît sur un tag qu'une fois que son accès laisse la station écrire.

Un équipement de ce pilote est une base de données : deux bases de données du même serveur sont deux équipements. Les équipements se rangent sous le pilote et peuvent être classés dans des dossiers, Pilote → Dossier → Équipement → Tag, comme sous tout pilote sans ligne série ni broker.

La page du pilote

La ligne sous l'en-tête indique « Chaque équipement lit une base de données. Ajoutez un équipement, saisissez où se trouve sa base de données et comment la station se connecte, puis balayez-le pour ajouter ses colonnes comme tags. » Pour Configurer le connector, la page porte la carte Portée du balayage propre au pilote, avec l'équipement dont le balayage lit la base de données (voir Découverte). En dessous se trouve le tableau Équipements de tout pilote (voir Le tableau des équipements), qui grandit avec Ajouter un équipement, à droite de son titre; vide, il indique « Aucun équipement pour l'instant. » La barre du pilote porte Découvrir, grisé tant que la carte Portée du balayage n'est pas complète. Le pilote est rangé sous Fichiers et bases de données, à côté du pilote File.

Équipement

Un équipement de ce pilote n'a pas de carte Connexion : la carte Base de données en tient la place, suivie de la carte Connexion à la base sur toute base de données sauf SQLite, qui n'a pas de connexion. L'Intervalle de scrutation (ms) de la carte Équipement, 1000 par défaut, dit à quelle fréquence les tags lisent la base de données, et chaque tag peut le remplacer comme sous tout pilote.

Un nouvel équipement est un SQL Server sans serveur : il indique « Serveur pas encore saisi », sa page dit « La station n'atteint pas cet équipement tant qu'il ne dit pas où se trouve sa base de données : rien n'est donc encore lu depuis lui et il n'y a aucune erreur à afficher. Saisissez-le dans la carte Base de données ci-dessous (le serveur et le nom de la base de données, le fichier ou la source de données) et la station s'y connecte. » et rien n'est lu tant qu'il ne le dit pas. La Base URI que montre l'en-tête est l'adresse d'exécution, qui ne contient jamais l'utilisateur ni le mot de passe : database://sqlserver?server=mes-sql&instance=SQLEXPRESS&database=MES pour une instance SQL Server, database://sqlite?file=C%3A%5CData%5Crecipes.db pour un fichier SQLite, database://odbc?source=ERP pour une source de données ODBC.

La carte Base de données

Un champ que le type choisi ne lit pas n'est pas affiché, et garde sa valeur pour le jour où il le lit. Choisir un autre type vide un port resté sur le port propre à l'ancienne base de données, pour que la nouvelle soit atteinte sur le sien. La case Serveur répartit ce que les outils de bases de données écrivent ensemble :

Tant que la carte ne dit pas où se trouve la base de données, l'équipement est enregistré tel quel et attend, point gris, sans rien lire et sans afficher d'erreur :

Un réglage que la carte ne peut pas prendre est signalé sous les cartes, et l'équipement n'est pas enregistré tant qu'il n'est pas corrigé :

L'enregistrement applique les mêmes règles, et le fil le dit quand il en refuse une : « L'équipement 'MES' a un réglage de base de données que son pilote ne peut pas utiliser. Ouvrez-le et corrigez le champ que son panneau signale. »

La carte Connexion à la base

Toute base de données sauf SQLite porte la carte Connexion à la base, avec l'utilisateur sous lequel la station se connecte.

PostgreSQL et MySQL n'ont pas de champ Chiffrement : leur connexion est chiffrée dès que le serveur le propose. Un SQL Server dont le certificat est le sien, comme l'est souvent celui d'un serveur d'usine, refuse la connexion avec les mots de la base de données sur une chaîne de certificats émise par une autorité qui n'est pas approuvée : Chiffrée, tout certificat accepté est le choix que ce serveur demande.

Sous ses champs, la carte dit quel utilisateur demander : « Demandez à l'administrateur de la base de données un utilisateur qui n'a que les droits dont la station a besoin : la lecture, et l'écriture seulement dans les tables que ses tags modifient. » La station lit et écrit les données d'un autre système avec tout ce que son utilisateur peut faire : cet utilisateur est donc la vraie limite de ce que la station peut modifier. Chaque écriture est inscrite au journal technique, comme sous tout pilote.

Un serveur où l'on se connecte avec un utilisateur, sans utilisateur encore saisi, dit à la place « Saisissez l'utilisateur avec lequel la station se connecte. D'ici là, la station ne connecte pas cet équipement. » Ce n'est pas un refus : l'équipement est enregistré, et son erreur dit qu'aucun utilisateur de la base de données n'est encore saisi, jusqu'à ce que l'utilisateur soit là.

En ligne, en attente et hors ligne

Chaque équipement a sa propre connexion, ouverte quand il se connecte et jamais partagée ni gardée dans un pool : une connexion qu'un serveur a coupée n'est jamais réutilisée.

Préparer le serveur

Les trois bases de données réseau sont livrées fermées à un autre ordinateur dans les installations courantes. Chacun de ces réglages se fait sur le serveur, par celui qui l'administre; la station n'en change aucun.

Toutes demandent aussi le port de la base autorisé dans le pare-feu de l'ordinateur du serveur. Quand le serveur répond de l'une de ces façons, la page de l'équipement dit de quel réglage il s'agit, avec ces étapes et les valeurs de cet équipement (le port, l'instance, l'adresse de cette station telle que le serveur l'a vue, la ligne de pg_hba.conf et le compte MySQL, chacun avec un bouton de copie), à la place de l'erreur en anglais de la base. L'avis disparaît de lui-même dès que l'équipement se connecte, ou quand le serveur répond autrement. Le journal et l'agent lisent les mêmes étapes.

Adressage du tag

Comment un tag lit

Un tag de ce pilote n'a pas de case d'adresse à lui : sa carte Source de la valeur demande comment il lit.

Un nouveau tag lit Table et colonne, par sa clé, en Double. Les types proposés sont Boolean, Int32, Int64, Float, Double, String et DateTime. À la lecture d'une cellule, un tag de nombre entier refuse une valeur avec une partie décimale plutôt que de l'arrondir (l'écriture fait l'inverse, voir Écriture), et un texte ne se lit comme nombre que s'il en est un. Chaque tag naît en Lecture seule; ce que l'écriture ajoute se trouve dans Écriture.

Table et colonne

Un nom se lit comme la base de données le lit :

Le pilote met chaque partie d'un nom entre les guillemets que sa base de données accepte : un nom n'est donc jamais collé dans une instruction comme du texte. Un tag dont les champs ne peuvent pas fonctionner n'est pas enregistré, et sa page dit ce qui lui manque :

La ligne en lecture seule Adresse source (bus) montre ce que reçoit le pilote : row?table=dbo.ProductionOrders&column=Quantity&key=OrderNo&equals=4711 pour une ligne par sa clé, newest?table=recipe_setpoints&column=oven_temperature&by=updated_at pour la ligne la plus récente.

Requête propre

La requête se lit comme la base de données la lit : ce qui se trouve dans un texte entre guillemets, un nom entre guillemets ou un commentaire n'est pas un mot de l'instruction. Une requête qui fait plus que lire est refusée là où elle est saisie :

L'adresse de bus d'un tag de requête est query?sql= suivi de la requête, encodée en pourcentage.

Lecture

Une lecture en échec garde la dernière lecture du tag, qui compte comme en échec une fois plus ancienne que son intervalle de scrutation plus 10 s, comme sous tout pilote. La base de données est interrogée à chaque lecture : un changement fait par un autre programme se voit à la lecture suivante, jamais à l'instant où il est fait.

Écriture

Un tag n'écrit qu'une fois que son Accès est Lecture et écriture ou Écriture seule. Sa carte Source de la valeur ajoute alors ce que fait une écriture :

Un tag en Écriture seule qui exécute sa commande d'écriture ne lit rien : sa carte Source de la valeur ne contient que l'écriture.

Une commande que le pilote ne peut pas exécuter est refusée sur la page du tag :

Les noms en @@, les fonctions de SQL Server, et les noms d'argument d'un EXEC (@speed = @value) ne sont pas des valeurs et restent tels qu'ils sont écrits. L'enregistrement applique les mêmes règles, et le fil le dit quand il refuse un tag : « Le tag 'Order quantity' ne dit pas où se trouve sa valeur dans la base de données, ou a une requête ou une commande d'écriture que son pilote refuse. Ouvrez-le et corrigez le champ que le panneau du tag signale. »

L'adresse de bus ajoute l'écriture : row?table=recipes&column=setpoint&key=code&equals=R-100&write=cell pour une cellule, none?write=command&command= suivi de la commande pour un tag en Écriture seule qui exécute sa commande.

Découverte

La carte Portée du balayage

Pour Configurer le connector, la page du pilote porte sa carte Portée du balayage, sous la ligne « Se connecte comme le fait l'équipement et propose un tag pour chaque colonne de ses tables, à la ligne la plus récente ou à la ligne de la plus petite clé. »

Un pilote sans équipement ne contient que « Une base de données se balaie à travers un équipement, qui garde sa connexion. Ajoutez un équipement de ce pilote et dites où se trouve sa base de données. » Ce qui manque encore à la portée est dit en rouge sous la carte, et Découvrir reste grisé tant qu'elle n'est pas complète :

Quand l'équipement à balayer a une modification qui ne peut pas être enregistrée, le balayage ne démarre pas : « La découverte n'a pas démarré parce que la modification de l'équipement à balayer n'a pas pu être enregistrée. »

Ce que le balayage propose

Le balayage se connecte comme le fait l'équipement, lit la liste que la base de données elle-même tient de ses tables et de ses vues (celles du système exclues) et de leurs colonnes, et dit quelle table il lit, comme « Lecture des colonnes de recipes… ». Il propose un candidat, l'équipement lui-même, marqué Déjà configuré : sa carte liste, cochées, les colonnes qu'aucun tag de l'équipement ne lit encore, et Ajouter les tags, avant Ouvrir, ajoute celles qui sont cochées à l'équipement, en lecture seule.

Les tags sont nommés d'après leur table et leur colonne (recipes.oven_temperature), typés d'après le type de la colonne, et chacun est en Lecture seule. Un balayage lit au plus 100 tables et 500 valeurs; un balayage coupé là dit « Le balayage de Recipes s'est arrêté tôt. Un balayage lit au plus 100 tables et 500 valeurs : donnez un nom de table ou un motif pour voir les autres. » Le reste du comportement du balayage se trouve dans Découverte.

La page d'un équipement fait la même chose sans la page de son pilote : Découvrir les tags, dans l'en-tête de sa carte des tags, se connecte comme l'équipement, balaie sa base de données tel qu'il est enregistré et ne propose que les colonnes pour lesquelles il n'a pas encore de tag (voir Découvrir les tags d'un équipement).

Exemple : un ordre de fabrication depuis SQL Server

Le MES garde ses ordres de fabrication dans SQL Server, dans la table dbo.ProductionOrders de la base de données MES, une ligne par numéro d'ordre :

1. Sur la page du pilote, Ajouter un équipement; nommez-le MES. Sur la carte Base de données gardez SQL Server, saisissez Serveur mes-sql (ou mes-sql\SQLEXPRESS pour une instance nommée), laissez Port vide et saisissez Nom de la base de données MES.
2. Sur la carte Connexion à la base saisissez Nom d'utilisateur station_reader et son Mot de passe, ou activez Se connecter avec le compte Windows de la station. Pour un serveur d'usine dont le certificat est le sien, choisissez Chiffrée, tout certificat accepté.
3. Ajouter un tag Order quantity, Int32 : Table de la valeur dbo.ProductionOrders, Colonne de la valeur Quantity, Ligne à lire Par sa clé, Colonne clé OrderNo, Valeur clé 4711. Son adresse de bus est row?table=dbo.ProductionOrders&column=Quantity&key=OrderNo&equals=4711.
4. Ajouter un tag Product, String, sur la même table et la même ligne, Colonne de la valeur ProductCode : les deux tags sont lus en une seule requête.

Avec les outils :

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

Exemple : une consigne de recette depuis PostgreSQL

Le système de recettes ajoute une ligne à recipe_setpoints chaque fois qu'une consigne change, datée dans sa colonne updated_at :

1. Ajouter un équipement; nommez-le Recipes, Type de base de données PostgreSQL, Serveur recipes-db, Port vide (le 5432 de PostgreSQL), Nom de la base de données recipes, puis Nom d'utilisateur et Mot de passe sur la carte Connexion à la base.
2. Ajouter un tag Oven setpoint, Double : Table de la valeur recipe_setpoints, Colonne de la valeur oven_temperature, Ligne à lire La plus récente, Colonne de date updated_at.

Chaque nouvelle ligne est lue à la lecture suivante du tag. PostgreSQL lit un nom simple en minuscules : une colonne créée avec des majuscules, comme OvenTemp, s'écrit donc entre guillemets, "OvenTemp". Avec les outils :

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

Exemple : une ligne de résultat écrite par un INSERT

Le système qualité veut une ligne par pièce mesurée dans sa table test_results :

1. Sur l'équipement de cette base de données, Ajouter un tag Result, Double, Accès Écriture seule.
2. Une écriture Exécute sa commande d'écriture, et dans Commande d'écriture saisissez INSERT INTO test_results (result, recorded_at) VALUES (@value, @now), qui ajoute la ligne.

Chaque valeur que Logic écrit dans Result devient une ligne à part, avec la date et l'heure de la station à côté; les écritures qui se suivent de près sont toutes gardées, dans l'ordre, aucune abandonnée pour une plus récente. Un tag en Lecture et écriture qui lit une cellule modifierait au contraire son unique ligne à chaque écriture. Avec les outils :

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

Exemple : Access et Oracle par ODBC

Quand la source de données ou le pilote qu'un équipement nomme n'existe que pour les programmes 32 bits (un Access d'un Office 32 bits, une source de données créée dans Sources de données ODBC (32 bits)), ou n'existe pas du tout sur cet ordinateur, le panneau de l'équipement dit lequel des deux cas c'est, avec le nom que l'équipement a donné, et donne l'instruction complète tant que l'équipement est activé et ne se connecte pas. L'erreur de l'équipement dit la même chose en anglais, et driver_capabilities aussi, dans le prerequisite du pilote Database (perDevice true) :

L'avis se termine par les pilotes ODBC 64 bits de cet ordinateur, sous le nom que prend Driver={...}. Une source de données ou un pilote que le côté 64 bits a, et qui échoue quand même, montre l'erreur propre du gestionnaire de pilotes.

Par ODBC, un nom simple se lit comme la base de données le lit (en majuscules sous Oracle) et un nom entre guillemets exactement; les dates et les heures sont envoyées à la seconde entière, la précision la plus fine que tout pilote ODBC accepte. Avec les outils :

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>

Outils de l'agent

driver_capabilities décrit ce pilote sous database : le chemin simple, chaque base de données avec ses champs et son port propre, les choix de chiffrement, les deux façons dont un tag lit et les deux dont il écrit, la règle selon laquelle une valeur n'entre dans une instruction que comme @value ou @now, les types, les délais, le conseil sur l'utilisateur de la base de données, la découverte et quatre exemples complets. device_upsert driver=Database accepte databaseKind (SqlServer, la valeur par défaut, PostgreSql, MySql, Sqlite ou Odbc), et pour un serveur host (un server\INSTANCE ou server,port de SQL Server est réparti), port, databaseName, et sur SQL Server databaseInstance, databaseWindowsSignIn et databaseEncryption (Verified, TrustServerCertificate ou Off); databaseFile pour SQLite, databaseOdbc pour ODBC; username et password, qui n'est jamais rendu. Un équipement qu'il renvoie porte database, avec l'adresse et le fait que l'équipement attend encore ou non son utilisateur. tag_upsert accepte la colonne de la valeur comme address, databaseSource (Fields ou Query), databaseTable, databaseRow (Key ou Newest), databaseKeyColumn, databaseKeyValue, databaseDateColumn, databaseQuery, et une fois que l'accessType écrit, databaseWriteMode (Cell ou Command) et databaseCommand; un nouveau tag est en lecture seule et en Double sauf si opcUaType dit autre chose. device_discover driver=Database accepte databaseDevice, le nom d'un équipement configuré du pilote, et facultativement databaseTables, un nom de table ou un motif avec *; les tags qui manquent à l'équipement s'ajoutent avec tag_upsert. connector_browse renvoie le databaseKind de chaque équipement. Les autres outils se trouvent dans Outils de l'agent.

Limites à connaître

• Le pilote lit et écrit les valeurs de ses tags, une valeur par tag. Il n'enregistre pas les essais de la station dans une base de données : une ligne par essai avec son numéro de série, son verdict et ses mesures n'est pas quelque chose que ce pilote écrit.
• Aucun pilote ODBC n'est livré avec le produit. Oracle, Access, Firebird et toute base de données autre que les quatre atteintes directement ont besoin de leur propre pilote ODBC 64 bits installé sur l'ordinateur; un pilote 32 bits n'est pas vu.
• L'équipement ne garde aucun mot de passe Windows : la connexion Windows à SQL Server, et un fichier SQLite sur un partage réseau, utilisent le compte sous lequel roule la station, et la base de données ou le partage doit donc laisser entrer ce compte.
• Une requête ne fait que lire. Ce qui modifie la base de données est une écriture, et une écriture n'a lieu que sur un tag dont l'accès écrit.
• Une valeur n'entre jamais dans le texte d'une instruction : la valeur écrite est toujours le paramètre @value, la date et l'heure de la station @now, et une valeur clé est aussi un paramètre. Une instruction qui nomme toute autre valeur est refusée.
• Une écriture de cellule modifie exactement une ligne; une commande UPDATE a besoin de son WHERE.
• La base de données est interrogée à chaque lecture : un changement fait par un autre programme se voit à la lecture suivante, et une base de données qui a beaucoup de tags d'une même ligne est interrogée une fois par passe pour tous.
• Une colonne binaire n'est pas lue.