UNIVERSIDADE FEEVALE

ÉMERSON BUTZEN

APLICAÇÃO DA ORIENTAÇÃO A OBJETOS EM SISTEMAS DE

AUTOMAÇÃO INDUSTRIAL

Novo Hamburgo
2014
 ÉMERSON BUTZEN

APLICAÇÃO DA ORIENTAÇÃO A OBJETOS EM SISTEMAS DE

AUTOMAÇÃO INDUSTRIAL

Trabalho apresentado como requisito parcial

do Curso de Pós-Graduação Especialização em
Automação e Controle da Universidade
Feevale para obtenção do grau de especialista.

Orientador: Prof. Esp. Rafael Lima

Novo Hamburgo
2014
AGRADECIMENTOS

Gostaria de agradecer a todos os que, de alguma

maneira, contribuíram para a realização desse
trabalho de conclusão, em especial:

A minha esposa, pela paciência em todas as

noites e finais de semana e pelo meu mau
humor, meu orientador por acreditar em mim e
aos amigos pela parceria de sempre, minha
gratidão.
 RESUMO

O desenvolvimento deste trabalho propõe o encontro entre concepções das áreas de

automação e controle, engenharia e qualidade de software. Tal temática é relevante, pois
promove reflexões, cujas soluções implicam redução de custos nos processos industriais,
diante da aplicação do paradigma de Orientação a Objetos à automação. O objetivo central
desse estudo é modelar uma aplicação (software) de automação industrial já desenvolvida,
aplicando as técnicas do paradigma de Orientação a Objetos introduzidos a partir da norma
IEC 61131, utilizando o software MasterTool IEC IEC XE da Altus. Nesse sentido, a questão
que norteia esse estudo estabelece-se: como diminuir o custo de desenvolvimento e
manutenção em aplicações de automação industrial? Acredita-se ainda, que sob essa aplicação
seja viável a redução de custos em projetos de automação em cerca de vinte por centro (20%).
O marco teórico compõe-se das elucidações de Capretz (2003), Meyer (2000), Buyya (2009),
Bolshakova (2005) e Guimarães (2005). Os principais resultados desse estudo referem-se à
confirmação de ganhos diante da aplicação do paradigma de Orientação a Objetos à
automação industrial, uma vez que os códigos gerados através deste paradigma se mostraram
mais organizados, passíveis de reutilização e permitem uma manutenção mais rápida e
apropriada.

Palavras-chave: Automação e Controle; Norma IEC 61131-3; Function Block; Engenharia de

Software; Orientação a Objetos.
 ABSTRACT

The development of this work proposes an encounter between conceptions of control systems,
software engineer and software quality. This issue is relevant because it promotes reflections,
whose solutions require cost reduction in industrial processes, by the application of Object-
oriented paradigm to automation. The central objective of this study is to model an application
(software) already developed industrial automation, applying the techniques of Object-
oriented paradigm introduced from IEC 61131, using the Altus MasterTool IEC XE software.
In this sense, the question guiding this study establishes itself: how to reduce the cost of
development and maintenance in industrial automation applications? It is believed that in this
application is feasible to reduce costs in automation projects in about twenty per center (20
%). The theoretical framework consists of elucidations of Capretz (2003), Meyer (2000),
Buyya (2009), Bolshakova (2005) and Guimarães (2005). The main results of this study refer
to the confirmation gains before applying the Object-oriented paradigm to industrial
automation, since the codes generated by this paradigm were more organized, reusable and
allow a faster and proper maintenance.

Key words: Control Systems; Standard IEC 61131; Function Block; Software Engineer;
Object-oriented paradigm.
 LISTA DE FIGURAS

Figura 2.1 – Descrição simples do sistema de controle _____________________________ 16

Figura 2.2 – Componentes de um sistema de controle industrial ______________________ 17
Figura 2.3 – Pirâmide da Automação Industrial ___________________________________ 19
Figura 3.1 – Áreas influenciadoras do paradigma de Orientação a Objetos _____________ 23
Figura 3.2 – Fusão de técnicas e paradigmas de linguagens de programação ____________ 24
Figura 3.3 – Entidade abstrata de um veículo ____________________________________ 26
Figura 3.4 – Objeto instanciado da entidade abstrata veículo ________________________ 26
Figura 3.5 – Mapeamento de entidade real no paradigma de Orientação a Objetos _______ 27
Figura 3.6 – Divisão da IEC 61131-3 ___________________________________________ 35
Figura 3.7 – Comunicação remota usando caminho de acesso _______________________ 38
Figura 3.8 – Modelo de software da IEC 61131-3 _________________________________ 40
Figura 3.9 – Linguagens de programação da norma IEC 61131-3_____________________ 41
Figura 3.10 – Bloco funcional em linguagem texto estruturado ______________________ 42
Figura 3.11 – Exemplo em linguagem de lista de instruções _________________________ 43
Figura 3.12 – Exemplo em linguagem Logic Ladder _______________________________ 44
Figura 3.13 – Exemplo em linguagem de Diagrama de Blocos Funcionais______________ 45
Figura 3.14 – Exemplo em linguagem de Sequenciamento Gráfico de Funções __________ 46
Figura 4.1 – Lógica atual Usiminas ____________________________________________ 48
Figura 4.2 – Identificação das entradas e saídas da Lógica atual Usiminas ______________ 50
Figura 4.3 – Classe L01_Class que representa a lógica das linhas 1, 3, 5 e 7 ____________ 51
Figura 4.4 – Classe L02_Class que representa a lógica das linhas 2, 4, 6 e 8 ____________ 52
Figura 4.5 – Aplicação mista: cabeçalho da aplicação com bloco funcional L01_Class ____ 52
Figura 4.6 – Aplicação mista: lógicas da aplicação da aplicação com o FB L01_Class ____ 53
Figura 4.7 – Etapas do processo de desenvolvimento através do paradigma de OO _______ 54
Figura 4.8 – Aplicação: cabeçalho da aplicação com os FBs L01_Class e L02_Class _____ 55
Figura 4.9 – Bloco funcional L02_Class_Com_Heranca com base no FB L01_Class _____ 56
Figura 4.10 – Sistema após a aplicação da L02_Class_Com_Heranca _________________ 57
 LISTA DE TABELAS

Tabela 3.1 – Partes da norma IEC 61131 ________________________________________ 31

Tabela 3.2 – Certificação dos ambientes IEC 61131-3 _____________________________ 33
Tabela 3.3 Primeira letra escrita para representar a variável de representação direta ______ 36
Tabela 3.4 Segunda letra escrita para representar a variável de representação direta ______ 36
Tabela 4.1 – Perfil de sistemas ________________________________________________ 59
Tabela 4.2 – Possível custo de manutenção com aplicações _________________________ 59
 LISTA DE ABREVIATURAS E SIGLAS

BF Bloco Funcional
CLP Controlador Lógico Programavel
EN Enable Input
ENO Enable Output
ERP Enterprise Resource Planning
EUA Estados Unidos da América
FB Function Block
FBD Function Block Diagram
IEC International Electrotechnical Commission
IHM Interface Homem Máquina
IL Instruction List
LD Ladder Diagram
MV Manipulated Variable
OO Orientação a Objetos
OOP Object-Oriented Programming
PID Proporcional Integral Derivativo
PLC Programmable Logic Controller
POO Programação Orientada a Objetos
POU Program Organization Units
PV Process Variable
SCADA Supervisory Control and Data Acquisition
SFC Sequential Function Chart
ST Structured Text
TC Technical Committee
 SUMÁRIO

1 INTRODUÇÃO _________________________________________________________ 11
1.1 Considerações iniciais _________________________________________________ 11
1.2 Tema e objetivos _____________________________________________________ 12
1.3 Justificativa _________________________________________________________ 13
1.4 Delimitação do tema, problema e hipótese _________________________________ 14
1.5 Organização _________________________________________________________ 14
2 ENGENHARIA DE AUTOMAÇÃO E CONTROLE __________________________ 15
2.1 Definição da Automação _______________________________________________ 15
2.2 Os componentes básicos _______________________________________________ 17
2.3 Pirâmide da Automação Industrial _______________________________________ 19
2.4 Engenharia de software aplica à automação ________________________________ 20
3 ORIENTAÇÃO A OBJETOS E A NORMA IEC 61131-3 ______________________ 22
3.1 Orientação a Objetos __________________________________________________ 22
3.1.1 Abstração ______________________________________________________ 25
3.1.2 Classes ________________________________________________________ 26
3.1.3 Herança _______________________________________________________ 27
3.1.4 Polimorfismo ___________________________________________________ 28
3.1.5 Ligação dinâmica ________________________________________________ 28
3.1.6 Encapsulamento _________________________________________________ 29
3.1.7 Concorrência ___________________________________________________ 29
3.1.8 Coletor de lixo __________________________________________________ 30
3.1.9 Persistência de objetos ____________________________________________ 30
3.1.10 Generalização __________________________________________________ 30
3.2 Norma IEC 61131-3 __________________________________________________ 31
3.2.1 Origem ________________________________________________________ 31
3.2.2 PLCopen ______________________________________________________ 32
3.2.3 Introdução à IEC 61131-3 _________________________________________ 34
3.2.4 Tipagem de dados _______________________________________________ 35
3.2.5 Variáveis ______________________________________________________ 35
3.2.6 Blocos Funcionais (FB) ___________________________________________ 37
3.2.7 Funções _______________________________________________________ 37
3.2.8 Configuração ___________________________________________________ 37
3.2.9 Caminhos de acesso ______________________________________________ 38
3.2.10 Recursos _______________________________________________________ 39
3.2.11 Tarefas ________________________________________________________ 39
3.2.12 Programas _____________________________________________________ 39
3.2.13 Modelo de software IEC 61131-3 ___________________________________ 39
3.2.14 Fluxo de controle ________________________________________________ 40
3.2.15 Linguagens de programação _______________________________________ 41
3.2.16 Texto Estruturado (ST) ___________________________________________ 42
3.2.17 Lista de Instruções (IL) ___________________________________________ 42
3.2.18 Logic Ladder (LD) _______________________________________________ 43
3.2.19 Diagrama de Blocos Funcionais (FBD) _______________________________ 44
3.2.20 Sequenciamento Gráfico de Funções (SFC) ___________________________ 45
3.2.21 Orientação a Objeto na norma IEC 61131-3 ___________________________ 46
4 APLICANDO A ORIENTAÇÃO A OBJETOS _______________________________ 48
4.1 Aplicação atual ______________________________________________________ 48
4.2 Remodelando a Aplicação com Orientação a Objetos ________________________ 50
4.2.1 Abstração das lógicas ____________________________________________ 50
4.2.2 Construção dos Blocos Funcionais (Classes) __________________________ 51
4.2.3 Utilizando os Blocos Funcionais ____________________________________ 52
4.2.4 Herança em Blocos Funcionais _____________________________________ 56
4.2.5 Resultados _____________________________________________________ 58
CONSIDERAÇÕES FINAIS ________________________________________________ 61
REFERÊNCIAS __________________________________________________________ 62
APÊNDICES _____________________________________________________________ 65
1 INTRODUÇÃO

Neste capítulo são apresentadas as considerações iniciais, os objetivos, a justificativa

deste trabalho, sua metodologia e estrutura.

1.1 Considerações iniciais

A automação industrial, desde o surgimento do PLC sempre utilizou a linguagem

Ladder Logic para desenvolver as aplicações de controle de sistemas (COSTA, 2009). Durval
(2011) define que Ladder Logic é uma linguagem de programação que representa uma
aplicação através de um diagrama gráfico com base nos diagramas de lógica de relé. Esta
linguagem foi amplamente aceita por representar símbolos elétricos consagrados para
construir suas lógicas (MORAES; CASTRUCCI, 2001). A estrutura da linguagem é baseada
em formalismos computacionais básicos do tipo “se..então” (if..then), como por exemplo: se
uma entrada ou um conjunto de entradas (chaves lógicas) forem verdadeiras, é executada
(energizada) a saída (COSTA, 2009).

Durante muitos anos foram vários os dialetos de linguagem Ladder Logic

(GUIMARÃES, 2005), gerando assim uma forma despadronizada da linguagem. Para mudar
este cenário, em 1992, a IEC lançou a norma IEC 61131, que na sua terceira parte padroniza
as linguagens de programação para os PLCs (ALVES, 2008). Esta informação é relevante
pelo fato de que aproximadamente 50% da capacidade de produção dos Estados Unidos, tem
aplicações desenvolvidas em Ladder Logic como indica Aiken et al. (2000). No Brasil este
número pode ser ainda maior. Em 2007, a Schneider Electric, pioneira (SCHNEIDER
ELECTRIC, 2009), lançou um controlador de acordo com a norma internacional IEC 61131-3
(PORTAL FATOR BRASIL, 2007) e a partir de então, outras empresas buscaram adequar
seus produtos a norma.

Ainda conforme Costa (2009), com o passar do tempo, normalmente todo o sistema
desenvolvido cresce e se torna cada vez mais complexo, exibindo muitas entradas e muitas
saídas, além de várias interligações entre seus componentes na sua execução. Assim, a
programação do PLC torna-se de grande complexidade, gerando erros de difícil localização,
que muitas vezes exigem a execução do sistema para tentar descobrir um erro em uma, ou
mais lógicas, das muitas que existem na aplicação Ladder Logic.

Segundo Aiken et al. (2000), a linguagem Ladder Logic caracteriza-se como de

baixo nível, o que torna complexa a tarefa de escrever programas corretos. Com isso a
 12

validação das aplicações se torna extremamente cara, muitas vezes em milhões de dólares
para fábricas de poucas paradas. Esse tipo de fábrica, quando parada, costuma ter um prejuízo
em torno de 3.000,00 dólares por minuto (AIKEN et al., 2000).

