Inspección visual con IA en fabricación: de la cámara al OK/NOK por MQTT

La inspección visual con IA utiliza cámaras y modelos entrenados para decidir si una pieza es buena o defectuosa, a la velocidad de la línea y sin la fatiga de un operario. Este artículo explica cómo se construye una estación de inspección, qué defectos resuelve la IA mejor que la visión artificial basada en reglas y cómo publicar cada resultado OK/NOK por MQTT para que el control de línea, los paneles y los registros de trazabilidad se mantengan sincronizados.

Qué hace la inspección visual con IA

La visión artificial tradicional se basa en reglas ajustadas a mano: medir un borde, contar píxeles por encima de un umbral, comparar con una plantilla. Funciona bien para comprobaciones dimensionales en piezas homogéneas. Le cuesta cuando los defectos varían de forma y aspecto, como arañazos, abolladuras, porosidad, contaminación, etiquetas arrugadas o soldaduras irregulares, o cuando la iluminación y el acabado de la pieza cambian durante un turno.

La inspección visual con IA sustituye o complementa esas reglas con un modelo aprendido. Según el problema, el modelo es de uno de estos tres tipos:

1. Clasificación: la imagen completa se etiqueta como ok o ng (no buena), o se le asigna una clase de defecto.
2. Detección de objetos o segmentación: el modelo dibuja cuadros o máscaras alrededor de los defectos, de modo que sabes dónde están y qué tamaño tienen.
3. Detección de anomalías: el modelo se entrena principalmente con piezas buenas y señala todo lo que parezca inusual. Es valioso cuando las muestras defectuosas son escasas, algo habitual en una línea madura.

El resultado que le importa a la fábrica es sencillo: un veredicto, una confianza, el tipo de defecto y un identificador que vincula el resultado a una pieza concreta.

Anatomía de una estación de inspección

Una estación que funciona es mucho más que un modelo. Lo que decide su éxito suele ser físico.

La iluminación merece la mayor atención. Una buena iluminación hace que los defectos resulten evidentes para una persona que mira la imagen en bruto; si tú no ves el arañazo, es poco probable que el modelo aprenda a detectarlo de forma fiable.

Construir el modelo de defectos

El flujo de trabajo del modelo sigue un camino previsible:

1. Recoge imágenes de la estación real, con la cámara, la óptica y la iluminación definitivas. Las imágenes tomadas con un móvil en el banco de trabajo no sirven.
2. Etiqueta de forma coherente. Redacta un catálogo breve de defectos con ejemplos de cada clase y del límite entre lo aceptable y el rechazo. Los desacuerdos entre etiquetadores se convierten en ruido para el modelo.
3. Entrena y valida con imágenes que el modelo nunca ha visto, incluidas piezas de distintos lotes y turnos.
4. Elige el umbral junto con los ingenieros de calidad. Dejar pasar un defecto (escape) y rechazar una pieza buena (falso rechazo) tienen costes muy distintos, así que el umbral de confianza es una decisión de negocio.
5. Funciona primero en modo sombra: el modelo publica veredictos pero no dispara rechazos, y los comparas con la inspección manual.
6. Despliega en el edge, normalmente como un modelo optimizado en una GPU o un acelerador junto a la cámara. Consulta desplegar modelos de ML en dispositivos edge para estrategias de empaquetado y actualización.

La inferencia debe hacerse en el edge porque la decisión de rechazo tiene que tomarse antes de que la pieza salga de la ventana de rechazo. Enviar imágenes completas a la nube añade latencia y consumo de ancho de banda sin ningún beneficio. Lo que viaja por la red es el resultado. La comparativa entre edge AI e IA en la nube analiza ese equilibrio con más detalle.

Por qué MQTT para los resultados de inspección visual con IA

Un veredicto de inspección tiene varios consumidores: el PLC o controlador de línea que acciona el rechazo, el MES o la base de datos de trazabilidad que registra el resultado asociado a un número de serie, un panel andon, un panel de calidad, un gemelo digital 3D de la línea que resalte la estación ante cada rechazo y, quizá, el portátil de un ingeniero durante la puesta en marcha. Cablear conexiones punto a punto con cada uno de ellos es frágil. Con publicación/suscripción, la estación publica una vez y cada consumidor se suscribe a lo que necesita.

MQTT encaja bien porque es ligero, admite QoS 1 para entregas al menos una vez y permite publicar un estado retenido de la estación, de modo que un panel que arranque más tarde sepa al instante si la estación está en línea. Las jerarquías de topics que siguen los niveles ISA-95 dan a cada resultado una dirección clara, por ejemplo:

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

ConnectMQ detecta topics de estilo ISA-95 y Unified Namespace y muestra los dispositivos por empresa, planta, área, línea y celda en su vista de dispositivos, lo que facilita moverse por un conjunto creciente de estaciones de inspección. Si ya usas Sparkplug B en la línea, la guía de Sparkplug B y Unified Namespace explica cómo conviven los dos estilos de topics.

