Simulacion Arena

PROYECTO FIN DE CARRERA
Sistemas con Logística de Retorno:

Aplicación al caso de contenedores retornables
5. SIMULACIÓN DEL MODELO CON ARENA
¿Qué es Simulación?
“ Simulación es el proceso de diseñar 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 límites 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 comprensión del mundo que le rodea, ejercitándose con parcelas reducidas y
evolucionando progresivamente a una visión unificada de sistemas cada vez más
complejos.
La simulación, haciendo uso de esta capacidad, es el diseño 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 mayoría de los casos, las
interrelaciones que componen el sistema serán lo suficientemente complicadas y
complejas como para hacer inviable la obtención de soluciones analíticas exactas con
métodos matemáticos. Es pues la simulación una buena herramienta para el estudio de
estos sistemas. No se aspira a encontrar soluciones analíticas y exactas del problema,
sino a la mejor comprensión de los sistemas en estudio.
La Simulación con ordenador se refiere a una serie de métodos para estudiar una amplia
variedad de modelos de sistemas del mundo real mediante evaluación numérica, usando
un software apropiado, diseñado para imitar las operaciones o características del
sistema, frecuentemente con respecto al tiempo. Desde un punto de vista práctico, la
simulación es el proceso de diseño y creación de un modelo por ordenador a partir de un
Página 73
sistema real o propuesto, con el fin de dirigir experimentos numéricos para comprender
mejor el comportamiento de dicho sistema según un conjunto de condiciones dado.
Aunque puede ser utilizado para estudiar sistemas simples, el poder real de esta técnica
se consigue completamente cuando se usa para estudiar sistemas complejos. Puede que
la simulación no sea la única herramienta para estudiar un modelo pero es con
frecuencia el método elegido. La razón para esto es que la simulación permite un
modelo lo bastante complejo, si es necesario, para representar el sistema fielmente y
además analizarlo. Otros métodos pueden requerir hipótesis de simplificación más
fuertes sobre el sistema para poder permitir su análisis, lo cual podría cuestionar la
validez del modelo.
Desarrollo de la Simulación
Cuando las capacidades y la sofisticación de los lenguajes y paquetes de simulación

empezaron a aumentar drásticamente sobre los años 40, el concepto de cómo y cuándo
usar simulación cambió.
Al principio, sobre finales de los años 50 y la década de los 60, la simulación era una
herramienta cara y especializada que era usada generalmente sólo por grandes
corporaciones que requerían grandes inversiones de capital (corporaciones del acero y
aeroespaciales).
El uso de la simulación tal como se conoce hoy en día empezó sobre los años 70 y
principios de los 80. Los ordenadores comenzaron a ser más rápidos y baratos y el valor
de la simulación empezó a ser descubierto por otras industrias, aunque la mayoría de las
compañías eran aún bastante grandes. Sin embargo, la simulación se convirtió en la
herramienta elegida por muchas compañías, sobre todo industria pesada y automoción,
para determinar por qué ocurrían los desastres y, en algunas ocasiones, para saber dónde
encontrar la causa del fallo.
Durante los 80 la simulación empezó a establecer sus raíces en los negocios debido en
gran parte a la introducción del ordenador personal y la animación. Aunque aún se
usaba para analizar los fallos de los sistemas, mucha gente solicitaba la simulación antes
Página 74
de que la producción empezara. A finales de los 80, la utilidad de la simulación fue

reconocida por muchas grandes firmas, varias de las cuales realmente hicieron de la
simulación un requerimiento antes de la aprobación de cualquier inversión importante
de capital. Sin embargo, la simulación no estaba aún lo bastante extendida y rara vez era
usada por pequeñas firmas.
La simulación realmente empezó a madurar sobre los 90. Muchas empresas pequeñas
incorporaron esta herramienta. Una mejor animación, fácil de usar, ordenadores más
rápidos, fácil integración con otros paquetes y la aparición de simuladores han ayudado
a que la simulación se convierta en una herramienta estándar en muchas compañías. La
manera en que la simulación se está usando también está cambiando, ahora se usa con
antelación, en la fase de diseño y, frecuentemente, actualiza los cambios que deben ser
realizados en los sistemas de operaciones. Esto proporciona un modelo de simulación
que permite ser usado para el análisis de sistemas en muy corto plazo. La simulación
también 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 simulación
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 simulación con
éxito. No obstante, la velocidad de cambio en la simulación se ha acelerado en los
últimos años y hay razones para pensar que seguirá este rápido crecimiento en un futuro
próximo.
Aplicaciones de la Simulación
Como ya se ha visto, la llegada del ordenador y su aplicación en simulación ha hecho

posible el desarrollo de un gran número de técnicas y su aplicación en muy diversos
campos:
• Sistemas de producción: planificación, control de inventarios, líneas de productos,
programación.
Página 75
• Sistemas de servicios: admisión de hospitales, operaciones en ventanillas de bancos,

