Simulacion Arena111

PROYECTO FIN DE CARRERA Sistemas con Logstica de Retorno: Aplicacin al caso de contenedores retornables
5. SIMULACIN DEL MODELO CON ARENA
Qu es Simulacin?
Simulacin es el proceso de disear un modelo de un sistema real y llevar a cabo experiencias con el mismo con la finalidad sea de aprehender el comportamiento del sistema o de evaluar diversas estrategias (dentro de los lmites impuestos por un criterio o un conjunto de ellos) para entender el funcionamiento del sistema. Robert
Shannon, 1975. La capacidad del ser humano, sobre otros animales, de poder abstraer los aspectos principales de una realidad y sus interrelaciones, pudiendo crear modelos reales o imaginarios que representen esa realidad, le proporciona la herramienta necesaria para la comprensin del mundo que le rodea, ejercitndose con parcelas reducidas y evolucionando progresivamente a una visin unificada de sistemas cada vez ms complejos. La simulacin, haciendo uso de esta capacidad, es el diseo de un modelo a partir de un sistema real que permite experimentar sobre dicho modelo para describir, explicar y predecir el comportamiento del sistema real. En la mayora de los casos, las interrelaciones que componen el sistema sern lo suficientemente complicadas y complejas como para hacer inviable la obtencin de soluciones analticas exactas con mtodos matemticos. Es pues la simulacin una buena herramienta para el estudio de estos sistemas. No se aspira a encontrar soluciones analticas y exactas del problema, sino a la mejor comprensin de los sistemas en estudio. La Simulacin con ordenador se refiere a una serie de mtodos para estudiar una amplia variedad de modelos de sistemas del mundo real mediante evaluacin numrica, usando un software apropiado, diseado para imitar las operaciones o caractersticas del sistema, frecuentemente con respecto al tiempo. Desde un punto de vista prctico, la simulacin es el proceso de diseo y creacin de un modelo por ordenador a partir de un
Pgina 73
sistema real o propuesto, con el fin de dirigir experimentos numricos para comprender mejor el comportamiento de dicho sistema segn un conjunto de condiciones dado. Aunque puede ser utilizado para estudiar sistemas simples, el poder real de esta tcnica se consigue completamente cuando se usa para estudiar sistemas complejos. Puede que la simulacin no sea la nica herramienta para estudiar un modelo pero es con frecuencia el mtodo elegido. La razn para esto es que la simulacin permite un modelo lo bastante complejo, si es necesario, para representar el sistema fielmente y adems analizarlo. Otros mtodos pueden requerir hiptesis de simplificacin ms fuertes sobre el sistema para poder permitir su anlisis, lo cual podra cuestionar la validez del modelo. Desarrollo de la Simulacin Cuando las capacidades y la sofisticacin de los lenguajes y paquetes de simulacin empezaron a aumentar drsticamente sobre los aos 40, el concepto de cmo y cundo usar simulacin cambi. Al principio, sobre finales de los aos 50 y la dcada de los 60, la simulacin era una herramienta cara y especializada que era usada generalmente slo por grandes corporaciones que requeran grandes inversiones de capital (corporaciones del acero y aeroespaciales). El uso de la simulacin tal como se conoce hoy en da empez sobre los aos 70 y principios de los 80. Los ordenadores comenzaron a ser ms rpidos y baratos y el valor de la simulacin empez a ser descubierto por otras industrias, aunque la mayora de las compaas eran an bastante grandes. Sin embargo, la simulacin se convirti en la herramienta elegida por muchas compaas, sobre todo industria pesada y automocin, para determinar por qu ocurran los desastres y, en algunas ocasiones, para saber dnde encontrar la causa del fallo. Durante los 80 la simulacin empez a establecer sus races en los negocios debido en gran parte a la introduccin del ordenador personal y la animacin. Aunque an se usaba para analizar los fallos de los sistemas, mucha gente solicitaba la simulacin antes
Pgina 74
de que la produccin empezara. A finales de los 80, la utilidad de la simulacin fue reconocida por muchas grandes firmas, varias de las cuales realmente hicieron de la simulacin un requerimiento antes de la aprobacin de cualquier inversin importante de capital. Sin embargo, la simulacin no estaba an lo bastante extendida y rara vez era usada por pequeas firmas. La simulacin realmente empez a madurar sobre los 90. Muchas empresas pequeas incorporaron esta herramienta. Una mejor animacin, fcil de usar, ordenadores ms rpidos, fcil integracin con otros paquetes y la aparicin de simuladores han ayudado a que la simulacin se convierta en una herramienta estndar en muchas compaas. La manera en que la simulacin se est usando tambin est cambiando, ahora se usa con antelacin, en la fase de diseo y, frecuentemente, actualiza los cambios que deben ser realizados en los sistemas de operaciones. Esto proporciona un modelo de simulacin que permite ser usado para el anlisis de sistemas en muy corto plazo. La simulacin tambin ha invadido el servicio de la industria, donde est siendo aplicada en muchas reas no tradicionales. Los mayores impedimentos a los que se enfrenta la simulacin desde que se ha convertido en una herramienta bien utilizada y universalmente aceptada son el tiempo necesario para llevar a cabo el desarrollo del modelo y los conocimientos y habilidades de modelado requeridos para ser capaz de desarrollar una simulacin con xito. No obstante, la velocidad de cambio en la simulacin se ha acelerado en los ltimos aos y hay razones para pensar que seguir este rpido crecimiento en un futuro prximo. Aplicaciones de la Simulacin Como ya se ha visto, la llegada del ordenador y su aplicacin en simulacin ha hecho posible el desarrollo de un gran nmero de tcnicas y su aplicacin en muy diversos campos: Sistemas de produccin: planificacin, control de inventarios, lneas de productos, programacin.
Pgina 75
Sistemas de servicios: admisin de hospitales, operaciones en ventanillas de bancos, grandes superficies, restaurantes de comida rpida. Sistemas de distribucin: almacenes, red de distribucin. Sistemas informticos: redes de comunicacin, ordenadores, software y hardware, protocolos. Sistemas econmicos y financieros. Otros: teora de juegos, situaciones de emergencias por catstrofes, etc.
La aplicacin de la simulacin a sistemas tan diversos persigue unos objetivos que se pueden recoger en la siguiente clasificacin:
Anlisis de sistemas ya existentes, para su mejor comprensin y optimizado de los