Alguns destes problemas são vistos também na área da Ciência da Computação, onde
há um um número maior de paradigmas de programação. Buyya et al (2009) aponta que cada
linguagem de programação impõe um determinado estilo de programação e assim, influencia
a forma de organizar a informação. Este conjunto é conhecido como paradigma de
programação, que pode ser compartilhado entre diversas outras linguagens, inclusive a
linguagem Ladder Logic. Para Leite e Júnior (2002), um exemplo destes problemas ocorre ao
desenvolver um sistema de pequeno porte. Normalmente, se opta pela rapidez de codificá-lo
com técnicas do paradigma estruturado, utilizado pela linguagem Ladder Logic. Porém sua
manutenção é comprometida na relação custo-tempo, onde a manutenção em um software
codificado com a técnica da programação estruturada é muito mais difícil de ser realizada.

A mudança de cenário ocorreu quando foi criado um novo paradigma conhecido

como Orientação a Objeto (OO). Nesse caso, para a solução no exemplo do sistema de
pequeno porte, possivelmente bastaria alterar a classe1 primitiva para que todas as classes
derivadas recebam a correção, ou seja, a manutenção de um software criado com o paradigma
de Orientação a Objetos é muito mais fácil e mais rápida. Num software no paradigma
estruturado isto já não acontece, tendo as suas correções de serem replicadas em todos os
módulos que se façam necessárias (LEITE; JÚNIOR, 2002).

Este paradigma de Orientação a Objeto (OO) também está presente na IEC 61131-3,
permitindo que o usuário codifique sua aplicação utilizando este paradigma. Existem
ferramentas como o CoDeSys que implementam a norma e deixam para o usuário escolher
entre a programação clássica ou orientada a objetos (POO) ou combinar ambos paradigmas de
programação (3S, 2009).

1.2 Tema e objetivos

Este trabalho irá abordar dois temas principais: engenharia e qualidade de software.
A engenharia de software é um conjunto de princípios e técnicas que auxiliam desenvolver o
software de maneira científica (BUYYA et al., 2009). Já a qualidade de software é descrita

1
Classe é uma técnica da OO que será explorada no 3.1.10 do Capítulo 3.
 13

como a combinação de diversos fatores, sendo os principais fatores: funcionalidade,

confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade (MEYER; 2000).

Assim, o objetivo teste trabalho é modelar uma aplicação (software) de automação

industrial já desenvolvida, aplicando as técnicas do paradigma de Orientação a Objetos
introduzidos a partir da norma IEC 61131, utilizando o software MasterTool IEC XE da
Altus. Como objetivos específicos estabelecem-se:

 Modelar a aplicação utilizando os conceitos de abstração, classes, herança e

encapsulamento da Orientação a Objetos;

 Estabelecer se há um ganho real no tempo de manutenção da aplicação

modelada;

 Mostrar as vantagens e desvantagens da modelagem dos conceitos de

Orientação a Objeto em uma aplicação de automação industrial.

1.3 Justificativa

O tema explorado por este trabalho visa contribuir para uma mudança na cultura de
codificação de novos ou velhos sistemas de automação dentro das empresas integradoras de
soluções de automação.

Atualmente, as indústrias realizam esforços para mudar os processos de negócios

existentes, em estruturas ágeis orientadas para o cliente e assim sobreviver no ambiente de
negócios competitivo e global. Entre os esforços, está a automação das fábricas, pois permite
a resolução do problema de diminuição da produtividade e qualidade do produto. Como o
nível de automação aumenta, os fluxos de materiais e métodos de controle de processo do
chão de fábrica tornam-se mais complicados, assim, é essencial reduzir os erros de lógica em
um estágio anterior nos projetos de automação; antes da codificação da lógica de controle
(HAN; PARK, 2007).

Como visto, na área da Ciência da Computação é possível obter ganhos com a

aplicação das técnicas de Orientação a Objetos. Assim, justifica-se o estudo da aplicação de
técnicas também desenvolvimento de sistemas na área de Engenharia de Automação e
Controle.
 14

1.4 Delimitação do tema, problema e hipótese

Diante desta contextualização, delimita-se o tema à aplicação das técnicas do

paradigma de Orientação a Objetos para um problema de automação industrial tradicional.
Emerge, então, o problema que norteia esse estudo: como diminuir o custo de
desenvolvimento e manutenção em aplicações de automação industrial?

Como hipótese cogita-se a aplicação das técnicas de Orientação a Objetos a uma

aplicação de automação industrial escrito de maneira tradicional, das quais serão enfatizadas
as diferenças como o tempo investido em desenvolvimento e manutenção, além de apontar as
vantagens e desvantagens obtidas no decorrer do trabalho. Acredita-se ainda, que sob essa
aplicação seja viável a redução de custos em projetos de automação em cerca de quarenta por
centro (40%).

1.5 Organização

Esta construção monográfica é constituída de três capítulos, sendo dois teóricos e um

aplicado. Inicia-se com a revisão bibliográfica acerca das noções centrais relacionadas à
Automação e Controle em Engenharia. Tais aspectos serão ancorados em Moraes e Castrucci,
(2001) e Nise (2011). O segundo capítulo enfoca o paradigma de orientação ao objeto e sua
conexão com a norma IEC 61131-3, introduzida pela International Electrotechnical
Commission, que dentre outros, tem o objetivo de padronizar as linguagens de programação
utilizadas em projetos de engenharia de automação. Para abordar esses aspectos e promover
as aproximações esperadas, conta-se com as elucidações de Capretz (2003), Meyer (2000),
Buyya (2009), Bolshakova (2005) e Guimarães (2005).

A aplicação realizada neste estudo é apresentada no terceiro capítulo. Parte-se da

contextualização do ambiente e do sistema atual, o qual está ancorado na abordagem
tradicional de resolução das problemáticas, à aplicação do paradigma de Orientação a Objetos
através das técnicas de abstração, classes e heranças para resolução da mesma situação
adversa. Por fim, apresentam-se os resultados que respondem à questão proposta neste
trabalho, indicando uma forma alternativa ao desenvolvimento e manutenção de aplicações
industriais que impliquem na redução de custos às indústrias.
2 ENGENHARIA DE AUTOMAÇÃO E CONTROLE

Este capítulo é dedicado a Engenharia de Automação e Controle, a partir da

abordagem de aspectos históricos e conceituais da área.

2.1 Definição da Automação

Automation é uma palavra inventada pelo marketing da indústria de equipamentos na

década de 1960 para enfatizar a participação do computador no controle automático do
processo (MORAES; CASTRUCCI, 2001). De acordo com Georgini (2003) a participação do
computador no controle automático, em substituição aos sistemas de controle a relés, ocorreu
devido ao aumento da competitividade da indústria automotiva, que buscava melhor
desempenho das linhas de produção, tanto em qualidade quanto produtividade. Assim a
divisão Hydramatic da GM especificou o projeto do PLC, e a Gould Modicom em 1969
desenvolveu o primeiro dispositivo atendendo as seguintes especificações:

 preço competitivo com os sistemas a relés;

 dispositivos de entrada e de saída facilmente substituíveis;

 funcionamento em ambiente industrial (suportando vibração, calor, poeira,

ruídos, etc);

 facilidade na programação e manutenção por técnicos e engenheiros;

 repetibilidade de operação e uso.

O sucesso na instalação desse primeiro sistema em 1969 foi imediato. Funcionando

como substitutos dos relés, os PLCs mostraram-se mais confiáveis e permitiram a redução de
custos dos materiais, de mão de obra, de instalação e de localização de falhas. Também
permitiram a redução de fiação e seus erros associados por ocuparem menos espaços que os
sistemas sucedidos. Outro ponto forte para aceitação foi que sua linguagem se baseava no
diagrama Ladder, a lógica de relés, além de utilizar os símbolos elétricos consagrados
(MORAES; CASTRUCCI, 2001).

Moraes e Castrucci (2001) mostram que a automação começou no início do século

passado, através do controle lógico. Seu surgimento se deu a partir da necessidade de
interligar contadores, disjuntores, relés de proteção e chaves manuais para dar partida,
proteger componentes e vigiar as condições de segurança nos processos elétricos. Só a partir
 16

da criação do PLC é que os avanços teóricos do controle dinâmico dispararam, por ser um
conceito de incalculável poder tecnológico. Este controle utiliza-se das medidas das saídas do
sistema, a fim de melhorar o desempenho operacional num esquema de realimentação. Assim,
é capaz de aperfeiçoar os processos em que é aplicado seja em velocidade, precisão e em
custo (MORAES; CASTRUCCI, 2001).

Desses aspectos, pode-se afirmar que todo o sistema que se apoia em computadores
para substituir o trabalho humano, seja em favor da segurança, da qualidade dos produtos, da
melhora na produção e/ ou da redução de custos, é dito como um sistema de automação
(MORAES; CASTRUCCI apud MARTINS, 2013), que permite o aperfeiçoamento de
objetivos complexos das indústrias e serviços. Para Pinto (2013, p.9), automação é

um sistema de equipamentos eletrônicos e/ou mecânicos que controlam seu próprio

funcionamento, quase sem a intervenção do homem. Automação é diferente de
mecanização. A mecanização consiste simplesmente no uso de máquinas para
realizar um trabalho, substituindo assim o esforço físico do homem. Já a automação
possibilita fazer um trabalho por meio de máquinas controladas automaticamente,
capazes de se regularem sozinhas.

Nise (2011) cita exemplos destes sistemas que funcionam quase sempre sozinhos: a
usinagem automática de metais e os veículos autoguiados de entrega de material para as
estações de trabalho. Existem ainda sistemas automatizados, com os quais se convive
diariamente e que necessitam da interação com o homem, como as máquinas de café,
refrigerantes ou alimentos, que possuem processo sistematizado desde os aspectos
financeiros, relativos a pagamento e troco, até a seleção e acesso ao produto. A automação
pode também ser percebida na abertura de portões, seja através de sensores ou de controle
remoto.

Estes sistemas de controle são constituídos por subsistemas e processos, também

chamados de plantas, montados com a finalidade de se obter resultados e desempenhos
desejados, tendo em conta uma entrada especificada. A Figura 2.1 mostra um sistema de
controle na sua forma mais simples, em que a entrada representa uma saída desejada.

Figura 2.1 – Descrição simples do sistema de controle

Entradas Sistema de Controle Saídas

Fonte: adaptado de Nise (2011)

Conforme estas definições pode-se afirmar que a automação é um sistema que

interliga vários tipos de equipamentos. Para que estes funcionem corretamente existe algum
 17

tipo de controle que permite a manipulação dos equipamentos. Este controle normalmente é
uma lógica executada rotineiramente (em ciclos) no PLC.

2.2 Os componentes básicos

Todo sistema de controle precisa de algum tipo de controlador para garantir uma
operação segura e economicamente viável. Isto pode ser visto numa simples planta onde o
objetivo é controlar a temperatura através de um motor elétrico acionando um ventilador, ou
numa planta complexa que utiliza um reator nuclear para produção de energia elétrica. Assim,
todos os sistemas de controle são definidos em três partes: os transdutores, os controladores e
os atuadores (GUIMARÃES, 2005).

Martins (2013) completa afirmando que sistemas automatizados são, algumas vezes,
extremamente complexos, mas ao observar como é composto é possível notar que seus
subsistemas possuem características comuns e de simples entendimento, ou seja, vários
sistemas simples que junto formam um sistema grande e muito complexo. Portanto,
formalmente, um sistema automatizado possui os seguintes componentes básicos:

 transdutores;

 comparação e controle;

 atuadores.

Figura 2.2 – Componentes de um sistema de controle industrial

Fonte: Guimarães (2005)

 18

Guimarães (2005) explica que o controlador monitora o estado real do processo de

uma planta através dos transdutores, cujo é definido de acordo com a necessidade da
aplicação. Os transdutores, que podem ser digitais (discretos), ou seja, medem variáveis com
estados distintos, tais como ligado/desligado ou verdadeiro/falso, e podem ser analógicos,
onde medem variáveis com uma faixa contínua, tais como pressão, temperatura, vazão ou
nível, convertem as grandezas físicas em sinais normalmente elétricos, os quais são
conectados com as entradas dos controladores.

Com base nos estados das entradas, que alimentam as Variáveis de Processo (PV), o
controlador utiliza um algoritmo de controle embutido para calcular as Variáveis Manipuladas
(MV), alimentando os estados das suas saídas. Os sinais elétricos das saídas são convertidos
para o processo através dos atuadores, que geram movimentos como válvulas, motores,
bombas e outros e utilizam a energia potencial pneumática para o acionamento.

Apesar da automação dos processos, o operador é Figura importante, pois interage

com o controlador através dos parâmetros de controle como o Set Point. Pinto (2005)
exemplifica com o caso em que o operador seleciona a temperatura de referência, ou seja, um
set point no controlador. A saída do processo, por exemplo, a temperatura real da água quente
à saída do permutador de calor, é medida pelo transdutor de temperatura e comparada no
controlador com a temperatura de referência (set point) de modo a gerar um sinal de erro se o
set point não for alcançado. Caso o sinal de erro seja gerado, o controlador gera um sinal de
comando2 para o atuador, neste caso uma válvula de regulação de vapor. Assim, o sinal de
comando permite variar gradualmente a abertura ou fechamento da válvula e, por
conseguinte, a vazão de vapor a admitir no permutador, sendo possível controlar
automaticamente a temperatura da água à saída do permutador, sem que seja necessária a
intervenção manual do operador na planta.

Alguns controladores facilitam a vida do operador, pois mostram os estados do

processo através de um display, ou tela, que é chamado de IHM (GUIMARÃES, 2005). Em
plantas muito grandes, os controladores enviam as informações para um software SCADA,
que representa graficamente todo o processo, onde é possível ver os níveis e vazão de tanques,
por exemplo. Neste nível, normalmente se compartilha os dados com a rede de informação
gerencial, ou seja, a rede geral de informação da empresa se interliga com a rede de

2
Sinal de comando ou sinal de controle é o sinal de saída do regulador, é normalmente do tipo elétrico,
pneumático ou hidráulico. É enviado para o atuador através de uma interface de potência (amplificador,
conversor, etc.).
 19

