PROJETO DE SISTEMA ATIVO DE CONTROLE HOLÔNICO PARA SISTEMAS PRODUTIVOS

Transcrição

1 6º CONGRESSO BRASILEIRO DE ENGENHARIA DE FABRICAÇÃO 6 th BRAZILIAN CONFERENCE ON MANUFACTURING ENGINEERING 11 a 15 de abril de 2011 Caxias do Sul RS - Brasil April 11 th to 15 th, 2011 Caxias do Sul RS Brazil PROJETO DE SISTEMA ATIVO DE CONTROLE HOLÔNICO PARA SISTEMAS PRODUTIVOS Robson Marinho da Silva, rmsilva@uesc.br 1 Maruedson Pires Martins, maruedson01@yahoo.com.br 1 Fabricio Junqueira, fabri@usp.br 2 Diolino José dos Santos Filho, diolino.santos@poli.usp.br 2 Paulo Eigi Miyagi, pemiyagi@usp.br 2 1 Universidade Estadual de Santa Cruz, Ilhéus, BA 2 Escola Politécnica da Universidade de São Paulo, São Paulo, SP Resumo: A utilização de novas tecnologias em PSs (Productive Systems) potencializa a execução múltipla e simultânea de diferentes processos explorando o intenso compartilhamento de recursos. Entretanto, para isso são necessárias novas abordagens para a supervisão e controle desses processos. Além disso, mesmo com o alto grau de automação desses PSs, sistemas totalmente infalíveis são inviáveis na prática, e para que um processo produtivo não sofra interrupções devido a alguma falha, os mecanismos de AFTCS (Active Fault-Tolerant Control System) devem ser adotados. Por outro lado, o HCS (Holonic Control System) é considerado uma interessante abordagem para a supervisão e controle de PSs, e desta forma é fundamental um estudo da combinação das técnicas de HCS e AFTCS visando assegurar maior flexibilidade, eficiência e robustez a estes sistemas. Neste contexto, este trabalho apresenta um procedimento para o projeto de AHCS (Active Holonic Control System) para supervisão e controle dos processos em PSs. O AHCS considera os requisitos de AFTCS e utiliza a PN (Petri Net) para a descrição da estrutura e do comportamento do sistema. Um exemplo de um FMS (Flexible Manufacturing System), considerado uma classe representativa de PS, é apresentado para demonstrar as vantagens do procedimento proposto. Palavras-chave: sistema de controle, tolerância à falha, rede de Petri, sistema holônico, reconfiguração. 1. INTRODUÇÃO Avanços em sistemas mecatrônicos, redes de comunicação e métodos de organização do trabalho, aliados à crescente competitividade e a necessidade de serviços eficientes alanvacaram grandes mudanças nos PSs (Productive Systems) exigindo mais flexibilidade sob diferentes demandas, tais como volume de produção, tipo de produto e natureza dos recursos envolvidos. Os PSs têm sido projetados para atender as demandas de produção e o foco, em geral, está na transformação tecnológica de material, no processamento de informações e na execução da ordem de produção, considerando atualmente requisitos de flexibilidade e agilidade. Estes sistemas devem executar múltiplos processos simultâneos, explorando o intenso compartilhamento de recursos, o que torna relativamente complexa a supervisão e controle do comportamento global destes sistemas (Schoop et al., 2002; Leitão et al., 2006 e Silva et al., 2011). Especificamente, observa-se que os sistemas de supervisão e controle têm evoluído de uma arquitetura centralizada e hierárquica para uma arquitetura heterárquica ou distribuída. Nessa nova arquitetura, o sistema é composto por vários sub-sistemas (que podem até ser instalados em diferentes localizações geográficas), em que as tarefas são divididas de acordo com a funcionalidade e capacidade de processamento de cada equipamento (Silva et al., 2011). Por outro lado, segundo Zhang & Jiang (2008), para assegurar que os processos produtivos do PS não sofram interrupções, devido a falhas de seus componentes, mecanismos de AFTCS (Active Fault-Tolerant Control System) devem ser considerados. Estes mecanismos envolvem a detecção da falha, o estudo dos seus efeitos, identificação das causas e, finalmente, a reconfiguração do sistema que é feita realocando funções e escolhendo caminhos alternativos de interação entre os processos (Arakaki & Miyagi, 2006). Em caso de ocorrência de falhas, a estratégia é recuperar as funcionalidades do sistema (regeneração) para manter operações críticas de tal forma que algumas partes do sistema são desativadas sem afetar outras partes (degeneração). Neste contexto, a integração de técnicas de MASs (Multi-Agents Systems) e HSs (Holonic Systems) com a tecnologia mecatrônica, chamado HCSs (Holonic Control Systems), é considerada uma tendência para a automação inteligente de PSs (Schoop et al., 2002; Silva et al., 2011; Sousa et al., 2004 e Colombo et al., 2001). O objetivo é explorar os conceitos que fundamentam os MASs e HSs como autonomia, reatividade, pró-atividade, cooperação, capacidade social (i.e., a consideração da interação humana no processo), e recursos de aprendizagem, considerando as vantagens complementares na implementação de HSs, por meio de MASs. Entretanto, a maioria dos sistemas de supervisão e controle de PSs não adotam mecanismos de HCSs e AFTCSs. De fato, a quantidade de material publicado sobre projeto de PSs que consideram a utilização dessas técnicas ainda é Associação Brasileira de Engenharia e Ciências Mecânicas 2011