mismos y la evaluacin de distintas estrategias ante un mismo problema en el sistema. El esquema en este tipo de simulacin sera:
Figura 5.1: Simulacin para el anlisis de sistemas ya existentes.
Como etapa previa al diseo de nuevos sistemas, intentando minimizar los aspectos negativos del modelo y su adecuacin al proyecto. El esquema sera el siguiente:
Pgina 76
Figura 5.2: Simulacin del diseo de nuevos sistemas.
Con fines de educacin o adiestramiento, para obtener experiencia en la toma de decisiones o adquirir ciertas rutinas o hbitos. Sistemas y Modelos en Simulacin La Simulacin, como la mayora de los mtodos de anlisis, implica el uso de sistemas y modelos. Un sistema se define por el conjunto de componentes o entidades que lo forman y las relaciones que existen entre sus componentes. Cada entidad o componente tiene sus caractersticas propias, definidas por un conjunto de variables. El entorno o medio ambiente define el resto de componentes que no forman parte del sistema pero que pueden influir en el mismo. El estado del sistema se define por el conjunto de valores que toman cada una de las variables que caracterizan a cada componente del sistema. Hay dos tipos de sistemas, discretos y continuos segn sea el valor de dichas variables: En los sistemas discretos el valor de las variables cambia en instantes determinados y separados en el tiempo, como por ejemplo, el nmero de coches en un tramo de calle cambia slo cuando entra o sale un nuevo coche.
Pgina 77
En los continuos, el valor de las variables que definen el estado del sistema cambia continuamente con respecto al tiempo, como por ejemplo, la velocidad de un coche en el proceso de incorporacin al trfico. Como se puede observar, un sistema casi nunca es completamente discreto o completamente continuo. Pero al clasificarlo como discreto, por ejemplo, se denota que en el cambio de valor en las variables predomina el discreto frente al posible cambio continuo de esa u otras variables del sistema. Por tanto, un sistema se puede entender como un proceso, real o planeado, que normalmente se estudia para medir su rendimiento, mejorar sus operaciones o disear si puede o no existir. Los representantes o controladores de un sistema pueden tener tambin una ayuda disponible para operaciones del da a da (como decidir qu hacer en una fbrica si una mquina importante se estropea). Dado un sistema para su estudio, se podr experimentar sobre el propio sistema, si este es accesible y los experimentos son no destructivos. Sin embargo, si este sistema real aun no existe fsicamente o no es accesible por otras razones, se necesitar recurrir a la realizacin de un modelo sobre el que experimentar para estudiar el sistema. Estos modelos que representan al sistema pueden asemejarse fsicamente ms o menos al sistema dado, dependiendo del grado de abstraccin que se realice. En funcin de esta abstraccin se tendrn: Modelos fsicos o icnicos: representan fsicamente al modelo real pero a distintas escalas, como el caso de reactores qumicos o tneles de aire. Modelos matemticos o lgicos: representan al sistema por medio de smbolos matemticos y diagramas de flujos. La experimentacin que se realice sobre el modelo para responder a las cuestiones planteadas sobre el sistema, depender de la complejidad de dicho modelo. Si el modelo es lo suficientemente simple como para admitir trabajar con relaciones matemticas cuantitativas, se obtendrn soluciones analticas y exactas para el sistema. Sin embargo, si no es posible un tratamiento de este tipo debido a la complejidad del modelo, ser necesario recurrir a la simulacin para poder estudiar el sistema.
Pgina 78
Definidos los modelos lgicos de simulacin, se pueden clasificar en tres direcciones principales: Estticos / Dinmicos: En los modelos estticos se representa el sistema en un instante concreto de tiempo (ejemplo: localizacin de almacenes en una regin). En los modelos dinmicos las variables del modelo evolucionan con el tiempo, como en los modelos de colas. Deterministas / Estocsticos: Aquellos modelos en los que todas las variables de entrada no puedan tomar valores aleatorios son deterministas, como por ejemplo los sistemas definidos por ecuaciones diferenciales. Los modelos en los cuales algunas de sus variables de entrada puedan tomar valores aleatorios sern modelos estocsticos. Esta aleatoriedad en los valores de entrada al sistema producir una aleatoriedad tambin en los valores de salida. Continuos / Discretos: Depende de los valores que pueda tomar el tiempo en la simulacin. El tiempo de simulacin es una variable continua en los modelos continuos, como pasa con los procesos qumicos, pudindose integrar con respecto al tiempo. Mientras que en los discretos, el tiempo de simulacin est definido para instantes concretos. Para la situacin que se pretende simular y teniendo en consideracin las definiciones anteriores, se tendr un modelo dinmico, estocstico y discreto. Ventajas e inconvenientes de la Simulacin Las ventajas ms importantes que podemos encontrar en la simulacin son las que se describen a continuacin: Experimentacin sobre el modelo, menos costosa que sobre el sistema. Compresin del tiempo, es decir, operaciones que ocurren en horas o das pueden simularse en segundos. Igualmente es posible el efecto contrario, estiramiento del tiempo. Ambiente controlado y posibilidad de modificacin. Los experimentos pueden ser mejor definidos y especficos que los realizados sobre el sistema real.
Pgina 79
Mayor y mejor comprensin de la realidad. Alternativa para el diseo de nuevos sistemas y su evaluacin. Estimacin de rendimientos de sistemas reales en diversas condiciones y situaciones, permiten comprobar la eficacia de los sistemas reales. Del mismo modo, tambin podemos encontrar algunos inconvenientes a la hora de elegir la simulacin como herramienta de trabajo para nuestro estudio: Aproximada e imprecisa, se trabaja sobre un modelo de la realidad, donde se desprecian y simplifican los componentes y sus relaciones. Necesaria una validacin del modelo, a travs de experimentos. Con una simulacin se pueden obtener gran cantidad de resultados, incluso una animacin del modelo ayuda a un mayor impacto de confianza en los resultados del modelo, que pueden estar respaldados slo por una deficiente validacin del mismo, llevando a conclusiones errneas. Precisin y simplicidad del modelo son objetivos contrapuestos. A mayor precisin se necesitar un modelo ms complejo en la mayora de los casos. La simulacin es un proceso costoso: el tiempo empleado, el software utilizado, es necesaria una experiencia en el modelado de sistemas. Etapas del proceso de Simulacin En la realizacin de un proyecto de simulacin se pueden definir una serie de etapas que faciliten y aumenten las posibilidades de xito del mismo. Sin embargo, el uso de nuevas herramientas de programacin ms potentes han facilitado algunas de ellas, e incluso su agrupacin en una sola. Estas etapas en las que se puede dividir un proceso de simulacin son: 1.- Formulacin del problema. Definicin detallada de los objetivos, de las restricciones e hiptesis de trabajo y de las variables que se van a utilizar para definir el estado del sistema y el control del mismo. Ser necesario definir tambin el grado de precisin requerido. La elaboracin de un modelo preliminar puede ayudar a poner de manifiesto de forma ms clara y precisa los
Pgina 80
objetivos del estudio, las variables y parmetros necesarios para el desarrollo del modelo y para el control del mismo. 2.- Formulacin del modelo. Elaboracin del modelo matemtico a utilizar, mediante tcnicas o herramientas especficas del modelado: Grafo de eventos y Diagrama de Ciclos de Actividades. La formulacin hecha debe ser simple, flexible, efectiva y eficiente, pudindose adaptar a cambios durante el proyecto de simulacin y el tiempo de computacin sea razonable. 3.- Anlisis y recogida de datos. Se suele realizar en paralelo con el punto anterior, ya que un buen modelo es fruto del conocimiento del sistema a modelar y de los datos experimentales procedentes de la observacin de las entradas y salidas del mismo. Los datos empricos obtenidos requieren un proceso de filtrado por parte del analista de forma que elimine interferencias debidas al propio proceso de recogida o agentes no presentes en el modelo. 4.- Codificacin. Consiste en trasladar el modelo a un lenguaje de programacin para introducirlo en el ordenador. Se pueden utilizar lenguajes de propsito general o bien lenguajes orientados a la simulacin. 5.- Verificacin y validacin. La verificacin es el proceso de revisin del programa para comprobar que ste representa fielmente el modelo que hemos implementado. Se utilizan distintas tcnicas como: verificacin manual de lgica, test modular, test de soluciones conocidas, anlisis de sensibilidad, test de estrs, animacin grfica. La validacin asegura la correcta representacin de la realidad por parte del modelo. Al realizar el modelo se suelen emplear una serie de hiptesis simplificativas como son: Se ignora el exterior. Aproximacin de funciones no lineales. Aproximacin de distribuciones empricas. Independencia entre los componentes.
Pgina 81
Agregacin de componentes. Estacionalidad. Existen varias tcnicas de validacin de modelos realizados mediante simulacin. De stas, las dos ms utilizadas son:
Experimentos de campo: a partir de unos datos de entrada y salida obtenidos del