supervisão e de controle, permitindo que importantes informações, tais como aquelas que
caracterizam desempenho de produção, possam ser analisadas pela gerência da empresa
(PINTO, 2005).

A partir desta contextualização, pode-se se abordar os níveis da pirâmide da

automação industrial.

2.3 Pirâmide da Automação Industrial

Como visto, a automação industrial exige a realização de várias funções, como ler,
armazenar, verificar, atuar, etc. Uma forma de representar todas as áreas envolvidas e a tarefa
das mesmas é a pirâmide da automação industrial, conforme a Figura 2.3.

Figura 2.3 – Pirâmide da Automação Industrial

Fonte: Moraes e Castrucci (2001)

A Figura 2.3 representa a pirâmide da automação industrial, na qual é possível

visualizar os diferentes níveis de controle de automação industrial, desde os equipamentos e
dispositivos em campo até o gerenciamento corporativo da empresa (SANTOS, 2013). A
descrição de cada um dos níveis, conforme Moraes e Castrucci (2001) é:

 nível 1: é o chão de fábrica, onde estão as máquinas, dispositivos e

componentes que medem e atuam no processo, todos estes componentes estão
envolvidos com o PLC;

 nível 2: com característica de ter alguma supervisão do processo, normalmente

é representado pelas interfaces homem máquinas (IHM) ou sistemas
 20

supervisórios, na qual há sempre uma variada quantidades de informações

sobre o nível 1;

 nível 3: apresenta informações sobre o controle do processo produtivo da

planta, normalmente composto por relatórios, estatísticas e índices de
qualidade da produção e do processo, além de índices de produtividade e
algoritmos de otimização da operação produtiva, tudo armazenado em um
grande banco de dados;

 nível 4: este nível é responsável pela parte de programação e também do

planejamento da produção, auxilia tanto no controle quanto também na
logística de suprimentos;

 nível 5: apresenta o nível gerencial da corporação, normalmente é um ERP

(Enterprise Resource Planning) responsável pela administração dos recursos
da empresa, tais como vendas, financeiro e estratégias de tomada de decisão.

Assim a Figura 2.3 demonstra, através da Pirâmide da Automação Industrial, uma

possibilidade para organização dos diferentes níveis de controle existentes através da divisão
em cinco níveis. Os níveis da base estão diretamente relacionados com os equipamentos
utilizados em campo, já os níveis superiores tratam do gerenciamento dos processos, da planta
e da empresa (SANTOS, 2013).

2.4 Engenharia de software aplica à automação

Moraes e Castrucci (2001) entendem que a engenharia de software é o conjunto das

técnicas de análise de requisitos, especificação, projeto de estrutura, codificação, teste e
manutenção das aplicações desenvolvidas, frisando que é um dos ramos da engenharia mais
solicitados.

O conjunto de etapas para o desenvolvimento de aplicações pode ser denominado de

Ciclo de Vida, que para Capretz (2003) é uma ideia importante, pois afirma que vários
modelos já foram propostos, a fim de sistematizar as diversas etapas do desenvolvimento.
Muitas metodologias de desenvolvimento de software também têm sido propostas ao longo
das últimas décadas. Essas metodologias fornecem alguma disciplina ao lidar com a
complexidade do software inerente, porque elas geralmente oferecem um conjunto de regras e
diretrizes que ajudam os engenheiros de software entender, organizar, decompor e representar
as aplicações.
 21

Estas metodologias são aplicadas para resolver todos os requisitos propostos por uma
aplicação, inclusive o principal requisito das aplicações de automação, que é a concorrência
de tarefas (MORAES; CASTRUCCI, 2001). A concorrência é vista em várias metodologias e
linguagens de programação. Em Java está presente através de threading3, sincronização, e
programação (BUYYA et al., 2009).

As aplicações para automação diferem-se das aplicações de fins comercias e

científicos. A velocidade nessas aplicações tem importância em si mesma, mas não interfere
com a correção dos resultados, ou seja, a aplicação estará correta em uma máquina lenta ou
em uma máquina rápida.

Nas aplicações de automação, correção e velocidade devem estar juntas. Por

exemplo, uma aplicação lê medidas de um transdutor de temperatura em um tanque de água e
as coloca em um buffer, a velocidade desta leitura não pode ser menor que a entrada no
buffer, sob-risco de perder informações essenciais para a tomada de decisão do controle. O
problema será administrar o fato de que uma tarefa pode estar mudando a variável enquanto
outra tarefa está lendo a mesma variável. Para resolver este problema existe um recurso
denominado de Mútua Exclusão, ou seja, cada acesso (fato) a variável é sinalizado através de
uma determinada flag, assim pode-se verificar se há outra tarefa na mesma área, mas uma
regra de prioridades estipulará a tarefa certa a utilizar a variável (MORAES; CASTRUCCI,
2001).

Após esta breve contextualização da Engenharia de Automação e Controle, explorar-

se-à a metodologia de software conhecida como Orientação a Objetos e como ela está
presente na área de automação industrial.

3
É uma forma de um processo dividir a si mesmo em duas ou mais tarefas que podem ser executadas
concorrentemente.
 22

3 ORIENTAÇÃO A OBJETOS E A NORMA IEC 61131-3

O avanço tecnológico relacionado à informática, principalmente nos últimos trinta

anos, impulsionou transformações no cotidiano de trabalho de diversas áreas. A área de
automação industrial foi uma delas, foco deste estudo, passaram a incorporar recursos até
pouco exclusivos da informática, oportunizando e instigando o ingresso de profissionais de
outros ramos junto ao departamento de engenharia, a fim de atender demandas específicas de
desenvolvimento de produto e/ ou manutenção.

Um dos recursos da informática que tem contribuído para o incremento dos artefatos
de automação industrial é a Orientação a Objetos. Trata-se de um paradigma utilizado na
computação que se tornou essencial em muitas das linguagens de programação amplamente
utilizadas na indústria de software, como C++, Object Pascal, C#, Java, entre outras,
inclusive o Laader Logic. Nessa última, com o Function Block (FB), o padrão descrito na
norma IEC 61131-3 (CHIRON; KOUISS, 2007) que implementa o paradigma de Orientação a
Objeto. Com o objetivo de compreender a contribuição do paradigma OO à norma IEC
61131-3, serão explorados a seguir suas noções centrais.

3.1 Orientação a Objetos

Para melhor entender o paradigma da Orientação a Objetos deve-se entender um

pouco da evolução de alguns conceitos que surgiram. Segundo Capretz (2003), o conceito de
“objeto” fundamental em sistemas apoiados no paradigma OO não surgiu associado ao
mesmo, o termo “objeto” apareceu sendo empregado em vários outros ramos da ciência da
computação. O paradigma incorporou o “objeto” através da evolução das outras práticas
existentes, práticas que decorrem de áreas como a simulação de sistemas, sistemas
operacionais, abstração de dados e inteligência artificial, conforme apresenta a Figura 3.1.
 23

Figura 3.1 – Áreas influenciadoras do paradigma de Orientação a Objetos

Fonte: adaptado de Capretz (2003)

A simulação foi um dos campos de pesquisa pioneiros no uso do conceito de

“objeto”. O Simula, linguagem de programação para aplicações de simulação de sistemas do
mundo real, idealizada em 1967, usou as “Classes de objetos”. Nessa linguagem, a execução
de um programa de computador é organizada em uma execução combinada de uma coleção
de objetos. Os objetos que compartilham comportamentos e constituem uma classe.

Meyer (2000), além do que expôs Capretz (2003), afirma que o Simula já
implementava o paradigma de Orientação a Objetos de forma completa, antes do surgimento
da programação estruturada, ou de Parnas4 ter publicado seus artigos sobre ocultamento de
informações, ou ainda, do uso da terminologia "tipo de dados abstratos". Isto aconteceu longe
dos EUA, tradicional polo de desenvolvimento de linguagens de programação. Foi no
Norwegian Computing Center, que alguns desenvolvedores de software já estavam se
beneficiando do poder das classes, herança, polimorfismo, ligação dinâmica e a maioria das
outras vantagens da Orientação a Objetos.

Os estudos de Buyya et al. (2009) compartilham da percepção de Meyer (2000)

acerca da origem da noção de objeto. Exemplo disso, é que os processos concorrentes são
geridos por classe de agendamentos. O Simula permitia classes com atributos5 e métodos6
públicos por padrão, mas também é possível declará-los como privado, ou seja, para um uso
interno da própria classe. Herança e funções virtuais são suportadas e a memória é gerenciada
automaticamente com a coleta de lixo (garbage collection).

4
David Lorge Parnas é um dos pioneiros da engenharia de software, desenvolveu o conceito de ocultamento de
informações na programação modular que é um elemento da programação orientada a objeto de hoje.
5
São os elementos que definem a estrutura de uma classe e também são conhecidos como variáveis de classe.
6
São sub-rotinas executadas por um objeto ao receber uma mensagem, determinam o comportamento dos
objetos de uma classe e são análogos às funções ou procedimentos da programação estruturada.
 24

Em contrapartida, Bolshakova (2005) mostra que cada linguagem foi inicialmente

desenvolvida dentro de um paradigma em particular e que apenas diante de sua evolução,
acumula elementos de técnicas de programação de outros estilos e linguagens, relação que
pode ser vista na Figura 3.2. Para essa autora, cuja perspectiva se desenvolve a partir
Goldberg (1982), o Smalltalk foi o primeiro projeto a utilizar a paradigma de Orientação a
Objetos, porém, sua baixa popularidade se deve a complexidade da sintaxe e semântica
dinâmica. Nele estão presentes ideias de objetos básicos, como a abstração do estado do
objeto e comportamento, encapsulamento, herança de estado, comportamento e o
polimorfismo de operações, que são amplamente integradas com os princípios de linguagens
de programação dos outros estilos. Sob esse viés, defende-se que o paradigma de Orientação a
Objetos generalizou-se logo que foi combinado com o tradicional paradigma imperativo,
principalmente quando foi incorporado as populares linguagens C e Pascal, originando,
assim, as linguagens imperativas orientadas a objeto, C++ e Object Pascal.

Figura 3.2 – Fusão de técnicas e paradigmas de linguagens de programação

Fonte: Bolshakova (2005)

Diante desta contextualização acerca de possíveis vertentes originárias, acredita-se

que é possível visualizar alguns dos pilares da Orientação a Objetos, como a abstração, as
classes, a herança, o polimorfismo, a ligação dinâmica, o encapsulamento, a concorrência, o
coletor de lixo, a persistência de objetos e a generalização. A fim de compreender
 25

adequadamente cada um dos elementos base da OO, para sua identificação e associação
posterior a outras linguagens de programação, apresentam-se suas noções centrais.

3.1.1 Abstração

Capretz (2003) aponta que a abstração é uma técnica que ajuda a lidar com a
complexidade. Abstração envolve uma seletiva análise de determinados aspectos de uma
aplicação, cujo objetivo é isolar os aspectos que são importantes para uma compreensão da
aplicação. Além de suprimir os aspectos irrelevantes, as classes e os objetos são a forma das
abstrações de uma aplicação. Devido a essas características, pode ser considerado um dos
princípios mais relevantes do paradigma de OO.

Corrobora com esse posicionamento Buyya et al. (2009), ao apontar que as

características essenciais de uma entidade7 são conhecidas como abstração. Assim, um
recurso pode ser um atributo refletido em uma propriedade que representa um estado ou um
dado, ou uma operação que reflete um método que representa um comportamento ou uma
função. Pode-se exemplificar essa afirmação a partir do entendimento do uso de um veículo
terrestre. Como se sabe, todo o veículo tem rodas, que podem variar de acordo com seu tipo.
Motos têm duas, triciclos tem três e veículos de passeio têm quatro rodas. Ao abstrair esse
aspecto de maneira generalizada, pode-se dizer que a entidade veículo terrestre tem o atributo
rodas, e seu objeto irá armazenar em sua propriedade a quantidade de rodas que ele tem
naquele momento, pois o objeto pode ser uma moto ou automóvel de passeio.

As Figuras 3.3 e 3.4 exemplificam a situação exposta, onde se vê a entidade veículo

abstraída (Figura 3.3), que apresenta atributos, ou seja, propriedades que armazenarão os
dados no objeto, e, métodos, ou seja, funções e comportamentos que irão ser executado no
objeto, abstraídos, e o próprio objeto instanciado (Figura 3.4).

7
Entidade, de acordo com o dicionário de Ferreira (1988), significa aquilo que existe ou imaginamos que existe;
ente, ser.
 26

Figura 3.3 – Entidade abstrata de um veículo

Atributos/Propriedades Métodos/Comportamento e Função

Marca Ligar()
Modelo Desligar()
Placa Direção()
Cor VelocidadeAtual()
Rodas

Fonte: Elaborado pelo autor (2014)

Figura 3.4 – Objeto instanciado da entidade abstrata veículo

Propriedades Métodos/Comportamento e Função

VW Ligar() Verdadeiro
Gol Desligar() Falso
ABC 1234 Direção() Para frente
Azul VelocidadeAtual() 40Km/h
4

Fonte: Elaborado pelo autor (2014)

Em síntese, a abstração é típica do processo de melhoria contínua na construção de

software orientado a objetos bem-sucedido (MEYER; 2000). A abstração também é um
recurso essencial para que a coleção de classes suporte a herança, tema do próximo
subcapítulo. Também exerce um papel fundamental no encapsulamento, pois através da
abstração que serão definidos os atributos e métodos privados e públicos de uma classe.

3.1.2 Classes

Segundo Meyer (2000), cada classe deve corresponder a uma abstração de dados
bem definida. Buyya et al. (2009) apresentam, de outra maneira, a mesma definição,
apontando que a estrutura de software que suporta a abstração de dados é conhecida como
classe. Uma classe é um tipo de dados que captura a essência de uma abstração. A classe é um
protótipo ou modelo que define características diferentes. Um recurso pode ser um dado ou
uma operação. Os dados são representados por variáveis de instância ou variáveis de dados de
uma classe. As operações também são conhecidas como comportamentos, métodos ou
funções. A Figura 3.5 sintetiza isso.
 27

