Resumo — Este artigo tem como objetivo descrever as tecnologias utilizadas na construção da plataforma de balcão organizado do projeto da ANEEL P&D, Código 0064-1059/2019, intitulado “Desenvolvimento de Plataforma para Operação de Balcão Organizado de Comercialização de Energia”, e, publicamente, Projeto AES Brasil de Energy Intelligence, que está sendo gerido pelas empresas Fohat Corporation e AES Brasil. As tecnologias utilizadas abrangem diferentes soluções de arquitetura e engenharia de software que juntas entregam as funcionalidades esperadas em uma plataforma de comercialização de energia. Desde o desenho da arquitetura de software até a escolha das tecnologias adotadas no projeto, levou-se em conta questões de segurança, performance e escalabilidade, que fornecerão maior estabilidade e confiança para os usuários da solução realizarem operações financeiras na solução desenvolvida.

Palavras-chave — Desenvolvimento de Software. Arquitetura de Software. Contêineres Docker. Python. Amazon Web Services.

I.  Introdução

No desenvolvimento de software são inúmeros os desafios que arquitetos e desenvolvedores possuem a fim de atender aos requisitos que entregarão o valor esperado ao projeto através da solução tecnológica criada. Assim, o time de desenvolvimento, depois de entender os requisitos do produto, define a arquitetura, as tecnologias e linguagens que irão compor a solução a ser criada. Este processo é de crucial importância, pois são estes componentes tecnológicos responsáveis pelo bom desempenho e qualidade das funcionalidades do projeto, principalmente em relação à consistência e segurança das operações financeiras realizadas na plataforma. O objetivo deste artigo é de tornar claro os desafios e soluções implementadas para o desenvolvimento da plataforma de balcão organizado do projeto da ANEEL P&D.

II.  Ambientes de Contratação de Energia

O Ambiente de Contratação Regulado (ACR), também conhecido como Mercado Cativo, é o segmento do mercado no qual se realizam as operações de compra e venda de energia elétrica entre agentes vendedores e agentes de distribuição. Nesse mercado, os consumidores não possuem o direito de escolha sobre o preço de compra nem sobre o seu fornecedor de energia, tendo suas tarifas reguladas pelo governo.

Já o Ambiente de Contratação Livre (ACL), objeto de trabalho neste projeto P&D, trata-se do segmento do mercado que permite que consumidores comprem energia elétrica diretamente dos agentes geradores e empresas comercializadores através de contratos bilaterais livremente negociados. Ambos os mercados são regulados de acordo com o Decreto nº 5.163, de 30 julho de 2004.

III.  Plataforma de Balcão Organizado de Comercialização de Energia

Uma plataforma de balcão de comercialização de energia trata-se de um ambiente digital para que vendedores e compradores negociem contratos de energia entre si (também chamada de Home Broker). Esse tipo de plataforma prove maior transparência de preços e velocidade na realização das operações de compra e venda para os participantes do mercado e, consequentemente, propicia uma maior liquidez na negociação de contratos de energia no Ambiente de Contratação Livre (ACL). O vendedor em um mercado de balcão de energia pode ser um gerador (que atue no ACL), comercializador de contratos de energia ou um consumidor livre que possua excedente de energia. O comprador, de igual modo, também pode ser um gerador, comercializador ou consumidor livre.

Espera-se que uma plataforma dessa natureza tenha confiabilidade e seja à prova de invasão, adulteração, ruptura e ou alteração de dados. No entanto, também há o risco de default, que uma plataforma como essa deve solucionar, ou seja, quando uma das partes do contrato bilateral não cumpre com o acordado. No mercado brasileiro de Energia, por exemplo, há o recente caso da comercializadora Vega Energy que, por não realizar apropriada gestão de risco de suas operações, deixou de honrar com cerca de R$ 200 milhões em contratos de venda de energia [2].

Esse risco de mercado poderia ser mitigado com a existência de uma câmara de compensação de contraparte central. Normalmente operada por uma instituição financeira, essa entidade realiza a compensação e a liquidação das transações realizadas entre compradores e vendedores, assegurando que os termos de uma negociação sejam cumpridos, mesmo se uma das partes perder sua capacidade de honrar o acordo.

Com isso, a câmara de compensação garante eficiência e estabilidade para o mercado, reduzindo o risco tanto o interpolado pela necessidade de confiança entre as contrapartes, como o da não liquidação financeira entre os agentes do mercado.

