Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Simulacion Que Es para Que Sirve
Simulacion Que Es para Que Sirve
Qu es Simulacin?
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
Pgina 75
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
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
Pgina 79
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:
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
Pgina 84
Pgina 85
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.
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
Pgina 90
Ventana de Arena
Pgina 91
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:
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:
Pgina 94
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
1. Los 4 Fabricantes
2. Los 10 Receptores
3. Los 2 depsitos
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
Fabricantes
1
2
3
4
En total
Entidades
creadas
5123
6324
5933
4660
22040
Pgina 98
emisores
Matriz Demanda
Porcentual por
emisor
1
2
3
4
receptores
1
10
17
14
17
12
12
15
100
11
14
13
12
16
100
14
17
13
17
14
100
16
18
20
100
Pgina 99
Emisores
Tiempos Distribucin
(Horas)
1
2
Depsitos
4,4
0,3
0,9
1,5
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:
receptores
3
4
5
8,6
3,5
7,6
1,6
7,8
0,9
4,7
9,1
2,8
1,5
6,5
7,9
7,9
4,6
3,7
5,8
2,1
6,2
0,4
0,7
0,2
6,7
6,7
1,5
3,7
1,8
5,5
8,7
2,4
3,8
7,6
8,3
0,9
1,3
2,5
5,9
3,4
0,8
6,6
Matriz Distancias
emisores
de Envos (horas)
1
2
3
4
10
Pgina 100
Pgina 101
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
receptores
(Horas)
1
2
3
4
5
6
7
8
9
10
Depsitos
0,1
2,8
4,2
8,9
0,1
1,7
0,4
0,6
3,6
4,7
0,7
9,9
0,3
0,5
0,8
0,2
5,8
8,1
7,2
Pgina 103
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:
Pgina 105
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
Pgina 107
P= 2204/44 = 50,1
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
Pgina 110
Pgina 111