Mantenimiento Predictivo usando Sistemas MultiAgentesoa.upm.es/54407/1/TFM_JAVIER_EDUARDO_CARRILLO_PLAZA.pdf · Mantenimiento Predictivo usando Sistemas MultiAgentes Javier Eduardo

Mantenimiento Predictivo usandoSistemas MultiAgentes

Javier Eduardo Carrillo Plaza

Escuela Técnica Superior de Ingenieros Informáticos

Universidad Politécnica de Madrid

Este trabajo es entregado para el grado de

Master en Ingeniería Informática

Julio 2016

Abstract

El presente documento contiene el Trabajo de Fin de Master (TFM) sobre Mantenimien-

to Predictivo usando la técnica de Sistemas Multiagentes.

Para realizar el TFM, se ha contado con la autorización y participación de personal

de la empresa CLH, permitiendo analizar la información de los cargaderos con el

objetivo de predecir averías en la válvula principal evitando derrames, lo cual ahorra

sobrecostes operacionales debido a que evita detener la carga de producto en los

cargaderos; adicionalmente también evita la limpieza exhaustiva que se debe realizar

cuando hay derrames en los cargaderos.

El sistema está diseñado para que tenga características de sistemas distribuibles y com-

ponentes de Inteligencia Artíficial (IA), es fácilmente extendible y con gran capacidad

de integración con otros sistemas.

El sistema recibe información de distintos elementos del entorno que capturan eventos

físicos de los activos de la compañía y tiene capacidad de conexión con el sistema de

mantenimiento. Específicamente, para el caso de los cargaderos, se procesa los eventos

generados en la válvula principal y analiza los datos utilizando Redes Neuronales

Artíficiales.

El proyecto fue gestionado como un proyecto de software tradicional, es por ello que

este documento también contiene análisis de riesgos, requerimientos funcionales y

técnicos del sistema y ejecución de pruebas.

Abstract

This document contents Master Thesis work (TFM by your Spanish acronym) about

Predective Maintenance using Multi Agent System technique.

The TFM has been authorized and attended of employees of CLH, allowing to analyze

landings information with the objective to predict faults, avoiding spillovers in landings

and save up operational overcosts because it avoid stop product loading in landings;

aditionally, avoid exhaustive environment cleaning when overruns occurs.

The system is designed with distributed characteristics and Artificial Intelligence com-

ponents, is easily expandable and have great integration capacity with other systems.

The system receives information of any environment elements that catch physic events

of assets company; on the other hand, the system have connectivity capacity with EAM

(Enterprise Asset Management) system to notify possible faults. Specifically, to the

case of landings, the systems analyzes and processes the events of main valve using

Artificial Neural Networks.

This project was managed as a traditional software project, that is the reason why

this document contents risk analysis, functional and technical requirements and test

executions.

III

Tabla de Contenido

Lista de Figuras VII

Lista de Tablas IX

Nomenclatura XI

1. Introducción y Objetivos 11.1. Siniestros al suministrar producto a los camiones cisterna . . . . . . . 1

1.1.1. Problemas conocidos en los brazos de carga de los cargaderos 2

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1. Objetivos Empresariales . . . . . . . . . . . . . . . . . . . . 3

1.2.2. Objetivos Técnicos . . . . . . . . . . . . . . . . . . . . . . . 4

2. Estado del arte 52.1. Sistemas multiagentes (MAS) . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Agente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2. Agente inteligente . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3. Ambiente o entorno . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.4. Estudio de Sistemas Multiagente . . . . . . . . . . . . . . . . 7

2.1.5. FIPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.6. JADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.7. Modelo BDI . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Mantener, Reparar y Revisar (MRO) . . . . . . . . . . . . . . . . . . 9

2.2.1. Tipos de Mantenimiento . . . . . . . . . . . . . . . . . . . . 10

2.3. Redes Neuronales Artificiales (ANNs) . . . . . . . . . . . . . . . . . 11

2.3.1. Función de la red . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.2. Aprendizaje . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.3. Paradigmas de Aprendizaje . . . . . . . . . . . . . . . . . . . 12

Tabla de Contenido

3. Evaluación de riesgos 133.1. Categorización de riesgos . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2. Identificación de riesgos . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3. Probabilidad e impacto de los riesgos . . . . . . . . . . . . . . . . . 14

3.4. Estratégias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4. Desarrollo 194.1. Análisis de información de los activos . . . . . . . . . . . . . . . . . 19

4.2. Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . 21

4.2.2. Requisitos técnicos . . . . . . . . . . . . . . . . . . . . . . . 22

4.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.1. Explicación general de la arquitectura . . . . . . . . . . . . . 22

4.3.2. Arquitectura general del sistema en entorno Cloud . . . . . . 23

4.3.3. Arquitectura general del sistema en entorno local . . . . . . . 24

4.3.4. Tipos de Agentes . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3.5. Tipos de Mensajes . . . . . . . . . . . . . . . . . . . . . . . 25

4.3.6. Mensajes entre agentes . . . . . . . . . . . . . . . . . . . . . 25

4.3.7. Diseño de la red neuronal . . . . . . . . . . . . . . . . . . . 26

4.3.8. Diseño de interface gráfica de usuario . . . . . . . . . . . . . 28

4.4. Plan de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4.1. Pruebas de agentes de entrada y salida de datos . . . . . . . . 31

4.4.2. Pruebas de agentes cognitivos . . . . . . . . . . . . . . . . . 37

4.4.3. Pruebas de visualización de datos . . . . . . . . . . . . . . . 38

5. Resultados 415.0.1. Resultados de Negocio . . . . . . . . . . . . . . . . . . . . . 41

5.0.2. Resultados Sistema Multiagente . . . . . . . . . . . . . . . . 42

5.0.3. Resultados Red Neuronal . . . . . . . . . . . . . . . . . . . . 42

6. Conclusiones 556.1. Conclusiones Empresariales . . . . . . . . . . . . . . . . . . . . . . 55

6.2. Conclusiones Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . 56

7. Líneas futuras 57

Bibliografía 59

VI

Lista de Figuras

1.1. Cargadero de camiones cisterna [1] . . . . . . . . . . . . . . . . . . 2

1.2. Válvula Smith Meter Modelo 210 [3] . . . . . . . . . . . . . . . . . 2

1.3. Membrana de válvula Smith Meter Modelo 210 . . . . . . . . . . . . 3

2.1. Proceso de BDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1. Estructura RBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1. Diseño general MAS entorno Cloud . . . . . . . . . . . . . . . . . . 23

4.2. Diseño general MAS entorno local . . . . . . . . . . . . . . . . . . . 24

4.3. Diseño general MAS - Parte 1 . . . . . . . . . . . . . . . . . . . . . 26

4.4. Diseño general MAS - Parte 2 . . . . . . . . . . . . . . . . . . . . . 26

4.5. Pantalla inicial del GUI Web . . . . . . . . . . . . . . . . . . . . . . 28

4.6. Tabla de agentes conectados . . . . . . . . . . . . . . . . . . . . . . 29

4.7. Tabla de resumen de datos . . . . . . . . . . . . . . . . . . . . . . . 29

4.8. Tabla de estadística de eventos por brazo de carga . . . . . . . . . . . 29

4.9. Gráfica del brazo de carga TORACCU072 . . . . . . . . . . . . . . . 30

5.1. Resultados Back Propagation TORACCU072 . . . . . . . . . . . . . 44

5.2. Gráficas de Resultados Back Propagation TORACCU072 . . . . . . . 45



5.5. Gráficas EAMP TORACCU072 . . . . . . . . . . . . . . . . . . . . 48

5.6. Gráficas R TORACCU072 . . . . . . . . . . . . . . . . . . . . . . . 49




5.10. Gráficas de Resultados Resilient Propagation TORACCU052 . . . . . 52

5.11. Gráficas EAMP TORACCU052 . . . . . . . . . . . . . . . . . . . . 53

VII

Lista de Figuras

5.12. Gráficas R TORACCU052 . . . . . . . . . . . . . . . . . . . . . . . 54

VIII

Lista de Tablas

3.1. Tabla de Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2. Tabla de probabilidad de riesgos . . . . . . . . . . . . . . . . . . . . 15

3.3. Tabla de impacto si ocurre el riesgo . . . . . . . . . . . . . . . . . . 15

3.4. Tabla de cualificación de riesgos . . . . . . . . . . . . . . . . . . . . 15

3.5. Tabla de Probabilidad e impacto de los riesgos . . . . . . . . . . . . . 16

3.6. Tabla de tipificación de estratégias . . . . . . . . . . . . . . . . . . . 16

