SERVIÇO PÚBLICO FEDERAL

MEC – SETEC
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE MATO
GROSSO – CAMPUS CUIABÁ
DEPARTAMENTO DA ÁREA DE ELETROELETRÔNICA
ENGENHARIA DE CONTROLE E AUTOMAÇÃO

JEAN KARLOS BRAZ DA LUZ

REPRESENTAÇÃO DE ESTAÇÃO DIDÁTICA EM AMBIENTE

DE SIMULAÇÃO E INTEGRAÇÃO COM SISTEMA DE
CONTROLE EMULADO

Cuiabá – MT
Outubro 2020
REPRESENTAÇÃO DE ESTAÇÃO DIDÁTICA EM UM AMBIENTE DE
SIMULAÇÃO E INTEGRAÇÃO COM SISTEMA DE CONTROLE
EMULADO

Trabalho de Conclusão de Curso

apresentado ao Departamento de
Eletroeletrônica do Curso de Bacharel em
Engenharia de Controle e Automação, do
Instituto Federal de Mato Grosso, como
exigência para a obtenção do título de
Bacharel em Engenharia de Controle e
Automação.

Orientador: Prof. Me. Marcelo Ferreira Arruda

Coorientador: Prof. Me. Edilson Alfredo da Silva

Cuiabá – MT
Outubro 2020
 Dados internacionais de catalogação na fonte

L979r Luz, Jean Karlos Braz da

Representação de estação didática em ambiente de simulação e integração com
sistema de controle emulado / Jean Karlos Braz da Luz – Cuiaba – MT, 2020.
62 f. : il. color.

Orientador(a) Prof. Me. Marcelo Ferreira Arruda

Co-orientador(a) Prof. Me. Edilson Alfredo da Silva
TCC (Graduação). (Bacharel em Engenharia de Controle e Automação) – Instituto
Federal de Educação, Ciência e Tecnologia de Mato Grosso, Campus Cuiabá, 2020.
Bibliografia incluída

1. Simulação. 2. Emulação. 3. Open Platform Communications (OPC). 4. Sistema de

Controle Automático. 5. Regime Domiciliar. I. Título.

Ficha catalográfica elaborada automaticamente de acordo com os dados fornecidos pelo(a) autor(a).

Bibliotecário(as): Jorge Nazareno Martins Costa (CRB1-3205)

Dedico este trabalho a minha noiva
Pamella Nascimento, que ao longo dessa
caminhada me apoiou em todos os
momentos desde quando estamos juntos,
e principalmente por ser quem me ensinou
a realizar.
 AGRADECIMENTOS

Meus primeiros agradecimentos são aos céus, Deus me agraciou com a

vida e com todos os momentos que me trouxeram ao fim da jornada desse curso.
Deus é bom o tempo todo.
Agradeço a meus pais, Noel Roza e Luiza Braz, que sempre apoiaram
minha carreira estudantil e acadêmica, se atentaram às necessidades que tive ao
longo da jornada, forneceram amparo e estrutura, para que eu permanecesse até o
fim.
Agradeço especialmente à minha noiva, Pamella Nascimento, que trouxe
motivação quando eu mais pensava em desistir, as pedras no caminho foram difíceis
de superar, mas com seu apoio, todas foram ficando para trás.
Agradeço a meu orientador, professor Marcelo Ferreira Arruda, por trazer
soluções para problemas aparentemente irresolúveis e por tornar esse trabalho
possível. Assim como ao professor Edilson Alfredo, por me apresentar o universo de
comandos elétricos e controladores lógicos programáveis, ainda no ensino médio.
Aos colegas de curso que fizeram dos estudos um momento de lazer, dos
momentos de lazer, motivos de aprendizado e por participarem dessa história, do
início ao fim, ou de parte dela.
Gratidão também ao Instituto Federal de Mato Grosso, onde estudo desde
o ensino médio, por proporcionar educação de qualidade e a oportunidade de
desenvolver senso crítico.
Ao Departamento de Eletroeletrônica - DAEE, o qual sou discente também
desde o ensino médio, que garantiu experiencias transformadoras.
E finalmente a todos os professores do Curso de Engenharia de Controle e
Automação, que através de seus ensinamentos colaboraram na formação de um
profissional, que carregará o nome da instituição para a vida.
“É bom que a jornada tenha um fim para
ir, mas no fim, o que importa é a jornada.”
Ursula K. Le Guin, 1969
 RESUMO

Tendo em vista benefícios de segurança e economia, uma busca contínua pela

possibilidade de que comissionamentos industriais sejam possíveis em um ambiente
totalmente virtual se desenvolve. Para isso, é importante a possibilidade de integração
entre um sistema de controle emulado e um ambiente de simulação, foi desenvolvido
então o procedimento para que ocorra a integração entre os sistemas, fazendo uso
da ferramenta computacional de simulação Arena e o controlador lógico programável
(CLP) MicroLogix 1200 emulado, ambos da Rockwell Automation, para tanto, a
interface de comunicação Open Platform Communications (OPC) é utilizada. Também
foi desenvolvida, utilizando o Arena, a representação de uma estação didática do
Sistema Modular de Produção da fabricante Festo, originalmente designada Modular
Production System (MPS), que simula fisicamente uma planta industrial separadora
de peças. Denota-se a possibilidade de representar em um ambiente de simulação
virtual a estação didática, validando a integração entre sistema de controle emulado e
ambiente de simulação, e possibilitando que tudo seja possível em regime domiciliar,
por se tratar de um comissionamento totalmente computacional.

Palavras-chave: Simulação, Emulação, Open Platform Communications (OPC),

Sistema de Controle Automático, Regime Domiciliar.
 ABSTRACT

In view of security and economy benefits, a continuous search for the possibility that
industrial commissioning is possible in a totally virtual environment develops. For this,
the possibility of integration between an emulated control system and a simulation
environment is important. The procedure for integration between the systems was
developed, using the Arena simulation computational tool and the programmable logic
controller (PLC) MicroLogix 1200 emulated, both from Rockwell Automation, for this
purpose, the Open Platform Communications (OPC) communication interface is used.
It was also developed, using Arena, the representation of a didactic station of the
Modular Production System (MPS) of the manufacturer Festo, which physically
simulates an industrial plant separating parts. It denotes the possibility of representing
the didactic station in a virtual simulation environment, validating the integration
between the emulated control system and the simulation environment, and making
everything possible in the home regime, as it is a fully computational commissioning.

Keywords: Simulation, Emulation, Open Platform Communications (OPC), Automatic

Control System, Home Regime.
 LISTA DE FIGURAS

Figura 1 — Diferentes possibilidades de comissionamento. ..................................... 14

Figura 2 — Ciclo de varredura de um controlador lógico programável. .................... 16
Figura 3 — Controlador MicroLogix 1200. ................................................................. 20
Figura 4 — Conjuntos componentes de uma estação MPS. ..................................... 22
Figura 5 — Estação Sorting e os componentes utilizados na representação. .......... 23
Figura 6 — Adicionando painel Advanced Process................................................... 25
Figura 7 — Modelo no Arena – pt.1. ......................................................................... 26
Figura 8 — Configuração do módulo Create “Pecas”................................................ 26
Figura 9 — Configuração do módulo Hold "Espaço da peça na barreira". ................ 27
Figura 10 — Configuração do módulo Decide "Diferentes pecas". ........................... 28
Figura 11 — Criando e configurando o atributo "Tipo" .............................................. 28
Figura 12 — Criando e configurando as variáveis no módulo Assign. ...................... 30
Figura 13 — Configuração do módulo Process “AtrasoLeituraSensor1” ................... 30
Figura 14 — Módulo Record de entrada ................................................................... 31
Figura 15 — Modelo no Arena – pt.2. ....................................................................... 31
Figura 16 — Configuração do módulo Hold "Barreira Pistao" ................................... 32
Figura 17 — Criando variáveis na tabela Variable. ................................................... 33
Figura 18 — Configuração do módulo Assign "LimpaSensPeca", alteração dos valores
das variáveis. ............................................................................................................ 33
Figura 19 — Configuração do módulo Signal. ........................................................... 34
Figura 20 — Configuração do módulo Create "Set01". ............................................. 35
Figura 21 — Criando os caminhos por condição no módulo Decide. ........................ 35
Figura 22 — Configuração dos módulos Create "Set" e Assign "Set sensor rampa".
.................................................................................................................................. 36
Figura 23 — Modelo no Arena – pt.3. ....................................................................... 36
Figura 24 — Configuração módulo Hold "AcionamentoAlavaca1" ............................ 37
Figura 25 — Modelo no Arena – pt.4. ....................................................................... 38
Figura 26 — Criando projeto no RSLogix 500. .......................................................... 39
Figura 27 — Fluxograma apresentando a lógica de programação............................ 40
Figura 28 — Linhas Ladder que tratam do tempo de análise e liberação das peças.
.................................................................................................................................. 41
Figura 29 — Lógica responsável pelo acionamento dos atuadores .......................... 41
Figura 30 — Resposta da rampa para recuar atuadores e liberar a esteira. ............. 42
Figura 31 — Como emular o CLP no RSLogix Emulate500. ..................................... 42
Figura 32 — Configuração do driver de rede no RSLinx Classic Gateway. .............. 43
Figura 33 — Download do programa para o CLP emulado. ...................................... 44
Figura 34 — Colocando o CLP emulado em modo Run. .......................................... 44
Figura 35 — Criando o tópico OPC para o CLP. ....................................................... 45
Figura 36 — Criando aplicação Integração. .............................................................. 46
Figura 37 – Criando o servidor OPC. ........................................................................ 46
Figura 38 – Criando a conexão no Arena. ................................................................. 47
Figura 39 — Tabela de variáveis, marcando I/O Port. .............................................. 47
Figura 40 — Conexão das variáveis do Arena às variáveis do CLP. ........................ 48
Figura 41 — Configurações Replication Parameters e Run Speed no Arena. .......... 49
Figura 42 — Adaptação do relatório de simulação, com registros dos módulos Record.
.................................................................................................................................. 51
Figura 43 — Registro de filas no relatório de simulação. .......................................... 52
 LISTA DE TABELAS

