Uma Arquitetura para Implementação de ControleSupervisório de Sistemas a Eventos Discretos

Elmo Domingues Martins'José Eduardo Ribeiro Cury'

Laboratório de Controle e Microinformática (LCMI)Departamento de Engenharia Elétrica - EELUniversidade Federal de Santa Catarina

Caixa Postal 476 88040-900 Florianópolis SC - Brasillelmo@lcmi .ufsc.br2cury@lcmi.ufsc.br

Abstract: In this paper we show that, when modeling a Discrete Event System (DES) describing eventsin the supervisor model as commands of the physical leveI, the use of the Ramadge and Wonham 'sclassical theory for constructing supervisors may give incorrect solutions . We then propose amethodology to deal with real DES that encompasses the analysis of the nature of events used to modelsuch systems, and also a physical arquitecture to suport the ideas presented in this work .

Resumo: Este artigo mostra que, ao modelar um Sistema a Eventos Discretos utilizando um mapeamentodireto de eventos do modelo supervisório em comandos da planta, o uso da teor ia clássica de Ramadge eWonham para a síntese de controladores pode levar a soluções não plausíveis . Propõe-se então umametodologia para tratar sistemas reais a eventos discretos , que abrange a análise da natureza dos eventosutilizados ao modelar tais sistemas, bem como uma arquitetura física que suporte as idéias aquiapresentadas.

1. IntroduçãoA teoria de controle de Sistemas a Eventos Discretosbaseada em autômatos ocupa hoje uma posiçãoimportante no contexto do estudo desta classe desistemas. Desenvolvida inicialmente por Wonham eRamadge [1] , esta teoria proporciona métodos eferramentas para modelagem, análise e síntese decontroladores.No entanto, a aplicação prática desta teoria não

tem sido tratada com a mesma ênfase . Poucos são ostrabalhos que propõe a implementação de malhas ouarquiteturas físicas de controle, como por exemplo aarquitetura proposta em [3 ] . Ainda assim, estestrabalhos não abordam aspectos importantes como : omapeamento entre os eventos físicos da planta e oseventos tratados a nível de supervisor (controlador);as decisões que devem ser tomadas para tratar o não-determinismo; a execução em tempo-real, etc;

Todas estas questões surgem a partir do momentoem que se deseja controlar um sistema real. Taissistemas possuem características próprias , queádicionam ao problema de síntese de controle umasérie de variáveis normalmente não tratadas na teoria.

Este trabalho tem o objetivo de fornecer umasolução clara e bem definida para a modelagem de

sistemas reais utilizando autômatos, de forma apossibilitar a construção de um modelo que sejarealizável na prática , e também propor umaarquitetura física que suporte as idéias aquiapresentadas .

2. PreliminaresNum sistema a eventos discretos controlado, existemno mínimo 2 elementos básicos : a planta (sistema aser controlado) e o supervisor (controlador). A planta,localizada no nível físico, interage com o nívelsupervisor através de atuadores e sensores.

Assim, os eventos no nível físico, ou representamcomandos especificos aos atuadores (ex .: mover agarra do robô do ponto "a" para o ponto "b"), ourepresentam sinais de sensores (ex. : sensor 2sensibilizado por uma peça).

O supervisor, por outro lado, necess ita conhecer ocomportamento da planta para que possa atuar sobre osistema em momentos bem determinados. Estecomportamento é descrito no nível de supervisãoatravés' de um modelo ou, formalmente , um geradorda planta.

Portanto, de um lado existem eventos queacontecem fisicamente na planta, que são comandosaplicados a atuadores ou sinais de sensores. De outro

184

lado, no nível de supervisão, existem eventos descritosno modelo da planta, que fornecem ao supervisor adinâmica do comportamento do sistema. Estes últimoseventos devem ser classificados, segundo [1] , emcoritroláveis (conjunto L c), que podem ser habilitadose desabilitados pelo supervisor, e em não-controláveis(conjunto L II ) , sobre os quais o supervisor não possuicontrole.

