UMA ARQUITETURA BASEADA EM AGENTES E INTERFACE WEB PARA SISTEMAS DE AUTOMAÇÃO DE SUBESTAÇÕES DE ENERGIA ELÉTRICA

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA JOSÉ HENRIQUE DOMETERCO UMA ARQUITETURA BASEADA EM AGENTES E INTERFACE WEB PARA SISTEMAS DE AUTOMAÇÃO DE SUBESTAÇÕES DE ENERGIA ELÉTRICA MONOGRAFIA DE ESPECIALIZAÇÃO ORIENTADORA: PROF.ª MSC. ANA CRISTINA B. KOCHEM VENDRAMIN CURITIBA DEZEMBRO 2006

JOSÉ HENRIQUE DOMETERCO UMA ARQUITETURA BASEADA EM AGENTES E INTERFACE WEB PARA SISTEMAS DE AUTOMAÇÃO DE SUBESTAÇÕES DE ENERGIA ELÉTRICA Monografia apresentada ao programa de Pós-Graduação em Informática da Universidade Tecnológica Federal do Paraná como requisito parcial para obtenção do título de Especialista em Informática com ênfase em Tecnologias Java. Orientador: Prof. ª Msc. Ana Cristina B. Kochem Vendramin CURITIBA DEZEMBRO 2006 i

Aos colegas da equipe de trabalho da COPEL. ii

AGRADECIMENTOS A minha geladeira, sempre útil nos intervalos deste trabalho. iii

SUMÁRIO LISTA DE FIGURAS...v LISTA DE SIGLAS...vi RESUMO...viii 1 INTRODUÇÃO...9 1.1 HIPÓTESES...10 1.2 OBJETIVO...12 1.3 JUSTIFICATIVA...12 1.4 ESTRUTURA DO TRABALHO...13 2 ARQUITETURAS DISTRIBUÍDAS PARA AUTOMAÇÃO...14 2.1 SISTEMAS MULTIAGENTES...14 2.2 ABORDAGENS DE ARQUITETURA PARA SISTEMAS DE AUTOMAÇÃO...17 3 ANÁLISE DE TECNOLOGIAS PARA SISTEMAS DE AUTOMAÇÃO...23 3.1 TECNOLOGIAS PARA SISTEMAS DISTRIBUÍDOS...23 3.1.1 Sockets...23 3.1.2 Java RMI...24 3.1.3 Web Services...24 3.1.4 Implementações de Plataformas de Agentes...25 3.1.5 Comparativo de Desempenho das Tecnologias...26 3.2 CAMADA DE APRESENTAÇÃO...29 3.2.1 Desafios Decorrentes da Utilização da Camada Web...32 3.2.2 SVG...33 3.2.3 AJAX...34 3.3 AVALIAÇÃO DA MÁQUINA VIRTUAL JAVA...35 3.4 INTEGRAÇÃO COM O SISTEMA LEGADO...37 4 A PLATAFORMA JADE...38 4.1 CONTAINER DE AGENTES JADE...38 4.2 O MODELO DE DESENVOLVIMENTO DO JADE...39 4.3 COMUNICAÇÃO ENTRE AGENTES...40 4.4 FERRAMENTAS AUXILIARES...41 4.5 TOLERÂNCIA A FALHAS...42 4.6 INTEGRAÇÕES...42 5 CENÁRIOS DE ARQUITETURA PARA AUTOMAÇÃO...44 5.1 O SISTEMA ATUAL...44 5.2 MODELOS DISTRIBUÍDOS DE AUTOMAÇÃO DE SUBESTAÇÕES...45 6 IMPLEMENTAÇÃO DO PROTÓTIPO PARA PROVA DE CONCEITO...50 6.1 SIMULADOR DE SUBESTAÇÃO...50 6.2 AGENTE SUBESTAÇÃO...52 6.3 AGENTE CLIENTE...53 6.4 CAMADA WEB...55 7 CONCLUSÕES E TRABALHOS FUTUROS...58 7.1 TRABALHOS FUTUROS...59 REFERÊNCIAS...60 iv

LISTA DE FIGURAS FIGURA 1 TESTES DE DESEMPENHO ENTRE AS TECNOLOGIAS RMI, WEB SERVICES, SOCKETS E AGENTES (JADE)....28 FIGURA 2 CONTAINERS JADE E PLATAFORMAS [JADE06]...39 FIGURA 3 MODELO DE QUATRO CAMADAS DE UM AMBIENTE DE AUTOMAÇÃO DE SUBESTAÇÕES....45 FIGURA 4 MODELO DE TRÊS CAMADAS DE UM AMBIENTE DE AUTOMAÇÃO DE SUBESTAÇÕES....46 FIGURA 5 DIAGRAMA DETALHADO DO MODELO DE TRÊS CAMADAS PROPOSTO, INCLUINDO O COV...47 FIGURA 6 ESQUEMA ELÉTRICO DA SUBESTAÇÃO FICTÍCIA...51 FIGURA 7 INTERAÇÃO ENTRE AGENTECLIENTE E AGENTESUBESTACAO....55 FIGURA 8 - EXEMPLO DA INTERFACE DE MONITORAMENTO PROVIDA PELO SISTEMA SCADA...56 FIGURA 9 - RESULTADOS DA APRESENTAÇÃO DAS INFORMAÇÕES DA SUBESTAÇÃO FICTÍCIA...57 v

LISTA DE SIGLAS ACL AID AJAX AMS ANEEL API CFP CIM COD COE CORBA COV DF FIPA GIF GNU HMI HTML HTTP IEC IEEE JADE JEE JMS JMX JNI Agent Communication Language Agent Identifier Asynchronous JavaScript And XML Agent Management System Agência Nacional de Energia Elétrica Application Program Interface Call for Proposals Common Information Model Centro de Operação de Distribuição Centro de Operação de Transmissão Commom Object Request Broker Centro de Operação Virtual Directory Facilitator Foundation for Intelligent Physical Agents Graphics Interchange Format GNU s Not Unix Human Machine Interface Hypertext Markup Language Hypertext Transfer Protocol International Electrotechnical Commission Institute of Electrical and Electronics Engineers Java Agent Development Framework Java Enterprise Edition Java Messaging Service Java Management Extentions Java Native Interface vi

JPG JSP JVM J2ME J2SE LGPL MAS MVC NCU RMI RTU SCADA SVG TCP/IP UML W3C WSDL XML Joint Photographic Experts Group Java Server Pages Java Virtual Machine Java 2 Micro Edition Java 2 Stardard Edition GNU Lesser General Public Licence Multiagent System Model View Controller Network Computing Unit Remote Method Invocation Remote Terminal Unit Supervisory Control and Data Aquisition Scalable Vectorial Graphics Transmission Control Protocol/Internet Protocol Unified Modeling Language World Wide Web Consortium Web Service Description Language Extensible Markup Language vii

RESUMO Arquitetura e tecnologia empregadas em sistemas computacionais distribuídos são elementos determinantes de suas qualidades não-funcionais, como interoperabilidade, reutilização e desempenho, as quais influenciam diretamente a agilidade e otimização das funções empresariais automatizadas por esses sistemas. Especificamente em automação de subestações de energia elétrica, funções de supervisão e controle operacional estão dependentes, em muitos casos, de sistemas SCADA (Supervisory Control and Data Acquisition) construídos no passado com arquiteturas rígidas e pouco interoperáveis. Sistemas multiagentes têm sido foco de estudo e utilização em aplicações SCADA, trazendo vantagens como modularidade, flexibilidade e cooperação. Aliado a isso, o uso de tecnologias Internet com suporte oferecido pela plataforma Java tem proporcionado um contexto adequado para viabilizar a evolução de aplicações existentes, oferecendo facilidades de integração e desenvolvimento. Este trabalho faz uma análise de tecnologias de computação distribuída e, com base nos resultados obtidos e na revisão da literatura, propõe uma arquitetura para automação de subestações, considerando o modelo hoje existente em uma empresa de energia elétrica. O modelo é uma proposta para resolver problemas de interoperabilidade entre centros de operação e a evolução tecnológica do sistema SCADA atual. Um protótipo é construído com intuito de experimentação das tecnologias que oferecem suporte à arquitetura proposta. Palavras-chave: Tecnologia Java; plataforma de agentes JADE; sistemas multiagentes; operação de subestações; SCADA. viii

9 1 INTRODUÇÃO A evolução das redes de computadores tem permitido o desenvolvimento de sistemas computacionais distribuídos e a flexibilização dos processos e execução de tarefas em muitas áreas de aplicação, entre elas a de energia elétrica. Entretanto, muitos sistemas possuem restrições para tempo de resposta, segurança, garantia de entrega de mensagens e processamento em tempo real, requisitos esses nem sempre alcançados pelas redes de computadores de uso geral, evidenciando a necessidade de configurações especiais e linhas de comunicação dedicadas. Na área de tele-operação de subestações de energia elétrica é comum a existência de sistemas que utilizam uma rede de comunicação dedicada, principalmente por serem sistemas construídos há décadas com tecnologias proprietárias que ao longo dos anos evoluíram sem considerar o uso de uma rede corporativa. Nesse contexto, é comum também as concessionárias de energia manterem centros de operação distribuídos geograficamente para gerenciar subestações de uma determinada região sem, contudo, haver uma integração total entre esses centros. Os sistemas de automação de subestações estão numa categoria de sistemas chamados de SCADA (Supervisory Control and Data Aquisition). Esses sistemas possuem unidades remotas (RTU Remote Terminal Unit) instaladas nas subestações, responsáveis pela interação direta com sensores e atuadores vinculados aos equipamentos elétricos [BOYER93]. As RTUs efetuam captura de informações da planta elétrica e enviam-nas para as estações centrais, localizadas no centro de operação, por meio de uma rede de comunicação que interliga cada centro com as várias subestações por ele controladas. As estações centrais acumulam os dados recebidos das RTUs e apresentam-nas aos terminais de operação (HMI Human Machine Interface). Os comandos emitidos pelos