Por isso, a plataforma de negociação em desenvolvimento neste projeto P&D, além de utilizar tecnologias que garantirão o seu correto funcionamento, também estará conectada à uma câmara de compensação que visará mitigar os riscos anteriormente citados.

IV.  Arquitetura de Software

Utilizou-se neste projeto P&D o padrão N-camadas (N-tier) de arquitetura de software, onde uma aplicação é dividida em camadas lógicas e camadas físicas.

As camadas são uma forma de separar responsabilidades e gerenciar dependências. Cada camada tem uma responsabilidade específica e uma camada superior pode usar serviços em uma camada inferior, mas não o contrário.

Na Figura 1, é possível visualizar a arquitetura desenvolvida da plataforma de balcão organizado de comercialização de energia, detalhada a seguir.

Figura 1. Arquitetura de software de N-camadas da plataforma de balcão organizado de comercialização de energia.

As camadas são fisicamente separadas, funcionando em máquinas separadas. Uma camada pode chamar a outra camada diretamente ou usar mensagens assíncronas (fila de mensagens). A separação física das camadas melhora a escalabilidade e a resiliência, mas também adiciona latência da comunicação de rede adicional, que terá o seu impacto mensurado através de ferramentas de monitoramento da aplicação como Sentry [3] e Zabbix [4].

Nas próximas etapas do projeto, algumas camadas lógicas da aplicação monolítica [5], atualmente desenvolvida utilizando o framework Django [6] serão separadas em serviços distintos, adotando as arquiteturas de microsserviços [7] e de orientação à eventos.

V.  Computação em Nuvem

A computação em nuvem é, atualmente, a melhor forma de alocar recursos de computação para o desenvolvimento de projetos, tendo a melhor relação custo-benefício visando mais agilidade e escalabilidade. Por isso, neste projeto foram utilizados recursos de computação em nuvem da Amazon Web Services, sendo este serviço responsável por prover a maior parte das soluções de computação necessários (servidores, armazenamento, bancos de dados, rede, software etc.) para o funcionamento da plataforma desenvolvida [8].

A nuvem oferece fácil acesso a uma grande variedade de tecnologias que permite a rápida implantação de serviços de tecnologia. Com esse tipo de arquitetura, não há necessidade de os recursos serem provisionados em excesso para absorver picos de carga futuros. Em vez disso, a quantidade de recursos provisionados é elástica, ou seja, há sempre a possibilidade de aumentar ou diminuir instantaneamente a escala desses recursos para ajustar a capacidade de acordo com a necessidade.

Ela também permite uma relação custo-benefício superior que a manutenção de uma infraestrutura tecnológica física própria, pois permite a troca de despesas fixas com datacenters, servidores físicos etc. por despesas variáveis, fazendo com que apenas recursos utilizados sob demanda, sejam cobrados. Além disso, as despesas variáveis são menores do que seriam as despesas fixas devido às economias de escala dos serviços em nuvem.

VI.  Interface do Usuário

A interface do usuário desenvolvida neste projeto é composta de tecnologias de front-end (HTML, CSS e JavaScript), que tem como objetivo prover os elementos que um usuário visualizará e com os quais ele interagirá. Isso inclui, o design de telas, botões, ícones, imagens, texto e todos os outros componentes visuais, que serão renderizados pelo navegador do usuário.

Dentre as tecnologias utilizadas no projeto, a principal delas é o framework Next [9], que facilita o desenvolvimento de aplicações utilizando a biblioteca React [10], abstraindo as tarefas comuns e redundantes com APIs relativamente mais simples para o desenvolvimento de interfaces de usuário.

Outro componente importante dentro das tecnologias utilizadas no desenvolvimento da interface de usuário é o GraphQL [11]. O GraphQL é uma linguagem de consulta de APIs que fornece uma descrição completa e compreensível dos dados das APIs, permitindo que a interface e outros clientes realizem requisições para criação, alteração e solicitação de forma que somente os dados requisitados sejam retornados. Isso evita que ocorram casos de over-fetching, em que dados demais são retornados e under-fetching, caso em que são retornados dados insuficientes. Estes casos são comuns no desenvolvimento de APIs REST e causam problemas de desempenho em uma aplicação Web.

VII.  Framework Django

Django é um framework Web gratuito de alto nível desenvolvido na linguagem de programação Python que incentiva o desenvolvimento rápido e um design limpo e pragmático. Construído por desenvolvedores experientes, foi criado originalmente como sistema para gerenciar o site do jornal Lawrence Journal-World na cidade de Lawrence, no Kansas (EUA). Tornou-se um projeto de código aberto sob a licença BSD [12] em 2005. Ele cuida de grande parte do trabalho de desenvolvimento da Web, para que qualquer desenvolvedor possa se concentrar em escrever seu aplicativo sem precisar reinventar a roda.

