Tulip ofrece flexibilidad a la hora de estructurar las aplicaciones en torno a las máquinas. El patrón adecuado depende de la madurez técnica de tu equipo, la estandarización de los procesos y el presupuesto.
Patrón 1: Aplicaciones de máquina componibles (modelo 1:1)
Estructura: Una máquina → Una aplicación → Una estación → Un terminal
Diagrama de arquitectura:.png)
Casos de uso
- Desarrolladores aficionados principiantes que crean sus primeras aplicaciones de monitorización de máquinas
- Implementacionesrápidas de prueba de concepto en las que la simplicidad prima sobre la eficiencia
- Procesos manuales personalizados por cada instancia de máquina (p. ej., la máquina 1 requiere pasos de inspección específicos que no se aplican a la máquina 2)
- Desarrollo orientado a las operaciones, en el que los desarrolladores desempeñan múltiples funciones y disponen de tiempo limitado
Por qué es importante
Este patrón asigna físicamente el software al hardware en una relación 1:1, eliminando la abstracción. Los desarrolladores pueden identificar una máquina en la planta de producción y asignársela a su propia aplicación. Esta claridad reduce el esfuerzo mental y hace que la resolución de problemas sea intuitiva.
Ejemplo
Escenario: Un fabricante de alimentos y bebidas cuenta con tres líneas de envasado. Cada línea tiene motivos de inactividad, configuraciones de piezas y flujos de trabajo de los operarios específicos.
Implementación
- Crear tipo de máquina: «Línea de envasado»
- Crear 3 máquinas: «Línea A», «Línea B», «Línea C»
- Crear 3 aplicaciones: «Terminal de la línea A», «Terminal de la línea B», «Terminal de la línea C»
- Asignar cada aplicación a una estación dedicada con un terminal fijo
Ventajas
- El claro aislamiento de datos evita la corrupción de datos entre máquinas
- Fácil personalización de los flujos de trabajo por máquina
- Resolución sencilla de problemas (el problema siempre se encuentra en una sola aplicación independiente)
Limitaciones
- Requiere un terminal físico por máquina (coste de hardware)
- Los cambios globales en la aplicación requieren actualizar tres aplicaciones distintas
- No es escalable más allá de unas 10 máquinas
Patrón 2: Asignación de máquinas a la aplicación de estación
Estructura: un tipo de máquina → una aplicación → varias estaciones (la máquina se asigna dinámicamente mediante la asignación de estaciones)
Diagrama de arquitectura:
Casos de uso
- Procesos estandarizados en tipos de máquinas idénticos
- Desarrolladores ciudadanos a tiempo completo familiarizados con la abstracción y la lógica de activación
- Se requiereescalabilidad horizontal (más de 10 máquinas del mismo tipo)
- El mantenimiento centralizado de las aplicaciones es una prioridad
Cómo funciona
- Asigna cada máquina a una estación en «Taller» > «Máquinas» (pestaña «Configuración»)
- En la aplicación, utiliza las condiciones de activación «en esta estación» para hacer referencia de forma dinámica a la máquina asignada
- Cuando la aplicación se ejecuta en la estación 1, interactúa con la máquina 1. Cuando se ejecuta en la estación 2, interactúa con la máquina 2
Ejemplo de activador de la aplicación
Cuando: La máquina de esta estación genereun cambio de estado.Si: Salida de la máquina / Cambio de estado =Inactivo. Entonces: Crear un registro en la tabla «Historial de estado».
Ejemplo
Escenario: un proveedor de primer nivel del sector de la automoción cuenta con 15 fresadoras CNC idénticas que ejecutan el mismo proceso de producción.
Implementación
- Crear tipo de máquina: «Fresadora CNC de 5 ejes»
- Crear 15 máquinas (de CNC-001 a CNC-015)
- Crear una aplicación: «Terminal de operador CNC»
- Crear 15 estaciones y asignar una máquina a cada una
- Implementar la única aplicación en las 15 estaciones
Ventajas
- Una única aplicación que mantener (las actualizaciones globales se propagan al instante)
- Menor tiempo de desarrollo de la aplicación para implementaciones en flotas
- Utiliza la lógica de activación «en esta estación» (referencia dinámica integrada a la máquina)
Limitaciones
- Sigue siendo necesario un terminal por estación (el coste del hardware se mantiene)
- Todas las máquinas deben ser del mismo tipo y tener atributos idénticos
- La lógica personalizada por máquina requiere ramificaciones condicionales (mayor complejidad)
Patrón 3: Aplicación con variables de máquina (terminal flotante)
Estructura: Una aplicación → Varios tipos de máquinas → Selección de máquinas basada en variables → Terminal compartida/flotante
Diagrama de arquitectura:
Casos de uso
- Restricciones presupuestarias: número limitado de terminales disponibles
- Modelo de operador flotante: un operador se desplaza entre máquinas con un iPad compartido
- Las máquinas no requieren supervisión continua: la aplicación solo tiene que estar en funcionamiento durante las operaciones activas
Limitación crítica: no admite funcionamiento sin interfaz gráfica
Este patrón no admite la supervisión en segundo plano ni sin interfaz gráfica. Si la aplicación está cerrada, ninguna máquina activa una alarma. Este patrón solo es adecuado para:
- Introducción de datos iniciada por personas (el operador registra defectos y recuentos de piezas)
- Inspecciones puntuales de las máquinas
- Escenarios en los que las máquinas no generan datos cuando la aplicación no está en ejecución
Cómo funciona
- Crea una variable de máquina en la aplicación (por ejemplo,
selectedMachine) - Añade un widget de menú desplegable o un escáner de códigos QR para rellenar
«selectedMachine»en tiempo de ejecución - Utiliza
«selectedMachine»en todas las referencias de activadores
Ejemplo de activador de la aplicación
Cuando: la variable de máquina «Máquina seleccionada» devuelva {Atributo}Entonces: almacenar el último resultado de la máquina en una variable
Ejemplo
Escenario: Un laboratorio farmacéutico cuenta con 5 instrumentos analíticos que solo funcionan durante las pruebas programadas. Los técnicos utilizan un iPad compartido para registrar los parámetros y resultados de las pruebas.
Implementación
- Crea 5 máquinas (HPLC-1, GC-MS-2, etc.)
- Desarrollar una aplicación: «Registro de equipos de laboratorio»
- Añadir un menú desplegable: «Seleccionar instrumento» → rellena la variable
selectedMachine - El técnico lleva el iPad de un instrumento a otro, selecciona el equipo activo y registra los datos
Ventajas
- Coste mínimo de hardware (un terminal compartido)
- Selección flexible de máquinas en tiempo de ejecución
- Ideal para flujos de trabajo puntuales o intermitentes
Limitaciones
- No funciona en modo «headless »: la aplicación debe estar ejecutándose activamente para que se ejecute cualquier lógica
- No hay supervisión en segundo plano cuando la aplicación está cerrada
- Gestión compleja del estado (¿qué máquina está activa actualmente?)
- No es adecuado para el seguimiento de la OEE las 24 horas del día, los 7 días de la semana
Árbol de decisión de patrones de arquitectura
Utiliza este árbol de decisión para seleccionar el patrón que mejor se adapte a tus necesidades:
Más información
- Monitorización de máquinas: arquitectura «headless» frente a arquitectura basada en aplicaciones
- Variables
{{snippet.¿Has encontrado lo que buscabas?}}