capítulo 2: métodos y materialesbibing.us.es/proyectos/abreproy/11981/fichero/memoria+pfc... ·...
TRANSCRIPT
Métodos y materiales
17
Capítulo 2: Métodos y materiales
Los sistemas embebidos son sistemas de altas prestaciones diseñados para ejecutar un
conjunto de aplicaciones concretas y que, sobretodo, van a estar integrados en sistemas
portables.
Generalmente están controlados por un DSP que no es más que un procesador digital
diseñado específicamente para aplicaciones de procesamiento de señales, de modo que
son capaces de manejar datos de forma más eficiente que un procesador de propósito
general. Así, permiten realizar un procesado digital en tiempo real similar al de un
ordenador corriente con la ventaja de poder ser integrado en sistemas portables, pero
también con las limitaciones que ello conlleva.
Los sistemas embebidos se caracterizan por unas condiciones de diseño muy estrictas,
que se refieren principalmente a tiempos de ejecución que permitan respuestas en
tiempo real, consumos de potencia suficientemente bajos como para proporcionar cierta
autonomía al dispositivo portable y coste razonable, de modo que el sistema represente
una solución viable al igual que interesante para los usuarios.
Estas características de portabilidad y de respuesta en tiempo real, hacen de los sistemas
embebidos una tecnología muy interesante desde el punto de vista de las aplicaciones
biomédicas, que en muchas ocasiones requieren de ambas propiedades.
2.1. Funcional
La implementación de un algoritmo de procesado digital de señales desde su diseño
hasta su ejecución en un sistema embebido no es un proceso trivial, por lo que resulta
conveniente tener a priori una visión general de los pasos a seguir.
Por ello, se va a seguir un procedimiento general e independiente de tecnología para
desarrollar este tipo de algoritmos para sistemas embebidos, desde su ideación hasta su
implantación en el dispositivo final. Como dispositivo final podemos entender cualquier
tipo de dispositivo integrado capaz de almacenar y/o ejecutar una determinada
Métodos y materiales
18
aplicación dentro de un sistema embebido en tiempo real. Las características más
importantes de este procedimiento son, que por una parte se trata de un procedimiento
general no sujeto implícitamente a ningún tipo de plataforma ni tecnología concreta y,
por otra, que este procedimiento es extensible a cualquier tipo de señal y de
procesamiento que se desee realizar dentro de un sistema embebido.
Un algoritmo de procesamiento de señal, en general, es diseñado inicialmente haciendo
uso de una herramienta matemática cuyo entorno de desarrollo integrado (IDE) permite
tanto la programación en un lenguaje de alto nivel de computación matemática, como la
simulación del algoritmo en términos de verificación y test en un PC, permitiendo de
este modo una depuración dinámica del código y acelerando así su implementación.
Una vez implementado el algoritmo de procesamiento, el siguiente paso consistiría en
compilar el código fuente para generar el archivo binario ejecutable, de forma que el
código de la aplicación pueda ser ejecutado en el dispositivo final, que en el caso de
sistemas embebidos se trata generalmente de un DSP.
La unidad central de procesamiento (CPU) del DSP ejecuta directamente código objeto,
el cual contiene instrucciones en lenguaje máquina, por lo que es indispensable generar
dicho código a partir de la compilación del código fuente de la aplicación. Para esta
tarea existen multitud de programas y entornos de desarrollo integrados de aplicaciones
embebidas, normalmente proporcionados por los mismos fabricantes de dispositivos
integrados, que permiten crear el archivo objeto ejecutable correspondiente a partir del
código programado y facilitan además el acceso al hardware, posibilitando incluso
grabar la aplicación en la memoria RAM del DSP. De este modo y como puede
deducirse, el dispositivo seleccionado para el sistema embebido determinará en gran
medida el entorno de desarrollo integrado concreto con el que se trabaja para llevar a
cabo esta tarea.
Sin embargo, por lo general en la elaboración de aplicaciones embebidas, el código
resultante del diseño de la aplicación en el lenguaje de programación propio del
software de desarrollo matemático, no resulta de utilidad. Esto se debe a que el lenguaje
de programación en el que se ha diseñado el algoritmo puede no ser compatible con los
lenguajes de programación aceptados por los compiladores del entorno de desarrollo
integrado con el que generar el archivo ejecutable. El código a partir del cual es posible
generar el código máquina ejecutable por el procesador se trata normalmente de un
Métodos y materiales
19
lenguaje de medio o alto nivel al que vamos a denominar código intermedio, ya que
actúa como puente entre el código en lenguaje de programación en el que se ha
diseñado el algoritmo y el código en lenguaje máquina del procesador en el que se va a
ejecutar. Evidentemente se requiere de una conversión del código desarrollado
originalmente al lenguaje de programación intermedio.
La figura de un lenguaje de programación intermedio, tiene su justificación en la gran
cantidad de herramientas de procesamiento matemático que existen, dado que no sería
factible tener un software específico para generar código máquina a partir de cada una
de ellas. Por ello resulta conveniente tener un punto de confluencia de todas ellas en un
lenguaje que sea empleado por las herramientas de generación de código máquina
ejecutable.
Una vez obtenido el código intermedio de la aplicación, podemos optimizarlo
convenientemente. De esta forma conseguimos un código optimizado e independiente
de plataforma, de modo que puede ser integrado en cualquier sistema embebido.
A partir de él, ya es posible generar el archivo binario ejecutable por medio del entorno
de desarrollo de aplicaciones embebidas. El archivo binario resultante de la compilación
es un archivo entendible por el procesador del DSP y contiene una imagen binaria
directamente ejecutable del programa. Generalmente incluye, no sólo información del
programa en sí, sino además otro tipo de información complementaria que ayuda al
sistema operativo a la ejecución de la aplicación. Por ello, el archivo ejecutable es
específico de la plataforma concreta que lo genera. Si se desea, y una vez obtenido el
archivo ejecutable, es posible generar el archivo binario plano que puede ser grabado en
cualquier tipo de memoria de almacenamiento del sistema, ya sea la memoria RAM
externa tanto síncrona dinámica (SDRAM) como asíncrona (flash). En la Figura 1 se
puede observar el diagrama funcional completo que se ha seguido.
Figura 1: Diagrama funcional del procedimiento de implementación de aplicaciones embebidas.
Métodos y materiales
20
2.2. Procesado digital de señales biológicas
2.2.1. Procesado digital de señales biológicas en sistemas
embebidos
Las señales biológicas pueden ser de varios tipos. Las hay químicas, de tipo calorífico,
eléctricas y mecánicas. Esta variedad da lugar a diferentes técnicas de adquisición de las
señales, es decir, a diferentes tipos de transductores que son necesarios para poder
capturar la señal y transformarla en una señal eléctrica analógica que sirve de entrada al
DSP, donde se realiza una conversión analógico-digital para obtener así la señal digital
que puede ser procesada por la CPU del DSP. El procesamiento, eso sí, será diferente
según la aplicación concreta que se desee. Del mismo modo, cualquier tipo de señal
biomédica necesita de un filtrado analógico en su adquisición y a menudo de
amplificación. La mayoría de aplicaciones requieren además un filtrado digital previo al
procesado para la reducción de ruido, al tratarse de señales débiles con un importante
nivel de ruido e interferencias [18]. En la Figura 2 se muestra un modelo simplificado
de un sistema de procesado de señales biológicas.
Figura 2: Sistema básico sensor-DSP.
Las prestaciones de los dispositivos sensores y DSPs actuales facilitan el procesado
distribuido en sistemas embebidos. Este tipo de procesamiento proporciona robustez y
flexibilidad al sistema [20]. Por una parte, reduce la probabilidad de un fallo general y
por otra permite diseñar y desarrollar de forma modular las distintas unidades
funcionales que componen el sistema. De este modo, posibilita una implementación
gradual, dando lugar a la integración de nuevas aplicaciones a lo largo del tiempo. Así,
es posible poner en marcha unos módulos concretos con el objetivo de obtener una
funcionalidad mínima para agregar nuevas aplicaciones posteriormente.
DSP
A/D procesador
sensor
señal biológica
señal eléctrica
señal digital
Métodos y materiales
21
Un ejemplo de aplicación muy común de sistemas de arquitectura distribuida es una red
de sensores para la captura y procesamiento de datos [21]. El uso de múltiples sensores
inteligentes de diferentes tipos para el procesamiento de un conjunto de señales
biológicas heterogéneas posibilita la generación de un conocimiento que permite
desarrollar sistemas de monitorización personalizada.
2.2.2. Filtrado previo de la señal
Las señales biomédicas suelen ser ruidosas por lo que el filtrado es una parte importante
del procesado de la señal para mejorar la relación señal a ruido. Por otra parte, en
ocasiones es necesario separar diferentes componentes de una señal para realizar
procesamientos distintos con cada una, en cuyo caso el filtrado también es una parte
importante dentro del procesamiento de la señal.
Podemos diferenciar dos tipos de filtros, los de respuesta finita (FIR) y lo de respuesta
infinita (IIR). Los filtros FIR presentan fase lineal y son siempre estables aunque son
poco eficientes computacionalmente tanto en ocupación en memoria como en tiempo de
ejecución. Por otro lado los filtros IIR son filtros lineales que consiguen cumplir
fácilmente con las condiciones de diseño en cuanto a frecuencias corte y bandas de
transición con un orden bajo. Sin embargo no tienen fase lineal, lo cual puede ser un
inconveniente según la aplicación de la que se trate. Son IIR los filtros Butterworth,
Tchebyscheb o elípticos. De ellos, son los elípticos los que consiguen una transición
más estrecha para un mismo orden en comparación con los otros dos, si bien presentan
rizado tanto en la banda de paso como en la de rechazo.
En algunas ocasiones no es posible eliminar ciertas componentes del ruido por medio de
filtros lineales sin eliminar parte de la señal de interés. En estas circunstancias y cuando
lo que se desea principalmente es eliminar picos de ruidos, es posible emplear filtros
medianos [25]. Los filtros medianos son filtros no lineales que permiten ponderar
ciertos valores de la secuencia de datos en función de los valores de las muestras
próximas.
Métodos y materiales
22
2.2.3. Estimación del espectro
Con el procesamiento de una señal biológica lo que se pretende es extraer la
información útil de la señal. Según el tipo de señal puede resultar interesante obtener la
información contenida en el dominio de la frecuencia, en el dominio temporal o en
ambos a la vez. Según esto se requerirá un método de análisis u otro.
El análisis del contenido espectral resulta de interés en el procesado de la mayoría de
señales biológicas [26]. Si este análisis se realiza además en un sistema en tiempo real,
el cálculo tendrá que ser rápido y eficiente. La respuesta en frecuencia se calcula
generalmente mediante DFT (Discrete Fourier Transform); sin embargo, en la práctica
se utiliza un método computacionalmente más rápido y eficiente de calcularla. Este
método es la FFT (Fast Fourier Transform). Matemáticamente, la DFT y la FFT son
equivalentes; sin embargo, en el cálculo de una DFT de N puntos se requiere un total de N� operaciones, mientras que la FFT necesitan N. log� N operaciones para completarlo
[19]. De esta forma se consigue reducir el número de operaciones y el tiempo de
cálculo, lo cual resulta relevante en los sistemas embebidos.
La mayoría de señales biomédicas no son estacionarias y en algunas ocasiones la
información temporal de la señal no se puede obviar, sino que aporta una serie de
información adicional importante. En este caso pueden emplearse los métodos tiempo-
frecuencia o los métodos tiempo-escala (también conocido como análisis Wavelet), los
cuales asumen que la señal no es estacionaria en el tiempo y permiten conocer la
distribución espectral así como el instante de tiempo en el que se da dicha distribución.
Un ejemplo de aplicación de estas técnicas son las imágenes médicas [26].
En la mayor parte de las señales biológicas resulta fundamental el análisis frecuencial
para extraer la información útil de las mismas. Es el caso, por ejemplo, de señales como
el ritmo cardíaco, los sonidos del corazón y los estomacales e intestinales, el
movimiento de ojos y otras respuestas motoras [26], así como las señales recogidas por
medio de pruebas como los electromiogramas (EMG), electroencefalogramas (EEG) y
electrocardiogramas (ECG).
Los métodos modernos de estimación espectral pueden clasificarse en paramétricos y no
paramétricos. A continuación vamos a ver estas técnicas de forma más amplia.
Métodos y materiales
23
Los métodos no paramétricos calculan la densidad espectral de potencia a partir de la
propia señal estimando la secuencia de autocorrelación a partir de los datos disponibles
y calculando su transformada en el dominio de la frecuencia. Estos métodos son
computacionalmente eficientes, no obstante el resultado es muy dependiente de la
fidelidad de la estimación de la autocorrelación, por lo que la resolución en frecuencia
va a estar limitada por la longitud de los datos de los que se disponga, entre otros
factores.
Los métodos paramétricos permiten construir un modelo, o proceso lineal, del sistema
que generó la señal asumiendo ruido blanco como entrada y estimando una serie de
parámetros a partir de los datos disponibles. La salida del modelo se va comparando con
la señal de entrada, modificando los parámetros del modelo hasta que ambos coincidan.
Cuando esto ocurra, la característica espectral del modelo será la estimación espectral
de la señal de entrada [26]. Esto se debe a que la entrada del modelo es ruido blanco que
es espectralmente plano, por lo que el espectro a la salida es directamente la magnitud
de la función de transferencia del modelo. En la Figura 3 se detalla gráficamente cómo
se realiza la estimación espectral en los modelos paramétricos.
Figura 3: Algoritmo de funcionamiento de los modelos paramétricos. Tomado de [26].
De este modo, podemos decir que los procesos lineales permiten modelar una secuencia
de datos como la salida de un filtro lineal ante una señal de entrada aleatoria. Así, para
el análisis del espectro mediante un modelado paramétrico de la señal, se busca el tipo
de modelo más adecuado de entre los existentes según el tipo de datos de la aplicación
que se esté tratando, estimando también el orden óptimo de dicho modelo.
Ajuste deparámetros
ModeloLineal
Comparación
Cálculo delespectro
Ruidoblanco
Señal deentrada
Espectroestimado
Salida delmodelo
Métodos y materiales
24
En la práctica del procesado digital de señales se emplean sobretodo los modelos
lineales debido a que permiten obtener una mejor estimación espectral en comparación
con los otros métodos, especialmente con secuencias de datos cortas.
Modelo paramétrico
En el modelado lineal de procesos aleatorios existen 3 tipos básicos de estructuras que
atienden a una función H(z) racional. Se trata de los modelos autorregresivo (AR) o
todo-polos, de promedio móvil (MA) o todo-ceros y autorregresivo y de promedio móvil
(ARMA). En la Figura 4, donde �[ ] es ruido blanco, pueden verse estos tipos.
Figura 4: Tipos de modelos lineales. (a) Modelo AR. (b) Modelo MA. (c) Modelo ARMA.
De ellos, el modelo AR es el más empleado debido a que su diseño es relativamente
sencillo en comparación con los otros dos modelos, además de que puede encontrarse
disponible gran cantidad de teoría para su análisis [27]. Asimismo, el modelo AR
consigue una buena estimación del espectro para secuencias finitas y es adecuado para
representar picos abruptos de frecuencia, como es el caso, por ejemplo, de las señales de
acelerometría.
Podemos encontrar varios métodos para la estimación de los parámetros del modelo
autorregresivo [27]. Todos ellos calculan los mismos parámetros de forma diferente.
Por nombrar algunos de ellos podemos citar el método de la covarianza, el método de la
autocorrelación o el método de Burg.
w[n] x[n]
w[n] x[n]
w[n] x[n]
(a)
(b)
(c)
Métodos y materiales
25
Orden óptimo del modelo paramétrico
Además de elegir el tipo de método, es igualmente importante seleccionar un orden
apropiado para el modelo paramétrico autorregresivo. El orden nos da una idea de la
exactitud con la que se estima el modelo por lo que se busca un valor del orden que
represente el proceso correctamente a la vez que minimice la complejidad del modelo.
Al tomar un orden demasiado bajo se corre el riesgo de suavizar el espectro, del mismo
modo que un orden excesivamente alto también puede tener efectos negativos al
suponer la posible introducción de picos en el espectro.
Si los datos pueden ser efectivamente descritos por un modelo AR de orden finito, la
varianza del error de predicción teórica se hace constante una vez que se alcanza el
orden del modelo [27]. Aunque existen diferentes criterios para determinar el orden
óptimo del modelo paramétrico, todos ellos buscan el que minimice el error de
predicción del modelo a través de funciones de coste. Si este orden es muy elevado
(supera el máximo N/2) se toma el valor en el que el valor criterio empieza a decrecer
lentamente [27].
Es posible acotar el rango de órdenes adecuados para el modelo según las características
de la señal de entrada. Según Shiavi [28], si el número de muestras N es bajo el rango
de selección del orden sería (N/3, N/2).
Aunque hay otros criterios, para seleccionar el orden óptimo del modelo se han elegido
tanto métodos que vienen siendo tradicionales, como el Criterio de Información Teórica
de Akaike (AIC) o el criterio de Mínima Longitud de Descripción de Rissanen (MDL),
como métodos más recientes como es el Criterio de Información Combinada (CIC).
Este criterio fue desarrollado por Boersen [29] y entre sus principales características
destaca su robustez para señales con un número finito de muestras además de que, junto
con el método Burg de estimación, supone una combinación muy fiable en la práctica
en el modelado autorregresivo [31].
A continuación se detallan los criterios para la selección del orden del modelo AR:
AIC ���(�) = � ln ���� + 2�
MDL ���(�) = � ln ���� + � ln �
Métodos y materiales
26
CIC ���(�) = � � !"(#)$ + %&' () 1 + +(,,∙)1 + +(,,∙)�
/01 − 1 , 3 5 +(,,∙)�/01 6
Donde,
N: número de muestras
P: orden
σ89� : error de predicción
RES(p) ≈ v(i, Burg) v(i, Burg) = 1 (N + 1 − i)D
2.2.4. Procesado digital de las señales para la detección de
caídas
En la sección anterior, se han expuesto algunas de las técnicas empleadas en el
procesamiento de señales biológicas. En este apartado se detalla el tipo de
procesamiento llevado a cabo en el caso concreto de las señales de acelerometría.
El algoritmo de detección de caídas trata este tipo de señales de forma que permite
extraer la información necesaria para determinar si el evento recogido en ellas se
corresponde o no con una caída. Ha sido diseñado por los investigadores del Grupo de
Ingeniería Biomédica y está implementado en el portable de monitorización del
movimiento humano diseñado por este mismo grupo [16].
Se trata de un sistema de procesado distribuido formado básicamente por un sensor
acelerómetro inteligente (IAU) y un servidor personal (PSE) [16]. El primero lleva a
cabo un procesado previo mientras que el segundo se encarga del procesado definitivo
[12],[17]. La IAU se encarga de recoger los datos captados por el sensor acelerómetro
triaxial. El dispositivo realiza además un procesado temporal preliminar para determinar
si el evento recogido se trata de un impacto. En caso de que así sea, las muestras son
almacenadas y enviadas al PSE para un procesamiento más exhaustivo. El PSE analiza
en profundidad los datos procedentes de la IAU mediante el algoritmo de detección de
caídas, el cual lleva a cabo tanto un análisis temporal como espectral de la señal, y
Métodos y materiales
27
determina si el impacto detectado por la IAU se trata o no de una caída. En caso de que
así sea, envía la correspondiente notificación a la unidad de acceso remoto (RAU) que
es el dispositivo encargado de remitir la información a los servicios de teleasistencia.
La arquitectura del sistema de monitorización puede observarse en la Figura 5.
Figura 5: Arquitectura del sistema de monitorización diseñado por el GIB [16].
De este modo, el algoritmo, ejecutado desde el PSE, recibe la información de un evento
en forma de tres señales de acelerometría (una por cada eje de aceleración) procedentes
de la IAU; las procesa y, por último, realiza la clasificación del evento en función del
resultado obtenido tras el procesamiento.
Estas señales presentan unas características particulares por lo que, de entre las técnicas
presentadas anteriormente en este capítulo, se tomarán aquellas que resulten más
convenientes para esta aplicación concreta. En la Figura 6, pueden verse ejemplos de
este tipo de señal.
Métodos y materiales
28
Figura 6: Ejemplo de señal de acelerometría a la salida del acelerómetro triaxial. Aceleración (eje y) frente a
muestras en el tiempo (eje x).
El procesado consta en primer lugar de un enventanado temporal de la señal. De este
modo, el algoritmo internamente procesa un menor número de muestras con los
beneficios computacionales que ello conlleva y por otra parte, realiza un análisis más
exhaustivo de la señal.
Las señales de acelerometría son señales muy ruidosas por lo que resulta necesario un
filtrado previo que reduzca los picos de ruido y mejore la relación Señal-Ruido de la
señal recibida. Para ello se hace uso de un filtro mediano de media 3 [25].
Dado que el acelerómetro mide la suma de todas las aceleraciones presentes en cada eje
de aceleración, como la componente de aceleración debida a la gravedad (componente
estática) y la componente debida al movimiento del cuerpo (componente dinámica)
entre otras [25], se realiza un segundo filtrado con tal de separar la componente de
aceleración gravitacional y la componente debida al movimiento del cuerpo. Para ello se
implementa un filtro elíptico. Estos filtros son lineales y consiguen implementar un
filtro de menor orden para unas especificaciones dadas o, visto desde otro punto de
vista, consiguen una transición más estrecha para un mismo orden en comparación con
otro tipo de filtros lineales. Por otra parte, los filtros elípticos no tienen fase lineal pero
esto no supone un inconveniente ya que en el procesado de las señales de acelerometría
la fase no aporta información útil.
La componente de aceleración gravitacional aporta información acerca de la orientación
del dispositivo [25] por lo que el análisis temporal de la misma puede ayudar a
Métodos y materiales
29
determinar la postura del sujeto que está siendo monitorizado. Para ello se calcula el
ángulo formado por la aceleración de la gravedad con la correspondiente aceleración
vertical del sensor acelerómetro [25].
Por último el procesado espectral de la componente dinámica de la aceleración ofrece
información adicional sobre el evento producido para confirmar si el posible impacto
previamente detectado por el sensor acelerométrico [12],[16] es una caída.
Otra característica importante de este tipo de señales que conviene tener en cuenta en su
análisis frecuencial, es que presentan picos abruptos como se puede apreciar en la señal
representada en la Figura 6. En la estimación espectral del algoritmo se emplean
modelos lineales. En concreto se ha tomado el modelo AR debido a tres motivos
fundamentales:
• su sencillez con respecto de otros modelos,
• realiza una buena estimación del espectro para secuencias finitas,
• es adecuado para representar picos abruptos de frecuencia, lo cual es muy
importante al tratarse de señales de acelerometría.
En cuanto a la estimación de los parámetros del modelo AR, podemos encontrar varios
métodos expuesto en el apartado de Materiales y Métodos. Sin embargo, se ha optado
por utilizar el método de Burg, que estima los parámetros del modelo directamente de
los datos disponibles sin necesidad de realizar cálculos intermedios [27].
2.3. Generación y optimización de código para sistemas
embebidos
Los entornos de desarrollo de procesado matemático son muy útiles para el diseño de
algoritmos ya que permite la implementación y prueba de código de forma
relativamente sencilla y rápida. Las características de los lenguajes de alto nivel propios
de estos entornos de programación, además de su flexibilidad o la simplicidad y
claridad de su interfaz, facilitan a los diseñadores el desarrollo de los algoritmos de
procesamiento de señales, que se desearán implementar posteriormente en sistemas
Métodos y materiales
30
embebidos. Un ejemplo muy representativo es Matlab, de Mathworks, que es una de las
herramientas de este tipo más usadas en el mundo.
Los DSPs ejecutan código en lenguaje máquina, que es el conjunto de códigos que
contienen operaciones básicas directamente compilables o interpretables por la unidad
central de procesamiento de un circuito integrado programable [30] como pueden ser no
sólo los DSPs, sino también los microprocesadores, microcontroladores, etc. El lenguaje
máquina se genera mediante software específico a partir de un código fuente en
lenguaje de programación de medio o alto nivel, el cual puede no coincidir con el
lenguaje de programación de la herramienta de computación matemática en el que se
diseña inicialmente la aplicación.
La optimización de aplicaciones, resulta fundamental en los sistemas embebidos. La
ocupación en memoria y el tiempo de ejecución del programa son los indicadores más
empleados en la medida del rendimiento de un sistema de tiempo real y aunque es
deseable que ambos sean mínimos especialmente en las aplicaciones biomédicas de
monitorización, es complicado o en ocasiones imposible optimizar más de un indicador
a la vez y generalmente la mejora de uno va en detrimento del otro [24]. Por ello, en
cada aplicación concreta se hará un estudio de los requisitos para determinar cuál de
estos aspectos es más crítico en el sistema, bien para intentar mejorar uno de ellos o
bien para buscar un equilibrio entre ellos en la fase de optimización si por el contrario
resulta más beneficioso.
En este apartado se van a describir todos aquellos entornos de programación que nos
sirven como herramienta para alcanzar uno de los objetivos concretos del proyecto
como es la implementación de algoritmos de procesado digital en el DSP de un sistema
embebido a partir de su diseño experimental, cumpliendo con las condiciones de diseño
del sistema.
2.3.1. Embedded Matlab
Matlab es muy útil para el diseño de algoritmos ya que permite la implementación y
simulación de la aplicación de un modo más bien sencillo, ágil y dinámico. Ofrece a los
diseñadores de software un entorno muy atractivo en el que desarrollar sus aplicaciones
por las características particulares del lenguaje Matlab. Sin embargo, por lo general, no
Métodos y materiales
31
es posible generar aplicaciones ejecutables por dispositivos integrados a partir de él. Por
este motivo es necesario convertir el código diseñado a un determinado lenguaje de
programación a partir del cual sea posible generar el código en lenguaje máquina
ejecutable por el DSP.
En un primer momento puede pensarse en la reprogramación manual del código inicial
como única solución. Este procedimiento representa una opción real si el tamaño del
código a implementar es abordable, pero puede suponer un problema si no lo es al ser
necesario invertir más recursos o, lo que es más importante, más tiempo para lograrlo.
Otra desventaja de este procedimiento se halla en la necesidad de repetir de nuevo la
verificación que conlleva implícitamente la tarea de implementación de código, como si
de un nuevo algoritmo se tratara. Así pues, puede resultar muy interesante, además de
provechoso, la conversión automática de código Matlab a lenguaje intermedio. Uno de
los lenguajes de programación más utilizados que sirven de puente para la generación
de código máquina es el lenguaje C, por lo que Matlab dispone de nuevas herramientas
que abordan esta cuestión y que pueden facilitar la conversión de Matlab a lenguaje C
reduciendo el coste de desarrollo y verificación del algoritmo final. Estas herramientas
pueden convertir una parte del lenguaje Matlab, llamado Embedded Matlab, a código C
embebido.
Embedded Matlab es el subconjunto dentro del lenguaje de programación Matlab que
soporta la generación de código eficiente para el prototipado y desarrollo de sistemas
embebidos. Está formado por más de 270 operadores y funciones tradicionales de
Matlab además de alrededor de 90 funciones para el desarrollo de software en punto fijo
[32].
Cabe destacar algunas de las características de Matlab que soporta Embedded Matlab
como arrays de más de una dimensión, operaciones con matrices, números complejos,
diferentes tipos de variables y clases numéricas, aritmética de punto fijo, estructuras de
control de flujo (if, switch, while, for), subfunciones, variables persistentes, estructuras,
caracteres o llamadas a funciones de Matlab entre otras características [33]. Puede
emplearse en diversas tareas como la generación de código C desde código Matlab,
generación de funciones C-MEX (C Matlab Executable) desde código Matlab para la
verificación desde Matlab del código C generado, generación de código HDL
(Hardware Description Language) desde código Matlab, integración de código Matlab
Métodos y materiales
32
en Simulink o integrar código C en Matlab, entre otros. De entre estas características
resulta de especial interés la capacidad de generación de código C a partir de código
Matlab, además de poder verificar el código C generado dentro del entorno Matlab.
Para ello es necesario contar con Real-Time Workshop (RTW) que se trata del back-end
o motor específico para la generación de código C embebido a partir de funciones de
Embedded Matlab en Simulink, Stateflow o en código Matlab plano por medio de su
característica Real-Time Workshop Embedded Coder. Así pues, Real-time Workshop es
la herramienta que genera y ejecuta código C independiente para desarrollo y
verificación de algoritmos modelados en Simulink o en código Embedded Matlab, de
modo que permite obtener código eficiente para aplicaciones en tiempo real al mismo
tiempo que permite realizar todo el proceso, desde el diseño del algoritmo hasta la
consecución del código C, sin salir del entorno Matlab.
Limitaciones de Embedded Matlab
No todos los elementos de Matlab son susceptibles de convertirse a C, solamente el
subconjunto Embedded Matlab, que soporta parte de los operadores y de las funciones
de Matlab pero no todos. Aquellos elementos presentes en el código que no estén
incluidos en el subconjunto generan errores en la compilación, los cuales son
convenientemente señalados en un informe en formato html. En el desarrollo de un
algoritmo en Matlab, normalmente no se presta atención a estas limitaciones pero es
interesante conocerlas ya que, si se tienen en cuenta desde un principio, es posible evitar
el trabajo de reprogramación que suponen los errores que se ponen de relieve en la
compilación.
Embedded Matlab no soporta [33]: Cell arrays (son matrices cuyas celdas pueden
contener datos de distinto tipo), la dualidad comando/función, variables dinámicas,
variables globales, funciones anidadas, objetos, “sparse matrices” y las declaraciones
“try” y “catch”.
Conviene tener en cuenta algunas de las diferencias entre el lenguaje Matlab y el
lenguaje C de cara a una posterior conversión de uno a otro, de esta forma es posible
salvar algunas de las limitaciones de Embedded Matlab.
Métodos y materiales
33
En una primera toma de contacto se evidencia que Matlab no necesita declarar las
variables antes de ser utilizadas; en cambio en lenguaje C es necesario declarar las
variables previamente. En la declaración se especifica, además del nombre de la
variable, el tipo y, en caso de tratarse de arrays, la longitud de los mismos. Además,
Matlab utiliza por defecto variables de precisión doble de 64 bits (double). Si no se
especifica el tipo de cada variable en la implementación en Matlab, todas pasarán a ser
del mismo tipo que eran originalmente, es decir de tipo “double” lo que de ningún modo
resulta eficiente en el código C resultante. Otra diferencia importante reside en la forma
de manejar los arrays. En lenguaje C han de tratarse elemento a elemento, tanto en la
asignación como en la operación mediante bucles for. En Matlab se simplifica bastante,
ya que la asignación puede realizarse como si de una variable entera se tratase mediante
el operador “=”, del mismo modo que se puede operar elemento a elemento añadiendo
el operador “.” a la operación que se quiere realizar. También existen diferencias
importantes entre ambos lenguajes en lo que a archivos de cabecera, definición de
funciones y paso de parámetros se refiere.
En cuanto a la utilización de la memoria se encuentran diferencias sustanciales. Matlab
asigna la memoria dinámicamente por lo que el tamaño de las variables puede cambiar
en tiempo de ejecución. Sin embargo, en sistemas embebidos es preferible la asignación
estática de la memoria, de modo que las variables tienen una longitud fija definida en su
declaración. Es por ello que, en lenguaje C, los arrays se suelen sobredimensionar pues
una vez definidos no pueden crecer.
Algo que no se tiene en cuenta en el diseño de algoritmos en Matlab y sí en el diseño
de aplicaciones embebidas es la importancia de analizar el algoritmo para asegurarse de
que opera de forma eficiente, dentro de la ocupación en memoria requerida y de los
recursos de los que se dispone con la finalidad de reducir la complejidad computacional
y el total de memoria ocupada. En función de los recursos requeridos y de los
disponibles puede ser necesario que el algoritmo sea especificado con tipos de datos de
punto fijo para su implementación embebida [34].
Métodos y materiales
34
Funciones C-MEX
Una de las características de Embedded Matlab es que permite verificar el código C
generado dentro del entorno Matlab, es decir, es posible compilar código C en funciones
que pueden ser llamadas desde Matlab. Este tipo de funciones son las funciones MEX
que permiten aprovechar el alto rendimiento de C, C++ o Fortran mientras se trabaja en
Matlab.
En definitiva, las funciones C-MEX no son más que funciones en código C que tienen
la particularidad de ser ejecutables desde Matlab dando la posibilidad de trabajar con
funciones en código Matlab y funciones en código C simultáneamente. De este modo,
se permite una conversión y verificación escalada del código al poder verificar cada
parte del código convertido dentro del algoritmo completo aunque éste no se haya
convertido en su totalidad.
Pasos para la conversión de código de Embedded Matlab a C
Antes de generar el código C fuente, es recomendable comprobar el algoritmo mediante
la generación de funciones C-MEX. El comando utilizado es el mismo tanto en la
generación de funciones C-MEX como en la generación de funciones C, se diferencian
por las opciones que especificamos según el caso.
Por todo esto, a continuación se va a comentar cómo generar una función C-MEX para
la comprobación del algoritmo. Después, se explica detalladamente cómo generar una
función en código C embebible y compilarla en una librería.
• Comprobación del algoritmo: generación de funciones C-MEX:
En este primer paso, no se genera código C fuente sino que se crea una función C-MEX,
es decir, una función en código C ejecutable desde Matlab pero sin llegar a ser
funciones C ejecutables por sí mismas. De este modo se puede verificar desde Matlab
que al pasar a código C el algoritmo sigue comportándose del mismo modo, esto es, que
el algoritmo no ha sido alterado a causa de la conversión y que la función C-MEX sigue
realizando la misma tarea que la función original en Matlab.
Se utiliza el pragma %#eml en la función que queremos comprobar.
Métodos y materiales
35
Después, desde la línea de comandos se introduce:
emlc -o nombrefuncionx -report nombrefuncion.m -eg{z}
Donde,
-o: indica que se genere función C-MEX.
-report: indica que se genere un informe de compilación.
-eg{z}: la entrada de la función se especifica mediante un ejemplo en la variable z,
que ha de ser declarada previamente.
Como se ha explicado, la entrada de la función se especifica a través de una variable
que sirve como ejemplo del tipo de parámetro que tendrá la función como entrada. Hay
que tener en cuenta que la función C-MEX sólo admitirá como válidas aquellas entradas
que sean del mismo tipo, longitud, tamaño, etc. que la variable que se utilizó como
ejemplo cuando fue generada.
La nueva función generada puede ser llamada en el entorno Matlab del mismo modo
que una función Matlab ordinaria. Así, simplemente sustituyendo la función original por
su correspondiente función C-MEX se podrá comprobar si el código generado realiza la
misma función que el código original Matlab.
• Generación de código C:
Una vez verificada la función, se genera el código fuente, obteniendo la función C y los
demás archivos necesarios para su compilación. Desde la línea de comandos se
introduce:
emlc -c -T RTW -report nombrefuncion.m -eg{z}
Donde,
-c: indica que se genere código C.
-T RTW: genera código C embebible y lo compila en una librería.
-report: indica que se genere un informe de compilación.
-eg{z}: la entrada de la función se especifica mediante un ejemplo en la variable z,
que ha de ser declarada previamente.
Métodos y materiales
36
Profundizando en la forma en que Embedded Matlab implementa el código C
automáticamente, cabe destacar algunos puntos importantes. Embedded Matlab vuelve
constantes todas aquellas variables que dependen a su vez de otras variables que
considera constantes. Por ello puede ser necesario editar el código C generado en
algunos casos. Por otra parte, en la conversión automática que lleva a cabo RTW, define
los tipos de datos en todos los casos. Por ejemplo, real_T hace referencia al tipo double
así como real32_T equivale a single de Matlab. En la Tabla 1 se muestran las
equivalencias de forma más completa.
Matlab C RTW
double double real_T
single float real32_T
int32 long long int int32_T
int16 long int int16_T
int8 short int int8_T
uint32 unsigned long long int uint32_T
uint16 unsigned long int uint16_T
uint8 unsigned short int uint8_T
int int int_T
uint unsigned int uint_T
boolean - boolean_T
char char char_T
Tabla 1: Equivalencias de los tipos de variables básicas en Matlab, lenguaje C y Real-Time Workshop.
2.3.2. Compilador de C de propósito general
Uno de los lenguajes de programación más utilizados y especialmente en el desarrollo
de sistemas embebidos, es el lenguaje C. Este lenguaje es muy utilizado debido su
extendido uso en entornos académicos y profesionales. Su portabilidad, el grado de
optimización en cuanto a eficiencia, ocupación en memoria y velocidad de
procesamiento que es posible alcanzar en aplicaciones embebidas son características
que dan lugar precisamente a que pueda ser compilado por un gran número de entornos
de desarrollo integrados.
Métodos y materiales
37
Bloodshed Dev-C++ es un entorno de desarrollo integrado para lenguaje C/C++ de libre
acceso [35] y costa de un editor de texto y un compilador de código fuente. El
compilador traduce el programa fuente completo a un programa de bajo nivel que puede
ser ejecutado directamente por un procesador [30].
Se considera interesante en el desarrollo de aplicaciones ya que permite llevar a cabo
una verificación de un programa en lenguaje C de forma independiente en un entorno
totalmente separado de otras herramientas que pueden ser empleadas en el proceso de
desarrollo de software embebido, como pueden ser Matlab o Code Composer Studio.
Con ello, se persigue conseguir que el código escrito sea independiente de plataforma,
de modo que al tratarse de código fuente plano, pueda ser compilado por cualquier
herramienta de desarrollo de software e implementado en cualquier entorno ya sea un
DSP, un microcontrolador, etc.
2.3.3. Code Composer Studio
Code Composer Studio (CCS) es un entorno de desarrollo integrado para procesadores
digitales de señal, microcontroladores y procesadores de aplicación de Texas
Instruments (TI) [36]. Se trata de un software formado por una serie de procedimientos
desarrollados para el hardware concreto de los DSPs de Texas Instruments. Implementa
las capas de abstracción de hardware (HAL), las cuales funcionan como interfaz entre el
hardware y el software de aplicación de un sistema, de modo que facilita la tarea de
acceso al hardware por parte del usuario a través de un interfaz sumamente intuitivo,
tarea que, de otro modo, podría resultar dificultosa.
Este software está formado por un conjunto de elementos que permiten desarrollar y
depurar aplicaciones embebidas para dispositivos de Texas Instruments como distintos
compiladores, editor de código fuente o simuladores, dando la posibilidad de
seleccionar un target concreto dentro de la familia de DSPs de Texas Instruments.
Proporciona al usuario un único interfaz con el que abordar cada uno de los pasos a
seguir en el proceso de desarrollo de aplicaciones embebidas y permite así reducir el
tiempo invertido en el desarrollo e integración de software para DSPs.
Métodos y materiales
38
CCS genera código ejecutable por el DSP a partir de código en lenguaje C en tres pasos
básicos: la compilación del código fuente de la aplicación, la construcción del archivo
ejecutable y la carga en la memoria RAM del target. A bajo nivel, este proceso implica
tres herramientas de generación de código fundamentales [37]: el compilador (compiler)
C/C++, el ensamblador (assembler) y el enlazador (linker). En primer lugar, CCS
genera código en lenguaje ensamblador a partir de código C, mediante el módulo
compilador de C/C++. A continuación, convierte el código ensamblador fuente en un
conjunto de archivos objeto de lenguaje máquina que el procesador del DSP puede
ejecutar, mediante el módulo llamado ensamblador. CCS también enlaza las secciones
separadas del código objeto que forman la aplicación y las combina en uno sólo para
producir un único archivo ejecutable con el módulo enlazador. En la Figura 7 se observa
este proceso de forma esquemática.
Figura 7: Proceso de generación de código ejecutable a partir de código fuente en lenguaje C.
Algunas familias de DSPs permiten el arranque de aplicaciones desde una memoria
externa. En la versión 3.3 y anteriores, CCS posibilita el manejo de scripts de
configuración del modo de arranque mediante el denominado CCS Scripting, el cual
está configurado para usar el intérprete de Perl ActivePerl (de la compañía ActiveState)
en su versión para el sistema operativo Windows. ActivePerl es un software que da
soporte a la ejecución de programas en lenguaje Perl por lo que es necesaria su
instalación junto con la de CCS. Así pues, para configurar el modo de arranque
ActivePerl proporciona dos herramientas software basadas en scripts que se ejecutan en
modo comando [38]. Por una parte, la aplicación genBootCfg.pl genera los ficheros de
configuración del arranque para cualquier modo. Por otra parte, necesariamente para la
conformación del arranque desde memoria externa, el software genAIS.pl genera el
programa binario de arranque a partir del fichero ejecutable enlazado .out creado en la
compilación del código fuente, y del fichero de configuración .cfg generado por la
aplicación genBootcfg.pl.
COMPILADORcódigo
ensamblador(.s)
ENSAMBLADORcódigoobjeto(.o)
códigofuente(.c)
ENLAZADORcódigo
ejecutable(.out)
Métodos y materiales
39
En la generación de un archivo ejecutable podemos encontrar archivos de diferente tipo
de los cuales algunos son obligatorios, mientras que otros dependen de la aplicación
concreta:
• .c: código fuente de la aplicación.
• .h: archivos de cabecera.
• .lib: facilitados por TI, estos archivos proporcionan soporte para el dispositivo
DSP correspondiente.
• .asm: contiene instrucciones en lenguaje ensamblador.
• .cmd: contiene la configuración de las secciones de memoria.
Para compilar un programa sencillo, son necesarios los archivos de código fuente (.c) y
los archivos de cabecera (.h). En función de la aplicación concreta puede añadirse las
librerías correspondientes (.lib) y/o partes del código e instrucciones que ya se
encuentren en lenguaje ensamblador (.asm).
Si se desea compilar un programa más complejo o simplemente utilizar las herramientas
de depuración y análisis en tiempo real que ofrece el entorno CCS, es posible hacer uso
de la herramienta software DSP/BIOS [39]. DSP/BIOS es la parte de CCS para
aplicaciones en tiempo real. Está formado por una serie de elementos entre los que
podemos destacar el módulo de gestión del reloj del sistema (CLK), el gestor de
memoria (MEM), el gestor del registro de eventos (LOG), el gestor de intercambio de
datos en tiempo real (Real Time Data Exchange, RTDX), el gestor de estdísticas (STS)
o el gestor de multitarea (TSK). DSP/BIOS proporciona comunicación entre el host y el
target de forma eficiente (RTDX), así como instrumentación de tiempo real (RTA).
Consta de una interfaz gráfica para facilitar la configuración tanto de RTDX como de
RTA, además de la generación de archivos de configuración (.cmd) que permiten, entre
otros, organizar la memoria, definir tareas, hilos, interrupciones hardware y software
además de establecer sus prioridades.
La instrumentación RTA [40] permite monitorizar y depurar el programa en tiempo real
interfiriendo mínimamente en su tiempo de ejecución y ocupación en memoria. Está
formada por varias herramientas de distinta índole, que pueden ser bien de exposición
Métodos y materiales
40
de mensajes de eventos por pantalla en un registro, bien de presentación de resultados
estadísticos o gráficos entre otros. Veamos estas herramientas con más detenimiento:
• Registro de eventos (Event LOG): En la depuración del código en aplicaciones
en tiempo real no se recomienda el uso de la función de biblioteca de C printf
contenida en la biblioteca RTS para mostrar mensajes por pantalla que nos
ayuden a determinar el correcto funcionamiento del programa. Se debe a que
requiere un número importante de ciclos de CPU para completarse, de forma que
puede alterar significativamente el normal funcionamiento del programa en
tiempo real [19]. En su lugar, es aconsejable la utilización de LOG_printf que
hace uso del registro de eventos. Es una función escrita directamente en lenguaje
ensamblador por lo que es mucho más pequeña y tiene un tiempo de ejecución
mucho menor.
• Estadísticas STS (STS Statistics): Muestra las estadísticas de los objetos creados
por el usuario como tareas, interrupciones hardware o software, etc.
• Host Channel Control: Monitoriza los canales definidos por el programa entre el
host y el target. Permite asociar archivos a cada canal e iniciar la transferencia
de datos.
• Gráfica de ejecución (Execution Graph): Facilita la visualización de la actividad
de los distintos objetos en función del tiempo y la interacción entre ellos.
• Gráfica de carga de la CPU (CPU Load): Muestra la gráfica de carga de la CPU.
• Vista del Kernel (Kernel Object View): Ofrece una perspectiva general de la
configuración y el estado de los objetos ejecutados por el DSP. Proporciona
información útil como cual ha sido el espacio de memoria asignado y cuanto de
ese espacio se ha usado, indicando desbordamiento si existiese en algún caso.
CCS presenta además un modo simulador [41] que permite configurar un procesador
ficticio que también incorpora diversos tipos de DSPs y que puede resultar de gran
utilidad en la comprobación del funcionamiento y depuración de la aplicación como
fase previa a la verificación en el dispositivo real. Las herramientas RTA también se
encuentran disponibles en modo simulador, con la excepción de la gráfica de carga de la
CPU que únicamente puede emplearse en comunicación con un DSP real. No obstante,
Métodos y materiales
41
este modo de operación no es aplicable en escenarios donde se requiera el uso de
elementos específicos del hardware y que implican principalmente manejo de puertos.
Aunque desde el punto de vista de la implementación de código resultaría más eficiente
programar directamente en código ensamblador, el compilador de CCS para
procesadores de la familia C6x puede alcanzar un rendimiento de más del 70%
comparado con el código escrito directamente en lenguaje ensamblador [37]. De este
modo, es posible obtener aplicaciones embebidas óptimas desde el programa
implementado en código C.
2.3.4. Método iterativo para implementación de software
El software de un sistema embebido se diseña específicamente para una plataforma
hardware determinada. Los métodos actuales de desarrollo tienen esto en cuenta y
proponen pautas para el despliegue de software y hardware embebidos en paralelo. Esto
es lo que se conoce como codesarrollo [21] y establece una serie de directrices para
implementar sistemas embebidos de forma coordinada y eficaz.
Tener clara la metodología de diseño que se va a seguir permite ahorrar tiempo a largo
plazo y adquirir un grado de conocimiento acerca del proceso que puede ser de utilidad
en futuros desarrollos. En el desarrollo de software embebido, es posible adoptar el
modelo Harmony Embedded Software (Harmony/ESW) [22] perteneciente a la familia
de procesos Harmony. Este método consiste en desarrollar un software funcional para
después, a partir de él, depurarlo y mejorarlo progresivamente mediante cambios
incrementales, hasta cumplir los requisitos deseados. Es un procedimiento iterativo
[21]-[23] en el que las fases que lo componen se recorren cíclicamente de forma que los
resultados de un ciclo determinan las acciones a llevar a cabo en el siguiente, lo que
permite aprovechar la experiencia recogida para mejorar el diseño en el siguiente ciclo y
optimizarlo rápida y dinámicamente. En la Figura 8 puede verse un esquema funcional
de este modelo iterativo.
Métodos y materiales
42
Figura 8: Método de desarrollo de software embebido Harmony/ESW.
Una vez que la aplicación presenta el funcionamiento deseado y un comportamiento
estable, empieza la mejora de la aplicación en términos de optimización. Las principales
condiciones de diseño de los sistemas embebidos [21] en comparación con los que no lo
son, hacen referencia a aspectos tales como la ocupación en memoria y el tiempo de
ejecución de los algoritmos implementados.
Es posible optimizar en diferentes puntos a lo largo del desarrollo de una aplicación
embebida, pero lo más habitual es hacerlo sobre el código fuente. En este caso, el
programador implementa el código de la forma más óptima según el indicador que
desee mejorar. Cada uno de los cambios realizados se valida dando lugar a una
optimización iterativa, siguiendo el modelo Harmony/ESW como se observa en la
Figura 8. Además, en el código es posible escribir directrices que ofrecen una mayor
información sobre algunas partes del mismo de forma que se puede compilar más
eficientemente [24], pues la compilación del código fuente también lleva implícitamente
una fase de optimización. Es decir, para generar el programa de bajo nivel, el
compilador realiza en primer lugar un análisis del código para después pasar a la etapa
de síntesis, en la que pueden darse las optimizaciones según las opciones del
compilador.
Métodos y materiales
43
2.4. Descripción del prototipo hardware del PSE
El prototipo del PSE está formado por un DSP de punto flotante de última generación
de Texas Instruments de la familia TMS320C6727. Su CPU opera a 300MHz y consta
de una memoria ROM de 384Kb y 256Kb de memoria RAM. Se ha incorporado una
memoria flash de 1Mb para albergar tanto código para el procesado de señal como
datos. Completa el módulo central un controlador que supervisa la actividad de la CPU
y del resto de elementos, con la finalidad de monitorizar el consumo de batería así como
su carga [12].
El módulo de comunicaciones está compuesto por todos aquellos dispositivos
necesarios para llevar a cabo la comunicación del PSE con el resto de elementos del
sistema. La comunicación del PSE con la IAU se establece mediante el estándar Zigbee,
para lo cual se emplea el transceptor CC2430 de Chipcom, fabricado por Texas
Instruments. Para la comunicación entre el PSE y RAU se realiza vía Bluetooth
mediante el transceptor STLC2500C de ST Microelectronics. Por últmo, el PSE se
comunica con el PC tanto mediante el conector JTAG como a través de infrarrojos con
el transceptor HSDL 3021 de Avago Technology.
El interfaz de usuario está formado por elementos tanto visuales como auditivos, de
modo que el usuario reciba información procedente del terminal. De este modo, el
usuario interactúa con el dispositivo a través del display LCD EM6125COG de EM
Microelectronics, el módulo de audio, con altavoz incluido, y el teclado de 4 botones
UB de Nikkai Switches. En la Figura 9 se muestra la arquitectura del PSE.
Figura 9: Diagrama de bloques de la arquitectura hardware del PSE. Tomado de [12].