Diseño del payload de resultados

Mantén un mensaje por pieza inspeccionada, pequeño y autodescriptivo:

{
  "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"
}

Los campos model y threshold son los que hacen que los resultados sean trazables meses después: cuando llega una reclamación de un cliente, puedes mostrar qué versión del modelo juzgó la pieza y con qué ajuste. La imagen en sí se queda en el almacenamiento local o va a un almacén de imágenes; el mensaje MQTT lleva una referencia, no los píxeles.

Ejemplo: publicar resultados de inspección en Python

Este ejemplo simula el bucle de la estación con paho-mqtt 2.x. Sustituye run_model() por tu llamada real de inferencia. Publica los resultados con QoS 1, un estado online/offline retenido con Last Will y estadísticas periódicas de rendimiento.

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):
    """Sustituto de la inferencia real: devuelve (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)   # muy por debajo de los 10 msg/s por cliente del broker público
finally:
    client.publish(f"{BASE}/status", "offline", qos=1, retain=True)
    client.loop_stop()
    client.disconnect()

Observa los resultados desde otro terminal, sustituyendo el ID por el que aparece en el topic:

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

El servidor MQTT público gratuito sirve para probar el diseño del payload y de los topics, pero está abierto a todo el mundo y no es lugar para datos de producción. Los datos de inspección de producción deben ir a un broker privado con TLS en el puerto 8883, con las credenciales y el client ID emitidos para la estación.

Cerrar el bucle con el control de línea

El actuador de rechazo no debe depender de un viaje de ida y vuelta a la nube. En la mayoría de las plantas, la estación envía la señal al PLC directamente por E/S o por un bus de campo para el propio rechazo, y MQTT transporta el mismo veredicto para todo lo demás: conteo, trazabilidad, paneles y alarmas. Cuando un PLC o un controlador edge sí se suscribe al topic de resultados, mantén el broker cerca de la línea o asegúrate de que la lógica de rechazo falle de forma segura si se cae la conexión.

Unas cuantas reglas mantienen el sistema fiable:

1. Publica una confirmación de rechazo desde el sensor del desviador, para poder cotejar los veredictos ng con los rechazos reales.
2. Incluye la versión del modelo en cada mensaje y mantén un topic status retenido que describa el modelo activo.
3. Restringe quién puede publicar en los topics cmd/ y valida cada valor de comando en la estación, como hace el ejemplo con el umbral.
4. Alerta ante la deriva del rendimiento. Una caída repentina del rendimiento suele deberse a un problema de iluminación o de cámara más que a un problema real de calidad.

Las reglas de alerta por umbral de ConnectMQ pueden vigilar valores numéricos, como el rendimiento en un mensaje de estadísticas, y registrar las alertas en el registro de alertas, lo que permite detectar la deriva rápidamente sin construir un servicio de monitorización aparte.

Problemas habituales en producción

Para proyectos de visión relacionados, consulta detección de objetos con YOLO sobre MQTT, la guía de Jetson Nano con MQTT y la guía principal de IA e IoT.

Conecta tus estaciones de inspección a ConnectMQ

Cada estación, panel y escritor de trazabilidad necesita un punto de encuentro fiable. ConnectMQ te ofrece un broker MQTT gestionado con TLS, MQTT 5, una vista de dispositivos ISA-95 y alertas por umbral, sin tener que operar infraestructura de broker en la red de la planta. Crea un broker con el plan Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y pasa a un despliegue Dedicated o BYOC cuando la línea entre en producción. Si todavía estás evaluando, el servidor público es un buen lugar para prototipar el payload.

Preguntas frecuentes

¿Cuántas imágenes necesito para entrenar un modelo de inspección visual con IA?

Depende de lo variadas que sean las piezas y los defectos. Empieza con imágenes de la estación real, cubre todas las clases de defecto y la variación normal, y añade ejemplos cada vez que el modelo falle algo en modo sombra.

¿Deben enviarse las imágenes por MQTT?

En general, no. Envía por MQTT el veredicto, la confianza y una referencia a la imagen, y guarda las imágenes en local o en un almacén de objetos, porque los mensajes binarios grandes chocan con los límites de tamaño del broker y ralentizan a todos los suscriptores.

¿Puede la inspección visual con IA sustituir a la visión artificial basada en reglas?

No siempre. La medición dimensional precisa se sigue haciendo mejor con reglas, mientras que la IA gestiona los defectos estéticos variables. Muchas estaciones combinan ambas y publican un único veredicto.

¿Qué QoS deben usar los resultados de inspección?

QoS 1 es la opción habitual, porque todos los resultados deben llegar para garantizar la trazabilidad. Haz que la inserción en la base de datos sea idempotente sobre el ID de pieza para que los duplicados ocasionales no causen problemas.