3.7. Tabla de estratégias . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2. Requisitos técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

IX

Nomenclatura

Abreviaturas

ACL Agent Content Language

AID Agent Identifier

AMS Agent Management System

ANNs Artificial Neural Networks

BDI Beliefs, desires and intentions

CLH Compañía Logística de Hidrocarburos

DCOPs Distributed constraint optimization

DF Directory Facilitator

EAMP Error Absoluto Medio Porcentual

FIPA Foundation for Intelligent Physical Agents

IT Informational Technology

JADE Java Agent DEvelopment Framework

MAS Multiagent Systems

MDP Markov Decision Process

MRO Maintenance, Repair, and Overhaul

OT Operational Technology

OT Orden de trabajo

XI

Nomenclatura

RBS Risk BreakDown Structure

T FM Trabajo Fin de Master

XII

Capítulo 1

Introducción y Objetivos

En el sector del mantenimiento industrial, tradicionalmente, se ha realizado man-

tenimiento correctivo y mantenimiento preventivo a los activos. El mantenimiento

correctivo genera altos costes para las organizaciones debido a que pueden ocasionar

grandes pérdidas si se detiene la producción; para disminuir el mantenimiento correctivo

se realiza mantenimiento preventivo, el cual se puede basar en periodos de tiempo (fre-

cuencias anuales, semestrales, mensuales, etc) o se puede basar en mediciones (tiempos

de funcionamiento, kilometraje, etc).

Realizar mantenimiento preventivo puede generar nuevo mantenimiento correctivo

o sobre costes si no se planifica correctamente su ejecución. Como alternativa, se puede

realizar mantenimiento predictivo, el cual está basado en el análisis de información

física de los activos (vibraciones, presiones, etc) con el objetivo de predecir averías

evitando el mantenimiento correctivo y disminuyendo el mantenimiento preventivo.

Debido a la gran y diversa información física que generan los activos, su análisis

en tiempo real para la predicción de averías es fundamental para el ahorro de costes en

mantenimiento al evitar mantenimiento correctivos y disminuir el balance de repuestos

en el inventario.

1.1. Siniestros al suministrar producto a los camionescisterna

En CLH, el suministro de producto a los camiones cisterna está automatizado,

al llegar el camión se realiza el control de la entrada a la instalación indicando el

pedido que van cargar; posteriormente se dirigen a un área de la instalación llamada

“Cargadero“, la cual está dividida en “Isletas“ en donde se realiza el suminitro de los

1


productos del pedido a través de los brazos de carga. En todo el proceso anterior,

únicamente hay intervención por parte del personal de CLH al acoplar el brazo de carga

al camión cisterna [2].

Figura 1.1 Cargadero de camiones cisterna

[1]

El suministro del producto se detiene

cuando se alcanza el número de litros que

corresponde al pedido, cuando se alcanza

el límite de almacenamiento de camión

cisterna o cuando se recibe la señal de

alarma indicando derramamiento de pro-

ducto.

El derramamiento de producto tiene

un alto coste operativo y ambiental, debi-

do a que se debe limpiar perfectamente la

zona afectada (parando el suministro en

esa isleta) y se debe sacar manualmente

el exceso de producto del camión cister-

na para cumplir la reglamentación que no

permiten circular camiones al 100% de

su capacidad.

1.1.1. Problemas conocidos enlos brazos de carga de los carga-deros

Figura 1.2 Válvula Smith Meter Modelo

210 [3]

La mayoría de los problemas de de-

rrame de producto se deben a problemas

presentados por la válvula Smith Meter

(Modelo 210), la cual está compuesta por

una válvula principal de membrana y dos

electro-válvulas pequeñas (una normal-

mente abierta y la otra normalmente ce-

rrada).

En forma resumida, la válvula princi-

pal tiene una membrana interna que per-

mite que el producto fluya o no a través

de la ella; dicha membrana está alrededor de un muelle que le permite estar por defecto

2

1.2 Objetivos

cerrada, se mueve por la diferencia de presiones que ejercen las dos electro-válvulas

pequeñas, cuando se abre una válvula la otra se cierra lo cual hace que fluya producto y

“empuje“ en un sentido u otro a la membrana, lo cual tiene el efecto de cerrar o abrir la

válvula principal.

Figura 1.3 Membrana de válvula

Smith Meter Modelo 210

Específicamente se han detectado los siguien-

tes problemas:

Problemas de desgaste o rotura de la mem-

brana de la válvula principal. Es un pro-

blema que no se puede detectar a simple

vista, actualmente analizan los tiempos de

apertura y cierre para determinar aproxima-

damente si la membrana está o no en buenas

condiciones. Este análisis se realiza no se

realiza frecuentemente porque requiere un

gran esfuerzo del personal de CLH para el

análisis manual de los datos.

Problemas en las electro-válvulas, cuando

falla alguna de las electro-válvulas puede que la válvula principal quede perma-

nentemente cerrada o puede que quede permanentenmente abierta, en ese caso se

debe proceder a un cierre manual de la válvula. Actualmente no se está realizando

análisis para predecir averías en las electro-válvulas porque no se está capturando

información de dichas válvulas.

1.2. Objetivos

El objetivo es utilizar la técnica de sistemas de multiagente para el mantenimiento

predictivo de activos.

Para alcanzar el anterior objetivo se deberán cumplir los siguientes objetivos especí-

ficos tanto empresariales como técnicos.

1.2.1. Objetivos Empresariales

Obtener y clasificar la información obtenida de sistemas que capturan eventos en

tiempo real de los activos en las instalaciones

3


Obtener y clasificar la información obtenida del sistema de gestión de manteni-

miento de activos

1.2.2. Objetivos Técnicos

Diseñar un sistema multiagente que permita procesar la información de los activos

para la predicción de averías

Comparar los resultados de predicción del sistema multiagente con la información

de averías obtenidas del sistema de gestión de mantenimiento

4

Capítulo 2

Estado del arte

Este capítulo introduce algunos conceptos básicos que se usan en el documento.

2.1. Sistemas multiagentes (MAS)

El estudio de sistemas multiagentes consiste en el desarrollo y análisis de resolución

de problemas sofisticados de inteligencia artíficial utilizando arquitecturas de sistemas

de un solo agente y multiagente.

2.1.1. Agente

En software, el concepto de Agente es la forma de describir una entidad de software

capaz de actuar con cierto grado de autonomía para completar tareas complejas[4]. Los

agentes tienen las siguientes características:

No son estrictamente invocados por una tarea pero pueden ser invocados por ellos

mismos

Pueden estar en espera mientras perciben el contexto

Pueden continuar su ejecución si las condiciones del contexto son las adecuadas

No necesitan interacción con el usuario

Pueden invocar otras tareas

5

Estado del arte

Diferencias del concepto de agentes con respecto a otros conceptos:

Un agente no es un simple programa: un agente reacciona al entorno, es autónomo,

es persistente y orientado a objetivos.

Un agente no es un objeto: los agentes son más autónomos que los objetos, los

agentes tienen comportamiento flexible (reactivo, proactivo, social), los agentes

tienen al menos un hilo de control pero pueden tener más de uno.

Un agente no es un sistema experto: Los sistemas expertos no están acoplados al

entorno, no están diseñados para tener comportamiento reactivo o proactivo y no

se considera que tengan comportamiento social

2.1.2. Agente inteligente

Un agente inteligente extiende la definición anterior de agente agregando las si-

guientes características:

Se adapta a nuevas reglas para resolver problemas

Es adaptable en tiempo real u online

Aprende y mejora con la interacción del entorno

Aprende rápidamente de grandes cantidades de datos

Es proactivo para alcanzar el objetivo

Puede tener habilidades sociales al interactuar con otros agentes

2.1.3. Ambiente o entorno

El entorno es el medio en el que se encuentra el agente, puede ser virtuales, discretos

o físicos.En el entorno generalmente se encuentra mas de un agente.

Los entornos de agentes pueden ser organizados de acuerdo a sus características:

Accesibilidad: Depende si es posible o no acceder a la información completa del

entorno.

Determinismo: Sucede cuando una acción causa un efecto definido en el entorno.

Dinamismo: El entorno influencia a las entidades en cada momento.

6

2.1 Sistemas multiagentes (MAS)

Discretitud: El número posible de acciones en el entorno es finito.

Dimencionalidad: El agente toma las decisiones de acuerdo a las características

espaciales del entorno

2.1.4. Estudio de Sistemas Multiagente

El estudio de sistemas multiagentes se enfoca en:

Ingeniería de software orientado a agentes

