SUZANA RIBAS DE ALMEIDA

Transcrição

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 SUZANA RIBAS DE ALMEIDA IMPLEMENTAÇÃO DE CONTROLE SUPERVISÓRIO EM CLPS USANDO LINGUAGEM DE ALTO NÍVEL JOINVILLE SC 2012

2 SUZANA RIBAS DE ALMEIDA IMPLEMENTAÇÃO DE CONTROLE SUPERVISÓRIO EM CLPS USANDO LINGUAGEM DE ALTO NÍVEL 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 Coorientador: Prof. Dr. Agnelo Denis Vieira JOINVILLE SC 2011

3 FICHA CATALOGRÁFICA A447i Almeida, Suzana Ribas de Implementação de Controle Supervisório em CLPs Usando Linguagem de Alto Nível / Suzana Ribas de Almeida orientador: Dr. André Bittencout Leal. Joinville, 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, Automação de Sistemas. 2.Teoria de Controle Supervisório. I. Leal, André Bittencourt. CDD 629.8

4

5 Ao meu marido Henrique Brüggmann Mühle pelo apoio, ajuda e carinho. Aos meus pais Ana Helena Ribas de Almeida e Eduardo Withers de Almeida pelo incentivo.

6 AGRADECIMENTOS Gostaria agradecer a todos que me ajudaram na realização deste trabalho, principalmente: Ao meu orientador, Prof. Dr. André Bittencourt Leal, pela orientação e dedicação. Ao meu coorientador, Prof. Dr. Agnelo Denis Vieira, pela disponibilidade, ajuda na revisão, sugestões e pela oportunidade de poder usar as instalações físicas da PUCPR para realização prática do trabalho. Aos bolsistas Thiago Oliveira e Renan Sebem pelo auxílio no desenvolvimento do trabalho. À FAPESC pela ajuda financeira. Aos amigos pela amizade e compreensão.

7 RESUMO DE ALMEIDA, Suzana Ribas. Implementação de controle supervisório em CLPs usando linguagem de alto nível, f. 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, Hoje em dia a competitividade entre as empresas está cada vez maior. Em um sistema de produção, a eficácia, a velocidade e a flexibilidade são importantes, pois significam redução de custos. Os sistemas de automação atuais estão cada vez mais complexos, justificando a necessidade de programas de controle mais eficientes, sem erros e de fácil manutenção. Entretanto, na maioria das aplicações práticas a solução destes problemas é feita com base na experiência do projetista, não seguindo uma metodologia formal, o que resulta em programas com erros e de difícil entendimento e manutenção, uma vez que só o projetista entende perfeitamente as soluções adotadas. A Teoria de Controle Supervisório (TCS) é um método para a síntese da lógica de controle de sistemas automatizados. Ela permite que problemas de controle sejam solucionados de modo formal, garantindo uma solução minimamente restritiva e não bloqueante e que atenda às especificações de controle. Entretanto, esta teoria ainda não é amplamente adotada em ambientes industriais, sendo a carência de métodos de implementação dos supervisores obtidos via TCS um elemento que contribui para que isso aconteça. Assim, esta dissertação se propõe a apresentar uma metodologia de implementação de controle supervisório em Controladores Lógicos Programáveis (CLPs). Neste trabalho, a síntese de supervisores é feita de acordo com a abordagem modular local, que traz os benefícios de uma metodologia formal e ainda permite explorar a modularidade da planta e das especificações de controle. A implementação é baseada numa arquitetura estruturada em três níveis: supervisor, interface e sistema a ser controlado. Para a implementação em CLP são empregadas três linguagens distintas de programação, as linguagens de alto nível Sequential Function Charts (SFC) e Structured Text, bem como a linguagem Ladder Diagram em algumas partes. O desenvolvimento da metodologia foi baseado em dois trabalhos: a tese de doutorado de Vieira (2007) e a dissertação de mestrado de Cruz (2011) e permitiu reunir as vantagens apresentadas em cada um destes. Para comparação entre a metodologia proposta e as duas metodologias citadas, foram feitos diversos testes em uma célula de manufatura existente na PUCPR, bem como simulações em CLP e em computador. Os resultados mostram que a metodologia proposta neste trabalho permite a implementação de programas em CLP que, num mesmo ciclo de varredura, são capazes de tratar todos os eventos não controláveis ocorridos na planta e ainda um evento controlável por célula de controle. Além disso, o uso de linguagens de alto nível resulta em um programa de mais fácil interpretação e manutenção, possibilitando ainda o reaproveitamento de códigos. Nesta dissertação também são abordados alguns problemas de implementação da estrutura de controle supervisório em CLPs, apresentando-se propostas para solucioná-los, bem como propriedades que, se atendidas, garantem que o problema não ocorra. Palavras-chave: Sistemas a Eventos Discretos. Controlador Lógico Programável (CLP). Abordagem Modular Local. Teoria de Controle Supevisório. Sequential Function Charts (SFC). Ladder Diagra. Structured Text.

8 ABSTRACT DE ALMEIDA, Suzana Ribas. Implementation of Supervisory Control in PLCs Using High-Level Language, f. Dissertation (Master Course in Electrical Engineering Area: Automation Systems) Santa Catarina State University, Post-Graduation Program in Electrical Engineering, Joinville, Nowadays the competition between companies is increasing. In a production system, efficiency, speed and flexibility are important means for cost reductions. The complexity of automation systems has been increasing, which makes necessary the implementation of more efficient control programs, free of errors and easy to maintain. However, in most practical applications the solution of these problems is dependent on designer's experience and doesn t follow a formal methodology, which results in programs with errors and difficulties to understand and maintain, since only the designer understands the adopted solutions. The Supervisory Control Theory (SCT) is a method extensively researched in academic circles for the synthesis of control logic of automated systems. It allows control problems to be solved in a formal way, ensuring a minimally restrictive and no blocking solution that meets the control specifications. However, this theory is not widely used in industrial environments yet, once the methods for implementation of supervisors obtained by TCS are still deficient. Thus, the intention of this Dissertation consists of showing a methodology for implementation of supervisory control in Programmable Logic Controllers (PLCs). In this work, the synthesis of supervisors is made in accordance to local modular approach, which brings the benefits of a formal methodology and allows exploring the modularity of the plant and the control specifications. The implementation is based on an architecture structured in three levels: supervisor, interface and system to be controlled. For the implementation in CLP three different programming languages are applied: the high-level languages Sequential Function Charts (SFC) and Structured Text and the low-level Ladder Diagram language in some parts. The development of the methodology was based on two works: a doctoral thesis by Vieira (2007) and master thesis by Cruz (2011) and brought together the advantages presented in each one of these. To compare the proposed methodology and the two mentioned methods, several tests were made on a manufacturing cell available at PUCPR and simulations on a PLC and computer as well. The results show that the use of the methodology proposed in this work makes possible to implement PLC programs that are able to treat all non-controllable events occurred in the system to be controlled and treat one controllable event by each control cell in the same scan cycle. Furthermore, the use of high-level languages results in a program of easier interpretation and maintenance, also enabling reutilization of codes. In this work some problems related to CLPs implementations are also showed and proposals for solving them are presented, as properties as well that, if accepted, ensure that the problem does not occur. Keywords: Discrete Events Systems. Programmable Logic Controller (PLC). Local Modular Approach. Supervisory Control Theory. Sequential Function Charts (SFC). Ladder Diagram. Structured Text.

9 LISTA DE SÍMBOLOS Σ alfabeto de eventos Σ* linguagem composta por todas as possíveis sequências de eventos Σc alfabeto de eventos controláveis Σu alfabeto de eventos não controláveis L linguagem L prefixo fechamento de L ε palavra de comprimento nulo σ, A, B, T, L, M eventos s cadeia de eventos (Q, Σ, f, q0, Qm) quíntupla que representa um autômato Q - é o conjunto de estados Σ - o alfabeto δ - função de transição de estados do autômato q0 - estado inicial Qm - conjunto dos estados marcados δ(q, σ) função de transição para o par q e σ G autômato para a planta Lm(G) linguagem marcada por G L(G) linguagem gerada por G operador de produto sincrono Ac componente acessível S Supervisor S/G sistema controlado SRA, SRB, SRC, SRD supervisores reduzidos E Especificação de controle K Linguagem alvo C(K,G) conjunto de sublinguagens de K que são controláveis em relação a G SupC(K,G) suprema linguagem controlável

10 LISTA DE ABREVIATURAS Teoria e Arquitetura de Controle Supervisório DECON9 DEcomposing the CONtrol Implementation DEpending on the CONtrolability of the events MS Nível Supervisores Modulares OP Nível Procedimentos Operacionais PS Nível Sistema Produto RSP Representação por Sistema Produto SC Sistema de Controle SEDs Sistemas a Eventos Discretos SP Sistema Produto TCS Teoria de Controle Supervisório Método de implementação Emg Emergency Man Manual PSI Physical System Initialization SI Software Initialization Sup Supervised IEC CLP Controlador Lógico Programável FB Function Block (elemento para estruturação do programa do CLP) FBD Function Block Diagram (linguagem de programação de CLP) FC Function (elemento para estruturação do programa do CLP) LD Ladder Diagram (linguagem de programação de CLP) OB Organization Block

11 SFC Sequential Function Chart (linguagem de programação de CLP) ST Structured Text (linguagem de programação de CLP) Outros PUCPR Pontifícia Universidade Católica do Paraná

12 LISTA DE FIGURAS Figura Autômato G Figura 2.2 Definição de composição síncrona de Cury (2001) Figura Sincronização G1 G2 com eventos em comum Figura Linha de transferência industrial (QUEIROZ E CURY, 2000) Figura Autômato das máquinas (CRUZ, 2011) Figura Autômatos das especificações (CRUZ, 2011) Figura 2.7- Controle supervisório monolítico (RAMADGE e WONHAM, 1989) Figura Células de controle Figura 2.9- Esquema de controle modular local (QUEIROZ e CURY, 2000) Figura 2.10 Representação por sistema produto Figura Supervisores locais (CRUZ, 2011) Figura Supervisores reduzidos (CRUZ 2011) Figura Arquitetura segundo Ramadge e Wonham (1989) Figura Arquitetura de controle supervisório, Queiroz e Cury (2002) Figura Processo cíclico do CLP Figura Símbolos da linguagem Ladder Diagram Figura Programa em Ladder Diagram Figura 3.6 Símbolos da linguagem SFC Figura Autômato susceptível ao efeito avalanche (HASDEMIR et al., 2008) Figura Programa em Ladder Diagram com efeito avalanche Figura Programa em Ladder Diagram sem efeito avalanche Figura Autômato susceptível ao efeito avalanche (HASDEMIR et al., 2008) Figura 3.11 Proposta de Vieira (2007) para efeito avalanche Figura Diagrama temporal Figura Problema da incapacidade de reconhecer a ordem dos eventos Figura Autômato susceptível ao problema de sincronização inexata Figura Propriedade Figura Propriedade Figura Supervisor SRC... 47

13 Figura Autômato susceptível ao problema da escolha Figura 4.1 Fluxograma proposto por Cruz (2011) Figura Fluxograma completo da rotina principal (CRUZ, 2011) Figura 4.3 Programa principal - OB Figura Parte da sub-rotina de leitura Figura Bloco ATUALIZA Figura 4.6 Eventos não controláveis no subsistema Gi (a) ENC G1; (b) Autômato G Figura 4.7 Eventos não controláveis nos supervisores (a) ENC SA; (b) Autômato SA Figura 4.8 Parte do programa de DESABILITAÇÕES Figura 4.9 Bloco TRATA ESCOLHA Figura 4.10 Eventos controláveis no subsistema Gi (a) EC G1; (b) Autômato G Figura 4.11 Eventos controláveis no supervisor (a) EC SA; (b) Autômato SA Figura Programa Main (VIEIRA, 2007) Figura Ordem de chamada de blocos Figura Supervisores reduzidos Figura Bloco FC dg Figura 5.5 Autômatos equivalentes a) com autolaço e b) sem autolaço Figura Exemplo de autômato da planta Figura Novo autômato H2 para a planta G Figura SFC para o subsistema G Figura SFC para o supervisor SRB Figura Desabilitação de eventos controláveis Figura Célula de Manufatura (VIEIRA, 2007) Figura RSP para a célula de manufatura (VIEIRA, 2007) Figura Supervisores reduzidos para a célula de manufatura (VIEIRA, 2007) Figura Parte do Bloco MS Figura FB para o supervisor slb Figura Desabilitação do evento A Figura 5.17 Parte do bloco PS, chamada do dg0 e G Figura 5.18 Bloco FC dg Figura 5.19 SFC G Figura Parte do bloco OP Figura Proposta de organização para a chamada de blocos Figura 6.2 Parte do bloco Action_sup... 80

14 Figura 6.3 Parte do bloco PS Figura Implementação do bloco G Figura 6.5 Chamada dos supervisores com eventos não controláveis Figura Chamada dos supervisores com eventos controláveis Figura Supervisor slb Figura Atualização das desabilitações Figura 6.9- Parte o bloco MS, eventos zerados Figura FB OP a Figura Autômato susceptível ao efeito avalanche Figura SFC susceptível ao efeito avalanche Figura Programa MS Figura Chamada do TRATA_ESCOLHA no bloco Action_sup Figura Bloco de escolha Figura TIME_TCK e início do NCiclo Figura Incremento de NCiclo Figura Chamada do Registra3 no G Figura Function Block Registra Figura Function Block Registra Figura Chamada do FB Registra Figura 7.7- FB Registra

15 LISTA DE TABELAS Tabela Plantas locais Tabela Resultado da execução do DECON Tabela Eventos por célula de controle Tabela Conversão Gi Hi Tabela 5.3- Transições de H Tabela 5.4 Eventos desabilitados Tabela 5.5 Eventos que causam mudança de estado Tabela Semântica de estados e eventos (VIEIRA, 2007) Tabela 6.1 No. de estados e de transições do conjunto de supervisores (VIEIRA, 2007) Tabela Primeiro teste na planta Tabela Primeiro teste simulado no CLP Tabela Primeiro teste simulado no computador Tabela Segundo teste, proposta de Vieira (2007) Tabela Segundo teste, nova proposta Tabela 7.6 Terceiro teste na planta Tabela Terceiro teste simulado Tabela Tamanho do código, comparação com a proposta de Vieira Tabela 7.9- Tamanho do código, comparação com a proposta de Cruz (2011)

16 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS ESTRUTURA DO TRABALHO CONTROLE SUPERVISÓRIO DE SISTEMAS A EVENTOS DISCRETOS SISTEMA A EVENTOS DISCRETOS Linguagem Autômato Composição síncrona TEORIA DE CONTROLE SUPERVISÓRIO (TCS) Identificação do conjunto de subsistemas envolvidos no problema Modelagem da planta Mapeamento dos eventos controláveis e não controláveis dos subsistemas Modelagem das especificações Síntese dos supervisores ABORDAGEM MONOLÍTICA Obtenção do modelo da planta G Obtenção do modelo da especificação E Cálculo da linguagem alvo K Cálculo da linguagem controlável SupC(K,G) ABORDAGEM MODULAR LOCAL Representação por sistema produto Obtenção das plantas locais Obtenção das especificações locais Obtenção das linguagens controláveis Teste de modularidade local... 32

17 2.4.6 Obtenção dos supervisores reduzidos CONCLUSÃO AO CAPÍTULO IMPLEMENTAÇÃO DE CONTROLE SUPERVISÓRIO EM CLPs ESTRUTURA DE IMPLEMENTAÇÃO IMPLEMENTAÇÃO EM CLPs ALGUMAS LINGUAGENS DE PROGRAMAÇÃO Ladder Diagram SFC - Sequential Function Chart e Structured Text PROBLEMAS NA IMPLEMENTAÇÃO Causalidade Efeito avalanche Incapacidade de reconhecer a ordem dos eventos Sincronização inexata Escolha CONCLUSÃO AO CAPÍTULO METODOLOGIA DE IMPLEMENTAÇÃO DECON APRESENTAÇÃO DA METODOLOGIA ESTUDO DE CASO: LINHA DE TRANSFERÊNCIA INDUSTRIAL Primeiro passo Inicialização dos estados Segundo passo Leitura das entradas Terceiro passo Quarto passo Quinto passo Sexto passo Sétimo passo Oitavo passo Nono passo RESULTADOS METODOLOGIA DE IMPLEMENTAÇÃO EM SFC (VIEIRA, 2007) PROPOSTA DE IMPLEMENTAÇÃO REPRESENTAÇÃO EM SFC Implementação do FC PS... 61

18 5.2.2 Implementação dos supervisores, FC MS Implementação do FC OP CÉLULA DE MANUFATURA Bloco MS Bloco PS Bloco OP CONCLUSÃO AO CAPÍTULO IMPLEMENTAÇÃO EM SFC COM TRATAMENTO DE MULTIPLOS EVENTOS NÃO CONTROLÁVEIS CHAMADA DOS BLOCOS Bloco PS Bloco MS Bloco OP SOLUÇÃO DE PROBLEMAS DE IMPLEMENTAÇÃO Causalidade Efeito avalanche e perda de informação Sincronização inexata Problema da escolha CONCLUSÃO DO CAPÍTULO COMPARAÇÕES ENTRE AS METODOLOGIAS PRIMEIRO TESTE DIFERENÇA ENTRE EVENTOS SEGUNDO TESTE EVENTOS NO MESMO CICLO TERCEIRO TESTE MONITORAMENTO DE TODOS OS EVENTOS TAMANHO DE PROGRAMA TAMANHO DE PROGRAMA COMPARANDO COM CRUZ (2011) CONCLUSÃO AO CAPÍTULO CONSIDERAÇÕES FINAIS CONCLUSÃO TRABALHOS FUTUROS Divisão do bloco PS Sincronização inexata propriedade Identificação do problema de escolha

19 8.2.4 Programação em Structured Text Geração automática de código REFERÊNCIAS

20 19 1 INTRODUÇÃO Para que as empresas sejam competitivas no mercado atual é necessário melhorar a qualidade dos seus produtos e diminuir seus custos de produção. Uma das maneiras de se conseguir isto consiste em automatizar processos de manufatura ou simplesmente aperfeiçoar sistemas já automatizados. A Teoria de Controle Supervisório (TCS), (Ramadge e Wonham, 1989), é uma ferramenta no processo de síntese da lógica de controle para sistemas automatizados. No sistema real existe uma série de subsistemas que trabalham em conjunto, cada qual com um comportamento distinto. Para o sistema funcionar, é necessário atender a algumas especificações. Um controle é necessário para que se garanta o atendimento a especificações. Este controle é feito a partir de um ou mais supervisores. Na TCS, a modelagem do comportamento da planta e das especificações de controle é feita por meio de autômatos de estados finitos. Ramadge e Wonham (1989) apresentam a abordagem monolítica, onde apenas um supervisor é sintetizado a fim de controlar a planta. Queiroz e Cury (2000) introduzem a abordagem modular local, que explora a modularidade da planta e das especificações de forma a sintetizar um conjunto de supervisores locais, cada qual atuando sobre uma parte da planta, mas de forma a garantir o cumprimento de todas as especificações de controle. O objetivo deste trabalho consiste em estudar a implementação da TCS em Controladores Lógicos Programáveis (CLP). Muitos trabalhos, (LEDUC e WONHAM, 1995; LEDUC, 1996; LAUZON et al. 1997; FABIAN e HELLGREN, 1998; DIETRICH et al., 2002; HELLGREN et al., 2002; LIU e DARABI, 2002; QUEIROZ e CURY, 2002; CHANDRA et al., 2003; MANESIS e AKANTZIOTIS, 2005; AFZALIAN et al., 2008; HASDEMIR et al., 2008; LEAL et al., 2009; POSSAN e LEAL, 2009; entre outros ), em sua maioria apresentam implementações utilizando a linguagem Ladder Diagram e abordagem monolítica. Queiroz e Cury (2000) implementam em CLP utilizando Ladder Diagram, porém tratam apenas um evento por ciclo de varredura. Para a síntese dos supervisores foi usada a Abordagem Modular Local. Vieira (2007) implementou utilizando Sequential Function Charts (SFC) tratando mais eventos por ciclo de varredura, um para cada supervisor. Foi utilizada a arquitetura de Controle Supervisório proposta por Queiroz e Cury (2000) que utiliza uma estruturada em três níveis: um supervisor, uma interface e o sistema a ser controlado. Esta interface consiste no sistema produto e procedimentos operacionais. Cruz (2011) utilizou a linguagem Ladder Diagram, porém trata mais eventos por ciclo de varredura. Cruz (2011), como os outros, utilizou para síntese dos supervisores a abordagem

