Aula 4 - Sistemas Supervisórios

Prévia do material em texto

AULA 4 
 
 
 
 
 
 
 
 
 
SISTEMAS SUPERVISÓRIOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Profª Ana Carolina Bueno Franco 
 
 
 
02 
CONVERSA INICIAL 
O planejamento de uma indústria está ligado à análise e ao 
armazenamento de dados. Nesse contexto, o supervisório tem um papel 
essencial: coletar os dados do chão de fábrica e direcionar para um banco de 
dados. Por esse motivo, não basta realizar o controle e a supervisão do processo, 
é preciso projetar o sistema e considerar como será feito o armazenamento dos 
dados, bem como as análises (transformar dados em informação). 
Vários módulos do supervisório dependem dos dados armazenados. Para 
entender isso melhor, o objetivo desta aula é conhecer: 
 os conceitos básicos de banco de dados; 
 os principais bancos de dados do mercado e suas características; 
 os históricos em supervisórios e como configurá-los; 
 o modo como são feitas as consultas nos supervisórios; 
 alguns comandos da linguagem SQL; 
 o uso de fórmulas e o modo como são gerados os relatórios. 
CONTEXTUALIZANDO 
Ao especificar um projeto de automação que envolva sistema supervisório, 
é preciso considerar diversos fatores: máquinas (servidores), rede de 
comunicação, integração com outros sistemas e banco de dados. Muitas funções 
e módulos dos supervisórios dependem diretamente do armazenamento de 
dados. Conhecer os sistemas disponíveis no mercado e seus conceitos básicos 
auxiliará o gestor de automação a identificar a melhor opção de acordo com as 
necessidades. 
TEMA 1 – BANCO DE DADOS: CONCEITOS BÁSICOS 
O conceito de banco de dados é bastante genérico. De forma geral, trata-
se de uma “coleção” de objetos que, de alguma forma, estão relacionados entre 
si. Dados considerados randômicos, que não possuem qualquer tipo de relação, 
não podem constituir um banco de dados. 
Outra característica do banco de dados é que este deve ter um grupo de 
usuários definidos e aplicações (consultas) pré-definidas (Cavalcanti, 2014). 
Um termo bastante utilizado e que gera dúvidas com relação ao conceito 
em si é o Sistema Gerenciador de Banco de Dados – SGBD (Elmasri; Navathe, 
 
 
03 
2005). Um SGBD pode ser definido como uma “coleção” de programas (softwares) 
cujas etapas são: 
 Definição: consiste em especificar quais serão os tipos de dados, estruturas 
e restrições para que os dados possam ser armazenados. 
 Construção: implica no processo de armazenamento dos dados (servidores 
etc.). 
 Manipulação: consiste na definição de funções e consultas dos dados e na 
geração de relatórios customizados pelos usuários. 
 Compartilhamento: definição da arquitetura e do modo como os dados 
serão compartilhados entre usuários. 
 Manutenção e segurança: etapa contínua e que exige extremo cuidado. Um 
SGBD deve estar alocado em uma rede com alto grau de segurança. 
Vejamos uma síntese desses conceitos básicos na Figura 1: 
Figura 1 – Conceitos básicos de banco de dados 
 
Fonte: Cavalcanti, 2014. 
A implementação de banco de dados na indústria é uma tarefa complexa e 
requer profissionais especializados. Existem vários fatores a serem considerados: 
 especificação de servidores; 
 redundância; 
 especificação de softwares e sistemas que dependem do uso desses 
dados; 
 
 
04 
 integração entre as áreas. 
A responsabilidade de gerir o banco de dados, bem como o SGBD e os 
sistemas relacionados, cabe ao administrador de banco de dados, conhecido 
como Database Administrator – DBA (Elmasri; Navathe, 2005). 
Com relação ao projeto, é preciso definir um modelo de dados (descrever 
a estrutura do banco, o tipo de dados, os relacionamentos e as restrições). Os 
modelos de dados são compostos de: 
 Entidades: relacionadas a um objeto do mundo real (pode ser objeto, 
pessoa etc.), como, por exemplo, funcionário. 
 Atributo: relacionado a alguma propriedade da entidade, como, por 
