Consumo Inteligente: Um estudo utilizando conceitos de IoT, com um modelo descentralizado (Fog/Edge Computing) e a abordagem Peer-to-Peer
Protótipo de um sistema completo de controle inteligente gastos. Trazendo automação na coleta e controle dos dados, bem como disponibilizando para consulta para admnistrador e clientes.
- MQTT
- Fog Computing
- Python
- Flask
- Pandas
Como uma otimização do projeto anterior, foi proposta uma nova abordagem, dessa vez utilizando um modelo descentralizado. Portanto, a solução baseia-se sobretudo na computação em névoa para o melhor uso da rede, tempo de resposta, escalabilidade e até segurança do projeto.
A computação em névoa é uma infraestrutura de computação descentralizada. Nela dados, computação, armazenamento e aplicativos estão localizados em algum lugar entre a fonte de dados e a nuvem. Assim como a computação de borda, a computação em névoa traz as vantagens e o poder da nuvem para mais perto de onde os dados são criados e utilizados. Inclusive, muitas pessoas usam os termos computação em névoa e computação de borda de forma intercambiável porque ambos envolvem trazer inteligência e processamento para mais perto de onde os dados são criados.
Para o desenvolvimento dessa infrastrutura foi utilizado o protocolo MQTT (Message Queing Telemetry Transport) em protoloco de transporte de mensagens de formato Cliente/Servidor, a qual possibilita a comunicação entre máquinas (M2M) e para a conectivada de IoT (internet of things).
Logo, para funcionar, o protocolo MQTT utiliza um modelo de Publish/Subscribe, onde permite que o cliente faça postagens e/ou capte informações enquanto o servidor irá administrar esse envio e o recebido dos respectivos dados.
Os maiores desafios desse problema, foram acerca de como usar essa 'névoa' de modo com que fosse possível otimizar o uso de todos os recursos. Para isso, foi pensada numa estruturação que trouxesse ligações que permitissem a troca de informações com o menor número de saltos possível, bem como, aproveitando ao máximo a rede.
- Nenhum usuário deve ultrapassar a média do consumo;
- Um usuário não deve ultrapassar um valor máximo em metros cúbicos;
- Visualizar N hidrômetros de maior consumo
- Selecionar um deles para visualizar os dados com o menor tempo de latência possível;
A cada ciclo de contagem, como mostrado na imagem, os hidrômetros que foram bloqueados na contagem anterior são desbloqueados, e então, a lista de hidrômetros conectados é percorrida novamente e os que estiverem acima da média são bloqeuados.
No problema, foi adotado um "teto de gastos", a cada contagem que o nó recebe, ele verifica se o hidrômetro passou do valor de teto. Há um valor de teto "default", que é o zero, nada acontece até que seja enviado um valor de teto pelo administrador. O valor é enviado para o servidor central, o qual encaminha para todos os nós conectados, onde ocorre a verificação e os possíveis cortes.A cada ciclo de contagem de um nó, é enviada uma lista ordena com hidrometros:gasto, o servidor central recebe e a ordena. O admin portanto, pode inserir o valor desejado para a visualização. Como o valor é indeterminado, pode ocorrer de não existir a quantidade pedida conectada à névoa, por isso, o servidor irá enviar todas as conexões de forma ordenada.
Para essa solução, foi usada a tecnologia de websockets, neste caso da biblioteca Flask (Flask-SocketIO), que é uma tecnologia a qual torna possível abrir uma sessão de comunicação interativa entre o navegador do usuário e um servidor. Com esta API, você pode enviar mensagens para um servidor e receber respostas orientadas a eventos sem ter que consultar o servidor para obter uma resposta.
A API então se inscreve no tópico do hidrômetro, ela envia as mensagem para o scrip JS, que exibe na página em em "tempo real".
O intermediário no processo de comunicação. Elementos que desejam publicar informações o fazem também através do broker, enviando-lhe as informações que possuem. Os elemtos que desejam receber as informações então se inscrevem no broker, para receber. Toda essa conexão é feita através de tópicos.
O tópico lembra o conceito de URI, com níveis separados por barras (/). Elementos da rede podem enviar diversos tópicos para o broker e subscritores podem escolher os tópicos que desejam subscrever. Nesse projeto foi utilizado um broker, este então manipula todas as informações do projeto. Nesse projeto foi utilizado um broker, este então manipula todas as informações do projeto.
O hidrômetro funciona como o sensor do sistema, ao inicializar, é possível escolher uma "tendência" para esse dispositivo, ele pode ter um consumo alto, médio ou baixo. O hidrômentro envia mensagens para o nó, assim atuando como publisher, também como subscriber, quando recebe a mensagem de bloqueio e desbloqueio, que é feita via MQTT . Assim, nele podemos verificar a vazão de água atual, o consumo total do período, status de vazamento e pode ser bloqueado por dois motivos: estar em débito e consumo maior que a média de consumo de todos os hidrômetros. Eles estão conectados ao nó da nuvem, que por sua vez, como agrupamento é chamado de setor.
O servidor central é responsável por manipular informações que precisam ser compartilhada entre todos os "setores", como enviando o teto de gastos para todos os nós, bem como calcular a média geral de todo o sistema, elencar os hidrômetros com maior gasto de todo o sistema. Ou ainda, enviar todos os hidrômetros que possuem vazamento. O servidor também possui um arquivo atrelado com todos os ID's de hidrômetros com possível vazamento. O servidor também atua como publisher e subscriber, enviando e recebendo informações.
*Exemplificação dos setores*
Os nós todos juntos compõe a névoa do sistema, eles possuem como banco de dados três planilhas: dadosGerais, que possui uma ocorrência de cada hidrômetro conectado com as informações mais atualizadas, o historicoGeralNo, onde estão presentes todas as informações de todos os nós, também há a planilha de pagamentos, onde estão as datas que devem ocorrer o pagamento das contas dos hidrômetros.O nó é o elemento com mais responsabilidades em todo o projeto, ele manipula as informações dos hidrômetros que são do seu setor, verificando seu histórico, verificando débito, retornando consumo e o valor da conta. Também, calcula a média, bloqueia e desbloqueia com base nesta média e no teto de gastos, e também retorna os hidrômetros elencados, com os com maiores gastos.
A tela do usuário consome a API usando a biblioteca requests, essa disponibiliza as opções. Para entrar na tela, deve-se informar sua ID e setor- 1. Histórico de gastos
- 2. Litros acumulados
- 3. Valor da sua conta
- 4. Pagar conta
- 1. Envia teto de gastos
- 2. Lista os N maiores hidrômetros
- 3. Lista vazamento
- 4. Verifica débito
- 5. Bloqueio determinado hidrômetro
- 6. Visualiza hidrômetro em tempo real
O projeto consegue realizar tudo dentro do previsto. Trouxe desafios na implementação e compreensão de protocolo mqtt, também possibilitou um estudo e reflexão mais aprofundada no que diz respeito ao que é a computação de borda. Algo que poderia ser adicionado em outras versões, é uma quantidade maior brokers, visto que é um servidor, o qual manipula todas as informações. Esses servidores poderiam ser separados por setores. No entanto, como o projeto ainda está em fase de projeto, não é prejudicado o seu desempenho. Também pode ser modificada a interface no terminal, e inserir uma interface web.
Também, as comunicações que não são "fixas" poderiam ser feitas todas em REST, não apenas centralizada como ocorre na versão atual. Isso deixaria a solução menos custosa e até mais rápida. O que facilitaria a descentralização total do projeto, não sendo dependente da API central mostrada.