21 20 modular local. Porém, na sua implementação não utilizou a arquitetura de Queiroz e Cury, pois não tem os procedimentos operacionais. Neste trabalho será utilizada a arquitetura de controle supervisório segundo Queiroz e Cury (2000), utilizada a linguagem Sequential Function Charts (SFC) como em (VIEIRA, 2007) e adotada a proposta de tratar vários eventos por ciclo de varredura do CLP, como em (CRUZ, 2011). Além da linguagem SFC serão utilizadas também as linguagens Structured Text e Ladder Diagram. O termo linguagem de alto nível será utilizado para denotar as linguagens SFC e, principalmente, para a linguagem Structured Text que é bloco estruturada e sintaticamente se assemelha à linguagem Pascal. Além disso, estas linguagens são mais flexíveis e estruturadas que a linguagem Ladder Diagram. 1.1 OBJETIVOS O objetivo principal deste trabalho consiste em apresentar uma metodologia de implementação de controle supervisório em CLPs que utilize uma linguagem de mais alto nível do que a linguagem Ladder Diagram usualmente empregada nas indústrias. Além disso, esta metodologia deve resultar em programas mais eficientes do que os obtidos por intermédio de metodologias encontradas na literatura, sendo capazes de tratar mais eventos por ciclo de varredura. 1.2 ESTRUTURA DO TRABALHO Esta dissertação está estruturada da seguinte forma. No Capitulo 2 é apresentado o controle supervisório de sistemas a eventos discretos (SEDs) onde são discutidas as formas de representação dos SEDs por linguagem e autômatos. Também é mostrada a teoria de controle supervisório (TCS), como é feito o desenvolvimento de um projeto e duas técnicas de síntese dos supervisores, a abordagem monolítica e a abordagem modular local. O capítulo 3 trata da implementação da estrutura da teoria de controle supervisório em CLPs e alguns problemas de implementação que foram tratados neste trabalho. São ainda mostradas duas formas de implementação: em linguagem Ladder Diagram e em Sequential Function Chart (SFC). No capítulo 4 é dedicado a proposta de implementação de Cruz (2011), denominada DECON9, que utiliza Ladder Diagram e possibilita o tratamento de vários eventos em um mesmo ciclo de varredura do CLP. Além disso, um estudo de caso é mostrado para esta implementação. No

22 21 capítulo 5 é mostrado a proposta de implementação de Vieira (2007) que utiliza Sequential Function Chart (SFC), é mostrado um estudo de caso para exemplificar. No capítulo 6 é apresentado a proposta deste trabalho que utiliza SFC, onde é possível tratar mais eventos por ciclo de varredura que na proposta de Vieira (2007). São também mostradas algumas soluções de problemas de implementação. Os estudos de caso utilizados por Cruz (2011) e por Vieira (2007) foram implementados com esta nova proposta, a partir dos quais é mostrada uma comparação no capítulo 7. O capítulo 8 é dedicado para a conclusão deste trabalho e sugestões trabalhos futuros.

23 22 2 CONTROLE SUPERVISÓRIO DE SISTEMAS A EVENTOS DISCRETOS Neste capítulo é apresentado o que são os Sistemas a Eventos Discretos (SEDs), mostrando suas formas de representação por linguagens e autômatos. É apresentada a Teoria de Controle Supervisório (TCS) e as etapas para o desenvolvimento de um sistema de controle segundo a TCS. São também apresentadas duas formas de fazer a síntese do supervisor, a abordagem monolítica e a abordagem modular local. 2.1 SISTEMA A EVENTOS DISCRETOS Segundo Cassandras e Lafortune (1999), um Sistema a Eventos Discretos (SED) é um sistema de estados discretos, dirigido a eventos, isto é, sua evolução de estado depende da ocorrência de eventos discretos assíncronos no tempo. Segundo Cury (2001), SED é um sistema dinâmico que evolui de acordo com a ocorrência abrupta de eventos físicos, em intervalos de tempo, em geral, irregulares e desconhecidos. Eventos são estímulos sem duração de tempo que afetam o comportamento de um sistema. Um evento pode ser o início de operação de uma máquina, o início de transporte, o resultado de um sistema de classificação, etc. Entre a ocorrência de dois eventos consecutivos, o sistema permanece em um determinado estado. A ocorrência de um evento pode causar então uma transição ou mudança de estado no sistema, de forma que sua evolução no tempo pode ser representada pela trajetória percorrida no seu espaço de estados (CURY, 2001). O comportamento lógico de um SED pode ser representado por linguagens e autômatos, Redes de Petri, Cadeias de Markov e Teoria das Filas, dentre outros formalismos. Neste trabalho serão utilizadas linguagens e autômatos para representar tal comportamento Linguagem Linguagem é uma representação do comportamento de um SED. Em um sistema, a mudança de estado depende de um evento. Um alfabeto, Σ, é um conjunto finito de eventos, como por exemplo Σ = {a, b, c, d, e}. As palavras são sequências finitas formadas pelos símbolos do alfabeto e a linguagem L é um conjunto das palavras, como, por exemplo, L = {ab, abc, ae, abcc} (CASSANDRAS e LAFORTUNE, 1999). Uma palavra vazia é representada por ε, Σ* é o conjunto contendo todas as sequências compostas por eventos de Σ, inclusive ε. Considerando a palavra abc, a é chamado de prefixo, b de subcadeia e c de sufixo

24 23 desta palavra. O prefixo-fechamento, L, é o conjunto de todas as sequências de Σ* que são prefixos de sequências de L (CURY, 2001) Autômato O autômato pode ser representado graficamente através de um diagrama de transição de estados ou através de uma quíntupla (Q, Σ, δ, q0, Qm), onde Q é o conjunto de estados, Σ o alfabeto, δ : Q x Σ Q a função de transição, q0 estado inicial e Qm conjunto dos estados marcados. Os estados são representados por círculos. Arcos direcionados unem os círculos representando a mudança de estado e são identificados com o evento que provoca esta transição. O estado inicial é representado por uma flecha onde não tem outro circlo anterior a ela. A título de exemplo, na Figura 2.1 apresenta-se um autômato G no qual o estado 0 é o estado inicial. Os estados marcados são representados por dois círculos concêntricos e indicam que uma tarefa foi completada, como os estados 0 e 1 de G. Figura Autômato G A um autômato são associadas duas linguagens, a linguagem gerada e a linguagem marcada. A linguagem gerada L(G) representa todas as possíveis sequências de eventos que podem ser seguidas no autômato G, partindo do estado inicial. No exemplo da Figura 2.1 L(G) = { ε, a, ab, abc, abcd, ae,...}. A linguagem marcada Lm(G) considera todas as cadeias que, partindo do estado inicial, chegam a um estado marcado, caracterizando um conjunto de tarefas que o sistema pode completar (CURY, 2001). Neste exemplo tem-se Lm(G) = { ε, a, ae, abd, abcd,...}. Um estado é acessível se a partir do estado inicial q0 for possível alcançá-lo através de uma sequencia de eventos. Um estado é co-acessível ou não bloqueante se a partir dele é possível alcançar um estado marcado. Um autômato é acessível se todos os estados forem acessíveis e é co-acessível se todos os estados forem co-acessíveis. Um autômato acessível e co-acessível é chamado de trim ou aparado (CURY, 2001).

25 Composição síncrona Uma operação que pode ser feita com os autômatos é a composição síncrona. Esta operação é muito utilizada na TCS (Ramadge e Wonham, 1989). A composição síncrona de dois autômatos G1 e G2 é representada por G1 G2 e consiste em sincronizar eventos em comum nestes autômatos. Um evento comum só pode ser executado sincronizadamente nos dois autômatos, porém eventos diferentes podem ser executados independentemente. Na Figura 2.2 mostra-se a definição de composição síncrona apresentada por Cury (2001) onde Ac corresponde a componente acessível do autômato. Figura 2.2 Definição de composição síncrona de Cury (2001) Na Figura 2.3 tem-se um exemplo de sincronização com um evento em comum nos dois autômatos. Os eventos a e c podem ser executados assincronamente, ou seja, de modo independente em cada autômato, já o evento b só pode ser executado sincronizadamente nos dois autômatos, G1 e G2. Figura Sincronização G1 G2 com eventos em comum

26 TEORIA DE CONTROLE SUPERVISÓRIO (TCS) A Teoria de Controle Supervisório (TCS) foi introduzida por Ramadge e Wonham em 1989 para o controle de sistemas a eventos discretos. Nesta abordagem a modelagem do sistema é feita utilizando linguagens formais e autômatos. A planta, G, representa o comportamento do sistema sem qualquer ação de controle, onde todos os eventos ocorrem livremente. O supervisor, S, faz o controle da planta desabilitando alguns eventos que levam a comportamentos indesejáveis (TEIXEIRA, 2008; CURZEL, 2008; VIEIRA, 2007). Em cada estado do supervisor pode ser identificado um conjunto de eventos a serem desabilitados. Segundo a Teoria de Controle Supervisório, o conjunto de eventos Σ é particionado em um conjunto de eventos controláveis, Σc, e um conjunto de eventos não controláveis, Σu. Um evento é classificado como controlável se sua ocorrência pode ser impedida, desabilitada, pela ação de um agente de controle. Caso isto não seja possível o evento é classificado como não controlável (CURY, 2001). Na representação gráfica de um autômato, os eventos controláveis são representados com uma linha transversal seccionando os arcos direcionados. Uma linguagem K é dita ser controlável em relação a G se KΣ u L K. Um supervisor S não bloqueante existe para G tal que Lm(S/G) = K se e somente se K for controlável. Seja C(K,G) o conjunto de todas as sublinguagens de K que são controláveis em relação a G. Conforme Queiroz (2004), existe um único elemento supremo contido em C(K,G), o qual é representado por SupC(K,G). Assim, se a linguagem K não é controlável, é necessário calcular a linguagem controlável que mais se aproxime de K, e o supervisor ótimo S é tal que Lm(S/G) = SupC(K,G). A ação do supervisor, S, no sistema controlado, S/G, tem como objetivo desabilitar os eventos em G que não podem ocorrer. O comportamento do sistema controlado S/G pode ser descrito pelo SED resultante da composição síncrona S G, o qual permite somente a ocorrência das transições possíveis em G e não desabilitadas por S. O comportamento em malha fechada se dá por L(S/G) = L (S G) e Lm(S/G) = Lm(S G) (CURY, 2001). Um sistema controlado S/G é não bloqueante se Lm ( S/ G) = L( S/ G), ou seja, a partir de qualquer palavra gerada pelo sistema sob supervisão é possível sempre completar uma tarefa. Para desenvolver um projeto de acordo com a TCS, é necessário seguir algumas etapas (CURZEL, 2008), as quais são apresentadas a seguir.

27 Identificação do conjunto de subsistemas envolvidos no problema Primeiramente é necessário identificar quais os subsistemas que compõem a planta e conhecer todas as suas características. A título de exemplo, considere a linha de transferência ilustrada na Figura 2.4, a qual é composta de seis máquinas Mx (com x = 1,...,6) ligadas por quatro buffers (BA, BB, BC e BD) com capacidade unitária. Este problema foi introduzido por Queiroz e Cury (2000) e posteriormente utilizado em alguns trabalhos relacionados a este, tais como em (CRUZ, 2011) e (LEAL et al., 2012). Por ser um problema simples e ao mesmo tempo apresentar alguns dos problemas que são discutidos ao longo deste trabalho, o mesmo é utilizado em mais de um capítulo desta dissertação. Figura Linha de transferência industrial (QUEIROZ E CURY, 2000) Modelagem da planta Na modelagem da planta o comportamento de cada um dos subsistemas envolvidos deve ser representado por um autômato. Assim, para o exemplo da Figura 2.4, o comportamento independente de cada máquina Mx pode ser modelado pelo autômato da Figura 2.5, no qual os eventos Ax indicam o início da operação, e os eventos Bx indicam o fim da operação das máquinas, com x = 1,..., 6. Figura Autômato das máquinas (CRUZ, 2011) Mapeamento dos eventos controláveis e não controláveis dos subsistemas Nesta etapa identificam-se quais são os eventos controláveis, cujas ocorrências podem ser desabilitadas pela ação de controle, e eventos não controláveis, cujas ocorrências não podem ser desabilitadas pela ação de controle. Neste exemplo os eventos Ax de início de operação das máquinas são controláveis, e os eventos Bx de fim de operação das máquinas são não controláveis. Assim, tem-se a seguinte divisão do alfabeto: Σc = {A1, A2, A3, A4, A5, A6} e Σu = {B1, B2, B3, B4, B5, B6}.

28 Modelagem das especificações No intuito de restringir o comportamento da planta a fim de que a mesma não apresente comportamentos indesejados, são introduzidas as especificações de controle. Na TCS estas especificações são modeladas por autômatos, sendo que para cada especificação é apresentado um modelo específico. No exemplo em questão têm-se as seguintes especificações: Respeitar a capacidade do buffer evitando que seja depositada uma quantidade de peças superior à sua capacidade; neste caso a capacidade é 1 ; Impedir o início da operação de uma máquina se o armazém que realiza sua alimentação está vazio. Autômatos que modelam estas especificações EA, EB, EC e ED referentes aos buffers BA, BB, BC e BD respectivamente são apresentados na Figura 2.6. Figura Autômatos das especificações (CRUZ, 2011) Síntese dos supervisores A TCS faz distinção entre o sistema a controlar, denominado planta, e o agente de controle, denominado supervisor. A planta modela todos os comportamentos possíveis em malha aberta, inclusive os indesejáveis (TEIXEIRA, 2008). Assim, o supervisor é o elemento que restringe o comportamento do sistema para atender as especificações. A síntese do supervisor é feita a partir do comportamento do sistema a ser controlado e do conjunto de especificações. Dentre as abordagens existentes para a síntese de supervisores, neste trabalho serão apresentadas a abordagem monolítica, criada por Ramadge e Wonham (1989), e a abordagem modular local, criada por Queiroz e Cury (2000). 2.3 ABORDAGEM MONOLÍTICA Na abordagem monolítica considera-se que um único supervisor interage com a planta numa estrutura em malha fechada como visto na Figura 2.7. O supervisor mapeia a sequência de eventos gerados pela planta e impede a ocorrência de determinados eventos, restringindo o comportamento do sistema ao comportamento desejado. Assim, a ação de

29 28 controle tem o objetivo de habilitar e desabilitar certos eventos, conforme a sequência de eventos observados na planta (CURZEL, 2008). Figura 2.7- Controle supervisório monolítico (RAMADGE e WONHAM, 1989) Considere que o sistema é constituído por "n" subsistemas, cada qual representado por um autômato Gi, com i {1, 2,..., n}. Considere também que tenham sido identificadas "m" especificações de controle, cada qual representada por um autômato Ej, com j {1, 2,..., m}. Para a síntese do supervisor na abordagem monolítica, devem ser seguidas as seguintes etapas: Obtenção do modelo da planta G Para obter a planta G é necessário fazer a composição síncrona de todos os autômatos dos subsistemas, ou seja, G = G1 G2... Gn. No caso do exemplo acima que é composta por seis máquinas Mx (com x = 1,...,6) tem-se G = G1 G2 G3 G4 G5 G Obtenção do modelo da especificação E Para achar o modelo de especificação E, faz-se a composição síncrona dos autômatos das especificações individuais, E = E1 E2... Em. No caso do exemplo têm-se quatro especificações, E = EA EB EC ED Cálculo da linguagem alvo K O comportamento desejado para a planta sob supervisão é chamado de linguagem alvo, denotado por K. Por simplicidade, neste trabalho utiliza-se a mesma notação tanto para a linguagem quanto para o autômato que marca esta linguagem, ou seja, denota-se por K o autômato que marca a linguagem alvo. Assim, K é obtido através da composição síncrona de G e E, ou seja, K = G E Cálculo da linguagem controlável SupC(K,G) O próximo passo é calcular a linguagem controlável e achar um elemento supremo supc(k,g). A abordagem monolítica apresenta duas dificuldades. A primeira consiste no crescimento exponencial do número de estados do supervisor à medida que se aumenta o

30 29 número de subsistemas e especificações, exigindo grande capacidade de processamento computacional para criar o supervisor. Como resultado para o exemplo, tem-se um supervisor com 216 estados e 666 transições. Como segunda dificuldade, a existência de um único supervisor gera um programa muito grande que dificulta seu desenvolvimento, implementação, entendimento e manutenção, uma vez que gera um consumo elevado de memória por parte do dispositivo de controle, por exemplo, um CLP (CURZEL, 2008). 2.4 ABORDAGEM MODULAR LOCAL Para solucionar o problema da abordagem Monolítica, Queiroz e Cury (2000) desenvolveram a abordagem Modular Local, na qual é explorada a modularidade das especificações de controle e a própria modularidade da planta. Assim, são definidos os supervisores locais, onde a atuação conjunta dos supervisores coordena o comportamento do sistema como um todo (CURZEL, 2008). Os supervisores locais SRi controlam uma planta local. Cada especificação Ej em sincronia com as plantas que têm eventos em comum definem uma célula de controle. Conforme definido em (VIEIRA, 2007), uma célula de controle é constituída por um supervisor e pelos subsistemas coordenados por ele. O exemplo apresentado na Figura 2.8 ilustra como formam as plantas locais e os supervisores locais. No exemplo, os subsistemas G1 e G2 têm eventos em comum com a especificação EA. A composição síncrona de G1 e G2 formam a planta local, e o conjunto EA, G1 G2 é usado para calcular o supervisor local. Figura Células de controle

