Implementação de Técnicas de Controle Max-Plus em um Simulador Realista Marcelo Xavier Reis Souza

Transcrição

1 Implementação de Técnicas de Controle Max-Plus em um Simulador Realista Marcelo Xavier Reis Souza Universidade Federal de Minas Gerais Escola de Engenharia Programa de Pós-Graduação em Engenharia Elétrica Belo Horizonte 2018

2

3 Marcelo Xavier Reis Souza Implementação de Técnicas de Controle Max-Plus em um Simulador Realista Dissertação de Mestrado apresentada ao Programa de Pós-graduação em Engenharia Elétrica da Universidade Federal de Minas Gerais como parte final dos requisitos para a obtenção do título de Mestre em Engenharia Elétrica. Área de concentração: Sinais e Sistemas Orientador: Prof. Dr. Vinícius Mariano Gonçalves Belo Horizonte 2018

4

5 À Deus pelo dom da vida, por iluminar meu caminho e me dar forças para seguir sempre em frente. À todos aqueles que acreditaram em meu potencial e que de alguma forma contribuiram para o êxito deste trabalho. Que minhas atitudes sejam diariamente reflexo deste sentimento de gratidão.

6

7 Agradecimentos Em primeiro lugar agradeço à Deus e à Nossa Senhora por permitir-me chegar até aqui, me guiando, dando forças e tranquilidade para seguir em frente com os meus objetivos. Aos meus pais, Laércio e Arlene, minha base e referência, pelo amor sempre incondicional, por terem me dado educação e ensinado valores que para sempre levarei em minha vida. Ao meu namorado Alex, por todo amor, carinho, compreensão e apoio em tantos momentos difíceis desta caminhada. Suas palavras de conforto e motivação foram importantes e decisivas para que eu pudesse chegar até aqui. Obrigado por estar sempre ao meu lado, compartilhando dos meus ideais e me incentivando sempre a prosseguir. Ao meu orientador, Professor Doutor Vinícius Mariano Gonçalves, exemplo de pessoa e profissional, por todo o conhecimento transmitido, pela compreensão, paciência e principalmente por ter acreditado e depositado a sua confiança em mim no desenvolvimento deste trabalho. Ao programa de Pós Gradução em Engenharia Elétrica da UFMG, representado pelo Prof o. Dr o. Luis Antônio Aguirre, por abrir as portas e permitir-me ingressar neste projeto. À todos os professores que fizeram parte desse caminhar, principalmente os professores Carlos Andrey Maia e Patrícia Nascimento Pena tão decisivos na orientação dos meus primeiros passos dentro do programa. À todos os meus amigos de mestrado, amigos do LACSED, pela troca de conhecimentos e momentos divididos, especialmente à Lisley, sempre companheira nos estudos, cujo o apoio e amizade estiveram presentes em todos os momentos. À CAPES pelo auxílio financeiro concedido durante o desenvolvimento deste trabalho. Enfim, agradeço carinhosamente a todos aqueles que de uma maneira ou de outra contribuíram para que este percurso pudesse ser concluído. Serei eternamente grato. Quando não souber para onde ir, olhe para trás e saiba pelo menos de onde você vem. (Provérbio Africano)

8

9 A tarefa não é tanto ver aquilo que ninguém viu, mas pensar o que ninguém ainda pensou sobre aquilo que todo mundo vê. (Arthur Schopenhauer)

10

11 Resumo Recentemente, tem sido dada grande atenção à teoria de sistemas lineares na chamada Álgebra Max-Plus, teoria essa que é adequada para a modelagem de certos tipos de sistemas a eventos discretos. Em muitos trabalhos na literatura é discutida a forma de se obter um controlador através de uma realimentação linear de estados que atenda determinadas especificações. O grande desafio, portanto, é quando computamos um controlador não-causal, que exige técnicas de causalização para permitir a sua implementação. Diante a única técnica de causalização, de conhecimento, existente na literatura, este trabalho, como primeira contribuição, propõe um novo método para a causalização de controladores, melhorando as condições de robustez e estabilidade. Como segunda contribuição será apresentado um simulador realista, desenvolvido a partir de uma planta real no qual será possível validar com eficiência e comodidade as técnicas de controle, além de simular de forma muito realística perturbações que são comuns em uma planta industrial. Palavras-chave: Álgebra Max-Plus; Sistema a Eventos Discretos; Redes de Petri; Causalização; Simulador.

12

13 Abstract Recently, great attention has been given to the theory of linear systems in the socalled Max-Plus Algebra, which is suitable to model certain kinds of discrete events systems. In many works in the literature the way to obtain a controller through a linear feedback of states that meets certain specifications is discussed. One challenge is when we compute a non-causal controller, which requires causalization techniques to allow its implementation. Given the unique technique of causalization, to the best of the author s knowledge, existing in the literature, this work, as the first contribution, proposes a new method for the causalization of controllers, improving the conditions of robustness and stability. As a second contribution, a realistic simulator will be presented, developed based in a real plant, in which it will be possible to validate with efficiency and convenience the control techniques in addition to simulating them, in a very realistic way, perturbations that are common in industrial plants. Keywords: Max-Plus Algebra; Discrete Event Systems; Petri Nets; Causalization; Simulator.

14

15 Lista de ilustrações Figura 1 Evolução dinâmica de um sistema a eventos discretos Figura 2 Sequência de disparos de transições em uma rede de Petri Figura 3 Exemplo de rede de Petri com temporização no lugar, representando um Grafo a Evento Temporizado (GET) Figura 4 Exemplo de grafo de precedência Figura 5 Exemplo de um grafo a evento temporizado (GET), para modelagem através de equações lineares em espaço de estados na álgebra max-plus. 37 Figura 6 Grafo a evento temporizado (GET) com a inclusão do estado x Figura 7 Foto do sistema no Laboratório Angevin de Pesquisa em Engenharia de Sistemas (LARIS) da Universidade de Angers - França Figura 8 Esquema do sistema de transporte da planta de Angers visto de cima.. 45 Figura 9 Grafo a evento temporizado da planta de Angers Figura 10 Modelo em malha aberta da planta de Angers Figura 11 Matrizes A, B T e C resultantes da modelagem da planta de Angers.. 48 Figura 12 Exemplo de especificação de controle para a planta de Angers Figura 13 Matrizes de especificação E e D Figura 14 Arquitetura do controle da planta de Angers Figura 15 Gráfico das especificações R1, R2, R3 e R4 para o sistema em malha fechada considerando o controlador causalizado pela técnica existente.. 63 Figura 16 Gráfico das especificações R1, R2, R3 e R4 para o sistema em malha fechada considerando o controlador causalizado pela técnica proposta.. 66 Figura 17 Perturbação devido ao agarramento de palete. Um palete ao agarrar no trecho B4 B5 sofre colisão do palete que vem atrás Figura 18 Tela principal do simulador Figura 19 Menus de ajustes da simulação (a) e de comando (b) acessados na tela principal

16 Figura 20 Tela Opções de Controle onde o usuário define o modo de controle, insere as especificações desejadas e calcula o controlador a partir do método de causalização escolhido Figura 21 Tela de comunicação TCP/IP onde o simulador pode ser controlado a partir de outros programas externos Figura 22 Tela Observador Figura 23 Menu Gráficos onde o usuário pode visulizar os gráficos para as entradas u i [k], estados x i [k] e saídas y i [k] bem como acompanhar o atendimento às especificações Figura 24 Gráfico de tendência para a especificação x 20 [k 1] x 18 [k]. A especificação é satisfeita a partir do 7 o evento Figura 25 Tela de Grafo Evento Temporizado (GET) do sistema Figura 26 Especificações R1, R2 e R3 impostas ao sistema e utilizadas para os testes em malha aberta e malha fechada com e sem perturbação Figura 27 Tela Control Options configurada para o modo sem controlador (malha aberta) e com as especificações desejadas para a simulação Figura 28 Menus da tela inicial onde à direita o usuário adiciona fichas de permissão aos botões e à esquerda inicia a simulação Figura 29 Menu da tela inicial e tela Control Options configurados para simulação em malha fechada sem perturbação Figura 30 Menu da tela inicial e tela Control Options configurados para simulação em malha fechada com perturbação Figura 31 Gráfico das especificações R1, R2 e R3 para o sistema simulado em malha aberta Figura 32 Gráfico da especificação R1, x 6 [k] x 22 [k], para o sistema simulado em malha fechada, sem perturbação, considerando as três diferentes abordagens Figura 33 Gráfico da especificação R2, x 20 [k 1] x 18 [k], para o sistema simulado em malha fechada, sem perturbação, considerando as três diferentes abordagens Figura 34 Gráfico da especificação R3, 4x 11 [k 1] x 12 [k], para o sistema simulado em malha fechada, sem perturbação, considerando as três diferentes abordagens Figura 35 Gráfico da especificação R1, x 6 [k] x 22 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 05% Figura 36 Gráfico da especificação R2, x 20 [k 1] x 18 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 05%

17 Figura 37 Gráfico da especificação R3, 4x 11 [k 1] x 12 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 05% Figura 38 Gráfico da especificação R1, x 6 [k] x 22 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 1% Figura 39 Gráfico da especificação R2, x 20 [k 1] x 18 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 1% Figura 40 Gráfico da especificação R3, 4x 11 [k 1] x 12 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 1% Figura 41 Gráfico da especificação R1, x 6 [k] x 22 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 2% Figura 42 Gráfico da especificação R2, x 20 [k 1] x 18 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 2% Figura 43 Gráfico da especificação R3, 4x 11 [k 1] x 12 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 2%

18

19 Lista de tabelas Tabela 1 Porcentagem dos eventos em que as especificações são atendidas, para cada método de causalização e especificação no teste em malha fechada sem perturbação Tabela 2 Porcentagem dos eventos em que as especificações são atendidas, para cada método de causalização e especificação, para o teste em malha fechada considerando taxas de perturbação ξ = 0.05%, ξ = 0.1% e ξ = 0.2%

20

21 Lista de símbolos T n n max Z max ρ(a) ε ξ A T I Dióide max-plus Dióide max-plus Soma max-plus Produto max-plus Menor ou igual que (ordem natural) Raio espectral de A Maior ou igual que (ordem natural) Elemento nulo álgebra max-plus Taxa de perturbação definida para o simulador Transposta de A Matriz identidade max-plus

22

23 Lista de siglas CLP Controlador Lógico Programável GET Grafo a Evento Temporizado SED Sistema a Eventos Discretos

24

25 Sumário 1 INTRODUÇÃO Apresentação Motivação Objetivos Objetivo Geral Objetivos Específicos Organização da Dissertação CONCEITOS PRELIMINARES Sistemas a Eventos Discretos Rede de Petri Rede de Petri Temporizada Grafo a Evento Temporizado Álgebra Max-Plus Definição Extensão Matricial Análise Espectral Sistemas Dinâmicos em Max-Plus Conexão da Álgebra Max-Plus com Grafo a Evento Temporizado Controle na Álgebra Max-plus SISTEMA CONSIDERADO Apresentação Modelagem do Sistema Considerado Arquitetura de Controle CONTRIBUIÇÕES Introdução

26 4.2 Causalização de Controladores Técnica de causalização existente Técnica de causalização proposta Comparação entre a técnica existente e a técnica proposta Termo de Controle Avançado Simulador Apresentação Funcionalidades EXPERIMENTOS COM O SIMULADOR Apresentação Especificações do sistema Testes Malha aberta Malha fechada - sem perturbação Malha fechada - com perturbação Resultados Malha aberta Malha fechada - sem perturbação Malha fechada - com perturbação CONCLUSÕES REFERÊNCIAS ANEXO A ARTIGO SUBMETIDO

27 25 Capítulo 1 Introdução 1.1 Apresentação Uma teoria relativamente nova, baseada na álgebra max-plus, encontra-se em amplo desenvolvimento e permite o controle de alguns sistemas a eventos discretos, mais especificamente Grafo a Evento Temporizado (GET), uma subclasse de rede de Petri (Baccelli et al. (1992)) e que tem sido aplicado para modelar, por exemplo, programação de trens, sistemas de manufatura, processo de produção de semicondutores e até mesmo dinâmicas de ribossomos (veja Gonçalves, Maia e Hardouin (2016) para uma revisão). Nesse sentido, muitos trabalhos encontrados na literatura recente (Katz (2007), Maia, Andrade e Hardouin (2011), Amari et al. (2012), Maia, Hardouin e Cury (2013), Gonçalves, Maia e Hardouin (2016), Kim e Lee (2016), Gonçalves, Maia e Hardouin (2017)), estudaram o problema em que se deseja que o estado do sistema respeite uma determinada especificação imposta. Nesses trabalhos o controlador é obtido como uma realimentação linear de estados, ou seja, u[k] = F x[k], onde a matriz F é fixa e o produto matricial é interpretado no contexto max-plus. Acontece que, após o cômputo do controlador, podemos obter controladores com característica não-causal, mais especificamente, quando a matriz F possui elementos negativos. Isso impossibilita a implementação física desse controlador. Neste caso, técnicas de causalização são utilizadas para permitir essa implementação, e é preciso garantir que mesmo após a sua causalização o controlador mantenha a sua propriedade de robustez. A primeira contribuição deste trabalho foi o desenvolvimento de uma nova técnica de causalização para controladores por realimentação de estado, considerando aspectos diferentes da única técnica que, do conhecimento do autor, existe na literatura: Maia, Hardouin e Cury (2013). A segunda contribuição foi o desenvolvimento de um simulador realista baseado em uma planta real. Com o simulador é possível testar e validar as técnicas de controle de uma maneira prática e eficiente, sem a necessidade de realizar testes na planta física real, o que geralmente é oneroso e requer tempo. Além disso, por se tratar de um modelo híbrido (informações e dinâmicas contínuas e discretas), o simulador

28 26 Capítulo 1. Introdução nos permite realizar testes com alguns tipos de perturbações realistas que não podem ser modelados satisfatorimante no modelo algébrico max-plus. 1.2 Motivação A primeira motivação deste trabalho surge da carência na literatura de técnicas para a causalização de controladores por realimentação de estado. Diante a única técnica de causalização, de conhecimento, existente na literatura (Maia, Hardouin e Cury (2013)) procurou-se desenvolver uma nova técnica, que oferece maior robustez ao controlador, na medida que leva menos eventos para convergir ao conjunto de especificações desejado. A segunda motivação deste trabalho surge da necessidade de testar as técnicas de controle em ambientes mais realistas. A validação dessas técnicas somente em modelos matemáticos, como é feita na maioria dos trabalhos sobre o assunto (do conhecimento do autor), abstrai situações de perturbações que podem acontecer em uma planta real. Realizar o estudo desses aspectos práticos em uma planta real nem sempre é fácil, uma vez que requer, por exemplo, a parametrização dos equipamentos e disponibilidade de profissionais experientes para operar a planta, o que pode demandar tempo e recursos, tornando estes testes complexos e inviáveis. O desenvolvimento de um simulador realista nos permite realizar, com mais veracidade e rapidez, a validação dessas técnicas, ao mesmo tempo que nos traz a comodidade de realizar os testes em qualquer lugar por meio de um computador. 1.3 Objetivos Objetivo Geral O objetivo desta dissertação é desenvolver uma nova técnica para a causalização de controladores max-plus e desenvolver um simulador realista, a partir de uma planta real, para testes e validação das técnicas de controle Objetivos Específicos Desenvolver uma nova técnica de causalização de controladores de forma a prover mais robustez e estabilidade ao sistema se comparado com a técnica existente na literatura (Maia, Hardouin e Cury (2013)); Validar as técnicas de causalização existente (Maia, Hardouin e Cury (2013)) e a proposta neste trabalho, e compará-las com relação à robustez e estabilidade; Simular o sistema com perturbações realistas (agarramento de paletes) e verificar se o controlador mantém o sistema dentro do conjunto de especificações desejado;

29 1.4. Organização da Dissertação Organização da Dissertação Os capítulos seguintes desta dissertação são organizados da seguinte forma: Conceitos Preliminares: expõe os conceitos básicos sobre a teoria de sistemas a eventos discretos e álgebra max-plus necessários para o desenvolvimento da técnica de causalização proposta e implementação do simulador; Sistema Considerado: explica sobre o funcionamento, modelagem e controle da planta real considerada para o desenvolvimento do simulador; Contribuições: apresenta uma breve revisão sobre causalização e a técnica de causalização existente (Maia, Hardouin e Cury (2013)) bem como o desenvolvimento matemático da técnica de causalização proposta e apresentação das funcionalidades do simulador desenvolvido; Testes e Resultados: apresenta os testes realizados com o simulador e os seus resultados, comparando as técnicas de causalização, e o comportamento do sistema mediante à perturbações; Conclusões: Expõe as conclusões deste trabalho e define as sugestões para trabalhos futuros.

