SlideShare uma empresa Scribd logo
1 de 8
Baixar para ler offline
Abstract— In this project, we developed a computational
system based on a framework of geo-referenced data that uses
Google Maps technology. The focus is on improving the modeling
of information for viewing and embedding technology, human-
computer interface (HCI) which includes visualization
environments synchronized. The first environment allows you to
have the vision of the network elements in the form of electrical
single line diagram, representing a consolidated technique in the
field of electricity. The second environment called GIS is a map-
based navigation with Google Maps that allows the physical
location of where it is represented the elements present in the
electrical line diagram. This integrated system is capable of
supporting the planning of network expansion works in the areas
of distribution and transmission of electricity.
Keywords— visualization system, GIS, distribution,
transmission, system of decision making, planning, google maps.
I. INTRODUÇÃO
QUALIDADE e quantidade da energia elétrica
distribuída pelas concessionárias são influenciadas pelo
crescimento da demanda por energia elétrica e pelo desgaste
dos elementos que compõem a rede elétrica. O planejamento
de obras de expansão e melhoria da rede elétrica é feito pela
concessionária para que a demanda por energia possa ser
atendida satisfatoriamente.
O planejamento, elaborado anualmente pelas
concessionárias, precisa atender as exigências dos órgãos
reguladores brasileiros. Dessa forma, cada concessionária
realiza um planejamento de curto prazo, considerando um
período de 10 anos, que é enviado a EPE (Empresa de
Pesquisa Energética) e constitui o Plano Decenal de
Expansão. A partir do planejamento de todas as
concessionárias, a EPE realiza estudos de viabilidade para
realização de cada empreendimento proposto.
O primeiro passo no processo de planejamento de redes de
alta tensão, o planejador realiza um diagnóstico de
desempenho técnico da rede existente. Para esse diagnóstico é
calculado o fluxo de potência, onde o planejador pode avaliar
o carregamento nos trechos e o nível de tensão das barras,
chamados critérios técnicos. De acordo com o diagnóstico
pode ser necessário propor obras que solucionem as violações
dos critérios técnicos, levando em consideração a demanda
A. Valerio Netto, Cientistas Desenvolvimento Tecnológico Ltda, Divisão de
tecnologia e novos negócios, valerio@cientistas.com.br
futura, dados geográficos, políticos e econômicos da região.
Assim é possível determinar onde, quando e a capacidade dos
reforços a serem incorporados à rede elétrica, visando atender
a demanda prevista com menor custo e padrões de qualidade
aceitáveis.
Atualmente, entre os softwares mais utilizados para o
planejamento de redes de distribuição de alta tensão
encontram-se o Anarede e o Anafas, desenvolvidos pelo
CEPEL, com módulos para cálculo de fluxo de potência e
curto circuito, respectivamente. Entretanto esses softwares
cobrem apenas a etapa de diagnóstico da rede elétrica, não
oferecendo suporte à tomada decisão na escolha das obras que
oferecem o melhor custo/benefício.
Este projeto vem ao encontro a suprir a necessidade por um
software capaz de auxiliar no planejamento de expansão e
melhorias de redes elétricas de alta tensão. O software
proposto chama-se Interplan-AT Plus e foi baseado no
Interplan-AT, software desenvolvido pela empresa Daimon
(www.daimon.com.br). Foram acrescentadas novas
funcionalidades, como importação e exportação de dados da
rede elétrica e novos recursos de visualização e edição da rede
elétrica, adicionando suporte ao geo-referenciamento por meio
do Google Maps [7].
O Interplan-AT Plus é uma ferramenta para apoio ao
planejamento de expansão de redes de distribuição de energia
elétrica de alta tensão que pode ser utilizada por engenheiros
eletricistas responsáveis pelo planejamento em
concessionárias de energia. Para isso, o planejador pode usar o
Interplan-AT Plus para importar a estrutura da rede ou
construí-la usando o editor gráfico de redes, e identificar as
áreas que necessitam de obras de expansão. Ainda usando o
editor gráfico de redes, o planejador propõe as obras
necessárias à satisfação dos critérios técnicos e econômicos
estabelecidos.
Como suporte à elaboração de obras de expansão, o
Interplan-AT Plus conta com a visão geo-referenciada da rede
de alta tensão utilizando o Google Maps. Para usar esse
recurso, basta que o planejador insira a localização geográfica
(latitude, longitude e elevação) dos elementos elétricos
presentes na rede.
O Interplan-AT Plus permite ainda a importação e
exportação da rede para o formato “.pwf” usado pelo Anarede.
Assim as concessionárias podem enviar seu plano de expansão
já no formato aceito pelo EPE.
A
A. Valerio Netto
Planning of Network System for the
Distribution and Transmission Areas of Electric
Energy
IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015 345
II. METODOLOGIA
A metodologia adotada para o desenvolvimento do projeto
Interplan-AT Plus é o IVPM2 – Iterative & Visual Project
Management Method – traduzido como “Método Iterativo e
Visual para Gestão de Projetos”, que se baseia na aplicação
dos princípios e práticas do gerenciamento ágil de projetos por
meio do uso das estruturas de apoio à gestão de projetos. O
método consiste de cinco fases:
1. Visão: determinar a visão do produto, o escopo do projeto,
os interessados no projeto, e a definição de como a equipe
irá trabalhar, interagir;
2. Concepção: definir entregas, cronograma e o plano de
iteração de acordo com a visão;
3. Projeto Detalhado: entregar os componentes do produto
(requisitos de projetos pré-definidos na fase da
Concepção) em ciclos de entregas reduzidos, minimizando
riscos e incertezas;
4. Validação: rever os resultados entregues, analisar a
situação atual e o desempenho do time. Adaptar esses
resultados se necessário;
5. Encerramento: encerrar o projeto, finalizar tarefas
pendentes e transferir as lições aprendidas mais
importantes.
Na fase de Visão do projeto Interplan-AT Plus foram
produzidos dois documentos de requisitos do produto. O
primeiro, chamado de Documento de Requisitos do Produto
(DRP), contém a descrição resumida do projeto e questões
para a identificação dos requisitos do produto, tais como:
desempenho, tempo de vida útil, durabilidade, produção
estimada, dentre outras.
Nesse documento são também abordadas questões a
respeito de vendas do produto e estudo de mercado.
O segundo documento, chamado de Especificação de
Requisitos de Software (ERS), define aspectos como escopo e
perspectiva do produto, bem como requisitos de interface com
o usuário e funcionalidades do software, de forma resumida.
Esses requisitos serão detalhados posteriormente na fase de
Concepção.
Os principais itens desse documento desenvolvidos na fase
de Visão são:
1. Escopo do Software: Contém uma primeira visão do
escopo do produto especificado. Deve apresentar informações
como: Nome do produto a ser desenvolvido; componentes
principais; o que o software fará; o que o software não fará;
funções que serão implementadas por outros componentes de
um sistema maior, ou versões futuras; e benefícios do produto
e valor para o cliente.
2. Perspectiva do produto: Posiciona o produto no
contexto em que está inserido. Relaciona as exigências do
sistema envolvente com a funcionalidade do software a ser
desenvolvido, caso o produto faça parte de um sistema maior.
No caso do Interplan-AT Plus, esse item detalha o mercado
energético brasileiro, destacando como o software
desenvolvido insere-se nesse contexto.
3. Interface de usuário: Define as interfaces entre o
produto e seus usuários humanos. Entre elas estão telas,
janelas e relatórios. Na fase de Visão é realizada apenas uma
descrição geral das interfaces mais importantes. Maiores
detalhes devem ser deixados para a fase de Concepção. No
caso do Interplan-AT Plus, foram descritas as necessidades de
um editor gráfico de redes e integração com o Google Maps.
4. Interface com software: Define as interfaces com
outros produtos de software, como aplicativos que recebem ou
enviam dados do produto. No caso do Interplan-AT Plus, esse
item contém a necessidade de integração com o software
Anarede, desenvolvido pelo CEPEL.
5. Funções do produto: Descrever as principais funções
do software, de maneira resumida e mostrando o objetivo que
será atingido com cada uma. No caso do Interplan-AT Plus,
são descritas as principais funcionalidades de apoio ao
processo de planejamento de redes de alta tensão.
6. Restrições: Descreve aspectos técnicos e gerenciais
que podem limitar as opções de desenvolvimento do software,
como restrições legais, limitações de hardware, restrições
quanto à linguagem de programação e banco de dados,
restrições de desempenho, confiabilidade e segurança. No
caso do Interplan-AT Plus, foram considerados aspectos
referentes ao ambiente computacional onde o software será
usado e medidas e soluções determinadas pelo órgão
regulador brasileiro, a Agência Nacional de Energia Elétrica
(ANEEL).
Os principais objetivos atingidos na fase de Concepção
foram o detalhamento dos requisitos iniciais definidos na fase
de Visão, escolha das tecnologias usadas no projeto e
elaboração do modelo conceitual do produto.
Os requisitos descritos resumidamente na fase de Visão são
detalhados na Concepção. O documento de Especificação de
Requisitos de Software (ERS) é estendido com os requisitos
de software em um nível de detalhe suficiente, capaz de
permitir aos desenvolvedores projetar um sistema para
satisfazer esses requisitos. Os principais itens desse
documento desenvolvidos na fase de Concepção são:
a) Interfaces de usuários - Descreve detalhadamente os
requisitos de interface com o usuário. Cada interface possui:
Protótipos de interface; Diagramas de estados, para entender o
comportamento exigido da interface; Relacionamentos com
outras interfaces; Lista de campos de dados da interface (tipo,
formato, validação, restrições); e Lista de comandos da
interface (ações, restrições, etc). No Interplan-AT Plus, foram
descritas 83 interfaces, incluindo as interfaces para edição da
rede (diagrama unifilar) e exibição do diagrama geo-
referenciado, abas de exibição dos atributos de cada elemento
elétrico da rede, interface para criação de obras, interfaces de
exibição dos resultados de fluxo de potência e curto-circuito,
interfaces para importação e exportação dos dados do Anarede
interface para importação e exportação do banco de dados
usado pelo software, entre outros. As interfaces mais
relevantes foram detalhadas integralmente, enquanto outras
mais simples e intuitivas foram detalhadas durante o Projeto
Detalhado.
b) Interfaces de software - detalha as interfaces com outros
346 IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015
produtos de software. Contém informações como
relacionamentos com outras interfaces e formato dos arquivos
utilizados. Para o Interplan-AT Plus foi descrito o formato de
dois arquivos usados pelo Anarede: “.pwf” para descrição das
propriedades dos elementos elétricos e “.lst”, para exibição
gráfica dos elementos. Adicionalmente, foi criado um formato
próprio – “.ceb” - para importação e exportação dos dados
referentes ao ciclo de estudos.
c) Requisitos funcionais - Os requisitos funcionais são
detalhados usando a técnica de casos de uso, onde cada caso
de uso expressa o objetivo que o ator deseja atingir com sua
execução. Os casos de uso descrevem por meio de uma
linguagem simples as ações fundamentais que precisam ter
lugar no software para aceitar e processar as entradas e para
processar e gerar as saídas. Descreve também os atores que
interagem com o software de maneira direta e indireta. Assim
é possível ilustrar o comportamento do software, facilitando a
compreensão dos usuários e permitindo a correção de
possíveis erros na especificação [5]. No ERS, esse item
contém uma descrição visual desses requisitos, chamada
diagrama de casos de uso. A descrição de cada caso de uso é
apresentada em um documento anexo de especificação de
casos de uso.
d) Requisitos não-funcionais - Descreve requisitos de
desempenho, qualidade e padrões e/ou regulamentações que o
produto deve respeitar. Inclui também requisitos lógicos para
qualquer informação que será colocada numa base de dados e
um esboço inicial do modelo entidade-relacionamento.
III. MODELO CONCEITUAL
O objetivo do Interplan-AT Plus é oferecer suporte ao
processo de planejamento de redes elétricas de alta tensão
mapeado durante a obtenção dos requisitos iniciais na fase de
Visão. O processo de planejamento é modelado por meio do
diagrama de atividades da UML exibido na Fig. 1 e descrito
em detalhes a seguir.
Figura 1. Diagrama de atividades do processo de planejamento de redes
elétricas de alta tensão.
1) Supervisor cria ciclo de estudos: Um ciclo de estudos
corresponde ao período de estudos onde os planejadores
fazem propostas para expansão da rede no período
considerado. Esse ciclo de estudos pode ser criado a partir de
uma de rede elétrica ou a partir de um ciclo de estudos
anterior já finalizado. Depois de criado, o ciclo de estudos
assume estado “Novo”, onde o supervisor pode inserir os
dados necessários para que os planejadores iniciem o
planejamento.
2) Supervisor insere dados para início do planejamento:
Para que os planejadores verifiquem se algum critério técnico
é transgredido, é necessário informar os dados de crescimento
de demanda para o período de estudo. Nesse momento, o
supervisor também pode fazer algumas modificações na rede,
em decorrência de alterações nas obras propostas em ciclo
anterior feita durante sua execução. Quando todos os dados
forem inseridos, o supervisor altera o estado do ciclo para
“Aberto”. A partir desse momento, os planejadores possuem
todos os dados necessários à proposição de obras.
3) Planejadores realizam diagnóstico da rede: Os
planejadores iniciam o planejamento das áreas da rede que
das quais são responsáveis. Para isso, o primeiro passo é
realizar o diagnóstico da rede através dos estudos de fluxo de
potência e curto-circuito. Com base nos resultados desses
estudos o planejador verifica quais elementos elétricos
transgrediram os critérios técnicos (carregamento, níveis de
tensão) e identifica a necessidade de melhoria e expansão da
rede.
4) Planejadores propõem obras para rede: Planejador
propõe obras (modificações) na rede em estudo para atender
as necessidades identificadas no fluxo de potência ou
solicitação de novos clientes. Essas obras podem ser obras de
expansão, renovação dos ativos e melhoria da qualidade do
sistema. O planejador pode propor mais de uma obra (obras
alternativas) para resolver um mesmo problema, buscando
como a rede comporta-se com cada obra. A obra que satisfaz
os critérios técnicos e financeiros é chamada obra proposta. A
seguir, a concessionária aprova obras para os primeiros três
anos do ciclo de estudos. Após a aprovação, a obra proposta
passa a ser chamada obra aprovada. Caso contrário, ela
continua sendo considerada proposta. Normalmente, as
concessionárias aprovam obras para os próximos três anos.
As obras sugeridas para os anos seguintes são chamadas obras
referenciais.
5) Planejadores finalizam planejamento: Todos os
planejadores submetem as obras propostas, referenciais e
aprovadas para todos os anos do ciclo de estudo para
supervisor.
6) Supervisor importa obras: Supervisor importa obras
exportadas pelos planejadores. Nesse processo pode acontecer
que dois planejadores tenham feito modificações em um
mesmo elemento elétrico, o que caracteriza um conflito na
rede. O supervisor só pode realizar estudos com as obras
propostas pelos planejadores quando os conflitos da rede
tiverem sido resolvidos. O supervisor pode resolver esses
conflitos alterando ele mesmo os elementos da rede que
compõem a obra.
VALERIO NETTO: PLANNING OF NETWORK SYSTEM FOR 347
7) Supervisor encerra ciclo de estudos: Supervisor encerra
período para os planejadores proporem reforços para a rede.
Nesse momento o ciclo de estudos possui estado “Encerrado".
8) Supervisor exporta ciclo de estudos: Supervisor exporta
dados do ciclo de estudos para o mesmo formato usado pelo
Anarede (.pwf + .lst). Assim é possível enviar os dados
necessários à EPE. É possível exportar a rede sem obras e a
rede com obras propostas, referenciais e aprovadas de um
determinado ano. O modelo conceitual faz parte do
detalhamento dos requisitos iniciais e usa o diagrama de
classes da UML [5] para descrever mais precisamente os
conceitos do domínio da aplicação relevantes para o
entendimento dos requisitos do produto. A principal base para
confecção do modelo conceitual é a descrição do processo de
planejamento. As figuras abaixo mostram a modelagem
conceitual para ciclo de estudo, elementos elétricos, redes e
fluxo de potência do Interplan-AT Plus. Cada classe
representa um conceito do domínio da aplicação, e as ligações
entre elas indica a relação entre cada conceito. Essa
modelagem foi feita usando o software de modelagem
Enterprise Architect 7.5 [6].
Define a estrutura arquitetônica principal do produto,
dividindo-o em camadas, pacotes lógicos e subsistemas. A
arquitetura usada no Interplan-AT Plus é chamada MVC
(Model-View-Controller) [1] e divide o produto em três
camadas: dados, visualização e controle. As vantagens dessa
arquitetura são a modularidade e possibilidade de troca de
uma camada, sem impactos nas demais. Além disso, essa
arquitetura facilita a distribuição das atividades, permitindo
que cada desenvolvedor atue em uma camada específica.
Na etapa de projeto detalhado foram implementados os
requisitos aprofundados durante a fase de Concepção,
respeitando a arquitetura e as tecnologias definidas, mas
também fazendo reajustes necessários. A escolha da
arquitetura MVC facilita a modularização do software e a
distribuição das atividades. Por isso, inicialmente, atuamos
em 3 frentes: interfaces, controle e banco de dados. Os
requisitos foram priorizados levando em consideração:
• Complexidade técnica: indicando a complexidade técnica
para implementação do requisito. Cada requisito foi
classificado em alta, média e baixa.
• Valor agregado ao produto: indicando o valor para o
produto do requisito. Cada requisito foi classificado em
fundamental, importante e opcional.
À medida que se progrediu com a implementação do
software, algumas dificuldades surgiram, com relação ao
desempenho e também à usabilidade, o que fez com que
adotássemos também o outro padrão de projeto – Singleton,
para garantir a visualização e sincronia correta entre os dados
do DU e do Google Maps.
Considerando essa priorização, o primeiro requisito a ser
implementado foi a construção da interface principal,
incluindo o diagrama unifilar e o diagrama geo-referenciado
(Google Maps).
Figura 2. 1) Menu Principal; 2) Barra de ferramentas; 3) Barra de ferramentas
do diagrama unifilar; 4) Abas para visualização da rede em cada ano do ciclo
de estudos; 5) Diagrama unifilar; 6) Diagrama georreferenciado,
GoogleMaps[7]; 7) Abas laterais para edição do diagrama unifilar para inserir
novos elementos, alterar propriedades e filtrar elementos visíveis no DU; 8)
Abas laterais para criação e visualização de obras no ciclo de estudos; 9)Abas
inferiores com resultados do fluxo de potência e mensagens de execução do
software.
IV. RESULTADOS
Para implementar a arquitetura do software, foi criada uma
camada de acesso aos dados denominada DAO, classes para
realização das transações, denominada CONTROL, a camada
de representação das entidades, chamada BO, a camada das
interfaces, chamada GUI. Além desta arquitetura, durante a
fase do projeto detalhado, foi adotado o padrão Singleton,
para garantir maior performance na exibição da rede no
Google Maps. Foi escolhido o Microsoft Visual Studio 2008
[3] como ambiente de desenvolvimentotraba de software. As
tecnologias usadas no Interplan-AT Plus adequadas para essa
arquitetura são:
• WPF (Windows Presentation Foundation [2]) para a
camada de visualização: tem como característica a
criação rápida de layouts customizados, interativos e
dinâmicos, o que permitindo maior qualidade na
interação com usuário. Além disso, permite a separação
entre a lógica e a interface, requisito para implementação
da arquitetura MVC.
• C# para a camada de controle e acesso ao banco de
dados: linguagem de programação orientada a objetos,
parte da plataforma .NET desenvolvido pela Microsoft.
Trata-se de uma linguagem robusta, com a qual a equipe
de desenvolvimento já estava familiarizada.
• banco de dados PostgreSQL: sistema gerenciador de
banco de dados de código aberto, com controle de
concorrência no acesso simultâneo aos dados e capaz de
armazenar tabelas com até 32 TB [4], utiliza a linguagem
SQL.
348 IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015
• Crystal Reports para a geração dos relatórios.
• Javascript, HTML, CSS, para criação da página de
exibição do Google Maps.
Foi aprimorada a interface disponibilizando-a nos idiomas
português, inglês e espanhol, o qual é definido por meio de
uma caixa de seleção na tela de login (Fig. 3).
Figura 3. Tela de login e seleção de idioma.
Para visualizar os elementos da rede no Google Maps,
optou-se por utilizar a API Javascript. Para isto, o primeiro
passo foi criar uma página web contendo as funções da API
Google Maps, com adaptações para os nossos dados.
Figura 4. Tela principal com mapa baseado no Google Maps.
Quando uma rede é carregada, existe a função de exibir o
mapa com seus elementos. Clicando sobre o ícone do
elemento no mapa, são exibidas suas informações de latitude,
longitude e o tipo do elemento (Fig. 5). No código C# da
aplicação, foi criada uma classe para transferência das
informações latitude, longitude, símbolo do elemento elétrico,
para a função javascript, de nossa página web.
Existe a opção de filtrar os tipos de elementos que são
exibidos no Mapa, por meio do componente visual checkbox.
Caso não haja nenhum elemento selecionado, é exibida, ou a
rede padrão, ou o mapa inicial vazio, devido a limitações do
Google Maps. Também existem limitações para o número de
acessos e quantidade de componentes que podem ser exibidos,
e isto pode variar de acordo com as modificações que são
implementadas pelos responsáveis pelo Google Maps.
Figura 5. Detalhe do geo-referenciamento.
A seguir, foram implementadas as abas para inserção dos
elementos elétricos ao diagrama unifilar e para alteração das
propriedades dos 15 elementos elétricos. A Fig. 6 mostra a
interface principal do Interplan-AT Plus. A aba para inserção
de elementos elétricos na rede está localizada na lateral
esquerda da tela principal. Para inserir um elemento, o
planejador deve selecionar o elemento desejado na lista, e
escolher sua localização no diagrama unifilar.
Quando isso é feito, a aba de propriedades é habilitada,
localizada na lateral direita da tela principal. Assim o
planejador pode inserir os dados do novo elemento e salvá-lo
no banco de dados. Para elementos elétricos que já fazem
parte da rede, a aba de propriedades é alterada de acordo com
o elemento selecionado. Nessa aba o planejador pode editar as
propriedades do elemento, cancelar a edição iniciada ou
remover o elemento da rede.
VALERIO NETTO: PLANNING OF NETWORK SYSTEM FOR 349
Figura. 6. Aba de propriedades do elemento.
Um dos diferenciais do Interplan-AT Plus é a possibilidade
de o planejador criar obras para resolver violações de critérios
técnicos. Isso é feito através de abas para criação, edição e
visualização das obras de um ciclo de estudos. É importante
lembrar que essas abas estão disponíveis apenas quando um
ciclo de estudos é aberto. Quando apenas uma rede é aberta,
apenas os controles para edição da rede são permitidos.
Na Fig. 7 é possível ver a tela principal com um ciclo de
estudos aberto. Na aba Lista de Obras o planejador pode
inserir uma obra, preenchendo propriedades como descrição e
custo. Toda obra criada é considerada inicialmente como
Alternativa. Quando uma obra é inserida em um ano,
automaticamente é persistida nos anos posteriores, e também
torna-se visível em cada diagrama unifilar subsequente.
Figura 7. Gerenciar obras.
Primeiramente, deve-se, no painel de obras, definir as
propriedades (nome, descrição, custos adicionais) desta obra,
para que então, torne-se possível modificar a rede. O modo de
inserção de elementos é o mesmo, seleciona-se o elemento no
respectivo painel, arrasta-se para o diagrama unifilar, e a
seguir, são preenchidas as propriedades deste elemento
elétrico.
Um dos pontos importantes deste novo software, é a
geração de relatórios de comparação de obras. Utilizou-se a
tecnologia Crystal Reports integrada ao Visual Studio para
este fim. Por meio de consultas optimizadas ao banco de
dados, os relatórios geram as informações detalhadas de
custos das obras propostas, organizadas para cada ciclo de
estudos realizado. Desta forma, o planejador pode optar pelas
obras mais satisfatórias, de acordo com os critérios técnicos e
econômicos adotados pela empresa usuária.
Figura 8. Relatório de comparação de custos de obras gerado pelo aplicativo.
V. CONSIDERAÇÕES FINAIS
As principais funcionalidades do projeto Interplan-AT
Plus, de acordo com os requisitos identificados, analisados e
modelados em conjunto com o potencial cliente, foram
implementadas.
As funções de cálculo de fluxo de potência,
intertravamento entre chaves e outras específicas de
manipulação da rede elétrica, bem como regras de negócio
para conexão de elementos devem ser realizadas pela empresa
parceira Daimon, e entregues na forma de classes ou
bibliotecas a serem agregadas ao software. Durante a fase de
projeto detalhado, algumas dificuldades foram levantadas:
• Uso de WPF: por tratar-se de uma tecnologia nova, boa
parte do material disponível aborda conceitos básicos, e
tarefas mais complexas com a integração do componente
webbrowser, o diagrama de desenho do DU, a interação
com javascript, e até mesmo a performance do software
quando operando com dados grandes volumes de dados
não foram corretamente dimensionados e considerados
350 IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015
na fase de concepção;
• Fase de concepção abordou muito superficialmente como
gerar o diagrama geo-referenciado, o que poderia ter
levado ao comprometimento da tarefa. Existem algumas
soluções implementadas para aplicações web, porém, por
tratar-se de um software que requer grande capacidade
de processamento, estabeleceu-se como requisito, que
seria uma aplicação desktop. Inicialmente, concebeu-se
utilizar arquivos KML.
• A ideia de dividir tarefas entre equipes, para
implementação da arquitetura MVC, até um certo ponto
é interessante, porém, em certas funcionalidades, é
praticamente inviável, do ponto de vista prático;
• A estratégia de ciclo de desenvolvimento adotada
inicialmente, não condiz com os preceitos de uma
metodologia ágil, mas sim, tem grande semelhança ao
método cascata, onde são definidos os requisitos
inicialmente, e só então inicia-se a implementação [8].
Para contornar estas dificuldades procurou-se focar no
objetivo a ser alcançado e visando produzir um código
bastante modularizado, para facilitar o reuso futuro. No que
diz respeito ao WPF, na medida em que tornou-se complicado
demais utilizar certos componentes, optou-se por alguma
solução alternativa, ou utilizando algum componente pronto,
ou utilizando o conhecimento prévio de C# com Windows
Forms.
A tela inicial, em que era pretendido um comportamento
similar à IDE do Visual Studio, com abas que podem ser
escondidas, e com redimensionamento automático de
conteúdo, foi um destes problemas, e a solução proposta foi o
uso da biblioteca Avalon Dock [9]. Esta biblioteca supriu até
um certo ponto as necessidades, porém, parece estar ainda
incompleta, e após inúmeros testes, com diferentes
configurações, optou-se por abrir mão de certas
funcionalidades no quesito interface, ganhando, no entanto, no
quesito estabilidade.
Com relação ao Google Maps, existem inúmeros exemplos
de uso, em aplicações web, porém para desktop, para
ambiente Microsoft, é raro encontrar informações
consistentes, um exemplo é a biblioteca Gmap.NET [10].
Diante da escassez de documentação para que pudéssemos
implementar uma solução estável e consistente, nossa busca
levou à implementação de uma classe que estabelece
comunicação com o browser incorporado no software. Esta
alternativa, requereu a criação de uma página HTML que
contém um código baseado na API do Google Maps.
Nesta página, a função HTML recebe os dados enviados a
partir do código C#, previamente formatados. Foi criado um
'parser': uma classe com métodos para codificar os dados num
formato aceitável para o código javascript, e no javascript
estes dados são novamente decodificados para que sejam
exibidos no mapa, nas coordenadas de latitude e longitude, o
símbolo do elemento elétrico correspondente.
Nesta etapa, já ficou evidenciado que a divisão MVC não é
totalmente apropriada para dividir tarefas entre diferentes
equipes, delegando a interface para um equipe diferente
daquela que implementa o código do modelo, ou de acesso à
base de dados. Isto poderia ser utilizado se já fosse sabido de
antemão, a forma em que os dados deveriam ser manipulados,
assim como a forma de interação com o componente
webbrowser.
O ponto positivo foi ter alcançado uma solução própria,
que torna a equipe detentora deste know-how.
Por fim, as fases do ciclo de vida do software, foram
concebidas com base num modelo cascata [8] [12], que se
caracteriza pela falta de flexibilidade das etapas, e pode até
funcionar muito bem em certos tipos de aplicações, mas no
caso do Interplan AT Plus, uma metodologia ágil, que
combine a necessidade de uma boa especificação do produto,
com a flexibilidade de produzir mudanças e adaptações em
tempo hábil, com foco maior na geração de código funcional,
e por consequência um produto que atenda às necessidades do
cliente, do que na criação de documentação [8,11]. Até
porque, após o período de dois anos, muito pode mudar e
corre-se o risco de produzir um produto obsoleto ao final.
Pensando nisto, na fase final, algumas funcionalidades
foram mantidas em aberto, para que seja possível a adequação
de necessidades específicas de eventuais clientes, e a
arquitetura foi sendo ajustada para facilitar a manutenção
futura.
Do ponto de vista estratégico, a ideia e ter em mãos, além
do produto inicialmente proposto para o setor de energia
elétrica, uma concepção de solução de software para
planejamento inteligente de infraestrutura.
Pode-se concluir que o projeto foi bem sucedido. O
software produzido é inovador e está sendo apresentado para
potenciais clientes. Pessoas foram treinadas nas tecnologias e
adquiriram novos conhecimentos, agregando valor à equipe
técnica.
AGRADECIMENTOS
O autor agradece o apoio financeiro do CNPq por meio do
programa RHAE Pesquisador na empresa (557812/2008-9) e
empresa Daimon (www.daimon.com.br).
REFERÊNCIAS
[1] Windows Presentation Foundation -
http://msdn.microsoft.com/en-us/library/ms754130.aspx –
Acessado em 16/06/2010.
[2] Freeman, E.T., Robson, E., Bates, B., Sierra, K. Head
First Design Patterns. 1ª edição, O'Reilly Media, 2004.
[3] Microsoft Visual Studio - http://msdn.microsoft.com/pt-
br/vstudio/default.aspx – Acessado em 16/06/2010.
[4] PostgreSQL - http://www.postgresql.org/about/ -
Acessado em 16/06/2010.
[5] Gilleanes T. ª Guedes. UML 2 - Uma abordagem prática.
1ª edição, Editora Novatec, 2009.
[6] Enterprise Architect - www.sparxsystems.com/ -
Acessado em 17/06/2010.
[7] Google Maps – maps.google.com – Acessado em
18/06/2010.
VALERIO NETTO: PLANNING OF NETWORK SYSTEM FOR 351
[8] Sommerville, Ian, Engenharia de Software, 8ª edição,
Addison Wesley, 2007.
[9] Avalon Dock - http://avalondock.codeplex.com/ -
acessado em 10/03/2010.
[10]Gmap.NET - http://greatmaps.codeplex.com/ - Acessado
em 05/08/2010.
[11]A Nova Metodologia, http://simplus.com.br/artigos/a-
nova-metodologia/ Acessado em 10/12/2010.
[12]A. Valerio, "Visualization System Integrated for Electric
Power Distribution Networks", IEEE LATIN AMERICA
TRANSACTIONS, Vol. 8, No. 6, pp. 728-733, Dec.
2010.
Antonio Valerio Netto é Doutor em computação e
matemática computacional pela Universidade de São
Paulo (ICMC/USP). Possui MBA em Marketing pela
FUNDACE (FEA-RP/USP). É técnico em informática
industrial pela ETEP, Bacharel em computação pela
Universidade Federal de São Carlos (DC/UFSCar) e
mestre em engenharia pela Universidade de São Paulo
(EESC/USP). Em 2001 foi pesquisador visitante na
Universidade de Indiana (EUA). Trabalhou cinco anos na área de P&D da
Opto Eletrônica S.A. e, posteriormente, dois anos como consultor de novas
tecnologias da Debis Humaitá do grupo DaimlerChrysler e um ano na T-
Systems, empresa do grupo Deutsche Telekom. Em 2003, fundou a Cientistas,
empresa focada no desenvolvimento de produtos tecnológicos, da qual é seu
principal dirigente. Em 2007, fundou a primeira empresa de robótica móvel
inteligente do país, a XBot, que em 2009 foi considerada pelo Sebrae SP uma
das pequenas empresas mais inovadoras do estado de São Paulo. É o
coordenador titular do Núcleo de Jovens Empreendedores e coordenador do
núcleo regional de inovação do CIESP de São Carlos e região. Foi diretor da
seção Brasil do International Council for Small Business (ICSB) e consultor
do programa SebraeTec do Sebrae SP entre 2003 e 2005. Possui em torno de
75 publicações entre livros, capítulos de livros, revistas e congressos
internacionais e nacionais nas áreas de computação e engenharia. Possui duas
patentes. Coordenou em torno de 15 projetos tecnológicos financiados pela
FINEP, CNPq, FAPESP e empresas privadas nos últimos cinco anos. Recebeu
diversos prêmios e menções honrosas, como a do Society of Automotive
Engineer (SAE) Brasil 2001 - melhor artigo técnico na categoria Projetos e de
melhor aluno do MBA em Marketing da FUNDACE (FEA-RP/USP) em 2006.
Em 2008 foi finalista do prêmio Empreendedor de Sucesso promovido pela
revista PEGN e FGV. Em 2009 tornou-se professor honorário da Universidad
Abierta Interamericana (Buenos Aires/ARG).
352 IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015

