Monografia JAVA-Ciro-Final - DAINF

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA
CIRO DE CARVALHO BRAGA
ESTUDO DO JADE E DO CIM NO CONTEXTO DE UM SISTEMA
SCADA
MONOGRAFIA DE ESPECIALIZAÇÃO
ORIENTADORA: PROF.ª MSC. ANA CRISTINA B. KOCHEM VENDRAMIN
CURITIBA
DEZEMBRO 2006
CIRO DE CARVALHO BRAGA
ESTUDO DO JADE E DO CIM NO CONTEXTO DE UM SISTEMA
SCADA
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.
Orientadora: Prof. ª Msc. Ana Cristina
B. Kochem Vendramin.
CURITIBA
DEZEMBRO 2006
i
Aos colegas da automação e do projeto de P&D.
ii
AGRADECIMENTOS
A todos que direta ou indiretamente auxiliaram na realização do trabalho.
iii
SUMÁRIO
Lista de Figuras .............................................................................................................v
Lista de Siglas................................................................................................................vi
Resumo ....................................................................................................................... viii
1 Introdução ...............................................................................................................1
1.1 Desafio ....................................................................................................................1
1.2 Motivação ...............................................................................................................1
1.3 Objetivo ..................................................................................................................2
1.4 Estrutura do trabalho...............................................................................................2
2 SASE – Sistema de automação de subestações.....................................................4
2.1 Histórico..................................................................................................................4
2.2 Inserção no contexto nacional ................................................................................5
2.3 Os Centros de Operação de Subestações da COPEL .............................................7
2.4 Características .........................................................................................................8
3 Arquitetura distribuída baseada em agentes .....................................................11
3.1 Rede Ethernet........................................................................................................12
3.2 Middleware ...........................................................................................................13
3.3 Tecnologia de Agentes..........................................................................................14
3.4 Desenvolvimento de agentes em Java ..................................................................18
3.5 FIPA......................................................................................................................20
3.6 JADE.....................................................................................................................22
3.7 Ontologia ..............................................................................................................28
4 Padroes IEC / CIM ...............................................................................................35
4.1 Tendência para Barramento de Integração ...........................................................36
4.2 O Padrao IEC 61970-301 (CIM) ..........................................................................38
4.3 CIM versus Ontologia...........................................................................................44
5 Experiência ............................................................................................................46
5.1 Arquitetura hipotética ...........................................................................................47
5.2 Modelagem da subestação ....................................................................................53
5.3 Simulador de subestação.......................................................................................55
5.4 Implementação de objetos CIM............................................................................57
5.5 Testes com Ontologia ...........................................................................................63
5.6 Agentes implementados........................................................................................65
5.7 Interação entre agentes e apresentação .................................................................67
6 Conclusões .............................................................................................................70
6.1 Trabalhos futuros ..................................................................................................71
Referências ...................................................................................................................73
iv
LISTA DE FIGURAS
Figura 1 - Esquema hierárquico - inserção da COPEL no sistema elétrico nacional................. 6
Figura 2 - Mapa do sistema elétrico do Paraná [ENGTRA05]. ................................................. 7
Figura 3 - Ciclo de vida de um agente JADE ........................................................................... 23
Figura 4 - Modelo UML da hierarquia de classes dos comportamentos JADE. ...................... 25
Figura 5 - Protocolo FIPA-ContractNet [Malucelli06]. ........................................................... 26
Figura 6 - Exemplo de uma plataforma distribuída JADE com tolerância a faltas. ................. 27
Figura 7 - O Modelo de Referência de Conteúdo do JADE..................................................... 32
Figura 8 - Meta-modelo do CIM. ............................................................................................. 39
Figura 9 - Visão geral dos pacotes CIM. .................................................................................. 40
Figura 10 - CIM: Hierarquia de classes de equipamentos........................................................ 42
Figura 11 - Estudo da estrutura física na COPEL. ................................................................... 50
Figura 12 - Estudo da estrutura lógica na COPEL. .................................................................. 52
Figura 13 - Unifilar proposto para o protótipo. ........................................................................ 54
Figura 14 - Modelo CIM reduzido para o protótipo................................................................. 58
Figura 15 – Identificação dos objetos CIM sobre o unifilar..................................................... 60
Figura 16 - Protégé: mini-ontologia CIM................................................................................. 64
Figura 17 - Gerenciamento gráfico dos agentes do protótipo no JADE................................... 66
Figura 18 - Sniffer: captura de mensagem ACL/SL0. .............................................................. 67
Figura 19 - Tela de operação do protótipo. .............................................................................. 69
v
LISTA DE SIGLAS
ACL
Agent Communication Language
API
Application Program Interface
AJAX
Asyncronous Java And XML
ANEEL
Agência Nacional de Energia Elétrica
CIM
Common Information Model
CO
Centro de Operação
COE
Centro de Operação de Estações
COD
Centro de Operação da Distribuição
COV
Centro de Operação Virtual
COPEL
Companhia Paranaense de Energia
EAI
Enterprise Application Integration
EPRI
Electric Power Research Institute
FIPA
Foundation for Intelligent Physical Agents
IDL
Interface Definition Language
IEC
International Electrotechnical Commission
IED
Intelligent Electronic Device
IHM
Interface Homem-Máquina
IIOP
Internet Inter-ORB Protocol
JADE
Java Agent Development Framework
JNI
Java Native Interface
JSP
Java Server Page
JVM
Java Vitual Machine
MOF
Managed Object Format
OCL
Object Constraint Language
ORB
Object Request Broker
OWL
Web Ontology Language
vi
RDF
Resource Description Framework
RMI
Remote Method Invocation
SASE
Sistema de Automação de Subestações
SCADA
Supervisory Control and Data Acquisition
SE
Subestação
SVG
Scalable Vector Graphics
UTR
Unidade Terminal Remota
UML
Unified Modeling Language
VLAN
Virtual Local Area Network
VPN
Virtual Private Network
XML
Extensible Markup Language
vii
RESUMO
A constante evolução dos sistemas computacionais em plataforma baixa propicia um
debate enriquecedor no campo da engenharia elétrica relacionada ao controle de
processos industriais. A COPEL, concessionária de energia elétrica do Paraná,
desenvolve uma solução própria de automação de subestações de transmissão e
distribuição que tem seu projeto inicial datado na década de 1990. Questões
relacionadas à adequação de normas administrativas, à hierarquia do setor elétrico,
à integração de aplicativos, à aderência a padrões abertos e à rapidez na tomada de
decisão operacional impelem a concessionária a procurar novas abordagens para se
manter no patamar de qualidade conquistado ao longo dos anos. Uma das
mudanças desejadas é o uso estratégico de sua estrutura de rede de comunicação.
A COPEL possui um backbone de alta velocidade que vem sendo utilizado até
mesmo em importantes programas governamentais de inclusão digital, promovendo
o desenvolvimento do estado. O uso de uma solução em rede dedicada exige o
conhecimento de sistemas distribuídos, programação, segurança, banco de dados,
confiabilidade e disponibilidade. Dentro dessa perspectiva, o presente trabalho
descreve como as tecnologias Java podem auxiliar no estudo de um sistema
distribuído com arquitetura aberta para a área de supervisão e controle operacional
da COPEL. Para entendimento do contexto, é apresentado o atual sistema de
automação da empresa. Depois, aborda-se a tecnologia de agentes em Java para
suprir as funções de middleware e estuda-se um padrão para a modelagem de
dados no setor elétrico. Por fim, são apresentados resultados práticos de um
protótipo com a aplicação dessas tecnologias, servindo como laboratório para a
COPEL consolidar o caminho escolhido para o seu sistema de automação.
Palavras-chave: Java, sistemas distribuídos, Common Information Model, plataforma
de agentes JADE, automação de subestações de energia elétrica.
viii
1
1
INTRODUÇÃO
A evolução dos centros de controle de energia elétrica é influenciada pelo
cenário do setor elétrico e pelo mercado de informática. A cada nova geração de
centros, aumenta-se o grau de incertezas e de abertura do ambiente. A
transformação atual, cuja consolidação deve levar ainda uma década, está
fortemente influenciada pelas mudanças na regulamentação do mercado de energia
e pela maturidade da tecnologia de processamento distribuído.
1.1 DESAFIO
O desafio deste trabalho é mostrar que as tecnologias Java podem ser
utilizadas como parte de um controle de processo industrial, especificamente, na
automação de subestações de energia elétrica.
1.2 MOTIVAÇÃO
A principal motivação desse trabalho é a modernização do sistema SCADA
(Supervisory Control and Data Acquisition) atualmente implantado na COPEL
(Companhia Paranaense de Energia). Apesar de atender com eficácia as
necessidades operacionais da concessionária, a atual solução carece de uma
sintonia com as principais tendências no setor, explorando tecnologias em ascensão.
Como a área de desenvolvimento de sistemas da concessionária pretende
pôr em discussão toda a solução, com foco no plano de negócios da área de
engenharia de automação da transmissão e da distribuição, abrem-se possibilidades
para a utilização de soluções baseadas em Java. Este estudo aqui apresentado
serve para aumentar os conhecimentos da equipe de desenvolvimento e para
referência de implementação do novo sistema.
Este trabalho está relacionado com um projeto de Pesquisa e
2
Desenvolvimento da ANEEL (Agência Nacional de Energia Elétrica) em fase de
execução pela empresa. Outro estudo acadêmico, também relacionado ao projeto,
complementa o entendimento deste trabalho [Dometerco06].
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. O
aumento do capital intelectual dos envolvidos reflete no aumento da qualidade dos
produtos e serviços da área de TI (Tecnologia da Informação) da empresa.
Algumas características pretendidas na modernização do atual sistema são
a interoperação entre os centros de operação, facilidade e conforto na operação,
aumento na segurança do sistema, integração entre os sistemas, desenvolvimento
ágil (expansão / manutenção).
1.3 OBJETIVO
O objetivo deste trabalho é apresentar um estudo dos conceitos de um
middleware para prover suporte a sistemas distribuídos baseados em uma
tecnologia de agentes implementada em Java. Também se pretende expor um
modelo UML de classes para representação de dados que compõem o universo de
uma concessionária de energia elétrica e um protótipo simplificado para avaliação de
algumas características levantadas (prova de conceitos).
1.4 ESTRUTURA DO TRABALHO
O trabalho está organizado da seguinte maneira. No capítulo 2, são
apresentados alguns aspectos em torno do atual sistema de automação da
concessionária de energia elétrica do estado do Paraná. No capítulo seguinte, é
estudada a tecnologia de agentes em Java para suprir as funções de middleware em
sistemas distribuídos. Depois, mostra-se uma pesquisa sobre a padronização de um
3
modelo de informações a ser utilizado em empresas de energia elétrica. A parte
experimental é descrita no capítulo 5. Finalmente, no capítulo 6 são enunciadas as
conclusões e propostas para trabalhos futuros.
4
2
SASE – SISTEMA DE AUTOMAÇÃO DE SUBESTAÇÕES
Este capítulo apresenta alguns aspectos em torno do atual sistema de
automação da concessionária de energia elétrica do estado do Paraná. O
entendimento da estrutura da área operacional e da interação com agentes externos
estabelece a importância estratégica de um sistema computacional para supervisão
e controle das subestações de energia.
2.1 HISTÓRICO
Na década de 80 a COPEL [COPEL06] usava um sistema proprietário de
hardware e software desenvolvido pela empresa Harris, hoje GE-Harris, para
supervisionar a rede de transmissão de energia elétrica paranaense. Porém, nessa
época, a companhia tomou a decisão de manter o sistema por si mesma, assumindo
a manutenção e o desenvolvimento de hardware e software, com foco na
independência e otimização do sistema para atender com mais qualidade e eficácia
o crescimento da demanda por energia elétrica.
O primeiro protótipo de um sistema de automação com solução própria foi
feito em linguagem Assembly no ano de 1986. Quatro anos mais tarde era liberada
uma versão em linguagem C feita sobre sistema operacional DOS. Em 1992 iniciouse um programa de automação em larga escala de suas subestações. Com uma
equipe multidisciplinar reunida e alocada especialmente ao programa, finalizou-se
em 1994 a primeira versão do SASE (Sistema de Automação de Subestações),
escrito para o sistema operacional QNX (um sistema multitarefa e tempo-real) em
linguagem C/C++. Neste ano o SASE começou a ser implantado no sistema elétrico
paranaense. De 1994 para cá, o sistema vem sendo constantemente expandido e
melhorado e é utilizado em 98% das 131 subestações de transmissão e em 86% das
380 subestações de distribuição (outubro 2006), com meta de atingir a totalidade até
5
o final de 2007. De 2003 até começo de 2006, foi desenvolvido um projeto para
portar o código do SASE para LINUX, sem perder a compatibilidade com o QNX. A
empresa está substituindo gradativamente as versões em campo para o novo
sistema.
O SASE possui hoje perto de 50 processos escritos em quase 270.000
linhas de código e é mantido por uma equipe de quase 20 profissionais com
formação em Engenharia Elétrica ou em Engenharia de Software, sendo a maioria
com pós-graduação em diferentes áreas ligadas direta ou indiretamente à tecnologia
de informação.
2.2 INSERÇÃO NO CONTEXTO NACIONAL
O órgão que regulamenta o setor elétrico nacional desde 1997, definindo
os níveis mínimos aceitáveis de qualidade de energia que as concessionárias devem
manter é a ANEEL [ANEEL06], criada pela Lei n.º 9.427 de 26 de Dezembro de
1996 e regulamentação no decreto n.º 2.335 de 6 de outubro de 1997. A ANEEL não
tem atribuição de operar o sistema.
O órgão responsável pela operação é o ONS (Operador Nacional do
Sistema Elétrico) [ONS06]. Ele é “uma entidade de direito privado, sem fins
lucrativos, criada em 26 de agosto de 1998, responsável pela coordenação e
controle da operação das instalações de geração e transmissão de energia elétrica
no Sistema Interligado Nacional (SIN), sob a fiscalização e regulação da ANEEL”
[ONS06].
A COPEL, através do COS (Centro de Operação do Sistema), atua em
conjunto com centros de operação de outras empresas e com o ONS, seguindo uma
estrutura hierárquica definida, dentro do SIN (Sistema Interligado Nacional).
Além de supervisionar as instalações da COPEL, o COS também recebe
dados em tempo real das empresas interligadas. Esses dados são de vital
6
importância para a segurança da operação do SIN, pois a COPEL está
geograficamente localizada em um ponto estratégico de transmissão de energia
elétrica, de interligação entre as regiões Sul e Sudeste .
A participação do COS na operação conjunta do SIN é regida pelos
procedimentos de rede elaborados pelo ONS e homologados pela ANEEL,
atendendo à determinação da Lei nº 9.648, de 27 de maio de 1998, regulamentada
pelo Decreto nº 5081, de 14 de maio de 2004, e pelo Contrato CPST nº 009/1999,
firmado entre a COPEL e o ONS em 9 de fevereiro de 2000, em Brasília, alterado
pelo Memorando de Entendimentos de 06.04.2006.
A COPEL deve permitir que o ONS atue sobre a rede elétrica mantida pela
empresa, tendo acesso a determinadas informações, relativas a medidas de tensão,
estados de chaves, entre outras, dessa rede. Para tanto, a companhia deve enviar
pontos monitorados da rede e deve acatar em determinados níveis à soberania do
ONS, no tocante a manobras no próprio sistema.
A Figura 1 ilustra como a COPEL aparece para o Operador Nacional do
Sistema e como está organizada a estrutura interna, hierarquicamente.
Operador Nacional do
Sistema Elétrico
- ONS / CNOS -------------------------------Governo Brasileiro
(Brasília)
Centro de Controle
- ONS / COSR-S -------------------------------Região sul
PR / SC / RS
(Florianópolis)
Centro de Operação do
Sistema COPEL
- COS -------------------------------COPEL
(Curitiba)
9 COEs
-------------------------------Centro de Operação de
Estações da Engenharia
de Transmissão
Centros de Controle
-------------------------------Demais regiões
Centros de Operação da
Geração COPEL
-------------------------------COPEL
(Curitiba)
5 CODs
-------------------------------Centro de Operação da
Engenharia de
Distribuição
Centros de Operação
-------------------------------Outras concessionárias
(Sul)
Automação da Distribuição:
-subdivididas entre os CODs em 5 regiões,
-automatizadas, mas necessitando de presença humana.
Subestações da Transmissão (128):
-subdivididas entre os COEs por região,
-total de 6 regiões,
-totalmente automatizadas, sem presença humana.
Figura 1 - Esquema hierárquico - inserção da COPEL no sistema elétrico nacional.
7
2.3 OS CENTROS DE OPERAÇÃO DE SUBESTAÇÕES DA COPEL
Segundo o modelo da ANEEL para o sistema elétrico, a COPEL divide o
controle de acordo com a separação elétrica existente entre suas subsidiárias de
transmissão e distribuição. Os COEs (Centros de Operação de Estações) controlam
as subestações de transmissão. Os CODs (Centros de Operação da Distribuição)
controlam as subestações de distribuição.
Os pontos relevantes para o COS são obtidos pela comunicação com os
COEs. Os CODs são independentes do COS, mas possuem interligação com alguns
COEs para receber informações de pontos em subestações mistas (contém
barramentos de alta e de média tensão). Essas duas áreas da companhia se
diferenciam pelo nível de tensão que controlam. Segundo a ANEEL, a transmissão
de energia elétrica engloba a rede de 230 kV a 750 kV e a distribuição engloba
tensões abaixo de 230 kV.
A Figura 2 mostra as divisões elétrico-geográficas do estado do Paraná.
Em cada região há pelo menos um COE ou COD.
Região de
Maringá
Região de
Cascavel
Região de
Pato Branco
Região de
Londrina
Região de
Ponta Grossa
Região de
Curitiba
Figura 2 - Mapa do sistema elétrico do Paraná [ENGTRA05].
8
Existem
cinco
CODs
espalhados
pelo
estado,
controlando
380
subestações, das quais, 326 são totalmente automatizadas. Na transmissão, são
nove COEs mantendo 131 SEs (Subestações) de tensão igual ou superior a 69 kV,
totalmente automatizadas, sendo que nas consideradas subestações-chave a
ANEEL determina que haja a presença de operadores.
2.4 CARACTERÍSTICAS
Os protocolos “chão-de-fabrica” mais antigos são baseados em meio serial
e são amplamente utilizados ainda hoje pelas concessionárias. Nesse contexto, é
comum a existência de diversos centros de operação regionais, distribuídos
geograficamente, sem, contudo, haver uma integração forte entre eles.
Os sistemas de controle de processos industriais podem ser representados
por dois níveis estruturais:
•
Acionamento de comandos, aquisição, adaptação e isolamento de
sinais elétricos: representa a parte que entra em contato com os
equipamentos do universo sob controle;
•
Supervisão e controle: representa a interação com os usuários e a
tomada de decisões.
Esse tipo de sistema é conhecido na engenharia elétrica pela sigla SCADA.
Uma topologia típica de um SCADA aplicado em um controle de
transmissão e distribuição de energia elétrica possui UTRs (Unidade Terminal
Remota) instaladas em subestações responsáveis pela interação direta com os
sensores e atuadores vinculados aos equipamentos elétricos. Estes efetuam captura
de informações da planta elétrica e enviam-nas para as estações centrais,
localizadas em centros de operação regionais, por meio de canais seriais, formando
uma estrutura ponto-a-ponto em estrela do tipo mestre-escravo. As estações
centrais acumulam os dados recebidos das UTRs e repassam para os
9
microcomputadores IHMs (Interface Homem-Máquina) Os comandos emitidos pelos
operadores, bem como aqueles gerados automaticamente pelas estações centrais,
são repassados para as UTRs para a atuação real na planta.
Um sistema SCADA possui restrições quanto ao tempo de resposta,
segurança, garantia de entrega de mensagens e processamento em tempo real,
requisitos nem sempre alcançados pelas redes de computadores de uso geral,
evidenciando a necessidade de configurações especiais e linhas de comunicação
dedicadas.
O SASE é uma implementação de um SCADA, presente em todos os
centros de operação da transmissão e da distribuição e também nas subestações
automatizadas. O número de computadores com o sistema já passa de 600.
Quando desejado, é possível agregar certo nível de "inteligência" ao SASE
nas subestações, o que de modo geral acontece, através da execução de processos
chamados de Funções Elétricas, permitindo que algumas ações sejam tomadas sem
necessidade de intervenção humana, auxiliando os operadores dos centros de
operação (COEs/CODs).
O SASE suporta os sistemas operacionais QNX versão 4.25 [QNX] e Linux.
As versões atuais ainda mantêm código multiplataforma. Porém, a falta de suporte
da versão 4 do QNX aliada à obsolescência de hardware, a incompatibilidade de
migração para novas versões do QNX e as mudanças necessárias para a
incorporação de novas tecnologias impõem à empresa a decisão de abandonar seu
uso. A COPEL utiliza uma mini-distribuição Linux gerada internamente e que tem por
base o kernel 2.4 e a distribuição Slackware 9.0/9.1.
Internamente, o sistema é composto de blocos funcionais. São eles:
•
Configuração;
•
Banco de dados tempo-real;
•
Protocolos de comunicação;
•
Interface Homem-Máquina;
10
•
Tratamento de alarmes;
•
Relógio;
•
Relatórios;
•
Funções elétricas automáticas;
•
Simulação.
A arquitetura da rede é do tipo par-de-micros. Nesta configuração, há
pouca especialização de tarefas entre os computadores. Basicamente, os nós
conectados na rede se diferenciam entre console de operação, núcleo do sistema e
geração de relatórios. As informações passadas entre níveis hierárquicos diferentes
são interceptadas pelo computador que compõe o núcleo do sistema, sendo
replicadas para todos os demais computadores.
11
3
ARQUITETURA DISTRIBUÍDA BASEADA EM AGENTES
Este capítulo apresenta a tecnologia de agentes em Java para suprir as
funções de middleware em sistemas distribuídos. O entendimento dos benefícios
que uma arquitetura distribuída pode trazer e da maturidade dos padrões e
ferramentas fortalece a decisão de seguir nesse caminho evolutivo para os sistemas
de computação na COPEL.
Durante as pesquisa acadêmicas, foram encontrados artigos abordando
arquiteturas distribuídas para várias áreas de aplicação. Dentro da área de controle
de sistemas de potência, percebe-se, a partir do ano 2000, um aumento na
utilização da tecnologia de agentes.
A
evolução
padronização
das
possibilitam
tecnologias
o
computacionais
estabelecimento
de
novas
e
tendências
diretrizes
para
para
o
desenvolvimento de sistemas para centros de controle. A COPEL, com sua
experiência
no
desenvolvimento,
implementação
e
operação
de
sistemas
proprietários, junto com suas limitações, observa a necessidade de empregar o
conceito de Sistemas Abertos.
O termo “sistema aberto” não tem apenas o significado de especificação
pública, mas também de definição de uma arquitetura que contempla as seguintes
características [Pereira95]:
•
Portabilidade: habilidade de implementar a mesma funcionalidade em
diferentes plataformas de hardware;
•
Expansibilidade: capacidade de expansão tanto em hardware como
em software;
•
Modularidade: diferentes funções são implementadas por módulos de
software com interfaces bem definidas, permitindo adição e remoção
sem interferir em outros módulos;
12
•
Interconectividade: habilidade de conectar diferentes plataformas de
hardware através de uma rede padrão.
3.1 REDE ETHERNET
A comunicação entre os níveis hierárquicos do sistema de automação
ocorre principalmente através de canais seriais com protocolo do tipo mestreescravo. Apesar desse modelo fornecer desempenho e confiabilidade satisfatórios,
há uma lista de desvantagens, particularmente em termos de flexibilidade e
integração com o mundo externo [Buse03].
Os dispositivos eletrônicos inteligentes (IEDs) que a empresa vem
adquirindo para uso nas subestações, oferecem, além da interface RS-232, outros
tipos de comunicação. Entre eles, o mais encontrado é a possibilidade de uma
conexão por rede Ethernet.
Por outro lado, a COPEL possui uma infra-estrutura de telecomunicações
diferenciada, sendo a primeira empresa do setor de energia elétrica a obter a licença
da ANATEL (Agência Nacional de Telecomunicações) para prestação de serviços
especializados. Algumas características dessa estrutura própria são:
•
Backbone com topologia em anel redundante através de cabos páraraios OPGW (Optical Ground Wire) em suas linhas de transmissão de
energia elétrica;
•
Presente em 146 cidades, com mais de 4.475 km de cabos ópticos
instalados no estado;
•
Alta capacidade e velocidade do sistema, com transporte em sistema
SDH (Synchronous Digital Hierarchy), disponíveis para conexões
urbanas e interurbanas, nas velocidades de 64 Kbps a 155 Mbps;
13
•
Redes de acesso metropolitano Gigabit Ethernet, com roteamento IP,
seguras e de uso privado. O serviço está disponível nas modalidades
fixa ou sob demanda.
O uso da rede nas subestações vem sendo forçado tanto pelos
equipamentos nela presentes quanto pela alta qualidade de sua infra-estrutura. Esta
mudança torna possível a interligação de diversos níveis hierárquicos do sistema de
automação, bem como o acesso aos dados de outros sistemas.
3.2 MIDDLEWARE
É a camada de software que provê o suporte para que os componentes de
um sistema distribuído possam se comunicar. Essa camada se situa entre o sistema
operacional e a aplicação. É ela quem trata de forma transparente muitos detalhes
de baixo nível geralmente necessários para a transferência de dados entre
aplicações que utilizam a rede.
O uso de uma camada de middleware em sistemas distribuídos diminui
substancialmente a complexidade da programação. Ela pode ser usada tanto em
sistemas baseados em um único computador quanto nos distribuídos por rede.
Um middleware deve ter certas propriedades [Heck03]:
•
Automatizar tarefas comuns de programação da rede;
•
Fornecer uma interface padrão que facilite a integração entre as
aplicações;
•
Prover interoperabilidade em ambientes heterogêneos.
A interoperabilidade permite que aplicações escritas em linguagens
diferentes, para diferentes sistemas operacionais ou para diferentes plataformas de
hardware possam trabalhar juntas.
Algumas soluções de middleware têm características plug-and-play , o que
permite que partes do sistema possam se reconfigurar dinamicamente. Por exemplo,
14
uma atualização ou uma troca de um algoritmo com o resto do sistema no ar e em
tempo real.
Encontra-se uma grande possibilidade para o desenvolvimento de um
middleware nas tecnologias baseadas em Java. Esta é uma linguagem orientada a
objetos independente de plataforma, com arquitetura em camadas e APIs de código
aberto que permitem seu uso em aplicações distribuídas, tais como EJB (Enterprise
Java Beans), RMI (Remote Method Invocation) e Java ORB (Object Request
Broker).
A interação de componentes Java com componentes não-Java pode ser
feita com o uso da tecnologia JNI (Java Native Interface). Ela fornece um padrão
para escrever código Java e encapsular código não-Java. Este código combinado
pode, então, ser tratado como um único objeto.
3.3 TECNOLOGIA DE AGENTES
A tecnologia de agentes é um dos mais interessantes desenvolvimentos no
campo da inteligência artificial distribuída, com ampla faixa de aplicação. 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 [Jennings98]. É uma entidade de software, suportado por uma plataforma
de implementação ou ambiente de execução ou ainda framework de agentes, que
pode se movimentar pelo sistema de forma independente [Buse03]. Um agente
trabalha com um sistema de mensagens que produz chamadas locais ou remotas,
utiliza serviço de diretórios, aceita de forma fácil e rápida novas funcionalidades,
promovendo modularidade ao sistema.
Suas principais características são [Azevedo99]:
•
Autonomia: agentes atuam sem necessidade de intervenção externa e
têm algum tipo de controle sobre suas ações e seu estado interno;
15
•
Sociabilidade: agentes interagem com outros agentes através de uma
linguagem de comunicação apropriada;
•
Reatividade: agentes são capazes de perceber mudanças nos
ambientes em que estão inseridos e respondem a essas mudanças
quando necessário;
•
Pró-atividade: agentes possuem suas próprias metas. Suas ações não
são apenas reações a mudanças no ambiente, mas visam também
alcançar as metas.
Os agentes podem operar autonomamente, sendo que as tarefas são
realizadas pela interação entre eles, de modo cooperativo. Um sistema baseado em
tecnologia de agentes fornece uma grande autonomia a cada uma das partes
constituintes, em comparação ao tradicional sistema SCADA.
Diversas abordagens de construção de sistemas multiagentes são
encontradas. Esgotar esse assunto não é o escopo deste trabalho.
Uma divisão possível para os agentes pode ser [Buse03]
•
Agente simples: usado para desempenhar tarefas simples que não
requerem inteligência. É o preferido quando se precisa de mobilidade,
devido ao seu tamanho reduzido;
•
Agente BDI (Belief-Desire-Intention): baseia-se no conceito dos três
estados mentais (Crença-Desejo-Intenção), sendo capaz de responder
a eventos externos e executar ações para atingir uma meta. Esta
flexibilidade torna-o adequado para a execução de diversas tarefas,
como controle em tempo-real, monitoração on-line e gerenciamento de
alarmes e eventos.
As crenças representam o possível conhecimento do agente. Um agente
pode ter crenças sobre si próprio, sobre o mundo e sobre outros agentes. Os
desejos são o conjunto de metas a serem realizadas num período de tempo. Os
desejos motivam o agente a agir de forma a realizar as metas. Os desejos podem
16
ser conflitantes. Os objetivos representam um subconjunto dos desejos. Em
contraste com os desejos, os objetivos não podem ser conflitantes. As intenções
representam um subconjunto dos objetivos. Se um agente decide atingir
determinado objetivo esse objetivo passa a ser uma intenção [Gomes05].
De forma semelhante, [Silva04] classifica os agentes em inteligentes ou
móveis. Os primeiros são entidades tipicamente estáticas e que utilizam diversos
algoritmos para a realização de tarefas específicas. Os últimos, por outro lado, são
programas capazes de migrar através de uma rede heterogênea de computadores,
procurando e interagindo com os serviços oferecidos por seus hospedeiros, para
realizarem diversas tarefas em nome de seu usuário.
É possível planejar uma arquitetura para automação de subestações
totalmente baseada em agentes [Buse03], executando tarefas de controle,
armazenamento e persistência de dados, usuários, documentação, análise de dados
e acesso aos IEDs.
A Tabela 1 apresenta um conjunto de agentes que podem existir num
sistema de automação de subestações. Essas tarefas podem necessitar restrições
de tempo, recursos de rede e processamento. Podem ser executadas isoladamente,
integradas em um pacote de software (por exemplo, em um módulo de IHM) ou
alimentar uma interface Web através de servlets, applets ou server pages.
Tarefa
Habilidade
Usuário
Tipo de Agente
Comando, pesquisa, suporte
a decisão
Visualização de
informações, Disparar
pesquisa
Sensores
Banco de dados
Transferência de dados,
aquisição de dados,
pesquisa
Adicionar informações
ao banco, responder
pesquisas
Dispositivo
Controle
Recuperação de
informações
Recuperação
Mover, determinar
relevância de
informações
Localização de
informações
Controle remoto
Controle
Mover
Localização de
dispositivos
Interface gráfica ou
outra interface do
usuário
Conhecimento
Modelo do usuário
Metadados do banco
Sinais recebidos do
equipamento
Modelo do sistema sob
controle
Tabela 1 - Tipos de agentes em um sistema de automação de subestações [Buse03]
17
Alguns agentes têm um papel de intermediar consultas e pedidos feitos
entre outros agentes; São os agentes corretores: Query Broker Agent para suportar
uma submissão de pesquisa e o Request Broker Agent para suportar um pedido de
serviço. Assim, pode-se modelar uma seqüência de mensagens entre esses agentes
para a realização de tarefas como atualização dos valores de uma subestação na
tela do usuário ou o envio de comandos para um equipamento. Uma alternativa para
a seqüência de intervenções feita por agentes corretores é a utilização de agentes
móveis, mais eficientes no caso da existência de uma rede lenta entre o usuário e a
subestação [Buse03].
No caso de um sistema totalmente baseado em agentes, para cada
equipamento que envia ou recebe dados deve haver um agente controlador. Este
agente pode atualizar os dados no agente do banco de dados por meio de uma
comunicação publish-subscribe (publicacao-assinatura) [Buse03].
Os agentes podem ser divididos ainda em módulos de acordo com a sua
localização. Podem existir módulos globais, contendo funcionalidades referentes à
interface do usuário e banco de dados, e módulos locais, contendo funcionalidades
específicas a cada subestação.
A utilização de agentes requer [Prayurachatuporn01]:
•
Um ambiente runtime para que os agentes possam ser executados;
•
Uma interface padrão para interações;
•
Serviços para a criação, migração e encerramento dos agentes.
A plataforma de agentes, que é o ambiente de execução (runtime), garante
o transporte das mensagens entre os agentes, os registros de entrada e saída dos
agentes na comunidade (páginas brancas) e também registro e busca por serviços
fornecidos pelos próprios agentes (páginas amarelas) [Vrba03].
O estudo da forma como os agentes devem se especializar para a
construção de um sistema de proteção e controle levou [Shono02] a dividir os
agentes de forma que um tipo serve para configurar os equipamentos, outro para
18
coletar dados para análise de falhas no sistema elétrico e um terceiro tipo serve para
patrulhar o ambiente, coletando informações sobre as condições de operação dos
equipamentos. Assim, a preocupação com a mobilidade irá depender da
complexidade envolvida em cada uma dessas funções. Podem existir agentes
responsáveis por planejar suas próprias rotas de viagem entre os dispositivos, como
também agentes fixados permanentemente nos equipamentos do sistema.
3.4 DESENVOLVIMENTO DE AGENTES EM JAVA
A linguagem Java recebe uma acentuada preferência em termos de
programação de agentes móveis, embora existam outras linguagens que podem ser
consideradas. Uma análise das características dessa linguagem pode ajudar no
entendimento dessa tendência.
O primeiro atrativo é que a linguagem Java permite portabilidade entre
plataformas diferentes. O advento do conceito de bytecode, que é um código
intermediário interpretado, e seu respectivo ambiente de execução JVM (Java Virtual
Machine) fornece o suporte adequado para que qualquer plataforma de hardware
com poder de processamento adequado e com qualquer sistema operacional possa
executar aplicativos em Java. Um sistema baseado em agentes pode aproveitar
essa característica para ampliar seu domínio a todos os computadores da rede.
Java oferece suporte à programação em rede, através do uso de sockets e
RMI (Remote Method Invocation) que é um middleware totalmente concebido para o
Java. A plataforma de agentes pode se beneficiar desse suporte para implementar
seus serviços de comunicação e transporte de agentes.
O que garante uma autonomia operacional de cada agente no sistema é a
sua capacidade de manter um fluxo de controle de execução independente dos
demais agentes. Como o Java fornece suporte à programação multi-threading, essa
característica é facilmente atendida.
19
Os mecanismos de tratamento de exceções do Java, associado com a
execução dentro de um ambiente controlado, a JVM, facilitam a recuperação de
desastres. Uma falha na execução de um agente ou na plataforma de agentes pode
ser rapidamente neutralizada, sem comprometer o computador em questão.
Para que um agente possua a característica de reatividade, conforme
explicado na seção 3.3, permitindo sua resposta a eventos externos, devem estar
presentes mecanismos de tratamento de eventos no ambiente. Java oferece um
modelo de tratamento de eventos que facilita a implementação dessa habilidade.
Um middleware de agentes deve prover um mecanismo para localizar os
serviços por ele suportados, como nomes de objetos remotos e diretórios. A
tecnologia JNDI (Java Naming and Directory) oferece essas funcionalidades na
forma de uma API. Assim, as aplicações distribuídas podem compartilhar
informações sobre usuários, máquinas, redes e serviços [Wong99]. A tecnologia JINI
(Java Intelligent Network Infrastructure) define um conjunto de convenções capaz de
permitir que serviços e clientes formem um sistema distribuído extremamente
dinâmico [Waldo01], permitindo que as aplicações possam descobrir serviços em
uma rede.
O mecanismo de serialização de objetos do Java permite que estruturas de
dados possam ser facilmente transformadas em um fluxo seqüencial de bits. Esta
característica facilita a implementação dos serviços de transporte e de persistência
de um sistema de agentes, pois esse fluxo pode ser transportado para outro
computador ou armazenado em algum tipo de repositório persistente de dados (um
banco orientado a objetos, por exemplo).
A capacidade do Java de carregar uma classe dinamicamente, chamada
class loader, permite que uma classe seja transportada de um computador para
outro e que seja adicionada a um processo em execução que não possuía
conhecimento dela em tempo de compilação. Assim, objetos representando agentes
podem ser instanciados em outro lugar. Então, após a serialização dos dados do
20
objeto, esse mecanismo pode reconstruí-lo em outra JVM sem maiores
complicações no código. Além disso, existem restrições de segurança que podem
ser impostas ao código recém-carregado.
Por essas características, um sistema de agentes móveis pode muito bem
fazer uso das tecnologias Java estabelecidas pela Sun Microsystems. As
comunidades acadêmicas e de software livre, além das grandes indústrias de
software, vêm fortalecendo a linguagem com soluções de alta qualidade para o
desenvolvimento e depuração de aplicações.
3.5 FIPA
A FIPA (Foundation for Intelligent Physical Agents) é uma fundação
internacional sem fins lucrativos voltada exclusivamente para a criação de padrões
concretos de comunicação que tornem possível a implementação de agentes
abertos e interoperáveis [FIPA06].
A FIPA mantém um conjunto de documentos, entre os quais está a
descrição de uma linguagem de comunicação totalmente voltada para a
comunicação entre agentes: a FIPA-ACL (Agent Communication Language).
Uma mensagem FIPA-ACL possui os seguintes elementos:
•
Propósito da comunicação (por exemplo: informar, perguntar, ordenar,
negociar);
•
Agente remetente;
•
Agentes de destino;
•
Conteúdo;
•
Linguagem para expressar o conteúdo;
•
Ontologia.
Os padrões FIPA vêm crescendo em uso e qualidade, o que pode ser
verificado através da observação da grande variedade disponível de plataformas de
21
desenvolvimento de agentes compatíveis [Gomes03].
Mensagens FIPA-ACL permitem que diferentes arquiteturas de agentes
possam se comunicar.
Para garantir a interoperabilidade entre os agentes e em outras esferas do
processamento de informações organizacionais, é muito importante adotar a
compatibilidade com os padrões FIPA.
As especificações FIPA cobrem diversos aspectos do desenvolvimento de
sistemas de agentes, não apenas a comunicação entre eles, feita através da ACL,
mas toda a parte de gerenciamento e organização da comunidade de agentes
também é apresentado [VRBA][JADE]:
•
AMS (Agent Management System): é o agente responsável por
guardar os nomes e localizações de todos os agentes presentes na
comunidade (serviços de páginas brancas);
•
DF (Directory Facilitator): é o agente responsável por registrar e
informar os serviços oferecidos pelos próprios agentes da comunidade
(serviços de páginas amarelas);
•
MTP (Message Transport Protocol): especificação que define como
as mensagens devem ser trocadas entre os agentes dentro e fora da
comunidade. Ela garante que um agente de uma comunidade possa se
comunicar com um agente em outra plataforma. Por exemplo, as
plataformas JADE e FIPA-OS podem se comunicar pelos protocolos
baseados no IIOP (Internet Inter-ORB Protocol) ou no HTTP (Hypertext
Transmission Protocol).
Existem mais de quarenta documentos distintos formando o conjunto de
especificações da FIPA, divididos nas áreas de aplicações de sistemas multiagentes,
arquitetura abstrata para sistemas multiagentes, comunicação entre agentes,
gerenciamento de sistemas multiagentes e, por fim, transporte de mensagens entre
agentes. Porém, desta listagem o maior avanço e detalhamento da padronização
22
ocorreu no tratamento das questões relativas à comunicação dos agentes [Gluz02].
A FIPA preocupa-se em definir e especificar os elementos para construção
de sistemas multiagentes interoperáveis. Nenhuma implementação é desenvolvida
pela FIPA. Outras fundações e empresas já vêm divulgando várias implementações
das especificações FIPA. As plataformas de maior destaque atualmente são o JADE
[Bellifemine99], o ZEUS [Nwana99] e o FIPA-OS[FipaOS03].
Segundo análises feitas por Vrba [VRBA03], comparando as plataformas
de agentes JADE/RMI, FIPA-OS/RMI, ZEUS/TCP-IP e JACK/UDP, de uma maneira
geral, a plataforma JADE apresentou o melhor desempenho. Os testes consistiram
de troca de mensagens síncronas (em série) e assíncronas (em paralelo) entre
agentes. Foram contempladas as comunicações entre um par de agentes, entre dez
pares de agentes, com apenas um servidor e duas JVMs e com dois servidores.
Com base na extensa avaliação feita no trabalho de Vrba, adotou-se para esse
trabalho a plataforma de agentes JADE.
3.6 JADE
O JADE (Java Agent Development Framework) é um ambiente para
desenvolvimento e execução de sistemas multiagentes em conformidade com as
especificações FIPA, totalmente codificado em Java [JADE]. Esta biblioteca é livre e
é distribuída sob a licença GNU Lesser General Public License (LGPL), o que evita a
abertura do código dos aplicativos feitos com ela.
Há dois produtos fornecidos neste framework: uma plataforma de execução
de agentes concordantes com a FIPA e um pacote para desenvolvimento de
agentes Java.
O JADE é composto por diversos pacotes de classes que implementam as
especificações FIPA. Além deles, é fornecido um pacote de ferramentas para facilitar
a administração da plataforma e do desenvolvimento da aplicação. Algumas delas
23
são: um agente gráfico de gerenciamento da plataforma; um agente para
monitoração que permite enviar e receber mensagens ACL; um agente de escuta
para interceptar as trocas de mensagens ACL da comunidade; um agente para
monitorar o ciclo de vida dos agentes; uma interface visual para controlar o DF
(páginas amarelas); um agente para gerar log; um agente que funciona como
gateway bidirecional entre uma plataforma JADE e uma conexão via socket TCP/IP.
O JADE oferece uma plataforma distribuída de agentes, com uma interface
gráfica para controle, ferramentas de debug, mobilidade para os agentes (intraplataforma), aderência às especificações FIPA, registro automático no AMS, suporte
a linguagens de conteúdo e ontologias (descritas na seção 3.7) voltadas para a
aplicação, entre outras coisas.
Em conformidade com a FIPA, o ciclo de vida de um agente JADE
obedece à máquina de estados ilustrada na Figura 3 [JadePrg05].
Figura 3 - Ciclo de vida de um agente JADE
24
Os estados pelos quais um agente pode passar durante seu ciclo de vida
são:
•
Initiated: o objeto agente está criado, mas não registrado no AMS. O
agente não tem nome, nem localização e não pode se comunicar com
outros agentes;
•
Active: o objeto agente está registrado no AMS, com um nome e
localização e tem acesso aos elementos do JADE;
•
Suspended: o objeto agente está parado. Sua execução interna está
suspensa e nenhum comportamento está em processamento;
•
Waiting: o objeto agente está bloqueado, aguardando por algum
evento. Sua execução interna está dormente e será acordada quando
alguma condição desejada ocorrer (por exemplo, a chegada de uma
mensagem);
•
Deleted: o agente está definitivamente morto. Sua execução interna
terminou e o agente não está mais registrado no AMS;
•
Transit: o agente está se movendo para uma nova localização. O
sistema continua enfileirando as mensagens que então serão enviadas
para o novo local.
Os
agentes
executam
tarefas
através
de
implementações
de
comportamentos (behaviours). Eles podem realizar diversas tarefas, em resposta a
diferentes eventos externos. O JADE mantém apenas uma linha de execução de
tarefas por agente, na qual são implementados os diversos objetos Behaviour.
Agentes multitarefas podem ser implementados mas sem suporte específico desta
plataforma (exceto para a sincronização da fila de mensagens ACL). A Figura 4
mostra o modelo UML para os comportamentos JADE [JadePrg05].
Os principais comportamentos JADE são:
•
SimpleBehaviour: executa uma tarefa atômica;
•
OneShotBehaviour: executa uma tarefa atômica apenas uma vez.
25
Significa que este objeto não terá mais utilidade após ser processado;
•
CyclicBehaviour: classe abstrata que modela um comportamento
atômico a ser executado sem parar (quando termina, recomeça
automaticamente). Para permitir que outros comportamentos possam
ser executados, deve-se entrar em bloqueio programado;
•
TickerBehaviour: classe abstrata que implementa uma tarefa a ser
executada periodicamente.
O guia do programador JADE, disponível em [JadePrg05] fornece uma
descrição detalhada destes e dos demais comportamentos.
Figura 4 - Modelo UML da hierarquia de classes dos comportamentos JADE.
26
A FIPA especifica um conjunto de protocolos padrão de conversação entre
agentes. O JADE implementa os procedimentos destes diálogos entre agentes
através de comportamentos. Assim, com o uso de métodos de retorno (callbacks),
usados nestes comportamentos, agentes podem entrar em uma negociação com o
uso de uma API homogênea.
Um exemplo de negociação é o protocolo FIPA-Contract-Net (Figura 5). Ele
permite que um agente iniciador da negociação envie uma mensagem contendo
uma proposta para um conjunto de agentes participantes. Estes avaliam a proposta
e respondem ao agente iniciador. A intenção é firmar uma ligação dinâmica apenas
entre o agente iniciador e os agentes ouvintes que fornecerem as melhores
respostas. O agente iniciador manda, então, uma mensagem de aceite ou de recusa
aos agentes participantes. Para terminar a contratação, os agentes ouvintes apenas
confirmam a decisão do agente iniciador.
Figura 5 - Protocolo FIPA-ContractNet [Malucelli06].
27
Como visto na seção 3.5, uma mensagem FIPA-ACL deve possuir uma
identificação do propósito da mensagem. JADE implementa mais de vinte
propósitos, sendo utilizados na prototipagem REQUEST (perguntar), INFORM
(informar), QUERY-IF e QUERY-REF (pesquisar), CPF (convidar para uma
proposta), ACCEPT (aceitar), REJECT (rejeitar). A documentação do JADE
[JadePrg05] fornece exemplos de conteúdo de mensagens ACL com alguns desses
propósitos.
A plataforma JADE denomina o local no qual os agentes residem de
container. Em uma comunidade de agentes deve existir no mínimo o container
principal (main-container) que é o gerenciador dos serviços da plataforma, podendo
existir containers extras, dependentes do principal. O JADE implementa um sistema
de tolerância a faltas através da replicação do container principal em outros
computadores integrados à plataforma. Com essa funcionalidade ativada, os
containers principais fazem conferências entre si para manter a integridade da
comunidade, mesmo que haja a perda de alguns deles. Os demais containers
encontram os principais de uma forma automática. Apenas um dos containers
principais executa os serviços da plataforma, sendo chamado de Master-MainContainer [JadeAdm05]. A Figura 6 exemplifica uma plataforma JADE em execução
com dupla redundância do container principal.
Plataforma Distribuída JADE
A
Container-2
A
Container-1
A
(Master) Main-Container-1
A
Main-Container-2
Main-Container-N
Container-M
A
A
Figura 6 - Exemplo de uma plataforma distribuída JADE com tolerância a faltas.
28
3.7 ONTOLOGIA
Baseado na idéia de que as pessoas têm visões diferentes do mundo, os
sistemas e seus agentes também as têm.
Transformações sintáticas de dados para a troca de informações entre
sistemas não resolvem o problema da comunicação, pois domínios diferentes
representam o mesmo conceito de maneiras diferentes. É necessária uma
representação semântica dos dados.
Para promover um entendimento dos dados existentes em domínios
diferentes, é necessário que o conteúdo das mensagens utilize um vocabulário
especifico para a área de aplicação.
Situações que exigem a troca de informações entre modelos diferentes de
dados, com ontologias próprias, precisam resolver a questão das transformações
semânticas. Problemas de heterogeneidade estrutural e semântica são bem
conhecidos dentro das comunidades de sistemas distribuídos [Malucelli06]. Sistemas
de
informação
diferentes
podem
armazenar
dados
e
conceitos
usando
relacionamentos estruturais diferentes e podem considerar o conteúdo de um item
de informação e seu significado de formas diferentes.
[Malucelli06] analisa o cenário de uma comunidade MAS (multi-agent
system) aberta com domínios diferentes mas que precisam executar operações B2B
(Business To Business). Em tal cenário, é proposta a utilização de agentes de
serviços de ontologia para facilitar a troca de dados, com a implementação do
protocolo de Interação Ontológica (OIP).
A ontologia é um método de representação semântica do conhecimento.
Pode ser definida como “uma especificação formal e explícita de uma
conceitualização compartilhada” [Vergara02]. Esta definição pode ser entendida da
seguinte maneira:
•
É formal porque é interpretada e lida pelo computador;
29
•
É explícita porque define os conceitos, propriedades, relacionamentos,
funções, axiomas e regras condicionais que a compõem;
•
É uma conceitualização porque é um modelo abstrato e uma visão
simplificada dos fenômenos do domínio que ele representa;
•
É compartilhada porque há um consenso prévio sobre a informação e é
aceita por um grupo de especialista.
Outras variações da definição acima são encontradas na literatura. Uma
mais antiga diz que “é uma especificação formal e explícita dos termos de um
domínio e relações entre eles” [Gruber93].
Pode-se entendê-la como a definição de um conjunto de conceitos, sua
taxonomia, inter-relação e regras que governam tais conceitos.
Há dois tipos de ontologias: leves e pesadas [Uschold96]. As leves são
aquelas capazes de modelar a informação referida para um domínio mas não
incluem axiomas ou regras condicionais, dificultando o entendimento delas. As
pesadas incluem todos os elementos que permitem fazer deduções sobre o
conhecimento contido nela. Os axiomas e as regras fornecem uma maneira de
definir o comportamento relacionado a um modelo de informação. Desta maneira, os
modelos de informação podem ser entendidos como ontologias leves [Vergara02].
A FIPA descreve suas ontologias em termos de predicados, ações e
conceitos. Esta visão pragmática satisfaz todas as necessidades que os agentes
possuem em relação às suas comunicações [Gomes05].
Quando uma certa informação é transferida entre dois agentes por meio de
uma mensagem ACL, ela é representada como uma expressão que contém
linguagem de conteúdo e formato próprios. Ambos os agentes podem ter maneiras
diferentes para representar a informação. Para permitir uma manipulação fácil de
pedaços dessa informação, os agentes devem representá-la internamente também
de forma segmentada. As expressões de conteúdo das mensagens ACL não são
adequadas para essa finalidade [JadeOnto04]. Uma simples passagem de valores
30
em forma de uma seqüência de bytes prejudica a manipulação da informação, pois
requer que a cada vez se tenha que programar e processar as quebras da
seqüência para conseguir retirar o valor de interesse. Agentes escritos em Java
podem representar a informação convenientemente dentro de objetos Java,
facilitando a manipulação das mensagens.
Para que uma informação possa ser passada entre agentes, é necessário
converter sua representação interna para a correspondente expressão de conteúdo
ACL. O agente de destino deve executar a operação ao contrário. Além disso, o
agente de destino deve proceder com checagens semânticas para validar a
informação. O JADE contém suporte para linguagem de conteúdo e ontologias
fornecendo automaticamente todas as conversões e checagens descritas acima.
Desta forma, os desenvolvedores podem trabalhar com as informações em seus
agentes como se fossem apenas objetos Java sem necessidade de trabalhos extras.
Enquanto a ontologia se preocupa como os elementos do domínio são
especificados para que possam ser entendidos entre os agentes, a linguagem de
conteúdo define a forma como essa ontologia será escrita nas mensagens entre
eles. Assim, têm-se linguagens codificadas em caracteres, podendo ser lidas pelos
humanos, e outras que são codificadas em binário, decifráveis apenas pelo
computador mas com menor esforço computacional. Linguagens de conteúdo
especificam a sintaxe das mensagens e são independentes de domínio. As
linguagens de leitura humana facilitam os testes e a reprodução das mensagens em
uma aplicação.
Um exemplo de linguagem com leitura humana é a FIPA-SL (FIPA Content
Language Specification) e seu subconjunto FIPA-SL0, ambas suportadas pelo
JADE. Tal subconjunto permite a construção de ações, conceitos e predicados
binários simples, sem incorporar construções mais complexas nem instruções
booleanas. Ela facilita o processamento do conteúdo das mensagens. No presente
trabalho, todos os exemplos de ontologia estão representados por esta linguagem.
31
Para que agentes possam conversar sobre dados e fatos relacionados a
um domínio, explorando o suporte do JADE para linguagem de conteúdo e
ontologia, devem seguir estes passos:
1) Definir a ontologia, incluindo os predicados, ações e conceitos em
forma de esquemas específicos para eles;
2) Desenvolver as classes Java associadas a cada esquema da
ontologia;
3) Selecionar uma linguagem de conteúdo suportada pela plataforma;
4) Registrar a ontologia definida e selecionar a linguagem de conteúdo
para os agentes;
5) Criar e manipular as expressões de conteúdo como objetos Java, que
são as instâncias das classes desenvolvidas. O JADE irá traduzir estes
objetos para/de seqüências de bytes que formam o conteúdo dos slots
das mensagens ACL.
Existem várias ferramentas para a criação de ontologias, tais como
Ontolingua [Farquhar97], WebOnto [Domingue98], WebODE [Arpírez01], Protégé
[Noy00], OntoEdit [Sure02], OilEd [Bechhofer01], etc.
A ferramenta utilizada para os estudos desta monografia foi a Protégé, pois
é baseada no Java, é referenciada na documentação do JADE [JadeOnto04], possui
código aberto e funciona em computador isolado, sem dependência de servidor.
Outras características encontradas são: editor de ontologia com interface gráfica;
desenvolvimento de plugins (extensões); exportação e importação do modelo de
domínio para os formatos RDF (Resource Description Framework), XML (Extensible
Markup Language) e OWL (Web Ontology Language) através de plugins específicos.
Outro plugin existente para o Protégé e muito importante para o presente estudo é o
BeanGenerator [Bean06] [JadeOnto04]. Esta extensão mapeia objetos do modelo
em correspondentes classes Java geradas automaticamente em conformidade com
as especificações do JADE.
32
A exportação da ontologia, na parte experimental deste trabalho, foi feita
no formato OWL [Antoniou03] [McGuinness04]. OWL constitui-se de uma linguagem
de marcação (tags) semântica, desenvolvida como uma extensão de vocabulário do
RDF para definição, publicação e compartilhamento de ontologias na Web. OWL é
escrita em XML e possui todas as suas vantagens. Uma ontologia OWL contém
classes, propriedades, instâncias de classes e seus relacionamentos.
O JADE classifica os elementos de um domínio, de acordo com suas
características semânticas, através de um Modelo de Referência de Conteúdo (CRM
– Content Reference Model), apresentado na Figura 7 [JadeOnto04].
Figura 7 - O Modelo de Referência de Conteúdo do JADE
O modelo apresenta a definição de predicados (predicates) e termos
(terms):
•
Predicates: expressões booleanas que apresentam o estado de um
relacionamento
entre
elementos.
São
tipicamente
usados
em
33
mensagens ACL com propósito INFORM ou QUERY-IF;
Exemplo: a expressão “a pessoa Ciro trabalha para a companhia
COPEL” pode ser identificada por (Trabalha-para (Pessoa :nome Ciro)
(Companhia :nome COPEL)).
•
Terms: expressões de identificação de entidades (abstratas ou
concretas) que existem no mundo. Os termos são classificados em:
o
Concepts: expressões que indicam entidades com estruturas
complexas, definidas como slots.
Exemplo: (Pessoa :nome Ciro :idade 35)
Conceitos não fazem sentido se usados diretamente como
conteúdo de uma mensagem ACL. Geralmente, eles são
referenciados em predicados ou em outros conceitos;
Exemplo: (Livro :titulo “Anjos e Demônios” :autor (Pessoa :nome
“Dan Brown”))
o
Agent actions: conceitos especiais que indicam ações a serem
executadas nos agentes. São tipicamente usados em mensagens
com propósito REQUEST;
Exemplo: (Vender (Livro :titulo “Anjos e Demônios”) (Pessoa
:nome Ciro))
o Primitives: expressões que indicam entidades atômicas como
strings e integers;
o Aggregates: expressões indicando entidades que são grupos de
outras entidades;
Exemplo: (sequencia (Pessoa :nome Fulano) (Pessoa :nome
Sicrano))
o Identifying Referential Expressions (IRE): expressões que
identificam entidade(s) para a(s) qual(is) um dado predicado é
verdadeiro. São tipicamente usados em mensagens com propósito
34
QUERY-IF ou QUERY-REF;
Exemplo:
(todos ?x (Trabalha-para
?x
(Companhia :nome
COPEL))) identifica “todos os elementos ‘x’ que têm o predicado
‘trabalha para a companhia COPEL’ como verdadeiro”, ou “todas
as pessoas que trabalham para a COPEL”.
o Variables: expressões (tipicamente usadas em pesquisas) que
indicam um elemento genérico não conhecido a priori.
35
4
PADROES IEC / CIM
Esse capítulo mostra uma pesquisa sobre a padronização de um modelo
de informações a ser utilizado em empresas de energia elétrica. O entendimento da
evolução de especificações para a troca de dados existente na área elétrica conduz
para a otimização dos recursos aplicados numa arquitetura distribuída.
Os investimentos de TI implicam que a organização deve desenvolver uma
abordagem de integração de aplicações corporativas que seja flexível, prática e
adaptável de tal forma que integrações de sistemas comprados ou construídos
possam ser realizadas de forma consistente e simples [Prates05].
As tecnologias de midlleware específicas para solução de problemas de
integração
de
sistemas
também
começaram
a
ficar
disponíveis
para
comercialização, diminuindo, em muito, o custo das soluções de EAI (Enterprise
Application Integration).
A partir de meados dos anos 90, vários projetos com objetivo de padronizar
métodos de troca de informação nas empresas foram iniciados. Pode-se citar o
projeto de uma Interface de Programação de Aplicações para Centros de Controle
(CCAPI - Control Center Application Programming Interface) do EPRI (Electric Power
Research Institute), o projeto do Sistema de Gerenciamento de Inventário da
NRECA (National Rural Electrical Cooperative Association) e os projetos de
especificação de padrões do IEC (International Electrotechnical Commission).
Fundamentalmente, estes projetos tinham o foco no mesmo problema que era
integrar as informações de processo com as informações corporativas, usando
metodologias padronizadas e expansíveis.
O IEC [IEC06] é uma entidade internacional constituída por um conjunto de
comitês técnicos responsáveis pelo desenvolvimento de padrões internacionais. Há
diversos grupos de trabalho em cada comitê. As decisões do IEC são feitas pelos
comitês nacionais, resultando em uma liberação de padrões internacionais. Os
36
membros dos comitês nacionais participam dos grupos para desenvolver os projetos
dos padrões. No Brasil, o representante oficial e exclusivo do IEC é a ABNT
(Associação Brasileira de Normas Técnicas) [ABNT06]. Nos Estados Unidos, a
participação se faz pelo ANSI (American National Standards Institute) [ANSI06].
4.1 TENDÊNCIA PARA BARRAMENTO DE INTEGRAÇÃO
Com o surgimento de sistemas baseados em padrões, a interoperabilidade
dentro da empresa tende a crescer, favorecendo a aquisição de componentes de
diferentes vendedores que são executados em uma solução única. Mas, com o
aumento do número de aplicações instaladas em uma corporação, fica visível o
problema de duplicação de informações por falta de integração dos bancos de
dados.
As áreas de TI têm custos elevados com o desenvolvimento de
adaptadores
para
troca
de
dados
entre
os
sistemas
em
sacrifício
do
desenvolvimento de novas funcionalidades. Sem existir um formato de intercâmbio
padronizado ou modelo de dados, percebe-se que a cada necessidade por mais
dados, mais adaptadores aparecem [Uslar05].
Uma informação de uso comum aliada a um modelo de dados para o
domínio dos sistemas de energia é um caminho possível para incrementar a
interoperabilidade entre áreas diferentes da empresa e entre outras empresas. Esta
característica diminui o número de conexões ponto-a-ponto necessárias entre os
sistemas, pondo em uso um único barramento de mensagens que, por
conseqüência, reduz também os custos de manutenção dentro da área de TI. Uma
solução pode ser realizada através de EAI. Mas, a simples construção de
adaptadores para conectar cada sistema independente à plataforma EAI, muitas
vezes não resolve problema de incompatibilidade nas estruturas dos dados
existentes no modelo de dados comum. Por falta de equivalência semântica, o dado
37
é perdido [Uslar05]. Então, o modelo de dados deve ser o mais abrangente possível.
Caso não seja, deve permitir extensões, sem comprometimento das funções de
interoperabilidade.
Mais recentemente, arquiteturas mais adaptáveis foram desenvolvidas.
Estas arquiteturas permitem aos sistemas operar em sintonia enquanto evitam uma
excessiva interdependência e provêem mecanismos para integrar sistemas legados
mais facilmente. Esta arquitetura é chamada de “Barramento de Integração” ou
modelo de “Publicação e Assinatura”” (Publish/Subscribe). Nesta abordagem, todos
os sistemas conversam com um único barramento de integração, que é uma peça de
middleware que gerencia a passagem de mensagens entre as aplicações.
A necessidade de padronizar uma técnica de integração também estava
sendo discutida nos comitês internacionais de padronização como o Technical
Committee 57 do IEC e no Object Management Group (OMG). Em particular, o
conceito de “Barramento de Integração” estava sendo apresentado para os grupos
de trabalho do IEC e do OMG.
O Workgin Group 14 é um grupo de elaboração de padrões do IEC, dentro
do Technical Committee 57 (TC 57), que está trabalhando em uma norma
internacional chamada IEC 61968. Este padrão tem como foco a integração das
maiores aplicações de uma concessionária relacionada com gerenciamento da
distribuição, e está baseada na abordagem do Barramento de Integração.
Os resultados destes trabalhos estão hoje consolidados em padrões
internacionais, como Common Information Model (IEC 61970) e System Interfaces
for Distribution Management (IEC 61968). Estes modelos aplicados utilizam
tecnologias tais como XML e têm feito grande progresso. E, além disso, têm
permitido uma abordagem de integração mais sistemática baseada num modelo de
troca de informações comuns.
38
4.2 O PADRAO IEC 61970-301 (CIM)
A norma IEC 61970-301 define o modelo de dados CIM (Common
Information Model) [CIM06] e tem como objetivo ser um modelo abstrato de dados
que represente todos os objetos importantes em uma concessionária de energia. O
CIM foi originalmente desenvolvido pelo EPRI no CCAPI e submetido ao IEC, WG13
do TC57 que tem foco em EMS (Energy Management Systems). Posteriormente,
este modelo foi estendido pelo WG14 de tal forma a atender geração, transmissão e
distribuição.
Estes
trabalhos
são
coordenados
com
outras
iniciativas
de
padronização tais como OAG (Open Applications Group) e OMG que estão
relacionadas com os sistemas administrativos e gerenciais das empresas em geral.
Assim, aplicações voltadas para as áreas de geração, transmissão, distribuição de
energia, bem como a parte de apoio administrativo, podem ser modeladas por essa
norma.
O CIM é um modelo de informação que usa estrutura básica e conceitos do
modelo orientado a objetos. Ele proporciona uma definição e uma estrutura de
dados coerentes que servem para gerenciar aspectos comuns de um domínio.
Permite troca de informações entre plataformas distintas sem estar amarrado a
implementações específicas.
É composto de um esquema e uma especificação:
•
Esquema CIM: descreve o modelo atual de gerenciamento da
informação;
•
Especificação CIM: define os detalhes para integração com outros
modelos de gerenciamento.
O esquema CIM fornece um conjunto de definições de classes com
propriedades e associações que permite um entendimento da estrutura conceitual
do modelo e uma organização das informações disponíveis. É estruturado em três
camadas:
39
•
Modelo Central (Core): contém noções aplicáveis a todas as áreas de
gerenciamento. É um conjunto de classes, associações e propriedades.
Fornece um vocabulário básico para análise e descrição do sistema
gerenciado;
•
Modelo Comum (Common): contém noções comum a uma área
específica de gerenciamento. Independe de uma tecnologia específica
ou implementação para desenvolvimento de aplicações. Fornece um
grupo de classes básicas para extensão de um esquema específico;
•
Esquema de extensão: representa extensões de tecnologia específica
para o modelo comum. Permite expandir classes e associações a partir
do modelo básico.
A especificação CIM fornece um meta-modelo orientado a objetos baseado
no UML que define sintaxes, regras.
O meta-modelo pode ser visto na Figura 8. Ele fornece a definição formal
de termos para expressar usos e semânticas no CIM.
Figura 8 - Meta-modelo do CIM.
40
Elementos do Modelo:
•
Schema: grupo de classes usado para administrar e nomear classes;
•
Class: coleção de instâncias com as mesmas propriedades e métodos;
•
Property: valor usado para indicar a característica de uma classe;
•
Method: declara o nome do método, tipo e parâmetros de retorno;
•
Trigger: reconhecimento de uma mudança de estado de uma classe e
atualização ou acesso de uma propriedade;
•
Association:
classe
que
contém
duas
ou
mais
referências
representando relacionamento entre dois ou mais objetos;
•
Reference: define regra que o objeto representa na associação;
•
Qualifier: fornece informações adicionais de classes, associações,
indicações, métodos, propriedades ou referências.
As classes do modelo de dados CIM estão divididas em aproximadamente
vinte pacotes estruturais. Os principais pacotes podem ser vistos na Figura 9.
Generation
Dynamics
LoadModel
Production
Generation
Outage
Protection
SCADA
Financial
Wires
Meas
Energy
Scheduling
Topology
Reservation
Core
Domain
Figura 9 - Visão geral dos pacotes CIM.
41
Segue uma descrição desses pacotes:
•
Core: fornece os objetos básicos, como o PowerSystemResource e o
ConductingEquipment, usados por quase todas as aplicações que
implementam o modelo;
•
Domain: define os tipos de dados básicos usados pelos atributos
dentro do modelo;
•
Wires: modela informações elétricas das redes de transmissão e
distribuição. É usado em aplicações de rede como Estimador de Estado
e Fluxo de Potência;
•
Topology: fornece pontos de conectividade entre os objetos dos
pacotes Core e Wires;
•
Meas: diferentemente dos pacotes anteriores que fornecem facilidades
para modelar dados estáticos, este pacote (forma abreviada para
Measurement) modela os dados dinâmicos, como os utilizados nos
fluxos de potência e no estado dinâmico da topologia;
•
Generation: é composto por dois sub-pacotes, Production e Generation
Dynamics, que tornam possível a modelagem de todos os diferentes
tipos de unidades geradoras de energia;
•
LoadModel: completam a possibilidade de modelagem de dados
dinâmicos;
•
Outage: modela informações da configuração de rede corrente e para
planejamento. São entidades opcionais dentro de uma aplicação de
rede típica.
•
Protection: modelagem de dispositivos de proteção, permitindo fazer
simulação adequada e criar detectores de falha no item elétrico.
O intercâmbio de dados entre empresas é o alvo do padrão IEC 61970302. Nele, tem-se mais três pacote: EnergyScheduling, Financial e Reservation.
O padrão IEC 61970-303 foca nas aplicações SCADA, suportando controle
42
operacional de equipamentos, abertura/fechamento de disjuntores. A parte de
aquisição de dados reúne dados telemétricos de várias fontes.
Os consumidores e suas características como carga do sistema,
parâmetros relacionados com certos horários do dia e dados associados também
podem ser também modelados.
Os diagramas de classes do modelo estão disponíveis em [CIM06] no
formato MDL (Rational Rose). Para exemplificar, a Figura 10 mostra a hierarquia dos
equipamentos relacionados com o pacote Wires. Então, quando se precisa gerar
uma representação de um breaker (disjuntor), sabe-se que este objeto herda as
características do objeto genérico switch (chave) que, por sua vez, representa um
recurso do sistema elétrico do tipo equipamento de condução.
Figura 10 - CIM: Hierarquia de classes de equipamentos.
43
O CIM pode ser implementado através das seguintes formas:
•
Repositório: armazena o modelo de informações na base de dados
(BD) para acesso de programas;
•
Aplicações DBMS: transforma definição conceitual em tecnologia
particular de BD. A troca de informações é feita com acesso a DBMS
comum;
•
Aplicações de objetos: cria um conjunto de objetos de aplicação numa
linguagem especifica;
•
Parâmetro de troca: troca informações na forma de um conjunto de
APIs.
No capítulo 5, é apresentado um modelo reduzido do CIM implementado
em objetos Java para aplicação no protótipo.
Outras definições existentes na norma IEC-61970 dizem respeito à
serialização dos objetos instanciados para a troca de dados na forma binária ou
ASCII. O IEC propõe o uso do esquema CIM RDF. A sintaxe RDF é uma infraestrutura padronizada pelo W3C (World Wide Web Consortium) para codificação,
troca e reuso de informações estruturadas na Web. RDF usa XML como sintaxe de
codificação [Vos01].
O CIM é um padrão aberto, vivo, que tem respaldo em organizações
voltadas tanto para o desenvolvimento de sistemas de informática quanto para a
engenharia elétrica e vem evoluindo ao longo de anos para melhorar a
interoperabilidade entre companhias de energia.
Enquanto o CIM está focado nos centros de controle, o padrão IEC 61850
implementa a troca de dados dentro das subestações. Há a necessidade de um
mapeamento entre estes dois padrões, realizado por uma extensão UML do IEC
61850 SCL (Substation Configuration Language). [Hughes04] propõe uma interação
harmônica entre estes modelos.
44
4.3 CIM VERSUS ONTOLOGIA
O CIM cobre muitos aspectos de uma ontologia de dados para a área de
energia pois é um padrão aberto a diversas formas de uso e implementação.
[Uslar05] propõe o uso do modelo CIM como uma ontologia para os
objetos mais conhecidos no domínio de sistemas de energia.
Como visto nas definições de ontologia, um modelo de informação pode
ser entendido como uma ontologia leve [Vergara02]. O modelo CIM define a
informação do domínio administrado de uma maneira formal e em concordância com
grupos de trabalho dentro do IEC. Entretanto, ele não fornece suporte semântico
para
a
dedução
do
conhecimento
baseado
nele
e,
para
conseguir
a
interoperabilidade, precisa ser estendido com axiomas e regras para se tornar uma
ontologia pesada.
Em termos de objetos, o trabalho com ontologia não é complicado. A única
diferença é que a terminologia é mais ampla e algumas vezes difere da orientação a
objeto: classes são chamadas de conceitos ou estruturas (frames); e atributos viram
slots.
Existem ferramentas no mercado para a geração dos arquivos de
ontologia. Então, pode-se inserir os conceitos existentes no CIM de forma manual
nesses aplicativos para que se tenha os arquivos em Java de representação da
ontologia a ser usada num sistema distribuído.
Existem diversas linguagens para a definição das ontologias. Cada
software implementa uma. Para aplicações voltadas para a Web, existe a OWL. Para
a criação da ontologia baseada diretamente no CIM, modelada em UML, pode-se
usar a OCL (Object Constraint Language) [Vergara02]. Esta linguagem permite a
definição de regras. Os axiomas e regras (constraints) permitem a formalização dos
conceitos pertencentes a um certo domínio, fornecendo os comportamentos, que,
por sua vez, estão intimamente relacionados à ontologia.
45
Resumindo, o CIM pode ser apontado como uma ontologia leve, pois
define um conjunto de conceitos compartilhados de um domínio mas não provê
mecanismos para formalizar regras condicionais ou definição de comportamentos.
Então, o CIM poderia ser expandido para agregar comportamentos, pelo uso de uma
ferramenta de ontologia. A OCL pode ser a linguagem propicia para a geração da
ontologia CIM expandida pois é parte da especificação UML e o CIM usa diagramas
de classe UML.
46
5
EXPERIÊNCIA
Este capítulo discorre sobre a parte experimental realizada com
tecnologias Java para validar o uso de agentes e do modelo CIM.
Questionamentos sobre o que é um centro moderno de controle de um
sistema elétrico são também foco de outras pesquisas. Há a preocupação em se
mostrar a exaustão das arquiteturas atuais e a tendência de uma operação única
mas geograficamente distribuída [Azevedo00].
Os principais problemas que as novas gerações dos centros de controle
estão enfrentando são:
•
Evolução constante de objetivos, métodos e necessidades: o cenário de
poucas mudanças para o qual eram projetados os centros está sendo
reformulado para uma situação mas dinâmica. Isto exige projetos de
software mais modulares, com facilidade de substituição, adição ou
remoção de componentes;
•
Variação da carga computacional: a sólida organização do ambiente
computacional dos centros existentes traz uma relativa estabilidade na
carga de processamento. Considerando-se um novo ambiente em que
parceiros externos independentes desempenham um papel importante,
a estrutura do centro deverá ser capaz de se adaptar a grandes
variações de cargas;
•
Operação mais próxima dos limites do sistema de energia: interesses
econômicos exigirão maior ajuste fino das aplicações. Um controle
otimizado para um sistema elétrico permite que este trabalhe mais
próximo de seus limites sem aumento de riscos envolvidos, ampliando o
ganho e reduzindo a necessidade de novos investimentos. Os
operadores devem ter fácil acesso às informações necessárias sem
precisar lançar mão de vários programas ou interfaces. As interfaces
47
devem ser projetadas para envolver o operador com as ações
necessárias para execução e não com os programas de aplicações
especificas;
•
Rápida obsolescência computacional: a arquitetura de software deve
ser tão aberta e modular quanto possível para estender a vida dos
projetos de centros de controle;
•
Distribuição geográfica: o conceito de um centro de controle como um
ambiente físico delimitado está sendo gradualmente substituído por um
único ambiente distribuído.
Com base nessas idéias, partiu-se para a concepção de uma arquitetura
de software e execução de um protótipo de sistema de automação distribuído com
tecnologia de agentes e uso de padrões.
5.1 ARQUITETURA HIPOTÉTICA
Uma nova arquitetura baseada na integração da estrutura existente, mas
que contemple padrões abertos, deve ser experimentada através de um pequeno
protótipo que ponha em discussão a validade das tecnologias Java. Visto do ponto
prático, os conceitos abordados neste trabalho ganham um novo prisma e a
percepção de uma futura aplicação real começa a ganhar volume.
A execução de um protótipo apresenta diversos questionamentos que
devem ser resolvidos. O primeiro deles, é a identificação das premissas:
•
Prover modularização do sistema, facilitando manutenção, expansão e
troca das partes integrantes;
o
O capítulo 3 tece diversos benefícios sobre o uso da tecnologia de
agentes em um sistema distribuído. Sendo esse um dos focos
desse trabalho.
o
A separação do sistema distribuído em camadas, atendendo ao
48
padrão MVC (model-view-controller) foi empregado no protótipo.
•
Facilitar a integração com outros sistemas;
o
Como investigado no capítulo 4, o padrão IEC/CIM destina-se à
modelagem de dados numa empresa do setor elétrico de forma a
ser reconhecido por outros participantes da rede.
•
Utilizar linguagem Java e outros padrões abertos;
o
Como visto na seção 3.5, adotou-se o ambiente JADE como
ferramenta de desenvolvimento e execução de agentes em Java.
Esta plataforma é aderente aos padrões FIPA, é livre e construída
totalmente em Java.
o
A exploração do modelo CIM também colabora na utilização de
padrões.
O segundo ponto é a definição de uma arquitetura hipotética. O cenário
imaginado é uma mera especulação científica e que carece de maiores agregados
para ser considerado como uma base robusta de um sistema real.
A atual arquitetura do sistema de operação traz uma forte dependência
entre as arquiteturas física e lógica. Como apresentado no capítulo 2, os centros de
operação concentram uma infra-estrutura computacional que não favorece
rearranjos dinâmicos entre operadores de centros diferentes. Para resolver isso,
foram estudadas diversas formas de se montar uma nova arquitetura física que
satisfizesse à arquitetura lógica existente.
A arquitetura usada para balizar o protótipo prevê a existência de IHMs
leves, implementadas em navegadores de Internet conhecidos. As sessões de
operação seriam controladas por uma parte do sistema batizada de COV (Centro de
Operação Virtual). Os operadores acessariam páginas dinâmicas em servidores
Web espalhados na rede dedicada. A tecnologia empregada na camada de
apresentação supriria as características funcionais existentes na IHM do SASE.
Questões como atualização rápida e periódica, representação gráfica de diagramas
49
unifilares e facilidade de manutenção e reconfiguração devem ser cuidadosamente
estudadas.
Tecnologias
como
SVG
(Scalable
Vector
Graphics)
e
AJAX
(Asynchronous JavaScript and XML) foram utilizadas no protótipo. Entretanto, o
estudo dessas tecnologias foge do escopo deste trabalho, podendo ser obtido em
[Dometerco06].
Nessa arquitetura, o SASE não mais existiria nos centros de operação. Sua
dimensão se restringiria às subestações, controlando os IEDs e executando as
funções elétricas automáticas. Na rede de operação existente em cada subestação,
inserir-se-ia um computador comunicando-se com o SASE e também executando a
solução de agentes na JVM. Por meio de conectores JNI, os dois ambientes
trocariam dados.
Uma vez dentro da plataforma de agentes, o fluxo de dados pode seguir
diretamente para outros agentes ou para o servidor Web associado com uma sessão
de navegação do operador.
Haveria um sistema geral de controle, atuando como mediador para as
sessões de operação, que reconheceria todas as subestações disponíveis para
gerenciamento e todos os usuários operadores. 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 e; uma camada intermediária, ponte entre as duas anteriores. A arquitetura
permitiria que qualquer centro, aplicando-se as devidas regras de segurança,
controlasse uma subestação independentemente da sua localização geográfica.
A estrutura física do sistema distribuído pode ser entendida analisando a
Figura 11. Cada subestação contém uma rede IP local para uso do SCADA. Nela,
pode-se inserir um computador com a aplicação “JAVA SE”. Esta aplicação é
executada sobre a plataforma de agentes JADE, com o modelo CIM implementado
na forma de objetos, comunicando-se com o SCADA. Através de um switch, tem-se
50
a ligação com a VLAN dedicada para a automação, implantada sobre a rede de
fibras ópticas que cobre todo o estado do Paraná.
Servidor JAVA - 1
Operador 1
Subestação N
Rede dedicada
Subestação 1
Operador Z
switch
Servidor JAVA - N
Ethernet
UCC
UCC
Aplicação JAVA SE
comutador serial
UTR
UTR
UTR
Figura 11 - Estudo da estrutura física na COPEL.
Os microcomputadores IHM representam as diversas sessões de aplicação
nos usuários, através de um navegador de Internet capacitado para executar
chamadas AJAX e interpretar tags XML de gráficos SVG. Estes IHMs se conectam
apenas na rede dedicada e representam os operadores de todos os centros de
controle.
Os computadores identificados como “Servidores JAVA” devem executar o
container Tomcat para servir as páginas aos microcomputadores IHMs. Também
devem executar as aplicações “JAVA COV”. Estas aplicações são executadas sobre
51
a plataforma JADE e implementam os conceitos de um COV.
Dentro do Tomcat existem servlets que disparam um container JADE. É
neste container que os agentes SEnProxy, explicados na seção 5.5, serão ativados
quando uma aplicação “JAVA SE” estiver presente na rede.
Uma vez que o modelo J2EE garante redundância para as sessões que
são executadas nos servidores Web, que o JADE especifica uma redundância de
main-container (não testado) e que a rede dedicada seja abrangente, robusta e
rápida, percebe-se que não há mais a necessidade de amarração física entre os
computadores IHM e os servidores Java e nem que haja uma correspondência em
quantidade de centros de controle reais e servidores Java.
Um exemplo de estrutura lógica do sistema pode ser visto na Figura 12.
Existem dois centros de controle: o COV 1 e o COV 2. Cada centro contém dois
operadores: COV 1 com operadores 1 e 2 e o COV 2 com operadores 3 e 4. O COV
1 controla as subestações 1 e 2. O COV 2 controla as subestações 3 e 4. Esta
configuração pode ser estruturada fisicamente da seguinte forma:
•
COV 1 é a aplicação “JAVA COV 1”, residente no servidor JAVA – 1;
•
COV 2 é a aplicação “JAVA COV 2”, residente no servidor JAVA – 2;
Neste exemplo, tem-se uma mera coincidência de quantidades de
centros e de servidores Java.
•
SE 1, SE 2, SE 3, SE 4 são as aplicações “JAVA SE 1”, “JAVA SE 2”,
“JAVA SE 3”, “JAVA SE 4”, residentes nas subestações 1, 2, 3 e 4,
respectivamente;
•
O COV 1 decidiu que o container Web a ser usado para vincular a SE 1
ao sistema é o existente no próprio servidor Java no qual ele se
hospeda. No caso, é o “ContainerWEB1”. Então, os operadores 1 e 2
receberão dados da subestação 1 em seus navegadores pelo Tomcat
existente no servidor JAVA – 1;
•
O COV 1 também decidiu que a SE 2 será atribuída ao
52
“ContainerWEB2”. Então, os operadores 1 e 2 receberão dados da
subestação 2 em seus navegadores pelo Tomcat existente no servidor
JAVA – 2;
•
Da mesma forma, o COV 2 decidiu que a SE 3 será atribuída ao
“ContainerWEB2” e a SE 4 ao “ContainerWEB1”. Assim, os operadores
3 e 4 receberão os dados da SE 3 pelo Servidor JAVA – 2 e os dados
da SE 4 pelo Servidor JAVA – 1;
Servidor JAVA - 1
COV 1
SE 1
SE 3
Operador 1
Operador 3
SE 2
Operador 2
SE 4
Operador 4
COV 2
Servidor JAVA - 2
Figura 12 - Estudo da estrutura lógica na COPEL.
Numa etapa anterior ao protótipo com agentes, foram feitos testes com
outras tecnologias de interconectividade, como Sockets, Java RMI e Web Services.
Seus resultados e avaliações podem ser obtidos em [Dometerco06] e [Geus06].
53
Para o trabalho no laboratório, utilizou-se a seguinte infra-estrutura de
hardware e de software:
•
Computadores PC Pentium ou AMD com 2GHz e 512MB de RAM;
•
Rede corporativa Ethernet Gigabit;
•
Sistema operacional Windows XP servicepack2;
•
JavaTM 2 Platform Standard Edition Development Kit 5.0 (JDK 1.5.0)
[Java06];
•
Ferramenta de desenvolvimento Eclipse SDK 3.2.1 Web Tools Platform
[Eclipse06];
•
Plataforma de agentes JADE 3.4 [Jade06];
•
Container JSP (Java Server Pages) Tomcat 5.5.9 [Tomcat06];
•
Navegador MS-Internet Explorer 6.0 sp2 [IE06];
•
Plugin Adobe SVG Viewer para visualização de gráficos SVG no MS-IE
[AdobeSVG06];
•
Ferramenta de modelagem UML Rational Rose 8.0 for Java
[Rational06];
•
Especificação CIM versão 10 revisão 4 [CIM06];
•
Editor de ontologia Protégé 3.1 [Protege06];
•
Plugin BeanGenerator 3.1.1 para criação de classes JADE no Protégé
[Bean06];
5.2 MODELAGEM DA SUBESTAÇÃO
Após a identificação das premissas, é necessário especificar os requisitos
mínimos existentes numa subestação (SE). Por ser um experimento inicial, seu
objetivo é mostrar que a tecnologia pode ser aplicada num sistema de automação.
Assim, reduziu-se ao máximo a modelagem de uma subestação real. A subestação
criada apresenta características encontradas em campo mas não possui um
54
correspondente real para uso no protótipo.
A SE contém apenas um transformador que recebe a tensão de outro localfonte. Para este transformador, tem-se também apenas um barramento sem
transferência e que alimenta dois circuitos de baixa tensão. Entre o transformador e
o barramento existe um disjuntor como elemento de proteção. Também se deve
considerar um disjuntor para cada circuito alimentador.
O diagrama unifilar correspondente pode ser visto na Figura 13.
Figura 13 - Unifilar proposto para o protótipo.
As medidas que podem ser lidas são:
•
VB:
Tensão no barramento, analógica;
•
FB:
Freqüência no barramento, analógica;
•
I1:
Corrente no circuito 1, analógica;
•
P1:
Potência no circuito 1, analógica;
•
I2:
Corrente no circuito 2, analógica;
55
•
P2:
Potência no circuito 2, analógica;
•
DP:
Estado do disjuntor principal, digital;
•
D1:
Estado do disjuntor do circuito 1, digital;
•
D2:
Estado do disjuntor do circuito 2, digital.
Além das medidas, a SE também pode executar comandos de abertura e
fechamento nos disjuntores.
5.3 SIMULADOR DE SUBESTAÇÃO
Como visto na descrição da arquitetura (seção 5.1), em uma subestação
deve ser executada uma aplicação Java que se comunica com o aplicativo SASE por
meio de conexão JNI. Outra forma seria a troca de mensagens com a plataforma de
agentes. Na seção 2.1, mostrou-se que o SASE foi construído em C, mas, não utiliza
um middleware que permita envio de mensagens IIOP, como o CORBA, para efetuar
a comunicação externa com o JADE (seção 3.5). Então, foi estudada a primeira
alternativa, com a carga de uma máquina Java a partir de um programa C e
instanciação de classes para popular valores nas estruturas de dados da linguagem
C e nos seus respectivos objetos Java. Estes testes não evoluíram pois
necessitariam de uma adaptação significativa do SASE para se comunicar com a
parte desenvolvida em Java, fugindo do foco deste trabalho.
A partir daí, criou-se um simulador para gerar atualização dos valores. A
aplicação
Java
executada
num
micro
simulando
uma
SE
contém
uma
implementação reduzida de objetos CIM para representar os valores tempo-real das
medidas analógicas, dos estados digitais e dos comandos digitais.
Este simulador apresenta as seguintes funcionalidades:
•
Implementa o CIM;
•
Os valores analógicos são atualizados aleatoriamente, dentro da faixa
estipulada para variação de acordo com o objeto CIM, a cada dez
56
segundos;
•
Os valores analógicos consideram os estados dos disjuntores. Por
exemplo, se o disjuntor D1 está aberto, as medidas de I1 e P1 ficam
zeradas;
•
Pode-se ler o banco analógico através de uma lista de medidas
analógicas de interesse;
•
As medidas digitais sofrem mudanças em períodos aleatórios na faixa
de cinco a dez segundos;
•
As mudanças de estado ficam armazenadas numa fila circular de até
300 registros, com a estampa de tempo das ocorrências;
•
Pode-se ler a fila de mudanças passando a quantidade de pontos que
se quer retirar dela. Quando o método for chamado, as mudanças
enviadas são eliminadas da fila;
•
Pedido de lista de valores analógicos CIM pelo teclado com
apresentação das mudanças na console (interface local). Deve-se
passar
uma
lista
contendo
atributos
name
dos
objetos
MeasurementValue cujos valores desejam ser recebidos;
•
Pode-se ler todas as medidas digitais (varredura de consistência);
•
(*) Recebe pedidos de comando através de identificações numéricas de
pontos de comando (PC), relacionados com a abertura ou fechamento
de cada um dos disjuntores;
•
(*) Simula a ação de comando através da mudança de um ponto de
estado (PE) relacionado ao equipamento desejado. Este ponto é
chamado PE de retorno;
•
(*) Após o recebimento de um comando, o PE de retorno passa para o
estado desejado após dois segundos e meio, sendo prevista a
simulação de falhas no acionamento a cada quatro comandos com
sucesso;
57
•
(*) Pode-se ter apenas um comando por vez;
(*) – Não modelado no CIM. Testado apenas na interface local do simulador.
5.4 IMPLEMENTAÇÃO DE OBJETOS CIM
Devido à abrangência da especificação CIM, uma implementação completa
iria consumir muito tempo e não seria o mais adequado para o protótipo. Fez-se um
trabalho de redução das classes originais para o estritamente necessário de modo a
modelar a subestação definida na seção 5.2. Com a exclusão das classes, muitos
pacotes também não tiveram representação, sendo eliminados. A Figura 14 mostra o
diagrama de classes completo do modelo reduzido gerado para o protótipo. Foi
ocultada a classe Core.Naming do diagrama para evitar a poluição visual, pois ela é
a superclasse de todas as demais do modelo que precisam de identificação por
nome.
A implementação do CIM reduzido foi feita na forma de objetos criados
estaticamente. Não foi usado banco de dados nem persistência para esses objetos.
Nem todas as classes do modelo reduzido foram necessárias. A lista de todos os
objetos presentes na aplicação Java executada na subestação estão na Tabela 2.
Os comentários na linha das medidas significam que outros atributos do objeto foram
preenchidos. O número entre parênteses identifica o valor considerado normal para
a medida. A letra n representa a faixa de variação considerada normal.
Foi implementado apenas um sensor (MeasurementValue) por medida
(Measurement).
Apesar de haver no modelo a classe para definição do transformador, seus
enrolamentos e comutador de taps, eles ainda não foram utilizados na
implementação.
CimVersionREDUZIDO
58
(from CIM)
Version : Logical View::jav a::lang::String = "cim10_030501"
LastUpdate : Logical View::jav a::lang::String = "11/05/2006"
CimVersionREDUZIDO()
+MemberOf _PSR
ValueToAlias
(from Meas)
+Values
1..n
PowerSy stemResource
(from Core)
0..1
+Terminal
+ValueAliasSet
Line
(from Wires)
Measurement
Value
1
ValueAliasSet
+Contains_Equipments
(from Meas)
(from Meas)
1..n
+Contain_MeasurementValues
0..1
+ValueAliasSet
0..1 +ValueAliasSet
+ConductingEquipment
0..1
0..n
Equipment
(from Core)
EquipmentContainer
(from Core)
+Controls
0..n
Control0..n
(from Meas)
+ControlledBy _Control
0..1
+Measurements
0..1
+MemberOf _Measurement
+MemberOf _SubControlArea
1
0..n +Contains_Measurements
SubControl +Contain_Substations
Measurement
Substation
Area
(from Meas)
0..n
0..n
+Controls
+MeasuredBy _Measurement
+Measurements
(from Core)0..1
1..n
(from Core)
1
0..n
0..n
+Measurements
ConductingEquipment
PowerTransf ormer
(from Core)
(from Wires)
+Terminals
0..n
+Measurements
0..1
Terminal
1 +Unit
Unit
(from Core)
1
+Unit
+LimitSets
0..n
(from Core)
+LimitSet
LimitSet
(from Meas)
1
+Limits
0..n
Connector
Switch
Conductor
(from Wires)
(from Wires)
(from Wires)
+Contains_ACLineSegments[]
Limit
(from Meas)
BusbarSection
(from Wires)
ACLineSegment
(from Wires)
(from Wires)
58
Figura 14 - Modelo CIM reduzido para o protótipo.
Breaker
59
Classe CIM
Substation
SubControlArea
Terminal[3]
Objeto
SE
AreaControle
TerminalConexao
TerminalConexao[0]
TerminalConexao[1]
TerminalConexao[2]
Breaker[3]
Disjuntor
Disjuntor[0]
Disjuntor[1]
Disjuntor[2]
BusbarSection
Barra
Line
Linha
ACLineSegment[2]
Circuito
Circuito[0]
Circuito[1]
Control[3]
Controle
Controle[0]
Controle[1]
Controle[2]
Measurement[9]
Medida
Medida[0]
Medida[1]
Medida[2]
Medida[3]
Medida[4]
Medida[5]
Medida[6]
Medida[7]
Medida[8]
MeasurementValue[9] ValorMedida
ValorMedida[0]
ValorMedida[1]
ValorMedida[2]
ValorMedida[3]
ValorMedida[4]
ValorMedida[5]
ValorMedida[6]
ValorMedida[7]
ValorMedida[8]
LimitSet[1]
atributo.aliasName
"SE Araucaria"
"COE Campo Comprido"
"T_BARRA"
"T_CIRC_1"
"T_CIRC_2"
"Terminal Barramento"
"Terminal Circuito 1"
"Terminal Circuito 2"
"DJ_P"
"DJ_1"
"DJ_2"
"BP"
"LF"
"DJ Principal"
"DJ Circuito 1"
"DJ Circuito 2"
"Barra Principal"
"Linha Fonte"
"C1"
"C2"
"Circuito 1"
"Circuito 2"
"C_DJ_P"
"C_DJ_1"
"C_DJ_2"
"Controle Disjuntor Principal"
"Controle Disjuntor Circuito 1"
"Controle Disjuntor Circuito 2"
"M_VB"
"M_FB"
"M_I1"
"M_P1"
"M_I2"
"M_P2"
"M_DJ_P"
"M_DJ_1"
"M_DJ_2"
"Tensao barramento"
"Frequencia barramento"
"Corrente Circuito 1"
"Potencia Circuito 1"
"Corrente Circuito 2"
"Potencia Circuito 2"
"Estado DJ Principal"
"Estado DJ Circuito 1"
"Estado DJ Circuito 2"
10 < n(13.8) < 14
55 < n(60) < 65
0 < n(300) < 350
0 < n(4) < 4.8
0 < n(15) < 175
0 < n(2) < 2.4
"S_VB"
"S_FB"
"S_I1"
"S_P1"
"S_I2"
"S_P2"
"S_E_DJ_P"
"S_E_DJ_1"
"S_E_DJ_2"
"Sensor Tensao Barramento"
"Sensor Frequencia Barramento"
"Sensor Corrente Circuito 1"
"Sensor Potencia Circuito 1"
"Sensor Corrente Circuito 2"
"Sensor Potencia Circuito 2"
"Sensor Estado DJ Principal"
Sensor Estado DJ Circuito 1
"Sensor Estado DJ Circuito 2"
double; sensor satura +30% do normal
double; sensor satura +8,33% do normal
double; sensor satura +30% do normal
double; sensor satura +30% do normal
double; sensor satura +30% do normal
double; sensor satura +30% do normal
boolean; registro de timestamp
boolean; registro de timestamp
boolean; registro de timestamp
Modelado apenas limites para a medida
M_VB
"CJ_LIM_N_VB"
"Conjunto de Limites Normais da
VB"
CjtoLimitesVB
CjtoLimitesVB[0]
Limit[2]
atributo.name
"ARC"
"COE_CCO"
Outros atributos
apenas um conjunto de limites normais
LimiteNormal
Unit[5]
ValueAliasSet[1]
LimiteNormal[0]
"LIM_N_VB_SUP"
LimiteNormal[1]
Unidade
Unidade[0]
Unidade[1]
Unidade[2]
Unidade[3]
Unidade[4]
DicionarioValores
"LIM_N_VB_INF"
Verbete
Verbete[0]
Verbete[1]
definido com o valor 14
definido com o valor 13
"kV"
"Hz"
"MW"
"A"
"DIGITAL"
Para o prototipo, há apenas um
dicionario de valores para associar em
todas as medidas / controles necessários
DicionarioValores[0]
ValueToAlias[2]
"Limite Superior VB para
ALarme"
"Limite Inferior VB para ALarme"
"ABERTO"
"FECHADO"
booleano definido como falso
booleano definido como verdadeiro
Tabela 2 - Objetos CIM para subestação do protótipo.
A Figura 15 identifica no diagrama unifilar da subestação os elementos que
foram modelados em objetos CIM. Os retângulos representam os objetos dos
60
sensores. São os sensores que fornecem ao sistema o valor das medidas
analógicas e digitais. As setas identificam as associações entre os objetos, conforme
o diagrama de classes do CIM apresentado na Figura 14.
COE_CCO
LF
ARC
S_E_DJ_P
LIM_N_VB_SUP
S_FB
M_DJ_P
C_DJ_P
S_VB
CJ_LIM_N_VB
LIM_N_VB_INF
DJ_P
S_E_DJ_1
M_VB
M_FB
S_E_DJ_2
T_BARRA
M_DJ_1
M_DJ_2
BP
DJ_1
DJ_2
C_DJ_1
C_DJ_2
T_CIRC_1
C1
T_CIRC_2
C2
M_I1
M_P1
M_I2
M_P2
S_I1
S_P1
S_I2
S_P2
Figura 15 – Identificação dos objetos CIM sobre o unifilar.
As seguintes associações foram realizadas:
•
A medida de tensão no barramento M_VB se associa com um conjunto
de limites CJ_LIM_N_VB. Este conjunto contém dois objetos de limites
identificados na geração de alarmes para ultrapassagem de nível alto e
nível baixo;
•
Os disjuntores DJ_P, DJ_1, DJ_2 se associam respectivamente com as
medidas M_DJ_P, M_DJ_1, M_DJ_2;
•
As medidas M_DJ_P, M_DJ_1, M_DJ_2 se associam com os
respectivos controles C_DJ_P, C_DJ_1, C_DJ_2;
61
•
As medidas M_DJ_P, M_DJ_1, M_DJ_2 se associam com seus
respectivos sensores S_E_DJ_P, S_E_DJ_1, S_E_DJ_2;
•
Todos os sensores se associam com as suas respectivas medidas;
•
A barra BP se associa ao terminal T_BARRA;
•
O terminal de conexão T_BARRA se associa com as medidas M_VB e
M_FB;
•
As medidas M_VB e M_FB se associam com seus respectivos
sensores S_VB e S_FB;
•
Os circuitos C1 e C2 se associam aos respectivos terminais de conexão
T_CIRC_1 e T_CIRC_2;
•
O terminal T_CIRC_1 se associa com as medidas M_I1 e M_P1 e estas
aos seus sensores S_I1 e S_P1;
•
O terminal T_CIRC_2 se associa com as medidas M_I2 e M_P2 e estas
aos seus sensores S_I2 e S_P2;
•
Todas as medidas se associam obrigatoriamente com um objeto de
identificação da unidade de grandeza sendo medida;
•
Todos os controles se associam a uma unidade também;
•
As medidas digitais M_DJ_P, M_DJ_1, M_DJ_2 se associam a um
dicionário de valores para identificar o que significa cada estado digital;
Exemplo: Para uma medida digital, os estados verdadeiro/falso
significam abertura/fechamento do equipamento, respectivamente. Para
outra medida, os mesmos estados significam operação normal/falha.
•
Os controles digitais C_DJ_P, C_DJ_1, C_DJ_2 também se associam
ao mesmo dicionário de valores;
Por enquanto, não há associação de linhas com elementos da subestação
e nem de modelagem do transformador.
O terminal (terminal de conexão) serve como ponto de junção entre um
barramento ou circuito e seus respectivos pontos de medição de valores.
62
O breaker (disjuntor) é um equipamento do sistema elétrico (derivado da
classe PowerSystemResource) para efetuar comando e para ler medidas digitais.
As atualizações a seguir foram necessárias para adaptar as classes do
modelo CIM à ontologia do JADE:
•
Core.Naming
o
Implementação da interface jade.content.Concept. Para que uma
classe do modelo possa ser mapeada num esquema de ontologia
do JADE como um conceito, ela precisa implementar esta
interface. Para facilitar, a implementação foi feita uma única vez
diretamente na superclasse do CIM para objetos que utilizam
atributos de nome;
o
Inclusão dos métodos setters/getters para acesso aos atributos.
Conforme
documentação
do
JADE
[JadeOnto04],
classes
ontológicas (classes associadas a um esquema de ontologia por
reflexão) devem fornecer esses métodos de acesso a atributos.
•
Domain.Numeric
o
Implementação da interface jade.content.Concept. Pelo mesmo
motivo usado nas classes nomeadas, a classe que define um tipo
numérico de dado também será usada como um conceito na
ontologia do protótipo;
o
Implementação dos setter/getters para os atributos. Classes
ontológicas devem implementar métodos de acesso padronizados
para seus atributos;
o
Inicialização dos atributos atualmente utilizados (INT_TYPE = 0,
DOUBLE_TYPE = 0, BOOLEAN_TYPE = false).
•
Meas.MeasurementValue
o
Implementação dos setter/getters para os atributos.
63
As
classes
abaixo
foram
removidas
do
modelo
por
possuírem
correspondentes na linguagem Java:
•
Domain.Boolean;
•
Domain.Integer;
•
Domain.Double;
•
Domain.Short.
5.5 TESTES COM ONTOLOGIA
As mensagens trocadas entre os agentes do protótipo devem registrar qual
a ontologia usada para identificação dos objetos (ver seção 3.5). A ontologia deve
ser gerada no JADE por uma classe que estenda jade.content.onto.Ontology. Essa
classe deve definir as constantes que compõem o vocabulário da ontologia, os
esquemas de identificação dos predicados, ações e conceitos e as classes Java
associadas (ver seção 3.7).
No primeiro contato com os exemplos existentes na documentação do
JADE para a criação de classes ontológicas, percebeu-se que este trabalho seria
árduo. Com isso em mente, foi otimizada a modelagem do que seria estritamente
necessário do CIM para a troca de dados, reduzindo-se a ontologia para a
implementação dos conceitos relacionados aos objetos Meas.MeasurementValue e
Domain.NUMERIC e do predicado MedidasExistentes.
O predicado passa uma lista de conceitos MeasurementValue, tendo os
atributos name preenchidos com as strings de identificação única do objeto CIM
modelado. Em resposta à mensagem QUERY-REF contendo o predicado
MedidasExistentes, é processada uma mensagem INFORM contendo os mesmos
conceitos interrogados, mas com os atributos value preenchidos com o valor da
medida
solicitada.
Com
esta
“mini-ontologia
CIM”,
denominada
OntologiaAutomacao, os agentes ficam aptos a mandar e receber as medidas
64
modeladas para a subestação.
A modelagem e construção da classe ontológica foram feitas na ferramenta
Protégé. A tela principal da OntologiaAutomacao feita na ferramenta é apresentada
na Figura 16.
Figura 16 - Protégé: mini-ontologia CIM.
Após a modelagem, aplica-se o plugin BeanGenerator (aba da direita vista
na tela da ferramenta Protégé) para a geração das classes em Java/JADE da
ontologia, esquema de predicado e esquema de conceitos. O processo de geração
exige apenas que se informe o local para geração, o pacote e o domínio das
classes. Uma vez acionado o plugin, é só inserir as classes no projeto e registrar a
ontologia no agente que gerencia o conteúdo do container JADE e nas mensagens
ACL.
65
5.6 AGENTES IMPLEMENTADOS
Conforme analisado na seção 3.3, há diversas formas de classificar e
utilizar os agentes de um sistema distribuído. O estágio atual do protótipo ainda não
implementa
nenhum
tipo
complexo,
contendo
apenas
agentes
simples,
desempenhando tarefas que não requerem inteligência. São meros coletores de
dados, mas que servem como uma primeira avaliação da tecnologia.
Por enquanto, foram construídos três tipos de agentes no protótipo:
•
COVx: agente global que gerencia um Centro de Operação Virtual de
número x;
•
SEn: agente local em uma subestação n que troca informações com o
simulador;
•
SEnProxy: agente local móvel que é criado pelo COVx após a
autenticação de um agente SEn e que migra para um container de
agentes Webcontainer. Troca dados com a servlet mantida para a
sessão do usuário e com o agente SEn respectivo.
Os locais (containers) onde os agentes residem são:
•
Main-Container: localizado no servidor de aplicação, hospeda o agente
COVx;
•
Webcontainer: localizado no servidor Web, é responsável por receber
agentes SEnProxy vindos do Main-Container;
•
Container-N: localizado na SE de número N, abriga o agente SEn.
Além dos agentes, são necessárias as classes:
•
OntologiaAutomação: contém a ontologia com base no CIM reduzido,
implementada como esquemas do JADE;
•
Servlet: lança o container Webcontainer e aguarda os dados
recebidos pelo agente SEnProxy;
•
Subestação: simulador de dados que fica aguardando mensagens do
66
JADE e gerando eventos para a fila.
A Figura 17 é uma tela capturada da ferramenta de interface gráfica para
controle da plataforma JADE, RMA (Remote Agent Management). Nela, pode-se
identificar a existência dos três containers e dos três agentes mencionados.
Percebe-se, ainda, a existência dos agentes ams e df no Main-Container, conforme
explicado na seção 3.5.
Figura 17 - Gerenciamento gráfico dos agentes do protótipo no JADE.
Com a ferramenta RMA, pode-se disparar as demais ferramentas que
acompanham o JADE (seção 3.6). Uma delas é um agente de escuta das
mensagens ACL, chamado Sniffer, mostrando o texto na linguagem SL0. Como
exemplo, a Figura 18 mostra a captura do conteúdo de uma mensagem com
propósito INFORM feita do agente SE1 para o agente SE1Proxy, passando a lista
de valores dos objetos MeasurementValue do modelo CIM associados com o
terminal T_BARRA, esquematizados na ontologia, e pedidos em uma mensagem
anterior (com propósito QUERY-REF).
67
((MedidasExistentes
(sequence (MeasurementValue :name S_VB
:value (NUMERIC :BOOLEAN_TYPE false
:INT_TYPE 0
:DOUBLE_TYPE 14.277346612698063))
(MeasurementValue :name S_FB
:value (NUMERIC :BOOLEAN_TYPE false
:INT_TYPE 0
:DOUBLE_TYPE 61.71474778014864)))))
Figura 18 - Sniffer: captura de mensagem ACL/SL0.
5.7 INTERAÇÃO ENTRE AGENTES E APRESENTAÇÃO
Para que o protótipo funcione conforme explicado na seção 5.5, com os
três containers do JADE e seus respectivos agentes, deve-se seguir os seguintes
passos:
•
Executar o JADE e carregar o agente COV1. O JADE se encarrega de
gerar o Main-Container automaticamente;
•
Lançar o servidor Tomcat com lançamento automático da servlet que
cria o Webcontainer;
•
Executar outra instância do JADE e carregar o agente SE1. O JADE se
encarrega de gerar o Container-1 automaticamente.
Quando o agente COV1 recebe a mensagem do agente SE1 com o
propósito CFP (Call for Proposal), ele sabe que está começando um protocolo de
conversação FIPA-ContractNet e aceita entrar na disputa pelo controle da
subestação, caso haja outros agentes do tipo COV na conversa. Assim que a
negociação termina, o COV1 passa a supervisionar a subestação e gera o agente
SE1Proxy para trocar os dados entre o agente SE1 e o servidor Tomcat, sendo
movido na seqüência para o Webcontainer.
A atualização dos dados na servlet ocorre de duas maneiras. A primeira, é
por um comportamento cíclico do agente SE1Proxy que envia uma mensagem com
propósito QUERY_REF para pesquisar os valores das medidas analógicas
68
existentes. O agente SE1 na subestação responde com os dados por uma
mensagem de propósito INFORM. A segunda maneira é por um comportamento
também cíclico do agente SE1 que manda uma mensagem INFORM para o
SE1Proxy, passando os valores dos conceitos MeasurementValue correspondente
às medidas digitais. Desta forma, os valores analógicos são perguntados para a
subestação mas as mudanças de valores digitais são enviadas sem pergunta prévia.
No componente de interface foi utilizada a combinação das tecnologias
Java Servlet , JSP, SVG e AJAX. Um servlet é uma classe Java, assim, é possível a
utilização de todos os recursos dessa linguagem para implementar o processamento
de uma requisição HTTP. A tecnologia JSP pode ser então utilizada no que ela faz
de melhor: controle de layout da página com inclusão de conteúdo dinâmico. A
combinação
das
tecnologias
forma
uma
ferramenta
poderosa
para
o
desenvolvimento de aplicações bem estruturadas e de fácil manutenção [Gomes03].
A interface do protótipo permite visualizar o diagrama unifilar no qual
aparecem as medidas existentes para a subestação. A instalação consiste apenas
de um navegador com suporte a SVG e AJAX. Para exemplificar, foi capturada uma
página HTML que representa a IHM do operador em um centro de controle (Figura
19). O diagrama está em SVG e os valores analógicos são atualizados por AJAX. A
representação dos estados dos disjuntores também ocorre por AJAX e é feita pela
mudança de cor dos símbolos retangulares destes equipamentos.
69
Figura 19 - Tela de operação do protótipo.
70
6
CONCLUSÕES
As empresas do setor de energia devem estar preparadas para um futuro
em que o ritmo de introdução de novas tecnologias é crescente. A supervisão tende
a não ficar baseada apenas em dados de baixo nível mas em informações de alto
nível sintetizadas automaticamente. Sistemas que contemplam interoperabilidade de
aplicações e que se preparam para incorporar inovações através de evolução sem
traumas tendem a reduzir custos e manter a motivação da empresa.
A modernização do sistema de automação da concessionária de energia
elétrica do estado do Paraná mantém-se alerta para a prospecção de tecnologias
emergentes que levem a empresa a um alto grau de sintonia com outros agentes do
sistema elétrico. Sistemas distribuídos com utilização da tecnologia de agentes são
largamente investigados na literatura científica. A adequação das tecnologias Java
na construção de um sistema distribuído moderno de automação passa a ser um
foco de interessante da área de desenvolvimento.
Os estudos de especificações voltadas para a criação de padrões
concretos de comunicação entre agentes abertos e interoperáveis fornecidas por
uma fundação internacional exclusiva para esse fim, a FIPA, e da plataforma JADE
para execução e desenvolvimento de agentes em Java mostram a evolução
existente da tecnologia. A plataforma JADE implementa diversas características que
facilitam a construção de um sistema distribuído. Sua aderência ao padrão FIPA
garante compatibilidade com outras plataformas de agentes. O produto ainda não foi
testado em seus aspectos de segurança e desempenho perante um ambiente de
testes severo, necessário para um sistema de missão-crítica.
A modelagem de dados CIM para a concessionária permite a concepção
de uma arquitetura baseada em padrões abertos envolvendo outros sistemas da
empresa. Novamente, a consciência de padrões internacionais utilizados no domínio
de conhecimento específico da área elétrica pode gerar benefícios para a integração
71
de sistemas.
O protótipo construído se preocupou em disponibilizar uma estrutura base
que possa servir de apoio a estudos mais aprofundados.
Por tudo o que se estudou neste trabalho, comprova-se que a tecnologia
abordada tem um potencial muito grande para compor uma operação eficiente e
eficaz do sistema elétrico paranaense.
6.1 TRABALHOS FUTUROS
Uma proposta de continuação do trabalho é o aprofundamento do estudo
de desempenho da tecnologia de agentes JADE para disponibilizar dados em
velocidade compatível com a criticidade do processo controlado. No caso de
processos elétricos considera-se, a grosso modo, o tempo de resposta de alguns
poucos segundos entre o acontecimento de um evento físico e sua entrada nos
algoritmos de funções elétricas automatizadas ou de sua apresentação ao operador
do sistema. Os sistemas de tempo real para a área elétrica também devem ter
capacidade de armazenar e processar seqüências de eventos (SOE – Sequence of
Events) devidamente discriminadas no tempo com resolução de um milissegundo.
O aperfeiçoamento do protótipo leva ao trabalho de: conversação com o
sistema SCADA existente; utilização das demais classes do modelo CIM, aplicandoas também na ontologia; uso de fila de mensagens para geração de alarmes; estudo
de criptografia e autenticação da plataforma e; construção de agentes inteligentes
para funções elétricas e configuração dinâmica. Interação entre a plataforma de
agentes e o mundo externo por Web, IIOP e JMS pode ser explorada no JADE
visando sempre o aumento do grau de integração corporativa.
O aprimoramento da questão de comunicação semântica, com a criação de
uma ontologia pesada, pode ser um fator contributivo quando se pensa em um
barramento de integração das principais aplicações da empresa. A possibilidade de
72
efetuar carregamento dinâmico da ontologia também pode ser explorada num futuro
próximo.
A adoção de outros padrões, como a interface de componentes IEC 61970401, deve ser estuda para levantamento de incompatibilidades com o uso da
tecnologia de agentes.
O desenvolvimento da interface também passa por validação da tecnologia
pelos operadores do atual sistema. A busca por maior grau de facilidades para
desenvolvimento e edição de unifilares deve ser considerada numa visão mais
ampla das necessidades do futuro sistema de automação.
Estudos sobre Tolerância a Faltas (TOF) também estão sendo feitos.
Falhas dos processos componentes do sistema deverão ser mascaradas de maneira
que o mesmo não dependa da confiabilidade de apenas um processo. Em
[Schultz06] são tratadas técnicas de TOF em sistemas distribuídos que podem ser
empregadas pela equipe de desenvolvimento de software da COPEL com aplicação
em um banco de dados de configuração e históricos.
Um exame das diversas possibilidades de surgimento ou desaparecimento
de centros, subestações ou operadores deve ser feito para uma modelagem de
negociação mais apurada. A distribuição de subestações para os operadores dos
centros deve considerar fatores como posição geoelétrica da subestação,
sobrecarga do centro, manobras em curso e manutenção de equipamentos.
73
REFERÊNCIAS
[ABNT06] ABNT - Associação Brasileira de Normas Técnicas; 04 julho 2006,
http://www.abnt.org.br.
[AdobeSVG06] Adobe SVG Viewer; 23 outubro 2006, http://www.adobe.com/svg.
[ANEEL06] ANEEL - Agencia Nacional de Energia Elétrica; 03 novembro 2006,
http://www.aneel.gov.br.
[ANSI06] ANSI - American
http://www.ansi.org.
National
Standards
Institute;
06
novembro
2006,
[Antoniou03] Antoniou, G.; van Harmelen, F. Web Ontology Language: OWL, Handbook on
Ontologies in Information Systems, 2003.
[Arpírez01] Arpírez, J. C.; Corcho, O.; Fernández-Lóopez, M.; Gómez-Pérez, A. WebODE: a
scalable ontological engineering workbench, First International Conference on
Knowledge Capture (KCAP'01), ACM Press, 2001.
[Azevedo99] Azevedo, Gilberto Pires de; Feijó, Bruno; Costa, Mônica A Estrutura da
Próxima Geração de Centros de Controle de Energia Elétrica, XV SNPTEE, 1999.
[Azevedo00] Azevedo, Gilberto P.; Feijó, Bruno; Costa, Mônica Control Centers Evolve with
Agent Technology, IEEE Computer Applications in Power, 2000.
[Bean06]
Ontology
Bean
Generator
for
Jade;
11
novembro
2006,
http://hcs.science.uva.nl/usr/aart/beangenerator/index25.html, http://protege.cim3.net.
[Bechhofer01] Bechhofer, S.; Horrocks, I.; Goble, C.; Stevens, R. OilEd: a Reason-able
Ontology Editor for the Semantic Web, In: Proceedings of 14th International Workshop on
Description Logics, Stanford, USA, August, 2001.
[Bellifemine99] Bellifemine, Fabio; Poggi, A.; Rimassa, Giovanni JADE: A FIPA-Compliant
agent framework, In: Practical Applications of Intelligent Agents and Multi-Agents,
1999.
[Buse03] Buse, D. P.; Sun, P.; Wu, Q. H., Fitch, J. Agent-Based Substation Automation, Proc.
IEEE Power & Energy, Vol 1, No 2, March/April 2003, pp. 50-55.
[CIM06]
CIM
–
Common
Information
http://www.cimusers.org/Model/CIM/root.html.
Model;
13
novembro
2006,
[COPEL06] COPEL – Companhia Paranaense de Energia; 14 novembro 2006,
http://www.copel.com.
[Dometerco06] Dometerco, J. H. Uma arquitetura baseada em agentes e interface web para
sistemas de automação de subestações de energia elétrica, Monografia de
Especialização, Curitiba, UTFPR, dezembro 2006.
[Domingue98] Domingue, J. Tadzebao and WebOnto: Discussing, Browsing and Editing
Ontologies on the Web, 11th International Workshop on Knowledge Management
Support, IEEE Intelligent Systems & their applications, Vol.15(3):26-32, 1998.
74
[Eclipse06] The Eclipse Foundation, 15 novembro 2006, http://www.eclipse.org.
[ENGTRA05] COPEL - Apresentação interna da área de engenharia de transmissão;
Curitiba, outubro 2005.
[Farquhar97] Farquhar, A.; Fikes, R.; Rice, J. The Ontolingua Server: A Tool for
Collaborative Ontology Construction, International Journal of Human Computer Studies,
Vol.46(6):707-727, 1997.
[FIPA06] FIPA - Foundation for Intelligent Physical Agents; Specifications Repository, 16
novembro 2006, http://www.fipa.org/specs/pesspecs.tar.gz.
[FipaOS03] FIPA - Open Source; 2001, Nortel Networks Corporation; 2003, Emorphia Ltd;
19
novembro
2006,
http://fipa-os.sourgeforge.net;
19
novembro
2006,
http://sourceforge.net/project/showfiles.php?group_id=3819 (última versão: FIPA-OS
2.2.0 de 18/03/2003).
[Geus06] Geus, K. de et al A distributed model for electrical substation automation based on
multi-agents technology, CIMCA'2006 and IAWTIC'2006, IEEE, novembro 2006.
[Gluz02] Gluz, João Carlos Linguagens de Comunicação entre Agentes: Fundamentos e
Propostas de Padronização, Trabalho Individual de Doutorado, Canoas, UFRGS, 2002.
[Gomes03] Gomes, Eduardo Rodrigues; Silveira, Ricardo Azambuja; Vicari, Rosa Utilização
de agentes FIPA em ambientes para Ensino a Distância, Trabalho apresentado no
CLEI2003, 2003.
[Gomes05] Gomes, Eduardo Rodrigues Objetos Inteligentes de Aprendizagem: uma
abordagem baseada em agentes para objetos de aprendizagem, Dissertação de Mestrado,
Porto Alegre, UFRGS, junho 2005.
[Gruber93] Gruber, T. R. A Translation Approach to Portable Ontology Specification,
Knowledge Acquisition 5, 1993.
[Heck03] Heck; Wills; Vachtsevanos Software Technology for Implementing Reusable,
Distributed Control Systems, Control Systems Magazine, IEEE, 2003.
[Hughes04] Hughes, Joe The Integrated Energy and Communication Systems Architecture,
Volume IV: Technical Analysis, EPRI, 2004.
[IE06] Microsoft Internet Explorer; 20 novembro 2006, http://www.microsoft.com.
[IEC06] IEC - International
http://www.iec.ch.
Electrotechnical
Commission;
22
novembro
2006,
[Jade06] Java Agent DEvelopment Framework; 23 novembro 2006, http://jade.tilab.com.
[JadeAdm05] Bellifemine, Fabio; Caire, Giovanni; Trucco, Tiziana; Rimassa, Giovanni JADE
Administrator’s Guide, JADE 3.4, 2006; 24 novembro 2006, http://jade.cselt.it.
[JadeOnto04] Caire, Giovanni; Cabanillas, David JADE Tutorial: Application-defined
Content Languages and Ontologies, JADE 2.6, 2004; 26 novembro 2006,
http://jade.cselt.it.
75
[JadePrg05] Bellifemine, Fabio; Caire, Giovanni, Trucco, Tiziana; Rimassa, Giovanni JADE
Programmer’s Guide, JADE 3.3, 2005; 27 novembro 2006, http://jade.cselt.it.
[Java06] JavaTM 2 Platform Standard Edition Development Kit 5.0; 28 novembro 2006,
http://java.sun.com.
[Jennings98] Jennings, N.; Sycara, K. e Wooldrige, M. A Roadmap of Agent Research and
Development, Autonomous Agents and Multi-Agent Sytems, Vol. 1, pp. 7-38, 1998.
[McGuinness04] McGuinness, D.; van Harmelen, F. OWL Web Ontology Language
Overview,
W3C
Recommendation,
2004;
29
novembro
2006,
http://www.w3.org/TR/owl-features.
[Malucelli06] Malucelli, Andreia Ontology-based Services for Agent Interoperability, Tese de
Doutorado, University of Porto, 2006.
[Noy00] Noy, N. F.; Fergerson, R. W.; Musen, M. A. The knowledge model of Protégé-2000:
Combining interoperability and exibility, Knowledge Engineering and Knowledge
Management. Methods, Models, and Tools: 12th International Conference, LNCS, 2000.
[Nwana99] Nwana, H. et al ZEUS: a toolkit for building distributed multi-agent systems, In:
Artifical Intelligence Journal, 1999.
[ONS06] ONS - Operador Nacional do Sistema Elétrico; 30 novembro 2006,
http://www.ons.org.br.
[Pereira95] Pereira, Luiz A.C. Pereira et al SAGE - Um Sistema Aberto para a Evolução,
Eletroevolução: sistema de potência, CIGRE, 1995.
[Prates05] Prates, Petronio Spyer Integração de Sistemas no Ambiente Corporativo Baseado
em Padrões, VI SIMPASE, 2005.
[Prayurachatuporn01] Prayurachatuporn, S; Benedicenti, L. Increasing the reliability of
control systems with agen technology, ACM SIGAPP Applied Computing Review, v. 9,
n. 2, Jul. 2001.
[Protege06]
Protégé,
Stanford
http://protege.stanford.edu.
Medical
Informatics;
01
dezembro
2006,
[QIU02] B. Qiu, H. B. Gooi, Y. Liu, E. K. Chan Internet-based SCADA display system, IEEE
Computer Applications in Power, January, 2002, Pp. 14-19.
[QNX] QNX Software Systems; 03 dezembro 2006, http://www.qnx.com.
[Rational06] IBM-Rational; 04 dezembro 2006, http://www.rational.com.
[Schultz06] Schultz, R. Aplicação de Técnicas de Tolerância a Faltas em Sistemas
Distribuídos na Comunicação dos Processos de um Sistema de Automação do Sistema
Elétrico, Curitiba, Monografia de Especialização, PUC-PR, 2006.
[Shono02] Shono, T. et al A Remote Supervisory System for a Power System Protection and
Control Unit Applying Mobile Agent Technology, In: Transmission and Distribution
Conference and Exhibition 2002, IEEE/PES, 2002.
76
[Silva04] Silva, Paulo Sérgio da Uma abordagem para incorporar mecanismos de
inteligência artificial a agentes móveis, Tese de Doutorado, Universidade Estadual de
Campinas, novembro 2004.
[Sure02] Sure, Y.; Erdmann, M.; Angele, J.; Staab, S.; Studer, R.; Wenke, D. OntoEdit:
Collaborative Ontology Engineering for the Semantic Web, First International Semantic
Web Conference (ISWC'02), 2002.
[Tomcat06] The Apache Jakarta Tomcat Servlet/JSP Container; 05 dezembro 2006,
http://jakarta.apache.org.
[Uschold96] Uschold, M.; Grüninger, M. Ontologies: Pinciples, Methods and Applications,
Knowledge Engineering Review, 1996.
[Uslar05] Uslar, Mathias Semantic Interoperability within the Power Systems Domain,
IHIS’05, novembro 2005, ACM.
[Vergara02] Vergara, Jorge E. López de; Villagrá, Víctor A.; Berrocal, Julio Semantic
Management: advantages of using na ontology-based management information metamodel, HPOVUA-2002 workshop, 2002.
[Vrba03] Vrba, Pavel JAVA-Based Agent Platform Evaluation, LNAI 2744, 2003.
[Vos01] Vos, A. de; Widergren, S.E.; Zhu, J. XML for CIM Model Exchange, IEEE, 2001.
[Waldo01] Waldo, J. Mobile Code, Distributed Computing, and Agents, IEEE Intelligent
Systems, March/April, 2001, p.10- 12.
[Wong99] Wong, D.; Paciorek, N.; Moore, D. Java-based Mobile Agents, Communications of
the ACM, v. 2, n. 3, p. 92-102, March, 1999.