Tabela 1: Histórico da Tecnologia dos CLPs .......................................................... 15

Tabela 2: Leitura dos sensores e código que representa a característica da peça no
modelo simulado ..................................................................................................... 29
Tabela 3: Relação das variáveis criadas no CLP .................................................... 39
 LISTA DE ABREVIATURAS

CIs — Circuitos Integrados

CLP — Controlador Lógico Programável
CPU — Central Process Unit
COM — Component Object Model
Covid-19 — Corona virus desease-2019
DCOM — Distributed Component Object Model
IEC — International Electrotechnical Comission
I/O — Input / Output
MPS — Modular Production System
ms — Milissegundos
OLE — Object Linkind and Embedding
OPC — Open Platform Communications
s — Segundos
 SUMÁRIO

1. INTRODUÇÃO .................................................................................................... 12

1.1. Contextualização ....................................................................................................... 12

1.2. Objetivos ................................................................................................................... 13
2. REVISÃO DE LITERATURA ............................................................................... 14

2.1. Simulação e Emulação .............................................................................................. 14

2.2. Controladores ............................................................................................................ 15
2.3. Sistema de Comunicação – Interface OPC ............................................................... 18
3. MATERIAIS ........................................................................................................ 20

3.1. Plataforma de Simulação .......................................................................................... 20

3.2. Sistema de Controle Emulado ................................................................................... 20
3.3. Comunicação e Integração ........................................................................................ 21
3.4. Sistema Modular de Produção – Festo ...................................................................... 21
4. METODOLOGIA E DESENVOLVIMENTO ......................................................... 24

4.1. Desenvolvendo modelo para a simulação ................................................................. 24

4.2. Programação em CLP e emulação ............................................................................ 38
4.3. Realizando a integração entre ambiente simulado e CLP emulado ........................... 43
5. RESULTADOS OBTIDOS .................................................................................. 50

6. CONCLUSÃO ..................................................................................................... 53

7. REFERÊNCIAS .................................................................................................. 55

APÊNDICES.............................................................................................................. 58

A – Modelo criado no Arena na íntegra. ........................................................................... 58

B – Programa no MicroLogix 500 em Ladder na íntegra. ................................................. 59
 12

1. INTRODUÇÃO

1.1. Contextualização
Historicamente, relata Marson (2014) que, o processo fabril é base para
aceleração e crescimento econômico de diversos setores, exercendo a partir da
industrialização um impacto dinâmico e transformador, incorporando novos processos
produtivos.
Os grandes avanços industriais podem ser marcados na história pelas grandes
conquistas de cada época. Para Marson (2014), na primeira revolução industrial, um
dos avanços mais significativos foi indústria mecânica, capaz de criar máquinas de
grande porte que poderiam produzir outras máquinas.
O período considerado a segunda revolução industrial, entre meados dos
séculos - XIX e XX, trouxe avanços importantes para a indústria por meio da
informática, para Branco (2020), período impulsionado pelo aprimoramento de
produtos e a comercialização de invenções que ainda são populares de certo modo.
Já no contexto da terceira revolução industrial, a partir de meados do século
XX, surgem os controladores lógicos programáveis, e que Baptista (2011) descreve
como “um computador projetado para trabalhar no ambiente industrial”.
O ambiente industrial exige um dinamismo cada vez maior ao longo dos anos,
Slota e Malopolski (2007) discutem que sistemas de manufatura que sejam realmente
flexíveis, são meios de alcançar uma produção, tempo e custos eficientes.
Slota e Malopolski (2007) apresentaram algumas problemáticas que esse
dinamismo pode trazer, como a necessidade de trocar recursos da linha de produção
e com isso, máquinas podem ficar temporariamente indisponíveis, podem falhar
devido a mudanças, e testes com os meios físicos instalados podem ameaçar a
segurança de colaboradores. Todas essas situações afetam a eficiência da produção,
o que favorece o uso de técnicas para analisar o sistema, sem que o mesmo seja
alterado.
O uso de simulação computacional é cada vez mais frequente, mas foram
necessários quase 40 anos, como destaca Baptista (2011), para que essa integração
fosse possível, principalmente devido aos altos custos que essa tecnologia
demandava em seus períodos iniciais.
O desenvolvimento de mecanismos que possibilitem a integração entre
sistemas de controle e modelos de simulação para Bastos et. al. (2010), é uma procura
 13

de empresas e pesquisadores.

Outro método de comissionamento conhecido, é a possibilidade de simular

fisicamente uma planta industrial, fazendo uso de protótipos em menor escala. Essa
abordagem tem grande importância no ambiente acadêmico pois possibilita
transportar o estudante para um ambiente industrial, antes mesmo de estar presente
nele, aprimorando o conhecimento de campo daquele que desenvolve atividades
nessas plataformas.

1.2. Objetivos
Baseando-se neste cenário, este trabalho tem por objetivo geral denotar um
método de integração entre um controlador lógico programável, nesse caso, o
MicroLogix 1200 emulado, sendo este o sistema de controle, e a ferramenta
computacional Arena, sendo o ambiente de simulação, por meio do protocolo
desenvolvido para possibilitar a integração.
E os objetivos específicos são:
 Realizar uma revisão bibliográfica sobre simulação, emulação, CLPs e a
interface OPC;
 Desenvolver a representação de uma estação didática de manufatura da
Festo, que simula fisicamente uma planta industrial separadora, no
ambiente de simulação computacional, e validar a integração e o modelo
no ambiente de simulação, fazendo uso dos relatórios emitidos pelo
Arena.
 14

2. REVISÃO DE LITERATURA

2.1. Simulação e Emulação

Na evolução da ciência industrial a simulação e a emulação tornaram-se
vitais no comissionamento de processos dizem Dzinic e Yao (2013), sendo termos
cada vez mais associados ao uso de ferramentas computacionais.
Na computação, para Moura, Walczack e Moura (2019), simulação significa
expressar de maneiras formais, matemáticas ou específicas uma operação ou
procedimento do mundo real. Com isso, segundo Dos Santos (1999), pode-se criar
uma história artificial do sistema e a partir desta, inferir como o sistema real
funcionaria.
Como apresenta Bellé (2011), simulação e emulação têm significados
muito semelhantes, imitar e comportar-se como alguma coisa, respectivamente. Mas
na computação os termos se distanciam ao atribuir à emulação, segundo Hasnan
(2005), o uso de uma simulação a fim de substituir um sistema físico, obtendo as
mesmas respostas, sendo assim, a emulação é um sistema virtual capaz de responder
tal como o sistema físico, possibilitando a substituição do mesmo para testes.
Como ressaltam Smith e Cho (2008), muitos autores sugerem diferentes
métodos que combinam realidade e simulação para testes. Métodos baseados nessas
combinações são mostrados na Figura 1.

Figura 1 — Diferentes possibilidades de comissionamento.

Fonte: Adaptado de Smith e Cho, 2008.

Baptista (2011) explica cada um dos métodos apresentados na Figura 1

através do trabalho de Auinger (1999).
 15

Segundo Auinger (1999), para testar sistemas de controle, as possíveis

combinações entre realidade e simulação, isto é, entre objetos do
mundo real e modelos de simulação (mundo simulado), podem ser
divididas em quatro:
(1) Teste Tradicional: quando o controle e a planta (ou processo) são
reais;
(2) Emulação (Soft-Commissioning): quando o controle é real e a planta
é simulada;
(3) Realidade no Laço (Reality in the Loop): quando o controle é
simulado e a planta é real;
(4) Simulação Off-line: quando o controle e a planta são simulados.

2.2. Controladores
Como cita Da Silva (2007), Controladores Lógicos Programáveis (CLP) são
equipamentos eletrônico-digitais compatíveis a aplicações industriais. São evoluções
dos antigos painéis elétricos, possibilitando o dinamismo na mudança da lógica do
processo que depende do dispositivo, algo antes impossível, pois os painéis eram
fixos.
Ainda segundo Da Silva (2007), os CLPs só se tornaram possíveis com o
advento dos circuitos integrados (CIs). A partir dessa evolução, no ano de 1968, a
divisão de hidramáticos da General Motors desenvolveu o primeiro CLP. Apresenta-
se na Tabela 1 uma relação do avanço dessa tecnologia.

Tabela 1 – Histórico da Tecnologia dos CLPs

1ª Geração Programação em Assembly. Era necessário conhecer o hardware

do equipamento, ou seja, a eletrônica do projeto do CLP.

2ª Geração Apareceram as linguagens de programação de nível médio. Foi

desenvolvido o “Programa monitor” que transformava para
linguagem de máquina o programa inserido pelo usuário.

