7/31/2019 CBA2004-Eletro

1/6

SISTEMA DE INTEGRAO DE TECNOLOGIAS DE AGREGAO DE MEDIO

E.F.V. E SILVA1,J.CB.LEITE1,O.G.LOQUES1,A.CORRADI1,P.R. DOS SANTOS2 E N.RIZZI JUNIOR2

1Instituto de Computao

Universidade Federal Fluminense (UFF)

Rua Passo da Ptria, 156 - Bloco E - CEP 24.210-240Niteri - Rio de Janeiro - Brasil

2AES Eletropaulo

Rua do Lavaps, 463, CEP 01519-000

So Paulo - So Paulo - Brasil

E-mails: {efontana, julius, loques, acorradi}@ic.uff.br e {paulo.roberto,

nelson.rizzi}@aes.com

Abstract.This paper presents a proposal for integration of heterogeneous devices in the context of Electronic Meters of ElectricEnergy. With an approach based in the construction of models that describe the domain of the measurement problem, we showthe possibility of integrating different models of meters in one configuration and metering system. The developed prototype hasvalidated the techniques and methodology employed.

Keywords Heterogeneous systems, electric energy meters, interoperability.

Resumo. Esse artigo apresenta uma proposta para integrao de sistemas heterogneos no contexto de Medidores de EnergiaEltrica Eletrnicos. Com uma abordagem centrada na construo de modelos que descrevem o domnio do problema de medio,mostramos a possibilidade de se integrar diferentes tipos de medidores em um s sistema de configurao e leitura. O prottipodesenvolvido validou as tcnicas e a modelagem empregadas.

Palavras-chave Sistemas heterogneos, medidores de energia eltrica, interoperabilidade.

1 Introduo

O suporte s atividades de uma empresa requer acolaborao entre os sistemas de computao que elapossui para compartilhar informaes e processosdisponveis nesses sistemas. Assim, diversasorganizaes tm unido esforos no sentido deestabelecer padres, arquiteturas e formatos derepresentao de dados que permitam ainteroperabilidade entre os sistemas de uma empresae mesmo entre empresas. No mbito das Empresas deEnergia Eltrica surgiram vrias propostas nessesentido. A UCA (Utility CommunicationsArchitecture), desenvolvida pelo EPRI (ElectricPower Research Institute), uma proposta dearquitetura que tem como objetivo estabelecerpadres para integrao das diversas reas funcionaisdentro das empresas do setor (UCA, 1997). Emparticular, o modelo GOMSFE (Generic ObjectModel Substations & Feeder Equipment) (UCA,2000) define os blocos de construo bsicos para acomposio de modelos lgicos de dispositivos.Outra proposta a DLMS/COSEM (DeviceLanguage Message Specification / CompanionSpecification for Energy Metering) (DLMS, 2002)que uma iniciativa de um grupo de empresaseuropias e visa especificar um medidor de energiainteropervel, que possa ser utilizado em rede,atravs de diferentes formas de comunicao.

Alguns pontos em comum podem serobservados entre as diversas iniciativas. Um deles que cada vez mais a integrao de sistemasheterogneos est sendo tratada como uma questode entendimento entre esses sistemas. Assim, aspropostas conduzem a uma abordagem que privilegiao entendimento da informao sendo compartilhada,

atravs da utilizao de modelos lgicos deinformao. Essa abordagem chamada deIntegrao Semntica ou Integrao Baseada emModelos (Reynoso, 2003).

Um outro ponto tem sido a incorporao deconceitos do paradigma de software conhecido comoOrientao a Objetos. Essa tecnologia permite aconstruo de modelos de dispositivos a partir dacomposio de blocos funcionais bsicos.

Atualmente, no que diz respeito rea demedio de energia, constata-se que diferentes tiposde medidores, com diferentes concepes do domniodo problema, precisam de softwares distintos eproprietrios para ler e alterar os dados em cada umdeles. Esse um problema que as empresas dedistribuio, como a Eletropaulo, com um grandeconjunto de medidores instalados, enfrentam.

