Embed Size (px)
Citation preview
ALGORITMOS DE OPTIMIZACIÓN APLICADOS A LA ADQUISICIÓN DE
IMÁGENES EN SATÉLITES DE OBSERVACIÓN DE LA TIERRA
PROYECTO FIN DE CARRERA INGENIERÍA AERONÁUTICA
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA
(UNIVERSIDAD DE SEVILLA)
DEPARTAMENTO DE INGENIERÍA AEROESPACIAL Y MECÁNICA DE FLUIDOS
AUTOR: Vera Flores, Carlos Iván TUTORES: Vázquez Valenzuela, Rafael Perea Rojas-Marcos, Federico
ii
Tabla de Contenidos
1 Introducción.............................................................................................................. 1 1.1 Marco Global.................................................................................................... 1 1.2 Estructura General del Proyecto....................................................................... 5
2 Formulación de SAP como un problema de programación lineal............................ 7 2.1 Metodología de Resolución.............................................................................. 7 2.2 Simplificaciones y Alcance del proyecto ....................................................... 11 2.3 Formulación del Problema de Planificación EOSs......................................... 12
2.3.1 Enunciado del Problema y Notación ...................................................... 13 2.3.2 Formulación de Modelos........................................................................ 16
2.3.2.1 Modelo Simplificado I: q-satélites y sensor fijo................................. 16 2.3.2.2 Modelo Simplificado II: q-satélites y sensor variable........................ 21 2.3.2.3 Modelo con Restricciones I: q-satélites, sensor fijo y restricciones de duty cycle............................................................................................................ 25
2.4 Herramienta de Geometría Computacional .................................................... 26 3 Algoritmos Heurísticos para la resolución del problema SAP............................... 33
3.1 Algoritmo GRASP para resolución del problema de planificación EOSs ..... 34 4 Análisis y Resultados ............................................................................................. 36
4.1 Estudios Estadísticos sobre el tiempo de cálculo de la matriz Q.................... 36 4.1.1 Modelo I (Matriz Q 2-D): q-satélites con sensor fijo ............................. 36 4.1.2 Modelo II (Matriz Q 3-D): q- satélites con sensor variable ................... 38
4.2 Comparativa entre resultados heurísticos y exactos....................................... 40 4.2.1 Análisis de Resultados............................................................................ 43 4.2.2 Ejemplo................................................................................................... 45
5 Conclusiones........................................................................................................... 53 6 Bibliografía............................................................................................................. 56 7 Apéndice: Descripción del Código Empleado........................................................ 58
7.1 Estructura general de cálculo de matriz Q...................................................... 58 7.1.1 Código SATVAR..................................................................................... 65 7.1.2 Código CALC......................................................................................... 72 7.1.3 Código INTVAR...................................................................................... 78
7.2 Algoritmo heurístico de optimización: Código q-GRASP............................. 80
iii
Lista de Figuras
FIGURA 1.1 EJEMPLO DE SOLUCIÓN NO ÓPTIMA GENERADA POR SAVOIR .....................................................3 FIGURA 1.2 EJEMPLO DE SOLUCIÓN ÓPTIMA USANDO UNA APROXIMACIÓN HEURÍSTICA DE DOS PASOS CON
SAVOIR ...............................................................................................................................................4 FIGURA 2.1 METODOLOGÍA DE RESOLUCIÓN DE SAP .................................................................................11 FIGURA 2.2 EJEMPLO SIMPLIFICADO DE SAP ..............................................................................................17 FIGURA 2.3 SUBREGIONES GENERADAS EN ℜ POR LA INTERSECCIÓN DE LAS ADQUISICIONES...................19 FIGURA 2.4 EJEMPLO ADQUISICIONES GENERADAS POR 10 SATÉLITES Y 5 POSICIONES DE SENSOR.............23 FIGURA 2.5 EJEMPLO SUBREGIONES GENERADAS POR 10 SATÉLITES Y 5 POSICIONES DE SENSOR................24 FIGURA 2.6 POLÍGONOS SOBRES LOS QUE SE APLICAN LAS OPERACIONES GEOMÉTRICAS............................28 FIGURA 2.7 OPERACIÓN DE DIFERENCIA EN POLYGONCLIP.....................................................................29 FIGURA 2.8 OPERACIÓN DE INTERSECCIÓN EN POLYGONCLIP.................................................................30 FIGURA 2.9 OPERACIÓN XOR EN POLYGONCLIP.....................................................................................31 FIGURA 2.10 OPERACIÓN DE UNIÓN EN POLYGONCLIP............................................................................32 FIGURA 4.1 TENDENCIAS COSTE COMPUTACIONAL VERSUS Nº DE SATÉLITES (MATRIZ Q); SENSOR FIJO.....38 FIGURA 4.2 TENDENCIAS COSTE COMPUTACIONAL VERSUS Nº DE ADQUISICIONES (MATRIZ Q); SENSOR
VARIABLE ..........................................................................................................................................40 FIGURA 4.3 SUBREGIONES GENERADAS EN LA INSTANCIA 10 (30 SATÉLITES / 10 MODOS DE SENSOR) ........45 FIGURA 4.4 TOTAL DE ADQUISICIONES A CONSIDERAR SOBRE LA INSTANCIA 10.........................................46 FIGURA 4.5 REGIÓN DE INTERÉS A CUBRIR (INSTANCIA 10) ........................................................................47 FIGURA 4.6 1ª ADQUISICIÓN DE LA SOLUCIÓN ÓPTIMA (INSTANCIA 10) .......................................................47 FIGURA 4.7 2ª ADQUISICIÓN DE LA SOLUCIÓN ÓPTIMA (INSTANCIA 10) .......................................................48 FIGURA 4.8 3ª ADQUISICIÓN DE LA SOLUCIÓN ÓPTIMA (INSTANCIA 10) .......................................................48 FIGURA 4.9 4ª ADQUISICIÓN DE LA SOLUCIÓN ÓPTIMA (INSTANCIA 10) .......................................................49 FIGURA 4.10 5ª ADQUISICIÓN DE LA SOLUCIÓN ÓPTIMA (INSTANCIA 10) .....................................................49 FIGURA 4.11 1ª ADQUISICIÓN DE UNA SOLUCIÓN CASI-ÓPTIMA (INSTANCIA 10) ..........................................50 FIGURA 4.12 2ª ADQUISICIÓN DE UNA SOLUCIÓN CASI-ÓPTIMA (INSTANCIA 10) ..........................................50 FIGURA 4.13 3ª ADQUISICIÓN DE UNA SOLUCIÓN CASI-ÓPTIMA (INSTANCIA 10) ..........................................51 FIGURA 4.14 4ª ADQUISICIÓN DE UNA SOLUCIÓN CASI-ÓPTIMA (INSTANCIA 10) ..........................................51 FIGURA 4.15 5ª ADQUISICIÓN DE UNA SOLUCIÓN CASI-ÓPTIMA (INSTANCIA 10) ..........................................52 FIGURA 4.16 6ª ADQUISICIÓN DE UNA SOLUCIÓN CASI-ÓPTIMA (INSTANCIA 10) ..........................................52 FIGURA 7.1 ESTRUCTURA DE CÓDIGOS PARA EL CÁLCULO DE LA MATRIZ Q (3D) .......................................58 FIGURA 7.2 PSEUDOCÓDIGO EMPLEADO EN MATRIZQVAR........................................................................61 FIGURA 7.3 ADQUISICIONES DE UN SATÉLITE USANDO UN PASO DE VALOR 1..............................................66 FIGURA 7.4 ADQUISICIONES DE UN SATÉLITE USANDO UN PASO DE VALOR 0.1 ...........................................67 FIGURA 7.5 SUBREGIONES GENERADAS POR 3 SATÉLITES, CON 5 POSICIONES DE SENSOR Y PASO DE 1........68 FIGURA 7.6 ADQUISICIONES CORRESPONDIENTES A 3 SATÉLITES, CON 5 POSICIONES DE SENSOR Y PASO DE 1
..........................................................................................................................................................68 FIGURA 7.7 PSEUDOCÓDIGO EMPLEADO EN SATVAR..................................................................................69 FIGURA 7.8 SUBREGIONES GENERADAS TRAS EL CÓMPUTO DE 2 ADQUISICIONES........................................75 FIGURA 7.9 2 ADQUISICIONES DE SATÉLITE.................................................................................................75 FIGURA 7.10 SUBREGIONES GENERADAS TRAS EL CÓMPUTO DE 4 ADQUISICIONES......................................75 FIGURA 7.11 4 ADQUISICIONES DE SATÉLITES.............................................................................................75 FIGURA 7.12 SUBREGIONES GENERADAS TRAS EL CÓMPUTO DE 6 ADQUISICIONES......................................75 FIGURA 7.13 6 ADQUISICIONES DE SATÉLITES.............................................................................................75 FIGURA 7.14 PSEUDOCÓDIGO EMPLEADO EN CALC....................................................................................76 FIGURA 7.15 PSEUDOCÓDIGO EMPLEADO EN Q_GRASP................................................................................83
iv
Lista de Tablas
TABLA 4.1 TIEMPOS DE CÁLCULO DE LA MATRIZ Q PARA MODELO I (SENSOR FIJO) ....................................37 TABLA 4.2 ESTUDIO ESTADÍSTICO DE LA EVOLUCIÓN DEL COSTE COMPUTACIONAL DE Q (MODELO I)........37 TABLA 4.3 TIEMPOS DE CÁLCULO DE LA MATRIZ Q PARA MODELO II (SENSOR VARIABLE) .........................39 TABLA 4.4 ESTUDIO ESTADÍSTICO DE LA EVOLUCIÓN DEL COSTE COMPUTACIONAL DE Q (MODELO II) ......39 TABLA 4.5 TABLA DE EXPERIMENTOS.........................................................................................................41 TABLA 4.6 RESULTADOS HEURÍSTICOS I .....................................................................................................43 TABLA 4.7 RESULTADOS HEURÍSTICOS II ....................................................................................................43 TABLA 4.8 ANÁLISIS DE EXPERIMENTOS.....................................................................................................44
v
Lista de Abreviaturas y Acrónimos
• Adquisición:
Región fotografiada por un satélite en un determinado modo de sensor durante un
intervalo de tiempo ],[ 10 TT . Esta región no tiene que estar contenida de manera íntegra
en la región objetivo.
• CPLEX:
Optimizador o solver, en este trabajo programado con GAMS, para resolver problemas
de programación matemática.
• Duty Cycle:
Período de tiempo durante el cual, el satélite puede llevar a cabo la toma de
adquisiciones. Procesos tales como descarga de datos con estaciones terrestres, eclipses,
recarga de baterías, etc., hacen que sea imposible la adquisición de datos en todo el
período de tiempo considerado.
• EOSs: "Earth Observation Satellites"
Tipo de satélites geocéntricos cuya función es la recopilación de datos sobre la
superficie terrestre para diversos fines, usando tecnología de detección avanzada.
• GAMS: "General Algebraic Modelling System"
Software desarrollado por A. Brooke, D. Kendrick y A. Meeraus que permite resolver
problemas de optimización. Plantea un lenguaje de modelización que permite escribir en
un editor la formulación matemática del problema y posteriormente aplicarle una serie
de "solvers" o programas de resolución. En el contexto de este proyecto, se usa para
corroborar la fiabilidad de los resultados obtenidos mediante algoritmos heurísticos en
la resolución del SAP.
• GRASP: "Greedy Randomized Adaptive Search Procedures"
Procedimiento iterativo que consiste en una fase de construcción y una fase de búsqueda
local. Se obtiene una solución factible durante la fase de construcción aplicando un
vi
procedimiento GREEDY aleatorizado de la fase de construcción. En cada iteración se
agrega un nuevo elemento a la solución de la iteración anterior de acuerdo al valor de
una función GREEDY. En lugar de escoger siempre el elemento que mejora más la
función objetivo, se construye una lista con los k mejores candidatos y se selecciona uno
de ellos al azar. Mayor fiabilidad (para k>1) que el método GREEDY (que no es más
que un GRASP con k=1) para obtener la solución óptima.
• GREEDY ("Algoritmo Codicioso o Voraz"):
Algoritmo de optimización metaheurística que elige en cada paso una solución local
óptima. Son algoritmos sencillos de programar y rápidos, pero poco fiables.
• ILP: "Integer Linear Programming"
• MPP: "Mathematical Programing Problem"
• SAP: "Swath Acquisition Problem"
• SaVoir: "Swath Acquisition Viewer"
Herramienta visual de planificación y optimización usada para la gestión de EOSs.
Desarrollada por Taitus Software.
1
1 Introducción
1.1 Marco Global "Earth Observation Satellites" (EOSs) forman una clase de satélites geocéntricos cuya
función es recopilar datos terrestres para diversos fines, usando tecnología de detección
avanzada. Estos datos se usan en una gran variedad de disciplinas tales como cartografía,
meteorología, oceanografía, geodesia o ciencias atmosféricas, entre otras. El uso de esta
clase de satélites está evolucionando rápidamente y están surgiendo nuevas aplicaciones:
detección de incendios, gestión de crisis o identificación de zonas pesqueras. Por estas
razones, los EOSs se están convirtiendo en una importante herramienta de estudio e
inspección global del planeta Tierra. Hoy en día muchos países y compañías de todo el
mundo se encuentran implicadas de manera activa en el desarrollo de esta clase de
satélites y sus aplicaciones. Sin embargo, a pesar del crecimiento de la flota de satélites
tipo EOSs, su número no es suficientemente grande para satisfacer la cada vez más
creciente necesidad a nivel mundial de recopilación de datos terrestres. En consecuencia,
las misiones de los EOSs deben ser planificadas de forma eficiente para maximizar su
rendimiento.
Actualmente, la mayoría de las actividades de detección remota requieren una
coordinación manual de la flota de satélites y planificadores de misión o algoritmos de
programación (Bibliografía [2], [6] y [8]). Sin embargo, el número existente de EOSs y
la demanda de mejora en los tiempos de observación, está provocando que la
coordinación manual de las actividades de los EOSs esté llegando a ser inviable. Los
datos de observación deben ser procesados mediante algoritmos automáticos de
planificación, los cuales seleccionan y planifican el rendimiento de aquellos conjuntos
de subsatélites que proporcionan el máximo beneficio (éste dependerá del criterio
seleccionado en cada misión concreta) bajo restricciones operativas, tales como la
disponibilidad del satélite, restricciones térmicas o de potencia, capacidad de datos,
nubes, restricciones de duty cycle y el tiempo limitado que permanece cada satélite
sobre la región de interés.
2
Este problema tradicionalmente ha sido estudiado para el caso de un sólo satélite. No
obstante, hoy en día las operaciones relacionadas con la observación terrestre se están
enfocando hacia una planificación multisatélite, buscando tiempos más cortos de
observación. Planteando el problema de esta manera conjunta, en donde una serie de
requisitos deberán ser satisfechos por todos aquellos satélites pertenecientes a una
misma constelación o incluso a diferentes misiones en cada una de sus revoluciones
alrededor de la superficie terrestre, no es posible desacoplar el problema por órbita o
satélite. La planificación y optimización deberá ser realizada simultáneamente para
todos los satélites y órbitas consideradas.
Se debe tener en cuenta que muchas misiones requieren una rápida decisión y gestión
(por ejemplo, asistencia humanitaria o evaluación de daños) o bien existe un flujo de
datos que se modifica rápidamente (debido a nubes, por ejemplo). De esta manera, los
algoritmos de planificación deberán encontrar (idealmente) la solución óptima en
tiempo real (o casi real). Teniendo en cuenta el número de satélites operativos, el
número total de observaciones que son capaces de ejecutar, así como el número de
restricciones y opciones existentes para cada observación, los problemas de
planificación en aplicaciones derivadas del uso de satélites tipo EOSs podrían llegar a
convertirse en problemas largos y costosos (tanto económica como
computacionalmente). Los algoritmos que proporcionan soluciones exactas son "lentos"
y los heurísticos (algoritmos que proporcionan una solución óptima o casi óptima en
tiempos de ejecución cortos) "más rápidos". Haciendo uso de las nuevas técnicas
matemáticas para el manejo de datos y cálculos en paralelo, estos algoritmos son
capaces de encontrar una solución casi-óptima de manera rápida.
La Figura 1.1 y la Figura 1.2 son ejemplos generados con SaVoir ("Swath Acquisition
Viewer"; herramienta visual de planificación y optimización usada para la gestión de
EOSs, desarrollada por Taitus Software).
En estos ejemplos , la región de interés a cubrir es Italia y se puede observar como las
adquisiciones provenientes de diferentes satélites (franjas naranjas) se solapan entre sí
(franjas naranja oscuro), generando imágenes redundantes. La Figura 1.1 corresponde al
caso de una solución no óptima, formada por adquisiciones generadas automáticamente
usando un algoritmo simple de "máxima cobertura" y sin memoria. Esto implica que en
cada iteración se escoge aquella adquisición que aporta la mayor cobertura sobre la
3
región de interés, sin tener en cuenta las subregiones cubiertas por las adquisiciones
anteriores. Esta falta de memoria hace que cada adquisición se plantee
independientemente de las demás, lo cual genera solapamientos entre adquisiciones lo
que implica información (adquisiciones) redundantes. SaVoir selecciona la mejor
posición de sensor en cada pasada de cada satélite sobre la región de interés para
maximizar la cobertura. El problema de no existir memoria, aparte de obtener
información redundante proveniente de los solapamientos, es que no siempre se
consigue una cobertura completa de la región de interés.
Figura 1.1 Ejemplo de solución no óptima generada por SaVoir
4
Figura 1.2 Ejemplo de solución optimizada usando una aproximación heurística de dos pasos con
SaVoir
Por contra, la Figura 1.2 muestra una estrategia de cobertura usando el mismo
procedimiento que el llevado a cabo en la Figura 1.1 pero esta vez usando memoria; es
decir, en cada iteración, se escoge aquella adquisición que mayor cobertura tiene sobre
aquellas subregiones pertenecientes a la región de interés que aún no han sido cubiertas
por adquisiciones anteriores. Esto produce una solución con menores adquisiciones pero
no necesariamente será la mejor elección (en tiempo, cobertura, coste o combinación de
estos criterios). Resaltar que los ejemplos mostrados en la Figura 1.1 y la Figura 1.2
representan casos extremos y artificiales para mostrar la amplitud del problema
considerado, dado que SaVoir realiza un tratamiento más optimizado del problema de
planificación EOSs.
Esta formulación del Swath Acquisition Problem (SAP) observada en la Figura 1.2
implica una gestión de multisatélites y constelaciones como un problema de
programación matemática y propone el uso de algoritmos heurísticos como
procedimiento para obtener una solución factible. Los procesos actuales de resolución
del SAP están basados en simples enumeraciones de las soluciones posibles, los cuales
5
consumen demasiado tiempo de computación, principalmente cuando se consideran
diferentes criterios o prioridades sobre los satélites. Por otra parte, las restricciones
generadas por duty cycle (período de tiempo durante el cual, el satélite puede llevar a
cabo la toma de adquisiciones) y por otras de naturaleza dinámica (tales como baterías o
capacidad de descarga de datos) no se suelen incorporar dentro del proceso o modelo de
optimización. En consecuencia, los resultados obtenidos en los procesos existentes de
optimización pueden estar lejos del óptimo real. Sin embargo, si estas restricciones
dinámicas no son relevantes, el desarrollo adecuado de métodos matemáticos robustos
de optimización pueden generar estrategias de resolución factibles para abordar el
problema SAP.
1.2 Estructura General del Proyecto
En este proyecto se presenta un estudio preliminar del problema de planificación EOSs.
Se darán formulaciones de los modelos matemáticos que describen este problema en
tres situaciones de complejidad creciente. Así mismo, se desarrollarán algoritmos
heurísticos para resolver el problema y se llevarán a cabo una serie de experimentos
para comparar los resultados de los heurísticos con las soluciones óptimas. El objetivo
final de este proyecto será fijar las bases para el diseño e implementación de una
herramienta en tiempo real para la planificación de EOSs, la cual deberá incluir
algoritmos de optimización para misiones y constelaciones múltiples, capaces de
trabajar con restricciones operacionales realistas. Dicha herramienta será integrada en el
futuro en la herramienta de simulación orbital SaVoir (Taitus 2011), aunque dicha
integración queda fuera del alcance del presente proyecto.
Una de las ventajas de usar SaVoir es que su motor visual implementa algoritmos de
geometría computacional que puede calcular (como se vio en la Figura 1.1 y Figura 1.2)
las subregiones en las cuales es dividida la región de interés a causa de las diferentes
adquisiciones tomadas por el conjunto de satélites usados, así como conocer qué
subregiones cubre una adquisición concreta. Estos cálculos se realizan a través de la
integración de las capacidades GIS y el uso de una geometría 3-D. Los algoritmos
geométricos trabajan directamente en 3-D para evitar las singularidades inherentes en
6
las proyecciones bidimensionales, de tal manera que se podría llevar a cabo el estudio
de cualquier región sobre la superficie terrestre sin restricciones.
Finalmente, en la Sección 7 se describen todos los códigos generados, los cuales han
sido implementados íntegramente en MATLAB.
7
2 Formulación de SAP como un problema de programación lineal
2.1 Metodología de Resolución
La aproximación hacia un algoritmo eficiente y óptimo para resolver el problema de
planificación EOSs puede ser resumido en 4 pasos:
1. Formulación del problema mediante un conjunto de restricciones matemáticas
adecuadas, lo cual nos permitirá el uso de algoritmos de optimización estándar.
Se desarrollaron varios modelos de complejidad creciente:
• q-satélites con sensor fijo: los satélites sólo pueden tomar
adquisiciones del área de interés usando un único modo (ángulo) de
sensor; por simplicidad, se toma como ángulo fijo aquél que forma
90º con el vector tangente a la órbita del satélite y en dirección a la
superficie terrestre. La formulación de este modelo se llevará a cabo
en la Sección 2.3.2.1.
• q-satélites con sensor variable: el sensor de cada satélite puede variar
dentro de un cierto rango para tomar adquisiciones desde diferentes
ángulos; sin embargo, no podrán variar dicho ángulo durante una
pasada dada, pero sí en la siguiente. Este modelo es más realista que
el modelo I debido a que los satélites EOSs poseen la capacidad de
captar imágenes desde diferentes direcciones a través de la variación
de sus sensores. La formulación de este modelo se llevará a cabo en
la Sección 2.3.2.2.
• q-satélites con sensor fijo y duty cycle: en este modelo se introducen
las restricciones operativas provocadas por el duty cycle. La
resolución de este modelo se escapa del alcance de este proyecto,
debido a su complejidad matemática. No obstante, se mostrará un
8
posible planteamiento matemático para abordarlo. Dicha formulación
se describe en la Sección 2.3.2.3.
Se dejará como trabajo futuro la formulación de un cuarto modelo "realista", en
el cual se considerarían flotas de EOSs con sensor variable y se tendrían en
cuenta restricciones de duty cycle así como otras de naturaleza dinámica (tales
como baterías o capacidad de descarga de datos).
2. Resolución del problema de geometría computacional, lo cual implica computar
las intersecciones entre las adquisiciones de los satélites y la región de interés
(es decir, las subregiones en que queda dividida la región en estudio). Estas
intersecciones no son difíciles de calcular para los modelos más simplificados,
pero su complejidad aumenta considerablemente conforme aumentamos la
complejidad del modelo. En estos casos, se propondrán algoritmos rápidos y
eficientes, capaces de manejar regiones complejas, posiblemente no convexas y
con agujeros.
El problema de geometría computacional puede ser resumido en el cálculo de
todas las subregiones generadas por las intersecciones de las adquisiciones de los
satélites con la región de interés. Basándonos en estas intersecciones, se creará
una matriz Q en dos pasos, aumentando su complejidad a la vez que su utilidad
dentro de los algoritmos de optimización:
• Matriz Q-2D, cuyas entradas (i, j) tomarán el valor "1" cuando la
subregión i es cubierta por la adquisición j y "0" en caso contrario. El
problema de usar esta matriz es que en el caso de variar la posición del
sensor (modelo II, ver Sección 2.3.2.2), no tendremos información
directa (aunque sí de manera indirecta) de cuál es la posición del sensor
en un determinado satélite que cubre una determinada subregión.
• Matriz Q-3D, cuyas entradas (i, j ,k) tomarán el valor "1" cuando la
subregión i sea cubierta por el satélite j usando una posición de sensor k,
y "0" en caso contrario. Esta matriz Q será la que se usará en los
algoritmos heurísticos de optimización descritos en la Sección 3.
9
3. Implementación de algoritmos de optimización heurísticos y exactos a partir de
la matriz Q obtenida en el paso 2. Ya que dichos algoritmos de optimización
trabajarán con esta matriz, se deduce que una correcta resolución del problema
de planificación dependerá de la exactitud y eficacia en el cálculo de la matriz Q.
Dada la complejidad del problema y la necesidad de obtener soluciones en
tiempo real, el uso de algoritmos exactos (que utilizan optimizadores como
CPLEX, por ejemplo) no es, en general, factible. Descartado el uso de
algoritmos exactos para la resolución del SAP, se desarrollarán los siguientes
algoritmos heurísticos:
• GREEDY: también denominado algoritmo voraz, es un algoritmo
heurístico que consistente en elegir en cada paso el elemento que
mejora más una cierta función objetivo con la esperanza de llegar a
una solución general óptima. El desarrollo del GREEDY será el paso
previo para obtener un algoritmo GRASP.
• GRASP: por sus siglas en inglés "Greedy Randomized Adaptive
Search Procedures" (Bibliografía [4]). Amplía el concepto del
método GREEDY, de tal manera que en lugar de elegir en cada
paso el elemento que mejora más una cierta función objetivo,
forma un conjunto con los mejores k elementos candidatos para
después elegir uno de ellos aleatoriamente y ser parte de la
solución. Este método será el algoritmo heurístico a implementar
para obtener una solución óptima al problema de planificación
EOSs. Notar que si k=1, el GRASP resultante es un GREEDY.
Estos algoritmos nos permitirán obtener una solución factible en períodos de
tiempo reducidos. No obstante, la calidad de los resultados obtenidos mediante
estos algoritmos heurísticos debe ser corroborada con algoritmos que
proporcionen una solución exacta. Con esta finalidad, se computarán soluciones
óptimas encontradas a través de CPLEX. Finalmente, a través de la comparación
entre las soluciones heurísticas y exactas podremos extraer una idea de cuál es la
pérdida (en términos de costes) cuando se usan los métodos heurísticos
10
4. Integración de los algoritmos de planificación en la herramienta SaVoir: una vez
que el problema ha sido modelado y resuelto, el desarrollo de los algoritmos
debe ser integrado en una herramienta de simulación visual, fácilmente
manejable por el usuario. Dicha herramienta deberá permitir seleccionar un
conjunto de satélites reales, una región de interés a estudiar, un índice de costes
y un conjunto de restricciones, y devolver una solución óptima o casi óptima del
conjunto de adquisiciones en tiempo real. La herramienta usará propagadores de
órbitas en los satélites a partir de elementos orbitales, resolviendo los problemas
de geometría computacional involucrados y aplicando los algoritmos heurísticos
previamente desarrollados en el paso 3 para encontrar una buena solución.
La herramienta más indicada para llevar a cabo la implementación de estos
algoritmos es SaVoir, debido a que reúne una serie de requisitos que no poseen
otras herramientas desarrolladas con propósitos similares:
• Fácil de usar
• Coste reducido en comparación con otras soluciones del mercado
• Tiene implementado un motor de geometría computacional que
se puede usar para calcular la matriz Q explicada en el paso 2.
Para aclarar la metodología a seguir, la Figura 2.1 que se muestra a continuación
esquematiza el proceso de resolución.
11
Figura 2.1 Metodología de Resolución de SAP
2.2 Simplificaciones y Alcance del proyecto
En este proyecto se pretende desarrollar los dos primeros modelos mostrados en la
Sección 2.1, considerando que las restricciones de duty cycle que lleva implícita la
resolución del tercer modelo (q-satélites con sensor fijo y duty cycle) escapan del
alcance de dicho proyecto por su complejidad matemática a la hora de implementarlo en
lenguaje de programación. Los cálculos de geometría computacional se llevarán a cabo
usando un toolbox de MATLAB (Polygon Clipper, a través de la función PolygonClip)
el cuál será desarrollado en la siguiente Sección 2.4. Este toolbox hace un tratamiento
simplificado en la forma de las adquisiciones tomadas por los satélites, considerándolas
como polígonos sobre la superficie terrestre. Esta simplificación está justificada porque
Formulación Matemática Problema
de Planificación de EOSs
Resolución Problema de Geometría
Computacional
Implementación Algoritmos Heurísticos
Integración en Herramienta Visual
SaVoir
12
la órbita que describen los EOSs son órbitas heliosíncronas casi polares, cuyas huellas
se pueden aproximar como polígonos sobre la superficie terrestre; por tanto, se ignora la
mecánica orbital y se evita el uso de propagadores de órbitas que aumentarían la
complejidad del problema. La elección de usar Polygon Clipper en vez de SaVoir se
hizo por varias razones:
• Polygon Clipper es una herramienta intuitiva y fácil de usar.
• En este proyecto, la resolución del problema de planificación EOSs se ha
realizado íntegramente a través de la programación en MATLAB. Utilizar
SaVoir implica programar en código C++.
• La implementación de un algoritmo de resolución al problema de planificación
EOSs en SaVoir está planteado como paso final en la metodología de resolución
(ver Sección 2.1). Este algoritmo deberá resolver un modelo realista, no
formulado en este proyecto, en el cuál se trate un problema con restricciones y
se consideren satélites con sensor variable.
Finalmente se desarrollarán algoritmos heurísticos (GRASP) para la resolución del
problema, comparando sus resultados con soluciones exactas. Esta comparativa nos dará
una idea de cómo de fiable es nuestra resolución del problema de planificación a través
de dichos algoritmos heurísticos (Sección 4.2).
2.3 Formulación del Problema de Planificación EOSs En esta sección se introducen los conceptos matemáticos usados en los modelos de
planificación EOSs, que ayudarán a describir el problema introducido en las secciones 1
y 2.1. Se comenzará definiendo aquellos conceptos que juegan un papel importante en
nuestro modelo.
Seguidamente se formularán los modelos matemáticos que describen el problema de
planificación, para lo cual se plantearán 3 modelos de complejidad creciente,
introducidos brevemente en el paso 1 de la Sección 2.1:
13
• Modelo I: modelo más simplificado del problema. Se usarán satélites con sensor
fijo. Este modelo trata de clarificar el problema de formulación de programación
lineal.
• Modelo II: extensión del modelo I en el cual se usan satélites cuyo sensor es
variable.
• Modelo III: se consideran las restricciones de duty cycle (por lo cual, los
sensores sólo pueden ser usados durante un período limitado de tiempo) así
como satélites con sensores fijos.
Este último modelo no será resuelto; sólo se planteará su formulación como un
problema de programación matemática, debido a que por su complejidad, escapa del
alcance y objetivos de este proyecto.
2.3.1 Enunciado del Problema y Notación
Para formular el problema de planificación de EOSs, se definen los siguientes conceptos:
• ℜ es la región de interés, es decir, la superficie terrestre que queremos cubrir.
No se hace ninguna hipótesis sobre la forma de ℜ , es decir, esta formulación es
válida para cualquier tipo de región de interés que se desee estudiar.
• T es la franja de tiempo en la que se plantea el problema de planificación. T es
un intervalo [ FTT ,0 ], siendo 0T el tiempo inicial y FT el final.
• S es el conjunto de satélites considerados en el problema de planificación. Para
evitar hacer uso de propagadores de órbitas, se asume que la posición de cada
satélite de S es conocida y que puede ser calculada con suficiente precisión para
cada instante de tiempo en T.
14
• Para cada satélite Ss∈ , SP es el conjunto de posibles posiciones de ángulo del
sensor de cada satélite s.
• Dado un satélite Ss∈ , una posición de sensor SPp∈ y un intervalo de tiempo
[ 10,tt ], una adquisición ( )10,,, ttpsa es definida como la superficie terrestre
cubierta por la traza del satélite s durante el período de tiempo [ 10,tt ] en su
posición de sensor p. Se define también el coste de la adquisición a como 0>ac .
• A es el conjunto de todas las adquisiciones posibles dadas por el conjunto de
satélites, sus posibles posiciones de sensor y dentro de la franja temporal T,
( ) [ ]{ }TttPpSsttpsaA S ⊂∈∈:= 10,10 ,,,,, .
• Subregiones SR: la intersección del conjunto de adquisiciones A con la región de
interés ℜ define un conjunto de subregiones cuya unión es igual a la región de
interés ℜ . Así mismo, iSR es la subregión i contenida en la región ℜ .
Basándonos en estos conceptos, definiremos la admisibilidad de las adquisiciones para
el problema de planificación de EOSs. Diremos que una selección de n adquisiciones
( ){ } Anittpsa iiiii ⊂= ,...,1,,,, 10 es admisible si:
1. Cada satélite s en la selección no se usa más de una vez en un mismo instante de
tiempo, es decir:
[ ] [ ] φ=∩⇒==∀ jjiiji ttttssnji 1010 ,,,,...,1, .
2. Si escogemos un satélite s de la selección más de una vez con diferentes
posiciones de sensor, se necesitará un período de tiempo Stp∆ para cambiar su
posición de sensor, es decir:
[ ] [ ] φ=∆+∩∆+⇒≠==∀ jjj
iii
jiji tptttpttppssnji 1010 ,,,,,...,1, .
3. Profundidad de la cobertura, jd : si una subregión de ℜ , jSR , es especialmente
relevante, es aconsejable llevar a cabo más de una adquisición. El parámetro jd
15
es un número entero no-negativo, que permite tomar más de una adquisición de
regiones "especialmente interesantes". Permite también incluir regiones con un
valor de 0=jd , lo cual significaría que se trata de regiones "sin interés" y por
tanto no sería necesario realizar adquisiciones de las mismas.
4. Restricciones de duty cycle: para cada satélite s existe un conjunto de Sn
subintervalos, Sn
SS
sTTT ,...,, 21 , tal que TT S
jnjS =∪ =1 , y un número
[ ]100,0∈SSLOT tal que s puede ser usado en cada SiT solamente durante un
porcentaje SLOT de tiempo, es decir:
[ ]( ) )(,,,...,1 10Sjs
SS
Sj
iis TlengthSLOTTttlengthnjs
i
≤∩=∀∀ ∑=
,
donde ( )100
sSLOTlength = .
Con esta notación, nos encontramos en posición de formular el problema de
planificación EOSs como sigue:
"Encontrar una selección óptima de adquisiciones admisibles
},...,1,]),[,,({ 10 niAttpsa iiiii =∈ , tal que i
ni a1=⊂ℜ U . Si alguna de las subregiones
jSR se encuentran marcadas como "no relevante" a través del parámetro de
profundidad de cobertura 0=jd , la última condición debería ser cambiada por
inijdj aSR
j 10: =≠ ⊂ UU ".
En este trabajo la selección se considerará óptima si minimiza una cierta función
objetivo }),...,({ 1 naaF . F puede tener diferentes definiciones en función del
objetivo perseguido, por ejemplo:
• nF = (minimiza el número total de adquisiciones posibles)
• ∑ == n
i aicF
1 (minimiza el coste de las adquisiciones)
• ini tF 1,...,1max== (minimiza el instante en que se cubre toda la región ℜ )
16
• Una combinación de las anteriores
Alternativamente, el objetivo podría ser maximizar la superficie cubierta, imponiendo
requerimientos de tiempo, costes, etc.
2.3.2 Formulación de Modelos
2.3.2.1 Modelo Simplificado I: q-satélites y sensor fijo
El primer modelo a estudiar implica el uso de q-satélites con sensor fijo, sin
restricciones de duty cycle; ello implica que pueden ser usadas las adquisiciones
completas de los satélites, siendo el conjunto de adquisiciones un conjunto finito cuyas
intersecciones con la región de interés ℜ generará un cierto número de subregiones
sobre dicha región. En este caso, dado un tiempo máximo de operación maxT , se
considerará una franja de tiempo ],0[ maxT . El objetivo será seleccionar el conjunto de
adquisiciones que durante el intervalo de tiempo permitido cubran la región ℜ con el
mínimo coste posible.
Sean naa ,...,1 el conjunto de posibles adquisiciones, obtenidas en este orden conforme
aumenta el tiempo de operación. Entonces, na será la última adquisición en poder ser
usada, lo que significa que 1+na ocurriría después de maxT . El tiempo en el cual la
adquisición ia comienza a escanear la región ℜ y el tiempo en el cual termina de
escanear dicha región, 0it y 1
it respectivamente, son conocidos y por tanto serán datos de
entrada. Notar que para que el modelo tenga coherencia, necesitamos asumir que
ittttt iiiii ∀≥≤≤ + 0,, 001
010 , así como max1 Ttn ≤ .
Como ejemplo simplificado de esta situación, consideremos el caso mostrado en la
Figura 2.2.
17
Figura 2.2 Ejemplo simplificado de SAP
La región de interés ℜ aparece como el rectángulo rojo y las cuatro posibles
adquisiciones },,,{ 4321 aaaa son los demás rectángulos de color mostrados en dicha
figura.
Se podría pensar en un algoritmo simple, el cual escogería primero la adquisición 1a
para cubrir una cierta área de la región ℜ . Iterativamente, se irían escogiendo las
adquisiciones 2a , 3a y 4a progresivamente, para ir cubriendo nuevas áreas de la región
ℜ que aún no han sido cubiertas por las adquisiciones anteriores. Con este proceso, las
cuatro adquisiciones son necesarias para cubrir toda la región de interés ℜ . Se puede
observar como la adquisición 1a es redundante y no debería aparecer en la solución
óptima, es decir, con las adquisiciones 2a , 3a y 4a se cubre toda la región de interés.
Notar que este ejemplo ha sido introducido sólo para mostrar que algunas
aproximaciones o soluciones aportarían una solución factible (si existen suficientes
adquisiciones disponibles), pero la mejor u óptima solución no sería obtenida.
18
Con la finalidad de resolver el problema óptimamente, se formulará como un problema
de programación matemática (MPP, por sus siglas en inglés). Para una completa y
exhaustiva introducción a este tipo de problemas, consultar Bibliografía [1] y [11].
Sea ix una variable binaria (sólo puede tomar valor "0" ó "1") que expresa si la
adquisición ia es usada ( 1=ix ) o no ( 0=ix ) y sea ic el coste de usar dicha adquisición
ia ( 0>ic ). Entonces, el problema de planificación EOSs puede ser formulado como:
nix
aas
xc
i
ixi
i
n
ii
i
,...,2,1},1,0{
..
min
1:
1
=∀∈
ℜ⊃=
=∑
U(1)
Notar que este problema puede ser no factible. Si existiese una subregión de ℜ no
cubierta por ninguna adquisición disponible, entonces la restricción de (1) nunca podría
ser satisfecha. Para poder obtener una solución al problema (1), se modelará como un
problema de programación lineal entera (ILP, Integer Linear Programming; consultar
Bibliografía [1] y [11]). De este tipo de problemas se extrae que las restricciones de (1)
deben ser expresadas como restricciones lineales. A continuación, se mostrará como se
llevará a cabo.
Sean },...,{ mi SRSR las subregiones en las cuales ℜ es dividida considerando todas las
intersecciones de las adquisiciones ia con ℜ y entre ellas mismas. A partir de este
conjunto de subregiones, obtendremos una matriz Q, cuyas entradas ijq tomarán el valor
"1" si la subregión jSR es cubierta por la adquisición ia , y "0" en caso contrario. Con
esta nueva matriz, el problema (1) puede ser formulado como:
19
nix
mjdqxas
xc
i
j
n
iiji
i
n
ii
,...,2,1},1,0{
,...,1..
min
,1
1
=∀∈
=∀≥∑
∑
=
=
(2)
Observando esta formulación del problema, vemos como en las restricciones de (2) se
han incluido las restricciones de profundidad de cobertura, forzando a cada subregión
jSR a ser cubierta por al menos jd adquisiciones diferentes )( +Ζ∈jd .
Aplicando nuestro modelo ILP (2) al ejemplo mostrado en la Figura 2.2, comprobamos
que algunas de las adquisiciones no son necesarias para cubrir ℜ . Consideraremos que
todos los costes son iguales, y por lo tanto, por la linealidad del problema, podemos fijar
el valor a 1=ic para todo 4,...,1=i . En este ejemplo, la región de interés ℜ es
subdividida en 16 subregiones como se ve en la Figura 2.3.
Figura 2.3 Subregiones generadas en ℜ por la intersección de las adquisiciones
20
La matriz Q resultante es:
=
0010
0100
0110
0110
0111
1000
1000
1001
0010
1010
1100
1100
1101
1110
1110
1111
Q
Aclaremos el significado de las filas y columnas de la matriz Q. La primera fila indica
que la subregión 1SR es cubierta por todas las adquisiciones },,,{ 4321 aaaa mientras
que por ejemplo, la fila 16 indica que la subregión 16SR es solamente cubierta por la
adquisición 2a .
Por otro lado, la primera columna, por ejemplo, indica que la adquisición 1a cubre las
subregiones 1SR , 4SR , 9SR y 12SR .
Destacar que la matriz Q puede ser simplificada expresando todas las filas que son
iguales a través de una única fila (lo cual implica unir las correspondientes subregiones).
De la misma forma, este proceso puede realizarse con las columnas. Observando las
filas de la matriz, observamos como las filas 2/3, 5/6, 8/16 10/11 y 13/14 son iguales
entre sí, lo que significaría, por ejemplo, que las subregiones 13SR y 14SR son cubiertas
por los mismos satélites, y por lo tanto, podrían ser tratadas como una única subregión.
De esta manera, el tamaño del problema (2) se podría llegar a reducir de manera
considerable. No obstante, se lleve a cabo o no esta reducción del problema, existe aún
una cuestión abierta, relativa a si se puede calcular siempre la matriz Q.
21
La complejidad computacional de la matriz Q podría llegar a convertirse en un cuello de
botella del algoritmo, siendo mayor que incluso el propio problema ILP; por lo tanto, se
deduce que es necesaria una implementación eficiente de las operaciones de geometría
computacional (unión, intersección y substracción). Además, debería introducirse un
sistema de valoración de las subregiones a cubrir, es decir, un sistema que sea capaz de
despreciar aquellas subregiones cuya área sea menor que un cierto valor. Este sistema
de valoración de las subregiones ha sido implementado en los códigos desarrollados
(ver Sección 7.1).
Fijando jd j ∀= 1 , la solución al problema (2) con los datos del ejemplo es
1,0 4321 ==== xxxx , lo cual significa que, como se anticipó, la adquisición 1a no es
necesaria para cubrir el área de interés ℜ .
2.3.2.2 Modelo Simplificado II: q-satélites y sensor variable
Suponemos que los satélites poseen un sensor variable, es decir, el ángulo del sensor
puede cambiar respecto a la perpendicular a la superficie terrestre en un cierto rango,
con la finalidad de obtener mejores adquisiciones de la región de interés. En este
modelo, suponemos que el modo (ángulo) del sensor del satélite puede ser variado en
cada revolución, pero debe mantenerse en dicho modo durante el período de tiempo en
el cual se encuentra escaneando la región de interés. También se asume que el sensor
posee K posibles modos discretos (típicamente )256≤K , llevando a cabo una
simplificación del modelo en el cuál se establece que todos los satélites posean el
mismo número de posiciones de sensor. El anterior modelo simplificado (2) puede ser
fácilmente adaptado a este caso añadiéndole a cada variable un superíndice k (que
especifica el modo) y el conjunto de restricciones que evitan cambiar dicho modo a lo
largo de una misma adquisición. Por lo tanto, sea kix una variable binaria, que toma el
valor "1" si la adquisición i es tomada con el sensor en posición k y "0" en caso
contrario. Ahora se deberán construir las subregiones de ℜ teniendo en cuenta que a lo
largo de todas las revoluciones de los satélites, se generarán K adquisiciones por satélite.
La matriz Q ahora se convertirá en tridimensional, cuyas entradas kijq tendrán valor "1"
22
si la subregión jSR puede ser fotografiada (cubierta) por la adquisición ia usando su
thk posición de sensor, y tomarán un valor "0" en caso contrario.
Como consecuencia de todo lo anterior, el problema (2) se transforma en:
Kknix
nix
mjdqxas
xc
ki
K
k
ki
K
kj
n
i
kij
ki
ki
K
k
n
ii
,...,2,1,,...,1},1,0{
,...,1,1
,...,1,..
min
1
1 1
1 1
=∀=∀∈
=∀≤
=∀≥
∑
∑∑
∑∑
=
= =
= =
(3)
El primer conjunto de restricciones de (3) establece que todas las subregiones deben ser
cubiertas por al menos una adquisición en alguno de sus posibles modos de sensor. El
segundo conjunto de restricciones fuerza a que una misma adquisición no pueda ser
usada en más de una posición, es decir, una vez seleccionada una adquisición con un
determinado modo de sensor (en un satélite concreto), el resto de las adquisiciones
obtenidas por ese mismo satélite pero usando posiciones de sensor diferentes a la
seleccionada en la adquisición, deben ser eliminadas o no consideradas en el problema
(3).
Para dar una idea de la magnitud del problema, consideremos un ejemplo en el que
tenemos 10 satélites, con 5 posiciones de sensor y un paso de 1 entre modos de sensor
contiguos (distancia entre adquisiciones contiguas para un mismo satélite, en unidades
de longitud). El total de las adquisiciones a considerar en el problema se puede observar
en la Figura 2.4, donde el rectángulo rojo representa el área de interés ℜ . El número
total de adquisiciones es de 50 (10 satélites con 5 modos de sensor posible).
23
Figura 2.4 Ejemplo adquisiciones generadas por 10 satélites y 5 posiciones de sensor
Así mismo, en la Figura 2.5 se muestra el conjunto de subregiones generadas por las
intersecciones de las 50 adquisiciones con la región de interés, donde por claridad en el
dibujo, no se han numerado. En total, en este problema de planificación EOSs se
deberán cubrir 525 subregiones con las restricciones definidas en (3).
24
Figura 2.5 Ejemplo subregiones generadas por 10 satélites y 5 posiciones de sensor
La matriz Q generada en este ejemplo es una matriz tridimensional de tamaño 10x525x5.
A continuación, se muestra un extracto de dicha matriz:
q(1,1,1)=1
q(1,1,2)=1
q(1,1,3)=0
q(1,1,4)=0
q(1,1,5)=0
q(2,1,1)=1
q(2,1,2)=1
q(2,1,3)=1
q(2,1,4)=1
q(2,1,5)=0
q(3,1,1)=0
q(3,1,2)=0
q(3,1,3)=0
q(3,1,4)=0
25
q(3,1,5)=0
Destacar que los índices de esta matriz Q (generada por MATRIZQVAR; ver código y
estructura en la Sección 7.1) cambian de significado respecto a lo explicado en
secciones anteriores. Ahora, cada elemento (i, j, k) tendrá valor "1" si el satélite i cubre
la subregión j en su posición de sensor k. Siguiendo esta notación, la segunda
componente q(1,1,2)=1 indica que la subregión 1 es cubierta por el satélite 1 en su
modo de sensor 2, mientras que la última componente de este extracto de la matriz Q,
q(3,1,5)=0, implica que la subregión 1 no es cubierta por el satélite 3 cuando usa un
modo de sensor 5.
2.3.2.3 Modelo con Restricciones I: q-satélites, sensor fijo y restricciones de duty cycle
En este modelo se asume que cada adquisición ia sólo puede usarse por un período
limitado de tiempo, iSLOT . Ahora, las variables son función del tiempo y las
restricciones se convierten en integrales y sumas.
tix tomará el valor "1" si la adquisición ia es usada en el instante t y "0" en caso
contrario, así como tiyq será "1" si la adquisición ia puede fotografiar el punto ℜ∈y en
el instante t. Este problema entraña mucha mayor complejidad que los dos modelos
anteriores, debido a que ahora tenemos que buscar funciones en lugar de sólo valores de
variables. Con todo esto, este modelo se formula de la siguiente forma:
],0[,,...,1},1,0{
],0[,)(
1
,0
,...,1,..
min
max
max
1
1
1
0
1
0
1
0
Ttnix
TtxdyqA
ydtq
niSLOTdtxas
dtxc
ti
ti
tyi
n
i
t
t
tyi
i
t
t
ti
n
i
t
t
tii
i
i
i
i
i
i
∈∀=∀∈
∈∀≤ℜ
ℜ∈∀>
=∀≤
∫
∑∫
∫
∑ ∫
ℜ
=
=
(4)
26
El primer conjunto de restricciones de (4) asegura que cada adquisición se usa no más
de su tiempo límite. El segundo conjunto de restricciones de (4) fuerza a que cada punto
de la región de interés (ℜ ) sea cubierto por al menos una adquisición en al menos un
intervalo de tiempo no degenerado. Notar que de esta manera, evitamos la paradoja de
adquirir sólo un conjunto finito de instantes, teniendo completamente escaneada el área
de interés con un coste nulo. El tercer conjunto de restricciones de (4) indica que si un
punto ℜ∈y ha sido cubierto por la adquisición ia en el instante de tiempo t, entonces
tix deberá ser igual a "1" ( )(ℜA es el área de ℜ ).
2.4 Herramienta de Geometría Computacional
Como paso previo antes de formular matemáticamente el problema de planificación, se
presenta en esta sección una descripción breve de la herramienta seleccionada para
realizar los cálculos de geometría computacional. En el paso 2 de la Sección 2.1, se dejó
entrever la necesidad de disponer de una herramienta capaz de computar las subregiones
en que queda dividida la región de interés debido a su intersección con las diferentes
adquisiciones de los satélites.
Se optó por el uso del toolbox de Matlab denominado Polygon Clipper. Se ha elegido
esta herramienta por las siguientes razones:
• Herramienta intuitiva y fácil de manejar.
• Gratuita (teniendo licencia de MATLAB).
• Implementa una gran diversidad de operaciones de geometría computacional:
operaciones de unión y diferencia, cálculo de áreas, posibilidad de usar zonas
con agujeros, etc.
La función de geometría computacional usada por esta herramienta posee la siguiente
estructura:
).,,( 21 índiceSSppolygoncliA =
27
1S y 2S corresponden a los polígonos sobre los cuales queremos realizar la operación
geométrica y el campo índice expresa la operación geométrica que queremos llevar a
cabo (diferencia, unión, intersección,...).
Los polígonos que actúan como argumentos de entrada en la función se deben expresar
de la siguiente manera:
),,""],[,""],[,"(" iholeSySxstructS YXi =
donde ][ XS y ][ yS representan las coordenadas X e Y de los vértices del polígono,
respectivamente. Destacar que dichas coordenadas deben ser introducidas en forma de
vector y recorriendo los vértices del polígono en sentido antihorario. El campo hole
hace referencia a si el polígono posee un agujero (en cuyo caso i=1) o no (i=0).
En todos los cálculos de geometría computacional desarrollados a lo largo de este
proyecto se han considerado polígonos llenos (sin agujeros) por simplicidad; por lo
tanto, el campo hole se considerará fijado a "0".
Como se ha comentado antes, el campo índice en la función polygonclip permite
escoger la operación geométrica que vamos a aplicar sobre los polígonos de entrada a la
función. Este índice puede tomar valores comprendidos entre "0" y "3". Las figuras
siguientes muestran la correspondencia entre cada valor del índice y la acción
geométrica llevada a cabo sobre los polígonos originales (rojo y azul), siendo los
polígonos en verde el resultado de dicha operación:
28
Figura 2.6 Polígonos sobres los que se aplican las operaciones geométricas
29
• "0" (Diferencia): resta al primer polígono del argumento de entrada el
segundo polígono
Figura 2.7 Operación de diferencia en POLYGONCLIP
30
• "1" (Intersección): calcula el polígono resultante de la intersección entre
ambos
Figura 2.8 Operación de intersección en POLYGONCLIP
31
• "2" (XOR): calcula los polígonos resultantes al restar el polígono
intersección a los polígonos originales (inputs). En este caso, tendremos dos
output.
Figura 2.9 Operación XOR en POLYGONCLIP
32
• "3" (Union): calcula el polígono resultante de la suma entre los polígonos
originales
Figura 2.10 Operación de unión en POLYGONCLIP
En nuestros cálculos, sólo necesitaremos usar las operaciones de diferencia ("0") e
intersección ("1"):
• Intersección: para conocer las subregiones que el satélite cubre sobre la región
de interés.
• Diferencia: para actualizar la región de interés, eliminando las zonas ya cubiertas
por los satélites y seguir operando con las zonas que aún quedan por cubrir.
33
3 Algoritmos Heurísticos para la resolución del
problema SAP
Debido a la complejidad del problema a resolver y la necesidad de obtener una "buena"
solución en un período de tiempo relativamente corto, es necesario aplicar algoritmos
heurísticos y/o metaheurísticos. Los algoritmos heurísticos son métodos que permiten
obtener, de manera rápida, una solución que se espera sea cercana a la solución óptima.
Para una introducción acerca de estos métodos heurísticos, consultar Bibliografía [5] y
[10].
En este trabajo se aplicará un algoritmo GRASP (Greedy Randomized Adaptive Search
Procedure) al problema de planificación EOSs. Este tipo de algoritmo heurístico ha sido
ampliamente utilizado para resolver problemas de optimización a gran escala, desde el
trabajo pionero desarrollado por Feo y Resende (Bibliografía [4]).
Un proceso GRASP consiste en añadir elementos de manera aleatoria a la solución del
problema, extraídos del conjunto de Ν∈k elementos que de manera individual, aportan
la mayor mejora en la función objetivo cuando se añade dicho elemento a la solución
previa. Este proceso es repetido y cada una de las diferentes (posibles) soluciones
obtenidas forman un conjunto de soluciones factibles. La solución final escogida por
GRASP será la mejor de entre todas las que forman este conjunto de soluciones
factibles obtenidas previamente. Cuando 1=k , esto es, cuando elegimos en cada
iteración el elemento que individualmente aporta la mayor mejora a la función objetivo,
el proceso obtenido es un algoritmo GREEDY. No obstante, veremos que el uso de un
algoritmo GREEDY estará más lejos de obtener una solución (casi) óptima que si se usa
un algoritmo GRASP con k>1.
34
3.1 Algoritmo GRASP para resolución del problema de planificación EOSs
El siguiente procedimiento aporta una solución factible a nuestro problema, 1Sol , esto
es, un conjunto de satélites cuyas adquisiciones cubren por completo la región de interés
ℜ .
Datos de entrada (inputs): },...,{,, 1 naak ℜ
Comenzamos fijando {}},,...,{,Re 1 ==ℜ= SolaaAqg n
1. Si kAq ≤ fijamos AqFq = , siendo Fq el conjunto constituido por las k
adquisiciones en Aq cuyas trazas, de manera individual, cubren la máxima área
de gRe . Si kAq > , se calculan los k elementos de Aq que individualmente
mejoran más la función objetivo, formando así el conjunto Fq.
2. De manera aleatoria, seleccionamos una adquisición ia de Fq. }{ iaSolSol U= .
Actualizamos }{ iaAqAq −= y iS\ReRe gg = (donde iS es la subregión
cubierta por la adquisición ia ).
3. Si φ=gRe , STOP. Sol es una solución factible. En caso contrario, volver al
paso 1.
Para explorar el conjunto de soluciones factibles, se repite este algoritmo hasta que
termina el tiempo de computación establecido (fijado por el usuario) o se llega al
máximo número de soluciones fijadas, maxJ (también establecidas por el usuario). De
este modo, sean },...,{max1 JSolSol el conjunto de soluciones factibles calculadas. Si
jCost indica el coste de obtener la solución jSol , esto es, ∑ ∈=
jSoli ij cCost , nuestro
algoritmo termina escogiendo la mejor solución factible de entre todas las que han sido
calculadas. Esto es, la solución final será *jSol , donde *j es aquella que hace
*max,...,1min
jjJj CostCost == .
35
Este problema se puede extender al caso en el que el uso de las adquisiciones tenga
asociado costes diferentes. En este caso, en el paso 1 podremos elegir la adquisición que
maximiza la ratio (área cubierta/coste de la adquisición).
36
4 Análisis y Resultados
4.1 Estudios Estadísticos sobre el tiempo de cálcul o de la matriz Q
Como se vio en la Sección 2.3.2, el cálculo de la matriz Q puede llegar a suponer un
cuello de botella en el algoritmo de resolución del problema de planificación de EOSs.
Para determinar analíticamente la evolución del coste de la matriz Q, se ha llevado a
cabo un estudio estadístico de la tendencia del tiempo de cálculo de esta matriz frente al
número total de adquisiciones posibles, tanto en el modelo I (donde se considera una
matriz Q 2-D) como en el modelo II (matriz Q 3-D).
4.1.1 Modelo I (Matriz Q 2-D): q-satélites con sensor fijo En la Tabla 4.1 muestra los datos experimentales de la evolución en los tiempos de
cómputo de la matriz Q (bidimensional) conforme vamos aumentando el número de
satélites en el modelo I. Podemos observar como el tiempo necesario para computar la
matriz crece con el número de satélites, llegando hasta un valor de 1.638 segundos para
32 satélites.
La Tabla 4.2 muestra las tendencias que se han testeado, así como las ecuaciones que
rigen su evolución y el parámetro 2R . Este parámetro será el que nos indicará cuál de
dichas tendencias es la que mejor aproxima el comportamiento o evolución del coste
computacional frente al número de satélites considerados en el problema ( 10 2 ≤≤ R ,
significando que cuanto más cercano sea a uno, mejor aproxima los datos
experimentales). En dicha tabla se puede observar como la mejor aproximación es una
tendencia de tipo exponencial, ya que su valor de 9902.02 =R es el más cercano a 1 (la
fila correspondiente está sombreada). Este hecho también se puede observar de manera
gráfica; en la Figura 4.1 se ve con claridad como la aproximación exponencial (línea de
tendencia en amarillo) es la que mejor aproxima los datos experimentales (puntos rojos).
Usando la ecuación de dicha tendencia de tipo exponencial, podemos estimar un tiempo
medio de cálculo en el modelo I con un número de satélites del orden de 100, en
37
aproximadamente 20 minutos. No obstante, en la Sección 4.1.2 (donde se verá el
estudio estadístico sobre modelo II, matriz Q 3-D), se comprobará como los tiempos de
computación de la matriz Q son del orden de 5 minutos, ya que nunca llegaremos a usar
un número de satélites en torno a 100, sino que el parámetro a tener en cuenta a la hora
de calcular el tiempo de computación de Q será el número total de adquisiciones
posibles.
Tabla 4.1 Tiempos de cálculo de la matriz Q para modelo I (sensor fijo)
Nº de Satélites (n_sat)
Subregiones Tiempo [s]
2 6 0,1092 4 20 0,1248 6 37 0,1092 8 43 0,156 10 58 0,2184 12 84 0,2808 14 96 0,3276 16 108 0,3744 18 140 0,4524 20 170 0,5772 22 202 0,6864 24 242 0,858 26 293 1,0452 28 316 1,2168 30 385 1,4664 32 409 1,638
Tabla 4.2 Estudio estadístico de la evolución del coste computacional de Q (modelo I)
Aproximación Ecuación 2R
Lineal 25.0_05.0 −⋅= satnt 0,8965
Logarítmica 72.0)_ln(51.0 −⋅= satnt 0,6303
Exponencial )_1.0exp(08.0 satnt ⋅⋅= 0,9902
Potencia 09.1_02.0 satnt ⋅= 0,861
38
Coste Computacional matriz Q
-0,5
0
0,5
1
1,5
2
0 5 10 15 20 25 30 35
Nº de Satélites(n_sat)
Tie
mpo
[s]
Lineal Log Exp Pot
Figura 4.1 Tendencias coste computacional versus nº de satélites (matriz Q); sensor fijo
4.1.2 Modelo II (Matriz Q 3-D): q- satélites con sensor variable
En este modelo, al considerar variable la posición del sensor, aumenta
considerablemente el número total de adquisiciones posibles y por tanto, el número de
subregiones generadas en ℜ . Realizando un estudio estadístico sobre la evolución del
tiempo de computación de Q frente al número de adquisiciones, se comprueba como la
tendencia que mejor aproxima la evolución de los datos experimentales es una de tipo
lineal. Los datos experimentales considerados están representados en la Tabla 4.3,
donde además del tiempo de computación, subregiones generadas y el número total de
adquisiciones posibles consideradas, está representado el tamaño de la matriz Q
tridimensional. Recordar de nuevo que estos índices (I, J, K) expresan número de
satélites (I) número de subregiones (J) y número de posibles modos de sensor (K).
El estudio estadístico desarrollado sobre este modelo está resumido en la Tabla 4.4,
donde la fila sombreada representa la tendencia que mejor aproxima los datos
experimentales. La mejor aproximación ahora se lleva a cabo usando una función lineal
con 9957.02 =R .
39
Creemos que esta sorprendente tendencia lineal se debe a dos razones:
• Introducir más satélites i generará subregiones de área tan pequeña que no serán
computadas por nuestro algoritmo; obviamente, se consumirá tiempo para
calcular dichas subregiones, pero al comprobar su área, se descartarán y no serán
consideradas en iteraciones posteriores.
• Mantener el número de satélites considerados e introducir un mayor número de
modos de sensor provocará que muchas de las adquisiciones para los modos de
sensor más altos se salgan de la región objetivo, y por tanto no generen ninguna
subregión nueva.
Tabla 4.3 Tiempos de cálculo de la matriz Q para modelo II (sensor variable)
Número de Adquisiciones
(a) Subregiones Tamaño de Q
(I, J, K) Tiempo
[s]
50 400 (5,400,10) 3,0888 100 1312 (20,1312,5) 18,6733 132 1718 (22,1718,6) 33,6026 154 1902 (22,1902,7) 43,5087 200 2065 (20,2065,10) 62,53 230 2274 (23,2274,10) 83,9753 312 2377 (24,2377,13) 126,2984 390 2449 (26,2449,15) 170,634 464 2535 (29,2535,16) 218,183 560 2553 (28,2553,20) 258,182
Tabla 4.4 Estudio estadístico de la evolución del coste computacional de Q (modelo II)
Aproximación Ecuación 2R Lineal 08.3452.0 −⋅= at 0.9957
Logarítmica 3.479)ln(93.108 −⋅= at 0.8592
Exponencial )007.0exp(56.9 at ⋅⋅= 0.7759
Potencia 7615.10049.0 at ⋅= 0.972
La Figura 4.2 representa la evolución del coste computacional en el cálculo de la matriz
Q en función del número total de adquisiciones posibles. En dicha figura, se encuentran
representadas las diferentes tendencias testeadas sobre los datos experimentales (puntos
rojos), corroborándose como la tendencia lineal es la que mejor aproximación aporta.
40
Utilizando la ecuación analítica de dicha tendencia (ver Tabla 4.4), podemos prever un
intervalo de computación de la matriz Q para adquisiciones del orden de 1000 de
aproximadamente 8 minutos.
Coste Computacional matriz Q
-100
0
100
200
300
400
500
600
0 100 200 300 400 500 600
Nº de Adquisiciones (a)
Tie
mpo
[s]
Lineal Log Exp Pot
Figura 4.2 Tendencias coste computacional versus nº de adquisiciones (matriz Q); sensor variable Por último, destacar que la herramienta usada para realizar los cálculos de geometría
computacional (Polygon Clipper) falla para determinadas combinaciones de número de
satélites y modos de sensor (generalmente valores altos). Este fallo provoca que
MATLAB dé un error interno y se deba cerrar el programa. Dicho error no es
provocado por el código desarrollado, sino por el archivo MEX utilizado por Polygon
Clipper; por lo cual, se propone como trabajo futuro realizar un debugging a dicho
archivo. Posiblemente, el desarrollo de este código en otros lenguajes de programación
(en lenguaje C++, por ejemplo) evitaría este error.
4.2 Comparativa entre resultados heurísticos y exac tos La implementación del algoritmo GRASP descrito en la Sección 3.1 fue llevada a cabo
en MATLAB (al igual que el resto de códigos generados). Dicho código está descrito en
la Sección 7.2, implementado bajo el nombre de q_GRASP. Como se comentó en la
41
Sección 1 (introducción), el objetivo final de nuestro proyecto es desarrollar un
algoritmo rápido y efectivo, capaz de calcular soluciones óptimas o casi óptimas en
tiempo real para el problema de planificación EOSs.
Una vez implementado dicho algoritmo, es necesario corroborar su fiabilidad a la hora
de encontrar el óptimo, valiéndonos para ello de la solución óptima que ofrecen los
algoritmos exactos. Con esta finalidad, se han diseñando 10 instancias, intentando
conseguir la mayor diversidad posible sobre el número de satélites y modos de sensor
usados, y se han resuelto con GRASP y con CPLEX.
La información acerca de las instancias testeadas se puede observar en la Tabla 4.5; en
esta tabla se presentan el número de satélites y posiciones de sensor usadas en cada
instancia, el número de subregiones generadas y el tiempo de cálculo de la matriz Q
tridimensional, TQ en segundos. El rango del número de satélites está entre 20 y 30, y
entre 6 y 20 para los modos de sensor. Así mismo, obtenemos un número de
subregiones generadas entre 1718 y 2553 y un promedio en el tiempo de cálculo de la
matriz Q de 1.95 minutos.
Tabla 4.5 Tabla de Experimentos
Instancia Satélites Modos Sensor Subregiones TQ
[s] 1 28 20 2553 258,1817 2 22 6 1718 33,6026 3 22 7 1902 43,5087 4 23 10 2274 83,9753 5 20 10 2065 62,53 6 24 13 2377 126,2984 7 26 15 2449 170,6339 8 29 16 2535 218,183 9 19 12 2158 73,6637 10 30 10 2127 96,7206
Cada una de estas instancias ha sido testeada utilizando el código q-GRASP
(Sección 7.2) y comparando sus resultados con el óptimo encontrado a través de
CPLEX. En el procedimiento desarrollado se han realizado 5000 iteraciones,
variando el número de elementos considerados (aquellos que aportan una mayor
mejora a la función objetivo), de entre los cuales el programa escoge uno
aleatoriamente. Es decir, hemos hecho escoger al algoritmo GRASP adquisiciones
de manera aleatoria de entre las 1, 2, 3, 4 ó 5 mejores (aquéllas que más subregiones
42
cubren de las que aún no han sido cubiertas) en cada iteración. Así mismo, se ha
hecho que el programa pare en el momento en que encuentre una solución óptima
(calculada previamente con CPLEX).
En resumen, se llevan a cabo 5000 iteraciones y el programa devuelve la mejor
solución encontrada, parando en el momento en que se halle una solución óptima (si
es que la encuentra).
Los resultados obtenidos están recogidos en la Tabla 4.6 y en la Tabla 4.7, siendo el
significado de cada columna:
• Óptimo CPLEX: número de satélites que forman la solución óptima,
calculada a través de un algoritmo exacto (calculada a partir de la resolución
del problema (3) con CPLEX).
• GR(k=1,...,5): número de satélites que forman la mejor solución (óptima o
no) encontrada por el algoritmo GRASP, cuando se le hace elegir
adquisiciones de manera aleatoria de entre las k=1,...,5 adquisiciones que
mayor mejora producen en la función objetivo (para cada iteración).
• T(k=1,...,5): tiempo (en segundos) que necesita el algoritmo GRASP para
encontrar la mejor solución (óptima o no), cuando se elige una adquisición
aleatoriamente de entre las k=1,...,5 mejores adquisiciones en cada iteración.
• It(k=1,...,5): número de iteraciones realizadas por GRASP hasta encontrar la
mejor solución (óptima o no) cuando se elige una adquisición aleatoriamente
de entre las k=1,...,5 mejores adquisiciones en cada iteración.
43
Tabla 4.6 Resultados heurísticos I
Instancia
Óptimo CPLEX
GR (k=1)
T [s] (k=1)
It (k=1)
GR (k=2)
T [s] (k=2)
It (k=2)
GR (k=3)
T [s] (k=3)
It (k=3)
1 5 7 0,6084 1 6 1,326 2 6 11,8873 15 2 8 9 0,1716 1 8 10,8733 62 8 78,9521 417 3 7 9 0,1872 1 8 6,162 30 7 51,4179 228 4 7 11 0,39 1 8 0,936 3 7 44,6475 118 5 7 11 0,2964 1 8 3,4008 12 7 159,963 504 6 7 11 0,5148 1 8 3,66 8 7 122,835 244 7 5 7 0,468 1 6 0,4368 1 6 4,3056 8 8 5 7 0,5304 1 6 0,4836 1 6 2,9172 4 9 7 8 0,2652 1 8 1,2636 4 7 228,401 638 10 5 9 0,4212 1 7 23,5718 58 6 6,0216 15
Tabla 4.7 Resultados heurísticos II
Instancia
Óptimo CPLEX
GR (k=4)
T [s] (k=4)
It (k=4)
GR (k=5)
T [s] (k=5)
It (k=5)
1 5 6 3,3696 4 6 2,1216 3 2 8 8 408,8162 1949 8 646,141 2939 3 7 7 339,349 1387 8 54,3975 216 4 7 7 861,1723 2126 7 110,917 273 5 7 7 212,9258 633 7 193,472 557 6 7 7 71,6357 136 7 751,582 1361 7 5 6 2,542 5 6 0,3744 1 8 5 6 5,5536 8 6 11,2009 17 9 7 8 93,6318 241 7 798,382 1933 10 5 5 180,0408 430 5 216,529 485
4.2.1 Análisis de Resultados
En los resultados mostrados en la Tabla 4.6 y Tabla 4.7 se observa como en 7 de las 10
instancias se alcanza el óptimo para alguna de las k usadas. Aquellas instancias en las
que no se ha logrado alcanzar el número óptimo de satélites, han sido comprobadas
manualmente, obligando al programa a seleccionar aquellos satélites que forman la
solución óptima que se encontró con CPLEX. Se observó que sería necesario utilizar un
k del orden de 18 para conseguir que el algoritmo encuentre esa solución óptima. Las
instancias donde no se obtiene el óptimo son la 1, 7 y 8, en las cuales nuestro código no
44
aportaría una solución óptima, pero daría una casi-óptima (usando un satélite más que el
óptimo) para k=2 en un máximo de 2 iteraciones y en un tiempo promedio de 0.75
segundos.
Una vez mostrados los resultados obtenidos en los experimentos, se ha procedido a
realizar un pequeño estudio estadístico para sacar conclusiones acerca de la efectividad
de nuestro código.
El análisis hecho sobre las instancias está recogido en la Tabla 4.8, en la cual para cada
k se muestra:
• Óptimo [%]: probabilidad de encontrar el óptimo (a través de CPLEX) en 5000
iteraciones.
• Tiempo [s]: promedio de tiempo (en segundos) necesario para encontrar la mejor
solución (óptima o no) en 5000 iteraciones.
• Iteraciones: promedio de iteraciones necesarias para encontrar la mejor solución
(óptima o no).
Tabla 4.8 Análisis de experimentos
k
Óptimo [%]
Tiempo [s]
Iteraciones
1 0 0,39 1 2 10 5,21 18 3 60 71,13 219 4 60 217,9 692 5 60 278,51 779
Vemos como para k=1 (sería como utilizar un algoritmo GREEDY) nunca se obtiene la
solución óptima, por lo cual descartaríamos usarla; así mismo, para k=2 solo
conseguiríamos obtener el óptimo en el 10 % de los casos aunque el tiempo necesario
en obtenerlo sería muy pequeño (5.21 segundos).
Ahora bien, en la Tabla 4.8 se observa como los mejores resultados, en cuanto a
efectividad en encontrar una solución óptima, son para k=3, 4, 5. En estos 3 casos, la
probabilidad de encontrar un óptimo asciende hasta el 60 %, si bien conforme aumenta
k, se eleva el tiempo y las iteraciones necesarias para encontrarlo.
45
Por todo esto, se recomendaría usar este código con k=3, ya que tendríamos el 60 % de
probabilidades de encontrar una solución óptima y además, en un tiempo relativamente
corto (alrededor de 1 minuto).
4.2.2 Ejemplo
Para clarificar ideas acerca de como funciona nuestro algoritmo GRASP, tomemos
como ejemplo la instancia 10, en la cual teníamos 30 satélites con 10 modos de sensor.
La Figura 4.3 muestra las subregiones generadas, siendo un total de 2127. Por claridad
en el dibujo, no se han numerado sobre la figura. La Figura 4.4 muestra el total de
adquisiciones generadas en esta instancia, donde el rectángulo en rojo representa la
región de interés ℜ que queremos cubrir.
Figura 4.3 Subregiones generadas en la instancia 10 (30 satélites / 10 modos de sensor)
46
Figura 4.4 Total de adquisiciones a considerar sobre la instancia 10
El problema a resolver será elegir, entre todas las adquisiciones mostradas en la Figura
4.4, aquel conjunto que optimiza la cobertura, es decir, el mínimo número de
adquisiciones tal que la región de interés quede totalmente cubierta o lo que es lo mismo,
que se cubran todas las subregiones mostradas en la Figura 4.3.
A continuación, representamos una solución óptima comparándola con una no óptima,
ambas calculadas utilizando el algoritmo GRASP implementado en nuestro código.
Desde la Figura 4.6 hasta la Figura 4.10, se muestra una solución óptima y desde la
Figura 4.11 hasta la Figura 4.16, una solución casi óptima. Esta solución óptima la
forman 5 adquisiciones y la solución casi óptima está compuesta por 6 adquisiciones.
En todas estas figuras la región de interés está representada por el rectángulo rojo (ver
Figura 4.5), mientras que los rectángulos verdes representan la entrada de una nueva
adquisición y los azules son adquisiciones que entraron en la solución en iteraciones
anteriores. En cada figura se muestra la adquisición que selecciona el código en cada
iteración del mismo, observando como ambas soluciones (óptima y no óptima) son
factibles, es decir, cubren toda la región de interés, pero la solución óptima necesita tan
sólo 5 adquisiciones (una menos que la solución no óptima). Notar que CPLEX no
calcula su solución de forma iterativa
47
Figura 4.5 Región de interés a cubrir (Instancia 10)
• Solución óptima:
Figura 4.6 1ª adquisición de la solución óptima (instancia 10)
48
Figura 4.7 2ª adquisición de la solución óptima (instancia 10)
Figura 4.8 3ª adquisición de la solución óptima (instancia 10)
49
Figura 4.9 4ª adquisición de la solución óptima (instancia 10)
Figura 4.10 5ª adquisición de la solución óptima (instancia 10)
50
• Solución no-óptima:
Figura 4.11 1ª adquisición de una solución casi-óptima (instancia 10)
Figura 4.12 2ª adquisición de una solución casi-óptima (instancia 10)
51
Figura 4.13 3ª adquisición de una solución casi-óptima (instancia 10)
Figura 4.14 4ª adquisición de una solución casi-óptima (instancia 10)
52
Figura 4.15 5ª adquisición de una solución casi-óptima (instancia 10)
Figura 4.16 6ª adquisición de una solución casi-óptima (instancia 10)
53
5 Conclusiones
Hemos visto como existe una cada vez más creciente necesidad de planificar y gestionar
de manera óptima los datos obtenidos de la superficie terrestre a través de flotas EOSs,
debido al surgimiento de un elevado número de aplicaciones, tales como la gestión de
crisis o la detección de incendios. Actualmente, la tendencia es una planificación
multisatélite, lo cual permite llevar a cabo la adquisición de datos de una manera más
rápida y eficaz. No obstante, ello hace que sean necesarios nuevos algoritmos que
gestionen eficientemente la elevada información que se obtiene. Se desean algoritmos
capaces de trabajar en tiempo real y que aporten soluciones óptimas (o casi) al problema
relacionado con la planificación de EOSs.
El uso de algoritmos exactos se hace inviable, debido a que suelen estar implementados
en software costosos; por ello, se llega a una solución de compromiso: el uso de
algoritmos heurísticos, los cuales proporcionarán una solución óptima o casi-óptima,
siendo en esta última situación aceptable siempre y cuando el algoritmo sea capaz de
proporcionarla en un tiempo razonable.
Bajo esta nueva perspectiva de afrontar el problema de planificación EOSs mediante
algoritmos heurísticos, se ha realizado una primera aproximación, formulando en primer
lugar 3 modelos de partida, de complejidad creciente, los cuales están basados en
problemas estándar de programación entera. Se vio como fue vital encontrar una
herramienta que llevara a cabo los cálculos relacionados con la geometría
computacional implicada en el problema. Para ello, se escogió el toolbox de MATLAB
Polygon Clipper (totalmente gratuito), reduciendo el problema al cálculo de una matriz
Q, la cual simplifica de una manera efectiva la organización de la información relativa a
las adquisiciones y subregiones obtenidas, permitiéndonos conocer qué subregiones son
cubiertas por cada satélite y por cada modo de sensor; por este motivo, dicha matriz se
convirtió en la base del problema de planificación y fue necesario una correcta y eficaz
definición y desarrollo de la misma.
54
De los 3 modelos formulados, sólo los dos primeros han sido resueltos, considerándose
que el tercer modelo (donde son consideradas restricciones de duty cycle) escapa al
objetivo de este proyecto y del estudio preliminar que se deseaba desarrollar.
Sobre los dos primeros modelos se ha realizado un pequeño análisis estadístico, con el
objetivo de estimar los tiempos de computación de la matriz Q, en función del número
total de adquisiciones posibles (proporcional al número de satélites y modos de sensor),
con el resultado de que en el segundo modelo, este tiempo sigue de manera muy exacta
una tendencia lineal, estimándose un tiempo de computación de aproximadamente 8
minutos para un orden de subregiones de 1000. Esto nos llevó a la conclusión de que el
cálculo de dicha matriz podría suponer un cuello de botella en el algoritmo de
optimización.
Finalmente, nos decantamos por usar un algoritmo heurístico de tipo GRASP para
resolver el problema de planificación EOSs. Fueron desarrollados 10 experimentos o
instancias, donde se compararon los resultados de dicho algoritmo con las soluciones
óptimas encontradas por CPLEX. En total, llegamos al óptimo en 7 de las 10 instancias
en alguna de las k=1,2,3,4,5 usadas. Aquellas instancias en las cuales no llegamos al
óptimo para ninguna k, se vio como, para obtener dichas solución, hubiese sido
necesario el uso de una k=18. Como conclusión, a partir de los datos obtenidos
podemos afirmar que nuestro código posee un 60 % de probabilidades de obtener una
solución óptima, siendo k=3 la mejor opción, ya que aparte de llegar al óptimo en el 60
% de las instancias, en el caso de no obtener un óptimo se comprobó como aportaba una
solución casi-óptima (una adquisición más que en la solución óptima) en un tiempo
inferior a 1 minuto.
Por último, tras este estudio preliminar del problema de planificación EOSs, se
identifican los siguientes puntos, donde sería necesario trabajar en un futuro con el
objetivo de conseguir obtener una herramienta óptima y eficiente de acuerdo con las
necesidades del problema:
• Formulación de nuevos modelos en los cuales se incluyan no sólo restricciones
de tipo duty cycle, sino también aquéllas de naturaleza dinámica, tales como
eclipses, tiempos de descarga de datos, etc., llegando así hasta un modelo
realista del problema.
55
• Implementar en el código propagadores de órbitas, para obtener una
aproximación realista de las adquisiciones a tener en cuenta sobre el problema
de planificación EOSs.
• Debugging sobre la herramienta de geometría computacional Polygon Clipper o
bien la utilización de otro tipo de herramienta que nos ayude a realizar estos
cálculos de manera efectiva y fiable.
• Implementación de otros algoritmos heurísticos que se aproximen mejor a una
solución óptima con un porcentaje de acierto superior al obtenido con GRASP,
tales como algoritmos genéticos o búsqueda de variables vecinas.
• Implementación de los códigos desarrollados en otros tipos de lenguaje de
programación, tales como C++ .
• Formular modelos donde sean considerados los denominados satélites ágiles, los
cuáles tienen la capacidad de variar su sensor tanto longitudinal como
lateralmente de manera continua. El modelado de este tipo de satélite sería más
complejo debido a los dos grados de libertad que tendríamos en el sensor.
• Implementación en herramienta SaVoir, como paso final tras conseguir un
código capaz de resolver de manera óptima y efectiva, en tiempo real, un
problema realista de planificación de EOSs.
56
6 Bibliografía
[1] Bazaraa, M.; Jarvis, J. and Sherali, H.; 1990. Linear programming and network
flows. Wiley
[2] Chien, S.; Smith, B. and Rabideau, G. 1998. Automated planning and scheduling for
goal-based autonomous spacecraft. IEEE Intelligent Systems and their applications,
Vol. 13, 13:50-55
[3] Cordone, R.; Gandellini, F. and Righini, G. 2008. Solving the swath segment
selection problem through lagrangian relaxation. Computers & Operation Research
35:854-862
[4] Feo, T. and Resende, M. 1989. A probabilistic heuristic for a computationally
difficult set covering problem. Operations Research Letters 8:67-71
[5] Michalewicz, Z. and Fogel, D.B. 2000. How to solve it: Modern Heuristics. Springer
Verlag.
[6] Muraoka, H.; Cohen, R.;Ohno, T. and Doi, N. 1998. Aster Observation scheduling
algorithm. Proceeding of SpaceOps 1998, Tokio, Japón.
[7] Schilling, D.A.; Jayaraman, V. and Barkhi, R. 1993. A review of covering problems
in facility location. Location Science 1 (1):25-55
[8] Sun, B.; Wang, W. and Qin, Q. 2008. Satellites Scheduling Algorithms based on
dynamics constraints satisfaction problem. 2008 International Conference of Computeer
Science and Software Engineering 167-170
[9] Taitus. 2011. Savoir: Swath Adquisition Viewer.
www.taitussoftware.com
[10] Vazirani, V. 2001. Approximation Algorithms. Springer
57
[11] Wolsey, L.A. 1998. Integer Programming. Wiley
• Páginas Web Consultadas
� Información de GAMS: http://www.uv.es/~sala/gams/14.PDF
� GREEDY:http://es.wikipedia.org/wiki/Algoritmo_voraz,
http://www.fceia.unr.edu.ar/lcc/t312/archivos/09.ED.Greedy.handout.pdf
� GRASP:http://catarina.udlap.mx/u_dl_a/tales/documentos/lii/hernandez_
r_cm/capitulo3.pdf
� Polygon Clipper:www.mathworks.com/matlabcentral/fileexchange/8818-
polygon-clipper
58
7 Apéndice: Descripción del Código Empleado
En esta sección se describen los códigos generados en la resolución del problema de
planificación de EOSs. Se mostrarán los pseudocódigos que siguen los programas
implementados y se aclarará el funcionamiento de los mismos. Al final de cada sección
de este capítulo, se muestran los códigos desarrollado en MATLAB.
7.1 Estructura general de cálculo de matriz Q
El cálculo de la matriz Q está compuesto por un código principal MATRIZQVAR, que es
el encargado de generar dicha matriz como output. MATRIZQVAR realiza la llamada del
código SATVAR, el cual proporciona como inputs a MATRIZQVAR el número total de
adquisiciones tomadas por todos los satélites (teniendo en cuenta todas sus posibles
posiciones de sensor) así como las subregiones generadas por la intersección de dichas
adquisiciones con la región de interés ℜ . Para calcular estos inputs, el código SATVAR
utiliza CALC (el cual se encarga de generar las subregiones) e INTVAR (base de datos
de los satélites del cual se vale SATVAR para crear las adquisiciones cuando variamos la
posición del sensor en los satélites). En el diagrama de la Figura 7.1 puede observarse la
estructura general de los códigos:
Figura 7.1 Estructura de códigos para el cálculo de la matriz Q (3D)
MATRIZQVAR
SATVAR
INTVAR CALC
59
Resumiendo, los códigos utilizados para el cálculo de la matriz Q son:
1. MATRIZQVAR: código principal encargado de generar la matriz Q. Dicho
código llama a SATVAR para obtener los inputs. Es el código que debe ser
ejecutado.
2. SATVAR: código empleado para generar todas las adquisiciones de los satélites
así como las subregiones generadas. Para ello, hace uso de CAL e INTVAR.
3. CALC: mediante el uso de la herramienta de geometría computacional mostrada
en la Sección 2.4, se encarga de generar una estructura de vectores, los cuales
representan cada una de las subregiones (polígonos) producidas por la
intersección de cada adquisición con la región de interés ℜ .
4. INTVAR: base de datos con las coordenadas geométricas de la adquisición
principal (con ángulo de sensor formando 90 º con el vector tangente a la órbita
del satélite y en dirección a la superficie terrestre) de cada uno de los satélites
EOSs. Mediante cálculos geométricos, SATVAR se encarga de generar las
adquisiciones producidas cuando el modo del sensor (ángulo) varía.
Es muy importante destacar que la matriz Q generada por el código MATRIZQVAR es
una matriz 3D (ver paso 2, Sección 2.1). El cálculo de la matriz Q tridimensional se
realiza al final del código de MATRIZQVAR, el cual es un simple proceso de bucles que
reordenan la matriz Q 2D para aportar directamente la información de los satélites y
posiciones de sensor que cubren cada subregión concreta de ℜ . Para la resolución del
Modelo I (Sección 2.3.2.1) bastará con usar la matriz Q 2D (pues no existe el grado de
libertad de ángulo de sensor) mientras que para la resolución del Modelo II (Sección
2.3.2.2) es necesario usar la matriz Q 3D.
60
La lógica desarrollada en el código MATRIZQVAR para la obtención de la matriz Q es
mostrada en el pseudocódigo de la Figura 7.2. Previamente, conviene establecer la
notación utilizada:
• n: número total de satélites EOSs considerados en el problema
• N: número total de subregiones generadas tras la intersección de todas las
adquisiciones con la región de interés ℜ
• ),( kjjk psa : adquisición tomada por el satélite js con una posición de sensor kp .
• A: conjunto de todas las posibles adquisiciones dadas por el conjunto de satélites
y por cada una de sus posiciones de sensor
• SR: conjunto de intersecciones de A con la región de interés ℜ , es decir, el
conjunto de subregiones generadas.
• c: número total de posibles modos de sensor en cada satélite
61
Figura 7.2 Pseudocódigo empleado en MATRIZQVAR
A, SR
j=0
j=j+1
),( kjjk psa
ikjjk SRpsa ∪),( =INT
i=0
¿INT =0? Sí No
¿Área(INT) >0.01?
Sí
No
Q(j,i,k)=1
Q(j,i,k)=0
i=i+1
SATVAR Inputs
¿i=N?
¿j=n? No
MATRIZ Q Sí
Sí
No
k=0
k=k+1
¿k=c?
Sí No
62
Partimos de A (conjunto de adquisiciones dadas por todos los satélites con todas sus
posibles posiciones de sensor) y SR (conjunto de subregiones en que ha quedado
dividida ℜ tras el paso de todas las adquisiciones de A). Estos inputs son calculados en
el código SATVAR.
Vamos escogiendo las adquisiciones una por una y computando sus intersecciones con
cada una de las subregiones iSR. Pueden darse dos posibilidades:
1. Dicha adquisición no cubre la subregión iSR: en ese caso, se le asignará a la
entrada (j,i,k) de la matriz Q un "0".
2. La adquisición cubre la subregión iSR: se calcula el área de la intersección. Si
dicha área es superior a 0.01 unidades de superficie, se le asigna a la entrada
(j,i,k) de Q un valor "1"; en caso contrario, será "0". Este filtro se realiza para
disminuir el coste computacional, evitando considerar subregiones de tamaño
despreciable. Por otro lado, la herramienta de geometría computacional Polygon
Clipper puede contabilizar como subregiones aquellas cuya área sea nula, es
decir, líneas. Este problema con la herramienta ocurre cuando el número total de
adquisiciones posibles es muy elevado (del orden de 25 satélites con 20
posiciones de sensor cada uno). En resumen, despreciar subregiones de área
inferior a 0.01 unidades de superficie atiende a dos razones:
• Disminuir el coste computacional, acercándonos a un
algoritmo que pueda trabajar en tiempo real.
• Evitar que se computen líneas como subregiones.
Este proceso termina cuando hemos comprobado si existe intersección o no entre cada
una de las adquisiciones jka con cada subregión iSR. Obtenemos la matriz Q 2D.
Con un breve bucle, convertimos la matriz Q en 3D, cuyas entradas (j,i, k) valdrán "1" si
la subregión i es cubierta por el satélite j en su posición de sensor k. El bucle consiste en
recorrer filas y columnas de la matriz Q y utilizar la función repmat de MATLAB, la
cual nos permite generar una matriz tridimensional.
63
• Código generado:
function [a,zonas,sat_traz,q]=matrizqvar(n,it,paso,'repres' ) % INPUTS: -n: nº de satélites -it: nº posiciones de sensor -paso: separación entre adquisiciones cont iguas para un mismo satélite -repres: 'si' / 'no' dependiendo si querem os numerar las subregiones generadas (en el gráfico) % OUTPUTS: -zonas: estructura de vectores donde se g uardan los polígonos que representan las subregiones generadas -a: nº total de subregiones -sat_traz: estructura de vectores donde s e guardan los polígonos que representan las adquisiciones -q: matriz Q tridimensional
r=struct( 'x' ,[0 16 16 0], 'y' ,[0 0 9 9], 'hole' ,0); %región de interés [zonas,a,sat_traz]=satvar(n,it,paso,repres); %%Vamos seleccionando cada una de las adquisiciones y la vamos %%comparando con la matriz 'zonas'(subregiones de ' R'), para %%determinar cuales de sus zonas cubre y cuales no a=numel(zonas); a_traz=numel(sat_traz); for k=1:a_traz
p=sat_traz(1,k); for i=1:a %%Escogemos con el índice 'i' la zona
R=zonas(1,i); %%Calculamos la intersección %%de la adquisición seleccionada con la zona(i) h=polygonclip(p,R,1);
%%Si la longitud de 'h' es cero, significa %%que no existe intersección, y por tanto, %%esa adquisición no cubre la zona 'i', lo que impl ica que en la %%matriz Q aparecerá un cero if length(h)==2
64
for l=1:2
area_int=abs(polygonarea(h(1,l).x,h(1,l) .y)); if area_int>0.01 Q(i,k)=1;
end
end end if length(h)==1 area_int=abs(polygonarea(h.x,h.y)); if area_int>0.01
Q(i,k)=1; else Q(i,k)=0; end end
if length(h)==0 Q(i,k)=0; end
end end
%% MATRIZ Q-3D
%'j'-->número de satélite original %'i'-->zona %'k'-->posición del sensor %q(j,i,k)-->será 1 si la zona 'i' es cubierta por %el satélite 'j' en su 'k-ésima' posición de sensor for i=1:numel(Q(:,1)) %Vamos recorriendo las zonas y comparándolas con la s adquisiciones, %rellenando la matriz 'q' por filas m=1;
for j=1:numel(Q(1,:))
65
q(sat_traz(1,j).original,i,sat_traz(1,j) .traza) ... =repmat(Q(i,m),[1 1]); m=m+1; end
end
7.1.1 Código SATVAR
Como ya se comentó en la Sección 7.1, este código es el encargado de generar el
conjunto de adquisiciones y subregiones, que serán usadas como inputs en
MATRIZQVAR. A continuación, se resume la notación utilizada:
• S: conjunto de satélites considerados en el problema de planificación.
• js : satélite j-ésimo perteneciente al conjunto S
• n: número total de satélites EOSs
• c: número total de posiciones de sensor en cada satélite js
• kp : posición k-ésima del sensor
La Figura 7.7 muestra el pseudocódigo que se ha seguido para programar SATVAR.
Como inputs, este programa toma una "base de datos" de satélites de INTVAR. Esta base
de datos está formada por estructuras que especifican las coordenadas X e Y de una
adquisición inicial de los satélites que se están considerando en el problema de
planificación EOSs, sin haber variado su posición de sensor; es decir, serían las
adquisiciones que se utilizarían en el modelo I (ver Sección 2.3.2.1). El programa va
tomando uno por uno los satélites procedentes de INTVAR y va variando su posición de
sensor, calculando geométricamente la adquisición (polígono) producida para cada
posición. La distancia entre adquisiciones contiguas (posiciones de sensor contiguas)
para un mismo satélite se fija mediante el parámetro paso, el cual es un input en todos
los códigos generados en este proyecto y es decisión del usuario. Cuanto mayor sea este
parámetro, mayor separación existirá entre adquisiciones contiguas para un mismo
satélite. La Figura 7.3 y la Figura 7.4 muestran dos adquisiciones contiguas (dos
posiciones de sensor) pertenecientes a un único satélite, en el caso en que el paso sea
"1" y "0.1", respectivamente. Las adquisiciones son los polígonos verdes mientras que
66
el polígono en azul representa la región de interés. Se comprueba como con un paso de
"1" (Figura 7.3) las adquisiciones para un mismo satélite están más distanciadas que si
utilizamos un paso de "0.1" (Figura 7.4). De esto se extrae que podemos obtener mayor
precisión utilizando pasos muy pequeños, si bien el problema que entraña esto es
aumentar el coste computacional y alejarnos de una herramienta capaz de trabajar en
tiempo real. Por tanto, se deberá llegar a una solución de compromiso o bien adaptar
este parámetro en función de los requisitos de la misión.
Figura 7.3 Adquisiciones de un satélite usando un paso de valor 1
67
Figura 7.4 Adquisiciones de un satélite usando un paso de valor 0.1
Cada vez que se computa una adquisición ),( kjjk psa , dicha adquisición entra en el
programa CALC. Este programa calcula las subregiones iSR en que queda dividida la
región de interés ℜ conforme se calculan sus intersecciones con las adquisiciones
(véase Figura 7.5 y Figura 7.6). Tanto las adquisiciones generadas por SATVAR como
las subregiones calculadas por CALC, se guardan en dos estructuras de vectores (una
para las adquisiciones y otra para las subregiones), las cuales serán las entradas de
MATRIZQVAR. La información contenida en estas estructuras de vectores es la relativa
a los polígonos que representan las subregiones (Figura 7.5) y las adquisiciones (Figura
7.6). La Figura 7.5 y la Figura 7.6 muestran una representación gráfica del contenido de
estas estructuras de vectores, para un caso en el que existen 3 satélites, con 5 posiciones
de sensor y un paso de "1" entre adquisiciones contiguas para un mismo satélite.
68
Figura 7.5 Subregiones generadas por 3 satélites, con 5 posiciones de sensor y paso de 1
Figura 7.6 Adquisiciones correspondientes a 3 satélites, con 5 posiciones de sensor y paso de 1
69
Figura 7.7 Pseudocódigo empleado en SATVAR
S
j=0
j=j+1
js
kj pS ( )
k=0
¿k =c?
¿j=n?
k=k+1
INTVAR Inputs
CALC
No
No
Sí
Sí A SR
70
• Código generado: function [zonas,a,sat_traz]=satvar(n,it,paso,'repres') % INPUTS: -n: nº de satélites -it: nº posiciones de sensor -paso: separación entre adquisiciones cont iguas para un mismo satélite -repres: 'si' / 'no' dependiendo si querem os numerar las subregiones generadas (en el gráfico) % OUTPUTS: -zonas: estructura de vectores donde se g uardan los polígonos que representan las subregiones generadas -a: nº total de subregiones -sat_traz: estructura de vectores donde s e guardan los polígonos que representan las adquisiciones
r=struct( 'x' ,[0 16 16 0], 'y' ,[0 0 9 9], 'hole' ,0); %región de interés vario=0; sss=0; drawpolygon(r.x',r.y', 'b' );hold on;
zonas=(r); a=numel(zonas);
% Con el indice 'k', vamos introduciendo satélites %y vamos comparándolos con cada región que forma la %matriz 'zonas' color=[ 'b' ; 'g' ; 'c' ; 'm' ; 'y' ; 'k' ]; nn=0; %indice que nos permite asignarle el campo "sat.ori g" al sat for k=1:n nn=nn+1; [poly]=intvar; sat=poly(k); if sat.sensor==1 vario=1;
%%CALCULO DE SAT CON SENSOR VARIABLE %se encarga de dibujar las diferentes posiciones de l sensor
for c=1:it itt=c; %indice que nos permite asignarle el campo "sat.tra z" al sat pdte=(sat.y(1,4)-sat.y(1,1)); y_h=abs((sat.x(1,2)-sat.x(1,1))); y_v=abs((sat.y(1,4)-sat.y(1,1))); %%%TRAZAS HORIZONTALES/VERTICALES if sat.x(1,1)==sat.x(1,4) %rectángulos horiz. / vert. if c==1 sat.sensor=0; end if y_h>y_v % traza horizontal
71
sat.y=[paso paso paso paso]+sat.y; sat.sensor=1; end if y_h<y_v %traza vertical sat.x=[paso paso paso paso]+sat.x; sat.sensor=1; end end if sat.x(1,1)~=sat.x(1,4) %trazas tumbadas if c==1 sat.sensor=0; end s1=sat.x(1,1)-sat.x(1,4); if s1<0 %%%tumbado hacia la derecha j=2;l=4;m=4; else %%%tumbado hacia la izquierda j=2;l=4;m=4; end pdte1=(sat.y(1,j)-sat.y(1,1))/((sat.x(1,j)-sat.x( 1,1))); %dcha pdte2=(sat.y(1,3)-sat.y(1,l)) ... /((sat.x(1,3)-sat.x(1,l))); %izq b1=sat.y(1,1)-pdte1*sat.x(1,1); b2=sat.y(1,m)-pdte2*sat.x(1,m); sat1.x=[sat.x(1,1) sat.x(1,j)]'+[paso paso]'; sat2.x=[sat.x(1,3) sat.x(1,l)]'+[paso paso]'; sat1.y=pdte1*sat1.x+b1; sat2.y=pdte2*sat2.x+b2; sat.x=[sat1.x' sat2.x']; sat.y=[sat1.y' sat2.y']; sat.sensor=1; end drawpolygon(sat.x',sat.y',color(mod(k,6 )+1));hold on; sat.original=nn; sat.traza=itt; % Con el índice 'i', recorremos cada región de %'zonas' para actualizar la estructura de subregion es sss=sss+1; [zonas,a,satt]=calc(zonas,sat,a); fiuu(sss)=[satt];
72
sat_traz=[fiuu]; end %%%%CALCULO DE SAT CON SENSOR FIJO else figure(1); drawpolygon(sat.x',sat.y',color(mod(k,6)+1) ); sat.original=nn; sat.traza=itt; sss=sss+1; [zonas,a,satt]=calc(zonas,sat,a); fiuu(sss)=[satt]; sat_traz=[fiuu]; end end %%BUCLE DE REPRESENTACIÓN GRÁFICA
figure(2); lab=1; for i=1:a drawpolygon(zonas(1,i).x,zonas(1,i).y, 'r' ); hold on; if repres== 'si' caux=sprintf( '%0.0f' ,lab); ss=polygoncentroid(zonas(1,i).x,zonas(1,i).y ); text(ss(1,1),ss(1,2),caux); lab=lab+1; end if repres== 'no' end end title( 'Zonas de intersección' ); if vario==0 sat_traz=struct([]); end
7.1.2 Código CALC
El código CALC es el encargado de crear una estructura de vectores, cuyos elementos
representan las subregiones en que ha quedado dividida la región de interés ℜ tras su
intersección con todas las adquisiciones consideradas en el problema de planificación.
Brevemente recordamos la notación empleada en el pseudocódigo mostrado en la
Figura 7.14:
• ),( kjjk psa : adquisición tomada por el satélite js en su posición de sensor kp
73
• *r y *SR : nº de subregiones y estructura de vectores de dichas subregiones sin
actualizar, es decir, antes de recalcularlas tras la intersección de la nueva
adquisición tomada.
• r y SR: nº de subregiones generadas y estructura de vectores que contienen las
coordenadas geométricas de dichas subregiones, una vez se han recalculado tras
considerar la nueva adquisición computada ),( kjjk psa .
• iSR: subregión generada por la intersección de la adquisición ),( kjjk psa con la
región de interés ℜ .
La lógica que sigue el código CALC es la siguiente:
a) Cada vez que SATVAR calcula una nueva adquisición ),( kjjk psa , ésta
entra en CALC para actualizar las subregiones generadas. En este
momento, sabemos que el número de subregiones que tenemos antes de
calcular las nuevas subregiones generadas tras considerar la nueva
adquisición ),( kjjk psa es *r y la estructura de vectores cuyos
elementos representan la geometría de cada subregión, *SR .
b) CALC va computando las intersecciones y las diferencias (mediante
POLYGONCLIP) de la adquisición ),( kjjk psa con cada subregión *iSR ,
generando nuevas subregiones (actualizadas) iSR.
c) Este proceso se repite hasta que la adquisición ),( kjjk psa ha sido
comparada con cada subregión *iSR . Las salidas a SATVAR serán ahora
el número de subregiones generadas tras considerar ),( kjjk psa , r y las
nuevas subregiones, contenidas en la estructura de vectores SR.
Este bucle se repite hasta que se han considerado sobre la región de interés ℜ todas las
adquisiciones ),( kjjk psa . Por lo cual, destacar que cada r y SR calculadas para una
74
adquisición ),( kjjk psa , pasarán a ser *r y *SR cuando se considere la adquisición
siguiente.
Tras el paso de todas las adquisiciones, se obtendrá una estructura de vectores final SR,
correspondiente a las subregiones generadas sobre ℜ . Esta estructura será input en el
código MATRIZQVAR así como en el algoritmo heurístico de optimización.
Desde la Figura 7.8 hasta la Figura 7.13 se muestra la evolución que sufren las
subregiones conforme computamos adquisiciones con la región de interés ℜ . En este
caso, se ha escogido como ejemplo el uso de 3 satélites, con 2 posiciones de sensor y un
paso de 1 entre adquisiciones contiguas; por tanto, en las figuras se representa
gráficamente como se actualiza la estructura de vectores correspondiente a las
subregiones conforme vamos introduciendo 2 posiciones de sensor en cada paso
(correspondientes a cada satélite).
Por último, comentar que el código CALC lleva implementado un pequeño bucle que
permite despreciar subregiones de área menor a 0.01 unidades de superficie, lo que hará
que, sin influir sobre el proceso de optimización, el código implementado sea más
rápido y eficiente.
75
Figura 7.8 Subregiones generadas tras el cómputo de 2
adquisiciones
Figura 7.9 2 adquisiciones de satélite
Figura 7.10 Subregiones generadas tras el cómputo de
4 adquisiciones
Figura 7.11 4 adquisiciones de satélites
Figura 7.12 Subregiones generadas tras el cómputo de
6 adquisiciones
Figura 7.13 6 adquisiciones de satélites
76
Figura 7.14 Pseudocódigo empleado en CALC
*
*
),(
SR
r
psa kjjk
i=0
i=i+1
r SR
¿i=r*? No
Sí
POLYGONCLIP
ikjjk
ikjjk
SRpsa
SRpsa*
*
),(
),(
∩
∪
SATVAR
SATVAR Inputs
iSR
77
• Código generado:
function [zonas,a,satt]=calc(zonas,sat,a) % INPUTS: -a: nº de subregiones sin actualizar -sat: adquisición a computar sobre la regi ón de interés -zonas: estructura de vectores donde se gu ardan los polígonos que representan las subregiones generadas, sin actu alizar con la nueva adquisición % OUTPUTS: -zonas: estructura de vectores donde se g uardan los polígonos que representan las subregiones generadas , actualizadas con la nueva adquisición -a: nº total de subregiones actualizada -satt=sat: se devuelve la nueva adquisici ón para ser guardada en una estructura de vectores, creada en S ATVAR
satt=sat; for i=1:a %región de interés R=zonas(i); i1=polygonclip(R,sat,1); if length(i1)==0 f(i)=[R]; g(i)=struct( 'x' ,[0], 'y' ,[0], 'hole' ,0); h(i)=struct( 'x' ,[0], 'y' ,[0], 'hole' ,0); end if length(i1)==1 i2=polygonclip(R,i1,0); if length(i2)==0 f(i)=[R]; g(i)=struct( 'x' ,[0], 'y' ,[0], 'hole' ,0); h(i)=struct( 'x' ,[0], 'y' ,[0], 'hole' ,0); end if length(i2)==1 f(i)=[i1]; g(i)=[i2]; h(i)=struct( 'x' ,[0], 'y' ,[0], 'hole' ,0); end if length(i2)==2 f(i)=[i1]; g(i)=[i2(1,1)]; h(i)=[i2(1,2)]; end
78
end end %La matriz zona se actualiza cada vez que %se termina de calcular las zonas intersección %con el nuevo satélites zonas=[f,g,h]; a=numel(zonas); h=0; for i=1:a if sum(zonas(1,i).x)~=0 & sum(zonas(1,i).y)~=0 d=abs(polygonarea(zonas(1,i).x,zonas(1,i).y)); if d>0.01 h=h+1; t(h)=[zonas(1,i)]; end end end zonas=t; a=numel(zonas);
7.1.3 Código INTVAR
Este código es una base de datos de satélites, o mejor dicho, es una base de datos de la
primera adquisición (original) de cada satélite. Serán usadas por el código SATVAR para
crear el resto de adquisiciones cuando variamos la posición del sensor en cada satélite.
Estas adquisiciones originales se introducen en forma de estructura:
),''],[,''],[,'(' asensorYyXxstructsati = .
Se observan 3 campos en dichas estructuras:
• Campo x: coordenadas X del polígono que modela la adquisición original
• Campo y: coordenadas Y del polígono que modela la adquisición original
• Campo sensor: tendrá valor "0" cuando se considere sensor fijo y "1" cuando el
sensor sea variable. En el modelo I (Sección 2.3.2.1) este campo se pondrá a "0"
mientras que para el modelo II (Sección 2.3.2.2) tendrá un valor "1".
79
Destacar que incluso dentro de un mismo modelo, podemos tener unos satélites con
sensor fijo y otros con sensor variable. Esto es así porque el código SATVAR es capaz de
trabajar con adquisiciones provenientes de satélites con sensor fijo y variable dentro del
mismo problema.
Finalmente, se crea una estructura de vectores denominada poly, cuyos elementos
representan cada una de las adquisiciones originales. SATVAR se encarga de llamar a
cada una de las adquisiciones originales utilizando poly.
• Código generado:
function [poly]=intvar(n) %%%Sensor fijo: Sensor==0 %%%Sensor variable: Sensor==1 r=struct( 'x' ,[0 16 16 0], 'y' ,[0 0 9 9]); sat1=struct( 'x' ,[3 5 5 3], 'y' ,[-2 -2 11 11], 'sensor' ,1); sat2=struct( 'x' ,[-2 18 18 -2], 'y' ,[5 5 7 7], 'sensor' ,1); sat3=struct( 'x' ,[-2 0 16 14], 'y' ,[0 -2 13 14], 'sensor' ,1); sat4=struct( 'x' ,[14 18 -1 -3], 'y' ,[-8 -5 10 8], 'sensor' ,1); sat5=struct( 'x' ,[15 17 17 15], 'y' ,[-2 -2 11 11], 'sensor' ,1); sat6=struct( 'x' ,[-7 -1 13 10], 'y' ,[0 -2 16 17], 'sensor' ,1); sat7=struct( 'x' ,[5 9 27 25], 'y' ,[-6 -8 10 12], 'sensor' ,1); sat8=struct( 'x' ,[4.3 6 26.1 24.3], 'y' ,[-8.4 -9.5 14.7 16], 'sensor' ,1); sat9=struct( 'x' ,[25 27 5 3], 'y' ,[-6 -4 18 16], 'sensor' ,1); sat10=struct( 'x' ,[6 8 0.3 -1.7], 'y' ,[-20.7 -19.1 11.7 11.1], 'sensor' ,1); sat11=struct( 'x' ,[3 4.4 16.3 15], 'y' ,[-6 -6.5 13.7 14.1], 'sensor' ,1); sat12=struct( 'x' ,[16 18 -1.3 -3.3], 'y' ,[-10 -9.4 19.4 19], 'sensor' ,1); sat13=struct( 'x' ,[-9 -8.6 20.7 20.3], 'y' ,[1 -1 9 10.8], 'sensor' ,1); sat14=struct( 'x' ,[-2 18 18 -2], 'y' ,[8 8 10 10], 'sensor' ,1); sat15=struct( 'x' ,[10 11.2 -9.8 -12.45], 'y' ,[-11 -10.6 10.4 10], 'sensor' ,1); sat16=struct( 'x' ,[0.8 4.4 1.8 -1.5], 'y' ,[-10 -9.4 11.6 11], 'sensor' ,1); sat17=struct( 'x' ,[-4 19 19 -4], 'y' ,[-1 -1 1 1], 'sensor' ,1); sat18=struct( 'x' ,[14.3 16 6.4 3.9], 'y' ,[-4 -3.3 17.7 17], 'sensor' ,1); sat19=struct( 'x' ,[2 4 4 2], 'y' ,[-1 -1 10.5 10.5], 'sensor' ,1); sat20=struct( 'x' ,[16 17 0 -1], 'y' ,[-2 -1 14 13], 'sensor' ,1); sat21=struct( 'x' ,[16.8 18.4 4 2.3], 'y' ,[-7 -6.6 15.8 15.5], 'sensor' ,1); sat22=struct( 'x' ,[2 4 22 20], 'y' ,[-3 -5 10 12], 'sensor' ,1); sat23=struct( 'x' ,[6.8 9.3 16.3 13.9], 'y' ,[-3.8 -4.8 11.1 12], 'sensor' ,1); sat24=struct( 'x' ,[6 8 8 6], 'y' ,[-1 -1 10 10], 'sensor' ,1); sat25=struct( 'x' ,[-2 1 17 14], 'y' ,[1 -2 11.3 14.2], 'sensor' ,1); sat26=struct( 'x' ,[5 11 11 5], 'y' ,[-4 -4 12 12], 'sensor' ,1); sat27=struct( 'x' ,[-8 -6 12 10], 'y' ,[-5 -7 18 20], 'sensor' ,1); sat28=struct( 'x' ,[-3 19 19 -3], 'y' ,[3 3 5 5], 'sensor' ,1); sat29=struct( 'x' ,[-2 2 2 -2], 'y' ,[-4 -4 11 11], 'sensor' ,1);
80
sat30=struct( 'x' ,[23 25 -2 -4], 'y' ,[-4 -2 12 10], 'sensor' ,1); sat31=struct( 'x' ,[1 3 13.3 11], 'y' ,[-3 -4 15 16], 'sensor' ,1); sat32=struct( 'x' ,[15 19 3 -1], 'y' ,[-4 0 16 13], 'sensor' ,1); poly=[sat28,sat29,sat30,sat31,sat32,sat6,sat7,sat8, sat9,sat10,sat11,sat12,sat13,sat14,sat15,sat16,sat17,sat18,sat19,sat20 ,sat21,sat22,sat23,sat24,sat25,sat26,sat27,sat1,sat2,sat3,sat4,sat5];
7.2 Algoritmo heurístico de optimización: Código q-GRASP
En esta sección se desarrolla el código implementado para resolver el problema de
planificación EOSs mediante un algoritmo heurístico. Como se comentó en la Sección 3,
el algoritmo utilizado es el GRASP, debido a su mayor probabilidad de encontrar un
óptimo que el algoritmo GREEDY (para k>1).
El pseudocódigo seguido en su implementación está descrito en la Figura 7.15, cuya
notación se describe a continuación:
• Q: matriz Q tridimensional
• SR: región de interés la cual se desea cubrir
• A: conjunto de adquisiciones ),( kjij psa
• num_k: indica entre qué número de elementos, de aquéllos que individualmente
producen la mayor mejora de la función objetivo, escogemos uno aleatoriamente
(en cada iteración)
• num_sol: indica el número de soluciones factibles deseadas
• n: número total de satélites EOSs
• p: número total de modos de sensor
• optSol_ : conjunto de soluciones factibles.
• *optSol : solución escogida entre todas las soluciones factibles calculadas
optSol_ , de la cual se espera sea óptima.
• ),( __ seleckselecj psa : adquisición jka escogida para formar parte como elemento de
una solución factible roptSol_ .
81
Q, SR,A num_k,num_sol
r=0
r=r+1
)):,,(_(
:1
:1
KjitQsumárea
pK
nj
jK =
=∀
=∀
Q_it=Q
Sub_cub=[área]
l=0
Q
MATRIZQVAR
Inputs
l=l+1
82
)_max( cubSubMaxl =
Máximos=[ lMax ]
Seleccionamos aleatoriamente
MáximosMaxl ∈ ,
que se corresponde con
),( __ seleckselecj psa
)],([_ __ seleckselecjr psaoptSol =
Sí
No
0:):,,_(_ =selecjitQ ;
0:),(:,_
1)_,,_(_/
=→
→=∀
iitQ
seleckiselecjitQi
roptSol_
¿l=num_k? No
¿Q_it=[zeros]?
Sí
83
Figura 7.15 Pseudocódigo empleado en q_grasp
Los input del código son Q, SR, A, num_k y num_sol.
num_sol y num_k son índices que determinan, respectivamente, el número de soluciones
factibles que deseamos obtener y entre cuántos elementos individuales en cada iteración
(de entre aquellos que producen una mayor cobertura de las subregiones aún sin cubrir)
elegimos uno aleatoriamente. En proceso seguido es el siguiente:
1. Creamos una matriz Q_it, la cual será modificada conforme se vayan calculando
los elementos que formarán parte de cada solución factible individual. Al
comienzo del cálculo de cada solución factible, se deberá resetear dicha Q_it
igualándola a la matriz Q original.
2. Para todo j (número de satélites que forman el conjunto de EOSs) y para todo k
(número total de posibles modos de sensor en cada satélite), se lleva a cabo la
operación sum[Q_it(j,:,k)], es decir, para cada satélite y para cada modo de
sensor, se calcula el número de subregiones cubiertas por cada adquisición; de
ahí, el sumatorio en el índice i. Es una manera de computar la cobertura de cada
adquisición sobre la región de interés ℜ , ya que recordar que un valor "1" en un
elemento (j, i, k) de la matriz Q indica que la subregión i es cubierta por el
satélite j en su modo de sensor k. Estos sumatorios correspondientes a cada
adquisición se almacenan en una matriz Sub_cub.
)_min(* optSolSolopt =
No
Sí
¿r=num_sol?
84
3. En la matriz Sub_cub, seleccionamos las num_k adquisiciones que mayor
número de subregiones cubren, y de ellas se escoge una al azar,
),( __ seleckselecj psa . Dicha adquisición pasa a ser elemento de una solución
factible individual, roptSol_ .
4. Actualizamos la matriz Q_it para que el programa no pueda volver a elegir una
adquisición tomada por el satélite que a entrado a formar parte de roptSol_ en
ninguno de sus posibles modos de sensor. Para ello, se introducen "0" en los
elementos de la matriz Q_it, que hacen referencia a todas las subregiones y todos
los modos de sensor correspondientes al satélite j seleccionado. Es decir:
0:):,,_(_ =selecjitQ ; así mismo, para que en las siguientes iteraciones no se
tengan en cuenta las subregiones iSR ya cubiertas, hacemos que cuando
1)_,,_(_ =seleckiselecjitQ , haya un "0" en cada elemento de Q_it donde se
encuentre dicha subregión i, para cualquier satélite j y para cualquier modo de
sensor k. Con estas dos operaciones, cumplimos con las restricciones formuladas
en (3) y hacemos que el algoritmo posea memoria.
5. Se repiten los pasos 2 a 4 hasta que Q_it=[zeros], lo que implica que han sido
cubiertas todas las subregiones de ℜ . De esta manera, obtenemos una solución
factible del problema. Si aún no se ha obtenido el número de soluciones
especificadas por num_sol, el programa volverá al paso 1.
6. Una vez que el código ha calculado el número de soluciones factibles
especificadas por num_sol, se elige de entre todas ellas aquélla que utilice un
menor número de adquisiciones. Esta solución es la que devuelve GRASP,
*optSol .
85
• Código generado:
% IMPLEMENTA ALGORITMO GRASP; APORTA LA MEJOR SOLUCIÓN (MÍNIMO Nº DE ADQUISICIONES QUE CUBREN TODA LA REGIÓN OBJETIVO), EL TIEMPO EN ENCONTRARLA Y LA MATRIZ Q ASÍ COMO EL TIEMPO EN CAL CULARLA PARA UN NÚMERO DE ITERACIONES INTRODUCIDAS POR EL USUARIO; SI SE CONOCE EL Nº DE SATÉLITES QUE FORMAN LA SOLUCIÓN ÓPTIMA (A TRAVÉ S DE CPLEX) EL PROGRAMA TERMINA EN EL MOMENTO EN QUE LA ENCUENTRA, NO SIENDO NECESARIO ESPERAR A QUE SE EJECUTEN TODAS LAS ITERACIONES.
function [q,sat_opt,optimo,minimo,satelite,t_q]=q_grasp(n,it ,paso,num_k,num_sol,op,'repres') % INPUTS: -n: nº de satélites -it: nº posiciones de sensor -paso: separación entre adquisiciones cont iguas para un mismo satélite
-num_k: indica de entre qué número de elem entos, de
aquellos que individualmente producen la mayor mejo ra de la función
objetivo, escogemos aleatoriamente uno, para cada i teración de cada
solución individual
-num_sol: número de soluciones factibles dese adas
-op: número de satélites que forman el óptimo , obtenido a
través de CPLEX; si no se conoce la solución de CPL EX, este input
se puede obviar sin más que suprimir el bucle en el que aparece
-repres: 'si' / 'no' dependiendo si querem os numerar las subregiones generadas (en el gráfico) % OUTPUTS: - q: matriz Q tridimensional -sat_opt: conjunto de soluciones factible s -optimo: vector que indica el número de a dquisiciones que forman cada solución -minimo: número de adquisiciones que form an la solución óptima -satelite: posicion de la solucion optima dentro del conjunto de sluciones factibles -t_q: tiempo de computo de matriz Q tridimensional t_q=cputime; [a,zonas,sat_traz,q]=matrizqvar(n,it,paso,repres); t_q=cputime-t_q;
%% CREAMOS UNA MATRIZ "q_it" que será la modificada en cada solución factible independiente %%% IMPLEMENTACION GRASP t_grasp=cputime;
86
for ind_global=1:num_sol q_it=q; suma=1; iter=0;
while suma~=0 iter=iter+1; indice=0; for j=1:n for k=1:it indice=indice+1; a=sum(q_it(j,:,k)); areas(indice)=struct( 'sat_orig' ,j, 'sat_traz' ,k, 'area' ,a); end end suma=0; indices_selec=zeros(num_k,1); aa=numel(areas(1,:)); for l=1:num_k seleccionado=0; for i=1:aa if areas(1,i).area>=seleccionado seleccionado=areas(1,i).area; indice=i; % nos dice la posicion del sat que mas cubre dentro % de la estructura sat_traz else end end indices_selec(l,1)=indice; areas(1,indice).area=0; end d=fix(rand*num_k)+1; %elegimos uno de los maximos al azar d=indices_selec(d,1); %% GUARDAMOS EL SAT SELECCIONADO sat_cobertura(iter)=[sat_traz(1,d)];
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%ACTUALIZACIÓN DE LA MATRIZ 'q_it' ppp=sat_cobertura(1,iter).original; for i=1:numel(zonas) if q_it(sat_traz(1,d).original,i,sat_traz(1,d).traza) ==1 q_it(:,i,:)=0; end end q_it(ppp,:,:)=0; for j=1:n for k=1:it a=sum(q_it(j,:,k)); suma=suma+a;
87
end end sat_opt(ind_global,iter)=struct( 'x' ,sat_traz(1,d).x, 'y' , ... sat_traz(1,d).y, 'original' ,sat_traz(1,d).original, ... 'traza' ,sat_traz(1,d).traza); rmfield(areas, 'area' ); clear areas ;clear sat_cobertura ; end tiempo(ind_global,:)=[ind_global,cputime-t_grasp]; kl=0; for j=1:numel(sat_opt(ind_global,:)) if sum(sat_opt(ind_global,j).x)~=0 & sum(sat_opt(ind_global,j).y) ... ~=0 kl=kl+1; end end if kl==op t_grasp=cputime-t_grasp %% Nos da el tiempo en encontrar la solución óptima, en el caso de que la conozcamos a través del CPLEX keyboard end end
%% Seleccionamos la mejor solución de entre el conj unto de soluciones optimo=zeros(num_sol,1); for i=1:numel(sat_opt(:,1)) kl=0; for j=1:numel(sat_opt(i,:)) if sum(sat_opt(i,j).x)~=0 & sum(sat_opt(i,j).y)~=0 kl=kl+1; end end optimo(i,:)=kl; end [Y,I]=min(optimo); minimo=Y; satelite=I;