3ª Geração Os CLPs passam a ter uma entrada de programação que era feita
através de um teclado, ou programador portátil, conectado ao
mesmo.

4ª Geração É introduzida uma entrada para comunicação serial, e a

programação passa a ser feita através de microcomputadores.
Com este advento surgiu a possibilidade de testar o programa
antes do mesmo ser transferido ao módulo do CLP, propriamente
dito.

5ª Geração Os CLPs de quinta geração vêm com padrões de protocolo de

comunicação para facilitar a interface com equipamentos de
outros fabricantes, e também com Sistemas Supervisórios e
Redes Internas de comunicação.

Fonte: Adaptado de Da Silva, 2007.

 16

O funcionamento dos controladores se dá de forma sequencial por um sistema

de varreduras, estas ocorrem por etapas, sendo a velocidade de processamento um
parâmetro importante, já que cada etapa é um ciclo de processamento, como comenta
Da Silva (2007). Na Figura 2, pode-se observar um fluxograma que representa o ciclo
de varredura de um CLP.

Figura 2 — Ciclo de varredura de um controlador lógico programável.

Fonte: Da Silva, 2007.

As etapas apresentadas no ciclo de varredura na Figura 2 são explicadas por

Da Silva (2007).
Início: Verifica o funcionamento da CPU, memórias, circuitos auxiliares,
estado das chaves, existência de um programa de usuário, emite aviso de
erro em caso de falha. Desativa todas as saídas.

Verifica o estado das entradas: Lê cada uma das entradas, verificando se

houve acionamento. O processo é chamado de ciclo de varredura.

Compara com o programa do usuário: Através das instruções do usuário

sobre qual ação tomar em caso de acionamento das entradas o CLP atualiza
a memória imagem das saídas.

Atualiza as saídas: As saídas são acionadas ou desativadas conforme a

determinação da CPU. Um novo ciclo é iniciado.
 17

Para que se possa realizar tarefas com um CLP, é necessário programá-lo. No

contexto de que são dispositivos desenvolvidos para substituir os comandos elétricos,
é necessário representar esses comandos em forma de linguagem de programação.
A principal linguagem de programação para CLPs, a mais reconhecida, é a
programação Ladder. Desenvolvida de modo a representar os diagramas elétricos
antes utilizados nos projetos de comandos, vem a ser uma linguagem gráfica em que
segundo Faustino (2005), "a lógica a ser executada pelo controlador é descrita por um
diagrama de interligação de contatos e bobinas".
A forma como esse diagrama fica organizado lembra uma escada, sendo a
origem do nome Ladder, que em inglês significa escada, como comenta Da Silva
(2007).
Através da linguagem de programação Ladder, a popularização do uso de
CLPs foi impulsionada, devido principalmente a essa semelhança entre os diagramas
elétricos utilizados anteriormente, como explica Faustino (2005), essa linguagem
permitiu uma transição muito suave de tecnologia, mesmo sendo um método
extremamente disruptivo em vista dos painéis elétricos tradicionais.
Conforme avançavam as tecnologias industriais e o número de empresas
fornecendo CLPs crescia, vários fabricantes de CLP foram criando métodos próprios
de implementar o Ladder, introduzindo pequenas mudanças. A maturidade de um
ramo industrial, segundo Lewis (1995), pode ser verificada quando os vários
representantes desse ramo sentem a necessidade de padronizações, e esse ponto
chegou para a automação no ano de 1979, quando segundo Faustino (2005), a IEC
(International Electrotechnical Comission) começou a definir o que viria a ser a Norma
IEC61131, a primeira a receber aceitação internacional no meio industrial.
Ainda segundo Faustino (2005), o grupo que foi designado como força tarefa-3
recebeu como principal objetivo desenvolver o novo padrão para linguagens de
programação dos CLPs, por fim desenvolvendo muito mais um guia para programação
que um conjunto de normas rígidas, dizem John et. al. (2001), ficando conhecida como
Norma IEC61131-3.
O resultado desse trabalho, a Norma IEC61131, define vários requisitos tanto
de software quanto de hardware, que ao cumprir com um número suficientes deles,
um dispositivo pode ser chamado CLP.
 18

2.3. Sistema de Comunicação – Interface OPC

O mercado globalizado, proveniente dos vários anos de avanço tecnológico
criou a necessidade de uma indústria cada vez mais adaptativa, como destaca Zhang
(2010), produtos industrializados sofrem requisições de mudanças contínuas pelos
clientes devido a esse cenário. Fato esse que, como ressalta Baptista (2011),
influencia significativamente a estratégia de produção de cada fabricante, exigindo
mudanças operacionais logísticas, físicas e de controle do chão de fábrica.
Para ajustar-se às demandas do mercado, de modo a não perder espaço para
concorrentes, novos ou antigos, melhores adaptados, o próprio chão de fábrica pode
passar por mudanças. Tais como cita Baptista (2011), reprogramação dos
instrumentos e equipamentos, mudanças na força de trabalho, introdução de novos
equipamentos, todos processos que incorrem custos, sejam estes materiais ou
operacionais.
A redução desses custos é uma estratégia desejável, sendo assim, segundo
Baptista (2011), a integração e comunicação entre um ambiente simulado e um
sistema de controle real (ou emulado) é válida principalmente para testar diferentes
estratégias de controle, analisar condições de operabilidade, de modo que a planta,
ou o chão de fábrica, não precisem ser afetados.
Para se dar a integração desses ambientes virtuais, ou mesmo de um ambiente
virtual e outro real, é necessário um sistema de comunicação, um método para que
todas as partes do todo, sejam capazes de trocar dados.
Na década de 90, segundo OPC Fundation (2018), o sistema operacional
Microsoft dominava o mercado de automação industrial, o que levou os fabricantes a
adotarem a tecnologia de comunicação Component Object Model (COM) e Distributed
COM (DCOM). Segundo Macoratti (2010), COM é a implementação do Object Linkind
and Embedding (OLE), “uma tecnologia que define um procedimento padronizado em
que um módulo cliente e um módulo servidor podem se comunicar através de uma
determinada interface”. Já DCOM, é o método que usa COM em sistema distribuído,
ou seja, sendo executado em mais de um computador simultaneamente.
Porém, a comunicação através desses métodos não era uniforme para todos
os fabricantes, o que influenciou os fornecedores Fisher-Rosemount, Intellution, Opto
22 e Rockwell Software a formarem uma força tarefa a fim de desenvolver uma
interface de dados baseada em DCOM, mas que fosse padronizada, chegando à
criação do OLE for Process Control (OPC). Esses eventos culminaram em 1996, na
 19

criação da Fundação OPC, responsável por certificar, validar, formalizar e organizar a

utilização dessa interface.
Como elucida a OPC Fundation (2020):
OPC é o padrão de interoperabilidade para a troca segura e confiável de
dados no espaço de automação industrial e em outras indústrias. É
independente de plataforma e garante o fluxo contínuo de informações entre
dispositivos de vários fornecedores. A OPC Foundation é responsável pelo
desenvolvimento e manutenção deste padrão.

Após doze anos de fundação, segundo Mahnke, Leitner e Damm (2009), a OPC
Fundation possuía mais de 450 membros, com mais de 1500 produtos diferentes
baseados em OPC listados e mais de 2500 fornecedores. Todos eles capazes de
trocar dados simples ou complexos, alarmes e eventos entre si.
 20

3. MATERIAIS

3.1. Plataforma de Simulação

Lançado pela Systems Modeling em 1992, para Prado (2014) o Arena, hoje
distribuído pela Rockwell Automation é o software mais utilizado para simulação, seja
em empresas ou instituições de ensino, considerado o mais popular no Brasil.
Trata-se de um ambiente gráfico de desenvolvimento, que segundo
Gonçalves (2010) “é ao mesmo tempo uma linguagem de simulação e um ambiente
de trabalho e experimentação”. Possibilita teste de modelos, gera relatórios de
resultados relacionados aos processos e possui recursos de animação integrados.
Essa foi a plataforma escolhida para realizar a integração, em sua versão 14.

3.2. Sistema de Controle Emulado

O sistema de controle emulado foi o CLP Micrologix 1200, série C, da fabricante
Allen Bradley, marca que hoje pertence à Rockwell Automation. Este modelo foi
escolhido por existir um disponível no campus institucional, que pode ser visto na
Figura 3, possibilitando que em trabalhos futuros ele seja utilizado em substituição ao
emulado. Comprovando também que a aquisição de um CLP não é necessária para
que os testes possam ocorrer em ambiente emulado.

Figura 3 — Controlador MicroLogix 1200.

Fonte: Próprio autor, 2020.

O Micrologix 1200 é um modelo considerado compacto, que possui vinte e

quatro entradas digitais ou DC inputs e dezesseis saídas digitais a relé, ou Relay
outputs.
 21

A emulação se deu através do software RSLogix Emulate500, também da

empresa Rockwell Automation, este cria um controlador virtual capaz de realizar as
tarefas do controlador real, e responder como tal.
Para a programação do controlador emulado, o software utilizado foi o RSLogix
500, plataforma também da Rockwell Automation, capaz de configurar e programar
controladores MicroLogix e outros modelos.

3.3. Comunicação e Integração

