Un caso de uso real: gestión de recetas

Introducción

El cliente es un fabricante líder de válvulas y componentes de manejo de fluidos para aplicaciones HVAC e industriales. La división de soluciones de energía solicitó un Sistema de Ejecución de Manufactura que pudiese lidiar con el proceso de ensamblado de bombas hidráulicas, esto es, una solución que pudiese manejar su amplísimo inventario de recetas y la rastreabilidad de sus unidades a lo largo de la línea de ensamble.

Entre estos dos objetivos principales, el primer reto ha sido gestionar su enorme número de recetas para un único producto final de una forma extremadamente configurable, sin tener que hacer uso de codificación de bajo nivel de una gran cantidad de información. La segunda opción no solamente habría hecho el desempeño inaceptable, sino que también habría conducido a un mantenimiento de datos extremadamente ineficiente.

Contexto de producción

Dado cualquiera de los productos (o dicho mejor, familia de productos) fabricados dentro de la división de energía, su proceso de ensamble es extremadamente variable. En otras palabras, si bien el número y tipo de operaciones de trabajo que se ejecutan siempre será el mismo para todas las unidades pertenecientes a esa familia, cualesquier dos unidades podrán variar por un número de razones que pudieran ir desde un desplazamiento diferente del tag de nombre a una forma, color, y/o sub-ensamblados completamente diferentes que se usarán.

Por ejemplo, dado un producto de nombre bomba H1P, las operaciones de trabajo siempre serán:

• Carga de hospedaje – colocación de placa – Pistones Servo – Cilindros Servo – Portador Magneto.
• Pasadores guía – Junta – Placa de bloqueo.
• Carga eje – Presión perno – Montar bloque cilindro – Cargar válvulas – Sensor presión
• Cargar casquillo – Protección carga – Junta superior – Bloque cilindro aceite – Ajuste de cápsula exterior – Cargar bomba – Vaselina – Sensor velocidad
• Rastrear HPVR – Placa de empuje – Cubrir adaptador – Prueba rotación torque – Descargar asa.
• Prueba final.
• Pintura.