Creencias, deseos e intensiones (BDI)

Cooperación y coordinación

Optimización de restricciones distribuidas (DCOPs)

Organización

Comunicación

Negociación

Aprendizaje multiagente

Robótica

Sistemas multirobot

2.1.5. FIPA

FIPA (Foundation for Intelligent Physical Agents) es una fundación que promueve

la tecnología basada en agentes y la interoperabilidad de sus estándares con otras

tecnologías. Actulamente FIPA hace parte de la IEEE.

FIPA propone un modelo de referencia de Sistemas Multiagentes que contiene los

siguientes componentes lógicos:

Agente: Como se ha comentado anteriormente, es un proceso computacional que

implementa la funcionalidad autónoma de la aplicación; se comunica usando el

lenguage ACL (Agent Content Language). Un agente puede tener capacidades

de servicios, los cuales son publicadas en las descripciones de servicios. Cada

agente tiene un identificador único (AID, Agent Identifier)

7

Estado del arte

Directory Facilitator (DF): Provee el servicio de páginas amarillas a los agentes.

En el DF los agentes podrán registrar sus servicios y consultar los servicios de

los otros agentes.

Agent Management System (AMS): Mantiene un directorio de AIDs para los

agentes registrados en el sistema.

Message Transport System (MTS): Método de comunicación por defecto entre

agentes en diferentes plataformas.

Plataforma: Es la infraestructura en donde es desplegado el sistema; consiste en

máquina, sistema operativo, software de soporte para agentes, componentes de

gestión de FIPA(DF, AMS y MTS) y agentes.

2.1.6. JADE

Java Agent DEvelopment Framework (JADE) es un framework de desarrollo de

agentes inteligentes implementado en java. JADE soporta la coordinación entre agentes

FIPA e implementa el estándar de lenguaje de comunicaciónn FIPA-ACL.

Los agentes pueden estar en alguno de los siguientes estados:

Iniciado (Initiated): El agente ha sido creado pero aún no está registrado en el

AMS.

Activo (Active): El agente ha sido registrado y tiene nombre. En este estado el

agente puede comunicarse con otros agentes.

Suspendido (Suspended): El hilo del agente está suspendido.

Esperando (Waiting): El agente está bloqueado esperando un evento.

Eliminado (Deleted): El agente y su hilo ha finalizado su ejecución, no está

registrado en el AMS.

En transito (Transit): El agente se está moviendo a una nueva ubicación.

2.1.7. Modelo BDI

El modelo BDI (Beliefs, desires and intentions) es un modelo de desarrollo para

programar agentes inteligentes caracterizado por la implementación de creencias, deseos

e intensiones de agentes de software.

8

2.2 Mantener, Reparar y Revisar (MRO)

BDI provee los mecanismos para separar la actividad de seleccionar un plan y la

ejecución del plan actual, balanceando el tiempo que invierte el agente en dichas tareas.

El modelo deja por fuera el diseño de los planes delegando dicha tarea a los diseña-

dores y desarrolladores del sistema.

Creencias (Beliefs):Representa el estado de la información del agente, en otras

palabras la creencia acerca del mundo (entorno) de si mismo y otros agentes. Se

usa la palabra creencia en vez de conocimiento porque no necesariamente son

verdad.

Deseos (Desires): Representan la motivación del agente; son los objetivos o

situaciones que el agente le gustaría alcanzar.

Intenciones (Intentions): Representa lo que el agente ha decidido hacer, en la

implementación del sistema significa que la ejecución de un plan ha comenzado.

BDI ejecuta continuamente el siguiente proceso:

Figura 2.1 Proceso de BDI

2.2. Mantener, Reparar y Revisar (MRO)

MRO implica arreglar cualquier fallo o rotura de dispositivos eléctricos, mecánicos o

tuberías; lo anterior incluye acciones rutinarias para mantener el dispositivo funcionando

(mantenimiento preventivo). MRO puede ser definido como “Todas las acciones que

tienen como objetivo mantener o restaurar un artículo en un estado en el cual pueda

desempeñar la función requerida“.

9

Estado del arte

2.2.1. Tipos de Mantenimiento

En forma general se puede realizar la clasificación del mantenimiento en los siguien-

tes tipos:

1. Mantenimiento de conservación: Es todo mantenimiento que se realiza con el

fin de mantener operativo el equipo el mayor tiempo posible.

a) Mantenimiento correctivo: Es toda tarea realizada para identificar, aislar y

rectificar un fallo de un equipo, máquina o sistema para que pueda volver a

un estado operativo dentro de las tolerancias o límites establecidos para su

operación.

1) Mantenimiento inmediato: Es el mantenimiento realizado inmediata-

mente posterior a la detección de un fallo que deja inoperativo a un

equipo.

2) Mantenimiento diferido: Es el mantenimiento realizado al detectar un

fallo en un equipo pero que no lo deja inoperativo.

b) Mantenimiento preventivo: El objetivo del mantenimiento preventivo es

mitigar las consecuencias de los fallos de un equipo, por lo tanto, son todos

los cuidados realizados por el personal para mantener equipos e instalacio-

nes en condiciones operativas realizando sistemáticamente operaciones de

inspección, detección y corrección de fallos incipientes antes de que ocurra

la avería y genere mayores consecuencias.

1) Mantenimiento programado: Es el mantenimiento que se realiza tenien-

do como base un periodo de tiempo, distancia recorrida, tiempo de

funcionamiento, entre otros.

2) Mantenimiento predictivo: Es el mantenimiento realizado al predecir

averías analizando tendencias de fenómenos físicos de los equipos

como vibraciones, temperaturas, etc.

3) Mantenimiento de oportunidad: Es el mantenimiento realizado en pe-

riodos de tiempo en el que los equipos no están en funcionamiento.

2. Mantenimiento de actualización: Es el mantenimiento realizado para actualizar

tecnológicamente un equipo o adaptarlo para que funcione en otros entornos.

10

2.3 Redes Neuronales Artificiales (ANNs)

2.3. Redes Neuronales Artificiales (ANNs)

Las redes neuronales artificiales [Santana] son las familias de modelos inspirados por

las redes neuronales biológicas y utilizando funciones de aproximación que dependen

de un gran número de entradas que generalmente son desconocidas.

Las redes neuronales artificiales son generalmente presentadas como sistemas de

interconexión de “neuronas“ que intercambian mensajes entre ellas. Las conexiones

tienen pesos numéricos que pueden ser ajustados de acuerdo a la experiencia haciendo

que la red sea adaptativa a las entradas y con capacidad de aprendizaje.

Las interconexiones se realizan entre capas de neuronas que pueden activar o no

las capas interiores hasta que se activen las neuronas de salida. Dichas interconexiones

tienen pesos que representan la importancia de dicha entrada para la neurona de destino.

2.3.1. Función de la red

Las redes neuronales artificiales son esencialmente un simple modelo matemático

definido como función:

f : X → Y (2.1)

Las ANNs generalmente están definidas como:

El patrón de interconexión de las distintas capas de neuronas.

El proceso de aprendizaje para actualizar los pesos de las interconexiones.

La función de activación que convierte las entradas con pesos de la neurona a su

salida de activación.

De acuerdo a la anterior, una neurona es representado por la función f (x) definida

como la composición de otras funciones gi(x). Por lo tanto, teniendo en cuenta los pesos

de las interconexiones la función de la neurona puede ser representada como:

f (x) = K(Σiwigi(x)) (2.2)

Donde w es el peso de las interconexiones y K es la función de activación de la

neurona.

11

Estado del arte

2.3.2. Aprendizaje

Lo más atractivo de las redes neuronales es la capacidad de aprendizaje. Dadas

una tarea específica y una clase de funciones F , aprender significa usar un conjunto de

observaciones para encontrar f ∗ ∈ F que resuelva desde un punto de vista óptimo.

Por lo tanto la definición de función de coste: C : F → R tal que para la función

óptima f ∗, C( f ∗)�C( f )∀ f ∈ F .

Elegir la función de coste se puede realizar de distintas formas, depende del problema

que se desee solucionar

2.3.3. Paradigmas de Aprendizaje

Existen tres tipos de paradigmas de aprendizaje: el supervisado, no supervisado y el

reforzado.

Aprendizaje supervisado

En el aprendizaje supervisado, se toma un conjunto de parejas de ejemplo (x,y),x ∈X ,y ∈ Y que ayude a encontrar la función f : X → Y que concuerden dentro de las

clases de funciones de ejemplo. El coste de la función es la diferencia entre el resultado

obtenido y el esperado de acuerdo al conocimiento del dominio del problema.