2 muito pouca (Schoop et al., 2002; Zhang & Jiang, 2008; Sousa et al., 2004; Leitão et al., 2006). Portanto, este trabalho visa contribuir para esta área apresentando um procedimento para a modelagem e operação de AHCS (Active Holonic Control System) para PSs, e suas especificações funcionais, em circunstâncias normais, e também no caso de ocorrência de falhas. Um exemplo de um FMS (Flexible Manufacturing System), considerado como uma classe de PS, é apresentado para ilustrar as vantagens do procedimento proposto. 2. PETRI NET (PN) Desde a sua apresentação em 1962 por Carl A. Petri, a PN (Petri Net) tem sido considerada como uma poderosa ferramenta para modelagem, análise e design de DES (Discrete Event System) (Reisig, 1985). Esta ferramenta permite uma descrição gráfica e matemática do sistema. A PN oferece a possibilidade de: (i) representação dinâmica do sistema e sua estrutura em vários níveis de abstração, (ii) representaçao de processos com sincronismo, concorrência, causalidade, conflito, compartilhamento de recursos, (iii) representação de estratégias de controle de PSs, e (iv) representação matemática para a realização de testes formais das propriedades do sistema. Isto é especialmente útil em aplicações de PSs (Silva et al., 2011). Alguns autores definem um modelo de PN homogêneo que inclui um único formalismo para descrever todo o sistema. Outros autores utilizam formalismos diferentes para cada parte do sistema. A primeira é formalmente mais elegante, mas apresenta dificuldades porque, em casos práticos, não é comum adotar uma perspectiva única para a concepção e projeto de todas as partes do sistema. A segunda é derivada da heterogeneidade dos sistemas reais e do ponto de vista dos projetistas de cada parte do sistema. Como este trabalho considera o uso prático, a segunda abordagem é adotada, mas para evitar a necessidade de especialistas para um grande número de formalismos, apenas dois tipos de PNs são considerados. Para modelar o comportamento dinâmico, é adotada um tipo de PN baseada na PN lugar/transição, chamada E-PN (Enhanced Petri Net), onde foram adicionadas transições temporizadas (termos relacionados com PN são apresentados em fonte Arial), arcos inibidores e arcos habilitadores (David & Alla, 1994). Para construir estes modelos um método que aplica uma derivação de PN canal/agência chamado PFS (Production Flow Schema) (Hasegawa et al., 1999) é usado. O PFS é uma técnica desenvolvida para sistematizar e facilitar a modelagem de PSs. Iniciando a modelagem do sistema em um alto nível de abstração, onde refinamentos sucessivos são aplicados e, em cada nível o modelo é mais detalhado. O objetivo é representar estruturadamente a funcionalidade das partes envolvidas na execução das atividades e o fluxo de operações dos processos produtivos. Assim, o procedimento combina a abordagem bottom-up e a abordagem top-down do refinamento gradual associado ao PFS. Relacionado à modelagem de falhas em DESs, já existem estudos para representar a detecção e o diagnóstico destas falhas. Miyagi & Riascos (2006), por exemplo, mostram que é possível desenvolver modelos de PN através da caracterização de padrões e detecção de falhas baseada em processamento de sinais de sensores. Em Sampath et al. (1996) é apresentado um procedimento para a modelagem de PSs com base em modelos de diagnóstico de falhas. Zhang & Jiang (2008) apresentam uma arquitetura padrão de AFTCSs e uma revisão bibliográfica classificada de acordo com diferentes critérios, tais como metodologias de projeto e aplicações. 3. HOLONIC CONTROL SYSTEM (HCS) A característica principal de um HCS é o seu foco no comportamento do sistema (Schoop et al., 2002, Colombo et al., 2001). O HCS é um sistema baseado em agentes inteligentes e plataformas de hardware multifuncional, para a integração flexível de hardware e funcionalidades de software que implementam os holons. Um levantamento de trabalhos publicados como Leitão et al. (2005), Colombo et al. (2001), Schoop et al. (2002), Sousa et al. (2004), Scheidt (2002) e as suas referências, mostra que existem várias contribuições que tratam da aplicação do conceito de holons ou agentes na área de PSs. Estes trabalhos foram considerados para a especificação da arquitetura e também motivaram o procedimento de modelagem aqui proposto. Analisando estes trabalhos, verifica-se que: ainda é pequeno o número de trabalhos que consideram a integração dos requisitos de HCS e AFTCS, assim como são poucas as aplicações práticas das tecnologias de agente, o que sugere que há um longo caminho para uma ampla utilização desses HSs. Assim, pode-se destacar que o desenvolvimento de aplicações também é considerado uma contribuição relevante; na maioria desses sistemas há troca direta de informações no formato de solicitação-resposta entre holons. No entanto, um HS deveria conceitualmente apresentar uma estrutura de comunicação que garante o alto nível de autonomia dos holons e funções baseados essencialmente no comportamento. Portanto, um mecanismo de negociação é mais favorável do que um formato de comunicação de solicitação-resposta entre holons. Por outro lado, um sistema que considera a reconfiguração requer recursos redundantes (Zhang & Jiang, 2008) e necessita assim considerar a malha de transmissão de sinais de controle como uma parte do sistema sendo controlado, pois, um problema nesta malha também pode afetar a coerência das ações de comando (Scheidt, 2002); e não há nenhuma informação sobre o uso de uma abordagem sistemática, como o PFS, para estruturar e racionalizar os modelos de desenvolvimento das arquiteturas propostas. Ou seja, padrões emergem sem um ambiente que facilite o desenvolvimento de novos modelos.

