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

Livre

0
0
116
6 months ago
Preview
Full text

  

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

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

  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, 2012.

  117 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, 2012.

  1.Automação de Sistemas. 2.Teoria de Controle Supervisório. I. Leal, André Bittencourt. CDD 629.8

  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.

  

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.

  

RESUMO

  DE ALMEIDA, Suzana Ribas. Implementação de controle supervisório em CLPs usando

  

linguagem de alto nível, 2012. 118f. 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, 2012. 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

  

ABSTRACT

  DE ALMEIDA, Suzana Ribas. Implementation of Supervisory Control in PLCs Using

  

High-Level Language, 2012. 118f. Dissertation (Master Course in Electrical Engineering –

  Area: Automation Systems) – Santa Catarina State University, Post-Graduation Program in Electrical Engineering, Joinville, 2011. 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.

  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

  

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

  Nível Procedimentos Operacionais

  OP – 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 61131-3

  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)

  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á

  

LISTA DE FIGURAS

Figura 2.1 - Autômato G .......................................................................................................... 23Figura 2.2 – Definição de composição síncrona de Cury (2001) ............................................. 24Figura 2.3 - Sincronização G1||G2 com eventos em comum ................................................... 24Figura 2.4 - Linha de transferência industrial (QUEIROZ E CURY, 2000) ............................ 26Figura 2.5 - Autômato das máquinas (CRUZ, 2011) ............................................................... 26Figura 2.6 - Autômatos das especificações (CRUZ, 2011) ...................................................... 27

  Figura 2.7- Controle supervisório monolítico (RAMADGE e WONHAM, 1989) .................. 28

Figura 2.8 - Células de controle................................................................................................ 29

  Figura 2.9- Esquema de controle modular local (QUEIROZ e CURY, 2000) ......................... 30

Figura 2.10 – Representação por sistema produto .................................................................... 31

  Figura 2.11- Supervisores locais (CRUZ, 2011) ...................................................................... 32

Figura 2.12 - Supervisores reduzidos (CRUZ 2011) ................................................................ 33Figura 3.1 - Arquitetura segundo Ramadge e Wonham (1989) ............................................... 34Figura 3.2 - Arquitetura de controle supervisório, Queiroz e Cury (2002) .............................. 35Figura 3.3 - Processo cíclico do CLP ....................................................................................... 36Figura 3.4 - Símbolos da linguagem Ladder Diagram ............................................................. 38Figura 3.5 - Programa em Ladder Diagram ............................................................................. 39Figura 3.6 – Símbolos da linguagem SFC ................................................................................ 39Figura 3.7 - Autômato susceptível ao efeito avalanche (HASDEMIR et al., 2008) ................ 40Figura 3.8 - Programa em Ladder Diagram com efeito avalanche .......................................... 41Figura 3.9 - Programa em Ladder Diagram sem efeito avalanche .......................................... 41Figura 3.10 - Autômato susceptível ao efeito avalanche (HASDEMIR et al., 2008) .............. 42Figura 3.11 –Proposta de Vieira (2007) para efeito avalanche ................................................ 43

  Figura 3.12- Diagrama temporal .............................................................................................. 44

Figura 3.13 - Problema da incapacidade de reconhecer a ordem dos eventos ......................... 44Figura 3.14 - Autômato susceptível ao problema de sincronização inexata ............................ 45Figura 3.15 - Propriedade 1 ...................................................................................................... 45

  Figura 3.16- Propriedade 2 ....................................................................................................... 46

Figura 3.18 - Autômato susceptível ao problema da escolha ................................................... 47Figura 4.1 – Fluxograma proposto por Cruz (2011) ................................................................. 49Figura 4.2 - Fluxograma completo da rotina principal (CRUZ, 2011) .................................... 50Figura 4.3 – Programa principal - OB1 .................................................................................... 51Figura 4.4 - Parte da sub-rotina de leitura ................................................................................ 52Figura 4.5 - Bloco ATUALIZA ................................................................................................ 53Figura 4.6 – Eventos não controláveis no subsistema Gi (a) ENC G1; (b) Autômato G1 ....... 54Figura 4.7 –Eventos não controláveis nos supervisores (a) ENC SA; (b) Autômato SA ........ 54Figura 4.8 Ố Parte do programa de DESABILITAđỏES ......................................................... 55Figura 4.9 – Bloco TRATA ESCOLHA .................................................................................. 56Figura 4.10 –Eventos controláveis no subsistema Gi (a) EC G1; (b) Autômato G1 ................ 56Figura 4.11 –Eventos controláveis no supervisor (a) EC SA; (b) Autômato SA ..................... 56Figura 5.1 - Programa Main (VIEIRA, 2007) .......................................................................... 59Figura 5.2 - Ordem de chamada de blocos ............................................................................... 60Figura 5.3 - Supervisores reduzidos ......................................................................................... 61Figura 5.4 - Bloco FC dg2 ........................................................................................................ 62Figura 5.5 – Autômatos equivalentes a) com autolaço e b) sem autolaço ................................ 63Figura 5.6 - Exemplo de autômato da planta ............................................................................ 64Figura 5.7 - Novo autômato H2 para a planta G2 .................................................................... 64Figura 5.8 - SFC para o subsistema G2 .................................................................................... 66Figura 5.9 - SFC para o supervisor SRB .................................................................................. 67Figura 5.10 - Desabilitação de eventos controláveis ................................................................ 67Figura 5.11 - Célula de Manufatura (VIEIRA, 2007) .............................................................. 69Figura 5.12 - RSP para a célula de manufatura (VIEIRA, 2007) ............................................. 70

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

