Diseno e Implementacion de ProcesamientosComputacionales para el Desarrollo de un
Software de Simulacion de Eventos DiscretosOrientado al Analisis RAM de Sistemas
Industriales
AutoresCristhian Ignacio Silva Cartagena
Juan David Zorrilla Herrera
Universidad Distrital Francisco Jose de Caldas
Facultad de IngenierıaProyecto Curricular de Ingenierıa Electronica
Carrera 8 # 40-62Bogota D.C.
2018
Diseno e Implementacion de ProcesamientosComputacionales para el Desarrollo de un
Software de Simulacion de Eventos DiscretosOrientado al Analisis RAM de Sistemas
Industriales
AutoresCristhian Ignacio Silva Cartagena
Juan David Zorrilla Herrera
DirectoresDiana Marcela Ovalle Martinez
PhD en Tecnologıas Industriales
Jorge Edison Granada JimenezEspecialista Senior en Gestion de Activos y Confiabilidad
Trabajo de GradoPasantıa desarrollado en la Empresa
KNOWLEDGE AND INTEGRATION ARCHITECTS (KNAR)
Universidad Distrital Francisco Jose de CaldasFacultad de Ingenierıa
Proyecto Curricular de Ingenierıa ElectronicaCarrera 8 # 40-62
Bogota D.C.2018
Contenido
Lista de Figuras VII
Lista de Tablas XI
1. Resumen Ejecutivo 1
1.1. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2. Objetivos Especıficos . . . . . . . . . . . . . . . . . . . 4
2. Descripcion y Analisis de Resultados 5
2.1. Eleccion del lenguaje de programacion . . . . . . . . . . . . . . . 5
2.2. Netflix en Julia y Matlab . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Disminucion de tiempo de ejecucion . . . . . . . . . . . . . . . . . 13
2.4. Estructuracion de los equipos de trabajo . . . . . . . . . . . . . . 24
2.5. Diseno e implementacion de la Operacion OR . . . . . . . . . . . 28
2.6. Computo paralelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.7. Acople con el primer modelador . . . . . . . . . . . . . . . . . . . 32
2.8. Integracion de maquinas . . . . . . . . . . . . . . . . . . . . . . . 49
2.9. Implementacion de Sistema en serie . . . . . . . . . . . . . . . . . 51
2.10. Algoritmo de sitonizacion de mantenimientos . . . . . . . . . . . . 58
2.11. Paralelizacion para equipos en serie . . . . . . . . . . . . . . . . . 59
3. Evaluacion de Objetivos 71
Conclusiones 75
Bibliografıa 77
Lista de Figuras
2.1. Comparacion en desempeno con C de diferentes lenguajes de pro-
gramacion [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Servicio dado por un sistema compuesto por dos equipos en serie . 10
2.3. Diseno del algoritmo para el servicio Netflix . . . . . . . . . . . . 12
2.4. Curva de costos en funcion del periodo de mantenimiento . . . . . 23
2.5. Comparacion de los tiempos de ejecucion utilizando las herramien-
tas de paralelizacion . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6. IDEF0 del proceso global . . . . . . . . . . . . . . . . . . . . . . . 25
2.7. Diagrama IDEF0 de las diferentes etapas del proyecto . . . . . . . 26
2.8. Diagrama IDEF0 del Proceso de Simulacion . . . . . . . . . . . . 27
2.9. Diagrama IDEF0 del Proceso de Computacion Paralela . . . . . . 28
2.10. Distribucion de las ocurrencias de los eventos en una lınea de tiempo 29
2.11. Diseno general de primera aproximacion de solucion donde se con-
sideraban las ocurrencias (y duraciones) de los eventos, analizando
la no disponibilidad ocasionada por estos . . . . . . . . . . . . . . 31
2.12. Tipos de solapamiento entre eventos donde (de izquierda a derecha
y de arriba a bajo) se tiene: (1) Solapamiento Total, (2) Solapa-
miento Parcial, y (3) Solapamiento de Contencion . . . . . . . . . 32
2.13. Modelos de la Taxonomıa de Flynn para (a) Single Instruction Sin-
gle Data Stream, (b) Single Instruction Multiple Data Stream, (c)
Multiple Instruction Single Data Stream y (d) Multiple Instruction
Multiple Data Stream . . . . . . . . . . . . . . . . . . . . . . . . 34
2.14. Herramienta de Pronostico de NPT . . . . . . . . . . . . . . . . . 37
2.15. Jerarquıa del proceso donde en (a) se visualiza un diagrama de
arbol referente al proceso industrial, mientras en (b) se plantean
la serie de vistas que tienen lugar en el mismo . . . . . . . . . . . 38
viii LISTA DE FIGURAS
2.16. interfaz grafica de usuario de Herramienta de Pronostico de NPT
donde en (a) se visualiza la configuracion para el registro de cada
elemento, mientras en (b) se muestra la configuracion de la simu-
lacion final junto con los elementos a ser procesados . . . . . . . . 40
2.17. Diagrama general de segunda aproximacion de algoritmo de proce-
samiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.18. Diagrama de flujo respecto al calculo de costos mediante el proceso
de Montecarlo haciendo uso de la Simulacion de Eventos Discretos
(Parte 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.19. Diagrama de flujo respecto al calculo de costos mediante el proceso
de Montecarlo haciendo uso de la Simulacion de Eventos Discretos
(Parte 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.20. Histograma de base para el calculo de P-maximo, P-mınimo y P-
medio, segun el intervalo de confianza . . . . . . . . . . . . . . . . 44
2.21. Curva de Falla y Mantenimiento donde se obtiene el costo segun el
lapso en las ocurrencias de los mantenimientos . . . . . . . . . . . 46
2.22. Costo Total del sistema considerando en (a) una idealizacion mien-
tras en (b) un resultado mas proximo a la realidad . . . . . . . . 47
2.23. Costo del sistema en funcion de la sintonizacion de dos manteni-
mientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.24. Primer Resultado obtenido de la sintonizacion de periodos de man-
tenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.25. Diagrama de procesos para la implementacion de SSH . . . . . . . 50
2.26. Logo modelador LogicProcessLanguage . . . . . . . . . . . . . . . 51
2.27. Vista de Proceso de modelador LPL . . . . . . . . . . . . . . . . . 52
2.28. Vista de Sistema de modelador LPL . . . . . . . . . . . . . . . . . 52
2.29. Vista de Equipo de modelador LPL . . . . . . . . . . . . . . . . . 52
2.30. Tercer Diseno para procesamiento de equipos en serie con capaci-
dades binarias (Parte 1) . . . . . . . . . . . . . . . . . . . . . . . 55
2.31. Tercer Diseno para procesamiento de equipos en serie con capaci-
dades binarias (Parte 2) . . . . . . . . . . . . . . . . . . . . . . . 56
2.32. Ilustracion de la linea de tiempo con las caracterısticas utilizadas
para su construccion segun tercer diseno . . . . . . . . . . . . . . 57
2.33. Relacion entre histograma resultado de proceso de Montecarlo e
ındices del intervalo de confianza . . . . . . . . . . . . . . . . . . 57
2.34. Estructura interna del proceso correspondiente al Sistema No.1 . . 58
2.35. Estructura interna del proceso correspondiente al Sistema No.2 . . 59
Lista de Figuras ix
2.36. Estructura interna del proceso correspondiente al Sistema No.3 . . 59
2.37. Graficas de costo de mantenimiento y costo de falla debidas a la
sintonizacion de periodos de mantenimiento para un sistema pre-
viamente configurado . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.38. Grafica de Costo Total debida a la sintonizacion de periodos de
mantenimiento para un sistema previamente configurado . . . . . 60
2.39. Periodos de mantenimiento sugeridos para los diferentes grupos de-
finidos por el usuario en el modelador . . . . . . . . . . . . . . . . 61
2.40. Costos asociados a las sintonizaciones llevadas a cabo para cada
uno de los grupos definidos, el primer resultado (izquierda) corres-
ponde a los costos originales del sistema, mientras a medida de
se sintonizan los grupos de mantenimiento hasta el ultimo resulta-
do (derecha) se tienen los costos respectivos de la sintonizacion de
todos los grupos de mantenimiento . . . . . . . . . . . . . . . . . 61
2.41. Algoritmo Computacional sin paralelizacion . . . . . . . . . . . . 63
2.42. Estructura para Sistema sin paralelizar . . . . . . . . . . . . . . . 63
2.43. Estructura para Sistema Paralelizando el bucle de iteraciones con
4 Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.44. Estructura para Sistema Paralelizando el bucle de iteraciones con
7 Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.45. Estructura para Sistema Paralelizando con Canales Remotos y con
4 Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.46. Estructura para Sistema Paralelizando con Canales Remotos y con
7 Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.47. Estructura para Sistema Paralelizando con Canales Remotos y @Pa-
rallel con 4 Procesos . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.48. Estructura para Sistema Paralelizando con Canales Remotos y @Pa-
rallel con 7 Procesos . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.49. Comparaciones de tiempo por metodos de paralelizacion respecto
a Simulacion no-paralelizada . . . . . . . . . . . . . . . . . . . . . 68
2.50. Comparaciones de memoria RAM por metodos de paralelizacion
respecto a Simulacion no-paralelizada . . . . . . . . . . . . . . . . 69
Lista de Tablas
2.1. Trabajos y objetivos asociados para el correcto desarrollo del pro-
yecto de grado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Especificaciones de lenguajes de programacion . . . . . . . . . . . 8
2.3. Caracterısticas del computador en el que se ejecuto el programa
para la toma de tiempo . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Tiempo promedio de corrida y dificultad de implementacion del
programa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Taxonomıas de Flynn . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6. Herramientas de Julia para paralelizacion . . . . . . . . . . . . . . 35
2.7. Objetos a utilizar, la forma en que los recopila el modelador y su
aplicacion y objetivo en la simulacion . . . . . . . . . . . . . . . . 53
Capıtulo 1
Resumen Ejecutivo
Los sistemas industriales han presentado un gran impacto en el desarrollo de las
sociedades, llevandolas a nuevos escenarios en cultura, ciencia y tecnologıa. Su
implementacion es de alta complejidad y sus beneficios garantizan una mejor ca-
lidad de los productos ofrecidos, mejoran el proceso de produccion e incrementan
la competitividad entre las empresas en el mercado. Sin embargo, es importante
considerar que al momento de implementar un sistema industrial se debera tener
en cuenta el analisis de su confiabilidad, disponibilidad y mantenibilidad conocido
como Analisis RAM (por sus siglas en ingles: Reliability, Availability, Maintai-
nability), el cual permite la gestion apropiada de los recursos que conforman el
sistema, su adecuado manejo y el mejor aprovechamiento que se puede extraer
de estos basados en datos cuantitativamente significativos para el desarrollo del
proceso.
El concepto de Analisis RAM ha sido desarrollado progresiva y principalmente
en el sector de Control de Calidad de Productos y Servicios. En el campo de la
ingenierıa, se presta mucha atencion en el aspecto de lo que ”debe ser logrado”,
mas no en lo que ”debe ser asegurado”dado el caso que criterios de diseno no sean
tomados en cuenta, por ello este analisis constituye una metodologıa que asegura
un buen diseno ingenieril con la integridad deseada [2].
Este Analisis RAM es brindado por empresas de consultorıa, que a traves de di-
ferentes herramientas, presentan un servicio profesional sobre la gestion de los
recursos industriales utilizados por las empresas que conforman este sector.
Knowledge and Integration Architects (KNAR SAS) es una empresa colombiana
2 1 ResumenEjecutivo
con mas de 10 anos de experiencia en el desarrollo de servicios de analisis de ries-
gos, y dedicada al prestar consultorıa por Analisis RAM principalmente orientado
a la industria y al sector aeronautico [3]. Una meta propuesta por KNAR SAS
es la de desarrollar aplicaciones producto de la ingenierıa colombiana, y de esta
manera retomar el objetivo que esta misma empresa lleva como insignia, de desa-
rrollar ciencia y tecnologıa aplicable al sector, en este caso, industrial.
Una limitacion que presenta el servicio prestado por KNAR SAS en el sector
industrial hace referencia al los soportes computacionales utilizados para el desa-
rrollo de analisis basados en sistemas de simulacion por eventos discretos que,
aunque poseen alta complejidad y efectividad para el tratamiento de los datos,
poseen bajos rendimientos en tiempo de procesamiento computacional, poca fle-
xibilidad y moderado consumo de recursos.
El mercado ya posee herramientas orientadas al Analisis RAM y su aplicacion en
la industria para ser apoyo en la consultorıa de empresas, entre ellas, el software
principal es denominado Taro y esta desarrollado por dos empresas: La Norue-
ga Det Norske Veritas, y la Alemana Germanischer Lloyd. Juntas (DNV-GL)
desarrollaron un software capaz de modelar el proceso Downstream del petroleo
y gas (Refinamiento, procesamiento y purificacion), tomando decisiones optimas
en diseno, operacion y mantenimiento, teniendo en cuenta datos de analisis de
desempeno. Datos base como balance de masa, configuracion de diseno y datos
de confiabilidad, son integrados en procesos abstractos que dan lugar a altamen-
te precisas predicciones de desempeno, permitiendo evaluar diferentes escenarios
para lograr ası el comportamiento optimo del sistema [4].
Aunque siendo el mejor software para desarrollar dicho analisis, Taro posee las
complicaciones ya mencionadas previamente. Surge entonces la interrogante de si
¿es posible desarrollar una herramienta de apoyo al analisis RAM que reduzca sig-
nificativamente el tiempo de procesamiento, posea mayor flexibilidad, y conlleve
a bajos costos, desarrollada en Colombia y pensada para su industria?.
1.1. Justificacion
Actualmente en el mercado existen software que ejecutan el proceso de analisis
de confiabilidad, disponibilidad y mantenibilidad pero presentan dificultades en
1.1 Justificacion 3
el tiempo de procesamiento, la flexibilidad y los costos, directos e indirectos, de
su uso, por lo cual, para una empresa que necesite tomar una decision confiable
y rapida, es importante poseer una herramienta que brinde una solucion a estos
inconvenientes.
El concepto de ingenierıa en Colombia ha decaıdo a un punto en el que la mano
de obra extranjera, ası como la produccion en ciencia y tecnologıa, son suficientes
para el mercado local, haciendo de la labor del ingeniero en la Nacion una labor
de administracion y de poca aplicacion de su area de estudio. Segun el Observa-
torio de Economıa Digital, en 2017 las empresas grandes en el paıs presentaron
una penetracion muy baja de Internet de las Cosas (14, 8 %), robotica (11, 1 %),
impresoras 3D (4, 8 %), realidad virtual (1, 7 %), Big Data (16, 8 %) e Inteligencia
Artificial (9, 7 %), lo que demuestra que estas tecnologıas estan muy rezagadas en
su adopcion en Colombia [5], es por ello que se desea desarrollar tecnologıa que
pueda posiblemente competir a nivel global y que presente la misma, o superior,
calidad que el desarrollo extranjero.
Una empresa de consultorıa, para dar solucion a un problema planteado por un
sector del mercado, necesita realizar un analisis RAM por medio de diferentes
herramientas, las cuales determinan una solucion apropiada. Debido al tiempo
consumido en el desarrollo del procesamiento para el posterior analisis de con-
fiabilidad, disponibilidad y mantenibilidad, se requiere de un alto consumo de
energıa el cual es de gran impacto para el medio ambiente.
De acuerdo con un estudio de la empresa XM, filial de la estatal Interconexion
Electrica S.A (ISA), entre julio de 2011 y junio de 2012 la demanda de energıa
electrica crecio 3,1 por ciento, mientras que en los primeros seis meses de 2012
registro un crecimiento de 2,7 por ciento. Igualmente, segun EPM, una persona
promedio usa 38KWh, que corresponde a un gasto excesivo y poco responsable
de la energıa electrica [6]. La solucion propuesta disminuirıa significativamente el
tiempo de procesamiento, y por ende el consumo energetico.
Ası mismo, los trabajos ofertados para un ingeniero electronico en el mercado
colombiano estan orientados al area de telecomunicaciones, en donde el ambito
de trabajo limita la labor hacia un aspecto tecnico mas no ingenieril. En KNAR
SAS se brinda la oportunidad de aplicar la ingenierıa y de innovar en el sector
industrial con alternativas tecnologicas que desarrollan la mentalidad profesional
y la experiencia laboral propias de un ingeniero.
4 1 ResumenEjecutivo
1.2. Objetivos
Para el desarrollo de la pasantıa se propusieron los siguientes objetivos como metas
a alcanzar al momento de la culminacion de la misma.
1.2.1. Objetivo General
Desarrollar algoritmos para el procesamiento computacional remoto, como parte
integral de un simulador de eventos discretos de sistemas industriales, utilizando
tecnicas de programacion que permitan mejoras en tiempos de procesamiento en
comparacion a los que presentan programas comerciales con la misma utilidad.
1.2.2. Objetivos Especıficos
Seleccionar un lenguaje de programacion orientado al computo paralelo, de
tal manera que este pueda desarrollar el procesamiento pertinente de una
forma eficiente.
Desarrollar una integracion entre maquinas a traves de servicios web, como
SSH o aplicativos web, con el fin de que el procesamiento computacional
pueda ser desarrollado en servidores remotos dedicados.
Seleccionar la o las arquitecturas de programacion que permitan hacer un
procesamiento computacional eficiente en las operaciones propias del simu-
lador de eventos discretos.
Comparar los tiempos de procesamiento en los programas existentes con los
obtenidos como resultado del computo paralelo implementado en el lenguaje
seleccionado, con el fin de hacer un analisis de eficiencia para ası identificar
fortalezas y debilidades de las diferentes estrategias implementadas.
Capıtulo 2
Descripcion y Analisis de
Resultados
Para lograr el cumplimiento de los objetivos del proyecto de grado se plantearon
los siguientes trabajos, los cuales se organizaron segun su planteamiento, desarro-
llo e implementacion. Los objetivos de cada trabajo se detallan en la Tabla 2.1.
Las descripciones del desarrollo de cada trabajo se enumeran a continuacion, ha-
ciendo enfasis en los resultados, productos, alcances e impactos obtenidos.
2.1. Eleccion de Julia como lenguaje de progra-
macion a usar
El desarrollo de prototipos, en el aspecto de software y desarrollo de aplicaciones
sobre este medio, es un problema que necesita de un lenguaje de alto-nivel, facil
de usar y flexible, que brinde al desarrollador las habilidades de concentrar los
esfuerzos hacia la solucion de dicha labor, en vez de dedicarse a detalles de bajo-
nivel y de computacion.
Un desarrollador esta habituado a usar lenguajes costosos o interpretados con
decadas de creacion, para expresar un problema a un alto-nivel, pero cuando sur-
ge la necesidad de desarrollar programas sensibles al desempeno, con computos
rapidos y efectivos, el desarrollador debe hacer uso de lenguajes compilados (C,
Fortran) o incluso codigo de ensamblador [7].
6 2 Descripcion y Analisis de Resultados
Tabla 2.1: Trabajos y objetivos asociados para el correcto desarrollo del proyecto
de grado
Trabajo Objetivo del trabajo
0Introduccion en la dinamica de la pasantıa y eleccion del Lenguaje de
Programacion a usar
1Inmersion en el area de trabajo de KNAR RAM y de la codificacion
en Julia
2Conocimiento de herramientas de Julia brindadas hacia la paraleliza-
cion de procesos computacionales
3Estructuracion del equipo de trabajo con apoyos graficos de negocios
organizacionales
4Primera aproximacion algorıtmica para la Simulacion de Eventos Dis-
cretos
5Exploracion y pruebas de teorıa de paralelizacion segun el estudio de
las taxonomıas existentes
6 Integracion de interfaz grafica preliminar con computo remoto
7Procesamiento y sintonizacion para de un sistema industrial con equi-
pos en serie y acople con interfaz grafica
8 Paralelizacion con CPU
El desarrollo del aplicativo que dara solucion al problema planteado por la empresa
KNAR SAS presenta este inconveniente, donde la brecha entre un alto-nivel y un
bajo-nivel, junto con el aprovechamiento coherente de la capacidad de computo,
seran un reto que debera ser solventado para brindar una alta calidad al aplicativo
desarrollado.
Se presentan entonces tres grandes aspectos que deben brindar un apoyo a dicha
meta a alcanzar, para ello se plantea abordar cada uno de estos items conside-
rando las diferentes caracterısticas, las cuales llevaran a un objetivo globalmente
coherente:
Tiempo de procesamiento Computacional:
Gran parte del tiempo de procesamiento es debido a que la carga compu-
tacional no es soportada por un sistema fısico, ello representa un inconve-
niente que se asume constante ya que el lenguaje de programacion debera
contar con las herramientas que faciliten una manipulacion de las especifica-
2.1 Eleccion del lenguaje de programacion 7
ciones tecnicas de la maquina. Esto lleva a la posibilidad de poder utilizar un
computo paralelo entre nucleos, procesadores centrales, procesadores grafi-
cos, entre otros.
Consumo de memoria:
La memoria implica un gran reto, esto es debido a que los datos a procesar
corresponderan a analisis estadısticos con bases de datos de tamanos consi-
derablemente4 grandes, ello ademas de las complejos sistemas a simular que
incrementaran la carga computacional, y significaran mas memoria. El uso
de los recursos tecnicos de hardware de manera apropiada y efectiva permi-
tira repartir la memoria y su procesamiento de manera versatil, llevando a
un consumo bajo respecto a alto procesamiento de datos.
Flexibilidad:
Gran variedad de lenguajes de programacion pueden ser utiles para el desa-
rrollo de una aplicacion que cumpla con los requerimientos planteados, sin
embargo la versatilidad, facilidad y eficiencia que estas pueden ofrecer varia
en gran medida considerando los diferentes niveles de implementacion y abs-
traccion, ello podrıa significar un importante punto de comparacion entre
las diferentes alternativas.
Teniendo un analisis detallado, y por consejo del director interno de pasantıa, se
procede a analizar el lenguaje de programacion Julia y compararlo con otros para
el mismo fin.
Respecto al primer item, la pagina web oficial del Julia realiza dicha comparacion
haciendo uso de Micro-Benchmarks (pruebas algorıtmicas identicas entre lengua-
jes) [1] donde evalua diferentes metodos repetitivos o de alta carga computacional,
para diferentes lenguajes incluyendo a Julia mismo. Las especificaciones de estos
lenguajes se muestran en la Tabla 2.2.
Teniendo como base C, la Figura 2.1 realiza las comparaciones respectivas entre
los diferentes lenguajes respecto a desempeno de C, ello debido a que este ultimo
trabajan a la mas alta rapidez.
Con base en el segundo item, Julia fue disenado desde el principio para un alto
desempeno computacional. Principalmente se encuentra la paralelizacion de pro-
cesos, la cual permite el desarrollo de diferentes algoritmos computacionales de
8 2 Descripcion y Analisis de Resultados
Tabla 2.2: Especificaciones de lenguajes de programacion
Lenguaje Especificaciones
Juliav1.0.0
OpenBLAS v0.2.20
SciLuav1.0.0-b12
OpenBLAS v0.2.20
Rust 1.27.0
Go1.9
OpenBLAS v0.2.20
Java 1.8.0-17
Javascript V8 6.2.414.54
Matlab R2018a
Anaconda Python
3.6.3
OpenBLAS v0.2.20
NumPy v1.14.0
R 3.5.0
Octave4.2.2
OpenBLAS v0.2.20
C and Fortrangcc 7.3.1
OpenBLAS v0.2.20
Mathematica Intel(R) MKL
acuerdo a arquitecturas definidas de computo paralelo, dichas arquitecturas per-
miten la distribucion adecuada de la memoria del sistema para su bajo consumo
y apropiacion efectiva [8].
Finalmente, la programacion en Julia permite a un desarrollador la posibilidad
de escribir codigo de alto desempeno haciendo uso de los recursos de CPU y de
memoria de una manera tan efectiva como al ser desarrollado en C, pero traba-
jando Julia puramente. Ası mismo hace uso de entornos con gran velocidad y
capacidad como lo son las tecnologıas de compilacion Low Level Virtual Machine
- Just in Time (LLVM JIT) (coleccion de tecnologıas y compiladores modulares
y reutilizables para Frontends y Backends) [7].
2.2 Netflix en Julia y Matlab 9
Figura 2.1: Comparacion en desempeno con C de diferentes lenguajes de progra-
macion [1]
2.2. Modelamiento del comportamiento del ser-
vicio de Netflix en Julia y Matlab (version
Academica)
Para la inmersion en el area de trabajo de KNAR se planteo un problema que tie-
ne por objetivo dar a conocer aquellos conceptos importantes los cuales se usaran
a lo largo del desarrollo de la pasantıa.
El problema consistio en encontrar durante un ano la disponibilidad de un servi-
cio prestado por Netflix, compuesto por dos equipos en serie que corresponden a
Internet y a la Red Electrica como se muestra en la Figura 2.2. Cada equipo posee
unos sucesos durante el ano llamados Fallas los cuales poseen una Ocurrencia y
una Duracion que son modeladas por funciones de probabilidad. Estos sucesos
generan un Time-Out al servicio prestado por Netflix.
10 2 Descripcion y Analisis de Resultados
Figura 2.2: Servicio dado por un sistema compuesto por dos equipos en serie
Para el desarrollo del problema planteado por la empresa se debio usar como len-
guaje de programacion Julia y Matlab con el objetivo de realizar una comparacion
usando como criterio el tiempo de ejecucion del algoritmo disenado.
El proceso para solucionar el problema siguiendo las instrucciones dadas fue en
primer lugar identificar aquellos conceptos que componen el problema a tratar,
una vez identificados los conceptos y palabras claves se crea un diseno en donde
se plasmara el algoritmo por medio de un diagrama de flujo, generando de esta
manera independencia al lenguaje de programacion; por ultimo se implementa
el diseno en los lenguajes respectivos teniendo como criterio al momento del la
programacion la facilidad de implementacion y el tiempo de ejecucion del mismo.
Siguiendo el plan de trabajo, los conceptos y palabras claves para entender el
problema son:
Suceso: denominado Falla, es aquello que ocurre cada cierto tiempo y posee
una duracion. Cada equipo tendra una serie de sucesos generando un Time-
Out al servicio.
Ocurrencia: modelado por una funcion de probabilidad, modela cada cuan-
to ocurrira un suceso, este ıtem esta relacionado directamente con una linea
de tiempo porque en ella ubica cada suceso
Duracion: Modelado por una funcion de probabilidad, modela cuanto dura
un suceso, este ıtem esta relacionado directamente con un Time-Out
Linea de Tiempo: permite ordenar una secuencia de sucesos o de eventos,
de tal forma que se visualice con claridad la relacion temporal entre ellos.
Time-Out: es la cantidad de tiempo en que el sistema estuvo fuera de
servicio causado por la duracion de un suceso.
Tiempo de Simulacion: momento indicado en la linea de tiempo en donde
no se realizan mas calculos.
2.2 Netflix en Julia y Matlab 11
Tabla 2.3: Caracterısticas del computador en el que se ejecuto el programa para
la toma de tiempo
Caracterıstica Valor
Marca y Modelo ASUS N56VZ
ProcesadorIntel(R) Core(TM) i7-3630QM CPU @ 2.40GHz, 2401
Mhz, 4 procesadores principales, 8 procesadores logicos
RAM Instalada 8.00 GB
Tipo de Sistema x64-based PC
Sistema Operativo Ubuntu 18.04
Tabla 2.4: Tiempo promedio de corrida y dificultad de implementacion del pro-
grama.
Herramienta de
software
Tiempo
Promedio
Dificultad de
implementacion
Matlab 2017 Version
Academica870.64 s Media
Julia v0.6.4 14.08 s Baja
Conociendo los conceptos y palabras claves que componen el problema a tratar se
procede a realizar el diseno evidenciado en la Figura 2.3.
Con el diseno verificado con pruebas de escritorio, se procedio a la codificacion
en los lenguajes de programacion Julia y Matlab en donde se evaluaron criterios
dichos en el enunciado (Tiempo y facilidad de implementacion).
Para la toma de tiempo, se ejecuto el programa disenado en un computador con
las caracterısticas mostradas en la Tabla 2.3.
Obteniendo el tiempo promedio de corrida de 14 muestras y su respectiva dificul-
tad de implementacion, mostrados en la Tabla 2.4.
La familiarizacion con la sintaxis y con las ventajas que ofrece el lenguaje JULIA
en aspectos como Tiempo de ejecucion y Facilidad de implementacion otorgo re-
cursos necesarios para el cumplimiento de los objetivos de la pasantıa. De igual
manera las primeras aproximaciones a la tecnica informatica de Simulacion de
Eventos Discretos (SED) aporto conceptos claves para el diseno de algoritmos de
12 2 Descripcion y Analisis de Resultados
Figura 2.3: Diseno del algoritmo para el servicio Netflix
2.3 Disminucion de tiempo de ejecucion 13
encolamiento y optimizacion.
Se agrego un criterio nuevo al momento de disenar un programa el cual consiste
en visualizar el tiempo de ejecucion de este.
2.3. Disminucion de tiempo de ejecucion para
Sintonizacion de periodo de mantenimiento
a traves de computo paralelo
El segundo trabajo entregable planteado en la pasantıa tiene por objetivo explorar
aquellas herramientas existentes para el computo paralelo brindadas por JULIA
con el unico fin de disminuir el tiempo de ejecucion de un programa o algoritmo.
Para este entregable se otorgo como recurso base el algoritmo Sintonizador de
periodo de mantenimiento de un equipo previamente disenado, el cual por medio
de alguna tecnica, funcion o taxonomıa de paralelizacion se logre una disminucion
en su tiempo ejecucion. El tiempo promedio por corrida de forma secuencial es de
80.56 segundos.
El proceso para realizar este entregable fue en primer lugar tener un completo
entendimiento del flujo de datos, de los diferentes bucles y las variables usadas
en el programa brindado por la empresa. Una vez comprendido la estructura del
algoritmo se procede a investigar las herramientas orientadas a la paralelizacion
brindadas por Julia para de esta forma, poder generar el diseno e implementacion
de un codigo que reduzca el tiempo de ejecucion.
El codigo brindado por la empresa esta dividido en tres secciones mostradas en
los Codigos 2.1-2.3.
us ing PyPlot
# Functions d e f i n i t i o n
func t i on genNextTTF( pDist : : Str ing , param1 : : Float64 , param2 : : Float64 ,
pverbose : : Int ) : : Float64
i f pDist==”W”
eta= param1
beta=param2
F = rand ( )
14 2 Descripcion y Analisis de Resultados
B= (1−F)B = 1/(B)
i f B>0
B = log (B)
e l s e
B=1/ log (−1∗B)
end
TTFi=eta ∗Bˆ(1/ beta )
i f pverbose>=3
p r i n t l n ( ”TTF gen ” , TTFi)
end
return TTFi
e l s e
re turn 10 .0
end
end
#START
#InitRUN
## Set Values
##COST: Costs In t eg e r Cost .
CF=6 #INPUT: Fa i l u r e Cost .
CPpm=1 #INPUT: Per i od i c Prevent ive Maintenance
Ind i v i dua l i n s t ance co s t .
## TIME: Time Var iab l e s
LcT=600.0 # INPUT: Duration o f a l i f e c y c l e .
Expressed in Months f o r convenience .
CurrentSimTime=0.0 # This ho lds the Current s imulated
time f o r c on t r o l i n g when the s imu la t i on time f o r a cy c l e i s over .
## LIMITS : Those numbers/amounts that c on t r o l and l im i t de s imu la t i on
proce s s
NLcSim x i PpmT=100 # INPUT: De f ine s the number o f C i f e
Cycle s imu la t i on s f o r each PpmT to a s s e s s .
CiPct=97 # INPUT: De f ine s the Conf idence
I n t e r v a l d e s i r ed
HGCfg=”Fast ” # INPUT: De f ine s t
GType=”Smooth” # INPUT: Raw/Smooth : De f ine s when to
apply moving avergage be f o r e producing the graph
## TYPE OF: Serves a l l the c l a s s i f i e r s used ac ro s s the app
TypeOfLastEvent=”” # A s t r i n g that can be con f i gu r ed as ”
F” f o r Fa i l u r e or Ppm f o r Pe r i od i c Prevent ive Maintenance .
TypeOfProbDist=”W” # A s t r i n g that can be con f i gu r ed as ”
W” f o r Weibull D i s t r i bu t i on . ( Further v e r s i on s w i l l i n c lude other
types )
## COUNTERS: I n t e r g e r Counters o f ocur r ence s
AccFCount=0 # Accounts f o r the Fa i l u r e s ocurred
2.3 Disminucion de tiempo de ejecucion 15
during a LcSim
AccPpmCount=0 # Accounts f o r the Ppm ocur rence s
during a LcSim
## VECTORS and VECTOR INDEXES: De f ines s e t s o f data
PpmT Step=0.01
PpmT Set= c o l l e c t ( 1 : PpmT Step : 8 0 . 0 )# INPUT: Containes the Per iods o f
p revent ive maintenance (Months ) to t ry during s imu la t i on .
i PpmT Set=0 # Contains the i n t e g e r index o f the
element o f the PpmT Set vec to r cu r r en t l y on p ro c e s s i ng .
i LcS im Set=0 # Contains the i n t e g e r index o f the
s imu la t i on being proce s s out fo the NLcSim x i PpmT de f ined .
LcSimPpmC Track x i PpmT=[] # Contains a l l the Accumulated Ppm
Cost f o r each one o f the NLcSim x i PpmT
LcSimFC Track x i PpmT=[] # Contains a l l the Accumulated Ppm
Cost f o r each one o f the NLcSim x i PpmT
LcSimC Track x i PpmT=[]
LcCHstg x i PpmT=[] # Contains a l l the co s t h istograms
ca l c u l a t ed from LcSimC Track x i PpmT ( Ful l Histogram )
LcC Ci x PpmT A=[] # Contains a l l 4−p l e t s d e s c r i b i n g Ci90
co s t boundar ies f o r each i PpmT Set .
LcC Ci x PpmT B=[]
LcC Ci x PpmT C=[]
## PARAMETERS OF: Inc lude s d e t a i l e s c on f i g u r a t i o n s o f g ene ra l t op i c s
shown be f o r e .
Eta1=20.0 # INPUT: Eta parameter o f Weibull
d i s t r i b u t i o n . Def ine e l t i po de equipo representado
Beta1=2.5 # INPUT: Beta parameter o f Weibull
d i s t r i b u t i o n . Def ine e l t i po de equipo representado
## FEEDBACK: F i l i n g in fo rmat ion fo t ra ck ing performance .
VRB=0 # INPUT: De f ine s when to produce text
outputs
# −−−> Mng PpmT Set Run
#−−−> Mng PpmT Set Run : 1
i PpmT Set=0 #Se ubica antes de l primer i nd i c e de
tiempos
#−−−> Mng PpmT Set Run : 2
NPpmT Set=s i z e (PpmT Set , 1 ) # Obtiene e l tamano de l vec to r Ppm T
que almacena l o s mu l t i p l e s pe r i odos de mtto a eva luar .
# −−> Loop Ppm T Set
# −−> Loop Ppm T Set : 1
f o r i PpmT Set=1:NPpmT Set
# −−> Mng LcSimSet x i PpmT Set
i LcS im Set=0
f o r i LcS im Set=1:NLcSim x i PpmT
i f VRB >= 1 p r i n t l n ( ”PpmT COA =” , PpmT Set [ i PpmT Set ] ) end
16 2 Descripcion y Analisis de Resultados
i f VRB >= 1 p r i n t l n ( ” Simulat ion COA =” , i LcS im Set ) end
# −−> Mng EvGen x i LcSim Set
# −−> Mng EvGen x i LcSim Set : 1
# −−> Inic LcSim Run
CurrentSimTime=0.0 # SetToZero
AccFCount=0
AccPpmCount=0
TypeOfLastEvent=”” # SetToNone
# −−> Mng EvGen x i LcSim Set : 2
whi l e CurrentSimTime <= LcT
i f VRB >= 2 p r i n t l n ( ”SimTime now i s ” , CurrentSimTime , ”
a f t e r a ” , TypeOfLastEvent ) end
# −−> prcUpdCCounts
i f TypeOfLastEvent==”F”
AccFCount+=1
end
i f TypeOfLastEvent==”Ppm”
AccPpmCount+=1
end
# −−> prcGenNextTTF
NextTTF = genNextTTF(TypeOfProbDist , Eta1 , Beta1 ,VRB)
# −−> prcIsF or Ppm
i f NextTTF > PpmT Set [ i PpmT Set ]
#La f a l l a o c u r r i r i a luego de l mantenimiento , se
de s ca r ta e l NextTTF
CurrentSimTime += PpmT Set [ i PpmT Set ]
#Se de f i n e e l t i po de evento como de mantenimiento
Ppm.
TypeOfLastEvent=”Ppm”
e l s e
#La f a l l a ocurre antes de l proximo mantenimiento , se
toma como l a ocu r r enc i a de una f a l l a .
CurrentSimTime += NextTTF
#Se de f i n e e l t i po de evento como de mantenimiento
Ppm.
TypeOfLastEvent=”F”
end
# −−>Loopend
# −−> Mng evGen x i LcSim Set : 3
i f VRB >=2 p r i n t l n ( ”The accumulated Ppm( planed ) count i s ” ,
AccPpmCount , ” and the F ( unplanned ) ” , AccFCount , ” Sim : ” ,
i LcS im Set ) end
# −−> prcCa lcStore LcS im x i LcS im Set
push ! ( LcSimPpmC Track x i PpmT ,AccPpmCount∗CPpm) #Array con
2.3 Disminucion de tiempo de ejecucion 17
co s t o s mantenimiento planeado de todas l a s s imu lac i one s
push ! ( LcSimFC Track x i PpmT , AccFCount∗CF) #Array con co s t o s
de f a l l a s de todas l a s s imu lac i one s
push ! ( LcSimC Track x i PpmT ,AccPpmCount∗CPpm+AccFCount∗CF) #
Array con co s t o s t o t a l e s en todas l a s s imu lac i one s
# −−> Mng evGen x i LcSim Set : FinRetorno
# −−>Loop LcSim Set : FinRetorno
end
# −−> Mng LcSim Set x i PpmT :3
i f VRB >=2 p r i n t l n ( ”Se c a l c u l a e l histograma para e l Ppm” ,
i PpmT Set ) end
# −−> prcLcC HistoCalc x i PpmT Set
#Directamente se busca e l Ci90 desde l o s datos de cos to s imulador
para cada Lc
#Ordena l o s e lementos en l o s array de co s t o s
s o r t ! ( LcSimC Track x i PpmT )
so r t ! ( LcSimFC Track x i PpmT )
so r t ! ( LcSimPpmC Track x i PpmT)
i f HGCfg==”Fast ”
IndexA = round ( Int64 , NLcSim x i PpmT/100∗(50−CiPct /2) )
IndexB = round ( Int64 , NLcSim x i PpmT/100∗50)IndexC = round ( Int64 , NLcSim x i PpmT/100∗(50+CiPct /2) )
#s t o r e s in fo rmat ion to each Ci90 vec to r
i f VRB >=2 p r i n t l n ( ”Se carga l a Matriz para e l Ppm” ,
i PpmT Set ) end
push ! ( LcC Ci x PpmT A , LcSimC Track x i PpmT [ IndexA ] )
push ! ( LcC Ci x PpmT B , LcSimC Track x i PpmT [ IndexB ] )
push ! ( LcC Ci x PpmT C , LcSimC Track x i PpmT [ IndexC ] )
end
i f HGCfg==”Deta i l ed ”
end
# −−> Mng LcSim Set x i PpmT : FinReturn
# −−> Loop PpmT Set : FinReturn
LcSimPpmC Track x i PpmT=[]
LcSimFC Track x i PpmT=[]
LcSimPpmCount Track x i PpmT=[]
LcSimFCount Track x i PpmT=[]
LcSimC Track x i PpmT=[]
end
p r i n t l n ( s i z e (LcC Ci x PpmT A , 1 ) )
p r i n t l n ( ”Proceso Exitoso ” )
toc ( )
Codigo 2.1: Primera seccion del codigo
18 2 Descripcion y Analisis de Resultados
# prcGraf icac ion LcMtx ”
GType=”Raw”
p r i n t l n ( ”Se da i n i c i o a l proceso de g r a f i c a c i o n : Modo : ” , GType)
i f GType==”Raw”
# Produces a Graph with the o r i g i n a l CiX% data
p l o t (PpmT Set , LcC Ci x PpmT A , ”b” )
p l o t (PpmT Set , LcC Ci x PpmT B , ”g” )
p l o t (PpmT Set , LcC Ci x PpmT C , ” r ” )
x l ab e l ( ”Periodo de mantenimiento (meses ) ” )
y l ab e l ( ”Unidades de Costo” )
show ( )
end
i f GType==”Smooth”
#Ca l cu l a t e s moving averages us ing 1/PpmT Step samples
AvSetSize= round ( Int , 1/PpmT Step )
RawVectorSize=s i z e (LcC Ci x PpmT C , 1 )
summary( AvSetSize )
i f AvSetSize>3
LcC Ci x PpmT SmoothA=[ ] #Nuevos array suav izados
LcC Ci x PpmT SmoothB=[ ]
LcC Ci x PpmT SmoothC=[ ]
PpmT Set Smooth=[ ]
MaxIndex=RawVectorSize−AvSetSize #Maximo va lo r a suav i za r
MinACost=10.9ˆ12 #Costos minimos , se i n i c i a l i z a n muy grandes
MinBCost=10.9ˆ12
MinCCost=10.9ˆ12
MinAT=0.0
MinBT=0.0
MinCT=0.0
f o r i Smooth=1:MaxIndex
SumA=0.0
SumB=0.0
SumC=0.0
SumT=0.0
f o r j=i Smooth : i Smooth+AvSetSize
SumA=SumA+ LcC Ci x PpmT A [ j ]
SumB=SumB+ LcC Ci x PpmT B [ j ]
SumC=SumC+ LcC Ci x PpmT C [ j ]
SumT=SumT+PpmT Set [ j ]
end
ValA=SumA/AvSetSize #Promedios de l o s va l o r e s sumados (
AvSetSize va l o r e s )
ValB=SumB/AvSetSize
ValC=SumC/AvSetSize
ValT=SumT/AvSetSize #Promedio de l tiempo
2.3 Disminucion de tiempo de ejecucion 19
i f ValA<MinACost
MinACost=ValA
MinAT=ValT
end
i f ValB<MinBCost
MinBCost=ValB
MinBT=ValT
end
i f ValC<MinCCost
MinCCost=ValC
MinCT=ValT
end
push ! ( LcC Ci x PpmT SmoothA , ValA)
push ! ( LcC Ci x PpmT SmoothB , ValB)
push ! ( LcC Ci x PpmT SmoothC , ValC)
push ! ( PpmT Set Smooth , ValT)
end
#Plot the Graph s to r ed in Smooth Var iab l e s
p l o t (PpmT Set Smooth , LcC Ci x PpmT SmoothA , ”b” )
p l o t (PpmT Set Smooth , LcC Ci x PpmT SmoothB , ”g” )
p l o t (PpmT Set Smooth , LcC Ci x PpmT SmoothC , ” r ” )
show ( )
p r i n t l n ( ”VALORES oPTIMOS” )
p r in t ( ”P50 : Costo Minimo =” ,MinBCost )
@pr int f ” Periodo optimo = %0.2 f \n” MinBT
pr in t ( ”IC : ” , CiPct , ” % Costo Minimo =” ,MinACost )
@pr int f ” Periodo optimo = %0.2 f \n” MinAT
# @print f ”IC : ” , CiPct ,”% Costo Maximo =”,MinCCost , ” ,
Frecuenc ia = %0.2 f \n” , MinCT
pr in t ( ”IC : ” , CiPct , ” % Costo Maximo =” ,MinCCost )
@pr int f ” Periodo optimo = %0.2 f \n” MinCT
pr i n t l n ( ”Graf icando promedios movi les : Cantidad x promedio ” ,
AvSetSize )
p r i n t l n ( ”
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−”)
p r i n t l n ( ”Di s t r : Weibull ParamBeta : ” , Beta1 , ” ParamEta : ” ,
Eta1 )
p r i n t l n ( ”Crf Costo : Costo de Fa l l a ” , CF, ” , Costo de Ppm ” ,
CPpm)
p r i n t l n ( ”Tiempo de Cic lo de Vida Valorado (meses ) : ” , LcT)
p r i n t l n ( ”
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−”)
e l s e
20 2 Descripcion y Analisis de Resultados
#Plot the r e gu l a r No Smoothed Graph
p r i n t l n ( ”No fue po s i b l e r e a l i z a r l o s promedios movi les ” )
p l o t (PpmT Set , LcC Ci x PpmT A , ”b” )
p l o t (PpmT Set , LcC Ci x PpmT B , ”g” )
p l o t (PpmT Set , LcC Ci x PpmT C , ” r ” )
end
x l ab e l ( ”Periodo de mantenimiento (meses ) ” )
y l ab e l ( ”Unidades de Costo” )
show ( )
end
Codigo 2.2: Segunda seccion del codigo
#VERIFICATIONS
#Fa i l u r e Function V e r i f i c a t i o n
NVrfSamples=10ˆ6
F=rand (NVrfSamples )
Tt f Se t =[ ]
f o r i =1:NVrfSamples
Tmp = (1−F[ i ] )
Tmp = 1/Tmp
i f Tmp>0
Tmp= log (Tmp)
e l s e
Tmp=1/ log (−1∗Tmp)
end
push ! ( Ttf Set , Eta1∗Tmpˆ(1/Beta1 ) )
end
summary( Tt f Se t )
s l o t s =round ( Int64 , NVrfSamples /20)
i f s l o t s >= 500 s l o t s =500 end
p l t [ : h i s t ] ( Ttf Set , s l o t s )
toc ( )
Codigo 2.3: Tercera seccion del codigo
En donde las variables independientes usadas en el codigo son:
PpmT Set: Ppm es un acronimo para Periodic Preventive Maintenance. T
en un acronimo para un perıodo de tiempo Time que define la frecuencia
o duracion total de una actividad o su perıodo de ejecucion. PpmT Set
Variable que representa el Vector que contiene un conjunto de frecuencias
de mantenimiento a ser analizadas.
N PpmT: Variable que contiene el numero total de perıodos (frecuencias)
de mantenimiento a analizar.
2.3 Disminucion de tiempo de ejecucion 21
COA PpmT: COA es un acronimo para Currently On Assessment. Hace
referencia al elemento de un conjunto que se encuentra siendo procesado.
COA PpmT Variable que almacena el intervalo de tiempo de mantenimiento
preventivo periodico en evaluacion
i PpmT Set: i es un acronimo de ındice, generalmente empleado para reco-
rrer vectores de 1 dimension. i PpmT Set Variable que contiene el ındice con
el que se recorre el vector de tiempos de mantenimiento preventivo periodico
a evaluar.
Las variables necesarias para configurar la optimizacion:
Dtype: Variable que contiene el tipo de distribucion a emplear en el proceso
de generacion de evento de falla.
Dp eta: Variable, parametro de distribucion aplicables a distribuciones tipo
Weibull.
Dp beta: Variable, parametro de distribucion aplicables a distribuciones
tipo Weibull.
Dp mu: Variable, parametro de distribucion aplicable a distribuciones tipo
Normal.
Dp sigma: Variable, parametro de distribucion aplicables a distribuciones
tipo Normal.
LcT: Variable, parametro que establece la duracion total de cada ciclo de
vida a analizar
CF: Variable, parametro que representa el costo de la falla.
CPpm: Variable, parametro que representa el costo de la intervencion Ppm.
NSim x i PpmT: Variable que contiene el numero de simulaciones por
cada perıodo de Ppm a evaluar, define la resolucion del histograma de costo.
Las variables asociadas con el almacenamiento de los datos generados y los sub-
secuentes calculos para la identificacion de la frecuencia optima de intervencion:
22 2 Descripcion y Analisis de Resultados
LcC Ci90 Set: LcC: Es un acronimo para Life Cycle Cost. Ci90 es un
concepto que representa el Intervalo de confianza delimitado por el 5 % y
el 95 % de confianza sobre una prediccion. Variable vector que contiene los
valores esperados de LcC para el 5 %, 50 % (E) y 95 %. Se calcula con el
proposito de ser adicionado a colas almacenadas en matrices.
LcC Ci90 x PpmT Mtx: Variable matriz empleada para almacenar to-
dos los LcC Ci90 de cada uno de los PpmT.
Las secciones principales se describe a continuacion:
InitRun
• Realizar la inicializacion de:
◦ Las variables de entrada para la optimizacion
◦ Las variables de configuracion del algoritmo de optimizacion
◦ La declaracion de los recursos a ser empleados durante la optimi-
zacion.
• La definicion de las funciones de muestreo de distribucion de probabi-
lidad.
• La integracion de recursos del lenguaje de modelamiento computacio-
nal.
Mng PpmT Set Run/Loop PpmT Set
• Establece la manera como seran explorados los multiples perıodos de
mantenimiento a evaluar para encontrar el optimo
Mng EvGen x i LcSim Set
• Establece la manera como se administrara la generacion de eventos.
• Establece como se diferenciara si en cada situacion se da una falla o un
evento y la manera como esto afectara los costos simulados.
prcLcC HistoCalc x i PpmT Set
• Establece la manera como se realizara el histograma de costos sobre el
grupo de simulaciones realizadas para cada perıodo de mantenimiento
de prueba.
2.3 Disminucion de tiempo de ejecucion 23
• Establece la manera como seran identificados los costos mınimos para
el valor medio esperado y los lımites del intervalo de confianza selec-
cionados para la simulacion.
• Establece la manera como seran graficados los resultados
Una vez conocida la estructura del algoritmo brindado por la empresa, se procedio
a identificar las secciones del codigo donde esten presentes bucles independientes,
con el objetivo de implementar paralelizacion con la ayuda de la herramienta su-
ministrada por Julia. Para el desarrollo se utilizo los comandos @spawn y fetch()
que corresponden a metodos para el direccionamiento de datos y funciones ha-
cia y desde los diferentes procesadores. Los bucles seleccionados se transformaron
en funciones independientes las cuales, con los comandos de paralelizacion, se
computaron en procesadores diferentes recopilando los resultados individuales pa-
ra la construccion de un resultado global el cual era el deseado en el programa
original.
El resultado que debe presentar los codigos corresponden a curva ilustrada en la
figura 2.4
Figura 2.4: Curva de costos en funcion del periodo de mantenimiento
La comparacion de tiempos de procesamiento computacional, para los codigos
paralelizados y los originales, se muestran en la Figura 2.5 utilizando la misma
prueba variando el numero de procesadores.
24 2 Descripcion y Analisis de Resultados
Figura 2.5: Comparacion de los tiempos de ejecucion utilizando las herramientas
de paralelizacion
2.4. Estructuracion de los equipos de trabajo a
traves de IDEF0
El proceso general del proyecto se analizo, estructuro, e implemento de acuerdo a
una metodologıa de modelamiento funcional llamada IDEF0, la cual permitio dar
un contexto a como abordar el problema planteado.
Muchas metodologıas efectivas existen para el modelamiento y manufactura de
procesos, especialmente en diseno. Los metodos IDEF tuvieron su nacimiento con
los programas de la Fuerza Aerea Estadounidense, para manufactura integrada
asistida computacionalmente (ICAM). Ası entonces, y con el crecimiento amplio
de estas metodologıas de modelamiento, IDEF ha sido parte de la ingenierıa con-
currente, gestion total de calidad, y re-ingenierıa de procesos de negocio [9].
Las tecnicas IDEF consisten en 3 niveles basicos, donde el primero de ellos es
denominado como IDEF0, el cual es un diagrama usado para la creacion de un
documento extremadamente comprensivo para describir las relaciones funciona-
les del entorno, al nivel de detalle permitido por el tiempo y las capacidades del
disenador. Este diagrama provee de un punto de partida para analisis y mejoras
del sistema. (Las tecnicas de IDEF1 e IDEF2 son usadas para la informacion de
requerimientos dinamicos del sistema) [10].
2.4 Estructuracion de los equiposde trabajo 25
Figura 2.6: IDEF0 del proceso global
El proceso global se ilustra en la Figura 2.6. En esta se visualiza que, para lo-
grar los pronosticos de desempeno financiero y tecnico, y partiendo de un proceso
industrial y de los parametros de mejoramiento u optimizacion, se hace uso de
una gran gama de lenguajes de programacion disponibles como recursos libres,
un lenguaje de modelamiento de propia creacion, un lenguaje de intercambio de
informacion, y los recursos de computo generales.
La Figura 2.7 ilustra la distribucion de etapas en el abordaje del problema, con-
templando multiples etapas descritas por:
Interfaz Usuario-Herramienta: Encargado de brindar a un usuario el
acceso a la herramienta computacional creada.
Modelamiento: Etapa que transformara la informacion del usuario sobre
el proceso industrial en un lenguaje comunicativo computacional.
Interpretador del Modelo: Proceso que convertira el lenguaje comunica-
tivo computacional en insumos informaticos para la aplicacion de algoritmos
computacionales sobre los mismos segun los requerimientos.
Simulacion: Proceso que desarrollara la tarea de determinar la mejor confi-
guracion de los periodos de mantenimiento, que dan lugar a mejores pronosti-
cos tecnicos y financieros del proceso industrial el cual, haciendo uso de un
metodo de Montecarlo, obtiene un analisis estadıstico de la simulacion de
eventos discretos basada en procesamientos computacionales eficientes en
tiempo y memoria.
26 2 Descripcion y Analisis de Resultados
Figura 2.7: Diagrama IDEF0 de las diferentes etapas del proyecto
Interfaz Herramienta-Usuario: Interaccion de salida de la herramienta
computacional con el usuario final
La etapa de Simulacion esta entonces compuesta por una serie de subprocesos,
consistentes en desarrollar el proceso de la construccion de la linea de tiempo con
los eventos discretos procesados haciendo uso de un computo paralelo. Para ello
se cuenta con un Coordinador Central quien presenta la hoja de ruta del proce-
samiento, y tiene presente los diferentes procesos ocurridos en toda la Simulacion
dando ordenes de inicio y despliegue de informacion. La Configuracion de la si-
mulacion presenta la primera fase de acondicionamiento de datos para dar paso
a la Computacion Paralela, quien desarrollara la simulacion como tal. La Figura
2.8 ilustra este proceso de Simulacion.
Finalmente, y como ultimo nivel de profundidad del diagrama general IDEF0, con-
tamos con el proceso de Computacion Paralela quien va a desarrollar la simulacion
de eventos discretos haciendo uso de recursos de Hardware para el computo para-
lelo de instrucciones algorıtmicas especıficas. La Figura 2.9 presenta este ultimo
nivel de profundidad donde se cuenta con:
Coordinador de Paralelizacion: Ası como el subproceso de nombre si-
milar en el proceso de Simulacion este se encarga de impartir ordenes de
2.4 Estructuracion de los equiposde trabajo 27
Figura 2.8: Diagrama IDEF0 del Proceso de Simulacion
computo y despliegue de datos, teniendo un control sobre la simulacion to-
tal
Simulacion de Eventos Discretos: Es el proceso que haciendo uso del
siguiente (Computacion Logica y Matematica) desarrolla la cola de eventos
y la procesa para un ciclo de vida determinado por el usuario y la cantidad
de iteraciones establecidas para el proceso de Monte Carlo.
Computacion Logica y Matematica: Desarrolla computo de apoyo para
la Simulacion de Eventos Discretos
28 2 Descripcion y Analisis de Resultados
Figura 2.9: Diagrama IDEF0 del Proceso de Computacion Paralela
El metodo IDEF0 permitio definir procesos interconectados por entradas, salidas,
atributos de control y herramientas, que fundamentaron la separacion en diferentes
etapas del proyecto, sin llevarlo a una disociacion completa.
2.5. Diseno e implementacion de la Operacion
logica, OR continua (Primer Diseno)
Para el desarrollo de la primera aproximacion y abordaje al problema se imple-
mento un diseno de procesamiento de eventos por medio de logica semi-booleana
donde se comparaban las duraciones de cada evento para determinar si existıa
una no disponibilidad en el sistema debido a la ocurrencia de algun evento y los
solapamientos entre estos. La Figura 2 muestra un diseno global de las operaciones
importantes sin ahondar mucho en como se desarrollaron como tal.
El nucleo del problema se basa en el calculo de la disponibilidad total en un ciclo de
vida, para ello se considero que cada evento esta compuesto por 3 caracterısticas:
Identificador, Ocurrencia y Duracion. Estas ultimas dos caracterısticas son un
matriz (nx2), que corresponde a numeros aleatorios calculados previamente, donde
2.5 Diseno e implementacion de la Operacion OR 29
Figura 2.10: Distribucion de las ocurrencias de los eventos en una lınea de tiempo
la totalidad de estos no debe exceder el ciclo de vida de la simulacion
n∑i=1
(oci + duri) < Ciclo de Vida
Donde oci y duri corresponden, respectivamente, a la ocurrencia y duracion del
evento i, para n eventos ocurridos durante todo el Ciclo de Vida
El solapamiento de los eventos se llevo a cabo considerando una operacion semi-
booleana (logica) continua donde, como se ilustra en la Figura 2.10, los eventos
se procesan en la lınea de tiempo simultaneamente.
Para el caso implementado en este punto del proyecto, se tuvieron en cuenta las
siguientes consideraciones:
1. En la ocurrencia de un evento, y durante esta, no existe disponibilidad del
sistema.
2. Solo existe un tipo de evento y no estan asociados por alguna razon.
3. Se considera un sistema con recursos infinitos
4. Los eventos ocurren independientemente sin importar la ocurrencia de los
demas eventos.
Luego de esto se implemento el diseno algorıtmico que daba lugar a este procesa-
miento de la linea de tiempo planteado con las consideraciones ya mencionadas,
ası entonces se da lugar al Diagrama de Flujo de la Figura 2.11 donde se puede
evidenciar la mencion a la operacion Dependiente la cual hace referencia a apli-
cacion analoga a la operacion logica OR pero de manera continua entre todas las
30 2 Descripcion y Analisis de Resultados
intervenciones de los eventos en la linea de tiempo.
De la misma manera, los computos de desempeno tecnico y desempeno financiero
hacen parte de logica computacional abordada con posterioridad. Para este caso
se analizo solo la operacion Dependiente, la cual se baso principalmente en el
analisis de que los eventos presentaran un solapamiento.
El termino Dependiente se concibe en modelamiento como el caso en que los
equipos, configurados en serie, presentan disponibilidades, siempre que todos esten
funcionando (no ocurra algun evento asociado al equipo), de tal manera que la
disponibilidad total del sistema sera la correspondiente al lapso en que un equipo
esta disponible, siempre que no se solape con algun lapso en que algun evento
ocurre (del equipo en cuestion o de cualquier otro equipo). Se plantean entonces
3 casos de solapamiento como los ilustrados en la Figura 2.12.
Dentro del diseno planteado se propone la Creacion de Matriz de vectores de even-
to en la cual se instanciaban todas las ocurrencias y duraciones de eventos, estos
eventos serian luego procesados entre ellos. Sin embargo, dicho proceso fue com-
plicado ya que llevo al incremento del tiempo de procesamiento.
Luego de planteados los disenos y analizados todos los posibles casos a darse,
se procedio a desarrollar el programa respectivo en JULIA donde se encontraron
diversas dificultades computacionales, donde la mas importante fue la del tiempo
de procesamiento.
La alternativa se presenta al Director interno de la pasantıa quien nos sugiere
cambiar la estrategia de abordaje del problema, y nos da las pautas para considerar
un nuevo diseno, mas preciso y mejor fundamentado.
2.6. Computo paralelo, las herramientas de Ju-
lia y las taxonomıas de Flynn
El computo paralelo es de gran importancia para el desarrollo del proyecto, ello
debido a que los procesos algorıtmicos a tener en cuenta son de gran consumo de
memoria y de tiempo.
2.6 Computo paralelo 31
Figura 2.11: Diseno general de primera aproximacion de solucion donde se con-
sideraban las ocurrencias (y duraciones) de los eventos, analizando la no disponi-
bilidad ocasionada por estos
32 2 Descripcion y Analisis de Resultados
Figura 2.12: Tipos de solapamiento entre eventos donde (de izquierda a derecha
y de arriba a bajo) se tiene: (1) Solapamiento Total, (2) Solapamiento Parcial, y
(3) Solapamiento de Contencion
Taxonomıas de Flynn
La teorıa de computo paralelo se remonta a las taxonomıas de Flynn, que ejem-
plifican las diferentes arquitecturas para el computo relacionando tramas de datos
e instrucciones, y su distribucion en diferentes procesos [11]. Flynn entonces es-
pecifica 4 tipos de arquitecturas basadas en unicas o multiples instrucciones y en
unicas o multiples tramas de datos. La Tabla 2.5 desarrolla una descripcion de
cada una de estas [12] .
Herramientas de Julia para paralelizacion
Por otro lado, Julia ofrece variadas opciones para desarrollar paralelizacion, ello
partiendo del hecho que los fundamentos de Julia se hacen orientando el lenguaje
al uso de computo paralelo, por lo cual, este lenguaje esta optimizado para dicho
fin. En la Tabla 2.6 se muestran los principales comandos de Julia orientados a la
paralelizacion, junto con su descripcion [13].
2.7. Acople con el primer modelador desarrolla-
do en una hoja de calculo (Segundo Diseno)
Luego del ultimo diseno propuesto, se recibieron correcciones y pautas para el
desarrollo de un diseno mas eficiente en velocidad de computo y de memoria, esto
2.7 Acople con el primer modelador 33
Tabla 2.5: Taxonomıas de Flynn
Taxonomıa Descripcion
SISD Single Instruction Single Data Corresponde al computo secuencial
usual, donde una instruccion manipula unicamente un conjunto de
datos en un intervalo de tiempo. No existe paralelizacion de procesos
en este caso. La Figura 2.13 (a) ilustra este modelo.
SIMD Single Instruction Multiple Data presenta un modelo donde una mis-
ma instruccion reside en cada uno de los procesadores a emplear, estos
operaran diferentes tramas de datos bajo dicha misma instruccion si-
multaneamente (paralelamente). El Modelo SIMD presenta entonces
un tipo de arquitecturas bastante util la cual hace referencia a la Me-
moria Compartida, de esta manera los procesos se comunican a traves
de dicha memoria. La Figura 2.13 (b) ilustra este modelo.
MISD Multiple Instruction Single Data posee una estructura similar a la del
modelo SIMD, pero en este caso se posee una misma trama de da-
tos, la cual sera procesada de manera simultanea, pero con multiples
instrucciones diferentes. Este modelo se presenta de manera teorica
puesto que no existen muchas aplicaciones con dicho fin. La Figura
2.13 (c) ilustra este modelo.
MIMD Multiple Instruction Multiple Data es el modelo mas utilizado ac-
tualmente, presenta un sistema de multiples procesadores capaces de
desarrollar trabajos independientemente, ademas de producir para un
sistema global, de manera que cada procesador posee un par instruc-
cion-trama de datos separadamente. De la misma manera que el mode-
lo SIMD, el modelo MIMD puede contar con Memoria Compartida,
sin embargo tambien posee caracterısticas de Memoria Distribuida
donde cada procesador ejecuta sus trabajos independientes y se co-
munican por envıo de mensajes. La Figura 2.13 (d) ilustra el modelo.
34 2 Descripcion y Analisis de Resultados
(a) (b)
(c) (d)
Figura 2.13: Modelos de la Taxonomıa de Flynn para (a) Single Instruction Single
Data Stream, (b) Single Instruction Multiple Data Stream, (c) Multiple Instruc-
tion Single Data Stream y (d) Multiple Instruction Multiple Data Stream
2.7 Acople con el primer modelador 35
Tabla 2.6: Herramientas de Julia para paralelizacion
Comando Descripcion
Future Resultado futuro de un trabajo realizado por un procesador
o por un trabajor, para obtener el valor de un Future se hace
uso de la funcion fetch()
remotecall Hace el llamado a una funcion especificando el procesador en
el que se ejecutara dicha funcion, funcion de bajo nivel de
interfaz que provee de un control mas preciso. El resultado
obtenido es un Future.
remotecall fetch Desarrolla el Fetch del remotecall
wait Espera a que un remotecall termine de ejecutarse, es decir,
que el procesado quede libre para otra instruccion
fetch Obtiene el valor de un Future en el procesador principal que
reside en un procesador diferente
spawn Asigna una instruccion a un procesador disponible.
spawnat Asigna una instruccion a un procesador en especifico
everywhere Es un comando que permite correr una instruccion en todos
los proceso.
parallel Implementa un patron de asignacion de iteraciones a multi-
ples procesos, combinandolos para un resultado global. Es
utilizado en bucles independientes
sync Es un proceso o una funcion que ejecuta donde el usuario tiene
que esperar a que todos los datos y tareas esten finalizadas.
async Es un proceso o una funcion que ejecuta una tarea sin que el
usuario tenga que esperar a que finalice la tarea.
RemoteChannel Vector donde se depositan datos los cuales seran utilizados
por diferentes tareas o funciones en cualquier procesador con
arquitectura FIFO (First In, First Out)
take! Obtiene los datos de manera concurrente que residen en un
canal o en un canal remoto
put! Ingresa datos de manera concurrente que residen en un canal
o en un canal remoto
addprocs Da disponibilidad a Julia para utilizar todos los procesadores
distribuyendolos virtualmente en Workers ya sean automati-
camente o definidas por el usuario
nworkers Conteo de trabajadores activos para procesamiento
workers Listado de identificadores de cada trabajador
nprocs Contero del numero de trabajadores, ademas del trabajador
correspondiente al procesador principal
36 2 Descripcion y Analisis de Resultados
nos llevo a replantear la forma de abordar el problema de tal manera que se llegara
a una solucion plausible y escalable.
El desarrollo algorıtmico presentado a continuacion permite la implementacion de
un aplicativo computacional que procesa un sistema de equipos en serie. Dichos
equipos, aparte de dar contexto al funcionamiento objetivo de cada sistema, po-
seen eventos definidos por mantenimientos y/o fallas caracterizados por funciones
de probabilidad, las cuales generan numeros aleatorios especıficos con relacion a
las ocurrencias y duraciones de estos dos tipos de eventos. El programa compu-
tacional desarrolla una simulacion de eventos discretos, y posteriormente hace uso
de un proceso de Monte Carlo [14]. que, iterativamente, brindara informacion es-
tadıstica respecto a los pronosticos de desempeno tecnico y desempeno financiero,
esto a traves de una muestra de datos (histogramas) respectiva al costo total, cos-
to de mantenimiento, costo de falla, disponibilidad del sistema y costo por lucro
cesante, por cada iteracion.
Primero, el equipo completo de pasantıa desarrollo, en una etapa diferente, una
herramienta que hiciera uso de la simulacion de eventos discretos por medio de
una Hoja de Calculo y macros en Visual Basic, donde se implementarıa la aplica-
cion de Pronostico de NPT (Non Productive Time). La Figura 2.14 explica
un poco de como fue construido este aplicativo.
2.7 Acople con el primer modelador 37
Figura 2.14: Herramienta de Pronostico de NPT
En la herramienta de Pronostico NPT, un modelador desarrollarıa la descrip-
cion abstracta de su sistema, configurado por elementos en serie y estableciendo
tantos de estos como deseara, asociando eventos de mantenimiento programado y
no programado (considerando los estimativos estadısticos por funciones de proba-
bilidad de cada uno), sus costos respectivos, ası como tambien los datos generales
de la simulacion como el Intervalo de Confianza, el Numero de Iteraciones y el
Costo por Lucro Cesante.
Para el desarrollo de la herramienta se hizo necesaria la configuracion de un arbol
jerarquico donde se explica la estructura de como el modelador presentara de
manera abstracta un sistema industrial, para ello, en la Figura 2.15 se ilustra este
arbol jerarquico explicado a continuacion:
Proceso: Elemento raız de la simulacion (universo). Todo modelador inicia
con una vista de proceso referente al proceso industrial global a procesar, y
este esta compuesto de diferentes sistemas.
38 2 Descripcion y Analisis de Resultados
(a)
(b)
Figura 2.15: Jerarquıa del proceso donde en (a) se visualiza un diagrama de arbol
referente al proceso industrial, mientras en (b) se plantean la serie de vistas que
tienen lugar en el mismo
Sistema: Segundo nivel en el proceso industrial, Cada sistema hace refe-
rencia a una accion general dentro del proceso, donde la union de todos los
sistemas lleva a cumplir la tarea para la cual existe el proceso.
Equipo: Componente de cada sistema, los equipos permiten al sistema lle-
var a cabo su accion, donde la union de estos presenta una coherencia para
dicho fin.
Evento: En principio todos los equipos funcionan con normalidad, sin em-
bargo, existen eventos dentro de estos que hacen referencia a los mante-
2.7 Acople con el primer modelador 39
nimientos programados y no programados del equipo, Estos eventos estan
descritos por funciones de probabilidad y modifican el estado del equipo
segun su configuracion, pueden llegar a afectar hasta el proceso segun estos,
mediante la accion sobre los equipos, actuen sobre un sistema.
• Falla: Conocida tambien como Mantenimiento No-Programado. Re-
presenta un alto costo y posee una duracion probabilisticamente es-
timada. Ası mismo su ocurrencia se da debido a una distribucion de
probabilidad (normalmente Weibull, normal, lognormal)
• Mantenimiento: Llamado tambien como Mantenimiento Programa-
do. Es aquel evento que ocurre segun una programacion ya sea por
calendario (por ejemplo fechas especificas de un ano) o por operacion
(respecto al tiempo en que el sistema ha estado activo; por ejemplo,
luego de 100 horas de operacion del sistema), las duraciones tambien
son probabilisticamente estimadas.
La importancia de este primer diseno da lugar a grandes consideraciones como lo
fueron la inclusion de diferentes funciones de probabilidad que pueden tener lugar
en un modelo industrial real, ello luego de desarrollar diferentes investigaciones
y consultas al director del proyecto por parte de la Empresa KNAR RAM. Ası
mismo tambien se establecen tiempos de duracion respecto a los mantenimientos
o las fallas, ya que debıan ser factores importantes en el desarrollo de la simula-
cion pues, la no disponibilidad del sistema correspondıa a un lapso que avanzaba
la simulacion progresivamente (afectaba en gran medida los mantenimientos por
tiempo de operacion).
Como se ilustra en la Figura 2.16, la interfaz grafica configuraba de manera perti-
nente un sistema bastante simple para luego ejecutar la simulacion del mismo. El
paso final de esta interfaz es la Exportacion del JSON donde se genera el lenguaje
comunicativo que posee la informacion del modelo abstracto del proceso industrial.
Lo que prosigue es la ejecucion del algoritmo computacional ideado para este fin,
el cual, se encargara de 2 grandes procesos: La interpretacion del Lenguaje Comu-
nicativo junto con la Simulacion de Eventos Discretos y el proceso de Montecarlo.
De manera general la Figura 2.17 ilustra este proceso de ejecucion algorıtmica.
Mas detalladamente, y siguiendo el objetivo de la pasantıa, se ahonda en el calculo
de costos, el cual se explica a continuacion con un diagrama de flujo en la Figura
40 2 Descripcion y Analisis de Resultados
2.19.
(a)
(b)
Figura 2.16: interfaz grafica de usuario de Herramienta de Pronostico de NPT
donde en (a) se visualiza la configuracion para el registro de cada elemento, mien-
tras en (b) se muestra la configuracion de la simulacion final junto con los ele-
mentos a ser procesados
El intervalo de confianza hace referencia a un rango de valores de una muestra
poblacional acotado por un maximo y un mınimo en el cual se define un nivel de
confianza en el que el usuario espera que un dato de la muestra este dentro de este
intervalo. Entre mas grande es el intervalo de confianza (o mayor es el nivel de
confianza), mayor es la cantidad de datos del espacio muestral que seran tenidos
en cuenta para analisis estadıstico. Sin embargo, los intervalos de confianza no
siempre son simetricos alrededor de estadısticas de muestra, ademas de que sus
distribuciones de muestreo no siempre tienen la misma forma para valores dife-
rentes [15]
Una forma simple de entender la implicacion y uso del Intervalo de Confianza
es por medio de la Figura 2.20, donde se ilustra el histograma de los datos del
espacio muestral. Para el analisis tenemos tres valores importantes relacionados
con dicho intervalo de confianza, estos son: la cota mınima del intervalo, la cota
2.7 Acople con el primer modelador 41
Figura 2.17: Diagrama general de segunda aproximacion de algoritmo de proce-
samiento
42 2 Descripcion y Analisis de Resultados
Figura 2.18: Diagrama de flujo respecto al calculo de costos mediante el proceso
de Montecarlo haciendo uso de la Simulacion de Eventos Discretos (Parte 1)
2.7 Acople con el primer modelador 43
Figura 2.19: Diagrama de flujo respecto al calculo de costos mediante el proceso
de Montecarlo haciendo uso de la Simulacion de Eventos Discretos (Parte 2)
44 2 Descripcion y Analisis de Resultados
Figura 2.20: Histograma de base para el calculo de P-maximo, P-mınimo y P-
medio, segun el intervalo de confianza
maxima y el dato medio. De esta manera podemos relacionar la cota mınima y
la cota maxima, como un caso de baja probabilidad, mientras que el valor medio
corresponde a la medicion de mayor probabilidad.
Respecto al analisis de los pronosticos de desempeno tecnico y financiero se pre-
sentan los espacios muestrales respectivos a:
costo total
costo de mantenimiento
costo de falla
disponibilidad del sistema
costo por lucro cesante
Una vez obtenidos estos datos se procede a la sintonizacion de los periodos de
mantenimiento del sistema, haciendo uso de las herramientas proveıdas por el len-
guaje de programacion utilizado (JULIA). De esta manera variamos los periodos
2.7 Acople con el primer modelador 45
de mantenimiento siguiendo una configuracion especıfica, de tal manera que que-
remos aminorar los costos e incrementar la disponibilidad del sistema al mismo
tiempo, para ello desarrollamos una teorıa de optimizacion sobre la cual basamos
el desarrollo algorıtmico.
Son tres resultados concluyentes para la sintonizacion y estos corresponden a: El
costo de Falla, El costo de Mantenimiento y El costo Total. Es importante te-
ner en cuenta que por cada una de las variaciones de periodo de mantenimiento
se corrieron tantas simulaciones de eventos discretos como interacciones existıan,
considerando cada una de estas entre un intervalo de tiempo definido por el ciclo
de vida.
El proceso simple de sintonizacion corresponde en elegir el periodo de manteni-
miento y desarrollar un barrido de su ocurrencia por un rango especifico, dicha
variacion implica 3 casos:
Si el mantenimiento ocurre muy seguido (el periodo de mantenimiento esta
en el inicio del rango de barrido) el costo de este se incrementa en gran
medida, mientras el de falla es bastante bajo.
Si el mantenimiento ocurre muy poco durante el ciclo de vida (al final del
rango de barrido) el costo de este es muy bajo, mientras que el costo de falla
es muy alto.
El costo por lucro cesante presenta comportamiento indeterminado.
La Figura 2.21 ilustra un poco este comportamiento (especialmente los primeros
dos casos) donde se muestra que el menor costo se da cuando la configuracion de
la repeticion de los mantenimientos da un costo igual al de la falla.
Ası entonces, sumando los costos, obtenemos la curva de costo total en funcion de
la variacion de la ocurrencia del mantenimiento. Esta curva presenta un mınimo el
cual brinda un parametro de periodicidad de mantenimiento, y costo del sistema
asociado a este, la grafica se ilustra en la Figura 2.22.
La teorıa optimizacion, para la sintonizacion, planteada constaba de la modifica-
cion de ciertos parametros mientras que otros permanecıan inamovibles durante
cada una de las intervenciones del sintonizador, este correspondıa en cambiar
progresivamente un periodo de mantenimiento mientras los demas permanecıan
46 2 Descripcion y Analisis de Resultados
Figura 2.21: Curva de Falla y Mantenimiento donde se obtiene el costo segun el
lapso en las ocurrencias de los mantenimientos
constantes en el valor predeterminado. Una vez encontrado el periodo de mante-
nimiento que configuraba un menor costo y mayor disponibilidad, se procedıa a
dejar este quieto y cambiar otro repitiendo el mismo proceso. Sucesivamente se
llegarıa a un resultado de modificacion de todos los periodos de mantenimiento
de tal manera que el resultado final concluyera en un bajo costo total lo cual
implicaba una mejor disponibilidad.
Sin embargo, durante la apropiacion y analisis de la teorıa de optimizacion, dimos
cuenta de que dicha optimizacion no llevaba a un optimo sino que simplemente
recurrıa siempre a un mınimo local en un hiperespacio el cual dependıa bastante
de las condiciones iniciales del sistema.
De manera sencilla, el analisis se propone teniendo en cuenta la modificacion de
solo dos periodos de mantenimiento en el sistema, el costo variarıa de una manera
bastante volatil si se consideraran diferentes condiciones iniciales, generando ası
un plano curvo con multiples mınimos locales que eclipsaban el mınimo global ob-
jetivo (Figura 2.23). Logicamente si incrementamos la cantidad de mantenimientos
a sintonizar, acabarıamos con un hiperplano con muchos mas mınimos locales, y
muchas menos probabilidades de dar con el mınimo global. Esta conclusion im-
plico para la empresa un desarrollo algorıtmico de mayor eficiencia matematica.
Desarrollado el codigo se obtuvieron los resultados ilustrados en la grafica de la
2.7 Acople con el primer modelador 47
(a)
(b)
Figura 2.22: Costo Total del sistema considerando en (a) una idealizacion mien-
tras en (b) un resultado mas proximo a la realidad
48 2 Descripcion y Analisis de Resultados
Figura 2.24 donde se observan las tres graficas resultado respecto a un intervalo
de confianza del 90 %, con un costo mınimo (respecto al P95) de 1.920 correspon-
diente a un periodo de mantenimiento de aproximadamente 54.
Figura 2.23: Costo del sistema en funcion de la sintonizacion de dos manteni-
mientos
Figura 2.24: Primer Resultado obtenido de la sintonizacion de periodos de man-
tenimiento
2.8 Integracion de maquinas 49
2.8. Integracion de maquinas a traves de servi-
dor SSH
Unas de las herramientas importantes en el desarrollo computacional, corresponde
con la segmentacion de los procesos, de tal manera, que el aplicativo presente una
flexibilidad tanto visual a la hora de ser usado por un individuo, como respecto
a los tiempos de procesamiento, la memoria consumida y la efectividad de los
resultados. Gran parte de la calidad del aplicativo, respecto estos ultimos pun-
tos, cobra importancia una vez se determina un protocolo de comunicacion entre
diferentes maquinas, donde cada una de estas se especializara en una parte del
procesamiento algorıtmico y computacional.
El estudio, implementacion, analisis, y documentacion desarrollada para esto, nos
llevo a implementar una integracion de maquinas a traves del servidor SSH. Di-
cha integracion, nos permitıa separar los procesos computacionales pesados (pro-
cesamiento de lınea de tiempo, generacion de numeros aleatorios, generacion de
proceso de Montecarlo, obtencion de resultados debido a analisis estadısticos plas-
mados algorıtmicamente, entre otros) de los no tan pesados (interfaz de usuario-
herramienta), Sin llegar a disociar por completo el aplicativo computacional como
tal.
La integracion de maquinas por SSH se llevo acabo considerando varios recursos
tecnicos, ya comprendidos y explicados anteriormente. Dicha integracion tomo
lugar a traves de los diferentes procesos desarrollados, y haciendo uso de los al-
goritmos computacionales ya implementados. Esto permitio que, a traves de una
interfaz bastante simple como lo fue la explicada previamente, se generara el len-
guaje comunicativo (JSON) a traves de un script vıa Visual Basic quien, al ser
ejecutado por un comando de interfaz, se enviarıa dicho lenguaje comunicativo a
traves de la conexion de area local y ejecutarıa los codigos desarrollados en Julia.
Posteriormente y una vez obtenidos los resultados graficos como archivos de ima-
gen JPEG, estos se traerıan por servicio SSH de nuevo a la maquina donde reside
la interfaz de usuario (maquina de usuario). El desarrollo de esta comunicacion
se explica en el diagrama ilustrado en la Figura 2.25 (para el uso del servicio
SSH se utilizo Putty [16] como servicio para comunicacion SSH) y se detalla a
continuacion:
50 2 Descripcion y Analisis de Resultados
Figura 2.25: Diagrama de procesos para la implementacion de SSH
Se identifica la ubicacion (Path) del cliente Putty:
s e t PATH = %ProgramFiles %\putty ; %PATH%
Se ubica la interfaz de usuario
cd C:\ Users \ c r i s i \Documents\KNAR\KNAR\
Se efectua una copia y transferencia del archivo .json en la maquina donde
reside el codigo, y usando la aplicacion de consola PSCP, para ello se in-
gresa el Password de la maquina objetivo, seguido del archivo a enviar, y
finalizando con la maquina, ubicacion y nombre de archivo objetivo.
pscp −pw JuanHerrera PruebaJSON . j son juanz@192 . 1 6 8 . 1 . 7 3 :
Descargas /pruebaJJ . j son
Lo siguiente corresponde a, por medio de otro aplicativo de consola llamado
PLINK, se ejecutara, vıa SSH en la maquina objetivo, el archivo tipo Julia
que usara del .json para desarrollar la simulacion (en este caso es Prueba.jl)
p l ink . exe −ssh juanz@192 . 1 6 8 . 1 . 7 3 −pw JuanHerrera cd Descargas / ;
j u l i a Prueba . j l
2.9 Implementacion de Sistema en serie 51
Finalmente, se desarrolla una copia y transferencia de todos los archivos .png
residentes en la carpeta objetivo, hacia la maquina de interfaz en la ubicacion
deseada (esto se efectuara siempre que encuentre archivos a trasferir)
pscp −unsa fe −pw JuanHerrera juanz@192 . 1 6 8 . 1 . 7 3 : Descargas /∗ . png%HOMEPATH%\Documents\KNAR\KNAR
(Maquina donde reside la Interfaz de usuario)
2.9. Implementacion de logica de procesamiento
de un sistema industrial conectado en serie
y con capacidades binarias (Tercer Diseno)
Como ultimo diseno se conto con el desarrollo de un algoritmo final de pasantıa,
el cual contaba con todas las observaciones notadas anteriormente. Ası mismo se
implemento este tercer diseno para un modelador mas completo y escalable con
las configuraciones necesarias para la operacion y uso del sistema computacional.
Ası entonces, este ultimo diseno posee tres etapas importantes: El modelador, la
simulacion de eventos discretos, y la sintonizacion de periodos de mantenimiento,
en esta sub-seccion se explicara a grandes rasgos las dos primeras etapas:
Modelador (LogicProcessLanguage)
Se crea el lenguaje de modelamiento llamado LogicProcessLanguage (Figura 2.26)
el cual es un lenguaje que representara el modelo abstracto de todo un sistema in-
dustrial, y sera clave para determinar las caracterısticas del mismo y comunicarlas
al algoritmo de procesamiento.
Figura 2.26: Logo modelador LogicProcessLanguage
52 2 Descripcion y Analisis de Resultados
Las bases del modelador ya se han implementado anteriormente, por lo cual se
conserva gran parte de este desarrollo conceptual resumido en la Figura 2.15. En
ese orden de ideas, el modelador actual cuenta con tres caracterısticas visuales de
partida que corresponden con las vistas dentro de este, teniendo entonces: La vista
de Proceso, La vista de Sistema, y La vista de Equipo, ilustradas en la Figura
2.27, 2.28 y 2.29 respectivamente.
Figura 2.27: Vista de Proceso de modelador LPL
Figura 2.28: Vista de Sistema de modelador LPL
Figura 2.29: Vista de Equipo de modelador LPL
Para cada una de las vistas se configuran datos especıficos para la ejecucion del
algoritmo de simulacion y sintonizacion. Estos datos fueron determinados para
poder resolver cada uno de los items dispuestos para la correcta ejecucion y entrega
de resultados. La Tabla 2.7 brinda un acercamiento a los objetos a utilizar, la forma
en que los recopila el modelador y su aplicacion y objetivo en la simulacion.
2.9 Implementacion de Sistema en serie 53
Tabla 2.7: Objetos a utilizar, la forma en que los recopila el modelador y su
aplicacion y objetivo en la simulacion
Vista Objeto Descripcion
Proceso
Ciclo de vida Tiempo total de simulacion para el proceso in-
dustrial. Puede estar definido en una unidad de
tiempo especifica la cual es comun en todas las
variables de tiempo en el modelador.
Numero de ite-
raciones
Total de repeticiones a efectuarse para lleva a ca-
bo el proceso de Montecarlo.
Intervalo de
Confianza
Valor usado para el calculo de los tres puntos de
costo relacionados con la confianza del sistema.
Costo Lucro
Cesante
Costo debido a la no disponibilidad (o disponibi-
lidad parcial) del sistema.
Sistemas Elementos que componen el proceso, pueden ser:
Suministro, Extraccion, Almacenamiento, Trans-
porte, Conversion, Division o Unificacion, donde
los dos primeros conforman la raız del proceso.
Relacion entre
sistemas
Puede ser discreta o continua e indica la direccion
del flujo.
Sistema
Equipos Componentes de un sistema que presentaran
mantenimientos programados y no programados.
Relacion Equi-
pos
Relaciones Serie y Paralelas (no abordadas en es-
ta fase del proyecto) que dan coherencia al siste-
ma.
Grupos Man-
tenimiento
Agrupacion de los mantenimientos para sintoni-
zacion por grupo definido por el usuario.
Equipo
Fallas Eventos que implican un alto costo y poseen una
distribucion de probabilidad asociada a su ocu-
rrencia y duracion.
Mantenimien-
tos
Eventos de menor costo con ocurrencia constan-
te y duracion definida por distribucion de pro-
babilidad, las fallas asociadas a cualquier man-
tenimiento son reconfiguradas una vez ocurre el
mantenimiento.
Distribucion
Probabilidad
Forma en la que los parametros de mantenimien-
tos y fallas son caracterizados, estos numeros
aleatorios generados corresponden al parametro
base del encolamiento de eventos y la Simulacion
de eventos discretos.
54 2 Descripcion y Analisis de Resultados
Simulacion de Eventos Discretos
La alternativa final (tercer diseno) para abordar y dar solucion al problema plan-
teado, consistio en implementar un diseno algorıtmico bajo las siguientes conside-
raciones:
Procesara solo equipos en serie para un solo sistema del proceso industrial.
Los eventos ocurridos en los equipos conllevan a una no disponibilidad total
del sistema (debido a su configuracion serie y a que la capacidad del sistema
cae a cero)
Mantenimientos pueden mitigar fallas asociadas lo cual implica una reins-
tanciacion de estas si el mantenimiento respectivo ocurre con anterioridad.
Los mantenimientos se sintonizaran agrupandolos de acuerdo a criterio del
modelador. Los grupos pueden variar en cantidad desde un mantenimiento,
hasta la totalidad de estos que hallan
El procesamiento de la lınea de tiempo se desarrolla segun tiempo de ope-
racion, lo cual implica que el ciclo de vida configurado para la simulacion
sera alcanzado unicamente cuando el tiempo de operacion del sistema a
disponibilidad completa sea igual a dicho ciclo de vida.
El diseno planteado se especifica a continuacion en la Figura 2.31 donde se ilustra
el flujo de datos y los pormenores analizados, teniendo en cuenta las considera-
ciones planteadas. Este diseno se desarrollo en conjunto con todo el equipo de
pasantıa.
Del diseno se resaltan diferentes caracterısticas que llevan a su correcto funciona-
miento, dichas caracterısticas fueron necesarias para la implementacion del algo-
ritmo, La Figura 2.32 ilustra estos datos anadidos para la construccion y proce-
samiento de la linea de tiempo.
Primero se tiene el tiempo de reloj, el cual es una variable utilizada para medir
el tiempo de operacion actual de la simulacion, comprobara si la simulacion ha
concluido al ser igual al ciclo de vida.
Por otro lado se tienen los parametros de ocurrencia y duracion que son ca-
racterısticas de los eventos que indican el momento en el cual se presentara un
2.9 Implementacion de Sistema en serie 55
Figura 2.30: Tercer Diseno para procesamiento de equipos en serie con capacida-
des binarias (Parte 1)
56 2 Descripcion y Analisis de Resultados
Figura 2.31: Tercer Diseno para procesamiento de equipos en serie con capacida-
des binarias (Parte 2)
2.9 Implementacion de Sistema en serie 57
Figura 2.32: Ilustracion de la linea de tiempo con las caracterısticas utilizadas
para su construccion segun tercer diseno
Figura 2.33: Relacion entre histograma resultado de proceso de Montecarlo e
ındices del intervalo de confianza
evento desde el tiempo de reloj actual, el lapso que permanecera en reparacion o
mantenimiento (respectivamente).
Ası entonces, el procesamiento de un ciclo de vida darıa lugar a una base de
datos, donde estos datos corresponden a la lınea de tiempo del sistema. Dicha
lınea de tiempo resumirıa el comportamiento del proceso para una unica iteracion,
entonces seria necesario desarrollar a traves de un analisis de Montecarlo multiples
iteraciones de la simulacion de eventos discretos para tener un analisis del proceso
estocastico de mejor precision y con mayor distribucion de datos resultantes, pero
considerando los siguientes parametros, por cada lınea de tiempo construida:
Conteo de no disponibilidad del sistema: Usado para determinar flujo
cesante y su costo total. Ası mismo se usa para determinar la disponibilidad
total del sistema.
Conteo de eventos ocurridos: usado para calcular el costo de falla o
58 2 Descripcion y Analisis de Resultados
Figura 2.34: Estructura interna del proceso correspondiente al Sistema No.1
de mantenimiento total del sistema, ello por medio del identificador unico
entregado por la interpretacion del modelo.
Todos estos datos corresponden a escalares asociados a cada iteracion, de tal ma-
nera que al final del proceso de Montecarlo, se acumularan vectores por cada
caracterıstica, dichos vectores se procesaran para determinar los valores del inter-
valo de confianza definido por el usuario (Figura 2.33).
A grandes rasgos, al final de un proceso de Montecarlo se poseen cuatro vectores de
tres posiciones cada uno donde estos vectores representan: Costo de Falla, Costo
de Mantenimiento, Costo por Lucro Cesante, Costo Total.
2.10. Diseno e implementacion de algoritmo de
sintonizacion de periodos de mantenimien-
to para el analisis RAM de la logica de
equipos en serie con capacidades binarias
Para la validacion de la integracion del Sintonizador de periodos de mantenimien-
to con la logica de procesamientos para sistemas industriales conectados en serie y
con capacidades binarias se crearon tres sistemas, en donde cada sistema contiene
un proceso, el cual posee 5 equipos en serie. El equipo 1, equipo 2 y equipo 3
contienen dos mantenimientos con una falla asociada a cada una. El equipo 4 y
5 poseen un mantenimiento con una falla asociada a cada una. En lo que varia
cada sistema es en la forma en que se agruparon los mantenimientos los cuales se
muestran en las Figuras 2.34, 2.35 y 2.36.
Se obtienen tres tipos de resultados para cada sistema. El primer resultado hace
referencia a las curvas de costo de mantenimiento y costo de falla debida a la
2.11 Paralelizacion para equipos en serie 59
Figura 2.35: Estructura interna del proceso correspondiente al Sistema No.2
Figura 2.36: Estructura interna del proceso correspondiente al Sistema No.3
sintonizacion de periodos de mantenimiento (Figura 2.37). El segundo consiste en
un analisis de costos del servicio brindado por el sistema en funcion de periodos
de mantenimiento (Figura 2.38) en donde se mostrara costo P5, P50 y el P95.
Por ultimo ,el tercer resultado consiste en el periodo mantenimiento sugerido para
cada grupo de mantenimiento y el costo asociado dicho periodo (Figura 2.39 y
2.40).
2.11. Paralelizacion de la logica de equipos en
serie con capacidades binarias a traves de
CPU
Para la implementacion de las taxonomıas de paralelizacion, y contando con la
teorıa ya explicada en las secciones anteriores, se procedio a desarrollar varios
disenos de paralelizacion para el ultimo algoritmo implementado. Estos disenos
permitieron comparar el tiempo de simulacion del sistema, el consumo de memo-
ria y la efectividad del mismo.
La Figura 2.41 muestra el diseno original del sistema no paralelizado, donde se
ilustran las diferentes etapas del algoritmo relacionadas coherentemente por el
flujo de datos.
60 2 Descripcion y Analisis de Resultados
Figura 2.37: Graficas de costo de mantenimiento y costo de falla debidas a la
sintonizacion de periodos de mantenimiento para un sistema previamente confi-
gurado
Figura 2.38: Grafica de Costo Total debida a la sintonizacion de periodos de
mantenimiento para un sistema previamente configurado
2.11 Paralelizacion para equipos en serie 61
Figura 2.39: Periodos de mantenimiento sugeridos para los diferentes grupos de-
finidos por el usuario en el modelador
Figura 2.40: Costos asociados a las sintonizaciones llevadas a cabo para cada
uno de los grupos definidos, el primer resultado (izquierda) corresponde a los
costos originales del sistema, mientras a medida de se sintonizan los grupos de
mantenimiento hasta el ultimo resultado (derecha) se tienen los costos respectivos
de la sintonizacion de todos los grupos de mantenimiento
62 2 Descripcion y Analisis de Resultados
Para el desarrollo de la paralelizacion se consideraron diferentes alternativas de-
pendiendo tanto de las herramientas brindadas por Julia, como las ubicaciones
algorıtmicas para desarrollar este proceso. A continuacion se listan las diferentes
aproximaciones con los resultados obtenidos tanto en memoria como en tiempo,
y el diagrama que detalla el computo paralelo.
Metodo 1 (Sin Paralelizacion):
Para la estructura algorıtmica sin paralelizacion, ilustrada en la Figura 2.42, se
obtuvieron los siguientes resultados:
Numero de Procesos utilizados: 1 (El principal)
Tiempo de Procesamiento: 6,3866 Segundos ± 0,0417 Segundos
Memoria RAM Utilizada: 66,1 % ± 0,2 %
Metodo 2 (Paralelizacion bucle):
La paralelizacion del bucle de iteraciones dentro del proceso de Montecarlo, fue
desarrollada con la macro @Parallel de Julia, esta distribuıa las iteraciones en
todos los procesos definidos previamente. Para este metodo se utilizaron 4 Procesos
ademas del principal. La Figura 2.43 ilustra la estructura de paralelizacion usada,
con los siguientes resultados:
Numero de Procesos utilizados: 4 + 1 (El principal)
Tiempo de Procesamiento: 1,7073 Segundos ± 0,0511 Segundos
Memoria RAM Utilizada: 81,3 % ± 0,1 %
Metodo 3 (Paralelizacion bucle):
Para este metodo se reutilizo la macro @Parallel de Julia, pero haciendo uso de
7 Procesos (ademas del principal). La Figura 2.44 ilustra la estructura usada, y
los resultados obtenidos:
2.11 Paralelizacion para equipos en serie 63
Figura 2.41: Algoritmo Computacional sin paralelizacion
Figura 2.42: Estructura para Sistema sin paralelizar
64 2 Descripcion y Analisis de Resultados
Figura 2.43: Estructura para Sistema Paralelizando el bucle de iteraciones con 4
Procesos
Numero de Procesos utilizados: 7 + 1 (El principal)
Tiempo de Procesamiento: 1,5630 Segundos ± 0,0547 Segundos
Memoria RAM Utilizada: 96,8 % ± 0,5 %
Metodo 4 (Canales Remotos):
En este metodo se usaron los RemoteChannels como herramientas de Julia sufi-
cientemente versatiles. En este caso se aplica una estructura tipo SIMD, donde la
instruccion algorıtmica de Simulacion de Eventos Discretos es comun para todos
los procesos, pero los datos obtenidos por cada uno de estos son diferentes. Se
usan primeramente 4 Procesos (ademas del principal). La ilustracion de la Figura
2.45 muestra la estructura, y seguidamente los resultados:
Numero de Procesos utilizados: 4 + 1 (El principal)
Tiempo de Procesamiento: 1,8881 Segundos ± 0,0455 Segundos
Memoria RAM Utilizada: 70,2 % ± 0,2 %
2.11 Paralelizacion para equipos en serie 65
Figura 2.44: Estructura para Sistema Paralelizando el bucle de iteraciones con 7
Procesos
Figura 2.45: Estructura para Sistema Paralelizando con Canales Remotos y con
4 Procesos
66 2 Descripcion y Analisis de Resultados
Figura 2.46: Estructura para Sistema Paralelizando con Canales Remotos y con
7 Procesos
Metodo 5 (Canales Remotos):
Este metodo es simular al Metodo 4 con la diferencia de que los procesos utilizados
en este caso son 7 ademas del principal. La Figura 2.46 muestra la estructura, y
posteriormente los resultados de rendimiento:
Numero de Procesos utilizados: 7 + 1 (El principal)
Tiempo de Procesamiento: 1,6038 Segundos ± 0,0305 Segundos
Memoria RAM Utilizada: 80,2 % ± 0,5 %
Metodo 6 (Metodos 2 y 4):
Para este metodo se utiliza una combinacion de los Canales Remotos y @Parallel
para 4 procesos. La Figura 2.47 muestra la estructura mixta usada aproximada a
un tipo MIMD, y luego los resultados:
Numero de Procesos utilizados: 4 + 1 (El principal)
Tiempo de Procesamiento: 2,1524 Segundos ± 0,0113 Segundos
Memoria RAM Utilizada: 69,6 % ± 0,2 %
2.11 Paralelizacion para equipos en serie 67
Figura 2.47: Estructura para Sistema Paralelizando con Canales Remotos y @Pa-
rallel con 4 Procesos
Metodo 7 (Metodos 3 y 5):
Lo mismo que para el Metodo 6, este metodo realiza lo propio pero con 7 pro-
cesos, La estructura se visualiza en la Figura 2.48 mientras que los resultados se
encuentran seguidamente:
Numero de Procesos utilizados: 7 + 1 (El principal)
Tiempo de Procesamiento: 2,0024 Segundos ± 0,0394 Segundos
Memoria RAM Utilizada: 81,3 % ± 0,1 %
Las Figuras 2.49 y 2.50 muestran la razon de decremento en tiempo de procesa-
miento e incremento de memoria RAM consumida respectivamente, ello durante
el proceso algorıtmico con cada uno de los metodos de paralelizacion explicados
anteriormente.
68 2 Descripcion y Analisis de Resultados
Figura 2.48: Estructura para Sistema Paralelizando con Canales Remotos y @Pa-
rallel con 7 Procesos
Figura 2.49: Comparaciones de tiempo por metodos de paralelizacion respecto a
Simulacion no-paralelizada
2.11 Paralelizacion para equipos en serie 69
Figura 2.50: Comparaciones de memoria RAM por metodos de paralelizacion
respecto a Simulacion no-paralelizada
Capıtulo 3
Evaluacion de Objetivos
Para la evaluacion de los objetivos de la pasantıa, propuestos al iniciar la misma,
se muestra, a continuacion, cada uno de los objetivos y los trabajos desarrollados
junto a sus resultados, dando una breve descripcion de los mismos con las anota-
ciones que dan razon del cumplimiento (total o parcial) o no cumplimiento de los
objetivos.
Objetivo: Seleccion del lenguaje de programacion orientado al
computo paralelo
Resultados Asociados:
Se desarrollo una evaluacion y discriminacion de los diferentes lenguajes de
programacion, en comparacion con Julia, el cual fue escogido como lenguaje
a usar debido a las caracterısticas de rendimiento computacional y algorıtmi-
co que este posee. Ademas se logro una apropiacion del lenguaje a traves de
un entorno de desarrollo integrado con las herramientas de Juno (propio de
Julia) y sobre el editor Atom.
Ası mismo se llevo a cabo una evaluacion en contraste con Matlab (Version
academica R2018a), lenguaje estudiado y trabajado para variadas labores
academicas durante la mayor parte del pregrado, desarrollando un codigo
identico, con las alternativas que ambos lenguajes ofrecıan para el manejo y
procesamiento de datos, dando resultados bastante favorables respecto a la
codificacion hecha en Julia.
72 Evaluacion de Objetivos
Descripcion de cumplimiento de objetivos:
Este objetivo especifico se cumplio en su totalidad al generar un reporte de
rendimiento de Julia en comparacion con otros lenguajes, y desarrollando
procesos algorıtmicos de complejidad moderada y avanzada en cortos tiem-
pos de codificacion, demostrando ası que Julia, como Lenguaje a utilizar
para el desarrollo completo de la pasantıa y para futuras fases del proyec-
to implementado, corresponde a una herramienta de gran versatilidad, y
efectividad.
Objetivo: Integracion entre maquinas a traves de servicios web,
como SSH o aplicativos web.
Resultados Asociados:
Se implemento una comunicacion a traves del par Cliente-Servidor SSH, la
cual permitio la transmision y recepcion de datos de manera simple y con
arquitectura en red local. Con ello se desarrollaron multiples pruebas de co-
municacion entre diferentes sistemas operativos a traves de variadas maqui-
nas computacionales. Dichas pruebas permitieron comprender los conceptos
del servicio SSH y dar pautas para su desarrollo y acople con el entorno de
Julia por medio del IDE Atom.
Durante el desarrollo del Segundo Diseno, y junto al primer modelador desa-
rrollado en una hoja de calculo, se implemento una macro desarrollada en
VisualBasic sobre la cual se ejecutaron comandos en Batch en el sistema ope-
rativo Windows (Ver. 10) para establecer la comunicacion SSH (con apoyo
del software Putty), la cual ejecutarıa comandos Bash en otra maquina con
sistema operativo Ubuntu (Ver. 17), desarrollando actividades de transmi-
sion de lenguaje comunicativo JSON, y recepcion de graficas resultantes.
Descripcion de cumplimiento de objetivos:
El objetivo fue cumplido de manera parcial ya que, aunque se logro una
comunicacion y transmision de datos a traves de servidor SSH, no fue imple-
mentado en fases posteriores del proyecto, donde se utilizo la paralelizacion
del algoritmo desarrollado en Julia. Aunque este correspondıa a un objetivo
de la pasantıa, no fue de gran importancia para el desarrollo total logrado en
el analisis, diseno, prueba e implementacion de un sintonizador de periodos
de mantenimiento con algoritmos computacionales ejecutados en paralelo.
Evaluacion de Objetivos 73
Objetivo: Arquitecturas de programacion que permitan hacer un
procesamiento computacional eficiente.
Resultados Asociados:
Se estudiaron las taxonomıas de Flynn adecuadamente, desarrollando un
analisis de las diferentes alternativas y sus respectivas arquitecturas con el
objetivo de economizar, tiempo y recursos computacionales como la me-
moria temporal (RAM). Ademas se comprendieron y pusieron a prueba las
diferentes herramientas suministradas por Julia para el desarrollo de compu-
to paralelo, asociandolas a su vez con las diferentes arquitecturas y como
podrıan llegar a implementarse de manera efectiva.
Descripcion de cumplimiento de objetivos:
El objetivo se cumplio en su totalidad, logrando una mejor comprension
del computo paralelo y su estrecha relacion con la simulacion de procesos
industriales basados en la simulacion de eventos discretos, ello debido a la
gran cantidad de iteraciones del proceso estocastico llevado a cabo en el
desarrollo, analisis e implementacion de la simulacion
Objetivo: Evaluacion de las estrategias implementadas para pro-
cesamiento computacional.
Resultados Asociados:
Se desarrollaron pruebas de paralelizacion del codigo desarrollado para el
tercer diseno sobre el proceso de Monte Carlo, implementando diferentes
aproximaciones y obteniendo un comparativo de resultados que ilustraron
los consumos de memoria RAM, y el tiempo computacional utilizado por
cada metodo de paralelizacion, los cuales fueron probados bajo el mismo
algoritmo base, y los cuales arrojaron los mismos resultados debidos a las
mismas entradas.
Descripcion de cumplimiento de objetivos:
Este objetivo se cumplio parcialmente ya que era deseado desarrollar parale-
lizacion con arquitecturas mas complejas haciendo uso de multiples procesa-
dores centrales e incluso con procesadores graficos, ello no fue logrado en su
totalidad ya que las alternativas en Julia para el desarrollo de paralelizacion
74 Evaluacion de Objetivos
en GPU se encuentran en estudios y actualizaciones constantes, teniendo
documentacion imprecisa al respecto y con grandes retos ya que varıan los
resultados esperados, segun las especificaciones de hardware y software.
Objetivo: No contemplado como objetivo de la pasantıa.
Resultados y descripcion:
Estas labores no se contemplaron como objetivos originales de la pasantıa,
pero debido a la agilidad con que se desarrollaron los demas objetivos, o
las necesidades y obligaciones contractuales de la empresa, se logro avanzar
en las diferentes fases del Proyecto al desarrollar varios disenos de proce-
samiento de lineas de tiempo, debidas a la simulacion de eventos discretos.
Las lineas de tiempo fueron procesadas primeramente por metodos de Monte
Carlo, y posteriormente en la sintonizacion de periodos de mantenimiento,
donde se hacia la busqueda de los supuestos optimos del sistema.
El resultado del Tercer Diseno junto a la Sintonizacion de Periodos de Man-
tenimiento, constituyeron los puntos claves para el desarrollo de la presen-
tacion final del proyecto, donde se da la muestra de una herramienta capaz
de procesar un sistema industrial configurado por equipos en serie, carac-
terizados probabilısticamente, para un analisis de eventos discretos, el cual
permite la determinacion del periodo de mantenimiento que da lugar al
mınimo costo posible, y pronosticado, del sistema segun la configuracion de
mantenimientos sugeridos.
Conclusiones
Los desarrollos logrados permitieron la apropiacion de multiples conocimientos
que llevaron a la implementacion de diferentes fases del proyecto durante el pe-
riodo de la pasantıa. Los retos asumidos y superados permitieron desarrollar cada
vez experiencias mas importantes que beneficiaron el proyecto de una manera ade-
cuada, ya que los tiempos de aprendizaje se vieron reducidos por la asimilacion
rapida de conceptos y herramientas, los cuales abrieron el paso a mejores desa-
rrollos que fueron logrados paulatinamente con el transcurso del tiempo y con la
creacion de nuevos y mejorados disenos
Es importante notar lo logrado en la eficiencia computacional, la cual fue trabajada
de manera pertinente. Las comparaciones resultantes de las diferentes arquitectu-
ras implementadas tomaron importancia a la hora de desarrollar procesamientos
de sistemas aun mas complejos que llevaron al algoritmo a su maxima expresion,
logrando probar cada una de las alternativas planteadas en el mismo y su impacto
en el rendimiento de los recursos de hardware utilizados.
Por otro lado, el desarrollo de diferentes herramientas, que brindaron apoyos sig-
nificativos para el desarrollo de acciones de computo, fueron fundamentales para
la implementacion de alternativas de solucion a la problematica planteada al inicio
de la pasantıa.
Ası mismo, los recursos humanos puestos a disposicion, tanto por parte de la
Universidad como por parte de la Empresa, fueron de gran importancia para la
creacion e innovacion lograda por el equipo de pasantıa al desarrollar un proyecto
que no poseıa antecedentes claros y accesible. Las teorıas de sintonizacion/opti-
mizacion, los disenos y los desarrollos de hardware fueron resultado de un gran
numero de disertaciones llevadas a cabo entre el grupo de pasantes y el apoyo
suministrado. Dichas disertaciones fueron clave para el exito logrado al final de
76 Conclusiones
la pasantıa, para desarrollar un algoritmo computacional capaz de procesar siste-
mas complejos, junto a un modelador de sistemas industriales que, debido a las
buenas interfases definidas en el transcurso del periodo de pasantıa, logro ser aco-
plado de manera adecuada para brindar el acercamiento preciso hacia una interfaz
Humano-Maquina.
El desarrollo del proyecto de grado en la empresa KNAR SAS, bajo la modalidad
de pasantıa, permitio un acercamiento a la vida laboral y su enlace estrecho con
la vida academica. Los trabajos desarrollados por multiples personas confluyeron
en un grande e importante proyecto que tomo significado con la apropiacion de
los conceptos, la aplicacion de las teorıas de manera adecuada, y los desarrollos
de las interfases entre etapas para la lograda culminacion de una fase importante
de este proyecto desarrollado.
Los resultados obtenidos lograron ser presentados en instancias formales de mayor
nivel, donde los resultados fueron calificados y aceptados con gran gusto, lo cual
demuestra que el desarrollo de un Sintonizador de Periodos de Mantenimiento para
un Sistema Industrial, corresponde a un desarrollo importante para la industria
y la ingenierıa Colombiana que en estos momentos se encuentra en un punto
de avance importante gracias a los desarrollos tecnologicos y cientıficos como el
presentado en este documento.
Bibliografıa
[1] Julia developers, “Julia micro-benchmarks.” https://julialang.org/
benchmarks/, Accedido Febrero 2018.
[2] Voorkant and R. F. Stapelberg, Handbook of Reliability, Availability, Main-
tainability and Safety in Engineering Design. Springer Science & Business
Media, 2009.
[3] Knowledge and Integration Architects, “KNAR SAS.” http://www.
knarsas.net/. Accedido el 2018-01-24.
[4] DNV GL, “Chemical process software Petrochemical plant process solutions
- Taro.” https://www.dnvgl.com/services/. Accedido el 2018-01-24.
[5] Publicaciones Semana S.A., “Analıtica de datos, una de las tecnologıas con
mas futuro en el 2018 en Colombia,” Dinero, p. Tecnologıa, Enero 2018.
[6] Publicaciones Semana S.A., “Abuso de energıa electrica causa danos al medio
ambiente,” Sostenible, Noviembre 2017.
[7] I. Balbaert, Getting Started with Julia Programming. Birmingham, UK: Packt
Publishing, 2015.
[8] Julia Developers, “Julia.” https://julialang.org/. Accedido el 2018-01.
[9] L. B. Gardner, ASTM Committee E-31 on Computerized Systems., and C. In-
ternational Symposium on Automated Integrated Manufacturing (1st : 1983
: San Diego, Automated manufacturing : a symposium. ASTM, 1985.
[10] W. B. Rouse and A. P. Sage, Handbook of systems engineering and manage-
ment. John Wiley & Sons, 2009.
[11] C. Xavier and S. S. S. S. Iyengar, Introduction to parallel algorithms. Wiley,
1998.
BIBLIOGRAFIA 79
[12] M. Abd-El-Barr and H. El-Rewini, Fundamentals of computer organization
and architecture. Wiley, 2005.
[13] Julia, “Julia Documentation.” https://docs.julialang.org/en/v1/, Ac-
cedido el 2018-05-01.
[14] P. Corporation, “Monte Carlo Simulation.” http://www.palisade-lta.
com/risk/simulacion_monte_carlo.asp, Accedido el 2018-05-01.
[15] M. Smithson, Confidence intervals. Sage Publications, 2003.
[16] S. Tatham, “PuTTY - a free SSH and telnet client.” https://www.putty.
org/, Accedido el 2018-04-18.