3 4. ARQUITETURA DE CONTROLE DO AHCS O AHCS é assim um sistema derivado de HCS para supervisão e controle dos processos em PSs, associada a um procedimento para o projeto e que considera os requisitos de AFTCS e utiliza a rede de Petri para a descrição da estrutura e do comportamento do sistema. Na arquitetura de AHCS, ilustrada na Fig. 1a, cada holon pode ser um recurso físico (CLP, robô, máquina CNC, etc.) ou um componente lógico (ordem de produção/ serviço, tipo de produto/ serviço, etc.). Cada holon é responsável por executar diferentes funcionalidades e seu comportamento individual contribui com outros holons para representar o comportamento do sistema inteiro. O holon do nível de planejamento, PrH (Product Holon), contém todo o conhecimento necessário para o funcionamento do PS e para escolher a estratégia que atinge os objetivos traçados. O holon do nível de ordenação, StH (Strategies Holon), contém todo o conhecimento para gerenciar a execução de cada estratégia de produção que resulta num produto. O holon do nível de supervisão, SuH (Supervisor Holon), tem como principal função a elaboração e execução de planos otimizados para os holons do nível de controle local, (Operational Holon). O representa os recursos físicos da planta que possuem algum dispositivo de controle para o seu funcionamento e estabelece o comportamento destes recursos de acordo com os objetivos e habilidades de cada um. O segue uma agenda, ou seja, a lista planejada de tarefas que o recurso tem de executar Mecanismos de tolerância a falhas de AHCS A seguir apresentam-se os mecanismos para execução de tarefas com autonomia e agilidade, que facilitam a interação e verificação do desempenho dos holons, e a alteração da estrutura de controle hierárquico para heterárquico, de acordo com a presença de falhas. Os mecanismos propostos permitem o chaveamento do controle e a negociação entre os holons. O chaveamento de controle envolve dois modos de operação: o modo estacionário em que o sistema de controle é coordenado de forma hierárquica e os s seguem a coordenação do SuH, e o modo transiente, em que os s assumem o controle (vide Fig.1a). Durante o modo estacionário os s interagem com os níveis hierárquicos superiores e durante o modo transiente, bem como, durante a alocação de serviços ou comandos, os StHs interagem diretamente com os s. As holarquias são representadas por elipses e um holon pode pertencer simultaneamente a várias holarquias (Fig. 1b) Negociação entre holons Figura 1. (a) Arquitetura de controle e (b) holarquias de AHCS. O mecanismo de negociação entre holons é baseado em regras que permitem negociação entre holons baseada em créditos recompensas e débitos penalidades, dependendo se uma ordem é executada com sucesso ou não. Quando um StH está encarregado de executar uma determinada estratégia, ele recebe as seguintes informações do PrH: a estratégia escolhida, uma medida quantitativa chamada fundo do serviço (π), o tempo programado, um valor de penalidade pelo atraso (φ), e um valor de recompensa (ε) por finalizar com sucesso. O StH deve gerenciar a negociação com os s para atingir o objetivo sem ultrapassar o valor limite previsto para o fundo do serviço. Por exemplo, durante alocação de novas ordens, há interação entre StHs e s. Após esta interação o StH aceita transferir (pagar) uma recompensa ε ao pela conclusão da ordem e receber uma penalidade φ se a ordem não for concluída no tempo devido. O desempenho dos holons é avaliado pelo resultado obtido dos valores obtidos de recompensas menos penalidades. A Tab. (1) sumariza a evolução desse mecanismo Estimação do tempo de recuperação Conforme representado na Fig. 2a, descreve-se aqui uma forma de estimar o tempo de reconfiguração. Se o recurso afetado pela falha ficar indisponível por um longo período de tempo, o prevê o tempo de recuperação (t r ), para poder revisar sua agenda, verificar as ordens planejadas durante o tempo de recuperação e, então cancelar a alocação