Figura 3.5 – Mapeamento de entidade real no paradigma de Orientação a Objetos

Fonte: Adaptado de Buyya et al. (2009)

A Figura 3.5 mostra a entidade do mundo real, sendo abstraída, ou seja, coletando as
principais características e comportamentos da entidade, sendo a origem então para a classe,
que será a representação daquela entidade do mundo real na aplicação.

3.1.3 Herança

A herança oferece, segundo Meyer (2000), um suporte para reutilização ou extensão

de classes, o que exige aproveitamento das fortes relações conceituais que possuem entre
entidades (classes), já que uma classe pode ser uma extensão, especialização ou a combinação
dos outros. Nesta linha, Capretz (2003) aponta que a herança é um mecanismo da Orientação
a Objetos que aumenta a reutilização de software.

Na prática, a herança envolve a criação de novas classes, também chamadas de

classes derivadas, ou seja, a partir de classes existentes (classes base ou primitiva). A criação
de novas classes permite a existência de uma hierarquia de classes que simula o conceito de
classe e subclasse do mundo real. A classe derivada herda os membros da classe base e
também adiciona seus próprios membros. Por exemplo, um sistema bancário deve ter clientes,
dos quais são mantidas informações como nome, endereço, telefone, etc. Uma subclasse de
clientes, neste caso, são os estudantes universitários, dos quais se mantêm, além dos nomes,
endereços e telefones, também o numero de matrícula e a instituição de ensino em que estão
matriculados.

A utilidade da herança está associada principalmente a duas estratégias de

programação: extensão e especialização. A extensão usa a herança para desenvolver novas
 28

classes, a partir das já existentes, adicionando novas funcionalidades. Já a especialização faz

uso de herança para refinar o comportamento de uma classe geral (BUYYA et al., 2009).

3.1.4 Polimorfismo

O polimorfismo permite que um objeto possa ser processado de diferentes maneiras,

por tipos de dados e/ou classes de dados, ou seja, trata-se da capacidade de resposta de
diferentes objetos a uma mesma mensagem, permitindo-se então, que um único nome ou
operador possa a ser associado a diferentes operações. Dependendo do tipo de dados
disponíveis, há a possibilidade de redefinir um método dentro de uma classe derivada
(BUYYA et al., 2009).

Tendo por base o exemplo anterior, acerca dos dados de estudantes da subclasse de
clientes em um sistema bancário, um programador poderia definir um método chamado
consultaCliente(). Porém, como este método já existe na classe base (clientes) e a informação
requerida é o CPF, então o programador sobrecarrega o método consultaCliente() e passa a
requisitar a instituição de ensino e numero de matrícula do estudante. No objeto da subclasse
pode-se efetuar a consulta por meio do CPF, ou instituição de ensino e número de matrícula.

A situação exemplificada remete ao estudo de Cardelli & Wegner (1985), cuja

definição, acerca das funções (métodos) que apresentam polimorfismo de parâmetros como
aquela que se pode trabalhar a partir de argumentos de vários tipos, geralmente fazendo o
mesmo tipo de trabalho, independentemente do tipo de argumento, assim, chamadas de
funções genéricas.

3.1.5 Ligação dinâmica

A ligação dinâmica exerce grande influência sobre a estrutura de aplicações

orientadas a objeto, uma vez que permite que os desenvolvedores escrevam chamadas simples
para designar o que se constitui em várias ligações possíveis. Dependendo da correspondente
situação em tempo de execução, por exemplo, a chamada do recurso consultaCliente() na
classe clientes. Isso evita a de repetição de testes (“Se é cliente universitário?”, “Se é cliente
pessoa física?” “Se é cliente pessoas jurídica?”) que flagelam software escrito com
abordagens mais convencionais (MEYER; 2000). Pascoe (1986) concorda que a ligação
dinâmica é necessária para o pleno uso do código no empilhamento de outros tipos de dados.
Ao se considerar a adição de um método de impressão para o módulo que imprime o conteúdo
de uma pilha, o conteúdo pode ser números inteiros, números de ponto flutuante e cadeias de
 29

caracteres, o que em uma abordagem tradicional incluiria uma declaração para verificar em
tempo de execução do método de impressão correto para o tipo que será impresso na pilha. Na
Orientação a Objetos, o “tipo” terá seu próprio imprimir.

3.1.6 Encapsulamento

Pode-se afirmar que encapsulamento tem o objetivo de esconder, dentro de uma

cápsula, a inteligência do software desenvolvido, tal qual uma capsula de remédio. Buyya et
al. (2009), usa esta analogia ao afirmar que sob o ponto de vista do usuário, um número de
características são acondicionadas em uma cápsula, a fim de formar uma entidade. Esta
entidade oferece serviços por meio de interfaces, cujo objetivo é esconder os detalhes de
implementação.

O termo encapsulamento é usado para descrever a ocultação dos detalhes de

desenvolvimento. Tem como principais vantagens a ocultação da informação e a
independência de implementação. O estudo de Meyer (2000), ao apresentar a linguagem de
programação Ada, considerada representante das linguagens de encapsulamento, dá ênfase à
ocultação de informações através de interface e implementações declaradas separadamente.

Assim, pode-se definir que o objeto (cápsula) é um encapsulamento de dados

protegidos, juntamente com as demais operações legais que atuam sobre essa informação
oculta (CAPRETZ, 2003). Dessa forma, é o processo, ou mecanismo, pelo qual pode-se
combinar o código e os dados manipulados em uma única entidade, que fornece uma camada
de segurança em torno dos dados manipulados, protegendo-os de interferências externas e uso
indevido (BUYYA et al., 2009).

3.1.7 Concorrência

Muitas linguagens orientadas a objeto implementam o recurso de concorrência. Para

Capretz (2003), a principal ideia das linguagens que suportam a concorrência é fornecer aos
programadores meios programáveis que permitam que objetos sejam executados
simultaneamente. Buyya et al. (2009) afirma que são meios programáveis de concorrência, o
uso de threading, a sincronização e o escalonamento. O uso de concorrência também permite
complexidade adicional para o desenvolvimento de aplicações, permitindo a elas mais
flexibilidade.
 30

3.1.8 Coletor de lixo

O coletor de lixo, ou garbage collector, é uma facilidade incluída no sistema em

tempo de execução8 para a linguagem de programação. Coletores de lixo clássicos são
ativados sob demanda e sempre rodam para a conclusão de uma tarefa. Em outras palavras, o
coletor de lixo está inativo desde que haja memória para o aplicativo, quando o aplicativo é
executado com falta de memória, é disparado o ciclo de coleta de lixo, onde recursos em
desuso são eliminados da memória (MEYER; 2000).

3.1.9 Persistência de objetos

A persistência é o conceito de que um objeto (um conjunto de dados) sobrevive após

a execução do programa, ou seja, entre fechar e abrir o programa novamente. Todos os
sistemas de banco de dados possuem suporte a persistência, mas sua persistência nem sempre
são compatíveis com as linguagens de programação. No entanto, a persistência pode ser
simulada através do uso de fluxos de arquivos que são armazenados no sistema de arquivos do
sistema operacional (BUYYA et al., 2009).

3.1.10 Generalização

Meyer (2000) afirma que a generalização é o processo de transformar elementos

especializados do programa em componentes de software reutilizáveis em diversas frentes.
Buyya et al. (2009) aprofunda tal consideração ao afirmar que a generalização identifica as
propriedades e os comportamentos comuns em abstrações. A diferença é que a abstração visa
simplificar a descrição de uma entidade, enquanto generalização identifica semelhanças entre
um conjunto de abstrações. Generalizações são importantes, pois são como "leis" ou
"teoremas", que estabelecem a base para muitas coisas. A generalização ajuda a desenvolver
software capturando a ideia de semelhança.

Diante desta breve contextualização acerca dos elementos principais ao entendimento

do paradigma de Orientação a Objetos, pode-se seguir a reflexão sobre seu uso em
concordância com a norma IEC 61131-3. Com essa norma a IEC passa a padronizar as
linguagens de programação e adota o paradigma de OO, além do paradigma tradicional.

8
Sistema em tempo de execução: é um componente da linguagem de programação, que complementa o
compilador, fornecendo os mecanismos necessários no momento da execução para apoiar a execução de sistemas
escritos na linguagem (MEYER; 2000).
 31

3.2 Norma IEC 61131-3

A Parte 3 da IEC 61131 é um dos esforços da IEC para padronizar o mercado de

automação. A seguir será apresentado um pouco da história até a chegada da norma.

3.2.1 Origem

Durante as últimas décadas, os controladores lógicos programáveis (PLCs) têm sido

a plataforma de implementação para algoritmos de controle em aplicações industriais. Após a
sua introdução em 1969, várias empresas desenvolveram PLCs com diferentes ambientes de
tempo de execução, sistemas operacionais e linguagens de programação (OTTO;
HELLMANN, 2009). Suas aplicações de controle foram desenvolvidas em BASIC, C, na
Lista de Instruções e em outras linguagens, normalmente proprietárias, incluindo vários
dialetos da programação Ladder Logic. A falta de padronização resulta no uso ineficiente do
tempo e do dinheiro, pois as pessoas envolvidas com tais sistemas dos técnicos, o pessoal da
manutenção, os projetistas de sistemas aos gerentes de planta, necessitam adaptar-se aos
padrões de cada fornecedor (GUIMARÃES, 2005).

Para alterar esse cenário, a IEC endossou o movimento de padronização das

linguagens com a norma IEC 61131, a qual estabeleceu padrões para Controladores
Programáveis. Esta norma só se aplica a controladores programáveis e seus periféricos, tais
como as ferramentas de programação e depuração, os equipamentos de testes e as interfaces
homem-máquina, mas não se aplica a todos os componentes de um sistema de automação
(ALVES, 2008).

A norma IEC 61131 é dividia em oito partes, conforme apresenta a Tabela 3.1:

Tabela 3.1 – Partes da norma IEC 61131

Parte Título Conteúdo
01 General Information Definições da terminologia e
conceitos

02 Equipment requirements and tests Teste

03 Programming languages Linguagens de programação

com definição de suas
estruturas e execução
04 User Guidelines Orientação para seleção,
instalação e manutenção de
PLCs
 32

05 Communications Definição de blocos de

comunicação entre
equipamentos
06 Functional safety Padrões para PLCs e seus
periféricos, como o subsistema
lógico do sistema de segurança
07 Fuzzy control programming Padrões para tratamento de
lógica Fuzzy em PLCs

08 Guidelines for the application and implementation Orientação para

of programming languages implementação das linguagens
IEC61131-3
Fonte: Adaptado de Filho (2005).

A conjunção das oito partes da norma busca promover a redução de custos com
implantação das aplicações de controle e automação devido às diferentes tecnologias. Pode-se
mencionar alguns aspectos que representam a redução de custos a partir dos ajustes da norma:
treinamentos, depuração, manutenção de software, engenharia e consultoria, permitir foco na
solução do problema e não na construção da aplicação, redução na dependência de
fornecedores de consultorias e hardwares, redução de erros e inconsistências na construção de
lógicas e soluções iguais para áreas iguais em indústrias iguais ou diferentes; uso e mudanças
de parametrizações e não do software todo, e o usos de bibliotecas padrões construídas por
diferentes programadores (ALVES, 2008).

Além da norma IEC 61131, foi constituída a associação PLCopen, foco de estudo do
próximo subcapitulo.

3.2.2 PLCopen

Fundada em 1992, a PLCopen tem como o objetivo de apoiar a programação do PLC

de acordo com a norma (OTTO; HELLMANN, 2009).

A PLCopen (2014) busca atingir este objetivo através das seguintes ações:

 aplicar o padrão IEC 61131-3;

 obrigar membros a fornecer ou usar PLCs que operam em conformidade com a

norma IEC 61131-3;

 promover a norma no mercado de PLCs;

 desenvolver conceitos de implementação comuns;

 33

 definir os critérios de conformidade e a designação de instituições para a

realização de testes de conformidade;

 influenciar a normalização no campo de PLCs dentro das organizações

internacionais de normalização.

Para dar credibilidade, os produtos aprovados pela PLCopen (2014) recebem um selo
de acordo com o nível da certificação obtida. Atualmente são três as principais certificações
destinadas aos fornecedores de ambientes de programação de PLCs:

Tabela 3.2 – Certificação dos ambientes IEC 61131-3

Certificação Abrangência Selo
Nível Base Produto compatível. Indica que o
fornecedor é um membro sério da
comunidade IEC 61131 e está
comprometida a usar a sintaxe padrão.

Nível Define a conformidade quanto a

Conformidade quantidade de tipos de dados declarados de
acordo com a norma IEC 61131-3.

Nível Define o quanto o produto é reutilizável de

Reutilização acordo com norma IEC 61131-3. Os
usuários são capazes de trocar as
definições de bloco de função e função
com outros produtos compatíveis com RL.

Fonte: elaborado pelo autor (2014).

Estas certificações trazem para o usuário uma garantia de que os produtos adquiridos
estão de acordo com a norma. Além disso, conforme Alves (2008), a PLCopen possui
internamente diversos grupos de trabalhos ou Comitês Técnicos (TCs), que trabalhem
continuamente, cada um deles responsável pela gestão de processos relacionados à norma, são
eles:

 TC1 – Normas: trabalha na melhoria da IEC 61131 como um todo, recebendo

sugestões e modificações de colaboradores;
 34

 TC2 – Funções: padroniza o uso de funções e blocos de funções já definidos e

depurados por outros programadores e fornecedores de softwares;

 TC3 – Certificação: licencia laboratórios e certifica instalações que

desenvolvem sistemas de automação projetados e instalados de acordo com a
norma IEC 61131;

 TC4 – Comunicações: trabalha na relação entre a comunicação e as linguagens

de programação, via IEC 61131-5 sobre a IEC 61131-3;

 TC5 – Software Seguro: faz recomendações quanto ao uso da norma IEC

