sistema inteligente de previsión de la evolución de la ... · lenguaje de programación java que...
TRANSCRIPT
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
Sistema inteligente de previsión de la
evolución de la fiabilidad de un
aerogenerador de un parque eólico en
función de la vida observada y del
mantenimiento aplicado
Autor: Jorge Luque Carrasco
Director: Rodrigo José de Andrade Vieira
Director: Miguel Ángel Sanz Bobi
MADRID Julio 2014
AUTORIZACIÓN PARA LA DIGITALIZACIÓN, DEPÓSITO Y DIVULGACIÓN EN ACCESO
ABIERTO (RESTRINGIDO) DE DOCUMENTACIÓN
1º. Declaración de la autoría y acreditación de la misma.
El autor D. _JORGE LUQUE CARRASCO___, como _ALUMNO__ de la UNIVERSIDAD PONTIFICIA
COMILLAS (COMILLAS), DECLARA
que es el titular de los derechos de propiedad intelectual, objeto de la presente cesión, en
relación con la obra PROYECTO FIN DE CARRERA DE SISTEMA INTELIGENTE DE PREVISIÓN DE
LA EVOLUCIÓN DE LA FIABILIDAD DE UN AEROGENERADOR DE UN PARQUE EÓLICO EN FUN-
CIÓN DE LA VIDA OBSERVADA Y DEL MANTENIMIENTO APLICADO_1, que ésta es una obra ori-
ginal, y que ostenta la condición de autor en el sentido que otorga la Ley de Propiedad Intelec-
tual como titular único o cotitular de la obra.
En caso de ser cotitular, el autor (firmante) declara asimismo que cuenta con el consentimien-
to de los restantes titulares para hacer la presente cesión. En caso de previa cesión a terceros
de derechos de explotación de la obra, el autor declara que tiene la oportuna autorización de
dichos titulares de derechos a los fines de esta cesión o bien que retiene la facultad de ceder
estos derechos en la forma prevista en la presente cesión y así lo acredita.
2º. Objeto y fines de la cesión.
Con el fin de dar la máxima difusión a la obra citada a través del Repositorio institucional de la
Universidad y hacer posible su utilización de forma libre y gratuita ( con las limitaciones que
más adelante se detallan) por todos los usuarios del repositorio y del portal e-ciencia, el autor
CEDE a la Universidad Pontificia Comillas de forma gratuita y no exclusiva, por el máximo plazo
legal y con ámbito universal, los derechos de digitalización, de archivo, de reproducción, de
distribución, de comunicación pública, incluido el derecho de puesta a disposición electrónica,
tal y como se describen en la Ley de Propiedad Intelectual. El derecho de transformación se
cede a los únicos efectos de lo dispuesto en la letra (a) del apartado siguiente.
3º. Condiciones de la cesión.
1 Especificar si es una tesis doctoral, proyecto fin de carrera, proyecto fin de Máster o cualquier otro
trabajo que deba ser objeto de evaluación académica
Sin perjuicio de la titularidad de la obra, que sigue correspondiendo a su autor, la cesión de
derechos contemplada en esta licencia, el repositorio institucional podrá:
(a) Transformarla para adaptarla a cualquier tecnología susceptible de incorporarla a internet;
realizar adaptaciones para hacer posible la utilización de la obra en formatos electrónicos, así
como incorporar metadatos para realizar el registro de la obra e incorporar “marcas de agua”
o cualquier otro sistema de seguridad o de protección.
(b) Reproducirla en un soporte digital para su incorporación a una base de datos electrónica,
incluyendo el derecho de reproducir y almacenar la obra en servidores, a los efectos de garan-
tizar su seguridad, conservación y preservar el formato. .
(c) Comunicarla y ponerla a disposición del público a través de un archivo abierto institucional,
accesible de modo libre y gratuito a través de internet.2
(d) Distribuir copias electrónicas de la obra a los usuarios en un soporte digital. 3
4º. Derechos del autor.
El autor, en tanto que titular de una obra que cede con carácter no exclusivo a la Universidad
por medio de su registro en el Repositorio Institucional tiene derecho a:
a) A que la Universidad identifique claramente su nombre como el autor o propietario de los
derechos del documento.
b) Comunicar y dar publicidad a la obra en la versión que ceda y en otras posteriores a través
de cualquier medio.
2 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría redactado en los
siguientes términos:
(c) Comunicarla y ponerla a disposición del público a través de un archivo institucional, accesible de
modo restringido, en los términos previstos en el Reglamento del Repositorio Institucional
3 En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría eliminado.
c) Solicitar la retirada de la obra del repositorio por causa justificada. A tal fin deberá ponerse
en contacto con el vicerrector/a de investigación ([email protected]).
d) Autorizar expresamente a COMILLAS para, en su caso, realizar los trámites necesarios para
la obtención del ISBN.
d) Recibir notificación fehaciente de cualquier reclamación que puedan formular terceras per-
sonas en relación con la obra y, en particular, de reclamaciones relativas a los derechos de
propiedad intelectual sobre ella.
5º. Deberes del autor.
El autor se compromete a:
a) Garantizar que el compromiso que adquiere mediante el presente escrito no infringe ningún
derecho de terceros, ya sean de propiedad industrial, intelectual o cualquier otro.
b) Garantizar que el contenido de las obras no atenta contra los derechos al honor, a la intimi-
dad y a la imagen de terceros.
c) Asumir toda reclamación o responsabilidad, incluyendo las indemnizaciones por daños, que
pudieran ejercitarse contra la Universidad por terceros que vieran infringidos sus derechos e
intereses a causa de la cesión.
d) Asumir la responsabilidad en el caso de que las instituciones fueran condenadas por infrac-
ción de derechos derivada de las obras objeto de la cesión.
6º. Fines y funcionamiento del Repositorio Institucional.
La obra se pondrá a disposición de los usuarios para que hagan de ella un uso justo y respetuo-
so con los derechos del autor, según lo permitido por la legislación aplicable, y con fines de
estudio, investigación, o cualquier otro fin lícito. Con dicha finalidad, la Universidad asume los
siguientes deberes y se reserva las siguientes facultades:
a) Deberes del repositorio Institucional:
- La Universidad informará a los usuarios del archivo sobre los usos permitidos, y no garantiza
ni asume responsabilidad alguna por otras formas en que los usuarios hagan un uso posterior
de las obras no conforme con la legislación vigente. El uso posterior, más allá de la copia priva-
da, requerirá que se cite la fuente y se reconozca la autoría, que no se obtenga beneficio co-
mercial, y que no se realicen obras derivadas.
- La Universidad no revisará el contenido de las obras, que en todo caso permanecerá bajo la
responsabilidad exclusiva del autor y no estará obligada a ejercitar acciones legales en nombre
del autor en el supuesto de infracciones a derechos de propiedad intelectual derivados del
depósito y archivo de las obras. El autor renuncia a cualquier reclamación frente a la Universi-
dad por las formas no ajustadas a la legislación vigente en que los usuarios hagan uso de las
obras.
- La Universidad adoptará las medidas necesarias para la preservación de la obra en un futu-
ro.
b) Derechos que se reserva el Repositorio institucional respecto de las obras en él registradas:
- retirar la obra, previa notificación al autor, en supuestos suficientemente justificados, o en
caso de reclamaciones de terceros.
Madrid, a ……….. de …………………………... de ……….
ACEPTA
Fdo……………………………………………………………
Proyecto realizado por el alumno:
Jorge Luque Carrasco
Fdo.: ………………………….… Fecha: …….. /...… /……..
Autorizada la entrega del proyecto cuya información no es de carácter confidencial:
EL DIRECTOR DEL PROYECTO
Rodrigo José de Andrade Vieira
Fdo.: ………………………………. Fecha: ……. /……/……
EL DIRECTOR DEL PROYECTO
Miguel Ángel Sanz Bobi
Fdo.: ………………………………. Fecha: ……. /……/……
Vº Bº DEL COORDINADOR DE PROYECTOS
Israel Alonso Martínez
Fdo.: …………………………………… Fecha: ……/……/……
Agradecimientos
Agradezco a todas las personas involucradas en este proyecto, especialmente a mis
directores y coordinador por toda la ayuda recibida.
También agradece a mi familia todo el apoyo y ayuda que me ha dado en los malos
momentos, permitiéndome seguir adelante en este proyecto.
Sistema inteligente de previsión de la evolución de la
fiabilidad de un aerogenerador de un parque eólico en
función de la vida observada y del mantenimiento
aplicado
Autor: Luque Carrasco, Jorge
Directores: Jose de Andrade Viera, Rodrigo
Sanz Bobi, Miguel Ángel
Entidad Colaboradora: ICAI – Universidad Pontificia Comillas
Resumen
El objetivo de este proyecto es desarrollar una plataforma multiagente inteligente que
permita simular el comportamiento de los componentes de un aerogenerador utilizando su
tiempo de vida, con ello se podrá obtener la probabilidad del fallo de los componentes y los
costes del propio aerogenerador a los largo del tiempo, permitiendo diseñar un plan de
manteamiento único óptimo para cada aerogenerador.
Hoy en día las energías renovables están volviéndose más comunes y necesarias en el
ámbito de la producción energética. La energía eólica constituye una de las fuentes de energía
con mayor crecimiento, hecho que se demuestra con el aumento de proyectos de construcción
de nuevos parques eólicos y la demanda de este tipo de energía.
Los principales factores que favorecen el desarrollo de la energía eólica son la
preocupación por el medio ambiente generada por el impacto mediático del cambio climático,
la seguridad del abastecimiento al ser una energía renovable.
Los aerogeneradores son máquinas sencillas, pero están expuestas a condiciones
meteorológicas extremas. Que un aerogenerador falle implica un coste tanto en energía no
producida como en reparación, mantenimiento o sustitución del aerogenerador. Por lo que es
deseable minimizar esos costes mediante un programa de mantenimientos basado en
simulaciones, predicciones y monitorización.
Algunas de las tecnologías utilizadas para el desarrollo de esta plataforma son el
lenguaje de programación JAVA que está ampliamente conocido en el ámbito de la
informática, es un lenguaje de programación orientado a objetos, con una gran API para el
tratamiento de diferentes tipos de problemas. Para poder desarrollar una plataforma
multiagente se ha integrado un middleware llamado JADE; escrito en JAVA y utilizado bajo este
mismo lenguaje, nos permite crear un sistema multiagente distribuido, dónde las agente
intercambian información para poder resolver un problema específico. La siguiente tecnología
que se ha usado es un sistema experto desarrollado por la NASA en los años 80, llamado CLIPS;
su funcionalidad será la dotar a nuestro sistema de una respuesta inteligente cuando sea
necesario realizar algún razonamiento sobre el estado de la plataforma. El uso de JFreeChart
tiene la finalidad de poder mostrar los datos obtenidos de la plataforma de una forma que el
usuario sea capaz de entender, es una herramienta muy potente para JAVA, que nos permite
diseñar gráficos con un acabado profesional.
Para modelar la probabilidad de fallo del componente se usará la distribución
exponencial, puesto que es una función de distribución de vida muy utilizada para modelar la
fiabilidad de componentes y sistemas porque se basa en una forma matemática sencilla y muy
tratable, además de considerarla representativa del intervalo de vida funcional o útil del ciclo
de vida de un componente.
La plataforma está basada en una arquitectura multiagente distribuida, compuesta por
un conjunto de agentes, los agentes son elementos inteligentes que son capaces de percibir su
entorno y responder o actuar de una forma racional.
Se ha definido un conjunto de agentes necesario para llevar a cabo esta finalidad:
Agente Central: Es el primer agente en ser lanzado y el que tiene que funcionar
siempre el primero, ya que implementa el núcleo de JADE, sin este no funcionaría
ningún otro agente, ya que se encarga de mantener un registro de los agentes.
También implementa los mecanismos para la comunicación de los agentes entre sí, y
por último crea automáticamente dos agentes fundamentales en la plataforma, los
agentes Agent Management System (AMS) y Directory Facilitator (DF).
Agente de Monitorización: Es agente principal de la simulación, es el agente que
realiza el cálculo de la probabilidad de todos los componentes del aerogenerador, para
ello simula el paso del tiempo en meses.
Agente de Anomalías: El agente de anomalías es el encargado de analizar la
información sobre un aerogenerador del resto de agentes y redistribuirla de manera
adecuada, además de analizar y almacenarla de manera temporal.
Agente de Mantenimiento: Este agente es el encargado de llevar al cabo el control del
mantenimiento.
Agente de Diagnóstico: Es el agente encargado de implementar el motor de inferencia
desarrollado usando CLIPSJNI, que tomará todas las decisiones sobre el plan de
mantenimiento según la información que recibe de anomalías.
Agente de Interface: Este agente se encarga de mostrar al usuario toda la información
centralizada del resto de agentes.
INTERFACE
MANTENIMIENTO
MONITORIZACION
ANOMALIAS DIAGNOSTICO
Probabilidad de
Fallo de los
componentes
Petición de
Mantenimiento
Información sobre manteni-
miento realizado
Información sobre los compo-
nentes
Respuesta del sistema experto
Petición de
Mantenimiento
Respuesta del
sistema exper-
to
Información sobre los compo-
nentes
Información sobre manteni-
miento realizado
Intelligent system for forecasting the evolution of the
reliability of a wind turbine on a wind farm on the basis
of observed life and maintenance applied
Autor: Luque Carrasco, Jorge
Directores: Jose de Andrade Viera, Rodrigo
Sanz Bobi, Miguel Ángel
Entidad Colaboradora: ICAI – Universidad Pontificia Comillas
Abstract
The objetive of this project is to delevop an intelligent multi-agent platform to
simulate the behavior of components of a wind turbine using its lifetime, thereby obtaining the
probability of failure of components and the costs of the wind turbine itself over time, allowing
a optimal design for each wind turbine.
Nowadays renewable energy are becoming more common and necessary in the field of
energy production. Wind power is one of the energy sources with higher growth, a fact that is
demonstrated by the increase in new construction projects of wind farms and the demand for
this type of energy.
The main factors that favor the development of wind energy are concerns about the
environment generated by the media coverage of climate change and the continuous supply
for be a renewable energy.
Wind turbine are simple machines, but are exposed to extreme weather conditions. A
wind turbine fails implies a cost in both energy not produced as repair, maintenance or
replacement of the wind turbine. So is derirable to minimize these costs through a maintance
programs based on simulations, predictions and monitoring.
Some of the technologies used for the development of this platform are the
programming language JAVA that is widely known in the field of computing, is an object-
oriented programming language, with a great API for the treatment of different types of
problems. To develop a multi-agent platform has integrated a middleware called JADE; written
in JAVA and used under the same language, this allow us to create a distributed multi-agent
system where the agents exchange information to solve a specific problem. The next
technology that has been used is an expert system developed by NASA in the 80s, called CLIPS;
his functionality will be providing an intelligent response when is required to do some
reasoning about the state of the platform. Using JFreeChart is intended to be able to display
data from the platform in a way that the user is able to understand, is a very powerful tool for
JAVA.
To model the probability of failure of the component the exponential distribution will
be used, since it is a life distribution function very used to model the reliability of components
and systems because it is based on a simple mathematical form and highly treatable, and held
representative of the functional life span or useful in the life cycle of a component.
The platform is based on a distributed multiagent architecture consisting of a set of
agents, the agents are smart items that are able to perceive their environment and respond or
act in a rational manner.
It has defined a set of agents necessary to carry out this purpose:
Central Agent: This is the first agent to be released and that has to always run the first,
as it implements the core of jade, without this any other agent won't work, since it is
responsible for keeping a record of the agents. It also implements the mechanisms for
the communication of the agents among themselves, and finally automatically creates
two key actors in the platform, the agents Agent Management System (AMS) and
Directory Facilitator (DF).
Monitoring Agent: Is a principal agent of the simulation, is the agent that performs the
calculation of the probability of all the components of the wind turbine, simulating the
passage of time in months.
Anomalies Agent: The agent of anomalies is responsible for analyzing the information
about a wind turbine for the rest of the agents and to redistribute it in an appropriate
manner, in addition to analyze and store it on a temporary basis.
Maintenance Agent: This agent is responsible for carrying out the control of the
maintenance.
Diagnostic Agent: the agent is responsible for implementing the inference engine
developed using CLIPSJNI, this will make all decisions about the maintenance plan
according to the information it receives from anomalies.
Interface Agent: This Agent is responsible for displaying to the user all the centralized
information on the agents.
INTERFACE
MANTENIMIENTO
MONITORIZACION
ANOMALIAS DIAGNOSTICO
Probabilidad de
Fallo de los
componentes
Petición de
Mantenimiento
Respuesta del sistema experto
Petición de
Mantenimiento
Información sobre manteni-
miento realizado
Información sobre manteni-
miento realizado
Información sobre los compo-
nentes
Información sobre los compo-
nentes
Respuesta del
sistema exper-
to
1
ÍNDICE
Capítulo 1 - Introducción ...................................................................................................... 7 1.1 Motivación del Proyecto ..................................................................................................... 8 1.2 Objetivos ............................................................................................................................. 9 1.3 Metodología Propuesta ..................................................................................................... 10 1.4 Recursos/Herramientas empleadas .................................................................................. 12 Capítulo 2 - Contexto de Trabajo ........................................................................................ 15 2.1 Introducción ...................................................................................................................... 16 2.2 Principios de funcionamiento de un aerogenerador ........................................................ 16 2.3 Definición de fiabilidad...................................................................................................... 17 2.4 Definición de mantenimiento ........................................................................................... 18 2.4.1 Concepto ..................................................................................................................... 18 2.4.2 Justificación ................................................................................................................. 18 2.4.3 Objetivos ...................................................................................................................... 19 2.4.4 Tipos de Mantenimiento ............................................................................................. 19 2.5 Metodología de fiabilidad y mantenimiento en el proyecto ............................................ 20 2.6 Distribución de vida exponencial ...................................................................................... 21 2.7 Tratamiento de la fiabilidad y mantenimiento en el sistema multiagente ....................... 24 2.8 Definición de sistemas multiagente .................................................................................. 25 Capítulo 3 - Tecnologías empleadas .................................................................................... 29 3.1 Introducción ...................................................................................................................... 30 3.2 JAVA ................................................................................................................................... 30 3.3 MYSQL ............................................................................................................................... 31 3.3.1 Conceptos .................................................................................................................... 31 3.3.2 Diseño de la Base de Datos ......................................................................................... 32 3.4 CLIPS Y CPLISJNI ................................................................................................................. 32 3.5 JFREECHART ....................................................................................................................... 33 3.6 JDOM ................................................................................................................................. 35 3.7 JADE ................................................................................................................................... 35 3.7.1 Introducción ................................................................................................................ 35 3.7.2 Conceptos .................................................................................................................... 36 3.7.3 Comunicación .............................................................................................................. 40 Capítulo 4 Requisitos y Organización .................................................................................. 45 4.1 Introducción ...................................................................................................................... 46 4.2 Requisitos .......................................................................................................................... 46 4.3 Organización ...................................................................................................................... 52 Capítulo 5 Diseño y Desarrollo de la Plataforma ................................................................. 55 5.1 Introducción ...................................................................................................................... 56 5.2 Modelado de datos ........................................................................................................... 56 5.3 Plataforma Multiagente .................................................................................................... 60 5.3.1 Gestión de Mantenimiento ......................................................................................... 60 5.3.2 Agente Central ............................................................................................................. 61 5.3.3 Agente Monitorización ................................................................................................ 63 5.3.4 Agente Mantenimiento ............................................................................................... 64 5.3.5 Agente Anomalias ........................................................................................................ 65 5.3.6 Agente Diagnóstico ...................................................................................................... 67
2
5.3.7 Agente Interface .......................................................................................................... 69 5.3.8 Esquema de Comunicaciones ...................................................................................... 74 Capítulo 6 Pruebas ............................................................................................................. 77 6.1 Introducción ...................................................................................................................... 78 6.2 Tipos de pruebas ............................................................................................................... 78 Capítulo 7 Implantación ..................................................................................................... 81 7.1 Introducción ...................................................................................................................... 82 7.2 Manual de implantación ................................................................................................... 82 7.2.1 JAVA ............................................................................................................................. 83 7.2.2 JADE ............................................................................................................................. 84 7.2.3 CLIPSJNI ....................................................................................................................... 87 7.2.4 MYSQL ......................................................................................................................... 88 7.3 Pruebas de implantación ................................................................................................... 89 7.4 Documentación final del proyecto .................................................................................... 89 Capítulo 8 Resultados ........................................................................................................ 91 8.1 Introducción ...................................................................................................................... 92 8.2 Planes de Mantenimiento ................................................................................................. 94 8.3 Ejecución de la plataforma ................................................................................................ 95 8.4 Resultado Aerogenerador A .............................................................................................. 98 Capítulo 9 Conclusiones y Futuras Mejoras ....................................................................... 109 9.1 Conclusiones.................................................................................................................... 110 9.2 Futuras mejoras ............................................................................................................... 111 Capítulo 10 Presupuesto .................................................................................................. 113 Anexo A Manual de Usuario ...................................................................................................... 117 Anexo B Ampliación de Resultados ........................................................................................... 123 Anexo C Bibliografía .................................................................................................................. 133
3
FIGURAS
Figura 1 Metodología .................................................................................................................. 10
Figura 2 Portátil Asus .................................................................................................................. 12
Figura 3 Aerogenerador .............................................................................................................. 17
Figura 4 Gráfica Probabilidad/Fiabilidad ..................................................................................... 22
Figura 5 Gráfica Mantenimiento ................................................................................................. 24
Figura 6 Logo JAVA ...................................................................................................................... 30
Figura 7 Logo MYSQL ................................................................................................................... 31
Figura 8 Logo CLIPS...................................................................................................................... 33
Figura 9 Ejemplo JFreeChart ....................................................................................................... 34
Figura 10 Logo JADE .................................................................................................................... 36
Figura 11 Directory Facilitator ..................................................................................................... 38
Figura 12 Estructura Behavior ..................................................................................................... 40
Figura 13 Ejemplo Mensaje FIPA ................................................................................................. 43
Figura 14 Logo FIPA ..................................................................................................................... 43
Figura 15 Organización del Proyecto .......................................................................................... 52
Figura 16 Estructura Ejemplo ParqueAerogenerador ................................................................. 57
Figura 17 Ejemplo XML ................................................................................................................ 59
Figura 18 Gestión Mantenimiento .............................................................................................. 60
Figura 19 Consola Agente Central ............................................................................................... 62
Figura 20 Interfaz Agente Central ............................................................................................... 62
Figura 21 Consola Agente Monitorización .................................................................................. 64
Figura 22 Consola Agente Mantenimiento ................................................................................. 65
Figura 23 Consola Agente Anomalias .......................................................................................... 66
Figura 24 Consola Agente Anomalias .......................................................................................... 67
Figura 25 Reglas Agente Diagnostico .......................................................................................... 68
Figura 26 Interfaz Agente Diagnostico ........................................................................................ 69
Figura 27 Interfaz Arbol del Agente Interface ............................................................................. 70
Figura 28 Interfaz Lista del Agente Interface .............................................................................. 71
Figura 29 Interfaz Coste del Agente Interface ............................................................................ 72
4
Figura 30 Interfaz Comparar del Agente Interface ..................................................................... 73
Figura 31 Esquema Simple de Comunicaciones .......................................................................... 74
Figura 32 Ejemplo de Prueba de Encadenamiento ..................................................................... 79
Figura 33 Instalación JAVA .......................................................................................................... 83
Figura 34 Consola JAVA ............................................................................................................... 84
Figura 35 Configuración Avanzada del Sistema .......................................................................... 85
Figura 36 JADE Consola Comando ............................................................................................... 86
Figura 37 JADE RAM GUI ............................................................................................................. 87
Figura 38 Statement para la creación de la BD ........................................................................... 88
Figura 39 PF - Averia Yaw A ......................................................................................................... 93
Figura 40 XML Inicial_A ............................................................................................................... 94
Figura 41 XML Barato_A .............................................................................................................. 94
Figura 42 XML Caro_A ................................................................................................................. 95
Figura 43 Nombre Simulacion ..................................................................................................... 96
Figura 44 Seleccionar Árbol ......................................................................................................... 96
Figura 45 Cargando los agentes .................................................................................................. 97
Figura 46 Pantalla Inicial ............................................................................................................. 97
Figura 47 Probabilidad y Coste AM A .......................................................................................... 99
Figura 48 Probabilidad y Coste FDM A ........................................................................................ 99
Figura 49 Probabilidad y Fallo FRM A ........................................................................................ 100
Figura 50 Probabilidad y Coste M A .......................................................................................... 100
Figura 51 Probabilidad y Coste AG A ......................................................................................... 101
Figura 52 Probabilidad y Coste TDC A ....................................................................................... 101
Figura 53 Probabilidad y Coste TDG A ....................................................................................... 102
Figura 54 Probabilidad y Coste G A ........................................................................................... 102
Figura 55 Probabilidad y Coste AY A ......................................................................................... 103
Figura 56 Probabilidad y Coste EAC A ....................................................................................... 104
Figura 57 Probabilidad y Coste DP A ......................................................................................... 104
Figura 58 Probabilildad y Coste FS A ......................................................................................... 105
Figura 59 Probabilidad y Coste O A ........................................................................................... 105
Figura 60 Probabilidad y Coste A A ........................................................................................... 106
Figura 61 Probabilidad y Coste PA ............................................................................................ 107
5
Figura 62 XML Simple ................................................................................................................ 117
Figura 63 Ejemplo Conf Central ................................................................................................. 117
Figura 64 XML Inicial_B ............................................................................................................. 117
Figura 65 XML Barato_B ............................................................................................................ 117
Figura 66 XML Caro_B ............................................................................................................... 117
Figura 67 Probabilidad y Coste DFM B ...................................................................................... 117
Figura 68 Probabilidad y Coste M B .......................................................................................... 117
Figura 69 Probabilidad y Coste AG B ......................................................................................... 117
Figura 70 Probabilidad y Coste G B ........................................................................................... 117
Figura 71 Probabilidad y Coste TDC B ....................................................................................... 117
Figura 72 Probabilidad Y Coste O B ........................................................................................... 117
Figura 73 Probabilidad y Coste FS B .......................................................................................... 117
Figura 74 Probabilidad y Coste A B ........................................................................................... 117
Figura 75 XML Inicial_C ............................................................................................................. 117
Figura 76 XML Barato_C ............................................................................................................ 117
Figura 77 XML Caro_C ............................................................................................................... 117
Figura 78 Probabilidad y Coste AM C ........................................................................................ 117
Figura 79 Probabilidad y Coste M C .......................................................................................... 117
Figura 80 Probabilidad y Coste FRM C ...................................................................................... 117
Figura 81 Probabilidad y Coste DFM C ...................................................................................... 117
Figura 82 Probabilidad y Coste EAP C ....................................................................................... 117
Figura 83 Probabilidad O C ........................................................................................................ 117
Figura 84 Probabilidad y Coste A C ........................................................................................... 117
6
TABLAS
Tabla 1 Requisito Interfaz de Usuario ......................................................................................... 47
Tabla 2 Requisito Base de Datos ................................................................................................. 47
Tabla 3 Requisito Gestor de Mantenimiento .............................................................................. 48
Tabla 4 Requisito Plataforma de Simulación ............................................................................... 48
Tabla 5 Requisito Agente Central ................................................................................................ 49
Tabla 6 Requisito Agente Monitorización ................................................................................... 49
Tabla 7 Requisito Agente Mantenimiento .................................................................................. 50
Tabla 8 Requisito Agente Anomalías ........................................................................................... 50
Tabla 9 Requisito Agente Diagnóstico ......................................................................................... 51
Tabla 10 Requisito Agente Interface ........................................................................................... 51
Tabla 11 Ejemplo de Mensaje ..................................................................................................... 75
Tabla 12 Presupuesto Software ................................................................................................ 115
Tabla 13 Presupuesto Hardware ............................................................................................... 115
Tabla 14 Presupuesto Personal ................................................................................................. 116
Tabla 15 Presupuesto Total ....................................................................................................... 116
7
Capítulo 1
INTRODUCCION
8
1.1 Motivación del Proyecto
Hoy en día las energías renovables están volviéndose más comunes y necesarias en el
ámbito de la producción energética. La energía eólica constituye una de las fuentes de energía
con mayor crecimiento, hecho que se demuestra con el aumento de proyectos de construcción
de nuevos parques eólicos y la demanda de este tipo de energía.
Los principales factores que favorecen el desarrollo de la energía eólica son la
preocupación por el medio ambiente generada por el impacto mediático del cambio climático,
la seguridad del abastecimiento al ser una energía renovable.
Los aerogeneradores son máquinas sencillas, pero están expuestas a condiciones
meteorológicas extremas. Que un aerogenerador falle implica un coste tanto en energía no
producida como en reparación, mantenimiento o sustitución del aerogenerador. Por lo que es
deseable minimizar esos costes mediante un programa de mantenimientos basado en
simulaciones, predicciones y monitorización.
Dado que el rendimiento y la eficiencia de los parques eólicos es cada vez más
importante tanto para los propietarios como para los inversores y explotadores del mismo,
una mejor planificación del mantenimiento, reparaciones, revisiones, etc. de los
aerogeneradores ahorraría costes reduciendo el tiempo de no producción y alargando el ciclo
de vida útil de los parques.
Otra motivación es la aplicación de la inteligencia artificial y el uso de agentes
inteligentes, una aplicación cada vez más extendida y con mayores y más complejos usos.
Además de ser un tema de un gran interés personal, es increíblemente útil en cualquier ámbito
imaginable, ya que lo buscado es que una máquina sea capaz de razonar, pensar y aprender al
igual que un ser humano, haciéndola útil en cualquier tarea que hasta el momento solo podía
realizara un ser humano.
9
1.2 Objetivos
El objetivo de este proyecto es desarrollar una plataforma multiagente inteligente que
permita simular el comportamiento de los componentes de un aerogenerador utilizando su
tiempo de vida, con ello se podrá obtener la probabilidad del fallo de los componentes y del
propio aerogenerador a los largo del tiempo, permitiendo diseñar un plan de manteamiento
único óptimo para cada aerogenerador.
Para ello se tomará una plataforma desarrollada en otro proyecto realizado hace unos
años, la cual se estudiará, modificará, adaptará y se ampliará para este proyecto. (Poner como
referencia bibliográfica)
Para asegurar que la información proporcionada por la plataforma y el trascurso de la
simulación es realista, se utilizarán datos de aerogeneradores, previamente analizados y
agrupados, ya que ese análisis y filtro no entra dentro de las competencias de este proyecto.
Con la nueva plataforma se podrán generar simulaciones complejas de múltiples
aerogeneradores simultáneos, permitiendo implementar y observar diferentes planes de
mantenimiento en cada simulación. Mediante pruebas y comparaciones se podrá obtener un
plan de mantenimiento eficiente y de bajo coste para el aerogenerador, que permitiría ahorrar
costes al parque eólico haciéndolo más eficiente.
10
1.3 Metodología Propuesta
En este apartado se expondrá la metodología que se seguirá a lo largo del proyecto, es
decir los pasos a realizar, con una justificación de cada uno de ellos (Figura 1):
Figura 1 Metodología
11
Análisis del contexto de trabajo: Se estudian todos los elementos que tendrán
importancia en el desarrollo del proyecto, que son los Aerogeneradores, mantenimiento
industrial, fiabilidad y sistemas multiagente.
Estudio de las tecnologías: En esta fase se obtendrá un conocimiento avanzado de las
diferentes herramientas y tecnologías que se utilizarán para desarrollar este proyecto, dicha
herramientas son: JAVA, JADE, JDOM, MySQL, JFreeChart, CLIPSJNI.
Elaboración de los requisitos: organización y costes: Una vez conocido todo lo
relacionado al entorno del proyecto y la herramientas y tecnologías, se elaborarán unos
requisitos que definan bien los objetivos que la plataforma tendrá que cumplir como así los
diferentes subsistemas en los que se dividirá. También se designarán los roles del desarrollo
del proyecto de todas las personas involucradas y sus responsabilidades. Con todo esto se
podrá realizar un presupuesto inicial.
Modificación, adaptación y ampliación de la plataforma: Esta fase es la que más
tiempo se le va a dedicar, ya que el grueso del proyecto. Se adaptará la plataforma al nuevo
entorno de trabajo y se añadirán nuevas funcionalidades que mejores la estabilidad y
escalabilidad de la plataforma, así como ofrecer una plataforma más amigable, sencilla de usar
y que ofrezca más información durante y después de las simulaciones.
Pruebas e implantación: Las prueba a pesar de estar en junto con la implantación se
realizarán a lo largo de todo el desarrollo de la plataforma involucrando a todos los
subsistemas y siendo de distintos tipos (pruebas de sobrecarga, de comunicación,
escalabilidad, etc.). Rn cuanto a la implantación se realizarán pruebas de implantación y un
manual que facilite al usuario implantar la plataforma en cualquier sistema.
Redacción de la memoria: En la fase final, se agrupará y organizará todo el contenido y
documentación generada en las fases anteriores para formar la memoria final del proyecto.
12
1.4 Recursos/Herramientas empleadas
En este apartado se listarán todos aquellos recursos y herramientas que se emplearon
en el desarrollo de este producto.
Los recursos/herramientas que se emplearon en el desarrollo del proyecto fueron:
Software:
o Microsoft Word 2010: Utilizado para la redacción de la documentación.
o JAVA: Lenguaje de programación para desarrollar la plataforma.
o Netbeans: Entorno de programación del proyecto.
o JADE: Librerias JAVA para la creación de sistemas multiagente.
o JDOM: Librerias JAVA para el uso de XML.
o JFreechart: Librerias JAVA para la creación de gráficos.
o CLIPSJNI: Librerias JAVA para la creación y uso de un motor de inferencia CLIPS.
Hardware:
o Portátil Asus A53SV-SX041V
Figura 2 Portátil Asus
13
Especificaciones Modelo: Asus A53SV-SX041V
Sistema Operativo: Windows 7 Home Premium SP1 64 Bits.
Procesador: Intel Core i5 2410M 2,4 GHz.
Adaptador Grafico: NVIDIA GeForce GT 540M
Memoria: 4 GB DDR3
Disco Duro: 500 GB HDD
Pantalla: 15.6 pulgadas, 16:9, 1366x768 pixels, glossy
Peso: 2.7kg
Precio: 549 €
Utilizado para el desarrollo de la aplicación.
14
15
Capítulo 2
CONTEXTO DE TRABAJO
16
2.1 Introducción
El proyecto está orientado hacia la evaluación y mejora de la fiabilidad y
mantenimiento de un parque eólico mediante un sistema multiagente. Este capítulo dará una
breve introducción a estos principios básicos:
Descripción de un aerogenerador y su funcionamiento
Definición de fiabilidad y de mantenimiento
Definición de un sistema multiagente
2.2 Principios de funcionamiento de un aerogenerador
Un aerogenerador es un generador eléctrico movido por una turbina que es accionada
por el viento. Su funcionamiento básico consiste en que la energía cinética del aire
proporciona energía mecánica a un rotor (la hélice), que a su vez a través de un sistema de
transmisión mecánico, hace girar el rotor mecánico de un generador convirtiendo esa energía
mecánica en energía eléctrica.
Su origen son los molinos de viento, que también utilizaban la energía cinética del
viento para la molienda y obtención de harina.
Los aerogeneradores pueden trabajar de manera aislada o agrupados en parques
eólicos o plantas de generación eólicos. La distribución de los mismo varía de cada parque o
estación ya que se tienen en cuenta el impacto ambiental y las turbulencia que generan el
movimiento de las palas (se busca no destrozar el terreno utilizado ni que los aerogeneradores
interfieran unos con otros).
Existen varios modelos en cuestión a los parques o plantas, en Europa se distingue
claramente un modelo centro-europeo, donde los aerogeneradores llegan a ubicarse en
pequeñas agrupaciones cerca de las poblaciones. Sin embargo en España se opta por
agrupaciones (a veces de gran tamaño) en las zonas montañosas con viento frecuente y suelen
estar alejadas de los núcleos de población.
17
2.3 Definición de fiabilidad
La fiabilidad es entendida como la probabilidad de que un componente complete su
propósito bajo unas condiciones establecidas durante un periodo de tiempo establecido.
Dentro de la industria esa enfocada a la predicción de fallos, tanto el donde como el cuándo,
por ello se crean modelos de fiabilidad que permitan obtener dicha información analizando
información sobre el componente [FORT13].
Para comprender la metodología que se va a implementar en la plataforma es
necesario explicar antes unos simples conceptos:
Modo de fallo: Es el fallo de un componente ocurrido por un único evento. Un
componente tiene múltiples modos de fallo, ya que puede fallar por múltiples razones.
Figura 3 Aerogenerador
18
MTBF (Mean Time Between Failures) o tiempo medio entre fallos: Tiempo transcurrido
entre la ocurrencia de 2 modos de fallos idénticos y consecutivos.
2.4 Definición de mantenimiento
2.4.1 CONCEPTO
El mantenimiento son un conjunto de técnicas destinada a conservar equipos e
instalaciones industriales, alargando su tiempo de vida buscando la más alta disponibilidad y
con el máximo rendimiento.
El mantenimiento no debe verse como un costo, si no como una inversión, ya que está
ligado a la producción, disponibilidad, calidad y eficiencia.
2.4.2 JUSTIFICACION
¿De verdad es necesario complicar la estructura de la compañía incluyendo personal,
departamentos, planes, etc. de mantenimiento? La respuesta es afirmativa, por las siguientes
razones:
Competitividad: Al estar en un mercado competitivos es necesario implementar cada
medida posible que permita abaratar costes. Por ello es necesario optimizar el
consumo de materiales y mano de obra; mediante el mantenimiento se ahorran costes
aumentando el tiempo de vida de los equipos, de esa manera su reemplazo (con su
gran coste) puede ser atrasado.
19
Productividad y disponibilidad: Han aparecido multitud de técnicas y estudios que su
implantación podría mejorar los resultados de la empresa. Un equipo sin
mantenimiento tiene una productividad decreciente conforme pasa el tiempo; sin
embargo mediante el mantenimiento es posible tener un nivel de productividad
estable durante todo el tiempo de vida del equipo, algo muy importante en sectores
de servicios (como los parques o plantas aerogeneradores) ya que pueden ofrecer sus
servicios a sus clientes de manera estable sin muchas complicaciones.
Compromiso de calidad, seguridad: Tanto por motivos legales como morales la
empresas deben ofrecer un servicio de calidad y que tanto su producción como
explotación sea seguro tanto para los empleados como para los clientes finales;
mediante el mantenimiento y sus resultados es posible monitorizar e imponer esos
criterios.
2.4.3 OBJETIVOS
A raíz de lo visto en los anteriores apartados se puede resumir que los objetivos del
mantenimiento son:
Evitar, reducir y reparar los fallos.
Aumentar el tiempo de vida de los equipos.
Evitar accidentes y detenciones inútiles.
Reducir costes.
2.4.4 TIPOS DE MANTENIMIENTO
En cuanto a los tipos de mantenimiento se pueden clasificar 2 tipos:
20
Mantenimiento Correctivo: Es el conjunto de actividades de reparación y sustitución,
que se realiza cuando aparece el fallo en elemento/componente/maquina. Solo es
aplicable a sistemas en los que es imposible predecir los fallos y que su interrupción
imprevista es admitida. Este tipo de mantenimiento no puede ser el único aplicado en
una instalación, ya que los fallos pueden afectar a otros componentes y es necesario
tener un gran stock de piezas de repuesto.
Mantenimiento Preventivo: Es el conjunto de actividades programadas encaminadas a
reducir la frecuencia e impacto de los fallos, más que un tipo de mantenimiento son
técnicas de detección para ordenar la intervención antes de la aparición del fallo. Este
tipo de mantenimiento se divide en 2 categorías:
o Mantenimiento Preventivo Sistemático: Se efectúa de manera periódica
según un plan establecido.
o Mantenimiento Preventivo Condicional: Se efectúa cuando una condición o
acontecimiento ya predeterminado ocurre.
2.5 Metodología de fiabilidad y mantenimiento en el proyecto
La información de la que parte la metodología son los tiempos de vida observable de
los componentes que corresponden a los fallos ocurridos siguiendo un plan de
mantenimientos preventivos estático y básico.
En lo referente a la indisponibilidad se parte de tener registrada la fecha y el modo de
fallo del componente. Un añadido sería disponer también del coste asociado a dicho fallo.
En cuanto al mantenimiento de los componentes se parte de:
Información sobre el mantenimiento correctivo del componente, fecha de ejecución,
tiempo de mantenimiento y coste.
21
Conocimiento sobre el plan de mantenimiento preventivo aplicado en la simulación,
con sus tiempos de lanzamiento, modos de fallo que se quieren prevenir y el coste de
cada mantenimiento preventivo.
Distribuciones de vida en fiabilidad. Utilizando el tiempo de indisponibilidad se ha
supuesto que también está disponible la tasa de fallos de cada modo de fallo. El
cálculo de dicha tasa se calcula obteniendo lo que se conoce como tiempo medio entre
fallos o MTBF (Mean Time Between Failures). Existen 2 tipos de enfoques para dar
forma a las distribuciones de vida:
o Métodos paramétricos: Basados en determinar una serie de parámetros que
permiten conformar funciones de distribución adecuadas para representar la
distribución de vida.
o Métodos no paramétricos: Realizan el modelado de fiabilidad mediante
observaciones reales [ANDE07], [BARL09], [BART09].
Los métodos paramétricos son los más extendidos y usados, en particular la
distribución de vida basada en la ley exponencial, el utilizando por la plataforma, y en la ley de
Weibull.
2.6 Distribución de vida exponencial
La distribución exponencial es una función de distribución muy utilizada para la
fiabilidad de componentes y sistemas ya que se basa en una forma matemática simple y muy
tratable.
En esta distribución se supone una tasa de fallo constante ( ). Las funciones básicas de
fiabilidad son las siguientes:
Función de densidad de probabilidad de fallo
( )
22
Función de distribución de fallos o función de probabilidad de fallo
( )
Función de fiabilidad
( )
En la plataforma se ha optado por este modelo por su sencillez y exactitud. Un
ejemplo de cómo sería la representación temporal de las funciones de probabilidad de fallo y
de la fiabilidad seria:
Figura 4 Gráfica Probabilidad/Fiabilidad
Como era de esperar según pasa el tiempo la probabilidad de fallo aumenta, y por
tanto disminuye la fiabilidad. De esta manera conociendo la tasa de fallo de un modo de fallo
de un componente, utilizando el tiempo transcurrido, se puede estimar la probabilidad de fallo
y la fiabilidad del mismo [JARD09].
23
Como se ha mencionado se puede obtener el MTBF observando las fechas en las que
ocurrieron indisponibilidades con modos de fallos similares. Una vez obtenido el MTBF de un
modo de fallo es posible calcular la tasa de fallo mediante su inversa.
Por supuesto existen otros medios para calcular la tasa de fallos, ya que se mide en
número de eventos por unidad de tiempo.
También se puede obtener una tasa de mantenimiento de forma similar, observando
los tiempos en los que se ha aplicado mantenimiento o tomando el valor del ciclo de
mantenimiento preventivo del plan de mantenimiento aplicado [LEVI09].
Una vez ya se conoce la distribución que se utilizara para calcular la probabilidad de
fallo hay que establecer un modelo de mantenimiento. Existen muchos modelos de
mantenimiento cuyo contenido esta fuera del alcance de este proyecto, por lo que solo se
comenta el contexto de trabajo que los modelos pueden tener:
Modelo de mantenimiento perfecto: Se considera que al realizar un mantenimiento
preventivo el componente queda como nuevo, es decir, la probabilidad de fallo vuelve
a ser 0.
Modelo de mantenimiento imperfecto: Al realizar un mantenimiento preventivo el
componente no queda como nuevo.
El modelo de mantenimiento elegido ha sido el modelo de mantenimiento imperfecto, ya
que es más realista (factor importante en una simulación). El efecto que tendría sobre la
probabilidad de fallo de un componente sería parecido a la siguiente gráfica.
24
Figura 5 Gráfica Mantenimiento
En el modelo que se implantará cada mantenimiento no tendrá la misma efectividad, si
no que se tendrá en cuenta el número de mantenimiento realizado a cada modo de fallo para
reducir su efectividad (si siempre tuviera la misma efectividad entonces jamás sería necesario
cambiar componentes y durarían una eternidad, lo cual no es para nada realista).
2.7 Tratamiento de la fiabilidad y mantenimiento en el sistema
multiagente
A modo de resumen y por clarificar conceptos se exponen todos los conceptos
explicados en este capítulo que se emplearán en la plataforma:
25
La unidad básica es el componente.
Cada componente tiene diferentes formas de fallar, es decir múltiples modos de fallo.
Cada modo de fallo tiene asociada una tasa de fallo.
Cada modo de fallo tiene aplicado un plan de mantenimiento preventivo propio.
Cada acción de mantenimiento tiene asociada una efectividad (1 para los
mantenimiento correctivos siempre), que se reduce según se aplican sobre el mismo
modo de fallo.
Cualquier acción de mantenimiento o indisponibilidad de componente tiene asociado
un coste.
La plataforma contempla la dinámica de un escenario simulado, donde se pondrán
observar las probabilidades de fallo de cada modo de fallo y componente, y las acciones de
mantenimiento realizadas. Observando estas dinámicas se podrá observar si los tiempos de
mantenimiento del plan implementado en la simulación son adecuados (tanto en efectividad
como en coste) y su efecto en la fiabilidad, de esa manera se podrá realizar más simulaciones.
2.8 Definición de sistemas multiagente
Un sistema multiagente es una solución basada en la cooperación entre agentes, en
donde uno o varios de ellos pueden tener implementada algún tipo de inteligencia artificial,
por ese motivo se enmarcan dentro del ámbito de la inteligencia artificial.
26
Los sistemas multiagente han aparecido en el mundo de la inteligencia computacional
con el objetivo de simular el comportamiento de sistemas complejos, utilizando para ello
componentes básicos denominados agentes.
Dado que su dominio de trabajo es muy extenso y complejo no se ha llegado a una
definición universal sobre lo que es un agente. Sin embargo, la comunidad científica
relacionada con estos sistemas si han llegado a un acuerdo sobre las características que
pueden usarse para reconocer a un agente [BELL04]:
Autonomía: Es la característica principal de un agente, su comportamiento está en su
propio conocimiento, es decir el agente tiene iniciativa propia y puede actuar
independientemente.
Sociabilidad: Otra característica esencial en un agente, como se ha mencionado
anteriormente un agente es un componente básico. Por lo que es necesario que
interactúe con otros agentes para poder desarrollar tareas complejas basándose en la
cooperación.
Aprendizaje y razonamiento: Un agente debe cumplir su cometido usando su
conocimiento y/o aprendido del entorno.
Identidad: Un agente puede ser una entidad física o virtual.
Reactividad: Un agente debe poder responder de la manera más rápida posible a
peticiones del entorno (pueden ser tanto del entorno fuera del sistema como otros
agentes).
Proactividad: Un agente es capaz de tomar la iniciativa en una actividad, tomar
decisiones, comunicarse con otros agente, etc. sin necesidad de actuación exterior.
Con todo esto una posible definición de agente sería: Un agente inteligente es un
objeto físico o virtual autónomo con capacidad de razonar y aprender que ya sea por iniciativa
propia o impuesta es capaz de alcanzar un objetivo cooperando con otros agentes inteligentes.
Una buena arquitectura de agentes es un componente fundamental para que un
sistema multiagente pueda desarrollar su función de manera óptima. Existen 4 tipos de
arquitecturas de agentes o formas en las que los agentes pueden ser implementados:
27
Basada en lógica (logic-based): Representan el entorno mediante símbolos o
sentencias y lo manipulan utilizando mecanismo lógicos o de razonamiento. La ventaja
de esta arquitectura es que fácil de codificar, ya que el conocimiento humano se
etiqueta de la misma manera, lo que hace más sencillo de entender. La desventaja es
que resulta difícil traducir el entorno a un sistema de símbolos o sentencias de manera
acertada en poco tiempo, por lo que en sistema de tiempo real estricto no resulta útil.
Reactiva (reactive): Implementan la toma de decisiones mediante un sistema de
estímulo-respuesta. La ventajas consiste en al no tener que convertir la información en
símbolos o sentencias es más rápida a la hora de actuar que la basada en lógica. La
desventaja es que al basarse en estímulo-respuesta requiere que el estímulo contenga
mucha información para poder generar una respuesta apropiada.
BDI (Belief, Desire, Intention): Se basa en filosofía y ofrece una teoría lógica que
define los estados mentales de creencia, deseo e intención mediante un modelo
lógico. El sistema más conocido es el Procedurar Reasonong System(PRS), que
implementa, además de los 3 mencionados, Plan y Interperter:
o Belief representa la información que tiene el agente sobre el entorno.
o Desire representa las tareas del agente, es decir los objetivos.
o Intention representa desires que el agente ha realizado para lograr el objetivo
final.
o Plan representa conjuntos de acciones que el agente puede realizar.
o Interperter es el que gestiona los agentes, actualizando los beliefs,
seleccionando desires para ser ejecutados.
28
Por capas (Layered): Es una arquitectura hibrida que acepta reactiva y basada en
lógica. Para poder realizarlo, los subsistemas se colocan en capas dentro de una
jerarquía que permite la convivencia de ambos tipos de arquitectura. Las capas
pueden estar en horizontal (en paralelo) o en vertical (en serie). La principal ventaja de
esta arquitectura es su simple diseño y flexibilidad; sin embargo dado que soporta 2
tipos de arquitecturas muy diferentes requiere un control y organización más
exhaustiva.
Se puede concluir que cada agente es portador de un microcomportamiento en un
dominio. Mediante al cooperación e interacción de varias agentes se induce un
macrocomportamiento capaz de resolver problemas complejos. Esta estructura es referida
como sistema multiagente.
Una de las claves en un sistema multiagente es la cooperación y comunicación entre
los mismo. La comunicación entre agentes se puede implementar usando formatos estándar
para intercambiar información, denominados lenguajes de comunicación de agentes. Dos de
los lenguajes más conocidos son FIPA-ACL (la plataforma del proyecto utilizara este lenguaje) y
KQML [GOME12].
Cabe destacar que cada vez aparecen más herramientas y procesos multiagente en el
mercado, sobre todo en el mercado industrial con herramientas para el control de procesos,
diagnostico de sistemas, manufactura, logística y gestión de redes. Aunque su mejor campo de
aplicación es la recogida, análisis y gestión de información, esto ha sucedido gracias a la
expansión de internet, donde, al ser un sistema distribuido, los sistemas multiagente han
resultado extremadamente eficaces y han aparecido multitud de sistemas, especialmente en
marketing.
29
Capítulo 3
TECNOLOGÍAS EMPLEADAS
30
3.1 Introducción
Una vez ya introducido el cometido de la plataforma, las bases teóricas necesarias para
comprender el motivo y rumbo del proyecto, en este capítulo se hablarán de las tecnologías
empleadas para el desarrollo de este proyecto, añadiendo una descripción, el porqué de su
uso y que aportan al proyecto.
3.2 JAVA
JAVA es un lenguaje de programación muy extendido y aceptado por una gran
comunidad de desarrolladores, lo que lo convierte en un lenguaje muy flexible y con multitud
de librerías creadas por dicha comunidad para casi cualquier tipo de aplicación, a raíz de esta
flexibilidad y multitud de librerías se ha decidido utilizar JAVA como lenguaje de programación
de la plataforma.
Figura 6 Logo JAVA
31
3.3 MYSQL
3.3.1 CONCEPTOS
MySQL es un sistema de gestor de base de datos del tipo relacional, perteneciente a la
empresa Sun microsystems, se distribuye bajo licencia GPL, aunque también dispone de
software para mediadas y grandes empresas con una mejora de prestaciones y servicios.
Las bases de datos relacionales almacenan los datos en relaciones, que representa una
tabla, obteniendo un conjunto de tablas separadas pero relacionadas entre sí que permite
velocidad y flexibilidad a la hora de manejar dichos datos; además al estar relacionadas es muy
simple obtener datos de múltiples tablas y combinarlos sobre un mismo pedido.
MySQL no solo acepta conexión directa a través de su propio software, sino que
también proporciona APIs que permiten que aplicaciones escritas con distintos lenguajes de
programación puedan acceder a los datos almacenados. En JAVA dicha API se denomina JDBC.
Se ha decidido utilizar este Sistema de Gestor de Base de Datos por los motivos ya
explicados además de por estar muy extendido, ser una herramienta open source y gratuita.
Figura 7 Logo MYSQL
32
3.3.2 DISEÑO DE LA BASE DE DATOS
El diseño de la base es datos de la plataforma es muy sencillo, ya que únicamente lo
utiliza el agente central para guardar información de 3 agentes (monitorización,
mantenimiento y anomalías) para permitir que entre agentes que monitorizan el mismo
elemento puedan comunicarse. El diseño es el siguiente:
ANOMALIAS = {AID + IP + DATOS}
MANTENIMIENTO = {AID + IP + DATOS}
TOMADATOS = {AID + IP + DATOS}
Siendo:
AID: Dirección del agente
IP: IP del agente
DATOS: Aerogenerador que monitoriza
3.4 CLIPS Y CPLISJNI
CLIPS es un entorno de desarrollo para la programación y desarrollo de un motor de
inferencia, cuya principal función es razonar como lo haría un ser humano. La estructura básica
del sistema experto que se desarrolla consiste en 4 componentes principales:
Una Base de hechos donde se almacenan los hechos (características, datos) percibidos
sobre un problema.
33
Una base de conocimiento, que contiene las reglas que representan el modelo del
conocimiento extraído.
El motor de inferencia, encargado de razonar.
Un interfaz de usuario para poder interactuar con el sistema experto.
CLIPS fue desarrollado por la NASA en el año 1984. Una vez el proyecto fue
abandonado, se liberó el software para que la comunidad de desarrolladores continuara su
desarrollo. CLIPS está escrito en C y los paradigmas que engloba son programación lógica,
imperativa y orientada a objetos.
CLIPSJNI, cuyo significado es CLIPS JAVA Native Interface, fue desarrollada
posteriormente y permite la integración de ese software en cualquier aplicación JAVA.
Figura 8 Logo CLIPS
3.5 JFREECHART
JFreeChart es una biblioteca completamente libre que permite dibujar gráficas de una
manera sencilla, y con un acabado profesional. Las características de la biblioteca son [JFRC14]:
34
Es “open source”, se distribuye bajo los términos de la GNU Licencia Pública General
Menor (LGPL), que permite el uso de las aplicaciones propietarias.
Proporciona una API consistente y bien documentada.
Apoyo a una amplia gama de gráficos.
Soporte para muchos tipos de salidas, incluyendo componentes Swing, archivos de
imagen y formatos gráficos vectoriales de archivo.
Su uso en la plataforma se limita a mostrar la información del resultado de los cálculos
de la función de densidad de probabilidad de fallo, como también la información sobre el
mantenimiento de cada modo de fallo. Es fuente de información más fácil de ver de la
plataforma, ya que muestra mucha información en un espacio reducido y constátenme
actualizada.
Figura 9 Ejemplo JFreeChart
35
3.6 JDOM
JDOM es una biblioteca de código abierto que permite manipular datos XML de
manera optimizada desde JAVA. Se ha elegido el usar XML para almacenar la información de
los componentes de la simulación ya que XML es un estándar muy extendido, fácil de leer y
comprender.
3.7 JADE
3.7.1 INTRODUCCION
JADE es un middleware completamente distribuido con una infraestructura flexible
permitiendo fáciles extensiones con módulos add-on. Este framework facilita el desarrollo de
sistemas completamente basado en agentes.
Al estar completamente escrito en JAVA, se beneficia de la inmensa cantidad de
librearias disponibles y compatibles que están en este lenguaje. Además ofrece una gran
cantidad de métodos que permite a los desarrolladores construir una aplicación basada en
agente con solo un conocimiento básico sobre agentes. Las ventajas que proporciona JADE son
las siguientes:
Creación básica de agentes.
Programación lógica de agentes mediante comportamiento o behaviors.
ACL FIPA para la comunicación entre agentes (envío y recepción de mensajes).
Manejo de información mediante el uso de ontologías.
36
Clases útiles para la programación de protocolos FIPA (y no FIPA).
Soporta distintos codecs (SL, RDF, etc.)
La definición de agente inteligente según [EPDI14] es:
“Podemos definir al agente inteligente como una entidad software que, basándose en
su propio conocimiento, realiza un conjunto de operaciones destinadas a satisfacer las
necesidades de un usuario o de otro programa, bien por iniciativa propia o porque alguno de
éstos se lo requiere.
Todos los agentes inteligentes son programas, pero no todos los programas que
realizan búsquedas son agentes inteligentes. Los agentes en sí mismos pueden ser
considerados como entidades individuales (partes de programa que tienen control sobre sus
propias vidas y movimientos). Continuamente están realizando procesos que les indican qué
hacer y cómo. Se comunican con otros agentes para resolver de forma adecuada su trabajo.”
Figura 10 Logo JADE
3.7.2 CONCEPTOS
Antes de continuar es importante definir un conjunto de definiciones y conceptos
importantes que su utilizarán a partir de ese momento (sobre todo en el capítulo del diseño de
la plataforma).
JADE se posiciona entre el programa de usuario y el sistema operativo, por lo tanto
ofrece una plataforma sencilla que permite desarrollar agente sin que sea necesario tener que
implementar las especificaciones técnicas típicas de los agentes [BELL04].
37
Los agentes se alojan en contenedores, como mínimo siempre hay un contenedor que
es el main-container o contenedor principal, dicho contenedor tiene la función de
implementar toda la base de JADE para que cualquier agente pueda registrarse y participar en
la plataforma, este contenedor también tiene integrado el Message Transport System, que es
lo que permite a los agente registrados comunicarse entre ellos.
Además, al crear el contenedor principal, se crean automáticamente dos agentes
necesarios para la plataforma, el Agent Management System (AMS) y el Directory Facilitator
(DF), cuya función es similar a la páginas blancas y las páginas amarillas respectivamente. Es
decir el AMS es un directorio donde se guardan todos los agentes registrados en la plataforma,
mientras que el DF guarda la información del agente registrado además de informar cual es el
servicio que el agente ofrece a la plataforma, esta información se utiliza para buscar al agente
cuando es requerido comunicarse con él.
Los agentes interactúan con el DF mediante intercambio de mensajes ACL usando el
lenguaje SL0 y la ontología FIPA-agent-management. JADE facilita este procedimiento con los
métodos implementados en la clase DFService. Para que un agente publique su servicio al DF:
El agente proporciona al DF una descripción, que incluye su AID (Agent Identifier), los
protocolos, lenguajes y ontologías que el agente utiliza y los demás agente deben
utilizar para poder comunicarse con él; y la lista de servicios que ofrece y publica.
Por cada uno de esos servicios se proporciona otra descripción, esta incluye: tipo de
servicio, nombre, protocolos, lenguajes y ontologías, además de una serie de
propiedades específicas del servicio.
Cuando un agente finaliza su ejecución debe eliminar del DF todos sus servicios.
38
Figura 11 Directory Facilitator
La función del AMS, del mismo modo que el DF para su función, proporciona unos
métodos relacionado con el registro de agentes en la plataforma:
Garantiza que cada agente tiene un nombre único evitando errores en la
comunicación.
Se encarga de proporcionar los servicios de páginas blancas y ciclo de vida, además
mantener actualizado el directorio de los identificadores de los agentes y el estado de
cada uno de ellos.
Cada agente debe registrarse en el AMS para recibir un AID que le permita
comunicarse con el resto de la plataforma.
39
Otro concepto importante mencionado junto con el AMS y el DF es el identificador del
agente, llamado AID, este AID funciona como una dirección IP para la plataforma, es decir para
establecer comunicación con el agente es necesario conocer su AID. Todo agente tiene un
método llamado setup, en el cual se añade la información necesaria para el correcto
funcionamiento del agente, en este método el agente crea su AID. El formato de dicho AID es
el siguiente:
Nombre_agente@direccion:puerto / JADE
Siendo nombre_agente el nombre del agente, dirección su dirección IP y puerto el
puerto que utiliza para comunicarse.
Una vez terminado el método setup, el agente realiza la petición de Register, que
consiste en enviar un mensaje al main-container, suministrando su nombre, AID y los demás
datos que se guardaran en el DF. Tras terminar el registro el agente puede comenzar su
funcionamiento mediante el comportamiento definido, también determinado en el método
setup.
Para desarrollar el comportamiento JADE proporciona un conjunto de métodos
englobados en la clase Behaviour. Existen varios tipos de comportamiento ya implementados
[PROG14]:
Simple Behaviour: Es un comportamiento simple.
OneShot Behaviour: Un comportamiento que solo se ejecuta una vez.
Cyclic Behaviour: Es un comportamiento cíclico. Es el principal comportamiento
implementado en la plataforma a desarrollar.
Parallel Behaviour: Permite la ejecución de varios comportamientos paralelos.
Sequencial Behaviour: Permite la ejecución de varios comportamientos, pero en orden
secuencial o por lotes.
FSM Behaviour: Es el comportamiento más complejo, permite definir una máquina de
estados finitos compuesta por subcomportamientos.
40
Figura 12 Estructura Behavior
3.7.3 COMUNICACIÓN
Como se ha mencionado anteriormente, la comunicación en un sistema con JADE se
realiza mediante el lenguaje de comunicación FIPA. Actualmente FIPA cuenta con más de 60
miembros de 20 países a lo largo del mundo.
FIPA fue establecida en 1996 como una asociación internacional sin ánimo de lucro
para el desarrollo de estándares relacionado con la tecnología de agentes (software
relacionado con el uso de agentes). Hasta la fecha ha producido 25 estándares, con otros 14 en
fase experimental y 3 más en una etapa preliminar. El núcleo de la actividad de FIPA sigue los
siguientes principios:
Tecnología de agente que provea de nuevos paradigmas para resolver antiguos y
nuevos problemas.
41
Dichas tecnologías deben alcanzar un cierto grado de madurez.
El uso de esas tecnología requiere antes su estandarización
La estandarización debe mostrarse como posible y que provea mejores resultados con
respecto a otras estandarizaciones.
La estandarización del mecanismo interno de los agentes no es el principal objetivo, si
no la infraestructura y el lenguaje requerida para permitir cooperaciones abiertas.
La estructura actual de FIPA está dirigida por la Junta Directiva, cuyos miembros son
elegidos, estos se encargan de la estrategia general de la organización y gestión
administrativa. La creación de grupos técnicos para el desarrollo de especificaciones concretas
está gestionada por la Junta de Arquitectura de FIPA (FAB – FIPA Arquitecture Board), cuyos
miembros son designados por la Junta Directiva. El trabajo de los grupos técnicos es dirigido
por Comités Técnicos (TCs – Technical Committees), que se crean al mismo tiempo que el
grupo técnico y se disuelve cuando termina el desarrollo de la especificación. Además Grupos
de Trabajo (WGs – Work Groups) se forman para la discusión de problemas técnicos y
establecer el marco de trabajo antes de formar el TC. Y por último Grupos de Intereses
Especiales (SIGs – Special Interest Groups) se forman se manera ocasional para la discusión de
cuestiones relacionadas con FIPA que no están ligadas al desarrollo de especificaciones
técnicas.
El modelo de comunicación FIPA puede ser separada en múltiples capas siguiendo el
ejemplo de OSI o TCP/IP. Dichas capas son:
Transporte: Define el protocolo de transporte, FIPA ha definido protocolos de
transporte de mensajes como IIOP, WAP y HTTP.
Codificación: Define múltiples representaciones y codificaciones del mensaje utilizando
estructuras de alto nivel como XML, String y Bit-Efficient.
Mensaje: La estructura del propio mensaje es independiente del método de
codificación empleado para mejorar la flexibilidad. Pero siguen existiendo parámetros
necesarios tales como el destino, origen, tipo de mensaje, time-out, etc.
42
Ontología: Los términos contenidos en la cabecera de los mensajes. Representa el
lenguaje que se emplea en el mensaje para que el destino pueda interpretarlo
correctamente, siempre que conozca la ontología.
Expresión del contenido: El contenido del mensaje puede estar en cualquier forma, ero
FIPA recomienda el uso de fórmulas lógicas generales y expresiones algebraicas para
enlazar contenido. El lenguaje más usado a la hora de expresar el contenido es FIPA-SL,
que utiliza expresiones como: not, or, implies, equiv, etc., además expresiones
algebraicas como any y all.
Acto Comunicativo: Expresa el motivo de la comunicación, FIPA-ACL contiene 22
distintos, por ejemplo: inform, request, agree, etc.
Protocolo de Interacción: Los mensajes no suelen intercambiados en un entorno
aislado, sino formando parte de una secuencia de interacción. FIPA define varios
protocolos de interacción especificando secuencias típicas de intercambios de
mensajes como por ejemple request, cuya interacción consiste en un agente hace una
petición y debe recibir la respuesta ya sea positiva o negativa.
43
Figura 13 Ejemplo Mensaje FIPA
Figura 14 Logo FIPA
44
45
Capítulo 4
REQUISITOS Y ORGANIZACIÓN
46
4.1 Introducción
En esta apartado se expondrán aquellas necesidades que este proyecto satisface o
dicho de otra forma los requisitos que este proyecto necesita cumplir, es necesario definir
dichos requisitos lo antes posible ya que permiten ver los objetivos del proyecto y una línea de
desarrollo clara.
Una vez definidos los requisitos se debe especificar la organización que se va a
mantener en ese proyecto, dicha organización consiste en especificar a todos los implicados en
el proyecto y su papel en el.
Por último con los requisitos y los implicados definidos es posible realizar una
estimación del coste del proyecto.
4.2 Requisitos
Los requisitos como se ha expuesto anteriormente representan los objetivos o
necesidades a cubrir por el proyecto. Para una fácil exposición y claridad de los mismos se ha
decidido representarlos mediante tablas con campos definidos y sencillos de entender.
SMSPA: Sistema Multiagente de Simulación de Parques de Aerogeneradores
47
Tabla 1 Requisito Interfaz de Usuario
HOJA DE REQUISITOS IDENTIFICACIÓN
Proyecto: SMSPA Jefe de proyecto: Jorge Luque Carrasco
REQUISITO
Fecha: 01/2014 Versión: 1.0 Estado: Aceptado Prioridad: Media
Título: Interfaz de Usuario
Identificador: R01 Categoría: Operacional
Descripción:
Como en cualquier plataforma, es necesario varios interfaces de usuario que permita al mismo
utilizar la plataforma.
Beneficios:
Permitir al usuario interactuar con la plataforma.
Comentarios y soluciones propuestas:
Desarrollo de una Interfaz que sea amigable y fácil de utilizar por el usuario.
Requisitos relacionados:
R03
Tabla 2 Requisito Base de Datos
HOJA DE REQUISITOS IDENTIFICACIÓN
Proyecto: SMSPA Jefe de proyecto: Jorge Luque Carrasco
REQUISITO
Fecha: 01/2014 Versión: 1.0 Estado: Aceptado Prioridad: Alta
Título: Base de Datos
Identificador: R02 Categoría: Funcional
Descripción:
Para el mantenimiento de todos los datos que requerirá la plataforma es necesaria la creación y
mantenimiento de una base de datos relacional.
Beneficios:
Mantener y utilizar todos los datos necesarios.
Comentarios y soluciones propuestas:
Crear una base de datos relacional.
Requisitos relacionados:
R03
48
Tabla 3 Requisito Gestor de Mantenimiento
HOJA DE REQUISITOS IDENTIFICACIÓN
Proyecto: SMSPA Jefe de proyecto: Jorge Luque Carrasco
REQUISITO
Fecha: 01/2014 Versión: 1.0 Estado: Aceptado Prioridad: Alta
Título: Gestor de Mantenimiento
Identificador: R03 Categoría: Funcional
Descripción:
Aplicación requerida para el lanzamiento de la simulación y poder interactuar con la base de
datos.
Beneficios:
Tener un enlace con la base de datos y con la simulación.
Comentarios y soluciones propuestas:
Crear una aplicación con dichas funcionalidades.
Requisitos relacionados:
R01, R02
Tabla 4 Requisito Plataforma de Simulación
HOJA DE REQUISITOS IDENTIFICACIÓN
Proyecto: SMSPA Jefe de proyecto: Jorge Luque Carrasco
REQUISITO
Fecha: 01/2014 Versión: 1.0 Estado: Aceptado Prioridad: Alta
Título: Plataforma de simulación
Identificador: R04 Categoría: Funcional
Descripción:
Plataforma de agentes que se encarguen de las tareas requeridas para la simulación.
Beneficios:
Poder Simular la evolución de un parque de Aerogeneradores
Comentarios y soluciones propuestas:
Desarrollar varios agentes que interactúen entre ellos.
Requisitos relacionados:
R01, R03, R05, R06, R07, R08, R09, R10
49
Tabla 5 Requisito Agente Central
HOJA DE REQUISITOS IDENTIFICACIÓN
Proyecto: SMSPA Jefe de proyecto: Jorge Luque Carrasco
REQUISITO
Fecha: 01/2014 Versión: 1.0 Estado: Aceptado Prioridad: Alta
Título: Agente Central
Identificador: R05 Categoría: Control
Descripción:
Agente necesario para el funcionamiento de una plataforma JADE.
Beneficios:
Poder registrar los agentes, administrar su comunicación y cerrar la simulación.
Comentarios y soluciones propuestas:
Desarrollo del Agente Central.
Requisitos relacionados:
R04
Tabla 6 Requisito Agente Monitorización
HOJA DE REQUISITOS IDENTIFICACIÓN
Proyecto: SMSPA Jefe de proyecto: Jorge Luque Carrasco
REQUISITO
Fecha: 01/2014 Versión: 1.0 Estado: Aceptado Prioridad: Alta
Título: Agente Monitorización
Identificador: R06 Categoría: Calculo
Descripción:
Agente necesario para el cálculo de la probabilidad de fallo del parque de aerogeneradores.
Beneficios:
Tener un cálculo actualizado de la probabilidad de fallo.
Comentarios y soluciones propuestas:
Desarrollo del Agente Monitorización.
Requisitos relacionados:
R04
50
Tabla 7 Requisito Agente Mantenimiento
HOJA DE REQUISITOS IDENTIFICACIÓN
Proyecto: SMSPA Jefe de proyecto: Jorge Luque Carrasco
REQUISITO
Fecha: 01/2014 Versión: 1.0 Estado: Aceptado Prioridad: Alta
Título: Agente Mantenimiento
Identificador: R07 Categoría: Fiabilidad
Descripción:
Agente necesario para aplicar el plan de mantenimiento seleccionado a la simulación.
Beneficios:
Dota a la simulación de realismo a largo plazo.
Comentarios y soluciones propuestas:
Desarrollo del Agente Mantenimiento.
Requisitos relacionados:
R04
Tabla 8 Requisito Agente Anomalías
HOJA DE REQUISITOS IDENTIFICACIÓN
Proyecto: SMSPA Jefe de proyecto: Jorge Luque Carrasco
REQUISITO
Fecha: 01/2014 Versión: 1.0 Estado: Aceptado Prioridad: Alta
Título: Agente Anomalías
Identificador: R08 Categoría: Control
Descripción:
Agente necesario para detectar anomalías en la información recibido e interactuar con el agente
Diagnostico.
Beneficios:
Control de información y enlace entre varios agentes.
Comentarios y soluciones propuestas:
Desarrollo del Agente Anomalías.
Requisitos relacionados:
R04
51
Tabla 9 Requisito Agente Diagnóstico
HOJA DE REQUISITOS IDENTIFICACIÓN
Proyecto: SMSPA Jefe de proyecto: Jorge Luque Carrasco
REQUISITO
Fecha: 01/2014 Versión: 1.0 Estado: Aceptado Prioridad: Alta
Título: Agente Diagnostico
Identificador: R09 Categoría: Análisis
Descripción:
Agente necesario para proporcionar inteligencia a la plataforma.
Beneficios:
Dotar a la plataforma de un motor de inferencia que simule el razonamiento humano.
Comentarios y soluciones propuestas:
Desarrollo del Agente Diagnostico.
Requisitos relacionados:
R04
Tabla 10 Requisito Agente Interface
HOJA DE REQUISITOS IDENTIFICACIÓN
Proyecto: SMSPA Jefe de proyecto: Jorge Luque Carrasco
REQUISITO
Fecha: 01/2014 Versión: 1.0 Estado: Aceptado Prioridad: Alta
Título: Agente Interface
Identificador: R10 Categoría: Visibilidad
Descripción:
Agente necesario para mostrar los resultados actualizados al usuario. Además de llevar un
registro de la probabilidad de fallo y los costes de la simulación.
Beneficios:
El usuario podrá ver los principales datos que le interesan en una sola ventana.
Comentarios y soluciones propuestas:
Desarrollo del Agente Interface.
Requisitos relacionados:
R04
52
4.3 Organización
A continuación se muestran las personas involucradas en este proyecto, en forma de
diagrama. Especificando lo responsables directos en la parte de arriba, a la derecha el
encargado de la supervisión de todo el proyecto y por último en la parte inferior aquellos
encargados de desarrollar el proyecto.
Miguel Ángel Sanz Bobi
Director de Proyecto
Rodrigo José de Andrade
Vieira
Director de Proyecto
Israel Alonso Martínez
Coordinador de Proyectos
Jorge Luque Carrasco
Jefe de Proyecto
Jorge Luque Carrasco
Diseñador
Jorge Luque Carrasco
Analista
Jorge Luque Carrasco
Programador
Figura 15 Organización del Proyecto
53
Ahora se especifican las responsabilidades de cada rol:
Director de Proyecto:
o Supervisa el trabajo desarrollado.
o Define los requisitos del proyecto y cuál será la metodología.
o Valora el trabajo desarrollado.
o Controla el avance del proyecto mediante reuniones con el Jefe de Proyecto.
Coordinador del Proyecto:
o Resuelve dudas sobre los entregables y fechas del proyecto.
o Valida el proyecto.
o Pone nota al proyecto.
Jefe de Proyecto:
o Ayuda al analista, diseñador y programador en sus materias correspondientes.
o Se reúne con los Directores del proyecto.
o Colabora en la documentación del proyecto.
Analista:
o Realiza el estudio inicial.
o Estudia el contexto de trabajo y todos los recursos disponibles.
o Realiza el análisis de requisitos.
54
o Participa en la especificación de objetivos y alcance del proyecto.
o Colabora en la documentación del proyecto.
Diseñador:
o Organiza la estructura de la base de datos.
o Realiza el modelo de dominio del sistema.
o Colabora en la documentación del proyecto.
o Define el cuaderno de carga del programador.
o Supervisa al programador.
o Diseño y especificaciones del sistema multiagente.
Programador:
o Implementa la base de datos.
o Implementa el cuaderno de carga.
o Realiza los puntos de programación de los agentes.
o Realiza los puntos de programación de la plataforma.
o Integración y pruebas de la plataforma.
o Realiza el manual de usuario.
55
Capítulo 5
DISEÑO Y DESARROLLO DE LA PLATAFORMA
56
5.1 Introducción
En este capítulo se explicará todo lo relacionado con la plataforma, los tipos de datos
que utiliza, como los utiliza y el porqué; los diferentes subsistemas presentes, su función y
cómo interactúan entre ellos.
5.2 Modelado de datos
Es necesario especificar con que datos va a tratar la plataforma y que tipo de datos
son; ya se ha mencionado que la información que se utiliza es del tipo de elementos de una
parque de aerogeneradores, cuyos componentes son los propios aerogeneradores, pero estos
a su vez están formados por componentes más internos (principalmente la multiplicadora, el
generador y las palas), que a su vez pueden tener asociados uno o más modos de fallo. A parte
de tener que modelar la relación de estos componentes, se debe tener en cuenta que la
relación más fuerte que tienen es la probabilidad de fallo (escala desde los modos de fallo
hasta el propio aerogenerador), por lo que si un aerogenerador tiene muchos componentes
con alta probabilidad de fallo se puede asegurar que el aerogenerador fallará.
Por este motivo se tiene que diseñar una estructura jerárquica de todos los
componentes (aerogenerador, multiplicadoras, generadores, modos de fallo, etc.), dicha
estructura es en forma de árbol, donde es importante la relación de cada elemento padre con
sus hijos, es decir, cada elemento del aerogenerador con los componentes que lo componen.
Para ello los elementos de la estructura jerárquica se intercalan con unos elementos llamados
conectores, que indican cual es la relación entre los elementos/componentes que se
encuentran por encima y por debajo del conector, teniendo un elemento por encima del
mismo y uno o varios por debajo.
57
La figura siguiente representa la estructura del parque aerogenerador utilizado para el
desarrollo y pruebas de la plataforma. El símbolo que les conecta representa el conector,
también llamado puerta.
Parque Aerogenerador
AG 17 AG 36
M 17
AM 17
FRM 17
AG 26
G 17 O 17
DFM 17
AG 17
TDG 17
TDC 17
AY 17
EAC 17
DP 17
DFM 26 AG 26
TDC 26
FS 26 AM 36
FRM 36
DFM 36
EAP 36
M 26 G26 O 26 M 36 O 36
FS 17
Figura 16 Estructura Ejemplo ParqueAerogenerador
58
A partir de esta figura se pueden observar los elementos conectores, o puertas, que
hay entre los componentes. En la plataforma del proyecto se han definido 3 tipos de
conectores distintos:
Conectores AND: Determinan una relación en serie entre los componentes, esto quiere
decir que la probabilidad de fallo del padre es el cálculo de la media de la probabilidad
de fallo de sus hijos.
Conectores OR: Determinan una relación en paralelo entre los componentes, esto
quiere decir que la probabilidad de fallo del padre es la inversa de la sumas de las
inversas de la probabilidades de fallo de sus hijos.
Puertas KdeN: En este conector no importa el cálculo de la probabilidad de fallo, si no
que detecte de los N hijos, K no hayan superado una probabilidad de fallo en
particular.
59
Una vez definida la estructura de datos se puede definir la configuración de los
aerogeneradores se debe pensar como pasar este modelo para que un programa escrito en
JAVA sea capaz de comprender dicha información guardad en un fichero y utilizarla en la
plataforma. Para ello se ha decidido utilizar un metalenguaje muy conocido en informática,
que también se ha utilizado para guardar la configuración de los agentes, este lenguaje se
llama XML o Extensible Markup Languaje. Este metalenguaje fue creado por el World Wide
Web Consortium, también conocido como W3C [WXML14], XML no lo que se dice un lenguaje
en sí mismo, sino más bien un lenguaje que permite definir otro lenguaje, esto se consigue
usando dos componente diferentes: el primero es un fichero XML donde se definen la
información de manera muy estructurada (es muy utilizado para la transferencia de
información en internet), después de tener este fichero se tiene otro con una extensión DTD,
que es el fichero que define el lenguaje del fichero XML, en la DTD se define la estructura que
debe tener el fichero XML.
Como se ha mencionado XML permite la definición estructurada de datos, que además
realiza de forma jerárquica (justo lo que necesita la plataforma). Se define un archivo XML que
no solo contendría los componentes del parque de aerogeneradores sino también toda la
información necesaria para los cálculos de la plataforma.
Figura 17 Ejemplo XML
60
5.3 Plataforma Multiagente
En este apartado se explicarán todos los elementos de la plataforma, tanto el lanzador
(Gestión de Mantenimiento) como cada uno de los agentes que integran la plataforma.
5.3.1 GESTION DE MANTENIMIENTO
Este programa no es ningún agente ya que no integra JADE, pero es un programa
necesario para lanzar los agentes que integran la plataforma y preparar los archivos necesarios
para su correcta ejecución, incluyendo el nombre inequívoco de la simulación para su posterior
guardado.
Figura 18 Gestión Mantenimiento
61
5.3.2 AGENTE CENTRAL
Es el primer agente en ser lanzado y el que tiene que funcionar siempre el primero, ya
que implementa el núcleo de JADE, sin este no funcionaría ningún otro agente, ya que se
encarga de mantener un registro de los agentes. También implementa los mecanismos para la
comunicación de los agentes entre sí, y por último crea automáticamente dos agentes
fundamentales en la plataforma, los agentes Agent Management System (AMS) y Directory
Facilitator (DF). Además de ser el agente que cierra la simulación mediante un botón.
Su funcionamiento consiste en una vez lanzado, creado los contenedores, el AMS y DF,
recibe peticiones de registro del resto de agentes (lanzados posteriormente), los registra y
comprueba que todo el registro se ha realizado de manera correcta (registrando además en la
base de datos a los agentes que lo requieren), que los agentes han sido designados al
contenedor correspondiente. Otras peticiones que recibe son la de comunicar la dirección de
agentes para que otros agentes puedan comunicarse por ello (EX: El agente de monitorización
del aerogenerador X necesita conocer que agente de anomalías se le ha asignado a dicho
aerogenerador para enviarle la información correspondiente a dicho agente de anomalías y no
a otro diferente).
Toda la información de inicio y registro se puede observar en la interfaz de usuario
diseñada para ello, además de la propia ventana de entorno jade que se crea al ejecutarse el
agente.
62
Figura 20 Interfaz Agente Central
Figura 19 Consola Agente Central
63
5.3.3 AGENTE MONITORIZACION
Es agente principal de la simulación, es el agente que realiza el cálculo de la
probabilidad de todos los componentes del aerogenerador, para ello simula el paso del tiempo
en meses. Dicha simulación del paso del tiempo es posible utilizando una herramienta de JAVA
denominada Timer, es parecido a un thread pero sin tener que realizar una gestión estricta.
Mediante este Timer se puede incluir en una tarea repetitiva que simula el paso de los meses y
por cada repetición calcular la probabilidad de fallo de los componentes.
Dicho cálculo se realiza utilizando lo explicado en el capítulo 2 de este documento.
Además al Timer se le ha incluido la posibilidad de que el componente pueda fallar de forma
estrepitosa, para ello se utilizan los datos obtenido del fichero para obtener la fecha más
probable y de manera aleatoria se elige un valor entre en 20% más y un 20% de dicha fecha.
A su vez también se realiza el cálculo de la efectividad de un mantenimiento sobre la
probabilidad de fallo y guarda ese estado para continuar la simulación del componente desde
ahí, por supuesto cada mantenimiento realizado sobre el componente aumenta el tiempo de
vida del mismo, desplazando la fecha del fallo especificado en el párrafo anterior.
Este agente envía la información sobre los componentes al agente anomalías, para su
análisis y proceso. También recibe información del agente de mantenimiento sobre los meses
en los que es necesario revisar los componentes, esta información se la traspasa al agente de
anomalías y espera su respuesta, una vez recibida la respuesta (si hay que realizar un
mantenimiento o no) ejecuta los métodos adecuados y envía el resultado al agente Interface
para que tenga constancia y pueda mostrar que en ese mes en particular se han llevado a cabo
acciones de mantenimiento, además de informar al agente de mantenimiento
correspondiente para que actualice los ciclos.
Aunque este agente no tenga interfaz gráfica es posible seguir su funcionamiento a
través de una ventana del sistema operativo creada por el entorno JADE.
64
Figura 21 Consola Agente Monitorización
5.3.4 AGENTE MANTENIMIENTO
Este agente es el encargado de llevar al cabo el control del mantenimiento, al igual que
el agente monitorización también tiene integrado una clase de Timer que simula el paso de los
meses. En cada ciclo, cada mes, comprueba respecto a los componente que monitoriza (solo 1
aerogenerador) si es necesario revisar dicho componente para deducir si hay que realizar un
mantenimiento o no. Para ello utiliza la variable ciclo (independiente para cada modo de fallo)
que se encuentra entre los múltiples parámetros del XML del fichero que se carga a la
simulación.
65
Al encontrar un componente que hay que revisar informa al agente de monitorización
correspondiente. Y cuando recibe el aviso de que cierto componente ha recibido un
mantenimiento preventivo o correctivo en un mes concreto, guarda esa información para
comenzar un ciclo en ese mismo mes (EX: el componente X cada 5 meses se debe revisar,
ciclo=5, el agente recibe un aviso de que se ha llevado a cabo un mantenimiento de dicho
componente el mes 12, en tal caso al siguiente vez que informara sobre la revisión de este
componente será el mes 17, 12+5).
Al igual que el agente de monitorización este agente no tiene interfaz, pero es posible
ver su ejecución funcionamiento a través de una ventana del sistema operativo creada por el
entorno JADE.
5.3.5 AGENTE ANOMALIAS
El agente de anomalías es el encargado de analizar la información sobre un
aerogenerador del resto de agentes y redistribuirla de manera adecuada, además de analizar y
almacenarla de manera temporal. Sirve de puente entre el resto de los agente (sin contar
Central).
Figura 22 Consola Agente Mantenimiento
66
Cada vez que recibe la información del agente de monitorización, la analiza en busca
de cualquier anomalía, actualiza la información que tiene guardada y envía al agente interface
la información de la probabilidad de fallo de los componentes.
Cuando recibe un aviso de mantenimiento de ciertos componentes, traspasa esa
información junto con la que tiene almacenada de la probabilidad de fallo al agente
diagnóstico para que devuelva la acción que se debería realizar sobre este componente,
información que luego envía a monitorización.
El agente de anomalías tiene tanto una ventana de consola como un interfaz de
usuario que te permite ver de manera rápida el estado básico del aerogenerador (si está bien,
hay componente cercanos al umbral de fallo o un componente lo ha superado o fallado)
mediante un semáforo con sus 3 luces, siendo verde todo es correcto, amarillo hay
componentes cercanos al umbral y rojo un componente ha fallado o ha superado el umbral.
Figura 23 Consola Agente Anomalias
67
5.3.6 AGENTE DIAGNOSTICO
Es el agente encargado de implementar el motor de inferencia desarrollado usando
CLIPSJNI, que tomará todas las decisiones sobre el plan de mantenimiento según la
información que recibe de anomalías. En este caso se tienen en cuenta 3 posibles respuestas:
1. No hacer nada, es decir, el componente no está cercano al fallo ni al umbral
asignado para garantizar su viabilidad, por lo que no es necesario realizar
ningún mantenimiento, ya que sería una pérdida de tiempo y dinero.
2. Realizar un manteniendo preventivo para alargar la vida del componente, esto
sucede cuando el componente ha superado el umbral fijado y, por tanto, su
eficiencia no es la deseada.
3. La última opción es realizar un mantenimiento correctivo, es decir cambiar el
componente, esto sucede cuando se detecta que el componente ha fallado,
que sucede según la fecha del fallo estrepitoso especificado en el apartado del
agente de monitorización.
Figura 24 Consola Agente Anomalias
68
Todo esto es posible gracias al uso del sistema experto integrado en el agente, como
se ha mencionado en el apartado de tecnologías se ha integrado el software CLIPSJNI para el
proceso de razonamiento y creación del entorno donde se ejecuta el sistema experto. Este
software necesita dos cosas para poder funcionar, primero una base de hechos no fija, la cual
se construye con la información recibida del agente de anomalías, y segundo, una base de
conocimiento, que es un conjunto de reglas que se extraen de la percepción del
funcionamiento de un aerogenerador y de su desarrollo. Las reglas son fijas y se guardan en un
fichero, cuyo contenido es el siguiente:
Una vez cargadas la reglas y los hechos en el programa CLIPSJNI este se ejecuta,
creando un fichero que contienen la base de hechos, tanto los recibidos como los inferidos en
el proceso de razonamiento, las reglas actividades y la respuesta del sistema experto al
razonamiento. Esta información es devuelta al agente de anomalías.
Este agente dispone de un interfaz en el cual se van mostrando las respuesta que el
agente obtiene tras la ejecución del proceso de razonamiento del sistema experto.
Figura 25 Reglas Agente Diagnostico
69
5.3.7 AGENTE INTERFACE
Este agente se encarga de mostrar al usuario toda la información centralizada del resto
de agentes. Tiene copia de la configuración de todos los aerogeneradores de la simulación (a
diferencia de anomalías, mantenimiento y monitorización que solo tienen información de la
configuración del aerogenerador asignado). Esto le permite mostrar la evolución de la
probabilidad de fallo y el coste de cada uno de ellos a lo largo del tiempo, y mostrar también
cuando se ha realizado un mantenimiento y que tipo de mantenimiento ha sido.
Otra función añadida es la de llevar actualizado el coste, a diferencia de la probabilidad
de fallo este no es complicado de calcular ni varia mes a mes, por lo que no es necesario crear
un agente que lo controle o asignárselo a monitorización. El agente interfaz al tener toda la
información de la configuración y recibir información sobre las probabilidad de fallo y los
mantenimientos es capaz hacer un cálculo sencillo y mantener una copia del coste a lo largo
del tiempo de los componentes.
Figura 26 Interfaz Agente Diagnostico
70
La funcionalidad del agente se divide en 4 formas (divididas por pestaña en el interfaz
de usuario del agente):
Pestaña Árbol: Muestra el árbol de la simulación, estructurado según los especificado
en el archivo XML cargado en la simulación, permite ver las gráficas de la probabilidad
de fallo de la simulación actual (de cualquier componente y no solo limitado a una
gráfica si no a las que el usuario quiera ver) y compararla con otras simulaciones
anteriores (con distinta configuración). Además de mostrar la jerarquía del propio
parque de aerogeneradores. Todos los gráficos generador por JFreeChart. En los
gráficos de probabilidad se pueden observar 2 cosas principalmente: La probabilidades
de fallo de la simulación actual (rojo) y las simulaciones que se han incluido para la
comparación (azul: prueba1, verde: prueba2); y los marcadores de la simulación actual
que indican los momentos en lo que se ha llevado una revisión (línea vertical amarilla),
un mantenimiento preventivo (línea vertical azul) y un mantenimiento correctivo (línea
vertical roja). Para seleccionar una gráfica solo hay que seleccionar el elemento con el
ratón para mostrarlo a la derecha o usar el botón derecho del ratón al seleccionar si se
quiere la gráfica en otra ventana, como se muestra a continuación:
Figura 27 Interfaz Arbol del Agente Interface
71
Pestaña Lista: Muestra la información más reciente sobre la probabilidad de los
componentes de un aerogenerador recibida.
Pestaña Coste: Lo mismo que Árbol pero con costes.
Figura 28 Interfaz Lista del Agente Interface
72
Pestaña Comparar: Permite seleccionar las simulaciones con las que se quiere
comparar la simulación actual y de esa manera poder comprobar la diferencia entre
varios planes de mantenimiento aplicados sobre un mismo aerogenerador.
Figura 29 Interfaz Coste del Agente Interface
73
Una cosa a tener en cuenta es que los gráficos se refrescan automáticamente, es decir,
se actualizan según llega nueva información sin necesidad de volver a seleccionar el
componente, pero solo por funcionalidad, es decir, si esta activa la pestaña árbol se
actualizarán las gráficas de probabilidad de fallo, y si esta activa la pestaña de costes entonces
se actualizarán las gráficas de costes.
Figura 30 Interfaz Comparar del Agente Interface
74
5.3.8 ESQUEMA DE COMUNICACIONES
A pesar de haberse explicado ya las comunicaciones tanto en el capítulo de tecnologías
como en los apartados anteriores, en este apartado se resumirán dichas comunicaciones en
forma de esquema, además de poner varios ejemplos de mensajes entre agentes para que se
pueda apreciar el formato e información que contienen.
En el siguiente esquema no se incluirán las comunicaciones con Central para simplificar
el esquema y que no sea especialmente confuso; ni las comunicaciones de control. Las
comunicaciones con central son exclusivamente registros, petición de una dirección de un
agente y el cierre de simulación.
INTERFACE
MANTENIMIENTO
MONITORIZACION
ANOMALIAS DIAGNOSTICO
Probabilidad de
Fallo de los
componentes
Petición de
Mantenimiento
Información sobre manteni-
miento realizado
Información sobre los compo-
nentes
Respuesta del sistema experto
Petición de
Mantenimiento
Respuesta del
sistema exper-
to
Información sobre los compo-
nentes
Información sobre manteni-
miento realizado
Figura 31 Esquema Simple de Comunicaciones
75
Y a modo de ejemplo se incluye un esquema de los mensajes que se envían. En el
siguiente se representa el envió de las probabilidades de fallo de los componentes desde
monitorización hasta anomalías. En el siguiente esquema/tabla se puede observar que todos
los mensajes tienen campos necesario: a quien va destinado el mensaje (Para), el motivo del
mensaje (Performative), la ontología para el muto entendimiento (Ontología) y por último el
contenido del mensaje, que a su vez se divide en 3 secciones: El tipo de agente que envía el
mensaje (TYPEDATOS), un número que lo identifica (int del sender) y el auténtico contenido
del mensaje (nombre del componente=error del componente-umbral del componente), cada
componente separado por “;” para poder dividirlos en destino utilizando métodos de gestión
de cadenas.
Tabla 11 Ejemplo de Mensaje
Para Anomalias
Performative INFORM
Ontología SIAM
Contenido TYPEDATOS Int del sen-der(TOMADEDATOS1+nunfile); “nombre=error-umbral;”;
76
77
Capítulo 6
PRUEBAS
78
6.1 Introducción
Una vez desarrollada la plataforma y probado de manera independiente cada
funcionalidad por separado y la transición entre éstas, es necesario realizar una serie de
pruebas para comprobar que la integridad de la plataforma es la deseada.
El objetivo de esta serie de pruebas es someter a la plataforma y a sus componentes a
una serie de verificaciones con el fin de garantizar un nivel de fiabilidad aceptable.
Una vez realizadas las pruebas se realizará la evaluación de la totalidad de las mismas,
en caso de obtener resultados positivos se procederá a la aceptación e implantación de la
plataforma. En caso contrario se deberá corregir el sistema, realizar de nuevo las pruebas y
evaluarlas, así hasta conseguir los resultados deseados.
6.2 Tipos de pruebas
Durante la programación y posterior a ésta se realizarán una serie de pruebas con el
objetivo de comprobar la funcionalidad y rendimiento requerido de la plataforma.
Previamente se habrá comprobado la fiabilidad y funcionalidad de los componentes que
forman el sistema por separado.
Los tipos de pruebas se pueden clasificar de la siguiente manera:
Pruebas de encadenamiento: Se verificará la transición y llamadas entre los distintos
componentes de la plataforma. Esta prueba se ha realizado monitorizando a bajo nivel
los datos y mensajes que se enviaban los distintos agentes entre sí, observando todo la
estructura del mensaje y sus componentes por separado; para ello se ha optado por
mostrar dicha información por consola utilizando el código adecuado. En la siguiente
figura se puede observar que se muestra el emisor de los mensajes y el contenido del
mismo.
79
Pruebas de integración: Tras verificar las llamadas y comunicaciones entre los
componentes de la plataforma se procede a integrar todos los componentes y
comprobar su integridad mediante pruebas de uso y tráfico como si de un usuario real
se tratase, buscando posibles brechas en la integridad de la plataforma que pasarán
por alto en las pruebas de pre-integración. Los resultados de estas pruebas se
demuestran observando el funcionamiento correcto de la plataforma.
Pruebas de explotabilidad del sistema: En estas pruebas se comprobará la facilidad
que tiene la plataforma para su explotación u operación.
Pruebas de sobrecarga: Verifican el correcto comportamiento del sistema ante los
estados de estrés en los que puede verse envuelto. Para la realización de esta prueba
se han ejecutado múltiples simulaciones con diferentes datos (cada uno más cargado
que el anterior), comprobando como sobrecarga al sistema el número de agentes que
se lanzan o la sobrecarga en la red por la comunicaciones entre los mismos.
Figura 32 Ejemplo de Prueba de Encadenamiento
80
Pruebas de recuperación: Pruebas realizadas con la finalidad de comprobar la
capacidad y reacción del sistema ante la pérdida de información. En este caso la
plataforma no es capaz de retomar la simulación desde el punto de fallo; sin embargo
toda la información generada durante la misma está segura y sin ningún tipo de daño,
a efectos prácticos está en el mismo estado que si el usuario hubiera cerrado la
simulación manualmente. Pruebas realizadas provocando el cierre de la plataforma
mediante el administrador de tareas y luego utilizando dicha simulación en la
comparación de simulaciones posteriores.
Pruebas de regresión: Realizadas durante toda la programación en busca de errores
de código o diseño originados por la modificación parcial posterior de los
componentes de la plataforma o la introducción de nuevos componente que
interactúan con los existentes. Este tipo de pruebas han sido las más frecuentes y su
procedimiento consistía en lanzar varias simulaciones diferentes y utilizar las
herramientas de las pruebas anteriormente descritas para volver a asegurar la
fiabilidad de la plataforma y comprobar la implementación de los nuevos elementos.
Pruebas de aceptación de usuario: En ocasiones están relacionadas directamente con
las pruebas de usabilidad. Estas pruebas las realiza el usuario final de la aplicación ya
sea en su entorno de trabajo o en un entorno de pruebas diseñado para tal fin, se
suelen realizar con el manual de usuario o del administrador. El objetivo de estas
pruebas en comprobar si el usuario final se siente satisfecho con la plataforma
desarrollado.
Pruebas de usabilidad: En ocasiones están relacionadas directamente con las pruebas
de aceptación de usuario. Estas pruebas las realiza el usuario final de la aplicación ya
sea en su entorno de trabajo o en un entorno de pruebas diseñado para tal fin, se
suelen realizar con el manual de usuario. El objetivo de estas pruebas en comprobar la
facilidad de uso de la plataforma desarrollada. Es posible incluso durante estas
pruebas realizar la formación del usuario en el uso del sistema.
81
Capítulo 7
IMPLANTACION
82
7.1 Introducción
Tras la realización de las pruebas, obteniendo resultados positivos, determinando la
integridad correcta de la plataforma se procede a la transferencia del software desarrollado al
centro de producción para llevar a cabo la explotación del sistema. La transferencia debe
prever la migración necesaria del software configurado a los equipos y estaciones de trabajo.
Las actividades que se deben abordar durante la implantación son diversas y distintas
entre sí.
Las diferentes partes del plan de implantación son:
Manual de implantación
Pruebas de implantación
Documentación final de proyecto.
7.2 Manual de implantación
En este apartado se detallan los pasos necesarios para la correcta implantación de la
plataforma. Dichas pasos son los siguientes:
Instalación de JAVA
Instalación de JADE
Instalación de CLIPSJNI
Instalación y configuración de MySQL
83
7.2.1 JAVA
Para la instalación de java es necesario bajarse primero java desde su página web
(https://www.java.com/es/download/). Una vez descargado, solo hay que ejecutar el .exe y
esperar a que finalice la instalación.
Para comprobar que java se ha instalado correctamente desde una consola de
comandos se puede ejecutar el comando java –version.
Figura 33 Instalación JAVA
84
7.2.2 JADE
Para la instalación de JADE es necesario bajarse JADE desde su página web
(jade.tilab.com). En este caso JADE es una carpeta con librerías, clases, ejemplos, demos, etc.
Mover la carpeta a algún directorio (por ejemplo C:/, se supondrá que se ha movido a esa
dirección), para la configuración de JADE es necesario crear variables de entorno. Para crear
variables de entorno ir a Panel de control\Sistema y seguridad\Sistema y dar click en la opción
configuración avanzada del sistema. Saldrá una ventana como la siguiente:
Figura 34 Consola JAVA
85
Hacer click en variables de entorno, en una variable de entorno denominada Path o
CLASSPATH (en caso de existir ambas hacerlo en ambas). Dar a Editar, en el valor de la variable
ir al final, escribir “;”para indicar que se va a incluir otro valor y escribir C:\jade\lib\jade.jar (o
donde este la carpeta\jade\lib\jade.jar).
Una vez modificado, en C:\User\X (el usuario del equipo) debería haber 2 ficheros:
APDescription y MTPs-Main-Container.
Figura 35 Configuración Avanzada del Sistema
86
Para comprobar la correcta instalación se entra en la consola (lo ideal para evitar
problemas de accesos en entrar en modo administrador) igual que en el caso java y se ejecuta
el comando java jade.Boot –gui . Al ejecutar el comando se abre la consola de administrador
del entorno JADE.
Figura 36 JADE Consola Comando
87
7.2.3 CLIPSJNI
Para que la plataforma pueda utilizar el motor de inferencia es necesario preparar el
equipo para reconocer CLIPSJNI. Primero se baja todo lo necesario (el archivo CLIPSJNI_0.3.zip
) en la siguiente pagina (http://sourceforge.net/projects/clipsrules/files/CLIPS/6.30/).
Dentro de zip que se encuentran varios archivos y carpetas que contienen, ejemplos de
código, el código fuente, librerías, y lo importante, un .dll (originalmente está hecho para
sistemas operativos de 32 bits, para sistemas operativos de 64 hay que convertirlo), dicho dll
hay que copiarlo en C:/windows/System32 (para Sistemas Operativos de 32 bits) o en
C:/Windows/SysWOW64 (para Sistemas Operativos de 64 bits).
Figura 37 JADE RAM GUI
88
7.2.4 MYSQL
Para instalar MySQL de la manera más rápida y sencilla es bajando el installer desde su
página web (http://dev.mysql.com/downloads/windows/installer/), este installer te permite
descargar e instalar cualquier producto MySQL (el fundamental es el Server ya que es
necesario un servidor para guardar la base de datos, y el workbench es muy útil ya que
permite acceder muchas funciones de MySQL e interactuar con el servidor mediante su
interfaz de usuario). Al instalar el MySQL Server te pedirá que crees un usuario y contraseña, el
usuario tiene que ser root para que la plataforma pueda crear una conexión con el servidor.
Una vez instalado MySQL se debe crear la base de datos que necesita la plataforma,
para ello se debe ejecutar un Statement con el código SQL necesario para la creación de la
base de datos y de las tablas.
Figura 38 Statement para la creación de la BD
89
7.3 Pruebas de implantación
Tras completarse la implantación sin incidencias se procede a realizar básicamente una
prueba final para determinar el éxito de la implantación.
Simplemente se prueba la plataforma en el entorno implantado y se comprueba que
no hay ninguna incidencia con ninguna de las tecnologías implantadas.
7.4 Documentación final del proyecto
Al finalizar el proyecto se debe asegurar que toda la documentación esté completa y
actualizada.
Esta documentación será de mucha utilidad en caso de futuras mejoras del sistema
implantado y de su mantenimiento o se podrán reutilizar componentes desarrollados durante
el proyecto en otros proyectos de área de conocimiento semejantes o incluso en áreas
completamente diferentes.
90
91
Capítulo 8
RESULTADOS
92
8.1 Introducción
Una vez explicado el diseño y desarrollo del sistema, como funciona cada subsistema y
explicar su implantación y pruebas, en este capítulo se presentará un caso ejemplo, en el que
se mostrarán 3 planes de mantenimiento diferentes y utilizando los datos que te proporciona
la plataforma comentar cual es el más adecuado y el porqué.
En dicho caso ejemplo se mostrarán las gráficas a nivel de parque aerogenerador, de
aerogenerador, componentes y modo de fallo. Sera una simulación a largo plazo (5 años)
donde se compararán las probabilidades de fallo y el coste a todos los niveles.
Se analizará el caso de un parque de aerogeneradores con 3 aerogeneradores (A, B,
C), cada aerogenerador tiene 3 componentes (Multiplicadora, Generador y Otros), cada uno
con modos de fallo diferentes: Multiplicadora (Avería multiplicadora, Disparo filtro
multiplicadora, fallo refrigeración multiplicadora); Generador (Avería Generador, Temperatura
disparo cojinete L.A., temperatura disparo generador); Otros (Avería yaw, Discrepancia Pitch,
Error accionamiento pitch, Fallo sincronización). No todas las multiplicadoras, generadores, etc
de cada aerogenerador tienen los mismo modos de fallo, ni la misma tasa de fallos (Constante
en el XML).
La hipótesis en la que se ha basado el proyecto desde el punto de vista de fiabilidad es
el considerar las tasas de fallo constantes y por tanto la función de fiabilidad es de tipo
exponencial. A modo de ejemplo se introducirá un gráfica que representa la evolución de la
fiabilidad del modo de fallo Averi Yaw del generador A.
93
Como se puede observar la probabilidad de fallo aumenta de manera constante
sufriendo varias revisiones a lo largo del tiempo (La línea vertical amarilla una fecha en la que
se ha revisado, no realizado un mantenimiento, el componente, dicha revisión tiene un coste
asociado). Y cuando la probabilidad ha superado el umbral especificado en el plan de
mantenimiento (50% en nuestro caso) se ha llevado un mantenimiento preventivo (línea
vertical azul, podría llamarse una reparación del componente, con su coste asociado), de
nuevo sigue pasando el tiempo y recibiendo revisiones, hasta que llega el mes 39 en el que el
componente falla (se ha mencionado en otros capítulos que se añadió la posibilidad de fallo
estrepitoso), en tal caso es necesario un mantenimiento correctivo (línea vertical roja,
reemplazar el componente, con su coste asociado).
Para este capítulo se utilizará solo 1 aerogenerador (el A) de los 3 introducidos en la
simulación, toda la información de los otros 2 aerogeneradores puede encontrarse en el Anexo
B Ampliación de Resultados, al final de este documento.
Figura 39 PF - Averia Yaw A
94
8.2 Planes de Mantenimiento
Se han creado 3 planes de mantenimiento diferentes (casos ejemplo) para hacer las
simulaciones en la plataforma, al final con la última simulación se compararán los 3. Las
diferencias entre las 3 estrategias de mantenimiento son las siguientes (para más información
sobre el significado de cada parámetro véase el Anexo A Manual de Usuario):
Inicial (llamado Prueba1 en la plataforma): A continuación se mostrarán los detalles de
modos de fallo del XML, que son lo que tienen los parámetros de cálculo de
probabilidad de fallo y de costes:
Barato (llamado Prueba2 en la plataforma): Para este se han reducido los ciclos,
reducido la efectividad del mantenimiento y en consecuencia reducido el coste del
mantenimiento preventivo.
Figura 40 XML Inicial_A
Figura 41 XML Barato_A
95
Caro (llamado Prueba3 en la plataforma): Para este se han aumentado los ciclos,
aumentado la efectividad del mantenimiento y en consecuencia aumentado el coste
del mantenimiento preventivo.
8.3 Ejecución de la plataforma
Una vez definidos los archivos con la configuración de los 3 planes de mantenimiento
se deben ejecutar primero la simulación 1 y 2 (con los archivos prueba1 y prueba2) y dejar que
pase el tiempo (este paso se va a omitir de poner imágenes de él ya que solo se pondrán
imágenes de la simulación prueba 3) para que la plataforma guarde información sobre dicho
planes para luego poder comparar los 3 planes de mantenimiento.
Una vez terminadas las simulaciones 1 y 2, se procede a ejecutar la simulación 3, para
ello se ejecuta la plataforma, se introduce el nombre de la simulación y se cargan los datos del
plan de mantenimiento prueba 3.
Figura 42 XML Caro_A
96
Una vez seleccionado el árbol los agentes deben lanzarse, para ello el usuario
solamente tiene que ejecutar lo comandos (pulsando la tecla enter) que aparece en la ventana
de consola. Y todos los agentes serán lanzados y sus interfaces y consolas saldrán en la
pantalla.
Figura 43 Nombre Simulacion
Figura 44 Seleccionar Árbol
97
Figura 46 Pantalla Inicial
Figura 45 Cargando los agentes
98
Una vez hecho esto ya se pueden ver todos los datos de los agentes y de la simulación,
pero en este caso ejemplo se mostrarán las gráficas al mismo tiempo la probabilidad de fallo y
coste y comentando una conclusión parcial de cada gráfica finalizando con una conclusión final
sobre los planes de mantenimiento implementados, para ello desde el agente interface se
expande el árbol de las pestañas Árbol y Costes y se eligen aquellos elementos cuyas gráficas
se quieren observar (haciendo doble click al elemento). El agente Interface que nos muestra la
información como se explicó en el capítulo 6 en el apartado del agente Interface, es el que está
a la izquierda superior de la pantalla, como se puede ver en el título de su ventana “Interface”.
8.4 Resultado Aerogenerador A
Antes de exponer los resultados y comentar hace falta aclarar que información
proporciona la gráfica (además de tener en cuenta que la simulación ha abarcado un total de 5
años):
Mantenimientos (estos solo estarán en los modos de fallo que es donde se aplican):
Aquí hay 3 líneas verticales, la amarilla indica revisión del modo de fallo, la azul que se
realiza un mantenimiento preventivo sobre el modo de fallo(es decir una reparación
sobre las piezas asociadas a ese modo de fallo), y la roja indica remplazo del modo de
fallo (es decir remplazo de las piezas asociadas a ese modo de fallo).
Información sobre el plan de mantenimiento inicial: Esta será la línea azul, e indicara la
probabilidad de fallo y el coste (según la gráfica) del resultado del plan de
mantenimiento inicial.
Información sobre el plan de mantenimiento barato: Esta será la línea verde, e indicara
la probabilidad de fallo y el coste (según la gráfica) del resultado del plan de
mantenimiento barato.
Información sobre el plan de mantenimiento caro: Esta será la línea roja, e indicara la
probabilidad de fallo y el coste (según la gráfica) del resultado del plan de
mantenimiento caro.
99
Se comienza por los modos de fallo de la multiplicadora:
En avería multiplicadora se puede observar que la probabilidad de fallo sigue un
patrón parecido en los 3 planes de mantenimiento, 2 revisiones y un mantenimiento antes de
que el componente falle, en este caso el componente falla antes siguiendo el plan de
mantenimiento de caro (es decir tiene menor tiempo de vida), mientras que con el plan barato
aguanta más y además observando la gráfica de coste es el plan que menor coste produce.
En disparo filtro multiplicadora se encuentra un patrón parecido al de avería
multiplicadora, pero con un mayor tiempo de vida del modo de fallo, a su vez en coste se
puede observar que el plan de mantenimiento barato sigue siendo la mejor opción.
Figura 47 Probabilidad y Coste AM A
Figura 48 Probabilidad y Coste FDM A
100
En disparo fallo refrigeración multiplicador no hay mucho que decir, como se puede
observar en la gráfica de probabilidad es un modo de fallo que es más habitual cambiarlo que
revisarlo o repararlo, los costes del mismo son muy estables siendo el plan inicial aquel que
ofrece mejores resultados económicos.
Para resumir lo visto relacionado con la multiplicadora, en el coste la mayoría del peso
se lo llevan avería multiplicadora, pero por su alto coste de mantenimiento, y disparo filtro
multiplicadora, que este se lo lleva por la cantidad de reemplazos que se hace a lo largo del
tiempo. Pero en cuanto tanto a fiabilidad como coste, se demuestra que el plan de
mantenimiento que más efectividad tiene es el plan barato.
Figura 49 Probabilidad y Fallo FRM A
Figura 50 Probabilidad y Coste M A
101
Ahora se pasa a los modos de fallo del generador:
En cuanto a avería generador su fiabilidad es buena, teniendo solo 1 o 2 reemplazos a
los largo de 5 años, por lo que su coste no es especialmente alto en ninguno de los 3 planes de
mantenimiento, sin embargo por una pequeña diferencia el que ofrece mejores resultados es
el plan de mantenimiento barato.
Figura 51 Probabilidad y Coste AG A
Figura 52 Probabilidad y Coste TDC A
102
En temperatura disparo cojinete, al igual que fallo refrigeración multiplicador, es un
modo de fallo con poco tiempo de vida, provocando que repare y reemplace en múltiples
ocasiones, proporcionado una fiabilidad muy similar en los 3 planes de mantenimiento, al igual
que el coste.
De nuevo se encuentra un modo de fallo con poco tiempo de vida, que requiere
múltiples reparaciones y remplazo, provocando un coste ascendente constante. Sin embargo a
pesar de que en fiabilidad muestran resultados similares los 3 planes de mantenimiento, en
coste se encuentra un claro de ganador, el plan de mantenimiento inicial, con un ahorro
cercano a los 2000€.
Figura 53 Probabilidad y Coste TDG A
Figura 54 Probabilidad y Coste G A
103
Para resumir lo visto relacionado con el generador, en el coste la mayoría del peso se
lo lleva temperatura disparo generador, que este se lo lleva por la cantidad de reemplazos que
se hace a lo largo del tiempo. En cuanto a coste se puede observar que los 3 planes son igual
de efectivos económicamente hablando, sin embargo en cuanto a fiabilidad el plan caro y el
inicial tiene un par de picos peligrosos (por encima del 20%) de probabilidad de fallo, luego el
plan más adecuado para el generador sería el plan barato.
Ahora se pasa a los modos de fallo de otros:
Para avería yaw en cuanto a fiabilidad los resultados son prácticamente idénticos con
diferencias de 1 o 2 meses en cuando a reparaciones y reemplazos para los 3 planes de
mantenimiento, sin embargo al observar costes se puede ver que el plan inicial es el más
adecuado con un ligero ahorro.
Figura 55 Probabilidad y Coste AY A
104
Aquí se puede observar de nuevo una fiabilidad paralela por los 3 planes de
mantenimiento con diferencia de 1 mes en cuando a sus reparaciones y reemplazos, haciendo
difícil elegir un plan de mantenimiento basándonos solo en eso. Pero al tener coste se puede
decidir que el mejor plan es el barato con un ahorro considerable de más de 1000€ con
respecto a los otros dos planes.
Figura 57 Probabilidad y Coste DP A
Figura 56 Probabilidad y Coste EAC A
105
Aquí se puede observar de nuevo una fiabilidad paralela por los 3 planes de
mantenimiento con diferencia de 1 mes en cuando a sus reparaciones y reemplazos, inclusive
entre el mes 41 y 57 (aprox.) su fiabilidad es idéntica, por lo que de nuevo para decidir el plan
la gráfica de costes será decisiva, y en este caso el plan caro es el más indicado por un ligero
ahorro.
En esta gráfica, a pesar del paralelismo de la fiabilidad, en cuanto a fiabilidad el plan
caro es el que más favorece la vida del modo de fallo y su fiabilidad, dato que además es
respaldado por la gráfica de costes, donde el plan caro resulta ser el más adecuado
económicamente hablando, por lo que conclusión sin lugar a dudas con este modo de fallo es
el plan de mantenimiento caro.
Figura 58 Probabilildad y Coste FS A
Figura 59 Probabilidad y Coste O A
106
Para resumir lo visto relacionado con otros, el coste está muy bien repartido entre
todos los modos de fallos, de esta manera se puede deducir que ningún modo de fallo es
problemático o innecesario de gestionar. En la fiabilidad, lamentablemente hay un pico algo
peligroso durante el mes 23 independientemente del plan de mantenimiento, pero no es
excesivamente grave. En cuanto a coste se puede observar que los planes barato y caro tienen
un coste muy similar, con la única diferencia durante el segundo año en el cual el caro tiene un
coste superior, por lo que si el plan se efectuara durante 2 año el plan barato sería la opción
ideal, en caso de que se alargara cualquiera de los dos sería adecuado.
Esta es la gráfica del aerogenerador, en el se puede ver que en cuanto a fiabilidad el
más inestable de los tres planes es el plan caro siendo el más estable el plan barato, que unido
a que en la gráfica de costes todos los planes producen costes y que en gran parte de los
modos de fallo y componentes se ha podido notar que el plan barato daba bueno resultados
en muchos casos tanto en fiabilidad como en costes, dicho plan sería el elegido para este
aerogenerador.
Figura 60 Probabilidad y Coste A A
107
Para finalizar este capítulo se muestra la gráfica del parque de aerogeneradores, tanto
en fiabilidad como en coste.
Figura 61 Probabilidad y Coste PA
108
109
Capítulo 9
CONCLUSIONES Y FUTURAS MEJORAS
110
9.1 Conclusiones
Tras el desarrollo de la plataforma se han llegado a un conjunto de
conclusiones que se expresan continuación.
La primera es que al integrar la inteligencia artificial resulta posible tratar problemas
complejos de mantenimiento y simulación como el que ha sido desarrollado en este proyecto.
Esta inteligencia artificial ha permitido realizar razonamiento y análisis sobre el estado de
aerogeneradores, ya sea utilizando agentes o el sistema experto integrado en uno de ellos,
permitiendo al usuario al capacidad de planificar o desarrollar estrategias de mantenimiento
de manera efectiva. Gracias a su uso se han podido definir las claves de las estrategias de
mantenimiento reduciendo su complejidad a nivel de programación.
Se ha podido obtener un conocimiento más detallado del funcionamiento de un
aerogenerador, su importancia y expansión en el sector energético, gracias al estudio inicial
que se realizó sobre el mismo para poder crear de manera realista la estructura jerárquica que
se utiliza como base de la simulación. Otro conocimiento adquirido es sobre la fiabilidad, su
importancia en el sector industrial, la gran cantidad y esfuerzos de estudios estadísticos que
hay detrás de ella en pos de obtener un máximo rendimiento. Usando estos conocimientos se
ha podido dotar a la agente de la “inteligencia industrial” necesaria para que comprendan su
función y conozcan como ejecutarla, además de poder desarrollar e implementar las reglas y
hechos necesarios para el correcto funcionamiento del motor de inferencia.
En la realización de este proyecto se han profundizado y utilizado los conocimientos
adquiridos durante la carrera, así como un entrenamiento para la realidad profesional que se
encontrará al finaliza la carrera. Permitiendo obtener más experiencia en resolución de
problemas, gestión del tiempo, creatividad de programación, a su vez de experimentar lo que
es desarrollar un proyecto de un tamaño superior a cualquiera visto durante la carrera, y ser
dirigido y ayudado por otros con más experiencia. Experiencia que se repetirá en múltiples
ocasiones a lo largo de la carrera profesional.
111
En lo referente a los objetivos planteados al principio, se han cumplido en mayor o
menor medida todos los objetivos, dando como resultado final aquello que se buscaba, una
plataforma multiagente que permita al usuario libertad en la creación de la estructura de los
archivos de la simulaciones, como una escalabilidad, ser capaz de comparar diferentes planes
de mantenimiento sobre una misma estructura en busca de sus resultados tanto individuales
como colectivos, dando la información necesaria para poder desarrollar planes flexibles.
9.2 Futuras mejoras
Dentro del ámbito de la simulación se podrían añadir varias mejoras enfocadas tanto
en el propio cálculo como en la interacción del usuario con la plataforma. En cuanto al cálculo
se podría desarrollar un modelo más complejo con más variables (como podría ser
temperaturas, velocidades de rotación de los componentes, etc.); en cuanto a la interacción un
posible mejora sería añadir un agente que introdujera eventos en la simulación (como
aumento repentino de temperatura, velocidad del viento excesivamente fuerte, terremoto,
etc.) y cómo afectaría eso a la probabilidad de fallo (además de que sería una mejora notable
en el motor de inferencia y el sistema experto) ; otra mejora sería implementar una segunda
aplicación que leyera los dataset dejado por las simulaciones para poder verlos sin necesidad
de ejecutar otra simulación de nuevo.
Ya fuera del ámbito de la simulación, este esquema de agentes y razonamiento podría
pasar al siguiente nivel y sustituir el agente de monitorización por un agente que estuviera
físicamente en los aerogeneradores recibiendo información a tiempo real de los sensores,
convirtiendo la plataforma de una simulación a un auténtico sistema de monitorización.
112
113
Capítulo 10
PRESUPUESTO
114
La puesta en marcha del sistema, requiere el uso de una serie de recursos, software
(conjunto de componentes lógicos necesarios para la realización de las tareas del sistema) y
hardware (requerido para el desarrollo y posterior explotación de la aplicación).
Lo que se busca en este apartado es realizar una estimación del presupuesto de la
implantación del sistema que se ha desarrollado en el proyecto. La valoración económica
abarca todos los puntos que influyeron en la realización del desarrollo. Los diferentes tipos de
costes son los siguientes:
Presupuesto del software: Costes relacionados con el software que se va a emplear.
Presupuesto del hardware: Costes relacionados con el hardware que se va a emplear.
Presupuesto del desarrollo: Se mostrarán todas las horas empleadas por el
desarrollador del sistema.
A continuación se mostrarán una serie de tablas que contienen los presupuestos
mencionados arriba junto con el presupuesto total.
115
Tabla 12 Presupuesto Software
RECURSO SOFTWARE TOTAL
JAVA (JRE y JDK) 0€
NetBeans 0€
JADE 0€
JFreeChart 0€
CLIPSJNI 0€
JDOM 0€
MySQL 0€
Licencia de Microsoft Office (cuatro años) Imputación del 25% sobre 569 €
142,25 €
Licencia Windows 7 64 Bits 119,99 €
TOTAL 262, 24 €
Tabla 13 Presupuesto Hardware
RECURSO HARDWARE TOTAL
Portátil Asus A53SV-SX041V 549,00 €
TOTAL 549,00 €
116
Tabla 14 Presupuesto Personal
PERSONAL Horas Coste Hora Coste Total
Directores del Proyecto 40 horas 40 € 1.600,00 €
Coordinador del Proyecto 5 horas 40 € 200,00 €
Jefe de Proyecto 20 horas 30 € 600,00 €
Analista 40 horas 25 € 1.000,00 €
Diseñador 50 horas 20 € 1.000,00 €
Programador 70 horas 15 € 1.050,00 €
TOTAL 5.450,00 €
Tabla 15 Presupuesto Total
COSTES TOTALES TOTAL
Costes Software 262,24 €
Costes Hardware 549,00 €
Costes Desarrollo 5.450,00 €
TOTAL 6.261,24 €
117
Anexo A
MANUAL DE USUARIO
118
En capítulos anteriores se ha explicado cómo funciona la plataforma y cómo
implementar, en este anexo se expondrán los conocimientos necesarios para crear los ficheros
XML necesario para la simulación, como configurar los ficheros de los agentes y donde se
almacena la información.
La estructura jerárquica de los ficheros de los aerogeneradores ya ha sido explicada en
este documento, además de ya haber introducido varias imágenes ejemplos. Así que aquí se
explicará brevemente el etiquetado necesario en el fichero y los parámetros que debe tener
cada etiqueta:
Figura 62 XML Simple
119
<?xml version="1.0" encoding="UTF-8"?> : Etiqueta inicial, simplemente indica la
versión de xml y el tipo de codificación. Es imprescindible tenerla para identificar que
es un xml.
<ParqueAeroGeneradores>: Es la raíz del árbol que se genera, dentro de esta etiqueta
se introducirán todos los datos del fichero. Termina con la etiqueta
</ParqueAeroGeneradores>.
<ConOR>: Conector, ya se ha explicado anteriormente que indica la relación entre el
contenido padre y sus hijos. Termina con la etiqueta </ConOR>.
<ViaEsp> o <Via>: Indica el siguiente nivel al parqueaerogeneradores, es decir los
Aerogeneradores. Termina con </ViaEsp> o </Via>. Los parámetros necesarios son:
o Nombre: Indica el nombre del aerogenerador.
<ComponenteEsp> o <Componente>: Indica el siguiente nivel al aerogenerador, es
decir los las piezas que los componen (Multiplicadora, Generador, etc.).Termina con
</ComponenteEsp> o </Componente>. Los parámetros necesarios son:
o Nombre: Indica el nombre del componente
<ModoFalloEsp> o <ModoFallo>: Indica el nivel de modo de fallo, es el nivel más bajo
de la estructura. Termina con </ModoFalloEsp> o </ModoFallo>. Los parámetros
necesarios son:
o Nombre: Nombre del modo de fallo.
o Constante: Variable utilizada para el cálculo de probabilidades además de
obtener la fecha inicial de fallo estrepitoso.
o Ciclo: Cada cuanto tiempo el plan de mantenimiento indica que se revise este
modo de fallo.
o Efectividad: Efectividad del mantenimiento preventivo en %.
o Revisión: Coste de revisar el modo de fallo.
o Preventivo: Coste del mantenimiento preventivo
120
o Correctivo: Coste del mantenimiento correctivo.
Una vez comprendido como crear el fichero necesario para la configuración del
parqueaerogeneradores para la simulación la siguiente fase es configurar el fichero xml de los
agente, la mayoría de campos/etiquetas de dichos ficheros no se deben modificar con una
excepción, la etiqueta <IP></IP>. El contenido entre dicha etiqueta debe ser el mismo para
todos los agente y el mismo contenido que el campo IP del fichero configCentral.xml.
El contenido de <IP></IP> debe ser la IP de la máquina donde se lanza el agente
central, esto se puede realizar de dos maneras: manual y automática. La manual es conociendo
la IP de la máquina y modificando el campo IP de los ficheros del resto de agentes. La
automática es ejecutando la simulación una vez, dicha simulación fallara si no se cumple lo
explicado en el párrafo superior, pero el fichero localizado en \resources\configCentral.xml
actualizara su campo IP automáticamente y entonces se deberá modificar manual el campo IP
de los ficheros del resto de agentes.
Las localizaciones de los ficheros de configuración del resto de agentes son las
siguientes:
General: \resources\configCentral.xml y \resources\config.xml
Anomalias: \bin\Anomalias\resources\config.xml
Central (también necesario configurar): \bin\Central\resources\config.xml y
\bin\Central\resources\configCentral.xml
Diagnóstico: \bin\Diagnostico\resources\config.xml
Figura 63 Ejemplo Conf Central
121
Interface: \bin\Interface\resources\config.xml
Mantenimiento: : \bin\Mantenimiento\resources\config.xml
Monitorización: \bin\Monitorizacion\resources\config.xml
Con todo esto la plataforma es configurada para poder ejecutarse correctamente. Así
que para finalizar se menciona donde se guardan los dataset utilizados para la creación de las
gráficas de la plataforma, en caso de que se quieran revisar post-simulación o por algún otro
motivos. Las simulaciones se guardan en \bin\Interface\simulaciones\nombre de la simulación.
122
123
Anexo B
AMPLIACION DE RESULTADOS
124
En este anexo se pondrán los resultados de los aerogeneradores B y C.
Aerogenerador B
Plan de Mantenimiento Inicial:
Plan de Mantenimiento Barato:
Plan de Mantenimiento Caro:
Multiplicadora + Modos de Fallo:
Figura 64 XML Inicial_B
Figura 65 XML Barato_B
Figura 66 XML Caro_B
Figura 67 Probabilidad y Coste DFM B
125
Generador + Modos de Fallo:
Figura 68 Probabilidad y Coste M B
Figura 69 Probabilidad y Coste AG B
126
Otros + Modos de Fallo:
Figura 71 Probabilidad y Coste TDC B
Figura 70 Probabilidad y Coste G B
127
Figura 73 Probabilidad y Coste FS B
Figura 72 Probabilidad Y Coste O B
128
Aerogenerador:
Aerogenerador C
Plan de Mantenimiento Inicial:
Plan de Mantenimiento Barato:
Figura 74 Probabilidad y Coste A B
Figura 75 XML Inicial_C
Figura 76 XML Barato_C
129
Plan de Mantenimiento Caro:
Multiplicadora + Modos de Fallo:
Figura 77 XML Caro_C
Figura 78 Probabilidad y Coste AM C
130
Figura 81 Probabilidad y Coste DFM C
Figura 80 Probabilidad y Coste FRM C
Figura 79 Probabilidad y Coste M C
131
Otros + Modos de Fallo:
Figura 82 Probabilidad y Coste EAP C
Figura 83 Probabilidad O C
132
Aerogenerador:
Figura 84 Probabilidad y Coste A C
133
Anexo C
BIBLIOGRAFIA
134
[ANDE07] Anders, G., Bertling, L., Cliteur G., Endrenyi, J., Jardine, A. & Li, W. Tutorial book on Asset Management - Maintenance and Replacement Strategies. IEEE Power Engineering Society General Meeting, Tampa, Florida, USA 2007.
[BARL09] Barlow, R.E. & Hunter, L. 1960.
Optimal preventive maintenance policies, Operations Research, 8: 90-100.
[BART09] Bartholomew-Biggs, M, Zuo, M. & Li, X. 2009.
Modelling and optimizing sequential imperfect preventive mainte-nance. Reliability Engineering & System Safety 94(1): 53-62.
[BELL04] Fabio Bellefemine, Giovanni Caire, Dominic Greenwood. 2004 Developing Multi-Agent System with JADE
[EPDI14] Pagina sobre temas informáticos http://www.elprofesionaldelainformacion.com/contenidos/1999/abril/agentes_inteligentes_definicion_y_tipologia_los_agentes_de_informacion.html
[FORT13] Fontúrbel Saez, Jorge Mejora del Mantenimiento de Aerogeneradores a partir del estudio de
su historial de eventos. [GOME12] Gómez Cayón, Pablo Sistema inteligente para la detección incipiente y el diagnóstico de
anomalías en los puestos de peaje automático de una autopista. [JARD06] Jardine, A.K & Tsang, A.H. 2006.
Maintenance, replacement, and reliability. Theory and applications. CRC Taylor & Francis.
[JFRC14] Pagina del proyecto JFreeChart –
http://www.jfree.org/jfreechart/
[LEVI09] Levitt, J. 2009. Handbook of Maintenance Management. Industrial Press.
135
[PROG14] Wiki sobre la programacion en JADE - http://programacionjade.wikispaces.com/Comportamientos
[WXML14] Wikipedia Artículo sobre XML
http://es.wikipedia.org/wiki/Extensible_Markup_Language