IoT e IA

Detecção de Anomalias em IoT: Métodos, Arquitetura e Onde Rodar os Detectores

Um guia prático para detectar anomalias em fluxos de sensores: quais métodos se encaixam em quais sinais, se devem rodar no dispositivo, na borda ou na nuvem e como o MQTT conecta detectores e alertas.

Diagrama de arquitetura de detecção de anomalias em IoT com sensores, um broker MQTT, detectores na borda e na nuvem e um topic de alertas
Rode isso no seu próprio broker MQTTTenha um broker MQTT privado e gerenciado no plano Free e comece com exemplos de código prontos.
Teste grátis Exemplos de código Sem cartão de crédito

Detecção de anomalias em IoT significa identificar automaticamente leituras ou padrões de sensores que não correspondem ao comportamento normal, cedo o bastante para agir. Este guia compara as principais famílias de detectores, mostra onde cada uma deve rodar em relação ao seu broker MQTT e oferece uma arquitetura de referência para publicar eventos de anomalia em que dashboards e pessoas possam confiar.

O que conta como anomalia em dados IoT

Nem todas as anomalias são iguais, e o tipo que importa para você define o método.

  • Anomalias pontuais. Uma única leitura muito fora da faixa normal: uma temperatura de 140 graus em um sensor que nunca passa de 80.
  • Anomalias contextuais. Um valor normal em um contexto e anormal em outro: 30 graus é normal ao meio-dia no verão e suspeito às 3 da manhã na câmara fria de um frigorífico.
  • Anomalias coletivas. Um padrão ao longo do tempo: uma vibração dentro dos limites em todas as amostras, mas cujo espectro se desloca lentamente em direção a uma frequência de falha de rolamento.
  • Anomalias multivariadas. Cada sinal é normal isoladamente, mas a combinação não é: corrente alta no motor com vazão baixa sugere uma bomba obstruída.

Há também uma categoria que não tem nada a ver com o processo: anomalias de qualidade de dados, como um sensor com sinal achatado, um valor travado, uma mudança repentina de unidade ou timestamps chegando fora de ordem. Na prática, esses estão entre os alertas mais comuns, e detectá-los primeiro evita que os seus detectores de processo gerem alarmes falsos.

Famílias de métodos de detecção de anomalias em IoT

Família Exemplos Indicada para Precisa de dados de treinamento Roda em microcontrolador
Regras e limites Limites fixos, limites de taxa de variação Modos de falha conhecidos, limites de segurança Não Sim
Estatística Z-score, IQR, EWMA, janelas móveis Sinais individuais com linha de base estável Um histórico curto Sim
Machine learning clássico Isolation Forest, One-Class SVM, Local Outlier Factor Características tabulares multivariadas Dados normais, sem rótulo Às vezes
Deep learning Autoencoders, preditores LSTM ou 1D-CNN Formas de onda, espectros, padrões temporais complexos Grande conjunto de dados normais Apenas modelos pequenos
Resíduo de previsão Modelos sazonais, previsões com gradient boosting Sinais sazonais como carga de energia Histórico com estações Raramente

Detectores estatísticos

Comece por aqui. Uma média e um desvio-padrão móveis, ou uma mediana e um intervalo interquartil, detectam uma parcela surpreendente dos problemas reais com quase nenhum esforço de engenharia. A EWMA (média móvel exponencialmente ponderada) se adapta a derivas lentas sem armazenar uma janela. Esses métodos são explicáveis, baratos e fáceis de ajustar. Os detalhes e o código estão em detecção de outliers em dados de sensores com Z-score, IQR e EWMA.

Detectores de machine learning

Quando as anomalias se escondem na relação entre os sinais, treine um modelo não supervisionado com a operação normal. O Isolation Forest é um padrão prático: rápido de treinar, robusto a variáveis irrelevantes e não precisa de rótulos. Você cria características por janela (média, RMS, pico, inclinação por sinal) e o modelo pontua o quão isolada cada janela está. Um passo a passo completo está em Isolation Forest para dados de sensores.

Detectores de deep learning

Para formas de onda brutas, como vibração e som, os autoencoders aprendem a reconstruir os padrões normais; um erro de reconstrução alto sinaliza algo novo. Eles exigem mais dados e processamento e são mais difíceis de explicar, então use-os quando características mais simples realmente falharem. O som de máquinas é um bom exemplo, abordado em detecção de anomalias de áudio em máquinas.

Onde os detectores rodam em relação ao broker

O MQTT oferece uma separação limpa: os dispositivos publicam dados, os detectores assinam e publicam os resultados de volta como novas mensagens. O broker MQTT fica no meio e não precisa saber o que nenhum detector faz. Isso deixa três opções de posicionamento.

No dispositivo

Rode limites, verificações de taxa de variação e modelos minúsculos diretamente no nó sensor. Vantagens: reação imediata, nenhuma dependência de conectividade e a possibilidade de enviar apenas resumos mais eventos de anomalia, em vez de dados brutos em alta taxa. Limitações: modelos pequenos, atualizações mais difíceis e nenhum contexto entre dispositivos.

No gateway de borda

Um gateway ou PC industrial assina as máquinas locais, roda modelos mais pesados como Isolation Forest ou autoencoders e publica as pontuações. Esse é o ponto ideal para a detecção multivariada dentro de uma máquina ou linha, e mantém os dados de alta frequência na própria unidade.

Na nuvem

Um serviço na nuvem assina várias unidades ao mesmo tempo. Ele pode comparar máquinas semelhantes entre fábricas, por exemplo unidades em Campinas e em Manaus, rodar modelos caros e combinar dados de processo com contexto de negócio. A latência é maior e depende do link de saída, então é o lugar errado para qualquer coisa relacionada à segurança.