Mais conteúdo relacionado

Semelhante a Planning Electric Network System Distribution Transmission Areas

Projetode redes
Projetode redesProjetode redes
Projetode redeswab030
 
Plano de Projeto - OUTLAY
Plano de Projeto - OUTLAYPlano de Projeto - OUTLAY
Plano de Projeto - OUTLAYJocelino Neto
 
Metodologia de desenvolvimento de sistemas
Metodologia  de desenvolvimento de sistemasMetodologia  de desenvolvimento de sistemas
Metodologia de desenvolvimento de sistemasPriscila Stuani
 
Plano projeto(final)
Plano projeto(final)Plano projeto(final)
Plano projeto(final)Raul Vilar
 
Aulas PPR Semanas 1 2 e 3 _ 18032024 (1).pptx
Aulas PPR Semanas 1 2 e 3 _ 18032024 (1).pptxAulas PPR Semanas 1 2 e 3 _ 18032024 (1).pptx
Aulas PPR Semanas 1 2 e 3 _ 18032024 (1).pptxTrcioMatsombe
 
Portfolio Grupo 4 ADS Unopar Desafios1-2-3-4
Portfolio Grupo 4 ADS Unopar Desafios1-2-3-4Portfolio Grupo 4 ADS Unopar Desafios1-2-3-4
Portfolio Grupo 4 ADS Unopar Desafios1-2-3-4Adilson Nascimento
 
