Edge e Cloud não são rivais: são camadas complementares de uma mesma arquitetura de telemetria/automação. O segredo está em decidir onde cada parte do trabalho deve acontecer. Este artigo apresenta critérios objetivos (latência, disponibilidade, custo, compliance), padrões arquiteturais e um roteiro para desenhar sua solução sem dogmas.
Por que a discussão importa
No chão de fábrica, decisões de milissegundos podem proteger pessoas e ativos. Ao mesmo tempo, análises históricas, relatórios e colaboração entre times exigem escala elástica e acesso seguro de qualquer lugar. O edge atende à necessidade de resposta local e resiliência; a nuvem entrega persistência, análise e compartilhamento.
Critérios de decisão (o que vai para cada lado?)
| Critério | Edge (Gateway/PLC) | Cloud (Nuvem) |
|---|---|---|
| Latência/Determinismo | Intertravamentos, debouncing, controle local | Irrelevante para laços de controle |
| Disponibilidade | Opera sem internet, store & forward | Alta disponibilidade para histórico e APIs |
| Volume/Taxa de dados | Pré-filtra, agrega, comprime | Armazena longo prazo e agrega cross-site |
| Segurança/Isolação | Segmenta OT, reduz superfície de ataque | TLS, IAM, trilhas de auditoria centralizadas |
| Compliance/Dados sensíveis | Dados brutos podem permanecer locais | Pseudonimização/mascaramento e políticas |
| Custo (CapEx vs OpEx) | CapEx em hardware; menor tráfego | OpEx elástico; custo por armazenamento e consulta |
Padrão híbrido vencedor
Na prática, a maioria das arquiteturas maduras é híbrida:
- Edge: leitura de I/O, normalização, regras locais, buffer offline, agregações por janela (ex.: média 1s -> 10s), publicação MQTT com QoS 1, LWT.
- Nuvem: ingestão, armazenamento histórico (camadas de retenção), dashboards, relatórios, modelos de detecção de anomalias, APIs para BI.
Fluxo de dados típico (resumo)
- Sensores → PLC/gateway (filtragem, debouncing, histerese).
- Gateway → Broker MQTT (local ou na nuvem); se off-line, enfileira e reenvia (store & forward).
- Broker → Ingestor/DB (retenção e downsampling) → Dashboards/Alertas/Modelos.
Edge: o que deve ficar local
- Segurança operacional: intertravamentos, paradas de emergência, permissivos de partida.
- Tratamento de sinal: debouncing, histerese, validação de intervalos (range checks), clamping.
- Agregação e compactação: reduzir taxa/volume antes de enviar.
- Cache/buffer: persistência local para desconexões – garantindo histórico completo.
- Config local (quando relevante): setpoints críticos, parâmetros de laços.
Nuvem: o que faz mais sentido centralizar
- Histórico e relatórios multi-período, multi-site.
- Dashboards e colaboração (acesso remoto, multi-usuário, SSO).
- Modelos analíticos: detecção de anomalias, KPI cross-site, benchmarking.
- Integrações com ERP/CMMS/BI via APIs.
- Gestão de identidade/acessos (IAM), auditoria e compliance.
MQTT como “cola” da arquitetura
MQTT é ideal para o acoplamento fraco entre edge e nuvem:
- QoS 1 como padrão; QoS 0 em streams efêmeros; QoS 2 apenas onde idempotência é crítica.
- Retained em estados (ex.:
.../gateway/status), evitando dashboards “cegos”. - LWT para detectar gateways off-line com tópicos de status retidos.
- ACL por tópico para separar publicadores/assinantes e reduzir blast radius.
Três padrões de implantação
- Broker local + replicação para nuvem
Vantagens: operação mesmo sem internet, baixa latência local. Desvantagens: mais moving parts.
Use quando: processos são sensíveis a latência e há múltiplos consumidores locais. - Broker gerenciado na nuvem + buffer robusto no edge
Vantagens: simplicidade operacional, IAM centralizado. Desvantagens: depende de internet, exige buffer forte.
Use quando: latência não é crítica e o site possui conectividade estável. - Híbrido por domínio (ex.: controls local, telemetry na nuvem)
Vantagens: separa criticidade; otimiza custos. Desvantagens: governança de tópicos mais complexa.
Use quando: há clara separação entre controle e monitoramento.
Governança de dados (evite o caos)
- Padrões de tópicos (ex.:
org/<site>/<area>/<equip>/<variavel>) e catálogo de tags versionado. - Versionamento de payload (
v1,v2) para evoluir sem quebrar assinantes. - Políticas de retenção: brutos curto prazo; agregados 1m/15m longo prazo.
- Observabilidade: métricas do broker, filas, taxa de mensagens, erros, status de gateways.
Custos: como equilibrar CapEx e OpEx
No edge: hardware (gateway/PLC, storage local), manutenção e atualizações OTA. Na nuvem: armazenamento, tráfego, consultas e usuários. Estratégias:
- Publicar por variação (delta) ou janelas agregadas para reduzir tráfego.
- Compactar no edge (quando possível) e usar formatos enxutos de payload.
- Separar dados essenciais de diagnósticos; evitar “telemetria tagarela”.
Segurança: dividir para conquistar
- Segmentação OT/IT com firewalls e rotas explícitas.
- TLS em trânsito; autenticação por usuário/senha ou certificados.
- ACL por tópico, princípios de mínimo privilégio.
- Inventário de dispositivos e gestão de chaves/credenciais.
Exemplo prático: água predial
Edge: lê nível (ultrassônico), estado de bomba, corrente; aplica histerese para evitar “liga/desliga” rápido; detecta sobrecorrente; agrega nível a cada 10s; mantém store & forward local. Cloud: recebe medições e eventos via MQTT (QoS 1); armazena brutos 7 dias e agregados por 1 ano; dashboards com runtime, ciclos/h e disponibilidade; alarmes com notificação por equipe.
Checklist para desenhar sua arquitetura
- Liste requisitos de latência e criticidade por caso de uso.
- Defina quais decisões ficam no edge (segurança, tratamento de sinal, agregação/compactação).
- Escolha o modelo de broker (local, nuvem, híbrido) e configure QoS/retained/LWT.
- Estabeleça padrões de tópicos e versionamento de payload.
- Implemente buffer offline e políticas de retenção de dados.
- Projete segurança: TLS, ACL, segmentação, gestão de credenciais.
- Planeje custos: taxa de mensagens, armazenamento, usuários e relatórios.
- Teste falhas: queda de internet, reinicialização de gateway, perda de energia, bursts de dados.
Conclusão: coloque lógica crítica e resiliência no edge; use a nuvem para história, análise e colaboração. O padrão híbrido, amarrado por MQTT com boas práticas (QoS 1, retained/LWT, governança de tópicos e payloads), entrega previsibilidade, custos equilibrados e escala.