Sistems

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.
Entidades
Fabricantes creadas
1 5123
2 6324
3 5933
4 4660
En total 22040
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 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 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 Emisores

(Horas) 1 2 3 4
Depsitos
1 4,4 0,3 x x
2 x x 0,9 1,5
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 receptores

de Envos (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 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 Depsitos

(Horas) 1 2
1 0,1 6
2 2,8 4,2
3 8,9 0,1
4
receptores
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 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

Sistems

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

Sistems

Cargado por

Copyright:

Formatos disponibles

PROYECTO FIN DE CARRERA

Sistemas con Logstica de Retorno:

5. SIMULACIN DEL MODELO CON ARENA

Simulacin es el proceso de disear un modelo de un sistema real y llevar a cabo

Cuando las capacidades y la sofisticacin de los lenguajes y paquetes de simulacin

de que la produccin empezara. A finales de los 80, la utilidad de la simulacin fue

Como ya se ha visto, la llegada del ordenador y su aplicacin en simulacin ha hecho

Sistemas de servicios: admisin de hospitales, operaciones en ventanillas de bancos,

La aplicacin de la simulacin a sistemas tan diversos persigue unos objetivos que se

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

Figura 5.2: Simulacin del diseo de nuevos sistemas.

Con fines de educacin o adiestramiento, para obtener experiencia en la toma de

Sistemas y Modelos en Simulacin

La Simulacin, como la mayora de los mtodos de anlisis, implica el uso de sistemas

Definidos los modelos lgicos de simulacin, se pueden clasificar en tres direcciones

Ventajas e inconvenientes de la Simulacin

Mayor y mejor comprensin de la realidad.

Etapas del proceso de Simulacin

En la realizacin de un proyecto de simulacin se pueden definir una serie de etapas que

Para llevar a cabo la ejecucin de una simulacin en el ordenador, se debe elegir el

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

5.1 Caractersticas del software Arena

Arena es un lenguaje de programacin cuya principal caracterstica es la posibilidad de

Figura 5.3: Estructura Jerrquica del Arena

Conceptos bsicos en Simulacin con Arena

En este apartado se definirn las distintas partes de un modelo de simulacin as como

Transporters: en este caso existe un nmero de vehculos encargados de realizar el

Arena es un lenguaje de simulacin 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 Clculo (Spreadsheet View). La otra regin a tener en cuenta es la

Figura 5.5: Mdulos del Proceso Bsico

Figura 5.6: Mdulos del Proceso Avanzado

En el Panel de Proceso de Traslado Avanzado se usan colores en los rectngulos para

Figura 5.7: Mdulos del Proceso de Traslado Avanzado

5.2 Aplicacin de ARENA al problema

Tratamos de simular el proceso logstico, usando contenedores retornables, que cubre la

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

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

completar los contenedores y otro de asignacin de ciertos atributos interesantes para la

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

Matriz Demanda receptores

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

Tiempos Distribucin Emisores

Tabla 5.3 Tiempos de distribucin

Figura 5.10 Mdulos de peticin y de retraso asociado.

Matriz Distancias receptores

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 Depsitos

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.