10 operadores, bem como aqueles gerados automaticamente pelas estações centrais, são repassados para as RTUs para a atuação real na planta sendo monitorada. Alguns autores reivindicam que a utilização da internet neste contexto é viável, alicerçada pelos avanços tecnológicos alcançados na área de comunicação e redes de computadores [QIU+02]. Para que haja maior flexibilização e melhoria no processo de automação de subestações é necessária uma infra-estrutura computacional que leve em conta os requisitos supramencionados e que permita a distribuição das tarefas entre os centros de operação de subestações de uma concessionária de energia. Essa estrutura possibilitaria a cobertura de um centro de controle por outro em determinadas situações, de forma a otimizar a capacidade de operação do sistema elétrico. 1.1 HIPÓTESES A adoção de uma nova infra-estrutura pode considerar a integração com funcionalidades existentes no sistema legado, visando preservar os investimentos já realizados pelas concessionárias, mas deve fazer o uso de tecnologias baseadas em padrões abertos para ampliar a conectividade e intercâmbio de informações de forma geral. Nesse momento, hipóteses sobre uma nova arquitetura podem ser levantadas, baseadas na integração com os sistemas legados. Uma provável arquitetura seria caracterizada pela adoção de um servidor Web como fonte de acesso aos dados, integrado com as aplicações SCADA no centro de operação, e o browser internet atuando com HMI. Nesta proposta, o processo de comunicação entre o centro de operação e a subestação se manteria inalterado. A arquitetura permitiria que qualquer centro de operação, salvo as devidas regras de segurança, controlasse uma subestação independentemente da sua localização geográfica. Este cenário seria indicado onde não houvesse rede TCP/IP (Transmission Control Protocol/Internet Protocol) entre o centro de operação

11 e a subestação. Em uma outra hipótese de arquitetura, um computador seria colocado em cada subestação, eliminando a necessidade de concentração de dados pelas estações centrais. Os browsers com a função de HMI acessariam diretamente esse servidor, o que exigiria que a rede entre o centro de operação e as subestações fosse TCP/IP. Este cenário implica em uma arquitetura totalmente distinta à arquitetura SCADA. Um terceiro cenário mais genérico, com atributos dos dois anteriores, poderia considerar que cada subestação é encapsulada por uma representação em software, o qual permite que se realizem todas as funções de leitura e atuação na respectiva subestação física. Não importa como este software está interligado com a subestação - seja por meio de uma rede dedicada ou TCP/IP, ou se ele está sendo executado no centro de operação ou na própria subestação. Haveria um sistema geral de controle que reconheceria todas as subestações disponíveis para gerenciamento, todos os usuários operadores, e atuaria como mediador para as sessões de operação. Pode-se dividir esta arquitetura em algumas camadas de responsabilidade, entre elas, uma camada responsável pela geração da interface com o usuário operador e pelo processo de interação com ele; outra camada responsável pela integração com a subestação através do sistema legado; uma camada intermediária, ponte entre as duas anteriores. Na literatura científica, algumas abordagens de arquiteturas distribuídas são descritas para várias áreas de aplicação. Para a maioria das aplicações SCADA, é citado o uso da tecnologia de agentes e Web [BUSE+03] [LI+02]. Independentemente da arquitetura adotada, testes de desempenho, segurança, confiabilidade e tolerância à falhas devem ser realizados para a instituição em produção de um sistema como este.

12 1.2 OBJETIVO O objetivo deste trabalho é investigar as arquiteturas e tecnologias disponíveis para a construção de sistemas de automação distribuída utilizando uma intranet corporativa, e efetuar a proposta de uma arquitetura com a construção de um protótipo para prova de conceito dos assuntos investigados. O enfoque será nas tecnologias empregadas para a geração da interface gráfica de usuário e em agentes móveis como parte do controle central do sistema. A integração com sistemas legados ficará em segundo plano. Para construção do protótipo, adotar-se-á como premissa o uso de tecnologias relacionadas com a plataforma Java. 1.3 JUSTIFICATIVA O presente trabalho está relacionado com um projeto de Pesquisa e Desenvolvimento da ANEEL (Agência Nacional de Energia Elétrica) em fase de execução pela COPEL Companhia Paranaense de Energia. Outro estudo acadêmico, também relacionado ao projeto, complementa o entendimento deste trabalho [BRAGA06]. A viabilização de um novo sistema para automação de subestações traz redução de custos pela não utilização de softwares proprietários na arquitetura proposta. A arquitetura baseada em padrões abertos permite maior integração com outros sistemas da empresa. O acesso via Web reduz custos de instalação da aplicação no cliente e permite maior flexibilização na gerência do sistema. Este estudo proporciona também aumento do capital intelectual dos envolvidos, que se reflete no aumento da qualidade dos produtos e serviços da área de TI (Tecnologia da Informação) da empresa.

13 1.4 ESTRUTURA DO TRABALHO O trabalho está organizado da seguinte maneira. No capítulo 2, são investigadas as arquiteturas para automação de subestações com foco em sistemas multiagentes. No capítulo seguinte, são descritas e analisadas potenciais tecnologias para consolidar uma arquitetura baseada em agentes. Um comparativo entre mecanismos de comunicação para aplicações distribuídas também é realizado. O capítulo 4 apresenta uma plataforma de agentes, denominada JADE (Java Agent Development Framework), utilizada nos experimentos deste trabalho. O capítulo 5 trata as propostas de modelos para o sistema de automação da COPEL. Em seguida, é montada uma prova de conceito para avaliar o funcionamento das tecnologias, como parte complementar dos assuntos tratados nos capítulos anteriores. Finalmente, no capítulo 7 são enunciadas as conclusões e propostas para continuidade dos trabalhos.

14 2 ARQUITETURAS DISTRIBUÍDAS PARA AUTOMAÇÃO O presente capítulo descreve conceitos pertinentes a sistemas multiagentes e apresenta soluções e arquiteturas encontradas na literatura para abordar a questão de computação distribuída em sistemas elétricos, em sua grande maioria baseadas em sistemas multiagentes e tecnologia internet. 2.1 SISTEMAS MULTIAGENTES Um sistema multiagente (MAS Multiagent System) pode ser definido como uma rede fracamente acoplada de entidades solucionadoras de problemas que interagem entre si para resolver problemas que estão além das capacidades ou conhecimentos de cada entidade em particular. Essas entidades são chamadas de agentes [DURFEE+89]. Existem diversas definições para o termo agente [JENNINGS+98], [FRANKLIN+96], [PRAYURACHATUPORN+01], [COSTA99], [FARACO98]. De uma forma geral, um agente é um sistema computacional que está situado em um ambiente e apto a atuar autonomamente, de forma flexível, sobre este ambiente para atingir seus objetivos de projeto. Segundo Prayurachatuporn e Benedicenti [PRAYURACHATUPORN+01], agentes de software são unidades de programa autônomas suportadas por um ambiente de execução, que podem utilizar a rede de computadores para se comunicarem entre si e para se movimentarem de um computador a outro. Eles constituem os blocos elementares para a construção de sistemas computacionais complexos. O propósito principal do ambiente de execução é oferecer aos agentes a infra-estrutura necessária para que eles possam atuar. Vários ambientes de execução podem trabalhar de forma integrada, possibilitando a movimentação de

15 agentes entre eles. Muitas características estão associadas aos agentes, não significando necessariamente que todas elas devam estar presentes [FERNANDES03]: a) Autonomia: refere-se ao princípio de que o agente pode atuar sem a intervenção direta de humanos ou outros agentes, tendo controle sobre suas próprias ações e seu estado de forma não supervisionada, com base na capacidade de inteligência. Sistemas de controle de processos por computador são exemplos de sistemas autônomos de computação; b) Comunicação: capacidade do agente de intercambiar seus recursos, seu conhecimento e suas decisões com outros agentes, e também outras entidades, como o ambiente onde executa e com seres humanos. Existem várias linguagens propostas para realizar a comunicação entre agentes, como AgentTalk, ACL (Agent Communication Language), KIF (Knowledge Interchange Format) e KQML (Knowledge Query and Manipulation Language); c) Cooperação e habilidade social: capacidade de trabalhar em conjunto, em busca de um objetivo comum. Um agente pode invocar outros para resolver seus próprios problemas, pode disponibilizar informações para a sociedade, acreditando que outros agentes irão solicitá-las e, eventualmente, cooperar para ajudar outros a resolverem seus problemas. Para que haja cooperação, os agentes devem ser dotados de comunicação; d) Inteligência: habilidade computacional ou analítica que um agente possui para analisar seu ambiente e resolver problemas. As técnicas ou heurísticas utilizadas podem ser redes neurais artificiais, lógica fuzzy, sistemas especialistas, algoritmos genéticos, colônia de formigas. A técnica mais adequada depende do objetivo do agente [JUNG+04]; e) Aprendizado: diz respeito ao agente poder receber de um treinador um