A maioria dos sistemas reais combina os três: limites no dispositivo, ML na borda e comparações de frota na nuvem, todos se comunicando por topics.

Uma arquitetura de topics de referência

connectmq/site1/area2/line1/pump3/telemetry      raw or aggregated readings
connectmq/site1/area2/line1/pump3/anomaly        detector output per asset
connectmq/site1/alerts                           confirmed alerts for people
connectmq/site1/area2/line1/pump3/detector/status  retained: model, version, health

Uma mensagem de saída do detector deve ser autoexplicativa:

{
  "ts": "2026-10-16T09:12:30Z",
  "asset": "pump3",
  "detector": "iforest-v3",
  "score": 0.71,
  "threshold": 0.62,
  "isAnomaly": true,
  "features": {"currentA": 18.4, "flowLpm": 41.0},
  "reason": "high current with low flow"
}

Incluir o limite, a versão do detector e as principais características que contribuíram transforma uma luz vermelha opaca em algo que um técnico consegue verificar.

Um loop de detector mínimo

O coração de qualquer detector em streaming cabe em poucas linhas. Este pontuador de z-score móvel é o padrão que o tutorial completo de detecção de anomalias em tempo real com Python expande em um serviço MQTT completo:

from collections import deque
import statistics

window = deque(maxlen=120)


def score(value, k=3.5):
    if len(window) < 30:
        window.append(value)
        return None
    mean = statistics.fmean(window)
    std = statistics.pstdev(window) or 1e-9
    z = (value - mean) / std
    if abs(z) < k:
        window.append(value)  # only learn from normal values
    return z

Repare no último detalhe: valores anômalos não são adicionados à linha de base, para que uma falha longa não se torne aos poucos o novo normal.

Reduzindo alarmes falsos

Alarmes falsos matam projetos de detecção de anomalias mais rápido do que detecções perdidas, porque os operadores param de prestar atenção. Uma checklist que ajuda:

  1. Filtre a qualidade dos dados primeiro. Sinalize valores travados, ausentes e fora da faixa separadamente das anomalias de processo.
  2. Use contexto. Ignore leituras durante partidas, limpezas e trocas de produto, que você pode detectar a partir de um topic de estado.
  3. Exija persistência. Gere um alerta somente após N janelas anômalas em M, não por uma única amostra.
  4. Adicione histerese. Encerre o alerta em um limite mais baixo do que o que o disparou, para evitar oscilações.
  5. Separe pontuação de alerta. Publique as pontuações brutas continuamente e decida sobre o alerta em uma etapa separada que você possa ajustar.
  6. Revise semanalmente. Marque cada alerta como útil ou ruído e ajuste os limites com base nesse registro.
  7. Versione os detectores. Coloque a versão do detector em toda mensagem para poder comparar antes e depois de uma mudança.

Operando a camada de mensageria

Detectores, dashboards, historiadores e ferramentas de alerta dependem todos do mesmo broker, então a confiabilidade dele importa. Para experimentos, o servidor MQTT público (gratuito) que o ConnectMQ mantém em broker.connectmq.com é suficiente para conectar um simulador, um detector e um dashboard em minutos, mas ele serve para testes e protótipos, não para dados de produção. Para dados reais da fábrica, você precisa de um broker MQTT gerenciado privado, como um broker MQTT na nuvem protegido por TLS e com credenciais por dispositivo.

O ConnectMQ fornece exatamente essa camada: MQTT 3.1.1 e 5.0 sobre TLS e WebSocket seguro, uma visão de dispositivos organizada por níveis ISA-95, um explorador de topics ao vivo para acompanhar as pontuações em tempo real e regras de alerta por limite com um registro de alertas para limites numéricos simples. Os modelos de detecção em si rodam nos seus serviços, o que deixa você livre para usar qualquer biblioteca.

Para entender como a detecção de anomalias se encaixa com previsão, visão computacional e assistentes LLM, leia o guia de IA e IoT.

Construa o seu pipeline de anomalias no ConnectMQ

Crie um broker no plano Serverless gratuito em app.connectmq.com, sem cartão de crédito, publique leituras simuladas e rode um detector que publique as pontuações de volta. Em poucos minutos, você verá valores brutos e eventos de anomalia lado a lado no explorador de topics.

Perguntas frequentes

Com qual método de detecção de anomalias devo começar?

Comece com limites e um z-score móvel ou EWMA em cada sinal importante. Passe para Isolation Forest ou autoencoders somente quando houver evidências de que as anomalias estão nas relações entre sinais ou nas formas de onda.

Preciso de dados de falha rotulados?

Não. A maior parte da detecção de anomalias em IoT é não supervisionada: os modelos aprendem o comportamento normal e sinalizam desvios. Os rótulos se tornam valiosos mais tarde, para avaliar e ajustar os alertas.

A detecção de anomalias deve rodar na borda ou na nuvem?

Rode verificações rápidas e relevantes para a segurança no dispositivo ou na borda, e comparações de toda a frota na nuvem. O MQTT permite mover um detector entre locais sem alterar os dispositivos.

Como publicar os resultados de anomalia?

Publique uma mensagem JSON por ativo em um topic de anomalia dedicado, incluindo a pontuação, o limite, a versão do detector e as características que contribuíram. Mantenha os alertas confirmados para pessoas em um topic separado.

Artigos relacionados

Todos os artigos →

Seu broker MQTT privado está a poucos cliques de distância

Crie uma conta, receba as credenciais do seu broker e conecte seu primeiro dispositivo — sem servidores para instalar, atualizar ou escalar.