El desafío
por Stephen D. Roberts (Universidad Estatal de Carolina del Norte) y Dennis Pegden (Simio LLC)
Tal y como se presentó en la Conferencia de Simulación de Invierno de 2017
Durante el último medio siglo, la simulación ha avanzado como herramienta de elección para el análisis de sistemas operativos. Los avances de la tecnología han estimulado nuevos productos y nuevos entornos sin estándares de software ni homogeneidad metodológica. Cada nuevo lenguaje o producto de simulación ofrece su propio conjunto único de características y capacidades. Sin embargo, estos productos de simulación son la evolución de la investigación, el desarrollo y la aplicación. En este artículo interpretamos el desarrollo histórico del modelado de simulación. En nuestra opinión, el modelado de simulación es la parte del proceso de resolución de problemas de simulación que se centra en el desarrollo del modelo. Es la interpretación de un problema real de producción (o servicio) en términos de un lenguaje de simulación capaz de realizar una simulación de ese proceso del mundo real. Aunque la "interpretación" está en los "ojos del que mira" (es decir, nosotros), hay algunos puntos de vista y métodos históricos que influyen en el diseño del modelo de simulación.
Introducción
Modelos frente a modelización
Los modelos matemáticos y estadísticos formales de operaciones se han desarrollado a lo largo de varias décadas de investigación. Sin embargo, cuando un modelo se aplica más allá de sus supuestos, deja abierta la cuestión de su aplicabilidad y el modelizador se enfrenta a la adaptación del modelo o al desarrollo de un nuevo modelo. La adaptación o creación de un nuevo modelo analítico es una tarea importante y que pone a prueba la capacidad analítica del desarrollador, y puede requerir bastante más tiempo y esfuerzo, quizá sin resultados tangibles.
El valor de un modelo es su uso. Dado que los modelos individuales tienen limitaciones y su ampliación puede resultar desalentadora, algunos investigadores y profesionales prefieren un entorno de modelización más flexible. La simulación se considera desde hace tiempo una herramienta de modelización que dispone de un entorno de desarrollo muy amplio y no requiere sofisticación matemática o estadística para el desarrollo y uso del modelo. Además, para aliviar la carga que supone el desarrollo de modelos de simulación, se han desarrollado diversos lenguajes de simulación. Cada lenguaje de simulación ofrece sus propias construcciones de modelado dentro de las cuales se puede construir, simular y analizar un modelo de simulación. Aunque los lenguajes han cambiado con el tiempo, el enfoque de modelado está inextricablemente ligado a su perspectiva de ejecución de la simulación.
Modelado
El objetivo de este documento es ofrecer una historia personalizada (y, por tanto, limitada) del modelado de simulación, tal y como se ha popularizado en gran medida a través de la Winter Simulation Conference. El uso de la simulación en un contexto de resolución de problemas requiere varias competencias:
- Definir correctamente el problema y establecer los objetos.
- Utilizar conceptos de modelización para abstraer las características esenciales del sistema en un modelo.
- Recoger y compilar datos y datos de entrada para el modelo.
- Convertir el modelo en un código legible por ordenador capaz de simular el sistema.
- Dar instrucciones al ordenador para que realice la simulación correcta y eficazmente en distintos escenarios.
- Resumir y analizar el resultado de la simulación en medidas de rendimiento.
Kiviat (1967) fue uno de los primeros en describir el proceso de modelización y los conocimientos necesarios. Un usuario con conocimientos profundos de casi cualquier lenguaje de programación de propósito general puede proporcionar la mayoría de estas competencias. Sin embargo, la carga de conseguir una simulación final es formidable, ya que el programador necesita proporcionar software para realizar todos los componentes necesarios, incluyendo la generación de números aleatorios, la generación de variantes aleatorias, la actualización del estado y el avance temporal, la recogida y visualización de estadísticas, etc. Por ello, existen lenguajes y bibliotecas de simulación que facilitan la creación de simulaciones.
Aunque muchos lenguajes de simulación han ido apareciendo y desapareciendo, los enfoques fundamentales de la simulación son similares. Un lenguaje de simulación ejecuta un modelo del sistema para representar dinámicamente el comportamiento del sistema a lo largo del tiempo. Esto se hace cambiando el valor de las variables de estado a lo largo del tiempo simulado. Los lenguajes de simulación pueden clasificarse en dos grandes familias: discretos y continuos. Las herramientas discretas modelan sistemas en los que el estado del sistema cambia en unidades discretas en momentos específicos. Las herramientas continuas modelan sistemas en los que el estado del sistema cambia continuamente a lo largo del tiempo. Aquí nos centramos en los sistemas discretos, aunque también se consideran los sistemas continuos. Hoy en día, la mayoría de los lenguajes de simulación son multimodales y admiten varios paradigmas de modelado que suelen mezclar capacidades discretas y continuas.
La solución
Modelado de visiones del mundo
Una simulación discreta consiste en un conjunto de variables de estado y un mecanismo para cambiar esas variables en el momento del evento. Una visión del mundo de modelado de simulación proporciona al profesional un marco para definir un sistema que cumpla los objetivos con suficiente detalle como para poder simular el comportamiento del sistema. A diferencia de las herramientas descriptivas estáticas simples como el diagrama de flujo(https://en.wikipedia.org/wiki/Flowchart), Visio(https://en.wikipedia.org/wiki/Microsoft_Visio), IDEF(https://en.wikipedia.org/wiki/IDEF), UML(https://en.wikipedia.org/wiki/Unified_Modeling_Language), etc., una visión del mundo de modelado de simulación debe dar cuenta con precisión de las transiciones de estado dinámicas que se producen con el tiempo. La visión del mundo proporciona un conjunto definitivo de reglas para avanzar en el tiempo y cambiar el estado discreto (o continuo) del modelo.
A lo largo de los 60 años de historia de la simulación, consideramos que predominan cuatro visiones del mundo distintas: evento, actividades, proceso y objetos (aunque se han ofrecido otras terminologías y taxonomías - véase Overstreet y Nance 1986). Todas ellas fueron desarrolladas por los pioneros de la simulación durante la década de 1960 (Gordon 1961; Markowitz et al. 1962; Tocher 1963; Dahl y Nygaard 1966) aunque estas visiones del mundo se han refinado significativamente en los últimos 50 años, las ideas básicas no han cambiado. La evolución de las herramientas de modelización se ha centrado en lograr un equilibrio entre facilidad de uso y flexibilidad. La visión del mundo basada en eventos proporciona la mayor flexibilidad, pero es más difícil de utilizar. La visión del mundo basada en actividades da más contexto a las actividades, pero con alguna restricción en el modelado. La vista de procesos es más fácil de usar, pero a costa de una menor flexibilidad de modelado. La vista de objetos es la más fácil y natural de todas, pero también tiene el precio de una mayor complejidad de modelado. La historia del desarrollo de lenguajes de simulación se ha centrado generalmente en hacer más flexibles las vistas de proceso y objeto, conservando al mismo tiempo su ventaja con la facilidad de uso. Al mismo tiempo, la mayoría de los lenguajes de simulación modernos mezclan sus métodos de ejecución (utilizando el procesamiento de eventos para eventos futuros y el escaneo de eventos actuales) y emplean la representación multimodal (como redes, procesos, dinámicas), por lo que no caen convenientemente en una taxonomía simple.
Modelización con eventos
Los eventos son puntos secuenciales en el tiempo en los que el sistema cambia de estado. Es responsabilidad del modelador asegurarse de que se reconocen los sucesos y de que se producen los cambios de estado. La decisión sobre los eventos es una elección del modelador y no siempre es obvia. Esta elección se rige en parte por el comportamiento del sistema, pero también por la naturaleza de las medidas de rendimiento que se necesitan de la simulación. Decidir los sucesos es sólo una parte del reto. Una vez que se produce un suceso, es necesario trazar la transición del estado actual al estado sucesor. Además, debe haber algún medio para mantener y añadir eventos en serie. Y hay que recoger y mostrar los resultados adecuados.
En el modelado con eventos es fundamental el papel del calendario de eventos futuros (cuya estructura de datos real ha evolucionado y puede variar) que mantiene todos los eventos futuros. Un lenguaje de simulación de eventos discretos a menudo funciona (1) eliminando el siguiente evento en el calendario de eventos y actualizando el tiempo de simulación a ese tiempo de evento, y (2) luego ejecutando procedimientos de actualización de estado asociados con ese evento.
La lógica de eventos puede implementarse en cualquier lenguaje de programación de propósito general, como Fortran, C++, C#, etc. Sin embargo, dado que algunas de las funciones de simulación, como la generación de variantes aleatorias y la programación de eventos, son comunes a la mayoría de las simulaciones, el uso de una biblioteca de dichas funciones en el contexto de un lenguaje de programación facilita enormemente el desarrollo del programa de simulación. Ejemplos de ello son el uso de Fortran aumentado por GASP (Pritsker y Kiviat 1969) y la programación en lenguaje C con CSIM (Schwetman 1986). Por otra parte, SIMSCRIPT II.5 (Russell 1983) proporcionó su propio lenguaje de programación para aumentar su biblioteca de simulación. También añadía facilidades básicas para definir entidades, asignar atributos a entidades y reunir entidades en conjuntos.
Las herramientas de visión del mundo de sucesos se utilizaron ampliamente durante los primeros 20 años de simulación. Muchas personas se decantaron por estas herramientas porque eran muy flexibles y podían utilizarse para modelar eficazmente una amplia gama de sistemas complejos. Nótese que durante este periodo la eficiencia era más importante porque los ordenadores tenían menos memoria y eran significativamente más lentos. Sin embargo, los modelos basados en eventos eran a menudo difíciles de entender y depurar y requerían conocimientos de programación que limitaban su uso general.
Posiblemente debido a su generalidad, no existen herramientas ampliamente aceptadas para modelar con eventos. Normalmente, los modelizadores emplean diagramas de flujo y dibujos informales. Algunos han abogado por las redes de Petri (Haas 2002) y los diagramas de flujo de señales. Un método general para modelar eventos discretos visualmente son los grafos de eventos, que fue introducido por Schruben (Schruben 1983). Aunque el gráfico de sucesos es una herramienta valiosa para entender la simulación de sucesos discretos, su uso como vehículo de modelado general es bastante limitado y se necesitan una serie de extensiones y embellecimientos para su uso general.
Modelado con actividades: El enfoque en tres fases
El modelado centrado en eventos ha dominado el desarrollo de modelos de simulación en general dentro de la comunidad norteamericana, mientras que K. D. Tocher inició en Inglaterra un enfoque ligeramente diferente del modelado discreto denominado enfoque trifásico (véase Hollocks 2008). Pidd (Pidd 2004) describe un método relacionado denominado exploración de actividades. Las actividades (operaciones iniciadas por eventos) constituyen la base de los cambios de estado cuando se producen eventos. El método de tres fases ha evolucionado, pero esencialmente consiste en (1) avanzar en el tiempo hasta el siguiente evento (llamado siguiente evento vinculado (dependiente del tiempo)), (2) procesar el uno o más siguientes eventos vinculados, y (3) procesar todas las demás acciones que están condicionadas a la ocurrencia de los eventos vinculados. Si bien es necesario un calendario de eventos futuros, también lo son las listas de eventos vinculados y condicionales. Estas listas de eventos condicionales posteriores (dependientes del estado) se vuelven a explorar hasta que no se puede iniciar ninguna actividad.
El enfoque en tres fases se basa en el uso de una herramienta de modelado conceptual denominada "diagrama del ciclo de actividad" (originalmente "diagrama de rueda"). Para identificar las actividades en cualquier sistema, es útil identificar primero los tipos de entidades que participan en las actividades. Por ejemplo, podrían ser los trabajos y un operario. Los trabajos llegan, esperan a la máquina y se marchan. El operario prepara la máquina y la pone en marcha. En caso contrario, el operario está inactivo cuando no hay trabajos que mecanizar. El mecanizado, la preparación y la llegada son actividades vinculadas, mientras que la espera y la inactividad son condicionales y dependen de las acciones vinculadas. Aquí se utiliza el diagrama de ciclo de actividad para identificar los elementos de la simulación trifásica.
Modelización de procesos
El modelado de procesos, principalmente en forma de GPSS (Gordon 1961), surgió paralelamente al desarrollo del modelado de eventos y actividades. El GPSS, desarrollado en IBM, era una herramienta de modelado además de un lenguaje de simulación. Veía el mundo como entidades (llamadas Transacciones) que se movían a través de un modelo compuesto por bloques de propósito especial. Cada bloque tenía una funcionalidad determinada. Existe una correspondencia casi unívoca entre el diagrama de bloques y el código de simulación. Así pues, el modelo de simulación tiene una interpretación visual y otra escrita. Esta correspondencia es importante porque el modelador del GPSS puede, en esencia, traducir el modelo visual casi directamente en un modelo de "enunciado" y, en lugar de la sintaxis del lenguaje, una semántica visual se convirtió en el principal medio de modelado. Este enfoque significaba que el modelador de simulación no necesitaba ser un programador y, por lo tanto, GPSS dio paso a un gran número de personas que intentaban la simulación y que, de otro modo, no habrían participado. El interés por el GPSS se vio alimentado por el libro clásico Simulation Using GPSS (Schriber 1974), escrito por Tomas J. Schriber en la Universidad de Michigan en 1974. Este libro fue uno de los primeros en defender que el modelado de simulación debía realizarse de forma estructurada.
Si bien GPSS fue ampliamente reconocido como fácil de aprender y utilizar, se plantearon muchas preguntas sobre su eficiencia de ejecución. En GPSS, la simulación se ejecuta a partir de dos listas: un calendario de eventos futuros y un calendario de eventos actuales. A medida que se generan las entidades, avanzan por el diagrama de bloques todo lo que pueden. Si encuentran un bloque que puede programar su salida algún tiempo después, esa entidad se coloca en el calendario de eventos futuros. Sin embargo, si la entidad no puede seguir adelante (quizá no haya recursos disponibles), se coloca en el calendario de eventos actuales. El calendario de eventos actuales se escanea y se vuelve a escanear hasta que no hay más acciones (algo parecido al escaneo de actividades) y entonces se elimina el siguiente evento del calendario de eventos y se avanza en el tiempo. Este escaneo del calendario de eventos actuales, junto con una serie de otras cuestiones, fueron la base de una versión muy mejorada de GPSS en 1983 llamada GPSS/H (Henriksen y Crain 1983) que fueron capaces de acortar la ejecución por un factor de cuatro o más, incluyendo el hecho de que GPSS/H fue compilado mientras que las versiones de IBM fueron interpretadas.
Inspirados por la amplia aceptación del modelado por bloques de GPSS, se desarrollaron una serie de nuevos lenguajes de proceso (finales de los 70, principios de los 80) basados en redes de bloques (nodos). Entre ellos se encontraban QGERT (Pritsker 1979) y SLAM (Pegden y Pritsker 1979). A principios de los 80 apareció el ordenador personal y SIMAN (Pegden 1982) fue uno de los primeros lenguajes de simulación que se ejecutaron en esta plataforma. SIMAN también empleaba bloques estilizados para crear un modelo de entidades que fluían a través de una red de lugares de procesamiento individuales.
Los lenguajes de modelado de procesos adoptaron generalmente el uso del calendario de eventos futuros y el calendario de eventos actuales. Sin embargo, para reducir el escaneo del calendario de eventos actuales, se añadieron eficiencias para incorporar un tiempo de reloj real en lugar de un tiempo de reloj entero, y eliminar el escaneo de entidades y eventos actuales cuyo estado no cambiará (como estar en una cola detrás de otros). Otras mejoras introducidas en la década de 1980 fueron la mejora de la generación de números aleatorios y variantes aleatorias, la reducción de la varianza, la gestión eficaz del calendario y la recopilación más eficaz de estadísticas. Pocos modeladores las conocían, ya que los lenguajes de simulación se identificaron más estrechamente con las organizaciones comerciales que los desarrollaban y mantenían y consideraban sus operaciones internas como propiedad intelectual. Esta relación de uno a uno entre lenguaje de simulación y organización comercial se mantiene en gran medida en la actualidad.
Una de las ventajas importantes de la orientación a procesos es que el modelo de proceso se define gráficamente en forma de diagrama de flujo (véase (Fishman 1973). De ahí que el usuario no tenga que ser programador para poder crear un modelo del sistema. Comparando el modelo de procesos con el enfoque por eventos, la lógica del modelo es mucho más sencilla de definir y comprender/aprender, y requiere pocos conocimientos de programación. No obstante, los lenguajes de simulación de procesos tienen limitaciones inherentes, ya que no todas las situaciones tienen un bloque correspondiente en el lenguaje. Por ejemplo, en una sala de urgencias, el paciente puede verse como una entidad que se mueve a través de los bloques de operaciones, pero hay recursos que también se mueven y que no están bien modelados por entidades. Con el tiempo, el modelador de procesos "choca contra la pared" en términos de representación y debe encontrar una representación menos aceptable en el lenguaje actual o encontrar otra forma de añadir la capacidad necesaria (normalmente mediante programación).
Otro avance conceptual que se produjo con el modelado de procesos fue la introducción de herramientas de modelado jerárquico que apoyaban la idea de bibliotecas de procesos específicas del dominio. El concepto básico es permitir al usuario definir sus propios pasos y bloques de proceso combinando pasos y bloques de proceso existentes. El sistema de modelado Arena(https://www.arenasimulation.com/), ampliamente utilizado, es un buen ejemplo de esta capacidad. En 1992, Cota y Sargent (Cota y Sargent 1992) añadieron la modularización y encapsulación de procesos, lo que dio lugar más tarde a los Gráficos de Flujo de Control Jerárquico que proporcionaban representación gráfica (y computación) de modelos de simulación (Sargent 1997). SLX (Henriksen 1995) es un ejemplo de lenguaje orientado a procesos más reciente desarrollado dentro de un marco orientado a objetos.
Modelización orientada a objetos
Otro punto de vista del modelado de procesos es que un modelo es un conjunto de procesos que interactúan o, de forma más general, objetos. Simula (Dahl y Nygaard 1966), desarrollado en la década de 1960, proporcionó una implementación temprana promoviendo la idea de objetos como elementos de la simulación y que estos objetos pueden incluir acciones descritas por la lógica que controlan este objeto y que pueden interactuar de forma sincrónica o asincrónica con otros objetos (algunas ideas evolucionaron a partir del lenguaje de inteligencia artificial Lista 2 - (véase Nygaard y Dahl 1981). Aunque se desarrolló a principios de la década de 1960 como lenguaje de simulación , apenas tuvo reconocimiento en Norteamérica y no se distribuyó ampliamente en Estados Unidos. Parte de la razón de su escasa difusión fue que se trataba de un lenguaje de programación de simulación basado en Algol, por lo que, además de ofrecer algunos conceptos de simulación muy singulares, requería un software/hardware único (para Estados Unidos). El valor de Simula, en retrospectiva, fue una importante contribución a la simulación, aunque primero fue más apreciado en la comunidad de programadores. Con el crecimiento de la simulación orientada a objetos, Simula ha sido redescubierto como precursor de muchos lenguajes de simulación actuales.
El modelado de simulación orientado a objetos se divide generalmente en dos campos. El primero, ejemplificado por Simula, es que el lenguaje de simulación debe contener conceptos orientados a objetos que permitan al modelador desarrollar programas de simulación sofisticados. En este enfoque, conceptos como tipos de datos abstractos, herencia, polimorfismo, composición, tipos parametrizados, etc. son relevantes porque permiten una amplia gama de objetos y comportamientos. Los modelos son compactos, eficientes y extensibles. En otras palabras, constituyen un mejor entorno para la programación de simulaciones. Hoy en día, los modelos suelen construirse en C++ o Java en el contexto de paquetes de simulación.
Las ideas introducidas por Simula sientan las bases de algunos avances recientes realizados por los diseñadores de lenguajes de simulación para que el enfoque orientado a objetos del modelado sea a la vez fácil de usar y flexible. Aunque estas ideas se introdujeron como conceptos de modelado de simulación, han cambiado por completo el diseño y la implementación de las herramientas de programación en general. Las ideas de Simula influyeron directamente en muchos lenguajes de programación posteriores, como Smalltalk, LISP, C++, Java y C#. Las ideas orientadas a objetos introducidas por Simula no son sólo el desarrollo más significativo en software de simulación, sino quizá el mayor avance en informática de los últimos 50 años.
Más allá de la simulación como reto de programación, el otro campo de modelado de la simulación orientada a objetos considera que la simulación orientada a objetos se compone de una amplia gama de objetos predefinidos, cada uno con un conjunto de comportamientos que se consideran relevantes para el control y el uso de los objetos. Esta orientación del modelado simplifica el proceso de creación de modelos al proporcionar un paradigma de modelado más natural y, en muchos casos, más fácil de utilizar. En un enfoque de modelado basado en objetos, creamos nuestro modelo colocando en él objetos de software que representan los componentes físicos del sistema: por ejemplo, un médico, un operario de máquina, una carretilla elevadora, una cinta transportadora, etc. Estos objetos pueden personalizarse especificando los valores de sus propiedades, como el tiempo de servicio, la velocidad de desplazamiento, etc. Por ejemplo, modelamos una fábrica colocando y describiendo mediante propiedades los trabajadores, máquinas, transportadores, robots y otros objetos que componen nuestra fábrica. Con la orientación a procesos, el modelador describe las acciones que tienen lugar en el sistema a medida que las entidades se mueven a través de los procesos. Obsérvese que, mientras que los pasos del proceso se describen con verbos (agarrar, retrasar, liberar), los objetos se describen con sustantivos (máquina, robot, trabajador). En la orientación a objetos, el modelador se limita a describir los componentes físicos del sistema y los comportamientos y acciones de estos objetos, que ya están integrados en ellos. Así, un objeto trabajador tiene comportamientos predefinidos que le permiten interactuar con las máquinas y otros trabajadores del modelo.
Resulta difícil imaginar una forma más natural de construir un modelo que utilizar una colección de componentes de modelado predefinidos que imiten los componentes del sistema real. El reto de este planteamiento es que, si queremos modelar cualquier cosa del mundo real, necesitamos una amplia biblioteca de objetos para poder capturar la enorme diversidad de objetos reales que nos podemos encontrar. Por ejemplo, no basta con tener un único objeto llamado robot, ya que en el mundo real hay muchos tipos distintos de robots. El empeño de los desarrolladores de lenguajes de simulación por crear una herramienta de simulación práctica basada en el enfoque por objetos ilustra el reto que supone disponer de flexibilidad y facilidad de uso en la misma herramienta de modelado de simulación. Aunque la flexibilidad que proporciona la orientación a procesos hace que siga siendo un enfoque ampliamente utilizado para el modelado de simulación, en los últimos 20 años se ha introducido un número creciente de productos de simulación de éxito basados en la orientación a objetos. Al igual que en los segundos 20 años se pasó de la orientación a eventos a la orientación a procesos, en los últimos 20 años se ha pasado de la orientación a procesos a la orientación a objetos. Las herramientas orientadas a objetos más recientes cuentan con un rico conjunto de bibliotecas de objetos centradas en áreas de aplicación específicas como la fabricación, la cadena de suministro y la sanidad. Algunas de estas herramientas también permiten a los usuarios crear y personalizar sus propias bibliotecas de objetos para áreas de aplicación específicas. La idea básica de poder crear objetos personalizados como concepto formal fue introducida por OleJohan Dahl y Kristen Nygaard del Norwegian Computing Center de Oslo en los años 60 en Simula y Simula 67 (Dahl et al. 1967). Simula introdujo la noción de clases de comportamiento (por ejemplo, Servidor, Trabajador, Robot), e instancias de las mismas (objetos, por ejemplo, Fred y Taladro), como parte de un paradigma de modelado explícito. Un modelador puede crear una clase de objeto, como Coche, y luego colocar múltiples instancias de esa clase en su modelo, y personalizar el comportamiento de cada instancia estableciendo valores de propiedad. También introdujeron la noción de subclase de objetos. Este potente concepto permite a un usuario crear una nueva clase de objeto a partir de una clase de objeto existente heredando, sobrescribiendo y ampliando el comportamiento de la clase de objeto. Por ejemplo, se puede crear una nueva clase de objeto denominada Camión a partir de la clase de objeto denominada Coche redefiniendo algunos comportamientos y añadiendo otros nuevos. La posibilidad de crear una nueva clase de objetos partiendo de una clase de objetos existente que tenga algunos comportamientos deseados simplifica enormemente el desarrollo de bibliotecas de objetos.
Gran parte del trabajo innovador en el diseño de lenguajes de simulación se está produciendo en las herramientas de simulación orientadas a objetos. Estas herramientas son cada vez más flexibles, pero conservan su ventaja en términos de facilidad de uso, por lo que desplazan a las herramientas orientadas a procesos. También tienen una ventaja clave en términos de animación. En el caso de las orientaciones a eventos y procesos, la adición de animación es un proceso de dos pasos, en el que el usuario primero construye el modelo lógico, y luego crea la animación como un paso separado, y luego une estos dos componentes. En la orientación a objetos, los objetos predefinidos no sólo vienen con sus propiedades, estados y comportamientos asociados, sino también con sus animaciones 3D asociadas. Esto permite al usuario construir rápidamente tanto la lógica del modelo como la animación en un solo paso.
Modelado dinámico de sistemas
La dinámica de sistemas es un enfoque de modelado desarrollado en el MIT a finales de los años 50 por Jay Forrester (Forrester 1961). Es una forma de simulación continua, en la que las variables pueden cambiar continuamente con el tiempo. A veces, la dinámica de sistemas se utiliza para aproximar sistemas discretos a gran escala (por ejemplo, modelando poblaciones). En su forma general, la dinámica de sistemas tiene un conjunto de variables de estado que están vinculadas dinámicamente a un conjunto de ecuaciones diferenciales. Sin embargo, en la mayoría de las aplicaciones, los modelos constan de "niveles" y "tasas", donde los niveles son simples variables de estado y las tasas son diferenciales de primer orden (Sterman 2000). Limitándonos a esta forma sencilla, es posible modelizar una amplia gama de problemas de sistemas dinámicos. La dinámica de los sistemas suele caracterizarse mediante diagramas de bucles causales y diagramas de acciones y flujos.
Un diagrama de bucle causal es un medio visual de mostrar la estructura y el comportamiento del sistema. Sin embargo, un modelo más detallado es su representación de existencias y flujos. Un stock puede representarse como un depósito que se llena y se vacía y mide el nivel de una variable de estado, como el número de pacientes en un servicio de urgencias o el número de personas que han estado expuestas a una enfermedad. Un flujo se representa como una válvula que controla la velocidad de cambio de una variable de estado. En este ejemplo, el flujo de pacientes que acuden a Urgencias puede estar controlado por el número de asegurados. A medida que aumenta el número de asegurados, disminuye la tasa de visitas a Urgencias. Pero todo esto puede verse mitigado por el coste, que aumenta el número de no asegurados, lo que a su vez incrementa el uso de Urgencias.
Forrester publicó el primer libro, y todavía clásico, en este campo, titulado Dinámica industrial, en 1961 (Forrester 1961). Uno de los modelos de Dinámica de Sistemas más conocidos es un modelo de crecimiento de la población mundial, que se popularizó en el exitoso libro de 1972 Los límites del crecimiento (Meadows et al. 1972). Este modelo preveía el crecimiento exponencial de la población y el capital, con recursos finitos, lo que llevaría al colapso económico en una amplia variedad de escenarios. El modelo original tenía cinco niveles que medían la población mundial, la industrialización, la contaminación, la producción de alimentos y el agotamiento de los recursos.
Aunque cualquier herramienta de simulación continua puede utilizarse para simular modelos de Dinámica de Sistemas, se han desarrollado varias herramientas de modelización específicas. Por ejemplo, (véasehttps://en.wikipedia.org/wiki/Comparison_of_system_dynamics_software). Originalmente, el principal lenguaje de simulación para dinámica de sistemas era Dynamo (ahora en desuso), pero hoy en día lenguajes como Stella(https://www.iseesystems.com/store/products/stella-architect.aspx) y Vensim(http://vensim.com/) son populares en la comunidad de dinámica de sistemas. Otros lenguajes de simulación como PowerSim(http://www.powersim.com/), y AnyLogic(http://anylogic.com/) tienen componentes de dinámica de sistemas, pero ahora ofrecen otras combinaciones con elementos de eventos y procesos. Además, aunque los modelos de dinámica de sistemas se expresan como sistemas continuos, la mayoría de las aplicaciones implican el modelado de sistemas discretos a gran escala con muchas entidades. Una alternativa a la Dinámica de Sistemas para sistemas discretos a gran escala es el modelado de agentes.
Modelado basado en agentes
El modelado basado en agentes (ABM) extiende la idea de objetos a los "agentes", cuyos atributos guardan una estrecha relación con el comportamiento humano, aunque no existe un acuerdo universal sobre su definición. Esta tendencia a tratar a los agentes como personas significa que los agentes deben tener características inteligentes y autónomas y capacidad para tomar decisiones independientes. Aunque los agentes puedan ser independientes, están situados en un entorno de otros agentes y, por tanto, existen reglas que rigen tanto la toma de decisiones individual como la interacción con otros agentes. Por lo general, la ABM tiende a aplicarse a problemas sociales que reflejan comportamientos sociales como enjambres, bandadas, seguimientos, etc. Algunos elementos de la ABM también incluyen la dinámica de sistemas.
El concepto básico del modelado basado en agentes (véase North y Macal 2007) es que un sistema se modela colocando agentes en él y dejando que el sistema evolucione a partir de la interacción de esos agentes. Cada agente es una entidad autónoma que interactúa con otras entidades del sistema. La atención se centra en modelar el comportamiento de los agentes en contraposición al comportamiento del sistema. En una orientación tradicional a procesos, las entidades siguen una secuencia de pasos de proceso, que se definen desde la perspectiva descendente del sistema. En cambio, el modelado basado en agentes define las reglas de comportamiento locales (a menudo simples) de cada entidad desde una perspectiva ascendente. El comportamiento del sistema se produce como resultado acumulativo de la interacción de los agentes entre sí. Algunos ejemplos de aplicación son las multitudes que se desplazan por una zona, los clientes que responden a la introducción de nuevos productos o las tropas en combate.
El marco de transición de estados para los agentes puede modelarse utilizando cualquier visión del mundo. El modelado basado en agentes suele implementarse utilizando una herramienta de simulación orientada a objetos. Por lo tanto, no se trata de una nueva visión del mundo de eventos discretos, sino más bien de un grupo de aplicaciones que suelen modelarse con la visión del mundo de objetos. Se utilizan clases para definir los estados y comportamientos de los agentes y se colocan instancias (a menudo un gran número) en el modelo. Los agentes (objetos) interactúan y el estado del sistema evoluciona con el tiempo. Algunas de las áreas de aplicación del modelado basado en agentes presentan algunos retos únicos, sobre todo cuando interviene un gran número de agentes (por ejemplo, el modelado de la evacuación de los aficionados de un estadio).
Para aplicaciones sencillas de modelado basado en agentes, el marco completo orientado a objetos con herencia y subclases es a veces más potente de lo necesario y un simple diagrama de estados puede ser suficiente para definir el comportamiento de la clase para cada agente. El concepto de diagrama de estados fue introducido por Shannon y Weaver (Shannon 1949) en su libro de 1949 The Mathematical Theory of Communication. Un diagrama de estados define un conjunto finito de estados en los que puede estar el agente, junto con las condiciones de transición que provocan una transición entre un par de estados. Cada diagrama suele definir el comportamiento de un objeto de una clase determinada y las transiciones de estado de las instancias de los objetos de esa clase. Aunque existen diversas variantes de diagramas de estado, todos definen los estados como nodos y los arcos como transiciones entre estados. Por ejemplo, el diagrama de estado de los agentes puede mostrar cómo se procesa una población infectada y cómo se producen los cambios de estado a lo largo del tiempo.
Debido al aumento de la capacidad de los ordenadores para gestionar un gran número de agentes, algunos modelos que antes se hacían como aproximaciones discretas utilizando un enfoque de Dinámica de Sistemas, ahora se hacen mejor utilizando un enfoque de Modelado Basado en Agentes. Esto permite una mayor flexibilidad en la lógica a costa de un mayor tiempo de ejecución. Uno de los primeros Modelos Basados en Agentes fue el Juego de la Vida desarrollado por John Conway en los años 70 (Conway 1970). El Juego de la Vida es un modelo bidimensional que implica el crecimiento celular que evoluciona utilizando un paso de tiempo fijo, donde cada célula tiene dos estados, vivo y muerto. El estado de una célula depende del estado de las vecinas del paso temporal anterior. El juego de Conway demostró el concepto básico de la aparición de complejidad a partir de reglas simples.
El interés por el modelado basado en agentes siguió creciendo y diversificándose en la década de 1990 con la aparición de diversas herramientas basadas en agentes, en particular Swarm(https://en.wikipedia.org/wiki/Swarm_(app)), NetLogo(https://ccl.northwestern.edu/netlogo/), Recursive Porous Agent Simulation Toolkit (Repast)(http://repast.sourceforge.net/repast_3/) y AnyLogic (http://anylogic.com/).
Experiencias personales en modelización
Nuestras propias experiencias con el modelado de simulación y los lenguajes de simulación abarcan desde finales de la década de 1970 hasta la actualidad. Aunque los enfoques de modelado son diferentes y se extienden desde los puntos de vista discutidos anteriormente, siguen basándose en las técnicas de eventos y procesos con intereses más recientes en métodos orientados a objetos y perspectivas multiparadigma que describimos en la siguiente sección . Presentamos observaciones para su comprensión histórica.
El desarrollo de SLAM tuvo su origen en una clase de simulación que impartió C. Dennis Pegden durante la primavera de 1978 en la Universidad de Alabama en Huntsville (UAH). Aunque Pegden había completado recientemente una clase de simulación impartida por A. Alan B. Pritsker durante sus estudios de posgrado en Purdue, su doctorado y su interés se centraban en la optimización matemática, por lo que la enseñanza de esta clase de simulación de posgrado en la UAH supuso tanto un esfuerzo como una experiencia de aprendizaje para Pegden. La clase contaba con una docena de estudiantes de posgrado a tiempo parcial, muchos de los cuales utilizaban la simulación a diario en su trabajo a tiempo completo en la NASA y varios contratistas aeroespaciales. Algunos de los estudiantes ya eran usuarios expertos de GPSS, SIMSCRIPT y otras herramientas de simulación. Dado el impresionante bagaje de los estudiantes de posgrado, Pegden decidió aprovechar la experiencia de los estudiantes mediante la enseñanza en equipo y centrarse en una comparación de los enfoques de eventos, procesos y objetos, junto con algoritmos eficientes para implementar herramientas de simulación. Durante esta clase, Pegden conoció las diferencias entre los enfoques de eventos, procesos y objetos y desarrolló la idea de fusionar un lenguaje de modelado de eventos y procesos en un único marco. Como el software GASP IV era de dominio público, Pegden utilizó GASP IV como los componentes de eventos y continuo de SLAM, y luego amplió este marco para incluir una nueva capacidad de modelado de procesos. El lenguaje SLAM se desarrolló en paralelo y como resultado directo de la enseñanza de esta clase.
En la época en que se completó SLAM, Pritsker and Associates comercializaba el producto de simulación GASP IV, desarrollado por Nicholas Hurst como tesis doctoral bajo la dirección de Alan Pritsker. Dado que SLAM ofrecía toda la funcionalidad de GASP IV, además de la capacidad añadida de modelado de procesos, suponía una clara mejora con respecto a GASP IV. En el verano de 1978, Pegden hizo un viaje a Pritsker y Asociados y presentó las ventajas de SLAM, y sugirió que Pritsker y Asociados comercializaran SLAM en lugar de GASP IV. Se llegó a un acuerdo de comercialización, junto con un acuerdo para ser coautores de un nuevo libro de texto sobre simulación con SLAM. Con el nuevo libro y el apoyo de Pritsker, SLAM se convirtió rápidamente en un éxito de mercado.
Durante los dos años siguientes, Pegden cambió su interés en la investigación de la optimización a la simulación y empezó a utilizar SLAM para modelar sistemas complejos. Rápidamente se dio cuenta de que, aunque el producto funcionaba bien para muchos problemas de los libros de texto, las limitaciones de las funciones de modelado de procesos obligaban al usuario a recurrir a la vista de eventos para la mayoría de las aplicaciones complejas del mundo real. Por tanto, el objetivo original de crear una herramienta de simulación que fuera más fácil de aprender y utilizar en aplicaciones reales no se estaba cumpliendo en muchas aplicaciones complejas, sobre todo en entornos de fabricación. Se hizo evidente que se necesitaría un lenguaje de procesos mucho más rico y capaz para cumplir este objetivo, y que se necesitaban características especiales para abordar algunas aplicaciones de fabricación. De ahí que Pegden decidiera empezar de cero y desarrollar el lenguaje SIMAN.
El desarrollo del lenguaje SIMAN comenzó en la primavera de 1981. El diseño se centró tanto en ampliar la exhaustividad de las características del proceso como en mejorar la eficacia de la ejecución. En el verano de 1981 salió al mercado el primer PC IBM, que se convirtió en la plataforma objetivo para el desarrollo de SIMAN, lo que añadió exigencias adicionales tanto a la eficiencia de la memoria como a la velocidad de ejecución. En agosto de 1981, Pegden se tomó un año sabático en Tektronix Inc. en Portland, Oregón, y se centró a tiempo completo en el desarrollo del lenguaje SIMAN. Durante este periodo, se modelaron con éxito varios procesos de fabricación utilizando versiones beta del lenguaje, lo que validó la idea de que SIMAN proporcionaba una mejora significativa en la capacidad de modelado de procesos. Durante este año sabático también se escribió un libro de texto sobre simulación con SIMAN (Pegden 1982).
En el verano de 1982, Pegden se puso en contacto con Pritsker and Associates para interesarse por la comercialización de SIMAN. Sin embargo, estaban fuertemente invertidos en SLAM y no expresaron ningún interés en el nuevo producto SIMAN. Así pues, en diciembre de 1982, Dennis y Lisa Pegden fundaron System Modeling Corporation y lanzaron el lenguaje SIMAN al mercado, con un éxito inmediato. Tres factores clave que impulsaron su crecimiento inicial en el mercado fueron: (1) la capacidad de modelado de procesos significativamente mejorada de SIMAN, (2) las características centradas en aplicaciones de fabricación y (3) la capacidad de SIMAN para ejecutarse en el nuevo IBM PC. SIMAN incorporó construcciones específicas para modelar equipos complejos de manipulación de materiales, como AGV y cintas transportadoras. SIMAN también implementó el concepto de marco experimental promovido por Zeigler (Zeigler 1984) de separar la lógica del modelo de la experimentación.
Tras la introducción de SIMAN, Systems Modeling Corporation desarrolló el sistema de animación Cinema basado en PC (1985) para proporcionar animación en tiempo real de los modelos SIMAN. Esto proporcionó un mayor realismo que los sistemas de animación basados en personajes existentes y, al ejecutarse en paralelo al modelo SIMAN, proporcionó una potente plataforma interactiva de verificación/validación de modelos. Fue un paso importante para aprovechar la potencia de la animación en la simulación. Dado que Microsoft Windows aún no estaba disponible, Cinema se desarrolló utilizando un sistema de ventanas personalizado. Como el PC estándar sólo tenía una resolución de 320 por 200, la versión inicial de Cinema requería una tarjeta gráfica y un monitor especiales de gama alta de terceros para proporcionar la resolución necesaria para producir una animación de calidad. SIMAN y Cinema se combinaron para formar el sistema de simulación Arena (1991), que se adaptó a Microsoft Windows. Arena introdujo el concepto de procesos gráficos para la construcción de modelos en lugar de declaraciones, y proporcionó una interfaz de cuadro de diálogo para introducir propiedades. También permitía realizar análisis de entrada y salida. Arena se hizo muy popular en aplicaciones comerciales y se convirtió en el producto de simulación dominante utilizado por las universidades para enseñar conceptos de simulación. La popularidad en las universidades se debió a la flexibilidad de modelado de SIMAN, la facilidad de uso de la interfaz gráfica y los populares libros de texto "Simulation with Arena" de W. David Kelton, Randall P. Sadowski, Deborah A. Sadowski y David T. Sturrock. En 2000, System Modeling Corporation fue adquirida por Rockwell, que actualmente comercializa y da soporte al producto Arena.
Aunque SIMAN supuso un paso adelante en la flexibilidad del modelado, todavía había muchas aplicaciones complejas que resultaban difíciles de modelar con la vista de procesos. Un problema que se planteaba con frecuencia era que los recursos (al igual que las entidades) en SIMAN no tenían capacidad de decisión personalizada. Aunque las entidades podían apoderarse de los recursos, éstos no tenían voz en el proceso. En algunos sistemas (por ejemplo, la sanidad) es más natural que los recursos controlen su propia lógica. Este reto de modelar sistemas que requieren una lógica de recursos compleja se convirtió en el centro del trabajo de Stephen Roberts.
Roberts fue contratado como miembro del profesorado de la Universidad de Purdue en 1973 y ocupó un puesto conjunto en el Instituto Regenstrief de Atención Sanitaria, que estaba situado dentro de las grandes clínicas de atención sanitaria general y multiespecialidad de la Facultad de Medicina de la Universidad de Indiana, situada en Indianápolis (Indiana). En un análisis de las características de funcionamiento de esas clínicas durante varios años, quedó claro que sólo la simulación permitía analizar los componentes complejos y estocásticos de esas instalaciones. En Purdue, Alan Pritsker y sus estudiantes estaban desarrollando lenguajes de simulación de redes (procesos) basados en la parte de simulación discreta de GASP IV. Aunque estos lenguajes hacían hincapié en el flujo de entidades a través de los procesos, estaba claro que en los servicios sanitarios el "flujo de pacientes y afines" era sólo una parte del entorno y el flujo de pacientes estaba muy limitado por los atareados proveedores y personal sanitario que prestaban servicios en un entorno dinámico, en contraste con las máquinas y equipos que podrían verse en una instalación de fabricación. De hecho, el flujo casi siempre estaba limitado por unos recursos humanos muy activos que decidían lo que se hacía y eso dependía de varios factores.
Así pues, a finales de los años 70 y principios de los 80, el Instituto Regenstrief desarrolló un producto de simulación llamado INSIGHT (antes INS) que incluía el flujo de entidades (entonces llamadas transacciones), pero estaba orientado en torno a las "descripciones de trabajo" realizadas por los distintos recursos "humanos" disponibles. La modelización empleaba una actividad como punto de servicio para entidades y recursos. La actividad especificaba el número, tipo y combinación de recursos necesarios y el tiempo de actividad asociado, pero las colas lógicas delante de una actividad retenían las entidades hasta que podía comenzar el servicio. Así pues, los recursos servían en las actividades, pero atendían a las entidades en las colas. Las entidades no se trasladaban a una actividad, sino que esperaban a que los recursos las trasladaran. Los recursos se identificaban individualmente y, opcionalmente, por tipo. Cada recurso se asociaba a un nodo primario en un árbol de decisión de recursos. Se pueden definir varios árboles de decisión de recursos. Ese nodo primario podía referirse a las colas dentro del modelo y/o con otros nodos primarios. Estos nodos primarios expresaban el método de evaluación de las colas asociadas y otros nodos por criterios de búsqueda. Por ejemplo, el nodo de decisión primario de una enfermera podría ser atender primero la cola de pacientes en salas de examen que necesitan un servicio de enfermería, luego atender la cola de pacientes que esperan ser ubicados en una sala de examen y que se les tomen los signos vitales, luego ejecutar otro nodo de decisión primario que dice ayudar en el registro o en la salida dependiendo del tiempo de espera de las personas. Este proceso de decisión podría formar parte de otro proceso de decisión o ser exclusivo de un recurso.
En cualquier caso, el proceso de decisión del recurso era dinámico y dependía fundamentalmente del estado del sistema. Lo que hacía funcionar el proceso de decisión era el algoritmo de actualización del estado utilizado por el lenguaje de simulación. Dado que los eventos de fin de actividad dominaban el resto de eventos, su actualización era fundamental para el modelado y se denominaba proceso en dos etapas. Cuando finalizaba una actividad, los recursos pasaban a un estado de espera temporal denominado almacenamiento intermedio. En ese momento, la Fase 1 enviaba a la entidad a la red hasta que su progreso se detenía por la necesidad de adquirir recursos, iniciar una actividad o marcharse. Una vez completada la etapa 1, se invocaba la etapa 2, en la que cada recurso en almacenamiento intermedio utilizaba su árbol de decisión para determinar qué debía hacer a continuación. O bien se ocupaba en otra actividad o se quedaba inactivo. Había especificaciones que permitían a las entidades identificar y reclamar recursos del almacenamiento intermedio y permitir que la actualización de un recurso hiciera que las entidades iniciaran actividades. Cabe señalar que las entidades podían sufrir retrasos debido a requisitos de sincronización como la recogida o el movimiento a distancia. Además, las prioridades entre los recursos para su uso en las actividades podrían producir el tanteo o la reanudación de las actividades.
El desarrollo del lenguaje de simulación INSIGHT continuó durante la década de 1980 y se describió en tutoriales en el WSC. Nunca alcanzó el éxito comercial y el Instituto Regenstrief suspendió su desarrollo cuando Roberts se marchó a la Universidad Estatal de Carolina del Norte en 1990. En la década de 1990 Roberts, junto con Jeff Joines principalmente, desarrolló un lenguaje de simulación orientado a objetos C++ cuyas características de simulación de procesos se parecían a INSIGHT. Gracias al polimorfismo de los objetos, esta simulación podía emplear "equipos", así como recursos individuales y de tipo en un proceso de decisión ampliado. Además, el desarrollo mostró cómo un lenguaje como INSIGHT podía ampliarse y extenderse con verdaderas características orientadas a objetos. Sin embargo, su uso requería una gran experiencia en programación C++, por lo que su aceptación fue muy limitada y su desarrollo se abandonó en menos de una década. Aunque INSIGHT nunca alcanzó el éxito comercial, puso de relieve la importancia de ampliar la flexibilidad del modelado más allá de los simples flujos de entidades para soportar también el modelado de la lógica de recursos complejos.
Tras un par de años alejado del mundo de la simulación, Pegden fue invitado a pronunciar la conferencia Titán en la Winter Simulation Conference de 2005 sobre el futuro de la simulación. Esta charla fue el impulso para dedicar tiempo a reflexionar sobre el estado de la simulación y lo que podría hacerse para mejorar las herramientas existentes. Esto llevó a Pegden a desarrollar el concepto de modificar los conceptos básicos de orientación a objetos para sustituir los métodos codificados por procesos, manteniendo la noción básica de clases, subclases, herencia, polimorfismo, anulación, etc. La motivación de esta idea era aportar las ventajas del enfoque orientado a objetos mediante procesos gráficos, evitando así la necesidad de conocimientos complejos de programación.
Pegden utilizó estos conceptos desarrollados para la charla Titan para crear el software de simulación Simio, que se introdujo en el mercado en 2008. Con Simio resultó mucho más fácil para los usuarios ampliar y crear bibliotecas de objetos sin necesidad de codificar en un lenguaje orientado a objetos como C++ o Java. Simio también amplió la idea de recurso inteligente introducida por INSIGHT. En Simio, los recursos (y las entidades) también son objetos que pueden responder a peticiones utilizando su propia lógica de proceso personalizada. Esto facilita enormemente el modelado de situaciones en las que la entidad o el recurso controla su propio comportamiento.
Otro avance clave de Simio fue la noción de utilizar procesos complementarios para los objetos con el fin de modificar su comportamiento instancia por instancia, sin modificar la definición del objeto. Antes de la introducción de este concepto en Simio, el método principal para añadir lógica personalizada a una instancia de objeto consistía en añadir al objeto eventos codificados de forma personalizada. Los procesos añadidos supusieron un gran avance porque son más fáciles de usar y más potentes. La potencia añadida procede de la lógica de procesos, que puede representar actividades que abarcan todo el tiempo, mientras que un evento codificado se limita a un instante en el tiempo.
La evolución de SLAM - SIMAN - Arena - Simio se ha producido a lo largo de un periodo de casi 40 años. Durante este periodo, el paradigma principal de modelización ha pasado de los eventos a los procesos y a los objetos. Con SLAM, el enfoque de modelado primario eran los eventos, con procesos utilizados cuando era posible. Con SIMAN, el enfoque de modelado primario fueron los procesos, con eventos utilizados cuando era necesario. Con Cinema/Arena, la animación se convirtió en una parte central del proceso de modelado y verificación/validación. Con Simio, el enfoque de modelado principal se basa en objetos y se utilizan procesos cuando es necesario. Esta evolución ha facilitado el uso de la simulación sin comprometer la flexibilidad del modelado.
Modelado multiparadigma
Los primeros enfoques de modelado de simulación eran reflejos de un único paradigma de simulación, a saber, evento, actividad, proceso y objeto. En la década de 1970 surgió una visión de modelado de paradigma "combinado" que permitía al usuario seleccionar el enfoque de modelado que mejor se ajustara al problema o combinar enfoques de modelado según lo dictara la situación. GASP IV (Pritsker 1974) popularizó la idea de combinar marcos discretos y continuos en el mismo modelo, aunque hubo esfuerzos anteriores de otros (véase, por ejemplo, Tocher y Splaine 1966). Este marco permitía tanto el modelado de eventos discretos como el modelado continuo dentro del mismo modelo de simulación. Proporcionaba tanto eventos de tiempo como de estado, de modo que los eventos discretos podían afectar a las variables continuas y los eventos de tiempo podían afectar a las variables discretas. SLAM (Pegden y Pritsker 1979) avanzó la combinación para incluir el modelado de procesos y fue una de las primeras herramientas ampliamente utilizadas para promover la idea de mezclar enfoques de modelado alternativos (procesos y eventos y continuo) en el mismo modelo. En el caso de SLAM, el modelado de procesos/continuo se utilizó para el modelado básico, y los eventos se utilizaron como "puerta trasera" para proporcionar una flexibilidad añadida.
La idea de utilizar la simulación en combinación con otras herramientas analíticas se empleó de manera informal al principio de la historia de la simulación. En 1983, Shanthikumar y Sargent (1983) ofrecieron una definición unificadora de los modelos híbridos de simulación/analítica. Presentaron cuatro clases de modelos híbridos que representan las formas en que la simulación y los modelos analíticos pueden interactuar. Swinerd y McNaught (2012) utilizaron recientemente una combinación de una simulación basada en agentes con un modelo analítico para crear un caso de simulación híbrida.
Las herramientas modernas de simulación orientada a objetos también emplean un enfoque multiparadigma. Estas herramientas combinan la facilidad y rapidez de modelado que proporcionan los objetos con la flexibilidad añadida por la incorporación de eventos y/o procesos especificados por el usuario. Por ejemplo, un objeto que representa un servidor puede tener puntos seleccionados en la lógica del objeto donde el usuario puede insertar su propia lógica de eventos o de procesos. La lógica de eventos suele incorporarse a los objetos utilizando un lenguaje de programación como Java o C++, o un lenguaje de scripting especial que puede utilizarse en lugar de código. Sin embargo, en ambos casos la lógica de eventos tiene una restricción importante: el tiempo simulado no puede avanzar dentro del evento. Esto restringe considerablemente el tipo de lógica que puede insertarse en una instancia de objeto. Por ejemplo, no es posible esperar a que un trabajador esté disponible dentro de un evento, ya que esto requeriría que el tiempo avanzara. Simio(https://www.simio.com/index.php) introdujo un enfoque mucho más potente que permite a los usuarios combinar objetos con procesos. Dado que los procesos pueden extenderse en el tiempo, permiten al usuario ampliar considerablemente el comportamiento de sus objetos. Así, los procesos pueden incrustarse en un objeto para esperar un tiempo determinado o una condición específica (por ejemplo, que Fred esté disponible). Este enfoque combina toda la potencia y flexibilidad de los procesos con la facilidad y rapidez de modelado de los objetos.
AnyLogic(http://anylogic.com/) ha combinado el modelado basado en agentes, la dinámica de sistemas y el modelado de eventos discretos en una sola herramienta. Un único modelo AnyLogic puede combinar los tres enfoques de modelado para representar el comportamiento del sistema.
También, complementando el interés en el multiparadigma hay un interés en unificar el modelado de simulación dentro de un marco específico o teoría de simulación. En 1981 Nance (Nance 1981) describió los papeles fundamentales del tiempo y el estado en simulaciones de eventos discretos que eventualmente condujeron a la Metodología Cónica (Overstreet y Nance 1985) que proporciona un marco para encapsular los puntos de vista básicos de modelado de evento, actividad y proceso.
La teoría de simulación más conocida ha sido el formalismo propuesto por Zeigler en 1984 (Zeigler 1984), ahora conocido como DEVS (Discrete Event System Specification). A lo largo de los años esa teoría ha sido desarrollada y aplicada a numerosos casos (ver (Zeigler y Muzy 2017). DEVS es una teoría formal de sistemas compuesta por entradas, estados y salidas en combinación con funciones de avance temporal para modelar componentes de sistemas discretos y continuos (potencialmente jerárquicos). La abstracción proporciona un marco que separa el modelado y la ejecución de la simulación para destacar, por ejemplo, el ordenamiento y la ejecución potencialmente paralela de los eventos. El formalismo DEVS ha suscitado interés en todo el mundo y su formulación ha acogido diversas ampliaciones e interpretaciones.
Adoptando un enfoque de teoría de grafos, Schruben y Yucesan (Schruben y Yücesan 1993) muestran que puede utilizarse una visión de grafos de sucesos de la simulación de sucesos discretos para crear un entorno completo y coherente de desarrollo de modelos (resolución de problemas). Un modelo de grafo de sucesos no sólo es visualmente atractivo, sino que proporciona un marco riguroso para la construcción de modelos (Savage et al. 2005).
Modelado con animación
Durante los primeros 30 años de simulación, los resultados se presentaban en forma de informes textuales. Aunque la animación visual de la ejecución de la simulación ya se preveía en 1970 (Reitman et al. 1970), la animación se integró en la simulación comercial en la década de 1980. Hubo un importante debate sobre los méritos de la animación. Muchos pensaban que la animación era un adorno que no influía realmente en el éxito de un proyecto de simulación. Sin embargo, en la actualidad se considera un componente esencial para el éxito de los proyectos de simulación y desempeña un papel clave en la expansión de las aplicaciones de simulación en la empresa. Una de las principales ventajas de la animación es su capacidad para comunicar el comportamiento del modelo a todas las partes interesadas. Todos, desde la planta de producción hasta la planta superior, pueden ver el comportamiento incorporado en el modelo. La animación aclara los supuestos de modelización y es una potente herramienta tanto para la verificación como para la validación del modelo.
Antes de la animación, los responsables de la toma de decisiones tenían que confiar en que el modelo reprodujera fielmente el comportamiento del sistema real con el nivel de detalle adecuado. A menudo podía haber fallos en la lógica del modelo, pero no había una forma sencilla y visual de detectar errores en la lógica. Con la animación, el modelo cobra vida y el comportamiento es claramente visible. La animación combinada con depuradores interactivos ha mejorado radicalmente la capacidad de encontrar y corregir errores lógicos en un modelo. La animación no sólo ayuda a los modeladores a encontrar y corregir errores desatendidos en la lógica, sino que también ayuda a comunicar las hipótesis simplificadoras planificadas que forman parte de cualquier modelo. La animación es un componente esencial para establecer la confianza en los resultados del modelo.
Uno de los primeros sistemas de animación de simulaciones fue un producto llamado See Why, desarrollado a finales de los 80, que utilizaba una animación rudimentaria basada en personajes. El software de simulación Witness(https://www.lanner.com/technology/witness-simulation-software.html) se desarrolló a partir de See Why. El sistema de animación Cinema era un sistema de animación 2D basado en vectores desarrollado en la misma época y era un sistema de animación en tiempo real para modelos SIMAN. El sistema de animación Cinema y el sistema de modelado SIMAN se integraron posteriormente en una única plataforma para crear el producto Arena, ampliamente utilizado. Otro de los primeros sistemas de animación 2D fue Proof(http://www.wolverinesoftware.com/ProofProducts.htm), desarrollado por Jimes O. Henriksen de Wolverine Software en 1989.
En los años 90 empezaron a surgir las capacidades de animación 3D. Algunos de los primeros sistemas fueron AutoMod (centrado en sistemas de manipulación de materiales) (http://www.appliedmaterials.com/global-services/automationsoftware/automod), Taylor ED (precursor de FlexSim(https://www.flexsim.com/)) y Simple++ (precursor de PlantSim (https://www.plm.automation.siemens.com/)). El debate sobre la animación también se ha extendido a la necesidad de disponer de animación 3D de alta fidelidad frente a la animación 2D. Algunos sostienen que la animación 2D es adecuada para obtener la mayoría de los beneficios de la animación, y que el esfuerzo adicional que requiere la 3D aporta rendimientos decrecientes. Aunque una animación 3D de mayor calidad no cambia el modelo subyacente ni los resultados en comparación con una animación 2D, el mayor realismo puede ayudar a comunicar los resultados del modelo. Además, con las mejoras en la animación 3D y la amplia disponibilidad de símbolos 3D ya no hay un precio significativo en tiempo o esfuerzo para crear la animación 3D. Así, la mayoría de las herramientas de simulación modernas ofrecen un entorno de animación 3D.
La combinación de un marco de trabajo orientado a objetos, un entorno de modelado 3D inmersivo y funciones de dibujo 3D mejoradas ha demostrado ser una combinación muy potente para introducir la animación 3D en la corriente principal del modelado de simulación. En la actualidad, la mayoría de las herramientas de simulación modernas ofrecen 3D de forma estándar.
La próxima ola de animación para simulación es el desarrollo de entornos de realidad virtual (RV) para mostrar animaciones de simulación. Esto permite al espectador sumergirse en el modelo y caminar por el sistema en un entorno de RV que imita el sistema real y tal vez interactuar con la simulación moviendo objetos, redirigiendo el tráfico o alterando la actividad de simulación. Varios sistemas de simulación (por ejemplo, Simio, FlexSim, Emulate3D(https://www.demo3d.com/) ya admiten entornos de RV para ver animaciones. Permitir que el usuario interfiera en la animación es el siguiente paso en el desarrollo de la visualización de RV.
El impacto empresarial
Comentario
La historia de la simulación está repleta de lenguajes y paquetes de simulación, cada uno de ellos con componentes de modelado únicos. Muchos se han perdido en el mercado de la popularidad debido a su incapacidad para captar al público de la simulación. A diferencia de la simulación continua, que se basa en la solución de ecuaciones diferenciales, las simulaciones discretas carecen de una teoría fundacional común y aceptada. Por ello, el modelado de simulaciones se sitúa a menudo en el ámbito del "arte". En la práctica, el arte de la simulación requiere un conocimiento bastante completo de lo que puede simular la herramienta utilizada, más que un enfoque desenfrenado del problema que se quiere resolver. En consecuencia, las simulaciones de éxito suelen ser el producto de algún interés comercial respaldado por una abundante documentación y herramientas de aprendizaje, todo ello dentro del marco que promueve las ventajas de la herramienta.
Se reconoce ampliamente que la traducción de un problema en una simulación es una amalgama de los objetivos de rendimiento de los sistemas, los datos de entrada disponibles y las habilidades de modelado del modelador. Existen varias formas de tratar los datos de entrada disponibles y las diversas medidas de rendimiento (véase Banks et al., 2010; Law, 2015). La conceptualización de modelos se ha basado generalmente en representaciones gráficas (diagramas de bloques, diagramas de flujo, diagramas de ciclos de actividad, etc.) que suelen asociarse a lenguajes de simulación específicos, y se ha producido un debate sistemático limitado sobre los enfoques generales. Robinson (Robinson 2008a, b) presenta un marco de modelado conceptual en dos partes. El significado y los requisitos del modelo conceptual incluyen: validez, credibilidad, utilidad y viabilidad. Se considera que la actividad de modelización propiamente dicha consiste en: comprender la situación del problema, determinar la modelización y los objetivos generales del proyecto, identificar el resultado del modelo, identificar las entradas del modelo y determinar el contenido del modelo. Todo ello proporciona un marco para la conceptualización, pero aún no da lugar a un modelo computacional. La implementación del modelo conceptual aún debe realizarse mediante un lenguaje de simulación o un paquete de simulación accesible al modelador de simulación.
El papel del lenguaje de simulación en el modelado de simulación sigue estando entrelazado. Los esfuerzos por hacer el modelado más transparente y visible mediante técnicas gráficas y a través del lenguaje natural ofrecen un potencial considerable para el modelado de simulación. No obstante, la tecnología de simulación debe interconectarse con el almacenamiento y el análisis de grandes volúmenes de datos para hacer realidad su mayor potencial a medida que avanza la tecnología informática.