XXII Seminário Nacional de Distribuição de Energia Elétrica

SENDI 2016 - 07 a 10 de novembro

Curitiba - PR - Brasil

Marcos de Almeida Leone Filho Venidera Pesquisa e Desenvolvimento Ltda. marcos@venidera.com

Rafael Giordano Vieira rafael@venidera.com

Makoto Kadowaki makoto@venidera.com

Andre Emilio Toscano andre@venidera.com

Sergio Augusto Alves Altieri ELEKTRO - Eletricidade e ServIços S.A sergio.altieri@elektro.com.br

Ricardo Marcos Garvizu Flores ricardo.flores@msppar.com.br

Antonio Kazuo Koga kazuo.koga@msppar.com.br

Robinson Semolini ELEKTRO - Eletricidade e ServIços S.A robinson.semolini@elektro.com.br

BID-MONITOR: O balanço energético das distribuidoras e geradoras apoiando o processo de tomada de decisão

em leilões de energia elétrica.

Palavras-chave

balanço energético

big-data

leilões de energia elétrica

séries temporais

Resumo

Este trabalho propõe uma metodologia para apoiar o processo de tomada de decisões em leilões de energia

elétrica que tem como objetivo fornecer uma ferramenta de apoio que ajude a reduzir estas incertezas deste

processo e, com isto, contribui para um planejamento de longo prazo mais assertivo tanto do mercado de

energia elétrica, como da expansão dos sistemas elétricos das empresas cooperadas.

Esta metodologia é baseada na construção de uma grande base de dados estruturada e organizada do setor

elétrico cujas análises geradas a partir dela terão condições de gerar insights e dicas para os colaboradores

envolvidos no processo de tomada de decisões em leilões de energia elétrica.

1. Introdução

O processo de tomada de decisão em leilões de energia é quase sempre um processo bem complexo e

que envolve grandes incertezas. Seja para um comprador ou para um vendedor de energia elétrica,

sempre é difícil tomar a decisões relativas à compra ou venda de energia elétrica. Com isto, uma decisão

mal tomada pode acarretar perdas financeiras enormes. Esta dificuldade de tomada de decisão ocorre,

principalmente, devido à influência não somente de variáveis diretamente associadas ao contexto do

1/10

negócio de comercialização de energia, mas também devido a variáveis conjunturais e macroeconômicas.

Assim, a quantidade de dados e variáveis que devem ser analisadas para construir uma decisão mais

assertiva é tão grande que um analista não tem condições analisar tudo que pode impactar sua decisão de

compra ou venda de energia elétrica, tanto por dificuldades técnicas de análise como por indisponibilidade

de ferramental computacional adequado.

Entretanto, é sabido que há muita informação (em diversas diferentes fontes) disponível publicamente na

internet que pode dar apoio a este processo de tomada de decisão, mas há grandes desafios no que diz

respeito à coleta, organização e armazenamento para viabilizar a realização de tais análises. Desta forma,

foi investigado e descoberto durante a execução desta pesquisa que esta estruturação e organização dos

dados são os pilares para que qualquer tipo de análise possa ser realizada com estes dados.

Neste contexto, a proposta deste projeto de Pesquisa e Desenvolvimento (P&D) é a de criar um arcabouço

tecnológico que forneça condições que estas análises sejam realizadas em tempo real ou adequado à

analise.

2. Desenvolvimento

Coleta e organização de dados

O conceito básico do projeto de P&D BID-MONITOR é o de construir uma base de dados que contará com

o maior número possível de informações do setor eletro-energético brasileiro e também de outras fontes

exógenas, como variáveis climatológicas e macroeconômicas. A construção desta base proporcionará

condições de realizar diversas análises relacionadas ao processo de tomada de decisão em leilões. Não

menos importante, é a capacidade deste sistema de dados responder às requisições de leituras em tempo

computacional mínimo de maneira que torne tais análises viáveis (uma análise pode necessitar de

centenas de requisições de leitura da base).

