Inspeção Visual com IA na Manufatura: da Câmera ao Aprovado/Reprovado via MQTT

A inspeção visual com IA usa câmeras e modelos treinados para decidir se uma peça está boa ou defeituosa, na velocidade da linha e sem a fadiga do operador. Este artigo explica como uma estação de inspeção é montada, quais defeitos a IA trata melhor do que a visão de máquina baseada em regras e como publicar cada resultado aprovado/reprovado via MQTT para que o controle de linha, os dashboards e os registros de rastreabilidade fiquem sincronizados.

O que a inspeção visual com IA faz

A visão de máquina tradicional depende de regras ajustadas manualmente: medir uma borda, contar pixels acima de um limiar, comparar com um template. Isso funciona bem para verificações dimensionais em peças consistentes. Mas tem dificuldade quando os defeitos variam de forma e aparência, como riscos, amassados, porosidade, contaminação, rótulos enrugados ou soldas irregulares, ou quando a iluminação e o acabamento das peças mudam durante o turno.

A inspeção visual com IA substitui ou complementa essas regras com um modelo aprendido. Dependendo do problema, o modelo é de um destes três tipos:

1. Classificação: a imagem inteira recebe o rótulo ok ou ng (not good, reprovada), ou é atribuída a uma classe de defeito.
2. Detecção de objetos ou segmentação: o modelo desenha caixas ou máscaras em torno dos defeitos, para que você saiba onde estão e qual o tamanho.
3. Detecção de anomalias: o modelo é treinado principalmente com peças boas e sinaliza qualquer coisa que pareça incomum. Isso é valioso quando amostras defeituosas são raras, o que é comum em uma linha madura.

O resultado que importa para a fábrica, seja uma autopeças em Joinville ou uma linha de eletrônicos em Manaus, é simples: um veredito, uma confiança, o tipo de defeito e um identificador que vincula o resultado a uma peça específica. Publicado de forma estruturada, esse mesmo resultado também pode alimentar o gêmeo digital da linha.

Anatomia de uma estação de inspeção

Uma estação funcional é muito mais do que um modelo. Os componentes que decidem se ela terá sucesso costumam ser físicos.

A iluminação merece a maior atenção. Uma boa configuração de iluminação torna os defeitos óbvios para uma pessoa olhando a imagem bruta; se você não consegue ver o risco, é improvável que o modelo aprenda a detectá-lo de forma confiável.

Construindo o modelo de defeitos

O fluxo de trabalho do modelo segue um caminho previsível:

1. Colete imagens da estação real, com a câmera, a lente e a iluminação definitivas. Imagens feitas com um celular na bancada não se transferem.
2. Rotule de forma consistente. Escreva um catálogo curto de defeitos com exemplos de cada classe e da fronteira entre aceitável e rejeitado. Divergência entre rotuladores vira ruído no modelo.
3. Treine e valide com imagens que o modelo nunca viu, incluindo peças de lotes e turnos diferentes.
4. Escolha o limiar junto com os engenheiros de qualidade. Deixar passar um defeito (escape) e rejeitar uma peça boa (falsa rejeição) têm custos muito diferentes, então o limiar de confiança é uma decisão de negócio.
5. Rode primeiro em modo sombra: o modelo publica vereditos, mas não dispara rejeições, e você compara com a inspeção manual.
6. Implante na borda, normalmente como um modelo otimizado em uma GPU ou acelerador ao lado da câmera. Veja como implantar modelos de ML em dispositivos de borda para estratégias de empacotamento e atualização.

A inferência pertence à borda porque a decisão de rejeição precisa acontecer antes que a peça saia da janela de rejeição. Enviar imagens completas para a nuvem adiciona latência e consumo de banda sem nenhum benefício. O que trafega pela rede é o resultado. A comparação entre edge AI e IA na nuvem aborda esse trade-off em mais detalhes.

Por que MQTT para resultados de inspeção visual com IA

Um veredito de inspeção tem vários consumidores: o CLP ou controlador de linha que aciona a rejeição, o MES ou banco de dados de rastreabilidade que registra o resultado associado a um número de série, um painel andon, um dashboard de qualidade e possivelmente o notebook de um engenheiro durante o comissionamento. Criar conexões ponto a ponto com cada um deles é frágil. Com publish/subscribe, a estação publica uma vez e cada consumidor assina o que precisa.

