DiseñoeImplementacióndelModeladorparaunSimulador ...repository.udistrital.edu.co/bitstream/11349/14812/1...DiseñoeImplementacióndelModeladorparaunSimulador deEventosDiscretosBasadoenAnálisisRAMconel

Diseño e Implementación del Modelador para un Simuladorde Eventos Discretos Basado en Análisis RAM con el

Cálculo de Disponibilidad y Paralelización del Algoritmodel Simulador (MainTUNER Fase 4)

Cristian Fernando Martínez DuarteDavid Fernando Peña Ortiz

Universidad Distrital Francisco José de CaldasFacultad de Ingeniería

Proyecto Curricular de Ingeniería Electrónica

Bogotá D.C.

2018

Diseño e Implementación del Modelador para un Simuladorde Eventos Discretos Basado en Análisis RAM con el

Cálculo de Disponibilidad y Paralelización del Algoritmodel Simulador (MainTUNER Fase 4)

Cristian Fernando Martínez Duarte Código: 20131005101David Fernando Peña Ortiz Código: 20131005010

Trabajo de grado para optar al título de:Ingenieros Electrónicos

Directora:Diana Marcela Ovalle Martínez. PhD.

Co-Director:Jorge Granada

Especialista Senior en Gestión de Activos y Confiabilidad

Modalidad de GradoPasantía

Universidad Distrital Francisco José de CaldasFacultad de Ingeniería

Proyecto Curricular de Ingeniería ElectrónicaBogotá D.C.

2018

Contenido

Lista de Figuras vii

Lista de Tablas ix

1. Antecedentes 1

2. Planteamiento del problema 7

3. Objetivos 93.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . 9

4. Alcances y Limitaciones 114.1. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5. Marco Teórico 135.1. Análisis RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.2. Modelamiento de procesos industriales . . . . . . . . . . . . . . . 145.3. Simulación de Eventos Discretos y simulación de Monte Carlo . . 155.4. Computo en paralelo . . . . . . . . . . . . . . . . . . . . . . . . . 16

6. Plan de Trabajo 196.1. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.1.1. Etapa 1: Contextualización del proyecto . . . . . . . . . . 206.1.2. Etapa 2: Funcionalidad adicional al algoritmo: cálculo de

disponibilidad del sistema . . . . . . . . . . . . . . . . . . 206.1.3. Etapa 3: Computo en Paralelo del algoritmo . . . . . . . . 206.1.4. Etapa 4: Diseño e implementación del modelador . . . . . 216.1.5. Etapa 5: Diseño e implementación del lenguaje de traspaso

de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

vi CONTENIDO

7. Desarrollo y análisis de resultados 237.0.1. Contextualización del proyecto y del trabajo realizado en

etapas anteriores . . . . . . . . . . . . . . . . . . . . . . . 237.0.2. Introducción al LPL y a la herramienta de modelamiento

desarrollada en la fase anterior . . . . . . . . . . . . . . . . 297.0.3. Revisión de la interfaz gráfica en una herramienta relacio-

nada con el área de trabajo de MainTUNER . . . . . . . . 427.0.4. Selección de la tecnología base para el desarrollo . . . . . . 457.0.5. Formulario web como primera aproximación al modelador . 487.0.6. Desarrollo del modelador en una aplicación híbrida median-

te Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.0.7. Modificación del interpretador para acoplarlo a los requeri-

mientos de la fase 4 . . . . . . . . . . . . . . . . . . . . . . 627.0.8. Interfaz gráfica MainTUNER . . . . . . . . . . . . . . . . 637.0.9. Algoritmo de cálculo de disponibilidad del sistema . . . . . 697.0.10. Computo en paralelo del algoritmo . . . . . . . . . . . . . 78

8. Análisis de cumplimiento de objetivos 938.0.1. Objetivo 1: Diseñar e implementar un algoritmo para el

cálculo de disponibilidad de sistemas genéricos con cone-xiones serie y paralelo en el lenguaje Julia. . . . . . . . . . 93

8.0.2. Objetivo 2: Analizar los métodos de paralelización en el len-guaje Julia, con el fin de implementar el algoritmo paraanálisis RAM en forma paralela. . . . . . . . . . . . . . . . 94

8.0.3. Objetivo 3: Diseñar e implementar, con la tecnología de in-terfaz de usuario seleccionada, una interfaz gráfica en la quese pueda modelar un sistema industrial mediante conexionesserie, paralelo y mixtas. . . . . . . . . . . . . . . . . . . . 95

8.0.4. Objetivo 4: Implementar el estándar de traspaso de datosentre la etapa de modelamiento y las demás etapas de Main-TUNER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

9. Conclusiones 97

Bibliografía 98

Lista de Figuras

1-1. Ejemplo de sistema de 1 equipo . . . . . . . . . . . . . . . . . . . 31-2. Ejemplo de sistema Serie . . . . . . . . . . . . . . . . . . . . . . . 31-3. Ejemplo de sistema Serie-Paralelo . . . . . . . . . . . . . . . . . . 41-4. Ejemplo de sistema MIMO . . . . . . . . . . . . . . . . . . . . . . 5

5-1. Modelo RBD configurado con ramas serie y paralelo [1] . . . . . . 14

6-1. Plan de trabajo de la pasantía . . . . . . . . . . . . . . . . . . . . 20

7-1. IDEF0 del proceso global [2] . . . . . . . . . . . . . . . . . . . . . 237-2. Diagrama IDEF0 de las diferentes etapas del proyecto [2] . . . . . 247-3. Logo LogicProcessLanguage [2] . . . . . . . . . . . . . . . . . . . . 267-4. Jerarquía de proceso en LPL[2] . . . . . . . . . . . . . . . . . . . 287-5. Diagrama IDEF0 de la capa de Interpretación del Modelo [3]. . . 297-6. Entorno principal LPLMod V. 1 . . . . . . . . . . . . . . . . . . . 317-7. Vista de proceso, se incluye (a) un modelo realizado en esta vista,

y (b) parámetros generales de la simulación . . . . . . . . . . . . 33((a)).33 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

subfigure((b)). 337-8. Vista de sistema en LPLMod V.1. . . . . . . . . . . . . . . . . . . 357-9. Vista de equipo en LPLMod V.1. . . . . . . . . . . . . . . . . . . 357-10.Partes de la interfaz gráfica de Arena . . . . . . . . . . . . . . . . 437-11.Ejemplo de un modelo de un proceso de ensamblaje realizado en

Arena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447-12.Parámetros de un componente del modelo de ejemplo en Arena . . 447-13.Parámetros generales de simulación . . . . . . . . . . . . . . . . . 457-14.Logo Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477-15.Parámetros generales del modelo en el formulario . . . . . . . . . 497-16.Parámetros de sistema en el formulario . . . . . . . . . . . . . . . 507-17.Parámetros de grupo de mantenimiento en el formulario . . . . . . 507-18.Partes de un diagrama creado mediante GO.js [4] . . . . . . . . . 547-19.Entorno principal vista de sistema LPLMod V. 2 . . . . . . . . . 55

viii LISTA DE FIGURAS

7-20.Aplicación de la librería inspector para dar características a unequipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7-21.Modelo de siete equipos en serie-paralelo . . . . . . . . . . . . . . 567-22.Sistema mixto LPLMod V.2 . . . . . . . . . . . . . . . . . . . . . 597-23.Interfaz Gráfica de MainTUNER para importación de librerías . . 657-24.Interfaz Gráfica MainTUNER . . . . . . . . . . . . . . . . . . . . 667-25.Interfaz Gráfica MainTUNER en selección del archivo JSON . . . 667-26.Interfaz Gráfica MainTUNER lista para ejecución . . . . . . . . . 677-27.Interfaz Gráfica MainTUNER en ejecución . . . . . . . . . . . . . 687-28.Esquema del algoritmo de capacidades . . . . . . . . . . . . . . . 697-29.Diagrama de flujo de la función de cálculo de capacidades . . . . . 717-30.Diagrama de flujo del retorno de la función conteo de capacidad

por iteración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727-31.Diagrama de flujo del retorno de la función de cálculo de capacidades 737-32.Diagrama de flujo MainTUNER para la prueba de paralelización . 867-33.Diagrama de flujo del algoritmo de MainTUNER sin paralelización 877-34.Diagrama de flujo del algoritmo de MainTUNER con paralelización 887-35.Sistema para la prueba de paralelización . . . . . . . . . . . . . . 897-36.Monitor de recursos . . . . . . . . . . . . . . . . . . . . . . . . . 90

Lista de Tablas

7-1. Variables de Salida en la Interpretación del Modelo [3] . . . . . . 307-2. Tipos de sistemas presentes en LPLMod V.1 . . . . . . . . . . . . 347-3. Parámetros generales del ejemplo en LPLMod V.1 . . . . . . . . . 367-4. Parámetros del modelo de ejemplo en la vista de proceso . . . . . 367-5. Parámetros de los equipos, eventos, para el modelo de ejemplo en

LPLMod V.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377-6. Parámetros del grupo de mantenimiento para el ejemplo . . . . . 377-7. Objetos utilizados para el cálculo de capacidades . . . . . . . . . 707-8. Matriz de eventos procesaos de prueba . . . . . . . . . . . . . . . 747-9. Matriz de pérdidas de capacidades al iniciar la prueba . . . . . . . 757-10.Matriz de pérdidas de capacidades al terminar la prueba . . . . . 767-11.Matriz de resultado final . . . . . . . . . . . . . . . . . . . . . . . 777-12.Resultados de la paralelización del código de MainTUNER FASE 3 887-13.Resultados de la paralelización del código de MainTUNER FASE

4: Carga de librerías . . . . . . . . . . . . . . . . . . . . . . . . . 917-14.Resultados de la paralelización del código de MainTUNER FASE

4: Ejecución algoritmo . . . . . . . . . . . . . . . . . . . . . . . . 917-15.Resultados de la paralelización del código de MainTUNER FASE 4 92

Capítulo 1Antecedentes

El crecimiento del sector industrial en Colombia ha llevado a las empresas a re-gistrar la información del desempeño de los equipos, que conforman los sistemasinvolucrados en los procesos de producción. Con estos datos, se pueden realizardiagnósticos y previsiones para aumentar la productividad. Para las empresassiempre es conveniente tener procesos de producción eficientes, tanto energéticacomo económicamente. En el ámbito real del mercado, el costo de producción noes la única variable negativa en el momento de realizar un balance para una em-presa, también se debe tener en cuenta el costo que aparece cuando un equipo salede funcionamiento, que es el resultado de la sumatoria entre el costo de manteni-miento o cambio y el costo por flujo cesante, que es el dinero que deja de percibirla empresa por que sus equipos no funcionan a su total capacidad y por ende laproductividad no es la máxima.

En los diagnósticos de desempeño, generalmente, se tienen en cuenta dos modoso eventos, que afectan la capacidad y disponibilidad de los equipos dentro delsistema: los mantenimientos preventivos y los mantenimientos correctivos [5]. Losprimeros se realizan con el fin de evitar la ocurrencia de una falla. Los segundos serealizan una vez la falla ya ha ocurrido. Cuando los mantenimientos preventivos serealizan muy distanciados en el tiempo, las fallas aparecen con más frecuencia, loque lleva a un aumento de la no disponibilidad y por ende del costo de flujo cesante.

Si por el contrario, los mantenimientos preventivos se realizan muy frecuente-mente, estos por si solos mantendrán al sistema funcionando a baja capacidad,aumentando el costo de flujo cesante. En este orden de ideas, es necesario hallarun período mantenimiento preventivo que evite la aparición de fallas de formafrecuente y que, además, tenga al sistema funcionando la mayor parte del tiempo.Para esto, las industrias hacen uso del análisis RAM, (por sus siglas en inglésReliability, Availability and Maintainability). Estos diagnósticos de desempeño,suelen ser complejos pues deben tener en cuenta todas las variables involucradasen el proceso industrial que son en su mayoría, de naturaleza estocástica.

2 1 Antecedentes

Actualmente, las herramientas de simulación permiten modelar sistemas de diversacomplejidad y presentan a los usuarios la facilidad tanto de modificar parámetrosdentro de los procesos de producción, sin alterar físicamente la disposición de losequipos, así como tener una aproximación de la producción total y de los costosasociados a esta. Uniendo la idea de buscar un período de mantenimiento quereduzca costos y permita la mayor disponibilidad, con la de una herramienta desimulación que permita modelar y obtener resultados basados en parámetros pro-pios de un sistema industrial, surge el problema tratado en esta pasantía.

La empresa colombiana Knowledge and Integration Architects S.A.S (Knar), ubi-cada en la ciudad de Bogotá, se dedica a la consultoría en gestión de infraestruc-tura física, propiedades, planta y equipos [6]. Actualmente, Knar trabaja con unaherramienta de simulación llamada Taro, basada en el procesamiento de eventosdiscretos, enfocada en sistemas de extracción y transporte de crudo, desarrolladapor la empresa DVN GL, la cual presenta baja flexibilidad, costos elevados enlicencia y no está enfocada en hallar períodos de mantenimiento que reduzcanlos costos asociados a la ocurrencia de eventos que reduzcan la disponibilidad delsistema [7].

Proyecto MainTUNER

MainTUNER surge a partir de la idea de mejorar el desempeño de un procesoindustrial, en términos de costos y producción, encontrando mejores periodos demantenimiento para los equipos del sistema industrial a analizar, de tal forma quese eviten lo más posible las fallas que puedan ocasionarse en los equipos, peroconsiguiendo a la vez un mínimo de mantenimientos preventivos a lo largo delciclo de vida del sistema.

Con el fin de desarrollar una herramienta de simulación que esté en capacidad desuperar las limitaciones de Taro, desde enero de 2018, a partir de pasantías con laUniversidad Nacional de Colombia (sede Bogotá) y la Universidad Distrital “Fran-cisco José de Caldas”, Knar ha venido trabajando en el desarrollo de un programade sintonización de mantenimientos, llamado MainTUNER. En un principio, elproyecto MainTUNER fue estructurado en 5 fases, detalladas a continuación.

3

Fase 1: MainTUNER Versión 0.1

En esta fase se desarrolló la contextualización de la versión inicial del métodode sintonización de costos de los componentes del ciclo de vida de un equipo,asociados con mantenimiento y riesgo operacional, aplicado a un escenario inicial.Se realizó un estudio del estado del arte del tema de sintonización de costos parala conceptualización del proyecto.


En esta fase se realiza una aproximación del algoritmo basado en simulación deeventos discretos para un sistema de un solo equipo, como se muestra en la figura1-1. Se integra a la fase 1 con el objetivo de verificar si la versión 0.1 logra lasintonización de costo para un sistema simplificado a un equipo.

In // Equipo // Out

Figura 1-1: Ejemplo de sistema de 1 equipo


En esta fase se realiza una nueva aproximación del algoritmo para el procesamientode un sistema conformado por equipos conectados en serie, como se muestra en lafigura 1-2. Se integra a las fases anteriores para verificar que se logra una correctasintonización de costos para esta configuración de equipos.

In // Equipo1 // Equipo2 // Out

Figura 1-2: Ejemplo de sistema Serie

Con respecto a la anterior fase, se adiciona:

Algoritmo para el sistema de conexión serie entre equipos

Cálculo de disponibilidad y costos para el sistema

Sintonización de costos en función de los periodos de mantenimiento para elsistema serie.

4 1 Antecedentes


En esta fase se realiza una mejora a la aproximación del algoritmo, para el pro-cesamiento de un sistema conformado por equipos conectados en serie y paralelo,con la limitante de tener un único flujo de entrada/salida, sistema tipo SISO, co-mo se muestra en la figura 1-3. Se integra a las fases anteriores para verificar quese logra una correcta sintonización de costos para esta configuración de equipos.

In // Equipo1 // Equipo2 //

// Equipo3

Out

Figura 1-3: Ejemplo de sistema Serie-Paralelo


Algoritmo para el sistema de conexión paralelo entre equipos