O objetivo deste trabalho apresentar umsistema de integrao de tecnologias que permitetratar os diversos tipos de medidores de energia jexistentes e que extensvel aos futuros medidores.A estratgia para atingir este objetivo foi a definiode um medidor genrico que pode representar,atravs de alguma especializao, os medidores jexistentes. Deste modo, neste trabalho apresentadoum modelo (lgico) genrico de medidor,configurvel e expansvel, capaz de integrar adefinio de diversos tipos de medidores especficos.

Uma tecnologia que vem se estabelecendo emmuitas reas da computao a XML (eXtensibleMarkup Language) (W3C, 1998). A XML surgiucomo promessa e de fato vem se tornando umaferramenta importante e amplamente usada naintegrao de sistemas. A tecnologia centrada emuma linguagem que permite a representao de dadosde forma estruturada e em formato texto, que facilita,

7/31/2019 CBA2004-Eletro

2/6

entre outras coisas, especificar a semntica dessesdados. Toda a modelagem empregada nesse trabalhofoi feita utilizando tecnologias relacionadas XML.

Uma tendncia que vem mundialmente seconfigurando a utilizao dos protocolos da Internet(e mesmo essa prpria rede) para o acesso aosequipamentos de medio e demais dispositivoseletrnicos inteligentes. Com a proposta de umaarquitetura baseada na Internet para construo de

um sistema de integrao, a questo da segurana dosdados tornou-se uma preocupao adicional nodesenvolvimento deste trabalho. Assim, diversosnveis de segurana foram incorporados ao sistemade integrao aqui descrito.

No restante do trabalho ser feita umaapresentao da modelagem utilizada (seo 2),seguida de uma introduo ao esquema de classesempregado (seo 3) e da descrio de um medidorde energia com base nessas classes (seo 4). Umabreve descrio da arquitetura do sistema deintegrao feita na seo 5, e as caractersticas desegurana so descritas na seo 6. As conclusesso apresentadas na seqncia.

2 Fundamentos da Modelagem Empregada

A modelagem utilizada baseada no conceito deOrientao a Objetos. O uso desta abordagempermite a especificao de classes e objetos quedefinem, de forma abstrata, a semntica das funesde um medidor genrico.

Nesse sentido, o objetivo principal definirblocos bsicos de construo (componentes)reutilizveis a serem empregados na especificao demodelos de medidores especficos de diferentesfabricantes. Um conceito fundamental da Orientaoa Objetos o de herana, que permite expressarsemelhanas entre classes na estrutura do domnio doproblema. Isto permite a definio de novas classesbaseadas em classes j definidas. Com a aplicaodesse conceito, as funes e atributos comuns de ummedidor genrico so definidos uma nica vez, emuma classe abstrata. Desta forma, medidoresespecficos de cada fabricante podem ser obtidoscomo especializaes ou implementaes dessaclasse. Instncias correspondentes aos dispositivosfsicos podem ento ser representadas por objetos daclasse associada (ver Figura 1).

Figura 1: Um dos benefcios da modelagem de dispositivos facilitar o reuso de definies comuns.

Uma iniciativa nessa rea, e ainda em estgio dedesenvolvimento, a especificao COSEM (DLMS,2002).O modelo que proposto nesse trabalho usacomo base as classes de interface definidas nessaespecificao. No estgio atual dos esforos emdireo padronizao do acesso a dispositivos de

campo relacionados a empresas de energia eltrica,COSEM a nica que j define uma modelagem demedidores de energia eltrica, o que determinounossa escolha. Assim, o modelo genrico foi baseadonessa especificao, procurando descrever atravs desuas classes as funes de medio definidas naNorma ABNT NBR 14522 (NBR, 2000).

importante ressaltar que no implementamos opadro DLMS/COSEM, mas que usamos apenas suas

