Sistema de controle Holônico

1. SISTEMAS DE  CONTROLE HOLÔNICO (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). Assim, 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 (Productive Systems). Estes trabalhos foram consideradas para a especificação da arquitetura e também motivaram o procedimento de modelagem aqui proposto.

No entanto, esses estudos também confirmam que há ainda um pequeno número de trabalhos que consideram a integração dos requisitos de HCS e AFTCS (Active Fault Tolerant Control Systems), e poucas aplicações práticas das tecnologias de agente, mostrando 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.

Analisando os trabalhos acima mencionados, verifica-se que 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 baseadas 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).

Outro ponto é que não há nenhuma informação sobre o uso de uma abordagem sistemática, como o PFS (Production Flow Schema) (Hasegawa et al, 1999), 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.

 

2. ARQUITETURA DE CONTROLE DO ACTIVE HOLONIC CONTROL SYSTEMS (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 (Reisig, 1995) 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 – holon de produto (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 – holon de estratégias (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 – holon supervisor (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, OpH – holon operacional (Operational Holon). O OpH 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 OpH segue uma “agenda”, ou seja, a lista planejada de tarefas que o recurso tem de executar.

 

2.1.   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 OpHs seguem a coordenação do SuH, e o “modo transiente”, em que os OpHs assumem o controle (vide Fig.1a). Durante o “modo estacionário” os OpHs 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 OpHs. As holarquias são representadas por elipses e um holon pode pertencer simultaneamente a várias holarquias (Fig. 1b).

 

Figura 1. (a) Arquitetura de controle e (b) holarquias de AHCS.

 

2.1.1.    Negociação entre holons

 

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 OpHs 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 OpHs. Após esta interação o StH aceita transferir (pagar) uma recompensa ε ao OpH 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.

 

2.1.2.    Estimação do tempo de recuperação

 

Tabela 1. Mecanismo de negociação baseado em créditos e débitos entre holons.

 

 

 

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 OpH 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 atual destas ordens, notificando o StH. Para isto, o OpH 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 OpH 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 OpH 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 OpH 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.

 

2.1.3.    Fator de autonomia

 

A autonomia de cada OpH é neste caso associado a um “fator de autonomia”, i.e., uma variável discreta {baixo, alto}. Inicialmente, o OpH 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 OpH reduz novamente seu fator de autonomia e retorna a estrutura de controle hierárquica, entrando novamente no modo estacionário.

 

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

 

Figura 2. Estimação do tempo de reconfiguração e (b) fases de AFTCS no AHCS.

 

 

 

REFERÊNCIAS

 

Arakaki, J., Miyagi, P.E., 2006, “Degeneration methods in intelligent building control system design”. IFIP, Boston, vol. 220, pp.469—478.

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”. Proceedings 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, USA, 410p.

David, R., Alla, H., 1994, “Petri nets for modeling of dynamic systems – a survey”. Automatica, vol.30, n.2, pp.175—201.

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”. Journal Int. & Robotic Systems, vol.26, n.3/4, pp.423—437.

Leitão, P., Colombo, A.W., 2006, “Petri net based Methodology for the Development of Collaborative Production Systems”, Proceedings of the 11th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA’06), Prague, pp. 819-826.

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.397-408.

Reisig, W., 1985, “Petri Nets an Introduction”. Springer Verlag, New York.

Sampath, M., Sengupta, R., Lafortune, S., Sinnamhoideen, K. Teneketzis, D.C., 1996, “Failure diagnosis using discrete-event models”. IEEE Trans. on Control Systems Technology, vol. 4, n.2, pp.105—124.

Schoop, R., Colombo, A.W., Suessmann, B., Neubert, R., 2002, “Industrial experiences, trends and future requirements on agent-based intelligent automation”, Proceedings of IECON the Annual Conference of IEEE Industrial Electronics Society, Vol.4, pp. 2978–2983.

Scheidt, D.H., 2002, “Intelligent Agent-Based Control”, Johns Hopkins Technical Digest, vol.23, n.4, pp.383—395.

Silva, R. M. ; Miyagi, P. E. ; Santos Filho, D. J.  “Design of Active Fault-Tolerant Control Systems”. In: Proceedings of DOCEIS 2011 2nd Doctoral Conference on Computing, Electrical and Industrial Systems, Springer IFIP Advances in Information and Communication Technology, v. 349. p. 367-374, 2011.

Sousa, P., Ramos, C., Neves, J., 2004, “The Fabricare System”. Prod. Planning & Control, vol. 15, n. 2, pp.156—165.

Zhang, Y., Jiang, J., 2008, “Bibliographical review on reconfigurable fault-tolerant control systems.  Annual Reviews in Control”, vol.32, pp.229–252.

 

 

Artigos relacionados

Projeto de sistemas de controle