Sin embargo, el número de variaciones posibles dentro de la misma familia H1P es de alrededor de 500. ¿Cómo varían estas 500 si se ensamblan “de la misma forma”? Por ejemplo, la operación “carga hospedaje” (#1) podría realizarse usando diferentes tornillos de acuerdo al lote específico de unidades, o la operación “presión perno” (#3) podría verificarse usando diferentes fuerzas de presión, etcétera. Las diferencias podrían ir desde “mínima” hasta “enorme”, lo que como resultado lleva a un alto número de variaciones dentro de la misma familia; los productos de mayor configuración podrían tener más de 2,000 variaciones posibles.

¿Pero cómo puede un ingeniero de procesos distinguir una variante de la otra? El “truco” usado por el cliente es usar una Lista de Materiales (BoM) diferente en cada variación posible, En el caso de que una parte usada varíe, es bastante obvio cómo esto puede ocurrir, mientras que esto podría no ser tan claro si la diferencia la da un color de pintura o desplazamiento de tag de nombre diferente. Este “problema” es superado al reservar un lugar en la BoM también para ítems “no físicos” (como el color de pintura) y asignando un designador de referencia para cada ítem de BoM (llamado cadena de ordenamiento o sort string según su terminología de SAP), el que típicamente define el desplazamiento de un ítem dentro del diseño CAD.

Dados estos hechos, al observar una BoM, los ingenieros de proceso pueden entender si es que están tratando con la variante A en vez de la variante B por:

• Ítem BoM: A podrá tener un ítem BoM que B no tiene y viceversa (un tornillo, un sub‑ensamble diferente, un color de pintura diferente);
• Cadena de Ordenamiento: A y B comparten el mismo ítem, pero colocado en una ubicación diferente;
• Código de Modelo Maestro: el código de modelo asignado a una orden de producción puede cambiar de variante a variante.

Considerando todo lo anterior y empleando la Siemens Opcenter Execution (SIMATIC IT) Suite, los factores decisivos considerados por Engineering para llegar a la solución óptima incluyeron:

• Volumen de datos: el tener en promedio cientos de recetas para cada familia de producto resultaría en una inmensa cantidad de datos dentro de la base de datos;
• Flexibilidad de datos: el asociar cualquier única BoM a un PPR llevaría a una configuración estrictamente estática; un ambiente de producción que se relacionara con tantas variaciones es tal porque las necesidades de producción son extremadamente flexibles y pueden cambiar fácilmente con el tiempo de acuerdo con las demandas de clientes, y una solución diseñada estáticamente no puede tolerar tal requerimiento.
• Mantenimiento de datos: los cambios aplicados a cualquier parte no se propagarían fácilmente.

La solución

La solución desarrollada para este cliente, también conocida como el “módulo de manejo de recetas”, se basa en el concepto de regla de producción; una regla de producción sirve al propósito de definir una acción a tomar en caso de que se trabaje en una variante específica en una estación dada.

Cualquier regla de producción se puede dividir en tres partes:

• Estación objetivo (operación trabajo);
• Criterio de aplicabilidad (en qué casos se va aplicar la regla);
• Cuerpo de la regla (qué es lo que se tiene que hacer).

El punto #1 responde a la pregunta “Es que estoy trabajando con la variante de producción “abc” (o en otro caso “Es que estoy trabajando con las variantes de producción”abc”/”def”/…”). El Punto #2 entonces define lo que se tiene que hacer en caso de que la respuesta al punto #1 sea positiva. A causa de su naturaleza, el Punto #1 debe de definirse haciendo referencia a:

• aquellos elementos en la BoM que pueden distinguir una variante de otra, P. Ej.: número de ítem BoM, cadena de ordenamiento, o código de módulo;
• a un nivel aún más alto, esos elementos pueden distinguir una familia de producto de otra, la ubicación de almacenamiento material final.

De esta manera, un ingeniero de procesos puede definir reglas contra una familia de productos enteras (con granularidad menos específica) o contra una variante específica (granularidad más fina).

El Punto #2 define lo que se tiene que hacer en caso de que la regla sea aplicable. Las acciones posibles podrían ser:

• usar un instrumento específico
• Tomar una parte de un almacenamiento “Pick To Light”;
• Mostrar una EWI (Instrucción Electrónica de Trabajo);
• Imprimir una etiqueta o tag de nombre;
• Enviar una confirmación a SAP.

Las reglas de producción se descargan típicamente a la capa de control para su aplicación. Por ejemplo, en el caso de reglas de instrumentos, la ID de instrumento y un conjunto de parámetros de funcionamiento se envían al controlador de línea que entonces disparará la herramienta automáticamente, señalará visualmente al operador qué herramienta usar, y/o prefijará sus parámetros de trabajo.

Con el propósito de una implementación sencilla, la solución proporcionada al cliente abstrae respecto a la “forma real” en la que se envían los datos al controlador de línea (enviando un XML), pero es capaz de escribir datos directamente a registros PLC.

Cómo y cuándo se calculan las reglas

Cuando está disponible una orden nueva, el módulo de manejo de recetas la importa junto con su BoM y, estación por estación (P. Ej.: ingreso de orden de producción uno por uno), verificará las reglas definidas para la estación actual e identificará aquellas que tengan un criterio de aplicabilidad “coincidente”.

Ya que las reglas se pueden etiquetar con un número de secuencia por parte del ingeniero de procesos que las define, para cada orden entonces el proceso completo resultará en un “guión” o script para cada estación unitaria. En otras palabras, Opcenter Execution (SIMATIC IT) “sabrá” todas las micro‑operaciones a realizar en cualquier estación dada y las descargará a la capa de control o las aplicará directamente.

Una última consideración acerca de las reglas se relaciona con cómo se las descarga a la capa de control. La solución se basa en un protocolo de comunicación en 4 pasos; para cada unidad, la capa de control:

• solicitará autorización para trabajar con el número de serie en la estación (interlocking);
• solicitará todas las reglas aplicables de forma secuencial;
• cargará los resultados reales de cada regla aplicada (fuerza de presión real, ángulo, torque, etc.);
• finalmente, confirmará si la salida es buena o es de desecho.

Esta solución, si bien “más lenta” en tanto resulta en sobrecarga de información, permite una comunicación síncrona entre Opcenter Execution (SIMATIC IT) y la capa de control, de forma que la producción se pueda detener y reanudar en caso de que esto se requiera. Adicionalmente, el módulo de manejar de recetas habilita la descarga de todas las reglas aplicables de inmediato y permite que la capa de control inteligente las revise.