Os softwares necessários para a integração entre as plataformas de simulação
e de controle emulados foram o RSLinx Classic Gateway e o FactoryTalk
Administration Console.
O RSLinx Classic Gateway é o software Rockwell Automation responsável pela
comunicação entre dispositivos, principalmente a comunicação entre CLPs e entre
rede de computadores com CLPs, mas também é possível utilizar o OPC para se
comunicar com outros recursos que possibilitem integração por meio dessa interface.
Através da interface OPC, é possível criar um servidor onde diferentes
dispositivos, que não necessariamente são de um mesmo fabricante, podem trocar
dados. Segundo Wikidot (2016), o servidor OPC possui os drivers dos dispositivos
suportados e disponibiliza o acesso aos dados que esses dispositivos estão
configurados para permitir a interação com aplicações externas via leitura ou escrita.
E o software FactoryTalk Administration Console é o responsável pela criação do
servidor OPC utilizado na integração.

3.4. Sistema Modular de Produção – Festo

Para realizar a integração proposta, escolheu-se um produto conhecido para
que fosse representado na plataforma de simulação. Trata-se de uma estação do
Sistema Modular de Produção ou Modular Production System (MPS) da fabricante
Festo.
O MPS é uma plataforma didática que visa representar plantas industriais
diversas em estações próprias, que segundo Pola (2015), cada estação é dividida em
quatro conjuntos. Como pode ser visto na Figura 4.
 22

Figura 4 — Conjuntos componentes de uma estação MPS.

Fonte: Pola, 2015.

Onde:
1. Planta, é o componente que representa o chão de fábrica do processo
daquela estação;
2. Painel de controle, é uma plataforma de interação homem máquina, para
realizar comandos locais;
3. Gabinete móvel;
4. Controlador, é o CLP instalado na estação para desenvolvimento de
programas.
A estação escolhida para a simulação foi a Sorting, que representa um
processo de separação de peças ou produtos, de acordo com suas características.
Peças que são divididas em três tipos: metálicas, vermelhas e pretas. É importante
ressaltar que a fim de simplificar a transposição, não foram considerados todos os
componentes dessa estação para a representação do sistema que foi simulado, pois
desejava-se realizar apenas o processo de separação, sem envolver etapas
anteriores. Sendo assim, os componentes representados foram:
 Sensor indutivo, responsável por detectar se a peça é metálica;
 Sensor óptico difuso, um responsável por detectar se há uma peça em
determinada posição da esteira, outro por verificar se a peça é ou não, preta;
 Módulo atuador de parada, um pistão eletro pneumático responsável por
parar a peça em determinada posição;
 Esteira transportadora;
 Módulo desviador; uma alavanca comandada por atuador linear eletro
 23

pneumático, responsável por desviar as peças do curso da esteira, para a

rampa;
 Rampas;
 Sensor retro reflexivo; responsável por determinar se alguma peça
desceu uma das rampas.
Todos os componentes utilizados no modelo de simulação podem ser vistos na
Figura 5, cujo a nomenclatura corresponde à apresentada por Pola (2015). O princípio
de funcionamento de cada um, seja atuador ou sensor, não são pontos de interesse
relevantes, e o que mais considera-se necessário é explicado em seções posteriores,
importa mais o papel que eles cumprem e como o cumprem, através da interpretação
dos dados de entrada e saída envolvidos.

Figura 5 — Estação Sorting e os componentes utilizados na representação.

Fonte: Próprio autor, 2020.
 24

4. METODOLOGIA E DESENVOLVIMENTO

A metodologia para o desenvolvimento desse projeto ocorreu inicialmente em

duas etapas: a primeira etapa trata-se de uma revisão da literatura e a segunda etapa,
do desenvolvimento do modelo de simulação, programação em CLP e integração
entre as plataformas.
Durante a primeira etapa, são apresentados conceitos básicos sobre
simulação, emulação, controladores lógicos programáveis e a interface de
comunicação OPC. Ainda dentro da primeira etapa, há a apresentação dos softwares
utilizados para tornar a execução possível. Já durante a segunda etapa é apresentado
o desenvolvimento da integração proposta, com o protocolo que torna possível a sua
reprodução e posteriormente apresenta-se os resultados obtidos.
O critério de inclusão para seleção das referências, foram os detalhes nas
informações relacionadas aos assuntos tratados, de modo a sustentar o texto em um
contexto histórico e de pesquisa.

4.1. Desenvolvendo modelo para a simulação

No software Arena, os projetos são chamados modelos. Para que um modelo
seja criado, basta iniciar o software.
Os fluxogramas que são a forma de programação dos modelos no Arena, são
criados utilizando módulos, então, deve-se anexar os painéis modelo que
disponibilizem os módulos que serão necessários.
Foram utilizados recursos dos painéis Basic Process e Advanced Process, para
incluí-los os passos são: File  Template Panel  Attach  Basic Process (para o
painel básico) ou Advanced Process (para o painel avançado). O processo aqui
descrito, para adicionar um novo painel, pode ser visto na Figura 6. É comum que o
Arena já abra com o painel Basic Process disponível.
 25

Figura 6 — Adicionando painel Advanced Process.

Fonte: Próprio autor, 2020.

Todo fluxo inicia-se com o módulo Create e encerra-se com o módulo Dispose,
o módulo Create é responsável pela criação das entidades que circularão pelo
processo, e Dispose é responsável por retirá-las do fluxo. Não necessariamente existe
apenas um de cada para o fluxo, mas é necessário que todo fluxo finde em um
Dispose. Estes são módulos do painel Basic Process.
Outros módulos do painel Basic Process utilizados foram: Process, principal
método de processamento na simulação, com opções de captura (seize) e liberação
(release); Decide, responsável por processar tomadas de decisão; Assign,
responsável por atribuir características às entidades, ou valores a variáveis; e Record,
recurso de coleta de dados durante o fluxo.
Os módulos do painel Advanced Process utilizados foram: Hold, que mantem a
entidade em uma fila, aguardando por um sinal ou uma condição; e Signal,
responsável por enviar um sinal a um módulo Hold, com propósito de mover uma
entidade antes parada na fila.
Segue-se então, nas Figuras 7 a 25, o desenvolvimento da representação da
estação didática no Arena.
 26

Figura 7 — Modelo no Arena – pt.1.

Fonte: Próprio autor, 2020.

O módulo Create com o nome “Pecas” (o Arena não aceita símbolos como “ç”
ou acentos) que pode ser visto na Figura 7, cria vários exemplares da entidade Peca.
Para configurar um módulo no Arena, pode-se dar dois clicks sobre ele, a configuração
escolhida para o módulo Create Pecas foi: Entity type: Pecas, isso determina o nome
do tipo da entidade que circulará no processo; Time between arrives: type - constant,
value – 1, units – seconds; Entities per arrival – 1, Max arrivals – infinite, first creation
– 0.0. Deste modo, o modelo representa que a cada 1 segundo uma peça será
depositada na entrada da esteira, a primeira peça é depositada no tempo 0,0s da
simulação e serão criadas peças infinitamente enquanto a simulação rodar.

Figura 8 — Configuração do módulo Create “Pecas”.

Fonte: Próprio autor, 2020.

O módulo Hold “Fila para ocupar espaco na barreira” representa o espaço que
a peça ocupa na esteira, enquanto o pistão bloquear o caminho da peça. Na estação
real, a fila que poderia se formar teria tamanho finito entre duas a três peças, no
modelo simulado essa fila tem tamanho indeterminado, sendo limitada apenas pela
versão utilizada do software Arena, pois se trata da versão livre, para estudantes, que
impede que o processo como um todo tenha mais que 150 entidades circulando
 27

simultaneamente. A configuração desse módulo foi: Type – Wait for a Signal; Wait for
Value – 1; Limit – 1; Queue Type – Queue; Queue Name – Espaco da peca na
barreira.queue. Assim, o módulo irá manter a entidade peça em sua própria fila, até
que receba um sinal igual a 1 de um módulo Signal, quando esse sinal ocorrer, apenas
uma entidade será movida da fila para o fluxo. Isso representa o fato de a esteira
suportar apenas uma peça por vez.

Figura 9 — Configuração do módulo Hold "Espaço da peça na barreira".

Fonte: Próprio autor, 2020.

O módulo Decide: “Diferentes Pecas” fará com que a entidade peça até então
não caracterizada, seja direcionada para um caminho que definirá dentro da
simulação qual a sua característica. As chances de que uma peça seja preta,
vermelha, ou metálica são de 33% para cada. Isso ocorre através da configuração:
Type – N-ways by condition; Percenteges: 33. É necessário criar três caminhos de
33%. No Arena isso faz com que a entidade seja necessariamente direcionada a um
desses caminhos, isso representa a aleatoriedade na entrada das peças, tendo
chances iguais de ocorrência para cada um dos três tipos.
Na Figura 10, é mostrado como adicionar caminhos por condições em um
módulo Decide, através da configuração feita no módulo “Diferentes Pecas”.
 28

Figura 10 — Configuração do módulo Decide "Diferentes pecas".

Fonte: Próprio autor, 2020.

Após o módulo “Diferentes Pecas” há três caminhos, cada um deles leva a um

módulo Assign. Ao entrar no módulo, ocorrem dois processos, o primeiro é a entidade
peça receber o atributo, definido com um código, que corresponde a seu tipo (nome
dado ao atributo), seja preta, vermelha ou metálica. Configuração que pode ser vista
na Figura 11.

Figura 11 — Criando e configurando o atributo "Tipo"