Figura 5.14 - Parte do Bloco MS .............................................................................................. 73Figura 5.15 - FB para o supervisor slb1 ................................................................................... 73Figura 5.16 - Desabilitação do evento A1 ................................................................................ 73Figura 5.17 – Parte do bloco PS, chamada do dg0 e G0 .......................................................... 74Figura 5.18 – Bloco FC dg0 ..................................................................................................... 74Figura 5.19 – SFC G0 ............................................................................................................... 75

  Figura 5.20- Parte do bloco OP ................................................................................................ 76

Figura 6.3 – Parte do bloco PS ................................................................................................. 81Figura 6.4 - Implementação do bloco G0 ................................................................................. 82Figura 6.5 – Chamada dos supervisores com eventos não controláveis ................................... 83Figura 6.6 - Chamada dos supervisores com eventos controláveis .......................................... 84Figura 6.7 - Supervisor slb2 ..................................................................................................... 84Figura 6.8 - Atualização das desabilitações.............................................................................. 85

  Figura 6.9- Parte o bloco MS, eventos zerados ........................................................................ 85 Figura 6.10- FB OP a0 .............................................................................................................. 86

Figura 6.11 - Autômato susceptível ao efeito avalanche .......................................................... 87Figura 6.12 - SFC susceptível ao efeito avalanche .................................................................. 88Figura 6.13 - Programa MS ...................................................................................................... 89Figura 6.14 - Chamada do “TRATA_ESCOLHA” no bloco Action_sup ................................ 91Figura 6.15 - Bloco de escolha ................................................................................................. 91Figura 7.1 - TIME_TCK e início do NCiclo ............................................................................ 92Figura 7.2 - Incremento de NCiclo ........................................................................................... 93Figura 7.3 - Chamada do Registra3 no G5 ............................................................................... 93Figura 7.4 - Function Block Registra3 ..................................................................................... 94Figura 7.5 - Function Block Registra ....................................................................................... 97Figura 7.6 - Chamada do FB Registra4 .................................................................................... 99

  Figura 7.7- FB Registra4 ........................................................................................................ 100

  

LISTA DE TABELAS

Tabela 2.1 - Plantas locais ........................................................................................................ 31Tabela 4.1 - Resultado da execução do DECON9.................................................................... 57Tabela 5.1 - Eventos por célula de controle ............................................................................. 62Tabela 5.2 - Conversão Gi – Hi ................................................................................................ 64

  Tabela 5.3- Transições de H2 ................................................................................................... 65

Tabela 5.4 Eventos desabilitados.............................................................................................. 66Tabela 5.5 Eventos que causam mudança de estado ................................................................ 67Tabela 5.6 - Semântica de estados e eventos (VIEIRA, 2007)................................................. 71Tabela 6.1 – No. de estados e de transições do conjunto de supervisores (VIEIRA, 2007). ... 87Tabela 7.1 - Primeiro teste na planta ........................................................................................ 94Tabela 7.2 - Primeiro teste simulado no CLP ........................................................................... 96Tabela 7.3 - Primeiro teste simulado no computador ............................................................... 96Tabela 7.4 - Segundo teste, proposta de Vieira (2007) ............................................................ 98Tabela 7.5 - Segundo teste, nova proposta ............................................................................... 99Tabela 7.6 – Terceiro teste na planta ...................................................................................... 102Tabela 7.7 - Terceiro teste – simulado ................................................................................... 104Tabela 7.8 - Tamanho do código, comparação com a proposta de Vieira ............................. 106

  Tabela 7.9- Tamanho do código, comparação com a proposta de Cruz (2011) ..................... 107

  

SUMÁRIO

  1 INTRODUđấO .............................................................................................................. 19

  1.1 OBJETIVOS ......................................................................................................... 20

  1.2 ESTRUTURA DO TRABALHO ......................................................................... 20

  