Aprendizaje no supervisado

En aprendizaje no supervisado, se recibe un dato x y una función de coste a minimi-

zar. La función de coste es dependiente de la tarea y de nuestras suposiciones.

Aprendizaje reforzado

En aprendizaje reforzado, los datos x no son dados pero son generados por interac-

ciones de agentes dentro de un entorno. En cada momento de tiempo t el agente ejecuta

una acción Yt y el entorno genera una observación Xt y un coste instantáneo Ct .

Más formalmente el entorno es modelado como un Proceso de Decisión de Markov

(MDP) con estados s1, ...,sn ∈ S y acciones a1, ...,an ∈ A.

12

Capítulo 3

Evaluación de riesgos

3.1. Categorización de riesgos

Para categorizar los riesgos se toma como refencia la siguiente estructura “Risk

BreakDown Structure“ (RBS):

Figura 3.1 Estructura RBS

Debido a que el proyecto se enmarca dentro de un Trabajo Fin de Master (TFM) se

disminuyen la categorización de los riesgos dado que algunas de las subcategorías no

aplican, por ejemplo: subcontratistas y proveedores, mercado y financiamiento.

13


3.2. Identificación de riesgos

La siguiente tabla describe los riesgos identificados y las categorías a las que

pertencen:

Cuadro 3.1 Tabla de Riesgos

ID Riesgo Categoría DescripciónR001 Gestión Desvíos en la planificación por demoras al obte-

ner la información

R002 Técnico Información insuficiente para la detección de

averías

R003 Técnico Información desvinculada entre los sistemas de

captura de datos y el sistema de gestión de man-

tenimiento

R004 Técnico Las predicciones del modelo no corresponden

con la realidad

R005 Organizacional Baja prioridad en la búsqueda de información de

los derrames por parte del personal de CLH

3.3. Probabilidad e impacto de los riesgos

En cada riesgo se estima la probabilidad de que ocurra y el grado de impacto en

caso de que ocurra; con lo anterior se calcula la cualificación del riesgo de tal forma

que se pueda enfocar la mayor parte los esfuerzos a mitigar o eliminar el riesgo.

Para realizar lo anterior es necesario definir las tablas con las escalas de probabilidad,

impacto y cualificación de los riesgos:

14

3.3 Probabilidad e impacto de los riesgos

Cuadro 3.2 Tabla de probabilidad de riesgos

% Probabilidad PesoMuy baja 15%

Baja 50%

Alta 70%

Muy Alta 85%

Máxima 100%

Cuadro 3.3 Tabla de impacto si ocurre el riesgo

% Impacto PesoMuy bajo 15%

Bajo 50%

Alto 70%

Muy Alto 85%

Máximo 100%

Cuadro 3.4 Tabla de cualificación de riesgos

% Riesgo Nivel2% Muy bajo

25% Bajo

49% Alto

72% Muy Alto

100% Crítico

15


Cuadro 3.5 Tabla de Probabilidad e impacto de los riesgos

ID Riesgo Probabilidad Impacto % Riesgo RiesgoR001 Muy Alta Muy Alto 72% Muy Alto

R002 Alta Alto 49% Alto

R003 Alta Bajo 35% Bajo

R004 Baja Bajo 25% Bajo

R005 Alta Alto 49% Alto

De la anterior tabla se concluye que los riesgos R001 (Desvíos en la planificación por

demoras al obtener la información), R002 ( Información insuficiente para la detección

de averías) y R005 (Baja prioridad en la búsqueda de información de los derrames por

parte del personal de CLH) son los que debemos dedicar los esfuerzos para evitar que

sucedan o en caso de que sucedan disminuir su impacto.

3.4. Estratégias

Dependendiendo del riesgo se seguirán alguno de las siguientes tipos de estratégias:

Cuadro 3.6 Tabla de tipificación de estratégias

Tipo de estratégiaMitigar Riesgo

Asumir Riesgo

Transferir Riesgo a Tercero

Eliminar riesgo

16

3.4 Estratégias

Cuadro 3.7 Tabla de estratégias

ID Riesgo Tipo de estratégia Descripción EstratégiaR001 Mitigar Riesgo Obtener el apoyo de la alta dirección para la

consecución de la información del proyecto

R002 Mitigar Riesgo Identificar la mayor cantidad posible de fuentes

de información que permitan predecir averías

R003 Asumir Riesgo Debido a que el riesgo es muy bajo se decide

asumirlo

R004 Asumir Riesgo Debido a que el riesgo es muy bajo se decide

asumirlo

R005 Mitigar Riesgo Obtener el apoyo de la alta dirección para la

consecución de la información del proyecto

17

Capítulo 4

Desarrollo

4.1. Análisis de información de los activos

Debido a que el problema estudiado se centra en los cargaderos, especialmente

en las causas que generan la avería de las válvulas de membrana, la información se

descompone de la siguiente manera:

Información de mantenimiento: La información de mantenimiento tendrá los

mantenimientos, tanto preventivo como correctivo, realizados sobre cualquiera de

los equipos del cargadero. La información servirá para justificar el motivo por el

cual ha fallado. Específicamente se obtiene la siguiente información de la orden

de trabajo (OT):

• Número de OT: Número único de la orden de trabajo.

• Tipo de OT: Determina si la OT es de correctivo (MC) o de preventivo (MP).

• Descripción: Descripción de la OT

• Activo: Código del activo al que se le hace mantenimiento

• Ubicación: Ubicación del elemento

• Fecha de avería: Fecha en la cual ocurrió la avería en caso de que sea de

tipo MC.

• Fecha de notificación: Fecha en que se notificó la avería en caso de que sea

de tipo MC.

• Fecha de puesta en marcha: Fecha en que el activo volvió a estar en funcio-

namiento.

19

Desarrollo

• Fecha de estado completa: Fecha en que se completaron los trabajos de la

OT.

• Especialidad: Especialidad de la mano de obra principal. Ejemplo: Eléctrico,

mecánico, etc

• Ejecutor: Código del ejecutor que realizó el mantenimiento.

• Empresa externa: Código de la empresa que realizó el mantenimiento.

De cada orden de trabajo se obtiene los materiales usados para completar la OT:

• Material: Código del material usado.

• Descripción: Descripción del material usado.

• Cantidad: Cantidad de material usado.

• Fecha de recepción: Fecha en la que se recibió el material.

De cada orden de trabajo se obtiene la mano de obra requerida para completar la

OT:

• Mano de obra: Código de mano de obra que participó en la ejecución de la

OT.

• Especialidad: Código de la especialidad que participó en la ejecución de la

OT.

• Fecha de inicio: Fecha de inicio de la mano de obra.

• Fecha de fin: Fecha de fin de la mano de obra.

• Horas empleadas: Esfuerzo en horas empleadas por la especialidad

Información de eventos: La información de los eventos se obtienen tanto de la

válvula de principal o de membrana como de las eletrovalvulas.

• Información de la válvula principal:

◦ Equipo: Es la identificación de la válvula

◦ Fecha evento: Fecha en que se captura el evento

◦ Tipo de evento: Caudal, volumen, producto, temperatura, señal de tierra.

◦ Valor del evento: Es el valor que corresponde al tipo de evento en la

fecha del evento.

20

4.2 Análisis de requisitos

• Información de las electroválvulas:

◦ Equipo

◦ Fecha evento

◦ Código Evento

◦ Evento: Apertura, Cierre, Alarma

4.2. Análisis de requisitos

En esta sección se detalla los requerimientos tantos funcionales como técnicos que

deberá cumplir el sistema. La definición de estos requisitos servirán de entrada para la

preparación tanto de las pruebas unitarias como pruebas de finales del sistema.

4.2.1. Requisitos funcionales

Cuadro 4.1 Requisitos funcionales

ID Requisito DescripciónRF01 Permitir la carga de eventos del cargadero a través de ficheros

RF02 Permitir visualizar el resumen de la información de los datos cargados

por brazo de carga

RF03 Visualizar gráficamente la información de los brazos de carga (Caudal,

Volumen y toma de tierra) gráficamente

RF04 Clasificar los patrones de carga de producto considerados normal para

alertar cuando cambie el patrón de carga de producto

21

Desarrollo

4.2.2. Requisitos técnicos

Cuadro 4.2 Requisitos técnicos

ID Requisito DescripciónRT01 Crear agente que tenga la funcionalidad de cargar datos desde un fichero

CSV tanto para eventos como para la información de las OTs

RT02 Crear agente que tenga la funcionalidad de almacenar la información en

las bases de datos NoSql como Cloudant y CouchDB

