El aviso no termina el trabajo
Una bandeja sigue en la mesa de salida. La cámara señala la situación, llega un aviso y alguien lo abre. ¿Quién comprueba qué ocurre y quién confirma que la bandeja ya se ha retirado? Para plantear un piloto útil de visión artificial a medida, separa cuatro momentos: detectar, entregar el aviso, revisar el caso y cerrar la incidencia con un criterio acordado.
Esta guía propone una ficha de responsabilidades y pruebas para ese recorrido. Todo el caso de la bandeja es ficticio: no describe un cliente, una instalación realizada ni resultados de Adaris. La primera prueba sería supervisada y sin órdenes a maquinaria. Que una cámara pueda localizar esa bandeja en tu entorno debe comprobarse con material representativo.
Qué aporta Adaris y qué debes definir con tu equipo
El servicio de visión artificial a medida de Adaris parte de lo que debe detectarse, las condiciones de la escena y los errores tolerables. Su alcance público incluye detecciones, recuentos y alertas revisables, con pruebas sobre imágenes reales y control humano. El encargo concreto, el equipo y la integración se acuerdan para cada caso.
En ese recorrido, Studio prepara y revisa material, permite comparar resultados y preparar la solución; Player ejecuta localmente el paquete con las fuentes y opciones acordadas. El recorrido público describe reglas, alertas y evidencias. Cada Player trabaja con una fuente activa cada vez; sus capacidades dependen del paquete y de su licencia.
Esas funciones no definen por sí solas quién atiende una incidencia en tu negocio. La ficha de esta guía es una propuesta de proceso: no una pantalla de Player ni una promesa de conexión ya disponible con tu programa de tareas.
Escribe la regla de negocio antes de elegir el canal
Caso ficticio: el equipo quiere revisar una bandeja roja que permanece en una zona de salida después del tiempo que se acuerde para el ensayo. El color solo identifica la muestra del ejemplo; no significa defecto, urgencia ni rechazo de mercancía. Primero hay que pactar qué bandeja y qué zona son observables, cuánto dura la condición y qué hacer si la imagen no permite decidir.
No uses un número de segundos tomado de otra instalación como criterio universal. La persona responsable debe decidir qué demora merece revisión y cuándo una observación es insuficiente. Define también qué ocurre fuera del horario atendido antes de elegir correo, una aplicación o cualquier otro destino.
| Decisión | Propuesta del ejemplo | Qué falta acordar |
|---|---|---|
| Situación | Bandeja pendiente de retirar en la zona acordada. | Objeto observable, zona y permanencia. |
| Responsable | Una persona de operaciones revisa el caso. | Titular, sustituto y horario de atención. |
| Primer destino | Registro manual del piloto. | Si conviene integrar después un sistema concreto. |
| Cierre | La persona verifica la retirada y lo anota. | Prueba suficiente, responsable y motivo de cierre. |
| Fuera de alcance | Calidad del contenido y órdenes a equipos. | No deducirlas de la presencia de una bandeja. |
Recibido, revisado y resuelto son estados distintos
En la hoja manual del ensayo, reserva una referencia para cada caso y anota por separado la observación, la recepción del aviso, la revisión humana y el cierre. No marques «resuelto» porque una notificación se haya abierto. Si la persona no puede confirmar qué ocurre, conserva el caso pendiente con la pregunta concreta.
Si llega dos veces el mismo aviso, comprueba la referencia y la evidencia antes de abrir otra tarea. Una segunda entrega del mismo evento no demuestra otra bandeja pendiente; tampoco debes unir dos casos distintos solo porque sucedan cerca en el tiempo. Estos son criterios propuestos para el registro y la futura integración, no una garantía de deduplicación automática del producto.
El manual de Cognex distingue el resultado de inspección y su confirmación de recepción. MVTec documenta por separado la tarea de visión y la comunicación con el controlador. Son referencias de otros ecosistemas: ayudan a formular preguntas sobre la entrega de resultados, sin demostrar compatibilidad ni equivalencia con Adaris. La separación entre recepción y cierre del caso de negocio es el criterio que proponemos aquí.
Prepara un registro que permita reconstruir el caso
Usa solo datos ficticios para preparar la ficha. Esta tabla es una plantilla manual propuesta, no un informe exportado por Player. Deja las horas, resultados y motivos sin rellenar hasta realizar el ensayo autorizado.
| Campo | Qué anotar | Para qué sirve |
|---|---|---|
| Referencia y observación | Referencia del caso, instante y escena o muestra autorizada. | Relacionar el aviso con el caso revisado. |
| Entrega | Destino previsto, recepción observada o fallo de entrega. | Distinguir la detección de su comunicación. |
| Revisión | Persona, momento, confirmación o duda concreta. | Saber quién comprobó la situación. |
| Decisión | Pendiente, descartado con motivo o cierre confirmado. | No confundir apertura del aviso con resolución. |
| Condiciones | Imagen insuficiente, cambio de escena u otra limitación. | Delimitar lo que no se pudo evaluar. |
Un primer piloto que pruebe también los fallos
Acuerda con Adaris una escena, una fuente, una regla y una persona revisora para una prueba sin acciones sobre equipos. Reserva situaciones con bandeja, sin bandeja y con visibilidad insuficiente, y prepara una referencia humana para compararlas. No completes la columna de resultados por anticipado.
Para comprobar el proceso de atención antes de conectarlo, ensaya en la hoja ficticia una entrega repetida, un destino no atendido y una retirada sin confirmación humana. Si después se desarrolla la conexión, su aceptación deberá comprobar esos comportamientos en un entorno autorizado. No interrumpas redes ni sistemas compartidos para simular fallos.
Registra detecciones omitidas y avisos sin una situación de referencia; mide por separado el tiempo hasta la revisión humana y los casos pendientes al terminar la prueba. Anota el conjunto evaluado y las condiciones junto a cada medida. Los objetivos y los criterios de aceptación se pactan antes; aquí no hay tasas de acierto ni mejoras medidas.
Si no hay imagen utilizable, anota «no evaluable», sin convertirlo en «zona vacía». Si nadie puede hacerse cargo o no se puede relacionar el aviso con su evidencia, deja la aceptación pendiente y corrige esa causa. La desaparición visual de la bandeja tampoco certifica su destino ni el contenido del envío.
Un asistente manual no conecta las cámaras
Un asistente de texto puede ayudarte a ordenar este procedimiento con información ficticia. Por ejemplo: «Con esta ficha inventada de una bandeja pendiente, separa observación, entrega, revisión y cierre. Enumera los datos que faltan. No inventes horas, responsables ni resultados; no marques resuelto un caso solo porque el aviso se recibió». Revisa la respuesta con quien gestiona el proceso.
Esa conversación no analiza la cámara, no modifica Player y no crea tareas en tu aplicación. Una automatización conectada requiere acordar destino, permisos mínimos, referencia de los casos, entregas repetidas, errores, registro y revisión humana. La compatibilidad con tu sistema debe estudiarse y probarse; no se presupone un conector.
Qué llevar a la primera conversación con Adaris
Trae el problema observable, la decisión que quieres apoyar, quién revisará el resultado y qué debería ocurrir con un aviso pendiente. Añade los casos difíciles y el destino que te gustaría estudiar. No hacen falta credenciales ni datos personales para preparar esa primera descripción.
Antes de compartir imágenes reales o información comercial, acuerda permisos, condiciones de tratamiento, acceso y conservación de evidencias y un canal adecuado. Pide un piloto con alcance y criterios de aceptación claros, y una valoración separada de la integración que realmente necesites. El contacto comercial se atiende en español.
Servicios relacionados
Fuentes
¿Qué debería pasar después del aviso?
Describe la escena, quién revisará el caso y el destino que quieres estudiar. Acordamos el alcance del piloto y evaluamos la integración necesaria.