IoT #03 — Pequenas ideias para projeção de uma arquitetura em Internet das Coisas

Problema: Prever, detectar e combater incêndios (acidentais ou não) em fazendas (no exemplo, estamos imaginando uma fazenda de 400 Km², cuja principal plantação é milho — que exige condições secas para a colheita)

Este artigo é um resumo da arquitetura de IoT proposta para o problema acima na aula de Arquitetura de IoT do MBA de Internet of Things da USP. A intenção do trabalho foi entender os conceitos de comunicação, tecnologia, protocolos, energia, sensores e dados que são necessários no escopo desse problema.

O primeiro ponto a abordar na arquitetura são os sensores. Para efeitos práticos da definição da arquitetura, não entraremos nos detalhes da especificação técnica do hardware. Caso tenha mais interesse nesse aspecto, segue um artigo que faz comparações bem pertinentes do hardware (para o módulo de rede, definimos o uso do XBee):

A questão, em termos de arquitetura, refere-se a organização dos sensores (rede Mesh para o Zig Bee antigo com alcance de 291m, ou rede star para o XBee novo com alcance de quase 1,5 km), o protocolo (ZigBee — baixo consumo de energia) e os dados que serão coletados (definimos os dados mínimos como temperatura, umidade e pressão). Em termos de energia, os sensores só ião notificar o gateway em caso de anomalia em algum dessas informações ou ao menos uma vez por dia, poupando energia da transmissão

Aqui vem uma decisão importante sobre a nossa arquitetura: se ela será centralizada ou descentralizada. Apesar de ter uma plataforma central que irá realizar as análises mais complexas e fornecer certo controle sobre as informações, optamos por uma arquitetura descentralizada, com o conceito de Edge Computing (ou Fog Computing), onde o processamento das informações ocorre independente da disponibilidade da plataforma central. E isso acontece pois em cada uma das áreas da fazenda colocamos um gateway inteligente (posicionados em mesh em todo o território) que processará inicialmente essas informações, e dependendo da análise coletiva das informações coletadas pelos sensores daquela área, irá informar a plataforma central e avisar os meios de combate a incêndio tópico a seguir), e caso ele processe e verifique um falso positivo, ele não irá acionar a plataforma e evitará o consumo de energia na rede.

Optamos por fazer uso do protocolo MQTT pois ele é orientado a eventos e simples e fácil de escalar. Os sensores serão os publishers, os gateways serão os brokers (incluindo a funcionalidade de autenticação dos sensores, para evitar que alguém envie um alarme falso) e os publishers serão a plataforma central e os meios de combate a incêndio (irrigadores, drones e tratores).

A plataforma central, centraliza todas as análises feitas e possibilita as seguintes questões:

  • Aviso a autoridades públicas da região, através de um conexão via rádio e/ou 3g/4g, notifica-os em caso de incêndio;
  • Criação de uma base pública OPEN DATA (ou não, dependendo do quão sensível sejam os dados e os desejos do fazendeiro) para que outras fazendas na região consulte — afinal um incêndio em uma fazenda pode afetar as outras. Além disso, facilita a ubiquidade, pois o fazendeiro não precisaria estar sempre de frente para a tela da plataforma para saber os resultados, poderia acessá-lo do celular mesmo quando estivesse fora da fazenda;
  • Dashboard com todas as análises dos dados coletados dos sensores, indicando áreas com maior risco e fazendo análises preditivas baseadas nos dados históricos;

Em termos de analytics, em quanto os gateways trabalham com threesholds, a plataforma central permite análises mais complexas, utilizando indicadores mais robustos para análise do risco da fazenda, podendo usa as seguintes fórmulas:

Detecção e Combate ao Incêndio

Por fim, a medida que seja detectado o incêndio, acionaríamos diversas linhas de defesa:

  • A primeira seria uma forma de combate não invasiva (irrigadores) que não destruiria a plantação e combatesse o incêndio logo que surgisse evitando que se alastrasse ou ao menos retardando-o. Ele seria acionado imediatamente pelo gateway (mesmo sem precisar acionar a plataforma central)
  • A segunda seriam através de drones com visão infravermelho e/ou transmissão de vídeo, que funcionaria como nossos batedores. Assim que o gateway apontasse o incêndio, ele iria até o local para trazer mais detalhes do foco do incêndio (se o irrigador vai dar conta, ou precisa de mais reforços, além de nos informar qual a previsão de expansão do incêndio — qual a intensidade, direção e tempo de alastramento). Também poderia carregar materiais químicos que ajudassem no combate ao foco de incêndio;
  • A terceira e última forma de combate, só seria acionado em casos extremos onde as primeiras e nem a ajuda das autoridades seria suficiente. Baseado nas informações de expansão do fogo e análise das áreas críticas, seriam acionados tratores autônomos que calculariam a área de impacto do incêndio e iria isolá-la do restante da plantação destruindo (fazendo uma espécie de trincheira) a plantação ao redor e criando uma área onde o fogo não conseguisse se alastrar, isolando-o em apenas um ponto.

OBS: Fizemos apenas um exercício livre da definição da arquitetura, e pedimos licença poética para evitar falar de custos, o que provavelmente afetaria a nossa arquitetura. O objetivo aqui foi apenas exercitar o pensamento da arquitetura, para os próximos passos, é interessante orçar toda a infraestrutura necessária e verificar o ROI para o fazendeiro se há viabilidade técnica e/ou financeira. Além disso, outros aspectos importantes da arquitetura que não foram discutidos aqui é em relação a Qualidade de Serviço, o quão tolerante a falhas a arquitetura deve ser, pensando em agregar confiabilidade ao sistema e até um pouco de segurança (safety) para os trabalhadores da fazenda.