O MQTT se encaixa bem porque é leve, oferece QoS 1 para entrega pelo menos uma vez e permite publicar um status retido da estação, para que um dashboard que inicie depois saiba imediatamente se a estação está online. Hierarquias de topics que seguem os níveis ISA-95 dão a cada resultado um endereço claro, por exemplo:

connectmq/plant1/assembly/line2/inspect1/result
connectmq/plant1/assembly/line2/inspect1/status
connectmq/plant1/assembly/line2/inspect1/stats
connectmq/plant1/assembly/line2/inspect1/cmd/threshold

O ConnectMQ detecta topics no estilo ISA-95 e Unified Namespace e exibe os dispositivos por empresa, planta, área, linha e célula na sua visualização de dispositivos, o que facilita navegar por um conjunto crescente de estações de inspeção. Se você já usa Sparkplug B na linha, o guia de Sparkplug B e Unified Namespace explica como os dois estilos de topic coexistem.

Projeto do payload de resultado

Mantenha uma mensagem por peça inspecionada, pequena e autodescritiva:

{
  "partId": "SN-24-104877",
  "ts": "2026-10-16T09:41:07.312Z",
  "verdict": "ng",
  "defect": "scratch",
  "confidence": 0.93,
  "bbox": [412, 188, 470, 214],
  "model": "housing-defects-v7",
  "threshold": 0.80,
  "inferenceMs": 18,
  "imageRef": "inspect1/2026-10-16/SN-24-104877.jpg"
}

Os campos model e threshold são o que torna os resultados rastreáveis meses depois: quando chega uma reclamação de cliente, você pode mostrar qual versão do modelo julgou a peça e com qual configuração. A imagem em si fica no armazenamento local ou vai para um repositório de imagens; a mensagem MQTT carrega uma referência, não os pixels.

Exemplo: publicando resultados de inspeção em Python

Este exemplo simula o loop da estação com paho-mqtt 2.x. Substitua run_model() pela sua chamada de inferência real. Ele publica resultados com QoS 1, um status online/offline retido com Last Will e estatísticas periódicas de rendimento.

import json
import random
import time
import uuid
from datetime import datetime, timezone

import paho.mqtt.client as mqtt

HOST, PORT = "broker.connectmq.com", 1883
RUN_ID = uuid.uuid4().hex[:8]
BASE = f"connectmq/demo/{RUN_ID}/plant1/assembly/line2/inspect1"
MODEL = "housing-defects-v7"
threshold = 0.80


def run_model(image=None):
    """Substituto da inferência real: retorna (label, confidence, bbox)."""
    if random.random() < 0.08:
        return random.choice(["scratch", "dent", "missing_screw"]), random.uniform(0.6, 0.99), [412, 188, 470, 214]
    return "ok", random.uniform(0.85, 0.99), None


def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)
    client.subscribe(f"{BASE}/cmd/threshold", qos=1)


def on_message(client, userdata, msg):
    global threshold
    try:
        value = float(msg.payload)
        if 0.5 <= value <= 0.99:
            threshold = value
            print("threshold set to", threshold)
    except ValueError:
        print("ignored invalid threshold", msg.payload)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"inspect1-{RUN_ID}")
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, PORT, keepalive=30)
client.loop_start()

ok = ng = 0
try:
    for n in range(1, 10_000):
        start = time.perf_counter()
        label, conf, bbox = run_model()
        inference_ms = round((time.perf_counter() - start) * 1000, 1)
        verdict = "ng" if label != "ok" and conf >= threshold else "ok"
        ok, ng = (ok + 1, ng) if verdict == "ok" else (ok, ng + 1)
        part_id = f"SN-{RUN_ID}-{n:06d}"
        result = {
            "partId": part_id,
            "ts": datetime.now(timezone.utc).isoformat(timespec="milliseconds"),
            "verdict": verdict,
            "defect": None if label == "ok" else label,
            "confidence": round(conf, 3),
            "bbox": bbox,
            "model": MODEL,
            "threshold": threshold,
            "inferenceMs": inference_ms,
        }
        client.publish(f"{BASE}/result", json.dumps(result), qos=1)
        if n % 20 == 0:
            stats = {"ok": ok, "ng": ng, "yield": round(ok / (ok + ng), 4)}
            client.publish(f"{BASE}/stats", json.dumps(stats), qos=1, retain=True)
        time.sleep(0.5)   # fica bem abaixo do limite de 10 msg/s por cliente do broker público
