escuela tÉcnica superior de ingenierÍa (icai) · pfc: nomada ii trabajando en este sentido nomada...
TRANSCRIPT
PROYECTO FIN DE CARRERA
Desarrollo de un sistema multiagente para diagnóstico de componentes de trenes
Aplicación: NOMADA (Nodo Operacional Multi-Agente para el
Diagnóstico de Anomalías)
AUTOR: DIEGO PRIETO MARTÍN
MADRID, Junio del 2006
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA
Autorizada la entrega del proyecto del alumno/a:
Diego Prieto Martín
EL DIRECTOR DEL PROYECTO
Miguel Ángel Sanz Bobi
Fdo.: …………………… Fecha: / /
Vº Bº del Coordinador de Proyectos
Miguel Ángel Sanz Bobi
Fdo.: …………………… Fecha: / /
PFC: NOMADA
i
DESARROLLO DE UN SISTEMA MULTIAGENTE PARA
DIAGNÓSTICO DE COMPONENTES DE TRENES Autor: Prieto Martín, Diego
Director: Sanz Bobi, Miguel Ángel, Arranz Matía, Antonio
Entidad Colaboradora: Instituto de Investigación Tecnológica y Departamento de
Sistemas Informáticos, Universidad Pontificia Comillas.
RESUMEN DEL PROYECTO
El mantenimiento de vehículos de transporte es de especial importancia, no sólo por el
coste que conlleva su aplicación a la gran cantidad de ellos en cada flota, sino por la
función social del servicio de transporte público, que requiere: fiabilidad, disponibilidad
y calidad de uso.
Los medios de transporte público son esenciales en la vida diaria, de ahí que su
disponibilidad sea un factor muy importante a tener siempre presente. Por otra parte, esa
necesidad obliga a disponer de flotas con un número suficiente de vehículos para, por
un lado, satisfacer la demanda y, por otro, cubrir posibles indisponibilidades debidas a
fallos. Para asegurar la disponibilidad de una flota de vehículos es necesario aplicar un
plan de mantenimiento adecuado a la prevención de fallos y con un impacto mínimo
tanto en el coste como en la fiabilidad y disponibilidad de los vehículos. Trabajando en
este sentido, es de vital importancia conocer el estado de salud de los componentes, ya
que éste es el mejor fundamento para establecer un plan de mantenimiento predictivo y
es con este propósito con el que ha sido concebida y desarrollada la aplicación que
concierne a este proyecto NOMADA (Nodo Operacional Multi-Agente para el
Diagnóstico de Anomalías). El sistema ha sido probado con datos provenientes de
unidades UT -450 de Cercanías RENFE.
Este proyecto se concreta en el diseño de una plataforma distribuida para soportar el
sistema y en el desarrollo de los agentes diagnóstico de su sistema multiagente.
PFC: NOMADA
ii
Trabajando en este sentido NOMADA ha sido diseñado como un sistema formado por
cinco aplicaciones independientes que cooperan entre sí bajo una arquitectura 3-tier.
Las aplicaciones requeridas por NOMADA son las siguientes: una aplicación dedicada
a recoger las medidas del exterior, otra que trate esa información para evaluarla e
inferir diagnósticos sobre los resultados obtenidos, y una que se encargue de mostrar
los resultados al usuario. Además, se hace necesaria una herramienta específica de
configuración del sistema y una aplicación que permita la comunicación de todas
estas aplicaciones independientes y sirva de vínculo entre ellas y la base de datos
(medio persistente).
En la siguiente figura se muestra la estructura del sistema y con quién se relaciona cada
una de las aplicaciones:
Diagrama funcional de NOMADA
Cada uno de los módulos que se muestran en la figura se explican a continuación:
InfoService: Servidor de información para el resto de aplicaciones del sistema,
se encarga de la recepción, preprocesado, publicación y almacenamiento
persistente de la información del sistema.
PFC: NOMADA
iii
Plan Information Entry (PIEntry): Aplicación con interfaz gráfica para la
introducción de información en el sistema. El usuario es capaz de indicar en
qué fichero se encuentran las entradas y la aplicación va cargando éstas
periódicamente.
Knowledge Management Application (KMA): Aplicación con interfaz
gráfica para la incorporación y gestión del conocimiento, tanto la definición
de la unidad de tren como la incorporación de modelos, reglas y diagnósticos.
Se dirige a un usuario administrador de NOMADA.
Multi-Agent System (MAS): Sistema multi-agente distribuido para la detección
de anomalías (agente evaluador de modelos) y elaboración de diagnósticos
(agente diagnóstico). Este proyecto ha tratado la parte relacionada con la
inferencia de diagnósticos y la arquitectura general del sistema.
Diagnostic Application (DA): Aplicación con interfaz gráfica para la
visualización del estado actual de la unidad, las anomalías detectadas y los
diagnósticos emitidos. Este proyecto ha tratado la parte relacionada con la
visualización de diagnósticos.
Persistencia (BBDD): Implantación como mecanismo de persistencia de una
base de datos relacional para el almacenamiento de las bases de hechos (estática,
dinámica e histórico) y de la base de conocimientos (reglas y diagnósticos).
Se han utilizado para el desarrollo del proyecto las tecnologías .NET de Microsoft (el
lenguaje utilizado ha sido C#), en combinación con una metodología basada en UML.
Para el desarrollo Web del aplicativo se ha utilizado ASP.NET.
Gracias, tanto a la estructura general de sistema, como al diseño de cada uno de los
módulos que la compone, se ha conseguido crear un programa flexible que permite, de
manera sencilla, ampliar el dominio de conocimiento del mismo e incluso aplicarlo a
otras áreas de conocimiento distintas de la tratada.
PFC: NOMADA
iv
Concluyendo, el sistema NOMADA trata de dar un paso más allá del desarrollo de
sistemas expertos basados en agentes introduciendo en este campo algunas técnicas del
software de última generación tales como servicios Web, business objects, agentes,
inteligencia distribuida, etc. Este enfoque, refuerza el modelo metodológico y
conceptual que se están llevando a cabo en aplicaciones similares. Dando lugar al
fomento del desarrollo de este tipo de sistemas.
PFC: NOMADA
1
Contenido
1 Introducción ...................................................................................................................4
2 Objetivos ........................................................................................................................9
2.1 Objetivo principal ...................................................................................................9
2.2 Objetivos derivados...............................................................................................11
2.3 Objetivos adicionales ............................................................................................13
2.4 Restricciones .........................................................................................................13
3 Arquitectura de la aplicación .......................................................................................15
3.1 Arquitecturas distribuidas .....................................................................................15
3.2 Arquitectura distribuida en NOMADA.................................................................20
3.3 Módulos de la aplicación ......................................................................................23
4 Modelo de Datos (DataModel) ....................................................................................27
4.1 Especificación del modelo de datos NOMADA ...................................................29
4.2 Componentes del modelo de datos........................................................................32
4.2.1 Base ................................................................................................................33
4.2.2 Componentes..................................................................................................34
4.2.3 Variables ........................................................................................................38
4.2.4 Relaciones ......................................................................................................43
4.2.5 Reglas.............................................................................................................47
4.2.6 Modelos..........................................................................................................51
4.2.7 Configuración.................................................................................................54
5 InfoService ...................................................................................................................57
5.1 Servicios (WSInfoService)....................................................................................60
5.1.1 WSPIE............................................................................................................60
5.1.2 WSMAS .........................................................................................................60
5.1.3 WSDM ...........................................................................................................61
5.2 Controlador de datos (DataManager)....................................................................61
5.3 Preprocesador (Preprocessor)................................................................................65
6 Sistema Multi-Agente (MAS, Multi-Agent System) ...................................................67
PFC: NOMADA
2
6.1 Agente ...................................................................................................................67
6.2 Sistema multiagente ..............................................................................................72
6.3 Plataforma multi-agente ........................................................................................76
6.3.1 Directorio (AgentRepository) ........................................................................76
6.3.2 Sindicación (PlatformSyndication) ................................................................79
6.3.3 Controlador de infraestructura (InfrastructureManager)................................82
6.3.4 Plataforma / Servicio (AgentPlatform) ..........................................................85
6.4 Agentes del sistema...............................................................................................87
6.4.1 Estructura de los agentes................................................................................88
6.4.2 Agente diagnóstico (AgentDiagnostic) ..........................................................89
6.4.3 Sistema experto ..............................................................................................93
7 Plan Information Entry (PI Entry)................................................................................96
7.1 Especificación de la implantación.........................................................................96
7.2 InterfazPI...............................................................................................................98
7.2.1 Main ...............................................................................................................98
7.2.2 Wizard ..........................................................................................................100
7.2.3 Wizard2 ........................................................................................................101
7.3 ModuloEntrada....................................................................................................102
7.3.1 Implement ....................................................................................................102
7.3.2 OtherDataFile...............................................................................................103
7.3.3 RMSDataFile ...............................................................................................103
7.3.4 Propiedades ..................................................................................................103
7.3.5 Eventos.........................................................................................................104
7.4 Formato de los ficheros.......................................................................................105
8 Diagnostic Analyzer (DA) .........................................................................................107
8.1 Especificación de la implantación.......................................................................109
8.2 DA.ui...................................................................................................................111
8.2.1 DiagnosticsManager.....................................................................................111
8.2.2 DiagnosticHistoryForm................................................................................112
8.2.3 DiagnosticTraceInTreeForm........................................................................113
8.3 DA.data ...............................................................................................................116
8.3.1 GeneralStatus ...............................................................................................116
PFC: NOMADA
3
8.3.2 DiagnosticTrace y DiagnosticElementalTrace.............................................116
8.4 DA.tools ..............................................................................................................117
8.4.1 LoggerAplication .........................................................................................118
8.5 DA.Infoservice ....................................................................................................118
8.5.1 WSDM .........................................................................................................118
9 Base de datos..............................................................................................................120
9.1 Base de datos de NOMADA...............................................................................121
9.1.1 Tablas de configuración ...............................................................................123
9.1.2 Tablas dinámicas..........................................................................................140
9.1.3 Gestión de históricos ....................................................................................149
10 Presupuesto del proyecto..........................................................................................151
10.1 Mediciones ........................................................................................................151
10.2 Precios unitarios ................................................................................................152
10.3 Sumas parciales.................................................................................................152
10.4 Presupuesto general...........................................................................................155
10.5 Licencias de software necesarias ......................................................................156
10.5.1 Licencias para el desarrollo........................................................................156
10.5.2 Licencias para la implantación...................................................................156
11 Conclusiones ............................................................................................................157
Referencias....................................................................................................................160
R1 Bibliografía..........................................................................................................160
R2 Referencias Web..................................................................................................162
Anexo A: Métodos accesibles desde WSPIE................................................................164
Anexo B: Métodos accesibles desde WSMAS .............................................................168
Anexo C: Métodos accesibles desde WSDM................................................................172
Anexo D: Base de datos de ISPMAT............................................................................180
PFC: NOMADA
4
1 Introducción
El mantenimiento de vehículos de transporte es de especial importancia, no sólo por el
coste que conlleva su aplicación a la gran cantidad de ellos en cada flota, sino por la
función social del servicio de transporte público, que requiere: fiabilidad, disponibilidad
y calidad de uso.
Los medios de transporte público son esenciales en la vida diaria, de ahí que su
disponibilidad sea un factor muy importante a tener siempre presente. Por otra parte, esa
necesidad obliga a disponer de flotas con un número suficiente de vehículos para, por
un lado, satisfacer la demanda y, por otro, cubrir posibles indisponibilidades debidas a
fallos. Para asegurar la disponibilidad de una flota de vehículos es necesario aplicar un
plan de mantenimiento adecuado a la prevención de fallos y con un impacto mínimo
tanto en el coste como en la fiabilidad y disponibilidad de los vehículos. Trabajando en
este sentido, es de vital importancia conocer el estado de salud de los componentes, ya
que éste es el mejor fundamento para establecer un plan de mantenimiento predictivo y
es con este propósito con el que ha sido concebida y desarrollada la aplicación que
concierne a este proyecto NOMADA (Nodo Operacional Multi-Agente para el
Diagnóstico de Anomalías).
La aplicación NOMADA ha sido diseñada para usar la información proveniente de
diversos sensores para, primero, ver si se detecta funcionamiento anómalo en alguno de
los componentes y, a continuación (en caso afirmativo), investigar la raíz del problema
e informar al usuario de lo que pasa y, si se puede, qué acción se debe realizar. Para
descubrir anomalías, el sistema utiliza como referencia modelos de comportamiento
normal (perceptrones y modelos lineales) y mapas autoorganizados (mapas de
Kohonen), obtenidos a partir de ensayos y análisis previos de datos en los componentes
a diagnosticar. Los modelos se han desarrollado utilizando técnicas de redes neuronales.
Finalmente, un sistema experto basado en reglas y factores de certeza se encarga de
diagnosticar la posible causa de las anomalías. NOMADA esta diseñado para el
PFC: NOMADA
5
diagnóstico inmediato tras la recepción de nueva información, bien sea con el tren en
servicio o en taller.
Como se puede ver en el párrafo anterior el uso específico de NOMADA es el
mantenimiento de componentes de trenes, aunque su diseño permite que con ligeras
modificaciones se adecue a casi cualquier tipo de vehículo e incluso a plantas o
instalaciones industriales.
Esto hace que nuestro proyecto cobre una mayor relevancia, dado que, según fuentes del
INE (Instituto Nacional de Estadística), el uso de trenes de cercanías se ha visto
incrementado en un 4,36% respecto al año anterior.
Así, podemos definir a NOMADA como una aplicación de mantenimiento predictivo
desarrollada para ALSTOM transporte, con la colaboración de RENFE. Actualmente la
aplicación ha sido probada con un componente del tren, el compresor, pero su diseño
permite la incorporación de otros componentes sin necesidad de modificar su estructura
interna. Los datos recogidos para probar el sistemas provienen de trenes de cercanías
modelo UT-450.
Figura 1.1 – Tren de Cercanías UT-450
PFC: NOMADA
6
Las características y atributos, más relevantes, de las unidades tratadas de estos trenes
se muestran a continuación:
Características básicas Tensión de alimentación: 3.000 Vcc
Anchura de vía:1.668 mm
Potencia en régimen continuo: 2.960 kW
Velocidad máxima: 140 Km/h
Aceleración de arranque: 0,62 m/s2
Aceleración entre 0 y 60 KM/h: 0,50 m/s2
Aceleración entre 0 y 140 Km/h: 0,25 m/s2
Deceleración máxima: 0,9 m/s2
Arranque en rampa de 35 CO
Conducción con velocidad prefijada: Sí
Sistemas de freno La UT posee los siguientes sistemas de freno:
Freno eléctrico de recuperación y/o reostático, con preferencia del primero sobre el segundo.
Freno neumático.
Freno de servicio, eléctrico y/o neumático, tipo "blending", con preferencia delprimero sobre el segundo.
Freno de estacionamiento por muelle acumulador.
El freno de servicio es combinado, eléctrico y/o neumático y recupera energía enla medida en que catenaria lo admita.
Dimensiones, pesos y plazas (M) (R) (M-4R-M) Dimensiones en (mm)
PFC: NOMADA
7
Longitud entre enganches 26.900 26.400 159.400Anchura exterior 2.926 2.926 Altura máxima sobre el carril 4.300 4.300 Altura del piso de plataforma sobre el carril 1.010 1.010
Peso (en T) Tara 70,2 52,6 350,8Carga normal 86,9 76,8 481,0 Plazas
Sentadas 128 188 1.008
De pie
Equipos auxiliares Equipo eléctrico auxiliar:
Convertidor estático: Cada coche dispone de un convertidor estático de 3.000Vcc/380 Vca, 3 fases 50 hz/72 Vcc de 120/85 KVA (8 motriz/remolque).
Batería: Cada coche dispone de una batería de Ni-Cd de 72 Vcc de una capacidad de 73/112 Amp/h 8motriz/remolque) que alimenta los circuitoseléctricos de baja tensión y el alumbrado de socorro.
Producción de aire: Dispone de un compresor principal rotativo de tornillo con unaproducción de 2.000 litros/min, de un compresor auxiliar y de un secador de aire.
Otros equipos
Central de Información del maquinista.
Sistema de Información al viajero, acústico y visual
Teleindicaciones exteriores
Megafonía y música ambiental
Antibloqueo
Central de seguridad
Asta
Engrasador de pestaña
PFC: NOMADA
8
24 puertas de acceso de viajeros, de accionamiento neumático.
Sistema de comunicación radio-telefónica con el Puesto de Mando de Circulación y con el Puesto de Control de Cercanías con tecnología GSM.
Enganche del tipo Couplomatic con acoplamiento mecánico, neumático y eléctrico, en testeros libres y tensor de enganche con testeros acoplados.
Para climatización cuenta con uno o dos equipos compactos (según sea motriz o remolque) con doble unidad acondicionada cada uno que proporcionarefrigeración y calefacción reforzándose en este modo con calentadores a niveldel piso de los departamentos.
Con esto se pretende mostrar que las UT-450 de tren son sistemas muy complejos y
grandes, y que mover una de estas unidades a un taller para realizar una revisión es una
tarea muy costosa tanto económicamente como desde un punto de vista funcional
(RENFE sólo dispone de una flota de 24 de estos trenes en Cercanías Madrid), ya que
cada vez que se lleva una máquina al taller, ésta queda fuera de circulación.
Es por este motivo que interesa tener una aplicación que nos permita conocer el estado
de los componentes en cada instante sin tener que llevarla a un taller para que sea
examinada como se hace actualmente.
La utilización de NOMADA permitirá tener un mejor conocimiento del estado de salud
de los componentes del tren de cercanías, permitiendo anticiparse al fallo y evitar
desmontajes innecesarios en taller, lo que sin duda repercutirá en una reducción de
costes y en una aplicación más eficiente del mantenimiento de las máquinas en cuestión.
Concluyendo, NOMADA es un sistema inteligente multiagente, resultado de técnicas de
redes neuronales combinadas con un sistema experto para diagnosticar el
funcionamiento de los componentes básicos de un tipo de tren de cercanías eléctrico,
con el propósito de realizar tareas de mantenimiento predictivo sobre ellos. Con este
objetivo, partiendo de la toma de medidas en ciertos puntos clave, podemos conocer el
estado de los componentes de la máquina en tiempo real, además, el sistema permite
mantener datos históricos de forma que se puedan realizar estudios comparativos de
entre los distintos ensayos de los componentes.
PFC: NOMADA
9
2 Objetivos
2.1 Objetivo principal
El objetivo del proyecto es el desarrollo de un sistema multiagente para la detección
y diagnóstico de anomalías en componentes de trenes. El sistema se probará con
unidades de tren del modelo UT-450 de Cercanías RENFE.
El proyecto completo recoge la detección y diagnóstico de anomalías para uno de los
componentes críticos de dichos trenes como es el compresor.
Este proyecto se concreta en el diseño de una plataforma distribuida para soportar el
sistema y el desarrollo de los agentes diagnóstico del sistema multiagente.
Dado lo complejo que resulta desarrollar modelos para la detección de anomalías, esto
constituye el objetivo de otro proyecto paralelo que, además, se encarga del desarrollo
del agente de detección de anomalías (o agente modelo) del sistema multiagente.
Del objetivo general citado anteriormente surgen una serie de requisitos que debe
cumplir nuestro sistema, estos son:
Arquitectura distribuida, dado que el sistema multiagente no recoge sólo la
parte de detección y diagnóstico de anomalías, si no que va desde que entran
los datos tomados de los sensores de la máquina o de las ficheros que
contienen las medidas de estos sensores hasta la fase de mostrar los resultados
al usuario, se hace necesario crear un sistema formado por varios módulos
distintos, uno de entrada de datos, otro que contenga el sistema multiagente en
sí mismo y uno que muestre al usuario los resultados inferidos por el sistema
multiagente. Cada uno de estos módulos no tienen por qué encontrarse
integrados en una misma aplicación, sino que la toma de datos puede hacerse
PFC: NOMADA
10
desde la propia unidad de tren mientras que el análisis de esos datos puede
estar en otro ordenador y la visualización de los resultados puede querer verse
en otra distinta.
Posibilidades de ampliación, dado que una UT-450 tiene más de un
componente crítico y el proyecto sólo abarca uno de ellos, un requisito
fundamental para el sistema es que sea posible agregar más componentes y
modelos sin necesidad de modificar el código de la aplicación. Para ello se
deberá pensar, no sólo en la estructura de datos necesaria para desarrollar la
detección y el diagnóstico de anomalías para el compresor, si no que se hace
necesario el proyectar un sistema suficientemente flexible para poder añadir
otros componentes. Esto afecta a todas las decisiones de arquitectura que
tomemos ya que debemos mirar dos pasos por delante de donde queremos
llegar.
Multiagente, esta característica del sistema se muestra de manera explícita en
el objetivo general. Dado que nuestro sistema va a estar compuesto por más de
un tipo de agente (como mínimo de dos, un agente de detección y otro de
diagnóstico) se hace necesario el uso de un sistema multiagente, que permita
definir tipos o roles de agentes (estos pueden estar prefijados) y la
comunicación entre ellos. Como el sistema debe ser ampliable es conveniente
que el número de agentes se cree de manera dinámica dependiendo del número
de componentes que vayamos a diagnosticar.
Los requisitos anteriores son de todo el sistema, pero este proyecto además de definir la
arquitectura alberga el desarrollo del agente de diagnóstico de anomalías (incluido en el
sistema multiagente), para el desarrollo de este agente concreto se han definido dos
objetivos:
Estructura común al del resto de agentes, se ha decidido que todos los
agentes tengan una estructura común, esto facilita, en parte, el desarrollo y la
integración posterior de los agentes en el sistema. Al otorgar al agente
PFC: NOMADA
11
diagnóstico una estructura equivalente al del resto de agentes, hacemos que
éstos sean un poco más ineficientes (puede haber módulos que podrían unirse
en vez de estar por separado), pero una de las grandes ventajas que tiene es
que facilita la comprensión del agente y, como ya se dijo antes, la integración
con el resto de la plataforma.
Motor de razonamiento hacia delante, se ha decidido que el agente
diagnóstico implemente un motor forward-chaining para inferir los
diagnósticos a partir de las reglas que le entren. Además otra característica es
que el agente diagnóstico debe hacer una transformación previa de los datos
que le entran (sus percepciones) para transformarlas en reglas. Otro de los
puntos que requieren los agentes diagnóstico es que sean capaces de
comunicarse, no sólo con los otros agentes del sistema, sino también entre
ellos.
2.2 Objetivos derivados
Del conjunto de objetivos principales anterior se derivan una serie de objetivos que se
deben realizar para conseguir lograr los anteriores. A continuación se exponen cada uno
de estos objetivos parciales:
Crear un soporte para el sistema, es esta fase se debe definir la arquitectura
global del sistema, es decir, por cuántas aplicaciones va a estar formado, cómo
se van a comunicar entre ellas y cual o cuales van a ser los medios persistentes
para guardar la información. Se ha decidido que el sistema esté formado por
tres aplicaciones que se comunican a través de un servicio Web, el medio
persistente principal para guardar la información de la aplicación será una base
de datos a la que se accederá mediante el servicio anteriormente mencionado
y, si las aplicaciones necesitan datos de configuración específicos para ellas,
estos se guardarán en ficheros de configuración con formato XML.
PFC: NOMADA
12
Diseño de módulos, se ha decidido dotar de una estructura general a cada una
de las aplicaciones de las que se compone la sistema. Esto facilita el desarrollo
y la comprensión cada una de esas aplicaciones, cogiendo de esa estructura
general aquellos módulos que se necesiten y omitiendo aquellos que la
aplicación no vaya a utilizar.
Crear el modelo de datos, uno de los módulos de los que se compone la
aplicación es, por motivos de eficiencia, un modelo de datos no persistente que
refleje la estructura de la base de datos de una manera avanzada. Este módulo
no es necesario que sea implementado por todas las aplicaciones, pero algunas
de ellas lo precisan.
Crear una aplicación de entrada de datos, debemos crear una aplicación de
entrada de datos para recoger los datos de los sensores colocados o de los
ficheros donde se encuentren las medidas recogidas de esos sensores.
Definir arquitectura del sistema multiagente, se debe definir la arquitectura
que tendrá el sistema multiagente con vistas a la integración de los agentes al
final del proyecto.
Crear agente diagnóstico, adecuándonos a la arquitectura general del sistema
multiagente, y dado que se ha determinado una arquitectura general para todos
los agentes, se debe desarrollar un agente de diagnóstico que, basándose en los
estímulos percibidos de los agentes modelo (que pertenecen al otro proyecto)
infieran las causas de por qué se han producido anomalías en los componentes.
Crear la parte del DA (Diagnostic Analyzer) que muestra la información
de los diagnósticos, se debe crear un interfaz gráfico que permita ver al
usuario los resultados de los diagnósticos inferidos en cada ensayo. El interfaz
también debe mostrar la parte concerniente a la detección de anomalías pero
esto se realiza en el proyecto que desarrolla los agentes de detección de
anomalías y los modelos. El interfaz debe mostrar los diagnósticos que se
PFC: NOMADA
13
producen en un momento dado, los diagnósticos que se han inferido a lo largo
de todo el ensayo y los diagnósticos que hayan sido inferidos en diagnósticos
pasados.
Integrar con el proyecto de detección de anomalías, como punto final del
proyecto, se integrará el agente diagnóstico y la parte del interfaz del DA
desarrollada para ver los diagnósticos inferidos y la aplicación de entrada de
datos en la arquitectura global del sistema así como con el resto de
componentes desarrollados por el otro proyecto.
2.3 Objetivos adicionales
Dada la arquitectura que se ha elegido para desarrollar el sistema, se han establecido
una serie de características que podrían implantarse en el sistema multiagente, éstas son
las siguientes:
Sistema distribuido, ya que debemos desarrollar un sistema multiagente, es
buena idea que ese mismo sistema pueda ser ejecutado a la vez entre varias
máquinas. Con este fin se ha desarrollado el sistema multiagente actual.
Balanceo de carga entre los sistemas multiagente de varias máquinas, que
el sistema sea multiagente no tiene mucho sentido si no somos capaces de
distribuir los agentes entre varios sistemas y que funcionen de manera
organizada para lograr su fin común. De esta manera, el sistema multiagente
debe poder repartir la carga entre todos los equipos de la red local que lo estén
ejecutando.
2.4 Restricciones
A continuación se muestran las restricciones para el desarrollo del sistema:
PFC: NOMADA
14
− La plataforma de desarrollo será Visual Studio .NET.
− El lenguaje de programación a usar es C#.
− El sistema debe funcionar en los sistemas operativos Windows.
PFC: NOMADA
15
3 Arquitectura de la aplicación
Para cumplir los objetivos propuestos del proyecto, ha sido necesario crear NOMADA
con una arquitectura de sistema distribuido.
Podemos definir arquitectura distribuida como una aplicación cuya funcionalidad
(servicios) y ejecución (procesos) se reparten entre diferentes entidades que operan de
forma simultánea. Dichas entidades pueden ubicarse en una misma máquina o
distribuidas en diferentes máquinas dentro de una red [COUL01].
Siguiendo esta definición, y como se adelantaba en el primer párrafo, el sistema
NOMADA presenta un arquitectura doblemente distribuida. En primer lugar, existen un
conjunto de aplicaciones independientes (KMA, PIEntry, DA, MAS e InfoService) que
interaccionan entre sí para cubrir todas las funcionalidades y requerimientos del sistema.
Estas aplicaciones trabajan, en cierto modo, de forma independiente para cubrir un fin
común, más adelante veremos para qué sirve cada una de estas aplicaciones. En
segundo lugar, la aplicación MAS (Multi Agent System) es una aplicación distribuida
en sí misma. Tal como se ha construido el MAS podemos ejecutarlo de forma paralela
en varias máquinas de forma transparente para el usuario, su ejecución en paralelo es
una funcionalidad implementada para posibilitar el reparto de carga en el sistema,
creando así un sistema de computación grid.
A continuación se van a explicar con más detalle las arquitecturas distribuidas para ver
dónde se encuadraría NOMADA dentro de este tipo de sistemas.
3.1 Arquitecturas distribuidas
La arquitectura distribuida base del resto de modelos de arquitecturas distribuidas es la
asociada al modelo cliente-servidor.
PFC: NOMADA
16
Las aplicaciones cliente / servidor, también denominadas two-tiers, consisten en un
proceso cliente (client tier) que pide servicios a un proceso servidor (Server tier). El
cliente es responsable de la capa de presentación mientras que en el servidor se
encuentra la lógica de la aplicación así como los mecanismos de interconexión
necesarios con otros sistemas (como una base de datos).
Figura 3.1 – Arquitectura cliente / servidor
Las características principales de una arquitectura de este tipo son:
1. El Cliente y el Servidor pueden actuar como una sola entidad y también pueden
actuar como entidades separadas, realizando actividades o tareas independientes.
2. Las funciones de Cliente y Servidor pueden estar en plataformas separadas, o en
la misma plataforma.
3. Un servidor da servicio a múltiples clientes en forma concurrente.
4. Cada plataforma puede ser escalable independientemente. Los cambios
realizados en las plataformas de los Clientes o de los Servidores, ya sean por
actualización o por reemplazo tecnológico, se realizan de una manera
transparente para el usuario final.
5. La interrelación entre el hardware y el software están basados en una
infraestructura poderosa, de tal forma que el acceso a los recursos de la red no
muestra la complejidad de los diferentes tipos de formatos de datos y de los
protocolos.
PFC: NOMADA
17
6. Un sistema de servidores realiza múltiples funciones al mismo tiempo que
presenta una imagen de un solo sistema a las estaciones Clientes. Esto se logra
combinando los recursos de cómputo que se encuentran físicamente separados
en un solo sistema lógico, proporcionando de esta manera el servicio más
efectivo para el usuario final. También es importante hacer notar que las
funciones Cliente/Servidor pueden ser dinámicas. Por ejemplo, un servidor
puede convertirse en cliente cuando realiza la solicitud de servicios a otras
plataformas dentro de la red. Su capacidad para permitir integrar los equipos ya
existentes en una organización, dentro de una arquitectura informática
descentralizada y heterogénea.
7. Además se constituye como el nexo de unión mas adecuado para reconciliar los
sistemas de información basados en mainframes o minicomputadores, con
aquellos otros sustentados en entornos informáticos pequeños y estaciones de
trabajo.
8. Designa un modelo de construcción de sistemas informáticos de carácter
distribuido. Su representación típica es un centro de trabajo (PC), en donde el
usuario dispone de sus propias aplicaciones de oficina y sus propias bases de
datos, sin dependencia directa del sistema central de información de la
organización, al tiempo que puede acceder a los recursos de este host central y
otros sistemas de la organización.
Algunos problemas que se han ido presentando con la evolución de los sistemas
informáticos, como el aumento exponencial de clientes y la ausencia de distribución
efectiva en el dominio del servidor, dieron lugar a la aparición de un nuevo modelo de
aplicación distribuida, esta arquitectura es la llamada n-tier (una variante de ésta es la
three tier). Esta arquitectura se compone de una capa inicial de presentación, una capa
final de persistencia y una o más capas intermedias donde se recogen las reglas
específicas de la aplicación. Estas capas se interconectan entre sí mediante una
infraestructura común llamada middleware que garantiza al sistema una escalabilidad y
flexibilidad sin precedentes.
PFC: NOMADA
18
Figura 3.2 – Arquitectura 3-tier
Un modelo arquitectónico más avanzado son las arquitecturas basadas en peer to peer.
Si las arquitecturas n-tier introducían un modelo de n capas con roles definidos, estas
arquitecturas recuperan la distribución de n capas (o nodos) pero posibilitando que éstas
puedan asumir cualquiera de los roles en función del estado del sistema.
Para implantar una arquitectura distribuida, además de definirla, se debe definir el modo
de comunicación que se va a establecer entre ellos. Actualmente existen muchas
alternativas para establecer una comunicación entre sistema, entre ellas están: sockets,
RPC (Remote Procedure Calls) y los objetos distribuidos [TANE95].
El sistema NOMADA se apoya en una arquitectura three-tier que utiliza la tecnología
de objetos distribuidos para establecer la comunicación entre los módulos.
Las funcionalidades que se pretenden cubrir con las arquitecturas distribuidas (y, por
tanto, con NOMADA) son [TANE02]:
Heterogeneidad de los componentes.- La interconexión, sobre todo cuando
se usa Internet, se da sobre una gran variedad de elementos hardware y
software, por lo cual necesitan de ciertos estándares que permitan esta
comunicación. Los middleware, son elementos software que permiten una
abstracción de la programación y el enmascaramiento de la heterogeneidad
PFC: NOMADA
19
subyacente sobre las redes. También el middleware proporciona un modelo
computacional uniforme.
Extensibilidad.- Determina si el sistema puede extenderse y reimplementado
en diversos aspectos (añadir y quitar componentes). La integración de
componentes escritos por diferentes programadores es un autentico reto.
Seguridad.- Reviste gran importancia por el valor intrínseco para los usuarios.
Tiene tres componentes:
o Confidencialidad.- Protección contra individuos no autorizados.
o Integridad.- Protección contra la alteración o corrupción.
o Disponibilidad.- Protección contra la interferencia con los
procedimientos de acceso a los recursos.
Escalabilidad.- El sistema es escalable si conserva su efectividad al ocurrir un
incremento considerable en el número de recursos y en el número de usuarios.
Tratamiento de fallos.- La posibilidad que tiene el sistema para seguir
funcionando ante fallos de algún componente en forma independiente, pero
para esto se tiene que tener alguna alternativa de solución. Técnicas para tratar
fallos:
Detección de fallos. Algunos fallos son detectables, con comprobaciones por
ejemplo.
Enmascaramiento de fallos. Algunos fallos detectados pueden ocultarse o
atenuarse.
Tolerancia de fallos. Sobre todo en Internet se dan muchos fallos y no es muy
conveniente ocultarlos, es mejor tolerarlos y continuar
Recuperación frente a fallos. Tras un fallo se deberá tener la capacidad de
volver a un estado anterior.
Redundancia. Se puede usar para tolerar ciertos fallos (DNS, BD, etc.)
Concurrencia. Compartir recursos por parte de varios clientes a la vez.
Transparencia. Es la ocultación al usuario y al programador de aplicaciones
de la separación de los componentes en un sistema distribuido. Se identifican 8
formas de transparencia:
De Acceso. Se accede a recursos locales y remotos de forma idéntica.
De ubicación. Permite acceder a los recursos sin conocer su ubicación.
PFC: NOMADA
20
De concurrencia. Usar un recurso compartido sin interferencia.
De replicación. Permite utilizar varios ejemplares de cada recurso.
Frente a fallos. Permite ocultar los fallos.
De movilidad. Permite la reubicación de recursos y clientes sin afectar al
sistema.
De prestaciones. Permite reconfigurar el sistema para mejorar las prestaciones
según su carga.
Al escalado. Permite al sistema y a las aplicaciones expandirse en tamaño sin
cambiar la estructura del sistema o los algoritmos de aplicación.
Con estos objetivos ha sido construido el sistema NOMADA, llegando a alcanzar la
mayor parte de los objetivos anteriores.
3.2 Arquitectura distribuida en NOMADA
Nuestro sistema presenta una arquitectura que obedece a los requerimientos funcionales
del propio sistema, tanto en su distribución como en la heterogeneidad de las
aplicaciones que lo componen.
Como es inherente a la arquitectura en la que se basa, se pueden distinguir tres capas:
applications tier, business tier y data tier.
Applications tier: Las especificaciones de NOMADA hacen necesaria una separación
de éste en distintas aplicaciones con diferentes vistas de la información y adaptadas a
distintos tipos de usuario. Para ello necesitamos una infraestructura común que permita
la coexistencia de estas aplicaciones en ejecución simultánea dentro del sistema. Como
consecuencia en este nivel se han extendido las funcionalidades típicas de la capa de
presentación (presentation tier) para permitir mayores capacidades de interacción con la
información del sistema (manipulación, cálculo y visualización). Es por este motivo por
el que la capa de presentación en nuestro sistema toma otro nombre.
PFC: NOMADA
21
De esta forma la capa de presentación pasa de ser una capa de presentación como las
habituales para convertirse en un entorno de ejecución de aplicaciones individuales que
comparten un mismo proveedor de información.
Dentro de esta capa se encuentra, además, el sistema multiagente que pasa a ser una
aplicación más de esta capa, de manera que, si queremos cambiarla, podemos hacerlo
sin necesidad de modificar el resto del sistema.
Business tier: Esta capa constituye el centro de información de NOMADA. Contiene
una representación del entorno actual y los mecanismos necesarios para la
interoperatibilidad con las otras dos capas. Esta capa proporciona un conjunto de
interfaces que permiten a las aplicaciones del nivel inferior el acceso a conjuntos de
datos específicos; desde el punto de vista del data tier ofrece una capa de abstracción de
datos que permite la recuperación de los datos persistentes en forma de objetos de
memoria y viceversa.
Data tier: Contiene un conjunto de dispositivos que se encargan de almacenar los
datos, son, por lo tanto, el medio persistente donde se guarda la información (como una
base de datos). La arquitectura del sistema es suficientemente flexible como para poder
ser extendida a cualquier dispositivo concreto implantado en esta capa.
La implantación de la arquitectura se realiza mediante servicios Web que operan como
infraestructura de comunicaciones entre las capas. La encargada de contener el servidor
con los servicios Web es el business tier.
PFC: NOMADA
22
Figura 3.3 – Arquitectura de NOMADA
Cada una de las aplicaciones que componen el sistema NOMADA ha sido desarrollada
siguiendo un modelo arquitectónico común definido en capas y orientado a
componentes.
API MICROSOFT .NET
COMUNICACIONES
MODELO DE DATOS
MIDDLEWARE
CONTROL
INTERFAZ GRAFICA DE USUARIO
API MICROSOFT .NET
COMUNICACIONES
MODELO DE DATOS
MIDDLEWARE
CONTROL
INTERFAZ GRAFICA DE USUARIO
Figura 3.4 – Arquitectura genérica de las aplicaciones
A continuación se describen las distintas capas que tiene cada aplicación:
PFC: NOMADA
23
− Comunicaciones: primera capa de la arquitectura, aquí se sitúan las
herramientas para la comunicación a bajo nivel entre sistemas. Estos son
protocolos, procedimientos de envío y recepción, etc. [POWE02].
− Middleware: capa arquitectónica esencial en todo sistema moderno de
comunicaciones. Esta capa es la que posibilita el intercambio de información
entre aplicaciones distribuidas. Su principal funcionalidad es encapsular las
comunicaciones realizadas por servicios Web, objetos distribuidos u otras
técnicas.
− Control: este componente recoge la parte operativa de la aplicación, esto es, el
conjunto de algoritmos y operaciones mediante los cuales se va a manipular el
modelo de datos.
− Interfaz gráfica de usuario: capa que posibilita la interacción entre el usuario
y la aplicación.
3.3 Módulos de la aplicación
Una vez explicado el diseño de la arquitectura global de NOMADA y el diseño que se
ha seguido para cada uno de los módulos (aplicaciones) que lo componen, es hora de
ver cuáles son las aplicaciones concretas que constituyen el sistema. Estas son:
InfoService: Servidor de información para el resto de aplicaciones del sistema,
se encarga de la recepción, preprocesado, publicación y almacenamiento
persistente de la información del sistema.
Plan Information Entry (PIEntry): Servicio para el suministro periódico de
información de la unidad (valor de los sensores / variables). Actualmente este
PFC: NOMADA
24
sistema se simula. El usuario es capaz de indicar en qué fichero se encuentran
las entradas y la aplicación va cargando éstas periódicamente.
Knowledge Management Application (KMA): Aplicación con interfaz gráfica
para la incorporación y gestión del conocimiento, tanto la definición de la
unidad como la incorporación de modelos, reglas y diagnósticos. Se dirige a
un usuario administrador de NOMADA.
Multi-Agent System (MAS): Sistema multi-agente distribuido para la detección
de anomalías (agente evaluador de modelos) y elaboración de diagnósticos
(agente diagnóstico).
Diagnostic Application (DA): Aplicación con interfaz gráfica para la
visualización del estado actual de la unidad de tren, las anomalías detectadas y
los diagnósticos emitidos. Se dirige a un usuario operario.
Persistencia (BBDD): Implantación como mecanismo de persistencia de una
base de datos relacional para el almacenamiento de las bases de hechos
(estática, dinámica e histórico) y de la base de conocimientos (reglas y
diagnósticos)
PFC: NOMADA
25
Figura 3.5 – Diagrama simplificado de NOMADA
No todos los componentes de arquitectura están presentes en cada una de las
aplicaciones. Esto se debe a que cada aplicación está destinada a cubrir una serie de
funcionalidades restringida. En la siguiente tabla se puede ver claramente qué capas
tiene cada aplicación.
InfoService PIEntry KMA MAS DA
Interfaz usuario Modelo datos Control Middleware Comunicaciones
Tabla 3.1 – Elementos arquitectónicos de cada aplicación
En la tabla superior se pueden observar una serie de decisiones tomadas a la hora de
desarrollar cada una de las aplicaciones:
− El InfoService y el MultiAgent System (MAS) son servicios del sistema y por
lo tanto no precisan de una interfaz gráfica de usuario. No obstante, las
PFC: NOMADA
26
aplicaciones disponen de un fichero de configuración para determinar ciertos
aspectos de su comportamiento.
− El PIEntry y el InfoService no requieren una instancia del modelo de datos. Su
manejo de este elemento no es lo suficientemente amplio como para cargarlo
en estos programas, hacerlo supondría ocupar recursos innecesariamente,
además de que complicaría el funcionamiento de las aplicaciones.
− Todas las aplicaciones se comunican entre sí mediante la capa de middleware
y la capa de comunicaciones (la plataforma Microsoft .NET Framework
encapsula esta capa permitiendo el desarrollo de comunicaciones partiendo de
un nivel superior). No obstante, hemos restringido el uso de esas
comunicaciones a las necesidades de cada aplicación.
Una vez vistos todas las aplicaciones que conforman NOMADA, y de qué se compone
cada una de ellas, podemos explicar como funciona el sistema completo:
1. En primer lugar, el usuario debe meter los datos en la base de datos a través del
PIEntry.
2. El siguiente paso es, arrancar el MAS para que se vayan procesando los datos
que han entrado o están entrando en el sistema. Lo que ocurre dentro del MAS
es lo siguiente:
a. Las entradas pasan a los agentes modelo, que analizan los datos y
detectan si algún componente está en estado anómalo.
b. La información concluida por los agentes modelo pasa a los agentes
diagnóstico, que transforman los resultados de los agentes modelo en
proposiciones para inferir diagnósticos.
c. Los agentes diagnóstico guardan sus conclusiones en la base de datos.
3. Una vez arrancado el MAS, el usuario puede arrancar el DA para ver que
resultados está obteniendo en el diagnóstico de los componentes y, así, conocer
el estado de la unidad de tren.
PFC: NOMADA
27
4 Modelo de Datos (DataModel)
Podemos definir el modelo de datos como una estructura de clases y objetos que sirven
para representar las estructuras organizacionales y las entidades reales de un
negocio. Lo más normal, es encontrar el modelo de datos como un componente
autónomo dentro de la arquitectura de la aplicación donde reside toda su lógica o
business logic (lógica de negocio). Podemos ver esta entidad como el componente más
específico y estratégico.
La validez de un modelo de datos puede ser medida en términos de potencia expresiva
(capacidad para expresar distintas estructuras de negocio, sin cambiar la estructura del
modelo de datos) además de flexibilidad, rendimiento, reutilización, etc. Una de las
dificultades más importante a la hora de diseñar el modelo de datos es la existencia de
una relación directa entre la potencia de expresión del modelo y la dificultad para el
desarrollo y mantenimiento de éste. Es por ello, que ha sido necesario llegar a un
término medio, con el que se logre un modelo de datos suficientemente potente para
soportar el mayor número de entidades de negocio, sin que ello conlleve una gran carga
en cuanto a mantenimiento y desarrollo se refiere.
El modelo de datos de NOMADA se construye de manera automática gracias a técnicas
de reflexión (que se explican a continuación), gracias a estas técnicas podemos trabajar
con el modelo de negocio (todas las, reglas datos y definiciones existentes) sin
necesidad de acceder constantemente al medio en el que están guardados. Además, la
carga del modelo de datos se realiza de forma automática al iniciar la aplicación,
utilizando técnicas que optimizan los accesos al medio persistente, en nuestro caso una
base de datos, todo ello apoyado en el lenguaje XML [ARRA05].
Reflexión es la capacidad de una aplicación para observar y modificar su estructura de
alto nivel. Normalmente, la reflexión es dinámica o en tiempo de ejecución, aunque
PFC: NOMADA
28
algunos lenguajes de programación soportan reflexión en tiempo de compilación o
estática.
En un sentido más amplio, la reflexión es una actividad computacional que razona sobre
su propia computación.
Cuando el código fuente de un programa se compila, normalmente se pierde la
información sobre la estructura del programa conforme se genera el código de bajo
nivel (normalmente lenguaje ensamblador). Si un sistema soporta reflexión, se preserva
la estructura como metadatos en el código generado. Dependiendo de la
implementación, el código con reflexión tiende a ser más lento que el que no lo tiene.
En los lenguajes que no distinguen entre tiempo de ejecución y tiempo de compilación
(como las distintas variantes de Lisp), no hay diferencia entre compilación o
interpretación de código y reflexión.
Algunas de las características más importantes de la reflexión son:
Descubrir y modificar construcciones de código fuente (tales como bloques de
código, clases, métodos, protocolos, etc.) como objetos de "categoría superior"
en tiempo de ejecución.
Convertir una cadena que corresponde al nombre simbólico de una clase o
función en una referencia o invocación a esa clase o función.
Evaluar una cadena como si fuera una sentencia de código fuente en tiempo de
ejecución.
En nuestro caso la reflexión se usa para almacenar y crear las estructuras de datos de
forma automática al crearse un objeto. Para un ejemplo ver la línea siguiente:
protected int _id; [DBColumn("compId")]
public int Id {
get { return _id; }
set { _id = value; } }
PFC: NOMADA
29
En ese caso, cuando se le pasa al constructor de la clase, donde están esas líneas, la tabla
correspondiente, automáticamente, en tiempo de ejecución, se crea la estructura y se va
metiendo la información de cada columna de la tabla en el atributo de la clase. En este
caso cuando se crea un objeto de la clase Component, se le pasa una fila y
automáticamente se coge la columna de esa fila cuyo nombre es compId y se crea el
atributo _id.
La base principal del modelo de datos son los business objects, se puede definir éste
como un objeto perteneciente al modelo de datos que implementa una cierta lógica
específica de la aplicación así como un mecanismo de persistencia.
La aparición de estos objetos se debe fundamentalmente a la forma de ejecución de casi
todas las aplicaciones basadas en servicios Web. Esto es así porque se necesita un
mecanismo genérico y con buen rendimiento para instanciar los objetos del modelo de
datos a partir de un medio persistente y, recíprocamente, guardar en dicho medio el
estado de los objetos una vez han sido manipulados. Esta tecnología son los business
objects que se comentaron en el párrafo anterior.
4.1 Especificación del modelo de datos NOMADA
El modelo de datos de NOMADA tiene un carácter estratégico y esencial dentro del
sistema global, lo que nos ha llevado a invertir una gran cantidad de tiempo en su
diseño y desarrollo. Cuanto más genérico consigamos que sea nuestro modelo de datos
más estructuras organizacionales podremos presentar.
La estructura de modelo de datos es la característica de un componente
(NOMADA::DataModel) compuesto a su vez de un conjunto de seis subcomponentes
(Configuration, Variables, Relations, Models, Rules) así como otros componentes
necesarios para soportar el DataModel, proporcionando características como, por
ejemplo, la persistencia. En el caso que trata nuestro sistema, el modelo de datos acoge
la estructura física de un subconjunto de componentes instalado en una máquina de tren
PFC: NOMADA
30
cercanías UT-450, y las relaciones dentro del alcance del proyecto, las variables
medidas asociadas a cada componente, así como el conocimiento necesario para
detectar y diagnosticar las posibles anomalías que se puedan producir durante el
funcionamiento de éstos.
La configuración de la unidad tractora del tren (porque es el modelo que se va a usar,
pero no quita que no se pueda reutilizar para otras estructuras) queda recogida en el
siguiente conjunto de bases o directorios:
− Componentes. Cada uno de los componentes escogidos para conformar el
sistema (ejemplo: compresor).
− Variables. Abstracción del estado de la máquina a partir de sensores y
modelos matemáticos.
− Relaciones. Dependencias de una cierta clase entre los distintos componentes
de la máquina.
− Reglas. Sentencias condicionales o causales del tipo SI… ENTONCES que
representan el conocimiento experto acerca de la unidad. Esta estructura es la
que hace que podamos inferir diagnósticos a partir de las anomalías
diagnosticadas, o del estado de los modelos.
− Modelos. Relaciones de variables que reflejan el comportamiento normal
previsto de cada componente y que permiten decidir si se está en presencia de
un comportamiento anómalo o no.
Además, a este conjunto de bases hay que añadirle una estructura de datos en forma de
tablas y relaciones (DataSet) que sirve para representar de forma estática toda la
información de los objetos instanciados.
En el siguiente apartado se verá una descripción detallada de cada uno de los distintos
subcomponentes que conforman el DataModel. A continuación, se muestra un diagrama
con la vista general de su estructura:
PFC: NOMADA
31
Figura 4.1 – Diagrama de paquetes del modelo de datos
Algunas de las características fundamentales pertenecientes a nuestro modelo de datos
son:
En tanto que nuestro modelo de datos está dentro de una arquitectura
orientada a componentes, está implementado como un componente
independiente accesible al resto de la aplicación mediante un único interfaz
común (el cual esta implementado dentro de la clase Configuration) y de
forma recursiva, mediante subcomponentes accesibles dentro del propio
componente a través de interfaces (son las clases Base que se encuentran
dentro de cada uno de los paquetes). De esta forma los componentes
estructurales del modelo de datos tienen un nivel óptimo de flexibilidad y
autonomía, más aún, cuando se ha perseguido en la medida de lo posible su
implantación siguiendo el patrones de diseño [LARM03].
PFC: NOMADA
32
Desde el punto de vista de modelo de datos de un sistema experto, se
organiza de forma implícita en torno a dos grandes componentes, base de
hechos y base de conocimientos (éstas son las fuentes de datos básicas de un
sistema experto). La base de hechos se compone de una base de componentes,
otra de variables y, por último, una que contiene las relaciones. Por su lado, la
base de conocimiento incluye una base de reglas y otra de diagnósticos. Con
esto tendríamos dos de los componentes principales de todo sistema experto.
Nos faltaría otro componente básico que es el motor de inferencia que, dadas
sus características, es totalmente inviable alojarlo en el modelo de datos. La
base de hechos está compuesta por los paquetes Components, Variables y
Relations, mientras que la base de conocimiento está formada por los paquetes
Diagnostics y Rules.
Si vemos el modelo de datos desde la perspectiva de un sistema n-tier
orientado a servicios Web, la mayoría de sus objetos están implementados
como business objects, que son instanciados automáticamente a partir de una
estructura de datos (DataSet) compuesta por tablas y relaciones entre las
mismas. De esta manera, una configuración tiene un carácter dual, puesto que
se compone de un conjunto de objetos en memoria y de una estructura de datos
con la información de los mismos.
4.2 Componentes del modelo de datos
Ahora vamos a analizar de forma pormenorizada cada uno de los subcomponentes del
modelo de datos desde un punto de vista conceptual y de implantación. Se mostrará
además el mecanismo de persistencia automática en el que se apoyan los business
objects usados.
Se van a incluir diagramas de clase simplificados para una mejor comprensión de la
estructura del modelo de datos, así como de las entidades y relaciones que lo
PFC: NOMADA
33
conforman. Además al final de la explicación de cada paquete se muestra el diagrama
de clases completo (incluyendo datos y métodos).
4.2.1 Base
Una base es una estructura de datos que representa un directorio de objetos de un mismo
tipo. Los elementos principales por los que está compuesta son:
− Un vector dinámico que referencia a cada uno de los objetos registrados y
permite operaciones de incorporación o supresión (el orden de los elementos
del vector no tiene porque ser, forzosamente, significativo).
− Dos indexadores que facilitan la recuperación de un objeto específico dentro
de una base a partir de su identificador numérico o de su nombre alfanumérico.
− Un método que asigna de manera automática identificadores numéricos a cada
uno de los objetos en el momento de su incorporación a la base.
− Una interfaz implícita compuesta tanto por los métodos de incorporación y
supresión de elementos como por los indexadores definidos.
De esta clase Base heredan las distintas bases del modelo de datos (bases de
componentes, de variables y de relaciones). Sin embargo, para evitar interdependencias
entre los distintos subcomponentes de modelo de datos, se ha decidido no implementar
esta clase abstracta, de esta manera, ésta queda recogida de forma implícita y conceptual
en la implementación de cada una de las bases.
Para mostrar los elementos básicos de una Base se va a mostrar en detalle la clase
ComponentBase:
PFC: NOMADA
34
Figura 4.2 – Diagrama UML de ComponentBase
En esta clase podemos observar el vector dinámico, que corresponde al ArrayList
_components, los dos indexadores que son los dos método this(…) uno recibe el índice
y el otro el nombre del componente. En este caso los métodos tienen ya un identificador
que viene de la base de datos, pero al meterse en el ArrayList éste le proporciona otro
que corresponde a su posición dentro del array. Los métodos de incorporación y
supresión vienen dados por la clase ArrayList, estos son Add() y Remove()
respectivamente.
4.2.2 Componentes
Un Componente es un objeto dentro del modelo de datos que representa un componente
físico del tren (por ejemplo, un compresor o, incluso, la propia unidad tractora del tren).
Éste se identifica mediante un identificador numérico unívoco, presenta un conjunto de
datos informativos sobre sí mismo, además posee una referencia al elemento padre (se
verá más adelante el por qué) y tiene asociados un conjunto de variables y relaciones.
Los componentes pueden ser de dos tipos, según estén compuestos a su vez de otros
componentes, en cuyo cayo son de tipo Composite, o sean componentes terminales (no
tengan hijos), en cuyo caso se llaman Leaf. Todos los componentes se encuentran
registrados en una base de componentes (ComponentBase) que conforman la
abstracción de la estructura física del tren o uno de sus componentes.
La base de componentes queda implantada siguiendo una estructura de datos de tipo n-
ario y a través de un design pattern de tipo Composite. Dicha estructura se compone de
un elemento raíz (la máquina de tren), que será el único componente que no tenga
PFC: NOMADA
35
padre, a partir del cual se extienden los distintos componentes intermedios siguiendo un
orden jerárquico de composición, cuyas hojas o elementos finales son aquellos
componentes que no se componen ni pueden estar compuestos de otros componentes.
Además, los componentes se encuentran referenciados e indexados en el directorio de
componentes.
Figura 4.3 – Estructura lógica del paquete Components
Las restricciones de esta representación lógica de la unidad son las típicas que
encontramos al tratar con una estructura de árbol convencional:
Todos los componentes, excepto el raíz, deben depender de, exclusivamente,
otro componente al que llamamos padre.
Todo componente intermedio (Composite) puede tener de 0 a n hijos. Un
componente Terminal, por definición, carece de hijos.
Con esta estructura podemos observar, claramente, que no es posible que un
componente tenga a su vez varios padres, esto significa que los componentes no pueden
repetirse dentro de la estructura.
Esta estructura es el mecanismo principal para representar la estructura de los
componentes del tren y organizar la información del sistema. Así, en las aplicaciones
KMA y DA se ofrece al usuario en todo momento un representación gráfica en forma de
PFC: NOMADA
36
árbol de los componentes del tren. A través de esta representación se posibilita el acceso
a otros elementos tales como modelos o variable.
Figura 4.4 – Ejemplo de árbol de componentes (con modelos)
Lo siguiente que se muestra es el diagrama de clases del paquete de componentes:
PFC: NOMADA
37
Figura 4.5 – Diagrama UML del paquete Components
PFC: NOMADA
38
4.2.3 Variables
Una Variable es la representación dentro del modelo de datos de un símbolo asociado a
una medida tomada del tren (por ejemplo, una medida de temperatura o de presión).
Toda Variable esta asociada a un componente respecto del cual nos da cierta
información para determinar la presencia o no de un determinado modo de fallo.
La clase Variables es de tipo abstracto, y contiene un conjunto de propiedades comunes
a la definición de objetos del modelo de datos y específicos de la propia entidad
variable. Entre lo valores específicos podemos señalar un indicador numérico del tipo
de variable (actualmente éste sólo será 1 para Variables directas o 2 para Variables
calculadas), un valor de tipo decimal que indica el grado de certeza (valor requerido por
los sistemas expertos, ya que éste se basa en factores de certeza) respecto al valor
(numérico o no) asociado a la variables y, finalmente, dos campos que informan acerca
del estado de la variable (activa o no) y la versión de su última modificación a nivel de
definición (no de su último uso).
Las variables numéricas son variables caracterizadas por un valor de tipo numérico
decimal, el tipo de unidades o magnitud en la que viene expresado, así como un
intervalo o rango cerrado de valores posibles (máximo y mínimo), fuera del cual la
variable se encontraría “fuera de rango” y se desactivaría de forma automática (no se
tendría en cuenta para ninguna acción). Cabe la posibilidad de que la variable no tenga
rango definido, para ello cuando se defina la variable se deben dejar sus valores de
“valor máximo” y “valor mínimo” a 0, con esto se permitiría a la variable tomar
cualquier valor.
Adicionalmente, toda variable numérica tiene un conjunto de estados lógicos definidos.
Estos estados permiten la transición entre los valores numéricos continuos que reciben
las variables y los estados lógicos discretos en que se hace necesario expresarlos para su
uso en reglas y proposiciones. Los estados lógicos se definen mediante una subdivisión
por intervalos del rango de la variable, así como por una etiqueta que expresa el valor
PFC: NOMADA
39
lógico de cada uno de dichos intervalos. En la actual implantación de NOMADA ha
sido necesaria la siguiente distinción de estados.
Para las variables que pertenecen a la salida de los modelos de tipo Umbral o PCM (que
son los que actualmente existen en NOMADA) se han definido los estados “bajo”,
“normal” y “alto”. Se puede realizar una ampliación de los estados e incluir, por
ejemplo, “muy bajo” y “muy alto” como estados, no hay ninguna complicación en esto.
La mayor parte de los modelos que se desarrollen posteriormente para NOMADA se
acogerán a esta clasificación de estados.
Existe un tipo de modelos que por sus características no puede acogerse a la anterior
clasificación de estados lógicos, por lo que, ha sido necesario crear unos estados
especiales para éstos; los modelos a los que nos referimos son los tipo KSOM (mapa de
Kohonen), los estados definidos para estos modelos son “verde”, “amarillo” y “rojo”. Es
cierto que se podrían haber adaptado los estados anteriores de “alto”, “normal” y “bajo”
y no extender los estados lógicos, pero a la hora de desarrollar proposiciones y reglas se
expresa el conocimiento mucho más claramente con estos estados específicos. Dado que
la complejidad para incluir estos estados no es muy elevada, se decidió añadirlos. Un
dato importante es que las salidas de un mapa son de tipo discreto, en cambio, para
definir estados se necesita coger un rango de valores. En la siguiente tabla se muestra
cómo se definen los rangos de valores para recoger los valores discretos.
Intervalo numérico Estado lógico
[-0.1, 0.9) “verde”
[0.9, 1.9) “amarillo”
[1.9, 2.9] “rojo”
A continuación se muestra un ejemplo de definición de estados “alto”, “bajo” y
“normal”:
PFC: NOMADA
40
Intervalo numérico Estado lógico
[0, 9) “bajo”
[9, 19) “normal”
[19, 50] “alto”
La diferencia fundamental es que a la hora de definir estados lógicos para los colores,
los rangos siempre tienen que ser esos, mientras que para el otro tipo de estados
podemos especificar el rango que queramos. Los estados de color se asocian a variables
de salida de modelos KSOM exclusivamente.
Una vez realizada la definición de estados podemos definir proposiciones para la
variable para los que se hayan definido (por ejemplo, la variable A). Así podríamos
construir proposiciones del tipo “La variable A es normal” o, si se tratase de una
variable de salida de un modelo KSOM, “la variable A es roja”, sin necesidad de
conocer el valor numérico concreto de la misma.
En la clase NumericVariable, los estados lógicos se encuentran implantados mediante
una lista ordenada de pares (valor, estado) donde el valor corresponde con la cota
inferior cerrada del intervalo y el estado con la etiqueta en forma de cadena de texto
predefinida en el sistema. Para el ejemplo anterior la lista sería de la siguiente manera:
{ (0, “bajo”, (9, “normal”), (19, “alto”)}. La cota superior cerrada del último intervalo
correspondería con el valor de la cota máxima definida para la variable.
En la versión actual podemos encontrar en el sistema dos tipos de variables numéricas
definidas: variables directas (DirectNumericVariable) y calculadas
(CalculatedNumericVariable). Las variables directas toman su valor directamente del
PIEntry mediante su identificador o TAG definido.
Las variables calculadas son evaluadas a través de una función matemática (expresada
mediante una cadena de texto), esta operación se realiza en el InfoService. Las variables
que toma como parámetros una variable calculada son llamadas variables padre, una
variable padre puede ser una variable directa o una variable con retraso. Las variables
PFC: NOMADA
41
con retraso son aquellas cuyo valor corresponde al de una variable directa en el instante
t-x (siendo t el instante actual y x el retraso).
Ante esto cabe destacar que nuestro modelo de datos presenta dos restricciones a la hora
de operar con variables:
Las variables calculadas no pueden depender de otras variables calculadas que
no sean variables con retraso o, bien, de variables directas. Este hecho no
supone limitación expresiva alguna, ya que cualquier función que toma como
parámetros variables calculadas puede ser transformada de forma directa en
otra función que dependa de variables directas y variables retrasadas
exclusivamente (incluyendo en su expresión las funciones de las variables
calculadas). La necesidad de dicha transformación consiste en evitar
dependencias funcionales en el cálculo de variables que podrían dar lugar a
bucles infinitos y a fallos inesperados. Por ello el modelo de datos establece un
orden secuencial a la hora de realizar cálculos sobre las variables definidas.
Entre una variable calculada y las variables que toma como parámetros existe
una relación de dependencia fuerte, en el sentido de que es imposible borrar
una variable si hay otras que dependen de ella. Con esta restricción del modelo
de datos se pretende evitar problemas de dependencia y coherencia en las
variables definidas.
El siguiente diagrama muestra la estructura de este paquete:
PFC: NOMADA
42
Figura 4.6 – Diagrama UML del paquete Variables
PFC: NOMADA
43
Un punto que resulta interesante tratar es dónde debería ir la nueva clase si se quiere
añadir un nuevo tipo de variable, por ejemplo que tome valores de cadena de caracteres
o un vector. Bien, esta nueva clase tendría que heredar de Variable y habría que
asignarle otro número para el tipo ya que, es en VariableBase donde se crean distintos
objetos Variable dependiendo del tipo, y hay que llamar al constructor específico de la
clase de la variable que se quiera instanciar.
Otro punto importante es que la definición y gestión de variables se realiza a través de
KMA.
4.2.4 Relaciones
Una Relación es una dependencia o conjunto de dependencias entre entidades. Mediante
una relación se pueden expresar las dependencias funcionales que existen entre un
conjunto de componentes, independientemente de sus dependencias estructurales (las
relaciones estructurales son aquellas que vienen determinadas por la estructura de
árbol).
En el modelo de datos de NOMADA una relación (Relation) queda definida mediante
un identificador unívoco, un nombre alfanumérico, un tipo de relación asociado y el
conjunto de nodos que componen dicha relación. Adicionalmente, se incluye un campo
lógico que permite especificar si la relación es dirigida. En caso de serlo, los nodos se
recorren de forma secuencial respetando su índice.
N1 N2 N3 … Ni
En caso contrario un nodo se relaciona con el nodo anterior y con el siguiente:
N1 N2 N3 … Ni
PFC: NOMADA
44
C1
C2
C3
C4
C5
C6
C7
C8
Relación dirigida
C1
C2
C3
C4
C5
C6
C7
C8
Relación no dirigida
nodo 1 nodo 2 nodo 3
nodo 1 nodo 2 nodo 3
C1
C2
C3
C1
C2
C3
C4
C5
C6
C4
C5
C6
C7
C8
Relación dirigida
C1
C2
C3
C1
C2
C3
C4
C5
C6
C4
C5
C6
C7
C8
Relación no dirigida
nodo 1 nodo 2 nodo 3
nodo 1 nodo 2 nodo 3
Figura 4.7 – Relaciones dirigidas y no dirigidas
Un tipo de relación (RelationType) consta, a su vez, de un identificador, un nombre y
una breve descripción en la que se define de qué trata la relación. Algunas relaciones
que se podrían tener son: “eléctrica” o “térmica”, por ejemplo. Asociar relaciones con
tipos permite clasificar las dependencias y restringir el impacto al tipo de anomalía
detectada.
Cada nodo (RelationNode) se compone de un conjunto de componentes iniciales
(origen) y un conjunto de componentes finales (destino), así como de un índice
numérico que indica el orden del nodo dentro de la relación. Dentro de cada nodo la
relación es completa, esto es, todos los elementos iniciales están relacionados con todos
los elementos finales. Se pueden definir relaciones no completas mediante la división de
una relación en subrelaciones.
PFC: NOMADA
45
C1
C2
C3
C4
C5
C6
C7
C8
Relación original R
C1
C2
C4
C5
C6
C7
C8
C3
C5
C6
C7
C8
nodo 1 nodo 2 nodo 3
Relaciones R1 y R2
nodo 1 nodo 2 nodo 3
Pb. Se desea indicar en la relación que C3 no está relacionado con C4
C1
C2
C3
C1
C2
C3
C4
C5
C6
C4
C5
C6
C7
C8
Relación original R
C1
C2
C4
C5
C6
C7
C8
C3
C5
C6
C7
C8
nodo 1 nodo 2 nodo 3
Relaciones R1 y R2
nodo 1 nodo 2 nodo 3
Pb. Se desea indicar en la relación que C3 no está relacionado con C4
Figura 4.8 – Composición de relaciones
Como sucede en el caso de las variables, las relaciones presentan algunas restricciones a
la hora de implementarlas, las más destacables son:
No se permiten las referencias circulares directas de elemento, esto significa
que un elemento no puede ser origen y destino simultáneamente dentro de un
mismo nodo. Se evita así toda relación reflexiva, que carecería de sentido
físico, y se evitan problemas de circularidad.
No se evitan, en cambio, las referencias circulares indirectas, dejando al
administrador del sistema la tarea de evitar este tipo de relaciones.
Las relaciones están implantadas como un elemento de ampliación de la capacidad del
sistema. Actualmente nuestro sistema no tiene una complejidad elevada (a nivel de
componentes) por lo que no requiere del uso de relaciones funcionales, no obstante al
incluir más componentes es muy probable que éstos tengan relaciones entre ellos.
El siguiente diagrama muestra la estructura de clases del paquete Relations:
PFC: NOMADA
46
Figura 4.9 – Diagrama UML del paquete Relations
PFC: NOMADA
47
4.2.5 Reglas
Una regla es una formulación mediante un sistema lógico del conocimiento causal del
experto. Así, toda regla se define como una relación condicional compuesta por un
antecedente (premisas) y un consecuente (conclusiones). Ambas partes están
compuestas a su vez por una o más proposiciones unidas mediante un operador de
conjunción.
“Si A1 y A2 y … y An ENTONCES C1 y C2 y … y Cn”
El conocimiento formalizado mediante reglas con esta expresión es del tipo “Si
ESTADOS entonces DIAGNOSTICO”.
Como ya se habrá identificado, este paquete del modelo de datos alberga el
conocimiento del sistema experto implantado en la aplicación para inferir diagnósticos.
Por lo tanto, este paquete es la base de conocimientos. Podemos definir base de
conocimientos de un sistema experto como la parte que contiene el conocimiento sobre
el dominio convenientemente organizado y estructurado, se busca para ello una forma
de representación lo más sencilla posible, por lo que, se escoge la representación del
conocimiento en forma de reglas.
Una regla (Rule) consta de un identificador unívoco, un nombre, un índice de prioridad,
que le dará su orden de ejecución respecto del resto de las reglas, y un conjunto de
premisas y conclusiones.
Una proposición (Proposition) consta de un identificador unívoco, un nombre, un
componente asociado y una lista de reglas de las que forma parte.
Con las dos estructuras anteriores conseguimos una estructura de datos doblemente
enlazada que permite, a partir de una regla, obtener las proposiciones que utiliza e,
PFC: NOMADA
48
inversamente, a partir de una proposición, conocer las reglas que deben ser disparadas
(utilizadas). Esta estructura resulta de gran ayuda en los procesos de inferencia.
Se definen así proposiciones de dos tipos: estados y diagnósticos, o, si se prefiere,
antecedentes y consecuentes. Las proposiciones de estado (Statement) afirman el estado
lógico de una variable del sistema, su forma es “<variable> ES <estado lógico>” (por
ejemplo, “La variable A es alta”).
Las proposiciones de diagnóstico (Diagnostic) son sentencias que informan del estado
de la unidad de tren en un instante determinado a partir del proceso de inferencia.
Incluyen obligatoriamente una descripción (“Fallo en C”) y, cuando sea necesario una
acción de respuesta (“Acción: Cambiar C”).
Tal como se ha explicado parece que se no se pueden encadenar reglas, es decir, que un
consecuente de una regla sea el antecedente de otra, esto no es correcto, el sistema
soporta en encadenamiento de reglas (es un requisito indispensable que, de no darse,
haría que el sistema experto no fuese de utilidad).
El objetivo de las reglas es representar un elemento de conocimiento que puede ser
empleado para resolver un problema que se presenta. De esta manera, las reglas
participan en un proceso de inferencia, donde partiendo de un conjunto de premisas, se
llega a un conjunto de consecuencias, que serán lo que se presenta como diagnósticos o
causas del problema.
Un dato importante a la hora de hablar de las reglas, es la certidumbre de éstas.
Podemos definir certidumbre como una variable que expresa el grado de certeza que el
experto deposita en una proposición o relación. El cálculo de certidumbre en NOMADA
se realiza mediante factores de certeza. Esta técnica es una técnica clásica y la más
utilizada a la hora de tratar con sistemas expertos, ya que, permite al experto expresar su
valoración personal frente a una aseveración a partir de su experiencia personal y
conocimiento.
PFC: NOMADA
49
Suponiendo el modelo de factores de certeza del conocido MYCIN, la certidumbre es
una variable que se define en el intervalo [-1, 1] siendo -1 la completa no creencia y 1
absoluta confianza. Toda proposición que participa en una regla tiene un grado de
certeza (certidumbre) asociado, específico para la proposición y para la regla.
Adicionalmente, el grado de certidumbre de una proposición depende del número de
reglas que la verifican y de los valores de certeza asociados a éstas.
Para una única regla se atiende a las siguientes normas a la hora de operar:
1. Se define MinAnt como la certidumbre de la parte antecedente (de las
proposiciones premisas) y se calcula como el mínimo de las certidumbres de las
proposiciones que componen dicha parte antecedente.
2. Se define la certidumbre de cada proposición en la parte consecuente como el
producto entre MinAnt y la certidumbre de la propia proposición concluida.
Si lo que se tienen son varias reglas que tienen una conclusión común, se aplica lo
siguiente:
Sean dos reglas R1 y R2 que alcanzan la misma conclusión h, a partir de dos evidencias
e1 y e2 diferentes: R1 : Si e1 entonces h, CF(h, e1) y R2 : Si e2 entonces h, CF(h, e2) El
factor de certeza de h se calculará como:
a) CF(h, e1) + CF(h, e2) (1-CF(h, e1)), si CF(h, e1)>0 y CF(h, e2)>0.
b) CF(h, e1) + CF(h, e2) (1+CF(h, e1)), si CF(h, e1)<0 y CF(h, e2)<0.
c) [CF(h, e1) + CF(h, e2)] / (1-min( |CF(h, e1)| , |CF(h, e2)| ), en otro caso.
El siguiente diagrama muestra la estructura de clases del paquete:
PFC: NOMADA
50
Figura 4.10 – Diagrama UML del paquete Rules
PFC: NOMADA
51
4.2.6 Modelos
Un Modelo es una función que toma como argumentos de entrada un conjunto de
variables, realiza una serie de operaciones sobre ellas y devuelve como resultado el
valor estimado de una (o varias) variables de salida, en el caso de los modelos de
comportamiento normal, y una celda concreta, en el caso de los modelos de mapas auto-
organizados (mapas de Kohonen).
Los modelos de comportamiento normal predicen el valor que deberían tomar un
conjunto de variables de salida, a partir de los valores actuales de un conjunto de
variables de entrada. Esta predicción es comparada posteriormente con el valor real de
las variables y, en base a ello, se calcula un error (diferencia entre valor real y
estimado). Si este error supera un intervalo de tolerancia, entonces se asocia al
componente asociado al modelo, un estado de anomalía.
El otro tipo de modelos admitido en el sistema son los de tipo KSOM, estos modelos,
también conocidos como mapas de Kohonen, son redes de neuronas topológicamente
ordenadas que, frente a la presentación de un patrón n-dimensional compiten hasta que
sólo una de ellas queda activada. Las reglas de funcionamiento de estos modelos
difieren con las de los anteriores, aquí ya no se habla de variable estimada y variable
error, si no que éstas pasan a tener el mismo valor (debido a las decisiones de diseño
tomadas). El que se presente o no anomalía dependerá exclusivamente de la salida del
modelo (bien es cierto, que la salida del modelo dependerá de las entradas de éste, pero
de ninguna manera la relación es como la del caso anterior).
Siguiendo el modelo de datos, un modelo se compone de parámetros (ModelParam).
Los parámetros constan de un identificador numérico, un nombre y una descripción,
pudiendo ser de dos tipos: parámetros de entrada o parámetros de salida.
Un argumento de entrada se caracteriza por apuntar a una variable de entrada definida
en el sistema a través de su tag. Un argumento de salida se caracteriza por apuntar a tres
PFC: NOMADA
52
variables distintas: una variable real, una variables estimada (que será la salida del
modelo) y una variable de error.
En el siguiente diagrama se muestra la estructura de clases del paquete Models:
PFC: NOMADA
53
Figura 4.11 – Diagrama UML del paquete Models
PFC: NOMADA
54
4.2.7 Configuración
La Configuración contiene de forma ordenada y accesible todos los elementos del
modelo de datos definidos anteriormente, así como sus relaciones y dependencias. El
objeto Configuration se compone de las cinco bases que se han visto anteriormente
(cada uno de los paquetes explicados tenía una base asociada). Junto a esas bases de
objetos instanciados, la configuración incluye una representación de los mismos por
medio de tablas (DataSet) y una clase para recuperar y almacenar los datos en el
InfoService (Persistente).
El tener la representación de datos tanto en forma de instancias como de tablas, es lo
que nos permite utilizar business objects que se almacenan de manera automática en un
medio persistente (nuestra BBDD). Así, la configuración inicial se recibe por medio del
InfoService a través de un DataSet, que contiene una réplica exacta de las tablas
necesarias de la BBDD. A partir de esa estructura de datos, se crean e instancian las
distintas bases y objetos mediante sus constructores correspondientes. Inversamente,
este mecanismo permite trasladar todas las modificaciones en los objetos de
configuración en el DataSet para que se guarden en el medio persistente.
Los business objects, comentados al principio del capítulo, nos permiten instanciar
objetos y almacenar objetos en tablas persistentes de manera automática.
Un objeto que merece especial atención es el DBColumn que nos permite relacionar una
propiedad o atributo del objeto con una columna de una tabla del DataSet. Para
establecer dicha correspondencia se debe añadir una línea encima de la definición de la
propiedad, tal como se vio al principio del capítulo:
protected int _id; [DBColumn("compId")]
public int Id {
get { return _id; }
PFC: NOMADA
55
set { _id = value; } }
El objeto Local se compone de dos métodos estáticos para asignar y leer valores a los
atributos de un objeto desde una tabla y viceversa. Es por ello que la mayoría de los
constructores de los objetos del modelo de datos reciben una fila (DataRow) para
inicializar sus atributos y propiedades; y los constructores de bases reciben una tabla
que se va recorriendo línea a línea para invocar un constructor particular [LIBE02].
Figura 4.12 – Diagrama UML del paquete BusinessObjects
PFC: NOMADA
56
El siguiente diagrama muestra la estructura del paquete Configuration:
Figura 4.13 – Diagrama UML del paquete Configuration
PFC: NOMADA
57
5 InfoService
El InfoService es un servidor de información mediante Servicios Web invocado por el
resto de aplicaciones que conforman el sistema para recibir y almacenar información.
Este componente se aloja dentro del IIS (Internet Information Server) de Microsoft y
publica una colección de servicios en formato XML y protocolo HTTP. Con esto
conseguimos que cualquier aplicación pueda acceder a él independientemente de su
implantación.
Antes de continuar vemos, por encima, la estructura del IIS y dónde se aloja nuestro
servicio.
Figura 5.1 – Estructura del IIS (Internet Information Service)
El InfoService reside en el servidor de páginas y aplicaciones Web de IIS de Microsoft
(la versión que se está utilizando actualmente es la 5.1). En esta plataforma se
constituye el entorno de ejecución de la aplicación y el marco de publicación de sus
servicios. La disponibilidad del InfoService depende, por lo general, de la
disponibilidad del IIS. Si el IIS está parado el InfoService no funcionará. Por el
contrario, si éste de halla arrancado el InfoService podrá estar funcionando
PFC: NOMADA
58
(normalmente estará operativo salvo que el administrador haya parado el servicio
expresamente). El InfoService únicamente se ejecuta cuando alguno de sus servicios es
invocado, esto es, utiliza conexiones sin estado o stateless.
De una forma sencilla, podemos ver el InfoService como un objeto que publica su
interfaz (esto sirve para cualquier servicio Web) mediante XML dentro de un servidor
de páginas Web convencional. De esta forma, quedan accesibles a otros objetos a través
de HTTP cuando un objeto invoca un método del Servicio Web, el servidor instancia el
objeto, ejecuta el método indicado, devuelve su resultado en formato XML y destruye el
objeto. Este proceso se repite en cada invocación, es por eso que se habla de conexiones
stateless. Con este mecanismo garantizamos la independencia de cada llamada en
términos de ejecución (cada ejecución es independiente del resto) y de información
(cada objeto utiliza su propia información y ésta no es compartida por el resto); además
de esto, se evita la existencia de conexiones abiertas en el servidor con el consiguiente
riesgo de saturación (existe un ataque que consiste exactamente en eso, abrir muchas
conexiones simultáneas en el servidor para saturarlo y que no sea capaz de ejecutar los
métodos, es el llamado DOS, Denial Of Service [MCLU02]).
La dirección física mediante la cuál se accede a los Servicios Web es idéntica a la de las
páginas Web, puesto que estos servicios son publicados de forma similar (podemos
obtener un listado de los servicios publicados introduciendo su dirección en un
navegador, ésta es una forma muy útil de verificar su disponibilidad). El formato
utilizado para acceder a estos métodos es el siguiente, se debe indicar el protocolo
utilizado para la transmisión, la dirección del servidor, el nombre del directorio y el
nombre de la colección de servicios (WSPIE, WSMAS o WSDM). La extensión .asmx
que sigue a cada una de las colecciones indica que se trata de una colección de servicios
Web en formato ASP.NET.
Gracias a la arquitectura del Internet Information Server hemos sido capaces de dotar al
InfoService de algunas funcionalidades que son de vital importancia para el sistema.
PFC: NOMADA
59
La utilidad principal del InfoService es crear una conexión entre las aplicaciones y la
base de datos. Gracias a esto funciona nuestro sistema, si en un momento determinado
el InfoService deja de funcionar, las distintas aplicaciones que componen nuestro
sistema quedan paralizadas y, por consiguiente, el sistema no funciona. Más adelante se
verán las distintas colecciones que ofrece el InfoService con una explicación en detalle
de cada uno de los métodos.
Sus principales funcionalidades son:
− Suministro y recepción de información por parte del resto de las aplicaciones
del sistema garantizando su coherencia y univocidad, así como restringiendo
su accesibilidad según los requerimientos particulares de cada aplicación.
− Preproceso de la información común a varios sistemas de forma que está
disponible permanentemente en un formato y valores calculados.
− Control y gestión de la versión de la información. Esta gestión se realiza de
forma manual, ya que tenemos pares de valores < ensayo, versión > para cada
versión. Para un control más exhaustivo de la información se utilizan
timestamps.
− Almacenamiento de la información en un medio persistente heterogéneo (para
ello utilizamos una capa de abstracción de datos).
Con esto quedan explicadas las distintas funcionalidades (las principales) del
InfoService, pero no sabemos cómo funciona realmente. En el siguiente gráfico se va a
intentar mostrar como funcionan los flujos de datos del InfoService.
PFC: NOMADA
60
Figura 5.2 – Diagrama simplificado del InfoService
Existen más clases además de las mostradas en la gráfica, pero estas son las más
importantes para entender el funcionamiento y la utilidad que presenta este servidor.
5.1 Servicios (WSInfoService)
Empezaremos describiendo las distintas colecciones de servicios que ofrece el
InfoService. Éstas están agrupadas por área funcional.
5.1.1 WSPIE
Colección de servicios que permite a la aplicación PIEntry recuperar la lista de tags y
enviar sus valores asociados en la unidad con una frecuencia predeterminada. Los
métodos a los que se puede acceder desde esta referencia Web se pueden ver en el
Anexo A de este mismo documento.
5.1.2 WSMAS
Colección de servicios utilizados por el Sistema Multiagente (MAS) para su actividad
normal. Éste es utilizado por el MAS para recibir la información de la unidad en una
versión determinada y para un ensayo determinado y almacenar posteriormente los
PFC: NOMADA
61
resultados de sus cálculos (estos serán, el resultado de los modelos y los diagnósticos).
Estos datos es necesario guardarlos para poder visualizarlos desde el DA y como
información histórica. Los métodos a los que se puede acceder desde esta referencia
Web se pueden ver en el Anexo B de éste mismo documento.
5.1.3 WSDM
Este conjunto de servicios permiten al resto de aplicaciones (principalmente el KMA y
el DA, también es utilizado por el MAS) recuperar la configuración del sistema,
efectuar modificaciones sobre ella, e introducir nueva información. Los métodos a los
que se puede acceder desde esta referencia Web se pueden ver en el Anexo C de éste
mismo documento.
NOTA: Los métodos del InfoService no acceden directamente a la BBDD. Cada uno de
estos métodos accede a la clase DataManager (la cual está construida siguiendo el
patrón singleton, lo que implica que sólo puede existir un objeto de este tipo o que todos
los que la instancian, instancian siempre el mismo objeto), esta clase contiene un objeto
DataSource, que realmente es un DSDataBase (DataSource es un interfaz, aunque está
definido como clase abstracta, que se utiliza para acceder a objetos DSDataBase). Un
ejemplo simple que se encuentra en la colección WSPIE:
[WebMethod]
public DataSet GetProperties()
{
return _dataManager.Source.GetProperties();
}
Como se puede ver, lo que se hace es acceder al método que contiene el DataSource que
instancia el DataManager.
5.2 Controlador de datos (DataManager)
PFC: NOMADA
62
El controlador de datos es el que se encarga de realizar todas las operaciones de
recuperación, modificación y almacenamiento de la información de configuración del
sistema, estado de los modelos e información histórica de las variables, tanto
provenientes de estímulos externos como de variables internas de la aplicación (las
cuales son variables de salida). Gracias a una capa de abstracción de datos intermedia
basada en XML, podemos modificar el medio persistente sin alterar el código.
Esta capa de abstracción intermedia no es otra que DataSource (una clase abstracta)
donde se definen una serie de operaciones básicas que debe realizar el sistema sobre el
medio persistente, la cual debe ser implementada por cualquier controlador válido de
datos para el sistema. Y el DataManager accederá a los métodos del controlador a través
de DataSource. El motivo de crear el DataSource como una clase abstracta y no como
un interfaz, es que de esta manera tenemos la posibilidad de, además de obligar a las
clases que heredan de ella a implementar determinados métodos, que se puedan
compartir métodos ya instanciados entre esas clase así como atributos. El único
requisito, pues, que una clase debe cumplir para ser controlador de datos es heredar de
la clase DataSource e implementar correctamente todos sus métodos abstractos.
Para hacer la capa de abstracción más flexible, se ha diseñado un mecanismo mediante
el cual el controlador de datos que se va a utilizar durante la sesión, se establece de
forma dinámica (a través del fichero de configuración Web.config del InfoService). Por
lo tanto, es imprescindible indicar en el fichero de configuración antes mencionado cuál
va a ser el controlador a utilizar, en nuestro caso DSDataBase. Como es natural, esta
clase debe estar compilada y dentro del directorio de ejecución (bin) del InfoService.
La clase DataManager es la encargada de instanciar un controlador de datos adecuado (a
partir del nombre definido en el archivo Web.config) y hacerlo disponible a todos los
servicios Web publicados en el InfoService. El método con el que se instancia el
controlador de datos es DataSourceBinding(), ejecutado desde el propio DataManager.
Además, se encarga de llevar el número de versión y de ensayo que controla la petición
de datos de versiones por parte del MAS y de DA.
PFC: NOMADA
63
En la actualidad el sistema implementa un controlador de datos optimizado para bases
de datos de tipo Microsoft SQL Server 2000. Este controlador utiliza la clase
DBConnector para conectar y desconectar de la base de datos, según los parámetros de
conexión especificados en el fichero de configuración del InfoService.
PFC: NOMADA
64
Figura 5.3 – Diagrama UML del paquete DataManager
PFC: NOMADA
65
5.3 Preprocesador (Preprocessor)
El preprocesador se encarga de preparar los valores de las variables (y las variables) de
entrada al sistema. Las medidas que, al fin y al cabo, son valores que entran desde los
sensores o desde los ficheros de datos no pueden pasar directamente a formar parte del
conjunto de entradas del sistema. Estas medidas deben ser tratadas y son las que dan
lugar a las variables. Existen dos tipos de variables posibles:
Las primeras son las variables directas. Estas variables entran al sistema y al
pasar por el preprocesador no se les aplica ningún tipo de modificación, los
valores que entran son los que pasan a ser los valores que toman las variables
en el sistema.
El otro tipo se ha definido como variable calculada. Estas variables requieren
la evaluación y cálculo de una función matemática o la búsqueda de un retraso.
Esta funcionalidad se ha implementado por medio de la clase Preprocessor, la
cual se vale de una serie de clases para realizar los cálculos de las funciones y,
así obtener los valores de las variables calculadas. Para realizar los cálculos se
emplean las clases ExpressionParser, Node y Operator que están en el fichero
MathCalculator.cs en el proyecto InfoService.
PFC: NOMADA
66
Figura 5.4 – Diagrama UML del paquete Preprocessor
PFC: NOMADA
67
6 Sistema Multi-Agente (MAS, Multi-Agent System)
Los sistemas multiagente (MAS) han demostrado ser una herramienta efectiva en un
amplio rango de aplicaciones. Sin embargo, las aplicación de la tecnología MAS a la
automatización de procesos industriales no ha sido tan frecuente. Algunos de los
problemas que plantea el uso de esta tecnología es que las aplicaciones necesitan
requerimientos en tiempo real (y más si lo que tratamos de hacer es un seguimiento de
componentes para realizar un mantenimiento predictivo) actualmente fuera del alcance
de la tecnología de agentes, un tratamiento dificultoso de las relaciones entre los agentes
y los sistemas a controlar, la falta de paralelismo en la automatización de procesos, etc.
En este contexto ha sido creado nuestro sistema multiagente, el cual conforma el núcleo
central de nuestra aplicación y que da nombre a la aplicación NOMADA para la
identificación y control de anomalías en componentes de trenes.
Este problema podemos abordarlo de forma efectiva gracias a que la mayor parte de los
módulos trabajan de forma simultánea, de manera que podemos asignar cada módulo a
un agente (se verá más adelante esta división).
Uno de los aspectos más interesantes del MAS es el uso de ontologías basadas en el
lenguaje de marcas. Una ontología se compone de un conjunto de clases, relaciones,
funciones, etc. que representan un conocimiento de un dominio particular. Una
ontología compartida por varios agentes presenta, por lo tanto, un formato común para
expresar datos y conocimiento.
6.1 Agente
Como se comprobará más adelante, el problema que debemos resolver es relativamente
sencillo en comparación con la estructura que se ha creado para resolverlo. Lo que se ha
pretendido con el desarrollo del sistema multiagente es no limitarlo a este caso concreto,
PFC: NOMADA
68
si no que pueda ser utilizado en otros sistemas realizando modificaciones mínimas e
incluso ninguna modificación.
Llegados a este punto conviene describir lo que es un agente y hacer una pequeña
descripción de cómo se estructuran los agentes en nuestro sistema.
Podemos definir agente como una entidad autónoma que se relacione con el entorno
donde reside y capaz de comunicarse con otros agentes, además, los agentes presentan,
por definición, una cierta capacidad de razonamiento específico para cumplir con un
objetivo determinado [WEIS99].
Figura 6.1 – Agente interaccionando con su entorno
Es importante decir que, cada agente tiene un dominio, es decir, un área dentro de su
entorno de la cual se encarga, esta zona de la que se encarga el agente es lo que se
conoce como esfera de influencia.
Los agentes inteligentes que conforman nuestro sistema tienen ciertas características
que lo dotan de flexibilidad y que son las siguientes:
Reactividad, el agente debe ser capaz de percibir estímulos de su entorno y
responder a él en un tiempo determinado con el fin de satisfacer sus objetivos
de diseño (hacer aquello para lo que ha sido diseñado).
PFC: NOMADA
69
Autonomía: capacidad de actuar sin intervención humana directa o de otros
agentes.
Sociabilidad: capacidad de interaccionar con otros agentes, utilizando como
medio algún lenguaje de comunicación entre agentes.
Iniciativa: un agente no sólo debe reaccionar a los cambios que se produzcan
en su entorno, sino que tiene que tener un carácter emprendedor y tomar la
iniciativa para actuar guiado por los objetivos que debe de satisfacer.
Veracidad: no comunica información falsa intencionadamente.
Benevolencia: no tiene objetivos contradictorios y siempre intenta realizar la
tarea que se le solicita.
Racionalidad: tiene unos objetivos específicos y siempre intenta llevarlos a
cabo.
Con este fin hemos dotado a los agentes de nuestro sistema con la siguiente
arquitectura:
PFC: NOMADA
70
análisis razonamiento
juiciodecisión
percepciones
acciones
Agente
Entorno
análisis razonamiento
juiciodecisión
percepciones
acciones
Agente
Entorno
Figura 6.2 – Estructura general de un agente en NOMADA
A continuación, se describen cada uno de los elementos fundamentales de nuestros
agentes:
Percepciones, son el conjunto de estímulos percibidos por el agente,
esencialmente variables de entorno y mensajes de otros agentes. Normalmente
un agente percibe un número limitado de estímulos, sólo los relativos a los
objetivos concretos que debe cumplir. Los estímulos pueden ser recibidos
tanto de forma síncrona como asíncrona.
Análisis, una vez percibidos los estímulos, el agente los analiza para ver si
interfieren con su actividad actual, si hay cambios respecto a los estímulos
anteriores, etc. En este momento se procede, además, a la modificación de los
datos para adaptarlos al lenguaje natural del agente (el formato de
procesamiento interno del agente).
Razonamiento, con los estímulos recibidos, después de haber pasado el filtro
anterior (en la fase de análisis) y con el formato adecuado, el agente realiza
PFC: NOMADA
71
una evaluación de los mismos siguiendo un mecanismo de razonamiento
concreto. Este proceso es el que hace que nuestros agentes no sean sólo
agentes, si no que puedan ser llamados agentes inteligentes. Este proceso
conduce a la formulación de una o varias conclusiones, una valoración de
variables, etc.
Juicio, tras obtener los resultados específicos de la fase de razonamiento, el
agente debe emitir un juicio sobre éstos. Por ejemplo, si tiene varias
alternativas debe seleccionar una de ellas.
Decisión, en esta fase el agente elabora una lista de acciones a realizar sobre el
entorno, tales como modificar variables o cambiar estados, y sobre otros
agentes, mediante el envío de mensajes. Un factor importante a la hora de
llevar a cabo estas acciones es la secuencia de las mismas, decidir a quién
enviar los mensajes, etc.
Acciones, son el conjunto de operaciones que el agente lleva a cabo sobre el
entorno y sobre el resto de los agentes (que percibirán estas acciones como
estímulos).
Todos los agentes de nuestro sistema tienen esta estructura, la complejidad de cada uno
de los elementos de esta arquitectura dependerá del fin para el que se ha diseñado dicho
agente. Así, un agente puramente reactivo realizaría las acciones directamente en
función de los estímulos percibidos, un agente intencional tendrá módulos de juicio y
decisión muy desarrollados, etc.
Los agentes permanecen durante todo su tiempo de vida percibiendo estímulos e
interactuando con su entorno. Se trata de un proceso cíclico cuya reactividad (frecuencia
de ciclo) depende de las necesidades del problema. En algunas situaciones el agente
reaccionará de manera inmediata a los estímulos, mientras que en otras, responderá a
ellos cada cierto tiempo.
PFC: NOMADA
72
6.2 Sistema multiagente
Podemos definir sistema multiagente como aquel en el cual varios agentes inteligentes
interactúan para conseguir un propósito común o para realizar una serie relacionada de
tareas. Todo esto mediante una serie de protocolos de comunicación específicos para
transmitir información entre los agentes y el entorno.
Cada agente tiene que ser capaz de interactuar con su entorno, el dominio del agente es
lo que se llama esfera de influencia, y, como es natural, la esfera de influencia es un
subconjunto del entorno del agente [WOOL02].
Figura 6.3 – Sistema multiagente interaccionando con su entorno
Esto hace que el concepto de sistema multiagente y arquitectura distribuida esté
íntimamente relacionado. Así el sistema que hemos creado tiene una serie de
características que permiten que se pueda distribuir la carga del MAS entre varios
PFC: NOMADA
73
equipos pudiendo crear de esta manera un sistema de grid (grid computing, estos
sistemas permiten que la carga de una o varias tareas sea distribuida entre varios
equipos).
Para la implementación de nuestro sistema multiagente se ha optado por seguir las
especificaciones FIPA [FIPA01] [FIPA04] [FISI01], debido principalmente a dos
razones. Por un lado, estas especificaciones se han convertido en un estándar reconocido
en el desarrollo de sistemas multiagente. Por otro lado, dichas especificaciones se
refieren, no únicamente al lenguaje de comunicación entre los agentes (como el caso de
otros estándares como el KQML [GONZ06]) , sino que abarcan aspectos como la
gestión de los agentes en una plataforma o el flujo lógico en una conversación ente
agentes (lo cual nos resulta de gran utilidad).
Figura 6.4 – Estructura de la plataforma multiagente de la FIPA
El modelo de agentes FIPA proporciona el marco en el cual los agentes existen y
operan. El facilitador de directorios (DF, Directory Facilitator) proporciona un servicio
de “páginas amarillas” a aquellos agentes que le consultan buscando los servicios
suministrados por otros agentes de la plataforma.
PFC: NOMADA
74
Por su parte el Sistema de Gestión de Agentes (AMS, Agent Management System)
proporciona al resto de agentes un servicio que podríamos llamar de “páginas blancas”
y, además, mantiene un directorio que contiene las direcciones de los agentes
registrados en la plataforma de agentes (AP, Agent Platform). Por último, se necesita un
servicio para transportar los mensajes entre las distintas plataformas.
Nuestro sistema multiagente (MAS) tiene como objetivo la evaluación de modelos de
comportamiento normal y mapas autoorganizados en tiempo real, pero sus
características de diseño nos permiten utilizarlo también para evaluar modelos
históricos, para detectar posibles anomalías, en cuyo caso se realizará a partir de ellas la
inferencia de diagnósticos acerca de sus causas. Como ya se comentó anteriormente,
dado que el proceso puede ser extremadamente complejo, el sistema permite su
distribución en varios equipos dentro de una red local para obtener un mejor
rendimiento. Para ello se ha implantado una arquitectura distribuida basada en la
metodología FIPA que se apoya en el uso de objetos remotos y librerías de Microsoft
.Net Remoting [GOME03].
El sistema consta de dos componentes diferentes: una plataforma multi-agente
(MAS::Platform), que proporciona la infraestructura operacional necesaria, y un
conjunto de agentes específicos (MAS::Agent).
El módulo de agentes (MAS::Agent) se compone a su vez de un agente (Agent) que
implanta las funcionalidades básicas comunes a cualquier agente, tales como, un
controlador de eventos, un conjunto de identificadores, etc. En base a él se han diseñado
tres tipos de agente específicos: agente modelo (de los que no se hablará en este
documento), agente diagnóstico (encargado de inferir diagnósticos a partir de la
información proveniente de los agentes modelo) y el agente coordinador (que controla
las operaciones del resto de los agentes). Esto se completa con un componente utilizado
para la gestión de eventos y otro para el cálculo de modelos [LOPA04].
La estructura global de la aplicación es la siguiente:
PFC: NOMADA
75
Figura 6.5 – Diseño estructural del MAS de NOMADA
PFC: NOMADA
76
Como se puede observar la estructura de la plataforma es muy similar a la especificada
por la FIPA.
6.3 Plataforma multi-agente
La plataforma multiagente de NOMADA dota al sistema de la infraestructura necesaria
para iniciar y alojar los distintos agentes que lo componen. Gracias a ella conseguimos
un sistema escalable y flexible. Un punto importante de esta plataforma es que
implementa técnicas avanzadas de sistemas distribuidos para evitar la existencia de una
plataforma coordinadora predeterminada y hacer de este modo un sistema más versátil.
En este apartado se analiza cada uno de los componentes de la plataforma multiagente,
estos son: AgentRepository, PlatformSyndication, y InfrestructureManager,
AgentPlatform.
6.3.1 Directorio (AgentRepository)
El sistema multiagente cuenta con un directorio (AgentRepository) equivalente al DF
del estándar de la FIPA. En él se incluyen referencias a las distintas plataformas así
como a los distintos agentes que residen en ellas. Cada plataforma tiene su propio
directorio donde almacena la información de las distintas plataformas.
El directorio (Repository) permite a cada plataforma conocer el resto de plataformas
disponibles dentro de la red local, así como referenciar a los agentes. La información
que contiene el directorio es la misma en todas las plataformas para garantizar la
robustez del sistema distribuido.
La clase principal (AgentRepository) esta implantada siguiendo el patrón singleton, de
forma que esté accesible al resto de componentes y clases de la red local. Consta de un
número de versión que corresponde con un flujo de entrada de datos proveniente del
InfoService que está usando el MAS en un momento dado, y de una lista con
PFC: NOMADA
77
información sobre el resto de las plataformas (PlatformInfo). Además, se incluyen
referencias directas a la plataforma coordinadora y a la plataforma local, por motivos de
comodidad a la hora de realizar operaciones.
La clase PlatformInfo, por su parte, contiene información y referencias sobre una
plataforma. Esta información es básicamente la dirección IP, una lista con los agentes
que contiene (AgentInfo) y un campo que indica si la plataforma es coordinadora o no.
Por último, la clase AgentInfo representa la información básica sobre un agente
(nombre, tipo, modelo o diagnóstico). Incluye también su URI (Universal Resource
Identificador), que identifica al agente de forma unívoca dentro de la red, una referencia
al propio agente y una lista que contiene la información de los modelos que tiene
asignados el agente o el identificador del componente (dependiendo de si es agente
modelo o diagnóstico).
El siguiente diagrama muestra el diagrama UML de AgentRepository:
PFC: NOMADA
78
Figura 6.6 – Diagrama UML del paquete AgentRepository
PFC: NOMADA
79
6.3.2 Sindicación (PlatformSyndication)
La sindicación es un proceso mediante el cual las distintas plataformas se integran en el
sistema multiagente. Concretamente, mediante este mecanismo se incorporan en la
aplicación distribuida las plataformas disponibles en la red local y se establece cuál de
ellas es la plataforma coordinadora. Este componente consta de cuatro clases y una
interfaz que se verán a continuación con más detalle. Además, ha sido necesario
establecer un protocolo de sindicación (con distintos tipos de mensajes y estados).
La interfaz, ISyndicationProtocol, consiste en un conjunto de métodos que debe
implementar cualquier clase que vaya a trabajar como controladora de sindicación (para
el envío y recepción de mensajes).
El controlador de sindicación (SyndicationManager) es la clase principal del
componente. Consta de la información necesaria para el intercambio de información
(dirección IP multicast), una referencia al directorio local y la duración del proceso.
Para el tratamiento de los mensajes, la clase se compone de un objeto para la recepción
(SyndicationListener) y otro para el envío (SyndicationSender). Ambas clases
implantan funcionalidades para establecer comunicaciones en red mediante mensajes y
sockets.
Los mensajes de sindicación (SyndicationMessage) se forman a partir de un tipo de
mensaje predefinido y la información de la plataforma que lo envía (objeto
PlatformInformation). Dadas las características del sistema es el propio protocolo el que
debe encargarse de procesar los mensajes en orden correcto, esto se debe a que, en un
sistema distribuido como el nuestro, sería necesario establecer un coordinador
predeterminado para garantizar un tiempo universal o que los mensajes sean
correlativos.
El diagrama UML correspondiente a la plataforma de sindicación es el siguiente:
PFC: NOMADA
80
Figura 6.7 – Diagrama UML del paquete PlatformSyndication
Protocolo de sindicación
Un protocolo de comunicación consiste en el conjunto de tipos de mensaje que pueden
ser enviados entre las entidades del sistema, así como el conjunto de estados en los que
se puede encontrar el proceso. En este apartado se detallan los tipos de mensaje y
estados que define el protocolo de sindicación nuestro sistema multiagente.
a. Tipos de mensaje definidos
El protocolo de sindicación define cuatro tipos de mensaje distintos:
PFC: NOMADA
81
- REQUEST. Este mensaje es enviado por toda plataforma multi-agente al
inicio del periodo de sindicación. Mediante él se informa al resto de posibles
plataformas de su incorporación al sistema.
- ANSWER. Cuando una plataforma recibe un mensaje, REQUEST responde
inmediatamente con un mensaje ANSWER en el que incluye la información
de su plataforma. Inversamente, cuando una aplicación recibe un mensaje
ANSWER añade la información de la plataforma a su directorio y comprueba
si se trata de la plataforma coordinadora. En caso afirmativo detiene el proceso
de sindicación local y se pone a la espera.
- TIMEOUT. Se trata de un mensaje interno (esto es, NO enviado al resto de
plataformas) para indicar al procesador de mensajes que el periodo de
sindicación ha concluido sin éxito –sin encontrar una plataforma coordinadora.
- COORDINATING. Si una plataforma finaliza su periodo de sindicación sin
haber encontrado una plataforma coordinadora en el sistema (TIMEOUT del
punto anterior) envía un mensaje de tipo COORDINATING para indicar que a
partir de ese instante ella asume el rol de coordinadora.
Tipo Respuesta
de receptora
REQUEST ANSWER
ANSWER No
TIMEOUT Coordinating / No
COORDINATING No
b. Estados posibles del proceso de sindicación
PFC: NOMADA
82
El protocolo de sindicación define un conjunto de estados predefinidos, indicando el
controlador de sindicación (SyndicationManager) el estado actual del proceso a través
de una variable de estado. El protocolo utiliza los siguientes estados predefinidos:
- REQUESTING. Cuando se inicia el proceso de sindicación por primera vez y
se envía un mensaje multicast de tipo “REQUEST”.
- WAITING_ANSWERS. Una vez que ha sido enviado correctamente el
mensaje REQUEST y el temporizador de la sindicación se inicia.
- FINISHED. Cuando el proceso de sindicación concluye. Esto puede ser
debido a dos razones. Bien el temporizador de la sindicación termina sin haber
encontrado a una plataforma coordinadora (en cuyo caso la plataforma local
asume ese rol), o bien, se detecta durante el proceso una plataforma
coordinadora cuando se recibe un mensaje de tipo COORDINATING o un
mensaje ANSWER proveniente de la plataforma coordinadora.
En la siguiente tabla se indican los posibles estados de la sindicación, los mensajes con
los que están relacionados y los métodos donde se asignan:
Estado Mensajes Método
REQUESTING REQUEST StartSyndication()
WAITING_ANSWERS ANSWER,
COORDINATING
StartSyndicationTimer()
FINISHED TIMEOUT,
COORDINATING,
ANSWER (coordinator)
SyndicationEventHandler()
6.3.3 Controlador de infraestructura (InfrastructureManager)
PFC: NOMADA
83
A través de este paquete el agente coordinador es capaz de repartir los agentes entre las
distintas plataformas que existen en el sistema, así como de suscribir unos agentes con
otros (establecer líneas de comunicación entre ellos).
Cada plataforma utiliza su propio servidor de infraestructura encargado de publicar un
objeto remoto de infraestructura en una URI y puerto determinados. El agente
coordinador utiliza un controlador de infraestructura para conectarse a las demás
infraestructuras del resto de plataformas y distribuir los agentes entre ellas (siguiendo
un protocolo creado por nosotros para la distribución de agentes).
El servidor de infraestructura (InfrastructureServer) es iniciado por la plataforma local
(AgentPlatform) al finalizar la sindicación. Éste publica un objeto remoto utilizando un
canal tipo TCP.
El objeto de infraestructura (RInfrastructure) sirve para crear, conectar y desconectar
agentes. Dos agentes están conectados si uno es capaz de recibir los eventos del otro
(comunicación unidireccional).
Además, existe un coordinador de infraestructuras (InfrastrucureManager) para
conectarse a los objetos remotos de todas las plataformas y distribuir los agentes.
La siguiente figura muestra el diagrama de InfrastructureManager:
PFC: NOMADA
84
Figura 6.8 – Diagrama UML del paquete InfrastructureManager
Algoritmo de distribución
El protocolo de distribución utilizado para repartir los agentes entre las plataformas es el
siguiente:
PFC: NOMADA
85
a) Con una plataforma. Todos los agentes se crean en esa plataforma.
b) Con dos plataformas. Se crean la mitad de los agentes en una plataforma y la
otra mitad en la otra.
c) Con más de dos plataformas. Se crean el cada plataforma no coordinadora
(cantidad de objetos) / (cantidad de plataformas - 1), y en la plataforma
coordinadora el resto de la división anterior.
6.3.4 Plataforma / Servicio (AgentPlatform)
Este paquete es el encargado de iniciar la aplicación en el equipo local.
La clase AgentPlatform al iniciarse instancia un objeto SyndicationManager y se abona
a sus eventos, iniciándose así el proceso de sindicación.
Si la plataforma es designada como coordinadora, después del proceso de sindicación,
se arranca el agente coordinador y comienza el proceso de distribución. Si no es
coordinadora espera a recibir órdenes de la plataforma coordinadora.
Adicionalmente, el controlador de sindicación de la plataforma coordinadora puede
enviar un evento a la plataforma multiagente informando de la incorporación de una
nueva plataforma. Si se recibe este evento, se redirige al agente coordinador que
reiniciará el proceso de distribución de infraestructura.
A continuación se puede ver el diagrama UML de AgentPlatform:
PFC: NOMADA
86
Figura 6.9 – Diagrama UML del paquete AgentPlatform
PFC: NOMADA
87
6.4 Agentes del sistema
Dentro de la plataforma existen varios tipos de agente dedicados a cumplir con la
funcionalidad de NOMADA, es decir, la detección y el diagnóstico de anomalías.
De esta forma tenemos tres tipos de agentes. Todos los tipos de agentes tienen en
común una base sobre la que son desarrollados y, dependiendo del tipo de agente, cada
uno define los métodos que necesita para cumplir con su funcionalidad [CAMP98]. Los
tipos de agentes que podemos encontrar son: coordinador, modelos y diagnóstico (este
proyecto sólo recoge las especificaciones del agente coordinador y los agentes
diagnóstico).
En la siguiente figura podemos ver un ejemplo de cómo se relacionan los agentes.
Observamos como los datos entran a los agentes modelo y, las salidas de éstos pasan a
los agentes diagnóstico que, utilizando la base de conocimiento alojada en el modelo de
datos, analizan los estímulos percibidos de los agentes anteriores para inferir
diagnósticos sobre el estado de los distintos componentes de la unidad. Tanto los
resultados de los agentes modelo como los de los agentes diagnóstico se guardan en la
base de datos para su posterior visualización a través del DA.
El agente coordinador no aparece debido a que su función no implica trabajar
directamente con información acerca del estado de los componentes, lo que hace, como
su propio nombre indica, es coordinar al resto de agentes del sistema.
PFC: NOMADA
88
Figura 6.10 – Diagrama funcional del MAS
A continuación, se va a describir la función y la estructura de un agente diagnóstico,
para lo cual, primero debemos ver cual es la estructura base en la que se apoyan todos
los agentes.
6.4.1 Estructura de los agentes
Todos los agentes heredan de una clase llamada Agent. Esta clase presenta el conjunto
de funcionalidades esenciales (reactividad, autonomía y comunicación) que debe
incorporar todo agente para considerarse como tal.
La clase Agent consta de una serie de identificadores, un índice de reactividad que
indica cada cuánto extraer eventos de la cola de procesamiento, una referencia al
InfoService y un controlador de eventos (EventProcessor) que posibilita el envío y
recepción de eventos.
La estructura del agente base es la siguiente:
PFC: NOMADA
89
Figura 6.11 – Diagrama UML de la clase Agent
6.4.2 Agente diagnóstico (AgentDiagnostic)
El agente diagnóstico es el encargado de inferir los diagnósticos de mayor nivel, dentro
de su área de conocimiento, a partir de la información de estado de los modelos
proporcionada por los agentes modelo. Cuando se tienen diagnósticos concretos se
envían éstos a un agente diagnóstico coordinador, que integrará todos los diagnósticos
parciales y emitirá diagnósticos finales (diagnósticos de mayor rango). En la siguiente
figura se muestra la estructura de un agente diagnóstico y las actividades que realiza:
PFC: NOMADA
90
análisis razonamiento
juiciodecisión
percepciones
acciones
• Base de reglas asociada al componente raíz del dominio del agente• Estados lógicos de las variables de error de los modelos
• Convertir estados lógicos de variables en aseveraciones de proposiciones (premisas iniciales)
• Inferencia de diagnósticos
• Informar al agente diagnóstico coordinador (si no actual)
• Comunicar al InfoService diagnósticos inferidos (traza)• Notificar agente diagnóstico coordinador (si no actual)
análisis razonamiento
juiciodecisión
percepciones
acciones
• Base de reglas asociada al componente raíz del dominio del agente• Estados lógicos de las variables de error de los modelos
• Convertir estados lógicos de variables en aseveraciones de proposiciones (premisas iniciales)
• Inferencia de diagnósticos
• Informar al agente diagnóstico coordinador (si no actual)
• Comunicar al InfoService diagnósticos inferidos (traza)• Notificar agente diagnóstico coordinador (si no actual)
Figura 6.12 – Estructura del agente diagnóstico de NOMADA
El agente diagnóstico se ha dividido en cinco clases, cada una de las cuales realiza una
función del agente Aunque en el caso del agente diagnóstico nos bastaría con cuatro
clases, se ha decidido dejar cinco para tener la misma estructura en todos los agentes.
A continuación se detallan las operaciones que realiza el agente diagnóstico en cada una
de sus fases:
1. Análisis.
En esta fase el agente diagnóstico traduce los estados lógicos de las variables
error recibidas de los agentes modelo en proposiciones existentes en su base de
PFC: NOMADA
91
reglas. Esto es importante, porque todo el funcionamiento del agente diagnóstico
se basa en variables error, no tiene en cuenta las variables de salida ni las reales.
2. Razonamiento
Con las premisas iniciales obtenidas en el punto anterior, el agente pone en
funcionamiento el motor de inferencia para extraer todas las conclusiones
posibles en su dominio de conocimiento. Esta clase equivaldría al motor de
inferencia de un sistema experto, que será explicado en el siguiente punto.
A partir de una lista de proposiciones iniciales se elabora una lista de reglas que
pueden ser disparadas (activadas). Una regla puede ser disparada si todas sus
premisas se cumplen y no ha sido activada con anterioridad. Las reglas se
disparan por prioridad. Para llegar lograr alcanzar todas las reglas, se sigue un
proceso iterativo mediante el cual cuando una regla se dispara, se marca como
disparada, se calculan sus conclusiones y la certeza de éstas y se borran las
premisas que dispararon esa regla (la lista de premisas que tenemos se
corresponde con la base de hechos de un sistema experto), el proceso finaliza
cuando no se pueden disparar más reglas. El resultado final es un conjunto de
conclusiones o proposiciones concluidas. El último elemento que faltaría por ver
para que este módulo sea un sistema experto es su base de conocimientos, la cual
es el conjunto de reglas que posee el agente para realizar diagnósticos
[HAYE83].
Figura 6.13 – Ciclo forward chaining seguido por los agentes diagnóstico
PFC: NOMADA
92
3. Juicio.
En el agente diagnóstico no se realiza ninguna actividad en el modulo de juicio, se
mantiene esta fase para mantener la estructura del resto de los agentes.
4. Decisión.
Si el agente diagnóstico no es coordinador, en esta fase, envía los resultados de su
inferencia al agente diagnóstico coordinador.
Además, el agente diagnóstico envía al InfoService su traza de inferencia (premisas
iniciales, conclusiones y valores de certeza), esto es utilizado por el usuario desde la
aplicación DA.
Agente diagnóstico coordinador
Éste es un tipo especial de agente diagnóstico que se encarga de inferir los diagnósticos
globales a partir de los diagnósticos parciales proporcionados por el resto de agentes
diagnóstico. Es igual que un agente diagnóstico exceptuando lo siguiente:
− Se encuentra siempre asignado al componente raíz, por lo tanto, su área de
dominio es toda la máquina.
− Recibe eventos de los demás agentes diagnóstico, en lugar de recibir
información de los agentes modelo.
− El proceso de inferencia siempre se realiza a partir de inferencias parciales y
no de premisas construidas en base al estado de los modelos.
En nuestro caso, no hay diagnóstico sobre toda la máquina, por lo que el agente
diagnóstico coordinador sólo agrupa el resto de conclusiones de los demás agentes
diagnóstico.
PFC: NOMADA
93
Figura 6.14 – Diagrama UML del paquete AgentDiagnostic
6.4.3 Sistema experto
Como se mencionó antes un agente diagnóstico es un sistema experto, y es por este
motivo por el que se hace necesario explicar qué es, en qué consiste y de qué están
formados este tipo de sistemas. En nuestro caso, el motor de inferencia que implementa
el agente diagnóstico es de tipo forward- chaining o de razonamiento hacia delante, esto
implica que partiendo de unos hechos (datos) llegamos a unas conclusiones (objetivos).
Podemos definir sistema experto como aquel sistema capaz de imitar la capacidad
mental del hombre y relacionar reglas de sintaxis del lenguaje hablado y escrito con
base en la experiencia, para luego hacer juicios acerca de un problema y obtener
solución a éste con mejores juicios y más rápidamente que el ser humano.
PFC: NOMADA
94
Lo que intenta un sistema experto es representar los mecanismos heurísticos que
intervienen en un proceso de descubrimiento. Estos mecanismos forman ese
conocimiento difícil de expresar que permite que los expertos humanos sean eficaces
calculando lo menos posible. Lo que se intenta que contenga un sistema experto es el
“saber hacer” [CUEN86].
La estructura que tienen los sistemas expertos es la siguiente:
Figura 6.15 – Sistema experto
La base de hechos contiene los hechos sobre un problema que se han descubierto
durante una consulta (en nuestro caso una versión). La base de hechos almacena las
premisas que se han dado en una versión determinada.
La base de conocimientos es la parte del sistema experto que contiene el conocimiento
sobre el dominio. Hay que obtener el conocimiento del experto y codificarlo en la base
de conocimientos. Una forma clásica de representar el conocimiento en un sistema
experto son las reglas. Una regla es una estructura condicional que relaciona
lógicamente la información contenida en la parte del antecedente con otra información
contenida en la parte del consecuente. La base de conocimientos de nuestro sistema se
almacena en la librería Rules, y su forma persistente está almacenada en algunas de las
tablas de la base de datos.
PFC: NOMADA
95
El motor de inferencia es el módulo que realiza el proceso de razonamiento humano en
un sistema experto. Dicho motor de inferencia trabaja con la información contenida en
la base de conocimientos y la base de hechos para deducir nuevos hechos. Contrasta los
hechos particulares de la base de hechos con el conocimiento contenido en la base de
conocimientos para obtener conclusiones acerca del problema. El motor de inferencia
puede ser de dos tipos:
− Razonamiento hacia delante (forward-chaining). Dadas unas premisas se busca
llegar a las conclusiones del problema.
− Razonamiento hacia atrás (backward-chaining). Busca determinar si se cumple
una conclusión con las remisas que se tienen en la base de hechos.
Además, nuestro sistema implementa un subsistema de explicación, a través del cual
nuestro sistema experto puede proporcionar una explicación al usuario de por qué está
haciendo una pregunta y cómo ha llegado a una conclusión.
PFC: NOMADA
96
7 Plan Information Entry (PI Entry)
La aplicación es la encargada de suministrar datos al sistema NOMADA. Esta
aplicación contiene un interfaz gráfico fácil de usar que permite seleccionar los datos
que se van a cargar de dos ficheros (más adelante se explica por qué se necesitan dos
ficheros y qué contiene cada uno de ellos). Con esa información, la aplicación se
encarga de introducir de manera automática todos los datos en el sistema para su
posterior procesado en el MAS (Multi-Agent System).
La aplicación se encuentra preparada para distintas contingencias como, por ejemplo,
que alguno de los ficheros de datos o los dos no tengan un formato adecuado (como es
lógico, se necesita un formato concreto para que la aplicación pueda leer el fichero).
7.1 Especificación de la implantación
El PIEntry se compone de tres únicos paquetes bien diferenciados. Cada uno de ellos se
encarga de una tarea concreta y juntos crean la aplicación. Además, esta división en
paquetes permite que si, en un momento determinado, se quiere cambiar la forma de
tratar los datos o cambiar el interfaz gráfico por otro que resulte más útil, no haya que
desarrollar una aplicación nueva, sino que basta con cambiar el paquete que convenga,
de la misma forma, si lo que se quiere cambiar es sólo alguna de las funcionalidades del
paquete o una de las clases, basta con cambiar esa clase sin afectar al resto (ésta es una
de las ventajas de la programación orientada o objetos).
PFC: NOMADA
97
Figura 7.1 – Diagrama de paquetes de la aplicación PIEntry
A continuación se va a dar una breve descripción de lo que contiene cada uno de los
paquetes:
− InterfazPI, este paquete alberga la estructura del interfaz de la aplicación. Se
compone únicamente de tres ventanas, una de visualización de resultados, otra
para introducir los ficheros necesarios para el ensayo y otra información
relevante, y una tercera para establecer las propiedades de la segmentación. La
segmentación es una función interna necesaria para tratar los datos que entran
del fichero de medidas de vibración (RMS), es una función compleja pero no
es objetivo de este proyecto el explicar como funciona.
− ModuloEntrada, contiene toda la lógica de tratamiento de ficheros, introduce
la información de las medidas en la base de datos, y es el que realmente realiza
una función crítica (la ausencia del paquete anterior haría inviable que se
viesen los resultados pero no que se introdujesen en la base de datos).
− Eventos, este paquete se diseñó para separar los eventos, que precisa la
aplicación para establecer una comunicación entre los dos paquetes, sin que
esté incluida en uno de ellos. De esta forma, se consiguen tener aislados los
eventos que usa la aplicación para, así, saber donde hay que añadirlos en caso
de que se necesite algún otro.
PFC: NOMADA
98
7.2 InterfazPI
Como ya se dijo antes, este paquete contiene el interfaz de usuario. Lo que se va a
explicar ahora son las clases de las que se compone y la función específica de cada
clase:
7.2.1 Main
La clase Main alberga la pantalla principal de la aplicación, gracias a ella podemos
realizar el resto de funcionalidades, ya que es esta clase la que llama e implementa las
demás.
A través de esta clase podemos acceder a la pantalla de alta de ensayos y a la de cambiar
los valores de la segmentación. Además, esta clase instancia un objeto Implement el
cual se encarga de cargar los ficheros e ir leyendo los datos para meterlos en la BBDD.
En el interfaz de la clase Main es donde se visualiza la información que va entrando al
sistema. Su diseño se puede ver en el gráfico siguiente:
PFC: NOMADA
99
Figura 7.2 – Pantalla principal del PIEntry
En la parte superior de la pantalla, se encuentra un menú que nos permite acceder a las
otras dos pantallas mencionadas anteriormente.
En el marco de superior, podemos ver la información del ensayo que se está realizando,
a qué unidad pertenece ese ensayo y qué compresor tiene (los compresores de las
unidades se suelen cambiar cada cierto tiempo, por lo que se hace necesario saber qué
compresor está instalado en esa máquina).
En el marco intermedio, se ven los datos que van entrando al sistema. A la derecha se
ven las medidas que se toman en continuo, éstas son, medidas de temperatura ambiente,
temperatura del aceite y presión del compresor. A la izquierda, se ven otras tres tablas
que muestran los armónicos seleccionados después de realizar la segmentación de datos
RMS. Cada una de las tablas corresponde a cada uno de los sensores situados en el
compresor para tomar las medidas de vibración.
PFC: NOMADA
100
El marco inferior, se utiliza para obtener información acerca de qué es lo que está
pasando con la entrada de datos. Se muestra información como por ejemplo, si el
ensayo se ha iniciado, en qué fase está la segmentación de datos o, si se han terminado
de leer los ficheros.
Internamente, esta clase recibe eventos de las clases que se encuentran en el paquete
ModuloEntrada, y es gracias a estos por lo que puede mostrar la información de lo que
está pasando.
7.2.2 Wizard
A través de esta clase podemos dar de alta un ensayo. La clase no realiza ninguna
operación, sólo toma los datos que le introduce el usuario, y es la clase Main la que se
encarga de realizar todas las operaciones necesarias.
Figura 7.3 – Pantalla de carga de datos
Como se muestra en la figura, el usuario tiene que introducir el nombre de la unidad de
tren, el del compresor y los dos ficheros donde se encuentran cada uno de los tipos de
datos, uno para las medidas en continuo y el otro para los datos RMS. Si se da a alguno
de los botones de la derecha accedemos al directorio donde se encuentran los ficheros
con las medidas, esto facilita la tarea de seleccionar los ficheros, ya que, podemos ver
una lista y seleccionar uno.
PFC: NOMADA
101
7.2.3 Wizard2
El Wizard dos es el interfaz a través del cual se pueden configurar los parámetros de
segmentación. Como en el caso anterior, no realiza ninguna operación, todas las
operaciones de interfaces se realizan a través de la clase Main.
Cuando se abre la ventana aparecen los parámetros de segmentación actuales, el usuario
puede cambiar estos desde ahí, y es en el Main donde se realiza la llamada a la BBDD
para modificarlos.
La siguiente figura muestra como es esta ventana, en ella se pueden ver todos los
parámetros necesarios para realizar la segmentación.
Figura 7.4 – Pantalla de propiedades de segmentación
A continuación se muestra el diagrama de clases de este paquete:
PFC: NOMADA
102
Figura 7.5 – Diagrama UML del paquete InterfazPI
7.3 ModuloEntrada
El módulo de entrada se encarga de trabajar con los ficheros de datos y de introducir la
información en la base de datos. Las clases que contiene son las siguientes:
7.3.1 Implement
Esta clase sólo se encarga de arrancar dos objetos de tipo OtherDataFile y RMSDataFile
y de dar de alta la información del nuevo ensayo, además informa al interfaz principal
de lo que está ocurriendo (respecto al alta del ensayo) para que se muestre al usuario.
PFC: NOMADA
103
7.3.2 OtherDataFile
La función de esta clase es la de leer el fichero de medidas tomadas en continuo en
intervalos de cinco segundos. Cada fila leída se almacena en la base de datos y se
manda al interfaz principal la información contenida en ella.
7.3.3 RMSDataFile
La función de esta clase es la de trabajar con el otro fichero de datos, el que contiene las
medidas RMS. En esta clase se lee el fichero con los datos RMS, se realiza la
segmentación de éstos en armónicos y, por último, se seleccionan. Los armónicos
seleccionados se guardan como entradas en la BBDD y se informa al interfaz principal
de todo lo que ha sucedido, esto es, los datos calculados, y, anteriormente, se había ido
informando de en qué fase estaba la segmentación.
Esta clase instancia un objeto de tipo Propiedades el cual contiene los parámetros de
segmentación.
7.3.4 Propiedades
La clase propiedad lo único que hace es tener una serie de propiedad para almacenar los
parámetros de segmentación, además de esto, contiene unos valores por defecto para
estos parámetros. Su única función es ser utilizada por la clase RMSDataFile cuando
ésta realiza la segmentación.
A continuación se muestra el diagrama de clases de este paquete:
PFC: NOMADA
104
Figura 7.6 – Diagrama UML del paquete ModuloEntrada
7.3.5 Eventos
Este paquete tiene un solo fichero en el cual se alojan cada uno de los eventos. Cada
evento constituye una clase distinta. Los distintos eventos que se utilizan son:
− StringInfoEventArgs, este evento va destinado al área que muestra
información sobre el estado del ensayo.
− ListValuesAREventArgs, este evento va destinado al conjunto de listas que
hay para mostrar los resultados de la segmentación.
− OtherValuesEventArgs, este evento va destinado a mostrar los datos de las
medidas tomadas en continúo.
− ModelInfoEventArgs, este evento sirve para que se pueda mostrar la
información del ensayo en la ventana principal.
PFC: NOMADA
105
Figura 7.7 – Diagrama UML del paquete Eventos
7.4 Formato de los ficheros
Ahora vamos a poner dos ejemplos de cuál es el formato correcto para cada uno de los
ficheros de entrada al sistema.
En primer lugar, vamos a mostrar el formato de un fichero de datos RMS, estos ficheros
deben tener un mínimo de tres columnas, compuestas por números. Los números
decimales deben separar su parte entera de la decimal por ‘,’ y si son exponenciales la
‘e’ debe ser minúscula y no mayúscula. Las columnas deben ir separadas un único
espacio.
PFC: NOMADA
106
Figura 7.8 – Estructura de un fichero de entrada de datos RMS A continuación se muestra el formato que debe tener el fichero de medidas en continúo.
Estos ficheros deben tener en su primera fila el nombre de la variable a la que
pertenecen los datos de la columna, este nombre debe coincidir con el del tag con el que
se identifique la variable en la BBDD. Como antes, las columnas deben separarse por
un espacio, y el formato de los números debe ser el mismo que el del caso anterior.
Figura 7.9 – Estructura de un fichero de datos de medidas en continuo
PFC: NOMADA
107
8 Diagnostic Analyzer (DA)
La aplicación DA (Diagnostic Analyzer) forma parte del sistema NOMADA. Esta
aplicación se encarga de mostrar a los usuarios los resultados de los cálculos realizados
para inferir los diagnósticos (incluyendo la detección de anomalías), dando al usuario la
información necesaria para saber qué está ocurriendo en la máquina y sus posibles
causas, en algunos casos también se informa de las acciones posibles a llevar a cabo
para solucionar el problema.
La aplicación DA es una aplicación autónoma dentro del sistema NOMADA que
proporciona toda la información sobre el estado actual y pasado del sistema. Con esto,
queremos decir que el DA no depende directamente de ninguna otra aplicación. Sin
embargo, si el MAS no está diagnosticando ningún ensayo, bien porque no está
encendido o, bien, porque no hay más datos sobre los que actuar (este caso se da si el
ensayo a terminado o el PIEntry no está introduciendo más datos), la funcionalidad de la
aplicación se ve muy mermada, puesto que no se podrán ver resultados en tiempo real.
Aún así, el DA está preparado para permitir ver el resultado de ensayos ya realizados.
Al arrancar, la aplicación recoge toda la información acerca de la configuración del
sistema utilizando el modelo de datos ya descrito en anteriores capítulos. A partir de ahí
construye sus propias estructuras de datos, para gestionar la información que
NOMADA proporciona a través del InfoService, como valores de variables y estados.
Las dos funciones principales que implementa el DA son:
Realizar una espera activa solicitando nueva información cada cierto tiempo al
InfoService. Esta información esta compuesta de, por un lado, el estado de los
modelos y los diagnósticos inferidos, y por otro, los valores de las variables de
la unidad junto con la evaluación de los modelos.
PFC: NOMADA
108
Mantener una interfaz de cara al usuario, a través de la cual se relaciona con
éste ofreciendo la información que solicita a través de pulsaciones de teclado o
de ratón. Con esto, se intenta ofrecer al usuario una forma simple y amigable
la información acerca del estado de los componentes diagnosticados, es decir,
saber si hay algo anómalo y por qué.
Los elementos que se encargan de soportar esta funcionalidad son:
− Un árbol de componentes, el cual ofrece un estado actual de cada modelo.
− Un marco que contiene una pestaña por cada componente para ver el estado
del componente de manera gráfica.
− Un cuadro de información de los últimos diagnósticos que el agente
coordinador ha emitido.
− Pantallas para mostrar la traza de cada uno de los diagnósticos.
− Pantallas para ver la evolución de los modelos.
La apariencia de la pantalla principal de la aplicación es la siguiente:
PFC: NOMADA
109
Figura 8.1 – Pantalla principal del DA
En este documento sólo se van a explicar los interfaces y clases relacionadas con la
información que se muestra al usuario acerca de los diagnósticos. Esto se debe a que el
resto de las clases (las relacionadas con los modelos) corresponden a otro proyecto, por
lo que no es objetivo de este documento explicarlas aquí.
8.1 Especificación de la implantación
El DA se compone de cuatro paquetes bien diferenciados. Cada uno de ellos se encarga
de una tarea concreta y juntos crean la aplicación. Además, esta división en paquetes
permite que si en un momento determinado se quiere cambiar la forma de tratar los
datos o cambiar el interfaz gráfico por otro que resulte más útil, no haya que desarrollar
una aplicación nueva, sino que basta con cambiar el paquete que convenga. De la misma
forma, si lo que se quiere cambiar es sólo alguna de las funcionalidades del paquete o
una de las clases, basta con cambiar esa clase sin afectar al resto (ésta es una de las
ventajas de la programación orientada a objetos).
PFC: NOMADA
110
Figura 8.2 – Diagrama de paquetes del DA
A continuación se va a dar una breve descripción de lo que contiene cada uno de los
paquetes:
− DA.ui, en este paquete residen las clases cuyo objetivo es presentar la
información al usuario. Necesitamos clases tan distintas como una que
presente información de datos en árboles, otra para mostrar gráficas, otra para
mostrar tablas de datos, listas, etc. Es por este motivo por el que la estructura
del paquete es sumamente compleja. Cabe resaltar que la estructura de interfaz
sólo sirve para que el usuario visualice información en ningún momento se le
permite modificarla.
− DA.data, este paquete engloba las clases que soportan el modelo no
persistente de NOMADA. Aquí se recogen aquellas clases que sirven para
manipular los datos o las que piden los datos al InfoService. Aquí, por lo tanto,
se encuentra implementada (en un de las clases) la lógica necesaria para
realizar la espera activa que se comentaba anteriormente.
− DA.tools, en este paquete se encuentra una clase que se encarga de escribir en
un fichero los eventos y excepciones que se pueden producir durante la
ejecución de la aplicación.
PFC: NOMADA
111
− DA.Infoservice, este paquete también contiene una sola clase que se encarga
de llamar a los métodos necesarios del InfoService para solicitar información.
Su estructura es muy parecida a la de la colección WSDM, ya que, lo que hace
es llamar a los métodos de esa colección y realizar pequeñas transformaciones
de datos.
8.2 DA.ui
Como ya se adelantó antes, este paquete contiene el interfaz de usuario. En este
apartado sólo se explicarán las clases que conciernen a la visualización de diagnósticos.
8.2.1 DiagnosticsManager
Esta clase contiene una lista y dos botones. Es la clase encargada de mostrar al usuario
los diagnósticos inferidos en ese momento, además proporciona al usuario la posibilidad
de ver la traza de ese diagnóstico, es decir, ver como se ha llegado a esa conclusión y de
acceder a la información de otros ensayos o ver todos los diagnósticos que se han
inferido para ese ensayo.
Gráficamente el DiagnosticsManager se ve como lo siguiente:
Figura 8.3 – Zona de diagnósticos en tiempo real
En la figura podemos ver una lista. Esta lista contiene todos los diagnósticos inferidos
en un momento dado (el actual), ya que uno de los objetivos del proyecto era el trabajo
en tiempo real.
PFC: NOMADA
112
A la derecha de la lista podemos ver dos botones. El de arriba sirve para ver la traza de
una de las conclusiones de la lista, mientras que el que está debajo sirve para ver todos
los diagnósticos inferidos para el ensayo y permite ver la información de diagnósticos
de otros ensayos.
Al seleccionar cualquiera de los elementos de la lista se nos mostrará información de si
ese diagnóstico tiene una acción asociada a llevar a cabo para solucionar el problema.
En caso de no tener asociada ninguna acción nos aparecerá un mensaje que indica que
no hay acción asociada a ese diagnóstico.
También se puede acceder a la traza del diagnóstico haciendo doble clic sobre
cualquiera de los elementos de la lista.
8.2.2 DiagnosticHistoryForm
Esta clase genera una ventana para poder ver la información completa relativa al ensayo
que se está viendo en modo online y nos permite acceder a la información relativa a
otros ensayos.
Como ya se explicó antes, la forma de acceder a este formulario es haciendo clic en el
botón de “Diagnóstico completo” que aparece en la ventana del DiagnosticsManager.
Su aspecto gráficamente es el siguiente:
PFC: NOMADA
113
Figura 8.4 – Pantalla de diagnósticos del DA
En él podemos ver como existe un marco superior, en el que se muestra la información
del ensayo del que se están viendo los diagnósticos.
A la derecha podemos ver una lista con todos los diagnósticos inferidos y la
información relevante asociada a éstos (fecha y certeza).
En el marco de la derecha tenemos la posibilidad de elegir si queremos ver todos los
diagnósticos del ensayo actual o, si queremos ver información de algún ensayo ya
realizado que se encuentre almacenado en la BBDD. Si lo que se desea es realizar la
segunda acción, debemos marcar “Histórico”, elegir el ensayo que queremos ver y darle
a cargar.
8.2.3 DiagnosticTraceInTreeForm
A través de esta clase podemos ver como ha llegado el agente coordinador a una
conclusión, esto se realiza mediante un proceso de reconstrucción de la traza a través de
clases contenidas en el paquete DA.data.
PFC: NOMADA
114
Como ya se dijo antes, la forma de acceder a esta ventana es, bien mediante el botón
“Traza Atrás” del DiagnosticsManager o bien, seleccionando un elemento de la lista de
diagnósticos y haciendo doble clic con el ratón sobre él.
El aspecto gráfico de esta ventana es el siguiente:
Figura 8.5 – Pantalla de traza de un diagnóstico
En esta ventana se puede apreciar como la traza atrás se construye partiendo de la
conclusión y llegando hasta las premisas que dispararon la regla. También se puede ver
que el primero en inferir un diagnóstico no es el agente coordinador de diagnósticos, si
no que es el agente que tiene en su dominio el componente que se diagnostica, el que
realiza el diagnóstico previamente.
La ventaja principal de mostrar esto en forma de árbol es que, si no interesa ver la traza
total del diagnóstico (es decir, desde el final hasta el principio) no tenemos por qué
verla, podemos ir profundizando en la traza hasta donde queramos, no se necesita llegar
a ver las premisas si no es necesario.
A continuación se muestra el diagrama UML de estas tres clases:
PFC: NOMADA
115
Figura 8.6 – Diagrama UML simplificado del paquete DA.ui
PFC: NOMADA
116
8.3 DA.data
Este paquete contiene las clases que realizan las operaciones de transformación de
información, además de soportar el modelo de datos.
Como en el caso anterior sólo se van a explicar las clases que tienen relevancia para
obtener la información acerca de diagnósticos. Además, se ha decidido agrupar un
conjunto de clases que no es necesario explicar individualmente.
8.3.1 GeneralStatus
Esta clase es la encargada de mantener el temporizador activo en el DA, recuperando
cada cierto tiempo el estado de los modelos y de los diagnósticos. Cada vez que se
recibe nueva información acerca de alguno de estos estados de lanza un evento, el cual
es recogido por una clase que recoge todos los elementos del interfaz (clase UIForm) y
esta se encarga de notificar los cambios al resto de componentes.
8.3.2 DiagnosticTrace y DiagnosticElementalTrace
La clase DiagnosticTrace encapsula toda la información necesaria para regenerar la
traza de un diagnóstico inferido en un momento dado. La reconstrucción de la inferencia
se lleva a cabo a través de las clases derivadas de DiagnosticElementalTrace, que son
AgentTrace, AgentTraceOK, ConclusionTrace, DerivedPropositionTrace y
PremiseTrace. La clase de tipo AgentTrace recoge la información de la traza de un
determinado agente. En caso de que el agente sea el coordinador, la traza de éste estará
compuesta a su vez por las trazas del resto de agentes. Se puede navegar a través de la
traza gracias a una serie de métodos contenidos en la clase AgentTrace, estos métodos
mantienen punteros a las trazas previas a ésta.
PFC: NOMADA
117
Así mismo, dentro de la traza de un agente podemos encontrar elementos distintos, estos
son, premisas, proposiciones derivadas, reglas que se han disparado y conclusiones.
Estos elementos se implementan a través de las clases PremiseTrace,
DerivedPropositionTrace y ConclusionTrace, se hace necesario, además, mantener una
jerarquía entre ellas basada en una relación causa efecto, ya que unas son causa de que
se originen las otras.
En definitiva, todos los elementos derivados de DiagnosticElementalTrace son objetos
que encapsulan un determinado momento del proceso de inferencia y mantienen una
relación con el momento anterior.
El diagrama de las clases que se ven afectadas por los diagnósticos en el paquete
DA.data se muestra a continuación (el diagrama está simplificado debido a la cantidad
de clases que se ven afectadas):
Figura 8.7 – Diagrama UML simplificado del paquete DA.data
8.4 DA.tools
Este paquete sólo contiene una clase llamada LoggerAplication.
PFC: NOMADA
118
8.4.1 LoggerAplication
Esta clase se encarga de crear un fichero de incidencias producidas en el DA. Este
fichero se puede leer con un procesador de textos cualquiera como el Bloc de notas o el
WordPad.
El diagrama de esta clase es:
Figura 8.8 – Diagrama UML del paquete DA.tools
8.5 DA.Infoservice
Este paquete, como en el caso anterior, contiene una única clase.
8.5.1 WSDM
Esta clase hace de puente entre el InfoService y el DA, siendo este punto el nodo central
de la comunicación entre ambas aplicaciones.
Un diagrama simplificado de esta clase es:
PFC: NOMADA
119
Figura 8.9 – Diagrama UML del paquete DA.Infoservice
PFC: NOMADA
120
9 Base de datos
La base de datos de NOMADA es el medio utilizado como soporte tanto de base de
conocimiento y base de hechos así como para establecer un medio de persistencia que
almacena los distintos ensayos realizados en el sistema.
El acceso a la BBDD está controlado a través del InfoService. Recordamos que el
InfoService es un programa alojado en un servicio Web que se utiliza para insertar
información de configuración del programa, incluyendo la función de añadir nuevas
reglas y proposiciones a la base de diagnósticos además de otros datos necesarios para
el funcionamiento del sistema (variables, modelos para la detección de anomalías, etc.).
Además de funciones para añadir datos el InfoService también contiene funciones para
acceder a esos datos, facilitando la carga de la base de conocimiento en el sistema y
simplificando la captura de nuevos hechos (llamamos hecho a la entrada de nueva
información en el sistema). Aquí se llama hecho a la lectura de las señales que
proporciona cada uno de los componentes a diagnosticar (serán una serie de números),
estos serán procesados por el agente de detección de anomalías que inferirá lo que
realmente son “hechos” para el sistema experto, el cual los introducirá en su base de
hechos y, ayudándose de la base de conocimiento, emitirá una serie de diagnósticos (y
acciones, cuando sea necesario) que supondrán la salida del sistema.
La base de datos de NOMADA está basada en la arquitectura de otra base datos, la del
programa ISPMAT, que tenía el mismo cometido que nuestro sistema actual. Dado que
nuestra aplicación trabaja con los mismos datos y se apoya en las mismas bases que
ISPMAT hay cierto parecido entre las dos (ver Anexo D), pero el diseño de la BBDD
de NOMADA es mucho más flexible y sencillo.
PFC: NOMADA
121
9.1 Base de datos de NOMADA
Para desarrollar la base de datos del actual sistema se ha elegido la plataforma de
Microsoft, Microsoft SQL Server 2000. Se ha elegido ésta y no otra por razones de
comodidad, además, de esta manera se evitan posibles problemas de integración con el
programa desarrollado o el sistema operativo (la aplicación ha sido programada con
Visual Studio .Net y debe funcionar sobre un sistema Windows XP).
SQL Server ofrecía un entorno cómodo para el desarrollo de BBDD, facilitando la
creación y borrado de respaldos de seguridad. Otro de los puntos fuertes de SQL Server
es la gran cantidad de información disponible en lo que a la plataforma se refiere. Por
ello y por cumplir otras características requeridas por la aplicación es por lo que se
eligió esta plataforma.
La BBDD incluye una serie de procedimientos almacenados para crear backups (copias
de respaldo) de determinadas tablas vitales para el funcionamiento del sistema, así como
para el almacenamiento de datos históricos. También se han incluido como
procedimientos almacenados determinadas consultas complejas para que las realice el
gestor de la BBDD en vez del InfoService (módulo de la aplicación que se comunica
con la BBDD).
Como se ha mencionado anteriormente algunas de las tablas de la BBDD antigua han
sido eliminadas, bien porque en la nueva aplicación no se trabaja con los datos de la
misma forma que anteriormente o bien porque esas tablas han pasado a formar parte de
otras. Ejemplo de esto son las tablas que conformaban la estructura del sistema de
adquisición de datos o algunas de las tablas de la base de conocimientos (la tabla de
antecedentes, la de consecuentes y la de diagnósticos han pasado ha formar una sola
tabla llamada “Propositions”).
PFC: NOMADA
122
El siguiente diagrama muestra todas las tablas de la BBDD y, a continuación se explica
cada una de ellas en detalle junto con determinadas consideraciones de diseño
[RIOR00].
Figura 9.1 – Estructura general de la base de datos de NOMADA
En esta ocasión también se aloja la base de hechos y de conocimientos en la misma base
de datos. Además, no se han separado valores de datos y definición de datos. Existe un
caso (en la tabla Variables) donde el valor de la variable se aloja junto con los datos que
la definen, pero esto resulta útil a la hora de cargar la información en la aplicación y de
observar el funcionamiento de la aplicación.
PFC: NOMADA
123
9.1.1 Tablas de configuración
Lo siguiente que explicaremos son las tablas en las que se aloja la configuración del
sistema, este grupo de tablas se utiliza para construir un “esqueleto” del sistema que se
está analizando. Por lo tanto en él se determinan todas las variables que entran a formar
parte de éste, los componentes que estamos tratando y todas las relaciones relevantes
(para el problema que trata) existentes entre ellos.
Empezaremos por las tablas referentes al detector de anomalías (los modelos que se
encargan de detectar anomalías).
Figura 9.2 – Estructura para la persistencia de modelos
Tabla Models:
Esta tabla contiene la definición de los modelos desarrollados con MATLAB y
guardados como archivo XML. Los campos que contiene la tabla son los siguientes:
PFC: NOMADA
124
− modelId: Identificador unívoco del modelo sirve para referenciar al modelo en
otras tablas.
Tipo: int
− modelName: Nombre que se le da al modelo, es utilizado por el usuario para
saber con qué modelo está trabajando.
Tipo: varchar(50)
− modelType: Tipo de modelo, se utiliza para especificar de qué tipo es el
modelo (esto es; perceptrón, mapa autoorganizado, lineal, umbral, etc.).
Tipo: varchar(50)
− compId: Componente asociado al modelo, cada modelo trabaja con un solo
componente (por ejemplo, el compresor, el cual tiene identificador 1).
Tipo: int
− XMLFile: Documento XML del modelo, no se guarda una referencia al
nombre del archivo que contiene el modelo, se guarda el archivo completo en
formato binario. Cuando el sistema multiagente se inicia, los modelos se
cargan de forma automática en este cogiendo las características que definirán
su comportamiento de la BBDD y no de su archivo XML original.
Tipo: image
− fileVersión: Versión del archivo XMLFile.
Tipo: datetime
− modelVersion: Versión del modelo, un modelo puede tener una versión
distinta al archivo XML que lo define.
Tipo: datetime
− isActive: Indica si el modelo está activo o no. Se pueden tener registrados
modelos en la BBDD que por diversas causas aún no hayan sido implantados
en el sistema. Un modelo que no está activo no se cargará en el MAS
(Multiagent System, Sistema multiagente).
Tipo: bit
Tabla RestrModels:
PFC: NOMADA
125
Se utiliza para definir restricciones en los modelos. Actualmente los modelos dados de
alta no tienen ninguna restricción, no obstante en futuros modelos puede ser necesario
establecer restricciones sobre algunos modelos, es por ello que se ha decidido implantar
esta funcionalidad. Los campos de la tabla son los siguientes:
− modelId: Modelo al que se le aplicará la restricción definida.
Tipo: int
− restrId: Identificador unívoco de la restricción que se ha definido.
Tipo: int
− varId: Identificador de la variable sobre la que se aplica la restricción.
Tipo: int
− tagName: Tag asociado a la variable, este tag está asociado con el
identificador de la variable.
Tipo: varchar(50)
− varValue: Valor umbral a partir del cual se aplicará la restricción.
Tipo: float
− operator: Operador que definirá cuando la restricción se cumple o no. Los
operadores definidos son: igual o mayor, igual o menor e igual.
Tipo: int
Tabla ParamModels:
Contiene la relación entre los modelos y los parámetros (variables). En esta tabla
aparecen las variables que son entrada al modelo, estas variables son las que hacen que
el modelo funcione, es decir, que se calcule correctamente si alguna de estas variables
falla o no está activada, el modelo no se calcula. El otro tipo de variables que se
relacionan con el modelo son las variables de salida, los valores de estas variables son
generados por el modelo, cada variable de salida del modelo en la tabla de variables se
dividirá en tres, el valor real de la variable, el valor estimado por el modelo con el que
estemos trabajando (variable Output) y la diferencia entre el valor real y el valor
estimado (variable Error). A continuación se muestran los campos de la tabla:
PFC: NOMADA
126
− modelId: Modelo que tiene asignado el parámetro (variable) definido en la
fila.
Tipo: int
− paramId: Identificador del parámetro, este valor es totalmente independiente
de cualquier tabla. El identificador de parámetro se va asignando
automáticamente según se van introduciendo parámetros de modelos en la
tabla.
Tipo: int
− paramNumber: Es el número de parámetro del modelo. Si un modelo tiene
tres parámetros habrá tres filas con el mismo modelId y cada uno tendrá un
paramNumber (de 1 a 3).
Tipo: int
− paramName: Nombre del parámetro definido en el fichero XML donde se
definía todo el modelo.
Tipo: varchar(50)
− description: Descripción del parámetro, la descripción también se coge del
fichero XML de definición del modelo.
Tipo: varchar(150)
− topSigma: Algunos modelos (como el perceptrón) tienen valores sigma
asociados, estos valores sirven para marcar intervalos en los que se considera
normal que se mueva una variable estimada por el perceptrón. En este caso se
trata del sigma superior. Los valores de los sigma se asocian a variable de
salida, no tiene sentido asociarlos a variables de entrada.
Tipo: float
− bottomSigma: Sigma inferior del parámetro definido.
Tipo: float
− versionDelay: Este campo indica si la variable es una versión retrasada de otra
y cuanto se retrasa.
Tipo: int
− varId: Variable “real” asociada al modelo, tanto si la variable es de entrada
como si es de salida esta columna contendrá un valor referido a una variable
(definido en la tabla Variables)
PFC: NOMADA
127
Tipo: int
− isInput: Indica si el parámetro es de entrada (True) o de salida (False).
Tipo: bit
− outputVarId: Puede tener valor NULL. Cuando una variable es de salida,
ésta, tiene que tener asociadas otras dos variables, una de ellas es la variable
output que contendrá el valor estimado por el modelo. El valor de este campo
hace referencia a una de las variables definidas en la tabla Variables.
Tipo: int
− errorVarId: Puede tener valor NULL. Cuando una variable es de salida, ésta,
tiene que tener asociadas otras dos variables, una de ellas es la variable error la
diferencia entre el valor de la variable (valor real) y el valor estimado por el
modelo. El valor de este campo hace referencia a una de las variables definidas
en la tabla Variables.
Tipo: int
− tagName: Tag (etiqueta) definida para la variable, el tag se coge del fichero
XML que contiene la configuración del modelo. Si el tag se especifica como
“CALC”, cuando se de alta el modelo se nos pedirá asociar ese parámetro a
una variable calculada ya definida, se asociará la variable calculada al campo
varId (la variable real) y se añadirán otras dos: la variable de salida (output) y
la de error.
Tipo: varchar(50)
Las tablas de configuración de modelos son creadas al dar de alta el modelo, por lo
tanto, la información que se recoge en ellas sale directamente del fichero XML y no del
campo XMLFile definido en la tabla Models.
Como se puede observar, las tabas referentes a los modelos de esta estructura de BBDD
son mucho más completas, también son más complejas. Pero la funcionalidad que se
conseguía antes con las tres tablas existentes se puede lograr ahora con dos tablas.
En este grupo de tablas sólo hemos tenido en cuenta las que afectan a los componentes
y las variables.
PFC: NOMADA
128
Figura 9.3 – Estructura para la persistencia de variables y componentes
Tabla Components:
En ella se definen todos los componentes con los que trabaja nuestro sistema, no nos
referimos a trabajo físico (no existe relación física entre el componente y el sistema),
sino a información para crear esa estructura virtual. Esto se hace porque tenemos que
saber a qué componente corresponde que variable o qué reglas afectan a qué
componente, necesitamos saber qué influencia tiene una variable sobre un componente.
Los campos que contiene esta tabla son los siguientes:
− compId, identificador unívoco del componente. Las referencias a
componentes de otras tablas se hacen a través de este índice.
Tipo: int
PFC: NOMADA
129
− compName, nombre del componente, su utiliza para comodidad del usuario.
Tipo: varchar(50)
− parentId, componente padre del componente. Los componentes se estructuran
en forma de árbol, el nodo raíz tendrá este campo a NULL, el resto tendrá una
referencia a un componente de nivel superior. En nuestro caso el nodo raíz se
llama “máquina”. Es imprescindible que exista un nodo raíz a partir del cual
cuelguen el resto de los componentes, de no ser así la aplicación no
funcionaría correctamente.
Tipo: int
− treeDepth, determina en qué nivel se encuentra el componente. Así el nodo
raíz tendrá un nivel 0, los que dependan de él nivel 1, etc.
Tipo: int
− description, este campo permite asociar una pequeña descripción al
componente o anotaciones requeridas que pueden resultar útiles para los
usuarios.
Tipo: varchar(150)
− isLeaf, indica si el componente es un nodo terminal, si lo es, no podrá tener
hijos.
Tipo: bit
− image, nombre del archivo donde se guarda la imagen del componente, puede
ser NULL. Sólo nos interesa tener guardadas las imágenes de los componentes
de primer nivel, si el componente es de otro nivel no tendrá imagen asociada.
Tipo: varchar(50)
− alarms, nombre del archivo donde se guardan las alarmas del componente,
puede ser NULL. Sólo nos interesa tener guardadas las alarmas de los
componentes de primer nivel, si el componente es de otro nivel no tendrá
alarmas asociadas.
Tipo: varchar(50)
Tabla TypeRelations:
PFC: NOMADA
130
En esta tabla se definen las relaciones que pueden existir entre dos o más componentes.
Actualmente esta tabla no se utiliza. Los campos de esta tabla son:
− relTypeId, identificador del tipo de relación.
Tipo: int
− relType, aquí se especifica el tipo de relación.
Tipo: varchar(50)
− description, en este campo se especifica una pequeña descripción sobre en
que consiste la relación asociada.
Tipo: varchar(150)
Tabla Relations:
En esta tabla se especifican las relaciones existentes, así como sus características. No se
dice a qué componentes van asociados, aquí se indica el tipo de relación que es
(definido en TypeRelations), si es binaria, etc. Los campos contenidos en la tabla son:
− relId: identificador unívoco de la relación.
Tipo: int
− relName: nombre de la relación, se recomienda que el nombre sea
identificativo, para poder trabajar con él con facilidad.
Tipo: varchar(50)
− isOriented: indica si la relación es ordenada, es decir, si se va a tener en
cuenta el orden de los componentes que intervienen en la relación.
Tipo: bit
− relTypeId: identificador del tipo de relación que hace referencia a un tipo de
relación definido en TypeRelations.
Tipo: int
− isBinary: indica si la relación se compone sólo de dos componentes (relación
1 - 1).
Tipo: bit
Tabla RRelations:
PFC: NOMADA
131
En esta tabla se definen las relaciones entre componentes. Aquí si se especifica el par de
componentes relacionados, si la relación implica más de dos componentes entonces se
definirán varias líneas con el mismo tipo de relación y los componentes debidamente
asociados. Los campos de esta tabla son:
− relId, identificador de la relación. Debe estar en la tabla Relations.
Tipo: int
− compId_1, componente de la relación. Debe estar en la tabla Components.
Tipo: int
− compId_2, componente de la relación. Debe estar en la tabla Components.
Tipo: int
− relIndex, indica el orden de los pares de componentes dentro de la relación.
Tipo: int
Como se puede observar la información de los modelos se ha visto ampliada
enormemente con respecto al sistema anterior. No obstante las tablas de relaciones no se
utilizan en el sistema por lo que se podría prescindir de ellas.
Tabla Variables:
Ésta es una de las tablas más complejas del sistema, en ella se apoya gran parte de la
funcionalidad de la aplicación. La tabla que aquí se llama Variables equivale a la tabla
BH_SIGNALS de la antigua estructura de BBDD. En esta tabla se incluyen todas las
variables con las que trabaja el sistema, tanto variables que entran directamente, como
aquellas que son consecuencia de cálculos internos y las que son generadas por los
modelos. La tabla contiene los siguientes campos:
− varId, identificador unívoco de la variable, es asignado automáticamente al
dar de alta la variable, el resto de tablas utilizan este índice para referirse a la
variable.
Tipo: int
− globalId, identificador global de la variable, asignado por el usuario. Es útil
para identificar a las variables, pero no se utiliza.
PFC: NOMADA
132
Tipo: varchar(2000)
− varName, nombre que se le asigna a la variable, este nombre, al contrario que
el anterior, se usa en momentos clave de la aplicación. Cuando tenemos
variables calculadas, este es el nombre que aparece en la fórmula para el
cálculo de la variable.
Tipo: varchar(50)
− varUnits, unidades en que se mide la variable.
Tipo: varchar(50)
− varValue, último valor recibido para la variable, esto en realidad no es un
parámetro de configuración y no se utiliza, pero es útil a la hora de comprobar
el correcto funcionamiento del sistema.
Tipo: float
− minRank, valor umbral por debajo del cual la variable se trata como si no
funcionase bien, es decir, no se tiene en cuenta para realizar las operaciones,
como por ejemplo, el cálculo de modelos.
Tipo: float
− maxRank, valor umbral por encima del cual la variable se trata como si no
funcionase bien, es decir, no se tiene en cuenta para realizar las operaciones,
como por ejemplo, el cálculo de modelos.
Tipo: float
− certainty, certeza asociada a la variable, este valor repercutirá en la certeza de
los diagnósticos inferidos por el sistema.
Tipo: float
− description, pequeña descripción de la variable, o datos que puedan resultar
relevantes a la hora de trabajar con ella.
Tipo: varchar(150)
− compId, identificador del componente al que pertenece la variable, una
variable tiene efecto sobre un componente.
Tipo: int
− isActive, indica si la variable está activa o no. Una variable que no esté activa
será como si no existiese, los modelos que la contienen no la tendrán en
PFC: NOMADA
133
cuenta, se pueden estar recibiendo datos de ella pero no será tenida en cuanta
por el sistema.
Tipo: bit
− varType, tipo de variable. En la aplicación hay definidos actualmente dos
tipos de variable, las variables de tipo 1 son variables directas, significa que
entran directamente en el sistema o que no se realiza ninguna operación sobre
ella, su valor no depende de otra variable, el tipo dos es para variables que
dependen de otras variables, es el caso de las variables calculadas o las
variables retrasadas.
Tipo: int
− tagName, tag asociado a esa variable, por definición sólo las variables de tipo
1 que no son salida de modelos (es decir, que entran de fuentes externas)
tienen un tag definido.
Tipo: varchar(50)
− varFunction, función asociada a una variable calculada, esta función se define
sobre variables directas, retrasadas (variables especiales) y constantes. Sólo
tendrán este campo relleno las variables calculadas, no las directas. Las
variables retrasadas también son variables calculadas, pero se permite que una
variable retrasada forme parte de la fórmula (podría existir un problema de
referencias circulares, pero se ha diseñado la aplicación para que soporte esta
posibilidad).
Tipo: varchar(2000)
− varVersion, fecha en la que fue creada la variable.
Tipo: datetime
Tabla RVariables:
Está tabla define relaciones entre variables, nos referimos a las relaciones que existen
entre las variables calculadas (un valor de una variable puede depender de la suma de
otras dos). Tiene los siguientes campos:
− varId_1, identificador de la variable dependiente. Tiene que estar en la tabla
Variables.
PFC: NOMADA
134
Tipo: int
− varId_2, identificador de la variable de la que se depende. Tiene que estar en
la tabla variables.
Tipo: int
Tabla LogicStates:
La tabla define el estado lógico de las variables dependiendo de su valor. Los estados
lógicos son una parte vital a la hora de hacer funcionar el sistema experto, ya que, con
ellos definimos las proposiciones de entrada al sistema (los antecedentes). Esta tabla es
una parte de la tabla BH_ESTADOS, en ella aún no se relacionan las señales con su
estado y no se indica si el estado provoca anomalía o no (esto en realidad se ha sacado
de la parte de base de hechos), de existir esto ahora esta almacenado en la tabla
SystemMessages que se verá más adelante. A continuación, se muestran los campos de
la tabla:
− sequence, es un número de secuencia que se le da al estado, no tiene mayor
relevancia (se pone, pero no se usa). Cuando se quiere referenciar un estado se
usa su nombre directamente.
Tipo: int
− state, indica el nombre del estado.
Tipo: varchar(50)
Tabla RLogicStates:
Esta es la otra parte de la tabla anterior BH_ESTADOS, en ella se relacionan las señales
con su estado dependiendo del valor que tenga. Aquí se especifican valores a partir de
los que la variable tendrá asociado a un estado. Sólo aparecen las variables que son
relevantes para el sistema y no todas las variables que existen. Sus campos son:
− varId, identificador de la variable a la que se le va a asociar el estado. Debe
estar en la tabla Variables.
Tipo: int
PFC: NOMADA
135
− varValue, valor de la variable a partir del cual la variable se encuentra en el
estado especificado (en realidad la relación es de mayor o igual).
Tipo: float
− state, estado que toma la variable si es mayor o igual que el valor especificado
en la columna anterior. El estado debe existir en la tabla LogicStates.
Tipo: int
El siguiente grupo de tablas, alberga la base de conocimiento, este grupo es utilizado
para inferir los diagnósticos del sistema experto, son las tablas que contienen el
“conocimiento del sistema”, lo que le hace inteligente.
Esta estructura de tablas es mucho más sencilla que la anterior (la de la BBDD de
ISPMAT). Se han unido las tablas de antecedentes y consecuentes en una sola llamada
Propositions.
Figura 9.4 – Estructura para la persistencia de reglas (conocimiento)
Tabla Propositions:
PFC: NOMADA
136
Como se comentó anteriormente esta tabla contiene tanto los antecedentes como los
consecuentes de las reglas, los consecuentes pueden tener asociadas acciones
correctoras. Los campos de esta tabla son los siguientes:
− propId, identificador unívoco de la proposición, se asigna automáticamente y
sirve para referirnos a la proposición en otras tablas.
Tipo: int
− propName, nombre de la proposición, cuando se da de alta la proposición se
pide que se le asigne un nombre. Éste realmente es poco utilizado pero
conviene que sea un nombre que identifique con claridad la proposición de la
que se trata.
Tipo: varchar(50)
− compId, componente al que se le asocia la proposición. No tiene gran
relevancia, ya que se podría pensar que si asociamos un componente a una
proposición sólo podremos actuar sobre las variables de ese componente, pero
no se restringe el acceso a ninguna variable por lo que no importa a qué
componente se le asocie. En cambio, nos es muy útil a la hora de diagnosticar
sólo un componente ya que nos permite filtrar los diagnósticos por este
elemento (por ejemplo, sería posible ver los diagnósticos que son sólo del
compresor).
Tipo: int
− isDiagnostic, determina si una proposición es diagnóstico (consecuente) o no,
en caso de no serlo, esto implica que se trata de un antecedente y viceversa.
Tipo: bit
− varId, para las proposiciones que no son diagnóstico debe haber una variable
asociada (un antecedente es una variable asociado a un estado lógico), en esta
columna se indica el identificador de la variable del antecedente.
Tipo: int
− varLogicState, valor lógico asociado a la proposición. Sólo se aplica si es un
antecedente, indica con qué estado lógico se asocia la variable, este par
(variable – estado lógico) debe ser coherente con lo que haya en la tabla
RLogicStates.
PFC: NOMADA
137
Tipo: varchar(50)
− description, pequeña descripción de la proposición en el caso de los
antecedentes, y diagnóstico que se mostrará al usuario en el caso de los
consecuentes. Si la proposición es diagnóstico (consecuente), esto es lo que se
mostrará al usuario si se cumplen las premisas asociadas a éste.
Tipo: varchar(150)
− actions, acciones correctoras a llevar a cabo. Sólo aparecerán en los
diagnósticos (consecuentes), no puede haber acciones correctoras en los
antecedentes. Otro apunte es que, no todos los diagnósticos tienen que tener
por obligación acciones correctoras.
Tipo: varchar(150)
Tabla Rules:
Contiene los nombres de las reglas que existen en el sistema. La tabla sólo consta de un
identificador, el nombre de la regla y una prioridad, a continuación se explica cada
campo:
− ruleId, identificador unívoco para referenciar a las reglas en otras tablas.
Tipo: int
− ruleName, nombre de la regla, se recomienda que sea un nombre relacionado
con la regla para poder identificarla con comodidad, pero no se usa.
Tipo: varchar(50)
− priority, prioridad de la regla. Puede haber reglas que tengan que ser
disparadas antes que otras, la prioridad indica un orden de disparo de reglas (1
es máxima prioridad).
Tipo: int
Tabla RPropositions:
En ella es donde realmente están creadas las reglas. Contiene la relación entre
antecedentes y consecuentes. Sus campos son:
− ruleId, identificador de la regla. Debe existir en la tabla Rules.
PFC: NOMADA
138
Tipo: int
− propId, identificador de la proposición a la que nos referimos, puede ser un
antecedente o un diagnóstico. Debe existir en la tabla Propositions.
Tipo: int
− isPremise, indica si la proposición es un antecedente o no. Se puede dar el
caso de el consecuente de una regla sea el antecedente de otra, por ello no
basta con decir si la proposición es diagnóstico o no en la tabla Propositions,
además se debe especificar en esta tabla si está actuando como antecedente o
consecuente en la regla.
Tipo: bit
− certainty, certeza de la regla, toda regla tiene que tener una certeza asociada
que, combinada con la certeza de las variables, nos dará la certeza del
diagnóstico. Esto se debe a que no se pueden asegurar las cosas siempre al
100%, en ocasiones sólo tenemos una probabilidad de que ocurran. La certeza
en la regla debe ser asignada por el experto según su propia experiencia.
Tipo: float
Con esto terminaríamos la parte de configuración de la aplicación, tal como se hizo con
la BBDD antigua. No obstante en este caso debemos añadir otras dos tablas al grupo de
tablas de configuración. Una de ellas es la tabla que define los estados de anomalía en
los que se encuentra un modelo (nos referimos a la tabla SystemMessages antes
mencionada). La otra tabla es la tabla de propiedades para la segmentación, se
necesitaba de un medio persistente para guardar estos parámetros y se ha aprovechado
la BBDD para ello debido a la seguridad que proporciona y a la facilidad que se tiene
para crear métodos que lean y modifiquen valores de las tablas alojadas en el servidor.
A continuación se definen estas tablas.
PFC: NOMADA
139
Figura 9.5 – Tablas de propiedades de segmentación y mensajes del sistema
Tabla SystemMessages:
Esta tabla sirve, como ya se dijo antes, para indicar en qué estado de anomalía se
encuentra un modelo. Un modelo puede encontrarse en varios estados de anomalía,
cuando un modelo se encuentra en este estado su valor se almacena en la BBDD, un
modelo en estado anómalo tendrá un código de retorno especial e interesa tener
almacenados los modelos que no están funcionando correctamente (una salida anormal
de un modelo puede indicar el mal estado de una entrada, lo que podría llevar a inferir
que el componente está en mal estado). Las columnas de esta tabla se describen a
continuación:
− msgId, identificador del mensaje. Un modelo devolverá (si se termina de una
forma que no es la esperada, nos referimos a un estado distinto de
“funcionando”) alguno de estos códigos de mensaje.
Tipo: int
− msgText, texto asociado al identificador, nos indica en qué tipo de estado ha
terminado el modelo, puede ser estado de anomalía puntual, no aplicable, etc.
Tipo: varchar(200)
− msgPriority, este campo no se usa, indica la urgencia que tiene ese estado
con respecto a los demás.
Tipo: int
Tabla Properties:
PFC: NOMADA
140
Esta tabla contiene los parámetros que se precisan para realizar la segmentación. La
segmentación es un proceso complejo que se realiza al inicio de la aplicación (forma
parte de un preproceso de datos). Los campos que tiene esta tabla son:
− longitud, dimensión del espectro.
Tipo: bigint
− frec_0, primera frecuencia del espectro.
Tipo: bigint
− dfrec, incremento de la frecuencia.
Tipo: bigint
− longEspSeg, número de componentes del espectro segmentado (ha de ser par).
Tipo: bigint
− anchoSeg, ancho de cada segmento.
Tipo: bigint
9.1.2 Tablas dinámicas
Las tablas que aparecen a continuación son tablas dinámicas que se van modificando
por los distintos módulos del programa. Estas tablas contienen las entradas de valores
de las distintas señales, así como las salidas producidas por estos valores después de
haber pasado por los modelos, también existe otra tabla, que es la que contiene los
diagnósticos inferidos al haber pasado las salidas de los modelos por el sistema experto
implantado en la aplicación.
Otra necesidad que existe, es el saber qué ensayos se han sido calculados, para ello
existe una tabla que contiene todos los ensayos introducidos en el sistema y otra con la
relación de las versiones que hay en cada ensayo. La última tabla de este bloque
contiene los estados de los modelos (si tienen un funcionamiento normal, estado
anómalo, no se pueden calcular, etc.). Ahora se va a ver cada una de las tablas por
separado.
PFC: NOMADA
141
Figura 9.6 – Tablas que se modifican durante la ejecución
Las tablas se muestran por orden de modificación, es muy importante entender de dónde
sale y a dónde va cada uno de los datos de esta tabla así como de dónde se cogen cada
uno de los datos de la misma para entender cómo funciona el sistema.
Tabla Ensayos:
Esta tabla contiene todos los ensayos que hay dados de alta en el sistema. Un ensayo se
da de alta en el momento en el que se seleccionan en el PIEntry dos ficheros, se mete el
nombre de la máquina y del compresor y se le da a aceptar, en ese momento se crea una
PFC: NOMADA
142
tabla en la BBDD con la información de ese ensayo. Luego la tabla es leída por el DA,
en él podemos seleccionar un ensayo calculado (ver columna isCalculated) y ver toda la
información que almacena. Las columnas que contiene son:
− ensayo, es el número de ensayo, cuando s inicia el InfoService, se coge el
último número de ensayo y se carga en el campo _currentEnsayo del
DataManager, esto es útil para el MAS y para DA a la hora de ver los ensayos
Online. El ensayo sólo se modifica mediante el PIEntry, el resto de módulos
de la aplicación sólo lo leen, en caso de que lo necesiten.
Tipo: bigint
− name, nombre del ensayo, el nombre del ensayo se compone del nombre de la
máquina y la fecha en la que fue dado de alta el ensayo, como se explicó
anteriormente, un ensayo se da de alta cuando se introducen los datos del
nuevo ensayo y se le da a aceptar.
Tipo: varchar(50)
− isCalculated, indica si el ensayo se ha calculado, que un ensayo haya sido
calculado significa que ha pasado por el MAS, por lo tanto tiene resultados
asociados, estado de los modelos, diagnósticos, etc. Y se puede ver desde el
DA. Un ensayo que no ha sido calculado tendrá en este campo un 0. Cuando
se da de alta un ensayo se pone este bit a 0 indicando que no se ha calculado,
cuando el MAS coge este ensayo lo primero que hace es poner este bit a 1 para
indicar que existen diagnósticos parciales (si el ensayo está Online, es decir,
siendo calculado en ese momento) o que tiene todos los diagnósticos (ya ha
sido calculado y, por lo tanto, se pueden ver sus resultados seleccionando el
modo histórico). Si un ensayo no ha sido calculado, su índice no aparecerá en
las tablas de StatusModels, HistoricModels y DiagnosticTrace, pero sí tendrá
datos en las tablas PIHistoric y UniversalSystemTime.
Tipo: bit
− valueTimeStamp, indica la hora en la que se da de alta el ensayo. Esta hora es
tomada justo antes de ejecutar la función para meter en la BBDD la
información del ensayo y es la hora que aparece en el nombre del ensayo
detrás del de la máquina.
PFC: NOMADA
143
Tipo: datetime
− maquina, almacena el nombre de la máquina de la que se han tomado los
datos. Es importante almacenar el nombre de la máquina para luego poder
hacer comparaciones entre los distintos ensayos de ésta, para así poder ver la
evolución del componente.
Tipo: varchar(50)
− compresor, almacena el nombre del compresor. El compresor de una máquina
puede cambiar (y cambia) cada cierto tiempo, debido a que el compresor es el
componente que estamos midiendo es importante almacenar su nombre, ya
que no tiene sentido comparar dos ensayos de una máquina a la que se le ha
cambiado el compresor, esto es porque los resultados saldrían notablemente
distintos.
Tipo: varchar(50)
− component, identificador del componente al que pertenece el ensayo,
actualmente el único valor posible es 1 (compresor). Este valor deberá
corresponderse con un alguno de los existentes en la columna compId de la
tala Components.
Tipo: int
Tabla UniversalSystemTime:
Contiene una relación de las versiones de un ensayo y la hora en la que fueron dadas de
alta. Esta tabla es muy útil para controlar que todas las versiones que están en las otras
tablas realmente existen porque han sido dadas de alta. Una versión se da de alta en el
momento en que se introducen nuevos datos en el PIHistoric. La tabla se modifica
mediante el PIEntry, pero es transparente para el usuario. Sus campos son:
− valueVersion, número de versión que se da de alta. Cada lectura de una ristra
de datos corresponde a una versión.
Tipo: bigint
− valueTimeStamp, fecha en la que se da de alta la versión, es muy útil para ver
si alguna versión se ha retrasado (actualmente que esto ocurra es físicamente
PFC: NOMADA
144
imposible, pero en un sistema distribuido con toma de datos de varias fuentes
esto sería posible).
Tipo: datetime
− ensayo, número de ensayo al que corresponde la versión.
Tipo: bigint
Tabla PIHistoric:
Esta tabla es fundamental para el sistema, sin ella no funcionaría nada, constituye la
entrada al sistema multiagente. Contiene todos los valores leídos de los ficheros o de los
sensores de los que se tomen los datos. En realidad las variables que se almacenan en
esta tabla son todas las requeridas por los modelos para funcionar. La tabla es
modificada por el PIEntry al añadir nuevos datos y es leída por el MAS cuando va a
calcular un ensayo. También es leída por el DA para realizar determinadas
representaciones de los datos. Los campos contenidos en esta tabla son:
− varId, es el identificador de la variable a la que nos referimos. Esta variable
debe existir en la tabla Variables vista anteriormente. Aunque desde el PIEntry
entran los tags de las variables, en el InfoService obtenemos los
identificadores de la misma (directamente de la tabla Variables, por ello es
necesario que las variables existan). Si está entrando una variable que no está
registrada en la BBDD, ésta no se grabará. El campo se corresponde con la
columna varId de la tabla Variables.
Tipo: int
− valueVersion, versión de la variable, este valor también se guarda en la tabla
UniversalSystemTime vista anteriormente. Se guarda el valor de la versión
porque interesa tenerlo a la hora de pedir determinados valores de las
variables.
Tipo: bigint
− valueTimeStamp, fecha de la versión, su valor es igual que el que hay en la
tabla UniversalSystemTime.
Tipo: datetime
PFC: NOMADA
145
− varValue, valor de la variable, entra desde el PIEntry. Este valor es el que
entra luego en el MAS, es utilizado en ocasiones por el DA, etc. Sin estos
valores el sistema no podría trabajar.
Tipo: float
− tagName, tag asociado a la variable, sólo las variables de entrada tienen tag, si
una variable no tiene tag significa que, obligatoriamente, es de salida. Una
variable de salida puede o no, tener tag asociado. El campo se corresponde con
alguno de la columna tagName de la tabla Variables.
Tipo: varchar(50)
− ensayo, ensayo al que corresponde la fila. Se necesita para trabajar con los
valores de las variables. Es necesario saber en todo momento sobre qué ensayo
se trabaja porque dos ensayos son independientes entre sí.
Tipo: bigint
Tabla StatusModels:
Esta tabla contiene el estado de los distintos modelos que existen en el sistema
(actualmente 6) para cada versión y ensayo. Con ella se sabe si los modelos están
funcionando en estado anómalo o no. En realidad si un modelo está funcionando no se
registra su estado en la tabla StatusModels simplemente se omite esta información. La
tabla es modificada (escrita) por el MAS y leída por el DA, el PIEntry no necesita saber
en absoluto de la existencia de esta tabla. Como sólo se registran los estados que no
están en estado funcionando, no existe un registro para cada ensayo en cada versión,
sino que sólo estarán dados de alta los modelos en estado anormal. Sus columnas son:
− modelStatusId, identificador unívoco para una fila. Esta columna se rellena
de forma automática. No se utiliza para nada, sólo sirve para tener un control
del número de filas que se han insertado, pero no existe una funcionalidad
crítica para el programa.
Tipo: bigint
− statusVersion, número de versión. Su función es la misma que en todas las
tablas, saber con que versión estamos trabajando, es importante para pedir los
datos de manera adecuada.
PFC: NOMADA
146
Tipo: bigint
− modelId, identificador del modelo. Este identificador debe existir en la tabla
Models vista anteriormente. Este campo es el único vínculo que tenemos para
reconocer el modelo con el que estamos trabajando. El campo se corresponde
con la columna modelId de la tabla Models.
Tipo: int
− statusCode, código de estado que indica el estado en el que se encuentra el
modelo (dentro de los estados de anomalía). Los posibles estados de un
modelo están definidos en la tabla SystemMessages, en esta columna se
guarda uno de los msgId definidos en esa tabla.
Tipo: int
− ensayo, identificador del ensayo con el que se está trabajando, su función es la
misma que la de la columna versión (un ensayo y una versión determinados
identifican unívocamente una fila).
Tipo: bigint
Tabla HistoricModels:
Contiene las variables calculadas en el MAS, estas variables son salidas de los modelos,
es decir, la tabla almacena todas las variables de tipo output para cada modelo, y esto,
para cada versión de cada ensayo. No se almacena el valor de las variables de tipo error,
además de porque no se necesita, porque es el resultado de la variable real, cuyo valor
ya está registrado en la tabla PIHistoric, menos el valor de la variable estimada que es lo
que se está almacenando en esta tabla. La tabla es escrita por el MAS y leída por el DA
para dibujar gráficas y ver la evolución de los datos. Las columnas que contiene son:
− varId, identificador de la variable. Este valor tiene que estar dado de alta en la
tabla Variables. Como ya se ha comentado antes los identificadores de las
variables que encontraremos aquí se corresponderán todos con variables de
tipo output.
Tipo: int
− valueVersion, versión con la que se está trabajando (la función es la misma
que la de la tabla PIHistoric).
PFC: NOMADA
147
Tipo: bigint
− varValue, valor de la variable. Este valor es el estimado por el modelo,
cuando un modelo realiza un cálculo con las variables de entrada (que coge de
la tabla PIHistoric) almacena su salida en esta tabla.
Tipo: float
− valueTimeStamp, fecha en la que se escribe la información que se almacena
en la fila. La función de esta columna es la de tener registradas cuando se ha
producido el cálculo de la versión para el ensayo dado. Se puede tener
almacenado un ensayo y calcularlo un mes después.
Tipo: datetime
− ensayo, ensayo del que se trata (la función es la misma que la de la tabla
PIHistoric).
Tipo: bigint
Tabla DiagnosticTrace:
Aquí se almacenan todos los diagnósticos inferidos por el sistema, en realidad sólo se
calculan diagnósticos cuando el MAS detecta que los estados de los modelos difieren
entre una versión y la versión anterior, por este motivo puede darse el caso de tener
diagnósticos en la versión 1 y que la siguiente versión diagnosticada sea la 8. Es
importante saber si el diagnóstico viene de un agente coordinador de diagnósticos o no.
Los diagnósticos de un agente coordinador son diagnósticos finales, mientras que los
que no lo son, son simplemente diagnósticos intermedios que se guardan para poder ver
la traza del diagnóstico (de donde sale) desde su inicio hasta el final. La tabla es escrita
por el MAS y leída por la parte de diagnósticos de DA. Sus columnas son las que se
muestran a continuación:
− id, identificador unívoco para una fila. Esta columna se rellena de forma
automática. No se utiliza para nada, sólo sirve para tener un control del
número de filas que se han insertado, pero no existe una funcionalidad crítica
para el programa.
Tipo: int
PFC: NOMADA
148
− diagVersion, número de versión que se está diagnosticando, los números de
versión no tienen porqué ser consecutivos (ya se explicó antes el motivo).
Tipo: bigint
− agentName, nombre del agente que ha hecho el diagnóstico. Este agente
puede ser un coordinador o uno de los agentes parciales que existen.
Llamamos agente parcial a aquel agente que sólo diagnóstica un componente,
es decir, tiene una funcionalidad reducida dentro del sistema.
Tipo: varchar(50)
− isCoordinator, esta columna indica si el agente es coordinador o no. Sólo el
agente coordinador de diagnósticos infiere diagnósticos finales (los que se
muestran en los históricos).
Tipo: bit
− traceIndex, este campo se utiliza para reconstruir la traza de diagnóstico. Sólo
una fila con este campo igual a cero se considera diagnóstico final.
Tipo: int
− ruleId, identificador de la regla que se ha disparado para inferir el diagnóstico.
No siempre que una regla ha disparado un diagnóstico, si la regla ha ‘escalado’
de un agente parcial al agente coordinador la regla que infirió el diagnóstico es
NULL. Como es natural, la regla deberá existir en la tabla Rules y esta
columna se corresponde con la columna ruleId de dicha tabla.
Tipo: int
− propId, identificador de la proposición asociada a la regla. La proposición
puede ser tanto un antecedente como un consecuente. Es más, existen en la
tabla los dos tipos de proposiciones asociados a la misma regla, interesa tener
esto en cuanta, para poder ver la traza de la proposición. A la hora de mostrar
los diagnósticos sólo de cogen los diagnósticos finales, para no crear
confusiones al usuario. El valor de esta columna se corresponde con la
columna propId de la tabla Propositions.
Tipo: int
− propCert, certeza de la proposición asociada. Si la proposición asociada es
un antecedente su certeza será cero, ya que, aunque las proposiciones tienen
una certeza por el hecho de estar, no siempre se tiene en cuenta. Si la certeza
PFC: NOMADA
149
es de un consecuente, que es lo más natural, ésta vendrá dada por las fórmulas
aplicadas en el MAS.
Tipo: float
− comments, comentarios acerca del diagnóstico (no se utiliza).
Tipo: char(500)
− ensayo, ensayo del que se trata.
Tipo: bigint
Con esto habríamos terminado la explicación de todas las tablas relevantes que existen
en la BBDD.
9.1.3 Gestión de históricos
Otro punto a tratar es la gestión de históricos, ésta es llevada a cabo por dos
procedimientos almacenados en la base de datos [NIEL03] que son los siguientes:
− Procedimiento BACKUPS: Este procedimiento ha de estar programado para
ejecutarse muy frecuentemente. Es el encargado de coger todos los datos de las
tablas PIHistoric e Historicmodels que tengan una antigüedad mayor o igual
que el número de horas que se le pase como parámetro, y copiarlos en la tabla
HistoricDataBackup. De este modo, se consigue que en las tablas PIHistoric e
HistoricModels solo estén los últimos datos recogidos o calculados, y las
aplicaciones que acceden a ellos realizan las consultas de manera más
eficiente, puesto que el tamaño de las tablas es grande, pero no
desproporcionado. Cabe señalar que tanto la tabla PIHistoric como
historicModels incorporan índices de búsqueda que incrementan todavía más
la eficiencia.
− Procedimiento HISTORY_BACKUPS: Este procedimiento ha de ejecutarse
de manera esporádica, una vez cada mes por ejemplo, y dependiendo del
número de variables y modelos que haya incorporado el sistema. Es el
PFC: NOMADA
150
encargado de coger los datos que se encuentran en la tabla
HistoricDataBackup y copiarlos en una tabla creada dinámicamente con el
nombre HistoryData_<ensayo1>_a_<ensayo2>, donde <ensayo1> y
<ensayo2> son los valores de los ensayos entre los cuales se encuentran todas
las filas copiadas. Finalmente, el procedimiento registra esta copia en la tabla
RegistryBackup, con el fin de que las aplicaciones que integran el sistema
conozcan de la existencia de esta nueva tabla y puedan consultarla. Tanto la
tabla HistoricDataBackup como las tablas que se crean dinámicamente
incorporan también índices que mejoran la eficiencia de las consultas sobre el
histórico. En caso de que el rendimiento de las consultas empeore, o que no
sea necesario el mantener algunas de las tablas dinámicamente creadas, éstas
pueden ser desvinculadas del sistema simplemente borrando la fila
correspondiente de la tabla RegistryBackup. Así mismo, la tabla borrada
podría ser exportada a formato Excel o cualquier otro a través del
procedimiento “Exportar Datos” de Microsoft SQL Server.
PFC: NOMADA
151
10 Presupuesto del proyecto
10.1 Mediciones
0 Diseño de sistema multiagente para la detección y diagnóstico de anomalías 1 Lanzamiento 2 Construcción de la plataforma que donde se desarrollará el sistema 2.1 Diseño de la plataforma donde se desarrollará el sistema 2.2 Codificación de la plataforma 2.3 Introducción de la información primaria 3 Construcción de un entorno abierto y flexible de diagnóstico 3.1 Diseño del entorno de diagnóstico 3.2 Codificación del entorno 4 Elaboración de módulo de recogida de información 4.1 Diseño del módulo de recogida de información 4.2 Codificación del módulo 4.3 Pruebas del módulo 5 Elaboración de agente diagnóstico 5.1 Diseño del agente 5.2 Codificación del agente 6 Desarrollo de una interfaz para los resultados del agente diagnóstico 6.1 Diseño de la interfaz 6.2 Codificación de la interfaz 7 Integración de los componentes en su entorno 7.1 Análisis de la integración 7.2 Realización de la integración 8 Prueba de la aplicación 9 Cierre del proyecto 9.1 Acabado de la documentación 9.2 Entrega de la documentación
PFC: NOMADA
152
10.2 Precios unitarios
Id. Nombre Precio (€)1 Lanzamiento 126,252 Construcción de la plataforma que donde se desarrollará el sistema 1994,753 Construcción de un entorno abierto y flexible de diagnóstico 1136,254 Elaboración de módulo de recogida de información 909,005 Elaboración de agente diagnóstico 1136,256 Desarrollo de una interfaz para los resultados del agente diagnóstico 858,507 Integración de los componentes en su entorno 1010,008 Prueba de la aplicación 252,509 Cierre del proyecto 757,50
Total proyecto: 8181,00
10.3 Sumas parciales
1 Lanzamiento
Total (€): 126,25
2 Construcción de la plataforma que donde se desarrollará el sistema
2.1 Diseño de la plataforma donde se desarrollará el sistema 757,50
2.2 Codificación de la plataforma…………………………………………. 1010,00
2.3 Introducción de la información primaria……………………………. 227,25
Total (€): 1994,75
3 Construcción de un entorno abierto y flexible de diagnóstico
3.1 Diseño del entorno de diagnóstico…………………………... 631,25
3.2 Codificación del entorno…………………………………….. 505,00
Total (€): 1136,25
PFC: NOMADA
153
4 Elaboración de módulo de recogida de información
4.1 Diseño del módulo de recogida de información……………. 505,00
4.2 Codificación del módulo……………………………………... 353,50
4.3 Pruebas del módulo………………………………………….. 50,50
Total (€): 909,00
5 Elaboración de agente diagnóstico
5.1 Diseño del agente……………………………………………... 631,25
5.2 Codificación del agente………………………………………. 505,00
Total (€): 1136,25
6 Desarrollo de una interfaz para los resultados del agente diagnóstico
6.1 Diseño de la interfaz…………………………………………. 505,00
6.2 Codificación de la interfaz…………………………………... 353,50
Total (€): 858,50
7 Integración de los componentes en su entorno
7.1 Análisis de la integración……………………………………. 505,00
7.2 Realización de la integración………………………………... 505,00
Total (€): 1010,00
8 Prueba de la aplicación
Total (€): 252,50
PFC: NOMADA
154
9 Cierre del proyecto
9.1 Acabado de la documentación………………………………. 757,50
9.2 Entrega de la documentación………………………………... 0,00
Total (€): 757,50
PFC: NOMADA
155
10.4 Presupuesto general
Id. Nombre de la tarea Horas Total 1 Lanzamiento 25 126,252 Construcción de la plataforma que donde se desarrollará el sistema 395 1994,752.1 Diseño de la plataforma donde se desarrollará el sistema 150 757,502.2 Codificación de la plataforma 200 1010,002.3 Introducción de la información primaria 45 227,253 Construcción de un entorno abierto y flexible de diagnóstico 225 1136,253.1 Diseño del entorno de diagnóstico 125 631,253.2 Codificación del entorno 100 505,004 Elaboración de módulo de recogida de información 180 909,004.1 Diseño del módulo de recogida de información 100 505,004.2 Codificación del módulo 70 353,504.3 Pruebas del módulo 10 50,505 Elaboración de agente diagnóstico 225 1136,255.1 Diseño del agente 125 631,255.2 Codificación del agente 100 505,006 Desarrollo de una interfaz para los resultados del agente diagnóstico 170 858,506.1 Diseño de la interfaz 100 505,006.2 Codificación de la interfaz 70 353,507 Integración de los componentes en su entorno 200 1010,007.1 Análisis de la integración 100 505,007.2 Realización de la integración 100 505,008 Prueba de la aplicación 50 252,509 Cierre del proyecto 150 757,509.1 Acabado de la documentación 150 757,509.2 Entrega de la documentación 0 0,00 Total: 1620 8181,00
Precio (€) / hora: 5,05
PFC: NOMADA
156
10.5 Licencias de software necesarias
10.5.1 Licencias para el desarrollo
Precio (€) Wind. XP Professional………………………………………………….. 317,99 Microsoft SQL Server 2000…………………………………….……… 1449,99 Visual Studio .NET Enterprise Architect 2003……………………... 565,99 Microsoft Office 2003…………………………………………………… 549 Visio 2003…………………………………………………………………. 744 Total: 3626,97
10.5.2 Licencias para la implantación
Precio (€) Wind. XP Professional………………………………………………….. 317,99 Microsoft SQL Server 2000…………………………………….……… 1449,99 Total: 1767,98
PFC: NOMADA
157
11 Conclusiones
El sistema NOMADA se ha constituido como una aplicación dedicada a la detección y
diagnóstico de anomalías. La implementación actual de NOMADA se sitúa el sector
ferroviario, concretamente en la detección y diagnóstico de anomalías en los
componentes de una máquina de tren de Cercanías RENFE modelo UT-450. Por el
momento, nuestro sistema sólo se centra en uno de los componentes de la unidad, el
compresor, pero su diseño permite la ampliación del dominio de conocimiento de
NOMADA hasta llegar a abarcar a toda la estructura del tren.
Esto se ha logrado gracias a un buen diseño, tanto en lo que a aplicaciones
independientes se refiere, recordemos que NOMADA se compone de módulos que
pueden funcionar por si solos, como al diseño de un sistema multiagente y al modelo de
datos que integran algunas de sus aplicaciones.
En cuanto a la arquitectura general de NOMADA, podemos ver éste como un sistema
construido con una arquitectura n-tier (o n-layer), compuesto a su vez de un conjunto de
aplicaciones autónomas y especializadas que interactúan mediante servicios Web. Esto
hace que, si en un determinado momento se precisa del cambio de alguna de estas
aplicaciones, se pueda realizar sin afectar al resto del sistema. Una ventaja importante a
tener en cuenta es que gracias a esta arquitectura podemos tener una deslocalización de
las aplicaciones en distintas máquinas dentro de una red. Por ejemplo, podemos tener
una aplicación de entrada de datos ejecutándose en una máquina que esté
proporcionando datos a la aplicación multiagente que a su vez puede estar distribuida
entre varias máquinas, para, todo ello ser mostrado a uno o varios usuarios a través del
Diagnostic Analyzer que se puede ejecutar en una o varias máquinas. Esto permitiría ver
los resultados del análisis de componentes tanto en la cabina de la unidad del tren como
en la central desde donde se realice el mantenimiento de trenes.
Respecto al sistema multiagente, se han utilizado las técnicas más novedosas en lo que
al diseño de sistemas de este tipo se refiere. Gracias al estándar FIPA, se ha conseguido
PFC: NOMADA
158
elaborar un sistema multiagente distribuido que, empleando técnicas de grid, permite el
reparto de carga entre varias máquinas. Con esto ya no se habla sólo de de que el
sistema multiagente sea distribuido, si no que llegamos a crear sociedades de agentes
capaces de comunicarse entre ellas sin saber, a priori, donde se encuentran, cuántos
agentes hay en el sistema, etc. Actualmente, el problema a resolver por parte del MAS
es muy sencillo. No obstante, las características de NOMADA permiten que el sistema
sea ampliado sin necesidad de modificar nada a nivel programación, para poder explotar
mejor esta potente aplicación.
Por último, nos encontramos con el modelo de datos, y es en este punto donde reside la
mayor debilidad de NOMADA. Los últimos avances se centran en la creación
automática de aplicaciones a partir del modelo de datos mediante lenguaje XML, y esta
es justamente la característica principal del modelo de datos de NOMADA que utiliza
técnicas de business objects para este propósito.
El modelo de datos es una parte esencial de algunas de las aplicaciones que integran
NOMADA, esto sumado a la alta vinculación que existe de este componente con la base
de datos, hace que el sistema sea un ente totalmente dependiente de la estructura del
modelo de datos. Es por este motivo por el que se ha tenido especial cuidado en crear un
modelo de datos lo más genérico posible. Actualmente, las variables soportadas por este
componente son sólo de tipo numérico, pero el diseño del modelo de datos permite que
se definan variables de otros tipos sin tener que modificar su estructura primaria.
El tiempo de respuesta del sistema es de un mínimo de 10 segundos, este tiempo podría
parecer elevado, pero cabe resaltar que un componente de tren no se estropea de un
momento al siguiente si no que sigue una evolución hasta que finalmente se estropea. Es
por ello que se puede permitir un margen a tiempo relativamente elevado de respuesta
del sistema.
El sistema NOMADA trata de dar un paso más allá del desarrollo de sistemas expertos
basados en agentes introduciendo en este campo algunas técnicas del software de última
generación tales como servicios Web, business objects, agentes, inteligencia distribuida,
PFC: NOMADA
159
etc. Este enfoque, refuerza el modelo metodológico y conceptual que se están llevando a
cabo en aplicaciones similares. Dando lugar al fomento del desarrollo de este tipo de
sistemas.
Es cierto que existen otras herramientas que nos ofrecen un entorno de desarrollo de
sistemas multi-agente como JADE o ABLE, e incluso que facilitan un entorno de
desarrollo que ayuda a crear agentes partiendo de técnicas de software convencional
como GAIA. Estas herramientas se podrían haber utilizado para desarrollar NOMADA,
pero gracias a un desarrollo a medida se consiguen particularidades del sistema que de
otra manera (utilizando plataformas como JADE), no podrían haberse implantado.
PFC: NOMADA
160
Referencias
R1 Bibliografía
[COUL01] George Coulouris, Jean Dollimore, etc., “Sistemas distribuidos:
conceptos y diseño”, Addison Wesley. 2001.
[TANE95] Andrew S. Tanenbaum, “Distributed Operating Systems”, Prentice Hall.
1995.
[TANE02] Andrew S. Tanenbaum, Maarten Van Oteen, “Distributed systems:
principles and paradigms”, Prentice-Hall. 2002.
[CAMP98] Eduardo Camponogara, Sarosh N. Talukdar, “Cooperation among
agents, distributed control applications”. Pittsburgh: Carnegie Mellon
University, Institute for Complex Engineered Systems. 1998.
[LOPA04] Adolfo López Paredes, “Ingeniería de sistemas sociales: diseño,
modelado y programación de modelos basados en agentes”, Valladolid:
Universidad de Valladolid. 2004.
[HAYE83] Frederick Hayes-Roth, Donald A. Waterman, Douglas B. Lenat,
“Building expert systems”, Addison-Wesley. 1983.
[CUEN86] José Cuena, “Inteligencia artificial: sistemas expertos”, Alianza. 1986.
[WOOL02] Michael Wooldridge, “An Introduction to Multiagent Systems”, John
Wiley and Sons Ltd. 2002.
PFC: NOMADA
161
[WEIS99] Gerhard Weiss, “Multiagent Systems: A Modern Approach to
Distributed Artificial Intelligence”, Massachusetts Institute of
Technology. 1999.
[GONZ06] E. J. González, A. Hamilton, L. Moreno, G. N. Marichal, J.A. Mendez,
“Diseño e Implementación de un Sistema Multiagente para la
Identificación y Control de Procesos”, Tenerife: Universidad de La
Laguna, Departamento de Física fundamental y Experimental,
Electrónica y Sistemas. 2006.
[FIPA01] Foundation for Intelligent Physical Agents, “FIPA Ontology Service
Specification”, FIPA. 2001.
[FIPA04] Foundation for Intelligent Physical Agents, “FIPA Agent Management
Specification”, FIPA. 2004.
[FISI01] Foundation for Intelligent Physical Agents, “FIPA Agent Software
Integration Specification”, FIPA. 2001.
[ARRA05] Antonio Arranz, “DADICC: Manual de Referencia”, Madrid: ICAI,
Instituto de Investigación Tecnológica. 2005.
[IITI00] Instituto de Investigación Tecnológica, “ISPMAT: Manual de
Referencia”, Madrid: ICAI, Instituto de Investigación Tecnológica. 2000.
[LIBE02] Jesse Liberty, “Programming C#, 2nd Edition”, O’Reilly. 2002.
[MCLU02] Stuart McClure, Joel Scambray, George Kurtz, “Hackers 3: Secretos y
soluciones para la seguridad de redes”, McGraw Hill. 2002.
PFC: NOMADA
162
[RIVE02] Enrique Rivero, Luis Martínez, Luis Reina, etc. “Introducción al SQL
para Usuarios Y Programadores, a nivel de IBM DB2 UDB versión 7.2 o
superior”, Thomson. 2002.
[RIOR00] Rebecca M. Riordan, “Diseño de bases de datos relacionales con Access
y SQL Server”, McGraw-Hill. 2000.
[VIEI00] Robert Vieira, “Professional SQL Server 2000 programming”, Wrox.
2000.
[NIEL03] Paul Nielsen, “Microsoft SQL Server 2000 Bible”, Wiley Publishing Inc.
2003.
[GOME03] Jorge J. Gómez Sanz, “Metodologías para el desarrollo de Sistemas
multi-agente”, Inteligencia Artificial, Revista Iberoamericana de
Inteligencia Artificial. No.18 (2003), pp. 51-63. 2003.
[POWE02] Bruce Powel Douglass, “Real-time design patterns: robust scalable
architecture for real-time systems”, Addison-Wesley. 2002.
[LARM03] Craig Larman, “UML y patrones: una introducción al análisis y diseño
orientado a objetos y al proceso unificado”, Pearson Educación : Prentice
Hall. 2003.
R2 Referencias Web
[MICR06] www.microsoft.com
[MSDN06] msdn.microsoft.com
[SUPO06] support.microsoft.com
PFC: NOMADA
163
[PROG06] www.programacion.com
[CSHA06] www.c-sharpcorner.com
[CODE06] www.codeproject.com
[WKPE06] es.wikipedia.org
[WKLE06] www.wikilearning.com
[EXEC06] my.execpc.com
[RENF06] www.renfe.es
[MSCI06] www.msci.memphis.edu
[MTAG06] www.multiagent.com
[REDC06] www.redcientifica.com
[MOGR06] www.monografias.com
[STRI06] strix.ciens.ucv.ve
[ITLP06] www.itlp.edu.mx
[FIPA06] www.fipa.org
[IISH06] localhost/iishelp/iis/misc/
PFC: NOMADA
164
Anexo A: Métodos accesibles desde WSPIE
Los métodos a los que se puede acceder mediante la colección del WSPIE son:
IncrementVersion: Incrementa el valor de la versión contenida en el
DataManager. Sirve para llevar un control de versión online, actualmente este
método no se utiliza, ya que el control de versión y de ensayo que lleva el
PIEntry es independiente.
Este método no tiene una consulta a la BBDD asociada (como se verá más
adelante, lo habitual es que cada método de la colección lleve asociada una o
varias consultas SQL [RIVE02] [VIEI00]).
SetEnsayo, inserta en la BBDDD la información de un nuevo ensayo.
Sentencia SQL asociada: INSERT INTO Ensayos (ensayo, name, isCalculated,
valueTimeStamp, maquina, compresor) VALUES (@ensayo, @name, 0,
@tS, @maquina, @compresor)
GetTags, obtiene todos los tags que existen asociados a una variable, se utiliza
cuando se va a insertar información en la tabla PIHistoric; lo que ocurre es que
antes de insertar la información debemos filtrarla y verificar que esas variables
existen.
Sentencia SQL asociada: SELECT tagName from Variables WHERE tagName IS NOT NULL
SetNextEnsayoNumber, incrementa el valor del ensayo contenido en el
DataManager. Sirve para saber qué ensayo es el actual y el que va a ser
diagnosticado por el MAS.
SetCurrentEnsayo, este método también indica al MAS qué ensayo va a ser
calculado, pero de forma manual. En un principio se pensó en la posibilidad de
tener ensayos no calculados y que el usuario indicase si quería calcularlo en
PFC: NOMADA
165
ese momento. Su función es la misma que la del método anterior, pero, en vez
de autoincrementar el ensayo, el usuario indica el número de ensayo
explícitamente.
GetProperties, obtiene las propiedades de segmentación para mostrárselas al
usuario. Las propiedades de segmentación son lo parámetros requeridos para
realizar la segmentación de armónicos.
Sentencia SQL asociada: SELECT * FROM Properties
GetDelayedVariableValue, obtiene el valor de una variable, que por las
condiciones de llamada a este método, será siempre de tipo DELAYED. Como
se observa, no hay ninguna sentencia SQL para coger una versión anterior de
esa variable, esto se debe a que al método en cuestión se le pasa el número de
versión que se quiere coger.
Sentencia SQL asociada: SELECT varId FROM Variables WHERE varName = @varName
SELECT varValue FROM PIHistoric WHERE varId = @varId AND
valueVersion = @valueVersion AND ensayo = @ensayo
GetCurrentEnsayoNumber, obtiene el número de ensayo actual. No contiene
una sentencia SQL ya que este valor está almacenado en el DataManager.
GetCurrentVersionNumber, obtiene el número de versión actual. No
contiene una sentencia SQL asociada, la razón es la misma que en el caso
anterior.
SetProperties, actualiza las propiedades para la segmentación de datos RMS.
Sentencia SQL asociada: DELETE FROM Properties
PFC: NOMADA
166
INSERT INTO Properties (longitud, frec_0, dfrec, longEspSeg,
anchoSeg) VALUES (@longitud, @frec_0, @dfrec, @longEspSeg,
@anchoSeg)
GetParamModelsKSOM, obtiene una lista con los tags de los modelos
KSOM, es necesario para vincular un armónico (que en definitiva es un valor)
con la variable correspondiente.
Sentencia SQL asociada: select substring(tagName, 1, 9) from dbo.ParamModels where
substring(tagName, 1, 3) = @idModel and substring(tagName, 4,
4) = 'sk_a'
GetStartingVersion, devuelve la versión por la que hay que empezar. En
nuestro caso siempre va a ser 1, pero si el sistema tuviese que funcionar en
otras condiciones el valor de la versión por la que debemos empezar podría ser
variable.
SetTagValues, este es el método más complejo de WSPIE, pero también el
más importante. Mediante este método el PIEntry envía periódicamente al
InfoService una lista de tags y valores asociados obtenidos, así como el
timestamp o instante global en el que fueron tomados dichos valores. Ante
esto, el InfoService recupera la lista de variables definidas en el sistema
(mediante el método GetTags comentado anteriormente) e inicia un
procedimiento de asignación de valores a esas variables.
A continuación explicaremos en qué consiste este procedimiento; en primer
lugar el preprocesador asigna a las variables directas su valor actual (una
variable directa es aquella cuyo valor es directamente el que viene de la toma
de datos). Posteriormente procede a evaluar las funciones de las variables
calculadas, primero de las variables retrasadas (se usa en este punto el método
GetDelayedVariableValue) y, más tarde, las que tienen una fórmula para su
cálculo. Las variables calculadas son variables cuyo valor se establece por
medio de una función.
PFC: NOMADA
167
Una vez establecidos los valores actuales de todas las variables de entrada,
éstos se almacenan en una de las tablas de la BBDD (en la tabla PIHistoric) de
forma que quedan disponibles para el resto de aplicaciones.
Sentencia SQL asociada:
(Se van a mostrar las sentencias directas, no las derivadas a otras llamadas
como es el caso de preprocessor) UPDATE Variables SET varValue = @varValue WHERE varId = @varId
INSERT INTO PIHistoric (varId, valueVersion, valueTimeStamp,
varValue, tagName, ensayo) VALUES (@varId, @valueVersion,
@valueTimeStamp, @varValue, @tagName, @ensayo)
PFC: NOMADA
168
Anexo B: Métodos accesibles desde WSMAS
Los métodos a los que se puede acceder mediante la colección del WSMAS son:
SendMail, este método sirve para enviar un correo electrónico al encargado de
vigilar el sistema si se detecta alguna anomalía grave. La información
requerida para enviar el email reside en el archivo Web.config del InfoService.
No es necesario enviar un correo cada vez que se detecte una anomalía, es por
eso que esta opción se puede desactivar.
SetIsCalculatedTrue, Indica que el ensayo se ha calculado, es usado por el
MAS cuando va a comenzar un ensayo. Sirve para indicar que un ensayo se ha
calculado total o parcialmente.
Sentencia SQL asociada: UPDATE Ensayos SET isCalculated = 1 WHERE ensayo = @ensayo
RemoveCurrentEnsayoDianostics, borra los diagnósticos y los valores de los
estados de los modelos para un ensayo concreto. Éste es un mecanismo para
evitar errores; si intentamos calcular un ensayo que ya ha sido calculado, se
borran todos los datos que han salido del MAS de ese ensayo y se calcula de
nuevo. Si no se hiciese esto podríamos romper el sistema por un simple error
del usuario.
Sentencia SQL asociada: DELETE FROM StatusModels WHERE ensayo = @ensayo
DELETE FROM HistoricModels WHERE ensayo = @ensayo
DELETE FROM DiagnosticTrace WHERE ensayo = @ensayo
PrepararEnsayo, este método implementa los dos métodos anteriores en uno
sólo. Por lo tanto, las sentencias SQL asociadas a este método son la suma de
las que aparecían en los dos métodos anteriores.
PFC: NOMADA
169
Sentencia SQL asociada: UPDATE Ensayos SET isCalculated = 1 WHERE ensayo = @ensayo
DELETE FROM StatusModels WHERE ensayo = @ensayo
DELETE FROM HistoricModels WHERE ensayo = @ensayo
DELETE FROM DiagnosticTrace WHERE ensayo = @ensayo
GetCurrentVersion, obtiene la versión actual del sistema, el método se la
pide directamente al DataManager, es por eso que no tiene sentencias SQL
asociadas.
GetLastVersion, obtiene la última versión que existe para el ensayo actual
dada de alta en una tabla de la BBDD. Sirve para saber hasta qué versión
puede pedir el MAS valores de variables para el ensayo que está calculando.
Puede parecer que este valor (el de la última versión del ensayo) no varía, pero
no es el caso, ya que según se vayan introduciendo nuevas versiones en el
sistema, el valor la última versión se irá incrementando. Este método es
utilizado por el MAS para la adquisición de datos de la unidad.
Sentencia SQL asociada: SELECT max(valueVersion) FROM PIHistoric WHERE ensayo = @ensayo
GetVariableValues, este método obtiene una lista completa de variables y
valores para la versión que se le indique a través de una estructura DataSet. En
el DataSet sólo se incluye una tabla formada por dos columnas una con el
nombre de la variable y la otra con el valor de esa variable para esa versión y
ensayo.
Sentencia SQL asociada: SELECT valueTimeStamp, varValue from PIHistoric where varId =
@varId and ensayo = @ensayo order by valueTimeStamp ASC
GetModelXMLFile, para inicializar el sistema multiagente es necesario que
los agentes modelo reciban durante la etapa inicial los documentos de
PFC: NOMADA
170
definición de modelo para cada uno de los modelos que tengan asociados.
Estos documentos son los utilizados por el ModelLogic para construir la
función de cálculo. Este método devuelve el documento XML almacenado en
la BBDD.
Sentencia SQL asociada: SELECT XMLFile FROM Models WHERE modelName= @modelName
GetModelXMLString, la función de este método es exactamente la misma
que la del método anterior, pero en vez de devolver el documento XML, se
devuelve éste en forma de string.
Sentencia SQL asociada: SELECT XMLFile FROM Models WHERE modelName= @modelName
SetModelValue, este método es utilizado por los agentes modelo para
comunicar al InfoService el resultado de la evaluación de cada modelo. Con
este método los agentes modelo registran el la base de datos los resultados de
la salida de cada uno de los modelos que operan en el sistema. Esto, más
adelante, es utilizado por el DA para mostrar el estado de la unidad y sirve
como información histórica.
Sentencia SQL asociada: INSERT INTO HistoricModels (varId, valueVersion, varValue,
valueTimeStamp, ensayo) VALUES (@varId, @valueVersion,
@varValue, @valueTimeStamp, @ensayo)
SetModelStatus, con este método los agentes modelo informan del estado de
los modelos, indicando para cada modelo asignado al agente un código de
estado (“Funcionando”, “Anomalía puntual”, etc.). Esta información es
utilizada por el DA y, como antes, almacenada en la BDD como información
histórica).
Sentencia SQL asociada: INSERT INTO StatusModels(statusVersion, modelId, statusCode,
ensayo) VALUES (@statusVersion, @modelId, @statusCode, @ensayo)
PFC: NOMADA
171
SetDiagnosticTrace, es utilizado por los agentes diagnóstico para guardar los
diagnósticos obtenidos a partir de ciertas premisas. Este método guarda la
traza completa, desde los antecedentes a los consecuentes, pasando por todos
los diagnósticos intermedios inferidos. La sentencia SQL que se asocia a este
método se ejecuta varias veces.
Sentencia SQL asociada: INSERT INTO DiagnosticTrace(diagVersion, agentName,
isCoordinator, traceIndex, ruleId, propId, propCert, ensayo)
VALUES (@diagVersion, @agentName, @isCoordinator, @traceIndex,
@ruleId, @propId, @propCert, @ensayo)
PFC: NOMADA
172
Anexo C: Métodos accesibles desde WSDM
Los métodos a los que se puede acceder mediante la colección del WSDM son:
SetConfiguration, introduce la configuración en el medio persistente dado (la
BBDD). Este método recibe un conjunto de tablas relativas a la configuración
del sistema a través del KMA.
Sentencia SQL asociada:
(Esto no se hace mediante sentencias SQL simples sino mediante métodos
proporcionados por el adaptador)
GetConfiguration, obtiene la información completa acerca de la
configuración. Este método invoca de forma interna métodos específicos para
cada área (o base) que conforma la configuración del sistema. Los métodos
específicos que invoca, son los que se ven a continuación, por ello las
sentencias SQL asociadas a este método son la suma de las asociadas a los
métodos que invoca. La información devuelta por este método se utiliza para
instanciar los objetos respectivos de forma automática.
Sentencia SQL asociada:
(Aquí van todas las sentencias asociadas a los métodos GetRules,
GetComponents, GetVariables, GetModels y GetSystemMessages)
GetRules, obtiene la información relativa acerca de las reglas que están dadas
de alta en el sistema. Esto incluye las reglas, las proposiciones contenidas en el
sistema y las relaciones entre las proposiciones (antecedentes y consecuentes)
que conforman dichas reglas.
Sentencia SQL asociada: SELECT * FROM Rules
SELECT * FROM Propositions
SELECT * FROM RPropositions
PFC: NOMADA
173
GetComponents, obtiene la información de los componentes dados de alta en
el sistema.
Sentencia SQL asociada: SELECT compId, compName, parentId, treeDepth, description,
isLeaf FROM Components ORDER BY treeDepth, compName
GetVariables, obtiene la información de las variables dadas de alta en el
sistema. Esto incluye las variables que existen, las relaciones que puedan
existir entre ellas (si una variable depende otras dos, se devuelve también este
hecho), los estados lógicos que hay en el sistema y las relaciones entre los
estados lógicos que existen y las distintas variables.
Sentencia SQL asociada: SELECT * FROM Variables
SELECT * FROM Rvariables
SELECT * FROM LogicStates ORDER BY sequence
SELECT varId, varValue, state FROM RLogicStates
GetModels, obtiene toda la información referente a los modelos. Esto incluye
la información de los parámetros de los modelos y las restricciones que
pudiera haber sobre cada uno de ellos.
Sentencia SQL asociada: SELECT * FROM Models ORDER BY modelId
SELECT * FROM ParamModels
SELECT * FROM RestrModels
GetSystemMessages, obtiene los mensajes que devuelve el sistema
dependiendo del estado en el que se encuentre el modelo.
Sentencia SQL asociada: SELECT * FROM SystemMessages ORDER BY msgId
PFC: NOMADA
174
GetModelXMLFile, obtiene el fichero XML de definición del modelo. El
método es el mismo que el especificado en la colección WSDMAS.
Sentencia SQL asociada: SELECT XMLFile FROM Models WHERE modelName= @modelName
GetModelXMLString, la función de este método es exactamente la misma
que la del método anterior, pero en vez de devolver el documento XML, se
devuelve éste en forma de string.
Sentencia SQL asociada: SELECT XMLFile FROM Models WHERE modelName= @modelName
LoadModels, este método sirve para gestionar la importación de modelos en
la configuración del sistema. El método en cuestión importa documentos de
definición de modelos desde un directorio, especificado en el archivo de
configuración del InfoService, a la base de datos. Es importante mencionar que
el directorio en el que se encuentran las definiciones de los modelos debe ser
compartido para que el método se ejecute correctamente.
Si el modelo que se va a cargar ya existía se sobrescribe, si no, se guarda la
nueva definición.
Sentencia SQL asociada: UPDATE Models SET XMLFile = @XMLFile, fileVersion =
@fileVersion WHERE modelName = @modelName
INSERT INTO ParamModels(modelId, paramNumber, paramName,
description, topSigma, bottomSigma, versionDelay, tagName,
isInput) VALUES(@modedId, @paramNumber, @paramName,
@description, @topSigma, @bottomSigma, @versionDelay,
@tagName, @isInput)
ResetModels, este método sirve para gestionar la importación de modelos en
la configuración del sistema. Este método elimina toda la información relativa
a los modelos almacenada en la BBDD.
Sentencia SQL asociada:
PFC: NOMADA
175
DELETE FROM ParamModels
DELETE FROM RestrModels
DELETE FROM Models
USE @initialCatalog DBCC CHECKIDENT(ParamModels, RESEED, 0)
GetModelStatus, obtiene el estado de los modelos para una versión
especificada en un ensayo especificado. Este tipo de métodos es el que usa el
DA para mostrar al usuario en qué estado está el sistema (en este caso los
modelos).
Sentencia SQL asociada: SELECT modelId, statusCode FROM StatusModels WHERE
statusVersion = @statusVersion and ensayo = @ensayo
GetLastCalculatedVersion, obtiene la última versión calculada para el
ensayo sobre el que estamos trabajando, es decir, el ensayo que se está
evaluando en ese momento o, en su defecto la última versión del último
ensayo que se calculó.
Sentencia SQL asociada: SELECT MAX(VALUEVERSION) VALUEVERSION FROM HISTORICMODELS WHERE
VARID = @varEstId AND VALUEVERSION <= @valueVersion and ensayo
= @ensayo
GetLastDiagnosticatedVersion, obtiene la última versión diagnosticada para
el ensayo sobre el que estamos trabajando, es decir, el ensayo que se está
evaluando en ese momento o, en su defecto la última versión del último
ensayo que se calculó.
Sentencia SQL asociada: SELECT MAX(DIAGVERSION) DIAGVERSION FROM DIAGNOSTICTRACE
WHERE DIAGVERSION <= @valueVersion and ensayo = @ensayo
GetLastStatusModelsVersion, obtiene el último estado de los modelos.
PFC: NOMADA
176
Sentencia SQL asociada: SELECT MAX(STATUSVERSION) STATUSVERSION FROM STATUSMODELS WHERE
STATUSVERSION <= @valueVersion AND ensayo = @ensayo
GetLastValuesVariable, obtiene el último valor de las variables de entrada al
sistema.
Sentencia SQL asociada: select valueTimeStamp, varValue from PIHistoric where varId =
@varId and ensayo = @ensayo order by valueTimeStamp ASC
GetDiagnosticTrace, obtiene la traza de un diagnóstico, esto es, dado un
diagnóstico determinado el método devuelve todos los datos de forma que el
DA es capaz de reconstruir el diagnóstico desde su inicio hasta su final.
Sentencia SQL asociada: select * from DiagnosticTrace t1, (select valueTimeStamp from
universalSystemTime where valueVersion = @version and ensayo =
@ensayo) t2 where diagVersion = @version and ensayo = @ensayo
order by iscoordinator ASC, agentName ASC, traceIndex ASC
GetAllDiagnosticHistoryOnline, obtiene toda la lista de diagnósticos finales
inferidos para el ensayo que se está llevando a cabo o, en su defecto, para el
último que se llevó a cabo.
Sentencia SQL asociada: select t1.id, t1.hora, t2.descripcion, round(t1.certeza,2)
certeza from (select D.id id, U.valueTimeStamp Hora, D.propId
propId, D.propCert Certeza from diagnosticTrace D,
universalSystemTime U where D.diagVersion = U.valueVersion and
D.ensayo = U.ensayo and D.ensayo = @ensayo and D.isCoordinator
= 1 and D.traceIndex <> 0 and D.ruleId is null) T1 join (select
propId propId, description descripcion from propositions) T2 on
t1.propId = t2.propId order by hora DESC
GetAllDagnosticHistoryHistoric, su función es la misma que la del método a
anterior, con la salvedad de que en este caso de le indica el ensayo del que se
quieren obtener los diagnósticos.
PFC: NOMADA
177
Sentencia SQL asociada: select t1.id, t1.hora, t2.descripcion, round(t1.certeza,2)
certeza from (select D.id id, U.valueTimeStamp Hora, D.propId
propId, D.propCert Certeza from diagnosticTrace D,
universalSystemTime U where D.diagVersion = U.valueVersion and
D.ensayo = U.ensayo and D.ensayo = @ensayo and D.isCoordinator
= 1 and D.traceIndex <> 0 and D.ruleId is null) T1 join (select
propId propId, description descripcion from propositions) T2 on
t1.propId = t2.propId order by hora DESC
GetEnsayoNumber, obtiene el número de un ensayo dado su nombre.
Sentencia SQL asociada: SELECT ensayo FROM Ensayos WHERE name = @name
GetEnsayos, obtiene una lista con todos los ensayos que han sido o están
siendo calculados. Es utilizado por el DA para conseguir la lista de los ensayos
que se puede ver en el modo histórico.
Sentencia SQL asociada: SELECT ensayo, name, valueTimeStamp, maquina, compresor FROM
Ensayos WHERE isCalculated = 1 ORDER BY valueTimeStamp DESC
GetNeuralWinnerOnline, obtiene la neurona ganadora del modelo KSOM.
Se debe especificar el nombre del modelo. La neurona ganadora corresponde a
la calculada en el ensayo que se está calculando en ese momento o, en su
defecto, a la última que ha sido calculada.
Sentencia SQL asociada: select varValue from HistoricModels ParamModels where
patindex(@modelName, paramName) !=0 and patindex('%idN%',
paramName)!= 0) = varId and valueVersion = 1 and ensayo =
@ensayo
GetNeuralWinnerHistoric, su función es la misma que la del método
anterior, con la salvedad de que en este caso se le indica el ensayo del que se
quiere obtener la neurona ganadora.
Sentencia SQL asociada:
PFC: NOMADA
178
select varValue from HistoricModels ParamModels where
patindex(@modelName, paramName) !=0 and patindex('%idN%',
paramName)!= 0) = varId and valueVersion = 1 and ensayo =
@ensayo
GetInputKSOMOnline, obtiene los valores que han entrado al modelo
KSOM. Estos valores son los correspondientes a los armónicos seleccionados
en la fase de segmentación de datos RMS. Se debe especificar el nombre del
modelo. Los valores devueltos corresponden a los datos que se están utilizando
en el ensayo actual o, en su defecto, a los del último ensayo que ha sido
calculado.
Sentencia SQL asociada: select P.varValue from PIHistoric P, (select varId from
dbo.ParamModels where patindex(@modelName, paramName)!=0 and
isInput = 1) V where V.varid = P.varId and P.ensayo = @ensayo
and valueVersion = 1
GetInputKSOMHistoric, su función es la misma que la del método anterior
con la salvedad de que en este caso se le indica el ensayo del que se quieren
obtener los valores que han entrado al modelo KSOM.
Sentencia SQL asociada: select P.varValue from PIHistoric P, (select varid from
dbo.ParamModels where patindex(@modelName, paramname)!=0 and
isInput = 1) V where V.varid = P.varId and P.ensayo = @ensayo
and valueVersion = 1
GetOutputVariablesOnline, obtiene el valor de una variable de salida de un
modelo. Estas variables se llaman Output y son aquellas que el modelo ha
estimado, durante todo el ensayo. Lo habitual es usarlo para variables de salida
de modelos de tipo PCM, pero no se excluye su uso para obtener las variables
de salida de otros modelos. Se debe especificar el identificador numérico de la
variable (y este debe ser de una variable de salida). Los valores devueltos se
PFC: NOMADA
179
corresponden a los que ha ido tomando la variable a lo largo de todo el ensayo
o, en su defecto, a los del último ensayo que se calculó.
Sentencia SQL asociada: select varValue from HistoricModels where varId = @varId and
ensayo = @ensayo order by valueVersion
GetOutputVariablesHistoric, su función es la misma que la del método
anterior pero en este caso se debe indicar el ensayo del que se quieren obtener
los valores.
Sentencia SQL asociada: select varValue from HistoricModels where varId = @varId and
ensayo = @ensayo order by valueVersion
GetRealVariablesOnline, obtiene los valores de una variable de entrada de
un modelo. Estas variables se llaman Real y son aquellas que entran en el
modelo, durante todo el ensayo. Lo habitual es usarlo para variables de entrada
de modelos de tipo PCM, pero no se excluye su uso para obtener las variables
de salida de otros modelos. Se debe especificar el identificador numérico de la
variable (y éste debe ser de una variable de salida). Los valores devueltos se
corresponden a los que ha ido tomando la variable a lo largo de todo el ensayo
o, en su defecto, a los del último ensayo que se calculó.
Sentencia SQL asociada: select varValue from PIHistoric where varId = @varId and
ensayo = @ensayo order by valueVersion
GetRealVariablesHistoric, su función es la misma que la del método anterior
pero en este caso se debe indicar el ensayo del que se quieren obtener los
valores.
Sentencia SQL asociada: select varValue from PIHistoric where varId = @varId and
ensayo = @ensayo order by valueVersion
PFC: NOMADA
180
Anexo D: Base de datos de ISPMAT
La base de datos original de NOMADA (la aplicación se llamaba ISPMAT [IITI00])
estaba instalada sobre un gestor Interbase (sistema gestor de bases de datos
relacionales). Para el buen funcionamiento de la aplicación se crearon una serie de
librerías dinámicas para manipular la BBDD (esto, como se ha explicado antes se
realiza ahora a través de un servicio Web).
Las tablas contenidas en Internase eran las siguientes:
Se disponía de una base de datos de históricos, encargada de almacenar todos los
valores de las señales automáticas. Las tablas que conformaban esa estructura eran las
siguientes:
Tabla PROCESO, la cual contenía las medidas obtenidas para cada una de las señales:
CAMPOS TIPO DESCRIPCIÓNID_SENAL int Identificador de la señal VALOR BLOB Valor de la medida FECHA TDATETIME Fecha de la adquisición
Tabla VOLUMEN_H, en esta tabla se guardaba la información referente a las copias de
seguridad existentes en la BBDD y desde que fecha hasta que fecha abarcaba cada una:
CAMPOS TIPO DESCRIPCIÓNETIQUETA char Etiqueta de la copia de
seguridad DESDE TDATETIME Fecha inicial de los datos de
la copia HASTA TDATETIME Fecha final de los datos de
la copia
PFC: NOMADA
181
El resto de las tablas estaban contenidas en una base de datos de configuración, en esta
BBDD se podía encontrar toda la información referente a los modelos (detector de
anomalías), Base de hechos, Base de conocimiento, información referente al sistema de
adquisición de datos y los datos necesarios para crear el interfaz sobre el que se veían
las anomalías detectadas y los diagnósticos inferidos.
Las tablas referentes a la información para el detector de anomalías eran las siguientes:
Tabla de MODELOS, esta tabla contenía las descripciones de los modelos:
CAMPOS TIPO DESCRIPCIÓN ID_MODELO int Identificador de la
función NOMBRE DNOMBRE_MODELO Nombre de la función DESCRIPCION DDESCRIPCION Descripción de la función TIPO DTIPO Tipo de función PARAMETROS BLOB Parámetros de la función
Tabla SE_ENT_MOD, que contenía la relación entre los modelos y sus entradas:
CAMPOS TIPO DESCRIPCIÓNID_SIGNAL int Identificador de la señal que
es entrada a la función ID_MODELO int Identificador de la función
Tabla SE_SAL_MOD, que contenía la relación entre los modelos y sus variables de
salida (señales):
CAMPOS TIPO DESCRIPCIÓNID_SIGNAL int Identificador de la señal que
es salida de la función ID_MODELO int Identificador de la función
PFC: NOMADA
182
Las tablas en las que se alojaba la configuración de la base de hechos (las variables que
entraban al sistema lo hacían desde las tablas contenidas en la base de históricos) se
muestran a continuación.
Tabla BH_COMPONENTES, contenía la información necesaria para identificar al
componente:
CAMPOS TIPO DESCRIPCIÓNID_COMPONENTE int Identificador del componente COMPONENTE DCOMPONENTE Nombre del componente PERTENECE_A DCOMPONENTE Nombre del componente padre
El concepto componente padre es algo que se utilizará en la nueva configuración de la
BBDD, la idea es que un componente puede depender de otro, en nuestro caso el
componente “compresor” está alojado dentro de un componente llamado “máquina” que
es el componente principal y del que dependerán el resto de componentes de esa
máquina, por ejemplo, el “bogie”.
Tabla BH_ESTADOS, servía para indicar qué estados provocan las distintas señales
(las que provocan algún estado) si se encuentran en determinados rangos. También
indicaba si el hecho de que esa señal se encontrase en ese estado provocaba una
anomalía o no (cuando se detecta anomalía se disparan reglas en el sistema experto y se
infieren diagnósticos):
CAMPOS TIPO DESCRIPCIÓNID_SIGNAL int Identificador la señal a la
que pertenece el estado ESTADO DESTADO Nombre del estado APODO DESTADO Apodo del estado ANOMALIA bool Indica si el estado genera
anomalía
PFC: NOMADA
183
Tabla BH_GRUPOS:
CAMPOS TIPO DESCRIPCIÓNGRUPO DELEMENTO Nombre del grupo de componentes
Tabla BH_GRUPOS_COMP, esta tabla indicaba a que grupo pertenece un
componente:
CAMPOS TIPO DESCRIPCIÓNID_COMPONENTE int Identificador del componente GRUPO DELEMENTO Nombre del grupo de componentes
Tabla BH_PROPIEDADES, contenía las propiedades que podía tener una variable:
CAMPOS TIPO DESCRIPCIÓNPROPIEDAD DELEMENTO Nombre de la propiedad
Tabla BH_PROPIEDADES_VAR, esta tabla relacionaba las variables con las
propiedades (si la variable tenía propiedades):
CAMPOS TIPO DESCRIPCIÓNID_VARIABLE int Identificador de la variable que
tiene la propiedad PROPIEDAD DELEMENTO Nombre de la propiedad
Tabla BH_SIGNALS, contenía todas las señales existentes en el sistema, tanto señales
reales que entraban desde los sensores, como variables necesarias para que funcionase
el sistema de detección y diagnóstico de anomalías, también estaban identificadas las
PFC: NOMADA
184
variables que eran salidas de los modelos (existe cierta similitud entre una variable y
una señal, por eso aquí se usan indistintamente):
CAMPOS TIPO DESCRIPCIÓNID_SIGNAL int Identificador de la señal
ID_VARIABLE int Identificador de la variable
asociada a la señal ID_COMPONENTE int Identificador del componente
asociado a la señal SIGNAL DSENAL Nombre de la señal RANGOMAX float Rango máximo de la medida RANGOMIN float Rango mínimo de la medida ACTIVIDAD bool Indica si la señal está activa UNIDADES DTIPO Unidades de la señal TIPO DSENAL Tipo de señal o constructor de
la señal
Tabla BH_VARIABLES, está tabla contenía únicamente los identificadores de las
variables y sus nombres:
CAMPOS TIPO DESCRIPCIÓNID_VARIABLE int Identificador de la variable VAR DVARIABLE Nombre de la variable
La información sobre antecedentes, consecuentes y reglas se alojaba en una serie de
tablas que conformaban la Base de conocimiento, estas tablas son las que hacían posible
que existiese una cierta capacidad de raciocinio en el sistema (como en cualquier
sistema experto), las tablas de las que se componía se muestran a continuación.
Tabla BC_ACCIONES, esta tabla contenía las acciones correctoras a realizar
dependiendo de la regla que se hubiese disparado:
PFC: NOMADA
185
CAMPOS TIPO DESCRIPCIÓNREGLA DREGLA Regla a la que pertenece la acción ACCION DANTECEDENTE Acción a llevar a cabo
Tabla BC_ANTECEDENTES, contenía la relación entre los antecedentes y las reglas:
CAMPOS TIPO DESCRIPCIÓNREGLA DREGLA Regla a la que pertenece el
antecedente ANTECEDENTE DANTECEDENTE Antecedente de la regla CONFIANZA float Confianza asociada al antecedente
Tabla BC_AREAS, esta tabla relacionaba las reglas dadas de alta y a qué área de
conocimiento se aplicaba. Entendemos como área de conocimiento el ámbito al que
podía afectar la regla, es decir una regla pede ser tenida en cuenta para un componente
pero no para otro, los componentes podrían ser las áreas en las que puede aplicarse la
regla:
CAMPOS TIPO DESCRIPCIÓNAREA DELEMENTO Nombre del área DESCRIPCION DDESCRIPCION Descripción del área
Tabla BC_CONSECUENTES, contenía la relación entre los consecuentes y las reglas
(el tener todos los antecedentes de una regla activados hace que esa regla se dispare y
obtengamos un consecuente):
CAMPOS TIPO DESCRIPCIÓNREGLA DREGLA Regla a la que pertenece el
consecuente CONSECUENTE DANTECEDENTE Consecuente de la regla
PFC: NOMADA
186
Tabla BC_DIAGNOSTICOS, contenía la relación entre los diagnósticos y las reglas
(un consecuente no implica siempre un diagnóstico, el diagnóstico la inferencia final del
sistema experto):
CAMPOS TIPO DESCRIPCIÓNREGLA DREGLA Regla a la que pertenece el
diagnóstico DIAGNOSTICO DANTECEDENTE Diagnóstico de la regla
Tabla BC_REGLAS, en esta tabla se alojaba la información referente a la regla en sí,
esto es, la confianza que teníamos en ella, una descripción de la misma, etc.:
CAMPOS TIPO DESCRIPCIÓNREGLA DREGLA Nombre de la regla DESCRIPION DDESCRIPCION Descripción de la regla AREA DELEMENTO Área a la que pertenece la regla IMPLICACION DELEMENTO (No se usa) CONFIANZA float Confianza asociada a la regla ACTIVIDAD bool Indica si la regla está activada
Lo siguiente que vamos a explicar es a estructura de tablas que conformaban el sistema
de adquisición de datos. Todo este grupo de tablas ha sido eliminado en el sistema
actual, pero es conveniente entender cual era la estructura del anterior sistema de
adquisición.
Tabla SAD_COMPONENTES, relacionaba un componente con el sistema al que
pertenece:
CAMPOS TIPO DESCRIPCIÓNCOMPONENTE DCOMPONENTE Nombre del componente ID_SISTEMA DDESCRIPCION Sistema al que pertenece el
componente
PFC: NOMADA
187
Tabla SAD_CONFIG_BANDAS, la tabla especificaba una serie de rangos para, en otra
tabla, asociar los rangos con las señales que se reciben:
CAMPOS TIPO DESCRIPCIÓNID_RANGO int Identificador del rango ID_BANDA int Identificador de la banda a la que
pertenece el rango DESDE int Inicio de la banda luminosa (0 – 255)HASTA int Final de la banda R int Parte roja del color de la banda G int Parte verde del color de la banda B int Parte azul de color de la banda
Tabla SAD_CONFIG_RANGOS, relaciona las señales con los rangos a los que
pertenece:
CAMPOS TIPO DESCRIPCIÓNID_SIGNAL int Identificador de la señal asociada
al rango ID_RANGO int Identificador del rango
Tabla SAD_CONVERTIDORES, contenía la información de los convertidores:
CAMPOS TIPO DESCRIPCIÓNID_CONVERTIDOR int Identificador del convertidor DIRECCION char Dirección en la que se
encuentra el convertidor NCANALES int Número de canales del
convertidor DESCRIPCION DDESCRIPCION Descripción del convertidor CONVERTIDOR DELEMENTO Nombre del convertidor
PFC: NOMADA
188
Tabla SAD_SENSORES, contenía la información asociada a los sensores, incluyendo
convertidor al que pertenecen y señal asociada al sensor:
CAMPOS TIPO DESCRIPCIÓNID_SENSOR int Identificador del sensor ID_SIGNAL int Identificador de la señal
asociada al sensor ID_CONVERTIDOR int Identificador del convertidor
al que se conecta el sensor SENSOR DDESCRIPCION Nombre del sensor DESCRIPCION DDESCRIPCION Descripción del sensor CANAL_S int Canal del convertidor al que se
conecta
Tabla SAD_FICHEROS, indicaba los ficheros que se iban a utilizar para meter las
medidas:
CAMPOS TIPO DESCRIPCIÓNID_FICHERO int Identificador del fichero en el
que van las medidas ID_SISTEMA int Identificador del sistema que usa
el fichero RUTA DDESCRIPCION Ruta del fichero
Tabla SAD_SIGNALS, contenía las propiedades de las señales recogidas por el
sistema:
CAMPOS TIPO DESCRIPCIÓNID_SIGNAL int Identificador de la señal ID_SISTEMA int Identificador del sistema al que
pertenece la señal SIGNAL DSENAL Nombre de la señal RGINF float Rango máximo de la medida de la señalRGMAX float Rango mínimo de la medida de la señal
PFC: NOMADA
189
UNIDADES DTIPO Unidades de la señal DOMINIO int (No se usa)
Tabla SAD_SIGNAL_E, la tabla vinculaba las señales con el fichero en el estaban:
CAMPOS TIPO DESCRIPCIÓNID_FICHERO int Identificador del fichero ID_SENAL int Identificador de la señal que va en
el fichero POSICION int Posición que ocupa la señal dentro
del fichero
Tabla SAD_SISTEMAS, contenía la definición de los sistemas:
CAMPOS TIPO DESCRIPCIÓNID_SISTEMA int Identificador del sistema SISTEMA DELEMENTO Nombre del sistema DESCRIPCION DDESCRIPCION Descripción del sistema
Tabla SAD_ULTIMOS, contenía una relación de señales y valores tomados:
CAMPOS TIPO DESCRIPCIÓNID_SIGNAL int Identificador de la señal FECHA TDATETIME Fecha en que se tomó la medida VALOR float Valor de la medida
Tabla SAD_VARIABLES, relacionaba las variables con el sistema al que pertenecían:
CAMPOS TIPO DESCRIPCIÓNVAR DVARIABLE Identificador de la variable ID_SISTEMA int Identificador del sistema en el
que se encuentra la variable
PFC: NOMADA
190
Tabla SAD_VOLUMEN, contenía la información relacionada con las copias de
seguridad:
CAMPOS TIPO DESCRIPCIÓNETIQUETA DELEMENTO Etiqueta de la copia de seguridad DESDE TDATETIME Fecha de los datos más antiguos de la
copia HASTA TDATETIME Fecha de los datos más recientes de
la copia
El último punto a explicar sobre la base de datos de ISPMAT es el conjunto de tablas
que se usaban para la creación del interfaz gráfico. Estas tablas contenían información
sobre donde iba colocado cada uno de los dibujos que correspondían a la posición de un
sensor, en el nuevo sistema esto ya no se realiza así, se han utilizado otras técnicas para
situar los sensores. A continuación se muestra la estructura de las tres tablas que servían
para configurar el interfaz gráfico.
Tabla MEDIDOR_SENAL:
CAMPOS TIPO DESCRIPCIÓNID_MEDIDOR int Identificador del medidor SIGNAL DSENAL Nombre de la señal o modelo asociado
al medidor POSICION int Posición que ocupa la señal de entre
las asociadas al medidor ETIQUETA DTIPO Etiqueta de la señal asociada
Tabla MEDIDORES, esta tabla contenía la posición del medidor en el interfaz:
PFC: NOMADA
191
CAMPOS TIPO DESCRIPCIÓNID_MEDIDOR int Identificador del medidor MEDIDOR DELEMENTO Nombre del medidor VISTA DELEMENTO Nombre de la vista o esquema al que
se asocia el medidor TIPO DTIPO Tipo de medidor POS_H int Altura del medidor POS_W int Anchura del medidor POS_T int Posición vertical del medidor POS_L int Posición horizontal del medidor TIPO_FORM DTIPO Tipo de ventana asociada al medidor
Tabla VISTAS, contenía la lista de vistas existentes:
CAMPOS TIPO DESCRIPCIÓNVISTA DELEMENTO Nombre de la vista o esquema ARCHIVO DDESCRIPCION Archivo donde se encuentra la
imagen que se carga en la vista
Como se puede observar la estructura de la base de datos que se empleaba anteriormente
es bastante compleja, es más, algunas de las tablas son innecesarias y podrían haberse
diseñado de forma más simple. Además hay definidos una gran cantidad de tipos de
datos cuando realmente no es necesario tener tanto, en la estructura actual (que se
muestra a continuación) no ha sido necesario definir ningún tipo de dato específico.
El conjunto de tablas contenidas en esta BBDD era de unas 35 tablas, el sistema actual
consta de 25, y aún así posiblemente haya alguna tabla de la que se podría prescindir
(hay diseñadas algunas tablas que el sistema actual no precisa, pero que podrían ser
necesarias en futuras ampliaciones de éste).
Además existía otro grupo de tablas, las cuales no se van a explicar, que contenía la
configuración de cada uno de los sensores y dispositivos de los que se toman los datos
del sistema. Había una tabla con los datos de cada sensor, una tabla por cada protocolo
de adquisición, una tabla con los puntos en los que se tomaban las medidas que contenía
PFC: NOMADA
192
el sensor y la posición que tomaba éste. Todas estas tablas se han perdido en la nueva
base de datos, ya que la estructura actual es mucho más sencilla e intuitiva y no se
precisa de dicha información para que el sistema funcione.