Detectando anomalias na coleta de dados de energia elétrica em tempo real – Parte 1

Por Ivan Vargas, Arquiteto de Soluções

Introdução

Coletar grandes volumes de dados e processá-los em lote é uma abordagem bastante comum e econômica. Entretanto, conforme o volume de dados aumenta e os problemas de negócio exigem que estes processamentos sejam feitos com mais frequência e rapidez, é necessário avaliar alternativas a este modelo. Neste contexto, abordagens relacionadas a aquisição e processamento de dados via streaming para processamento em tempo real tem se mostrado uma alternativa eficiente para atender a diferentes requisitos de negócio. Os recursos computacionais são dimensionados de forma mais eficiente, além de possibilitar que análises e decisões sejam feitas durante o processamento destes dados.

A proposta desta série de 3 blog posts é explorar uma arquitetura para a coleta de dados de energia elétrica, com o objetivo de identificar anomalias nos dados coletados de cada medidor e possibilitar o disparo de ações remotas caso algum desvio de comportamento seja detectado. Adicionaremos também dashboards para o monitoramento desta coleta na visão de um operador deste sistema. Além disto, os dados coletados serão armazenados para processamentos adicionais e serão enriquecidos com dados cadastrais para que seja possível gerar análises históricas por data, região, cidade e estado, por exemplo. O resultado desta coleta também pode ser utilizado para atender a outros casos de uso como, por exemplo, a modelos de previsão de consumo de energia. Para isto, a AWS fornece o Quickstart Utility Meter Data Analytics on AWS.

Este post é a primeira parte desta série onde iremos descrever o blueprint da arquitetura completa utilizando os serviços AWS. Na segunda parte, abordaremos em detalhes como coletar e disponibilizar os dados via streaming para processamento em tempo real. Na terceira e última parte, falaremos sobre como fazer a agregação dos dados coletados para gerar informações e insights com o cruzamento de informações transacionais e cadastrais.

Contexto de negócio e volumetria

Utilizaremos o mercado de energia elétrica brasileiro com um exemplo de uso da arquitetura proposta. Neste contexto, tanto os geradores quanto os consumidores necessitam enviar os dados dos seus medidores diariamente. Estes dados contêm informações do fluxo de energia passante no medidor e devem ser capturados e agregados em intervalos de 5 minutos, isto é, temos 288 registros de dados de energia para cada medidor por dia. De acordo com o relatório de administração da Câmara de Comercialização de Energia Elétrica – CCEE de 2019, o ano passado finalizou com 23.485 pontos de medição. O ponto de medição aqui é um conceito lógico para a abstração da instalação física e é composto basicamente por dois medidores de energia, o principal e o de retaguarda. Portanto, a volumetria esperada neste contexto é de 46.970 medidores enviando 288 registros de medição por dia, totalizando mais de 13.5 milhões registros diários. O formato do arquivo enviado é XML e tem tamanho médio de 300kb, o que gera um volume diário em torno de 14GiB. A janela mensal de dados processados gira em torno de 400 milhões de registros e 420 GiB de dados. Ainda de acordo com o relatório acima, o mercado teve um crescimento de 17% de 2018 para 2019. Podemos considerar que esta volumetria também cresce na mesma proporção.

Considerando a volumetria acima, processar estes dados via streaming e em tempo real faz bastante sentido e traz benefícios como a flexibilidade da plataforma tecnológica, detecção de comportamentos não esperados rapidamente e um monitoramento preciso que pode disparar antecipadamente ações como a manutenção ou desconexão de medidores, por exemplo.

O exemplo do caso de uso citado acima refere-se à visão na ótica da Câmara de Comercialização de Energia Elétrica (CCEE). Entretanto, este caso de uso é também aplicável às distribuidoras de energia, porém em um conjunto diferente de informações. As distribuidoras normalmente utilizam soluções de Meter Data Management (MDM) específicas para o seu parque de medidores e que executam comandos remotos, além da coleta de dados.

Arquitetura proposta

A proposta desta série de blog posts é exemplificar como o caso de uso proposto pode ser resolvido utilizando os serviços da AWS. Não é o objetivo aqui detalhar uma arquitetura de referência end-to-end sobre o tema, pois demandaria uma abordagem mais profunda com relação à alguns componentes da arquitetura (como os medidores, por exemplo). Nesta arquitetura, utilizamos um dispositivo Raspberry PI com o intuito de demonstrar as possibilidades com relação comunicação bidirecional utilizando o AWS IoT Core, sem o compromisso de abordar a arquitetura específica para o dispositivo utilizando também serviços AWS como o AWS IoT Greengrass ou FreeRTOS, específicos para este fim.

O diagrama abaixo detalha a arquitetura completa utilizada durante esta série de blog posts:

O diagrama foi dividido em 3 blocos: Data Ingestion, Near Realtime Processing e Historical Data Visualization. Abaixo, fazemos a descrição dos componentes por cada bloco e destacados pela numeração correspondente:

Data Ingestion

Localização física de um gerador de energia contendo dois medidores para fins de redundância. Estes medidores enviam um payload JSON via protocolo MQTT ou HTTPS ao AWS IoT Core, que é um serviço gerenciado e atua como broker MQTT para a coleta de dados de milhões de dispositivos. Associado ao AWS IoT Device Management, são responsáveis pela segurança através da troca de chaves públicas e privadas entre os dispositivos, facilitando a transmissão segura de informações via TLS 1.2. O IoT Rules é responsável por rotear as mensagens para dois componentes: o Amazon Kinesis Data Stream, contendo o dado original e sem nenhuma transformação, e o Amazon Elasticsearch Service, um serviço gerenciado da AWS para clusters Elasticsearch com Kibana.
Os dados adicionados pelo IoT Rules ao Amazon Kinesis Data Streams são consumidos por 3 componentes: o Amazon Kinesis Data Analytics e dois Amazon Kinesis Firehoses. O Kinesis Firehose S3 Dump é responsável por bufferizar os dados recebidos, agregar as várias mensagens e salvar no Amazon S3 no formato Parquet compactados. O Firehose Elasticsearch Buffer controla a inserção dos dados no Amazon Elasticsearch Service para evitar sobrecarga do componente por causa do volume de dados.

Near Realtime Processing

Foram criados 2 dashboards no Kibana providos pelo Amazon Elasticsearch Service para o acompanhamento dos dados sendo enviados e também para a notificação das anomalias detectadas. Os dashboards são atualizados automaticamente minuto a minuto, considerando o tempo mínimo de bufferização do Amazon Kinesis Firehose.
O Amazon Kinesis Data Analytics é responsável por fazer a detecção de anomalias utilizando algoritmos de Machine Learning. As anomalias identificadas são inseridas no Amazon Elasticsearch Service e no Amazon S3. Além disto, a função Lambda set-timestamp enriquece os dados incluindo o score da anomalia e timestamp.
A segunda função Lambda chamada anomaly-checker envia uma mensagem MQTT ao AWS IoT Core com o score da anomalia e o comando remoto a ser executado caso ele esteja acima de um threshold parametrizado.
O dispositivo físico que simula o medidor de energia, neste caso usando um Raspberry PI, demonstra o recebimento de dados do AWS IoT Core via MQTT para atualizar o dashboard com o status do dispositivo e também executar comandos remotos enviados pelo passo anterior. Por exemplo, disparar um alarme na planta do gerador ou desativar a entrada de energia em um medidor são alguns comandos relevantes neste cenário.

Historical Data Visualization

Os dados armazenados no Amazon S3 são catalogados pelo AWS Glue Data Catalog. Eles foram previamente particionados no Amazon Kinesis Firehose nas dimensões Ano, Mês, Dia e Hora e são atualizadas com um Crawler criado no AWS Glue. Com o Amazon Athena, mapeamos os arquivos Parquet e CSV (com os dados cadastrais) disponíveis no S3 como external tables e disponibilizamos consultas SQL com o join dos dados de medição e dados cadastrais para mapeamento do Dataset dentro do Amazon QuickSight.
Com o Amazon QuickSight, geramos um dashboard interativo com os dados agregados com o histórico da coleta e possibilidade de drill down por ano, mês, dia, hora, estado, cidade, proprietário do medidor, medidor, tipo de dado coletado e score de anomalia.

Benefícios e Próximos passos

Até aqui falamos sobre como é possível resolver o caso de uso descrito utilizando os serviços AWS com uma abordagem escalável e flexível baseada em eventos e utilizando apenas serviços gerenciados. Esta estratégia traz como principais benefícios:

Eliminação da necessidade de gerenciamento de servidores;
Flexibilidade para a inclusão de novas funcionalidades, pois é possível agregar novas regras ao fluxo existente sem impacto no fluxo de dados principal.
Modelo de custo pay-per-use, possibilitando que o TCO da solução escale juntamente com o volume de dados trafegados;
Permite escalar para milhões de dispositivos com o processamento em tempo real de gigabytes de dados;

Nos próximos posts iremos descrever como implementar esta arquitetura passo a passo.

Sobre o autor

Ivan Vargas é Arquiteto de Soluções na AWS focado em empresas no segmento Digital, que já nasceram ou tem a maioria da sua operação na nuvem. Atua auxiliando os clientes desenhando e influenciando soluções baseadas nos serviços AWS. Com mais de 15 anos de experiência em Arquitetura, Desenvolvimento Web e gestão de TI, Ivan atuou em diversos projetos de desenvolvimento e modernização de aplicações.

O blog da AWS