Terrorhandlinger

Os Controladores Lógicos programáveis (CLPs) são dispositivos de controle especializados em controles lógicos de sistema automáticos ou semiautomáticos. Conforme apresentado por Brandin (1996), esses dispositivos são projetados para trabalhar em ambientes industriais em condições adversas de temperatura, umidade, ruído e vibração. São muitas vezes programados em linguagem ladder, também conhecida por lógica de contato, uma vez que esse tipo de linguagem é associado a dispositivos elétricos, como contatos e bobinas. A linguagem ladder é uma linguagem gráfica, em forma de diagrama, que está definida na IEC 61131-3 (IEC, 2003), norma internacional de programação de CLP, que

define outras quatro linguagens de programação. Na Tabela 4.1 apresentam-se as funções básicas da linguagem ladder abordadas pela IEC 61131-3.

Tabela 4.1 – Comandos ladder abordados pela IEC 61131-3

SÍMBOLO NOME DESCRIÇÃO

-| |- Contato NA Contato normalmente aberto -|\|- Contato NF Contato normalmente fechado

-(S) Liga bobina É ligada quando a linha está energizada e permanece ligada até que seja desligada em outra parte do código.

-(R) Desliga bobina É desligada quando a linha está energizada e permanece desligada até que seja ligada em outra parte do código.

-( ) Energiza bobina Permanece ligada enquanto a linha está energizada.

Ao longo dos anos os CLPs se mostraram muito versáteis, e suas aplicações só têm aumentado, assim como sua capacidade de lidar com controles mais complexos, como controle PID e controle hierárquico de plantas inteiras. No entanto, a sua herança original ainda influencia seu comportamento (FABIAN e HELLGREN, 1988), seja na linguagem de programação, como apresentado anteriormente, ou seja, na forma de processamento do código. A forma de processamento do programa pelo CLP consiste em executar um único programa sequencialmente do início ao fim repetidamente. Em cada ciclo de processamento, (também conhecido como ciclo de varredura) o CLP lê os valores das entradas, processa a lógica programada e ao final escreve nas saídas os novos valores estabelecidos.

O modelamento de um autômato em liguagem ladder, consiste em representar cada estado e cada evento com variáveis internas, ou seja, bits de memórias (boolean), onde o estado atual é dado pela memória que está assumindo o valor 1 e as memórias dos demais estados estarão com o valor 0. Os eventos são identificados por borda de subida ou descida dos bits, onde uma borda é detectada através da comparação de valor lógico entre o ciclo atual e o anterior. A borda de subida é quando o valor muda de 0 para 1 (falso para verdadeiro), já a borda de descida o valor muda de 1 para 0 (verdadeiro para falso).

O modelamento das transições é realizado por meio da lógica binária “e” (AND) juntamente com os comandos de ligar (SET) e desligar (RESET), apresentados anteriormente. Na Figura 4.1 a lógica “e” se dá entre a memória que representa o estado atual (G0.0) com a memória que representa o evento que promove a transição (A). Quando o resultado da operação “e” for satisfatório o próximo estado é definido ao ser ligada a memória que representa o próximo estado (G0.1) e desligada a memória que presenta o estado atual (G0.0) (HASDEMIR, KURTULAN, GÖREN, 2008). Assim, segundo Fabian e Hellgren (1998), na

implementação da estrutura de controle supervisório em Controladores Lógicos Programáveis (CLPs), deve-se fazer com que o CLP se comporte como uma máquina de estados.

Figura 4.1 – Modelamento em ladder da transição do autômato

4.3 PROBLEMAS NA IMPLEMENTAÇÃO DA TCS EM CLP

A TCS considera que a evolução da planta é dirigida pela ocorrência de eventos discretos, os quais possuem natureza instantânea (tempo de duração nulo) e assíncrona (apenas um evento ocorre a cada instante). Por outro lado, a planta real e o seu elemento de controle (CLP) têm sinais que estão sempre presentes nas entradas e saídas, só havendo mudança em seus valores. Assim, na implementação de supervisores em CLPs é preciso associar as mudanças nos valores destes sinais à ocorrência de eventos discretos e estabeler uma interação entre planta e supervisor, porém ambos devem trabalhar em sincrônia.