finally:
    client.publish(f"{BASE}/status", "offline", qos=1, retain=True)
    client.loop_stop()
    client.disconnect()

Acompanhe os resultados em outro terminal, substituindo o ID pelo que aparece no topic:

mosquitto_sub -h broker.connectmq.com -p 1883 -i qa-viewer-91c2 \
  -t 'connectmq/demo/<run-id>/plant1/assembly/line2/inspect1/#' -v

O servidor MQTT público em broker.connectmq.com serve para experimentar o payload e o design de topics, mas é aberto a todos. Dados de inspeção de produção pertencem a um broker privado com TLS na porta 8883, usando as credenciais e o client ID emitidos para a estação.

Fechando o ciclo com o controle de linha

O atuador de rejeição não deve depender de uma ida e volta à nuvem. Na maioria das plantas, a estação sinaliza a rejeição diretamente ao CLP por I/O ou fieldbus, e o MQTT transporta o mesmo veredito para todo o resto: contagem, rastreabilidade, dashboards e alarmes. Onde um CLP ou controlador de borda assinar o topic de resultado, mantenha o broker perto da linha ou garanta que a lógica de rejeição falhe de forma segura quando a conexão cair.

Algumas regras mantêm o sistema confiável:

1. Publique uma confirmação de rejeição a partir do sensor do desviador, para poder comparar os vereditos ng com as rejeições reais.
2. Coloque a versão do modelo em todas as mensagens e mantenha um topic status retido descrevendo o modelo ativo.
3. Restrinja quem pode publicar nos topics cmd/ e valide cada valor de comando na estação, como o exemplo faz com o limiar.
4. Gere alertas para desvios de rendimento. Uma queda repentina no rendimento costuma ser um problema de iluminação ou de câmera, e não um problema real de qualidade.

As regras de alerta por limiar do ConnectMQ podem monitorar valores numéricos, como o rendimento em uma mensagem de estatísticas, e registrar alertas no log de alertas, uma forma rápida de perceber desvios sem construir um serviço de monitoramento separado.

Problemas comuns em produção

Para projetos de visão relacionados, veja detecção de objetos com YOLO via MQTT, o guia de Jetson Nano com MQTT e o guia principal de IA e IoT.

Conecte suas estações de inspeção ao ConnectMQ

Cada estação, dashboard e gravador de rastreabilidade precisa de um ponto de encontro confiável. O ConnectMQ oferece um broker MQTT gerenciado com TLS, MQTT 5, visualização de dispositivos ISA-95 e alertas por limiar, sem que você precise operar infraestrutura de broker na rede da planta. Crie um broker no plano gratuito Serverless em app.connectmq.com, sem cartão de crédito, e migre para uma implantação Dedicated ou BYOC quando a linha entrar em produção. Se você ainda está avaliando, o broker MQTT público de testes é um bom lugar para prototipar o payload.

Perguntas frequentes

Quantas imagens são necessárias para treinar um modelo de inspeção visual com IA?

Depende de quão variadas são as peças e os defeitos. Comece com imagens da estação real, cubra todas as classes de defeito e a variação normal, e adicione exemplos sempre que o modelo deixar passar algo no modo sombra.

As imagens devem ser enviadas via MQTT?

Em geral, não. Envie o veredito, a confiança e uma referência da imagem via MQTT e armazene as imagens localmente ou em um object store, porque mensagens binárias grandes esbarram nos limites de tamanho do broker e deixam todos os assinantes mais lentos.

A inspeção visual com IA pode substituir a visão de máquina baseada em regras?

Nem sempre. A medição dimensional precisa ainda é mais bem feita com regras, enquanto a IA lida com defeitos estéticos variáveis. Muitas estações combinam as duas abordagens e publicam um único veredito.

Qual QoS os resultados de inspeção devem usar?

QoS 1 é a escolha usual, porque todo resultado precisa chegar para garantir a rastreabilidade. Torne a inserção no banco idempotente pelo ID da peça, para que duplicatas ocasionais não causem problemas.