RT03 Crear agente que identifique patrones en la información prediciendo

averías utilizando redes neuronales

RT04 Crear interface gráfica de usuario utilizando HTML5 para visualizar un

resumen con los datos cargados en el sistema

RT05 Crear interface gráfica de usuario permita visualizar gráficamente los

datos de Caudal, Volumen y Toma a Tierra usando HTML5

RT06 Los mensajes enviados a los agentes de escritura de base de datos se

deben distribuir uniformemente entre todos los agentes que tengan el

servicio de escritura de base de datos

4.3. Diseño

En ésta sección se detalla el diseño del sistema multiagente que se ha propuesto

para detectar averías en las válvulas de una isleta de carga de hidrocarburos.

El sistema incorpora dos variantes, dadas las tendencias actuales en computación,

uno utilizando recursos locales y otro utilizando recursos en cloud. Para el entorno local

se utiliza la base de datos CouchDB y Node.JS como entorno web; para el entorno

cloud se utiliza los servicios de IBM Bluemix, Cloudant NoSQL para la Base de datos

y Liberty Java App para el servidor web.

4.3.1. Explicación general de la arquitectura

En forma general, el sistema multiagente interactua con el entorno procesando la

información del mismo y tomando la decisión sobre cómo reaccionar ante los cambios

presentados en el entorno.

22

4.3 Diseño

En este caso, en el entorno están el sistema PI, el sistema Wincsr y el sistema Maxi-

mo. El sistema PI se encarga de capturar los eventos de los activos en las instalaciones

(caudal, temperatura, volumen, etc), el sistema Wincsr captura los eventos de apertura,

cierre y alarmas de errores en las electroválvulas, el sistema Maximo es el sistema de

gestión de mantenimiento en donde están registradas las características técnicas de los

activos y los matenimientos tanto preventivo como correctivo que se hace a cada activo.

El sistema multiagente tiene tres tipos de agentes, uno de entrada/salida, un agente

controlador de información, en este caso hay un solo agente controlador de la informa-

ción de la válvula; por último, hay un tipo de agente cognitivove

El diseño ofrece la posibilidad tanto de entrada como de salida a Maximo para

ofrecer la posibilidad de generar una alerta de mantenimiento en caso de que sea

detectada una avería.

Tal y como se puede observar en las siguientes arquitecturas, el sistema está to-

talmente preparado para sistemas distribuidos debido a que los agentes pueden estar

dispersos en distintos servidores y las bases de datos usadas (Cloudant y CouchDB)

están diseñadas para entornos distribuidos.

4.3.2. Arquitectura general del sistema en entorno Cloud

Figura 4.1 Diseño general MAS entorno Cloud

23

Desarrollo

En la figura 4.1, se utiliza la plataforma cloud de IBM para el almacenamiento de

la información, utilizando Cloudant NoSQL DB que permite almacenar y buscar gran

cantidad de información rápidamente; por otro lado se utiliza el servidor de aplicaciones

Liberty (basado en WebSphere Application Server) para desplegar la aplicación que

permite la visualización de la información del sistema multiagente.

4.3.3. Arquitectura general del sistema en entorno local

Figura 4.2 Diseño general MAS entorno local

En la figura 4.2, se muestra una alternativa local al entorno cloud presentado

anteriormente, debido a que la gran cantidad de información, que utiliza el sistema,

sobrepasa la cantidad de transacciones límite que ofrece Bluemix de forma gratuita. El

entorno local, utiliza la base de datos CouchDB y el entorno web Node.JS por su alta

capacidad transaccional y bajo uso de recursos de máquina.

24

4.3 Diseño

4.3.4. Tipos de Agentes

Agentes de Entrada y Salida

Los agentes de entrada y salida tendrán la responsabilidad de importar y exportar la

información que necesite el sistema.

Agentes de Gestión de Datos

Los agentes de gestión de datos conocerán los datos de cada tipo de válvula, si no

lo conoce, se encargará de conseguir la información a través de los agentes de entrada y

salida.

Agentes de Cognitivos

Los agentes cognitivos pedirán la información que consideren relevante a los agentes

gestores de datos para aprender, razonar y generar nuevo conocimiento con respecto a

los equipos, de tal forma que puedan predecir averías anticipadamente.

Para implementar el razonamiento se usa redes neuronales artificiales, cuyo diseño

se explica detalladamente más adelante.

4.3.5. Tipos de Mensajes

Evento: Representa todos los eventos generados por el sistema PI (cuadal, volu-

men, tomatierra y producto)

OT: Representa la información más importante de una orden de trabajo

MaterialOT: Representa la información de los materiales utilizados en las órdenes

de trabajo

ManoObraOT: Representa la información de personas que trabajan en las órdenes

de trabajo

Agente: Representa la información de los agentes del sistema multiagente

4.3.6. Mensajes entre agentes

Los siguientes diagramas de interacción muestran los mensajes que intercambian

los agentes en distintos momentos.

25

Desarrollo

Al iniciar el sistema, los agentes de la válvula principal y las electroválvulas solicitan

información a los agentes de entrada y salida de CSV y NoSQL.

Esa información posteriormente será usada por el o los agentes de red neuronal para

la predicción de averías.

Figura 4.3 Diseño general MAS - Parte 1

Figura 4.4 Diseño general MAS - Parte 2

4.3.7. Diseño de la red neuronal

Para la identificación de patrones de las aperturas y cierres de la válvula principal, se

analizará la información del caudal desde el punto de vista de series temporales, por lo

tanto, se usará las redes neuronales perceptron multicapa con los modos de aprendizaje

“Backpropagation“ y “Resilient Propagation“.

26

4.3 Diseño

Para diseñar el agente que contiene la implementación de la red neuronal se siguen la

siguiente metodología: Búsqueda de las variables de entrada, preparación del conjunto

de datos, creación de la red, entrenamiento y validación.

Debido a que no se conoce con antelación el comportamiento de la red con los

datos de la válvula se siguen los siguientes pasos pero durante la implementación se

van ajustando hasta que considere que el error de las predicciones de la red neuronal es

asumible. A continación explico cada no uno de los pasos:

Búsqueda de las variables de entrada

La búsqueda de las variables de entrada consiste en establecer la cantidad de

variables de entrada necesaria para entrenar la red. Es decir, se decidirá una cantidad

n de entradas tal que las variables 1,2, ...,n−1 son los valores de entrenamiento y la

variable n es el valor esperado dado los n−1 valores anteriores.

Preparación del conjunto de datos

Antes de realizar el entrenamiento de la red se deben normalizar los datos de entrada

en el intervalo de [0,1].

Creación de la red neuronal

En este paso se deberá decidir el número de neuronas en cada una de las capas (capa

de entrada, capa oculta y capa de salida).

Entrenamiento

En este paso se prepara la estructura de datos necesaria para el entrenamiento de la

red con los datos normalizados para que posteriormente la red tome dicha estructura

para su entrenamiento.

El paradigma de aprenizaje utilizado es el supervisado, por lo tanto, los datos que

se usan en el entrenamiento dependerá de la parametrización del agente; por ejemplo:

un 80% de datos de entrenamiento y un 20% de datos de predicción.

Predicción

Después del entrenamiento de la red se ejecutan las predicciones con los datos

reales establecidos para tal fin. En esta fase el sistema calcula el error obtenido en la

predicción.

27

Desarrollo

4.3.8. Diseño de interface gráfica de usuario

La interface gráfica de usuario está diseñada utilizando tecnologías web (HTML5,

JS, JSON, etc). Está compuesta de la página inicial que contiene el resumen de la

información de los datos almacenados, tiene dos páginas que contienen la información

de los brazos de carga de forma gráfica y por último contiene una página con el

conocimiento adquirido por el agente cognitivo y los resultados de las predicciones.

Diseño general

Figura 4.5 Pantalla inicial del GUI Web

La aplicación web está dividida en tres zonas: la zona de cabecera en donde se

encuentra el nombre de la aplicación y el usuario conectado, el menu que contiene las

distintas opciones que ofrece el sistema y la zona en donde se muestra el contenido de

las distintas opciones.

Diseño de página de resumen

La siguiente tabla muestra los últimos agentes conectados indicando la última

conexión, el último estado y el tamaño de la cola de mensajes

28

4.3 Diseño

Figura 4.6 Tabla de agentes conectados

La siguiente tabla muestra un resumen de todos los datos cargados en el sistema,

tanto datos de eventos como datos de órdenes de trabajo.

Figura 4.7 Tabla de resumen de datos

La siguiente tabla muestra los datos cargados por brazo de carga indicando los