Porém, uma vez definido que ageração de eventos será dada a partir da alteração dos sinais, consequentimente esse processo de identificação dos enventos é realisado pelo CLP de forma ciclica no início e no término de cada ciclo de varedura. Caso a planta gere dois envetos durante um cilco de varedura do CLP, o sistema pode interpretar que os eventos ocorreram simultaneamente. Uma vez violando uma premissa da TCS podem-se ter complicações no controle da planta. E os atrasos, provenientes da atualização periódica do CLP, pode romper a sincronia entre planta e supervisor.

Outro ponto que deve ser considerado, é que a TCS assume que a planta gera todos os eventos (controlaveis ou não controlaveis), e o supervisor apenas promove a desabilitações dos eventos controlaveis, restringindo minimamente o comportamento da planta. Por outro lado, em uma plicação prática, alguns eventos são gerados na planta física e outros são gerados pelo CLP, a partir dos acionamentos resultantes das alterações dos sinais de saídas.

Assim, a implementação da TCS em CLP, não é trivial e pode levar a alguns problemas que serão apresentados a seguir.

4.3.1 Causalidade

A TCS assume que todos os eventos são gerados espontaneamente pela planta e que os supervisores devem apenas estabelecer as desabilitações dos eventos controláveis a serem gerados pela planta. A Figura 4.2 ilustra uma arquitetura de controle supervisório em conformidade com está hipótese. Observe que o papel dos supervisores é estabelecer as desabilitações dos eventos controláveis em conformidade com Ramadge e Wonham (1989).

Figura 4.2 – Arquitetura para TCS segundo Ramadge e Wonham (1989)

Porém, em uma aplicação prática os eventos controláveis não são gerados espontaneamente pela planta física, mas são respostas a comandos do CLP (MALIK, 2002). A Figura 4.3 ilustra uma arquitetura mais próxima da realidade onde o controlador, ou seja, o CLP recebe informações do estado da planta física através de sensores ligados nas entradas e atua no controle da planta ativando ou desativando saídas.

Figura 4.3 – Arquitetura realística

Desse modo, a implementação deve responder à seguinte questão “Quem gera o que?” (FABIAN e HELLGREN, 1998), ou seja, quem será responsável pela geração de cada evento: a planta ou o CLP.

Para atender fielmente a hipótese de Ramadge e Wonham (1989) de que os eventos são espontaneamente gerados pela planta e de que o supervisor apenas desabilita eventos controláveis, deve ser implementado no CLP o sistema produto (SP) como proposto por Queiroz e Cury (2002). Nesta estrutura os autômatos que representam os subsistemas assíncronos (representação por sistema produto) são implementados no CLP e são responsáveis pela geração dos eventos controláveis. Assim todos os eventos são gerados no sistema produto e os supervisores mantêm a função original de apenas estabelecer as

desabilitações dos eventos controláveis. A Figura 4.4 ilustra a arquitetura do sistema de controle e a planta de acordo com a proposta de Queiroz e Cury (2002).

Figura 4.4 – Arquitetura proposta por Queiroz e Cury (2002) 4.3.2 Efeito avalanche

O efeito avalanche ocorre quando a mudança do valor no CLP é registrada por meio de um evento e este provoca a transição indevida de mais de um estado do sistema num mesmo ciclo de varredura do CLP. Resultando na quebra de sincronia entre a planta e o supervisor implementado no CLP e, consequentemente, as futuras ações de controle serão inválidas. A Figura 4.5 apresenta o autômato de uma determinada planta G0 que, dependendo da forma em que for implementado no CLP, pode provocar o efeito avalanche. Note que a ocorrência do evento A no estado 0 deve fazer com que o autômato transite para o estado 1, ficando neste estado até uma nova ocorrência do evento A, ou a ocorrência do evento B.

Figura 4.5 – Autômato que proporciona o efeito avalanche

Na Figura 4.6 é apresentado um exemplo de código de CLP que poderia ser usado para a implementação do autômato da Figura 4.5. Neste programa, G0.i representa o estado i de G0 e A0.2 e B0.2 representam os eventos A e B, respectivamente. Veja que da forma em que foi descrito o código do CLP, a ocorrência de um único evento A no estado 0 provoca duas transições de estado, levando o programa para o estado 2 do autômato.

Figura 4.6 – Código do CLP que mostra o efeito avalanche

Uma forma de solucionar esse problema, conforme Queiroz, Santos e Cury (2001), é controlar a execução do CLP para que apenas um evento seja tratado a cada ciclo de varredura, limitando o desempenho do CLP. Entretanto, esta solução se mostra inadequada

para a metodologia proposta neste trabalho, uma vez que a intenção é tratar o maior número de eventos em um mesmo ciclo de varredura do CLP.