2 CONTROLE SUPERVISÓRIO DE SISTEMAS A EVENTOS DISCRETOS ........ 22

  2.1 SISTEMA A EVENTOS DISCRETOS ............................................................... 22

  2.1.1 Linguagem ................................................................................................ 22

  2.1.2 Autômato .................................................................................................. 23

  2.1.3 Composição síncrona ................................................................................ 24

  2.2 TEORIA DE CONTROLE SUPERVISÓRIO (TCS) .......................................... 25

  2.2.1 Identificação do conjunto de subsistemas envolvidos no problema ......... 26

  2.2.2 Modelagem da planta ............................................................................... 26

  2.2.3 Mapeamento dos eventos controláveis e não controláveis dos subsistemas ............................................................................................... 26

  2.2.4 Modelagem das especificações ................................................................. 27

  2.2.5 Síntese dos supervisores ........................................................................... 27

  2.3 ABORDAGEM MONOLÍTICA .......................................................................... 27

  2.3.1 Obtenção do modelo da planta G ............................................................. 28

  2.3.2 Obtenção do modelo da especificação E .................................................. 28

  2.3.3 Cálculo da linguagem alvo K ................................................................... 28

  2.3.4 Cálculo da linguagem controlável SupC(K,G) ......................................... 28

  2.4 ABORDAGEM MODULAR LOCAL ................................................................. 29

  2.4.1 Representação por sistema produto .......................................................... 30

  2.4.2 Obtenção das plantas locais ...................................................................... 30

  2.4.3 Obtenção das especificações locais .......................................................... 31

  2.4.4 Obtenção das linguagens controláveis ...................................................... 32

  2.4.6 Obtenção dos supervisores reduzidos ....................................................... 32

  2.5 CONCLUSÃO AO CAPÍTULO .......................................................................... 33

  3 IMPLEMENTAđấO DE CONTROLE SUPERVISốRIO EM CLPs ..................... 34

  3.1 ESTRUTURA DE IMPLEMENTAđấO ............................................................. 34

  3.2 IMPLEMENTAđấO EM CLPs ........................................................................... 35

  3.3 ALGUMAS LINGUAGENS DE PROGRAMAđấO ......................................... 37

  3.3.1 Ladder Diagram ........................................................................................ 37

  3.3.2 SFC - Sequential Function Chart e Structured Text ................................. 38

  3.4 PROBLEMAS NA IMPLEMENTAđấO ............................................................ 40

  3.4.1 Causalidade ............................................................................................... 40

  3.4.2 Efeito avalanche ....................................................................................... 40

  3.4.3 Incapacidade de reconhecer a ordem dos eventos .................................... 42

  3.4.4 Sincronização inexata ............................................................................... 44

  3.4.5 Escolha ..................................................................................................... 47

  3.5 CONCLUSÃO AO CAPÍTULO .......................................................................... 48

  

4 METODOLOGIA DE IMPLEMENTAđấO DECON9 ............................................. 49

  4.1 APRESENTAđấO DA METODOLOGIA ......................................................... 49

  4.2 ESTUDO DE CASO: LINHA DE TRANSFERÊNCIA INDUSTRIAL ............. 50

  4.2.1 Primeiro passo – Inicialização dos estados .............................................. 52

  4.2.2 Segundo passo – Leitura das entradas ...................................................... 52

  4.2.3 Terceiro passo ........................................................................................... 53

  4.2.4 Quarto passo ............................................................................................. 54

  4.2.5 Quinto passo ............................................................................................. 54

  4.2.6 Sexto passo ............................................................................................... 55

  4.2.7 Sétimo passo ............................................................................................. 56

  4.2.8 Oitavo passo ............................................................................................. 56

  4.2.9 Nono passo ............................................................................................... 57

  4.3 RESULTADOS .................................................................................................... 57

  

5 METODOLOGIA DE IMPLEMENTAđấO EM SFC (VIEIRA, 2007) .................. 58

  5.1 PROPOSTA DE IMPLEMENTAđấO ................................................................ 58

  5.2 REPRESENTAđấO EM SFC ............................................................................. 61

  5.2.2 Implementação dos supervisores, FC MS ................................................ 66

  5.2.3 Implementação do FC OP ........................................................................ 68

  5.3 CÉLULA DE MANUFATURA ........................................................................... 68

  5.3.1 Bloco MS .................................................................................................. 71

  5.3.2 Bloco PS ................................................................................................... 74

  5.3.3 Bloco OP .................................................................................................. 75

  5.4 CONCLUSÃO AO CAPÍTULO .......................................................................... 76

  6 IMPLEMENTAđấO EM SFC COM TRATAMENTO DE MULTIPLOS

EVENTOS NÃO CONTROLÁVEIS .................................................................................... 77

  6.1 CHAMADA DOS BLOCOS ................................................................................ 79

  6.1.1 Bloco PS ................................................................................................... 79

  6.1.2 Bloco MS .................................................................................................. 83

  6.1.3 Bloco OP .................................................................................................. 85

  6.2 SOLUđấO DE PROBLEMAS DE IMPLEMENTAđấO .................................. 86

  6.2.1 Causalidade ............................................................................................... 86

  6.2.2 Efeito avalanche e perda de informação ................................................... 87

  6.2.3 Sincronização inexata ............................................................................... 90

  6.2.4 Problema da escolha ................................................................................. 90

  6.3 CONCLUSÃO DO CAPÍTULO .......................................................................... 91

  

7 COMPARAđỏES ENTRE AS METODOLOGIAS ................................................... 92

  7.1 PRIMEIRO TESTE – DIFERENÇA ENTRE EVENTOS................................... 93

  7.2 SEGUNDO TESTE – EVENTOS NO MESMO CICLO. ................................... 96

  7.3 TERCEIRO TESTE – MONITORAMENTO DE TODOS OS EVENTOS ........ 99

  7.4 TAMANHO DE PROGRAMA .......................................................................... 105

  7.5 TAMANHO DE PROGRAMA COMPARANDO COM CRUZ (2011) ........... 106

  7.6 CONCLUSÃO AO CAPÍTULO ........................................................................ 108

  