classes de interface como base para gerar os nossosblocos bsicos de construo. Essas classes somapeadas em tipos de dados compostos, com base naestrutura de esquemas XSD (XML SchemaDefinition). A composio dessas classes forma umesquema XSD, que representa o modelo lgico de ummedidor de energia genrico, e que pode serespecializado em XSDs de medidores especficos.Instncias desses XSDs so os arquivos XML querepresentam um estado (um objeto) de um medidorespecfico. Ou seja, um sistema que deseja realizaruma leitura dos dados de um medidor, solicita eespera receber um documento XML emconformidade com esse XSD. Em adio,considerando o fato de que uma empresa possuidiversos medidores de um determinado modelo, oXSD correspondente serve para representar toda agama de medidores desse modelo.

3 Modelagem de Classes de Interface COSEM emEsquemas XSDs

O primeiro passo na modelagem foi a definiodas classes de interface COSEM como blocos bsicosde construo nos esquemas XSD. COSEM define 24classes de interface bsicas (DLMS, 2002). Em nossotrabalho usamos apenas aquelas que seriam teis paraa modelagem dos medidores nacionais, que seguem anorma NBR 14522 e so mais comuns no contexto daEletropaulo. A notao utilizada para caracterizaruma classe de interface em COSEM define o nomeda classe, seus atributos e seus mtodos. Tomemoscomo exemplo a classe de interface ExtendedRegister(ver Figura 2). Nesse exemplo, os diversoscampos indicados esto abaixo descritos (na Tabela 1ser mantida a nomenclatura em ingls, porcompatibilidade com a documentao do padro).

Extended Register 0..n Class_id=4, Version=0

Atribute(s) Data Type Min. Max. Def.1 logical_name (static) octet-string2 value (dyn) instance specific3 scaler_unit (static) Scal_unit_type4 status (dyn) instance specific5 capture_time (dyn) Octet-string

Figura 2: ClasseExtended Register.

Com o objetivo de facilitar a visualizao damodelagem, as classes de interface so representadaspor diagramas estruturais, construdos com o uso daferramenta XMLSPY (Altoya, 2004). Por exemplo, amesma classe Extended Register vista na Figura 3como o tipo complexo ExtendedRegister, com os

seus elementos constitutivos class_id, version e todosos seus atributos (logical_name, value, scaler_unit,status, e capture_time). Sendo essa notaorecursiva, o atributo scaler_unit representado pelo

Medidor Genrico

Definies Bsicas

Medidor Saga 1000

(Classe MedidorSaga1000)Definies diretamenteherdadas e definies

especializadas

7/31/2019 CBA2004-Eletro

3/6

tipo complexo scaler_unit_type, que possui oselementos scalere unit.

Class name Extended Register Descreve a classeCardinality 0..n Especifica o nmero de

instncias dessa classe quepodem existir em umdispositivo lgico

Class_id 4 Identifica o cdigo daclasse (feito pela

Associao DLMS)Version 0 Cdigo de verso da classeAttributes No exemplo, de

logical_name acapture_time;podem ser estticosou dinmicos

Especifica os atributos quepertencem classe;logical_name sempre oprimeiro atributo de umaclasse e identifica ainstncia

Data Type e.g., octet-string Define o tipo de dados doatributo

Min. Especifica se o atributotem um valor mnimo

Max. Especifica se o atributotem um valor mximo

Def. Especifica se o atributotem um valor default

Tabela 1: Especificao dos campos da classe de interfaceExtended Register.

Figura 3: Diagrama estrutural da classe de interfaceExtendedRegister.

Tipo Registrador Extendido

Cdigo 1: Cdigo XSD da estrutura indicada na Figura 3.

O esquema XSD apresentado na Figura 3 podeser visto em seu formato texto no Cdigo 1. Comopode-se notar, este XSD mostra as restries s quais

um objeto do tipo ExtendedRegistere seus atributosdevem obedecer. Assim, por exemplo, uma grandezamapeada como uma instncia dessa classe deve ter oatributo value (em negrito no cdigo) do tipointeiro longo (xs: long) e pode variar entre 0 e99999999.

Assim, uma grandeza de um medidor que possuitodos os atributos de um tipo ExtendedRegister modelada como uma instncia desse tipo complexo