Plano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents ControlPlano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents Controlazarael2607
 
Automação de _Processos _ Industriais By WEG.pdf
Automação de  _Processos _ Industriais  By WEG.pdfAutomação de  _Processos _ Industriais  By WEG.pdf
Automação de _Processos _ Industriais By WEG.pdfEMERSON EDUARDO RODRIGUES
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de softwareDanilo Gois
 
(2) apostila clp completa
(2) apostila clp completa(2) apostila clp completa
(2) apostila clp completamarcosvida
 
14131394 apostila-clp-completa
14131394 apostila-clp-completa14131394 apostila-clp-completa
14131394 apostila-clp-completajpandradejp
 
Apostila WEG CLP Completa
Apostila WEG CLP CompletaApostila WEG CLP Completa
Apostila WEG CLP CompletaRicardo Akerman
 
Informatica softwares para Eng. Civil
Informatica softwares para Eng. CivilInformatica softwares para Eng. Civil
Informatica softwares para Eng. Civiljcarlosfb
 

Semelhante a Planning Electric Network System Distribution Transmission Areas (20)

x-solutions
x-solutionsx-solutions
x-solutions
 
Plano de Projeto SGS
Plano de Projeto SGSPlano de Projeto SGS
Plano de Projeto SGS
 
Projetode redes
Projetode redesProjetode redes
Projetode redes
 