8 CONSIDERAđỏES FINAIS ....................................................................................... 109

  8.1 CONCLUSÃO .................................................................................................... 109

  8.2 TRABALHOS FUTUROS ................................................................................. 111

  8.2.1 Divisão do bloco PS ............................................................................... 111

  8.2.2 Sincronização inexata – propriedade 2 ................................................... 111

  8.2.4 Programação em Structured Text ........................................................... 111

  8.2.5 Geração automática de código ................................................................ 111

  

REFERÊNCIAS ................................................................................................................... 113

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 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, 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.

  

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.

2.1.1 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 Σ, 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).

2.1.2 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 2.1 - 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).

2.1.3 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 2.3 - Sincronização G1||G2 com eventos em comum

2.2 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 . 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 , 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.

  2.2.1 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 2.4 - Linha de transferência industrial (QUEIROZ E CURY, 2000)

  2.2.2 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 2.5 - Autômato das máquinas (CRUZ, 2011)

  2.2.3 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,

  2.2.4 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&rdq
  • 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 2.6 - Autômatos das especificações (CRUZ, 2011)

  2.2.5 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,

  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:

  2.3.1 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 || G6.

  2.3.2 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.

  2.3.3 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.

  2.3.4 Cálculo da linguagem controlável SupC(K,G)

  O próximo passo é calcular a linguagem controlável e achar um elemento supremo

  sup C(K,G).

  A abordagem monolítica apresenta duas dificuldades. A primeira consiste no

  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 2.8 - Células de controle 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:

  2.4.1 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.

  2.4.2 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 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 produtoTabela 2.1 - 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||G6

2.4.3 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.

  2.4.4 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),

  Sup C(KC,GLC), SupC(KD,GLD).

  Na Figura 2.11 são apresentados os supervisores locais SlocA, SlocB, SlocC e SlocD.

  

Figura 2.11- Supervisores locais (CRUZ, 2011)

  2.4.5 Teste de modularidade local

  Para que a ação conjunta dos diversos supervisores locais seja não bloqueante, deve- se 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.

  2.4.6 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 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 2.12 - 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.

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 3.1 - 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 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 3.2 - 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.

Figura 3.3 - Processo cíclico do CLP

  A programação de CLPs é normatizada através das normas IEC 61131 (VIEIRA, 2007). Esta série é estruturada nos seguintes volumes:

  • IEC 61131-1 Programmable controllers - Part 1: General information, 2003,

  2nd. ed

  .;

  • IEC 61131-2 Programmable controllers - Part 2: Equipment requirements and
  • IEC 61131-3 Programmable controllers - Part 3: Programming languages,
  • IEC/TR 61131-4 Programmable controllers - Part 4: User guidelines 2004, 2nd. ed.
  • IEC 61131-5 Programmable controllers - Part 5: Communications, 2000;
  • IEC 61131-7 Programmable controllers - Part 7: Fuzzy control programming,
  • IEC/TR 61131-8 Programmable controllers - Part 8: Guidelines for the

  tests, 2003, 2nd. ed. ;

  2003, 2nd. ed. ;

  ;

  2000;

  

application and implementation of programming languages

  , 2003, 2nd. Ed; (VIEIRA, 2007). A norma IEC 61131-3 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

  3.3.2. 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

3.3.1 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.

Figura 3.4 - 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.

3.3.2 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.

Figura 3.5 - Programa em Ladder DiagramFigura 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.

  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.

  3.4.1 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.

  3.4.2 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 3.7 - 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

Figura 3.8 - 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 3.9 - 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

Figura 3.10 - 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 3.11. 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.

3.4.3 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).

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 3.13.

  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.

  

Figura 3.12- Diagrama temporal

Figura 3.13 - Problema da incapacidade de reconhecer a ordem dos eventos

3.4.4 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 3.14. 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

  σ 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 3.14 - 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. σ Σ c c

  ∈ s K σ Σ σ σ Propriedade 1: Uma linguagem K é dita insensível ao atraso se para , Κ u u c u ∈ ∈ ∈ sσ , sσ sσ , sσ K u c c u e , quando então .

  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 3.15 - Propriedade 1 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. *

  Propriedade 2: Uma linguagem K é dita insensível ao entrelaçamento de atraso k se, σ Σ σ Σ Κ σ para s ∈ K , ∈ e , quando sσ , sσ ∈ então sσ K . c c u ∈ u c u ∈ u c É importante observar que os autores apresentam um relaxamento na propriedade σ Κ original de forma que a condição sσ ∈ não é mais exigida nesta definição. Os autores c u 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 ocorre enquanto σ σ u o supervisor habilita , então a sequência sσ não pode ocorrer. Sob o ponto de vista do c c u σ

  S G S G

  controle supervisório, se sσ ∈ L ( / ) mas sσ ∉ L ( / ) pode-se afirmar que σ c c u σ

  

sσ ∉ L ( G ) , ou seja, que o evento não controlável é fisicamente impossível de