sistema real, y se comparan con los datos de salida obtenidos del modelo para los mismos datos de entrada.
Test de Turing: a personas con experiencia sobre el sistema real modelado, se le

aportan los resultados obtenidos a travs de la simulacin y otros inventados, para ver si son reconocidos. 6.- Diseo de experimentos. A la hora de realizar experimentos con el modelo hay que tomar decisiones referentes a algunos aspectos relacionados con: Las condiciones iniciales que existan: es necesario fijar las condiciones de partida que cada iteracin realice y su posible influencia en los resultados. Las iteraciones necesarias para obtener las precisiones definidas, ya que se obtienen datos de tipo estadstico. Consideraciones realizadas respecto al valor escogido para los parmetros utilizados y la relacin entre estos. 7.- Experimentacin y anlisis de los resultados. Se puede diferenciar entre sistemas que terminan y sistemas que alcanzan un estado estable en el tiempo. Los sistemas que terminan son aquellos que representan procesos que tienen lugar en un periodo de tiempo determinado, acabado ste, termina el proceso. La experimentacin se realiza por lotes de experimentos que se consideran independientes entre s. Normalmente el tiempo de ejecucin de estos modelos es pequeo. Sin embargo, en sistemas que alcanzan un estado estable en el tiempo, lo que interesa es definir a qu estado estable tienden, y estudiar los valores de las variables en este estado. La experimentacin se realiza a travs de largas ejecuciones del modelo,
Pgina 82
divididas en trozos respecto al tiempo tal que estos puedan ser considerados como procedentes de experimentos independientes entre si. 8.- Documentacin. Elaboracin de un documento que refleje los resultados obtenidos y cmo se ha ido realizando el proceso de simulacin: variaciones introducidas en el modelo, datos de entrada, etc. 9.- Presentacin de resultados. Una adecuada eleccin de la presentacin de resultados puede dar lugar a una mayor confianza en el modelo realizado por arte de personas ajenas al modelo y por tanto en las conclusiones obtenidas. Lenguajes de simulacin Para llevar a cabo la ejecucin de una simulacin en el ordenador, se debe elegir el lenguaje donde programar el modelo creado. Bien un lenguaje de propsito general como puede ser C, BASIC, FORTRAN o bien lenguajes especficos de simulacin La utilizacin de lenguajes de propsito general permite una mayor flexibilidad que ciertos lenguajes especficos de simulacin. Estos lenguajes de propsito general, de menor costo, crean un eficiente cdigo del modelo que requiere de un tiempo de ejecucin muy inferior al de lenguajes especficos de simulacin. Sin embargo, la construccin del modelo es ms tediosa y con mayor probabilidad de errores al tener que trabajar en niveles de programacin demasiado bajos. Los lenguajes de simulacin permitirn un menor tiempo de codificacin, al proveer de elementos orientados a la simulacin. An as, el tiempo de ejecucin ser mayor. Tambin proveen de buenas herramientas de deteccin de errores de forma automtica, haciendo ms fcil y segura la escritura del cdigo. Su flexibilidad, sin embargo, es mucho mayor que en un lenguaje de propsito general, al igual que el coste del software, al trabajar a un ms alto nivel en programacin. Algunos de estos lenguajes son:
Pgina 83
GPSS (General Purpose Simulation System), desarrollado por Geoffrey Gordeon en el seno de la corporacin IBM en 1961. SIMSCRIPT II.5, desarrollado por Markowitz y otros en la Corporacin Rand en 1962. SLAM II (Simulation Language for Alternative Modeling), desarrollado por Dennis Pegden y Alan Pritsker en 1979. SIMAN (SIMulation ANalysis), desarrollado por Dennis Pedgen en 1982. Los lenguajes de simulacin son paquetes informticos que incluyen elementos frecuentemente utilizados en cualquier tipo de aplicaciones de simulacin. Tambin existe otra posibilidad a la hora de desarrollar la codificacin del modelo, son los simuladores, se trata de paquetes informticos igualmente, pero que proporcionan elementos de simulacin utilizados normalmente en un tipo especfico de aplicaciones de simulacin, como por ejemplo los procesos de fabricacin en una determinada pieza, requiriendo una programacin muy reducida o casi nula. Se pierde flexibilidad, pero se gana eficacia y rapidez en el modelado.
Pgina 84
5.1 Caractersticas del software Arena Arena es un lenguaje de programacin cuya principal caracterstica es la posibilidad de adecuacin al nivel de programacin necesario en cada caso, incluso dentro de un mismo modelo. Esto permite que Arena no pierda flexibilidad, al incluir la posibilidad de utilizacin de lenguajes de propsito general como Microsoft, Visual Basic o C. Se combinan pues todas las facilidades de una programacin de alto nivel con la flexibilidad de un lenguaje de programacin general. Esto lo consigue proporcionando una serie de plantillas intercambiables entre s que contienen mdulos para el modelado y anlisis de simulacin grfica y que pueden combinarse para construir una amplia variedad de modelos de simulacin. Para una mayor facilidad de exposicin y una mejor organizacin, los mdulos estn agrupados en paneles y en la mayora de los casos, los mdulos de diferentes paneles pueden mezclarse dentro de un mismo modelo. Esta flexibilidad a la hora de modelar se mantiene debido a que Arena tiene una estructura completamente jerrquica, como se muestra en la figura.
Pgina 85
Figura 5.3: Estructura Jerrquica del Arena
En cualquier momento, se puede trabajar con mdulos de bajo nivel del panel de Bloques y Elementos y obtener acceso a la flexibilidad de un lenguaje de simulacin si es necesario, as como mezclar construcciones del SIMAN junto con mdulos de alto nivel de otra plantilla (de hecho, los mdulos de Arena estn formados por componentes SIMAN). Para necesidades especializadas, como algoritmos de decisin complejos o el acceso de datos desde una aplicacin externa, se pueden escribir partes del modelo en
Pgina 86
un lenguaje como Visual Basic o C/C++. Todo esto, sin importar cmo de alto o bajo se quiera estar en la jerarqua, tiene lugar en una misma interfaz grfica para el usuario. Junto a esta flexibilidad, Arena aporta todos los elementos generales de otros lenguajes de simulacin como: la utilizacin de distribuciones estndar, la ejecucin de varias iteraciones independientes en un solo lote, la utilizacin de periodos de eliminacin de los efectos de condiciones iniciales, en los cuales las variables no guardan valores para posteriores anlisis estadsticos. Adems, Arena permite la utilizacin de un modo rpido de ejecucin para la obtencin de resultados y otro modo donde se tiene acceso a la animacin del modelo. La animacin ofrece multitud de posibilidades, incluso la importacin desde otros programas como AUTOCAD o MICROSOFT VISIO. Incluye la animacin dinmica en el mismo medio de trabajo. Tambin proporciona un soporte integrado, incluyendo grficos, para algunas cuestiones de diseo estadstico y anlisis, que forman parte de un buen estudio de simulacin. Arena incorpora una biblioteca con multitud de ejemplos que ayudan en la codificacin y modelado del sistema. Para la depuracin del modelo se tiene la posibilidad de escoger entre diferentes tipos de trazas posibles, incluyendo las distintas causas de error y solucin ante cualquier problema. Otras herramientas de inters son los analizadores de datos, tanto de entrada como de salida, para modelos estocsticos, que incluyen las ms frecuentes tcnicas estadsticas de tratamiento de datos: test de comparacin de medias, comparacin de varianzas, correlogramas, intervalos de confianza de media y de desviacin estndar, ajuste de distribuciones estadsticas estndar a un conjunto de datos, grficos de barras, histogramas, grficos XY; etc. Tambin hay que destacar la interfaz con otros programas compatibles con Windows, como son Excel, Word, Visual Basic y PowerPoint. Por ltimo, a modo de resumen, se muestra lo que es posible hacer con Arena: Modelar los procesos para definir, documentar y comunicar los resultados y avances obtenidos.
Pgina 87
Simular el futuro del sistema para entender las relaciones complejas e identificar las oportunidades para poder realizar mejoras. Visualizar las operaciones con grficos de animacin dinmicos. Analizar cmo el sistema llevar a cabo su configuracin bajo una serie de posibles alternativas de manera que se pueda elegir de forma segura el mejor camino para sacar adelante los negocios.
Conceptos bsicos en Simulacin con Arena
En este apartado se definirn las distintas partes de un modelo de simulacin as como la importancia de cada una de ellas a la hora de modelar y ejecutar: Entidades: Es el trmino utilizado para representar personas, objetos, o cualquier otra cosa, reales o imaginarias, que se mueven a travs del modelo, pudiendo causar cambios en el estado del sistema o afectar a otras entidades. Son los objetos dinmicos en la simulacin, son creadas, pasan a travs de una sucesin de procesos y luego desaparecen, en el caso de los modelos de ciclo abierto ya que, no obstante, es posible tener entidades que nunca dejen el sistema sino que permanezcan circulando por l. Sin embargo, todas las entidades han de ser creadas, bien por uno mismo o automticamente por el software. Atributos: Para individualizar entidades, se les asignan atributos. Un atributo es una caracterstica comn de todas las entidades, pero con un valor especfico que permite diferenciar una de otra. Lo ms importante con respecto a los atributos es que sus valores estn unidos a entidades especficas. El mismo atributo tendr normalmente valores diferentes para entidades distintas. As, los atributos son variables locales (local para cada entidad). Arena puede asignar estos atributos automticamente o ser definidos por uno mismo si es necesario. Variables (Globales): Una variable es una parte de informacin que refleja algunas caractersticas del sistema, sin importar cuntas o qu tipos de entidades pueda haber. Se pueden tener muchas variables diferentes en un modelo, pero cada una de ellas es
Pgina 88
nica. Hay dos tipos de variables: Variables fabricadas por Arena (nmero de entidades en la cola, nmero de recursos ocupados, tiempo de simulacin, etc.) y Variables
definidas por el usuario (nmero de entidades en el sistema, etc.). Al contrario que los
atributos, las variables no estn unidas a una entidad especfica, sino que ms bien pertenecen al sistema en general. Son accesibles por todas las entidades y muchas pueden ser cambiadas por alguna entidad. Recursos: Para que sobre una entidad se realice un proceso determinado ser necesaria la presencia de uno o varios recursos que presten ese servicio. Los recursos representan todo aquello necesario para realizar un proceso: personas, mquinas, herramientas, etc. Son elementos estticos del modelo y en ellos son alojadas las entidades, presentando posibles estados distintos definidos por el usuario: ocupados, libres, en fallo, etc. Colas: Son espacios de espera para las entidades en su movimiento por el sistema, cuando estas han sido detenidas por causas del fallo del sistema. Por ejemplo, si un determinado recurso est ocupado y la entidad quiere acceder a l, ha de esperar hasta que est disponible. Son elementos pasivos del modelo, no se pueden crear durante la ejecucin del programa. Estaciones: Arena representa los sistemas dividindolos en subsistemas. Estos subsistemas son llamados estaciones. De esta forma, el modelo se hace ms manejable y se proporciona una forma fcil de definicin del movimiento de entidades entre partes del sistema. Conveyors y transporters: Una entidad puede ser transferida de una estacin a otra de diferentes formas: Una conexin directa: la entidad no ha de esperar a que est disponible ningn medio de transporte. En el camino se invierte un tiempo fijado por el usuario, pudiendo especificarse como cero. Conveyors: funcionan como cintas transportadoras. Una vez que la entidad pide el acceso desde una estacin para dirigirse a otra, ha de esperar a que exista sitio en la cinta para comenzar el transporte. Se detallarn ms caractersticas de este transporte en puntos posteriores del proyecto.
Pgina 89
Transporters: en este caso existe un nmero de vehculos encargados de realizar el transporte. La entidad tras solicitar un vehculo ha de esperar a que est disponible para poder realizar el transporte. Acumuladores Estadsticos: Para conseguir medidas de los resultados o salidas llevados a cabo, hay que hacer uso de varias variables que actan como acumuladores estadsticos conforme la simulacin progresa, como pueden ser: el nmero de partes producidas, el total de tiempo esperando en una cola, nmero de entidades que han pasado a travs de una cola, el mayor tiempo que se ha permanecido en la cola, el total de tiempo que pasa en el sistema para todas las entidades que van desapareciendo, el rea ocupada debajo de la curva de algunas funciones, etc. Eventos: A la hora de ejecutar el modelo, bsicamente todo se centra en los eventos. Un evento es algo que ocurre en un instante de tiempo (simulado) que puede hacer cambiar, atributos, variables o acumuladores estadsticos, como pueden ser: la llegada o la salida del sistema de una entidad, el final de la simulacin, etc. Para poder ejecutar, una simulacin debe seguir los eventos que se supone que ocurrirn en el futuro (simulado). En Arena, esta informacin es guardada en un calendario de eventos. Reloj de Simulacin: El tiempo actual en la simulacin es guardado en una variable llamada Reloj de Simulacin. El transcurso de este tiempo no tiene por qu coincidir con el real, se puede acelerar o retardar. Este reloj marca el transcurso de los eventos del calendario y es una parte muy importante de la simulacin dinmica (el reloj es una variable llamada TNOW). Comienzo y Parada: Una cuestin muy importante en la simulacin es cmo empezar y parar. Arena hace muchas cosas automticamente, pero no es capaz de decidir cuestiones del modelado como el comienzo y la parada. El usuario es quien debe determinar las condiciones apropiadas de comienzo, cunto debera durar la ejecucin y si se debera parar en un instante particular de tiempo o cuando ocurra algn suceso especfico. Estas decisiones pueden tener un gran efecto tanto en los resultados como en las cosas ms obvias como pueden ser los valores de los parmetros de entrada.
Pgina 90
Ventana de Arena
Arena es un lenguaje de simulacin para ser utilizado en entorno Windows 95 o posterior y se maneja como cualquier otro programa con entorno de ventanas, con todos los elementos y operaciones que este contiene. Adems, Arena es completamente compatible con otros software de windows, como procesadores word, hojas de clculo y paquetes CAD. Para este proyecto se utilizar la versin 5.0 cuya ventana se muestra en la figura indicando las distintas partes que la componen.
Figura 5.4: Ventana de Arena
A la hora de modelar un proceso en Arena, se trabajar con tres regiones principales de la ventana: en primer lugar se tiene la ventana del modelo propiamente dicha que se divide en dos partes claramente diferenciadas: Vista del Organigrama (Flowchart View)
Pgina 91
y Vista de la Hoja de Clculo (Spreadsheet View). La otra regin a tener en cuenta es la
Barra de Proyecto (Project Bar):