4 atual destas ordens, notificando o StH. Para isto, o estima dois parâmetros distintos: (i) t e que define o tempo em que as ordens precisam retornar para o StH, e (ii) t c que é o tempo para verificar se a falha foi recuperada, re-estimar e re-aplicar os parâmetros do tempo se a falha não foi recuperada como previsto. Este tempo é menor que t e. Uma possível maneira para calcular estes dois valores é determinar o tempo de recuperação (t r ) despendido em tratamento de falhas anteriores e assumir 50% para t c e 90% para t e. Transcorrido t c, se a falha não está recuperada, é necessário re-estimar os parâmetros de tempo e cancelar as estratégias que estão planejadas para o novo intervalo de tempo. Obtém-se o novo tempo estimado somando t c a t e e verificando novamente a recuperação em t c. O remove a ordem planejada que seria executada dentro do novo intervalo de tempo (t c + t e ) de sua agenda local, enviando mensagens para os StHs responsáveis por cada uma destas ordens. Durante o tempo que o recurso está indisponível, o somente recebe novos comandos se estes puderem ser executados fora do intervalo de tempo estimado para recuperação. Após a execução da ação de recuperação, o armazena as informações relevantes sobre a falha, principalmente o tempo de recuperação e a solução utilizada para recuperá-la. O registro destas informações permite criar novo conhecimento que suportará futuras reações às falhas. Tabela 1. Mecanismo de negociação baseado em créditos e débitos entre holons. Fase holon de estratégia (StH) holon operacional () Alocação de uma ordem contrata a execução da ordem por ε e a penalidade por φ. contrata a execução da ordem por ε e a penalidade por φ. Finaliza uma operação com sucesso. paga o valor ε ao HO, i.e., π π ε aumenta o total dos créditos por ε, i.e., µ µ+ε Finaliza uma operação com atraso. paga o valor ε e recebe o valor φ do HO, i.e., π π ε+φ diminui o total de créditos por φ e aumenta por ε, i.e., µ µ+ε-φ Operação cancelada (atraso, defeito, etc.) recebe o valor φ do HO, i.e., π π+φ diminui o total de créditos por φ, i.e., µ µ-φ Fator de autonomia A autonomia de cada é neste caso associado a um fator de autonomia, i.e., uma variável discreta {baixo, alto}. Inicialmente, o tem um fator de autonomia {baixo}, que permite a sua coordenação pelo SuH, executando quando disponível, os planos que o SuH indica. Quando uma falha ocorre e esta é identificada, inicia-se o tratamento da falha. Esta função adapta o comportamento dos holons na presença de falha. As entradas para esta função são: (i) o valor da variável do fator de autonomia (α); (ii) o tempo de restabelecimento (τ) que é o tempo estimado necessário para a recuperação da falha; e (iii) o parâmetro do tipo de falha (ρ) que indica a ocorrência de uma determinada falha. No caso de um fator de autonomia {baixo}, a ocorrência de uma falha representada por {ativa}, gera a mudança do fator de autonomia para {alto} e a seleção de um comportamento adequado para o tratamento da falha. Depois de transcorrido τ, se o fator de autonomia é {alto} e a falha ainda está {ativa}, isto significa que o sistema ainda não foi recuperado e, e τ é re-estimado. Caso a falha e a situação causada pela mesma já foi resolvida, situação indicada por {inativa}, o holon pode retornar a estrutura anterior à ocorrência da falha, mudando o fator de autonomia para {baixo}. Quando a falha é removida, ou seja, quando a sua causa e suas conseqüências são sanadas, cada reduz novamente seu fator de autonomia e retorna a estrutura de controle hierárquica, entrando novamente no modo estacionário AFTCS no AHCS Para considerar a ocorrência de falhas, as funções de AFTCS no AHCS são divididas em quatro fases (Fig. 2b) e estão presentes em cada holon independente do tipo. A fase de estimação envolve: (i) a detecção de sintomas, que podem identificar a existência de falhas através da supervisão dos processos e (ii) o isolamento da falha que é baseado em um modelo contendo características (tipo, dados estatísticos, etc.) que asseguram a identificação da falha. Quando os sintomas detectados não permitem qualquer conclusão, o sistema deve ser programado para identificar o tipo de falha em casos similares ou requisitar intervenção externa. A fase de planejamento decide a ação de reconfiguração baseada em prioridades pré-definidas como, por exemplo: menor queda de desempenho, menor tempo de recuperação, etc. A partir de dados históricos, é possível medir a significância estatística de cada tipo de falha em termos como a taxa de freqüência, o tempo de recuperação e o custo operacional. A fase de execução envolve o envio de comandos para execução do plano de ação selecionado. A última fase é a de aprendizagem que envolve a armazenagem dos dados relevantes em relação ao plano executado. Portanto, pode-se afirmar que AHCS atua de acordo com as seguintes regras de AFTCS: se <sintomas> então <seleciona falha>; se <falha selecionada> então <seleciona ação>; se <ação selecionada> então <ativa reconfiguração>; e se <reconfiguração executada> então <armazena dados relevantes>.