16 conhecimento através de um conjunto de instruções, ou então aprender continuamente por experiência, baseado no resultado das decisões que toma de forma autônoma a partir da percepção do ambiente; f) Reatividade: capacidade de perceber mudanças em seu ambiente por meio de sensores e responder de maneira temporal a tais mudanças; g) Pró-atividade: o agente toma iniciativa para atingir o objetivo que lhe é atribuído em vez de simplemente reagir a mudanças no ambiente; h) Mobilidade: capacidade de se mover entre ambientes de execuções, utilizando muitas vezes uma rede de computador. O estado dos dados do agente podem ser transportados ou não como o agente durante a movimentação. Algumas propriedades que se destacam em sistemas multiagentes são: cada agente possui informação ou capacidade incompleta para solucionar um problema e, portanto, tem uma visão limitada; não há controle global do sistema; dados são descentralizados; e a computação é assíncrona [SYCARA98]. Em Zangh et al. [ZHANG+04] é dito que sistemas multiagentes oferecem uma abordagem flexível, modular, integrada e extensível para resolver problemas de comunicação, computação distribuída e integração em aplicações na área de energia elétrica. Para sistemas SCADA, o uso de plataforma de agentes possibilita [PRAYURACHATUPORN+01]: a) Independência de localização: oferece o acesso ao agente independente do seu local de execução, permitindo a implementação de mecanismos de tolerância à falhas; b) Independência de plataforma: quando diferentes ambientes de execução interagem, e cada qual executa em uma plataforma distinta. Os agentes podem operar em qualquer uma das plataformas de forma transparente. Apesar dos sistemas multiagentes apresentarem papel importante no

17 desenvolvimento de aplicações computacionais, o mero fato de que um domínio particular do problema possui origens de dados distribuídas não implica necessariamente que uma solução baseada em agentes seja a mais apropriada [FERNANDES03]. 2.2 ABORDAGENS DE ARQUITETURA PARA SISTEMAS DE AUTOMAÇÃO Ebata et al. [EBATA+00] comentam que a arquitetura moderna para SCADA está baseada no modelo RISC-UNIX-TCP/IP, um modelo de sistema distribuído aberto, mas que não contempla o uso de tecnologias Internet e Intranet devido a questões de desempenho e confiabilidade para sistemas em tempo real. O trabalho propõe a utilização de uma intranet como plataforma para um sistema SCADA e relata resultados preliminares de testes, focando em tempo de resposta de comunicações e confiabilidade. O tratamento dessas questões é resolvido com a construção de um middleware que incorpora funções como sistema de gerenciamento de dados em memória, comunicação baseada em multicast sobre IP e wide area cluster. Buse et al. [BUSE+03] descrevem uma arquitetura genérica que aplica a metodologia de sistemas multiagentes em automação de subestações. Os autores alegam que os sistemas de automação e controle de sistemas elétricos atuais, baseados no modelo SCADA, apesar de oferecerem desempenho e confiabilidade adequados, não apresentam flexibilidade no que diz respeito ao acesso aberto às informações. Acrescentam também que modelos alternativos, como sistemas cliente-servidor e Web têm a desvantagem de serem algumas vezes inflexíveis, centralizarem as funcionalidades de monitoramento do sistema elétrico e também exigirem muita largura de banda. Por sua natureza inerentemente distribuída, os sistemas elétricos são alvo de aplicação de sistemas de controle baseados em

18 agentes, os quais provêem maior autonomia para cada parte constituinte do sistema elétrico. Nessa arquitetura, agentes são designados para diferentes funções, tais como monitorar e controlar o sistema elétrico, ler dispositivo, armazenar dados, prover interface gráfica, e se comunicam por meio de mensagens ACL sobre um ambiente de runtime. A recuperação de informações pode ser feita por meio de agentes móveis, os quais trafegam pela rede, ou por meio da identificação de agentes responsáveis por tarefas específicas e troca de mensagens entre eles. Hopkinson et al. [HOPKINSON+03] reportam o desenvolvimento de um ambiente de simulação distribuído. Eles alegam que os simuladores atuais na área de sistemas elétricos de potência modelam de maneira precisa sistemas de potência do passado, os quais eram controlados como grandes parques regionais de potência sem elementos significativos de comunicação. Entretanto, uma vez que sistemas de potência estão cada vez mais adotando sistemas de controle e proteção que fazem uso de redes de computadores, tais simuladores estão cada vez menos capazes de predizer o provável comportamento da malha de potência resultante. De forma semelhante, as ferramentas usadas para avaliar novos protocolos e sistemas de comunicação foram desenvolvidas sem a devida atenção aos papéis que eles podem ter em cenários de potência. A ferramenta proposta em [HOPKINSON+03] utiliza múltiplos sistemas comerciais e de pesquisa para preencher a lacuna. Segundo os autores, o sistema permite que usuários encapsulem de maneira transparente o comportamento de sistemas complexos que abranjam domínios múltiplos por meio do uso de um framework simples baseado em agentes. Li et al. [LI+02] consideram um sistema SCADA como uma aplicação completamente baseada em Web, decompondo cada pedaço do software de aplicação em um conjunto de componentes de um website. Os autores esquematizaram o projeto de um subsistema de controle de supervisão e de um subsistema de aquisição de dados com base no modelo de arquitetura em três

19 camadas, o qual adiciona flexibilidade e escalabilidade ao sistema e permite que este se beneficie de toda a tecnologia Internet disponível, tais como arquitetura aberta, protocolo de comunicação padrão e módulos de aplicação maduros. É proposto o uso de uma RTU inteligente que contém módulos para aquisição de dados e recepção de comandos e um NCU (Network Computing Unit), o qual é construído com tecnologia de agentes sobre Java e suporta protocolo HTTP (Hypertext Transfer Protocol). A RTU interage com a camada central do sistema implementada por aplicações que executam em servidor Web, a qual, por sua vez, serve de acesso aos clientes utilizando Web browsers. Para manter as informações constantemente atualizadas nos clientes, os browsers executam pooling com o servidor via tecnologia Java Applets. Prayurachatuporn e Benedicenti [PRAYURACHATUPORN+01] descrevem como o desenvolvimento de um protocolo de serviço de diretório, que utiliza tecnologia de agentes em um ambiente de runtime chamado TEEMA (TRLabs Execution Environment for Software Agents), aumentou a confiabilidade teórica do sistema SCADA. Segundo os autores, a utilização da tecnologia de agentes é adequada por permitir distribuição, a qual inerentemente promove redundância, e modularidade, a qual promove versatilidade. As características principais de um sistema de agentes que são vantajosos para um sistema SCADA são: modularidade; autonomia, que possibilita ao usuário desempenhar tarefas de forma colaborativa com o computador; pró-atividade e mobilidade. A utilização de agentes móveis no protocolo de um sistema de controle distribuído provê [PRAYURACHATUPORN+01]: a) um ambiente runtime para que os agentes possam ser executados; b) uma interface padrão para interações; c) serviços para a criação, migração e encerramento de agentes móveis; d) suporte à mobilidade e comunicação de agentes enquanto provê segurança tanto para os hosts quanto para os agentes.

20 Agentes têm que ser identificados de maneira inequívoca no ambiente em que operam. Isso possibilita que o controle, a comunicação, a cooperação e a coordenação dos agentes ocorram. Um agente é localizado através do serviço de diretórios e é acessado onde quer que esteja, o que possibilita a implementação de um mecanismo seguro quanto a falhas, no qual múltiplas cópias de um agente podem ser ativadas em diferentes localidades, melhorando assim, de maneira efetiva, a confiabilidade do sistema. Uma outra aplicação da tecnologia de agentes no contexto de proteção e controle de sistemas elétricos, funcionando sobre uma intranet, é descrita por Shono et al. [SHONO+02]. O propósito é a redução do custo total de manutenção e gerenciamento dos equipamentos físicos envolvidos no sistema. Os autores comentam que algumas plataformas de agentes não oferecem garantias de operação quando restrições temporais são impostas, e propõem uma plataforma para agentes móveis em tempo real, denominada RTMAP (Real Time Mobile Agent Platform) a qual permite: a) sincronizações entre múltiplos agentes em um ambiente distribuído; e b) redundância para resolver problemas de comunicação. Uma aplicação descrita no trabalho de Shono et al., a qual utiliza a plataforma de agentes em tempo real, subdivide os agentes em: a) Agentes de configuração: configuram relés de proteção. De acordo com o comportamento do sistema elétrico, esses agentes podem permanecer em um relé específico para mudar suas configurações de proteção e controle; b) Agentes de análise: coletam dados para análise de falhas no sistema elétrico. Esses agentes móveis também são responsáveis por planejar suas próprias rotas de viagem entre os dispositivos e, caso as informações coletadas sejam insuficientes para análise, executar um replanejamento de rota;

21 c) Agentes de patrulha: coletam informações sobre as condições de operação dos equipamentos. Seki et al. [SEKI+02] desenvolveram um protótipo de um sistema de processamento de informação de sistemas de energia baseado na Web. Entretanto, em seu estágio inicial, o protótipo contempla apenas informações sobre falhas de energia. Sua arquitetura, que segundo os autores assegura flexibilidade e escalabilidade em sistemas de energia, consiste de: a) uma camada de aplicação baseada em Web browser; b) uma camada de modelo de informação que reflete o comportamento do sistema de energia; e c) uma camada de gerenciamento de objetos distribuídos utilizando CORBA (Commom Object Request Broker) e OS/Network. Yavnai [YAVNAI94] apresenta uma arquitetura distribuída e descentralizada para a organização, comando, controle e comunicação de um sistema multiagentes funcionando de forma cooperativa e autônoma. A motivação para a operação cooperativa autônoma tem sua sustentação na necessidade de executar missões críticas com restrições de tempo, recursos e disponibilidade que estão além da capacidade de um único agente. No caso dos agentes estarem geograficamente distribuídos, a operação cooperativa é uma abordagem adequada, fornecendo suporte a: a) compartilhamento de informações; b) compartilhamento de recursos; c) alocação eficiente de recursos; d) respostas orientadas a contexto e situação; e) robustez e flexibilidade sob mudanças de condições; f) redundância. Uma característica chave da arquitetura proposta por Yavnai é que todos os agentes são idênticos em relação à percepção, ao processamento de informação,

à tomada de decisão, à capacidade de comunicação, independentemente de sua missão. Dessa forma um agente pode ser facilmente substituído no caso de falha. 22