Plano de Projeto - OUTLAY
Plano de Projeto - OUTLAYPlano de Projeto - OUTLAY
Plano de Projeto - OUTLAY
 
Metodologia de desenvolvimento de sistemas
Metodologia  de desenvolvimento de sistemasMetodologia  de desenvolvimento de sistemas
Metodologia de desenvolvimento de sistemas
 
Plano projeto(final)
Plano projeto(final)Plano projeto(final)
Plano projeto(final)
 
Aulas PPR Semanas 1 2 e 3 _ 18032024 (1).pptx
Aulas PPR Semanas 1 2 e 3 _ 18032024 (1).pptxAulas PPR Semanas 1 2 e 3 _ 18032024 (1).pptx
Aulas PPR Semanas 1 2 e 3 _ 18032024 (1).pptx
 
Portfolio Grupo 4 ADS Unopar Desafios1-2-3-4
Portfolio Grupo 4 ADS Unopar Desafios1-2-3-4Portfolio Grupo 4 ADS Unopar Desafios1-2-3-4
Portfolio Grupo 4 ADS Unopar Desafios1-2-3-4
 
Dfd
DfdDfd
Dfd
 
Plano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents ControlPlano de Projeto de Software do​ Residents Control
Plano de Projeto de Software do​ Residents Control
 