grandes superficies, restaurantes de comida rápida.
• Sistemas de distribución: almacenes, red de distribución.
• Sistemas informáticos: redes de comunicación, ordenadores, software y hardware,
protocolos.
• Sistemas económicos y financieros.
• Otros: teoría de juegos, situaciones de emergencias por catástrofes, etc.
La aplicación de la simulación a sistemas tan diversos persigue unos objetivos que se

pueden recoger en la siguiente clasificación:
Análisis de sistemas ya existentes, para su mejor comprensión y optimizado de los
mismos y la evaluación de distintas estrategias ante un mismo problema en el sistema.
El esquema en este tipo de simulación sería:
Figura 5.1: Simulación para el análisis de sistemas ya existentes.
Como etapa previa al diseño de nuevos sistemas, intentando minimizar los aspectos
negativos del modelo y su adecuación al proyecto. El esquema sería el siguiente:
Página 76
Figura 5.2: Simulación del diseño de nuevos sistemas.
Con fines de educación o adiestramiento, para obtener experiencia en la toma de

decisiones o adquirir ciertas rutinas o hábitos.
Sistemas y Modelos en Simulación
La Simulación, como la mayoría de los métodos de análisis, 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
características 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 según 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 número de coches en un tramo de calle
cambia sólo cuando entra o sale un nuevo coche.
Página 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 incorporación al tráfico. 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 diseñar si
puede o no existir. Los representantes o controladores de un sistema pueden tener
también una ayuda disponible para operaciones del día a día (como decidir qué hacer en
una fábrica si una máquina 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 físicamente o no es accesible por otras razones, se necesitará recurrir a la
realización de un modelo sobre el que experimentar para estudiar el sistema.
Estos modelos que representan al sistema pueden asemejarse físicamente más o menos
al sistema dado, dependiendo del grado de abstracción que se realice. En función de esta
abstracción se tendrán:
• Modelos físicos o icónicos: representan físicamente al modelo real pero a distintas
escalas, como el caso de reactores químicos o túneles de aire.
• Modelos matemáticos o lógicos: representan al sistema por medio de símbolos
matemáticos y diagramas de flujos.
La experimentación 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 matemáticas
cuantitativas, se obtendrán soluciones analíticas 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 simulación para poder estudiar el sistema.
Página 78
Definidos los modelos lógicos de simulación, se pueden clasificar en tres direcciones

principales:
Estáticos / Dinámicos: En los modelos estáticos se representa el sistema en un
instante concreto de tiempo (ejemplo: localización de almacenes en una región). En los
modelos dinámicos las variables del modelo evolucionan con el tiempo, como en los
modelos de colas.
Deterministas / Estocásticos: 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 serán modelos estocásticos.
Esta aleatoriedad en los valores de entrada al sistema producirá una aleatoriedad
también en los valores de salida.
Continuos / Discretos: Depende de los valores que pueda tomar el tiempo en la
simulación. El tiempo de simulación es una variable continua en los modelos continuos,
como pasa con los procesos químicos, pudiéndose integrar con respecto al tiempo.
Mientras que en los discretos, el tiempo de simulación está definido para instantes
concretos.
Para la situación que se pretende simular y teniendo en consideración las definiciones
anteriores, se tendrá un modelo dinámico, estocástico y discreto.
Ventajas e inconvenientes de la Simulación
Las ventajas más importantes que podemos encontrar en la simulación son las que se
describen a continuación:
• Experimentación sobre el modelo, menos costosa que sobre el sistema.
• Compresión del tiempo, es decir, operaciones que ocurren en horas o días pueden
simularse en segundos. Igualmente es posible el efecto contrario, estiramiento del
tiempo.
• Ambiente controlado y posibilidad de modificación. Los experimentos pueden ser
mejor definidos y específicos que los realizados sobre el sistema real.
Página 79
• Mayor y mejor comprensión de la realidad.

• Alternativa para el diseño de nuevos sistemas y su evaluación.
• Estimación de rendimientos de sistemas reales en diversas condiciones y situaciones,
permiten comprobar la eficacia de los sistemas reales.
Del mismo modo, también podemos encontrar algunos inconvenientes a la hora de
elegir la simulación 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 validación del modelo, a través de experimentos. Con una simulación se
pueden obtener gran cantidad de resultados, incluso una animación del modelo ayuda a
un mayor impacto de confianza en los resultados del modelo, que pueden estar
respaldados sólo por una deficiente validación del mismo, llevando a conclusiones
erróneas.
• Precisión y simplicidad del modelo son objetivos contrapuestos. A mayor precisión se
necesitará un modelo más complejo en la mayoría de los casos.
• La simulación es un proceso costoso: el tiempo empleado, el software utilizado, es
necesaria una experiencia en el modelado de sistemas.
Etapas del proceso de Simulación
En la realización de un proyecto de simulación 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 programación más potentes han facilitado algunas de ellas, e
incluso su agrupación en una sola. Estas etapas en las que se puede dividir un proceso
de simulación son:
1.- Formulación del problema.
Definición detallada de los objetivos, de las restricciones e hipótesis 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 también el grado de precisión requerido. La elaboración de un
modelo preliminar puede ayudar a poner de manifiesto de forma más clara y precisa los
Página 80
objetivos del estudio, las variables y parámetros necesarios para el desarrollo del
modelo y para el control del mismo.
2.- Formulación del modelo.
Elaboración del modelo matemático a utilizar, mediante técnicas o herramientas
específicas del modelado: Grafo de eventos y Diagrama de Ciclos de Actividades. La
formulación hecha debe ser simple, flexible, efectiva y eficiente, pudiéndose adaptar a
cambios durante el proyecto de simulación y el tiempo de computación sea razonable.
3.- Análisis 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
observación de las entradas y salidas del mismo. Los datos empíricos 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.- Codificación.
Consiste en trasladar el modelo a un lenguaje de programación para introducirlo en el
ordenador. Se pueden utilizar lenguajes de propósito general o bien lenguajes orientados
a la simulación.
5.- Verificación y validación.
La verificación es el proceso de revisión del programa para comprobar que éste
representa fielmente el modelo que hemos implementado. Se utilizan distintas técnicas
como: verificación manual de lógica, test modular, test de soluciones conocidas, análisis
de sensibilidad, test de estrés, animación gráfica.
La validación asegura la correcta representación de la realidad por parte del modelo. Al
realizar el modelo se suelen emplear una serie de hipótesis simplificativas como son:
• Se ignora el exterior.
• Aproximación de funciones no lineales.
• Aproximación de distribuciones empíricas.
• Independencia entre los componentes.
Página 81
• Agregación de componentes.
• Estacionalidad.
Existen varias técnicas de validación de modelos realizados mediante simulación. De
éstas, las dos más 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 través de la simulación y otros inventados, para ver si
son reconocidos.
6.- Diseño 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 iteración realice y su posible influencia en los resultados.
• Las iteraciones necesarias para obtener las precisiones definidas, ya que se obtienen
datos de tipo estadístico.
• Consideraciones realizadas respecto al valor escogido para los parámetros utilizados y
la relación entre estos.
7.- Experimentación y análisis 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 experimentación se realiza por lotes de experimentos que se consideran
independientes entre sí. Normalmente el tiempo de ejecución de estos modelos es
pequeño. 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 experimentación se realiza a través de largas ejecuciones del modelo,
Página 82
divididas en trozos respecto al tiempo tal que estos puedan ser considerados como
procedentes de experimentos independientes entre si.
8.- Documentación.
Elaboración de un documento que refleje los resultados obtenidos y cómo se ha ido
realizando el proceso de simulación: variaciones introducidas en el modelo, datos de
entrada, etc.
9.- Presentación de resultados.
Una adecuada elección de la presentación 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 simulación
Para llevar a cabo la ejecución de una simulación en el ordenador, se debe elegir el

lenguaje donde programar el modelo creado. Bien un lenguaje de propósito general
como puede ser C, BASIC, FORTRAN o bien lenguajes específicos de simulación La
utilización de lenguajes de propósito general permite una mayor flexibilidad que ciertos
lenguajes específicos de simulación. Estos lenguajes de propósito general, de menor
costo, crean un eficiente código del modelo que requiere de un tiempo de ejecución muy
inferior al de lenguajes específicos de simulación. Sin embargo, la construcción del
modelo es más tediosa y con mayor probabilidad de errores al tener que trabajar en
niveles de programación demasiado bajos.
Los lenguajes de simulación permitirán un menor tiempo de codificación, al proveer de
elementos orientados a la simulación. Aún así, el tiempo de ejecución será mayor.
También proveen de buenas herramientas de detección de errores de forma automática,
haciendo más fácil y segura la escritura del código. Su flexibilidad, sin embargo, es
mucho mayor que en un lenguaje de propósito general, al igual que el coste del
software, al trabajar a un más alto nivel en programación. Algunos de estos lenguajes
son:
Página 83
• GPSS (General Purpose Simulation System), desarrollado por Geoffrey Gordeon en el

seno de la corporación IBM en 1961.
• SIMSCRIPT II.5, desarrollado por Markowitz y otros en la Corporación 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 simulación son paquetes informáticos que incluyen elementos
frecuentemente utilizados en cualquier tipo de aplicaciones de simulación. También
existe otra posibilidad a la hora de desarrollar la codificación del modelo, son los
simuladores, se trata de paquetes informáticos igualmente, pero que proporcionan
elementos de simulación utilizados normalmente en un tipo específico de aplicaciones
de simulación, como por ejemplo los procesos de fabricación en una determinada pieza,
requiriendo una programación muy reducida o casi nula. Se pierde flexibilidad, pero se
gana eficacia y rapidez en el modelado.
Página 84
5.1 Características del software Arena
Arena es un lenguaje de programación cuya principal característica es la posibilidad de

adecuación al nivel de programación necesario en cada caso, incluso dentro de un
mismo modelo. Esto permite que Arena no pierda flexibilidad, al incluir la posibilidad
de utilización de lenguajes de propósito general como Microsoft, Visual Basic o C. Se
combinan pues todas las facilidades de una programación de alto nivel con la
flexibilidad de un lenguaje de programación general. Esto lo consigue proporcionando
una serie de plantillas intercambiables entre sí que contienen módulos para el modelado
y análisis de simulación gráfica y que pueden combinarse para construir una amplia
variedad de modelos de simulación. Para una mayor facilidad de exposición y una mejor
organización, los módulos están agrupados en paneles y en la mayoría de los casos, los
módulos 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 jerárquica, como se muestra en la figura.
Página 85
Figura 5.3: Estructura Jerárquica del Arena
En cualquier momento, se puede trabajar con módulos de bajo nivel del panel de
Bloques y Elementos y obtener acceso a la flexibilidad de un lenguaje de simulación si
es necesario, así como mezclar construcciones del SIMAN junto con módulos de alto
nivel de otra plantilla (de hecho, los módulos de Arena están formados por componentes
SIMAN). Para necesidades especializadas, como algoritmos de decisión complejos o el
acceso de datos desde una aplicación externa, se pueden escribir partes del modelo en
Página 86
un lenguaje como Visual Basic o C/C++. Todo esto, sin importar cómo de alto o bajo se
quiera estar en la jerarquía, tiene lugar en una misma interfaz gráfica para el usuario.
Junto a esta flexibilidad, Arena aporta todos los elementos generales de otros lenguajes
de simulación como: la utilización de distribuciones estándar, la ejecución de varias
iteraciones independientes en un solo lote, la utilización de periodos de eliminación de
los efectos de condiciones iniciales, en los cuales las variables no guardan valores para
posteriores análisis estadísticos.
Además, Arena permite la utilización de un modo rápido de ejecución para la obtención
de resultados y otro modo donde se tiene acceso a la animación del modelo.
La animación ofrece multitud de posibilidades, incluso la importación desde otros
programas como AUTOCAD o MICROSOFT VISIO. Incluye la animación dinámica
en el mismo medio de trabajo. También proporciona un soporte integrado, incluyendo
gráficos, para algunas cuestiones de diseño estadístico y análisis, que forman parte de
un buen estudio de simulación.
Arena incorpora una biblioteca con multitud de ejemplos que ayudan en la codificación
y modelado del sistema. Para la depuración del modelo se tiene la posibilidad de
escoger entre diferentes tipos de trazas posibles, incluyendo las distintas causas de error
y solución ante cualquier problema.
Otras herramientas de interés son los analizadores de datos, tanto de entrada como de
salida, para modelos estocásticos, que incluyen las más frecuentes técnicas estadísticas
de tratamiento de datos: test de comparación de medias, comparación de varianzas,
correlogramas, intervalos de confianza de media y de desviación estándar, ajuste de
distribuciones estadísticas estándar a un conjunto de datos, gráficos de barras,
histogramas, gráficos XY; etc.
También 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.
Página 87
• Simular el futuro del sistema para entender las relaciones complejas e identificar las
oportunidades para poder realizar mejoras.
• Visualizar las operaciones con gráficos de animación dinámicos.
• Analizar cómo el sistema llevará a cabo su configuración bajo una serie de posibles
alternativas de manera que se pueda elegir de forma segura el mejor camino para sacar
adelante los negocios.
Conceptos básicos en Simulación con Arena
En este apartado se definirán las distintas partes de un modelo de simulación así como
la importancia de cada una de ellas a la hora de modelar y ejecutar:
Entidades: Es el término utilizado para representar personas, objetos, o cualquier otra
cosa, reales o imaginarias, que se mueven a través del modelo, pudiendo causar cambios
en el estado del sistema o afectar a otras entidades.
Son los objetos dinámicos en la simulación, son creadas, pasan a través de una sucesión
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 automáticamente por el software.
Atributos: Para individualizar entidades, se les asignan atributos. Un atributo es una
característica común de todas las entidades, pero con un valor específico que permite
diferenciar una de otra. Lo más importante con respecto a los atributos es que sus
valores están unidos a entidades específicas. 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 automáticamente o ser definidos
por uno mismo si es necesario.
Variables (Globales): Una variable es una parte de información que refleja algunas
características del sistema, sin importar cuántas o qué tipos de entidades pueda haber.
Se pueden tener muchas variables diferentes en un modelo, pero cada una de ellas es
Página 88
única. Hay dos tipos de variables: Variables fabricadas por Arena (número de entidades
en la cola, número de recursos ocupados, tiempo de simulación, etc.) y Variables
definidas por el usuario (número de entidades en el sistema, etc.). Al contrario que los
atributos, las variables no están unidas a una entidad específica, sino que más 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, máquinas, herramientas, etc.
Son elementos estáticos 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
ejecución del programa.
Estaciones: Arena representa los sistemas dividiéndolos en subsistemas. Estos
subsistemas son llamados estaciones. De esta forma, el modelo se hace más manejable y
se proporciona una forma fácil de definición del movimiento de entidades entre partes
del sistema.
Conveyors y transporters: Una entidad puede ser transferida de una estación a otra
de diferentes formas:
• Una conexión directa: la entidad no ha de esperar a que esté disponible ningún 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 estación para dirigirse a otra, ha de esperar a que exista sitio en la
cinta para comenzar el transporte. Se detallarán más características de este transporte en
puntos posteriores del proyecto.
Página 89
• Transporters: en este caso existe un número de vehículos encargados de realizar el

transporte. La entidad tras solicitar un vehículo ha de esperar a que esté disponible para
poder realizar el transporte.
Acumuladores Estadísticos: Para conseguir medidas de los resultados o salidas
llevados a cabo, hay que hacer uso de varias variables que actúan como acumuladores
estadísticos conforme la simulación progresa, como pueden ser: el número de partes
producidas, el total de tiempo esperando en una cola, número de entidades que han
pasado a través 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, básicamente 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 estadísticos, como pueden ser: la llegada o
la salida del sistema de una entidad, el final de la simulación, etc. Para poder ejecutar,
una simulación debe seguir los eventos que se supone que ocurrirán en el futuro
(simulado). En Arena, esta información es guardada en un calendario de eventos.
Reloj de Simulación: El tiempo actual en la simulación es guardado en una variable
llamada Reloj de Simulación. 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 simulación dinámica (el reloj es una
variable llamada TNOW).
Comienzo y Parada: Una cuestión muy importante en la simulación es cómo empezar
y parar. Arena hace muchas cosas automáticamente, 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, cuánto debería durar la ejecución y
si se debería parar en un instante particular de tiempo o cuando ocurra algún suceso
específico. Estas decisiones pueden tener un gran efecto tanto en los resultados como en
las cosas más obvias como pueden ser los valores de los parámetros de entrada.
Página 90
Ventana de Arena
Arena es un lenguaje de simulación 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. Además, Arena es completamente
compatible con otros software de windows, como procesadores word, hojas de cálculo y
paquetes CAD. Para este proyecto se utilizará la versión 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)
Página 91
y Vista de la Hoja de Cálculo (Spreadsheet View). La otra región a tener en cuenta es la