5 Figura 2. (a) Estimação do tempo de reconfiguração e (b) fases de AFTCS no AHCS. 5. PROCEDIMENTO DE MODELAGEM O procedimento de desenvolvimento do AHCS está ilustrado em PFS na Fig.3a e envolve: análise de requisitos, modelagem considerando reconfiguração, análise/simulação, implementação e operação. O foco neste trabalho está nas etapas 1 e 2. Etapa 1 - análise de requisitos o detalhamento em PFS desta etapa está ilustrado na Fig. 3b. São definidas as especificações de AHCS: objetivo do sistema, objeto de controle, dispositivos de controle, definição das tarefas, estratégias e funções de controle, a descrição da interação entre as partes do sistema, e os casos de reconfiguração. Ou seja, define-se as características estruturais da planta física sob controle, seu layout e recursos, os planos de processos dos produtos disponíveis e as estratégias de controle em situação normal e sob efeito de falhas. A especificação destes planos envolve, entre outros, a definição das matérias-primas, a lista de operações, e as precedências entre as operações. Cada operação é caracterizada por uma breve descrição, o tipo necessário de máquina que pode executar a operação e o prazo de execução estimado. Sub-etapa identificação dos holons - aqui alguns holons são identificados, i.e.,, SuH e PrH. O StH é criado de acordo com a necessidade de produção, não sendo possível identificá-lo durante a fase de projeto. Quando um PrH recebe uma solicitação para produzir algum produto, ele solicita o gerenciamento da execução a um StH, informando os dados necessários para produção como tempo, planos alternativos de processo, funcionalidades dos recursos envolvidos, e seqüências de operação. Inicialmente, identifica-se os s que coordenam as atividades desses recursos de acordo com os objetivos e habilidades de cada um. A identificação do PrH envolve a definição das funções de controle de cada produto a ser processado no PS e dos planos de execução das ordens de produção. Assim, o PrH contém todo o conhecimento necessário para operar o PS e escolher a melhor estratégia para alcançar os objetivos planejados. A função do StH envolve a preparação da agenda e coordenação de decisões para a execução dessas tarefas. Quando um processo solicita um recurso, na verdade, está solicitando ao StH o controle da alocação dos recursos. O SuH verifica os recursos disponíveis que possuem as funcionalidades necessárias para executar este processo. Sub-etapa 1.2 especificação com requisitos de tolerância à falha aqui se considera além da operação em condições normais, as medidas a serem tomadas em casos imprevistos como falhas, falta de energia, erros de operação, etc. Estas especificações regulam o comportamento do sistema definindo, por exemplo, a execução da agenda, o gerenciamento da execução, a supervisão, o fator de autonomia, o chaveamento do modo de controle e a reorganização estrutural da arquitetura do AHCS. Os objetivos nesta sub-etapa são listar: (i) a identificação das falhas e dos pontos críticos (falhas que podem afetar as funções essenciais do sistema), (ii) as especificações para o diagnóstico de falhas e (iii) as estratégias para tratamento de falhas e para reconfiguração. A Tab. (2) relaciona alguns aspectos que devem ser levantados nesta etapa. Tabela 2. Aspectos relacionados a requisitos de tolerância a falha. Aspecto ocorrência de falha ponto crítico componente do sistema sensoriamento arquitetura do sistema ação de reconfiguração Questões a serem analisadas Que falhas podem ser detectadas e diagnosticadas? Em que condições estas falhas podem ser detectadas e diagnosticadas? Quais as soluções e o tempo necessário para recuperação destas falhas de acordo com dados existentes ou históricos? Que falhas podem levar a uma reconfiguração do sistema? Que parâmetros podem ser reconfigurados? Que informações devem ser coletadas e em que freqüência? Que recursos podem ser utilizados para reconfigurar o sistema? Qual o grau de redundância a ser considerado? Qual grau de degradação de desempenho é aceitável para cada processo? Sub-etapa definição de padrões de interação entre holons aqui as especificações de processos interativos entre holons são definidas: pedido de novos produtos, execução, tratamento de falhas e reconfiguração. O AHCS considera a comunicação direta entre o StHs e s para alocar comandos e executá-los, tratar de falhas e reconfigurar o sistema. Isto permite o uso de diferentes estruturas de controle, resultando em uma reação mais rápida

6 contra distúrbios no sistema. Interações adicionais que envolvem a transmissão de comandos específicos da aplicação, entre StHs, s, e o objeto de controle, são definidas durante o desenvolvimento dos modelos do projeto em estudo. Etapa 2 - modelagem considerando reconfiguração - modelos em PFS e E-PN representam as interações de negociação entre holons, a solicitação de ordens aos s, a preparação e execução dessas ordens e, o tratamento de falhas em sua ocorrência. A sincronização dos modelos em E-PN é feita por arcos habilitadores e inibidores. Essas interações são extraídas do diagrama de seqüência UML (Unified Modeling Language) (Booch et al., 1999). Na Fig. 3c tem-se em PFS que ilustra um exemplo de modelagem do PrH, que envolve, a atividade [elaboração de plano], ações de levantamento de estratégias alternativas e requisitos para execução de um determinado produto. Figura 3. PFSs do procedimento de desenvolvimento. As estratégias de controle de AHCS são modeladas nesta etapa, como os mecanismos diagnosticador e decisor para cumprir as exigências das fases de diagnóstico e decisão. Os passos para a concepção do modelo em E-PN do diagnosticador são: (i) construção de modelos em E-PN dos componentes do objeto de controle, (ii) construção de modelos de estratégias de controle em PFS e E-PN; (iii) definição de eventos observáveis, geralmente aqueles relacionados a comando de estratégia de controle, e eventos não-observáveis (Sampath et al., 1996), geralmente relacionados a falhas; (iv) construção de modelos de E-PN de sensores; (v) construção do modelo em E-PN do diagnosticador a partir do estado inicial considerado normal (i.e., sem falhas); (vi) definição das interações, por meio de transições e arcos de habilitação, das estratégias de controle realizadas com possíveis eventos observáveis e não observáveis que podem acontecer a partir do estado inicial, e (vii) relacionar os estados obtidos com os estados dos sensores, e assim verificar se o sistema obteve sucesso na execução do comando. Se o diagnosticador não indica o estado correto, então as causas devem ser inferidas para resolver possíveis conflitos. Este mecanismo de decisão é chamado de decisor e suas regras de tomada de decisão podem ser baseadas em dados probabilísticos, por exemplo. Em Silva et al. (2011) é apresentado um exemplo de desenvolvimento de um modelo de diagnosticador e decisor. Etapa 3 análise/ simulação esta etapa é desenvolvida com apoio de ferramentas de edição, análise estrutural e simulação de E-PN. Este tipo de análise permite a re-engenharia do sistema de controle durante a fase de projeto. Esta etapa é subdividida em: análise qualitativa e quantitativa. A análise qualitativa permite a verificação das propriedades estruturais e comportamentais, para derivar conclusões sobre o funcionamento do sistema, tais como: (i) vivacidade, que está relacionado com a ausência completa de bloqueios no PS; (ii) acessibilidade, para estudar as propriedades dinâmicas do PS; (iii) reversibilidade, para se recuperar de eventos de interrupção da operação; (iv) conservação e limitação, para verificar a variação do número de marcas. Para realizar análise quantitativa é necessária a introdução do parâmetro de tempo associado com as transições. Assim, é possível verificar se o disparo de transições é consistente com as especificações do PS. A análise quantitativa é realizada por meio de técnicas de simulação associada com as propriedades da E-PN. O uso de aplicativos computacionais voltados para a simulação de sistemas a eventos discretos, e.g. Simul8 (Concannon et al., 2004), permitem também que se construa um modelo do processo com tempo relativamente reduzido, com vantagens na visualização. Desse modo, além de se obter estatísticas, é possível visualizar o seu funcionamento e detectar possíveis erros ou problemas no sistema, facilitando o entendimento dos stakeholders (envolvidos) no projeto. Etapa 4 - implementação - para o uso prático, os modelos resultantes são interpretadas como especificações de programas de controle a serem executados por controladores programáveis (nível de controle local) e computadores (nível de controle supervisório). Essa etapa também compreende a codificação, parametrização e desenvolvimento de interfaces específicas de cada equipamento (Fig. 4a). Etapa 5 - operação - nesta etapa, a supervisão em tempo real do sistema de supervisão e controle é realizada sincronizando o funcionamento dos modelos em E-PN com os sinais de sensores do estado dos dispositivos, permitindo a geração de relatórios e gráficos de controle, a fim de supervisionar e controlar o sistema (Fig. 4b). A adaptação e reconfiguração de AHCS é suportado usando este procedimento, ou seja, a introdução ou remoção de novos componentes requer a adição ou remoção de novas marcas nos modelos correspondentes de E-PN e, em alguns casos, a modificação dos modelos em E-PN de holons.