31 30 Nesta abordagem, os autômatos que representam o sistema são menores, com menos estados que na abordagem monolítica. Consequentemente os supervisores obtidos são menores prevenindo-se assim o aumento do número de estados. A tarefa de fazer com que o sistema em malha fechada obedeça ao conjunto de restrições é dividida em subtarefas que são realizadas por diferentes supervisores como visto na Figura 2.9. As especificações são tratadas localmente e os supervisores são projetados com uma visão parcial da planta. Figura 2.9- Esquema de controle modular local (QUEIROZ e CURY, 2000) Para se desenvolver um projeto de TCS utilizando-se a abordagem modular local, devem ser seguidas as seguintes etapas: Representação por sistema produto Na abordagem modular local, deve-se obter uma representação por sistema produto (RSP) mais refinada possível para a planta (QUEIROZ e CURY, 2000), o que consiste em obter o maior número de subsistemas assíncronos (que não compartilham eventos comuns) que modelam a planta em malha aberta. Caso a modelagem obtida inicialmente inclua um conjunto de subsistemas que compartilhem eventos, basta substituir este conjunto pelo autômato resultante da composição síncrona dos mesmos. Assim como na Figura 2.10 (a), é necessário fazer a composição síncrona dos subsistemas G1 e G2, pois ambos têm o evento a e também dos subsistemas G4 e G5, pois ambos têm o evento g. Para isto é feita a composição síncrona G1 G2 e G4 G5 resultando na representação por sistema produto da Figura 2.10 (b). No exemplo estudado na Figura 2.4, nas plantas não existem eventos em comum, logo os autômatos da Figura 2.5 já representam o sistema produto Obtenção das plantas locais Para encontrar cada planta local, é necessário identificar os subsistemas que possuem eventos em comum com a especificação correspondente. Assim, cada planta local é obtida pela composição síncrona dos subsistemas afetados por uma dada especificação. Na Tabela 2.1 pode ser visto o exemplo da linha de transferência da Figura 2.4. Para cada especificação da Figura 2.6 é verificado quais eventos estão envolvidos e de que subsistemas. Por exemplo,

32 31 a especificação EA tem os eventos B1 e A2, que fazem parte dos subsistemas G1 e G2. Logo a planta local GLA será a composição síncrona de G1 e G2. Figura 2.10 Representação por sistema produto Tabela Plantas locais Especificações Eventos Subsistemas Plantas Locais EA B1, A2 G1, G2 GLA = G1 G2 EB B3, A4 G3, G4 GLB = G3 G4 EC B2, B4, A5 G2, G4, G5 GLC = G2 G4 G5 ED B5, A6 G5, G6 GLD = G5 G Obtenção das especificações locais As especificações locais são obtidas pela composição síncrona das plantas locais com as respectivas especificações. No exemplo anterior as especificações locais são dadas por: KA = GLA EA, KB = GLB EB, KC = GLC EC, KD = GLD ED.

33 Obtenção das linguagens controláveis Nesta etapa é necessário calcular a linguagem controlável contida em cada especificação local. Para o exemplo tem-se: SupC(KA,GLA), SupC(KB,GLB), SupC(KC,GLC), SupC(KD,GLD). Na Figura 2.11 são apresentados os supervisores locais SlocA, SlocB, SlocC e SlocD. Figura Supervisores locais (CRUZ, 2011) Teste de modularidade local Para que a ação conjunta dos diversos supervisores locais seja não bloqueante, devese garantir que os supervisores locais são não conflitantes. Para tanto, deve-se realizar o chamado teste da modularidade local, o qual consiste em fazer a composição síncrona de todos os supervisores locais e verificar se o autômato resultante é aparado (trim). No exemplo o teste resultou em um autômato trim com 216 estados Obtenção dos supervisores reduzidos Para reduzir o tamanho da memória no CLP diminuindo o número de estados e transições, é possível fazer a redução dos supervisores (VAZ e WONHAM, 1986 apud QUEIROZ, 2004). Um supervisor reduzido S1 é equivalente a um supervisor S se apresentar o mesmo comportamento, ou seja, se L(S1/G) = L(S/G) e Lm(S1/G) = Lm(S/G) (QUEIROZ, 2004). Para isto são utilizadas ferramentas para a retirada de algumas informações da planta, mas é mantida a ação de controle que promove as desabilitações. Como o supervisor trabalha em conjunto com o sistema produto, as informações retiradas não se perdem (CRUZ, 2011;

34 33 QUEIROZ e CURY, 2000). Para o exemplo da Figura 2.4 foi calculado os supervisores reduzidos, mostrados na Figura 2.12, utilizando a ferramenta TCT. Os eventos desabilitados são representados com a linha tracejada. Figura Supervisores reduzidos (CRUZ 2011) 2.5 CONCLUSÃO AO CAPÍTULO Neste capítulo foi feita uma apresentação da Teoria de Controle supervisório (TCS), abordando o que é um Sistema a Eventos Discretos (SED) e suas formas de representação. Foram apresentados os passos para fazer um projeto de controle segundo a TCS e duas formas de fazer a síntese do supervisor: a abordagem monolítica, proposta por Ramadge e Wonham em 1989; e a abordagem modular local proposta por Queiroz e Cury (2000). Na abordagem monolítica o cálculo de um único supervisor responsável por todas as especificações de controle necessita de um maior esforço computacional e leva à explosão do número de estados quando se têm plantas de grande porte. Além do que, a implementação de supervisores com maior número de estados e transições traz dificuldades no entendimento e na manutenção da lógica de controle referente ao supervisor. Na abordagem modular local a ação de controle é dividida em vários supervisores o que reduz o esforço computacional para o cálculo dos supervisores. Além disso, os supervisores obtidos são menores do que o supervisor monolítico, o que resulta em implementações modulares que são de mais fácil compreensão e manutenção. A desvantagem desta abordagem é a possibilidade de bloqueio na ação conjunta dos supervisores, que requer a realização do teste de modularidade, e no pior caso tem a mesma complexidade computacional que a síntese do supervisor monolítico.

35 34 3 IMPLEMENTAÇÃO DE CONTROLE SUPERVISÓRIO EM CLPs Neste capítulo será feita uma apresentação sobre a arquitetura de controle supervisório apresentado por Queiroz e Cury (2000). Será apresentada também a implementação desta arquitetura em Controladores Lógicos Programáveis (CLPs), apresentando algumas linguagens utilizadas para programação de CLPs, Sequential Function Charts (SFC) e Ladder Diagram, que são utilizadas neste trabalho e alguns problemas que surgem neste tipo de implementação. 3.1 ESTRUTURA DE IMPLEMENTAÇÃO Segundo Ramadge e Wonham (1989) os eventos são gerados espontaneamente na planta e os supervisores têm a função de somente desabilitar os eventos indesejados como mostrado na Figura 3.1. Figura Arquitetura segundo Ramadge e Wonham (1989) No intuito de possibilitar a aplicação desta teoria e que mantivesse coerência com este aspecto da TCS, Queiroz e Cury (2002) propuseram uma arquitetura de controle supervisório estruturada em três níveis. Nesta arquitetura é utilizada uma interface entre a planta e os supervisores sintetizados em conformidade com a TCS. Na Figura 3.2 pode ser visto que esta interface é constituída pelo nível sistema produto e o nível procedimentos operacionais. A planta de Ramadge e Wonham (1989) é considerada como o sistema produto, procedimentos operacionais e sistema a ser controlado. O sistema de controle, SC, é todo implementado no CLP e consistem nos supervisores, sistema produto e procedimentos operacionais (VIEIRA, 2007). Desta forma, nesta estrutura os supervisores mantêm sua função de apenas desabilitar eventos controláveis, como proposto por Ramadge e Wonham (1989), e a geração de eventos é feita no nível da Planta Ramadge-Wonham. O sistema produto tem como entrada as respostas do sistema a ser controlado, que são os eventos não controláveis. Estas respostas são tratadas no sistema produto que gera os eventos controláveis, que são os comandos mandados

36 35 para o procedimento operacional. Os procedimentos operacionais fazem a comunicação com o sistema a ser controlado. Para cada evento controlável é normalmente associado um procedimento operacional. Os procedimentos operacionais permitem realizar um detalhamento do processo de modelagem da planta, simplificando a modelagem do sistema e das especificações. Com esta simplificação é possível reduzir a complexidade do processo de síntese do supervisor, diminuindo o número de estados e eventos. As saídas e entradas do sistema a ser controlado são estabelecidas em atuadores e sensores que estão no sistema a ser controlado (VIEIRA, 2007). Figura Arquitetura de controle supervisório, Queiroz e Cury (2002) 3.2 IMPLEMENTAÇÃO EM CLPs CLPs são dispositivos de controle muito utilizado a industria. Um CLP trabalha de forma cíclica sendo que primeiramente lê os dados de entrada, processa o código de modo sequencial e no final atualiza a saída. Este processo cíclico pode ser visto na Figura 3.3.

37 36 Figura Processo cíclico do CLP A programação de CLPs é normatizada através das normas IEC (VIEIRA, 2007). Esta série é estruturada nos seguintes volumes: IEC Programmable controllers - Part 1: General information, 2003, 2nd. ed.; IEC Programmable controllers - Part 2: Equipment requirements and tests, 2003, 2nd. ed.; IEC Programmable controllers - Part 3: Programming languages, 2003, 2nd. ed.; IEC/TR Programmable controllers - Part 4: User guidelines 2004, 2nd. ed.; IEC Programmable controllers - Part 5: Communications, 2000; IEC Programmable controllers - Part 7: Fuzzy control programming, 2000; IEC/TR Programmable controllers - Part 8: Guidelines for the application and implementation of programming languages, 2003, 2nd. Ed; (VIEIRA, 2007). A norma IEC Programmable controllers - Part 3: Programming languages define 5 linguagens usadas para a programação de CLPs. A linguagem mais utilizada é a Ladder Diagram. Esta é uma linguagem gráfica que permite a manipulação de variáveis do tipo inteiro e real, porém é mais adequada para manipulação de variáveis Booleanas. Remete ao conceito de diagramas de relés e envolve apenas decisões lógicas. Outra importante linguagem é Sequential Function Charts (SFC) que é uma linguagem onde o programa é feito em passos e transições. É a linguagem mais apropriada à implementação do controle de sistemas sequenciais. Estas duas linguagens serão vistas com mais detalhes nas seções e

38 Outras linguagens gráficas que a norma define são: Function Block Diagram, que remete a diagramas com circuitos digitais de portas lógicas; Instruction List, que remete à linguagem Assembly. A quinta linguagem que a norma define é uma linguagem de alto nível denominada Structured Text. Esta linguagem é utilizada quando no programa a manipulação de variáveis inteiras e reais se faz necessária, bem como quando são necessárias estruturas de decisão e repetição. É uma linguagem textual que pode ser programada em qualquer editor de texto. A interpretação/legibilidade e documentação do algoritmo, quando editado nesta linguagem, também são mais simples do que o correspondente editado em Ladder Diagram ou em Function Block Diagram. Tendo em vista que a implementação de um projeto mais complexo envolve o controle de sistemas sequenciais, algoritmos com estruturas de decisão e repetição, bem como de manipulação de variáveis de diversos tipos, a modularização do programa do usuário empregando diferentes linguagens de programação permite a seleção da linguagem mais apropriada para cada um dos módulos deste programa (VIEIRA, 2007; FABIAN e HELLGREN, 1998). 3.3 ALGUMAS LINGUAGENS DE PROGRAMAÇÃO Ladder Diagram Ladder Diagram é uma linguagem gráfica, que através de contatos abertos e fechados trabalha com variáveis Booleanas, tornado-as verdadeiras ou falsas. Na Figura 3.4 são mostrados alguns símbolos, exemplo de memórias e variáveis utilizadas na linguagem Ladder Diagram. A condição de contato normalmente fechado só executa a próxima instrução se a variável M30.0, INTERCALA_A2_A4, por exemplo, apresentar o valor falso. O contato normalmente aberto executa a próxima instrução se a variável M24.0, SD.0, apresentar o valor verdadeiro. A bobina mantém o valor da variável M10.1, da1, se as condições anteriores a ela forem verdadeiras, caso contrário o valor será falso. Set torna a variável M24.1, SD.1, com valor verdadeiro, O Reset torna a variável M24.0, SD.0, com valor falso. A chamada de função chama uma função ATUALIZA que está implementada em outro bloco. Pulso torna a variável M100.1, BORDA, com valor positivo por um ciclo de varredura quando a condição anterior torna-se verdadeira.

39 38 Figura Símbolos da linguagem Ladder Diagram Os supervisores e módulo do sistema produto podem ser representados em Ladder Diagram, por exemplo. Na Figura 3.5 é mostrado o supervisor SRD da linha de transferência industrial da Figura 2.4. Se o supervisor estiver no estado 0 e ocorrer o evento B5, ou seja, a variável SD.0 for verdadeira e a variável M2B5 for verdadeira, o autômato transita para o estado 1. Para isto a variável SD.1 torna-se verdadeira, a variável SD.0 e a variável M2B5 tornam-se falsas SFC - Sequential Function Chart e Structured Text Sequential Function Chart (SFC) é uma linguagem de programação que estrutura uma seção de código de forma gráfica para programar controladores lógicos programáveis, CLPs. A SFC possibilita a programação em operações sequenciais. O processo consiste em passos e transições no qual cada passo é associado um conjunto de ações. O programa muda de um passo para outro dependendo da transição, condições, que pode ser programada em Ladder Diagram ou em Function Block Diagram (FDB). Nos CLPs da Siemens é utilizado o editor SIMATIC / S7-GRAPH. Na Figura 3.6 são mostrados alguns símbolos usados em SFC.

40 39 Figura Programa em Ladder Diagram Figura 3.6 Símbolos da linguagem SFC Um programa é estruturado com os seguintes blocos: o Program, o Function (FC) e o Function Block (FB). Nos CLPs da Siemens o Organization Block (OB) é um Program e ainda é necessário criar uma tabela de variáveis, chamada Symbols.

41 40 Os Function Blocks (FB) devem ser instanciados, criando uma instância DB, na qual estão contidos os dados e os parâmetros do controle sequencial do sistema. 3.4 PROBLEMAS NA IMPLEMENTAÇÃO A implementação da TCS em CLPs não é trivial, sendo necessários alguns cuidados. Existem alguns problemas de implementação que podem trazer a falta de sincronismo da planta com o programa implementado no CLP. Alguns dos trabalhos que abordam este tema são: (FABIAN e HELLGREN, 1998), (VIEIRA, 2007), (HASDEMIR et al., 2008), (CRUZ, 2011), (LEAL et al., 2012), entre outros. Na sequência são apresentadas as principais questões a serem consideradas na implementação da estrutura de controle supervisório em CLPs Causalidade O problema da causalidade é levantando com a pergunta Quem gera o que? (FABIAN e HELLGREN, 1998). Para a TCS a planta gera todos os eventos e o supervisor apenas desabilita os eventos controláveis indesejados, como visto na Figura 3.1. Segundo (MALIK, 2002), na prática os eventos controláveis não são gerados espontaneamente pela planta Efeito avalanche O efeito avalanche se dá quando a ocorrência de um evento provoca indevidamente sucessivas transições de estado no programa do CLP. Na Figura 3.7 é mostrado um autômato cuja implementação é susceptível ao efeito avalanche. Figura Autômato susceptível ao efeito avalanche (HASDEMIR et al., 2008) Considere por exemplo que o autômato da Figura 3.7 seja implementado pelo programa apresentado na Figura 3.8. Se o autômato estiver no estado q1 (se a variável q1 for verdadeira) e ocorrer o evento σ1, o programa muda para o estado q2, porém o evento σ1 continua ativo (a variável continua verdadeira) e o programa avança para o estado q3 no mesmo ciclo. Assim, a ocorrência de σ1 provoca a transição do estado q1 para o estado q3 no programa, enquanto a planta real transita para o estado q2, uma vez que o evento σ1 ocorreu uma única vez.

42 41 Figura Programa em Ladder Diagram com efeito avalanche Segundo Fabian e Hellgren (1998), uma solução para o problema do efeito avalanche consiste em inverter a ordem de algumas linhas de programa, conforme ilustrado na Figura 3.9. Deste modo, se o autômato estiver no estado q1 e se o evento σ1 estiver ativo, o programa muda para o estado q2, não ocorrendo o efeito avalanche. Figura Programa em Ladder Diagram sem efeito avalanche Esta solução, no entanto, não é eficiente para todos os casos. Para o autômato da Figura 3.10, por exemplo, a solução de inversão de linhas de programa não evita o efeito avalanche.

43 42 Figura Autômato susceptível ao efeito avalanche (HASDEMIR et al., 2008) Para resolver este problema, Hasdemir et al. (2004, apud VIEIRA 2007), criam variáveis duplicadas para cada estado do supervisor. Uma variável está associada ao ciclo atual do supervisor e outra relacionada ao ciclo de atualização seguinte. Assim, a ordem de implementação é irrelevante. Esta proposta é aplicável para autômatos nos quais existem ciclos na estrutura de transição de estados, mas aumenta o número de variáveis no sistema. Para Vieira (2007), um procedimento simples é criar apenas uma variável, que se torna verdadeira quando um supervisor muda de estado, e torna-se falsa no final da seção de código referente à implementação do supervisor, como pode ser visto na Figura Assim não são necessárias tantas variáveis como na proposta de Hasdemir et al. (2004) e a ordem de implementação não é relevante, sendo aplicável também para autômatos em que existam ciclos na estrutura de transição de estados. Esta solução funciona quando o CLP é implementado na linguagem Ladder Diagram. A proposta de Cruz (2011) para o efeito avalanche é duplicar as variáveis que representam a ocorrência de eventos, e quando o evento é usado para mudar o estado de um supervisor, o mesmo torna-se falso. Esta proposta é explicada em detalhes na seção 4.2, porém também tem o custo de aumentar o número de variáveis Incapacidade de reconhecer a ordem dos eventos O problema da incapacidade de reconhecer a ordem dos eventos ocorre quando é verificada, na etapa de leitura das entradas do CLP, a ocorrência de dois ou mais eventos, não sendo possível saber qual ocorreu primeiro. Na Figura 3.12 é mostrado um diagrama de tempo onde σ Planta é um sinal elétrico proveniente da planta cuja mudança de nível (borda de subida) é associada a um evento não controlável da planta, registrado no programa do CLP como σ CLP. Os eventos σ planta1 e σ planta2 ocorrem na planta durante a fase de processamento, em t1 e t2, do CLP e só são verificados pelo CLP na leitura do próximo ciclo, não havendo como saber qual evento ocorreu primeiro para ser tratado nesta ordem. (FABIAN e HELLGREN, 1998).

44 43 Figura 3.11 Proposta de Vieira (2007) para efeito avalanche Se a ação de controle depende da ordem dos eventos não controláveis, mudando para estados diferentes, ocorre o problema da incapacidade de reconhecer a ordem dos eventos, como ilustrado na Figura Segundo Fabian e Hellgren (1998), para que este problema não ocorra, é necessário que o autômato do supervisor apresente a propriedade de insensibilidade ao entrelaçamento de eventos não controláveis, o que significa dizer que a ordem de ocorrência de eventos não controláveis não determina a ação de controle.

45 44 Figura Diagrama temporal Figura Problema da incapacidade de reconhecer a ordem dos eventos Sincronização inexata O problema da sincronização inexata (FABIAN e HELLGREN 1998) pode ocorrer quando o autômato do supervisor possui algum estado no qual a ocorrência de um evento não controlável resulta na alteração da ação de controle. Neste caso, é possível que durante o tempo necessário para que o supervisor seja atualizado com a informação de ocorrência do evento não controlável, a ação de controle seja indevidamente aplicada à planta. Para ilustrar este problema considere o supervisor representado pelo autômato mostrado na Figura Considere que o estado ativo do supervisor seja o estado 0 e que na etapa de leitura das entradas do CLP não é verificada nenhuma mudança nas mesmas (não é registrada a ocorrência do evento σ u ). Suponha agora que na etapa de execução do programa ocorra a mudança de nível no sinal de entrada do CLP que corresponde ao evento σ u. Tendo em vista que as alterações nas entradas do CLP são registradas somente na etapa de leitura, o evento σ u