30 28 Capítulo 1. Introdução

31 29 Capítulo 2 Conceitos Preliminares 2.1 Sistemas a Eventos Discretos Qualquer processo que desejamos simular pode ser considerado como um sistema. Sistemas são conjuntos de elementos, materiais ou imateriais, entre os quais pode definir uma relação e que operam como uma estrutura organizada. Por exemplo, uma fábrica é um exemplo de sistema, onde um grupo de pessoas e máquinas trabalham juntos para a produção de algum produto. Dependendo da natureza de suas variáveis, um sistema pode ser definido como discreto ou contínuo. Em um sistema contínuo as variáveis podem assumir qualquer valor real em um dado intervalo (por exemplo, medidas de temperatura e de pressão). Já em um sistema discreto as variáveis podem assumir apenas um número limitado de valores ou estados (por exemplo, no caso de uma máquina, os estados: ligado, desligado ou defeito). Um Sistema a Eventos Discretos (SED) é definido como um sistema cuja evolução dinâmica depende da ocorrência de eventos. Para que um SED possa existir, é necessário que existam ações ocorrendo, e que estas por sua vez gerem eventos. Um evento pode ser identificado com uma ação proposital (ligar um interruptor), uma ocorrência espontânea (perda de conexão com o provedor de internet) ou o resultado da verificação de uma condição (a temperatura do reator excedeu o limite de segurança). Esses eventos produzem mudanças de estado e em qualquer caso, essas mudanças se caracterizam por serem abruptas e instantâneas: ao perceber um evento, o sistema reage imediatamente, acomodando-se em tempo nulo numa nova situação, onde permanece até que ocorra um novo evento. Desta forma, a simples passagem do tempo não é suficiente para garantir que o sistema evolua e, de modo geral, os eventos ocorrem em instantes de tempo irregulares. Um sistema só mudará de estado quando ocorrer um evento. Se não ocorrer nenhum evento, o sistema permanecerá no mesmo estado. A Figura 1 apresenta um diagrama de evolução dinâmica de um SED. Os eventos são nomeados com os símbolos δ, α, τ, β, φ e os estados do sistema são representados por q 0, q 1, q 2, q 3, q 4 e q 5. O estado inicial é q 0 e os eventos, δ, α, τ, β, φ, mudam o estado do

32 30 Capítulo 2. Conceitos Preliminares sistema para q 1, q 2, q 3, q 4 e q 5, respectivamente. Quando não há a ocorrência de nenhum evento, o sistema permanece no mesmo estado. Figura 1 Evolução dinâmica de um sistema a eventos discretos. Como exemplo de SED s, temos os sistemas de filas, sistemas de comunicação, sistemas de computação, sistemas de manufatura, sistemas de tráfego, etc. Até o momento foram desenvolvidos vários modelos para SED s, que modelam diferentes tipos de sistemas bem como permitem diferentes objetivos na análise dos sistemas em estudo. O modelo que será abordado neste trabalho será o de rede de Petri Temporizada, mais especificamente a subclasse de Grafo a Evento Temporizado (GET), que tem dado forte contribuição ao desenvolvimento da teoria de controle de SED s. 2.2 Rede de Petri As redes de Petri são um modelo de SED s desenvolvido por Carl Adam Petri no início dos anos 1960, muito relacionado a autômatos no sentido de que elas também representam explicitamente a função de transição dos SED s e manipulam eventos de acordo com regras (Cassandras e Lafortune (2008)). Sua representação é convenientemente descrita graficamente, pelo menos para sistemas pequenos, resultando em gráficos de rede de Petri que são intuitivos e capturam muitas informações estruturais sobre o sistema. Basicamente um gráfico de rede de Petri contém lugares, transições e arcos direcionados conforme mostrado na Figura 2. Os arcos interligam os lugares e as transições, não podendo nunca conectar lugares e lugares ou transições e transições. Definem-se como lugares de entrada de uma transição, aqueles para onde um arco se destina e lugares de saída de uma transição aqueles de onde um arco se origina. Cada lugar da rede pode

33 2.2. Rede de Petri 31 armazenar qualquer número de fichas e são essas fichas que habilitam os disparos das transições. Quando uma transição é disparada, ela consome uma ficha de cada um de seus lugares de entrada e produz uma ficha em cada um de seus lugares de saída. A execução de uma rede de Petri é não-determinística. Isso significa que múltiplas transições podem ser habilitadas ao mesmo tempo (cada uma pode ser disparada) e que nenhuma transição deve ser obrigatoriamente executada em determinado momento. Para ilustrar um processo de disparo de transições e mudança de estado, considere a rede de Petri representada na Figura 2 (a). Podemos ver que a única transição habilitada é t 1, já que requer uma única ficha do lugar p 1. Quando t 1 é disparada, uma ficha é removida de p 1 e uma ficha é colocada em cada um dos lugares de saída, p 2 e p 3, como pode ser visto na Figura 2 (b). Neste novo estado, somente a transição t 2 passa a ser habilitada. Quando t 2 é disparada uma ficha é consumida dos lugares de entrada p 2 e p 3 e uma ficha é colocada no lugar de saída p 4 gerando um novo estado, representado pela Figura 2 (c). Agora, a única transição habilitada é a t 3, que quando disparada, retira uma ficha do lugar de entrada p 4 e coloca uma ficha no lugar de saída p 1, levando o sistema a sua condição inicial, conforme mostrado na figura Figura 2 (a). Figura 2 Sequência de disparos de transições em uma rede de Petri Rede de Petri Temporizada No caso de modelos de SED s de duração indeterminada, as redes de Petri fornecem uma estrutura muito geral. Esta estrutura pode ser estendida para modelos temporiza-

34 32 Capítulo 2. Conceitos Preliminares dos, equipando uma rede de Petri com uma estrutura de relógio e transformando-a em uma rede de Petri temporizada. Essa estrutura de relógio associa um tempo (número real) às transições e tem o seguinte significado: quando uma dada transição da rede é habilitada ela não dispara imediatamente, mas incorre de um atraso no disparo dado por esse tempo associado. Durante esse atraso as fichas são mantidas nos lugares de entrada da transição. Somente após esse tempo, a transição dispara e as fichas dos lugares de entrada da transição são consumidas e as dos lugares de saída produzidas (Cassandras e Lafortune (2008)). 2.3 Grafo a Evento Temporizado Um Grafo a Evento Temporizado (GET) é uma sub-classe de rede de Petri temporizada em que cada local possui exatamente uma transição antecessora e outra sucessora e todos os arcos possuem peso unitário (Figura 3). Cada local, juntamente com seus arcos de entrada e saída, pode ser interpretado como um próprio arco, conectando a transição antecessora e a sucessora diretamente (Baccelli et al. (1992)). Em sua definição usual, a temporização está associada à transição, mas existem situações em que esse tempo está associado aos lugares. Neste caso, o tempo associado ao lugar representa a mínima quantidade de tempo que uma ficha deve ser mantida, depois de ser entregue ao local, até que ela possa ser usada para permitir uma transição. Um GET não permite nem pode modelar conflitos; uma ficha em um lugar pode ser consumida por apenas uma transição predeterminada e vários locais podem preceder uma determinada transição, o que o torna muito útil para modelar problemas de sincronização. Figura 3 Exemplo de rede de Petri com temporização no lugar, representando um GET.

35 2.4. Álgebra Max-Plus 33 Sistemas que podem ser representados por GET s têm a grande vantagem de poderem ser modelados através de equações lineares em espaço de estados na chamada álgebra max-plus, na forma x[k + 1] = Ax[k] Bu[k], o que será explicado na subseção Álgebra Max-Plus Definição A álgebra max-plus, também conhecida como álgebra tropical é um exemplo de uma estrutura algébrica denominada dióide ou semi-anel idempotente (Baccelli et al. (1992)) na qual: onde representa o máximo e a soma tradicional: Z max = (Z { },, ) (1) a b = max(a, b) e a b = a + b. O símbolo usualmente é omitido para o produto, portanto, ab na álgebra max-plus é lido como a b = a + b. Nós denotamos o elemento pelo símbolo ε, e ele será também ocasionalmente denotado por elemento nulo. Exemplo: 5 2 = max(5, 2) = = = = max(1, 3) = = = Extensão Matricial Existe também uma analogia matricial da álgebra tradicional para a álgebra max-plus. Dado um número natural positivo, n, a n-ésima ordem matricial na álgebra max-plus, T n n max, é uma dióide na qual T n n max = (Z {, }) n n, que é a matriz quadrada de ordem n na qual todas as entradas são números inteiros ou ε. Assim, dada as matrizes A e B T n n max, a soma matricial na álgebra max-plus é definida como: {A B} ij = A ij B ij (2) que é completamente análogo à soma matricial tradicional (bastando substituir + por max). No mesmo caminho, o produto matricial na álgebra max-plus é definido como: n {A B} ij = A ik B kj (3) k=1

36 34 Capítulo 2. Conceitos Preliminares que também é análogo ao produto matricial tradicional, bastando substituir + por max e por +. Exemplo: Considerando duas matrizes quadradas, de ordem 2, dadas por: então: A = , B = 4 ε 6 1 max(2, 4) max(1, ε) A B = = 4 1 max(5, 6) max(3, 1) 6 3 max(2 + 4, 1 + 6) max(2 + ε, 1 + 1) A B = = 7 2. max(5 + 4, 3 + 6) max(5 + ε, 3 + 1) 9 4 Lembrando que, de agora em diante, o símbolo também será omitido para o produto matricial, e portanto AB = A B Análise Espectral Autovetor e Autovalor Consideremos A T n n max. Um autovetor de A com autovalor associado λ Q { } é qualquer vetor v (Q { }) n ε (isto é, que tem pelo menos uma entrada diferente de ε) tal que Av = λv. Para exemplificar consideremos: A = ε 1 2 ε que claramente tem todas as suas entradas em T max. As equações para o autoproblema Av = λv são lidas na álgebra tradicional como: 1 + v 2 = λ + v v 1 = λ + v 2. Esta equação é linear no sentido tradicional e tem como solução geral v 1 = α, v 2 = α + 1/2 e λ = 3/2 para qualquer α. Podemos ver que λ é necessariamente um número racional não inteiro (mesmo que α possa ser escolhido de modo que v tenha apenas entradas inteiras, por exemplo, α = 1/2). Na prática, no entanto, pode-se supor sem perda de generalidade que α e v têm entradas no T max. Isso se deve

37 2.4. Álgebra Max-Plus 35 ao fato de que é possível redefinir as dimensões do problema para garantir que os autovetores e os autovalores tenham apenas um número inteiro ou entradas ε. Grafo de Precedência e Matriz Incidência Consideremos A T n n max. O grafo de precedência de A é um grafo ponderado com n nós e um arco indo do nó i para j, com peso A ij, se e somente se A ij ε. Em geral, diz-se que A é a matriz de incidência deste grafo. Como exemplo, consideremos o grafo de precedência representado pela Figura 4: Figura 4 Exemplo de grafo de precedência. A matriz de incidência A, referente a este grafo, é dada por: ε 3 ε ε ε ε 1 6 A =. 2 ε ε 4 2 ε ε 1 Grafo Fortemente Conexo Consideremos A T n n max. Um grafo de A é dito ser fortemente conexo se para todo par de nós (i, j) desse grafo o nó j é alcançável a partir do nó i. Matriz Irredutível Uma matriz A T n n max é considerada irredutível se o grafo de precedência de A é fortemente conexo. Para uma matriz A irredutível existe um inteiro c que garante a seguinte propriedade de ciclicidade:

38 36 Capítulo 2. Conceitos Preliminares A k+c = λ c A k sendo que k é superior a um número inteiro K e λ representa o autovalor da matriz A. Essa ciclicidade define um comportamento periódico em regime permanente, após um regime transitório (Baccelli et al. (1992)). Caminho, Ciclo, Peso e Comprimento Consideremos uma matriz de incidência A de um grafo ζ. O caminho no grafo é a sequência de nós i[0] i[1] i[2]... i[k], onde k é dito ser o comprimento do caminho, enquanto A i[0]i[1] +A i[1]i[2] +...+A i[k 1]i[k] é o seu peso. O caminho é um ciclo se i[k] = i[0]. Como exemplo, consideremos o grafo da Figura 4. O caminho é um ciclo com tamanho 3 e peso 3 + ( 1) + 2 = 4. Raio Espectral O raio espectral de uma matriz A, ρ(a), é definido como o maior autovalor de A. Outra forma de se encontrar o raio espectral é analisando todos os ciclos médios simples (sem autolaços) do grafo de precedência da matriz A. O raio espectral, neste caso, será o maior valor de ciclo médio encontrado. O valor do ciclo médio é encontrado dividindo o peso do ciclo pelo seu tamanho. Por exemplo, na Figura 4, o ciclo médio formado pelos nós é dado por [3 + ( 1) + 2]/3 = 4/3. O maior valor de ciclo médio é aquele formado pelos nós cujo valor é [ ]/3 = 11/3. Portanto, o raio espectral da matriz A, que tem o gráfico de precedência representado pela Figura 4, é ρ(a) = 11/ Sistemas Dinâmicos em Max-Plus Conexão da Álgebra Max-Plus com Grafo a Evento Temporizado Conforme mencionado na seção 2.3, os sistemas que podem ser representados por um GET têm a grande vantagem de poderem ser modelados através de equações lineares evento-invariante na álgebra max-plus na forma: x[k + 1] = Ax[k] Bu[k] (4) y[k] = Cx[k] Gu[k] (5)

39 2.5. Sistemas Dinâmicos em Max-Plus 37 onde x[k] T n max, u[k] T n max, y[k] T d max, A T n n max, B T n m max, C T d n max e G T d m max. As Equações 4 e 5 são similares às equações do sistema dinâmico linear invariantes no tempo, da álgebra tradicional, com a diferença de que aqui o k representa um evento e não o tempo, e a soma e o produto tradicional são substituídos pela soma e produto max-plus. Nesta seção mostraremos como é realizada essa modelagem a partir do GET exemplo mostrado na Figura 5. Figura 5 Exemplo de um grafo a evento temporizado (GET), para modelagem através de equações lineares em espaço de estados na álgebra max-plus. O primeiro passo é classificar as transições como entradas, estados ou saídas. As entradas são todas as transições que não possuem nenhum lugar conectado a elas, as saídas são todas as transições que não são conectadas a nenhum lugar e os estados são todas as transições restantes. Conforme vemos na Figura 5 o sistema possui uma entrada (u 1 ), três estados (x 1, x 2 e x 3 ) e uma saída (y 1 ). Os números acima de cada lugar do grafo representam a temporização do lugar, ou seja, o tempo mínimo que a ficha deve permanecer ao chegar ao lugar para que possa habilitar a transição. Agora, consideremos a transição x 1. É preciso descobrir, em primeiro lugar, todos os lugares que estão conectados a ela, e as respectivas transições para cada um desses lugares (haverá apenas uma transição atribuída a cada local, devido ao fato de que a rede de Petri é um grafo a evento temporizado). No caso de x 1, existem três: u 1, com um lugar com 1 unidade de tempo e uma ficha; x 2, com um lugar com 3 unidades de tempo e uma ficha; x 3, com um lugar com 0 unidades de tempo e duas fichas; Para x 1 disparar pela (k + 1)-ésima vez, u 1 precisa ter disparado pela k-ésima vez (já que existe uma ficha) e esperado pelo menos 1 unidade de tempo (o tempo mínimo de retenção da ficha no lugar). Além disso, x 2 precisa ter disparado pela k-ésima vez