7 Figura 4. Implementação e operação do AHCS. 6. EXEMPLO DE APLICAÇÃO EM UM SISTEMA DE MANUFATURA Um sistema flexível de manufatura (FMS flexible manufacturing system) é uma classe de PS e aqui é utilizado para ilustrar as principais características das etapas 1 e 2 do procedimento proposto. Etapa 1 análise de requisitos o objetivo deste sistema (Fig. 5a) é efetuar trabalho sobre dois itens (A,B). O sistema é composto por três estações de trabalho (WS1, WS2, WS3), um robô manipulador (R), um local de carregamento (L) e descarregamento (U), uma estação de armazenamento de pallets (P). Um operador humano (H) é responsável pela supervisão, inspeção, manutenção, operações de inicialização e de finalização. As estações de trabalho processam um item de cada vez, e cada uma das estações possui um buffer de entrada (Bin) e um buffer de saída (Bout) considerados com capacidade de armazenamento infinita. O robô R é responsável pelo carregamento e descarregamento dos itens e, se necessário entre as estações, i.e., considera-se que R1 tem total liberdade de movimento e acesso a todo o sistema. As seqüências de operações são: item A: Op_WS1 Op_WS2 e item B: Op_WS3 Op_WS2. Em que Op_WS1, Op_WS2 são trabalhos realizados sobre A e B em WS1 e WS2, respectivamente. Para garantir certo grau de redundância ao sistema é considerado que após um determinado tempo de inicialização (setup) a WS2 pode realizar tanto a operação da WS1 como da WS3. Assim, de acordo com a necessidade, as seqüências podem ser: A: Op_Set Op_WS2 Op_Set Op_WS2 e B: Op_Set Op_WS2 Op_Set Op_WS2, em que Op_Set representa a operação de setup para ajustar WS2 a realizar o trabalho. Sub-etapa 1.1- identificação dos holons: para identificar os s, o primeiro passo é encontrar o conjunto de recursos disponíveis no chão de fábrica. Na Tab. (3) estão listados os s deste sistema, que representam os recursos: robô, operador humano, estação de trabalho, transportador e pallet. Observa-se que nem todos os recursos disponíveis são candidatos a estar associado à holons, pois, analisando as dependências físicas entre os objetos identificados, é possível agregar recursos em um único holon. Neste exemplo, os buffers de entrada e saída são considerados partes de suas respectivas estações de trabalho, e considera-se o conjunto de buffers e estação como sendo um único. Tabela 3. Identificação de s. descrição funcionalidade un. R1 robô transporte/ carga/ descarga peças (A,B) 1 WS1 estação de trabalho efetuar operação OpWS1 1 WS2 estação de trabalho efetuar operação OpWS2 1 WS3 estação de trabalho efetuar operação OpWS3 1 Tr1 transportador transportar peça entre buffer de saída da WS1 para buffer entrada WS2 1 Tr2 transportador transportar peça entre buffer de saída da WS1 para buffer entrada WS2 1 H operador humano supervisão, inspeção, manutenção, operações de inicialização e de finalização 1 Há dois holons de produto: PrH-ProdA e PrH-ProdB que representam os itens A e B que são trabalhados no FMS. Dividem-se as estratégias de controle do sistema em funções operacionais e de modo de operação. Os StHs não são definidos durante a fase de projeto, mas são os responsáveis pelo gerenciamento destas estratégias. As funções operacionais envolvem as estratégias de produção de A e produção de B. As funções de modo de operação envolvem a seleção entre modo de controle automático ou semi-automático. A diferença entre estes modos é que no modo semi-automático o sistema solicita autorização ao operador humano para prosseguir ao término de cada operação. A identificação do SuH pode ser feito através da análise da descrição dos níveis hierárquicos no controle da planta. Neste caso, apenas um SuH (SuH-FMS) para o controle do sistema é considerado. Sub-etapa 1.2 especificação com requisitos de tolerância à falha - é feito inicialmente o levantamento de pontos críticos, tratamento de falhas e a degeneração, vide Tab. (4). As estratégias desenvolvidas com base nesse levantamento