46 45 só será registrado no próximo ciclo de varredura do CLP. Assim, embora fisicamente o evento σ u tenha acontecido na planta antes da aplicação do evento σ c, e, portanto, a planta esteja no estado correspondente ao estado 2 do autômato do supervisor, o programa do CLP continua no estado 0 e então aplica indevidamente na planta a ação de controle correspondente ao evento σ c, violando assim a especificação de controle. Figura Autômato susceptível ao problema de sincronização inexata Para que o problema não ocorra, os autores apresentam uma propriedade, originalmente introduzida por Balemi (1992, apud FABIAN e HELLGREN 1998). Esta propriedade trata da definição de linguagem insensível ao atraso. Propriedade 1: Uma linguagem K é dita insensível ao atraso se para s K σ, c Σ c e σ Σ u u, quando sσ c, sσ u Κ sσ σ,sσ σ K então u c c u. De acordo com esta propriedade, se nenhuma escolha feita pelo supervisor for invalidada pela ocorrência de um evento não controlável, pode-se afirmar que o supervisor é insensível ao atraso, pois o supervisor pode seguir as palavras formadas independente da ordem de ocorrência de tais eventos (sσcσu e sσuσc são ambos mapeados pelo supervisor). Assim, se a linguagem da planta sob supervisão (L(S/G)) é insensível ao atraso, então o problema da sincronização inexata não ocorre. Considere que o autômato da Figura 3.15 representa a linguagem da planta sob supervisão. Note que esta linguagem é insensível ao atraso, pois indiferente de ocorrer o evento controlável σc antes ou depois do evento não controlável σu, chega-se ao mesmo estado. Figura Propriedade 1

47 46 Basile e Chiacchio (2007) expandem o conceito de linguagem insensível ao atraso de forma a considerar o entrelaçamento entre um evento controlável e uma sequência de eventos não controláveis de tamanho k. Assim, para que um autômato apresente uma linguagem com esta propriedade é necessário que, um evento controlável habilitado em um determinado estado deva também estar habilitado no estado que pode ser alcançado se uma sequência de eventos não controláveis de tamanho k acontecer. Os autores introduziram então a noção de linguagem insensível ao entrelaçamento de atraso k. para Propriedade 2: Uma linguagem K é dita insensível ao entrelaçamento de atraso k se, * s K, σ c Σ c e σ, quando sσ c, sσ u Κ então sσ uσ c K. u Σ u É importante observar que os autores apresentam um relaxamento na propriedade original de forma que a condição sσ cσ u Κ não é mais exigida nesta definição. Os autores justificam este relaxamento com a argumentação de que na TCS embora os eventos sejam habilitados pelo supervisor, a geração deles é feita pela planta. Assim, se o supervisor habilita σ, então a sequência c σ c u σ ocorre enquanto u sσ não pode ocorrer. Sob o ponto de vista do controle supervisório, se sσ c L( S / G ) mas sσ cσ u L( S / G ) pode-se afirmar que sσ cσ u L( G ), ou seja, que o evento não controlável σ é fisicamente impossível de u acontecer na planta após a aplicação da ação de controle Assim, se considerarmos k = 1, o autômato mostrado na Figura 3.16 atende a propriedade 2, mas não atende a propriedade 1, pois no estado 1 não existe o evento σu. σ. c Figura Propriedade 2 Deve-se observar que para que esta propriedade seja suficiente para garantir a não ocorrência do problema de sincronização inexata, é necessário que na implementação sejam tomados alguns cuidados. Cruz (2011) apresenta uma solução para sincronização inexata, mas para que esta solução seja viável é necessário atender a propriedade 1. Tal solução será apresentada no Capítulo 4.

48 Escolha O problema da escolha ocorre quando dois ou mais eventos controláveis estão habilitados para ocorrer num dado estado do supervisor, porém somente um poderá ser gerado até que ocorra a atualização dos supervisores (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. Segundo Malik (2002), se for priorizado o tratamento de um evento em relação aos outros, parte do sistema poderá nunca ser executada, além de ser possível ocorrer o bloqueio do sistema. O supervisor SRC da Figura 2.12 (b) do sistema da linha de transferência da Figura 2.4 pode ser reescrito como na Figura Se no estado 0 for sempre dada prioridade ao evento A2, a máquina M4 nunca entrará em operação. Figura Supervisor SRC Outro exemplo é da Figura Se no estado 2 for dada prioridade para o evento B, o evento D nunca ocorrerá, além de causar bloqueio, pois o sistema nunca chegará a um estado marcado, logo nunca será completada a tarefa. Figura Autômato susceptível ao problema da escolha Cruz (2011) apresenta uma solução que será vista na seção Será esta a solução utilizada no presente trabalho.

49 CONCLUSÃO AO CAPÍTULO Neste capítulo foi mostrada a estrutura de implementação da TCS em CLPs, sua implementação conforme a norma IEC 61131, algumas linguagens que são utilizadas e alguns problemas como a escolha, avalanche, dentre outros. A seguir serão apresentadas duas propostas de implementação da estrutura de controle supervisório em CLPs. A proposta de Cruz (2011) que é implementada em Ladder Diagram, e a proposta de Vieira (2007) que é implementada em SFC.

50 49 4 METODOLOGIA DE IMPLEMENTAÇÃO DECON9 Neste capítulo será apresentada a metodologia de implementação denominada DECON9 (LEAL et at., 2012, CRUZ, 2011). Esta metodologia tem como base a abordagem modular local de síntese de supervisores (QUEIROZ E CURY, 2000) e utiliza a linguagem Ladder Diagram para implementação da estrutura de controle no CLP. Ela se diferencia em função de possibilitar o tratamento de diversos eventos num mesmo ciclo de varredura do CLP, motivo pelo qual é utilizada como referência para o desenvolvimento deste trabalho. 4.1 APRESENTAÇÃO DA METODOLOGIA A proposta de Cruz (2011) se baseia na separação do tratamento dos eventos de acordo com a sua controlabilidade de forma a priorizar o tratamento dos eventos não controláveis. Assim, tanto a implementação no nível do sistema produto (SP) quanto dos supervisores é dividida em dois blocos distintos, sendo um deles destinado ao tratamento das transições de estado decorrentes de eventos não controláveis e o outro destinado ao tratamento dos eventos controláveis, conforme ilustrado na Figura 4.1. Figura 4.1 Fluxograma proposto por Cruz (2011) Primeiramente são tratados no sistema produto todos os eventos não controláveis que ocorreram na planta. Em seguida, é feita a atualização de estados nos supervisores devido a estes eventos. Na terceira parte são feitas as desabilitações dos eventos controláveis para em seguida tratar no sistema produto e nos supervisores os eventos controláveis. Com isto é possível tratar no mesmo ciclo de varredura todos os eventos não controláveis que ocorreram na planta e ainda os eventos controláveis que não foram desabilitados. Segundo Cruz (2011), o fluxograma da Figura 4.1 pode ser expandido para o fluxograma mostrado na Figura 4.2, com os 9 passos. Nesta metodologia, o programa

51 50 principal é implementado num bloco denominado OB1. Este é um bloco de execução cíclica. Nele é escrito todo o programa e chamadas a outros blocos. O primeiro passo só é executado no primeiro ciclo de varredura do CLP, os oito passos restantes são executados sequencialmente e ciclicamente, algumas vezes chamando outros blocos. O nome DECON9 advém de DEcomposing the CONtrol Implementation DEpending on the CONtrolability of the events sendo que o número 9 refere-se à quantidade de passos necessários para a sua implementação. Figura Fluxograma completo da rotina principal (CRUZ, 2011) 4.2 ESTUDO DE CASO: LINHA DE TRANSFERÊNCIA INDUSTRIAL Cruz (2011) utilizou um problema apresentado por (QUEIROZ E CURY, 2000) para mostrar sua proposta. Trata-se de uma linha de transferência composta de seis máquinas Mx (com x = 1,...,6) ligadas por quatro armazéns (BA, BB, BC e BD) com capacidade unitária, dispostos como mostrado no segundo capítulo na Figura 2.4. Esta linha tem como objetivo transportar uma peça de uma máquina à outra sem que ocorram overflow e underflow nos armazéns intermediários. Os autômatos que modelam as máquinas Mx (com x = 1,...,6) podem ser vistos na Figura 2.5. As especificações de não overflow e não underflow nos armazéns são apresentadas na Figura 2.6.

52 Figura 4.3 Programa principal - OB1 51

53 52 Sintetizando os supervisores pela abordagem modular local (QUEIROZ, 2004) obtém-se os supervisores não conflitantes, que após serem reduzidos, são apresentados na Figura Maiores detalhes sobre as especificações e os supervisores podem ser encontrados em (CRUZ, 2011) e (QUEIROZ e CURY, 2000). Na Figura 4.3 apresentam-se trechos da rotina principal do programa OB1 para o estudo de caso, identificando cada um dos passos da metodologia DECON Primeiro passo Inicialização dos estados Primeiramente são realizadas as inicializações de estado de modo a definir o estado inicial dos supervisores e de cada um dos subsistemas que compõem o sistema produto. Este passo é realizado a partir da chamada de uma sub-rotina denominada INICIALIZA (ver Figura 4.3) e é executado somente no primeiro ciclo de varredura do CLP. Tendo em vista a simplicidade desta sub-rotina, ela não é apresentada neste trabalho Segundo passo Leitura das entradas No segundo passo é feita a chamada a uma sub-rotina denominada LEITURA (ver Figura 4.3), a qual é responsável por identificar alterações nos sinais de entrada do CLP decorrentes de mudanças na planta e registrar as mesmas como eventos não controláveis. Este passo ocorre em todo ciclo de varredura do CLP e os eventos são armazenados em um grupo de variáveis M1Bi, onde i = 0, 1,..., número de eventos. Como pode ser visto o exemplo na Figura 4.4, se houve mudança no sinal de entrada M40.0, a variável M1.B1 torna-se verdadeira, que representa o evento não controlável B1, por exemplo. Mais detalhes podem ser vistos em (CRUZ, 2011). Figura Parte da sub-rotina de leitura

54 Terceiro passo O terceiro passo é dividido em duas partes. Na primeira parte é chamada uma subrotina denominada ATUALIZA, visto na Figura 4.5, que faz uma cópia dos valores armazenados no grupo de memórias M1Bi para um grupo de memórias M2Bi de modo a salvar neste grupo as informações dos eventos não controláveis Bi que ocorrem na planta. Esta duplicação de informação ocorre para evitar o efeito avalanche e não perder a informação dos eventos para os próximos passos. Figura Bloco ATUALIZA Na segunda parte são chamadas as sub-rotinas responsáveis pelas transições de estado devido aos eventos não controláveis (ENC) em cada um dos subsistemas Gi que compõem o sistema produto, ENC G1, ENC G2,... Como o sistema produto é composto por subsistemas assíncronos, então o mesmo evento não provoca transição de estado em mais de um subsistema, de forma que não é necessário atualizar o grupo M1Bi chamando o bloco ATUALIZA antes de cada subsistema. Quando um subsistema Gi muda de estado, o evento que gerou a mudança torna-se falso. Isto é feito para não ocorrer o problema do efeito avalanche (FABIAN e HELLGREN, 1998). Na Figura 4.6 (a) é apresentado o ENC G1, referente ao autômato G1 na Figura 4.6 (b). Se o subsistema G1 estiver no estado 1 e o evento B1 ocorrer, variável M2B1 estiver verdadeira, G1 muda para o estado 0 e o valor de B1 do grupo de variáveis M2, M2B1, torna-se falso.

55 54 Figura 4.6 Eventos não controláveis no subsistema Gi (a) ENC G1; (b) Autômato G Quarto passo Neste passo são chamados os supervisores (ENC SA, ENC SB,...) para tratar os eventos não controláveis. Porém, antes da chamada a cada um dos supervisores é necessário fazer a atualização dos eventos, chamando o bloco ATUALIZA, pois os supervisores não são necessariamente assíncronos e então o mesmo evento pode promover a transição de estado em mais de um supervisor. Esta chamada pode ser vista na Figura 4.3 passo 4. A Figura 4.7 mostra o supervisor SA, que trata os eventos não controláveis, ENC SA. Se o supervisor SA estiver no estado 0 e o ocorrer o evento B1, o supervisor muda para o estado 1 e o evento B1 do grupo de variáveis M2, M2B1, torna-se falso. A variável M2B1 torna-se falsa para evitar o efeito avalanche. Antes de chamar o próximo supervisor, são atualizados novamente os eventos, M2Bi, chamando o bloco ATUALIZA. Depois deste quarto passo, todos os eventos não controláveis gerados pela planta foram tratados. Figura 4.7 Eventos não controláveis nos supervisores (a) ENC SA; (b) Autômato SA Quinto passo Neste passo são feitas as desabilitações dos eventos controláveis em função do estado atual dos supervisores. Na Figura 4.3 mostra-se a chamada da função DESABILITAÇÕES e na Figura 4.8 mostra-se parte do programa de como é feita a desabilitação dos eventos A1, A2 e A3. Se o estado do supervisor SA for igual a 1, é

56 55 desabilitado o evento A1. Se o estado do supervisor SA for zero ou o estado do supervisor SC for 1 ou 2, é desabilitado o evento A2. Figura 4.8 Parte do programa de DESABILITAÇÕES Sexto passo O sexto passo é dedicado ao tratamento da escolha e só é executado quando este problema é detectado. Isto ocorre quando dois eventos controláveis estão habilitados e podem ser gerados, porém só um pode ocorrer. No exemplo utilizado, o problema da escolha é encontrado no estado 0 do supervisor SC Figura 2.12 (b), pois os eventos A2 e A4 estão habilitados e a ocorrência de um destes leva à desabilitação do outro. Assim, somente um deles poderá ser gerado. Na solução adotada pelos autores foi de que a cada ciclo de varredura do CLP a variável INTERCALA_A2_A4 muda de valor (verdadeiro ou falso). Assim, quando as duas variáveis da2 e da4 estão falsas (os eventos A2 e A4 não estão desabilitados), é feita a chamada ao bloco TRATA ESCOLHA, conforme mostrado na Figura 4.3. Desta forma, de acordo com o valor assumido pela variável INTERCALA_A2_A4, o bloco TRATA ESCOLHA desabilita aleatoriamente um dos eventos (LEAL et al., 2009). Como pode ser visto na Figura 4.9, quando a variável INTERCALA_A2_A4 for verdadeira, o evento A2 é desabilitado, quando falsa o evento A4 que será desabilitado. Se no sistema não existir o problema de escolha, este sexto passo não é implementado (CRUZ, 2011).

57 56 Figura 4.9 Bloco TRATA ESCOLHA Sétimo passo Neste passo são tratados os eventos controláveis (EC) no nível do sistema produto. Assim, os eventos controláveis que não foram desabilitados no ciclo de varredura atual são gerados neste passo. Na Figura 4.3 é mostrada a chamada destes blocos, EC G1, EC G2... Por exemplo, a Figura 4.10 (a) mostra o bloco EC G1 referente ao autômato G1 da Figura 4.10 (b). Quando G1 está no estado 0 e o evento A1 não está desabilitado, o evento A1 é gerado e G1 vai para o estado 1. Figura 4.10 Eventos controláveis no subsistema Gi (a) EC G1; (b) Autômato G Oitavo passo O oitavo passo faz a atualização de estados nos supervisores devido aos eventos controláveis gerados no nível do sistema produto. Na Figura 4.3 é mostrada a chamada destes blocos, EC SA, EC SB... Na Figura 4.11 (a) mostra-se o supervisor EC SA. Se o supervisor SA está no estado 1 e o evento A2 ocorreu, o supervisor muda para o estado 0. Figura 4.11 Eventos controláveis no supervisor (a) EC SA; (b) Autômato SA

58 Nono passo No nono passo as informações sobre os eventos controláveis são mapeadas em endereços de saídas do CLP de forma a atuar sobre a planta. Na Figura 4.3 pode ser visto a chamada do bloco de escrita. Mais detalhes podem ser vistos em Cruz (2011). 4.3 RESULTADOS Implementando o exemplo acima e feita a simulação conforme a proposta de Cruz (2011) têm-se os resultados vistos na Tabela 4.1. Nesta simulação foi considerado que o evento não controlável ocorreu no ciclo seguinte do evento controlável equivalente. Tabela Resultado da execução do DECON9 Ciclo Eventos Não Eventos Controláveis Controláveis 1 A1, A3 2 B1, B3 A4 3 B4 A3, A5 4 B3, B5 A2, A6 5 B2, B6 A1, A5 6 B1, B5 A4, A6 7 B4, B6 A3, A5 8 B3, B5 A2, A6 9 B2, B6 A1, A5 Pode ser observado que nesta metodologia o programa é capaz de tratar diversos eventos num mesmo ciclo de varredura do CLP, o que consiste numa característica importante da mesma. Note por exemplo que com o término de operação das máquinas M3 e M5 (eventos B3 e B5) no ciclo de número 4, o CLP trata os respectivos eventos não controláveis e ainda atua nas saídas de forma a iniciar a operação das máquinas M2 e M6 (eventos A2 e A6). Esta característica de tratar mais eventos por ciclo de varredura torna o sistema mais rápido e consegue responder e tratar os eventos assim que ocorreram na planta. Neste capítulo foi estudada a proposta de Cruz (2011), que trata vários eventos no mesmo ciclo de varredura. Esta implementação foi feita na linguagem Ladder Diagram que é muito utilizada nas empresas. A seguir será apresentada a proposta de Vieira (2007), que propõe uma implementação em linguagem de alto, a qual apresenta vantagens de desenvolvimento e manutenção.

59 58 5 METODOLOGIA DE IMPLEMENTAÇÃO EM SFC (VIEIRA, 2007) Neste capítulo será apresentado o método proposto por Vieira (2007) para a implementação da arquitetura de controle supervisório definida por Queiroz e Cury (2000) em Controladores Lógicos Programáveis (CLPs). Tal método é utilizado como uma das principais referências para o desenvolvimento deste trabalho uma vez que apresenta características importantes como o uso de uma linguagem de alto nível, o que resulta em um programa modular e estruturado, além de resultar em programas que estão em conformidade com a norma internacional IEC PROPOSTA DE IMPLEMENTAÇÃO A implementação de VIEIRA (2007) é feita em linguagem Sequential Function Chart, SFC. Nesta arquitetura além dos níveis Supervisores Modulares e Sistema Produto existe o nível Procedimentos Operacionais. Este nível permite tratar de forma consistente os aspectos de implementação denominados em Vieira (2007) como causalidade, sinais e eventos, detalhamento da abstração. O método de implementação consiste em converter sistematicamente os conjuntos dos supervisores e o conjunto de autômatos da representação por sistema produto em conjuntos de Sequential Function Charts. O programa é então estruturado em uma rotina principal, chamada Main Program, e diversos Functions (FCs) e Functions Blocks (FBs). O program main implementa seis modos de operação distintos: Software Initialization (SI); Physical System Initialization (PSI); Manual (Man); Supervised (Sup); Emergency (Emg) e Idle (passos init e PSIted). Tais modos são estabelecidos em conformidade com o passo ativo do SFC apresentado na Figura 5.1. No modo Software Initialization (SI) (obtido quando o passo SI está ativo) a ação action_si é executada apenas uma vez ao ocorrer a ativação do passo SI. Nesta ação todas as variáveis têm seus valores devidamente inicializados, assim como, todos os SFCs que implementam os supervisores, módulos do sistema produto e procedimentos operacionais são inicializados. No modo Physical System Initialization (PSI) é possível conduzir o sistema a ser controlado ao seu estado inicial.

60 59 Figura Programa Main (VIEIRA, 2007) No modo Software Initialization (SI) (obtido quando o passo SI está ativo) a ação action_si é executada apenas uma vez ao ocorrer a ativação do passo SI. Nesta ação todas as variáveis têm seus valores devidamente inicializados, assim como, todos os SFCs que implementam os supervisores, módulos do sistema produto e procedimentos operacionais são inicializados. No modo Physical System Initialization (PSI) é possível conduzir o sistema a ser controlado ao seu estado inicial. No modo Manual (Man) é o operador quem define a habilitação dos eventos controláveis. Isto permite que o sistema seja conduzido através de uma sequência específica de eventos. Como segurança, a ação de controle dos supervisores é apresentada ao operador para que ele possa decidir adequadamente qual evento controlável deve ser habilitado. O sistema pode evoluir para o modo Supervised desde que nenhuma das especificações de controle tenha sido violada pela ação definida pelo operador.

61 60 No modo Emergency (Emg) todas as atividades são suspensas e são executados os procedimentos de emergência pré-estabelecidos. No modo Supervised (Sup) são os supervisores que controlam o sistema, estabelecendo a desabilitação dos eventos controláveis. A ação action_sup é constituída por três estruturas, os FBs MS, PS, OP, os quais são executados conforme ilustrado na Figura 5.2. O primeiro a ser chamado é o FC MS, o qual realiza a chamada sequencial de todos os FBs que implementam os "m" supervisores modulares locais SRj, j J = {A, B,..., m} (SRA, SRB,...). Em seguida, estabelece a desabilitação de eventos controláveis. O segundo a ser chamado é o FC PS, que realiza a chamada sequencial de todos os FBs que implementam os modelos da representação por sistema produto constituída por "n" subsistemas G i, i I onde I = {1, 2,..., n}. A chamada a um determinado subsistema G i só ocorre se o tratamento de eventos deste subsistema não está suspenso por já ter sido realizado o tratamento de eventos de algum outro subsistema que compartilha célula de controle com o sistema em questão. Esta ação é realizada pelo FC dgi. Conforme definido em (VIEIRA, 2007), uma célula de controle é constituída por um supervisor e pelos subsistemas coordenados por ele. Figura Ordem de chamada de blocos Para priorizar o tratamento dos eventos não controláveis sobre o tratamento dos eventos controláveis, o FC PS é chamado duas vezes consecutivas. Na primeira vez, quando a variável CED = 1, são tratados apenas os eventos não controláveis. Na segunda vez, quando CED = 0, são tratados os eventos controláveis. Por fim é chamado o FC OP, que chama todos os FBs dos procedimentos operacionais. Nesta metodologia, quando ocorre o tratamento de um evento de um dado subsistema, impede-se o tratamento de eventos de todos os subsistemas que definem alguma

62 61 célula de controle com o subsistema em questão. É possível, contudo, o tratamento de eventos de subsistemas que não compartilham qualquer célula de controle com o subsistema em questão. 5.2 REPRESENTAÇÃO EM SFC Nesta seção será mostrado como converter os autômatos da representação por sistema produto e dos supervisores em SFCs correspondentes. Será também mostrado como cada function MS, PS e OP é implementado Implementação do FC PS O FC PS chama os FCs dgi e os FBs G i. Cada autômato da representação por sistema produto constituída por "n" subsistemas G i será sistematicamente convertido em um SFC correspondente. Para implementar os FCs dgi é preciso identificar quais plantas compartilham células de controle. Na Figura 5.3 mostra-se um exemplo de supervisores reduzidos. Estes são os supervisores da linha de transferência industrial ilustrada na Figura 2.4 da seção Figura Supervisores reduzidos Na Tabela 5.1 estão relacionados os supervisores com os eventos e plantas coordenados por estes supervisores do exemplo. Nesta tabela verifica-se que o subsistema G1 compartilha a célula de controle apenas com o subsistema G2. Já este último compartilha a célula de controle com G1, G4 e G5. As células de controle podem ser visualizadas na Figura 2.8. Assim, o tratamento de um evento de G1 não requer a suspensão do tratamento dos eventos de G3, G4, G5 nem do G6, requer somente a suspensão do tratamento do evento de G2. Por outro lado, o tratamento do evento

63 62 de G2 requer a suspensão o tratamento dos eventos de G1, G4 e G5 até que ocorra a atualização do estado ativo de todos os supervisores. Tabela Eventos por célula de controle Supervisor Eventos Planta local SRA A1, B1, A2 G1 G2 SRB A3 B3, A4 G3 G4 SRC B5, A2, A4, B2, B4, A5 G2 G4 G5 SRD A5, B5, A6 G5 G6 Na proposta de Vieira (2007), duas variáveis Booleanas, gievt e gid, com i I = {1, 2,..., n} são usadas para garantir que a cada ciclo de varredura do CLP ocorra o tratamento de, no máximo, um evento de cada célula de controle. A variável gievt torna-se verdadeira, sinalizando que um evento ocorreu na planta Gi correspondente. A variável gid deve assumir valor verdadeiro sempre que ocorrer o tratamento de evento de qualquer subsistema que compartilhe alguma célula de controle com o subsistema Gi em questão. Se a variável gid assume valor verdadeiro então não é realizado o tratamento de eventos no subsistema Gi correspondente. No exemplo em questão, para o subsistema G2 é verificado se g1evt, g2evt, g4evt ou g5evt apresentam valor verdadeiro. Se houver algum valor verdadeiro, significa que algum evento foi tratado em um destes subsistemas e então o valor da variável g2d torna-se verdadeiro, conforme ilustrado na Figura 5.4. No bloco PS, antes de chamar o subsistema G2 é verificado o valor da variável g2d. Caso esta variável esteja com o valor verdadeiro, o subsistema G2 não é chamado, impedindo assim o tratamento de quaisquer eventos no subsistema G2. Figura Bloco FC dg2

64 63 Segundo Vieira (2007), são necessárias três etapas para converter os autômatos dos subsistemas do nível SP nos respectivos SFCs. A primeira etapa consiste em definir as variáveis que serão utilizadas. Além das variáveis gid e gievt citadas anteriormente, é necessário criar uma variável do tipo Booleana CED. A ativação da variável CED suspende o tratamento de qualquer evento controlável. Uma variável do tipo Booleana σ é criada para cada evento σ Σ Gi, i I. Estas variáveis se tornam verdadeiras quando ocorrem os eventos correspondentes. Para cada evento controlável é necessário criar mais duas variáveis Booleanas, σid e cmdσi. Se o evento σi é desabilitado num dado estado de um supervisor, a variável σid torna-se verdadeira. A variável cmdσi se torna verdadeira quando ocorre o evento σi. Esta variável será posteriormente tratada no bloco responsável pelo detalhamento da ocorrência do evento controlável correspondente. Para cada evento não controlável é criada mais uma variável inteira, rspii. Esta variável indica o número de ocorrências deste evento pendentes a serem tratadas. A segunda etapa consiste em fazer a conversão do autômato Gi em um autômato Hi, com i I = {1, 2,..., n}, correspondente que atenda às seguintes regras (VIEIRA, 2007): L(Gi) = L(Hi); Cada estado é associado a um evento, ou seja, se houver mudança de um estado será sempre devido à ocorrência do mesmo evento; Nenhum evento conduz para o estado inicial do autômato; Não poderão existir autolaços, ou seja, quando ocorrer um evento obrigatoriamente haverá mudança de estado. Se o autômato original possuir autolaços, é necessário primeiramente criar outro autômato equivalente sem autolaços. Veja o exemplo na Figura 5.5 Figura 5.5 Autômatos equivalentes a) com autolaço e b) sem autolaço Este procedimento utilizado por Vieira (2007) foi baseado em (CARROLL e LONG, 1989) para converter um autômato de Mealy em um autômato de Moore.