40 38 Capítulo 2. Conceitos Preliminares (já que existe uma ficha) e esperado pelo menos 3 unidades de tempo, o tempo mínimo de espera naquele lugar. Finalmente, também é necessário que x 3 tenha disparado pela (k 1)-ésima vez (já que existem duas fichas) e esperado 0 unidades de tempo (não há tempo de espera mínimo neste caso). Assim, podemos escrever que: x 1 [k + 1] max(x 3 [k 1], x 2 [k] + 3, u 1 [k] + 1) e seguindo o mesmo raciocínio podemos derivar a seguinte equação para x 2, x 3 e y 1 : x 2 [k + 1] 2 + x 1 [k + 1] x 3 [k + 1] 6 + x 2 [k + 1] y 1 [k] 1 + x 3 [k]. Então, as equações para o primeiro tempo de disparo são obtidas trocando-se a desigualdade por uma igualdade, já que temos a política de disparar o mais cedo possível: x 1 [k + 1] = max(x 3 [k 1], 3 + x 2 [k], 1 + u 1 [k]) x 2 [k + 1] = 2 + x 1 [k + 1] x 3 [k + 1] = 6 + x 2 [k + 1] y 1 [k] = 1 + x 3 [k]. Note que na equação para x 1 [k + 1], um termo no evento k 1, a saber x 3 [k 1], aparece à direita. Além disso, na equação para x 2 [k + 1], um termo no evento k + 1, a saber x 1 [k + 1], aparece à direita. Também na equação para x 3 [k + 1], um termo no evento k + 1, a saber x 2 [k + 1], aparece à direita. Para escrever essas equações como na Equação 4, somente atrasos de ordem k nos estados podem estar no lado direito da equação. O problema para x 3 [k 1] pode ser resolvido criando um novo estado x 4 [k] e uma nova equação x 4 [k + 1] = x 3 [k]. Desta forma, o GET do sistema com a inclusão da nova variável é representado pela Figura 6 e as equações para o primeiro tempo de disparo representadas como: x 1 [k + 1] = max(x 4 [k], 3 + x 2 [k], 1 + u 1 [k]) x 2 [k + 1] = 2 + x 1 [k + 1] x 3 [k + 1] = 6 + x 2 [k + 1] x 4 [k + 1] = x 3 [k] y 1 [k] = 1 + x 3 [k]. Para resolver o problema para x 1 [k + 1] e x 2 [k + 1] basta substituir a primeira equação na segunda, e depois a segunda na terceira, de forma que: x 1 [k + 1] = max(x 4 [k], 3 + x 2 [k], 1 + u 1 [k])

41 2.5. Sistemas Dinâmicos em Max-Plus 39 Figura 6 Grafo a evento temporizado (GET) com a inclusão do estado x 4. x 2 [k + 1] = max(2 + x 4 [k], 5 + x 2 [k], 3 + u 1 [k]) x 3 [k + 1] = max(8 + x 4 [k], 11 + x 2 [k], 9 + u 1 [k]) x 4 [k + 1] = x 3 [k] y 1 [k] = 1 + x 3 [k]. Usando a notação da álgebra max-plus, temos: x 1 [k + 1] = x 4 [k] 3x 2 [k] 1u 1 [k]) x 2 [k + 1] = 2x 4 [k] 5x 2 [k] 3u 1 [k]) x 3 [k + 1] = 8x 4 [k] 11x 2 [k] 9u 1 [k]) x 4 [k + 1] = x 3 [k] y 1 [k] = 1x 3 [k]. (6) As equações em 6 podem, portanto, serem escritas de forma matricial conforme as Equações 4 e 5: x 1 [k + 1] x 2 [k + 1] x 3 [k + 1] x 4 [k + 1] = ε 3 ε 0 ε 5 ε 2 ε 11 ε 8 ε ε 0 ε x 1 [k] x 2 [k] x 3 [k] x 4 [k] ε u 1 [k] y 1 [k] = ( ε ε 1 ε ) x 1 [k] x 2 [k] x 3 [k] x 4 [k] ( ) ε u1 [k].

42 40 Capítulo 2. Conceitos Preliminares Controle na Álgebra Max-plus Dado um sistema modelado através de equação em espaço de estados lineares em maxplus, x[k + 1] = Ax[k] Bu[k], pode ser necessário que um conjunto de especificações seja satisfeito. Isso pode ser feito manipulando as variáveis de controle para projetar uma lei de controle. Muitos trabalhos já foram publicados de forma a sintetizar controladores para este problema, quando as especificações podem ser escritas como equações lineares max-plus no espaço de estados (Katz (2007), Maia, Andrade e Hardouin (2011), Amari et al. (2012), Gonçalves, Maia e Hardouin (2016), Kim e Lee (2016), Gonçalves, Maia e Hardouin (2017)). Existem vários objetivos de controle, mas no caso específico deste trabalho estamos interessados em projetar uma lei de realimentação de estado da forma u[k] = F x[k] que conduza o estado do sistema dinâmico a uma especificação definida, em um número finito de eventos, e a mantenha lá depois, em estado estacionário. Queremos que isso ocorra para qualquer condição inicial. Esse problema de regulação contempla especificações escritas linearmente na forma Ex[k] = Dx[k]. Essas especificações podem ser, por exemplo, que a diferença do tempo de saída e entrada de um peça em um forno não seja superior a um determinado valor, evitando-se assim sobreaquecimento. Também pode ser, por exemplo, que duas peças cheguem sincronizadas a um determinado ponto da linha de produção (ou seja, a diferença de tempo seja nula). Os trabalhos de Gonçalves, Maia e Hardouin (2017), Gonçalves (2014) nos fornecem condições necessárias e suficientes (salvo algumas exceções muito específicas) para a resolução desse tipo de problema. Lá é definida o que o artigo chama de equação característica de controle : λχ = Aχ Bμ Eχ = Dχ (7) na qual λ Z, χ Z n max e μ Z m max. A solução {λ, μ, χ} é dita ser própria se χ não tiver entradas ε. Cada uma das incógnitas relaciona uma característica específica do sistema em estado estacionário. O escalar λ comanda a taxa do sistema (disparos/unidade de tempo) em regime permanente, de modo que quanto maior for esse número, mais lento será o sistema em malha fechada. O vetor χ está relacionado ao estado x[k] no estado estacionário: ele será um múltiplo escalar dele, isto é, no estado estacionário x[k] = hλ k χ para um escalar h(x 0 ) que depende da condição inicial. Finalmente, o vetor μ está relacionado com a entrada em regime permanente: u[k] = hλ k μ para o mesmo escalar h(x 0 ). A Equação 7 é condição necessária (Gonçalves, Maia e Hardouin (2017)), ou seja, se a equação não tiver solução o problema de controle também não terá solução. Ela é quase sempre suficiente, ou seja, existe uma classe ampla de problemas de controle na qual ela é suficiente: quando se resolve a equação é possivel achar a solução do problema. Mas

43 2.5. Sistemas Dinâmicos em Max-Plus 41 existe uma classe bem específica de problemas em que pode-se achar uma solução, mas ela não fornece diretamente a solução do problema (ver Gonçalves, Maia e Hardouin (2017) para mais detalhes). A equação característica de controle (Equação 7) pode ser resolvida tranformando-a em um problema de autovalor de dois lados, definido como: λup = V p (8) onde U e V são dados. Existem diversos algoritmos para a resolução dessa equação (Gonçalves, Maia e Hardouin (2017)). Uma vez resolvida a equação e encontrados os parâmetros {λ, μ, χ}, encontramos a lei de controle do sistema definida por: u[k] = F x[k] = μ( χ) T x[k] (9) onde a matriz estática F é simplesmente o cômputo de μ( χ) T. Já o valor de λ encontrado é o tempo de ciclo do sistema em malha fechada, ou seja, se encontrarmos λ = 30 segundos, por exemplo, significa que quando fecharmos a malha ocorrerá em média um evento a cada 30 segundos. Pode ser que no cômputo de F encontremos uma matriz não-causal, onde um ou mais de seus elementos seja um negativo diferente de ε. Isso exigirá uma predição dos estados. Neste caso é necessário utilizar técnicas para causalização de F, o que será discutido na seção 4.2. Outra característica do controlador definido pela Equação 9 é que ele controla para qualquer condição inicial x 0, o que implica em uma propriedade de robustez muito interessante. Se o sistema convergir para um conjunto de especificações desejadas e sair desse conjunto devido a uma perturbação, então, após um número finito de etapas, ele retornará para esse conjunto desejado, rejeitando a perturbação. Isso porque podemos considerar um novo sistema no qual, a condição inicial é o estado perturbado, as dinâmicas são as mesmas que a do sistema antigo e o evento k é zerado para 0. Já que a convergência acontece para cada condição inicial e os parâmetros do sistema dinâmico independem de k, a convergência também é garantida para este novo sistema e, eventualmente, a rejeição da perturbação é alcançada. A fim de demonstrar algebricamente o cálculo de um controlador utilizando o método do trabalho de Gonçalves, Maia e Hardouin (2017), consideremos como exemplo um sistema, onde as matrizes A, B, E e D são definidas como: A = 1 ε ε 2, B = 0 0, E = ( 0 ε ), D = ( ε 0 ). Substituindo as matrizes dadas na Equação 7 temos: λ χ 1 χ 2 = 1 ε ε 2 χ 1 χ 2 0 μ 0

44 42 Capítulo 2. Conceitos Preliminares ( ) 0 ε χ 1 = ( ε 0 χ 2 e explicitando em equações escalares: ) χ 1 χ 2 λχ 1 = 1χ 1 μ λχ 2 = 2χ 2 μ χ 1 = χ 2. (10) Como as equações em (10) são Max-Plus homogêneas em χ e μ ( se (λ, χ, μ) é solução, (λ, αχ, αμ) é solução para um α escalar), temos que arbitrar um dos elementos de χ ou de μ. Então arbitramos μ = 0 (μ é um escalar). Logo temos: λχ 1 = 1χ 1 0 λχ 2 = 2χ 2 0 onde: λχ 1 1χ 1 λ 1 λχ 2 2χ 2 λ 2. Como solução das equações acima, temos que λ 2. Adotando, por exemplo, λ = 3, temos: 3χ 1 = 1χ 1 0 3χ 1 = 0 3χ 2 = 2χ 2 0 3χ 2 = 0 onde: χ = χ 1 χ 2 = 3 3 Com os valores de χ e μ, substituindo na Equação 9, temos a expressão do controlador para esse exemplo:. u[k] = 0 ( 3 3 ) x[k] = ( 3 3 ) x[k]. O método do trabalho de Gonçalves, Maia e Hardouin (2017) também será utilizado para controlar uma versão simulada de uma planta, o que será visto no Capítulo 3.

45 43 Capítulo 3 Sistema Considerado 3.1 Apresentação Conforme mencionado no Capítulo 1, estamos interessados em estudar os aspectos práticos de um controlador. Como realizar esses estudos em uma planta real pode ser inviável, umas das contribuições deste trabalho é o desenvolvimento de um simulador realista, baseado em uma planta existente, para realizar testes e validação das técnicas de controle. A implementação do simulador baseia-se em um sistema de correia transportadora que está localizado no Laboratório Angevin de Pesquisa em Engenharia de Sistemas (LARIS) da Universidade de Angers França. A descrição da planta e todo o seu funcionamento pode ser visto detalhadamente no trabalho de Gonçalves (2014). Basicamente, esse sistema move paletes através de dois circuitos independentes, conforme representado pela Figura 7. Esse sistema por meio de sinais externos, permite o bloqueio dos paletes utilizando botões distribuídos em diferentes partes do circuito. O tempo em que é desejável para abaixar ou levantar os botões são as entradas do sistema. Ao longo dos circuitos existem sensores de proximidade (próximos aos botões) que permitem a detecção do palete. Esses sensores fornecem as saídas do sistema, que são os tempos em que um palete passou através de um dado ponto. A arquitetura de controle da planta pode ser vista detalhadamente na seção 3.3. Na Figura 8 temos representado o esquema do sistema visto de cima, onde podemos ver que o sistema é composto de dois circuitos independentes, com dez botões (B1 a B10) e dez sensores de proximidade (um sensor um pouco antes de cada botão). No circuito superior temos os botões B1 à B4 e três paletes, localizados inicialmente um pouco antes de B1, que se movem em sentido horário. Já no circuito inferior temos os botões B5 à B10 e também três paletes, dois deles localizados imediatamente um pouco antes de B5 e outro um pouco antes de B6, todos se movendo em sentido anti-horário. Os botões são programados de modo que, quando acionados (abaixados) permitem a passagem do palete e voltam automaticamente para cima em 2 segundos. Essa temporização garante

46 44 Capítulo 3. Sistema Considerado Figura 7 Foto do sistema no Laboratório Angevin de Pesquisa em Engenharia de Sistemas (LARIS) da Universidade de Angers - França. Fonte: Gonçalves (2014, p. 116) que, se mais de um palete estiver esperando na fila, quando o botão dispara uma vez, apenas um palete continua o percurso. Os circuitos do sistema são dividos em trechos, que correspondem ao caminho entre dois botões sucessivos e cada trecho possui uma capacidade de palete e um tempo associados. Essa temporização representa o tempo que um palete precisa ir de pouco antes do botão inicial para o botão sucessivo quando não há nada no caminho (tempo mínimo). Por exemplo, no trecho B1 B2 temos um limite máximo de 3 paletes e uma temporização de 8 segundos, ou seja, um palete ao sair de B1 leva 8 segundos para chegar em B2. Já no trecho B9 B10 temos um limite máximo de 2 paletes e uma temporização de 2 segundos, ou seja, um palete ao sair de B9 leva 2 segundos para chegar em B10. O sistema é programado de forma que, se o trecho para onde o palete está se dirigindo estiver cheio, o botão não dispara (desce), não permitindo a passagem do palete. Para que um dado botão do sistema dispare três condições precisam ser satisfeitas: (I): deve haver pelo menos um palete esperando antes do botão; (II): deve haver pelo menos um espaço vazio no trecho para onde o palete está se movimentando, ou seja, o trecho não pode estar em sua capacidade máxima; (III): deve haver uma ficha de permissão para botão, o que representa uma ação externa do sistema;

47 3.1. Apresentação 45 Figura 8 Esquema do sistema de transporte da planta de Angers visto de cima. Fonte: Gonçalves (2014, p. 118) No sistema também temos uma sincronização forçada entre os circuitos superior e inferior usando os botões B3 e B10. Desta forma, mesmo que o botão B3 tenha as condições para disparo satisfeitas, ele somente irá disparar (abaixar) se o botão B10 também tiver as condições satisfeitas e vice-versa. Dessa forma, seus acionamentos são sempre sincronizados. Esse intertravamento entre os botões não é físico e sim realizado através de uma lógica no Controlador Lógico Programável (CLP) que realiza a interface com a planta. Uma observação importante a ser feita é que na planta real não existem alguns sensores utilizados no desenvolvimento do simulador e que são necessários para fazer controle por realimentação de estado. Esses sensores, chamados de sensores virtuais, medem o tempo de chegada do palete em cada posição antes de cada botão do sistema, onde não existem sensores físicos instalados. Por exemplo, no trecho B1 B2, que possui três paletes de capacidade, cada palete pode se situar em três posições diferentes antes do botão B2, que são: Posição 1: palete parado em primeiro lugar na linha um pouco antes de B2; Posição 2: palete parado em segundo lugar na linha um pouco antes de B2; Posição 3: palete parado em terceiro lugar na linha um pouco antes de B2;

48 46 Capítulo 3. Sistema Considerado Nesse caso, o tempo de chegada na Posição 1 é medido por um sensor físico (sensor de proximidade) instalado um pouco antes do botão B2. Já os tempos de chegada nas Posições 2 e 3 são medidos através de sensores virtuais, que são programados no simulador. Como na planta real esses sensores virtuais não existem, é necessário fazer uma realimentação por saída (apenas alguns dos estados são medidos) ou um observador (ver Gonçalves et al. (2014)). A análise do controle por observadores (realimentação por saídas) não será o foco deste trabalho e ficará como oportunidades futuras de estudo. A Figura 9 nos mostra a representação da planta de Angers por um GET (ver definição na seção 2.3), o que permite a modelagem desse sistema através de equações lineares em espaço de estados na álgebra max-plus, conforme será demonstrado na seção 3.2. As transições amarelas representam botões, a parte vermelha diz respeito às entradas e as partes verdes às saídas. Os números acima de cada local representam o tempo que um palete precisa ir de pouco antes do botão inicial para o botão sucessivo quando não há nada no caminho (tempo mínimo). Quando esse número é ausente, é considerado tempo nulo. 3.2 Modelagem do Sistema Considerado Em malha aberta, a planta de esteiras de Angers, detalhada na seção 3.1, pode ser vista como um sistema da forma representada pela Figura 10, onde temos como entrada o vetor u[k] que representa o tempo de entrega das fichas de permissão aos botões. Cada botão do sistema possui um vetor u i [k] independente e cada posição desse vetor, indexado pelo evento k, armazena esse tempo de entrega. Ou seja, u 2 [8] na Figura 9, representa o tempo de entrega da nona ficha de permissão para o botão B2 (lembrando que o índice k se inicia em 0 ). Como saída do sistema temos o vetor x[k] que representa o evento de interesse, que são os tempos de chegada de um palete em um determinado botão. Ou seja, x 4 [3] na Figura 9, representa o tempo em que um palete chegou pela quarta vez ao botão B2 (lembrando que o índice k se inicia em 0 ). Portanto, as entradas u i [k] influenciam nas saídas x i [k], ou seja, dependendo do tempo em que são entregues as fichas de permissão, temos diferentes tempos de chegada dos paletes aos botões. A planta de Angers pode ser modelada como SED cuja dinâmica de evolução dos estados é definida por x[k +1]=f(x[k], u[k]), que nos diz que o próximo estado é calculado em função do estado atual e da entrada atual. Como o sistema é classificado como um GET (Figura 9), a equação de evolução de estados tem a conveniência de poder ser linearizada na forma x[k + 1] = Ax[k] Bu[k] e todo o sistema pode ser modelado utilizando essa equação (conforme demonstrado na subseção 2.5.1). A Figura 11 nos mostra as matrizes A, B T e C resultantes da modelagem da planta de Angers. Uma vez modelado o sistema, podemos desejar impor algum objetivo de controle e computar um controlador que atenda as especificações desejadas. Na planta de Angers,