O framework Django é “moderadamente opinativo”, ou seja, ele possui uma opinião sobre o modo correto de desenvolver tarefas comuns em uma aplicação, porém com bastante flexibilidade, o que auxilia os desenvolvedores a criar soluções Web escaláveis com rapidez, agilidade e segurança.

Nesse projeto, o Django foi utilizado para criar a aplicação monolítica responsável pelo cadastro de usuários e empresas, criação de ordens de compra e venda de contratos de energia, e, pela gestão de limites de crédito dos participantes do mercado de balcão que operarem dentro dessa plataforma (objeto deste projeto).

Posteriormente, essas funcionalidades serão separadas em serviços individuais, quando a plataforma migrará de uma arquitetura monolítica para uma arquitetura de microsserviços.

O Django também é responsável por servir a API GraphQL para comunicação com a interface de usuário através da biblioteca Graphene [13].

Estes serviços poderão ser desenvolvidos utilizando outro framework que não o Django, e até mesmo utilizar outra linguagem de programação diferente do Python, ficando sob responsabilidade do time de tecnologia da Fohat Corporation, a definição das tecnologias mais adequadas para atender aos requisitos de cada serviço.

VIII.  Banco de Dados

O framework Django também é responsável por definir o esquema e realizar a persistência de dados da aplicação em um banco de dados relacional. Para isso, o Django possui um poderoso ORM (Object-Relational-Mapper) — em português, mapeador objeto-relacional —, que faz o mapeamento da estrutura do banco de dados e fornece uma API para uso do banco de dados dentro da aplicação.

O banco de dados relacional utilizado no projeto é o PostgreSQL, pois ele possui uma boa reputação e uma arquitetura confiável e robusta para armazenar e escalar cargas de trabalho complexas com segurança, além de contar com mais de 30 anos de desenvolvimento de software de código aberto por parte de uma comunidade ativa.

IX.  Matching Engine

Um mecanismo de correspondência – do inglês, matching engine – é o principal componente de software de uma plataforma de negociação, pois é ele o responsável por combinar lances e ofertas para concluir negociações ao mesmo preço.

O algoritmo mais comumente utilizado é o algoritmo “preço-tempo e prioridade” – do inglês, Price-Time Priority – onde as ordens são classificadas, primeiramente pelo seu preço de oferta e, em seguida, de acordo com a data e hora da inserção na lista de ordens de cada produto [14].

No desenvolvimento da matching engine, além da aplicação monolítica utilizando o framework Django para salvar as ordens criadas através da interface de usuário, utilizou-se também a biblioteca Faust [15] – que consome as mensagens publicadas em tópicos no Apache Kafka – para então realizar o processamento do algoritmo de correspondência de ordens do mercado do balcão de energia.

Nas fases iniciais do projeto, foi-se utilizado a biblioteca Celery [16], em conjunto com o servidor de mensageria RabbitMQ [17]. No entanto, foram identificados erros que levaram à conclusão de que essa não seria a melhor abordagem para atender aos requisitos para o funcionamento desse serviço, pois constatou-se que o RabbitMQ não entregou as mensagens em ordem de criação aos serviços consumidores. Já com o Apache Kafka, foi possível assegurar a ordenação da entrega de mensagens aos consumidores, fazendo com que o algoritmo implementado pelo time de desenvolvimento funcionasse corretamente.

X.  Funcionalidades

O desenvolvimento da plataforma Home Broker traz consigo diferenciais tecnológicos e funcionais, capazes de promover uma nova perspectiva de operação no mercado de energia. O principal fator tecnológico e funcional que a torna diferente de todas as outras plataformas disponíveis no Brasil para operação de compra e venda de energia, trata-se da integração que o Home Broker possui com outra plataforma chamada na Fohat de Turing, que possibilita o mercado de energia e as instituições financeiras, interagirem em uma rede DLT – Distributed Ledger Technology, para troca de informações privadas em tempo real sem a necessidade de integração e recuperação de dados em Banco de Dados local ou privado.

Esse modelo de tratamento de dados em rede DLT possibilita que o mercado passe a operar a compra e venda de energia, utilizando o modelo mundialmente conhecido como Central Counterparty, ou Contraparte Central e, através desse modelo, a gestão de risco financeiro do mercado fica sob a responsabilidade de uma entidade financeira habilitada pela regulação do Bacen do Brasil.