65 64 Considerando que qi são os estados, σi são os eventos Σ Gi,σdummy Σ Gi, Q é o conjunto de estados, Σ é o conjunto de eventos, δ é a função de transição de estados: δ((q, σ2),δ1) = (δgi(q, σ1), σ1). Na Figura 5.6 é apresentado o autômato G2 onde QG2 = {0, 1} e ΣG2 = {A2, B2}. O estado inicial de H2 será q0h2 = (0, σdummy). Na Tabela 5.2 pode ser vista a conversão de G2 em H2. Figura Exemplo de autômato da planta Tabela Conversão Gi Hi G2 δh2( (0, σdummy), A2) (δg2(0, A2), A2) (1, A2); δh2( (1, A2), B2) (δg2(1, B2), B2) (0, B2); δh2( (0, B2), A2) (δg2(0, A2), A2) (1, A2); A Figura 5.7 ilustra o autômato H2 para as plantas G2 mostradas na Figura 5.6. Figura Novo autômato H2 para a planta G2 A terceira etapa consiste na conversão do novo autômato em linguagem SFC. Segundo Vieira (2007), este procedimento foi baseado na conversão de autômatos em Redes de Petri em (CASSANDRAS e LAFORTUNE, 1999). Cada passo do SFC está associado a um estado qi de Hi e cada transição está associada a uma tripla da função de transição de estados (qorig, σ, qdest). O passo inicial é o q0hi = (0, σdummy). Cada transição (xq, xq ) está associada à tripla-ordenada (q, σ, q ). Na Tabela 5.3 mostram-se as transições associadas à tripla-ordenada de H2.

66 65 Tabela 5.3- Transições de H2 (q, σ, q ) (xq, xq ) G2 (0, σdummy), A2, (1, A2) (x0, x1) (1, A2), B2, (0, B2) (x1, x2) (0, B2), A2, (1, A2) (x2, x1) Para ocorrer o disparo de uma transição é necessário que a mesma esteja habilitada (todos os passos imediatamente precedentes estão ativos) e que a condição de transição assuma valor lógico verdadeiro. Esta condição pode ser uma expressão booleana ou uma comparação. Na Figura 5.8 mostra-se o SFC (FB G2) para o subsistema G2. O passo S1 é o passo inicial e equivale ao estado (0, σdummy) do autômato H2 da Figura 5.7. O passo S2 equivale ao estado (1, A2) e o passo S3 equivale ao estado (0, B2) do autômato H2. Para desativar o passo S1 e ativar o passo S2 é necessário que as variáveis a2d e CED sejam falsas. Se a variável a2d for verdadeira, significa que o evento A2 está desabilitado e não pode acontecer. Se CED for verdadeira, significa que não podem ser tratados eventos controláveis. Se o passo S1 está ativo e as duas variáveis forem falsas, o passo S2 é ativado e as variáveis a2 e cmda2 tornam-se verdadeiras, o que significa que o evento A2 ocorreu. A variável g2evt torna-se verdadeira sinalizando o tratamento de um evento do subsistema correspondente. Estando o passo S2 ativo, só poderá ativar o passo S3 se a variável rspi2 for maior que 1, o que significa que existe ao menos uma ocorrência do evento não controlável B2 para ser tratada. Se o passo S3 for ativado, a variável b2 torna-se verdadeira e o valor da variável rspi2 é decrementado em 1. Para ativar novamente o passo S2, é preciso que a2d e CED apresentem novamente valor falso.

67 66 Figura SFC para o subsistema G Implementação dos supervisores, FC MS O FC MS chama os supervisores e estabelece a desabilitação dos eventos controláveis. A implementação dos FBs dos supervisores em SFC é feita em duas etapas. A primeira etapa consiste em definir o mapa de saída (desabilitações dos eventos controláveis) dos supervisores. Para encontrar estas variáveis verificam-se em cada estado de cada supervisor quais eventos serão desabilitados e indicam-se estas desabilitações por meio de varáveis Booleanas, σidsrj, j J = {a, b,..., m}, i I = {1, 2,..., n}. Neste exemplo, para o supervisor SRB (ver Figura 5.3) são criadas as variáveis a3dsrb e a4dsrb, que correspondem à desabilitação do evento A3 (estado 1) e do evento A4 (estado 0), respectivamente, pelo supervisor SRB, conforme mostrado na Tabela 5.4. Tabela 5.4 Eventos desabilitados Supervisor Estado Desabilitações Variáveis SRB (y=3) 0 1 A4 A3 a4dsrb, a3dsrb

68 67 Na segunda etapa é necessário identificar o conjunto de eventos que provocam mudanças de estado em cada supervisor. São utilizadas as variáveis σi, i I = {1, 2,..., n} para cada evento. Por exemplo, para o supervisor SRB são utilizadas as variáveis b3 e a4 criadas anteriormente, conforme ilustrado na Tabela 5.5. Tabela 5.5 Eventos que causam mudança de estado Supervisor Estado Evento Variáveis SRB 0,1 B3 a4, b3 (y=3) 1,0 A4 Assim, o FB do supervisor SRB fica como na Figura 5.9, onde o passo S1 representa o estado 0 do autômato mostrado na Figura 5.3 (a) e o passo S2 corresponde ao estado 1. Deve-se destacar aqui que os autolaços não são implementados, pois não provocam transição de estado no supervisor e, portanto não resultam em alteração de passo do SFC. Figura SFC para o supervisor SRB O FB MS chama os FBs de todos os supervisores (SRA, SRB, SRC e SRD), fazendo as devidas atualizações de estados (se necessário) e, em seguida, com base no valor das variáveis σidsrj, j J = {a, b,..., m}, i I = {1, 2,..., n}, determina o conjunto de eventos desabilitados pela ação conjunta dos supervisores. Por exemplo, na Figura 5.10 ilustra-se que a desabilitação do evento A2 (variável a2d) pode ocorrer no supervisor SRA ou no SRC. Se a variável a2dsra ou a a2dsrc for verdadeira, a variável a2d torna-se verdadeira. Figura Desabilitação de eventos controláveis

69 Implementação do FC OP O FC OP chama os FBs dos procedimentos operacionais, que agem diretamente sobre os subsistemas da planta física. A cada evento controlável é associado um procedimento operacional (VIEIRA, 2007). Os FBs OP evoluem dependendo do estado de sensores e comandos. Com a evolução da planta e consequentemente do FB OP, podem ocorrer eventos não controláveis. Quando ocorre um evento não controlável na planta, no procedimento operacional a variável rspii é incrementada em uma unidade para o sistema poder tratar este evento. A obtenção do SFC do procedimento operacional faz parte do processo de modelagem do sistema. Em Vieira (2007) são apresentadas algumas recomendações para a obtenção deste SFC: 1. Se o SFC representar a geração de um evento controlável, os comandos devem ser convertidos em expressões que possibilitem a mudança de estado. O SFC deve representar as transições do sistema, e a cada mudança de estado o comando deve ser desativado para confirmar que o mesmo foi tratado pelo procedimento operacional; 2. Se o SFC for tratar um evento não controlável, o mesmo deve ter a variável que representa o evento (rspii) incrementada em 1 ; No final do ciclo do procedimento o estado do SFC correspondente deve sempre retornar ao estado inicial. 5.3 CÉLULA DE MANUFATURA No intuito de validar a metodologia proposta em sua tese de doutorado, Vieira (2007) utilizou como estudo de caso uma célula de manufatura existente na Pontifícia Universidade Católica do Paraná (PUCPR). Esta célula é mostrada na Figura 5.11 (a) e é composta por uma mesa rotativa (M0), um sistema de classificação e transporte de peças (M1); um sistema de furação (M2); um sistema de teste (M3); um manipulador robótico (M4) e um dispositivo de alimentação (M5). Uma foto desta célula é apresentada na Figura 5.11 (b). Nesta célula são processados três diferentes tipo de peças, que se diferem nas cores e dimensões. As peças estão armazenadas aleatoriamente no armazém B1. O sistema de alimentação M5 alimenta o sistema de classificação e transporte M1. A peça é colocada na posição B2 onde será medida e selecionada. Se a peça for aceita, a mesma vai para a posição P1 da mesa rotativa M0. Se for descartada, a peça vai para a posição B3. A peça será descartada se suas medidas forem diferentes das estabelecidas ou se a quantidade de peças a serem produzidas for igual à quantidade máxima estipulada para aquele tipo. A mesa rotativa

70 69 M0 gira com a peça aceita para posição P2 onde será submetida ao processo de furação no sistema M2. Depois de furada, a mesa rotativa M0 gira com a peça para a posição P3 para a peça ser testada no sistema M3. Este teste tem como resposta Ta se o teste for aceito e Tb se o teste da furação for rejeitado. Após o teste a mesa rotativa M0 gira para a posição P4. Nesta posição o manipulador robótico M4 retira a peça da mesa e a direciona para um dos armazéns B5, B6 ou B7, dependendo do tipo da peça, ou direciona para o B4 se for rejeitada pelo teste M3. Figura Célula de Manufatura (VIEIRA, 2007) Os autômatos que modelam as máquinas M1, M2, M3, M4 e M5 podem ser vistos na Figura 5.12 e a descrição de cada um dos estados e eventos é apresentada na Tabela 5.6. Sintetizando os supervisores pela abordagem modular local (QUEIROZ, 2004) obtêm-se os supervisores não conflitantes, que após serem reduzidos, são apresentados na Figura Maiores detalhes sobre as especificações podem ser encontrados em (VIEIRA, 2007).

71 Figura RSP para a célula de manufatura (VIEIRA, 2007) 70

72 71 Tabela Semântica de estados e eventos (VIEIRA, 2007) Autômato Estado Evento G0 0 - repouso A0 - iniciar rotação de rotacionando B0 - rotação concluída 0 - repouso T1 - iniciar classificação G1 1 - classificando L1 - classificada e aceita 2 - em pausa M1 - classificada e rejeitada 3 - transportando A1 - iniciar transporte B1 - transportada 0 - repouso A2 - iniciar furação G2 1 furando B2 - furada com sucesso 2 - em pane L2 - pane na furação M2 - sistema de furação reparado G3 0 repouso A3 - iniciar procedimento de teste TA 1 - testando T3 - iniciar procedimento de teste TB B3 - teste concluído G4 0 - repouso A4 - iniciar retirada e armazenagem 1 - retirando da mesa B4 - retirada da mesa 2 - armazenando M4 armazenada G5 0 - repouso A5 - iniciar alimentação da célula 1 - alimentando a célula B5 - célula alimentada 2 - sem peças para alimentação L5 - armazém B1 vazio M5 - armazém B1 recarregado Bloco MS O bloco MS chama os blocos dos supervisores sequencialmente, como na Figura O bloco sla corresponde ao Sa da Figura 5.13, o slb1 ao Sb1. A ordem em que os supervisores são chamados é irrelevante. Cada bloco de supervisor determina quais são os eventos desabilitados em cada estado daquele supervisor. A título de ilustração, na Figura 5.15 mostra-se o FB para o supervisor slb1. Se o supervisor transita para o passo S2, as variáveis a0dslb1 e a1dslb1 tornam-se verdadeiras. No final do bloco MS as variáveis aidsrj são usadas de modo a determinar o conjunto de eventos que serão desabilitados pela ação conjunta dos supervisores modulares locais. Por exemplo, na Figura 5.16 se a variável a1dslb1 ou a variável a1dslc1 estiver verdadeira, a variável a1d torna-se verdadeira, levando à desabilitação do evento A1.