49 3.2. Modelagem do Sistema Considerado 47 Figura 9 Grafo a evento temporizado da planta de Angers. Fonte: Gonçalves (2014, p. 122) Figura 10 Modelo em malha aberta da planta de Angers. sabemos que os botões B3 e B10 são sincronizados. Se esses botões forem deixados incontroláveis, pode acontecer de um palete ter que esperar muito tempo atrás de um dos botões, esperando que um palete chegue atrás do outro botão. Então, uma especificação que poderia ser desejada, seria de um palete não esperar por muito tempo pelo outro palete. Na Figura 12 temos um exemplo dessa especificação, onde em (a) desejamos que um palete ao chegar um pouco antes do botão B3 não espere mais do que 20 unidades de tempo por um palete chegar próximo ao botão B10 e em (b) desejamos que um palete

50 48 Capítulo 3. Sistema Considerado Figura 11 Matrizes A, B T e C resultantes da modelagem da planta de Angers. ao chegar próximo ao botão B10 não espere mais do que 20 unidades de tempo por um palete chegar próximo ao botão B3. Analisando o GET (Figura 9) da planta de Angers podemos equacionar as especificações na forma: Para o palete esperando em B3: x 6 [k] x 22 [k] 20; Para o palete esperando em B10: x 22 [k] x 6 [k] 20;

51 3.2. Modelagem do Sistema Considerado 49 Figura 12 Exemplo de especificação de controle para a planta de Angers. onde o estado x 6 [k] indica a presença do palete antes do botão B3 e o estado x 22 [k] indica a presença do palete antes do botão B10. Transformando as inequações acima em equações lineares em max-plus temos: Para o palete esperando em B3: Para o palete esperando em B10: x 6 [k] 20x 22 [k] = 20x 22 [k]; x 22 [k] 20x 6 [k] = 20x 6 [k]; Portanto temos esse conjunto de especificações representado linearmente na forma da equação: Ex[k] = Dx[k] (11) onde as matrizes E e D são representadas na Figura 13. Figura 13 Matrizes de especificação E e D. Modelado o sistema e as especificações podemos encontrar um controlador da forma u[k] = f(x[k]) que garanta a convergência do sistema em regime permanente para um conjunto de especificações desejadas, e sua permanência nesse. Em muitos trabalhos como (Katz (2007), Maia, Andrade e Hardouin (2011), Amari et al. (2012), Gonçalves, Maia

52 50 Capítulo 3. Sistema Considerado e Hardouin (2016), Kim e Lee (2016), Gonçalves, Maia e Hardouin (2017)) obtemos esse controlador como realimentação linear de estados, ou seja, u[k] = F x[k] para uma matriz fixa F. Mas será o trabalho de Gonçalves, Maia e Hardouin (2017), brevemente apresentado na subseção 2.5.2, que será adotado na implementação do controle no simulador (seção 4.3) pois é nele que obtemos condições matemáticas que são sempre necessárias (se violar as equações não há solução para o problema de controle) e suficientes (se a equação tiver solução, o problema de controle tem solução) para uma ampla gama de problemas. É também o primeiro trabalho, de conhecimento do autor, a garantir propriedades matemáticas de robustez para o controlador. 3.3 Arquitetura de Controle Na planta real, todo o sistema recebe comandos de um CLP, que por sua vez, recebe ações diretamente da sua interface de usuário ou através de um programa C++ em um computador conforme mostrado na Figura 14. O sistema pode ser dividido como: Figura 14 Arquitetura do controle da planta de Angers. Computador - Usando uma programação em C++ é realizado o cálculo dos parâmetros do controlador (matriz F ), por meio das matrizes A e B do sistema e as especificações inseridas pelo usuário. Caso a matriz F encontrada seja não-causal (ver seção 4.2), um algoritmo de causalização é utilizado para permitir a implementação do controlador. O computador recebe do CLP as informações de estado x[k] da planta e, juntamente com a matriz F obtida, realiza o cálculo do controlador u[k] = F x[k]. Estes eventos x[k], no caso da planta de Angers, são os tempos de chegada dos paletes antes dos botões, que são medidos pelos sensores de proximidade instalados próximos aos botões. O algoritmo para o cálculo de u[k] é relativamente simples, onde uma dada entrada u i [k] somente será computada quando ocorrerem todos os eventos de estados associados a um valor diferente de ε da matriz F. Por exemplo, considere o sistema diferente da planta de Angers, composto de 3 estados e três entradas, com a lei de controle dada por:

53 3.3. Arquitetura de Controle 51 u 1 [k] u 2 [k] u 3 [k] = ε ε ε x 1 [k] x 2 [k] x 3 [k]. Para o cômputo de u 1 [k] definido por: u 1 [k] = εx 1 [k] 2x 2 [k] 4x 3 [k] o algoritmo aguarda a ocorrência dos eventos de estado x 2 [k] e x 3 [k] para realizar o cálculo. Repare que indifere a ocorrência do evento x 1 [k], visto que ele está associado a um valor ε. Portanto, as entradas u 1 [k], u 2 [k] e u 3 [k] podem ser computadas em tempos diferentes. Por exemplo, a entrada u 2 [k] depende apenas da ocorrência do evento x 1 [k], mas isso não significa que ela será computada primeiro que a entrada u 1 [k], pois os eventos x 2 [k] e x 3 [k] podem ocorrer primeiro que o evento x 1 [k]. A programação desta forma é bastante eficiente pois evita cálculos desnecessários otimizando o processamento do computador; CLP - Responsável por toda a interface com a planta de Angers. Ele registra as informações vindas dos sensores de presença da planta, que representam o tempo que um determinado palete passa por um dado botão, ou seja, quando um sensor na planta é atuado, o CLP registra imediatamente o tempo daquela atuação referente aquele sensor. Portanto, no CLP temos registrado todas as informações de estado x[k] da planta, que são enviadas para o computador para o cálculo do tempo de disparo dos botões (u[k]). O CLP recebe do computador e armazena os tempos de disparo u[k] para cada um dos botões e realiza o acionamento dos botões quando esse tempo é alcançado. Um função que é implementada logicamente no CLP é o intertravamento dos botões B3 e B10. Conforme descrito na seção 3.1 esses botões possuem seus acionamentos sincronizados; Planta - Neste nível temos a planta de Angers, que se comunica diretamente com o CLP enviando as informações dos sensores de presença instalados próximos aos botões e recebendo os comandos de acionamento dos botões;

54 52 Capítulo 3. Sistema Considerado

55 53 Capítulo 4 Contribuições 4.1 Introdução Com relação às várias técnicas para síntese de controladores max-plus disponíveis na literatura (Katz (2007), Maia, Andrade e Hardouin (2011), Amari et al. (2012), Maia, Hardouin e Cury (2013), Gonçalves, Maia e Hardouin (2016), Kim e Lee (2016), Gonçalves, Maia e Hardouin (2017)) temos dois problemas práticos importantes que ainda não foram amplamente discutidos na literatura e que foram o foco de desenvolvimento deste trabalho. O primeiro deles é quando um controlador, expresso pela lei u[k] = F x[k], é não-causal, isto é, demanda em um determinado momento o conhecimento de um valor que só será obtido no futuro. Nesse caso, há a necessidade de se usar técnicas de causalização, isso é, transformar o controlador em algo equivalente que possa ser implementado. De nosso conhecimento, somente o trabalho de Maia, Hardouin e Cury (2013) trata de técnicas de causalização para controladores por realimentação de estado genéricos. No entanto essa técnica demonstra ser pouco robusta uma vez que se utiliza de informações de estados muito atrasadas. A primeira contribuição deste trabalho, portanto, é abordar e discutir uma nova técnica de causalização que se utiliza, além de informações atrasadas, também de informações recentes e comprovar que ela é mais robusta na medida que leva menos eventos para convergir ao conjunto desejado. Essa contribuição também foi publicada em nosso trabalho (Souza e Gonçalves (2018)). O segundo problema prático encontrado é que geralmente a validação das técnicas de controle é realizada no próprio modelo max-plus de síntese do controlador e não em situações reais ou mesmo em situações realistas, o que levanta dúvidas se o controlador funcionará para a planta real em que este modelo foi baseado ou mesmo se ele reagirá a perturbações que normalmente acontecem em sistemas reais. De fato, de nosso conhecimento, apenas o trabalho de Gonçalves (2014) relatou na literatura uma implementação real desse tipo de controlador. Nesse caso, o controlador desenvolvido foi empregado com sucesso para controlar a planta real apresentada no Capítulo 3, e foi capaz de rejeitar perturbações causadas naturalmente pelo sistema. Mas, infelizmente, plantas como aque-

56 54 Capítulo 4. Contribuições las geralmente não estão prontamente disponíveis, pois necessitam de parametrizações e requerem a presença de um profissional experiente para manuseá-la. Além disto, devido à dinâmica da planta, testes simples podem demorar muito tempo para serem concluídos, o que torna a realização de vários testes inviável. Pensando nessas considerações, a segunda contribuição deste trabalho foi desenvolver um simulador da planta apresentada no Capítulo 3. Como as características de interesse da planta (movimento dos paletes, colisões entre eles, colisões com os botões, detecção da chegada de paletes, etc...) não têm uma natureza física muito complexa como em processos químicos, térmicos e elétricos, por exemplo, foi possível desenvolver um simulador bastante realista. Com este simulador é possível validar as técnicas de controle de maneira rápida e eficiente além de realizar testes com perturbações realistas que geralmente são abstraídas no modelo max-plus. 4.2 Causalização de Controladores Neste trabalho, estamos interessados em obter um controlador que atenda um conjunto de especificações desejado. Esse controlador é uma realimentação linear de estados, cuja lei de controle é definida por u[k] = F x[k] e pode ser obtido conforme descrito na subseção Acontece que, como mencionado anteriormente, podemos encontrar um controlador que seja não-causal. Isso acontece quanto a matriz estática F é não-causal, ou seja possui pelo menos um elemento negativo diferente de ε. Para exemplificar, considere a matrizes F 1, F 2 e F 3, onde F 1 e F 2 são causais, enquanto que F 3 é não-causal, pois possui um elemento negativo diferente de ε, a saber 5. F 1 = F 2 = 2 1 ε 3 F 3 = 5 ε. ε 4 O problema de F ser uma matriz não-causal, é que não conseguimos implementar o controlador fisicamente, já que o valor negativo implica em predições de valores de estado. Para mostrar essa situação, consideremos como exemplo a matriz F 3 não-causal mostrada acima e uma lei de controle definida por: u 1[k] u 2 [k] = ou, explicitando as equações escalares: 5 ε x 1[k] ε 4 x 2 [k] u 1 [k] = ( 5)x 1 [k] (12) u 2 [k] = 4x 2 [k]. (13) Podemos observar pela Equação 13, que a entrada u 2 [k] é implementável e a sua lei nos diz que o seu disparo sempre ocorre 4 unidades de tempo após a ocorrência do evento x 2 [k]. Já na Equação 12, vemos que u 1 [k] não pode ser implementado, em princípio,

57 4.2. Causalização de Controladores 55 visto que a sua lei de controle nos diz que seu disparo deve ocorrer 5 unidades de tempo antes do evento x 1 [k] ocorrer. Ou seja, quando o evento x 1 [k] ocorre, já se passou o tempo previsto para o disparo da entrada u 1 [k], e disparar essa entrada em qualquer outro tempo não é garantia de que o controle seja mantido. Neste caso, para que essa regra seja implementada fisicamente, para o disparo de u 1 [k], é necessário prever qual o tempo de disparo de x 1 [k]. Desta forma, causalizar o controlador significa submeter um controlador não implementável fisicamente à técnicas de causalização de forma a torná-lo implementável. As seções seguintes abordarão essas técnicas, sendo na subseção abordada a técnica de causalização existente na literatura (Maia, Hardouin e Cury (2013)) e na subseção desenvolvida uma nova técnica (1 a contribuição deste trabalho) para essa causalização Técnica de causalização existente Do conhecimento dos autores, na literatura atual temos apenas uma técnica, Maia, Hardouin e Cury (2013), para a causalização de controladores por realimentação de estados genéricos. Seu funcionamento será descrito a seguir. Consideremos uma lei de controle não realizável dada por: u[k] = F nc x[k] (14) onde a matriz F nc é não-causal, ou seja, pelo menos um de seus elementos é um negativo diferente de ε. Aplicando essa lei de controle no modelo matemático da planta, dado por x[k] = Ax[k 1] Bu[k 1], temos o modelo matemático da planta em malha fechada, dado por: x[k] = (A BF nc )x[k 1] (15) O que essa técnica faz é realizar a predição de informações dos estados até que tenhamos um controlador que seja implementável. Em um primeiro momento ela prediz o valor do estado x[k] (Equação 15) e substitui na Equação 14. Assim, temos: u[k] = F nc (A BF nc )x[k 1] (16) Nessa nova expressão do controlador se o resultado de F nc (A BF nc ) for uma matriz causal, então o controlador passa a ser implementado a partir da informação de estado atrasada em um evento. Caso contrário, se o resultado for uma matriz não-causal, o controlador ainda não é implementável e a técnica continua a fazer a predição, nesse caso para o estado x[k 1]. Pela Equação 15 sabemos que: x[k 1] = (A BF nc )x[k 2] (17) Logo, substituindo x[k 1] da Equação 16 pela Equação 17, temos:

58 56 Capítulo 4. Contribuições u[k] = F nc (A BF nc )(A BF nc )x[k 2] (18) Agora, nessa nova expressão, se o resultado de F nc (A BF nc )(A BF nc ) for uma matriz causal, então o controlador passa a ser implementado a partir da informação de estado atrasada em dois eventos. Caso contrário, o controlador ainda não é implementável e a técnica continua a fazer a predição, agora para o estado x[k 2]. A predição continua até que obtenhamos uma matriz causal, e consequentemente um controlador implementável. Eventualmente, é demonstrado em Maia, Hardouin e Cury (2013) que é possível encontrar uma matriz causal F mc = F nc (A BF nc ) m, incrementando-se m quantas vezes preciso, desde que a matriz A BF nc seja uma matriz irredutível com autovalor maior que 0. Quando isso acontecer teremos um controlador, que é definido genericamente por: u[k] = F nc (A BF nc ) m x[k m] (19) para um m qualquer e todo k m. Repare que a medida que aumentamos o valor de m para causalizar a matriz, mais atrasado se torna o nosso controlador. Uma desvantagem dessa técnica é que ela realiza, muitas vezes, a predição de informações desnecessárias. Afim de comprovarmos essa afirmação, consideremos como exemplo a seguinte lei de controle: que: u[k] = F x[k] = 1 ε ε 1 x[k] Trata-se de um controlador não implementável, pois a matriz F é não causal. Temos u 1 [k] = 1x 1 [k] (20) u 2 [k] = ( 1)x 2 [k]. (21) Note que parte desse controlador é implementável, a saber a ação de controle u 1 [k] cujo tempo de disparo é uma unidade de tempo após o tempo de acontecimento do evento x 1 [k]. Já a outra parte, a ação de controle u 2 [k] não é implementável, pois o seu tempo de disparo é duas unidades de tempo antes do tempo de acontecimento do evento x 2 [k]. Utilizando o princípio da técnica existente, que causaliza o controlador como um todo, e considerando um modelo matemático em malha fechada dado por: x[k] = x[k 1] temos a nova expressão do controlador, para esse exemplo, dada por: u[k] = x[k 1]