Vista del Organigrama: Contiene todos los grficos del modelo, incluyendo el organigrama del proceso, la animacin y otros elementos de dibujo. Vista de la Hoja de Clculo: Muestra los datos del modelo, como tiempos, costes y otros parmetros. Muchos parmetros del modelo pueden ser vistos y editados tanto en la vista del organigrama como en la de la Hoja de Clculo, pero esta ltima da el acceso a mucho de los parmetros a la vez, ordenados en grupos compactos de parmetros similares apropiados, es especialmente til en grandes modelos. Barra de Proyecto: se encuentra en el borde izquierdo de la ventana. Presenta varios paneles que contienen los principales tipos de objetos que se utilizarn. El primero de los paneles es el Panel de Proceso Bsico (Basic Process) que contiene los bloques de construccin fundamentales para modelar, llamados mdulos, que se usarn para definir el organigrama del proceso de simulacin. Junto a ste se tienen dos paneles ms, el Panel de Informes, que muestra los resultados de una simulacin tras ser ejecutada y el Panel de Navegacin, el cual permite mostrar diferentes vistas del modelo, incluyendo los distintos submodelos que pueda haber dentro de un modelo jerrquico. Adems del Panel de Proceso Bsico, existen otros paneles: el Panel de Proceso Avanzado (Advance Process) que contiene bloques de construccin ms pequeos para un modelado ms detallado, el Panel de Proceso de
Traslado Avanzado (Advance Transfer Process) el cual incluye muchas opciones para el
movimiento de entidades por el modelo y el lenguaje de simulacin de Bloques y
Elementos (los cuales juntos ofrecen acceso completo al SIMAN), que sustenta el
Arena. Aparte de stos, existen otros paneles que contienen ms construcciones para aplicaciones especiales, como son el modelado de centros de llamadas o lneas de alta velocidad de empaque. Adems de estas tres regiones principales, existen otras dos que tambin forman parte de la ventana de Arena. La primera de ellas, situada en la parte ms alta de la ventana, est formada por varias Barras de Herramientas que facilitan un rpido acceso a
Pgina 92
actividades frecuentes. Por otro lado, en la parte inferior de la ventana, se tiene la Barra
de Estado, que muestra informacin sobre el estado de la simulacin, como el valor del
reloj de la simulacin durante la ejecucin o el nmero de copias que estn siendo y que sern ejecutadas. Llegados a este punto es importante hablar de los mdulos del programa. Los mdulos se pueden considerar como los bloques bsicos de construccin para definir los modelos en Arena. Son los objetos del organigrama y los datos que definen el proceso que ser simulado. Se eligen de los distintos paneles de la Barra de Proyecto. Existen dos tipos bsicos de mdulos: los de organigramas y los de datos. Los mdulos de los organigramas definen los procesos dinmicos del modelo. Se puede pensar en estos mdulos como nodos o lugares a travs de los cuales las entidades fluyen, se originan o desaparecen del modelo. Los mdulos de los organigramas se suelen conectar unos con otros. En el panel del Proceso Bsico, se pueden encontrar los siguientes mdulos:
Figura 5.5: Mdulos del Proceso Bsico
Pgina 93
Cada tipo de mdulo de este panel tiene una forma distintiva. Pero en los otros dos paneles se encuentran otro tipo de mdulos representados todos por rectngulos. De esta manera, los mdulos del Proceso Avanzado son:
Figura 5.6: Mdulos del Proceso Avanzado
En el Panel de Proceso de Traslado Avanzado se usan colores en los rectngulos para distinguir los diferentes tipos de mdulos.
Pgina 94
Figura 5.7: Mdulos del Proceso de Traslado Avanzado
Los mdulos de datos definen las caractersticas de varios elementos del proceso, como entidades, recursos y colas. Pueden tambin actualizar variables y otro tipo de valores numricos y expresiones que pertenecen al modelo. Los iconos para estos mdulos en la Barra de Proyecto parecen una hoja de clculo. Los mdulos del panel de Proceso Bsico son: Entity (Entidad), Queue (Cola), Resource (Recurso), Variable (Variable), Schedule (Programa) y Set (Conjunto). Los otros paneles contienen tipos adicionales de mdulos de datos: Expression (expresin),
Statistic
(Estadstica),
Conveyor
(Conveyor),
Segment
(Segmento),
Distance
(Distancia), etc. Tanto los mdulos del organigrama como los de datos estn relacionados mediante nombres dados a objetos que tienen en comn (como colas, recursos, tipos de entidades y variables). Arena guarda una lista interna de los nombres que se le dan a estos tipos de objetos tal como el usuario los define y entonces presenta estos nombres en una lista que ayuda a recordar qu cosas han sido nombradas.
Pgina 95
Una vez obtenidos los conocimientos bsicos del Arena, se puede comenzar a abordar la simulacin del problema definido en los captulos anteriores.
Pgina 96
5.2 Aplicacin de ARENA al problema
Tratamos de simular el proceso logstico, usando contenedores retornables, que cubre la demanda de las grandes superficies de un producto cualquiera fabricado por las diversas marcas que lo producen, aplicando un sistema de logstica de retorno con depsitos. Existen dos depsitos intermedios de contenedores retornables adonde vuelven despus de haber sido usados, para una entrega, con el producto correspondiente como carga, desde un emisor los fabricantes del bien - hasta la gran superficie demandante. Los fabricantes tambin podran contemplarse como centros logsticos de distribucin suficientemente grandes como para poder evitar la problemtica de la fabricacin en esta simulacin. Slo habra, por tanto, dos entidades fundamentales: por un lado, los productos asociadas a una demanda por cada gran superficie y por cada fabricante, de modo matricial. Por otro, los contenedores retornables en nmero fijo desde el comienzo de la simulacin, contemplados como recursos compartidos.
El modelo diseado bajo el software ARENA se compone de 3 partes fundamentales:
1. Los 4 Fabricantes 2. Los 10 Receptores 3. Los 2 depsitos
Se describen a continuacin ms detalles de cada uno de ellos:
1. Los 4 fabricantes, que crean el nmero exacto de entidades demandadas por los receptores en su conjunto, como puede verse el la tabla 5.1, estn formados por un mdulo de creacin, otro de lotes para la agrupacin de productos con objeto de
Pgina 97
completar los contenedores y otro de asignacin de ciertos atributos interesantes para la ejecucin del programa, como el cambio del dibujo que representa a la entidad.
Fabricantes
Entidades creadas 5123 6324 5933 4660 22040
1 2 3 4
En total
Tabla 5.1 Entidades creadas.
Figura 5.8 Mdulos de creacin y de asignacin.
A continuacin, se coloca un mdulo de decisin que se encarga de hacer el reparto de los contenedores en funcin de la demanda correspondiente a cada receptor, en porcentajes del total de productos creados por ese fabricante, segn la tabla 5.2:
Pgina 98
Matriz Demanda Porcentual por emisor
receptores 1
17 11 5 8
2
8 14 14 16
3
14 0 5 18
4
17 13 17 7
5
2 12 13 8
6
12 16 0 2
7
12 7 17 4
8
3 8 14 9
9
15 9 8 7
10
0 9 9 20 100 100 100 100
1 2 3 4
emisores
Tabla 5.2. Demanda porcentual
Figura 5.9 Mdulo de reparto de demandas.
Seguidamente, en cada una de las ramificaciones, encontramos un mdulo de solicitud de recurso que crear una cola a la espera de que queden libres los contenedores de los depsitos. Cabe mencionar que los emisores 1 y 2 solicitarn recurso slo al depsito 1 y los emisores 3 y 4 harn lo propio con el depsito 2. Asociado a esta peticin de recurso se encuentra un tiempo de retraso que simula el tiempo invertido por el contenedor en acudir desde el depsito solicitado al emisor solicitante. Tiempos relacionados con los costes descritos en epgrafes anteriores asumiendo que 1 hora de transporte cuesta 10 unidades monetarias. Por tanto, los tiempos a tener en cuenta son los descritos en la tabla 5.3:
Pgina 99
Tiempos Distribucin (Horas)
Emisores
1 1 2
4,4 x
2
0,3 x
3
x 0,9
4
x 1,5
Depsitos
Tabla 5.3 Tiempos de distribucin
Figura 5.10 Mdulos de peticin y de retraso asociado.
Finalmente, para acabar con la descripcin de esta seccin del modelo, nos encontramos con un mdulo de ruta, que enva las entidades a los receptores segn unos retrasos establecidos por la matriz de costes transformada, eso s, en horas (dividiendo por 10), por lo que tenemos:
Matriz Distancias de Envos (horas)
1 1 2 3 4
8,6 1,5 0,7 3,8
2
3,5 6,5 0,2 7,6
receptores 3 4 5
7,6 7,9 6,7 8,3 1,6 7,9 6,7 0,9 4 4,6 1,5 1,3
6
7,8 3,7 3,7 2,5
7
0,9 5,8 1,8 5,9
8
4,7 2,1 5,5 3,4
9
9,1 6,2 8,7 0,8
10
2,8 0,4 2,4 6,6
emisores
Tabla 5.4 Distancias de envos.
Pgina 100
Figuta 5.11 Mdulo de ruta.
La vista que presenta esta seccin bajo el entorno ARENA es la siguiente:
Pgina 101
Figura 5.12 Seccin emisor del modelo.
Pgina 102
2. Los 10 Receptores. Formados inicialmente por un mdulo estacin que recibir los envos hechos desde los emisores y un mdulo de retraso que simular el tiempo invertido en la descarga, tiempo considerado constante de media hora para todos ellos. A continuacin se encuentre un mdulo de separacin cuyo objeto es duplicar las entidades para poder seguirle la pista, en el camino de retorno, a los contenedores transportadores. Por un lado, por tanto, depositaremos las entidades consideradas entregadas, eliminndolas despus de ser contadas, y por otro, las enviaremos por un mdulo ruta al depsito correspondiente que es el ms cercano que se encuentre de cada receptor, que corresponde con la siguiente tabla:
Tiempo Recuperacin (Horas)
Depsitos
1 1 2 3 4 5 6 7 8 9 10
0,1 2,8 8,9 1,7 0,6 4,7 9,9 0,5 0,2 8,1
2
6 4,2 0,1 0,4 3,6 0,7 0,3 0,8 5,8 7,2
receptores
Tabla 5.5 Tiempos de recuperacin.
Pgina 103
Figura 5.13 Mdulos Estacin y decisin.
Esta seccin del modelo se representa as:
Figura 5.14 Vista de la seccin receptor.
3. Los 2 depsitos. Los dos depsitos que mostraron ser los ptimos en el anlisis anteriormente realizado (2 y 3) pasan ahora a nombrarse 1 y 2 por comodidad, pero manteniendo todos los datos asociados ellos. Por lo cual, la distancia, en unidad de tiempo, a la que se encuentran ambos es de 0.5 horas, para poder simular el proceso de recolocacin de contenedores. Dichos depsitos se forman con un mdulo de recepcin, de tipo estacin al que le sigue una pregunta formulada al tipo de contenedor que se trate para poder distinguir aquellos pertenecientes al depsito 1 o al 2 y facilitar as la recolocacin de los mismos. Esta recolocacin, como hemos dicho, lleva asociada un retraso simulando en hecho fsico del transporte de contenedor. Seguidamente, los contenedores se ven sometidos a
Pgina 104
otro retraso que simula, esta vez, la limpieza y mantenimiento del mismo. Por ltimo, antes de su disposicin/eliminacin, realizamos la liberacin del recurso contenedor que podr, por tanto estar de nuevo disponible para atender a alguna de las colas solicitantes situadas en los emisores. La vista ampliada de estos depsitos se representa as en el entorno ARENA:
Figura 5.14 Vista de la seccin Depsitos.
Por tanto, la vista global del modelo de simulacin se muestra a continuacin:
Pgina 105
Figura 5.15 Vista general del modelo.
Repaso de algunas consideraciones hechas: Nmero fijo, por cada simulacin, de contenedores retornables, hasta ajustar tiempos necesarios para el reparto completo 2 depsitos de contenedores de capacidad limitada al nmero de recursos disponibles. 10 productos por cada contenedor o camin, como quiera llamarse. Ms correcto sera decir camin-contenedor, porque se est suponiendo que el medio de transporte es ese tipo de camin que slo es capaz de acarrear un contenedor, tpicamente de 12 metros de longitud, como carga. La creacin total, en nmero, del producto del fabricante 1, por ejemplo, es la suma de las demandas mensuales de todas las superficies de venta. La simulacin corre solo para un periodo de tiempo concreto: un mes, segn los datos disponibles-introducibles de demanda, es decir, slo nos interesa el resultado global del periodo total.
Pgina 106
Toda la demanda del periodo se crea en el instante cero y se almacena en cola, as como todos los contenedores retornables considerados en la simulacin.
Pgina 107
5.3 Resultados de la simulacin
Se trata de simular como se comporta el sistema, viendo fundamentalmente los tiempos de ejecucin, con la variacin de un parmetro p que relaciona la demanda total con el nmero de contenedores. Podemos hacer varias simulaciones en casos extremos del parmetro para observar el comportamiento lmite del modelo.
P= demanda de contenedores/ n contenedores
El primer caso simulado contiene 44 contenedores y despus de su simulacin nos ofrece un tiempo de reparto de 514 horas, que equivale a 21 das laborables trabajando a 24 horas por da. No se ajusta a nuestro horizonte temporal de 1 mes, por poco, para el cual hemos supuesto la demanda, por tanto, debemos disminuir en nmero de contenedores. Como informacin, cabe decir que el parmetro p alcanza el valor, previsiblemente inapropiado, de:
P= 2204/44 = 50,1
El segundo caso ensayado, con 40 contenedores, ofreci un tiempo total de ejecucin de 569 horas, que significa, suponiendo que se reparte durante las 24 horas del da, un horizonte temporal de 24 das. Si consideramos que slo repartimos los das laborables, tenemos que nuestro modelo, con 40 contenedores, reparte casi exactamente en el tiempo previsto de 1 mes (22 das), con lo cual parece ser que nos hemos acercado al nmero apropiado de contenedores y, lo que es ms importante, a la relacin del parmetro p:
P = 2204 / 40 = 55,1
Pgina 108
Para afinar en nuestra bsqueda del ptimo, probamos ahora con 42 contenedores, 21 en cada depsito, y simulamos. En este ensayo obtenemos que el tiempo de reparto es de 535 horas, que representa 22,3 das, horizonte temporal casi exacto a nuestro periodo supuesto de demanda. El parmetro p, una vez redondeado en el sentido apropiado para considerar 22 das, resulta alcanzar un valor de:
P=2204 / 42 = 53
Otros ensayos realizados nos muestran que, para 36 contenedores, el tiempo de reparto es de 630 horas, equivalentes a 1 mes y una semana; y que para los casos extremos de 2 contenedores (1 en cada depsito) el tiempo de reparto es de 11.370 horas (474 das), caso extremo sin ninguna utilidad prctica. Tambin se ha realizado, como comprobacin de la solidez del modelo, la simulacin para un nmero muy grande de contenedores, donde puede observarse que el tiempo de reparto final slo depende del proceso de transporte ms lento de todo el sistema. As, para 20.000 contenedores, el tiempo obtenido es de 16 horas que coincide con el tiempo que tarda en enviarse un producto desde el emisor 4 al receptor 10 y vuelta al depsito correspondiente, con todos los procesos incluidos de descarga, limpieza y mantenimiento. Demuestra ser as un modelo coherente y robusto.
Por tanto, como observacin fundamental de nuestra simulacin, hemos obtenido que la relacin entre el nmero de contenedores y la demanda a satisfacer es de valor:
P= 53
Lo que significa que, dada una demanda determinada, siempre podremos saber qu nmero de contenedores se ajusta al cumplimiento del tiempo de reparto necesitado, sin ms que dividir la demanda entre este valor del parmetro.
Pgina 109
Posibles mejoras y ampliaciones
La primera variante mejorada del modelo sera contemplar la posibilidad de distribucin de varios productos, aadiendo la creacin, por parte de los fabricantes, de otras entidades que tuvieran su correspondiente demanda asociada. Tambin podra contemplarse como factible la inclusin de aleatoriedad en todos los desplazamientos, recogiendo as la realidad azarosa de cualquier proceso de transporte, as como de los tiempos de descarga, limpieza y mantenimiento a los que se ven sometidos los contenedores y sus entidades asociadas en el modelo. Otra variante podra ser la modificacin del nmero de productos por contenedor, que provocara la definicin de otro problema completamente diferente, ya que el parmetro p se alejara tanto del valor ptimo calculado como nos separsemos de esos 10 productos por contenedor que hemos supuesto en nuestras simulaciones. Es decir, en el caso de estimar 15 productos por contenedor, por ejemplo, el tiempo de ejecucin se reducira y el parmetro p debera, forzosamente, ser notablemente inferior.
Pero estas mejoras no aportan complicaciones conceptuales al modelo simulado, tan solo complejidad resoluble con suficiente capacidad de computacin, algo que no merece la pena desarrollar en un trabajo de este tipo con unos valores que, desde el primer momento, han sido escogidos aleatoriamente. Eso s, es necesario, como as se ha hecho, una coherencia necesaria en todos aquellos nmeros que lo requeran, como distancias simtricas y rdenes de magnitud semejantes. En situaciones reales con datos extrados de un problema realista, si cabe hacer un desarrollo concienzudo de todas estas variantes, especialmente en el caso de las variables aleatorias de tiempo y, sobre todo, de las capacidades de transporte de los modelos disponibles de contenedores retornables. Otra interpretacin de nuestro problema, este ya ms alejado de lo aqu inicialmente considerado, es la posibilidad de distinguir otros medios de transporte que no sean el
Pgina 110
camin-contenedor aqu supuesto, es decir, que un medio de transporte pueda acarrear varios contenedores retornables en un solo trayecto. Pero esto ya queda para trabajos posteriores.
Pgina 111