Cálculo de capacidades para el sistema (Actualización de cálculo de dispo-nibilidad)

Sintonización de costos en función de los periodos de mantenimiento para elsistema serie-paralelo

Paralelización del algoritmo utilizado en el proceso de MonteCarlo


En esta última fase, se realiza una aproximación final a MainTUNER, que permitahacer el procesamiento de un sistema conformado por equipos conectados de formatipo MIMO (Múltiples entradas, múltiples salidas), como se muestra en la figura1-4. Se integra a las fases anteriores para verificar que se logra una correctasintonización de costos para esta configuración de equipos.

5

In1 // Equipo1 // Equipo4 // Out1

// Equipo3 //

In2 // Equipo2 // Equipo5 // Out2

Figura 1-4: Ejemplo de sistema MIMO


Algoritmo para el sistema de conexión mixta entre equipos

Sintonización de costos en función de los periodos de mantenimiento para elsistema mixto

Una vez definidas las fases, KNAR SAS, en colaboración con pasantes anterioresrealizaron la ejecución de las fases 1, 2 y 3. Es decir, en esta pasantía se trabajará apartir de la fase 4, teniendo como base lo realizado hasta la fase 3 (Procesamientode sistemas de conexión únicamente serie).

Modelador

Como se mencionó anteriormente MainTUNER posee tres etapas, la primera deellas y con la que el usuario interactúa directamente es la etapa de modelamiento.En esta etapa, el usuario dispondrá de una interfaz gráfica en la cual arrastrabloques que representan equipos, con la opción de añadir el tipo de conexionesmediante otros bloques y lineas que los unen.

En cada equipo es posible configurar los tipos de no disponibilidad (Falla o man-tenimiento), con sus respectivas distribuciones de probabilidad. En esta etapa, elusuario configura su sistema para que al finalizar el modelador, por medio de unlenguaje comunicativo, se conecte al algoritmo que realizará el análisis RAM.

Actualmente, el modelador está diseñado en Java utilizando un plugin de mode-lamiento. Debido a la poca documentación acerca del diseño del modelador y a la

6 1 Antecedentes

imposibilidad de acceder a modificar el modelador es necesario cambiarlo. Por loque el modelador actual solo tendrá la función de generar sistemas para las prue-bas del rediseño de la etapa de simulación. Además de esto se utiliza el formatoJSON, (acrónimo de JavaScript Object Notation), para realizar la transición ha-cia la etapa de simulación, lo que implica un algoritmo de interpretación previa,que actualmente realiza modificaciones en la información procedente de la etapade modelamiento, pues esta no se encuentra completa y con el transcurrir de lasdiferentes etapas del proyecto, se ha quedado corta en cuanto a funcionalidad.

Uno de los objetivos de la pasantía es diseñar el modelador de nuevo de formaque sea más amigable con el usuario, por lo tanto, es necesario hacer un análisisde requerimientos y tomar del antiguo modelador elementos que se consideranútiles para el nuevo diseño, así como simplificar el lenguaje de transición entrelas etapas de tal forma que el algoritmo de interpretación no tenga que realizarmodificaciones a la información previo al traspaso a la etapa de simulación.

Capítulo 2

Planteamiento del problema

El proyecto MainTUNER está listo para iniciar la fase 4 de desarrollo en la cual sebusca principalmente elevar la complejidad de los sistemas que desean sintonizar,teniendo en cuenta la capacidad de cada equipo dentro del proceso, para esto serequiere una interfaz gráfica en la cual se pueda proporcionar un modelo que tengaen cuenta dirección de flujo, múltiples entradas y salidas, y parámetros propiosde cada equipo, como la capacidad y el rendimiento. También se requiere mejoraren la capacidad de cómputo y para esto se buscarán métodos de paralelización detal forma que el tiempo de simulación se reduzca.

La fase 4 se encuentra dividida en tres etapas: modelamiento, simulación y sin-tonización, en lo que corresponde a esta pasantía, se abarcarán las etapas demodelamiento y una parte de la simulación. Se buscará implementar un modela-dor que permita al usuario describir un sistema industrial por medio de relacionesentre bloques e ingresar los parámetros necesarios para el funcionamiento de losalgoritmos presentes en las etapas de simulación y sintonización. En cuanto a laetapa de simulación, se diseñará e implementará un algoritmo que calcule la capa-cidad y disponibilidad del sistema y se implementará un método de paralelizaciónque permita que MainTUNER aproveche la capacidad de cómputo de la máquinaen donde se corra.

Capítulo 3

Objetivos

3.1. Objetivo general

Desarrollar un “modelador” para la herramienta de simulación MainTUNER yagregar funcionalidades como paralelización y cálculo de disponibilidad.

3.2. Objetivos específicos

1. Diseñar e implementar un algoritmo para el cálculo de disponibilidad desistemas genéricos con conexiones serie y paralelo en el lenguaje Julia.

2. Analizar los métodos de paralelización en el lenguaje Julia, con el fin deimplementar el algoritmo para análisis RAM en forma paralela.

3. Diseñar e implementar, con la tecnología de interfaz de usuario selecciona-da, una interfaz gráfica en la que se pueda modelar un sistema industrialmediante conexiones serie, paralelo y mixtas.

4. Implementar el estándar de traspaso de datos entre la etapa de modelamien-to y las demás etapas de MainTUNER.

Capítulo 4

Alcances y Limitaciones

4.1. Alcances

Considerando que en el desarrollo de esta pasantía se obtendrá una porción de lafase 4 del proyecto MainTUNER, su alcance estará sujeto al modelador utilizadopor la herramienta de análisis RAM y el cálculo de disponibilidad en el algoritmode la herramienta, así como de su paralelización.

El modelador, al final de esta pasantía, cumplirá con las siguientes funciones:

Permitir al usuario de forma gráfica describir cualquier sistema industrial,mediante relaciones jerárquicas donde los niveles en orden ascendente son:equipo, sistema y proceso. En cada nivel de jerarquía existen unos paráme-tros propios que son dados por el usuario.

Crear relaciones tipo serie, paralelo y mixto entre los equipos indicando unadirección de flujo.

Agregar a cada equipo modos de falla y mantenimientos asociados a estas,cada uno con parámetros propios.

Obtener un modelo en formato JSON que haga la transición hacia la etapade simulación, pasando los datos de tal forma que sean fácilmente interpre-tables.

Las funcionalidades adicionales al algoritmo de análisis RAM cumplirá las siguien-tes funciones:

12 4 Alcances y Limitaciones

Utilización de todos o algunos de los procesadores que posea el equipo en elque se realiza la ejecución del análisis RAM

Cálculo de Disponibilidad del sistema analizado con información estadísticaal realizar el método de Montecarlo.

Cálculo de costos debido al no funcionamiento del sistema analizado (Costode lucro cesante), utilizando el cálculo de disponibilidad del sistema.

4.2. Limitaciones

Como se había mencionado en los alcances, el proyecto estará limitado en cuantoa que se desarrollará una parte de la fase 4 en el desarrollo de MainTUNER. Porende, las limitaciones estarán sujetas a:

Algoritmo de la simulación de eventos discretos utilizada para realizar elmétodo de Montecarlo.

Métodos de paralelización que posee Julia y la documentación en diversasaplicaciones.

Funcionalidades propias de la tecnología seleccionada para el desarrollo delnuevo modelador.

Capítulo 5

Marco Teórico

5.1. Análisis RAM

Estudio que se realiza con el fin de optimizar el rendimiento de un sistema, minimi-zar la pérdida de producción debida a fallos (tanto sean seguros como peligrosos)y requerimientos de mantenimiento e inspección, e identificar los equipos más crí-ticos para el funcionamiento óptimo del proceso. Los conceptos básicos a tener encuenta dentro del análisis RAM son:

Proceso industrial: Conjunto de operaciones y procedimientos aplicadosa la materia prima con el objetivo de obtener algún beneficio económico dela transformación de esta [8].

Disponibilidad: La proporción del tiempo en la que el sistema está dispo-nible para operar correctamente [9].

Mantenibilidad: Probabilidad de que un equipo en fallo sea restaurado auna situación operativa normal en un periodo de tiempo específico [9].

Confiabilidad: Probabilidad de que un equipo desempeñe una función re-querida, bajo unas condiciones definidas, durante un periodo de tiempo de-finido [9].

14 5 Marco Teórico

5.2. Modelamiento de procesos industriales

La primera etapa de una herramienta de simulación es la encargada de interactuarcon el usuario y la que permite la entrada de información abstraída del procesoindustrial, aquí se determina qué elementos quedarán dentro del alcance de lasimulación y cuáles no se tendrán en cuenta. Cuando se realiza análisis RAM elpaso inicial es definir un modelo abstracto en el cual se ingresan los parámetrosde las funciones de distribución de probabilidad relacionadas con los eventos queafectan la disponibilidad del sistema, esto se conoce como RBD, (por sus siglasen inglés Reliability Block Diagram) [10].

La complejidad de los modelos RBD puede ir desde sistemas simples compuestospor bloques en serie, hasta sistemas conformados por combinaciones de bloquesen serie y paralelo [1]. En un modelo RBD, debe existir un nodo de entrada yun nodo de salida. Para que el diagrama sea lógico, los bloques configurados yasea en serie, paralelo o mixto, estarán entre estos nodos. La Figura 5-1, detallauna configuración de bloques relacionados de manera mixta, aquí se observan losnodos de entrada y salida.

Figura 5-1: Modelo RBD configurado con ramas serie y paralelo [1]

Cuanta mayor cantidad de información un modelo abstraiga del proceso industrial,el resultado de la simulación para el análisis RAM será mas confiable. Una vezmodelado el diagrama de bloques se debe realizar una lista de suposiciones paraque las relaciones entre los bloques y modos que causan los diferentes cambios de

5.3 Simulación de Eventos Discretos y simulación de Monte Carlo 15

estado sean mas sencillos de entender. Además de esta, la lista de suposicionesbrinda las siguientes ventajas :

Facilita a otros especialistas que vayan a realizar análisis RAM entender elmodelo realizado.

Cuando se realiza algún cambio en el modelo, una nueva lista de suposicionespuede ser creada y comparada con la versión anterior que poseía el modelo.

5.3. Simulación de Eventos Discretos y simulaciónde Monte Carlo

La simulación de Eventos Discretos (SED) utiliza un modelo matemático y lógicode un sistema físico que retrata los cambios de estado en puntos precisos del tiempode simulación. Tanto la naturaleza del cambio de estado y el tiempo en el que seproduce el cambio se produce en tiempos precisos de tiempo (Discretos) [11]. Lossistema de clientes esperando por el servicio, el manejo de piezas de inventario oel ejército militar son típicos ejemplos de SED [12].

Las partes que componen una SED se mencionan a continuación [13]:

Estado: Colección de variables que describen el sistema en cualquier mo-mento.

Variables (Globales): Son información que refleja alguna característicadel sistema independientemente de las entidades de este.

Entidades: Son objetos dinámicos que cambian de estado y afectan y sonafectados por otras entidades en el estado del sistema. Se mueven duranteel tiempo de la simulación. Todas las entidades deben ser creadas. Específi-camente en el proyecto serán los Equipos.

Actividades: Intervalo de tiempo en el que ocurre los cambios de estado,es decir, el tiempo de duración después de un evento. Específicamente en elproyecto serán la duración de eventos.

Evento: Instante de tiempo en el que se da un cambio de estado en elsistema. Específicamente en el proyecto serán la ocurrencia de las actividadesde falla o duración.

16 5 Marco Teórico

Reloj de simulación: Medición de la separación de Eventos. Mantieneel registro del tiempo. Este reloj no registra el paso del tiempo de formacontinua, sino que salta del tiempo de un evento al tiempo del siguiente.Para ello, el reloj de simulación interactúa con la línea de tiempo tiempo desimulación requerido.

La simulación de Monte Carlo es la generación de objetos o procesos aleatoriosen un computador. Estos objetos pueden surgir "naturalmenteçomo parte de unmodelamiento de un sistema de la vida real, como una compleja vía férrea, trans-porte de neutrones o la evolución del inventario de un almacén. En muchos casos,los objetos aleatorios son introducidos artificialmente para resolver un problemapuramente determinístico por ejemplo el valor de pi [14].

La idea del método de Monte Carlo es repetir un experimento muchas veces paraobtener muchos resultados de interés utilizando la ley de los grandes números yotros métodos de inferencia estadística.

5.4. Computo en paralelo

El computo en paralelo es una forma de cómputo en la que muchas instruccionesse ejecutan simultáneamente. En general, los problemas grandes pueden ser redu-cidos en problemas más pequeños, los cuales se pueden resolver al mismo tiempo(Paralelismo). En resumen, hay varias formas diferentes de computación paralela:paralelismo a nivel de bit, paralelismos a nivel de instrucción, paralelismo de datosy paralelismo de tareas [15].

Paralelismo a nivel de bit: Esta forma de paralelismo es usada parasumar 2 números en binario, dividiendo el problema y sumando cadenas debits más cortas.

Paralelismo a nivel de instrucción: Un programa de ordenador es, enesencia, una secuencia de instrucciones ejecutadas por un procesador. Es-tas instrucciones pueden reordenarse y combinarse en grupos que luego sonejecutadas en paralelo sin cambiar el resultado del programa. Actualmentecon la ayuda de los “pipelines” de los procesadores se realiza este tipo deparalelización.

5.4 Computo en paralelo 17

Paralelismo de datos: Distribuye el conjuntos de datos a través de múl-tiple procesadores. La misma tarea es ejecutada en paralelo con diferentesconjuntos de datos .

Paralelismo de tareas: Asigna porciones del espacio de búsqueda a di-ferente procesadores. Entonces, diferentes tareas ocurren con los mismosdatos. Hay dos tipos de paralelismo de tareas: Basado en la estrategia dedivide y vencerás y el basado en cola de tareas; el primero, divide el espaciode búsqueda y le asigna cada partición a un procesador en especifico; el se-gundo, asigna dinámicamente pequeñas porciones del espacio de búsquedaa un procesador cuando está disponible .

Paralelismo Híbrido de datos y tareas: Es un paralelismo de segmen-tación (pipeline) de tareas, dónde cada tarea tendrá datos paralelizados yla salida de una tarea es la entrada de la siguiente [16].

Capítulo 6

Plan de Trabajo

6.1. Metodología

La metodología utilizada en el proyecto consiste de 5 etapas para resolver los ob-jetivos propuestos en este documento (Figura 6-1). La primera etapa consistiráen la contextualización del proyecto, en esta etapa se aprenderá todas las herra-mientas necesarias para modificar el algoritmo utilizado y una inicialización en elambiente de trabajo de la empresa.

Al completar esta etapa se dará inicio a la resolución de los objetivos del docu-mento, por lo tanto, la segunda etapa es la de añadir una nueva funcionalidadal algoritmo: el cálculo de disponibilidad del sistema y la tercera etapa; computoen paralelo del algoritmo. Estas dos etapas corresponden directamente al códigoutilizado para realizar el análisis RAM.

La cuarta etapa corresponde al diseño e implementación del nuevo modelador,para lo cual se verifican las tecnologías disponibles, se escogerá una y se procederáal diseño del nuevo modelador en esta tecnología.

La última etapa corresponde a la implementación del estándar de trasmisión dedatos JSON en el modelador y la correspondiente lectura de este en un procesointermedio entre el modelador y las demás etapas de MainTuner. A continuación,se hará un detalle en cada etapa que compone el desarrollo de esta pasantía.

20 6 Plan de Trabajo

Figura 6-1: Plan de trabajo de la pasantía

6.1.1. Etapa 1: Contextualización del proyecto

En esta primera etapa, el objetivo es conocer la metodología de trabajo de laempresa y conocer los desarrollos alcanzados, se conocerá el algoritmo de análisisRAM, el modelador utilizado hasta el momento y se realizará una introducción allenguaje de programación Julia. También se realizará el análisis de requerimientospara las etapas posteriores.

6.1.2. Etapa 2: Funcionalidad adicional al algoritmo: cálcu-lo de disponibilidad del sistema

