Database

Valores que um sistema da fábrica guarda numa tabela de banco de dados (SQL Server, PostgreSQL, MySQL e MariaDB, SQLite, ou qualquer banco de dados por ODBC) lidos como tags, e escritos de volta onde uma tag manda: os cartões Banco de dados e Entrada, uma tag que lê uma célula pela tabela, pela coluna e pela linha ou executa uma consulta própria, os dois jeitos de uma tag escrever, a varredura que oferece uma tag por coluna, quatro exemplos completos e o que o driver não faz.

O driver Database lê os valores que um sistema da fábrica guarda numa tabela de banco de dados: a ordem de produção que o MES mantém, a receita ou o setpoint que o ERP guarda, o resultado que outro sistema de ensaio registrou. Cada tag lê um valor de uma tabela, e os valores chegam onde chegam os de toda outra tag: no Logic, nos dashboards, nas execuções de uma bancada de teste do Process. Onde uma tag manda, o driver também escreve de volta: na célula que a tag lê, ou por um comando próprio da tag.

SQL Server, PostgreSQL, MySQL e MariaDB, e SQLite são acessados sem nada instalado no computador. Qualquer outro banco de dados (Oracle, Access, Firebird e outros) é acessado pelo próprio driver ODBC, que precisa estar instalado no computador na versão de 64 bits.

Ler é o uso principal, e o caminho é curto: um dispositivo diz onde está o banco de dados e como a estação entra nele, a varredura oferece uma tag por coluna das tabelas, e toda tag nasce somente leitura. O que é de escrita só aparece numa tag depois que o acesso dela deixa a estação escrever.

Um dispositivo deste driver é um banco de dados: dois bancos de dados do mesmo servidor são dois dispositivos. Os dispositivos ficam sob o driver e podem ser arquivados em pastas, Driver → Pasta → Dispositivo → Tag, como em todo driver sem linha serial nem broker.

A página do driver

A linha sob o cabeçalho diz "Cada dispositivo lê um banco de dados. Acrescente um dispositivo, informe onde está o banco de dados dele e como a estação entra, e depois varra-o para acrescentar as colunas como tags." Para Configurar Connector, a página traz o cartão Escopo da varredura próprio do driver, com o dispositivo cujo banco de dados a varredura lê (veja Descoberta). Abaixo dele fica a tabela Dispositivos de qualquer driver (veja A tabela de dispositivos), que cresce com Acrescentar dispositivo, à direita do título; vazia, diz "Nenhum dispositivo ainda." A barra do driver traz Descobrir, cinza até o cartão Escopo da varredura estar completo. O driver aparece em Arquivos e bancos de dados, ao lado do driver File.

Dispositivo

Um dispositivo deste driver não tem cartão Conexão: o cartão Banco de dados fica no lugar dele, seguido do cartão Entrada em todo banco de dados menos o SQLite, que não tem entrada. O Intervalo de leitura (ms) do cartão Dispositivo, 1000 por padrão, diz de quanto em quanto tempo as tags leem o banco de dados, com cada tag podendo sobrescrevê-lo como em qualquer driver.

Um dispositivo novo é um SQL Server sem servidor: diz "Servidor ainda não informado", a página dele diz "A estação não alcança este dispositivo enquanto ele não disser onde está o banco de dados dele, então nada é lido dele ainda e não há erro a mostrar. Informe isso no cartão Banco de dados abaixo (o servidor e o nome do banco de dados, o arquivo ou a origem de dados) e a estação se conecta a ele." e nada é lido até ele dizer. A Base URI que o cabeçalho mostra é o endereço de runtime, que nunca traz o usuário nem a senha: database://sqlserver?server=mes-sql&instance=SQLEXPRESS&database=MES para uma instância do SQL Server, database://sqlite?file=C%3A%5CData%5Crecipes.db para um arquivo SQLite, database://odbc?source=ERP para uma origem de dados ODBC.

O cartão Banco de dados

Um campo que o tipo escolhido não lê não aparece, e guarda o valor para quando ler. Escolher outro tipo esvazia uma porta deixada na porta própria do banco de dados anterior, para que o novo seja acessado na dele. A caixa Servidor separa o que as ferramentas de banco de dados escrevem juntos:

Enquanto o cartão não diz onde está o banco de dados, o dispositivo é salvo como está e aguarda, com o ponto cinza, nada lido e nenhum erro mostrado:

Uma configuração que o cartão não aceita é dita abaixo dos cartões, e o dispositivo não é salvo até ela ser corrigida:

O salvamento segue as mesmas regras, e o feed diz quando recusa uma: "O dispositivo 'MES' tem uma configuração de banco de dados que o driver não consegue usar. Abra-o e corrija o campo que o painel marca."