Barra de Proyecto (Project Bar):
Vista del Organigrama: Contiene todos los gráficos del modelo, incluyendo el
organigrama del proceso, la animación y otros elementos de dibujo.
Vista de la Hoja de Cálculo: Muestra los datos del modelo, como tiempos, costes y
otros parámetros. Muchos parámetros del modelo pueden ser vistos y editados tanto en
la vista del organigrama como en la de la Hoja de Cálculo, pero esta última da el acceso
a mucho de los parámetros a la vez, ordenados en grupos compactos de parámetros
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 utilizarán. El primero de
los paneles es el Panel de Proceso Básico (Basic Process) que contiene los bloques de
construcción fundamentales para modelar, llamados módulos, que se usarán para definir
el organigrama del proceso de simulación.
Junto a éste se tienen dos paneles más, el Panel de Informes, que muestra los resultados
de una simulación tras ser ejecutada y el Panel de Navegación, el cual permite mostrar
diferentes vistas del modelo, incluyendo los distintos submodelos que pueda haber
dentro de un modelo jerárquico. Además del Panel de Proceso Básico, existen otros
paneles: el Panel de Proceso Avanzado (Advance Process) que contiene bloques de
construcción “más pequeños” para un modelado más 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 simulación de Bloques y
Elementos (los cuales juntos ofrecen acceso completo al SIMAN), que sustenta el
Arena. Aparte de éstos, existen otros paneles que contienen más construcciones para
aplicaciones especiales, como son el modelado de centros de llamadas o líneas de alta
velocidad de empaque.
Además de estas tres regiones principales, existen otras dos que también forman parte
de la ventana de Arena. La primera de ellas, situada en la parte más alta de la ventana,
está formada por varias Barras de Herramientas que facilitan un rápido acceso a
Página 92
actividades frecuentes. Por otro lado, en la parte inferior de la ventana, se tiene la Barra
de Estado, que muestra información sobre el estado de la simulación, como el valor del
reloj de la simulación durante la ejecución o el número de copias que están siendo y que
serán ejecutadas.
Llegados a este punto es importante hablar de los módulos del programa. Los módulos
se pueden considerar como los bloques básicos de construcción 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
básicos de módulos: los de organigramas y los de datos.
Los módulos de los organigramas definen los procesos dinámicos del modelo. Se
puede pensar en estos módulos como nodos o lugares a través de los cuales las
entidades fluyen, se originan o desaparecen del modelo. Los módulos de los
organigramas se suelen conectar unos con otros. En el panel del Proceso Básico, se
pueden encontrar los siguientes módulos:
Figura 5.5: Módulos del Proceso Básico
Página 93
Cada tipo de módulo de este panel tiene una forma distintiva. Pero en los otros dos
paneles se encuentran otro tipo de módulos representados todos por rectángulos. De esta
manera, los módulos del Proceso Avanzado son:
Figura 5.6: Módulos del Proceso Avanzado
En el Panel de Proceso de Traslado Avanzado se usan colores en los rectángulos para