59 4.2. Causalização de Controladores 57 onde: u 1 [k] = 2x 1 [k 1] 2x 2 [k 1] (22) u 2 [k] = ( 2)x 2 [k]. (23) Repare que o controlador ainda não é implementável, mas a ação de controle u 1 [k] agora é implementável utilizando informações atrasadas de estado em um evento, sendo que antes essa ação de controle já era implementável utilizando informação de estado atual, sem necessidade de previsão, como mostrado na Equação 20. Ou seja, essa parte do controlador não precisava passar pelo processo de causalização Técnica de causalização proposta Da mesma forma que a técnica existente (Maia, Hardouin e Cury (2013)), a técnica proposta também utiliza da previsão de informações de estado para tornar o controlador implementável. A diferença é que essa técnica agora irá realizar a predição somente na parte do controlador que não é implementável, evitando-se assim predições desnecessárias. Essa técnica parte do princípio de que toda matriz não-causal pode ser desmembrada em sua parte causal e não-causal. Como exemplo, suponhamos uma matriz L, não-causal: L = ε Definindo-se um operador causal [.] c que irá desmembrar a matriz com sua parte causal (elementos 0 ou iguais a ε) e o operador não-causal [.] n que irá desmembrar a matriz com sua parte não-causal (elementos < 0 ou iguais a ε), temos que: [L] c = ε ε 1 4, [L] n = ε ε 2 ε de forma que [L] c [L] n = L. Seja um sistema representado, em max-plus, por: x[k + 1] = Ax[k] Bu[k] e um controlador u[k] = F x[k], possivelmente não-causal pois F pode ser não-causal. Temos a matriz de malha fechada definida como M = (A BF ). Então, separando-se F em sua parte causal [F ] c e não-causal [F ] n, temos: u[k] = [F ] c x[k] [F ] n x[k]. (24)

60 58 Capítulo 4. Contribuições Note que a parte [F ] c x[k] do controlador é implementável, pois não depende de previsões do futuro. A parte [F ] n x[k] não, ao menos que ela seja uma matriz toda de ε. Se for o caso dela ser ε, podemos parar. Caso não, note que assumindo que o controlador u[k] = F x[k] foi implementado, temos: x[k + 1] = (A BF )x[k] x[k + 1] = Mx[k]. (25) Então substituindo a Equação 25 somente na parte não-causal da Equação 24, temos: u[k] = [F ] c x[k] ([F ] n M)x[k 1]. (26) Note que a matriz ([F ] n M) pode ter alguns elementos 0, e de fato, tende a ter mais elementos positivos, uma vez que M tem raio espectral 0 e portanto a multiplicação por M tende a aumentar os elementos. Separando a parte causal e não-causal dessa matriz teremos: u[k] = [F ] c x[k] [([F ] n M)] c x[k 1] [([F ] n M)] n x[k 1]. (27) Note que agora temos os termos: [F ] c x[k] e [([F ] n M)] c x[k 1] que são implementáveis pois são causais. O termo [([F ] n M)] n x[k 1] não é causal. Mas temos através da Equação 25 que: x[k 1] = Mx[k 2]. Então, substituindo na parte não-causal da Equação 27, temos: u[k] = [F ] c x[k] [([F ] n M)] c x[k 1] [([([F ] n M)] n M)] c x[k 2] (28) [([([F ] n M)] n M)] n x[k 2]. E assim, continuamos com esse procedimento. Temos duas situações possíveis: a parte não-causal pode ser eventualmente ε ou isso pode nunca acontecer. Se acontecer, então nosso controlador será causal e da forma: s u[k] = F i x[k i] (29) i=0 com matrizes F i causais e um s finito, em que: F 0 = [F ] c F 1 = [([F ] n M)] c F 2 = [([([F ] n M)] n M)] c F 3 = [([([([F ] n M)] n M)] n M)] c...

61 4.2. Causalização de Controladores 59 e assim por diante. Entretanto, a sequência F n pode nunca terminar. Para exemplificar esse fato, tomemos como exemplo: F = ( 1 ε ), M = Podemos verificar que [F ] n = F e [F M] n = F. Então F 0 = [F ] c = ε e F 1 = F 2 = F 3 =... Nesse caso, a sequência nunca termina. Sobre esse fenômeno, enunciaremos dois resultados sem prova. Esses resultados serão detalhados em trabalhos futuros: Embora possa não terminar, a sequência F n é cíclica após um transiente, isso é, existem inteiros τ e σ tal que F τ+kσ = F τ para todo k. Assim, só existem matrizes novas até F τ+σ 1. Nesse caso, como os estados são naturalmente não decrescentes (x[k + 1] x[k]), podemos desconsiderar sem nenhuma perda as matrizes após F τ+σ 1 e implementar o controlador com as demais, como se a sequência tivesse terminado Comparação entre a técnica existente e a técnica proposta A fim de compararmos, o desempenho da técnica existente (subseção 4.2.1) com o da técnica proposta (subseção 4.2.2), consideremos um exemplo, onde as matrizes A e B do sistema são definidas como: A = ε 3 ε ε ε ε 0 ε ε ε ε 2 ε, B = ε ε ε 4 e o conjunto de especificações, puramente matemáticas, linearmente representadas na forma Ex[k] = Dx[k] como: Especificação R1: Especificação R2: Especificação R3: Especificação R4: x 1 [k] = x 1 [k] 0, 5x 2 [k] 3x 3 [k] 0, 5x 4 [k]; x 2 [k] = 0, 5x 1 [k] x 2 [k] 2, 5x 3 [k] x 4 [k]; x 3 [k] = 3x 1 [k] 2, 5x 2 [k] x 3 [k] 2, 5x 4 [k]; x 4 [k] = 0, 5x 1 [k] x 2 [k] 2, 5x 3 [k] x 4 [k];

62 60 Capítulo 4. Contribuições onde: E = 0 ε ε ε ε 0 ε ε ε ε 0 ε ε ε ε 0, D = 0 0, 5 3 0, 5 0, 5 0 2, , 5 0 2, 5 0, 5 0 2, 5 0. No cômputo do controlador que atenda as especificações acima, utilizamos a metodologia do trabalho de Gonçalves, Maia e Hardouin (2017), brevemente descrita na subseção 2.5.2, e encontramos um controlador não-causal, cuja matriz F, não-causal, é dada por: 11 10, , 5 F =. 2 1, 5 1 1, 5 A seguir, utilizaremos cada uma das técnicas abordadas para a causalização do controlador encontrado e verificaremos o comportamento do sistema para cada técnica de causalização Causalização pela técnica existente O objetivo desta técnica é encontrar um valor de m no qual a iteração F nc (A BF nc ) m resulte em uma matriz causal e possamos representar a lei de controle conforme Equação 19. A fim de facilitar os cálculos, denotemos a matriz de malha fechada M = (A BF nc ), onde F nc = F. Deste modo, temos que: , 5 2 2, 5 5 2, 5 M =. ε 0 ε ε 2 2, 5 5 2, 5 Para m = 1 temos: F nc (A BF nc ) m = F nc (M) m = F nc M F nc M = F nc M = 11 10, , 5 2 1, 5 1 1, 5 8, 5 8 5, 5 8 0, 5 1 3, , 5 2 2, 5 5 2, 5 ε 0 ε ε 2 2, 5 5 2, 5 Podemos verificar que, após a primeira iteração, a matriz resultante ainda é nãocausal e por isso continuamos incrementando o valor de m.

63 4.2. Causalização de Controladores 61 Para m = 2 temos: F nc (A BF nc ) m = F nc (M) m = F nc M 2 M 2 = M M = 5 5, 5 8 5, 5 4, 5 5 7, , 5 5 2, 5 4, 5 5 7, , , 5 F nc M 2 = 2 1, 5 1 1, 5 6 5, 5 3 5, 5 F nc M 2 = 3 3, 5 6 3, 5 5 5, 5 8 5, 5 4, 5 5 7, , 5 5 2, 5 4, 5 5 7, 5 5 Podemos verificar, que após a segunda iteração, a matriz resultante ainda é nãocausal e por isso continuamos incrementando o valor de m. Para m = 3 temos: F nc (A BF nc ) m = F nc (M) m = F nc M 3 7, , 5 8 M 3 7 7, , 5 = M M M = , , , 5 7, , , , 5 F nc M 3 7 7, , 5 = 2 1, 5 1 1, , , , 5 3, 5 3 0, 5 3 F nc M 3 = 5, 5 6 8, 5 6 Podemos verificar que, após a terceira iteração, a matriz resultante ainda é nãocausal e por isso continuamos incrementando o valor de m. Para m = 4 temos: F nc (A BF nc ) m = F nc (M) m = F nc M 4 M 4 = M M M M = 10 10, , 5 9, , , , 5 9, , 5 10

64 62 Capítulo 4. Contribuições F nc M 4 = F nc M 4 = 11 10, , 5 2 1, 5 1 1, 5 1 0, 5 2 0, 5 8 8, , , , 5 9, , , , 5 9, , 5 10 Podemos verificar que, após a quarta iteração, a matriz resultante ainda é não-causal e por isso continuamos incrementando o valor de m. Para m = 5 temos: F nc (A BF nc ) m = F nc (M) m = F nc M 5 12, , 5 13 M , , 5 = M M M M M = 9, , , , 5 12, , , , 5 F nc M , , 5 = 2 1, 5 1 1, 5 9, , , , 5 1, 5 2 4, 5 2 F nc M 5 = 10, , 5 11 Após a quinta iteração, e com valor de m = 5, encontramos uma matriz causal, onde todos os elementos são positivos: F mc = 1, 5 2 4, , , A lei de controle, para esse exemplo, pode ser representada como: u[k] = F mc x[k 5]. (30) Como é possível verificar pela Equação 30, o novo controlador encontrado utiliza-se de todas as informações de estado atrasadas, neste caso, de cinco eventos passados. A fim de mostrar o comportamento desse controlador com relação à causalidade e robustez, foram relizados testes em uma janela de 100 eventos arbitrando-se uma condição inicial e inserindo perturbações nos enventos k = 20, k = 40, k = 60 e k = 80. Os resultados do atendimento a cada especificação imposta são mostrados na Figura 15, onde no eixo

65 4.2. Causalização de Controladores 63 das ordenadas temos o erro, que é a diferença Ex[k] Dx[k] para cada especificação. A especificação é considerada atendida quando esse erro é nulo. Figura 15 Gráfico das especificações R1, R2, R3 e R4 para o sistema em malha fechada considerando o controlador causalizado pela técnica existente. Pela Figura 15, podemos verificar que o controlador perdeu robustez com a técnica de causalização existente (Maia, Hardouin e Cury (2013)), pois não consegue eliminar satisfatoriamente as perturbações inseridas. Mesmo que a perturbação não ocorra em um dado evento k, pelo fato de utilizar-se de informações atrasadas de cinco eventos passados (Equação 30), o controlador não consegue atender as especificações impostas Causalização pela técnica proposta O objetivo é tentar encontrar uma lei de controle representada pela Equação 29 onde todas as matrizes F i são causais. Utilizaremos aqui também a matriz de malha fechada M = (A BF ) definida por: , 5 2 2, 5 5 2, 5 M = ε 0 ε ε 2 2, 5 5 2, 5

66 64 Capítulo 4. Contribuições Definindo-se o operador causal [.] c que irá desmembrar as matrizes em sua parte causal e o operador não-causal [.] n que irá desmebrar a matriz com sua parte não-causal procedemos com o cômputo das matrizes F i. Matriz F 0 = [F ] c : F 0 = 11 10, , 5 2 1, 5 1 1, 5 = c ε ε ε ε ε ε 1 ε 11 10, , , , 5 Temos que = 2 1, 5 1 1, 5 2 1, 5 ε 1, 5 n é totalmente composta de ε, portanto o processo continua. não Matriz F 1 = [([F ] n M)] c : F 1 = 8, 5 8 5, 5 8 0, 5 1 3, 5 1 = c ε ε ε ε 0, 5 1 3, 5 1 não é to- 8, 5 8 5, 5 8 8, 5 8 5, 5 8 Temos que = 0, 5 1 3, 5 1 ε ε ε ε n talmente composta de ε, portanto o processo continua. Matriz F 2 = [([([F ] n M)] n M)] c : F 2 = 6 5, 5 3 5, 5 ε ε ε ε = c ε ε ε ε ε ε ε ε não é to- 6 5, 5 3 5, 5 6 5, 5 3 5, 5 Temos que = ε ε ε ε ε ε ε ε n talmente composta de ε, portanto o processo continua. Matriz F 3 = [([([([F ] n M)] n M)] n M)] c : F 3 = 3, 5 3 0, 5 3 ε ε ε ε = c ε ε ε ε ε ε ε ε

67 4.2. Causalização de Controladores 65 não é to- 3, 5 3 0, 5 3 3, 5 3 0, 5 3 Temos que = ε ε ε ε ε ε ε ε n talmente composta de ε, portanto o processo continua. Matriz F 4 = [([([([([F ] n M)] n M)] n M)] n M)] c : F 4 = 1 0, 5 2 0, 5 ε ε ε ε = c ε ε 2 ε ε ε ε ε não é total- 1 0, 5 2 0, 5 1 0, 5 ε 0, 5 Temos que = ε ε ε ε ε ε ε ε n mente composta de ε, portanto o processo continua. Matriz F 5 = [([([([([([F ] n M)] n M)] n M)] n M)] n M)] c : F 5 = ε ε ε ε = c ε ε ε ε é totalmente composta de ε, o pro Como ε ε ε ε cesso não continua. = n ε ε ε ε ε ε ε ε Encontradas as matrizes F 0, F 1, F 2, F 3, F 4 e F 5, a lei de controle, para esse exemplo, pode ser representada como: u[k] = F 0 x[k] F 1 x[k 1] F 2 x[k 2] F 3 x[k 3] F 4 x[k 4] F 5 x[k 5] (31) Pela Equação 31 podemos ver que na técnica proposta o controlador utiliza-se de informações atrasadas de no máximo cinco eventos além de informações recentes de estado (x[k]). A fim de mostrar comportamento deste controlador com relação à causalidade e robustez, foram realizados os mesmos testes feitos para o controlador encontrado pela técnica existente, onde foi definida a mesma condição inicial e perturbações nos eventos k = 20, k = 40, k = 60 e k = 80. Os resultados do atendimento a cada especificação imposta são mostrados na Figura 16, onde no eixo das ordenadas temos o erro, que é a diferença Ex[k] Dx[k] para cada especificação. A especificação é considerada atendida quando esse erro é nulo.

68 66 Capítulo 4. Contribuições Figura 16 Gráfico das especificações R1, R2, R3 e R4 para o sistema em malha fechada considerando o controlador causalizado pela técnica proposta. Podemos verificar pela Figura 16, que o controlador encontrado pela técnica de causalização proposta (Equação 31) consegue eliminar as perturbações inseridas nos eventos k = 20, k = 40, k = 60 e k = 80. Mesmo saindo do conjunto de especificações desejado, o controlador consegue convergir novamente para este conjunto após poucos eventos. Diante disso temos evidências, que serão também mostradas posteriormente no Capítulo 5, de que a técnica existente de Maia, Hardouin e Cury (2013) tende a ser menos robusta se comparada com a técnica proposta. Essa conclusão ocorre quanto comparamos as equações dos controladores para as duas técnicas. Na técnica existente de Maia, Hardouin e Cury (2013), representada pela Equação 19, podemos verificar que todas as informações utilizadas são atrasadas. Já na técnica proposta neste trabalho, representada pela Equação 29, verificamos que além de informações atrasadas o controlador utiliza-se de informações mais recentes o que proporciona uma resposta mais rápida do controlador quando o sistema perturbado.