Fonte: Próprio autor, 2020.
 29

Para o código atribuído a New Value, foi utilizada a relação que a peça tem com
os sensores que ela aciona na estação real, e feita a conversão dessa relação em
código binário, para hexa decimal, como demonstrado na tabela 2.

Tabela 2 – Leitura dos sensores e código que representa a característica

da peça no modelo simulado.

Sensor Sensor Sensor Preta Vermelha Metálica Código

Ótico difuso Ótico Indutivo
(presença) difuso (cor
não preta)
1 0 0 X 4

1 1 0 X 6

1 1 1 X 7

Fonte: Próprio autor, 2020.

O segundo processo nos blocos Assign que podem ser vistos na Figura 7 é a
mudança dos valores das variáveis que correspondem a leitura dos sensores. Para
representar os sensores de identificação das peças, na simulação, foram criadas três
variáveis de saída no Arena: SensorPres, sensor ótico difuso responsável pela leitura
de presença, se há uma peça no espaço logo atrás da barreira; SensorCor, sensor
ótico difuso responsável pela leitura de cor da peça, sendo acionado quando a peça
não é preta; e SensorMag, sensor indutivo que identifica se a peça é metálica.
Portanto cada módulo Assign define essas variáveis de acordo com o que é
apresentado na tabela 2.
É apresentado na Figura 12 o processo de criação de variáveis diretamente do
módulo Assign, e seus respectivos valores.
 30

Figura 12 — Criando e configurando as variáveis no módulo Assign.

Fonte: Próprio autor, 2020.

Para os casos das peças vermelha e metálica, antes do módulo Assign, há

ainda um módulo Process, que simulam o tempo que os sensores levam para que a
identificação esteja completa, isso ocorre pois a peça não entra no alcance de todos
os sensores simultaneamente, portanto a leitura não ocorre simultaneamente para os
três, o primeiro a responder é o SensorPres, por isso não se insere um módulo,
indicando atraso zero, configura-se o módulo Process “AtrasoLeituraSensor1” para o
SensorCor, com atraso de 200ms, depois configura-se o módulo Process
“AtrasoLeituraSensor2” para o SensorMag, com atraso de 500ms. Esses valores são
aproximados, pois não foi possível realizar um ensaio rigoroso para determiná-los.

Figura 13 — Configuração do módulo Process “AtrasoLeituraSensor1”.

Fonte: Próprio autor, 2020.
 31

Os módulos Record registram a quantidade de peças de cada cor

separadamente que passaram pelo processo de determinação do tipo, para que seja
possível comparar com as peças que foram processadas e posteriormente desceram
pelas suas determinadas rampas.

Figura 14 — Módulo Record de entrada.

Fonte: Próprio autor, 2020.

Foram configurados um módulo Record para cada tipo de peça, com o Type –
Count, com Value – 1. Deste modo, cada entidade que passa pelo módulo conta uma
unidade, e no relatório pós simulação, essa contagem ficará registrada em “EntrPecas
pretas” como pode ser visto na Figura 14, o exemplo para as peças pretas.

Figura 15 — Modelo no Arena – pt.2.

Fonte: Próprio autor, 2020.

Na Figura 15, o módulo Process “Ocupacao do espaco criado” representa o

tempo que uma peça leva percorrendo a esteira, para ocupar o espaço liberado em
frente ao pistão quando uma peça acabou de passar, sendo um atraso de 500ms. A
sua configuração se dá da mesma maneira que dos módulos Process
 32

“AtrasoLeituraSensor1” e “AtrasoLeituraSensor1”, que podem ser vistos na Figura 13,

apresentada anteriormente.
O módulo seguinte, “Barreira pistao”, é um módulo Hold, com a configuração:
Type – Scan for Condition; Condition – Barreira==0; Queue Type – Queue; Queue
Name – Barreira pistao.queue. Esta configuração faz com que a entidade permaneça
na fila do módulo até que a condição Barreira==0 seja lida. Barreira é a variável de
entrada criada para receber os dados do CLP, tal como o módulo atuador de parada
receberia na realidade. O sinal aguardado é 0, pois o funcionamento do atuador é
normalmente recuado, liberando o caminho para a peça. Entende-se por sinal ou
posição normal, o estado de repouso do sensor ou atuador, estado em que o
dispositivo não está atuado.

Figura 16 — Configuração do módulo Hold "Barreira Pistao".

Fonte: Próprio autor, 2020.

Nesse caso, a variável não é declarada ao dar seu nome dentro do módulo,
diferente do que ocorre com variáveis criadas no módulo Assign. Portanto é
necessário navegar pelo painel Basic Process, selecionar a tabela Variable, inserir
uma nova linha, com um duplo click na área indicada, e então renomear a variável
criada automaticamente, para “Barreira”, como visto na Figura 17. Os outros itens
disponíveis para configuração não foram utilizados nesse momento.
 33

Figura 17 — Criando variáveis na tabela Variable.

Fonte: Próprio autor, 2020.

Após passar pelo módulo “Barreira pistao”, a entidade peça entra no módulo
Process “Passagem da peca”, que simula o tempo que a peça leva para percorrer o
espaço na esteira necessário para que não seja mais bloqueada pela barreira. É,
portanto, um processo de atraso, com o mesmo tempo e configuração de “Ocupacao
do espaço criado”, 500ms.
“LimpaSensPeca” é um módulo Assign, que altera as variáveis de sensor para
0, considerando que a peça saiu de seus alcances de leitura, e sua configuração é
apresentada na Figura 18.

Figura 18 — Configuração do módulo Assign "LimpaSensPeca", alteração dos valores das

variáveis.
Fonte: Próprio autor, 2020.
 34

Em seguida, o que em tempo real ocorre simultaneamente com a mudança de

estados dos sensores, algo que a simulação imita, parando a contagem do tempo
enquanto a entidade passa de um módulo para o outro, caso não haja processos que
a parem ou a atrasem, há a liberação do espaço da esteira que fica antes da barreira,
processo realizado pelo módulo Signal “Indicacao que a peca desocupou o espaco”,
visto na Figura 19, que dá a condição para liberar apenas uma entidade da fila do
módulo “Espaco da peca na barreira”. Para isso configurou-se Signal Value – 1, pois
é o valor que o módulo Hold está aguardando e o Limit – 1, para que apenas uma
entidade possa ocupar o espaço que foi criado.

Figura 19 — Configuração do módulo Signal.

Fonte: Próprio autor, 2020.

Devido a esse espaço no ambiente simulado ser desocupado somente quando

uma entidade passou por ele, foi necessário criar um módulo Create, chamado
“Set01”, que determina que o espaço está livre para a primeira peça que chega ao
processo enviando uma única entidade ao módulo “Indicacao que a peca desocupou
o espaço”. A entidade que aciona esse sinal é genérica, ou seja, não sofreu nenhuma
alteração, criada após 1,0s de simulação, pois o módulo Hold só permite que sua fila
libere uma entidade, caso a mesma esteja ocupada, portanto há esse tempo de
espera, configuração que pode ser vista na Figura 20. A entidade criada em “Set01” é
removida do processo sendo desviada pelo módulo Decide em seguida, sendo movida
para o módulo Dispose 2.
 35

Figura 20 — Configuração do módulo Create "Set01".

Fonte: Próprio autor, 2020.

O módulo Decide “Separacao de pecas” mudará o caminho no fluxo da

simulação que a entidade peça tomará, de acordo com sua característica. É um
recurso que não coincide perfeitamente com a estação real, onde a peça só é
desviada pela alavanca e permanece no caminho da esteira, mas é um modo de fazer
com que a entidade seja direcionada para o módulo Record que representa a rampa
correta no modelo. Além disso, como mencionado anteriormente, também é desviada
a entidade genérica criada em “Set01”.
Para direcionar a peça para a rampa correta no modelo, o método utilizado é a
N-Way by Condition, onde a condição analisada é o atributo Tipo, de acordo com o
código que caracteriza a peça. Já para a remoção do fluxo principal da entidade
genérica, a condição utilizada foi o tipo de entidade. Essas configurações são vistas
na Figura 21.

Figura 21 — Criando os caminhos por condição no módulo Decide.

Fonte: Próprio autor, 2020.
 36

Ainda na Figura 15, são apresentados dois módulos que não são parte do fluxo
que representa a esteira, são eles o módulo Create “Set” e Assign “Set sensor rampa”.
O primeiro, cria uma entidade genérica no tempo 0,0s que ao passar pelo segundo,
muda a variável de saída SensorRamp para o valor 1, definindo assim seu estado
normal. A configuração desses dois módulos é apresentada na Figura 22.

Figura 22 — Configuração dos módulos Create "Set" e Assign "Set sensor rampa".
Fonte: Próprio autor, 2020.

Essa variável foi criada para representar o sensor retro reflexivo, que indica que
uma peça desceu por uma das rampas. O valor 1 é escrito pois o funcionamento do
sensor é um sinal normalmente alto, indo para sinal baixo quando uma peça passa
por ele. A entidade genérica gerada nesse ponto é então movida para o módulo
Dispose 2.

Figura 23 — Modelo no Arena – pt.3.

Fonte: Próprio autor, 2020.
 37

Os módulos Hold “AcionamentoAlavanca1” e “AcionamentoAlavanca2”

