uma arquitetura baseada em agentes para conﬁguração ... · universidade federal do rio grande...

UNIVERSIDADE DO RIO GRANDE DO NORTEFEDERAL

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

CENTRO DE TECNOLOGIA

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA E

DE COMPUTAÇÃO

Uma Arquitetura Baseada em Agentes paraConfiguração Dinâmica de Aplicações

Inteligentes em Ambiente Foundation Fieldbus

Vinícius Ponte Machado

Orientador: Prof. Dr. Adrião Duarte Dória Neto

Co-orientador: Prof. Dr. Jorge Dantas de Melo

Tese de Doutorado apresentada ao Pro-grama de Pós-Graduação em EngenhariaElétrica e de Computação da UFRN comoparte dos requisitos para obtenção do títulode Doutor em Ciências.

Natal, RN, 11 de dezembro de 2009

Divisão de Serviços Técnicos

Catalogação da publicação na fonte. UFRN / Biblioteca Central Zila Mamede

Vinícius Ponte MachadoUma Arquitetura Baseada em Agentes para Configuração Dinâmica de Apli-

cações Inteligentes em Ambiente Foundation Fieldbus/ Vinícius Ponte Machado- Natal, RN, 2009

23 p.

Orientador: Adrião Duarte Dória NetoCo-orientador: Jorge Dantas de Melo

Tese (doutorado) - Universidade Federal do Rio Grande do Norte. Centrode Tecnologia. Programa de Pós-Graduação em Engenharia Elétrica e de Com-putação.

1. Redes Industriais. 2. Sistemas Multiagente. I. Machado, Vinícius Ponte

RN/UF/BCZM CDU 004.932(043.2)

Uma Arquitetura Baseada em Agentes paraConfiguração Dinâmica de Aplicações

Inteligentes em Ambiente Foundation Fieldbus

Vinícius Ponte Machado

Tese de Doutorado aprovada em 11 de dezembro de 2009 pela banca examinadora com-posta pelos seguintes membros:

Prof. Dr. Adrião Duarte Dória Neto (orientador) . . . . . . . . . . . . . . . . DCA/UFRN

Prof. Dr. Jorge Dantas de Melo (co-orientador) . . . . . . . . . . . . . . . . . DCA/UFRN

Prof. Dr. Dennis Brandão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EESC/USP

Prof. Dr. João José Vasco Peixoto Furtado . . . . . . . . . . . . . . . . . . . . . . . . UNIFOR

Prof. Dr. Luiz Affonso Henderson Guedes de Oliveira . . . . . . . . . . DCA/UFRN

"Sorte é estar preparado para aoportunidade quando ela aparece."

Benjamin Disraeli

Agradecimentos

A Deus pelo dom da vida e por ter me concedido saúde e paz de espírito para a realizaçãodesse trabalho.

À minha família. Meus pais, Excelsa e Machado por me proporcionarem educação eos alicerces morais para que pudesse viver com dignidade e respeito. A Karine, minhaesposa, pelo amor, paciência e apoio nos momentos difíceis de minha caminhada, desde agraduação até o doutorado e por me proporcionar uma nova família que está começandocom a chegada de nosso filho.

Ao meu orientador e ao meu co-orientador, professores Adrião e Jorge pela confiança,disponibilidade e acima de tudo parceria com que foi realizado nosso trabalho. Agradeçotambém pelo ambiente que me proporcionaram no qual pude trabalhar com tranquilidadenos experimentos. Pelo acolhimento, sou muito grato.

Aos professores Dennis Brandão pela receptividade na USP-São Carlos proporcionandoum ambiente acolhedor quando lá estive e pela parceria em nosso trabalho, Vasco Furtado,a quem devo uma boa parte da minha formação acadêmica, pelos ensinamentos que atéhoje tento seguir e Affonso Guedes, cujas conversas sempre agradáveis contribuíram sig-nificativamente para a condução desta pesquisa. Muito obrigado pela presença na bancade examinadores desta tese.

Aos meus colegas e amigos da UFPI, em especial aos que estiveram comigo aqui noprograma, André Macêdo, Érico Leão, Kelson Aires, Raimundo Moura e Ricardo Britto,pelos momentos que compartilharam comigo as incertezas e os êxitos que tivemos emNatal e principalmente obrigado pela amizade que firmamos e rearfirmamos aqui. Tenhocerteza nossa parceria renderá bons frutos em nosso ambiente de trabalho.

Aos meus colegas do Laboratório de Sistemas Inteligentes, Heliana, Lima, Adriano,Rafael, Danniel, Moiséis, Roque e João Paulo pelas trocas de conhecimento e dicas pre-ciosas na condução do meu trabalho. Agradeço também pela descontração e relaxamentonos momentos do cafezinho.

Aos meus colegas do LAMP, Bruno, Raimundo Viégas Jr., Carlos M. Viégas, Ivanovitch,Alexandre e Kennedy pelo clima agradável de trabalho. A Juliana pela parceria nos ar-tigos. A Daniel Martins, pela paciência, ajuda na planta fieldbus e ensinamentos sobresua operação. E a Leonardo Guanabara, cujo auxílio foi imprescindível ao longo destetrabalho me ajudando conduzir a pesquisa pela área de controle e automação, até entãodesconhecida para mim.

Aos professores e funcionários do DCA, em especial a Adelardo Medeiros, Pablo Alsina,Ana Maria Guerreiro e Giovanni Barbosa, que de uma forma ou de outra fizeram me sentiracolhido no departamento.

À CAPES e ao CNPq, pelo apoio financeiro.

Resumo

A automação industrial está diretamente ligada ao crescimento da tecnologia da in-formação. Tanto as melhorias em soluções de hardware quanto o aprimoramento emmetodologias de desenvolvimento de software propiciaram o crescimento do controle doprocesso produtivo ao longo dos anos. Nesta tese, propomos uma arquitetura que per-mitirá a união de duas tecnologias no âmbito de hardware (redes industriais) e software(sistemas multiagente). O objetivo de nossa proposta é unir essas tecnologias em umaarquitetura multiagente para permitir implementação de aplicações inteligentes nos dis-positivos de campo. Com isso pretendemos fazer que os agentes possam detectar e apon-tar soluções para problemas encontrados no ambiente de rede industrial. Este trabalhoainda alia a aprendizagem de máquina ao contexto industrial, permitindo dessa forma quea arquitetura de agentes proposta possa se tornar adaptável a um contexto de produçãodesconhecido ou inesperado. Para isso, utilizamos redes neurais e mostramos uma es-tratégia para alocação destas redes em dispositivos da rede industrial. Pretendemos assimviabilizar uma melhoria no suporte a decisão em ocorrências no nível de planta auxiliandoos operadores na detecção e correção de problemas e falhas.

Palavras-chave: Redes Industriais, Sistemas Multiagente, Redes Neurais, Aprendiza-gem de Máquina.

Abstract

The industrial automation is directly linked to the development of information tec-nology. Better hardware solutions, as well as improvements in software developmentmethodologies make possible the rapid growth of the productive process control. In thisthesis, we propose an architecture that will allow the joining of two technologies in hard-ware (industrial network) and software field (multiagent systems). The objective of thisproposal is to join those technologies in a multiagent architecture to allow control strate-gies implementations in to field devices. With this, we intend develop an agents architec-ture to detect and solve problems which may occur in the industrial network environment.Our work ally machine learning with industrial context, become proposed multiagent ar-chitecture adaptable to unfamiliar or unexpected production environment. We used neuralnetworks and presented an allocation strategies of these networks in industrial networkfield devices. With this we intend to improve decision support at plant level and allowoperations human intervention independent.

Keywords: Industrial Networks, Multi-Agents Systems, Neural Networks, MachineLearning.

Sumário

Sumário i

Lista de Figuras iii

Lista de Tabelas v

1 Introdução 11.1 Hipóteses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Estrutura da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Fundamentação Teórica 62.1 Sistemas MultiAgente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Aprendizagem de Máquina . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Redes Neurais . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Redes Industriais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Barramentos Industriais . . . . . . . . . . . . . . . . . . . . . . 132.3.2 Barramento Foundation FieldBus . . . . . . . . . . . . . . . . . 14

2.4 Sensores de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5 Sensores de Software em Redes Foundation FieldBus . . . . . . . . . . . 182.6 Agentes no Contexto Industrial . . . . . . . . . . . . . . . . . . . . . . . 24

2.6.1 Ambiente FieldBus (Barramento de Campo) . . . . . . . . . . . . 252.6.2 Sistema Multiagente em Redes Industriais . . . . . . . . . . . . . 26

2.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 Arquitetura Multiagente em Blocos Funcionais 343.1 Alocação Dinâmica de Blocos Funcionais . . . . . . . . . . . . . . . . . 343.2 Arquitetura dos agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.1 Agentes de Observação . . . . . . . . . . . . . . . . . . . . . . . 373.2.2 Agentes de Diagnóstico . . . . . . . . . . . . . . . . . . . . . . 383.2.3 Agentes de Execução . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3 Plataforma de Agentes em Ambientes Foundation Fieldbus . . . . . . . . 403.4 Aprendizagem dos Agentes . . . . . . . . . . . . . . . . . . . . . . . . . 413.5 Ação dos Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.6 Camada LABVIEW/FIPA . . . . . . . . . . . . . . . . . . . . . . . . . 443.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

i

4 Testes e Experiências 464.1 Estrutura de Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.1 Nível Supervisório . . . . . . . . . . . . . . . . . . . . . . . . . 474.1.2 Nível Fieldbus . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Treinamento dos Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3 Agentes de Observação . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.4 Agente de Diagnóstico . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.5 Agente de Execução - Teste 1: Perda de Sinal . . . . . . . . . . . . . . . 594.6 Agente de Execução - Teste 2: Ruído . . . . . . . . . . . . . . . . . . . . 604.7 Agente de Execução - Teste 3: Auto-Calibração . . . . . . . . . . . . . . 614.8 Agente de Execução - Teste 4: Controle de tensão . . . . . . . . . . . . . 644.9 Análise e Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5 Considerações Finais 685.1 Comprovação de Hipóteses . . . . . . . . . . . . . . . . . . . . . . . . . 685.2 Contribuições da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.3 Dificuldades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.4 Perspectivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Lista de Publicações 71

Referências bibliográficas 72

Lista de Figuras

2.1 Classificação des agentes baseados em Nwana (1996) . . . . . . . . . . . 82.2 Modelo de Neurônio Artificial baseado em Haykin (2001) . . . . . . . . 102.3 Barramento de Campo Industrial . . . . . . . . . . . . . . . . . . . . . . 132.4 Protocolo Foundation Fieldbus . . . . . . . . . . . . . . . . . . . . . . . 142.5 Topologia típica de uma rede fieldbus . . . . . . . . . . . . . . . . . . . 152.6 Esquema interno do bloco artimético padrão FF . . . . . . . . . . . . . . 192.7 Esquema interno do bloco caracterizador de sinais padrão FF . . . . . . . 202.8 Diagrama de blocos da implementação do algoritmo de filtragem para

medidas de sensores [Costa 2006] . . . . . . . . . . . . . . . . . . . . . 212.9 Esquema Geral do Sistema de Detecção e Isolamento de falhas [Fernan-

des 2007] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.10 Esquema Geral para Classificação das Falhas [Fernandes 2007] . . . . . . 222.11 Diagrama de Blocos do Treinamento da Auto-Correção [Cagni et al. 2005] 252.12 Sistema multiagente como parte de um sistema hierárquico de automação

[Wagner 2002] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.13 Ambiente de atuação de agente de Stefano & Santoro (2009) . . . . . . . 282.14 Ambiente de atuação de agente de [Frey 2008] . . . . . . . . . . . . . . . 292.15 Ambiente de atuação de agente de [T.Pirttioja et al. 2005] . . . . . . . . . 302.16 Ambiente de atuação de agente de [Macerauskas & Teresius 2004] . . . . 31

3.1 Exemplo de reconfiguração dos blocos funcionais [Ramalho 2009] . . . . 353.2 Exemplo de conexão de blocos funcionais artiméticos . . . . . . . . . . . 363.3 Rede Neural 1-3-1 generalizando a função seno . . . . . . . . . . . . . . 363.4 Rede Neural 1-3-2-1 simulando a função exponencial . . . . . . . . . . . 363.5 Mudanças de arquitetura de redes neurais . . . . . . . . . . . . . . . . . 373.6 Sistema simples de controle baseados baseado em blocos funcionais . . . 393.7 Filtro de Ruídos baseado em blocos funcionais . . . . . . . . . . . . . . 393.8 Ambiente multiagente proposto . . . . . . . . . . . . . . . . . . . . . . . 413.9 Anatomia dos agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.10 Execução dos Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.11 Esquema de implementação de agentes em LABVIEW . . . . . . . . . . 44

4.1 Esquema da planta utilizada nos experimentos . . . . . . . . . . . . . . . 474.2 Planta utilizada nos experimentos . . . . . . . . . . . . . . . . . . . . . 484.3 Tela do Sistema de Monitoramento . . . . . . . . . . . . . . . . . . . . . 494.4 Tela de Depuração (Debug) . . . . . . . . . . . . . . . . . . . . . . . . . 50

iii

4.5 Rede Neural em blocos funcionais representada graficamente no Syscon- Agentes de Observação . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.6 Rede Neural em blocos funcionais representada graficamente no Syscon- Agentes de Observação . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.7 Rede Neural em blocos funcionais representada graficamente no Syscon- Agente de Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.8 Tela de treinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.9 Parte do arquivo de treinamento dos agentes de observação . . . . . . . . 534.10 Parte do arquivo de treinamento dos agentes de execução . . . . . . . . . 544.11 Tela de treinamento de redes neurais do aNETka . . . . . . . . . . . . . 554.12 Parte do arquivo de treinamento dos agentes de diagnóstico . . . . . . . . 554.13 Parte do arquivo de treinamento do agente de diagnóstico . . . . . . . . . 574.14 Exemplo de arquivo de configuração da rede neural para o agente de ob-