exemplo, nome do funcionário. 
 Relacionamento: tipo de associação entre duas ou mais entidades, como, 
por exemplo, um projeto em comum entre vários funcionários. 
A Figura 2 ilustra um exemplo: 
Figura 2 – Modelo entidade relacionamento 
 
Fonte: Modelagem..., [S.d.]. 
 
 
 
05 
TEMA 2 – BANCO DE DADOS E SISTEMAS SUPERVISÓRIOS 
Todos os fornecedores de sistemas supervisórios disponibilizam acesso a 
diversos sistemas gerenciadores de bancos de dados. Os mais usados no 
mercado são o Microsoft SQL e o Oracle. Em geral, o acesso ao banco é nativo. 
Na etapa de desenvolvimento, é preciso selecionar qual será o banco de dados 
escolhido, o usuário administrador e a finalidade de uso. 
Link (2014) aponta que “o Access da Microsoft 
(<https://products.office.com/pt-br/access>) é utilizado em aplicações de pequeno 
porte e tem a vantagem de ser facilmente configurado. Sua desvantagem é que o 
tamanho do arquivo de dados cresce rapidamente e se torna instável a partir de 
100 MB”. Segundo o autor: 
O SQL Server, também da Microsoft (<https://www.microsoft.com/pt-
br/sql-server/sql-server-2016>), possui um excelente desempenho, é 
estável e bastante utilizado em aplicações de grande porte. Outra 
vantagem importante é que a Microsoft disponibiliza uma versão gratuita, 
que suporta arquivo de dados para até 10 GB. Sua desvantagem é que, 
em caso de desligamento durante a sua atualização de dados, não há 
um recurso que o proteja contra falhas. (Link, 2014) 
Já o Oracle (<https://www.oracle.com/br/index.html>), para Link (2014), 
“também é bastante utilizado para aplicações de grande porte, possui alta 
velocidade e requisitos de segurança e confiabilidade. Sua desvantagem é que 
exige profissionais com alta especialização técnica”. Portanto, cabe ao gestor de 
automação especificar em conjunto com a equipe de informática os custos de 
implementação do banco e a manutenção do sistema. 
Temos um exemplo na Figura 3: 
 
 
06 
Figura 3 – Escolha do banco de dados no supervisório Elipse E3 
 
Fonte: Elipse Software, 2017. 
Um ponto que gera muita dúvida é o dimensionamento do banco de dados. 
É muito importante considerar que nem todas as variáveis que estão sendo 
supervisionadas e controladas serão armazenadas. Isso deve ser especificado na 
etapa de projeto, prevendo também futuras expansões na aplicação. 
As informações armazenadas servirão para os históricos (consulta dos 
dados), análise de alarmes (conforme visto nas aulas anteriores, os alarmes 
também são armazenados) e fórmulas. 
TEMA 3 – HISTÓRICOS EM SUPERVISÓRIOS 
O módulo conhecido por históricos é responsável pelo armazenamento das 
informações que o supervisório está coletando de campo (através de 
Controladores Lógicos Programáveis – CLP). Os dados armazenados serão 
utilizados para análises futuras, seja no próprio supervisório ou em outros 
 
 
07 
sistemas. É nesse módulo que se define quais serão as variáveis armazenadas e 
em qual banco de dados elas serão salvas (Figura 4). 
Figura 4 – Configuração do histórico no supervisório Elipse E3 (definição das 
variáveis) 
 
Fonte: Elipse Software, 2017. 
O armazenamento das variáveis pode ser definido por tempo ou através de 
eventos. Quando as variáveis são inseridas no histórico, é necessário que o 
programador defina uma chave primária, e esta chave primária pode ser definida 
como um campo (ou informação) único que identifica um objeto. 
O Cadastro de Pessoas Físicas (CPF), por exemplo, pode ser considerado 
uma chave primária, pois cada brasileiro tem um CPF cuja sequência de números 
é única. Não existem brasileiros com um mesmo número de CPF. 
É importante estabelecer a chave primária, pois ela será utilizada em 
associações entre tabelas. Além disso, o banco de dados não permitirá que sejam 
inseridas chaves primárias duplicadas. Existem dois tipos de chave primária: 
1. chave primária simples: formada por um único campo; 
2. chave primária composta: formada pela combinação de dois ou mais 
campos da tabela.Ao definir uma chave primária, seja ela simples ou composta, é preciso 
levar em consideração que: 
 uma tabela de banco de dados pode ter uma única chave primária; 
 os valores não podem ser repetidos ou duplicados; 
 não é possível ter valores “nulos”. 
Vejamos um exemplo de definição da chave primária na Figura 5: 
 
 
08 
Figura 5 – Definição da chave primária em vermelho (supervisório Elipse E3) 
 
Fonte: Elipse Software, 2017. 
Outro campo importante de ser definido é o “índice”. Esse campo é utilizado 
para otimizar o desempenho de uma consulta e geralmente é pré-definido pelo 
banco. Caso o índice não seja utilizado, durante uma consulta, o banco fará a 
leitura desde o primeiro registro até que localize registros relevantes, o que faz 
com que as consultas fiquem mais lentas. 
A Figura 6 ilustra um editor de índices: 
Figura 6 – Editor de índices (supervisório Elipse E3) 
 
Fonte: Elipse Software, 2017. 
 
 
 
09 
TEMA 4 – CONSULTAS AO BANCO DE DADOS EM SUPERVISÓRIOS 
Após estabelecer o banco de dados, as tabelas do projeto e variáveis de 
processo a serem armazenas, é necessário criar consultas aos dados. Uma 
consulta, ou Query, é realizada para buscar informações específicas 
estabelecidas pelo usuário. 
A consulta pode ser realizada por scripts ou por meio de interfaces gráficas. 
Para qualquer operação no banco de dados (desde gravar ou localizar dados), 
são utilizados comandos no formato Structured Query Language (SQL). 
A linguagem SQL é utilizada em bancos de dados relacionais. Foi criada 
em 1974 pela IBM baseada na álgebra relacional (Maciel, 2013). Algumas 
cláusulas básicas da SQL (Figura 7): 
 SELECT – utilizada para buscar as informações de interesse do usuário. 
 FROM – mostrará todas as tabelas que contêm as informações que o 
usuário buscou através da cláusula SELECT. 
 WHERE – especifica critérios de campo que devem ser atendidos para 
cada registro. 
 ORDER BY – especifica como será a ordenação dos dados. 
Figura 7 – Tela de consulta (supervisório Elipse E3) 
 
Fonte: Elipse Software, 2017. 
 
 
010 
As consultas realizadas podem ser mostradas aos usuários por meio de 
tabelas e gráficos. Esses objetos também são usados para mostrar dados em 
tempo real, alarmes e históricos (Figuras 8 e 9). 
Figura 8 – Dados visualizados em forma de tabela (supervisório Elipse E3) 
 
Fonte: Elipse Software, 2017. 
Figura 9 – Dados visualizados em forma de gráfico (supervisório Elipse E3) 
 
Fonte: Elipse Software, 2017. 
TEMA 5 – FÓRMULAS E RELATÓRIOS 
As fórmulas ou receitas podem ser definidas como um conjunto de valores 
pré-definidos para um determinado grupo de variáveis. Podem ser comparadas a 
uma receita. O usuário vai definir o que deve ser armazenado em cada variável, 
bem como suas restrições, e carregá-las no supervisório sempre que necessário. 
 
 
011 
Os supervisórios permitem a alteração desses parâmetros em tempo de 
execução. As fórmulas estão relacionadas às tabelas do banco de dados, pois 
seus valores devem ficar armazenados (Figuras 10 e 11). 
Figura 10 – Tabela criada para armazenar uma fórmula (supervisório Elipse E3) 
 
Fonte: Elipse Software, 2017. 
Figura 11 – Configuração de valores em uma fórmula (supervisório Elipse E3) 
 
Fonte: Elipse Software, 2017. 
O relatório é outro módulo muito importante do supervisório e que também 
está diretamente relacionado ao banco de dados. Independentemente do 
departamento em que atue, o usuário do supervisório vai gerar relatórios 
específicos, de acordo com a sua consulta de dados. 
Os relatórios podem ser customizados por usuário e também ser gerados 
com uma periodicidade programada, como, por exemplo, um relatório diário da 
produção de determinados produtos. 
Cada fornecedor de supervisório disponibiliza ferramentas específicas para 
a geração e a configuração dos relatórios. Existem, inclusive, componentes 
ActiveX (visto em aulas anteriores) específicos para isso. De modo geral, um 
relatório é organizado por seções, conforme indicado na Figura 12: 
 
 
012 
Figura 12 – Seções de um relatório 
 
Fonte: Elipse Software, 2017. 
 Report Header – utilizada para mostrar o título. Aparece somente uma vez 
no relatório. 
 Page Header – usada para mostrar cabeçalho de colunas, número de 
páginas, títulos de páginas ou qualquer outra informação que precise ser 
impressa no início de cada página. 
 Group Header/Footer – usadas para colocar informações adicionais antes 
e depois do corpo do relatório. 
 Detail – é a seção que mostra os dados consultados. 
 Page Footer – usada para imprimir número de páginas ou qualquer 
informação que precise ser mostrada uma só vez. 
O modo de configuração do relatório depende das funcionalidades do 
sistema escolhido. É possível inserir consultas que já façam cálculos, objetos 
gráficos e figuras (Figuras 13 e 14). 
 
 
013 
Figura 13 – Configuração de relatório de alarmes (supervisório Elipse E3) 
 
Fonte: Elipse Software, 2017. 
Figura 14 – Configuração de relatório de nível (supervisório Elipse E3) 
 
Fonte: Elipse Software, 2017. 
O relatório pode ser visualizado em tela, e também há possibilidade de 
exportar para um arquivo, por exemplo, em formato PDF, XLS, DOC etc. (Figura 
15). 
 
 
014 
Figura 15 – Configuração de impressão do relatório (supervisório Elipse E3) 
 
Fonte: Elipse Software, 2017. 
FINALIZANDO 
O armazenamento dos dados provenientes do supervisório é muito 
importante. Esses dados serão visualizados e analisados de diversas formas, seja 
por tabelas, gráficos ou relatórios. É imprescindível prever um bom sistema de 
banco de dados que, em conjunto com o supervisório, possa atender à demanda 
dos usuários. 
 
 
 
015 
REFERÊNCIAS 
CAVALCANTI, T. R. Introdução a banco de dados. ITnerante, [S.l.], 19 nov. 2014. 
Disponível em: <http://www.itnerante.com.br/profiles/blogs/artigo-01-bd01-
introdu-o-a-banco-de-dados>. Acesso em: 14 mar. 2018. 
ELIPSE SOFTWARE. Tutorial do E3 para Desenvolvedores. Porto Alegre: 
Elipse Software, 2017. 
ELMASRI, R.; NAVATHE, S. B. Sistemas de banco de dados. São Paulo: 
Pearson Addison Wesley, 2005. 
LINK, D. Usando Bancos de dados no E3: Capítulo 1 – Escolhendo o Banco de 
Dados. Elipse Knowledgebase, Porto Alegre, 24 jun. 2014. Disponível em: 
<http://kb.elipse.com.br/pt-
br/questions/4181/Usando+Bancos+de+dados+no+E3%3A+Capítulo+1+-
+Escolhendo+o+Banco+de+Dados>. Acesso em: 14 mar. 2018. 
MACIEL, J. SQL Structured Query Language (Banco de Dados). 2013. 
Disponível em: 
<http://www.ppgsc.ufrn.br/~rogerio/material_auxiliar/CLP20132_SQL.pdf>. 
Acesso em: 14 mar. 2018. 
MODELAGEM de dados. Universidade Católica de Brasília – Informática e 
Educação, Brasília, [S.d.]. Disponível em: 
<https://cae.ucb.br/conteudo/programar/banco/new_bancomodelagem.html>. 
Acesso em: 14 mar. 2018.