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
i
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
ii
Aos colegas da automação e do projeto de P&D.
iii
AGRADECIMENTOS
A todos que direta ou indiretamente auxiliaram na realização do trabalho.
iv
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
v
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
vi
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
vii
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
viii
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.
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
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
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.
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 iniciou- se 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é
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
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.
Figura 1 - Esquema hierárquico - inserção da COPEL no sistema elétrico nacional.
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)
Centros de Controle ---
Demais regiões
Centros de Operação --- Outras concessionárias
(Sul)
9 COEs ---
Centro de Operação de Estações da Engenharia
de Transmissão
5 CODs ---
Centro de Operação da Engenharia de
Distribuição
Subestações da Transmissão (128):
-subdivididas entre os COEs por região, -total de 6 regiões,
-totalmente automatizadas, sem presença humana.
Automação da Distribuição:
-subdivididas entre os CODs em 5 regiões,
-automatizadas, mas necessitando de presença humana.
Centros de Operação da Geração COPEL ---
COPEL (Curitiba)
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.
Figura 2 - Mapa do sistema elétrico do Paraná [ENGTRA05].
Região de Maringá
Região de Cascavel
Região de Londrina
Região de Ponta Grossa Região de
Pato Branco
Região de Curitiba
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
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;
• 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.
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 das tecnologias computacionais e tendências para padronização possibilitam o estabelecimento de novas diretrizes 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;
• 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 mestre- escravo. 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ára-
raios 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;
• 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,
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;
• 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
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.
Tabela 1 - Tipos de agentes em um sistema de automação de subestações [Buse03]
Tipo de Agente Tarefa Habilidade Sensores Conhecimento
Usuário Comando, pesquisa, suporte a decisão
Visualização de informações, Disparar pesquisa
Interface gráfica ou outra interface do usuário
Modelo do usuário
Banco de dados Transferência de dados, aquisição de dados, pesquisa
Adicionar informações ao banco, responder pesquisas
Metadados do banco
Dispositivo Controle Sinais recebidos do
equipamento
Modelo do sistema sob 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
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
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.
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
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
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
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
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 (intra- plataforma), 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
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.
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.
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].
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-Main- Container [JadeAdm05]. A Figura 6 exemplifica uma plataforma JADE em execução com dupla redundância do container principal.
Figura 6 - Exemplo de uma plataforma distribuída JADE com tolerância a faltas.
Plataforma Distribuída JADE
Container-1
Main-Container-2
(Master) Main-Container-1
Main-Container-N Container-2
Container-M A
A
A A
A A
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;
• É 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
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.
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.
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
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
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.
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
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