servação (tanque 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.15 Código de execução em linguagem G do agente de diagnóstico . . . . . . 584.16 Parte da tela de monitoramento que mostra os agentes de observação e

diagnóstico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.17 Configuração de blocos funcionais alocados para o agente de execução -

Inferência do nível do tanque 1 . . . . . . . . . . . . . . . . . . . . . . . 604.18 Configuração de blocos funcionais alocados para o agente de execução -

Filtro de ruído . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.19 Gráfico com de sinais normal, com ruído e filtrado . . . . . . . . . . . . . 624.20 Configuração de blocos funcionais alocados para o agente de execução -

Filtro de ruído . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.21 Gráfico de auto-compensação . . . . . . . . . . . . . . . . . . . . . . . . 634.22 Gráfico de comparação do tempo de resposta dos agentes de execução . . 66

Lista de Tabelas

2.1 Principais Blocos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . 162.2 Situações de falhas com base nos resíduos . . . . . . . . . . . . . . . . . 232.3 Tabela comparativa de trabalhos de agentes em ambientes industriais . . . 33

4.1 8 possíveis falhas e seus respectivos resíduos . . . . . . . . . . . . . . . 56

v

Capítulo 1

Introdução

Com o aumento da competitividade das organizações, a velocidade no meio de pro-dução tem se tornado um fator decisivo para o sucesso de uma corporação. O processoprodutivo, alavancado por essa competitividade e aliado à crescente exigência de qual-idade fez com que as organizações começassem a perceber a importância de se manterum controle, não só da confecção do produto em si (ou prestação do serviço) mas de to-dos os processos que o cercam: fornecimento de matéria-prima, controle de qualidade edistribuição do produto. O advento da Tecnologia da Informação (TI), fez com que os sis-temas computacionais surgissem como uma solução para não só agilizar, como tambémcontrolar as mais diversas atividades do processo produtivo. O aumento de tecnologia em-barcada no processo de manufatura dos produtos faz com que cada vez mais a produçãoseja automatizada e dependa o mínimo possível de intervenção humana.

Com passar do tempo, foram sendo desenvolvidos sistemas mais complexos para am-bientes industriais, com tecnologias próprias, protocolos, softwares e hardwares maisapropriados para as necessidades de um processo produtivo. Principalmente no que serefere à comunicação entre os diversos dispositivos espalhados pelo campo (área) de pro-dução. Para viabilizar e controlar essa comunicação foram desenvolvidas diversas tec-nologias de Redes Industriais.

Redes industriais são essencialmente sistemas distribuídos, ou seja, diversos elemen-tos (sensores e atuadores, por exemplo) trabalham de forma simultânea a fim de supervi-sionar e controlar um determinado processo. Tais elementos, quando interligados, devemtrocar informações de forma rápida e precisa. Um ambiente industrial é geralmente hostil(sujeito a ruídos, interferências, altas temperaturas, etc.), de maneira que os dispositivose equipamentos pertencentes a uma rede industrial devem ser também confiáveis e ro-bustos (tolerantes a falhas). As Redes Industriais surgiram da necessidade de reduçãode cabeamento, flexibilidade de implementação das aplicações, baixa tolerância a ruídos,etc.

Nesse contexto, introduzimos o paradigma de agentes de software [Wooldridge 2002]como opção para automatizar tarefas repetitivas e que requerem um certo nível de au-tonomia e robustez. A função de um agente é interagir com o ambiente, devendo tercapacidade de reunir informações (perceber) do meio onde está inserido, tomar decisõesbaseadas nestas informações e iniciar uma ação específica conforme o que percebeu[Russell & Norvig 2003].

CAPÍTULO 1. INTRODUÇÃO 2

Outra área de pesquisa que iremos inserir no contexto de redes industriais é Apren-dizagem de Máquina, que são softwares que, em termos de implementação, melhoramseu desempenho por meio de experiência. Em nosso contexto, entidades de softwareexternos ou internos ao ambiente industrial podem, por exemplo, aprender sobre o fun-cionamento da planta1. Ou seja, situações que necessitem de avaliação ou intervençãohumanas podem ser "aprendidas"por essas entidades, de forma a automatizar algumasdessas situações evitando a intervenção de supervisores e/ou operadores humanos, dandomais agilidade ao processo produtivo.

Segundo Bass et al. (2003) a arquitetura de um sistema computacional é a estruturaa qual engloba os elementos de software, as propriedades desses elementos e as relaçõesentre eles. Ao se definir uma arquitetura expomos as propriedades do sistema e fornece-mos uma representação, um guia de entendimento intelectual da estrutura como um todo,permitindo aos projetistas raciocinar sobre a possibilidade do sistema satisfazer a deter-minadas exigências.

Baseado nesta concepção, neste trabalho propomos uma arquitetura que reúne as tec-nologias anteriormente mencionadas (agentes e aprendizagem de máquina) aplicadas aredes industriais, tendo como enfoque principal proporcionar às arquiteturas de redes ex-istentes suporte aos usuários em certas atividades do processo de produção.

Para controlar tais atividades, muitas aplicações têm sido desenvolvidas alocando econectando blocos funcionais (unidades de processamento existentes nos dispositivos darede). Em alguns casos estas aplicações estimam, em tempo real, variáveis de interessenão medidas a partir de outras variáveis disponíveis(medidas indiretas). Esta abordagem échamada Software Sensor ou sensores virtuais [James et al. 2000]. Atualmente a alocaçãoou configuração de Software Sensor é feita pelo operador da planta industrial utilizandoum sistema supervisório.

No âmbito de redes industriais, principalmente nas redes Foundation Fieldbus [Foundation2001] que usaremos neste trabalho, a alocação de blocos funcionais para instanciar apli-cações (software sensor) requer, além da parada do funcionamento de toda a rede indus-trial, a intervenção dos usuários/supervisores da rede. A alternativa para reconfiguraçãodinâmica das aplicações distribuídas nos instrumentos da rede industrial é integrada aocontrole da planta na tentativa de dar maior adaptabilidade no processo de detecção ecorreção de falhas. A reconfiguração de blocos funcionais em tempo de execução, tornaviável a implementação de sensores de software autônomos agregados a uma rede in-dustrial, os quais serão acionados sem intervenção do usuário. A reconfiguração on linepermite a alocação da arquitetura aqui proposta nos blocos funcionais dos dispositivos decontrole da planta.

Com a reunião das tecnologias anteriormente descritas (Sistemas Multiagente, Apren-dizagem de Máquina e Redes Industriais), propomos soluções à algumas lacunas exis-tentes nos Sistemas de Automação e Redes Industriais, tais como:

• A implementação de aplicações nos dispositivos de campo é realizada através daintervenção do usuário, requerendo na maioria dos casos a parada do funcionamentoda planta.

1Unidade industrial ou setor dentro de uma indústria, que produza algo específico


• Situações de falha são notificadas aos supervisores da rede através de alarmes geral-mente depois que acontecem, havendo poucos mecanismos que possam antever ouevitar tais situações.• As configurações de controle geralmente implementadas nas redes industriais não

possuem um comportamento dinâmico ou processamento mais complexos (inteligente).

Acreditamos que a inclusão de agentes na rede industrial, aliado à implementação dealgoritmos de aprendizagem de máquina, possa preencher essas lacunas e, além disso,auxiliar os usuários e supervisores da rede, agregando um mecanismo de configuraçãodinâmica dos dispositivos, controle inteligente, detecção e correção de falhas.

1.1 HipótesesNo contexto de redes industriais, observamos algumas questões que merecem atenção

pois quando não respeitadas podem gerar situações que comprometem o correto funciona-mento do processo monitorado ou controlado por uma rede industrial.

Atividades controladas pelas redes industriais requerem funcionamento contínuo etolerante a falha, pois qualquer parada na planta pode acarretar uma parada na produção,consequentemente perdas financeiras ou acidentes. Quando ocorre alguma falha, em al-guns casos, a intervenção do usuário (supervisor) é requerida para que esta falha sejacorrigida. Além disso, em situações específicas, a mudança na configuração dos disposi-tivos da rede que envolve alocação e configuração de novos blocos funcionais, a parada dosistema é, na maioria dos casos, obrigatória e não existe nenhuma plataforma fornecidapelos fabricantes que permita a integração automática de diferentes software sensors emum ambiente de rede industrial, bem como a implementação on line de novas funçõesbaseadas no processamento inteligente da informação.

Baseado nestas hipóteses, o problema a ser resolvido é como detectar e reparar falhasque ocorram na planta mudando as aplicações implementadas nos dispositivos de campode forma dinâmica (on line). No contexto desse problema podemos perceber três fatoresque podem definir a sua solução: (1) autonomia, (2) aprendizagem e (3) adaptação.

Um sistema autônomo (1) tem independência para intervir no processo quando necessário.Essa autonomia só lhe é conferida se esse sistema for capaz de resolver problemas, mesmopara os quais ele não tenha sido previamente programado. Isso só é possível se ele puderaprender (2) sobre o funcionamento do processo, fazendo com que o sistema seja capazde se (3) adaptar a um contexto de funcionamento novo ou inesperado. Essas três car-acterísticas conferem com o conceito de agentes de software, o quê faz com que seu usoseja muito apropriado ao problema em questão.

Portanto, a hipótese central que defenderemos nesta tese é:

O uso de aprendizagem de máquina faz com que agentes aprendam o fun-cionamento da planta industrial Foundation Fieldbus e assim possam in-terferir autonomamente em algumas funcionalidades como por exemplodetecção e resolução de problemas (falhas).

A partir da hipótese central, temos ainda como hipóteses secundárias:


• O uso de agentes confere autonomia na resolução de problemas nas redes industri-ais.• O uso de aprendizagem de máquina ajuda os agentes descobrirem padrões de falha

e possíveis soluções.• A proposição de uma estratégia de alocação dinâmica permite que os agentes sejam

alocados nas redes industriais para descobrir e reparar as falhas.

1.2 ObjetivosDefinidas as hipóteses podemos traçar os objetivos deste trabalho. O principal deles

é criar uma arquitetura multiagente que permita incorporar nas redes industriais Founda-tion Fieldbus aplicações inteligentes baseadas nos blocos funcionais de dispositivos decampo. Esta arquitetura deve viabilizar a alocação de recursos (algoritmos) em sensores eatuadores que permitam realizar algumas tarefas para auxiliar os supervisores a detectar esolucionar alguns problemas na rede, tais como, filtragem de ruído, predição, calibração,etc. Com isso, pretende-se viabilizar uma melhoria no suporte a decisão em ocorrênciasno nível de planta e permitir um funcionamento ainda mais independente de intervençãohumana.

Além disso, com a reunião das tecnologias de Sistemas MultiAgente e Redes Indus-triais acreditamos alcançar os objetivos secundários, preenchendo algumas lacunas nocontexto de Sistemas de Automação. O primeiro deles é automatizar atividades dentrodo âmbito da planta. Diversas informações colhidas pelos sensores são passadas aos su-pervisores e ficam a espera de uma análise. Neste caso, os agentes processariam essasinformações de modo a poderem tomar decisões sobre o funcionamento do processo in-dustrial, permitindo que a arquitetura de agentes proposta possa se tornar adaptável a umcontexto de produção desconhecido ou inesperado.

Para alcançar este objetivo apresentaremos a especificação de uma arquitetura multi-agente, destacando seus componentes (agentes), suas tarefas e o ambiente que eles estãoinseridos (rede industrial padrão foundation fieldbus). Além disso, descreveremos a es-tratégia de alocação dinâmica de aplicações que permitirá a implementação dos agentesnos dispositivos de campo. Com o desenvolvimento desta arquitetura acreditamos con-tribuir cientificamente em três questões:

• Uma especificação de um sistema multiagente para a implementação de aplicaçõesem blocos funcionais - neste caso, têm-se a definição de tarefas de cada grupo deagentes, comunicação, avaliação de desempenho, limitações, bem como referênciasa futuras expansões da capacidade dos agentes e seus impactos na rede industrial.• Utilização de algoritmos de aprendizagem (mais especificamente Redes Neurais

Artificiais - RNA) para detecção e correção de falhas.• Proposição de uma estratégia para alocação dinâmica de blocos funcionais.


1.3 Estrutura da TeseJuntamente com esta introdução, a presente tese possui quatro partes, na forma de

capítulos. O segundo capítulo discorre sobre o estado da arte, trazendo os conceitos quepremeiam a proposta aqui apresentada, possibilitando uma visão geral sobre Agentes In-teligentes, Aprendizagem de Máquina e Redes Industriais, além de mostrar trabalhos quecorrelacionam essas áreas. Ainda no segundo capítulo, abordaremos as principais apli-cações de controle inteligentes em sensores de software, principalmente sobre a aplicaçãode agentes no âmbito industrial. Neste momento, mostramos trabalhos que nos remetemao uso de agente em sistemas de automação.

No capítulo três discutimos a arquitetura proposta, especificando os agentes, suasatividades, relacionamentos (iteração e comunicação) e ambiente. No capítulo quatro sãoapresentados exemplos de implementação. Mostramos como os agentes lidam com algunsproblemas encontrados em uma planta real. Ainda neste capítulo também apontaremosos resultados com relação ao desempenho da arquitetura proposta.

Encerraremos este trabalho com a conclusão, mostrando as contribuições científicase técnicas bem como as perspectivas futuras e verificaremos ainda se os objetivos dessatese foram alcançados, finalizando com a comprovação das hipóteses mostradas nessecapítulo.

Capítulo 2

Fundamentação Teórica

Neste capítulo iremos discorrer sobre os conceitos que permeiam nossa proposta, aomesmo tempo que mostraremos trabalhos correlatos em cada área abordada. Iniciaremosfalando sobre os sistemas multiagente (SMA), procurando nos posicionar entre os váriosconceitos sobre o tema e mostrando suas características e aplicações. Em seguida abor-daremos a aprendizagem de máquina, mais especificamente as redes neurais, que seráutilizada neste trabalho. Serão abordados ainda os principais tipos de redes industriaisenfatizando o Foundation FieldBus que será utilizado na arquitetura proposta.

Para finalizar, veremos trabalhos que enfatizam o uso de software (software sensors- sensores de software) e de agentes no ambiente industrial. Além disso, destacaremostrabalhos de SMA no ambiente fieldbus. Diante disso, pretendemos mostrar as aplicaçõese soluções apontadas na literatura para a implementação de SMA em redes industriais. Deacordo com esses conceitos acreditamos posicionar nosso trabalho dentro dessas tecnolo-gias aqui apresentadas facilitando assim o seu entendimento. Pretendemos ainda destacara importância de nosso estudo frente a outros realizados na comunidade científica.

2.1 Sistemas MultiAgenteDe uma forma geral, podemos entender o agente como uma entidade que percebe o

ambiente através de sensores e age neste ambiente através de atuadores, ou seja, é capaz deinteragir com o meio em que está inserido, tomando decisões que irão auxiliar a alcançarseu objetivo [Russell & Norvig 2003]. Assim, um agente é uma entidade computacionalcom um comportamento autônomo, que lhe permite decidir suas próprias ações.

Apesar de não haver consenso na literatura científica sobre conceito do termo, nestetrabalho consideramos o termo agente com base no que há de comum entre as definiçõesde diversos autores, mostradas a seguir. Autonomia, aprendizagem e adaptação são car-acterísticas presentes na maioria dos conceitos sobre agente:

• Um agente é um programa de computador que pode operar autonomamente e efet-uar tarefas singulares sem a direta supervisão humana [Hoffman & Novak 1996].• Para Macal & North (2006), um agente deve ter as seguintes características: (1) ser

identificável - uma entidade com um conjunto de características e regras que gov-ernam seu comportamento e tem capacidade de tomar decisões; (2) estar situado -

CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 7

habitar em um ambiente com o qual interage e também no qual interage com out-ros agentes; (3) ser autônomo; (4) ser flexível e possuir habilidade para aprendere adaptar seu comportamento através do tempo baseado em experiências (apren-dizado).• Agente autônomo é o que consegue decidir por si só como relacionar os dados

obtidos com ações, de modo que seus objetivos sejam atingidos com sucesso [Maes1995].• Para Bonabeau (2002), na modelagem baseada em agentes o sistema é visto como

uma coleção de entidades autônomas de tomadas de decisão. Esta modelagem con-siste de um grupo de agentes e as relações entre eles.

Tanto na definição apresentada no primeiro parágrafo desta seção, quanto nas rela-cionadas acima, há um consenso em três características: autonomia, explicitamentecitada; aprendizagem, onde o desempenho do agente melhora com a experiência (a cadaexecução) [Mitchell 1997]; e adaptação, pois ao interagir com um ambiente que mudaconforme sua ação e, em alguns casos também é influenciado por fatores externos, énecessário que o agente se adapte a essas mudanças, de forma a continuar sua execuçãoem direção ao seu objetivo.

Portanto, consideraremos neste trabalho, que agente é uma entidade de software quepossui autonomia, aprendizagem e adaptação, baseado nos conceitos anteriormente de-scritos.

Para Wooldridge (2002), existem duas noções gerais de agentes. A primeira, chamadade noção fraca, abrange a maior parte dos agentes. Ela inclui propriedades como au-tonomia, comunicação, reatividade, pró-atividade, etc. Já a noção forte de um agenteimplica na adição de propriedades ou é complementada por conceitos geralmente aplica-dos a ações humanas, tais como crença, intenção e obrigação. Assim, a habilidade paraperceber e aprender sobre um problema e resolvê-lo, substitui a ação e intervenção hu-mana. Como podemos ver na Figura 2.1, os agentes implementados em nossa arquiteturasão classificados como agentes inteligentes na divisão de Nwana (1996) e com a noçãofraca de agente de Wooldridge (2002).

Um conjunto de agentes que interagem entre si, dentro de um mesmo ambiente échamado de sistema multiagente (SMA). Os SMA formam uma sub-área da inteligênciaartificial distribuída. Para os SMA, o termo autônomo designa o fato de que os agentestêm uma existência própria, independente da existência de outros agentes. Usualmente,cada agente possui um conjunto de capacidades comportamentais que definem suas com-petências, um conjunto de objetivos e a autonomia necessária para utilizar suas capaci-dades a fim de alcançar seus objetivos [Weiss 1999].

Para tentar regulamentar o desenvolvimento e interoperabilidade dos sistema multi-agentes foi criada a FIPA (Foundation for Intelligent Physical Agents). Ela tem comoobjetivo a promoção de padrões de software (especificações) e de tecnologias que fa-cilitem comunidades de agentes heterogéneos e sistemas baseados em agentes a interagirentre si. A plataforma FIPA-OS (Open Source) possui quatro tipos de agentes básicossuportados: (1) reativo que reage a mensagens ACL provenientes de outros agentes noambiente; (2) proativo, onde o agente consegue decidir quando deve iniciar a interaçãocom outros agentes; (3) social que reúne as características dos agentes reativo e proativo;


Cooperação Aprendizado

Autonomia

AgentesAprendizes

AgentesInteligentes

AgentesColaborativos

Agentes deInterface

Figura 2.1: Classificação des agentes baseados em Nwana (1996)

e autônomo onde cada agente possui possui capacidade tomar as próprias decisões paraalcançar seus objetivos. Qualquer plataforma FIPA contém:

• Directory Facilitator (DF): Tipo de agentes que fornecem o serviço de "páginasamerelas"a outros agentes (localização de serviços);• Agent Management System (AMS): gere o ciclo de vida de um agente na plataforma,

enquanto providencia serviços de "páginas brancas"a outros agentes (localização deagentes, nomes e serviços de controle de acessos)• Message Transport Service (MTS): gerencia a comunicação entre os agentes;

Utilizamos sistemas multiagente como um paradigma de programação para projetare desenvolver sistemas de software complexos e distribuídos [Wooldridge et al. 2000],facilitando a criação de software interoperável. Em SMA as aplicações são projetadas edesenvolvidas como entidades autônomas (agentes) que podem atingir seus objetivos in-teragindo com outros agentes através de protocolos e linguagens de alto nível. Os agentessão considerados entidades com controle de persistência (por exemplo, threads de con-trole distinto, processos distintos em uma única máquina, ou processos separados emmáquinas diferentes).

A decisão sobre qual ação será tomada é determinada pelo agente, tendo em con-sideração as mudanças acontecidas no ambiente em que atua, bem como seus própriosobjetivos. A idéia principal em um sistema multiagente é que um comportamento globalinteligente pode ser alcançado a partir do comportamento individual dos agentes. Em umSMA, não é necessário que cada agente seja individualmente inteligente para alcançar umcomportamento global inteligente.


2.2 Aprendizagem de MáquinaA Aprendizagem de Máquina (AM) está relacionada com programas computacionais

que melhoram seu desempenho automaticamente através da experiência. Técnicas deAM podem ser divididas, de maneira geral, em aprendizado supervisionado, aprendizadonão supervisionado e aprendizagem por reforço. Se antes do processo de aprendizadoo indutor recebe um conjunto de exemplos, cada exemplo tendo sido formado por umconjunto de atributos de entrada e um conjunto de atributos de saída, então esse tipo deaprendizado pode ser classificado como aprendizado supervisionado.

O aprendizado não supervisionado é realizado quando, para cada exemplo, apenasos atributos de entrada estão disponíveis. Essas técnicas de aprendizado são utilizadasquando o objetivo for encontrar um conjunto de dados padrões ou tendências (aglomer-ados) que auxiliem o entendimento desses dados. Já a aprendizagem por reforço (rein-forcement learning) [Sutton & Barto 1998] consiste, basicamente, em fazer um agenteescolher suas ações se baseando apenas na interação com o ambiente. Diferentemente daaprendizagem supervisionada, na qual existe um professor que diz ao agente qual deveriater sido a ação correta para cada estado, na aprendizagem por reforço existe apenas umcrítico, que indica o caminho correto, mas não diz exatamente a resposta correta. Nestetrabalho utilizaremos redes neurais como mecanismo de aprendizagem (supervisionada)de máquina.

2.2.1 Redes NeuraisA busca por um modelo computacional que simule o funcionamento das células do

cérebro data dos anos 40, com o trabalho de McCulloch e Pitts (1943). O entusiasmopela pesquisa neste campo cresceu durante os anos 50 e 60. Nesse período, Rosenblatt(1958) propôs um método de aprendizagem para as redes neurais artificiais, denominadopercepton. Até 1969, muitos trabalhos foram realizados utilizando o percepton comomodelo. No final dos anos 60, Minsky e Pappert (1969) publicaram um trabalho no qualapresentam importantes limitações do perceptron.

Porém, somente durante os anos 80, o estudo de RNA aumentou devido aos avançosmetodológicos e tecnológicos, como também aumentaram os recursos computacionaisdisponíveis. O modelo de neurônio artificial da Figura 2.2 é uma simplificação do modeloapresentado por Haykin (2001).

Uma rede neural artificial é composta por várias unidades de processamento, cujo fun-cionamento é paralelo e, por vezes, distribuído. Essas unidades, geralmente são conec-tadas por canais de comunicação que estão associados a determinado peso, denominadopeso sináptico. As unidades fazem operações apenas sobre seus dados locais, que sãoentradas recebidas pelas suas conexões. O comportamento inteligente de uma rede reuralartificial advém das interações entre as unidades de processamento da rede.

O modelo da Figura 2.2 é composto por três elementos básicos:

• um conjunto de n conexões de entrada (x1, x2, ..., xn), caracterizadas por pesos (w1,w2, ..., wn);• um somador para acumular os sinais de entrada;


Figura 2.2: Modelo de Neurônio Artificial baseado em Haykin (2001)

• uma função de ativação que limita o intervalo permissível de amplitude do sinal desaída (y) a um valor fixo.

O modelo da Figura 2.2 inclui também um sinal de bias aplicado externamente, repre-sentado por bk. O bias bk tem o efeito de aumentar ou diminuir a entrada da função de ati-vação, dependendo se ele é negativo ou positivo, respectivamente. Em termos matemáti-cos, pode-se descrever um neurônio k escrevendo o seguinte par de equações:

uk =m

∑j=1

wk jxx j (2.1)

e

yk = ϕ(uk +bk) (2.2)

onde x1 , x2 , ..., xm são os sinais de entrada; wk1 ,wk2 , ...,wkm são os pesos sinápticosdo neurônio k; uk é a saída do combinador linear devido aos sinais de entrada; bk é o bias;ϕ(.) é a função de ativação; e yk é o sinal de saída do neurônio.

O comportamento das conexões entre os neurônios é simulado por meio de seus pesossinápticos. Os valores de tais pesos podem ser negativos ou positivos, dependendo dasconexões serem inibitórias ou excitatórias. O efeito de um sinal proveniente de um outroneurônio é determinado pela multiplicação do valor (intensidade) do sinal recebido pelopeso da conexão correspondente (xi .. pi). É efetuada a soma dos valores xi .. pi de todasas conexões, e o valor resultante é enviado para a função de ativação, que define a saída(y) do neurônio. Combinando diversos neurônios, forma-se uma rede neural artificial. Deuma forma simplificada, uma rede neural artificial pode ser vista como um grafo onde osnós são os neurônios e as ligações fazem a função das sinapses.

As redes neurais artificiais se diferenciam pela sua arquitetura e pela forma como ospesos associados às conexões são ajustados durante o processo de aprendizado (treina-mento da RNA). Isso é realizado através do cálculo do erro que pode ser calculado como


a diferença entre a saída real gerada pela rede e a saída desejada, fornecida em um ensinosupervisionado.

Por exemplo: ek = dk − yk Onde para um estímulo k, e - sinal de erro; d - saídadesejada apresentada durante o treinamento; y - saída real da rede após a apresentação doestímulo de entrada. Durante o aprendizado supervisionado, portanto, os erros vão sendocalculados sucessivamente, até que cheguem a um valor satisfatório, definido a priori.Sendo assim, surge uma curva de erros, a qual está diretamente relacionada à natureza domodelo de neurônio utilizado.

A arquitetura de uma rede neural restringe o tipo de problema no qual a rede poderáser utilizada, e é definida pelo número de camadas (camada única ou múltiplas camadas),pelo número de nós em cada camada, pelo tipo de conexão entre os nós (feedforwardou feedback) e por sua topologia. Uma das propriedades mais importantes de uma redeneural artificial é a capacidade de aprender por intermédio de exemplos e fazer inferênciassobre o que aprendeu, melhorando gradativamente o seu desempenho. As redes neuraisutilizam um algoritmo de aprendizagem cuja tarefa é ajustar os pesos de suas conexões.

Propriedades das Redes Neurais

Dentre as diversas propriedade das redes neurais, podemos destacar a sua estruturaparalela e distribuída, sua habilidade de aprender e conseqüentemente de generalizar. Ageneralização refere-se ao fato de uma rede neural produzir saídas adequadas para en-tradas que não fizeram parte do conjunto de treinamento (aprendizagem). Essas duas pro-priedades de processamento de informação tornam possível para as redes neurais trataremproblemas complexos (de grande escala), quando comparadas com abordagens tradi-cionais. Outras propriedades das redes neurais são enumeradas a seguir [Haykin 2001]:

• Não-linearidade - uma rede neural formada por neurônios com funções de ativaçãonão-lineares permite efetuar relacionamentos não-lineares entre entradas e saídas.• Mapeamento de entrada-saída - a aprendizagem supervisionada, ou aprendizagem

com um "professor", envolve a modificação dos pesos sinápticos de uma rede neuralpela aplicação de um conjunto de amostras de treinamento ou exemplos da tarefa.Cada exemplo consiste em um sinal de entrada único e de uma resposta desejadacorrespondente. Apresenta-se para a rede um exemplo escolhido ao acaso do con-junto, e os pesos sinápticos da rede são modificados para minimizar a diferençaentre a resposta desejada e a resposta real da rede, produzida pelo sinal de en-trada, de acordo com um critério estatístico apropriado. O treinamento da rede érepetido por muitos exemplos do conjunto até que a rede alcance um estado estável,onde não haja mais modificações significativas nos pesos sinápticos. Os exemplosde treinamento previamente utilizados podem ser reaplicados durante a sessão detreinamento, mas em uma ordem diferente. Assim, a rede aprende com os exemplosao construir um mapeamento entrada-saída para o problema considerado.• Adaptabilidade - as redes neurais têm uma capacidade de adaptar seus pesos sinápti-

cos a modificações do ambiente. Em particular, uma rede neural treinada para atuarem um ambiente específico pode ser facilmente retreinada para lidar com peque-nas modificações nas condições operativas do ambiente. Além disso, quando está


operando em um ambiente não estacionário, uma rede neural pode ser projetadapara modificar seus pesos sinápticos em tempo real.• Resposta a evidências - no contexto da classificação de padrões, uma rede neural

pode ser projetada para fornecer informação não somente sobre qual padrão partic-ular selecionar, mas também sobre a confiança ou crença na decisão tomada. Estainformação pode ser utilizada para rejeitar padrões ambíguos, caso eles estejampresentes, e com isso melhorar o desempenho de classificação da rede.• Tolerância a falhas - uma rede neural, implementada na forma física (em hardware)

é inerentemente tolerante a falhas ou capaz de realizar computação robusta, no sen-tido de que seu desempenho se degrada suavemente sob condições de operaçãoadversas. Se um neurônio ou suas conexões são danificados, por exemplo, a recu-peração de um padrão armazenado é prejudicada em qualidade. Contudo, devidoa natureza distribuída da informação armazenada na rede, o dano deve ser extensopara que a resposta global da rede seja degradada seriamente. O que deve ser ob-servado nessas condições, é uma degradação suave do desempenho em vez de umafalha comprometedora.

2.3 Redes IndustriaisA automação é o conjunto de sistemas baseados em máquinas e programas com obje-

tivo de executar tarefas previamente programadas para controlar sequências de operaçõessem a intervenção humana [Moraes & Castrucci 2001]. Através da programação do sis-tema, o usuário consegue monitorar com precisão um processo produtivo, controlandoassim diversas variáveis (temperatura, pressão, nível ou vazão), gerenciando a distânciatoda a cadeia produtiva.

Arquiteturas distribuídas de automação industrial são caracterizadas por redes de dis-positivos, usualmente conectadas através de um sistema de comunicação em barramentochamado de barramento de campo (FieldBus) [Wild 2000]. Ele é o meio físico que per-mite a comunicação dos dispositivos com os sistemas supervisórios1 da planta industrial.

A comunicação digital trouxe uma série de ganhos ao controle e supervisão de proces-sos industriais, tornando inteligente os sensores e atuadores, uma vez que hoje são con-struídos como sistemas microprocessados capazes de executar processamento local. Ossistemas de barramentos industriais promovem alto nível de integração em uma planta,abrangendo desde o nível do chão-de-fábrica2, passando pelo nível de supervisão até onível de análise e otimização.

Redução dos custos de cabeamento, aumento na qualidade e na quantidade de infor-mação oriunda da planta, flexibilidade de reconfiguração e possibilidade de estratégiasde controle mais complexas, estão entre algumas vantagens proporcionadas pela tecnolo-

1Sistemas Supervisórios são programas (softwares) utilizados para a supervisão de processos industriaiscontínuos que permitem que sejam monitoradas e rastreadas informações do processo produtivo [Silva &Salvador 2004]

2Chão-de-fábrica é uma nomenclatura usada para designar o nível mais baixo da cadeia de produção. Éo local onde estão os dispositivos (sensores e atuadores) que lidam diretamente com a manufatura de umproduto e manipulação da matéria prima para produto acabado [Fortulan & Filho 2005]


gia de barramento de campo. Os benefícios tecnológicos e funcionais obtidos através dautilização de barramentos de campo fazem desta solução o atual estado da arte em instru-mentação e controle de plantas industriais. Fieldbuses se inserem em um contexto queprivilegia a distribuição do processamento como opção de arquitetura.

A introdução da instrumentação digital permitiu melhorias em termos de condiciona-mento de sinais, transmissão de grandezas, facilidade e flexibilidade de instalação e con-figuração. Ao mesmo tempo, a utilização de controle digital para processos trouxe ummaior poder de controle e acesso à informação sobre a planta.

A disponibilidade dentro do instrumento de capacidade computacional significativae a existência de uma gama de informações produzidas pelo instrumento digital, alémda simples grandeza medida, levaram avanços à pesquisa sobre barramentos de campo[Berge 2001].

2.3.1 Barramentos IndustriaisA conexão usando barramento (Figura 2.3) traz uma série de vantagens, especialmente

quando comparamos com o esquema tradicional, no qual para cada ponto de medição énecessário uma conexão independente. Dentre elas podemos citar:

• flexibilidade para estender a rede e adicionar módulos na mesma linha;• permite atingir maiores distâncias do que com conexões tradicionais;• redução substancial de cabeamento;• simplificação da instalação e operação e• possibilidade de conectar dispositivos de diferentes fornecedores.

Barramento Industrial

Monitoração e Controle

TCP-IP

Sensor

Atuador Atuador

Sensor

CLP

Figura 2.3: Barramento de Campo Industrial

Entre os protocolos existentes para comunicação industrial, temos por exemplo, oFoundation Fieldbus [Wild 1999], Profibus [Popp 1997], e o protocolo CAN [Daviset al. 2007]. A utilização de objetos (dispositivos) distribuídos, trabalhando em con-junto trás algumas peculiaridades relacionadas com o modelo de controle anteriormenteutilizado. O barramento Fundation Fieldbus, por exemplo, permite o uso de modeloscliente/servidor e publisher/subscriber, e ainda utiliza-se do conceito de blocos funcionais


Nível Físico

Pilha

de

Comunicação

Enlace

Aplicação

Modelo OSI

Subnível deAcesso (FAS)

Especificação deMensagens (FMS)

Apresentação

Sessão

Transporte

Rede

1

2

3

4

5

6

7

Enlace

Nível Físico Nível Físico

Aplicaçãodo

Usuário

BlocoFuncional

Descritorde

Dispositivo

FOUNDATION FieldBus FOUNDATION FieldBus

Figura 2.4: Protocolo Foundation Fieldbus

padronizados. Em relação ao Profibus, tem-se que a utilização de mestres e escravos comcomunicação ponto a ponto restringe o uso de objetos distribuídos, já que a autonomiados mesmos é uma das características que se deseja preservar. Diferente da comunicaçãoponto a ponto geralmente utilizada pelos outros barramentos, o barramento CAN possuia característica de broadcast que pode ser convenientemente explorada pelos sistemas deautomação industrial. A seguir, detalharemos o protocolo foundation fieldbus utilizadoem nossa proposta

2.3.2 Barramento Foundation FieldBusFoundation Fieldbus (FF) é um sistema de comunicação digital bidirecional que per-

mite a interligação direta de múltiplos instrumentos no campo, realizando funções decontrole e monitoração de processo e estações de operação através de softwares super-visórios.

O protocolo Foundation Fieldbus foi desenvolvido baseado no padrão ISO/OSI. Em-bora não contenha todos os seus níveis, podemos em primeira análise dividi-lo em nívelfísico ("Physical Layer- que trata das técnicas de interligação dos instrumentos), níveisde software ("Communication Stack") que tratam da comunicação digital entre os equipa-mentos (Figura 2.4) e a camada do usuário (User Layer) onde estarão as aplicações de-senvolvidas para controle de processos [Zeilmann 2002].

O Foundation Fieldbus surgiu com o objetivo de interligar e operar os instrumentos decampo com características diferentes e de diversos fabricantes. Cada dispositivo possuiuma certa capacidade de processamento de informações o que permite a descentralizaçãode suas tarefas. A rede baseada em FF possui características peculiares a redes industriais:imunidade a ruídos, pré-processamento de dados específicos, transmissão de informaçõesadicionais dos dados capacitando o diagnóstico do dispositivo.


Como os dispositivos podem ser de diferentes fabricantes, a padronização das funçõesa serem distribuídas nos mesmos foi necessária. Estas funções são chamadas de BlocosFuncionais (BF - Function Blocks). A interligação dos blocos funcionais é que definea estratégia de controle e programação do processo. Na configuração (pelo sistema decontrole) especifica-se a escolha do BF e em que dispositivo será executado.

Para realizar a comunicação o FF usa dois sistemas de barramento (Figura 2.5), olento, intrisicamente seguro, H1, e o rápido, H2, barramento de alto nível com velocidadede 1 a 2,5 MBit/s. Este último já foi abandonado pela indústria. De qualquer forma, oFoundation Fieldbus utiliza o High Speed Ethernet (HSE) como protocolo do barramentomais rápido.

Sendo um padrão, o Foundation Fieldbus (FF) permite que dispositivos de diferentesfabricantes possam ser integrados em um único sistema (interoperabilidade). Isto é pos-sível apenas quando todos os dispositivos seguem exatamente a especificação FF. Os dis-positivos são independentes do hardware de configuração, devido aos descritores de dis-positivos (DD - Device Descriptions), que permite que qualquer sistema de controle oucomputador possa operar com o dispositivo se conhecer o seu DD.

Com a interoperabilidade, um dispositivo FF pode ser substituído por um dispositivosimilar de um outro fornecedor com maior funcionalidade na mesma rede FF, mantendoas características originais. Isto permite aos usuários mesclarem dispositivos de campo esistemas de vários fornecedores.

Estações de Trabalho

Dispositivos de CampoBlocos Funcionais

Fieldbus Ethernet

DFI

Dispositivos de Acoplamento

Rede H1 FieldBus

HSE

Figura 2.5: Topologia típica de uma rede fieldbus

O Foundation Fieldbus associa todas as funções e dados dos dispositivos a tipos difer-entes de blocos, cuja relação depende do tipo do dispositivo. O bloco de recurso descrevecaracterísticas de um dispositivo, como o nome, o fabricante, o número serial, as versõesdo hardware e firmware, etc. Já os blocos funcionais (BF) são objetos implementados porestruturas de software que realizam as funções comuns ao ambiente de controle de pro-


cesso. São padronizados blocos funcionais FF tanto para funções simples, como entradae saída, quanto para algumas funções de maior complexidade, como controladores.

De posse desses recursos, torna-se possível construir aplicações de controle já que oscomponentes básicos, representados pelos BF, já estão instalados nos equipamentos decampo, bastando apenas, que sejam instanciados e conectados adequadamente através desuas interfaces padronizadas. A especificação FF define conjuntos de blocos funcionaispadrão que podem ser usados para descrever as funcionalidades básicas. Eles estão lista-dos na Tabela 2.1.

Tabela 2.1: Principais Blocos FuncionaisSigla Descrição do Bloco

AI Analog Input (entrada analógica)AO Analog Output (saída analógica)B Bias (bias)

CS Control Selector (seletor de controle)DI Discrete Input (entrada discreta)DO Discrete Output (saída discreta)ML Manual Loader (carregador manual)PD Proportional/Derivative (proporcional/derivativo)PID Proportional/Integral/Derivative (proporcional/integral/derivativo)RA Ratio (taxa)

Componentes Foundation FieldBus

Cliente OPCO padrão OPC (OLE3 for Process Control) estabelece as regras para que sejam de-

senvolvidos sistemas com interfaces padrão para comunicação dos dispositivos de campo(CLPs (Controlador Lógico Programável), sensores, atuadores, etc.) com sistemas demonitoração, supervisão e gerenciamento. Estas especificações tem a finalidade de orien-tar os desenvolvedores para a implementação das aplicações cliente e servidor. A rigor, osusuários finais não precisam conhecer as especificações, sendo suficiente conhecer os as-pectos práticos para utilização do padrão. A publicação das especificações para o padrãoOPC possibilitou o desenvolvimento de diversos produtos para automação industrial, osquais se beneficiam das vantagens proporcionadas pelo padrão, tais como padronizaçãodas interfaces de comunicação entre os servidores e clientes de dados de tempo real,facilitando a integração e manutenção dos sistemas [Tan et al. 2006]. Além disso, ex-iste a eliminação da necessidade de drivers de comunicação específicos (proprietários)e conseqüentemente, uma melhoria do desempenho e otimização da comunicação entredispositivos de automação.

3OLE - Tecnologia desenvolvida pela Microsoft para suprir a necessidade de se integrar diferentes apli-cações dentro da plataforma Windows


O padrão OPC é nativo da plataforma Windows c©. Para plataformas não-Windows,existem algumas soluções que consistem em portar o DCOM4 para estas plataformas.No futuro, a especificação OPC para XML deverá facilitar a integração de plataformasnão-Windows para a comunicação OPC [Schwarz & Boercsoek 2007].

As aplicações e produtos baseados no OPC existentes no mercado podem ser somenteum cliente, um servidor ou ambos. Normalmente, os produtos para monitoração de dados(sistemas supervisórios) são clientes OPC. Já os produtos que fazem a comunicação diretacom os dispositivos de campo utilizando protocolos proprietários são servidores OPC.Cada produto pode incorporar as duas funcionalidades, sendo o mais comum que umaaplicação normalmente do tipo cliente possa ser servidor e não o contrário.

O padrão OPC permite ainda a comunicação de blocos de dados entre o servidor e osclientes. Isto representa uma grande otimização, pois as informações de tempo e estadodo dado são tratados e fornecidos apenas uma vez para um conjunto de dados, reduzindoassim o overhead da comunicação. Neste caso, cada item é configurado como um blocode dados.

Em linhas gerais, o desempenho da comunicação OPC se aproxima do desempenhoapresentado por sistemas que utilizam drivers de comunicação específicos e otimizados.Normalmente, os drivers específicos possuem um ótimo desempenho após serem devida-mente depurados e otimizados. Como um servidor OPC é uma camada de software a maispara implementar as interfaces padrão e os mecanismos de comunicação com o cliente,é de se esperar que o desempenho do mesmo só seja afetado em relação a comunicaçãocom o cliente e não com o dispositivo de campo.

No caso da comunicação com o dispositivo de campo, cada fornecedor pode imple-mentar o driver e o protocolo que melhor se ajustem às necessidades do dispositivo e darede de comunicação. Desta forma, o desempenho do servidor OPC está mais relacionadoà capacidade dos recursos de hardware da máquina que executa a aplicação do servidor doque propriamente do driver específico. Uma vez que os recursos de hardware estão cadavez mais poderosos em relação à capacidade de processamento, isto não tem se mostradoum problema.

DFIA DFI (Distributed Field Interface) é o gerenciador de comunicação, ou seja, o dis-

positivo que controla as ações relacionadas ao sistema fieldbus. Ela é um componente dehardware integrado ao sistema que auxilia no gerenciamento, monitoramento, controle,manutenção e operação a planta. É um elemento fundamental na arquitetura fieldbus,executando a maioria das funções exigidas pelo sistema de controle. Este equipamentofunciona como a interligação (bridge) entre os canais, onde os instrumentos estão instala-dos e o operador (Figura 2.5). Possui 4 (quatro) módulos, os quais possibilitam a conexãodo sistema com a rede HSE, abragendo a comunicação para os instrumentos localizadosem segmentos diferentes. Além de interligar os canais, a DFI conecta todo o sistema auma rede Ethernet utilizando para isso um switch. Possui endereço fixo de IP, o qual podeser acessado pelo sistema supervisório através de tecnologia OPC.

A DFI é o elemento chave de interface em um sistema de controle de campo, com-

4DCOM - acrônimo para Distributed Component Object Model é uma tecnologia proprietária da Mi-crosoft para criação de componentes de software distribuídos em computadores interligados em rede.


binando recursos de comunicação. Possui acesso direto a entradas e saídas e controleavançado para aplicações contínuas e discretas. Funciona como bridge H1-H1, H1-HSE(HIGH SPEED ETHERNET) ou H1- HSE-H1, e também como mestre dos barra-mentos H1, gerenciando a comunicação em cada canal. Permite ainda a execução dediversos blocos funcionais, além de funcionar como gateway entre HSE ou H1 e outrosprotocolos que não são FF, como DeviceNet, Profibus,etc.

2.4 Sensores de SoftwareAtualmente, uma das aplicações mais procuradas na automação industrial é a medição

indireta, que consiste em inferir um valor a partir das medidas de outros sensores. Issopode ser realizado através da implementação dos chamados software sensors, ou, sensoresde software. Além dessa, outra aplicação recorrente na automação é o uso de dispositivos(sensores ou atuadores) inteligentes.

Com o advento dos microcontroladores e a grande disponibilidade de ferramentas e re-cursos para o processamento de sistemas digitais, foi possível introduzir uma elevada ca-pacidade de computação aos sensores e atuadores [Chong & Kumar 2003]. Deste contextonasce o termo dispositivos inteligente, que é a integração de um sensor analógico ou dig-ital ou um atuador a uma unidade de processamento e uma interface de rede [Elmenreichet al. 2003].

O conceito de redes de sensores inteligentes não está somente ligado à troca de infor-mações de um dispositivos para outro, mas também com o compartilhamento e disponi-bilidade das informações em tempo-real. O funcionamento de dispositivos inteligentesem rede através de interfaces padronizadas torna possível o compartilhamento de infor-mações e recursos de um sistema, a supervisão de um processo completo, além de acessoe monitoramento remoto das variáveis envolvidas. O uso de dispositivos com capacidadede processamento aliado ao seu poder de comunicação possibilita criar aplicações dis-tribuídas entre os sensores e atuadores da rede. Algumas dessas aplicações, usadas maisespecificamente no ambiente foundation fieldbus serão mostradas à seguir.

2.5 Sensores de Software em Redes Foundation FieldBusOs resultados obtidos em trabalhos anteriores têm mostrado que o uso dispositivos

inteligentes, aliado às técnicas de redes neurais, permite a incorporação de inteligência naaplicação de controle da planta.

Uma dificuldade que surge na análise das aplicações inteligentes desenvolvidas é aausência de uma plataforma dedicada que permita a integração de diferentes sensoresnum ambiente de rede industrial, bem como a implementação de novas funções baseadasno processamento inteligente da informação.

Uma das ferramentas mais utilizadas no projeto e implementação dos sensores desoftware são as redes neurais artificiais. A ausência de uma solução padrão que imple-mente redes neurais no ambiente de redes FF dificulta o desenvolvimento de um pro-jeto de medição indireta para o campo, além de outros possíveis projetos que envolvam


redes neurais. A menos que se opte por uma solução proprietária, o que não garantemanter a interoperabilidade entre os dispositivos da rede, principalmente se esses foremde fabricantes diferentes. Contudo, diversos trabalhos apresentam implementações queaproveitam a capacidade de processamento dos blocos funcionais do Foundation Field-Bus.

No trabalho de Silva et al. (2006) é apresentado um estudo da viabilidade técnicada utilização de redes neurais artificiais em dispositivos de campo que seguem o padrãoFoundation Fieldbus mostrando a possibilidade de tal implementação, baseada completa-mente em blocos funcionais padrões. A solução apresentada garante a interoperabilidadesendo possível sua implementação em qualquer equipamento, de qualquer fabricante quecontenham os blocos funcionais padrão, bastando para isso que ele seja homologado pelaFoundation FieldBus.

Dentre os blocos funcionais padronizados, os blocos aritmético e caracterizador sãodiretamente utilizados no projeto de um neurônio artificial. Através da configuração e in-terligação desses dois blocos funcionais, podemos obter um modelo de neurônio próximoao mostrado na Seção 2.2.1. As diferenças ficam por conta da função de ativação. Nobloco aritmético da Figura 2.6, o sub-bloco algorithm logic é utilizado para calcular ocampo local induzido (saídas) do neurônio a partir de suas entradas. Esse valor é calcu-lado aplicando-se um peso para cada entrada do neurônio (o bloco funcional provê essespesos como parâmetros), e depois somando-os com um valor adicional, chamado de bias,também disponível no bloco funcional como parâmetro. Para isso, foi escolhido, entre asvárias funções do sub bloco algorithm type, o algoritmo somador tradicional.

*

Figura 2.6: Esquema interno do bloco artimético padrão FF

Depois de calculado o campo local induzido, para que seja possível implementar umneurônio artificial (com até três entradas), falta apenas a função de ativação, que será im-plementada usando o bloco funcional padrão chamado de "Caracterizador de Sinais"ou


simplesmente caracterizador. O bloco caracterizador é mostrado na Figura 2.7 e tem afunção de fazer um mapeamento entre uma entrada e sua respectiva saída. Esta função,é definida a partir de uma Tabela com no máximo 21 pontos (x-y), onde os pontos inter-mediários são obtidos a partir de uma interpolação linear executada pelo bloco funcional.

IN_1 OUT_1

IN_2 OUT_2

Caracterizador

IN

OUT

Figura 2.7: Esquema interno do bloco caracterizador de sinais padrão FF

Ligando-se a saída de um bloco aritmético, configurado como descrito anteriormente,à entrada de um bloco caracterizador implementando uma função de ativação, tem-se umneurônio artificial. Dessa forma podemos formar uma rede neural artificial interligando asaída desse neurônio, às entradas de outros neurônios e organizá-los de maneira desejada.

Ao utilizar somente blocos funcionais padronizados para a implementação de redesneurais, podemos ter uma maior flexibilidade na arquitetura da rede, visto que pode-se conectar quantos blocos forem necessários, formando qualquer arquitetura desejada.Além disso, têm-se a possibilidade de processamento paralelo e distribuído uma vezque pode-se distribuir neurônios entre os dispositivos da rede. E aqueles que podemser paralelizados, são agendados para o mesmo tempo no macro-ciclo5, tendo assim umadiminuição do esforço computacional de um dispositivo ao distribuir neurônios entre eles.

Quando comparado ao uso de um micro-computador executando o algoritmo de redeneural, a implementação em blocos funcionais padrão [Silva et al. 2006] apresenta a pos-sibilidade de execução de algoritmos inteligentes em ambientes hostis (altas temperaturas,descargas elétricas, etc.), visto que a solução estaria encapsulada em um sistema com car-acterísticas de segurança intrínseca e maior robustez a falhas. Ao usar micro-computador,o sinal coletado e o sinal injetado na rede devem ser agendados no macro-ciclo, o queaumentaria o tamanho do mesmo.

No trabalho de Costa (2006) é proposto o desenvolvimento de um sistema de fil-tragem composto por um algoritmo inteligente, capaz de separar informação e ruídosprovenientes de sensores de campo interligados por uma rede Foundation Fieldbus (FF).A implementação do algoritmo é feita em blocos funcionais padrão da própria rede FF,com treinamento on-line via OPC.

Essa abordagem usa algoritmos baseados em Análise de Componentes Independentes(Independent Component Analysis - ICA)[Amari et al. 1997], mais especificamente oFastICA[Hyvarinen 1999]. Dentre os blocos funcionais padronizados, foram utilizados

5Um macro-ciclo é uma única iteração da agenda dentro de um dispositivo. É o tempo de um ciclo decomunicação dos dispositivos.


os blocos AI (Analog Input) e ARITH (aritmético). Da mesma forma como utilizados porSilva et al. (2006) para representar um RNA.

A Figura 2.8 apresenta um diagrama de blocos do processo de implementação do algo-ritmo FastICA em blocos funcionais. Inicialmente foi realizada uma coleta de dados paraque fosse formado o conjunto de treinamento do algoritmo. Esse conjunto foi compostopor medidas ruidosas, referentes aos sinais dos dois sensores, enviadas ao supervisório viaOPC. Após o treinamento do algoritmo, os pesos sinápticos resultantes foram instanciadosnos blocos funcionais dos sensores de campo, mantendo o padrão de interoperabilidadedo sistema e visando uma forma robusta de filtragem de ruído independente de sistemassupervisórios.

Sensor 1

Ambiente FF

Via OPC Via OPC Via OPC

Rede

Neural

(FastICA)

Entrada Analógica Adição de Ruído

Valores Reais

Ruído

SAÍDAS DA REDE NEURAL

Sensor 2

Supervisório Supervisório Supervisório

Figura 2.8: Diagrama de blocos da implementação do algoritmo de filtragem para medidasde sensores [Costa 2006]

Outro trabalho relacionado a software sensors é mostrado em Fernandes et al. (2007),onde foi desenvolvido um sistema de detecção e isolamento de falhas utilizando redesneurais artificiais, aplicado a um sistema que controla os níveis de dois tanques (sistemade níveis). O esquema geral do funcionamento do sistema está exibido na Figura 2.9.Nesse caso, ao mesmo tempo em que o sistema de níveis está em execução, um sistemaelaborado a partir de Redes Neurais Artificiais (RNA) procura fazer a sua identificaçãoutilizando suas mesmas entradas (x(k)). A cada instante, a saída do sistema de níveis(y(k)) é comparada à saída do sistema de identificação (y′(k)), gerando um valor deresíduo (r(k) = y(k)− y′(k)) que será posteriormente utilizado no sistema de detecçãoe isolamento/classificação de falhas. Este último analisa os valores residuais e indica aocorrência ou não de falhas e caso ocorra, qual o seu tipo.

Os dados reais extraídos da planta (composta por dois tanques) para treinamento dasredes neurais foram captados da rede com o auxílio de softwares utilizando o padrão OPC.O sistema foi definido como identificação em dois-passos, o que significa a existência deuma RNA pra avaliar o nível do tanque 1 e outra para avaliar o nível do tanque 2. Aarquitetura da RNA 1, usada para avaliar o nível do tanque 1 é composta por:

• Três nós na camada de entrada, onde as entradas são: Vp(k), Vp(k−1) and L1(k−1);• Uma camada oculta com três neurônios com função de ativação sigmóide e


Sistema deNíveis

Sistema paraIdentificação

Detecção eIsolamento de

Falhas

x(k) y(k)

S/F

F1

F2

Fn

y’(k)

r(k)+

-

Figura 2.9: Esquema Geral do Sistema de Detecção e Isolamento de falhas [Fernandes2007]

• Um neurônio na camada de saída (função de ativação linear), representando o níveldo tanque 1 estimado no instante atual k, L′1(k).

A arquitetura da RNA 2, usada para estimar o nível do tanque 2, foi:

• Dois nós na camada de entrada, onde as entradas são: L1(k−1) and L2(k−1);• Uma camada oculta com três neurônios com função de ativação sigmóide;• Um neurônio na camada de saída (função de ativação linear), representando o nível

do tanque 2 estimado no instante atual k, L′2(k).

Onde L é o nível do tanque e V é a tensão aplica a bomba. Com esta estratégia deidentificação, é possível obter dois resíduos, R1 e R2, onde R1 = L1−L′1 e R2 = L2−L′2.Observando a disposição dos resíduos, foi elaborada uma estratégia para a classificaçãodas falhas ilustrada na Figura 2.10. Neste caso, uma RNA, denominada RNA 3, é treinadarecebendo como dados de entrada os valores de R1 e R2. A saída da rede correspondea um vetor de N + 1 números, onde N é a quantidade de falhas que a rede será capaz declassificar.

Tanque 1 Tanque 2

RNA 2

RNA 3Classificação de Falhas

RNA 1

R1

F1 F2 FnS/F

R2

.....

+ +

- -

Figura 2.10: Esquema Geral para Classificação das Falhas [Fernandes 2007]

Considerando os dois resíduos para detectar e isolar falhas, o SDI pode detectar nomáximo 8 diferentes falhas, sendo que R1 = 0 and R2 = 0 indique o comportamento


normal do sistema. As demais falhas identificáveis são vistas na Tabela 4.1 onde o sinalde ’+’ representa o resíduo positivo, ’-’ resíduo negativo e 0 representa um valor muitopróximo a zero.

Tabela 2.2: Situações de falhas com base nos resíduosFalha Descrição R1 R2

Ausência de Falha 0 01 Vazamento no tanque 1

para fora do sistema- 0

2 Entupimento do tanque 1 + -3 Entupimento do tanque 2 - +4 Vazamento no tanque 2

para fora do sistema0 -

5 Erro de leitura de sensortanque 1 (Ruído)

+ 0

5 Erro de leitura de sensortanque 2(Ruído)

0 +

A RNA 3 também foi treinada com o algoritmo de Backpropagation, para a qual onúmero de neurônios foi escolhido heuristicamente e estão totalmente conectados. Combase na situação descrita, a arquitetura da RNA 3 ficou da seguinte maneira:

• Dois nós na camada de entrada, onde as entradas são: R1 e R2;• Uma camada oculta com 6 neurônios com função de ativação sigmóide;• Sete neurônios na camada de saída (função de ativação linear), representando uma

das situações ilustradas na Tabela 4.1 no instante atual k.

Como o classificador neural trabalha em cima de valores positivos, negativos e próx-imos a zero para os resíduos, ele poderia ter sido traduzido em um conjunto de regrascom sentenças condicionais. Por exemplo, se R1 for positivo e R2 negativo, bastaria fazerum teste condicional e indicar que a falha 2 está ocorrendo. Por outro lado, se um outrosistema dinâmico pudesse ser modelado por N resíduos, onde N é um valor muito grande,ficaria um pouco difícil codificar diversas sentenças condicionais para informar a falha.Além disso, o classificador neural pode detectar falhas com resíduos semelhantes (duasfalhas diferentes com mesmos R1 e R2, por ex., R1 = + e R2 = 0), porém com amplitudesem faixas de valores distintas, sem a necessidade de um novo teste condicional verifi-cando o limiar da falha. A principal vantagem de se utilizar a RNA como classificador éo fato dela ser uma ótima generalizadora de funções.

Por exemplo, dificilmente os resíduos assumirão valores iguais a zero, então quandoalguma situação for considerada com valor de R1 ou R2 igual a zero, significará que eleestará dentro de uma faixa de valores (positivos e negativos) muito próximos a zeros.Assim, com o classificador baseado em regras, seria necessária a definição de um limiarque identificasse resíduos nulos ou próximos de zero.

No trabalho de Cagni et al. (2005) é mostrada outra abordagem de software sensors,usada neste caso para auto-correção, auto-verificação e auto-validação de medidas em


sensores. Esses instrumentos de medição utilizam elementos transdutores capazes detransformar uma grandeza física em um sinal elétrico, analógico ou digital, cujo sinalde saída depende do valor da grandeza medida. A partir desse sinal elétrico é possívelvisualizar o valor da grandeza por meio de uma escala gráfica ou de um mostrador digital.A função matemática que define a proporcionalidade entre a grandeza física e o sinalfornecido pelo sensor é chamada de curva de calibração.

É comum, durante o ciclo de vida de um processo industrial, que os sensores atuantesna planta se desgastem e se descalibrem com o tempo, isto é, que a curva de calibraçãose deforme, fazendo com que o sinal referente ao valor da medição não corresponda aovalor real da grandeza física. Essa descalibração deve ser evitada pois pode mascarar osverdadeiros resultados obtidos com o processo, ocasionando erros em seu controle. Aproposta dos autores é utilizar Redes Neurais Artificiais, aproveitar a sua capacidade deaprendizado e aproximação de funções, de forma que elas possam aprender a variaçãoda curva de calibração do sensor com o tempo. Conhecendo o padrão de variação de talcurva, é possível corrigir erros oriundos da descalibração e indicar quando o sensor estádescalibrado.

O algoritmo da Auto-Correção tem como objetivo corrigir o erro provocado pelas al-terações na forma da curva de calibração do sensor. Essa correção possibilita o aumentodo tempo em que sensor pode ficar em campo sem a necessidade de uma nova calibraçãoem laboratório. Seu funcionamento parte do princípio de que existe um sensor descali-brado em funcionamento, denominado sensor comum, cujas medidas serão interceptadaspor uma rede neural que tem conhecimento do tempo de funcionamento do sensor. A redeneural deve conhecer o quanto o sensor está descalibrado levando em consideração o seutempo de funcionamento, de forma que corrija o erro de medição.

Para que a correção seja possível, é necessário que a rede neural passe por uma fase detreinamento. Nesta fase, um conjunto de dados contendo a medição de um sensor descali-brado para diversos valores de entrada e o seu tempo de funcionamento são apresentados auma Rede Neural Perceptron de Múltiplas Camadas. Estes dados serão comparados comos dados provenientes de um sensor devidamente calibrado, denominado sensor padrão,gerando um sinal de erro que será utilizado pelo algoritmo da backpropagation para ajus-tar os pesos da rede neural.

A rede neural deverá, dessa maneira, conhecer o padrão de descalibração do sensorpara diversos tempos de funcionamento, de forma que um sensor descalibrado em con-junto com a rede neural se comporte da mesma maneira que um sensor calibrado. Odiagrama de blocos que representa o treinamento da rede neural para a Auto-Correçãopode ser visto na Figura 2.11.

2.6 Agentes no Contexto IndustrialEm um SMA, os agentes são o conjunto de entidades ativas, já as entidades passivas

formam o ambiente. Um agente raciocina sobre os outros agentes e o ambiente, assimquando um agente está inserido em um determinado ambiente ele se encontra exposto ainterações com este ambiente. Existem diversas propriedades de um ambiente que podeminfluenciar no projeto do agente. E para seu funcionamento, o ambiente perfeito é o


Planta SensorPadrão

SensorComum

RedeNeural

+

-

Erro

Tempo

Leitura do Sensor

Leitura do Sensor

Correções dos Pesos

Leitura Compensada

Figura 2.11: Diagrama de Blocos do Treinamento da Auto-Correção [Cagni et al. 2005]

acessível, estático, (ou semi-estático) e episódico. Sob este aspecto dizemos que umSMA trabalha sem restrições [Russell & Norvig 2003].

Aplicações de SMA no ambiente de automação e industria apóiam-se em uma grandevariedade de trabalhos na literatura ([Weyns et al. 2005], [Weyns & Holvoet 2007], [Seilonen,Pirttioja & Appelqvist 2002], [Feng et al. 2007]). A principal razão de usar agentes nestesambientes é que estas aplicações necessitam de interpretação e planejamento distribuído.Estas áreas de aplicações são também caracterizadas por uma distribuição natural de sen-sores e atuadores no espaço da planta [Chaib-draa 1995].

2.6.1 Ambiente FieldBus (Barramento de Campo)Componentes de controle de um processo (dispositivos e softwares) precisam ser ca-

pazes de responder a estímulos dentro de um limite de tempo (tipicamente milissegundosou microssegundos). Um sistema que monitore a temperatura de um motor, por exemplo,tem que ser capaz de desligá-lo rapidamente, caso a temperatura exceda um certo limite.

Geralmente, as tarefas executadas por sensores e atuadores de uma rede industrialrespeitam o macro-ciclo de execução. Ou seja, dentro de um determinado intervalo detempo os dispositivos de campo realizam suas aferições e ações. Se fizermos uma analogiacom os ambientes de agentes discutidos no início da sessão, podemos dizer que o ambi-ente fieldbus é episódico. Referindo-se a um dispositivo atuador como sendo um agente,percebemos que sua ação depende somente do episódio (macro-ciclo) atual. Quanto aquestão de acessibilidade, não podemos garantir que um agente inserido em barramentode campo tenha acesso a todas as variáveis necessárias no momento de sua execução.Neste caso, o ambiente fieldbus é inacessível.

Sensores e atuadores em barramento de campo tem suas ações dependentes principal-mente de variáveis (temperatura, pressão, vazão, etc) que mudam com o tempo. Seguindoesta linha de raciocínio podemos perceber que comportamento da planta (fieldbus) édinâmico, pois enquanto o agente delibera sobre sua ação o ambiente muda.

Após estas argumentações, podemos concluir que ao contrário do ambiente ideal ex-posto anteriormente, um agente inserido no contexto do barramento de campo, está no


ambiente episódico, não-acessível e dinâmico, ou seja, severas restrições. Além disso,outras restrições, no que diz respeito a implementação dos agentes, não só em barramentode campo, mas também no processo de automação como um todo, devem ser destacada[Wagner 2002]:

• Diferente do domínio de sistemas tradicionais, onde são usados computadores eservidores que seguem um padrão, componentes de hardware usado em sistemasde automação são específicos. Por essa razão, componentes de hardware e softwarepossuem uma associação bem próxima. Ou seja, mudanças no software afetam ohardware e vice-versa.• Plantas industriais são sistemas de hardware-software bastante heterogêneos cau-

sando um enorme esforço de desenvolvimento e operação. Dessa forma, requer umvolume de investimento igualmente grande. Essa é o principal motivo para os oper-adores e gerentes da rede industriais serem céticos com relação a novas tecnologias.• Novas abordagens devem ser adotadas de maneira pragmática, de forma a se en-

caixarem nos requerimento dos processos monitorados pela planta.• Modelos de aplicação já utilizados no domínio da aplicação devem ser integrados

mantendo a interoperabilidade.• Novos atributos devem ser implementados sem grande mudanças nas arquiteturas

de hardware e software existentes.

2.6.2 Sistema Multiagente em Redes IndustriaisA natureza distribuída e o processamento independente dos dispositivos fazem com

que as redes industriais sejam um ambiente propício para o uso de agentes. Além disso,em ambientes de redes industriais as tarefas que são executadas pelos dispositivos, namaioria dos casos, são dependentes umas das outras. Neste cenário, há uma estreitaconexão e colaboração entre os sensores e atuadores de uma planta. Por isso, as tendênciasde pesquisa nesta área é propor a troca de modelos hierárquicos por modelos horizontais([Deen 2003], [Shen et al. 2001]), nos quais partes (sistemas de software e dispositivos)de um mesmo nível podem interagir diretamente uns com os outros.

Nestes casos, agentes de software e sistemas multiagente (SMA) são utilizados comoarquiteturas que permitem este tipo de interação. O paradigma de desenvolvimento deagentes permite a quebra da complexidade de problemas, dividindo-os em partes menores(pequenas tarefas), que são executadas através da interação entre os agentes. O maior es-forço de pesquisa neste sentido está dedicado em aplicar um SMA para problemas dealocação, i. e. organizar eficientemente no nível de chão-de-fábrica tarefas das células deprodução ([Giret et al. 2005], [Cockburn & Jennings 1996], [Stefano & Santoro 2000],[Stefano & Santoro 2002]). O paradigma de desenvolvimento de agentes é uma alterna-tiva para sistemas distribuídos e de engenharia complexa em seus vários níveis, como aadministração, supervisório e chão de fábrica.

Para Wagner (2002), um sistema de automação pode interagir com um sistema multia-gente na forma de um nível hierárquico de comunicação (Figura 2.12). A cooperação dosagentes é desenvolvida para agir de forma muito parecida com o sistema de automação e


pode ser divida em duas categorias básicas: agentes de recurso (AR) e agentes de serviços(AS):

• Com o sistema multiagente, todas as entidades reais (sensores, atuadores, etc.)que estão no foco do problema do sistema de automação são representados pelosagentes de recursos. A complexidade destes agentes depende do nível de atuaçãoda entidade em questão.• Os agentes de recurso encapsulam as informações da entidade que ele representa.

Isto é, eles são capazes de se comunicar com as interfaces da entidade (dispositivos)e prover uma visão abstrata da entidade para o agente de sistema.• Agentes de recursos podem ser de diferentes tipos para representar diferentes visões

(papéis) da entidade: agente de projeto, agente de monitoramento, agente de diag-nóstico. Estes agentes cooperam entre si para alcançar o objetivo do sistema.• Agentes de recursos agem autonomamente em referência às entidades que eles

representam. Por exemplo: agentes representando um dispositivo de campo sãocapazes de responder a uma mudança no ambiente através da manipulação dosparâmetros do dispositivo. Sinais de status e diagnósticos podem ser armazenados einterpretados por agentes de recursos de, forma a gerar informação de manutenção(e.g. predição de vida útil ou predição de falhas).• Agentes de recursos podem, de forma autônoma, construir estruturas que refletem

as estruturas físicas e lógicas da planta.• Ações pró-ativas podem ser aplicadas para predição de falhas ou planejamento de

manutenção preventiva.• Agentes de serviço não representam uma entidade real, mas uma tarefa ou visão

dentro do sistema de automação. Eles são desenvolvidos para realizar funçõesnão cobertas por dispositivos ou elementos de controle. (gerência de dispositivos,gerenciamento de inspeção, etc.)• A comunicação já existente entre os dispositivos e sistemas supervisórios deve ser

mantida. Além disso, os agentes devem respeitar as restrições do processo (re-strições de tempo-real).

Stefano & Santoro (2009) apresentam uma arquitetura baseada em agentes móveispara controle de processos distribuídos. Um conjunto de agentes é utilizado para, emuma célula de produção, controlar, monitorar reconfigurar funcionalidades da célula. Osagentes (Figura 2.13) operam em uma estrutura de dois níveis: no nível superior osagentes de planejamento analisam as entradas do sistema e automaticamente criam osagentes de campo, os quais operam no nível inferior e executam tarefas de controle. Osagentes de campo são móveis e são capazes de, autonomamente, assumir o controle dacélula. A mobilidade permite que o agente de campo mude sua execução de um disposi-tivo para outro quando uma falha do sistema requerer uma nova distribuição de tarefas.

Um algoritmo de balanço de carga é introduzido para alocar cada agente de campo aum controlador de modo a não sobrecarregar os dispositivos. Este algoritmo usa a técnicade branch-and-bound (ramifica e limitar) para explorar todas as possibilidades de alo-cação e aplica duas heurísticas para eliminar as soluções não-viáveis e selecionar o mel-hor ramo a ser analisado. O algoritmo foi desenvolvido para execução on line, de modo


Controle de Processos

Nível de Supervisão

Nível de Campo

Sensores &Atuadores

AR n

AR 3

AR 2

AR 1

AS n

AS 1

Figura 2.12: Sistema multiagente como parte de um sistema hierárquico de automação[Wagner 2002]

C Agente de Campo Sensor

Atuador

Agente de Planejamento

Agente de Monitoramento

P

C

P

M

M

C

P

M C

P

M

Figura 2.13: Ambiente de atuação de agente de Stefano & Santoro (2009)

a permitir uma rápida distribuição dos agentes quando uma situação de falha acontecer.Além disso, os agentes são desenvolvidos usando um o framework de desenvolvimentode agentes JADE (Java Agent Development Framework).

Nesta mesma linha de implementação está o trabalho de Frey (2008), que assim comoa arquitetura de agentes que será apresentada nesta tese, utiliza aprendizagem de máquina(no caso mapas auto-organizáveis) para que os agentes aprendam como diagnosticar osproblemas encontrados no processo industrial. O sistema de diagnóstico ilustrado naFigura 2.14 é baseado na idéia de analisar continuamente as mensagens transmitidas nobarramento de campo (fieldbus) e extrair suas características, as quais descrevem o com-


portamento do respectivo dispositivo de campo e sua interação com todo o processo.

fieldbus

fieldbus

DC DC

DC

M

M

M

D

D

Dispositivosde campo

AgenteMestre

Agente deDiagnóstico


Mestre

Figura 2.14: Ambiente de atuação de agente de [Frey 2008]

Os agentes de diagnóstico, que estão no nível mais baixo do processo de automação(fieldbus) são executados nos dispositivos, como por exemplo, os fieldbus gateways (Seção2.3.2). A tarefa dos vários agentes de diagnóstico é analisar as mensagens do barramentode campo de um determinado dispositivo e gerar informações significantes que possamindicar falhas ou problemas.

Implementado em um nível mais alto do processo de automação (supervisório) estãoos agentes de diagnóstico mestres. Eles recolhem também informações sobre o processocontidas nos sistemas de monitoramento e controle da planta. Ainda segundo Frey (2008),não há um padrão entre os processos industriais, ou seja, é pouco provável que uma plantatenha um comportamento similar a outra, mesmo quando se trata da produção de ummesmo item ou controle das mesmas variáveis. Essa natureza singular de cada processofaz com que sejam necessários sistemas que possam se adaptar a um contexto novo oudesconhecido.

Com isso, baseando-se no histórico dos valores das variáveis medidas, usam um al-goritmo de aprendizagem de rede neural, mais especificamente o SOM (self-organizingfeature maps) ou mapas de características auto-organizáveis. A vantagem desse método éque não é necessário conhecer um modelo do processo a priori.

Outro trabalho que relaciona multiagentes na supervisão de processos industriais é ode Pirttioja et al. (2005). Os autores mostram que agentes atuam como mediadores entre ooperador (supervisor) e o processo (dispositivos). Para isso é criada uma camada de con-hecimento cujo o objetivo, segundo o autor, é integrar o máximo de informações possíveise automatizar o processamento dessas informações facilitando a tomada de decisões dosusuários. A arquitetura proposta pode ser vista na Figura 2.15.

O tipo de agente principal é o Agente de Processo (PA) que é o responsável por moni-torar uma determinada quantidade de dispositivos monitorados (esfera de influência). Ele


AP11

AP12

AP1

AP13

FD

ACAI

BD

ABD

Agentes deProcesso

Esfera deInfluência

AgenteCliente

Agente deTarefas Especiais

Ambiente

Figura 2.15: Ambiente de atuação de agente de [T.Pirttioja et al. 2005]

verifica constantemente as variáveis do processo e observa mudanças na estrutura físicada planta. Os Agentes de Processos (AP) formam uma hierarquia, manipulando abstraçãode dados de um nível para o outro. No nível inferior do processo, os agentes manipulaminformações detalhadas das medições, enquanto os agentes nos níveis mais altos lidamcom informações mais resumidas sobre as condições do processo.

O Agente de Informação (AI) é um especialista que provê serviços de informaçãopara outros agentes. Um Agente de Informação possui habilidades de decompor umatarefa em sub-tarefas. Essas sub-tarefas são repassadas para outros agentes, os quaistem a possibilidade de executá-las. Ou seja, agentes de informação delegam tarefas paraoutros agentes.

O Agente Cliente (AC) provê uma interface para os agentes humanos e traduz asconsultas dos usuários para a linguagem de comunicação dos agentes. Já os Agentes deBanco de Dados (ABD) servem como mecanismo de acesso as informações armazenadasem sistemas legados. Os ABD também traduzem as informações para um formato com-patível com a linguagem dos agentes. Por fim, o Facilitador de Diretório (FD) forneceuma ampla variedade de serviços e informações sobre o processo para os agentes. O FDé padronizado pela FIPA.

Em seu trabalho, Elmenreich (2003) propõe a idéia de um sistema multiagente parainterconectar diversos agentes independentes e assim fazer com que esse agrupamentoextrapole as capacidade dos agentes individuais. De uma forma geral, segundo o autor,o uso de agentes deve aumentar a velocidade do processamento (através do paralelismo),confiança (através da redundância), eficiência e flexibilidade. Pesquisas recentes têmmostrado também a capacidade de SMA em sistemas embarcados. Contudo, existemalguns problemas críticos para um SMA neste ambientes [Elmenreich 2003]:

• Comunicação - agentes devem concordar com um protocolo de transporte, comu-nicação e linguagem comuns de forma a interagir corretamente [Nwana & Ndumu


1999]. Por exemplo, um SMA que lida com sistemas embarcados diferentes, provavel-mente não consegue lidar com representações diferentes de dados e semânticas.• Integração com aplicações existentes - especialmente sistemas embarcados pos-

suem sistemas legados; sistemas que foram desenvolvidos de acordo com suaspróprias regras e convenções. Uma vez que a participação de tais sistemas nãofoi previamente incluída nos projetos (SMA), deve existir um esforço extra na im-plementação de uma interface apropriada para o SMA.• Capacidade de tempo-real - devido à forma livre de acoplamento dos agentes indi-

viduais, um SMA é tipicamente assíncrono e, então, tende a acelerar suas tarefas,tempos de execução inesperado e, no pior caso, situações de deadlock.• Supervisão - É geralmente difícil monitorar o comportamento de cada agente indi-

vidualmente para que se respeite as exigências de sistema em tempo real. Tarefasde monitoramento podem mudar o comportamento ou desempenho de um SMA.

Além disso, outros aspectos na implementação de agentes em ambientes industriaisdevem ser levados em conta. De acordo com Landaburu et al. (2002), agentes devemser usados em sistemas fieldbus como plataforma leve, não atrapalhando o processo emquestão. Li et al. (2004) diz que um sistema multiagente é um campo importante depesquisa em sistemas de controles inteligentes e diagnóstico de falhas. Baseado empesquisa sobre funções de cooperação e coordenação de multiagentes, uma estruturasemântica a qual integra controle, diagnóstico e monitoramento é construída e estes mod-elos (estratégia de cooperação e máquina de raciocínio) também são desenvolvidos.

Outro trabalho que podemos citar é o de Macerauskas & Teresius (2004). Os au-tores comparam a implementação de um protótipo baseado em agente de controle decélulas com a experiência de implementações usando abordagens tradicionais de agentes,mostrando os benefícios de cada abordagem. O uso de várias linguagens e plataformasde comunicação distribuídas, para desenvolver aplicações de controle, permite o uso damesma aplicação em ambientes de diferentes sistemas.

Agente Operacional Agente Operacional

Agente deProduto

AgenteSupervisor

Agente deTarefa

ParteLógica

ParteLógica

Agente deGerência

Interação dosAgentes

SistemasExternos

Figura 2.16: Ambiente de atuação de agente de [Macerauskas & Teresius 2004]

Os Agentes Operacionais (AO), mostrados na Figura 2.16, controlam as interaçõescom os recursos físicos, tais como humanos, sensores e atuadores. Os AO possuem a


parte lógica que controla e interage com os dispositivos. O Agente Supervisor coordenaos demais agentes de acordo com a estrutura organizacional da planta. Enquanto que oagente de produto representa os recursos disponíveis no sistema e cuida da informaçõesassociadas ao processo realizado pela planta. Os Agentes de Tarefas controlam a execuçãode uma tarefa e as informações sobre a manufatura de um produto e o Agente de Gerênciasupervisiona e aloca os agentes no sistema.

A arquitetura desenvolvida para um agente genérico é baseada em três módulos e umabase de dados local que contém todas as informações relevantes sobre o comportamentodos agentes. Existe ainda um módulo de tomada de decisão que controla todas as ativi-dades de um agente e inclui mecanismos de cooperação e mecanismos de aprendizagemde forma a auxiliar a tomada de decisão dos supervisores quando ocorrer uma falha. Asinformações armazenadas na base de dados local envolve vários tipos de dados tais comorestrições, objetivos, regras de decisão e procedimentos.

Cada agente é autônomo, tem controle do seu próprio comportamento e possui umacomunidade e conhecimento locais. Ainda segundo Macerauskas & Teresius (2004), épossível construir agentes independentes que possam ser alocados em ambientes distribuí-dos. A adição de inteligência a um agente para, por exemplo, tomar decisões, pode servista como um plug-in de um módulo de inteligência. Para pequenos usos específicos,a abordagem tradicional pode apresentar vantagens de pequena complexidade de desen-volvimento.

A principal diferença entre SMA e sistemas tradicionais é que SMA não possui umcontrole de dispositivo comum, o qual pode ditar as ações dos agentes. Em comparaçõescom abordagens tradicionais o SMA apresenta importantes melhorias tais como expansi-bilidade, robustez, reatividade, suporte a ambientes distribuídos e re-uso de código.

No trabalho de Lin & Yang (2007) vemos que a construção de uma ontologia6 é im-portante para implementação de uma linguagem de conteúdo em uma plataforma multi-agente, e assim crucial para a implementação de sua proposta de metodologia de recon-figuração de um sistema de linha de produção usando SMA. Assim, o modelo propostoé construído de acordo com duas funções: satisfazer o conhecimento sobre o processoda linha de produção e suportar o procedimento de reconfiguração. Para isso o autor usao modelagem fornecida pelo Protégé [Dong et al. 2007] (Ontologias) e Zeus [Glanzeret al. 2001] (Agentes).

2.7 Considerações FinaisNeste capítulo mostramos a fundamentação teórica de Redes Neurais, Sistemas Mul-

tiagente e Redes Industriais. Além disso, mostramos também dois tipos de trabalhos cujaa filosofia irá se aplicar na arquitetura que será proposta por esta tese. O primeiro deles serefere a redes neurais aplicadas a sensores de software de redes industriais.

Observamos que em um ambiente foundation fieldbus podem ser aplicadas diversasconfigurações de redes neurais que contemplam soluções para vários tipos de problemas

6Uma ontologia é uma especificação de uma conceituação, isto é, uma descrição de conceitos e relaçõesque existem em um domínio de interesse. Basicamente, uma ontologia consiste desses conceitos e relações,e suas definições, propriedades e restrições, descritas na forma de axiomas. [Gruber 1993]


tais como: filtragem de ruído, auto-calibração, detecção de falhas, etc. Todos este trabal-hos têm resultados que mostram a viabilidade deste tipo de aplicação.

No segundo tipo de trabalho apresentado anteriormente temos o uso de agente emambientes industriais. O que podemos perceber nessas implementações cujas caracterís-ticas principais são mostradas na Tabela 2.3 é que as arquiteturas possuem uma divisãode agentes com tarefas bem definidas, o que ajuda no desenvolvimento e manutenção dosagentes. Além disso, percebemos que o uso de agente em ambientes industriais é umaidéia que, apesar de nova, mostra uma grande aplicabilidade na solução de problemasencontrados nestes ambientes. Podemos perceber também que a maioria destes trabalhosalocam os agentes no nível de supervisão. E mesmo aqueles que alocam estes agentesnos dispositivos de campo fazem com que haja uma dependência de funcionamento comaqueles alocados no supervisório.

Tabela 2.3: Tabela comparativa de trabalhos de agentes em ambientes industriaisTrabalho Comunicação Funções dos

AgentesNível deAtuação

AgenteCoordenador

Implementação

[Wagner 2002] Direta Distintas Supervisórioe Campo

Sim -

[Macerauskas &Teresius 2004]

Direta Distintas Supervisório Sim -

[Pirttioja et al. 2005] Indireta Distintas Supervisório Não Ontologias[Frey 2008] Indireta Distintas Supervisório

e CampoNão S.O.M

[Stefano &Santoro 2009]

Indireta Distintas Supervisórioe Campo

Sim Heurísticas

No próximo capítulo apresentaremos nossa arquitetura mostrando que, assim como ostrabalhos aqui relacionados, usamos um conjunto de agentes com tarefas específicas (dis-tintas), comunicação direta e com nível de atuação nos nível de campo sem a necessidadede um agente coordenador. Contudo, será apresentado, como diferencial dos trabalhosrelacionados, a implementação de agentes nos próprios dispositivos de campo, de formaindependente de implementações no nível de supervisão e utilizando as técnicas de redesneurais alocadas nos blocos funcionais.

Capítulo 3

Arquitetura Multiagente em BlocosFuncionais

Este capítulo irá mostrar os componentes e o funcionamento da arquitetura multia-gente proposta. Esta arquitetura envolve quatro componentes que serão explicados commaiores detalhe mais adiante. O primeiro componente é a Alocação Dinâmica de Blo-cos Funcionais que na verdade é uma estratégia para poder alocar e desalocar blocosfuncionais (BF) dos dispositivos de campo e, conseqüentemente, a partir dessa alocaçãoinstanciar aplicações diferentes. O segundo componente são as redes neurais artificiais(RNA). São essas redes, alocadas nos BFs, que servirão como aplicações, ou seja, depen-dendo do treinamento da rede e de sua arquitetura, a rede age como um software diferente.

Outro componente que será discutido neste capítulo é a Camada LABVIEW/FIPA, re-sponsável basicamente pela comunicação dos agentes e pelo tráfego e armazenamento deinformação da arquitetura. Por fim, os agentes compõem o quarto componente. Assimcomo os trabalhos mostrados na sessão anterior, eles são divididos em tipos que repre-sentam suas tarefas (observação, diagnóstico e execução). Os agentes aqui apresentadossão redes neurais instanciados nos blocos funcionais dos dispositivos de campo. Elespercebem o ambiente (fieldbus) através de sensores e agem neste ambiente através de at-uadores (dispositivos), ou seja, são capazes de interagir com o meio em questão (CamadaLABVIEW/FIPA), tomando decisões (aprendidos no treinamento da rede neural) que irãoauxiliar a alcançar seu objetivo (resolução de problemas).

3.1 Alocação Dinâmica de Blocos FuncionaisPara alocar e desalocar os agentes nos blocos funcionais dos dispositivos de campo

é necessário mudar dinamicamente a configuração desses blocos. Ou seja, mudar emtempo de execução a forma de como eles estão interconectados alterando assim o com-portamento da aplicação instanciada nos dispositivos. Para isso, deve-se alterar os links(conexões) existentes entre blocos funcionais instanciados nos dispositivos de controlepara que, em seguida, outros blocos que estão inutilizados nos dispositivos possam as-sumir suas tarefas [Ramalho 2009].

Como podemos ver na Figura 3.1, a estratégia de reconfiguração é baseada em 4etapas.

CAPÍTULO 3. ARQUITETURA MULTIAGENTE EM BLOCOS FUNCIONAIS 35

1. Parametrização do novo bloco funcional, assim como a conexão de suas entradas;2. Migração dos dados do bloco em execução;3. Criação de novos links com as saídas do novo bloco funcional e4. Exclusão do bloco inutilizado da aplicação.

1 2 3 4

Figura 3.1: Exemplo de reconfiguração dos blocos funcionais [Ramalho 2009]

Uma das alternativas para realizar reconfigurações está associada à manipulação domacro-ciclo de execução da rede. Nesse caso, durante a faixa de atuação de tarefas assín-cronas, em que a rede não realiza ações de nível crítico em relação ao tempo de execução,pretendia-se instanciar os novos blocos funcionais para diferentes atividades. Porém, dev-ido às limitações e restrições de segurança do Foundation Fieldbus e do padrão OPC, nãoé possível interferir no macro-ciclo de execução da rede para incorporar outras atividadesque não estejam estruturadas através do algoritmo gerado pelo software de configuraçãoSyscon1. Só é possível ajustar alguns parâmetros que permitem escrita contínua duranteo tempo de execução. A inserção de novos links lógicos exige uma parada no modo deoperação dos instrumentos.

Diante da impossibilidade de realizar uma realocação de uma aplicação baseada emblocos funcionais diferentes daqueles que foram pré-instanciados, assim como para alteraro macro-ciclo de execução, adotou-se uma outra alternativa. A partir de uma aplicaçãopré-alocada na rede, torna-se possível instanciar diferentes aplicações com base em algunsartifícios usados nos blocos funcionais padrões.

Nossa estratégia é criar uma grande (macro) configuração de blocos funcionais e a par-tir dela derivar outras configurações [Machado et al. 2008b]. Ou seja, mudando os valorespassados de um bloco a outro, podemos mudar as aplicações instanciadas no dispositivosde campo. Na Figura 3.2 podemos ver a conexão de dois blocos funcionais aritméticos.O valor de saída processado pelo bloco da esquerda é passado para a entrada do bloco dadireita. Pode-se observar que o valor de saída do sub-bloco interno ALGORITHM LOGICé multiplicada pelo valor GAIN. Colocando este valor em 0 (zero), zeramos também ovalor passado de um bloco para o outro, anulando assim essa conexão. Ou seja, o valorpassado pelo bloco da esquerda (zero) não irá ter influência no cálculo do valor de saídado bloco da direita.

1Ferramenta de software para configurar e operar um sistema de controle de processo industrial baseadoem Foundation Fieldbus fornecido pelo fabricante SMAR (www.smar.com.br)


* *

Figura 3.2: Exemplo de conexão de blocos funcionais artiméticos

Observa-se também que existem três valores de ganho (GAIN_IN_1,GAIN_IN_2 eGAIN_IN_3) associados a cada entrada, que podem ser manipulados. Zerando esses val-ores também anularemos as entradas associadas. Um exemplo dessa estratégia é apresen-tado em [Machado et al. 2009a]. As figuras 3.3 e 3.4 apresentam a implementação deduas redes neurais baseadas em blocos funcionais no Syscon correspondentes as funçõesseno e exponencial, respectivamente. Ressalta-se que cada fabricante possui seu softwarede configuração próprio, portanto a forma de como a configuração é apresentada podevariar dependendo de qual software está sendo utilizado.

Neur1

Neur2

Neur3

FuncAtiv1

FuncAtiv2

FuncAtiv3

Neur4

Neur5

Input Output

3.03640.00497

1.3942

0.15561

-0.50772-2.6871

0

0

0

3.4881

0

-2.6824

0

-0.44385

-0.50824

Figura 3.3: Rede Neural 1-3-1 generalizando a função seno

Neur1

Neur2

Neur3

FuncAtiv1

FuncAtiv2

FuncAtiv3

Neur4

Neur5

Input Output

39.1251-29.54

-1.891

2.53431.3942

3.3284

20.929120.7939

6.805

5.1492

0

6.897537.45

-3.47

-24.91

13.82

0.1944

3.2169

Figura 3.4: Rede Neural 1-3-2-1 simulando a função exponencial

Estas implementações são realizadas a partir de uma mesma arquitetura, levando emconsideração blocos funcionais já alocados nos dispositivos (pré-instanciados). Contudo,observamos que, a partir da manipulação dos links lógicos (conexões entre os blocos) eparâmetros internos dos blocos, é possível obter duas arquiteturas distintas. A Figura 3.3,por exemplo, corresponde a uma rede neural do tipo 1-3-1 (uma entrada, três neurôniosna camada intermediária e uma saída). Já a Figura 3.4 corresponde a uma rede neural


cuja arquitetura é 1-3-2-1 (uma entrada, três neurônios na primeira camada intermediária,dois neurônios na segunda e uma saída). Assim, mudando os links (conexões) dos blo-cos podemos ter várias configurações de redes neurais (Figura 3.5) que podem atenderdiferentes situações. É importante ressaltar que os blocos funcionais, não precisam nec-essariamente estar no mesmo dispositivo. As interconexões (links) dos BFs podem estarem dispositivos diferentes, o que dá a característica de processamento distribuído a ar-quitetura.

Configuração 1 Configuração 2

Configuração 3 Configuração 4

Figura 3.5: Mudanças de arquitetura de redes neurais

3.2 Arquitetura dos agentesEm nossa arquitetura foram desenvolvidos três tipos de agentes como características

próprias. Agentes de Observação responsáveis por verificar se existe alguma falha naplanta, Agentes de Diagnóstico, que reconhecem que tipo de problema (falha) está acon-tecendo e os Agentes de execução que são responsáveis por corrigir a falha encontrada.A seguir detalharemos o funcionamento destes agentes.

3.2.1 Agentes de ObservaçãoOs Agentes de Observação (AO) tem como objetivo detectar anomalias na medição

de sensores ou inconsistências nos atuadores. Para isso, é necessário conhecer previa-mente o comportamento do sistema para detectar e diagnosticar falhas, pois dessa forma


temos um parâmetro de comparação sobre seu funcionamento. Ou seja, engenheiros deautomação podem associar falhas a padrões de comportamento das variáveis do sistema.Pesquisas realizadas em detecção e isolamento de falhas (FDI - Fault Detection and Iso-lation) têm utilizado algoritmos inteligentes tais como Lógica Fuzzy e Redes NeuraisArtificiais ([Korbicz & Kowal 2007], [Dexter 1995]).

Neste trabalho, os agentes de observação usam redes neurais ora para predição de de-terminado valor de medição de um dispositivo, ora para inferir o valor medido com baseem outras variáveis. Os AOs devem então aprender como predizer ou inferir o compor-tamento do sinal antes de serem alocados nos blocos funcionais dos dispositivos. Esteaprendizado é realizado no nível de supervisório, onde é feito o treinamento da rede neu-ral. Assim, os agentes de observação conhecem o comportamento esperado do sinal me-dido. Quando alocados nos dispositivos (RNA com pesos sinápticos aprendidos), os AOtentam predizer ou inferir o sinal e comparam-no com o sinal real. Caso exista uma difer-ença significativa entre os sinais o agente indica que existe um problema.

3.2.2 Agentes de DiagnósticoQuando um problema (falha) é detectado, ele deve ser corretamente diagnosticado

para garantir uma correção apropriada. O Agente de Diagnóstico, assim como o agentede observação, usa redes neurais artificiais para diagnosticar corretamente qual problemaestá ocorrendo no sistema. Esta abordagem é baseada no trabalho de Detecção e Isola-mento de falhas de Fernandes et al. (2007).

A maioria dos sistemas DDF (Detecção e Diagnóstico de Falhas) considera a com-paração de uma ou mais variáveis do sistema real com a sua respectiva variável em umsistema simulado ou inferido por uma RNA (que deve corresponder ao real). Essa com-paração é feita a partir da diferença entre a variável obtida no sistema real e a variávelgerada pela rede neural. Esta diferença é denominada resíduo. Dependendo do valordesse resíduo é possível saber que falha está ocorrendo.

O que o agente de diagnóstico faz é gerar, através de RNAs, resíduos que possamindicar uma falha. Neste caso, é realizado um treinamento da rede neural, simulando aspossíveis falhas do sistema. Uma vez treinada a saída RNA, com base nas variáveis cap-tadas nos dispositivos, é comparada com o valor real medido. Os valores de resíduos quepodem indicar os tipos de falhas irão depender dos valores que estão sendo monitorados.No próximo capítulo será mostrado um exemplo de como essa abordagem é utilizada naprática.

3.2.3 Agentes de ExecuçãoQuando um problema é detectado e diagnosticado pelos agentes de observação e diag-

nóstico respectivamente, os Agentes de Execução (AE) mudam as interconexões (sessão3.1) dos blocos funcionais para alocar um algoritmo (software sensor), geralmente umarede neural, para corrigir o problema ou a falha. A organização desse blocos determinaa aplicação utilizada pelo EA pra resolver o problema. Os AEs podem se comportar (serconfigurados) de diferentes formas, dependendo da falha apresentada.


Como já citado anteriormente, a implementação dos agentes é baseada na estruturaformada pelos blocos funcionais dos dispositivos de campo. Cada bloco funcional executaum tipo de função e diversas aplicações são implementadas pela junção de diversos blocosfuncionais. Neste primeiro exemplo (simples), a Figura 3.6 mostra uma configuraçãode blocos funcionais vista no Syscon. São através de interconexões como essas que osagentes de execução serão representados.

Input

Output

PIDOUT

OUT

IN BKCAL_IN

BKCAL_OUT

CAS_IN

Figura 3.6: Sistema simples de controle baseados baseado em blocos funcionais

Uma variável de entrada é adquirida pelo bloco funcional responsável pela leitura(Input). Este valor é processado por um algoritmo interno do bloco funcional que comparao valor de entrada com um valor de referência, criando um valor de saída, usando o blocoPID (Proportional-Integral-Derivative)2. Outro tipo de agente de execução é ilustrado naFigura 3.7. Neste caso, a estrutura formada pelos blocos funcionais representa uma filtrode ruídos baseado em uma rede neural.

Figura 3.7: Filtro de Ruídos baseado em blocos funcionais

A flexibilidade da camada de aplicação (representada pelos blocos funcionais) dofoundation fieldbus, permite diferentes implementações no nível de campo. A combi-nação de blocos aritméticos e caracterizadores produz uma configuração similar a neurôniosartificiais [Silva et al. 2006] (sessão 1.5). Assim, podemos ter diversas arquiteturas de re-des neurais gerando uma variedade de agentes de execuções diferentes.

Por exemplo: se o problema detectado é uma interferência na medição acarretada porum ruído externo, blocos funcionais dos dispositivos de campo são combinados formando

2Proporcional-Integral-Derivativo


uma rede neural que atue como filtro de ruído [Costa 2006]. Se for detectado uma perdade precisão na medição de um sensor, por exemplo, o AE pode agir como um algoritmo,também baseado em rede neural, de auto-compensação de um determinado sensor [Cagniet al. 2005].

3.3 Plataforma de Agentes em Ambientes Foundation Field-bus

A arquitetura proposta é composta de um sistema multiagente que possui rotinas deinspeção em dados coletados dos dispositivos de campo da planta. O objetivo é fazer queos agentes monitorem os dispositivos de campo, investigando inconsistências que podemimpedir o correto funcionamento do processo produtivo, tais como: perda de precisão,ruídos externos, interpretação de alarmes, etc. Durante o processo, os agentes realizamtarefas para analisar e corrigir problemas usando estratégias de software sensor, algumasdelas mostradas na Seção 2.5.

A Figura 3.8 mostra a arquitetura proposta, composta de agentes de observação, di-agnóstico e execução. O Agente de Observação (AO) é responsável por monitorar osdispositivos de campo, verificando inconsistências e falhas. O Agente de Diagnóstico(AD) procura identificar o tipo de problema detectado pelo AO. Após o problema seridentificado, o Agente de Execução (AE) tenta corrigi-lo, implementando um algoritmointeligente (software sensor). Além dos agentes, outro componente nesta arquitetura é acamada de software que permite que os agente possam interagir com o modelo FoundationFieldbus (Camada LABVIEW/FIPA).

Utilizamos a linguagem G3 e o ambiente LABVIEW4 para desenvolver agentes [Polaków& Metzger 2007] no padrão FIPA. Esta linguagem dispensa o uso de qualquer formal-ismo sintático, típico das linguagens de programação convencional, para a construção docódigo-fonte. Sua representação gráfica do algoritmo e a depuração interativa oferecidas,permitem que a construção de programas seja feita de forma mais intuitiva.

A principal razão para o uso do padrão FIPA é poder agregar outros agentes com omesmo padrão na arquitetura. Também é utilizada a interface OPC, de forma similarao trabalho de Seilonen, Appelqvist & Koskinen (2002), para integrar os agentes com acamada LABVIEW/FIPA. Esta camada permite a comunicação com os dispositivo atravésdo padrão OPC.

A estrutura de um agente pode ser vista na Figura 3.9. O aprendizado dos agentes(treinamento das redes neurais) ocorre no nível mais alto (supervisório) que se comu-nica com os dispositivos através da camada LABVIEW/FIPA. O gateway (DFI) é respon-sável (fisicamente) por estabelecer esta comunicação. O aprendizado é implementadosnas máquinas supervisórias como parte do agente.

A ação do agente é realizada no nível de controle (blocos funcionais dos dispositivos).

3A linguagem de programação que permite implementar os mesmos tipos de estruturas de programaçãoconvencional usando blocos gráficos.

4LabVIEW (acrónimo para Laboratory Virtual Instrument Engineering Workbench) é um ambiente deprogramação e compilação a linguagem G.


Repositório de InformaçõesCliente OPC

Agente deObservação


Agente deExecução

Pump

Reservoir

FF Devices

Foundation FieldBus

ConversionCircuits

mV/4-20mA

Tank 1

Tank 2

Processo a ser Controlado

Rede Ethernet

Interface Foundation Fieldbus

Camada LABVIEW/FIPA

Sistema Supervisório

Outros Processos

Figura 3.8: Ambiente multiagente proposto

As interconexões dos blocos funcionais formam redes neurais que possibilita controlar umdeterminado processo. Os agentes da arquitetura são implementados como RNAs usadasem alguns momentos para monitorar dispositivos (agentes de observação), para diagnos-ticar problemas (agentes de diagnóstico) e em outros para corrigir falhas (agentes de exe-cução). É importante ressaltar que a escolha de uma arquitetura de rede neural é baseadana capacidade de processamento dos dispositivos. Sendo assim, não é possível alocar re-des neurais com um grande número de neurônios no mesmo dispositivo pois eles possuempoder de processamento limitado. Além disso, a rede neural artificial (RNA) alocadanos blocos funcionais dos dispositivos de campo não deve afetar o controle do processopois arquiteturas de RNAs complexas podem influenciar no processo controlado quandosão compartilhados blocos funcionais entre a RNA e aplicação de controle. Em nossosexperimentos foram testadas diversas arquitetura de RNAs com quantidade maiores deneurônios e camadas. Entretanto, nos agentes desenvolvidos, pequenas arquiteturas ob-tiveram desempenho satisfatório em detectar, diagnosticar e corrigir os problemas.

3.4 Aprendizagem dos AgentesSendo uma rede neural, os agentes passam por duas fases. Eles devem aprender

(treinamento da rede neural) e agir (uso da rede neural treinada). Estes agentes aprendemsobre o funcionamento do dispositivo. Por exemplo, os agentes de observação aprendemcomo predizer o comportamento (valores de saída normais) de um atuador e os agentes


Gateway

Nível deSupervisão

Aprendizado

Ação

Nível deControle

Processo a ser controlado

Camada FIPA/FieldBus

Figura 3.9: Anatomia dos agentes

de execução aprendem como compensar um ruído externo que atrapalhe a medição de umsensor. Este treinamento é realizado no nível supervisório e as informações dos disposi-tivos são captadas através da camada LABVIEW/FIPA.

Os agentes de observação armazenam os dados coletados dos dispositivos, que poste-riormente serão utilizados para o treinamento de uma RNA. As informações aprendidasapós o treinamento da rede (pesos da RNA) são armazenadas no repositório de infor-mações (RI) para serem utilizadas na fase de ação dos agentes. Para realizar o treina-mento da rede neural, utilizamos uma ferramenta desenvolvida em LABVIEW chamadaaNETka [Zurek et al. 2009], que foi integrada à arquitetura proposta. Este módulo é capazde manipular uma rede neural com até 8 camadas e 256 neurônios por camada, limitadopela capacidade de memória do computador. A aNETka trabalha com funções de ati-vação linear, tangente sigmóide e tangente hiperbólica e com arquiteturas feed-foward eback-propagation.

3.5 Ação dos AgentesA sequencia de execução da arquitetura proposta é mostrada na Figura 3.10. Os

agentes de observação e execução aprendem o funcionamento padrão do dispositivo (1).O AO pode aprender como inferir a medição de um determinado dispositivo através deoutras variáveis do sistema, por exemplo. Neste caso é treinada uma rede neural cujasentradas são outras variáveis do processo e a saída é o valor medido pelo sensor moni-


torado. Além isso, o AO pode aprender como predizer valores de medição de um deter-minado sensor com base nos valores medidos anteriormente [Machado et al. 2008c]. Jáos agentes de execução aprendem (1), por exemplo, como compensar um ruído externoem um determinado dispositivo [Costa et al. 2003] (Seção 2.5).

Fase de Aprendizado

Sinal de Entrada

Agente de Diagnóstico

4Sinal deSaída

8

Repositório de Informações

2

65

Fase de Ação

Agente de Observação

3

Agente de Observação

1

Agente de Execução

7

Agente de Execução

1

Figura 3.10: Execução dos Agentes

As informações aprendidas (pesos da rede neural) são armazenadas no repositório deinformações (RI) (2). O agente de observação usa essas informações para monitorar osdispositivos (3). Por exemplo, a rede neural já treinada (5) recebe como entradas valoresde outras variáveis do sistema. Como saída teríamos um valor de medida inferido pelaRNA. Esse valor é comparado com o valor real que está sendo medido pelo dispositivo.Havendo uma diferença significante entre esses valores, o AO indica uma possível falha.Quando um problema ou falha é detectado, ele deve ser diagnosticado corretamente paragarantir uma correção apropriada (4). O agente de diagnóstico (rede neural já treinada)identifica o tipo de problema detectado pelo AO [Fernandes et al. 2007] (Seção 2.5). Tãologo o problema seja detectado (pelo AO) e identificado (pelo agente de diagnóstico) (6),o agente de execução decide a configuração para resolver o problema. O AE aloca umaconfiguração de blocos funcionais com base em uma configuração macro já configurada(Seção 3.1) nos dispositivos foundation fieldbus para resolver o problema (7). Os agentesde execução são, de fato, blocos funcionais instanciados nos dispositivos formando umarede neural. A organização desses dispositivos caracterizam a forma de como (que algo-ritmo de controle) os AE irão solucionar o problema. Ao final da execução, temos umsinal (ou saída de um dispositivo) livre de erro (8).


3.6 Camada LABVIEW/FIPAA Figura 3.11 mostra o framework de implementação da arquitetura em LABVIEW.

Além dos agentes (AO, AD, AE), existem ainda o módulo de comunicação, o módulo deaprendizagem e o repositório de informações. O agente de execução representado nesteframework é o controle para alocar a rede neural nos blocos funcionais. O AE é a própriarede neural alocada nos blocos funcionais dos dispositivos de campo. Os módulos decomunicação são responsáveis por traduzir as mensagens no formato FIPA-ACL [Feng &Lu 2003], para os padrões OPC e LABVIEW.

Figura 3.11: Esquema de implementação de agentes em LABVIEW

O módulo de aprendizagem executa o treinamento da rede neural baseado nos dis-positivos monitorado pelo AO. Conforme apontamos anteriormente, os pesos da RNAadquiridos no treinamento são armazenados no repositório de informações. Na fase deexecução o módulo de aprendizagem provê aos agentes a estrutura da rede neural (quan-tidade de neurônios, camadas e pesos sinápticos). Existe ainda, uma interface de configu-ração que permite aos supervisores configurar o comportamento dos agentes e monitoraros dispositivos e o processo.

3.7 Considerações FinaisNeste capítulo apresentamos a arquitetura multiagente, mostrando como os compo-

nentes desta arquitetura são projetados e como interagem. Além disso, mostramos tam-bém uma estratégia para alocação de blocos funcionais que permite mudar, em tempo deexecução, a aplicação alocada nos dispositivos de campo, independente das limitaçõesimpostas pela arquitetura foundation fieldbus.


Acreditamos que essa mudança dinâmica de controle aliada aos aplicativos que podemser formados através do uso de rede neurais, tornam o ambiente fieldbus propício paraimplementação de agentes. As experiências que serão mostradas no próximo capítulocorroboram com a aplicabilidade da arquitetura multiagente, proposta em um ambientede rede industrial real.

Capítulo 4

Testes e Experiências

Um modelo de processo automatizado foi implementado para testar a viabilidade daarquitetura proposta. Este ambiente de teste consiste em uma aplicação que simula falhas,um sistema baseado em foundation fieldbus e o protótipo da arquitetura de agentes. Oprocesso de teste possui características similares a processo industrial, porém em escalareduzida.

O esquema da Figura 4.1 mostra que a planta é composta por dois tanques em cascata.A água que sai pelo orifício do tanque 1 cai dentro do tanque 2. Este, por sua vez,também tem um orifício onde a água cai diretamente para o reservatório. Uma bombaé responsável por levar a água do reservatório para o tanque 1. Em cada tanque existeum sensor de pressão Foundation Fieldbus (FF), usado para medir a altura dos níveisde líquido correspondentes, ligados à rede Fieldbus. Além dos sensores de pressão, umconversor (FF/loop de corrente 4 a 20 mA) é usado para injetar sinais na bomba d’águaatravés de um atuador.

A rede industrial Foundation Fieldbus é ligada a um computador supervisório atravésde interfaces de rede Ethernet. A partir deste computador é realizado todo o processo deconfiguração dos dispositivos, e o posterior monitoramento. O sistema transmite sinaispara a bomba permitindo o fluxo de água nos tanque 1 e assim manter o nível de águaem ambos os tanques. Este computador ainda executa o sistema de controle dos agentese simulação de falhas. Este último (cliente OPC) transmite sinais (linha pontilhada) aosdispositivos para simular problemas na planta. A Figura 4.2 mostra a planta montada noLAMP (Laboratório de Análise e Medição de Petróleo do DCA-UFRN).

4.1 Estrutura de FuncionamentoConforme mostrado na Figura 3.9, a anatomia dos agentes é composta de duas partes

(aprendizagem e ação) onde cada uma delas estão em níveis diferentes da planta (nível desupervisão e nível de controle). Para dar suporte as duas partes, foram criadas em cadanível uma estrutura para dar suporte ao funcionamento dos agentes.

CAPÍTULO 4. TESTES E EXPERIÊNCIAS 47

Bomba

Reservatório

Dispositivos FF

Foundation FieldBus

Rede Ethernet

Tanque 1

Tanque 2

Configuração eSupervisório

Circuitos deConversãomV/4-20mA

DFI(Interface FF/Ethernet)

ClienteOPC

Figura 4.1: Esquema da planta utilizada nos experimentos

4.1.1 Nível SupervisórioNo nível de supervisão foi criado um sistema, baseado na linguagem G, para monitorar

o processo e as atividades dos agentes que estão no nível de dispositivos. Além disso, osistema desenvolvido, permite forçar ou simular falhas no processo a fim de observar ofuncionamento da arquitetura. A Figura 4.3 mostra a tela principal do sistema.

Esta tela é dividida em três colunas. No lado esquerdo, temos a representação gráficada altura dos níveis dos tanques e do reservatório (em cm). Na parte central, temos umconjunto de opções (Simulate Problems), onde é possível selecionar um problema a sersimulado na planta. Vale ressaltar que nem todas as falhas são simuladas por esse soft-ware. Alguns problemas como entupimento do tanque 1 (Clogging Tank 1) são forçadospor alterações na própria planta. Neste caso, é mudado o diâmetro do orifício de escoa-mento do tanque. Ao selecionarmos a opção Ruído na Medição do Tanque 1 (Noise inTank 1 Measurement), por exemplo, é enviado (via OPC) um sinal de ruído para a plantaque será misturado ao valor medido pelo sensor do tanque 1.

Logo abaixo da seleção de problemas temos o controle de tensão da bomba, seguidodos botões do módulo de treinamento (Training Module) e depuração (Debug). O mó-dulo de depuração permite observar valores de outras variáveis que são influenciadas pelaação dos agentes, permitido assim uma melhor análise do desempenho da arquitetura. Omódulo de treinamento será visto com mais detalhes na sessão 4.2. Por fim, na parte in-ferior da coluna central temos uma chave que alterna entre a medição real e simulada dos


Rede Fieldbus

Sistema de Níveis DFI

Figura 4.2: Planta utilizada nos experimentos

tanques e os botões para observar, em um gráfico, o ruído adicionado a um sinal medido(Show Noise Chat). Também consta um led verde indicando a ação de um agente (ControlAgent).

Na coluna direita estão os itens que permitem monitorar o funcionamento dos agentes.O primeiro deles é o Agente de Observação (Observation Agent). Três valores podemser monitorados nesta coluna. O Threshold, L1(Pred) e L2(Pred). Os dois últimos sãovalores de dois agentes de observação (redes neurais instanciadas nos blocos funcionais)que inferem os valores dos dois tanques. L1(Pred) é inferido através do valor medido dotanque 2 e a tensão aplicada à bomba. Já L2(Pred) é inferido através do valor medido dotanque 1 e a tensão. Esse valores servem como referência de funcionamento normal dostanques, uma vez que a RNA responsável pela inferência foi treinada em uma situaçãolivre de falhas.

Quando a diferença entre os dois valores (inferido e medido) passar do limiar (Thresh-old) em qualquer um dos tanques, o agente de observação envia uma mensagem ao agentede diagnóstico, solicitando que este indique que problema está acontecendo. O led Acti-vate indica que uma nova configuração de rede neural está sendo carregada para os blocosfuncionais dos dispositivos de campo, após um novo treinamento.

Os indicadores do agente de diagnóstico (Diagnostic Agent) ficam logo abaixo doagente de observação. Conforme mostrado na Seção 3.2.2, os AD são baseados no sistemade detecção e isolamento de falhas de Fernandes et al. (2007), portanto sua estrutura é


Figura 4.3: Tela do Sistema de Monitoramento

formada por três redes neurais (Figura 2.10). A primeira que infere o valor do tanque1 (L1’) e a segunda para inferir o valor do tanque 2 (L2’). A terceira RNA indicaráqual tipo de falha foi detectada pelo agente de observação, com base nos resíduos R1e R2 dos tanques 1 e 2, respectivamente. Existem também duas caixas de valores deproblema (Problem), uma numérica e outra de texto, mostrando ao usuário que problemaestá acontecendo. Quando a falha for diagnosticada, o AD envia uma mensagem ao agentede execução indicando o problema que está ocorrendo para que o AE se encarregue decorrigi-la.

Vale ressaltar que como os sinais medidos são muito suscetíveis a variações, não éprudente ativar o agente de execução assim que o AD diagnosticar uma falha. Para que setenha certeza do diagnóstico, foi implementado no AD uma contagem de tipos de falhas.Isso siginifica que o AD só enviará a mensagem de diagnóstico ao AE depois que a falhaacontecer um certo número de vezes. Isso pode ser visto na tela que se abre ao pressionarno botão debug (depuração) na coluna central (Figura 4.4).

Na sequencia de controles da coluna da direita, temos o led que indica o funciona-


Figura 4.4: Tela de Depuração (Debug)

mento do agente de execução e logo abaixo, o led que indica o funcionamento do AEespecífico para auto-correção (Auto-Correction Agent). Todos os agentes de execução es-tão instanciados nos blocos funcionais dos dispositivos de campo e se baseiam em umaúnica rede neural que muda sua configuração dependendo do problema a ser solucionado.Por fim, temos o botão que zera a contagem de tempo (Reset Time) (para detecção dadescalibração) e o botão que permite acompanhar graficamente o andamento da descali-bração de um sensor através do sinal medido (Show Decalibration Chat).

4.1.2 Nível FieldbusA estrutura que dá suporte para arquitetura no nível de campo (fieldbus) é composta

por três redes neurais, alocadas nos blocos funcionais dos dispositivos de campo. Emnossa implementação essas três RNAs correspondem a dois agentes de observação e umagente de execução. Ou seja, a primeira infere o valor do nível do tanque 1 (4.5), asegunda o valor do nível do tanque 2 (4.6) e a última muda sua arquitetura de acordo como tipo de AE alocado.

É importante destacar que apesar de estarem alocadas "exclusivamente"para os agentesde observação, nada impede que em outras plantas, ou outras situações essas redes neuraispossam ser utilizadas para outros fins. Inclusive usadas como outros agentes de execuçãoou diagnóstico. Por esse motivo, as redes foram projetadas para serem utilizadas de difer-entes formas, com arquiteturas maiores.

Podemos perceber que, tanto a rede da Figura 4.5, quanto a da Figura 4.6 possuem3 entradas na primeira camada; 5 neurônios na camada intermediária e um na camadade saída (3-5-1). Nos exemplos mostrados nessas figuras somente duas entradas sãoaproveitadas (2-5-1). Na Figura 4.5, as entradas são o nível do tanque 2, representadopelo bloco LD-302-1-AI e a tensão da bomba (FI-302-1-CONST). A saída (OUT-3) é ovalor inferido do nível do tanque 1. Já na Figura 4.6, as entradas são o nível do tanque 1,


representado pelo bloco LD-302-2-AI e a tensão da bomba (FI-302-1-CONST). A saída(OUT-2) é o valor inferido do nível do tanque 2.

Figura 4.5: Rede Neural em blocos funcionais representada graficamente no Syscon -Agentes de Observação

Figura 4.6: Rede Neural em blocos funcionais representada graficamente no Syscon -Agentes de Observação

A outra rede neural que dá suporte a arquitetura proposta é a da Figura 4.7. Ela servea todos os agentes de execução. Neste caso, é utilizado a estratégia de alocação dinâmica


de blocos funcionais, apresentado na sessão 3.1. Ou seja, os valores das interconexõesdos blocos e os pesos sinápticos mudam para que a RNA possa alocar uma aplicação quecorrija a falha detectada pelo agente de observação.

Figura 4.7: Rede Neural em blocos funcionais representada graficamente no Syscon -Agente de Execução

Pela Figura 4.7, observamos que a arquitetura da rede neural é do mesmo tipo dasredes mostradas anteriormente. A diferença é que ela possui duas saídas (3-5-2). Pode-mos perceber que, conectada as duas primeiras entradas, existem diversos blocos querepresentam diferentes valores medidos. Dependendo da aplicação alocada no agente deexecução os links são mudados, selecionando a entrada apropriada. Notamos ainda queuma terceira entrada está ociosa (IN3) o que permite a expansão da rede para alocação deoutras aplicações. Nas próximas sessões especificaremos os blocos funcionais conectadosa estas entradas.

4.2 Treinamento dos AgentesPara poder monitorar, diagnosticar e corrigir o problema corretamente, os agentes

baseados em redes neurais têm que passar pelo processo de treinamento, a fim de aprendero correto funcionamento da planta. Em nossa arquitetura, o treinamento é feito duasfases distintas: captação dos valores das variáveis da planta e o treinamento da RNApropriamente dito.

Na primeira fase, uma base de dados contendo os valores das variáveis são coletadospara o treinamento. Na Figura 4.8 vemos a tela do módulo de treinamento (trainingmodule). Ao selecionarmos o led do treinamento do agente de observação para o tanque1 (Record Train File T1), um arquivo é gerado com dados coletados do valor do nível dotanque 2 (L2), tensão aplicada à bomba (T) e do nível do tanque 1 (L1). As duas primeirasvariáveis (L2 e T) serão as entradas da rede neural e a última (L1) é a saída da rede neural.Um exemplo desse arquivo pode ser visto na Figura 4.9 A. Assim, será treinada uma rede


neural que infere o nível do tanque 1 (T1) a partir dos valores do tanque 2 (L2) e a tesãoaplicada a bomba (T). De modo similar ao treinamento do agente de observação do tanque1 é realizado o treinamento do AO do tanque 2 (Record Train File T2) que gera um arquivomostrado na Figura 4.9 B.

Figura 4.8: Tela de treinamento

A B

Figura 4.9: Parte do arquivo de treinamento dos agentes de observação

O outro led presente na tela do módulo de treinamento é o de aprendizagem de ruído(Learning Noise) que é o treina o agente de execução para remover o ruído na medição


do tanque 1. De forma análoga aos agentes de observação é gerado um conjunto detreinamento, baseado em variáveis captadas dos sensores dos dispositivos (Figura 4.10A). Para isso, é adicionado ao valor medido, através do cliente OPC, um ruído que variadentro de um determinado intervalo. A rede neural implementada para o filtro é a mesmaapresentada anteriormente, na Figura 2.8 [Costa 2006]. Portanto, ela precisa ser treinadacom as entradas de duas medidas do nível do tanque 1, captadas pelos sensores (Sm1 eSm2) e com duas saídas: sinal sem ruído (S) e o ruído adicionado (R).

A B

Figura 4.10: Parte do arquivo de treinamento dos agentes de execução

No treinamento do agente de execução responsável pela auto-calibração (TrainingDecalibration), também é gerado um arquivo de treinamento (Figura 4.10 B) com basena rede neural mostrada na Figura 2.11 [Cagni et al. 2005]. Neste caso, no decorrer dotempo, o sensor que mede o nível do tanque 1 perde a precisão, indicando cada vez maisum nível inferior do que realmente se apresenta no tanque. Para coletar os dados detreinamento é forçada a perda de precisão. A aplicação simula gradativamente a perdatotal da medição em um intervalo de 10 minutos.

São coletados como valores de entrada, o valor do nível do tanque 1, que apresentadescalibração (Sd) e o tempo (Time). Como saída da rede, temos o sinal que deveria estarsendo apresentado caso não houvesse a descalibração (Sc). Esse último valor é oriundode um sensor cablibrado chamado de sensor comum (sessão 2.5).

Após a fase de coleta de dados, os arquivos serão submetidos aos treinamentos daredes neurais. Nesta segunda fase é utilizada uma ferramenta desenvolvida no ambienteLABVIEW, chamada aNETKa [Zurek et al. 2009], mostrada na Figura 4.11. Apesar defuncionar de forma transparente para o usuário ou supervisor da rede, é possível obser-var se necessário, através da tela principal do aNETka, parâmetros do treinamento comotaxa de aprendizado (learning rate), correlação (train correlation), erro médio quadrado(RMS), entre outros. Além de permitir visualizar graficamente o andamento do treina-mento.

De forma similar aos demais, o agente de diagnóstico também passa pela fase detreinamento (Record Train file DA - Figura 4.8). Como já dito anteriormente, os AD são


Figura 4.11: Tela de treinamento de redes neurais do aNETka

baseados no sistema de detecção e isolamento de falhas de Fernandes et al. (2007). Logo,são necessários treinamentos de três redes neurais

Em uma primeira etapa, são treinadas as redes neurais para estimar as medidas nor-mais (livres de problemas) dos níveis dos tanques (L1’ e L2’ da Figura 4.3). Para estimaro L1’, temos como entrada o nível do tanque 1 no estado anterior (L_Ant), a tensão apli-cada a bomba no estado anterior (V_Ant) e a tensão atual (V). Como saída da rede temoso nível do tanque no momento atual (Nível). Parte do arquivo de treinamento para L1’está mostrado na Figura 4.12 A. Com isso, o agente de diagnóstico estima a medida donível do tanque de acordo com o estado anterior.

A B

Figura 4.12: Parte do arquivo de treinamento dos agentes de diagnóstico

Já para estimar o nível do tanque 2 (L2’) é treinada uma rede neural, que tem como


entradas o nível do tanque 1 em um estado anterior (L1_Ant) e o nível do tanque 2 emum estado anterior (L2_Ant). A saída desta rede é o nível do tanque 2 no momento atual(L2). Parte deste arquivo de treinamento é mostrado na Figura 4.12 B.

Para concluir o treinamento do agente de diagnóstico é necessário treinar uma ter-ceira RNA que tem como objetivo estimar um diagnóstico de falha na planta a partir dosresíduos calculados sobre os níveis (estimados e real) dos tanques. Os resíduos do tan-ques (R1 e R2) são calculados a partir da diferença entre as medições reais e os valoresestimados (L1’ e L2’). A estratégia adotada é forçar (simular) esses problemas (colunacentral da tela de monitoramento), guardar os resíduos para cada problema e treinar umarede neural que possa detectar, a partir destes resíduos, uma falha. Para isso é utilizada aTabela 4.1.

Tabela 4.1: 8 possíveis falhas e seus respectivos resíduosFalha Descrição R1 R2

Ausência de Falha 0 01 Entupimento Tanque 1 - -2 Vazamento do Tanque 1

para fora- 0

3 Vazamento do Tanque 1para Tanque 2

Não Observado Não Observado

4 Vazamento Tanque 2 0 -5 Ruído no tanque 1 + 06 Ruído no tanque 2 0 +7 Erro de Leitura do tanque

1- +

8 Erro de Leitura do tanque2

+ -

Uma amostra do arquivo de treinamento da rede neural do agente de diagnóstico émostrada na Figura 4.13. Ao final do treinamento a rede neural pode estimar qual falha osistema apresenta com base nos resíduos. É importante ressaltar que nem sempre os val-ores positivos ou negativos são respeitados no diagnóstico. Considera-se a aproximaçãode valores feita pela rede neural.

Ao fim do treinamento são gerados arquivos como os da Figura 4.14 que contém todasas informações necessárias para instanciar a rede neural nos dispositivos de campo, taiscomo quantidade de camadas, pesos sinápticos, bias, quantidade de amostra do conjuntode treinamento e variáveis de entrada e de saída. Todos os arquivos ficam armazenados norepositório de informação. Além desses arquivos, informações como configurações dosblocos funcionais instanciados nos dispositivos de campo, estão disponíveis para seremusados pelos agentes. Vale ressaltar que o repositório pode estar distribuído em outrasmáquinas do sistema, evitando que se criem gargalos de comunicação que atrapalhem ofuncionamento da arquitetura.


Figura 4.13: Parte do arquivo de treinamento do agente de diagnóstico

Figura 4.14: Exemplo de arquivo de configuração da rede neural para o agente de obser-vação (tanque 2)

4.3 Agentes de ObservaçãoApós a fase de treinamento, os agentes de observações são instanciados nos blocos

funcionais dos dispositivos de campo. Esses agentes usam a arquitetura mostrada nasfiguras 4.5 e 4.6, mas não utilizam todos os blocos desta configuração, conforme mostradona Seção 4.1.2. Usando a metodologia de alocação dinâmica de blocos funcionais (Seção2.1), as conexões entres os blocos, pesos sinápticos e bias são reajustados para formaruma rede-neural (2-5-1), permitindo que os agentes de observação infiram o valor demedida normal de cada tanque.


Caso a medida do sensor do nível do tanque ultrapasse o limite (threshold), para maisou para menos do que foi estabelecido pelo operador, o agente de observação envia umamensagem para o agente de diagnóstico, fazendo com que ele indique qual falha estáacontecendo na planta.

4.4 Agente de DiagnósticoO agente de diagnóstico é composto por três redes neurais. Por isso e por a pouca

disponibilidade de blocos funcionais em na planta em questão, os AD são implementadosnos computadores do nível supervisório. Os pesos sinápticos e bias calculados na fasede treinamento são utilizados em módulos do aNETka (Figura 4.15). Assim, ao recebera mensagem do agente de observação o AD usa as três redes neurais já treinadas paraidentificar o problema e enviar uma mensagem ao agente de execução para corrigir afalha.

Figura 4.15: Código de execução em linguagem G do agente de diagnóstico

Caso exista uma falha de perda de sinal no sensor de medição do tanque 1, o AD éavisado pelo AO e são calculados os resíduos, conforme mostrado na Figura 4.16. Nestecaso, podemos observar o valor de R1 negativo (-3,78215) e R2 positivo (1,37493) indi-cando (pela Tabela 4.1) um erro de leitura (Reading Error Tank 1). É importante ressaltarque, mesmo estando alocado nível de supervisão, nada impede que o AD seja implemen-tado nos blocos funcionais dos dispositivos de campo. Para isto, basta que existam blocosdisponíveis para alocação das três redes neurais. Isso tornaria a arquitetura proposta com-pletamente independente do nível de supervisão.

Em nossa planta, podem ocorrer quatro tipos de problemas que requerem 4 tipos deação distintas do agente de execução: perda de sinal do sensor de medição, ruído no sinalde medição, auto-calibração e o controle de nível (entupimento e vazamento). A seguir,veremos como o agente de execução se comporta em cada um deles.


Figura 4.16: Parte da tela de monitoramento que mostra os agentes de observação e diag-nóstico

4.5 Agente de Execução - Teste 1: Perda de SinalQuando o agente de diagnóstico detectar a perda do sinal de medição do tanque 1 (R1

negativo e R2 positivo), por exemplo, imediatamente o agente de execução começa suasatividades. A primeira delas é instanciar nos blocos funcionais dos dispositivos de campoa rede neural que irá solucionar o problema, usando a estratégia de alocação dinâmica deblocos funcionais. Ou seja, são alocados os pesos e bias que após o treinamento estãodisponíveis no repositório de informação e ajustados os links da configuração já previa-mente instancida nos blocos funcionais (Figura 4.7). Isso permite alocar a rede neural queirá inferir os valores para a medição do tanque 1, substituindo o sensor que teve o sinalperdido.

A Figura 4.17 mostra em destaque os blocos utilizados para o agente de execução.Esta rede infere o valor do tanque 1 (sinal de medição que foi perdido) a partir da tensãoaplicada a bomba e do nível do tanque 2. Portanto, temos como entrada os blocos LD-302-1-AI, responsável pela medição do nível do tanque 2 e LD-302-1-CONST, que indica atensão aplicada a bomba. Sendo assim, são utilizados dois blocos de entrada (IN1 e IN2),cinco blocos aritméticos (W11 até W15), três blocos caracterizadores (FATIV1, FATIV2e FATIV3) e na camada de saída, que utiliza uma função linear, dois aritméticos (W21 eW22) e um bloco de saída (OUT).

É importante ressaltar que a ação deste agente é independente da aplicação do nível desupervisão. Isso permite, de forma transparente para o usuário, que outros sistemas quesupervisionam esta planta tenham acesso ao valor inferido pelo agente para o tanque 1. A


Figura 4.17: Configuração de blocos funcionais alocados para o agente de execução -Inferência do nível do tanque 1

configuração permanecerá nos dispositivos até que o sensor seja reparado ou substituído.

4.6 Agente de Execução - Teste 2: RuídoOutro problema detectado pelo agente de diagnóstico é ruído no sinal de medição

do nível dos tanques. Neste caso, um ruído de intervalo limitado é adicionado ao valormedido pelo sensor do tanque 1. Para extrair ruído foi utilizado o algoritmo FastICA[Costa 2006] (Figura 2.8) sendo necessária a presença de um segundo sensor que tambémtem adicionado à sua medida um ruído de mesma amplitude ao adicionado ao primeirosensor.

Após o ruído ser detectado pelo agente de diagnóstico através dos resíduos (R1 pos-itivo e R2 próximo a 0), uma rede neural (FastICA) é instanciada (ajuste de valores depesos sinápticos, bias e links) nos blocos funcionais dos dispositivos de campo, a par-tir da configuração já previamente alocada nos blocos funcionais (Figura 4.7). Isso fazcom que o agente de execução passe a filtrar o ruído encontrado no sensor. A Figura4.18 mostra em destaque os blocos funcionais alocados para o AE que remove o ruído dosensor.

Temos como entrada os blocos Ruído, que é o valor medido pelo sensor 1 mais oruído e AUX, que indica o valor medido do nível do tanque 1 pelo sensor 2 mais o ruído.Sendo assim, são utilizados dois blocos de entrada (IN1 e IN2), cinco blocos aritméticos(W11 até W15), três blocos caracterizadores (FATIV1, FATIV2 e FATIV3) e na camadade saída, que utiliza uma função linear, quatro blocos aritméticos (W21, W22, W23 eW24) e dois blocos de saída. O bloco OUT terá o valor do sinal sem ruído e o blocoOUTb terá como saída o ruído retirado do sensor.

O valor do sensor com ruído que mede o nível do tanque 1 é substituído pelo valor


Figura 4.18: Configuração de blocos funcionais alocados para o agente de execução -Filtro de ruído

de saída do bloco OUT. Dessa forma teremos, de forma transparente para o usuário ousupervisor, um valor para o nível do tanque sem ruído (filtrado). Este agente permaneceráem execução até que a fonte de ruído tenha sido removida. Na Figura 4.19, podemos ver ográfico com os sinais adquiridos na planta. Em verde (Predicted Signal) temos o sinal quedeveria estar sendo medido no momento. Este sinal é inferido pelo agente de observaçãoa partir do sinal medido do nível do tanque 2 e a tensão aplicada a bomba.

Em preto, observamos o sinal de medida do nível do tanque 1 acrescentado o ruído(Noisy Signal). E em vermelho, temos o sinal filtrado (Compensate Signal), onde pode-mos ver a aproximação dele com o sinal que deveria estar sendo medido no momento.

4.7 Agente de Execução - Teste 3: Auto-CalibraçãoMesmo sem fazer parte do conjunto de possíveis falhas mostrado na Tabela 4.1, o

agente de diagnóstico é capaz de detectar a perda de calibração de um sensor. Se depoisde um certo tempo a diferença entre o valor medido do nível de um tanque (no casotanque 1) e o valor de um sensor padrão ultrapassar um limite pré-estabelecido o agentede execução, que realiza a auto-compensação, entra em funcionamento.

O tempo em questão é o tempo de garantia indicado pelo fabricante do dispositivo,onde não há perda de calibração. Em nosso exemplo, por questão praticidade, esse tempofoi estipulado em 10 minutos. Ou seja, se em dez minutos, a contar do inicio do moni-toramento do nível dos tanques, houver diferença significativa (indicada pelos operadoresda planta) entre os sinais do sensor do tanque 1 e o sinal de medição do sensor padrão, osinal será compensado.

O esquema de auto-compensação que foi utilizado é mostrado na Figura 2.11. Dessaforma, uma rede neural será alocada nos blocos funcionais para realizar o processo de


Figura 4.19: Gráfico com de sinais normal, com ruído e filtrado

compensação do sinal. Com base nos valores adquiridos na fase de treinamento e ar-mazenados no repositório de informações, temos a rede neural da Figura 4.20 alocadanos blocos funcionais. Em destaque os blocos utilizados para auto-compensação.

Figura 4.20: Configuração de blocos funcionais alocados para o agente de execução -Filtro de ruído

Assim como as configurações mostradas anteriormente, temos duas entradas IN1 e


IN2 que recebem valores dos blocos LD-302-2-AI, que é responsável pela medição donível do tanque 1 e o bloco Tempo que indica o tempo de descalibração decorrido. Nacamada intermediária temos cinco blocos aritméticos (W11 até W15), três blocos carac-terizadores (FATIV1, FATIV2 e FATIV3) e na camada de saída, que utiliza uma funçãolinear, dois blocos aritméticos (W21 e W22) e o bloco de OUT. Na saída do bloco OUTteremos o valor compensado do nível do tanque. Nesta configuração existe ainda o blocoDiff, que faz a diferença entre o valor compensado e o valor de um dispositivo padrão(sem descalibração). Essa diferença, chamada auto-validação [Cagni et al. 2005], é uti-lizada para verificar numericamente o quanto a auto-calibração está eficiente. A Figura4.21 mostra o gráfico de auto-compensação.

Figura 4.21: Gráfico de auto-compensação

Assinalado de preto temos o gráfico que representa a medição do sensor descalibrado(Measured Signal). Notamos, que ao passar do tempo, o sinal sofre uma degradação namedição. Em vermelho temos o sinal de um sensor padrão (Default Signal). Na ausênciade outro sensor do mesmo tipo, este sinal é inferido pelo agente de observação a partirdo sinal medido do nível do tanque 2 e a tensão aplicada a bomba. Na cor verde temoso sinal compensado pelo agente de execução. Como nos outros casos, o sinal do sensordescalibrado é substituído pelo sinal de saída da rede neural. E assim persistirá até que osensor seja cabilbrado novamente.


Esta tela permite que o operador veja outras três informações no canto superior es-querdo. A primeira é o erro estimado (Estimated Error), que é a diferença entre o sinalmedido (descalibrado) e o sinal compensado. Em seguida, temos o tempo (Time(sec))decorrido (em segundos) desde do início da ação do agente de execução. Este tempo édiferente do mostrado no eixo X do gráfico, pois este último refere-se ao tempo total damedição do sensor (início do funcionamento da planta). Por fim, temos o valor do errodo sistema (System Error) que é fornecido pelo bloco Diff. Como já mencionado ante-riormente, é a diferença entre o valor compensado e o valor de um dispositivo padrão,permitindo verificar se o agente de execução está compensando corretamente o valordescalibrado. Quanto mais próximo a zero estiver o valor do erro do sistema, melhorestá sendo a compensação.

4.8 Agente de Execução - Teste 4: Controle de tensãoOutro processo moderado pelo agente de execução é o controle do nível do tanque,

que impede transbordamento do fluido. Novamente uma rede neural é utilizada, pararegular a tensão da bomba de modo a impedir que o tanque transborde. Para o controledo tanque 1, uma RNA é previamente treinada utilizando como entrada o nível do tanque2 e a tensão da bomba para aquele nível.

Quando ocorre entupimento do tanque 1 há conseqüentemente um aumento no níveluma diminuição no nível do tanque 2. Tão logo o entupimento seja detectado pelo agentede diagnóstico, uma nova tensão da bomba é inferida pelo valor do nível do tanque 2.Como esse valor (nível do tanque 2), é um valor menor do que normalmente é medidoa tensão inferida tem um valor mais baixo aplicado a bomba, o que conseqüentementebaixa o nível do tanque 1.

Por exemplo, com a tensão de 20 volts aplicada a bomba, o nível do tanque 1 ficaem 22,2321cm e do tanque 2 em 10,0623cm em condições normais. Se houver pequenoentupimento do orifício que vaza água do tanque 1 para o tanque 2, os níveis ficam em25,3369cm e 7,9987cm respectivamente. Neste exemplo, o agente de execução através daRNA já treinada infere uma nova tensão de 17,74v, baixando consequentemente, o níveldos dois tanques.

É importante destacar que, assim como o agente de diagnóstico, em nosso experi-mento, o agente que realiza este controle não está instanciado nos blocos funcionais dosdispositivos. Ele atualmente funciona no nível de supervisório. Contudo, a simplicidadeda sua implementação permite que ele seja facilmente alocado no nível de campo. Alémdisso, outras aplicações mais complexas podem ser usadas para controle de níveis, comoa encontrada no trabalho de de Lima et al. (2005)

4.9 Análise e DesempenhoBoa parte dos trabalhos científicos fundamentam suas análises de desempenho na

comparação com técnicas, ferramentas ou experimentos similares. Em nossa pesquisanão foi detectadas nenhuma arquitetura similar que possa fornecer de maneira eqüitativa,


uma comparação, apesar de existirem várias propostas de arquiteturas de agentes apli-cadas em redes industriais na literatura. Contudo, podemos analisar sob alguns aspectos,o desempenho de nossa arquitetura.

Tomando como base os controles de processos convencionais, temos como principalvantagem de nossa arquitetura a capacidade de aprendizado dos agentes que permite suaadaptação a contextos de falhas novos ou inesperados. A fase de treinamento permite queo agente perceba o comportamento da planta. Sendo assim, conhecendo o funcionamentonormal da planta, o agente pode perceber que qualquer mudança nos valores medidos quesejam diferentes daqueles valores aprendidos podem indicar uma falha. Dessa forma, épossível tomar decisões que melhor corrija esta falha. Outra forma de fazer com o que osagentes aprendam como detectar uma falha é simular um determinado problema e realizaro treinamento dos agentes nessas condições. Isso faz com que eles aprendam um padrãode falha.

Outra vantagem em relação aos controles convencionais, está no fato de que umamesma configuração instanciada nos blocos funcionais dos dispositivos pode ser aproveitadaem outros processos. Neste caso, a reconfiguração dinâmica de blocos funcionais possi-bilitou superar as limitações do protocolo que não permitia mudanças no controle emtempo de execução. Além disso, a possibilidade de alocar blocos funcionais de formadistribuída (em dispositivos diferentes), permite um melhor aproveitamento da aplicaçãoe evita que os dispositivos fiquem sobrecarregados.

Durante os testes não houve falhas na medição dos sensores e na ação dos atuadoresenquanto os agentes estavam em funcionamento. Nem mesmo quando ocorre a mudançade configuração na rede neural do agente execução (uma só para os quatro tipos de ação)houve perda de valores de medição.

É importante destacar que os blocos funcionais instanciados para a rede neural daFigura 4.7 estão dispersos nos dispositivos responsáveis pela medida do tanque 1, tanque2 e no controle da bomba. Em nenhum momento esses valores foram alterados ou per-didos, devido aos requisitos de segurança do modelo Foundation Fieldbus. Isso reforçaa capacidade de transparência da arquitetura proposta, pois mesmo com três agentes alo-cados nos dispositivos de campo, o controle normal da planta não foi alterado nem apresença dos agentes pôde ser percebida.

Outro fator analisado foi o tempo de resposta dos agentes. A Figura 4.22 mostra umgráfico que compara o tempo que um agente execução leva para entrar em funcionamento,a partir do momento que a mensagem do agente de diagnóstico é recebida. Ou seja, o grá-fico mostra o tempo que os pesos sinápticos, bias e links são instanciados na configuraçãode blocos funcionais pré-alocada (Figura 4.7). Ressaltamos que configurações com val-ores já definidos (que não sofrem alterações), como os agentes de observação, entram emfuncionamento imediatamente, junto com o controle da planta.

A barra de Alocação Completa mostra o tempo que é necessário para carregar nosdispositivos de campo o controle normal da planta incluindo as três redes neurais (figuras4.5, 4.6 e 4.7) pelo aplicativo Syscon. Esse procedimento, que consiste em resetar osdispositivos e alocar todos os blocos funcionais envolvidos, leva em torno de 25 minutos(1500 segundos).

Para alocar o agente de execução responsável pela inferência do sinal perdido são


0

200

400

600

800

1000

1200

1400

1600

Alocação Completa Correção de Leitura Filtro de Ruído Auto-Correção

1500

36 66 44

Tem

po

(se

gu

nd

os)

Figura 4.22: Gráfico de comparação do tempo de resposta dos agentes de execução

necessários 36 segundos. Para alocar o filtro de ruído são necessários 66 segundos. Essetempo maior é devido a quantidade maiores de blocos funcionais instanciados nesta con-figuração. Diante disso, para o pleno funcionamento do AE para auto-correção, são gastos44 segundos. Em relação ao tempo gasto para alocação de toda a configuração de controlee de redes neurais, a alocação dinâmica de blocos funcionais tem-se mostrado eficiente.Outros resultados de desempenho da estratégia de alocação dinâmica podem ser vistosem Ramalho (2009).

Notamos que as atividade realizadas pelos agentes de execução não são consider-adas de nível crítico, cujo tempo de resposta tem que ser imediato como por exemplo, ocontrole dos níveis dos tanques. Para este caso é necessário alocar previamente uma ar-quitetura (RNA) que não mude, ou seja, que não seja compartilhada com outros agentes.Outros estudos mais aprofundados sobre o protocolo Foundation Fieldbus, podem revelarnovas perspectivas sobre a questão da mudança on-line de configuração blocos funcionais.

Um ensaio sobre a mudança on-line de blocos funcionais foi realizada em um simu-lador de redes industriais Foundation Fieldbus [Brandao & Pinotti 2006] e publicada emMachado et al. (2009b). A proposta exemplifica que, caso fosse possível a mudança deon line blocos funcionais, ou seja, exclusão, alocação e reconfiguração, a arquitetura teriaum ganho de desempenho (tempo) considerável.

Outro aspecto a ser discutido é a qualidade do treinamento. Nos exemplos mostradosaqui, os arquivos de treinamento são compostos, em média, de 8000 amostras. Contudo,para alguns casos, como o filtro de ruído (Figura 4.19) a saída da rede neural treinada nãofoi tão precisa. Em contrapartida, para o caso de auto-correção, a saída da rede neuraltreinada (sinal compensado) obtivemos resultados mais precisos (Figura 4.21). Estudosmais aprofundados sobre a qualidade do treinamento também trará ganho de desempenhoa arquitetura.

Conforme foi dito anteriormente agentes como o de diagnóstico e o de execução re-


sponsável pelo controle dos tanques, não foram implementados nos blocos funcionais dosdispositivos de campo. Porém em plantas com maior número de dispositivos e conseqüen-temente mais blocos funcionais, a implementação de tais agentes no contexto fieldbus éperfeitamente viável. Além disso, com todos os agentes alocados nos blocos funcionaisdos dispositivos, a ação desses agentes passa a ser totalmente independente do nível desupervisão.

Capítulo 5

Considerações Finais

Nesta tese foi apresentada uma arquitetura multiagente que incorpora funções de mon-itoramento, aprendizagem (através de redes neurais artificiais) e atuação. Finalizando estedocumento mostraremos nas seções seguintes os objetivos alcançados, comprovações dehipóteses, as inovações trazidas pela arquitetura aqui proposta e as dificuldades encon-tradas para sua realização. Mostraremos ainda as perspectivas que este trabalho propor-ciona bem como as perspectivas futuras.

5.1 Comprovação de HipótesesNo Capítulo 1 colocamos a seguinte hipótese a ser provada:

O uso de aprendizagem de máquina faz com que agentes aprendam o fun-cionamento da planta industrial Foundation Fieldbus e assim possam in-terferir autonomamente em algumas funcionalidades como por exemplodetecção e resolução de problemas (falhas).

No decorrer do texto mostramos que através do uso de redes neurais artificiais, umagente alocado nos blocos funcionais dos dispositivos de campo (sensores e atuadores)pode aprender (através do treinamento da RNA) sobre o funcionamento da planta, per-mitindo assim, determinar falhas que podem ocorrer no processo industrial tais como,por exemplo, ruídos externos, perda de sinal de medição e perda de calibração. Elabo-ramos uma arquitetura aplicada a uma planta real (sistemas de níveis de dois tanques) quepermitiu comprovar também as hipóteses secundárias:

• O uso de agentes confere autonomia na resolução de problemas nas redes indus-triais. Através dos exemplos mostrados no Capítulo 4, vemos que independenteda intervenção do operador/supevisor da planta, os agentes são capazes de detectar,diagnosticar e corrigir a falha.• O uso de aprendizagem de máquina ajuda os agentes descobrir padrões de falha

e possíveis soluções. O treinamento da rede neural realizado sob condições de falhamostrado no Capítulo 4, permite que os agentes conheçam o padrão do problemaque está ocorrendo na planta. Com isso, eles são capazes de identificar o tipo deproblema e utilizar a melhor estratégia para solucioná-lo.

CAPÍTULO 5. CONSIDERAÇÕES FINAIS 69

• A proposição de uma estratégia de alocação dinâmica permite que os agentes se-jam alocados nas redes industriais para descobrir e reparar as falhas. No Capí-tulo 3, apresentamos a estratégia de alocação dinâmica de blocos funcionais. Estaestratégia tem como objetivo alocar pequenas configurações de redes neurais a par-tir de configurações maiores, apenas trocando as ligações (links) entre os blocosfuncionais e mudando seus parâmetros (pesos sinápticos) adquiridos no seu treina-mento. Isso permite que os agentes possam mudar suas funções para se adequarema uma falha detectada.

5.2 Contribuições da TeseA principal inovação deste trabalho é agregar agentes ao contexto de uma rede indus-

trial, mais especificamente nos dispositivos de campo. No Capítulo 2 foram mostradosdiversos trabalhos que agregam agentes no contexto industrial, porém em nenhum delesos agentes foram implementados nos dispositivos de campo (sensores e atuadores). As-sim, atividades de detecção e correção de falhas podem ser realizadas de forma autônoma,transparente e independente de sistemas supervisórios.

Outra inovação do trabalho é a alocação dinâmica de blocos funcionais que repre-sentarão os agentes/RNAs. Essa estratégia suplanta a limitação do protocolo Founda-tion Fieldbus de não permitir que blocos funcionais sejam alocados ou desalocados emtempo de execução (on-line), fazendo com que não só agentes possam ser alocados, masqualquer outra configuração de controle, permitido que se modifique dinamicamente ocomportamento do controle da planta.

5.3 DificuldadesDentre as dificuldades encontradas para a implementação de nossa arquitetura, pode-

mos destacar a arquitetura fechada do protocolo (Foundation Fieldbus) que impede o in-stanciamento on-line do blocos funcionais. Ou seja, não é possível ativar, ou desativar osblocos funcionais dos dispositivos com a planta em funcionamento. Para alocarmos umaconfiguração de blocos funcionais convencionalmente, o funcionamento da planta é inter-rompido e as configurações dos blocos funcionais, feitas pelos supervisores da planta, écarregada para os dispositivos.

Este tipo de abordagem vai de encontro com os objetivos de nossa arquitetura, uma vezque é importante que os agentes, principalmente os de execução, possam agir prontamentea um problema encontrado na rede. O desejável é que seja possível, em um momentooportuno, que os agentes possam ser instanciados nos blocos funcionais dos dispositivosde campo, respondendo em tempo hábil a resolução de um problema. Para suplantaresta dificuldade foi proposta a estratégia de configuração dinâmica de blocos funcionaisapresentada no Capítulo 3.

Suplantado o problema da alocação, o tempo de resposta da estratégia, ou seja, otempo levado para alocar uma configuração tornou-se um fator crucial para o desempenhoda arquitetura proposta. As atividade realizadas pelos agentes de execução mostradas nos

CAPÍTULO 5. CONSIDERAÇÕES FINAIS 70

Capítulo 4 não são consideradas de nível crítico, cujo tempo de resposta tem que ser ime-diato, como por exemplo, o controle dos níveis dos tanques. O que faz com que esse fatorseja considerada uma das limitações de nossa arquitetura. Para este caso (controle denível) é necessário alocar previamente uma arquitetura (RNA) que não mude, ou seja, quenão seja compartilhada com outros agentes. São necessários estudos mais aprofundadossobre o protocolo Foundation Fieldbus sobre a questão da mudança on line de configu-ração blocos funcionais para que possamos obter tempos menores quando alocada umaconfiguração em blocos funcionais.

5.4 PerspectivasComo perspectivas futuras, além do estudo para melhoria do tempo de resposta da

alocação dos agentes, mostrada no Capítulo anterior, pretendemos automatizar ainda maisa arquitetura. Para isso, um dos trabalhos futuros é propor uma estratégia que possadetectar blocos funcionais livres na planta para alocação de aplicações.

Outro aspecto a ser analisado em implementações futuras diz respeito ao aprendizadodas redes neurais. É necessário estudar mecanismos que indiquem aos agentes o quantode conhecimento já é suficiente e, por outro lado, quando a fase de treinamento deve serrefeita para que os agentes adquiram novos conhecimento à respeito de novas situaçõesde falhas ocorridas na planta. Além disso, uma análise de quais blocos funcionais e quaisligações entre eles trariam melhor desempenho para a arquitetura, seria um fator quepoderia trazer sensível melhoria ao trabalho proposto.

Diante do exposto, acreditamos ter alcançado nossos objetivos, especificando de umsistema multiagente para a implementação de aplicações em blocos funcionais, utilizandode algoritmos de aprendizagem para detecção e correção de falhas em ambientes indus-triais e propondo de uma estratégia para alocação dinâmica de blocos funcionais.

Lista de Publicações

Machado, V. P.; Dória Neto A. D.; de Melo J. D.; (2010) A Neural Network MultiAgentArchitecture Applied to Industrial Networks for Dynamic Allocation of ControlStrategies using Standard Function Blocks. IEEE Transaction on Industrial Elec-tronics. (to be publish).

Machado, V. P.; Brandão, D.; Dória Neto, A. D.; de Melo, J. D.; (2009) A MultiagentArchitecture Based in a Foundation Fieldbus Network Function Blocks for FaultDetection. Factory Automation. Intechweb. (to be publish).

Machado, V. P.; Brandão, D.; Dória Neto, A. D.; de Melo, J. D.; Ramalho L.; Medeiros,J.; (2008) A Neural Network MultiAgent Architecture Applied to Fieldbus Intelli-gent Control. 13th IEEE International Conference on Emerging Technologies andFactory Automation, Hamburgo. p. 567-574.

Machado, V. P.; Brandão, D.; Dória Neto, A. D.; de Melo, J. D.; Ramalho, L.; Medeiros,J.; (2008) MultiAgent architecture for function blocks: Intelligent configurationstrategies allocation. 6th IEEE International Conference on Industrial Informatics- INDIN 2008, Daejeon. p. 1377-1382.

Machado, V. P.; Brandão, D.; Dória Neto, A. D.; de Melo J. D.; Ramalho, L.; MedeirosJ.; Martins, D. L.; (2008) Dynamic Funtion Blocks Allocation: A Multiagent Ap-proach. XVII Congresso Brasileiro de Automática - CBA 2008. Juiz de Fora.

Machado, V. P.; Brandão, D.; Dória Neto, A. D.; de Melo, J. D.; Ramalho, L.; MedeirosJ.; Costa, B.; A Simulated Environment for a Multi-agent architecture based in aFoundation Fieldbus network function blocks. IEEE International Conference onDistributed Human-Machine Systems - DHMS 2008, Athens. p. 566-573.

Referências Bibliográficas

Amari, Shun-Ichi, Tian ping Chen & Andrez Cichocki (1997), ‘Stability analysis of adap-tive blind source separation’, IEEE Transactions on Neural Networks 10, 1345–1351.

Bass, Len, Paul Clements & Rick Kazman (2003), Software Architecture in Practice,Addison-Wesley Professional.

Berge, J. (2001), Fieldbus for Process Control: Enginneering, Operation and Mainte-nance, ISA - The Instrumentation, System and Automation Society.

Bonabeau, E. (2002), Agent-based modelling: Methods and techniques for simulatinghuman systems, em ‘Proceedings of the National Academy of Science’, Vol. 3,pp. 7280–7287.

Brandao, Dennis & M. Pinotti (2006), ‘Industrial smart transmitters modeling for pc-based instruments development platform’, Industrial Technology, 2006. ICIT 2006.IEEE International Conference on pp. 2375–2379.

Cagni, E., David Ricardo do Vale Pereira, Adrião Duarte Dória Neto, Jorge Dantasde Melo & Luiz Affonso Guedes (2005), The implementation of the self-calibration,self-compensation and self-validation algorithms for foundation fieldbus sensors arepresented using standard function blocks, em ‘Computational Intelligence for Mea-surement Systems and Applications, 2005. CIMSA. 2005 IEEE International Con-ference on’, pp. 220–225.

Chaib-draa, B. (1995), ‘Industrial applications of distributed ai’, Commun. ACM38(11), 49–53.

Chong, Chee-Yee & S.P. Kumar (2003), ‘Sensor networks: evolution, opportunities, andchallenges’, Proceedings of the IEEE 91(8), 1247–1256.

Cockburn, D. & N. R. Jennings (1996), Archon: A distributed artificial intelligence sys-tem for industrial applications, em G. M. P.O’Hare & N. R.Jennings, eds., ‘Founda-tions of Distributed Artificial Intelligence’, John Wiley & Sons, pp. 319–344.

Costa, I., Adrião Dória Neto, J. D. Melo & J. A. N Oliveira (2003), Embedded fasticaalgorithm applied to the sensor noise extraction problem of foundation fieldbus net-work, em ‘International Joint Conference on Neural Networks’.

72

REFERÊNCIAS BIBLIOGRÁFICAS 73

Costa, Isabele Morais (2006), Projeto e implementação em ambiente foundation fieldbusde filtragem estocástica baseada em análise de componentes independentes, Disser-tação de mestrado, Programa de Pós-Graduação em Engenharia Elétrica - Universi-dade Federal do Rio Grande do Norte.

Davis, Robert I., Alan Burns, Reinder J. Bril & Johan J. Lukkien (2007), ‘Controller areanetwork (can) schedulability analysis: Refuted, revisited and revised’, Real-TimeSyst. 35(3), 239–272.

de Lima, Fábio Soares, Luiz Affonso Guedes, Adrião D. Dória Neto & Jorge D. Melo(2005), Controle inteligente para um tanque não-linear de 1a. ordem através de redesindustriais foundation fieldbus utilizando blocos funcionais padrão, em ‘SimpósioBrasileiro de Automação Inteligente - VII SBAI’.

Deen, S.M. (2003), Agent-based Manufacturing: Advances in the Holonic Approach,Springer: Berlin.

Dexter, A.L. (1995), ‘Fuzzy model based fault diagnosis’, Control Theory and Applica-tions, IEE Proceedings - 142(6), 545–550.

Dong, Hai, Farookh Khadeer Hussain & Elizabeth Chang (2007), Application of protégéand sparql in the field of project knowledge management, em ‘Systems and Net-works Communications, 2007. ICSNC 2007. Second International Conference on’,pp. 74 – 74.

Elmenreich, Wilfried (2003), Intelligent methods for embedded systems, em ‘In Proceed-ings of the First Workshop on Intelligent Solutions in Embedded Systems (WISES2003’, pp. 3–11.

Elmenreich, Wilfried, Stefan Pitzek, Technische Universität, Wien Technische & Univer-sität Wien (2003), Smart transducers - principles, communications, and configura-tion, em ‘In Proceedings of the 7th IEEE International Conference on IntelligentEngineering Systems’, pp. 510–515.

Feng, Qibin & Guoqiang Lu (2003), Fipa-acl based agent communications in plant au-tomation, em ‘Emerging Technologies and Factory Automation, 2003. ETFA 2003.IEEE International Conference on’, Vol. 2, IEEE, pp. 74–78.

Feng, Quibin, Aleksey Bratukin, Albert Treytl & Thilo Sauter (2007), A flexible multi-agent system architecture for plant automation, em ‘5th IEEE International Confer-ence on Industrial Informatics (INDIN 2007) Industrial Informatics, IEEE Transac-tions on’, pp. 1047–1052.

Fernandes, Raphaela Galhardo, Diego R. Cabral Silva, Luiz Affonso Guedes & AdriãoDuarte Dória Neto (2007), ‘An implementation of a fault detection and isolationsystem on foudation fieldbus environment’, International Journal of Factory Au-tomation, Robotics and Soft Computing 3, 130–136.


Fortulan, Marcos & Eduardo Gonçalves Filho (2005), ‘Uma proposta de aplicação debusiness intelligence no chão-de-fábrica’, Gestão e Produção 12(1), 55–66.

Foundation, Fieldbus (2001), Foundation Specification Function Block Application Proc-cess, Fieldbus Foundation.

Frey, Christian (2008), Process diagnosis and monitoring of field bus based automationsystems using self-organizing maps and watershed transformations, em ‘MultisensorFusion and Integration for Intelligent Systems, 2008. MFI 2008. IEEE InternationalConference on’, pp. 620–625.

Giret, Adriana, Vicente J. Botti & Soledad Valero (2005), Mas methodology for hms, em‘HoloMAS’, pp. 39–49.

Glanzer, K., A. Hammerle & R. Geurts (2001), he application of zeus agents in manu-facturing environments, em ‘Database and Expert Systems Applications, 2001. Pro-ceedings. 12th International Workshop on’, pp. 628 – 632.

Gruber, T. R. (1993), Towards principles for the design of ontologies used for knowledgesharing, em N.Guarino & R.Poli, eds., ‘Formal Ontology in Conceptual Analysisand Knowledge Representation’, Kluwer Academic Publishers.

Haykin, S. (2001), Redes neurais: princípios e prática, Bookman.

Hoffman, Donna & Thomas P Novak (1996), ‘Marketing in hypermedia computer medi-ated environments: conceptual foundations’, Journal of Marketing 60(2), 50–68.

Hyvarinen, A. (1999), ‘Fast and robust fixed-point algorithm for independent componentanalysis.’, IEEE Transactions on Neural Networks 10, 626–634.

James, S. C., R. L. Legge & H Budman (2000), ‘On-line estimation in bioreactors: Areview’, Reviews in Chemical Engineering 16(4), 311.

Korbicz, Jozef & Marek Kowal (2007), ‘Neuro-fuzzy networks and their application tofault detection of dynamical systems’, Eng. Appl. Artif. Intell. 20(5), 609–617.

Landaburu, Penya, S. Mahlknecht & P. Rössler (2002), Lightweight agent platform forhigh-performance fieldbus nodes, em ‘WIP Proceedings of the WFCS 2002’, pp. 17– 20.

Li, Tie-Jun, Yu-Qing Peng, Hai-Wen Zhao & Kai Li (2004), Application of multi-agentin control and fault diagnosis systems, em ‘Machine Learning and Cybernetics. Pro-ceedings of 2004 International Conference on’, Vol. 1, pp. 194–197.

Lin, H. & C. Yang (2007), Specification of multi-agent systems in the gamma language,em ‘Electrical and Computer Engineering, Canadian Conference on’, pp. 1372 –1375.


Macal, Charles M. & Michael J. North (2006), Tutorial on agent-based modeling andsimulation part 2: how to model with agents, em ‘WSC ’06: Proceedings of the 38thconference on Winter simulation’, Winter Simulation Conference, pp. 73–83.

Macerauskas, V. & V. Teresius (2004), ‘Investigation of multi-agent control system’, Elek-tronika Ir Elektrotechnika 3, 52.

Machado, Vincius P., Adrião Duarte Dória Neto, Jorge Dantas de Melo, Leonardo Ra-malho & Juliana Medeiros (2008b), Multiagent architecture for function blocks:Intelligent configuration strategies allocation, em ‘Industrial Informatics, 2008. IN-DIN 2008. 6th IEEE International Conference on’, pp. 1377–1382.

Machado, Vincius P., Adrião Duarte Dória Neto, Jorge de Melo, Leonardo Ramalho,Daniel Martins & Juliana Medeiros (2008c), Dynamic funtion blocks allocation: Amultiagent approach, em ‘XVII Congresso Brasileiro de Automática - CBA 2008’.

Machado, Vinicius Ponte, Adrião Duarte Dória Neto & Jorge Dantas de Melo (2009a), ‘Aneural network multiagent architecture applied to industrial networks for dynamicallocation of control strategies using standard function blocks’, IEEE Trans. on In-dustrial Electronics 56. a ser publicado.

Machado, Vinicius Ponte, Dennis Brandão, Adrião Duarte Dória Neto & Jorge Dantasde Melo (2009b), A Multiagent Architecture Based in a Foundation Fieldbus Net-work Function Blocks for Fault Detection.

Maes, P. (1995), ‘Artificial life meets entertainment: lifelike autonomous agents’, Com-munications of the ACM 38(11).

Mitchell, Tom M. (1997), Machine Learning, McGraw-Hill, New York.

Moraes, Cicero & Plinio Castrucci (2001), Engenharia de Automação industrial, LTC,Rio de Janeiro.

Nwana, H. S. & D. T. Ndumu (1999), A perspective on software agents research, em‘Knowledge Engineering Review’.

Nwana, Hyacinth S. (1996), ‘Software agents: An overview’, Knowledge EngineeringReview 11(3), 1–40.

Pirttioja, Teppo, Antti Pakonen, Ilkka Seilonen, Aarne Halme & Kari Koskinen (2005),Multi-agent based information access services for condition monitoring in processautomation, em ‘Proceedings of the 3rd IEEE International Conference on IndustrialInformatics 2005’, Vol. 1, pp. 10–12. The 3rd IEEE International Conference onIndustrial Informatics, Perth, Australia, 10-12.8.2005.

Polaków, Grzegorz & Mieczyslaw Metzger (2007), Agent-based approach for labviewdeveloped distributed control systems., em N. T.Nguyen, A.Grzech, R. J.Howlett &L. C.Jain, eds., ‘KES-AMSTA’, Vol. 4496 de Lecture Notes in Computer Science,Springer, pp. 21–30.


Popp, M. (1997), The rapid way to profibus, Relatório técnico, PROFIBUS Nutzerorga-nization, Karslhue, Germany.

Ramalho, Leonardo Sávio Guanabara (2009), Reconfiguração dinâmica de estratégiasdistribuídas em dispositivos foundation fieldbus para a otimização de processos naindústria do petróleo, Dissertação de mestrado, Programa de Pós-Graduação emCiência e Engenharia de Petróleo da UFRN.

Russell, Stuart & Peter Norvig (2003), Artificial Intelligence: A Modern Approach,seconda edição, prentice, prenticeort.

Schwarz, M. H. & J. Boercsoek (2007), A survey on ole for process control (opc), em‘ACS’07: Proceedings of the 7th Conference on 7th WSEAS International Confer-ence on Applied Computer Science’, World Scientific and Engineering Academyand Society (WSEAS), Stevens Point, Wisconsin, USA, pp. 186–191.

Seilonen, Appelqvist & Koskinen (2002), Agent-based approach for fault-tolerance inprocess automation systems, em ‘Proceedings of the 3rd International Symposiumon Robotics and Automation (ISRA 2002)’, pp. 106–111.

Seilonen, I., T. Pirttioja & P. Appelqvist (2002), Agent technology and process automa-tion, em ‘10th Finnish Artificial Intelligence Conference (STeP 2002)’, pp. 31–35.

Shen, Weiming, Douglas H. Norrie & Jean-Paul A. Barthès (2001), Multi-Agent Systemsfor Concurrent Intelligent Design and Manufacturing, Taylor & Francis (Londonand New York).

Silva, A & M Salvador (2004), O que são sistemas supervisórios, Elipse Software, SãoPaulo.

Silva, Diego R. Cabral, Luiz Affonso Guedes, Adrião Duarte Dória Neto & Jorge Dantasde Melo (2006), ‘Neural networks implementation in foundation fieldbus environ-ment: A case study in neural control’, International Journal of Factory Automation,Robotics and Soft Computing .

Stefano, Antonella Di & Corrado Santoro (2000), Mobile agents for distributed processcontrol, em ‘2000 International Conference on Intelligent Engineering Systems’.

Stefano, Antonella Di & Corrado Santoro (2002), On-line load balancing in a multi-agentindustrial environment, em ‘Proceedings of the 6th IEEE International Conferenceon Intelligent Engineering Systems (INES 2002)’.

Stefano, Antonella Di & Corrado Santoro (2009), ‘A3m: an agent architecture for auto-mated manufacturing.’, Softw., Pract. Exper. 39(2), 137–162.

Sutton, R. S. & A. G. Barto (1998), Reinforcement Learning: An Introduction, Cam-bridge, MA: MIT Press.


Tan, Vu Van, Dae-Seung Yoo & Myeong-Jae Yi (2006), Design and implementation ofweb service by using opc xml-da and opc complex data for automation and con-trol systems, em ‘Computer and Information Technology, 2006. CIT ’06. The SixthIEEE International Conference on’, pp. 263 – 263.

Wagner, Thomas (2002), An agent-oriented approach to industrial automation systems,em ‘Proceedings of the 3th International Symposium on Multi-Agent Systems,Large Complex Systems and E-Business’, pp. 508–524.

Weiss, Gerhard (1999), Multiagent Systems: A Modern Approach to Distributed ArtificialIntelligence, MIT Press, Cambridge, MA, USA.

Weyns, D., K. Schelfthout, T. Holvoet & T. Lefever (2005), Decentralized control of egvtransportation systems, em ‘Autonomous Agents and Multiagent Systems’, pp. 67–74.

Weyns, Danny & Tom Holvoet (2007), ‘Architectural design of a situated multiagentsystem for controlling automatic guided vehicles’, International Journal on AgentOriented Software Engineering 1(4), 1–39.

Wild, R. (1999), A tool for validating timing requirements of industrial applications basedon the foundation feldbus protocol, em S.Dagstuhl, ed., ‘24TH IFAC/IFIP WORK-SHOP ON REAL-TIME PROGRAMMING’.

Wild, R. (2000), Proposta de ferramenta para validação temporal em barramentos decampo, Dissertação de mestrado, Programa de Pós-Graduação em EngenhariaElétrica, Universidade Federal do Rio Grande do Sul, Porto Alegre, RS.

Wooldridge, M., N. Jennings & D. Kinny (2000), The gaia methodology for agent-oriented analysis and design, em ‘Autonomous Agents and Multi-Agent Systems’,pp. 285–312.

Wooldridge, Michael (2002), Introduction to MultiAgent Systems, John Wiley & Sons.

Zeilmann, Rafael (2002), Uma estratégia para controle e supervisão via internet de pro-cessos industriais, Dissertação de mestrado, Mestrado em Engenharia Elétrica, Uni-versidade Federal do Rio Grande do Sul, Porto Alegre, RS.

Zurek, Stan, Anthony Moses & Michael Packianather (2009), ‘Implementing an artificialneural network using national instruments labview’. Available at: http://sine.ni.com/csol/cds/item/vw/p/id/681/nid/124200.

http://sine.ni.com/csol/cds/item/vw/p/id/681/nid/124200

http://sine.ni.com/csol/cds/item/vw/p/id/681/nid/124200

uma arquitetura baseada em agentes para conﬁguração ... · universidade federal do rio grande...

Documents