distinguir los diferentes tipos de módulos.
Página 94
Figura 5.7: Módulos del Proceso de Traslado Avanzado
Los módulos de datos definen las características de varios elementos del proceso,
como entidades, recursos y colas. Pueden también actualizar variables y otro tipo de
valores numéricos y expresiones que pertenecen al modelo. Los iconos para estos
módulos en la Barra de Proyecto parecen una hoja de cálculo.
Los módulos del panel de Proceso Básico son: Entity (Entidad), Queue (Cola), Resource
(Recurso), Variable (Variable), Schedule (Programa) y Set (Conjunto). Los otros
paneles contienen tipos adicionales de módulos de datos: Expression (expresión),
Statistic (Estadística), Conveyor (Conveyor), Segment (Segmento), Distance
(Distancia), etc.
Tanto los módulos del organigrama como los de datos están relacionados mediante
nombres dados a objetos que tienen en común (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.
Página 95
Una vez obtenidos los conocimientos básicos del Arena, se puede comenzar a abordar la
simulación del problema definido en los capítulos anteriores.
Página 96
5.2 Aplicación de ARENA al problema
Tratamos de simular el proceso logístico, 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 logística de retorno con depósitos.
Existen dos depósitos intermedios de contenedores retornables adonde vuelven después
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 también podrían contemplarse como centros logísticos de distribución
suficientemente grandes como para poder evitar la problemática de la fabricación en
esta simulación.
Sólo habría, 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 número fijo desde el comienzo de
la simulación, contemplados como recursos compartidos.
El modelo diseñado bajo el software ARENA se compone de 3 partes fundamentales:
1. Los 4 Fabricantes
2. Los 10 Receptores
3. Los 2 depósitos
Se describen a continuación más detalles de cada uno de ellos:
1. Los 4 fabricantes, que crean el número exacto de entidades demandadas por los
receptores en su conjunto, como puede verse el la tabla 5.1, están formados por un
módulo de creación, otro de lotes para la agrupación de productos con objeto de
Página 97
completar los contenedores y otro de asignación de ciertos atributos interesantes para la

ejecución del programa, como el cambio del dibujo que representa a la entidad.
Entidades
Fabricantes creadas
1 5123
2 6324
3 5933
4 4660
En total 22040
Tabla 5.1 Entidades creadas.
Figura 5.8 Módulos de creación y de asignación.
A continuación, se coloca un módulo de decisión que se encarga de hacer el

reparto de los contenedores en función de la demanda correspondiente a cada receptor,
en porcentajes del total de productos creados por ese fabricante, según la tabla 5.2:
Página 98
Matriz Demanda receptores

Porcentual por
emisor 1 2 3 4 5 6 7 8 9 10
1 17 8 14 17 2 12 12 3 15 0 100
emisores
2 11 14 0 13 12 16 7 8 9 9 100
3 5 14 5 17 13 0 17 14 8 9 100
4 8 16 18 7 8 2 4 9 7 20 100
Tabla 5.2. Demanda porcentual
Figura 5.9 Módulo de reparto de demandas.
Seguidamente, en cada una de las ramificaciones, encontramos un módulo de solicitud

de recurso que creará una cola a la espera de que queden libres los contenedores de los
depósitos. Cabe mencionar que los emisores 1 y 2 solicitarán recurso sólo al depósito 1
y los emisores 3 y 4 harán lo propio con el depósito 2. Asociado a esta petición de
recurso se encuentra un tiempo de retraso que simula el tiempo invertido por el
contenedor en acudir desde el depósito solicitado al emisor solicitante. Tiempos
relacionados con los costes descritos en epígrafes 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:
Página 99
Tiempos Distribución Emisores

(Horas) 1 2 3 4
1 4,4 0,3 x x
Depósitos
2 x x 0,9 1,5
Tabla 5.3 Tiempos de distribución
Figura 5.10 Módulos de petición y de retraso asociado.
Finalmente, para acabar con la descripción de esta sección del modelo, nos encontramos
con un módulo de ruta, que envía las entidades a los receptores según unos retrasos
establecidos por la matriz de costes transformada, eso sí, en horas (dividiendo por 10),
por lo que tenemos:
Matriz Distancias receptores

de Envíos (horas) 1 2 3 4 5 6 7 8 9 10
1 8,6 3,5 7,6 1,6 4 7,8 0,9 4,7 9,1 2,8
emisores
2 1,5 6,5 7,9 7,9 4,6 3,7 5,8 2,1 6,2 0,4
3 0,7 0,2 6,7 6,7 1,5 3,7 1,8 5,5 8,7 2,4
4 3,8 7,6 8,3 0,9 1,3 2,5 5,9 3,4 0,8 6,6
Tabla 5.4 Distancias de envíos.
Página 100
Figuta 5.11 Módulo de ruta.
La vista que presenta esta sección bajo el entorno ARENA es la siguiente:
Página 101
Figura 5.12 Sección emisor del modelo.
Página 102
2. Los 10 Receptores. Formados inicialmente por un módulo estación que recibirá los
envíos hechos desde los emisores y un módulo de retraso que simulará el tiempo
invertido en la descarga, tiempo considerado constante de media hora para todos ellos.
A continuación se encuentre un módulo de separación 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, eliminándolas después de ser contadas, y por otro, las enviaremos por un
módulo ruta al depósito correspondiente que es el más cercano que se encuentre de cada
receptor, que corresponde con la siguiente tabla:
Tiempo Recuperación Depósitos

(Horas) 1 2
1 0,1 6
2 2,8 4,2
3 8,9 0,1
receptores
4 1,7 0,4
5 0,6 3,6
6 4,7 0,7
7 9,9 0,3
8 0,5 0,8
9 0,2 5,8
10 8,1 7,2
Tabla 5.5 Tiempos de recuperación.
Página 103
Figura 5.13 Módulos Estación y decisión.
Esta sección del modelo se representa así:
Figura 5.14 Vista de la sección receptor.
3. Los 2 depósitos. Los dos depósitos que mostraron ser los óptimos en el análisis
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
recolocación de contenedores.
Dichos depósitos se forman con un módulo de recepción, de tipo estación al que le
sigue una pregunta formulada al tipo de contenedor que se trate para poder distinguir
aquellos pertenecientes al depósito 1 o al 2 y facilitar así la recolocación de los mismos.
Esta recolocación, como hemos dicho, lleva asociada un retraso simulando en hecho
físico del transporte de contenedor. Seguidamente, los contenedores se ven sometidos a
Página 104
otro retraso que simula, esta vez, la limpieza y mantenimiento del mismo. Por último,
antes de su disposición/eliminación, realizamos la liberación 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 depósitos se representa así en el entorno ARENA:
Figura 5.14 Vista de la sección Depósitos.
Por tanto, la vista global del modelo de simulación se muestra a continuación:
Página 105
Figura 5.15 Vista general del modelo.
Repaso de algunas consideraciones hechas:

- Número fijo, por cada simulación, de contenedores retornables, hasta ajustar
tiempos necesarios para el reparto completo
- 2 depósitos de contenedores de capacidad limitada al número de recursos
disponibles.
- 10 productos por cada contenedor o camión, como quiera llamarse. Más correcto
sería decir camión-contenedor, porque se está suponiendo que el medio de
transporte es ese tipo de camión que sólo es capaz de acarrear un contenedor,
típicamente de 12 metros de longitud, como carga.
- La creación total, en número, del producto del fabricante 1, por ejemplo, es la
suma de las demandas mensuales de todas las superficies de venta.
- La simulación corre solo para un periodo de tiempo concreto: un mes, según los
datos disponibles-introducibles de demanda, es decir, sólo nos interesa el
resultado global del periodo total.
Página 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 simulación.
Página 107
5.3 Resultados de la simulación
Se trata de simular como se comporta el sistema, viendo fundamentalmente los tiempos

de ejecución, con la variación de un parámetro “p” que relaciona la demanda total con el
número de contenedores. Podemos hacer varias simulaciones en casos extremos del
parámetro para observar el comportamiento límite del modelo.
P= demanda de contenedores/ nº contenedores
El primer caso simulado contiene 44 contenedores y después de su simulación nos

ofrece un tiempo de reparto de 514 horas, que equivale a 21 días laborables trabajando
a 24 horas por día. No se ajusta a nuestro horizonte temporal de 1 mes, por poco, para
el cual hemos supuesto la demanda, por tanto, debemos disminuir en número de
contenedores. Como información, cabe decir que el parámetro “p” alcanza el valor,
previsiblemente inapropiado, de:
P= 2204/44 = 50,1
El segundo caso ensayado, con 40 contenedores, ofreció un tiempo total de ejecución de

569 horas, que significa, suponiendo que se reparte durante las 24 horas del día, un
horizonte temporal de 24 días. Si consideramos que sólo repartimos los días laborables,
tenemos que nuestro modelo, con 40 contenedores, reparte casi exactamente en el
tiempo previsto de 1 mes (22 días), con lo cual parece ser que nos hemos acercado al
número apropiado de contenedores y, lo que es más importante, a la relación del
parámetro “p”:
P = 2204 / 40 = 55,1
Página 108
Para afinar en nuestra búsqueda del óptimo, probamos ahora con 42 contenedores, 21 en
cada depósito, y simulamos. En este ensayo obtenemos que el tiempo de reparto es de
535 horas, que representa 22,3 días, horizonte temporal casi exacto a nuestro periodo
supuesto de demanda. El parámetro “p”, una vez redondeado en el sentido apropiado
para considerar 22 días, 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 depósito) el tiempo de reparto es de 11.370 horas (474 días),
caso extremo sin ninguna utilidad práctica.
También se ha realizado, como comprobación de la solidez del modelo, la simulación
para un número muy grande de contenedores, donde puede observarse que el tiempo de
reparto final sólo depende del proceso de transporte más 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 depósito
correspondiente, con todos los procesos incluidos de descarga, limpieza y
mantenimiento. Demuestra ser así un modelo coherente y robusto.
Por tanto, como observación fundamental de nuestra simulación, hemos obtenido que la
relación entre el número de contenedores y la demanda a satisfacer es de valor:
P= 53
Lo que significa que, dada una demanda determinada, siempre podremos saber qué
número de contenedores se ajusta al cumplimiento del tiempo de reparto necesitado, sin
más que dividir la demanda entre este valor del parámetro.
Página 109
Posibles mejoras y ampliaciones
La primera variante mejorada del modelo sería contemplar la posibilidad de distribución

