El desafío
por George Thiers, Timothy Sprock y Leon McGinnis (Georgia Institute of Technology); Adam Graunke (Boeing Research and Technology); y Michael Christian (The Boeing Company).
Tal y como se presentó en la Winter Simulation Conference de 2016
Un proyecto de investigación de varios años centrado en la transición del diseño a la producción de una empresa aeroespacial mundial y, en particular, en cómo responder a las preguntas relacionadas con la producción mucho antes de lo que es posible hoy en día en el ciclo de diseño de un programa. Una dificultad fundamental es que el tiempo y los conocimientos necesarios para formular modelos de análisis adecuados impiden su uso rutinario, especialmente en el desarrollo de nuevos programas. El objetivo del proyecto era reducir estos requisitos, y a finales de 2014 se había desarrollado una metodología para la generación de análisis bajo demanda para responder a preguntas rutinarias sobre sistemas de producción. En 2015 se llevó a cabo un proyecto piloto para demostrar la eficacia, que una aplicación de la metodología podría de hecho reducir en al menos un orden de magnitud el tiempo necesario para responder a una pregunta frecuente, de forma repetible mientras que la especificación de los productos, sus planes de proceso, las instalaciones previstas y los recursos disponibles cambiaban con frecuencia. Este artículo resume la metodología, su aplicación en un proyecto piloto y sus resultados preliminares.
Introducción
Una empresa aeroespacial internacional pretende mejorar el diseño de sus sistemas de producción abordando cuestiones clave en una fase más temprana del ciclo de vida del producto. Las herramientas de diseño asistido por ordenador (CAD) y de ingeniería (CAE) ayudan a los diseñadores de productos proporcionándoles la posibilidad de evaluar métricas mecánicas, aeroespaciales, térmicas y de otros tipos sobre los diseños de productos candidatos. Sin embargo, las herramientas informáticas que ayudan a los diseñadores de sistemas de producción con capacidades de análisis bajo demanda son más limitadas. Por tanto, la visión de la empresa es mejorar el soporte de herramientas para el diseño, el diagnóstico y la mejora continua de los sistemas de producción, comenzando por ofrecer a los diseñadores la capacidad de evaluar con un botón métricas de "producibilidad" y preguntas como:
- Si el diseño de un avión incluyera nuevos materiales, ¿existe capacidad para fabricar las piezas necesarias a un ritmo y coste determinados?
- Si un subconjunto importante se divide en distintas secciones fabricadas por diferentes proveedores y unidas en el montaje final, ¿cómo debe equilibrar el calendario de entrega una gran solidez frente a las interrupciones del suministro y unos costes de inventario bajos?
- ¿Qué inversión en herramientas, utillajes, moldes y otros recursos se necesita para fabricar un determinado subconjunto a un determinado ritmo de producción?
Cualquiera que sea la lista de preguntas, el objeto de la investigación es cómo responderlas con un botón, y hay varios factores que lo dificultan. En primer lugar, la capacidad de respuesta con un botón requiere formular y resolver una serie de modelos de análisis de investigación operativa, incluidos modelos estadísticos, de simulación de eventos discretos y de análisis de optimización.Los métodos y algoritmos de solución están bien estudiados en la literatura, pero no está bien estudiado cómo formular un modelo de análisis a partir de una descripción del sistema neutra para el análisis y una pregunta sobre el sistema de forma automatizada, robusta y reutilizable. En segundo lugar, durante las primeras fases de diseño, es posible que la especificación de un producto sólo exista a un alto nivel de abstracción, lo que significa que la funcionalidad de los pulsadores debe acomodarse a cantidades variables de detalle. En tercer lugar, mientras que la información sobre productos y procesos puede recogerse de forma rigurosa en los sistemas de gestión del ciclo de vida del producto (PLM), la información sobre recursos e instalaciones no suele serlo: en muchas empresas, los conocimientos sobre producción suelen ser informales, tácitos y transitorios. Si la columna vertebral de la arquitectura de una empresa incluye CAD, gestión de datos de productos (PDM), sistemas de ejecución de fabricación (MES) y planificación de recursos de fabricación (MRP), la combinación de estos sistemas sigue careciendo de la información necesaria para responder a muchas preguntas sobre la capacidad de producción, incluidas las enumeradas anteriormente. Por lo tanto, cuando un diseñador pulsa el botón, también debe esperar suministrar información adicional, lo que plantea las cuestiones de qué es exactamente esa información, qué lenguaje y formato debe adoptar y qué flexibilidad existe para su detalle.
Una analogía de la visión de la empresa es aumentar los asistentes personales, como Siri de Apple, la búsqueda por voz de Google o Cortana de Microsoft, con la funcionalidad adicional necesaria para responder a preguntas de productividad sobre los diseños candidatos. Para entender en qué se diferencia la funcionalidad necesaria de la que ya existe, hay que tener en cuenta que muchas de las preguntas que se hacen a los asistentes personales pueden responderse mediante una simple búsqueda en una base de datos o en Internet. También existen ejemplos aislados de maquinaciones más avanzadas, una de las más populares es el cálculo de direcciones de conducción. Las preguntas sobre la navegación por redes de transporte civilnosuelen responderse buscando rutas pregrabadas en bases de datos, sino formulando un análisis de optimización del flujo de la red por el camino más corto, resolviéndolo (quizá utilizando el algoritmo de Dijkstra con heurística) y haciéndolo en cuestión de segundos y de forma invisible para el usuario final. Con esta analogía, los factores enumerados anteriormente pueden resumirse en dos retos: (1) una necesaria generalización y ampliación de las capacidades de los asistentes personales para la formulación y solución de análisis, y (2) el modelado. Responder a preguntas sobre direcciones de conducción es posible porque los asistentes personales ya tienen un conocimiento detallado de las redes de transporte civil. Sin embargo, no tienen conocimiento de los productos, procesos, recursos e instalaciones patentados de una empresa arbitraria, e incluso si tuvieran acceso a los sistemas de información de la empresa, estos no son completos, ni pueden funcionar comúnmente en el papel requerido de un entorno de diseño experimental.
A finales de 2014, se había desarrollado una metodología para hacer frente a estos retos, y en particular al reto del modelado. La metodología permite responder mediante un botón a cuestiones de producibilidad a través de la formulación automática de muchos tipos de modelos de análisis diferentes, pero el proyecto piloto se centró exclusivamente en la formulación de modelos de simulación de eventos discretos, en consonancia con la observación de Nelson de que "la simulación es cada vez más elúnicométodo capaz de analizar, diseñar, evaluar o controlar los sistemas inciertos, complejos y a gran escala en los que estamos interesados" (Taylor et al. 2013). Un requisito impuesto por la empresa es utilizar herramientas comerciales disponibles en el mercado (COTS) para modelos de simulación formulados automáticamente, incluidos Simio y Tecnomatix Plant Simulation.
1. La solución
1.1 Trabajo previo: Generación y modelado de modelos
Muchos analistas de ingeniería han intentado añadir automatización a su flujo de trabajo, siguiendo el paradigma de separar la descripción del sistema del análisis del sistema, creando descripciones del sistema de una manera supuestamente más fácil, y luego transformándolas automáticamente en la semántica y sintaxis de un lenguaje de análisis particular según sea necesario. Yuan et al. (1993) describen un generador de modelos de simulación en lenguaje SIMAN de "sistemas operativos discretos" que se modelan con una "red de operaciones" y "ecuaciones de operación". Son y Wysk (2001) describen la construcción automática de modelos de simulación en el lenguaje Arena para responder a preguntas sobre el control del taller de fabricación, utilizando una abstracción de red denominada "grafo de estado de piezas basado en mensajes" para capturar posibles rutas a través de los recursos de un taller. Fournier (2011) describe la construcción automática de modelos de simulación en varios lenguajes (QUEST, Arena, ProModel, FlexSim) utilizando el estándar Core Manufacturing Simulation Data (CMSD), y Bergmann et al. (2012) mapea CMSD al lenguaje de simulación SLX. Dong y Chen (2001) generan Redes de Petri orientadas a objetos a partir de reglas de comportamiento de la Arquitectura de Sistemas Abiertos de Fabricación Integrada por Ordenador (CIMOSA), y Deavours et al. (2002) generan Redes de Actividad Estocástica (SAN) a partir de formalismos de modelado compatibles con el marco Mobius. Los generadores de modelos de análisis de simulación que introducen modelos de sistemas en lenguaje SysML son Batarseh et al. (2015) y Kapos et al. (2014), este último generando modelos ejecutables de Especificación de Sistemas de Eventos Discretos (DEVS).
Obsérvese la variedad de lenguajes de descripción de sistemas en las citas anteriores. Además de los "sistemas operacionales discretos", los "grafos de estados parciales basados en mensajes", el CMSD, etc., hay muchos otros lenguajes candidatos, que van desde ideas de investigación hasta estándares adoptados. Un estándar OASIS para el intercambio de datos de planificación y programación de la producción es (OASIS 2011). El resultado del comité ISO TC 184/SC4 incluye el estándar ISO 10303 para la captura legible por máquina y el intercambio de datos de productos (Pratt 2001). AutomationML es un estándar de estándares para el intercambio de datos entre herramientas de ingeniería en una planta de producción (Drath et al. 2008). Estos esfuerzos estandarizan los esquemas de datos, y también hay esfuerzos para estandarizar la semántica y las ontologías. Una norma de OMG que formaliza la semántica de los procesos empresariales es Business Process Model and Notation (BPMN) (OMG 2011). Un estándar del Supply Chain Council que formaliza la semántica de la gestión de la cadena de suministro es el Supply Chain Operations Reference (SCOR) (SCC 2012). Las propuestas para formalizar la semántica de fabricación incluyen la Ontología de Semántica de Fabricación (MASON) (Lemaignan et al. 2006) y también Molina y Bell (1999), Cutting-Decelle et al. (2007), y Guerra-Zubiaga y Young (2008).
Tanenbaum (1981) observa: "Lo bueno de las normas es que hay muchas entre las que elegir"."En los primeros años del proyecto de investigación, los autores buscaron un lenguaje de descripción de sistemas único y "perfecto" para los sistemas de producción (Thiers y McGinnis, 2013), agregando diversas contribuciones citadas y rellenando huecos. Sin embargo, nunca se desarrolló nada que los autores pudieran argumentar plausiblemente que todo el mundo debería usar, por razones que incluyen una tensión fundamental entre lo concreto y lo abstracto (el primero necesario para la accesibilidad del usuario, el segundo necesario para la robustez y la reutilización), y también que un lenguaje está inexorablemente moldeado por los casos de uso de sus autores en un momento en el tiempo.Inevitablemente, tanto los casos de uso como el tiempo cambian, el lenguaje debe evolucionar, los programas de transformación que están estrechamente acoplados al lenguaje se rompen, y el autor debe mantener código que ha olvidado hace tiempo, si es que se puede encontrar al autor original. El progreso sólo se reanudó cuando finalmente se aceptó que nunca existiría un lenguaje de descripción de sistemas único y "perfecto" para los sistemas de producción, y se ideó una forma de dar cabida a una plétora de lenguajes de descripción de sistemas similares pero diferentes.
1.2 El reto de las herramientas COTS de simulación de eventos discretos
Además de un gran número de lenguajes para la descripción de sistemas, también hay un gran número de lenguajes para el análisis de simulación de eventos discretos - a diferencia del dominio de análisis de optimización que tiene un lenguaje canónico "Un Lenguaje de Programación Matemática" (AMPL) (Fourer et al. 1993), hasta donde saben los autores, el dominio de simulación de eventos discretos no tiene tal lenguaje canónico, y cada elección de lenguaje difiere de otras opciones de lenguaje tanto en la semántica como en la sintaxis. Si hay m opciones de lenguaje de descripción del sistema yn opciones de lenguaje de análisis de la simulación, entonces se producenm n permutaciones de transformaciones de la descripción del sistema al análisis de la simulación, lo que limita gravemente la rentabilidad de la inversión de escribir y mantener cada una de ellas. La metodología descrita en este documento reducem a1, pero sigue permitiendomlenguajes de descripción del sistema añadiendo un paso de transformación intermedio que acopla cada lenguaje a un lenguaje de abstracción puente de back-end.
Entre los esfuerzos citados en la sección 1.Entre los esfuerzos citados en la sección 1.1 para generar automáticamente modelos de simulación, existe una variedad considerable en cuanto a la ubicación de la "inteligencia" de la transformación: puede estar aguas arriba en el lenguaje de descripción del sistema (fusionando efectivamente ese lenguaje con el lenguaje de análisis aguas abajo), en la propia transformación (como con los lenguajes y herramientas de transformación de modelo a modelo de propósito general, incluidos QVT (OMG 2016) y ATL (EMF 2016), o aguas abajo en el lenguaje de análisis del sistema (fusionando efectivamente ese lenguaje con el lenguaje de descripción aguas arriba, el enfoque de facto de muchos proveedores de herramientas de simulación COTS). En algunos casos, los investigadores intentan simplificar las transformaciones escribiendo su propio lenguaje de simulación de eventos discretos y solucionador, como en Biswas y Narahari (2004), Chatfield et al. (2006), y Schonherr y Rose (2009), lo que permite la transformación de la descripción del sistema al análisis de simulación utilizando mapeos directos uno a uno. En opinión de los autores, desarrollar herramientas de análisis ad hoc cuando se dispone de herramientas COTS adecuadas -incluso si su lenguaje es inconveniente- no parece un camino sostenible. La metodología descrita en este artículo sitúa la mayor parte de la "inteligencia" de la transformación en las propias transformaciones de modelo a modelo, pero propone un pequeño paso adelante al construir modelos de simulación en la mayor medida posible utilizando bloques de biblioteca de modelos que son versiones ejecutables de elementos de modelos de abstracción puente.
Metodología
Una metodología es una colección de procesos, métodos y herramientas relacionados (Estefan 2008), y el proceso de la metodología de este documento se muestra en la figura 1. Tanto el Modelo del Sistema en la parte superior izquierda como el Modelo de Abstracción Puente en la parte superior central son sólo descripciones, y ambos se componen en realidad de dos niveles diferentes de abstracción de modelado, que podrían denominarse el esquema y los datos o el metamodelo y el modelo de instancia, o definiciones de clases e instancias de objetos en la terminología del software orientado a objetos. El lenguaje de descripción del sistema que se discute en profundidad en la sección 1.1 es la capa superior del esquema o metamodelo, y la distinción es importante porque las transformaciones de modelo a modelo sólo dependen de esta capa y deberían funcionar con cualquier modelo de datos o de instancia. El Metamodelo de Abstracción de Puentes es una creación abstracta que captura los elementos comunes subyacentes compartidos por todos los sistemas logísticos de eventos discretos: sistemas de fabricación, cadenas de suministro, sistemas de almacenamiento y distribución, sistemas de transporte y logística, sistemas de prestación de asistencia sanitaria, etcétera. Una observación clave es que la mayoría de los sistemas estudiados en ingeniería industrial tienen una estructura de red, y la mayoría de los análisis de investigación operativa de los mismos son análisis basados en redes. El metamodelo de abstracción de puente ha evolucionado desde su creación hasta convertirse en una colección de modelos en capas, pero la capa original y fundamental los autores la denominan red de flujo de fichas, con un extracto que se muestra en la figura 2.
El modelo de abstracción puente se introduce para mediar en una tensión fundamental entre lo concreto y lo abstracto: un modelo de sistema debe ser tan concreto como sea necesario para la accesibilidad, el modelo de abstracción puente debe ser tan abstracto como sea posible para la robustez y la reutilización, y la eficacia depende de que las correspondencias entre ambos sean fáciles de crear y mantener. Las correspondencias se realizan como especificaciones declarativas de transformaciones de modelo a modelo, y su actualización en respuesta a modelos de sistema nuevos o en evolución debe ser lo más sencilla y rápida posible. En terminología de software, el paso intermedio añadido tiene el efecto de mitigar el estrecho acoplamiento entre los lenguajes de descripción de sistemas y los lenguajes de análisis de sistemas, para aliviar los costes cuando un lenguaje de descripción de sistemas debe cambiar inevitablemente con los casos de uso y el tiempo. En la figura 1, el acoplamiento de la segunda etapa entre el Modelo de Abstracción Puente y el Modelo de Análisis seguirá siendo estrecho, pero el acoplamiento de la primera etapa entre el Modelo de Sistema y el Modelo de Abstracción Puente debe ser lo más holgado posible para dar cabida a Modelos de Sistema nuevos o en evolución. Es importante destacar que, debido a la estabilidad del modelo de abstracción puente, la tarea de escribir y mantener las transformaciones de la segunda fase debería tener un retorno de la inversión suficiente para que pueda ser adoptada por un equipo dedicado, en lugar de por diversos analistas.
Muchas ideas nuevas son variaciones de otras antiguas, y el proceso de la figura 1 puede clasificarse como tal, un trasplante de las mejores prácticas de la ingeniería de software a la de sistemas. La novedad de la metodología radica en sus métodos y herramientas, que abordan los grandes retos de investigación que existen para que esto funcione en la ingeniería de sistemas:
- El Metamodelo de Abstracción de Puentes, un metamodelo explícito, neutro desde el punto de vista del análisis y legible por humanos y máquinas, que capta los elementos comunes subyacentes que comparten todos los sistemas logísticos de eventos discretos. A medida que evolucionaba el proyecto de investigación, pronto quedó claro que el modelo de abstracción puente se desarrollaría de forma iterativa durante años. Modelar la estructura de un sistema suele ser lo más fácil, modelar el comportamiento (piense en procesos) suele ser más difícil y modelar el control (piense en reglas de negocio) suele ser lo más difícil de todo. Además, la mayoría de los lenguajes candidatos para crear este metamodelo (UML, SysML, Ecore, OPM, diagramas entidad-relación, etc., el lenguaje del lenguaje) están orientados a objetos, y el modelado de sistemas orientados a objetos puede ser una forma de pensar poco familiar.
- Transformaciones de modelo a modelo. Para transformar un modelo de sistema en un modelo de abstracción puente en la figura 1, el mecanismo ha evolucionado desde la aplicación de estereotipos UML a especificaciones declarativas en lenguajes de transformación de propósito general, incluidos QVT y ATL, hasta un lenguaje y un motor de transformación de modelo a modelo personalizados que se describen con más detalle en la sección 3.
- Comprender el espacio de preguntas sobre los sistemas de producción y los análisis capaces de responderlas. Este reto está íntimamente relacionado con el conocimiento profundo del dominio. En el momento en que una aplicación de la metodología soporte una masa crítica de preguntas rutinarias sobre la capacidad de producción, surgirá un nuevo reto: cómo hacer un uso productivo de un "genio de la respuesta a preguntas" formulando las preguntas adecuadas. Los autores prevén que para ello será necesario captar los procesos de nivel superior (diagnóstico, mejora continua, diseño, etc.) y las preguntas formuladas durante cada etapa de la ejecución de esos procesos.
En Thiers (2014), Sprock y McGinnis (2014) y Sprock (2016) se puede encontrar un amplio análisis de los procesos, métodos y herramientas de la metodología. La búsqueda y experimentación con nuevos métodos y herramientas continúa, por ejemplo, un método de uso de bloques de biblioteca de modelos que son versiones ejecutables de elementos de modelo de abstracción de puente, en la mayor medida posible, cuando se construyen modelos de análisis en un dominio sin un lenguaje canónico.
PROYECTO PILOTO
A finales de 2014 la metodología había madurado sobre el papel, y en 2015 se llevó a cabo un proyecto piloto para demostrar la eficacia, que una aplicación de la metodología podría de hecho reducir el tiempo necesario para responder a una pregunta frecuente en al menos un orden de magnitud, de una manera repetible mientras que la especificación de los productos, sus planes de proceso, las instalaciones previstas y los recursos disponibles cambian continuamente. Los pasos eran los siguientes
Paso 1: Hacer que el usuario elija un escenario frecuente para el que la formulación de modelos de simulación de eventos discretos, para responder a una variedad de preguntas, podría ser muy valiosa.El escenario para este proyecto implicaba la evaluación de la capacidad de fabricación para la fabricación de piezas de materiales compuestos, con la pregunta frecuente "¿Cuál es el número mínimo de recursos necesarios para apoyar una tasa de producción dada?" De interés son los recursos de moldes de composite y autoclaves, que para grandes piezas aeroespaciales pueden ser muy caros con largos plazos de aprovisionamiento.
Paso 2: Para el escenario elegido, crear un lenguaje de descripción del sistema.Este paso requiere capturar la semántica neutral al análisis que los usuarios emplean para hablar de su negocio y representarlo en los sistemas de información. Este lenguaje evolucionó de forma iterativa durante el proyecto piloto, y su estado en la iteración final se muestra en la figura 3. Obsérvese que se trata de un esquema a nivel de usuario. Obsérvese que se trata de un modelo a nivel de esquema y no de ninguna instancia del sistema de producción: sirve como definición común de instalaciones, procesos de fabricación, alternativas a los mismos, estados futuros deseados para ellos, etc.
¿Puede considerarse el lenguaje de la figura 3 un metamodelo abstracto para describir sistemas de producción arbitrarios? Desde luego que no: se trata del esquema de un usuario concreto, y de un esquema mínimo para un caso de uso concreto, que puede diferir sintáctica e incluso semánticamente de los esquemas de otros usuarios. Entre las características importantes se incluye la dosificación en el autoclave (por volumen de piezas o por una lista específica de tipos y cantidades de piezas), así como los recursos asociados a las piezas a través de múltiples pasos del proceso (moldes de estratificación compuestos desde la fase previa a la estratificación hasta la fase posterior al curado). Esta semántica también permite separar las instalaciones físicas de las definiciones de procesos funcionales, ya que un componente clave de la cuestión de la capacidad es que los planes de procesos no se ejecutan en el vacío, sino que se ejecutan en instalaciones concretas que ejecutan múltiples planes de procesos simultáneamente mientras comparten recursos comunes. Entre los aspectos semánticos que no se incluyen, pero que pueden ser importantes en otros escenarios, se encuentran los trabajos con plazos, las redes de viajes dentro de las instalaciones y entre ellas, el control de rutas de trabajos y recursos, etc. La innovación de la metodología consiste en que los programas generadores de análisis sólo están vagamente acoplados al lenguaje de descripción del sistema de la figura 3, con el efecto de que esos programas pueden seguir funcionando mientras evoluciona el lenguaje (durante el proyecto piloto, el lenguaje evolucionó en aproximadamente ocho iteraciones espaciadas un mes). Dicho de otro modo, la metodología relaja la carga de hacer "perfecto" un lenguaje de descripción de sistemas antes de invertir en programas generadores de análisis que dependan de él.
Paso 3: Precisar la pregunta.Este paso debería resultar superfluo una vez alcanzado cierto nivel de madurez del soporte de herramientas, pero es imprescindible durante los primeros proyectos piloto. La tarea consiste en determinar qué información espera el autor de la pregunta en una respuesta, y cómo extraer o inferir esa información del resultado de la simulación. Para la pregunta"¿Cuál es el número mínimo de recursos necesarios para mantener un ritmo de producción determinado?", supongamos que la respuesta es "x ey unidades de los tipos de recursos A y B son las cantidades mínimas necesarias para mantener, de media, 20 aviones al mes". ¿Es esto suficiente, o también se esperan calificadores de riesgo como"x e y unidadesde los tipos de recursos A y B sólo producirán 19 aviones en α% de los meses y sólo 18 aviones en β% de los meses"? Un gran punto para el desarrollo futuro es devolver respuestas con interpretaciones, calificadores de riesgo y más. La metodología es una herramienta de apoyo a la toma de decisiones, no una herramienta de toma de decisiones, porque la toma de decisiones debe reflejar una evaluación humana del riesgo, que podría ser el eje x en algún tipo de diagrama de Pareto-frontera que se devuelve como respuesta a una pregunta.
Precisar la pregunta también supuso un esfuerzo exclusivo del primer proyecto. Dado que la mayor parte del trabajo consistía en el desarrollo de software, se siguió un paradigma de desarrollo en espiral con un periodo de iteración de aproximadamente un mes. La pregunta "¿Cuál es el número mínimo de recursos necesarios para mantener un determinado ritmo de producción?" se convirtió en el colofón de una serie de preguntas hito:
- ¿Cuál es la duración (prevista) (del ciclo en bruto) de un determinado (trabajo)? Un modelo de simulación de eventos discretos para responder a esta pregunta es el más sencillo e interesante que pueda imaginarse.
- ¿Cuál es el (rendimiento esperado) de la ejecución regular de un determinado (trabajo)? Para responder a esta pregunta sólo se requiere la simulación del proceso, sin el contexto de una instalación de fabricación, otros planes de proceso que se ejecuten simultáneamente en esa instalación, paradigmas de recursos compartidos, etc.
- ¿Cuál es el (rendimiento) (esperado) de la fabricación de determinados (productos) en determinadas (instalaciones)? Para responder a esta pregunta es necesario simular una única instalación de fabricación que ejecute varios planes de proceso simultáneamente y comparta recursos comunes. Para responder a esta pregunta, basta con añadir un optimizador que busque el número mínimo de recursos.
- ¿Cuál es el número mínimo de recursos necesarios para alcanzar un determinado rendimiento? Curiosamente, en realidad nunca se añadió un optimizador; el patrocinador del proyecto piloto reconoció que se trataba de una simple extensión y prefirió emplear mejor el tiempo añadiendo fidelidad a la descripción del sistema y, a su vez, a los modelos de simulación generados automáticamente.
Paso 4: Asignar el modelo de sistema front-end al modelo de abstracción puente back-end, tanto como sea necesario para responder a la pregunta. La eficacia de la metodología depende del acoplamiento más laxo posible entre estos dos modelos, y el más laxo que podemos imaginar es una especificación declarativa de una transformación de modelo a modelo, cuyo ejemplo se muestra en la figura 4.
El XML de la figura 4 es una representación de bajo nivel con la que no se espera que los usuarios interactúen directamente. Las mejoras en la usabilidad deberían facilitar la creación y actualización de especificaciones declarativas de transformaciones de modelo a modelo. Al inicio del proyecto, los autores habían imaginado realizar estos mapeos mediante el mecanismo de aplicación de estereotipos UML (Batarseh et al. 2012). Sin embargo, esto pronto se volvió insostenible debido a su inflexibilidad: la aplicación de un estereotipo UML define de hecho una regla de transformación de uno a uno, lo que obliga al modelo del sistema y al modelo de abstracción puente a parecerse mucho y solo diferir efectivamente en la sintaxis. A continuación, los autores consideraron lenguajes de transformación de modelo a modelo de uso general y estandarizados, como QVT o ATL, pero las especificaciones de transformación eran bastante prolijas y pronto se dieron cuenta de que incorporar el conocimiento del objetivo de la transformación permitía una simplificación drástica. Esta simplificación conlleva una pérdida de flexibilidad, pero una flexibilidad que no era necesaria, en consonancia con la conclusión de Cleenewerck y Kurtev (2007) de que "es mejor abordar el problema de la semántica traslacional en la Ingeniería Dirigida por Modelos con un lenguaje de transformación específico del dominio en lugar de con uno de propósito general". El trabajo futuro incluye reconciliar el lenguaje de transformación personalizado y específico del dominio con un estándar como QVT.
Paso 5: Crear modelos de instancia y pulsar "Adelante" Para responder a una pregunta de productividad con un botón, el último paso requiere describir rápidamente el objeto de la pregunta: instancias de productos, procesos, recursos e instalaciones. El metamodelo de la figura 3 es análogo a las definiciones de clases de software, que pueden generar un gran número de instancias de objetos. En el proyecto piloto esto se hizo en un entorno tabular y similar a Excel, y en la figura 5 se muestra un extracto.
Las tablas y su esquema de la figura 5 se ajustan al metamodelo de la figura 3: la operación corresponde a una tabla y cada atributo corresponde a una columna. Las tablas y el esquema de un modelo de instancia se generan mediante un mapeo objeto-relacional, y un usuario describe el tema de la pregunta rellenando las tablas. Este es un entorno de modelado que podría beneficiarse de muchas mejoras de usabilidad; una es que las tablas que se muestran a los usuarios son efectivamente tablas de bases de datos relacionales en bruto, y la adición de una capa de vista permitirá la simplificación, la organización y la ocultación de datos redundantes (por ejemplo, tablas de unión que se siguen de cualquier atributo cuyo límite superior de multiplicidad es > 1). Otra mejora es que, aunque en la figura 5 se muestran tablas y columnas para cada elemento del metamodelo de la figura 3, el conocimiento de la pregunta de un usuario permite filtrar visualmente sólo las tablas y columnas relevantes para responder a esa pregunta. Otra mejora consiste en añadir la visualización de cualquier modelo de sistema del usuario, ya que a medida que se rellenan las filas de las tablas se construye en segundo plano un modelo de abstracción puente, y la visualización debería ser posible al menos para las vistas de procesos e instalaciones. Las mejoras en la usabilidad de este entorno son fundamentales para reducir al máximo el tiempo y los conocimientos necesarios para responder a las preguntas rutinarias sobre productividad.
En la figura 6 se muestra un ejemplo de un modelo de simulación de eventos discretos y un experimento que se generan automáticamente al pulsar "go".
Impacto en la empresa
Conclusiones y trabajo futuro
La transición del diseño a la producción es un proceso empresarial complejo, y la investigación descrita en este artículo respalda ese proceso al permitir a los diseñadores apreciar las consecuencias para la producción de las decisiones de diseño mucho antes de lo que es posible hoy en día en el ciclo de diseño de un programa. Se ha desarrollado una metodología que permite responder a las preguntas sobre la capacidad de producción con sólo pulsar un botón, y su novedad radica en el grado de separación de las preocupaciones: separa la descripción del sistema del análisis del sistema y, además, separa la descripción concreta del sistema front-end de la descripción abstracta del back-end. La implementación de un proyecto piloto admite modelos de sistema creados en el lenguaje Ecore, el conjunto de preguntas enumeradas en la sección 3 y la generación mediante pulsadores de modelos de simulación y experimentos en los lenguajes Simio, SimEvents y Tecnomatix Plant Simulation para responder a esas preguntas. La pregunta del proyecto piloto se refería al número de recursos -un cambio paramétrico- y también se demostró la capacidad de la aplicación para acomodar cambios estructurales, incluidos cambios en los planes de proceso, cambios en las asignaciones de puestos de trabajo, refinamiento de los tipos de recursos, descripción en niveles de abstracción, etc. En el momento de redactar este documento, no existe ninguna diferencia funcional entre los cambios paramétricos y los estructurales, ya que la implementación regenera completamente un modelo de simulación para cualquier cambio en el modelo de instancia, aunque esto puede sofisticarse en el futuro en aras de la eficiencia.
Al final del proyecto piloto, la prueba de concepto se puso a disposición del cliente. El cliente estima que, en el caso de preguntas rutinarias sobre sistemas de producción, la aplicación de la metodología en una herramienta puede suponer una reducción drástica del tiempo, el coste y los conocimientos necesarios para utilizar la simulación y otros tipos de análisis para responder a esas preguntas, al menos una reducción del orden de magnitud. Estas reducciones pueden ahorrarse o dedicarse a evaluar más escenarios de producción y sus impactos, considerar más ideas y alternativas de mejora y explorar más el espacio de diseño de un sistema de producción. Sin embargo, el cliente también señala que son necesarias varias mejoras para alcanzar un nivel de preparación técnica (TRL) avanzado y producir una herramienta que los analistas agradecerían en su trabajo diario. La herramienta es un entorno de modelado y transformación de modelos, y se necesitan mejoras en el lenguaje y la interfaz de usuario para crear esquemas de descripción de sistemas, modelos de instancia de sistemas conformes, transformaciones a modelos de abstracción puente y procesos automatizados de formulación de análisis. Estas mejoras ayudarán a delimitar los tipos de preguntas sobre sistemas de producción que son de hecho "rutinarias", y éste podría ser un conjunto sorprendentemente generoso.
Se espera que esta investigación pueda hacer crecer el mercado de los análisis de Investigación Operativa. Los análisis estadísticos, de simulación de eventos discretos y de optimización pueden responder a preguntas de importancia crítica, pero el tiempo, el coste y los conocimientos necesarios para su utilización en el statu quo pueden resultar prohibitivos para todas las empresas, salvo para las más grandes. En opinión de los autores, las más apremiantes son la evolución de las descripciones de los sistemas, pasando de modelos principalmente estructurales a otros más maduros que incluyan el comportamiento y el control, y la comprensión de los procesos de alto nivel, como el diseño, el diagnóstico y la mejora continua. Para que el diseño de los sistemas de producción sea tan sofisticado como el diseño de los propios productos, es imprescindible un profundo conocimiento de los sistemas de ingeniería industrial, además de la capacidad de emplear de forma rentable el análisis de la investigación operativa cuando sea necesario.
Agradecimientos
La investigación de la que aquí se informa ha contado con el apoyo de Georgia Tech a través de la Cátedra Gwaltney de Sistemas de Fabricación, de una subvención de Rockwell-Collins y de proyectos de investigación financiados por el Centro de Investigación de United Technologies y la Asociación Universitaria Estratégica Boeing-Georgia Tech.