Histórico
Visando experimentar nossa hipótese, foi
elaborado um protótipo inicial do VisciPower.
O propósito nesta etapa inicial, apenas exploratório,
era a visualização de pontos e linhas que representavam
um diagrama unifilar simples, a partir de dados especificados em
um arquivo texto no formato IEEE
Common Data Format.
Nesse primeiro experimento, o objetivo era apenas
visualizar os dados na forma de um diagrama unifilar, mesmo que
de forma rudimentar, sem preocupação formal com simbologias
técnicas (veja figura abaixo). O diagrama unifilar foi escolhido
pois é a representação gráfica com a
qual os engenheiros e operadores estão acostumados a trabalhar.
Esboço inicial da interface, teste com sistema
de 14 barramentos
Os dados que previam a geração e
o carregamento do sistema (referentes ao pré-despacho) ao
longo do dia ainda não eram utilizados, tampouco informações
sobre as localizações geográficas. As informações
eram lidas a partir do arquivo do IEEE
Common Data Format e a partir delas eram construídos
os diagramas. Na época do experimento, foi necessário
o acréscimo de mais dois campos de informação
para os barramentos no arquivo do IEEE, para que contemplassem suas
coordenadas geográficas bidimensionais. Os barramentos eram
exibidos diretamente a partir destas coordenadas, e os ramos construídos
em seguida, segundo informações do arquivo sobre a
conectividade entre os barramentos. Mais tarde estas informações
gráficas foram separadas em um outro arquivo para não
comprometerem o formato padronizado pelo IEEE e também para
a composição de uma arquitetura mais organizada e
eficiente.
O uso de dados de conectividade provenientes do
arquivo de dados na tentativa de se gerar as linhas de transmissão
gerou problemas de cruzamento entre os ramos, num clássico
problema de roteamento. Nesse ponto houve um grande esforço
para se encontrar um algoritmo ideal para o roteamento entre os
barramentos. No entanto, esses algoritmos se mostraram demasiadamente
complexos para o objetivo principal do projeto, a visualização
de sistemas geralmente invariantes no tempo, no que diz respeito
a sua disposição geográfica, para auxiliar
no planejamento de ações no pré-despacho de
energia elétrica.
Devido às dificuldades com o roteamento
dos barramentos, ficou decidido que essa não seria mais uma
preocupação: as informações gráficas
(coordenadas geográficas dos barramentos e ramos)
seriam extraídas diretamente de um mapa, manualmente. Portanto,
a trabalhosa tarefa de se definir as coordenadas dos pontos
que irão formar os barramentos e os ramos se dará
apenas uma vez, na criação do diagrama. Podem
haver alterações, mas estas, quando ocorrem, são
muito raras. A princípio, como não possuíamos
estas informações, a aquisição
das coordenadas geo-referenciadas foi feita manualmente, com o auxílio
de uma simples régua. Futuramente esperamos que estas informações
geo-referenciadas, especialmente as referentes ao sistema
elétrico brasileiro, estejam disponíveis em um banco
de dados.
A parte de interação do usuário
nessa fase se limitava apenas a formas de visualização
diferentes para os mesmos dados (deslocamento e zoom),
ou seja, o usuário não podia ainda alterar nenhum
valor das grandezas do sistema.
Esta etapa inicial de experimentação,
repleta de tentativas, fracassos e retrabalhos, foi útil
para mostrar os pontos que deveriam ter maior ênfase na modelagem
dos dados e que ditariam o rumo para alcançar o objetivo
principal do projeto.
Vencida a primeira barreira da familiarização
com os dados e requisitos do sistema, foi o momento de se incrementar
o protótipo de interface, adicionando funcionalidades e dados
importantes obtidos das interações com os especialistas
da área energética.
O objetivo da segunda etapa foi aperfeiçoar
a interface, aproximando-a mais do modelo mental exigido pelos usuários,
adicionando dados considerados importantes e destacando possíveis
pontos onde esses dados acarretariam problemas para o sistema elétrico.
Pequenos gráficos em forma de "pizza"
(piecharts) foram posicionados no centro das linhas, representando
a porcentagem do carregamento da linha naquele momento (figura abaixo).
A estratégia adotada para destacar os pontos de sobrecarga
foi exibir o gráfico com uma cor que chamasse mais a atenção
do usuário; em nosso caso adotou-se a cor vermelha.
Segunda evolução da interface,
exemplo com 30 barramentos
Uma das principais interações foi
a terceira etapa, cujo objetivo principal foi classificar as informações
envolvidas no pré-despacho para formar uma arquitetura de
\emph{software} mais organizada e criar uma interface que se aproximasse
mais dos requisitos dos usuários. Ao trabalhar com uma grande
quantidade de informação, a organização
e a categorização dos dados desempenham um papel de
vital importância em seu gerenciamento. Os dados foram então
organizados em três arquivos distintos, no formato ASCII:
um para dados elétricos persistentes, originados dos arquivos
originais do IEEE; outro para os dados elétricos específicos
do pré-despacho (gerações e demandas previstas,
ao longo do período de tempo considerado) e um terceiro
apenas com as informações gráficas necessárias
à exibição do diagrama unifilar geo-referenciado.
Nesta interação, a interface sofreu
uma significante alteração para refletir a nova organização
dos dados, e foi dividida em duas janelas. A janela principal do
protótipo (figura abaixo), subdividida em três partes,
exibia do lado esquerdo dois gráficos cartesianos, um para
a demanda total de carga ativa do sistema (em MW) ao longo do horizonte
de tempo considerado e outra para os carregamentos médio
e total nas linhas de transmissão, em porcentagem, também
ao longo do período de tempo estudado. Do lado direito estava
a visão geral do sistema elétrico em forma de diagrama
unifilar, destacando os pontos problemáticos do sistema com
cores, só que desta vez com relação a um instante
de tempo t especificado nos gráficos adjacentes.
De acordo com o que observasse nesta janela, o usuário poderia
abrir uma janela onde maiores detalhes do sistema eram exibidos,
além de poder navegar pelo sistema (através de zoom
e centralização de regiões de interesse) e
exibir alguns dados na tela. Esta janela foi criada separadamente
de forma a concentrar as funcionalidades de navegação
e detalhamento, numa visão distinta da visão geral
da janela principal.
Janela principal da terceira geração
do VisciPower
Na quarta etapa, o objetivo foi implementar o simulador
(baseado no modelo simplificado que
propusemos) integrado à interface, com o propósito
de adicionar interação do usuário com os dados
de pré-despacho. Além disso, todas as evoluções
obtidas nas interações anteriores foram integradas
para testar diferentes configurações.
Apesar dos poucos usuários com os quais
estávamos trabalhando já se mostrarem bastante satisfeitos
com os resultados das interações anteriores, novas
evoluções eram necessárias para o aperfeiçoamento
do projeto. Durante a quinta etapa propomos trabalhar com um sistema
de teste mais volumoso, visando testar a robustez do sistema e saber
como ele se comportaria com um volume maior de dados. Não
possuíamos dados de sistemas elétricos reais, principalmente
os dados gráficos. Alguns casos de teste maiores, no formato
IEEE
Common Data Format, estavam disponíveis, no entanto
eram de difícil legibilidade, apresentavam inconsistências
e, além disso, não forneciam as informações
gráficas e de pré-despacho necessárias. Com
o auxílio dos especialistas da área de planejamento
energético, conseguimos diagramas unifilares mais legíveis
para os casos de 57 barramentos e 118 barramentos. Identificamos
que os sistemas de 30 e de 57 barramentos eram subconjuntos do sistema
de 118 barramentos. Com algumas edições gráficas
e muito trabalho manual, foi possível mesclar, eliminando
as redundâncias e acrescentando novos dados, todas as informações
destes sistemas em um único caso de teste, que resultou com
176 barramentos. A partir deste novo sistema de teste extraímos
(também manualmente) as informações gráficas
e de pré-despacho para serem armazenadas em arquivos.
O escopo de nosso modelo começaria a se
fechar durante a sexta etapa. Determinamos que um dos principais
objetivos do projeto seria o apoio à localização
geográfica de áreas com problemas operativos
em relação à carga ativa. Localizando estas
áreas de forma rápida e precisa, o operador poderia
calcular qual seriam os possíveis efeitos de alterações
em determinados pontos do sistema. Nosso modelo permitiria que o
usuário partisse de uma análise primeiramente qualitativa
do sistema (identificação dos pontos problemáticos)
para uma análise quantitativa (mudança de valores
de geração para simulação), num processo
iterativo.
Com a utilização de grande quantidade
de dados, percebemos que havia uma certa "poluição"
visual ao visualizarmos o sistema elétrico de uma forma geral.
O destaque de potenciais problemas nas linhas de transmissão
ao longo do diagrama unifilar não era visualizado de forma
legível, comprometendo a agilidade na tomada de decisões
por parte dos usuários.
Percebendo a existência de níveis
de hierarquia dentre os dados representados, foi possível
se pensar em uma melhor estratégia de visualização.
Aplicamos uma técnica simples de multirresolução,
que consiste numa hierarquia de visualização, exibindo
diferentes níveis de detalhamento para um mesmo conjunto
de dados. O parâmetro escolhido para representar esta hierarquia
foram os níveis de tensão, refletindo a própria
estratégia real de análise utilizada pelos engenheiros
de pré-despacho: existe um tronco de transmissão (circuito)
de nível de tensão mais alto que leva a energia ou
para subestações repetidoras ou para subestações
que reduzem o nível de tensão para a sub-transmissão;
estas, por sua vez, podem ir a outras subestações
transformadoras que podem reduzir a outro nível de tensão,
até alcançar o sistema de distribuição,
ou consumidores finais de grande porte. Portanto, a análise
do sistema elétrico é realizada de acordo com o nível
de tensão, do mais alto para o mais baixo. A incubência
de filtrar os dados foi dada ao próprio usuário, para
que ele reproduza, em alto nível, o mesmo processo mental
que ele utiliza na elaboração de um pré-despacho.
Com a possibilidade de filtragem por níveis
de tensão, surge um problema: se a linha de transmissão
com potenciais problemas não estiver no nível de visualização
corrente, teoricamente ela não seria visualizada. No entanto,
isso fugiria de nosso objetivo de exibir todos os possíveis
problemas da rede de forma rápida e objetiva. A solução
adotada para esta questão foi utilizar um atributo gráfico
sobre a linha que apresentar problemas, independente do nível
de visualização em que o usuário esteja.
Nas etapas finais ocorreram outras evoluções
relativas à organização do modelo de dados.
Para refletir a estrutura relacional dos dados e também pensando
na futura manipulação de dados mais volumosos, adotamos
um Sistema Gerenciador de Banco de Dados (SGBD). O principal objetivo
de um SGBD é proporcionar um ambiente tanto \emph{conveniente}
quanto \emph{eficiente} para a recuperação e armazenamento
das informações armazenadas em um banco de dados.
Optamos pela utilização do MySQL,
o mais popular sistema de gerenciamento de banco de dados de código
aberto e multiplataforma.
Confira o resultado clicando aqui! |