Desta forma, é importante destacar que a maior parte das informações serão capturadas de dados

públicos que são disponibilizados diretamente na rede mundial de computadores (internet) através da

programação de softwares de computador chamados de "web crawlers" (veja descrição na seção a seguir).

Contudo, qualquer dado capturado da internet tem o seu formato específico (uma página HMTL, um

arquivo PDF e um arquivo MS-Excel são alguns exemplos), o que faz com que seja necessário extrair as

informações específicas que se deseja analisar e, sobretudo, colocá-las em um formato padrão para que

sejam armazenadas na base de dados de forma coerente e organizada. Para esta finalidade, foram

construídos algoritmos de "parsing" (veja descrição na seção à seguir).

2/10

Assim, uma vez capturados e processados (cada dado será capturado na mesma frequência que ele for

disponibilizado na internet, seja minuto a minuto ou mensalmente), estes dados serão gravados um uma

base de dados de alto desempenho em servidores de alta performance na "nuvem" (como Amazon AWS,

Heroku ou Red Hat Openshift).

Portanto, o sistema de coleta, organização e armazenamento de dados pode ser resumido

esquematicamente como é mostrado à seguir.

Figura 1: Sistema de coleta, organização e armazenamento de dados

Como pode ser visto na Figura 1, um exemplo esquemático de coleta de dados é ilustrado. No caso, o

objetivo é armazenar as séries de dados dos resultados dos leilões de energia elétrica da CCEE (Câmara

Comercializadora de Energia Elétrica) organizados por data, montante, número do contrato, entre outros.

Para alcançar este objetivo, o local no site da CCEE onde há os dados consolidados dos leilões de energia

elétrica é explorado pelo "web crawler" que é programado para baixar e salvar na base de dados a planilha

MS-Excel que contém estes dados. Em seguida, o "parser" analisa a planilha, extrai os dados relavantes,

organiza e salva-os no banco de dados que contém todas as informações que estão ordenadas e

organizadas (ou seja, que já passaram por um "parser").

"Web Crawlers"

Um "web crawler", ou "rastreador web" (tradução mais próxima para o português), é um programa de

computador que navega pela rede mundial de computadores de uma forma metódica e automatizada

(também são chamados de indexadores automáticos, bots, web spiders, Web robot, ou Web scutter). O

processo que um "web crawler" executa é chamado de "web crawling" ou "spidering" (Heaton, 2002).

Desta forma, muitos sites, em particular os motores de busca, usam "crawlers" para manter uma base de

dados atualizada (navegando por toda a rede de computadores e criando cópias nas bases de dados dos

servidores destes motores de busca). Os "web crawlers" são principalmente utilizados para criar uma cópia

de todas as páginas visitadas para um pós-processamento por um motor de busca que irá indexar as

páginas baixadas para prover buscas mais rápidas (Cheong, 1996).

3/10

Com isto, foram programados "web crawlers" específicos para cada fonte de dados (com exceção dos

casos dos serviços de internet que possuem API - nestes casos, os dados podem ser coletados

programaticamente). Desta forma, quando se deseja, por exemplo, baixar uma planilha com dados

consolidados das distribuidoras de energia elétrica do site da CCEE, um "web crawler" que navega no site

da CCEE e baixa a referida planilha teve que ser programado para coletar esta planilha específica.

"Parser"

Um "parser" (também conhecido como "analisador sintático") é um componente de software que usa dados

de entrada (no caso deste projeto, pode ser, por exemplo, um arquivo MS-Excel) e constrói uma estrutura

de dados (uma árvore de análise, uma árvore de sintaxe abstrata, uma estrutura hierárquica e uma série

temporal são alguns exemplos) dando uma representação estrutural da entrada com verificação de sintaxe

apropriada durante este processo. A análise sintática pode ser precedida ou seguida por outros passos ou

estes podem ser combinados num único passo. Assim, o analisador é, muitas vezes, precedido por um

analisador lexical separado, o que cria "tokens" (ou marcadores) da sequência de caracteres de entrada.