de varios productos, añadiendo la creación, por parte de los fabricantes, de otras
entidades que tuvieran su correspondiente demanda asociada.
También podría contemplarse como factible la inclusión 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 podría ser la modificación del número de productos por contenedor, que
provocaría la definición de otro problema completamente diferente, ya que el parámetro
“p” se alejaría tanto del valor óptimo calculado como nos separásemos 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 ejecución se
reduciría y el parámetro “p” debería, forzosamente, ser notablemente inferior.
Pero estas mejoras no aportan complicaciones conceptuales al modelo simulado, tan

solo complejidad resoluble con suficiente capacidad de computación, 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 números que lo requerían, como
distancias simétricas y órdenes de magnitud semejantes.
En situaciones reales con datos extraídos 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 interpretación de nuestro problema, este ya más alejado de lo aquí inicialmente
considerado, es la posibilidad de distinguir otros medios de transporte que no sean el
Página 110
camión-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.
Página 111

Simulacion Arena

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Simulacion Arena

Enviado por

Direitos autorais:

Formatos disponíveis

PROYECTO FIN DE CARRERA

Sistemas con Logística de Retorno:

5. SIMULACIÓN DEL MODELO CON ARENA

“ Simulación es el proceso de diseñar un modelo de un sistema real y llevar a cabo