c u σ u acontecer na planta após a aplicação da ação de controle . c

  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.

  

Figura 3.16- 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.

3.4.5 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 3.17. Se no estado “0” for sempre dada prioridade ao evento A2, a máquina M4 nunca entrará em operação.

Figura 3.17 - Supervisor SRC

  Outro exemplo é da Figura 3.18. 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 3.18 - Autômato susceptível ao problema da escolha

  Cruz (2011) apresenta uma solução que será vista na seção 4.2.6. Será esta a solução utilizada no presente trabalho.

3.5 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.

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 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 4.2 - 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.

  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 2.12. 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 DECON9.

  4.2.1 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.

  4.2.2 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 4.4 - Parte da sub-rotina de leitura

4.2.3 Terceiro passo

  O terceiro passo é dividido em duas partes. Na primeira parte é chamada uma sub- rotina 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 4.5 - 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.

Figura 4.6 – Eventos não controláveis no subsistema Gi (a) ENC G1; (b) Autômato G1

  4.2.4 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

  4.2.5 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 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

4.2.6 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).

Figura 4.9 – Bloco TRATA ESCOLHA

  4.2.7 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 G1

  4.2.8 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”.

4.2.9 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 4.1 - Resultado da execução do DECON9

  Eventos Não Eventos Ciclo

  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.

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 61131-3.

5.1 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

Figura 5.1 - 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

  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 onde I = {1, 2, ..., n}. A chamada a um determinado subsistema G só

  i ∈ i

  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 5.2 - 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 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.

5.2.1 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 2.4.6.

Figura 5.3 - 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 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 5.1 - 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 5.4 - Bloco FC dg2 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.

  Gi

  Uma variável do tipo Booleana σ é criada para cada evento “σ” Σ , 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,

  Gi Gi σ Σ

  Considerando que qi são os estados, σi são os eventos Σ , dummy , 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 5.6 - Exemplo de autômato da plantaTabela 5.2 - 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 5.7 - 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.

  

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.

Figura 5.8 - SFC para o subsistema G2

5.2.2 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 A4 a4dsrb,

  (y=3)

  1 A3 a3dsrb 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 5.9 - 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.

5.2.3 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á

  

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 5.11 - 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 5.13. Maiores detalhes sobre as especificações podem ser encontrados em (VIEIRA, 2007).Figura 5.12 - RSP para a célula de manufatura (VIEIRA, 2007)Tabela 5.6 - Semântica de estados e eventos (VIEIRA, 2007)

  Autômato Estado Evento G0 0 - repouso A0 - iniciar rotação de 90° 1 - rotacionando B0 - rotação concluída G1 0 - repouso T1 - iniciar classificação

  1 - classificando L1 - classificada e aceita 2 - em pausa M1 - classificada e rejeitada 3 - transportando A1 - iniciar transporte

  B1 - transportada G2 0 - repouso A2 - iniciar furação

  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

5.3.1 Bloco MS

  O bloco MS chama os blocos dos supervisores sequencialmente, como na Figura

  5.14. 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.

  Figura 5.13- Supervisores reduzidos para a célula de manufatura (VIEIRA, 2007)

Figura 5.14 - Parte do Bloco MSFigura 5.15 - FB para o supervisor slb1

5.3.2 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

  (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 G0

5.3.3 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.

  

Figura 5.20- 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.

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 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 6.1.2. A implementação de mais de um evento não controlável no mesmo supervisor será apresentada com detalhes na seção 6.2.2.

Figura 6.1 - 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 evolução, esta condição será abordada na seção 6.1.1. 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 6.1.3.

  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 5.11.

6.1.1 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 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 torna- se verdadeira, (“g0d := true”), caso contrário torna-se falso (“g0d := false”).

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

  σ d

  (se a variável 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).

  σ 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 6.4 - 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 6.1.3. 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 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.

6.1.2 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 6.2.2.

  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.

Figura 6.6 - 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 6.2.2.

  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 6.7 - 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

  

a2dslc1 no supervisor slc1 e a variável a2dslc2 é tratada no supervisor slc2. Todos estes

supervisores podem desabilitar o evento A2.

Figura 6.8 - 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.

  

Figura 6.9- Parte o bloco MS, eventos zerados

6.1.3 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 5.11. 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.

  

Figura 6.10- 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.

6.2.1 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).

Tabela 6.1 – No. de estados e de transições do conjunto de supervisores (VIEIRA, 2007).

6.2.2 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 6.11 - Autômato susceptível ao efeito avalanche

  Na Figura 6.12 temos o SFC da Figura 6.11. Se ocorrer o efeito avalanche neste exemplo, as ações associadas aos passos S2 e S4 não são executadas.

Figura 6.12 - 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 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 tornam- se 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 6.13 - Programa MS

  6.2.3 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.

  6.2.4 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 2.12. 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

Figura 6.14 - 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 6.15. 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 dA4.

Figura 6.15 - Bloco de escolha

6.3 CONCLUSÃO DO CAPÍTULO

  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.

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 317-2. 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 7.1 - TIME_TCK e início do NCiclo No final do bloco OB1 a variável NCiclo é incrementada como visto na Figura 7.2.Figura 7.2 - 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 7.3 - 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.