61131 em sistemas de segurança, em especial a utilização em conformidade
com as normas de segurança IEC 61508 e IEC 61511;

 TC6 – XML: trabalha na especificação e divulgação da padronização da norma

IEC 61131 para uso com a linguagem XML (eXtensible Markup Language).

Após esta abordagem geral sobre a norma IEC 61131-3, o próximo subcapitulo
abordará e ampliará as noções referentes a terceira parte da norma IEC 61131, ou seja, suas
características.

3.2.3 Introdução à IEC 61131-3

Ao seguir a norma, Guimarães (2005) e Alves (2008) apontam que o ambiente de

programação do PLC deve ser capaz da decomposição de programas complexos em n
elementos, os quais devem possuir interfaces padrões para comunicar entre eles. A norma
define também as cinco linguagens de programação para o desenvolvimento de aplicações ou
seus elementos.

Para atingir este objetivo, a programação é orientada para o desenvolvimento de

programas a partir das abordagens top-down e bottom-up9, que baseiam-se em três princípios:

 modularização: decomposição de qualquer sistema, complexo ou não, em

partes menores capazes de serem gerenciáveis;

 estruturação: forma hierárquica utilizada para a programação em níveis

facilitando a modularização e reutilização de blocos;

9
Top-down e bottom-up são estratégias de processamento de informações e ordenação do conhecimento, usados
em uma variedade de campos, incluindo software, teorias humanísticas e científicas, gestão e organização.
Podem ser vistos como um modelo de pensamento e de ensino.
 35

 reutilização: de blocos funcionais ou programas.

Percebe-se que a norma IEC 61131-3 tem duas vias em sua construção: elementos
comuns e linguagens de programação. As ferramentas de estruturação dentro da norma IEC
61131-3 estão focadas em elementos comuns, embora fique evidente que conectam-se às
linguagens de programação (VAN DER WAL, 1999). A Figura 3.6 ilustra a divisão da norma.

Figura 3.6 – Divisão da IEC 61131-3

Fonte: van der Wal (1999)

Os elementos comuns são compostos por: tipagem de dados, variáveis, blocos

funcionais, funções e sequenciamento gráfico de funções e o modelo de software, que é
composto por: configuração, recursos e tarefas, programas. Já as linguagens de programação
compõem-se: SFC, ST, IL, LD e FBD. Diante disso, será visto cada um dos elementos
comuns e as linguagens de programação.

3.2.4 Tipagem de dados

A padronização de tipo de dados impede erros em um estágio inicial, por exemplo,

dividir uma data por um inteiro. Os tipos de dados são utilizados para definir o tipo de
qualquer variável utilizada. Os tipos de dados comuns são: Boolean, Integer, Real, Byte, Word
e também Date, Time-of-Day e String. Com base nestes tipos de dados comuns, pode-se
definir tipos de dados próprios, conhecidos como tipos de dados derivados, que podem ser
reutilizados inúmeras vezes (VAN DER WAL, 1999).

3.2.5 Variáveis

As variáveis são associadas somente para endereços explícitos de hardware (entradas

e saídas) nas configurações, recursos e programas. Cria-se assim um alto nível de
independência do hardware, permitindo a reutilização do software. O escopo das variáveis
pode ser local ou global.
 36

Variáveis locais são limitadas à Unidade de Organização de Programa, conhecidas

pela sigla em inglês POU, nas quais elas são declaradas. Neste escopo, os seus nomes podem
ser reutilizados em outras partes sem nenhum conflito, eliminando outra fonte de erros muito
comum, os dados corrompidos pela aplicação.

Variáveis globais devem ser declaradas como tal (VAR_GLOBAL). Para cada
parâmetro pode ser atribuído um valor inicial na partida a quente e a frio da aplicação, de
forma a se garantir os valores corretos (VAN DER WAL, 1999).

Guimarães (2005) afirma que as posições de memória do PLC podem ser acessadas
usando variáveis de representação direta do endereço de memória, ou seja, é permitida a
leitura e escrita de dados em posições conhecidas de memória, tais como entradas, saídas e
endereços internos. A notação utilizada é padronizada para permitir a portabilidade, onde
todas começam com o caractere “%”, seguido de uma ou duas letras, onde a memória do PLC
pode ser dividida em três regiões lógicas, conforme pode-se observar nas Tabelas 3.3 e 3.4.

Tabela 3.3 Primeira letra escrita para representar a variável de representação direta

Primeira Letra Interpretação

I Input: Recebe os valores das variáveis analógicas e discretas dos módulos

de entrada.

Q Output: Para armazenar os valores a serem escritos nos dispositivos

externos.

M Memória Interna: Armazena valores intermediários.

Fonte: Guimarães (2005).

Tabela 3.4 Segunda letra escrita para representar a variável de representação direta

Segunda Letra Interpretação

X Bit

B Byte (8 bits)

W Word (16 bits)

 37

D Double word (32 bits)

L Long word (64 bits)

Fonte: Guimarães (2005).

A partir das Tabelas 3.3 e 3.4 pode-se exemplificar algumas variáveis de

representação direta do endereço de memória, como:

 %IX10 (*Memória de endereço 10 e entrada bit*);

 %IW12 (*Memória de endereço 12 e entrada palavra de 16 bits*);

 %MW232 (*Palavra de endereço de memória 232*);

 %QL28 (*Memória de endereço 25 e entrada palavra longa de 32 bits*).

3.2.6 Blocos Funcionais (FB)

Os blocos são os blocos básicos de construção, contendo uma estrutura de dados e

um algoritmo. Equivalem aos circuitos integrados, representando uma função de controle
especializada (VAN DER WAL, 1999).

Alves (2008) define blocos funcionais como partes de programas hierarquizados e

estruturados de forma a serem parametrizáveis e reutilizáveis. Os dados possuem persistência,
ou seja, mantêm-se inalterados entre cada execução. Devido a isso, IEC 61131-3 considera os
blocos de função como do paradigma de Orientação a Objetos (JOHN; TIEGELKAMP,
2010). São exemplos de blocos funcionais: PID, temporizadores, contadores e blocos criados
com funções específicas como controle de motores.

3.2.7 Funções

As funções são também conhecidas por procedimentos ou métodos são elementos de

programação que não possuem persistência, gerando resultados a cada execução (ALVES,
2008). A IEC 61131-3 definiu algumas funções padrões como, por exemplo: ADD(), ABS (),
SQRT, SIN() e COS(). Já as funções definidas pelo usuário, uma vez definidas, podem ser
usadas inúmeras vezes (VAN DER WAL, 1999).

3.2.8 Configuração
 38

A configuração representa o nível mais alto da formulação de uma aplicação para

resolver um problema particular de controle. É específica para cada aplicação de controle,
incluindo a disposição do hardware, recursos de processamento, endereçamento de memória
para I/O e demais capacidades do sistema (VAN DER WAL, 1999).

Alves (2008) corrobora ao afirmar que a configuração corresponde ao software

necessário a um PLC ou conjunto de PLCs para que cumpram suas funções de controle. A
configuração define todos os elementos interagentes com suas configurações individuais e
uma configuração total dada pelo resultado das diversas configurações.

3.2.9 Caminhos de acesso

Conforme Guimarães (2005), os caminhos de acesso permitem a transferência de

dados entre diferentes configurações, onde cada configuração pode definir um número de
variáveis (leitura, escritas ou ambos) para acesso por configurações remotas. Na Figura 3.7
pode-se visualizar esta configuração.

Figura 3.7 – Comunicação remota usando caminho de acesso

Fonte: Guimarães (2005)

A norma IEC 61131-3 afirma que os mecanismos de comunicação estarão

disponíveis para a troca de informação, porém, não aborda a forma a ser adotada. Em
contrapartida, a parte cinco da norma IEC 61131 define que os blocos funcionais proverão os
serviços para leitura e escrita de variáveis em configurações remotas.
 39

3.2.10 Recursos

Os Recursos são elementos com capacidade de processamento dentro de uma

“Configuração”, sendo capaz de executar programas IEC. Pode existir fisicamente (CPU do
processador, interfaces de operação IHM, gateways de comunicação) ou virtualmente (uso
compartilhado de memórias de processamento por softwares distintos). Em uma configuração
pode-se ter n Recursos (ALVES, 2008).

3.2.11 Tarefas

As tarefas são definidas dentro de um “Recurso” e controlam a execução de um

conjunto de programas ou blocos funcionais. São conFiguradas para serem executadas
periodicamente ou quando da ocorrência de um evento específico, como por exemplo, a
mudança de uma variável. Salienta-se que um recurso pode abarcar um número amplo de
tarefas. (VAN DER WAL, 1999).

3.2.12 Programas

Assim como os Blocos Funcionais (FB) e as Funções, os programas são chamados de

Unidades de Organização de Programas (POUs) de acordo com a IEC 61131-3. Porém, pode-
se afirmar, que os programas são constituídos a partir de blocos funcionais e funções, estes
escritos em qualquer das linguagens definidas pela IEC. Consiste de uma rede de funções e
FBs, os quais são capazes de trocar dados (VAN DER WAL, 1999). Além de acessar
diretamente as Entradas e Saídas e comunicar com outros programas (ALVES, 2008).

3.2.13 Modelo de software IEC 61131-3

Configuração, recursos, tarefas e programas representam o modelo de software

definido pela norma IEC 61131-3, conforme pode ser visto na Figura 3.8.
 40

Figura 3.8 – Modelo de software da IEC 61131-3

Fonte: Alves (2008)

O modelo de software representado na Figura 3.8 apresenta além dos quatro itens
Configuração, Recursos, Tarefas e Programas, os itens que os compõem, como Funções,
Blocos Funcionais (FB) e Caminhos de Acesso, sendo que todos estes elementos estão dentro
de um fluxo de controle.

3.2.14 Fluxo de controle

A norma IEC 61131 não define os mecanismos para controle de execução dos
elementos da aplicação, os quais dependem da implementação. Entretanto, são definidos os
comportamentos na partida (start-up) e parada (shut-dowmn) da aplicação:

 Partida:

o quando uma configuração parte, todas as variáveis globais são

inicializadas e todos os recursos são ativados;

o quando um recurso parte, todas as variáveis dentro do recurso são

inicializadas e todas as tarefas são habilitadas;

o uma vez habilitadas as tarefas, todos os programas e blocos funcionais

associados serão executados, quando a tarefa estiver ativa.
 41

 Parada:

o quando uma configuração para, todos os recursos da mesma também

param;

o quando um recurso para, todas as tarefas são desabilitadas,

interrompendo a execução dos programas e blocos funcionais.

Após a conceituação dos elementos comuns da norma IEC 61131-3, o próximo item
deste estudo refere-se as linguagens de programação.

3.2.15 Linguagens de programação

A norma IEC 61131-3 possui cinco linguagens de programação padrões. Isto

significa que suas sintaxes e semânticas foram definidas, eliminando a chance de dialetos
(VAN DER WAL, 1999). Destas cinco linguagens, três são gráficas e duas são textuais. A
síntese das linguagens incorporadas à norma pode ser vista na Figura 3.9.

Figura 3.9 – Linguagens de programação da norma IEC 61131-3

Fonte: Adaptado de Filho (2005)

A Figura 3.9 mostra a linguagem SFC no topo, pois hierarquicamente é a mais

importante. Diante disso, as linguagens ST, IL, FBD e LD podem ser usadas dentro de blocos
de ação e em transições da programação SFC (GUIMARÃES, 2005).

Como visto anteriormente, a norma IEC 61131-3 define os elementos comuns às

cinco linguagens de programação com o intuito de padronizar seu entendimento. Exemplo
desses elementos comuns são as variáveis e tipos de dados, que permitem a utilização de
qualquer linguagem de programação. Para melhor entender as linguagens de programação,
abordar-se-á cada uma, a começar pela linguagem de texto estruturado.
 42

3.2.16 Texto Estruturado (ST)

A linguagem de texto estruturado é uma linguagem de alto nível, muito próxima de

outras linguagens, como C e Pascal, esta última com muita similaridade de sintaxe. Contém
todos os elementos essenciais de uma linguagem moderna, incluindo condicionais (IF-THEN-
ELSE e CASE OF) e iterações (FOR, WHILE e REPEAT). Permite a programação de
funções e blocos funcionais que teriam difícil solução com outras linguagens. É indicada para
situações de tomada de decisões e cálculos (VAN DER WAL, 1999) (ALVES, 2008).

A Figura 3.10 apresenta um bloco funcional desenvolvido em linguagem de

programação ST.

Figura 3.10 – Bloco funcional em linguagem texto estruturado

Fonte: Brune e Lima (2013)

3.2.17 Lista de Instruções (IL)

A lista de ilustrações é a contraparte europeia à linguagem Ladder Logic, criada nos

EUA. Como uma linguagem textual, se assemelha ao assembler (VAN DER WAL, 1999).
Utiliza-se principalmente em pequenas aplicações ou otimizações de códigos ao nível de bits
e variáveis e é eficiente e rápida ao nível de bits por se aproximar do código da CPU. Porém,
é uma linguagem pouco estruturada e de difícil compreensão se usada em grande escala.
 43

Trata-se de uma linguagem comumente utilizada por pequenos fabricantes de PLCs devido à
simplicidade em pequenas aplicações, além de ser desnecessário o uso de compiladores como
as demais (ALVES, 2008). O exemplo na Figura 3.11 mostra como é um código desenvolvido
em linguagem de programação IL

Figura 3.11 – Exemplo em linguagem de lista de instruções

Fonte: Elaborado pelo autor (2014)

3.2.18 Logic Ladder (LD)

A linguagem Logic Ladder baseia-se na representação gráfica da Lógica de Relés.

Com origem nos EUA, a representação se dá através de contatos e bobinas interconectados,
que destacam a energização entre os elementos (VAN DER WAL, 1999) (GUIMARÃES,
2005).

Essa linguagem é utilizada em controle/comando discreto de equipamentos e sinais.

Adequada para uso de lógicas sequenciais e combinacionais (Boole) – And-Or-XOr, com
visualização na forma de contatos de relés: -| |- -|/|- -(G)-| (ALVES, 2008). Apresenta-se, na
Figura 3.12, um exemplo da linguagem de programação LD.
 44