O cartão Entrada

Todo banco de dados menos o SQLite traz o cartão Entrada, com o usuário com que a estação entra.

PostgreSQL e MySQL não têm o campo Criptografia: a conexão deles é criptografada sempre que o servidor oferece. Um SQL Server com certificado próprio, como costuma ser o de um servidor de fábrica, recusa a conexão com as palavras do banco de dados sobre uma cadeia de certificados emitida por uma autoridade em que não se confia: Criptografada, qualquer certificado aceito é a escolha que esse servidor pede.

Abaixo dos campos, o cartão diz que usuário pedir: "Peça ao administrador do banco de dados um usuário só com as permissões de que a estação precisa: leitura, e escrita só nas tabelas que as tags dela mudam." A estação lê e escreve os dados de outro sistema com tudo o que o usuário dela pode fazer, então esse usuário é o limite real do que a estação consegue mudar. Toda escrita é registrada no diário, como em todo driver.

Um servidor em que se entra com usuário, sem usuário informado ainda, diz em vez disso "Informe o usuário com que a estação entra. Até lá a estação não conecta este dispositivo." Não é uma recusa: o dispositivo é salvo, e o erro dele diz que nenhum usuário do banco de dados foi informado ainda, até o usuário estar lá.

Online, aguardando e offline

Cada dispositivo tem uma conexão só dele, aberta quando ele se conecta e nunca compartilhada nem guardada num pool, então uma conexão que um servidor derrubou nunca é usada de novo.

Preparar o servidor

Os três bancos de rede vêm fechados a outro computador em instalações comuns. Cada um destes ajustes é feito no servidor, por quem o administra; a estação não muda nenhum deles.

Todos eles precisam também da porta do banco liberada no firewall do computador do servidor. Quando o servidor responde de um desses jeitos, a página do dispositivo diz qual ajuste é, com estes passos e os valores deste dispositivo (a porta, a instância, o endereço desta estação como o servidor o viu, a linha do pg_hba.conf e a conta do MySQL, cada um com um botão de copiar), no lugar do erro em inglês do banco. O aviso some sozinho quando o dispositivo conecta, ou quando o servidor responde de outro jeito. O registro e o agente leem os mesmos passos.

Endereçamento de tags

Como uma tag lê

Uma tag deste driver não tem caixa de endereço própria: o cartão Origem dela pergunta como ela lê.

Uma tag nova lê Tabela e coluna, pela chave, como Double. Os tipos oferecidos são Boolean, Int32, Int64, Float, Double, String e DateTime. Ao ler uma célula, uma tag de número inteiro recusa um valor com fração em vez de arredondá-lo (a escrita é o contrário, veja Escrita), e um texto só é lido como número quando é um. Toda tag nasce Somente leitura; o que a escrita acrescenta está em Escrita.

Tabela e coluna

Um nome é lido do jeito que o banco de dados o lê:

O driver põe cada parte de um nome entre as aspas que o banco de dados dele aceita, então um nome nunca é colado numa instrução como texto. Uma tag cujos campos não funcionam não é salva, e a página dela diz o que falta:

A linha somente leitura Endereço de origem (barramento) mostra o que o driver recebe: row?table=dbo.ProductionOrders&column=Quantity&key=OrderNo&equals=4711 para uma linha pela chave, newest?table=recipe_setpoints&column=oven_temperature&by=updated_at para a linha mais recente.

Consulta própria

A consulta é lida do jeito que o banco de dados a lê: o que fica dentro de um texto entre aspas, de um nome entre aspas ou de um comentário não é palavra da instrução. Uma consulta que faz mais do que ler é recusada onde é digitada:

O endereço de barramento de uma tag de consulta é query?sql= seguido da consulta, codificada em porcentagem.

Leitura

Uma leitura que falhou mantém a última leitura da tag, que conta como falha quando fica mais velha que o intervalo de leitura dela mais 10 s, como em todo driver. O banco de dados é consultado a cada leitura: uma mudança que outro programa faz é vista na leitura seguinte, nunca no instante em que é feita.

Escrita

Uma tag só escreve depois que o Acesso dela é Leitura e escrita ou Somente escrita. O cartão Origem dela então acrescenta o que uma escrita faz:

Uma tag Somente escrita que executa o comando de escrita dela não lê nada, então o cartão Origem dela traz só a escrita.

Um comando que o driver não consegue executar é recusado na página da tag:

Os nomes com @@, as funções do SQL Server, e os nomes de argumento de um EXEC (@speed = @value) não são valores e ficam como estão escritos. O salvamento segue as mesmas regras, e o feed diz quando recusa uma tag: "A tag 'Order quantity' não diz onde está o valor dela no banco de dados, ou tem uma consulta ou um comando de escrita que o driver recusa. Abra-a e corrija o campo que o painel da tag marca."

