Saltar a contenido

Visión y alcance

Qué es el sistema Embolsadora 4.0, qué hace hoy y qué explícitamente no hace.

El problema

M.R.G. Equipamientos S.R.L. fabrica máquinas embolsadoras industriales que funcionan aisladas: no transmiten datos a ningún sistema central. Sin registro de lo que ocurre en cada ciclo, no hay trazabilidad del proceso ni forma de anticipar una falla. La detección de problemas depende de que el operario los perciba y llame al servicio técnico, lo que produce paradas de línea y visitas de urgencia.

Qué es el sistema

Una plataforma que digitaliza el funcionamiento de la máquina: captura las variables operativas del PLC en planta, las almacena local y remotamente, y las presenta en un dashboard web accesible desde cualquier lugar.

Está construido sobre cinco repositorios y corre en dos ubicaciones físicas: una Raspberry Pi en la planta del cliente y servicios en la nube. Ver mapa de repositorios.

Qué NO es

Es un sistema de monitoreo, no de control

No hay escritura hacia el PLC. El historian lo lee por Modbus TCP y ningún componente del sistema le envía comandos ni configuración: no hay escrituras de registros ni de bobinas en ninguna parte del código, y el Cloud solo hace GET hacia la Raspberry Pi.

Es un límite deliberado —el anteproyecto excluye la programación del PLC, a cargo del equipo de electrónica del TECPRO— y condiciona todo el modelo de seguridad: un atacante que comprometiera el sistema no podría operar la máquina.

Tampoco están en el alcance:

  • El desarrollo físico de la embolsadora.
  • El mantenimiento en planta ni el soporte técnico post implementación.
  • La escalabilidad a una flota: el alcance es una máquina prototipo. La arquitectura es multi-tenant y está preparada para más, pero la validación es sobre un equipo.

Usuarios

Perfil Rol en el sistema Qué hace
Operario del cliente cliente_operario, operario Monitorea la máquina y consulta históricos. No recibe alertas automáticas: el motor que las emitiría no existe
Administrador del cliente cliente_admin Gestiona los usuarios de su empresa, roles y layouts. Puede definir reglas de alarma, que hoy se guardan sin evaluarse
Administrador de MRG admin, platform_admin Gestiona tenants, dispositivos y claves; opera cross-tenant
Técnico instalador (no es un rol de la aplicación) Instala y provisiona la Raspberry Pi en planta

El técnico instalador no existe como rol en el software y no accede a la aplicación: es un perfil que esta documentación nombra para poder hablar de las acciones que alguien tiene que hacer en planta para que el sistema funcione. Su guía es el runbook de instalación.

Estado de los objetivos

Los diez objetivos específicos del anteproyecto y cómo están resueltos hoy. La columna propuesta registra los que conviene revisar: un objetivo puede cambiar a lo largo de la vida del proyecto, y esta tabla es donde se discute ese cambio.

# Objetivo Estado Cómo está resuelto Propuesta
1 Modelo de arquitectura con conectividad Raspberry Pi ↔ nube ✅ Contenedores C4 —
2 Servicio en Raspberry Pi que reciba datos del PLC ✅ Historian (Modbus) + Edge Pi Service —
3 Almacenamiento local y remoto ✅ InfluxDB local · Postgres y MongoDB en la nube —
4 Dashboard con visualización en tiempo real e histórica ◑ parcial 14 de 32 widgets consumen métricas reales, sobre 10 variables Acotar el tablero a los widgets con dato real, o ampliar el catálogo de variables que el historian publica
5 Sistema de alertas automáticas ✗ no implementado Existe el CRUD de reglas; no existe el motor que las evalúe Implementar el motor de evaluación, o redefinir el objetivo como definición de reglas sin evaluación automática. La decisión se registra en la bitácora de alcance
6 Estructurar los datos para análisis e inteligencia de negocio ✅ Semántica AAS (aasPath) end-to-end hacia MongoDB —
7 Interfaces adaptadas a los perfiles fabricante y cliente ✅ Multi-tenancy + RBAC dinámico + vista cross-tenant —
8 Trazabilidad por registros históricos y logs ◑ parcial Log service implementado; mediciones históricas en MongoDB Llevar el indicador de calidad del dato hasta el dashboard: hoy se queda en el log del historian
9 Autenticación, cifrado y seguridad ◑ con deudas JWT por JWKS, con solo ES256 y RS256 admitidos; claves de API hasheadas. Detalle en seguridad Cerrar las deudas abiertas en seguridad: restringir CORS y autenticar los chequeos del Cloud hacia el Edge
10 Entorno visual interactivo de análisis y seguimiento ✅ Dashboard con layouts configurables por usuario —

Funciones previstas que hoy no están

Además del motor de alarmas:

Función Estado Detalle
Heartbeat Edge → Cloud No implementado en ninguno de los dos extremos El Cloud responde 501; en el Edge el paquete app/heartbeat contiene solo un doc.go
Servidor AAS en la nube Descartado Se especificó contra norma IDTA-01002-3-1, y la función quedó resuelta por FA³ST en la Pi
Red privada Cloud → Pi No configurada El contrato inbound asume una VPN que no está configurada en ningún repositorio
Backups Sin política definida No hay política documentada para Postgres, MongoDB ni InfluxDB

Contexto institucional

Proyecto Final de Carrera de Ingeniería en Sistemas de Información, UTN Facultad Regional Santa Fe, en el marco del programa de transferencia tecnológica TECPRO 2024 (Proyecto N.º 125), con M.R.G. Equipamientos S.R.L. como empresa destinataria.

El componente proyecto-embolsadora (historian AAS) pertenece a una tesis de maestría distinta. Se integra como componente aportado y se cita con su autor; no se documenta como trabajo del Proyecto Final.

Para seguir