valores mínimos, máximos y el número de registros de cada variable del brazo de carga.

Figura 4.8 Tabla de estadística de eventos por brazo de carga

29

Desarrollo

Diseño de página de gráficas de los datos de brazos de carga

Los gráficos de los datos de los brazos de carga se dividen en dos partes: En la parte

inferior se encuentra una línea de tiempo con todos los datos cargados del brazo (en la

imagen de ejemplo se observan los datos del mes de octubre) y en la parte superior ve

el detalle de cualquier fragmento de tiempo seleccionado por el usuario.

El objetivo de la gráfica es permitir interactuar de forma gráfica con la información

de los brazos de carga para que pueda interpretar fácilmente los resultados obtenidos a

través del sistema multiagente.

Figura 4.9 Gráfica del brazo de carga TORACCU072

4.4. Plan de pruebas

El plan de pruebas se subdivide en los tres partes principales del sistema: Los

agentes de entrada y salida de datos, los agentes cognitivos y la interface de usuario.

30

4.4 Plan de pruebas

4.4.1. Pruebas de agentes de entrada y salida de datos

Número de prueba PAESD - 001

Objetivo Prueba de conexión con la base de datos Cloudant

Prerequisitos La base de datos debe estar en creada con anterioridad en

Cloudant

Procedimiento 1. Configurar el fichero de propiedades de base de datos

2. Inicializar el agente de entrada salida de base de datos

NoSQL

Resultado Esperado Al inicializar el agente cambia a través de distintos estados

escribiendo en la base de datos cada vez que pasa por ca-

da uno de ellos. Se espera que cada cambio de estado se

almacene correctamente.

Observaciones


Objetivo Prueba de conexión con la base de datos CouchDB

Prerequisitos La base de datos debe estar en creada con anterioridad en

CouchDB

Procedimiento 1. Configurar el fichero de propiedades de base de datos

2. Inicializar un agente de entrada salida de base de datos

NoSQL

Resultado Esperado Al inicializar el agente cambia a través de distintos estados

escribiendo en la base de datos cada vez que pasa por ca-

da uno de ellos. Se espera que cada cambio de estado se

almacene correctamente.

Observaciones

31

Desarrollo


Objetivo Realizar pruebas de carga de datos de eventos del brazo de

carga desde ficheros CSV

Prerequisitos La base de datos debe estar creada con anterioridad

Procedimiento 1. Configurar el fichero de propiedades con las rutas de las

cargas de datos


NoSQL

3. Inicializar un agente de entrada salida de CSV

4. Copiar un fichero de carga con formato CSV que contenga

datos de eventos del brazo de carga a la ruta de ficheros de

eventos

Resultado Esperado Se espera que el fichero sea movido a un subdirectorio lla-

mado “procesado“ y por cada línea del fichero csv el agente

de E/S de CSV envíe un mensaje al agente de E/S de base de

datos cargando los datos correctamente en la base de datos

Observaciones

32

4.4 Plan de pruebas


Objetivo Realizar pruebas de carga de datos de OTs del brazo de carga

desde ficheros CSV



cargas de datos


NoSQL



datos de OTs del brazo de carga a la ruta de ficheros de OTs





Observaciones

33

Desarrollo


Objetivo Realizar pruebas de carga de datos de Mano de Obras OTs

del brazo de carga desde ficheros CSV



cargas de datos


NoSQL



datos de Mano de Obras de OTs del brazo de carga a la ruta

de ficheros de mano de obra





Observaciones Si el número de OT de la mano de obra no existe, no se

cargará la mano de obra

34

4.4 Plan de pruebas


Objetivo Realizar pruebas de carga de datos de Materiales de OTs del

brazo de carga desde ficheros CSV



cargas de datos


NoSQL



datos de Materiales de OTs del brazo de carga a la ruta de

ficheros de materiales





Observaciones Si el número de OT del material no existe, no se cargará la

mano de obra

35

Desarrollo


Objetivo Comprobar que las líneas de los ficheros de carga en forma-

to CSV se distribuyan uniformemente entre los agentes de

escritura de base de datos

Prerequisitos 1. La base de datos de estar creada con anteriorirdad

2. El fichero de propiedades debe tener la configuración de

conexión a la base de datos

3. El fichero de propiedades debe tener la configuración de

las rutas de cargas de ficheros

Procedimiento 1. Preparar un fichero de carga (es indiferente si es fichero

de eventos o de OTs) con N líneas

2. Copiar el fichero de carga a la ruta de carga de ficheros

3. Esperar que el agente CSV termine de enviar a procesar

todas las líneas

4. Entrar en el entorno web del sistema multiagente de pre-

dicción de averías para consultar el número de mensajes

asignado a cada agente de escritura de bases de datos

Resultado Esperado Se espera que el número de líneas N esté distribuido unifor-

memente entre los agentes de escritura. Es decir, si hay n

agentes de escritura se espera que cada uno tenga aproxima-

damente N/n mensajes.

Observaciones

36

4.4 Plan de pruebas

4.4.2. Pruebas de agentes cognitivos

Número de prueba PACOG - 001

Objetivo Entrenar la red neuronal

Prerequisitos Tener datos cargados con anterioridad en la base de datos

Procedimiento 1. Ejecutar un agente de entrada/salida de base de datos

2. Ejecutar un agente cognitivo en modo entrenamiento


dicción de averías para consultar el conocimiento que va

adquiriendo la red neuronal

Resultado Esperado Se espera que el agente cognitivo vaya adquiriendo conoci-

miento mientras va procesando la información de la base de

datos

Observaciones

Número de prueba PACOG - 002

Objetivo Verificar si después de que la red neuronal haya sido entre-

nada puede predecir una avería

Prerequisitos 1. Tener datos cargados con anterioridad en la base de datos

2. La red neuronal debe estar entrenada con anterioridad con

datos anteriores a una avería conocida

Procedimiento 1. Ejecutar un agente de entrada/salida de base de datos

2. Ejecutar un agente cognitivo en modo predicción.


dicción de averías para consultar las alertas generadas por el

agente cognitivo

Resultado Esperado 1. El agente debe continuar procesando la información desde

el punto en el que ha quedado en el entrenamiento

2. A medida que se acerque al momento en que se sabe

con anterioridad que ha ocurrido una avería, el agente debe

notificar una alerta

Observaciones

37

Desarrollo

4.4.3. Pruebas de visualización de datos

Número de prueba PVD - 001

Objetivo Verificar que la información del estado de los agentes de la

página de resumen se actualiza correctamente.

Prerequisitos 1. El sistema multiagente debe estar configurado y en ejecu-

ción

2. El servidor web Node.JS debe estar en ejecución

Procedimiento 1. Entrar en un navegador al entorno web del sistema

2. Refrescar cada 2 minutos el navegador

Resultado Esperado Se espera que el estado de los agentes se vaya actualizando

cada ves que se refresque el navegador

Observaciones


Objetivo Verificar que la información de Resumen de Datos se actua-

liza correctamente


ción



2. Cargar datos (es indiferente si son datos de Eventos u

OTs) en el sistema multiagente

3. Esperar a que el agente de carga CSV procese la informa-

ción

4. Esperar que losa agentes de entrada/salida de base de datos

procesen la información

3. Refrescar la aplicación web

Resultado Esperado Se espera que después de cargar la información se actualice

los datos que se muestran en la aplicación web

Observaciones

38

4.4 Plan de pruebas


Objetivo Verificar que la información de Estadísticas de Eventos se

actualiza correctamente


ción



2. Cargar datos de Eventos en el sistema multiagente


ción

4. Esperar que losa agentes de entrada/salida de base de datos



Resultado Esperado Se espera que después de cargar la información se actualice

los datos que se muestran en la aplicación web

Observaciones

39

Desarrollo


Objetivo Verificar que la información de los eventos (Caudal, Volumen

y Toma a Tierra) se muestran correctamente en las gráficas

de los brazos de carga


ción



2. En el menú de la izquierda selecciona un brazo de carga

3. Cargar datos de Eventos en el sistema multiagente para

el brazo de carga seleccionado, preferiblemente en una zona

temporal distinta que los datos que ya se encuentran carga-

dos.


ción

5. Esperar que los agentes de entrada/salida de base de datos



Resultado Esperado Se espera que los datos cargados se visualicen en la gráfica.

Los datos de toma a tierra se debe visualizar como una señal

digital

Observaciones

40

Capítulo 5

Resultados

En éste capítulo se presentan los resultados obtenidos desde tres enfoques diferentes.