Por ser uma plataforma Web com acesso em diferentes navegadores, foi possível implementar recursos modulares que podem ser acessados por uma ou todas as empresas, tudo dependerá do perfil operacional da empresa na junto a Fohat e ou a administradora de mercado.

Dentre todas as funcionalidades que a plataforma Home Broker para Balcão Organizado tem, vamos listar algumas que são diferenciais competitivos de mercado e características para um mercado de trading mais líquido e seguro.

1. Match de ordem em nível multilateral. A plataforma Home Broker, quando integrada a plataforma (“Turing”), que controla as garantias financeiras entre os operadores (“Margem de Operação”), possibilita que uma ordem de compra ou venda de energia, esteja habilitada para qualquer outra empresa conectada ao Home Broker, ou seja, uma ordem disponível no Book de Ordens, pode ser atendida por qualquer participante. Chamamos esse processo de “Tela Cega, pois os participantes somente conheceram sua contraparte após o pronto efetivo da formalização contratual. Esse modelo traz inúmeros benefícios como liquidez, por mais negócios podem ser gerados, segurança, porque todos os players sabem que uma contraparte atestará a liquidação financeira daquele contrato e transparência de preços porque no mercado líquido e seguro as partes estão preocupadas em executar suas estratégias e se torna muito mais complexo e arriscado a tentativa de manipulação de preços.
2. A plataforma Home Broker também possui tipos de ordem seguindo o padrão de trading para Bolsa de Valores. Uma empresa pode inserir ordens naturais que, apresentam de forma aberta e objetiva todo o volume ofertado pela empresa e dessa forma, o mercado toma conhecimento, na íntegra, da intenção de oferta de um ou vários playres para um produto e valor em questão. Também há como possibilidade o envio de uma ordem “Tudo ou Nada”, que, na íntegra, informa ao mercado que determinado participante somente aceita vender ou comprar todo o conteúdo disponível no lote ofertado. Para empresas mais estrategistas, a plataforma permite a inserção da ordem “Iceberg”. Na ordem Iceberg a empresa informa quanto do volume exposto na ordem de compra ou venda, deve permanecer aberto para visualização dos demais players de mercado. A ordem Iceberg permite que os participantes com grandes volumes de energia possam operar esses volumes de forma transparente, sem expor sua estratégia de posicionamento ou de exposição energético.

• Relatórios para Pós Trading. Para empresas que precisam ajustar a estratégia de operação para as mesas de energia com vários traders, a plataforma Home Broker permite que todos possam, de forma online, acompanhar os trades realizados independente de terem sidos formalizados por um robô ou por uma pessoa, paralelamente à extração de dados do mercado ou atualização das regras operacionais da instituição. Todos os relatórios podem, ainda, serem extraídos para um arquivo Excel ou integrados de forma automatizada em sistemas legado, ERPs ou de Gestão de Dados, via APIs.

1. Integração multi-plataformas via APIs. O Home Broker está diretamente ligado a outras plataformas da Fohat através de um barramento de APIs e, esse barramento, quando devidamente autorizado, permite que os participantes possam conectar seus sistemas legado diretamente à plataforma Home Broker para enviar ou retirar ordens, consumir dados de mercado, abaixar contratos assinados e atualizar estratégia de compra e venda de energia.
2. Integração com parceiros de mercado. A plataforma Home Broker, através do modulo Terminal Broker, possui integrações com vários parceiros de negócio a saber: BBCE, CCEE, DCIDE e outros. Por causa dessas integrações, o participante não precisará contratar outras plataformas para gerenciar BackOffice, mesa de risco, financeiro e jurídico porque tudo pode ser realizado diretamente na plataforma Terminal Broker, que é um módulo conectado a plataforma Home Broker.

A plataforma Home Broker foi complemente preparada para ser capaz de processar ordens de compra e venda de energia, formalização bilateral de contratos com ou sem garantias associadas, processamento de venda e compra de I-RECs e automações de compra e venda de energia pelo módulo de VPP (Virtual Power Plant ou Usinas Virtuais).

Todos os recursos são acessados de forma logada, em comunicação criptografada SSL com utilização de senha configurada com o mesmo padrão recomendado pelo Roteiro Básico de Qualificação Operacional BMF&Bovespa – PQO e, contra senha de confirmação para inserção, atualização e exclusão de ordens, assinatura de contratos e gestão de usuários da plataforma.

XI.  Conclusões

