Desarrollo, despliegue y validación de un laboratorio virtual oceanográfico basado en computación Grid

UNIVERSIDADE DE SANTIAGO DE COMPOSTELA Departamento de Electrónica e Computación Tesis doctoral DESARROLLO, DESPLIEGUE Y VALIDACIÓN DE UN LABORATORIO VIRTUAL OCEANOGRÁFICO BASADO EN COMPUTACIÓN GRID Presentada por: D. David Mera Pérez Dirigida por: Dr. D. José Manuel Cotos Yáñez Dr. D. José Varela Pet Noviembre de 2012 Dr. D. José Manuel Cotos Yáñez, Profesor Titular de Universidad del Área de Lenguajes y Sistemas Informáticos de la Universidad de Santiago de Compostela Dr. D. José Varela Pet, Profesor Contratado Doctor de Universidad del Área de Lenguajes y Sistemas Informáticos de la Universidad de Santiago de Compostela HACEN CONSTAR: Que la memoria titulada DESARROLLO, DESPLIEGUE Y VALIDACIÓN DE UN LABORATORIO VIRTUAL OCEANOGRÁFICO BASADO EN COMPUTACIÓN GRID ha sido realizada por D. David Mera Pérez bajo nuestra dirección en el marco del Programa de Doctorado Interuniversitario de Investigación en Tecnologías de la Información del Departamento de Electrónica e Computación de la Universidade de Santiago de Compostela, y constituye la Tesis que presenta para optar al título de Doctor. Este trabajo ha sido desarrollado en los siguientes centros de investigación de la Universidad de Santiago de Compostela: – Centro Singular de Investigación en Tecnoloxías da Información (CITIUS). – Instituto de Investigacións Tecnolóxicas (IIT). Noviembre de 2012 Dr. D. José Manuel Cotos Yáñez Director de la tesis Dr. D. José Varela Pet Codirector de la tesis D. David Mera Pérez Autor de la tesis The Answer to the Great Question, of Life, the Universe and Everything [...] Forty-two, said Deep Thought, with infinite majesty and calm. [...] That quite definitely is the answer. I think the problem, to be quite honest with you, is that you’ve never actually known what the question is. The Hitchhiker’s Guide to the Galaxy. Agradecimentos Parece que fue ayer cuando me embarqué en este viaje pero la realidad es que ya ha pasado bastante tiempo y, sobre todo, muchas horas de trabajo. Es el momento de echar la vista atrás y pensar en todo el apoyo recibido de mis compañeros de trabajo, amigos, familia y organizaciones sin el cual esto nunca hubiese llegado a buen puerto. En primer lugar, agradecer al Dr. José Manuel Cotos Yáñez y al Dr. José Varela Pet, directores del presente trabajo, la oportunidad de emprender esta aventura junto a ellos y por la confianza depositada en mí desde el comienzo. Gracias por apoyarme, guiarme y dedicarme tantas horas de vuestro tiempo para sacar esto adelante. A mis compañeros de trabajo del Instituto de Investigaciones Tecnológicas, con los que he pasado la mayor parte de este tiempo, que me han aconsejado y ayudado siempre que lo he necesitado. A Carmen Cotelo Queijo, mi compañera de armas en el proyecto de RETELAB, por echarme una mano desinteresada siempre que me ha hecho falta. Al Dr. Pablo García Rodríguez por sus conocimientos y consejos pero especialmente por su apoyo y ánimos durante todo el trabajo. Al Dr. Óscar García Pineda de la Universidad Estatal de Florida por su tiempo y conocimientos e indicarme el camino cuando éste estaba poco claro. A mis amigos por aguantar mis «rollos frikis», por darme siempre ánimos y, sobre todo, por estar siempre ahí aunque los tenga abandonados. VIII A Leticia, «mi vida», por todas las horas que le he robado y que no podré devolverle. No sabría como expresar lo importante que has sido. Gracias por estar siempre a mi lado y por tu apoyo incondicional. Sin ti, esto no sería posible. A mi familia y, en especial a mis padres, por todo el cariño y apoyo recibido durante toda mi vida y por confiar en que yo era capaz de cualquier cosa y animarme siempre a luchar y a esforzarme al máximo en todos los aspectos de la vida. Sin vosotros yo no sería quien soy. Gracias por todo. Y a tantos otros que no he nombrado pero que llevo en la cabeza y en el corazón. ¡GRACIAS A TODOS! IX Este trabajo no habría sido posible sin el apoyo y/o colaboración de las siguientes instituciones: – Sociedad de Salvamento y Seguridad Marítima (SASEMAR), concretamente el Centro de Coordinación de Salvamento de Finisterre que nos facilitó los datos sobre los vertidos detectados en la costa gallega durante los últimos años. – Ministerio de Educación y Ciencia a través de la financiación del proyecto «Laboratorio Virtual para la Red Nacional de Teledetección Oceanográfica» con referencia ESP200613778-C04. – Xunta de Galicia a través de la financiación del proyecto «Análise e interpretación de imaxes de satélite a partires de técnicas de intelixencia artificial: aplicación a contaminantes no medio mariño» con referencia PGIDIT08SIN001236PR. – Universidad de Santiago de Compostela mediante el «Programa de Contratos Predoctorales de la Universidad de Santiago de Compostela 2010». XVI Índice de figuras 3.15. Esquema de la arquitectura empleada para el envío y monitorización de trabajosenRETELAB.............................. 55 3.16. Integración del espacio de almacenamiento privado del usuario con el portlet deenvíodetrabajos............................... 56 3.17. Integración del Data Grid con el portlet de envío de trabajos. . . . . . . . . . 57 3.18. Portlet para la monitorización de los trabajos de usuario. . . . . . . . . . . . 58 3.19. Representación de la temperatura superficial en un instante de una simulación empleandoROMS................................ 59 3.20. Composición de la monitorización de un trabajo y su integración con el Data Grid y el sistema de visualización de IDV. . . . . . . . . . . . . . . . . . . 61 4.1. Orígenes de los vertidos de hidrocarburos. . . . . . . . . . . . . . . . . . . 66 4.2. Resolución espacial de un radar a bordo de un satélite. . . . . . . . . . . . . 67 4.3. Antena virtual generada por SAR. . . . . . . . . . . . . . . . . . . . . . . . 68 4.4. Imagen SAR de la costa gallega obtenida por el satélite Envisat (04/05/2007). 69 4.5. Efecto del viento en la retrodispersión de un pulso SAR. . . . . . . . . . . . 70 4.6. Sistema automático para la detección de sentinazos. . . . . . . . . . . . . . 72 4.7. Analisis de la forma de 1.638 sentinazos detectados en el Mediterráneo duranteelaño1999. .............................. 74 5.1. Esquema de Separación de Tráfico de Fisterra. . . . . . . . . . . . . . . . . 78 5.2. Imagen SAR del vertido provocado por el accidente del buque petrolero Prestige(17/11/2002). ............................. 79 5.3. Bases de la Agencia española de Salvamento y Seguridad Marítima (SASEMAR) en Galicia y recursos asignados a la región. . . . . . . . . . . 80 5.4. Espectro electromagnético. . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.5. Retrodispersión media obtenida de una imagen Radar de Apertura Sintética Avanzado (ASAR) Wide Swath Mode (WSM) para vientos de 4 m/s, 6 m/s y 10m/s. ..................................... 84 5.6. Representación de la densidad de cobertura de la Base de Datos. . . . . . . . 85 5.7. Área de estudio y Esquema de Separación de Tráfico de Fisterra (ESTF). . . 86 5.8. DB de imágenes con sentinazos utilizada para el proyecto SENTINAZOS . . 86 5.9. Localización de los sentinazos contenidos en las imágenes de la colección. . 87 5.10. Máscara de tierra utilizada en SENTINAZOS. . . . . . . . . . . . . . . . . 88 Índice de figuras XVII 5.11. Ejemplo de uso del filtro de mediana . . . . . . . . . . . . . . . . . . . . . 89 5.12. Píxeles muestreados agrupados según su Ángulo de Incidencia (IA). . . . . . 90 5.13. Elementos de la muestra agrupados por la velocidad del viento. . . . . . . . 91 5.14. Esquema de acciones realizadas para establecer el umbral adaptativo. . . . . 92 5.15. Representación de la aproximación de la intensidad en función del IA para distintos valores de la velocidad del viento. . . . . . . . . . . . . . . . . . . 93 5.16. Componentes principales y porcentaje de varianza explicado. . . . . . . . . 96 5.17. DB de candidatos etiquetados utilizados para desarrollar los clasificadores. . 97 5.18. Elementos de una neurona artificial. . . . . . . . . . . . . . . . . . . . . . . 99 5.19. Estructura de una red neuronal Perceptrón Multicapa (MLP). . . . . . . . . 100 5.20. Ejemplo simplificado de una red MLP. . . . . . . . . . . . . . . . . . . . . 101 5.21. Esquema de la neuronas empleadas en la Red Neuronal Artificial (ANN) desarrollada. .................................. 103 5.22. Arquitectura del clasificador desarrollado basado en una red neuronal MLP. . 104 5.23. Ejemplo de desarrollo de un árbol de decisión binario. . . . . . . . . . . . . 106 5.24. Árbol de decisión binario, sin podar y con hojas puras, generado por el proceso de entrenamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.25. Árbol de decisión binario podado. . . . . . . . . . . . . . . . . . . . . . . 108 5.26. Pantalla principal del software de escritorio. . . . . . . . . . . . . . . . . . 109 5.27. Captura de pantalla del resultado de procesar una imagen SAR a través de los parámetros por defecto y un clasificador ANN. . . . . . . . . . . . . . . 111 5.28. Captura de pantalla del portlet desarrollado para integrar SENTINAZOS en ellaboratoriovirtual. ............................. 112 6.1. Composición de dos imágenes SAR y resultados generados por los diferentes clasificadores. ................................. 114 6.2. Detalle de los sentinazos detectados por la ANN . . . . . . . . . . . . . . . 115 9.1. Arquitectura del Cloud relacionada con los servicios que proporciona. . . . . 129 Índice de tablas 5.1. Número de embarcaciones identificadas en el ESTF. . . . . . . . . . . . . 78 5.2. Parámetros orbitales del satélite Envisat. . . . . . . . . . . . . . . . . . . . 81 5.3. Modos de operación del sensor ASAR a bordo del Envisat. . . . . . . . . . 83 5.4. Coeficientes y puntos de corte para las funciones de umbral adaptativo. . . 93 5.5. Vector de características. . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.6. Componentes principales y porcentaje de varianza explicado. . . . . . . . 96 5.7. Coeficientes de los componentes principales seleccionados. . . . . . . . . 97 6.1. Eficacia de los diferentes clasificadores sobre los conjuntos de validación y test....................................... 113 7.1. Diferentes sistemas de detección de vertidos y su porcentaje de eficacia en laclasificación................................. 118 CAPÍTULO 1 INTRODUCCIÓN Las necesidades computacionales de la sociedad actual son cada vez mayores. Determinadas áreas de investigación como la física de altas energías, las ciencias de la Tierra o la meteorología, ven limitado su desarrollo por la necesidad de más y mejores recursos computacionales. Aunque el desarrollo tecnológico es la primera barrera que se encuentran los investigadores, también lo es el acceso a la propia tecnología, ya que, a menudo, la tecnología más puntera es económicamente inaccesible o su uso requiere de extensos conocimientos que limitan su generalización. La computación distribuida surge con el objetivo de permitir la colaboración y compartición de recursos para reducir costes y maximizar la capacidad de almacenamiento y procesamiento. Su rápida evolución permitió a los investigadores resolver problemas complejos que hasta hace poco eran inasumibles y afrontar retos más ambiciosos incluso cuando los medios de los que disponían eran escasos. La observación remota de la Tierra es un claro ejemplo en el que las necesidades computacionales avanzan a un ritmo difícil de igualar por el desarrollo tecnológico. Desde que en 1957 el Sputnik Soviético fuese el primer satélite en ser enviado al espacio, han sido muchas las misiones tanto civiles como militares que se han llevado a cabo para observar remotamente la Tierra. Año tras año el número de misiones espaciales, así como el número de proyectos de investigación relacionados con éstas, se ha ido incrementando y, al menos en un futuro a corto y medio plazo, la política a este respecto será continuista, ya que según un informe de Euroconsult, Satellite-Based Earth Observation, Market Prospects to 2017, se espera que cerca de 200 nuevos satélites estén operativos en el 2017. 2Capítulo 1. Introducción Gracias a los avances tecnológicos, las misiones se han vuelto cada vez más sofisticadas y cuentan con instrumentación más especializada, generando un gran volumen de información sobre nuestro planeta que es necesario almacenar y procesar. La observación remota de la Tierra o teledetección se ha convertido en una técnica imprescindible en el seguimiento y estudio de determinados procesos ambientales críticos para nuestro planeta como, por ejemplo, el cambio climático, el deshielo o el deterioro de la capa de ozono. Del mismo modo, la teledetección también es esencial en el seguimiento de desastres, tanto naturales como provocados por el hombre, como son los incendios, los terremotos o los vertidos contaminantes. En particular, la teledetección es una herramienta fundamental en el estudio de los océanos y sus fenómenos asociados. Los océanos cubren cerca de las tres cuartas partes del planeta y albergan al 97% de las especies pero, a pesar de estas cifras, a menudo no somos conscientes de su importancia e influencia; por ejemplo: son el pulmón del planeta, ya que más de la mitad de la captura mundial de CO2y de la producción de oxígeno se realizan a través del mecanismo conocido como Producción Primaria (PP) [56], las actividades relacionadas con el mar sustentan al 10-12% de la población mundial [42] y nuestra dependencia energética hacia ellos es incuestionable, puesto que aproximadamente la mitad de la producción mundial de gas natural y el 30% de la de petróleo se extrae de los yacimientos presentes en el lecho marino [11]. El estudio de los océanos es una tarea interdisciplinar en el que grupos tan heterogéneos como los de los biólogos, físicos, meteorólogos, oceanógrafos o informáticos deben trabajar juntos para abordar problemas de naturaleza compleja y obtener los mejores resultados. A menudo, dichos grupos se encuentran dispersos y pertenecen a centros diferentes, lo que supone un problema, tanto organizativo como de seguridad y, en muchos casos, este tipo de dificultades puede obstaculizar la buena marcha de los proyectos o directamente imposibilitarlos. Además, la gran cantidad de datos, obtenidos a través de la observación remota y necesarios para la investigación, genera grandes dificultades en cuanto a su almacenamiento, procesamiento y distribución. Los centros necesitan disponer tanto de recursos de computación de altas prestaciones como de almacenamiento masivo, acordes a las necesidades de los proyectos pero esto no siempre es posible. La computación Grid, paradigma de la computación distribuida, se posiciona como la tecnología más adecuada para cubrir las demandas tecnológicas de la investigación oceanográfica y proporcionar un acceso ágil y eficiente a los datos almacenados. La computación Grid permite desplegar entornos dedicados a compartir recursos entre diferentes centros a través de la 1.1. Computación Grid 3 red y, además, permite administrar grupos virtuales de usuarios que se forman, en el marco de un proyecto, para maximizar sus posibilidades en torno a objetivos comunes. 1.1. Computación Grid Tradicionalmente, los grupos y las organizaciones para la investigación han trabajado de forma local con sus propios recursos (computadores, sensores, bases de datos, etc.) y, a menudo, la heterogeneidad de los recursos, así como la ausencia en el uso de estándares, ha dificultado tanto la colaboración con otros centros como la compartición de la información. Este modelo de trabajo queda obsoleto desde el momento en que se afrontan problemas interdisciplinares, interorganizativos y que demandan cantidades ingentes de recursos que ningún centro puede asumir por sí solo. Un ejemplo de ello es el proyecto Large Hadron Collider (LHC) que genera alrededor de 15 Petabytes de datos cada año [99], los cuales deben ser almacenados, procesados y distribuidos. Proyectos de tal envergadura, que normalmente engloban a multitud de grupos, hacen necesario modificar la forma de trabajar y buscar alternativas que permitan compartir recursos para adaptarse a las necesidades de los proyectos. La colaboración entre grupos interdisciplinares y dispersos geográficamente es una pieza clave en este nuevo modelo de trabajo, ya que deja obsoleto el concepto tradicional de organización y da paso a las llamadas Organizaciones Virtuales (VOs), donde diferentes grupos se unen durante un período de tiempo determinado y comparten sus recursos para acometer unas actividades concretas. La compartición de recursos en VOs debe entenderse en el sentido más general, es decir, acceso remoto a software, Bases de Datos (DBs), sensores, computadoras y cualquier otro tipo de medio tanto físico como lógico, por lo que se hacen indispensables métodos adaptados para su gestión. Durante la década de los 90 aparece una nueva aproximación denominada computación Grid que nace con los objetivos de solucionar las demandas computacionales de la sociedad y de facilitar la adaptación a los nuevos conceptos organizativos. La computación Grid supone un nuevo paradigma de computación distribuida que permite agregar y compartir recursos heterogéneos y geográficamente distribuidos entre diferentes organizaciones. En uno de los primeros esfuerzos por concretar el término Grid, Ian Foster y Carl Kesselman [46] lo definen como: «Una infraestructura hardware y software que proporciona un acceso fiable, consistente, generalizado y de bajo coste a capacidades computacionales de alta calidad.» 4Capítulo 1. Introducción Profundizando en la descripción tenemos que: – Por infraestructura, Foster y Kesselman se refieren a un conjunto de recursos heterogéneos que incluye datos, sensores, ciclos de computación, etc., así como al hardware necesario para la interconexión de los recursos y el software utilizado para su monitorización y gestión. – El acceso es considerado fiable si proporciona a los usuarios unos niveles de rendimiento altos, predecibles y estables. – Por acceso consistente se entiende que se proporcionan servicios a través de interfaces estándar y utilizando parámetros normalizados. El uso de estándares beneficia a la generalización del paradigma y al desarrollo de aplicaciones de usuario. – Se considerará que el acceso es generalizado si el usuario cuenta con un núcleo de servicios genéricos sea cual sea el sistema Grid al que se conecta. – El acceso a bajo coste es determinante para su aceptación, ya que su uso deberá ser más rentable que el de sus alternativas. A medida que la tecnología Grid fue evolucionando, la definición anterior fue manifestándose insuficiente e incluso se dudó de la necesidad de este nuevo paradigma; por ello, Foster et ál. [52] redefinen el concepto y lo asocian a un problema sin resolver: «El problema real que subyace tras el concepto Grid es la coordinación de organizaciones virtuales dinámicas y multiinstitucionales en la resolución de problemas y la compartición de recursos.» En la definición anterior, se entiende por una VO un conjunto de personas y/o instituciones que se agrupan a través de una política de compartición de recursos. Las VOs pueden variar en gran medida en cuanto a su propósito, ámbito, tamaño, duración y localización. Los autores justifican la necesidad de este nuevo paradigma por no existir, hasta ese momento, una tecnología de computación distribuida que permitiese gestionar recursos compartidos basándose en relaciones tan flexibles como las de las VOs, con sofisticados controles de acceso que incluyesen una gestión desde el punto de vista más específico al más general, con delegación de credenciales o que integrase el uso de políticas tanto locales como globales y que, además, ofreciera un alto rendimiento, calidad de servicio, planificación de las tareas, múltiple asignación de recursos, monitorización y bajo coste. 1.1. Computación Grid 5 La Figura 1.1 muestra un ejemplo de un sistema Grid y del uso de los recursos compartidos por parte de dos VOs. En este ejemplo, tres centros ponen a disposición de la comunidad parte de sus recursos pero gestionados por una política de acceso que filtra por la VO a la que pertenecen los usuarios. Cada centro está etiquetado con los recursos que comparte y la política de seguridad que se les aplica. Centro B Centro C Centro A Participantes en la VO-Ciclos pueden utilizar potencia computacional siempre y cuando no esté en uso por el centro propietario Participantes en la VO-Aeronáutica pueden acceder a la BD1 y BD2 Participantes en la VO-Aeronáutica pueden ejecutar el SW1 Participantes en la VO-Aeronáutica pueden ejecutar el SW2 y SW3 Figura 1.1: Ejemplo básico de un sistema Grid formado por 3 centros que comparten parte de sus recursos con dos VOs (VO-Aeronáutica y VO-Ciclos). Los participantes en la VO-Ciclos aprovechan la potencia computacional (ciclos) de los recursos compartidos por los centros ‘A’ y ‘C’. Los participantes de la VO-Aeronáutica pueden ejecutar aplicaciones que han sido compartidas por los centros ‘A’ y ‘B’ y acceder a las DBs del centro ‘B’. Elaboración propia a partir de [52]. A medida que las tecnologías Grid se fueron popularizando, el término Grid se empezó a explotar comercialmente diluyéndose su significado y utilizándose como eslogan para captar nuevos clientes. Las empresas incluyeron el término en muchos productos que difícilmente podían encajar dentro de su definición. En un intento de delimitar el concepto, Ian Foster [49] publicó una lista con 3 puntos básicos que recogen la esencia del concepto y que, en una publicación posterior junto con Carl Kesselman [8], agrupó para proponer una nueva definición: 12 Capítulo 1. Introducción – Por último, la Sección 3.6 muestra diferentes aplicaciones integradas para validar el laboratorio virtual e introduce el sistema desarrollado para detectar vertidos de hidrocarburos denominado SENTINAZOS y que centra la siguiente parte de la memoria. La segunda parte de la tesis doctoral describe en detalle el proyecto SENTINAZOS, «Análise e interpretación de imaxes de satélite a partires de técnicas de intelixencia artificial: aplicación a contaminantes no medio mariño». El proyecto, con referencia PGIDIT08SIN001236PR, fue financiado por la Consellería de Innovación e Industria de la Xunta de Galicia entre los años 2008 y 2010 e implicó, en su desarrollo, a la Universidad de la Coruña (UDC) y la USC; los equipos de ambas instituciones abordaron el problema desde dos puntos de vista diferentes pero complementarios: – La UDC centró su esfuerzos en el desarrollo de algoritmos para la detección grandes cantidades de vertidos ocasionados por catástrofes. – La USC se implicó en el desarrollo de un sistema de detección de pequeños vertidos (sentinazos) ocasionados, generalmente, por tareas de mantenimiento y en la integración de dicho sistema en RETELAB. Después de introducir, en el Capítulo 4, el problema de la contaminación oceánica y el estado del arte de los sistemas de detección de vertidos, el Capítulo 5 se centra en el desarrollo del sistema implementado. La descripción detallada del problema a resolver (Sección 5.1) y las fuentes de datos empleadas (Sección 5.2) son la antesala para entrar en el detalle de las diferentes fases y algoritmos involucrados en el análisis e interpretación de las imágenes Radar de Apertura Sintética (SAR): – Las diferentes acciones de preprocesado necesarias para preparar los datos SAR para su posterior análisis son descritas en la Sección 5.3. – La segmentación de la imagen, relacionando las condiciones meteorológicas con la intensidad de la señal del satélite, se detalla en la Sección 5.4. Durante esta fase los posibles vertidos o candidatos son identificados y aislados. – La Sección 5.5 describe el proceso por el que cada candidato es descrito empleando un conjunto de características. 1.4. Estructura de la memoria 13 – Cada candidato, a través de técnicas de Inteligencia Artificial (AI), es clasificado como falso positivo o vertido según sus descriptores. La implementación, uso y comparación de los diferentes clasificadores empleados es detallada en la Sección 5.6. – La Sección 5.7 describe la aplicación de escritorio desarrollada para validar el sistema, así como su integración en RETELAB a través de un portlet. La parte reservada al desarrollo de SENTINAZOS finaliza con un análisis detallado (Capítulo 6) y la discusión (Capítulo 7) de los resultados obtenidos. Los capítulos finales de la tesis doctoral se reservan para mostrar los resultados y conclusiones del trabajo (Capítulo 8) y para perfilar las líneas de investigación abiertas por la tesis doctoral y que sería interesante desarrollar a corto y medio plazo (Capítulo 9). Parte I Laboratorio Virtual de Teledetección Oceanográfica CAPÍTULO 2 EVOLUCIÓN DE LA COMPUTACIÓN GRID 2.1. Estandarización de las tecnologías Grid La computación Grid (véase el Capítulo 1) es un paradigma de computación distribuida que surge como respuesta a dos necesidades: por un lado, la de disponer de entornos especializados en la resolución de problemas complejos con altas demandas computacionales y, por otro, la de gestionar VOs que permitan la colaboración entre grupos interdisciplinares y dispersos geográficamente. El camino hacia su estandarización y globalización (véase la Figura 2.1) se inicia a principios de la década de los 90 a partir de implementaciones ad hoc que resolvían problemas concretos. Las aplicaciones resultantes aprovechaban la potencia computacional procedente de unir diferentes recursos distribuidos. En esta primera etapa, la meta de los desarrolladores era hacer que funcionasen las aplicaciones y explorar nuevas posibilidades tecnológicas. La implementación se realizaba directamente sobre los protocolos de Internet sin seguir ningún tipo de estándar y, en general, las soluciones estaban muy limitadas en cuanto a seguridad, escalabilidad, robustez o interoperabilidad. I-WAY [44] es considerado el primer Grid moderno que abrió la puerta al desarrollo y estudio de la computación Grid en profundidad [22] [9]. Se presentó en la conferencia ACM/IEEE Supercomputing del año 1995 (SC95) a través de una demostración en la que se conectaron 17 centros de supercomputación por medio de 11 redes de alta velocidad. Se creó un superordenador virtual sobre el que se probaron alrededor de 60 aplicaciones diferentes. I-WAY exploró varios aspectos que ahora se consideran esenciales en un Grid como la seguridad o 18 Capítulo 2. Evolución de la Computación Grid 1990 1995 2000 2005 Soluciones "Ad-Hoc" Globus Toolkit Open Grid Services Arch. Funcionalidad y estandarización Gestión de sistemas virtuales compartidos Estándar de facto Implementación única Estándares de iure Múltiples implementacionesEstándares de internet Web services, etc. 2010 Figura 2.1: Evolución de las tecnologías Grid. Imagen adaptada de [50]. el envío y la gestión de trabajos. Su éxito demostró las posibilidades de la computación Grid y llevó a aumentar considerablemente los esfuerzos en el desarrollo de proyectos concebidos para compartir recursos de computación distribuidos. I-WAY puede considerarse el germen del proyecto Globus [45], que surge con el objetivo de investigar y desarrollar tecnologías Grid fundamentales y marca el comienzo de la segunda etapa en la evolución hacia la estandarización. El proyecto, liderado por Ian Foster (codesarrollador de I-WAY y fundador del concepto de computación Grid), tiene uno de sus pilares en la implementación del Globus Toolkit (GT) [47]. El GT es un conjunto de componentes software diseñado para desplegar infraestructuras Grid y proporcionar servicios que gestionen aspectos tales como la seguridad, el envío de trabajos o la administración de los recursos. El GT se sitúa en la capa de middleware, es decir, entre la capa de aplicaciones de usuario y la de recursos. Esta capa proporciona herramientas que permiten que los recursos participen de forma coordinada en un entorno unificado y aseguren el acceso transparente a los usuarios. Además del GT, surgieron otros proyectos para el desarrollo de infraestructuras Grid como Legion [57] o Uniform Interface to Computing Resources (UNICORE) [94] pero, desde su primera versión en 1998, el GT se posicionó como el middleware dominante y, en 2002, su segunda versión (GT2) se estableció como el estándar de facto en el desarrollo de aplicaciones Grid. 2.1. Estandarización de las tecnologías Grid 19 El GT2 fue pionero en el desarrollo de sistemas Grid interoperables [50] pero, aunque algunos de sus componentes fueron desarrollados formalmente, en general, la implementación del GT2 carecía de directrices y no fue sometida a una revisión pública. A medida que la computación Grid se establecía y se popularizaba (trascendiendo incluso al ámbito académico), se hizo más patente la necesidad de desarrollar estándares que aportasen total interoperabilidad no sólo a nivel de aplicaciones Grid, sino también de componentes fundamentales del sistema y permitiesen la integración de múltiples tecnologías en un sistema de recursos compartidos [73]. En el año 2002 surge la Open Grid Service Architecture (OGSA) [51], la cual define un estándar que incluye servicios básicos de computación Grid como la seguridad, gestión de recursos, administración de trabajos, etc. OGSA busca la convergencia entre la tecnología Grid y los servicios Web, por lo que define una arquitectura abierta basada en servicios para desarrollar entornos Grid. OGSA no aporta detalles para la implementación del estándar y, en consecuencia, surge una importante dificultad: OGSA requería servicios Web con estado pero el estándar de dichos servicios no lo proporcionaba. En 2003 surge la Open Grid Services Infrastructure (OGSI), la cual detalla una posible implementación de OGSA y presenta una versión modificada de los servicios Web denominada servicios Grid [68]. Estos servicios proporcionaban, entre otras cosas, soporte para el estado gracias a una modificación del Web Services Description Language (WSDL) [30] llamada Grid Web Service Definition Language (GWSDL) [115]. La tercera versión del GT surge en 2004 y, en su camino hacia la estandarización, basa su implementación en el estándar definido por OGSI. La comunidad Grid pronto consideró que OGSI era una aproximación poco conveniente [102], sobre todo por usar una versión modificada de los servicios Web en lugar de basarse en el estándar. Se continuó trabajando para encontrar una mejor solución para la implementación del estándar OGSA, en general, y para la implementación de servicios Web con estado, en particular. En 2004 se propuso la especificación Web Service Resource Framework (WSRF) con el objetivo de sustituir a OGSI y aportar una implementación de los servicios Web con estado aceptada tanto por la comunidad Grid como por la comunidad de servicios Web. WSRF integra OGSA con los servicios Web puros y es la base para la implementación de la cuarta versión del Globus Toolkit (GT4) (versión empleada en el desarrollo del laboratorio virtual de RETELAB). 20 Capítulo 2. Evolución de la Computación Grid El término de servicio Grid ha continuado utilizándose pero, a partir de la especificación de WSRF, se asocia a cualquier servicio que, de acuerdo a la nueva especificación, se ajuste a las convenciones de interfaz de una infraestructura Grid. Continuando con el proceso de estandarización, Foster y Kesselman [50] anticiparon en el año 2003 una futura fase en la búsqueda de un sistema Grid global que denominaron gestión de sistemas virtuales compartidos. Partiendo de la especificación de OGSA, en esta fase se preveía un incremento del conjunto de servicios y sistemas estándar orientados a la interoperabilidad. Este nuevo conjunto de estándares estaría enfocado a la administración tanto de dispositivos móviles como de grandes sistemas con múltiples VOs, y todo ello aumentando el grado de virtualización, enriqueciendo los modos de compartición e incrementando la calidad de servicio. 2.2. Arquitectura de un sistema Grid La arquitectura de un sistema Grid desarrollado con GT (véase la Figura 2.2) se divide en capas y está construida sobre los principios del modelo de reloj de arena (hourglass model) [50], en el que las capas intermedias, situadas en el cuello del reloj, contienen un conjunto de protocolos e interfaces que los desarrolladores de servicios y aplicaciones de más alto nivel (capas superiores) utilizan y que les permiten abstraerse de los desarrollos y tecnologías de las capas inferiores que gestionan el uso de los recursos locales. – Capa de infraestructura (Fabric layer): proporciona las operaciones básicas sobre los recursos que serán utilizadas como base para el desarrollo de operaciones de más alto nivel. – Capa de conectividad (Connectivity layer): define el núcleo de los protocolos utilizados para la comunicación y la autenticación requeridos en las transacciones. – Capa de recursos (Resource layer): contiene los protocolos necesarios para gestionar de forma remota el acceso e interacción con los recursos individuales. – Capa colectiva (Collective layer): contiene protocolos para la gestión de recursos múltiples. Utiliza los protocolos definidos en las capas inferiores para implementar sus operaciones. 2.3. Interfaces Grid 21 Recursos locales: computadoras, redes, almacenamiento, sensores, etc. Acceso seguro a recursos y servicios. Gestión de recursos múltiples: diagnóstico, monitorización, etc. Herramientas y aplicaciones de usuario. Capa de aplicaciones Capa colectiva Capa de recursos Capa de conectividad Capa de infraestructura Figura 2.2: Arquitectura Grid basada en capas y construida sobre los principios del modelo de «reloj de arena». Figura adaptada de [50]. – Capa de aplicaciones (Application layer): esta capa contiene las aplicaciones de usuario que se implementan de forma específica para dar respuesta a un problema dentro del entorno de una organización virtual. Para su desarrollo se utilizan las interfaces desarrolladas en las capas inferiores. 2.3. Interfaces Grid Existen dos tipos de usuarios relacionados con los sistemas Grid, desarrolladores y usuarios finales. Es habitual que los usuarios no tengan grandes conocimientos tecnológicos y, en particular, la formación en este ámbito es muy escasa. Éstos ven al sistema como un medio para desarrollar su trabajo, por lo que la usabilidad del entorno ha de ser primordial. La CLI es la solución básica para el acceso a un Grid pero es muy poco amigable y requiere de un estudio previo de los comandos y sus formas de uso, por lo que habitualmente es rechazada por los usuarios finales. Es conveniente desarrollar entornos que faciliten el acceso y utilización de los sistemas y, en la medida de lo posible, que abstraigan a los usuarios de los detalles tecnológicos para que puedan centrarse en sus trabajos. Con el desarrollo de la Web 2.0 surge la tendencia de migrar aplicaciones y sistemas a la Web, convirtiendo Internet en un entorno amigable y conocido para el usuario. La compu- 28 Capítulo 2. Evolución de la Computación Grid está implementado a través de componentes JSP reutilizables que pueden ser integrados en nuevas implementaciones. Al contrario de OGCE, que utilizaba varias APIs, GridPortlets proporciona una única API de alto nivel pensada para acceder a los servicios Grid e interactuar con los recursos y así desarrollar portlets y aplicaciones Grid específicas. Los portlets desarrollados a través de GridPortlets no son completamente independientes de GridSphere y, aunque teóricamente son compatibles con el API estándar, no se pueden integrar fácilmente en otros contenedores de portlets [116]. GridPortlets, pensando en la usabilidad, proporciona una sencilla pero potente interfaz para el envío de trabajos que abstrae al usuario de los detalles de bajo nivel y almacena un detallado historial de cada trabajo procesado para que pueda ser consultado a posteriori. 2.3.3. Portales Grid: casos de estudio Durante la primera década del siglo XXI, sobre todo en los primeros años, la incidencia de los sistemas Grid en la sociedad fue en aumento, no sólo en el campo académico, sino también en el empresarial. La estandarización de las tecnologías Grid y la mejora de las interfaces de usuario hicieron de esta tecnología una valiosa herramienta. Fueron muchos los sistemas Grid desplegados y numerosos también los portales Grid desarrollados para interactuar con los sistemas de una forma amigable. Una gran mayoría de estos portales estaban centrados en la visualización de información, monitorización de los recursos y sistemas y en la ejecución de tareas simples; no obstante, algunos otros profundizaron en la tecnología y desarrollaron aplicaciones Web que facilitaban la realización de tareas Grid complejas a los usuarios. GENIUS Grid Portal La Organización Europea para la Investigación Nuclear (CERN), en general, y el proyecto LHC, en particular, han ejercido una gran influencia en el desarrollo de la tecnología Grid. El portal Grid GENIUS [19] [15], implementado dentro del marco del proyecto europeo DataGrid, fue desarrollado para proporcionar acceso a los datos del LHC y permitir su utilización en diferentes aplicaciones sobre un sistema Grid. Estaba diseñado para proporcionar un acceso seguro a funcionalidades Grid como el envío y ejecución de trabajos, la administración de datos o el acceso interactivo para el análisis de los datos generados. GENIUS fue un portal Grid pionero basado en una versión extendida del GT. Este middleware modificado extendió la interfaz de Globus facilitando la interacción entre las aplicaciones software y el sistema Grid. La primera versión del portal se puede considerar dentro 2.3. Interfaces Grid 29 de la primera generación de portales Grid (véase la Sección 2.3.1), ya que su desarrollo está fuertemente acoplado con el middleware utilizado. El portal permitía el acceso remoto de usuarios pero mantenía la necesidad de tener una cuenta personal en el servidor del portal con la que se proporcionaba acceso al sistema de ficheros local. La autenticación y autorización de los usuarios sobre los recursos Grid se realizaba a través de la delegación de credenciales implementada con MyProxy (véase la Sección 3.2) Earth System Grid (ESG) En general, los proyectos relacionados con el estudio de la Tierra poseen una serie de particularidades que dificultan su desarrollo a través de medios tradicionales: – Generan cantidades ingentes de información, bien sea a través de la observación directa de fenómenos o bien a través de la ejecución de modelos que los simulan. – Los algoritmos y modelos utilizados suelen requerir una gran potencia computacional. – Implican ciencias interdisciplinares en donde trabajan científicos de diferentes ramas que deben colaborar para obtener el máximo rendimiento de las investigaciones. La computación Grid se adapta especialmente bien a este tipo de proyectos y, en concreto, el proyecto ESG [23] es uno los más relevantes. Centrado en la investigación climática, ESG proporciona un entorno colaborativo con el objetivo de almacenar, distribuir y procesar las enormes cantidades de datos utilizadas en el seno de sus proyectos. Además de proporcionar la infraestructura necesaria para el almacenamiento de la información climática, gran parte de los esfuerzos del proyecto fueron destinados a desarrollar estándares y servicios de metainformación orientados a administrar, navegar, buscar y compartir los datos almacenados. Un portal Grid facilita el acceso a los datos y los servicios de búsqueda y recuperación de información. El acceso a los recursos Grid se basa en el sistema de delegación de credenciales de MyProxy (véase la Sección 3.2) pero ESG desarrolló y empleó un novedoso sistema de registro de usuarios para la generación automática de credenciales. El Portal-based User Registration Service (PURSe) [53] permite el registro de usuarios y la creación y administración de sus Certificados Digitales (DCs) y respectivos proxies de forma automática. Originalmente fue desarrollado dentro del proyecto pero, posteriormente, evolucionó como sistema independiente e integrable en nuevos portales Grid. 30 Capítulo 2. Evolución de la Computación Grid PURSe encaja perfectamente con la política de facilidad de uso que dirige el proyecto RETELAB, por lo que fue integrado como medio de registro de usuarios. No obstante, el módulo de registro fue modificado y mejorado para dar un soporte más amplio que el proporcionado por defecto y así ajustarse a las necesidades del laboratorio virtual. Los detalles de implementación y de integración se muestran en detalle en la Sección 3.2. P-Grade P-Grade es un portal Grid, basado en GridSphere, concebido para soportar formas complejas de ejecución de trabajos dirigidas por flujos de tareas (workflows). P-Grade está diseñado para trabajar con Globus como middleware, lo que le permite integrarse con cualquier sistema Grid que lo utilice y aportarle la capacidad avanzada de administración de flujos de tareas. Proporciona a los usuarios un editor de flujos que permite diseñar localmente las tareas y subirlas al servidor. Empleando Java Web Start (JavaWS), los usuarios pueden descargar el editor desde el portal y éste se instala automáticamente y de forma transparente en la estación de trabajo del usuario. Dentro de un mismo flujo de tareas, P-Grade soporta la asignación de trabajos a recursos que pertenezcan a diferentes Grids e incluso la creación de flujos colaborativos entre varios investigadores. Es tarea del usuario la asignación de los recursos en concreto en donde se vaya a ejecutar una parte del flujo, por lo que el usuario debe conocer la estructura del sistema. CAPÍTULO 3 PROYECTO RETELAB 3.1. Descripción del proyecto RETELAB es un laboratorio virtual, desplegado sobre un sistema distribuido, que proporciona un entorno de trabajo colaborativo enfocado al desarrollo de proyectos de teledetección oceanográfica [78] [33]. Nace en el seno de la red RETEMAR con el objetivo proporcionar un entorno para llevar a cabo proyectos de altas prestaciones entre sus integrantes. Según las especificaciones iniciales, los requerimientos que debía cubrir el laboratorio virtual eran: – Gestión de recursos compartidos: el laboratorio virtual debía poseer la capacidad de integrar y administrar recursos distribuidos pertenecientes a los diferentes centros de la Red. – Soporte para el almacenamiento, administración e intercambio de datos distribuidos: el almacenamiento local tiene grandes limitaciones a la hora de administrar las ingentes cantidades de datos capturados a través de la teledetección, por lo que RETELAB debía disponer de un sistema de datos distribuidos que permitiese almacenar, procesar y compartir la información. – Potencia computacional: en general, las aplicaciones científicas oceanográficas (modelos climáticos, detección de contaminantes, etc.) demandan una gran cantidad de recursos computacionales. El sistema proporcionaría la potencia necesaria para su ejecución. 32 Capítulo 3. Proyecto RETELAB – Seguridad: dado que el laboratorio proporcionaría acceso a recursos compartidos, la seguridad debía ser uno de los pilares en el diseño e implementación de RETELAB. – Interfaz amigable: es necesario que la interfaz de acceso al sistema sea intuitiva y fácil de utilizar para que los usuarios puedan centrarse en sus trabajos sin tener que dedicar esfuerzos al aprendizaje de nuevas herramientas. – Visualización: el laboratorio virtual debía proporcionar las herramientas necesarias para visualizar tanto los resultados de los trabajos como los datos almacenados. Las especificaciones del sistema, junto con las características típicas de las aplicaciones que se desea ejecutar, hacen de la computación Grid la tecnología más adecuada para el desarrollo del laboratorio virtual y el acceso a través de un portal Grid, la opción más simple y amigable para el usuario final. 3.1.1. Arquitectura general del sistema El diseño de RETELAB se corresponde con una arquitectura cliente-servidor multicapa (véase la Figura 3.1) en la que una aplicación cliente, típicamente un navegador Web, realiza peticiones a un servidor que las procesa y devuelve un resultado. A continuación se describen brevemente las principales capas del sistema: – Capa de aplicaciones: en esta capa se sitúa el servidor Web (Tomcat + Apache) en el que está desplegado el portal Grid a través del cual se accede al sistema. El portal, basado en el contenedor de portlets GridSphere, contiene diferentes portlets que encapsulan y gestionan tareas sobre los recursos de alta computación. – Capa de middleware: en esta capa está desplegada la cuarta versión del Globus Toolkit que contiene la tecnología y herramientas necesarias para gestionar un Grid. GT4 proporciona una colección de servicios que permiten a las aplicaciones (capa superior) operar sobre los recursos de alta computación (capa inferior). – Capa de recursos: en esta capa se sitúan los recursos del sistema. Se trata de recursos distribuidos y heterogéneos que pertenecen a diferentes centros. 3.1. Descripción del proyecto 33 Figura 3.1: Arquitectura general del sistema RETELAB. Recursos del sistema El sistema Grid de RETELAB permite incluir recursos de cualquier centro participante en el proyecto pero en el despliegue inicial sólo se ponen a disposición de la comunidad recursos de la USC y del CESGA. La USC colaboró con un cluster compuesto por 11 nodos, 10 AMD Opteron 2212 y 1 INTEL Xeon 5130, cada uno de los cuales presenta las siguientes características: arquitectura x86_64, 2 procesadores dual core, frecuencia de 2GHz, 4GB RAM e interconexión GigaEthernet. El CESGA aportó un cluster compuesto de 4 nodos HP Proliant de las siguientes características: arquitectura x86_64, 2 procesadores Intel Xeon Quadcore X5355 (8 cores/equipo), frecuencia de 2,66GHz, 8 GB de RAM, 4 x 2MB caché (L2) e interconexión GigaEthernet. Los recursos proporcionados por el CESGA se aprovecharon al máximo gracias a la plataforma de virtualización Xen [6]. Tal y como se muestra en la Figura 3.2, uno de los nodos del cluster fue virtualizado para alojar a 3 recursos virtuales diferentes: – RETELAB UI: aloja la interfaz de acceso al laboratorio virtual, es decir, el portal Grid. 34 Capítulo 3. Proyecto RETELAB – CESGA CE: gestiona los trabajos que le llegan al cluster actuando como nodo principal o «cabeza». – Nodo de trabajo: se ha virtualizado un nodo de trabajo que, si bien no tiene la potencia computacional del resto de los nodos, es aprovechado y utilizado como parte del cluster. Fedora Core 6 + XEN Scientific Linux 4.5 (64 bits) Scientific Linux 4.5 (64 bits) Scientific Linux 4.5 (64 bits) Hardware Xen® Hypervisor CEUI Nodo Trabajo Scientific Linux 4.5 (64 bits) Scientific Linux 4.5 (64 bits) Scientific Linux 4.5 (64 bits) Cluster CESGA Figura 3.2: Recursos aportados por el CESGA. 3.2. Registro y acceso de los usuarios El objetivo de esta sección es mostrar el módulo para el registro y acceso de los usuarios de RETELAB al sistema pero, para una mejor comprensión, es necesario introducir brevemente algunos conceptos sobre la infraestructura de seguridad del GT. 3.2. Registro y acceso de los usuarios 35 Security Grid Infrastructure (GSI) La GSI es un conjunto de herramientas, librerías y protocolos usados por el GT para gestionar el acceso de los usuarios y aplicaciones a los recursos de altas prestaciones [70]. Los pilares fundamentales del GSI son la PKI y los Certificados Digitales (DCs) X.509. Cada participante de un sistema Grid dispone de un DC X.509 que lo identifica y que, principalmente, está compuesto por: – Un nombre que identifica a la persona o recurso al que representa el DC. – La clave pública del propietario del DC. – El nombre de la Autoridad Certificadora (CA) que ha firmado el DC y que garantiza la identidad del propietario. Es esencial que todos los participantes de un Grid confíen y tengan acceso a las claves públicas de las CAs utilizadas para firmar los DCs. – La firma digital de la CA que valida el DC . Es importante diferenciar dos términos en el ámbito de la seguridad Grid: – Autenticar: proceso de identificar unívocamente a un usuario o a un recurso. – Autorizar: proceso que identifica las acciones que puede realizar un usuario sobre un recurso concreto. Autenticación El proceso de autenticación de participantes en un sistema Grid es mutuo, es decir, para establecer una comunicación entre dos participantes es necesario que cada uno de ellos se identifique ante el otro a través del siguiente método: 1. La entidad ‘A’ establece una conexión con la entidad ‘B’ y le envía su DC. 2. La entidad ‘B’ comprueba la autenticidad del DC utilizando la clave pública de la CA con la firma del certificado. 3. Una vez validado el certificado, ‘B’ trata de confirmar que la entidad que envió el DC es realmente su propietaria y para ello envía un mensaje aleatorio para que ‘A’ lo codifique utilizando su clave privada. 4. La entidad ‘A’ utiliza su clave privada para codificar el mensaje y éste es devuelto a ‘B’. 36 Capítulo 3. Proyecto RETELAB 5. ‘B’ utiliza la clave pública de ‘A’, contenida en el DC, para descodificar el mensaje y comprobar que es el mismo que el original. 6. Una vez que ‘A’ es autenticada, ‘B’ iniciaría nuevamente el proceso enviando su DC a ‘A’. Cuando un usuario desarrolla una tarea en un Grid, ésta puede requerir varios recursos o puede que, durante su procesamiento, necesite solicitar servicios en nombre del usuario. Según el método de autenticación mostrado, cada vez que el usuario necesite un recurso o requiera un servicio debería autenticarse. El uso de la clave privada exige la atención del usuario, ya que se almacena cifrada y es necesario que el usuario introduzca su contraseña cada vez que sea necesaria su autenticación. Esto puede resultar tedioso en tareas complejas, sobre todo si se dilatan en el tiempo. Para solucionarlo, GSI introduce el concepto de delegación. Este mecanismo permite al usuario asignar un proxy a la tarea deseada y evita tener que presentar su DC cada vez que la tarea realiza una operación en su nombre. Los proxies son credenciales, con un tiempo de vida muy reducido, generadas por los usuarios a partir sus DCs. La identidad de los proxies es la misma que la de los DCs salvo una pequeña modificación que indica su naturaleza. La creación de un proxy implica la generación tanto de una clave pública como de una privada que se almacenan sin cifrar y a las que se puede acceder sin contraseña evitando la acción del usuario. Autorización Por defecto, GSI proporciona unos sistemas de autorización muy básicos de entre los que cabe destacar el sistema gestionado por el GridMap. Cada recurso posee un fichero denominado GridMap que contiene una lista que relaciona nombres de usuario (identificadores presentes en los DCs) con cuentas de usuario locales. Si el usuario tiene una cuenta local, entonces puede utilizar dicho recurso. Es conveniente disponer de sistemas que ayuden a la creación y gestión de dichas listas y de las cuentas correspondientes. La ventaja es que GSI también proporciona mecanismos para el desarrollo e integración de sistemas de autorización propios y esto será aprovechado para gestionar la autorización de los usuarios de RETELAB. MyProxy MyProxy [86] es un repositorio on-line de certificados cuya finalidad es proporcionar proxies temporales bajo demanda para que puedan ser utilizados en cualquier momento y 3.2. Registro y acceso de los usuarios 37 desde cualquier lugar. MyProxy puede ser utilizado para delegar credenciales a servicios que actúen en lugar del usuario y es el método más habitual para delegar y usar credenciales en los portales Grid. MyProxy puede ser utilizado de dos modos diferentes: – Repositorio de credenciales de usuario: MyProxy actúa como almacén de los DCs y de las claves privadas de los usuarios. Abstrae al usuario del uso y almacenamiento de los certificados y permite generar proxies temporales bajo demanda. Este uso implica que el usuario delega la seguridad de sus DCs en el servidor. – Repositorio de proxies: MyProxy almacena los proxies generados por los usuarios a través de sus DCs y genera nuevos representantes con una vida más corta que los originales. Es necesario que los usuarios generen y alojen nuevos proxies cada vez que los almacenados caduquen. 3.2.1. Autenticación y autorización Uno de los requisitos fundamentales para la construcción del laboratorio virtual (véase la Sección 3.1) era el desarrollo de una interfaz de usuario sencilla y amigable que no demandase grandes conocimientos tecnológicos. La sencillez de un sistema debe empezar desde el registro y acceso de los usuarios pero, a menudo, esto entra en conflicto con los requerimientos de seguridad, por lo que fue necesario encontrar una solución equilibrada. La seguridad en RETELAB está basada en el modulo GSI del GT4, lo que condiciona el acceso al sistema y supone que los usuarios deban disponer de un DC. El proceso para obtener y emplear un DC es, cuanto menos, tedioso para el usuario y puede producir rechazo al uso del sistema, por lo que es necesario adaptarlo para que sea más cómodo. Por otro lado, es importante que el sistema de autorización sea sencillo de administrar pero lo suficientemente potente para responder a las siguientes preguntas: – ¿Quién puede acceder? – ¿Qué recursos puede utilizar? – ¿Qué tareas puede realizar sobre un recurso concreto? Un RBAC [91] parece ser la mejor alternativa. En RBAC los permisos se encuentran asociados a roles y los usuarios son poseedores de uno o más roles, por lo que adquieren los permisos asociados a éstos. Los roles permiten reflejar con mayor veracidad la estructura de una VO y el 44 Capítulo 3. Proyecto RETELAB Para la integración de los DCs y ACs en el procedimiento de SSO se actuó, principalmente, en la clase GridSphereServlet. Esta clase fue previamente modificada en el proyecto MAMS para crear usuarios Shibboleth en el portal GridSphere y, en el caso de RETELAB, se incorporaron los métodos necesarios para la gestión de los DCs y ACs. El código para la creación y almacenamiento del los DCs asociados a los usuarios de Shibboleth se muestra en el Código A.4, mientras que el procedimiento para la creación de los ACs se presenta en el Código A.5. La inclusión de Shibboleth en el sistema de RETELAB permite que los socios del proyecto que deseen integrarse en una Red de confianza puedan autenticarse a través de sus sistemas internos sin necesidad de registrarse en el portal. 3.3. Sistema de almacenamiento distribuido El sistema de almacenamiento de RETELAB [75] [80] fue diseñado para gestionar grandes colecciones de datos provenientes de la teledetección y de los propios proyectos oceanográficos. En RETELAB, el concepto de dato debe entenderse como un fichero binario que representa un producto obtenido a través de un sensor o generado a través de un proceso de análisis de datos previos. Este tipo de productos requiere un considerable espacio en disco, por lo que su almacenamiento masivo es una tarea complicada que no puede ser resuelta utilizando DBs tradicionales. La computación Grid puede afrontar este reto a través de un Data Grid, es decir, un sistema de almacenamiento distribuido entre los diferentes recursos del Grid. RETELAB no pretende ser sólo una herramienta para el almacenamiento y procesamiento, sino que busca ser un medio para compartir conocimiento entre la comunidad oceanográfica; por ello, debe proporcionar procedimientos a los usuarios que, de forma sencilla, permitan publicar y compartir los resultados de sus investigaciones. Estos procedimientos deberían estar basados en el uso de metadatos para describir los productos almacenados y así facilitar los procesos de localización y distribución de los mismos. Los metadatos son datos que describen el contenido de otros datos. Funcionan de forma similar a un índice para localizar objetos. A cada objeto se le asigna una «ficha» que lo describe a través de varios campos y que es utilizada para localizarlo dentro de un almacén. Un ejemplo clarificador sería el de las fichas de los libros en una biblioteca. En RETELAB, cada dato almacenado tiene asociado un conjunto de pares campo-valor que lo describen y que ayudan a realizar búsquedas más concretas a través de las colecciones de datos. Los metadatos 3.3. Sistema de almacenamiento distribuido 45 pueden estar almacenados de forma interna, incrustados dentro del propio dato al que describe (cabecera), o en un almacenamiento externo. Figura 3.7: Arquitectura del Data Grid desplegado en RETELAB. La arquitectura de la solución implementada, que puede verse en la Figura 3.7, está formada por tres capas: la capa inferior, que contiene a los recursos del Grid, almacena las colecciones de datos; la capa intermedia o middleware integra las diferentes tecnologías que forman el núcleo del sistema; y, por último, la capa superior proporciona la interfaz de usuario para acceder al sistema de almacenamiento. Las tecnologías presentes en la capa de middleware son las encargadas de gestionar el almacenamiento de RETELAB. El núcleo del Data Grid lo forma el servicio de GT4 denominado Replica Location Service (RLS). Los elementos almacenados están identificados por un Nombre Lógico de Fichero (LFN) y cada uno de ellos tiene asociado ‘N’ Nombres Físicos de Ficheros (PFNs), es decir, las diferentes rutas donde está almacenado, ya que puede estar replicado. Por lo tanto, el servicio «conoce» la localización específica de cada dato dentro de RETELAB relacionando LFNs con PFNs. El RLS funciona gracias a dos subsistemas, el 46 Capítulo 3. Proyecto RETELAB Local Replica Catalog (LRC), y el Replica Location Index (RLI). Por un lado, cada recurso del Data Grid de RETELAB tiene desplegado un LRC con un listado que relaciona los LFNs con los PFNs almacenados en ese recurso y, por otro lado, RETELAB posee un RLI que, de forma centralizada, relaciona los LFNs con los diferentes LRCs donde están almacenados. Es tarea de cada LRC informar al RLI de las colecciones de datos que gestiona. Para describir correctamente los datos es necesario disponer de un conjunto de metadatos que permita reflejar todas sus características y particularidades. RETELAB ha utilizado el estándar para metadatos geoespaciales ISO 19115 [7]. Este estándar proporciona un conjunto de metadatos orientado a describir datos geoespaciales aportando información sobre la identificación, la extensión, la calidad, el modelo espacial y temporal, la referencia espacial y la distribución de dichos datos. El almacenamiento y gestión de los metadatos se hizo de forma externa al propio dato (la alternativa sería agregarlos en la propia cabecera) y centralizada empleando el Metadata Catalog System (MCS) [100]. El MCS es un servicio del GT4 que proporciona un catálogo de metadatos a través de una interfaz que cumple con el estándar de OGSA. Este catálogo permite describir datos a través de metainformación. OGSA-DAI [17], que proporciona una interfaz OGSA para el acceso a ficheros XML y DBs relacionales, puede integrarse con el MCS para proporcionarle la capacidad de almacenamiento de los metadatos, así como los mecanismos de autenticación propios de un Grid. El sistema de almacenamiento fue integrado en el portal Grid para que el usuario pudiese utilizarlo a través de los diferentes portlets desplegados. El proceso de acceso y recuperación de un archivo almacenado se resume en la Figura 3.8 e incluye los siguientes pasos: 1. El usuario, utilizando metadatos, realiza una consulta a través del portlet correspondiente. 2. El sistema consulta el MCS para obtener los nombres lógicos cuyos metadatos se ajustan a la consulta de usuario. 3. El sistema consulta al RLI para saber qué LRCs gestionan los datos relacionados con los alias obtenidos. 4. El sistema consulta a los LRCs las direcciones físicas vinculadas a los LFN. 3.3. Sistema de almacenamiento distribuido 47 5. A través de la dirección física, el sistema puede mover los datos utilizando, por ejemplo, el servicio GridFTP [13]. El GridFTP, que es parte del GT4, se basa en el protocolo FTP para proporcionar transferencias de datos seguras, robustas, rápidas y eficientes. Figura 3.8: Secuencia resumida de acciones para buscar y acceder a los datos almacenados. Los usuarios no sólo pueden buscar y utilizar las colecciones de datos del sistema, sino que pueden publicar los resultados de sus trabajos asignándoles una lista de metadatos que los describan. Además, cada usuario dispone de un espacio virtual propio donde puede descargar datos para editarlos y, cuando estén listos, subirlos y compartirlos con el resto de la comunidad. La integración del Data Grid con el sistema de envío de trabajos se detalla en la Sección 3.5.1. Detalles de implementación Para facilitar la integración de la DB con los portlets, se desarrolló y empaquetó en un JAR un conjunto de clases que proporcionan las herramientas para la gestión de la DB virtual. Cada portlet que quisiese emplear la DB sólo necesitaba incorporar el JAR entre sus librerías. El paquete es descrito a través del diagrama de clases simplificado de la Figura 3.9. Las clases implementadas interactúan con las clases proporcionadas por el GT4. 48 Capítulo 3. Proyecto RETELAB Figura 3.9: Diagrama de clases simplificado en el que se presentan las clases utilizadas para desarrollar las operaciones sobre la DB virtual. El desarrollo de las clases para la gestión de la DB tuvo varias dificultades y, entre ellas, es interesante destacar dos [80]: – Integración de OGSA-DAI y el MCS: GT proporciona librerías para gestionar el MCS; concretamente, la clase DaiMCSClient es una implementación de un cliente para conectarse al MCS sobre OGSA-DAI. Esta clase hace uso de otra llamada GenericServiceFetcher que se encarga de instanciar clases que implementan interfaces para comunicarse con los diferentes servicios de datos. GenericServiceFetcher se conecta con un servicio a través de una URL y recupera el WSDL que lo describe. El análisis del WSDL le permite determinar la distribución de OGSA-DAI empleada para implementarlo y así instanciar la interfaz adecuada. El código utilizado para recuperar el WSDL intenta realizar una conexión a una URL pero sin especificar la clase responsable para gestionar dicha conexión. Si la clase responsable no está definida de forma explícita, se asigna una en tiempo de ejecución que depende del protocolo usado para la conexión. Cuando GenericServiceFetcher forma parte de un software de escritorio funciona correctamente 3.3. Sistema de almacenamiento distribuido 49 pero en un entorno J2EE, debido a la forma de cargar las clases en memoria que usa el Tomcat, no encuentra la clase responsable adecuada. Fue necesario modificar y hacer explícito la clase que debía cargar en la conexión modificando la clase GenericServiceFetcher (véase el Código A.6). – Gestión de proxies: cuando un usuario se autentica en el portal, el sistema obtiene automáticamente un proxy de su DC del repositorio MyProxy. El GT proporciona librerías para gestionar dicho proxy y definirlo como el DC por defecto para que sea empleado en las autenticaciones. El problema surge con el servicio RLS que necesita que el DC esté almacenado físicamente en un directorio local. Para solucionarlo se desarrolló un procedimiento de conexión/validación con la DB que fijaba el DC por defecto para que fuese utilizado por los servicios que lo requiriesen y, además, fuera almacenado local y temporalmente para que el RLS pudiese usarlo en la autenticación. El procedimiento empleado se detalla en el Código A.7. 3.3.1. Almacenamiento de datos Se han desarrollado diferentes procedimientos para introducir datos en el sistema de almacenamiento de RETELAB que cubren las diferentes necesidades de sus usuarios. Almacenamiento de datos locales Se ha habilitado un sistema de transferencia y almacenamiento de datos locales (véase la Figura 3.10) que permite a los usuarios compartir datos con la comunidad. Para transferir los datos, el usuario debe seleccionar el producto de su computadora que desea compartir, asignarle un LFN y describirlo a través de metadatos escogidos a través de una lista confeccionada a partir del estándar ISO 19115. Almacenamiento de datos vía FTP En el campo de la observación de la Tierra, es habitual que los usuarios utilicen datos almacenados en servidores FTP externos para sus proyectos. Se ha implementado un portlet (véase la Figura 3.11) que permite el acceso a dichos servidores para copiar y transferir datos a RETELAB. El usuario debe introducir sus datos de acceso, navegar a través del árbol de directorios del servidor FTP, seleccionar los elementos que quiere añadir y describirlos a través de metadatos. Si los datos están comprimidos puede establecerse el tipo de compresión para que éstos sean desempaquetados automáticamente antes de almacenarse. 50 Capítulo 3. Proyecto RETELAB Figura 3.10: Portlet para el almacenamiento de datos locales en RETELAB. Almacenamiento de datos generados en RETELAB Los datos generados tras la ejecución de una tarea en RETELAB pueden compartirse con el resto de la comunidad a través del sistema de almacenamiento (véase la Figura 3.12). El usuario puede visualizar los datos de salida y seleccionar los que desee añadir al Data Grid y, al igual que en el resto de los casos, podrá ir añadiendo los metadatos que considere necesarios para describir cada elemento. Inicialización del Data Grid La introducción de nuevos elementos en el sistema de almacenamiento se hace, por defecto, de uno en uno a través de un portlet dedicado pero esto no es asumible en el momento de desplegar el sistema, ya que es necesario dar de alta grandes colecciones de datos. Se desarrolló un sistema de registro automático de datos a través de ficheros XML que indicaban rutas, alias y metadatos para cada elemento. Este procedimiento es de uso exclusivo del administrador y permite dar de alta automáticamente grandes volúmenes de datos. Con el doble propósito de probar el proceso para la inicialización del Data Grid y el de proporcionar suficientes recursos para poder ejecutar los proyectos que validarían el laboratorio (véase la Sección 3.6), se dieron de alta varias colecciones de datos: – Una colección de imágenes SAR correspondientes, por un lado, al Golfo de México y, por otro, a la costa noroeste de la Península Ibérica, así como los datos de viento 3.3. Sistema de almacenamiento distribuido 51 Figura 3.11: Portlet para la integración de datos externos en el sistema. asociados a éstas en formato Network Common Data Form (NetCDF). Estos productos fueron empleados para desarrollar y validar el proyecto de SENTINAZOS (véase la Sección 3.6.3). – Una colección de datos en NetCDF empleada para desarrollar la aplicación para el cálculo de la PP (véase la Sección 3.6.3) que incluía: •Datos de temperatura superficial del mar provenientes de los sensores AVHRR y MODIS. •Datos sobre la concentración de clorofila provenientes de los sensores MODIS y SeaWIFS. •Datos sobre la radiación solar disponible para el cálculo de la fotosíntesis estimados por la NASA. Cada producto almacenado fue etiquetado con un conjunto de metadatos para describirlo y así facilitar su posterior identificación y búsqueda. El formato NetCDF [93] ha sido ampliamente utilizado en RETELAB debido a su popularidad dentro de la comunidad científica. Es utilizado regularmente en aplicaciones relacio- 52 Capítulo 3. Proyecto RETELAB Figura 3.12: Resultados de la ejecución de un trabajo en el Grid. El usuario puede visualizarlos y revisarlos y/o añadirlos al Data Grid previa descripción usando metadatos. nadas con la climatología, meteorología o la oceanografía para el intercambio de datos, es decir, como formato de entrada/salida. 3.4. Visualización de los datos Se han integrado dos tipos de visores en RETELAB para la visualización de los datos, bien para validar las búsquedas, bien para el análisis de los resultados tras ser procesados. 3.4.1. Live Access Server Un Live Access Server (LAS) [101] es un servidor con la capacidad de conectarse a servidores externos OPeNDAP [32] para el acceso e intercambio de datos. Está diseñado para proporcionar acceso a datos científicos georreferenciados y trabajar con información proveniente de distintos servidores como si fuese una única DB. Un LAS permite generar gráficos de forma dinámica, solicitar fragmentos de datos en una variedad de formatos, comparar variables almacenadas en DBs diferentes y generar estadísticas básicas. La herramienta de visualización por defecto es Ferret, software de código abierto especialmente dirigido a trabajar con datos georreferenciados y que permite crear datos cien- 3.4. Visualización de los datos 53 tíficos y proporciona una poderosa herramienta de análisis. Una de las grandes ventajas de un LAS es que cualquier usuario puede acceder a través de un simple navegador. Se desplegó un LAS en RETELAB y se integró dentro del portal a través de un portlet con un Iframe, elemento HTML que permite empotrar un documento HTML dentro de otro; en este caso, se utilizó para incrustar la interfaz Web del LAS como puede verse en la Figura 3.13. Figura 3.13: Integración del Live Access Server en RETELAB. 3.4.2. Integrated Data Viewer El Integrated Data Viewer (IDV) [84], desarrollado por Unidata, es una herramienta software implementada en Java que permite visualizar y analizar datos geocientíficos. Para integrar IDV en el sistema se desarrolló un procedimiento que, por cada elemento recuperado tras una consulta a la DB o por cada resultado producido por la ejecución de un trabajo, genera dinámicamente un enlace a un fichero Java Networking Launching Protocol (JNLP). La descarga, por medio del enlace, de este fichero inicia, previa confirmación del usuario, la instalación temporal del software IDV. La instalación se realiza de forma automática y transparente gracias a JavaWS y, una vez finalizada, IDV es cargado con los datos asociados al enlace. El único requisito para su utilización es disponer del Entorno de Ejecución de Java (JRE) que incluye al propio JavaWS. 60 Capítulo 3. Proyecto RETELAB 3.6.2. Cálculo del modelo de producción primaria RETELAB debía poder integrar aplicaciones realizadas por los propios centros asociados al proyecto, por lo que se adaptó, a través de un portlet, un modelo realizado por el ICCM para el cálculo de la Producción Primaria (PP) oceánica. La PP puede definirse como la generación de componentes orgánicos a partir del CO2que realizan los organismos autótrofos a través de los procesos de fotosíntesis o quimiosíntesis. Es un mecanismo clave que permite a los océanos, a través del fitoplancton, ser los pulmones del planeta, ya que gracias a la PP se genera cerca del 50% de la producción global de oxígeno y se captura alrededor de la mitad delCO2mundial. El cálculo de este parámetro es fundamental para comprender el papel que juega el ciclo del carbono en el sistema climático mundial. Los llamados modelos bioópticos son los métodos más utilizados para el cálculo a gran escala de la PP. Estos modelos se basan en información obtenida a través de satélites que incluye, entre otros datos, información sobre las biomasas de fitoplancton y de la luminosidad oceánica. En concreto, el modelo implementado para RETELAB es una adaptación del Vertically Generalised Production Model (VGPM) desarrollado por Berhefeld y Falkowsky [20]. El portlet implementado permite definir los parámetros de entrada al modelo y ejecutarlo en el sistema Grid. Los parámetros esperados para un correcto funcionamiento son: la temperatura superficial oceánica, la concentración de clorofila y los datos sobre la radiación disponible para fotosíntesis. La Figura 3.20 muestra una composición que ilustra la visualización de resultados del cálculo de PP una vez lanzada la tarea en el sistema Grid. 3.6.3. SENTINAZOS Después de haber integrado y adaptado aplicaciones desarrolladas por terceros, se afrontó el reto de implementar una desde cero que aprovechase el sistema y, además, fuese útil para la comunidad en un problema de difícil solución como es la detección semiautomática de contaminantes marinos basados en hidrocarburos. La contaminación marina es un problema que habitualmente afecta a nuestras costas y que, a menudo, se relaciona con grandes catástrofes de petroleros. Sin embargo, en un mayor porcentaje, es originada por pequeños derrames que, bien sea de forma fortuita debido a pequeños accidentes o bien sea de forma premeditada a causa de tareas de mantenimiento, se producen diariamente. Los centros de vigilancia marítima invierten una gran cantidad de recursos en la vigilancia y persecución de estos actos pero cubrir toda la superficie costera es una tarea inabarcable. Los satélites aportan la cober- 3.6. Validación del laboratorio virtual 61 Figura 3.20: Composición de la monitorización de un trabajo y su integración con el Data Grid y el sistema de visualización de IDV. tura necesaria para el estudio y monitorización de grandes áreas y, concretamente, estudios previos [25] [110] demostraron la viabilidad del uso de las imágenes SAR de satélites en la detección de este tipo de contaminantes. El objetivo es desarrollar una aplicación que permita el análisis de imágenes de SAR para detectar hidrocarburos e integrarla en RETELAB, ya que esto proporcionaría ciertas ventajas como: – Distribuir el almacenamiento de las imágenes SAR. – Compartir las colecciones de imágenes que cada centro disponga con el resto de participantes del proyecto. – Optimizar los algoritmos, ya que tienen una gran carga computacional que, en gran medida, está asociada a los bucles que las analizan y que son candidatos a ser paralelizados. – Ejecutar diferentes instancias de la aplicación al mismo tiempo aprovechando los diferentes recursos del sistema y así analizar simultáneamente diferentes áreas de la costa. 62 Capítulo 3. Proyecto RETELAB Aunque la bibliografía muestra que existen algoritmos similares para la detección de vertidos, éstos suelen presentar uno o varios de los siguientes problemas: – Requieren la presencia activa de un operador. – El coste computacional es demasiado alto para su uso en tiempo real. – Las implementaciones se basan en librerías comerciales con licencias privativas. – No tienen en cuenta los efectos de los fenómenos meteorológicos, principalmente el viento, en la detección de los vertidos. Debido a la complejidad de los algoritmos desarrollados, la segunda parte de la tesis está dedicada a describirlos en detalle y resaltar el carácter innovador de los mismos. Parte II Validación del Laboratorio Virtual: avances en la detección automática de vertidos de hidrocarburos CAPÍTULO 4 ESTADO DEL ARTE Introducción Aunque existen muchos tipos de contaminantes, los vertidos de hidrocarburos son, probablemente, los que más afectan al ecosistema marino. A pesar de lo que popularmente es aceptado, las grandes catástrofes provocadas por los petroleros suponen una pequeña parte de dicha contaminación. Un estudio de la Agencia Espacial Europea (ESA) [39] reveló que tan sólo un 7% de los vertidos pueden ser atribuidos a accidentes, mientras que un 45% corresponden a derrames que habitualmente se realizan durante operaciones de mantenimiento (por ejemplo la limpieza de las sentinas) y que denominaremos sentinazos, un 13% proviene de fuentes naturales y el 35% restante corresponde a vertidos realizados directamente en los ríos. Los vertidos afectan a la economía (turismo, pesca, etc.) y al ecosistema de las regiones damnificadas, por lo que son necesarios sistemas y herramientas para su localización. Una rápida identificación permitiría minimizar su impacto e incluso identificar a sus causantes. Los sensores que operan en el rango de las microondas, comúnmente llamados radares, han demostrado ser de gran utilidad en la detección de vertidos de hidrocarburos. Radar El radar es un sistema de detección activo [31] cuyo funcionamiento básicamente consiste en el envío de un pulso de energía en el rango de las microondas hacia la superficie terrestre. Este haz es reflejado y retrodispersado por la superficie y parte de la energía es recogida nuevamente por la antena del radar. La intensidad de la señal que vuelve a la antena es medida y grabada para posteriormente ser utilizada en la construcción de una imagen de la 66 Capítulo 4. Estado del arte 45% 7% 13% 35% Sentinazos Accidentes Emanaciones naturales Ríos Figura 4.1: Orígenes de los vertidos de hidrocarburos. Imagen adaptada de [39] zona estudiada. Cada píxel de la imagen está asociado a un área sobre el terreno y almacena un valor que representa la cantidad de energía que regresa al sensor debido a la retrodispersión. Tradicionalmente los buques y los aviones han sido los medios de vigilancia más utilizados en la lucha contra la contaminación oceánica. Por un lado, los buques equipados con sistemas de radar son útiles para detectar contaminantes en sus proximidades y obtener muestras de los vertidos pero su restringida cobertura limita su eficacia; por otro lado, los aviones de vigilancia que utilizan sistemas de Radar Lateral Aerotransportado (SLAR) permiten vigilar áreas más extensas pero su coste hace que sea poco viable emplearlos para monitorizar superficies de gran tamaño de forma intensiva y simultánea. En resumidas cuentas, tanto los buques como los aviones son adecuados como medios de primera intervención pero sería deseable un sistema más económico con mayor cobertura. El uso de sistemas de radar instalados a bordo de satélites permite abarcar áreas mucho más extensas y a un coste razonable pero su resolución espacial no es adecuada para la búsqueda de pequeños derrames de hidrocarburos. La resolución es la habilidad para distinguir dos objetos separados por la mínima distancia posible. Si la distancia entre los objetos es suficiente, cada uno de ellos estará localizado en una celda de la imagen diferente y serán distinguibles; en caso contrario, el radar devolverá una combinación de la energía reflejada por los dos objetos como si fuese uno sólo [74]. Tanto el radar aerotransportado como el espacial observan la superficie lateralmente (véase la Figura 4.2) y su resolución espacial es diferente 67 en la dirección paralela a la trayectoria del satélite, también denominada resolución en acimut, y en la perpendicular, es decir, en la dirección al objetivo. En la perpendicular a la trayectoria del satélite, el sistema puede discriminar dos objetos si la distancia entre ellos es mayor que la mitad de la anchura del pulso (pulse width) enviado. La resolución perpendicular se calcula a través de la siguiente fórmula: Rp=c·τ 2=c 2·β(4.1) , siendo cla velocidad de la luz y τla anchura del pulso. También puede expresarse a través el ancho de banda del pulso (pulse bandwidth) representado por β. Normalmente, los radares a bordo de satélites trabajan en anchos de banda que van desde los 10 a los 40 MHz. Este rango generaría resoluciones que van desde los 15 a los 3,7 metros, que son suficientemente buenas para la detección de vertidos. El problema principal está asociado a la resolución en acimut, es decir, en la trayectoria del satélite, que se calcula como: Rac =λ·d LA (4.2) , siendo λla longitud de onda, dla distancia del sensor al objetivo y LAla longitud de la antena. d A A' B' B Rac R'ac 800 km d'=1.131 km 15° 45° Trayectoria del satélite Perpendicular a la trayectoria Figura 4.2: Resolución espacial de un radar a bordo de un satélite. 68 Capítulo 4. Estado del arte Dado que la longitud de onda está situada dentro de un rango determinado de microondas y que no puede haber grandes variaciones de la altura a la que orbita el satélite, la resolución en acimut queda directamente determinada por la longitud de la antena. Obtener una óptima resolución utilizando sistemas de radar sobre plataformas espaciales implicaría el uso de antenas de enormes proporciones, lo que sería impracticable. Empleando los datos de ejemplo de la Figura 4.2, un radar que operase en la Banda C con una longitud de onda de 5 cm y que viajase a bordo de un satélite que orbitase a 800 km de altura, necesitaría una antena de casi 2 km para conseguir una resolución de 30 m cuando el Ángulo de Incidencia (IA) fuese de 45◦. LA=0,05·1131·103 30 =1.885m(4.3) Para solucionar este hándicap, surge un tipo especial de radar llamado SAR que permite obtener resoluciones de pocos metros con antenas de pequeñas dimensiones. Por ejemplo, la resolución del Envisat alcanzaba los 30 m empleando una antena rectangular de 1,3 m x 10 m. SAR Los principios básicos del funcionamiento del SAR solucionan la limitación de resolución del radar. El SAR, montado sobre una plataforma móvil, analiza y recoge diferentes medidas de un mismo punto durante su trayecto (Figura 4.3). Esto permite simular una antena de las mismas proporciones que la distancia entre la primera y la última medición llegando a conseguir resoluciones de tan sólo unos pocos metros. Línea de tierra Traza Antena virtual Primera medición Última medición Figura 4.3: Antena virtual generada por SAR. Las imágenes SAR son complejas y difíciles de interpretar y esto es debido a múltiples factores (la superficie es estudiada lateralmente, el ángulo de emisión e incidencia del haz de 69 energía varía, la señal de retorno se ve afectada por la distancia entre la antena y la superficie estudiada, etc.). La Figura 4.4 muestra un ejemplo de una imagen SAR en la que se aprecia cómo la intensidad no es homogénea. Las zonas más cercanas al satélite y con menor IA dan lugar a niveles de intensidad más altos (representados de forma más clara), mientras que las zonas más alejadas y con ángulos mayores son representadas de forma más oscura debido a los bajos niveles de intensidad. Figura 4.4: Imagen SAR de la costa gallega obtenida por el satélite Envisat (04/05/2007). Además de la amplia cobertura y buena resolución que puede conseguirse con el SAR, es necesario destacar que, al ser un sensor activo, su funcionamiento no depende de la radiación solar y puede utilizarse durante el día y la noche. Además, el sensor es independiente de la cobertura nubosa, ya que su haz de energía en el rango de las microondas le permite atravesarla sin sufrir alteraciones. Un estudio en mayor profundidad de SAR y de sus aplicaciones puede encontrarse en [66]. Imágenes SAR de la superficie oceánica La superficie del mar, en condiciones moderadas de viento, presenta cierta rugosidad generada por las ondas capilares. Esta rugosidad provoca una retrodispersión uniforme del haz de energía enviado por el SAR. Los vertidos de hidrocarburos, así como determinados fe- 76 Capítulo 4. Estado del arte El 99,4% de los look-alikes fueron clasificados correctamente, mientras que la eficacia en la detección de los sentinazos alcanzó el 78,4%. •Brekke y Solberg [26] se basaron en el modelo anterior para desarrollar un sistema de detección de sentinazos en dos pasos. En el primer paso emplearon un clasificador estadístico normalizado con el objetivo de detectar todos los sentinazos y, en un segundo paso, aplicaron un estimador de confianza que asignaba una probabilidad a cada sentinazo. Su DB se componía de 104 imágenes Envisat Wide Swath Mode (WSM) divididas en tres subconjuntos: entrenamiento (56 imágenes), validación (20 imágenes) y test (27 imágenes). La eficacia del clasificador fue del 92,7% sobre los sentinazos y del 89,7% con los look-alikes. – Fiscella et ál. [41] realizaron una comparativa entre un clasificador de probabilidad compuesta y uno basado en la distancia de Mahalanobis. El conjunto de datos de entrenamiento estaba compuesto por 80 sentinazos y 43 look-alikes, mientras que el de test, que estaba analizado por un operador, tenía 11 sentinazos, 6 look-alikes y 4 indefinidos. El 81,8% de los sentinazos y el 100% de los look-alikes fueron correctamente clasificados usando la distancia de Mahalanobis, mientras que el clasificador de probabilidad compuesto identificó el 90,9% de los sentinazos y el 67% de los look-alikes. La eficacia de los diferentes métodos de clasificación es totalmente dependiente de las fases previas y por tanto, es difícil compararlos. Es necesario segmentar el candidato para poder clasificarlo, siendo clave para su correcta clasificación las características seleccionadas y su poder discriminatorio. Es importante también destacar que las eficacias de algunos clasificadores viene dada a nivel de píxel [54] y las de otros a nivel de candidato [103]. En general, la eficacia a nivel de píxel suele ser más elevada dado que se evalúa una muestra mayor y los errores de clasificación, si son pocos, quedan más diluidos. CAPÍTULO 5 SISTEMA AUTOMÁTICO DE DETECCIÓN DE VERTIDOS EN IMÁGENES DE SAR 5.1. Descripción del proyecto Galicia es una región en el noroeste de España con más de 1.200 km de costa y aproximadamente 720 playas donde el mar ha jugado siempre un papel muy importante en la vida de sus habitantes. La pesca y la agricultura han sido pilares fundamentales de su economía y, actualmente, el sector turístico juega también un papel esencial. Sus costas, playas y las bondades de su gastronomía, particularmente la relacionada con el producto de mar (pescados y mariscos), son en buena parte culpables del incremento turístico. Además, se encuentran en esta región importantes astilleros y puertos tanto civiles como militares. La situación geográfica de Galicia convierte a sus costas en un paso obligado para buena parte del tráfico marítimo europeo. El Esquema de Separación de Tráfico de Fisterra (ESTF), mostrado en la Figura 5.1, es utilizado para dirigir y controlar este tránsito. Las vías de circulación están, empezando por la más próxima a la costa, a 21,7 millas náuticas (40 km), 28,3 millas náuticas (52,4 km), 35,5 millas náuticas (65,7 km) y 39,5 millas náuticas (73 km) de Cabo Fisterra. Las vías C y D del ESTF son usadas para navegar de norte a sur, mientras que la A y B se utilizan en sentido contrario. Las vías B y D están reservadas para embarcaciones con mercancías peligrosas. Cada año miles de buques de mercancías navegan a lo largo del ESTF y, debido a la normativa internacional, todos los barcos tienen que informar de su posición al servicio de 78 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR 7°W8°W9°W10°W 44°N 43°N 42°N 0 30 60 90 12015 Millas náuticas 130º 75º Cabo Vilán Cabo Fisterra Tráfico costero DCBA Figura 5.1: Esquema de Separación de Tráfico de Fisterra. Tráfico Marítimo de Fisterra, al cruzar las líneas de demora 130◦a Cabo Vilán y 75◦a Cabo Fisterra. La Tabla 5.1 muestra el número de informes recibidos entre los años 1999 y 2009. Año 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 Buques 41.829 44.561 44.331 43.209 43.469 42.538 43.212 41.942 42.136 42.354 40.320 Tabla 5.1: Número de embarcaciones identificadas en el ESTF. Este intenso tráfico tiene graves consecuencias medioambientales en forma de accidentes y vertidos como, por ejemplo, el del petrolero Urquiola en 1976 o el del Mar Egeo en 1992. Sin embargo, la catástrofe más importante y con mayor repercusión ha sido la del buque petrolero Prestige que, el 13 de Noviembre del año 2002, sufrió un accidente frente a la costa gallega para acabar hundiéndose al cabo de seis días. En la Figura 5.2 se observa la extensión del vertido 5 días después de la catástrofe. La amplia cobertura científica del accidente permitió obtener multitud de datos y de información, lo que unido a un incremento de los recursos económicos tuvo como consecuencia el desarrollo de varios proyectos para la detección y seguimiento de grandes vertidos [90] [18] [34]. A pesar de que los medios de vigilancia y prevención se incrementaron después de la catástrofe, se descubren regularmente pequeños vertidos (sentinazos) provenientes de las operaciones de mantenimiento y limpieza de sentinas. Es conveniente recordar que los pequeños 5.1. Descripción del proyecto 79 vertidos, a pesar de no ser tan mediáticos, son la fuente de contaminación por hidrocarburos más importante (véase la Figura 4.1). 8°30'W9°W9°30'W10°W10°30'W 44°N 43°30'N 43°N 42°30'N 42°N 0 10 20 30 405 Millas náuticas Figura 5.2: Imagen SAR del vertido provocado por el accidente del buque petrolero Prestige (17/11/2002). La Agencia española de Salvamento y Seguridad Marítima (SASEMAR) es la autoridad pública encargada de monitorizar las costas gallegas en general y el ESTF en particular. SASEMAR, como se observa en la Figura 5.3, cuenta con varias bases de vigilancia en Galicia y con recursos, tanto marinos como aéreos, para efectuar la monitorización y la vigilancia. El uso de buques y aviones es costoso y limitado, por lo que el acuerdo suscrito con la Agencia Europea de Seguridad Marítima (EMSA) para recibir hasta un máximo 12 avisos al mes provenientes de la inspección de imágenes SAR sobre posibles vertidos es especialmente útil. Estos avisos son evaluados por el personal de SASEMAR y, cuando se considera apropiado, envían sus propios recursos a la zona. En general, una nación costera como es España y en particular Galicia con su intenso tráfico marítimo y su trágico historial de catástrofes medioambientales, debería poseer su propio sistema de análisis de imágenes SAR sin depender de sistemas de terceros. Con este ánimo, se desarrolló un sistema semiautomático de detección de vertidos de hidrocarburos a partir de imágenes SAR que, aunque resulta fácilmente adaptable a otras regiones, fue optimizado para su uso en las costas gallegas [79]. Se prestó especial atención a su implementación con el objetivo de dar una respuesta en tiempo cuasi real sin sacrificar la eficiencia. Las diferentes herramientas, software o librerías utilizadas para el desarrollo del prototipo están soportadas por licencias públicas, lo que permite la libre distribución del producto final. Los siguientes 80 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR A Coruña Porto do Son Vigo Recursos de SASEMAR en Galicia 1 avión de vigilancia CESSNA 337-G 1 avión de vigilancia CN235-300 1 helicóptero S61N - Sikorsky 1 helicóptero AW139 3 buques polivalentes Figura 5.3: Bases de la SASEMAR en Galicia y recursos asignados a la región. apartados detallan el desarrollo del algoritmo utilizado y su incorporación a un prototipo. La Sección 5.2 presenta la DB de imágenes usada para el desarrollo y las fuentes de datos utilizadas. Las particularidades del algoritmo se describen en las Secciones 5.3, 5.4, 5.5 y 5.6. Por último, la Sección 5.7 se centra en la descripción del prototipo implementado y en su integración en RETELAB. 5.2. Fuentes de datos 5.2.1. Satélite Envisat En Marzo del 2002 la ESA puso en órbita el satélite de observación terrestre Envisat [1]. Su objetivo principal era dotar a Europa de una mayor capacidad para la observación de la Tierra desde el espacio y dar continuidad a las misiones predecesoras de los satélites ERS1 y ERS-2. La instrumentación del Envisat estaba diseñada para realizar observaciones y mediciones del océano, la tierra, el hielo y la atmósfera. Estuvo operativo hasta el 8 de Abril del 2012, día en que se perdió el contacto. El 9 de Mayo del 2012, la ESA dio por finalizada oficialmente la misión. Algunos de los parámetros orbitales del satélite pueden consultarse en la Tabla 5.2. La continuidad de las misiones europeas para la observación de la Tierra está garantizada con la serie de satélites Sentinel que está siendo desarrollada por la ESA dentro del programa 5.2. Fuentes de datos 81 de Monitorización Global para el Medioambiente y la Seguridad (GMES). Se espera que el primer satélite Sentinel sea lanzado durante el año 2013. Órbitas por día 14,3 Periodo repetición de ciclo 35 días Órbitas por ciclo 501 Período orbital 100,59 min. Velocidad de la órbita 7,45 km/s Inclinación orbital 98,55◦ Altitud media 799,8 km Tabla 5.2: Parámetros orbitales del satélite Envisat. A bordo del Envisat viajaban 10 instrumentos dedicados a la observación de la Tierra: – El instrumento de Orbitografía y Radioposicionamiento Doppler Integrado por Satélite (DORIS) ofrecía datos sobre la órbita del satélite con gran precisión. Esta información era utilizada para determinar la posición exacta del satélite. – El Espectrómetro de Imágenes de Resolución Media (MERIS) medía la reflectancia de la Tierra en el rango del espectro solar, analizando el color de los océanos y la cobertura del terreno. Los mapas de alta resolución generados con sus datos son utilizados para evaluar los efectos del cambio climático. – El Radiómetro Avanzado de Exploración Longitudinal (AATSR) permitía medir la temperatura de la superficie de la Tierra y de los océanos a partir de la radiación térmica infrarroja que emite nuestro planeta. – El Altímetro de Radar (RA-2) era capaz de registrar la topografía de la superficie terrestre con una precisión de unos pocos centímetros, lo que hacía posible analizar, por ejemplo, la evolución temporal del nivel del mar. – El objetivo principal del Radiómetro de Microondas (MWR) era el de realizar mediciones del vapor de agua de la atmósfera y del contenido de agua líquida de las nubes. – El instrumento para Monitorización Global del Ozono mediante la Ocultación de Estrellas (GOMOS) proporcionaba una cartografía global del ozono en altitud y un seguimiento de tendencia de gran precisión. 82 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR – El Interferómetro de Michelson para Ecografía Atmosférica Pasiva (MIPAS) era un espectrómetro independiente de la luz solar que servía para realizar mediciones de alta resolución del espectro de emisiones gaseosas en la atmósfera terrestre. – La misión principal del Espectrómetro de Absorción de Exploración e Imágenes para Cartografía Atmosférica (SCIAMACHY) era registrar el espectro de rayos solares que pasan a través de la atmósfera. Se utilizaba para encontrar huellas de absorción espectral producidas por determinados gases y, entre otras utilidades, permitía realizar mapas globales de polución atmosférica. – El Retrorreflector Láser (LRR) era un sensor pasivo utilizado como reflector de pulsos láser de alta potencia enviados desde estaciones en tierra y que proporcionaba la distancia entre el satélite y la estación. – El Radar de Apertura Sintética Avanzado (ASAR) era un novedoso instrumento SAR del que se obtuvieron los datos utilizados para el desarrollo de SENTINAZOS. La siguiente Sección profundiza su descripción. La mayoría de los instrumentos presentados, excepto el MWR y el RA-2, tenían cobertura global y necesitaban entre 1 y 3 días para completarla. Radar de Apertura Sintética Avanzado El ASAR es un sensor activo que opera en el rango de las microondas, concretamente en la banda C con una frecuencia de 5,331 GHz. En la figura 5.4 se muestra el espectro electromagnético, ofreciendo mayor detalle en el rango de las microondas. Las características particulares del sensor, además de su independencia de la luz solar y de la cobertura nubosa, lo hacen especialmente eficiente en el estudio de temas tan diversos como: frentes oceánicos, oleaje marino, detección de barcos y contaminantes, movimiento y extensión de hielos, agricultura, estudios urbanísticos, desastres naturales, etc. Dependiendo del área de estudio, se trabajará en uno de los 5 modos de operación soportados por el sensor y que son descritos en la Tabla 5.3. Envisat Wide Swath Mode El Envisat Wide Swath Mode (WSM) es el modo de operación que mejor se adapta a la búsqueda de vertidos de hidrocarburos. Por un lado, gracias a la técnica ScanSAR, ofrece una 5.2. Fuentes de datos 83 Banda Frecuencia (GHz) Long. onda (cm) Infrarojo Medio Microondas Radar Radio Bandas Audio AC UV Gamma Rayos X PLSCXKQVW 0,39 1,55 0,3 1,0 3,0 10,0 30,0 100,0 5646 36 10,9 5,75 3,9 100 30 10 310,3 Visible 10 10 10 10 10 10 10 10 10 10 1 20 18 16 14 12 10 864 2 ⟶ ⟵ Longitud de onda Frecuencia, Hz 0,0.3 Å 0,3 Å 3 Å 30 Å 300 Å 0,3 μm 3 μm 30 μm 300μm 0,3 cm 3 cm 30 cm 3 m 30 m 300 m 3 km 30 km 300 km Longitud de onda (λ) 0,4 μm 0,7 μm Figura 5.4: Espectro electromagnético. Figura adaptada de la web de la ESA [1]. Modo Trazas Polarización Resolución (m) Cobertura aproximada (km) IA (grados sexagesimales) Ruido de fondo (dB) Image Mode (IM) IS1, IS2, IS3, IS4, IS5, IS6 o IS7 VV o HH 30 56 (traza 7) - 100 (traza 1) 15◦−45◦-19 a -22 Alternating Polarisation (AP) IS1, IS2, IS3, IS4, IS5, IS6 o IS7 HH/VV, HH/HV, VV/VH 30 56 (traza 7) - 100 (traza 1) 15◦−45◦-19 a -22 Wide Swath (WS) SS1 + SS2 + SS3 + SS4 + SS5 VV o HH 150 400 17◦−42◦-21 a -26 Global Monitoring (GM) SS1 + SS2 + SS3 + SS4 + SS5 VV o HH 1.000 400 17◦−42◦-32 a -35 Wave (WV) IS1, IS2, IS3, IS4, IS5, IS6 o IS7 VV o HH 30 5 15◦−45◦-20 a -22 Tabla 5.3: Modos de operación del sensor ASAR a bordo del Envisat. amplia cobertura de 405 km y una resolución media de 150 m. Por otro lado, la relación entre el ruido de fondo y la retrodispersión es adecuada para la búsqueda de sentinazos en casi todas las condiciones cuando se utiliza la polarización vertical-vertical. Polarización Los radares pueden transmitir el haz energético con polarización horizontal (H) o con polarización vertical (V) y recibir la señal retornada nuevamente con polarización horizontal, vertical o ambas. Esto es interesante debido a que los diferentes materiales 84 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR de los que está compuesta la cubierta terrestre reflejan las señales con intensidades diferentes dependiendo de la polarización e incluso algunos materiales convierten una polarización en otra. Dependiendo del objetivo de la investigación, es más adecuado un tipo u otro de polarización. Los productos de Envisat WSM pueden trabajar con dos tipos de polarización, la vertical-vertical (VV) y la horizontal-horizontal (HH). Ruido de fondo Los sistemas para la adquisición de datos y procesamiento de señales están afectados por diferentes tipos de ruido y de señales no deseadas. La suma de todo esto es lo que se define como ruido de fondo o noise floor. La intensidad de este ruido sitúa el umbral o medida mínima que puede ser tomada e identificada con certeza, es decir, no se puede identificar nada cuya intensidad de señal sea inferior al ruido de fondo, ya que queda enmascarado por dicho ruido. La retrodispersión del océano varía dependiendo del IA, la polarización y la velocidad y dirección del viento. Los productos WSM de Envisat con polarización VV poseen un ruido de fondo, entre -21 dB y -26 dB, que se encuentra por debajo de la media de retrodispersión del océano en casi todas las condiciones. Esta característica permite buscar la presencia de hidrocarburos, ya que éstos se asocian a valores de retrodispersión inferiores a los generados por las áreas del mar sin presencia de contaminantes. La Figura 5.5 muestra la retrodispersión del océano obtenida de una imagen SAR que no tenía presencia de hidrocarburos. Se puede observar que la retrodispersión varía según el IA y la velocidad del viento. Ángulo de incidencia (grados) Retrodispersión (dB) Vientos 10 m/s Vientos 6 m/s Vientos 4 m/s 15 20 25 30 35 40 45 5 0 -5 -10 -15 -20 -25 Figura 5.5: Retrodispersión media obtenida de una imagen ASAR WSM para vientos de 4 m/s, 6 m/s y 10 m/s. 5.2. Fuentes de datos 85 5.2.2. Colección de datos Para el desarrollo del sistema se ha contado con una colección de 47 imágenes WSM con polarización VV del Envisat obtenidas a través de un convenio con la ESA. Las imágenes, tomadas entre los años 2007 y 2011, corresponden al noroeste de la Península Ibérica, estando la mayoría centradas en la costa gallega, como puede verse en el mapa de densidad mostrado por la Figura 5.6. Figura 5.6: Representación de la densidad de cobertura de la Base de Datos. La región de estudio es una ampliación del ESTF construida tal y como se muestra en la Figura 5.7. Las imágenes de los años 2007 y 2008 contienen sentinazos detectados por operadores de la EMSA a los que se les ha asignado una probabilidad (alta, baja o media) de ser hidrocarburos. El resto de la colección contiene sentinazos y look-alikes confirmados a través de misiones aéreas de SASEMAR. El número de imágenes de la colección y cuántas de ellas contienen sentinazos (confirmados o no) se puede ver en la Figura 5.8a agrupadas por año. La clasificación de los sentinazos de la colección es mostrada en la Figura 5.8b. La Figura 5.9 muestra la posición geográfica de los vertidos presentes en la DB. Éstos se caracterizan por estar agrupados en torno al ESTF, lo cual es debido a que es paso obligado para los buques y, en consecuencia, sufre en mayor medida el efecto de los sentinazos. 92 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR muestra no tenía suficientes datos como para realizar más divisiones. Cada grupo creado fue nuevamente dividido en subconjuntos en base al IA. En cada subconjunto (con al menos 10 valores) se calculó la media y la desviación típica de los valores de intensidad. Finalmente se escogió el valor de intensidad más alto para cada subconjunto siempre y cuando fuese igual o menor a la suma de la media y el doble de la desviación típica de dicho subconjunto. Nótese que en esta ocasión, al ajustar mejor los valores gracias a los vientos, se optó por relajar el umbral máximo empleando dos veces la desviación típica y no sólo una como en el caso de la umbralización sin vientos (véase Ecuación 5.1). El esquema del proceso seguido se muestra en la Figura 5.14. A=muestra de 1.652 píxeles A' 1= píxeles con viento < 4 m/s A'2= píxeles con viento < 5 m/s A'3= píxeles con viento < 6 m/s A'4= píxeles con viento < 7 m/s A'5= píxeles con viento >= 7 m/s A'' 1= píxeles con ángulo de incidencia [17,18] A''2= píxeles con ángulo de incidencia [18,19] A''25= píxeles con ángulo de incidencia [41,42] ... x25 x2 x1 xi=max(Bi); Bi={y∈A''i / y ≤ A''i + 2*σA''i} Figura 5.14: Esquema de acciones realizadas para establecer el umbral adaptativo. El resultado de este proceso es un conjunto de intensidades para cada rango de velocidad estudiado. Realizando un análisis de regresión sobre los datos se comprobó que, al igual que en la primera aproximación, una función de cuarto grado y una exponencial negativa se ajustaban de forma significa a la muestra. Estudiando dichas funciones con más detalle y a través de pruebas de segmentación, se comprobó que los mejores resultados se obtenían usando la función de cuarto grado en los ángulos de incidencia menores y la exponencial negativa en los mayores. Se estableció una función definida por partes para el cálculo adaptativo del umbral en el que el IA es utilizado para establecer el punto de corte entre las partes. La Tabla 5.4 presenta los coeficientes de las funciones adaptados según la velocidad del viento, así como los puntos de corte establecidos por los IAs. 5.4. Segmentación 93 Velocidad del viento Función de cuarto grado Punto de corte Función exponencial negativa vel. <=4m/s6,3662∗10−6x4−0,00083671x3+0,041262x2−0,90719x+7,5353 37,8◦5,9169e−0,17881x vel. <=5m/s3,0874∗10−6x4−0,00043845x3+0,023424x2−0,55931x+5,0588 36,25◦6,6689e−0,17944x vel. <=6m/s2,1022∗10−6x4−0,00031131x3+0,017414x2−0,4365x+4,1503 36,82◦5,7770e−0,17217x vel. <=7m/s2,7742∗10−6x4−0,00039094x3+0,02086x2−0,50088x+4,5883 37,52◦5,4477e−0,16858x vel. > 7m/s1,2416∗10−6x4−0,00019466x3+0,011604x2−0,31143x+3,182 36,8◦6,2053e−0,17101x Tabla 5.4: Coeficientes y puntos de corte para las funciones de umbral adaptativo. Las funciones exponenciales negativas para vientos de 4 m/s, 6 m/s y mayores que 7 m/s se representan gráficamente en la Figura 5.15 0 0.05 0.1 0.15 0.2 0.25 0.3 20 25 30 35 40 Intensidad Ángulo de incidencia Viento <=4 m/s Viento <=6 m/s Viento > 7 m/s Figura 5.15: Representación de la aproximación de la intensidad en función del IA para distintos valores de la velocidad del viento. 5.4.2. Aplicación del umbral adaptativo El proceso de segmentación se aplica sobre todos los píxeles de una imagen SAR excepto los que previamente han sido enmascarados como tierra y los que pertenecen a zonas fuera del área de alcance del sensor. De cada píxel procesado se extrae su intensidad, el IA y la velocidad del viento. A partir de la velocidad del viento y de los coeficientes presentados en la Tabla 5.4, se obtienen las funciones adecuadas y el punto de corte (IA) entre la función polinómica y la exponencial negativa. Según el IA del píxel y tras compararlo con el punto de corte, se selecciona una 94 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR de las dos funciones y se utiliza el ángulo como parámetro. La función devolverá un umbral que identificará el máximo valor de intensidad que podría tener el píxel analizado para ser considerado parte de un sentinazo. Si la intensidad es menor o igual al umbral, el píxel será etiquetado como candidato y, en caso contrario, como superficie limpia. 5.4.3. Filtro de vientos Dado que existen estudios previos que consideran que es necesaria una velocidad del viento de al menos 3 m/s para detectar un sentinazo, los píxeles segmentados que estén afectados por vientos de intensidad menor que ese umbral son considerados look-alikes y son eliminados de la imagen segmentada. 5.4.4. Filtro de área Los medios de vigilancia contra la polución como los buques y aviones tienen un coste de uso elevado y son limitados, por lo que sólo son utilizados cuando la situación es potencialmente dañina o el vertido tiene una dimensión considerable. Las estructuras formadas por los píxeles segmentados que tengan un área menor que 50 píxeles (equivalente a 0,3km2) son consideradas como falsos positivos o como pequeños sentinazos no dañinos que pueden ser eliminados de la imagen segmentada. 5.5. Extracción de características El resultado de la fase de segmentación es una imagen binaria donde aparecen resaltados todos los sentinazos junto con un gran número de look-alikes. Es tarea de un clasificador separar los sentinazos de los falsos positivos y, para una correcta clasificación, es necesario obtener un vector de características para cada candidato que pueda ser analizado por el clasificador. El vector de características utilizado para el desarrollo de este algoritmo está basado en tres tipos de características: – Características de forma: la forma puede ser un factor determinante para clasificar un candidato. Estudios anteriores [92] han mostrado que, debido a su naturaleza, los sentinazos pueden agruparse en 5 grandes clases desde el punto de vista de su forma (véase la Figura 4.7). 5.5. Extracción de características 95 – Características físicas: se han incorporado características asociadas al nivel de intensidad de los píxeles dado que su importancia y utilidad ha sido refrendada por estudios previos [37]. – Información contextual: Los datos de contexto en general y más concretamente los de vientos [40] son de gran utilidad a la hora de detectar sentinazos y deben ser incorporados al vector de características. Tipo Nombre Descripción Forma APR Área / Perímetro Elongación Eje mayor / Eje menor MPR Eje mayor / Perímetro Rectangularidad Área / Área (Min. rect. engloba) Circularidad Perímetro2/ (4 π*Área) Thickness Número de erosiones necesarias para dividir un objeto. Hu1 (η20 +η02) Hu2 (η20 −η02) + 4η2 11 Hu3 (η30 +3η12)2+ (3η21 −η03)2 Hu4 (η30 +η12)2+ (η21 +η03)2 Hu5 (η30 −3η12)(η30 +η12)[(η30 +η12)2−3(η21 +η03)2]+(3η21 −η03)(η21 +η03)[3(η30 + η12)2−(η21 +η03)2] Hu6 (η20 −η02)[(η30 −η12)2−(η21η03)2]+ 4η21(η30 +η12)(η21 +η03) Hu7 (3η21 −η30)(η00 +η12)[(η30 +η12)2−3(η21 +η03)2]+(3η12 −η03)(η21 +η03)[3(η30 + η12)2−(η21 +η03)2] Flusser y Suk - I1(η20η02 −η2 11)/η4 00 Flusser y Suk - I2(−η2 30η2 03 +6η30η21η12η03 −4η30η3 12 −4η3 21η03 +3η2 21η2 12)/η10 00 Flusser y Suk - I3(η20η21η03 −η20η2 12 −η11η30η03 +η11η21η12 +η02η30η12 −η02η2 21)/ν7 00 Flusser y Suk - I4(−η3 20η2 03 +6η2 20η11η12η03 −3η2 20η02η2 12 −6η20η2 11η21η03 −6η20η2 11η2 12 + 12η20η11η02η21η12 −3η20η2 02η2 21 +2η3 11η30η03 +6η3 11η21η12 −6η2 11η02η30η12 − 6η2 11η02η2 21 +6η11η2 02η30η21 −η3 02η2 30)/η11 00 Contexto AI IA respecto al centroide de la mancha. Viento Velocidad del viento en el área estudiada. Físicas Intensidad Intensidad media de los píxeles contenidos en la mancha candidato. ASR Ratio de la intensidad del candidato respecto al área circundante. Nota: ηi j representa a los momentos centrales normalizados. Tabla 5.5: Vector de características. El vector generado (véase Tabla 5.5) está compuesto por 21 componentes de los que 17 corresponden a características de forma. Para disminuir la dimensionalidad del vector se aplicó un Análisis de Componentes Principales (PCA) [67] sobre las características de forma. La Tabla 5.6 contiene los porcentajes de varianza explicados por los componentes principales obtenidos tras el PCA, mientras que la Figura 5.16 muestra gráficamente el porcentaje explicado por el subconjunto de componentes más representativo. Finalmente, se sustituyeron las 96 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR 17 características de forma por los 5 primeros componentes cubriendo así más del 92% de la varianza y reduciendo considerablemente la dimensionalidad del vector. Los coeficientes de los componentes principales seleccionados se muestran en la Tabla 5.5. PCA1 PCA2 PCA3 PCA4 PCA5 0 10 20 30 40 50 60 70 80 90 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 100% Componentes Principales Varianza Explicada Figura 5.16: Componentes principales y porcentaje de varianza explicado. Componente Principal 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Varianza explicada (%) 47,7716 18,3024 13,8332 7,3918 5,0537 3,7671 1,9663 0,8758 0,4884 0,3178 0,0938 0,0693 0,0414 0,0142 0,0089 0,0041 0,0001 Tabla 5.6: Componentes principales y porcentaje de varianza explicado. 5.6. Clasificación Una vez caracterizados los candidatos, es necesario clasificarlos y asignarles una clase (sentinazo o look-alike). El vector de características de cada candidato es la entrada para un clasificador cuya salida será una clase o etiqueta identificándolo. La eficiencia del clasificador está directamente relacionada con los datos del vector, es decir, un buen clasificador no podrá clasificar correctamente si las características no discriminan suficientemente bien. La máxima seguida para el desarrollo de los clasificadores fue la de minimizar el número de falsos negativos incluso cuando la consecuencia era incrementar el número de falsos positivos. Para el sistema es asumible mostrar falsos positivos debido a que, o bien el sistema es semiautomático, es decir, un operador humano filtra los resultados antes de enviar los medios de vigilancia, o bien el sistema es completamente automático, en cuyo caso los sistemas de vigilancia se activarían tras el descubrimiento del look-alike con el consecuente gasto 5.6. Clasificación 97 Var1 PCA Var2 PCA Var3 PCA Var4 PCA Var5 PCA APR -0,0321 0,0466 0,6160 0,1722 -0,1237 elongación 0,1770 0,3460 -0,1469 0,2321 -0,1141 MPR 0,.2596 0,0579 0,3499 0,0017 -0,0160 Rectangularidad -0,1196 -0,0306 0,2473 0,0149 0,8811 Circularidad 0,3070 -0,.0775 0,0457 -0,0321 -0,2217 Thickness -0,0013 0,0530 0,6099 0,1626 -0,2103 Hu10,3299 0,0316 -0,0735 0,0802 -0,0472 Hu20,3371 0,0255 -0,0683 0,1573 0,0767 Hu30,3389 -0.0366 -0,0237 0,0670 0,1383 Hu40,2769 0,3158 -0,0167 -0,0164 0,1338 Hu50,2092 0,4218 -0,0049 -0,0343 0,1185 Hu60,2055 0,4349 -0,0000 -0,0842 0,1202 Hu7-0,2791 0,3182 -0,0151 0,0583 -0,1003 FS10,2795 -0,2692 0,0373 -0,2175 -0,0562 FS20,0728 -0,2281 -0,1329 0,7528 0,0772 FS3-0,2540 0,2239 -0,1053 0,4511 -0,0382 FS4-0,2567 0,3457 -0,0020 -0,1540 -0,0864 Tabla 5.7: Coeficientes de los componentes principales seleccionados. económico pero sin consecuencias medioambientales. Los falsos negativos, por el contrario, no podrían detectarse ni de forma automática ni por un operador ya que el sistema no los mostraría y esto conllevaría un mayor impacto en el ecosistema dado que no se activarían los protocolos de gestión de forma temprana. Los siguientes apartados describen dos clasificadores desarrollados para identificar los candidatos generados en la segmentación. Para su desarrollo y entrenamiento se ha utilizado una DB de candidatos previamente etiquetados con 155 falsos positivos y 80 sentinazos que fueron distribuidos en 3 grandes grupos (véase la Figura 5.17): el 70% de los elementos fue reservado para el entrenamiento, un 15% fue utilizado para el conjunto de validación y el 15% restante fue seleccionado para el conjunto de test. Base de datos de candidatos 155 Look-alikes 80 Sentinazos 128 66 27 14 101 52 27 14 Test Validación Datos para el entrenamiento Entrenamiento 85% 15% 15% 70% Figura 5.17: DB de candidatos etiquetados utilizados para desarrollar los clasificadores. 98 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR 5.6.1. Redes Neuronales Artificiales Introducción Las ANN tratan de emular el comportamiento del cerebro humano y la extracción de conocimiento genérico a partir de un conjunto de datos [71]. Las ANNs, al igual que el cerebro, están compuestas de procesadores elementales llamados neuronas artificiales o simplemente neuronas que, conectadas entre sí o a entradas externas, cooperan para producir un estímulo de salida. Cuando un conjunto de neuronas recibe todas sus entradas de una misma fuente y todas sus salidas se dirigen a un mismo destino, forman una capa. Una neurona artificial se caracteriza por los siguientes elementos (véase la Figura 5.18): – Estado inicial: las neuronas de la red presentan un estado o valor inicial (at−1) previo a recibir los estímulos externos y que influirá en su respuesta a éstos. – Conexiones neuronales: valores de entrada a la neurona j-ésima (xi) con unos pesos asociados (wi j). – Función de propagación: determina la entrada de la neurona (Netj). Generalmente es el sumatorio de cada uno de sus estímulos externos o entradas (xi) multiplicado por su peso asociado (wi j). Es habitual que se incluya un término constante (x0) denominado sesgo. La inclusión de este elemento se deriva del comportamiento de las neuronas biológicas, que poseen umbrales internos de activación que distorsionan el impacto causado por los estímulos recibidos. El término suele tener el valor ‘1’ y el valor y signo de su peso indica su influencia en la función. – Función de activación o transferencia: combina el valor inicial de la neurona (at−1) con la entrada obtenida por la función de propagación (Netj) para producir un nuevo estado o valor de la neurona. – Función de salida: transforma el estado de la neurona generado a través de la función de transferencia en una señal de salida (yj) que se trasmitirá a las siguientes neuronas. Habitualmente, la función de salida coincide con la función identidad, es decir, el valor de salida es, en la práctica, el valor retornado por la función de transferencia. Una de las características más importantes de las ANNs es su capacidad de generalizar a partir de ejemplos, lo que permite dar una respuesta correcta ante patrones no presentados previamente. Las ANNs tienen la capacidad de aprender creando, modificando o destruyendo 5.6. Clasificación 99 ... w1,j wd,j wn,j F(aj(t-1),Netj)=aj(t)) f(aj(t))=yj → yj Entradas Pesos Entrada total Func. activación Func. salida Salida X0 Sesgo w0,j Netj=∑ wkj·xk k=0 n X1 Xd Xn ... Neurona j-ésima Figura 5.18: Elementos de una neurona artificial. Figura adaptada de [71]. sus conexiones (pesos) entre sus neuronas. Existen diferentes algoritmos de aprendizaje pero todos ellos pueden ser englobados en uno de los dos grandes tipos presentados a continuación: – Aprendizaje supervisado: se caracteriza por la presencia de un agente que controla el proceso de entrenamiento estableciendo una respuesta correcta para una serie de valores de entrada determinados. Si la salida de la red no es la salida deseada, el supervisor modifica iterativamente los pesos de las neuronas de la red (wi j) con el objetivo de que el resultado tienda al deseado. Éste es el tipo de aprendizaje utilizado para desarrollar la ANN para la detección de los sentinazos y, en concreto, se usó una técnica de aprendizaje por corrección de error denominada backpropagation. Las técnicas por corrección de error ajustan los pesos de las conexiones de la red en base a la diferencia entre la salida deseada y la obtenida. Una de las reglas más sencillas para la corrección es la siguiente: wt+1 i j =wt i j +∆wi j ∆wi j =α(rj−yj)xj (5.4) Dada una conexión neuronal entre la neurona i-ésima y la j-ésima con un peso wi j en el instante t,∆wi j representaría la variación en el peso de la conexión en el instante t+1, es decir, la corrección del error. En el cálculo de ∆wi j,αes un factor de aprendizaje, rj es la salida deseada ante un determinado patrón, mientras que yjes la salida realmente obtenida y, finalmente, xjes la entrada a la neurona j. 100 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR – Aprendizaje no supervisado: se presenta a la red una serie de patrones sin una respuesta asociada. La red busca particularidades, correlaciones o categorías presentes en los datos de entrada y los categoriza. Las conexiones neuronales son uno de los elementos fundamentales en el aprendizaje y pueden producirse entre neuronas de una misma capa o entre neuronas de capas diferentes sin limitaciones. El modelo de ANNs más utilizado en la práctica es el Perceptrón Multicapa (MLP), que constituye un modelo particular en el que la propagación de los datos es siempre hacia adelante, es decir, ninguna salida neuronal constituye la entrada a una neurona de la misma capa o de una capa anterior. Las redes MLP (véase la Figura 5.19) están compuestas por una capa neuronas de entrada donde se recogen los datos del exterior, una o varias capas de neuronas ocultas y una capa de salida que devuelve los resultados de la red. Figura 5.19: Estructura de una red neuronal MLP. Algoritmo de retropropagación de errores Debido a su sencillez y eficacia, el algoritmo de retropropagación de errores o de backpropagation [58] es uno de los algoritmos de aprendizaje supervisado más extendido para redes MLP. Básicamente, el algoritmo modifica iterativamente los pesos de las conexiones entre las neuronas con el objetivo de minimizar el error de la red. Partiendo de unos pesos aleatorios y de un conjunto de patrones de entrenamiento correctamente clasificados, el algoritmo procesa a través de la red cada patrón. El error cometido al procesar un patrón es cuantificado para modificar los pesos en consecuencia. La modificación iterativa de los pesos se realiza con el objetivo de que el resultado real tienda al deseado. La cuantificación del error medio-total de 5.6. Clasificación 101 la red se calcula como: E(w|x,r) = 1 2(r−y)2(5.5) , siendo rel resultado deseado para la entrada de un patrón a la red e yel resultado realmente obtenido. La modificación de los pesos trata de minimizar el error de la red, siendo el descenso de gradiente el método más habitual para ello, siempre y cuando la función para calcular el error sea diferenciable. Las variaciones de los pesos utilizando el descenso de gradiente se obtendrían a través del siguiente cálculo: ∆wh j =−α∂E ∂wh j (5.6) El algoritmo de retropropagación de errores tiene dos fases principales: en una primera fase, los patrones de entrenamiento son presentados y analizados por la red y sus salidas son comparadas con los resultados esperados; en una segunda fase se modifican los pesos de la red calculando el error cometido y propagándolo desde la capa de salida hasta la capa de entrada. x0=1 xj xn z0=1 whj vih zh zk w0 sesgo sesgo v0 yi Figura 5.20: Ejemplo simplificado de una red MLP. Actualización de los pesos Partiendo del ejemplo mostrado en la Figura 5.20 en el que la función de transferencia de las neuronas de la capa oculta es una sigmoide, la salida de la red, para un determinado patrón p, se obtiene a través del siguiente cálculo: yp i= k ∑ q=1 viqzq+v0(5.7) 108 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR El árbol con hojas puras y generado únicamente a través del entrenamiento se muestra en la Figura 5.24; se puede observar que el tamaño del árbol es considerable y se le presupone un sobreentrenamiento. A través de un proceso de poda, en el que se calculó la eficacia de los diferentes subárboles sobre el conjunto de validación, se estableció que el mejor clasificador era el subárbol presentado en la Figura 5.25. Para confirmar su eficacia se utilizó el conjunto de test. Los resultados del clasificador sobre los candidatos contenidos tanto en el conjunto de test como en el de validación, se presentan en el Capítulo 6. Ratio intensidad < 2,04183 Sentinazo Look-alike PCA3 < 9,49121 AI < 24,9877 Viento < 2,98174 PCA4 < 2,37383 Intensidad < 0,0748946 PCA1 < 107,964 Intensidad < 0,00383156 Ratio intensidad < 2,49859 Viento < 3,49681 PCA1 < 53,2078 PCA1 < 185,418 Sentinazo Look-alike Sentinazo Look-alike Sentinazo PCA5 < -1,45036 PCA1 < 491,891 PCA1 < 7,13184 Sentinazo Look-alike Sentinazo Ratio intensidad 1,60946 PCA4 < 3,12993 PCA4 < 3,18744 PCA1 < 23,493 PCA5 < -3,77764 PCA2 < 2,19814 Viento < 5,63786 Sentinazo Look-alike Look-alike Sentinazo Look-alike Sentinazo Look-alike Sentinazo Look-alike Sentinazo Sentinazo Sentinazo Look-alike Sí No No No No No No No No No No No No No No No No No No No No No No Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Sí Figura 5.24: Árbol de decisión binario, sin podar y con hojas puras, generado por el proceso de entrenamiento. Ratio intensidad < 2,04183 Sentinazo Look-alike PCA3 < 9,49121 Sentinazo No No Sí Sí Figura 5.25: Árbol de decisión binario podado. 5.7. Validación del sistema de detección de vertidos 109 5.7. Validación del sistema de detección de vertidos 5.7.1. Desarrollo de un software de escritorio La necesidad de evaluar los algoritmos presentados en las secciones anteriores condujo al desarrollo de un software de escritorio. La implementación del prototipo se basó en software de código libre y abierto con el objetivo de que pudiese ser libremente distribuido y así promover la colaboración entre la comunidad científica. Visualización Para facilitar el trabajo con los datos SAR, se implementó un visor específico que permitiese visualizar e interactuar (navegar, aumentar y reducir) con las imágenes, así como representarlas sobre un mapa de contexto mundial para mejorar la interpretación de los resultados. El visor (véase la Figura 5.26) también se diseñó para acceder a los metadatos contenidos en las cabeceras de las imágenes. Figura 5.26: Pantalla principal del software de escritorio. 110 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR Identificación de sentinazos El prototipo implementado contiene las diferentes funciones y métodos de detección de sentinazos presentados en los apartados anteriores. Existen dos formas de ejecutarlo: por un lado, automáticamente a través de los parámetros, filtros y funciones por defecto; por otro lado, haciendo uso de una personalización que permite configurar y/o modificar el procesado de la imagen: – Filtro de ruido: la aplicación dispone de un filtro de mediana, un filtro de Gauss y un filtro bilateral. – Filtro de área: el usuario puede seleccionar el valor máximo del filtro del área que se aplicará a la imagen. – Clasificadores: la aplicación permite emplear los diferentes clasificadores a través de su configuración por defecto o cargando una nueva base de conocimiento. El resultado de cada acción ejecutada sobre la imagen es mostrado en el visor, lo que permite evaluar sus efectos. La Figura 5.27 muestra un ejemplo del resultado obtenido tras procesar una imagen SAR empleando los parámetros por defecto: máscara de tierra (véase la Sección 5.3.2), filtro de mediana de 3x3 (véase la Sección 5.3.3), segmentación por umbralización adaptativa en base a los vientos (véase la Sección 5.4.1), filtro de vientos menores a 3 m/s (véase la Sección 5.4.3), filtro de áreas inferiores a 0,3 Km2(véase la Sección 5.4.4) y clasificación empleando la ANN (véase la Sección 5.6.1). 5.7.2. Integración en RETELAB Una vez finalizado y validado el sistema de detección de vertidos de hidrocarburos se procedió a su integración en RETELAB. Al contrario que el prototipo de escritorio que permitía ir visualizando el efecto de ejecutar diferentes acciones sobre los datos SAR, la versión Grid de SENTINAZOS fue pensada para ser ejecutada en modo no interactivo, de forma que el usuario debe seleccionar en un primer momento los parámetros de la tarea y a continuación procesarla y esperar a los resultados finales. A pesar de la limitación en cuanto a la interacción, las ventajas que proporciona la computación Grid al sistema SENTINAZOS son importantes: 5.7. Validación del sistema de detección de vertidos 111 Figura 5.27: Captura de pantalla del resultado de procesar una imagen SAR a través de los parámetros por defecto y un clasificador ANN. – Permite compartir los datos (vientos, datos SAR, etc.) entre los diferentes centros participantes. – Los resultados obtenidos pueden ser distribuidos y utilizados para nuevos estudios por el resto de los participantes de la red: por ejemplo, para realizar predicciones de la evolución de los vertidos o para ejecutar algoritmos de backtracking con el objetivo de detectar su fuente. – El entorno de RETELAB permite ejecutar diferentes instancias de SENTINAZOS y así procesar diferentes áreas simultáneamente. – La presencia de recursos computacionales de gran potencia puede aportar una mayor velocidad de procesamiento. El portlet para la detección de sentinazos permite seleccionar diferentes acciones a realizar sobre los datos SAR como, por ejemplo, segmentar, clasificar una imagen previamente segmentada o segmentar y clasificar. Para la clasificación se permite escoger uno de los dos clasificadores implementados (ANN o árboles de decisión) y los parámetros escogidos tanto para los filtros (ruido, área, vientos) como para los clasificadores, están prefijados. 112 Capítulo 5. Sistema automático de detección de vertidos en imágenes SAR Al igual que el resto de los portlets, éste ha sido integrado con el Data Grid (véase la Sección 3.3) tanto para poder acceder y utilizar los datos de la DB virtual como para compartir los resultados generados. Además, el portlet también se ha integrado con el monitor de tareas para realizar un seguimiento del estado de las tareas y acceder a los resultados que generen. La Figura 5.28 muestra el portlet desarrollado para SENTINAZOS y su integración en el laboratorio de RETELAB. Figura 5.28: Captura de pantalla del portlet desarrollado para integrar SENTINAZOS en el laboratorio virtual. CAPÍTULO 6 RESULTADOS 6.1. Eficacia Los clasificadores presentados en las secciones 5.6.1 y 5.6.2 han sido desarrollados utilizando la DB de candidatos presentada en la Figura 5.17, es decir, se han utilizado los mismos conjuntos para entrenar, validar y probar los clasificadores, lo que permitió realizar una comparativa entre ellos en términos de eficacia (véase Tabla 6.1). Los datos relativos al rendimiento del árbol de decisión original (sin podar) son meramente ilustrativos, ya que reflejan cómo el sobreentrenamiento afecta a la clasificación de otros conjuntos que no sean el de entrenamiento. En la práctica, sólo el árbol podado y la red MLP han sido utilizados como clasificadores. Validación Test Sentinazos Look-alikes Sentinazos Look-alikes Red MLP 85,7% 85,2% 92,9% 96,3% Árbol decisión original 50,0% 88,9% 35,7% 88,9% Árbol decisión podado 92,9% 85,2% 92,9% 92,6% Tabla 6.1: Eficacia de los diferentes clasificadores sobre los conjuntos de validación y test. La eficacia de los clasificadores fue comprobada directamente sobre las imágenes SAR al ser éstos implementados como parte del prototipo descrito en la sección 5.7.1. La Figura 6.1 muestra una composición, realizada sólo con el objeto de facilitar la visualización, de 2 imágenes SAR (Figura 6.1a) y su correspondiente segmentación (Figura 6.1b), así como los resultados obtenidos por los clasificadores (Figura 6.1c y Figura 6.1d). Enmarcados en 114 Capítulo 6. Resultados color rojo se identifican varios sentinazos, confirmados a través de misiones de vigilancia de SASEMAR, que se detallan en la Figura 6.2 junto al resultado de clasificarlos mediante la red MLP. 9°W10°W 43°N 0 10 20 305 Millas Náuticas A B C a b 9°W10°W 43°N 0 10 20 305 Millas Náuticas A B C 9°W10°W 43°N 0 10 20 305 Millas Náuticas A B C c d Figura 6.1: a) Composición, a efectos de visualización, de 2 imágenes SAR. La imagen ‘1’ fue obtenida el 28/03/2011 y la imagen ‘2’ el 14/10/2011. b) Composición formada por la segmentación de las imágenes SAR. c) Montaje formado por los resultados de aplicar el clasificador basado en el árbol de decisión a las imágenes segmentadas. d) Montaje formado por los resultados de aplicar el clasificador basado en la red MLP a las imágenes segmentadas. Se puede observar que los resultados obtenidos a través del clasificador basado en el árbol de decisión son muy similares a los ofrecidos por el que utiliza la red MLP (sobre todo desde el punto de vista de la detección de sentinazos), si bien la ANN (véase la Figura 6.1d) genera una menor cantidad de falsos positivos. 6.1. Eficacia 115 A 10°30'W10°40'W 43°40'N 0 1 2 30,5 Millas Náuticas B 9°50'W10°W10°10'W10°20'W10°30'W 43°N 42°50'N 42°40'N 0 4 8 122 Millas Náuticas C 9°40'W9°50'W10°W 42°10'N 42°N 0 2 4 61 Millas Náuticas Figura 6.2: A la izquierda, detalle de los sentinazos confirmados e identificados en la Figura 6.1; a la derecha, resultados obtenidos a través del clasificador basado en una red MLP. 116 Capítulo 6. Resultados 6.2. Tiempo de procesamiento El tiempo requerido para el procesamiento de las imágenes en la búsqueda de vertidos de hidrocarburos es crítico y, por ello, los algoritmos presentados en las secciones anteriores han sido desarrollados con el objetivo de minimizarlo pero sin sacrificar su eficacia, sobre todo en cuanto a la no detección de sentinazos (falsos negativos). Además de tener un especial cuidado en el diseño e implementación del software, el código se desarrolló pensando en obtener el mejor rendimiento de los microprocesadores multinúcleo presentes en la mayoría de las computadoras actuales. Para la implementación se empleó el API de OpenMP [36], que permite adaptar y paralelizar automáticamente la ejecución del código entre los diferentes núcleos de los que disponga el procesador donde se ejecuta la aplicación y así obtener el máximo rendimiento. Fueron probadas dos versiones del algoritmo (clásica y optimizada) utilizando un nodo de computación Core 2 Duo - 2,13 Ghz con 3 GB de RAM y, después de 100 iteraciones sobre una imagen de 8.088 x 6.481 píxeles, la versión optimizada empleó una media de 19,4 segundos por ejecución, mejorando un 29,6% el tiempo de ejecución del algoritmo clásico. CAPÍTULO 7 DISCUSIÓN Debido a las condiciones, tanto geográficas como climatológicas, de la costa gallega (área de estudio), los vientos de baja intensidad generan la mayor parte de los falsos positivos o look-alikes. El algoritmo desarrollado los filtra, en su mayor parte, en la fase de segmentación al introducir una umbralización basada en la velocidad del viento. Una de las consecuencias de este proceso de segmentación es que algunos vertidos pueden quedar parcialmente ocultos en la salida si se encuentran situados en áreas afectadas por vientos de baja intensidad. Modificar el umbral de viento mínimo mejora la segmentación en algunos de los casos pero a costa de incrementar notablemente el número de falsos positivos. Es muy complicado detectar sentinazos en áreas con vientos de baja intensidad debido a que la superficie del mar no genera el brillo suficiente en la imagen SAR para que se produzca un contraste entre la superficie afectada por el sentinazo y el mar limpio y, además, la intensidad de la señal retrodispersada que llega al satélite se aproxima al ruido de fondo (véase la Sección 5.2.1) dificultando discernir los fenómenos presentes en la superficie. A pesar de que la utilización de los datos de viento mejoró considerablemente la segmentación, ésta podría ser más precisa si se utilizasen medidas reales o provenientes de modelos de vientos más precisos que el CMOD5 que trabaja directamente con los datos SAR. El modelo CMOD5 es bastante exacto cuando se trata de velocidades de viento inferiores a 15 m/s y empeora con vientos de mayor intensidad [62]. El error producido por el modelo, aunque sea pequeño, podría ser clave para que una zona sea identificada como look-alike, sobre todo si no alcanza el umbral mínimo de viento. 124 Capítulo 8. Resultados y conclusiones implementado empleando GridSphere, que proporciona un entorno de desarrollo de portales Web basado en portlets. El uso de portlets permite desplegar aplicaciones independientes del middleware Grid utilizado en el sistema, así como reutilizarlas en otros portales. La solución tecnológica desarrollada permite al usuario centrar sus esfuerzos en el desarrollo de sus trabajos y no en el aprendizaje de las herramientas. –Sistema de autenticación y autorización simplificado: buscando una solución bien equilibrada entre seguridad y facilidad de uso, se diseñó y desarrolló un sistema de autenticación y autorización integrando y mejorando diferentes tecnologías. El sistema de registros de usuarios PURSe fue desplegado para abstraer a los usuarios del uso de los DCs. Tanto PURSe como GridSphere fueron modificados para gestionar roles de usuarios a través de ACs y así poder emplearlos como medio de autorización en el Grid. El uso de un sistema de autorización del tipo RBAC en un Grid simplifica la administración de los recursos y, por esta razón, en RETELAB se integró el software PERMIS que permite gestionar políticas de seguridad basadas en roles. –Despliegue de un sistema de autenticación SSO: los usuarios que pertenezcan a centros incluidos en la red de confianza de RETELAB pueden acceder al portal sin necesidad de registrarse, a través del sistema de autenticación de sus centros. Para realizar este proceso se integró Shibboleth y se desarrollaron procedimientos que generan, de forma temporal, DCs y ACs para los usuarios externos. Los datos necesarios para los diferentes certificados son proporcionados por las organizaciones en el proceso de autenticación. –Despliegue de un sistema de almacenamiento distribuido basado en metadatos: se ha diseñado y desplegado un sistema de almacenamiento distribuido que permite a la comunidad de RETELAB compartir los datos de sus investigaciones. Esta DB virtual, que soporta formatos estándar en oceanografía, está dirigida por metadatos para facilitar el etiquetado y descripción de los datos almacenados y así mejorar los sistemas de búsquedas. Para unificar el uso de los metadatos se ha seleccionado el estándar para describir información geográfica ISO 19115. –Despliegue de un metaplanificador y un monitor de trabajos: se ha diseñado una interfaz de ejecución y monitorización de trabajos que permite a los usuarios configurar, ejecutar y monitorizar sus trabajos sin que sea necesario que conozcan la infraestructura hardware. Para ello, se ha desplegado una versión mejorada del metaplanificador 125 GridWay que se encarga de gestionar, en nombre del usuario, la ejecución de las tareas. El monitor permite visualizar el estado de las tareas y acceder a los resultados una vez que hayan finalizado. Tanto la versión del GridWay utilizada como la interfaz de ejecución y monitorización de los trabajos ha sido realizada por el CESGA en el marco del proyecto RETELAB. –Validación y distribución de los resultados: utilizando la interfaz de monitorización, el usuario puede acceder a los resultados de las tareas ejecutadas. Desde la interfaz de resultados, el usuario puede descargar los ficheros generados o compartirlos con la comunidad, publicándolos, previa descripción a través de metadatos, en la DB virtual, lo que realimenta el sistema. El entorno cuenta con una herramienta avanzada para la visualización y validación de los datos llamada IDV (desarrollada por Unidata). Este software se descarga e instala en el puesto de trabajo del usuario de forma temporal y transparente y se ejecuta con los datos seleccionados por el usuario. –Desarrollo de un sistema de detección de vertidos de hidrocarburos: el laboratorio virtual se ha validado a través del despliegue de varias aplicaciones y, entre ellas, por su entidad, alcance y necesidad de investigación adicional del estado del arte, destaca SENTINAZOS. Éste es un sistema de detección de vertidos de hidrocarburos en la superficie oceánica que fue desarrollado con el doble propósito de validar el sistema y de encontrar una solución para un problema diario de nuestras costas. Las principales aportaciones de este sistema son: •Desarrollo de un procedimiento de segmentación adaptativo basado en la velocidad del viento: partiendo de una DB de imágenes SAR enriquecida, tanto con datos de viento como con información de vertidos de hidrocarburos, se implementó un segmentador basado en una umbralización adaptativa. El establecimiento de este umbral tiene como base el estudio de centenares de datos muestreados en los que se analizó la velocidad del viento, el IA del satélite respecto al punto muestreado y su valor de intensidad. Tras el estudio de la muestra, se constató que si el IA era similar, las muestras asociadas a hidrocarburos tenían valores de intensidad menores a las que representaban superficie limpia pero, además, se comprobó que estos valores tenían una relación directa con el viento que afectaba a la zona. Empleando estos datos, se estableció una función definida por partes que representaba el umbral de intensidad del hidrocarburo según el IA y la velocidad del 126 Capítulo 8. Resultados y conclusiones viento. Este procedimiento de segmentación obtiene un menor número de falsos positivos que otras alternativas, lo que permite facilitar el trabajo del clasificador y obtener mejores resultados. •Caracterización de los candidatos a través de la forma: diferentes estudios han constatado que los sentinazos adquieren formas que siguen patrones singulares debido a su origen y a su antigüedad. Partiendo de la hipótesis de que la forma es un elemento diferenciador, se desarrolló un procedimiento para caracterizar los candidatos que generaba un vector dominado por las características relacionadas con la forma. La dimensionalidad de dicho vector fue reducida a través de un PCA, siendo el resultado utilizado como entrada para el clasificador. •Sistema semiautomático de detección de vertidos: se desarrollaron y analizaron dos clasificadores para separar los falsos positivos de los sentinazos. Tanto la ANN como el árbol de decisión obtuvieron resultados muy prometedores. El uso de un segmentador optimizado permite emplear clasificadores más sencillos, por lo que se reduce el tiempo de procesamiento sin sacrificar la tasa de aciertos. •Disminución del tiempo de procesamiento: empleando un paradigma de programación paralela con memoria compartida, se ha implementado un sistema que permite procesar completamente un producto SAR en un tiempo considerablemente inferior al usado por aplicaciones similares encontradas en la literatura. Esta mejora en el tiempo de procesamiento permite emplear el sistema de detección como una herramienta de ayuda a la toma de decisiones en tiempo casi real. CAPÍTULO 9 TRABAJO FUTURO 9.1. Trabajo futuro en el proyecto RETELAB El futuro del laboratorio virtual puede verse desde dos puntos de vista: por un lado, la evolución del propio entorno, que se centrará en el análisis de los posibles puntos de confluencia entre la computación Grid y la Cloud. Por otro, el del desarrollo y mejora de las aplicaciones desplegadas, en particular, la mejora de los algoritmos para la detección de vertidos, así como la adaptación de éstos para trabajar con datos provenientes de fuentes diferentes al Envisat, como por ejemplo el futuro satélite Sentinel-1. 9.1.1. Computación Cloud La computación Cloud es un nuevo paradigma de computación distribuida que ha surgido con fuerza estos últimos años. Al igual que ocurrió con la computación Grid, su definición ha sido objeto de debate tanto en el mundo empresarial como entre la comunidad científica. La literatura presenta multitud de definiciones pero en general se observa que las que provienen del mundo empresarial se centran en la perspectiva del usuario final y su experiencia de uso, mientras que desde la comunidad científica se incluyen también aspectos relativos a su arquitectura. Foster et ál. [48] definen la computación Cloud como: «Un paradigma de computación distribuida de gran envergadura dirigido por economías de escala en el que un conjunto administrado de recursos (procesamiento, almacenamiento, entornos y aplicaciones) abstractos, virtualizados y dinámicamente escalables se proporcionan, bajo demanda, a clientes vía Internet.» 128 Capítulo 9. Trabajo futuro La computación Cloud es un paradigma de computación distribuida altamente especializado que presenta las siguientes diferencias respecto a anteriores paradigmas [48]: – Es altamente escalable. – Puede ser encapsulado como una entidad abstracta y proporcionar diferentes niveles de servicios a los clientes finales. – Está dirigido por economías de escala. – Los servicios son proporcionados bajo demanda y pueden ser configurados dinámicamente a través de la virtualización. Su arquitectura puede dividirse en capas [48] y éstas mantienen una estrecha relación con los servicios proporcionados (véase la Figura 9.1): – Capa de infraestructura: contiene los recursos hardware más básicos como son los recursos computacionales, los de almacenamiento o los relacionados con la infraestructura de red. – Capa de recursos unificados: empleando los recursos básicos, se encapsulan, a través de la virtualización, nuevos recursos más complejos que pueden ser proporcionados a las capas superiores o directamente a los usuarios finales. – Capa de plataforma: proporciona a los recursos unificados herramientas especializadas, middleware y servicios. Su finalidad es preparar un entorno de desarrollo o de despliegue que pueda ser utilizado por la capa de aplicaciones o proporcionado como servicio a los usuarios. – Capa de aplicaciones: contiene aplicaciones que son ejecutadas en el Cloud y expuestas como servicios para ser utilizadas por los usuarios finales. Los Clouds, en general, proporcionan bajo demanda hasta tres tipos de servicios a los que el usuario puede acceder a través de un navegador Web o de un API bien definida [105]: – Infraestructura como Servicio (IaaS): proporciona recursos computacionales (procesamiento y almacenamiento) virtualizados. Esto permite que los usuarios puedan obtener recursos con unas determinadas características (número de procesadores, memoria, espacio en disco, etc.) para cubrir unas necesidades concretas. 9.1. Trabajo futuro en el proyecto RETELAB 129 – Plataforma como Servicio (PaaS): los servicios de plataforma están pensados para proporcionar a los usuarios entornos específicos, bien sea para desarrollar software o bien sea para desplegarlo, permitiendo que los usuarios se abstraigan del hardware y/o configuraciones. – Sofware como Servicio (SaaS): proporciona software específico para que sea accesible remotamente por los clientes a través de Internet. Figura 9.1: Arquitectura del Cloud relacionada con los servicios que proporciona. Figura adaptada de [105]. 9.1.2. Integración de la computación Cloud en RETELAB La integración de la computación Cloud en el proyecto RETELAB podría proporcionar una mayor flexibilidad al laboratorio. Existen varias líneas de futuro interesantes para desarrollar: – Agregación de recursos bajo demanda: los recursos proporcionados por RETELAB están limitados tanto en su número como en sus características. Si la demanda de recursos por parte de los usuarios excede la capacidad del laboratorio, ya sea porque la cantidad de trabajos ejecutados es mayor de la que puede absorber, porque los trabajos requieren recursos con características superiores (número de procesadores, memoria, etc.) o porque necesitan de un determinado entorno de ejecución que no está disponible, el Cloud podría proporcionar una solución rápida y puntual. Aprovechando que el Cloud 130 Capítulo 9. Trabajo futuro proporciona IaaS, podrían agregarse bajo demanda los recursos necesarios y gracias al PaaS sería posible obtener recursos con una determinada configuración. La tarea de instanciar los recursos recaería sobre el metaplanificador GridWay del que existe un plugin (Broker GW-SLA) que permite negociar con entidades externas para incorporar recursos al Grid y que ya fue utilizado con éxito en proyectos previos [55]. – Modificación dinámica de los recursos: el uso de la computación Cloud también sería útil para gestionar los propios recursos de RETELAB, ya que podría optimizar su uso. Cuando se ejecuta un trabajo en el laboratorio, el metaplanificador necesita conocer sus necesidades para poder gestionar su ejecución. Puede darse el caso de que un trabajo sea asignado a un recurso libre y lo infrautilice, ya que no necesita de todo su potencial (procesadores, memoria, etc.). Mientras tanto, puede llegar a la cola un trabajo que, aunque realmente necesite mejores condiciones para que su ejecución sea óptima, podría aprovechar la parte ociosa del recurso a la espera de mejores recursos. Desplegando un Cloud sobre los recursos disponibles podrían virtualizarse y optimizarse generando recursos «a medida». Asociando a cada cada tarea información sobre cuáles serían los requisitos mínimos y cuáles los deseados para su ejecución, se podría virtualizar y asignar un recurso en el momento en que estuviesen disponibles los recursos mínimos. A medida que los recursos base fuesen quedando ociosos, se aprovecharía la escalabilidad dinámica del Cloud para mejorar el recurso virtual asignado a la tarea hasta alcanzar los requisitos deseados. El metaplanificador sería el encargado de gestionar este proceso, por lo que sería necesario extender el JSDL para soportar dicha información. 9.2. Evolución de las aplicaciones desplegadas: SENTINAZOS 9.2.1. Fuentes de datos Los algoritmos desarrollados para localizar vertidos de hidrocarburos están basados en datos obtenidos por el satélite Envisat a través del modo de operación WSM. A pesar de que la base de los algoritmos es válida para otras fuentes de datos, es cierto que éstos deberían ser adaptados para ajustarse a sus particularidades como, por ejemplo, a las diferentes resoluciones espaciales. La adaptación de los algoritmos para trabajar con diferentes fuentes siempre fue considerado como un trabajo futuro que actualmente y debido a la pérdida de contacto con el satélite Envisat, ha cobrado mayor relevancia. A corto plazo los algoritmos deberían ser adaptados para analizar datos provenientes del Radarsat, mientras que a medio plazo sería 9.2. Evolución de las aplicaciones desplegadas: SENTINAZOS 131 interesante adaptarlos para trabajar con los datos que provengan del Sentinel-1, satélite cuyo lanzamiento está previsto para el año 2013. 9.2.2. Mejora de los algoritmos Existen varias líneas de trabajo que podrían conducir a una mejora de los algoritmos actuales para la detección de vertidos: – Información contextual: dado que los sentinazos son generados habitualmente por buques que transitan por el ESTF o por sus cercanías, sería interesante añadir información contextual respecto a su entorno como, por ejemplo, la proximidad a una posible fuente del vertido o su localización respecto al ESTF. Esta información podría ser obtenida empleando los propios datos SAR, ya que es posible utilizarlos para detectar embarcaciones [89] y, al estar georreferenciados, también es posible posicionar los sentinazos respecto al ESTF. – Incorporación de datos provenientes de los Sistemas Automáticos de Identificación (AISs) de buques: la Organización Internacional Marítima (IMO) requiere que la mayor parte de las embarcaciones posean un sistema AIS para identificarlos y localizarlos. Estos sistemas envían sus datos a estaciones receptoras que almacenan y procesan la información. SASEMAR ha implantado cobertura para AIS a lo largo de toda la costa española, por lo que la información recogida podría ser utilizada en el sistema de detección para acotar los posibles causantes del vertido. – Incorporación de nuevos datos de viento: unos pocos informes de las misiones aéreas a las que tuvo acceso SASEMAR contenían medidas de la velocidad del viento de las zonas en las que fueron detectados vertidos. Estas medidas no se ajustaban correctamente a las obtenidas por el modelo CMOD5 y, aunque la comparación es complicada debido a que las misiones aéreas eran enviadas después de obtener y procesar la imagen SAR (no correspondían al mismo momento), se considera que una posible línea futura es incorporar datos reales o de otros modelos que puedan ser más precisos y así poder comparar los resultados con los obtenidos actualmente. – Análisis de nuevos clasificadores: a pesar de que los resultados obtenidos con las ANNs y con los árboles de decisión son satisfactorios, sería deseable analizar otros clasificadores con el objetivo de alcanzar un mejor porcentaje de aciertos. De entre las diferentes 132 Capítulo 9. Trabajo futuro posibilidades, las Máquinas de Soporte Vectorial (SVM) resultan especialmente interesantes ya que, en problemas tanto de clasificación como de regresión, tratan de definir un hiperplano en un espacio n-dimensional que separe las posibles clases de una forma estricta desde el punto de vista matemático. Otras opciones posibles serían las redes funcionales o los clasificadores basados en lógica borrosa. Bibliografía [1] European Space Agency (ESA). https://earth.esa.in. [2] PURSE: Portal-based User Registration Service. http://www.Gridscenter.org/solutions/purse, (Retrieved October 2012). [3] Sakai project Web Page. http://www.sakaiproject.org/ (Retrieved October 2012). [4] The Apache Velocity Project. http://velocity.apache.org (Retrieved October 2012). [5] Tupelo Web Page. http://tupeloproject.ncsa.uiuc.edu/ (Retrieved October 2012). [6] Xen Web page. http://www.xen.org/ (Retrieved October 2012). [7] ISO 19115:2003 Geographic information - Metadata. Technical report, International Organization for Standardization, 2003. [8] The Grid 2, Second Edition: Blueprint for a New Computing Infrastructure. Morgan Kaufmann, 2 edition, December 2003. [9] Ahmar Abbas. Grid computing a practical guide to technology and applications. Charles River Media, 2004. [10] A. Abdelnur and S. Hepper. JSR 168: Portlet Specification. Technical report, Sun Microsystems, October 2003. Also available online: http://www.jcp.org/en/jsr/detail?id=168 (Retrieved Sept 2012). [11] International Energy Agency. Medium-Term Oil and Gas Markets. IEA Publications, 2011. Also available online: http://www.iea.org/publications/freepublications/publication/MTOGM2011_Unsecured.pdf (Retrieved Sept 2012).