69 4.3. Simulador Termo de Controle Avançado Uma vez que o controlador é causalizado, ele pode ser não robusto no sentido que leve mais eventos para convergir ao conjunto de especificações desejado. De fato, todo controlador resultante de um processo de causalização tende a ser menos robusto do que o controlador original, e dependendo da criticidade da especificação que ele deva atender, pode ser inviável a sua utilização. A não robustez de um controlador se deve à quantidade de informações atrasadas que ele utiliza. Da teoria de controle clássica sabemos que quanto mais informações atrasadas forem utilizadas, mais instável se torna o sistema. Das técnicas de causalização (existente e proposta) apresentadas nas seções anteriores, as duas se utilizam de informações atrasadas, o que pode comprometer a robustez do controlador. A ideia de implementação de um termo de controle avançado surgiu a partir deste trabalho, mais especificamente, quando realizados os testes para validação das técnicas de controle utilizando o simulador da planta de Angers (apresentado na seção 4.3). Naquela ocasião, percebeu-se que o controlador não reagia satisfatoriamente mesmo tendo informações mais recentes dos estados x[k]. Basicamente, o termo de controle avançado consiste da adição, na Equação 29, de um termo que usa as informações mais recentes disponíveis para calcular os próximos disparos x[k + 1]. O termo F ad x[k + 1] é adicionado da seguinte forma: s u[k] = F ad x[k + 1] F [i]x[k i]. (32) k=0 onde a matriz F ad, deve ser cuidadosamente escolhida, pois além de ser causal ela deve evitar deadlocks no sistema. Todo o desenvolvimento e detalhamento matemático desta implementação, bem como os resultados de sua aplicação, foi realizado pelo orientador desta dissertação e resultou em um artigo submetido à revista IEEE Transactions on Control Systems Technology (Gonçalves e Souza ( Em revisão)), que está disponibilizado no Anexo A deste documento. Os resultados da aplicação prática deste termo de controle avançado será visto no Capítulo 5, onde será possível comparar o desempenho do controlador com e sem a adição deste termo utilizando a planta de Angers. 4.3 Simulador Apresentação A implementação do simulador, como segunda contribuição deste trabalho, foi baseada em uma planta de esteiras existente na Universidade de Angers - França cujo funcionamento e detalhamento de controle estão descritos no Capítulo 3. O desenvolvimento de um simulador para um sistema dessa natureza é de grande utilidade, pois testes realizados na planta real nem sempre são simples de se fazer, primeiramente devido à sua localização

70 68 Capítulo 4. Contribuições (Angers - França) e também devido a indisponibilidade dos engenheiros que manuseiam a planta. Já o simulador desenvolvido permite a simulação a qualquer momento com resultados rápidos (por permitir o ajuste da velocidade de simulação) e bastante fiéis à planta real. Uma questão que pode vir à tona por profissionais na área de SED s é sobre a real necessidade em se construir um simulador para a validação das técnicas de controle, visto que o modelo em max-plus já faz essa validação. A princípio, o desenvolvimento de um simulador pode parecer apenas a representação gráfica e animação de um sistema, mas ele possui uma funcionalidade muito importante na validação das técnicas de controle quando o sistema está submetido à perturbações. Por se tratar de um modelo híbrido (com informações e dinâmicas discretas e contínuas) o simulador nos permite simular alguns tipos de perturbações realistas que podem acontecer no sistema, como por exemplo, a colisão de paletes no meio de um trecho. A Figura 17 da planta de Angers ilustra esse tipo de perturbação, onde no meio do trecho B4 B1 do circuito superior, um palete sofre um agarramento (que pode ocorrer devido a problemas de lubrificação na esteira ou até mesmo uma ação forçada do operador ao segurar o palete) o que gera a colisão do palete anterior. Esse tipo de perturbação não consegue ser modelada satisfatoriamente no modelo max-plus, pois nesse modelo temos apenas as informações discretizadas da posição dos paletes, próximo aos botões. Já no simulador, além de informações discretas, temos a informação contínua da posição de todos os paletes ao longo dos trechos, permitindo a modelagem e simulação desse tipo de perturbação. Figura 17 Perturbação devido ao agarramento de palete. Um palete ao agarrar no trecho B4 B5 sofre colisão do palete que vem atrás.

71 4.3. Simulador Funcionalidades O simulador proposto para este trabalho foi desenvolvido em linguagem 𝐶# e possui interface amigável com as mesmas configurações da planta real descrita no Capítulo 3. A Figura 18 mostra a tela principal do sistema onde, ao centro, podemos ver representado graficamente os dois circuitos (inferior e superior) da planta da Universidade de Angers, os dez botões de controle e os paletes distribuídos conforme esquemático mostrado na Figura 8. Próximo a cada um dos botões temos um contador que informa a quantidade de fichas de permissão armazenadas para aquele botão. A cada ficha de permissão que chega ao botão é acrescido uma unidade ao contador, e toda vez que o respectivo botão é acionado uma unidade é decrescida. No canto inferior direito da tela temos a indicação do tempo corrente de simulação. Figura 18 Tela principal do simulador No canto superior esquerdo da tela principal temos um menu, mostrado na Figura 19 (a), onde o usuário pode definir algumas configurações de simulação, como parar e iniciar a simulação, definir a velocidade de simulação (disponível em 4 estágios) e ativar e definir a probabilidade de perturbação no sistema, 𝜉. Essa perturbação força, o agarramento de um palete aleatório por algum tempo - imitando problemas reais na fábrica devido a problemas de lubrificação - com uma taxa definida pelo usuário. Mais precisamente, após cada unidade de tempo existe uma probabilidade 𝜉 em que um palete aleatório será perturbado. Além disso, o usuário pode provocar uma perturbação manual ao sistema, segurando manualmente um palete, bastando manter o cursor do mouse sobre ele.