En esta segunda etapa, se da solución al primer objetivo específico, para ello conlas herramientas y habilidades adquiridas en la etapa 1 se procede al diseño y suposterior implementación del algoritmo de cálculo de disponibilidad del sistemautilizando el lenguaje de programación Julia. Adicionalmente se debe garantizarun acople de la información enviada (Capacidad del sistema en una simulación ylos costos) con el algortimo de simulación de Monte Carlo.

6.1.3. Etapa 3: Computo en Paralelo del algoritmo

En esta etapa se da solución al segundo objetivo específico, por lo tanto, se reali-zará una investigación en la documentación del lenguaje Julia sobre métodos de

6.1 Metodología 21

paralelización. Se realizarán pruebas sobre estos métodos y con base en ellos serealizará una paralelización del algoritmo de análisis RAM para la simulación deMonte Carlo.

Al finalizar esta etapa se da por terminado la intervención sobre el algoritmoutilizado para el análisis y simulación.

6.1.4. Etapa 4: Diseño e implementación del modelador

En esta etapa se da solución al tercer objetivo específico, para ello se investigarásobre tecnologías para el desarrollo gráfico, se seleccionará una y desarrollará elnuevo modelador, de acuerdo a la experiencia con el modelador utilizado en lasfases 2 y 3 de MainTUNER, y con los requerimientos para las fases 4 y 5.

6.1.5. Etapa 5: Diseño e implementación del lenguaje detraspaso de datos

El objetivo de esta etapa es obtener una estructura que describa de forma com-pleta y mediante el estándar de traspaso de datos JSON, todas las relaciones ycaracterísticas presentes en el sistema modelado.

Una vez obtenido el JSON del modelo, se realizará el diseño e implementación deun algoritmo interpretador que será el encargado de realizar la traducción desdeel formato JSON hacia el lenguaje Julia.

Capítulo 7

Desarrollo y análisis de resultados

7.0.1. Contextualización del proyecto y del trabajo realiza-do en etapas anteriores

El proyecto MainTUNER busca el desarrollo de una herramienta que permitaobtener pronósticos de desempeño técnico y financiero, tomando como base laocurrencia, duración, y costos de las fallas y los mantenimientos que afectan unproceso industrial durante un tiempo determinado.

En la figura 7-1 se muestra el IDEF0 del proceso global del proyecto MainTUNER,estructurado en las etapas anteriores.

Figura 7-1: IDEF0 del proceso global [2]

MainTUNER está dividido en tres etapas que contribuyen al desarrollo de laherramienta, son: Modelamiento, Simulación de Eventos Discretos (SED) y Pa-

24 7 Desarrollo y análisis de resultados

Figura 7-2: Diagrama IDEF0 de las diferentes etapas del proyecto [2]

ralelización y sintonización. A continuación se presenta una descripción breve decada una de estas. En la Figura 7-2 se ilustra el diagrama IDEF0 de las diferentesetapas del proyecto

Modelamiento: Luego de que el usuario realice la abstracción de un mode-lo del sistema que desea simular, de forma gráfica se ingresan las relacionesentre los equipos. Posteriormente se relacionan los eventos que afectan ladisponibilidad del sistema (fallas y mantenimientos) y los costos asociadosa estos. A esto se denomina Modelo comunicativo. Una vez realizado elModelo comunicativo, esta etapa realiza la traducción a un Modelo infor-mático, que incluye todos los datos, parámetros y relaciones ingresados deforma gráfica. Finalmente, el Modelo informático se traduce a un lenguajede programación, incluyendo variables y constantes que serán usadas por laetapa siguiente. Más adelante se realizará una descripción más detallada deesta sección

Simulación de Eventos Discretos (SED): Con las variables obtenidasde la etapa de Modelamiento, se realiza el encolamiento de los eventos aso-ciados a los equipos que integran el proceso industrial durante el tiempo devida que se desea simular. Esto se realiza de forma iterativa aplicando unproceso de Monte Carlo, de aquí se obtienen datos estadísticos de costo queserán entregados a la siguiente etapa usando percentiles.

25

Paralelización y Sintonización: Esta etapa se busca implementar méto-dos que permitan aprovechar de una mejor forma los recursos de cómputopara que el algoritmo disminuya su tiempo de ejecución. Usando los datosde costo que entrega la etapa SED, esta etapa se encarga de aplicar métodosque permitan sintonizar los períodos de mantenimiento, con el objetivo dedisminuir los costos.

Lenguaje de programación Julia Language

El lenguaje seleccionado para las primeras fases del proyecto fue Julia, por lotanto, las siguientes fases seguirán utilizando este mismo lenguaje en su versión0.6.

Julia es un lenguaje científico de alto rendimiento. Julia es un lenguaje dinámico,por lo tanto no es necesaria la declaración explicita del tipo de una variable,similar a Python. Además Julia ofrece un alto nivel computacional en cálculosmatemáticos, por estas razones fue escogido como lenguaje de programación parael proyecto.

En las primeras fases del proyecto se realizó la contextualización sobre el len-guaje, el conocimiento sobre su estructura y una pruebas preliminares para elacercamiento hacia este.

Se realizó una investigación basado en la documentación técnica que Julia brindaal público. Adquiriendo los conceptos más importantes para la paralelización y elmanejo de matrices n dimensionales.

Manejo de herramientas de repositorios

Para una correcta implementación y fácil corrección de errores se utiliza un sis-tema de versionamiento como git con el objetivo de tener claro los avances entreversiones y un control sobre estos.

En la primera fase del proyecto se realizó el uso de la herramienta de repositoriobitbucket.org, ya que ofrece la posibilidad de tener repositorios privados con unmáximo de 5 usuarios. Es importante garantizar la privacidad de los datos para


la empresa por esta razón se eligió esta herramienta.

Se realizó una investigación en los términos para utilizar el repositorio como fetch,push, pull y commit [17].

Fetch: Este comando recupera todos los datos del proyecto remoto que no setenga todavía.

Push: Envio de datos del repositorio local al repositorio remoto.

Pull: Incorpora los cambios de un repositorio remoto a la actual rama del proyectolocal.

Commit: Registro de los cambios del repositorio local para luego ser enviadospor "push".

Con estos conceptos y Bitbucket se realizó un manejo del repositorio del proyecto.

Lenguaje LogicProcess (LPL) y herramienta de modelamiento

En la fase anterior del proyecto se desarrolló un lenguaje de modelamiento de-nominado LogicProcessLanguage (Figura 7-3) en el que se agrupan los conceptossobre los cuales se basan los desarrollos en las tres etapas de MainTUNER. Basa-do en este lenguaje, se implementó en Java una herramienta de modelamiento enla cual se realiza la interacción con el usuario. Los conceptos en LPL involucrandefiniciones generales, las cuales agrupan los términos base del proyecto; y defi-niciones del modelador, estos conceptos involucran funcionalidades propias de laherramienta desarrollada en Java.

Figura 7-3: Logo LogicProcessLanguage [2].

27

Conceptos generales LPL

Jerarquía del sistema industrial: Hace referencia a los niveles de análisisdentro de un proceso industrial. En la Figura , se ilustra la organización deesta jerarquía en LPL.

Proceso: Es el universo de análisis, se encuentra conformado por sistemasy representa a la planta industrial de forma general.

Falla: Es un evento no programado cuya ocurrencia está descrita por unafunción de distribución de probabilidad (normalmente de tipo Weibull, Nor-mal o Lognormal), y su duración es probabilísticamente estimada. Es laabstracción de las afectaciones que pueden ocurrir en cualquier momento aun equipo estando en funcionamiento. La duración hace referencia al tiempode reparación de la falla. Una falla puede estar asociada o no a un manteni-miento.

Mantenimiento: Es un evento programado, cuya duración y ocurrencia sonconocidas. La ocurrencia está determinada por la operación, (tiempo duranteel cual el equipo ha estado activo) o calendario (fechas específicas). Unmantenimiento siempre estará asociado a una falla y retardará la ocurrenciade esta dentro del tiempo de simulación.

Costos: Dentro de LPL se definen dos tipos de costo

• Costo de evento: Asociados a la ocurrencia y duración de fallas y man-tenimientos.

• Costo por lucro cesante: Es el dinero que deja de percibir una industriapor no funcionar a su máxima capacidad.

Ciclo de vida y Número de Iteraciones: El primero hace refencia altiempo total sobre el cual se va a simular, y el segundo parámetro estáasociado al proceso de Monte carlo empleado para realizar el proceso decómputo.

Grupo de mantenimiento: Asociación de mantenimientos cuyas duracio-nes se considera pueden ser modificadas para evaluar efectos en los costosdel sistema. Está descrito por los siguientes parámetros:

• Periodo máximo - MaxPer : Período máximo hasta el cual se realizaráel barrido, dentro de la etapa de sintonización de mantenimientos.

• Periodo mínimo - MinPer : Período mínimo desde el cual se realizaráel barrido, dentro de la etapa de sintonización de mantenimientos.


• Tamaño del paso - PerChange: Tamaño del paso al realizar el barrido,dentro de la etapa de sintonización de mantenimientos.

• Identificador - Id : Número único que identifica al grupo de manteni-miento.

Figura 7-4: Jerarquía de proceso en LPL[2].

Herramienta de modelamiento basada en Java

Tomando como base los conceptos generales de LPL, se desarrolló en la primerafase del proyecto una herramienta de modelamiento por medio del lenguaje deprogramación Java, y haciendo uso del IDE Eclipse Modelling Tools. Incorporabaun diagramador con tres vistas diferentes: Proceso, Sistema y Equipo, (ver Figura) y permitía la traducción desde el modelo gráfico hacia un lenguaje comunicativoque será usado en la etapa de Interpretación del modelo (ver Figura 7-2). Enla sección 7.0.2 se describen de forma más detallada las funcionalidades de estaherramienta.

29

Modelo comunicativo JSON e Interpretador

A partir de la herramienta de modelamiento, se obtenía un archivo formato JSON(del inglés JavaScript Notation Object) que contenia los datos y parámetros in-cluidos por el usuario en la interfaz gráfica. JSON es un formato ligero de inter-cambio de datos. Leerlo y escribirlo es simple para humanos, mientras que paralas máquinas es simple interpretarlo y generarlo. [18]. La capa de interpretaciónfue codificada en lenguaje Julia y es la encargada de declarar las variables glo-bales usadas en la etapas posteriores. SU estructura se ilustra en por medio deldiagrama IDEF0 mostrado en la Figura . En las fase anterior del proyecto, delarchivo JSON el interpretador obtenía las variables globales descritas en la tabla.

Figura 7-5: Diagrama IDEF0 de la capa de Interpretación del Modelo [3].

7.0.2. Introducción al LPL y a la herramienta de modela-miento desarrollada en la fase anterior

Para iniciar con el desarrollo del nuevo modelador,(en adelante LPLMod V.2),fue necesario remitirse a la herramienta desarrollada en la fase anterior (en ade-lante LPLMod V.1), el objetivo era extraer las funcionalidades y característicasprincipales de la interfaz gráfica, y entender el código base de desarrollo.


Tabla 7-1: Variables de Salida en la Interpretación del Modelo [3]

Nombre Variable Tipo Descripcióniterations Float Número de repeticiones que se realiza una simulación.lifeCycleTime Float Tiempo total de la simulación del proceso.numberEvents Float Número Total de eventos configurados en el proceso.numberEquip Float Número Total de equipos configurados en el proceso.costNoFlow Float Costo de Lucro Cesante que se utiliza para todo el proceso.confidenceInterval Float Intervalo de confianza.eventListConfig Array

[N,13]"Matriz con los parámetros de configuración de cada uno de loseventos configurados para todos los equipos de los diferentessistemas del proceso. Es una matriz de Nx13, donde N es elnúmero de eventos configurados para el sistema. La estructura dela matriz es:Columna(1): contiene el tipo de distribución de probabilidad dela ocurrencia del evento.Columna(2): contiene el parámetro 1 de la istribución.Columna(3): contiene el parámetro 2 de la distribución.Columna(4):contiene el parámetro 3 de la distribución.Columna(5): contiene el tipo de distribución de probabilidad dela duración del evento.Columna (6): contiene el parámetro 1 de la distribución.Columna(7): contiene el parámetro 2 de la distribución.Columna(8):contiene el parámetro 3 de la distribución.Columna(9): contiene Costo de ocurrencia del evento.Columna(10): contiene Tipo de evento. Es 1, si es Falla y 2, sies mantenimiento.Columna(11): contiene el ID de identificación del evento.Columna(12): contiene un array que contiene el ID de identifi-cación de las fallas asociadas, para el caso en que el evento sea unmantenimiento.Columna(13): contiene el ID de identificación del equipo al quepertenece el evento.

configGroupMant Array[N,5]

Matriz con los parámetros de configuración de cada uno de losgrupos de mantenimiento configurados para todos los sistemasdel proceso. Esta variable es usada principalmente en la Etapade Optimización. Es una matriz de 5xN, donde N es el númerode grupos configurados. La estructura de la matriz es:Columna(1): contiene el identificador del grupo.Columna (2): contiene un array de longitud m, donde m es elnúmero de mantenimientos asociados al grupo. Este array contie-ne los identificadores de los mantenimientos.Columna(3): contiene el valor inicial (periodo) del rango de bús-queda, definido para el grupo de mantenimiento.Columna(4): contiene el valor final (periodo) del rango de bús-queda para el grupo de mantenimiento.Columna(5): Es el delta cambio (resolución de búsqueda) que seutiliza para recorrer el rango de búsqueda, desde el valor inicial,hasta el valor final del mismo; definido para el grupo de manteni-miento.

31

LPLMod V.1 es una herramienta desarrollada en Java mediante el IDE EclipseModeling Tools. Que aplicaba los siguientes principios:

Jerarquía de proceso

Siguiendo los conceptos del lenguaje LPL, LPLMod V.1 presentaba tres vistascada una haciendo referencia a la jerarquía de proceso y con funcionalidades es-pecíficas, Ver Figura 7-4.

Entorno principal

El entorno principal del modelador consta de tres partes principales: la venta-na principal, el explorador de modelos y la barra de herramientas. La ventanaprincipal es donde se realizarán los procesos principales durante la etapa de mo-delamiento, la barra de herramientas cambia de acuerdo a las vistas. En la figura7-6 se observa el entorno principal de LPLMod V.1.

Figura 7-6: Entorno principal LPLMod V. 1


Vista de Proceso

Aquí se describe la planta industrial por medio de sistemas, ver Tabla 7-2 dondese describen los tipos de sistemas presentes en LPLMod V.1, se exporta el modelofinal a formato JSON y se agregan los parámetros generales de simulación (verFigura 7-7). Estas opciones se encuentran presentes en la barra de herramientasde esta vista. Todo modelo debe tener por lo menos un sistema de tipo Supply y unsistema de tipo Extraction. En la Figura 7-7, se ilustran las partes de un modelode ejemplo conformado por un sistema de tipo Supply, seguido de un sistema detipo Transport conectado a un sistema de tipo Extraction.

33

((a))

((b))

Figura 7-7: Vista de proceso, se incluye (a) un modelo realizado en esta vista, y(b) parámetros generales de la simulación


Tabla 7-2: Tipos de sistemas presentes en LPLMod V.1

Tipo de sistema Parámetros

Extraction

NombreCosto por lucro cesante

Cantidad máximaVelocidad máximaPrecio de venta

Supply NombreVelocidad máxima

Transport NombreFlujo Máximo

Storage Nombre.Capacidad máxima

Division NombreCantidad máxima

ConversionNombre.

Cantidad máximaValor de intercambio

Unification NombreCantidad máxima

Vista de Sistema

Se accede dando doble clic sobre un sistema presente en la vista de proceso. Dentrode la esta vista, se configuran los equipos y las relaciones entre ellos, que puedenser de tipo serie (Limiting y Dependent) o paralelo (Concurrent y Redundant).En la Figura 7-8, se observan tres equipos, pertenecientes a una rama serie. Dosde ellos se encuentran conectados a una relación en paralelo, también se observaun grupo de mantenimiento conformado por M1 y M3.

