Você está na página 1de 93

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO CEARÁ -

IFCE
IFCE CAMPUS FORTALEZA

CURSO DE TECNOLOGIA EM MECATRÔNICA INDUSTRIAL

DANIEL SILVA DE OLIVEIRA

INTEGRAÇÃO DE SOFTWARES DE AUTOMAÇÃO COM PROTOCOLO OPC PARA


A APRENDIZAGEM DE PROGRAMAÇÃO

FORTALEZA
2021
DANIEL SILVA DE OLIVEIRA

INTEGRAÇÃO DE SOFTWARES DE AUTOMAÇÃO COM PROTOCOLO OPC PARA


A APRENDIZAGEM DE PROGRAMAÇÃO

Trabalho de conclusão de curso, na forma de monogra-


fia, apresentado ao curso de Tecnologia em Mecatrô-
nica Industrial do Instituto Federal de Educação, Ciên-
cia e Tecnologia do Ceará – IFCE – Campus Fortaleza,
como requisito para obtenção do Título de Graduação.

Orientador: Prof. Me. Josias Guimarães Batista

FORTALEZA
2021
DANIEL SILVA DE OLIVEIRA

INTEGRAÇÃO DE SOFTWARES DE AUTOMAÇÃO COM PROTOCOLO OPC PARA


A APRENDIZAGEM DE PROGRAMAÇÃO

Trabalho de conclusão de curso, na forma de monografia, apresen-


tado ao curso de Tecnologia em Mecatrônica Industrial do Instituto
Federal de Educação, Ciência e Tecnologia do Ceará – IFCE –
Campus Fortaleza, como requisito para obtenção do Título de
Graduação, aprovado pela comissão formada pelos professores:

Aprovado em ____/____/_______

BANCA EXAMINADORA

Prof. Me. Josias Guimarães Batista (Orientador)


Departamento de Indústria, Campus Fortaleza
(IFCE)

Prof. Dr. André Pimentel Moreira


Departamento de Indústria, Campus Fortaleza
(IFCE)

Prof. Me. José Leonardo Nunes da Silva


Departamento de Indústria, Campus Fortaleza
(IFCE)
Dedico este trabalho primeiramente a Deus que foi a mola propul-
sora de toda permissão de situações na minha vida, depois a minha
família, em particular a minha mãe, que é minha razão de viver,
minha guerreira e incentivadora que nunca deixou eu desistir e
lutou por mim e comigo até o fim.
AGRADECIMENTOS

Meus Agradecimentos primeiramente ao meu Gestor do Senai Elias Pedrosa e as coorde-


nadoras pedagógicas Maria Valcineide e Hyandra do Vale, que me apoiaram neste desafio que
era terminar o ensino superior. Trabalhar e estudar nunca foi uma tarefa fácil, mas labutar com
esse time amenizava muita coisa. Quero agradecer em particular a todos os colaboradores do
IFCE que tiveram paciência comigo, apoiando-me e corrigindo quando necessário. Aos amigos
professores que fiz ao longo da jornada deste curso, em particular a este sensacional Mestre e
Professor que admiro bastante, Josias Guimarães, que foi meu colega de trabalho no Senai e hoje
além de professor de umas das disciplinas mais interessantes do Tecnólogo em Mecatrônica,
Sistema de Supervisão, é meu orientador neste trabalho, ele me fez apaixonar-se pela área
da Pneumática, foi meu instrutor nos primeiros passos da automação, eu fiquei aprendendo e
anotando tudo que ele falava sobre essa parte da mecânica e o encantamento foi tanto que este
trabalho não podia ser sobre outra coisa e nem sobre sua supervisão. E por fim agradecer a todos
os alunos que estudaram comigo, que eu ajudei e que me ajudaram quando eu não tinha mais
forças pra continuar a luta, foram tantos desafios, como trancamento de matricula, turmas de
aulas no Senai que ministrei a noite no horário das aulas no IFCE, COVID 19, e muitos deles me
ajudaram, incentivaram e foram tão importantes que os levarei para o resto da minha vida.
"Nada te perturbe, Nada te espante. Tudo passa. Só Deus perma-
nece. A paciência tudo alcança. Quem a Deus tem, nada lhe falta:
Só Deus basta.

Santa Teresa D’Ávila


RESUMO

Este trabalho consiste em implementar um sistema de comunicação baseado no conceito criado


pela Microsoft®, que permite incorporar e vincular documentos e outros objetos, chamado OLE
(Object Linking and Embedding) da qual se origina o padrão OPC (OLE for Process Control),
permitindo a interoperabilidade entre os softwares Fluidsim®, Codesys® e Elipse SCADA®.
O padrão OPC é um protocolo desenvolvido para permitir a comunicação entre equipamentos
de diferentes fabricantes. O objetivo deste trabalho é mostrar como configurar este protocolo,
para que se estabeleça uma comunicação entre os softwares envolvidos. A primeira parte traz
uma fundamentação teórica dos conteúdos que norteiam a aplicação, depois será apresentado
um passo a passo da configuração do protocolo OPC para cada software. As telas finais de cada
sistema com sua aplicação serão apresentadas nos resultados e a proposta futura será condensada
na conclusão. O trabalho foca em aprendizado baseado em problemas e dará oportunidade de
treino em linguagens de programação sem que se precise dos componentes físicos para obter um
bom desenvolvimento de aprendizagem significativa, atingindo as competências necessárias que
a área exige. Após esse estudo o Aluno ou Professor estará cada um no seu campo de visão com
uma oportunidade de aprendizado dentro dos moldes das metodologias ativas.

Palavras-chave: Padrão OPC, Automação, Supervisão, Didática, Codesys®, Elipse SCADA®,


Fluidsim®, Comunicação entre softwares.
ABSTRACT

This work consists of implementing a communication system based on the concept created by
Microsoft®, which allows embedding and linking documents and other objects, called OLE
(Object Linking and Embedding) from which the OPC standard originates OLE for Process
Control), allowing interoperability between Fluidsim®, Codesys® and Elipse SCADA® software.
The OPC standard is a protocol designed to allow communication between equipment from
different manufacturers. The objective of this work is to show how to program this protocol, so
that communication between the involved softwares can be established. The first part brings a
theoretical foundation of the contents involved, then a step-by-step configuration of the OPC
protocol for each software will be presented. The final screens of each system with its application
will be presented in the results and the future proposal will be condensed in the conclusion.
The work focuses on problem-based learning and will provide the opportunity for training in
programming languages without the need for physical components to obtain a good development
of significant learning, reaching the necessary skills that the area requires. After this study, the
Student or Teacher will each be in their field of vision with a learning opportunity within the
framework of active methodologies.

Keywords: Standard OPC, Automation, Supervision, Didactics, Codesys®, Elipse SCADA®,


Fluidsim®, Communication between software.
LISTA DE ILUSTRAÇÕES

Figura 1 – Pirâmide de Automação. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20


Figura 2 – Simulador da fonte do quadro de comando do tanque de cozimento. . . . . . 23
Figura 3 – Simulador FluidSIM da Festo. . . . . . . . . . . . . . . . . . . . . . . . . 24
Figura 4 – Plataforma 3S CodeSys SP PLCWinNT Festo. . . . . . . . . . . . . . . . . 26
Figura 5 – Detalhamento da IDE CodeSys. . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 6 – Diagrama de blocos dos níveis l, 2 e 3 da pirâmide de automação. . . . . . . 28
Figura 7 – Sistema de supervisão e controle. . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 8 – Tela principal do Elipse SCADA. . . . . . . . . . . . . . . . . . . . . . . . 30
Figura 9 – Diagrama de um Sistema Eletropneumático automatizado. . . . . . . . . . . 31
Figura 10 – Vista em corte de uma válvula duplo solenoide. . . . . . . . . . . . . . . . 32
Figura 11 – Desenho em corte de um atuador eletropneumático. . . . . . . . . . . . . . 33
Figura 12 – Elementos de Sinais Eletropneumáticos. . . . . . . . . . . . . . . . . . . . 33
Figura 13 – Posição e o número de entradas e saídas das válvulas direcionais. . . . . . . 35
Figura 14 – Simbologia dos acionamentos das válvulas direcionais. . . . . . . . . . . . 35
Figura 15 – Válvulas Direcionais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 16 – Simbologia dos atuadores pneumáticos. . . . . . . . . . . . . . . . . . . . 37
Figura 17 – Circuito Eletropneumático. . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figura 18 – Simbologia do cilindro de dupla ação. . . . . . . . . . . . . . . . . . . . . 39
Figura 19 – Sequência de Acionamento de Atuadores. . . . . . . . . . . . . . . . . . . 40
Figura 20 – Diagrama trajeto passo da sequencia A+ B+ A- B-. . . . . . . . . . . . . . 40
Figura 21 – Técnica cadeia estacionária. . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 22 – Hierarquia das camadas do modelo de referência OSI. . . . . . . . . . . . . 43
Figura 23 – Acesso a dados de processos com protocolo OPC. . . . . . . . . . . . . . . 44
Figura 24 – Evolução da tecnologia OPC. . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 25 – Cliente Servidor OPC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 26 – Arquitetura Protocolo OPC. . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figura 27 – Formato Binário e XML do protocolo OPC. . . . . . . . . . . . . . . . . . 48
Figura 28 – Convergência de tecnologias. . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figura 29 – Modelo TCP e SOAP para o protocolo OPC. . . . . . . . . . . . . . . . . . 49
Figura 30 – Esquema hipotético. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 31 – Diagrama Trajeto Passo do esquema hipotético. . . . . . . . . . . . . . . . 51
Figura 32 – Diagrama Eletropneumático. . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 33 – Sequencia de acordo com o diagrama trajeto passo. . . . . . . . . . . . . . 52
Figura 34 – Divisão da sequência em passos. . . . . . . . . . . . . . . . . . . . . . . . 53
Figura 35 – Diagrama de comando eletropneumático. . . . . . . . . . . . . . . . . . . . 53
Figura 36 – Diagrama de contatos eletropneumáticos. . . . . . . . . . . . . . . . . . . . 54
Figura 37 – Diagrama de força. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 38 – Criação de um novo programa no Codesys®. . . . . . . . . . . . . . . . . . 55
Figura 39 – Criação do target Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 40 – Criação do target Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 41 – Criação do target Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 42 – Definição da Linguagem de Programação. . . . . . . . . . . . . . . . . . . 57
Figura 43 – Definição das variáveis globais. . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 44 – Identificação das variáveis globais. . . . . . . . . . . . . . . . . . . . . . . 58
Figura 45 – Exportação das variáveis globais. . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 46 – Escolha das variáveis globais para exportação. . . . . . . . . . . . . . . . . 59
Figura 47 – Exportando variáveis para outros sistemas. . . . . . . . . . . . . . . . . . . 60
Figura 48 – Salvando arquivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 49 – Compilação da programação. . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 50 – Verificação de erros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 51 – Parâmetros de configuração. . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figura 52 – Nomeação do Servidor de comunicação. . . . . . . . . . . . . . . . . . . . 63
Figura 53 – Link de comunicação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 54 – CLP Virtual do Codesys. . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 55 – Tempo máximo de operação do CLP Virtual. . . . . . . . . . . . . . . . . . 64
Figura 56 – CLP Virtual em Running. . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 57 – Protocolo OPC do Codesys. . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 58 – Configuração do CLP Virtual para modo Single. . . . . . . . . . . . . . . . 65
Figura 59 – Edição do modo Single do CLP Virtual. . . . . . . . . . . . . . . . . . . . 66
Figura 60 – Conexão OPC do Codesys. . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figura 61 – Componentes de comunicação OPC. . . . . . . . . . . . . . . . . . . . . . 67
Figura 62 – Representação dos blocos do CLP Festo . . . . . . . . . . . . . . . . . . . 67
Figura 63 – Habilitação da comunicação OPC do Fluidsim. . . . . . . . . . . . . . . . . 68
Figura 64 – Propriedades de comunicação OPC. . . . . . . . . . . . . . . . . . . . . . . 68
Figura 65 – Configuração das Portas do OPC. . . . . . . . . . . . . . . . . . . . . . . . 69
Figura 66 – Servidor OPC da Festo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figura 67 – Servidor OPS no Codesys. . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Figura 68 – Configuração da porta de entrada do módulo lógico. . . . . . . . . . . . . . 70
Figura 69 – Configuração do bloco de CLP para entradas e saídas. . . . . . . . . . . . . 71
Figura 70 – Ícone Elipse SCADA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figura 71 – Tela de configuração do Elipse SCADA. . . . . . . . . . . . . . . . . . . . 72
Figura 72 – Nova aplicação no Elipse. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figura 73 – Configuração do servidor OPC do Elipse. . . . . . . . . . . . . . . . . . . . 73
Figura 74 – Servidor OPC criado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figura 75 – Localizar o tipo de servidor OPC. . . . . . . . . . . . . . . . . . . . . . . . 74
Figura 76 – Servidores Locais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figura 77 – Importar variáveis globais. . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figura 78 – Configuração do bloco de CLP para entradas e saídas. . . . . . . . . . . . . 76
Figura 79 – Habilita escrita automática. . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figura 80 – Configurações das variáveis globais. . . . . . . . . . . . . . . . . . . . . . 77
Figura 81 – Circuito eletropneumático de comando. . . . . . . . . . . . . . . . . . . . . 78
Figura 82 – Circuito elétrico do CLP no Fluidsim. . . . . . . . . . . . . . . . . . . . . 79
Figura 83 – Tela final do supervisório. . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figura 84 – Programação Parte 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figura 85 – Programação Parte 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figura 86 – Programação Parte 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figura 87 – Programação Parte 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figura 88 – Programação Parte 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figura 89 – Programação Parte 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figura 90 – Programação Parte 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figura 91 – Programação Parte 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
LISTA DE ABREVIATURAS E SIGLAS

IFCE Instituto Federal de Ciência, Tecnologia e Educação do Ceará

OLE Object Linking and Embedding

OPC OLE for Process Control

CLP Controlador Lógico Programável

IHM Interface Homem – Máquina

COM Component Object Model

DCOM Distributed Componen Object Model

IEC International Electro technical Comission

SCADA Supervisory Control And Data Acquisition

IP Internet Protocol

TCP Transmission Control Protocol

DIN Instituto Alemão para Normatização (do original Deutsches Institut für
Normung)

IEC Comissão Eletrotécnica Internacional (do original International Electrotech-


nical Commission)

IEEE Institute of Electrical and Eletronic Engineers

IOT Internet of Things

LAN Local Area Network

OSI Open System Interconnection

OPC UA OLE for Process Control Unified Architecture

OPC-DA OLE for Process Control Data Access

MES Manufacturing Execution Systems

ERP Enterprise Resource Planning

PIMS Process Information Management System

LIMS Laboratory Information Management System


SED Simulação a Eventos Discretos

CAD Desenho Assistido por Computador

CAM Manufatura assistida por computador

CNC Comando Numérico Computadorizado

OTS Simuladores para Treinamento Operacionais

SENAI Serviço Nacional de Aprendizagem Industrial

EAD Educação à Distância

ISO International Organization for Standardization

