Una receta puede cambiar la temperatura, la velocidad, la presión, los tiempos, el movimiento y la calidad del producto sin descargar un programa en el controlador. Por eso, los datos de las recetas son operativamente importantes incluso cuando se almacenan en una matriz UDT ordinaria de Logix. El objetivo del diseño no es simplemente guardar valores, sino impedir que valores incompletos, obsoletos, no autorizados o incompatibles se activen.

Un flujo de trabajo controlado separa la edición del operador de los valores que controlan actualmente la máquina.

Asigne cuatro funciones distintas a los datos de la receta

Utilice estructuras separadas para las recetas almacenadas, la fuente seleccionada, una copia de trabajo editable y la copia del proceso activo. La HMI solo edita la copia de trabajo. Una solicitud de guardado valida y confirma esa copia de trabajo en un registro de almacenamiento seleccionado. Una solicitud de activación independiente vuelve a validar los datos y transfiere un registro completo y aprobado a la estructura activa.

Esta separación evita que cada pulsación de tecla en la HMI cambie un punto de ajuste activo. También permite cancelar, comparar, aprobar, revertir y mostrar mensajes claros al operador. La receta activa permanece estable mientras se revisa otra receta.

El hardware PanelView está organizado en la colección Allen-Bradley PanelView, y las plataformas de control están disponibles a través de PLC & PAC Systems. La selección del hardware no sustituye las reglas de transacción implementadas en la aplicación.

Diseñe la UDT como un registro gobernado

Agrupe los valores de proceso relacionados en una UDT para que el almacenamiento, la comparación y la transferencia utilicen un diseño único y definido. Añada metadatos como el identificador de la receta, el nombre, la versión de formato, el código del producto, la revisión, la hora de creación, la hora de modificación, el estado de validez y el responsable del cambio. Mantenga el estado operativo fuera de la estructura de puntos de ajuste cuando no deba copiarse con una receta.

Cada miembro numérico necesita unidades de ingeniería, un rango permitido y una justificación para ese rango. Utilice enumeraciones acotadas o códigos validados para los modos discretos en lugar de texto libre. Defina valores predeterminados solo cuando sean seguros y técnicamente significativos.

Una versión de formato es importante durante las actualizaciones del software. Si una versión posterior del programa del controlador añade campos o cambia las unidades, los registros antiguos deben rechazarse o migrarse de forma deliberada. Copiar un diseño binario antiguo en una UDT nueva sin una regla de compatibilidad puede crear puntos de ajuste que parezcan válidos, pero sean incorrectos.

Valide las relaciones, no solo los límites individuales

Comprobar cada campo frente a un mínimo y un máximo es necesario, pero insuficiente. Un límite alto debe mantenerse por encima de un límite bajo. El tiempo de rampa debe ser coherente con la velocidad y la distancia. Las duraciones de las fases deben ajustarse a la secuencia. Las opciones mutuamente excluyentes no pueden habilitarse simultáneamente. Una velocidad puede ser aceptable para un tamaño de producto y peligrosa para otra configuración de herramientas.

Implemente la validación en la lógica del controlador porque el controlador es responsable de la respuesta del proceso. La HMI puede repetir las comprobaciones para proporcionar información inmediata, pero no debe ser la única capa de aplicación de las reglas. Devuelva un código de validación específico e identifique el miembro o la relación que falló. El mensaje «Receta no válida» por sí solo obliga al personal de mantenimiento a revisar decenas de valores.

Distinga entre una advertencia y un rechazo. Una advertencia puede requerir confirmación o revisión de un supervisor, mientras que un registro rechazado no puede guardarse ni activarse. No permita nunca que un botón de confirmación genérico anule un límite estricto del equipo o de seguridad.

Utilice una máquina de estados de transacción explícita

Los comandos momentáneos de la HMI pueden perderse, repetirse o permanecer activos después de una interrupción de las comunicaciones. Implemente una secuencia de solicitud y reconocimiento con un número de transacción. La HMI escribe los datos de trabajo, incrementa el número de solicitud y espera. El controlador captura una copia estable, la valida, ejecuta una sola vez la acción solicitada y devuelve el mismo número de transacción junto con el resultado y el código de error.

