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.

Fabricantes Entidades 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 1002 11 14 0 13 12 16 7 8 9 9 1003 5 14 5 17 13 0 17 14 8 9 100

emis

ores

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

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

emis

ores

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

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

rece

ptor

es

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

Documents