23 3 ANÁLISE DE TECNOLOGIAS PARA SISTEMAS DE AUTOMAÇÃO A construção de sistemas de automação de subestações implica no estabelecimento de um arcabouço tecnológico, abrangendo elementos para comunicação, tecnologias destinadas à construção de interfaces para o usuário e integração com sistemas legados. O foco deste capítulo é discorrer sobre esses assuntos, já apresentando resultados comparativos entre os elementos de comunicação inclusive com uma plataforma de agentes, e apontando algumas técnicas para a construção da interface com o usuário via Web. 3.1 TECNOLOGIAS PARA SISTEMAS DISTRIBUÍDOS Muitas tecnologias de interconectividade têm sido abordadas e descritas na literatura. Dentre elas, pode-se destacar sockets, Java RMI (Remote Method Invocation), web services e tecnologia de multiagentes, as quais são descritas na seqüência. Testes comparativos sob a ótica de desempenho são realizados para avaliar a adequação de cada uma delas no âmbito de sistemas de automação de subestações. 3.1.1 Sockets Sockets são estruturas que permitem que funções de software se interconectem. O termo é usado para especificar uma estrutura que faz com que rotinas de software na mesma máquina ou em máquinas diferentes possam se comunicar. Sockets são implementados em várias linguagens de programação (Assembler, C, C++, Java, dentre outras) para a maioria dos sistemas operacionais existentes. Também são utilizados como núcleo para tecnologias mais sofisticadas de comunicação, entre elas RMI, CORBA e Web Services.

24 3.1.2 Java RMI RMI é um middleware que permite que um objeto sendo executado em uma JVM (Java Virtual Machine) invoque métodos de um objeto sendo executado em outra JVM, ou seja, RMI provê um mecanismo de comunicação entre programas escritos na linguagem Java. RMI define um conjunto de interfaces remotas que podem ser utilizadas para criar objetos remotos. Diferentemente de sockets, que disponibiliza uma API (Application Program Interface) básica para manipulação de estruturas de comunicação, a API RMI fornece uma estrutura orientada a objetos de alto nível que encapsula toda a comunicação básica para acessar métodos remotos. 3.1.3 Web Services Web Services são componentes de software criados a partir de conjuntos de protocolos e padrões abertos para computação distribuída na Internet definidos pelo W3C (World Wide Web Consortium) 1. Os Web Services utilizam XML (Extensible Markup Language) como base para sua pilha de protocolos e suas principais características são: independência de implementação e plataforma; permite comunicação síncrona e assíncrona; arquitetura fracamente acoplada e orientada a serviço; reaproveitamento dos serviços distribuídos na rede e facilidade de utilização. A principal desvantagem dos Web Services reside no baixo desempenho quando essa tecnologia é comparada com outras, tais como RMI e CORBA, como conseqüência de seu formato baseado em texto. 1 Consórcio internacional que busca desenvolver e padronizar tecnologias interoperáveis na Web.

25 3.1.4 Implementações de Plataformas de Agentes A tecnologia de multiagentes tem sido reconhecida como um conceito chave na construção de sistemas de controle distribuído, inteligente, autoorganizador e robusto [LEEUWEN+97]. Existem muitas implementações de plataformas multiagentes. No trabalho de Vrba [VRBA03] são analisadas várias delas: JADE (CSELT), FIPA-OS (Emorphia), ZEUS (British Telecom), JACK (Agent Oriented Software), GRASSHOPPER 2(IKV++ Technologies AG), ADK (Tryllian), JAS (Fujitsu, HP, IBM, Sun), AgentBuilder (IntelliOne Technologies), MadKit (MadKit Team), Comtex Agent Plataform (Communication Technologies), Bee-gent (Toshiba) e Aglets (IBM Japan). Vrba faz uma análise mais específica sobre desempenho, entre as plataformas JADE, FIPA-OS, ZEUS e JACK. De maneira geral, a plataforma JADE, em seus testes, apresentou maior desempenho com relação às outras avaliadas. Os testes consistiram de um esquema serial e outro paralelo. No esquema serial, a comunicação entre um par de agentes opera de maneira sincronizada, ou seja, o agente remetente envia a segunda mensagem apenas depois de receber a resposta do agente destinatário relativa à primeira mensagem enviada. No esquema paralelo, o agente remetente envia todas as mensagens de uma só vez. Os testes também contemplaram a comunicação entre um par de agentes e entre dez pares de agentes. Além disso, contemplaram uma configuração com apenas um servidor, com um servidor e duas máquinas virtuais Java e com dois servidores. Baseado na abrangente avaliação feita na publicação supramencionada, adotou-se neste trabalho a plataforma JADE, descrita em detalhes no capítulo 4. JADE provê um arcabouço para a implementação de sistemas multiagentes por meio de middleware compatível com as especificações elaboradas pela FIPA (Foundation for Intelligent Physical Agents), uma organização da IEEE Computer Society responsável por promover tecnologia baseada em agentes e a

26 interoperabilidade de seus padrões com outras tecnologias [BELLIFEMINE +05a]. As especificações tratam da linguagem de comunicação entre agentes a ACL, protocolos de interação e teoria de atos comunicativos, do controle e gerenciamento de agentes em uma plataforma específica e entre plataformas distintas, do transporte e representação de mensagens através de diferentes protocolos de rede, e de entidades abstratas que são requeridas para a construção de serviços e da própria plataforma de agentes [FIPA06a]. Uma vez que essa tecnologia é implementada inteiramente em Java, a plataforma pode ser distribuída em diversas máquinas, as quais não precisam ter necessariamente o mesmo sistema operacional. 3.1.5 Comparativo de Desempenho das Tecnologias Uma das maneiras de avaliar a adequabilidade das tecnologias de computação distribuída, mencionadas neste trabalho, na questão da automação de subestações consiste em testes de desempenho. Entretanto, deve-se ter em mente que soluções que utilizam diferentes tecnologias de distribuição podem, e devem, ter diferentes arquiteturas. Quando se utilizam sistemas multiagentes, por exemplo, tem-se por princípio a implantação de inteligência local, a qual minimiza a necessidade de comunicação. Pode-se dizer, portanto, que a adequabilidade de sistemas multiagentes em relação à outra tecnologia não pode ser julgada apenas pelo seu desempenho apresentado, mas todo o seu paradigma deve ser considerado. Os testes de desempenho fornecem, mesmo assim, importantes informações que podem subsidiar decisões quanto à utilização dessas tecnologias. O estudo contempla um servidor contendo um simulador de subestação, a qual contém interfaces para as diferentes tecnologias. Os clientes fazem requisições à subestação. Nos testes, todos os clientes implementados com as tecnologias

27 testadas fazem a mesma requisição, a saber, a recuperação dos pontos de estado da subestação de maneira síncrona. O cliente da plataforma JADE necessita uma adaptação para funcionar de maneira síncrona, isto é, o fim da requisição se dá no momento em que o servidor responde com os dados solicitados. Os clientes foram implementados como testes do JUnit, um framework de testes de regressão que facilita a criação de testes unitários em Java [JUNIT06]. Essa modalidade de teste se concentra na verificação da menor unidade de um projeto de software, neste caso, o método do cliente que interage com o servidor da subestação. A execução dos clientes foi realizada pela ferramenta JMeter, uma aplicação desktop puramente Java que permite a execução de testes funcionais e a medição de desempenho [JMETER06]. Testes foram executados para comparar as tecnologias levando-se em consideração o número de requisições simultâneas a serem atendidas pelo servidor e o tempo de resposta desse atendimento. O produto utilizado nos testes com Web Services foi o Sun Java Application Server Platform Edition 8 [PE06]. Ele oferece um utilitário que gera, a partir de uma descrição de serviço codificada no padrão WSDL (Web Service Description Language), as classes Java utilizadas para a implementação do servidor e do cliente de web services. Os testes foram executados por duas máquinas clientes acessando de forma não simultânea um servidor, tendo todos os computadores as mesmas características de processamento e memória (Pentium IV, 2,6 GHz, 512 MBytes de memória interna, com sistema operacional Windows XP). Esse procedimento foi utilizado para minimizar um possível impacto da rede corporativa nos resultados. Com este mesmo objetivo, cada conjunto de requisições simultâneas (5, 10, 25, 50, 100) do teste foi executado três vezes, sendo computadas as médias das amostras de tempo de atendimento das requisições dos dois computadores cliente. Os resultados obtidos, que podem ser visualizados na Figura 1, demonstram que a tecnologia RMI apresenta melhor desempenho que as demais.

28 Isso ocorre porque, embora RMI seja baseada em sockets, implementa várias otimizações que influenciam diretamente no desempenho, como um pool para a reutilização das conexões sockets instanciadas. Na implementação com sockets, o recurso de pool não foi utilizado, o que pode ser verificado no gráfico pela degradação dos resultados com o aumento da carga. Nesse caso, a influência no desempenho foi maior no cliente, devido ao elevado número de conexões sockets criadas pelo sistema operacional. Embora RMI adicione várias camadas de abstração sobre a tecnologia sockets, ele apresenta um desempenho melhor na relação carga/desempenho devido às otimizações fornecidas em sua API. FIGURA 1 TESTES DE DESEMPENHO ENTRE AS TECNOLOGIAS RMI, WEB SERVICES, SOCKETS E AGENTES (JADE). Web services apresenta um tempo de resposta aceitável para poucas requisições simultâneas. Quanto maior o número de requisições simultâneas, maior o consumo de recursos da máquina, tanto no cliente como no servidor, e o tempo de resposta apresenta degradação mais acentuada. A tecnologia de agentes utilizando a plataforma JADE teve desempenho melhor que web services, porém pior que RMI e sockets. Entretanto, deve-se observar que a tecnologia de agentes, quando utilizada de acordo com sua filosofia, ou seja, considerando inteligência local, não apresenta alta demanda de