72 70 Capítulo 4. Contribuições Figura 19 Menus de ajustes da simulação (a) e de comando (b) acessados na tela principal. Na parte inferior esquerda da tela principal temos um menu, mostrado na Figura 19 (b), com alguns botões que implementam funções específicas. O primeiro botão, Control Options, abre a tela mostrada na Figura 20, na qual o usuário pode selecionar o modo de operação para controlar a planta. Existem quatro modos de controle possíveis: Without Controller: neste modo nenhum controle automático é executado. O sistema funciona em malha aberta e o usuário adiciona as fichas de permissão manualmente para cada botão, clicando no respectivo botão, ou através do botão Add Tokens Buttons que adiciona 10 fichas de permissão para cada botão; External Automatic: neste modo o usuário carrega um arquivo externo com extensão (.txt), com as matrizes de controle F [i] e o sistema implementa uma ação de controle, conforme a técnica proposta na subseção 4.2.2, onde u[k] = s i=0 F i x[k i]; Internal Automatic: mesma estrutura de controle que o modo External Automatic, com a diferença que as matrizes F [i] são calculadas internamente de acordo com as especificações lineares especificadas pelo usuário (como mostrado na Figura 20). O usuário pode selecionar os botões que deseja usar para o controle. O algoritmo para calcular o controlador é baseado nos resultados obtidos no trabalho de Gonçalves, Maia e Hardouin (2017). O usuário também pode escolher o método de causalização desejado (método existente (subseção 4.2.1) ou método proposto (subseção 4.2.2) e decidir se quer ou não implementar o termo avançado (subseção 4.2.4) para melhorar a robustez do controlador;

73 4.3. Simulador 71 TCP/IP Automatic : neste modo, um programa externo controla o sistema usando protocolo TCP/IP. O simulador fornece interfaces para disponibilizar informações dos estados, entradas e saídas para os programas externos quando solicitado, bem como para adicionar fichas de permissão aos botões. Desta forma, pode-se escrever uma estratégia de controle personalizada para controlar o sistema. A Figura 21 nos mostra a tela de comunicação TCP/IP onde o usuário insere as informações de porta e endereço IP do cliente e inicia a comunicação; Figura 20 Tela Opções de Controle onde o usuário define o modo de controle, insere as especificações desejadas e calcula o controlador a partir do método de causalização escolhido. Figura 21 Tela de comunicação TCP/IP onde o simulador pode ser controlado a partir de outros programas externos.

74 72 Capítulo 4. Contribuições O próximo botão, Observer Options, abre a tela (Figura 22) onde o usuário passa a trabalhar com observadores de estados para realizar o controle, usando apenas saídas. Nessa tela o usuário insere, em uma lista, o observador desejado e habilita as saídas que deseja utilizar para o controle. Note que as estratégias de controle implementadas nas Opções de Controle (Figura 20) assumem a medição do estado completo do sistema x[k]. Na planta real, não dispomos de sensores para medir todos os eventos: temos disponível apenas a medição de alguns eventos, relativos aos sensores de proximidade próximos a cada botão. Em nosso simulador, temos sensores extras (sensores virtuais) para medir todos os estados e, assim, o feedback do estado pode ser realizado. O controle por observadores é uma opção do usuário caso queira simular uma situação mais realista. Figura 22 Tela Observador. No próximo botão, Graphics, um menu é aberto (Figura 23) e usuário pode ver os gráficos de tendência para as variáveis de estado x i [k], entrada u i [k] e saída y i [k]. Além disso ele pode monitorar as especificações lineares implementadas em Opções de Controle (Figura 20) e verificar se estão sendo satisfeitas. A Figura 24 nos mostra o gráfico de tendência para a especificação x 20 [k 1] = x 18 [k]. Essa é uma especificação de sincronização de chegada de paletes próximo aos botões B8 e B9, ou seja, quanto um palete estiver chegando próximo ao botão B9 outro palete deve estar chegando próximo ao botão B8. O gráfico no mostra o erro e k =x 20 [k 1] x 18 [k] que deve ser o mais próximo possível de zero. Podemos verificar, neste caso, que a especificação é satisfeita a partir do 7 o evento.

75 4.3. Simulador 73 Figura 23 Menu Gráficos onde o usuário pode visulizar os gráficos para as entradas u i [k], estados x i [k] e saídas y i [k] bem como acompanhar o atendimento às especificações. Figura 24 Gráfico de tendência para a especificação x 20 [k 1] x 18 [k]. A especificação é satisfeita a partir do 7 o evento. No botão TEG, o usuário pode ver o modelo GET para o sistema conforme mostrado na Figura 25. Este modelo exibe, especificamente, o significado físico de cada evento de estado x i [k], evento de entrada u i [k] e evento de saída y i [k]. Assim ele nos permite escrever, por exemplo, as especificações desejadas em Opções de Controle (Figura 20). O botão Add Tokens Buttons simplesmente adiciona 10 fichas de permissão para cada um dos botões. O botão Export Data exporta os dados da simulação (eventos de estado, entrada e saída) para um arquivo de extensão (.txt) em um local definido pelo usuário.

76 74 Capítulo 4. Contribuições Por último, o botão System Restart reinicia o sistema (posição dos paletes, número de fichas de permissão) para a configuração inicial. Figura 25 Tela de Grafo Evento Temporizado (GET) do sistema

77 75 Capítulo 5 Experimentos com o Simulador 5.1 Apresentação Neste capítulo, iremos descrever os testes realizados com o simulador desenvolvido da planta de Angers (seção 4.3) e os seus resultados. O objetivo é, após definir as especificações que desejamos ao sistema, verificar o seu comportamento em malha aberta e malha fechada e, neste último caso, validar as técnicas de controle com relação à causalidade e à robustez. Serão realizados três tipos de testes, sendo o primeiro considerando o sistema em malha aberta (sem controlador), o segundo considerando o sistema em malha fechada sem perturbação e o terceiro considerando o sistema em malha fechada com perturbação, onde serão consideradas três taxas de perturbação, ξ = 0, 05%, ξ = 0, 1% e ξ = 0, 2%. Nos testes em malha fechada, para o cômputo do controlador, serão consideradas três abordagens: a primeira utilizando o método de causalização existente (Maia, Hardouin e Cury (2013)), discutido na subseção 4.2.1, que será chamado de Maia, a segunda considerando o método de causalização proposto, discutido na subseção 4.2.2, que será chamado de Proposto e a terceira considerando o método de causalização proposto conjugado com o termo de controle avançado, discutido na subseção 4.2.4, que será chamado de Proposto+Avd. 5.2 Especificações do sistema Antes da realização dos testes, a primeiro passo é definir as especificações do sistema, ou seja, como desejamos que o sistema funcione, quais regras na movimentação do paletes ele deverá atender. Consideramos três especificações, representadas pela Figura 26, e definidas como: Especificação R1: como descrito no Capítulo 3, os botões B3 e B10 são intertravados, de forma que seus acionamentos são sincronizados. Devido a essa condição, um palete ao chegar próximo ao botão B3, por exemplo, pode ter de esperar por muito

78 76 Capítulo 5. Experimentos com o Simulador tempo um palete chegar próximo ao botão B10, para que ambos os botões sejam disparados. O mesmo ocorre quando um palete chega ao botão B10, pode ser que espere por muito tempo um palete chegar em B3. A especificação que desejamos é que esse tempo de espera seja nulo. Ou seja, os paletes devem chegar simultaneamente aos botões B3 e B10. Analisando a Figura 9, podemos ver que a equação que representa essa especificação pode ser definida como x 6 [k] = x 22 [k]. Isto é verdade porque os eventos x 6 [k] e x 22 [k] são os eventos de um palete começando a percorrer uma distância de um palete a partir dos botões B3 e B10, respectivamente; Especificação R2: desejamos que um palete chegue ao botão B8 ao mesmo tempo que um palete chegue ao botão B9. Essa especificação pode ser equacionada como x 20 [k 1] = x 18 [k], onde x 18 e x 20 são os eventos de um palete começando a percorrer uma distância de um palete a partir dos botões B8 e B9, respectivamente; Especificação R3: desejamos eliminar a fila de paletes antes do botão B1. Pela Figura 9, x 12 e x 11 são os tempos que um palete começa a percorrer uma distância de um palete e dois paletes a partir de B1, respectivamente. Para eliminar a fila antes de B1, assim que um palete começar a percorrer uma distância de dois paletes, evento x 11, ele não deve esperar para chegar em B1. O tempo para percorrer a distância de um palete é de 4 unidades de tempo. Na Figura 9, o palete em x 11 para o evento k 1 é o mesmo em x 12 para o evento k. Assim, temos essa especificação equacionada como 8x 11 [k 1] = 4x 12 [k] ou simplesmente 4x 11 [k 1] = x 12 [k]. Figura 26 Especificações R1, R2 e R3 impostas ao sistema e utilizadas para os testes em malha aberta e malha fechada com e sem perturbação. Portanto, temos as seguintes especificações equacionadas para o controle do sistema: Especificação R1: x 6 [k] = x 22 [k]; Especificação R2: x 20 [k 1] = x 18 [k];

79 5.3. Testes 77 Especificação R3: 4x 11 [k 1] = x 12 [k]; que são meramente didáticas e podem não representar sentido lógico para o funcionamento da planta, servindo apenas para validar as técnicas de controle. Definidas as especificações, já temos todas as informações necessárias para realização dos testes, que serão descritos a seguir. 5.3 Testes Malha aberta Neste primeiro teste estamos interessados em verificar o comportamento do sistema em malha aberta, ou seja, se as especificações impostas são garantidas por ele mesmo, sem a necessidade de um controlador. Para realizar este teste, na tela Control Options, aberta a partir da tela inicial do simulador, escolhemos o modo de controle como Without Controller e inserimos as equações das especificações R1, R2 e R3 no campo de especificações (Figura 27). Como neste teste todos os botões são incontroláveis, na tela inicial do simulador adicionamos manualmente fichas de permissão a todos os botões (clicando sobre eles) ou através do botão Add Tokens Buttons. Por fim iniciamos a simulação clicando no botão Start. (Figura 28). Figura 27 Tela Control Options configurada para o modo sem controlador (malha aberta) e com as especificações desejadas para a simulação.

80 78 Capítulo 5. Experimentos com o Simulador Figura 28 Menus da tela inicial onde à direita o usuário adiciona fichas de permissão aos botões e à esquerda inicia a simulação Malha fechada - sem perturbação Neste teste estamos interessados em verificar o comportamento do sistema em malha fechada, sem perturbação, onde o controlador, da forma u[k] = F x[k], será calculado internamente ao simulador. Para isso, na tela Control Options, acessada a partir da tela inicial do simulador, escolhemos o modo de controle como Internal Controller, ou seja, as matrizes de controle F i serão calculadas internamente de acordo com as especificações R1, R2 e R3 impostas ao sistema. Em seguida inserimos as equações das especificações R1, R2 e R3 no campo de especificações e selecionamos qual método de causalização desejamos utilizar (Maia ou Proposto) e se desejamos incluir o termo avançado (Proposto+Avd), no cálculo do controlador. Todos os botões são mantidos ativos e farão parte do controle. Com os parâmetros inseridos calculamos o controlador através do botão Compute State Feedback. Por fim, na tela inicial, mantemos a perturbação desativada e iniciamos a simulação clicando no botão Start. (Figura 29) Malha fechada - com perturbação Da mesma forma que no teste anterior, iremos calcular o controlador internamente ao simulador, com a diferença de que neste teste iremos incluir perturbações e verificar como o sistema se comporta. Na tela Control Options, acessada a partir da tela inicial do simulador, escolhemos o modo de controle como Internal Controller, inserimos as equações das especificações R1, R2 e R3 no campo de especificações, selecionamos qual método de causalização desejamos utilizar (Maia ou Proposto) e se desejamos incluir o termo avançado (Proposto+Avd) e calculamos o controlador através do botão Compute State

81 5.3. Testes 79 Figura 29 Menu da tela inicial e tela Control Options configurados para simulação em malha fechada sem perturbação. Feedback. Na tela principal do simulador definimos a taxa de perturbação ξ = 0, 05% para o primeiro teste, ou seja, após cada unidade de tempo na simulação, existe uma chance de 0, 05% de que um palete aleatório agarre por algum tempo. Por fim, iniciamos a simulação clicando no botão Start. (Figura 30). O mesmo teste será realizado considerando as outras duas taxas de perturbação ξ = 0, 1% e ξ = 0, 2%. Figura 30 Menu da tela inicial e tela Control Options configurados para simulação em malha fechada com perturbação.

82 80 Capítulo 5. Experimentos com o Simulador 5.4 Resultados Todos os testes descritos na seção 5.3 foram realizados dentro de uma janela de 200 eventos e as especificações monitoradas através dos gráficos de especificação. Os resultados para cada tipo de teste serão apresentados a seguir Malha aberta Pelos gráficos mostrados na Figura 31 podemos verificar que a única especificação garantida quando o sistema é colocado em malha aberta é a especificação R3 representada pela equação 4x 11 [k 1] = x 12 [k], pois, após um transiente inicial, a diferença 4x 11 [k 1] x 12 [k] é praticamente nula, indicando que não ocorrem filas antes do botão B1. Já as diferenças x 6 [k] x 22 [k] e x 20 [k 1] x 18 [k] que representam, respectivamente, as especificações R1 e R2 não são nulas indicando que estas especificações não são atendidas, ou seja, os paletes não chegam simultaneamente aos botões B3 e B10 e um palete não chega ao botão B8 ao mesmo tempo que outro palete chega ao botão B9. Portanto, em malha aberta, o sistema é instável e não controlável como já era esperado. Figura 31 Gráfico das especificações R1, R2 e R3 para o sistema simulado em malha aberta.

83 5.4. Resultados Malha fechada - sem perturbação Neste tipo de teste, foi verificado o comportamento do sistema em malha fechada desconsiderando as perturbações. Foram realizadas três abordagens diferentes, a primeira utilizando o método de causalização existente na literatura (Maia), a segunda utilizando o método de causalização proposto neste trabalho (Proposto) e a terceira utilizando o método de causalização proposto conjugado com o termo de controle avançado (Proposto+Avd). Os testes, com cada método de causalização, foram realizados em uma janela de 200 eventos e as Figuras 32, 33 e 34 nos mostram os resultados da comparação dos métodos para cada especificação, R1, R2 e R3. Podemos verificar visualmente pelos gráficos que para os três métodos o sistema se controla após um transiente inicial, mas os métodos Proposto e Proposto+Avd possuem um desempenho melhor sob o método Maia, pois neles o controlador consegue chegar ao controle (especificações atendidas) em um número menor de eventos. Uma análise estatística, apresentada na Tabela 1, nos mostra essa comparação de desempenho indicando a porcentagem dos eventos nos quais as especificações são atendidas, para cada método aplicado e cada especificação. Neste caso, foi considerada como especificação atendida uma diferença Ex[k] Dx[k] menor do que 5 unidades de tempo em valor absoluto. Figura 32 Gráfico da especificação R1, x 6 [k] x 22 [k], para o sistema simulado em malha fechada, sem perturbação, considerando as três diferentes abordagens.

84 82 Capítulo 5. Experimentos com o Simulador Figura 33 Gráfico da especificação R2, x 20 [k 1] x 18 [k], para o sistema simulado em malha fechada, sem perturbação, considerando as três diferentes abordagens. Figura 34 Gráfico da especificação R3, 4x 11 [k 1] x 12 [k], para o sistema simulado em malha fechada, sem perturbação, considerando as três diferentes abordagens.

85 5.4. Resultados 83 Tabela 1 Porcentagem dos eventos em que as especificações são atendidas, para cada método de causalização e especificação no teste em malha fechada sem perturbação. Sem Perturbação Método R1 R2 R3 Maia 98% 97% 97,5% Proposto 99,5% 99% 98,5% Proposto+Avd 99,5% 99% 98,5% Malha fechada - com perturbação Neste teste, foi verificado o comportamento do sistema em malha fechada considerando as perturbações (agarramento dos paletes). Essas perturbações foram configuradas em três níveis diferentes (ξ = 0, 05%, ξ = 0, 1% e ξ = 0, 2%) que representam a porcentagem de chance de um palete aleatório agarrar por algum tempo após cada unidade de tempo. Para cada nível de perturbação foram feitos testes, em uma janela de 200 eventos, considerando as três abordagens (Maia, Proposto, Proposto+Avd). As Figuras 35, 36, 37, 38, 39, 40, 41, 42, 43, nos mostram os resultados da comparação dos métodos para cada especificação, R1, R2 e R3, para os diferentes valores de perturbação, considerando os 100 primeiros eventos. Taxa de Perturbação ξ = 0, 05% Figura 35 Gráfico da especificação R1, x 6 [k] x 22 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 05%.

86 84 Capítulo 5. Experimentos com o Simulador Figura 36 Gráfico da especificação R2, x 20 [k 1] x 18 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 05%. Figura 37 Gráfico da especificação R3, 4x 11 [k 1] x 12 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 05%.

87 5.4. Resultados 85 Taxa de Perturbação ξ = 0, 1% Figura 38 Gráfico da especificação R1, x 6 [k] x 22 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 1%. Figura 39 Gráfico da especificação R2, x 20 [k 1] x 18 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 1%.

88 86 Capítulo 5. Experimentos com o Simulador Figura 40 Gráfico da especificação R3, 4x 11 [k 1] x 12 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 1%. Taxa de Perturbação ξ = 0, 2% Figura 41 Gráfico da especificação R1, x 6 [k] x 22 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 2%.

89 5.4. Resultados 87 Figura 42 Gráfico da especificação R2, x 20 [k 1] x 18 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 2%. Figura 43 Gráfico da especificação R3, 4x 11 [k 1] x 12 [k], para o sistema simulado em malha fechada, considerando as três diferentes abordagens e uma taxa de perturbação ξ = 0, 2%.

90 88 Capítulo 5. Experimentos com o Simulador Analisando os gráficos, vemos que para todas as especificações (R1, R2, R3) e para todos os níveis de perturbação, o desempenho do método Proposto+Avd foi melhor que o método Proposto que por sua vez foi melhor que o método Maia. Isso é comprovado através da análise estatística mostrada na Tabela 2, que indica a porcentagem dos eventos nos quais as especificações são atendidas, para cada método de causalização e especificação, considerando as taxas de perturbação ξ = 0, 05%, ξ = 0, 1% e ξ = 0, 2%. Tabela 2 Porcentagem dos eventos em que as especificações são atendidas, para cada método de causalização e especificação, para o teste em malha fechada considerando taxas de perturbação ξ = 0.05%, ξ = 0.1% e ξ = 0.2%. ξ = 0, 05% ξ = 0, 1% ξ = 0, 2% Método R1 R2 R3 R1 R2 R3 R1 R2 R3 Maia 90% 82% 77% 83% 68% 59% 76% 61% 52% Proposto 94% 89% 84% 90% 81% 76% 86% 73% 63% Proposto+Avd 97% 94% 94% 95% 84% 83% 91% 77% 75% A explicação para esses resultados, é que a técnica da abordagem Maia utiliza de informações muito atrasadas. De fato, na Equação 19, temos m = 2, ou seja sempre usamos informações atrasadas por dois eventos. Isto significa que uma perturbação do sistema que ocorreu em k 2 influencia o sistema no evento k, mesmo que não haja perturbação do sistema neste evento. Isto é uma perturbação causada pelo controlador. Por outro lado, a abordagem Proposto utiliza-se de informações mais recentes x[k]. Finalmente a abordagem Proposto+Avd utiliza um termo avançado e consequentememte usa a informação mais recente disponível para calcular o próximo evento k +1 para algum x i. Um comportamento que notamos ao analisar os dados da Tabela 2 é que com o aumento das taxas de perturbação, os controladores ficaram menos robustos e esta robustez tende a diminuir ainda mais à medida que se aumenta esta taxa. Isto porque quando aumentamos o nível de perturbação do sistema, o controlador não consegue atuar em tempo (rejeitando a perturbação) antes de ocorrer outra perturbação, ou seja o aumento incontrolável de perturbações leva à instabilidade do sistema.

91 89 Capítulo 6 Conclusões Neste trabalho foi possível desenvolver uma nova técnica para a causalização de controladores por realimentação de estados genéricos. Diferentemente da técnica de causalização existente na literatura (Maia, Hardouin e Cury (2013)), essa nova técnica utiliza-se de informações recentes de estado e oferece maior robustez ao controlador. Através de um exemplo matemático e posteriormente por meio de simulação, foi possível comparar as duas técnicas e verificar o melhor desempenho da técnica proposta sobre a técnica existente, visto que ela consegue convergir o sistema para o conjunto de especificações impostas em uma quantidade menor de eventos, mesmo diante perturbações. O desenvolvimento de um simulador realista, com características muito próximas à da planta de Angers, permitiu-nos realizar, com rapidez e eficiência, vários testes para a validação das técnicas de controle aqui abordadas, testes esses que certamente seriam mais complexos e demandariam maior tempo se fossem realizados na planta física. A inclusão de perturbações na simulação também foi um grande diferencial, pois nos permitiu ver na prática como o controlador reage às situações adversas que são passíveis de ocorrer na planta real. A partir dos testes realizados e seus resultados foi possível reafirmar e comprovar graficamente o melhor desempenho da técnica proposta sobre a técnica existente (Maia, Hardouin e Cury (2013), e ainda mais, que a técnica proposta conjugada com o termo de controle avançado oferece uma robustez ainda maior ao controlador. Algumas discussões foram aqui iniciadas e carecem de um maior estudo e comprovação, o que será feito em oportunidades futuras de trabalho, dentre elas: Provar as propriedades matemáticas do controlador submetido à técnica de causalização proposta neste trabalho. Como vimos ao final da seção a sequência de matrizes causais F n pode nunca terminar. O objetivo será provar matematicamente que, mesmo não terminando, essa sequência tende a ser cíclica, o que permite, portanto, que ela seja interrompida e apenas uma quantidade finita de matrizes seja utilizada para o cálculo do controlador;

92 90 Capítulo 6. Conclusões Aperfeiçoar o simulador desenvolvido para também realizar o controle por realimentação de saídas, ou seja, apenas com informações medidas, diferentemente da abordagem deste trabalho, que considerou a implementação do controlador por realimentação de estados;

93 91 Referências AMARI, S. et al. Max-plus control design for temporal constraints meeting in timed event graphs. IEEE Transactions on Automatic Control, v. 57, n. 2, p , BACCELLI, F. et al. Synchronization and Linearity. [S.l.]: Wiley, New York, CASSANDRAS, C. G.; LAFORTUNE, S. Introduction to Discrete Event Systems. [S.l.]: Springer Science+Business Media, LLC, GONÇALVES, V. M. Tropical Algorithms for Linear Algebra and Linear Event-invariant Dynamical Systems. Tese (Doutorado) Universidade Federal de Minas Gerais, Belo Horizonte, Brazil, GONÇALVES, V. M.; MAIA, C. A.; HARDOUIN, L. On the steady-state control of timed event graphs with firing date constraints. Automatic Control, IEEE Transactions on, v. 61, n. 8, p , GONÇALVES, V. M.; MAIA, C. A.; HARDOUIN, L. On max-plus linear dynamical system theory: The regulation problem. Automatica, v. 75, p , GONÇALVES, V. M. et al. An observer for tropical linear event-invariant dynamical systems. IEEE CDC-ECC, Los Angeles, GONÇALVES, V. M.; SOUZA, M. X. On max-plus linear dynamical system theory: Validation of control techniques in a realistic simulator. IEEE Transactions on Control Systems Technology, 2018 Em revisão. KATZ, R. D. Max-plus (A; B)-invariant spaces and control of timed discrete-event systems. IEEE Transactions on Automatic Control, v. 52, n. 2, p , KIM, C.; LEE, T. E. Feedback control of cluster tools for regulating wafer delays. IEEE Transactions on Automation Science and Engineering, v. 13, n. 2, p , MAIA, C. A.; ANDRADE, C. R.; HARDOUIN, L. On the control of maxplus linear system subject to state restriction. Automatica, v. 47, n. 5, p , MAIA, C. A.; HARDOUIN, L.; CURY, J. E. R. Some results on the feedback control of max-plus linear systems under state constrains. In: 52nd IEEE Conference on Decision and Control. [S.l.: s.n.], p

94 92 Referências SOUZA, M.; GONÇALVES, V. M. Técnicas de causalização de controladores max-plus: Validação em um simulador. XXII Congresso Brasileiro de Automática, 2018.

95 93 ANEXO A Artigo Submetido Artigo submetido à revista IEEE Transactions on Control Systems Technology, em fase de revisão, com o título: On Max-Plus Linear Dynamical System Theory: Validation of Control Techniques in a Realistic Simulator, onde, na seção V-B, pode ser visto todo o desenvolvimento e detalhamento matemático do termo de controle avançado abordado na subseção deste trabalho.

96 94 ANEXO A. Artigo Submetido

97 95 On Max-Plus Linear Dynamical System Theory: Validation of Control Techniques in a Realistic Simulator Vinicius Mariano Gonçalves, Marcelo Xavier Reis Souza Abstract For a class of discrete event systems called Timed Event Graphs, we can write linear equations in the Max-Plus algebra that describe the firing dynamics. In some cases, we can use independent events - inputs - to influence the system dynamics in order to achieve a desired specification. In this setting, significant attention has been devoted in the literature to the mathematical development of controllers that achieve these desired specifications. However, not much work has been done in the practical implementation of these controllers in a real plant or even in a realistic simulator, since usually the techniques are validated in the Max-Plus model. We address this important aspect by discussing some practical issues in the implementation of these controllers, more specifically the problem of causality and robustness, in a realistic scenario: a simulator. We propose solutions for these issues and also some formal guarantees for these solutions. Index Terms Discrete Event Systems, Max-Plus, Control, Simulation I. INTRODUCTION Timed Event Graph (TEGs henceforth) is a subclass of Petri Nets used to model some Discrete Event Systems ([2]). It has been applied to model, for example, train scheduling, manufacturing systems, semi-conductor production process and even ribosome dynamics (see [6] for a review). It is well-known that the firing dynamics of TEGs can be conveniently described using the state variables and independent inputs by applying the Max Plus Algebra [2], with dynamical linear equations in this algebra that mirror the traditional time-invariant linear systems. Then, as in traditional linear system theory, we can manipulate the independent inputs to perform some kind of control [9], [11], [1], [12], [6], [10], [7], [14], [13], [3], [8]. In this sense, many works in recent literature [9], [11], [1], [12], [6], [10], [7], [14] studied the problem in which we want that the system state respects a special type of constraint. More specifically, one that can be described as a semimodule, the Max-Plus version of traditional vector spaces. We are grateful to brazilian agencies CNPQ, FAPEMIG and CAPES for funding this work. Vinicius Mariano Gonçalves (mariano@cpdee.ufmg.br) is with electrical engineering department of Universidade Federal de Minas Gerais (UFMG), Brazil (Av. Pres. Antônio Carlos, Pampulha, Belo Horizonte - MG, ). Marcelo Xavier Reis Souza (mxrs@outlook.com.br) is with Programa de Pós-Graduação em Engenharia Elétrica of Universidade Federal de Minas Gerais (UFMG), Brazil (Av. Pres. Antônio Carlos, Pampulha, Belo Horizonte - MG, ). In many of these works (see [9], [11], [1], [12], [6], [10], [7], [14] for instance) the control synthesis procedure generates the same kind of control: (Max-Plus) linear static feedbacks. More precisely, if x[k] is the state vector and u[k] the input vector then u[k] = F x[k], in which the matrix F is fixed and the matricial product is interpreted in the Max-plus sense. While a significant and important effort has been employed in creating new techniques for generating these controllers, the literature lacks reports of implementation of these in real situations or even in realistic situations (as in a realistic simulator). Usually, the validation of the control techniques is done in the same Max-Plus models that were used to generate the controllers, thus leaving open important questions as (i) will the controller works for the real plant in which this model was based? (ii) how will the controller reacts to perturbations that normally happen in real systems? and (iii) what are the difficulties in implementing these controllers in a real plant? Indeed, to the best of the authors knowledge, only one previous work, [5], reported in the literature a real implementation of this kind of controller. In this case, the controller developed in the author s thesis was successfully employed to control a real plant, available at Universite d Angers, France, composed of two conveyor belts in which pallets move controlled by some buttons positioned across the system. The Max-Plus controller, implemented in a C program that communicates with the PLC that controls the plant, was able to reject perturbations caused naturally by the system (pallets being stuck temporally due to the lack of lubrication) or man-made (pallets being held by hand). Due to the lack of implementations reported in literature, it is clear that it is important to study with care how these controllers will perform in real situations. Unfortunately, real plants such as the one in the Université d Angers are not usually readily available. For instance, the aforementioned conveyor belt has a considerable setup time and requires the availability of some personnel that handle the plant. Furthermore, due to the slow dynamic of the system, even a simple test may take a lot of time to be complete. In order to make tests that have a good practical adherence while at the same time having convenience, a realistic simulator of Angers conveyor belt system was developed. Since the dynamics of the conveyor belt system are not very complex (such as very complex chemical, thermal or electromagnetic phenomena), composed basically of movement of pallets and collision between themselves and the buttons, it was possible to develop a simulator that matches very closely the system

98 96 ANEXO A. Artigo Submetido behaviour. The system simulates common perturbations that happen in the real system, such as pallets being stuck, and has a TCP/IP interface so outside programs can communicate and control it. Furthermore, the system has very convenient features as acceleration of the simulation time (thus a large number of tests can be done very quickly), exportation of data for analysis, quick importation of controller parameters for validation among others. Thus, we can perform realistic test very conveniently and identify bottlenecks in the control techniques more easily. Two specific practical issues were studied using the developed simulator. They are: Causalisation: a very important matter is that some control laws u[k] = F x[k] derived from the aforementioned control synthesis methods may be not implementable due to its noncausal nature. This means, essentially, that the controller demands the prediction of events. To exemplify, suppose x and u are scalars and F = ( 2). Thus the control law u[k] = F x[k] reads as fire u for the k th time 2 time units before x fires for the k th time. Noncausality happens when the matrix F has non-ε negative entries. Thus, one practical problem is how to convert a noncausal controller in an equivalent one which is causal, that is, a causalisation technique is sought. To the best of the authors knowledge, the only general causalisation technique present thus far in the literature is the one in [12]. Robustness: not much theoretical development has been dedicated to addressing robustness issues in Max-Plus controllers. Thus, in most cases we do not have formal guarantees that the controller is going to perform well, i.e. drive the system to the desired specifications, even when there are some occasional perturbations such as some deviation from the nominal parameters of the model (e.g pallets being stuck and taking more time to reach the next button than considered in the model). The basic robustness property is that once a perturbation drives the system state outside the specification the controller is eventually able to drive the system back to the desired behaviour. In this sense, to the best of the authors knowledge, only two works, [6], [7], addressed this issue both theoretically and with experiments. They showed that the derived controller has the property of converging to the desired set for any initial condition of the system in a finite number of steps. This entails the desired robustness property since any perturbed state can be considered as the (new) initial state of the system, in which we have the guarantee that eventually the state will achieve the desired specification. A more advanced robustness property is not only the matter of being able to reject perturbations, but how efficient is the controller in handling these. This can be described mathematically as how many events one must wait till we have convergence to the desired set, which henceforth will be our qualitative description of robustness. In this paper, we are going to address both these problems. First, we will describe a realistic simulator developed for validating Max-Plus control techniques. Then, we will argue (and then show in our realistic simulator at the end of this paper) that the causalisation technique proposed in [12] may generate non-robust causalised controllers because it relies on too much in delayed information. We will address this issue by proposing a new causalisation technique that uses more recent information. We will then argue (and then show using experiments at the end of this paper) that even though robustness is improved, the controller is not sufficiently robust. We will then propose an additional causal term to the controller that improves this situation. Finally, we will validate the proposed techniques in the aforementioned realistic simulator. In a nutshell, this work contributes to the control practice by proposing techniques for solving practical problems encountered in Max-Plus controller implementations and validating them in realistic situations. We also provide some formal guarantees for the proposed techniques. II. MATHEMATICAL PRELIMINARIES We will now make some basic definitions. The Max-Plus algebra is the dioid (an idempotent semiring) Z max = (Z { },, ) whose is the maximum and is the traditional sum. It has been also called Tropical Algebra. The symbol will be frequently omitted and so it will be interpreted by juxtaposition, just like the traditional product in the traditional algebra. So ab is read as a b = a+b. We denote the element by the symbol ε, and it will also be occasionally denoted by the null element. There is also a matricial analogue of this algebra, and so for two matrices A, B of appropriate dimension A B and A B will be interpreted as the matricial sum and product with + being replaced by and by. All vectors are column vectors. The symbol A T denotes the transpose of the matrix A. A vector or matrix of appropriate dimension composed only of ε will also be denoted by ε. A matrix without any ε entries is said to be full. The symbol I will denote the max-plus identity matrix of an appropriate order, that is, a matrix in which the diagonal element is 0 and ε otherwise. For a natural number A the k th matrix power A k will be defined recursively as A k+1 = A k A and A 0 = I. If λ is a scalar not ε then λ 1 = λ. For a matrix P we will denote by {P } ij the entry on the row i and column j. The Kleene closure of a square matrix A is equal to i=0 Ai. The spectral radius of this matrix, ρ(a), is the greatest scalar λ for which there exists a vector v ε in which Av = λv. Generally, even though the entries of the matrix A lie in Z or are ε, the spectral radius can be a rational number. However, since the units of the problem can be redefined, the entries of the matrix (and thus the spectral radius) can be re-scaled so the spectral radius is either an integer or ε. Thus hereafter we can assume without loss of generality that ρ(a) Z max. In the traditional setting, ρ(a) is the eigenvalue of A with the largest absolute value. For a matrix X, we also definine the set Im X as the semimodule generated by all possible Max-Plus linear combinations of columns of X.

99 97 Let denote the minimum operation. We define as A /B as the greatest solution X of XB A, and can be computed as {A /B} ij = k (A ik B jk ) with the definition that ( ε) + (ε) = +. This operation is called right residuation. We also define the left residuation A \B as the greatest solution X of AX B. By transposing this inequation we can see that A \B = (B T /A T ) T. III. THE PROBLEM Consider a Max-plus linear dynamical system x[k + 1] = Ax[k] Bu[k] (1) in which x[k] Z n max and u[k] Z m max. This models the firing times of a TEG, which in turn is considered being a model of some real plant. Assuming that we are able to measure all the states, the problem that is addressed in this paper is of designing a feedback control u[k] = f(x[0 : k]) (in which x[0 : k] is all the informations of the state available till the step k) that drives the system state x[k] to a specification semimodule 1 described as IV. THE PLANT, THE SIMULATOR AND THE MAX-PLUS MODEL We will apply the controller in a simulator that mimics a real plant. In this section, we will describe the real plant, the realistic simulator and the Max-Plus model of the form in Equation 1 that is obtained from the simulator and is necessary for control synthesis. A. The plant The real plant available at Université d Angers, more specifically at the Laboratoire angevin de recherche en ingénierie des systèmes (LARIS), is a conveyor belt system. See Figure 1 for a real picture and Figure 2 for schematics. The real plant is actually more complex than the one considered in [5] and in the simulator described in this paper, since it has behaviours that can not be modeled using TEGs (such as decisions for which path the pallets are going to take in the conveyor belt). S = {x Z n max Ex = Dx} (2) for given matrices E, D. For instance, we may desire that x 1 [k] 10x 2 [k], which can be written as x 1 [k] 10x 2 [k] = 10x 2 [k] and thus as a row of Ex[k] = Dx[k]. We also require that this convergence happens for any initial condition x[0] of Equation 1. This condition is actually important for guaranteeing robustness, that is, that the system is going to recover from an eventual perturbation and return to the desired set. Indeed, this perturbed state can be considered as the new initial condition of the same system and then, since convergence is guaranteed to any initial condition, we can be sure that the state eventually returns to the desired specification. This problem, or at least a simplified form of it, has been studied recently [9], [11], [1], [12], [6], [10], [7]. In all these aforementioned works the control structure is the same, a static linear feedback of the form u[k] = F x[k] for a matrix F, and thus the works differ in how this matrix is obtained and the formal guarantees we have attached to it. To the best of the authors knowledge, the only works that guarantee convergence for any initial condition x[0] are [6], [7]. In special, [7] presents a necessary condition for solving this kind of problem, that is also sufficient for a wide class of problems (the so-called non-critical problems). This condition is essentially the solvability of a two-sided Max- Plus eigenproblem [4], the so-called control characteristic equation. This will be the control synthesis strategy adopted in this work. 1 The Max-plus version of vector spaces. Fig. 1. Conveyor belt at the Université d Angers. Picture taken from [5]. Fig. 2. Schematics of the conveyor belt. Adapted and taken from [5]. The system is composed by two independent circuits, ten buttons (B1 to B10) and ten proximity sensors (before each button) that detect the time in which a pallet arrives at the button. It is considered that each one of the circuits have three pallets each, and the pallets in the inferior circuits move counter-clockwise and the one in the superior circuit clockwise. There is a limit on the number of pallets each stretch (path between two consecutive buttons) can hold (see Figure 2). The buttons control the flow of the pallets according to some conditions. In order to the button to be activated (go down), we must have There must be one pallet waiting just before the button;

100 98 ANEXO A. Artigo Submetido There must be a free space in the next stretch (see Figure 2), since there is a limit on the number of pallets in each one; There must be a control token, which can be made available independently, in the button. After the button is activated one token is consumed. When the button activates, it goes down and allows exactly one pallet to go to the next stretch. When this happens, it goes up again and blocks the next pallet in the queue. Another characteristic of the system is that the buttons B3 (in the superior circuit) and B10 (in the inferior circuit) are synchronized. They activate with the same conditions as the other buttons, but considering the conditions of both buttons. So, for instance, in order to the buttons B3 and B10 to activate there must be a pallet waiting in both B3 and B10. Thus, they always activate together. Clearly, we can use the control tokens to control the flow of the pallets and to impose some synchronization constraints. However, in the plant there are eventually some lubrication problems that make the pallets to be stuck for a while. This causes perturbations in any kind of synchronization that is imposed in the system. B. The simulator The simulator proposed for this work was developed in C# language with a friendly interface and with the same configurations of the real plant described in Subsection IV-A. Figure 3 shows the main screen of the system. Here, the user can set some simulation settings, as to stop and start the simulation, set simulation speed and set the probability of perturbation in the system, ξ. This perturbation randomly forces a pallet to get stuck for a while - mimicking real problems in the plant due to lubrication problems - with the rate set by the user. More precisely, after every time unit there is a probability ξ that a random pallet will be perturbed. Furthermore, the user can also hold a pallet manually by keeping the mouse cursor over it. Fig. 3. Main screen of the simulator. In the lower-left part, there are some buttons that implements specific functions. The first, Control options, opens the screen in Figure 4, in which the user can select the mode of operation for controlling the plant: Without controller: no automatic control is performed. The user adds control tokens manually for each button by clicking on the respective button; External automatic: loads from a.txt file control matrices F [i] and implements a control action of the form u[k] = s i= 1 F [i]x[k i] on the system; Internal automatic: same control structure as external automatic, but the matrices F [i] are computed internally according to user-specified Max-Plus linear constraints (as shown in Figure 4). The user can choose which buttons he/she wants to use when controlling (the others will always be enabled, i.e, infinite control tokens). The algorithm for computing the controller is based on the results in [7]. The user can also choose the causalisation method (two are implemented, the one from [12] and the one discussed on this paper, see Subsection V-A) and whether or not the user wants to implement the advanced term to improve robustness (see Subsection V-B); TCP/IP automatic: an external program controls the system using TCP/IP. The simulator provides interfaces for delivering information of the states, inputs and outputs to the external programs when requested as well as to add tokens to the buttons. This way, one can write a customized control strategy for controlling the system. Fig. 4. Control menu. Note that the control strategies implemented in the Control options assume the measurement of the full system state x[k]. In the real plant at Université d Angers, we do not have sensors for measuring all the events: we have available only the measurement of some events, respective to the proximity sensors close to each button. In our simulator, we have extra sensors (virtual sensors) to measure all the states and so state feedback can be performed. In the next button, Graphics, the user can see trend graphics for the variables x i [k] (states), u i [k] (inputs) and y i [k] (outputs). The user can also monitor the constraints he/she implemented in the Control options panel. See Figure 3, in which the user is following the constraint x 20 [k] = x 18 [k 1]. In this case, the graph displays the error e[k] = x 20 [k] x 18 [k 1], which should be as close to 0 as possible. In the TEG button, the user can see the TEG model for the system (see Subsection IV-C). This model displays, specifically, the physical meaning of each state event x i [k], input event u i [k] and output event y i [k], so he/she can be able to write, for example, the desired constraints in the Control

101 99 Fig. 5. Trend graphic for a constraint options panel. The button Add token buttons simply adds 10 control tokens for each button, Export data exports the simulation data (state, input and outputs events) to a.txt file and System Restart simply restarts the system (position of pallets, number of control tokens) to the initial setting. An Youtube video of the simulator running can be seen in C. The timed event graph model Using an identification procedure, performed by extracting data from the simulator, we were able to measure the holding times associated to each place in Figure 6. Consequently, we can write the dynamical system in the Max-Plus state space form as in Equation 1, in which x[k] is a vector with 33 entries and u[k] is a vector with 10 entries. With this model, we will be able to synthesize our controller to implement in our simulator, as described in [7]. It is very important to stress that while our model is a discrete event system, our simulated plant, and our realistic simulator, is a hybrid system, since it has time-driven and event-driven dynamics. Indeed, the continuous state of the system, the position of each pallet, changes continuously as the time passes and their position is important to determine the firing times of the events considered in the discrete event system model. For instance, one pallet localized in the middle of a stretch can get stuck and hold others before it, delaying the firing time of an event. This behaviour is not modelled in the TEG (Max-Plus) model in Equation 1, which considers the nominal traveling times between the buttons. Thus, the discrete event system model, Equation 1, is only an abstraction and simplification of the more realistic model of the real plant (the simulator). Seeing the impact of this abstraction on the efficiency of the controller (which is synthesized using the Max-Plus model) is one of the goals of this work. V. CONTROLLER SYNTHESIS AND ISSUES With the Max-Plus model and the simulator on hand, we will establish some constraints on the form of Equation 2 and use the technique presented in [7] to generate a controller u[k] = F x[k]. But, before we implement this controller, we need to discuss two problems. One, that outright prevents the implementation of the controller, is that it can be noncausal. The other is that it may be nonrobust, that is, it may take many events to converge to the desired specification after a perturbation happens on the system. We will address both issues in this section. Fig. 6. TEG that models the system, taken and adapted from [5]. The conveyor belt system, and therefore our realistic simulator, can be modeled as a TEG, as can be seen in Figure 6. We have three kinds of events: the black ones (state events), the red events (independent inputs, representing the aforementioned control tokens in each button) and the green events (outputs, arrival time at each button, not used currently in the simulator). As mentioned previously, in our simulator we have some virtual sensors that are not available in the real plant. They allow all the states in Figure 6 to be available for implementing the state feedback control, to be discussed in Subsection V. More details of the modelling of this system can be found in [5]. A. Causality As with many others control synthesis techniques, there is no guarantee that the controller u[k] = F x[k] derived from [7] is implementable, since it may be non-causal and demand a prediction of events. This happens when the matrix F has non-ε negative entries. To the authors best knowledge, the only idea for causalisation of general controllers u[k] = F x[k] available in literature was presented in [12]. This technique works as follows: assuming that the control law is implementable, we can plug it into Equation 1 and obtain x[k + 1] = (A BF )x[k] = Mx[k] in closed loop. Then, we have that for any r, x[k] = (A BF ) r x[k r] = M r x[k r]. Thus u[k] = F x[k] = F M r x[k r]. (3) The idea is choosing r large enough so F M r is causal. This is always possible if M is strongly connected and ρ(m) > 0 (see [12]), two very reasonable hypotheses in practical systems. In a nutshell, the core idea of the technique is to use the closed loop model x[k] = Mx[k 1] to be always able to