Figura 7.4 - 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 7.1 - Primeiro teste na planta

  N.Prop. Vieira (2007) Diferença ciclo A5/B5 592,6 310,6 Diferença ciclo B5/T1

  1 Diferença ciclo A5/T1 592,6 311,6 Diferença Tempo A5/B5 3796 ms 3844 ms Diferença Tempo B5/T1 12 ms Diferença Tempo A5/T1 3796 ms 3856 ms 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.

Tabela 7.2 - Primeiro teste simulado no CLP

  5

  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.

  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.

  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.

  5

  1 Diferença ciclo A5/T1

  6 Diferença ciclo B5/T1

  N.Prop. Vieira (2007) Diferença ciclo A5/B5

  N.Prop. Vieira (2007) Diferença ciclo A5/B5

Tabela 7.3 - Primeiro teste simulado no computador

  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

  5

  1 Diferença ciclo A5/T1

  6 Diferença ciclo B5/T1

  5

  Porém, foi acrescentada uma variável para que os processos terminem somente quando o 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 7.5 - 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 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 7.4 - Segundo teste, proposta de Vieira (2007)

  linha ciclo Evento dif.ciclo 1 28047 rspb1 2 28048 B1

  1 3 33544 rspb1 5496 4 33545 B1

  1 5 39002 rspb2 5457 6 39003 B2

  1 7 53186 rspb1 14183 8 53186 rspb2 9 53186 rspb3

  10 53187 B1

  1 11 53188 B2 1 12 53189 B3

  1

  13 72337 rspb2 19148 14 72338 B2

  1 Na nova proposta, as respostas rspb1, rspb2 e rspb3 são incrementadas no mesmo ciclo (ciclo de número 216595) 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.

Tabela 7.5 - Segundo teste, nova proposta

  linha ciclo Evento dif.ciclo 1 87028 rspb1 2 87029 B1

  1 3 116040 rspb1 29011 4 116041 B1

  1 5 164784 rspb2 48743 6 164785 B2

  1 7 216595 rspb1 51810 8 216595 rspb2 9 216595 rspb3

  10 216596 B1

  1 11 216596 B2 12 216596 B3

  13 228217 rspb2 11621 14 228218 B2

  1

7.3 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

  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).

  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 5.310 ciclos em 34.350 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 2.717 ciclos em 33.946 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.

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,6 3818 B5 308 3868 T1

  3 L1 248,4 1602 T1

  1

  10 A1

  4 B1 481,8 3106 L1 129,6 1618 A0 A5

  4

  5 B0 552,4 3560 A1

  1

  10 A2

  30

  6 B5 21,2 114 B1 214,4 2670 T1

  50

  7 B2 37 188 A0

  1

  12 A0 526 A5

  8 L1 408 2282 B0 283,6 3540

  9 B0 138,6 712 A2

  1

  12 A1

  4

  10 A3

  1

  4 B5 16,6 208

  11 B3 71 462 T1

  1

  12

  12 B1 367 2368 B2 15,2 192 A0

  6 A5

  13 B0 546,2 3520 A0

  1

  10 A2

  2 A4

  14 B5 31,8 208 L1 213,8 2672 T1

  4

  15 B2 27,8 176 B0 69,4 862

  16 B4 254,6 1644 A1

  1

  10 A0

  2

  17 L1 208 1360 A3

  1

  10

  18 B0 338,6 2196 B3 38,8 482 A1

  2

  19 A3

  1

  8 B1 183,4 2286

  20 B3 73 476 A0

  1

  10 A5

  2 A5

  2

  1

  12 No monitoramento de todos os eventos feito sobre simulações do programa no CLP e

  3

  36 A2

  

35 B0 281,2 3528

  14 A5

  1

  34 A0

  

33 B1 181 2264

  32 B3 40 500

  10

  1

  31 A3

  12

  30 A1

  22 B0 547,80 3546 A2

  

29 B0 173,6 2172

  

28 L1 108 1360

  10

  1

  27 A0

  

26 B4 128,8 1608

  

25 B2 14,2 118

  70

  1

  24 T1

  

23 B5 19,6 246

  2 A4

  12 A2

  1

  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

Tabela 7.7 - Terceiro teste – simulado

  1

  1

  1 B1 5,4

  1 B1 6,25 1 11,5

  1 B3 4,2 1 10,67

  1 B3 6,25 1 10,5

  1 A3 3,8 1 11,33

  12

  1

  1 A1 1,4 A3 8,25

  13

  1 L1 3,8 A1 8,25

  1 A0 7,75 1 12,5

  11

  1

  3 B0 5,75

  2 B0 11,4 3 34,67

  2 L1 14,25 2 23,5

  

1 A0

  12

  1

  8

  1 A0

  12

  1 A0 2,4 A5 0,5 A5 0,8 B0

  11

  1 B5 9,4 2 23,33

  3 B0 13,5 2 23,5

  15 3 34,33

  