29 comunicação. Deve-se considerar também que o desenvolvimento na plataforma JADE demanda maior elaboração por se tratar de um modelo assíncrono de comunicação e por possuir uma estrutura própria de desenvolvimento baseada em comportamentos. Diante dos resultados dos testes e das discussões, considerou-se que o desempenho apresentado pelo JADE não é um fator impeditivo para a sua adoção como tecnologia para computação distribuída. Evidentemente, se o seu comportamento nos experimentos indicasse uma incapacidade para lidar com um número elevado de requisições simultâneas, ou então se os tempos de resposta fossem substancialmente superiores ao pior caso, a sua adoção seria descartada. No capítulo 4 a plataforma JADE é explorada em mais detalhes. 3.2 CAMADA DE APRESENTAÇÃO A camada de apresentação tem o propósito de expor a lógica de negócio e permitir a interação do usuário com a aplicação. Para aplicações baseadas em internet essa camada é conhecida também como camada Web. A utilização de interfaces de usuário baseadas em Web browser traz significativas vantagens [FOWLER03], [JOHNSON02], [JOHNSON04], entre elas: a) a facilidade de instalação da aplicação, já que ela é hospedada em um servidor e apenas o browser é necessário no computador do usuário, funcionando como cliente universal; b) desacoplamento do usuário com as tecnologias e plataformas utilizadas no servidor; c) menor esforço de configuração, pois normalmente firewalls são configurados para liberar o tráfego de rede na porta 80 utilizada pelo servidor de páginas HTML (Hypertext Markup Language); d) menor exigência de poder computacional no usuário, já que maior

30 parte do processamento ocorre no servidor. Para que a camada Web seja construída com uma estrutura lógica adequada, recomenda-se a utilização de um padrão de arquitetura denominado MVC (Model View Controller) [FOWLER03]. O MVC foi proposto Trygve Reenkaug para a plataforma Smalltalk 2 na década de 70 e desde então tem influenciado a maioria dos frameworks voltados para interface com o usuário e a forma de pensar sobre o design de interfaces. O MVC divide a camada de apresentação em três elementos distintos: a) Modelo: elemento não visual que contém informações a respeito do domínio da aplicação e as regras de negócio que governam o acesso e a modificação desses dados; b) Visão (view): constitui a exibição do modelo em uma interface de usuário. Como exemplo, se no modelo há um objeto que representa um equipamento elétrico, a visão implementará um mecanismo como uma página HTML para mostrar as informações do equipamento e permitir a emissão de comandos para interação com o modelo; c) Controlador (Controller): recebe os comandos da visão e baseando-se nas informações da requisição, determina qual parte da lógica de negócio deve ser invocada e atualiza o modelo. Conforme o retorno da invocação, o controlador seleciona qual visão deve ser apresentada ao usuário. A visão interage com o modelo para a sua exibição. Como todas as requisições são canalizadas ao controlador, ele torna-se um local adequado para implementação de regras de segurança, log de acessos e validações de argumentos das requisições. Segundo Fowler [FOWLER03], a utilização do MVC favorece a coesão, pois implica em melhor distinção de responsabilidade entre os elementos que tratam 2 Linguagem de programação pioneira na introdução dos conceitos de programação orientada a objetos, desenvolvida pela Xerox.

31 da interação com o usuário. Ainda, um ponto chave na separação entre visão e modelo é a direção da dependência, pois a primeira deve depender do segundo, mas não o contrário. Assim, como o modelo está isolado da visão, tipos diferentes de visão podem ser elaboradas sem que o modelo seja alterado. Em aplicações desktop, é possível que o modelo atualize automaticamente a visão quando ele sofrer alterações de estado. Neste caso o MVC é dito MVC push [JOHNSON02], [JOHNSON04], pois as atualizações ocorridas no modelo são empurradas para a visão. Para preservar o relacionamento de dependência unidirecional entre os dois elementos, da visão para o modelo, a implementação pode utilizar o design pattern Observer [GAMMA+95]. Neste padrão, são inseridas no modelo referências de observadores interessados em sua mudança de estado. O modelo reconhece apenas a interface desses observadores e, quando as mudanças ocorrem, ele notifica tais referências, não dependendo das implementações subjacentes a elas. Por outro lado, em aplicações Web com interfaces de usuário em HTML, o estilo de comunicação request-response apresenta um impedimento para a atualização automática da visão pelo modelo. Assim, o MVC é tido como MVC Web ou MVC pull, pois a visão deve sempre buscar as informações do modelo para exibição. Para o desenvolvimento da camada de apresentação, optou-se por utilizar neste trabalho a plataforma JEE (Java Enterprise Edition) [SUN06] por motivos de facilidade de integração com o framework JADE, uma vez que ambos utilizam a linguagem Java, e devido à robustez proporcionada por essa plataforma. Além disso, em virtude de definições arquiteturais pré-estabelecidas no ambiente corporativo onde este trabalho está sendo desenvolvido, as aplicações com interface Web devem ser preferencialmente desenvolvidas em plataforma JEE. Na plataforma JEE, o elemento modelo do MVC é comumente implementado em Java Beans, o controlador em Servlets e a visão em JSP (Java

32 Server Pages). Java Beans são classes Java comuns que aderem a três convenções de codificação [SUN06]: possuem um método construtor sem parâmetros, implementam a interface java.io.serializable e possuem métodos públicos para acessar e modificar suas variáveis-membro. Servlets são programas Java que atendem a uma especificação padronizada pela SUN [SUN06] na qual se estabelece uma API para a comunicação entre o servidor Web e o programa Java. Dessa forma, os programas Servlets são capazes de receber requisições remotas de Web browser através do protocolo HTTP e produzir as respostas. As Servlets são preparadas para trabalhar em ambiente multithreaded e oferecem recursos para a implementação de aplicações Web, como manutenção do estado de sessões de usuário. JSP, assim como Servlets, é uma tecnologia para geração de páginas dinâmicas. A diferença reside no fato de que em Servlets todo o conteúdo é gerado explicitamente por programação Java, enquanto que no JSP é possível fazer uma distinção entre conteúdo estático e dinâmico através da inserção de marcadores especiais na página estática para invocar código Java [SUN06]. Além da opção de implementar o MVC através da construção de software de forma a atender um propósito específico, existem diversos frameworks Java disponíveis, comercializados ou sob licenças de software livre, que facilitam a implantação de uma arquitetura MVC, tais como Java Server Faces [JSF06], Spring MVC [SPRING06], Struts [STRUTS06]. Em [BARRETO06] é realizada uma análise comparativa sobre esses frameworks e os resultados apontam para a adoção do JSF. 3.2.1 Desafios Decorrentes da Utilização da Camada Web No âmbito de sistemas de automação de subestações, alguns desafios são

33 impostos quando as interfaces baseadas em Web são utilizadas. A riqueza de informações visuais exigida na operação de uma subestação não é suprida pelos componentes de HTML, pois são limitados e não expansíveis. O uso de imagens para representar diagramas unifilares e outros esquemas elétricos não é apropriado, pois as informações contidas nessas imagens mudam com alta freqüência e a atualização constante no browser geraria alto tráfego de informações na rede. Frameworks para a camada Web, como o JSF, trazem consigo componentes visuais mais sofisticados se comparados aos elementares do HTML, contudo ainda fica a lacuna para a representação dos diagramas. O sistema de automação deve lidar com mecanismos de alarmes, avisos e notificações, eventos estes que ocorrem no sistema quando há mudança de estado de determinado componente elétrico, quando valores limiares são atingidos para determinada grandeza elétrica, e assim por diante. Alguns desses eventos devem ser enviados para a interface do operador para informá-lo ou para que ações sejam tomadas. O modelo de comunicação request-response utilizado entre o browser e o servidor impede que alterações ocorridas em objetos da aplicação reflitam automaticamente no cliente. É necessário que o browser execute uma nova requisição para obter as informações atualizadas. Tradicionalmente, cada requisição envia todos os dados do formulário HTML e recebe a página completa para ser redesenhada, mesmo quando há pouca ou nenhuma alteração nos objetos, gerando com isso um tráfego de rede maior que o necessário. Visando abordar as questões mencionadas acima com a utilização de padrões abertos, foram identificadas duas tecnologias, SGV (Scalable Vectorial Graphics) e AJAX (Asynchronous JavaScript And XML), descritas na seqüência. 3.2.2 SVG SVG (Scalable Vectorial Graphics) é uma linguagem para descrever

34 gráficos bidimensionais estáticos ou animados em XML, padronizada pelo W3C [W3C06]. As vantagens do SVG em relação aos formatos de imagens tais como JPG (Joint Photographic Experts Group) ou GIF (Graphics Interchange Format) são [W3SCHOOLS06a]: arquivos de imagens são representados via XML, que podem ser lidos e interpretados em uma gama maior de ferramentas; as imagens SVG são escaláveis, não perdendo a qualidade com alterações na resolução; facilidade de busca dentro imagem; SVG é um padrão aberto, ao contrário de seu principal concorrente, o Flash, que é uma tecnologia proprietária da empresa Adobe [FLASH06]. A principal desvantagem do SVG é a falta de suporte pelos Web browsers. Atualmente, o Internet Explorer e o Mozilla requerem a instalação de um software adicional para a interpretação de arquivos SVG. Entretanto, outros como o Firefox, já possuem suporte nativo. Dentre as representações gráficas suportadas pelo SVG estão texto, linhas, retângulos, círculos, elipses, polilinhas e polígonos. O uso de gradientes, para realização de transições suaves entre cores, e filtros, para produzir efeitos como agudização ou borramento em imagens, também é suportado. Como o SVG é definido em XML, sua estrutura pode ser manipulada dentro do browser através de JavaScript. Esse mecanismo oferece condições de alterar regiões da imagem apresentada ao usuário de uma maneira eficiente. 3.2.3 AJAX AJAX é uma técnica de desenvolvimento de aplicações Web cujo propósito é tornar ágil o processo de comunicação entre o browser e o servidor, aumentando a interatividade, velocidade e usabilidade da interface oferecida ao usuário. Isso é obtido por meio da redução do tráfego de dados com o servidor através de um