Cuando las capacidades y la sofisticación de los lenguajes y paquetes de simulación

de que la producción empezara. A finales de los 80, la utilidad de la simulación fue

Como ya se ha visto, la llegada del ordenador y su aplicación en simulación ha hecho

• Sistemas de servicios: admisión de hospitales, operaciones en ventanillas de bancos,

La aplicación de la simulación a sistemas tan diversos persigue unos objetivos que se

Figura 5.1: Simulación para el análisis de sistemas ya existentes.

Figura 5.2: Simulación del diseño de nuevos sistemas.

Con fines de educación o adiestramiento, para obtener experiencia en la toma de

Sistemas y Modelos en Simulación

La Simulación, como la mayoría de los métodos de análisis, implica el uso de sistemas

Definidos los modelos lógicos de simulación, se pueden clasificar en tres direcciones

Ventajas e inconvenientes de la Simulación

• Mayor y mejor comprensión de la realidad.

Etapas del proceso de Simulación

En la realización de un proyecto de simulación se pueden definir una serie de etapas que

Para llevar a cabo la ejecución de una simulación en el ordenador, se debe elegir el

• GPSS (General Purpose Simulation System), desarrollado por Geoffrey Gordeon en el

5.1 Características del software Arena

Arena es un lenguaje de programación cuya principal característica es la posibilidad de