de dados. Com isso, ganha-se em clareza namodelagem, pois se modela apenas uma vez a classee, para cada grandeza do tipoExtendedRegister, bastaassoci-la a esse tipo.

Diversas outras classes COSEM forammapeadas. Dentre elas, classes que representam asassociaes COSEM. As associaes constituem umdos mecanismos usados para implementao dosrequisitos de segurana no padro COSEM.

Atravs das associaes possvel estabeleceros direitos de acesso aos dados do medidor, com baseem restries aplicadas a cada cliente. Esses direitosdizem respeito aos objetos vistos pelo cliente, bemcomo s restries que sero impostas nos acessosaos atributos e mtodos desses objetos (e.g., usuriosadministradores podem ter acesso de leitura e escritade parmetros, enquanto que usurios do tipoconsumidor podem apenas ler esses parmetros).

Os objetos visveis em uma associao podemser obtidos por um cliente atravs da leitura doatributo "object_list" do objeto "associao". Assim,diferentes clientes podem ter diferentes vises de ummesmo dispositivo.

Dois tipos de associao so definidos emCOSEM, um para as chamadas associaes de nomecurto (Short Name - SN) e outro para as associaesde nome lgico (Logical Name - LN). A diferenaentre elas est: (i) na forma de endereamento dosmtodos e atributos dos objetos que elas referenciam,e (ii) nos tipos de restries de acesso e seguranaque elas oferecem.

Assim, se a associao utilizada no dispositivolgico do tipo AssociationSN (Figura 4) haveruma instncia dessa classe de interface para cadaassociao que o dispositivo possa manter. noatributo "object_list" que ficam armazenados todosos objetos aos quais a associao faz referncia, ouseja, um objeto que estiver na lista pode ser acessadode acordo com as restries que estiveremestabelecidas pela associao.

Figura 4: Associao do tipoAssociationSN.

4 Representao de um Medidor de Energia

Genrico

Com base na norma nacional, e nos manuais dosmedidores de interesse, identificamos ascaractersticas gerais que um medidor de energia

7/31/2019 CBA2004-Eletro

4/6

7/31/2019 CBA2004-Eletro

5/6

A utilizao de um cenrio distribudo baseadona web para a construo da aplicao tornou-seconveniente. Isso traz flexibilidade e transparncia,na medida em que permite a aquisio dos dados, portodos os agentes envolvidos, gerador, vendedor,comprador, auditor, etc., alm de ser uma tendncianas discusses associadas a padres para a rea. AFigura 8 mostra a arquitetura da aplicao:

Figura 8: Arquitetura do sistema.

As Interfaces de Usurios (IUs) do prottipo sodescritas por pginas HTML, contendo applets para aexibio dos dados das leituras realizadas no medidore para validao de parmetros a serem carregadosno medidor. As IUs so visualizadas em navegadoresweb e trocam dados codificados em HTML e XMLcom o sistema atravs de protocolos padres. OSistema PLPM atua como um servidor web, comsub-funes especficas para ler, processar earmazenar os dados, e repassar parmetros aomedidor.

Para facilitar a realizao de testes foi necessriaa construo de um simulador de medidor.Basicamente, o que esse simulador faz retornar aosistema PLPM, quando solicitado, uma leitura emformato XML. Esse arquivo de leitura obtido pelomapeamento de arquivos K7 (arquivos de leituragerados por medidores de energia reais) no formatoXML. O protocolo de comunicao entre o sistemaPLPM e o simulador de medidor o RMI. A escolhadesse protocolo deve-se ao fato de utilizarmos alinguagem Java no desenvolvimento, que padro defacto em programao na web.

Um grande problema na rea que os medidores

usualmente utilizam protocolos proprietrios para atroca de dados, ou ainda algum outro, como oModbus. Ou seja, no h uma padronizao entre osfabricantes alm daquela indicada pela norma NBR14522. Esse ltimo protocolo, embora insatisfatriopara as demandas atuais, o nico em comum paraaquisio de dados de medidores nacionais. Dessaforma, em nosso prottipo, esse foi o protocoloescolhido para comunicao entre o PLPM e omedidor.

