UMA ARQUITETURA BASEADA EM AGENTES E INTERFACE …cristina/Dometerco.pdf · A evolução das redes...
64
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
Transcript of UMA ARQUITETURA BASEADA EM AGENTES E INTERFACE …cristina/Dometerco.pdf · A evolução das redes...
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
i
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
ii
Aos colegas da equipe de trabalho da COPEL.
iii
AGRADECIMENTOS
A minha geladeira, sempre útil nos intervalos deste trabalho.
iv
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
v
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
vi
LISTA DE SIGLAS
ACL Agent Communication Language
AID Agent Identifier
AJAX Asynchronous JavaScript And XML
AMS Agent Management System
ANEEL Agência Nacional de Energia Elétrica
API Application Program Interface
CFP Call for Proposals
CIM Common Information Model
COD Centro de Operação de Distribuição
COE Centro de Operação de Transmissão
CORBA Commom Object Request Broker
COV Centro de Operação Virtual
DF Directory Facilitator
FIPA Foundation for Intelligent Physical Agents
GIF Graphics Interchange Format
GNU GNU´s Not Unix
HMI Human Machine Interface
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
JADE Java Agent Development Framework
JEE Java Enterprise Edition
JMS Java Messaging Service
JMX Java Management Extentions
JNI Java Native Interface
vii
JPG Joint Photographic Experts Group
JSP Java Server Pages
JVM Java Virtual Machine
J2ME Java 2 Micro Edition
J2SE Java 2 Stardard Edition
LGPL GNU Lesser General Public Licence
MAS Multiagent System
MVC Model View Controller
NCU Network Computing Unit
RMI Remote Method Invocation
RTU Remote Terminal Unit
SCADA Supervisory Control and Data Aquisition
SVG Scalable Vectorial Graphics
TCP/IP Transmission Control Protocol/Internet Protocol
UML Unified Modeling Language
W3C World Wide Web Consortium
WSDL Web Service Description Language
XML Extensible Markup Language
viii
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.
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,
22
à 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.
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, auto-
organizador 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 Smalltalk2 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,1hash2 24,0 19,5 24,1 19,9 0,4hash 6,0 5,9 5,1 5,4 2,0heapsort 51,0 46,9 46,0 46,2 47,3matrix 51,0 35,2 53,7 39,2 28,1methcall 38,0 4,8 33,4 4,9 26,2nestedloop 46,0 37,6 47,7 37,8 20,0strcat 7,0 5,4 5,3 4,7 3,4random 63,6 39,3 69,6 46,5 21,0sieve 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
37
natureza do tipo de processamento específico da aplicação deve ser levada em
consideração na escolha da linguagem.
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.
56
No sistema SCADA atual, as medidas obtidas periodicamente da
subestação são apresentadas ao usuário dentro de um diagrama esquemático,
observado na Figura 8. Isso facilita a associação dos valores das medidas com o
equipamento elétrico correspondente.
FIGURA 8 - EXEMPLO DA INTERFACE DE MONITORAMENTO PROVIDA PELO SISTEMA SCADA.
Conforme discutido na seção 3.2, a linguagem SVG permite a conjugação
de texto e formas geométricas em um documento XML, de maneira que o resultado
final seja visualizado como uma imagem dentro de um browser. Assim, para montar
a interface de usuário, foi criado um documento SVG com a aparência visual da
subestação fictícia, cujas posições para a impressão das medidas foram
identificadas através de elementos da linguagem XML.
Ao ser carregado no browser, o documento SVG aciona uma função escrita
na linguagem JavaScript que, por sua vez, utiliza AJAX para requisitar ao servidor
Web os dados da subestação.
A requisição é atendida por um programa Servlet, que obtém as medidas
analógicas e de estado geradas pelo AgenteCliente e monta a resposta em um
documento XML. Uma função em JavaScript percorre as informações recebidas da
requisição e efetua a atualização no documento SVG, nos elementos previamente
identificados como posições de medidas.
57
Os resultados no browser são mostrados na Figura 9. Observa-se em (A),
na cor vermelho, as medidas analógicas, e em verde, o estado fechado dos
disjuntores. Após nova interação com o servidor Web, o resultado, em (B), mostra as
medidas com valor zero devido aos disjuntores, indicados em vermelho, estarem
abertos. O período de atualização é de cinco segundos, para manter compatibilidade
com o ciclo de atualização do AgenteCliente.
(A) (B)
FIGURA 9 - RESULTADOS DA APRESENTAÇÃO DAS INFORMAÇÕES DA SUBESTAÇÃO FICTÍCIA.
58
7 CONCLUSÕES E TRABALHOS FUTUROS
Uma investigação de arquiteturas e tecnologias disponíveis para a
construção de sistemas de automação de subestações de energia elétrica é
apresentada neste trabalho. Sistemas multiagentes baseados em Web têm sido foco
de estudo e implementação de aplicações para automação, produzindo arquiteturas
distribuídas, modulares e integráveis.
Testes de desempenho sobre tecnologias para computação distribuída são
executados em laboratório. Resultados ratificam a tendência verificada na literatura,
apontando para a utilização da tecnologia de multiagentes e, como conseqüência, a
inclusão de inteligência localizada.
Nota-se que a plataforma JADE está em fase de maturidade, oferecendo
um conjunto de ferramentas para desenvolvimento, facilidades para integração e
suporte à linguagem Java.
O uso de Web browsers na camada de apresentação exige o emprego de
técnicas para resolver a questão da atualização freqüente de informações mostradas
ao usuário, e a aplicação de recursos para aprimorar os elementos visuais em uma
página HTML. É tido como boa prática o emprego do MVC para estruturação dos
componentes dessa camada.
Um modelo específico para a automação de subestações é proposto, o
qual apresenta uma estrutura virtual dinâmica de controle e monitoração. Este
modelo ainda deve ser avaliado de forma criteriosa, considerando-se os requisitos
existentes no sistema de automação de subestações atual e os que são necessários
a sua evolução frente às tecnologias disponíveis atualmente.
Conclui-se que deve haver continuidade dos trabalhos para tornar viável o
desenvolvimento de um sistema de automação mais flexível, pois há diversas
questões em aberto que merecem estudos e testes. Mesmo assim, já é lançada
alguma luz sobre o problema da interoperabilidade entre os centros de operação.
59
7.1 TRABALHOS FUTUROS
Estudos sobre segurança no modelo proposto devem ser iniciados.
Criptografia no tráfego de mensagens, autenticação e autorização de usuários,
registro de logs para auditoria, proteção contra intrusos e não repúdio são pontos
que merecem atenção.
Com relação à tolerância à falhas, avaliar o uso de containers JADE e da
camada Web de forma redundante, observando o impacto da replicação de agentes
sobre o desempenho global do sistema. Verificar alternativas para a integração do
JADE com aplicações externas, de forma a diminuir o acoplamento entre as
camadas e garantir a entrega de mensagens entre elas.
Testes de carga devem ser planejados e executados sobre um protótipo
mais completo, visando identificar gargalos e robustez da arquitetura proposta.
Levantar requisitos junto aos usuários para especificar as regras de
negociação entre COVs e subestações, e a responsabilidade da tomada de
decisões. Mesmo havendo inteligência embutida no sistema capaz de descobrir a
situação ótima para distribuição da carga entre os COVs, pode haver interesse do
usuário em tomar a decisão final, utilizando essa informação apenas como fator de
apoio.
Evoluir o protótipo buscando aprimoramento na camada de interação com
o usuário, permitindo emissão de comandos e monitoramento simultâneo de várias
subestações.
Investigar técnicas de engenharia de software para modelagem de
sistemas multiagentes, visando capturar o dinamismo das interações entre agentes e
os seus comportamentos.
60
REFERÊNCIAS
[BARRETO06] BARRETO, C. G. Agregando Frameworks de Infra-Estrutura em uma Arquitetura Baseada em Componentes: Um Estudo de Caso no Ambiente AulaNet. Rio de Janeiro, 2006. Dissertação (Mestrado em Informática) - Departamento de Informática do Centro Técnico e Científico – Pontifícia Universidade Católica do Rio de Janeiro.
[BELLIFEMINE +05a] BELLIFEMINE, F.; CAIRE, G.; TRUCCO, T; RIMASSA, G. Jade Programmer’s guide, 2005. Disponível em <http://jade.tilab.com/doc/>. Acesso em Ago. 2006.
[BELLIFEMINE +05b] BELLIFEMINE, F.; CAIRE, G.; TRUCCO, T; RIMASSA, G.; MUNGENAST, R. Jade Administrator´s Guide, 2005. Disponível em <http://jade.tilab.com/doc/>. Acesso em Ago. 2006.
[BOYER93] BOYER, S. A. SCADA – Supervisory Control and Data Acquisition. Instrument Society of America, 1993.
[BRAGA06] BRAGA, C. de C. Estudo do JADE e do CIM no Contexto de um Sistema SCADA. Curitiba, 2006. Monografia (Especialização em Informática) Departamento Acadêmico de Informática - Universidade Tecnológica Federal do Paraná.
[BUSE+03] BUSE, D. P.; SUN, P.; WU, Q. H., FITCH, J. Agent-Based Substation Automation. Proc. IEEE Power & Energy, v. 1, n. 2, p. 50-55, Mar/Abr 2003.
[COSTA99] COSTA, M. T. C. da. Uma Arquitetura Baseada em Agentes para Suporte ao Ensino à Distância. Florianópolis, 1999. Tese (Doutorado em Engenharia de Produção) – Centro Tecnológico, Universidade Federal de Santa Catarina.
[IEC06] INTERNATIONAL ELECTROTECHNICAL COMMISSION. Common Information Model (CIM). Disponível em < http://www.iec.ch/>. Acesso em 20 Jul. 2006.
[DURFEE+89] DURFEE, E. H.; LESSER, V. Negotiating Task Decomposition and Allocation Using Partial Global Planning. In: GASSER, L; HUHNS, M. (eds). Distributed Artificial Intelligence. San Francisco, California.: Morgan Kaufmann, 1989, v. 2, p. 229–244.
[EBATA+00] EBATA, Y.; HAYASHI, H.; HASEGAWA, Y.; KOMATSU, S.; SUZUKI, K. Development of the Intranet-based SCADA (supervisory control and data acquisition system) for power system. Power Engineering Society Winter Meeting, IEEE, v. 3, p. 23-27, Jan 2000.
[ECLIPSE06] Eclipse - an open development platform. Página oficial do Eclipse. Disponível em <http://www.eclipse.org/>. Acesso em 21 Nov. 2006.
[FARACO98] FARACO, R. A. Uma arquitetura de Agentes para Negociação dentro do Domínio do Comércio Eletrônico. Florianópolis, 1998. Dissertação (Mestrado em Engenharia de Produção) – Centro Tecnológico, Universidade Federal de Santa Catarina.
61
[FERNANDES03] FERNANDES, A. M. da R.. Inteligência Artificial – Noções Gerais. Florianópolis, SC: Visual Books, 2003.
[FIPA06a] FIPA Specification Grouped by Category. Disponível em <http:// www.fipa.org/ repository/ bysubject.html>. Acesso em: 23 Nov. 2006.
[FIPA06b] FIPA Communicative Act Library Specification. Disponível em <http://www.fipa.org/specs/fipa00037/SC00037J.html>. Acesso em: 23 Nov. 2006.
[FIPA06c] FIPA Contract Net Interaction Protocol Specification. Disponível em <http://www.fipa.org/specs/fipa00029/SC00029H.html>. Acesso em 23 Nov. 2006.
[FLASH06] Flash Professional 8. Disponível em <http://www.adobe.com/ products/flash/>. Acesso em 25 Nov. 2006.
[FOWLER03] FOWLSER, M. Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.
[FRANKLIN+96] FRANKLIN, S.; FRAESSER, A. Is it an Agent, or just a Program?: a Taxonomy of Autonomous Agents. Proceedings of the Third International Workshop on Agent Theories, Architectures, and Languages. Springer-Verlag, 1996.
[GAMMA+95] GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
[GLIPS06] GLIPS Graffiti SVG Editor. Página oficial do projeto GLIPS. Disponível em <http://glipssvgeditor.sourceforge.net/>. Acesso em 25 Nov. 2006.
[HOPKINSON+03] HOPKINSON, K. M.; BIRMAN, K. P.; GIOVANINI, R.; COURY, D. V.; WANG, X.; THORP, J. S. EPOCHS: integrated commercial off-the-shelf software for agent-based electric power and communication simulation. Simulation Conference, Proceedings of the 2003 Winter, v. 2, p. 1158 – 1166, Dez. 2003.
[JADE06] Java Agent Development Framework. Página Oficial do JADE. Disponível em <http://jade.tilab.com/>, Acesso em 01 Nov. 1006.
[JENNINGS+98] JENNINGS, N.; SYCARA, K.; WOOLDRIGE, M. A Roadmap of Agent Research and Development. Autonomous Agents and Multi-Agent Sytems, v. 1, p. 7-38, 1998.
[JMETER06] Apache Jmeter. Página oficial do framework JMeter. Disponível em <http://jakarta.apache.org/jmeter/>. Acesso em 24 Nov. 2006.
[JOHNSON02] JOHNSON, R. Expert One-on-One J2EE Design and Development. Reading: Wiley Publishing Inc., 2002.
[JOHNSON04] JOHNSON, R. Expert One-on-One J2EE Development without EJB. Wiley Publishing Inc., 2004.
62
[JSF06] JavaServer Faces. Implementação de referência da Sun. Disponível em <https://java.sun.com/javaee/javaserverfaces/>. Acesso em: 11 Nov. 2002.
[JUNG+04] JUNG, J.; LIU, C. Multi-agent system technologies and an application for power system vulnerability. Power Engineering Society General Meeting (IEEE), v. 1, p. 61 - 64, 2004.
[JUNIT06] JUnit.org. Página oficial do framework JUnit. Disponível em <http://www.junit.org/index.htm>. Acesso em 24 Nov. 2006.
[LEA06] LEA, K. The Java is Faster than C++ and C++ Sucks Unbiased Benchmark. Disponível em <http://kano.net/javabench/>. Acesso em 02 Fev. 2006.
[LEEUWEN+97] LEEUWEN, E. H. VAN; NORRIE, D. Intelligent manufacturing: holons and holarchies. Manufacturing Engineer, v. 76, n. 2, p. 86–88, 1997.
[LI+02] LI; D.; SERIZAWA Y.; KIUCHI, M. Concept design for a Web-based supervisory control and data-acquisition (SCADA) system. In: TRANSMISSION AND DISTRIBUTION CONFERENCE AND EXHIBITION 2002, Asia Pacific. IEEE/PES, v. 1, p. 32 - 36, Out. 2002.
[OMG06] OBJECT MANAGEMENT GROUP. Unified Modeling Language (UML). Página oficial da UML. Disponível em <http://www.uml.org/>. Acesso em 19 Nov. 2006.
[PE06] Sun Java System Application Server Platform Edition 8.2. Página oficial do servidor de aplicações J2EE 1.4 da Sun. Disponível em <http:// www.sun.com/software/products/appsrvr/previous/pe8/index.xml>. Acesso em: 24 Nov. 2006.
[PRAYURACHATUPORN+01] PRAYURACHATUPORN, S; BENEDICENTI, L. Increasing the reliability of control systems with agen technology. ACM SIGAPP Applied Computing Review, v. 9, n. 2, Jul. 2001.
[QIU+02] QIU, B.; GOOI, H. B.; LIU, Y.; CHAN, E. K. Internet-based SCADA display system. IEEE Computer Applications in Power, p. 14-19, Jan. 2002.
[SEKI+02] SEKI, T.; KUBOTA, K.; TSUCHIYA, T.; TAMURA, S.; WATANABE, H.; TANAKA, T. Power systems information delivering system using Internet technology. In: TRANSMISSION AND DISTRIBUTION CONFERENCE AND EXHIBITION 2002, Asia Pacific. IEEE/PES, v. 1, p. 12 – 17, Out. 2002.
[SHONO+02] SHONO, T.; SEKIGUCHI, K.; TANAKA, T.; KATAYAMA, S. Remote Supervisory System for a Power system Protection and Control Unit Applying Mobile Agent Technology. In: TRANSMISSION AND DISTRIBUTION CONFERENCE AND EXHIBITION 2002, Asia Pacific. IEEE/PES, v. 1, p. 148-153, Out. 2002.
[SPRING06] Spring Framework. Página oficial do framework Spring. Disponível em <http://www.springframework.org/>. Acesso em: 11 Nov. 2006.
[STRUTS06] Struts. Página oficial do framework Struts. Disponível em <http:// struts.apache.org/>. Acesso em: 11 Nov. 2006.
63
[SUN06] The Source for Java Developers. Página oficial do Java. Disponível em <http://java.sun.com>. Acesso em: 11 Nov. 2006.
[SYCARA98] SYCARA, K. P. Multiagent Systems. AI Magazine, v. 10, n. 2, p. 79-93, 1998.
[TOMCAT06] Apache Tomcat. Página oficial do Apache Tomcat. Disponível em <http://tomcat.apache.org/>. Acesso em 21 Nov. 2006.
[VRBA03] VRBA, P. JAVA-Based Agent Platform Evaluation. In: HoloMAS 2003, p. 47–58, 2003.
[W3C06] WORLD WIDE WEB CONSORTIUM. Scalable Vector Graphics – XML Graphics for the Web. Página oficial do SVG. Disponível em <http://www.w3.org/Graphics/SVG/>. Acesso em 11 Nov. 2006.
[W3SCHOOLS06a] W3SCHOOLS. Introduction to SVG. Disponível em <http://www.w3schools.com/svg/svg_intro.asp>. Acesso em 11 Nov. 2006.
[W3SCHOOLS06b] W3SCHOOLS. AJAX Tutorial. Disponível em <http:// www.w3schools.com/ajax/default.asp>. Acesso em 12 Nov. 2006.
[YAVNAI94] YAVNAI, A. Distributed decentralized architecture for autonomous cooperative operation of multiple agent system. AUV ’94 – Proceedings of the 1994 Symposium on Autonomous Underwater Vehicle Technology. Jul. 1994, p. 61 – 67.
[ZHANG+04] ZHANG, Z. et al. Multiagent system solutions for distributed computing, communications and data integration needs in the power industry. Power Engineering Society General Meeting (IEEE), v.1, p. 45- 49, 2004.