apresentados na Figura 23, aguardam pelo sinal que indica o acionamento dos
módulos desviadores. As variáveis envolvidas são as de entrada AlavancaR1 e
AlavancaR2, para o caminho onde a peça não é desviada, não há razão para o uso
do módulo. Com eles, a entidade peça só seguirá para o caminho determinado quando
a respectiva alavanca está acionada, um indicativo de problema na programação, é
quando as entidades param na fila de um desses módulos, o que significa que as
alavancas não foram acionadas corretamente. A configuração do módulo
“AcionamentoAlavanca1” é apresentada na Figura 24, sendo equivalente à
configuração do módulo “AcionamentoAlavanca2”.

Figura 24 — Configuração módulo Hold "AcionamentoAlavaca1".

Fonte: Próprio autor, 2020.

Como descrito anteriormente, é necessário seguir o procedimento apresentado

na Figura 17, pois inserir o nome das variáveis em um módulo Hold, não as criam no
ambiente de simulação, é necessário faze-lo manualmente.
Em seguida há módulos Process que representam o tempo que a peça leva
para percorrer a esteira e descer pela sua respectiva rampa. “TempEsteiraDireta” é
configurado com o tempo que a peça leva para percorrer a esteira sem desvios de
alavanca, sendo a rampa mais distante, chamada Rampa 3 e representada pelo
módulo Record, de mesmo nome, o tempo de atraso configurado é de 3,0s. Para o
módulo “TempEsteiraR1”, a configuração é de atraso de 1,0s, sendo o tempo da peça
na esteira quando desviada pela primeira alavanca, o que a leva para a Rampa 1, a
mais próxima, representada pelo módulo Record de mesmo nome. O mesmo ocorre
com o módulo “TempEsteiraR2” em relação a segunda alavanca e a rampa central,
Rampa 2, o tempo configurado é de 2,0s.
 38

Pode ser visto na Figura 25 o processo de descida das peças pelas suas
respectivas rampas.

Figura 25 — Modelo no Arena – pt.4.

Fonte: Próprio autor, 2020.

O módulo Assign “Leitura da rampa” altera a variável de saída SensorRamp

para 0, representando o momento que o sensor atua, quando uma peça desce
qualquer uma das três rampas. Depois ocorre um atraso no módulo Process
“AtrasoDescida”, que representa o tempo que a peça leva para sair do alcance do
sensor, configurado para 300ms. Depois disso a variável de saída SensorRamp
retorna para o estado normal igual a 1 no módulo Assign “LimpaSensRamp”, e
finalmente a entidade peça sai do fluxo de simulação pelo módulo Dispose 1,
encerrando assim o modelo da estação no ambiente de simulação Arena.
No Apêndice A apresenta-se o modelo criado no Arena na íntegra.

4.2. Programação em CLP e emulação

A linguagem de programação utilizada foi o Ladder, que segundo Da Silva
(2007), foi a primeira linguagem de programação criada para CLPs, se assemelhando
aos diagramas elétricos que eram desenhados para representar os comandos
elétricos, antes da invenção do CLP. Ao escolher o programa RSLogix 500, a
utilização de linguagem Ladder torna-se inevitável, já que é a única disponível.
Para criar um projeto no RSLogix 500, tendo o controlador escolhido como
base, seguiu-se os seguintes passos: File  New. Após selecionar essa opção, uma
janela se abre, onde pode-se preencher o Processor Name ou nome do processador,
que no RSLogix 500 pode ser também o nome do projeto, e escolher o controlador
que será utilizado.
 39

Figura 26 — Criando projeto no RSLogix 500.

Fonte: Próprio autor, 2020.

O programa foi pensado com a esteira em funcionamento, pois o foco estrutural

da lógica e do modelo foi exclusivamente a separação das peças. A escolha dos
nomes das variáveis foi feita a fim de corresponder com os nomes adotados no modelo
simulado. Isso não é um requisito, é um recurso utilizado para tentar reduzir a taxa de
erros no processo de integração. As variáveis do CLP podem ser vistas na Tabela 3.

Tabela 3 – Relação das variáveis criadas no CLP.

Entrada Saída
SensorPres Barreira
SensorCor AlavancaR1
SensorMag AlavacaR2
SensorRamp ----------------------------------

Fonte: Próprio autor, 2020.

É importante ressaltar que as variáveis criadas no Arena são do tipo real, o que
faz com que ocupem o espaço de 16 bits, mesmo que o dado a ser trocado seja do
tipo booleano. Isso limita a programação no âmbito da atribuição de variáveis, pois um
dado de sinal binário acaba por ocupar um espaço hexa decimal, com endereçamento
fixo. Algo que não seria um problema ao utilizar o software RSLogix 5000 Enterprise
Series, como demonstram Bastos et al. (2010), pois com ele é possível criar variáveis
 40

exclusivamente simbólicas, sem endereçamento, o que não é possível com RSLogix

500.
As variáveis que no Arena são de entrada, no CLP são de saída, assim como
as de saída são de entrada. Essas são as variáveis que farão parte da comunicação,
mas também foram criados temporizadores e variáveis auxiliares que podem ser
vistas posteriormente. Na Figura 27, é apresentada a lógica de programação por meio
de um fluxograma.

Figura 27 — Fluxograma apresentando a lógica de programação.

Fonte: Próprio autor, 2020.

O processo de identificação das peças é baseado nas respostas dos sensores

que estão no início da esteira, eles quem trazem a informação necessária para decidir
qual rampa receberá qual peça.
O primeiro processo tratado é o de análise da peça que chega à barreira.
Sabendo que algumas condições são necessárias para que as peças sejam
corretamente separadas, algumas atitudes foram tomadas.
Só é permitida a liberação de uma peça, caso não haja outra peça na esteira,
esse bloqueio é realizado pelos sinais enviados aos módulos desviadores que são
acionados de acordo com o tipo de peça, como a rampa três não possui desviador, foi
utilizado uma variável auxiliar.
Além disso, para uma correta separação das peças, é necessário garantir que
todos os sensores de identificação tenham atuado, se for o caso. Para isso, utiliza-se
do SensorPres como aquele que inicia o processo, por ser o que responde mais
rápido, este quando atuado aciona um temporizador com atraso suficiente para que
todos os sensores respondam, portanto, 850ms. Passado esse tempo o atuador de
 41

parada é recuado por 500ms, para que a peça passe. A programação em Ladder deste
procedimento pode ser verificado na Figura 28.

Figura 28 — Linhas Ladder que tratam do tempo de análise e liberação das peças.
Fonte: Próprio autor, 2020.

Enquanto o tempo de análise decorre, ocorre o acionamento do atuador que

determinará que rampa a peça seguirá, de acordo com os sensores que atuaram com
essa peça, essa lógica corresponde à relação apresentada na tabela 2 e pode ser
vista na Figura 29.

Figura 29 — Lógica responsável pelo acionamento dos atuadores.

Fonte: Próprio autor, 2020.

O tipo de bobina utilizado, é o Latch, que ao receber um sinal alto, muda o

estado da variável para alto, e mesmo que o sinal volte a ser baixo, a variável
permanece com sinal alto. É necessário que em outro momento a mesma variável
tenha uma bobina Unlatch, que muda o sinal para baixo.
 42

Tanto os atuadores como a variável auxiliar são retornadas para a posição

inicial, através da bobina Unlatch, com o sinal proveniente do SensorRamp, o que
pode ser visto na Figura 30, ou seja, quando uma peça desce uma das rampas. Isso,
atrelado à primeira linha do programa apresentado na Figura 28 e um tempo adequado
de recuo do módulo de parada, garantem que apenas uma peça estará na esteira
após a barreira. Com o tempo de análise para que todos sensores atuem, garante-se
também a qualidade da seleção das peças.

Figura 30 — Resposta da rampa para recuar atuadores e liberar a esteira.

Fonte: Próprio autor, 2020.

Com a programação feita, que pode ser visualizada na íntegra no Apêndice B,

com o código compilado e o projeto salvo, é possível através do software RSLogix
Emulate500 emular o controlador escolhido, procedimento demonstrado na Figura 31.

Figura 31 — Como emular o CLP no RSLogix Emulate500.

Fonte: Próprio autor, 2020.
 43

Deve-se escolher o número dado a estação, que posteriormente será a posição

do controlador na rede. Optou-se pela posição 01. Com isso feito, basta selecionar
OK, e o CLP emulado foi criado. Mas ainda não está em uso.

4.3. Realizando a integração entre ambiente simulado e CLP emulado

Para realizar a integração, o método desenvolvido segue de acordo ao
apresentado por Bastos et. al. (2010). Que consiste no mapeamento das variáveis de
entrada e saída do Arena e do CLP por meio de um servidor OPC.
A primeira etapa para isso, é estabelecer a rede no RSLinx Classic Gateway
que permitirá a comunicação entre o computador e o CLP emulado, depois do CLP
emulado com o servidor OPC.
Ao abrir o RSLinx Classic Gateway, selecionar Configure Driver abre a janela
para configurar um novo dispositivo. Nessa janela deve-se escolher o dispositivo que
será configurado, no caso o SLC 500 (DH485) Emulator Driver, que é o driver para
um CLP emulado no RSLogix Emulate500, depois selecionar Add new, o que abre a
janela para dar nome ao driver, onde optou-se por manter o padrão. Selecionando
OK, abre-se a janela onde se configura características do driver, a única modificada
foi o número da estação, que não é a mesma do CLP, pois a configurada nessa etapa
é a estação do driver de rede do CLP, optou-se pela posição 00 e nenhum nome foi
dado, conforme demonstrado na Figura 32. O status do driver deve estar em running
ao fim dessa configuração.