Rechace una nueva solicitud mientras otra transacción esté ocupada. Aplique un tiempo de espera en la HMI y conserve el resultado del controlador durante el tiempo suficiente para que el operador pueda leerlo. Después de una reconexión, la HMI compara los números de transacción en lugar de suponer que el guardado anterior falló.

El controlador debe transferir el registro completo y validado en un único punto de ejecución definido. Los movimientos dispersos controlados por condiciones independientes pueden crear una mezcla de valores antiguos y nuevos. Si otra tarea o ruta de comunicación puede modificar los datos simultáneamente, diseñe una instantánea estable y verifique que su secuencia no haya cambiado durante la copia.

Separe el guardado de la activación

Guardar registra una copia de trabajo revisada en el almacenamiento. Activar cambia los valores utilizados por el proceso. Estas acciones requieren permisos, mensajes e interbloqueos independientes. Es posible que un técnico pueda preparar una receta sin estar autorizado para ejecutarla.

Defina cuándo se permite la activación: máquina detenida, ciclo completado, actuadores en un estado seguro, herramientas correctas confirmadas, ausencia de fallos críticos y presencia del rol de operador requerido. Si algunos valores pueden cambiar durante la producción, enumérelos explícitamente y controle su transferencia. No dependa de la memoria del operador para saber qué campos son seguros en línea.

Después de la activación, devuelva a la HMI el identificador y la revisión de la receta activa. Compare la copia activa con la fuente aprobada y genere una alarma ante cualquier diferencia inesperada. La lógica de secuencia posterior debe utilizar únicamente la copia activa, nunca las etiquetas de trabajo de la HMI.

Adapte los permisos y las evidencias a la importancia de la acción

Como mínimo, distinga entre las acciones de ver, editar, guardar, activar, eliminar y restaurar. Restrinja la eliminación más estrictamente que la selección. Evite las credenciales compartidas cuando la aplicación requiera responsabilidad individual. Si la plataforma admite auditoría, registre el usuario, la hora, la acción, el identificador de la receta, la revisión anterior, la nueva revisión y el resultado.

El controlador también debe conservar evidencias operativas que no dependan por completo de la HMI: identificador activo, revisión, última transacción, resultado de validación y hora de activación. Los registros de la HMI son útiles, pero pueden perderse durante el reemplazo del terminal o la descarga de la aplicación.

Sea claro sobre los límites. El historial ordinario de recetas de una máquina no es automáticamente un sistema de registros electrónicos para una producción regulada. Si se requieren firmas, evidencia contra manipulaciones, conservación o registros de auditoría validados, evalúe la arquitectura y los procedimientos completos.

Diseñe el comportamiento durante el arranque y la pérdida de comunicaciones

Especifique qué receta se activa después de reiniciar el controlador, descargar el programa, restaurar la memoria o reemplazar la HMI. Cargar ciegamente el registro cero puede ser peligroso. Los datos retentivos deben validarse antes de utilizarse, incluida la versión de formato y todas las relaciones. Si no se puede demostrar su validez, mantenga la máquina en un estado definido y exija selección y confirmación.

La pérdida de comunicación con la HMI no debe activar parcialmente una receta. El controlador continúa con el último registro activo completo o sigue la respuesta segura específica del proceso. Cuando se restablezcan las comunicaciones, borre los estados de edición obsoletos y muestre el estado real de la transacción del controlador antes de habilitar otro comando.

Pruebe las rutas de fallo

Ponga en marcha y compruebe el guardado normal, un campo no válido, una relación no válida, una acción no autorizada, una pulsación repetida del botón, una interrupción de red durante la transferencia, el reinicio del controlador, el reinicio de la HMI, el almacenamiento lleno, la eliminación, la reversión y un registro con formato antiguo. Confirme que ningún caso cree una receta activa mezclada.

Realice una prueba de límites para cada campo numérico importante y verifique las unidades en la HMI y en el controlador. Compare todos los miembros activos después de la transferencia. Registre los resultados y conserve una receta conocida y válida fuera de la copia de seguridad del controlador para que la recuperación no dependa de un solo dispositivo.

Un sistema de recetas sólido hace visibles los cambios propuestos, los valida en el controlador, activa una revisión completa en un estado controlado y deja suficientes evidencias para reconstruir lo ocurrido. Esa disciplina importa más que el hecho de que el almacenamiento comience como una matriz UDT o como un componente de recetas de la HMI.