Outra proposta para solucionar esse problema é apresentada por Fabian e Hellgren (1998), onde a estrutura lógica associada a cada transição de estados deve ser implementada em ordem reversa ao autômato. Assim, para o autômato apresentado na Figura 4.5, o código a ser implementado no CLP é ilustrado na Figura 4.7. Porém, essa abordagem pode não funcionar para alguns modelos de autômatos, ou seja, está solução só deve ser aplicado para os autômatos que não apresentem ciclos na estrutura de transição (HASDEMIR, KURTULAN, GÖREN, 2008).

4.3.3 Simultaneidade

O problema chamado de simultaneidade também conhecido como incapacidade de reconhecer a ordem de eventos não controláveis, não está relacionada com a forma em que é realizada a implementação, e sim com a forma em que é realizado o processamento do CLP. Devido à natureza cíclica de execução do programa do CLP, no qual a leitura dos seus sinais de entrada é feita somente no início de cada ciclo de varredura. A ocorrência dos eventos não controláveis da planta é identificada pelo CLP, a partir da alteração do valor dos sinais de entrada. Assim, se entre uma leitura e outra das entradas, houver a mudança de valor de dois ou mais sinais, haverá o registro simultâneo de ocorrência de eventos não controláveis. Note que esta mudança nos sinais pode ser simultânea ou não, mas ela é registrada num mesmo ciclo de varredura.

Entretanto, devido a natureza assíncrona dos modelos usados na TCS, não se tem como representar a ocorrência simultânea de eventos. Para melhor ilustrar este problema, considere a Figura 4.8. Note que na leitura das entradas feita em um k-ésimo ciclo de varredura do CLP, as entradas 0 e 1 do CLP não estão ativas, mas durante este ciclo de varredura ocorre uma mudança de nível no sinal da entrada 1 e logo em seguida ocorre uma mudança de nível do sinal da entrada 0. No início do próximo ciclo de varredura é realizada uma nova leitura das entradas e estas mudanças são detectadas, porém o programa do CLP é incapaz de identificar qual das mudanças aconteceu primeiro, o que é conhecido na literatura como incapacidade de reconhecer a ordem de eventos não controláveis (FABIAN e HELLGREN, 1988).

Figura 4.8 – Processamento cíclico da leitura das entradas do CLP

Assim, para que o problema, descrito anteriormente, não se manifeste é necessário que o sistema tenha a propriedade da insensibilidade ao entrelaçamento, conforme apresentado por Fabian e Hellgren (1988).

A Figura 4.9 apresenta um autômato que evidencia esse problema. Estando no estado 1 a ordem da ocorrência dos eventos B e C leva o sistema a estados diferentes, sendo que em cada um dos estados alcançados tem-se uma ação de controle diferente.

Figura 4.9 – Autômato que evidencia o problema de insensibilidade ao entrelaçamento 4.3.4 Sincronização inexata

Durante a execução do programa pode haver uma mudança em algum sinal de entrada do CLP e, neste caso, esta mudança só será reconhecida no início do próximo ciclo de varredura. Assim, pode-se dizer que a comunicação entre a planta e o CLP é sujeita a atrasos devidos a atualização periódica dos sinais de entrada do CLP (BALEMI, 1992).

Segundo Fabian e Hellgren (1998), a sincronização inexata pode ser um problema quando uma mudança num sinal de entrada do CLP invalida a ação de controle (geração de um evento controlável).

Para ilustrar este problema, considere o autômato e o diagrama temporal mostrados na Figura 4.10. Considere que num dado ciclo de varredura o programa do CLP esteja no estado 1 deste autômato e que na leitura-k das entradas do CLP não tenha sido identificada nenhuma mudança no sinal de entrada associado ao evento não controlável C. Suponha ainda que durante a execução do programa é tomada a decisão de gerar o evento controlável B, porém, antes de terminar o ciclo de varredura do CLP com a escrita k+1 (antes, portanto de ter havido uma mudança no sinal de saída do CLP devido ao evento B) ocorra a mudança na entrada do CLP referente ao evento C, invalidando então a ação de controle B para a escrita k+1. Neste caso, o supervisor aplicou uma ação de controle inadequada em função de uma perda de sincronismo entre a planta real e o programa de controle.

Figura 4.10 – Ilustração do problema da sincronização inexata