Alternativamente, estes podem ser combinados na análise sintática sem varredura. Com isto, analisadores

pode ser programados à mão ou podem ser gerados de forma automática ou semi-automática por um

gerador de analisador. Ainda é importante destacar que o "parsing" é complementar à atividade de

"templating", que produz saída formatada de acordo um "template" (que pode ser, por exemplo, uma série

de datas e valores, ou seja, uma série temporal).

Sistema de armazenamento de dados

O armazenamento de dados de um sistema como o utilizado no projeto de P&D BID-MONITOR exige que

sejam aplicadas múltiplas tecnologias com a finalidade de prover desempenho suficiente de escrita e

leitura de dados que possam suportar e amparar a coleta de centenas de milhares de unidades de

informação por segundo e a leitura de quantidades ainda maiores de dados (muitas vezes preprocessados,

que possam ser aplicados para uso em ferramentas de análise e visualização dos dados armazenados)

atendendo, assim, os requisitos estabelecidos pelos objetivos definidos para o sistema desenvolvido neste

P&D. Logo, diversos desafios se apresentam na definição do que poderia ser entendido como um banco

de dados.

A acepção do termo "banco de dados" é comumente associado à utilização de sistema computacionais de

bancos de dados de paradigma relacional, nos moldes do proposto por Codd (1970) em que um modelo de

dados é definido segundo o estabelecimento de entidades e relacionamentos em um modelo lógico que

descreve as unidades de informação e suas associações. Entretanto, no período de 1999 a 2005 o termo

"Web 2.0" começou a ser utilizado em revistas e conferências para descrever o padrão ou mais

precisamente o conjunto de previsões estabelecido para o uso da internet com a entrada massiva de

usuários e dispositivos na rede e o surgimento de mídias sociais. Dentre os diferentes aspectos

conjecturados para o que viria a ser a a rede mundial de computadores (Wold Wide Web) o mais

4/10

expressivo é o de que o número de geradores de conteúdos cresceria de forma abrupta, o que hoje

verificamos com as redes sociais, IoT (Internet of Things) e uso de ferramentas de Big Data. Assim,

considerando estimativas simples foi possível prever que as bases de dados relacionais não atenderiam às

necessidades de uso vindouras, dadas suas necessidades de armazenamento e custo computacional de

atendimento dos preceitos de consistência (relacionamentos e chaves).

Assim, visando atender às necessidades futuras identificadas surgiram tecnologias como a computação

em nuvem, que basicamente passa a prover poder computacional como um recurso agrupado,

massivamente automatizado, virtualizado, paralelo e passível de crescimento com a adição de mais

computadores. Da mesma maneira, os bancos de dados também adaptaram-se as aplicações previstas e,

assim, passaram a ter como requisitos o suporte a massas de dados e acessos em grande e crescente

volume. A estes bancos de dados foi denominado o acrônimo de categoria NoSQL, que inicialmente era