Figura 3.12 – Exemplo em linguagem Logic Ladder

Fonte: Elaborado pelo autor (2014)

3.2.19 Diagrama de Blocos Funcionais (FBD)

O diagrama de blocos funcionais é uma linguagem muito utilizada na indústria de

processos, pois expressa o comportamento de funções, blocos funcionais e programas como
um conjunto de blocos gráficos interligados, como nos diagramas de circuitos eletrônicos.
Parece com um sistema em termos do fluxo de sinais entre elementos de processamento
(VAN DER WAL, 1999).

Cada função também tem uma saída digital extra, denominada Enable Output
(ENO), que é definida como verdadeira (TRUE), quando a execução da função é efetuada
com sucesso. Assim, é comum encadear a saída ENO de uma função com a entrada Enable
Input (EN) da outra para garantir que a cadeia só produzirá um resultado correto, quando
todas as etapas estiverem corretas (GUIMARÃES, 2005). A Figura 3.13 mostra um exemplo
de uso da linguagem de programação FDB.
 45

Figura 3.13 – Exemplo em linguagem de Diagrama de Blocos Funcionais

Fonte: Elaborado pelo autor (2014)

3.2.20 Sequenciamento Gráfico de Funções (SFC)

O sequenciamento gráfico de funções pode ser utilizado como linguagem e também

como um elemento comum, que deriva das redes de Petri e da norma IEC 848 Grafcet, com
alterações necessárias para converter a representação de uma documentação padrão em um
conjunto de elementos de controle de execução. Descreve graficamente o comportamento
sequencial de um programa de controle e é capaz de estruturar sua organização interna, além
de auxiliar na decomposição do problema de controle em partes gerenciáveis, enquanto
mantém a sua visão geral (VAN DER WAL, 1999).

Alves (2008) aponta que o SFC permite a programação em forma textual e estrutura
as ações em partes a serem usadas de forma hierárquica e com abordagem top-down. Também
promove ganhos de desempenho por executar apenas passos ativos na estrutura do programa e
permitir fácil rastreabilidade de eventos.

Conforme Guimarães (2005), a linguagem de sequenciamento gráfico de funções é

adotada pela ISA SP 88 para programação de sistemas de controle de bateladas (Batch
Control Systems). O SFC é capaz de mostrar os múltiplos estados de um sistema, as possíveis
mudanças de estado e as respectivas causas. Repartindo um problema de controle de forma
que todos os aspectos relevantes são considerados e executados.

Uma sequência em SFC é composta por uma série de passos mostrados como
retângulos, conectados por linhas verticais, onde cada passo representa um estado particular
 46

programado em qualquer uma das demais linguagens IEC (ST, FBD, LD e IL). Para melhor
entendimento, propõe-se a Figura 3.14.

Figura 3.14 – Exemplo em linguagem de Sequenciamento Gráfico de Funções

Fonte: Adaptado de Alves (2008)

Cada linha de conexão possui uma barra horizontal que representa uma transição, a
qual é associada a uma condição que, quando verdadeira, causa a desativação do passo
anterior e a ativação do passo seguinte. Uma transição recebe um nome (T1, T2, T3, etc...) e é
programada nas linguagens ST, FBD, LD e IL. Cada um dos passos pode ter uma ou mais
ações associadas que é representada por um ou mais programas. O fluxo é de cima para baixo
(top-down), mas ramos podem ser usados para retornar para passos anteriores (GUIMARÃES,
2005).

3.2.21 Orientação a Objeto na norma IEC 61131-3

O conceito de Orientação a Objetos foi introduzido na programação de Controle e

Automação pela IEC através de um padrão descrito na especificação IEC 61131-3: o bloco
funcional (FB) (CHIRON; KOUISS, 2007). As empresas, desde então, procuram
disponibilizar ambientes que permitam aplicar os conceitos de Orientação a Objetos no
desenvolvimento de aplicações para Controle e Automação.
 47

O MasterTool IEC XE, da empresa brasileira Altus, afirma oferecer a programação

Orientada a Objetos com conhecidas vantagens de modernas linguagens de alto nível, como
JAVA ou C++, como uso de classes, interfaces, métodos, herança e polimorfismo. Os blocos
funcionais escritos em IEC podem ser estendidos e estas extensões estão disponíveis para
todos os aspectos de engenharia. A linguagem de programação Orientada a Objetos oferece
grandes vantagens para o usuário como, por exemplo, quando reutiliza partes existentes de
uma aplicação ou quando se trabalha em uma mesma aplicação com vários desenvolvedores
(ALTUS, 2013c).

Outra ferramenta que disponibiliza esta opção é o CoDeSys, da empresa alemã 3S,
da qual destacam-se os seguintes pontos:

 bloco funcional: é uma classe com exatamente um método;

 métodos: são rotinas que são firmemente atribuídos a um bloco de função ou

uma interface. Eles operam com os dados do bloco de função, mas pode,
assim como funções IEC, ter variáveis de entradas e saídas ou variáveis
locais;

 interface: possui um conjunto de métodos e define as variáveis necessárias dos

métodos. O corpo do método é o programado na classe;

 objetos: são instâncias de blocos funcionais (classes) (3S, 2009).

Kajihara et al. (2004) apontam, que nos últimos anos, o custo de engenharia para
sistemas de controle tende a aumentar rapidamente devido à integração e promoção dos
sistemas de controle sob a demanda de poupar trabalho e espalhar a expansão da TI. Dentro
desta perspectiva, muitos esforços têm sido feitos para popularizar e aumentar a adesão dos
fornecedores e usuários à norma IEC 61131-3, já que apresenta como solução melhorar a
reutilização de software, linguagem de descrição de controle padrão e a Orientação a Objetos
introduzidos no sistema de controle.

Após a conceituação da Orientação a Objetos e da norma IEC 61131-3, o próximo

capítulo se destinará a modelagem, em Orientação a Objetos, de uma aplicação em
programação clássica.
 48

4 APLICANDO A ORIENTAÇÃO A OBJETOS

Neste capítulo serão utilizados alguns dos conceitos de Orientação a Objetos em uma
aplicação já desenvolvida no ambiente tradicional (MasterTool Programming) de
programação Ladder, utilizando o paradigma sequencial lógico.

4.1 Aplicação atual

A aplicação desde estudo é responsável pelo envio de amostras de aço para análise
via motores tipo turbina da Usiminas. Foi desenvolvida na ferramenta MasterTool
Programming, lançada no ano de 2000 (ALTUS, 2013a). Para melhorar a comparação de
paradigmas, a aplicação foi transcrita MasterTool IEC XE 1.40 (ALTUS, 2013b). Este
software contempla a norma IEC 61131-3, mas permite o usuário desenvolver sistemas
utilizando apenas a lógica sequencial.

Na Figura 4.1 mostra-se uma lógica inteira de parte da aplicação disponibilizada de

automação e controle transcrita no paradigma sequencial lógico, sem os conceitos de
Orientação a Objetos como classes e heranças. A partir desta aplicação serão extraídos alguns
trechos de lógica e estes trechos serão remodelados utilizando o paradigma de Orientação a
Objetos.

Figura 4.1 – Lógica atual Usiminas

continua
 49

continuação

Fonte: Adaptado de Usiminas (2013)

Ao observar a Figura 4.1, nota-se que existem várias lógicas semelhantes,

especificamente as lógicas 1, 3, 5 e 7, que apresentam diferenças entre as variáveis, mas a
lógica é igual. O mesmo ocorre com as lógicas 2, 4, 6 e 8. Quando for necessária a
manutenção de uma destas lógicas o usuário terá que realizar um esforço maior.
 50

4.2 Remodelando a Aplicação com Orientação a Objetos

As características mais comuns de técnicas de modelagem OO incluem a interação

de objetos, composição hierárquica de objetos, e a reutilização de objetos (HAN; PARK,
2007). Para alcançar estes objetivos, e assim, diminuir os custos no desenvolvimento e
manutenção das aplicações, serão aplicadas as técnicas de Orientação a Objetos.

4.2.1 Abstração das lógicas

As características essenciais de uma entidade são conhecidas como abstração

(BUYYA et al., 2009). Aplicando o conceito de abstração, pode-se diminuir o número de
alteração das lógicas citadas anteriormente. Para isso, separa-se em entradas, processamento e
saídas, pois são estas as características mais comuns das entidades da automação industrial.

No caso da Figura 4.2, existem duas entidades, uma entidade representada pela
lógica 1 e outra entidade representada pela lógica 2.

Figura 4.2 – Identificação das entradas e saídas da Lógica atual Usiminas

+
Fonte: Adaptado de Usiminas (2013)

Ao destacar em azul as variáveis de entrada e em vermelho as variáveis de saída,

apresentadas na Figura 4.2, conclui-se a etapa de abstração.