Para que o todo o sistema (planta + supervisor)funcione harmoniosamente, deve existir ummapeamento entre os eventos que acontecem no nívelfísico, e os eventos controláveis e não-controláveisdescritos no modelo da planta, no nível de supervisão.Logo, a questão que se coloca é a seguinte: "Qual arelação entre os eventos descritos no modelo da plantae os eventos que fisicamente ocorrem na planta?".

Este mapeamento depende da forma como a plantaé modelada.

Usualmente, ao modelar o comportamento de umsistema real, a tendência é mapear diretamente todosos comandos e sinais de sensores em eventos nomodelo.

No entanto, esta técnica de modelagem pode levara problemas ao se tentar solucionar a questão desíntese de supervisor para um caso real, utilizando-sea teoria clássica [1].

O exemplo a seguir visa mostrar claramente oproblema encontrado.

3. Um exemplo ilustrativoO sistema abaixo é parte de uma mini-célula demanufatura localizada no Laboratório de Controle eMicrolnformática da Universidade Federal de SantaCatarina.

Este pequeno sistema é composto por uma estaçãode espera e um buffer, ligados por uma esteira, comomostra ajigura J.

Pallet si\ m ;steira

Estaçãode espera

Ax

figura 1 - Sistema Estação de Espera + Buffer

A estação de espera é composta por um atuadorpneumático Ax ' SI e S2 são sensores óticos quedetectam a passagem de "pallets",

Quando um "pallet" chega a estação de espera, oufica parado (atuador Ax estendido) ou passalivremente pela estação (atuador Ax recolhido), sendocarregado pela esteira para outras partes da mini-célula. Quando um "pallet" passa na frente de um

sensor, este fica sensibilizado, ou caso contrário, osensor está "livre". O "buffer" é, neste caso, o espaçoexistente entre os sensores SI e S2'

3.1 A modelagem utilizando a teoria clássicaAo modelar o sistema acima, utilizou-se ummapeamento direto de eventos do supervisor emeventos do nível físico . O comando de estender oatuador Ax foi mapeado no evento "trancar"; ocomando de recolher o atuador Ax foi mapeado noevento "liberar"; o sinal de sensibiliação do sensorSJ foi mapeado no evento "Son"; e o sinal indicandoo jim da passagem de um "pallet" por SJ foi mapeadono evento "Soff" .

O modelo escolhido para a estação de espera foiinicialmente aquele mostrado najigura 2.

510n

Q) 510" )@

figura 2 - Modelo que representa o comportamento livre da"estação de espera"

Nota-se que este modelo reflete, de forma bastanterazoável, o comportamento livreda estação.

O modelo do comportamento do "buffer" estádescrito najigura 3.

810ff 810ff

._->@ 0) ®S20n S20n

figura 3 - Modelo do comportamento do "buffer"

A modelagem do "buffer" levou em conta onúmero de "pallets" que o espaço entre SI e S2comporta. Neste caso podem existir fisicamente dois"pallets",

A composição síncrona dos dois modelos (buffer +estação de espera) é representada pelo autômato dajigura 4.

Neste caso, segundo a teoria clássica, a naturezado supervisor é de agente desabilitador; os eventossão assumidos como gerados pela planta. No entanto,

185

na realidade, esta situação corresponde à de umsistema sob a ação de um outro elemento de controleque pode gerar comandos sem nenhuma restriç ão.Assim, por exemplo, se este agente fosse desligado,todos os eventos controláveis, ainda que habilitados,não ocorreriam.

Uma possível especificação que poderia seraplicada a este sistema, seria a de permitir queapenas uma peça por vez possa ocupar o espaçoentre SI e S2, ou seja, o "buffer" . Esta especificaçãopode ser modelada como mostrado najigura 5.

810ft

820n

figura 5 - Especificação

