Diseño e implementación de un algoritmo basado en simulación de eventos discretos para procesamiento de eventos y evaluación de sistemas serie paralelo (MainTuner fase 4)
Texto completo
(2)
(3) Diseño e Implementación de un Algoritmo basado en Simulación de Eventos Discretos para Procesamiento de Eventos y Evaluación de Sistemas Serie-Paralelo (MainTUNER Fase 4). Juan Pablo Vélez Rodríguez Código: 20131005993 Carlos Andrés Pardo Barbosa Código: 20122005063. Trabajo de grado para optar al título de: Ingenieros Electrónicos. Directora: Diana Marcela Ovalle Martínez. PhD. Codirector: Jorge Edison Granada Jiménez Knowledge and Integration Architects Modalidad de Grado: Pasantía. Universidad Distrital Francisco José de Caldas Facultad de Ingeniería Proyecto Curricular de Ingeniería Electrónica Bogotá D.C. 2018.
(4)
(5) Resumen El presente documento describe el proyecto de pasantía llevado a cabo, en el cual se desarrolla la fase 4 de una herramienta de simulación aplicada a procesos industriales y basada en simulación de eventos discretos, la cual ya está realizada hasta su fase 3. Esta herramienta permite obtener un análisis de confiabilidad de costos y producción de dichos procesos mediante el paradigma de programación de eventos. Lo anterior se realiza con el fin de dar solución a diferentes obstáculos que presenta la empresa Knar S.A.S. al desempeñarse en el ámbito de la consultoría en ingeniería, mediante el uso de herramientas de software comerciales que presentan grandes limitaciones de flexibilidad y velocidad de ejecución. La tarea desempeñada en el desarrollo de esta fase, se enmarca en la simulación de eventos discretos de procesos industriales de complejidad media, y su diseño parte de la investigación de teorías relacionadas y de la contextualización del trabajo realizado previamente. Por medio de un plan de trabajo establecido, se busca la construcción gradual de la herramienta de simulación que cumpla con los objetivos establecidos para la fase 4 del proyecto. Estos objetivos incluyen obtener resultados de desempeño de procesos industriales que permitan realizar diagnósticos y sugerir cambios en su tratamiento para mejorar su desempeño. El desarrollo de esta pasantía, además de permitir establecer una conexión entre el ámbito laboral y el académico, permite aplicar habilidades adquiridas a lo largo del proceso de formación de pregrado a contextos industriales, considerando el impacto que tienen estos desarrollos en su aplicación en problemas reales, mediante la comercialización de proyectos en los que la ingeniería juega un papel importante..
(6)
(7) Contenido. Resumen. v. Lista de Figuras. ix. Lista de Tablas. xiii. Introducción. xv. 1. Antecedentes. 1. 2. Planteamiento del problema. 5. 3. Objetivos 3.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . .. 7 7 7. 4. Alcances y Limitaciones 4.1. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 9 9 9. 5. Marco Teórico 5.1. Simulación . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1. Etapas para realizar un Estudio de Simulación 5.1.2. Simulación de Eventos Discretos . . . . . . . . 5.2. Procesos Estocásticos y Métodos de Monte Carlo . .. . . . .. 11 11 12 13 17. 6. Plan de Trabajo 6.1. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1. Etapa 1: Contextualización del proyecto . . . . . . . . . . 6.1.2. Etapa 2: Desarrollo del Algoritmo . . . . . . . . . . . . . .. 21 21 22 22. . . . .. . . . .. . . . .. . . . .. . . . .. . . . ..
(8) Contenido. viii. 6.1.3. Etapa 3: Implementación del Algoritmo . . . . . . . . . . . 6.1.4. Etapa 4: Pruebas y Validación . . . . . . . . . . . . . . . . 7. Desarrollo y Resultados 7.1. Etapa 1: Contextualización del proyecto . . . . . . . . . . . 7.2. Etapa 2: Desarrollo del Algoritmo . . . . . . . . . . . . . . . 7.3. Etapa 3: Implementación del Algoritmo . . . . . . . . . . . . 7.4. Etapa 4: Pruebas y Validación . . . . . . . . . . . . . . . . . 7.4.1. Simulación de un sistema de un equipo . . . . . . . . 7.4.2. Simulación de un sistema serie de dos equipos: . . . . 7.4.3. Simulación de un sistema paralelo de dos equipos: . . 7.4.4. Simulación de un sistema serie-paralelo de 3 equipos: 7.4.5. Simulación de un sistema serie-paralelo de 6 equipos: 7.4.6. Simulación de sistema serie-paralelo de 13 equipos: .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. 23 23 25 25 29 45 47 49 58 67 72 79 84. 8. Análisis de Resultados. 91. 9. Análisis de Cumplimiento de los Objetivos. 95. Conclusiones. 97. Bibliografía. 99.
(9) Lista de Figuras. 1-1. 1-2. 1-3. 1-4.. Ejemplo Ejemplo Ejemplo Ejemplo. de de de de. sistema sistema sistema sistema. de 1 equipo . Serie . . . . . Serie-Paralelo MIMO . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 2 2 3 3. 5-1. Diagrama de Flujo- Programación de Eventos . . . . . . . . . . . 5-2. Proceso Estocástico . . . . . . . . . . . . . . . . . . . . . . . . . .. 15 17. 6-1. Plan de trabajo de la pasantía . . . . . . . . . . . . . . . . . . . .. 22. 7-1. 7-2. 7-3. 7-4. 7-5. 7-6. 7-7.. 27 28 30 33 34 36. Estructura del mensaje JSON inicial . . . . . . . . . . . . . . . . Diagrama de entradas/salidas del módulo LECJSON . . . . . . . Cuadro jerárquico de la nueva estructura JSON . . . . . . . . . . Diagrama de entradas/salidas del módulo Interpretador . . . . . Conceptualización de “súper equipo” . . . . . . . . . . . . . . . . Algoritmo SED general . . . . . . . . . . . . . . . . . . . . . . . . Diagrama de flujo del subproceso de Encolamiento y reinstanciación de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8. Diagrama de flujo del subproceso de registro y procesamiento serie 7-9. Representación de una intersección temporal de eventos . . . . . . 7-10.Diagrama de flujo del subproceso de registro y procesamiento paralelo 7-11.Sistema 1: Un equipo . . . . . . . . . . . . . . . . . . . . . . . . . 7-12.Costos totales por periodo de mantenimiento asociados a la configuración del sistema 1 . . . . . . . . . . . . . . . . . . . . . . . . 7-13.Costo debido por la pérdida de producción por periodo de mantenimiento para la configuración del sistema 1 . . . . . . . . . . . . 7-14.Costo Pmax debido a las intervenciones por periodo de mantenimiento para la configuración del sistema 1 . . . . . . . . . . . . . 7-15.Periodo sugerido de mantenimiento para el sistema 1 . . . . . . .. 38 40 41 42 49 50 50 51 51.
(10) x. LISTA DE FIGURAS 7-16.Comparación de costos del sistema 1 con la configuración inicial y con el nuevo periodo de mantenimiento . . . . . . . . . . . . . . . 7-17.Comparativo de los resultados de MainTuner contra la herramienta comercial en los puntos destacados para la configuración 1 del sistema 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18.Costos totales por periodo de mantenimiento asociados a la configuración 2 del sistema 1 . . . . . . . . . . . . . . . . . . . . . . . 7-19.Costos totales por periodo de mantenimiento asociados a la configuración 3 del sistema 1 . . . . . . . . . . . . . . . . . . . . . . . 7-20.Comparativo de los resultados de MainTuner contra la herramienta comercial en los puntos destacados para la configuración 2 del sistema 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21.Comparativo de los resultados de MainTuner contra la herramienta comercial en los puntos destacados para la configuración 3 del sistema 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22.Sistema 2: Dos equipos en conexión serie . . . . . . . . . . . . . . 7-23.Costos totales por periodo de mantenimiento asociados a la configuración 1 del sistema 2 . . . . . . . . . . . . . . . . . . . . . . . 7-24.Costo debido por la pérdida de producción por periodo de mantenimiento para la configuración 1 del sistema 2 . . . . . . . . . . . 7-25.Costo Pmax debido a las intervenciones por periodo de mantenimiento para la configuración 1 del sistema 2 . . . . . . . . . . . . 7-26.Periodo de mantenimiento con menor costo sugerido por la simulación del sistema 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27.Comparación de costos del sistema 2 con la configuración inicial y con el nuevo periodo de mantenimiento . . . . . . . . . . . . . . . 7-28.Comparativo de los resultados de MainTuner contra la herramienta comercial en los puntos destacados para la configuración 1 del sistema 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29.Costos totales por periodo de mantenimiento asociados a la configuración 2 del sistema 2 . . . . . . . . . . . . . . . . . . . . . . . 7-30.Costo debido por la pérdida de producción por periodo de mantenimiento para la configuración 2 del sistema 2 . . . . . . . . . . . 7-31.Costo Pmax debido a las intervenciones por periodo de mantenimiento para la configuración 2 del sistema 2 . . . . . . . . . . . . 7-32.Periodo de mantenimiento con menor costo sugerido por la simulación de la segunda configuración del sistema 2 . . . . . . . . . . .. 52. 53 55 55. 57. 57 58 59 59 60 60 61. 62 63 64 64 65.
(11) LISTA DE FIGURAS 7-33.Comparación de costos de la segunda configuración del sistema 2 con los parámetros iniciales y con el nuevo periodo de mantenimiento 7-34.Comparativo de los resultados de MainTuner contra la herramienta comercial en los puntos destacados para la configuración 2 del sistema 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-35.Sistema 3: Dos equipos en conexión paralela . . . . . . . . . . . . 7-36.Costos totales por periodo de mantenimiento asociados a la primera configuración del sistema 3 . . . . . . . . . . . . . . . . . . . . . . 7-37.Costo debido por la pérdida de producción por periodo de mantenimiento para la primera configuración del sistema 3 . . . . . . . 7-38.Costo Pmax debido a las intervenciones por periodo de mantenimiento para la primera configuración del sistema 3 . . . . . . . . . 7-39.Periodo de mantenimiento con menor costo sugerido por la simulación de la primera configuración del sistema 3 . . . . . . . . . . . 7-40.Comparación de costos de la segunda configuración del sistema 3 con los parámetros iniciales y con el nuevo periodo de mantenimiento 7-41.Comparativo de los resultados de MainTuner contra la herramienta comercial en los puntos destacados para la primera configuración del sistema 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-42.Sistema 4: 3 equipos en conexión serie-paralelo . . . . . . . . . . . 7-43.Costos totales por periodo de mantenimiento asociados a la configuración 1 del sistema 4 . . . . . . . . . . . . . . . . . . . . . . . 7-44.Costo debido por la pérdida de producción por periodo de mantenimiento para la configuración 1 del sistema 4 . . . . . . . . . . . 7-45.Costo Pmax debido a las intervenciones por periodo de mantenimiento para la configuración 1 del sistema 4 . . . . . . . . . . . . 7-46.Periodo sugerido de mantenimiento para el sistema 4 . . . . . . . 7-47.Comparación de costos del sistema 4 con la configuración inicial y con el nuevo periodo de mantenimiento . . . . . . . . . . . . . . . 7-48.Comparativo de los resultados de MainTuner contra la herramienta comercial en los puntos destacados para la configuración 1 del sistema 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-49.Costos totales por periodo de mantenimiento asociados a la configuración 2 del sistema 4 . . . . . . . . . . . . . . . . . . . . . . . 7-50.Comparativo de los resultados de MainTuner y la herramienta comercial para la configuración 2 del sistema 4 . . . . . . . . . . . . 7-51.Sistema 5: 6 Equipos en conexión serie-paralelo . . . . . . . . . .. xi. 65. 66 67 68 68 69 69 70. 71 72 73 73 74 74 75. 76 77 78 79.
(12) xii. LISTA DE FIGURAS 7-52.Costos totales por periodo de mantenimiento asociados al sistema 5 7-53.Costo debido por la pérdida de producción por periodo de mantenimiento para el sistema 5 . . . . . . . . . . . . . . . . . . . . . . 7-54.Costo Pmax debido a las intervenciones por periodo de mantenimiento para el sistema 5 . . . . . . . . . . . . . . . . . . . . . . . 7-55.Periodo de mantenimiento con menor costo sugerido por la simulación del sistema 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-56.Comparación de costos de la configuración del sistema 5 con los parámetros iniciales y con el nuevo periodo de mantenimiento . . 7-57.Comparativo de los resultados de MainTuner y la herramienta comercial para la configuración del sistema 5 . . . . . . . . . . . . . 7-58.Sistema 6: 13 equipos en conexión serie-paralelo . . . . . . . . . . 7-59.Costos totales por periodo de mantenimiento asociados al sistema 6 7-60.Costo debido por la pérdida de producción por periodo de mantenimiento para el sistema 6 . . . . . . . . . . . . . . . . . . . . . . 7-61.Costo Pmax debido a las intervenciones por periodo de mantenimiento para el sistema 6 . . . . . . . . . . . . . . . . . . . . . . . 7-62.Periodo de mantenimiento con menor costo sugerido por la simulación del sistema 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-63.Comparación de costos de la configuración del sistema 6 con los parámetros iniciales y con el nuevo periodo de mantenimiento . . 7-64.Comparativo de los resultados de MainTuner y la herramienta comercial para la configuración del sistema 6 . . . . . . . . . . . . .. 80 80 81 81 82 83 84 86 86 87 87 88 89.
(13) Lista de Tablas. 7-1. 7-2. 7-3. 7-4. 7-5. 7-6.. Lista de Operaciones utilizadas en el algoritmo . . . . . . . . . . . Lista de variables utilizadas en el algoritmo . . . . . . . . . . . . . Lista de la notación húngara utilizada . . . . . . . . . . . . . . . . Primera configuración del sistema 1 . . . . . . . . . . . . . . . . . Datos obtenidos de la primera configuración del Sistema 1 . . . . Correlación entre resultados de MainTuner y la herramienta comercial para la configuración 1 del sistema 1 . . . . . . . . . . . . . . 7-7. Segunda configuración del sistema 1 . . . . . . . . . . . . . . . . . 7-8. Tercera configuración del sistema 1 . . . . . . . . . . . . . . . . . 7-9. Datos obtenidos de la segunda configuración del Sistema 1 . . . . 7-10.Datos obtenidos de la tercera configuración del Sistema 1 . . . . . 7-11.Correlación entre resultados de MainTuner y la herramienta comercial para la configuración 2 y 3 del sistema 1 . . . . . . . . . . . . 7-12.Primera configuración del sistema 2 . . . . . . . . . . . . . . . . . 7-13.Datos obtenidos de la primera configuración del Sistema 2 . . . . 7-14.Correlación entre resultados de MainTuner y la herramienta comercial de la primera configuración del sistema 2 . . . . . . . . . . . . 7-15.Segunda configuración del sistema 2 . . . . . . . . . . . . . . . . . 7-16.Datos obtenidos de la segunda configuración del Sistema 2 . . . . 7-17.Correlación entre resultados de MainTuner y la herramienta comercial de la segunda configuración del sistema 2 . . . . . . . . . . . 7-18.Primera configuración del sistema 3 . . . . . . . . . . . . . . . . . 7-19.Datos obtenidos de la segunda configuración del Sistema 2 . . . . 7-20.Correlación entre resultados de MainTuner y la herramienta comercial de la primera configuración del sistema 3 . . . . . . . . . . . . 7-21.Primera configuración del sistema 4 . . . . . . . . . . . . . . . . . 7-22.Datos obtenidos de la primera configuración del Sistema 4 . . . .. 37 39 46 49 53 53 54 54 56 56 57 58 61 62 63 66 66 67 70 71 72 75.
(14) xiv. LISTA DE TABLAS 7-23.Correlación entre resultados de MainTuner y la herramienta comercial para la configuración 1 del sistema 4 . . . . . . . . . . . . . . 7-24.Segunda configuración del sistema 4 . . . . . . . . . . . . . . . . . 7-25.Datos obtenidos de la segunda configuración del Sistema 4 . . . . 7-26.Correlación entre resultados de MainTuner y la herramienta comercial para la configuración 2 del sistema 4 . . . . . . . . . . . . . . 7-27.Configuración del sistema 5 . . . . . . . . . . . . . . . . . . . . . 7-28.Datos obtenidos de la configuración del Sistema 5 . . . . . . . . . 7-29.Correlación entre resultados de MainTuner y la herramienta comercial para la configuración del sistema 5 . . . . . . . . . . . . . . . 7-30.Configuración del sistema 6 . . . . . . . . . . . . . . . . . . . . . 7-31.Datos obtenidos de la configuración del Sistema 6 . . . . . . . . . 7-32.Correlación entre resultados de MainTuner y la herramienta comercial para la configuración del sistema 6 . . . . . . . . . . . . . . .. 76 77 78 78 79 82 83 85 88 89.
(15) Introducción En Colombia, a través de las décadas se ha visto la necesidad de implementar soluciones para mejorar el desempeño de sistemas industriales, que han tomado fuerza a la par con el desarrollo tecnológico de los últimos años. Estas soluciones están propuestas para que, de alguna forma, mejoren los resultados de producción y costos de un proceso industrial [1]. Con los nuevos avances tecnológicos, implementar esta clase de soluciones ha tomado importancia, puesto que en un proceso industrial, se buscará generar siempre la mayor cantidad de producción (según su capacidad) y el menor costo de producción posible. Si el sistema industrial se mantiene en operación durante más tiempo, más producción se obtiene y las ganancias son mayores. En cambio, si el sistema detiene su operación, además de los gastos en los que se incurre para en el sistema, se deja de percibir la ganancia asociada a la producción, y esta se puede traducir en millonarias perdidas, dependiendo del tipo de industria. La pérdida de producción tiene muchas consecuencias que pueden resultar graves en determinados casos. En las petroleras, por ejemplo, no extraer petróleo puede llevar a tener pérdidas exorbitantes, por lo cual es necesario evitar la reducción de los niveles de producción, para que los costos por lucro cesante (pérdida por falta de producción) sean los menores posibles. Por otra parte, un sistema o equipo puede presentar fallas en un determinado tiempo, generalmente asociado al ciclo útil de funcionamiento, o bien, la falta de mantenimiento a los equipos. Cuando un equipo falla, se pierde la producción que dicho equipo puede aportar. Si el equipo es esencial en el sistema, una falla puede llevar a detener toda la producción, lo cual conlleva a perder mucho dinero por dejar de producir. Con el fin de evitar que los equipos fallen, se programan mantenimientos preventivos a los equipos..
(16) xvi. INTRODUCCIÓN Sin embargo, realizar mantenimiento a los equipos conlleva apagarlos o desconectarlos del sistema, por lo que también provoca un bajón de producción, por tanto, no es conveniente realizar mantenimientos en intervalos muy cortos. Aún así, al realizar mantenimientos preventivos se puede disminuir el costo que conlleve mantener al sistema en operación, ya que los costos de mantenimiento preventivos son generalmente menores a los costos de corrección de fallas, por ende, es importante que el sistema presente la menor cantidad de fallas posibles sin perjudicar la producción debido a mantenimientos preventivos. Actualmente, las herramientas de simulación de sistemas industriales han tomado importancia, ya que permiten modelar sistemas de complejidades bajas hasta sistemas de alta complejidad y son capaces de representar la funcionalidad de un sistema como si estuviera funcionando realmente. Esto permite observar, por ejemplo, el comportamiento del proceso de producción en detalle, modificar el diseño y realizar pruebas por computadora sin necesidad de tocar el sistema industrial. Así, se asegura que un sistema no se implemente hasta que la simulación otorgue un balance positivo, ya que si se presenta algún problema en simulación, se sabrá que es un fallo que hay que corregir. Al juntar la practicidad de la simulación de un sistema industrial y el objetivo de disminuir costos de producción y maximizar ganancias, surge la idea de crear un programa de simulación que permita modelar un sistema industrial determinado para observar su comportamiento aproximado, y en base a esto, realizar la respectiva disminución de costos, reflejados por un barrido de periodos de mantenimiento. En otras palabras, se modifican los intervalos de mantenimiento preventivo, con el fin de encontrar un periodo adecuado, en donde el sistema presente el menor número de fallas, pero que a la vez, no se hagan demasiados mantenimientos que bajen la producción o eleven los costos al sistema mencionado, con el fin de tener una mayor productividad..
(17) Capítulo 1 Antecedentes Knowledge and Integration Architects S.A.S. - Knar - es una empresa Colombiana dedicada al desarrollo de servicios de análisis de riesgo y consultoría en temas de confiabilidad industrial. Actualmente, Knar ha venido trabajando con un software de simulación enfocado en el análisis de comportamiento de una planta extractora de combustible, con los inconvenientes de los muy altos costos de licencia vitalicia y capacitación, baja flexibilidad de simulación, y además, el software, no ofrece ninguna sugerencia de mejoramiento de la productividad [2].. Proyecto MainTUNER Con el fin de desarrollar una herramienta de simulación que esté en capacidad de superar las limitaciones de Taro, desde enero de 2018, a partir de pasantías con la Universidad Nacional de Colombia (sede Bogotá) y la Universidad Distrital “Francisco José de Caldas”, Knar ha venido trabajando en el desarrollo de un programa de sintonización de mantenimientos, llamado MainTUNER. En un principio, el proyecto MainTUNER fue estructurado en 5 fases, detalladas a continuación.. Fase 1: MainTUNER Versión 0.1 En esta fase se desarrolló la contextualización de la versión inicial del método de 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 para la conceptualización del proyecto..
(18) 2. 1 Antecedentes Fase 2: MainTUNER Versión 0.2 En esta fase se realiza una aproximación del algoritmo basado en simulación de eventos discretos para un sistema de un solo equipo, como se muestra en la Figura 1-1. Se integra a la fase 1 con el objetivo de verificar si la versión 0.1 logra la sintonización de costo para un sistema simplificado a un equipo.. Figura 1-1: Ejemplo de sistema de 1 equipo Fase 3: MainTUNER Versión 0.3 En esta fase se realiza una nueva aproximación del algoritmo para el procesamiento de un sistema conformado por equipos conectados en serie, como se muestra en la Figura 1-2. Se integra a las fases anteriores para verificar que se logra una correcta sintonización de costos para esta configuración de equipos.. 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 el sistema serie. Fase 4: MainTUNER Versión 0.4 En esta fase se realiza una mejora a la aproximación del algoritmo, para el procesamiento de un sistema conformado por equipos conectados en serie y paralelo, con la limitante de tener un único flujo de entrada/salida, como se muestra en la.
(19) 3 Figura 1-3. Se integra a las fases anteriores para verificar que se logra una correcta sintonización de costos para esta configuración de equipos.. Figura 1-3: Ejemplo de sistema Serie-Paralelo Con respecto a la anterior fase, se adiciona: Algoritmo para el sistema de conexión paralelo entre equipos Cálculo de capacidades para el sistema Sintonización de costos en función de los periodos de mantenimiento para el sistema serie-paralelo Fase 5: MainTUNER Versión 0.5 En esta última fase, se realiza una aproximación final a MainTUNER, que permita hacer el procesamiento de un sistema serie paralelo de mayor complejidad (múltiples redes y nodos), como se muestra en la Figura 1-4. Se integra a las fases anteriores para verificar que se logra una correcta sintonización de costos para esta configuración de equipos.. Figura 1-4: Ejemplo de sistema MIMO.
(20) 4. 1 Antecedentes Con respecto a la anterior fase, se adiciona: Algoritmo para el sistema de conexión mixta entre equipos Sintonización de costos en función de los periodos de mantenimiento para el sistema mixto.
(21) Capítulo 2 Planteamiento del problema En la actualidad, el desarrollo del proyecto MainTuner se encuentra listo para iniciar su fase 4 de desarrollo, esta pasantía estará orientada a trabajar en dicha fase, teniendo como base lo realizado hasta la fase 3 (Procesamiento de sistemas de conexión únicamente serie). Fundamentalmente, se requiere elevar el nivel de complejidad de los sistemas que se buscan sintonizar. Es decir, se busca subir la complejidad al implementar un diseño que permita evaluar sistemas con equipos en conexión tanto serie como paralelo. El trabajo de la fase 4 se segmenta en 3 enfoques generales: modelamiento, simulación y sintonización. En esta pasantía se buscará resolver uno de dichos enfoques, más específicamente la simulación. Partiendo del diseño que se tiene del trabajo anterior para equipos con conexión en serie, se creará un nuevo diseño, adaptado para procesar equipos conectados tanto en serie como en paralelo. Además, se agregará un método de sintonización realizado en la fase previa, con el fin de observar con detalle el nivel de producción que presenta el sistema industrial..
(22)
(23) Capítulo 3 Objetivos 3.1.. Objetivo general. Desarrollar un algoritmo que permita realizar un análisis de disponibilidades y costos para sistemas de complejidad media (sistemas con equipos en conexión serie-paralelo).. 3.2.. Objetivos específicos. 1. Diseñar un algoritmo que realice el registro y procesamiento de eventos discretos asociados a equipos conectados en serie. 2. Diseñar un algoritmo que realice el registro y procesamiento de eventos discretos asociados a equipos conectados en paralelo. 3. Diseñar un algoritmo base, a partir de los dos diseños anteriores, que realice el registro y procesamiento de los eventos discretos asociados a los equipos de un sistema serie-paralelo. 4. Implementar en código el algoritmo base diseñado, utilizando lenguaje Julia. 5. Validar resultados obtenidos del algoritmo codificado contra los resultados obtenidos de una herramienta de simulación comercial..
(24)
(25) Capítulo 4 Alcances y Limitaciones 4.1.. Alcances. Considerando que en el desarrollo de esta pasantía se obtendrá una parte del proyecto completo, su alcance estará sujeto a la Simulación de Eventos Discretos (SED en adelante). El algoritmo a diseñar para SED consistirá en hacer el registro y procesamiento de los eventos discretos asociados a los equipos de un sistema serie-paralelo. Este algoritmo, al final de esta pasantía, cumplirá con las siguientes funciones: Identificación de los eventos discretos de un sistema serie-paralelo. Lectura de las relaciones entre los equipos del sistema (tipo de conexión de los equipos en el sistema) Creación de una línea de tiempo en donde se obtenga el encolamiento de eventos del sistema según su ocurrencia, duración y demás información relevante del evento ocurrido. Corroboración de los datos a través del método de Monte Carlo, quien le da una caracterización estocástica al fenómeno a simular. Comparación de los resultados de la simulación contra los datos arrojados por una herramienta de simulación comercial.. 4.2.. Limitaciones. Como se menciona en la sección de alcances, el proyecto estará limitado en cuanto a que se hará una parte de lo que es el proyecto general. Por ende, las limitaciones.
(26) 10. 4 Alcances y Limitaciones estarán sujetas a: Desarrollo de una etapa de modelamiento, en donde se llegue a una interfaz de usuario. No se garantizará un mejor resultado para todos los sistemas. No se buscarán óptimos periodos de mantenimiento, sino periodos de mantenimiento que reduzcan el costo de lucro cesante..
(27) Capítulo 5 Marco Teórico Este capítulo consiste en la contextualización de la información teórica de las temáticas que conforman el proyecto. La información recopilada se enfocará en algunos temas de gran importancia dentro del proyecto: Simulación con énfasis en simulación de eventos discretos, debido a que el trabajo previo realizó en base a este paradigma, procesos estocásticos y métodos de Monte Carlo, debido a que estos dos elementos conforman la base del modo en que se trabajan los sistemas reales en la industria debido a su complejidad.. 5.1.. Simulación. Cuando se requiere estudiar un sistema, con el fin de medir desempeño y hacer toma de decisiones, es posible experimentar con el sistema real y cambiar sus condiciones, de manera en que se obtengan los resultados provenientes de la cotidianidad del sistema en funcionamiento (los cuales no están contemplados del todo en el diseño de dicho sistema) [3], de manera que no sea necesario realizar un modelo que represente el mismo comportamiento del sistema y además, se obtengan resultados reales de este. Sin embargo, dicha experimentación directa puede implicar, entre otras cosas, gastos en su ejecución e incluso, consecuencias en el entorno en que se desarrolla en aquellos en que los experimentos podrían tener una larga duración [4]. Por lo tanto, cuando los sistemas presentan mayor dificultad en su evaluación física, es necesario y además útil, la creación de un modelo que permita imitar su funcionamiento y de esta manera evaluar su desempeño ante la variación de sus componentes, y por ende de las situaciones a las que se enfrentará. Estos modelos deberán ser construidos con el suficiente detalle para que puedan ser considerados los posibles agentes externos (como los cotidianos)..
(28) 12. 5 Marco Teórico. La simulación como herramienta computacional, consiste en la utilización de técnicas de análisis matemático, las cuales permiten imitar el funcionamiento de procesos mediante el determinado modelo que los represente. Según Kelton y Sadowski en [3], la simulación (por computador), se refiere a los métodos para estudiar una gran variedad de modelos de sistemas del mundo real mediante la evaluación numérica, usando software diseñado para imitar las operaciones o características de estos, por lo general, en el transcuso del tiempo y bajo determinadas condiciones. Aunque esta puede ser usada para el estudio de sistemas sencillos, el verdadero sentido de usar esta técnica surge cuando se requiere estudiar sistemas con mayor complejidad.. 5.1.1.. Etapas para realizar un Estudio de Simulación. Los pasos para llevar a cabo la experimentación de un sistema por medio de simulación, de acuerdo a [4], se detallan a continuación. Definición del Sistema: Es necesario hacer en primera medida, hacer un análisis preliminar del mismo, de manera que se determinen las restricciones del sistema, sus variables las relaciones entre estas, las medidas de efectividad y los resultados que se esperan obtener del estudio. Formulación del modelo: Se definen las variables que conforman el modelo, las relaciones entre ellas y los diagramas que describan completamente el modelo. Existen diferentes tipos de modelos, los cuales pueden ser aplicados a un sistema según sea la necesidad de sus resultados. Estos modelos pueden clasificarse en: estáticos y dinámicos (dependiendo de si es importante la evolución de las variables en el tiempo o no), determinísticos y estocásticos (dependiendo de si se consideran variables de naturaleza estocástica o no) y, continuos y discretos (dependiendo de si las variables cambian continuamente en el tiempo o solo en instantes específicos) [4], [5] y [6]. Recolección de Datos: Se definen con exactitud los datos que el modelo va a requerir para producir los resultados deseados. Esta información se puede obtener de registros contables, opiniones de expertos o incluso de experimentación..
(29) 5.1 Simulación Implementación del modelo: Instauración del modelo para el procesamiento del mismo en computador. Validación: Mediante esta etapa se encuentran las deficiencias en la formulación del modelo y su veracidad se basa principalmente en: Resultados esperados analíticamente. Exactitud de la predicción del futuro. La comprobación de falla del modelo al utilizar datos que hacen fallar al sistema real. Experimentación: Generación de los datos deseados y análisis de sensibilidad de los índices requeridos. Interpretación: Se interpretan los resultados arrojados en la simulación. Para el desarrollo de un modelo de simulación de sistemas, el trabajo que nos antecede, realizó la elección del paradigma de simulación de Eventos Discretos [7].. 5.1.2.. Simulación de Eventos Discretos. La Simulación de Eventos Discretos (SED en adelante) hace referencia al modelamiento computacional de sistemas, mediante la evaluación de los cambios instantáneos en las variables de estado [6]. Estos cambios ocurren en puntos separados de tiempo no equiespaciados [4] determinados por eventos. Los eventos se definen como los sucesos que hacen que el sistema cambie de estado al presentarse. El modelo con SED salta desde el tiempo de ocurrencia de un evento hacia el tiempo de ocurrencia del siguiente evento. Este tipo de modelo permite dar flexibilidad y eficiencia para ser usada en amplia variedad de situaciones reales [6]. Una SED modela el progreso de los sistemas de Colas a través del tiempo, por lo tanto, es útil para problemas que consisten en simulaciones de colas o redes complejas con colas en los cuales los procesos pueden ser bien definidos y el énfasis está en representar incertidumbre a través de distribuciones estocásticas. Muchas de estas aplicaciones ocurren en las industrias de manufactura y servicio [6]. Las partes que componen una SED se mencionan a continuación [3],[6].. 13.
(30) 14. 5 Marco Teórico Entidades: Son objetos dinámicos que cambian de estado y afectan y son afectados por otras entidades en el estado del sistema. Se mueven durante el tiempo de la simulación. Todas las entidades deben ser creadas. Atributos: Son las características comunes de todas las entidades pero con un valor en específico en cada una de manera que se diferencien. Variables (Globales): Son información que refleja alguna característica del sistema independientemente de las entidades de este. Recursos: Representa el objeto que provee un servicio a una entidad. El recurso es utilizado por la entidad y lo libera cuando termina de usarlo, de manera que otras entidades utilicen el recurso. Colas: Cuando un recurso no está disponible para ser utilizado por una entidad y esta última no puede avanzar en el tiempo, la entidad espera en una cola. Las colas tienen capacidades y reglas que definen la prioridad de las entidades como FIFO (First In First Out). Línea de Tiempo: Contiene el tiempo de ocurrencia de los eventos del sistema en el tiempo simulado requerido. El tiempo de ocurrencia está determinado según sus atributos, por lo general, determinado por los números aleatorios que siguen el comportamiento de la distribución de probabilidad que los caracterizan. Reloj de Simulación: Mantiene el registro del tiempo. Este reloj no registra el paso del tiempo de forma continua, 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 de simulación requerido. La línea de tiempo está determinada por el enfoque de la SED, puesto que esta se genera teniendo en cuenta las relaciones que se consideren entre los eventos del sistema. Este enfoque está dado por el paradigma de SED seleccionado. Entre los paradigmas de SED, se tienen [4] y [6]: Programación de Eventos. Exploración de Actividades. Interacción de Procesos..
(31) 5.1 Simulación Programación de Eventos Este paradigma consiste principalmente en que la línea de tipo incluye la relación causal entre los eventos y, por lo tanto, puede planificar eventos para instantes futuros y cancelar la planificación de eventos que ya estaban definidos. La Figura 5-1 muestra el algoritmo en forma de diagrama de flujo que permite la simulación del sistema mediante Programación de Eventos [4].. Figura 5-1: Diagrama de Flujo- Programación de Eventos En donde: Rutina de Inicialización: Asigna los atributos a los eventos y programa la línea de tiempo. Rutina de Tiempo: Determina cuál es el evento más inminente de los programados y avanza el reloj de simulación hasta ese instante. Rutinas de Eventos: Realizan el flujo de acciones asociado a cada evento dependiendo d las relaciones de dicho evento con otros. Puede añadir o quitar eventos de la línea de tiempo. Rutina de Informes: Calcula y muestra el valor de las variables de salida.. 15.
(32) 16. 5 Marco Teórico Exploración de Actividades En este paradigma de SED se describen la actividades en las que participan las entidades del sistema y determina las condiciones que causan que una actividad inicie o finalice [6]. Los eventos no son programados por el modelador sino que son ejecutados por las condiciones especificadas. Interacción de Procesos Muchos modelos de simulación incluyen secuencias de elementos que ocurren en patrones definidos a lo largo del tiempo [6]. Este paradigma permite facilitar la descripción de los modelos puesto que consiste en tomar el punto de vista de las entidades y describir su circulación a través del sistema, es decir, se centra en los procesos que llevan a cabo las entidades durante la simulación [4]. En esencia este paradigma está orientado a la Programación de Eventos, pero en este caso se permite obtener una interacción con el usuario, puesto que tiene una presentación gráfica del estado de los procesos. Este paradigma es desarrollado empleando entornos de simulación que facilita la descripción del modelo mediante interfaces de usuario. Las principales características de una SED se muestran a continuación [7]: Casi todos los modelos de SED presentan la necesidad de representar la aleatoriedad del sistema a estudiar y por lo tanto se puede decir que SED es estocástica por naturaleza. Pertenece a la clasificación de simulación discreta, donde el estado del sistema sólo puede cambiar en puntos discretos de tiempo en los que ocurren eventos. El análisis de los datos de entrada y salida de los modelos de simulación requiere conocimientos de estadística. Representaciones creíbles de parámetros estocásticos en simulaciones dinámicas requieren un número extenso de datos. Por otro lado, también se requiere el uso de métodos estadísticos para el análisis de los resultados. Se deben tomar decisiones acerca de el número de replicaciones independientes que se requieren, la duración de la corrida de simulación, el uso de técnicas de reducción de varianza, la selección de los escenarios, etc..
(33) 5.2 Procesos Estocásticos y Métodos de Monte Carlo. 5.2.. Procesos Estocásticos y Métodos de Monte Carlo. Los procesos estocásticos están definidos por una familia o colección de variables aleatorias que varían con el tiempo. Un ejemplo de un proceso estocástico es como el que se observa en la figura 5-2. Figura 5-2: Proceso Estocástico Los Estados son los posibles valores que pueden tomar las variables aleatorias, por lo que se puede tener un espacio de estados discreto o un espacio de estados continuo. Las variables aleatorias pueden cambiar con respecto a tiempo discreto o continuo. En el caso del tiempo discreto se podría tomar que los cambios de estado ocurran cada día, cada mes, etc.. En el caso del tiempo continuo, los cambios de estado se podrían realizar en cualquier instante. Bajo las diferencias que puede haber entre un proceso estocástico y otro, se definen algunos tipos de procesos [8]: Una Cadena es un proceso estocástico en el cual el tiempo y las variables aleatorias solo toman valores discretos. Un Proceso de Saltos Puros es un proceso estocástico en el cual los cambios de estados ocurren en forma aislada y aleatoria pero la variable aleatoria sólo toma valores discretos en el espacio de estados. En un Proceso Continuo los cambios de estado se producen en cualquier instante y hacia cualquier estado dentro de un espacio continuo de estados.. 17.
(34) 18. 5 Marco Teórico Sobre la teoría existen muchas más clasificaciones determinadas por características específicas del modo en que se describe el tiempo, las variables aleatorias y por las distribuciones de probabilidad que describen la variables. Muchos fenómenos de la naturaleza, las finanzas y la ingeniería pueden ser caracterizados por procesos estocásticos debido a la dificultad de generar un modelo analítico. Sin embargo, sobre estos cálculos siempre existe incertidumbre. La incertidumbre se refiere a la situación en que no se tiene completo conocimiento sobre un proceso dado, esta falta de conocimiento puede referirse a la descripción del proceso, sus causas o sus resultados [9]. En este punto los algoritmos computacionales pueden aportar en gran medida para disminuir el error en los resultados que provean los modelos estocásticos de procesos reales.. Métodos de Monte Carlo Muchos problemas numéricos en ciencia, ingeniería, finanzas y estadísticas que presentan dificultad en generar una solución analítica, son resueltos hoy en día gracias a algoritmos computacionales, es decir, a través de experimentos en una computadora [10]. Los Métodos de Monte Carlo proponen la realización de experimentos regidos por variables aleatorias, en donde se busca reducir el error de los resultados mediante el número de repeticiones (error = √1N , N es el número de repeticiones), todo esto hoy en día facilitado por el avance tecnológico de las computadoras, permitiendo que el error pueda ser llevado a valores mínimos. Luego de obtener las N repeticiones, se observan las características estadísticas de los experimentos (resultados del modelo), permitiendo que finalmente se puedan realizar conclusiones sobre los resultados del modelo en función de los experimentos estadísticos. En general la aplicación de este método para obtener resultados de un proceso cualquiera se pueden enmarcar en los siguientes pasos [11]: Generación de números aleatorios siguiendo una distribución de probabilidad previamente obtenida de experimentos reales. Experimentación numérica, es decir la evaluación numérica de funciones de desempeño para N repeticiones..
(35) 5.2 Procesos Estocásticos y Métodos de Monte Carlo Análisis estático de la salida del modelo, es decir, la extracción de la información probabilística contenida en los resultados. Los métodos de Monte Carlo se pueden aplicar en diferentes áreas de la ingeniería, estas son en Estimación, Optimización, aproximaciones numéricas e integrales multidimensionales con el uso integradode cadenas de Markov [12], y Simulación. En simulación se usa principalmente en simulación de sistemas que están descritos por eventos (Simulación de Eventos Discretos).. 19.
(36)
(37) Capítulo 6 Plan de Trabajo 6.1.. Metodología. La metodología a seguir para cumplir con el proyecto propuesto será realizar, en primer lugar, una segmentación del mismo en 4 pasos, como se estableció en los objetivos, es decir, el plan de trabajo consistirá en cumplir con los objetivos uno por uno, resolviendo problemas pequeños para finalmente construir y resolver el problema mayor. Primero, se hará una contextualización del proyecto, en donde se observarán con detalle y se entenderán todos los conceptos y requerimientos que debe tener dicho proyecto, además de hacer una contextualización en cuanto al alcance del proyecto hasta el momento. Una vez se complete esta etapa, vendrá la etapa de desarrollo del algoritmo. En esta etapa, se realizará un diseño que cumpla con el correcto registro y procesamiento de los eventos asociados a los equipos de un sistema serie-paralelo. Posteriormente, una vez se tenga el diseño, llega la etapa de implementación, en donde, como su nombre lo indica, se hará la implementación en código del diseño obtenido y se validarán los resultados con lo esperado según el algoritmo propuesto. Finalmente, se hará la etapa de validación, en donde, utilizando el método de Montecarlo, se hará una corroboración de los resultados obtenidos por medio de una herramienta comercial. De esta forma, la metodología a usar para la realización de este proyecto se podrá observar de una mejor forma según la Figura 6-1..
(38) 22. 6 Plan de Trabajo. Figura 6-1: Plan de trabajo de la pasantía A continuación, se hará un detalle en cada etapa que compone el desarrollo de esta pasantía.. 6.1.1.. Etapa 1: Contextualización del proyecto. En esta primera etapa, para poder comenzar a desarrollar el algoritmo base del proyecto, se necesitará realizar primero una contextualización. Conocer de fondo la idea del proyecto es vital para entender lo que se requiere hacer, la necesidad del proyecto, los requerimientos que debe tener y la idea principal a la cual se quiere llegar. Una vez se entienda a fondo el proyecto, se pasará a estudiar los alcances realizados hasta el momento en la empresa. Esto será de gran ayuda para saber si se puede partir de lo hecho anteriormente por los pasantes anteriores.. 6.1.2.. Etapa 2: Desarrollo del Algoritmo. Una vez la contextualización esté lista, se pasa a diseñar el algoritmo. Para ello, se segmentará el problema en 3 secciones: el algoritmo principal, el algoritmo de procesamiento serie y el algoritmo de procesamiento paralelo. Se harán estos algoritmos por separado y una vez listos, se juntarán para conformar el algoritmo general. Esto se realizará con el fin de conseguir una mayor practicidad a la hora de implementar y de probar el algoritmo, ya que será segmentable, y por ende,.
(39) 6.1 Metodología muy práctico. Se realizará un diagrama de secuencias en donde se especifique los pasos del algoritmo, paso por paso, con entradas y salidas para cada función que se implemente, con el fin de que el algoritmo quede lo suficientemente claro y entendible para implementarlo en código.. 6.1.3.. Etapa 3: Implementación del Algoritmo. Cuando el diagrama de secuencia esté terminado, se procederá a implementarlo en Julia. El método de implementación será el mismo que se usó a la hora de diseñarlo, segmentando el proceso en el script principal, el script de procesamiento serie y el script de procesamiento paralelo. Cada script operará como función, cada una con entradas y salidas, y se conformará de subfunciones con tareas específicas según lo requiera el algoritmo. Al final se juntará todo en el script principal y se obtendrá el algoritmo implementado.. 6.1.4.. Etapa 4: Pruebas y Validación. Luego de tener el algoritmo implementado en código, se realizará la etapa de pruebas y validación de resultados. En esta etapa se buscará verificar si el algoritmo diseñado realiza o no las operaciones correctamente. Se validará el diseño con diferentes pruebas, (diferentes sistemas y parámetros) para comprobar veracidad de resultados. Estos resultados se corroborarán con los resultados obtenidos de una herramienta de simulación comercial, para finalmente determinar si el algoritmo arroja resultados coherentes.. 23.
(40)
(41) Capítulo 7 Desarrollo y Resultados En el presente capítulo se mostrará el desarrollo de cada una de las etapas propuestas en el capítulo anterior, las cuales dan cumplimiento a los objetivos establecidos.. 7.1.. Etapa 1: Contextualización del proyecto. A lo largo de esta etapa, se realiza una capacitación de lo que se tiene actualmente del proyecto MainTuner, es decir, el trabajo realizado en el proyecto hasta el momento. Para ello, se tiene como guía la documentación y los códigos realizados del proyecto hasta su fase 3, y con base en ella, se dará inicio a la fase 4, ya teniendo claridad de lo que es el proyecto y teniendo las bases para iniciar esta nueva fase. Para el completo entendimiento de lo que se tiene hasta el momento, se realiza una serie de tareas, las cuales se especifican a continuación. Contextualización de MainTuner: Como se había mencionado en el Capítulo 2, el proyecto MainTuner se segmenta en 3 enfoques generales: modelamiento, simulación y sintonización, este último incluyendo una etapa de paralelización, esta se incluye con el fin de mejorar el rendimiento de la aplicación. A continuación detallaremos cada uno de los enfoques. Modelamiento: En esta etapa se desarrolla la interacción con el usuario. El usuario podrá, a partir de una aplicación por medio de una interfaz gráfica, modelar su sistema definiendo la estructura general de su planta industrial. También definirá la configuración de cada uno de los equipos, sus distribuciones de probabilidad de falla y mantenimiento inicial, entre otros, los datos generales del sistema se detallarán más adelante. Esta etapa permitirá obtener los recursos necesarios para trabajar en la etapa de simulación..
(42) 26. 7 Desarrollo y Resultados Simulación: En esta etapa se desarrolla el proceso de encolamiento y tratamiento de los eventos extraídos de la etapa de modelamiento, basados en el paradigma de Simulación de Eventos Discretos (SED). Esta etapa es el núcleo del proyecto, ya que, con base en la información recolectada del sistema, se hace el procesamiento que permite obtener los datos de confiabilidad, costo y capacidad para cada periodo de mantenimiento. Sintonización: En esta etapa se desarrolla la búsqueda de un periodo de mantenimiento que reduzca el costo y maximice la capacidad del sistema. Para ello, se realiza un barrido (variación) del periodo de mantenimiento, con el fin de obtener una curva de costos y capacidades en función del periodo de mantenimiento. Esta etapa está en constante conexión con la etapa de simulación, ya que, una vez obtiene los datos de confiabilidad, costo y capacidad para el periodo de mantenimiento inicial, cambia el periodo de mantenimiento según el paso del barrido ingresado por el usuario y retorna a realizar la simulación para dicho periodo, y así sucesivamente hasta recorrer el rango de búsqueda también ingresado por el usuario.. En el caso de esta práctica, las actividades realizadas se enfocan en el desarrollo de la etapa de simulación. Para su realización, se considera necesario comprender no sólo lo realizado hasta el momento en la etapa de simulación, sino también entender a plenitud lo realizado en particular en la etapa de modelamiento, ya que en dicha etapa se obtienen los insumos con los cuales se trabajará en la etapa a realizar.. Entendimiento de la estructura del archivo JSON: Con base en un mensaje JSON obtenido en la etapa de modelamiento, se hace un estudio con el fin de observar la estructura del mismo, y entender como se extrae la información de este formato de texto. El mensaje JSON inicial tiene la estructura como se muestra en la Figura 7-1 [13]. Esto será de gran ayuda a la hora de poner en marcha la etapa 2 del proyecto (definida en el Capítulo 6), ya que nos permite entender las variables que se van a tratar y la forma de cómo deben tratarse..
(43) 7.1 Etapa 1: Contextualización del proyecto. Figura 7-1: Estructura del mensaje JSON inicial Modelo de entradas/salidas del módulo LECJSON: El módulo LECJSON tiene como funcionalidad la lectura y extracción de información proveniente del mensaje JSON. Para una mejor comprensión del proceso que se realiza para la lectura de los datos, se realiza un modelo de entradas y salidas general, el cual se observa en la Figura 7-2 El gestor de archivos lee el mensaje JSON y lo transforma a código Julia conservando la estructura inicial del archivo. El procesamiento de los datos se encarga de la extracción de los datos en diferentes arreglos de matrices y vectores con toda la información necesaria para la simulación.. 27.
(44) 28. 7 Desarrollo y Resultados. Figura 7-2: Diagrama de entradas/salidas del módulo LECJSON De esta forma, se obtienen las variables representadas en la Figura 7-2, siendo estas variables las que se procesan en el módulo SED: EventListConfig: Contiene información de ocurrencias y duraciones de los eventos, añadiendo tipo de evento y relación mantenimiento-falla. ConfigGroupMant: Contiene información de los grupos de mantenimiento asignados por el usuario. NumberEvents, NumberEquip, CostNoFlow, Iterations, LifeCycleTime, ConfidenceInterval: Información general del sistema asignado a cada variable correspondiente.. Análisis del módulo SED de la fase previa: Basados en lo realizado en la fase 3 del proyecto MainTuner, se realiza un análisis detallado del módulo SED actual, lo cual será la base para la fase 4 del proyecto. Primero se realiza una lectura del diagrama de flujo del módulo, el cual representa el proceso paso a paso del encolamiento y posterior registro y procesamiento de los eventos asociados a los equipos en conexión serie..
(45) 7.2 Etapa 2: Desarrollo del Algoritmo Luego se realiza una lectura del código del módulo SED programado en el lenguaje Julia para la fase actual. Se evidencia el proceso seguido en el diagrama de flujo y se toman consideraciones para la realización del nuevo módulo para la fase 4. Posteriormente, se realiza una prueba de escritorio para comprender el proceso y los resultados obtenidos en la fase 3 y finalmente, se realizan unas consideraciones finales para el nuevo módulo, tales como, la mejora de la organización y agrupamiento de la información general y adaptación del método de simulación por encolamiento. 7.2.. Etapa 2: Desarrollo del Algoritmo. Una vez contextualizados en el proyecto, se procede a realizar el diseño. A continuación se observan las tareas realizadas que corresponden al desarrollo del algoritmo. Introducción al manejo de repositorios: Con el fin de tener una mejor organización en el desarrollo del código, se considera la opción del manejo de repositorios. Por esto, se realiza un estudio de la guía de manejo de repositorios tanto en GitHub como en Git, con el objetivo de tener el mejor sistema de gestión de archivos para tener un mejor control del código y mejorar la organización de la programación. Se encontró que para la vinculación con el entorno de programación en Julia, ’Atom’, el sistema de repositorios de GitHub resulta ser más cómodo, ya que permite cargar los códigos en la nube con mucha facilidad, lo que permite una mejor comunicación entre ordenadores y un fácil acceso al código desde diferentes equipos.. Entendimiento de la estructura del nuevo mensaje JSON con equipos en paralelo: La fase 4 consiste en la integración de equipos en conexión paralela a MainTuner. Esto implica una evolución de los 2 primeros enfoques en los cuales se dividió el proyecto, modelamiento y simulación. por ende, es importante conocer cómo va a cambiar la etapa de modelamiento y qué nuevos parámetros se tendrán disponibles en la etapa de simulación.. 29.
(46) 30. 7 Desarrollo y Resultados Entonces, desde la etapa de modelamiento se crea un nuevo sistema que permite la configuración de equipos en paralelo, y la estructura del mensaje JSON generado con esta configuración se analiza, con el fin de entender los cambios realizados en comparación a la estructura del mensaje JSON anterior. La figura 7-3 representa la jerarquía de los elementos que componen el nuevo mensaje JSON, y se detalla a continuación:. Figura 7-3: Cuadro jerárquico de la nueva estructura JSON.
(47) 7.2 Etapa 2: Desarrollo del Algoritmo Proceso: Un proceso se establece como un conjunto de sistemas conectados entre sí. Un proceso tiene como información básica: • Nombre: Nombre asignado al proceso. • Unidad de tiempo: Pueden ser días, meses, años, etc. • Ciclo de vida: Tiempo de operación del sistema. • Costo de lucro cesante: Valor que se pierde cuando un sistema pirde capacidad de operación. • Número de simulaciones: Cantidad de repeticiones para proceso de Monte Carlo. • Unidad de moneda: Pueden ser dólares, euros, pesos, etc. • Intervalo de confianza: Rango estimado de valores, en el cual , con una muy alta probabilidad, se estima que estará cierto valor desconocido. • Sistemas Sistema: Un sistema se establece como un conjunto de equipos interconectados entre sí. Un sistema tiene como información básica: • Nombre: Nombre asignado al sistema. • Tipo: Puede ser almacenamiento, transporte, suministro, entre otros. • Relación final: En caso de conectarse con otros sistemas, especifica a qué otros sistemas se conecta el sistema actual. • Conectores: Si la conexión a otro sistema es discreta, el tipo de conexión, nombre y porcentaje de paso. • Equipos • Grupos de Mantenimiento Equipo: Un equipo es un dispositivo necesario para el funcionamiento de un sistema. En este caso, a un equipo se le asigna como información básica: • Nombre: Nombre asignado al equipo • Relación: Tipo de conexión externa • Eventos. 31.
(48) 32. 7 Desarrollo y Resultados Evento: Un evento es un suceso ocurrido en un equipo por el cual detuvo su operación normal. Un evento puede ser tanto correctivo (falla) como preventivo (mantenimiento). En este caso, un evento se compone de: • Duración: Se define la duración del evento mediante una distribución de probabilidad definida por el usuario. Dicha función de probabilidad debe tener como mínimo 1 parámetro y se le debe definir el tipo de distribución (Normal, Constante, Weibull, etc) • Costo: Valor que cuesta llevar a cabo el evento • Desempeño: Define el nivel de capacidad que pierde el equipo cuando el evento ocurre (En este caso siempre es pérdida total de capacidad) • Tipo: Si el evento es falla o mantenimiento • Nombre: Nombre asignado al evento • Ocurrencia: Al igual que con la duración, la ocurrencia se define mediante una función probabilística definida por el usuario. • Mantenimiento o falla asociado: Todo mantenimiento debe tener una falla asociada (no tendría sentido hacer un mantenimiento si no hay falla la cual prevenir). Las fallas no necesariamente tienen mantenimientos asociados. Grupo de Mantenimiento: Definidos por el usuario, estos permiten agrupar varios mantenimientos a la hora de encontrar un periodo el cual disminuya los costos totales de mantenimiento, es decir, permite realizar varios mantenimientos en simultáneo. Se define: • Periodo mínimo: Valor de tiempo de búsqueda mínimo • Tasa de cambio: Valor de paso de barrido • Periodo máximo: Valor de tiempo de búsqueda máximo • Identificador: Nombre o etiqueta del grupo de mantenimiento • Mantenimientos asociados: Mantenimientos involucrados en el grupo de mantenimiento Relaciones: Puede ser limitante (conexión serie) o redundante (conexión paralelo). Se define además los equipos involucrados a cada relación.
(49) 7.2 Etapa 2: Desarrollo del Algoritmo Reestructuración de LECJSON: Como es de esperarse, al realizar la adición de equipos en conexión paralela, el módulo LECJSON (el cual cambia su nombre a Interpretador) debe actualizarse para permitir el manejo de esa nueva información. De esta forma, se obtiene un nuevo diagrama de entradas/salidas para este nuevo módulo, el cual se puede observar en la Figura 7-4.. Figura 7-4: Diagrama de entradas/salidas del módulo Interpretador Para este nuevo caso, considerando la nueva información que se extrae, tendremos la siguiente información detallada de estas variables: EventListConfig: Contiene información de ocurrencias y duraciones de los eventos, añadiendo tipo de evento, relación mantenimiento-falla y se añade identificador de evento, relación de equipo y pérdida de capacidad asociada al equipo. ConfigGroupMant: Contiene información de los grupos de mantenimiento asignados por el usuario. NumberEvents, NumberEquip, CostNoFlow, Iterations, LifeCycleTime, ConfidenceInterval: Información general del sistema asignado a cada variable correspondiente. MatSupEq: Contiene información de lo que se llamó “súper equipo”, el cual equivale a una red de equipos conectados en paralelo entre sí (ver Figura. 33.
(50) 34. 7 Desarrollo y Resultados 7-5), es decir, detalla los equipos que están relacionados a cada uno de los “súper equipos".. Figura 7-5: Conceptualización de “súper equipo”. Diseño del nuevo módulo SED: Para comenzar con el diseño, es muy importante conocer tanto lo que se tiene como lo que se requiere, y ya se conoce lo que se tiene. Para conocer lo que se requiere, tenemos la siguiente lista de necesidades y condiciones que se deberán cubrir en el nuevo diseño: Necesidades • Ya se hace el registro y procesamiento de eventos asociados a equipos serie. Ahora se requiere la posibilidad de añadir equipos en paralelo. • Anteriormente se tenía una curva de capacidades o bien máxima o mínima, 100 % o 0 %. Con la incorporación de equipos en paralelo, será posible tener tantas diferentes capacidades como equipos en paralelo existan. Condiciones • El proceso industrial, así como se desarrolló en la fase 3, contendrá un sólo sistema • Se trabajará en tiempo contínuo, y con esto, a pesar de ser altamente improbable, se deberá tener la posibilidad de que 2 eventos ocurran al mismo tiempo..
(51) 7.2 Etapa 2: Desarrollo del Algoritmo Analizando las necesidades, y tomando como ejemplo el esquema de la Figura 7-5, si el equipo 1 presenta un evento, el sistema estará fuera de operación (un evento, ya sea falla o mantenimiento, siempre ocasionará que el equipo al cual pertenece el evento salga de operación). En cambio, si se presenta un evento del equipo 2, el cual aporta un 50 % de capacidad en el “súper equipo”, entonces se tendrá una capacidad del sistema del 50 %. Ahora bien, si ocurre un evento del equipo 2 y 3 en un mismo intervalo de tiempo, el sistema dejará de funcionar, ya que ambos equipos del “súper equipo” están fuera de operación. Esta es la consideración más importante a tener en cuenta, ya que hay que tener en cuenta una posible intersección temporal de eventos en el encolamiento, algo que en la fase 3 no era posible que sucediera. Entonces, se estudian los diferentes casos que pueden ocurrir a la hora de encolar eventos por medio de varias pruebas de escritorio y con esto se evalúan las posibilidades en el diseño del nuevo módulo SED. Con base en lo entendido anteriormente, se rediseña el módulo SED, tomando como base el diseño del antiguo SED. El diseño que se tiene actualmente del módulo SED tiene varios inconvenientes, entre los más importantes está el hecho de que no es segmentable, lo que significa que se sigue un proceso general, pero no un subproceso, por lo que la programación es engorrosa. Entonces, se decide reestructurar el diseño, de tal forma que se tenga un proceso global y un conjunto de subprocesos. Dicho esto, se definen los subprocesos principales que conformarán el proceso global: Un subproceso encargado de la obtención de los datos recibidos del interpretador. Un subproceso encargado de organizar y extraer los eventos que van ocurriendo para encolarlos. Un subproceso encargado de operar y almacenar la información de los eventos encolados de los equipos en serie (más relevante). Un subproceso encargado de operar y almacenar la información de los eventos encolados de los equipos en paralelo (en caso de que no hayan eventos asociados a equipos de conexión serie). Un subproceso encargado de realizar el análisis RAM (cálculo de costos y capacidad) con base en los eventos evaluados durante el tiempo de operación del sistema.. 35.
(52) 36. 7 Desarrollo y Resultados De esta forma, se evalúan los eventos por orden de prioridad, ya que los eventos asociados a equipos serie, cuando ocurren, sacan de funcionamiento al sistema, y no será posible que ocurran otros eventos debido a que el sistema está apagado. Por lo anterior se encolan primero los eventos asociados a equipos serie. En cambio, los eventos asociados a equipos paralelo dependen de los otros equipos paralelos pertenecientes al mismo súper equipo para dejar fuera de operación al sistema. Por ende, en caso de que ocurra un evento asociado a un equipo en paralelo, es posible que ocurran varios eventos en el mismo intervalo de tiempo sin que el sistema pierda por completo su capacidad. Dicho en pocas palabras, registrar primero los eventos asociados a equipos serie nos ahorrará tiempo en la evaluación de casos.. Figura 7-6: Algoritmo SED general.
(53) 7.2 Etapa 2: Desarrollo del Algoritmo Por otra parte, gracias al fraccionamiento del problema en subprocesos, se obtiene un código más segmentable y escalable con respecto a lo que se tenía anteriormente, y con esto se espera que sea un código más entendible y manejable para posteriores trabajos. Cabe aclarar que el cálculo de capacidades corresponde al trabajo realizado en otro proyecto, por lo que en este documento sólo se entrará en detalles con el cálculo de costos. Dicho todo esto, se procede a rediseñar el módulo SED. El diagrama de flujo que representa el módulo SED basados en los subprocesos mencionados anteriormente se presenta en la Figura 7-6. Operaciones: En el algoritmo se realizan diferentes operaciones que sirven tanto para el registro de los eventos como para el desplazamiento en la línea de tiempo. Las operaciones se especifican en la Tabla 7-1 Tabla 7-1: Lista de Operaciones utilizadas en el algoritmo Operación Operación 1. Operación 2. Operación 3. Operación 4. Operación 5. Operación 6 Operación 7 Operación 8. Descripción Pérdida de capacidad = Pérdida de capacidad del equipo asociado Tiempo Inicial = Tiempo de Reloj + Ocurrencia del evento Tiempo Final = Tiempo Inicial + Duración del evento Tiempo de Reloj = Tiempo Final Pérdida de capacidad = Pérdida de capacidad Total - Pérdida de capacidad del equipo asociado Tiempo Inicial = Tiempo inicial del índice anterior Tiempo Final = Tiempo Inicial + Duración del evento Tiempo de Reloj = No cambia Pérdida de capacidad = Pérdida de capacidad del equipo asociado Tiempo Inicial = Tiempo inicial del índice anterior Tiempo Final = Tiempo Inicial + Duración Almacenada Tiempo de Reloj = No cambia Ocurrencia = 0 Duración = Duración actual - Duración Almacenada Pérdida de capacidad = Pérdida de capacidad del equipo asociado Tiempo Inicial = Tiempo de Reloj + Ocurrencia del evento Tiempo Final = Tiempo Inicial + Duración del vento Tiempo de Reloj = Tiempo Inicial Si todos los índices del súper equipo han sido añadidos en la MCSE y El menor de los Tiempos Finales >El mayor de los Tiempos Iniciales de los eventos asociados a los índices en la MCSE Tiempo de Reloj = Tiempo inicial mayor (de los eventos intersectados en la MEP) + Duración Almacenada Duración de solapamiento = El menor de los Tiempos Iniciales - El mayor de los Tiempos Iniciales (de los eventos “solapados” en la MEP). 37.
(54) 38. 7 Desarrollo y Resultados Invocación al Interpretador: Es el subproceso más trivial. La invocación al interpretador se encarga de instanciar o inicializar las variables que llegan del módulo Interpretador. Además, instanciará cada una de las variables que se utilizarán a lo largo del algoritmo. Las variables mencionadas se especifican en la Tabla 7-2. Encolamiento y reinstanciación de eventos: Mientras el ciclo de vida no haya terminado, es decir, el tiempo de reloj de operación no sea mayor al ciclo de vida determinado por el usuario, se ejecutará el subproceso de encolamiento y reinstanciación de eventos. El subproceso se muestra en la Figura 7-7.. Figura 7-7: Diagrama de flujo del subproceso de Encolamiento y reinstanciación de eventos El encolamiento de eventos, según el paradigma de simulación de eventos discretos, consiste en secuenciar los eventos en orden de ocurrencias, de menor a mayor ocurrencia. En este caso, una vez se instancien inicialmente la ocurrencia y duración de los eventos según sus distribuciones de probabilidad, se extraen el(los) evento(s) más próximos a ocurrir y se procede a registrarlos. Adicionalmente, los eventos registrados deberán reinstanciarse para la siguiente iteración del proceso hasta que se cumpla con el ciclo de vida. Finalmente, los eventos encolados se guardan en la Lista de Eventos Actuales (LEA) y con base en esta variable se continúa el proceso en el diagrama de SED..
Figure
Documento similar
La campaña ha consistido en la revisión del etiquetado e instrucciones de uso de todos los ter- mómetros digitales comunicados, así como de la documentación técnica adicional de
If certification of devices under the MDR has not been finalised before expiry of the Directive’s certificate, and where the device does not present an unacceptable risk to health
In addition to the requirements set out in Chapter VII MDR, also other MDR requirements should apply to ‘legacy devices’, provided that those requirements
The notified body that issued the AIMDD or MDD certificate may confirm in writing (after having reviewed manufacturer’s description of the (proposed) change) that the
Debido al riesgo de producir malformaciones congénitas graves, en la Unión Europea se han establecido una serie de requisitos para su prescripción y dispensación con un Plan
Como medida de precaución, puesto que talidomida se encuentra en el semen, todos los pacientes varones deben usar preservativos durante el tratamiento, durante la interrupción
que hasta que llegue el tiempo en que su regia planta ; | pise el hispano suelo... que hasta que el
E Clamades andaua sienpre sobre el caua- 11o de madera, y en poco tienpo fue tan lexos, que el no sabia en donde estaña; pero el tomo muy gran esfuergo en si, y pensó yendo assi