importante notar que o sistema PLPM projetado para trabalhar com um medidor dofuturo. Para os nossos propsitos, caracterizamos

como um medidor do futuro, aquele que, quandosolicitado pelo sistema, devolve uma leitura de dadose/ou parmetros no formato de um arquivo XML, emconformidade com o modelo XSD que o descreve.Para adaptar o sistema PLPM aos medidores atuais

necessrio o uso de linguagens de transformao,como XSLT, e parsers como JAXP. Essaslinguagens permitem transformar os dados doformato que os medidores fornecem para o XML evice-versa.

5.1 Processo de Leitura

Para ler dados, ou alterar os parmetros de

configurao de um medidor, o usurio precisaacessar a IU atravs de um navegador. No primeiroinstante, exigida a autenticao do usurio atravsde um formulrio HTML. Se a autenticao forrealizada com sucesso, a IU apresenta a interface deleitura e manipulao de dados. O usurio precisaento se identificar para estabelecer seu nvel depermisso de acesso e indicar de qual medidor desejater informaes. Isso possvel atravs daidentificao das restries de acesso ao medidor, viao seu XSD. A interface tambm se adapta srestries de acesso de cada classe de usurio sdiversas informaes do medidor.

Em carter de avaliao de conceitos, paraanalisarmos o emprego das associaes, definimostrs classes de usurios, dois administradores compermisses distintas e um consumidor compermisses restritas. As restries de acesso aosdados para cada usurio so descritas de acordo comassociaes no medidor. Esses usurios so: Administrador 1 - tem direitos de leitura sobre

todos os dados e parmetros, e permisso paraparametrizar o medidor;

Administrador 2 - tem direitos de leitura sobretodos os dados e parmetros, mas no tempermisso para parametrizar o medidor;

Consumidor - tem direito de leitura de algunsdados de faturamento para controle interno.

A Figura 9 ilustra os dados relativos ao canal 1de um medidor Saga 1000, de uma leitura realizadapor um usurio do tipo Consumidor.

Figura 9: Processo de leitura do medidor.

Como podemos notar, a Figura 9 possui asgrandezas listadas em trs maneiras. Essa foi a formaque achamos conveniente para ilustrar as restriesque um medidor possui em relao ao modelo

genrico e as restries de um usurio em relao sassociaes. As grandezas com o nome em negrito, eos campos em branco e com valores preenchidos,como as quatro primeiras no exemplo, representamaquelas que existem no medidor e que o usurio tem

7/31/2019 CBA2004-Eletro

6/6

acesso. As grandezas com os nomes em cinzarepresentam as grandezas que existem no modelogenrico, mas no so implementadas nesse medidorespecfico. As outras grandezas com o nome emnegrito, porm com os campos preenchidos com otexto Sem acesso, representam as grandezas que omedidor possui, mas que o usurio atual no tempermisso de acesso.

5.2 Caractersticas Adicionais do Sistema

As seguintes caractersticas devem ser destacadas emnosso sistema de agregao de medio: Os acessos aos dispositivos so feitos atravs de

navegadores de Internet, tais como Netscape ouInternet Explorer, possibilitando visualizao emqualquer regio geogrfica e a partir de qualquercomputador, sem o uso de aplicativos especficos;

O medidor de energia tambm poder estar emqualquer regio, desvinculando a ao daconcessionria a uma determinada rea fsica deatuao;

Transparncia e flexibilidade, na medida em quepermite a obteno dos dados por todos os agentesenvolvidos (gerador, vendedor, comprador, auditoretc);

Fcil incorporao de novos medidores, bastandopara isso incorporar os XSDs que os descrevem.

6 Caractersticas de Segurana

A questo da segurana um ponto de extremaimportncia para se manter a integridade dos dadosem um sistema computacional, principalmentequando o acesso ocorre via web, e havendo aindamltiplos agentes envolvidos. No caso dos medidoresde energia e sistemas de medio, os agentes so asempresas de energia eltrica, os consumidores e asentidades reguladoras.