Simulacion Arena111

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Simulacion Arena111

Cargado por

Copyright:

Formatos disponibles

PROYECTO FIN DE CARRERA Sistemas con Logstica de Retorno: Aplicacin al caso de contenedores retornables

5. SIMULACIN DEL MODELO CON ARENA

Anlisis de sistemas ya existentes, para su mejor comprensin y optimizado de los

Figura 5.1: Simulacin para el anlisis de sistemas ya existentes.

Figura 5.2: Simulacin del diseo de nuevos sistemas.

Experimentos de campo: a partir de unos datos de entrada y salida obtenidos del

Test de Turing: a personas con experiencia sobre el sistema real modelado, se le

Figura 5.3: Estructura Jerrquica del Arena

Conceptos bsicos en Simulacin con Arena

Figura 5.4: Ventana de Arena

y Vista de la Hoja de Clculo (Spreadsheet View). La otra regin a tener en cuenta es la

Barra de Proyecto (Project Bar):

Figura 5.5: Mdulos del Proceso Bsico

Figura 5.6: Mdulos del Proceso Avanzado

Figura 5.7: Mdulos del Proceso de Traslado Avanzado

5.2 Aplicacin de ARENA al problema

El modelo diseado bajo el software ARENA se compone de 3 partes fundamentales:

1. Los 4 Fabricantes 2. Los 10 Receptores 3. Los 2 depsitos

Se describen a continuacin ms detalles de cada uno de ellos:

Entidades creadas 5123 6324 5933 4660 22040

Tabla 5.1 Entidades creadas.

Figura 5.8 Mdulos de creacin y de asignacin.

Matriz Demanda Porcentual por emisor

Tabla 5.2. Demanda porcentual

Figura 5.9 Mdulo de reparto de demandas.

Tiempos Distribucin (Horas)

Tabla 5.3 Tiempos de distribucin

Figura 5.10 Mdulos de peticin y de retraso asociado.

Matriz Distancias de Envos (horas)

Tabla 5.4 Distancias de envos.

Figuta 5.11 Mdulo de ruta.

La vista que presenta esta seccin bajo el entorno ARENA es la siguiente:

Figura 5.12 Seccin emisor del modelo.

Tiempo Recuperacin (Horas)

Tabla 5.5 Tiempos de recuperacin.

Figura 5.13 Mdulos Estacin y decisin.

Esta seccin del modelo se representa as:

Figura 5.14 Vista de la seccin receptor.

Figura 5.14 Vista de la seccin Depsitos.

Por tanto, la vista global del modelo de simulacin se muestra a continuacin:

Figura 5.15 Vista general del modelo.

5.3 Resultados de la simulacin

P= demanda de contenedores/ n contenedores

Posibles mejoras y ampliaciones

También podría gustarte