Figura 32 — Configuração do driver de rede no RSLinx Classic Gateway.

Fonte: Próprio autor, 2020.

Com essa configuração feita, pode-se retornar ao RSLogix 500 e realizar o

download do programa para o CLP emulado, o método para isso pode ser visto na
Figura 33. Para permanecer online e deixa-lo em modo Run, é necessário manter
 44

tanto o RSLinx Classic Gateway quanto o RSLogix Emulate500 abertos durante todo
o procedimento, já que o primeiro é o software responsável pela comunicação entre
computador e CLP, e o segundo, é o próprio CLP, mas emulado.

Figura 33 — Download do programa para o CLP emulado.

Fonte: Próprio autor, 2020.

Para deixar o CLP no modo Run, ou seja, iniciar seus ciclos de varredura, o
procedimento pode ser visto na Figura 34, basta um click na seta ao lado de Remote
Prog e então selecionar Run, uma janela que questiona se quer entrar neste modo
surge, então, basta confirmar.

Figura 34 — Colocando o CLP emulado em modo Run.

Fonte: Próprio autor, 2020.

A próxima etapa realizada foi criar o tópico OPC, onde o CLP lê e escreve os
dados compartilhados.
Para isso, no RSLinx Classic Gateway, seleciona-se DDE/OPC  Configure
Topic, que leva a janela de configuração de tópicos. Seleciona-se New para criar um
tópico e surgirá a opção de nomeá-lo, optou-se por dar o nome de Sorting, tal como a
estação simulada. Do lado direito dessa janela, deve-se selecionar através da árvore
 45

Workstation o controlador MicroLogix 1200, com ele marcado selecionar Done abrirá
uma caixa de diálogo perguntando se é desejado atualizar o tópico, portanto
seleciona-se Sim. Como pode ser visto na Figura 35.

Figura 35 — Criando o tópico OPC para o CLP.

Fonte: Próprio autor, 2020.

Com o tópico criado, deve-se configurar o servidor OPC com o qual esse tópico
trocará dados, assim como posteriormente o Arena. Essa configuração foi realizada
no software FactoryTalk Administration Console.
Ao abri-lo, uma caixa de diálogo aparece, questionando qual o diretório
desejado, utiliza-se a opção Network, pois nela é possível se comunicar com o Arena.
Em Network (This Computer) usar o botão direito do mouse apresenta a opção New
Aplication, essa aplicação será utilizada na integração, por isso deu-se o nome de
Integração. Como demonstrado na Figura 36.
 46

Figura 36 — Criando aplicação Integração.

Fonte: Próprio autor, 2020.

Com o botão direito do mouse, seleciona-se em Integração, a opção Add New

Data Server, onde é criado um servidor OPC, através da opção OPC Data Server, a
este foi dado o nome de MicroArena. Em OPC Server name (ProgID) seleciona-se
através do Browse o servidor RSLinx OPC Server, que é o se onde o tópico
anteriormente criado lê e escreve dados, tal como apresentado na Figura 37.

Figura 37 – Criando o servidor OPC.

Fonte: Próprio autor, 2020.

O último elemento da integração é a simulação, com o software Arena. Com o

mesmo aberto, seleciona-se Communications  Configure FactoryTalk Live Data
Connections. Isso leva a janela de configuração de conexões, seleciona-se Add para
criar uma. O que leva a uma janela onde deve-se indicar o FactoryTalk Directory
Scope, que corresponde a aplicação criada, ou seja, Integração, encontrada através
 47

do Browse. Os passos para tal são vistos na Figura 38.

Figura 38 – Criando a conexão no Arena.

Fonte: Próprio autor, 2020.

Com a conexão entre o Arena e o servidor OPC criada, é necessário relacionar

as variáveis do Arena às variáveis do CLP por meio desta conexão, o que é
apresentado na Figura 39. Para isso seleciona-se a tabela de variáveis em Basic
Process  Variables e marca-se a caixa de seleção I/O Port, liberando a opção de
escolher qual a utilização dessa variável, entrada ou saída (Input ou Output), o que
ocorreu de acordo com o necessário segundo o modelo e a programação do CLP.

Figura 39 — Tabela de variáveis, marcando I/O Port.

Fonte: Próprio autor, 2020.

Ao permitir o uso das variáveis como I/O Ports, elas ficam disponíveis em
Communications  Connect I/O. Abrindo uma aba na região inferior do Arena, então
realiza-se o processo de conexão. Em Connection seleciona-se a conexão que foi
criada anteriormente, não tendo alterado o nome, que foi o caso, chama-se
Connection 1. Em Connected To, para cada uma das variáveis, seleciona-se o espaço
vazio, depois o menu através do botão “…”. Isso leva à janela Tag Browser, onde
navegou-se até o endereço no CLP correspondente a variável selecionada, fazendo
 48

isso para todas as variáveis. Procedimento visualizado na Figura 40.

Figura 40 — Conexão das variáveis do Arena às variáveis do CLP.

Fonte: Próprio autor, 2020.

Encerrando as atividades de integração, é necessário ajustar as configurações

de simulação, para que ocorra em tempo real, e os dados possam ser trocados entre
simulação e CLP emulado, sem perdas.
Foi configurada a simulação no Arena através da seleção de Run  Setup.
Duas das abas disponíveis foram configuradas: Replication Parameters, onde são
tratados os parâmetros de replicação, como quanto tempo a simulação vai rodar; Run
Speed, onde são tratados os parâmetros dos tempos que decorrem durante a
simulação; as configurações podem ser vistas na Figura 41.
 49

Figura 41 — Configurações Replication Parameters e Run Speed no Arena.

Fonte: Próprio autor, 2020.

Para Replication Parameters adotou-se apenas 1 minuto de tempo de

simulação, por ser considerado suficiente para validar a integração entre as
plataformas. Para Run Speed foram utilizados os parâmetros adotados por Baptista
(2011), estes que fazem com que o tempo de simulação seja equivalente ao tempo
real.
 50

5. RESULTADOS OBTIDOS

A maneira como o programa de CLP e o modelo de simulação foram

desenvolvidos, faz com que só seja possível rodar a simulação no Arena em caso de
uma integração bem sucedida, mas além de observar se a integração foi um sucesso,
deve-se avaliar alguns resultados diferentes para saber se o modelo de simulação foi
elaborado de modo a representar de fato a estação didática tratada. É válido ressaltar
que para executar a simulação é necessário que todos os softwares estejam rodando,
com as configurações tratadas no desenvolvimento.
Uma forma de observar se a integração foi bem sucedida, é utilizar o RSLogix
500 em modo online, deste modo é possível supervisionar os acionamentos das
entradas e saídas do CLP, enquanto a simulação é executada, e notar se
correspondem a lógica utilizada para programação. Esse mesmo tipo de supervisão é
possível no Arena, através da aba Monitor I/O, acessada via Communications 
Monitor I/O.
Para avaliar se a simulação corresponde à estação real em seu
funcionamento, deve-se levar em conta, os dados dos relatórios de simulação, se
alguns itens correspondem ao esperado.
Um item que deve ser avaliado é a comparação de peças que foram registradas
na leitura onde são identificadas, e as que foram posicionadas em suas respectivas
rampas. Isso mostrará se as peças foram tratadas devidamente no processo, o que é
possível graças aos módulos Record utilizados. As informações ficam registradas na
seção Counter do relatório de simulação, como pode ser visto na Figura 42.
 51

Figura 42 — Adaptação do relatório de simulação, com registros dos módulos Record.

Fonte: Próprio autor, 2020.

Observa-se que as peças registradas na entrada foram tratadas corretamente.

Quando a simulação terminou, uma peça vermelha estava posicionada na barreira
esperando a esteira estar livre para ser direcionada à rampa correta e uma peça preta
ocupava a esteira.
Outro ponto a ser observado no relatório de simulação, é a seção de filas, ou
Queue, apresentada na Figura 43, onde são registradas informações sobre tempo de
espera e número de entidades que estiveram na fila, seja na média, ou o número
máximo.
 52

Figura 43 — Registro de filas no relatório de simulação.

Fonte: Próprio autor, 2020.

Para verificar se o programa do CLP funcionou adequadamente, pode-se

observar o número de entidades nas filas dos módulos Hold “AcionamentoAlavanca1”
e “AcionamentoAlavanca2”. Estas não podem registrar entidades, já que segundo a
lógica proposta as alavancas permanecem acionadas desde a saída da peça da
barreira, até que ela desça pela sua respectiva rampa, e o tempo em que isso decorre
é tratado em outro módulo, módulos Process posteriores. Entidades na fila desses
módulos indicariam que houve o acionamento de outro módulo desviador enquanto
uma peça ainda estava na esteira.
Observa-se que não houve tempo de espera ou entidades esperando nos
módulos de atenção, portanto o programa funcionou adequadamente.
Comparando as duas seções que podem ser vistas nas Figuras 42 e 43, pode-
se concluir também, que o sistema não é suficientemente eficiente para uma peça
entrando a cada segundo. Basta observar que 46 entidades foi o número máximo na
fila de espera pelo espaço em frente a barreira, enquanto apenas 15 peças foram
tratadas.
 53

6. CONCLUSÃO