entendido pela qualidade de não prover a linguagem de pesquisa (Strucured Query Language,

(Chamberlin, et al., 1974) e que mais tarde passa a ser referido como "Not-only-SQL", visto que são

apresentadas implementações da linguagem nos produtos que seguem preceitos NoSQL.

Os bancos de dados NoSQL abrem mão do atendimento aos requisitos ACID (das bases de dados

relacionais), porém fornecem aos desenvolvedores uma maior flexibilidade no estabelecimento de

infraestruturas complexas e eficientes para o armazenamento de dados, o que foi um requisito exigido para

a composição do que podemos chamar de base de dados do projeto BID-MONITOR.

Com isto, para criar um ambiente de armazenamento de dados eficiente para grandes massas de dados,

foi necessária a composição de diferentes bases de dados NoSQL, cada uma com uma finalidade, além de

componentes que orquestram entrada e saída. Assim, descrevemos abaixo os componentes aplicados à

implementação da base de dados:

1.MongoDB e OrientDB: aplicados no armazenamento de documentos ou informações isoladas tais

como as obtidas como arquivos de dados ou documentos. Os documentos são geolocalizados por

padrão;2. OpenTSDB: consiste em um ambiente completo de gerenciamento de séries temporais que utiliza o

HBase como base de dados;3. Neo4J e OrientDB: os dados são associados através de grafos, assim, documentos, séries

temporais, arquivos e quaisquer outros conjuntos de dados podem se relacionar através de

conexões (ou arestas do grafo);4. Elasticsearch: utilizado para a indexação e buscas;5. Redis: aplicado na indexação e cacheamento de informações para leitura.

5/10

As entradas e saídas de dados são realizadas por APIs RESTful assíncronas que possibilitam que os

acessos aos dados possam ser padronizados em requisições formatadas e que possibilitam o atendimento

de volumes elevados de pedidos de escrita e leitura dos dados.

Utilizando uma estrutura variada de componentes aplicados para atividades definidas é possível gerar uma

plataforma robusta e eficiente ao atendimento das necessidades de armazenamento do projeto de P&D

BID-MONITOR.

Além disto, o modelo de dados assumido tem características multi-modelo, dado os tipos de dados

estruturados e não estruturados que são armazenados na forma de um grafo conexo. Neste contexto,

diferentes entidades coexistem e se relacionam e tanto as entidades como os relacionamentos constituem

objetos de dados com características próprias (rótulo, formato e valor dos dados). Assim, foi projetado um

modelo baseado em elementos chamados de "Entidade Principal" (nó ou vértice do grafo) e de "Entidade

Relacionadora" (aresta do grafo), com ambos podendo armazenar dados no formato chave/valor. Para

cada tipo de "Entidade" temos o conjunto de propriedades (veja diagrama abaixo): Chave única no sistema

(Internal_id), chaves únicas diversas para uma entidade (IDs), dados (Data), metadados (Metadata

), geolocalização (GeoLocation) e um tipo qualquer que pode ser arbitrado para fins de agrupamentos de

entidades. O diagrama apresentado na figura abaixo ilustra o modelo de grafo adotado.

Figura 2: Diagrama do modelo de grafo.

Visando exemplificar o modelo proposto podemos nos remeter à planilha de leilões consolidados da

CCEE. Neste caso, tomemos como entidades principais um gerador de energia e um comprador

(comercializadora ou distribuidora) e como uma entidade relacionadora a que é definida por um contrato.

Análise de dados

A análise dos dados coletados nesta primeira fase do projeto BID-MONITOR foi norteada pelo objetivo de

conseguir detectar, no caso de uma distribuidora de energia elétrica, por exemplo, diferenças entre o total

de energia contratada versus a carga de energia elétrica prevista para sua área de concessão.

Assim, para alcançar este objetivo, a técnica foi simples. O algoritmo de "parsing" deveria converter

qualquer dado encontrado em qualquer fonte de informação no formato de uma série temporal diária de

potência média (em MW médios) com data de início e fim determinado pelo contexto do dado coletado (se

6/10

o dado é um contrato de energia elétrica, a data de início é o início da vigência do contrato e a data final é

o fim da vigência do contrato). Com este exemplo simples de um contrato transformado em série temporal,

fica simples ver o desafio do tamanho do conjunto de dados gerado e a necessidade da utilização das

ferramentas apresentadas na seção anterior. Para exemplificar, façamos uma aproximação de cálculo para

ter ideia da necessidade de armazenamento para uma simples planilha de leilões consolidados da CCEE

(que é atualizada mensalmente e tem um tamanho médio de 12MB) que possui em torno de 24mil

contratos que, em média, duram 20 anos:

(24.000 contratos) x (20 anos) x (365 dias) = (175.200.000 registros)

Tendo em vista que cada registro precisa armazenar uma data, um valor, uma métrica e um metadado

associado temos:

(32 bytes por registro) x (175.200.000 registros) = 5.606.400.000 = 5,6064 GB

Portanto, usando este conceito básico de transformar dados em séries temporais, ao somar ponto-a-ponto

as séries temporais de n contratos, é possível obter o total (em MW médios) destes n contratos em um

determinado intervalo de tempo (dias, semanas, meses, etc.). Entreanto, aqui, mais uma vez, fica claro o

desafio de realizar tal somatório dado o tamanho do conjunto de dados que está sendo analisado

Balanço Energético

Com o conceito básico de criar e somar "ponto-a-ponto" séries temporais, foi possível, por exemplo, para

um dado agente do setor elétrico, calcular dia a dia o total de potência disponível para suprimento e

contrastar este valor com, por exemplo, uma previsão de carga para o mesmo período. A diferença entre a

previsão de carga e o total de potência disponível é o que é chamado de "balanço energético". Entretanto,

como muitos agentes sabem, a tarefa mais difícil é computar o total de potência disponível, pois ela

depende dos seguintes dados:

1.Total de energia contratada nos leilões de energia elétrica (disponível no site da CCEE);

2. Atrasos no início de suprimento dos geradores novos (disponível no site da ANEEL, ONS, PSR e

processos judiciais);3. Total de energia contratada através de contratos bilaterais (disponível no site da ANEEL);4. Cotas do PROINFA (disponível no site da CCEE e da ANEEL);5. Cotas de garantia física (disponível no site da ANEEL);6. Cotas da UHE Itaipu (disponível no site da ANEEL);7. Cotas das usinas de Angra I e Angra II (disponível no site da ANEEL).

Com isto, para cada um destes dados, foram construídos "web crawlers" e algoritmos de "parsing"

específicos, conforme mostra o diagrama a seguir.

7/10

Figura 3: Fluxo de coleta, armazenamento e organização dos dados para a computação do balanço

energético

Com esta infraestrutura de dados foi possível construir o balanço energético da Elektro, como mostra o

gráfico à seguir.

8/10

Figura 4: Balanço Energético da Elektro entre 2016 e 2020

Entretanto, a mesma infraestrutura de dados proporcionou realizar vários outros tipos análises. O gráfico à

seguir mostra a comparação do total contratado por diferentes distribuidoras do setor elétrico brasileiro.

Figura 5: Total contratado por distribuidora no ano de 2016

3. Conclusões

A metodologia proposta neste trabalho se mostrou extremamente eficaz e flexível no processo de cálculo

do balanço energético dos agentes do setor elétrico brasileiro, sendo, sobretudo, capaz de computar

balanços energéticos e diversas outras análises para cada agente em poucos minutos quando feito por um

analista. Entretanto, futuramente, estas análises serão computadas de maneira sistemática e o resultado

9/10

desta computação será reportado ao analista na forma de um alerta, fazendo com que esta computação

consuma apenas alguns poucos segundos de processamento e não seja perceptível ao analista, uma vez

que ela será realizada automaticamente do lado do servidor (não visível ao usuário).

Além disto, nas próximas etapas deste projeto de pesquisa, novos dados serão adicionados à base de

dados e, com isto, novas análises serão geradas.

4. Referências bibliográficas

Biggs, N.; Lloyd, E. and Wilson, R. (1986), "Graph Theory", 1736-1936, Oxford University Press.

Chamberlin, Donald D; Boyce, Raymond F (1974). "SEQUEL: A Structured English Query Language

" (PDF). Proceedings of the 1974 ACM SIGFIDET Workshop on Data Description, Access and Control

(Association for Computing Machinery): 249–64.

Cheong, Fah-Chuh (1996). "Internet Agents. Spiders, Wanderers, Brokers and Bots", Indianapolis, New

Riders, p. 84-88. ISBN 1-56205-463-5.

Codd, E.F. (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM

13 (6): 377–387. doi:10.1145/362384.362685.

Heaton, Jeff (2002). "Programming Spiders, Bots, and Aggregations in Java", San Francisco, Sybex, p. 350-

352. ISBN 0-7821-4040-8.

_________________________________________

10/10