Por una lado están los resultados obtenidos para el negocio de CLH, por otro lado, desde

una perspectiva general, se informa los resultados obtenidos con el sistema multiagente

y por último se detalla los resultados de la red neuronal utilizada por el agente cognitivo.

5.0.1. Resultados de Negocio

Integración y clasificación de la información

El primer gran resultado obtenido con este proyecto ha sido obtener, integrar y

clasificar la información. La iniciativa de éste proyecto fue tomada desde el área de

Sistemas, sin embargo, la información estaba dispersa entre el área de Sistemas y el

área de Operaciones, por un lado en Sistemas estaban datos muy básicos de señales

digitales y análogas (cuyos administradores no tenían el conocimiento completo para su

interpretación) y la información del mantenimiento realizado sobre los equipos (tanto

preventivo como correctivo) , y por otro lado, en Operaciones se encontraba los datos

de los derrames ocurridos en los últimos años.

Análisis de la información

Al nivel del análisis de información, el sistema obtuvo muy buenos resultados con

la poca informacion útil obtenida en el proyecto. Al integrar y clasificar la información

obtenida, se llegó a la conclusión que había poca información que se pudiera usar para

realizar mantenimiento predictivo. La única variable que podía brindar información

sobre el comportamiento de las válvulas principales del cargadero era el Caudal, las

41

Resultados

demás fueron descartadas porque no eran útiles, o porque eran dependientes del Caudal

o porque no eran fiables.

5.0.2. Resultados Sistema Multiagente

El sistema multiagente desarrollado crea la base para la implementación de un

sistema que integre información de múltiples sistemas con el objetivo de su análisis

utilizando técnicas de inteligencia artificial; obteniendo resultados en los siguientes

aspectos.

Sistema distribuido

Es un sistema con capacidad de instalarse en un entorno distribuido tanto a nivel del

sistema multiagente como a nivel de base de datos debido a que soporta bases de datos

basadas en Map-Reduce como CouchDB o Cloudant.

Capacidad de crecimiento del sistema

Debido a la arquitectura con la cual fue diseñado el sistema, tiene un alto potencial de

crecimiento, tanto en integración con otros sistemas como en la capacidad de análisis de

información. Los siguientes puntos resumen el resultado obtenido en la implementación

del sistema:

Implementación de más agentes de integración de sistemas: Actualmente el

sistema tiene tres formas de integración: Carga de ficheros CSV, conexión a la

BD CouchDB y conexión a la BD Cloudant.Sin embargo, debido a la arquitectura

del sistema, es fácilmente extensible a

Implementación de otros agentes cognitivos: En este proyecto se ha implementado

un agente cognitivo basandose en redes neuronales para la predicción de series

temporales; dejando la estructura del sistema lista para extender los agentes

cognitivos utilizando otras técnicas.

5.0.3. Resultados Red Neuronal

Para el análisis de los resultados obtenidos utilizando la red neuronal artificial se

utiliza el Error Absoluto Medio Porcentual (EAMP), el cual se intenta de minimizar;

por otro lado se utiliza el coeficiente de correlación (R) para comprobar la diferencia

que se produce en los datos predecidos por la red y los datos esperados.

42

Para la ejecución de la red neuronal se realizaron la combinación de las siguientes

condiciones:

Porcentaje de datos de aprendizaje: 80% y 75%

Algoritmo de aprendizaje: Back propagation y Resilient propagation.

Variables de entrada: 2,3,5,10,15 y 20

Al combinar las anteriores condiciones se obtuvieron los siguientes resultados

representados tanto numérica como gráficamente.

Resultados válvula TORACCU072

La válvula TORACCU072, se encuentra ubicada en la instalación de Zaragoza, en

el séptimo cargadero. La información analizada corresponde al mes de octubre de 2014

en donde fue reportado un sobrellenado el 21/10 a las 13:18h. Después de analizar

los resultados de la red neuronal se determinó que el patrón de comportamiento del

caudal no presentaba anomalías con respecto a los datos de las semanas anteriores,

posteriormente el personal encargado del análisis de los derrames informó que el

derrame ocurrió debido a que el transportista no purgó uno de los compartimentos del

camión, es decir, no se aseguró que el compartimento estuviese vacio antes de realizar

la carga del producto.

En los siguientes datos se pueden observar los resultados obtenidos en la ejecución

de la red neuronal. Las descripción de cada una de las columnas es la siguiente:

% Aprendizaje: Es el porcentaje de los datos que se destinaron para el aprendi-

zaje de la red neuronal.

Var Entrada: Es el número de valores (menos uno) que se toman de la serie

para realizar la predicción; es decir, si la variable de entrada es 10 quiere decir

que se toman 9 números y se predice el décimo valor.

Nº Predicciones: Es el número de predicciones que se realizaron durante la

ejecución. Éste numero depende del número seleccionado en las variables de

entrada.

MAD: Es el Error Absoluto Medio.

EAMP: Es el Error Absoluto Medio Porcentual calculado a partir de los datos

predecidos siguiendo la siguiente fórmula:

43

Resultados

TS: Es la señal de rastreo (em inglés Tracking Signal), permite medir la desvia-

ción con respecto al valor esperado. Aunque esté valor ha sido calculado, no es

tenido en cuenta en el análisis de resultados.

Corr R: La correlación R permite comparar la distancia entre los valores espe-

rados y los predecidos midiendo el grado de relación entre ellas. Entre más se

acerque a 1 quiere decir que están más relacionadas.

Figura 5.1 Resultados Back Propagation TORACCU072

Comparación Back Propagation. Aprendizaje 80% vs Aprendizaje 75%

Utilizando el algoritmo de aprendizaje Back Propagation para la válvula TORAC-

CU072, como era de esperar, al utilizar un aprendizaje del 75% de los datos el EAMP

es mayor, sin embargo, se estabiliza y se mantiene con la misma tendencia del aprendi-

zaje del 80% con un poco más de error.

Por otro lado, al analizar la variable de correlación y al compararla entre los dos

porcentajes de aprendizaje, se puede concluir que en forma general, utilizando el 80%

de los datos para aprendizaje permite que las predicciones estén más aproximadas a los

resultados esperados.Sin embargo, a través del tiempo, la red entrenada con el 75% de

los datos mejora considerablemente las predicciones.

44

De las siguientes gráficas se puede observar que debe existir un equilibrio en el

número de variables de entrada, si se seleccionan muy pocas variables o un número

excesivo el error en las predicciones aumenta. Utilizando Back Propagation y un

porcentaje de datos de aprendizaje de 80% ó 75%, el número adecuado de variables de

entrada para la válvula TORACCU072 es 12.

Figura 5.2 Gráficas de Resultados Back Propagation TORACCU072

Comparación Resilient Propagation. Aprendizaje 80% vs Aprendizaje 75%

De forma similar al algoritmo de aprendizaje Back Propagation, el algoritmo Resi-

lient Propagation tiene comportamiento parecido usando el 75% u 80% de los datos

para aprendizaje, aumentando el valor del error al tener muy pocas variables de entrada

o al tener exceso de variables de entrada. Según los resultados obtenidos para la válvula

TORACCU072, el número adecuado de variables de entrada son 10, similar al resultado

obtenido utilizando Back Propagation.

45

Resultados

Con respecto a la variable de correlación, el comportamiento de la red neuronal con

un aprendizaje del 75% de los datos datos es similar al observado con el algoritmo de

aprendizaje Back Propagation. Mientras que la red que fue entrenada con el 80% de los

datos presenta una correlación estable a partir de 5 o más variables de entrada.


46


Comparación Back Propagation vs Resilient Propagation

En las anteriores secciones se ha comparado los resultados entrenando las redes con

75% y 80% de los datos, usando los dos algoritmos de aprendizaje Back Propagation

y Resilient Propagation, pero no se han realizado comparaciones de los resultados

obtenidos entre ellos.

Las siguientes gráficas comparan los resultados obtenidos con ambos algoritmos de

aprendizaje.

El EAMP es muy parecido entre los dos algoritmos de aprendizaje sin importar

la cantidad de datos usados para el entrenamiento de la red. Aunque el algoritmo

Resilient Propagation tiene un mejor comportamiento cuando las variables de entrada

son menores que 10 y peor comportamiento después de 10.

47

Resultados

Figura 5.5 Gráficas EAMP TORACCU072

Al observar las siguientes gráficas de correlación se puede identificar que con el

75% de datos de aprendizaje ambos algoritmos se comportan de forma similar; al

aumentar el número de variables de entrada se comprueba que el algoritmo de Resilient

Propagation genera peores resultados que Back Propagation.