Ao longo dos anos as tecnologias de simulação avançaram, assim como os

métodos computacionais, com isso é possível integrar simulações e sistemas de
controle automáticos, sejam reais ou emulados.
Demonstra-se por meio deste trabalho um método possível de integração entre
plataforma de simulação e sistema emulado, amparado pela interface de comunicação
OPC, e aproveitando recursos disponibilizados por uma fabricante que possui
produtos em ambos os contextos. Isso não significa que essa integração só é possível
entre recursos de um mesmo fabricante, a interface OPC possibilita comunicação
entre produtos de fabricantes diferentes, sendo um possível ponto de estudos futuros.
A programação foi funcional e o modelo desenvolvido para a simulação
correspondeu de modo suficiente à planta real, demonstrando inclusive uma limitação
em relação a capacidade de processamento de peças da planta.
Outro ponto possível para estudos futuros, seriam métodos para aumentar a
eficiência da planta, seja através das configurações que podem ser alteradas
diretamente, como a velocidade de transporte da esteira, ou avaliando a possibilidade
de implementar mais recursos, como: incluir sensores que identifiquem
individualmente a descida de peças na rampa, ou a posição atual da peça na esteira,
possibilitando o processamento de mais peças por vez; utilizar atuadores desviadores
com respostas mais rápidas, diminuindo o tempo necessário para que a peça seja
totalmente processada.
Também há possibilidade de avaliar, mesmo sem nenhuma nova
implementação, o estudo de qual seria o valor ótimo de tempo para entrada de peças,
ou seja, considerando que a estação já trabalha em sua eficiência máxima, qual seria
o tempo entre chegadas que a estação suporta sem gerar filas ou lacunas onde os
processos estejam desocupados.
A possibilidade de criar uma animação que corresponda à estação didática
trabalhada em funcionamento, no ambiente de simulação não foi explorada, sendo um
ponto de desenvolvimento de trabalhos futuros, já que o Arena traz essa possibilidade
integrada.
Com a solução apresentada neste trabalho, é possível levar o ambiente
industrial para o ambiente virtual no cenário do ensino. Esta possibilidade ganha
 54

importância, considerando a situação pandêmica que atingiu o mundo em 2020,

devido a doença do Covid-19, pois por meio da possibilidade dessa integração,
sistemas com plantas instaladas em instituições de ensino podem ser estudados em
regime domiciliar, através de técnicas de simulação e recursos de emulação.
É possível concluir então que os objetivos propostos foram alcançados e outros
problemas foram observados oportunizando estudos futuros.
 55

7. REFERÊNCIAS

AUINGER, F.; VORDEWINKLER, M.; BUCHTELA, G.; Interface drive domain-

independent modeling architecture for “soft-comissioning” and “reality in the loop”. In:
Winter Simulation Conference, Phoenix, Arizona, USA. p. 798-805, 1999.

BAPTISTA, Rodrigo César Teixeira; INTEGRAÇÃO ENTRE SISTEMA DE

CONTROLE E SIMULAÇÃO DISCRETA PARA A ANÁLISE DE DESEMPENHO DE
UMA VIA SEMAFORIZADA. 2011. Dissertação (Mestrado em Pesquisa Operacional
e Inteligência Computacional) — Programa De Pós-Graduação Em Pesquisa
Operacional E Inteligência Computacional, Universidade Candido Mendes. Campo
dos Goytacazes.

BASTOS, Patrick Júnior Teixeira; JÚNIOR, Érico Carvalho; CARDOSO, Leonardo das
Dores; RANGEL, João José de Assis; TAVARES, Leonardo Oliveira. Simulação a
eventos discretos para comissionamento de sistemas de controle. Anais do XVII
Simpósio de Engenharia de Produção, SIMPEP, Bauru/SP, 16p., 2010.

BELLÉ, Adriane; Um Ambiente Computacional para apoio ao Ensino de Estrutura de

Processamento. 2011. Dissertação (Mestrado em Engenharia Elétrica) — Faculdade
de Engenharia Elétrica e de Computação, Universidade Estadual de Campinas.
Campinas.

BRANCO, Anselmo Lázaro; Revoluções industriais - Primeira, segunda e terceira

revoluções. Disponível em <
https://educacao.uol.com.br/disciplinas/geografia/revolucoes-industriais-primeira-
segunda-e-terceira-revolucoes.htm?cmpid=copiaecola >. Acesso em: 18 Oct 2020.

DA SILVA, Marcelo Eurípedes; CONTROLADORES LÓGICO PROGRAMÁVEIS –

LADDER. Disponível em: < https://docplayer.com.br/8153965-Controladores-logico-
programaveis-Ladder.html >. Acesso em: 18 Oct. 2020.

DOS SANTOS, Mauricio Pereira; Introdução à Simulação Discreta. Disponível em: <
http://www.mpsantos.com.br/simul.pdf >. Acesso em 18 Oct. 2020.

DZINIC, Jasmin; YAO, CHARLIE; Simulation-based verification of PLC programs.

Gothenburg, Sweden: Department of Signals and Systems Division of Automatic
Control, Automation and Mechatronics — Chalmers University Of Technology, 2013.
Report No: EX058.p.5.

FAUSTINO, Marcos Roberto; NORMA IEC61131-3: ASPECTOS HISTÓRICOS,

TÉCNICOS E UM EXEMPLO DE APLICAÇÃO. 2005. Tese (Mestrado em Engenharia)
— Departamento de Engenharia de Energia e Automação Elétricas, Escola Politécnica
da Universidade de São Paulo. São Paulo.

GONÇALVES, Daneil Bertoli; APOSTILA, ARENA SOFTWARE — APLICAÇÕES EM

LOGÍSTICA. Disponível em: <
http://danielbertoli.synthasite.com/resources/ApostilaArena.pdf >. Acesso em: 18 Oct.
2020.
 56

HASNAN, Khalid Bin; Methodology to Develop Hybrid Simulation/Emulation Model.

2005. Tese (Doutorado em Filosofia) — Sheffield Hallam University. Sheffield.

JOHN, K. H.; TIEGELKAMP, M.; IEC61131-3: Programming industrial automation

systems. Berlim: Springer, 2001. 376p.

LEWIS, R. W.; Programming industrial control systems using IEC1131-3. London: The
Institution of Eletrical Engineers, 1995. 281p.

MACORATTI, José Carlos; VB - Falando um pouco sobre a tecnologia COM.

Disponível em: < http://www.macoratti.net/vb_dcom1.htm >. Acesso em: 20 Oct. 2020.

MAHNKE, Wolfgang; LEITNER, Stefan-Helmut; DAMM, Mathias. Introduction. In: OPC

Unified Architecture. Edition Number: 1. Heidelberg: Springer-Verlag Berlin, 2009.

MARSON, Michel Deliberali. A evolução da indústria de máquinas e equipamentos no

Brasil: Dedini e Romi, entre 1920 e 1960. Nova econ., Belo Horizonte, v. 24, n. 3, p.
685-710, Dec. 2014. Disponível em
<http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0103-
63512014000300685&lng=en&nrm=iso>. Acesso em
18 Oct. 2020. https://doi.org/10.1590/0103-6351/2096.

MOURA, S. L. S.; WALCZAK, F. S.; MOURA, R. A. SIMULAÇÃO COMPUTACIONAL,

ESSÊNCIA DA AGILIDADE, TECNOLOGIA E VIRTUALIZAÇÃO COM VASTA
APLICAÇÃO NA INDÚSTRIA MANUFATUREIRA EM GERAL. In: CIMATech -
Congress of Industrial Management and Aeronautical Technology, 6, 2019, São José
dos Campos, Anais, FATEC - Faculdade de Tecnologia,FATEC, Nov. 2019.p.1-2.

OPC Fundation; History. Disponível em: < https://opcfoundation.org/about/opc-

foundation/history/ >. Acesso em: 18 Oct. 2020.

OPC Fundation; What is OPC?. Disponível em: <

https://opcfoundation.org/about/what-is-opc/ >. Acesso em: 18 Oct. 2020.

POLA, Daniel Felix Santa Rosa. Modular Production System MPS Sistema Modular
de Produção. Festo Brasil Ltda. São Paulo. Maio. 2015.p.5.

PRADO, Darci Santos do. Usando ARENA em simulação. 5ª Edição. Nova Lima:
FALCONI Editora, 2014. — (Série Pesquisa Operacional, vol. 3). 388p.: il.

SLOTA, A.; W. MALOPOLSKI. “Integration of simulation software Arena with FMS

control system.” International Journal of Simulation Modelling 6 (2007): 165-172.

SMITH, Jeffery S.; CHO, Younchol. Offline commissioning of a PLC-based control

system using Arena. In: Winter Simulation Conference, Miami, FL, USA. p. 1802-1810,
2008.

WIKIDOT. O que é OPC?. Disponível em: < http://automatos.wikidot.com/01-o-que-e-

opc >. Acesso em: 18 Oct. 2020.
 57

ZHANG, D. Z.; ANOSIKE, A. I. Modelling and simulation of dynamically integrated

manufacturing systems. Advances in Intelligent and Soft Computing, Proceedings of
the 6th CIRP-Sponsored International Conference on Digital Enterprise Technology,
Vol. 66, p. 865-876, 2010.
 58

APÊNDICES
A – Modelo criado no Arena na íntegra.
 59

B – Programa no MicroLogix 500 em Ladder na íntegra.