Visión artificial en el borde: guía de evaluación industrial

Evaluar visión en el borde exige algo más concreto que comprobar si el modelo dibuja un rectángulo correcto. Hay que demostrar cómo una imagen controlada produce una decisión oportuna, trazable y coherente con supuestos explícitos. El procedimiento siguiente usa cuadros generados o grabados y un destino PLC sintético. No valida cámara en vivo, actuador, red de planta, función de seguridad ni preparación para producción.

1. Definir primero el contrato óptico

Antes de elegir el modelo, documente posición de cámara, lente, foco, exposición, resolución, modo de disparo, pose esperada, velocidad y vibración admisible. Para la iluminación, registre geometría, intensidad, temperatura de color, difusión y protección contra luz ambiente. Una puntuación alta no corrige un cambio óptico desconocido.

Declare una ROI en coordenadas de píxeles y justifique qué queda fuera. La prueba de este lote usa [20, 20, 80, 80] y descarta detecciones cuyo centro no pertenece a esa región. Es una regla verificable, no un método universal. Durante el comisionamiento debe confirmarse que todas las tolerancias mantienen la pieza dentro de la ROI y que ninguna zona excluida puede contener un defecto relevante.

2. Separar entrada grabada de captura real

OpenCV documenta VideoCapture para archivos de video, secuencias de imágenes, cámaras y flujos IP. La API actual también permite solicitar una API de captura y consultar getBackendName() una vez abierta la fuente. El resumen de Video I/O muestra cómo seleccionar el backend en tiempo de ejecución. Esto sustenta un banco reproducible con archivos y backend declarado, pero no prueba el comportamiento de una cámara o un controlador específicos.

Fije versión de OpenCV, checksum del archivo, dimensiones, formato de píxel posterior a la decodificación, backend solicitado y reportado, y cantidad de cuadros. Devuelva fallo si la fuente no abre, un cuadro no se decodifica, cambian las dimensiones o el backend no coincide con la configuración aprobada. Un video grabado no reproduce jitter de disparo, pérdida de paquetes, transiciones de exposición, suciedad de lente ni buffering en vivo.

3. Preparar una prueba determinista y privada

Priorice imágenes geométricas generadas. Si necesita material grabado, use muestras fabricadas sobre fondo neutro: sin personas, credenciales, pantallas, etiquetas, números de serie, audio ni datos de clientes. Conserve el clip mínimo, elimine metadatos y publique un checksum en lugar de imágenes sensibles.

El verificador define detecciones deterministas para tres casos: defecto dentro de la ROI, detección de alta confianza fuera de ella y cuadro vencido. Con umbrales y tiempos fijos, las respuestas esperadas son REJECT, CLEAR y UNKNOWN. Así se prueban ROI, antigüedad y decisión sin OpenCV, runtime de inferencia, red ni hardware.

4. Tratar la incertidumbre como resultado

Use como mínimo REJECT, CLEAR y UNKNOWN. Reserve UNKNOWN para cuadros vencidos o ausentes, error de decodificación, inferencia no disponible, salida inválida y excepciones de política. Nunca transforme silenciosamente una observación inexistente en CLEAR.

Calibre umbrales con datos etiquetados de aceptación. Un falso rechazo desperdicia producto bueno o detiene el flujo; una omisión libera un defecto. Calidad, producto y operaciones deben acordar el costo permitido por clase. Informe matriz de confusión y cantidades de falsos rechazos y omisiones sobre un conjunto reservado, y revise los casos ambiguos. Los peligros asociados a seguridad requieren análisis independiente y controles certificados; este clasificador no es una función de seguridad.

5. Medir desde inferencia hasta decisión

Marque disponibilidad del cuadro y emisión de la decisión con el mismo reloj monotónico. Publique percentiles y peor valor observado, no FPS o latencia genéricos. Compare la distribución con el presupuesto de scan del PLC y takt de máquina, incluyendo márgenes de transporte y actuación definidos por ingeniería de control. Esa comparación indica compatibilidad presupuestaria; no acopla de forma determinista la inferencia Linux con el scan del PLC.

Todo benchmark debe identificar hardware y acelerador, sistema y versiones, modelo y forma de entrada, tamaño de batch, cantidad de muestras, calentamiento y método de reloj. También debe declarar si incluye preprocesamiento, transferencia host-dispositivo, inferencia, transferencia dispositivo-host, posprocesamiento y lógica de decisión. Este artículo no presenta resultados porque no se suministró una ejecución autorizada con ese registro completo.

6. Evitar que la cola esconda cuadros viejos

Limite la cola. Si la inferencia queda atrás, descarte cuadros reemplazados o detenga la entrada según el contrato; no permita crecimiento invisible de latencia. Cada cuadro y decisión debe llevar instante de captura y secuencia. Rechace secuencias duplicadas o desordenadas y emita UNKNOWN al superar la antigüedad máxima. Observe profundidad de cola, descartes, decisiones vencidas, errores de decodificación e inferencia.

7. Terminar en un destino PLC sintético

En esta evaluación, envíe {sequence, capturedAt, decidedAt, result, reason} a un destino PLC sintético en memoria. Compruebe orden, una decisión por secuencia aceptada y fallo cerrado. No escriba GPIO, registros Modbus, tags de PLC ni actuadores. Integrar producción exige direccionamiento bajo control del equipo OT, diseño eléctrico, autenticación y segmentación cuando correspondan, timeouts, heartbeat, enclavamientos y una respuesta segura probada por separado.

8. Comisionar con evidencia revisable

• Bloquee versiones de cámara, lente, luz, ROI, software, modelo y umbrales.
• Repita las pruebas con muestras grabadas aprobadas y decisiones esperadas.
• Mida todas las etapas temporales en hardware identificado y compárelas con el presupuesto revisado.
• Introduzca desenfoque, reflejo, oclusión, desplazamiento, cuadros ausentes, inferencia detenida y destino desconectado.
• Obtenga aprobación de calidad para falsos rechazos y omisiones, y de control antes de conectar un PLC.

9. Operar, detectar degradación y retroceder

Genere alertas por tasa de cuadros vencidos, UNKNOWN, distribución de clases, falsos rechazos revisados, omisiones confirmadas, profundidad de cola, limitación térmica, presión de almacenamiento y deriva visual. Retenga muestras privadas solo durante el plazo definido. Un panel ayuda a investigar; no demuestra por sí mismo que la inspección siga siendo válida.

El rollback deshabilita al consumidor de decisiones, restaura modelo y configuración aprobados como una unidad versionada y devuelve la autoridad al proceso alternativo documentado. Conserve logs y resultados. No reintente automáticamente órdenes de actuación ni interprete UNKNOWN como aceptación. Repita el comisionamiento tras cambiar cámara, iluminación, ROI, modelo, runtime o presupuesto temporal.

Referencias oficiales de OpenCV

• API VideoCapture de OpenCV 4.x: fuentes aceptadas, API preferida, estado de apertura, captura de cuadros y nombre del backend usado.
• Resumen de Video I/O de OpenCV: selección del backend en tiempo de ejecución para dispositivos y archivos.

Estas referencias delimitan la entrada de software. La prueba y el comisionamiento deben demostrar el comportamiento del sistema de inspección concreto.