Este modelo representa claramente uma restrição àcapacidade de armazenamento do buffer.

Aplicando-se esta restrição ao sistema, obtem-se aseguinte linguagem alvo, representada pelo autômatodajigura 6, resultado da composição síncrona entre osautômatos dasjiguras 4 e 5.

explícita deste agente e portanto não permite que selide com situações como esta.

Para resolver este problema existem duas opções:• Rever a modelagem de todo o sistema;• Utilizar novas abordagens para o

tratamento de síntese de supervisores.

3.2 Um novo modelo para o sistema "estaçãode espera + buffer"

Para este novo modelo, não será utilizado omapeamento direto de eventos controláveis do nívelsupervisório em comandos do nivel físico.

Sob um ponto de vista funcional, a estação deespera " tem a função" de permitir ou não a passagemde "pallets" . Esta "permissão" pode ser vista comoum evento controlável , já que a decisão sobre apassagem ou não de determinado "pallet" caberá aosupervisor. Outro evento, este agora não-controlável ,seria o fim da passagem do pallet pela estação.

O novo modelo para a estação de espera émostrado najigura 7.

Passar palie!

5 20n

510n . 5520n

510ft

Passou

fi gura "7 - Novo modelo para a "estação de espera "

Liberar .,' 8

figura 6 - Modelo que representa a linguagem-alvo para osistema a ser controlado

Ao aplicar a teoria clássica neste sistema, amáxima linguagem controlável encontrada é vazia.Isto se deve ao fato de existir um caminho de eventosnão-controláveis, partindo do estado inicial , que podeconduzir a planta ao estado 5, e consequentemente, auma situação não desejada. Não existe ao menos umevento controlável que possa ser desabilitado por umsupervisor, que impeça a planta de atingir o estado 5.'Este resultado é mais uma vez resultado da

interpretação de que os eventos são gerados pelaplanta.

Se, no entanto, mais uma vez, imaginássemos queexisfe um agente controlador que é responsável pelageração dos eventos correspondentes a comandos, oresultado acima pode não ser plausível. De fato, é fácilmostrar que a especificação acima pode ser atendida,se o comando de trancar for efetivamente enviado aoatuador A, toda vez que um pallet passar por SI'

Este modelo inicial impõe ao "agente de controle"a responsabilidade de gerar os eventos controláveis,porém, a teoria clássica [1] não prevê a existência

51 0n 520n

TrancaA :' Liberar, '"

520n

5 2 0 nTrancar.

4