73 Figura Supervisores reduzidos para a célula de manufatura (VIEIRA, 2007) 72

74 73 Figura Parte do Bloco MS Figura FB para o supervisor slb1 Figura Desabilitação do evento A1

75 Bloco PS No bloco PS é chamado primeiramente o bloco dgi, que verifica se foi tratado algum evento em outro subsistema que divide a mesma célula de controle. O bloco Gi só poderá ser chamado se o tratamento de eventos deste subsistema não está suspenso, ou seja, a variável gid tem que estar com o valor falso. No caso da Figura 5.17 o bloco G0 só será chamado se g0d for falso. A ordem de chamada dos FBs (G1, G2,...) prioriza o tratamento de eventos. Figura 5.17 Parte do bloco PS, chamada do dg0 e G0 No bloco dgi é verificado se houve evolução em algum subsistema que compartilha célula de controle com o subsistema correspondente. Para isto são utilizadas as variáveis gievt. Na Figura 5.18 pode ver visto que se g0evt, g1evt, g2evt, g3evt ou g4evt for verdadeiro então a variável g0d torna-se verdadeira. Figura 5.18 Bloco FC dg0 O tratamento dos eventos controláveis não desabilitados é feito nos blocos Gi que não foram suspensos. Assim, se no passo S1 do bloco G0 o evento a 0 não estiver desabilitado

76 75 (a variável a0d for falsa), e ainda se a variável CED for falsa, então o passo S2 fica ativo (ver Figura 5.19) e as variáveis a0, cmda0 e g0evt tornam-se verdadeiras, como explicado anteriormente. Se no passo S2 a variável rspi0 for maior que 0 o passo S3 fica ativo e é feita a sinalização de ocorrência de eventos não controláveis. A variável rspi0 é decrementanda e as variáveis b0 e g0evt tornam-se verdadeiras. Figura 5.19 SFC G Bloco OP O bloco OP chama sequencialmente os blocos dos procedimentos operacionais. Estes blocos controlam as atividades a serem realizadas pelos subsistemas que compõem a planta física. A cada evento controlável deve ser associado um comando. A execução do processo de controle do sistema pode também resultar em ocorrência de eventos não controláveis. Parte do bloco OP é ilustrada na Figura 5.20.

77 76 Figura Parte do bloco OP 5.4 CONCLUSÃO AO CAPÍTULO Neste capítulo apresentou-se a proposta de Viera (2007) que utilizou uma linguagem de alto nível, denominada Sequential Function Chart, SFC em sua implementação. Porém em sua proposta ocorre somente um evento por célula de controle a cada ciclo de varredura. No capítulo que segue introduz-se uma metodologia de implementação em SFC semelhante à de Vieira (2007), mas que possibilita o tratamento de mais eventos por ciclo de varredura.

78 77 6 IMPLEMENTAÇÃO EM SFC COM TRATAMENTO DE MULTIPLOS EVENTOS NÃO CONTROLÁVEIS Nesta seção apresenta-se uma metodologia para a implementação da arquitetura de controle supervisório em Controladores Lógicos Programáveis (CLPs) que reúne os aspectos positivos das metodologias apresentadas anteriormente, como o tratamento de todos os eventos não controláveis, a utilização dos procedimentos operacionais. Um dos objetivos desta proposta é possibilitar o tratamento de diversos eventos associados a um único supervisor, podendo ocorrer vários eventos para serem atualizados no mesmo supervisor no mesmo ciclo de varredura. Assim como em (VIEIRA, 2007) e em (CRUZ, 2011), para a síntese dos supervisores foi utilizada a abordagem modular local proposta por Queiroz (2004). Esta metodologia resulta em um programa estruturado, modularizado e com a capacidade de tratar múltiplos eventos a cada ciclo de varredura do CLP. Como em (VIEIRA, 2007) o programa do CLP é estruturado em diversos blocos, cada qual com uma função específica. Entretanto, no intuito de utilizar a linguagem mais adequada a cada módulo, na presente metodologia são utilizadas três diferentes linguagens para implementação: Sequential Function Chart SFC, Ladder Diagram e Structured Text. Um dos objetivos desta metodologia consiste em obter um programa capaz de processar o maior número de eventos por ciclo de varredura do CLP. Para isto é feita uma divisão no tratamento dos eventos de acordo com a sua controlabilidade, como na metodologia DECON9 (LEAL et al., 2012). Em especial, deseja-se que todos os eventos não controláveis que aconteceram na planta sejam processados tão logo tenham ocorrido, mantendo assim o programa do CLP atualizado em relação ao estado da planta. Nesta nova proposta, conforme ilustrado na Figura 6.1, o bloco Action_sup tem uma sequência de ações e chamadas de outros blocos priorizando o tratamento de eventos não controláveis. Esta sequência dentro do Action_sup é feita dentro de um ciclo de varredura e é realizada em todo ciclo. Inicialmente faz-se CED = 1 para dar prioridade ao tratamento dos eventos não controláveis. O bloco PS é chamado, que por sua vez chama os Gi, i I = {1, 2,..., n}, para o processamento dos eventos não controláveis do sistema produto. Em seguida é chamado o bloco MS, que chama os supervisores (SRA, SRB,...) para atualização dos estados dos mesmos em função dos eventos não controláveis já processados nos blocos Gi. Depois, os supervisores são chamados novamente para atualizar seus estados

79 78 em função dos eventos controláveis gerados no ciclo anterior. Neste ponto o bloco MS já faz a atualização dos eventos não controláveis e controláveis, não sendo necessário chamá-lo novamente. No bloco MS é feita a desabilitação dos eventos controláveis e será abordado com mais detalhes na seção A implementação de mais de um evento não controlável no mesmo supervisor será apresentada com detalhes na seção Figura Proposta de organização para a chamada de blocos O próximo passo consiste em fazer CED = 0 e chamar o bloco PS para gerar os eventos controláveis do sistema produto. O bloco PS faz a verificação nos blocos dgi e em seguida chama os Gi. Os blocos dgi verificam se houve algum tratamento de evento que pertence à mesma célula de controle. O bloco Gi subsequente só será chamado se não houver esta

80 79 evolução, esta condição será abordada na seção Os blocos Gi geram os eventos controláveis do sistema produto que não foram desabilitados pelos supervisores. Por fim é chamado o bloco OP que chama os procedimentos operacionais, Op1, Op2,..., O bloco OP será abordado na seção Na proposta de Vieira (2007) o tratamento de um evento, tanto controlável quanto não controlável, de um determinado subsistema resulta na suspensão de qualquer evento de todo subsistema que compartilha célula de controle com o subsistema em questão. Isto é necessário para garantir que a cada ciclo de varredura do CLP cada supervisor tenha que ter a atualização de estado devido à ocorrência de no máximo um único evento. Nesta abordagem esta restrição ao tratamento de eventos é flexibilizada. Apenas a geração de eventos controláveis é que requer a suspensão do tratamento de eventos controláveis dos subsistemas que compartilham uma célula de controle. O tratamento de eventos não controláveis não resulta na suspensão do tratamento de eventos de qualquer subsistema, inclusive do próprio subsistema que teve evento tratado. 6.1 CHAMADA DOS BLOCOS Parte do bloco Action_sup pode ser vista na Figura 6.2. Como explicado acima, segue a ordem do programa. Primeiro faz-se CED = 1, chama-se o bloco PS, que chama os Gi, i I = {1, 2,..., n}. O bloco MS é chamado, que chama os supervisores. Torna-se CED = 0 e chama novamente o bloco PS. Neste ponto são zeradas então as variáveis gid e gievt, que têm por objetivo identificar se algum evento controlável pertencente à mesma célula de controle em que foi gerado. No fim é chamado o bloco OP, que chama os procedimentos operacionais. A seguir será descrito com detalhes cada bloco apresentado na Figura 6.2. A implementação foi feita na mesma célula de manufatura utilizada por Vieira (2007), anteriormente ilustrada na Figura Bloco PS O bloco PS é o responsável pela geração e processamento dos eventos nos blocos do sistema produto. Quando a variável CED = 1, este bloco simplesmente chama os Gi para processar os eventos não controláveis. Quando CED = 0, primeiramente chama os dgi para verificar se foi gerado algum evento controlável de qualquer subsistema que compartilha célula de controle com o subsistema em questão. Posteriormente os Gi são chamados para gerar os eventos controláveis. Este bloco foi escrito em Structured Text para facilitar as verificações de célula de controle e as chamadas dos blocos que são realizadas somente

81 80 quando necessário. Enquanto na proposta de Vieira (2007) os dgi são funções chamadas no PS, nesta proposta o código dos dgi foi incorporado diretamente ao PS, eliminando a função dgi. Com isto há uma diminuição do tamanho do código final. Parte do programa do bloco PS pode ser visto na Figura 6.3. Figura 6.2 Parte do bloco Action_sup O segmento de código originalmente implementado na função dgi só é executado quando os eventos controláveis puderem ser gerados. No caso da primeira chamada deste bloco, quando CED = 1, não serão verificados os gievt s. Somente na segunda chamada, com CED = 0 ( IF CED = false THEN ), que os gievt s serão analisados. No exemplo da Figura 6.3, se qualquer uma das variáveis g0evt ou g1evt ou g2evt ou g3evt for verdadeira, g0d tornase verdadeira, ( g0d := true ), caso contrário torna-se falso ( g0d := false ).

82 81 Figura 6.3 Parte do bloco PS Após fazer a verificação dos gievt s, quando necessário, é feita a chamada do subsistema Gi correspondente. Para evitar chamadas desnecessárias são verificadas algumas condições adicionais antes de chamar o FB Gi. Com estas verificações, apenas os blocos que possuem eventos aptos a serem tratados serão chamados, tornando o ciclo de varredura mais ágil e rápido. No caso do G0 a expressão IF (g0d = false AND CED = false) OR rspb0 > 0 THEN é usada no intuito de verificar três condições: se estão sendo tratados os eventos controláveis (CED é falso); e se nenhum outro evento controlável de alguma célula de controle compartilhada por G0 foi tratado (g0d é falso); ou se existe alguma ocorrência do evento b0 pendente para ser tratada (rspb0 for maior que zero). Se as duas primeiras forem falsas ou se a terceira for verdadeira, é então chamado o bloco FB G0, o que é feito pelo comando fb40.db40 (INIT_SQ := FALSE); conforme mostrado na Figura 6.3. O evento controlável σ está apto a ser tratado se sua ocorrência não está desabilitada (se a variável σd correspondente assume valor falso) e se o tratamento de eventos não controláveis não está suspenso (se a variável CED assume valor falso). O evento não controlável σ u está apto a ser tratado se existe alguma ocorrência deste evento pendente para ser tratada (se a variável rspσ correspondente assume valor maior do que zero).

83 82 Na proposta de Vieira (2007), mesmo que um determinado subsistema não tenha qualquer evento apto a ser tratado o Function Block correspondente é chamado para atualização. Isto resulta em tempo de processamento desperdiçado. Nesta proposta a implementação é otimizada reduzindo o tempo de processamento do ciclo de varredura do CLP realizando a chamada a um Function Block que implementa o módulo do sistema produto apenas quando há evento apto a ser processado. Na Figura 6.4 mostra-se a implementação em SFC do bloco G0. Figura Implementação do bloco G0 Na Figura 6.4 o passo S1 é o passo inicial. Neste passo, quando as variáveis a0d e CED são falsas, ocorre o disparo da transição T1 desativando o passo S1 e ativando o passo S2, onde as variáveis a0, cmda0 e g0evt tornam-se verdadeiras. A variável a0 torna-se verdadeira no intuito de indicar a geração do evento controlável A0. A variável cmda0 é utilizada no procedimento operacional, e será abordada na seção A variável g0evt indica que um evento controlável ocorreu em G0, e que não poderá ser gerado outro evento controlável de qualquer célula de controle compartilhada por G0. Em um próximo ciclo de varredura, quando a variável rspb0 for maior que zero, ocorrerá a evolução para o passo S3 e no intuito de sinalizar a ocorrência do evento não controlável B0, a variável b0 torna-se verdadeira e a variável rspb0 será decrementada em 1. Para ativar novamente o passo S2, é

84 83 necessário que as variáveis CED e a0d assumam valor falso, ou seja, que seja possível tratar eventos controláveis e que o evento controlável a0 não esteja desabilitado por qualquer supervisor. Na proposta de Vieira (2007), no passo S2, além das variáveis já mencionadas, a variável g0evt torna-se verdadeira. Isto ocorre pois, na proposta de Vieira (2007), se ocorreu algum evento não controlável b0, não poderá ocorrer qualquer outro evento (controlável ou não) que pertença à qualquer célula de controle compartilhada por G0. Nesta proposta este controle é feito somente com eventos controláveis, e os eventos não controláveis são todos tratados Bloco MS O bloco MS é responsável pela chamada dos supervisores e também por estabelecer as desabilitações de eventos controláveis. Este bloco foi escrito em Structured Text a fim de facilitar a programação e possibilitar a atualização de vários eventos no mesmo ciclo de varredura, sendo atualizados primeiramente os eventos não controláveis e depois os eventos controláveis. Foi possível também, através desta programação, tratar o problema de perda de informação e o efeito avalanche, que será visto na seção No bloco MS são chamados os supervisores e primeiramente são feitas atualizações de estados nos supervisores somente devido aos eventos não controláveis (ver Figura 6.5). Posteriormente os supervisores são chamados novamente para atualizar os estados em decorrência dos eventos controláveis (ver Figura 6.6). A fim de aumentar a velocidade de processamento do programa, são chamados somente os supervisores que podem sofrer mudança de estado. Na Figura 6.5 mostra-se parte do programa da chamada dos supervisores no bloco MS atualizando os eventos não controláveis. Neste caso o supervisor slb3 só será chamado se os eventos não controláveis B0 ou B3 tiverem ocorrido, ou seja, as variáveis b0 ou b3 estiverem verdadeiras. Figura 6.5 Chamada dos supervisores com eventos não controláveis Na Figura 6.6 mostra-se parte do programa do bloco MS onde a chamada do supervisor slb3 só ocorre se as variáveis a0, a3 ou t3 forem verdadeiras, ou seja, se estes eventos controláveis ocorreram.

85 84 Figura Chamada dos supervisores com eventos controláveis Nesta proposta é possível ocorrer mais de um evento por supervisor. Assim, é necessário atualizar todos os eventos em cada supervisor. Esta solução será mostrada em detalhes na seção Os supervisores são programados em SFC, seguindo a proposta de Vieira (2007). Na Figura 6.7 apresenta-se a implementação do supervisor slb2, onde no estado S2 as variáveis a0dslb2 e a2dslb2 tornam-se verdadeiras, o que provocará a desabilitação dos eventos A0 e A2. Figura Supervisor slb2 Após todos os supervisores terem sido chamados e atualizados com as devidas transições de estado decorrentes dos eventos, é feita a atualização das desabilitações no intuito de determinar quais eventos controláveis devem ser desabilitados. Na Figura 6.8 mostra-se um trecho de código do bloco MS referente às desabilitações de eventos controláveis. Neste exemplo, se a variável a2dslb2 estiver verdadeira, então a variável a2d se torna verdadeira, o que significa que o evento A2 está desabilitado. Neste caso, outros supervisores também podem desabilitar o evento A2. A variável a2dslb2 é tratada no supervisor slb2, a variável

86 85 a2dslc1 no supervisor slc1 e a variável a2dslc2 é tratada no supervisor slc2. Todos estes supervisores podem desabilitar o evento A2. Figura 6.9. Figura Atualização das desabilitações No final do bloco MS são zeradas todas as variáveis de eventos σi como ilustrado na Figura 6.9- Parte o bloco MS, eventos zerados Bloco OP O bloco FC OP é o bloco que faz a chamada dos procedimentos operacionais, Op1, Op2,..., Oph, que agem diretamente sobre os subsistemas da planta física. Ao iniciar o FB Opl, l L = {1, 2,..., h}, caso a variável cmdσi esteja com o valor verdadeiro, o bloco inicia a troca informações com a planta. Dependendo do sistema que está sendo monitorado, o FB Opl passa por vários passos. Quando o FB chega ao passo que significa que a planta física acabou o processo, a variável respσi é incrementanda em 1. Na Figura 6.10 é mostrado o FB a0, que trata da mesa rotativa da Figura Quando a variável cmda0 assume valor verdadeiro, muda para o passo S2 e esta variável torna-se falsa, iniciando então a rotação na mesa. Quando o passo S4 é ativado, significa que a planta já realizou todos os procedimentos e a mesa já está em uma nova posição. Nesta situação a variável rspb0 é incrementada em 1 e o bloco volta para o passo inicial, S1.

87 86 Figura FB OP a0 6.2 SOLUÇÃO DE PROBLEMAS DE IMPLEMENTAÇÃO Nesta seção serão apresentadas soluções para alguns problemas de implementação Causalidade Conforme visto na Figura 3.2, os blocos de sistema produto, procedimentos operacionais e o sistema a ser controlado, compõem a planta Ramadge - Wonham. Segundo a TCS, os eventos são espontaneamente gerados na planta e apenas desabilitados pelos supervisores. Sendo assim os supervisores continuam somente com a função de desabilitar eventos. Com esta forma de implementação é possível utilizar os supervisores reduzidos, reduzindo o número de estados. Para a célula de manufatura utilizada neste trabalho e por Vieira (2007), pode ser visto na Tabela 6.1 a diferença do número de estados e transições entre os supervisores não reduzidos e os reduzidos, utilizando tanto a abordagem monolítica como a abordagem modular local (VIEIRA, 2007).

88 87 Tabela 6.1 No. de estados e de transições do conjunto de supervisores (VIEIRA, 2007) Efeito avalanche e perda de informação Os supervisores são implementados na linguagem SFC como visto na Figura 6.7. Existem duas formas de configurar o disparo de transições nos SFCs no SIMATIC da Siemens. No Block Settings existe a opção de Skip steps. Se esta opção for verdadeira o programa dispara todas as transições habilitadas em uma mesma chamada do SFC, sem executar as ações associadas aos passos que são ativados e desativados ao longo desta chamada. No autômato da Figura 6.11, se o evento a aconteceu, o programa vai do estado 1 para o estado 7, ocorrendo o efeito avalanche. Figura Autômato susceptível ao efeito avalanche Na Figura 6.12 temos o SFC da Figura Se ocorrer o efeito avalanche neste exemplo, as ações associadas aos passos S2 e S4 não são executadas.

89 88 Figura SFC susceptível ao efeito avalanche Outra situação em que pode haver perda de informação é se os eventos b e c aconteceram, o programa vai pular do passo S1 para o passo S6 no mesmo ciclo sem executar as ações associadas ao passo S3. Com o Skip steps falso, o programa evolui apenas um passo por chamada do FB onde está implementado o supervisor em SFC. Por exemplo, na Figura 6.12, se ocorrer o evento a encontrando-se o supervisor no passo S1, este transita para o passo S2, não ocorrendo o efeito avalanche. Entretanto, no uso do skip steps falso existe o risco de perda da informação sobre a ocorrência de eventos. Por exemplo, se em um mesmo ciclo de varredura ocorrer os eventos b, c e d, o supervisor transita do passo S1 para o passo S3, podendo perder a informação de ocorrência dos eventos c e d. Além disso, esta opção permite apenas o tratamento de um evento a cada chamada do bloco. Assim, se o bloco é chamado uma vez por ciclo de varredura, o programa trata apenas um evento por ciclo. A solução para este problema, adotada neste trabalho, consiste em verificar quantos eventos aconteceram e, dentro do programa estruturado do bloco MS, o supervisor é chamado tantas vezes quanto necessárias para tratar todos os eventos que ocorreram na planta. Para isto são criados grupos de variáveis temporárias dentro do MS. Na Figura 6.13 é apresentada parte do programa referente ao autômato da Figura 6.11 escrito em Structured Text. O supervisor slb3 pode ser chamado até quatro vezes, ou seja, pode ocorrer