8 são enviadas pelo PrH para serem implementadas tanto nos StHs como nos s dependendo do nível desejado de reação. Sub-etapa definição dos padrões de interação entre os holons - na Fig. 5b tem-se o diagrama UML, o PFS e a E-PN das interações para [execução] que ocorre entre StHs e o na ordem de execução [solicita pallet]. Observase que o pode receber ordens de execução de StHs diferentes, que para facilitar a compreensão foram denominados conforme o item (A, B) que deve executar (StH- prod A, StH prod. B). Tabela 4. Lista de pontos críticos, tratamento de falhas, e reconfiguração e/ou degeneração. pontos críticos tratamento de falha reconfiguração e/ou degeneração falha no carregamento / descarregamento atua nas variáveis de controle e reinicializa o controlador mudar para modo de controle semi-automático e solicita transporte através de operador humano falha nos sensores e/ou nos alarmes mudar parâmetros nos dispositivos para tentar resolver a falha, liberar acesso para técnicos mudar para modo de controle semi-automático falta de energia perda total de comunicação entre dois hosts de manutenção acionar geradores para manter o funcionamento verificar qual a melhor estratégia a ser adotada e, se necessário reiniciar os nós com falha se a energia gerada não for suficiente para manter toda a fábrica, reduzir a energia em outros subsistemas e manter nas áreas prioritárias identificar caminhos alternativos e adotar o que tiver menor MTBF Etapa 2 modelagem considerando reconfiguração - A modelagem dos s envolve o detalhamento do comportamento dos dispositivos físicos. De acordo com o objeto de controle sob estudo, tem-se a especificação funcional da atividade [execução], ou seja, do envio e recebimento de sinais do para o objeto de controle. Na Fig. 5b tem-se o exemplo em que o -P recebe solicitações de dois StHs e informa a disponibilidade existente de pallet. Na Fig. 5c têm-se os modelos em PFS e E-PN de: (i) plano de produção do produto A, (ii) E-PN objeto de controle de robô e seu controlador considerando a influência da malha de transmissão de sinais de controle, (iii) E-PN do refinamento em PFS da atividade [carrega em WS1], e (iv) detalhamento em E-PN das estratégias para executar a atividade [efetua OP_WS1]. Na Fig. 5d tem-se um exemplo para tratamento de falha [falta de energia] e sua reconfiguração. 7. CONCLUSÕES Um procedimento para projeto de um sistema de controle, chamado AHCS (active holonic control system) que considera não somente as operações normais mas também a ocorrência de falhas em sistemas produtivos (SPs) foi apresentado. O AHCS combina os requisitos de um sistema de controle holônico (HCS) e de um AFTCS (active faulttolerant control system), com especial atenção para a reconfiguração do sistema. O processo de modelagem é baseado em uma interpretação e uma extensão da rede de Petri, PFS e E-PN respectivamente, que são utilizados para estruturar o desenvolvimento dos modelos dos componentes e a apresentação do procedimento proposto. São propostos mecanismos de tolerância às falhas que garantem flexibilidade ao sistema, implementação de uma estrutura de controle hierárquico ou heterárquico e, a reação às falhas de forma mais ágil. Um exemplo de aplicação em um sistema de manufatura flexível demonstra as vantagens do procedimento proposto. O procedimento de desenvolvimento do AHCS está dividido em etapas: etapa 1 - análise de requisitos, etapa 2 - modelagem considerando reconfiguração, etapa 3 - análise/simulação, etapa 4 - implementação e etapa 5 - operação. O foco neste artigo está nas etapas 1 e 2. Um projeto mais amplo está sendo desenvolvido (Silva et al., 2011), que envolve além da modelagem, simulação e validação dos modelos de E-PN, o desenvolvimento de um estudo de caso experimental de AHCS. Naquele projeto, os parâmetros para analisar a efetividade do sistema de controle de PSs envolvem: a flexibilidade, a reconfigurabilidade, a robustez e a agilidade, que são parâmetros difíceis de avaliar por apresentarem certo grau de subjetividade em sua análise. A flexibilidade neste caso está relacionada à capacidade do sistema de controle suportar uma re-organização interna no caso de mau funcionamento de alguns recursos e de mudanças de demanda. A reconfigurabilidade do sistema de controle está relacionada a habilidade de suportar diferentes configurações do sistema, pela adição ou remoção de equipamentos, ou seja, diferentes configurações com um custo mínimo de esforço. Uma medida de robustez pode ser a forma como o sistema de controle reage a possíveis entradas errôneas ou fatores ambientais que afetam o sistema. O ideal seria testar todos os possíveis erros, mas na realidade não é possível testar todos os erros que podem ocorrer no sistema. Assim, o procedimento para medir a robustez compreende a simulação de cenários com a introdução de possíveis falhas e a análise como deve ser a reação do sistema de controle e da perda de produtividade. Neste estudo experimental, alguns indicadores quantitativos podem ser representados e comparados com diferentes arquiteturas de controle, como por exemplo, o lead time (i.e., o tempo total requerido para entrega de um produto), o delay time (i.e., a diferença entre a data de conclusão e a data de vencimento de pedido), o throughput (i.e., a razão entre o número de peças produzidas e o tempo necessário para executar um ciclo de produção) e a utilização de recursos (i.e., a média da percentagem de utilização dos recursos do sistema). Na Fig. 6 tem-se um exemplo de como deve ser implementado este experimento.