( LiberarLiberar

510n . 6O evento "passou " pode ser mapeado diretamente

no evento "S l off' da planta. Já para o evento "passarpallet ' não existe um correspondente direto no nívelfísico.

Habilitar o evento "passar pallet " corresponde aimplementar um comando de recolher o atuador A,.Por outro lado , desabilitar este evento corresponde aimplementar o comando de estender o atuador A, . Já aocorrência deste evento indica que um "pallet" estápassando livremente pela estação, o que fisicamentesignifica que o sensor SI está sensibilizado e o atuadorA, está recolhido.

Portanto, a habilitação e desabilitação dos eventoscontroláveis é de responsabilidade do supervisor. Seno modelo inicial era exigido que se considerasse aexistência de um "agente controlador;' , neste novomodelo quem gera estes eventos é a planta, e omodelo é compatível com a teoria clássica.

O modelo do buffer segue a mesma idéia.mantendo a mesma estrutura (figura 8).

Passou Passou,·' 0' 2"=c.-

Saiudo SaiudobLlfe.- bLlfe.-

fi gura li - Novo modelo para o "buffer "

o evento "saiu do buffer" pode ser mapeadodiretamente no evento "Sçon ".

A composição dos novos modelos fornece o

186

comportamento livre para a planta , descrito na figura9.

Saudobuffer

Sauoo Saudobuffer buffer

fi gura 9 - Novo modelo para o sistema "estação de espera+ buffer "

o primeiro aspecto importante a ser notado é adiminuição do número de estados. Outro fatointeressante é que o nível de abstração utilizadotornou o modelo mais " legível" . A especificaçãoinicial, assim como o buffer, apresenta a mesmaestrutura, como mostra e figura 10.

Passou:1'0' . ""1':

Saiu dobuffer

fi gura lO - Especificação utilizando novos eventos

A aplicação desta especificação ao comportamentolivre da planta é mostrado najigura 11.

Séiudobuffer

forçáveis, foi inicialmente proposta por Golaszewski eRamadge [ 2] .

Um evento desta classe ocorre se e somente se forforçado por alguma entrada externa, e neste caso,prevalece sobre a ocorrência de qualquer outroevento . Deve-se considerar que o tempo gasto paraimplementar os comandos associados a estes eventosdeve ser suficiente para que se antecipem aos demaiseventos.

A utilização deste conceito, implica na revisão detrês pontos importantes da teoria clássica: o conjuntoL de eventos ; o conjunto r de entradas de controle; ea controlabilidade de linguagens.

Diferentemente de [ 1 ], o conjunto L, naabordagem apresentada em [2], é dividido em trêsconjuntos distintos de eventos: Lu e Lc' como descritosanteriormente, e o conjunto Lr, que contém os eventosforçáveis.

A partir deste novo conjunto de eventos, define-seum novo conjunto de entradas de controle, comosendo :

{

r:r E 2L /\ r = {Q'"} /\ Q'" E :Ef }r= v

r ç 2 LuU Lc /\ :EIIc r

figura 11 - Linguagem-alvo para o novo modelo

Saiudobuffer

, ,. Passarpallel , Passo,! -,,> ,q;.. . ) ·.....1 , . : <, .-

fi gura 12 - Máxima Linguagem Controlável para o novomodelo

Neste conjunto, nota-se a existência de dois 'tiposbem definidos de entradas de controle: ou umcomando aplicado por um nível superior ao nível daplanta ; ou um conjunto contendo os eventoscontroláveis que ocasionalmente estão habilitados etodos os eventos não-controláveis .

É interessante permitir ao supervisor a opção defornecer uma entrada de controle que seja a união dosdeis tipos de conjuntos citados acima. Isto pode serfeito definindo-se o conjunto de entradas de controlecomo sendo o fechamento de r, denotado de cl(r).Este novo conjunto garante a existência de umamáxima linguagem controlável, pois é fechado para aoperação de união.

Como definido em [2] , para um dado K ç L eSE K , o conjunto ativo de K depois de s é:

:E K (s) = {Q'" E :E:sQ'" E K} ;ou seja,L k(S) contém todos os eventos possíveis de ocorrer

depois que socorre.Seja também L(G) a linguagem gerada pelo

autômato da planta .Uma linguagem K ç L(G) é dita (L(G),c1(r») -

controlável se:

Passou. -...----....,

Passou ' Passa" palet ,, _,) '

Séiudobuffer

. o Passa" Pa1e:/ f ...." . . ' ,, /

A máxima linguagem controlável pode ser entãorepresentada pelo autômato dajigura 12. Neste caso,o result ado obtido util izando-se a teoria clássica ébastante razoável. Para que a especificação sejaatendida, basta ao supervisor desabilitar o evento"passar pallet " no estado 2.

A desabilitação do evento "passar pallet " noestado 2 significa, como mencionado anteriormente,estender o atuador Ax> bem como a habilitação desteevento no estado inicial implica em recolher A, .

3.3 A modelagem utilizando "eventosforçáveis"

A idéia de estender a teoria clássica pela introdução danoção de uma nova classe de eventos , os eventos

Deseja-se então, utilizar a abordagem apresentadaem [2 ] afim de construir um controlador (supervisor)para o sistema "estação de espera + buffer ",

187

figura 13 - Máxima Linguagem Controlável para o sistema"estação de espera + buffer " utilizando a abordagem de

eventos f orçáveis

o conjunto L de eventos é dividido em:L II = {"S/on " , "S joff" ' "S2011"}LI = { "trancar " , "liberar" }

L c =0Nada é modificado nos modelos propostos

inicialmente.O que deve ser revisto é o cálculo da máxima

linguagem controlável , a partir da linguagem-alvodescrita nafigura 6.

Finalmente, neste caso, a máxima linguagemcontrolável , utilizando a noção de eventos forçáveis, édescrita pelo autômato dafigura /3 .

Portanto, observa-se que, utilizando a abordagemde eventos forçáveis, o modelo inicialmente propostoé factível.

4. Proposta para uma Arquitetura FísicaDuas observações podem ser feitas a respeito dassoluções apresentadas anteriormente:

• A solução utilizando eventos forçáveis abrangea primeira solução. Ou seja, a noção decontrolabilidade utilizada em 3.3 pode serutilizada também em 3.2, obtendo-se o mesmoresultado;

• Ambas as soluções requerem um módulointermediário, que seja responsável pela"tradução" dos eventos do nível supervisórioem eventos do nível físico.

O supervisor, mesmo com a noção de eventosforçáveis, continua sendo um mapa que a cada estadoestabelece quais eventos devem ser habilitados e quaisdevem ser desabilitados. Ou seja , o supervisormantém a responsabilidade única de habilitar edesabilitar eventos, porém, reconhece a existência deum outro elemento capaz de gerar eventos que sãocomandos enviados à planta

Este novo elemento trata-se de um módulointermediário (M!), que de posse da informação vindado supervisor, decidirá ou não sobre o envio de umcomando ao nível físico.

Este módulo pode ser dividido em dois

510n

subm ódulos: um que trata dos eventos controláveis(M/C), e outro que trata dos eventos forçáveis (M/F) .

Os eventos não-controláveis não necessitam sertratados pelo M/. Estes eventos, como são sempremapeados em sinais de sensores, são gerados pelaplanta e enviados diretamente ao supervisor.

O supervisor envia ao M/C a informação tanto doseventos controláveis habilitados quanto osdesabilitados, já que ambas as situações semprerepresentam comandos que devem ser enviados aonível físico. Ao receber esta informação, o M/C deveimediatamente enviar os comandos associados aonível físico. O M/C não precisa realizar nenhum tipode tomada de decisão sobre qual comando enviar.

No caso dos eventos forçáveis, o supervisor enviaao M/F somente os eventos habilitados, já que adesabilitação destes eventos significa apenas a nãoaplicação do comando associado. O MIF deve , emseguida, decidir se aplica ou não o comando associadoao evento . Além disso, deve decidir, entre várioseventos forçáveis, qual efetivamente será aplicado.Neste caso exige-se uma tomada de decisão, que podeser feita utilizando-se regras de prioridades, ou mesmoa aplicação de métodos probabilísticos.

Quando a informação enviada pelo supervisorcontém a habilitação de eventos forçáveis e também ahabilitação e desabilitação de eventos controláveis, aaplicação dos comandos associados aos eventoscontroláveis pelo MIC deve ser imediata, enquantoque a aplicação dos comandos associados aos eventosforçáveis depende de uma decisão a ser tomada peloMIF. Neste caso, se não houver a aplicação denenhum evento forçável, a planta se encarregará degerar algum evento (controlável ou não-controlável) .Porém, em casos onde a informação enviada pelosupervisor apenas contém a habilitação de eventosforçáveis, a aplicação de um destes eventos pelo MIFé obrigatória. Caso contrário, ou um evento não-controlável indesejado será gerado pela planta, ounada mais acontece e o sistema pára de evoluir.

Se um evento forçável for aplicado, o M/F deveenviar esta informação de volta ao supervisor de modoa alertá-lo da ocorrência do evento, já que a planta nãopode fornecer este tipo de informação, pois a mesma égerada exclusivamente pelo M/F. .

Além do módulo intermediário, existe ainda umoutro módulo que realiza uma interface entre o nívelfísico e o nível supervisório. Este módulo,denominado Interface, recebe os sinais de sensores donível físico e os mapeia em eventos não-controláveisou eventos controláveis.

Para efeito de ilustração, seja r/lc os eventoscontroláveis habilitados e desabilitados pelosupervisor; r/lf os eventos forçáveis habilitados pelosupervisor; Yc os comandos associados a habilitação edesabilitação dos eventos controláveis; Yf oscomandos associados aos eventos forçáveis ; tlc os

510n

Liberar

4

Trancar

510ft.: 1

520n

Liberar

Trancaf\ . . Liberar

( 2)<

5 10n

188

eventos controláveis ocorridos; 'lI os eventosforçáveis ocorridos; e ttnc os eventos não-controláveisocorridos; .

A arquitetura proposta pode ser vista nafigura 14,

A abordagem introduzida em [2], deve serutilizada para o cálculo do supervisor, pois abrangetodos estes conjuntos distintos de eventos.

Para se implementar um controlador, partindo-sede um modelo que possui eventos com estascaracterísticas, há a necessidade de se implementar ummódulo intermediário entre a planta e o supervisor.

Este módulo é responsável pela tradução doseventos controláveis e forçáveis do supervisor emcomandos do nível físico . Além disso, deve ser dotadode capacidade de decisão sobre a aplicação ou não deum comando.

A arquitetura proposta é bastante simples, atendeàs características dos eventos apresentados, e ésuficientemente geral para lidar com uma ampla classede problemas reais.

lYf ISensoresI I__1:

Planta -----.J

iYe,

, "f_ "'

•!11 ne'11e

, .lo, - _:f_ _!- . - , . 1

.:Mie :MIF , :InterfaceI. U i . !__MJ l. 1

figura 14"' Proposta de uma arquitetura fisica para ocontrole supervisório de sistemas reais

ou ainda, considerando um diagrama mais sintéticoque representa a malha fechada de controle, comomostra a figura 15. Nesta figura , considera-se G aplanta e S o supervisor, sendo que a Interface estáincorporada à planta.

, 211.. ..

figura 15 - Malha fechada para o controlesuperv isório de sistemas reais

6. Referências[1] Ramadge, P.J., and Wonham, W.M.

"Supervisory Contrai of a class of DiscreteEvent Processes", SIAM 1. Control andOptimization, vol. 25, n!! 1, January 1987 .

[ 2] Golaszewski, C.H., and Ramadge, P.J. "Contraiof Discrete Event Processes with ForcedEvents", Proceedings of the 20th Conference onDecision and Control , Los Angeles, CA,December 1987.

[3] Brandin, B.A., Wonham , W.M., and Benhabib,B. "Discrete Event System Supervisory Appliedto the Management of ManufacturingWorkcells " , 7th Intemational Conference onComputer Aided Manufacturing Enginnering,V.C Venkatesh and LA. McGeough Eds .,Elsevier 1991, pp. 527-536.

5. ConclusõesAo se tratar o problema de síntese de supervisorespara um sistema real a eventos discretos, deve-se estaratento à natureza dos eventos que fazem parte dosistema. O mapeamento direto de eventos do modeloda planta em comandos do nível físico, comousualmente feito , pode resultar em soluçõesincoerentes com a prát ica, ao se utilizar a teoria. proposta em [ 1] .

Propõe-se então que, ao modelar um sistema real,os eventos controláveis representem situações geradaspela própria planta, sobre as quais o supervisor,através de comandos, possa permitir ou não queocorram, através da habilitação e desabilitação desteseventos.

Quando comandos necessitam ser diretamentemapeados em eventos no modelo, propõe-se que estessejam modelados como eventos forçáveis .

189