35 processo de comunicação assíncrono, de forma que a página inteira não precise ser recarregada a cada requisição, mas somente as partes dela que necessitem de atualização [W3SCHOOLS06b]. AJAX é baseado em tecnologias padronizadas como JavaScript, HTML e XML. Com o JavaScript as requisições HTTP são remetidas ao servidor por intermédio de um componente existente na API do browser. Uma função em JavaScript é vinculada a esse componente para que seja notificada quando a resposta da requisição acontecer. Esta função recebe as informações e procede a atualização de elementos da página, os quais podem ser acessados como nós de uma árvore XML. Embora a técnica possa reduzir o volume de dados trafegados pela rede e aumentar a qualidade das interfaces Web, é importante observar que o servidor tende a receber um número maior de requisições HTTP em virtude do refinamento da interatividade com o usuário. 3.3 AVALIAÇÃO DA MÁQUINA VIRTUAL JAVA O mito de que aplicações em Java são lentas em relação àquelas desenvolvidas em linguagens de alto desempenho foi questionado nos testes de laboratório deste projeto, com o objetivo de obter uma real avaliação a respeito de seu desempenho frente a outras tecnologias, e sua pertinência a sistemas de automação. Os testes foram realizados utilizando uma máquina Pentium 2 com 128 MBytes de memória. As máquinas virtuais Java utilizadas foram desenvolvidas pela Sun [SUN06], nas versões 1.4.2 e 5.0. As opções Hotspot server, utilizado para otimizar o desempenho no lado servidor, e Hotspot client, utilizado para otimizar o desempenho no lado cliente, foram usadas em ambas as versões. Um conjunto abrangente de algoritmos foi utilizado para que os testes

36 pudessem avaliar os principais aspectos. Uma observação importante é que ambas as versões da JVM apresentaram desempenhos similares no sistema operacional Linux, mas a versão 5.0 apresentou desempenho bem melhor em relação à versão 1.4.2 no sistema operacional Windows. A Tabela 1 apresenta um resumo dos testes de desempenho comparativo entre as linguagens Java e C++, com as duas versões de JVM (1.4.2 e 5.0) e utilizando uma série de algoritmos. TABELA 1 - COMPARATIVO DE DESEMPENHO ENTRE DUAS VERSÕES DE JVM E ENTRE AS LINGUAGENS JAVA E C++, UTILIZANDO UM CONJUNTO ABRANGENTE DE ALGORITMOS (TEMPO MEDIDO EM SEGUNDOS), EXECUTADOS EM LINUX. JVM 1.4.2 JVM 5.0 C++ ALGORITMO HOTSPOT CLIENT HOTSPOT SERVER HOTSPOT CLIENT HOTSPOT SERVER fibo 39,0 29,4 51,2 30,1 59,1 hash2 24,0 19,5 24,1 19,9 0,4 hash 6,0 5,9 5,1 5,4 2,0 heapsort 51,0 46,9 46,0 46,2 47,3 matrix 51,0 35,2 53,7 39,2 28,1 methcall 38,0 4,8 33,4 4,9 26,2 nestedloop 46,0 37,6 47,7 37,8 20,0 strcat 7,0 5,4 5,3 4,7 3,4 random 63,6 39,3 69,6 46,5 21,0 sieve 25,0 22,9 26,1 20,2 19,3 Em [LEA06] são fornecidos dados comparativos que foram confirmados pelos testes realizados neste trabalho. Os algoritmos utilizados são os mesmos daqueles apresentados na referência. A versão 5.0 da JVM não é contemplada nos testes descritos pela referência, mas foram realizados para enriquecer o comparativo e comprovar o bom desempenho da tecnologia. Os resultados, em geral, confirmam que o desempenho de Java não é necessariamente inferior ao de C++, variando de acordo com os aspectos dos algoritmos. O desempenho de Java com o Hotspot Server mostrou ser melhor do que o de Java com o Hotspot Client. Fica também evidente a discrepância de desempenho dependendo da natureza dos recursos computacionais necessários, levando à conclusão de que, quando o desempenho é uma questão chave, a

natureza do tipo de processamento específico da aplicação deve ser levada em consideração na escolha da linguagem. 37 3.4 INTEGRAÇÃO COM O SISTEMA LEGADO As possibilidades de integração oferecidas pela plataforma Java são amplas, incluindo conectores para acesso a banco de dados e serviços de mensageria, e suporte a middlewares como CORBA, RMI e web services. Quando há necessidade de integração sem a utilização de um middleware, a linguagem Java oferece uma tecnologia chamada JNI (Java Native Interface) [SUN06]. Essa tecnologia permite a integração de código escrito em Java, executado numa máquina virtual Java, com aplicações e bibliotecas escritas em outras linguagens. No caso de sistemas de automação, essa tecnologia apresenta muito potencial, uma vez que tipicamente existe toda uma infra-estrutura em funcionamento, a qual deve ser encarada como uma estrutura legada. Desta maneira, a evolução de um sistema de automação pode ocorrer de forma gradativa, mantendo a infra-estrutura existente e construindo a nova sem o impacto causado por substituições de componentes de software.

38 4 A PLATAFORMA JADE JADE é um framework para desenvolvimento de sistemas multiagentes sob licença de software LGPL (GNU Lesser General Public Licence) e é usado comercialmente em algumas empresas como a Telecom Italia LAB, Whitestein Technologies AG e Acklin B.V. [JADE06]. Ele oferece um ambiente de execução aos agentes, denominado de container, bibliotecas para o desenvolvimento de agentes e ferramentas de apoio, conforme descritos a seguir. 4.1 CONTAINER DE AGENTES JADE Um container representa uma instância de execução do JADE. Vários containers JADE podem estar interligados formando uma plataforma, onde os agentes podem se comunicar e se movimentar de forma transparente. O primeiro container a ser instanciado é chamado de main container e os demais são containers secundários que se registram no primeiro. Assim, em cada plataforma existe apenas um main container. No main container estão hospedados dois agentes especiais: AMS (Agent Management System) e DF (Directory Facilitator). O AMS é responsável por garantir a unicidade de nomes de agentes na plataforma e pelo ciclo de vida de agentes nos containers secundários. De acordo com a especificação FIPA, cada agente Jade é identificado por um Agent Identifier (AID), que o distingue dos demais na plataforma. O DF oferece um serviço de páginas amarelas, onde os agentes podem procurar serviços ofertados por outros agentes para atender suas necessidades. A Figura 2 mostra duas plataformas. A primeira, chamada de Platform 1, é composta por três containers. Os agentes A1, AMS e DF estão hospedados no Main container. Os agentes A2 e A3 estão no Container 1 enquanto que o agente A4 está

39 hospedado no Container 2. O Container 1 e o Container 2 se registram no Main container para estabelecer a plataforma. A segunda plataforma, chamada de Platfform 2, contém apenas um container (Main container) abrigando os agentes A5, AMS e DF. FIGURA 2 CONTAINERS JADE E PLATAFORMAS [JADE06] 4.2 O MODELO DE DESENVOLVIMENTO DO JADE Um agente é definido por meio de uma classe Java que estende a classe jade.core.agent. Pode-se reimplementar métodos especiais invocados pelo container em certos momentos do ciclo de vida do agente: a) Método setup(): invocado na criação do agente, útil para realizar inicializações de variáveis ou de comportamentos, descritos mais adiante;

40 b) Método takedown(): invocado quando a instância do agente está sendo eliminada do container. Para destruir uma instância, deve-se invocar explicitamente o método dodelete() do agente. O comportamento de um agente, ou seja, as ações que ele toma e como ele reage ao ambiente de execução, é especificado em classes que estendem jade.core.behaviours.behaviour ou em uma de suas subclasses. Há classes específicas para comportamentos que devem ser executados de tempos em tempos (TickerBehaviour), continuamente (CyclicBehaviour), uma única vez (OneShotBehaviour), entre outras. Um agente pode conter qualquer número de comportamentos. Eles são executados de forma não preemptiva, ou seja, a execução do próximo comportamento só ocorre quando o atual finalizar. Cada vez que um comportamento entra em execução, o método action da classe é invocado servindo, portanto, como local para a implementação de regras de negócio no agente. Dentro de um comportamento, tem-se uma referência à instancia do agente ao qual ele pertence, possibilitando o acesso às suas propriedades. 4.3 COMUNICAÇÃO ENTRE AGENTES O paradigma de comunicação adotado no JADE é o de troca de mensagens de forma assíncrona. Cada agente possui uma caixa de entrada onde o container insere as mensagens recebidas de outros agentes. Cada vez que uma mensagem é postada na fila o agente receptor é notificado. A decisão de consumir ou não a mensagem na fila e o momento que isso ocorre fica a cargo da implementação do comportamento no agente. As mensagens trocadas pelos agentes JADE seguem o formato da linguagem ACL definida pela FIPA. Para compor uma mensagem, os principais elementos são: o remetente da mensagem; a lista de destinatários; a intenção da