Assim, a entidade da lógica 1 é representada por três entradas, são elas: duas
variáveis de representação direta de endereço de memória (%IX0008.4 e %IX0012.3) e uma
constante de tempo (t#15s); o processamento é representado pelo temporizador TON e por
fim a saída é representada na variável %IX0009.2.

Já entidade representada pela lógica 2, tem duas entradas: a variável de representação

direta %IX0009.2 que tem armazenado o resultado obtido pela saída do processo anterior e
variável de tempo (t#1s). Observando-se as lógicas 2, 4, 6 e 8, percebe-se que este tempo é
uma constante de um único valor, o que permite retirar o status de entrada e defini-lo como
 51

uma variável constante. O processamento também é representado por um temporizador e uma

saída em %IX0009. 2.

4.2.2 Construção dos Blocos Funcionais (Classes)

Bloco funcional é uma classe (3S, 2009). Com a abstração das características
essenciais das lógicas 1 e 2, pode-se construir uma classe (FB) para cada lógica. A Figura 4.3
apresenta o bloco funcional L01_Class desenvolvido a partir da abstração da lógica 1.

Figura 4.3 – Classe L01_Class que representa a lógica das linhas 1, 3, 5 e 7

Fonte: Elaborado pelo autor (2014)

Ao observar a lógica 1 da Figura 4.2 e a lógica construída da Figura 4.3 nota-se uma
grande semelhança; o que muda em si é o uso das variáveis. Na Figura 4.2 há o uso de
variáveis de representação direta e na construção da classe, usam-se as variáveis simbólicas,
ou seja, pode-se reutilizar este bloco funcional onde a lógica seja igual, pois as variáveis
simbólicas podem receber o valor de qualquer entrada, desde que o tipo de dado seja o
correto. Assim a Entrada02 do bloco funcional, por exemplo, pode receber o %IX0012.3 da
lógica 1 da Figura 4.2, ou o %IX0012.04 da lógica 5 da Figura 4.1. Portanto, torna-se possível
aplicar o bloco funcional nas lógicas 1, 3, 5 e 7 da Figura 4.1, o resultado será apresentado nas
Figuras 4.4 e 4.5.

A segunda lógica do sistema também pode se tornar um bloco funcional. A Figura

4.4 mostra a classe L02_Class desenvolvida a partir da abstração realizada na lógica 2 da
Figura 4.2, na qual há duas entradas e uma saída. Porém, uma das entradas foi transformada
em uma constante, pois seu valor em todas as lógicas sempre foi o mesmo.
 52

Figura 4.4 – Classe L02_Class que representa a lógica das linhas 2, 4, 6 e 8

Fonte: Elaborado pelo autor (2014)

4.2.3 Utilizando os Blocos Funcionais

Após a construção dos dois blocos funcionais é possível utilizá-los na aplicação

apresentada na Figura 4.1, criando assim uma aplicação mista. Em um primeiro momento,
utilizar-se-á apenas o bloco funcional L01_Class, conforme Figuras 4.5 e 4.6.

Figura 4.5 – Aplicação mista: cabeçalho da aplicação com bloco funcional L01_Class

Fonte: Elaborado pelo autor (2014)

 53

Figura 4.6 – Aplicação mista: lógicas da aplicação da aplicação com o FB L01_Class

Fonte: Elaborado pelo autor (2014)

 54

Na construção desta aplicação mista é possível visualizar que a classe L01_Class é

utilizada quatro vezes na Figura 4.5. As “variáveis” desta classe em tempo de execução da
aplicação são instâncias de objetos do tipo L01_Class, ou seja, L01, L03, L05 e L07 serão
objetos únicos, cada um com seus valores, preservando-se o comportamento anterior da
aplicação.

Conforme Figura 4.6, o objeto L01 recebe as variáveis de entradas identificadas

anteriormente, %IX0008.4, %IX0012.3, e o tempo presentes na Figura 4.2. A saída
%IX0009.2, por sua vez, é também a entrada da lógica seguinte. Isso permite unir as duas
lógicas.

A Figura 4.7 resume a etapa completa do uso de alguns artifícios do paradigma de

Orientação a Objetos, como abstração, classe e objeto.

Figura 4.7 – Etapas do processo de desenvolvimento através do paradigma de OO

Fonte: Elaborado pelo autor (2014)

 55

Para concluir esta etapa, a Figura 4.8 mostra o resultado da aplicação de automação e
controle com o uso dos dois blocos funcionais.

Figura 4.8 – Aplicação: cabeçalho da aplicação com os FBs L01_Class e L02_Class

Fonte: Elaborado pelo autor (2014)

 56

Por fim, pode-se afirmar que aplicação mostrada na Figura 4.8 foi desenvolvida sob
o paradigma de Orientação a Objetos. Apesar das lógicas 5, 6, 7 e 8 não passarem pelo
processo de abstração, cabe ressaltar que há casos em que a Orientação a Objetos não traz
ganhos significativos. Nestes casos, a abordagem tradicional continua sendo uma boa solução.

4.2.4 Herança em Blocos Funcionais

A Herança em Blocos Funcionais permite a extensão e reutilização de código

existente sem ter de repeti-lo, ou reescrevê-lo (BUYYA et al., 2009). A herança oferece um
suporte para reutilização ou extensão de classes, o que exige aproveitamento das fortes
relações conceituais que possuem entre classes (Meyer, 2000). Com base nessas afirmações, o
cenário para aplicar a herança é composto pela análise da lógica da aplicação (Figura 4.1) e
dos blocos funcionais apresentados nas Figuras 4.3 e 4.4.

As lógicas 1, 3, 5 e 7, da Figura 4.1, além de serem reproduzidas no bloco funcional

L01_Class, podem ser vistas como parte das lógicas subsequentes, no caso, 2, 4, 6 e 8. Sendo
assim, este código pode ser visto um código base, fazendo com que se tenha motivação para
estendê-lo para o bloco funcional L02_Class, surgindo assim um novo bloco funcional, o
L02_Class_Com_Heranca, visto na Figura 4.9.

Figura 4.9 – Bloco funcional L02_Class_Com_Heranca com base no FB L01_Class

Fonte: Elaborado pelo autor (2014)

 57

Ao analisar a Figura 4.9 é possível perceber outros benéficos da Orientação a

Objetos. O bloco funcional criado é uma extensão do bloco L01_Class, o que significa dizer
que o objeto instanciado contém todas as funções do bloco funcional L01_Class. Como a
lógica do bloco funcional L02_Class_Com_Heranca também tem um temporizador (TEE2),
este é declarado “local” com outro nome para evitar assim o conflito com o temporizador
(TEE) declarado no bloco funcional base. Já a saída do bloco base é entrada do novo bloco.
Para acessar o seu valor, basta colocar o prefixo “SUPER^.”. Depois de processado, é
sobrescrita a variável de saída do bloco funcional base (Saida01).

Ao aplicar o bloco funcional na aplicação, como visto na Figura 4.10, o impacto

visual é grande, pois parece não lembrar à aplicação mostrada na Figura 4.1; mas ao executar
a aplicação os resultados serão os mesmos.

Figura 4.10 – Sistema após a aplicação da L02_Class_Com_Heranca

continua
 58

continuação

Fonte: Elaborado pelo autor (2014)

Apesar do uso explícito de um bloco de função a menos, o tamanho do programa não

diminui, ainda cria uma dificuldade maior de entendimento. Com isso é finalizada a aplicação
da Orientação a Objetos nesta aplicação de Controle e Automação. Na seção seguinte,
apresentam-se alguns resultados com a aplicação destas três técnicas: abstração, classes e
herança.

4.2.5 Resultados

Diante da construção do Trabalho, cujo objetivo é diminuir os custos com o

desenvolvimento e manutenção de aplicações de Automação Industrial, obtiveram-se alguns
resultados. Banker e Datar (1989) mostram, em seu estudo, um perfil de aplicações em 1989,
relevante para o estudo atual conhecer o tamanho das aplicações.
 59

Tabela 4.1 – Perfil de sistemas

Variável Média Desvio Padrão Mínimo Máximo

Erros/Ano 348 561 14 2995

Custo programação/Ano U$ 69.300,00 U$ 66.100,00 U$ 8.300,00 U$ 353.200,00

Linhas de código 21.500 18.500 54.000 702.000

Fonte: adaptado de Banker e Datar (1989).

A Tabela Tabela 4.1 mostra que em 1989 uma aplicação tinha em média 21.500
linhas de código (lógicas). Sabe-se que o tamanho dos programas atuais só aumenta, pois cada
vez mais, temos mais controle em plantas industriais. Aiken et al. (2000) aponta que o custo
de indústria parada gira em torno de U$ 3.000,00 por minuto. Sendo assim, é possível validar
este estudo tabulando os dados da seguinte forma:

 paradigma utilizado;

 número de lógicas Ladder: determinam a possibilidade de custo da planta

parada, pois podem vir receber qualquer alteração no futuro;

 tempo para alterar uma lógica: baseado na experiência adquirida neste trabalho;

 custo total da manutenção.

Os dados para o paradigma Sequencial Lógico tem sua fonte na da Figura 4.1, e os
dados do paradigma de Orientação a Objetos nas Figuras 4.3, 4.4 e 4.8. Define-se, assim, a
Tabela 4.2.

Tabela 4.2 – Possível custo de manutenção com aplicações

Paradigma Lógicas Tempo Custo Total

Sequencial Lógico 12 90s (1,5min) U$ 54.000,00

(12 * 1,5 * 3000)

Orientação a Objetos 10 90s (1,5min) U$ 45.000,00

(10 * 1,5 * 3000)

Fonte: elaborado pelo autor (2014).

 60

Apesar da economia de U$ 9.000,00, deve-se ressaltar que a Tabela contabiliza

apenas a troca ou inserção de elementos dentro da lógica, logo, parti-se do pressuposto de que
o desenvolvedor saiba qual é o problema, ou qual a implementação nova que deve ser feita.
Caso necessite depurar a aplicação até encontrar um erro, ou entender o funcionamento da
mesma antes de implementar uma nova rotina, os custos terão um aumento significativo.
 61

CONSIDERAÇÕES FINAIS

Pode-se afirmar que existe um ganho real ao adotar o paradigma de Orientação a

Objetos em aplicações de Automação e Controle, pois os códigos gerados através deste
paradigma se mostram mais organizados, passíveis de reutilização e permitem uma
manutenção mais rápida e apropriada. Porém, vale destacar que o estudo foi elaborado a partir
de um problema conhecido e já modelado no paradigma Sequencial Lógico. Esse foi um dos
problemas enfrentados para a medição dos resultados, já que não permitiu a resolução do
problema e o acompanhamento do desenvolvimento da aplicação nos dois paradigmas.

Outra dificuldade encontrada refere-se às indústrias aceitarem a proposta de resolver

algum problema ou adaptar um problema já existente de seu processo produtivo, apesar do
estudo poder gerar algum ganho para essas indústrias. Das cinco indústrias consultadas apenas
uma apoiou o estudo, enquanto as outras justificaram que seu processo é sigiloso. Como
possibilidade de trabalhos futuros propõe-se a aplicação desse estudo a um problema real de
automação desenvolvido desde o início, para também acompanhar o processo de manutenção
do projeto aplicado junto aos engenheiros de aplicação.
 REFERÊNCIAS

3S-Smart Software Solutions Gmb. OOP in an IEC 61131-3 Tool. CoDeSys Object-
Oriented Controller Programming. 2009. Disponível em:
http://ftc.beijer.se/files/C125728B003AF839/B0022B2949098947C1257A6300283F69/CoDe
Sys_OOP_2009_e.pdf>. Acesso em: 23/01/2014.
AIKEN, Alexander; FÄHNDRICH, Manuel; SU, Zhendong. Detecting races inRelay
Ladder Logic programs. International Journal on Software Tools for Technology Transfer,
vol.3, n.1, p93-105, 2000. Disponível em:
<http://www.cs.ucdavis.edu/~su/publications/sttt00.pdf>. Acesso em: 28 nov. 2013.
ALTUS Sistemas de Automação S.A.. Série MASTERTOOL. In: Histórico de Revisões de
Software. São Leopoldo. 2013a. Disponível em:
<http://www.altus.com.br/ftp/Public/Portugues/Revisoes%20de%20Produtos/HistoricoReviso
esSoftwareALTUS.pdf>. Acesso em 21 dez. 2013.
ALTUS Sistemas de Automação S.A.. MasterTool IEC XE. São Leopoldo. 2013c.
Disponível em: <
http://www.altus.com.br/ftp/Public/Portugues/Produtos/Mtool/01%20Software/MT8500%20-
%20MasterTool%20IEC%20XE/Caracteristicas%20Tecnicas/CT103705.pdf>. Acesso em 21
dez. 2013.
ALTUS Sistemas de Automação S.A.. Série MasterTool IEC XE. São Leopoldo. 2013b.
Disponível em: <
http://www.altus.com.br/site_ptbr/index.php?option=com_content&view=article&id=638&Ite
mid=289>. Acesso em 21 dez. 2013.
ALVES, Anísio Chagas Bernardino. A Norma Iec 61131. Sistemas de Controle:
Especificação e Implantação, Curso de Pós-graduação Latu-sensu Especialização em
Instrumentação e Controle de Processos industriais, Universidade Federal do Espírito Santo,
out., 2008. Disponível em:
<http://libertas.pbh.gov.br/~danilo.cesar/outros/concurso_ufmg/Sistemas_de_Controle_-
_NORMA_IEC_61131.pdf>. Acesso em: 20 set. 2013.
BANKER, Rajiv D.; DATAR, Srikant M.; ZWEIG, Dani. Software complexity and
maintainability. Age, v. 11, n. 5.6, p. 3, 1989.
BOLSHAKOVA, Elena. Programming paradigms in computer science education.
International Journal Information Theories and Applications, vol.12, n.3, p285, 2005.
Disponível em: <http://www.foibg.com/ijita/vol12/ijita12-3-p13.pdf>. Acesso em: 20 set.
2013.
BUYYA, Rajkumar; CHU, Xingchen; SELVI, S Thamarai. Object-Oriented Programming
With Java: Essentials and Applications. New Delhi, Tata Mcgraw-Hill Publishing
Company, 2009. 649p.
CAPRETZ, Luiz Fernando. A brief history of the object-oriented approach. ACM
SIGSOFT Software Engineering Notes, vol.28, n.2, p.6, mar., 2003.
CARDELLI, Luca; WEGNER, Peter. On Understanding Types, Data Abstraction, and
Polymorphism. Computing Surveys, vol.17, n.4, p.471-522, 1985. Disponível em: <
http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf>. Acesso em: 20 set. 2013.
CHIRON, Fabien; KOUISS, Khalid,. Design of IEC 61131-3 Function Blocks using
SysML. Mediterranean Conference on Control & Automation, Athens, 2007.
 63

COSTA, Eduard Montgomery Meira. Redes de Petri: um paradigma de modelagem para a

automação. Mecatrônica Atual, n4, p18-23, 2009.
DURVAL, Santiago Arias. Ladder Logic Programming in Industrial Controls. Deposition
Industrial Controls. 2011. Disponivel em: <
http://www.ece.gatech.edu/academic/courses/ece4007/11spring/ECE4007L05/kj10/Technical
_Review.pdf>. Acesso em: 08 dez. 2013.
FERREIRA, Aurélio Buarque de Holanda. Mini Dicionário da Língua Portuguesa. 2ª ed.
Rio de Janeiro, RJ: Nova Fronteira, 1988, 536 p.
FILHO, João Aristides Bottura. Benefícios da norma IEC61131-3 aplicada a CLP’s.
Artigos Técnicos, ISA Seção Rio de Janeiro, fev., 2005. Disponível em: <
http://www.isarj.org.br/pdf/artigos/IEC%2061131-3.pdf>. Acesso em: 19 ago. 2013.
GEORGINI, Marcelo. Automação aplicada. 4a.ed. – São Paulo: Érica, 2003. 236p.
GUIMARÃES, Hugo Casati Ferreira. Norma IEC 61131-3 para programação de
controladores programáveis: estudo e aplicação. Projeto de Graduação. Universidade
Federal do Espírito Santo, 2005. Disponível em:
<http://www2.ele.ufes.br/~projgrad/documentos/PG2005_1/hugocasatiferreiraguimaraes.pdf>
. Acesso em: 19 ago. 2013.
HAN, Kwan Hee; PARK, Jun Woo. Development of Object-Oriented Modeling Tool for
the Design of Industrial Control Logic. IEEE XV SERA, p.353-358. 2007.
JOHN, Karl-Heinz; TIEGELKAMP, Michael. IEC 61131-3: programming industrial
automation systems: concepts and programming languages, requirements for
programming systems, decision-making aids. Springer, 2010.
KAJIHARA, S.; ONO, M.; HOUZOUJI, H.; TARUISHI, H.; TAKAYANAGI, Y..
Development and products of the object-oriented engineering tool for the integrated controller
based on IEC 61131-3. In: SICE annual conference. 2004. p.1952-1956.
LEITE, Mario, JUNIOR, Nelson Abu Sanra Rahal. Programação Orientada a Objeto: Uma
Abordagem Didática. 2002. Disponível em: <
http://www.ccuec.unicamp.br/revista/infotec/artigos/leite_rahal.html> Acesso em: 04 dez.
2013.
BRUNE, Osmar; LIMA, Rafael. Projeto SimulDelay. In: Disciplina Algoritmos de Controle
da Pós-Graduação Especialização em Automação e Controle. Universidade Feevale. 2013.
MARTINS, Geomar Machado. Princípios de Automação Industrial. 2012. Disponível em:
<http://coral.ufsm.br/desp/geomar/automacao/Apostila_032012.pdf>. Acesso em: 19 ago.
2013.
MEYER, Bertrand. Object-Oriented Software Construction. 2nd ed. Upper Saddle River,
NJ: Prentice Hall, 2000. 1296p.
MORAES, Cícero Couto de; CASTRUCCI, Plínio de Lauro, Engenharia de automação
industrial- 1a. ed. - Rio de Janeiro: LTC, 2001. 295p.
NISE, Norman S. Control Systems Engineering. 6th ed. Hoboken, NJ: John Wiley & Sons,
Inc., 2011. 944p.
OTTO, Andreas; HELLMANN, Klas. IEC 61131: A general overview and emerging
trends. Industrial Electronics Magazine, IEEE, vol.3, n.4, p27-31, 2009.
 64

PASCOE, Geoffrey A. Elements of Object-Oriented Programming. Byte vol.11, n8, p139-

144, ago., 1986.
PINTO, Fabio da Costa. Sistemas de Automação e Controle. 2005. Disponível em:
<http://www.abraman.org.br/Arquivos/41/41.pdf>. Acesso em: 19 ago. 2013.
PLCopen. Article 2 In: Articles of Association. [s.d.]. Disponível em: <
http://www.plcopen.org/pages/organization/articles_of_association/>. Acesso em: 29 de
outubro de 2013.
PORTAL FATOR BRASIL. Schneider Electric apresenta soluções para controle e
instrumentação na ISA Show South America 2007. 2007. Disponível em: <
http://www.revistafatorbrasil.com.br/ver_noticia.php?not=25183>. Acesso em: 31 dez. 2013.
PRODANOV, Cleber Cristiano; FREITAS, Ernani Cesar de. Metodologia do trabalho
científico [recurso eletrônico]: métodos e técnicas da pesquisa e do trabalho acadêmico.
2.ed. Novo Hamburgo: Feevale, 2013. 277p.
SANTOS, Guilherme. A pirâmide da automação industrial. Automação Industrial. [s.d.].
Disponível em: <http://www.automacaoindustrial.info/a-piramide-da-automacao-industrial/>.
Acesso em: 29 de outubro de 2013.
SCHNEIDER ELECTRIC. Schneider Electric apóia publicação sobre a norma IEC
61131. 2009. Disponível em < http://www.schneider-
electric.com.br/brasil/pt/empresa/noticias/releases/pesquisa-de-
releases.page?c_filepath=/templatedata/Content/News/data/pt/local/releases/releases/2009/05/
20090512_schneider_electric_apoia_publicac_o_sobre_a_norma_iec_61131.xml>. Acesso
em: 22/01/2014.
VAN DER WAL, E. Introduction into IEC 1131-3 and PLCopen. In: The Application of
IEC 61131 to Industrial Control: Improve Your Bottom Line Through High Value
Industrial Control Systems (Ref. No. 1999/076), IEE Colloquium on. IET, 1999. p2/1-2/8.
 65

APÊNDICES
 66

De: Rafael Lima

Enviada em: quarta-feira, 30 de outubro de 2013 17:26
Para: Emerson Butzen
Cc: Jones Clemente Camilo
Assunto: ENC: Aplicação com AL ou PO para monografia

Valeu a força Jones.

Sds,
Rafael Lima
Project Manager - R&D
——————————
Fone: +55 51 3589 9500
Celular: +55 51 9246 7295
e-mail: rafael.lima@altus.com.br

www.altus.com.br @altus_sa
Suporte Técnico: 0800 510 9500
Matriz:
Av. Theodomiro Porto da Fonseca, 3101
CEP 93020-080 - Bairro Duque de Caxias
São Leopoldo/RS – Brasil
Colabore com o Programa Ambiental Altus! Antes de imprimir, pense em sua responsabilidade e compromisso com o meio-
ambiente. E lembre-se: a prevenção é a melhor forma de evitar acidentes do trabalho!
- As informações contidas neste e-mail são confidenciais e de utilização exclusiva do(s) destinatário(s), sendo seu sigilo
protegido por lei. Se você recebeu por engano, por favor, apague-o imediatamente sem copiá-lo, armazená-lo ou distribuí-lo.

De: Jones Clemente Camilo

Enviada em: quarta-feira, 30 de outubro de 2013 17:26
Para: Rafael Lima
Assunto: ENC: Aplicação com AL ou PO para monografia

Em anexo.

Sds,
Jones Clemente Camilo
Especialista de Produtos
——————————
Fone: +55 11 20391950
Celular: +55 11 993480863
e-mail: jones@altus.com.br
Skype: jonesccamilo
TV Altus: http://vimeo.com/channels/altus/

www.altus.com.br @altus_sa
Suporte Técnico: 0800 510 9500
Suporte Técnico: 051 35899546
Filial São Paulo
Alameda dos Maracatins, 780 – Conjunto 1501
CEP 04080-001 - Bairro Moema
São Paulo/SP – Brasil
Colabore com o Programa Ambiental Altus! Antes de imprimir, pense em sua responsabilidade e compromisso com o meio-
ambiente. E lembre-se: a prevenção é a melhor forma de evitar acidentes do trabalho!
- As informações contidas neste e-mail são confidenciais e de utilização exclusiva do(s) destinatário(s), sendo seu sigilo
protegido por lei. Se você recebeu por engano, por favor, apague-o imediatamente sem copiá-lo, armazená-lo ou distribuí-lo.
 67

De: Ronildo Alves Batista [mailto:ronildo.batista@usiminas.com]

Enviada em: quarta-feira, 30 de outubro de 2013 16:48
Para: Jones Clemente Camilo
Assunto: ENC: Aplicação com AL ou PO para monografia

Jones, segue.

Aplicação envio de amostras de aço para analise via motores tipo turbina.

Ronildo Alves Batista

Supervisor de Manutenção - U1 Manu Acia

Av. Pedro Linhares Gomes, 5431 - Bairro Usiminas

CEP 35160-900 - Ipatinga - MG
T 55 31 38290948
F 55 31 38290948
C 55 31 98334411
www.usiminas.com
======================================
Classificação:
Público [ ] Uso interno [ ] Restrito [ X ] Confidencial [ ]

Grupo de acesso:
Destinatários deste correio
======================================

Aviso Legal
Esta mensagem e/ou seus anexos podem conter informações privilegiadas, sejam elas confidenciais, restritas ou internas das
empresas do Grupo Usiminas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem e/ou seus
anexos, você não deve usar, copiar ou divulgar as informações nela contida ou tomar qualquer ação baseada nessas
informações.
Este ambiente está sujeito a monitoramento.

Lawful Warning
This message and / or its attachments may contain privileged information, either confidential, restricted or internal from the
USIMINAS Group’s companies. If you are not the receiver or authorized person to receive this message and /or its attachments,
you must not use, copy or disclose the information contained in it or take any action based on this information.
This environment is subject to monitoring.
 68

De: Ivan Caetano de Sousa

Enviada em: terça-feira, 29 de outubro de 2013 13:57
Para: Ronildo Alves Batista
Assunto: RES: Aplicação com AL ou PO para monografia

Ok, enviador de amostra é o ideal.

Ivan Caetano de Sousa

Gerente de Manutenção da Aciaria
ivan.caetano@usiminas.com

" O ZERO ACIDENTE É POSSÍVEL "

Av. Pedro Linhares Gomes, 5.431 - Bairro Usiminas

CEP: 35160-900 - Ipatinga, Minas Gerais - Brasil
T 55 31 3829-0952
C 55 31 8317-8913
www.usiminas.com

Classificação da informação: ( ) Confidencial ( ) Restrita ( ) Uso Interno ( ) Pública

Grupo de acesso: Destinatários deste e-mail

Aviso Legal
Esta mensagem e/ou seus anexos podem conter informações privilegiadas, sejam elas confidenciais, restritas ou internas das
empresas do Grupo Usiminas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem e/ou seus
anexos, você não deve usar, copiar ou divulgar as informações nela contida ou tomar qualquer ação baseada nessas
informações.
Este ambiente está sujeito a monitoramento.

Lawful Warning
This message and / or its attachments may contain privileged information, either confidential, restricted or internal from the
USIMINAS Group’s companies. If you are not the receiver or authorized person to receive this message and /or its attachments,
you must not use, copy or disclose the information contained in it or take any action based on this information.
This environment is subject to monitoring.
 69

De: Ronildo Alves Batista

Enviada em: terça-feira, 29 de outubro de 2013 12:42
Para: Ivan Caetano de Sousa
Assunto: RES: Aplicação com AL ou PO para monografia

Podemos enviar de equipamento mais simples, como o Enviador de amostras ou KGC.

Ronildo Alves Batista

Supervisor de Manutenção - U1 Manu Acia

Av. Pedro Linhares Gomes, 5431 - Bairro Usiminas

CEP 35160-900 - Ipatinga - MG
T 55 31 38290948
F 55 31 38290948
C 55 31 98334411

www.usiminas.com

======================================
Classificação:
Público [ ] Uso interno [ ] Restrito [ X ] Confidencial [ ]

Grupo de acesso:
Destinatários deste correio
======================================

Aviso Legal
Esta mensagem e/ou seus anexos podem conter informações privilegiadas, sejam elas confidenciais, restritas ou internas das
empresas do Grupo Usiminas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem e/ou seus
anexos, você não deve usar, copiar ou divulgar as informações nela contida ou tomar qualquer ação baseada nessas
informações.
Este ambiente está sujeito a monitoramento.

Lawful Warning
This message and / or its attachments may contain privileged information, either confidential, restricted or internal from the
USIMINAS Group’s companies. If you are not the receiver or authorized person to receive this message and /or its attachments,
you must not use, copy or disclose the information contained in it or take any action based on this information.
This environment is subject to monitoring.
 70

De: Ivan Caetano de Sousa

Enviada em: segunda-feira, 28 de outubro de 2013 17:57
Para: Ronildo Alves Batista
Assunto: RES: Aplicação com AL ou PO para monografia

Tem como mandar alguma aplicação simples e que não contenha detalhes do nosso processo?

Ivan Caetano de Sousa

Gerente de Manutenção da Aciaria
ivan.caetano@usiminas.com

" O ZERO ACIDENTE É POSSÍVEL "

Av. Pedro Linhares Gomes, 5.431 - Bairro Usiminas

CEP: 35160-900 - Ipatinga, Minas Gerais - Brasil
T 55 31 3829-0952
C 55 31 8317-8913
www.usiminas.com

Classificação da informação: ( ) Confidencial ( ) Restrita ( ) Uso Interno ( ) Pública

Grupo de acesso: Destinatários deste e-mail

Aviso Legal
Esta mensagem e/ou seus anexos podem conter informações privilegiadas, sejam elas confidenciais, restritas ou internas das
empresas do Grupo Usiminas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem e/ou seus
anexos, você não deve usar, copiar ou divulgar as informações nela contida ou tomar qualquer ação baseada nessas
informações.
Este ambiente está sujeito a monitoramento.

Lawful Warning
This message and / or its attachments may contain privileged information, either confidential, restricted or internal from the
USIMINAS Group’s companies. If you are not the receiver or authorized person to receive this message and /or its attachments,
you must not use, copy or disclose the information contained in it or take any action based on this information.
This environment is subject to monitoring.
 71

De: Ronildo Alves Batista

Enviada em: segunda-feira, 28 de outubro de 2013 16:43
Para: Ivan Caetano de Sousa
Cc: Laert Benatti Neto
Assunto: ENC: Aplicação com AL ou PO para monografia

Ivan, gostaria de saber se poço atender a solicitação abaixo.

Ronildo Alves Batista

Supervisor de Manutenção - U1 Manu Acia

Av. Pedro Linhares Gomes, 5431 - Bairro Usiminas

CEP 35160-900 - Ipatinga - MG
T 55 31 38290948
F 55 31 38290948
C 55 31 98334411

www.usiminas.com

======================================
Classificação:
Público [ ] Uso interno [ ] Restrito [ X ] Confidencial [ ]

Grupo de acesso:
Destinatários deste correio
======================================

Aviso Legal
Esta mensagem e/ou seus anexos podem conter informações privilegiadas, sejam elas confidenciais, restritas ou internas das
empresas do Grupo Usiminas. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem e/ou seus
anexos, você não deve usar, copiar ou divulgar as informações nela contida ou tomar qualquer ação baseada nessas
informações.
Este ambiente está sujeito a monitoramento.

Lawful Warning
This message and / or its attachments may contain privileged information, either confidential, restricted or internal from the
USIMINAS Group’s companies. If you are not the receiver or authorized person to receive this message and /or its attachments,
you must not use, copy or disclose the information contained in it or take any action based on this information.
This environment is subject to monitoring.
 72

De: Jones Clemente Camilo [mailto:jones@altus.com.br]

Enviada em: segunda-feira, 28 de outubro de 2013 16:28
Para: Ronildo Alves Batista
Cc: Emerson Butzen; Rafael Lima
Assunto: Aplicação com AL ou PO para monografia

Caro Ronildo, boa tarde.

Como comentei contigo, a Altus tem parceria com a FEEVALE (que é uma universidade no Rio Grande do Sul). Nesta parceria
foi criado um curso de pós graduação onde projetistas do Nexto ministram cursos e outros colegas que também trabalham do
P&D da Altus são alunos.

Afim de desenvolver monografias mais consistentes, estamos entrando em contato com usuários de Altus que utilizam desde
controladores mais antigos aos mais novos.

Na minha opinião as aplicações feitas na Aciaria são ideais para esse estudo.

Neste projeto da Monografia, os desenvolvedores irão aplicar técnicas avançadas em alguns trechos de códigos de CLPs AL
ou Ponto para testar o comportamento da lógica.

Poderia passar uma copia de algum programa AL que vocês tem na Aciaria. Se possível, também citar as principais
características do processo, exemplo: controle de dosagem, revezamento de bombas, receitas, controle de nível, etc. Não
precisa detalhar o programa.

Friso que é apenas para uso para esse fim, e é de extremo sigilo. Isto é, não iremos publicar todo o conteúdo do programa.
Podemos emitir uma carta de sigilo caso você julgue necessário.

Estou mandando em cópia para as duas pessoas do P&D que estão trabalhando neste projeto.

Muito obrigado mais uma vez pela ajuda. Forte abraço.

Sds,
Jones Clemente Camilo
Especialista de Produtos
——————————
Fone: +55 11 20391950
Celular: +55 11 993480863
e-mail: jones@altus.com.br
Skype: jonesccamilo
TV Altus: http://vimeo.com/channels/altus/

www.altus.com.br @altus_sa
Suporte Técnico: 0800 510 9500
Suporte Técnico: 051 35899546
Filial São Paulo
Alameda dos Maracatins, 780 – Conjunto 1501
CEP 04080-001 - Bairro Moema
São Paulo/SP – Brasil
Colabore com o Programa Ambiental Altus! Antes de imprimir, pense em sua responsabilidade e compromisso com o meio-
ambiente. E lembre-se: a prevenção é a melhor forma de evitar acidentes do trabalho!

- As informações contidas neste e-mail são confidenciais e de utilização exclusiva do(s) destinatário(s), sendo seu sigilo
protegido por lei. Se você recebeu por engano, por favor, apague-o imediatamente sem copiá-lo, armazená-lo ou distribuí-lo.

- The contents of this e-mail are confidential to the addressee and are intended solely for the recipients use. If you are not the
addressee, you have received this e-mail in error. Any disclosure, copying, distribution or action taken in reliance on it is
prohibited and may be unlawful.