Figura 5.3: Estructura Jerárquica del Arena

Conceptos básicos en Simulación con Arena

• Transporters: en este caso existe un número de vehículos encargados de realizar el

Arena es un lenguaje de simulación para ser utilizado en entorno Windows 95 o

Figura 5.4: Ventana de Arena

A la hora de modelar un proceso en Arena, se trabajará con tres regiones principales de

y Vista de la Hoja de Cálculo (Spreadsheet View). La otra región a tener en cuenta es la

Figura 5.5: Módulos del Proceso Básico

Figura 5.6: Módulos del Proceso Avanzado

En el Panel de Proceso de Traslado Avanzado se usan colores en los rectángulos para

Figura 5.7: Módulos del Proceso de Traslado Avanzado

5.2 Aplicación de ARENA al problema

Tratamos de simular el proceso logístico, usando contenedores retornables, que cubre la

El modelo diseñado bajo el software ARENA se compone de 3 partes fundamentales:

Se describen a continuación más detalles de cada uno de ellos:

completar los contenedores y otro de asignación de ciertos atributos interesantes para la

Tabla 5.1 Entidades creadas.

Figura 5.8 Módulos de creación y de asignación.

A continuación, se coloca un módulo de decisión que se encarga de hacer el

Matriz Demanda receptores

Tabla 5.2. Demanda porcentual

Figura 5.9 Módulo de reparto de demandas.

Seguidamente, en cada una de las ramificaciones, encontramos un módulo de solicitud

Tiempos Distribución Emisores

Tabla 5.3 Tiempos de distribución

Figura 5.10 Módulos de petición y de retraso asociado.

Matriz Distancias receptores

Tabla 5.4 Distancias de envíos.

Figuta 5.11 Módulo de ruta.

La vista que presenta esta sección bajo el entorno ARENA es la siguiente:

Figura 5.12 Sección emisor del modelo.

Tiempo Recuperación Depósitos

Tabla 5.5 Tiempos de recuperación.

Figura 5.13 Módulos Estación y decisión.

Esta sección del modelo se representa así:

Figura 5.14 Vista de la sección receptor.

Figura 5.14 Vista de la sección Depósitos.

Por tanto, la vista global del modelo de simulación se muestra a continuación:

Figura 5.15 Vista general del modelo.