Para garantir a integridade dos dados, propomosuma poltica de segurana em diversos nveis (verFigura 8). Um primeiro nvel baseado na prpriaarquitetura da Internet, nos seus protocolos emecanismos de autenticao padronizados. Um outronvel de segurana baseado na gerao de logs emdiversos pontos do sistema. Um terceiro nvel baseado nas associaes estabelecidas com osdispositivos lgicos. Adicionalmente, foram tambmmantidas as tradicionais caractersticas de segurana

j implementadas na rea de medio, como oregistro das alteraes realizadas no medidor (Nvel 4da figura 8).

No que diz respeito ao Nvel 1, foram adotadassolues disponveis livremente, gratuitas ecomprovadamente eficazes para troca deinformaes. Essas tecnologias so a SSL (SecureSocket Layer), o conceito de roles e realms, e aautenticao atravs de certificados digitais (ASF,2003).

No nvel de gerao de logs (Nvel 2 na figura

8), so armazenadas informaes de acesso aosistema e ao medidor feitas pelos usurios. Porexemplo, se um usurio muda algum parmetro nomedidor, sero armazenados, a identificao dousurio, o parmetro que foi alterado, a data, a hora,

e o nmero IP da mquina de onde a alterao foifeita. A gerao de logs importante e pode serusada para a realizao de auditorias no caso desuspeita de fraudes.

O Nvel 3 est associado diretamente aodispositivo lgico e refere-se ao conceito deassociaes. Quando um dispositivo fornece um dadoem XML ao sistema, ele fornece tambm asrestries de acesso a esse dado de acordo com o

usurio que o est requisitando. O Nvel 4 refere-seaos procedimentos j tradicionais.

7 Concluses

O objetivo principal deste trabalho foi demonstrar,em termos conceituais e prticos, os benefcios evantagens da abordagem de utilizao de modelospara a integrao de sistemas heterogneos,principalmente no contexto de medidores de energiaeltrica. Nessa abordagem, a interoperabilidade entresistemas tratada em um nvel mais alto deabstrao, no nvel de representaes de domnio.

O uso de modelos como estratgia de integraomostrou-se uma boa alternativa no processo deintegrao de sistemas. Essa abordagem permite quea soluo esteja centrada nas funcionalidades e nocomportamento dos sistemas, separando-os dosdetalhes das tecnologias utilizadas naimplementao.

Um ponto importante a ser destacado que,tanto na modelagem quanto na implementao dosistema, houve uma preocupao na adoo depadres e em solues de software livres e gratuitos,e ainda a independncia de plataforma de execuo.Assim, utilizamos XML como forma derepresentao e modelagem dos dados, Java comolinguagem e ambiente de desenvolvimento, a Internetcomo arquitetura, TCP/IP, HTTP e SSL comoprotocolos de comunicao.

Referncias

Altova (2004). XMLSPY. Disponvel emhttp://www.xmlspy.com, pgina consultada emFevereiro de 2004.

ASF (2003). The Tomcat 4 Servlet/JSP Container,Documentation Index, Apache Software Foundation,http://jakarta.apache.org/tomcat/tomcat-4.0-doc/.

DLMS (2002). DLMS UA 1000-1, COSEMIdentification System and Interface Objects, 5a.ed., DLMS User Association.

NBR (2000).Intercmbio de informaes para sistemas demedio de energia eltrica, NBR 14522, AssociaoBrasileira de Normas Tcnicas, Rio de Janeiro.

Reynoso E.M.D. (2003). Integrao de Sistemas Baseadaem Modelos: Uma Aplicao no Setor Eltrico,Dissertao de Mestrado, PGC-IC/UFF, Maro.

UCA (2000). Generic Object Models for Substation &Feeder Equipment (GOMSFE), Verso 0.91, UtilityCommunications Architecture, EPRI.

UCA (1997). Introduction to UCA Version 2.0, EditorialDraft 1.0, Utility Communications Architecture,

EPRI.W3C (1998).Extensible Markup Language (XML) 1.0, 2a.

ed., WWW Consortium.