O endereço de barramento acrescenta a escrita: row?table=recipes&column=setpoint&key=code&equals=R-100&write=cell para uma célula, none?write=command&command= seguido do comando para uma tag Somente escrita que executa o comando dela.

Descoberta

O cartão Escopo da varredura

Para Configurar Connector, a página do driver traz o cartão Escopo da varredura, sob a linha "Entra como o dispositivo entra e oferece uma tag para cada coluna das tabelas dele, na linha mais recente ou na linha da menor chave."

Um driver sem dispositivo traz só "Um banco de dados é varrido por meio de um dispositivo, que guarda a entrada dele. Acrescente um dispositivo deste driver e diga onde está o banco de dados dele." O que ainda falta ao escopo é dito em vermelho abaixo do cartão, e Descobrir continua cinza até ele estar completo:

Quando o dispositivo a varrer tem uma edição que não pode ser salva, a varredura não começa: "A descoberta não começou porque a edição do dispositivo a varrer não pôde ser salva."

O que a varredura oferece

A varredura entra como o dispositivo entra, lê a lista que o próprio banco de dados tem das tabelas e das views dele (sem as do sistema) e das colunas delas, e diz que tabela lê, como "Lendo as colunas de recipes…". Ela oferece um candidato, o próprio dispositivo, marcado como Já configurado: o cartão dele lista, marcadas, as colunas que nenhuma tag do dispositivo lê ainda, e Acrescentar tags, antes de Abrir, acrescenta as marcadas ao dispositivo, somente leitura.

As tags recebem o nome da tabela e da coluna (recipes.oven_temperature), o tipo da coluna, e toda uma é Somente leitura. Uma varredura lê no máximo 100 tabelas e 500 valores; uma cortada ali diz "A varredura de Recipes parou antes. Uma varredura lê no máximo 100 tabelas e 500 valores: informe um nome de tabela ou um padrão para ver os outros." O resto do comportamento da varredura está em Descoberta.

A própria página de um dispositivo faz o mesmo sem a página do driver: Descobrir tags, no cabeçalho do cartão de tags dele, entra como o dispositivo entra, varre o banco de dados dele como ele está salvo e oferece só as colunas para as quais ele ainda não tem tag (veja Descobrir as tags de um dispositivo).

Exemplo: uma ordem de produção do SQL Server

O MES guarda as ordens de produção no SQL Server, na tabela dbo.ProductionOrders do banco de dados MES, uma linha por número de ordem:

1. Na página do driver, Acrescentar dispositivo; dê o nome MES. No cartão Banco de dados mantenha SQL Server, informe Servidor mes-sql (ou mes-sql\SQLEXPRESS para uma instância nomeada), deixe Porta vazia e informe Nome do banco de dados MES.
2. No cartão Entrada informe Usuário station_reader e a Senha dele, ou ligue Entrar com a conta do Windows da estação. Para um servidor de fábrica com certificado próprio, escolha Criptografada, qualquer certificado aceito.
3. Acrescentar tag Order quantity, Int32: Tabela dbo.ProductionOrders, Coluna do valor Quantity, Linha a ler Pela chave, Coluna-chave OrderNo, Valor-chave 4711. O endereço de barramento dela é row?table=dbo.ProductionOrders&column=Quantity&key=OrderNo&equals=4711.
4. Acrescentar tag Product, String, na mesma tabela e na mesma linha, Coluna do valor ProductCode: as duas tags são lidas numa só consulta.

Com as ferramentas:

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

Exemplo: um setpoint de receita do PostgreSQL

O sistema de receitas acrescenta uma linha a recipe_setpoints toda vez que um setpoint muda, datada na coluna updated_at:

1. Acrescentar dispositivo; dê o nome Recipes, Tipo de banco de dados PostgreSQL, Servidor recipes-db, Porta vazia (a 5432 do PostgreSQL), Nome do banco de dados recipes, e depois Usuário e Senha no cartão Entrada.
2. Acrescentar tag Oven setpoint, Double: Tabela recipe_setpoints, Coluna do valor oven_temperature, Linha a ler A mais recente, Coluna de data updated_at.

Cada linha nova é lida na leitura seguinte da tag. O PostgreSQL lê um nome simples em minúsculas, então uma coluna criada com maiúsculas, como OvenTemp, é escrita entre aspas: "OvenTemp". Com as ferramentas:

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

Exemplo: uma linha de resultado escrita como INSERT

O sistema de qualidade quer uma linha por peça medida na tabela test_results dele:

