AULA 4

SISTEMAS SUPERVISÓRIOS

Profª Ana Carolina Bueno Franco

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,
02
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;

03
  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.].

04
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:

05
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

06
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:

07
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.

08
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.

09
 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.

010
 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:

011
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).

012
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).

013
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.

014
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.

015