Anteproyecto¶
Lo que el proyecto comprometió ante la cátedra, en febrero de 2026. Es un documento histórico: no se actualiza. Si lo construido difiere, eso se registra en la bitácora de alcance, no corrigiendo esta página.
Esta página es el registro estructural, no el documento completo
El anteproyecto incluye además fundamentación, justificación, aportes y matriz de riesgos, con un análisis detallado de la situación operativa y comercial de la empresa destinataria. Ese análisis no se publica acá: el sitio es público y describe a un tercero.
El documento íntegro vive en
embolsadora-frontend/docs/_process/pendiente-hub/embolsadora-4.0.md, en un repositorio
privado. Lo que sigue son las secciones que definen el compromiso del proyecto y contra las
que se mide lo construido.
Se omiten también los números de legajo de los autores: no aportan a la documentación y el sitio es público.
Identificación¶
| Título | Diseño e implementación de una plataforma para el monitoreo de datos de máquinas embolsadoras en entornos industriales |
| Carrera | Ingeniería en Sistemas de Información |
| Institución | Universidad Tecnológica Nacional, Facultad Regional Santa Fe |
| Autores | Lucía Rosa Scharff · Federico Alberto Degiovanni |
| Directora | Dra. María Laura Caliusco |
| Co-director | Prof. Pablo Gaspoz |
| Marco | TECPRO 2024 — Proyecto N.º 125 |
| Empresa destinataria | M.R.G. Equipamientos S.R.L. |
| Fecha del documento | 2026-02-06 |
Objetivo general¶
Diseñar e implementar una plataforma web basada en tecnologías de Industria 4.0 que permita digitalizar, monitorear y analizar el funcionamiento de una máquina embolsadora, mejorando la eficiencia operativa, la trazabilidad del proceso y la toma de decisiones, con el fin de aumentar su escalabilidad, conectividad y capacidad de supervisión remota.
Objetivos específicos¶
Los diez compromisos contra los que se mide el proyecto. El estado verificado de cada uno está en la matriz de evidencias.
| # | Objetivo |
|---|---|
| 1 | Diseñar un modelo de arquitectura de software que contemple la conectividad entre una Raspberry Pi y la nube |
| 2 | Desarrollar un servicio web que se ejecute en una Raspberry Pi y reciba datos operativos desde un PLC |
| 3 | Almacenar los datos recolectados de forma local y remota, utilizando tecnologías de base de datos escalables y seguras |
| 4 | Implementar un dashboard web que permita visualizar en tiempo real e históricamente los datos de funcionamiento |
| 5 | Configurar un sistema de alertas automáticas ante condiciones anómalas o fallas operativas |
| 6 | Estructurar los datos recolectados para habilitar futuras tareas de análisis e inteligencia de negocio |
| 7 | Desarrollar interfaces para el monitoreo continuo y en tiempo real, adaptadas a los perfiles de usuario (fabricante y cliente) |
| 8 | Garantizar la trazabilidad completa de la operación mediante registros históricos y logs operativos |
| 9 | Implementar mecanismos de autenticación, cifrado y seguridad para proteger los datos en tránsito y en reposo |
| 10 | Diseñar y desarrollar un entorno visual interactivo para el análisis y seguimiento del estado de la máquina |
Alcance¶
Incluido¶
- Servicio web embebido que se ejecuta en una Raspberry Pi.
- Recolección, transmisión y almacenamiento de datos operativos, local y en la nube.
- Dashboard web responsivo con datos históricos y en tiempo real.
- Sistema de alertas automáticas ante fallas o condiciones anómalas.
- Observabilidad activa: registros de eventos, logs operativos y monitoreo del estado de sensores.
- Generación de métricas clave e informes para la toma de decisiones.
Excluido¶
- El desarrollo físico de la embolsadora y la programación del PLC, a cargo del equipo de electrónica del TECPRO.
- Mantenimiento en planta y soporte técnico posterior a la implementación.
- La escalabilidad a otras máquinas: "el alcance se restringe al desarrollo de la solución para una máquina prototipo; la escalabilidad a otras máquinas será evaluada en futuras etapas."
El límite del PLC explica el modelo de seguridad
Que la programación del PLC esté fuera del alcance es lo que convierte al sistema en uno de
monitoreo y no de control, y eso sostiene varias decisiones posteriores: ver
SYS-ADR-007.
Usuarios contemplados¶
Personal técnico y operario de M.R.G.; personal administrativo o de producto de la empresa; y clientes usuarios finales de las máquinas.
Entregables principales¶
| Entregable | Estado verificado |
|---|---|
| Servicio corriendo en Raspberry Pi | ✅ |
| Servicio corriendo en la nube | ✅ |
| Base de datos local y remota con registros históricos | ✅ |
| Interfaz web operativa | ✅ |
| Sistema de alertas y métricas | ✗ el motor de alertas no existe |
| Documentación técnica | ✅ este sitio |
Tecnologías previstas¶
Lo que el anteproyecto anticipó. El contraste con lo efectivamente usado —y las tres adiciones no previstas— está en la bitácora de alcance.
- Raspberry Pi como gateway industrial.
- Protocolos HTTP y HTTPS.
- Almacenamiento local SQLite o PostgreSQL; remoto Supabase, Firebase o AWS RDS.
- Backend en Go o Python.
- Dashboard con React y bibliotecas de visualización como Chart.js o Recharts.
Metodología¶
Enfoque ágil basado en Scrum, adaptado a un equipo de dos personas: sin Scrum Master dedicado, con el rol de Product Owner compartido entre el equipo y la dirección, sprints de dos semanas, sincronizaciones diarias informales y una retrospectiva mensual.
El trabajo se gestionaría con un Product Backlog centralizado priorizado con la dirección, un tablero Kanban por sprint y métricas simples de velocidad.
Herramientas previstas: Notion para documentación y backlog, Google Workspace para colaboración, GitHub para control de versiones, Visual Studio Code y GitHub Copilot.
El backlog previsto es el origen de un hueco actual
El anteproyecto sitúa el Product Backlog —y por lo tanto las historias de usuario— en Notion, fuera de los repositorios.
Esa decisión es la causa de que hoy las US-0xx se referencien en varios lugares del
sistema y su definición no esté en ningún repositorio: ver
historias de usuario.
Cronograma¶
El cronograma planificaba de mayo a noviembre de 2025, en diez actividades: relevamiento, diseño de arquitectura, benchmark de almacenamiento en la nube, definición del modelo de datos, backend de la nube, investigación y prueba de concepto en Raspberry Pi, backend de la Raspberry Pi, frontend, integración y pruebas, y documentación final.
La tabla de Gantt original no es reproducible
El documento tiene la grilla de semanas, pero el sombreado que indicaba en qué semana caía cada actividad se perdió en la conversión a Markdown: todas las celdas quedaron vacías.
Lo que sí se conserva es la ventana completa y el orden de las actividades, que es lo que la bitácora usa para medir el desvío — y el orden real resultó inverso al planificado.
Informes de avance planificados¶
Tres, antes de la entrega final: 2025-08-20, 2025-09-17 y 2025-10-22. Su estado está en informes de avance.
Lo que no se publica acá¶
Por la razón explicada arriba, estas secciones quedan solo en el documento original:
| Sección | Qué contiene |
|---|---|
| Fundamentación | El marco de Industria 4.0, IIoT y uso de hardware abierto, con referencias |
| Justificación | La situación operativa y comercial de la empresa destinataria, y los problemas concretos de la máquina |
| Aportes | Beneficios esperados para la empresa, sus clientes y el ámbito académico |
| Gestión de riesgos | Matriz de probabilidad e impacto, estrategias, planes de contingencia y gobernanza |
| Impacto ambiental | — |
Fuentes¶
- Documento fuente:
docs/_process/pendiente-hub/embolsadora-4.0.md, con front-matterstatus: historicoydestino: embolsadora-docs
Relacionado¶
- Bitácora de alcance — en qué difiere lo construido de esto
- Matriz de evidencias — objetivo por objetivo, con su evidencia
- Visión y alcance — qué es el sistema hoy