MADRID, JUNIO 2016
Autor: Jose Carlos Padial Diaz-Merino
Director: Francisco Rosales García
Graduado en Ingeniería Informática
Universidad Politécnica de Madrid
Escuela Técnica Superior de Ingenieros Informáticos
TRABAJO FIN DE GRADO
Adaptación a tiempo real de los índices de sincronización HSLMN y SL
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Agradecimientos
Muchas gracias al DATSI por permitirmetrabajar con ellos, en especial a Fran y a Dopicomis tutores durante estos ultimos dos anos.
Muchas gracias tambien a mis padres, a Carmeny a Laura por el apoyo que me han brindadosiempre que lo necesitaba.
Finalmente, quiero dedicar este trabajo a mihermana Marina, decirle que la quiero yrecordarle que, aunque a veces se desespere, conesfuerzo todo es posible.
iii
iv
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Indice general
1. Introduccion 1
1.1. Contexto del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Trabajos Previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Tecnologıas utilizadas en los algoritmos . . . . . . . . . . . . . . . . . . 2
1.3.1. Lenguaje de programacion C . . . . . . . . . . . . . . . . . . . . 2
1.3.2. MatLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.3. OpenMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.4. CUDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Los algoritmos originales 5
2.1. FSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. HSLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Aspectos comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Parametros de entrada . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2. Datos de entrada . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Diferencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1. pref vs k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.2. Varianza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Unificacion de algoritmos 9
3.1. Limpieza de los algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Estudio de prestaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
v
INDICE GENERAL
4. Procesamiento de datos 13
4.1. Almacenamiento del estado en codigo C . . . . . . . . . . . . . . . . . . 13
4.1.1. Variables estaticas . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2. Variables globales . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.3. Variables globales dinamicas . . . . . . . . . . . . . . . . . . . . 15
4.2. Almacenamiento del estado en codigo MatLab . . . . . . . . . . . . . . . 16
4.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Diseno del algoritmo de tiempo real 19
5.1. Naturaleza de los datos de entrada . . . . . . . . . . . . . . . . . . . . . 19
5.2. Uso eficiente de la memoria . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3. Disposicion de los datos en memoria . . . . . . . . . . . . . . . . . . . . 20
5.3.1. Matrices C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.2. Matrices Matlab . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4. Almacenamiento de los datos leıdos . . . . . . . . . . . . . . . . . . . . 24
5.5. Informacion para almacenar globalmente . . . . . . . . . . . . . . . . . 24
6. Estructura HSLMN RT 25
6.1. Inicializacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.1. Lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.2. Almacenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.3. Procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.4. Reempaquetado de los datos . . . . . . . . . . . . . . . . . . . . 28
6.3. Finalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4. Diferencias MatLab y lınea de mandatos . . . . . . . . . . . . . . . . . . 28
6.4.1. Lectura de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.2. Recogida de resultados . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.3. Deteccion del final de lectura . . . . . . . . . . . . . . . . . . . . 29
6.5. Pseudocodigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
vi
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
7. Visualizacion de los resultados 31
7.1. Opciones de visualizacion . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1.1. Redibujar la grafica en cada iteracion . . . . . . . . . . . . . . . 31
7.1.2. Refreshdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1.3. Modificar graficas . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.2. Comparacion de tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.3. Opcion escogida y detalles de la implementacion . . . . . . . . . . . . . 34
8. Resultados obtenidos 35
8.1. Visualizacion de resultados . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.2. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.2.1. Tiempo de ejecucion . . . . . . . . . . . . . . . . . . . . . . . . 39
8.2.2. Uso de memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9. Conclusiones 43
10. Trabajos futuros 45
10.1. Alternativas en la lectura y el almacenamiento de los datos . . . . . . . . 45
10.2. Recogida de resultados en MatLab . . . . . . . . . . . . . . . . . . . . . 46
10.3. Integracion con HERMES . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.4. Paralelizacion usando CUDA . . . . . . . . . . . . . . . . . . . . . . . . 46
10.5. Usos alternativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
vii
INDICE GENERAL
Resumen
En este documento se explica el trabajo realizado sobre algoritmos que calculan los
denominados como “Indices de Sincronizacion Generalizada” h, s, l, m, n y SL, utiliza-
dos para calcular el nivel de correlacion entre dos senales extraıdas del cerebro humano
mediante el uso de la electroencefalografıa y la magnetoencefalografıa, con el objetivo de
estudiar su funcionamiento.
El principal objetivo del proyecto es unificar y transformar estos algoritmos para con-
seguir un unico algoritmo capaz de calcular el valor de estos ındices sobre flujos de datos.
Para ello se realizan estudios sobre como afrontar distintos aspecto asociados al procesa-
miento de datos en tiempo real como pueden ser la incertidumbre de la naturaleza de los
datos o la manera en la que se almacenan.
Abstract
This document will be focused on the work done onto the algorithms that calculate
the “Generalized Synchronization Indices” know as h, s, l, m, n and SL, which allow
comparation between two signals extracted from the human brain via electroencephalo-
graphy and magnetoencephalography in order to find any possible correlation between
them while trying to study the behaviour of the human brain.
Trough this project we will unify and transform these algorithms into a singe algo-
rithm capable of calculating the value of these indices when applied to data streams. Se-
veral studies about how to deal with different aspects associated with real-time processing
such as the uncertain nature of the data or how to store the data we have already read are
treated through the project.
viii
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Capıtulo 1
Introduccion
En los ultimos anos se ha aumentado enormemente la capacidad de computo de los
ordenadores, no tanto por el incremento de la velocidad de los procesadores, sino por el
aumento del numero de operaciones que es capaz de ejecutar en paralelo un solo procesa-
dor. Esto supone una gran ventaja en el campo de la investigacion ya que la mayorıa de las
aplicaciones de calculo cientıfico operan con muchısimos datos y pueden ser facilmente
paralelizables al no depender unos de otros.
En este proyecto en concreto se hace uso de esta capacidad de computo para proce-
sar en tiempo real datos obtenidos de EEG1 y MEG2 con el objetivo de poder estudiar el
comportamiento del cerebro humano ante distintos estımulos. Con los resultados obteni-
dos de este estudio se trata de poder caracterizar y detectar de forma temprana diversas
patologıas como pueden ser Alzheimer o Parkinson.
1.1. Contexto del trabajo
Tras una colaboracion entre el DATSI3 y el CTB4 surgen varios algoritmos para cal-
cular los llamados “Indices de Sincronizacion Generalizada”. Estos ındices son SL5 [1]
y la agrupacion de 5 ındices conocida como HSLMN6 [2], y son utilizados dentro de
HERMES7[3], un toolbox para MatLab desarrollado por el CTB como parte de sus pro-
yectos de investigacion.
Hasta el momento, estos algoritmos operaban sobre un conjunto de datos obtenido
con anterioridad, generando tanto el valor promedio de un ındice para cada par de senales
dadas, ası como las varianza de este. El objetivo de este trabajo consiste en adaptar ambos
1Electroencefalogramas2Magnetoencefalogramas3Departamento de Arquitectura y Tecnologıa de Sistemas Informaticos4Centro de Tecnologıa Biomedica5Synchronization Likelihood6Indices H, S, L, M y N7HERramientas de MEdida de la Sincronizacion
1
CAPITULO 1. INTRODUCCION
algoritmos para que operen sobre flujos de datos, ası como desarrollar una interfaz que
permita visualizar los resultados segun el algoritmo procesa los datos.
Para poder llevar a cabo la tarea se han designado varias fases, siendo las principa-
les unificar los algoritmos HSLMN y FSL8, adaptar el nucleo de la aplicacion para que
funcione en tiempo real, disenar las interfaces para poder invocar ese nucleo bien desde
consola de comandos o bien desde MatLab, para finalmente desarrollar una interfaz de
visualizacion dentro de MatLab.
1.2. Trabajos Previos
Ambos algoritmos han recibido varios cambios y mejoras desde que se empezara a
trabajar sobre ellos en el ano 2011. De estas mejoras destacamos la inclusion de la des-
viacion tıpica como medida de dispersion de los ındices, la funcion de trigger, que permite
obtener resultados parciales de los ındices y base del algoritmo de tiempo real que se desa-
rrolla a lo largo de este trabajo y la posibilidad de trabajar con distintos experimentos de
manera simultanea, cruzando los datos entre ellos.
Ademas de estas mejoras relativas a la naturaleza de los ındices, ambos algoritmos
originalmente secuenciales fueron traducidos del lenguaje MatLab a C, lo que ya de por
si se tradujo en un aumento de las prestaciones de los mismos. Una vez los algoritmos se
tradujeron al lenguaje C se realizo la paralelizacion tanto sobre CPU como sobre GPU,
obteniendo un gran aumento de las prestaciones de los mismos al poder utilizar todos los
nucleos CPU y GPU disponibles.
Ambos algoritmos han pasado por las manos de distintas personas y de ellos han
surgido tanto artıculos cientıficos [4] como Trabajos de Fin de Grado [5], [6]. Todos estos
artıculos han servido como base para aprender tanto el funcionamiento de los algoritmos
como que optimizaciones con las que cuentan y la evolucion de los mismos.
1.3. Tecnologıas utilizadas en los algoritmos
1.3.1. Lenguaje de programacion C
El lenguaje de programacion C es un lenguaje de proposito general desarrollado en
torno al ano 1970 por Dennis M. Ritichie. Se trata de un lenguaje imperativo disenado
para la programacion de sistemas que poco a poco fue ganando popularidad fuera de este
ambito gracias a su gran eficiencia.
En el contexto de este proyecto, es el lenguaje en el que estan escritos todos los algo-
ritmos, aunque disponen de interfaces para ser utilizados desde bien desde el el entorno
MatLab o bien desde lınea de mandatos.
8Fast Synchronization Likelihood
2
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
1.3.2. MatLab
Al hablar de MatLab no nos referimos unicamente al lenguaje de programacion, sino
tambien al entorno disenado para trabajar con el mismo. Este entorno dispone de una serie
de herramientas que permiten tanto cargar datos, como trabajar con ellos y visualizarlos ,
todo a traves de interfaces o de comandos sencillos, caracterıstica que lo convierte en el
entorno ideal para aquellos investigadores que no son expertos en programacion.
Una de las principales caracterısticas de MatLab es su eficiencia al realizar operacio-
nes de calculo tanto vectorial como matricial, no obstante, no es un lenguaje apropiado
para el desarrollo de software de proposito general, al tratarse de un lenguaje interpretado.
Para poder aprovechar tanto el poder que ofrece su entorno de trabajo como las ventajas
de un lenguaje compilado, existe la opcion de utilizar interfaces MEX9, que permiten eje-
cutar codigo en otros lenguajes de programacion, como por ejemplo C o Java, mucho mas
rapidos que MatLab.
1.3.3. OpenMP
OpenMP [7] es una API10 para la programacion de aplicaciones paralelas de memoria
compartida. Esta disponible para los lenguajes C, C++ y Fortran, bajo un gran numero de
plataformas, arquitecturas y sistemas operativos.
OpenMP utiliza directivas de compilacion que le indican al compilador que debe in-
cluir codigo para lanzar multiples hilos de ejecucion que se dividen el trabajo de la seccion
paralela. Permite tambien la utilizacion de variables de entorno para controlar en tiempo
de ejecucion cual es el grado de paralelismo con el que se va a ejecutar la aplicacion
1.3.4. CUDA
CUDA11 [8] es un conjunto de herramientas desarrollado por Nvidia que permiten
desarrollar algoritmos que ejecutan sobre sus GPUs. Mediante un lenguaje de programa-
cion similar a C y un compilador propio se genera codigo que en tiempo de ejecucion se
ejecutara sobre la GPU en lugar de hacerlo sobre la CPU.
Ademas de las herramientas basicas, CUDA incluye la biblioteca Thrust [9], que ofre-
ce un gran abanico de primitivas como por ejemplo scan, sort o reduce con opcion para
poder ejecutarse tanto sobre CPU como sobre GPU.
9MatLab Executable10Interfaz de Programacion de Aplicaciones11Compute Unified Device Architecture
3
CAPITULO 1. INTRODUCCION
4
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Capıtulo 2
Los algoritmos originales
Estos algoritmos surgieron como herramientas para poder calcular los niveles de sin-
cronizacion entre las ondas emitidas por el cerebro humano y ası tratar de comprender
mejor su funcionamiento, pudiendo llegar incluso a utilizarse para detectar en fases tem-
pranas ciertas ciertas enfermedades neurodegenerativas como pueden ser el Alzheimer o
el Parkinson, lo que permite controlarlas con un tratamiento adecuado y evitar que sigan
desarrollandose, o incluso curarlas.
En este capıtulo no se pretende explicar la base matematica que hay detras de ellos,
disponible en sus respectivos artıculos [1], [2], sino explicar los aspectos de implementa-
cion que es necesario conocer y que se mencionan a lo largo de todo el trabajo.
2.1. FSL
El algoritmo FSL [4] es una version optimizada tanto tanto en tiempo de ejecucion co-
mo en uso de memoria del algoritmo SL, que calcula la correlacion o sincronizacion entre
un conjunto de canales obtenidos como resultado de analisis de las ondas cerebrales de
un paciente mediante el uso de cascos de electroencefalografıa y magnetoencefalografıa.
Estos cascos estan equipados con multiples sensores que registran la actividad cerebral
del paciente. Cada sensor del casco produce informacion atribuida a un canal que luego
sera comparada contra el resto de canales dentro de la ventana de tiempo que se le indique
para ası poder comprobar tanto efecto de distintos estımulos sobre el paciente como que
areas del cerebro se estimulan.
2.2. HSLMN
De manera similar al algoritmo FSL, el algoritmo HSLMN permite calcular 5 ındices
de sincronizacion generalizada que proporcionan distintas medidas de sincronizacion o
correlacion entre cada par de canales de entrada.
5
CAPITULO 2. LOS ALGORITMOS ORIGINALES
Este algoritmo permite calcular los 5 ındices a la vez procesando cada experimen-
to una unica vez, que facilita la labor a los investigadores al proporcionarles un mayor
numero de medidas de correlacion sin que el tiempo que se necesita para calcularlas se
vea gravemente impactado.
2.3. Aspectos comunes
Ambos algoritmos tienen una estructura similar, ya que estan formados por un nucleo
que se encarga de procesar los datos leıdos desde un fichero y de calcular el valor pro-
medio de los ındices y por un conector que permite que el usuario interactue con este
nucleo bien desde MatLab o bien desde consola de mandatos. Otra caracterıstica comun
a ambos algoritmos es una division logica en tres fases, lectura de los datos, parametros
de configuracion y comprobaciones sobre los mismos, analisis de los datos y calculo de
los valores promedio de los ındices.
Como se ha mencionado anteriormente, tanto el algoritmo FSL como el algoritmo
HSLMN han pasado por varias iteraciones desde que fueron creados. La version que
existıa en la fecha de comienzo de este trabajo y que se ha utilizado como base para
la unificacion y la creacion del algoritmo de tiempo real es la version C optimizada y
paralelizada sobre CPU con OpenMP.
En los siguientes apartados se detallan las caracterısticas que comparten ambos algo-
ritmos relevantes en este trabajo.
2.3.1. Parametros de entrada
Ambos algoritmos reciben diversos parametros de entrada que definen su comporta-
miento y como deben procesar los datos. Estos parametros, junto con otros que se obtienen
de ellos son:
l Tambien conocido como τ , que se usa junto con el parametro m para representar el
estado de una senal en un instante de tiempo.
m Se usa junto con el parametro l y que representa la dimension del vector que se utiliza
en en cada instante para representar el estado de una senal.
x Indica el tamano de la ventana de exclusion. Esta ventana de exclusion se utiliza para
descartar los x vecinos mas cercanos a la hora de calcular el valor de los ındices y
ası evitar la auto-correlacion entre datos cercanos.
w Indica el tamano de la ventana de inclusion. Esta ventana limita el numero de vecinos
cercanos al punto que se esta procesando que se estudian para calcular el valor de
los ındices, ya que aquellas muestras muy alejadas de la que se esta procesando
pueden no ser relevantes para esta.
6
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Ventana Numero de vecinos que se estudian para procesar cada muestra y que equivale
a 2 ∗ (w − x). Cabe destacar que en los extremos de los datos puede no existir un
numero suficiente de vecinos para hacer el calculo completo y sea necesario realizar
el calculo con un numero menor de vecinos.
c Numero de canales de los datos. Es posible indicarle este valor al algoritmo, pero si no
se indica, se calcula automaticamente al recibir los datos de entrada.
d Numero de muestras de los datos. Al igual que sucede para el parametro c, es posible
indicarle este valor al algoritmo, pero si no se indica, se calcula automaticamente al
recibir los datos de entrada.
trigger Indica cada cuantas muestras se van a a volcar los resultados parciales. No es un
parametro propio del algoritmo, sino que indica al programa que se debe realizar
un volcado de datos parcial tras procesar un bloque de trigger muestras.
2.3.2. Datos de entrada
Ambos algoritmos reciben como entrada un fichero de texto plano con los datos pro-
ducidos por un experimento de una longitud determinada.
Estos datos estan organizado de tal manera que existen tantas filas como muestras se
hayan recogido durante ese experimento y en cada fila aparece un valor por cada canal
que se quiera estudiar.
Ası, si se ha realizado un experimento de 10 segundos de duracion, con un a velocidad
de muestreo de 250Hz, en el que se muestrea la informacion procedente de 4 sensores, el
fichero de entrada asociado a ese experimento estara formado por 2500 filas y 4 columnas,
almacenando la informacion de 10000 datos.
Es de estos ficheros de entrada de donde el algoritmo obtiene el numero de canales y
de muestras del experimento que se esta procesando. Es importante tener en cuenta que
el numero de canales permanece constante a lo largo de todo el experimento, por lo que
los algoritmos comprueban que permanezca constante mientras leen los datos de entrada
y emiten un error si no es ası.
2.4. Diferencias
Aunque las diferencias entre ambos algoritmos no son significativas (fuera de la parte
relativa al calculo de los ındices), existen algunos factores que aunque son similares, no
es posible realizar una equivalencia entre uno y otro.
7
CAPITULO 2. LOS ALGORITMOS ORIGINALES
2.4.1. pref vs k
Ambos algoritmos calculan la distancia euclıdea de un vector definido por los parame-
tros m y l entre el dato que se esta estudiando y cada uno de los datos dentro de la ventana
que rodea a ese dato. No obstante, cada algoritmo determina de manera distinta cuantos
de los vecinos cercanos se consideran a la hora de calcular el valor del ındice.
Mientras que algoritmo FSL utiliza el concepto pref, indicando que porcentaje de
los vecinos mas cercanos se utiliza a la hora de calcular el valor de los ındices para cada
dato, el algoritmo HSLMN se basa en un numero, conocido como k, que indica que se
utilizan los k vecinos mas cercanos para calcular el valor de los ındices.
A la hora de introducir el calculo del ındice SL dentro del algoritmo SL es necesario
recordar que el valor de los ındices se ve ligeramente modificado en los extremos, pues
el concepto de pref escala si no se dispone de la ventana completa para calcular los
ındices, mientras que el concepto de k no lo hace.
2.4.2. Varianza
Con el algoritmo HSLMN se calcula no solo el valor promedio de cada ındice, sino
tambien la varianza de este que permite estimar como de fiable es el ındice calculado.
Contrastando con esto, algoritmo FSL no implementa ningun tipo de medida de dispersion
que permita estimar la fiabilidad de los resultado obtenidos.
2.5. Conclusiones
Debido a estas similitudes, se planteo como paso previo a la adaptacion a tiempo real
unificar los algoritmos para ası reducir el esfuerzo necesario para adaptarlos a tiempo real
al tener que realizar la labor con un unico algoritmo en lugar de con dos.
Al unificar los algoritmo no solamente se consigue simplificar y agilizar la adaptacion
a tiempo real, sino que tambien se consigue reducir el tiempo necesario para conocer el
valor de todos los ındices, pues el usuario puede disponer de un algoritmo que procese
calcula todos los ındices procesando el fichero una unica vez.
8
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Capıtulo 3
Unificacion de algoritmos
Para adaptar el calculo de los ındices a tiempo real era conveniente disponer de un
unico algoritmo en el que se realiza de manera simultanea el calculo de los 6 ındices (H,
S, L, M, N y SL), en lugar de tener que utilizar dos algoritmos distintos. Este algoritmo
unificado permite eliminar la necesidad de procesar un fichero varias veces y la redun-
dancia que introducen operaciones ajenas al calculo de los ındices como tal, tales como
la lectura de los datos o la ordenacion de las distancias entre canales, comunes a ambos
algoritmos.
Puesto que el algoritmo HSLMN calcula los 5 ındices en una unica ejecucion, se
opto por anadir el calculo del ındice SL al algoritmo HSLMN, que ya calcula de manera
simultanea varios ındices y dispone de opciones relacionadas con este aspecto, como por
ejemplo, excluir los ındices que no se quieran calcular y ası acelerar reducir el tiempo
necesario para calcular los otros.
A la hora de incluir el calculo del ındice SL dentro del algoritmo HSLMN fue nece-
sario adaptar el concepto de pref, al concepto de k, originario del HSLMN. Como se
ha explicado en el capıtulo anterior, aunque ambos conceptos representan lo mismo en
los extremos de la senal donde no se dispone de suficientes datos para llenar la ventana,
la densidad de datos con la que se calculan los ındices es distinta, lo que se traduce en
pequenas variaciones en el resultado final.
Para poder comprobar que la unificacion de los algoritmos se ha realizado de manera
satisfactoria, disponemos de una baterıa de pruebas con unos datos de entrada y un resulta-
do conocido. Estas pruebas se dividen en dos tipos, aquellas que utilizan datos sinteticos,
conocidas como da, “4x4000” o simplemente “data” y aquellas que utilizan los datos de
una prueba real, conocidas como “pt”, “148x50863” o “paciente test”.
3.1. Limpieza de los algoritmos
El primer paso antes de unificar los algoritmos consiste en reorganizar y refactorizar
el codigo del algoritmo HSLMN, pues aunque originalmente el algoritmo HSLMN se
9
CAPITULO 3. UNIFICACION DE ALGORITMOS
diseno para poder incluir el calculo de mas ındices en el algoritmo, el modo en el que este
se programo originalmente no permite incluir un ındice mas sin tener modificar la gran
parte del codigo.
El principal impedimento lo encontramos en las variables utilizadas para almacenar
los resultados de los ındices, pues el algoritmo disponıa de variables distintas variables
sobre las que se realizaban siempre las mismas operaciones, en lugar de agrupar las dichas
variables dentro de un mismo array, lo que se traduce en duplicidad de codigo cada vez
que que querıa realizar una accion sobre todos los ındices.
Al almacenar cada ındice como una entrada en un array es posible simplificar el codigo
eliminando en torno a un 1/3 del mismo, puesto que donde antes habıa varias lıneas de
codigo, una para cada ındice, ahora hay una unica operacion que se ejecuta sobre todos
los miembros de un array.
Esta limpieza del algoritmo HSLMN no ha tenido ningun impacto ni en las prestacio-
nes ni en la manera en la que se utiliza el algoritmo, ya que se trata de una refactorizacion
que solo afecta a la parte interna del mismo.
3.2. Estudio de prestaciones
Para estudiar las prestaciones del algoritmo unificado frente a los algoritmos origi-
nales, se han realizado 1000 ejecuciones de cada una de las pruebas, siempre sobre la
maquina Espino, con las mismas condiciones de carga de la maquina y las mismas opcio-
nes de compilacion, para tratar de minimizar la influencia que causas ajenas al algoritmo
puedan influir en los resultados.
Si lo que nos interesa es calcular el valor de todos los ındices, la opcion mas intere-
sante es sin duda utilizar el algoritmo unificado, indicando a la hora de ejecutarlo que
queremos el resultado de todos los ındices, ya que el tiempo de este es claramente infe-
rior al resultante de ejecutar el algoritmo HSLMN para calcular parte de los ındices y el
algoritmo FSL para calcular el restante.
Como se puede observar en la Figura 3.1 en la que aparecen ordenados los tiempos
de estas 1000 ejecuciones, al promediar los resultados realizados sobre los datos del ex-
perimento “4x4000”, podemos calcular que el tiempo necesario para calcular todos los
ındices es un 46 % mejor cuando se utiliza el algoritmo unificado. En el caso de los resul-
tados del experimento de datos reales, reflejada en la Figura 3.2, se obtiene el valor de los
6 ındices un 10 % mas rapido que utilizando ambos algoritmos por separado.
Aunque se muestra una clara disminucion del tiempo necesario para calcular todos
los llamados “Indices de Sincronizacion Generalizada” no todo son ventajas, ya que el
algoritmo HSLMN necesita realizar la ordenacion de todos los elementos cercanos al
cada punto estudiado para poder calcular el valor del ındice L, por lo que ordena mas
elementos de los que necesita el ındice SL.
Esta situacion que se ve reflejada en ambas figuras, al ser el tiempo de calcular uni-
10
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
camente el ındice SL muy similar al de calcular todos los ındices cuando se utiliza el
algoritmo unificado. Si nos fijamos en la Figura 3.1 asociada al experimento con datos
sinteticos, podemos observar como el tiempo necesario para calcular el ındice SL es apro-
ximadamente un 15 % mayor utilizando el algoritmo unificado. Para las pruebas con datos
reales de la Figura 3.2 el algoritmo unificado necesita el triple de tiempo que el algoritmo
FSL para calcular el unicamente ındice SL, ya que tiene que realizar la ordenacion que se
ha mencionado anteriormente.
Figura 3.1: Comparacion tiempos FSL y HSLMN(4x4000)
Figura 3.2: Comparacion tiempos FSL y HSLMN(148x50863)
11
CAPITULO 3. UNIFICACION DE ALGORITMOS
12
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Capıtulo 4
Procesamiento de datos
Para estudiar como funcionara el algoritmo de tiempo real se han desarrollado una
serie de prototipos sencillos con un funcionamiento muy similar a la version MatLab del
algoritmo de tiempo real.
Estos prototipos reciben varios vectores columna desde MatLab, devolviendo en cada
llamada la suma de los datos que reciben y anadiendo este valor a un total, que persiste
entre llamadas y que contiene la suma de todos los datos recibidos hasta el momento.
Un aspecto que es necesario tener en cuenta tanto con estos prototipos con el algoritmo
de tiempo real es que tanto el tamano de los datos con los que se llama al algoritmo como
el numero de veces que se hace pueden.
Uno de los principales intereses es comprobar como se mantener el estado entre las
llamadas para estudiar si este estado iba a ser almacenado dentro de MatLab, lo que sim-
plificarıa el programa al recibir el estado en cada llamada, pero ralentizarıa cada llamada
al aumentar la transmision de informacion entre MatLab y el algoritmo, o si, por el con-
trario, es el propio algoritmo el que almacena el resultado de los datos procesados hasta
el momento.
4.1. Almacenamiento del estado en codigo C
4.1.1. Variables estaticas
La primera alternativa estudiada almacena la suma total entre llamadas mediante el
uso de variables estaticas declaradas dentro del codigo. Esta es una solucion valida para
el prototipo sencillo, sin embargo, la visibilidad de este estado almacenado queda limitada
al ambito en el que se define la variable, lo que complica trabajar con la aplicacion real
al ser necesario ir pasando el estado entre las distintas funciones de las que se preve que
este formada la misma.
13
CAPITULO 4. PROCESAMIENTO DE DATOS
sumaStatic.c
1 #include <mex.h>2
3 void mexFunction(int nlhs, mxArray *plhs[],4 int nrhs, const mxArray *prhs[]){5
6 static double sum = 0;7 /* Input matrix */8 double *data;9 data = mxGetPr(prhs[0]);
10 /* Input size */11 int M = mxGetM(prhs[0]);12
13 /* Output value */14 double *result;15 plhs[0] = mxCreateDoubleMatrix(1,1,mxREAL);16 result = mxGetPr(plhs[0]);17
18 /* Fill sum with the sum of the input */19 int i;20 for (i = 0; i < M; ++i) {21 sum += data[i];22 }23
24 *result = sum;25
26 }
4.1.2. Variables globales
Para solucionar el problema del ambito se modifico el primer prototipo, transforman-
do la variable que en un principio era estatica en una variable global. Este cambio permitıa
que, al igual que en el caso anterior, la variable conservara su valor entre llamadas, au-
mentando la el ambito de la variable, que ya no queda limitada a la seccion en la que se
define, sino que es accesible desde cualquier funcion que la necesite.
sumaGlobal.c
1 #include <mex.h>2 double sum = 0;3
4 void mexFunction(int nlhs, mxArray *plhs[],5 int nrhs, const mxArray *prhs[]){
14
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
6
7 /* Input matrix */8 double *data;9 data = mxGetPr(prhs[0]);
10 /* Input size */11 int M = mxGetM(prhs[0]);12
13 /* Output value */14 double *result;15 plhs[0] = mxCreateDoubleMatrix(1,1,mxREAL);16 result = mxGetPr(plhs[0]);17
18 /* Fill sum with the sum of the input */19 int i;20 for (i = 0; i < M; ++i) {21 sum += data[i];22 }23
24 *result = sum;25
26 }
4.1.3. Variables globales dinamicas
El prototipo sencillo puede almacenar todo su estado en una variable tipo doublesin ningun problema, pero en el caso de una aplicacion real es necesario almacenar un
estado mucho mas complejo, que no es posible conocer completamente en tiempo de
compilacion. Para poder solventar este problema se convierte la variable global en un
puntero que la aplicacion se encargara de de manejar, inicializando la region de memoria
que sea necesaria para cada caso y trabajando con ella como necesite.
sumaMalloc.c
1 #include <mex.h>2
3 double *ptr = NULL;4
5 void* calloc(size_t n, size_t size){6 return mxCalloc(n,size);7 }8
9 void mexFunction(int nlhs, mxArray *plhs[],10 int nrhs, const mxArray *prhs[]){11
15
CAPITULO 4. PROCESAMIENTO DE DATOS
12 /* Input matrix */13 double *data;14 data = mxGetPr(prhs[0]);15 /* Input size */16 int M = mxGetM(prhs[0]);17
18 /* Output value */19 double *result;20 plhs[0] = mxCreateDoubleMatrix(1,1,mxREAL);21 result = mxGetPr(plhs[0]);22
23 /* If this is the first call, initialize the memory space */24 if (ptr == NULL) {25 ptr = calloc(1, sizeof(int));26 }27
28 /* Fill sum with the sum of the input */29 int i;30 for (i = 0; i < M; ++i) {31 *ptr += data[i];32 }33
34 *result = *ptr;35
36 }
4.2. Almacenamiento del estado en codigo MatLab
Para el ultimo prototipo, en el que el estado se guarda en MatLab, se ha creado un
objeto de sistema MatLab (que hereda de la clase matlab.System). Este objeto dispo-
ne de una interfaz predefinida que se ejecutan con llamadas a setup(obj,<args>),
step(obj,<args>) y reset(obj,<args>), entre otras, y que proporcionan una
interfaz perfecta para procesar datos en tiempo real, al poder inicializar la aplicacion,
procesar un fragmento de los datos y reiniciar el estado de la aplicacion utilizando los
metodos estandar que se utilizan en otras aplicaciones de tiempo real en MatLab.
sumaSystem.m
1 classdef sumaSystem < matlab.System2
3 properties (Nontunable)4 data;5 end6
16
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
7 properties (Access = private)8 data_sum;9 end
10
11 methods12 % Constructor13 function obj = sumaSystem(data)14 obj.data = data;15 end16 end17
18 methods (Access = protected)19 %% Common functions20 function setupImpl(obj,u)21 obj.data_sum = 0;22 end23
24 function y = stepImpl(obj,i)25 obj.data_sum = obj.data_sum + sum(obj.data(:,i));26 y = obj.data_sum;27 end28
29 function z = getDiscreteStateImpl(obj)30 z = struct(’sum’, obj.data_sum );31 end32
33 end34 end
4.3. Conclusiones
Habiendo evaluado las distintas alternativas de las que disponemos para almacenar el
estado en el caso de la version MatLab, se ha optado por almacenar todo el estado dentro
del fichero mex, sobre las mismas variables globales que utiliza la version de linea de
mandatos. Se espera ası poder reducir al mınimo las diferencias a nivel de codigo entre
estas dos versiones.
Al observar la potencia que proporcionan los objetos de sistema de MatLab, se deci-
dio presentar la interfaz de MatLab como un objeto de estos, que enlace con el fichero
mex correspondiente, facilitandole los datos que se quieran procesar en cada momento,
que sera el que interactua con el nucleo de la aplicacion de manera similar a como harıa
la funcion main de la version desde lınea de mandatos..
17
CAPITULO 4. PROCESAMIENTO DE DATOS
18
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Capıtulo 5
Diseno del algoritmo de tiempo real
A la hora de adaptar un algoritmo para su aplicacion en tiempo real es necesario
considerar las diferencias que existen entre el procesamiento de datos estandar, con un
tamano fijo frente al procesamiento de datos con tamano y velocidad de llegada variable.
En el caso de este algoritmo en concreto, al que hemos decidido llamar HSLMN RT1,
tambien se han tenido en cuenta una serie de factores propios del algoritmo que, en el
caso de ser descuidados, tendrıan un gran impacto en la eficiencia del mismo.
5.1. Naturaleza de los datos de entrada
El algoritmo debe estar preparado para recibir un numero variable de muestras por
la entrada, pues la informacion que recibe no tiene por que llegar de manera uniforme y
ni se pueden ni se deben hacer asumpciones sobre el tamano de la misma. Como se ha
mencionado anteriormente, lo que si que ha de permanecer constante es el tamano de cada
una de las muestras que se reciben en cada etapa.
5.2. Uso eficiente de la memoria
El algoritmo original necesita almacenar en memoria la totalidad de los datos que va a
procesar para luego procesarlos de principio a fin. Una las caracterısticas imprescindibles
del nuevo algoritmo es la capacidad para procesar los datos reteniendo unicamente los
datos necesarios para procesar el siguiente fragmento, descartando los datos que ya no le
sean de utilidad.
Gracias a esta caracterıstica el algoritmo es capaz de procesar cualquier cantidad de
datos sobre un espacio de memoria limitado, como se puede observar en el apartado 8.2.2,
donde se estudia la memoria que utiliza el algoritmo para una serie de datos de entrada
cada vez mayor.
1HSLMN Real Time
19
CAPITULO 5. DISENO DEL ALGORITMO DE TIEMPO REAL
5.3. Disposicion de los datos en memoria
El algoritmo recorre los datos para procesarlos, primero procesando todos los instantes
de un canal y luego procesando el resto de canales, por lo que debemos de procurar que
reciba los datos ası dispuestos en memoria para que los accesos a datos se realicen a traves
de las memorias caches, minimizando ası el tiempo que se pierde cuando el sistema tiene
que traer los datos de memoria principal.
A la hora de trabajar con matrices podemos verlas como un conjunto de filas con
varios elementos en cada fila o como un conjunto de columnas con varios elementos en
cada columna.
Si consideramos las matrices como un conjunto de filas, estamos ante lo que se conoce
como matrices row-major, en las que 2 elementos consecutivos de la misma fila, aparecen
contiguos en memoria.
En el otro caso, en el que vemos las matrices como un conjunto de columnas, se habla
de matrices column-major, ya que los elementos que aparecen contiguos en memoria son
los de la misma columna.
Para referirnos a un elemento en concreto de un a matriz lo haremos indicando primero
el numero de la fila y luego el numero de columna de la matriz. El ındice del primer
elemento de cada fila o columna puede variar de un lenguaje a otro, pues hay algunos que
empiezan a indexar en 0 y otros que lo hacen en 1.
5.3.1. Matrices C
El lenguaje de programacion C no conoce el concepto de matriz, pero si conoce el
concepto de vector o array, definido por una una direccion de memoria que considera el
origen y un desplazamiento mediante el cual accede a los elementos del mismo.
Este concepto de vector fuerza que el primer elemento del vector sea el elemento
numero 0, pues el primer elemento del vector es el que se encuentra en la direccion donde
comienza el vector, con desplazamiento de 0 elementos.
Jugando con este concepto de vector y/o con varios de los mismos, en C se puede
trabajar con matrices de diferentes maneras. En los siguientes apartados se mencionan
algunas formas que se utilizan dentro del algoritmo, junto con sus ventajas e inconvenien-
tes.
Matrices compactas
Este tipo de matriz esta almacenada en memoria como un bloque de memoria con-
secutivo, de tal manera que en dos direcciones de memoria consecutivas aparecen dos
elementos consecutivos. Al llegar al final de una fila, el siguiente elemento que aparece
es el primero de la fila siguiente.
20
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Con estas matrices el acceso a los datos de la misma es bastante rapido, pues todos los
elementos estan en la misma region, por lo que al acceder a un dato se lleva a memoria
cache un bloque de memoria que contiene toda o gran parte de la matriz.
Sin embargo, no todo son ventajas, pues su uso de cara al usuario es bastante molesto,
ya que al estar considerando la matriz como un vector es este el que debe calcular la
posicion del elemento multiplicando el ındice de la fila a la que desea acceder por el
numero de columnas y sumandole el ındice de la columna que desea.
M(i, j) → M [i ∗ nColumnas+ j]
Figura 5.1: Matriz compacta almacenada por filas
Multiples vectores
En este tipo de matriz se realiza el acceso a los datos utilizando dos tipos de vectores
distintos, por un lado vectores que contienen a las filas y por otro lado un vector que
contiene cada una de las filas que forman la matriz. En este tipo de matrices no es posible
asegurar que los vectores que contienen los valores de las filas aparezcan consecutivos
en memoria, ya que al realizar la reserva de espacio, estos pueden quedar alojados en
cualquier parte del heap.
Almacenar una matriz de esta manera hace los accesos a los elementos mas lentos, ya
que es necesario acceder primero al vector de la fila que queremos consultar y luego a la
columna que nos interese, aunque facilita la labor del programador ya que simplemente
ha de indicar los ındices de la fila y la columna a la que desea acceder.
M(i, j) → M [i][j]
21
CAPITULO 5. DISENO DEL ALGORITMO DE TIEMPO REAL
Figura 5.2: Matriz formada por multiples vectores
Como este tipo de matrices se suele almacenar en el heap del programa acceder a los
datos de una misma fila es relativamente rapido (aunque mas lento que el caso anterior por
la necesidad de pasar antes por el vector de filas), pero acceder a dos filas distintas muy
lento, ya que, como se ha explicado antes, al reservar espacio para la matriz esta puede
estar distribuida por toda la memoria.
VLA
Una solucion intermedia entre los dos tipos anteriores la encontramos en los VLA2,
vectores n-dimensionales para los que el compilador reserva en tiempo de ejecucion un
espacio de memoria compacto donde almacenarlos. Este espacio, a pesar de ser compacto,
puede ser accedido utilizando la misma sintaxis que en el ejemplo anterior.
M(i, j) → M [i][j]
Figura 5.3: Matriz VLA almacenada por filas
La principal ventaja de este tipo la encontramos a la hora de acceder a los datos,
pues al tratarse de un bloque de memoria compacto no es necesario acceder primero al
vector intermedio para luego acceder al dato. La principal desventaja de este tipo aparece
al trabajar con matrices de muchos elementos, pues el programa reserva estas matrices
sobre la pila, un recurso limitado que terminara con la ejecucion del programa si se agota.
2Array de tamano variable (Variable Length Array)
22
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
M2D
Existe un tipo de matrices, que internamente denominamos M2D3 en la que se guardan
de manera compacta los elementos de cada fila, precedidos de una cabecera que indica
donde comienza cada una de las filas. Con esta configuracion todo lo necesario para acce-
der a la matriz esta en la misma region de memoria y el acceso a los elementos es sencillo
para el programador.
M(i, j) → M [i][j]
Figura 5.4: M2D almacenada por filas
Esta matriz no elimina el primer acceso para conocer la localizacion de la fila pero
sı que lo acelera al asegurar que toda la informacion necesaria esta en el mismo bloque
que los datos de la matriz.
El principal problema de estas matrices es su creacion, ya que es el programador el
que tiene que reservar el espacio de memoria correspondiente a los datos y a la cabecera,
que luego ha de rellenar con la posicion de memoria correspondiente al comienzo de cada
una de las filas.
5.3.2. Matrices Matlab
Matlab es un lenguaje de mas alto nivel y matematico, disenado para trabajar con
matrices. Sus operaciones sobre matrices son mucho mas potentes que las de C, ya que el
propio lenguaje incluye operadores para sumar, restar, multiplicar, trasponer... matrices.
Ya que matlab esta disenado para realizar operaciones con matrices, el primer elemen-
to de la matriz es el elemento numero 1, al igual que ocurre en las matrices en matemati-
cas.
Matrices dispersas
Este tipo de matrices solo almacenan aquellos elementos que no son nulos. MatLab
es capaz de trabajar con ellas sin ningun problema, pero tratar con ellas a bajo nivel es
complicado, por lo que no se tendran en cuenta de cara al algoritmo.
3Matriz 2D
23
CAPITULO 5. DISENO DEL ALGORITMO DE TIEMPO REAL
Matrices completas
Son el principal tipo de matrices que se utilizan dentro de MatLab, matrices que al-
macenan todos los elementos que contienen, nulos o no. Ademas de todos estos datos,
las matrices almacenan una pequena cabecera indicando el numero de dimensiones de la
misma y la longitud de estas dimensiones, entre otros datos.
A la hora de trabajar con ellas desde una interfaz MEX la matriz aparece como un
bloque de memoria compacto y transpuesto. Esta transposicion es debida la manera en la
que MatLab almacena sus matrices, agrupando los valores por columnas en lugar de por
filas.
Figura 5.5: Matriz compacta almacenada por columnas
5.4. Almacenamiento de los datos leıdos
Como el algoritmo debe invertir la menor cantidad posible de tiempo en las fases de
lectura y almacenamiento de los datos se ha optado por utilizar un bloque de memoria
compacto para los datos todavıa sin procesar, que el algoritmo transpone y transforma en
una M2D antes de realizar el calculo de los ındices.
Aunque este metodo podrıa parecer poco optimo ya que es necesario transponer los
datos almacenados cada vez que se va a procesar un fragmento, si quisieramos guardar
los datos tal y como los recibe el algoritmo serıa necesario segmentar los datos de entrada
para copiarlos uno a uno a su lugar de destino correspondiente, anadiendo una logica y
una serie de calculos que habrıa que ejecutar cada vez que se lee un fragmento y que no
impide que luego sea necesario transformar la matriz en una M2D, ya que estas matrices
no pueden ser redimensionadas facilmente, por lo que no son apropiadas para un buffer
en el que el tamano varıa frecuentemente.
5.5. Informacion para almacenar globalmente
Junto con los datos que lee el algoritmo se deben almacenar tanto los parametros
necesarios para procesar un fragmento como las matrices sobre las que se calculan los
resultados parciales de cada etapa y el resultado final que genera el algoritmo una vez ha
leıdo todos los datos.
Ya que toda esta informacion debe estar disponible para el algoritmo desde el principio
del mismo se ha optado por reservar la memoria necesaria e inicializar todos los valores
que sea posible una unica vez al principio y reutilizarlos hasta que el algoritmo llegue a
su fin.
24
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Capıtulo 6
Estructura HSLMN RT
Como ya se ha ido mencionado a lo largo de todo este documento, es necesario al-
macenar un estado global que mantenga tanto los datos que se han leıdo como cierta in-
formacion necesaria para procesarlos. Estos informacion se almacena dentro de un struct
llamado rt state.
Dada la naturaleza del algoritmo HSLMN RT podemos dividirlo en tres fases, una
de inicializacion, una de procesamiento, que se ejecuta multiples veces y una fase de
finalizacion y limpieza, que aparecen explicadas al lo largo de este capıtulo. Al final del
mismo se tambien incluye una version del algoritmo en pseudocodigo.
6.1. Inicializacion
Esta primera fase ha de ejecutarse antes de poder empezar a procesar, pues es el punto
donde se reserva toda la memoria que necesita el programa para su correcto funciona-
miento y donde se inicializan todas las variables globales que se van a utilizar.
En esta primera version se reserva espacio para las matrices que almacenan el valor
promedio de los ındices, para las que almacenan los resultados parciales y para el buffer
de memoria en el que almacenar el los datos que utiliza el algoritmo para calcular los
ındices. Es en este ultimo punto donde surgen la mayor parte de las dudas, pues debemos
decidir cuanto espacio hay que reservar.
Debemos tener en cuenta que, salvo en los extremos de los datos, donde la informacion
es mas limitada, el algoritmo necesita disponer de la informacion de 2*w muestras, wanteriores y w posteriores, para poder procesar correctamente una muestra concreta.
Para que el algoritmo pueda almacenar datos que aun no estan procesados, nece-
sitamos reservar una cantidad de espacio mayor, que para esta primera version es de
3*(2*w), que permite que se procesen un maximo de 2*(2*w) muestras en la si-
guiente iteracion.
Ademas de reservar los bloques de memoria que acabamos de mencionar, en esta fase
25
CAPITULO 6. ESTRUCTURA HSLMN RT
se inicializan los siguientes campos, que se utilizan durante todo el algoritmo:
first sample Primera muestra de los datos almacenados que el algoritmo debe procesar.
Es necesario disponer este campo ya que despues de la primera iteracion el buffer
con los datos leıdos contiene datos ya han sido procesados pero que todavıa son
necesarios para procesar las siguientes muestras.
last sample Ultima muestra de los datos almacenados que el algoritmo debe procesar.
Dado que el algoritmo necesita wmuestras posteriores a la que esta procesando, este
campo limita la ultima muestra que puede procesar, dejando todas aquellas muestras
posteriores sin procesar para que sean procesadas en siguiente etapa, cuando se
hayan leıdo mas.
total samples Numero total de muestras que se han leıdo desde el comienzo del algorit-
mo. Se utiliza para llevar una cuenta de las muestras leıdas y ası poder informar al
usuario.
samples processed Numero de muestras que ya han sido procesadas. Se utiliza para cal-
cular el valor promedio de los ındices, pues este depende del numero total de mues-
tras procesadas.
channels Numero de canales de los datos. Necesario para comprobar si el numero de ca-
nales cambia a lo largo del algoritmo y para poder reservar el buffer interno, ya que
como no es posible indicarle al lenguaje C que queremos reservar espacio para Xmuestras, debemos reservar espacio para X*num canales*sizeof(<tamanode una dato>).
size Numero de datos actualmente almacenados en el buffer. Se utiliza tanto para deter-
minar si es posible procesar un fragmento del tamano requerido por el usuario como
para saber si una lectura adicional desbordarıa el buffer.
max size Tamano maximo del buffer. Es el tamano del buffer en el que se almacenan los
datos y limita el numero maximo de datos que podemos almacenar.
Ya que para la fase de inicializacion es necesario reservar un bloque con un tamano
que varıa en funcion del numero de canales, es necesario conocer de antemano el numero
de estos, leyendo el primer fragmento antes de la fase de inicializacion.
6.2. Procesamiento
Esta fase, que podrıamos considerar el nucleo del algoritmo, se puede a su vez dividir
en otras cuatro fases, que se explicaran a continuacion y que anaden flexibilidad al algo-
ritmo, pues al separar la lectura y el almacenamiento del calculo de los ındices se pueden
utilizar diferentes enfoques a la hora de recibir los datos.
Aunque para esta primera version se ha optado por un enfoque basado en una ventana
deslizante donde se almacenan los datos, en la seccion 10.1 se mencionan otras posibles
alternativas.
26
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
6.2.1. Lectura
Como primer paso en la fase de procesamiento es necesario leer un fragmento de un
tamano al menos lo bastante grande como para poder procesar un fragmento del tamano
que indique el usuario mediante el parametro trigger.
Esta lectura del tamano que necesita el algoritmo se puede realizar en varias iteracio-
nes, siendo el propio algoritmo el que comprueba si ya dispone de bastantes datos o si
es necesario realizar otra iteracion para leer mas antes de empezar a procesar un nuevo
fragmento.
6.2.2. Almacenamiento
Tras realizar la lectura es necesario mover los datos leıdos del buffer temporal sobre
el que se han ido leyendo al buffer interno del algoritmo, ya que hasta este momento el
algoritmo no sabe que se han leıdo nuevos datos.
Para realizar esta operacion se copia la totalidad del bloque memoria en el que estan
almacenados los datos que se han leıdo en la ultima etapa justo a continuacion del ultimo
dato dato que estaba almacenado.
Recordamos que es posible hacer esta copia directamente ya que los datos se alma-
cenan de igual manera que se leen, por lo que, antes de poder procesarlos sera necesario
transponerlos y transformarlos al formato que necesita algoritmo para procesarlos correc-
tamente.
6.2.3. Procesamiento
En esta fase del algoritmo, a la que solo se puede acceder tras comprobar que se dispo-
ne de suficiente informacion para procesar al menos un fragmento de tamano trigger,
se procesan tantos fragmentos como sea posible con los datos que haya almacenados en
ese momento.
El primer paso consiste en convertir el bloque de memoria compacto que contiene los
datos a procesar en una M2D, que posteriormente se transpone, dejando los datos en la
configuracion idonea para el algoritmo.
Con los datos ya completamente preparados se establecen una serie de lımites para,
en las muestras alejadas de los extremos, no procesar aquella que no tengas al menos wmuestras posteriores, lo que desvirtuarıa tanto los resultados parciales de esa etapa como
el valor promedio de los ındices que se calcula al final.
Una vez se han definido los lımites, el algoritmo entra en un bucle para procesar estos
fragmentos de tamano trigger. Cada iteracion del bucle procesa trigger muestras
mediante una llamada a la funcion HSLMN delta, nucleo del algoritmo HSLMN origi-
nal que permite procesar un bloque datos de cualquier tamano.
27
CAPITULO 6. ESTRUCTURA HSLMN RT
Cuando el algoritmo retoma el control despues de la llamada a HSLMN delta se
anade el resultado a las matrices donde se va almacenando el resultado final y se calcula
el resultado parcial, para poder mostrarlo posteriormente.
Con el calculo de este resultado parcial se llega al final del bucle, que se repite tantas
veces como fragmentos de tamano trigger para procesar disponga el algoritmo.
6.2.4. Reempaquetado de los datos
Tras haber procesado todos los datos o no tener necesario para procesar otro fragmento
completo, el algoritmo procede a reempaquetar los datos en el buffer para poder volver a
pasar por las fases de lectura y almacenamiento.
Este reempaquetado de los datos se realiza deslizando la ventana de los datos que se
pueden procesar al principio del buffer, moviendo tanto los muestras que hayan queda-
do sin procesar como las ultimos w muestras, necesarias para realizar correctamente el
calculo de las proximas muestras.
Al realizar el reempaquetado es necesario modificar rt state.first sample y
rt state.last sample para reflejar cuales de los datos del buffer se pueden proce-
sar y cuales no.
6.3. Finalizacion
Una vez se han leıdo todos los datos del experimento que se esta estudiando, el al-
goritmo realiza dos funciones mas, el calculo final del valor promedio de los ındices,
con su correspondiente volcado donde corresponda y la liberacion de todos los recursos
asociados.
Para el calculo final de los ındices el algoritmo vuelve a ejecutar una fase de procesa-
miento en la que se terminan de procesar todos los datos que queden en el buffer, pues ya
sabemos que no vamos a recibir mas datos.
La parte de liberar los recursos asociados al algoritmo consiste en realizar las lla-
madas a la funcion free sobre los recursos que se hayan reservado y marcarlos como
no-inicializados.
6.4. Diferencias MatLab y lınea de mandatos
Aunque la base del algoritmo es la misma en ambos casos, existen algunas diferencias
entre ambos algoritmos. Estas diferencias, aunque no varıan el resultado que produce el
algoritmo, si que varıan ligeramente como se usa, ya que la version de lınea de mandatos
es auto-contenida que lee y procesa los datos mientras que la version MatLab se limita a
procesar los datos, recibiendolos como argumento.
28
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
6.4.1. Lectura de datos
Mientras que en la interfaz de lınea de mandatos el algoritmo recibe un descriptor de
fichero, la interfaz MatLab esta disenada para ser llamada repetidas veces recibiendo un
fragmento de datos. En el primer caso es el propio algoritmo el que lee todos hasta que
se queda sin, mientras que en el segundo caso es el usuario que llama al algoritmo el que
indica cuando se han acabado de leer los datos.
6.4.2. Recogida de resultados
La version de lınea de mandatos simplemente vuelca los resultados a un fichero, solu-
cion que no es valida para la version MatLab, pues los resultados han de recogerse desde
el entorno de MatLab, no sobre un fichero.
Es esta necesidad la que fuerza al algoritmo a no bloquear el entorno en el intervalo
de tiempo desde que se invoca el algoritmo hasta que este devuelve los resultados finales,
sino que tras cada una de las etapas en las que se procesan o se intentan procesar los
datos almacenados el algoritmo devuelve tanto el control como los resultados parciales al
entorno MatLab.
Aquı el usuario ha de tener en cuenta que el algoritmo solo es capaz de devolver
el resultado parcial del ultimo fragmento procesado, por lo que si alimenta el algoritmo
con bloques de datos mas grandes o mas pequenos que el tamano del fragmento que
desea procesar, se encontrara con que le falta informacion de fragmentos que han sido
procesados o que el algoritmo devuelve varias veces la informacion del mismo fragmento,
ya que no dispone de bastantes muestras para procesar uno nuevo
6.4.3. Deteccion del final de lectura
El algoritmo con interfaz para lınea de mandatos es capaz de detectar cuando no tiene
mas datos para leer en el descriptor que se le ha indicado, por lo que en ese momento
puede pasar a ejecutar la fase de finalizacion.
No ocurre lo mismo en el caso de MatLab, pues al realizarse la lectura fuera del
algoritmo este no es capaz de determinar cuando dejaran de llegar datos, por lo que la
responsabilidad de indicarle al algoritmo cuando debe calcular el resultado final recae
sobre el usuario, que debe indicarselo al algoritmo mediante la invocacion de una funcion.
6.5. Pseudocodigo
29
CAPITULO 6. ESTRUCTURA HSLMN RT
Algoritmo 1 Fase de inicializacion
if algoritmo no inicializado thenrt state.first sample = 0;rt state.last sample = 0;rt state.total samples = 0;rt state.channels = num canales;rt state.size = 0;rt state.max size = 3 ∗ (2 ∗ w) ∗ rt state.channels;rt state.data = reservar espacio(rt state.max size);reservar espacio para los indices();
end if
Algoritmo 2 Fase de procesamiento
while quedan datos por leer domuestras leidas = leer un fragmento();copiar datos leidos al buffer();rt state.last sample += num canales ∗muestras leidas;rt state.total samples += muestras leidas;rt state.channels += num canales;rt state.size = 0;if hay bastantes datos para procesar thendatos M2D = transformar en M2D(rt state.data);datos = transponer M2D(datos M2D);Il = ultimo fragmento procesable();for i = rt state.first stample to Il doIb = i;Ie = min(i+ trigger, Il);fragment size = Ie− Ib;if fragment size != trigger thenbreak;
end ifcnt = HSLMN delta();samples processed += cnt;acumular valor indices finales();calculo valor indices parciales();
end forrecompactar datos();
end ifend while
Algoritmo 3 Fase de finalizacion
if algoritmo inicializado thenprocesar datos restantes();liberar espacio(rt state.data);liberar espacio para los indices();
end if
30
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Capıtulo 7
Visualizacion de los resultados
Con el algoritmo ya terminado el siguiente paso es crear una interfaz que permita vi-
sualizar los resultados parciales que devuelve el algoritmo. Como existe una version para
MatLab del algoritmo se ha optado por implementar la interfaz dentro de este entorno.
Para visualizar los resultados se utiliza una grafica que se actualiza con los valores
parciales que devuelve el algoritmo. Gracias a la potencia del entorno de MatLab existen
varias maneras de hacer esta actualizacion, que se exploraran en la siguiente seccion.
7.1. Opciones de visualizacion
7.1.1. Redibujar la grafica en cada iteracion
La primera opcion considerada consiste en borrar la grafica antigua redibujando la
nueva grafica encima mediante la funcion plot cada vez que el algoritmo produce nuevos
resultados.
% Crear graficax = 0:0.1:2*pi;y = sin(x);plot(x,y);% Actualizar datosy = sin(x.ˆ3);% Redibujar graficaplot(x,y);
Esta opcion aunque es la mas sencilla tambien la menos eficiente, ya que MatLab debe
destruir y volver a reconstruir todos los objeto asociados a la grafica (ejes, lıneas, textos,
divisiones...) cada vez que hay una modificacion en los datos. Como ventaja tambien cabe
destacar que esta es la opcion mas clara de cara al usuario, ya que cada vez que hay que
actualizar la grafica simplemente se dibuja una nueva.
31
CAPITULO 7. VISUALIZACION DE LOS RESULTADOS
7.1.2. Refreshdata
La siguiente opcion considerada es utilizar la funcion refreshdata que proporciona
MatLab. Esta funcion actualiza todas las graficas que conocen cual es el origen de sus
datos en el momento en el que se llama a la funcion.
1 % Crear grafica2 x = 0:0.1:2*pi;3 y = sin(x);4 h = plot(x,y);5 % Indicar el origen de los datos6 set(h,’YDataSource’,’y’)7 set(h,’XDataSource’,’x’)8 % Actualizar grafica9 y = sin(x.ˆ3);
10 refreshdata;
Sin embargo, debido al funcionamiento interno de la funcion, refreshdata explora
todos las graficas que existen en el programa aunque actualizar solo aquellas cuyo origen
de datos conoce. Aunque es posible indicarle que grafica se quiere actualizar su eficiencia
es menor que la de otras opciones.
A estos costes hay que anadir la existencia de un error en algunas versiones de MatLab
que impide que la funcion refreshdata actualice las graficas con mas de una funcion en
ellas, como es nuestro caso al querer mostrar simultaneamente los resultados de los 6
ındices (H, S, L, M, N y SL)
7.1.3. Modificar graficas
La ultima opcion consiste en modificar de manera manual la informacion de los datos
que se pintan en la grafica e indicarle a MatLab mediante la funcion drawnow que tiene
que redibujarla.
1 % Crear grafica2 x = 0:0.1:2*pi;3 y = sin(x);4 h = plot(x,y);5 % Actualizar datos6 y = sin(x.ˆ3);7 set(h,’YData’,y);8 % Actualizar grafica9 drawnow;
Esta ultima opcion es la mas rapida de las 3, pues solo se solo cambiamos la informa-
cion de la grafica que se ha modificado. Tampoco es difıcil de entender, pues se realiza
con una llamada a la funcion set, equivalente a realizar una asignacion.
32
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
7.2. Comparacion de tiempo
Para comprobar la eficiencia de las distintas opciones se ha medido el tiempo necesa-
rio para actualizar una misma grafica 10000 veces con las tres opciones mediante el uso
del siguiente programa:
1 x = 0:.1:2;2 y = sin(x);3 h = plot(x,y);4 set(h,’YDataSource’,’y’)5 set(h,’XDataSource’,’x’)6
7 % Redibujar grafica8 tic9 for i=1:10000
10 y = sin(x.ˆ3);11 delete(h);12 h = plot(x,y);13 end14 toc15
16 % Refreshdata17 tic18 for i=1:1000019 y = sin(x.ˆ3);20 refreshdata(h);21 end22 toc23
24 % Actualizar datos25 tic26 for i=1:1000027 y = sin(x.ˆ3);28 set(h,’YData’,y);29 drawnow;30 end31 toc
Como se puede comprobar en la figura 7.1, la ultima alternativa es 5 veces mas rapida
que dejarle a MatLab la actualizacion de los datos y en torno a 8 veces mas rapida que
borrar y redibujar la nueva grafica en el lugar de la anterior.
33
CAPITULO 7. VISUALIZACION DE LOS RESULTADOS
Figura 7.1: Comparacion entre los distintos metodos para actualizar una grafica
7.3. Opcion escogida y detalles de la implementacion
Tras este pequeno estudio de las distintas opciones se opto por implementar la interfaz
actualizando manualmente los datos de cada uno de los ındices manualmente para despues
llamar una unica vez a la funcion drawnow.
Antes de comenzar a procesar los datos es necesario inicializar las graficas que mues-
tran los ındices, almacenando sus handlers, indicar que canales se desean visualizar (cada
ındice devuelve el resultado de comparar los canales por parejas) y finalmente inicializar
los textos que acompanan a la grafica mostrando el valor numerico de los ındices.
Como se explico anteriormente, la version MatLab recibe los datos del propio progra-
ma y devuelve el control a MatLab una vez procesado el fragmento del tamano indicado.
Es al retomar el control tras procesar un fragmento de datos cuando se anaden al final
de los ındices el nuevo valor calculado, se actualizan las los ejes, para mostrar unicamente
el fragmento de los datos deseado (pues de otra manera tras unos segundos no serıa posible
distinguir claramente su valor) y se ordena a MatLab que redibuje la grafica.
34
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Capıtulo 8
Resultados obtenidos
Uno de los principales objetivos de este proyecto ha sido siempre mantener la eficien-
cia que caracterizaba a los algoritmos HSLMN y FSL, bases del original, sin olvidar que
el objetivo principal es poder visualizar la evolucion de las distintas senales del experi-
mento a lo largo del mismo.
8.1. Visualizacion de resultados
Con los algoritmos originales es posible realizar una visualizacion a posteriori de los
resultados parciales. Esta visualizacion es muy costosa, pues es necesario procesar el fi-
chero original del experimento, indicando que se desean volcar los resultados parciales.
Una vez hecho esto es necesario procesar este nuevo fichero para transformar los resulta-
dos a un formato facil de visualizar que permita finalmente mostrarlo.
El nuevo algoritmo es mas rapido ya que muestra los resultado parciales a medida que
se van calculando, eliminando la necesidad de tener que procesar un segundo fichero, con
el coste que esto supone.
La figura 8.1, extraıda directamente del entorno MatLab, muestra el resultado del pro-
cesamiento y la visualizacion del experimento “da”, mientras que en la figura 8.1, obteni-
da de la misma manera que la anterior, se muestran los primeros instantes del experimento
“pt”. Con este nuevo algoritmo es posible ver la evolucion del valor del ındice en tiempo
real, pudiendo compararlo con el valor en instantes de tiempo anteriores.
35
CAPITULO 8. RESULTADOS OBTENIDOS
Figura 8.1: Resultados experimento “da”
Figura 8.2: Resultados experimento “pt”
36
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Con los resultados de las dos figuras anteriores es complicado asegurar que el algo-
ritmo funciona correctamente, por lo que se han utilizado los datos de otro experimento
sintetico, al que hemos llamado “sin-cos”, con un comportamiento predecible.
Este experimento esta compuesto por 2 canales con 4000 muestras en cada canal,
obtenidos de los datos de un seno y de un coseno. El valor de sincronizacion sera maximo
en los puntos que el seno y el coseno coinciden, por lo que para un experimento de 1 solo
perıodo se espera encontrar dos picos que indiquen esto.
Figura 8.3: Datos del experimento sin-cos
37
CAPITULO 8. RESULTADOS OBTENIDOS
La figura 8.4 nos da una confirmacion visual de que el algoritmo detecta los picos de
sincronizacion, primer paso para asegurar que el algoritmo funciona correctamente.
Al repetir el experimento alimentando al algoritmo una y otra vez con los mismos
datos observamos como estos picos que muestran la sincronizacion se repiten una y otra
vez sin cesar, prueba con la que podemos confirmar que el algoritmo es capaz de mantener
el bucle de lectura-procesamiento sin devolver datos erroneos, tal y como muestra la figura
8.5
Figura 8.4: Resultado experimento “sin-cos”(1 perıodo)
Figura 8.5: Resultado experimento “sin-cos”(varios perıodos)
38
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
8.2. Rendimiento
Los dos factores importantes a tener en cuenta de cara al procesamiento de las senales
son el tiempo necesario para procesar una senal y la cantidad de memoria necesaria para
hacerlo que en el caso de dispararse limitarıan la viabilidad del algoritmo.
8.2.1. Tiempo de ejecucion
Al realizar la comparacion entre el algoritmo unificado, con prestaciones similares a
los originales, y el algoritmo de tiempo real se ha observado que el coste de pintar en cada
etapa los es apenas apreciable.
Para esta comparacion se ha procesado el experimento “paciente test”, el experimento
mas largo de los que disponemos, con la version MatLab el algoritmo HSLMN unificado
y con el algoritmo HSLMN RT, indicando la opcion de volcar resultados parciales cada
100 muestras a ambos.
El algoritmo HSLMN RT es mas lento que el algoritmo original, pues tiene que en-
cargarse no solo de calcular el valor de los ındices sino que tambien tiene que mostrar
los datos. La principal diferencia que permite que el algoritmo HSLMN RT compita en
tiempo contra el algoritmo original la encontramos en la parte del mismo.
Las figuras 8.6 y 8.7 muestran una comparativa tanto del tiempo necesario para pro-
cesar el experimento como como del numero de muestras que es capaz de procesar el
algoritmo. Ambas graficas muestran que el algoritmo HSLMN RT es un 2 % mas lento
que el algoritmo original, un dato bastante impresionante teniendo en cuenta las dimen-
siones del experimento
Podemos atribuir que la diferencia sea tan pequena a que el original realiza el vol-
cado de los datos sobre el disco en cada etapa (una operacion muy lenta) mientras que
el algoritmo HSLMN RT devuelve los datos MatLab como variables, evitando todas las
operaciones de entrada/salida.
39
CAPITULO 8. RESULTADOS OBTENIDOS
Figura 8.6: Tiempo promedio necesario para procesar el experimento “pt”
Figura 8.7: Capacidad de procesamiento de los algoritmos frente al experimento “pt”
40
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
8.2.2. Uso de memoria
El otro factor a considerar a la hora de evaluar el rendimiento de la funcion es la canti-
dad de memoria que necesita para procesar un experimento. El algoritmo original necesita
almacenar en memoria el 100 % de los datos que va a procesar, por lo que a medida que
aumenta el numero de datos a procesar, las necesidades de este son mayores. El nuevo
algoritmo HSLMN RT utiliza un buffer de un tamano finito, que reutiliza completamen-
te, por lo que la cantidad maxima de memoria que necesita el algoritmo depende de los
parametros del algoritmo, no del numero de muestras que se procesen.
En la figura 8.8 encontramos el resultado de aplicar ambos algoritmos a una serie de
experimentos creados a concatenando varias veces seguidas los datos del experimento
“sin-cos”. En ella se muestra el maximo de memoria que ha necesitado el algoritmo para
procesar los distintos experimentos. Esta cantidad varıa mucho en el caso del algoritmo
HSLMN unificado pero se mantiene constante en el caso del algoritmo HSLMN RT.
Figura 8.8: Uso maximo de memoria durante el procesamiento de distintos experimentos
41
CAPITULO 8. RESULTADOS OBTENIDOS
42
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Capıtulo 9
Conclusiones
A lo largo de este proyecto se han transformado dos algoritmos, cuyo funcionamiento
era bastante similar, en un unico algoritmo bien optimizado con un objetivo muy concreto.
Examinando punto a punto los distintos pasos que debıan darse para llegar al objetivo final
es posible identificar cuales son los componentes claves del mismo, aquellos en los que
dependen tanto su efectividad como su eficiencia.
Aunque el algoritmo queda lejos de ser perfecto, pues existen varios aspectos mejora-
bles que se tratan en el capıtulo 10, si que es un algoritmo robusto que permite procesar
un conjunto de gran tamano en un tiempo razonable. La robustez del algoritmo es uno
de sus puntos claves, ya que lucha contra el principal problema del analisis de datos en
tiempo real, la incertidumbre frente a la naturaleza de la entrada.
Es esta incertidumbre la que ha marcado el desarrollo de casi todo el proyecto, pues
es la que ha determinado que el algoritmo debe poder leer cualquier cantidad de datos,
que ha de ser reentrante para no bloquear el entorno desde el que se utiliza y la necesidad
de desacoplar lectura, almacenamiento y procesamiento de los datos.
En la parte de unificacion de los algoritmos se ha visto como un mal diseno a la hora de
desarrollar un algoritmo puede aumentar dramaticamente el tamano del codigo del mismo
y dificultar enormemente tanto la legibilidad como la facilidad de realizar modificaciones
sobre el.
Tambien quiero hacer hacer notar la importancia de tener una buena planificacion que
detalle claramente los pasos que se han de seguir desde el principio hasta el final de un
proyecto. En un proyecto mal planificado es muy complicado saber que tareas hay que
llevar a cabo y que tareas estan ya terminadas, pudiendo llegar incluso a situaciones en
las que, debido a esto, se realiza el trabajo por duplicado.
Para concluir, me gustarıa realizar una valoracion de lo que a mi me ha supuesto este
proyecto. Gracias a el he podido trabajar siguiendo una buena planificacion en un entorno
en el que he sido capaz de integrarme muy facilmente. Tambien me ha permitido profun-
dizar en el uso de herramientas y tecnologıas de profiling y depuracion, imprescindibles
para realizar trabajos serios. Puedo afirmar que estoy orgulloso de haber realizado este
trabajo y de pensar que puede llegar a ayudar a muchas personas en el dıa de manana.
43
CAPITULO 9. CONCLUSIONES
44
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Capıtulo 10
Trabajos futuros
A lo largo del trabajo se han explorado varias alternativas en diferentes aspectos del
diseno y desarrollo tanto del algoritmo HSLMN RT como de la interfaz de visualizacion
de los resultados.
En esta seccion se van a exponer algunos posibles aspectos que aunque quedan fuera
del ambito del proyecto, podrıan revisarse en otros futuros proyectos tanto como para
mejorar el algoritmo como para encontrar nuevos usos para el.
10.1. Alternativas en la lectura y el almacenamiento delos datos
Actualmente el algoritmo procesa los datos almacenados en un buffer que actua como
ventana deslizante sobre los datos del experimento que esta procesando. Esta solucion,
aunque perfectamente valida, no permite realizar de manera simultanea las fases de lectura
y procesamiento de los datos, ya que solo se dispone de un unico buffer del que puede
leer el algoritmo.
El diseno actual del algoritmo facilita la modificacion de la fase de lectura y almace-
namiento de los datos para que los almacene dentro de una estructura mas compleja, como
podrıa ser un doble o triple buffer o hasta un buffer circular, que permita el algoritmo siga
recibiendo datos mientras procesa los mismos.
Otro aspecto a estudiar es la modificacion del algoritmo o de la manera en la que se
almacenan los datos para ver si es posible evitar las transformaciones y transposiciones
que hay que realizar sobre los datos antes de poder procesarlos correctamente.
45
CAPITULO 10. TRABAJOS FUTUROS
10.2. Recogida de resultados en MatLab
Como ya se ha comentado anteriormente, la interfaz MatLab puede devolver varias
veces el mismo resultado parcial u omitir el resultado de alguna iteracion, dependiendo
de los parametros con los que ha sido configurado.
Para evitar que sea necesario una configuracion muy minuciosa a la hora de llamar al
algoritmo para poder visualizar comodamente los resultados, se podrıa incluir un modulo
que almacene todos los resultados parciales que se han calculado y no han sido devueltos
a MatLab, devolviendolos como una matriz n-dimensional.
10.3. Integracion con HERMES
No hay que olvidar que los algoritmos HSLMN y SL, padres del algoritmo HSLMN RT,
estan disponibles para ser utilizados dentro de la herramienta HERMES. Aunque el nue-
vo algoritmo dispone de una interfaz para ser utilizado desde MatLab, la integracion total
con la herramienta HERMES podrıa facilitar aun mas la labor de aquellos investigadores
interesados.
10.4. Paralelizacion usando CUDA
Como se especifico al principio del documento, el algoritmo HSLMN RT tiene como
base la version paralela utilizando OpenMP del algoritmo HSLMN unificado, capaz de
calcular tanto los ındices HSLMN como el ındice SL. Junto a esta version existe otra
version paralela utilizando OpenMP y CUDA que puede dar incluso mejores resultados.
Paralelizar el algoritmo sobre GPU no es una labor complicada, ya que realmente es
el nucleo de computo HSLMN delta el que unico que lanza varios hilos para realizar
los calculos necesarios, la parte interesante de este punto reside en un estudio de las
prestaciones de esta version pues es posible que al no procesar todos los datos de golpe la
version GPU del algoritmo HSLMN rt sea incluso mas lenta debido al coste de transferir
informacion entre la CPU y la GPU.
10.5. Usos alternativos
Aunque el algoritmo se crea con el objetivo de poder facilitar las labores de estudio
del cerebro a los investigadores su uso no tiene por que quedar limitado a ese ambito.
Cabe estudiar como se pueden utilizar estos ındices de sincronizacion para observar la
correlacion entre senales con otros orıgenes completamente distintos, como podrıan ser
varios canales de audio o los datos de la bolsa de valores de un paıs.
46
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Acronimos
API Interfaz de Programacion de Aplicaciones
CTB Centro de Tecnologıa Biomedica
CUDA Compute Unified Device Architecture
DATSI Departamento de Arquitectura y Tecnologıa de Sistemas Informaticos
FSL Fast Synchronization Likelihood
HERMES HERramientas de MEdida de la Sincronizacion
HSLMN Indices H, S, L, M y N
SL Synchronization Likelihood
MEX MatLab Executable
EEG Electroencefalogramas
MEG Magnetoencefalogramas
VLA Array de tamano variable (Variable Length Array)
M2D Matriz 2D
HSLMN RT HSLMN Real Time
47
CAPITULO 10. TRABAJOS FUTUROS
48
Adaptacion a tiempo real de los ındices de sincronizacion HSLMN y SL
Bibliografıa
[1] C. Stam and B. van Dijk, “Synchronization likelihood: an unbiased measure of gene-
ralized synchronization in multivariate data sets,” Physica D: Nonlinear Phenomena,
vol. 163, no. 3–4, pp. 236 – 251, 2002.
[2] D. Chicharro and R. G. Andrzejak, “Reliable detection of directional couplings using
rank statistics,” Phys. Rev. E, vol. 80, p. 026217, Aug 2009.
[3] G. Niso et al., “Hermes: Towards an integrated toolbox to characterize functional and
effective brain connectivity,” Neuroinformatics, vol. 11, no. 4, pp. 405–434, 2013.
[4] F. Rosales et al., “An efficient implementation of the synchronization likelihood al-
gorithm for functional connectivity,” Neuroinformatics, vol. 13, no. 2, pp. 245–258,
2015.
[5] I. M. Cuquerella, “Optimizacion y paralelizacion de un algoritmo de sincronizacion
mediante el uso de GPUs y la tecnologıa CUDA,” Thesis, Universidad Politecnica de
Madrid, Jan 2013.
[6] S. S. Fernandez, “Optimizacion de ındices de sincronizacion generalizada para el
analisis de datos MEG,” Thesis, Universidad Politecnica de Madrid, Jan 2014.
[7] OpenMP Site. [Online] Available: http://openmp.org/wp/.
[8] CUDA Site. [Online] Available: https://developer.nvidia.com/cuda-zone.
[9] Thrust Site. [Online] Available: http://thrust.github.io/.
49
Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,
C=ES
Fecha/Hora Mon Jun 06 20:11:28 CEST 2016
Emisor delCertificado
[email protected], CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES
Numero de Serie 630
Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)