En la gráfica de correlación en donde se usó el 80% de los datos para aprendizaje se

puede observar que Resilient Propagation ha estado estable y con mejor correlación que

Back Propagation desde, aproximadamente, 5 variables de entradas.

48

Figura 5.6 Gráficas R TORACCU072

Resultados válvula TORACCU052

La válvula TORACCU052 se encuentra ubicada en la instalación de Torrejón, en

el quinto cargadero. La información analizada corresponde al mes de diciembre del

2014 en donde fue reportado un fallo del sistema el 16 de diciembre a las 3:33 de la

mañana. Después de analizarlos resultados de la red neuronal se determinó que el patrón

del comportamiento del caudal no presentaba anomalías con respecto a los datos de

días anteriores. El derrame ocurrió porque una de las electroválvulas falló dejando la

49

Resultados

válvula principal permanentemente abierta; el personal procedió a cerrar manualmente

la válvula principal.

Comparación Back Propagation. Aprendizaje 80% vs Aprendizaje 75%

A diferencia de la válvula anterior, en la válvula TORACCU052 presenta diferen-

cia de comportamientos de las redes neuronales dependiendo de la cantidad de datos

que se usaron para el aprendizaje. En este caso las ejecuciones realizadas con datos de

aprendizaje del 75% presentó estabilidad en los resultados anuque se modifiquen la

cantidad de variables de entrada.

En cambio, al usar el 80% de los datos para el aprendizaje las predicciones aumen-

taron el EAMP y disminuyó la variable de correlación de R; en otras palabras, aumentar

la cantidad de datos de entrenamiento no aportó valor a las predicciones de los datos.


En las siguientes gráficas se puede observar claramente que al usar el 75% de los

datos para el aprendizaje se obtuvieron predicciones con menor error por lo tanto con

mayor correlación a los datos esperados.

50


Comparación Resilient Propagation. Aprendizaje 80% vs Aprendizaje 75%

De forma similar al algoritmo Back Propagation, con el algoritmo Resilient Propa-

gation se obtuvieron mejores resultados al entrenar la red con el 75% de los datos.

Al utilizar el 75% de los datos para entrenamiento de la red, se estabilizó el error

desde aproximadamente 5 variables de entrada hasta 20 variables de entrada; aumen-

tando progresivamente la correlación de los resultados a medida que se amplian el

número de variables de entrada hasta aproximadamente 16, en donde empieza a reducir

la correlación de las predicciones.

Al utilizar el 80% de los datos para el entrenamiento de la red, el comportamiento

de Resilient Propagation fue similar a Back Propagation, se aumento el EAMP a medida

que se iban aumentando las variables de entrada hasta que se estabilizó alrededor de las

16 variables de entrada.

51

Resultados


Figura 5.10 Gráficas de Resultados Resilient Propagation TORACCU052

52

Comparación Back Propagation vs Resilient Propagation

Ambos algoritmos se han comportado practicamente igual cuando se usa el 80% de los

datos para aprendizaje, tanto en el EAMP como en el análisis de correlación.

Al comparar ambos algoritmo con un aprendizaje del 75% el algoritmo Resilient

Propagation obtiene una pequeña mejora sobre Back Propagation, sin embargo el

comportamiento es similar.

Figura 5.11 Gráficas EAMP TORACCU052

53

Resultados

Figura 5.12 Gráficas R TORACCU052

54

Capítulo 6

Conclusiones

Tanto el objetivo principal como los objetivos empresariales y técnicos fueron

alcanzados por completo. Sin embargo, el objetivo técnico Çomparar los resultados de

predicción del sistema multiagente con la información de averías obtenidas del sistema

de gestión de mantenimiento", se cumplió en el periodo de tiempo en el que nos dieron

los datos, pero se puede mejorar realizando pruebas con datos posteriores.

6.1. Conclusiones Empresariales

Este proyecto ha permitido integrar la información de múltiples sistemas que

contienen datos de los activos de CLH, mostrando la necesidad de analizar dicha

información con el objetivo de reducir costes operacionales.

Al clasificar la información obtenida de los distintos sistemas, se puede concluir

que no se está obteniendo la suficiente información de los activos para realizar

mantenimiento predictivo, por ejemplo, en la válvula principal de los cargade-

ros se podría obtener información de vibraciones, actualmente la información

principal que se captura es el caudal.

Es muy importante tener a una persona que conozca e interprete correctamente la

información obtenida de los diferentes sistemas ya que tanto el desarrollo como

los resultados generados en el sistema dependen de la interpretación realizada de

los datos.

El análisis de riesgos permitió la anticipación a los problemas que podían suceder

en el proyecto y generar estrategias para mitigarlas. Dos de ellos, justamente los

de mayor impacto (R001 - Desviación en la planificación por demoras al obtener

55

Conclusiones

la información y R002 - Información suficiente para la detección de averías) se

materializaron y fueron mitigados.

6.2. Conclusiones Técnicas

Utilizar Sistemas Multiagentes permite desacoplar las distintas funcionalidades

del sistema obteniendo alta capacidad de reutilización y facilitando la implemen-

tación de nuevas funcionalidades.

Utilizar bases de datos distribuidas distribuidos con sistemas multiagentes permite

aumentar la capacidad de procesamiento de información del sistema distribuyendo

la carga computacional de los distintos agentes.

Los sistemas que utilizan la técnica de redes neuronales para la predicción de

series temporales dependen de la selección del tipo de red neuronal y su parame-

trización para aproximarse adecuadamente a los resultados esperados.

Después de ejecutar las pruebas del sistema, se puede observar que cada válvula

tiene comportamiento diferente, por lo tanto la red neuronal de cada válvula debe

ser entrenada con los datos de la propia válvula y las predicciones realizadas por

la red neuronal serán diferentes. Lo importante es que la red neuronal establezca

patrones de comportamiento de la serie temporal y se detecten cambios en dichos

patrones.

Realizar múltiples ejecuciones con distintas parametrizaciones de la red neuronal

permite identificar los escenarios en donde las predicciones de la red neuronal se

aproxima más a los resultados esperados.

56

Capítulo 7

Líneas futuras

Como se ha dicho anteriormente, la ejecución de este proyecto ha permitido sentar

las bases para crear un sistema que se puede ir ampliando de acuerdo a las necesidades

del cliente debido a la arquitectura flexible con la cual fue construido.

Los siguientes puntos representan las líneas futuras en las que se puede ampliar el

proyecto a mediano plazo:

Actualmente el sistema soporta integración a través de ficheros CSV o conexión

directa a las base de datos CouchDB y Cloudant. Sin embargo, con poco esfuerzo

se puede extender la capacidad de integración a otras bases de datos comerciales

(Oracle, DB2, etc) o analizar alternativas de integración como servicios web o

REST.

La creación de un agente cognitivo basado en redes neuronales es solo un ejemplo

de las capacidades cognitivas que puede alcanzar el sistema. Debido a que el

sistema está basado en agentes, se puede agregar

Al ampliar las opciones de integración del sistema, es posible aumentar la fun-

cionalidad de los agentes cognitivos para que tomen decisiones de acuerdo a los

datos que van recibiendo del entorno.

Al recibir mayor información del entorno, analizar la información en cuanto llegue

y tomar decisiones, el sistema podría generar notificaciones cuando determine

que alguno de los activos está funcionando fuera de los patrones establecidos

como normales.

57

Bibliografía

[1] (2016a). Imagen de un cargadero de CLH. http://www.clh.es/image/img_transportistas.jpg. [En línea; 17/02/2016].

[2] (2016b). Instalaciones de Almacenamiento de Hidrocarburos. http://www.clh.es/file/Publicaciones/201512%20Instalaciones_cast.pdf. [En línea; 13/02/2016].

[3] (2016). Manual válvula Smith Meter Modelo 210. http://info.smithmeter.com/literature/docs/mn03010.pdf. [En línea; 23/02/2016].

[4] Nwana, H. S. (1996). Software agents: An overview. Cambridge University Press.

[Santana] Santana, J. F. D. P. Sistemas conexionistas – redes neuronales. XII Conferen-cia de la Asociación Española para la Inteligencia Artificial (CAEPIA).

59

Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,

C=ES

Fecha/Hora Wed Jul 06 21:31:57 CEST 2016

Emisor delCertificado

[email protected], CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)

Documents

Mantenimiento Predictivo usando Sistemas MultiAgentesoa.upm.es/54407/1/TFM_JAVIER_EDUARDO_CARRILLO_PLAZA.pdf · Mantenimiento Predictivo usando Sistemas MultiAgentes Javier Eduardo