Diogo Luiz Leme da Cruz - Udesctede.udesc.br/bitstream/tede/1848/1/Diogo Luiz Leme...
101
1 UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE MESTRADO EM ENGENHARIA ELÉTRICA DIOGO LUIZ LEMES DA CRUZ METODOLOGIA PARA IMPLEMENTAÇÃO DE CONTROLE SUPERVISÓRIO MODULAR LOCAL EM CONTROLADORES LÓGICOS PROGRAMÁVEIS JOINVILLE – SC 2011
Transcript of Diogo Luiz Leme da Cruz - Udesctede.udesc.br/bitstream/tede/1848/1/Diogo Luiz Leme...
1
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC
CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT
DEPARTAMENTO DE ENGENHARIA ELÉTRICA – DEE
MESTRADO EM ENGENHARIA ELÉTRICA
DIOGO LUIZ LEMES DA CRUZ
METODOLOGIA PARA IMPLEMENTAÇÃO DE CONTROLE
SUPERVISÓRIO MODULAR LOCAL EM CONTROLADORES
LÓGICOS PROGRAMÁVEIS
JOINVILLE – SC
2011
2
DIOGO LUIZ LEMES DA CRUZ
METODOLOGIA PARA IMPLEMENTAÇÃO DE CONTROLE SUPERVISÓRIO MODULAR LOCAL EM CONTROLADORES
LÓGICOS PROGRAMÁVEIS
Dissertação apresentada à Universidade do Estado de Santa Catarina como requisito para a obtenção do grau de Mestre em Engenharia Elétrica.
Orientador: Prof. Dr. André Bittencourt Leal
JOINVILLE – SC
2011
3
FICHA CATALOGRÁFICA
D955m
Cruz, Diogo. Metodologia para Implementação de Controle Supervisório Modular Local em Controladores Lógicos Programáveis / Diogo Luiz Lemes da Cruz; orientador: Dr. André Bittencout Leal. – Joinville, 2011. 101 f. : il ; 30 cm. Incluem referências. Dissertação (mestrado) – Universidade do Estado Santa Catarina, Centro de Ciências Tecnológicas, Mestrado em Engenharia Elétrica, Joinville, 2011.
1.Automação de Sistemas. 2.Teoria de Controle Supervisório. I. Leal, André Bittencourt.
CDD 629.8
4
"METODOLOGIA PARA IMPLEMENTAÇÃO DE CONTROLE SUPERVISÓRIO
MODULAR LOCAL EM CONTROLADORES LÓGICOS PROGRAMÁVEIS"
por
DIOGO LUIZ LEMES DA CRUZ
Esta dissertação foi julgada adequada para a obtenção do título de
MESTRE EM ENGENHARIA ELÉTRICA
área de concentração em “Automação de Sistemas”, e aprovada em sua forma final pelo
CURSO DE MESTRADO PROFISSIONAL EM ENGENHARIA ELÉTRICA
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA
UNIVERSIDADE DO ESTADO DE SANTA CATARINA.
Dr. André Bittencourt Leal CCT/UDESC (orientador/presidente)
Banca Examinadora:
Joinville, 29 de julho de 2011. Dr. Marcelo da Silva Hounsell CCT/UDESC (coorientador)
Dr. César Rafael Claure Torrico UTFPR
Dr. Roberto Silvio Ubertino Rosso Junior CCT/UDESC
5
À minha família.
6
AGRADECIMENTOS
Agradeço a Deus pelo dom da vida, pela saúde e por ter me guiado por mais esta
etapa da minha vida.
À minha esposa Cintia, pelo apoio e motivação.
Ao meu orientador, Prof. André Bittencourt Leal, pela atenção, dedicação e amizade.
Ao meu coorientador, Prof. Marcelo da Silva Hounsell, pela disponibilidade, ajuda
na revisão e sugestões.
Ao colega Heric Denis Farias e aos bolsistas do Programa de Educação Tutorial -
PET Engenharia Elétrica José Gregório do Rosário e Adriano Oliveira Pires, pelo auxílio no
desenvolvimento do trabalho.
7
RESUMO
CRUZ, Diogo Luiz Lemes da. Metodologia para Implementação de Controle Supervisório Modular Local em Controladores Lógicos Programáveis. 2011. 101f. Dissertação (Mestrado em Engenharia Elétrica – Área: Automação de Sistemas) – Universidade do Estado de Santa Catarina, Programa de Pós-Graduação em Engenharia Elétrica, Joinville, 2011.
Na atualidade, a automação da manufatura tem assumido cada vez mais um papel importante dentro das indústrias e os problemas de controle de sistemas automatizados têm se tornado cada vez mais complexos. Assim, o tradicional uso de métodos empíricos fortemente baseados na experiência do programador pode levar a soluções inadequadas ou ineficientes. Neste sentido, a Teoria de Controle Supervisório (TCS) apresentada por Ramadge e Wonham (1989) se mostra uma ferramenta adequada uma vez que garante a obtenção de uma lógica de controle ótima (minimamente restritiva e não bloqueante) e que satisfaz às especificações de controle. Este trabalho apresenta uma metodologia para implementação da TCS em Controladores Lógicos Programáveis (CLPs). A modelagem da planta e das especificações de controle é feita por autômatos e linguagens e no intuito de explorar a modularidade da planta e das especificações utiliza-se a abordagem modular local (QUEIROZ e CURY, 2000) para a síntese dos supervisores. O uso de uma metodologia formal para a implantação em sistemas de controle possibilita ainda uma padronização no desenvolvimento, teste e estrutura de códigos nos CLPs e obter uma solução livre de erros e bloqueios, fugindo dos métodos empíricos. Os métodos de implementação da TCS em CLP encontrados na literatura apresentam a característica de limitar a evolução do sistema, muitas vezes tratando um único evento por ciclo de varredura do CLP. Também, é apresentada uma série de problemas que podem ocorrer na implementação de supervisores em elementos de controle como CLPs (FABIAN e HELLGREN, 1998). Entretanto, nem todos os problemas apresentados são solucionados e para alguns deles são apresentadas propriedades que o modelo do sistema deve satisfazer para que tais problemas não se manifestem. Já a metodologia desenvolvida neste trabalho permite tratar em um mesmo ciclo de varredura do CLP todos os eventos não controláveis gerados pela planta, e ainda promover o controle da mesma a partir dos eventos controláveis gerados ao final desse ciclo. O desenvolvimento desta metodologia leva em consideração os problemas que podem ocorrer quando se utiliza a teoria na prática, apresentando uma solução para alguns desses problemas. Destaca-se a solução do chamado problema da escolha, cuja priorização indevida de eventos pode levar ao bloqueio ou tornar parte do sistema inoperante (MALIK, 2002). Como solução para este problema propõe-se uma escolha aleatória dinâmica para a geração dos eventos controláveis, evitando assim os problemas mencionados. Para facilitar a implementação da estrutura de controle supervisório no CLP foi criado um software de geração automática de código, que baseado na metodologia proposta, converte a listagem gerada pelo software de Sistema a Eventos Discretos (SED) em linguagem LADDER. A validação dos resultados obtidos com a ferramenta de geração de código foi realizada por intermédio de simulações feitas para diferentes problemas de controle supervisório.
Palavras-chave: Sistemas a Eventos Discretos; Célula Flexível de Manufatura; Controlador Lógico Programável.
8
ABSTRACT
CRUZ, Diogo Luiz Lemes da. Methodology for Implementation of Supervisory Control Local Modular in Programmable Logic Control. 2011. 101f. Dissertation (Master Course in Electrical Engineering – Area: Automation Systems) – Santa Catarina State University, Post-Graduation Program in Electrical Engineering, Joinville, 2011.
Currently, manufacturing automation has assumed an increasingly important role within the industry and the problems of automated control systems have become increasingly complex. Thus, the traditional use of empirical methods heavily base on the experience of the programmer can lead to inappropriate or ineffective solutions. In this case, the Supervisory Control Theory (SCT) of Ramadge and Wonham (1989) cam be a suitable tool because it ensures the achievement of optimal control logic (minimally restrictive and nonblocking) and also that meets the specifications of control. This paper presents a methodology for implementation of SCT in Programmable Logic Controllers (PLCs). The modeling of the plant and the specification of control is done by automata and languages, and in order to exploit the modular nature of the plant and the specifications we use the local modular approach (QUEIROZ and CURY, 2000) for the synthesis of supervisors. The use of a formal methodology for implementing control system also allows to standardize in the development, testing and structure of the PLC code and obtain a free of errors solution and crashes, discarding the empirical methods. The methods of implementation of the TCS in PLC existing literature have the feature to limit the evolution of the system, often dealing with one event per PLC scan cycle. Also presented is a series of problems that can occur in the implementation of supervisors in control elements such as PLCs (FABIAN and HELLGREN, 1998). However, not all of these problems have solutions and for some of them are presented some properties that the modeling of the system must ensure in order to avoid such problems. This method treats all the uncontrollable events produced by the plant in just one PLC scan cycle. The also promotes the control of the plant at the end of cycle. The development of this methodology takes into account the possible problems when using the theory into practice. Thus providing solutions to the problems. In this case the solutions, “Choice”, stands out. It promotes the random generation of controllable events. One it is give priority to a particular event over another, it can cause the system to lock or be inoperative (MALIK, 2002). To facilitate the implementation of supervisory control structure in PLC, was created a computational tool for the automatic generation of control logic, based on the proposed methodology that converts the list generated by the software Discrete Event System (DES) in LADDER code. The validation of the results obtained with the tool generation was done through simulations for different problems of supervisory control.
Keywords: Discrete Events Systems; Flexible Manufacturing Cell; Programmable Logic Controller.
9
SUMÁRIO
1� INTRODUÇÃO .............................................................................................................. 16�
1.1� OBJETIVOS GERAIS ......................................................................................... 18�
1.2� OBJETIVOS ESPECÍFICOS ............................................................................... 18�
1.3� ORGANIZAÇÃO DO TRABALHO ................................................................... 19�
2� SISTEMA A EVENTOS DISCRETOS ........................................................................ 20�
2.1� INTRODUÇÃO .................................................................................................... 20�
2.2� FORMALISMO PARA REPRESENTAÇÃO DE SED ...................................... 20�
2.2.1� Linguagens ............................................................................................... 20�
2.2.2� Representação de SEDs por linguagens ................................................... 22�
2.2.3� Autômatos para representação de SEDs ................................................... 22�
2.2.4� Composição de autômatos ........................................................................ 26�
3� TEORIA DE CONTROLE SUPERVISÓRIO ............................................................ 28�
3.1� INTRODUÇÃO .................................................................................................... 28�
3.2� CONTROLABILIDADE ..................................................................................... 28�
3.3� MODELAGEM DO SISTEMA ........................................................................... 29�
3.3.1� Modelagem da planta ............................................................................... 29�
3.3.2� Modelagem das especificações ................................................................. 30�
3.3.3� Supervisores ............................................................................................. 30�
3.4� SÍNTESE DO SUPERVISOR .............................................................................. 30�
3.4.1� Abordagem Monolítica ............................................................................. 30�
3.4.2� Abordagem Modular Local ...................................................................... 31�
4� REVISÃO SOBRE IMPLEMENTAÇÃO DA TCS EM CLP ................................... 34�
4.1� INTRODUÇÃO .................................................................................................... 34�
4.2� CONTROLADORES LÓGICOS PROGRAMÁVEIS ........................................ 34�
4.3� PROBLEMAS NA IMPLEMENTAÇÃO DA TCS EM CLP ............................. 36�
4.3.1� Causalidade ............................................................................................... 37�
4.3.2� Efeito avalanche ....................................................................................... 38�
4.3.3� Simultaneidade ......................................................................................... 40�
4.3.4� Sincronização inexata ............................................................................... 41�
10
4.3.5� Escolha ..................................................................................................... 42�
4.4� CONSIDERAÇÕES SOBRE IMPLEMENTAÇÕES .......................................... 44�
5� METODOLOGIA PARA IMPLEMENTAÇÃO DA TCS EM CLP......................... 45�
5.1� INTRODUÇÃO .................................................................................................... 45�
5.1.1� Solução para o problema da Causalidade ................................................. 45�
5.1.2� Solução para o Efeito Avalanche: Represamento .................................... 46�
5.1.3� Solução para o problema da Escolha: Pseudo-aleatoriedade ................... 48�
5.1.4� Considerações sobre os demais problemas ............................................... 53�
5.1.5� Tratamento de múltiplos eventos .............................................................. 54�
5.1.6� Detalhamento da Metodologia Proposta .................................................. 56�
5.2� ESTUDO DE CASO ............................................................................................ 62�
5.2.1� Descrição do sistema físico ...................................................................... 63�
5.2.2� Modelos dos dispositivos da planta .......................................................... 64�
5.2.3� Modelo das especificações ....................................................................... 64�
5.2.4� Síntese dos Supervisores Modulares Locais ............................................. 65�
5.3� IMPLEMENTAÇÃO CONFORME A METODOLOGIA PROPOSTA ............ 67�
5.3.1� Rotina principal ........................................................................................ 68�
5.3.2� Inicialização dos estados .......................................................................... 69�
5.3.3� Leitura das entradas .................................................................................. 70�
5.3.4� Resgate dos eventos não controláveis ...................................................... 71�
5.3.5� Atualização do sistema produto com os eventos não controláveis ........... 72�
5.3.6� Atualização dos supervisores com os eventos não controláveis .............. 73�
5.3.7� Desabilitações de eventos controláveis .................................................... 73�
5.3.8� Tratamento da escolha .............................................................................. 74�
5.3.9� Geração dos eventos controláveis no sistema produto ............................. 75�
5.3.10� Atualização dos supervisores com os eventos controláveis gerados ........ 76�
5.3.11� Escrita nas saídas ...................................................................................... 76�
6� FERRAMENTA DE GERAÇÃO AUTOMÁTICA DO CÓDIGO PARA O CLP .. 78�
6.1� INTRODUÇÃO .................................................................................................... 78�
6.2� APRESENTAÇÃO DA FERRAMENTA CCSSM ............................................. 78�
6.3� APLICAÇÃO DA FERRAMENTA .................................................................... 85�
6.3.1� Descrição do Problema ............................................................................. 86�
6.3.2� Modelos dos dispositivos da planta .......................................................... 86�
11
6.3.3� Modelo das especificações ....................................................................... 88�
6.3.4� Síntese dos Supervisores Modulares Locais ............................................. 90�
6.4� RESULTADO DA FERRAMENTA DE GERAÇÃO ......................................... 92�
7� CONSIDERAÇÕES FINAIS ......................................................................................... 95�
7.1� CONTRIBUIÇÕES .............................................................................................. 96�
7.2� TRABALHOS FUTUROS ................................................................................... 97�
REFERÊNCIAS ..................................................................................................................... 98�
12
LISTA DE FIGURAS
Figura 2.1 – Autômato de estados finitos ................................................................................. 24�
Figura 2.2 – Autômato não bloqueante .................................................................................... 25�
Figura 2.3 – Autômato bloqueante ........................................................................................... 25�
Figura 2.4 – Autômatos G1 e G2 ............................................................................................... 26�
Figura 2.5 – Composição síncrona G1||G2 ................................................................................ 27�
Figura 3.1 - Autômato que a presenta a diferenciação da controlabilidade dos eventos .......... 28�
Figura 3.2 – Controle de SED em malha fechada .................................................................... 31�
Figura 3.3 – Estrutura de controle modular local (QUEIROZ e CURY, 2002a) ..................... 32�
Figura 3.4 – Sequência para obtenção da Especificação Local ................................................ 33�
Figura 4.1 – Modelamento em ladder da transição do autômato ............................................. 36�
Figura 4.2 – Arquitetura para TCS segundo Ramadge e Wonham (1989)............................... 37�
Figura 4.3 – Arquitetura realística ............................................................................................ 37�
Figura 4.4 – Arquitetura proposta por Queiroz e Cury (2002) ................................................. 38�
Figura 4.5 – Autômato que proporciona o efeito avalanche..................................................... 38�
Figura 4.6 – Código do CLP que mostra o efeito avalanche .................................................... 39�
Figura 4.7 – Código do CLP invertido para impedir o efeito avalanche .................................. 39�
Figura 4.8 – Processamento cíclico da leitura das entradas do CLP ........................................ 40�
Figura 4.9 – Autômato que evidencia o problema de insensibilidade ao entrelaçamento ........ 41�
Figura 4.10 – Ilustração do problema da sincronização inexata............................................... 42�
Figura 4.11 – Autômato para ilustrar o problema da escolha ................................................... 43�
Figura 4.12 – Programa que prioriza a execução do evento B com relação ao C .................... 43�
Figura 4.13 – Supervisor não bloqueante cuja implementação pode ser bloqueante ............... 44�
Figura 5.1 – Arquitetura proposta por Queiroz e Cury (2002) ................................................. 46�
Figura 5.2 – Código que evita o efeito avalanche .................................................................... 47�
Figura 5.3 – Problema da escolha para mais de dois eventos................................................... 48�
Figura 5.4 – Problema da escolha para uma lista de eventos ................................................... 48�
Figura 5.5 – Autômato que permite a geração de dois eventos ................................................ 49�
Figura 5.6 – Fluxograma que determina se existe o problema da escolha ............................... 50�
Figura 5.7 – Solução para o problema da escolha entre dois eventos ...................................... 51�
Figura 5.8 – Solução para o problema da escolha entre mais de dois eventos ......................... 52�
Figura 5.9 – Solução para o problema da escolha para uma lista de eventos ........................... 53�
13
Figura 5.10 – Fluxograma da rotina principal .......................................................................... 55�
Figura 5.11 – Geração de múltiplos eventos controláveis ........................................................ 56�
Figura 5.12 – Fluxograma da rotina principal completo .......................................................... 57�
Figura 5.13 – Identificação da transição na entrada e geração de evento ................................ 58�
Figura 5.14 – Transição com eventos não controláveis no sistema produto ............................ 58�
Figura 5.15 – Transição com eventos não controláveis nos supervisores ................................ 59�
Figura 5.16 – Resgata os eventos gerados pela planta ............................................................. 59�
Figura 5.17 – Desabilitações dos eventos controláveis ............................................................ 60�
Figura 5.18 – Geração dos eventos controláveis ...................................................................... 61�
Figura 5.19 – Transição dos supervisores com eventos controláveis ....................................... 61�
Figura 5.20 – Transição dos supervisores com eventos controláveis ....................................... 62�
Figura 5.21 – Linha de transferência industrial ........................................................................ 63�
Figura 5.22 - Autômato das máquinas Gx para x = 1, 2, 3, ..., 6 .............................................. 64�
Figura 5.23 - Especificações dos buffers BA para x=1, BB para x=3 e BD para x=5 .................. 64�
Figura 5.24 - Especificação do buffer BC ................................................................................. 65�
Figura 5.25 – Supervisores modulares locais ........................................................................... 66�
Figura 5.26 – Supervisores modulares locais reduzidos........................................................... 67�
Figura 5.27 – Fluxograma dos estados e eventos ..................................................................... 68�
Figura 5.28 – Rotina principal .................................................................................................. 69�
Figura 5.29 – Inicialização dos estados .................................................................................... 70�
Figura 5.30 – Leitura das entradas e identificação dos eventos não controláveis .................... 71�
Figura 5.31 – Resgate dos eventos não controláveis ................................................................ 71�
Figura 5.32 – Transições do sistema produto com eventos não controláveis........................... 72�
Figura 5.33 – Transições dos supervisores com eventos não controláveis .............................. 73�
Figura 5.34 – Desabilitações de eventos controláveis .............................................................. 74�
Figura 5.35 – Escolha entre os eventos A2 e A4 ....................................................................... 75�
Figura 5.36 – Geração dos eventos controláveis pelo sistema produto .................................... 76�
Figura 5.37 – Transições dos supervisores com os eventos controláveis ................................. 76�
Figura 5.38 – Escrita nas saídas................................................................................................ 77�
Figura 6.1. Arquitetura da ferramenta de geração de código CCSSM ..................................... 80�
Figura 6.2. Tela inicial .............................................................................................................. 80�
Figura 6.3. Inserir os supervisores ............................................................................................ 81�
Figura 6.4. Inserir sistema produto ........................................................................................... 82�
Figura 6.5. Descrição dos estados ............................................................................................ 82�
14
Figura 6.6. Especificação de eventos controláveis ................................................................... 83�
Figura 6.7. Especificação de eventos não controláveis ............................................................ 84�
Figura 6.8. Condições para promover o reset dos sinais de saída CLP .................................... 84�
Figura 6.9. Seleção do modelo de CLP .................................................................................... 85�
Figura 6.10. Sistema automatizado de rotas variáveis (GROOVER, 2001)............................. 86�
Figura 6.11. Modelos das máquinas: a) G1, b) G2 e c) G3. ....................................................... 87�
Figura 6.12. Modelo da esteira transportadora G4. ................................................................... 87�
Figura 6.13. Modelo do sistema de transporte G0. ................................................................... 88�
Figura 6.14. Especificações: a) E0, b) E1, c)E2, ..., j)E9. ........................................................ 89�
Figura 6.15. Especificação E10. ............................................................................................... 89�
Figura 6.16. Especificação E11. ............................................................................................... 90�
Figura 6.17. Supervisor reduzido Sr0. ....................................................................................... 92�
Figura 6.18. Parte do código do CLP no formato texto e ladder ............................................. 93�
Figura 6.19. Novo projeto ........................................................................................................ 93�
Figura 6.20. Seleção do arquivo L5X ....................................................................................... 94�
Figura 6.21. Código gerado pela ferramenta em ladder ........................................................... 94�
15
LISTA DE TABELAS
Tabela 4.1 – Comandos ladder abordados pela IEC 61131-3 .................................................. 35�
Tabela 5.1 - Eventos dos dispositivos da célula ....................................................................... 63�
Tabela 5.2 – Eventos comuns entre modelos e especificações................................................. 66�
Tabela 6.1 – Ladder para os CLPs das famílias ControLogix® e CompactLogix™ ............... 92�
16
1 INTRODUÇÃO
Quando se aumenta o nível de automação de um sistema de produção, ou seja,
quanto menor a interferência do homem, maior é a redução dos custos de fabricação. Assim
ao se reduzir as falhas humanas na fabricação se reduzem os custos com retrabalho,
proporcionando um aumentando na qualidade do produto. A automação também facilita o
setup automático da linha de produção, quando está produz vários modelos que compõe o
portfólio da indústria, proporcionando certo grau de flexibilidade do sistema de produção.
Para atender todos esses requisitos se exige uma evolução constante dos dispositivos
de controle, ou seja, novas funcionalidades têm sido agregadas a estes, tais como, maior
capacidade de processamento, aumento da memória para o armazenamento de informações,
possibilidade de conexão a outros dispositivos e interface de programação amigável. Contudo,
principalmente na indústria não se tem uma evolução das técnicas e metodologias utilizadas
no desenvolvimento do projeto do controle (BRANDIN, 1996), onde o que prevalece é a
experiência do desenvolvedor que estabelece a lógica de controle do sistema de forma
empírica, já que não são utilizadas ferramentas formais para o desenvolvimento do projeto do
controle destes sistemas automatizados.
Cassandras e Lafortune (1999) abordam a utilização de ferramentas formais para o
desenvolvimento de procedimentos sistemáticos de análise, projeto (síntese) e implementação
de sistemas de controle, dentre os quais se destacam: Redes de Petri, Cadeias de Markov,
Teoria das Filas, Simulação, Álgebra de Processos e Max-Plus, Lógica Temporal, Autômatos
e Linguagens.
A grande maioria dos modelos citados se baseia na experiência do desenvolvedor.
Assim, se tornar apenas uma linguagem de programação de alto nível, onde a ação de controle
é limitada pela análise realizada pelo desenvolvedor. Porém, a Teoria de Controle
Supervisório (TCS) proposta por Ramadge e Wonham (1989) se destaca das demais, pois é
dotada de procedimentos de síntese de controladores, ou seja, é realizado um processo
automático de síntese do controle, ao invés dos procedimentos tradicionais (empíricos).
Conforme Hellgren et al. (2005, apud Vieira, 2007, p. 5), “apesar da grande
aceitação da Teoria de Controle Supervisório pelo meio acadêmico, havendo diversas
extensões à mesma e um número muito grande de publicações com foco em aspectos teóricos,
são raras as aplicações industriais. A razão principal para isto é o problema da implementação
física”. No caso da implementação em CLPs esses problemas surgem, pois se utiliza uma
teoria baseada em eventos discretos no tempo, mas o CLP é baseado em sinais que são
17
processados ciclicamente, uma vez que o ciclo de processamento do CLP consiste em ler as
entradas, processar o código linha a linha e ao final atualizar as saídas. Vieira (2007) cita
ainda diversas abordagens desenvolvidas no intuito de superar tais problemas, dentre as quais
algumas foram utilizadas como referências também para este trabalho, destacando-se:
(FABIAN e HELLGREN, 1998), (DIAS, 2005), (COSTA, 2005), (MORAES e LEAL, 2006),
(TEIXEIRA et al., 2006), (CARVALHO, 2007), (QUEIROZ, 2004), (QUEIROZ e CURY,
2002b), (VIEIRA, 2001), (BOUZON et al., 2004), (SANTOS et al., 2006), dentre outras
obras que abordam a TCS e a implementação desta em CLPs.
Ao se utilizar a Teoria de Controle Supervisório se obtêm a solução ótima do
controle de determinado sistema de forma sistemática. Já por intermédio da abordagem
Modular Local (QUEIROZ e CURY, 2000) explora-se a modularidade da planta. Assim,
quando é necessário alterar a lógica de controle, (lembrando que um sistema de manufatura
pode sofrer alteração), seja pela inclusão/exclusão de equipamentos ou alteração no layout do
sistema, essa alteração é facilitada, pois devem ser reprojetados apenas os supervisores que
englobam as respectivas especificações de controle modificadas.
Entretanto, no chão de fábrica a solução de controle é obtida de forma empírica, as
alterações do programa, muitas vezes, são dolorosas e a documentação e comentários no
corpo do programa são essenciais para que um terceiro possa entender o projeto para então
alterá-lo, não se utilizam procedimentos sistemáticos como na teoria citada, visto que ela não
é conhecida e dominada no âmbito industrial.
Neste trabalho será apresentada uma proposta de metodologia para a obtenção do
programa do CLP aplicando da TCS, conforme apresentado e discutido previamente em
(LEAL, CRUZ e HOUNSELL, 2009). A metodologia de implementação proposta visa
facilitar ao máximo a utilização da TCS no desenvolvimento de soluções de controle na
prática, de modo a garantir o funcionamento do sistema e a geração automática do programa
do CLP. A contribuição da metodologia proposta consiste no fato de possibilitar o tratamento
de diversos eventos em um mesmo ciclo de varredura do CLP, sejam estes eventos
controláveis ou não. Além disso, serão propostas soluções para diversos problemas
decorrentes da implementação da TCS em CLPs. Também será apresentada uma ferramenta
que gera o código do CLP automaticamente a partir dos supervisores sintetizados, essa
ferramenta foi desenvolvida tendo como base a metodologia proposta.
18
1.1 OBJETIVOS GERAIS
Com o intuito de evitar os métodos empíricos utilizados na indústria e sistematizar o
procedimento de projeto da lógica de controle, será abordada a TCS como ferramenta formal
para síntese dos supervisores. Como a TCS não é normalmente utilizada na indústria, por se
tratar de uma teoria nova, a implementação do supervisor em um CLP não é trivial, uma vez
que pode acarretar em alguns problemas, o que dificulta ainda mais a disseminação da TCS na
indústria. Assim, foi desenvolvida uma metodologia para a implementação da TCS em CLPs,
que trata os problemas que podem vir a surgir no desenvolvimento do código do CLP,
resultando em um código organizado que facilite o entendimento.
1.2 OBJETIVOS ESPECÍFICOS
A partir dos estudos das metodologias de implementação da TCS em CLPs,
existentes na literatura, se estabeleceu o objetivo de desenvolver uma metodologia de
implementação, que explora a máxima capacidade de processamento do CLP, ou seja, permita
que em um mesmo ciclo de varredura do CLP mais de um evento possa ser tratado.
Proporcionado assim, o maior número possível de mudança de estados ao longo de um ciclo
de execução do código do CLP.
Para obter a lógica de controle será aplicada a TCS, mais especificamente, a
abordagem modular local na síntese dos supervisores. O motivo de se utilizar essa abordagem
é explorar a modularidade das especificações de controle e dos subsistemas que compõem a
planta, para então se obter supervisores modulares cuja ação conjunta permita o controle
coordenado do sistema.
Os supervisores sintetizados serão implementados no formato reduzido (QUEIROZ,
2004), ou seja, reduzindo o número de estados que serão implementados no CLP,
proporcionando menos código e menos esforço para se converter o resultado teórico em um
programa de CLP. Antes de implementar os supervisores, se faz necessário garantir algumas
propriedades, que serão apresentadas ao longo desse trabalho.
A implementação em CLP é feita utilizando-se a linguagem Ladder (IEC, 2003), por
ser uma linguagem mais difundida no meio industrial, de fácil visualização e entendimento,
possibilitando que alterações e localização de falhas sejam feitas rapidamente.
Para validar a possibilidade de sistematização, da metodologia será desenvolvida
uma ferramenta que gera automaticamente o código do CLP, a partir dos supervisores
sintetizados. Obtendo assim, um atrativo a mais para a utilização da TCS pela a indústria.
19
1.3 ORGANIZAÇÃO DO TRABALHO
Esta dissertação está estruturada da seguinte forma: no Capítulo 2 é apresentada uma
revisão sobre os conceitos de Sistemas a Eventos Discretos (SEDs) e os formalismos de
Linguagens e Autômatos utilizados para a representação de SEDs.
Na sequência, o capítulo 3 faz uma revisão sobre a Teoria de Controle Supervisório
proposta por Ramadge e Wonham (1989) chegando até a abordagem Modular Local proposta
por Queiroz e Cury (2000).
No Capítulo 4 são levantadas as metodologias de implementação da TCS em
sistemas de controle, apresentado as soluções, dos principais problemas e dificuldades.
O Capítulo 5 contempla a principal contribuição desse trabalho, ou seja, é
apresentada uma metodologia para se implementar em CLP, os resultados obtidos pela
modelagem do sistema, utilizando a TCS juntamente com a abordagem Modular Local,
apresentada no Capítulo 3. A proposta de metodologia busca solucionar os problemas
levantados no Capítulo 4 e apresenta um diferencial com relação às outras metodologias
pesquisadas.
No capítulo 6 é apresentada uma ferramenta de geração automática de código para o
CLP, que foi desenvolvida tendo como base a metodologia proposta. Também é abordado um
problema teórico, que busca apresentar os passos necessários para estabelecer a solução do
problema ao se utilizar um CLP para controlar o processo.
No último capítulo são comentados os resultados obtidos com a proposta de
implementação aliada à ferramenta desenvolvida, para o desenvolvimento do controle
supervisório em CLP, são apresentadas as contribuições do trabalho e as propostas para
futuros trabalhos.
20
2 SISTEMA A EVENTOS DISCRETOS
2.1 INTRODUÇÃO
O presente capítulo tem como objetivo apresentar a teoria utilizada para se modelar a
classe de sistemas do qual trata este trabalho, denominada Sistemas a Eventos Discretos
(SEDs).
Um Sistema a Eventos Discretos (SED) é descrito por Cassandras e Lafortune (1999)
como sendo um sistema de estados discretos, dirigido a eventos, isto é, sua evolução de
estados depende da ocorrência de eventos discretos assíncronos no tempo.
Pelo termo “evento” pode-se entender que é a ocorrência de um determinado
fenômeno no sistema em questão, essa ocorrência é abrupta, sem duração no tempo e pode
afetar o comportamento deste sistema. Um evento pode ser identificado como uma ação
específica, como por exemplo, a abertura de uma válvula pneumática que proporciona o
avanço do cilindro pneumático, ou o acionamento de um sensor que indica que determinado
cilindro pneumático está avançado. Um conjunto de eventos ordenados forma uma sequência
de eventos que pode ser usada para descrever determinado comportamento de um dado
sistema. Uma sequência de eventos especifica então a ordem de ocorrência dos eventos, mas
sem levar em consideração o instante de tempo em que cada evento ocorreu.
Diversos tipos de sistemas podem ser modelados como SEDs, dentre os quais se
incluem robótica, sistemas de comunicação, controle de tráfego, logística e em diversos
campos da indústria principalmente na manufatura, que são o foco deste trabalho. Assim, na
sequência são apresentados os formalismos para a representação de SEDs por intermédio de
linguagens e de autômatos.
2.2 FORMALISMO PARA REPRESENTAÇÃO DE SED
A fim de se formalizar a representação de SEDs serão apresentados nessa seção os
conceitos básicos da teoria de linguagens e autômatos. Caso o leitor queira se aprofundar mais
nesse assunto, sugere-se a consulta às seguintes referências: (CASSANDRAS e
LAFORTUNE, 1999; CURY, 2001; TEIXEIRA, 2008; WONHAM, 2004).
2.2.1 Linguagens
O comportamento de um SED pode ser representado por linguagens definidas sobre
um alfabeto Σ formado por um conjunto finito e não vazio de símbolos associados aos eventos
do sistema. Neste contexto, cada evento do SED é representado por um símbolo e uma
21
sequência de eventos pode ser representada por uma palavra definida sobre o alfabeto Σ.
Assim, por definição, uma linguagem L definida sobre um alfabeto Σ, é um conjunto de
palavras formadas pelas sequências de símbolos pertencentes a esse alfabeto Σ. Define-se
ainda Σ* como o conjunto de todas as sequências finitas de símbolos do conjunto Σ, incluindo
a palavra vazia, que é representada pelo símbolo ε (CURY, 2001). Vale lembrar que uma
sequência de símbolos (palavra) é chamada também de cadeia. O comprimento de uma
palavra s, denotado por |s|, corresponde ao número de eventos que a compõem.
Como uma linguagem é um conjunto de palavras, as propriedades matemáticas
válidas para conjuntos, como união, intersecção e outras, também podem ser aplicadas em
linguagens.
Ao se utilizar linguagem devem ser consideradas as seguintes operações:
1. Concatenação:
Esta operação consiste em, como o próprio nome diz, concatenar uma palavra
pertencente a L1, seguida de uma palavra pertencente a L2, sendo L1 e L2 ⊆ Σ*, a referida
concatenação é representada pela cadeia L1L2, que é definida como segue:
L1L2 = {s ∈ Σ*: (s = s1s2), (s1 ∈ L1) e (s2 ∈ L2)}
Desta forma, uma cadeia está em L1L2 se ela pode ser escrita como a concatenação
de uma cadeia de L1 com uma cadeia de L2. Sejam as cadeias t, u, v, s ∈ Σ* onde a cadeia s é
resultante da concatenação das cadeias t, u, e v, ou seja, tuv = s, então: t é chamado prefixo de
s; u é chamado de subcadeia de s; e v é chamado sufixo de s.
2. Prefixo-Fechamento:
A operação de prefixo-fechamento de uma linguagem é dada pelo conjunto formado
por todos os prefixos das palavras pertencentes à referida linguagem. Dessa forma, seja uma
linguagem L ∈ Σ*, então o prefixo-fechamento de L é representado por L , onde por
definição:
L = {s ∈ Σ*: ∃ t ∈ Σ* (st ∈ L)}
De forma geral LL ⊆ , ou seja, uma linguagem é igual ou está contida no seu
prefixo-fechamento. Uma linguagem L é dita prefixo-fechada se qualquer prefixo de qualquer
cadeia pertencente à linguagem L for também uma cadeia existente em L, ou seja, LL = . Por
exemplo, considere o alfabeto Σ = {t, u, v} e a linguagem L1 = {ε, u, utt}, o prefixo
fechamento de L1 seria formado por 1L = {ε, u, ut, utt}.
22
3. Fechamento-Kleene:
O fechamento-Kleene de uma determinada linguagem é dado pela concatenação de
um número finito de cadeias de L, incluindo a cadeia vazia ε, dessa forma seja uma linguagem
L ⊆ Σ*, então o fechamento-Kleene de L é representado por L*, onde por definição:
L* = {ε} ∪ L ∪ LL ∪ LLL ∪ ....
Como exemplo, considera-se o alfabeto Σ = {t, u, v}, e a linguagem L2 = {v}
definidos sobre Σ, o fechamento–Kleene é dado por: L2* = {ε, v, vv, vvv,...}.
2.2.2 Representação de SEDs por linguagens
Ao se utilizar linguagem para representar um SED, deve-se associar o conjunto de
eventos existentes no sistema em questão a símbolos que são definidos sobre um alfabeto �, e
dessa forma o comportamento dos eventos do referido sistema pode ser descrito através de um
par de linguagens L e Lm.
A linguagem L ⊆ Σ*, que recebe o nome de linguagem gerada, é uma linguagem
prefixo-fechada e descreve, passo a passo, o comportamento gerado pelo sistema, ou seja, o
conjunto de todas as cadeias de eventos fisicamente possíveis de ocorrer na planta.
Já a linguagem Lm ⊆ L, que recebe o nome de linguagem marcada, representa o
conjunto de cadeias de eventos que, partindo do estado inicial, levam o sistema a completar
uma tarefa.
Duas propriedades de linguagens L e Lm são sintetizadas para representar um SED:
1. L ⊇ Lm, ou seja, o comportamento gerado contém o comportamento marcado
de um SED;
2. L = L , ou seja, o comportamento gerado de um SED é prefixo-fechado.
Usando linguagens podem-se representar todas as possíveis sequências de eventos
(L) ou as tarefas que o sistema pode completar (Lm). Porém se torna impraticável se
representar todas as possíveis sequências de eventos que um SED pode gerar, assim para
facilitar a representação existem ferramentas que trabalham com recursividade, por exemplo,
expressões regulares, autômatos de estados finitos, etc.
2.2.3 Autômatos para representação de SEDs
Ao se utilizar autômatos de estados finitos para se representar um SED, se tem uma
facilidade para se generalizar a recursividade, conforme apresentado anteriormente. Porém, a
principal vantagem que se tem na utilização de autômatos, está relacionada com a limitação
23
computacional que a representação por linguagem apresenta. Assim, quando se utiliza
autômatos na síntese do controlador de um SED, a representação gráfica facilita o
entendimento e a execução, viabilizando o desenvolvimento de algoritmos computacionais
(CASSANDRAS e LAFORTUNE, 1999). A seguir serão apresentados os principais conceitos
relacionados aos autômatos de estados finitos. Para facilitar o entendimento serão levantadas
as principais relações existentes entre os autômatos e as linguagens, para então apresentar a
representação de um SED utilizando-se autômatos.
Todo e qualquer autômato determinístico de estados finitos é composto por uma
quíntupla G = (X, Σ, f, xo, Xm), onde:
• X é o conjunto finito de estados do autômato;
• Σ é o conjunto de eventos que definem o alfabeto;
• f : X x Σ → X é a função de transição de estados;
• xo é o estado inicial do autômato;
• Xm é o conjunto de estados finais (marcados) onde Xm ⊆ X.
Normalmente a representação de um autômato é feita graficamente, onde os estados
são representados por círculos, e as transições de estados são representadas por setas. O
estado inicial é identificado através de uma seta apontando para ele, sendo que esta seta não
inicia em nenhum outro estado.
A título de ilustração, considere o autômato G cujo conjunto de estados é definido
por X = {0, 1, 2}, o alfabeto de eventos é definido em Σ = {A2, A4, A5, B2, B4, B5}, e a função
de transição de estados é dada por f(0,B5) = 0, f(0,A2) = 1, f(0,A4) = 1, f(1,B5) = 1, f(1,B2) = 2,
f(1,B4) = 2, f(2,B5) = 2, f(2,A5) = 0. O estado inicial xo = {0} e o conjunto de estados marcados
é definido por Xm = {0, 2}. A representação gráfica do autômato G é apresentada pela Figura
2.1.
O autômato da Figura 2.1 representa um sistema que inicia no estado 0, onde os
únicos eventos possíveis de ocorrer são A2, A4 e B5, na ocorrência do evento B5 se permanece
no estado 0 e uma tarefa é registrada. Ainda no estado 0 ocorrendo o evento A2 ou A4 o
sistema transita para o estado 1, sem completar tarefa. Estando no estado 1, os eventos
passíveis de ocorrer são B2, B4 e B5, novamente o evento B5 não muda de estado, porém
nenhuma tarefa é completada. Ainda no estado 1, ocorrendo o evento B2 ou B4 o sistema
transita para o estado 2, onde uma tarefa é completada. Estando no estado 2 o único evento
possível é o A5, onde a ocorrência deste promove a transição para o estado 0 e uma tarefa é
completada, fechando o ciclo.
24
Figura 2.1 – Autômato de estados finitos
Ao autômato G = (X, Σ, f, xo, Xm) são associadas duas linguagens, a linguagem
gerada L(G), que representa todas as cadeias que podem ser seguidas no autômato a partir do
estado inicial, e a linguagem marcada Lm(G), que considera todas as cadeias que partindo do
estado inicial chegam a um estado marcado, incluindo, neste caso, o próprio estado inicial.
Assim, tem-se que:
• L(G) := {r ∈ Σ* : f (xo, r) é definida};
• Lm(G) := {s ∈ Σ* : f (xo, s) ∈ Xm}.
Assim, um SED pode ser modelado por um autômato G, onde L(G) é o
comportamento gerado pelo sistema e Lm(G) é o conjunto de tarefas completas do sistema
(CURY, 2001).
Um estado de um autômato é chamado de não acessível quando não existe nenhuma
cadeia de eventos que, partindo do estado inicial, leve ao referido estado. Da mesma forma,
um estado x ∈ X é dito ser acessível se x = f (xo, s) para algum s ∈ Σ*. Assim se todos os
estados de um determinado autômato forem acessíveis este autômato é chamado de acessível.
Por definição, a operação Ac(G) é a componente acessível do autômato G, e é obtida pela
eliminação de seus estados não acessíveis e das transições associadas a eles.
Já um estado é chamado de co-acessível (ou não bloqueante) se partindo do referido
estado existe uma cadeia de eventos que leve a um estado marcado, ou seja, um estado x ∈ X,
é co-acessível se existe s ∈ Σ* tal que f (x, s) ∈ Xm. Se todos os estados de um determinado
autômato são co-acessíveis, este autômato é chamado de co-acessível ou não bloqueante. A
condição de co-acessibilidade de um autômato pode ainda ser descrita pela equação:
)()( GLmGL = (2.1)
25
Por definição, um SED é dito não bloqueante se, e somente se, satisfaz as condições
da Equação 2.1. Caso contrário, o SED é dito bloqueante (CURY, 2001). A condição de
bloqueio corresponde a cadeias de eventos geradas pelo sistema a partir das quais não se pode
completar nenhuma tarefa. O autômato apresentado na Figura 2.2 é co-acessível (não
bloqueante), pois o estado 2 representa uma tarefa completada do sistema, o que caracteriza o
não bloqueio.
Figura 2.2 – Autômato não bloqueante
Já na Figura 2.3 é mostrado um autômato onde ocorre o bloqueio do sistema no
estado 1, ainda que seja possível a ocorrência do evento B5.
Figura 2.3 – Autômato bloqueante
Por definição, a operação Trim(G) do autômato G é obtida pela eliminação dos
estados não acessíveis e dos estados não co-acessíveis, bem como das transições associadas a
estes, resultando em um autômato aparado (trim).
26
2.2.4 Composição de autômatos
Segundo Cury (2001), na representação de SEDs por autômatos, pode-se modelar o
comportamento global do sistema por intermédio de um único autômato, ou então se pode
decompor o SED em diversos subsistemas, e representar o comportamento de cada um deles
por um autômato diferente. Assim, se dois ou mais subsistemas não apresentarem eventos em
comum em seus alfabetos, esses subsistemas operam concorrentemente, mas
assincronamente.
Porém, para os subsistemas que apresentam eventos em comum em seus alfabetos,
haverá uma sincronização através destes eventos, ou seja, a ocorrência de um evento é
simultânea em todos os subsistemas que compartilham o referido evento. Este comportamento
é capturado pela definição de produto síncrono (ou composição síncrona) de autômatos,
conforme apresentado a seguir.
Dados dois autômatos G1 = (X1, Σ1, f1, xo1, Xm1) e G2 = (X2, Σ2, f2, xo2, Xm2), a
composição síncrona G1||G2 é definida por:
G1||G2 = Ac(X1 × X2, Σ1∪Σ2, f1||2, (xo1,xo2), Xm1 × Xm2)
onde Ac é a componente acessível e
f1||2 : (X1 × X2) × (Σ1∪Σ2) → (X1 × X2)
ou seja:
��
�
��
�
�
��
�
��
�
�
�∈�∉�∈
�∈�∉�∈
�∩�∈�∩�∈
=
contráriocasoindefinida
xeesexfx
xeesexxf
xxesexfxf
xxf)2( )),2(2,1(
)1( )2),,1(1(
)2()1( )),2(2),,1(1(
)),2,1((212
121
2121
2||1σσσσ
σσσσ
σσσσ
σ
A partir da definição pode se concluir que um determinado evento só será possível de
ocorrer se o referido evento estiver ativo nas plantas G1 e G2, ou se o respectivo evento estiver
ativo na planta G1 e não pertencer ao alfabeto de G2, ou então se o evento estiver ativo em G2
e o referido evento não pertencer ao alfabeto de G1.
Por exemplo, sejam os autômatos G1 e G2 mostrados na Figura 2.4.
Figura 2.4 – Autômatos G1 e G2
27
A composição síncrona dos autômatos G1 e G2 mostrados na Figura 2.4 está
representada pelo autômato mostrado na Figura 2.5.
Figura 2.5 – Composição síncrona G1||G2
Em uma análise de pior caso, segundo Queiroz (2000), o número de estados
resultantes de uma composição síncrona pode crescer exponencialmente, se tornando uma
tarefa difícil de ser realizada à medida que o autômato vai crescendo, mas existem
ferramentas computacionais desenvolvidas para estas atividades. Neste trabalho utilizou-se
uma ferramenta computacional chamada de IDES (RUDIE, 2006). Além desta, duas outras
ferramentas são bastante conhecidas no meio acadêmico, a saber, o TCT (FENG e
WONHAN, 2006) e “Grail para controle supervisório” (REISER et al., 2006), ou, de forma
abreviada, Grail. Mais informações relativas à sua aplicação são encontradas em (CURY,
2001; GARCIA, 2006). O software Grail (REISER et al., 2006) também é utilizado neste
trabalho, porém com menor ênfase do que o IDES.
28
3 TEORIA DE CONTROLE SUPERVISÓRIO
3.1 INTRODUÇÃO
Neste capítulo a Teoria de Controle Supervisório (TCS) (RAMADGE e WONHAM,
1989), será sucintamente apresentada de modo a prover o embasamento teórico necessário
para a apresentação da metodologia de implementação dessa teoria em controladores lógicos
programáveis, que é o tema principal desse trabalho.
Serão apresentadas ainda duas abordagens de síntese de supervisores, a chamada
abordagem monolítica, introduzida por Ramadge e Wonham (1989) e uma extensão desta,
chamada de abordagem Modular Local, proposta por Queiroz e Cury (2000).
3.2 CONTROLABILIDADE
Para Ramadge e Wonham (1989) o alfabeto de eventos Σ é dividido em eventos
controláveis, Σc ⊆ Σ, e eventos não controláveis, Σuc ⊆ Σ, sendo que Σ ⊆ Σc ∪ Σuc com Σc ∩
Σuc = ∅. Os eventos controláveis são subordinados à ação de controle, ou seja, o evento pode
ser desabilitado pelo sistema de controle, como por exemplo, o acionamento de uma válvula
pneumática para que um determinado cilindro seja avançado. Já os eventos não controláveis
não são subordinados ao sistema de controle, ou seja, a ocorrência destes eventos não pode ser
diretamente desabilitada pela ação de controle, como por exemplo, o acionamento de um
sensor que indica que determinado cilindro pneumático está avançado.
Esta classificação é muito importante, pois é com base nela que a metodologia de
implementação proposta nesse trabalho organiza o programa no CLP.
Ao representar um SED utilizado autômatos, para diferenciar os eventos controláveis
dos não controláveis, as transições de estados devido a eventos controláveis são representados
por uma seta seccionada por uma pequena linha transversal e as setas que representam as
transições devido a eventos não controláveis não são seccionadas (CURY, 2001). A Figura
3.1 representa um autômato, onde o evento A é controlável e o evento B é não controlável,
assim apenas a seta que representa a transição de estado devido ao evento A deve ser
diferenciada por uma linha transversal.
Figura 3.1 - Autômato que a presenta a diferenciação da controlabilidade dos eventos
29
3.3 MODELAGEM DO SISTEMA
Para projetar um sistema de controle supervisório de um SED, deve-se
primeiramente modelar o sistema em estudo por intermédio de autômatos. Uma vez definido a
qual nível de detalhamento o modelamento do sistema irá abranger, ou seja, quais serão os
sinais trocados pela planta e pelo sistema de controle, para se determinar o supervisor devem-
se seguir os seguintes passos:
1. Listar todos os eventos existentes;
2. Dividir a lista de eventos em eventos controláveis e não controláveis;
3. Para cada elemento que compõe a planta física, deve-se realizar o
modelamento usando autômato de modo que, cada subsistema tenha os
mesmos estados e transições existentes na planta;
4. Garantir que a linguagem gerada pelos autômatos dos subsistemas,
representa o funcionamento real da planta;
5. Modelar as especificações de controle, que irá garantir o funcionamento
desejado ao sistema;
6. Por fim, escolher a abordagem desejada para então realizar a síntese do(s)
supervisor(es).
3.3.1 Modelagem da planta
Conforme visto anteriormente um sistema pode ser composto por um conjunto de
subsistemas concorrentes que podem compartir ou não eventos, ou seja, trabalharem
sincronamente ou assincronamente (RAMADGE e WONHAM, 1989; QUEIROZ, 2004).
Assim, a partir dessa propriedade, o comportamento da planta pode ser modelado por
um conjunto de geradores Gi, i = 1, ... , n, onde cada um deles representa o comportamento de
um dos subsistemas que compõem a planta. Um modelo para o comportamento global da
planta pode ser obtido realizando-se a composição síncrona de todos os geradores, ou seja, G
= G1||G2|| ... ||Gn. Entretanto, conforme apresentado por Queiroz e Cury (2000a) a
complexidade computacional desta composição síncrona cresce exponencialmente de acordo
com o número de estados de cada um dos geradores, o que pode levar à explosão
combinatória de estados.
30
3.3.2 Modelagem das especificações
Uma vez modelada a planta, deve-se então definir os objetivos de controle do
sistema, para então realizar o modelamento das especificações de controle por meio de
autômatos. O objetivo das especificações de controle é evitar que o sistema atinja estados
indesejados ou proibidos, de forma a obedecer aos objetivos de controle. Estes estados podem
ser causadores de bloqueio ou então serem fisicamente inadmissíveis. O modelamento da
especificação de controle pode ser feito para definir os estados proibidos da planta ou também
pode ser definida em termos de sequências indesejadas de eventos.
3.3.3 Supervisores
O modelamento de um SED promove a representação G de todo o comportamento do
sistema que seja fisicamente possível, incluindo comportamentos indesejáveis que devem ser
evitados por intermédio da ação de controle. A Teoria de Controle Supervisório proposta por
Ramadge e Wonham (1989), afeta a linguagem gerada pela planta, como se os eventos
indesejáveis fossem momentaneamente apagados da estrutura de transição, de modo a
desabilitar os eventos controláveis indesejáveis. Conforme apresentado no item anterior, os
eventos controláveis a serem desabilitados, foram mapeados pelas especificações de controle
E. O agente de controle, denominado de supervisor S, trabalha em malha fechada de forma a
limitar minimamente o comportamento do sistema de modo a garantir que o mesmo esteja de
acordo com as especificações de controle. Assim, o comportamento de G controlado por S,
denotado por S/G, desabilita a ocorrência de cadeias de eventos fisicamente possíveis em G,
mas não são aceitas por E. O comportamento marcado de G sob a ação do supervisor S é dado
por Lm(G/S) = L(G/S) ∩ Lm(G).
Um supervisor é chamado de próprio, ou não bloqueante, se a ação de controle do
supervisor sobre uma planta G não leva ao bloqueio do sistema em malha fechada, ou seja, se
)/()/( GSLGSLm = .
3.4 SÍNTESE DO SUPERVISOR
3.4.1 Abordagem Monolítica
Na Abordagem Monolítica de síntese de supervisores, proposta por Ramadge e
Wonham (1989), o objetivo consiste em projetar um único supervisor para coordenar o
comportamento da planta. Assim, nesta abordagem todos os modelos dos subsistemas que
compõem a planta são sincronizados em um único modelo que representa o funcionamento
global da planta G e, da mesma forma, todas as especificações de controle também são unidas
31
em uma única especificação global E, para então calcular o supervisor resultante S. A Figura
3.2 ilustra a estrutura de controle em malha fechada de uma planta G sob a ação do supervisor
S.
Figura 3.2 – Controle de SED em malha fechada
Segundo Queiroz (2004) na abordagem monolítica à medida que se aumenta o
número de subsistema, o número de estados crescem exponencialmente. Assim essa
abordagem apresenta alguns pontos negativos. Um deles é com relação ao grande esforço
computacional que se pode chegar, quando se realiza a composição assíncrona de vários
autômatos. Outro ponto negativo se da na utilização dos supervisores resultantes, em
plataformas de controle (normalmente CLP), quando estes apresentam muitos estados,
podendo gerar extensos programas, onde a compreensão, validação e manutenção, ficam
bastaste difícil. Em alguns caso o tamanho do programa pode inviabilizar a sua utilização em
um determinado hardware, seja pela capacidade de armazenamento ou pela capacidade de
processamento. Podendo até se justificar com isso a pouca utilização da TCS na indústria.
A fim de, diminuir o tamanho dos supervisores, resultando em um esforço
computacional menor, na síntese do supervisor, Queiroz e Cury (2000) propõe utilizar a
abordagem Modular Local.
3.4.2 Abordagem Modular Local
Esta abordagem é uma extensão à abordagem monolítica e explora a modularidade
da planta e das especificações de controle, de modo que ao invés de se determinar um único e
extenso supervisor são determinados vários supervisores locais e a atuação conjunta desses
supervisores controla o funcionamento do sistema como um todo. A Figura 3.3 ilustra a
estrutura de controle supervisório modular local para dois supervisores.
32
Figura 3.3 – Estrutura de controle modular local (QUEIROZ e CURY, 2002a)
As vantagens de se utilizar essa abordagem consistem em ser mais fácil de calcular,
uma vez que são gerados menos estados, além dessas vantagens também tem o fato que a
divisão do sistema em vários subsistemas permite organizar o programa do CLP facilitando
assim o seu entendimento. Assim a metodologia de implementação, proposta neste trabalho,
foi desenvolvida tendo como base esta abordagem.
A aplicação da abordagem Modular Local de síntese de supervisores (QUEIROZ,
2000; QUEIROZ e CURY, 2000a; 2000b; 2002a) requer que o sistema a ser controlado seja
descrito por sistema produto, ou seja, por diversos geradores que não possuem eventos em
comum (geradores assíncronos). Por sua vez, cada especificação imposta pelo projetista é
representada por um gerador Ej e definida, respectivamente, em subconjuntos de eventos Σj ⊆
Σ para j ∈ {1,..., m}, sendo m o número de especificações. A partir de cada Σj é determinada
uma planta local, denotada por Glocalj, que consiste na composição síncrona dos subsistemas
que apresentam em seu alfabeto pelo menos um evento que seja pertencente ao alfabeto de
uma dada especificação (ou a mais de uma), resultando em um grupo de plantas locais.
Após determinar todas as plantas locais deve-se calcular então a chamada
especificação local, que consiste em realizar o produto síncrono entre uma dada especificação
com a sua respectiva planta local. Na Figura 3.4 é apresentada uma sequência de passos para
a obtenção de uma especificação local.
33
Figura 3.4 – Sequência para obtenção da Especificação Local
O comportamento desejado pode ser expresso por uma linguagem alvo denotado por
Klocalj = Ej||Lm(Glocalj). A partir disso, calculam-se as máximas linguagens controláveis locais
SupC(Klocalj, Glocalj). Com este procedimento é possível realizar a síntese de um supervisor
local para cada uma das especificações definidas no projeto. A representação dos supervisores
locais é dada por Slocj, onde j = {1,..., m}.
Para garantir que o sistema sob a ação do conjunto de supervisores locais não
apresente bloqueio, deve-se realizar o teste da modularidade (ou teste de não conflito). Este
teste pode ser feito realizando-se a composição síncrona de todos os supervisores locais e
determinando assim se o gerador resultante é trim, ou seja, o gerador resultante não deve
apresentar estados não acessíveis e nem estados não co-acessíveis. Caso isto seja verificado,
diz-se que os supervisores são modulares locais (não conflitantes) e o Teorema 7 apresentado
em (QUEIROZ, 2000) garante que a ação conjunta dos supervisores locais é equivalente à
ação de um supervisor monolítico que atende a todas as especificações simultaneamente.
Caso esta propriedade não seja verificada, significa que ação conjunta desses
supervisores levará o sistema a um estado de bloqueio. Em (QUEIROZ, 2000) encontra-se
uma seção que aborda a resolução de conflito entre supervisores.
Um ponto negativo dessa abordagem foi destacado por Queiroz (2000), e consiste na
complexidade do teste da modularidade local, que pode exigir um esforço computacional
muito grande, essa complexidade pode ser menor ou igual à complexidade de se calcular o
supervisor utilizando a abordagem Monolítica proposta por Ramadge e Wonham (1989).
Segundo (QUEIROZ, 2000), a complexidade computacional envolvida no teste da
modularidade é equivalente à complexidade computacional do cálculo do supervisor
monolítico. Assim, para sistemas de grande porte, este teste pode se tornar
computacionalmente inviável, sendo, portanto, motivo de atenção de alguns pesquisadores
(PENA, 2009; FLORDAL e MALIK, 2006).
34
4 REVISÃO SOBRE IMPLEMENTAÇÃO DA TCS EM CLP
4.1 INTRODUÇÃO
Na solução de problemas de automação da manufatura por meio da Teoria de
Controle Supervisório (TCS) modela-se o comportamento da planta como um Sistema a
Eventos Discretos (SED) e, autômatos de estados finitos são usados para descrever a planta,
as especificações e os supervisores.
A TCS considera que os eventos são assíncronos e discretos no tempo, essa
consideração reduz consideravelmente a síntese dos supervisores. Porém, na prática ao se
utilizar um Controlador Lógico Programável (CLP), como sistema de controle. Devido à
forma cíclica de processamento do código, a detecção dos eventos gerados pela planta física
pode levar o sistema a interpretar que tais eventos foram gerados ciclicamente. Assim, essa
diferença entre a teoria e a prática pode manifestar uma serie de problemas.
Também deve ser levado em consideração que a TCS considera que todos os eventos
são gerados pela planta. Porém, na prática o CLP promove geração de eventos na planta física
ao realizar acionamentos.
Contudo, a implementação dos supervisores sintetizados a partir TCS, em um
sistema de controle não é trivial, principalmente quando se utiliza um CLP como sistema de
controle.
Neste capítulo será realizada uma revisão de trabalhos que abordam alguma
metodologia para a implementação da TCS em sistemas de controle, dando ênfase os
procedimentos que envolvem CLPs. Também serão apresentados os principais problemas,
identificados na literatura, quando se realizar a implementação da TCS em CLP.
4.2 CONTROLADORES LÓGICOS PROGRAMÁVEIS
Os Controladores Lógicos programáveis (CLPs) são dispositivos de controle
especializados em controles lógicos de sistema automáticos ou semiautomáticos. Conforme
apresentado por Brandin (1996), esses dispositivos são projetados para trabalhar em
ambientes industriais em condições adversas de temperatura, umidade, ruído e vibração. São
muitas vezes programados em linguagem ladder, também conhecida por lógica de contato,
uma vez que esse tipo de linguagem é associado a dispositivos elétricos, como contatos e
bobinas. A linguagem ladder é uma linguagem gráfica, em forma de diagrama, que está
definida na IEC 61131-3 (IEC, 2003), norma internacional de programação de CLP, que
35
define outras quatro linguagens de programação. Na Tabela 4.1 apresentam-se as funções
básicas da linguagem ladder abordadas pela IEC 61131-3.
Tabela 4.1 – Comandos ladder abordados pela IEC 61131-3
SÍMBOLO NOME DESCRIÇÃO
-| |- Contato NA Contato normalmente aberto
-|\|- Contato NF Contato normalmente fechado
-(S) Liga bobina É ligada quando a linha está energizada e permanece ligada até que seja desligada
em outra parte do código.
-(R) Desliga bobina É desligada quando a linha está energizada e permanece desligada até que seja
ligada em outra parte do código.
-( ) Energiza bobina Permanece ligada enquanto a linha está energizada.
Ao longo dos anos os CLPs se mostraram muito versáteis, e suas aplicações só têm
aumentado, assim como sua capacidade de lidar com controles mais complexos, como
controle PID e controle hierárquico de plantas inteiras. No entanto, a sua herança original
ainda influencia seu comportamento (FABIAN e HELLGREN, 1988), seja na linguagem de
programação, como apresentado anteriormente, ou seja, na forma de processamento do
código. A forma de processamento do programa pelo CLP consiste em executar um único
programa sequencialmente do início ao fim repetidamente. Em cada ciclo de processamento,
(também conhecido como ciclo de varredura) o CLP lê os valores das entradas, processa a
lógica programada e ao final escreve nas saídas os novos valores estabelecidos.
O modelamento de um autômato em liguagem ladder, consiste em representar cada
estado e cada evento com variáveis internas, ou seja, bits de memórias (boolean), onde o
estado atual é dado pela memória que está assumindo o valor 1 e as memórias dos demais
estados estarão com o valor 0. Os eventos são identificados por borda de subida ou descida
dos bits, onde uma borda é detectada através da comparação de valor lógico entre o ciclo atual
e o anterior. A borda de subida é quando o valor muda de 0 para 1 (falso para verdadeiro), já a
borda de descida o valor muda de 1 para 0 (verdadeiro para falso).
O modelamento das transições é realizado por meio da lógica binária “e” (AND)
juntamente com os comandos de ligar (SET) e desligar (RESET), apresentados anteriormente.
Na Figura 4.1 a lógica “e” se dá entre a memória que representa o estado atual (G0.0) com a
memória que representa o evento que promove a transição (A). Quando o resultado da
operação “e” for satisfatório o próximo estado é definido ao ser ligada a memória que
representa o próximo estado (G0.1) e desligada a memória que presenta o estado atual (G0.0)
(HASDEMIR, KURTULAN, GÖREN, 2008). Assim, segundo Fabian e Hellgren (1998), na
36
implementação da estrutura de controle supervisório em Controladores Lógicos Programáveis
(CLPs), deve-se fazer com que o CLP se comporte como uma máquina de estados.
Figura 4.1 – Modelamento em ladder da transição do autômato
4.3 PROBLEMAS NA IMPLEMENTAÇÃO DA TCS EM CLP
A TCS considera que a evolução da planta é dirigida pela ocorrência de eventos
discretos, os quais possuem natureza instantânea (tempo de duração nulo) e assíncrona
(apenas um evento ocorre a cada instante). Por outro lado, a planta real e o seu elemento de
controle (CLP) têm sinais que estão sempre presentes nas entradas e saídas, só havendo
mudança em seus valores. Assim, na implementação de supervisores em CLPs é preciso
associar as mudanças nos valores destes sinais à ocorrência de eventos discretos e estabeler
uma interação entre planta e supervisor, porém ambos devem trabalhar em sincrônia.
Porém, uma vez definido que ageração de eventos será dada a partir da alteração dos
sinais, consequentimente esse processo de identificação dos enventos é realisado pelo CLP de
forma ciclica no início e no término de cada ciclo de varedura. Caso a planta gere dois
envetos durante um cilco de varedura do CLP, o sistema pode interpretar que os eventos
ocorreram simultaneamente. Uma vez violando uma premissa da TCS podem-se ter
complicações no controle da planta. E os atrasos, provenientes da atualização periódica do
CLP, pode romper a sincronia entre planta e supervisor.
Outro ponto que deve ser considerado, é que a TCS assume que a planta gera todos
os eventos (controlaveis ou não controlaveis), e o supervisor apenas promove a desabilitações
dos eventos controlaveis, restringindo minimamente o comportamento da planta. Por outro
lado, em uma plicação prática, alguns eventos são gerados na planta física e outros são
gerados pelo CLP, a partir dos acionamentos resultantes das alterações dos sinais de saídas.
Assim, a implementação da TCS em CLP, não é trivial e pode levar a alguns
problemas que serão apresentados a seguir.
37
4.3.1 Causalidade
A TCS assume que todos os eventos são gerados espontaneamente pela planta e que
os supervisores devem apenas estabelecer as desabilitações dos eventos controláveis a serem
gerados pela planta. A Figura 4.2 ilustra uma arquitetura de controle supervisório em
conformidade com está hipótese. Observe que o papel dos supervisores é estabelecer as
desabilitações dos eventos controláveis em conformidade com Ramadge e Wonham (1989).
Figura 4.2 – Arquitetura para TCS segundo Ramadge e Wonham (1989)
Porém, em uma aplicação prática os eventos controláveis não são gerados
espontaneamente pela planta física, mas são respostas a comandos do CLP (MALIK, 2002). A
Figura 4.3 ilustra uma arquitetura mais próxima da realidade onde o controlador, ou seja, o
CLP recebe informações do estado da planta física através de sensores ligados nas entradas e
atua no controle da planta ativando ou desativando saídas.
Figura 4.3 – Arquitetura realística
Desse modo, a implementação deve responder à seguinte questão “Quem gera o
que?” (FABIAN e HELLGREN, 1998), ou seja, quem será responsável pela geração de cada
evento: a planta ou o CLP.
Para atender fielmente a hipótese de Ramadge e Wonham (1989) de que os eventos
são espontaneamente gerados pela planta e de que o supervisor apenas desabilita eventos
controláveis, deve ser implementado no CLP o sistema produto (SP) como proposto por
Queiroz e Cury (2002). Nesta estrutura os autômatos que representam os subsistemas
assíncronos (representação por sistema produto) são implementados no CLP e são
responsáveis pela geração dos eventos controláveis. Assim todos os eventos são gerados no
sistema produto e os supervisores mantêm a função original de apenas estabelecer as
38
desabilitações dos eventos controláveis. A Figura 4.4 ilustra a arquitetura do sistema de
controle e a planta de acordo com a proposta de Queiroz e Cury (2002).
Figura 4.4 – Arquitetura proposta por Queiroz e Cury (2002)
4.3.2 Efeito avalanche
O efeito avalanche ocorre quando a mudança do valor no CLP é registrada por meio
de um evento e este provoca a transição indevida de mais de um estado do sistema num
mesmo ciclo de varredura do CLP. Resultando na quebra de sincronia entre a planta e o
supervisor implementado no CLP e, consequentemente, as futuras ações de controle serão
inválidas. A Figura 4.5 apresenta o autômato de uma determinada planta G0 que, dependendo
da forma em que for implementado no CLP, pode provocar o efeito avalanche. Note que a
ocorrência do evento A no estado 0 deve fazer com que o autômato transite para o estado 1,
ficando neste estado até uma nova ocorrência do evento A, ou a ocorrência do evento B.
Figura 4.5 – Autômato que proporciona o efeito avalanche
Na Figura 4.6 é apresentado um exemplo de código de CLP que poderia ser usado
para a implementação do autômato da Figura 4.5. Neste programa, G0.i representa o estado i
de G0 e A0.2 e B0.2 representam os eventos A e B, respectivamente. Veja que da forma em
que foi descrito o código do CLP, a ocorrência de um único evento A no estado 0 provoca
duas transições de estado, levando o programa para o estado 2 do autômato.
39
Figura 4.6 – Código do CLP que mostra o efeito avalanche
Uma forma de solucionar esse problema, conforme Queiroz, Santos e Cury (2001), é
controlar a execução do CLP para que apenas um evento seja tratado a cada ciclo de
varredura, limitando o desempenho do CLP. Entretanto, esta solução se mostra inadequada
para a metodologia proposta neste trabalho, uma vez que a intenção é tratar o maior número
de eventos em um mesmo ciclo de varredura do CLP.
Outra proposta para solucionar esse problema é apresentada por Fabian e Hellgren
(1998), onde a estrutura lógica associada a cada transição de estados deve ser implementada
em ordem reversa ao autômato. Assim, para o autômato apresentado na Figura 4.5, o código a
ser implementado no CLP é ilustrado na Figura 4.7. Porém, essa abordagem pode não
funcionar para alguns modelos de autômatos, ou seja, está solução só deve ser aplicado para
os autômatos que não apresentem ciclos na estrutura de transição (HASDEMIR,
KURTULAN, GÖREN, 2008).
Figura 4.7 – Código do CLP invertido para impedir o efeito avalanche
40
4.3.3 Simultaneidade
O problema chamado de simultaneidade também conhecido como incapacidade de
reconhecer a ordem de eventos não controláveis, não está relacionada com a forma em que é
realizada a implementação, e sim com a forma em que é realizado o processamento do CLP.
Devido à natureza cíclica de execução do programa do CLP, no qual a leitura dos seus sinais
de entrada é feita somente no início de cada ciclo de varredura. A ocorrência dos eventos não
controláveis da planta é identificada pelo CLP, a partir da alteração do valor dos sinais de
entrada. Assim, se entre uma leitura e outra das entradas, houver a mudança de valor de dois
ou mais sinais, haverá o registro simultâneo de ocorrência de eventos não controláveis. Note
que esta mudança nos sinais pode ser simultânea ou não, mas ela é registrada num mesmo
ciclo de varredura.
Entretanto, devido a natureza assíncrona dos modelos usados na TCS, não se tem
como representar a ocorrência simultânea de eventos. Para melhor ilustrar este problema,
considere a Figura 4.8. Note que na leitura das entradas feita em um k-ésimo ciclo de
varredura do CLP, as entradas 0 e 1 do CLP não estão ativas, mas durante este ciclo de
varredura ocorre uma mudança de nível no sinal da entrada 1 e logo em seguida ocorre uma
mudança de nível do sinal da entrada 0. No início do próximo ciclo de varredura é realizada
uma nova leitura das entradas e estas mudanças são detectadas, porém o programa do CLP é
incapaz de identificar qual das mudanças aconteceu primeiro, o que é conhecido na literatura
como incapacidade de reconhecer a ordem de eventos não controláveis (FABIAN e
HELLGREN, 1988).
Figura 4.8 – Processamento cíclico da leitura das entradas do CLP
Assim, para que o problema, descrito anteriormente, não se manifeste é necessário
que o sistema tenha a propriedade da insensibilidade ao entrelaçamento, conforme
apresentado por Fabian e Hellgren (1988).
A Figura 4.9 apresenta um autômato que evidencia esse problema. Estando no estado
1 a ordem da ocorrência dos eventos B e C leva o sistema a estados diferentes, sendo que em
cada um dos estados alcançados tem-se uma ação de controle diferente.
41
Figura 4.9 – Autômato que evidencia o problema de insensibilidade ao entrelaçamento
4.3.4 Sincronização inexata
Durante a execução do programa pode haver uma mudança em algum sinal de
entrada do CLP e, neste caso, esta mudança só será reconhecida no início do próximo ciclo de
varredura. Assim, pode-se dizer que a comunicação entre a planta e o CLP é sujeita a atrasos
devidos a atualização periódica dos sinais de entrada do CLP (BALEMI, 1992).
Segundo Fabian e Hellgren (1998), a sincronização inexata pode ser um problema
quando uma mudança num sinal de entrada do CLP invalida a ação de controle (geração de
um evento controlável).
Para ilustrar este problema, considere o autômato e o diagrama temporal mostrados
na Figura 4.10. Considere que num dado ciclo de varredura o programa do CLP esteja no
estado 1 deste autômato e que na leitura-k das entradas do CLP não tenha sido identificada
nenhuma mudança no sinal de entrada associado ao evento não controlável C. Suponha ainda
que durante a execução do programa é tomada a decisão de gerar o evento controlável B,
porém, antes de terminar o ciclo de varredura do CLP com a escrita k+1 (antes, portanto de
ter havido uma mudança no sinal de saída do CLP devido ao evento B) ocorra a mudança na
entrada do CLP referente ao evento C, invalidando então a ação de controle B para a escrita
k+1. Neste caso, o supervisor aplicou uma ação de controle inadequada em função de uma
perda de sincronismo entre a planta real e o programa de controle.
42
Figura 4.10 – Ilustração do problema da sincronização inexata
Note que a incapacidade de reconhecer a ordem de eventos não controláveis,
apresentado anteriormente é diferente da sincronização inexata. A primeira está relacionada
com a incapacidade do CLP, determinar a ordem em que os eventos não controláveis
ocorrerão no intervalo de duas leituras consecutivas. Já a segunda está relacionada a não
observação da ocorrência de um determinado evento não controlável, ao mesmo tempo em
que se toma a decisão de gerar um evento controlável.
Também é importante salientar que esses dois problemas não são gerados apenas
quando se utiliza a TCS para obter o código do CLP, esses problemas são provenientes do
modo cíclico de processamento do código pelo CLP. É possível que esses problemas possam
ser manifestados em uma solução obtida de forma empírica. Assim, para uma solução
convencional se faz necessário a realização de teste da lógica de controle para uma possível
detecção da existência do problema.
4.3.5 Escolha
Tendo em vista que os supervisores obtidos por intermédio da TCS são minimamente
restritivos, após a ocorrência de uma determinada sequência de eventos, pode haver múltiplas
opções para prosseguir no comportamento da planta. Assim, quando o sistema de controle é
responsável pela geração de uma parcela de eventos, a decisão sobre qual será o próximo
evento a ser gerado é compartilhada entre o sistema a ser controlado e o sistema de controle.
De acordo com Fabian e Hellgren (1998), no intuito de evitar uma série de problemas, “a
implementação tem que simultaneamente escolher e transitar; e somente um evento deve ser
escolhido”, ou seja, apenas um evento controlável deve ser gerado em cada ciclo de varredura
do CLP.
A Figura 4.11 apresenta um autômato de um supervisor hipotético S1, que
proporciona o problema da escolha. Após a transição do estado 0 para o estado 1 o supervisor
deve decidir qual será o próximo passo, gerar o evento B e transitar para o estado 2 ou gerar o
43
evento C e transitar para o estado 3. Esta escolha deve ser feita uma vez que os dois eventos
estão aptos a ocorrer e o sistema não pode gerar os dois eventos e estar em dois estados ao
mesmo tempo.
Figura 4.11 – Autômato para ilustrar o problema da escolha
A proposta apresentada por Fabian e Hellgren (1998) consiste em selecionar apenas
um evento entre as opções existentes, essa escolha pode ser intencional ou não, para o
autômato apresentado na Figura 4.11, o código ilustrado na Figura 4.12, prioriza a execução
de um evento em detrimento a outro(s), o que, de acordo com Malik (2002), pode fazer com
que uma parcela do comportamento do sistema deixe de ser realizada e é possível até que essa
escolha leve ao bloqueio do sistema mesmo tendo-se supervisores não bloqueantes.
Figura 4.12 – Programa que prioriza a execução do evento B com relação ao C
44
Considere por exemplo um supervisor representado pelo autômato da Figura 4.13. Se
no estado 1 for dada prioridade para o evento C com relação ao evento B, o sistema nunca
alcançará o estado 2, tornando se uma ação bloqueante já que não será completada uma tarefa
(sinalizada no estada 2). Por outro lado, se a prioridade for para o evento B, o supervisor
jamais alcançará os estados 3 e 5, o que levará parte do sistema a ficar inoperante.
Figura 4.13 – Supervisor não bloqueante cuja implementação pode ser bloqueante
4.4 CONSIDERAÇÕES SOBRE IMPLEMENTAÇÕES
Fabian e Hellgren (1998) abordam a implementação da TCS em CLPs, porém sem
uma metodologia definida para um projeto como um todo, e nem todos os problemas são
solucionados de forma genérica (HASDEMIR, KURTULAN, GÖREN, 2008).
Em (QUEIROZ e CURY, 2002b) e (QUEIROZ, 2004) é apresentada uma
implementação da TCS em CLP utilizando a linguagem ladder, para um tipo especifico de
modelo de autômato, onde para cada evento controlável deve existir um evento não
controlável de resposta, por fim, o código do CLP está estruturado por uma única rotina o que
dificulta o entendimento e não é apresentada uma metodologia para realizar a seleção de
eventos controláveis quando se tem o problema da escolha.
Assim, segundo Vieira (2007) esses pontos levantados se tornam uma limitação, e
contra partida, o autor apresenta uma metodologia de implementação, onde o código é
organizado em blocos de funções (Function Blocks) o que prevê diversos modos de operações
(automático, manual e falhas), porém é utilizada uma linguagem de alto nível Sequencial
Function Chart (SFC), que não é muito difundido entre os programadores de CLP, outro
agravante é que se faz necessário alterar o modelamento do autômato de modo a remover os
auto-laços (self-loops) e o autor não apresenta uma solução para o problema da escolha.
45
5 METODOLOGIA PARA IMPLEMENTAÇÃO DA TCS EM CLP
5.1 INTRODUÇÃO
Neste capítulo será apresentada uma proposta de metodologia para a implementação
da Teoria de Controle Supervisório (TCS) em Controladores Lógicos Programáveis (CLPs).
Essa proposta é a base do presente trabalho e tem como objetivo contribuir para que a TCS
seja mais utilizada em aplicações e ambientes industriais.
O desenvolvimento da metodologia adota o diagrama de contados (ladder) como a
linguagem de programação do CLP e os autômatos são implementados por máquinas de
estados assim como (FABIAN e HELLGREN, 1998), (QUEIROZ, SANTOS e CURY, 2001)
e (CURZEL e LEAL, 2006).
As propostas de implementação de supervisores em linguagem ladder existentes na
literatura, tais como as de (LEDUC, 1996), (HELLGREN et al, 2002) e (QUEIROZ e CURY,
2002), por exemplo, apresentam algo em comum, que é tratar um único evento por ciclo de
varredura do CLP. Este procedimento é usado para manter a coerência do sistema de controle
e evitar o efeito avalanche.
Assim, a dinâmica de processamento consiste em pelo menos um ciclo para atualizar
o sistema, e outro ciclo para promover a atuação na planta física. Tornado a atualização-
atuação do supervisor mais lenta do que aquela obtida via solução tradicional, sem a
utilização da TCS. Se durante um ciclo de varredura houvesse “n” mudanças nas entradas do
CLP, o programa levaria “n” ciclos de varredura para tratar estas informações (sinalizar a
ocorrência destes eventos na planta), aumentando a possibilidade de ocorrência de algum
problema decorrente do atraso de comunicação apontado por Balemi e Brunner (1992).
O principal objetivo da metodologia proposta é possibilitar o tratamento do maior
número de eventos possíveis em um mesmo ciclo de varredura, sejam esses eventos
controláveis ou não controláveis. E, como objetivo secundário, buscar solucionar os
problemas que possam vir a apresentar quando se utiliza a TCS para se determinar o programa
do CLP, onde a solução desses problemas é realizada visando sempre o objetivo principal.
5.1.1 Solução para o problema da Causalidade
Para responder a questão “Quem gera o que?” (FABIAN e HELLGREN, 1998) a fim
de atender fielmente a hipótese de que os eventos são espontaneamente gerados pela planta e
de que o supervisor apenas desabilita eventos controláveis. Será usada a solução a presentada
46
por Queiroz e Cury (2002), conforme apresentado na secção 4.3.1 onde a Figura 5.1 ilustra a
arquitetura do sistema de controle e a planta.
Outra vantagem que se tem ao implementar o sistema produto no CLP é que
possibilita utilizar os supervisores no formato reduzido. Quando se reduz um supervisor se
retira desse a informação de quais eventos são fisicamente possíveis de ser executados pela
planta. Porém, ao implementar o sistema produto no CLP essa informação é preservada.
Assim, ao reduzir o supervisor possibilita, em muitos casos, diminuindo o número de
estados e transições, consequentemente resultando em um consumo menor de memórias para
se representar o modelo dos supervisores no CLP.
Figura 5.1 – Arquitetura proposta por Queiroz e Cury (2002)
5.1.2 Solução para o Efeito Avalanche: Represamento
Para evitar o chamado efeito avalanche, propõem-se utilizar duas memórias para
cada evento não controlável, a primeira memória é usada para armazenar os eventos gerados
pela planta e a segunda para proporcionar as transições dos estados do sistema produto e dos
supervisores, represando a propagação do evento.
No intuito de ilustrar a solução proposta para eliminar o efeito avalanche, apresenta-
se na Figura 5.2 o código de CLP referente à implementação do autômato ilustrado
anteriormente na Figura 4.5. Note que a cada transição de estados é apagada a informação
relativa ao evento que ocasionou a transição. Dessa forma, uma vez estando no estado 0 e
ocorrendo a geração do evento A, ao executar a primeira linha do código o sistema irá
transitar para o estado 1, apagar a informação que estava no estado 0 e apagar a informação
que o evento A está ativo; quando executar a próxima linha de comando o chamado efeito
avalanche não se manifestará, uma vez que a informação que o evento A estava ativo foi
apagada.
47
Como o sistema produto é composto de subsistemas assíncronos, uma vez atualizado
com determinado evento não controlável, essa informação não seria mais usada até que esse
evento seja gerado novamente pela planta. Porém, a informação que determinado evento não
controlável está ativo pode ser usada em outra parte do código, principalmente para atualizar
os estados dos supervisores, uma vez que um determinado evento não controlável pode fazer
parte de mais de um supervisor. Assim, é necessário que a informação dos eventos não
controláveis que foram gerados pela planta seja resgatada antes de se atualizar cada
supervisor, o que é resolvido pelo uso de uma memória auxiliar.
Figura 5.2 – Código que evita o efeito avalanche
Dessa forma, a rotina de leitura das entradas deve monitorar as transições nos sinais
de entrada do CLP e salvar a informação que o evento foi gerado em uma memória e, para se
promover a transição de estados no sistema produto e nos supervisores deve ser usada outra
memória que tenha a mesma informação que foi estabelecida na leitura das entradas.
É importante salientar que em teoria o sistema produto também é possível ser
manifestado em eventos controláveis, porém os autores não observaram nenhuma aplicação
prática que pudesse gerar esse problema, de qual quer forma a solução adotada para os
eventos não controláveis poderia ser aplicada aos eventos controláveis também.
48
5.1.3 Solução para o problema da Escolha: Pseudo-aleatoriedade
Para resolver o problema da escolha, deve-se avaliar cada um dos supervisores
separadamente, identificando em quais estados este problema está presente e quais são os
eventos envolvidos na escolha em cada estado. O caso mais simples do problema da escolha é
quando estão envolvidos apenas dois eventos controláveis, como apresentado anteriormente
na Figura 4.11. Porém, problemas envolvendo mais de dois eventos controláveis são comuns
em aplicações reais. A Figura 5.3 apresenta um exemplo onde no estado 1, existe o problema
da escolha entre três eventos controláveis, veja que a geração de qual quer um dos eventos (B,
C ou D), que estão habilitados a ocorrer no estado 1, desabilita a geração dos demais eventos.
Figura 5.3 – Problema da escolha para mais de dois eventos
Também é possível que o problema da escolha envolva eventos individuais ou uma
lista de eventos. A Figura 5.4 apresenta um exemplo onde existe o problema da escolha entre
o evento B e os eventos C ou D, ou seja, o supervisor pode optar por gerar apenas o evento B
ou gerar os dois eventos C e D, transitando mais de um estado e chegando ao estado 5.
Figura 5.4 – Problema da escolha para uma lista de eventos
49
Neste ponto é importante explicar que no estado 1 da Figura 5.4 a escolha entre os
eventos C e D não se apresenta como um problema, pois independente da ordem desta
escolha, ao se gerar os eventos C e D a ação de controle resultante no estado 5 será o mesmo.
No intuito de melhor ilustrar esta questão, considere o autômato da Figura 5.5. Note
que no estado 1 o sistema deveria escolher entre gerar o evento D ou C, transitando para o
estado 2 ou 3, de modo que no próximo ciclo de varredura independente de qual desses
estados o sistema se encontra, a próxima ação a ser tomada levará para o estado 4. Assim, se
for gerado o evento D e posteriormente gerar o eventos C, transitando até o estado 4, a ação
de controle não é alterado caso se inverta a ordem de geração dos eventos, ou seja, se for
gerado o evento C e em seguida gerar o evento D, também irá levar ao estado 4. Com o intuito
de aumentar o número de eventos controláveis gerados num mesmo ciclo de varredura, a
solução proposta consiste em gerar ambos os eventos no mesmo ciclo de varredura do CLP,
gerando então os eventos (C e D) e transitando para o estado 4.
Figura 5.5 – Autômato que permite a geração de dois eventos
A seguir, apresenta-se um fluxograma, (ver Figura 5.6) que ilustra a metodologia
utilizada para verificar quais estados apresentam o problema de escolha e, para cada estado,
determina quais eventos fazem parte do problema da escolha.
Para resolver o problema da escolha após a rotina de desabilitações é verificado para
cada estado que apresenta o problema da escolha se este estado está ativo, e se os eventos
envolvidos no problema da escolha também estão ativos. Caso estejam, deve ser chamada
uma sub-rotina, que de maneira aleatória, a cada dois eventos não desabilitados que pertença
ao problema da escolha apenas um permanecer habilitado. A aleatoriedade se dá ao se utilizar
uma memória auxiliar que assume um valor diferente a cada ciclo de varredura.
50
Figura 5.6 – Fluxograma que determina se existe o problema da escolha
Para um problema que envolve apenas dois eventos na escolha, como o apresentado
na Figura 4.11, uma memória booleana auxiliar resolveria o problema. No lado esquerdo da
Figura 5.7 é apresentada parte da rotina principal do programa do CLP, após a chamada da
rotina de desabilitações a cada ciclo de varredura é alterado o valor da memória auxiliar,
chamada nesse caso de “AUX”. A condição para que seja chamada a sub-rotina que trata o
problema da escolha entre os eventos B e C leva em consideração o estado do supervisor e os
eventos envolvidos no problema da escolha. No lado direito da Figura 5.7 é apresentada a
sub-rotina que trata o problema da escolha. Se a memória “AUX” assumir o valor 1, a variável
d_B (desabilita B) é setada, o que implica em desabilitar o evento B. De outra forma, a
variável d_C (desabilita C) é setada e consequentemente o evento C é desabilitado.
A garantia de uma aleatoriedade na escolha se dá em função da mudança do valor da
memória “AUX”, a cada ciclo de varredura do CLP. Assim, em um determinado ciclo k,
quando for necessário utilizar a memória “AUX” em um tratamento da escolha, esta irá
51
assumir o valor 0 ou 1 aleatoriamente, uma vez que não se tem controle de em qual ciclo será
realizado um tratamento do problema da escolha.
Figura 5.7 – Solução para o problema da escolha entre dois eventos
Quando o problema da escolha envolve mais de dois eventos, como no exemplo
apresentado na Figura 5.3, propõe-se que a aleatoriedade seja por pares de eventos. A Figura
5.8 apresenta parte da rotina do programa do CLP para o problema da escolha entre os
eventos B, C e D. No lado esquerdo da Figura 5.8 está ilustrada parte da rotina principal do
CLP, após a chamada da sub-rotina que trabalha as desabilitações e alterar o valor da
memória auxiliar, estão implementadas três condições para a chamada de cada sub-rotina, que
trata o problema da escolha entre cada par de eventos, ou seja, deve-se escolher entre os
eventos (B e C), (C e D) ou (B e D) de modo a se escolher apenas um. Esta leva em
consideração o estado do supervisor e o par de eventos envolvidos em cada sub-rotina que
será chamada ou, não.
No lado direito da Figura 5.8 são apresentadas a sub-rotinas que tratam o problema
da escolha para cada par de eventos. Para a primeira sub-rotina, se a memória “AUX” assumir
o valor 1, a variável d_B (desabilita B) é setada, o que implica a desabilitação do evento B.
Caso contrário, a variável d_C é setada e o evento C é desabilitado. Da mesma forma para a
segunda sub-rotina apresentada, se a memória “AUX” assumir o valor 1, o evento C é
desabilitado, caso contrário o evento D será desabilitado. Para a terceira sub-rotina ilustrada,
se a memória “AUX” assumir o valor 1, o evento D será desabilitado, caso contrário o evento
desabilitado será o B.
Note que não necessariamente todas as rotinas devem ser chamadas, pois caso um
evento já esteja desabilitado não é necessário levar em conta este evento na decisão de
escolha. Veja também que para o exemplo apresentado, após a chamada das sub-rotinas
apenas um evento permanecerá habilitado. Assim, estado todos os eventos habilitados e se a
memória “AUX” estiver como valor 1 apenas o evento B permanecerá habilitado, do contrario
caso a memória “AUX” estiver como valor 0 apenas o evento D permanecerá habilitado.
52
Figura 5.8 – Solução para o problema da escolha entre mais de dois eventos
É importante salientar que realmente para mais de dois eventos, envolvidos no
problema da escolha, uma única memória auxiliar não irá promover a aleatoriedade entre
todos os eventos, uma vez que uma única memória pode assumir apenas dois valores. Seriam
necessárias mais memórias auxiliares, dependendo da quantidade de eventos envolvidos no
problema da escolha, ou então, estabelecer outra estratégia que promovesse a aleatoriedade.
Uma solução para esse caso em especifico foi apresentado por Pinotti, Leal e Oliveira (2010),
onde é usada uma memória do tipo numérica que a cada ciclo de varredura do CLP tem seu
valor alterado, assim quando é necessário estabelecer a escolha está será determinada pelo
valor correspondente a memória numérica.
Porém conforme apresentado anteriormente, e diferentemente do que foi apresentado
por Pinotti, Leal e Oliveira (2010), o tratamento da escolha, independente do número de
eventos envolvidos, deve ser realizado agrupando os eventos aos pares, de modo que apenas
um evento permaneça habilitado, ou seja, em hipótese alguma o tratamento do problema da
escolha pode estabelecer a desabilitação para todos os eventos.
Por fim, quando o problema da escolha envolve uma lista de eventos, como
apresentado na Figura 5.4, a solução do problema se dá tratando a lista de eventos com lógica
or, como mostra a Figura 5.9. No lado esquerdo da Figura 5.9 é apresentado parte da rotina
principal do programa do CLP. Note que a condição para a chamada da sub-rotina que trata o
problema da escolha deve ser feita como apresentado anteriormente, porém os eventos que
fazem parte da lista de eventos a serem desabilitados ou não, devem ser dispostos em paralelo
formando a lógica “ou”.
Assim, se pelo menos um evento da lista não estiver desabilitado (C ou D) e o evento
B também não estiver, deve-se escolher entre a lista (C e D) ou o evento B. Conforme pode
53
observar na sub-rotina que trata o problema da escolha (lado direito da Figura 5.9),
dependendo do valor da memória auxiliar, é feita a desabilitação do evento B ou de ambos os
eventos (C e D) da lista.
Figura 5.9 – Solução para o problema da escolha para uma lista de eventos
É importante observar que o problema da escolha se dá entre eventos controláveis
habilitados em um estado de um mesmo supervisor, e não entre eventos de supervisores
distintos. Assim, a análise do problema da escolha é feita sempre para cada supervisor
isoladamente.
5.1.4 Considerações sobre os demais problemas
Para a incapacidade de reconhecer a ordem de eventos (simultaneidade) e
sincronização inexata não foi desenvolvido nenhum tratamento específico neste trabalho, pois
se considera que esses problemas não são tratáveis devido à forma de funcionamento dos
CLPs, que ciclicamente lê as entradas, processa o código e atualizando as saídas. Também
não se encontrou na literatura algum trabalho que apresentasse uma solução, ficando assim
um ponto a ser pesquisado em trabalhos futuros. Porém, é importante salientar que esses
problemas não são exclusivos da implementação da TCS em CLP, em soluções convencionais
onde não se utiliza a TCS, esses problemas também podem se manifestar.
Nesse caso, a vantagem de se usar a TCS, é que se tem conhecimento desses
problemas, quando existentes, durante o projeto de controle do sistema. Já em uma aplicação
convencional, não se tem conhecimento desses problemas. O que leva a necessidade de se
realizar testes de funcionamento do sistema para validação da lógica de controle.
Encontra partida, nem todos os modelamentos irão apresentar esses problemas,
assim, para que a estrutura de controle supervisório modular local possa ser implementada
sem que estes problemas se manifestem, o modelamento deve apresentar algumas
propriedades.
Para poder garantir que problemas relacionados à incapacidade de reconhecer a
ordem de eventos não se manifestarão no sistema, deve-se garantir que os autômatos que
54
modelam cada um dos supervisores apresentem a propriedade da insensibilidade ao
entrelaçamento de eventos não controláveis (FABIAN e HELLGREN, 1998).
Da mesma forma, para poder afirmar que o problema da sincronização inexata não
irá ocorrer no sistema, deve-se garantir que a linguagem gerada por cada um dos autômatos
dos supervisores, e consequentemente pelos supervisores, tenha a propriedade de ser
insensível ao atraso (BALEMI e BRUNNER, 1992).
5.1.5 Tratamento de múltiplos eventos
A proposta de implementação da TCS em CLP está baseada no fluxograma ilustrado
na Figura 5.10. Grosso modo, utiliza-se a estrutura de controle apresentada por Queiroz e
Cury (2002), na qual os supervisores modulares locais e o sistema produto (SP) são
implementados no CLP, porém a ordem para a implementação desses elementos é feita
separando-os em blocos de eventos, de acordo com a controlabilidade dos eventos.
Ou seja, as transições dos autômatos são implementadas em pontos diferentes ao
longo do código do CLP, dependendo apenas se a transição envolve um evento controlável ou
não controlável. Essa definição da implementação conforme a controlabilidade do evento foi
o ponto de partida para o desenvolvimento da metodologia apresentada nesse trabalho, o que
levou aos autores a batizar a metodologia de DICCE9 (Definição da Implementação
Conforme a Controlabilidade do Evento) sendo que o número 9 corresponde aos nove passos
que devem ser seguidos para realizar a implementação, conforme será apresentado na próxima
secção.
Primeiramente são implementadas todas as transições que envolvem apenas eventos
não controláveis, e após são implementadas as transições que envolvem os eventos
controláveis.
Ao escrever o programa de forma a tratar os eventos na ordem “eventos não
controláveis – desabilitações – eventos controláveis”, consegue-se tratar num único ciclo de
varredura todos os eventos não controláveis gerados pela planta, identificados na leitura das
entradas do CLP, atualizando os estados dos subsistemas e dos supervisores.
Uma vez estando o sistema produto e os supervisores atualizados, deve se em
seguida definir o conjunto de eventos desabilitados pelos supervisores a partir do estado em
que cada supervisor se encontra.
A partir da lista de eventos habilitados, em nível de sistema produto são identificados
quais eventos controláveis são possíveis de serem gerados na planta física. Assim, a cada
55
transição realizada no sistema produto, com um evento controlável que não está desabilitado,
é gerado o respectivo evento promovendo a atualização dos estados do sistema produto.
Finalmente, a partir dos eventos que foram gerados no sistema produto, serão
atualizados os estados dos supervisores. E a transferências dos eventos gerados no sistema
produto para a planta física será ao final do ciclo de varredura, com a escrita das saídas.
Figura 5.10 – Fluxograma da rotina principal
Dessa forma, se entre leituras consecutivas duas ou mais entradas do CLP tiverem
mudanças de sinal, correspondendo a ocorrências de eventos não controláveis na planta, então
o programa do CLP, desenvolvido a partir da metodologia proposta, irá tratar todos os eventos
não controláveis independente da ordem em que estes foram gerados. Assim, uma vez
atualizado o sistema produto e os supervisores com todos os eventos gerados pela planta, a
rotina que promove as desabilitações dos eventos controláveis estará em sincronia com o
estado da planta física, passando-se então à etapa de geração de eventos.
A metodologia propõe que, o CLP gere num mesmo ciclo de varredura todos os
eventos controláveis que não foram desabilitados ao final da rotina de desabilitações. Desde
que esses eventos não fazem parte de um problema da escolha. Isto pode ser feito uma vez
que a geração de um dos eventos controláveis não irá alterar a ação de controle com relação
aos demais eventos controláveis a serem gerados.
Para melhor entendimento desta questão considere os dois supervisores modulares
(S1 e S2) apresentados na Figura 5.11. Estando ambos no estado inicial, os únicos eventos
controláveis que estariam habilitados a ocorrer, após a rotina de desabilitações seriam os
eventos A1 e A4. Logo, ambos os eventos poderiam ser gerados no mesmo ciclo de varredura,
pois esses eventos controláveis não são compartilhados entre os supervisores e,
consequentemente a ação de controle de um determinado supervisor, não é alterada em função
de um evento que não faz parte desse supervisor.
56
Agora, caso S1 esteja no estado 1 e S2 esteja no estado 0, os únicos eventos
habilitados seriam os eventos A2 e A4, note que para o supervisor S2 os eventos em questão
fazem parte de um problema da escolha, e assim de acordo com a metodologia proposta, um
dos dois eventos deve ser desabilitado. Esta decisão deve ser tomada aleatoriamente e caso
seja determinado que o evento A2 seja desabilitado, apenas o supervisor S2 irá transitar de
estado com o evento A4, do contrário os dois supervisores irão promover transição de estados
com o evento A2.
Figura 5.11 – Geração de múltiplos eventos controláveis
5.1.6 Detalhamento da Metodologia Proposta
A metodologia para implementação da TCS modular local em CLP, organiza o
programa do CLP em sub-rotinas as quais são chamadas por uma rotina principal. Esta
estruturação é possível ser implementada nos CLP existentes no mercado e levar a um
programa estruturado e organizado, facilitando sua interpretação e manutenção. Além disso,
permite-se que uma mesma sub-rotina possa ser chamada mais de uma vez ao longo da rotina
principal, o que pode levar a reaproveitamento de código e à diminuição do programa.
Com o intuito de organizar o programa e facilitar seu entendimento, devem ser
criadas dez sub-rotinas e a ordem de chamada dessas sub-rotinas é fundamental para o correto
funcionamento programa. Assim, pode-se expandir o fluxograma apresentado na Figura 5.10
para o fluxograma apresentado na Figura 5.12, onde são incorporadas as sub-rotinas de leitura
e escrita do CLP, inicialização dos estados dos autômatos e tratamento do problema da
escolha, como será detalhado seguir em nove passos.
Note que na Figura 5.10, a sub-rotina nomeada de “Resgata os eventos gerados pela
planta” é chamada mais de uma vez ao longo do ciclo de varredura.
57
Figura 5.12 – Fluxograma da rotina principal completo
O primeiro passo consiste em setar as memórias que representam os estados iniciais
dos supervisores e dos subsistemas que compõem o sistema produto, já os demais estados
devem ser resetados. Esse procedimento deve ser realizado apenas uma única vez, no primeiro
ciclo de varredura do CLP.
O segundo passo consiste em realizar a leitura das entradas do CLP e identificar
quais eventos foram gerados pela planta, de acordo com a identificação de alterações nos
sinais de entrada do CLP correspondente aos eventos não controláveis. A Figura 5.13
apresenta, no seu lado direito, um exemplo de rotina que pode ser usada para identificar a
geração dos eventos B e D, para o autômato apresentado no lado esquerdo da mesma figura.
Nesta rotina, a cada mudança do sinal de entrada I0.0, de zero para um é identificado que o
evento B foi gerado pela memória B0.1. Da mesma forma, o evento D, representado pela
memória D0.1, é gerado toda vez que se tem uma alteração no valor da entrada I0.1, de zero
para um.
58
Figura 5.13 – Identificação da transição na entrada e geração de evento
O terceiro passo é promover as transições de estados para todo o sistema produto
com todos os eventos não controláveis que acabaram de ser identificados. Para isso são
implementadas apenas as transições pertencentes ao sistema produto que envolve eventos não
controláveis, lembrando que a cada transição realizada com um determinado evento a
informação que o evento estava ativo é apagada a fim de evitar o efeito avalanche. A Figura
5.14 mostra o código do CLP que promove a transição de estados para o autômato
apresentado na Figura 5.13.
Figura 5.14 – Transição com eventos não controláveis no sistema produto
No quarto passo, todos os supervisores implementados também devem realizar as
transições de estados com os eventos não controláveis. A estrutura do código do CLP a ser
implementado nos supervisores é a mesma estrutura usada no sistema produto que foi
apresentado na Figura 5.14. Da mesma forma, apenas as transições dos supervisores que
envolvam os eventos não controláveis devem ser implementadas nesse momento. A Figura
5.15 apresenta no lado esquerdo o autômato de um supervisor e no lado direto o programa do
CLP que promove a transição de estados para os eventos não controláveis existentes.
59
Figura 5.15 – Transição com eventos não controláveis nos supervisores
Como a informação que o evento ativo foi apagado durante a atualização do sistema
produto, antes de se atualizar cada supervisor deve-se resgatar a informação de quais eventos
não controláveis foram gerados pela planta. Para isso, cada evento não controlável utiliza duas
memórias, uma memória é usada para armazenar quais eventos foram gerados pela planta e a
outra é usada para promover a transição de estados e será apagada em seguida.
A Figura 5.16 apresenta um exemplo de código de CLP para atualizar quais eventos
não controláveis foram gerados. Para o evento B são usadas as memórias B0.1 e B0.2 onde na
memória B0.1 é armazenada a informação que o evento B foi gerado, como ilustrado a Figura
5.13, e a memória B0.2 é utilizada para promover a transição do estado, como foi apresentado
na Figura 5.14 e Figura 5.15.
Figura 5.16 – Resgata os eventos gerados pela planta
Desta forma se dá prioridade para o tratamento de eventos não controláveis,
mantendo o estado do sistema produto e os estados dos supervisores em sincronia com o
estado da planta física, evitando-se o efeito avalanche.
O quinto passo não se difere em nada do que foi proposto por Queiroz e Cury (2002),
onde, a partir do estado atual dos supervisores verificam-se quais eventos estão desabilitados
60
pelo conjunto de supervisores. A Figura 5.17 apresenta no lado direito, um exemplo de código
de CLP que promove as desabilitações dos eventos controláveis para o supervisor ilustrado no
lado esquerdo da mesma. Note que as memórias d_A0.0 e d_C0.0 apresentam a informação
acerca da desabilitação ou não dos eventos controláveis A e C.
Figura 5.17 – Desabilitações dos eventos controláveis
O sexto passo leva em consideração os estados em que se encontra cada um dos
supervisores, e a lista de eventos controláveis não desabilitados em cada um desses estados.
Assim, se algum dos supervisores apresentar o problema da escolha, esta deve ser realizada
aleatoriamente. A estrutura do código a ser implementado depende de cada caso, conforme
apresentado anteriormente na seção 5.1.3. Por outro lado se nenhum supervisor apresentar o
problema da escolha o sexto passo não será implementado.
Já o sétimo passo corresponde à geração dos eventos controláveis que não foram
desabilitados anteriormente e são possíveis de ocorrer na planta. Esta geração de eventos é
feita no nível do sistema produto e é seguida da atualização de estados do sistema produto
devido a estes eventos. Assim, nesse passo devem ser implementadas todas as transições que
envolvem os eventos controláveis presentes no sistema produto que não foram implementadas
no segundo passo, completando assim a implementação do sistema produto no CLP.
Na Figura 5.18 apresenta-se um exemplo de programa de CLP para a atualização do
sistema produto referente ao autômato mostrado ao lado esquerdo da mesma. Quando a planta
G1 estiver no estado 0 e o evento A não estiver desabilitado (com a memória d_A0.0 não
energizada) o sistema promove a transição para o estado 1, apaga a informação que a planta
estava no estado 0 e gerando o evento A, setando a memória A0.1.
61
Figura 5.18 – Geração dos eventos controláveis
No oitavo passo é realizada a atualização dos estados dos supervisores com os
eventos controláveis que foram gerados no passo anterior, ou seja, são implementadas todas
as transições dos supervisores que apresentam eventos controláveis que não foram
implementas no terceiro passo, completando assim a implementação dos supervisores no
CLP. Na Figura 5.19 apresenta-se o código do CLP que promove as transições dos estados
para o supervisor apresentado ao lado esquerdo da mesma. Note que estando no estado 0 o
supervisor deve transitar para o estado 1, com a geração do evento controlável A, realizada
anteriormente no sistema produto, conforme foi apresentado na Figura 5.18.
Figura 5.19 – Transição dos supervisores com eventos controláveis
Assim, a partir dos dois últimos passos, antes mesmo da atuação física nas saídas do
CLP decorrentes dos eventos controláveis gerados, o sistema produto e os supervisores
estarão antecipando o estado da planta física. Note também, que teoricamente existe a
possibilidade de existir o problema do efeito avalanche para eventos controláveis. Porém não
foi estabelecido nenhum procedimento para tratar esse tipo de problema nos dois últimos
passos. Uma vez que, os autores entendem que, em uma aplicação prática, esse problema não
62
irá se apresentar. De qualquer forma, acaso exista um exemplo prático que velha a apresentar
esse tipo de problema, poderia ser utilizada a mesma abordagem que foi apresentada para
evitar esse problema no tratamento dos eventos não controláveis.
No nono e ultimo passo, são transmitidos para a planta física os eventos controláveis
que foram gerados anteriormente, ou seja, os eventos mapeados promovem acionamentos das
saídas do CLP, gerando os eventos na planta física e dá-se início a um novo ciclo de
varredura. Na Figura 5.20 apresenta-se o código do CLP que atualiza as saídas Q0.0 e Q0.1, a
partir dos eventos gerados no sistema produto, representado pelo autômato ao lado esquerdo
da mesma. Veja que quando o evento é transformado em comando para a saída, a informação
que o evento estava ativo é apagada. Note também que é necessário estabelecer uma condição
para que o sinal de saída seja resetado.
No exemplo em questão a geração dos eventos não controláveis que está fazendo
esse papel, porém poderia ser qualquer outro evento até mesmo ser apenas um pulso onde a
largura deste seria dada por um temporizador. Em fim, o importante é que o reset dos sinais
de saídas deve ser realizado antes da geração dos eventos controláveis, para que não haja a
possibilidade de uma condição de reset desabilitar um evento antes de este evento ser
transmitido a planta física.
Figura 5.20 – Transição dos supervisores com eventos controláveis
5.2 ESTUDO DE CASO
Com o objetivo de ilustrar a metodologia de implementação proposta nesse trabalho,
a seguir será apresentada a solução completa de um problema de controle supervisório,
mostrando desde o modelamento da planta e das especificações, a síntese dos supervisores,
até a obtenção do código ladder referente à lógica de controle que deve ser implementada no
CLP a fim de garantir o correto funcionamento do sistema.
63
5.2.1 Descrição do sistema físico
O problema a ser estudado consiste em uma linha de transferência industrial
composta por seis máquinas Mx (com X = 1,..., 6) ligadas por quatro buffers By (para y = A, B,
C e D), com capacidade de uma peça, dispostas como mostrado na Figura 5.21. O inicio de
operação das máquinas são eventos controláveis, já o término de operação são eventos não
controláveis. A linha deve trabalhar de modo a transportar as peças pelas máquinas, porém
uma máquina não pode iniciar a operação se não tiver peça no buffer de alimentação.
Por outro lado, havendo uma peça em um determinado buffer não pode ser
depositada outra peça nesse buffer. Já as máquinas M1 e M3, como não apresentam buffer de
entrada devem considerar que sempre existirão peças disponíveis para essas máquinas. De
forma semelhante, por não apresentar buffer de saída, a máquina M6 poderá liberar quantas
peças produzir sem qualquer restrição. Esse problema foi estudado por Queiroz e Cury (2000)
e foi escolhido por ser simples e ao mesmo tempo apresentar os problemas que se quer
estudar.
Figura 5.21 – Linha de transferência industrial
Na Tabela 5.1 apresenta-se uma lista dos eventos associados ao funcionamento de
cada máquina, bem como o tipo do evento de acordo com a sua controlabilidade, a descrição
do evento e a qual entrada (I) ou saída (Q) do CLP o evento está associado.
Tabela 5.1 - Eventos dos dispositivos da célula
DISPOSITIVO EVENTO TIPO DE EVENTO DESCRIÇÃO I/O
Máquina 1 A1 Controlável Início de operação da máquina 1 Q0.0
B1 Não controlável Término de operação da máquina 1 I0.0
Máquina 2 A2 Controlável Início de operação da máquina 2 Q0.1
B2 Não controlável Término de operação da máquina 2 I0.1
Máquina 3 A3 Controlável Início de operação da máquina 3 Q0.2
B3 Não controlável Término de operação da máquina 3 I0.2
Máquina 4 A4 Controlável Início de operação da máquina 4 Q0.3
B4 Não controlável Término de operação da máquina 4 I0.3
Máquina 5 A5 Controlável Início de operação da máquina 5 Q0.4
B5 Não controlável Término de operação da máquina 5 I0.4
Máquina 6 A6 Controlável Início de operação da máquina 6 Q0.5
B6 Não controlável Término de operação da máquina 6 I0.5
64
5.2.2 Modelos dos dispositivos da planta
O comportamento de cada máquina Mx (X = 1,..,6) é representado pelo autômato Gx
da Figura 5.22. Cada máquina apresenta apenas dois estados, sendo que no estado 0 a
máquina está parada aguardando peça, e no estado 1 a máquina está trabalhando uma peça.
Conforme a Tabela 5.1, o início de operação é um evento controlável Ax, e o final de operação
um evento não controlável Bx.
Figura 5.22 - Autômato das máquinas Gx para x = 1, 2, 3, ..., 6
5.2.3 Modelo das especificações
A Teoria proposta por Ramadge e Wonham (1989) prevê que a partir de
especificações que traduzam as condições desejadas para a operação do sistema, obtêm-se os
supervisores que devem ser usados de forma a garantir este comportamento da planta em
malha fechada (sob a ação dos supervisores). Nesta seção são apresentadas as especificações
que determinam como deve ser a operação coordenada dos dispositivos para o problema
proposto anteriormente.
O autômato representado pela Figura 5.23, representa a especificação para controle
dos buffers de forma a evitar underflow e overflow nos mesmos: BA para x = 1, BB para x = 3 e
BD para x = 5.
Figura 5.23 - Especificações dos buffers BA para x=1, BB para x=3 e BD para x=5
A especificação representada pelo autômato da Figura 5.24 também previne o
underflow e overflow do buffer BC, assim a máquina M5 só estará habilitada a iniciar a
operação após ser depositada uma peça, pela máquina M2 ou pela máquina M4, em seu buffer
de entrada. Uma vez depositada uma peça só poderá ser depositada uma nova peça após o
início de produção da máquina. Note que deve ser feito uma aleatoriedade para que impeça
que a máquina M5 sempre trabalhe peça de uma única máquina M2 ou M4.
65
Figura 5.24 - Especificação do buffer BC
5.2.4 Síntese dos Supervisores Modulares Locais
Nesta abordagem a ação de controle é distribuída entre vários autômatos
denominados supervisores locais, onde cada um deles representa a máxima linguagem
controlável para cada planta local. Desta forma, cada supervisor local coordena uma parte do
sistema global.
Na extensão à TCS proposta por Queiroz e Cury (2000), o problema de modelagem e
controle é abordado de forma modular. Esta abordagem permite que alterações somente
exijam mudanças no modelo específico correspondente, e não no sistema como um todo.
A partir dos modelos dos dispositivos que compõem a planta e das especificações de
funcionamento vistos nas seções 5.2.2 e 5.2.3, é preciso fazer a composição síncrona entre
estes modelos, conforme Queiroz e Cury (2000).
Primeiramente deve-se determinar o sistema produto. Para isso, é realizar a
composição síncrona para todas as subplantas que apresentam eventos em comum obtendo o
maior número possível de subsistemas assíncronos. Para o problema em estudo nenhuma
subplanta apresenta eventos em comum, logo os modelos apresentados na seção 5.2.2
corresponde o conjunto de subsistemas do sistema produto.
Em seguida, deve-se determinar o conjunto de plantas locais. Para isso deve ser
realizado o produto síncrono entre os subsistemas que são afetados diretamente ou
indiretamente por uma determinada especificação. A forma mais prática para levantar esse
cruzamento é por meio de uma tabela, como mostra a Tabela 5.2, assim as plantas locais são:
GLA=G1||G2, GLB=G3||G4, GLC=G2||G4||G5 e GLD=G5||G6. Do cruzamento da ocorrência do
evento pertencente em cada especificação com relação aos eventos pertencentes a cada
subplanta, deve verificar se alguma especificação pode ser agrupada. Para o problema em
estudo esse cruzamento não ocorre. Assim, não será necessário agrupar nem uma
especificação.
66
Tabela 5.2 – Eventos comuns entre modelos e especificações
M1 M2 M3 M4 M5 M6
A1 B1 A2 B2 A3 B3 A4 B4 A5 B5 A6 B6
EA X X
EB X X
EC X X X
ED X X
Na sequência deve-se realizar a composição síncrona das plantas locais com as
especificações, gerando as especificações locais: ELA = GLA�EA, ELB = GLB�EB, ELC =
GLC�EC e ELD = GLD�ED.
Por fim, calcula-se a máxima linguagem controlável para cada supervisor, denotada
SupC(GLy,ELy) para y = {A, B, C e D}. Assim, chega-se aos supervisores locais: SlocA, SlocB,
SlocC e SlocD, que estão apresentados na Figura 5.25 onde no lado direito são apresentados os
supervisores SlocA para z=1, SlocB para z=3 e SlocD para z=5 e ao lado esquerdo está apresentado
o supervisor SlocC.
Figura 5.25 – Supervisores modulares locais
Porém, é necessário assegurar a modularidade local do conjunto de supervisores
locais, garantindo que a ação conjunta de todos os supervisores seja não bloqueante, conforme
demonstrado por Queiroz e Cury (2000). A verificação da modularidade local consiste em
realizar a composição síncrona de todos os supervisores locais da seguinte forma: S =
SlocA||SlocB||SlocC||SlocD.
67
Após a composição síncrona, deve-se verificar o autômato resultante desta
composição não apresenta estados bloqueantes. Para então, poder afirmar que os supervisores
locais são modulares entre si.
A Figura 5.26 apresenta os supervisores calculados anteriormente e apresentados na
Figura 5.25, porém agora estes supervisores estão na forma reduzida (SU e WONHAM, 2001
e 2004) onde na esquerda se encontram os seguintes supervisores: SA para z=1, SB para z=3 e
SD para z=5, já à direta é apresentado o supervisor SC.
Figura 5.26 – Supervisores modulares locais reduzidos
Este procedimento busca diminuir ainda mais o número de estados dos supervisores.
A fim de reduzir a quantidade de memórias utilizadas na implantação desses supervisores
pode-se lançar mão de algumas ferramentas de redução dos supervisores, essas ferramentas
mantém a ação de controle para promover as desabilitações dos eventos controláveis, porém
os supervisores perdem informações sobre a planta, mas como o sistema produto será
implementado juntamente com os supervisores no CLP, as informações que foram perdidas ao
se reduzir os supervisores estarão preservadas no sistema produto.
5.3 IMPLEMENTAÇÃO CONFORME A METODOLOGIA PROPOSTA
A partir do fluxograma apresentado na Figura 5.12, que é resultante da metodologia
de implementação proposta, foi desenvolvido a Figura 5.27 que leva em consideração os
autômatos modelados que compõem o sistema produto da linha de transferência e os
autômatos dos supervisores sintetizados, que estão na sua forma reduzida. Assim, para cada
passo do fluxograma da Figura 5.12 é apresentado um balão correspondente, em cada balão
são apresentados quais estados e/ou eventos são envolvidos no respectivo passo.
68
Para um melhor entendimento da Figura 5.27 deve-se ressaltar que x corresponde à
quantidade de subsistemas que compõem o sistema produto, sendo x = 1,..., 6, e z corresponde
aos eventos dos seguintes supervisores SA para z=1, SB para z=3 e SD para z=5. Além disso, y
corresponde a todos os supervisores sendo y={A, B, C e D}, já para os balões que apresentam
autômatos são tratadas apenas as transições representadas por linhas cheias. Convém ressaltar
que as transições que não causam mudança de estado (self-loops), não precisam ser tratadas e,
portanto, não serão implementadas no CLP.
Figura 5.27 – Fluxograma dos estados e eventos
5.3.1 Rotina principal
No intuito de melhor organizar o programa do CLP, criou-se uma rotina principal
que chama blocos de funções (sub-rotinas) responsáveis pelo tratamento de cada bloco
ilustrado no fluxograma da Figura 5.12, assim a rotina principal é apresentada na Figura 5.28.
A ordem em que são chamadas as sub-rotinas está de acordo com a metodologia proposta para
implementação.
69
Figura 5.28 – Rotina principal
Dessa forma são criadas dez sub-rotinas, onde cada uma dessas sub-rotinas será
apresentada a seguir.
5.3.2 Inicialização dos estados
O primeiro balão apresentado na Figura 5.27, corresponde à inicialização dos estados
do sistema produto e dos supervisores, assim a memória correspondente ao estado inicial de
cada autômato deve receber o valor um. Já as demais memórias, que representam os demais
estados devem receber o valor zero, como mostra a Figura 5.29. Essa sub-rotina deve ser
chamada apenas no primeiro ciclo de varredura do CLP para que os estados iniciais dos
autômatos sejam informados corretamente, logo a memória “Primeiro ciclo” apresentada na
Figura 5.28, que chama a sub-rotina, deve receber o valor um apenas no primeiro ciclo do
CLP.
70
Figura 5.29 – Inicialização dos estados
5.3.3 Leitura das entradas
Na sequência do fluxograma apresentado na Figura 5.27 o segundo balão
corresponde à sub-rotina de leitura das entradas do CLP e identificação dos eventos não
controláveis, que foram gerados pela planta.
Essa sub-rotina deve ser chamada no início de cada ciclo de varredura do CLP, pois
ao realizar a leitura das entradas e verificar a existência de alguma transição positiva em uma
determinada entrada, é identificada a ocorrência de um evento não controlável correspondente
à entrada que apresentou a transição, essa relação está apresentada na Tabela 5.1. A Figura
5.30 apresenta a sub-rotina desenvolvida para o problema em estudo, onde a função “POS”
garante que o evento não controlável será identificado somente no ciclo de varredura no qual
ocorreu a transição do sinal de entrada (borda de subida), onde essa função é especifica para o
CLP que foi utilizada.
71
Figura 5.30 – Leitura das entradas e identificação dos eventos não controláveis
5.3.4 Resgate dos eventos não controláveis
Cada evento não controlável necessita de duas memórias, assim do grupo de eventos
não controláveis são estabelecidos dos grupos de memórias aqui nomeados de Mx.0 e Mx.1. O
primeiro grupo de memórias Mx.0 foi apresentado na seção 5.3.3, onde a função do primeiro
grupo de memórias Mx.0 é armazenar a informação de quais eventos foram gerados pela
planta.
Dessa forma, seguindo a sequência do fluxograma apresentado na Figura 5.27, o
terceiro balão corresponde à sub-rotina que atualiza um segundo grupo de memórias Mx.1,
com a informação que está armazenada no grupo Mx.0, de modo que o segundo grupo será
utilizado para promover as transições de estados do sistema produto e dos supervisores.
Como a informação de quais eventos a planta gerou está armazenada em Mx.0,
mesmo que Mx.1 perca essa informação ela poderá ser resgatada toda vez que for chamada a
sub-rotina, apresentada na Figura 5.31.
Figura 5.31 – Resgate dos eventos não controláveis
72
5.3.5 Atualização do sistema produto com os eventos não controláveis
O quarto balão da Figura 5.27, corresponde à sub-rotina que trata apenas os eventos
não controláveis do sistema produto, ou seja, esta sub-rotina é um jogador de autômatos.
Quando um ou mais eventos são gerados pela planta, o jogador de autômatos promove as
mudanças nos estados dos subsistemas. Assim, em um mesmo ciclo de varredura os
autômatos podem transitar de estados de acordo com a quantidade de eventos não controláveis
ocorridos na planta.
A informação acerca do estado atual de cada subsistema é atualizada conforme
mostrado na Figura 5.32, por exemplo, veja na primeira linha da sub-rotina, quando a planta
G1 estiver no estado 1 e o evento de término de produção B1 for identificado será realizada a
transição para o estado 0 e para evitar o efeito avalanche, ao transitar de estado é apagada de
B1.1 a informação que o evento estava ativo. Note que em um mesmo ciclo de varredura se
outro subsistema também estiver apto a proporcionar uma transição está será possível
também.
Figura 5.32 – Transições do sistema produto com eventos não controláveis
Como o sistema produto é composto por subsistemas assíncronos, um evento tratado
em um subsistema não irá ocorrer em outro, assim não há problema em apagar a informação
do evento no momento em que for registrada a sua transição.
73
5.3.6 Atualização dos supervisores com os eventos não controláveis
O quinto e o sexto balões da Figura 5.27, são implementados na sub-rotina que trata
os eventos não controláveis dos supervisores, ou seja, também se tem aqui um jogador de
autômatos, porém agora apenas com as transições de eventos não controláveis dos
supervisores representados no sexto balão.
Nos supervisores, que não são necessariamente assíncronos, pode acontecer de um
mesmo evento estar apto a proporcionar uma transição de estados em mais de um supervisor.
Portando, como a cada transição realizada por um evento, a informação de que esse evento
está ativo é apagada, evitando assim o efeito avalanche, deve se resgatar essa informação em
certos momentos. Assim, antes de executar o jogador de autômatos de cada supervisor é
necessário atualizar o grupo de memórias Mx.1 com a informação do grupo de memórias
Mx.0, representado no quinto balão da Figura 5.27, isso é feito chamando a sub-rotina
“Resgate dos eventos não controláveis”, como mostra a Figura 5.33. Note também que a
estrutura que promove a transição de estados é a mesma utilizada para atualizar o sistema
produto, como foi apresentado anteriormente, porém agora são levados em consideração os
estados dos supervisores.
Figura 5.33 – Transições dos supervisores com eventos não controláveis
5.3.7 Desabilitações de eventos controláveis
O sétimo balão, apresentado na sequência do fluxograma da Figura 5.27, consiste na
sub-rotina de desabilitações de eventos controláveis, ou seja, de acordo com o estado atual de
todos os supervisores, se determinam quais são os eventos controláveis que devem ser
desabilitados.
74
Uma vez atualizados os estados do sistema produto e dos supervisores com as
transições provocadas pelos eventos não controláveis gerados pela planta, pode-se dizer que
os autômatos implementados no CLP estão em sincronia com a planta, ou seja, estão nos
mesmos estados que a planta física se encontra
Assim, podem-se verificar quais eventos estão desabilitados pela ação conjunta dos
supervisores. O procedimento que promove a desabilitação dos eventos controláveis está
apresentado na Figura 5.34, note que diferentes estados de diferentes supervisores podem
desabilitar um mesmo evento.
Figura 5.34 – Desabilitações de eventos controláveis
5.3.8 Tratamento da escolha
Na sequência do fluxograma da Figura 5.27, o oitavo balão corresponde ao
tratamento do problema da escolha de eventos controláveis. Esta sub-rotina só deve ser
chamada quando necessária dependendo do estado de um determinado supervisor e dos
eventos envolvidos no problema da escolha. Para cada problema de escolha existente deve ser
criada uma sub-rotina diferente.
É possível que dois ou mais eventos controláveis não sejam desabilitados pelos
supervisores. Caso esses eventos pertençam a um mesmo supervisor pode ser que seja um
problema de escolha. No exemplo em estudo, as máquinas M2 e M4 não podem iniciar ao
mesmo tempo a produção, pois quando uma terminar de produzir esta deposita uma peça no
buffer de saída e a outra máquina ficaria impossibilitada de depositar a sua peça no buffer,
uma vez que as duas compartilham o mesmo buffer. Ou seja, quando o supervisor SC está no
estado 0, os eventos A2 e A4 não estão desabilitados, mas não podem ser gerados ao mesmo
tempo (ao final de um ciclo de varredura), pois a geração de um dos eventos desabilitará a
geração do outro, devendo-se então escolher qual deles será gerado no sistema produto.
De acordo com a metodologia proposta nesse trabalho, para resolver o problema da
escolha e ao mesmo tempo garantir que esta escolha não leve o sistema ao bloqueio, é
75
chamada uma sub-rotina após a rotina de desabilitação, que de maneira aleatória mantém
apenas um evento habilitado, para os eventos que estão envolvidos no problema da escolha.
Propõe-se então usar uma memória auxiliar chamada aqui de “AUX” que, conforme ilustrado
no fluxograma da Figura 5.28, a cada ciclo de varredura assume um valor diferente (0 ou 1).
Assim, para o problema em estudo, que apresenta o problema da escolha apenas para
os eventos A2 e A4 quando o supervisor SC está no estado 0, a condição para se chamar a sub-
rotina que trata o problema da escolha é apresentada na linha 7 da rotina principal ilustrada na
Figura 5.28. A sub-rotina chamada é apresentada na Figura 5.35, onde se a memória “AUX”
assumir o valor um, o evento A2 é desabilitado, caso contrário o evento A4 é desabilitado,
garantindo assim uma escolha aleatória.
Figura 5.35 – Escolha entre os eventos A2 e A4
5.3.9 Geração dos eventos controláveis no sistema produto
O nono balão do fluxograma da Figura 5.27, corresponde a um jogador de
autômatos, porém agora apenas os eventos controláveis do sistema produto são tratados,
assim, cada evento controlável não desabilitado e apto a ocorrer, levaria à transição do
sistema produto e à sinalização que determinado evento deve ser gerado pelo CLP,
proporcionando na planta física a ocorrência de um evento controlável.
É importante observar que o problema da escolha se dá entre eventos controláveis
habilitados em um estado de um supervisor, e não entre eventos de supervisores distintos.
Assim, pela metodologia proposta neste trabalho, num mesmo ciclo de varredura podem-se
gerar diversos eventos controláveis. Por exemplo, no problema em estudo, o início de
operação das máquinas M1 e M3 podem ocorrer ao mesmo tempo, e assim, ao final de um
determinado ciclo de varredura, podem ser gerados os eventos A1 e A3.
Na Figura 5.36 apresenta-se a estrutura do jogador de autômatos para o problema em
estudo. Observe que cada transição realizada no sistema produto corresponde à sinalização de
um determinado evento que deverá ser gerado.
76
Figura 5.36 – Geração dos eventos controláveis pelo sistema produto
5.3.10 Atualização dos supervisores com os eventos controláveis gerados
O décimo balão apresentado na Figura 5.27, corresponde a um jogador de autômatos
com apenas os eventos controláveis dos supervisores. Conforme apresenta a Figura 5.37, os
eventos controláveis identificados no sistema produto, devem promover as transições
atualizando os estados dos supervisores.
Figura 5.37 – Transições dos supervisores com os eventos controláveis
5.3.11 Escrita nas saídas
Por fim, no último balão da Figura 5.27, fechando o ciclo de processamento do CLP,
é realizada a atualização das saídas com as condições para reset dos sinais e a geração dos
eventos controláveis na planta física. Note na Figura 5.38 que inicialmente são implementadas
todas as condições de reset das saídas, para só então se implementar a geração dos eventos
com a ação nas saídas.
77
Figura 5.38 – Escrita nas saídas
78
6 FERRAMENTA DE GERAÇÃO AUTOMÁTICA DO CÓDIGO PARA O CLP
6.1 INTRODUÇÃO
Com o passar dos anos novas tecnologias são desenvolvidas, sejam melhorias ou
inovações em software como também em surgimento de novos dispositivos de hardware, com
mais capacidade de memória, processamento, segurança e etc. Porém, na indústria não se tem
uma evolução nas técnicas e metodologias utilizadas no desenvolvimento do projeto do
controle, onde o que prevalece é a experiência do desenvolvedor que estabelece a lógica de
controle do sistema de forma empírica.
A utilização de procedimentos que, de uma forma automática, se obtenha a síntese do
controle, ao invés dos procedimentos tradicionais (empíricos), como é o caso da Teoria de
Controle Supervisório (RAMADGE e WONHAM, 1989), agilizará a obtenção da solução de
controle, proporcionado uma padronização dos códigos gerados.
Conforme Hellgren et al. (2005, apud Vieira, 2007, p. 5), “apesar da grande
aceitação da Teoria de Controle Supervisório pelo meio acadêmico, havendo diversas
extensões à mesma e um número muito grande de publicações com foco em aspectos teóricos,
são raras as aplicações industriais. A razão principal para isto é o problema da implementação
física”.
A metodologia proposta neste trabalho busca, solucionar os problemas da
implementação da TCS em controladores lógicos programáveis (CLP) e para facilitar ainda
mais o acesso da indústria a essa teoria, foi desenvolvida uma ferramenta que elimina todo
trabalho braçal de escrita dos programas, gerando um programa estruturado conforme a
metodologia propõe.
6.2 APRESENTAÇÃO DA FERRAMENTA CCSSM
O objetivo do desenvolvimento da ferramenta para geração de código foi de auxiliar
na tarefa de escrita do código do CLP, de forma a automatizar a transcrição do autômato
obtido para o supervisor no código de programação do CLP. Assim, foi desenvolvida uma
ferramenta de geração automática de código para o CLP. Esta ferramenta foi desenvolvida,
como auxílio de bolsistas do Programa de Educação Tutorial – PET Engenharia Elétrica, que
desenvolveram toda interface e as rotinas de geração de códigos tendo como base a
metodologia proposta nesse trabalho. Tanto para a organização do programa como para a
criação das sub-rotinas, de modo a promover o tratamento do problema da escolha caso
79
exista. Assim, foi implementado o fluxograma apresentado na seção 5.1.3, que determina
quais estados apresentam o problema da escolha e para cada um desses estados, quais são os
eventos que fazem parte do problema da escolha e qual a disposição desses eventos. Portanto
para cada estado que apresenta o problema da escolha é estabelecido uma solução dependendo
da disposição dos eventos envolvidos no problema, conforme apresentado seção 5.1.3.
O CCSSM é um programa no qual, a partir de um arquivo de formato conhecido da
Teoria de Controle Supervisório oriundo de uma ferramenta computacional de síntese dos
supervisores, como por exemplo, os softwares Grail (REISER et al., 2006; CURY, 2001;
GARCIA, 2006), TCT (FENG e WONHAN, 2006) e IDES (RUDIE, 2006), é possível gerar o
programa no formato textual, para ser implementado diretamente em CLPs dos modelos
ControlLogix® e CompactLogix™ do fabricante Rockwell (ROCKWELL), ou seja, o código
final gerado pode ser carregado no software compilador desses CLPs RSLogix™ 5000 para
então ser convertido para a linguagem ladder.
No desenvolvimento da ferramenta foi estabelecido que ela deveria possibilitar a
inclusão de novas funcionalidades, ou seja, inicialmente seria desenvolvida a solução para um
determinado modelo de CLP. Porém com o avanço da ferramenta o objetivo será de gerar
códigos para os mais variados modelos de CLPs existentes, além de receber como entrada os
mais variados tipos de arquivos, provenientes dos softwares Grail, TCT e IDES, que são os
software mais utilizados no meio acadêmico, para modelagem da planta e geração dos
supervisores.
Com base nos requisitos apresentados anteriormente, foi estabelecido que a
ferramenta de programação do software de geração de código deveria ser aberta, ou seja,
qualquer usuário deveria ter acesso ao código fonte, assim foi escolhida a linhagem de
programação C# (também conhecido como C Sharp).
Para atender aos diferentes tipos de arquivos de entrada, foi estabelecido que a
ferramenta deveria converter o formato desses arquivos em um único formato, tendo assim
sempre um mesmo ponto de partida para desenvolver o gerador de código.
Como cada modelo de CLP apresenta um formato específico de arquivo para que
possa ser importado pelo compilador do mesmo, foi estabelecido que para cada modelo de
CLP fosse desenvolvida uma rotina especifica totalmente independente, tendo sempre como
entrada um mesmo tipo de arquivo.
A Figura 6.1 apresenta a arquitetura que foi estabelecida para o desenvolvimento da
ferramenta. O papel da interface é receber os arquivos provenientes do Grail, TCT ou IDES
para então gerar um arquivo único (de extensão CSM). Esse arquivo mantém as informações
80
dos supervisores sintetizados e o modelamento do sistema produto (SP). Para cada modelo de
CLP é desenvolvido um tradutor dedicado, que gera o arquivo a ser importado no CLP tendo
como base a metodologia proposta nesse trabalho. Veja que o desenvolvimento do tradutor é
facilitado uma vez que o arquivo de entrada (.CSM) estará sempre no mesmo formato.
Figura 6.1. Arquitetura da ferramenta de geração de código CCSSM
A interface da ferramenta de conversão é composta por telas que serão apresentadas
a seguir. A tela inicial, representada pela Figura 6.2, possibilita criar um novo projeto ou abrir
um projeto já existente, em formato CSM.
Ao criar um novo projeto deve ser informado qual foi o tipo de abordagem utilizada
na síntese do supervisor, tendo como opção apenas a abordagem modular local, porém a
interface já tem uma previsão, para que possa aceitar a abordagem monolítica também.
Outra informação necessária consiste em informar qual foi a ferramenta utilizada
para síntese do supervisor, seja o Grail, TCT ou IDES, visto que cada um deles tem suas
vantagens, porém no presente momento apenas está implementada para aceitar arquivos do
IDES.
Figura 6.2. Tela inicial
81
Ao confirmar as opções do arquivo o usuário tem acesso à segunda tela, representada
pela Figura 6.3. Nessa tela existem algumas abas, o usuário tem liberdade para percorrer por
todas as abas, essa divisão organiza o procedimento de geração do código.
A primeira aba (ver Figura 6.3), denominada de “Supervisors”, é utilizada para
adicionar ao projeto os arquivos dos supervisores sintetizados. Deve-se especificar o diretório
onde se encontra o arquivo e clicar no botão “Add”. A qualquer arquivo adicionado pode ser
removido, basta para isso selecionar o arquivo na lista e clicar no botão “Remove”. À medida
que vai se inserindo os supervisores ou se retirando supervisores já adicionados, a lista é
atualizada.
Figura 6.3. Inserir os supervisores
A segunda aba, denominada “Product Systems” está apresentada na Figura 6.4, é
utilizada para se adicionar ao projeto os arquivos que compõe o sistema produto que modelam
a planta física. Da mesma forma, que na aba anterior, deve-se especificar o diretório onde se
encontra cada arquivo e clicar no botão “Add”, para se adicionar o modelamento dos
subsistemas que compõe o sistema produto e qualquer arquivo adicionado pode ser removido.
82
Figura 6.4. Inserir sistema produto
A Figura 6.5 apresenta a terceira aba, denominada “Symbols”, onde se tem acesso a
novas três abas (ou sub-menu). No primeiro sub-menu, denominado “States” estão listados
todos os estados existentes, dos supervisores e do sistema produto que foram adicionados ao
projeto. Assim é possível, para cada estado estabelecer um nome para a memória que
representa o estado e criar uma descrição, de modo que quando for gerado o programa para o
CLP, essa descrição será incluída nos comentários do programa onde esse estado se encontra,
facilitando assim o entendimento do programa.
Figura 6.5. Descrição dos estados
83
Já no segundo sub-menu, apresentado pela Figura 6.6, denominado “Events”, são
listados todos os eventos existentes, sejam eles controláveis ou não controláveis,
possibilitando para cada evento inserir uma descrição do que ele representa, e essa descrição
será adicionada nos comentários ao longo do programa do CLP.
Outra função dessa tela é que, para cada evento controlável, é possível definir como
deverá ser o comportamento das saídas do CLP para transferir à planta os comandos dos
eventos que foram gerados no sistema produto, ou seja, pode ser criada uma sub-rotina que,
quando o evento é gerado essa sub-rotina é chamada, por outro lado existe a possibilitada de
se acionar uma saída digital especifica do CLP. Esta saída poderá ser ligada ou desligada até
que outro evento altere o estado dessa saída, ou ainda poderá ser criado um temporizador que
mantenha a saída ligada ou desliga por um tempo configurável.
Figura 6.6. Especificação de eventos controláveis
Já para os eventos não controláveis, como se pode ver na Figura 6.7, é possível
definir como deverá ser o comportamento da entrada física do CLP para que determinado
evento seja sensibilizado no programa. Por exemplo, se determinado evento for o
acionamento de um sensor, esse evento será gerado no programa quando o sinal proveniente
desse sensor proporcionar na entrada do CLP uma mudança de estado podendo ser, nesse
caso, a subida do sinal de nível baixo para nível alto ou poderia ser o contrário de nível alto
para nível baixo.
84
Figura 6.7. Especificação de eventos não controláveis
No último sub-menu, representado pela Figura 6.9, denominado “Output Reseters” é
possível estabelecer para cada saída digital que foi mapeada anteriormente e que não está
ligada a um temporizador. Ou seja, para todas saídas digitais cuja geração dos eventos apenas
liga ou desliga, pode-se estabelecer outro evento ou uma lista de eventos que, quando gerados,
alterem o estado desta determinada saída digital.
Figura 6.8. Condições para promover o reset dos sinais de saída CLP
85
Por fim na última aba, representada pela Figura 6.9 é possível selecionar para qual
modelo de CLP o projeto será convertido, o objetivo é que a ferramenta possa vir a gerar o
programa pronto para o CLP, visto que cada modelo de CLP tem suas características com
comandos específicos, mas todos no fundo são iguais, principalmente quando se usa apenas os
comandos mais simples existentes em todos os modelos de CLP.
Figura 6.9. Seleção do modelo de CLP
Porém, a tecnologia utilizada nos softwares de compilação dos CLPs é fechada, ou
seja, os proprietários impedem que usuários possam ter acesso ao código fonte, e também são
incompatíveis entre diferentes marcas de CLP. Algumas vezes, até mesmo entre diferentes
famílias de uma mesma marca são incompatíveis entre si, de modo a ser impossível gerar um
arquivo para uma determinada família de CLP e abrir esse arquivo no compilador de outra
família. Assim para solucionar esse problema a ferramenta gera um arquivo em um formato
específico para determinada marca de uma determinada família de CLP, descrevendo o
programa em um formato textual, de modo que este arquivo possa ser importado pelo
compilador, para então poder ser visualizado no formato ladder.
No momento a ferramenta está capacitada a gerar arquivos para o CLP da família
ControlLogix® e CompactLogix™ do fabricante Rockwell (ROCKWELL). Ou seja, a
ferramenta gera um arquivo na extensão L5X que pode ser aberto pelo compilador RSLogix™
5000. Esse procedimento será explicado a seguir com o acompanhamento de um estudo de
caso.
6.3 APLICAÇÃO DA FERRAMENTA
O problema aqui abordado foi apresentado por Groover (2001, apud Silva, Busetti,
Vieira, Santos, 2007), e trata de um sistema automático de produção de múltiplos produtos,
86
onde a sequencia de produção de um determinado produto pode ser diferente de outro
produto. A Figura 6.10 apresenta uma configuração genérica para o problema abordado.
6.3.1 Descrição do Problema
Considere nesse estudo a Figura 6.10 composto por três estações de trabalho (M1,
M2 e M3), onde cada máquina pode realizar operações diferentes sobre os produtos. Assim
cada estação de trabalho apresenta um buffer de entrada e um buffer de saída, totalizando seis
buffers (B1, B2, B3, B4, B5 e B6) e cada buffer tem capacidade para armazenar uma única
peça. Para se transportar as peças entre as máquinas será utilizado um robô. Para alimentação
de produtos ao sistema existe uma esteira de entrada (Inlet mat conveyor) com um buffer (B0)
de capacidade unitária. Para os produtos acabados existe uma esteira de saída (Outlet mat
conveyor) com capacidade infinita. O sistema pode processar dois tipos de produtos
diferentes, identificas de tipo A e B.
Figura 6.10. Sistema automatizado de rotas variáveis (GROOVER, 2001).
6.3.2 Modelos dos dispositivos da planta
No modelamento das estações de trabalho (M1, M2 e M3) leva-se em consideração o
tipo de produto que cada estação venha produzir, para o exemplo em questão o plano de
trabalho define que a peça tipo A deve passar pelas máquinas M1, M2 e M3, respectivamente
nessa ordem. Já para a produção do produto tipo B a peça deve passar pelas máquinas M1 e
M3, respectivamente nessa ordem.
A Figura 6.11 apresenta os autômatos das plantas G1, G2 e G3 correspondentes às
máquinas M1, M2 e M3, respectivamente. Para cada máquina o estado 0 representa o repouso.
87
Já os estados 1 e 2 representam as estações produzindo os produtos tipo A e B,
respectivamente. Os eventos �mtA e �mtB representam o início de operação das peças tipo A e
B, respectivamente e são eventos controláveis, já os eventos �mtA e �mtB, representam o final
de produção das peças tipo A e B, respectivamente e são eventos não controláveis.
Figura 6.11. Modelos das máquinas: a) G1, b) G2 e c) G3.
A Figura 6.12 apresenta o modelamento da esteira transportadora de entrada de
produtos no sistema. Onde o evento �es representa o início de operação da esteira, que é um
evento controlável. Os eventos �pA e �pB, representam o final de operação da esteira, com a
chegada de uma nova peça ao sistema do tipo A e B, respectivamente e estes eventos são não
controláveis.
Figura 6.12. Modelo da esteira transportadora G4.
O modelo do sistema de transporte é o que apresenta o maior número de estados,
como mostra a Figura 6.13. Veja que o modelo do robô deve possibilitar ele se mover em
todas as posições de entrada e saída de peça, porém serão permitidos apenas dois tipos de
movimento, para sair de um buffer de saída até um buffer de entrada e sair de um buffer de
entrada para ir até um buffer de saída. Evitando assim movimentações desnecessárias para um
transporte mais eficiente.
88
Figura 6.13. Modelo do sistema de transporte G0.
Assim, o modelo resultante representa o robô em dois estados: parado em algum
buffer ou transportando peça de um buffer pata outro. Os eventos �xy representam os
comandos para o deslocamento do robô do buffer x para o buffer y, sendo esse um evento
controlável. Os eventos �z representam o final de movimento do robô chagando ao buffer z e
estes eventos são não controláveis.
6.3.3 Modelo das especificações
O conjunto de especificações, que irão coordenar o sistema de manufatura, pode ser
dividido em três grupos, para um melhor entendimento cada grupo será apresentado a seguir.
O primeiro grupo é responsável por especificar o comportamento individual de cada
buffer aliado ao fim de transporte do robô determinando a próxima atividade. Na Figura 6.14
estão apresentadas as especificações do primeiro grupo. De modo geral as especificações E0 à
E6 buscam evitar o overflow e underflow dos buffers B0 à B6 e coordenam o transporte dos
diferentes tipos de peça pelas estações. Já as especificações E7 e E8 estabelece o
funcionamento do término do processo para as peças do tipo A e B. Por fim, a especificação
E9 determina o início de produção da máquina M3.
89
Figura 6.14. Especificações: a) E0, b) E1, c)E2, ..., j)E9.
A Figura 6.15 apresenta o modelamento de especificação que compreende ao
segundo grupo, onde busca coordenar o deslocamento do sistema de transporte, que depende
exclusivamente do plano de processo de produção das peças do tipo A e B. Já a especificação
E10, restringe o transporte de peça apenas para os pontos necessários. No estado 8, que não é
acessível, são colocados os eventos que não são desejados.
Figura 6.15. Especificação E10.
90
Por fim a Figura 6.16 apresenta o terceiro e último grupo de especificação, composta
apenas pela especificação E11. O objetivo desta especificação é coordenar o conjunto de
subsistemas máquina 1, sistema de transporte e esteira de alimentação, considerando que os
dois tipos de peça podem ser processados na máquina 1, conforme o roteiro de produção. Veja
que é possível se ter duas peças sendo coordenadas por essa especificação, onde uma estaria
no buffer de entrada enquanto a outra estaria em processo na máquina ou buffer de saída.
Figura 6.16. Especificação E11.
6.3.4 Síntese dos Supervisores Modulares Locais
Conforme apresentado no item 3.4.2, nesta abordagem a ação de controle é
distribuída entre vários autômatos denominados supervisores locais, onde cada um deles
representa a máxima linguagem controlável para cada planta local. Desta forma, cada
supervisor local coordena uma parte do sistema global.
No primeiro passo a ser seguido para se chegar aos superiores locais é determinar as
plantas locais realizando a composição síncrona entre os autômatos dos dispositivos, que
apresentam eventos com o mesmo nome nos modelos individuais dos dispositivos e que
ocorrem também em alguma especificação. Este procedimento é feito para cada especificação
do projeto que tenha eventos comuns com os subsistemas correspondentes.
As composições síncronas foram realizadas com auxílio do software IDES da
seguinte forma:
Gloc0 = G0||G4 Gloc1 = G0||G1
Gloc2 = G0||G2
Gloc3 = G0||G3
Gloc4 = G0||G4||G1
Gloc5 = G0
91
Na sequência foi feita a composição síncrona das plantas locais com as
especificações da planta que continham eventos comuns, gerando as especificações locais, da
seguinte forma:
Kloc0 = Gloc0||E0
Kloc1 = Gloc1||E1
Kloc2 = Gloc1||E2
Kloc3 = Gloc2||E3
Kloc4 = Gloc2||E4
Kloc5 = Gloc3||E5
Kloc6 = Gloc6||E6
Kloc7 = Gloc1||E7
Kloc8 = Gloc1||E8
Kloc9 = Gloc9||E9
Kloc10 = Gloc5||E10
Kloc11 = Gloc4||E11
Por fim, calculou-se a máxima linguagem controlável para cada supervisor Si (i = 0,
..., 11) denotada SupC(Gloci,Kloci). Assim, chega-se aos supervisores locais e para se assegurar
a modularidade local do conjunto de supervisores locais, deve-se garantir que a ação conjunta
de todos os supervisores é não bloqueante, conforme demonstrado em (QUEIROZ e CURY,
2000). Para isso deve-se realizar a composição síncrona de todos os supervisores locais da
seguinte forma:
S = Sloc0||S loc1||S loc2||S loc3||S loc4||S loc5||S loc6||S loc7||S loc8||S loc9||S loc10||S loc11
Após a composição síncrona verificou-se que o autômato resultante desta
composição é Trim, isto é, não tem estados bloqueantes. Assim, pode-se afirmar que os
supervisores locais são modulares entre si.
Com o objetivo de se reduzir o número de estados e transições a serem
implementados no CLP, para cada supervisor modular local, é possível ser calculado um
supervisor correspondente, que apresenta a mesma ação de controle, porém esse novo
supervisor pode apresentar um número igual ou menor de estados, são os supervisores
reduzidos. A Figura 6.17 apresenta o supervisor reduzido Sr0 que é um dos onze supervisores
reduzidos que serão implementados no CLP. Os supervisores reduzidos apresentados nesse
trabalho são diferentes dos utilizados por Silva, Busetti, Vieira, Santos (2007), porém em
ambos os supervisores apresentam a mesma ação de controle, essa diferença se dá, pois nesse
trabalho a redução foi realizada com algoritmo de redução do Grail implementado no IDES,
enquanto que Silva, Busetti, Vieira, Santos (2007) utilizaram o TCT.
92
Figura 6.17. Supervisor reduzido Sr0.
6.4 RESULTADO DA FERRAMENTA DE GERAÇÃO
Após inserir os modelos dos subsistemas e dos supervisores reduzidos na ferramenta
de geração de código CCSSM, foi gerado um arquivo de extensão L5X. Este arquivo
apresenta o código do CLP estabelecido a partir da metodologia proposta, em um formato
textual. A Tabela 6.1 apresenta a relação dos comandos ladder e de seus respectivos
comandos no formato textual para os CLPs que compõe as famílias ControlLogix® e
CompactLogix™.
Tabela 6.1 – Ladder para os CLPs das famílias ControLogix® e CompactLogix™
SÍMBOLO TEXTO NOME DESCRIÇÃO
-] [- XIC Contato NA Contato normalmente aberto
-]\[- XIO Contato NF Contato normalmente fechado
-(L) OTL Liga bobina É ligada quando a linha está energizada e permanece ligada até que seja
desligada em outra parte do código.
-(U) OTU Desliga bobina É desligada quando a linha está energizada e permanece desligada até que
seja ligada em outra parte do código.
-( ) OTE Energiza bobina Permanece ligada enquanto a linha está energizada.
93
A Figura 6.18 apresenta no lado esquerdo parte do arquivo L5X, do código que foi
gerado. Já ao lado direito da Figura 6.18, está apresentado o código correspondente no
formato ladder. É importante salientar, que esse formato de arquivo é apenas aceito pelo
compilador RSLogix™ 5000, uma vez que a ferramenta de geração de código gera arquivos
específicos.
Figura 6.18. Parte do código do CLP no formato texto e ladder
Para se importar o arquivo gerado pela ferramenta CCSSM no compilador e
visualizá-lo do formato ladder, deve-se primeiro criar um projeto no compilador, como
mostra a Figura 6.19. Deve ser estabelecido o modelo do CLP, na opção Type e fornecer o
nome para o projeto, na opção Name.
Figura 6.19. Novo projeto A partir do projeto criado, basta clicar no botão abrir e selecionar o arquivo gerado
pela ferramenta, como ilustra Figura 6.20. Em seguida deve selecionar o projeto recém-
criado, para que o compilador importe o código proveniente do arquivo L5X no projeto
criado.
94
Figura 6.20. Seleção do arquivo L5X
Ao final deste procedimento já é possível visualizar o código do CLP gerado pela
ferramenta CCSSM no formato ladder. A Figura 6.21 apresenta o resultado do problema
abordado. Veja que na rotina principal (MAIN) se tem apenas a chamada das sub-rotinas que
também foram criadas e que estão apresentadas abaixo da rotina principal.
Figura 6.21. Código gerado pela ferramenta em ladder
95
7 CONSIDERAÇÕES FINAIS
Neste trabalho foi apresentada uma metodologia para a implementação da Teoria de
Controle Supervisório (TCS) usando a abordagem Modular Local, no desenvolvimento de
uma solução de controle, sobre a plataforma de Controladores Lógicos Programáveis (CLPs).
Tendo como objetivo principal gerar um código para CLP que explore a máxima capacidade
de processamento, ou seja, em um único ciclo de varredura tratar o maior número de eventos
possíveis.
Esta metodologia mostrou-se bastante prática, uma vez que na indústria a solução de
problemas é feita com base na experiência do projetista, e geralmente, não é utilizado um
procedimento formal para a obtenção da lógica de controle para um determinado sistema.
Porém, devido às simplificações do modelamento teórico do sistema, a aplicação da TCS em
uma solução prática não é trivial, principalmente quando se utiliza um CLP como dispositivo
de controle. Ao modelar o conceito teórico de evento (controlável ou não controlável) no
CLP, dependendo da estratégia utilizada, podem levar a uma série de problemas, como o
efeito avalanche, o problema da escolha, causalidade e etc. Assim, com um objetivo
secundário, a metodologia de implementação proposta buscou solucionar tais problemas.
Tendo como destaque a solução para o problema da escolha, uma vez que não se encontrou na
literatura nenhum outro trabalho relacionado que apresentasse uma proposta de solução.
Para os problemas de sincronização inexata e simultaneidade, não foi estabelecido
uma solução, uma vez que para os autores, esses problemas não são gerados apenas quando se
utiliza a TCS na implementação do código do CLP, ou seja, em uma solução convencional
esses problemas também podem se manifestar. Pois, tais problemas estão diretamente ligados
ao modo de processamento do CLP, que se dá por ciclos (leitura das entradas, processamento
do código e atualização das saídas). Assim, a grande vantagem de se utilizar a TCS é que está
possibilita ainda durante o projeto do sistema determinar se o sistema poderá ou não
apresentar esses problemas.
Afim de, facilitar a visualização do programa e o entendimento do seu funcionamento,
o código resultante foi estruturado em uma rotina principal que promove as chamadas das
sub-rotinas, está organização também possibilita o reaproveitamento do código, uma vez que
uma determinada sub-rotina pode ser chamada mais de uma vez. Porém, para obter uma
solução completa, partindo do modelamento teórica, não elimina a necessidade de que o
usuário tenha o mínimo conhecimento sobre a TCS.
96
Os exemplos teóricos utilizados nesse trabalho foram validados por intermédio de testes
de simulação realizados sobre o ambiente de programação do CLP. Foi observado o correto
funcionamento dos sistemas, segundo as especificações de controle e em alguns casos, em um
único ciclo de varredura, o programa fez o tratamento de mais de um evento (obtendo assim o
objetivo principal). Além disso, nos testes observou-se a escolha aleatória de eventos
controláveis (atendendo a solução apresentada para o problema da escolha) e a não ocorrência
dos problemas discutidos neste trabalho.
Com os resultados obtidos, verifica-se que a proposta inicial de se utilizar uma
metodologia formal para desenvolver de forma sistemática o programa de controle a partir do
modelo da planta e das especificações e sua posterior implementação em CLP foi atingida,
tendo ainda solucionado vários problemas. Com base nestes resultados, pretende-se
disseminar o uso da TCS para obter o controle de células de manufatura.
Não foi possível aplicar a metodologia proposta em uma planta real, uma vez que a célula
didática existente na universidade apresentou problemas de hardware e a nova célula está em
processo de licitação. A alternativa seria simular a realidade com modelos criados com
Realidade Virtual (HOUNSELL e LEAL, 2010), uma vez que já existe uma linha de pesquisa
que vai ao encontro com essa necessidade.
7.1 CONTRIBUIÇÕES
Destacam-se como contribuições do presente trabalho:
• Disseminação da aplicação da TCS junto à comunidade acadêmica;
• Implementação da TCS em CLP, de modo a tratar o maior número de eventos
possíveis em um mesmo ciclo de varredura;
• Solução para o problema da escolha, uma vez que são encontrou na literatura
outro trabalho que abordasse uma solução para esse problema;
• Proposição e resolução de problemas teóricos existentes na literatura;
• Estudo de problemas teóricos com simulação do comportamento da planta via
entradas e saídas digitais;
• Criação de um programa para conversão de código de autômatos para CLP;
• Estudos preliminares de integração da célula real com a realidade virtual;
• Publicação de trabalhos científicos divulgando a implementação da TCS em
CLP:
97
o ETFA 2009 – 14th IEEE International Conference on Emerging
Technologies and Factory Automation (LEAL, CRUZ, HOUNSELL,
2009);
o SBAI 2009 – 4° Simpósio Brasileiro de Automação Inteligente
(CRUZ, LEAL, ROSSO Jr, ROZÁRIO, 2009);
7.2 TRABALHOS FUTUROS
Possibilidades de desenvolvimento para futuros:
• Implementação de especificações de segurança (modo manual e automático)
conforme abordado por Vieira (2007);
• Pesquisa de soluções para os problemas de sincronização inexata e
simultaneidade.
• Melhorar o algoritmo que promove a escolha aleatória para múltiplos eventos
controláveis;
• Incorporar na ferramenta de geração de código a possibilidade de entrar com
o modelamento de autômatos realizado a partir do Grail o do TCT;
• Criar novas rotinas de geração de código que possam ser aceitos por outros
modelos de CLPs;
• Desenvolver e incorporar na ferramenta algoritmos que promovem a
verificação das propriedades: insensibilidade ao entrelaçamento de eventos
não controláveis e insensibilidade ao atraso;
• Aplicar a metodologia de implementação em controle em células didáticas e
se possível em plantas industriais;
• Integração com a Realidade Virtual, permitindo que o código resultante seja
testado e validado no controle de ambientes virtuais;
• Usar a Realidade Virtual em ensino e treinamento da metodologia, onde
problemas como colisão e bloqueio podem ser identificados e corrigidos sem
danificar os dispositivos reais;
• Implementação do(s) supervisor(es) em Microcontroladores;
98
REFERÊNCIAS
ÁLVARES, A.J.; FERREIRA, J.C.E., Metodologia para Implantação de Laboratórios Remotos Via Internet na Área de Automação da Manufatura, Anais do 2o Congresso Brasileiro de Engenharia de Fabricação (COBEF). Uberlândia-MG, pp. 18- 21, 2003.
ATTIÉ, S.S.; Automação Hidráulica e Pneumática Empregando a Teoria de Sistemas a Eventos Discretos. Dissertação (Mestrado em Engenharia Mecânica) – Centro Tecnológico, Universidade Federal de Santa Catarina. Florianópolis, 1998.
BOUZON, G.; OLIVEIRA, M. L.; VALLIM, M. B.; LACOMBE, J. P.; FREITAS, G. M.; CURY, J.E.R.; FARINES, J.M.; CEBE: uma plataforma para experimentação real aplicada ao ensino de sistemas a eventos discretos. Anais do Congresso Brasileiro de Automática CBA. Gramado-RS. v. 1. pp. 724-729, 2004.
BRANDIN, B. A.; The Real-Time Supervisory Control of an Experimental Manufacturing Cell. IEEE Transactions on Robotics and Automation. 12(1). 1-14, 1996.
CARVALHO, J. R.; Contribuições a Implementação da Estrutura de Controle Modular Local. Dissertação (Mestrado em Engenharia de Produção e Sistemas) – Pontifícia Universidade Católica do Paraná. Curitiba, 2007.
CASSANDRAS, C.G.; LAFORTUNE S.; Introduction to Discrete Event Systems. Kluwer Academic Publishers. USA, 1999.
CASTRUCCI, L.C.; MORAES, C.C.; Engenharia de Automação Industrial, Editora LTC, Brasil, 2007.
COSTA, G. O.; Uma Plataforma Computacional de Suporte ao Ciclo de Desenvolvimento de Sistemas Automatizados de Manufatura. Dissertação (Mestrado em Engenharia de Produção e Sistemas) – Pontifícia Universidade Católica do Paraná. Curitiba, 2005.
CURY, J.E.R; Teoria de Controle Supervisório de Sistemas a Eventos Discretos. V Simpósio Brasileiro de Automação Inteligente. Canela-RS, 2001.
CURZEL, J.L.; LEAL, A.B.; Implementação de controle supervisório em linguagem Ladder para uma célula flexível de manufatura didática. In: XVI Congresso Brasileiro de Automática. Bahia, Brasil, p.2700-2705. 2006.
CURZEL, J.L.; SILVA, F.T. da; AMARAL, S. do e LEAL, A.B.; Concepção de uma célula flexível de manufatura didática para o ensino de engenharia. In: Anais do XXXIV Congresso Brasileiro de Ensino de Engenharia. Passo Fundo-RS, p.1916-1926. 2006.
CURZEL, J. L.; HOUNSELL, M. S.; LEAL, A. B. Uso da Realidade Virtual para Ensino de Automação da Manufatura. In: ICECE 2007 International Conference on Engineering and Computer Education, Monguaguá / Santos. p. 773-777. 2007a.
99
CURZEL, J. L.; LEAL, A. B.; HOUNSELL, M. S. Realidade Virtual como ferramenta de simulação aplicada no ensino de automação da manufatura. In: 4º Simpósio Iberoamericano de Educación, Cibernética e Informática (SIECI 2007), Orlando. 2007b.
CRUZ, D. L. L. da; LEAL, A. B.; ROSSO Jr, R. S. U.; ROZÁRIO, J. G.; Proposta de Implementação de Controle Supervisório em Controladores Lógicos Programáveis. In: 4º Simpósio Brasileiro de Automação Inteligente (SBAI 2009), Brasília. P. 19-24. 2009.
DIAS, J. R. S.; Um Laboratório para um Curso de Automação Industrial Utilizando a Teoria de Sistemas a Eventos Discretos. Mestrado (Dissertação em Engenharia Elétrica) – Universidade Federal do Rio de Janeiro. Rio de Janeiro, 2005.
FABIAN, M.; HELLGREN, A. PLC-based implementation of supervisory control for discrete event systems. In: 37th IEEE Conference on Decision and Control, v. 3, p. 3305- 3310. 1998
FENG, L.; WONHAM, W. M.; TCT: A Computation Tool for Supervisory Control Synthesis. In: 8th Workshop on Discrete Event Systems (WODES), p. 388-389. Ann Arbor. 2006.
FLORDAL, H.; MALIK, R.; Nonblocking Verification Using Conflict Equivalence. In: 8th International Workshop on Discrete Event Systems (WODES), p. 100-106. Ann Arbor. 2006.
GARCIA, T. R.; CURY, J. E. R.; Grail para Controle Supervisório de Sistemas a Eventos Discretos. Guia do Usuário, Disponível em: http://www.das.ufsc.br/~cury/grail.html
GROOVER, M. P.; Automation, Production Systems and Computer Integrated Manufacturing. Ed. Prentice Hall 2º ed. New Jersey. 2001.
HASDEMIR, T.; KURTULAN, S.; GÖREN, L.; An Implementation Methodology for Supervisory Control Theory. The International Journal of Advanced Manufacturing Technology, v. 03. n. 03-04 p. 373-385. 2008. �
HELLGREN, A.; FABIAN, M.; LENNARTSON, B.; On the execution of sequential function charts. Control Engineering Practice, v. 13 p. 1283-1293. 2005.
HOUNSELL, M. S.; PIMENTEL, A.; On The Use of Virtual Reality to Teach Robotics. In: ICECE - International Conference on Engineering and Computer Education, Santos-SP. (IEEE Education Society), v. 01. p. 1-5. 2003.
HOUNSELL, M. S.; SILVA, E. L.; LEAL, A. B.; Simulação Gráfica 3D de Células de Manufatura Reconfiguráveis via Autômatos Finitos In: 9th IEE/IAS - International Conference on Industry Applications, São Paulo. p. 1-33. 2010.
IEC; International Standard IEC 61131-3, Programmable Logic Controllers – Part 3: Programming Languages. 2003.
LEAL, A. B.; CRUZ D. L. L. da; HOUNSELL, M. S.; Supervisory Control Implementation into Programmable Logic Controllers. In: 14th IEEE International Conference on Emerging Technologies and Factory Automation – ETFA 2009, Palma de Maiorca, Espanha. 2009.
100
LEDUC, R. J.; PLC Implementation of DES supervisor for a manufacturing testbed: an implementation perspective. Master’s thesis. Dept. of Computer and Electrical Engineering, University of Toronto, Canada. 1996.
MALIK, P.; Generating Controllers from Discrete-event Models. In: F. Cassez, C jard, F. Laroussinie, M. D. Ryan, Proc of the MOVEP. 2002.
MORAES, W. R. de; LEAL, A. B.; Controle supervisório do transportador de entrada de um sistema flexível de manufatura. Anais do VI INDUSCON. Joinville, 2004.
PINOTTI, A. J.; LEAL, A. B.; OLIVEIRA, D. S.; Uma Proposta para Implementação da Estrutura de Controle Supervisório em Controladores Lógicos Programáveis. In: XVIII Congresso Brasileiro de Automática - CBA. Bonito – MS., Brasil, p. 2830-2837. 2010
QUEIROZ, M.H. de; Controle Supervisório Modular de Sistemas de Grande Porte.Dissertação (Mestrado em Engenharia Elétrica) – Centro Tecnológico, Universidade Federal de Santa Catarina. Florianópolis, 2000.
!!!!!!!!; Controle Supervisório Modular e Multitarefa de Sistemas Compostos. Tese (Doutorado em Engenharia Elétrica) – Centro Tecnológico, Universidade Federal de Santa Catarina. Florianópolis, 2004.
QUEIROZ, M.H. de; CURY, J.E.R.; Modular supervisory control of large scale discrete event systems. In: Proceedings of the 5th International Workshop on Discrete Event Systems: Analysis and Control. Ghent, Belgium: Kluwer Academic Publishers, p. 103-110. 2000a. !!!!!!!!; Modular control of composed systems. In: Proceedings of the American Control Conference. Chicago, USA. pp. 40551-4055. 2000b. !!!!!!!!; Controle supervisório modular de sistemas de manufatura. Revista Controle & Automação, v. 13, n. 2, p. 115-125. 2002a. ________; Synthesis and implementation of local modular supervisory control for a manufacturing cell. In: 6th International Workshop in Discrete Event Systems. Zaragoza, Spain: Kluwer Academic Publishers, p. 377-382. 2002b.
QUEIROZ, M.H. de, SANTOS, E.A.P. e CURY, J.E.R.; Síntese modular do controle supervisório em diagrama escada para uma célula de manufatura. Anais do V Simpósio Brasileiro de Automação Inteligente, Gramado RS. 2001.
RAMADGE, P. J.; WONHAM, W. M.; The control of discrete event systems, Proc. of IEEE, Special Issue on Discrete Event Dynamic Systems, v. 77, n. 1, p. 81-98. 1989.
REISER, C; CUNHA, A. E. C. da ; CURY, J. E. R. . The Environment Grail for Supervisory Control of Discrete Event Systems. In: 8th Workshop on Discrete Event Systems (WODES 2006), p. 390-391. Ann Arbor. 2006.
ROCKWELL, Automation, http://www.rockwellautomation.com
RUDIE, K.; The Integrated Discrete-Event Systems Tool. In: 8th Workshop on Discrete Event Systems (WODES 2006), p. 394-395. Ann Arbor. 2006.
101
SANTOS, E.A.P.; VIEIRA, A.D.; BUSETTI, M.A.; Controle de um sistema integrado de manufatura baseado na Teoria de Controle Supervisório. In: Congresso Brasileiro de Automática, Bahia, Brasil, p. 1181-1186. 2006.
SIEMENS, Automation and Drives, http://www.automation.siemens.com
SILVA, D. B.; BUSETTI M. A.;VIEIRA, A. D.; SANTOS, E. A.; Application of the Supervisory Control to Automated Systems of Multi-Product Manufacturing. In: 12th IEEE Conference on Emerging Technologies and Factory Automation, Patras, Grecee. p. 689 – 696. 2007.
SILVEIRA, P. R.; SANTOS, W. E.; Automação e Controle Discreto, Editora Érica, São Paulo, 231 p. 1998
SU, R.; WONHAM, W. M.; Supervisor Reduction for Discrete Event Systems. In: Proceedings of 2001 Conference on Information Sciences and Systems, The Johns Hopkins University, pp. 786-791, 2001.
!!!!!!!!; Supervisor Reduction for Discrete-Event Systems. Discrete Event Dynamic Systems, v. 14, n. 1, pp31-53, 2004.
TEIXEIRA, C.A.; Aplicação da Teoria de Controle Supervisório no Projeto de Controle para Eletrodomésticos. Dissertação (Mestrado em Engenharia Elétrica) – Universidade do Estado de Santa Catarina. Joinville, 2008.
TEIXEIRA, C.A.; LEAL, A.B.; SOUZA, A.H.; Implementação de supervisores em microcontroladores: Uma abordagem baseada na teoria de controle de sistemas a eventos discretos. In: XVI Congresso Brasileiro de Automática. Bahia, Brasil, p. 2772-2777. 2006.
VIEIRA, A. D.; Método de Implementação do Controle de Sistemas a Eventos Discretos com Aplicação da Teoria de Controle Supervisório. Tese (Doutorado em Engenharia Elétrica) – Centro Tecnológico, Universidade Federal de Santa Catarina. Florianópolis, 2007.
!!!!!!!!; Modelagem e implementação de sistemas seqüenciais utilizando o método passo a passo. Pontifícia Universidade Católica do Paraná. Curitiba, 2001.