41 mensagem, por exemplo, se o agente simplesmente está ordenando outro a executar uma tarefa, apenas informando algum fato ou efetuando um CFP (Call for Proposal) para obter considerações sobre um determinado assunto de um grupo de agentes; o conteúdo propriamente dito; a linguagem utilizada para expressar o conteúdo, sendo necessário que ambos os lados da comunicação estejam aptos para a linguagem escolhida; e a ontologia 3 utilizada nas mensagens. Devido a não preempção dos comportamentos no agente, como explicado antes, é importante que a espera por uma determinada mensagem aconteça de forma não bloqueante. Isso faz com que o agente suspenda a execução do respectivo comportamento e só coloque-o novamente na fila de execuções quando alguma mensagem chegar para o agente, dando oportunidade para os demais comportamentos serem executados. 4.4 FERRAMENTAS AUXILIARES Devido à dificuldade de depuração e monitoramento de aplicações multiagentes, algumas ferramentas estão disponíveis no JADE, cada uma sendo também implementada como um agente e disponibilizando uma interface gráfica ao usuário [BELLIFEMINE +05b]. A ferramenta RMA (Remote Monitoring Agent) possibilita iniciar um agente, interromper a execução de plataforma, container ou agente, enviar mensagens a um grupo de agentes, efetuar a migração ou clonagem de agentes, integrar uma plataforma remota, seja ela JADE ou não, à plataforma corrente, etc. A ferramenta DummyAgent permite interagir de uma forma mais refinada com agentes em execução no ambiente, possibilitando o envio e recebimento de mensagens ACL com armazenamento de histórico. 3 Uma especificação formal e explícita dos termos de um domínio e das relações entre eles.

42 Para interagir com o agente de diretórios DF, a ferramenta DF GUI permite registrar, consultar e cancelar o registro de agentes naquele diretório. O Instropector Agent habilita a visualização do ciclo de vida do agente, todas as mensagens por ele trocadas, e a execução passo-a-passo dos comportamentos cadastrados para o agente. Por último, o Sniffer Agent apresenta em diagrama toda a seqüência de mensagens trocadas entre agentes previamente selecionados. Esta ferramenta tem bastante utilidade para realizar uma análise dinâmica das aplicações. 4.5 TOLERÂNCIA A FALHAS Conforme a especificação FIPA, uma mensagem de falha é retornada ao agente remetente quando o agente destinatário não é encontrado. O JADE permite a definição de estratégias para tratar falhas na entrega de mensagens ACL, possibilitando o armazenamento temporário dessas mensagens até que o receptor esteja disponível. Outra característica do JADE para tolerância à falhas é a possibilidade de redundância do container principal (main container). Essa característica evita que a plataforma entre em colapso se ocorrerem falhas no main container, já que existe sempre uma dependência dos containers secundários com o principal. 4.6 INTEGRAÇÕES Como os agentes JADE são construídos em Java, os recursos externos que um agente pode acessar, tais como banco de dados ou serviços na rede, são determinados pelas capacidades da linguagem Java na plataforma J2SE (Java 2 Stardard Edition), e não necessariamente pela plataforma JADE. Em [JADE06] são listados pacotes de software que acrescentam funcionalidades ao framework JADE padrão, incluindo facilitadores para integrações

43 com o ambiente externo, como aplicações Microsoft.NET e J2ME (Java 2 Micro Edition), JMS (Java Messaging Service), Web Services e JMX (Java Management Extentions). O JADE disponibiliza interfaces de programação para aplicações Java comandarem, por exemplo, a iniciação e o ciclo de vida de containers e agentes. Na criação de um agente, objetos da aplicação podem ser informados como parâmetros, servindo posteriormente como ponte de integração entre o agente e a aplicação externa via memória.

44 5 CENÁRIOS DE ARQUITETURA PARA AUTOMAÇÃO A proposta de uma nova arquitetura deve considerar fatores importantes como a integração com o sistema existente, o estado da arte na questão de automação de subestações e os requisitos do usuário. A integração com o sistema legado preserva investimentos realizados e diminui riscos do projeto, favorecendo uma transição suave e sem impactos no processo de migração para a novo sistema. Segundo Prayurachatuporn e Benedicenti [PRAYURACHATUPORN+01], padrões de migração evolucionária podem ser usados para transformar o sistema SCADA existente em um sistema de agentes através da substituição gradativa de componentes pelos seus equivalentes na plataforma de agentes, e ao mesmo tempo prover interfaces para comunicação com os componentes SCADA. A seguir é apresentada uma visão geral do sistema existente na COPEL e são discutidos modelos para estruturar uma nova arquitetura. 5.1 O SISTEMA ATUAL Na COPEL, as subestações estão conectadas, por meio de um protocolo específico do sistema de automação, a cinco centros de operação de distribuição (CODs) e nove centros de operação de transmissão (COEs), espalhados pelas regiões elétrico-geográficas do Estado do Paraná. Esses centros de operação não estão necessariamente conectados entre si, exigindo que cada subestação seja operada exclusivamente por meio do centro de operação ao qual pertence. Esta estrutura rígida acarreta uma necessidade de integração maior entre os centros, de forma que uma subestação possa teoricamente ser gerenciada por qualquer um deles. A disponibilidade de uma rede corporativa de alta velocidade aliada às características de novos sistemas SCADA influenciam a exploração de tecnologias baseadas em agentes e Web para o novo sistema.

45 5.2 MODELOS DISTRIBUÍDOS DE AUTOMAÇÃO DE SUBESTAÇÕES O estudo de possíveis arquiteturas para o sistema de automação distribuída foi baseado em um ambiente constituído de quatro camadas conforme ilustra a Figura 3. A primeira camada é a plataforma do usuário ou operador. A segunda camada diz respeito ao núcleo de interação com o usuário, a qual basicamente consiste de um módulo servidor (seja centralizado ou distribuído) que pode estabelecer conexão com os outros componentes do sistema e gerenciar a segurança de acesso, como autenticação e autorização. A terceira é constituída dos centros de operação (COE/COD), e a quarta camada representa as subestações controladas pelos centros de operação. FIGURA 3 MODELO DE QUATRO CAMADAS DE UM AMBIENTE DE AUTOMAÇÃO DE SUBESTAÇÕES. Os estudos demonstraram que, como primeira alternativa, é possível mesclar as camadas 2 e 3, concebendo um servidor distribuído com unidades servidoras nos centros de operação, não necessariamente em todos. A alternativa derivada dos estudos de cenários aponta para uma arquitetura na qual as camadas 2, 3 e 4 estão presentes em cada subestação, contemplando um servidor que permita a comunicação entre subestações, ou seja, sem a presença de um servidor central. Entretanto, essa arquitetura, extremamente

46 flexível, implica em significativa complexidade de gerência. Dessa forma, um modelo abstrato adequado que contemple um servidor distribuído aponta para a primeira alternativa, ou seja, uma arquitetura com três camadas, como ilustrado na Figura 4. A camada 2 é constituída de um ou mais servidores para prover redundância e anular problemas causados por falhas em um dos servidores. O papel exercido pelos centros de operação (COEs e CODs) é, neste modelo, exercido pelos centros de operação virtuais (COVs), os quais independem de sua localização física. FIGURA 4 MODELO DE TRÊS CAMADAS DE UM AMBIENTE DE AUTOMAÇÃO DE SUBESTAÇÕES. O COV é uma sessão de operação de um conjunto de subestações por parte de uma equipe de operadores. A operação de uma subestação específica pode ser negociada entre COVs, uma vez que a subestação só pode ser controlada em um determinado instante por um único centro de operação. Isso significa dizer que os centros de operação físicos do modelo anterior são substituídos por centros de operação virtuais dinâmicos. Igualmente, um conjunto de operadores pode obter acesso a mais de um COV, por exemplo, numa situação emergencial em que o operador vinculado a um determinado COV necessite acesso a uma subestação vinculada a outro COV.

47 A Figura 5 ilustra o modelo proposto de maneira mais detalhada. É relevante observar que a plataforma multiagentes engloba as camadas 2 e 3. Na camada 3, cada subestação possui um container que pode abrigar vários agentes, cada um representando determinados elementos da subestação e assumindo certos grupos de funções elétricas. O propósito de um container é formar um ambiente para que os agentes possam ser executados. Os agentes da camada 3 interagem com um container principal na camada 2, na qual é feita a comunicação entre a plataforma multiagentes e os operadores por meio do servidor de aplicação. Esse servidor provê serviços básicos, tais como HTTP e autenticação. FIGURA 5 DIAGRAMA DETALHADO DO MODELO DE TRÊS CAMADAS PROPOSTO, INCLUINDO O COV. Este modelo embute em sua arquitetura uma estrutura de negociação entre os agentes que representam os COVs. Dessa maneira, um COV pode negociar a possessão temporária de uma subestação com seu atual proprietário, por meio de regras pré-estabelecidas e regras baseadas no status do sistema. Por exemplo, uma das regras prioritárias consiste no fato de que nenhuma subestação pode ficar desacoplada de um agente operador em qualquer instante. As negociações também levam em consideração os perfis dos operadores

48 envolvidos, estabelecendo regras de prioridade que provêm determinado operador de maior ou menor poder em determinado instante. Por exemplo, a solicitação de controle de uma determinada subestação por parte de um operador de um COV pode ter maior ou menor prioridade de acordo com seu perfil. Esta arquitetura distribuída possibilita que nos agentes das subestações existam funções automatizadas que atuam independentemente do restante do sistema e que as decisões dependentes de mais de uma subestação fiquem a cargo dos COVs. O importante nesse caso é a capacidade que as subestações têm de fornecer as informações necessárias para a tomada de decisão, de forma a não centralizar tarefas específicas que não requerem uma monitoração global. Isso também pode representar uma menor carga nos servidores centrais diminuindo a necessidade de comunicação, de acordo com a filosofia de sistemas multiagentes. Em termos de implementação, cada COV pode ser representado por um agente registrado no serviço de diretório da plataforma JADE. Sempre que uma nova subestação é incorporada ao sistema, ela se anuncia aos COVs localizados por meio do serviço de diretório. O processo de negociação é iniciado assim que a subestação faz uma chamada por propostas (CFP) aos COVs disponíveis. Essa transação é feita de acordo com o protocolo de interação FIPA Contract Net [FIPA06c]. Cada COV tem a opção de devolver uma proposta de aceite ou uma rejeição. O objetivo do processo é estabelecer, por meio de regras pré-determinadas e do estado atual do sistema, o COV e o operador mais adequados para assumir o controle da subestação. Esse processo pode ser visto como um balanceamento de carga, cujos parâmetros poderiam ser a localização geo-elétrica da subestação, a quantidade de operadores disponíveis em cada COV, a sobrecarga de trabalho de cada operador, a complexidade da subestação, entre outros. Os operadores podem, por meio de seus agentes, negociar a transferência de controle de uma determinada subestação com outros ligados ao mesmo COV.