PLC Programmable Logic Controllers

OPC AE OLE for Process Control Alarmes e Eventos

OPC HDA OLE for Process Control Historical Data Access

XML eXtensible Markup Language

DIN Deutsches Institut für Normung

CAN Controller Area Network

MATLAB Matrix Laboratory

HTTP HyperText Transfer Protocol

MQTT Message Queue Telemetry Transport

UFPR Universidade Federal do Paraná

ABNT Associação Brasileira de Normas Técnicas

NBR Norma brasileira

ST Structured Text

IL Instruction List

LD Ladder

FBD Function Block Diagram

SFC Sequential Function Chart


SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Importância do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Revisão da literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Motivação e problemática . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5 Contribuições do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Automação Industrial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Os Simuladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 O Software FluidSIM® . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 A plataforma CodeSys® . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 O Sistema SCADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6 Os Sistemas Eletropneumáticos . . . . . . . . . . . . . . . . . . . . . . . 31
2.6.1 Elementos de Comando . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6.2 Elementos de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6.3 Elementos de Sinal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6.4 Método de Maximização de Contatos . . . . . . . . . . . . . . . . . . . . 39
2.7 O Protocolo OPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.7.1 O Protocolo OPC UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.7.1.1 Formato UA Binário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.7.1.2 Formato XML – Extensible Markup Language . . . . . . . . . . . . . . . . . 47
2.7.1.3 Protocolo OPC/TCP (OLE for Process Control / Transmission Control Protocol) 48
2.7.1.4 Protocolo SOAP/HTTPS (Simple Object Access Protocol / Hypertext Transfer
Protocol Secure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1 Resolução da situação problema pelo método da maximização de conta-
tos no FluidSIM® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 Configuração do protocolo OPC no Codesys® . . . . . . . . . . . . . . . 55
3.3 Configuração do protocolo OPC no Fluidsim® . . . . . . . . . . . . . . 67
3.4 Configuração do protocolo OPC no Elipse SCADA® . . . . . . . . . . . 71

4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1 Resultado Final do Codesys . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2 Resultado Final do Fluidsim® . . . . . . . . . . . . . . . . . . . . . . . . 77
4.3 Resultado Final do Elipse SCADA® . . . . . . . . . . . . . . . . . . . . . 79
4.4 Discussões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.1 Sugestões para trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . 82

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

APÊNDICE A – PROGRAMAÇÃO EM LADDER NO CODESYS . . 88


14

1 INTRODUÇÃO

Os conhecimentos são construídos sobre prismas, um deles é a necessidade de fazer


articulações entre o que já se sabe e os novos conceitos que se vão aprender. Essas interações
dão-se ao longo da vida, elas podem ser únicas configurando um processo peculiar ou coletivas.
Segundo o filósofo francês Lévy (2007), acredita que o desenvolvimento da inteligência coletiva
se dá tanto pela reflexão filosófica, histórica e sociológica, quanto pela aplicação em tecnologias.
A metodologia ou aprendizagem ativa passa pelo processo da inteligência coletiva,
baseados em projetos colaborativos, focados em situações-problemas nos quais os discentes são
protagonistas na criação de novos conhecimentos e competências que podem ser aplicados em
várias áreas acadêmicas e profissionais, portanto é muito importante um olhar diferenciado para
o ensino acadêmico.
Em consonância com as ideias de Villas-Boas e Neto (2011) a reformulação da formação
do perfil profissional do engenheiro, coloca então demandas por novas metodologias ativas,
análises pedagógicas inseridas no contexto dessa nova forma de pensar a educação e visões da
relação ensino-aprendizagem mais denso. Nesse contexto, a expressão “aprendizagem ativa”, ou
“métodos ativos de aprendizagem”, tem recebido atenção especial por parte do corpo docente.
Com o avanço da tecnologia, as pessoas têm aprendido mais rápido. A informação é instantânea
e condensada em nuvens globais, sendo assim, o professor precisa estar atento para constituir
respostas possíveis às novas demandas educacionais.
Para os que atuam na área, a educação conteudista ou expositiva tradicional, também
pode ser considerada ativa pois não deixa de ser atividade executada por estudantes, associam-se,
naturalmente, a estas tendências, dúvidas e questionamentos sobre o real significado da expressão
sendo incorporados nos trabalhos, avaliações, exercícios e laboratórios.(BARBOSA; MOURA,
2013).
De acordo com McGrew, Saul e Teague (2000) neste modelo, o professor tem o papel de
mediador do processo de ensino-aprendizagem e tem que atuar como um facilitador antenado
na formação cognitiva e construtiva do conhecimento do seu corpo discente. O docente é um
gerenciador de ambientes e ferramentas de aprendizagem contextualizada, seja por situação
de aprendizagem, estudos de casos, situações problemas e deve ser desprendido do modelo
conteudista avançando para uma aprendizagem independente, colaborativa e transformadora.
Por sua vez, o aluno deve estar aberto às novas perspectivas de ensino caracterizadas pela
realidade virtual, internet das coisas, escola invertida, hibridismo no ensino e as simulações dos
processos através de softwares, que tendem a diminuir a distância do real para o educacional. Em
outros termos, essa metodologia de ensino tem como cerne o desenvolvimento das habilidades
e das competências técnicas, atitudinais, procedimentais e sociais dos discentes, oferecendo
estruturas para um desenvolvimento das inteligência coletivas em níveis mais avançados, como
análise, síntese e criação. (ANDERSON; BLOOM et al., 2001).
No artigo de Albuquerque et al. (2019) o parque industrial tem sofrido mudanças signifi-
cativas em sua estrutura funcional devido à inserção da indústria 4.0, algoritmos e automação,
por meio do Aprendizado de Máquina (AM), tornando-se cada vez mais comuns em ambientes
competitivos entre empresas, para aumentar a produção e reduzir os custos.
No XI simpósio de excelência em gestão e tecnologia foi produzido um artigo sobre
comissionamento virtual, segundo Cruz et al. (2014) a integração entre o mecanismo virtual
Capítulo 1. Introdução 15

com um Controlador Lógico Programável (CLP) acontece por meio de protocolos industriais
de comunicação, que podem ser MODBUS, PROFIBUS, PROFINET, ASI, Ethernet TCP/IP,
CAN, DeviceNet, dentre estes, existe um muito difundido por ser de padrão aberto, que é OLE
for Process Control” (OPC), onde OLE significa “Object Linking and Embedding” baseado em
uma estrutura cliente servidor, que foi o protocolo escolhido para este trabalho.
Quando se fala em integrar sistemas estamos em outra esfera de análise. Os processos de
automação são hierarquizados e subdivididos em níveis, com suas regras e protocolos específicos
aos quais podemos citar as de níveis de campo, controle e supervisão, atuando em cada um dos
segmentos que são conhecidos como pirâmide da automação.

1.1 Importância do trabalho

Em 2019, iniciou-se o curso técnico em mecatrônica, no SENAI, a distância, e foi


utilizada a estratégia de ensino com o uso dos simuladores e a integração entre eles. Essa
experiência pedagógica de que é possível aprender a programar sistemas através de simulação
foi uma grande motivação para este trabalho.
Durante este período, era necessária a utilização de equipamentos que simulavam situ-
ações práticas, seja um inversor, CLP, Interface Homem Máquina (IHM), servo motor, dentre
outros. Então como treinar para não esquecer o que foi aprendido, sem os equipamentos físicos?
Este questionamento também foi um motivador para a execução deste estudo.
Segundo o artigo de Silva et al. (2020), o pesquisador aplicou os processos de controle de
nível, onde fez a simulação de uma planta didática estudando o comportamento das diversas téc-
nicas de controle, uma das disciplinas mais desafiadoras do Bacharel em Engenharia. Fez uso de
gráficos com o MATLAB®, modelando todo o sistema, conseguindo assim unir os conhecimentos
das disciplinas de sistemas de controle e automação industrial em uma atividade experimental.
Isso permitiu um melhor aprendizado pessoal, pois a interdisciplinaridade apresentou uma visão
de totalidade sobre o conhecimento estudado, mostrando onde ele poderia atuar.
Nesse contexto, entra a importância dos simuladores para o ensino acadêmico aliado às
tecnologias de virtualização, que estão se mostrando aditivos importantes para o chão de fábrica
e para o ambiente educacional, ao permitirem a criação de cópias fieis dos sistemas integrados
de manufatura, ou simplesmente um sistema automatizado menos complexo, possibilitando
analisar e testar configurações de maquinário, sistemas, plantas e medir os resultados antes de
implementar qualquer alteração no ambiente real. (CARDOSO, 2016).

1.2 Revisão da literatura

De acordo com (VILLAS-BOAS; NETO, 2011) que analisou a integração entre um


software de Simulação a Eventos Discretos (SED) o URURAU® e outro de simulação dinâmica
usando o CAD 3D Inventor®, percebeu a comunicação de alto nível entre eles. Além dessa parte
de modelagem, foi usado o CLP da Siemens S7 1200® e o FluidSIM®, comunicando tudo via
OPC. Na ocasião foi concluído que a utilização de softwares para comissionamento de sistemas
controlados seria uma alternativa iminentemente viável. Sendo assim, pôde-se afirmar que foi
possível comissionar uma linha de produção antes de implementar a planta física, modelando o
sistema com o Software URURAU® e usando os conceitos de integração.
Outro trabalho importante na linha de simuladores, podemos citar McGregor (2002),
onde trabalhou-se os leiautes físicos e os limites operacionais que poderiam ser auxiliados de
acordo com os resultados das simulações. Ainda sobre simuladores, de acordo com Sakurada
Capítulo 1. Introdução 16

e Miyake (2009), novos sistemas podem ser criados e avaliados, bem como sistemas que já
existem podem ser totalmente modificados, por meio de ferramentas como os simuladores.
Nos últimos dez anos, foram registrados trabalhos de avanços significativos usando os
simuladores e já projeta-se melhorias para a próxima década, afirma Cheng et al. (2016). Dentre
as áreas impactadas por este processo podemos citar a saúde, serviços públicos, economia,
transporte, meio ambiente, indústria alimentícia, entre outras. Os robôs humanoides são avanços
também nesta área de simulação, assim como os colaborativos têm sustentado uma reviravolta
em sistemas de repetibilidade, paletização e etc. O desenvolvimento de multiplataformas, usadas
em longa escala pela internet, construção de modelos utilizando os conceitos de modelagem,
incorporando ferramentas de sistemas dinâmicos, são tendências.
Na mesma linha de pensamento foi desenvolvida uma abordagem prática sobre a comuni-
cação OPC, no VI Seminário de Automação de Processos na Associação Brasileira de Metalurgia
e Materiais. O artigo de Fonseca (2002) permitiu demonstrar que os sistemas de automação e os
equipamentos de chão de fábrica já poderiam se beneficiar do padrão OPC. Usou-se como teste
a plataforma WINTEL®, desenvolvida pela Microsoft. O trabalho descreveu o padrão OPC, sob
o ponto de vista prático e foi importante para entender como o protocolo funciona e apresentou
orientações para utilização de seus recursos e a gama de possibilidade de uso do mesmo.

1.3 Motivação e problemática

Atualmente está em voga o uso do retrofit que é uma espécie de melhoria de instalações
antigas que busca atualizar o processo, ou pela substituição total desses sistemas antigos por
maquinários mais modernos e confiáveis ligados ao controle e automação. Essas atualizações
esboçam enormes vantagens como a monitoração de falhas ou detecção das mesmas antes que
ocorram controle e monitoramento do processo.
O Instituto Federal do Ceará (IFCE) possui vários laboratórios ligados à automação e
controle de processos e estes precisam acompanhar a evolução da indústria. Cada ambiente
possui kits didáticos específicos, a maioria deles muito caros e de manutenção elevada, o que
além de aumentar o custo da oferta, torna mais difícil a replicação destes espaços.
Por isso, a necessidade de simulação desses equipamentos levou vários fabricantes a
apostarem no desenvolvimento de softwares específicos para cada área, onde podemos citar o
Proteus® para a eletrônica, o CadeSIMU® para comandos elétricos, o EPLAN® para projetos
elétricos, o FluidSIM® para pneumática, eletropneumática e hidráulica, o Elipse SCADA® ou
Elipse E3® para sistemas supervisórios, o VIJEO® para IHM, o CODESYS®, TIA Portal®,
Somachine®, LogixPro®, dentre outros vários para programação de CLP, Factory IO® e Auto-
mation Studio® para simulação de processos integrados de manufatura, o Autocad®, a lista é
interminável.
Capítulo 1. Introdução 17

Um dos softwares citados acima e largamente usado na manipulação de circuitos que


envolvam automações pneumáticas e afins é o software FluidSIM® da fabricante FESTO de
componentes pneumáticos e hidráulicos que ajuda principalmente na elaboração de circuitos
sequenciais utilizando vários métodos de construção.
O software pode reforçar os conhecimentos em automação de manipulação pneumática
e assim atender às expectativas exigidas pelo mercado de trabalho. Os módulos que envolvem
as automações eletropneumáticas são largamente utilizados em diferentes áreas, tais como:
indústria têxtil, farmacêutica, alimentícia, agricultura, exploração madeireira, produção de
energia, automotivo, naval, plástico, vestuário e etc. por isso, seu domínio é muito importante
para a área de automação.

1.4 Objetivos

A seguir serão apresentados o objetivo geral e os específicos deste trabalho.

1.4.1 Objetivo Geral


Relizar a implementação de três softwares Elipse SCADA®, Fluidsim® e CodeSys®
onde será configurado o CLP na linguagem Ladder tendo como integrador o protocolo OPC, que
será responsável pela comunicação entre os mesmos. A ideia é facilitar para o corpo docente e
discente a utilização da integração de softwares de automação para poder desenvolver técnicas de
programação e comunicação entre os mesmos, utilizando um protocolo aberto de comunicação.

1.4.2 Objetivos Específicos

1. Facilitar o aprendizado em programação para alunos da graduação ou ensino técnico com


a utilização de softwares simuladores e integrativos;

2. Apresentar o método de maximização de contatos da eletropneumática como base para a


conversão na linguagem Ladder.

3. Determinar o protocolo de comunicação OPC entre o cliente e o servidor.

4. Possibilidade de comunicar-se com um supervisório.

1.5 Contribuições do trabalho

Este trabalho traz como contribuição principal a comunicação de três softwares diferentes
o Elipse SCADA® que fará o supervisório do sistema, o Fluidsim® que será responsável pela
manipulação eletropneumática e a plataforma CodeSys® onde será configurado o CLP virtual,
usando a linguagem Ladder. A comunicação se dará pelo protocolo OPC que será responsável
pela interconexão dos mesmos. Os simuladores são importantes na automação e integrá-los de
maneira simples e produtiva pode ser uma ferramenta útil na aprendizagem. A virtualização
é uma tendência, a simulação de sistemas uma necessidade e a integração comunicativa entre
softwares uma realidade.
Capítulo 1. Introdução 18

1.6 Organização do trabalho

O escopo deste trabalho está organizado em capítulos, os quais apresentam uma sequência
que mostra o passo a passo de como configurar o protocolo OPC nos softwares escolhidos para o
sistema.
No Capítulo 2 será apresentada a fundamentação teórica dos conceitos mais importantes
da automação industrial e a importância dos simuladores, onde apresentaremos os softwares
Fluidsim ®, CodeSys® e Elipse SCADA ®.
No Capítulo 3 será demonstrada a metodologia do trabalho. Como fazer com que esses
softwares se comuniquem, através do protocolo OPC.
O Capítulo 4 mostrará os resultados e as discussões sobre o trabalho. Este está dividido
em tópicos e mostrará o resultado da tela final de cada software.
No Capítulo 5 será feita a conclusão do trabalho e serão elencadas as sugestões para
trabalhos futuros.
19

2 FUNDAMENTAÇÃO TEÓRICA

Nesta seção serão abordados os principais conceitos da automação industrial, a impor-


tância dos simuladores, o software Fluidsim ® da Festo, a plataforma CodeSys ®, o sistema
supervisório Elipse SCADA ®, os sistemas eletropneumáticos, o protocolo OPC e o desafio
proposto da integração destes softwares.

2.1 Automação Industrial

Automação é a substituição do trabalho humano ou animal por máquinas. Um sistema


para ser considerado automático deve ter a mínima interferência do operador humano. Automação
é o controle de processos automáticos. Automático significa ter um mecanismo de atuação
próprio, que faça uma ação requerida em tempo determinado ou em resposta a certas condições.
(RIBEIRO, 1999).
O termo “automação” dá notoriedade à ação da tecnologia, mais precisamente às lingua-
gens de programação para a automatização do controle do processo produtivo. Podemos então
resumir, a palavra automação como sendo:

"Qualquer sistema, apoiado em computadores, que substitui o trabalho humano, em


favor da segurança das pessoas, da qualidade dos produtos, rapidez da produção ou
da redução de custos, assim aperfeiçoando os complexos objetivos das indústrias, dos
serviços ou bem estar."(MORAES; CASTRUCCI, 2010).

Conforme Martins (2012), a automação foi pensada para ser difundida nas mais distintas
atividades humanas. Podemos citar um braço importante dessa vertente, a domótica, que é a
automação residencial, como exemplo, casas inteligentes, que possuem sistemas de alarmes,
luminárias, som, abertura de garagem, controle de temperatura, todos controlados por inteligência
artificial ou por um microcontrolador, como o ESP32 que se comunica com a internet. Mas
não podemos esquecer que a automação está presente no nosso dia a dia, desde controle de
acesso, bancos, supermercados, hospitais, transporte, aplicativos, assim por diante. Tudo isso
foi desenvolvido para facilitar a vida do ser humano, visando a gestão do tempo, promovendo
eficácia, eficiência e acima de tudo segurança.
Em seu livro Engenharia de Automação Industrial (MORAES; CASTRUCCI, 2010)
citam que existem muitas funções que precisam ser subdividas na automação, para isso foi criado
uma espécie de modelo hierárquico representado na Figura 1 que é conhecida como Pirâmide
da Automação, dividida em níveis, com equipamentos e protocolos específicos de cada camada.
Na base da pirâmide estão os dispositivos de campo (sensores, atuadores); no nível 2 está a
camada de controle, onde fica o CLP; no nível 3 temos os sistemas de supervisão. No topo da
pirâmide destaca-se o gerenciamento corporativo que receberá os dados da produção em forma
de planilhas, acessos remotos, WEB ou Intranet.
Capítulo 2. Fundamentação teórica 20

Figura 1 – Pirâmide de Automação.

Fonte: Oliveira (2012).

Em resumo o nível 1 é chamado de nível dos dispositivos, máquinas e componentes,


trata-se do chão de fábrica. O nível 2 abrange os controladores automáticos centralizados ou não
das atividades da planta. O nível 3 permite a supervisão do processo produtivo, geralmente é
constituído pelo banco de dados, onde guardam estatísticas do processo, indicadores de qualidade,
algorítimos de otimização. Já o nível 4 responde pela programação e planejamento da produção
e realiza o controle da cadeia de suprimento. O nível 5 é responsável pela administração dos
recursos da empresa, onde estabelece-se o gerenciamento corporativo, nesta área abrangem os
softwares para gestão de vendas, fazendo ponte direta com o sistema financeiro.
Segundo Alves (2004) a automação é modo pelo qual consegue-se alcançar melhores
índices de qualidade. Não podemos definir qualidade apenas no controle final do processo
produtivo, a qualidade é adquirida durante todas as fases, através de um minucioso controle
dimensional das grandezas envolvidas. Dessa maneira, a automação faz com que se aumente os
índices de qualidade do processo.
Ainda de acordo com Alves (2004) cada sistema de automação compõe-se de cinco
elementos que são os seguintes:

1. Acionamento: são equipamentos que fornecem o sistema de energia para alcançar deter-
minado objetivo. Podemos ter como exemplo os motores elétricos, pistões pneumáticos ou
hidráulicos;

2. Sensoriamento: responsável por garantir o monitoramento das máquinas. É a técnica de


obtenção de informações acerca de um objeto. Exemplos: Ultrassônicos para a medição
de nível, termopares para medição de temperatura e pressostatos para medição de pressão.
Capítulo 2. Fundamentação teórica 21

3. Controle: regula os acionamentos por meio das informações repassadas pelos sensores,
Por exemplo, para manter o nível de água num reservatório, usa-se um controlador de
vazão que permite ou não a passagem do fluido por meio de uma válvula borboleta. Até
mesmo um robô possui um controlador para movimentar seus servos, afim de garantir sua
área de trabalho.

4. Comparador ou elemento de decisão: sistema que toma decisões para atuar no sistema,
tendo como base a comparação de valores medidos com os estabelecidos. Temos como
exemplo, os termostatos que são destinado a manter constante a temperatura de um
determinado sistema, através de sua regulação automática, pode ter sua decisão de ação
manipulada pelos controladores.

5. Programas: além de possuir as informações do processo são eles que estabelecem as


interface de comunicação com os demais componentes.

Ainda segundo o autor, ele frisa que a automação é capaz de fixar o homem no centro
da produção industrial. Nesta condição precisa cada vez mais capacitar-se e especializar-se,
buscando competência para realizar as suas atividades. Os processos estão cada vez mais
automatizados e qualificar-se é condição necessária para manter-se ativo nessa nova revolução
tecnológica.

2.2 Os Simuladores

O uso assertivo da tecnologia sempre será a melhor solução para a minoração de proble-
mas, erros, falhas de operação e acidentes industriais, por outro lado, também será responsável
pela potencialização do lucro, da produção e melhor especificação dos itens produtivos.

"A simulação pode ser definida como uma representação operacional de características
centrais da realidade. Esta definição novamente identifica duas características centrais
que devem ambas existir antes, para qualificar como uma simulação. Primeiro, ele
deve representar uma situação real de alguma ordem – seja uma situação extraída
diretamente da vida real ou uma situação imaginária que possivelmente poderia ser
tirada da vida real (por exemplo, a invasão por seres extraterrestres). Segundo, deve ser
operacional ou, em outras palavras, deve constituir um processo contínuo - esse critério
exclui a simulação efetivamente da classe de outras representações análogas e estáticas,
como fotografias, mapas, gráficos e diagramas de circuitos, mas inclui modelos de
trabalho. de todos os tipos."(ELLINGTON; ADDINALL; PERCIVAL, 1982).

Um simulador pode ser um software, uma máquina ou um game, que seja capaz de
reproduzir o comportamento e a modelagem de um sistema sob diversas condições, facilitando
assim o aprendizado para que se possa trabalhar com isso, praticando com os simuladores. Estes
costumam combinar partes mecânicas com eletrônicas junto com partes virtuais que ajudam a
simular a realidade no plano virtual.
De acordo com Reis (2017) o uso de simuladores para treinamento operacionais vem
crescendo a cada dia. Ainda na mesma linha, Santoni et al. (2007), afirma que os simulado-
res esboçam um papel singular uma vez que podem recompor uma variedade de condições
operacionais, para que o operador possa executar especificada tarefa.
Capítulo 2. Fundamentação teórica 22

Partindo-se do pressuposto que os simuladores relacionam-se aos fenômenos ou sistemas


do mundo real representados, Lunce (2006) propõe uma seriação que envolve quatro faces dos
simuladores: físicas, iterativas, processuais e situacionais, conforme se apresentam a seguir:

• as simulações físicas em um cenário aberto um aluno-usuário pode manipular variáveis e


observar os resultados;

• as simulações iterativas fazem com que o aluno deva repetidamente conduzir a simulação
alterando variáveis com cada interação para testar a hipótese, ele vai conduzir pesquisas
científicas, construir e testar hipóteses e observar os resultados;

• as simulações processuais aproximam o aluno do real, onde ele pode manipular objetos
simulados com objetivo de adquirir habilidades, seja motoras ou cognitivas, requeridas
caso estivesse operando no mundo real;

• as simulações situacionais lembram muito as dinâmicas de grupo, ou treinos para interpre-


tação teatral, onde é modelado o comportamento humano, tendo em foco a resposta das
atitudes individuais e coletivas que eles despertem para situações inusitadas que muitas
vezes eles precisam dar respostas rápidas para problemas complexos. Simulações situacio-
nais tendem a ser um dos mais difíceis tipos de simulação a serem projetados e eficazmente
utilizados.

Desenvolver metodologias de avaliação de desempenho de alunos que utilizam simulado-


res educacionais embarcados em ambientes virtuais de aprendizagem para o ensino da engenharia
é um grande desafio. Precisa haver um elo entre o que se está manipulando com as capacidade
sociais e técnicas que estão sendo desenvolvidas, junto com o ambiente real, que possuem outras
variáveis e muitas vezes o tempo não é uma delas.
O SENAI possui a sua própria metodologia de ensino baseado em competências e sua
forma avaliativa baseada em situações de aprendizagem. Então o que já era aplicado nos moldes
dos cursos presenciais foram sendo modelados e dando espaço aos softwares e equipamentos
simuladores para o uso na Educação a Distância (EAD), sem prejuízo de competências ou
esquecimento de capacidades. (ARRUDA; MATOS, 2012).
A Figura 2 mostra um simulador cuja fonte linear de alimentação é utilizada no quadro
de comando de controle dos sensores, porém sofreu um problema e teve seus componentes
danificados. O aluno precisa ler o documento técnico da fonte fornecido pelo simulador, ver
no almoxarifado se há os componentes específicos, dimensioná-los de acordo com o esquema
elétrico da fonte, fazer as medições, testar e produzir um relatório técnico. O próprio simulador
tem seus algorítimos de cálculos e a nota é gerada automaticamente após o envio do relatório.
Capítulo 2. Fundamentação teórica 23

Figura 2 – Simulador da fonte do quadro de comando do tanque de cozimento.

Fonte: Próprio Autor (2021).

2.3 O Software FluidSIM®

Segundo manual do fabricante FESTO (2004) o FluidSIM® foi lançado no departamento


de sistemas baseados em conhecimentos da universidade Alemã de Paderborn. O conceito
e o desenvolvimento do FluidSIM® Pneumática estão baseados em pesquisas realizadas por
Dr. Daniel Curatolo, Dr. Marcus Hoffmann e Dr. habil. Benno Stein. Esse software é uma
ferramenta didática que simula conhecimentos de pneumática e eletropneumática usando o
sistema Microsoft Windows®.
Uma peculiaridade importante do FluidSIM® é a combinação da funcionalidade do CAD
com a simulação. O FluidSIM® está programado com base na norma ABNT NBR 8896:1985 de
símbolos gráficos para sistemas e componentes hidráulicos e pneumáticos.
A parte do CAD no FluidSIM® foi elaborada pensando no conhecimento sobre técnica de
fluidos. Por exemplo, ao criar o desenho dos diagramas, o software analisa se algumas conexões
entre os elementos são permitidas. Outro atributo do FluidSIM® e talvez a mais importante seja
a sua extraordinária análise didática: com este software é possível visualizar, desenhar, aprender
e ensinar os conhecimentos pneumáticos.
Os componentes pneumáticos, desde válvulas, atuadores, elementos de sinais, são es-
miuçados através de descrições, figuras reais dos componentes e animações que mostram os
princípios de operação aos quais se referem; foram elaborados também exercícios de apoio
e filmes didáticos para ajudarem na disseminação do conhecimento não só sobre os circuitos
mais difundidos, mas também sobre o uso de componentes pneumáticos. Assim, o FluidSIM®
torna-se perfeito para usar em aulas ou como programa de estudo.
O software FluidSIM® foi desenvolvido de forma especial para ser o mais intuitivo
e amigável possível. O aluno desenvolverá habilidades de desenhar e simular diagramas de
circuitos eletropneumáticos rapidamente, o que é um desafio enorme quando se está aprendendo
sobre as mais diversas técnicas de elaboração de circuitos.
De acordo com Heck, Souza e Mantovani (2016) é indispensável no desenvolvimento
de projetos, que se faça o uso da simulação e da visualização do funcionamento dos circuitos
Capítulo 2. Fundamentação teórica 24

eletropneumáticos e o FluidSIM® é uma aplicação completa, pensada para a criação, simulação,


instrução e estudo da Eletropneumática, Eletrohidráulica e circuitos digitais.
A Figura 3 traz uma aplicação com dois atuadores e uma ventosa, sendo controlados pela
modulo virtual de CLP que o sistema disponibiliza. Também mostra a figura do atuador linear e
das válvulas de comando 5/2 duplo piloto e duplo solenoide que está interligada ao atuador de
giro limitado. O circuito é meramente ilustrativo e não tem haver com a aplicação desenvolvida
neste trabalho.
Figura 3 – Simulador FluidSIM da Festo.

Fonte: Próprio Autor (2021).

2.4 A plataforma CodeSys®

Segundo Souza e Pereira (2015), o CodeSys® é uma plataforma de software desenvolvida


especificamente para atender às diferentes necessidades dos modernos projetos de automação
industrial. O termo CodeSys® é uma abreviatura de Controller Development System e significa
Sistema de Desenvolvimento de Controladores.
O software é desenvolvido pela empresa alemã de software 3S-Smart Software Solu-
tions®, e segue a norma IEC 61131-3, norma da International Electrotechnical Commission
(IEC), utilizando o padrão de linguagens de programação para hardwares de controle. IEC é
uma organização internacional de padronização elétrica, eletrônica e técnica relacionada. Alguns
de seus padrões foram desenvolvidos em conjunto com a International Organization for Stan-
dardization (ISO). Quando o primeiro CLP começou a funcionar nas décadas de 1960 e 1970,
começou a buscar a padronização das linguagens de programação.
O CLP para Prudente (2000) “é um computador que realiza controle em vários níveis
de complexidade, seu aspecto interessante é que ele pode ser usado e programado por qualquer
pessoa sem muito conhecimento no uso do computador”. Foi só na década de 1990 que a então
IEC1131-3 estabeleceu cinco linguagens de programação principais, que foram posteriormente
Capítulo 2. Fundamentação teórica 25

renumeradas e denominadas IEC 61131-3. O que poucas pessoas sabem é que o padrão IEC
61131-3 é na verdade apenas um capítulo do grupo de padrões IEC 61131, que cobre apenas
CLP.
Em seu trabalho de Mestrado sobre um controlador lógico programável baseado no
CodeSys®, Silva (2017) afirma que os criadores da plataforma garantem aos potenciais clientes
que seu software está de acordo com a Parte 3 das linguagens de programação da norma. Qualquer
uma das cinco linguagens que fazem parte da mesma, podem ser usadas pelo programador para
que desenvolva seu projeto ou até mesmo utilizar várias linguagens ao mesmo tempo, no mesmo
programa funcionando em runtime.
As cinco linguagens são:

• Structured Text (ST) - Semelhante ao Pascal e ao C

• Instruction List (IL) - Parecido com a linguagem Assembly

• Ladder (LD) - A combinação de relés e bobines

• Function Block Diagram (FBD) - Blocos de funções com entradas e saídas

• Sequential Function Chart (SFC) - Linguagem semelhante ao Grafcet

Também é importante frisar de acordo com Silva (2017) que os técnicos de automação
não precisam de licença para usar o CodeSys®, portanto, não há custo para o usuário. Sabemos
que mais de 400 fabricantes e dezenas de milhares de usuários finais adotaram o CodeSys®.
Mitsubishi, BECKHOFF, ABB, Schneider, SEW, Bosch, Festo ou Turck e outras marcas usam
esta solução em seu portfólio de produtos. É por isso que a plataforma CodeSys® é uma das
principais ferramentas de programação IEC 61131-3, independente do fabricante.
O software pode compilar programas e realizar testes virtuais neles, eliminando assim o
problema de usar CLP na fase de teste. Pode-se monitorar as variáveis do processo a qualquer
momento, para que se possa criar uma interface homem máquina e interagir com o sistema.
Embora o software de desenvolvimento seja parte da solução do 3S-Smart Software Solutions®
que os técnicos usam para desenvolver seus aplicativos, ele é gratuito para os usuários, mas para
aqueles que usam a CodeSys® para desenvolver, fabricar e vender dispositivos compatíveis, isso
não é viável, neste caso, para cada dispositivo vendido no mercado, você deve continuar a usar a
solução de software 3S-Smart ® para licenciamento. Portanto, o fabricante terá que arcar com o
custo do sistema que a 33S-Smart Software Solutions® chama de CoDeSys Run Time System
(CodeSys RTS) (SILVA, 2017).
O CodeSys® exige que os fabricantes de equipamentos forneçam produtos com os
chamados pacotes de suporte de destino. Ao instalar este pacote de driver, pode-se acessar
dispositivos de diferentes fornecedores na ferramenta de programação. Em tempo de execução,
o código de controle CodeSys® é executado com o suporte do sistema de tempo de execução
CodeSys® padrão no dispositivo.
A Festo fornece a versão 2.3.9.42 usada neste trabalho, que contém pacotes de suporte
de destino para os modelos CPX-CEC ® e CPX-CEC-C1®. Esta versão está em conformidade
com a configuração, depuração e programação do controlador usando o software CodeSys® ,
que pode ser baixado do site do fabricante.
A Figura 4 mostra a plataforma CodeSys® da Integrated Development Environment (IDE).
Esta é a tela de programação onde a linguagem selecionada é o diagrama Ladder, neste ambiente
Capítulo 2. Fundamentação teórica 26

desenvolvemos todos os códigos, primeiro declaramos as variáveis, e depois programamos de


acordo com a aplicação.

Figura 4 – Plataforma 3S CodeSys SP PLCWinNT Festo.

Fonte: Próprio Autor (2021).

Já na Figura 5 consegue-se detalhar melhor a IDE que é composta de seções. Cada parte
tem sua função e está discriminada abaixo, segundo a fabricante EATON (2012).

Figura 5 – Detalhamento da IDE CodeSys.

Fonte: EATON (2012)


Capítulo 2. Fundamentação teórica 27

• ORGANIZADOR - é usado para gerenciar os novos itens de cada pasta. Através dele
inserimos novos elementos nas pastas localizadas abaixo e solicitamos a visualização
/edição de alguns itens.
• ORGANIZADOR / PROGRAMAS – Nesta pasta alocamos os programas do CLP, bem
como suas funções e seus blocos de função. É o lugar onde fica a POU Program Organiza-
tion Units. Uma POU é um objeto de um tipo e linguagem especificados, que abriga o
código que é chamado por uma Tarefa ou outra POU.
• ORGANIZADOR / TIPOS DE DADOS – Aqui nós colocamos nossos tipos de dados
, Structures, Enumeration, etc. São tipos de dados criados pelo usuário conforme a IEC
61131-3.
• ORGANIZADOR / VISUALIZADOR – Dentre os recursos oferecidos pelo CodeSys®,
está a criação de telas para visualização do programa criado, tanto online como off-line
(modo simulação), estas telas são criadas e gerenciadas nesta pasta.
• ORGANIZADOR / RECURSOS – Pasta responsável por vários itens no CodeSys®. En-
tre eles: configuração de hardware, configuração do sistema da CPU, criação de variáveis
de rede, geração de gráficos de tendência, criação de tabelas de monitoração etc.
• ÁREA DE TRABALHO – Quando selecionamos ou criamos algo em qualquer pasta do
organizador, este item aparece na área de trabalho para edição ou visualização.
• BARRA DE FERRAMENTAS – Aqui ficam algumas ferramentas para acesso mais
rápido a algumas funções do programa, esta barra muda conforme o item selecionado na
Área de Trabalho.

2.5 O Sistema SCADA

Segundo MORAES e CASTRUCCI (2007), O sistema de monitoramento supervisório


é um sistema digital de análise e processamento de equipamentos para gerenciar variáveis de
processo. Pode-se atualizar para consultas históricas e armazená-los em um banco de dados
local ou remoto. Esses dispositivos são amplamente utilizados na indústria, o sistema de
monitoramento de exibição especialmente desenvolvido para a planta em questão, controla e
monitora os atuadores (pneumáticos, elétricos, hidráulicos) e gera relatórios, exibe avisos e
comandos, interrompe circuitos de emergência ou Iniciar ou reinicie processos. A Figura 6
mostra um exemplo de um sistema de monitoramento de rastreamento.
De acordo com Silva e Salvador (2005) dependendo do seu sistema de monitoramento
e rastreamento, pode-se rastrear e monitorar informações em tempo real durante a produção
ou instalação. Essas informações são coletadas, manipuladas, analisadas, armazenadas e dispo-
nibilizadas aos usuários por meio de dispositivos de coleta de dados. Esses sistemas, também
conhecidos como SCADA (Supervisory Control and Data Acquisition), que significa Controle
de Supervisão e Aquisição de Dados.
Hoje os sistemas de automação industrial usam computadores e tecnologias de comu-
nicação para automatizar o monitoramento e controle de processos industriais, coletar dados
em ambientes complexos e, por fim, analisar os dados. O sistema SCADA identifica os pontos
de supervisão que são qualquer variável ou número presente na aplicação e executa funções de
cálculo (matemática, operações lógicas) que podem também representar pontos de dados de
entrada e saída em um processo controlado, neste caso, corresponde às quantidades reais do
processo (temperatura, nível, vazão e etc.) e servem como um elo entre o controlador e o sistema.
Capítulo 2. Fundamentação teórica 28

Figura 6 – Diagrama de blocos dos níveis l, 2 e 3 da pirâmide de automação.

Fonte: MORAES e CASTRUCCI (2007)

Os sistemas supervisórios usam tags que são variáveis alfanuméricas associadas a um apli-
cativo que pode realizar funções computacionais (como matemática, lógica, vetores ou strings).
O processo é controlado e supervisionado, neste caso, as tags correspondem às quantidades reais
do processo, temperatura, nível, fluxo, etc.
Os sistemas SCADA também podem verificar as condições de alarmes definidas quando
os valores de sinalização estiverem fora do intervalo ou condições predefinidas, podem armazenar
registros em um banco de dados, disparar sons, mensagens, alterar cores de mudança e muito
mais. Os componentes físicos do sistema de monitoramento são: Sensores e atuadores.
Um sensor é um dispositivo conectado a um equipamento controlado e monitorado
por um sistema SCADA que converte parâmetros físicos como velocidade, nível de água e
temperatura em sinais analógicos e digitais, podendo ser lidos por uma estação remota, já os
atuadores são usados no sistema para indicar ações e movimentações do sistema.
A Figura 7 mostra o sistema de monitoramento e controle. A estação central de monito-
ramento é o principal dispositivo do sistema SCADA, coleta as informações geradas a partir da
estação remota e age contra ela. As informações coletadas podem ser centralizadas em um único
computador ou distribuídas em uma rede de computadores para que possam ser compartilhadas.
Capítulo 2. Fundamentação teórica 29

Figura 7 – Sistema de supervisão e controle.

Fonte: Knowledgebase (2019)

Segundo o site do fabricante Elipse® no site Knowledgebase (2019) informa que os


sistemas SCADA a maior parte das vezes dividem suas atividades mais importantes em blocos
ou módulos, isso oferece flexibilidade e robustez com base na solução de que você precisa. Em
geral, essas tarefas podem ser divididas da seguinte forma:

• Núcleo de processamento;
• Comunicação com PLCs/RTUs;
• Gerenciamento de Alarmes;
• Históricos e Banco de Dados;
• Lógicas de programação interna (Scripts) ou controle;
• Interface gráfica;
• Relatórios;
• Comunicação com outras estações SCADA;
• Comunicação com Sistemas Externos / Corporativos;
• Outros.

A regra geral para que um sistema SCADA funcione é que ele comunique-se com um
dispositivo, essa informação deve ser transmitida para o núcleo principal do software. O Núcleo
é responsável por distribuir e coordenar esse fluxo de informações para os demais módulos. Ele
relata anomalias visualizando o status do dispositivo e o progresso dos processos controlados
(normalmente gráficos, animações, relatórios e etc.) automaticamente.
A tecnologia de computador usada para desenvolver sistemas SCADA avançou sig-
nificativamente nos últimos anos para melhorar ainda mais a confiabilidade, flexibilidade e
Capítulo 2. Fundamentação teórica 30

conectividade. Também inclui novas ferramentas que reduzem o tempo que você gasta configu-
rando e ajustando seu sistema que sempre será adaptado às necessidades de cada instalação.
O software escolhido para realizar a função de supervisão deste trabalho foi o Elipse
SCADA®. A Figura 8 mostra a tela principal de programação deste software. O Elipse SCADA®
combina alto desempenho e flexibilidade representados por múltiplos recursos que facilitam
e aceleram o desenvolvimento de aplicações. É totalmente configurável e permite monitorar
variáveis em tempo real por meio de gráficos e objetos conectados a variáveis físicas em campo.
Ele também pode acionar, enviar e receber informações com dispositivos de coleta de dados. O
software usa uma linguagem de programação exclusiva, o Elipse Basic pode automatizar várias
tarefas para atender às necessidades específicas de qualquer negócio. (ELIPSE, 2004).

Figura 8 – Tela principal do Elipse SCADA.

Fonte: Próprio Autor (2021).


Capítulo 2. Fundamentação teórica 31

2.6 Os Sistemas Eletropneumáticos

De acordo com Bonacorso e Noll (2000) cada vez mais combinações de várias formas de
energia estão sendo observadas nos processos industriais. A prática ensinou que o conhecimento
de hidráulica, pneumática, eletricidade, eletrônica e suas combinações são tão importantes e
necessárias na automação. Portanto, não consideramos o conhecimento mais importante do que
outros conhecimentos e sempre nos esforçamos para integrá-lo a uma determinada aplicação,
levando em consideração a tecnologia, a economia essencial com a sociedade.
Fialho (2018) define eletropneumática como:

“Eletropneumática é o ramo da pneumática que passa a utilizar a energia elétrica CC ou


CA como fonte de energia para o acionamento de válvulas direcionais, compondo as
.
assim as chamadas eletroválvulas e válvulas proporcionais, energizando ainda sensores
magnéticos de posicionamento, pressostatos, micro-switchs, etc.” (FIALHO, 2018)

Estamos discutindo principalmente processos industriais que usam uma combinação de


energia do ar e energia elétrica. Isso é chamado de automação eletropneumática. Um sistema
eletropneumático automatizado, conforme mostra a Figura 9, é composto pelas seguintes partes:
elementos de sinal, elementos de trabalho, elementos de comando e elementos de controle.

Figura 9 – Diagrama de um Sistema Eletropneumático automatizado.

Fonte: Vasconcelos et al. (2015)

De acordo com Bonacorso e Noll (2000) de um plano de projeto de automação, extrai-se


a sequência de tarefas do item de trabalho, ou seja, um diagrama mostrando onde cada item
de trabalho está localizado em uma etapa do processo automatizado gerando um circuito. Um
circuito eletropneumático é construído a partir dessa sequência de operações.
Capítulo 2. Fundamentação teórica 32

2.6.1 Elementos de Comando


Os elementos de comando são válvulas pneumáticas (esse termo será usado, porque
trata-se da ciência de movimentação do fluido, mas estamos tratando da eletropneumática, e todo
o estudo será nessa função) que trabalham na operação de comandar os elementos de trabalho,
geralmente são as válvulas direcionas de simples e dupla solenoide. A Figura 10 traz um desenho
em corte de uma válvula direcional 5/2 vias com duplo solenoide. A imagem mostra a vista
interna desse componente.

Figura 10 – Vista em corte de uma válvula duplo solenoide.

Fonte: Ferraz (2015)

2.6.2 Elementos de Trabalho


Os elementos de trabalho convertem energia elétrica e pneumática em outras formas de
energia. Como exemplos podemos citar os motores elétricos, cilindros e motores pneumáticos
que executam automaticamente e assim acionam os elementos de sinalização. A Figura 11
mostra em corte a visão interna de um atuador de dupla ação pneumático, também chamado de
pistão, cilindro. Mostra os componentes que fazem parte este elemento.
Capítulo 2. Fundamentação teórica 33

Figura 11 – Desenho em corte de um atuador eletropneumático.

Fonte: Gomes (2020)

2.6.3 Elementos de Sinal


Os elementos de sinais são válvulas fins de curso ou sensores elétricos que informam
quando solicitados ao elemento de controle, que pode ser um CLP, sobre o andamento do
processo automatizado, são eles os responsáveis para enviar os sinais para as solenoides. A
Figura 12 mostra alguns tipos de sensores industriais, tais como, sensor capacitivo, indutivo,
magnético, óptico e um fim de curso elétrico.

Figura 12 – Elementos de Sinais Eletropneumáticos.

Fonte: Próprio Autor (2021).


Capítulo 2. Fundamentação teórica 34

Através deste mecanismo,vemos uma realimentação contínua do sensor elétrico notifi-


cando o elemento de controle sobre o estado atual de cada elemento de trabalho. Com base nessas
informações, o elemento de controle direciona a próxima etapa. Isso acontece periodicamente e
configura um processo automatizado.
É muito importante para quem está estudando os comando eletropneumáticos, entender
essa cadeia de comando, porque cada elemento tem sua função e especificidade. É importante
também ter noção de comandos elétricos, pois a lógica do circuito de comando é a mesma,com
contatos normalmente abertos e fechados, relés, temporizadores, contadores, botões. O domínio
das simbologias é indispensável para um estudante de automação, podemos destacar as simbolo-
gias dos elementos de comandos, em particular as válvulas de simples e duplo solenoide, saber o
comportamento dessas válvula faz toda diferença na montagem dos circuitos.
De acordo com Bonacorso e Noll (2000) válvulas eletropneumáticas são componentes de
um sistema pneumático que recebe automaticamente um comando de um circuito de controle.
Existem vários tipos de válvulas pneumáticas, dentre as mais usuais, podemos citar as válvulas
direcionais (direcionam o fluxo do fluido) e são classificadas de acordo com o número de entradas
e saídas – 2, 3, 4 ou 5 vias.
Segundo UFPR (2015) para que haja padronização e praticidade na elaboração e leitura
de um diagrama eletropneumáticos, normalizam-se os símbolos a serem empregados. A norma
utilizada é a ABNT NBR 8896:1985. É importante definir algumas premissas dessas normas :

• O símbolo não caracteriza a forma construtiva de um componente nem suas dimensões,


caracterizam apenas sua função.

• As válvulas são simbolizadas por meio de quadrados.

• O número de quadrados indica o número de posições que a válvula pode assumir.

• Dentro de cada quadrado as vias de passagem de uma válvula são indicadas por linhas e
setas. As setas, usualmente, indicam o sentido do fluxo.

Ainda segundo UFPR (2015) os quadrados são usados para simbolizar as válvulas. O
número de quadrados significa o número de posições que uma válvula direcional possui (dois é
a quantidade mínima de posições de comutação). O sentido do fluxo, são indicados por setas.
Os bloqueios ou retensões são representados por um “T”. As válvulas podem ser normalmente
abertas ou fechadas de acordo com o quadrado da direta no posicionamento, conforme podemos
ver na simbologia mostrada na Figura 13.
Capítulo 2. Fundamentação teórica 35

Figura 13 – Posição e o número de entradas e saídas das válvulas direcionais.

Fonte: RevistaMT (2020).

Os acionamentos externos são responsáveis pela mudança das posições de uma válvula
direcional. Podemos destacar esses acionamentos externos, quanto ao seu tipo: ação muscular,
ação mecânica, pressão, elétrico ou combinação entre estes, conforme podemos ver na Figura 14.
Não foi colocado todos os acionamentos, apenas um recorte que faz alusão ao trabalho.

Figura 14 – Simbologia dos acionamentos das válvulas direcionais.

Fonte: Próprio Autor (2021).


Capítulo 2. Fundamentação teórica 36

Define-se como posição de repouso aquela condição em que, através de molas, por
exemplo, os elementos móveis da válvula são posicionados enquanto a mesma não é acionada.
Posição de partida ou inicial será denominada àquela que os elementos móveis da válvula
assumam, após montagem na instalação e ligação da pressão na rede, bem como na possível
ligação elétrica e com a qual começa o programa previsto.
A posição inicial ou de repouso é definida pela condição em que ela se encontra, enquanto
os elementos móveis da válvula não estão operando, por exemplo, por uma mola.
Para garantir a identificação e ligação correta das válvulas, marcam-se as vias com letras
maiúsculas. Segue-se a regra abaixo, definido pela norma citada acima.

• Vias de utilização – A, B ou 2 e 4.

• Linhas de alimentação (entrada) – P ou 1.

• Escapes (exaustão) – R, S, T ou 3, 5 e 7.

• Linhas de comando (pilotagem) – Z, Y, X ou 10, 12 e 14.

A nomeação de uma válvula direcional depende do número de vias (conexões) e do


número de posições de comando, conforme podemos observar na Figura 15. O primeiro número
indica a quantidade de vias e o segundo número indica a quantidade de posições de comando da
válvula. As conexões piloto não são consideradas como vias.

Figura 15 – Válvulas Direcionais.

Fonte: Próprio Autor (2021).


Capítulo 2. Fundamentação teórica 37

A simbologia dos atuadores pneumáticos é muito mais intuitiva e de fácil compreensão,


veja conforme Figura 16 a simbologia destes atuadores mais comuns.

Figura 16 – Simbologia dos atuadores pneumáticos.

Fonte: Fonte: Próprio Autor (2021).

Muitos recursos que abrangem a eletropneumática são desenvolvidos para as aplicações


mais diversas possíveis. Esses recursos vão desde o próprio componente principal até a me-
todologia de desenvolvimento do projeto para entregar e garantir o funcionamento adequado.
Existem vários métodos para resolução das situações gerais ou especificas, dentre eles, o “método
intuitivo”, o “método cascata” ou "maximização de contatos". Este ultimo foi objeto de análise
nesse trabalho.
Segundo Brandão (2010) independente da técnica empregada, algumas regras são reco-
mendadas para uma melhor representação do circuito de comando eletropneumático:

• O barramento elétrico de +24Vcc deve sempre ser uma barra horizontal posicionada na
parte superior do circuito.

• O barramento elétrico de 0V deve sempre ser uma barra horizontal posicionada na parte
inferior do circuito.

• As chaves devem ser posicionadas acima das bobinas de relés.


Capítulo 2. Fundamentação teórica 38

• As bobinas de relés devem ser posicionados imediatamente acima do barramento de 0V.

• Não é possível a conexão de bobinas de relés em série, pois a tensão disponível para cada
não seria a tensão de 24Vcc do barramento de alimentação.

• Todos os elementos de uma conexão vertical devem ser desenhados alinhadamente.

• A distância entre conexões verticais deve ser mantida e de um valor adequado.

A Figura 17 trata de um circuito eletropneumático que faz com que o atuador avance e
retorne automaticamente e o número de vezes dessa ação está sendo controlado pelo contador,
que após atingir a contagem de duas vezes, parará o sistema. O circuito foi montado de modo
intuitivo, não obedecendo a uma técnica, o sistema é montado de acordo com a experiência do
executor.
Figura 17 – Circuito Eletropneumático.

Fonte: Próprio Autor (2021).


Capítulo 2. Fundamentação teórica 39

2.6.4 Método de Maximização de Contatos


Vale a pena ressaltar a sequencia de acionamento de um atuador. Dois ou mais ci-
lindros pneumáticos podem avançar e retornar, obedecendo a uma sequência de movimentos
predeterminada.
Representação Abreviada:

• As letas A, B, C... -> Representam os atuadores.

• O sinal positivo ( + ) -> Representa avanço de um atuador.

• O sinal negativo ( - ) -> Representa recuo de um atuador.

A figura 18 mostra três cilindros de dupla ação, e a representação do cilindro A avançado.


As etiquetas 1S1 e 1S2 representam os fins de curso que servirão de sinal para o circuito entender
que o cilindro chegou ao seu percurso total seja de avanço ou retorno.

Figura 18 – Simbologia do cilindro de dupla ação.

Fonte: Próprio Autor (2021).

A Figura 19 trata-se de uma das sequências mais básicas dos comandos pneumáticos
(A+ B+ A- B-). Primeiro o cilindro A avança, toca no fim de curso a1, e envia o sinal para a
solenoide de avanço do cilindro B, que avança, expulsando os materiais trazidos pelo avanço do
cilindro A. Após tocar no fim de curso b1, o mesmo envia um sinal para a solenoide de recuo do
cilindro A, fazendo ele voltar até tocar no fim de curso a0 e fazer voltar o cilindro B. Executando
assim a sequência da operação.
Capítulo 2. Fundamentação teórica 40

Figura 19 – Sequência de Acionamento de Atuadores.

Fonte: Maciel (2000)

A representação destes movimentos podem de um modo chamado diagrama trajeto-passo


que representa, sob a forma de gráfico, os movimentos que um cilindro realiza em cada passo,
durante um ciclo de trabalho, conforme vemos na Figura 20.

Figura 20 – Diagrama trajeto passo da sequencia A+ B+ A- B-.

Fonte: Maciel (2000)


Capítulo 2. Fundamentação teórica 41

De acordo com Pedroso (2005) a maximização de contato, também conhecida como


método passo a passo ou método de cadeia estacionária, não possui propriedades que reduzem o
número de relés auxiliares usados para o controle elétrico. Alternativamente, pode ser aplicada
com segurança a qualquer circuito sequencial pneumático, sejam em válvulas de controle
direcional de duas ou três posições ou de acionamento simples ou duplo. No método passo a
passo cada passo é responsável pelo movimento de um único cilindro. Ou seja, cada caractere na
sequência representa um cilindro e o número de passos será igual ao número de movimentos
representados na sequência de atuadores diferentes, posso ter no mesmo passo, acionamentos
simultâneos, mas nunca de mesmo cilindro. Portanto, em uma sequência em que 2 cilindros
avançam e retornam uma única vez por ciclo, há quatro movimentos, ou seja, quatro passos.
A técnica consiste nas três etapas:

• Para cada passo da sequência de acionamento é utilizado um relé auxiliar.

• O passo seguinte só acontece se o passo anterior ocorrer primeiro.

• O último passo é responsável por desativar o primeiro passo.

A Figura 21 traz um recorte da técnica da cadeia estacionária, ou método de maximização


de contatos. Os passos são representados por memórias, que neste casos são os relés auxiliares
K1, K2, K3, e etc. No circuito de comando, cada passo põe o passo posterior é necessário
fazer uma tabela da segmentação dos passos para saber quais fins de curso acionam os passos.
No circuito de força é preciso saber qual passo põe a solenoide para executar o movimento da
sequência em questão e qual passo tira. (MACIEL, 2000).

Figura 21 – Técnica cadeia estacionária.

Fonte: Maciel (2000)


Capítulo 2. Fundamentação teórica 42

2.7 O Protocolo OPC

Segundo LEITÃO (2006), nos últimos anos controlar processos pelo uso de software tem
aumentado consideravelmente. Num sistema, em que é necessário a utilização de diversos equi-
pamentos, muitos deles de fabricantes diferentes, necessita-se de softwares que se comuniquem
entre si.
De acordo com (FRANCO et al., 2010) Para realizar o desenvolvimento de sistemas
de controle inteligente, a fim de proporcionar uma melhor integração e facilitar a automação e
o controle, deve-se pensar na melhor maneira de efetuar a comunicação entre os dispositivos
envolvidos nesse controle. Uma forma é a utilização do padrão Object Linking and Embedding
(OLE) for Process Control (OPC), protocolo baseado no modelo de componentização criado
pela Microsoft e denominado Component Object Model (COM), que é uma maneira eficiente de
estabelecer interfaces para aplicações e considerado hoje o protocolo padrão da indústria.
O controle de processo na indústria pode ser representado por três níveis distintos:

• nível de campo, em que a presença de dispositivos inteligentes por redes fieldbus se torna
cada vez mais comum;

• nível de processo, no qual sistemas de controle distribuído (DCS) e os sistemas de supervi-


são e aquisição de dados (SCADA) disponibilizam dados;

• nível gerencial, em que se utilizam sistemas de bancos de dados e planilhas.

A integração desses níveis é de grande interesse para a indústria. O procedimento usual,


para possibilitar essa integração, é o desenvolvimento de drivers de comunicação entre diferentes
sistemas (SOUZA; FILHO; PENA, 1998).
O modelo de referência Open Systems Interconnection (OSI) determina como a parte
física (hardware) e a parte lógica (software) se comunicam. Essa comunicação esta baseada
nas diferentes camadas existentes entre a parte física e a lógica do processo. Cada camada
na hierarquia define um subconjunto de funções necessárias para o OSI. Sete camadas foram
consideradas suficientes para dividir o sistema em lógicas similares e funções compreensíveis.
Esse tido de ordenação das camadas do modelo OSI descreve uma hierarquia de funções,
(MELENDEZ; PETERSEN, 1986). As camadas são apresentadas hierarquicamente da mais
baixa (camada física) para a mais alta (camada de aplicação), como mostra a Figura 22.
A maioria dos programas de redes industriais usam a camada de aplicação para comunicar-
se com outros programas. Os Processos que rodam nessa camada são específicos da aplicação,
o dado é passado do programa de rede, no formato usado internamente por essa aplicação, e é
codificado dentro do padrão de um protocolo. Um dos principais problemas com interfaces de
sistema de dispositivo é a compatibilidade de protocolo na camada de aplicativo. Atualmente, os
fabricantes estão interessados em padronizar os protocolos de comunicação de controladores ló-
gicos programáveis (CLPs) para garantir a comunicação entre diferentes dispositivos. (FRANCO
et al., 2010).
Para compatibilizar essas camadas de aplicação, foi criado o protocolo OPC, estabele-
cendo assim regras para que sejam desenvolvidos sistemas com interfaces-padrão de comunicação
dos dispositivos de campo (CLPs, sensores, balanças, medidores de vazão e etc.) com sistemas
de monitoração, supervisão e gerenciamento, tais como SCADA, Manufacturing Execution
Systems (MES), Enterprise Resource Planning (ERP). (FONSECA, 2002).
Capítulo 2. Fundamentação teórica 43

Figura 22 – Hierarquia das camadas do modelo de referência OSI.

Fonte: Franco et al. (2010)

De acordo com Franco et al. (2010) O protocolo OPC esboça uma tendência enorme de
padronização desse nível de aplicação, o que é verdade. Todo fabricante de CLP fornece um
servidor OPC que permite comunicar o equipamento com sistemas de nível hierárquico mais alto.
Por sua vez, os sistemas SCADA, MES, Process Information Management System (PIMS), os
especialistas, Laboratory Information Management System (LIMS), e etc. Oferecem um cliente
OPC capaz de solicitar dados e enviar comandos para um servidor OPC de nível hierárquico
mais baixo.
O OPC é um padrão de comunicação de dados que permite a conexão direta com um
"cliente"a várias informações em diferentes pontos como controladores, dispositivos de I/O,
banco de dados, interface de máquina, monitoramento, processamento gráfico capacidades e etc.
Para implementar essa comunicação, o OPC usa um protocolo universal para enviar dados entre
o "servidor"(fonte de dados) e o "cliente"(aplicativo) eliminando, dentro do possível o uso de
drivers e conversores.(FRANCO et al., 2010).
Quando se utiliza de um padrão OPC, é necessário somente um driver padrão que se
torna o servidor. Os dados são convertidos para uma forma que qualquer cliente que tenha uma
disposição OPC possa se conectar sem qualquer tipo de preparo prévio, conforme Figura 23.
Capítulo 2. Fundamentação teórica 44

Figura 23 – Acesso a dados de processos com protocolo OPC.

Fonte: Franco et al. (2010)

O uso de servidores OPC permite algumas vantagens em relação ao desenvolvimento de


projetos em que se utilizam drivers conforme Maciel (2003). Algumas delas são:

• Uniformidade de interface para diferentes redes e protocolos, ou seja, dispensa a necessi-


dade de ajustes dos drivers de cada rede, o que costuma levar tempo na configuração;

• Integração plena com a rede, mesmo quando alterações de protocolo forem implementadas
o OPC será utilizado pelo fabricante;

• Eliminação da necessidade de drivers de comunicação;

• Integração entre diferentes ferramentas de supervisão.

Com o surgimento do sistema operacional Microsoft Windows® e o uso desta plataforma


na automação industrial, surgiu a tecnologia OPC (Clássica).
Um modelo de coleta de dados padronizado permite a comunicação entre sistemas indus-
triais e hardware usando os próprios recursos do sistema operacional. Como resultado, novas
restrições e requisitos foram associados ao desenvolvimento do OPC UA, segundo (VENTU-
RELLI, 2018). A Figura 24 traz a evolução do protocolo OPC.
Segundo Marcio (2021) O OPC Clássico Utiliza-se da interface COM/DCOM (Distri-
buted Component Object Model), também do Microsoft Windows®, permitindo troca de dados
entre aplicativos e dispositivos, por exemplo, um PLC e um sistema SCADA conectado com um
OPC e possui três especificações:

1. DA (Data Access): para troca de dados em tempo real.

2. A&E (Alarm and Events): dados e mensagens de eventos de estados.

3. HDA (Historical Data Access): dados para análise histórica de eventos.


Capítulo 2. Fundamentação teórica 45

Figura 24 – Evolução da tecnologia OPC.

Fonte: Venturelli (2018)

Ainda segundo Marcio (2021) O OPC Clássico se mostrou limitado para alguns desafios
do seu tempo. As principais limitações que surgiram na época foram:

• Problemas frequentes de configuração com o DCOM.

• Não há timeouts configuráveis.

• Apenas Microsoft Windows®.

• Segurança muito simples Nenhum controle sobre DCOM.

A Figura 25 mostra um PLC e um SCADA comunicando-se com um Driver OPC


disponibilizado pelo servidor. Nesse modo de operação que caracteriza o OPC Clássico é
necessário o Windows® para que se gerencie a troca de dados.
Para entender como o padrão OPC UA foi alcançado, sabendo que esta é a tecnologia mais
recente em comunicação de dados, era necessário entender antes, que cada fabricante desenvolvia
suas próprias características e particularidades, e em meados de 1990 eram necessários “drives”
proprietários para se comunicar.
Capítulo 2. Fundamentação teórica 46

Figura 25 – Cliente Servidor OPC.

Fonte: Venturelli (2018)

2.7.1 O Protocolo OPC UA


O OPC Unified Architecture (UA) foi a tecnologia desenvolvida para ser o upgrade do
OPC Clássico, permanecendo um padrão open source de comunicação de dados industriais.
Diferente do OPC Clássico, o OPC UA usa os conceitos de orientação ao objeto e suporta
estruturas de máquinas de estado, bancos de dado independente do sistema operacional. Existem
também várias vantagens do OPC UA sobre o OPC tradicional: (MARCIO, 2021)

• Suporta arquitetura orientada a serviços (SOA) que permite a fácil personalização do OPC
UA, para diversos tipos de dispositivos e aplicativos.

• Possibilita a troca de dados brutos e informações pré-processadas entre os sistemas in-


corporados nos sensores e nos dispositivos de campo e os sistemas de ERP, MES e de
visualização de processos (IHM).

• Possui segurança robusta de dados.

Pode-se usar o OPC UA para configurar diferentes matrizes de arquitetura de conexão.Não


esquecendo do conceito básico de comunicação que é baseado em cliente-servidor, para que se
possa conectar sistemas com vários hardwares, como SCADA, bancos de dados e serviços em
nuvem. Abaixo na Figura 26, podemos ver três arquiteturas diferentes do protocolo OPC entre
servidor e cliente.
A comunicação OPC UA suporta dois formatos, UA Binário e XML. O remetente
criptografa os dados no formato correto e o destinatário deve descriptografar o conteúdo com
toda segurança e integridade para reconstruir os dados originais, Marcio (2021).
Capítulo 2. Fundamentação teórica 47

Figura 26 – Arquitetura Protocolo OPC.

Fonte: Venturelli (2018)

2.7.1.1 Formato UA Binário


.
Segundo Romano (2019) o formato UA Binário é um conjunto de dados seriados em
formato de array (conjunto ou estrutura de dados) de bytes. Este é um método simples e de
baixo custo, Mensagens UA Binario reduzem o custo computacional em termos de codificação e
decodificação, entretanto só é interpretado por clientes compatíveis com OPC UA.

2.7.1.2 Formato XML – Extensible Markup Language


Os documentos XML trocam dados em camadas de alto nível, por isso são considerados
protocolos universais. As mensagens codificadas em XML podem ser interpretadas pelos clientes
seguindo a estrutura da linguagem XML, (ROMANO, 2019).
De acordo com Marcio (2021) como codificar e decodificar em XML é mais caro,
normalmente essa tecnologia é usada para comunicação corporativa fim a fim. A Figura 27
mostra uma topologia com o formato Binário e XML numa mesma rede separada pelo tipo de
serviço e aplicação.
Segundo Venturelli (2018) a transformação digital permite indústrias mais inteligentes.
Portanto, é mais eficiente, mais barato e mais seguro. Portanto, a automação industrial terá um
papel fundamental nesta transição, juntamente com a Indústria 3.0, que se baseia na pirâmide
da automação, e se transformará nos pilares da Automação Industrial, que é a industria 4.0. A
Figura 28 mostra essa convergência, padronização e velocidade. Na prática, isso significava que
cada fabricante desenvolvia o seu, com suas particularidades e características.
Capítulo 2. Fundamentação teórica 48

Figura 27 – Formato Binário e XML do protocolo OPC.

Fonte: Venturelli (2018)

Figura 28 – Convergência de tecnologias.

Fonte: Venturelli (2018)

O OPC UA suporta dois protocolos de comunicação, o OPC/TCP e o SOA/HTTPS.

2.7.1.3 Protocolo OPC/TCP (OLE for Process Control / Transmission Control Protocol)
.
De acordo com Romano (2019) este sistema se baseia no protocolo TCP para transporte
de dados, permitindo um canal full-dulplex entre o Server e o Client, no modelo Socket (soquete),
o canal se comunica com pacotes Binários, permitindo canal seguro (soquete seguro), somente
clientes OPC são capazes de receber informações de OPC-TCP.
Capítulo 2. Fundamentação teórica 49

2.7.1.4 Protocolo SOAP/HTTPS (Simple Object Access Protocol / Hypertext Transfer Pro-
tocol Secure)
Esse protocolo normalmente funciona com mensagens estruturadas SOAP (XML) envia-
das por HTTPS, que é conhecido por envelopes de e-mail. Essas mensagens são conjuntos de
dados que suportam XML e são usadas para se comunicar com vários tipos de dispositivos que
podem funcionar com segurança, criptografia e certificados digitais, (MARCIO, 2021).
O OPC UA utiliza as tecnologias SSL (Secure Sockets Layer), TLS (Transport Layer
Security) e AES (Advanced Encrypton Standard), que permitindo os seguintes controles de
segurança:
De acordo com Romano (2019) proteção contra acesso não autorizado, alterações de
valor de processo, vandalismo e danos por uso inadvertido, os recursos de segurança são
parte integrante do padrão e incluem autenticação de usuário e aplicativo, assinaturas digitais
de mensagens e criptografia de dados de saída. A troca de dados entre dispositivos OPC
UA é protegida por verificações de segurança, integridade e autenticação. O mecanismo de
transferência de dados OPC UA é acessível via firewall e internet e permite controle de acesso
local e internet. A Figura 29 mostra uma combinação de dois protocolos SOAP e TCP que atuam
como XML e binários respectivamente no mesmo aplicativo.

Figura 29 – Modelo TCP e SOAP para o protocolo OPC.

Fonte: Venturelli (2018)


50

3 METODOLOGIA

Foi criada uma situação problema hipotética, para auxiliar na condução do trabalho,
conforme descrição abaixo.
Determinada máquina tem seu processo operacional descrito pelo diagrama trajeto passo
abaixo. Sua função é implementar uma lógica de programação em Ladder, cujo acionamento se
dará por um supervisório e que faça a máquina funcionar de acordo com o esquema proposto. A
Figura 30 traz uma situação hipotética onde três atuadores de dupla ação, obedecerão a sequência
do diagrama trajeto passo, descrita na Figura 31. O esquema eletropneumático pode ser conferido
na Figura 32.

Figura 30 – Esquema hipotético.

Fonte: Próprio Autor (2021).

3.1 Resolução da situação problema pelo método da maximização de contatos no Fluid-


SIM®

O primeiro passo é levantar a sequência eletropneumática em questão, depois pelo método


de maximização dos contatos implementar a lógica de programação no FluidSIM®. A Figura 33
mostra a sequência de acordo com o projeto e o diagrama de comando eletropneumático.
Feito isso divide-se a sequência em passos, cada agrupamento de movimentos cor-
responde a um passo e será representado por uma memória "K". Como havia repetição de
movimentos, foi usada a técnica de multiplicação de contatos, onde cada fim de curso foi associ-
ado a uma memória que começou a ser contada a partir de K100 até K105, correspondendo a
seis fins de curso, conforme Figura 34. A técnica de construção do circuito eletropneumático foi
a cadeia estacionária, alguns dos seus princípios construtivos foi esmiuçado no capitulo dois,
sobre eletropneumática. O foco deste trabalho não é o ensino desta técnica, mas a comunicação
entre os softwares. Uma vez estabelecida a comunicação, as possibilidades de teste são infinitas.
Capítulo 3. Metodologia 51

Figura 31 – Diagrama Trajeto Passo do esquema hipotético.

Fonte: Próprio Autor (2021).

Figura 32 – Diagrama Eletropneumático.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 52

Figura 33 – Sequencia de acordo com o diagrama trajeto passo.

Fonte: Próprio Autor (2021).

A Figura 35 mostra a elaboração do circuito de comando eletropneumático, cada passo


está sendo representado por uma memória de K1 a K8.
Já a Figura 36 traz a distribuição de contatos que foram associados a uma memória.
A Figura 37 traz o diagrama de força, com a lógica de contatos abertos e fechados que
acionam as solenoides.
Capítulo 3. Metodologia 53

Figura 34 – Divisão da sequência em passos.

Fonte: Próprio Autor (2021).

Figura 35 – Diagrama de comando eletropneumático.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 54

Figura 36 – Diagrama de contatos eletropneumáticos.

Fonte: Próprio Autor (2021).

Figura 37 – Diagrama de força.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 55

3.2 Configuração do protocolo OPC no Codesys®

O segundo passo é converter esse diagrama eletropneumático na linguagem de contatos


Ladder. Muitos alunos apresentam dificuldade de intuitivamente programar em Ladder, uma vez
que essa linguagem deriva muito de lógica e sem uma técnica para ajudar a programar, dificultaria
resolver as sequências propostas. Com a ajuda do Fluidsim® e da técnica de maximização de
contatos, o estudante consegue resolver os desafios de sequencias eletropneumáticas e depois é
só converter para a linguagem Ladder.
A seguir segue-se um tutorial de configuração do protocolo OPC para o CodeSys®. Para
iniciar a programação, clica-se no ícone do software CodeSys®. Deve-se clicar em File depois
em New, para abrir um novo projeto, conforme Figura 38 abaixo.

Figura 38 – Criação de um novo programa no Codesys®.

Fonte: Próprio Autor (2021).

O sistema abrirá uma nova tela para escolher a configuração de destino. Deve-se clicar
em configuration escolher a opção 3S Codesys SP PLCWinNT V2.4, conforme Figura 39.

Figura 39 – Criação do target Settings.

Fonte: Próprio Autor (2021).

É importante seguir as etapas posteriores, pois permitirão interagir com as variáveis


globais. Marque o item General, conforme Figura 40 e depois a opção Load bootproject
automatically, conforme Figura 41, para que o sistema seja carregado automaticamente, as outras
opções por padrão já estão marcadas, depois clique em OK.
Capítulo 3. Metodologia 56

Figura 40 – Criação do target Settings.

Fonte: Próprio Autor (2021).

Figura 41 – Criação do target Settings.

Fonte: Próprio Autor (2021).

O último passo dessa primeira parte é definir o tipo de linguagem de programação a ser
utilizada. Neste caso será escolhida a linguagem Ladder, realizando as operações indicadas na
Figura 42. Deve-se marcar Type of POU a opção Program e depois em Language of the POU
marcando assim a opção LD para Ladder.
Capítulo 3. Metodologia 57

Figura 42 – Definição da Linguagem de Programação.

Fonte: Próprio Autor (2021).

A segunda etapa é definir as variáveis globais. Estas variáveis poderão ser lidas por
outros programas como FluidSIM® e Elipse SCADA® através do protocolo OPC. Sigas as etapas
conforme Figura 43.

Figura 43 – Definição das variáveis globais.

Fonte: Próprio Autor (2021).

Ao dar um duplo click em Global Variables, o software abre um menu que nos permite
declarar as variáveis globais, conforme Figura 44. Foram declaradas variáveis, dentre as quais
temos a de entrada de nome IN, outra de saída de nome OUT, ambas do tipo BYTE e uma outra
variável para comunicar-se com o Elipse SCADA® de nome MEMO1 do tipo BOOL.
Capítulo 3. Metodologia 58

Figura 44 – Identificação das variáveis globais.

Fonte: Próprio Autor (2021).

Quando criamos as variáveis globais precisamos exportá-las para que outros softwares
possam usá-las em seus sistemas de programações. Esse talvez seja o passo mais importante
e que não deve ser esquecido jamais na comunicação OPC. Conforme figura 45, na árvore
Resources, você deve dar um duplo clique em Workplace, vai aparecer a tela Options, você deve
clicar em Symbol configuration e depois em Configure symbol file.
A Figura 46 mostra a etapa que valida a exportação das variáveis que foram criadas para
que outros softwares as reconheça como variáveis globais do sistema. Quando for marcada a
opção Configure symbol file da figura anterior o sistema abre a tela Set object atributtes, deve-se
clicar em Global Variables e selecionar todas as variáveis que você deseja exportar e clicar
depois em OK.
Capítulo 3. Metodologia 59

Figura 45 – Exportação das variáveis globais.

Fonte: Próprio Autor (2021).

Figura 46 – Escolha das variáveis globais para exportação.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 60

A Figura 47 mostra a última etapa da exportação das variáveis globais. Deve-se selecionar
a caixa Dump symbol entries e depois clicar em OK.

Figura 47 – Exportando variáveis para outros sistemas.

Fonte: Próprio Autor (2021).

Cumprida todas as etapas, clique em File depois em Save as, para salvar o arquivo,
conforme Figura 48.

Figura 48 – Salvando arquivo.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 61

É importante verificar os possíveis erros de declaração de variáveis ou programação


indevida. É necessário clicar em Project e selecione Rebuild all, conforme Figura 49. Se estiver
tudo certo, o sistema exibirá conforme a Figura 50 que não existe erros. Caso encontre erros nas
definições ou programação corrija-os e repita o processo de compilação.

Figura 49 – Compilação da programação.

Fonte: Próprio Autor (2021).

Figura 50 – Verificação de erros.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 62

Para a configuração do Protocolo OPC no Codesys®, primeiro clique em Online e depois


Communication Parameters, conforme Figura 51.

Figura 51 – Parâmetros de configuração.

Fonte: Próprio Autor (2021).

Precisa-se criar um nome para conexão, em Channels clique em Local (1), depois em
New (2), para uma nova conexão. Estabeleça um nome para a conexão, foi usado o nome
"COMUNICAÇÃO"(3). Escolha depois o protocolo TCP/IP (Level 2) (4). Após esses passos
clique em OK (5), conforme Figura 52. Pode certificar-se que está tudo configurado corretamente
se o nome da comunicação que foi criada ficar registrada com os dados escolhidos, conforme
Figura 53.
Capítulo 3. Metodologia 63

Figura 52 – Nomeação do Servidor de comunicação.

Fonte: Próprio Autor (2021).

Figura 53 – Link de comunicação.

Fonte: Próprio Autor (2021).

Quando você baixa o software Codesys® ele vem com três arquivos muito importantes.
O primeiro deles é o do software propriamente dito, o segundo é do PLCWinNT24 que trata-se
do servidor CLP do Codesys® e o terceiro é o ícone para configurar a conexão com o protocolo
OPC. A Figura 54 mostra o CLP virtual. Ao efetuar um duplo clique neste ícone, vai aparecer
uma mensagem igual a da Figura 55, mostrando que esta conexão vai ficar online por duas horas.
Capítulo 3. Metodologia 64

Figura 54 – CLP Virtual do Codesys.

Fonte: Próprio Autor (2021).

Figura 55 – Tempo máximo de operação do CLP Virtual.

Fonte: Próprio Autor (2021).

A Figura 56 mostra o CLP Virtual em RUNNING, ou seja, ativo no sistema, pronto


para comunicar-se, o software vai encapsular os dados no protocolo TCP/IP para que possa ser
transmitido pelo protocolo OPC. O último arquivo importante é o FestoOPCConfig Figura 57,
esse configurará o protocolo OPC para comunicar este software aos demais. Esses arquivos
devem estar juntos e de preferência na sua área de trabalho.

Figura 56 – CLP Virtual em Running.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 65

Figura 57 – Protocolo OPC do Codesys.

Fonte: Próprio Autor (2021).

Ao configurar o servidor OPC, clique em File (1) , é importante que deixe marcada a
opção Single PLC (2) , conforme Figura 58, depois clicar em NEW (3) para criar a comunicação
do CLP Virtual com o protocolo OPC. Obedecer as etapas descritas pela Figura 59. Clicar em
Connection (1) e depois em Edit, deve aparecer o mesmo nome que foi criado ao definir as
comunicações de parâmetros no Codesys®, no caso o link de nome: COMUNICAÇÃO.

Figura 58 – Configuração do CLP Virtual para modo Single.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 66

Figura 59 – Edição do modo Single do CLP Virtual.

Fonte: Próprio Autor (2021).

O servidor OPC é local e de nome COMUNICACAO, o gateway tem que ser Local.
A partir dai já temos uma comunicação OPC que pode trocar dados com outra plataforma,
conforme Figura 60.

Figura 60 – Conexão OPC do Codesys.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 67

3.3 Configuração do protocolo OPC no Fluidsim®

O terceiro passo segue-se após terminar a programação do CLP no Codesys®, que foi
baseada no método passo a passo da eletropneumática, feita anteriormente. É necessário preparar
o sofwtare FluidSIM® para comunicar-se com o Codesys®. O Festo FluidSIM® simula os
acionamentos eletropneumáticos para obter os sinais de entrada e saída por meio do protocolo
OPC. A Festo disponibiliza o FestoCoDeSys.OPC.02 que gerencia a comunicação entre o
Codesys® e o FluidSIM® de forma simplificada.
Os sinais de entrada e saída do FluidSIM® são exportados por meio de um bloco
disponibilizado na biblioteca padrão. A Figura 61 mostra os componentes da biblioteca do
FluidSIM®, mas precisamente os blocos de comunicação OPC.

Figura 61 – Componentes de comunicação OPC.

Fonte: Próprio Autor (2021).

A Figura 62 mostra os blocos de comunicação que são constituídos de forma semelhante


à representação de um módulo de entrada ou saída digital de 8 portas.

Figura 62 – Representação dos blocos do CLP Festo

.
Fonte: Próprio Autor (2021).
Capítulo 3. Metodologia 68

Para a transmissão de sinais utiliza-se o protocolo OPC. Para configurar o protocolo,


seleciona-se no menu Options do FluidSIM® e a opção EasyPort/OPC/DDE Connection, con-
forme Figura 63.

Figura 63 – Habilitação da comunicação OPC do Fluidsim.

Fonte: Próprio Autor (2021).

A seguir, como indica a Figura 64 habilita-se o modo OPC com o buffer de eventos.

Figura 64 – Propriedades de comunicação OPC.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 69

Para configurar a comunicação do Festo CoDeSys OPC com o Codesys®, conforme


Figura 65, pode-se selecionar o item do digrama de blocos com o botão direito do mouse. A
seguir seleciona-se Properties.

Figura 65 – Configuração das Portas do OPC.

Fonte: Próprio Autor (2021).

Conforme detalhamento na Figura 66, você deve clicar em Browse do OPC Server, então
vai abrir uma janela para selecionar o servidor OPC, escolha o arquivo FestoCoDeSys.OPC.02
como OPC Server e clique em OK.

Figura 66 – Servidor OPC da Festo.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 70

Observação: É muito importante na hora que estiver definindo as portas no FluidSIM®


salvar a configuração OPC Config, senão ele pode não reconhecer as portas, conforme detalhado
na Figura 67.

Figura 67 – Servidor OPS no Codesys.

Fonte: Próprio Autor (2021).

Na sequência, descrita na Figura 68, deve-se clicar em Browse do “item”. Selecionar


a variável criada no Codesys® para representar as entradas, neste caso, a variável que foi
selecionada foi a de nome "IN". Clicar depois em OK.

Figura 68 – Configuração da porta de entrada do módulo lógico.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 71

Fazer este mesmo procedimento para configurar a saída para o CLP. O FluidSIM® inverte
os conceitos de entrada e saída, de modo que o móduloFluidSIM® OUT recebe as entradas do
CLP e FluidSIM® IN recebe as saídas. Dessa forma, o bloco deverá estar configurado conforme
a Figura 69 abaixo:

Figura 69 – Configuração do bloco de CLP para entradas e saídas.

Fonte: Próprio Autor (2021).

3.4 Configuração do protocolo OPC no Elipse SCADA®

O último passo da metodologia deste trabalho, traz o sistema supervisório que está uma
camada acima da camada onde está o CLP, segundo a pirâmide da automação. Essa parte de
comunicar o sistema supervisório Elipse com o Codesys® tem pouca literatura, o que tornou
este trabalho mais desafiador. Abaixo na Figura 70 encontramos o ícone do software Elipse
SCADA® e ao clicar duas vezes sobre o mesmo, abrirá uma tela, indicando que o software é de
demonstração, mas atende a especificação deste trabalho.

Figura 70 – Ícone Elipse SCADA.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 72

A Figura 71 traz a tela principal do software e a Figura 72 a forma como deve-se criar
uma nova aplicação de desenvolvimento.

Figura 71 – Tela de configuração do Elipse SCADA.

Fonte: Próprio Autor (2021).

Figura 72 – Nova aplicação no Elipse.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 73

É importante configurar antes de tudo o servidor OPC, conforme Figura 73. Clique
em Organaizer (1), vai abrir a tela dessa função, deve-se clicar em OPCServer (2) e depois
em "Novo", para criar um servidor. A Figura 74 traz o servidor OPC criado, agora precisa ser
configurada e associada as tags de informação.

Figura 73 – Configuração do servidor OPC do Elipse.

Fonte: Próprio Autor (2021).

Figura 74 – Servidor OPC criado.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 74

Uma vez criado o servidor, precisamos localizar qual o tipo de servidor OPC fará a
comunicação do Elipse SCADA®, com o CLP. Clique em localizar (1), conforme Figura 75.

Figura 75 – Localizar o tipo de servidor OPC.

Fonte: Próprio Autor (2021).

O sistema abrirá uma janela com vários servidores locais. É muito importante definir o
mesmo servidor que fez a comunicação com o Fluidsim®, no caso o FestoCoDeSys.OPC.02,
clique neste servidor (2) e depois em Ok (3), conforme Figura 76.
De posse da escolha do tipo de servidor OPC, é hora de importar as variáveis globais que
foram criadas no CLP. Clique em Importar (1), conforme Figura 77.
Vai aparecer todas as variáveis globais criadas no CLP no menu "Servidor OPC". Deve-se
importar para o menu "Sua Aplicação". Selecionar a variável clicando sobre ela, arrate até o
menu "Server", para que a mesma seja compilada como variável do Elipse SCADA®, conforme
Figura 78.
Após importar todas as variáveis, as mesmas aparecerão no Organaizer, no item "Server".
Deve-se clicar uma por uma e marcar a caixa "habilitar escrita automática", conforme Figura 79.
Capítulo 3. Metodologia 75

Figura 76 – Servidores Locais.

Fonte: Próprio Autor (2021).

Figura 77 – Importar variáveis globais.

Fonte: Próprio Autor (2021).


Capítulo 3. Metodologia 76

Figura 78 – Configuração do bloco de CLP para entradas e saídas.

Fonte: Próprio Autor (2021).

Figura 79 – Habilita escrita automática.

Fonte: Próprio Autor (2021).


77

4 RESULTADOS

Neste capítulo são apresentados os resultados do trabalho. Serão mostrados o resultado


final de cada software, sua configuração e leiaute.

4.1 Resultado Final do Codesys

Abaixo segue a programação em Ladder da atividade. A Figura 80 traz as variáveis


globais, que serão usadas no Fluidsim® ou no Elipse SCADA® conforme aplicação. A progra-
mação em Ladder foi espelhada do método passo a passo da eletropneumática e pelo fato dela
ser extensa foi anexada no apêndice deste trabalho.

Figura 80 – Configurações das variáveis globais.

Fonte: Próprio Autor (2021).

4.2 Resultado Final do Fluidsim®

Abaixo na Figura 81 encontramos o circuito eletropneumático de comando que ficará no


plano final do Fluidsim®. A sequência foi aleatória, dividida em 7 passos, alguns simultâneos.
Para esta situação, foi desenvolvido primeiramente o método da cadeia estacionária, pois há
repetições de movimentos e a técnica ficava bem próxima do passo a passo para o Ladder. De
modo que a conversão para a liguagem do CLP, foi apenas um espelho e mudança dos labels das
entradas e saídas do CLP.
Capítulo 4. Resultados 78

Figura 81 – Circuito eletropneumático de comando.

Fonte: Próprio Autor (2021).

Na Figura 82 foi esboçada as configurações elétricas de entradas e saídas do CLP no


Fluidsim®, esses endereços foram distribuídos de forma aleatória. Com essa identificação fica
bem mais fácil definir as entradas e saídas do CLP. É muito portante para cada projeto ter essa
identificação. De modo que se precisar alterar a sequência da operação, as mudanças no CLP
serão mais simplificadas.
Capítulo 4. Resultados 79

Figura 82 – Circuito elétrico do CLP no Fluidsim.

Fonte: Próprio Autor (2021).

4.3 Resultado Final do Elipse SCADA®

Abaixo na Figura 83 encontramos a tela principal do Elipse SCADA®.


Essa tela possui animações que estão com variáveis globais que foram declaradas no
CLP. Todas as configurações são feitas no servidor OPC. Foi usado esse software porque ele
ocupa pouco espaço de memória no computador, é menos complexo na sua operação e cumpre
os requisitos para proposta do trabalho.
Capítulo 4. Resultados 80

Figura 83 – Tela final do supervisório.

Fonte: Próprio Autor (2021).

4.4 Discussões

Este trabalho teve como foco principal fins didáticos, tem-se mais uma proposta para
aprendizagem de programação em CLP usando o Codeys®, simulação de circuitos eletropneu-
máticos com o Fluidsim® e desenvolvimento de sistemas supervisórios, utilizando o Elipse
SCADA®.
A comunicação entre os softwares deu-se através da utilização do protocolo OPC, que
possibilita a troca de dados entre diferentes equipamentos e controladores. Cada software já trazia
em suas configurações as regras de uso desse protocolo, o escolhido foi o que é disponibilizado
pela Festo Codesys OPC para comunicação entre os mesmos.
As instituições, sejam do ensino superior ou médio técnico da área de automação podem
usar este modelo didático para ensino dos seus alunos.
Uma validação desta metodologia foi a do professor Paulo Santiago de Manaus. Ele é
o criador do site Centro de Automação 4.0, onde sua plataforma de ensino já formou vários
alunos em todo o Brasil, usando o Codeys® e o protocolo OPC como base para a realização da
integração de softwares. O seu método foi uma das inspirações para este trabalho.
Estamos no alvorecer das metodologias ativas, da virtualização, da simulação em tempo
real, do advento da internet 5G, da robotização, da inteligência artificial, do aprendizado de
máquinas, cada vez mais os softwares se converterão para os sistemas integrativos e o protocolo
OPC UA é uma grande aposta.
Segundo Neves (2021) o protocolo OPC UA, é um protocolo de comunicação com
potencial na Indústria 4.0, visto possibilitar a ligação entre várias redes de comunicação distintas,
tendo como característica a interoperabilidade.
Capítulo 4. Resultados 81

Nunca foi tão importante a segurança da informação através de cyber sistemas, o volume
gerado por alarmes, defeitos, soluções precisam ser armazenados em bancos de dados. A
tecnologia da informação através das redes de computadores, está invadindo o mundo da
automação e daqui a alguns anos, todos nós dessa área da automação deveremos entender de
tratamento de dados e criptografia, pois a segurança dos dados será a caixa de pandora da próxima
era.
82

5 CONCLUSÕES

Este trabalho demonstrou que para fins didáticos tem-se um modelo para aprendizagem
de programação em CLP, bem como desenvolvimento de sistemas eletropneumáticos e supervi-
sórios, abrindo novas opções para seu aperfeiçoamento. Iniciou-se o projeto pela modelagem da
sequência retirada do diagrama trajeto-passo, usando a técnica de maximização de contatos em
eletropneumática, depois tomando como base esse esquema, converteu-se para a linguagem Lad-
der. A configuração do sistema supervisório foi o último elemento configurado, proporcionando
as três instâncias da automação. Depois disso foi configurado o protocolo OPC, permitindo a
comunicação e integração entre os softwares.
O módulo desenvolvido possibilitou, de forma geral, simulação de implementações e
análises da programação de processos industriais utilizando metodologias ativas de aprendizagem,
dentre as quais se destacam os simuladores, que é uma estratégia que aproxima o virtual do real.
O trabalho ficou estruturado da seguinte forma: foram apresentados, no Capítulo 2,
a fundamentação teórica onde foi feita uma abordagem sobre os processos automatizados,
esmiuçando as principais características dos softwares que participaram da implementação,
caracterizando os conteúdos trabalhados na dissertação. No Capítulo 3 foi descrita a metodologia
trabalhada que teve o foco na implementação do protocolo OPC nos softwares FluidSIM®,
Codesys® e Elipse SCADA® explorando algumas de suas funcionalidades e características,
emulando os sistemas. O Capítulo 4 abordou os resultados finais de cada aplicação, bem
como as discussões geradas pela implementação. Finalmente, o Capítulo 5, apresentou nas
conclusões uma proposta para utilização dos simuladores nos sistemas automatizados, em uma
visão pedagógica atualizada, propondo trabalhos futuros.
Outro ponto que valeu a pena destacar foi a utilização do Protocolo OPC. Ele usa
tecnologia inovadora, open source que está se difundindo no ambiente industrial e sendo utilizada,
entre outras, na área de controle de processos, com múltiplas funcionalidades, principalmente
com o advento da indústria 4.0. Foi explorado, no desenvolvimento do trabalho, somente
uma de suas configurações do OPC o Data Acess, possibilitando a comunicação entre os
softwares, fundamental ao desenvolvimento do trabalho. Estas limitações não possibilitaram
que se analisasse e aplicasse outras ferramentas disponibilizadas pelo OPC, como transpor esses
dados para a nuvem, ou usar banco de dados, mas podem ser aproveitadas para o desenvolvimento
de trabalhos futuros.
Desse modo, conclui-se que a utilização de simuladores para sistemas de manufatura,
envolvendo circuitos sequenciais eletropneumáticos, linguagem Ladder e supervisório foi uma
alternativa potencialmente viável para a aprendizagem. Esses softwares apresentam vantagens
de custo e beneficio, antes da implementação em sistema real.

5.1 Sugestões para trabalhos futuros

Considerando os aspectos abordados sobre o trabalho desenvolvido, podem ser estabele-


cidas alguns preceitos para sua continuidade, ou mesmo outros trabalhos, complementares a esta
dissertação.
Uma outra linha de pesquisa consiste no aprofundamento e aplicabilidade do protocolo
OPC, principalmente com o uso de interfaces que simulam processos industriais em 3D como
o Factory IO® ou o Automation Studio®, buscando utilizar suas outras funcionalidades e
Capítulo 5. Conclusões 83

potencialidades, por suas características de protocolo aberto, atualidade e influência industrial.


Pode-se melhorar o sistema supervisório com o uso do Elipse E3®, que permite uma
programação orientada a objeto e banco de dados. Usar a IHM do Codesys® para ser um
caminho a mais de visualização do sistema e inserir um novo dispositivo de aprendizagem.
Mudar a programação de Ladder para Grafcet, afim de deixar a programação mais enxuta e
incrementar mais cilindros e outros dispositivos nos circuitos eletropneumáticos.
Para trabalhos mais ousados principalmente com a industria 4.0, seria a integração de
mais sistemas, como outras IHMs, CLP de Segurança, acesso enviar esses dados para a nuvem
e serem gerenciadas através do Big Data por exemplo. É possível também comunicar-se com
o microcontrolador ESP32 e permitir interconectividade com outros protocolos que fazem o
back-end e o front-end da interface WEB para internet.
Aprender a integrar simuladores no aprendizado de programação é importante para o
desenvolvimento acadêmico. O protocolo OPC é uma porta de entrada para o futuro das integra-
ções de sistemas automatizados. Cada vez mais os fabricantes desses dispositivos disponibilizam
em seus softwares a opção da configuração desse protocolo para integração. Os simuladores
caminham para este mesmo processo, ou seja, facilitar a comunicação dos mesmos. Estamos
no alvorecer de uma disrupção tecnológica, a aplicação de sistemas wireless e IoT - Internet of
Things com o OPC estarão certamente dominando as comunicações industriais. Fica a sugestão
de estudo para trabalhos futuros.
84

REFERÊNCIAS

ALBUQUERQUE, P. H. et al. Na era das máquinas, o emprego é de quem? Estimação da


probabilidade de automação de ocupações no Brasil. [S.l.], 2019.

ALVES, T. dos S. Automação industrial i. Escola Superior de Tecnologia de Abrantes e


Instituto Politécnico de Tomar, Departamento de Engenharia e Gestão Industrial–DEGI,
v. 2005, 2004.

ANDERSON, L. W.; BLOOM, B. S. et al. A taxonomy for learning, teaching, and assessing:
A revision of Bloom’s taxonomy of educational objectives. [S.l.]: Longman„ 2001.

ARRUDA, S. R.; MATOS, O. A. Metodologia senai para formação profissional com base
em competências: um estudo de caso sobre a implantação deste método no departamento
regional do senai de santa catarina. Revista E-Tech: Tecnologias para Competitividade
Industrial-ISSN-1983-1838, p. 34–58, 2012.

BARBOSA, E. F.; MOURA, D. G. de. Metodologias ativas de aprendizagem na educação


profissional e tecnológica. Boletim Técnico do Senac, v. 39, n. 2, p. 48–67, 2013.

BONACORSO, N. G.; NOLL, V. Automação eletropneumática. [S.l.]: Saraiva Educação SA,


2000.

BRANDãO, D. ACIONAMENTO E CIRCUITOS ELETROPNEUMÁTICOS. 2010.


Disponível em: <https://edisciplinas.usp.br/pluginfile.php/4278765/mod_resource/content/0/
SEL0406_2018_Notas%20de%20aula_Eletro-pneum%C3%A1tica.pdf>. Acesso em: 28 mai.
2021.

CARDOSO, M. d. O. Indústria 4.0: a quarta revolução industrial. Universidade Tecnológica


Federal do Paraná, 2016.

CHENG, R. et al. Simulation: the past 10 years and the next 10 years. In: IEEE. 2016 Winter
Simulation Conference (WSC). [S.l.], 2016. p. 2180–2192.

CRUZ, F. da et al. Comissionamento virtual: Ferramenta de validação de programas de controle


de sequencia em sistemas automatizados de manufatura. 2014.

EATON. Programação Básica CoDeSys Galileo. 2012. Disponível em: <https:


//docplayer.com.br/14324406-Programacao-basica-codesys-galileo.html>. Acesso em: 22 mai.
2021.

ELIPSE. Tutorial Elipse SCADA. 2004. Disponível em: <http://www.docs.mekatronik.com.br/


wp-content/uploads/2010/07/Tutorial-Elipse-Scada.pdf>. Acesso em: 22 mai. 2021.

ELLINGTON, H.; ADDINALL, E.; PERCIVAL, F. A handbook of game design. [S.l.]: Kogan
Page, 1982.

FERRAZ, F. Eletropneumática. 2015. Disponível em: <https://fagnerferraz.files.wordpress.


com/2011/11/aula-eletropneumatica-fagner.pdf>. Acesso em: 22 mai. 2021.

FESTO. Manual Fluidsim 3.6. 2004. Disponível em: <https://tecnologiamecanica.files.


wordpress.com/2011/07/apostila-fluidsim-festo-pneumatica.pdf>. Acesso em: 12 mai. 2021.
FIALHO, A. B. Automação Pneumática Projetos, dimensionamento e análise de circuitos.
[S.l.]: Saraiva Educação SA, 2018.

FONSECA, M. de O. Comunicação opc–uma abordagem prática. 2002.

FRANCO, I. C. et al. Utilização do protocolo de comunicação ole for process control em


processos industriais. Exacta, Universidade Nove de Julho, v. 8, n. 3, p. 319–329, 2010.

GOMES, S. Eletropneumática e Eletro-hidráulica. 2020. Disponí-


vel em: <http://eletropneumaticaeeletrohidraulica.blogspot.com/2016/02/
aula-10-elementos-de-trabalho-pneumatico.html>. Acesso em: 22 mai. 2021.

HECK, G.; SOUZA, F. A. M. de; MANTOVANI, C. A. Utilização do software fluidsim


como material didático no ensino de fundamentos de automação industrial. Anais do Salão
Internacional de Ensino, Pesquisa e Extensão, v. 8, n. 2, 2016.

KNOWLEDGEBASE, E. O que são sistemas supervisórios? 2019. Disponível em:


<https://kb.elipse.com.br/o-que-sao-sistemas-supervisorios/>. Acesso em: 22 mai. 2021.

LEITÃO, G. Arquitetura e Implementação de um cliente OPC para aquisição de dados na


indústria do petróleo. 2006. Disponível em: <http://www.nupeg.ufrn.br/documentos_finais/
monografias_de_graduacao/monografias/gustavoleitao.pdf>. Acesso em: 14 jun. 2021.

LÉVY, P. Inteligência coletiva (A). [S.l.]: Edições Loyola, 2007.

LUNCE, L. M. Simulations: Bringing the benefits of situated learning to the traditional


classroom. Journal of Applied Educational Technology, v. 3, n. 1, p. 37–45, 2006.

MACIEL. Configurando o Elipse E3 como cliente OPC. 2003. Disponível em:


<https://kb.elipse.com.br/configurando-o-elipse-e3-como-cliente-opc/>. Acesso em: 08 jul.
2021.

MACIEL, S. Aula 2 - Método Maximização de Contatos (Cadeia Estacionária). 2000.


Disponível em: <https://drive.google.com/file/d/0B9tmI58MYGtpSFIzNzlLejRKcDA/view>.
Acesso em: 23 mai. 2021.

MARCIO. ACIONAMENTO E CIRCUITOS ELETROPNEUMÁTICOS. 2021. Disponível


em: <https://www.automacaoindustrial.info/opc-ua-na-automacao-industrial/>. Acesso em: 14
jun. 2021.

MARTINS, G. M. Princípios de automação industrial. Apostila da disciplina de automação


industrial da UFSM, Santa Maria, 2012.

MCGREGOR, I. The relationship between simulation and emulation. In: IEEE. Proceedings of
the Winter Simulation Conference. [S.l.], 2002. v. 2, p. 1683–1688.

MCGREW, R.; SAUL, J.; TEAGUE, C. Instructor’s Manual to Accompany Physics, for
Scientists and Engineers. [S.l.]: Harcourt College Pub., 2000.

MELENDEZ, W. A.; PETERSEN, E. L. The upper layers of the iso/osi reference model (part ii).
Computer Standards & Interfaces, Elsevier, v. 5, n. 2, p. 65–77, 1986.

MORAES, C. C.; CASTRUCCI, P. Engenharia de automação industrial. rio de janeiro: Ltcn,


2007. 2007.
MORAES, C. C. d.; CASTRUCCI, P. d. L. Engenharia de automação industrial. Rio de Janeiro:
LTC, v. 2, n. 1, p. 25, 2010.

NEVES, T. M. d. S. Virtualização de processos na Indústria 4.0. Tese (Doutorado), 2021.

OLIVEIRA, K. Pirâmide da Automação. 2012. Disponível em: <http://kleberautomation.


blogspot.com/2012/01/piramide-da-automacao.html>. Acesso em: 28 abr. 2021.

PEDROSO, B. Aula 8: Método de Maximização de Contatos. 2005. Disponível em:


<https://docplayer.com.br/141925067-Aula-8-metodo-de-maximizacao-de-contatos.html>.
Acesso em: 23 mai. 2021.

PRUDENTE, F. Automação IndustriaL PLC: Teoria E Aplicações . [S.l.]: Grupo Gen-LTC,


2000.

REIS, R. L. Uso de simulador para validação de sistema de segurança de uma planta industrial.
Universidade Federal da Bahia. Escola Politécnica, 2017.

REVISTAMT, M. M. e T. A instalação de válvulas solenoides. 2020. Disponível em:


<http://www.revistamt.com.br/Materias/Exibir/a-instalacao-de-valvulas-solenoides>. Acesso
em: 22 mai. 2021.

RIBEIRO, M. A. Automação industrial. Salvador:[sn], 1999.

ROMANO, M. Guia Definitivo: Entenda tudo sobre o que é OPC UA e como isso pode
impactar a sua indústria. 2019. Disponível em: <https://www.logiquesistemas.com.br/blog/
opc-ua/>. Acesso em: 16 jun. 2021.

SAKURADA, N.; MIYAKE, D. I. Aplicação de simuladores de eventos discretos no processo de


modelagem de sistemas de operações de serviços. Gestão & Produção, SciELO Brasil, v. 16,
n. 1, p. 25–43, 2009.

SANTONI, C. et al. A real-time interface simulator for operator’s training: a proposed


architecture. In: SCSC. [S.l.: s.n.], 2007. p. 460–467.

SILVA, A. P. G. D.; SALVADOR, M. O que são sistemas supervisórios? São Paulo, 2005.

SILVA, F. H. et al. Identificação e controle de uma planta de nível utilizando controlador lógico
programável. Anais da Sociedade Brasileira de Automática, v. 2, n. 1, 2020.

SILVA, R. F. P. Um controlador programável baseado em CoDeSys: estágio na Bresimar


Automação SA. Tese (Doutorado), 2017.

SOUZA, L. C.; PEREIRA, A. L. S. Estudo e aplicação de linguagens de programação utilizando


o software codesys. Instituto federal de educação, ciência e tecnologia de goiás, 2015.

SOUZA, L. C. A.; FILHO, C. S.; PENA, R. T. Padrão de acesso a dados opc e


sua implementação em um driver opc-modbus. In: II CONGRESSO MINEIRO
DE AUTOMAÇÃO, V SIMPÓSIO REGIONAL DE INSTRUMENTAÇÃO DA
ISA-BH/GRINST-MG. [S.l.: s.n.], 1998. p. 157–164.

UFPR. Simbologia Pneumática. 2015. Disponível em: <http://ftp.demec.ufpr.br/disciplinas/


EngMec_NOTURNO/TM372/Conte%FAdos/2%20Simbologia/Simbologia%20ABNT%
20resumo.pdf>. Acesso em: 28 mai. 2021.
VASCONCELOS, N. de O. et al. Análise comparativa entre os métodos “intuitivo” e “cascata”
para resolução de problemas em pneumática. 2015.

VENTURELLI, M. ACIONAMENTO E CIRCUITOS ELETROPNEUMÁTICOS. 2018.


Disponível em: <https://www.youtube.com/watch?v=NJkhZrEALxU&t=21s>. Acesso em: 14
jun. 2021.

VILLAS-BOAS, V.; NETO, O. M. Aprendizagem ativa na educação em engenharia. In:


Congresso Brasileiro de Educação em Engenharia,–COBENGE Blumenau. [S.l.: s.n.],
2011.
APÊNDICE A – PROGRAMAÇÃO EM LADDER NO CODESYS

Figura 84 – Programação Parte 1.

Fonte: Próprio Autor (2021).

Figura 85 – Programação Parte 2.

Fonte: Próprio Autor (2021).


Figura 86 – Programação Parte 3.

Fonte: Próprio Autor (2021).

Figura 87 – Programação Parte 4.

Fonte: Próprio Autor (2021).


Figura 88 – Programação Parte 5.

Fonte: Próprio Autor (2021).

Figura 89 – Programação Parte 6.

Fonte: Próprio Autor (2021).


Figura 90 – Programação Parte 7.

Fonte: Próprio Autor (2021).

Figura 91 – Programação Parte 8.

Fonte: Próprio Autor (2021).

Você também pode gostar