Problemas reales, soluciones de ingeniería

Acceso y selección de modo. Una sola llave controla ambos. Desbloquea la puerta de entrada y termina el modo automático, y la misma llave es necesaria dentro del recinto para habilitar el modo manual. Como la llave no puede estar en ambos lugares a la vez, el modo automático no puede reactivarse mientras hay alguien dentro.

Modo automático. Cada lado del elevador tiene una puerta rápida. Solo una puede estar abierta a la vez, para que el aire frío no pase de la zona de congelación a la de refrigeración.

Modo manual. El movimiento vertical se bloquea mientras una puerta esté abierta; solo el transportador del carro puede meter o sacar cargas. Para mover el elevador verticalmente hay que mantener presionado el pulsador de habilitación de un panel móvil de seguridad diseñado para ambientes fríos.

Recuperación de sobrerrecorrido. Si el elevador llega al final de carrera superior, se permite un movimiento restringido incluso con una puerta abierta, pero solo hasta liberar el interruptor, para devolver el elevador a una posición segura.

Reacciones de paro. Según la falla de seguridad, los accionamientos se detienen con STO (Safe Torque Off) o SS1 (Safe Stop 1).

La situación. Un nuevo sistema de transportadores de pallets debía conectarse al sistema de un tercero que ya estaba en producción. El software de la interfaz lo había preparado otra persona, y la única ventana para el trabajo era un día sin producción.

Diagnóstico. Los dos sistemas no se conectaron al primer intento. El enlace funcionaba a través de un acoplador PN/PN entre las dos redes PROFINET, así que registré trazas del PLC de las señales intercambiadas para ver exactamente dónde fallaba la secuencia de entrega. Las trazas mostraron que el handshake preparado seguía una definición de interfaz desactualizada que ya no coincidía con el sistema del tercero.

Trabajo con el tercero. Su ingeniero estaba en sitio. Juntos revisamos su secuencia paso a paso, y ese mismo día nos proporcionó la documentación vigente de la interfaz.

Solución bajo presión de tiempo. Reprogramé la secuencia de entrega de nuestro lado para que coincidiera con la definición vigente. El sistema del tercero no se modificó.

Validación. Antes de terminar el día probé transferencias de pallets en ambas direcciones, entregando y recibiendo pallets. La producción se reanudó a la mañana siguiente sin interrupciones.

La situación. Un sistema de manejo de materiales en operación debía migrarse a un nuevo concepto de software de control. Su documentación estaba desactualizada, así que la referencia real era el propio sistema en operación.

Reconstrucción del sistema. Reconstruí el layout a partir de la instalación en operación y preparé las interfaces con los 12 sistemas conectados con los que intercambia datos.

Mi rol. No era el líder del proyecto, pero era quien tenía más experiencia con el nuevo concepto de control dentro del equipo, así que me encargué del diseño del software.

Cerrar las brechas. Algunas funciones existentes no estaban cubiertas por el nuevo software estándar. Diseñé y programé módulos a medida para que el nuevo software las reproduzca, conservando todo aquello de lo que depende la planta.

Estado. El software está actualmente en puesta en marcha.

El sistema. Un buffer de clasificación con seis líneas almacena pilas de cajas. Las pilas se desapilan y se liberan hacia el siguiente subsistema, mientras siguen llegando cajas nuevas a la entrada.

El equilibrio. El buffer debe decidir cuándo apilar y cuándo desapilar. Si desapila demasiado pronto, el siguiente subsistema recibe más de lo que puede procesar; si lo hace demasiado tarde, se queda sin material. Si ignora la entrada, las cajas se acumulan hacia otros subsistemas.

Trabajo con lógica heredada. La lógica existente funcionaba en producción, pero no estaba bien documentada. Antes de cambiar nada, rastreé cómo decidía entre los modos de apilado y desapilado en las seis líneas.

Mejora de la secuencia. Con esa comprensión, mejoré la secuencia para que cada decisión considere tanto la cantidad de cajas en la entrada como la disponibilidad del siguiente subsistema.

Asistido por IA, bajo control del ingeniero. Usé herramientas de IA para diseñar el nuevo concepto, escribir el código y elaborar la documentación. No compartí información interna: describí los requisitos y mi intención, guié a la IA paso a paso y la corregí cuando se equivocaba. Revisé, probé y validé personalmente cada cambio antes de que funcionara en el sistema.

El dispositivo es el servidor. Diblio corre completamente en un TOMi8, un dispositivo Android del aula. Este crea su propia red WiFi, y el docente o los alumnos abren la biblioteca en un navegador. En ningún momento se necesita conexión a internet.

Diseñada para cómo funcionan realmente las aulas. La mayor parte del tiempo el docente opera la biblioteca en el propio dispositivo, con la pantalla proyectada para todo el grupo. Eso hace que el procesador modesto del dispositivo sea el hardware que importa, así que cada función interactiva se diseña y prueba primero con él. También se da soporte a alumnos con sus propios dispositivos.

Funciones. Lectores de PDF y EPUB, reproducción de video y audio, lectura grupal que mantiene todas las pantallas en la misma página, lectura en voz alta, notas y progreso personales, y un panel docente.

Entrega. El servidor y la aplicación web se empaquetan en una sola app de Android, con guía de instalación y manual de usuario. El código está cubierto por pruebas unitarias y pruebas de extremo a extremo de los principales flujos del aula.

Cómo se construyó. Desarrollé Diblio con agentes de programación con IA, a partir de especificaciones, decisiones de arquitectura y planes de prueba que yo definí y revisé.

Dos negocios, un mismo patrón. Una empresa de catering y una artista independiente tenían el mismo problema de fondo: las solicitudes llegaban por canales dispersos, y el seguimiento de clientes y fechas dependía de la memoria y de mensajes.

Sitio web público. Cada negocio tiene un sitio que presenta su trabajo y convierte visitas en solicitudes: cotizaciones para eventos, encargos de obra.

Panel de administración. Las solicitudes llegan a un panel privado donde el dueño las revisa, gestiona clientes y da seguimiento a cada solicitud hasta la reservación, sin necesidad de ayuda técnica.

Calendario. La disponibilidad se lleva en un calendario. Para la empresa de catering, no se pueden reservar dos eventos en la misma fecha salvo que el dueño lo permita explícitamente.

Cómo se construye. Estoy desarrollando ambos sistemas con agentes de programación con IA, a partir de requisitos y diseños que yo defino y reviso.