Metodologia
MetodologiaMetodologia
Metodologia
 
(2) apostila clp completa
(2) apostila clp completa(2) apostila clp completa
(2) apostila clp completa
 
Automação de _Processos _ Industriais By WEG.pdf
Automação de  _Processos _ Industriais  By WEG.pdfAutomação de  _Processos _ Industriais  By WEG.pdf
Automação de _Processos _ Industriais By WEG.pdf
 
Plano do projeto de software
Plano do projeto de softwarePlano do projeto de software
Plano do projeto de software
 
(2) apostila clp completa
(2) apostila clp completa(2) apostila clp completa
(2) apostila clp completa
 
Apostila clp completa weg
Apostila clp completa wegApostila clp completa weg
Apostila clp completa weg
 
14131394 apostila-clp-completa
14131394 apostila-clp-completa14131394 apostila-clp-completa
14131394 apostila-clp-completa
 
Apostila WEG CLP Completa
Apostila WEG CLP CompletaApostila WEG CLP Completa
Apostila WEG CLP Completa
 
Modelo plano projeto de sw oo
Modelo plano projeto de sw ooModelo plano projeto de sw oo
Modelo plano projeto de sw oo
 
Informatica softwares para Eng. Civil
Informatica softwares para Eng. CivilInformatica softwares para Eng. Civil
Informatica softwares para Eng. Civil
 

Mais de BelenMonse

Tema 4 clases_y_objetos
Tema 4 clases_y_objetosTema 4 clases_y_objetos
Tema 4 clases_y_objetosBelenMonse
 
Tema 8 polimorfismo
Tema 8 polimorfismoTema 8 polimorfismo
Tema 8 polimorfismoBelenMonse
 
Programa analítico prog ii 17 17
Programa analítico prog ii 17 17Programa analítico prog ii 17 17
Programa analítico prog ii 17 17BelenMonse
 
Sílabo prog ii sistemas 17 17
Sílabo prog ii sistemas 17 17Sílabo prog ii sistemas 17 17
Sílabo prog ii sistemas 17 17BelenMonse
 
Historia del Internet
Historia del InternetHistoria del Internet
Historia del InternetBelenMonse
 
Plan de negocios
Plan de negociosPlan de negocios
Plan de negociosBelenMonse
 
Plan de negocios para hostingnet
Plan de negocios para hostingnetPlan de negocios para hostingnet
Plan de negocios para hostingnetBelenMonse
 
Plan de negocios para empresa de trabajo de campo, en la
Plan de negocios para empresa de trabajo de campo, en laPlan de negocios para empresa de trabajo de campo, en la
Plan de negocios para empresa de trabajo de campo, en laBelenMonse
 
Plan de negocios asdsdf
Plan de negocios asdsdfPlan de negocios asdsdf
Plan de negocios asdsdfBelenMonse
 
El modelo de negocios
El modelo de negociosEl modelo de negocios
El modelo de negociosBelenMonse
 

Mais de BelenMonse (10)

Tema 4 clases_y_objetos
Tema 4 clases_y_objetosTema 4 clases_y_objetos
Tema 4 clases_y_objetos
 
Tema 8 polimorfismo
Tema 8 polimorfismoTema 8 polimorfismo
Tema 8 polimorfismo
 
Programa analítico prog ii 17 17
Programa analítico prog ii 17 17Programa analítico prog ii 17 17
Programa analítico prog ii 17 17
 
Sílabo prog ii sistemas 17 17
Sílabo prog ii sistemas 17 17Sílabo prog ii sistemas 17 17
Sílabo prog ii sistemas 17 17
 
Historia del Internet
Historia del InternetHistoria del Internet
Historia del Internet
 
Plan de negocios
Plan de negociosPlan de negocios
Plan de negocios
 
Plan de negocios para hostingnet
Plan de negocios para hostingnetPlan de negocios para hostingnet
Plan de negocios para hostingnet
 
Plan de negocios para empresa de trabajo de campo, en la
Plan de negocios para empresa de trabajo de campo, en laPlan de negocios para empresa de trabajo de campo, en la
Plan de negocios para empresa de trabajo de campo, en la
 
Plan de negocios asdsdf
Plan de negocios asdsdfPlan de negocios asdsdf
Plan de negocios asdsdf
 
El modelo de negocios
El modelo de negociosEl modelo de negocios
El modelo de negocios
 