O desenvolvimento de uma plataforma para negociação de contratos de energia não se mostra uma tarefa simples, tendo em vista as várias tecnologias envolvidas nesse projeto para fornecer uma solução robusta e segura ao mercado. Um desafio particular dele também foi o de criar uma arquitetura de software capaz de receber ordens de negociação e realizar a execução de negócios de forma assíncrona, em tempo real e de uma forma justa para todos os participantes da plataforma.

Também é visível a maturidade do projeto em tecnologias front-end utilizando-se das tecnologias GraphQL e do framework Next para a utilização de recursos para a atualização de dados em tempo real das negociações realizadas na plataforma.

Soma-se a isso a utilização das melhores práticas de desenvolvimento e arquitetura de software utilizando-se computação em nuvem e técnicas de agilidade que dão à equipe do projeto os recursos necessários para planejar, executar e revisar as funcionalidades desenvolvidas.

É satisfatório ver a plataforma de negociação em funcionamento, tendo a certeza de que o resultado deste projeto P&D ANEEL possibilitará oportunidades de negócios para todos os participantes do Mercado Livre de Energia com mais segurança e confiabilidade.

Agradecimentos

À AES Brasil pela confiança na Fohat Corporation e, à sua equipe de inovação, representada por Julia Rodrigues, pelo profissionalismo e suporte ao trabalho. Na Fohat Corporation, agradecimentos especiais a todo o time de tecnologia e produto empenhado na construção deste projeto, ao Guilherme Gonçalves, pelas orientações na escrita do artigo e Sonia Marques, pela revisão do texto.

Referências Bibliográficas

• AGÊNCIA NACIONAL DE ENERGIA ELÉTRICA. Programa de Pesquisa e Desenvolvimento Tecnológico do Setor de Energia Elétrica – ANEEL. Disponível em: <https://www.aneel.gov.br/programa-de-p-d/>. Acesso em: 15 de dez. de 2020.
• VALOR ECONÔMICO. Energia: Vega não honra R$ 200 milhões em contratos após alta de preço. Disponível em: <https://valor.globo.com/empresas/noticia/2019/02/01/energia-vega-nao-honra-r-200-milhoes-em-contratos-apos-alta-de-preco.ghtml/>. Acesso em 16 de dez. de 2020.
• Application Monitoring and Error Tracking Software. Disponível em: <https://sentry.io/>. Acesso em: 16 de dez. de 2020.
• The Enterprise-Class Open Source Network Monitoring Solution. Disponível em: <https://www.zabbix.com/>. Acesso em: 16 de dez. de 2020.
• Monolithic Architecture pattern. Disponível em: < https://microservices.io/patterns/monolithic.html>. Acesso em: 16 de dez. de 2020.
• The Web framework for perfectionists with deadlines. Disponível em: <https://www.djangoproject.com/>. Acesso em: 15 de dez. de 2020.
• Microservice Architecture pattern. Disponível em: <https://microservices.io/patterns/microservices.html>. Acesso em: 16 de dez. de 2020.
• AMAZON WEB SERVICES. Serviços de Computação em Nuvem. Disponível em: <https://aws.amazon.com/pt/>. Acesso em: 11 de jan. de 2021.
• JS. The React framework. Disponível em <https://nextjs.org/>. Acesso em 14 de jan. de 2021.
• A JavaScript library for building user interfaces. Disponível em <https://reactjs.org/>. Acesso em 14 de jan. 2021.
• A query language for your API. Disponível em < https://graphql.org/>. Acesso em 14 de jan. de 2021.
• OPEN-SOURCE INITIATIVE. The 3-Clause BSD License. Disponível em: <https://opensource.org/licenses/BSD-3-Clause/>. Acesso em: 14 de dez. de 2020.
• GRAPHENE-PYTHON. GraphQL in Python Made Easy. Disponível em <https://graphene-python.org/>. Acesso em 14 de jan. de 2021.
• Matching Orders Definition. Disponível em: < https://www.investopedia.com/terms/m/matchingorders.asp>. Acesso em: 16 de dez. de 2020.
• FAUST DOCUMENTATION. Disponível em: < https://faust.readthedocs.io/>. Acesso em: 16 de dez. de 2020.
• CELERY DOCUMENTATION. Distributed Task Queue. Disponível em: < https://docs.celeryproject.org/>. Acesso em: 16 de dez. de 2020.
• Messaging that just works. Disponível em: <https://www.rabbitmq.com/>. Acesso em: 16 de dez. de 2020.