9 - P (a) Estrutura física de um sistema de manufatura (b) diagrama UML e modelos de interação entre holons (c) PFS e modelos em E-PN de plano do PrH-A (d) Exemplo da modelagem do tratamento de falha e sua reconfiguração. Figura 5. Sistema flexível de manufatura e exemplo de alguns modelos. 8. REFERÊNCIAS Arakaki, J., Miyagi, P.E., 2006, Degeneration methods in intelligent building control system design. IFIP, Boston, vol. 220, pp Booch, G., Rumbauch, J., Jacobson, I., 1999, The Unified Modeling Language User Guide. Addison Wesley Longman, Inc. Colombo, A.W., Neubert, R., Schoop, R., 2001, A solution to holonic control systems. Proc. of ETFA the 8th IEEE Int. Conf on Emerging Technologies and Factory Automation, Sophia/Nice. Concannon, K., Elder, M., Hunter, K., Tremble, J., Tse, S., 2004, Simulation Modeling with Simul8, Visual, 410p. David, R., Alla, H., 1994, Petri nets for modeling of dynamic systems - a survey. Automatica, vol.30, pp Hasegawa, K., Miyagi, P. E., Santos Filho, D. J., Takahashi, K., Ma, L. Q., Sugisawa, M., 1999, On resource arcs for Petri net modeling of complex shared resource systems. J. Int. & Robotic Systems, vol.26, n.3/4, pp Leitão, P., Colombo, A.W., 2006, Petri net based methodology for the development of collaborative production systems, Proc. of ETFA the 11th IEEE International Conference on Emerging Technologies and Factory Automation, Prague, pp Miyagi, P.E., Riascos, L.A.M., 2006, Modeling and analysis of fault-tolerant systems for machining operations based on Petri nets. Control Engineering Practice, vol.14, n.4, pp Reisig, W., 1985, Petri Nets an Introduction. Springer Verlag, New York.

10 PrH StH Su H Op H FPS PrH StH SuH Op H 6 º C ON G R E S S O BR A S I L E I R O D E E N G E N H A R I A D E F AB R I C A Ç Ã O 1 1 a 1 5 d e A b r i l d e Ca x i a s d o S u l - R S Bout_WS2 Tr2 WS2 Bin_WS2 Tr1 FPS StH StH StH Carregar A em WS1 Efetua OP_WS1 PROGRAMAÇÃO GLOBAL Bin_WS2 WS3 R Bout_WS1 WS1 SuH Transporte A para Bout_WS1 Bout_WS2 H U P L Bin_WS1 Tower PC To wer PC Ether net PrH PrH To wer PC Transporte Bout_WS1 para Bin_WS2 te Tower PC To wer PC H Carregar A em WS1 PROGRAMAÇÃO LOCAL te Figura 6. Exemplo de implementação de AHCS. Sampath, M., Sengupta, R., Lafortune, S., Sinnamhoideen, K. Teneketzis, D.C., 1996, Failure diagnosis using discreteevent models. IEEE Trans. on Control Systems Technology, vol. 4, n.2, pp Schoop, R., Colombo, A.W., Suessmann, B., Neubert, R., 2002, Industrial experiences, trends and future requirements on agent-based intelligent automation, Proc. of IECON the Annual Conf. of IEEE Industrial Electronics Society, vol.4, pp Scheidt, D.H., 2002, Intelligent agent-based control, Johns Hopkins Technical Digest, vol.23, n.4, pp Silva, R. M. ; Miyagi, P. E. ; Santos Filho, D. J., 2011, Design of active fault-tolerant control systems. In: Springer IFIP Advances in Information and Communication Technology, v p Sousa, P., Ramos, C., Neves, J., 2004, The fabricare system. Prod. Planning & Control, vol. 15, n. 2, pp Zhang, Y., Jiang, J., 2008, Bibliographical review on reconfigurable fault-tolerant control systems. Annual Reviews in Control, vol.32, pp DIREITOS AUTORAIS Os autores são os únicos responsáveis pelo conteúdo do material impresso incluído neste trabalho. DESIGN OF ACTIVE HOLONIC CONTROL SYSTEMS FOR PRODUCTIVE SYSTEMS Robson Marinho da Silva, rmsilva@uesc.br 1 Maruedson Pires Martins, maruedson01@yahoo.com.br 1 Fabricio Junqueira, fabri@usp.br 2 Diolino José dos Santos Filho, diolino.santos@poli.usp.br 2 Paulo Eigi Miyagi, pemiyagi@usp.br 2 1 Universidade Estadual de Santa Cruz, Ilhéus, BA 2 Escola Politécnica da Universidade de São Paulo, São Paulo, SP Abstract. The utilization of new technologies in productive systems (PSs) increases the potential for multiple and simultaneous execution of different processes exploring the intense sharing of resource However, new approaches are needed for designing of supervision and control that allow this behavior. Besides, totally infallible systems are unviable, and for a PS does not to suffer interruptions due to component failure, the concept of AFTCS (active faulttolerant control system) mechanism must be adopted. On the other hand, holonic control system (HCS) is considered a trend for an intelligent automation and the study of the combination of HCS techniques and AFTCS is fundamental to assure efficiency, flexibility and robustness of PSs. In this context, a procedure is presented to design active holonic control system (AHCS), for supervision and control of processes in PSs. AHCS considers AFTCS requirements and interpreted Petri net for the description of the systems behavior. An example of a flexible manufacturing system (FMS), considered as a representative class of PS, is presented for demonstrated the vantages of procedure proposed. Keywords: control system, fault-tolerance, Petri net, holon, reconfiguration. The authors are the only responsible for the printed material included in this paper.