UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA 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 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 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. i PFC: NOMADA 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. ii PFC: NOMADA 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. iii PFC: NOMADA 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. iv PFC: NOMADA 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 1 PFC: NOMADA 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 2 PFC: NOMADA 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 3 PFC: NOMADA 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 4 PFC: NOMADA 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 5 PFC: NOMADA 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 del primero 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 en la medida en que catenaria lo admita. Dimensiones, pesos y plazas (M) (R) (M-4R-M) Dimensiones en (mm) 6 PFC: NOMADA 26.900 26.400 Longitud entre enganches 2.926 2.926 Anchura exterior 4.300 4.300 Altura máxima sobre el carril Altura del piso de plataforma sobre 1.010 1.010 el carril 159.400 Peso (en T) Tara Carga normal 70,2 86,9 52,6 76,8 350,8 481,0 128 188 1.008 Plazas Sentadas De pie Equipos auxiliares Equipo eléctrico auxiliar: Convertidor estático: Cada coche dispone de un convertidor estático de 3.000 Vcc/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 circuitos eléctricos de baja tensión y el alumbrado de socorro. Producción de aire: Dispone de un compresor principal rotativo de tornillo con una producció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 7 PFC: NOMADA 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 proporciona refrigeración y calefacción reforzándose en este modo con calentadores a nivel del 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. 8 PFC: NOMADA 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 9 PFC: NOMADA 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 10 PFC: NOMADA 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. 11 PFC: NOMADA 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 12 PFC: NOMADA 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: 13 PFC: NOMADA − 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. 14 PFC: NOMADA 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. 15 PFC: NOMADA 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. 16 PFC: NOMADA 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. 17 PFC: NOMADA 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 18 PFC: NOMADA 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. 19 PFC: NOMADA 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. 20 PFC: NOMADA 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. 21 PFC: NOMADA 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 INTERFAZ GRAFICA DE USUARIO MODELO DE DATOS CONTROL MIDDLEWARE COMUNICACIONES Figura 3.4 – Arquitectura genérica de las aplicaciones A continuación se describen las distintas capas que tiene cada aplicación: 22 PFC: NOMADA − 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 23 PFC: NOMADA 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) 24 PFC: NOMADA 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 25 PFC: NOMADA 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. 26 PFC: NOMADA 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 27 PFC: NOMADA 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; } } 28 PFC: NOMADA 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 29 PFC: NOMADA 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: 30 PFC: NOMADA 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]. 31 PFC: NOMADA 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 32 PFC: NOMADA 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: 33 PFC: NOMADA 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 nario 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 34 PFC: NOMADA 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 35 PFC: NOMADA á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: 36 PFC: NOMADA Figura 4.5 – Diagrama UML del paquete Components 37 PFC: NOMADA 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 38 PFC: NOMADA 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”: 39 PFC: NOMADA 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 40 PFC: NOMADA 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: 41 PFC: NOMADA Figura 4.6 – Diagrama UML del paquete Variables 42 PFC: NOMADA 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 43 PFC: NOMADA Relación dirigida C1 C4 C7 C2 C5 C8 C3 C6 nodo 1 nodo 2 nodo 3 Relación no dirigida C1 C4 C7 C2 C5 C8 C3 C6 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. 44 PFC: NOMADA Relación original R C1 C4 C7 C2 C5 C8 C3 C6 nodo 1 nodo 2 nodo 3 Pb. Se desea indicar en la relación que C3 no está relacionado con C4 Relaciones R1 y R2 C1 C4 C7 C2 C5 C8 C6 nodo 1 nodo 2 nodo 3 C7 C5 C3 C8 C6 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: 45 PFC: NOMADA Figura 4.9 – Diagrama UML del paquete Relations 46 PFC: NOMADA 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, 47 PFC: NOMADA 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. 48 PFC: NOMADA 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: 49 PFC: NOMADA Figura 4.10 – Diagrama UML del paquete Rules 50 PFC: NOMADA 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 autoorganizados (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 51 PFC: NOMADA 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: 52 PFC: NOMADA Figura 4.11 – Diagrama UML del paquete Models 53 PFC: NOMADA 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; } 54 PFC: NOMADA 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 55 PFC: NOMADA El siguiente diagrama muestra la estructura del paquete Configuration: Figura 4.13 – Diagrama UML del paquete Configuration 56 PFC: NOMADA 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 57 PFC: NOMADA (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. 58 PFC: NOMADA 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. 59 PFC: NOMADA 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 60 PFC: NOMADA 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) 61 PFC: NOMADA 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. 62 PFC: NOMADA 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. 63 PFC: NOMADA Figura 5.3 – Diagrama UML del paquete DataManager 64 PFC: NOMADA 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. 65 PFC: NOMADA Figura 5.4 – Diagrama UML del paquete Preprocessor 66 PFC: NOMADA 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, 67 PFC: NOMADA 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). 68 PFC: NOMADA 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: 69 PFC: NOMADA percepciones análisis razonamiento decisión juicio Agente acciones 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 70 PFC: NOMADA 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. 71 PFC: NOMADA 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 72 PFC: NOMADA 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. 73 PFC: NOMADA 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: 74 PFC: NOMADA Figura 6.5 – Diseño estructural del MAS de NOMADA 75 PFC: NOMADA 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 76 PFC: NOMADA 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: 77 PFC: NOMADA Figura 6.6 – Diagrama UML del paquete AgentRepository 78 PFC: NOMADA 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: 79 PFC: NOMADA 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: 80 PFC: NOMADA - 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 81 PFC: NOMADA 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, StartSyndicationTimer() COORDINATING FINISHED TIMEOUT, SyndicationEventHandler() COORDINATING, ANSWER (coordinator) 6.3.3 Controlador de infraestructura (InfrastructureManager) 82 PFC: NOMADA 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: 83 PFC: NOMADA 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: 84 PFC: NOMADA 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: 85 PFC: NOMADA Figura 6.9 – Diagrama UML del paquete AgentPlatform 86 PFC: NOMADA 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. 87 PFC: NOMADA 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: 88 PFC: NOMADA 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: 89 PFC: NOMADA percepciones • Base de reglas asociada al componente raíz del dominio del agente • Estados lógicos de las variables de error de los modelos análisis razonamiento • 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) decisión juicio • Comunicar al InfoService diagnósticos inferidos (traza) • Notificar agente diagnóstico coordinador (si no actual) acciones 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 90 PFC: NOMADA 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 91 PFC: NOMADA 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. 92 PFC: NOMADA 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. 93 PFC: NOMADA 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. 94 PFC: NOMADA 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. 95 PFC: NOMADA 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). 96 PFC: NOMADA 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. 97 PFC: NOMADA 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: 98 PFC: NOMADA 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. 99 PFC: NOMADA 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. 100 PFC: NOMADA 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: 101 PFC: NOMADA 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. 102 PFC: NOMADA 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: 103 PFC: NOMADA 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. 104 PFC: NOMADA 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. 105 PFC: NOMADA 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 106 PFC: NOMADA 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. 107 PFC: NOMADA 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: 108 PFC: NOMADA 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). 109 PFC: NOMADA 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. 110 PFC: NOMADA − 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. 111 PFC: NOMADA 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: 112 PFC: NOMADA 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. 113 PFC: NOMADA 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: 114 PFC: NOMADA Figura 8.6 – Diagrama UML simplificado del paquete DA.ui 115 PFC: NOMADA 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. 116 PFC: NOMADA 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. 117 PFC: NOMADA 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: 118 PFC: NOMADA Figura 8.9 – Diagrama UML del paquete DA.Infoservice 119 PFC: NOMADA 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. 120 PFC: NOMADA 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”). 121 PFC: NOMADA 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. 122 PFC: NOMADA 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: 123 PFC: NOMADA − 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: 124 PFC: NOMADA 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: 125 PFC: NOMADA − 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) 126 PFC: NOMADA 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. 127 PFC: NOMADA 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 128 PFC: NOMADA − 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: 129 PFC: NOMADA 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: 130 PFC: NOMADA 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. 131 PFC: NOMADA 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 132 PFC: NOMADA 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. 133 PFC: NOMADA 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 134 PFC: NOMADA − 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: 135 PFC: NOMADA 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. 136 PFC: NOMADA 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. 137 PFC: NOMADA 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. 138 PFC: NOMADA 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: 139 PFC: NOMADA 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. 140 PFC: NOMADA 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 141 PFC: NOMADA 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. 142 PFC: NOMADA 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 143 PFC: NOMADA 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 144 PFC: NOMADA − 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. 145 PFC: NOMADA 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). 146 PFC: NOMADA 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 147 PFC: NOMADA − 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 148 PFC: NOMADA 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 149 PFC: NOMADA 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. 150 PFC: NOMADA 10 Presupuesto del proyecto 10.1 Mediciones 0 1 2 2.1 2.2 2.3 Diseño de sistema multiagente para la detección y diagnóstico de anomalías Lanzamiento Construcción de la plataforma que donde se desarrollará el sistema Diseño de la plataforma donde se desarrollará el sistema Codificación de la plataforma Introducción de la información primaria 3 Construcción de un entorno abierto y flexible de diagnóstico Diseño del entorno de diagnóstico Codificación del entorno 3.1 3.2 4 4.1 4.2 4.3 5 5.1 5.2 6 6.1 6.2 7 7.1 7.2 8 9 9.1 9.2 Elaboración de módulo de recogida de información Diseño del módulo de recogida de información Codificación del módulo Pruebas del módulo Elaboración de agente diagnóstico Diseño del agente Codificación del agente Desarrollo de una interfaz para los resultados del agente diagnóstico Diseño de la interfaz Codificación de la interfaz Integración de los componentes en su entorno Análisis de la integración Realización de la integración Prueba de la aplicación Cierre del proyecto Acabado de la documentación Entrega de la documentación 151 PFC: NOMADA 10.2 Precios unitarios Id. 1 2 3 4 5 6 7 8 9 Nombre Precio (€) 126,25 Lanzamiento 1994,75 Construcción de la plataforma que donde se desarrollará el sistema 1136,25 Construcción de un entorno abierto y flexible de diagnóstico 909,00 Elaboración de módulo de recogida de información 1136,25 Elaboración de agente diagnóstico 858,50 Desarrollo de una interfaz para los resultados del agente diagnóstico 1010,00 Integración de los componentes en su entorno 252,50 Prueba de la aplicación 757,50 Cierre del proyecto Total proyecto: 8181,00 10.3 Sumas parciales 1 Lanzamiento Total (€): 2 126,25 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 152 PFC: NOMADA 4 5 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.1 Diseño del agente……………………………………………... 631,25 5.2 Codificación del agente………………………………………. 505,00 Elaboración de agente diagnóstico Total (€): 1136,25 6 7 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.1 Análisis de la integración……………………………………. 505,00 7.2 Realización de la integración………………………………... 505,00 Integración de los componentes en su entorno Total (€): 1010,00 8 Prueba de la aplicación Total (€): 252,50 153 PFC: NOMADA 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 154 PFC: NOMADA 10.4 Presupuesto general Id. 1 2 2.1 2.2 2.3 Nombre de la tarea Lanzamiento Construcción de la plataforma que donde se desarrollará el sistema Diseño de la plataforma donde se desarrollará el sistema Codificación de la plataforma Introducción de la información primaria 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 Horas Total 25 126,25 395 1994,75 150 757,50 200 1010,00 45 227,25 225 1136,25 125 631,25 100 180 505,00 909,00 100 505,00 70 353,50 4.3 Pruebas del módulo 5 Elaboración de agente diagnóstico 10 225 50,50 1136,25 5.1 Diseño del agente 125 631,25 5.2 Codificación del agente 6 Desarrollo de una interfaz para los resultados del agente diagnóstico 100 170 505,00 858,50 6.1 Diseño de la interfaz 100 505,00 6.2 Codificación de la interfaz 7 Integración de los componentes en su entorno 70 200 353,50 1010,00 7.1 Análisis de la integración 100 505,00 7.2 Realización de la integración Prueba de la aplicación 8 Cierre del proyecto 9 9.1 Acabado de la documentación 9.2 Entrega de la documentación 100 505,00 50 252,50 150 757,50 150 757,50 0 0,00 1620 8181,00 3 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 Total: Precio (€) / hora: 5,05 155 PFC: NOMADA 10.5 Licencias de software necesarias 10.5.1 Licencias para el desarrollo Precio (€) Wind. XP Professional………………………………………………….. Microsoft SQL Server 2000…………………………………….……… Visual Studio .NET Enterprise Architect 2003……………………... Microsoft Office 2003…………………………………………………… Visio 2003…………………………………………………………………. Total: 317,99 1449,99 565,99 549 744 3626,97 10.5.2 Licencias para la implantación Precio (€) Wind. XP Professional………………………………………………….. Microsoft SQL Server 2000…………………………………….……… Total: 317,99 1449,99 1767,98 156 PFC: NOMADA 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 157 PFC: NOMADA 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, 158 PFC: NOMADA 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. 159 PFC: NOMADA 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. 160 PFC: NOMADA [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. 161 PFC: NOMADA [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 162 PFC: NOMADA [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/ 163 PFC: NOMADA 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 164 PFC: NOMADA 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 165 PFC: NOMADA 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. 166 PFC: NOMADA 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) 167 PFC: NOMADA 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. 168 PFC: NOMADA 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 169 PFC: NOMADA 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 valueTimeStamp, ensayo) (varId, VALUES valueVersion, (@varId, varValue, @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) 170 PFC: NOMADA 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) 171 PFC: NOMADA 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 172 PFC: NOMADA 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 173 PFC: NOMADA 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 description, isInput) @description, ParamModels(modelId, topSigma, bottomSigma, VALUES(@modedId, @topSigma, paramNumber, paramName, versionDelay, @paramNumber, @bottomSigma, tagName, @paramName, @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: 174 PFC: NOMADA 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. 175 PFC: NOMADA 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 @ensayo) t2 where diagVersion = @version and ensayo = = @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. 176 PFC: NOMADA 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 patindex(@modelName, HistoricModels paramName) !=0 and ParamModels where 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: 177 PFC: NOMADA select varValue from patindex(@modelName, HistoricModels paramName) !=0 ParamModels and where 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 dbo.ParamModels from where PIHistoric P, (select patindex(@modelName, varId paramName)!=0 from 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 dbo.ParamModels from where PIHistoric P, (select patindex(@modelName, varid paramname)!=0 from 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 178 PFC: NOMADA 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 179 PFC: NOMADA 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 ID_SENAL VALOR FECHA TIPO int BLOB TDATETIME DESCRIPCIÓN Identificador de la señal Valor de la medida 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 ETIQUETA TIPO char DESCRIPCIÓN Etiqueta de DESDE seguridad TDATETIME Fecha inicial de los datos de HASTA la copia TDATETIME Fecha final de los datos de la copia de la copia 180 PFC: NOMADA 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 ID_MODELO TIPO int DESCRIPCIÓN Identificador NOMBRE DESCRIPCION TIPO PARAMETROS función DNOMBRE_MODELO Nombre de la función DDESCRIPCION Descripción de la función DTIPO Tipo de función BLOB Parámetros de la función de la Tabla SE_ENT_MOD, que contenía la relación entre los modelos y sus entradas: CAMPOS ID_SIGNAL ID_MODELO TIPO int DESCRIPCIÓN Identificador de la señal que int es entrada a la función 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 ID_SIGNAL ID_MODELO TIPO int DESCRIPCIÓN Identificador de la señal que int es salida de la función Identificador de la función 181 PFC: NOMADA 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 ID_COMPONENTE COMPONENTE PERTENECE_A TIPO int DCOMPONENTE DCOMPONENTE DESCRIPCIÓN Identificador del componente Nombre del componente 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 ID_SIGNAL ESTADO APODO ANOMALIA TIPO int DESCRIPCIÓN Identificador la señal a la DESTADO DESTADO bool que pertenece el estado Nombre del estado Apodo del estado Indica si el estado genera anomalía 182 PFC: NOMADA Tabla BH_GRUPOS: CAMPOS GRUPO TIPO DELEMENTO DESCRIPCIÓN Nombre del grupo de componentes Tabla BH_GRUPOS_COMP, esta tabla indicaba a que grupo pertenece un componente: CAMPOS ID_COMPONENTE GRUPO TIPO int DELEMENTO DESCRIPCIÓN Identificador del componente Nombre del grupo de componentes Tabla BH_PROPIEDADES, contenía las propiedades que podía tener una variable: CAMPOS PROPIEDAD TIPO DELEMENTO DESCRIPCIÓN Nombre de la propiedad Tabla BH_PROPIEDADES_VAR, esta tabla relacionaba las variables con las propiedades (si la variable tenía propiedades): CAMPOS ID_VARIABLE PROPIEDAD TIPO int DESCRIPCIÓN Identificador de la variable que DELEMENTO tiene la propiedad 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 183 PFC: NOMADA variables que eran salidas de los modelos (existe cierta similitud entre una variable y una señal, por eso aquí se usan indistintamente): CAMPOS ID_SIGNAL TIPO int DESCRIPCIÓN Identificador de la señal ID_VARIABLE int Identificador int asociada a la señal Identificador del DSENAL float float bool DTIPO DSENAL asociado a la señal Nombre de la señal Rango máximo de la medida Rango mínimo de la medida Indica si la señal está activa Unidades de la señal Tipo de señal o constructor de ID_COMPONENTE SIGNAL RANGOMAX RANGOMIN ACTIVIDAD UNIDADES TIPO de la variable componente la señal Tabla BH_VARIABLES, está tabla contenía únicamente los identificadores de las variables y sus nombres: CAMPOS ID_VARIABLE VAR TIPO int DVARIABLE DESCRIPCIÓN Identificador de la variable 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: 184 PFC: NOMADA CAMPOS REGLA ACCION TIPO DREGLA DANTECEDENTE DESCRIPCIÓN Regla a la que pertenece la acción Acción a llevar a cabo Tabla BC_ANTECEDENTES, contenía la relación entre los antecedentes y las reglas: CAMPOS REGLA TIPO DREGLA ANTECEDENTE DANTECEDENTE CONFIANZA float DESCRIPCIÓN Regla a la que pertenece el antecedente Antecedente de la regla 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 AREA DELEMENTO DESCRIPCION DDESCRIPCION DESCRIPCIÓN Nombre del área 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 REGLA TIPO DREGLA CONSECUENTE DANTECEDENTE DESCRIPCIÓN Regla a la que pertenece el consecuente Consecuente de la regla 185 PFC: NOMADA 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 REGLA TIPO DREGLA DIAGNOSTICO DANTECEDENTE DESCRIPCIÓN Regla a la que pertenece el diagnóstico 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 REGLA DESCRIPION AREA IMPLICACION CONFIANZA ACTIVIDAD TIPO DREGLA DDESCRIPCION DELEMENTO DELEMENTO float bool DESCRIPCIÓN Nombre de la regla Descripción de la regla Área a la que pertenece la regla (No se usa) Confianza asociada a la regla 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 COMPONENTE ID_SISTEMA TIPO DCOMPONENTE DDESCRIPCION DESCRIPCIÓN Nombre del componente Sistema al que pertenece el componente 186 PFC: NOMADA 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 ID_RANGO ID_BANDA DESDE HASTA R G B TIPO int int DESCRIPCIÓN Identificador del rango Identificador de la banda a la que int int int int int pertenece el rango Inicio de la banda luminosa (0 – 255) Final de la banda Parte roja del color de la banda Parte verde del color de la banda Parte azul de color de la banda Tabla SAD_CONFIG_RANGOS, relaciona las señales con los rangos a los que pertenece: CAMPOS ID_SIGNAL ID_RANGO TIPO int DESCRIPCIÓN Identificador de la señal asociada int al rango Identificador del rango Tabla SAD_CONVERTIDORES, contenía la información de los convertidores: CAMPOS TIPO ID_CONVERTIDOR int DIRECCION char DESCRIPCIÓN Identificador del convertidor Dirección en la que se NCANALES int encuentra el convertidor Número de canales DDESCRIPCION DELEMENTO convertidor Descripción del convertidor Nombre del convertidor DESCRIPCION CONVERTIDOR del 187 PFC: NOMADA Tabla SAD_SENSORES, contenía la información asociada a los sensores, incluyendo convertidor al que pertenecen y señal asociada al sensor: CAMPOS ID_SENSOR ID_SIGNAL TIPO int int ID_CONVERTIDOR int DESCRIPCIÓN Identificador del sensor Identificador de la asociada al sensor Identificador del señal convertidor al que se conecta el sensor DDESCRIPCION Nombre del sensor DDESCRIPCION Descripción del sensor int Canal del convertidor al que se SENSOR DESCRIPCION CANAL_S conecta Tabla SAD_FICHEROS, indicaba los ficheros que se iban a utilizar para meter las medidas: CAMPOS ID_FICHERO TIPO int DESCRIPCIÓN Identificador ID_SISTEMA int que van las medidas Identificador del sistema que usa RUTA el fichero DDESCRIPCION Ruta del fichero del fichero en el Tabla SAD_SIGNALS, contenía las propiedades de las señales recogidas por el sistema: CAMPOS ID_SIGNAL ID_SISTEMA SIGNAL RGINF RGMAX TIPO int int DESCRIPCIÓN Identificador de la señal Identificador del sistema DSENAL float float pertenece la Nombre de la Rango máximo Rango mínimo al que señal señal de la medida de la señal de la medida de la señal 188 PFC: NOMADA UNIDADES DOMINIO DTIPO int Unidades de la señal (No se usa) Tabla SAD_SIGNAL_E, la tabla vinculaba las señales con el fichero en el estaban: CAMPOS ID_FICHERO ID_SENAL POSICION TIPO int int DESCRIPCIÓN Identificador del fichero Identificador de la señal que va en int el fichero Posición que ocupa la señal dentro del fichero Tabla SAD_SISTEMAS, contenía la definición de los sistemas: CAMPOS ID_SISTEMA SISTEMA DESCRIPCION TIPO int DELEMENTO DDESCRIPCION DESCRIPCIÓN Identificador del sistema Nombre del sistema Descripción del sistema Tabla SAD_ULTIMOS, contenía una relación de señales y valores tomados: CAMPOS ID_SIGNAL FECHA VALOR TIPO int TDATETIME float DESCRIPCIÓN Identificador de la señal Fecha en que se tomó la medida Valor de la medida Tabla SAD_VARIABLES, relacionaba las variables con el sistema al que pertenecían: CAMPOS VAR ID_SISTEMA TIPO DVARIABLE int DESCRIPCIÓN Identificador de la variable Identificador del sistema en el que se encuentra la variable 189 PFC: NOMADA Tabla SAD_VOLUMEN, contenía la información relacionada con las copias de seguridad: CAMPOS ETIQUETA DESDE HASTA TIPO DELEMENTO TDATETIME DESCRIPCIÓN Etiqueta de la copia de seguridad Fecha de los datos más antiguos de la TDATETIME copia 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 ID_MEDIDOR SIGNAL POSICION ETIQUETA TIPO int DSENAL DESCRIPCIÓN Identificador del medidor Nombre de la señal o modelo asociado int al medidor Posición que ocupa la señal de entre DTIPO las asociadas al medidor Etiqueta de la señal asociada Tabla MEDIDORES, esta tabla contenía la posición del medidor en el interfaz: 190 PFC: NOMADA CAMPOS ID_MEDIDOR MEDIDOR VISTA TIPO POS_H POS_W POS_T POS_L TIPO_FORM TIPO int DELEMENTO DELEMENTO DESCRIPCIÓN Identificador del medidor Nombre del medidor Nombre de la vista o esquema al que DTIPO int int int int DTIPO se asocia el medidor Tipo de medidor Altura del medidor Anchura del medidor Posición vertical del medidor Posición horizontal del medidor Tipo de ventana asociada al medidor Tabla VISTAS, contenía la lista de vistas existentes: CAMPOS VISTA ARCHIVO TIPO DESCRIPCIÓN DELEMENTO Nombre de la vista o esquema 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 191 PFC: NOMADA 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. 192