Note que a incapacidade de reconhecer a ordem de eventos não controláveis, apresentado anteriormente é diferente da sincronização inexata. A primeira está relacionada com a incapacidade do CLP, determinar a ordem em que os eventos não controláveis ocorrerão no intervalo de duas leituras consecutivas. Já a segunda está relacionada a não observação da ocorrência de um determinado evento não controlável, ao mesmo tempo em que se toma a decisão de gerar um evento controlável.

Também é importante salientar que esses dois problemas não são gerados apenas quando se utiliza a TCS para obter o código do CLP, esses problemas são provenientes do modo cíclico de processamento do código pelo CLP. É possível que esses problemas possam ser manifestados em uma solução obtida de forma empírica. Assim, para uma solução convencional se faz necessário a realização de teste da lógica de controle para uma possível detecção da existência do problema.

4.3.5 Escolha

Tendo em vista que os supervisores obtidos por intermédio da TCS são minimamente restritivos, após a ocorrência de uma determinada sequência de eventos, pode haver múltiplas opções para prosseguir no comportamento da planta. Assim, quando o sistema de controle é responsável pela geração de uma parcela de eventos, a decisão sobre qual será o próximo evento a ser gerado é compartilhada entre o sistema a ser controlado e o sistema de controle. De acordo com Fabian e Hellgren (1998), no intuito de evitar uma série de problemas, “a implementação tem que simultaneamente escolher e transitar; e somente um evento deve ser escolhido”, ou seja, apenas um evento controlável deve ser gerado em cada ciclo de varredura do CLP.

A Figura 4.11 apresenta um autômato de um supervisor hipotético S1, que proporciona o problema da escolha. Após a transição do estado 0 para o estado 1 o supervisor deve decidir qual será o próximo passo, gerar o evento B e transitar para o estado 2 ou gerar o

evento C e transitar para o estado 3. Esta escolha deve ser feita uma vez que os dois eventos estão aptos a ocorrer e o sistema não pode gerar os dois eventos e estar em dois estados ao mesmo tempo.

Figura 4.11 – Autômato para ilustrar o problema da escolha

A proposta apresentada por Fabian e Hellgren (1998) consiste em selecionar apenas um evento entre as opções existentes, essa escolha pode ser intencional ou não, para o autômato apresentado na Figura 4.11, o código ilustrado na Figura 4.12, prioriza a execução de um evento em detrimento a outro(s), o que, de acordo com Malik (2002), pode fazer com que uma parcela do comportamento do sistema deixe de ser realizada e é possível até que essa escolha leve ao bloqueio do sistema mesmo tendo-se supervisores não bloqueantes.

Considere por exemplo um supervisor representado pelo autômato da Figura 4.13. Se no estado 1 for dada prioridade para o evento C com relação ao evento B, o sistema nunca alcançará o estado 2, tornando se uma ação bloqueante já que não será completada uma tarefa (sinalizada no estada 2). Por outro lado, se a prioridade for para o evento B, o supervisor jamais alcançará os estados 3 e 5, o que levará parte do sistema a ficar inoperante.

Figura 4.13 – Supervisor não bloqueante cuja implementação pode ser bloqueante

4.4 CONSIDERAÇÕES SOBRE IMPLEMENTAÇÕES

Fabian e Hellgren (1998) abordam a implementação da TCS em CLPs, porém sem uma metodologia definida para um projeto como um todo, e nem todos os problemas são solucionados de forma genérica (HASDEMIR, KURTULAN, GÖREN, 2008).

Em (QUEIROZ e CURY, 2002b) e (QUEIROZ, 2004) é apresentada uma implementação da TCS em CLP utilizando a linguagem ladder, para um tipo especifico de modelo de autômato, onde para cada evento controlável deve existir um evento não controlável de resposta, por fim, o código do CLP está estruturado por uma única rotina o que dificulta o entendimento e não é apresentada uma metodologia para realizar a seleção de eventos controláveis quando se tem o problema da escolha.

Assim, segundo Vieira (2007) esses pontos levantados se tornam uma limitação, e contra partida, o autor apresenta uma metodologia de implementação, onde o código é organizado em blocos de funções (Function Blocks) o que prevê diversos modos de operações (automático, manual e falhas), porém é utilizada uma linguagem de alto nível Sequencial Function Chart (SFC), que não é muito difundido entre os programadores de CLP, outro agravante é que se faz necessário alterar o modelamento do autômato de modo a remover os auto-laços (self-loops) e o autor não apresenta uma solução para o problema da escolha.

5 METODOLOGIA PARA IMPLEMENTAÇÃO DA TCS EM