1 B0

  2 A0 1,8 L1 6,5 1 11,5

  1 B4 0,25 B4 0,2 A0 15 2 23,5

  11

  1

  1 B2 3,8

  1 T1 0,8 B2 6,25 1 11,5

  2 T1 8,25 1 11,5

  7 1 11,5

  20

  1 B5

  1 A2 4,6 A4 0,25 0,5 A4

  12

  1

  3 A2 7,25

  34

  3

  3 B0 11,4

  34

  3

  1 B2 2,8 1 10,67

  1

  a) Vieira (2007)

  5 T1 8,25

  12

  1

  4 A1 7,5

  44

  4

  13

  

4 L1

  1 T1 2,6 L1 29,25 4 48,5

  12

  1

  53

  4 B1 21,5 3 35,5

  5

  19

  

6 B5

  70

  6

  A5 A5 B5 41,25

  (ms) Dif.Ciclo Dif.Tempo (ms) Dif.Ciclo

  (ms) Dif.Ciclo Dif.Tempo (ms) Dif.Ciclo Evento Dif.Tempo

  CLP Computador CLP Computador Evento Dif.Tempo

  b) Nova Proposta

  

1 A1

  3 B1 9,8

  6

  1

  1 T1 2,6 B2

  8 1 12,5

  2 T1

  24

  2

  1 B5 7,8

  12

  1

  1 A2 4,4 B5 7,25

  11

  7

  3

  3 A2

  34

  3

  3 B0 11,2

  20 3 34,5

  1 A0 3,6 A5 0,25 0,5 A5 0,8 B0

  12

  1

  3 A0 7,5

  33

  2 L1 0,6 A3

  8

  1

  12

  1 A3 4,6 1 11,67

  1 B3 6,25

  1

  11

1 B3 3,4

  1

  11

  1 B1 6,5 1 11,5

  1 B1 6,2 1 11,67

  1 A0 7,5 1 11,5

  1 A0 1,6 A5 0,5

  1 A5 0,4 Total 349,25 49 577

  49 Total 183,4 36 404,3

  36

7.4 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.

Tabela 7.8 - Tamanho do código, comparação com a proposta de Vieira

  

Vieira (2007) Nova Proposta Diferença

Tamanho Tamanho Tamanho Bloco (bytes) Bloco (bytes) (bytes) G0

  • 6 858 G0 852 G1
  • 18 1494 G1 1476 G2
  • 18 1218 G2 120
  • 6 1134 G3 1128 G4
  • 12 1046 G4 1034 G5
  • 18 1280 G5 1262 PS (LAD) 530 PS (SCL) 716 dg0

  50 dg1 50 dg2 48 dg3 50 dg4 46 soma 818 soma -102 dg5

  44 716 502 MS (LAD) 568 MS (SCL) 1070

  • 66 action_Sup 240 action_Sup 174 9270 256 Total

  9014 Total Symbols Total 168047 Total

159033 Symbols 159033

168303 256

7.5 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

  Tabela 7.9- Tamanho do código, comparação com a proposta de Cruz (2011) Cruz (2011) Nova Proposta Diferença

  48 DB 458 soma 96 soma 756 660 ENC G6

  46 TRATA ESCOLHA

  510 TRATA ESCOLHA

  46 DB 402 soma 94 soma 604

  48 SRD 202 EC SD

  62 DB 508 soma 120 soma 710 590 ENC SD

  58 SRC 202 EC SC

  608 ENC SC

  46 DB 402 soma 94 soma 702

  48 SRB 300 EC SB

  46 DB 402 soma 94 soma 604 510 ENC SB

  48 SRA 202 EC SSA

  660 ENC SSA

  48 DB 458 soma 96 soma 756

  48 G6 298 EC G6

  48 G5 298 EC G5

  Bloco Tamanho (bytes) Bloco Tamanho

  48 DB 458 soma 96 soma 756 660 ENC G2

  (bytes) Tamanho (bytes) OB1 232 OB1

  88 -144 DESABILITAđỏES

  74 MS2 (SCL) 590 ATUALIZA

  86 PS2 (SCL) 592 action_Sup 240 soma

  392 soma 1510 1118 ENC G1

  48 G1 298 EC G1

  48 G2 298 EC G2

  660 ENC G5

  48 DB 458 soma 96 soma 756

  660 ENC G3

  48 G3 298 EC G3

  48 DB 458 soma 96 soma 756 660 ENC G4

  48 G4 298 EC G4

  48 DB 458 soma 96 soma 756

  46

  8712 7296 1416 Total Total 67119 Total c/ 49710 -17409 Total c/ Symbols Symbols