1. No dispositivo desse banco de dados, Acrescentar tag Result, Double, Acesso Somente escrita.
2. Uma escrita Executa o comando de escrita dela, e no Comando de escrita escreva INSERT INTO test_results (result, recorded_at) VALUES (@value, @now), que acrescenta a linha.

Cada valor que o Logic escreve em Result vira uma linha própria, com a data e a hora da estação ao lado; escritas que vêm uma atrás da outra são todas mantidas, em ordem, nenhuma descartada por uma mais nova. Uma tag Leitura e escrita que lê uma célula mudaria, em vez disso, a única linha dela a cada escrita. Com as ferramentas:

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

Exemplo: Access e Oracle por ODBC

Quando a origem de dados ou o driver que um dispositivo indica existe só para programas de 32 bits (um Access de um Office de 32 bits, uma origem de dados criada em Fontes de Dados ODBC (32 bits)), ou não existe neste computador, o painel do dispositivo diz qual dos dois casos é, com o nome que o dispositivo deu, e dá a instrução inteira enquanto o dispositivo está ligado e não conecta. O erro do dispositivo diz o mesmo em inglês, e o driver_capabilities também, no prerequisite do driver Database (perDevice true):

O aviso termina com os drivers ODBC de 64 bits que este computador tem, pelo nome que o Driver={...} leva. Uma origem de dados ou um driver que existe em 64 bits e mesmo assim falha mostra o erro do próprio gerenciador de drivers.

Pelo ODBC, um nome simples é lido como o banco de dados o lê (em maiúsculas no Oracle) e um nome entre aspas exatamente; datas e horas são enviadas no segundo inteiro, o mais fino que todo driver ODBC aceita. Com as ferramentas:

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>

Ferramentas do agente

driver_capabilities descreve este driver em database: o caminho simples, cada banco de dados com os campos e a porta própria, as escolhas de criptografia, os dois jeitos de uma tag ler e os dois de escrever, a regra de que um valor só entra numa instrução como @value ou @now, os tipos, os tempos de espera, o conselho sobre o usuário do banco de dados, a descoberta e quatro exemplos completos. device_upsert driver=Database aceita databaseKind (SqlServer, o padrão, PostgreSql, MySql, Sqlite ou Odbc), e para um servidor host (um server\INSTANCE ou server,port do SQL Server é separado), port, databaseName, e no SQL Server databaseInstance, databaseWindowsSignIn e databaseEncryption (Verified, TrustServerCertificate ou Off); databaseFile para o SQLite, databaseOdbc para o ODBC; username e password, que nunca é devolvida. Um dispositivo que ele devolve traz database, com o endereço e se o dispositivo ainda aguarda o usuário. tag_upsert aceita a coluna do valor como address, databaseSource (Fields ou Query), databaseTable, databaseRow (Key ou Newest), databaseKeyColumn, databaseKeyValue, databaseDateColumn, databaseQuery, e quando o accessType escreve, databaseWriteMode (Cell ou Command) e databaseCommand; uma tag nova é somente leitura e Double, a menos que opcUaType diga outra coisa. device_discover driver=Database aceita databaseDevice, o nome de um dispositivo configurado do driver, e opcionalmente databaseTables, um nome de tabela ou um padrão com *; as tags que faltam ao dispositivo são acrescentadas com tag_upsert. connector_browse devolve o databaseKind de cada dispositivo. As outras ferramentas estão em Ferramentas do agente.

Limites que vale conhecer

• O driver lê e escreve os valores das tags dele, um valor por tag. Ele não registra as execuções da estação num banco de dados: uma linha por execução com o número de série, o veredito e as medidas não é algo que este driver escreve.
• Nenhum driver ODBC vem com o produto. Oracle, Access, Firebird e todo banco de dados que não seja um dos quatro acessados diretamente precisam do próprio driver ODBC de 64 bits instalado no computador; um de 32 bits não é visto.
• O dispositivo não guarda senha do Windows: a entrada no SQL Server com a conta do Windows, e um arquivo SQLite num compartilhamento de rede, usam a conta em que a estação roda, então o banco de dados ou o compartilhamento precisa deixar essa conta entrar.
• Uma consulta só lê. O que muda o banco de dados é uma escrita, e uma escrita só acontece numa tag cujo acesso escreve.
• Um valor nunca entra no texto de uma instrução: o valor escrito é sempre o parâmetro @value, a data e a hora da estação @now, e um valor-chave também é um parâmetro. Uma instrução que nomeia qualquer outro valor é recusada.
• Uma escrita de célula muda exatamente uma linha; um comando UPDATE precisa do WHERE dele.
• O banco de dados é consultado a cada leitura: uma mudança que outro programa faz é vista na leitura seguinte, e um banco de dados com muitas tags de uma mesma linha é consultado uma vez por passada para todas elas.
• Uma coluna binária não é lida.