Tfm javier eduardo_carrillo_plaza

Mantenimiento Predictivo usando
Sistemas 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 1
1.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 5
2.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 Artiﬁciales (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 13
3.1. Categorización de riesgos . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Identiﬁcación de riesgos . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Probabilidad e impacto de los riesgos . . . . . . . . . . . . . . . . . 14
3.4. Estratégias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Desarrollo 19
4.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áﬁca 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 41
5.0.1. Resultados de Negocio . . . . . . . . . . . . . . . . . . . . . 41
5.0.2. Resultados Sistema Multiagente . . . . . . . . . . . . . . . . 42
5.0.3. Resultados Red Neuronal . . . . . . . . . . . . . . . . . . . . 42
6. Conclusiones 55
6.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áﬁcas 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 cualiﬁcación de riesgos . . . . . . . . . . . . . . . . . . . . 15
3.5. Tabla de Probabilidad e impacto de los riesgos . . . . . . . . . . . . . 16
3.6. Tabla de tipiﬁcació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 Identiﬁer
AMS Agent Management System
ANNs Artiﬁcial 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
TFM 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 planiﬁca 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 camiones
cisterna
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 en
los 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 ﬂuya 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 clasiﬁcar 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 soﬁsticados de inteligencia artíﬁcial 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 ﬁnalizado 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 signiﬁca 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 deﬁnido 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 ﬁnanciamiento.
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ón
R001 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 Peso
Muy baja 15%
Baja 50%
Alta 70%
Muy Alta 85%
Máxima 100%
Cuadro 3.3 Tabla de impacto si ocurre el riesgo
% Impacto Peso
Muy bajo 15%
Bajo 50%
Alto 70%
Muy Alto 85%
Máximo 100%
Cuadro 3.4 Tabla de cualiﬁcación de riesgos
% Riesgo Nivel
2% 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 Riesgo
R001 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égia
Mitigar 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égia
R001 Mitigar Riesgo Obtener el apoyo de la alta dirección para la
consecución de la información del proyecto
R002 Mitigar Riesgo Identiﬁcar 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ón
RF01 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ón
RT01 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 ﬁgura 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 ﬁgura 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 artiﬁciales, 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 identiﬁcació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 ﬁn. 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 ﬁcheros CSV
cargas de datos
NoSQL
datos de OTs del brazo de carga a la ruta de ﬁcheros de OTs
Observaciones
33

Desarrollo
Objetivo Realizar pruebas de carga de datos de Mano de Obras OTs
del brazo de carga desde ﬁcheros CSV
cargas de datos
NoSQL
datos de Mano de Obras de OTs del brazo de carga a la ruta
de ﬁcheros 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 ﬁcheros CSV
cargas de datos
NoSQL
datos de Materiales de OTs del brazo de carga a la ruta de
ﬁcheros 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 Veriﬁcar 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
notiﬁcar 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 Veriﬁcar 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áﬁcamente.
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áﬁcas 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áﬁcas 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áﬁcas 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áﬁcas 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 modiﬁquen 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áﬁcas 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áﬁcas 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áﬁcas EAMP TORACCU052
53

Resultados
Figura 5.12 Gráﬁcas 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 suﬁciente 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 identiﬁcar 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/
ﬁle/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 Artiﬁcial (CAEPIA).
59

Este documento esta firmado por
Firmante 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 del
Certificado
EMAILADDRESS=camanager@fi.upm.es, CN=CA Facultad de
Informatica, O=Facultad de Informatica - UPM, C=ES
Numero de Serie 630
Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (Adobe
Signature)

Tfm javier eduardo_carrillo_plaza

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Tfm javier eduardo_carrillo_plaza

Similar a Tfm javier eduardo_carrillo_plaza (20)

Último

Último (20)

Tfm javier eduardo_carrillo_plaza