90 89 no mesmo ciclo de varredura os eventos a, b, c e d. Primeiramente é verificado se o evento a ocorreu, IF copa THEN. Se copa for verdadeiro significa que o evento a ocorreu e tornamse falsos os eventos b, c e d deixando apenas o evento a verdadeiro e o supervisor slb3 é chamado. Isto é feito para evitar o efeito avalanche. Se o evento a não ocorreu, copa for falso, não chama o supervisor slb3. Em seguida é feita esta verificação para os outros eventos b, c e d e para quantos eventos ocorreram. Figura Programa MS

91 Sincronização inexata A satisfação da propriedade 1 definida em Balemi (1992, apud FABIAN e HELLGREN 1998) garante que o problema da sincronização inexata, apresentada na seção 3.4.4, não ocorra Problema da escolha No intuito de solucionar o problema da escolha, neste trabalho adota-se a solução proposta por Cruz (2011). No exemplo utilizado na Figura 2.4 o problema da escolha surge quando as máquinas M2 e M4 podem iniciar suas operações, ou seja, os eventos A2 e A4 não estão desabilitados. Este caso pode ser visto no supervisor reduzido SRC da Figura Neste supervisor quando no estado 0, podem ocorrer os eventos A2 e A4. Este problema é tratado antes de chamar o bloco PS com o CED = 0, ou seja, quando irá tratar os eventos controláveis. Para identificar se o problema da escolha existe, Cruz (2011) fez a análise em cada supervisor local isoladamente, nos supervisores não reduzidos e nos reduzidos. Leal et al. (2012) afirmam que um problema de escolha pode existir em algum supervisor local, mas não se apresentar na ação conjunta dos supervisores. Assim, a solução adotada por Cruz (2011) é suficiente, mas pode não ser necessária para evitar o problema da escolha. No caso de um problema da escolha ser identificado em um supervisor local, é acrescentado um trecho de código a fim de solucionar este problema, mas o mesmo só será chamado caso o problema se manifeste na ação conjunta dos supervisores. Para obter uma solução necessária e suficiente seria preciso avaliar o problema da escolha sobre o supervisor monolítico (composição dos supervisores modulares). Segundo Dietrich et al. (2002) para garantir que a implementação do supervisor tenha um comportamento não bloqueante, é necessário atender simultaneamente um conjunto de propriedades (VIEIRA, 2007). Na Figura 6.14 apresenta-se o trecho de programa do bloco Action_sup onde é feito a chamada do bloco que faz o tratamento da escolha, o TRATA_ESCOLHA. Esta parte do código só é implementada quando existe o problema da escolha, ou seja, quando dois eventos estão aptos a serem gerados, porém transitam para estados diferentes, e somente um poderá transitar. É utilizada uma variável INTERCALA_A2_A4, que a cada ciclo de varredura do CLP assume de forma alternada os valores 0 e 1. O bloco que trata a escolha só é chamado quando os eventos A2 e A4 não estão desabilitados, ou seja, quando as variáveis a2d e a4d estão com o valor falso.

92 91 Figura Chamada do TRATA_ESCOLHA no bloco Action_sup A escolha de qual evento será gerado dependerá da variável INTERCALA_A2_A4, que desabilitará um dos eventos de forma aleatória, como mostra na Figura Se a variável INTERCALA_A2_A4 for igual a 1, o evento A2 será desabilitado por intermédio da variável da2, e se a variável INTERCALA_A2_A4 for igual a zero o evento A4 será desabilitado por intermédio da variável da CONCLUSÃO DO CAPÍTULO Figura Bloco de escolha Neste capítulo foi apresentada uma proposta de implementação de controle supervisório em CLPs usando as linguagens Sequential Function Charts (SFC), Structured Text e Ladder Diagram. Este trabalho tem como objetivo ter uma implementação em alto nível, utilizando a linguagem SFC, como a proposta de Vieira (2007). Outro objetivo é ter uma implementação mais dinâmica, com capacidade de processar vários eventos no mesmo ciclo de varredura e ser capaz de tratar todos os eventos não controláveis que ocorreram na planta o mais rápido possível, como na proposta de Cruz (2011). Além disso, foi apresentada uma solução para alguns problemas de implementação identificados em outros trabalhos. Esta metodologia foi testada e comparada com as duas propostas anteriores e foram verificadas as vantagens e desvantagens. Esta comparação será apresentada no capítulo 7.

93 92 7 COMPARAÇÕES ENTRE AS METODOLOGIAS Neste capítulo serão feitas comparações entre as três metodologias de implementação apresentadas anteriormente. Para validar a proposta deste trabalho as três metodologias foram implementadas e foram feitos vários testes e comparações com a nova proposta. No caso do problema da célula utilizada por Vieira (2007), os testes foram feitos na prática sobre a célula experimental existente na PUCPR, que utiliza o CLP da Família Siemens S7-300, com a CPU Os testes foram adicionalmente simulados em um CLP Siemens S7-300 com uma CPU 315F-2 PN/DP e também no ambiente de programação e simulação SIMATIC instalado em um computador. A comparação com o exemplo utilizado por Cruz (2011) foram feitas apenas com base em simulações em computador no ambiente SIMATIC Siemens, uma vez que no próprio trabalho de Cruz (2011) foram apresentados apenas resultados de simulação. Os três testes mostrados a seguir são comparações entre a nova proposta e a proposta de Vieira (2007). Para começar a contar o tempo no bloco OB1 utiliza a função TIME_TCK. Se é a primeira vez que o bloco OB1 esta sendo executado, zera a variável NCiclo que conta o número dos ciclos como podem ser vistos na Figura 7.1. Figura TIME_TCK e início do NCiclo No final do bloco OB1 a variável NCiclo é incrementada como visto na Figura 7.2.

94 93 Figura Incremento de NCiclo 7.1 PRIMEIRO TESTE DIFERENÇA ENTRE EVENTOS Neste teste foi monitorada a ocorrência do evento controlável A5, a ocorrência do evento não controlável correspondente B5 e a ocorrência do próximo evento controlável T1. Estes eventos ocorrem no início do ciclo de produção da planta, no dispositivo de alimentação (A5 e B5) e no início da classificação (T1). Cada vez que um evento destes ocorre, é chamado o FB Registra3 como mostra na Figura 7.3 parte o bloco G5 quando ocorre o evento A5. Figura Chamada do Registra3 no G5 Este Function Block cria uma tabela com número do ciclo e o tempo que ocorreu como visto na Figura 7.4.

95 94 Figura Function Block Registra3 Este teste foi executado 5 vezes em cada uma das plataformas (célula, CLP e computador), e sua avaliação foi feita através do cálculo da média da diferença dos ciclos e dos tempos. Na Tabela 7.1 apresenta-se o resultado do teste realizado na planta da PUCPR. Na primeira coluna, N.Prop. refere-se ao resultado da proposta deste trabalho. Na segunda coluna é o resultado do trabalho de Vieira (2007). Pode-se verificar que a quantidade de ciclos que ocorreu entre o evento controlável A5 e o evento não controlável B5 foi maior na nova proposta que na proposta de Vieira (2007). Tabela Primeiro teste na planta N.Prop. Vieira (2007) Diferença ciclo A5/B5 592,6 310,6 Diferença ciclo B5/T1 0 1 Diferença ciclo A5/T1 592,6 311,6 Diferença Tempo A5/B ms 3844 ms Diferença Tempo B5/T ms Diferença Tempo A5/T ms 3856 ms

96 95 Na nova proposta o programa que implementa a arquitetura de controle supervisório foi atualizado aproximadamente o dobro do número de vezes que na proposta de Vieira (2007), ou seja, cada ciclo de atualização do referido programa é executado na metade do tempo requerido na proposta de Vieira (2007). Pode-se afirmar assim que o sistema de controle responde de forma mais rápida às mudanças ocorridas no sistema a controlar, pois o tempo de processamento é reduzido. Esta redução no tempo de reação se deve basicamente ao fato de que os Function Blocks onde estão implementados os módulos do sistema produto e os supervisores só são chamados para atualização se houver algo de relevante a ser realizado pelos mesmos, isto é, se há a possibilidade de tratamento de eventos pelo sistema produto ou se há evento tratado que possa causar a transição de estado dos supervisores. Para a análise do tempo de reação em cada uma das propostas comparou-se o tempo transcorrido entre o início da operação de alimentação (ocorrência do evento A5) e o término desta operação (evento B5), valores que são apresentados na linha Diferença Tempo A5/B5 da Tabela 7.1. Com base nesta análise pode-se afirmar que na nossa proposta houve uma redução de 1,25% no tempo de reação, quando comparado com a proposta de Vieira. Na linha Diferença ciclo B5/T1 da Tabela 7.1 pode ser visto também que na nova proposta os eventos B5 e T1 foram tratados no mesmo ciclo de varredura, enquanto que na proposta de Vieira (2007) foram necessários dois ciclos para tratar os dois eventos. Isto ocorre uma vez que estes eventos pertencem aos subsistemas G5 e G1, respectivamente, que compartilham uma célula de controle com o supervisor SD. Em Vieira (2007) não é possível tratar tais eventos no mesmo ciclo de varredura do CLP, já na nova proposta esta restrição é eliminada. Este fato também determina a redução no tempo de resposta do sistema de controle, pois uma ação de controle devida a uma alteração no estado do sistema a controlar é executada em um menor tempo. Na linha Diferença Tempo B5/T1 da Tabela 7.1 pode-se observar que, em média, houve uma diminuição de 12 ms neste tempo de reação. A diferença de tempo entre ocorrer o evento A5 e o evento T1 na nova proposta teve uma redução de 1,56%. Este mesmo teste simulado no CLP (Tabela 7.2) e somente no computador (Tabela 7.3) mostra que os tempos na nova proposta são menores.

97 96 Tabela Primeiro teste simulado no CLP N.Prop. Vieira (2007) Diferença ciclo A5/B5 5 6 Diferença ciclo B5/T1 0 1 Diferença ciclo A5/T1 5 7 Diferença Tempo A5/B5 20,8 ms 41,4 ms Diferença Tempo B5/T1 1 ms 8,2 ms Diferença Tempo A5/T1 21,8 ms 49,6 ms Tabela Primeiro teste simulado no computador N.Prop. Vieira (2007) Diferença ciclo A5/B5 5 6 Diferença ciclo B5/T1 0 1 Diferença ciclo A5/T1 5 7 Diferença Tempo A5/B5 27 ms 70 ms Diferença Tempo B5/T1 0 ms 12 ms Diferença Tempo A5/T1 54 ms 82 ms 7.2 SEGUNDO TESTE EVENTOS NO MESMO CICLO. Este teste foi realizado somente a partir da implementação feita sobre a planta existente na PUCPR. O sistema foi executado no modo manual, situação em que todos os eventos são desabilitados por segurança e o operador habilita o evento desejado à medida que observa a evolução da planta. Neste teste foi habilitado primeiramente o evento A5, que corresponde ao início do sistema de alimentação. A peça foi levada até a posição P2, onde foi submetida ao processo completo de furação (Figura 5.11). Foi iniciado o ciclo de produção de uma segunda peça, que foi levada até a posição P1. Com as duas peças em suas respectivas posições, foi feito o giro da mesa rotativa, M0, levando-se as peças às posições P2 e P3 respectivamente. Foi iniciado o processo de furação com a peça na posição P2 e o processo de teste com a outra peça na posição P3. Porém, foi acrescentada uma variável para que os processos terminem somente quando o operador desejar. Um terceiro ciclo de produção foi iniciado, de forma que uma terceira peça foi levada à posição P1, porém não foi finalizado o processo de transporte. Com este

98 97 procedimento os três subsistemas (G1, G2 e G3 estavam respectivamento nos estados: 3 - transportando, 1 - furando, 1 - testando). Nesta parte do teste, foi acionado o comando para que os términos dos três processos em andamento (Teste, Furação, Transporte) ocorressem simultaneamente, ou seja, que as respostas, rspb1, rspb2 e rpsb3, correspondentes aos eventos não controláveis, B1, B2 e B3, fossem incrementadas no mesmo ciclo de varredura, mostrado nas linhas 7, 8 e 9 da Tabela 7.4. Foi observado em cada proposta como foi o comportamento do sistema. Para este teste foi criado o FB Registra, no qual parte do programa é mostrado na Figura 7.5. É registrado quais eventos ocorreram, o ciclo e o tempo. Figura Function Block Registra Na proposta de Vieira (2007), observa-se que as respostas dos processos, rspb1, rspb2 e rspb3 são incrementadas todas no mesmo ciclo (ciclo de número 53186), porém o tratamento dos eventos não controláveis correspondentes ocorrem cada um em um ciclo diferente, conforme mostrado nas linhas 10, 11 e 12 da Tabela 7.4. No primeiro ciclo ocorreu o tratamento evento não controlável B1, no seguinte ocorreu o tratamento do evento não controlável B2 e finalmente em um terceiro ciclo ocorreu o tratamento do evento não

99 98 controlável B3. Isto acontece porque os três subsistemas compartilham células de controle e, portanto, não pode haver o tratamento de eventos destes subsistemas no mesmo ciclo de atualização da arquitetura de controle. Tabela Segundo teste, proposta de Vieira (2007) linha ciclo Evento dif.ciclo rspb B rspb B rspb B rspb rspb rspb B B B rspb B2 1 Na nova proposta, as respostas rspb1, rspb2 e rspb3 são incrementadas no mesmo ciclo (ciclo de número ) e, linhas 7, 8 e 9 na Tabela 7.5. Nas linhas 10, 11 e 12 da Tabela 7.5 pode ser verificado que os eventos não controláveis, B1, B2 e B3 são todos tratados no ciclo seguinte. Isto ocorre uma vez que nesta proposta é possível tratar todos os eventos não controláveis no mesmo ciclo, mesmo que compartilhem células de controle. Este fato também determina a redução no tempo de resposta do sistema de controle, tornando o programa mais dinâmico.

100 99 Tabela Segundo teste, nova proposta linha ciclo Evento dif.ciclo rspb B rspb B rspb B rspb rspb rspb B B B rspb B TERCEIRO TESTE MONITORAMENTO DE TODOS OS EVENTOS Neste terceiro teste foram monitorados todos os eventos controláveis e não controláveis a partir da implementação feita sobre a planta física e também de simulações no CLP e em computador. Para realização deste teste, quando ocorre um evento no blocos Gi é chamado o FB Registra4 com a informação que qual evento ocorreu e o número do ciclo como visto na Figura 7.6 quando ocorre o evento A1 no bloco G1 Figura Chamada do FB Registra4

101 100 No FB Registra4 é registrado todos os eventos que ocorreram, o ciclo e o tempo como é mostrado a Figura 7.7. Figura 7.7- FB Registra4 Na Tabela 7.6 é mostrada a média da diferença entre os ciclos de varredura do CLP e a média da diferença do tempo, ambas tomadas a partir dos resultados obtidos em 5 execuções distintas da planta. Na primeira coluna, intitulada CASP - Ciclo de Atualização do Sistema Produto, são contabilizados somente os ciclos de varredura do CLP nos quais houve tratamento de eventos e na segunda (e na quinta) colunas mostram-se os eventos que ocorreram em cada um destes ciclos. Já na terceira (e na sexta) coluna mostra-se a média da diferença do número de ciclos de varredura do CLP que ocorreram entre o tratamento de eventos. Por fim, na quarta (e na sétima) colunas mostra-se a média da diferença do tempo entre o tratamento de eventos da proposta deste trabalho (proposta de Vieira). Nas 3 últimas colunas são apresentados os resultados obtidos com a implementação baseada na proposta de Vieira (2007).

102 101 Analisando a Tabela 7.6 pode-se verificar que na proposta deste trabalho alguns eventos foram tratados no mesmo ciclo de varredura do CLP, como por exemplo os eventos B5 e T1 no CASP 2 e os eventos B1, A0 e A5 no CASP 4. Já na implementação feita seguindo a proposta de Vieira, no ciclo de varredura do CLP correspondente ao CASP 2 foi tratado apenas o evento B5 o evento T1 é tratado no próximo ciclo de varredura do CLP e portanto no CASP 3. De forma similar, no ciclo de varredura do CLP corresponde ao CASP 6 é tratado apenas o evento B1, os eventos A0 e A5 são tratados nos próximos ciclos de varredura do CLP no CASP 7 e 8, respectivamente. Isto ocorre uma vez que na proposta deste trabalho todos os eventos não controláveis podem ser tratados num único ciclo, ainda que pertençam à mesma célula de controle, o que não acontece com a proposta de Vieira (2007). Pode-se ver na Tabela 7.6 que para tratar estes 40 primeiros eventos a nova proposta precisou de 22 CASP, ao passo que na proposta de Vieira (2007) foram necessários 36 CASP. Pode ser observado também que entre os eventos desta proposta ocorreram mais ciclos que na proposta de Vieira (2007). Por exemplo, entre o CASP 1 e 2 (tratamento dos eventos que correspondem ao início e fim de operação do sistema de alimentação) nesta proposta ocorreram uma média de 592 ciclos de varredura do CLP, enquanto na proposta de Vieira (2007) ocorreram em média 308 ciclos. Isto demonstra que a nova proposta lê mais vezes a entrada e trata com mais rapidez um evento que ocorre na planta. Esta diferença é decorrente do fato de que o sistema produto e os supervisores somente são chamados se existe possibilidade de tratar algum evento ou atualizar um estado. Na nova proposta foram executadis em média ciclos em ms (valores resultantes da média de 5 execuções da planta) para tratar os 40 primeiros eventos. Na proposta de Vieira (2007) foram rodados em média ciclos em ms. Neste caso, a diferença entre os tempos finais de cada proposta não é significativo, pois a planta tem seus tempos de processamento (constantes de tempo) muito mais longos que o tempo de processamento do software. Por este motivo foi verificado uma diferença pequena no tempo final, porém na nova proposta os eventos foram tratados assim que gerados pela planta, e o sistema leu mais vezes a entrada para tratá-los o mais rápido possível, o que em plantas com dinâmicas mais rápidas ou mais complexas pode levar a diferenças significativas entre as propostas.

103 102 Tabela 7.6 Terceiro teste na planta Nova Proposta Proposta de Vieira (2007) CASP Eventos Dif.Ciclo Dif.Tempo Eventos Dif.Ciclo Dif.Tempo 1 A5 A5 2 B5 592, B T L1 248, T A B1 481, L1 129, A0 0 0 A B0 552, A A B5 21,2 114 B1 214, T B A A A L B0 283, B0 138,6 712 A A A3 1 4 B5 16, B T B B2 15,2 192 A0 0 6 A B0 546, A A2 0 2 A B5 31,8 208 L1 213, T B2 27,8 176 B0 69, B4 254, A A L A B0 338, B3 38,8 482 A A3 1 8 B1 183, B A A B1 362, B0 280, A0 0 2