49 Vale salientar que, se a negociação ultrapassar os limites de um COV, quem executa a negociação são os COV envolvidos. No caso da desconexão de um operador, por exemplo, as subestações sob sua supervisão serão distribuídas entre os demais operadores do COV por meio de regras. A decisão final sobre a transferência de cada subestação está a cargo do próprio COV.

50 6 IMPLEMENTAÇÃO DO PROTÓTIPO PARA PROVA DE CONCEITO O desenvolvimento de um protótipo tem como objetivo validar os conceitos embutidos no modelo, apresentados na seção anterior. Entretanto, devido à utilização de um arcabouço tecnológico, a implementação requer inicialmente a consolidação da experiência no uso dessas tecnologias. Desta maneira, este capítulo trata da prova de conceito sob o ponto de vista de integração das tecnologias envolvidas. O protótipo montado considera os elementos essenciais para encerrar uma cadeia de interação que vai desde a interface de usuário via browser até a subestação monitorada. O intuito é a redução de riscos do projeto por meio da compreensão e validação da comunicação entre agentes e da montagem dinâmica da interface com informações vindas da plataforma de agentes. Assim, o modelo de negociação entre subestações, COVs e operadores não é implementado nesta etapa. Detalhes do funcionamento de cada elemento são descritos na seqüência. As ferramentas empregadas na construção foram o JADE versão 3.4, máquina virtual Java 5.0, ambiente de desenvolvimento Java integrado Eclipse 3.2 [ECLIPSE06] e, como servidor HTTP e ambiente de execução de Servlets, o Apache TomCat 5.5 [TOMCAT06]. Para geração de documentos SVG foi utilizado o editor GLIPS Graffiti [GLIPS06]. 6.1 SIMULADOR DE SUBESTAÇÃO O simulador representa uma subestação de energia elétrica em operação, capturando todos os estados e comportamentos possíveis de uma subestação real. Os simuladores são úteis para o desenvolvimento e teste de aplicações SCADA, devido à inviabilidade de se ter uma infra-estrutura elétrica completa em ambiente de laboratório.

51 Como o circuito elétrico de uma subestação é complexo, onde muitos de seus componentes possuem sensores e atuadores acoplados para leitura de medidas e execução de comandos, o simulador montado neste trabalho representa uma subestação fictícia, cujo esquema é mostrado na Figura 6. FIGURA 6 ESQUEMA ELÉTRICO DA SUBESTAÇÃO FICTÍCIA. A energia elétrica chega na subestação e percorre a linha que está conectada diretamente ao elemento T-1, um transformador. Em seguida, passa pelo disjuntor DJ-01 e bifurca-se na barra horizontal, indo para os alimentadores 1 e 2, atravessando antes os disjuntores DJ-02 e DJ-03 que estão nas barras verticais. A partir daí, a energia elétrica vai para a rede de distribuição urbana. As medidas elétricas de interesse são intensidade de corrente e potência, para as barras verticais, e tensão e freqüência para a barra horizontal. Tais medidas são chamadas de medidas analógicas. Para os disjuntores, é necessário conhecer suas medidas de estado, aberto ou fechado.

52 No simulador, a estruturação das classes Java que representam as medidas e os equipamentos foi baseada em um modelo chamado CIM (Common Information Model) [IEC06]. Esse modelo foi desenvolvido pelo IEC (International Electrotechnical Commission) com o propósito de unificar os conceitos sobre as entidades existentes em uma subestação, seus atributos e relacionamentos, facilitando a construção de sistemas de automação e a troca de informações entre as organizações da área de energia elétrica. O modelo é implementado em um diagrama de classes na notação UML (Unified Modeling Language) [OMG06]. Detalhes sobre o CIM e seu uso no contexto da automação de subestações podem ser obtidos em [BRAGA06]. Para proporcionar o comportamento dinâmico, o simulador utiliza duas threads que, periodicamente, abrem e fecham os disjuntores e calculam as medidas analógicas. Por se tratar de um experimento, o cálculo usa números randômicos dentro de intervalos pré-estabelecidos. Cada medida é identificada de forma única dentro do simulador. O simulador também aceita comandos externos para abrir ou fechar um disjuntor ou para recuperar as atuais medidas, analógicas ou de estado. Todas as mudanças de estado nos disjuntores são armazenadas em uma fila circular para eventual recuperação do histórico das atuações sobre a subestação. Quando essa recuperação ocorre, os estados lidos são removidos da fila. Caso haja enchimento completo da fila, as medidas transbordadas vão para arquivos de log. 6.2 AGENTE SUBESTAÇÃO Para incorporar a subestação na plataforma JADE, foi desenvolvido um agente chamado AgenteSubestacao, que encapsula os detalhes de implementação do simulador. Esse agente poderia conter inteligência local para tomar decisões a respeito do monitoramento da subestação, comunicando-se com o resto da

53 plataforma somente quando necessário. Para o protótipo, no entanto, esse agente possui apenas duas responsabilidades. A primeira é receber, via mensagem ACL, solicitações de leitura de medidas analógicas, efetuar consultas ao simulador e a preparação e envio de resposta. A segunda é realizar, periodicamente, o consumo parcial da fila de mudanças de estado no simulador e remetê-las para a camada de interface com o usuário. Em ambos os casos, a entidade que interage com o AgenteSubestacao é um outro agente, chamado de AgenteCliente, explicado mais adiante. O AgenteSubestacao e o AgenteCliente são hospedados em containers diferentes, mas em uma mesma plataforma JADE. Para atender às solicitações, foi adicionado ao agente um comportamento derivado da classe jade.core.behaviours.cyclicbehaviour. Esse comportamento fica em estado de espera até a chegada de uma mensagem. Quando isso ocorre, uma lista de identificadores de medidas é extraída do conteúdo dessa mensagem e, para cada identificador, o agente associa um valor de medida obtido junto ao simulador. Após recebimento da resposta, o comportamento fica novamente em espera por novas solicitações. A segunda responsabilidade do agente AgenteSubestacao foi implementada por uma classe derivada de jade.core.behaviours.tickerbehaviour. Essa classe usa a mesma estrutura do comportamento anterior para inserir na mensagem todos os pares contendo identificador e valor de estado. 6.3 AGENTE CLIENTE O AgenteCliente funciona neste protótipo como um elemento que faz a ponte entre o AgenteSubestacao e a camada Web. Ele efetua, através de dois comportamentos cíclicos distintos, a varredura das atuais medidas analógicas no AgenteSubestacao, e a recepção das variações de estado que ocorrem nos

54 disjuntores da subestação. As informações obtidas são armazenadas em uma estrutura de dados em memória para serem utilizadas na camada Web. Essa estrutura é mantida internamente em uma classe Java instanciada através do design pattern Singleton [GAMMA+95]. O Singleton garante que apenas uma instância da classe é criada no contexto da aplicação. Assim, quando a camada Web solicitar a estrutura, será retornado o mesmo objeto utilizado pelo AgenteCliente. Evidentemente, para que haja somente um contexto para a aplicação, o container JADE que hospeda o AgenteCliente é iniciado e executado no mesmo processo da camada Web. Essa forma de implementação cria um alto acoplamento entre as duas camadas, Web e agentes, mas foi escolhida devido a sua simplicidade e a uma restrição da plataforma JADE não é permitido o acesso direto ao agente a partir de aplicações externas, eles ficam encapsulados através de uma outra classe Java, que não apresenta em sua interface as variáveis-membro pertencentes aos agentes. Outras alternativas de integração poderiam ser exploradas, como a troca de mensagens com a plataforma de agentes via JMS, o que eliminaria o acoplamento físico permitindo que cada camada seja executada em um processo distinto. Embora a varredura pudesse ser iniciada somente sob demanda da camada Web, optou-se por embutir essa ação no agente. Assim, quando tal camada precisa da informação, ela consulta a estrutura de dados e considera que lá estão as medidas mais atualizadas. O agente insere na estrutura de dados apenas o último estado de cada disjuntor. Apesar do histórico de mudanças ser descartado, o propósito dessa remessa de informações de estado é verificar o comportamento do agente na recepção de uma torrente de dados, os quais, em situações reais de operação, poderiam ser eventos, alarmes e outras mudanças de estados ocorridas na subestação. A Figura 7 mostra a ferramenta JADE Sniffer Agent capturando as

55 interações entre o AgenteSubestacao e o AgenteCliente, colocados em execução no Main-Container e container-1, respectivamente. As mensagens assinaladas como INFORM referem-se ao envio das medidas de estado, e as mensagens QUERY-REF e respectiva INFORM-REF indicam a solicitação e resposta do AgenteCliente por medidas analógicas. Essas assinalações significam a intenção da mensagem ACL, conforme descrito em [FIPA06b], sendo INFORM a intenção de um agente notificar um evento, QUERY-REF a requisição a um agente e INFORM-REF a resposta a uma requisição. FIGURA 7 INTERAÇÃO ENTRE AGENTECLIENTE E AGENTESUBESTACAO. 6.4 CAMADA WEB A camada Web deste protótipo apresenta em um browser as informações mantidas pelo AgenteCliente relativas à subestação fictícia.