Vista de Equipo

Se accede dando doble clic sobre un equipo presente en la vista de sistema. En estavista se configuran los modos de falla y los mantenimientos (eventos) relaciona-dos a estos, cada uno de estos tiene asociada una ocurrencia y duración descritaspor funciones de distribución de probabilidad. En LPLMod V. 1, son: Constante,

35

Figura 7-8: Vista de sistema en LPLMod V.1.

Normal, LogNormal, Weibull, Exponencial, Triangular y Triangular Uniforme. Enla Figura 7-9, se observa la vista del equipo .E1"dos modos de falla cada uno conun mantenimiento asociado.

Figura 7-9: Vista de equipo en LPLMod V.1.

Modelo comunicativo JSON generado por LPLMod V. 1

Para entender el archivo JSON generado, se planteó un modelo de ejemplo, cuyosparámetros se encuentran descritos en las tablas 7-3, 7-4, 7-5 y 7-6. Luego, seidentificó la estructura general y se verificó por simple inspección que los paráme-tros descritos en el modelo gráfico se encontraran en el mensaje JSON.


Tabla 7-3: Parámetros generales del ejemplo en LPLMod V.1

Parámetro ValorNombre - Name Proceso_EjemploCiclo de vida - Life Cycle 3650Número de iteraciones - NSim 100Unidad de tiempo - Time Unit DaysMoneda - Currency DollarIntervalo de confianza - Confi.Interval 90

Tabla 7-4: Parámetros del modelo de ejemplo en la vista de proceso

Sistema Parámetro Valor

Sistema tipo Supply

Nombre - Name Supply_sisVelocidad máxima - MaxVel 1

Número de salidas 1

Sistema tipo Transport Nombre - Name Transport_sisFlujo máximo - Max Flow 1

Sistema tipo Extraction

Nombre - Name Extraction_sisCantidad máxima - MaxQuanty 1

C.Lucro Cesante 10000000Valor - Value 5

37

Tabla 7-5: Parámetros de los equipos, eventos, para el modelo de ejemplo enLPLMod V.1

Equipo Mantenimientos Fallas Relación

E1

Nombre: M1 Nombre: F1Costo: $ 10 Costo: $20

Dur: Constante: 2 Dur: Constante: 5Oc: Constante: 30 Oc: Weibull: η = 150, β = 2,2Falla asociada: F1

SerieNombre: M2 Nombre: F2Costo: $ 30 Costo: $40

Dur: Constante: 0.5 Dur: Constante: 5Oc: Constante: 15 Oc: Weibull: η = 200, β = 3,0Falla asociada: F2

E2

Nombre: M3 Nombre F3Costo: $ 50 Costo: $100

Dur: Constante: 7 Dur: Constante: 15 Paralelo con E2Oc: Constante 120 Oc: Weibull: η = 220, β = 3,5Falla asociada: F3

E3

Nombre: M4 Nombre F4Dur: Constante: 10 Dur: Constante: 7 Paralelo con E3

Costo: $ 70 Costo: $50Oc: Constante 150 Oc: Weibull: η = 350, β = 2,0Falla asociada: F4

Tabla 7-6: Parámetros del grupo de mantenimiento para el ejemplo

Grupo de Mantenimiento Parámetros

Grupo 1

Mantenimientos: [M1, M3]Max Per: 1500Per Change: 5.0Min Per: 5.0

Id: 1

Una vez terminado el modelo en las tres vistas para cada uno de los elementospresentes. Se exporta el modelo a formato JSON. El análisis de este archivo per-mite verificar que todas las funcionalidades presentes gráficamente se encuentrendescritas de forma adecuada, para esto se buscó que las relaciones y datos ingre-


sados en el modelo, se encuentren dentro del archivo JSON. A continuación sedescribe la estructura generada por LPLMod V.1.

1. Características generales del modelo:

{" lPLModeler : Process " : {"xmi : v e r s i on " : 2 ," systems " : [ . . . ] ,"xmlns : lPLModeler " : " http ://www. example . org / lPLModeler " ,

"name" : "Proceso_Ejemplo " ,"xmlns : x s i " : " http ://www.w3 . org /2001/XMLSchema−i n s t anc e " ," currency " : " Do l la r " ,"xmlns : xmi " : " http ://www. omg . org /XMI" ," l i f e C y c l e " : 3650 ," timeUnit " : "Days " ," c o n f i I n t e r v a l " : 90

2. Características del sistema de tipo Supply

{"nOuts " : 1 ," conec to r s " : [ {

" d i s c r e t e i n " : "//@systems .1/ @conectors . 0 " ," x s i : type " : " lPLModeler : DiscreteOut " ,"name" : "out1 " ," percent " : 1

} ] ,"maxVel " : 1 ," x s i : type " : " lPLModeler : Supply " ,"name" : " Supply_sis "

} ,

3. Características del sistema de tipo Transport

{" equipments " : [ . . . ] ," f i n a lR e l a t i o n " : "//@systems .1/ @re l a t i on s . 1 " ," conec to r s " : [ . . . ] ," x s i : type " : " lPLModeler : Transport " ,"name" : "Transport_sis " ," groups " : [ { . . . } ] ,"maxFlow" : 1 ," r e l a t i o n s " : [ . . . ]

} ,

39

4. Características del sistema de tipo Extraction

{"cLostFlow " : 1000000 ,"maxQuanty " : 5 ," conec to r s " : [ {

" x s i : type " : " lPLModeler : D i s c r e t e In " ,"name" : " In2 " ," d i s c r e t e ou t " : "//@systems .1/ @conectors . 1"

} ] ," x s i : type " : " lPLModeler : Extract ion " ,"name" : " Extrac t i on_s i s " ," va lue " : 5

}

5. Características del equipo E3{

" outRe lat ion " : "//@systems .1/ @re l a t i on s . 0 " ,"name" : "E3" ," events " : [

{" durat ion " : {

" x s i : type " : " lPLModeler : Constant " ," time " : 10

} ," co s t " : 70 ," performance " : 0 . 5 ," f a i l u r e s " : "//@systems .1/ @equipments . 2/@events . 1 " ," x s i : type " : " lPLModeler : Maintenance " ,"name" : "M4" ," occurrence " : {" time " : 150} ," type " : "Execution "

} ,{

" durat ion " : {" x s i : type " : " lPLModeler : Constant " ," time " : 7

} ," co s t " : 50 ," performance " : 0 . 5 ," x s i : type " : " lPLModeler : Fa i l u r e " ,"name" : "F4" ," occurrence " : {

" eta " : 350 ," x s i : type " : " lPLModeler : Weibull " ," beta " : 2


} ,"maintenances " :"//@systems .1/ @equipments . 2/ @events . 0"

}]

}

6. Grupo de mantenimiento 1

10" groups " : [ {

"minPer " : 5 ,"perChange " : 5 ,"maxPer " : 1500 ," id " : 1 ,"maintenances " : "//@systems .1/ @equipments . 0/ @events . 0//@systems .1/ @equipments . 1/ @events . 0"

} ]

7. Relaciones entre equipos

10" r e l a t i o n s " : [

{" outRe lat ion " : "//@systems .1/ @re l a t i on s . 1 " ," x s i : type " : " lPLModeler : Redundant " ," inEquipment " : "//@systems .1/ @equipments . 1//@systems .1/ @equipments . 2"

} ,{

" inRe l a t i on " : "//@systems .1/ @re l a t i on s . 0 " ," x s i : type " : " lPLModeler : L imit ing " ," inEquipment " : "//@systems .1/ @equipments . 0 " ," f ina lSys tem " : "//@systems .1"

}]

La estructura del JSON para los Equipos E1 y E2 es la misma que para E3.El proceso de creación del JSON es automático y no se tiene control sobre este.Además de esto aparece información que no es entregada por el usuario y que debeser ignorada por la capa de Interpretador del Modelo. Se observó que LPLModV.1 ya incorporaba en el mensaje JSON la relación en paralelo, denominada allícomo Redundant. En el desarrollo de LPLMod V.2 se buscó la forma de generarun archivo JSON sobre el cual se tuviera control por código, de tal forma que lacapa que se encarga de hacer la interpretación, reduzca su carga en funciones y semejorara la escalabilidad en la etapa de modelamiento.

41

Revisión del código base

Con el objetivo de retormar el proceso de desarrollo del modelador e incluir lascaracterísticas necesarias para la fase 4 del proyecto MainTUNER, se inició labúsqueda de la documentación técnica que describiera el trabajo realizado enLPLMod V.1. Se encontrarón archivos donde indicaba que se había utilizado lafuncionalidad Eclipse Modeling Forms (EMF) del IDE Eclipse Modeling Tools.EMF facilita la tarea de realizar interfaces de usuario que impliquen formularios,es un asistente que evita al desarrollador la tarea de codificar cada elementode la interfaz [19]. Se concluyó que el código base es resultado del uso de unasistente dentro del IDE, además de esto, no se encontró documentación quedescribiera la forma en la cual se había desarrollado LPLMod V.1., y debido a lapoca documentación no fue posible realizar desarrollos posteriores sobre LPLModV.1.

Resumen de funcionalidad y facilidad de uso

Analizado LPLMod V.1, se tienen las siguientes conclusiones respecto a su fun-cionalidad y facilidad de uso.

El modelador es completamente dependiente del IDE Eclipse Modeling Tools,esto hace que los requerimientos de hardware y software de LPLMod V.1sean los mismos que el IDE. Y como se encuentra basado en Java, es nece-sario instalar el JDK (Java Development Kit). Esto plantea una restricciónal usuario final.

El proceso de instalación de la herramienta dentro del IDE se hace de lamisma forma como si de un plugin de Eclipse se tratara

La creación de un nuevo modelo involucra un proceso tedioso que no esintuitivo.

Una vez creado el nuevo modelo, el usuario puede describir un proceso usan-do la cantidad de sistemas que desee.

En la vista de sistema el proceso para relacionar los equipos no es intuitivo,y dentro del modelo no se observa diferencia gráfica entre una relación tiposerie y una tipo paralelo. No existe la forma de identificar la entrada y lasalida del sistema, y con esto el flujo de trabajo.


Dentro de la vista de equipo, para asociar una distribución de probabilidada un evento se debe arrastrar desde la barra de herramientas y soltarlosobre el evento en cuestión, este proceso no es intuitivo, y se torna tediososi se debe agregar a un mismo equipo modos de falla y mantenimientos confunciones de distribución de probabilidad diferentes. Esto mismo se debehacer al agregar un puerto de entrada o salida a un sistema dentro de lavista de proceso.

El proceso para exportar el archivo JSON no es intuitivo puede inducir alusuario a errores, el mensaje JSON contiene todos los datos ingresados porel usuario e información adicional que no es necesaria en las capas siguientes,no hay forma de cambiar la estructura del archivo JSON.

7.0.3. Revisión de la interfaz gráfica en una herramientarelacionada con el área de trabajo de MainTUNER

Por recomendación del coordinador del proyecto y del director interno, antes deiniciar con el desarrollo del nuevo modelador, se debía realizar una revisión de lainterfaz gráfica de algún software usado en el mismo ámbito de MainTUNER, esdecir, simulación de eventos discretos y modelamiento de procesos. Se escogió elsoftware ARENA.

Arena Simulation

Arena es un software de simulación de eventos discretos que proporciona al usuariola posibilidad de modelar un sistema industrial y experimentar con este, de talforma que se puedan evaluar casos y resultados posibles de ganancia y producción.

Interfaz gráfica

La interfaz gráfica de Arena, ilustrada en la Figura 7-10 involucra las siguientespartes.

Barra de herramientas de proyecto: Contiene tres paneles: El panel deBasic Process, el panel Report, el panel Navigate, el panel Flow Process, el

43

panel Advanced Transfer y el panel Packaging. Cada panel contiene módulospara ser usados durante la construcción del modelo.

Vista de diagrama de flujo: En esta vista se construye el modelo gráficoteniando como referencia una dirección de flujo, es decir, todo sistema amodelar debe tener entrada y salida. Se usan las formas habituales en laconstrucción de diagramas de flujo.

Vista de hoja de datos: En este panel, se encuentran los datos del modelo.

Figura 7-10: Partes de la interfaz gráfica de Arena

En la Figura 7-11, se observa uno de ejemplos existentes dentro del software, eneste caso se trata de una linea de ensamblaje, en la parte superior se muestra laanimación del proceso y en la parte inferior, el diagrama que lo modela. Cadaelemento del diagrama posee unas características dadas, como se muestra en laFigura 7-12, además de esto la dirección del flujo se puede identificar fácilmente.


Figura 7-11: Ejemplo de un modelo de un proceso de ensamblaje realizado enArena

Figura 7-12: Parámetros de un componente del modelo de ejemplo en Arena

Los parámetros generales de simulación se encuentran fuera del espacio de tra-bajo, se ilustran en la Figura 7-13, además del tiempo de simulación, se puedeseleccionar de qué elemento se desea obtener estadísticas.

45

Figura 7-13: Parámetros generales de simulación

Se concluyó que todo modelador de procesos debe presentar un flujo de trabajoclaro, además de esto los parámetros de simulación no deben estar mezclados conelementos de modelo, y que las conexiones entre elementos deben realizarse dentrodel área de trabajo y no deben hacer parte de las barras de herramientas dondese encuentran los elementos para sintetizar el modelo. La revisión de esta interfazbrindó las bases necesarias para definir requerimientos respecto al LPLMod V. 2,lo que se realizará en la sección siguiente.

7.0.4. Selección de la tecnología base para el desarrollo

Este es un proceso clave en el momento de iniciar el desarrollo, requiere tener encuenta: los requerimientos de funcionalidad, el contexto del proyecto y las tecno-logías más usadas para el desarrollo de software en el mercado. A continuación sedetalla el trabajo realizado para la selección de la tecnología a implementar.


Levantamiento de requerimientos básicos para el nuevo modelador

El análisis realizado al LPLMod V. 1 y al modelador del software de simulaciónde eventos discretos consultado, dió como resultado el siguiente listado de funcio-nalidades requeridas.

1. Existe un panel de herramientas desde el cual se pueden arrastrar bloqueshacia una ventana de trabajo y cada una de los bloques tiene figura únicaque lo identifica y representa una abstracción a una parte de un procesoindustrial, ya sea a nivel de proceso, sistema o equipo.

2. Los bloques pueden ser relacionados para formar un grafo que representeun proceso y existe una forma para darle características a cada uno de losbloques.

3. Debe existir la opción de comentar alguno de los bloques dentro del modelo,esto con el fin de brindar más herramientas para realizar el análisis de losresultados en MainTUNER.

4. Las características que se pueden dar a cada bloque son diferentes y depen-den de la vista en la que se encuentre. En la vista de proceso se podráningresar las características generales relacionadas con costos y parámetrosde simulación, así como ingresar bloques que representen sistemas.

5. En la vista de sistema, se podrá crear un modelo que represente de formaadecuada los equipos y sus relaciones, ya sean serie o paralelo, Se debe poderidentificar la entrada y la salida del sistema de tal forma que el modelo tengaun sentido de flujo, y sea más sencillo de interpretar. Además de esto, cadaequipo debe tener una capacidad asociada.

6. En la vista de equipo, se ingresarán los modos de falla y mantenimiento,sus costos y sus duraciones y ocurrencias descritos por las funciones dedistribución de probabilidad usadas en LPLMod V.1. Los mantenimientossiempre deben estar asociadas a una falla, mientras que estas últimas podránestar aisladas.

7. Una vez terminado el proceso de modelado, la aplicación tiene una funciona-lidad que permite guardar todo el grafo, de tal forma que se pueda disponerde este posteriormente.Una vez guardado, se podrá exportar a un archivoen formato JSON que indique de forma detallada los bloques en cada vista,sus parámetros, y las relaciones existentes entre ellos.

47

Una de las conclusiones del análisis al desarrollo anterior era que se debía evitaren lo posible una dependencia con un sistema operativo o con un software deter-minado, pues esto introduce una restricción para la empresa en el momento devender la aplicación. Dentro del proceso de selección de la tecnología, se tuvieronen cuenta tres tipos de aplicaciones.

1. Aplicación nativa: Es un software de aplicación que se desarrollada paraun sistema operativo específicamente, tienen la ventaja de poder aprovecharal máximo el hardware y software específico del dispositivo.

2. Aplicación web: Desarrolladas mediante, html, JavaScript y CSS. Tienenla ventaja de que no necesitan ser descargadas e instaladas y pueden seraccedidas a través de un navegador.

3. Aplicación híbrida: Una aplicación híbrida es una combinación de lasdos anteriores, Se desarrollan con lenguajes propios de las aplicaciones web,por lo que permite su uso en diferentes plataformas, pero también dan laposibilidad de acceder a gran parte de las características del hardware deldispositivo. Tomando las características de la aplicación nativa, esta tambiénse puede distribuir por medio de una app-store.

En KNAR SAS, los desarrollos de aplicaciones se realizan por medio del frameworkIonic Figura 7-14), que permite la creación de aplicaciones de tipo híbrido, ydebido a que se basa en el paradigma MVC (del inglés Model-View Controller), esdecir, por un lado define componentes para la representación de la información, ypor otro lado para la interacción del usuario. Se espera que en futuras versionesde MainTUNER, los procesos de cómputo se realicen en la nube, y una interfazgráfica desarrollada bajo esta plataforma, sienta las bases para los desarrollosfuturos.

Figura 7-14: Logo Ionic


7.0.5. Formulario web como primera aproximación al mo-delador

El desarrollo de este formulario web tiene como antecedente la herramienta NPT(Non Productive Time) descrita brevemente en [2], y tiene como objetivo describirun proceso industrial, por medio de los parámetros usados en LPL, teniendo encuenta sistemas, equipos y eventos para al final obtener un mensaje de tipo JSONde la misma forma que se hacía en NPT.

Inicialmente, se tomaron los conceptos y parámetros dados en LPLMod V.1, laaplicación fue desarrollada usando html, JQuery, (librería de JavaScript que sim-plifica algunas funciones de esta) y CSS. Por ser una primera aproximación, nose prestó tanta atención a la perte visual de la página sino que se ahondó en laestructura del JQuery y del html para cumplir el objetivo de esta tarea

Archivo html

En esta primera aproximación, se utilizó la siguiente estructura para ingresar losdatos de cada item, a continuación se presentan los datos generales del proceso:

<div id = "addProcess"><br>Name : <input type= " text " id="nameP"><br>L i f e c y c l e : <input type " text " id =" l c"><br>Time uni t : <s e l e c t name="TimeUnit" r equ i r ed id= "tU"><opt ion value ="Not de f ined">Choose an option−−</option><opt ion value ="Years">Years</option><opt ion value ="Months">Months</option><opt ion value ="Days">Days</option><opt ion value ="Hours">Hours</option></s e l e c t ><br>Currency : <s e l e c t name="Currency" r equ i r ed id="currency"><opt ion value ="Uknown">Choose an option−−</option><opt ion value ="USD $">United Sta t e s Do l l a r (USD)</option><opt ion value ="EUR ">European Euro (EUR)</option><opt ion value ="GBP ">Pound (GBP)</option><opt ion value ="COP $">Colombian Peso (COP)</option></s e l e c t ><br>Conf idence I n t e r v a l : <input type= " text " id="c I n t e r v a l"><br>Number o f i t e r a t i o n s : <input type= " text " id="n I t e r"><br><button id="b_createP">Set Process </button>

</div>

49

Archivo en JQuery

En esta capa se plantearon las funciones que permitían la obtención de datos y sealmacenaban para poder desplegarlos al final en un archivo JSON. Con los datosingresados se creaba un objeto con tantos atributos como parámetros tuviera elequipo, el sistema o el proceso. Los datos se obtenían del html de las siguienteforma, siguiendo el ejemplo para los datos generales del proceso:

f unc t i on p_data ( ){var proce s sCon f i g = {

"name" : $("#nameP" ) . va l ( ) ," l i f e C y c l e " : $("# l c " ) . va l ( ) ," timeUnit " : $("#tU " ) . va l ( ) ,"Currency " : $("#currency " ) . va l ( ) ," c on f I n t e r v a l " : $("# c In t e r v a l " ) . va l ( ) ," i t e r a t i o n s " : $("#nI t e r " ) . va l ( )

} ;r e turn proce s sCon f i g ;

} ;

Resultados

La disposición de los elementos dentro del formulario se presenta en las Figuras7-15, 7-16 y 7-17.

Figura 7-15: Parámetros generales del modelo en el formulario


Figura 7-16: Parámetros de sistema en el formulario

Figura 7-17: Parámetros de grupo de mantenimiento en el formulario

A medida que se avanzaba con el desarrollo del formulario, se iba evaluando enconsola el JSON que se obtenía, si bien se tenía más control sobre la obtencióndel mensaje JSON, la complejidad de modelar un proceso con equipos dispuestosen serie y paralelo, que además tenían multiples entradas y salidas era grande. Elmensaje en formato JSON que se obtenía para los datos en la vista de proceso sedetalla más adelante.[

51

Process :{"name" : "ProcessExample " ," l i f e C y c l e " : "3650" ," timeUnit " : "Years " ,"Currency " : "USD $" ," c on f I n t e r v a l " : "90" ," i t e r a t i o n s " : "100"

}]

7.0.6. Desarrollo del modelador en una aplicación híbridamediante Ionic

Para el desarrollo de LPLMod v. 2, dentro de Ionic, inicialmente fué necesariodelimitar los conceptos y funcionalidades que las otras dos etapas de MainTU-NER requerían para el desarrollo de los algoritmos y que debían ser incluidos aLPLMod V. 2. Posteriormente se realizó una búsqueda y selección de una libreríade JavaScript que permitiera la creación de diagramas. Luego se realizó un ejem-plo de la vista de sistema, en una aplicación web con la librería seleccionada, paraconocer a fondo las funciones y el manejo del código. Para después incorporar estedesarrollo dentro de una aplicación tipo "Hola Mundo"de Ionic. El paso a seguirera incorporar las demás vistas y funcionalidades al desarrollo anterior y obtenerel archivo JSON global, dando así por finalizado el proceso, a continuación sedetallan cada uno de estos pasos, sus resultados, inconvenientes y conclusiones.

Búsqueda y selección de una libreria de JavaScript para diagramación

Para cumplir con el requerimiento gráfico de esta tarea, se realizó una búsqueda delibrerías basadas en JavaScript que estuvieran orientadas hacia la diagramación,luego se definieron los siguientes criterios para evaluarlas:

1. La librería posee una biblioteca de formas predeterminadas.

2. Existe una función que permite crear diagramas por medio de Drag anddrop

3. Entre las formas agregadas al diagrama se pueden crear relaciones que seanidentificables.


4. La librería tiene una función que permite importar y exportar el esquemacon todas sus características hacia o desde un archivo en formato JSON.

5. La librería evaluada es fácilmente integrable en una aplicación desarrolla-da con Ionic, y tiene una versión de prueba que permite hacer uso de susfuncionalidades mientras se adquiere la licencia.

Para realizar la evaluación de las librerías, se remitió a la documentación presenta-da por los desarrolladores de cada una de estas, y a los ejemplos presentados en suspáginas web. A continuación, se detallan las librerías evaluadas, y una descripciónacerca del cumplimiento o no de los criterios expresados anteriormente.

Las librerías consideradas para realizar la evaluación fueron:

Vis.js:

1. Contiene fundamentalmente las siguientes formas: elipse, tríangulo,rombo, cilindro, círculo y cuadrado, las demás son variaciones de estasen tamaño o dirección.

2. No posee esta funcionalidad, no indica dentro de la documentación sipuede realizarse

3. Se pueden agregar labels a una relación para identificarla.4. Si posee esta función.5. Esta libreria se encuentra en npm y es posible agregarla desde allí a

cualquier framework

Rappid:

1. Permite la creación de diferentes tipos de diagramas conocidos, comolos diagramas UML, redes de Petri, diagramas BPMN, entre otros, ypara cada uno de ellos posee una paleta de diferentes formas geométri-cas, además de las básicas.

2. Si posee esta funcionalidad, dentro de los demos se encuentra un ejem-plo donde se ilustra su uso.

3. Las relaciones pueden ser identificadas mediante labels.4. Dentro de la documentación existe una sección dedicada a la serializa-

ción de diagramas hacia el formato JSON.5. En npm se encuentra la versión gratuita Joint.js, que no posee todas

las funcionalidades ni variedad de paletas de Rappid

53

MxGraph

1. La aplicación para realizar diagramas draw.io se encuentra basada enesta librería y allí se puede observar la amplia gama de figuras y rela-ciones que se pueden utilizar.

2. Posee una función que permite arrastrar y clonar partes del diagrama,pero en la documentación no lo especifica.

3. Las relaciones se identifican por medio de labels.

4. No aplica el formato JSON, utiliza XML.

5. Esta librería es de código abierto, hace parte de un proyecto colabora-tivo y se encuentra en npm.

Mermaid.js:

1. Posee las figuras siguientes figuras geómetricas necesarias para realizarun diagrama de flujo o un diagrama de Gantt.

2. Los diagramas creados con esta librería son estáticos.

3. Las funcionalidades de esta librería están limitadas a los tipos de dia-gramas mencionados anteriormente.

4. Como el diagrama que se crea es estático, una vez creado este no esposible editar las características de este.

5. No se encuentra en npm, se puede instalar por medio de yarn.

Go.js:

1. Posee una amplia paleta de figuras, y por medio de estas se puedenrealizar diagramas de flujo, diagramas de estado, e inclusive circuitoslógicos.

2. Posee un elemento denominado Palette que permite realizar la funciónde drag and drop.

3. Las relaciones pueden ser identificadas por medio de labels y puedenser editadas las veces que se desee

4. La función diagram.toJSON(), permite realizar esta tarea.

5. Go.js puede ser utilizada con todas sus funcionalidades en modo deprueba, los diagramas aperecerán con un mensaje que indique que seuso ese modo. Go.js se encuentra en npm.


A partir de la evaluación realizada, se eligió la librería Go.js desarrollada porNorthwoods Software. Se realizó una consulta a esta empresa para verificar lasfuncionalidades observadas en los demos de la página web y para aclarar dudassurgidas en la investigación acerca de esta. Una ventaja que brindaba esta libreríasobre las demás es que ofrece el código fuente de todos sus ejemplos, en su páginaweb y como repositorios en GitHub, además de esto, tiene tutoriales con ejemplosinteractivos, lo que facilita el proceso de aprendizaje y uso de la librería.

Libreria Go.js

En Go.js un diagrama se encuentra conformado por nodos, (Nodes), que son unidosa tráves de Links, haciendo uso de puertos (Ports), entonces, para poder relacionardos nodos de un diagrama, estos deben poseer puertos que permitan las conexionesdesde y hacia estos. En la Figura 7-18 se muestran las partes de un diagramacreado mediante Go.js, el puerto se resalta en rosado.

Dentro de Go.js, existen librerías adicionales que permiten modificar las propieda-des de los nodos dentro de un diagrama, para el desarrollo de esta vista se empleóla librería Inspector. Se encuentra basada en HTML, y permite el despliegue dedatos de un objecto de JavaScript seleccionado o de un objecto Model.modelData,es decir de un nodo, o relación dentro del diagrama [20].

Figura 7-18: Partes de un diagrama creado mediante GO.js [4]

55

Desarrollo de la vista de sistema en una aplicación web usando la tec-nología seleccionada

Mediante la libreria Go.js seleccionada en el ítem anterior, se desarrolló una apli-cación web que contenía la vista de sistema de un proceso industrial, en la Figura7-19.

Figura 7-19: Entorno principal vista de sistema LPLMod V. 2

Figura 7-20: Aplicación de la librería inspector para dar características a unequipo.

En la parte superior de la Figura 7-19, se encuentran los parámetros generalesde simulación, debajo de este se encuentra la barra de herramientas desde dondese podrán arrastrar y soltar los equipos sobre el área de trabajo ubicada debajode esta. En esta área de trabajo se observan los puertos de entrada/salida delsistema.


Se decidió comenzar por la vista de equipo debido a que en esta se encuentranlas relaciones serie-paralelo que son parte importante del desarrollo en esta fasede MainTUNER. Para ingresar datos a cada equipo se debe hacer clic derechosobre un equipo presente en el diagrama, se desplegará una ventana creada porla libreria Inspector, como se observa en la Figura 7-20. En la figura 7-21, semuestra un modelo conformado por siete equipos, donde existe una rama serie,única. De esta figura también se observa una dirección de flujo, un nodo de entraday salida. Se incluyó otro frame de tipo Inspector que incluye los datos básicos deuna simulación.

Figura 7-21: Modelo de siete equipos en serie-paralelo

Cuando se considere que todos los datos han sido ingresados, por dedio del botón.Export to JSON", se obtendrá en la consola del navegador el mensaje de traspasode datos dónde se pueden identificar las siguientes partes:

1. Datos principales de simulación."Process View : " ,

{"Name" : "Proceso 1" ,"CostLostFlow " : 1000000 ,"NIter " : "100" ,"Currency " : "Do l l a r " ,"TimeUnit " : "Day" ," L i f eCyc l e " : "3650"

} ,

2. Datos relacionados a los equipos presentes en el sistema."Equipment : " ,

[[

" type : Equipment " ,

57

{"Name" : "EQ1" ," Id " : −1,"Capacity " : 0 . 1

} ,{

"Name" : "EQ2" ," Id " : −4,"Capacity " : 1

} ,{

"Name" : "EQ3" ," Id " : −5,"Capacity " : 0 . 5

} ,{


} ,{


} ,{


} ,{

"Name" : "EQ7" ," Id " : −9,"Capacity " : 1

}]

] ,

3. Datos relacionados a las relaciones entre los equipos en el sistema

[{

"__gohashid " : 3759 ," from " : "S" ," to " : −1," fromPort " : " InputNode " ," toPort " : " I "

} ,{


"__gohashid " : 4381 ," from " : −1," to " : −5," fromPort " : "O" ," toPort " : " I "

} ,{

"__gohashid " : 4457 ," from " : −4," to " : −1," fromPort " : " I " ," toPort " : "O"

} ,{


} ,{


} ,{


} ,{


} ,{

"__gohashid " : 6310 ," from " : −8," to " : −7," fromPort " : " I " ," toPort " : " I "

} ,{

59

"__gohashid " : 6386 ," from " : −8," to " : −7," fromPort " : "O" ," toPort " : "O"

} ,{


} ,{

"__gohashid " : 6886 ," from " : −9," to " : "E" ," fromPort " : "O" ," toPort " : "OutNode"

}]

Este primer diagrama incluía un tipo de equipo con una entrada y una salida, luegose añadió otro equipo con dos entradas, una salida, para crear un sistema de tipomixto, este modelo se observa en la Figura 7-22. El JSON generado no cambiarespecto a los datos principales de simulación ni respecto a los datos relacionadosa los equipos presentes en el sistema. Las relaciones entre los equipos se muestrana continuación

Figura 7-22: Sistema mixto LPLMod V.2

[{

"__gohashid " : 3759 ," from " : "S" ,


" to " : −1," fromPort " : " InputNode " ," toPort " : " I "

} ,{


} ,{


} ,{


} ,{


} ,{

"__gohashid " : 8188 ," from " : −5," to " : −6," fromPort " : "O" ," toPort " : "O"

} ,{


} ,{

"__gohashid " : 9231 ," from " : −7,

61

" to " : −2," fromPort " : "O" ," toPort " : " I1 "

} ,{

"__gohashid " : 9301 ," from " : −2," to " : −8," fromPort " : " I2 " ," toPort " : "O"

} ,{

"__gohashid " : 10315 ," from " : −2," to " : "E" ," fromPort " : "O" ," toPort " : "OutNode"

}]

De los mensajes JSON se pueden identificar los siguientes parámetros en cada unade sus partes:

1. Parámetros principales de simulación. Cuenta con los items:Name,CostLost-Flow, NIter, Currency, TimeUnit y LifeCycle, cada uno haciendo re-ferencia a los items ya expuestos en la tabla 7-3.

2. Datos relacionados con los equipos. Este cuenta con tres parámetros:Name,Id y Capacity. En LPLMod V.1 no se incluía capacidad para los equipos,dentro de la interfaz gráfica y estos datos se ingresaban desde el interpreta-dor.

3. Información respecto a las relaciones entre equipos. Se identifican los items:gohashid, from, to, fromPort, toPort. A partir de estos, e identificando,que cada from y cada to tienen un código único, se podrán reconstruir lasrelaciones existentes entre los equipos presentes en el modelo.

Cabe resaltar que los ID presentados son negativos porque de es la forma queutiliza la librería para identificar los componentes dentro del modelo.


Incorporación del desarrollo anterior en una app de Ionic

El siguiente paso era incorporar el diseño anterior en un app de Ionic, y a partir deahi, y con los componentes que ofrece este framework, mejorar el primer desarrolloy acoplar las tres diferentes vistas. Durante el desarrollo de esta tarea, el ciclocontractual que KNAR SAS tenía su cliente respecto a MainTUNER cerró, y fuenecesario parar las actividades relacionadas con el desarrollo del nuevo modeladorpara iniciar la descripción formal de las funcionalidades de la fase 4 y realizarlas pruebas necesarias para el cliente. Debido a esto esta tarea no se completó.La tarea se realizó para mejorar la usabilidad de la herramienta, el desarrollo deuna interfaz que acoplara el JSON generado y las demás capas, de tal forma queel usuario no viera código sino únicamente los resultados tanto de la etapa demodelamiento como de las etapas siguientes.

7.0.7. Modificación del interpretador para acoplarlo a losrequerimientos de la fase 4

A la par que se iba desarrollando el nuevo modelador, se usaba LPLMod V.1 paraobtener los JSON y realizar las pruebas durante el desarrollo. La etapa SED seconcibió un algoritmo para procesar eventos de equipos que estuvieran dispuestosen serie o en paralelo, y para esto requerían que la etapa de interpretador lesentregara las siguientes variables, y se modificaron algunas de las descritas en lasección 7.0.1. La modificación se basó en el diseño estructurado en [3].

1. EventListConfig: A esta matriz se le añade el identificador de evento,relación de equipo (serie o paralelo) y pérdida de capacidad asociadaal equipo.

2. MatSupEq: Contiene la información de un súper-equipo, de esta forma sellamó a una red de equipos conectados en paralelo.

63

7.0.8. Interfaz gráfica MainTUNER

Para acoplar el algoritmo de sintonización de mantenimientos de MainTUNER yel diseño en el modelador se hace uso del lenguaje de comunicación JSON como seobservó anteriormente, por lo tanto para realizar la unión entre estas dos etapas serequiere realizar una interfaz gráfica, ya que el software del modelador no permiterealizar la sintonización de Mantenimientos en la misma interfaz.

Como solución se requiere una interfaz gráfica que cumpla con los siguientes re-querimientos:

Sencilla navegación e intuitiva.

Permita al usuario cargar el archivo JSON desde sus documentos, este ar-chivo es generado por el modelador.

La interfaz deberá mostrar barras de progreso de acuerdo al porcentaje dela sintonización de mantenimiento por cada grupo.

La interfaz deberá mostrar adicionalmente como mensaje el progreso decarga de la aplicación (librerías) y sintonización.

Para cumplir los requerimientos se intentó realizar la interfaz gráfica en Julia, perono fue satisfactoria, ya que en la versión 0.6 de Julia, el manejo con la interfazgráfica de Python no era intuitivo y generaba problemas con las librerías dellenguaje de programación Python. Por estas razones se eligió para el desarrollode la interfaz gráfica el uso de Python.

Para cumplir con los requerimientos de la visualización del avance de sintonizacióny carga de librerías, se utilizó como método de comunicación un archivo de textocon extensión .log, con lo cual en el código del algoritmo de sintonización enMainTUNER se utilizó la función mostrada a continuación:


@everywhere func t i on toTxt2 ( path ,mat)t ry

f=open ( path )s=r e ad s t r i n g ( f ) ;c l o s e ( f )open ( path , "w") do f

wr i t e ( f , " $mat")end

catchopen ( path , "w") do f

wr i t e ( f , " $mat")end

endend

En está función se genera la escritura del archivo ”path” con el mensaje ”mat”.Utilizando esta función en los ciclos donde se avanzaba dentro de la simulaciónde Monte Carlo, se realizaba un cálculo para determinar el porcentaje de avancey se envía este mensaje a un archivo de texto con la función toTxt2().

Para la lectura en Python de los archivos de texto de la comunicación, se utilizanlas funciones nativas de open() y read(). Para el manejo de la concurrencia yavance de la barra de progreso se utilizó un hilo con un subproceso encargado dela lectura del archivo y el avance de la barra de progreso. Finalmente en Pythonse realizó la disposición gráfica de los elementos y sus funciones. El resultadomostrado en la figura 7-23 corresponde a la apertura de la aplicación y el iniciode la carga de librerías.

65

Figura 7-23: Interfaz Gráfica de MainTUNER para importación de librerías

Al realizarse la carga de librerías, la interfaz de usuario habilita las opciones parala carga del archivo JSON como se muestra en la figura 7-24. En esta pantallael usuario no puede utilizar el botón de ”Execute MainTUNER” hasta que hayarealizado la carga de un archivo JSON.

La pantalla de la figura 7-24 muestra la disposición gráfica de todos los elementospermitiendo cumplir los requerimientos solicitados de navegación sencilla e intui-tividad, ya que el manejo de la interfaz solo requiere de tres clic: dos clic para caracarga del archivo JSON y uno para la ejecución de MainTUNER. La pantalla decarga de elección del archivo JSON se observa en al figura 7-25, nótese que solose puede elegir archivos finalizados en la extensión JSON.


Figura 7-24: Interfaz Gráfica MainTUNER

Figura 7-25: Interfaz Gráfica MainTUNER en selección del archivo JSON

67

Finalmente al oprimir el botón de ”Execute MainTUNER” como lo indica la figura7-26, se genera el inicio de la sintonización de mantenimiento del sistema indicadoen el archivo JSON. El funcionamiento de las barras de progreso se observa en lafigura 7-27.

En la consola incorporada en la interfaz gráfica se mostrarán los siguientes men-sajes conforme la sintonización avance:

Importing model chiquillo.JSON

Current System Analysis

Tunning Started

Displaying Results

End ond Simulation

Figura 7-26: Interfaz Gráfica MainTUNER lista para ejecución


Figura 7-27: Interfaz Gráfica MainTUNER en ejecución

Finalmente, se realiza el despliegue de resultados generados por el algoritmo deMainTUNER que corresponden a las gráficas de costos por periodo de manteni-miento para cada grupo con el periodo de mantenimiento propuesto para cadagrupo y otras gráficas relevantes para el analista.

69

7.0.9. Algoritmo de cálculo de disponibilidad del sistema

Para el algoritmo de cálculo de disponibilidad del sistema o el cálculo de la capa-cidad porcentual de un equipo en el sistema, se requería que los datos de todos loseventos ocurridos en una simulación fueran transformados a una linea de tiempocon la capacidad del sistema en el tiempo. Está linea de tiempo es utilizada pa-ra calcular el porcentaje de no disponibilidad en el sistema, valor necesario paracalcular el costo de lucro cesante de la simulación de eventos discretos.

La idea principal para el diseño fue la escalabilidad y el cumplimiento del requeri-miento del cálculo de lucro cesante, para ello la primera idea fue tratar un esquemade árbol, en el cual primero se procesaran los eventos de los equipos conectados enparalelo y posteriormente se procesaran los eventos en serie utilizando una únicafunción que reciba los datos de los eventos de cada equipo.

Por lo tanto, se plantea como lo propone la figura 7-28 el uso de un administra-dor o coordinador (conteo de capacidad por iteración) que conoce la topología delsistema con la matriz de eventos procesados, matriz que contiene la informaciónde identificación del equipo con el tiempo de inicio y fin del evento y su pérdidade capacidad. Con la información mencionada el administrador usa la función decálculo de capacidades para realizar los cálculos de capacidad de equipos conecta-dos en paralelo en primera parte y posteriormente el cálculo de capacidad de losequipos conectados en serie.

Figura 7-28: Esquema del algoritmo de capacidades


Basado en el esquema de la figura 7-28 hay dos algoritmos a realizar: el algoritmode la función de cálculo de capacidades de ciertos equipos y el algoritmo de conteode capacidad por iteración, el cuál utilizará la función de cálculo de capacidades.En la tabla 7-7 se muestran los objetos o variables utilizadas en el algoritmo deMainTUNER para el cumplir con el cálculo de capacidades.

Tabla 7-7: Objetos utilizados para el cálculo de capacidades

Objeto DescripciónMatriz de eventos Matriz en donde se registrarán los eventos procesados en la línea

procesados de tiempo. Se registra el identificador de evento, el tiempoinicial y final del evento y la capacidad del equipo.

Matriz de eventos Matriz similar a MEP sin el identificador del evento, para facilitarel procesamiento de los datos.

Matriz de pérdidas Matriz que llevará el control de los eventos que ocurrieron en cadade capacidades equipo. Contiene el indicador de equipo y su matriz de evento.Identificador de Indicador que asocia los equipos conectados en serie en un gruposúper equipo llamado súper equipo. Si el índice es cero son equipos en serie.

Matriz de Control Matriz que llevará el control del solapamiento temporal de eventos

de Súper Equipos en los súper equipos existentes en el sistema. Se registrael indicador de súper equipo y los equipos asociados a este.

Matriz de Matriz que reunirá las matrices de eventos de entrada de la funciónProcesamiento de cálculo de capacidades.

Matriz de Matriz que reunirá los eventos de equipos conectados en un súperResultados equipo o de todos los súper equipos.

Vector tiempo Vector que almacena todos los tiempos diferentes presentados enla matriz de procesamiento, tanto iniciales como finales.

Contador_capacidad Escalar que llevará el conteo a través de la matriz de resultados.

Rango de análisis Vector en el cual se almacenan todos los tiempos iniciales y finalesdiferentes de la matriz de procesamiento

vector de pérdida Vector en que se almacenaran determinados valores de la columnade capacidades pérdida de capacidad de la matriz de procesamiento.

Definiendo los objetos o variables que interactúan en la ejecución del algoritmose muestra en la figura 7-29 el diagrama de flujo del algoritmo para la función decálculo de capacidades. En la figura 7-30 se muestra el algoritmo para la funciónde conteo de capacidad por iteración y por último, la función que adecua los datospara el tratamiento económico para el sintonizador se observa en la figura 7-31.

71

Figura 7-29: Diagrama de flujo de la función de cálculo de capacidades


Figura 7-30: Diagrama de flujo del retorno de la función conteo de capacidadpor iteración

73

Figura 7-31: Diagrama de flujo del retorno de la función de cálculo de capacidades

Para el algoritmo de cálculo de capacidades se basa en la utilización de las matricesde eventos para cada equipo como valores de entrada y el parámetro que indicasi es una operación de equipos en serie(máximo) o paralelo(suma). El algoritmocrea el vector tiempo con el fin de generar todos los intervalos donde ocurrieroncambios de estado en el sistema, por lo tanto es importante que sea diferentes,posteriormente analiza todos los intervalos de tiempo para determinar la pérdidade capacidad en el rango de análisis y lo almacena en la matriz de resultados,realizando este procedimiento en cada intervalo se obtiene la pérdida de capacidaden toda la línea de tiempo a analizar.

Para el algoritmo de conteo de capacidad por iteración se basa en como se mencio-nó anteriormente un diagrama de árbol, por lo tanto, primero realiza el procesa-miento de todos los súper equipos o equipos conectados en paralelo para obtenerun sistema final de equipos en serie y reescribe todas las matrices de equipos quecomponen ese súper equipo como una única matriz de eventos, con las matrices


de eventos de todos los súper equipos que simulan un sistema conectado en serie,vuelve a utilizar la función de cálculo de capacidad para obtener las capacidadesdel sistema total.

Finalmente en el algoritmo de retorno de resultados obtiene el lucro cesante entoda la línea de tiempo y obtiene la curva de capacidades con un histograma detodas las simulaciones de Monte Carlo.

Validación del algoritmo de cálculo de capacidades

Para la validación del algoritmo de cálculo de capacidades se realizaron variaspruebas similares a la mostrada a continuación con resultados satisfactorios. Parailustrar el método de pruebas se utiliza una matriz de eventos procesados, en esteejemplo se observa en la tabla 7-8, con esta matriz de entrada fue el parámetrode entrada y se realizó una prueba de escritorio en el algoritmo para verificarmanualmente cada valor.

Tabla 7-8: Matriz de eventos procesaos de prueba

ID Tiempo Inicial Tiempo Final Péddida de Capacidad1 1 1 1 7 402 1 2 1 8 201 2 1 2 6 602 2 2 7 10 300 1 2 8 11 1002 3 1 8 11 502 3 1 11 12 500 1 1 13 18 1002 3 1 19 23 502 2 2 20 23 301 2 2 21 24 600 1 2 22 25 1002 3 1 27 31 502 1 2 27 34 202 2 2 29 32 302 2 1 29 31 302 2 1 31 34 30

75

La matriz de pérdidas de capacidades generada al iniciar el algoritmo de conteo decapacidad por iteración se observa en la tabla 7-9, está misma matriz al terminarde ejecutar la prueba se observa en la tabla 7-10 comprobando los cambios queel algoritmo realizo a está matriz como se indica en los diagramas de flujo. Ladiferencia notables es que la matriz de pérdidas de capacidades al terminar laprueba contiene los intervalos de tiempo aislados, es decir, no hay solapamiento,está matriz está lista para ser procesada por última vez para genera la matriz deresultados final.

Tabla 7-9: Matriz de pérdidas de capacidades al iniciar la prueba

Súper Equipo Tiempo inicial Tiempo Final Pérdida de Capacidad

08 11 10013 18 10022 25 100

11 7 402 6 6021 24 60

2

1 8 207 10 308 11 5011 12 5019 23 5020 23 3027 31 5027 34 2029 32 3029 31 3031 34 30


Tabla 7-10: Matriz de pérdidas de capacidades al terminar la prueba

Súper Equipo Tiempo inicial Tiempo Final Capacidad

08 11 10013 18 10022 25 100

1

0 1 01 2 402 6 1006 7 407 21 021 24 6024 30 0

2

0 1 01 7 207 8 508 10 8010 11 5011 12 5012 19 019 20 5020 23 8023 27 027 29 7029 31 10031 32 8032 34 50

Por último el resultado generado por el algoritmo utilizado y que corresponde alrealizar la prueba manualmente es el mostrado en la tabla 7-11

77

Tabla 7-11: Matriz de resultado final

Tiempo inicial Tiempo Final Pérdida de Capacidad0 1 01 2 402 6 1006 7 407 8 508 10 10010 11 10011 12 5012 13 013 18 10018 19 019 20 5020 21 8021 22 8022 23 10023 24 10024 25 10025 27 027 29 7029 30 10030 31 10031 32 8032 34 50

Como se observa en la matriz de resultado el vector está en pérdidas de capaci-dad, al realizar la conversión en la función de retorno de resultados se genera losresultados adecuados para el calculo de costo de lucro cesante y demás variablesde intereses para el análisis posterior del algoritmo de MainTUNER.

En esta prueba y con el algoritmo de sintonización se comprobó que el algoritmofunciona correctamente, por razones comerciales, los resultados en sintonizaciónno son mostrados en este documento. El ejemplo realizado en este documento esun ejemplo académico y la matriz de eventos procesados no corresponde con unsistema real.


7.0.10. Computo en paralelo del algoritmo

El computo en paralelo para el algoritmo de MainTUNER fue tratado por lospasantes anteriores [2]. En este documento se exploran diversos métodos de para-lelización para el algoritmo de eventos discretos.

Con los conocimientos adquiridos en la contextualización del lenguaje de progra-mación Julia v0.6 se procedió a profundizar en el campo del computo en paraleloen este lenguaje. Para ello se realizó la investigación en la documentación y sedesarrolló la siguiente guía de inicio en paralelización en Julia v0-6.

Guía de inicio en paralelización en Julia v0.6

Esta guía está basada en la documentación técnica de Julia v0.6 [21].

Julia se basa en dos primitivas:

Referencia remota: es un objeto que puede usarse desde cualquier procesopara referirse a un objeto almacenado en un proceso particular.

Llamadas remotas: es una solicitud de un proceso para llamar a ciertafunción sobre ciertos argumentos en otro procesos.

Las referencias remotas poseen dos variantes RemoteChannel y Future, esteúltimo es el resultado de una llamada remota, el cual ocurre al solicitar a unprocesador o trabajador (Worker) que realice una tarea, mientras el programaque solicitó el llamado continua en sus tareas, puede esperar el resultado con unwait() y adquirir el resultado con fetch().

El RemoteChannel es regrabable, es decir, varios procesos pueden coordinar susprocesos respecto referenciando un canal remoto. Esto se verá con mayor detallemás adelante.

A continuación se explicará el concepto de Workers, el cual es el alma de laparalelización por CPU de Julia.

El concepto de Workers está relacionado a la cantidad de CPU’s del equipo y elWorkers uno siempre será utilizado como coordinador de los demás, a menos de

79

que solo haya uno en ese caso será un Worker, por lo tanto si se tiene 4 CPU’sen un equipo se necesita agregar 4 Workers para aprovechar la máxima capacidaddel equipo dando como resultado un número de 5 Workers.

La agregación de Workers se realiza con la instrucción addprocs(NúmeroWorkers),dónde Número Workers es la cantidad de procesadores que se quiere agregar, cabeaclarar que si agregamos más procesadores de los que dispone el equipo no utilizarálos adicionales. Si la instrucción está sin parametros addprocs(), automáticamenteagrega tantos procesadores como CPU’s disponga el equipo.

La función rmprocs(#procs) elimina el Workers #procs. Cada Workers tiene suid y cada vez que se borra uno, este id no se utilizará.

Ejemplo: Las siguientes lineas de código

j u l i a > addprocs (4 )j u l i a > rmprocs (4 )j u l i a >addprocs (1 )j u l i a >procs ( )

Arroja como resultado:

Int64 [ 5 ]12356

En este ejemplo se observa que el id 4 no se ha utilizado y hay 5 Workers como sesolicitó con las líneas addprocs(), también se incluye una nueva función procs(),la cual retorna los ids de los Workers que están inicializados actualmente.

La función nprocs() retornará el número de Workers utilizados,para el ejemploanterior retornaría 5.

Retomando las llamadas remotas, las cuales son solicitudes de procesos como semencionó anteriormente, con la función remotecall() se pueden ordenar las solici-tudes de procesos con el control de que procesador la realice. Los argumentos deesta función son primero la función a realizar, segundo el procesador que realizarála tarea y por último los argumentos de la función a realizar.


Ejemplo de la utilización para una matriz rand de 2x2 y para un rand individualen el Worker N:

var1=remote ca l l ( rand , 3 , 2 , 2 )var2=remote ca l l ( rand , 3 )

Los resultados de estas líneas son Future, por lo tanto si queremos los resultadosde las tareas utilizaremos fetch(). Ejemplo:

f e t ch ( var1 )2x2 Array{Float64 , 2 } :0 .289043 0.5712920.270633 0.300696

Este procedimiento se puede ahorrar utilizando la función remotecall_fetch().

Esta forma de realizar la paralelización no es muy conveniente, por lo tanto existela macro @spawn la cual facilita el proceso.

@spawn: Realiza la solicitud de un proceso a un Worker libre cualquiera, es decir,es exactamente igual a remotecall() sin el parámetro de Worker.

Ejemplo: var1=@spawn rand(2,2)

Esta macro devuelve un Future, por lo tanto, es necesario hacer el fetch de lavariable en la cual se guardó el Future: fetch(var1).

@everywhere: Fuerza a todos los Workers o procesos a ejecutar la función. Estamacro sirve para enseñarle los métodos a los Workers para su posterior utilizaciónen cada uno.

@parallel: Esta macro realiza procesos en paralelo en un for, puede tener unreductor para la operaciones, sin el reductor no se encuentra mucho sentido aluso ya que no realiza una paralelización estricta de los procesos. como se ve en elsiguiente ejemplo:

a = ze ro s (100000)@pa ra l l e l f o r i = 1:100000

a [ i ] = iend

81

Los resultados son que a no tuvo modificaciones, porque cada proceso tiene unacopia de a, pero no a directamente. Al utilizar un SharedArray el problema essolucionado:

a = SharedArray{Float64 }(10)@pa ra l l e l f o r i = 1 :10

a [ i ] = iend

Con este arreglo cada proceso tiene directamente a la matriz. Utilizando reductoresel @parallel adquiere mejor uso, como se ve en el siguiente ejemplo para calculael número de caras de una moneda en mil millones de lanzamientos:

nheads = @para l l e l (+) f o r i = 1:1000000000Int ( rand ( Bool ) ) ;

end

Antes de entrar a canales es importante conocer las dos macros @sync y @async

@async: Esta función es similar a @spawn solo que las tareas se corren en elproceso local de cada Workers; es utilizado para crear tareas de alimentación deprocesos, ya que se le entrega el proceso, espera hasta acabarlo y le entrega otrohasta que no haya que entregar.

@sync: Esta función es utilizada para hacer la espera de que las tareas en todoslos Workers estén finalizadas para continuar, a diferencia del @async que lashacen de forma asincrónica.

Canales

Los canales son muy útiles para realizar traspaso de datos de tareas, especialmentelas que involucran operaciones de entrada y salida, como el problema realizado eneste proyecto o simulaciones de monte carlo.

Un canal es como un tubo al cual entran datos por un extremo y se van almace-nando o se sacan por el otro extremo, es decir, es un sistema FIFO(Primero enentrar, primero en salir). Las funciones para esto son las siguientes:

Múltiples escritores en diferentes tareas pueden escribir el mismo canal me-diante put!().


Múltiples lectores en diferentes tareas pueden leer datos del mismo canalmediante take!().

Es decir, entrar datos utiliza put!() y sacarlos take!().

Para mostrar un ejemplo que ofrece la documentación de julia es necesario incluiruna nueva macro:

@schedule: Agrega una tarea a la cola de programa de la máquina local, esdecir, con ella podemos agregar n instancias de una función para que se ejecutenconcurrentemente.

Los canales tienen ciertas características:

Para la creación se utiliza: var=channel{Tipo}{Cantidad_elementos}.

Donde tipo es el tipo de datos(Float32,Int,Bool,Any. . . ) y Cantidad_elementoses la capacidad del canal.

Si un canal está vacío y algún lector utiliza take!(), el canal estará bloqueadahasta que haya datos en el canal.

Si un canal está lleno, alcanzó su capacidad, y algún escritor utiliza put!(), elcanal estará bloqueado hasta que haya espacios disponibles.

La función isready() sirve para verificar la presencia de objetos en el canal,mientras que wait() espera por un objeto esté disponible.

La función close() cerrará el canal impidiendo su escritura por un put!() o eltraslado de datos del canal en un for con mayor iteraciones y produzca bloqueopor un take!().

Con lo anterior, se utiliza el siguiente ejemplo de julia en el cual utiliza 4 tareaspara un único canal llamado jobs(trabajos), lo cuales se guardan el id del trabajo.Cada tarea en este ejemplo lee el id de trabajo, espera una cantidad aleatoria detiempo y escribe en el canal de resulados (results) una tupla con el id y el tiempode espera. Finalmente se muestra los resultados

j u l i a > addprocs ( 4 ) ; # add worker p r o c e s s e s

j u l i a > const jobs = RemoteChannel(()−>Channel{ Int } ( 3 2 ) ) ;

83

j u l i a > const r e s u l t s = RemoteChannel(()−>Channel{Tuple } ( 3 2 ) ) ;

j u l i a > @everywhere func t i on do_work( jobs , r e s u l t s )# de f i n e work func t i on everywhere

whi l e t ruejob_id = take ! ( j obs )exec_time = rand ( )s l e e p ( exec_time )# s imu la t e s e l apsed time doing ac tua l workput ! ( r e s u l t s , ( job_id , exec_time , myid ( ) ) )

endend

j u l i a > func t i on make_jobs (n)f o r i in 1 : n

put ! ( jobs , i )end

end ;

j u l i a > n = 12 ;

j u l i a > @schedule make_jobs (n ) ;# feed the jobs channel with "n" jobs

j u l i a > f o r p in workers ( )# s t a r t ta sk s on the workers to p roce s s r eque s t s in p a r a l l e l

@async remote_do (do_work , p , jobs , r e s u l t s )end

j u l i a > @elapsed whi l e n > 0 # pr in t out r e s u l t sjob_id , exec_time , where = take ! ( r e s u l t s )p r i n t l n (" $job_id f i n i s h e d in $ ( round ( exec_time , 2 ) )seconds on worker $where ")n = n − 1

end

La macro @elapsed funciona para medir el tiempo.

Los resultados generados fueron:


1 f i n i s h e d in 0 .18 seconds on worker 42 f i n i s h e d in 0 .26 seconds on worker 56 f i n i s h e d in 0 .12 seconds on worker 47 f i n i s h e d in 0 .18 seconds on worker 45 f i n i s h e d in 0 .35 seconds on worker 54 f i n i s h e d in 0 .68 seconds on worker 23 f i n i s h e d in 0 .73 seconds on worker 311 f i n i s h e d in 0 .01 seconds on worker 312 f i n i s h e d in 0 .02 seconds on worker 39 f i n i s h e d in 0 .26 seconds on worker 58 f i n i s h e d in 0 .57 seconds on worker 410 f i n i s h e d in 0 .58 seconds on worker 20.055971741

Con estos resultados se da por terminada la guía para ingresar en la paraleliza-ción de Julia v0.6, esta guía fue desarrollado como partes de los entregables pararealizar la paralelización del algoritmo de MainTUNER.

Comparación de los métodos de paralelización

Para el problema de paralelización propuesto se necesita computar en paralelodiversas simulaciones de eventos discretos para generar una simulación de Monte-Carlo. Por ello no es posible utilizar la solución de @parallel ya que la simulaciónde eventos discretos posee multiples bucles en su código y esta macro es útil parabucle pequeños.

La macro @spawn tampoco es útil debido a que está es utilizada para paralelizarfunciones pero al utilizar el fetch() se obtiene mayores tiempos a los de los canalesremotos [2].

Por lo tanto, la solución escogida para las pruebas de paralelización fueron loscanales remotos.

Adicionalmente se realizó una prueba similar a la realizada en la pasantía anteriory se logró la paralelización de las iteraciones en la simulación de eventos discretos.La reducción de tiempo lograda fue del 45.36%, la memoria ram consumida no semidió por falta de métodos en Julia.

85

Está prueba fue la base para la realización de la paralelización del algoritmodesarrollado en la fase 4 y será explicado en la siguiente sección.

Paralelización del algoritmo utilizado en MainTUNER fase 4

Para la paralelización del algoritmo utilizado en la fase 4 del proyecto MainTU-NER se basó en las pruebas iniciales, estas pruebas se basaron en introducir códigodentro del algoritmo, con el fin de cambiar la comunicación para lograr que todoslos datos que se procesan en un bucle, se computen de forma paralela, con lo cualse ganaría una mejora en el tiempo de procesamiento.

Como se mencionó anteriormente el método escogido fueron los canales remotos,para ello al diagrama de flujo del algoritmo de MainTUNER se agregaron dos blo-ques para la carga de los procesos relacionados a la carga de los canales remotoscomo se muestra en la figura 7-32. En esta figura se observan dos bloques resal-tados en los cuales se realiza la carga de los Workers o procesadores y en el otrolos canales que en los cuales se colocará y tomará la información de los procesosen paralelo realizados por los Workers en el bloque ’Ejecución del algoritmo deprocesamiento’, el cual recibirá modificaciones para la realización del proceso enparalelo del bucle principal.

El algoritmo de MainTUNER para su desarrollo utiliza la carga de librerías; inter-pretación del archivo JSON, estándar para intercambiar información;ejecución delalgoritmo con está información y el despliegue de resultados.Se observa en la lafigura 7-32 dos cargas de librería, este procedimiento se realizara con el fin de quelos procesadores no utilicen memoria RAM en un proceso que nunca utilizarán, yaque la tarea de interpretación es realizada únicamente por el procesador principalantes de iniciar la ejecución del algoritmo.


Figura 7-32: Diagrama de flujo MainTUNER para la prueba de paralelización

El diagrama de flujo para la ejecución del algoritmo se observa en la figura 7-33, en este diagrama se observa una semejanza al diagrama de flujo de todo elprograma en el cual se carga variables, se procesan y se envían resultados. Lasfunciones de procesamiento no se alteran para la paralelización, por lo tanto, alincluir paralelización se tiene que modificar este diagrama como se muestra en lafigura 7-34 en el cual se añaden bloques para la creación y asignación de tareascon su posterior adquisición de datos dentro de una rutina iterativa con la mismacantidad de iteraciones que el proceso sin paralelización.

Los Workers realizan las tareas de manera asíncrona utilizando el canal remoto enel cual se crearon las tareas, para ello en el bloque creación de tareas se realizantantas tareas como iteraciones tiene el proceso y se colocan(put!()) en un canal

87

remoto de trabajos para que los Workers tomen (take!()) estas tareas y las pro-cesen con la ayuda de la función remote_do(), la cual asigna a los procesadorestareas cuando estos finalicen la tarea actual. De esta manera los procesadores tra-bajan de manera paralela de manera asíncrona mientras el procesador principalse encarga de tomar los resultados que los procesadores o Workers colocan en elcanal remoto de resultados.

Figura 7-33: Diagrama de flujo del algoritmo de MainTUNER sin paralelización


Figura 7-34: Diagrama de flujo del algoritmo de MainTUNER con paralelización

Realizando este procedimiento se obtuvieron los resultados mostrados en la tabla7-12 con un total de 10 pruebas utilizando el comando @time de Julia. Las pruebasfueron realizadas en un equipo con procesador Intel Core i5-2537M @1.40 GHzcon 4 núcleos y 4 GB de memoria RAM.

Tabla 7-12: Resultados de la paralelización del código de MainTUNER FASE 3

Metodología Tiempo utilizado en el procesamientoSin paralelización 9.7189 ± 0.209 sCon paralelización 4.4097 ± 0.043 s

En los resultados de la tabla 7-12 se observa una reducción de tiempo del 54.62%en el procedimiento paralelizado sobre el procedimiento sin paralelizar, con lo cual

89

en estas primeras prueba se comprobó que el método de paralelización funcionaba,aunque no se realizó la medida del consumo de memoria RAM.

Basado en el diseño anterior se procedió a realizar la paralelización del proceso deMonte Carlo para MainTUNER [2] [3].Este proceso es utilizado para la sintoni-zación del periodo de mantenimiento del sistema a analizar, para ello se realizanmúltiples simulaciones de MonteCarlo con el objetivo de realizar la búsqueda deun mejor periodo de mantenimiento para los equipos industriales a simular.

El proceso de MonteCarlo utiliza varias simulaciones de eventos discretos del siste-ma a analizar para realizar el análisis estadístico de estas, las simulaciones ocurríansecuencialmente en el diseño sin paralelización, con el algoritmo implementado eneste trabajo, las simulaciones de eventos discretos ocurren paralelamente, mientrashay un procesador central que se encarga de reunir los datos y realizar los cálculosestadísticos de los datos con el objetivo de reducir los tiempos de cómputo.

El procedimiento realizado fue el mismo realizado para la paralelización de losciclos utilizados en la simulación de eventos discretos de la fases 1,2 y 3 como seobserva en las figuras 7-33 y 7-34.

Las pruebas fueron realizadas en un equipo con procesador Intel Core [email protected] GHz con 4 núcleos, 4 GB de memoria RAM en el sistema operativo Lubuntu18.04, para ello se utilizó la función @time y el monitor de recursos de Lubuntucomo se muestra en la figura 7-36, en está figura se evidencia el uso de todos losprocesadores al utilizar el procedimiento paralelizado con el incremento en el usode la memoria RAM. El sistema utilizado para esta prueba se muestra en la figura7-35.

In // Equipo1 // Equipo2 //

// Equipo3

Out

Figura 7-35: Sistema para la prueba de paralelización


Figura 7-36: Monitor de recursos

Los resultados mostrados en la tabla 7-13 comparan el proceso paralelizado yel proceso sin paralelizar para la carga de librerías, ya que al ser un procesoparalelizado requiere mayor tiempo de carga de librerías debido a que deben sercargadas en cada procesador. En este ejemplo se observa que la carga de libreriasen el algoritmo sin paralelizar se demora un 60.7% menos de tiempo en cargar laslibrerias que el algoritmo paralelizado y posee un consumo porcentual promediode memoria RAM de 17.9% menor al consumo del algoritmo paralelizado.

91

El algoritmo sin paralelizar en la carga de librerías posee menor consumo dememoria RAM y menor tiempo debido a que un único procesador ejecuta laslibrerías y realiza la carga de ellas, en el proceso paralelizado se requiere que cadaprocesado ejecute cada librería, adicionalmente se tiene que realizar la asignaciónde las cargas de trabajo de todos los procesadores. Los resultados mostrados en

Tabla 7-13: Resultados de la paralelización del código de MainTUNER FASE 4:Carga de librerías

Metodología Tiempo Uso de memoria RAMSin paralelización 25.9442 ± 0.1060 s 1,2± 0.4583%Con paralelización 66.0253 ± 0.3721 s 19.1 ± 1.4440%

la tabla 7-14 comparan el proceso paralelizado y el proceso sin paralelizar parala ejecución del algoritmo de MonteCarlo. En los resultados se puede observaruna mejora en el tiempo de procesamiento del 23,41% del algoritmo paralelizadoal algoritmo sin paralelizar a costo de un 4,75% de memoria RAM consumidaadicionalmente en ejecución. La figura 7-36 muestra el instante en el que losprocesadores comienzan a realizar el trabajo en paralelo con lo que se demuestrael uso de la paralelización, además el tiempo se redujo en la ejecución del algoritmode sintonización como lo indica la tabla 7-14, demostrado que la aplicación de laparalelización fue éxitosa.

Tabla 7-14: Resultados de la paralelización del código de MainTUNER FASE 4:Ejecución algoritmo

Metodología Tiempo Uso de memoria RAMSin paralelización 233,8514 ± 0.1060 s 1,5± 0,2517%Con paralelización 179,1007 ± 0,9068 s 6,2500 ± 1,5711%

Por último los resultados de las tablas 7-13 y 7-14 se suman para mostrar lostiempos totales y consumo porcentual de memoria RAM en la tabla 7-15. En estatabla se observa la reducción total del 5.61% de tiempo en el algoritmo paraleli-zado respecto al algoritmo sin paralelizar con un costo porcentual del 22.45% dememoria RAM. Los resultados son muy similares en el tiempo utilizado, aunqueen el consumo de memoria RAM se observa una diferencia notable para analizarla viabilidad de la paralelización.

La aplicación de técnicas de paralelización en el proyecto es satisfactoria debidoa que la carga de librerías se realiza en la pantalla de carga de la aplicación,por lo que el usuario tendrá un retraso del 60.7% de tiempo en esta pantalla decarga, pero una reducción del tiempo de procesamiento en la sintonización de sus


Tabla 7-15: Resultados de la paralelización del código de MainTUNER FASE 4

Metodología Tiempo Uso de memoria RAMSin paralelización 259,7956 ± 0.1060 s 2,7± 0,7024%Con paralelización 245,2063 ± 0,8074 s 25,15 ± 1,4827%

periodos de mantenimiento del 23,41%. Con lo cual en un sistema más complejoestá reducción de tiempo dará la posibilidad al analista de obtener resultados másrápido a un mayor costo de uso de memoria RAM, el cual puede ser solucionadoal expandir la memoria.

Capítulo 8

Análisis de cumplimiento de objetivos

A continuación se describen brevemente las tareas realizadas para desarrollar cadauno de los objetivos planteados al inicio de la pasantía, indicando las razones desu cumplimiento total o parcial.

8.0.1. Objetivo 1: Diseñar e implementar un algoritmo parael cálculo de disponibilidad de sistemas genéricos conconexiones serie y paralelo en el lenguaje Julia.

Resultados Asociados:

Se desarrollo un algoritmo basado en un coordinador y una función que desarrollael cálculo de capacidades en bloques pequeños, simulando una estructura de árbol,en donde se resuelven los problemas más pequeños y se va ascendiendo hasta llegara describir el sistema completo, en este caso, solo había dos capas por lo que elorganizador primero resuelve los equipos conectados en paralelo para luego resolverlos equipos conectados en serie.

Se implementó el algoritmo diseñado con resultados satisfactorios tanto en pruebasrealizadas con matrices de eventos procesados, como en pruebas no documentadasdel algoritmo de MainTUNER, el algoritmo es escalable para sistemas mixtos, porlo que no un algoritmo exclusivo a equipos con conexiones serie y paralelo con locual se cumplió con el requerimiento de escalabilidad y también tiene una funcióndentro del código de Monte Carlo en la cual se realiza el cálculo de costo de lucrocesante.

94 8 Análisis de cumplimiento de objetivos

Descripción de cumplimiento de objetivos:

El objetivo se cumplió en su totalidad, ya que se cumplió con el diseño de un algo-ritmo escalable y con cálculo de lucro cesante con una implementación satisfactoriaante las pruebas realizadas. Este código es aplicable para las futuras aplicacionesdel proyecto en las cuales se deben manejar sistemas mixtos con múltiples flujos.

8.0.2. Objetivo 2: Analizar los métodos de paralelizaciónen el lenguaje Julia, con el fin de implementar elalgoritmo para análisis RAM en forma paralela.

Resultados Asociados:

Se analizaron los métodos de paralelización propuestas en la documentación deJulia y en [2], para ello se realizó una guía de paralelización con los métodosdisponibles para paralelización en la versión 0.6 de Julia, en esta guía se indica lasfunciones y macros utilizan en computo en paralelo. Con el análisis realizado seoptó por utilizar como método de paralelización para el proceso de Monte Carlode MainTUNER el uso de los canales remotos.

Se realizó una implementación base documentada en este documento en el cuál seexplica el uso de los canales remotos dentro de bucles para el cómputo en paralelo,los resultados arrojados indican un rendimiento superior en tiempos del procesoparalelo sobre el proceso sin paralelizar.

Finalmente, se realizó la implementación del computo en paralelo del algoritmoMainTUNER en la simulación de Monte Carlo, con lo cual se obtuvo una reduccióndel tiempo de procesamiento del algoritmo.

Descripción de cumplimiento de objetivos:

El objetivo se cumplió en su totalidad, ya que se realizó el análisis de los métodosde paralelización, en el cual se escogió el método de canales remotos y se imple-mentó en el algoritmo para análisis RAM (MainTUNER) con el cual se obtuvouna reducción de tiempos de procesamiento a costo de mayor memoria RAM.

95

8.0.3. Objetivo 3: Diseñar e implementar, con la tecnologíade interfaz de usuario seleccionada, una interfaz grá-fica en la que se pueda modelar un sistema industrialmediante conexiones serie, paralelo y mixtas.

Resultados Asociados: Se realizó una inmersión al desarrollo anterior paraextraer de él los conceptos y funcionalidades necesarias para el nuevo desarrollo.Posteriormente se realizó el análisis de la interfaz gráfica de Arena, y se seleccionóel tipo de aplicación que se quería que fuera MainTUNER cuando se incorporaranlas tres etapas de forma orgánica, se seleccionó el framework Ionic para realizarel nuevo desarrollo.

Basado en esto, se propuso un formulario basado en html, JQuery y CSS, repli-cando el concepto del NPT. Poseriormente se inició con la búsqueda de libreríasde diagramación en JavaScript, se realizó la definición de criterios para elegir unade ellas.

Con la librería escogida se realizó una aplicación web que contenía la vista desistema del nuevo modelador, que incluía equipos dispuestos en relaciones serie,paralelo y mixtas. Finalmente se realizó una interfaz gráfica que era la etapa detransición entre la capa de modelamiento y las demás capas de MainTUNER, elobjetivo de esta era evitar que el usuario final interactuara con el código de lasetapas SED y paralelización.

Descripción de cumplimiento de objetivos: Este objetivo fue cumplido par-cialmente pues por factores propios de la dinámica de una organización, y de loscontratos que rigen los proyectos de desarrollo no se culminó con la incorporacióndel desarrollo en Ionic.

8.0.4. Objetivo 4: Implementar el estándar de traspaso dedatos entre la etapa de modelamiento y las demásetapas de MainTUNER.

Resultados Asociados: Para cada uno de los desarrollos, tanto para el formula-rio, como para el desarrollo en la aplicación web, se obtenían mensajes en formatoJSON como estándar de traspaso de datos, además de esto, se realizó la modifica-ción de la capa de interpretación del modelo para entregar las variables globales

96 8 Análisis de cumplimiento de objetivos

que requería la etapa SED.

Descripción de cumplimiento de objetivos: Este objetivo se cumplió total-mente pues se realizó la traducción desde la etapa JSON hasta la etapa SED, ypara cada desarrollo se obtuvo un JSON fácilmente interpretable y accesible.

Capítulo 9

Conclusiones

Se concluyó que la metodología de árbol es una buena aproximación para realizarel cálculo de capacidades escalable, incluso la función de cálculo de capacidadesse puede expandir para analizar otros parámetros como rendimiento. También esuna aproximación válida para afrontar la futura fase de MainTUNER, en la cualse deben manejar sistemas mixtos con múltiples flujos.

Los métodos de paralelización aportan mejores en tiempo a costo de memoriaRAM, para el ejemplo especifico en este documento, se obtuvo una reducción del23,41% de tiempo entre el método paralelizado y sin paralelizar en la ejecución dela sintonización y como se observo en la sección Ïnterfaz gráfica MainTUNER.eltiempo de carga de librerías es un parámetro con menor impacto. Lo ideal parautilizar el algoritmo de MainTUNER es contar con un equipo con un procesadormultinúcleo con alta frecuencia y una capacidad de memoria mayor a 8 GB deRAM.

En cuanto al desarrollo de la interfaz gráfica, se concluye que este tipo de etapastambién requieren planificación y diseño para evitar invertir tiempo en escriturade código innecesario. La documentación técnica debe estar clara para facilitar lasdinámicas de trabajo en equipo y escalabilidad de los desarrollos.

Durante el desarrollo de la pasantía es importante resaltar la planificación de losproyectos de ingeniería, con un desarrollo de tiempo mayoritario para el análisisde requerimientos, si este análisis se realiza correctamente y bien estructura lasdemás fases del proyecto serán facilitadas, por lo tanto, para la siguiente fasedel proyecto de MainTUNER se debe en realizar un buen enfoque en todos losrequerimientos del software.

Bibliografía

[1] ITEM-Software.Inc: “Reliability Block Diagram (RBD)“. http://www.reliabilityeducation.com/, 2007. Online; Accedido en 13 de Octubre del2018.

[2] Silva, C. y J. Zorrilla: Diseño e Implementación de Procesamientos Compu-tacionales para el Desarrollo de un Software de Simulación de Eventos Dis-cretos Orientado al Análisis RAM de Sistemas Industriales, Enero 2019.

[3] Rojas, D. y J. Sosa: Diseño e Implementación de un Algoritmo que permitarealizar el Análisis RAM de Procesos Industriales Simples basado en Simu-lación de Eventos Discretos, Enero 2019.

[4] Software, Northwoods: “GOJS Demos”. https://gojs.net/latest/samples/flowchart.html, Enero 2017. Online;Accedido en 5 de Febrerodel 2019.

[5] Renovetec: “Mantenimiento industrial”. http://www.renovetec.com/590-mantenimiento-industrial/110-mantenimiento-industrial/305-tipos-de-mantenimiento, 2017. Online; Accedido en 13 de Octubre del2018.

[6] KNAR: “KNAR-Nuestra empresa”. http://www.knarsas.net/knarsasnew_aboutus_es/knarsasnew_whoweare_es, 2017. Online; Accedido en 12 deOctubre del 2018.

[7] GL, DNV: “Chemical process software and petrochemical plant processsolutions - Taro”. https://www.dnvgl.com/services/chemical-process-software-and-petrochemical-plant-process-solutions-taro-1176,2013. Online; Accedido en 13 Octubre del 2018.

[8] Baca, G: “Introducción a la ingeniería industrial”. Patria, México, segun-da edición, 2014.

BIBLIOGRAFÍA 99

[9] DEKRA-Insight: “Análisis RAM“. https://dekra-process-safety.es/images/documents/Analisis_RAM_Datasheet_A4_ES_2016, 2016. Online;Accedido en 13 de Octubre del 2018.

[10] Calixto, E: “Gas and oil reliability engineering - Modeling and Analysis”. GulfProfessional Publishing, 225 Wyman Street, Waltham, MA 02451, USA, 2013.

[11] Albrecht, Mike: “Introduction to Discrete Event Simulation”. http://www.albrechts.com/mike/DES/Introduction%20to%20DES.pdf, Enero 2010.Online;Accedido en 13 Octubre del 2018.

[12] Matloff, Norman: ”Introduction to discrete-event simulation and the simpylanguage”. Dept of Computer Science. University of California, 2:3, Enero2008.

[13] Kelton, WD, RP Sadowski y DT Sturrock: “Simulation with Arena”. 2th.McGraw-Hill, 2002.

[14] Kroese, D. P.; Brereton, T.; Taimre T.; Botev Z. I.: ”Why the Monte Carlomethod is so important today’. Wiley Interdiscip Rev Comput Stat, página386:392, Junio 2014.

[15] Almasi, G. S. y A. Gottlieb: “Highly parallel computing’. Redwood City,California, 1989.

[16] Gan, Vincent W. ; Lin, Chun Wei ; Fournier Viger Philippe ; Chao HanChieh ; Yu Philip.: ”A Survey of Parallel Sequential Pattern Mining’. LATEXCLASS FILES, 6:3:4, Enero 2018.

[17] Chacon, S y B Straub: “Pro Git”. Apress, second edición.

[18] ECMA: “Standard ECMA-404 The JSON data interchange syntax”.http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf, Enero 2017. Online;Accedido en 2 de Febrero del 2019.

[19] Foundation, Eclipse: “Getting Started With EMF Forms”. https://eclipsesource.com/blogs/tutorials/getting-started-with-EMF-Forms/, Enero 2017. Online;Accedido en 5 de Febrero del 2019.

[20] Software, Northwoods: “Data Inspector”. https://gojs.net/latest/extensions/dataInspector.html, Enero 2017. Online;Accedido en 5 deFebrero del 2019.

[21] JuliaLang: “Julia Documentation”. https://docs.julialang.org/en/v0.6/, Agosto 2018. Online;Accedido en 28 de Enero del 2019.

Documents

DiseñoeImplementacióndelModeladorparaunSimulador ...repository.udistrital.edu.co/bitstream/11349/14812/1...DiseñoeImplementacióndelModeladorparaunSimulador deEventosDiscretosBasadoenAnálisisRAMconel