Planning Electric Network System Distribution Transmission Areas

  • 1. Abstract— In this project, we developed a computational system based on a framework of geo-referenced data that uses Google Maps technology. The focus is on improving the modeling of information for viewing and embedding technology, human- computer interface (HCI) which includes visualization environments synchronized. The first environment allows you to have the vision of the network elements in the form of electrical single line diagram, representing a consolidated technique in the field of electricity. The second environment called GIS is a map- based navigation with Google Maps that allows the physical location of where it is represented the elements present in the electrical line diagram. This integrated system is capable of supporting the planning of network expansion works in the areas of distribution and transmission of electricity. Keywords— visualization system, GIS, distribution, transmission, system of decision making, planning, google maps. I. INTRODUÇÃO QUALIDADE e quantidade da energia elétrica distribuída pelas concessionárias são influenciadas pelo crescimento da demanda por energia elétrica e pelo desgaste dos elementos que compõem a rede elétrica. O planejamento de obras de expansão e melhoria da rede elétrica é feito pela concessionária para que a demanda por energia possa ser atendida satisfatoriamente. O planejamento, elaborado anualmente pelas concessionárias, precisa atender as exigências dos órgãos reguladores brasileiros. Dessa forma, cada concessionária realiza um planejamento de curto prazo, considerando um período de 10 anos, que é enviado a EPE (Empresa de Pesquisa Energética) e constitui o Plano Decenal de Expansão. A partir do planejamento de todas as concessionárias, a EPE realiza estudos de viabilidade para realização de cada empreendimento proposto. O primeiro passo no processo de planejamento de redes de alta tensão, o planejador realiza um diagnóstico de desempenho técnico da rede existente. Para esse diagnóstico é calculado o fluxo de potência, onde o planejador pode avaliar o carregamento nos trechos e o nível de tensão das barras, chamados critérios técnicos. De acordo com o diagnóstico pode ser necessário propor obras que solucionem as violações dos critérios técnicos, levando em consideração a demanda A. Valerio Netto, Cientistas Desenvolvimento Tecnológico Ltda, Divisão de tecnologia e novos negócios, valerio@cientistas.com.br futura, dados geográficos, políticos e econômicos da região. Assim é possível determinar onde, quando e a capacidade dos reforços a serem incorporados à rede elétrica, visando atender a demanda prevista com menor custo e padrões de qualidade aceitáveis. Atualmente, entre os softwares mais utilizados para o planejamento de redes de distribuição de alta tensão encontram-se o Anarede e o Anafas, desenvolvidos pelo CEPEL, com módulos para cálculo de fluxo de potência e curto circuito, respectivamente. Entretanto esses softwares cobrem apenas a etapa de diagnóstico da rede elétrica, não oferecendo suporte à tomada decisão na escolha das obras que oferecem o melhor custo/benefício. Este projeto vem ao encontro a suprir a necessidade por um software capaz de auxiliar no planejamento de expansão e melhorias de redes elétricas de alta tensão. O software proposto chama-se Interplan-AT Plus e foi baseado no Interplan-AT, software desenvolvido pela empresa Daimon (www.daimon.com.br). Foram acrescentadas novas funcionalidades, como importação e exportação de dados da rede elétrica e novos recursos de visualização e edição da rede elétrica, adicionando suporte ao geo-referenciamento por meio do Google Maps [7]. O Interplan-AT Plus é uma ferramenta para apoio ao planejamento de expansão de redes de distribuição de energia elétrica de alta tensão que pode ser utilizada por engenheiros eletricistas responsáveis pelo planejamento em concessionárias de energia. Para isso, o planejador pode usar o Interplan-AT Plus para importar a estrutura da rede ou construí-la usando o editor gráfico de redes, e identificar as áreas que necessitam de obras de expansão. Ainda usando o editor gráfico de redes, o planejador propõe as obras necessárias à satisfação dos critérios técnicos e econômicos estabelecidos. Como suporte à elaboração de obras de expansão, o Interplan-AT Plus conta com a visão geo-referenciada da rede de alta tensão utilizando o Google Maps. Para usar esse recurso, basta que o planejador insira a localização geográfica (latitude, longitude e elevação) dos elementos elétricos presentes na rede. O Interplan-AT Plus permite ainda a importação e exportação da rede para o formato “.pwf” usado pelo Anarede. Assim as concessionárias podem enviar seu plano de expansão já no formato aceito pelo EPE. A A. Valerio Netto Planning of Network System for the Distribution and Transmission Areas of Electric Energy IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015 345
  • 2. II. METODOLOGIA A metodologia adotada para o desenvolvimento do projeto Interplan-AT Plus é o IVPM2 – Iterative & Visual Project Management Method – traduzido como “Método Iterativo e Visual para Gestão de Projetos”, que se baseia na aplicação dos princípios e práticas do gerenciamento ágil de projetos por meio do uso das estruturas de apoio à gestão de projetos. O método consiste de cinco fases: 1. Visão: determinar a visão do produto, o escopo do projeto, os interessados no projeto, e a definição de como a equipe irá trabalhar, interagir; 2. Concepção: definir entregas, cronograma e o plano de iteração de acordo com a visão; 3. Projeto Detalhado: entregar os componentes do produto (requisitos de projetos pré-definidos na fase da Concepção) em ciclos de entregas reduzidos, minimizando riscos e incertezas; 4. Validação: rever os resultados entregues, analisar a situação atual e o desempenho do time. Adaptar esses resultados se necessário; 5. Encerramento: encerrar o projeto, finalizar tarefas pendentes e transferir as lições aprendidas mais importantes. Na fase de Visão do projeto Interplan-AT Plus foram produzidos dois documentos de requisitos do produto. O primeiro, chamado de Documento de Requisitos do Produto (DRP), contém a descrição resumida do projeto e questões para a identificação dos requisitos do produto, tais como: desempenho, tempo de vida útil, durabilidade, produção estimada, dentre outras. Nesse documento são também abordadas questões a respeito de vendas do produto e estudo de mercado. O segundo documento, chamado de Especificação de Requisitos de Software (ERS), define aspectos como escopo e perspectiva do produto, bem como requisitos de interface com o usuário e funcionalidades do software, de forma resumida. Esses requisitos serão detalhados posteriormente na fase de Concepção. Os principais itens desse documento desenvolvidos na fase de Visão são: 1. Escopo do Software: Contém uma primeira visão do escopo do produto especificado. Deve apresentar informações como: Nome do produto a ser desenvolvido; componentes principais; o que o software fará; o que o software não fará; funções que serão implementadas por outros componentes de um sistema maior, ou versões futuras; e benefícios do produto e valor para o cliente. 2. Perspectiva do produto: Posiciona o produto no contexto em que está inserido. Relaciona as exigências do sistema envolvente com a funcionalidade do software a ser desenvolvido, caso o produto faça parte de um sistema maior. No caso do Interplan-AT Plus, esse item detalha o mercado energético brasileiro, destacando como o software desenvolvido insere-se nesse contexto. 3. Interface de usuário: Define as interfaces entre o produto e seus usuários humanos. Entre elas estão telas, janelas e relatórios. Na fase de Visão é realizada apenas uma descrição geral das interfaces mais importantes. Maiores detalhes devem ser deixados para a fase de Concepção. No caso do Interplan-AT Plus, foram descritas as necessidades de um editor gráfico de redes e integração com o Google Maps. 4. Interface com software: Define as interfaces com outros produtos de software, como aplicativos que recebem ou enviam dados do produto. No caso do Interplan-AT Plus, esse item contém a necessidade de integração com o software Anarede, desenvolvido pelo CEPEL. 5. Funções do produto: Descrever as principais funções do software, de maneira resumida e mostrando o objetivo que será atingido com cada uma. No caso do Interplan-AT Plus, são descritas as principais funcionalidades de apoio ao processo de planejamento de redes de alta tensão. 6. Restrições: Descreve aspectos técnicos e gerenciais que podem limitar as opções de desenvolvimento do software, como restrições legais, limitações de hardware, restrições quanto à linguagem de programação e banco de dados, restrições de desempenho, confiabilidade e segurança. No caso do Interplan-AT Plus, foram considerados aspectos referentes ao ambiente computacional onde o software será usado e medidas e soluções determinadas pelo órgão regulador brasileiro, a Agência Nacional de Energia Elétrica (ANEEL). Os principais objetivos atingidos na fase de Concepção foram o detalhamento dos requisitos iniciais definidos na fase de Visão, escolha das tecnologias usadas no projeto e elaboração do modelo conceitual do produto. Os requisitos descritos resumidamente na fase de Visão são detalhados na Concepção. O documento de Especificação de Requisitos de Software (ERS) é estendido com os requisitos de software em um nível de detalhe suficiente, capaz de permitir aos desenvolvedores projetar um sistema para satisfazer esses requisitos. Os principais itens desse documento desenvolvidos na fase de Concepção são: a) Interfaces de usuários - Descreve detalhadamente os requisitos de interface com o usuário. Cada interface possui: Protótipos de interface; Diagramas de estados, para entender o comportamento exigido da interface; Relacionamentos com outras interfaces; Lista de campos de dados da interface (tipo, formato, validação, restrições); e Lista de comandos da interface (ações, restrições, etc). No Interplan-AT Plus, foram descritas 83 interfaces, incluindo as interfaces para edição da rede (diagrama unifilar) e exibição do diagrama geo- referenciado, abas de exibição dos atributos de cada elemento elétrico da rede, interface para criação de obras, interfaces de exibição dos resultados de fluxo de potência e curto-circuito, interfaces para importação e exportação dos dados do Anarede interface para importação e exportação do banco de dados usado pelo software, entre outros. As interfaces mais relevantes foram detalhadas integralmente, enquanto outras mais simples e intuitivas foram detalhadas durante o Projeto Detalhado. b) Interfaces de software - detalha as interfaces com outros 346 IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015
  • 3. produtos de software. Contém informações como relacionamentos com outras interfaces e formato dos arquivos utilizados. Para o Interplan-AT Plus foi descrito o formato de dois arquivos usados pelo Anarede: “.pwf” para descrição das propriedades dos elementos elétricos e “.lst”, para exibição gráfica dos elementos. Adicionalmente, foi criado um formato próprio – “.ceb” - para importação e exportação dos dados referentes ao ciclo de estudos. c) Requisitos funcionais - Os requisitos funcionais são detalhados usando a técnica de casos de uso, onde cada caso de uso expressa o objetivo que o ator deseja atingir com sua execução. Os casos de uso descrevem por meio de uma linguagem simples as ações fundamentais que precisam ter lugar no software para aceitar e processar as entradas e para processar e gerar as saídas. Descreve também os atores que interagem com o software de maneira direta e indireta. Assim é possível ilustrar o comportamento do software, facilitando a compreensão dos usuários e permitindo a correção de possíveis erros na especificação [5]. No ERS, esse item contém uma descrição visual desses requisitos, chamada diagrama de casos de uso. A descrição de cada caso de uso é apresentada em um documento anexo de especificação de casos de uso. d) Requisitos não-funcionais - Descreve requisitos de desempenho, qualidade e padrões e/ou regulamentações que o produto deve respeitar. Inclui também requisitos lógicos para qualquer informação que será colocada numa base de dados e um esboço inicial do modelo entidade-relacionamento. III. MODELO CONCEITUAL O objetivo do Interplan-AT Plus é oferecer suporte ao processo de planejamento de redes elétricas de alta tensão mapeado durante a obtenção dos requisitos iniciais na fase de Visão. O processo de planejamento é modelado por meio do diagrama de atividades da UML exibido na Fig. 1 e descrito em detalhes a seguir. Figura 1. Diagrama de atividades do processo de planejamento de redes elétricas de alta tensão. 1) Supervisor cria ciclo de estudos: Um ciclo de estudos corresponde ao período de estudos onde os planejadores fazem propostas para expansão da rede no período considerado. Esse ciclo de estudos pode ser criado a partir de uma de rede elétrica ou a partir de um ciclo de estudos anterior já finalizado. Depois de criado, o ciclo de estudos assume estado “Novo”, onde o supervisor pode inserir os dados necessários para que os planejadores iniciem o planejamento. 2) Supervisor insere dados para início do planejamento: Para que os planejadores verifiquem se algum critério técnico é transgredido, é necessário informar os dados de crescimento de demanda para o período de estudo. Nesse momento, o supervisor também pode fazer algumas modificações na rede, em decorrência de alterações nas obras propostas em ciclo anterior feita durante sua execução. Quando todos os dados forem inseridos, o supervisor altera o estado do ciclo para “Aberto”. A partir desse momento, os planejadores possuem todos os dados necessários à proposição de obras. 3) Planejadores realizam diagnóstico da rede: Os planejadores iniciam o planejamento das áreas da rede que das quais são responsáveis. Para isso, o primeiro passo é realizar o diagnóstico da rede através dos estudos de fluxo de potência e curto-circuito. Com base nos resultados desses estudos o planejador verifica quais elementos elétricos transgrediram os critérios técnicos (carregamento, níveis de tensão) e identifica a necessidade de melhoria e expansão da rede. 4) Planejadores propõem obras para rede: Planejador propõe obras (modificações) na rede em estudo para atender as necessidades identificadas no fluxo de potência ou solicitação de novos clientes. Essas obras podem ser obras de expansão, renovação dos ativos e melhoria da qualidade do sistema. O planejador pode propor mais de uma obra (obras alternativas) para resolver um mesmo problema, buscando como a rede comporta-se com cada obra. A obra que satisfaz os critérios técnicos e financeiros é chamada obra proposta. A seguir, a concessionária aprova obras para os primeiros três anos do ciclo de estudos. Após a aprovação, a obra proposta passa a ser chamada obra aprovada. Caso contrário, ela continua sendo considerada proposta. Normalmente, as concessionárias aprovam obras para os próximos três anos. As obras sugeridas para os anos seguintes são chamadas obras referenciais. 5) Planejadores finalizam planejamento: Todos os planejadores submetem as obras propostas, referenciais e aprovadas para todos os anos do ciclo de estudo para supervisor. 6) Supervisor importa obras: Supervisor importa obras exportadas pelos planejadores. Nesse processo pode acontecer que dois planejadores tenham feito modificações em um mesmo elemento elétrico, o que caracteriza um conflito na rede. O supervisor só pode realizar estudos com as obras propostas pelos planejadores quando os conflitos da rede tiverem sido resolvidos. O supervisor pode resolver esses conflitos alterando ele mesmo os elementos da rede que compõem a obra. VALERIO NETTO: PLANNING OF NETWORK SYSTEM FOR 347
  • 4. 7) Supervisor encerra ciclo de estudos: Supervisor encerra período para os planejadores proporem reforços para a rede. Nesse momento o ciclo de estudos possui estado “Encerrado". 8) Supervisor exporta ciclo de estudos: Supervisor exporta dados do ciclo de estudos para o mesmo formato usado pelo Anarede (.pwf + .lst). Assim é possível enviar os dados necessários à EPE. É possível exportar a rede sem obras e a rede com obras propostas, referenciais e aprovadas de um determinado ano. O modelo conceitual faz parte do detalhamento dos requisitos iniciais e usa o diagrama de classes da UML [5] para descrever mais precisamente os conceitos do domínio da aplicação relevantes para o entendimento dos requisitos do produto. A principal base para confecção do modelo conceitual é a descrição do processo de planejamento. As figuras abaixo mostram a modelagem conceitual para ciclo de estudo, elementos elétricos, redes e fluxo de potência do Interplan-AT Plus. Cada classe representa um conceito do domínio da aplicação, e as ligações entre elas indica a relação entre cada conceito. Essa modelagem foi feita usando o software de modelagem Enterprise Architect 7.5 [6]. Define a estrutura arquitetônica principal do produto, dividindo-o em camadas, pacotes lógicos e subsistemas. A arquitetura usada no Interplan-AT Plus é chamada MVC (Model-View-Controller) [1] e divide o produto em três camadas: dados, visualização e controle. As vantagens dessa arquitetura são a modularidade e possibilidade de troca de uma camada, sem impactos nas demais. Além disso, essa arquitetura facilita a distribuição das atividades, permitindo que cada desenvolvedor atue em uma camada específica. Na etapa de projeto detalhado foram implementados os requisitos aprofundados durante a fase de Concepção, respeitando a arquitetura e as tecnologias definidas, mas também fazendo reajustes necessários. A escolha da arquitetura MVC facilita a modularização do software e a distribuição das atividades. Por isso, inicialmente, atuamos em 3 frentes: interfaces, controle e banco de dados. Os requisitos foram priorizados levando em consideração: • Complexidade técnica: indicando a complexidade técnica para implementação do requisito. Cada requisito foi classificado em alta, média e baixa. • Valor agregado ao produto: indicando o valor para o produto do requisito. Cada requisito foi classificado em fundamental, importante e opcional. À medida que se progrediu com a implementação do software, algumas dificuldades surgiram, com relação ao desempenho e também à usabilidade, o que fez com que adotássemos também o outro padrão de projeto – Singleton, para garantir a visualização e sincronia correta entre os dados do DU e do Google Maps. Considerando essa priorização, o primeiro requisito a ser implementado foi a construção da interface principal, incluindo o diagrama unifilar e o diagrama geo-referenciado (Google Maps). Figura 2. 1) Menu Principal; 2) Barra de ferramentas; 3) Barra de ferramentas do diagrama unifilar; 4) Abas para visualização da rede em cada ano do ciclo de estudos; 5) Diagrama unifilar; 6) Diagrama georreferenciado, GoogleMaps[7]; 7) Abas laterais para edição do diagrama unifilar para inserir novos elementos, alterar propriedades e filtrar elementos visíveis no DU; 8) Abas laterais para criação e visualização de obras no ciclo de estudos; 9)Abas inferiores com resultados do fluxo de potência e mensagens de execução do software. IV. RESULTADOS Para implementar a arquitetura do software, foi criada uma camada de acesso aos dados denominada DAO, classes para realização das transações, denominada CONTROL, a camada de representação das entidades, chamada BO, a camada das interfaces, chamada GUI. Além desta arquitetura, durante a fase do projeto detalhado, foi adotado o padrão Singleton, para garantir maior performance na exibição da rede no Google Maps. Foi escolhido o Microsoft Visual Studio 2008 [3] como ambiente de desenvolvimentotraba de software. As tecnologias usadas no Interplan-AT Plus adequadas para essa arquitetura são: • WPF (Windows Presentation Foundation [2]) para a camada de visualização: tem como característica a criação rápida de layouts customizados, interativos e dinâmicos, o que permitindo maior qualidade na interação com usuário. Além disso, permite a separação entre a lógica e a interface, requisito para implementação da arquitetura MVC. • C# para a camada de controle e acesso ao banco de dados: linguagem de programação orientada a objetos, parte da plataforma .NET desenvolvido pela Microsoft. Trata-se de uma linguagem robusta, com a qual a equipe de desenvolvimento já estava familiarizada. • banco de dados PostgreSQL: sistema gerenciador de banco de dados de código aberto, com controle de concorrência no acesso simultâneo aos dados e capaz de armazenar tabelas com até 32 TB [4], utiliza a linguagem SQL. 348 IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015
  • 5. • Crystal Reports para a geração dos relatórios. • Javascript, HTML, CSS, para criação da página de exibição do Google Maps. Foi aprimorada a interface disponibilizando-a nos idiomas português, inglês e espanhol, o qual é definido por meio de uma caixa de seleção na tela de login (Fig. 3). Figura 3. Tela de login e seleção de idioma. Para visualizar os elementos da rede no Google Maps, optou-se por utilizar a API Javascript. Para isto, o primeiro passo foi criar uma página web contendo as funções da API Google Maps, com adaptações para os nossos dados. Figura 4. Tela principal com mapa baseado no Google Maps. Quando uma rede é carregada, existe a função de exibir o mapa com seus elementos. Clicando sobre o ícone do elemento no mapa, são exibidas suas informações de latitude, longitude e o tipo do elemento (Fig. 5). No código C# da aplicação, foi criada uma classe para transferência das informações latitude, longitude, símbolo do elemento elétrico, para a função javascript, de nossa página web. Existe a opção de filtrar os tipos de elementos que são exibidos no Mapa, por meio do componente visual checkbox. Caso não haja nenhum elemento selecionado, é exibida, ou a rede padrão, ou o mapa inicial vazio, devido a limitações do Google Maps. Também existem limitações para o número de acessos e quantidade de componentes que podem ser exibidos, e isto pode variar de acordo com as modificações que são implementadas pelos responsáveis pelo Google Maps. Figura 5. Detalhe do geo-referenciamento. A seguir, foram implementadas as abas para inserção dos elementos elétricos ao diagrama unifilar e para alteração das propriedades dos 15 elementos elétricos. A Fig. 6 mostra a interface principal do Interplan-AT Plus. A aba para inserção de elementos elétricos na rede está localizada na lateral esquerda da tela principal. Para inserir um elemento, o planejador deve selecionar o elemento desejado na lista, e escolher sua localização no diagrama unifilar. Quando isso é feito, a aba de propriedades é habilitada, localizada na lateral direita da tela principal. Assim o planejador pode inserir os dados do novo elemento e salvá-lo no banco de dados. Para elementos elétricos que já fazem parte da rede, a aba de propriedades é alterada de acordo com o elemento selecionado. Nessa aba o planejador pode editar as propriedades do elemento, cancelar a edição iniciada ou remover o elemento da rede. VALERIO NETTO: PLANNING OF NETWORK SYSTEM FOR 349
  • 6. Figura. 6. Aba de propriedades do elemento. Um dos diferenciais do Interplan-AT Plus é a possibilidade de o planejador criar obras para resolver violações de critérios técnicos. Isso é feito através de abas para criação, edição e visualização das obras de um ciclo de estudos. É importante lembrar que essas abas estão disponíveis apenas quando um ciclo de estudos é aberto. Quando apenas uma rede é aberta, apenas os controles para edição da rede são permitidos. Na Fig. 7 é possível ver a tela principal com um ciclo de estudos aberto. Na aba Lista de Obras o planejador pode inserir uma obra, preenchendo propriedades como descrição e custo. Toda obra criada é considerada inicialmente como Alternativa. Quando uma obra é inserida em um ano, automaticamente é persistida nos anos posteriores, e também torna-se visível em cada diagrama unifilar subsequente. Figura 7. Gerenciar obras. Primeiramente, deve-se, no painel de obras, definir as propriedades (nome, descrição, custos adicionais) desta obra, para que então, torne-se possível modificar a rede. O modo de inserção de elementos é o mesmo, seleciona-se o elemento no respectivo painel, arrasta-se para o diagrama unifilar, e a seguir, são preenchidas as propriedades deste elemento elétrico. Um dos pontos importantes deste novo software, é a geração de relatórios de comparação de obras. Utilizou-se a tecnologia Crystal Reports integrada ao Visual Studio para este fim. Por meio de consultas optimizadas ao banco de dados, os relatórios geram as informações detalhadas de custos das obras propostas, organizadas para cada ciclo de estudos realizado. Desta forma, o planejador pode optar pelas obras mais satisfatórias, de acordo com os critérios técnicos e econômicos adotados pela empresa usuária. Figura 8. Relatório de comparação de custos de obras gerado pelo aplicativo. V. CONSIDERAÇÕES FINAIS As principais funcionalidades do projeto Interplan-AT Plus, de acordo com os requisitos identificados, analisados e modelados em conjunto com o potencial cliente, foram implementadas. As funções de cálculo de fluxo de potência, intertravamento entre chaves e outras específicas de manipulação da rede elétrica, bem como regras de negócio para conexão de elementos devem ser realizadas pela empresa parceira Daimon, e entregues na forma de classes ou bibliotecas a serem agregadas ao software. Durante a fase de projeto detalhado, algumas dificuldades foram levantadas: • Uso de WPF: por tratar-se de uma tecnologia nova, boa parte do material disponível aborda conceitos básicos, e tarefas mais complexas com a integração do componente webbrowser, o diagrama de desenho do DU, a interação com javascript, e até mesmo a performance do software quando operando com dados grandes volumes de dados não foram corretamente dimensionados e considerados 350 IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015
  • 7. na fase de concepção; • Fase de concepção abordou muito superficialmente como gerar o diagrama geo-referenciado, o que poderia ter levado ao comprometimento da tarefa. Existem algumas soluções implementadas para aplicações web, porém, por tratar-se de um software que requer grande capacidade de processamento, estabeleceu-se como requisito, que seria uma aplicação desktop. Inicialmente, concebeu-se utilizar arquivos KML. • A ideia de dividir tarefas entre equipes, para implementação da arquitetura MVC, até um certo ponto é interessante, porém, em certas funcionalidades, é praticamente inviável, do ponto de vista prático; • A estratégia de ciclo de desenvolvimento adotada inicialmente, não condiz com os preceitos de uma metodologia ágil, mas sim, tem grande semelhança ao método cascata, onde são definidos os requisitos inicialmente, e só então inicia-se a implementação [8]. Para contornar estas dificuldades procurou-se focar no objetivo a ser alcançado e visando produzir um código bastante modularizado, para facilitar o reuso futuro. No que diz respeito ao WPF, na medida em que tornou-se complicado demais utilizar certos componentes, optou-se por alguma solução alternativa, ou utilizando algum componente pronto, ou utilizando o conhecimento prévio de C# com Windows Forms. A tela inicial, em que era pretendido um comportamento similar à IDE do Visual Studio, com abas que podem ser escondidas, e com redimensionamento automático de conteúdo, foi um destes problemas, e a solução proposta foi o uso da biblioteca Avalon Dock [9]. Esta biblioteca supriu até um certo ponto as necessidades, porém, parece estar ainda incompleta, e após inúmeros testes, com diferentes configurações, optou-se por abrir mão de certas funcionalidades no quesito interface, ganhando, no entanto, no quesito estabilidade. Com relação ao Google Maps, existem inúmeros exemplos de uso, em aplicações web, porém para desktop, para ambiente Microsoft, é raro encontrar informações consistentes, um exemplo é a biblioteca Gmap.NET [10]. Diante da escassez de documentação para que pudéssemos implementar uma solução estável e consistente, nossa busca levou à implementação de uma classe que estabelece comunicação com o browser incorporado no software. Esta alternativa, requereu a criação de uma página HTML que contém um código baseado na API do Google Maps. Nesta página, a função HTML recebe os dados enviados a partir do código C#, previamente formatados. Foi criado um 'parser': uma classe com métodos para codificar os dados num formato aceitável para o código javascript, e no javascript estes dados são novamente decodificados para que sejam exibidos no mapa, nas coordenadas de latitude e longitude, o símbolo do elemento elétrico correspondente. Nesta etapa, já ficou evidenciado que a divisão MVC não é totalmente apropriada para dividir tarefas entre diferentes equipes, delegando a interface para um equipe diferente daquela que implementa o código do modelo, ou de acesso à base de dados. Isto poderia ser utilizado se já fosse sabido de antemão, a forma em que os dados deveriam ser manipulados, assim como a forma de interação com o componente webbrowser. O ponto positivo foi ter alcançado uma solução própria, que torna a equipe detentora deste know-how. Por fim, as fases do ciclo de vida do software, foram concebidas com base num modelo cascata [8] [12], que se caracteriza pela falta de flexibilidade das etapas, e pode até funcionar muito bem em certos tipos de aplicações, mas no caso do Interplan AT Plus, uma metodologia ágil, que combine a necessidade de uma boa especificação do produto, com a flexibilidade de produzir mudanças e adaptações em tempo hábil, com foco maior na geração de código funcional, e por consequência um produto que atenda às necessidades do cliente, do que na criação de documentação [8,11]. Até porque, após o período de dois anos, muito pode mudar e corre-se o risco de produzir um produto obsoleto ao final. Pensando nisto, na fase final, algumas funcionalidades foram mantidas em aberto, para que seja possível a adequação de necessidades específicas de eventuais clientes, e a arquitetura foi sendo ajustada para facilitar a manutenção futura. Do ponto de vista estratégico, a ideia e ter em mãos, além do produto inicialmente proposto para o setor de energia elétrica, uma concepção de solução de software para planejamento inteligente de infraestrutura. Pode-se concluir que o projeto foi bem sucedido. O software produzido é inovador e está sendo apresentado para potenciais clientes. Pessoas foram treinadas nas tecnologias e adquiriram novos conhecimentos, agregando valor à equipe técnica. AGRADECIMENTOS O autor agradece o apoio financeiro do CNPq por meio do programa RHAE Pesquisador na empresa (557812/2008-9) e empresa Daimon (www.daimon.com.br). REFERÊNCIAS [1] Windows Presentation Foundation - http://msdn.microsoft.com/en-us/library/ms754130.aspx – Acessado em 16/06/2010. [2] Freeman, E.T., Robson, E., Bates, B., Sierra, K. Head First Design Patterns. 1ª edição, O'Reilly Media, 2004. [3] Microsoft Visual Studio - http://msdn.microsoft.com/pt- br/vstudio/default.aspx – Acessado em 16/06/2010. [4] PostgreSQL - http://www.postgresql.org/about/ - Acessado em 16/06/2010. [5] Gilleanes T. ª Guedes. UML 2 - Uma abordagem prática. 1ª edição, Editora Novatec, 2009. [6] Enterprise Architect - www.sparxsystems.com/ - Acessado em 17/06/2010. [7] Google Maps – maps.google.com – Acessado em 18/06/2010. VALERIO NETTO: PLANNING OF NETWORK SYSTEM FOR 351
  • 8. [8] Sommerville, Ian, Engenharia de Software, 8ª edição, Addison Wesley, 2007. [9] Avalon Dock - http://avalondock.codeplex.com/ - acessado em 10/03/2010. [10]Gmap.NET - http://greatmaps.codeplex.com/ - Acessado em 05/08/2010. [11]A Nova Metodologia, http://simplus.com.br/artigos/a- nova-metodologia/ Acessado em 10/12/2010. [12]A. Valerio, "Visualization System Integrated for Electric Power Distribution Networks", IEEE LATIN AMERICA TRANSACTIONS, Vol. 8, No. 6, pp. 728-733, Dec. 2010. Antonio Valerio Netto é Doutor em computação e matemática computacional pela Universidade de São Paulo (ICMC/USP). Possui MBA em Marketing pela FUNDACE (FEA-RP/USP). É técnico em informática industrial pela ETEP, Bacharel em computação pela Universidade Federal de São Carlos (DC/UFSCar) e mestre em engenharia pela Universidade de São Paulo (EESC/USP). Em 2001 foi pesquisador visitante na Universidade de Indiana (EUA). Trabalhou cinco anos na área de P&D da Opto Eletrônica S.A. e, posteriormente, dois anos como consultor de novas tecnologias da Debis Humaitá do grupo DaimlerChrysler e um ano na T- Systems, empresa do grupo Deutsche Telekom. Em 2003, fundou a Cientistas, empresa focada no desenvolvimento de produtos tecnológicos, da qual é seu principal dirigente. Em 2007, fundou a primeira empresa de robótica móvel inteligente do país, a XBot, que em 2009 foi considerada pelo Sebrae SP uma das pequenas empresas mais inovadoras do estado de São Paulo. É o coordenador titular do Núcleo de Jovens Empreendedores e coordenador do núcleo regional de inovação do CIESP de São Carlos e região. Foi diretor da seção Brasil do International Council for Small Business (ICSB) e consultor do programa SebraeTec do Sebrae SP entre 2003 e 2005. Possui em torno de 75 publicações entre livros, capítulos de livros, revistas e congressos internacionais e nacionais nas áreas de computação e engenharia. Possui duas patentes. Coordenou em torno de 15 projetos tecnológicos financiados pela FINEP, CNPq, FAPESP e empresas privadas nos últimos cinco anos. Recebeu diversos prêmios e menções honrosas, como a do Society of Automotive Engineer (SAE) Brasil 2001 - melhor artigo técnico na categoria Projetos e de melhor aluno do MBA em Marketing da FUNDACE (FEA-RP/USP) em 2006. Em 2008 foi finalista do prêmio Empreendedor de Sucesso promovido pela revista PEGN e FGV. Em 2009 tornou-se professor honorário da Universidad Abierta Interamericana (Buenos Aires/ARG). 352 IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015