104 103 A B0 547, A A2 0 2 A B5 19, T B2 14, B4 128, A L B0 173, A A B B A A B0 281, A No monitoramento de todos os eventos feito sobre simulações do programa no CLP e também no computador, para as duas propostas obteve-se o mesmo comportamento do monitoramento feito sobre a planta física. Na Tabela 7.7 são mostrados os eventos, a média da diferença dos tempos e a média da diferença dos ciclos, médias estas obtidas também para 5 execuções do programa. Na Tabela 7.7 (a) apresentam-se os dados relativos ao teste feito com a proposta de Vieira (2007) e na Tabela 7.7 (b) os resultados obtidos com a proposta deste trabalho. Em ambas as tabelas, na primeira coluna são apresentados os eventos, a segunda e terceira colunas são referentes ao teste simulado no CLP e a quarta e quinta coluna são referentes ao teste simulando no computador. Conforme se pode observar na Tabela 7.7 (b), na nova proposta foi tratado mais de um evento por ciclo de varredura. Note por exemplo que em todas as linhas referentes ao evento L1 a diferença de ciclo em relação ao evento anterior (evento B5) é igual a zero, o que significa que T1 e B5 ocorreram no mesmo ciclo. Na última linha da Tabela 7.7 mostra-se o valor total referente ao somatório das diferenças de ciclos e também das diferenças de tempo para as duas simulações (no CLP e no computador). Com base nestes valores pode-se concluir que a implementação feita a partir de nova proposta necessita menos ciclos de atualização do sistema produto e tempo menor do que a implementação feita a partir da proposta de Vieira para tratar o mesmo número de eventos.

105 104 Evento A5 Dif.Tempo (ms) Tabela Terceiro teste simulado a) Vieira (2007) b) Nova Proposta CLP Computador CLP Computador Dif.Ciclo Dif.Tempo (ms) Dif.Ciclo Evento A5 Dif.Tempo (ms) Dif.Ciclo Dif.Tempo (ms) Dif.Ciclo B5 41, B T1 8, T1 2, L1 29, ,5 4 L A1 7, A B1 21,5 3 35,5 3 B1 9, A0 7, A0 3, A5 0,25 0 0,5 0 A5 0, B ,5 3 B0 11, A A2 4, B5 7, B5 7, T ,5 1 T1 2, B B2 2,8 1 10,67 1 A A L1 14, ,5 2 B0 11,4 3 34,67 3 B0 5, L1 3, A1 8, A1 1, A3 8, A3 3,8 1 11,33 1 B3 6, ,5 1 B3 4,2 1 10,67 1 B1 6, ,5 1 B1 5, A0 7, ,5 1 A0 2, A ,5 0 A5 0, B B0 11, A2 7, A2 4, A4 0,25 0 0,5 0 A B ,5 1 B5 9,4 2 23,33 2 T1 8, ,5 1 T1 0, B2 6, ,5 1 B2 3, B4 0, B4 0, A ,5 2 A0 1, L1 6,5 1 11,5 1 B ,33 3 B0 13,5 2 23,5 2 L1 0, A1 7, ,5 1 A1 1,

106 105 A A3 4,6 1 11,67 1 B3 6, B3 3, B1 6,5 1 11,5 1 B1 6,2 1 11,67 1 A0 7,5 1 11,5 1 A0 1, A5 0, A5 0, Total 349, Total 183, , TAMANHO DE PROGRAMA No intuito de comparar o tamanho do programa obtido a partir de cada uma das propostas, foram comparados apenas os blocos que sofreram alterações em relação à proposta de Vieira (2007). Na Tabela 7.8 podem ser vistas as diferenças. Nos FB Gis foram eliminadas as variáveis gievt, diminuindo assim o tamanho dos blocos. No caso do PS, o programa era implementado em Ladder Diagram e os dgi cada um em um bloco de Ladder Diagram. Na nova proposta todos foram reunidos em um único bloco escrito em Structured Text. Este bloco ficou menor e ainda tem mais funções. No bloco PS da nova proposta só são verificados os dgi se estiver tratando os eventos controláveis. O bloco Gi só será chamado se algumas condições forem verdadeiras, como foi visto no Capítulo 6, evitando chamadas desnecessárias dos blocos. O Bloco MS na proposta de Vieira (2007) é escrito em Ladder Diagram, na Nova proposta foi escrito em SCL, ficando maior nesta. Vale lembrar, entretanto, que na nova proposta os supervisores somente são chamados se este for mudar de estado. Pode ser verificado que no total o programa da Nova Proposta fica 0,15% maior, porém mais eficiente, sendo capaz de tratar mais rapidamente os eventos não controláveis que ocorrem no sistema a ser controlado. Conclui-se que, mesmo resultando em um código mais eficiente a diferença de memória requerida para realizar a implementação é desprezível.

107 106 Tabela Tamanho do código, comparação com a proposta de Vieira Vieira (2007) Nova Proposta Diferença Bloco Tamanho (bytes) Bloco Tamanho (bytes) Tamanho (bytes) G0 858 G G G G G G G G G G G PS (LAD) 530 PS (SCL) 716 dg0 50 dg1 50 dg2 48 dg3 50 dg4 46 dg5 44 soma 818 soma MS (LAD) 568 MS (SCL) action_sup 240 action_sup Total 9014 Total Symbols Symbols Total Total TAMANHO DE PROGRAMA COMPARANDO COM CRUZ (2011) Comparando o programa com a proposta de Cruz (2011), na Tabela 7.9 pode-se verificar que o tamanho do programa obtido a partir da proposta deste trabalho ficou 6,15 vezes maior em todos os blocos, o que é esperado em um programa de mais alto nível. O único bloco que na proposta de Cruz (2011) ficou maior foi a tabela de símbolos, 37,6%. Na contagem final, o programa da nova proposta ainda ficou menor 25,9% em relação à proposta de Cruz (2011). Este fato era esperado pois a memória requerida para implementar um SFC é praticamente dez vezes superior à memória requerida para implementar uma estrutura sequencial equivalente na linguagem Ladder Diagram.

108 107 Tabela 7.9- Tamanho do código, comparação com a proposta de Cruz (2011) Cruz (2011) Nova Proposta Diferença Bloco Tamanho (bytes) Bloco Tamanho (bytes) Tamanho (bytes) OB1 232 OB DESABILITAÇÕES 74 MS2 (SCL) 590 ATUALIZA 86 PS2 (SCL) 592 action_sup 240 soma 392 soma ENC G1 48 G1 298 EC G1 48 DB 458 soma 96 soma ENC G2 48 G2 298 EC G2 48 DB 458 soma 96 soma ENC G3 48 G3 298 EC G3 48 DB 458 soma 96 soma ENC G4 48 G4 298 EC G4 48 DB 458 soma 96 soma ENC G5 48 G5 298 EC G5 48 DB 458 soma 96 soma ENC G6 48 G6 298 EC G6 48 DB 458 soma 96 soma ENC SSA 48 SRA 202 EC SSA 46 DB 402 soma 94 soma ENC SB 48 SRB 300 EC SB 46 DB 402 soma 94 soma ENC SC 58 SRC 202 EC SC 62 DB 508 soma 120 soma ENC SD 48 SRD 202 EC SD 46 DB 402 soma 94 soma TRATA ESCOLHA 46 TRATA ESCOLHA 46 0 Symbols Symbols

109 108 Total 1416 Total Total c/ Symbols Total c/ Symbols CONCLUSÃO AO CAPÍTULO Neste capítulo foram apresentados os resultados dos testes comparativos entre as propostas. Pode-se verificar que em relação a proposta de Vieira (2007), a proposta deste trabalho é capaz de tratar mais eventos por ciclo de varredura sendo mais eficiente. A comparação em relação ao trabalho de Cruz, mostra que mesmo sendo um programa de alto nível, o tamanho do programa final ficou menor.

110 109 8 CONSIDERAÇÕES FINAIS Neste capítulo será apresentada a conclusão deste trabalho, mostrando que o objetivo foi alcançado e também serão apresentadas algumas sugestões para trabalhos futuros. 8.1 CONCLUSÃO Neste trabalho foi introduzida uma metodologia de implementação utilizando arquitetura de controle supervisório de Queiroz e Cury (2002), onde a planta original de Ramadge e Wonham (1989) é composta pelo sistema produto, procedimentos operacionais e sistema a ser controlado. Com esta arquitetura os eventos são gerados na planta e os supervisores tem a função de desabilitar eventos. Para a síntese do supervisor foi utilizada a Abordagem Modular Local proposta por Queiroz e Cury (2000) onde são definidos supervisores locais que, em conjunto, coordenam o comportamento do sistema. Esta implementação tem como um dos objetivos utilizar a linguagem Sequential Function Charts (SFC) e tratar o máximo de eventos por ciclo de varredura do CLP. Para validar a proposta foram utilizados dois exemplos. No primeiro foi utilizada uma linha de transferência industrial onde Cruz (2011) exemplificou seu trabalho. Outro exemplo utilizado para a implementação foi na planta física de uma célula de manufatura utilizada por Vieira (2007). Nos dois exemplos foram utilizadas as linguagens Sequential Function Charts (SFC), Ladder Diagram e Structured Text. Em cada ciclo de varredura do CLP podem ser tratados todos os eventos não controláveis que ocorreram na planta, e ainda até um evento controlável por célula de controle. Antes de chamar cada subsistema ou supervisor é feita uma verificação se existe possibilidade de algum evento ser tratado ou atualizado. Assim os blocos somente são chamados se necessário, o programa fica mais eficiente e o ciclo de varredura mais rápido. No trabalho de Vieira (2007) o tratamento de eventos de um determinado subsistema, tanto controlável quanto não controlável, é suspenso se já tiver sido realizado o tratamento de evento de algum subsistema que compartilha alguma célula de controle como o subsistema em questão. Com isto ocorre somente um evento por célula de controle por ciclo de varredura do CLP. Na nova proposta esta restrição ao tratamento de eventos é flexibilizada. Apenas o tratamento (geração) de eventos controláveis é que requer a suspensão do tratamento de eventos controláveis dos subsistemas que compartilham eventos com o subsistema que teve o evento tratado. Desta forma o tratamento de eventos não controláveis nunca resultam na suspensão do tratamento de eventos de qualquer subsistema, inclusive do próprio subsistema

111 110 que teve o evento tratado. Além disto, em um ciclo de varredura todos os eventos não controláveis são tratados. Na proposta de Vieira (2007), mesmo que um determinado subsistema não tenha qualquer evento apto a ser tratado, o Function Block correspondente é chamado para atualização. Isto resulta em tempo de processamento desperdiçado. Na nova proposta a implementação é otimizada, reduzindo o tempo de processamento do ciclo de varredura do CLP e realizando a chamada de um Function Block que implementa o módulo do sistema produto apenas quando há evento apto a ser processado. Na proposta de Cruz (2011) o programa foi implementado na linguagem Ladder Diagram, que é uma linguagem de baixo nível. Na nova proposta foi implementado em uma linguagem de mais alto nível. Como esperado, o código das funções da programação de alto nível é maior que na de baixo nível. Porém na proposta de Cruz (2011) é utilizada uma quantidade maior de variáveis, o que nesta nova proposta não foi necessário. Sendo assim, o código final da proposta deste trabalho ainda ficou menor. O exemplo utilizado por Cruz (2011) foi apenas simulado no computador e não foi utilizado o bloco de procedimentos operacionais. Como é um exemplo simples e somente simulado, os eventos foram lidos no início do ciclo de varredura. Com isto todos os eventos não controláveis eram tratados com um ciclo antecipadamente que em relação a esta proposta. Porém o problema de usar este tipo de implementação em sistemas mais complexos e práticos, é que com os procedimentos operacionais é possível realizar abstrações na etapa de modelagem deixando os subsistemas mais simples e modelos com menor número de estados reduzindo a complexidade da síntese dos supervisores. Esta implementação ficou mais eficiente, tratando mais eventos por ciclo de varredura do CLP, porém o custo desta implementação é o aumento da complexidade na geração de código. Na proposta de Queiroz (2004) era tratado no máximo um evento por ciclo de varredura do CLP, com isto a implementação fica mais simples, pois não se realiza a análise das células de controle, dispensa a função dgi e as variáveis gdi e gievt. Na nova proposta tem um melhor desempenho bem como um aumento na complexidade de geração de código. Apesar de ser complexa, é possível de ser automatizada. Neste caso a solução apresentado na Figura 6.13 deve ser implementada para todo supervisor considerando todos os eventos para os quais a função de transição de estados (do autômato que implementa o supervisor) está definida.

112 111 Assim, pode-se dizer que a metodologia de implementação apresentada neste trabalho foi alcançada. Foi feita uma implementação usando Sequential Function Charts (SFC), Ladder Diagram e Structured Text. Alcançou também o objetivo de tratar mais eventos por ciclo de varredura deixando o programa mais eficiente comparando com a proposta de Vieira (2007). 8.2 TRABALHOS FUTUROS Nesta seção serão apresentadas algumas sugestões para trabalhos futuros Divisão do bloco PS Na proposta deste trabalho, existe um bloco PS escrito em Structured Text que é chamado duas vezes. Na primeira chamada são tratados os eventos não controláveis e na segunda chamada são tratados os eventos controláveis. Porém, a cada vez é feita a verificação de quais eventos devem ser tratados, desperdiçando-se tempo com estas verificações. Se o bloco fosse separado, menos verificações seriam necessárias, tornando o bloco mais ágil, além de um programa mais claro Sincronização inexata propriedade 2 Basile e Chiacchio (2007) apresentam a propriedade 2, como visto na seção A implementação feita atende a propriedade a propriedade 1 de Balemi (1992, apud FABIAN e HELLGREN 1998). Pode ser feito um estudo de como fazer uma implementação que atenda a prioridade Identificação do problema de escolha Existe uma grande dificuldade para identificar se em um sistema de controle existe o problema de escolha. Segundo DIETRICH et al. (2002) é necessário seguir um conjunto de propriedades. Um trabalho que pode ser feito é criar um procedimento que identifique se o sistema de controle tem ou não o problema de escolha Programação em Structured Text Neste trabalho foi utilizado três tipos de linguagem: Sequential Function Charts (SFC), Ladder Diagram e Structured Text. Um trabalho que pode ser desenvolvido é fazer uma implementação em Structured Text, facilitando a geração de código automático Geração automática de código Realizar um estudo comparativo entre as ferramentas que contemplam a geração automática de código para CLPs e desenvolver uma ferramenta que implemente as soluções

113 112 apresentadas neste trabalho. Dentre as ferramentas existentes para Sistemas a Eventos Discretos que tratam da geração de código podem-se citar: GPACLP (CURZEL, 2008); CGLI, 2012; DES2ST, 2012; DESTool, 2012.

114 113 REFERÊNCIAS AFZALIAN, A.; NOORBAKHSH, M.; NAVABI, A. PLC implementation of decentralized supervisory control for dynamic flow controller. Proceedings of the 17th IEEE International Conference on Control Applications (CCA'08), pp , San Antonio, Texas (USA), September, BASILE, F.; CHIACCHIO, P.; On the Implementation of Supervised Control of Discrete Event Systems. In: Transactions on Control Systems Technology. Vol.15, no. 4, CASSANDRAS, C.G.; LAFORTUNE S.; Introduction to Discrete Event Systems. Kluwer Academic Publishers. USA, CGLI, disponível em < acessado em abril de CHANDRA, V.; HUANG, Z.; KUMAR, R. Automated Control Synthesis for an Assembly Line Using Discrete Event System Control Theory. IEEE Transactions on Systems, Man, and Cybernetics Part C: Applications and Reviews, Vol. 33, No. 2, (may 2003), pp , ISSN CURY, J. E. R; Teoria de Controle Supervisório de Sistemas a Eventos Discretos. Simpósio Brasileiro de Automação Inteligente. Canela-RS, V CURZEL, J. L.; Síntese e implementação de controle supervisório em uma célula flexível de manufatura didática. Dissertação (Mestrado em Engenharia Elétrica) Universidade do Estado de Santa Catarina. Joinville, CRUZ, D. L. L. da; Metodologia para Implementação de Controle Supervisório Modular Local em Controladores Lógicos Programáveis. Dissertação (Mestrado em Engenharia Elétrica) Universidade do Estado de Santa Catarina. Joinville, DES2ST, disponível em < acessado em abril de DESTool, disponível em < acessado em abril de DIETRICH, P.; MALIK, R.; WONHAM, W.M.; BRANDIN, B.; Implementation considerations in supervisory control. In: Synthesys and control of discrete event systems. Kluwer Academic Publishers, p , 2002 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

115 114 FLORDAL, H.; MALIK, R.; Nonblocking Verification Using Conflict Equivalence. In: 8th International Workshop on Discrete Event Systems (WODES), p Ann Arbor HASDEMIR, T.; KURTULAN, S.; GÖREN, L.; An Implementation Methodology for Supervisory Control Theory. The International Journal of Advanced Manufacturing Technology, v. 03. n p HELLGREN, A.; LENNARTSON, B. & FABIAN, M. Modelling and PLC-based implementation of modular supervisory control, Proceedings of the 6th International Workshop on Discrete Event Systems (WODES 02), pp ISBN: Zaragoza, Spain, October 2002 LAUZON, S. C.; MILLS, J. K.; & BENHABIB, B.. An Implementation Methodology for the Supervisory Control of Flexible Manufacturing Workcells, Journal of Manufacturing Systems, Vol. 16, No. 2, pp , 1997 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,, pp LEAL, A. B. ; CRUZ, D. L. L. ; HOUNSELL, M. S.. PLC-based Implementation of Local Modular Supervisory Control for Manufacturing Systems. In: Faieza Abdul Aziz (Ed.). (Org.). Manufacturing System. 1 ed. : INTECH, 2012, v., p LEDUC, R. J. PLC Implementation of a DES supervisor for a manufacturing testbeb: an implementation perspective, M.A.Sc. Thesis, Dept. of Electrical and Computer Engineering, Univ. of Toronto, Canada., 1996 LEDUC, R.J.; WONHAM W. M. PLC implementation of a DES supervisor for a manufacturing test bed. Proceeding of Thirty-Third Annual Allerton Conference on Communication, Control and Computing, pp , University of Illinois, LIU, J.; DARABI, H. (2002). Ladder logic implementation of Ramadge-Wonham supervisory controller, Proceedings of the 6th International Workshop on Discrete Event System (WODES 02), pp ISBN: Zaragoza, Spain, October MALIK, P.; Generating Controllers from Discrete-Event Models. In: F. Cassez, C jard, F. Laroussinie, M. D. Ryan, Proc of the MOVEP, pp MANESIS, S.; AKANTZIOTIS, K. (2005). Automated synthesis of ladder automation circuits based on state-diagrams. Advances in Engineering Software, 36, pp POSSAN, M. C.; LEAL, A. B. (2009). Implementation of Supervisory Control Systems Based on State Machines. In: Proceedings of the 14th IEEE International Conference on Emerging Technologies and Factory Automation ETFA, pp , Palma de Mallorca, 2009.

116 115 QUEIROZ, M. H. de; Controle Supervisório Modular e Multitarefa de Sistemas Compostos. Tese (Doutorado em Engenharia Elétrica) Universidade Federal de Santa Catarina. Florianópolis, 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 ; 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 QUEIROZ, M. H. de, SANTOS, E. A. P.; 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 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 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, 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.