diseno~ e implementaci on de procesamientos...

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


Lista de Figuras ix


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


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.


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


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 ( )


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


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


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


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


# 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


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


#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.


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:


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.


• 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.


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.


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


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


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


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.


(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


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


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.


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.


(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-


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


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


Figura 2.17: Diagrama general de segunda aproximacion de algoritmo de proce-

samiento


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)


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)


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


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


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


(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


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:


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


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.


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.


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


Figura 2.30: Tercer Diseno para procesamiento de equipos en serie con capacida-

des binarias (Parte 1)


Figura 2.31: Tercer Diseno para procesamiento de equipos en serie con capacida-

des binarias (Parte 2)


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


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



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.


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


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


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)



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:


Figura 2.41: Algoritmo Computacional sin paralelizacion

Figura 2.42: Estructura para Sistema sin paralelizar


Figura 2.43: Estructura para Sistema Paralelizando el bucle de iteraciones con 4

Procesos




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:





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


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:




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:





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:




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.


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


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.


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.


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.


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.


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.


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.


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.

https://julialang.org/benchmarks/

https://julialang.org/benchmarks/

http://www.knarsas.net/

http://www.knarsas.net/

https://www.dnvgl.com/services/

https://julialang.org/

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.

https://docs.julialang.org/en/v1/

http://www.palisade-lta.com/risk/simulacion_monte_carlo.asp

http://www.palisade-lta.com/risk/simulacion_monte_carlo.asp

https://www.putty.org/

https://www.putty.org/