Demuestre inspección automatizada en sus propios productos
Empieza con un filtro de viabilidad sobre sus muestras reales, porque algunas tareas visuales no son resolubles a la velocidad de su línea y es más barato saberlo en la primera semana. Lo que sigue es diseño de imagen, datos anotados, un modelo validado y una prueba controlada en línea, con resultados por clase de defecto, y los defectos no detectados y los rechazos incorrectos contados por separado.
Comprobar mi caso de uso de visiónHablar con un ingeniero de fabricación¿Es este el problema que necesita resolver?
- La inspección visual depende de la atención de una persona al final de un turno largo.
- El mismo tipo de defecto sigue llegando al cliente y nadie puede decir con qué frecuencia.
- La inspección es la razón por la que la línea no puede ir más rápido.
- Un proyecto de visión anterior se aceptó por una cifra de exactitud y falló en los defectos que importaban.
Interlocutor principal: Responsable de calidad · Responsable de producción · Responsable de automatización · Responsable de ingeniería · Director de planta
Qué demostrará este PoC
Alcance recomendado del piloto
- Una estación de inspección y una familia de producto, incluidas sus variantes reales.
- Un conjunto delimitado y nombrado de clases de defecto o verificación — no "cualquier defecto".
- Cámara, óptica e iluminación seleccionadas después del paso de diseño de imagen.
- Un flujo de rechazo o confirmación del operario, para que una decisión lleve a una acción.
- Muestras de entrenamiento, validación y aceptación mantenidas estrictamente separadas en todo momento.
Qué estará funcionando durante el PoC
Cómo se desarrolla este PoC
Las duraciones son habituales, no garantizadas. Lo que alarga un calendario: datos incompletos o ausentes, aprobaciones de seguridad y de red, plazos de entrega de hardware, recogida de muestras, acceso para la instalación, el plan de producción, el acceso al entorno de pruebas del ERP y el tiempo que su equipo necesita para revisar los resultados.
No se prevé ninguna parada imprevista. Cualquier ventana de instalación o interrupción controlada se acuerda con usted por adelantado y se planifica en torno a la producción.
Cómo se medirá el éxito
| Métrica | Cómo se define | De dónde sale el dato | Tipo |
|---|---|---|---|
| Precisión por clase de defecto | De las piezas marcadas para una clase, la proporción que realmente pertenece a ella — reportada por clase, nunca promediada en una sola cifra. | Conjunto de validación reservado | Técnica |
| Exhaustividad por clase de defecto | De las piezas que realmente muestran una clase, la proporción detectada — reportada por clase y por variante de producto. | Conjunto de validación reservado | Técnica |
| Tasa de falsos positivos | Piezas defectuosas aprobadas como buenas. Contadas y reportadas por separado de los rechazos incorrectos, porque su coste de negocio es completamente distinto. | Conjunto de validación reservado | Técnica |
| Tasa de rechazos incorrectos | Piezas buenas rechazadas. La cifra que decide si los operarios mantendrán el sistema encendido. | Conjunto de validación reservado | Operativa |
| Matriz de confusión y número de muestras | Matriz completa clase por clase con el número de muestras por clase, para que el lector pueda juzgar cuánto vale el resultado. | Conjunto de validación reservado | Técnica |
| Latencia de procesamiento y cumplimiento de velocidad de línea | Tiempo de inspección por pieza frente al tiempo de ciclo disponible, medido en la línea en lugar de en un puesto de trabajo. | Datos de la plataforma MSF | Técnica |
| Tasa de clasificación incierta | Proporción de piezas que el modelo no pudo decidir con confianza, lo que el flujo de confirmación del operario tiene que absorber. | Conjunto de validación reservado | Operativa |
| Disponibilidad y comportamiento de confirmación del operario | Disponibilidad del sistema durante la prueba en línea, y cómo gestionaron realmente los operarios confirmaciones y anulaciones. | Datos de la plataforma MSF | Adopción |
Antes de implantar nada, MSF y su equipo acuerdan cómo se calcula cada métrica, de dónde sale la línea base, qué datos quedan excluidos y qué resultado respalda una decisión de despliegue. Esta página enumera lo que se mide; los objetivos concretos pertenecen al alcance escrito del PoC, no a una promesa comercial.
Lo que usted aporta
- Piezas o imágenes OK y NOK representativas, que cubran cada variante y cada clase de defecto en alcance.
- Definiciones de defecto, reglas de severidad y los niveles aceptables de falsos positivos y rechazos incorrectos.
- Tiempo de ciclo, velocidad de línea, campo de visión y las condiciones ambientales en la estación.
- Detalles de la interfaz de PLC o rechazo y cualquier requisito de trazabilidad.
Quién hace qué
Meta Smart Factory aporta
- Taller de descubrimiento y facilitación del alcance
- Configuración de la solución para el alcance acordado
- Trabajo de integración y conexión dentro de ese alcance
- Hardware MSF incluido en la propuesta
- Formación de los usuarios del piloto
- Las definiciones de KPI y el método de validación
- Seguimiento de incidencias y soporte durante el piloto
- El informe final de resultados y el diseño del despliegue
- El veredicto de viabilidad, el diseño de imagen y una versión de modelo validada con su evaluación reproducible.
- Ejemplos de fallo —las imágenes en las que se equivocó— y no solo las que acertó.
Usted aporta
- Un responsable de negocio y un responsable técnico designados
- Acceso puntual a usuarios, línea, máquinas y sistemas autorizados
- Una explicación fiel del proceso y de los datos maestros
- Acceso de red, energía, montaje y seguridad
- Documentación de ERP, PLC y proveedores, y los expertos que la conocen
- Muestras representativas o datos históricos
- La validación de que la línea base es justa
- Retroalimentación y la decisión de aceptación
- Suficientes muestras NOK genuinas por clase; los defectos raros son los más difíciles y los más importantes de aportar.
- Acceso a la línea para la prueba controlada a velocidad de producción normal.
Se define en la propuesta escrita
- Panel PC, tabletas, servidores y servidores con GPU
- Cámaras, ópticas, iluminación y envolventes
- Lectores, impresoras, dispositivos RFID, contadores y sensores
- Viajes, instalación, transporte, aranceles y trabajo eléctrico local
- Si el hardware se alquila o se compra
- Si el importe del PoC se descuenta de un despliegue
Las condiciones comerciales, la propiedad del hardware, los viajes, el alcance de la integración y cualquier descuento sobre el despliegue se definen en la propuesta escrita del PoC. No son iguales para todos los productos y esta página no los promete.
Lo que recibe al final
- Veredicto de viabilidad con el razonamiento detrás.
- Diseño de imagen e iluminación validado sobre piezas reales.
- Una versión de modelo validada con una evaluación reproducible.
- Informe de métricas por clase de defecto, con ejemplos de fallo incluidos.
- Lista de riesgos y limitaciones que cubre las condiciones que lo degradan.
- Cuadro de cantidades de hardware, arquitectura de integración y recomendación de despliegue.
Dependencias, exclusiones y límites
Este PoC depende de
- Suficientes muestras NOK genuinas por clase — la causa más habitual de retraso en un PoC de visión.
- Presentación estable de la pieza en la estación, o un utillaje acordado para lograrla.
No incluido en este PoC
- Clases de defecto no nombradas en el alcance, y variantes de producto no representadas en las muestras.
- Manipulación mecánica, utillaje y construcción del mecanismo de rechazo.
La exactitud global nunca se usa como métrica de aceptación — sobre un conjunto de defectos desequilibrado puede parecer excelente mientras se pierde todos los defectos que importan. Los resultados se reportan por clase con el número de muestras, y no se hace ninguna afirmación para tipos de defecto, variantes o condiciones que no estuvieran en el conjunto validado.
Seguir, ajustar o parar: el punto de decisión
Preguntas frecuentes
¿Cuántas piezas de muestra necesitan?
Depende de cuán variable sea el defecto y el producto, y el filtro de viabilidad da una cifra concreta para su caso. Como regla, la restricción no son las piezas OK —esas están por todas partes— sino ejemplos NOK genuinos por clase, especialmente los defectos raros que son la razón entera del proyecto.
¿Por qué no simplemente reportar exactitud?
Porque en una línea que produce un 2% de defectos, un modelo que aprueba todo obtiene un 98% de exactitud y no detecta ninguno. La precisión y la exhaustividad por clase, más los falsos positivos y los rechazos incorrectos por separado, son las únicas cifras que describen lo que realmente pasará en su línea.
¿Qué pasa si el filtro de viabilidad dice que no?
Recibe el razonamiento, la evidencia de imagen y, donde exista, una alternativa —un punto de inspección distinto, una geometría de iluminación distinta, o una comprobación basada en sensor en lugar de visual. Un no claro en la primera semana es un buen resultado comparado con una celda fallida en el noveno mes.
¿Funcionará más adelante con nuevos tipos de defecto?
No automáticamente, y esto se indica en la lista de limitaciones en lugar de disimularse. Un modelo detecta aquello para lo que se entrenó y validó. Las clases de defecto nuevas necesitan muestras nuevas, reentrenamiento y una validación fresca — una actividad normal y planificable, pero no gratuita.
Productos y programas PoC relacionados
Solicitar este Proof of Concept
Cuéntenos el alcance que tiene en mente y le responderemos con un plan de PoC por escrito: qué se conecta, qué aporta usted, cómo se mide el éxito y cómo será la decisión final.