7.6 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.

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 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

  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.

  8.2.1 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.

  8.2.2 Sincronização inexata – propriedade 2

  Basile e Chiacchio (2007) apresentam a propriedade 2, como visto na seção 3.4.4. 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 2.

  8.2.3 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.

  8.2.4 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.

  8.2.5 Geração automática de código 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, 2
  • DES2ST, 2012;
  • DESTool, 2012 .

  

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. 522-527, San Antonio, Texas (USA), September, 2008.

  BASILE, F.; CHIACCHIO, P.; On the Implementation of Supervised Control of Discrete Event Systems. In: Transactions on Control Systems Technology. Vol.15, no. 4, 2007. CASSANDRAS, C.G.; LAFORTUNE S.; Introduction to Discrete Event Systems. Kluwer Academic Publishers. USA, 1999. CGLI, disponível em <http://www.das.ufsc.br/~lellis/Arq_Prof/CGLI/> acessado em abril de 2012. 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. 284-289, ISSN 1094-6977. CURY, J. E. R; Teoria de Controle Supervisório de Sistemas a Eventos Discretos. V Simpósio Brasileiro de Automação Inteligente. Canela-RS, 2001. CURZEL, J. L.; 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, 2008. 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, 2011.

  DES2ST, disponível em < http://sourceforge.net/projects/ides2st/> acessado em abril de 2012. DESTool, disponível em <http://www.rt.eei.uni-erlangen.de/FGdes/destool/index.html> acessado em abril de 2012. 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. 185-201, 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. 3305- 3310. 1998.

  FLORDAL, H.; MALIK, R.; Nonblocking Verification Using Conflict Equivalence. In: 8th International Workshop on Discrete Event Systems (WODES), p. 100-106. Ann Arbor. 2006. HASDEMIR, T.; KURTULAN, S.; GÖREN, L.; An Implementation Methodology for Supervisory Control Theory. The International Journal of Advanced Manufacturing Technology, v. 03. n. 03-04 p. 373-385. 2008. HELLGREN, A.; 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. 1-6. ISBN: 0-7695-1683-1. 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. 91-101., 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. 899- 905. 2009. 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. 1-24. 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. 519-528, University of Illinois, 1995. 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. 383-389. ISBN: 0-7695-1683-1. Zaragoza, Spain, October 2002. MALIK, P.; Generating Controllers from Discrete-Event Models. In: F. Cassez, C jard, F. Laroussinie, M. D. Ryan, Proc of the MOVEP, pp. 337-342 2002. MANESIS, S.; AKANTZIOTIS, K. (2005). Automated synthesis of ladder automation circuits based on state-diagrams. Advances in Engineering Software, 36, pp .225–233. 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. 819-826, Palma de Mallorca, 2009.

  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, 2004.

  QUEIROZ, M. H. de; CURY, J. E. R.; Modular supervisory control of large scale discrete event systems. In: Proceedings of the 5th International Workshop on Discrete Event Systems: Analysis and Control. Ghent, Belgium: Kluwer Academic Publishers, p. 103-110. 2000. ________; Synthesis and implementation of local modular supervisory control for a manufacturing cell. In: 6th International Workshop in Discrete Event Systems. Zaragoza, Spain: Kluwer Academic Publishers, p. 377-382. 2002. 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. 2001. RAMADGE, P. J.; WONHAM, W. M.; The control of discrete event systems, Proc. of IEEE, Special Issue on Discrete Event Dynamic Systems, v. 77, n. 1, p. 81-98. 1989.

  TEIXEIRA, C. A.; Aplicação da Teoria de Controle Supervisório no Projeto de Controle para Eletrodomésticos. Dissertação (Mestrado em Engenharia Elétrica) – Universidade do Estado de Santa Catarina. Joinville, 2008.

  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.

Novo documento

Tags

Documento similar

UNIVERSIDADE FEDERAL DE UBERLÂNDIA – UFU FACULDADE DE ENGENHARIA ELÉTRICA – FEELT PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
0
0
156
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS AGROVETERINÁRIAS – CAV PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIAS AGRÁRIAS MESTRADO EM PRODUÇÃO VEGETAL
0
0
95
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS AGROVETERINÁRIAS – CAV PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIAS AGRÁRIAS MESTRADO EM PRODUÇÃO VEGETAL
0
0
57
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS AGROVETERINÁRIAS – CAV PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIAS AGRÁRIAS MESTRADO EM PRODUÇÃO VEGETAL
0
0
81
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS AGROVETERINÁRIAS – CAV PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIAS AGRÁRIAS MESTRADO EM PRODUÇÃO VEGETAL
0
0
75
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE ARTES – CEART PROGRAMA DE PÓS-GRADUAÇÃO EM MÚSICA – MESTRADO (PPGMUS)
0
0
92
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS DA EDUCAÇÃO – CCEFAED MESTRADO EM EDUCAÇÃO E CULTURA
0
0
11
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS DA EDUCAÇÃO – CCEFAED MESTRADO EM EDUCAÇÃO E CULTURA
0
0
150
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS DA EDUCAÇÃO – CCEFAED MESTRADO EM EDUCAÇÃO E CULTURA
0
0
97
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS DA EDUCAÇÃO – FAED
0
0
169
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS DA EDUCAÇÃO – FAED
0
0
161
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS HUMANAS E DA EDUCAÇÃO – FAED PROGRAMA DE PÓS-GRADUAÇÃO EM EDUCAÇÃO – MESTRADO
0
0
137
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT MESTRADO EM EDUCAÇÃO E CULTURA
0
0
80
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS AGROVETERINÁRIAS – CAV MESTRADO EM CIÊNCIAS VETERINÁRIAS
0
0
69
UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC CENTRO DE CIÊNCIAS AGROVETERINÁRIAS – CAV MESTRADO EM CIÊNCIAS VETERINÁRIAS
0
0
85
Show more