Repositorio Institucional de Documentos

UNIVERSIDAD DE ZARAGOZA CENTRO POLIT´ ECNICO SUPERIOR PROYECTO FIN DE CARRERA Ingenier´ıa de Telecomunicaci´on DESARROLLO DE UN AGENTE SNMPv3 PARA LA GESTI´ ON T´ ECNICA DE DISPOSITIVOS EN ESCENARIOS DE ATENCI´ ON DOMICILIARIA Andreas Mu˜noz Zuara Director: Nelia Lasierra Beamonte Ponente: ´ Alvaro Alesanco Iglesias Dpto. de Ingenier´ıa Electr´onica y Comunicaciones Mayo de 2011 Agradecimientos Este proyecto es el final de una etapa de mi vida llena de esfuerzo y dedicaci´on, pero que sin la ayuda de diversa gente que he ido conociendo a los largo de estos a˜nos no habr´ıa sido posible. Quiero dar las gracias a ´ Alvaro por haberme ofrecido la oportunidad de realizar un proyecto interesante y por haber conseguido gracias a sus asignaturas que me decidiera por telem´atica. Todav´ıa m´as debo agradecer a Nelia su esfuerzo y dedicaci´on para que yo consiguiera terminar el proyecto a tiempo para esta convocatoria, y su apoyo cuando m´as estresado me encontraba. Seguro que echa de menos el llegar a casa y encontrar una docena de correos de mi parte pregunt´andole dudas desesperado. A mis compa˜neros de laboratorio a lo largo de estos arduos meses. A Gonzalo, que siempre nos devolv´ıa al trabajo cuando est´abamos vagos; a Carol, por contagiarnos su alegr´ıa; a Luis yYasmina, por todos los buenos ratos que hemos pasado “frikeando” por internet. Tampoco debo olvidar a mis compa˜neros de clase. A Rub´en, por todas esas risas que nos hemos echado en clase y por ser siempre los primeros en apuntarnos a pr´acticas. A Javi, un compa˜nero de pr´acticas inmejorable. A Natalia, mi ch´ofer particular durante la carrera. A Ver´onica, porque cuando hablo con ella siempre me levanta el ´animo. A Ana yLoreto, por todo el apoyo moral que me han prestado durante el proyecto. A Aguilar,Alba,H´ector,Manu,Miki,Jos´e,Miguel,Cros,Diego y tantos otros, gracias por todos los buenos momentos que hemos pasado juntos. A mis amigos de toda la vida, Diego,Guillermo,V´ıctor,Alberto,Javier,Jorge yLuis por aguantarme todos estos a˜nos, y en especial a Enrique por nuestros duelos entre f´ısicos e ingenieros. A ´ Alvaro yDavid porque aunque nos vemos poco siempre estais ah´ı cuando hace falta. A´ Alex, por haber estado siempre a mi lado en los momentos buenos y no tan buenos, y con el a toda la banda que conoc´ı gracias a ´el, Sara,Sonia,Juan,Boldoba y el resto, sin olvidar a Vallejo que si no le nombro me mata. A mi familia y a todo el que alguna vez me ha ayudado a llegar donde he llegado, que seguro que me dejo unos cuantos, gracias. DESARROLLO DE UN AGENTE SNMPv3 PARA LA GESTI´ ON T´ ECNICA DE DISPOSITIVOS EN ESCENARIOS DE ATENCI´ ON DOMICILIARIA RESUMEN En este proyecto se ha desarrollado un agente SNMPv3 (Simple Network Management Protocol) para la gesti´on t´ecnica de dispositivos involucrados en un escenario de atenci´on domiciliaria. Este agente va a permitir recoger la informaci´on t´ecnica de los dispositivos m´edicos (b´ascula, term´ometro...) asociados al Compute Engine (CE), el cual es el dispositivo concentrador de datos utilizado en la casa del paciente para reunir informaci´on de los dispositivos y enviarla posteriormente al centro sanitario correspondiente. Adem´as, el agente permitir´a la gesti´on t´ecnica del CE, permitiendo as´ı conocer informaci´on de recursos propios de dicho dispositivo y la detecci´on de posibles problemas que afecten al correcto funcionamiento de ´este. El dise˜no del agente se ha adaptado a la utilizaci´on de dispositivos m´edicos que implementen el est´andar X.73 para las comunicaciones con el CE. Para desarrollar las herramientas que componen el sistema de gesti´on se ha utilizado software Java y bases de datos MySQL. El agente no s´olo ofrece la ventaja de una centralizaci´on de la informaci´on proveniente de los dispositivos m´edicos, sino que permite una escalabilidad total. Para llevar a cabo estas funciones, se han dise˜nado los bloques que componen el sistema completo: establecimiento y control de comunicaciones SNMP entre agente y gestores, dise˜no de la MIB de gesti´on de la informaci´on t´ecnica, control de las comunicaciones con el manager X.73 y dise˜no del interfaz del agente y del interfaz de simulaci´on del manager X.73. Adem´as, el agente desarrollado recoger´a informaci´on de los recursos propios del CE mediante encuestas SNMP transparentes al gestor. De esta forma, el agente propuesto permite la gesti´on de la informaci´on t´ecnica de los dispositivos, dejando a elecci´on del gestor la configuraci´on de alarmas y eventos. Por ´ultimo, se han realizado pruebas mediante simulaci´on del sistema de gesti´on propuesto para comprobar el alcance de la gesti´on del sistema y asegurar que todas las capacidades que el sistema se supone debe cumplir para realizar una gesti´on completa realmente se llevan a cabo de forma satisfactoria. Mediante la consecuci´on de estas pruebas, se presenta un resumen de los resultados obtenidos que demuestra la eficacia del sistema de gesti´on de dispositivos m´edicos propuesto. ´ Indice general 1 Introducci´on y Objetivos 1 1.1 Introducci´on................................... 1 1.2 Estadodelarte ................................. 3 1.3 Propuesta.................................... 6 1.4 Objetivos .................................... 8 1.5 Materiales y herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . 9 1.6 Organizaci´on de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2 Arquitectura del Agente 11 2.1 Descripci´on del agente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Descripci´on de la arquitectura SNMP . . . . . . . . . . . . . . . . . . . . 14 2.2.1 Conceptos b´asicos de SNMP . . . . . . . . . . . . . . . . . . . . . 14 2.2.2 Bases de datos en SNMP: MIB . . . . . . . . . . . . . . . . . . . . 16 2.2.3 Caracter´ısticas espec´ıficas de SNMPv3 . . . . . . . . . . . . . . . . 17 2.3 Funcionalidades del agente como proxy . . . . . . . . . . . . . . . . . . . . 18 2.3.1 Est´andar ISO/IEEE 11073 . . . . . . . . . . . . . . . . . . . . . . 19 2.3.2 Protocolo de comunicaciones agente SNMP- Manager X.73 . . . . 19 3 Dise˜no de la MIB MedicalDevicesManager 23 3.1 Introducci´on................................... 23 3.2 Estructura de la MIB Medical Devices Manager . . . . . . . . . . . . . . . 24 3.2.1 Grupo ComputeEngineControlInfo . . . . . . . . . . . . . . . . . . 25 3.2.2 Grupo MedicalDeviceInfo . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.2.1 MedicalDeviceControlTable . . . . . . . . . . . . . . . . . 27 3.2.2.2 MedicalDeviceDataTable . . . . . . . . . . . . . . . . . . 28 i ii ´ INDICE GENERAL 3.2.2.3 MedicalDeviceStateTable . . . . . . . . . . . . . . . . . . 28 3.2.2.4 SpecificErrorsTable . . . . . . . . . . . . . . . . . . . . . 30 3.2.3 GrupoAlarmTable........................... 31 3.2.4 GrupoEventTables........................... 32 3.2.4.1 ConfigEventTable . . . . . . . . . . . . . . . . . . . . . . 32 3.2.4.2 LogTable ........................... 32 3.2.5 Grupo ManagerTable . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.6 Definici´on de los Traps . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.3 Definici´on formal de la MIB . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4 Implementaci´on y pruebas 37 4.1 Definici´on de un entorno de simulaci´on . . . . . . . . . . . . . . . . . . . . 37 4.2 Entornodepruebas............................... 38 4.2.1 Recogida de informaci´on del CE . . . . . . . . . . . . . . . . . . . 39 4.2.2 Recepci´on y almacenamiento de datos de los dispositivos m´edicos . 39 4.2.3 Comprobaci´on de alarmas y eventos . . . . . . . . . . . . . . . . . 42 4.2.4 Actualizaci´on de los MDs . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.5 Borrado de tablas y objetos . . . . . . . . . . . . . . . . . . . . . . 46 5 Conclusiones y l´ıneas futuras 49 5.1 Conclusiones .................................. 49 5.2 L´ıneasfuturas.................................. 51 Bibliograf´ıa 53 ´ Indice de figuras 1.1 Aquitectura general de un sistema de telemonitorizaci´on . . . . . . . . . . 2 1.2 Funcionamiento del manager X.73 . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Esquema general de la arquitectura propuesta . . . . . . . . . . . . . . . . 7 2.1 Esquema de bloques del proyecto . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 Bloques de comunicaciones del agente . . . . . . . . . . . . . . . . . . . . 13 2.3 Ejemplo de creaci´on del OID de un objeto . . . . . . . . . . . . . . . . . . 16 2.4 Sincronizaci´on y conexi´on entre agente y gestor SNMP . . . . . . . . . . . 18 2.5 Comunicaci´on entre manager X.73 y agente SNMP . . . . . . . . . . . . . 21 2.6 Ejemplo de documento XML . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1 Estructura general de la MIB . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2 Objetos de ComputeEngineControlInfo . . . . . . . . . . . . . . . . . . . . 26 3.3 Objetos de MedicalDeviceControlTable . . . . . . . . . . . . . . . . . . . . 28 3.4 Objetos de MedicaDeviceDataTable . . . . . . . . . . . . . . . . . . . . . 29 3.5 Objetos de MedicalDeviceStateTable . . . . . . . . . . . . . . . . . . . . . 29 3.6 Objetos de SpecificErrorsTable . . . . . . . . . . . . . . . . . . . . . . . . 30 3.7 Objetos de AlarmTable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.8 Objetos de ConfigEventTable . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.9 ObjetosdeLogTable.............................. 33 3.10 Objetos de ManagerTable . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1 Interfaz gr´afico del agente desarrollado . . . . . . . . . . . . . . . . . . . . 38 4.2 Visualizaci´on del contenido de la tabla de control del CE . . . . . . . . . . 39 4.3 Interfaz con un term´ometro conectado al sistema . . . . . . . . . . . . . . 40 4.4 Ejemplo de XML que contiene informaci´on de estado . . . . . . . . . . . . 41 iii 41.2. Estado del arte Figura 1.2. Funcionamiento del manager X.73. con los que deba comunicarse y utilicen distinos lenguajes para ello. A pesar de que la arquitectura elegida finalmente es SNMP, durante la b´usqueda y documentaci´on inicial sobre arquitecturas y tecnolog´ıas de gesti´on de redes se encontraron alternativas interesantes. CORBA (4) (Common Object Request Broker Arquitecture) es una arquitectura basada en un mecanismo intermediario llamado broker. La idea es que esta arquitectura nos permite comunicar aplicaciones definidas en diferentes lenguajes y ejecutados en distintas plataformas de manera trasparente sin tener que realizar ning´un proceso intermedio. CORBA se encarga de la comunicaci´on entre sistemas. El funcionamiento de CORBA es el siguiente: tenemos un cliente y un servidor conectados mediante CORBA; el cliente desea realizar una petici´on y se la env´ıa al broker, ´este lo traduce y lo env´ıa al servidor, el cual cursa la petici´on y env´ıa la respuesta al broker, y finalmente se reenv´ıa al cliente. Esta arquitectura es capaz de soportar m´as de veinte lenguajes de programaci´on diferentes, lo que evitar´ıa problemas de incompatibilidad entre sistemas. Para el sistema que se plantea CORBA podr´ıa ser muy interesante, ya que mediante su uso nos olvidarnos de traducir porque la arquitectura se encarga de todo. Adem´as este protocolo tiene diferentes versiones dise˜nadas para equipos con pocos recursos como los sensores, para gastar menos energ´ıa. Por otra parte, SNMP nos permite una gesti´on m´as amplia y est´a muy extendido entre la mayor´ıa de fabricantes. Adem´as, este sistema no es tan heterog´eneo como para apreciar las ventajas que una aplicaci´on de este tipo nos ofrece. MANNA (5) (Management Architecture for Wireless Sensor Networks) es una tecnolog´ıa de gesti´on creada para gestionar redes de sensores wireless. Esta arquitectura Cap´ıtulo 1. Introducci´on y Objetivos 5 propone un sistema integrado de gesti´on de la seguridad desde el que podemos administrar cada nodo sensor a trav´es de una p´agina web. MANNA divide la gesti´on de los sensores en 3 dimensiones: ´areas funcionales, niveles de gesti´on y funcionalidades de WSN (Wireless Sensor Networks). Dentro de los m´odulos funcionales, MANNA dispone de una interfaz de usuario web desde la que se puede monitorizar la red y analizar la informaci´on del sistema; el m´odulo de gesti´on de la informaci´on de los sensores puede mostrar los datos en gr´aficas y permite al administrador cambiar el periodo de las mediciones, el m´odulo de gesti´on del nodo sensor permite gestionar el sensor o un grupo de sensores y pedir informaci´on a los mismos; el m´odulo de informaci´on del nodo sensor permite la autenticaci´on y registro de usuarios autorizados; finalmente, el m´odulo de seguridad de la red proporciona informaci´on del estado de la seguridad de la red. Realmente la idea de MANNA es parecida a la que queremos desarrollar nosotros, un sistema de gesti´on que ofrezca seguridad y permita controlar los par´ametros de los sensores. Sin embargo SNMP tiene la ventaja de que es un sistema muy extendido y que muchos de los dispositivos existentes tipo routers o gateways lo tienen implementado, as´ı que aunque MANNA no ofrece ventajas sustanciales sobre SNMP, ´este ´ultimo si las tiene frente a MANNA. NETCONF (6) es un protocolo de gesti´on muy reciente basado en el protocolo XML. Es el nuevo protocolo del IETF (Internet Engineering Task Force) para la gesti´on de varios dispositivos simult´aneamente, incluso de diferentes fabricantes. Este protocolo permite mantener 3 configuraciones diferentes de gesti´on del equipo: running, la configuraci´on actual del dispositivo; candidate, configuraci´on en standby que puede modificarse con la de running funcionando; y la de startup, que es la configuraci´on inicial del dispositivo. Utiliza una estrucutura en capas para separar de forma adecuada la gesti´on de datos del protocolo de transporte que va por debajo. Un protocolo basado en XML tiene las ventajas de ser muy flexible definiendo estructuras de datos, existen muchas APIs (Application Programming Interface) gratuitas, es f´acil de leer y de transmitir por canales seguros. SNMP es una arquitectura que presenta muchas ventajas en el ´ambito de la gesti´on de redes, por eso es el est´andar de facto, sin embargo no carece de limitaciones. NETCONF ha sido dise˜nado expresamente para suplir las carencias de SNMP respecto a la gesti´on de dispositivos, presentando una alternativa de futuro a SNMP para sistemas donde los 61.3. Propuesta gestores necesiten escribir grandes cantidades de informaci´on en las bases de datos y para la gesti´on de muchos equipos simult´aneamente. Tras evaluar las distintas propuestas, hemos comprobado que SNMP tiene ventajas tanto sobre CORBA como sobre MANNA, sin embargo NETCONF es m´as potente que SNMP. El factor determinante de la elecci´on realizada ha sido la amplia distribuci´on del protocolo a nivel mundial. NETCONF es un protocolo de reciente aparici´on, mientras que SNMP se implementa en la mayor´ıa de routers, gateways y otros dispositivos de diferentes compa˜n´ıas, adem´as de que como no queremos escribir grandes cantidades de informaci´on en la base de datos, sus limitaciones no nos afectan sustancialmente. Existen otros trabajos que utilizan tambi´en SNMP como soluci´on de gesti´on en entornos sanitarios similares, como se puede apreciar en (7), (8) y (9). Sin embargo, la aplicaci´on que se propone en este proyecto a la utilizaci´on del est´andar X.73 resulta novedosa, adem´as de presentarse, a diferencia de los trabajos anteriores, una arquitectura que permite una gesti´on global en un escenario de telemonitorizacion domiciliaria. 1.3 Propuesta En este proyecto se propone el desarrollo de un agente SNMPv3 para la gesti´on t´ecnica de dispositivos m´edicos en entornos de atenci´on domiciliaria. En concreto, se va integrar la gesti´on t´ecnica de los MDs que utilizan el est´andar X.73 para la transmisi´on de datos as´ı como el CE dentro de la arquitectura SNMP. De manera que la arquitectura propuesta de gesti´on integra los dos est´andares. Esta arquitectura nos permite almacenar la informaci´on obtenida de los dispositivos m´edicos de forma estructurada en unas bases de datos propias de esta arquitectura, conocidas como MIB (Management Information Base). El agente propuesto, adem´as de funcionar como agente SNMP para establecer comunicaciones con gestores externos, funcionar´a como proxy X.73. De esta forma, el agente establecer´a comunicaciones con un manager capaz de comunicarse con los dispositivos m´edicos mediante dicho protocolo, aplic´andose as´ı el dise˜no del agente a la utilizaci´on de este protocolo por parte de los dispositivos m´edicos. Por lo tanto, la informaci´on con la que se evaluar´a el funcionamiento de los dispositivos se almacenara en una MIB privada, separada en tablas dependiendo del tipo de informaci´on que se trate. La MIB va a permitir conocer informaci´on t´ecnica de los MDs, as´ı como gestionar recursos propios del CE. La gesti´on del CE se va a llevar a Cap´ıtulo 1. Introducci´on y Objetivos 7 cabo mediante la realizaci´on de encuestas peri´odicas a un agente SNMP presente en el mismo, y finalmente va a permitir la definici´on de eventos y alarmas ante la detecci´on de problemas t´ecnicos tanto en los MDs como en el CE. Como se observa en la figura 1.3, en la que se representa la estructura general del sistema, cualquier gestor que se autentique de forma correcta en nuestro agente podr´a acceder a la informaci´on que ´esta almacena, pudiendo tanto examinar el comportamiento de los dispositivos a lo largo del tiempo como configurar el agente para que le avise cuando haya alg´un problema con alguno de los dispositivos conectados. Figura 1.3. Esquema general de la arquitectura propuesta. Como previamente hemos resaltado, queremos y necesitamos seguridad en nuestras comunicaciones, as´ı que se ha decidido utilizar la versi´on 3 del protocolo. Esta ´ultima versi´on del protocolo nos aporta varios mecanismos de seguridad: USM (10) (User-based Security Model) nos proporciona protecci´on frente a ataques de usuarios que traten de autenticarse en nuestro sistema sin autorizaci´on, el VACM (11) (View-based Acces Control Model) define la pol´ıtica de control de acceso para el agente y determina a qu´e partes del la MIB puede acceder cada gestor, y lo m´as importante es que proporciona cifrado y privacidad a las comunicaciones. El uso de SNMP en el dise˜no del agente nos proporciona las siguientes ventajas: •El agente nos permite gestionar un n´umero indeterminado de dispositivos y mantener un n´umero indeterminado de gestores. •SNMP nos permite la definici´on de traps, mensajes as´ıncronos enviados por el agente al gestor para la notificaci´on de cambios importantes en la monitorizaci´on de un recurso. Su definici´on en este entorno puede ser de gran utilidad para la definici´on y gesti´on de alarmas relacionadas con el funcionamiento de los dispositivos m´edicos. 81.4. Objetivos •La versi´on 3 del protocolo nos proporciona confidencialidad e integridad en las comunicaciones mediante los m´etodos previamente comentados. •Gracias a la integraci´on del CE en la arquitectura SNMP, y utilizando el protocolo X.73 para la transmisi´on de informaci´on, conseguimos una plataforma de gesti´on integrada e interoperable que concentra en un s´olo m´odulo de gesti´on toda la informaci´on t´ecnica procedentes de las diferentes fuentes (CE y MDs) que componen el escenario de telemonitorizaci´on. 1.4 Objetivos El objetivo principal de este proyecto es el dise˜no de un agente SNMP para la gesti´on de dispositivos m´edicos en entornos de atenci´on domiciliaria. Para llevar a cabo la realizaci´on del proyecto se han completado los siguientes objetivos: 1. Dise˜no tecnol´ogico del agente •Documentaci´on sobre el funcionamiento del protocolo SNMP e implementaci´on de bases de datos MIB, as´ı como la revisi´on de las especificaciones de dispositivos del est´andar X.73 y revisi´on bibliogr´afica sobre t´ecnicas de gesti´on de dispositivos m´edicos y t´ecnicas comunes de gesti´on de redes. •Dise˜no de las comunicaciones entre el agente y el gestor para una conexi´on segura. •Dise˜no y desarrollo de la MIB privada en la que se almacenen los datos obtenidos de los dispositivos, as´ı como las alarmas y eventos que los gestores quieran utilizar. •Implementaci´on de las comunicaciones con el manager X.73 mediante intercambio de ficheros XML. •Dise˜no del interfaz gr´afico del agente. 2. Aplicaci´on del agente en un escenario simulado: implementaci´on y pruebas •Dise˜no de un interfaz gr´afico para simular un entorno domiciliario en el que varios dispositivos m´edicos env´ıan informaci´on m´edica al manager X.73 Cap´ıtulo 1. Introducci´on y Objetivos 9 y ´este establece las comunicaciones con el agente dise˜nado para el cual est´a encargado de su control t´ecnico. •Definici´on de los escenarios de prueba necesarios para comprobar el correcto funcionamiento del agente. •Presentaci´on y an´alisis de los resultados obtenidos. 1.5 Materiales y herramientas utilizadas El desarrollo de la aplicaci´on inform´atica se llev´o a cabo sobre el lenguaje de programaci´on Java y el entorno de desarrollo SDK Eclipse. Para el almacenamiento est´atico de los datos se hizo uso de una base de datos MySQL. La conexi´on entre Java y la base de datos se realiz´o mediante el conector de bases de datos JDBC (Java DataBase Conectivity). Para la implementaci´on de las comunicaciones SNMP entre el agente y el gestor se ha utilizado un framework de Java llamado SNMP4j (12). Adem´as se utiliz´o el programa MIB Browser de MG-Soft (13) como gestor para comprobar y demostrar el correcto funcionamiento del agente. Tanto el lenguaje MySQL como la herramienta de programaci´on son multiplataforma, lo que nos proporciona las ventajas de portabilidad e independencia del sistema operativo que se utilice. 1.6 Organizaci´on de la memoria En el cap´ıtulo 1 se ha desarrollado una breve introducci´on al PFC y los objetivos principales que se han perseguido. En el cap´ıtulo 2 se describen los bloques que componen la arquitectura, detallando adem´as las caracter´ısticas m´as importantes de la arquitectura SNMP as´ı como de la informaci´on t´ecnica X.73. En el cap´ıtulo 3 se describe la organizaci´on de la MIB as´ı como se detallan los campos de las tablas y grupos que la componen. El cap´ıtulo 4 recoge las pruebas realizadas y resultados obtenidos de la evaluaci´on del funcionamiento del agente, adem´as de la evaluaci´on y el an´alisis final de la eficacia demostrada por el mismo ante las simulaciones a las que se le someti´o. 10 1.6. Organizaci´on de la memoria Finalmente, en el cap´ıtulo 5 se exponen las conclusiones obtenidas sobre el resultado del proyecto, y las posibles l´ıneas futuras de investigaci´on y mejora que se podr´ıan seguir. Cap´ıtulo 2 Arquitectura del Agente 2.1 Descripci´on del agente El agente se encarga de almacenar informaci´on que proviene de los dispositivos m´edicos facilitando de esta forma su gesti´on t´ecnica a un gestor externo. Como el programa va a ser intermediario de todas las peticiones y acciones que se van a realizar en el sistema global, podemos situarlo en un ´unico dispositivo, creando un sistema centralizado que nos ahorra recursos y facilita la instalaci´on y mantenimiento del mismo. Por lo tanto, el software necesario se ver´a reducido a la instalaci´on del agente en una m´aquina accesible por toda la red y al mantenimiento de gestores SNMP en aquellos sistemas operativos desde los que queramos tener acceso a nuestro agente. La arquitectura general del agente SNMPv3 est´a compuesto por 3 bloques. 1. Bloque de comunicaciones SNMP entre agente y gestor. El agente y el gestor se comunican mediante el protocolo SNMPv3. El agente se encarga de atender las peticiones que le llegan del gestor, del mismo modo que es capaz de enviar mensajes as´ıncronos al gestor cuando alguna de las alarmas definidas por el mismo se activa. 2. Bloque de comunicaciones con el manager X.73. Las comunicaciones entre agente y manager se realizan mediante documentos XML. El agente se encarga de traducir la informaci´on que le llega del manager X.73 en valores que ´el pueda almacenar en la base de datos, adem´as puede enviar XML al manager para pedirle actualizaciones de informaci´on que los dispositivos 11 12 2.1. Descripci´on del agente le hayan comunicado. 3. Bloque de la MIB de gesti´on de dispositivos m´edicos. La MIB va a recoger toda la informaci´on de monitorizaci´on, tanto la proporcionada por los MDs como la proporcionada por el CE adem´as de permitir la definici´on y configuraci´on de alarmas. El agente se encarga tanto de crear las tablas, como de escribir, modificar y borrar datos en ellas, siguiendo una estructura interna que explicaremos m´as adelante. En la figura 2.1 se puede apreciar el resultado final a trav´es del esquema global del sistema. El funcionamiento general del sistema es el siguiente. Los dispositivos m´edicos se comunican con el manager X.73 instalado en el dispositivo concentrador. ´ Este transmite la informaci´on recibida al agente mediante el uso de un protocolo basado en el intercambio de documentos XML. Este protocolo funciona de manera que cuando el dispositivo m´edico realiza un cambio de estado o env´ıa informaci´on al manager, el manager se lo comunica al agente mediante el XML generado. El agente se encarga de traducir y almacenar la informaci´on en la MIB, a la vez que se ocupa de forma est´atica de obtener datos del tr´afico en la red y uso del procesador. Figura 2.1. Esquema de bloques del proyecto. La obtenci´on de datos del CE se realiza mediante encuestas SNMP. El CE, adem´as de nuestra MIB, tiene disponibles otras MIBs para realizar consultas, como es la Cap´ıtulo 2. Arquitectura del Agente 13 MIB2, donde se almacenan par´ametros de tr´afico y del sistema. Nuestro agente manda peticiones de consulta a la MIB2, y a trav´es de unos datos concretos de esa MIB podemos calcular el ancho de banda o el uso de CPU del CE. Cuando el gestor se conecta al agente puede consultar toda la informaci´on almacenada hasta la fecha, adem´as de poder actualizar el estado de los dispositivos a trav´es del agente, que se encarga de proporcionarle todos los servicios que precise. De esta forma el proceso que se lleva a cabo es totalmente transparente de cara al usuario, el cual se encarga solamente de conectar los dispositivos a la m´aquina que contiene el agente, y tambi´en transparente de cara al gestor, que exclusivamente tiene que lanzar peticiones y configurar alarmas y el agente se encarga de procurarle lo que necesita. En la figura 2.2 se muestra m´as detalladamente las comunicaciones entre los distintos bloques que componen el agente. Figura 2.2. Bloques de comunicaciones del agente. En definitiva, el agente propuesto nos ofrece una soluci´on centralizada y transparente al usuario, con posibilidades de integraci´on en una red que ya posea una gesti´on de redes con SNMP. 20 2.3. Funcionalidades del agente como proxy Clase: atributo-subatributo Valor Descripci´on MDS: System-Type-Spec-List MDC DEV SPEC - PROFILE SCALE xxx Tipo de dispositivo (gluc´ometro, b´ascula...) MDS: System-Id OctetString Identificador ´unico del MD. MDS: System-Model::model OctetString Model del MD. MDS: System- Model.manufacturer OctetString Fabricante del MD. MDS: Dev-Configuration-Id Standard config/Extended config Tipo de configuraci´on utilizada por el MD. MDS: Power-Status onMains(0), onBattery(1), chargingFull(8) Muestra si el MD est´a usando bater´ıa o conectado a la red. MDS: Battery-Level Int (percentage) Porcentaje de bater´ıa restante. MDS:: Remaining- Battery-Time MDC DIM MIN, MDC DIM HR, or MDC DIM DAY Timepo restante de bater´ıa. Tabla 2.1. Ejemplo de etiquetas de la clase MDS. implementada esa posibilidad, de momento s´olamente es capaz de devolver al agente los ´ultimos datos recibidos de los dispositivos. La comunicaci´on se realiza mediante socket TCP/IP dentro de la misma m´aquina. Se utiliza una serie de etiquetas para indentificar la informaci´on que se est´a transmitiendo: deviceInfo para la informaci´on t´ecnica, measurementInfo para la informaci´on cl´ınica ystateInfo para la informaci´on del estado del dispositivo. Los comandos que usa el agente para pedir informaci´on son getDeviceInfo ygestStateInfo. Adem´as, cuando la comunicaci´on la inicie el agente, el XML llevar´a un requestId para identificar al mensaje, y relacionarlo con la respuesta enviada por el manager X.73 y saber a qu´e petici´on est´a respondiendo. Cuando el mensaje es enviado de forma as´ıncrona por el manager no hace falta mandar el requestId. En la figura 2.5 se aprecia la comunicaci´on entre manager y agente. En la parte superior se encuentra la comunicaci´on iniciada por el agente pidiendo informaci´on al manager, y en la parte inferior la comunicaci´on as´ıncrona del manager cuando recibe datos de los dispositivos m´edicos. El primer paso que realizan los dispositivos para poder transmitir informaci´on es Cap´ıtulo 2. Arquitectura del Agente 21 Figura 2.5. Comunicaci´on entre manager X.73 y agente SNMP. la asociaci´on con el manager. Esto consiste comunicar que su estado es AVAILABLE. El manager se lo comunica al agente, el cual extrae del documento el indentificador del dispositivo (SystemId), as´ı como la configuraci´on que est´a utilizando. Cuando un dispositivo se retira del CE, enviar´a un estado de NOTAVAILABLE. En la figura 2.6 se presenta un ejemplo de documento XML enviado por un dispositivo m´edico. 22 2.3. Funcionalidades del agente como proxy Figura 2.6. Ejemplo de documento XML. Cap´ıtulo 3 Dise˜no de la MIB MedicalDevicesManager 3.1 Introducci´on Una MIB (Management Information Base) es una base de datos estructurada que sirve para almacenar informaci´on intercambiada a trav´es del protocolo SNMP. En este proyecto, para contener la informaci´on proporcionada por el manager X.73 se ha dise˜nado una MIB privada. Esta base de datos se divide en varias tablas, cada una responsable de un tipo de informaci´on diferente dentro del sistema. Los gestores pueden aceder a la informaci´on recogida en estas tablas e incluso configurar algunas de ellas para mejorar su capacidad de control sobre la informaci´on tabulada, mediante la definici´on de alarmas y eventos, un m´etodo muy eficaz de controlar los valores an´omalos de forma pasiva por parte del gestor. Tambi´en se les permite solicitar actualizaciones de los dispositivos, bien de su estado de conexi´on o de los datos almacenados, as´ı como la configuraci´on del tipo de aviso mediante traps que van a recibir del agente. La definici´on formal de las MIB se realiza mediante un lenguaje de definici´on de datos, el est´andar SMI (Structure of Management Information). La filosof´ıa de este lenguaje prima la sencillez a la hora de definir datos, nos permite una gran flexibilidad y escalabilidad a la hora del dise˜no, de manera que esta base de datos se puede expandir sin demasiada dificultad para aumentar su capacidad de gesti´on sobre los dispositivos en un futuro. Como la definici´on mediante el est´andar SMI es una obligaci´on que impone la arquitectura, permite que cualquier gestor que se conecte al agente sea capaz de 23 24 3.2. Estructura de la MIB Medical Devices Manager interpretar la estructura de la base de datos y de acceder a sus valores con la misma facilidad que si de una MIB p´ublica se tratara, necesitando ´unicamente el gestor tener la definici´on formal de la MIB dentro de su registro de MIBs. El est´andar utilizado nos permite realizar una descripci´on de cada variable dentro de la MIB, de forma que cualquier gestor sea capaz de analizar la informaci´on contenida en las tablas sin necesidad de conocimientos previos de la organizaci´on y prop´osito de la MIB. La definici´on formal se incluye en el anexo E. Adem´as la definici´on de alarmas nos permite tanto la emisi´on de mensajes tipo Trap, como la creaci´on de entradas en una tabla de Logs, para poder comprobar un hist´orico de valores an´omalos, la cual ser´a descrita en el siguiente apartado junto con las dem´as tablas. 3.2 Estructura de la MIB Medical Devices Manager Siguiendo la estructura en ´arbol definida por SNMP, la MIB se incluye dentro del grupo de las MIB privadas, en un grupo llamado ZaragozaNetworkManagementResearchGroup, creado en la Universidad de Zaragoza para contener MIBs creadas por sus grupos de investigaci´on, en el cual se recogen dise˜nos anteriores de bases de datos para la gesti´on de dispositivos. Siguiendo con el orden del grupo, nuestra MIB tendr´a el ´ındice 4 dentro del mismo, con lo que el OID que identificar´a la base de datos MedicalDevicesManager ser´a 1.(iso). 3(org). 6(dod). 1(internet). 4(private). 1(enterprises). 28308(zaragozaNetWorkManagementResearchGroup). 4(medicalDevicesManager). En la figura 3.1 se observa la estructura de la MIB dentro de la organizacion jer´arquica de SNMP. La estructura de la MIB MedicalDevicesManager se dispone en 5 grupos, los cuales contienen 10 tablas en total, separados seg´un la informaci´on que contienen y la relaci´on entre las tablas que contienen. En el primer grupo, ComputeEngineControlInfo, encontramos la informaci´on relacionada con los recursos propios del CE. El siguiente, MedicalDeviceInfo, contiene las tablas que almacenan informaci´on de los dispositivos m´edicos, tanto de control, como de datos y estados, y finalmente de los errores sucedidos. Cap´ıtulo 3. Dise˜no de la MIB MedicalDevicesManager 25 Figura 3.1. Estructura general de la MIB. El grupo AlarmTable contiene las alarmas definidas por el gestor. EventTables es el grupo que contiene las tablas de eventos definidos por el gestor, y los logs resultantes de los eventos. El siguiente grupo contiene la tabla donde se almacena la informaci´on relativa a los gestores del sistema, y finalmente nos encontramos con las posibles traps que puede enviar el agente. Para el dise˜no de la MIB se ha seguido la filosof´ıa de RMON (17). RMON se define como una extensi´on de las MIB que basa su funcionamiento en la organizaci´on de la MIB que implementa en tabla de control y tabla de datos, consiguiendo de esta forma soportar nuevas funciones adem´as de las de SNMP: configuraci´on e invocaci´on de acciones. En los subapartados siguientes se explica de forma m´as detallada la organizaci´on de cada tabla y su funcionalidad. La informaci´on par´ametro a par´ametro de cada una de ellas se encuentra en el anexo C. 3.2.1 Grupo ComputeEngineControlInfo En este grupo no encontramos ninguna tabla, sino “hojas”, como se observa en la figura 3.2, en las que se almacenan informaci´on est´atica que caracteriza al CE, tales como su identificador dentro del sistema, tipo de dispositivo, estado de trabajo en el que se encuentra o n´umero de MDs asociados en ese momento; asimismo tambi´en encontramos informaci´on de los recursos propios del CE, como son el ancho de banda 26 3.2. Estructura de la MIB Medical Devices Manager utilizado y el uso de memoria y de procesador, recogidos con periodicidad de un minuto de las tablas MIB II mediante encuestas SNMP al propio dispositivo y de forma transparente al gestor, incluyendo la fecha en la que se recogieron por ´ultima vez estos valores. Tambi´en se conserva informaci´on de contacto con el usuario que posee el CE. Finalmente encontramos dos variables escribibles, updateRequestStateMDs y updateRequestTechnicalDataMDs, que le permiten al gestor pedir una actualizaci´on del estado o los datos t´ecnicos de todos los MDs que tiene asociados, respectivamente. Figura 3.2. Objetos de ComputeEngineControlInfo. La forma de acceder a cada uno ser´a mediante un OID, que se contruir´a a partir del el identificador de la rama madre m´as un ´ındice consecutivo empezando por el 1 para cada hoja, tal que as´ı: 1 .3 .6 .1 .4 .1 .28308 .4(MedicalDevicesManager) .1(computeEngineControlInfo) .X, siendo X un valor del 1 al 15, que es el n´umero de hojas de esta rama. 3.2.2 Grupo MedicalDeviceInfo El grupo medicalDeviceControlInfo contiene toda la informaci´on relativa a los datos y recursos pertenecientes a los dispositivos m´edicos asociados. Toda esa informaci´on se organiza en 4 tablas, divididas por informaci´on de control, datos t´ecnicos de los Cap´ıtulo 3. Dise˜no de la MIB MedicalDevicesManager 27 dispositivos, errores sucedidos durante la recogida de esos datos, y cambios en el estado de asociaci´on de los MDs. A cada MD dentro de nuestra base de datos vamos a proporcionarle un identificador que servir´a para indexar varias de las tablas de la MIB. Ese identificador ser´an n´umeros consecutivos en orden de la primera conexi´on al CE. La forma de indexar las entradas de las tablas de este apartado ser´a mediante el identificador del dispositivo responsable de la entrada, y para las entradas correspondientes a datos, estados y errores, tambi´en se utilizar´a el ´ındice del dato, estado o error en cuesti´on, quedando un OID de esta forma: 1 .3 .6 .1 .4 .1 .28308 .4(MedicalDevicesManager) .2(MedicalDeviceInfo) .1(MedicalDeviceControlTable) .A(identificador de la tabla dentro del grupo) .1(Entry de la tabla) .B(indentificador del par´ametro dentro de la tabla) .C(identificador del dispositivo) .D(identificador del dato, estado o error, cuando se requiera). 3.2.2.1 MedicalDeviceControlTable Esta tabla contiene informaci´on est´atica de los dispositivos. Entre ellos se incluyen el fabricante, modelo e identificador del MD, adem´as del tipo de dispositivo, protocolo, configuraci´on utilizada y la fecha en que se conect´o por primera vez al CE. Finalmente contiene dos par´ametros de escritura similares a los descritos en el grupo anterior, updateRequestState y updateRequestTechData, que en este caso se utilizan para permitir al gestor pedir la actualizaci´on del estado o informaci´on t´ecnica del dispositivo en cuesti´on. Se crear´a una entrada nueva en esta tabla cada vez que un nuevo dispositivo se registre en el CE. Es posible que la primera vez que un dispositivo se conecte no nos proporcione informaci´on suficiente para llenar todos los par´ametros de la nueva entrada. Si es as´ı, todos los valores no facilitados permanecer´an con un valor nulo hasta que el MD los actualice en pr´oximas transmisiones. Para solicitar una actualizacion de valores, el gestor activar´a la actualizaci´on poniendo el valor 1 en los campos de updateRequestState o updateResquestTechnicalData. Posteriormente estos valores volver´an al valor anterior para no estar realizando peticiones de actualizaci´on continuamente. 28 3.2. Estructura de la MIB Medical Devices Manager Figura 3.3. Objetos de MedicalDeviceControlTable. 3.2.2.2 MedicalDeviceDataTable Esta tabla contiene informaci´on relativa al funcionamiento t´ecnico de los MDs tales como el tipo de alimentaci´on, el nivel de bater´ıa restante y la estimaci´on de la duraci´on de la bater´ıa, o si se ha producido alg´un error en esa medici´on. Adem´as guardamos tambi´en la fecha en que se realiz´o esa entrada en la tabla. Para cada uno de los dispositivos esta tabla permite registrar un total de 20 entradas relativas a sus datos t´ecnicos, lo que permitir´a realizar comparativas o permitir´a observar su comportamiento a lo largo del tiempo. Cuando un dispositivo env´ıa por primera vez un dato, se incializan sus 20 entradas a un valor nulo y se van rellenando conforme van llegando m´as mediciones. Una vez completas todas las entradas disponibles, se empiezan a sobreescribir las entradas m´as antiguas y se actualiza la posici´on de cada entrada para que la nueva entrada pase a ser la primera en la tabla. A la hora de evaluar las entradas desde el gestor, ignoraremos aquellas que todav´ıa sigan con valor nulo. 3.2.2.3 MedicalDeviceStateTable Cuando el manager detecta un cambio de estado en un dispositivo lo hace saber mediante el documento XML correspondiente. En esta tabla se almacenan esos cambios Cap´ıtulo 3. Dise˜no de la MIB MedicalDevicesManager 29 de estado. Adem´as del nuevo estado, en esta tabla podemos encontrar la fecha en que se recibi´o la informaci´on y los identificadores correspondientes al dispositivo y el n´umero de captura de la entrada. Para esta tabla se han seguido las mismas reglas respecto al tama˜no y la inicializaci´on que en la tabla anterior. Figura 3.4. Objetos de MedicaDeviceDataTable. Figura 3.5. Objetos de MedicalDeviceStateTable. 36 3.3. Definici´on formal de la MIB de administraci´on, convenciones, sintaxis y reglas b´asicas para la construcci´on de MIBs. La definici´on completa y estructura formal de la MIB se recoge en el anexo E. Un ejemplo de la definici´on ser´ıa el siguiente: idComputeEngine OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION ‘‘This is the identifier for this compute engine inside the network.’’ ::= { computeEngineControlInfo 1} Cada objeto de la MIB tiene que tener especificados los siguientes par´ametros: Nombre (usando la convenci´on SMI), tipo de dato del ASN.1 (integer32,octetstring, objectidentifier,etc.) o de los tipos de datos definidos en la MIB (en este caso: Date, DisplayString EntryStatus, Mode, OperationValue, OwnerString), el tipo de acceso permitido para ese valor (lectura, escritura, lectura / escritura), soporte de la implementaci´on requerida (status: definidos todos en este caso como obligatorios), una breve descripci´on del objeto y su relaci´on con otros objetos de la MIB, es decir, su posici´on dentro del ´arbol, indicando a qu´e tabla pertenece y en qu´e posici´on se encuentra. Cap´ıtulo 4 Implementaci´on y pruebas 4.1 Definici´on de un entorno de simulaci´on Para comprobar el correcto funcionamiento del sistema integrado, se han realizado una serie de pruebas incluyendo todos los aspectos que el agente es capaz de gestionar. Hemos realizado las pruebas con un software de simulaci´on de dise˜no propio que nos permitir´a reproducir situaciones reales de funcionamiento. El primer interfaz es el que nos aparece al lanzar el agente en un equipo. Este interfaz nos permite configurar el puerto y la IP en el que escuchar´a el agente, as´ı como los par´ametros de seguridad que regir´an las comunicaciones. Estos par´ametros est´an compuestos por el nombre de usuario, las contrase˜nas de autenticaci´on y privacidad y el nivel de seguridad de la comunicaci´on (privacidad y autenticaci´on, s´olo autenticaci´on o ninguna de las dos). Una vez lanzado el interfaz, podemos conectarnos al mismo mediante un gestor SNMP comercial. En nuestro caso utilizamos MIB Browser. Adem´as de escuchar en un puerto a la espera de la conexi´on del gestor, el agente tambi´en abre un socket que le permitir´a recibir los documentos XML proporcionados por el manager X.73. El interfaz se puede observar en la figura 4.1, en el anexo A se puede comprobar con m´as detalle la forma en que el agente se conecta al gestor y recibe estos documentos. El segundo interfaz nos permitir´a simular la presencia de dispositivos m´edicos en el sistema. Vamos a simular 4 tipos diferentes de dispositivos: term´ometro, b´ascula, pulsiox´ımetro y medidor de presi´on arterial. El interfaz simula el comportamiento de estos dispositivos, permitiendo enviar modificaciones en el estado o mensajes con informaci´on t´ecnica. Tras seleccionar el tipo de informaci´on que se va a transmitir, 37 38 4.2. Entorno de pruebas Figura 4.1. Interfaz gr´afico del agente desarrollado. se crea un documento XML que representar´a dicha informaci´on mediante las etiquetas correspondientes del protocolo X.73 para cada par´ametro. Esta informaci´on se transmite utilizando un socket como si del verdadero manager se tratara. Este interfaz se explica m´as detalladamente en el anexo B. 4.2 Entorno de pruebas Para evaluar los resultados obtenidos en las pruebas realizadas al agente, vamos a mostrar el comportamiento del agente mediante un ejemplo que ilustraremos con capturas de pantalla en el que se seguir´a el proceso l´ogico de conexi´on y env´ıo de datos de un dispositivo, adem´as de la creaci´on de alarmas y eventos y su posterior funcionamiento. Para comprobar que los valores en las tablas son correctos nos conectaremos al agente con el MIB Browser y visualizaremos las tablas desde su interfaz gr´afico. Cap´ıtulo 4. Implementaci´on y pruebas 39 4.2.1 Recogida de informaci´on del CE Cuando activamos el agente, aparte de abrir el socket y quedarse escuchando a la espera de conexiones por parte del gestor, tambi´en empieza la recogida de informaci´on de recursos propios del CE. El agente env´ıa peticiones SNMP a la MIB II presente en el CE en la que se recoge informaci´on del tr´afico y nivel de utilizaci´on de los sistemas del CE. Estos datos se almacenan en la tabla de control del CE. El resto de valores de esa tabla son est´aticos en su mayor´ıa y se escriben al iniciar el agente por primera vez. En la figura 4.2 vemos los objetos pertenecientes a la tabla de control tras consultar los recursos propios del sistema. Figura 4.2. Visualizaci´on del contenido de la tabla de control del CE. 4.2.2 Recepci´on y almacenamiento de datos de los dispositivos m´edicos Uno de los principales objetivos del agente es el mantenimiento de una MIB con la informaci´on que le llega de los dispositivos m´edicos. Para comenzar las pruebas, partimos del supuesto de que el agente acaba de ser instalado en el CE y no se ha conectado todav´ıa ning´un dispositivo, por lo tanto sus tablas est´an vac´ıas. As´ı podemos comprobar que desde el principio el agente funciona correctamente. En este caso vamos a simular la conexi´on de un term´ometro al CE. Al conectarse el bot´on rojo del interfaz gr´afico pasa a color verde si se ha realizado la conexi´on, como 40 4.2. Entorno de pruebas vemos en la figura 4.3. Lo primero que hacen los dispositivos al conectarse por primera vez es mandar su estado de funcionamiento. Cuando un dispositivo se conecta por primera vez debe enviar un estado de AVAILABLE. A partir de ese momento el dispositivo puede cambiar de estado, pero no podr´a enviar datos hasta que se encuentre en estado ASSOCIATED. La primera vez que llegue a este estado el dispositivo enviar´a informaci´on t´ecnica, y a partir de entonces cada vez que el dispositivo se asocie podr´a enviar informaci´on, cambiando su estado a OPERATING. En la figura 4.4 se muestra un ejemplo de XML. Figura 4.3. Interfaz con un term´ometro conectado al sistema. Para interpretar la informaci´on presente en el documento, el agente lee las etiquetas que deben llevar los par´ametros para poder ser interpretadas por el protocolo X.73. En la figura 4.4 vemos algunos ejemplos de etiquetas. Unas etiquetas se utilizan para informaci´on como la etiqueta STATEINFO para imformar de un estado. Tambi´en hay etiquetas de atributos como MDC ATTR DEV CONFIG, que sirve para indicar que el valor siguiente es la configuraci´on del dispositivo. Dentro del XML, la informaci´on se divide en apartados seg´un el tipo de Cap´ıtulo 4. Implementaci´on y pruebas 41 Figura 4.4. Ejemplo de XML que contiene informaci´on de estado. informaci´on que se trate: t´ecnica, m´edica o de estado. Dentro de cada apartado se transmiten diferentes atributos, cada uno con un identificador (como el MDC ATTR DEV CONFIG) y el valor o valores correspondientes. Los atributos m´edicos tambi´en incluyen la escala con la que est´an tomados. Tras interpretar la informaci´on contenida en el documento, el agente almacena dicha informaci´on en la tabla que corresponda. Lo primero que se comprueba es si el dispositivo que ha enviado el mensaje est´a registrado previamente en la MIB. De no ser as´ı, lo registramos en la tabla de control de MDs y le asignamos un identificador dentro de la MIB. Adem´as, actualizamos el n´umero de MDs conectados al CE en la tabla de control del CE. Si la informaci´on era t´ecnica, se crea una entrada en la tabla de datos. Los datos m´edicos inclu´ıdos en un XML con la informaci´on t´ecnica servir´an para comprobar si las medidas realizadas por el dispositivo entran dentro de los m´argenes aceptables de trabajo. Es decir, si un term´ometro est´a registrando valores de 50 ◦C, hay algo que no funciona bien. Si el dispositivo transmite un error espec´ıfico o el dato m´edico se sale de los umbrales de aceptaci´on, se crea a su vez una entrada en la tabla de errores. Finalmente, la informaci´on de estado se escribir´a en la tabla de estados. Como explicamos en el cap´ıtulo anterior, las tablas de datos y estados han sido limitadas en extensi´on para evitar sobrecargar al agente con tablas demasiado grandes. Siguiendo con el ejemplo que se ha iniciado al conectar un nuevo dispositivo, seguimos realizando cambios en su estado, para posteriormente poder enviar informaci´on. En la figura 4.5 podemos observar los estados por los que ha pasado el dispositivo antes de poder enviar informaci´on. El siguiente paso es el env´ıo de informaci´on por parte del dispositivo, cuyo registro 42 4.2. Entorno de pruebas en las tablas de la MIB podemos apreciar en la figura 4.6. A continuaci´on conectaremos otro dispositivo m´as (figura 4.7) y enviaremos mensajes con datos que contienen errores, tanto generales de funcionamiento como espec´ıficos a traves del pulsiox´ımetro. En las figuras 4.8 y 4.9 podemos observar el funcionamiento de la MIB en esos casos. 4.2.3 Comprobaci´on de alarmas y eventos El gestor crea una alarmas o evento mediante el env´ıo de peticiones SNMP. Para ello nuestro agente tiene que tratar esas peticiones, comprobar qu´e tipo de petici´on es, y tratarla como corresponda. Se van a definir una serie de alarmas para probar los diferentes tipos de Traps que se pueden enviar. Primero se define una alarma que mande un trap de tipo Warning cuando el primer dispositivo que se conect´o env´ıe un estado de DISCONNECTED. En la figura 4.11 se puede apreciar la configuraci´on de la alarma. Hay que tener en cuenta que para poder definir una alarma antes se deben tener creados los eventos a los que se va a asociar, como se puede comprobar en la figura Figura 4.5. Vista desde MIB Browser del contenido de la tabla de estados. Figura 4.6. Vista desde MIB Browser del contenido de la tabla de datos. Figura 4.7. Conexi´on de varios dispositivos. Cap´ıtulo 4. Implementaci´on y pruebas 43 Figura 4.8. Ejemplo de datos con errores. Figura 4.9. Vista de la tabla de errores. 4.10. Tampoco se puede validar la alarma hasta que no se hayan definido un n´umero Figura 4.10. Error al crear alarma al no estar creado el evento asociado. 44 4.2. Entorno de pruebas determinado de objetos dentro de la tabla, y hasta que la alarma no se haya validado no ser´a evaluada a la hora de determinar si se activan o no las alarmas. Figura 4.11. Alarma configurada para el estado DISCONNECTED. Para evaluar si se activa una alarma, cada vez que se introduce un nuevo dato en una tabla, el agente comprueba si su OID coincide con alguno perteneciente a una alarma definida y validada. En el caso de que as´ı sea, comprueba que el valor de la variable cumple las restricciones impuestas por la alarma, esto es, el valor no excede los umbrales o no es un valor concreto que activa la alarma. En caso de activarse la alarma, el evento asociado a la misma indica lo que se debe hacer a continuaci´on. Seg´un sea el caso se transmite un trap al gestor que defini´o la alarma, se crea una entrada en la tabla de logs o ambas acciones. En la figura 4.12 vemos c´omo llega una Trap al gestor indicando, adem´as del tipo de Trap, el valor que ha hecho activarse la alarma. 4.2.4 Actualizaci´on de los MDs Para simular el comportamiento del manager X.73 ante una petici´on de actualizaci´on de un dispositivo, se dispone de una serie de XML con informaci´on que responde a todos los tipos de peticiones que pueden llegar de parte del agente. Tras enviar la petici´on, se simular´a que el manager la ha recibido, la ha procesado y responde con un XML. La respuesta es procesada a su vez por el proxy y posteriormente se trata como si de un mensaje as´ıncrono enviado por el manager se tratara, actualizando las tablas que sean necesarias. Cap´ıtulo 4. Implementaci´on y pruebas 45 Figura 4.12. Trap enviada por la alarma anterior. Para ilustrarlo en la figura 4.14 se puede comprobar como tras la petici´on de actualizaci´on del dispositivo, se ha producido una actualizaci´on en su estado. Figura 4.13. Estados del dispositivo antes de actualizar. Figura 4.14. Estados del dispositivo despu´es de actualizar. Bibliograf´ıa [1] W.Stallings. “SNMP and SNMPv2: The Infraestructure for Network Management”. IEEE Communications Magazine, 1998. [2] W.Stallings. “SNMPv3: A Security Enhancement For SNMP”. IEEE Communications Surveys, 1998. [3] ISO/ IEEE11073. Health informatics Medical Devices Communication [P11073- 20601. Application profile-Optimized protocol]. http://standards.ieee.org/. Primera edici´on: 2006. [4] M.Rodr´ıguez, R.Sanz, S.Gal´an, C.Garc´ıa, R.Chinchilla, A.Yela. “CORBA: Una plataforma software para el futuro”. [5] Shinkyung Lee, Namje Park, Dooho Choi. “Security Mangement System for Sensor Network”. International Conference of Convergence and Hybrid Information Technology 2008, 2008. [6] James Yu, Imad al Ajarmeh. “An Empirical Study of the NETCONF Protocol”. 2010 Sixth International Conference on Networking and Services, 2010. [7] Jungho Seo, Jungil Heo, Suyoung Lim, Jinsoo Ahn, Wooshik Kim. “A Study on the Implementation of a Portable u-Healthcare System using SNMP and AODV”. Proceeding of the 29th Annual International Conference of the IEEE EMBS Cit´e Internationale, Lyon, France, 2007. [8] Yen Yang Lim, Marco Messina, Frank Kargl, Leena Ganguli, Martin Fisher, Tommy Tsang. “SNMP-Proxy For Wireless Sensor Network”. Fifth Intenational Conference on Information Technology: New Generations, 2007. 53 54 Bibliograf´ıa [9] “WilocT: localizaci´on y trazabilidad en entornos sanitarios”. Reportaje de RFID Magazine, 2009. [10] U. Blumenthal and B.Wijnen. “User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)”. Technical Report RFC 2574, Internet Engineering Task Force (IETF), 1999. [11] B. Wijnen, R. Presuhn, and K. McCloghrie. “View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)”. Technical Report RFC 2575, Internet Engineering Task Force (IETF), 1999. [12] Framework SNMP4j. El API de SNMP orientada a objetos para agentes y gestores Java. Disponible en: http://www.snmp4j.org/. [13] MIB Browser. Gestor comercial de MG-Soft. Disponible en: http://www.mg-soft.si/. [14] K. McCloghrie, D. Perkins, and J. Schoenwaelder. “Structure of Management Information Version 2 (SMIv2)” Technical Report RFC 2578, Internet Engineering Task Force (IETF), 1999. [15] Borrador de comunicaci´on de datos entre manager X.73 y agente Versi´on 1.6. Communications Technologies Group (GTC), Universidad de Zaragoza, 2011. [16] N.Lasierra, A.Mu˜noz, A.Alesanco, J.Escayola, J.Garc´ıa. “SNMPv3-ISO/IEEE 11073 integration for technical management in home-based telemonitoring scenarios”, 2011. [17] S. Waldbusser. “Remote Network Monitoring Management Information Base” Technical Report RFC 2819, Internet Engineering Task Force (IETF), 2000. [18] K. McCloghrie, D. Perkins, and J. Schoenwaelder. “Structure of Management Information Version 2 (SMIv2)”. Technical Report RFC 2578, Internet Engineering Task Force (IETF), 1999.