Referencia de aplicación. Esta es una arquitectura ilustrativa y una lista de comprobación del alcance, no un proyecto de cliente verificado ni una implementación medida. Las tecnologías, el alcance de la integración y los elementos de entrega se acuerdan para el briefing real.
Escenario y restricciones
Una fábrica que sustituye el seguimiento de la producción mediante hojas de cálculo. El requisito decisivo es la trazabilidad bidireccional: dado un número de serie terminado, enumerar cada lote de material que se incorporó a él y, dado un lote de material defectuoso, enumerar cada unidad terminada afectada. Este requisito determina el modelo de datos: no puede añadirse posteriormente sin reprocesar el historial.
Arquitectura
Capas y responsabilidades
| Capa | Tecnología | De qué se responsabiliza |
|---|---|---|
| Web de oficina | Vue 3 + Element Plus | Liberación de pedidos, mantenimiento de BOM, planificación, revisión de calidad y elaboración de informes. |
| Cliente de planta | Dispositivo portátil / tableta Android (Kotlin), con capacidad sin conexión | Registro basado en escaneos en cada estación. Diseñado para manos enguantadas y una Wi-Fi deficiente: objetivos grandes, pocos toques y cola local. |
| API | Go + Gin | Validación de registros frente a la ruta, reglas de consumo de materiales y consultas de trazabilidad. |
| Almacenamiento | MySQL | Pedidos, rutas, registros de producción y genealogía de lotes. |
| Pasarela de dispositivos | Puente MQTT u OPC UA (opcional) | Extrae conteos o mediciones de los equipos cuando el proveedor expone una interfaz, y los normaliza en las mismas tablas de producción. |
| Informes | Trabajos de agregación programados | Rendimiento, tiempo de ciclo y carga de estación precalculados, porque estas consultas recorren demasiado historial para ejecutarse en tiempo real con cada carga del panel. |
Modelo de datos
Las tablas siguientes contienen las reglas de las que depende todo lo demás. Equivocarse en ellas es lo que convierte una demostración funcional en un sistema que no puede ampliarse.
Entidades principales
| Entidad | Campos clave, relaciones y reglas |
|---|---|
| item / bom | Lista de materiales multinivel con fechas de vigencia y reglas de sustitución. Las versiones de la BOM se conservan, no se sobrescriben, de modo que un pedido fabricado el mes pasado siga resolviéndose según la BOM que realmente utilizó. |
| work_order / routing_step | El pedido y su lista ordenada de operaciones, cada una vinculada a un centro de trabajo con un tiempo estándar y las reglas de registro correspondientes a ese paso. |
| production_report | Producción por estación: operador, hora de inicio y finalización, cantidad buena, retrabajo y desperdicio con códigos de motivo. Esta es la entrada de la que se deriva cada métrica, por lo que sus reglas de validación importan más que los paneles. |
| material_lot / lot_consumption | Lotes recibidos y su consumo contra una orden de trabajo. lot_consumption es la unión que hace posible la genealogía; sin ella, la trazabilidad se reduce a conjeturas. |
| serial / genealogy | Unidades terminadas serializadas vinculadas a sus lotes consumidos, formando el grafo que responde a ambas direcciones de consulta y rastreo. |
| inspection / defect | Puntos de inspección, regla de muestreo, códigos de defecto y disposición (aceptar, retrabajar, desechar), cada uno vinculado al registro que produjo la unidad. |
Interfaces clave
Endpoints que contienen las reglas de negocio
| Endpoint | Propósito y notas sobre concurrencia |
|---|---|
| POST /api/v1/reports | Registro de estación. Valida que el paso de ruta anterior se haya completado, que la cantidad registrada no supere la cantidad liberada y que el consumo de materiales esté dentro de la tolerancia de la BOM; rechazar aquí las entradas incorrectas es lo que mantiene fiables los datos de producción. |
| POST /api/v1/reports/batch | Carga de la cola sin conexión desde dispositivos portátiles, con deduplicación mediante un UUID de cliente y conservación de la hora de captura. |
| GET /api/v1/trace/forward/{lot} | Dado un lote de material, devuelve todos los números de serie terminados afectados: la consulta de la que depende una retirada. |
| GET /api/v1/trace/backward/{serial} | Dado un número de serie terminado, devuelve la genealogía completa de los lotes de material. |
| POST /api/v1/work-orders/{id}/release | Libera un pedido y captura la versión de la BOM y de la ruta, para que las modificaciones posteriores de los datos maestros no puedan reescribir el historial. |
Decisiones técnicas
- Genealogía modelada desde el principio. Incorporar la trazabilidad posteriormente significa que los datos históricos nunca podrán rastrearse. Si la trazabilidad es un posible requisito futuro, la unión lot_consumption debe existir desde la primera versión, aunque los informes lleguen después.
- BOM y ruta capturadas en la liberación del pedido. Los datos maestros cambian constantemente; los pedidos deben seguir resolviéndose según la versión con la que se liberaron, o las variaciones de costes y de consumo pierden su significado.
- Validación en el endpoint de producción, no en el panel. Las métricas calculadas a partir de entradas no validadas producen cifras incorrectas con apariencia de certeza. Rechazar un registro imposible en el momento de entrada es más barato que explicar posteriormente una cifra de rendimiento defectuosa.
- Cola sin conexión en el dispositivo portátil. La Wi-Fi de fábrica tiene zonas sin cobertura cerca del metal y la maquinaria. Los registros que fallan en esas zonas simplemente no se realizarán, y el conjunto de datos desarrollará huecos silenciosamente.
- Convivencia con el ERP existente en lugar de sustituirlo. Compare una interfaz delimitada para pedidos y movimientos de inventario con una migración de ERP utilizando las dependencias, costes y riesgos reales; confirme el flujo de trabajo financiero antes de elegir.
Objetivos de diseño hipotéticos
Las cifras siguientes son ejemplos hipotéticos de planificación de capacidad, no resultados medidos de clientes, una recomendación de dimensionamiento validada ni un SLA. Establezca objetivos de aceptación específicos del proyecto después de definir la carga de trabajo, los dispositivos, los datos, el hardware y las dependencias de terceros; verifíquelos mediante un piloto y pruebas de carga antes de comprometerse con un objetivo de producción.
Objetivos de capacidad y rendimiento
| Objetivo | Valor y supuesto |
|---|---|
| Escaneo a confirmación | Objetivo hipotético: respuesta local inferior a 1 segundo para un informe y dispositivo definidos. Persistir los registros en cola y distinguir el acuse local de la aceptación del servidor; probar los retrasos y fallos de red. |
| Consulta de trazabilidad | Ambas direcciones responden en unos pocos segundos para una profundidad de genealogía habitual, utilizando uniones indexadas de lotes y números de serie; las estructuras multinivel profundas se validan con sus datos reales durante la aceptación. |
| Panel de producción | Se sirve a partir de agregados precalculados, actualizados según un calendario acordado con operaciones, en lugar de recorrer los registros sin procesar en cada carga de página. |
| Tolerancia sin conexión | Un turno completo de informes en cola localmente y cargados al restablecerse la conexión, con deduplicación mediante el UUID de cliente. |
Qué incluye la entrega
- Código fuente web de oficina, código fuente del backend Go y código fuente del cliente Android de planta en su repositorio
- Esquema de base de datos con versionado de BOM y tablas de genealogía documentados, además del historial de migraciones
- Documentación de la API, incluido el contrato de carga sin conexión y las reglas de validación de producción
- Especificación de la interfaz con el ERP y el formato de intercambio acordado
- Notas de despliegue, procedimiento de copia de seguridad y restauración, y notas de configuración del hardware de etiquetas o escáneres
Planificación para su empresa
Los módulos anteriores son un punto de partida, no un paquete fijo. Normalmente reducimos la primera versión a un flujo de trabajo principal y uno administrativo, y después ampliamos cuando el uso real muestra dónde se encuentran realmente la carga y los casos límite. Envíe un briefing delimitado y lo compararemos con esta arquitectura para indicarle qué partes todavía no necesita.