El Instituto de Electrónica Aplicada – IEA, se complace en presentar la revista “Innovación y Tecnología”, en su segunda edición electrónica que corresponde a la gestión 2017, el objetivo de la revista, es la difusión de los trabajos realizados por estudiantes de la Carrera de Ingeniería Electrónica, Estudiantes de la Maestría en Ingeniería en Redes de Comunicación, docentes y estudiantes investigadores del IEA, que está dirigida a la comunidad universitaria y sociedad en general. En este tercer número se presentan trabajos que se están realizando en el marco de las líneas de investigación del IEA, como ser: radiodifusión digital, aplicaciones de software de código abierto, y robótica.
Ing. Luís Alfonso Jurado Viscarra Director a.i. Instituto de Electrónica Aplicada La opinión vertida en cada uno de los artículos es de responsabilidad de los autores, está prohibida la reproducción total o parcial por cualquier medio existente, sin la autorización del IEA y de sus autores.
ÍNDICE ANÁLISIS DE RECEPCIÓN HF MEDIANTE RADIO DEFINIDA POR
07
SOFTWARE Juan Pablo Patón Mamani ANÁLISIS Y DETERMINACIÓN NUMÉRICA DE DIFERENCIA ENTRE S/N Y C/N EN TELEVISIÓN DIGITAL ISDB-TB
11
Iglesias Rodríguez Erick Adrián DISEÑO E IMPLEMENTACIÓN DE UN ROBOT SEGUIDOR DE LÍNEA VELOCISTA CON CONTROL PID
17
Juan Javier Acarapi Paco, Franz Apaza Quispe EL MANEJO DE DOCKER
23
Ramiro V. Mora Miranda ESTUDIO COMPARATIVO DE RENDIMIENTO DE SERVICIOS WEB:
31
ESB MULE JAVA VS. GO Omar Elias Yana Cerezo ESTUDIO DE FACTIBILIDAD TÉCNICA PARA LA MIGRACIÓN DE LA
41
RADIODIFUSIÓN DIGITAL TERRESTRE EN ONDA MEDIA CON EL ESTÁNDAR DRM 30 PARA BOLIVIA Christian Iván Peña Durán MODULACIONES EN AMPLITUD Y FRECUENCIA EN BASE A GNU RADIO Anthony Pablo Mejillones Perca
49
PROTOTIPO INICIAL DE UNA PRÓTESIS MIOELÉCTRICA DE LA
57
MANO Bryan Alfonso Saravia Quisbert SISTEMA PARA MONITOR DE PARKINSON Edgar Gonzales Laura
63
Análisis de Recepción HF mediante Radio Definida por Software Juan Pablo Patón Mamani Instituto de Electrónica Aplicada, Universidad Mayor de San Andrés La Paz, Bolivia juanpablo.patonmamani@gmail.com Abstract—Se analiza los componentes de un receptor SDR simple mediante diseños y simulación para realizar recepción de señal RF que puede ser utilizado en Media Onda y Onda Corta. El estudio presentado contempla las etapas que deben ser consideradas en su diseño. Partiendo de la base teórica y proyectos similares en recepción se analiza las características particulares de un receptor SDR.
I. INTRODUCCIÓN
Los dispositivos SDR están caracterizados por su flexibilidad. Modificando o reemplazando programas se puede cambiar completamente la funcionalidad. Esto es deseable en la implementación de receptores de señal en un proceso de conversión como es el caso de la radio Analógica tradicional a la Radio Digital. El diseño de dispositivos SDR en recepción permite el análisis de señales en computadoras personales. Los diseños de esta gama son generalmente empleados en radio afición de bandas internacionales. Al emplear la entrada de audio de una computadora para analizar la señal en banda base, se emplea la tarjeta de audio como Procesador Digital de Señales. Existen limitaciones en cuanto al ancho de banda máximo que se puede lograr y la precisión de las muestras de señal. Aun con pérdidas, la señal enviada a la computadora debe permitir la decodificación de señal.
II. FUNDAMENTO TEÓRICO A. Radio Definida por Software Un sistema SDR está compuesto por tres secciones: La Interfaz Frontal ó RF Front-End, la sección de Frecuencia Intermedia (IF) y la sección de Banda Base. Las dos primeras conforman el dispositivo receptor y la tercera parte se encuentra en la computadora realizando el análisis de la señal. La interfaz Frontal RF es la encargada de transmisión y/o recepción de señal. Amplifica y modula la señal en transmisión • para obtener una medida digital de una medida • analógica. La tarjeta de audio de una computadora personal, generalmente tiene las siguientes características: Característica Ancho de Banda
Magnitud 12/24/48
Unidades kHz
o realiza la conversión de radiofrecuencia (RF) a frecuencia intermedia (IF), para el caso de la recepción. Generalmente, en esta etapa comprende de componentes analógicos para el manejo de la señal de radiofrecuencia. La sección IF realiza la conversión entre la señal IF y la Banda Base. En dispositivos SDR, esta etapa es realizada generalmente mediante la conversión de señal digital. Se realiza la conversión Digital-Analógica, en el caso de la transmisión, y Analógica-Digital en recepción. Finalmente, la banda base se encarga del análisis de la señal recibida. Esta señal se procesa mediante software en una computadora personal, y puede comprender de procesos como: modulación, demodulación, análisis espectral, etc. En el procesamiento digital de señal, se tienen los siguientes parámetros: • Frecuencia de Muestreo, se define como el número de veces por segundo que se toma una medida de la señal analógica. • Rango Dinámico, Es la diferencia entre el máximo valor que se puede medir y la mínima magnitud que puede ser detectada por el PDS. • Numero de Niveles, determina la resolución de la muestra y depende del número de bits empleados. A mayor número de bis, mayor precisión de la medida, y por lo tanto, menor error de cuantificación. • Tiempo de conversión, Se refiere al tiempo requerido
Frecuencia Muestreo Nª bits
de
44.1/48/96/192
kHz
16/24
bits
Tabla 1: PDS en una tarjeta de Audio de PC
B. Receptor SDR Un receptor SDR presenta varias etapas electrónicas durante la conversión de señal.
7
Figura 1: Diagrama de Bloques SDR Receptor
La recepción de señal mediante un conversor HF, se emplea para anchos de banda reducidos. El diseño se limita al máximo soportable por la tarjeta de sonido, que se ve interferido por perdidas en la conectorizacion. La sección RF Frontal comprende de la antena, un amplificador de señal, un filtro pasa bajos, un oscilador y un multiplicador. El amplificador toma la señal recibida con la antena, que es un elemento radiante, y elimina aquellas frecuencias que se generan producto de ruido de intermodulación mediante el filtro. Posteriormente, se multiplica la señal recibida con el oscilador local para realizar la conversión a Frecuencia Intermedia. La conversión realizada en la sección Frontal RF puede hacerse a una frecuencia intermedia. Se considera Zero-IF a la frecuencia intermedia con valor cero. Cuando la frecuencia central de la señal no es cero la frecuencia intermedia traspone la señal RF a una frecuencia superior la banda base y menor a la señal RF. En este caso se realiza una nueva conversión en la etapa posterior. Los receptores con esta característica son los llamados receptores heterodinos de doble conversión.
8
Jack puede ser utilizado como entrada a programas SDR previamente instalados que se encargan de realizar procesos de análisis como demodulación, o decodificación según la aplicación. III. DESARROLLO A. Oscilador Local En diseños SDR, generalmente se emplea una interfaz I2C, de comunicación serial con la computadora, conectada a un Sintetizador Digital Directo de Frecuencias (DDFS) como el AD9835. Una actualización es posible mediante el AD9851, un DDFS de estas características que puede ser controlado mediante un micro-controlador. Por facilidad, una placa de desarrollo Arduino es una alternativa para control del DDFS. La facilidad de comunicación mediante comandos AT entre placas Arduino y la computadora puede aprovecharse para establecer una interfaz de control del módulo AD9851. Las frecuencias de sintonización con el micro-controlador, se establecen mediante una formula simple y una palabra de 8 bits enviada al AD9851.
Las frecuencias intermedias más comunes son las de 10 MHz y 455 kHz. En este caso se emplea la segunda opción para un receptor con un ancho de ban da previsto menor a 20 kHz.
El Oscilador Local controlado genera una señal senoidal de frecuencia configurable. Esta señal es generada mediante un conversor Digital-Analógico, por esta razón, se emplea un filtro anti-alias a su salida.
En la sección IF, en función a las características del receptor, se realiza una segunda conversión. Después de la conversión a frecuencia intermedia realizada en la sección anterior, la señal puede tener frecuencia central cero o requerir una segunda conversión. La señal finalmente está en banda base y se prepara para ser digitalizada.
A la frecuencia de Sintonización a configurar con el Oscilador local, se le debe agregar 467 kHz. Este valor es generalmente empleado en receptores Heterodinos de doble conversión. Se establece 455 kHz como frecuencia central de la señal IF y 12 kHz de ancho de banda del canal.
En el desarrollo de receptores SDR simples, la digitalización de señal digital se realiza directamente en la computadora. La entrada de audio de un conector convencional
La primera conversión sitúa la señal en frecuencia intermedia. Posteriormente, se cambia a la frecuencia de banda base. La segunda conversión emplea un Oscilador a 455kHz, donde quedan 12 kHz de ancho de banda de la señal.
B. Filtro Anti-alias. Se debe analizar las características de un filtro pasa bajo como anti-alias para el oscilador local. El empleo de un filtro pasivo frente a un filtro activo en este proyecto es necesario para trabajar sin la necesidad de una fuente de alimentación para el funcionamiento del filtro. Es deseable para trabajos con baja potencia. Delimitando el ancho de banda del filtro, este debe tener un límite de 30 MHz. Las frecuencias de onda corta generalmente son menores al límite; tanto en media onda, como en las bandas internacionales. El diseño de un filtro pasivo de estas características se puede realizar mediante técnicas como Butterworth o Chebycheff. Los datos del diseño se muestran a continuación:
Figura 3: Respuesta en Frecuencia del Filtro Anti-Alias
C. Mezclador de Frecuencias La señal RF junto con la señal senoidal se unen mediante un multiplicador mezclador de frecuencias. Se genera una señal de frecuencia intermedia IF en la primera conversión fijada a 467 kHz, y en la segunda conversión, a banda base con un ancho de 12 kHz. Para esta etapa del diseño, existen varios modelos de mezcladores. Según el fabricante y las características del modelo. Para el proyecto se analiza el principio de funcionamiento del mezclador doblemente balanceado mediante célula de Gilbert.
Figura 2: Filtro Basa Bajo Anti-alias
Característica Frecuencia de Corte
Valor 30 MHz
Atenuación
6 dB
Rizado
1 dB
Resistencia OL
50 ohm
Tabla 2: Valores de diseño Filtro pasa bajo
La célula de Gilbert es una aplicación de los amplificadores diferenciales transistorizados aplicados a salidas controladas por corriente. Se trata de Amplificadores Diferenciales Interconectados en los cuales dos entradas regulan la señal final. La simulación del circuito es similar a la recibida mediante el NE602/6012. IV. CONCLUSIONES Con el análisis realizado se ha logrado caracterizar los componentes de un receptor y se han planteado modelos de simulación para las etapas de un receptor SDR simple.
En la tabla se establece un valor de 6 dB de atenuación del filtro como valor base para la entrada de amplitud. Existen filtros resonadores con este valor de amplificación en dispositivos de radio a 455 kHz como frecuencia IF.
La construcción del sistema SDR requiere módulos de un receptor de señal que pueden utilizarse para el desarrollo de receptores SDR propios.
Se fija una resistencia del generador aproximada de 50 ohms con una amplitud máxima de 1.5 V. Se espera una salida aproximada de 330 mV debido a la atenuación en señales que superan la frecuencia de corte.
Parte de la infraestructura es montada sobre proyectos de radioaficionados. Un desarrollo más eficiente de estos sistemas daría como resultado módulos de análisis de señal con mayor precisión. La simulación de componentes electrónicos para desarrollo SDR tiene limitaciones en cuanto a precisión. Uno de los nuevos retos de recepción de señal deberá estar centrado en la modulación de señales I/Q. tomando muestras de la señal con un desfase de 90 grados. Característica deseable en sistemas OFDM dentro del análisis SDR.
9
Bibliografía By Gerald Youngblood, A. (2002). A Software-Defined Radio for The Masses,. QEX. Iván Pinar Domínguez, J. J. (2011). Laboratorio de Comunicaciones Digitales Radio Definida por Software. Sevilla. Sigfredo Pagel, F. I. (2005). Diseño de una Unidad Frontal RF para Recepcion Digital DRM. Revista Española de electronica, 50-56.
Figura 4: Célula de Gilbert
Figura 5: Salida de la Célula de Gilbert a una Modulación
10
AnĂĄlisis y determinaciĂłn numĂŠrica de diferencia entre S/N y C/N en TelevisiĂłn Digital ISDB-Tb Iglesias RodrĂguez, Erick AdriĂĄn
IngenierĂa ElectrĂłnica –Universidad Mayor de San AndrĂŠs La Paz- Bolivia eaiglesias@umsa.bo
Resumen— En el presente artĂculo se analizara la diferencia existente entre los valores de relaciĂłn seĂąal a ruido (S/N o SNR) y relaciĂłn portadora a ruido (C/N o CNR) presente en ISDB-Tb (Integrated Services Digital Broadcasting-Terrestrial Brazil). Para esto Ăşltimo, se utilizara los valores de amplitud de seĂąal (I,Q) definidos para las portadoras de datos y portadoras pilotos 1
(TMCC, AC, SP, y CP) asĂ como la cantidad de ellas en el ancho de banda Ăştil en ISDB-Tb, segĂşn especifica [1]. TambiĂŠn, se citara el anĂĄlisis y determinaciĂłn numĂŠrica de diferencia entre S/N y C/N realizado por [3] para el sistema DVB-T (Digital Video Broadcasting Terrestrial).
A. Esquemas de ModulaciĂłn en ISDB-Tb En ISDB-Tb se utilizan los esquemas de modulaciĂłn QPSK, 16QAM, 64QAM. Estos esquemas de modulaciĂłn tambiĂŠn son llamados esquemas de modulaciĂłn I (In Phase) y Q (Quadrature) [3] o esquemas de modulaciĂłn vectorial [6]. Estos esquemas de modulaciĂłn permiten que una secuencia de bits sea expresada o ‘mapeada’ a travĂŠs de sĂmbolos (I,Q). [3] muestra un ejemplo de modulaciĂłn QPSK (Quadrature Phase Shift Keying), el cual es ilustrado en la Fig. I.1.
�ndice de TÊrminos—SNR. CNR. Portadoras. ISDB-Tb
I. INTRODUCCIĂ“N Para empezar, [6] menciona que: “La relaciĂłn C/N es un parĂĄmetro de extrema importancia en cualquier sistema de telecomunicaciones y depende, entre otros factores, del esquema de modulaciĂłn utilizado (QPSK, 16 QAM, 64 QAM). Esta relaciĂłn se mide en radiofrecuencia y no debe ser confundida con la relaciĂłn seĂąal a ruido (S/N) utilizada para seĂąales de audio y video en banda baseâ€?. Por otra parte, [6] y [3] muestran los valores lĂmites para C/N en funciĂłn del tipo de modulaciĂłn y tasa de codificaciĂłn. Por otra parte, es conocido que algunos instrumentos de mediciĂłn de seĂąal ISDB-Tb (como el expuesto en [5]) entregan el valor medido de S/N en lugar de C/N. Es por cuanto, en el presente artĂculo se propondrĂĄ una relaciĂłn numĂŠrica entre C/N y S/N en ISDB-Tb; un cĂĄlculo de los valores lĂmites de S/N tomando en cuenta los valores umbrales definidos para C/N podrĂa ser realizado.
Fig. I.1 Mapeo con modulaciĂłn QPSK
En la Fig. I.1 se aprecia el mapeo de una secuencia de bits. En la secuencia se selecciona dos bits de manera que el par de bits tenga un equivalente igual al sĂmbolo posicionado por el vector. Valga mencionar, que para QPSK cuatro sĂmbolos I y Q son definidos. AdemĂĄs, en la Fig. I.1 se muestra una portadora Io(t) igual a
cos(Zct ) . Entonces, el sĂmbolo (I,Q) es igual a: iq mod(t ) i cos(Zct ) q sin(Zct ) [v] (1-1)
1
una explicaciĂłn de las portadoras piloto es explicado en la Tabla II.1 del presente documento
La ecuaciĂłn (1-1) es ilustrada grĂĄficamente en la Fig. I.2.
11
B. NormalizaciĂłn de niveles de modulaciĂłn [1] indica que cuando se asignan puntos en la constelaciĂłn, como se mostrĂł en las Fig. I.3, el nivel de la seĂąal de transmisiĂłn debe ser obligatoriamente normalizado, multiplicando cada uno de esos puntos por el correspondiente factor de normalizaciĂłn mostrado en la Tabla I.1. Como resultado, la potencia media del sĂmbolo se torna igual a uno, independientemente del esquema de modulaciĂłn usado. Tabla I.1 NormalizaciĂłn de esquemas de modulaciĂłn Esquema de modulaciĂłn de la Factor de normalizaciĂłn portadora QPSK/ DQPSK Z/ 2 16-QAM Fig. I.2 SĂmbolo QPSK
64-QAM
Para el caso de 16 QAM (Quadrature Amplitude Modulation) cuatro bits son combinados en el mapeador; entonces, una portadora (sĂmbolo) puede transportar cuatro bits, y hay diecisĂŠis posibles sĂmbolos en su constelaciĂłn. Es de esa manera que [3] muestra lo ilustrado en la Fig. I.3.
Fig. I.3 Diagramas de ConstelaciĂłn QPSK, 16QAM, y 64QAM
En la Fig. I.3 se puede apreciar la constelaciĂłn 64QAM con sesenta y cuatro sĂmbolos donde cada uno puede transportar ocho bits. AdemĂĄs, [3] indica que las constelaciones mostradas corresponden a diagramas de constelaciĂłn reales, i.e. deteriorado por ruido. Esto Ăşltimo, puede ser expresado por un valor de SNR asociado al deterioro por ruido de la constelaciĂłn. Para ir terminando, la ecuaciĂłn (1-1) puede ser tambien expresado a travĂŠs de la ecuaciĂłn (1-2).
iq mod(t ) Z
Z ˜ cos(Zct M )[v]
i 2 q 2
M
tan 1 (q / i)
(1-2)
Esta Ăşltima ecuaciĂłn nos ayudara a ver el proceso de normalizaciĂłn de amplitud de una seĂąal QPSK o QAM.
12
Z/
10
Z/
42
En la Tabla I.1 el valor de ‘Z’ es correspondiente al visto en la ecuaciĂłn (1-2). II. PORTADORAS DE DATOS Y PILOTOS En el sistema ISDB-Tb, el ancho de banda de canal de 6MHz puede ser subdividido en 13 sub-bandas o segmentos, en los cuales diferentes parĂĄmetros de modulaciĂłn pueden ser seleccionados. Valga mencionar que con el ancho de banda igual a 6MHz, la banda utilizada es igual 5,57MHz, i.e. hay una banda de guarda de 200 KHz (aproximadamente) para los canales adyacentes superior e inferior. AdemĂĄs, en ISDB-Tb se utilizan tres modos. Estos modos indican la cantidad de portadoras contenidas en un segmento y/o en el canal. [3] muestra el significado de lo mencionado: a) Modo I, 108 portadoras por sub-banda 3.968 kHz espaciamiento por sub-portadora 1404 portadoras en el canal b) Modo II, 216 portadoras por sub-banda 1.9841 kHz espaciamiento por sub-portadora 2808 portadoras en el canal c) Modo III, 432 portadoras por sub-banda 0.99206 kHz espaciamiento por sub-portadora 5616 portadoras en el canal
Los modos I, II, y III indican el número de portadoras activas en el canal; 1404, 2808, y 5616, donde el número de portadoras por segmento puede ser calculado dividiendo entre trece la cantidad de portadoras por canal. En estas portadoras activas se encuentran las portadoras utilizadas para datos así como portadoras pilotos que son indicadas por [1] y [6], las cuales son: a) Pilotos Dispersos (Scattered Pilots) b) Pilotos Continuos (Continual Pilots) c) Pilotos TMCC (Transmission and Multiplexing Configuration Control) d) Canal Auxiliar (AC) El número de portadoras de datos y pilotos es mostrado en Tabla II.1 Tabla II.1 Distribución de portadoras por segmento Distribución de portadoras por Modo 1 Modo 2 Modo 3 segmento Total
108
216
432
Portadora de datos
96
192
384
SP (Pilotos dispersos)
9
18
36
TMCC (Control de configuración y
1
2
4
AC1 (Canal Auxiliar)
2
4
8
CP (Piloto Continuo)*
1
1
1
multiplexación de transmisión)
SP y CP son usados por el receptor para sincronización y recepción. TMCC es información de control y configuración para el receptor. AC se usa para transmitir información adicional *El piloto CP es una portadora que se adiciona al final de la banda útil y no pertenece a ninguno de los 13 segmentos.
III. RELACIÓN NUMÉRICA ENTRE C/N Y S/N PARA DVB-T Para empezar, [3] indica que cuando convertimos la relación portadora a ruido (C/N) a la relación señal a ruido (S/N), la energía en las portadoras pilotos debe ser considerada, de manera que se sustraiga de la energía total y dé como resultado la energía en las portadora de datos, ya que S/N toma en cuenta únicamente la señal asociada a las portadoras de datos. Además, la página 389 de [3], menciona que los pilotos continuos (continual) CP y dispersos (scattered) SP son siempre excitados con 2.5 dB respecto al nivel medio de la señal de las portadora de datos. En otras palabras, el nivel de voltaje de las portadoras piloto es más alto por 4/3 de manera que comparado con el valor medio de la señal de las portadoras de datos la potencia de las portadoras continuas y dispersas son más altas por 16/9. 20 log(4/3) = 2.5 dB; radio de voltaje de portadoras CP y SP respecto al valor promedio de la portadora de datos DVB-T además utiliza una portadora piloto llamada TPS, la cual no es sobre excitada respecto al valor medio de la señal de las portadoras de datos. Además, los instrumentos de medición están usualmente calibrados para C/N y no para S/N. Sin embargo, S/N es relevante para el cálculo del bit error ratio (BER) causado por interferencia de puro ruido en el canal; entonces, el valor de C/N debe ser convertido en S/N. Es así que [3] indica la fórmula para la energía en las portadoras de datos (payload carrier) sin portadoras piloto, lo cual es expresado en la ecuación (3-1): payload_to_signal =
Por otra parte, [1] indica que la modulación para las portadoras pilotos es BPSK con los puntos (+ 4/3, 0) y/o (- 4/3, 0) ambos sobre el eje real Q del diagrama de constelación. Por ejemplo para la portadora CP [1] muestra lo ilustrado en la Tabla II.2. Modo Modo 1 Modo 2 Modo 3
Tabla II.2 Señal de modulación para CP
Amplitud de la señal de modulación (I,Q) (-4/3,0) (+4/3,0) (+4/3,0)
payload payload + (scattered+ continual) (4/3)2 + TPS 1)
(3-1)
Donde:
payload es el número de portadoras de datos Scattered es el número de portadoras SP Continual es el número de portadoras CP TPS es el número de portadoras TPS
Valga recalcar que, según [3] para determinar el BER en DVB-T, solamente la potencia en las portadoras de datos puede ser usada como potencia de señal. En DVB-T, la diferencia entre la potencia general de las portadoras (para todas las portadoras) y la potencia en las
13
portadoras de datos es determinada por la expresiĂłn (3-1). Entonces, para el modo 2K y 8K para DVB-T se tiene: payload_to_signal =
payload payload + (scattered+ continual) ˜ (4/3)2 + TPS)
§ ¡ 1512 ¸¸ payload_to_signal 2k = 10log¨¨ 2 Š 1512 + (131+ 45) ˜ (4/3) 17 ˜ 1) š
payload_to_signal 2k = 0.857 dB
(3-2)
§ ¡ 6048 ¸¸ payload_to_signal 8k = 10log¨¨ 2 6048 + (524 + 177) ˜ (4/3) 68 ˜ 1) Š š
payload_to_signal 8k = -0.854 dB
(3-3)
Sin embargo, el ruido en el ancho de banda de las portadoras de datos es reducido respecto al valor global de las portadoras Es asĂ que, la reducciĂłn del ruido en el ancho de banda de las portadoras de datos es mostrado en la expresiĂłn (3-4) ¡ § payload ¸¸ 10 ˜ log¨¨ otal de portadoras t š Š
(3-4)
(3-5)
(3-6)
(3-7)
Modo 8k: C S N N
14
0.520dB ( 0.854dB) 0.33dB
payload payload + (scattered+ continual AC1 TMCC ) ˜ (4/3)2
(4-1)
Reemplazando valores de la Tabla II.1 en la ecuaciĂłn (4-1)
tenemos:
payload_to_signal modo1 = § 13 ˜ 96 10log¨¨ 13 96 + (13 9 1 ˜ ˜ 13 ˜ 2 13 ˜ 1) ˜ (4/3)2 Š
¡ ¸¸ š
(4-2)
payload_to_signal modo1 = -0.8766dB
¡ ¸¸ š
(4-3)
payload_to_signal modo2 = -0.8740dB
§ 13 ˜ 384 10log¨¨ 2 Š 13 ˜ 384 + (13 ˜ 36 1 13 ˜ 8 13 ˜ 4) ˜ (4/3)
¡ ¸¸ š
payload_to_signal modo 3 = -0.8728dB
Modo 2k: 0.522dB ( 0.857dB) 0.34dB
payload_to_signal =
payload_to_signal modo 3 =
AsĂ, la diferencia entre C/N y S/N en DVB-T esta dado por la diferencia entre (3-5) y (3-2) asĂ como por (3-6) y (3-3):
C S N N
Tomando en cuenta el anĂĄlisis realizado para DVB-T por [3], la amplitud de potencia media de sĂmbolo (QPSK, 16 QAM, 64QAM) igual a la unidad (asociado a la potencia de las portadora de datos), y la amplitud de seĂąal de modulaciĂłn BPSK igual a +-4/3 (Tabla II.2) para las portadoras pilotos de la Tabla II.1, se propone la ecuaciĂłn (4-1) para el cĂĄlculo de energĂa en las portadoras de datos (payload carrier) sin portadoras piloto (para ISDB-Tb).
§ 13 ˜ 192 10log¨¨ 13 192 + (13 18 1 13 ˜ 4 13 ˜ 2) ˜ (4/3)2 ˜ ˜ Š
Para el modo 8k: § 6048 ¡ 10 ˜ log¨ ¸ 0.520dB Š 6917 š
RELACIÓN NUMÉRICA ENTRE C/N Y S/N PARA ISDB-TB
payload_to_signal modo 2 =
Para el modo 2k: § 1512 ¡ 10 ˜ log¨ ¸ 0.522dB Š 1705 š
IV.
(3-8)
(4-4)
Por otra parte, la reducciĂłn de ruido en el ancho de banda de las portadoras de datos para los modos 1, 2 y 3 en ISDB-Tb es dado por la ecuaciĂłn (4-5) § 13 ˜ 384 ¡ § 13 ˜ 192 ¡ § 13 ˜ 96 ¡ 10 ˜ log¨ ¸ ¸ 10 ˜ log¨ ¸ 10 ˜ log¨ Š 13 ˜ 432 š Š 13 ˜ 216 š Š 13 ˜ 108 š
0.5115dB
(4-5)
Entonces, tomando en cuenta la diferencia de (4-5) con las ecuaciones (4-2), (4-3) asĂ como (4-4) tenemos los
valores numéricos de C/N menos S/N para los modos 1, 2 y 3 para ISDB-Tb. La Tabla IV.1 ilustra los resultados. Tabla IV.1 Valores numéricos de diferencia entre C/N y S/N
Modo
C/N[dB]-S/N[dB]
C/N-S/N [dB]
1
-0.5115-(-0.8766)
0.3651
2
-0.5115-(-0.8740)
0.3625
3
-0.5115-(-0.8728)
0.3613
V. CONCLUSIONES Los resultados mostrados en la Tabla IV.1 permiten obtener valores de S/N de aquellos instrumentos calibrados para medir C/N. Por otra parte, los resultados de la Tabla IV.1 puede ser utilizados para definir valores umbrales de S/N tomando en cuenta los valores límites de C/N definidos para ISDB-Tb. Valga mencionar que, para determinar el BER en un sistema de Televisión Digital tal como ISDB-Tb el valor de S/N es utilizado.
RECONOCIMIENTO Este trabajo de investigación fue realizado en ambientes proporcionados por la Lic. Olga Rodríguez quien permitió el uso de los recursos necesarios para la redacción del documento.
VI. REFERENCIAS [1] ABNT NBR 15601 , «Televisión digital terrestre — Sistema de transmisión,» 2007. [2] ABNT NBR 15604, Television Digital Terrestre Receptores, Rio de Janeiro, 2007. [3] W. Fisher, Digital Video and Audio Broadcasting Technology, Berlin: Springer-Verlag, 2010. [4] ITU-R BT.2389-0, «Guidelines on mesurements for digital terrestrial television broadcasting system,» Geneva, 2016. [5] Larocca y e. al, «AN OPEN AND FREE ISDB-T FULL_SEG RECEIVER IMPLEMENTED IN GNU RADIO,» WINNCOMM, p. 10, 2016. [6] N. Pisciotta, C. Liendo y L. Roberto, Transmision de Television Digital Terrestre en la norma ISDB-Tb, Córdoba y Mendoza: CENGAGE Learning, 2013.
15
16
DISEÑO E IMPLEMENTACIÓN DE UN ROBOT SEGUIDOR DE LÍNEA VELOCISTA CON CONTROL PID Juan Javier Acarapi Paco, Franz Apaza Quispe Universidad Mayor de San Andrés La Paz, Bolivia junajapipa@gmail.com franz.apaza.q@gmail.com
Abstract−− En el presente artículo se pretende publicar la estrategia para el diseño y construcción de un robot seguidor de línea velocista. Se muestra una descripción física de los componentes del robot, como también del desarrollo de algoritmos de control y métodos de estimación de posición. De esta manera se pretende afianzar las bases para la construcción y desarrollo del mismo, permitiendo que los estudiantes tengan un mayor interés en la elaboración de prototipos.
I.
INTRODUCCION
Los robots seguidores de línea son robots muy sencillos, que cumplen una única misión, seguir una línea marcada que normalmente es de color negro sobre una superficie blanca. Son considerados los "Hola mundo" de la robótica. En este documento se presenta la metodología seguida para el diseño y construcción de un robot móvil seguidor de línea negra, utilizando una placa de ARDUINO NANO. Los alcances de este proyecto se dividen en dos categorías: software y hardware. Software: se refiere a la realización de los algoritmos de control y métodos de estimación para su posterior programación. Para este fin se pretende aplicar leyes de control clásico, en este caso un controlador PID, el cual tiene el propósito de mejorar la respuesta de los sensores y motores. Para la parte de métodos de estimación se aplicara el promedio ponderado el cual ayudara a la toma de decisiones en él recorrido de la pista. Hardware: principalmente conformada por el diseño de la estructura del robot, desde el PBC hasta el ensamblaje de los componentes (motores, drives para motores, sensores, microcontrolador, ruedas, etc.) necesarios para la implementación y funcionamiento del robot.
El objetivo es que el robot siga una línea de forma óptima y con una velocidad adecuada para una competición de robótica. Para lograr tal objetivo se desarrollará algoritmos de control y métodos de estimación para controlar los sensores (siga la referencia) y los motores (tiempo de respuesta). II.
DISEÑO Y CONSTRUCCIÓN
A. Diseño hardware El hardware es el conjunto de dispositivos que hacen posible el funcionamiento de un robot, este abarca todos los componentes mecánicos y electrónicos. Para el prototipo de este trabajo se necesita básicamente de un chasis, motores y electrónica; en esta última, todos los robots constan de los mismos componentes: sistema sensorial, sistema de control, alimentación y actuadores como se puede apreciar en la Fig. 1:
Fig.1 Arquitectura general del robot
1) Chasis: El diseño de la infraestructura (chasis) del robot es muy importante al momento de realizar la construcción, pues se debe tener en cuenta: forma, tamaño, peso, distribución de elementos, distancia entre las ruedas, distancia entre el eje de las ruedas y sensores, la altura del chasis respecto al suelo y materiales de fabricación, ya que todos influyen en el funcionamiento del robot. A la hora de decidir cómo va a ser la forma del chasis se plantean dos planteamientos importantes. Una es la distribución mecánica en él chasis y otra es la elección de los componentes. Para dimensionar el chasis del robot se recurrió a análisis cinemático. Se tomó en cuenta el modelo físico y el
17
comportamiento cinemĂĄtico del robot. Las dimensiones a considerar en el diseĂąo del robot son la distancia entre las ruedas, entre el eje de las ruedas y los sensores con respecto entre las ruedas [1]. đ??Žđ??Žđ??Žđ??Ž =
đ?‘˝đ?‘˝đ?‘˝đ?‘˝đ?‘šđ?‘šđ?‘šđ?‘š − đ?‘˝đ?‘˝đ?‘˝đ?‘˝đ?‘łđ?‘łđ?‘łđ?‘ł đ?‘łđ?‘łđ?‘łđ?‘ł
‌‌‌‌‌‌‌‌1
đ?œ”đ?œ”đ?œ”đ?œ” = đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Žđ?‘Žđ?‘Žđ?‘Ž đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x; đ?‘‰đ?‘‰đ?‘‰đ?‘‰đ??żđ??żđ??żđ??ż = đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Ž đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łâ„Žđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘‰đ?‘‰đ?‘‰đ?‘‰đ?‘…đ?‘…đ?‘…đ?‘… = đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Ž đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘–đ?‘–đ?‘–đ?‘–đ?‘–đ?‘–đ?‘–đ?‘–đ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Ž đ??żđ??żđ??żđ??ż = đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘‘đ?‘‘đ?‘‘đ?‘‘đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x; đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Ž
Otro aspecto importante con respecto de entre las ruedas, es el radio mĂnimo de curvatura que el robot puede tomar sin invertir el sentido de giro de una rueda: đ?‘łđ?‘łđ?‘łđ?‘ł
�������� +��������
đ?‘šđ?‘šđ?‘šđ?‘š = ∗ ( đ?&#x;?đ?&#x;?đ?&#x;?đ?&#x;?
đ?‘˝đ?‘˝đ?‘˝đ?‘˝đ?‘šđ?‘šđ?‘šđ?‘š −đ?‘˝đ?‘˝đ?‘˝đ?‘˝đ?‘łđ?‘łđ?‘łđ?‘ł
)‌‌‌‌‌2
đ?‘…đ?‘…đ?‘…đ?‘… = đ?‘…đ?‘…đ?‘…đ?‘…đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł
El siguiente punto a analizar en el diseĂąo es entre la distancia entre los sensores de lĂnea y el eje de las ruedas, generalmente se une la placa de control, usando un brazo, se realiza de esa forma ya que se necesita que tenga una cierta distancia entre los sensores y la tracciĂłn para que el robot pueda ver con cierta anticipaciĂłn la curva.
Fig.3 sensor QTR-8A
3) Motores y ruedas: Los motores son una parte fundamental del robot, ya que de estos depende la velocidad con la que puede desplazarse, aquĂ se debe considerar el peso del robot y el radio de la rueda para su correcta selecciĂłn, el radio de las ruedas influye significativamente en el desempeĂąo del robot, ya que la velocidad mĂĄxima y el torque necesario para mover al robot estĂĄn condicionados por esta variable. Para calcular el torque del motor requerido segĂşn [3] se necesita la masa total del robot, el radio de la rueda y la aceleraciĂłn que se desee: đ?‘‡đ?‘‡đ?‘‡đ?‘‡ = đ?‘€đ?‘€đ?‘€đ?‘€ ∗ (đ?‘Łđ?‘Łđ?‘Łđ?‘Ł + đ?‘Žđ?‘Žđ?‘Žđ?‘Ž ∗ sin(đ?œƒđ?œƒđ?œƒđ?œƒ)) ∗ đ?‘Žđ?‘Žđ?‘Žđ?‘Žâ€Śâ€Śâ€Śâ€Śâ€Ś.3
Donde: đ?‘‡đ?‘‡đ?‘‡đ?‘‡ = đ?‘‡đ?‘‡đ?‘‡đ?‘‡đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘šđ?‘šđ?‘šđ?‘šđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘€đ?‘€đ?‘€đ?‘€ = đ?‘€đ?‘€đ?‘€đ?‘€đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x; đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘&#x;đ?‘&#x;đ?‘&#x;đ?‘&#x; đ?‘Łđ?‘Łđ?‘Łđ?‘Ł = đ??´đ??´đ??´đ??´đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘ŁĂłđ?‘Žđ?‘Žđ?‘Žđ?‘Ž đ?œƒđ?œƒđ?œƒđ?œƒ = Ă đ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Ž đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘?đ?‘?đ?‘?đ?‘?đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Žđ?‘Žđ?‘Žđ?‘Ž = đ??şđ??şđ??şđ??şđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Ž đ?‘Žđ?‘Žđ?‘Žđ?‘Ž = đ?‘…đ?‘…đ?‘…đ?‘…đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Łđ?‘Ł đ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Žđ?‘Ž
En el mercado existen mĂşltiples motores DC (micro motores), que ofrecen pares y velocidades que cumples con nuestras necesidades [4]. 4) Driver motor: Es necesario una interfaz entre el microcontrolador y el motor para poder controlarlo, despuĂŠs de revisar algunas opciones existentes en el mercado, se optĂł por el controlador de potencia TB6612FNG [5], este trae dos puentes H, y cuenta con salidas PWM lo cual utilizaremos para regular la velocidad de giro de los motores.
Fig.2 estructura fĂsica del chasis
Como se aprecia en la Fig. 2, toda la electrĂłnica necesaria para el funcionamiento del robot, excepto los sensores, se ubican el al chasis. Los sensores para la detecciĂłn de la lĂnea, se encuentran ubicados a cierta distancia del chasis soportado por un brazo. 2) Sensores: Para la detecciĂłn de lĂnea utilizaremos la placa de sensores QTR-8A [2], El mĂłdulo trae 8 pares emisor receptor espaciados entre si 9.525 mm; la salida de cada sensor (fototransistor) estĂĄ conectado a una resistencia de pull-up para obtener un voltaje analĂłgico que estĂĄ entre 0 y 5 V.
18
Fig.4 driver TB6612FNG pololu
5) BaterĂas: La fuente de energĂa para alimentar los circuitos electrĂłnicos, asĂ como los motores del robot, serĂĄn dos baterĂas LIPO [6] de corriente continua de 3,5 V. Las baterĂas
Lipo tienen 3 cosas importantes que hacen a estas baterías la elección perfecta para los vuelos de radiocontrol: -
Las baterías LiPo son ligeras y se pueden hacer de casi cualquier forma y tamaño. Las baterías Lipo tienen gran capacidad lo que significa que tienen un montón de energía en un tamaño reducido. Las baterías LiPo tiene una tasa de descarga alta para alimentar los sistemas eléctricos más exigentes.
6) Regulador de voltaje: Un regulador de tensión o regulador de voltaje es un dispositivo electrónico diseñado para mantener un nivel de tensión constante. Para nuestro caso el uso de este dispositivo nos permitirá tener un voltaje de 5 V, ya que las baterías nos proporcionan una tensión de 7 V (colocamos en serie las dos baterías de 3,5 V), esto permitirá alimentar los componentes que soportan hasta 5 V como tensión de entrada, en lo que concierne al presente documento utilizaremos un regulador variable, el famoso LM317. 7) Arduino nano: Utilizamos una placa de ARDUINO NANO [7], es una placa creada para el aprendizaje y la introducción a la programación e implementación en el mundo físico. Es una plataforma de desarrollo de computación física de código abierto, basada en una placa con un sencillo micro controlador y un entorno de desarrollo para crear software para la placa.
b.
c. d.
Entorno de programación: es simple y directa el entorno de programación de Arduino es fácil de usar para principiantes y lo suficientemente flexible para los usuarios avanzados Hardware ampliable: los diseñadores de circuitos con experiencia pueden hacer su propia versión del módulo, ampliándolo u optimizando. Tamaño reducido ideal para proyectos de pequeño tamaño.
8) Diseño del PBC: Un PCB es una tarjeta de circuito impreso donde sobre una superficie no conductora se disponen de pistas o caminos de material conductor. El programa para la realización de PBC fue EAGLE [8]. Para realizar el diseño de la placa se tomó consideraciones, como: a)
La ubicación de cada componente del robot, teniendo en cuenta su peso, su dimensión y la función que cumple en el robot de tal modo que la placa diseñada estuviera equilibrada en relación al peso y simetría.
b) El tamaño de la placa, tomando las necesidades para el buen funcionamiento cinemático mencionados en el inciso 2).
Fig.6 PCB robot seguidor de línea Fig.5 Placa Arduino nano
B. Diseño del software Arduino, además de simplificar el proceso de trabajar con micro-controladores. Ofrece algunas ventajas respecto a otros sistemas: a.
Multiplataforma: El software utilizado en el Arduino es multiplataforma, funciona en sistemas operativos como Windows, Macintosh y Linux.
Una vez descrita la parte hardware, se describirá la parte de software, en la cual se detalla el tipo de comportamiento que tendrá el robot, esta se dividirá en bloques, cada bloque se encargará de una tarea en específico. Cada uno de los bloques estarán relacionado a través del programa principal, y dependiendo del caso, se realiza la tarea que sea necesaria, además que se aplicarán diferentes algoritmos para el funcionamiento de los mismos.
19
2) Bloque motor: En este bloque, se encargarĂĄ de controlar tanto la velocidad por modulaciĂłn de ancho de pulso (PWM), la cual es generada por uno de los timers del microcontrolador, ademĂĄs del control del motor, si se detiene o avanza hacia adelante.
Fig.7 esquema de los programas
1) Bloque sensores: Para esta parte se usĂł un arreglo de 8 sensores, ĂŠl QTR-8A, para realizar la lectura de los datos del sensor QTR-8A, se utilizarĂĄ la librerĂa de dicho modulo [9], dicha librerĂa trabaja con el mĂŠtodo de promedio ponderado, el cual estima la posiciĂłn en la que se encuentra el robot sobre la lĂnea negra y en base a los resultados leĂdos, poder tomar las decisiones adecuadas. Una de las grandes ventajas que tiene la librerĂa, es que proporciona una funciĂłn de calibraciĂłn, este adquiere una cantidad determinada de datos y realiza un promedio de valores, los cuales son usados posteriormente, puesto que los valores leĂdos por el sensor son demasiado susceptibles a la cantidad de luz del ambiente.
Fig.9 Diagrama de flujo control de motores
3) Bloque de control: En este bloque se realizarĂĄ la inserciĂłn del controlador al robot seguidor de lĂnea, en el cual se implementarĂĄ un controlador Proporcional Integral Derivativo (PID) de lazo cerrado, cuyo objetivo es mejorar la respuesta del robot, de la posiciĂłn respecto de la lĂnea en alta velocidad, de manera ideal, el error de posiciĂłn debe ser cero (que se encuentre en el centro de la lĂnea negra). Se implementarĂĄ la siguiente ecuaciĂłn del controlador PID a implementar: đ?’•đ?’•đ?’•đ?’•
đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘(đ?’•đ?’•đ?’•đ?’•) ) đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘ = đ?’Œđ?’Œđ?’Œđ?’Œđ?’‘đ?’‘đ?’‘đ?’‘ ∗ đ?’†đ?’†đ?’†đ?’†(đ?’•đ?’•đ?’•đ?’•) + đ?’Œđ?’Œđ?’Œđ?’Œđ?’‘đ?’‘đ?’‘đ?’‘ ∗ ďż˝ đ?’†đ?’†đ?’†đ?’†(đ?’•đ?’•đ?’•đ?’•) + đ?’Œđ?’Œđ?’Œđ?’Œđ?’‘đ?’‘đ?’‘đ?’‘ ∗ ( đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘ đ?&#x;Žđ?&#x;Žđ?&#x;Žđ?&#x;Ž
Para implementarlo en un programa, la anterior ecuaciĂłn se la discretizarĂĄ, por ello resulta de la siguiente manera: đ?’?đ?’?đ?’?đ?’?
đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘(đ?’?đ?’?đ?’?đ?’?) = đ?’Œđ?’Œđ?’Œđ?’Œđ?’‘đ?’‘đ?’‘đ?’‘ ∗ đ?’†đ?’†đ?’†đ?’†(đ?’?đ?’?đ?’?đ?’?) + đ?’Œđ?’Œđ?’Œđ?’Œđ?’‘đ?’‘đ?’‘đ?’‘ ∗ ďż˝ đ?’†đ?’†đ?’†đ?’†(đ?’?đ?’?đ?’?đ?’?) + đ?’Œđ?’Œđ?’Œđ?’Œđ?’‘đ?’‘đ?’‘đ?’‘ ∗ (đ?’†đ?’†đ?’†đ?’†(đ?’?đ?’?đ?’?đ?’?) − (đ?’?đ?’?đ?’?đ?’? − đ?&#x;?đ?&#x;?đ?&#x;?đ?&#x;?)) đ?&#x;Žđ?&#x;Žđ?&#x;Žđ?&#x;Ž
Existe la certeza que el sistema sea inestable, con respecto al controlador Integral, puesto que es la suma de todos los errores generados, si la cantidad de datos es demasiado grande, causara fallas de funcionamiento, volviendo inestable al sistema, por lo cual se acotara, solo se tomara los Ăşltimos 10 errores: Fig.8 Diagrama de flujo de cĂĄlculo de posiciĂłn de error
20
đ?’?đ?’?đ?’?đ?’?
đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘(đ?’?đ?’?đ?’?đ?’?) = đ?’Œđ?’Œđ?’Œđ?’Œđ?’‘đ?’‘đ?’‘đ?’‘ ∗ đ?’†đ?’†đ?’†đ?’†(đ?’?đ?’?đ?’?đ?’?) + đ?’Œđ?’Œđ?’Œđ?’Œđ?’‘đ?’‘đ?’‘đ?’‘ ∗ ďż˝ đ?’†đ?’†đ?’†đ?’†(đ?’‹đ?’‹đ?’‹đ?’‹) + đ?’Œđ?’Œđ?’Œđ?’Œđ?’‘đ?’‘đ?’‘đ?’‘ ∗ (đ?’†đ?’†đ?’†đ?’†(đ?’?đ?’?đ?’?đ?’?) − (đ?’?đ?’?đ?’?đ?’? − đ?&#x;?đ?&#x;?đ?&#x;?đ?&#x;?)) đ?’‹đ?’‹đ?’‹đ?’‹=đ?’?đ?’?đ?’?đ?’?−đ?&#x;—đ?&#x;—đ?&#x;—đ?&#x;—
Utilizando este anĂĄlisis se tendrĂĄ la certeza de que no incrementara demasiado. Las velocidades de los motores se establecen en funciĂłn de dos parĂĄmetros, la salida del controlador y la velocidad del robot (velocidad crucero), para ello se utilizarĂĄ el siguiente criterio: Si el error es negativo: đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’•đ?’•đ?’•đ?’•đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’‘đ?’‘đ?’‘đ?’‘đ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘ = đ?’—đ?’—đ?’—đ?’—đ?’†đ?’†đ?’†đ?’†đ?’—đ?’—đ?’—đ?’—đ?’Žđ?’Žđ?’Žđ?’Žđ?’—đ?’—đ?’—đ?’—đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’—đ?’—đ?’—đ?’—đ?’‘đ?’‘đ?’‘đ?’‘đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’“đ?’“đ?’“đ?’“đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Ž + đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘(đ?’?đ?’?đ?’?đ?’?) đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’•đ?’•đ?’•đ?’•đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’…đ?’…đ?’…đ?’…đ?’Žđ?’Žđ?’Žđ?’Ž = đ?’—đ?’—đ?’—đ?’—đ?’†đ?’†đ?’†đ?’†đ?’—đ?’—đ?’—đ?’—đ?’Žđ?’Žđ?’Žđ?’Žđ?’—đ?’—đ?’—đ?’—đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’—đ?’—đ?’—đ?’—đ?’‘đ?’‘đ?’‘đ?’‘đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’“đ?’“đ?’“đ?’“đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Ž
Si el error es positivo:
đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’•đ?’•đ?’•đ?’•đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’‘đ?’‘đ?’‘đ?’‘đ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’Šđ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘ = đ?’—đ?’—đ?’—đ?’—đ?’†đ?’†đ?’†đ?’†đ?’—đ?’—đ?’—đ?’—đ?’Žđ?’Žđ?’Žđ?’Žđ?’—đ?’—đ?’—đ?’—đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’—đ?’—đ?’—đ?’—đ?’‘đ?’‘đ?’‘đ?’‘đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’“đ?’“đ?’“đ?’“đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Ž đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’•đ?’•đ?’•đ?’•đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’…đ?’…đ?’…đ?’…đ?’Žđ?’Žđ?’Žđ?’Ž = đ?’—đ?’—đ?’—đ?’—đ?’†đ?’†đ?’†đ?’†đ?’—đ?’—đ?’—đ?’—đ?’Žđ?’Žđ?’Žđ?’Žđ?’—đ?’—đ?’—đ?’—đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’—đ?’—đ?’—đ?’—đ?’‘đ?’‘đ?’‘đ?’‘đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’“đ?’“đ?’“đ?’“đ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Žđ?’Ž − đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘đ?’‘(đ?’?đ?’?đ?’?đ?’?)
De esta manera se podrĂĄ controlar los motores utilizando controlador PID, el cual dependerĂĄ de la posiciĂłn del robot con respecto a la lĂnea negra.
Fig.11 Diagrama de flujo programa principal
En el programa principal se describe la funciĂłn calibraciĂłn de sensores, el cual funciona utilizando la librerĂa del sensor QTR-8A, este realiza el testeo de la cantidad de luz del ambiente. III.
PROTOTIPO FINAL
Una vez finalizado el diseĂąo, el anĂĄlisis y escogido los materiales adecuados para la elaboraciĂłn del robot, se procede al armado y programaciĂłn del mismo.
Fig.12 Prototipo seguidor de lĂnea velocista
Posteriormente se realizaron pruebas individuales, para ver el correcto armado, la verificaciĂłn de los sensores, pruebas de conectividad, como tambiĂŠn su eficiencia, tanto de velocidad, duraciĂłn de las baterĂas y estabilidad con respecto a las diferentes curvas de la pista, en base a ellas se realizĂł algunos ajustes para mejorar y reducir las falencias encontradas. Fig.10 Diagrama de flujo del controlador PID
4) Programa principal: El programa principal llamara a todas las demĂĄs funciones ya descritas. Para la implementaciĂłn se utilizĂł diferentes librerĂas y funciones que se observaron anteriormente. Ahora se describirĂĄ el programa principal:
IV.
CONCLUSIONES
DespuĂŠs de las pruebas realizadas en pista se puede concluir que: Un parĂĄmetro que se deberĂĄ de tomar en cuenta, fue el tipo de llanta que deberĂa de usar el robot, puesto que este, al momento de realizar pruebas, tiende a deslizarse o tener poco
21
agarre con respecto a la superficie de la pista, para poder disminuir este parámetro se optó por proporcionar una capa o un recubrimiento que adhiera a la superficie de la pista, pero al pasar el tiempo este tiende a perder o disminuir la adherencia. Adicionalmente todo el sistema es demasiado sensible a la luz del ambiente, por lo cual se recomienda recubrir lo sensores, para que estos, no sean afectados por el medio, caso contrario se deberá de realizar un ajuste a través de software, lo cual tiende a proporcionar error de funcionamiento. Otro de los factores importantes es la facilidad que uno tiene al momento de adquirir los materiales, estos deberán de ser seleccionados, dependiendo del estado del arte del país, puesto que existen otros dispositivos que volverían y disminuirían de gran manera el tamaño y hardware del robot. RECONOCIMIENTOS Para el diseño y el financiamiento de dicho proyecto, se agradece a los docentes de la carrera de Ingeniería Electrónica y del Instituto de Electrónica Aplicada, por la confianza, motivación y el apoyo brindado. También a compañeros que nos proporcionaron sus respectivas observaciones. REFERENCIAS [1] J. S. Tercero, Cibernética aplicada Robots educativos, México: Alfaomega, 2009. [2] Polulo, QTR-8RC Reflectance Sensor Array, Pololu, 1 Enero 2001. [En línea]. Available: https://www.pololu.com/product/961. [Último acceso: 25 Abril 2017]. [3] A. Neal, Tips for selecting DC motors for your mobile robot, Servomagazine, 20 Enero 2010. [En línea]. Available: http://www.servomagazine.com/uploads/issue_downloads/pdf/Tips%20For% 20Selecting%20DC%20Motors%20For%20Your%20Mobile%20Robot.pdf. [Último acceso: 31 Marzo 2017]. [4] Pololu, 50:1 Micro Metal Gearmotor HP, Pololu, 1 Enero 2001. [En línea]. Available: https://www.pololu.com/product/998. [Último acceso: 13 Abril 2017]. [5] Toshiba, Data sheet Driver IC for dual DC motor, Toshiba, 9 Junio 2008. [En línea]. Available: https://www.adafruit.com/images/productfiles/1944/TB6612FNG%20datasheet.pdf. [Último acceso: 10 mayo 2017]. [6] [7] «Arduino Nano Manual». [8] M. Guadilla Barciela, Trad., «Tutorial: EAGLE 4.0 para Linux y Windows “Esquema - Líneas de conexión - Autoruter”». CadSoft Computer, Inc. [9] «Pololu - Arduino Library for the Pololu QTR Reflectance Sensors». [En línea]. Disponible en: https://www.pololu.com/docs/0J19/all. [Accedido: 07jun-2017].
22
EL MANEJO DE DOCKER Ramiro V. Mora Miranda Universidad Mayor De San Andrés Facultad De Ingeniería Ingeniería Electrónica Instituto De Electrónica Aplicada La Paz, Bolivia rmora@umsa.edu.bo
Abstract— Este documento describe de forma simple y objetiva el empleo de la herramienta Docker para el uso de este recurso informático de tendencia de uso en el campo de la virtualización de servicios telemáticos. A partir de procedimientos detallados, se demuestra la funcionalidad de la herramienta, principalmente, en la administración e interconexión de servidores. . I. INTRODUCCIÓN Generalmente, para acceder o ejecutar correctamente una aplicación, se requiere tener instaladas una serie de otras aplicaciones. Docker, es un programa de código abierto que permite que una aplicación Linux y sus dependencias, se empaqueten formando lo que se denomina un contenedor y de esta manera, ejecutar la aplicación de forma correcta, sin la necesidad de preocuparse por configuraciones o la instalación de otros programas. Es decir, Docker crea contenedores ligeros y portátiles para que las aplicaciones y/o servicios puedan ser ejecutados en cualquier máquina que tenga instalado Docker, independientemente del sistema operativo con el que se cuente. La diferencia fundamental entre Docker y la virtualización de máquinas, radica en que el contenedor generado por Docker, no es una máquina virtual. Un contenedor demanda menos espacio de almacenamiento, mientras que, a una máquina virtual requiere instalar un sistema operativo para su funcionamiento, por su parte, un contenedor de Docker, recurre al sistema operativo que tiene la máquina en la que se ejecuta el contenedor, lo que permite que el contenedor de Docker tome los recursos más básicos del sistema operativo de la máquina en la que se ejecuta y aquellos aspectos específicos sean agregados en el interior del contenedor. [1] En el presente artículo, se desarrollarán los procedimientos básicos para el trabajo con Docker. Los ejemplos serán aplicados en un sistema operativo Linux, en su distribución Ubuntu versión II. INSTALACIÓN DE DOCKER Dependiendo del tipo de instalación que se realizó, puede que sea importante agregar algunas propiedades al sistema, lo que permitirá la instalación de aplicaciones mediante repositorios. [2]
Para la instalación de Docker en Ubuntu, en primer lugar, se debe actualizar la base de datos de paquetes. sudo apt-get update
Es necesario agregar la clave GPG de Docker, en el repositorio oficial del sistema. sudo apt-key adv --keyserver hkp://p80.pool.skskeyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
Además de incluir el repositorio Docker a las fuentes APT. sudo apt-add-repository \\ 'deb https://apt.dockerproject.org/repo xenial main'
ubuntu-
Como también, actualizar la base de datos de paquetes con los de Docker, desde el repositorio recién agregado: sudo apt-get update
Es recomendable realizar la instalación desde el repositorio de Docker, en vez del repositorio predeterminado por Ubuntu 16.04: apt-cache policy docker-engine
A continuación, se procederá con la instalación de Docker: sudo apt-get install -y docker-engine
Docker estará instalado, el daemon iniciado y el proceso habilitado desde el arranque. Una prueba de que se está ejecutando Docker como servicio es: sudo systemctl status docker
De forma predeterminada, ejecutar el comando docker requiere privilegios de root, es decir, se tiene que prefijar el comando con sudo. También puede ser ejecutado por un usuario que pertenezca al grupo docker, el cual se crea automáticamente durante la instalación de Docker.
sudo system.properties.common
23
Para dejar de escribir sudo cada vez que ejecute el comando docker, es necesario añadir el nombre del usuario al grupo docker:
docker ps
Para tener una lista de todas las imágenes:
sudo usermod -aG docker $(whoami) docker ps -a
Para agregar un usuario al grupo docker, en el que no se ha iniciado sesión, se debe declarar explícitamente el nombre de usuario a ser utilizado: sudo usermod -aG docker username
El uso de Docker, consiste en enviar una cadena de opciones y comandos seguidos de argumentos. La sintaxis toma la forma de: docker [option] [command] [arguments]
Si se desea ver todos los subcomandos disponibles: docker
Para identificar la versión instalada, se puede consultar mediante: docker --version
III. CONTENEDORES VS. IMÁGENES A. Imagen Una imagen podría considerarse como plantilla o una captura del estado de un contenedor. Por ejemplo, una imagen podría contener el sistema operativo Ubuntu, con un servidor Apache y una aplicación web instalada. Las imágenes se utilizan para crear contenedores, y nunca cambian. [3] Existen muchas imágenes públicas con elementos básicos como Java, Ubuntu, Apache y otros, que se pueden descargar y utilizar. El repositorio oficial http://hub.docker.com
de
imágenes
Docker
es:
B. Contenedores El concepto de contenedor es como si se restaurara una máquina virtual a partir de una captura. Es decir, son instancias en ejecución de una imagen. Los contenedores son los que ejecutan instrucciones o aplicaciones. A partir de una única imagen, es posible ejecutar varios contenedores. [3] C. Diferencia entre contenedor e imagen Como las imágenes no cambian, se crea un contenedor a partir de una imagen y mientras se esté ejecutando el contenedor y se cambia o instala alguna herramienta, al detener el contenedor y al volver a ejecutar la misma imagen, los cambios no se verán reflejados. [3] Si se desea obtener una lista de las imágenes en ejecución, se recurre al comando:
24
o simplemente los identificadores de las imágenes: docker ps -a -q
Cada imagen y contenedor genera un identificador, el cual consiste en un número tomado al azar por el sistema, que estará vigente mientras la imagen o el contenedor permanezcan en el equipo. IV. CONTENEDORES RESIDENTES Para iniciar un contenedor basta con ejecutar el comando run, como ejemplo se iniciará un contenedor que simplemente presentará la hora en la pantalla. docker run jpetazzo/clock
Sin embargo, al momento de paralizar o cerrar el contenedor, éste se detiene y se restaura al punto inicial del arranque. Para que el contenedor se encuentre residente en memoria, se debe recurrir a la opción -d. docker run -d jpetazzo/clock
Como se mencionó, todos los contenedores en ejecución son nombrados, de forma inicial, con un número de identificación (ID), el cual es generado de forma aleatoria. Para ver los registros históricos del contenedor se recurre a la opción logs. docker logs id
Se indicará, de forma general, como id al identificador del contenedor, ya que este número variará entre las diferentes computadoras. Para ver los últimos 5 o n registros del contenedor se procede con: docker logs –tail 5 id
Si se desea conocer al último contenedor generado: docker ps -l
o sólo el id de éste: docker ps -l -q
Al igual que en Unix, es posible tener en pantalla los registros a medida que se vayan generado: docker logs –tail 1 -f id
Y para detener un proceso: docker kill id
V. IMÁGENES INTERACTIVAS Docker, ofrece una gran variedad de imágenes en su sitio oficial hub.docker.com, donde después del registro es posible descargar estas imágenes de acuerdo con los requerimientos del proyecto. Sin embargo, esto también puede realizarse a través de la línea de comando. Por ejemplo, se consultará por la imagen zookeeper.
Ahora el programa wget sí estará disponible. Se puede repetir este ejercicio con el comando curl. # apt install -y curl # curl # exit
Este nuevo contenedor difiere de la imagen original, puesto que, se instalaron dos aplicaciones que originalmente no estaban disponibles y para conocer estas diferencias, se puede ejecutar el comando: docker diff id
docker search zookeeper
En caso de que se desee transformar este contenedor en una imagen, es posible mediante:
o por la versión jessie de Debian.
docker commit id
docker pull debian:jessie
Para descargar una imagen, se recurre a la opción pull, que requiere del nombre de la imagen seguido por el identificador (tag). A continuación, a modo de ejemplo, se instalará la imagen de una versión del sistema operativo Ubuntu y a ésta, se agregarán los comandos wget y curl. docker images docker run -it Ubuntu bash
Este último comando también puede ser ejecutado de la siguiente manera:
De esta manera, se generará un nuevo identificador, tal que es posible recuperar la nueva imagen con los cambios realizados. docker run -it nuevo_id bash # wget
Ahora, el comando wget estará disponible para su utilización. VI. ETIQUETAS A LAS IMÁGENES Las nuevas imágenes, de forma inicial, se generan con un número de identificación aleatorio, pero es posible renombrarlas a través:
docker run --rm -it ubuntu bash
docker images docker tar id nombre_de_la_imagen
La opción -it solicita a Docker, una terminal interactiva y la opción --rm borra otros contenedores residentes que previamente hayan sido generados con la misma imagen.
VII. COMANDOS IMPORTANTES A continuación, se presentarán diversos comandos, los que son empleados con mayor frecuencia.
Una vez obtenido el prompt del sistema operativo correspondiente al contenedor, se pueden ejecutar diversos comandos.
•
sudo service docker restart
# wget
•
En la imagen oficial de Ubuntu, el comando wget no está disponible, por lo tanto, tampoco en el contenedor, sin embargo, es posible instalarlo, siempre y cuando el equipo tenga una conexión activa a Internet u otro repositorio local. Para ello, se procede con las mismas instrucciones que emplea el sistema operativo Ubuntu, ya que en realidad se está inmerso en un contenedor que representa a un equipo donde se ejecuta Ubuntu. # apt-get update # apt-get install -y wget # wget
Reiniciar el servicio de Docker
Listar a los contenedores activos
docker ps
•
Lista con todos los contenedores -a (all)
docker ps -a
•
Lista con los identificadores de todos los contenedores
docker ps -aq
•
Lista de los identificadores de aquellos contenedores activos
25
docker ps -q
Último contenedor ejecutado
•
docker ps -l
Remueve un contenedor por medio del id.
•
docker rm id
Lista de las imágenes disponibles en la máquina local
•
En la línea 1, se evocará a la imagen del sistema operativo Ubuntu, si esta no existe en la máquina local, realizará la descarga de la misma. En la línea 2, con la imagen ya descargada y en ejecución se procederá con la actualización. En la línea 3, se instalará de forma desatendida el programa wget. En cada uno de estos pasos se crea y destruye un contenedor antes de obtener la imágen final.
docker images
Lista con los identificadores de las imágenes disponibles en la máquina local
•
docker images -q
Remueve de forma obligatoria una imagen a través del id
•
Para que el batch sea ejecutado se procede mediante: docker build -t mi_ubuntu .
Revisando el listado de imágenes se puede evidenciar la presencia de una nueva, denominada mi_ubuntu. docker images
docker rmi -f id
Presenta información acerca de la opción rmi
•
Se puede ejecutar la nueva imagen a través de: docker run --it mi_ubuntu bash
docker rmi --help
VIII. ARCHIVO DOCKERFILE Una opción muy útil de Doker, es la generación de una imagen “personalizada”, una que contenga todas las aplicaciones, opciones y configuraciones que se requieren para realizar un trabajo en particular. Esta nueva imagen, puede ser generada a partir de una ya existen, por medio del archivo Dockerfile. A continuación, se desarrollará un ejemplo donde se presentan los comandos más importantes para este fin. Es recomendable ubicar una carpeta donde se generará la imagen, para este caso, se crea una carpeta con el nombre mi_imagen. mkdir mi_imagen cd mi_imagen
Dentro de la carpeta destino, se debe crear un archivo con el nombre Dockerfile. Este nombre debe ser respetado. touch Dockerfile
Puede editarse el archivo Dockerfile con cualquier programa editor de texto.
Para ver la bitácora de ejecución de la nueva imagen: docker history mi_ubuntu
Y para eliminar la imagen de forma obligatoria: docker rmi -f mi_ubuntu
Docker, permite la ejecución de comandos al momento de generar la imagen. Continuando con el ejemplo anterior, se procederá con la identificación del número IP a través de la página web http://ifconfig.co/ip (Se recomienda revisar el sitio web para conocer más acerca de las opciones que ofrece). Editando el archivo Dockerfile, agregar la siguiente línea: 4
CMD wget -O- -q http://ifconfig.co/ip
Será necesario reconstruir la imagen o generar una nueva, este caso se generará una nueva bajo el nombre mi_direccion_ip. docker build -t mi_direccion_ip
Se puede apreciar la nueva imagen
nano Dockerfile docker images
Una vista de Dockerfile es: 1 2 3
26
FROM ubuntu RUN apt-get update RUN apt-get install -y wget
Y al momento de ejecutarla docker run mi_direccion_ip
ésta responderá con una dirección IP, que dependerá de la conexión a Internet que se posea. Sin embargo, la página web http://ifconfig.co tiene diversas opciones, por ejemplo: presenta la ciudad desde donde se realiza la consulta. docker run mi_direccion_ip http://ifconfig.co/city
Pero la imagen creada presenta un error, debido a que el comando no puede ser ejecutado por el contenedor, para solucionar este inconveniente, se deben declarar variables de ingreso, lo que es posible también realizar a través del archivo Dockerfile. Editando el archivo: ENTRYPOINT [ “wget”, “-O-”, “-q”]
4
Como en el paso anterior, se regenera la imagen mi_direccion_ip docker build -t mi_direccion_ip
Si no existe la imagen en el equipo, ésta será descargada. Con la opción publish-all, expone el puerto del contenedor a través de uno generado de forma aleatoria. Para identificar este puerto se ejecuta: docker ps
En el ejemplo, se redireccionó el puerto 32768 al 8000. Por lo tanto, para acceder al servidor web se debe apuntar al URL y el puerto identificado: http://ip:32768 Donde el ip corresponde a la dirección IP del equipo anfitrión. También es posible asignar un número de puerto específico y no uno aleatorio. En este caso será el puerto 88 docker kill id doker run -d -p 88:8000 jpetazzo/web
Para visualizar el contenido del servidor web:
Al momento verificar el envío de argumentos al contenedor, se tiene:
curl localhost:88
docker run mi_direccion_ip http://ifconfig.co/ip
Si no se conoce la dirección IP se puede ejecutar el comando:
Dando como resultado la dirección IP:
Dirección IP docker run mi_direccion_ip http://ifconfig.co/city
Presentando la ciudad desde donde se realiza la consulta: Ciudad docker run mi_direccion_ip http://ifconfig.co/country
o el país: País Finalmente, si se desea acceder al prompt del contenedor, se debe ejecutar: docker run -it --entrypoint bash mi_direccion_ip
docker inspect ‘{{.NetworkSetting.IPAddress}}’
–format
Se tendrá como respuesta, por ejemplo:
172.17.0.2 X. BORRAR CONTENEDORES E IMÁGENES Conociendo las diferencias entre un contenedor y una imagen, se puede borrar del repositorio, sea una imagen o un contenedor. docker rm $(docker ps –all --filter=”status=exited” --quiet)
Con el comando anterior, se borrarán todos aquellos contenedores que tengan como estado exited. Para borrar todas aquellas imágenes que no se utilizan, se puede ejecutar: docker rmi $(docker images --filter=“dangling=true” --quiet)
IX. RED BÁSICA CON CONTENEDORES Para demostrar el acceso a los contenedores por medio de los puertos de red, se empleará un servidor web básico como es del de jpetazzo/web
En algunos casos, se debe indicar que el borrado sea de forma obligatoria o forzada.
docker run -d –publish-all jptazzo/web
docker rmi -f $(docker images)
27
XI. SERVIDORES CON DOCKER Para concluir, se procederá con la realización de dos ejemplos que demuestran la interconexión de contenedores y su interacción con carpetas locales. A. Apache y PHP En este primer ejercicio, se desea contar con un servidor web que soporte la programación PHP, donde las carpetas de almacenamiento y archivos de configuración estarán fuera del contenedor y radicarán en la máquina local. La estructura del proyecto tendrá la siguiente distribución de archivos: ./Dockerfile ./apache_config.conf ./www/index.php
Editar el archivo Dockerfile 1 2 3 4
5 6 7 8 9
10
11 12 13 14 15 16 17 18 19 20 21 22
23 24
FROM ubuntu:latest MAINTAINER Nombre del responsable
# Instalar apache, PHP y programas suplementarios: openssh-server, curl y lynx-cur empleados para depurar el contenedor
RUN apt-get update && apt-get -y upgrade && DEBIAN_FRONTEND=noninteractive apt-get -y install \ apache2 php7.0 php7.0-mysql libapache2-mod-php7.0 \ curl lynx-cur # Habilita el apache mods
RUN a2enmod php7.0 RUN a2enmod rewrite
# Actualiza el archivo PHP.ini, habilita los tags de programación y un ingreso silencioso.
RUN sed -i "s/short_open_tag = Off/short_open_tag = On/" /etc/php/7.0/apache2/php.ini RUN sed -i "s/error_reporting = .*$/error_reporting = E_ERROR | E_WARNING | E_PARSE/" /etc/php/7.0/apache2/php.ini # Definición de las variables de entorno de Apache
ENV ENV ENV ENV ENV
APACHE_RUN_USER www-data APACHE_RUN_GROUP www-data APACHE_LOG_DIR /var/log/apache2 APACHE_LOCK_DIR /var/lock/apache2 APACHE_PID_FILE /var/run/apache2.pid
# Define el puerto de publicación
EXPOSE 80
# La carpeta www será enlazada a la carpeta /var/www/site del contenedor
28
AllowOverride All Order deny,allow Allow from all </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>
El archivo www/index.php 1
<? echo "<p>Hello?</p>"; ?>
Para generar la imagen y ejecutar el contenedor: docker build -t mi_sitio docker run -p 8080:80 -d mi_sitio docker run -it -p 8080:80 mi_sitio bash docker run -it -p 8080:80 /folder_www:/var/www/site mi_sitio bash # apache2ctl start
-v
Para salir del contenedor sin detenerlo se debe presionar ctrl p q. Y para reingresar, conociendo el id del contenedor docker attach id
B. MySQL y PhpMyAdmin Primero se deben descargar las imágenes del servidor de base de datos MySQL y el cliente PhpMyAdmin. docker pull mysql/mysql docker pull phpmyadmin/phpmyadmin
Una vez concluida la descarga, es bueno verificar la existencia de las imágenes dentro el directorio de Docker. docker images
Para ejecutar la base de datos y el cliente se debe tomar en cuenta que, el usuario principal de MySQL requiere de una clave de acceso, esto se puede definir al momento de realizar la llamada al contenedor. Con la opción -e se puedes definir las variables de entorno, este caso la clave será 0000. Por otra parte, se está nombrando al contendor como mysql el que será empleado para acceder mediante el cliente PhpMyAdmin.
ADD www /var/www/site
docker run --name mysql -e MYSQL_ROOT_PASSWORD=0000 -d mysql/mysql-server
ADD apache-config.conf /etc/apache2/sites-enabled/ 000-default.conf
Una vez que el contenedor mysql se encuentra en ejecución, resta acceder desde el cliente PhpMyAdmin, el que se encuentra en otro contendor, para ello, se emplea la opción link. Otro aspecto importante es el redireccionamiento de los puertos, en este caso se empleará el puerto 8080 local que apuntará al 80 del contenedor.
# Actualiza el sitio inicial con el archivo de configuración creado en el equipo local
# Se iniciará el servidor en modo residente
CMD /usr/sbin/apache2ctl -D FOREGROUND
El archivo apache-config.conf 1 2 3 4 5 6
7 8 9 10 11 12 13 14 15
<VirtualHost *:80> ServerAdmin me@mydomain.com DocumentRoot /var/www/site <Directory /var/www/site/> Options Indexes FollowSymLinks MultiViews
docker run --name myadmin -d 8080:80 phpmyadmin/phpmyadmin
--link
mysql:db
-p
Para realizar una prueba y verificar el funcionamiento del servicio: http://dirección_ip:8080 Como en los casos anteriores, es posible acceder al bash mediante docker exec -i -t id bash
Un aspecto que debe tomarse en cuenta es el acceso a la base de datos como usuario root, generalmente este acceso se encuentra restringido a la dirección local (localhost), para que se pueda trabajar con la base de datos con este usuario se debe modificar la tabla user. # mysql -uroot -p Passwd 0000 Mysql> use mysql; Select host, user from user; > update user set host=’%’ host=’localhost’
where
Para terminar, si se desea ejecutar el contenedor con las bases de datos residentes en la máquina local, se puede emplear la opción -v y a continuación la dirección de la carpeta local, seguida de la carpeta correspondiente al contenedor. docker run --name mysql -e MYSQL_ROOT_PASSWORD=0000 -v /home/user/datadir/:/var/lib/mysql -d mysql/mysql-server
XII. CONCLUSIÓN. Docker, es una herramienta muy útil para el desarrollo de nuevas aplicaciones, ya que estas imágenes pueden ser compartidas entre un grupo de programadores y estos a su vez, pueden continuar con la evolución de un proyecto, realizando un trabajo colaborativo más eficiente. Docker también es muy bueno para contar con entornos de pruebas. Es muy sencillo crear y borrar un contenedor, además de ser muy ligeros, por lo que es posible ejecutar varios contenedores en una misma máquina. Esto beneficia a la parte de sistemas, ya como los contenedores son más ligeros que las máquinas virtuales, se reduce el número de máquinas necesarias para contar con un entorno de desarrollo. [1] [2] [3]
REFERENCIAS Jarostaw Krochmailski, Developing with Docker, Packt Publishing Ltd. Birmingham, UK. 2012 Docker. Docker homepage [Online]. Available: https://docs.docker.com/engine/installation/ James Turnbull, The Docker Book, ebook. 2014
29
30
Estudio Comparativo de Rendimiento de Servicios Web: ESB Mule Java vs. Go Omar Yana Instituto de Electrónica Aplicada, Universidad Mayor de San Andrés La Paz, Bolivia omar182_ya@hotmail.com
Abstract—Hoy en día existen diversas soluciones ESB de integración middleware software/hardware completo con licencia propietaria (IBM, Oracle) y open source (Mule, WSO2). Sin embargo, los problemas de rendimiento lo solucionan con la asignación de más recursos computacionales (memoria, procesadores y etc.) y no necesariamente mejorando el código por parte del desarrollador, al estar basado en flujos de integración mediante XML. El mecanismo de transformación/traducción SOAP/XML<=>REST/JSON es realizado mediante una aplicación web proxy servicios web compacto, con lenguaje de programación neutro, garantizando el mayor rendimiento e implementación de patrones de interoperabilidad e integración; en pequeñas/medianas empresas con recursos limitados y bajos costes. En este estudio, se evaluó a través de la experimentación de los prototipos: aplicación web proxy servicios web Go y aplicación web proxy ESB Mule servicios web Java; se comparo ambos cualitativamente y cuantitativamente. Los resultados empíricos están estadísticamente probados para determinar el grado de significación de los resultados. Index Terms—Interoperability, Integration, Performance, Web services, Proxy, REST, SOAP, ESB
– Microsoft DCOM (Distributed Component Object Model) – GLOBAL (Global Object-Based Environment) • Permiten el intercambio de datos estructurados mediante XML (eXtensible Markup Language)/JSON (JavaScript Object Notation) sobre el protocolo HTTP (Hypertext Transport Protocol) como capa de aplicación o transporte, con especificaciones complejas o simples; y son de bajo rendimiento [3]. – SOAP (Simple Object Access Protocol) – REST (REpresentional State Transfer) – WebSockets – SWS (Semantic Web Service) Tecnologías como Sockets, DCOM y RMI, continúan en uso y otras están evolucionando hacia "cualquier servicio que está disponible sobre Internet" [4] como muestra Fig. 1. Así también surgieron modelos de arquitectura [5] que tienen un papel crítico en conectar servicios y aplicaciones heterogéneas en SOA (Service-Oriented Architecture) [6][7]:
I. I NTRODUCCIÓN La complejidad de interoperabilidad e integración de aplicaciones basada en red, es un problema por la necesidad de compartir datos, procesos e información dentro/fuera de una organización [1]. Sin embargo, los servicios web desde su creación solucionan en parte el problema de interoperar e integrar aplicaciones basada en red; como las soluciones tecnológicas presentadas a lo largo de los últimos años: • Permiten el intercambio de datos estructurados mediante octetos sobre TCP (Transmission Control Protocol)/UDP (User Datagram Protocol) y son de alto rendimiento [2]. – EDI (Electronic Data Interchange) – Sockets – Sun RPC (Remote Procedure Call) – DCE/RPC (Distributed Computing Environment/ Remote Procedure Call) – CORBA (Common Object Request Broker Architecture) – Java RMI (Remote Method Invocation)
Basado en directorio de 4,700 web APIs listados en ProgrammableWeb
Fig. 1 Distribución de APIs en protocolos y estilos Fuente John Musser [8]
P2P (Point-to-Point) mantenimiento complejo para las aplicaciones heterogéneas. MOM (Message-Oriented Middleware) API (Application Programming Interfaces) única para las aplicaciones heterogéneas mediante dos arquitecturas básicas Point-toPoint y Publish/Subscribe. EAI (Enterprise Application Integration) mensaje XML único para las aplicaciones heterogéneas mediante dos
31
arquitecturas básicas Hub-and-Spoke y Bus. ESB (Enterprise Service Bus) tecnología propietaria, se requiere de personal cualificado, coste de licencias, basado en configuración y no programación [9]. Un beneficio clave de los servicios web, es la definición de un estándar/estilo, formato de intercambio de datos en XML/JSON, lenguaje de definición de interfaz WSDL (Web Services Description Language)/WADL (Web Application Description Language), mecanismos de aplicación o transporte de comunicación SOAP/REST sobre HTTP y APIs (recurso, mensaje y RCP) [10]. Sin embargo, las problemáticas actuales son: • La complejidad de las especificaciones de los servicios web conocida como incompatibilidad [11], discrepancia entre lo recibido y lo realmente recibido caso .NET y J2EE [12][13]). • Bajo rendimiento de los servicios web [14] especialmente en la transformación/traducción SOAP<=>REST al utilizar un intermediario Comercial [15] o Software Libre o Codigo Abierto [16]. A. Formulación del Problema La interoperabilidad e integración, es un problema entre aplicaciones basada en red; y bajo rendimiento (tiempo de respuesta, transacciones por segundo y throughput: bytes por segundo [16][3]) debido a las transformaciones a realizar sobre datos, procesos e información a intercambiar [17], si se utiliza un ESB [18] para comunicar SOAP<=>REST. II. BASE T EÓRICA Esta sección describe los conceptos principales. A. Servicios Web Un servicio web es un modulo de software ofertado por un proveedor de servicio, y invocado por un consumidor de servicio mediando descubrimiento de un repositorio de registro de servicio; construido sobre estándares abiertos, como TCP/IP, HTTP, URI, JSON y XML [19]. Los servicios web son un elemento primordial para la interoperabilidad e integración de diferentes aplicaciones basada en red, implementadas en diferentes plataformas, lenguajes de programación y tecnologías. 1) SOAP: Es un protocolo estándar desarrollada por Microsoft, IBM y ahora se encuentra bajo el auspicio de W3C [20]. Utiliza como protocolo de transporte HTTP y el formato de intercambio de información XML. La estructura de los mensajes SOAP es: Envelope, Header, Body, Fault; ademas incorpora WSDL, UDDI y especificaciones adicionales WS * (WS-Security, WS-Transacción, etc.). El envió de mensaje SOAP causa bajo rendimiento en comparación a REST [3].
32
2) REST: Es un estilo desarrollado por Roy Thomas Fielding [21]. Utiliza como protocolo de aplicación HTTP y el formato de intercambio de información XML/JSON. El servicio es proveído como un recurso identificado con una URI (Uniform Resource Identifier) llevada a cabo por cuatro del estándar HTTP (GET, PUT, POST, DELETE) [22], ademas incorpora WADL; esto simplifica el acceso al servicio web. B. ESB Es un elemento de software de integración que combina mensajería, servicios web, transformación, invocación, mediación, soporte para distintos protocolos y seguridad que permite la comunicación entres diversas aplicaciones basada en red a través de un bus común. La mayoria de los ESB se basan en se basan en MEP (Pattern of Interchange of Messages) [23]. Existe una gran variedad de productos de software/hardware: Apache Camel, Mule, Apache ServiceMix, Spring Integration, BizTalk, IBM WebSphere ESB, Artix ESB, iWay Service Manager, Oracle Service Bus, webMethods ESB, Progress Sonic ESB, Java Composite Application Suite, ActiveMatrix Service Bus, Business Accelerator ESB, WSO2 [24] y IBM WebSphere DataPower Integration Appliance. C. Trabajos Relacionados A continuación se presentan los principales trabajos relacionados. [25] plantea el diseño de un modelo para integrar aplicaciones Grid para superar problemas de interoperabilidad, implementando un prototipo recurso broker con servicios web SOAP y lenguaje de programación Java. [26] presenta la integración de dispositivos industriales (sensores) mediante patrones SOA con servicios web REST, implementando un middleware con lenguaje de programación Go, obteniendo bajo rendimiento en la simulación en un entorno de sistema en tiempo real. [27] presenta una herramienta de traducción solicitud/respuesta JSON-RPC<=>SOAP basada en el WSDL, para que los dispositivos móviles accedan mediante JSON-RPC a servicio web tradicional SOAP. [28] plantea un framework denominado REST2SOAP, para convertir servicios REST a SOAP y proveer el documento de descripción de servicios WADL; con la finalidad de reducir carga de trabajo de integración. [29] propone basado en la MDA (Arquitectura Dirigida por Modelos), un metamodelo MOF (Meta Object Facility) que abstrae los principales conceptos de servicios web, como mecanismo mediador para la transformación de protocolo SOAP<=>estilo REST; considerando el metamodelo intermedio SOA y los metamodelos SOAP/REST. III. M ÉTODO DE I NVESTIGACIÓN El presente estudio utiliza un método empírico, al ser aplicable el uso de la experiencia para obtener el conocimiento directamente [30]. Y un diseño cuasi-experimental al manipular en
• Aplicación móvil consumidor servicios web (Lenguaje Java). • Aplicación desktop SoapUI consumidor servicios web (Lenguaje Java). • Aplicación web proveedor servicios web (Lenguaje C#).
diferentes modalidades o niveles al grupo de experimentación, no se considera la presencia/ausencia del grupo de control [31]. Aplicando además, un diseño cuantitativo al establecer relaciones causales entre variables cuantificables con un tipo de investigación explicativo, descubre qué causa un determinado hecho, sino también busca aclarar porqué lo causa [32].
C. Escenario de Experimentación
A. Muestra
Escenario general de experimentación, está compuesta por los siguientes componentes como en Fig. 2:
Son las siguientes aplicaciones basada en red: • Aplicación web consumidor servicios web, con lenguaje Php y protocolo SOAP. • Aplicación desktop consumidor servicios web, con lenguaje Java y protocolo SOAP. • Aplicación desktop consumidor servicios web, con lenguaje C# y protocolo SOAP. • Aplicación móvil consumidor servicios web, con lenguaje Java y protocolo SOAP. • Aplicación web proveedor servicios web, con lenguaje C# y estilo REST. B. Instrumento Son las siguientes herramientas de pruebas de servicios web: SoapUI [33] (Versión 5.2.0) es una herramienta Open Source desarrollado en Java, provee mecanismos de pruebas funcionales y de rendimiento para servicios web. Es un consumidor servicios web de protocolo SOAP y estilo REST; fácil de utilizar a través de una interfaz gráfica [34]. TCPMon [35] (Versión 1.0) es una herramienta Open Source desarrollado en Java, que puede usarse para monitorear mensajes de protocolo TCP. IV. E XPERIMENTACIÓN Para facilitar la comparación de interoperabilidad e integración y rendimiento; consiste en realizar medidas repetidas con un solo grupo experimental en dos modalidades. A. Modalidad de Experimentación Las modalidades de experimentación son: • Aplicación web proxy ESB Mule servicios web (Lenguaje Java). • Aplicación web proxy servicios web (Lenguaje Go). B. Grupo de Experimentación El grupo de experimentación es el mismo en cada modalidad: • Aplicación web consumidor servicios web (Lenguajes Php). • Aplicación desktop consumidor servicios web (Lenguaje Java). • Aplicación desktop consumidor servicios web (Lenguaje C#).
Fig. 2 Escenario de experimentación: proxy transformación/traducción
1) Consumidor: Aplicación basada en red que genera una petición de solicitud en protocolo SOAP y la envía a la aplicación intermediaria; y recibe una respuesta en protocolo SOAP • Aplicación web consumidor servicios web (Lenguajes Php). • Aplicación desktop consumidor servicios web (Lenguaje Java). • Aplicación desktop consumidor servicios web (Lenguaje C#). • Aplicación móvil consumidor servicios web (Lenguaje Java). • Aplicación desktop SoapUI consumidor servicios web (Lenguaje Java). 2) Intermediario: Aplicación basada en red que espera una petición de solicitud en protocolo SOAP de la aplicación consumidor, transforma la petición de solicitud en estilo REST y la envía a la aplicación proveedor; del cuál recibe una respuesta en estilo REST y transforma la respuesta recibida en protocolo SOAP. • Aplicación web proxy ESB Mule servicios web (Lenguaje Java). • Aplicación web proxy servicios web (Lenguaje Go). 3) Proveedor: Aplicación basada en red que espera una petición de solicitud en estilo REST y genera una respuesta a la aplicación intermediaria en estilo REST. • Aplicación web proveedor servicios web (Lenguaje C#)
33
4) API: Código fuente utilizado como interfaz para la comunicación entre aplicaciones consumidor, intermediario y proveedor; en función a: • WSDL. • WADL. 5) Red: Conecta los ordenadores de los componentes consumidor, intermediario y proveedor. D. Entorno de Experimentación Entorno de hardware y software desplegada en el Laboratorio del INSTITUTO DE ELECTRÓNICA APLICADA. 1) Consumidor: • Hardware: – Processor: Intel(R) Core(TM) i3 CPU 550 @ 3.20 GHz, 2 core. – RAM: 4.00 GB. – Network Adapter: NIC de Gigabit Ethernet PCI de la familia Realtek RTL8169/8110 (NDIS 6.20). – IP Address: 192.168.100.71 - Subnet Mask: 255.255.255.0 - Gateway: 192.168.100.1. • Software: – Operating System: Windows 10 Pro. – Type System: 64 bits. 2) Intermediario (físico): • Hardware: – Processor: 1 Intel Xeon E5-2603v3 1.60 GHz, 15 MB L3 Cache, 6 core. – RAM: 8.00 GB. – Hard Disk: 1 TB SATA. – Network Adapter: HP Embedded Dual Port 361i Adapter. – IP Address: 192.168.100.10 - Subnet Mask: 255.255.255.0 - Gateway: 192.168.100.1. • Software: – Operating System: Proxmox Virtual Environment 4.31. – Type System: 64 bits. 3) Intermediario (virtual): • Hardware: – Processor: Common kvm64 processor 1.60 GHz, 1 sockets 6 core. – RAM: 2.00 GB. – Hard Disk: 30 GB SATA. – Network Adapter: Intel E1000. – GO -> IP Address: 192.168.100.81:8282 - Subnet Mask: 255.255.255.0 - Gateway: 192.168.100.1. – ESB MULE JAVA -> IP Address: 192.168.100.83:8383 - Subnet Mask: 255.255.255.0 - Gateway: 192.168.100.1. • Software: – Operating System: Ubuntu Server 16.04.2 - amd64. – Type System: 64 bits.
34
4) Proveedor: • Hardware: – Processor: Intel(R) Core(TM) i5-2500C CPU @ 3.30 GHz, 4 core. – RAM: 8.00 GB. – Network Adapter: Intel(R) 82579V Gigabit Network Connection. – IP address: 192.168.100.99:8181 - Subnet mask: 255.255.255.0 - Gateway: 192.168.100.1. • Software: – Operating System: Windows Server 2016 - Free Evaluation. – Type System: 64 bits. 5) Red: • Hardware: – Device: Cloud Router Switch. – Manufacturer: MikroTik. – Model: CRS125-24G-1S-2HnD-IN. – Network Adapters: 24-Port 10/100/1000 Mbps. – Patch Cord: UTP Category 5e. – Operating System: RouterOS. – Processor: 60 MHz, 1 core. – RAM: 128 MB. E. Experimento de Interoperabilidad e Integración El objetivo es medir las funcionalidades de servicios web de la aplicación web proxy servicios web para interoperar e integrar en el intercambio de datos, procesos e información entre aplicaciones basada en red con la transformación de servicios web SOAP/XML<=>REST/JSON. 1) Resultados Modalidad Aplicación Web Proxy ESB Mule Servicios Web Java: Se realizó pruebas funcionales de servicios web, que consistieron en una solicitud enviando un mensaje SOAP con cinco aplicaciones consumidores servicios web, a la aplicación web proxy ESB Mule servicios web (Lenguaje de programación Java) para realizar la transformación mensaje SOAP/XML a REST/JSON y viceversa; y a su vez esta realizó una solicitud enviando un mensaje REST a la aplicación proveedor de servicios web. La Tabla I, muestra los resultados obtenidos de interoperabilidad e integración. 2) Resultados Modalidad Aplicación Web Proxy Servicios Web Go: Se realizó pruebas funcionales de servicios web, que consistieron en una solicitud enviando un mensaje SOAP con cinco aplicaciones consumidores servicios web, a la aplicación web proxy servicios web (Lenguaje de programación Go) para realizar la transformación mensaje SOAP/XML a REST/JSON y viceversa; y a su vez esta realizó una solicitud enviando un mensaje REST a la aplicación proveedor de servicios web. La Tabla II, muestra los resultados obtenidos de interoperabilidad e integración. F. Experimento de Rendimiento El objetivo es medir el rendimiento de la aplicación web proxy servicios web para interoperar e integrar en el in-
Tabla I R ESULTADO DE I NTEROPERABILIDAD P ROXY ESB M ULE JAVA Prueba
Aplicación basada en red
1
Aplicación web consumidor servicios web, con lenguajes Php y protocolo SOAP Aplicación desktop consumidor servicios web, con lenguaje Java y protocolo SOAP Aplicación desktop consumidor servicios web, con lenguaje C# y protocolo SOAP Aplicación móvil consumidor, con lenguaje Java y protocolo SOAP Aplicación desktop consumidor SoapUI, con lenguaje Java y protocolo SOAP
2
3
4 5
Aplicación web proveedor servicios web, con lenguajes C# y estilo REST SI
Aplicación basada en red
1
Aplicación web consumidor servicios web, con lenguajes Php y protocolo SOAP Aplicación desktop consumidor servicios web, con lenguaje Java y protocolo SOAP Aplicación desktop consumidor servicios web, con lenguaje C# y protocolo SOAP Aplicación móvil consumidor, con lenguaje Java y protocolo SOAP Aplicación desktop consumidor SoapUI, con lenguaje Java y protocolo SOAP
2
3
4 5
Tabla III R ESULTADO DE R ENDIMIENTO P ROXY ESB M ULE JAVA
SI
SI
SI SI
Tabla II R ESULTADO DE I NTEROPERABILIDAD P ROXY G O Prueba
servicios web, a la aplicación web proxy ESB Mule servicios web (Lenguaje de programación Java) para realizar la transformación mensaje SOAP/XML a REST/JSON y viceversa; y a su vez esta realizó una solicitud enviando un mensaje REST a la aplicación proveedor de servicios web. La Tabla III, muestra los resultados obtenidos de rendimiento.
Aplicación web proveedor servicios web, con lenguajes C# y estilo REST SI SI
SI
SI SI
# 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
# Registros 1 5 10 25 50 75 100 250 500 750 1000 2500 5000 7500 10000 12500 15000 17500 20000 25000
min max 129–413 129–575 129–504 129–395 129–582 130–408 130–440 133–469 138–551 144–592 148–609 177–596 225–646 270–1017 323–915 380–1069 428–1158 468–1378 540–1567 638–1748
avg ms 165,53 162,55 162,20 169,14 167,79 167,54 167,79 175,86 183,58 199,32 196,21 239,28 306,90 396,80 466,16 560,36 645,44 743,23 816,30 981,28
tps 30,20 30,75 30,82 29,56 29,79 29,84 29,79 28,43 27,23 25,08 25,48 20,89 16,29 12,60 10,72 8,92 7,74 6,72 6,12 5,09
kbps 12,15 39,16 72,81 166,39 329,87 492,88 654,25 1553,07 2970,01 4100,95 5553,57 11377,07 17740,65 20581,92 23347,29 24283,38 25284,92 25611,40 26656,60 27712,61
2) Resultados Modalidad Aplicación Web Proxy Servicios Web Go: Se realizó las pruebas de carga de servicios web, que consistieron en 20 solicitudes enviando un mensaje SOAP con la aplicación desktop SoapUI consumidor servicios web, a la aplicación web proxy servicios web (Lenguaje de programación Go) para realizar la transformación mensaje SOAP/XML a REST/JSON y viceversa; y a su vez esta realizó una solicitud enviando un mensaje REST a la aplicación proveedor de servicios web. La Tabla IV, muestra los resultados obtenidos de rendimiento. Tabla IV R ESULTADO DE R ENDIMIENTO P ROXY G O
tercambio de datos, procesos e información entre aplicaciones basada en red con la transformación de servicios web SOAP/XML<=>REST/JSON. Tiempo de respuesta [ms] es el intervalo de tiempo que transcurre entre la solicitud/respuesta entre componentes cliente/intermediario/servidor. Transacciones por segundo [tps] es el número de solicitudes que se atienden en un período de tiempo entre componentes cliente/intermediario/servidor. Throughput (kilobytes por segundo) [kbps] es la tasa media (velocidad) de volumen de información transferida entre componentes cliente/intermediario/servidor y los gastos de comunicación. 1) Resultados Modalidad Aplicación Web Proxy ESB Mule Servicios Web Java: Se realizó las pruebas de carga de servicios web, que consistieron en 20 solicitudes enviando un mensaje SOAP con la aplicación desktop SoapUI consumidor
# 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
# Registros 1 5 10 25 50 75 100 250 500 750 1000 2500 5000 7500 10000 12500 15000 17500 20000 25000
min max 4–406 4–291 5–51 5–71 6–172 6–339 8–359 12–334 20–397 28–437 35–285 82–548 159–961 234–833 318–1900 390–1587 470–1967 514–1668 648–2439 863–2326
avg ms 13,84 9,53 8,22 8,20 10,19 15,14 13,34 23,52 37,01 42,89 51,15 141,58 264,58 403,22 520,89 643,75 770,18 878,40 1091,70 1317,92
tps 361,18 524,42 607,86 609,31 490,62 330,20 374,72 212,54 135,08 116,55 97,74 35,31 18,89 12,40 9,59 7,76 6,49 5,69 4,57 3,79
kbps 145,32 667,82 1435,95 3429,75 5432,75 5454,10 8229,57 11610,62 14733,35 19057,63 21303,21 19230,47 20572,19 20255,22 20886,24 21125,46 21201,44 21685,84 19905,33 20634,73
35
G. Método de Análisis Estadístico Se necesita analizar los resultados, simplemente haciendo cálculos de rendimiento específico y generando gráficas o tablas no son suficientes para el análisis. Se utilizo las siguientes herramientas: lenguaje R, entorno integrado de desarrollo R y RStudio [36][37]. 1) Prueba t de Student Comparación por Pares (Apareado): Para el experimento de rendimiento, con un tamaño de muestra (20 pruebas), se ha utilizado Prueba t de Student [38] apareado con dos colas, por ser mediciones de pruebas repetitivas en tres modalidades de experimentación. Para una distribución t de Student se considera: • Número de grados de libertad = 19. • Probabilidad (nivel de significancia) = 0,05 (repartida 0,025 en cada cola). • Muestra de tamaño n = 20 pruebas. Tabla V
aplicaciones basada en red con servicios web SOAP y REST. Tabla VI R ESULTADO C OMPARATIVO DE I NTEROPERABILIDAD Prueba
Aplicación basada en red
1
Aplicación web consumidor servicios web, con lenguajes Php y protocolo SOAP Aplicación desktop consumidor servicios web, con lenguaje Java y protocolo SOAP Aplicación desktop consumidor servicios web, con lenguaje C# y protocolo SOAP Aplicación móvil consumidor, con lenguaje Java y protocolo SOAP Aplicación desktop consumidor SoapUI, con lenguaje Java y protocolo SOAP
2
3
4
P-VALUES - C OMPARACIÓN POR PARES ( APAREADO ) Comparación por pares (apareado) avg ms tps kbps
Aplicación web proxy servicios web ESB Mule Java vs. Go t P-Value 1,149000 0,264800 -3,707800 0,001493 -1,926200 0,069180
* Nota : P (T <= t) bilateral. Si P-Value <= 0,05; entonces ambas muestras tienen diferencias estadísticas significativas al nivel de confianza del 95%. Si P-Value > 0,05; entonces ambas muestras no tienen diferencias estadísticas significativas al nivel de confianza del 95%.
El valor P-Value, ayuda a analizar los resultados experimentales de rendimiento, para determinar las diferencias entre las observaciones de un mismo individuo (SoapUI) en un particular escenario de experimentación. La Tabla V, muestra los resultados del cálculo de las pruebas t de Student. En la cual existe diferencias estadísticas en tps; Sin embargo en tps y kbps no existe diferencias estadísticas, de esto se deduce que Go obtiene mayor rendimiento con registros menor o igual a 1000 (<= 1000 [registros]) y ESB Mule Java obtiene mayor rendimiento con registros mayor a 1000 (> 1000 [registros]). V. R ESULTADOS Y D ISCUSIÓN Se elaboró tablas y gráficas comparativas de los resultados obtenidos en las dos modalidades de experimentación: Aplicación web proxy ESB Mule Java servicios web y Aplicación web proxy Go servicios web. A. Comparativa de Resultados de Interoperabilidad e Integración La Tabla VI, compara los resultados de la aplicación web proxy ESB Mule servicios web con lenguaje de programación Java y la aplicación web proxy servicios web con lenguaje de programación Go; se observa que tienen el mismo resultado con respecto a la funcionalidad de transformar/traducir servicios web protocolo SOAP/XML<=>estilo REST/JSON entre
36
5
Aplicación web proveedor servicios web, con lenguajes C# y estilo REST ESB Mule Java Go SI SI SI
SI
SI
SI
SI
SI
SI
SI
B. Comparativa de Resultados de Rendimiento La Tabla VII, compara los resultados de la aplicación web proxy ESB Mule servicios web con lenguaje de programación Java y la aplicación web proxy servicios web con lenguaje de programación Go; se observa que tienen diferentes resultados con respecto al rendimiento (tiempo de respuesta, transacciones por segundo y throughput) de transformar/traducir servicios web protocolo SOAP/XML<=>estilo REST/JSON entre aplicaciones basada en red con servicios web SOAP y REST. Tabla VII R ESULTADO C OMPARATIVO DE R ENDIMIENTO Registros # # 1 1 2 5 3 10 4 25 5 50 6 75 7 100 8 250 9 500 10 750 11 1000 12 2500 13 5000 14 7500 15 10000 16 12500 17 15000 18 17500 19 20000 20 25000
ESB Mule Java avg ms tps kbps 165,53 30,20 12,15 162,55 30,75 39,16 162,20 30,82 72,81 169,14 29,56 166,39 167,79 29,79 329,87 167,54 29,84 492,88 167,79 29,79 654,25 175,86 28,43 1553,07 183,58 27,23 2970,01 199,32 25,08 4100,95 196,21 25,48 5553,57 239,28 20,89 11377,07 306,90 16,29 17740,65 396,80 12,60 20581,92 466,16 10,72 23347,29 560,36 8,92 24283,38 645,44 7,74 25284,92 743,23 6,72 25611,40 816,30 6,12 26656,60 981,28 5,09 27712,61
avg ms 13,84 9,53 8,22 8,20 10,19 15,14 13,34 23,52 37,01 42,89 51,15 141,58 264,58 403,22 520,89 643,75 770,18 878,40 1091,70 1317,92
Go tps 361,18 524,42 607,86 609,31 490,62 330,20 374,72 212,54 135,08 116,55 97,74 35,31 18,89 12,40 9,59 7,76 6,49 5,69 4,57 3,79
kbps 145,32 667,82 1435,95 3429,75 5432,75 5454,10 8229,57 11610,62 14733,35 19057,63 21303,21 19230,47 20572,19 20255,22 20886,24 21125,46 21201,44 21685,84 19905,33 20634,73
1) Tiempo de Respuesta: En la Fig. 3, se observa que la aplicación web proxy servicios web Go es más rápida obteniendo el primer lugar con 313,26 [ms]. En segundo lugar
con 353,66 [ms], está la aplicación web proxy ESB Mule servicios web Java con una diferencia más lenta del 13% en relación al primer lugar..
Fig. 5 Resultado comparativo de throughput (kilobytes por segundo)
Fig. 3 Resultado comparativo de tiempo de respuesta
2) Transacciones por Segundo: En la Fig. 4, se observa que la aplicación web proxy servicios web Go logra mayor número de transacciones obteniendo el primer lugar con 198,24 [tps]. En segundo lugar con 20,60 [tps], está la aplicación web proxy ESB Mule servicios web Java el número de transacciones se comporta con un decremento del 90% en relación al primer lugar..
Fig. 4 Resultado comparativo de transacciones por segundo
3) Throughput (Kilobytes por Segundo): En la Fig. 5, se observa que la aplicación web proxy servicios web Go logra mayor velocidad de volumen de información obteniendo el primer lugar con 13849,85 [kbps]. En segundo lugar con 10927,05 [kbps], está la aplicación web proxy ESB Mule servicios web Java la velocidad de volumen de información se comporta con un decremento del 21% en relación al primer lugar. C. Discusión Los resultados experimentales de interoperabilidad e integración obtenidos señalan que la aplicación web proxy servicios web Go es igual a la aplicación web proxy ESB Mule servicios web Java. Los resultados experimentales de rendimiento obtenidos señalan que las aplicación web proxy servicios web Go y la aplicación web proxy ESB Mule servicios web Java son
diferentes. En el caso Go tiene mejores tiempos de respuesta, transacciones por segundo y throughput (bytes por segundo); cuando son registros menores o igual a 1000. Lo cual, confirma la optimización de rendimiento entre la aplicaciones basada en red con lenguajes de programación heterogéneas (Java, C# y Php), servicios web (SOAP/XML y REST/JSON); en el correcto funcionamiento del intermediario proxy servicios web Go. VI. C ONCLUSIÓN El mecanismo de transformación/traducción entre servicios web SOAP/XML y REST/JSON para mayor rendimiento; esta orientada a pequeñas/medianas empresas para realizar la interoperabilidad e integración de aplicaciones basada en red a bajo coste y recursos de infraestructura limitada. El diseño y desarrollo ad-hoc de una aplicación web proxy servicios web compacto en lenguaje de programación Go fuertemente tipado es una solución óptima para obtener un mayor rendimiento, utilizando patrones de interoperabilidad e integración. Las aplicaciones prototipo basada en red web, desktop y móvil consumidor/proveedor servicios web están diseñados y desarrollados en lenguajes de programación Java, C# y Php; con servicios web SOAP/XML y REST/JSON. Los resultados de rendimiento de la aplicación web proxy servicios web Go es validado con la comparación de la aplicación web proxy ESB Mule servicios web Java, en favor de Go en lo que respecta a su interoperabilidad, integración y rendimiento; en tiempo de respuesta en un 13%, transacciones por segundo en un 90% y throughput (kilobytes por segundo) en un 21%. El resultado sólo constituye optimización de rendimiento, para su implementación de modo ágil se requiere del diseño y desarrollo de un framework en lenguaje de programación Go. A PÉNDICE A A PLICACIONES BASADA EN R ED A. Aplicación Web Consumidor Servicios Web, con Lenguaje Php y Protocolo SOAP/Estilo REST 1) Consumidor: • Aplicación basada en red: Web.
37
• Entorno de desarrollo integrado: Notepad++ versión 5.3.1. • Aplicación servidor: Apache HTTP Server versión 2.4.17. • Plataforma de desarrollo: PHP versión 5.6.21 y CodeIgniter 2.2.2. • Lenguaje de programación: Php. • API para SOAP: Librería php_soap versión 5.6.21 y NuSOAP (Web Services Toolkit) versión 0.6.5. • API para REST: Librería restclient (CodeIgniter-REST Client) versión 2.2.1 y codeigniter-curl versión 1.3.0. B. Aplicación Desktop Consumidor Servicios Web, con Lenguaje Java y Protocolo SOAP/Estilo REST 1) Consumidor: • Aplicación basada en red: Desktop. • Entorno de desarrollo integrado: Netbeans versión 7.2.1. • Plataforma de desarrollo:• Java Development Toolkit (JDK) versión 1.7.0_11. • Lenguaje de programación: Java. • API para SOAP: Librería JAX-WS versión 2.2.6. • API para REST: Librería Jersey versión 1.8 (JAX-RS RI) y JAX-RS versión 1.1. C. Aplicación Desktop Consumidor/Proveedor Servicios Web, con Lenguaje C# y Protocolo SOAP/Estilo REST 1) Consumidor: • Aplicación basada en red: Desktop. • Entorno de desarrollo integrado: SharpDevelop versión 4.2.0-Beta. • Plataforma de desarrollo: .NET Framework versión 2.0. • Lenguaje de programación: C# versión 5.0. • API para SOAP: Librería System.Web.Services versión 4.0.0.0. • API para REST: Librería System.Net versión 4.0.0.0 y Newtonsoft.Json versión 6.0.8. 2) Proveedor: • Aplicación basada en red: Web. • Entorno de desarrollo integrado: Xamarin Studio versión 5.9.2. • Aplicación servidor: Internet Information Services versión 10.0.10240. • Plataforma de desarrollo: Mono/.NET Framework versión 4.0. • Lenguaje de programación: C# versión 5.0. • API para SOAP: Librería System.Web.Services versión 4.0.0.0. • API para REST: Librería System.Web.Http versión 4.0.0.0 y Newtonsoft.Json versión 4.5.11. • Base de datos orientada a objetos embebida: db4o versión 7.2 - .NET versión 2.0. • Módem GSM: LG KS360. – Comando AT: Hypertrm versión 6.2. – Interfaz serial: RS-232 mediante cable.
38
D. Aplicación Móvil Consumidor Servicios Lenguaje Java y Protocolo SOAP/Estilo REST
Web,
con
1) Consumidor: • Aplicación basada en red: Móvil. • Entorno de desarrollo integrado: Android Development Toolkit (adtbundle) versión 21.0.1, Eclipse (Juno) Java Development Tools versión 3.8.1 y Java Development Toolkit (JDK) versión 1.7.0_11. • Plataforma de desarrollo: Android versión 4.1.2 y API Level versión 16. • Lenguaje de programación: Java. • API para SOAP: Librería ksoap versión 2.5.8. • API para REST: Librería android (apache) y gson versión 2.2.0. E. Aplicación Desktop SoapUI Consumidor Servicios Web, con Lenguaje Java y Protocolo SOAP/Estilo REST 1) Consumidor: • Aplicación basada en red: Desktop SoapUI versión 5.2.0. • Plataforma de desarrollo: Java Runtime Environment (JRE) versión 1.7.0. • Lenguaje de programación: Java. • API para SOAP: Soporta SOAP. • API para REST: Soporta REST. 2) Configuración: Para realizar las pruebas de rendimiento. En SoapUI Preferences -> HTTP Settings, marcar cierre la conexión HTTP después de cada solicitud SOAP, para deshabilitar el HTTP Keep-Alives. En LoadTest Options, desmarcar basado sobre el tiempo real pasado, para utilizar el cálculo basado en el tiempo de ejecución promedio: TPS = ( 1000 / avg ) * threadcount; BPS = ( bytes / CNT ) * TPS;
avg: tiempo promedio del Test Step (en milisegundos). CNT: número de veces que el Test Step ha sido ejecutado. TPS: número de transacciones por segundo para el Test Step. bytes: número de bytes procesados por el Test Step. BPS: bytes por segundo procesado por el Test Step. threadcount: número de hilos o usuarios virtuales para el Test Step. En LoadTest configurar para las 20 pruebas de rendimiento: Strategy: en este caso de prueba servicio web, es la estrategia simple o básica, que realiza la ejecución TestCase con un retardo configurable aleatorio. Limit: en este caso de prueba servicio web, es 300 segundos que la prueba estará en ejecución. Threads: o “Usuarios Virtuales”: en este caso de prueba servicio web, es 5 usuarios virtuales. Test Delay: en este caso de prueba servicio web, es 1000 milisegundos entre cada caso de prueba (en el caso de existir más casos de prueba). Random: es un factor de 0 a 1 para asignarle un nuevo valor de retardo de prueba (Test Delay), su cálculo es el siguiente:
Test Delay = TestDelay - RandomNumberBetween(0, TestDelay*Random);
En este caso de prueba servicio web, es 0 realizando el cálculo es: Test Delay = 1000 - RandomNumberBetween(0, 1000*0) = 1000 milisegundos;
F. Aplicación Web Proxy Servicios Web, con Lenguaje Go y Protocolo SOAP/Estilo REST 1) Intermediario: • Aplicación basada en red: Web. • Entorno de desarrollo integrado: LiteIDE X versión X32.2 linux - x64 - qt4. • Aplicación servidor: Nativo. • Plataforma de desarrollo: Go versión 1.9.0 linux amd64. • Lenguaje de programación: Go. • API para SOAP: Librería “encoding/xml” y “net/http”. • API para REST: Librería “encoding/json” y “net/http”. G. Aplicación Web Proxy ESB Mule Servicios Web, con Lenguaje Java y Protocolo SOAP/Estilo REST 1) Intermediario: • Aplicación basada en red: Web. • Entorno de desarrollo integrado: Anypoint Studio Tooling for Mule ESB versión 5.3.0 y Eclipse Java Development Tools versión 3.10.1. • Aplicación servidor: Apache Tomcat versión 7.0.78 o Mule Server versión 3.7.2. • Plataforma de desarrollo: Java Development Toolkit (JDK) versión 1.7.0_79 linux - x64. • Lenguaje de programación: Java. • API para SOAP: Librería CFX versión 2.7.15. • API para REST: Librería Jersey versión 1.8 (JAX-RS RI) y JAX-RS versión 1.1. A PÉNDICE B P ROCEDIMIENTO T RANSFORMACIÓN /T RADUCCIÓN PARA S OLICITUD /R ESPUESTA SOAP/REST A. Solicitud/Respuesta SOAP/REST para enviarMensaje 1 Solicitud SOAP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
REQUEST - SOAP POST /proxywsgo/soap/sms HTTP/1.1 Connection: close Accept-Encoding: gzip,deflate Content-Type: text/xml;charset=UTF-8 SOAPAction: "" Content-Length: 420 Host: 127.0.0.1:8282 User-Agent: Apache-HttpClient/4.1.1 (java 1.5) <soapenv:Envelope xmlns:soapenv= "http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://soap/"> <soapenv:Header/> <soapenv:Body> <soap:enviarMensaje> <modoMensaje>single</modoMensaje> <encUsername>test</encUsername> <encPassword>test</encPassword> <numero>59176100000</numero> <envia>omar</envia> <mensaje>test soap client</mensaje> <numeroMensaje>1</numeroMensaje> </soap:enviarMensaje> </soapenv:Body> </soapenv:Envelope> http://127.0.0.1:8282/proxywsgo/soap/sms
2 Solicitud REST
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
REQUEST - REST PUT /serverrestws/rest/sms HTTP/1.1 Host: 127.0.0.1:8181 User-Agent: Go-http-client/1.1 Content-Length: 150 Accept: application/json Accept-Encoding: gzip { "modoMensaje":"single", "encUsername":"test", "encPassword":"test", "numero":"59176100000", "envia":"omar", "mensaje":"test soap client", "numeroMensaje":"1" } http://127.0.0.1:8181/serverrestws/rest/sms
3 Respuesta REST 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
RESPONSE - REST HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Content-Type: application/json; charset=utf-8 Expires: -1 Server: Microsoft-IIS/10.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Fri, 01 Apr 2017 09:00:12 GMT Connection: close Content-Length: 12 { "result":1 } http://127.0.0.1:8181
4 Respuesta SOAP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
RESPONSE - SOAP HTTP/1.1 200 OK Content-Type: text/xml; charset=UTF-8 Date: Fri, 01 Apr 2017 09:19:02 GMT Content-Length: 207 Connection: close <soap:Envelope xmlns:soap= "http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:enviarMensajeResponse xmlns:ns2="http://soap/"> <return>1</return> </ns2:enviarMensajeResponse> </soap:Body> </soap:Envelope> http://127.0.0.1:8282
B. Solicitud/Respuesta SOAP/REST para listarMensaje 1 Solicitud SOAP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
REQUEST - SOAP POST /proxywsgo/soap/sms HTTP/1.1 Connection: close Accept-Encoding: gzip,deflate Content-Type: text/xml;charset=UTF-8 SOAPAction: "" Content-Length: 253 Host: 127.0.0.1:8282 User-Agent: Apache-HttpClient/4.1.1 (java 1.5) <soapenv:Envelope xmlns:soapenv= "http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://soap/"> <soapenv:Header/> <soapenv:Body> <soap:listarMensaje> <cantidadRegistro>2</cantidadRegistro> </soap:listarMensaje> </soapenv:Body> </soapenv:Envelope> http://127.0.0.1:8282/proxywsgo/soap/sms
2 Solicitud REST 1 2 3 4 5
REQUEST - REST GET /serverrestws/rest/sms/cantidadRegistro/2 HTTP/1.1 Host: 127.0.0.1:8181 User-Agent: Go-http-client/1.1 Accept: application/json Accept-Encoding: gzip http://127.0.0.1:8181/serverrestws/rest/sms
3 Respuesta REST 1 2 3 4 5 6 7 8 9 10 11 12
RESPONSE - REST HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Content-Type: application/json; charset=utf-8 Expires: -1 Server: Microsoft-IIS/10.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Fri, 01 Apr 2017 09:26:02 GMT Content-Length: 303 [
39
13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ]
{ "modoMensaje":"single", "encUsername":"test", "encPassword":"test", "numero":"59176100000", "envia":"omar", "mensaje":"test soap client", "numeroMensaje":"1" }, { "modoMensaje":"single", "encUsername":"test", "encPassword":"test", "numero":"59176100000", "envia":"omar", "mensaje":"test soap client", "numeroMensaje":"1" } http://127.0.0.1:8181
4 Respuesta SOAP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
RESPONSE - SOAP HTTP/1.1 200 OK Content-Type: text/xml; charset=UTF-8 Date: Fri, 01 Apr 2017 09:26:02 GMT Content-Length: 635 Connection: close <soap:Envelope xmlns:soap= "http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:listarMensajeResponse xmlns:ns2="http://soap/"> <return> <modoMensaje>single</modoMensaje> <encUsername>test</encUsername> <encPassword>test</encPassword> <numero>59176100000</numero> <envia>omar</envia> <mensaje>test soap client</mensaje> <numeroMensaje>1</numeroMensaje> </return> <return> <modoMensaje>single</modoMensaje> <encUsername>test</encUsername> <encPassword>test</encPassword> <numero>59176100000</numero> <envia>omar</envia> <mensaje>test soap client</mensaje> <numeroMensaje>1</numeroMensaje> </return> </ns2:listarMensajeResponse> </soap:Body> </soap:Envelope> http://127.0.0.1:8282
R ECONOCIMIENTOS Agradecer a Paul Cori ayudante de laboratorio del Instituto de Electrónica Aplicada de la Universidad Mayor de San Andrés, por su apoyo en la realización de la experimentación. R EFERENCIAS [1] L. F. Gómez, “Interoperabilidad en los sistemas de información documental (sid): la información debe fluir,” Revista Códice, vol. 3, pp. 23– 39, 2007. [2] M. A. Belkoura, “Performance analysis of distributed object-oriented computing techniques,” Master’s thesis, Texas Tech University, 1999. [3] P. K. Potti, S. Ahuja, K. Umapathy, and Z. Prodanoff, “Comparing performance of web service interaction styles: Soap vs. rest,” Conference on Information Systems Applied Research, vol. 5, pp. 1–24, 2012. [4] B. Suda, “Soap web services,” Master’s thesis, University of Edinburgh, 2003. [5] G. Hohpe and B. Woolf, Enterprise Integration Patterns Designing, Building, and Deploying Messaging Solutions. United States, Massachusetts: Pearson Education, 1 ed., 2011. [6] A. A. Almonaies, A Framework for Migrating Web Applications to Web Services. PhD thesis, Queen’s University, 2013. [7] N. M. Josuttis, SOA in Practice. United States: O’Reilly Media, 1 ed., 2007. [8] J. Musser, “Open apis: State of the market,” 2012. Disponible en http: //ProgrammableWeb.com/, 15/04/2017. [9] A. Hevia, “¿es necesario un esb hoy en día?,” 2010. Disponible en http:// www.pensandoensoa.com/2016/03/06/es-necesario-un-esb-hoy-en-dia/, 20/09/2016. [10] R. Daigneau, Service Design Patterns : Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services. United States, Massachusetts: Pearson Education, 1 ed., 2011.
40
[11] M. D. Rosales, “Arquitectura orientada a servicios,” Convención Científica de Ingeniería y Arquitectura CUJAE, vol. 1, pp. 1–10, 2008. [12] L. Rodríguez, A. Vignaga, and F. Zipitría, “Estudios de interoperabilidad .net/j2ee,” pp. 1–15, 2002. [13] L. M. S. Jaimes, J. O. P. Jaimes, and J. J. Méndez, “J2ee and. net platforms in the development of web services,” Revista Colombiana de Tecnologías de Avanzada, vol. 1, pp. 125–132, 2009. [14] A. Otero, J. C. Perez, L. de Seta, A. Casado, and J. Rubira, “Javahispano podcast - 035 - arquitectura soa y servicios web (soap/rest) 15/02/2009,” 2001. Disponible en http://www.javahispano.org/storage/podcasts/035_ JavahispanoPodcast_ServiciosWeb.mp3, 06/10/2016. [15] A. Otero and E. Camacho, “Javahispano podcast - 042 - noticias abril 2009 (a) 05/04/2009,” 2001. Disponible en http://www.javahispano. org/storage/podcasts/042_JavahispanoPodcast_Noticias0904_a.mp3, 06/10/2016. [16] S. P. Ahuja and A. Patel, “Enterprise service bus: A performance evaluation,” Communications and Network, vol. 3, pp. 133–140, 2011. [17] E. GEL-XML, H. B. Technology, R. C. Pinto, and J. C. G. Díaz, “Lenguaje común de intercambio de información,” tech. rep., Ministerio de Tecnologías de la Información y las Comunicaciones•, 2013. Colombia, Bogotá. [18] A. Hevia, “¿podríamos “saltarnos” el esb en ciertos casos?,” 2010. Disponible en https://pensandoensoa.com/2014/12/04/ podriamos-saltarnos-el-esb-en-ciertos-casos/, 03/03/2017. [19] J. Tihomirovs and J. Grabis, “Comparison of soap and rest based web services using software evaluation metrics,” Information Technology and Management Science, vol. 19, p. 92–97, 2016. [20] W3C, “World wide web consortium,” 2000. Disponible en http://www. w3c.org. [21] R. T. Fielding, Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, 2000. [22] H. Hamad, M. Saad, , and R. Abed, “Performance evaluation of restful web services for mobile devices,” International Arab Journal of eTechnology, vol. 1(3), pp. 72–78, 2010. [23] M. D. Rosales, “Arquitectura orientada a servicios,” Convención Científica de Ingeniería y Arquitectura CUJAE, vol. 1, pp. 1–10, 2008. [24] R. Z. Frantz, “Integración de aplicaciones,” tech. rep., Universidad de Sevilla, 2008. [25] D. R. Aremu and O. O. Adesina, “Web services: A solution to interoperability problems in sharing grid resources,” ARPN Journal of Systems and Software, vol. 1(4), pp. 141–148, 2011. [26] J. V. E. Beltrán, “Integración de procesos industriales mediante patrones soa y tecnología restful,” Master’s thesis, Universidad de Alicante, 2013. [27] C. Samsel, S. Gökay, PaulHeiniz, and K.-H. Krempels, “Web service to json-rpc transformation,” Proceedings of the 8th International Joint Conference on Software Technologies, vol. 1, pp. 214–219, 2013. [28] Y.-Y. Peng, S.-P. Ma, and J. Lee, “Rest2soap: a framework to integrate soap services and restful services,” National Science Council, vol. 1, pp. 1–4. [29] A. D. S. de la Cruz, “Una aproximación mda para la conversión entre servicios web soap y restful,” Master’s thesis, Universidad Complutense de Madrid, 2013. [30] G. E. Barchini, “Métodos ‘i + d’ de la informática,” Revista de Informática Educativa y Medios Audiovisuales, vol. 2(5), pp. 16–24, 2005. [31] R. H. Sampieri, C. F. Collado, and P. B. Lucio, Metodología de la investigación. México, México D.F.: McGraw-Hill/Interamericana, 4 ed., 2006. [32] A. A. V. Horna, Desde la Idea Hasta la Sustentación: Siete Pasos para una Tesis Exitosa. Un Método Efectivo para las Ciencias Empresariales. Perú, Lima: Universidad de San Martín de Porres, 2 ed., 2010. [33] SoapUI. Disponible en http://www.soapui.org/. [34] S. Hussain, Z. Wang, I. K. Toure, and A. Diop, “Web service testing tools: A comparative study,” School of Computer and Communication Engineering, pp. 1–7. [35] Apache TCPMon. Disponible en http://ws.apache.org/commons/ tcpmon/. [36] Lenguaje R and R. Disponible en https://www.r-project.org/. [37] RStudio. Disponible en https://www.rstudio.com/. [38] L. R. Ojeda, Probabilidad y Estadística Básica para Ingenieros. Ecuador, Guayaquil: Escuela Superior Politécnica del Litoral, 1 ed., 2007.
1
Estudio de Factibilidad T´ecnica Para la Migraci´on de la Radiodifusi´on Digital Terrestre en Onda Media con el Est´andar DRM 30 para Bolivia Christian Iv´an Pe˜na Dur´an Universidad Mayor de San Andr´es Facultad de Ingenier´ıa Ingenier´ıa Electr´onica cipena@umsa.bo
Abstract—Desde una visi´on t´ecnica, se ven todas las especificaciones requeridas; como ser: la estructura, los modos, y el sistema de trasmisi´on para el est´andar DRM 30. Adicionalmente, se plantea la asignaci´on de frecuencias para un modo h´ıbrido y digital, como tambi´en la potencia de transmisi´on para una estaci´on digital. Para concluir, se ven las relaciones de protecci´on y el estudio de interferencias co canal y canal adyacente. Se concluye, por un lado, que al digitalizar la radiodifusi´on sonora terrestre existir´a una renovaci´on de la programaci´on y una incorporaci´on de nuevos y mejores contenidos para una audiencia m´as exigente. Por otro lado, se recomienda que durante la transici´on digital, no s´olo se debe tomar en cuenta el aspecto t´ecnico, sino tambi´en el legal. Por lo tanto, se sugiere formar una comisi´on consultiva encargada exclusivamente de esta migraci´on. Keywords—migraci´on, est´andar, DRM, radiodifusi´on, digital, onda, media.
I.
´ I NTRODUCCI ON
La Digital Radio Mondiale es un est´andar de radio digital que ha sido dise˜nado por los organismos de radiodifusi´on, con la asistencia y participaci´on activa tanto de transmisores como de fabricantes de receptores, y otras partes interesadas como los organismos reguladores. Ha sido dise˜nado espec´ıficamente como un reemplazo digital de alta calidad para la radiodifusi´on anal´ogica actual en las bandas de AM; como tal, puede operar con las mismas asignaciones de canalizaci´on y espectro empleados en la actualidad.
El est´andar DRM describe un n´umero de diferentes modos de funcionamiento, que pueden ser ampliamente divididos en dos grupos de la siguiente manera: • Modos DRM 30, que est´an dise˜nados espec´ıficamente para utilizar las bandas de radiodifusi´on AM por debajo de 30 MHz . • Modos DRM + , que utilizan el espectro de 30 MHz a 300 MHz, centrada en la banda de radiodifusi´on de FM. DRM ha recibido las recomendaciones necesarias de la ITU, por lo tanto, proporciona el apoyo normativo internacional para las transmisiones. La norma principal DRM ha sido publicada por el ETSI. Incluso ETSI publica toda la gama de normas t´ecnicas actuales de DRM. II. C ARACTER´I STICAS T E´ CNICAS A. Funcionamiento del Sistema La Figura 2 describe el flujo general de las diferentes clases de informaci´on desde la codificaci´on, a la izquierda de la Figura, hasta un transmisor de sistema DRM, a la derecha. Aunque no se incluye una figura con un diagrama del receptor, e´ ste ser´ıa el diagrama inverso.
Fig. 2.
Fig. 1.
DRM - Digital Radio Mondiale
Diagrama a bloques de la transmisi´on de la se˜nal
A la izquierda hay dos clases de informaci´on de entrada: • Audio y datos codificados que est´an combinados en el multiplexor de servicio principal. • Canales de informaci´on que evitan el multiplexor y que se denominan FAC y SDC.
41
2
B. Ancho de Banda del Canal Digital Un modo de transmisi´on se define mediante tres (3) par´ametros: el ancho de banda del canal y los par´ametros relacionados con la eficiencia de transmisi´on, como son el orden de la constelaci´on y el tipo de modulaci´on OFDM. Las canalizaciones actuales para radiodifusi´on por debajo de los 30 [MHz] son de 9 o´ 10 [kHz] seg´un la regi´on terrestre. El sistema DRM se ha dise˜nado teniendo en cuenta estas canalizaciones y permite utilizar diferentes canalizaciones. El canal utilizado en la transmisi´on se define mediante un c´odigo de ocupaci´on espectral, con los valores de 0 a 5. Las canalizaciones posibles y los c´odigos correspondientes son los que se exponen a continuaci´on, y la representaci´on del ancho de banda es como aparece en la Figura 3. • La mitad de los anchos de banda nominales: para permitir una transmisi´on simulcast con se˜nales AM anal´ogicas: 4,5 o´ 5 [kHz] (c´odigos 0 o´ 1, respectivamente). • Anchos de banda nominales: 9 o´ 10 [kHz] (c´odigos 2 o´ 3, respectivamente). • El doble de los anchos de banda nominales: para una mayor capacidad de transmisi´on, siempre que las restricciones de planificaci´on permitan esta facilidad: 18 o´ 20 [kHz] (c´odigos 4 o´ 5, respectivamente).
Fig. 3.
Diferentes anchos de banda
Conviene destacar que la canalizaci´on empleada actualmente para la radiodifusi´on anal´ogica en onda media en Europa es de 9 [kHz]. En Bolivia, cada estaci´on de radio AM tiene asignado un ancho de banda de 10 [kHz]. El ancho de banda total dedicado a estaciones AM va desde los 535 hasta los 1.625 [kHz]. C. Ocupaci´on del Espectro La especificaci´on del sistema DRM 30 permite varios modos de robustez (A a D) y de tipos de ocupaci´on del espectro (0 a 5) de las se˜nales DRM. En este s´olo se utilizan determinadas combinaciones de modo de robustez y de tipo de ocupaci´on de espectro. Los par´ametros de las combinaciones de modo utilizadas, es decir, el correspondiente n´umero de sub portadoras y la separaci´on entre las mismas en la se˜nal OFDM dan lugar a las anchuras de banda que figuran en las filas A a D de la Figura 4. Las anchuras de banda de la u´ ltima fila de la Figura 4 son las anchuras de banda nominales de las respectivas ocupaciones de espectro de la se˜nal DRM 30 y los valores de las filas A a D son las anchuras de banda de se˜nal exactas para las diferentes combinaciones de modo.
42
Fig. 4. Anchura de banda (kHz) de las combinaciones de modos de robustez DRM 30
Las combinaciones de tipos de ocupaci´on de espectro y de modos de robustez dan lugar a varios espectros de RF del transmisor que causan niveles de interferencias distintos y que, por tanto, requieren relaciones de protecci´on de RF diferentes. D. Relaci´on Te´orica de la Se˜nal a Ruido La Figura 5 muestra las proporciones requeridas de la SNR para los cuatro modos de DRM 30 al operar en el canal 1. Una BER de 1 en 104 corresponde al punto en el que la calidad de audio subjetiva comienza a degradarse hasta el punto que se define como l´ımite de servicio. Tablas similares para los seis canales se enumeran tanto en la EBU TECH 3330 como en la ITU-R BS1514-2.
Fig. 5. S/N [dB] para conseguir una BER de 1x10−4 para todos los modos de robustez DRM con los tipos de ocupaci´on de espectro 2 o´ 3 (9 o´ 10 kHz) en funci´on del esquema de modulaci´on y del nivel de protecci´on para el modelo de canal No 1
Para las aplicaciones de radiodifusi´on simult´anea en una anchura de banda nominal de canal de 9 o´ 10 [kHz], son adecuados los tipos de ocupaci´on de espectro 0 y 1 del DRM. S´olo los modos de robustez A y B proporcionan esta caracter´ıstica.
Fig. 6. S/N [dB] para conseguir una BER de 1x10−4 para los modos de robustez A y B de DRM con los tipos de ocupaci´on de espectro 0 o´ 1 (4,5 o´ 5 kHz) en funci´on del esquema de modulaci´on y del nivel de protecci´on para el modelo de canal No 1
Para la aplicaci´on del modo de robustez A con los tipos de ocupaci´on del espectro 1 o´ 3, o del modo B con los tipos 0 o´ 2, tambi´en se recomiendan los valores de S/N de las Figuras 5
3
y 6 debido a que las diferencias en calidad de funcionamiento son inferiores a 0,1[dB]. A diferencia del modelo de canal No 1, el modelo de canal No 2 representa un modelo de propagaci´on en ondas hectom´etricas durante la noche que incluye, adem´as de la onda de superficie, una onda ionosf´erica retardada. E. C´alculo de la Intensidad de Campo M´ınima Como DRM 30 est´a dise˜nado para trabajar junto a los servicios de AM durante un tiempo considerable, el proceso de planificaci´on utilizado, est´a basado en los mismos principios y supuestos subyacentes como aquellos usos para los servicios de AM. Para los prop´ositos de planificaci´on AM, la Intensidad de Campo M´ınima - MFS se basa en: (1) Una SNR de audio de 26[dB] referido a un 30% de modulaci´on. (2) Una figura especulativa para el ruido global, vista por el receptor, y expresada como una intensidad de campo equivalente. Este campo de ruido es dependiente de la banda de frecuencia. La Figura 7 establece el procedimiento utilizado por la ITU para obtener las intensidades de campo de ruido recibidas, de las cuales las intensidades de campo m´ınimas resultantes para DRM 30 son calculadas sumando la SNR de datos requeridos.
Emin = 24, 5[dB] + 8, 6[dB] = 33, 1[dBµV /m]
(2)
Emin = 24, 5[dB] + 18, 7[dB] = 43, 2[dBµV /m]
(3)
La ecuaci´on 2 corresponde a una transmisi´on en Modo A2 (9[kHz]) usando un esquema de modulaci´on de 16 QAM, con un ´ındice de codificaci´on medio de 0,5 (16,4[kbps]). La ecuaci´on 3 corresponde a una transmisi´on en Modo A2 (9[kHz]) usando un esquema de modulaci´on de 64 QAM, con un ´ındice de codificaci´on medio de 0,78 (30,9[kbps]).
Fig. 8.
Intensidad de campo utilizable para Bolivia (digital)
Por tanto, la Figura 8 muestra los valores de intensidad de campo utilizables, considerando los tres grupos de frecuencias en la banda de amplitud modulada en onda media. El 1[dB] adicional en el ruido intr´ınseco del receptor es debido a que el ancho de banda DRM 30 es m´as grande en comparaci´on con el ancho de banda con doble banda lateral AM. F. C´alculo de la Potencia de Transmisi´on Para calcular la ERP por un transmisor se determina con la siguiente f´ormula: PERP [dBk] = PT X [dBk] + GAN T [dB] − LLIN E [dB] (4)
Fig. 7. Procedimiento para estimar la m´ınima intensidad de campo utilizable
La m´ınima intensidad de campo utilizable es el factor clave en cuanto a la cobertura. Esta se calcula mediante la adici´on del ruido intr´ınseco del receptor y de la CNR para un servicio satisfactorio. DRM 30 requiere un nivel de intensidad de campo muy inferior a la radio anal´ogica. Emin [dBµV /m] = RxN oisef loor + S/N
(1)
Considerando los valores de SNR de la Figura 5 y de la Figura 6, se sustituyen en la ecuaci´on (1), teniendo en cuenta la Figura 7, se obtiene:
Donde: PERP es la potencia radiante efectiva. PT X es la potencia del transmisor. GAN T es la ganancia de la antena. LLIN E es la p´erdida en la l´ınea de transmisi´on por adaptadores y acopladores. Caso Anal´ogico: Para una potencia de trasmisi´on de 1.000[W], una ganancia de antena de 0[dB] (5.16[dBi]) y una p´erdida en la l´ınea debido a conectores y acopladores de 0,5[dB]. Sustituyendo los valores en la ecuaci´on (4), se tiene: PERP [dBk] = 10 · log(1)[dBk] + 0[dB] − 0, 5[dB] PERP [dBk] = −0, 5[dBk]
(5) (6)
Caso Digital: Para una potencia de trasmisi´on de 400[W], una ganancia de antena de 0[dB] (5.16[dBi]) y una p´erdida en la l´ınea debido a conectores y acopladores de 0,5[dB]. Sustituyendo los valores en la ecuaci´on (4), se tiene: PERP [dBk] = 10 · log(0, 4)[dBk] + 0[dB] − 0, 5[dB] (7) PERP [dBk] = −4, 48[dBk]
(8)
43
4
G. Estudio de Interferencias en canal adyacente y co-canal Interferencia co-canal: La interferencia co canal viene causada por la presencia de se˜nales deseadas e interferentes en el mismo canal dentro de la anchura de banda del amplificador de frecuencia intermedia IF. Como ambas, la se˜nal deseada y la interferente se encuentran sobrepuestas, la se˜nal interferente no puede ser filtrada por m´etodos habituales. El nivel de interferencia en el co canal depende de dos caracter´ısticas, la primera del rechazo co canal del receptor y la segunda de la emisi´on del transmisor. La relaci´on de protecci´on absoluta cocanal para emisiones DRM a DRM est´a en el orden de los 16[dB] para una BER de 1x10−4 .
Fig. 9.
Se˜nales interferentes
Interferencia canal adyacente: Puede producirse interferencia de canal adyacente debido a dos aspectos, el primero al funcionamiento de una se˜nal interferente en el canal adyacente y el segundo, a las emisiones no esenciales del transmisor. El nivel de interferencia de canal adyacente depende de las caracter´ısticas de rechazo de radiofrecuencia RF del receptor. En este caso, no se han identificado se˜nales pr´oximas a la frecuencia de operaci´on autorizada que puedan crear interferencias, ni de co canal ni de canal adyacente. ´ D IGITAL III. T RANSMISI ON A. Se˜nal Transmitida Al elevar el nivel de esta se˜nal a la potencia requerida para la radiodifusi´on es imperativo que la relaci´on entre fase y amplitud correcta se mantenga. Si la se˜nal se distorsiona, la MER bien puede caer a niveles inaceptables, y en u´ ltima instancia la se˜nal DRM 30 ser´a inutilizable. V´ease la Figura 10.
44
Fig. 10.
Envolventes de radio frecuencia
La se˜nal DRM 30, como la de radiodifusi´on, se asemeja mucho a un ruido de banda limitada. Esto es una ventaja cuando se considera la relaci´on de protecci´on de los sistemas anal´ogicos interferidos por DRM 30, pero no cuando se trata de la amplificaci´on. La variaci´on estad´ıstica de tensi´on en la envolvente sigue, te´oricamente, una distribuci´on Rayleigh, pero en la pr´actica significa que se encuentra entre 10 y 11[dB]. Afortunadamente, para los modos DRM 30, las topolog´ıas de los transmisores actuales de AM pueden ser adaptadas para amplificar la se˜nal de DRM 30 en una manera eficiente. B. Transmisi´on Simulcast Canal Multiple La configuraci´on simulcast DRM permite ´ la transmisi´on simult´anea tanto de se˜nales de alta frecuencia anal´ogicas como digitales en DRM, utilizando un s´olo transmisor. El escenario menos dram´atico se basa en un per´ıodo transitorio de AM y los servicios de coexistencia DRM, preservando, en la medida de lo posible, la calidad de la infraestructura actual anal´ogica, su cobertura y su calidad en la recepci´on. Existen 9 modos en la norma DRM que definen diferentes anchos de banda para la parte anal´ogica y la parte digital de la se˜nal de emisi´on simult´anea. Los modos de transmisi´on simult´aneos, cuyo ancho de banda total es la de un solo canal AM, es decir, 9 o´ 10[kHz] dependiendo de la regi´on considerada por la ITU. Tradicionalmente han sido llamados SCS. Esos modos proporcionan un ancho de banda DRM que se limita a 4,5 o´ 5[kHz]. Esta reducci´on tiene una reducci´on directa tambi´en en la tasa de bits de audio disponibles. Por otro lado, el MCS se limita a asignar 9 o´ 10[kHz] a la parte digital DRM, a costa de que el ancho de banda total MCS debe ser de al menos 18[kHz].
Fig. 11.
Conguraci´on del espectro de la emisi´on simult´anea multicanal
Esta configuraci´on y sus implicaciones regulatorias deben ser analizadas por los reguladores. En la Regi´on 2, el ancho
5
de banda de canal para la radiodifusi´on AM es de 10[kHz] de acuerdo con las Actas finales de la conferencia administrativa regional de radiocomunicaciones para establecer un plan del servicio de radiodifusi´on en la banda 1.605 - 1.705[kHz] en la Regi´on 2 que permite la inserci´on de una se˜nal de emisi´on simult´anea MCS, como se ilustra en la Figura 11, en dos canales de AM. ´ Canal Unico: Una simple superposici´on de una se˜nal AM de DSB mediante una se˜nal digital DRM dar´ıa lugar a una fuerte degradaci´on de las dos se˜nales debido a las interferencias. Por lo tanto, los siguientes requisitos para la se˜nal SCS tienen que cumplirse: • La recepci´on de la se˜nal de DRM digital no debe ser distorsionada por la se˜nal anal´ogica en el mismo canal. • La caracter´ıstica de la se˜nal digital en el canal SCS tiene que ser compatible con la especificaci´on ETSI ES 201 980. • La demodulaci´on sobre el est´andar de la se˜nal transmitida SCS debe ser suficiente para impartir el programa de audio anal´ogico. • La calidad de la se˜nal de audio anal´ogica no debe ser notablemente influenciada por la se˜nal de DRM. Todos los requisitos son cumplidos por una caracter´ıstica de la se˜nal SCS como se describe en lo siguiente. La se˜nal consiste en tres partes. V´ease la Figura 12. 1. El grupo de portadoras DRM que contiene la informaci´on completa del FAC en la parte USB con el ancho de banda de 4,5 o´ 5[kHz]. 2. Una se˜nal complementaria con el mismo ancho de banda en la LSB. 3. Una portadora sinusoidal adicional en la frecuencia de referencia en el centro del canal.
Fig. 12.
Caracter´ısticas de una se˜nal DRM/AM simulcast canal u´ nico
Para mantener a los dos primeros requisitos, la se˜nal DRM ha de restringirse en ancho de banda, es decir, s´olo la mitad del canal puede asignarse; tipos de ocupaci´on del espectro 0 y 1. La se˜nal complementaria se determina en el modulador, de tal manera que la se˜nal recibida despu´es de la demodulaci´on de la envolvente de la se˜nal global SCS corresponder´a en condiciones ideales a la se˜nal anal´ogica de banda base de audio (tercer requisito), es decir, que tiene que minimizar la influencia de la se˜nal de DRM en la envolvente para agregar la parte anal´ogica de banda base de audio. Para proporcionar una calidad satisfactoria de la se˜nal de audio anal´ogica (´ultimo
requisito) la potencia de la USB, incluyendo la parte DRM, tiene que ser reducida en comparaci´on con la potencia de la LSB. Un ejemplo de la caracter´ıstica de espectro de la se˜nal resultante se da en la Figura 12. Se muestra el espectro de densidad de potencia de un se˜nal DRM/AM de SCS medida en la etapa de entrada de un receptor DRM. La profundidad de modulaci´on para la se˜nal anal´ogica AM se estableci´o a aproximadamente el 30% y la potencia de la USB se ha reducido en 18[dB] en comparaci´on con el veh´ıculo, es decir -18[dBc]. Dentro de la LSB el efecto de reflejo t´ıpico por la se˜nal DRM en el USB se puede ver claramente, adem´as de la parte AM cerca de la portadora. Si la energ´ıa de la USB se reduce a´un m´as, la se˜nal SCS resultante converger´a hacia una caracter´ıstica de SSB. C. Topolog´ıas de la Red Resdes de Frecuencia M´ultiple: La oferta de MFS es una soluci´on atractiva para proporcionar una cobertura de a´ rea amplia en situaciones donde la frecuencia de operaci´on no puede ser coordinada en todo el territorio deseado. Como se describi´o anteriormente, siempre que el mismo modo DRM se use para todas las transmisiones, entonces es posible, para un receptor de DRM, cambiar entre frecuencias sin roturas en el audio. Los requisitos de sincronizaci´on de red son pr´acticamente id´enticos a los que se requieren para una SFN. En un caso m´as general en el que el oyente puede ser llevado de transmisiones DRM a DRM, pero en diferentes bandas; y por lo tanto diferentes modos, o a un servicio de sostenimiento anal´ogico, las interrupciones de audio se pueden minimizar mediante el uso de receptores de doble front-end junto con cualquiera de las dos opciones: (a) una memoria intermedia en el receptor o (b) el uso de las redes de transmisi´on de retardo de concordancia. ´ Redes de Frecuencia Unica: Aunque las redes s´ıncronas anal´ogicas se utilizan pocas veces en MF y LF para proporcionar una cobertura extendida, siempre hay problemas con la interferencia mutua en las regiones de solapamiento, a veces conocido como ”´areas de ruido de fondo”. Esto por lo general requiere el uso adicional de frecuencias para complementar la cobertura en estas a´ reas. Las transmisiones de FM son particularmente susceptibles a trayectos m´ultiples, especialmente en est´ereo, y s´olo una red de frecuencia se utiliza en raras ocasiones, y luego bajo condiciones muy determinadas. Con un dise˜no cuidadoso, estos problemas pueden ser casi eliminados utilizando una red DRM SFN. Una vez recibidas las se˜nales, todas llegan dentro del intervalo de guarda que se refuerzan mutuamente, la recepci´on es mejorada en comparaci´on con un caso de un solo transmisor. Hay dos mecanismos separados que conducen a la mejora de la recepci´on. i. Aumento en la fuerza de transmisi´on como resultado del ”poder de suma” de los componentes individuales de transmisi´on (V´ease la Figura 13) ii. En las frecuencias de VHF, un fen´omeno conocido como ”ganancia de red” en la que la desviaci´on est´andar de
45
6
la media de intensidad de campo se reduce como resultado de las contribuciones de dos o m´as transmisiones recibidas por trayectos no co-relacionados.
boliviano, por permitir elevar la calidad del audio y ofrecer servicios adicionales de valor agregado, estos u´ ltimos constituyen adem´as una reactivaci´on del inter´es en los radiodifusores en la banda de la actual amplitud modulada con nuevos y mejores contenidos. Adem´as de esto, DRM 30 permite el uso eficiente del espectro mediante la implementaci´on de redes de frecuencia u´ nica, presenta grandes ventajas debido a que la suma de las se˜nales que recibe el receptor proveniente de dos o m´as transmisores, permite generar una ganancia en la red. Adem´as la infraestructura de radiodifusi´on es m´as barata y existe un menor consumo de potencia de los transmisores para una mejor cobertura. R ECONOCIMIENTO
Fig. 13.
Comparaci´on transmisi´on anal´ogica vs. digital
IV. C ONCLUSIONES En la actualidad, la radiodifusi´on sonora anal´ogica en onda media no tiene una buena calidad de sonido ya que sufre problemas de degradaci´on y acumula ruidos y distorsiones en su trayecto. Tampoco tiene una buena acogida en los sectores urbanos que es donde se tiene un n´umero potencial de oyentes. Al iniciar el proceso de digitalizaci´on en la banda AM, con el empleo de t´ecnicas digitales que incorporan m´etodos de correcci´on de errores, se obtiene una mejor calidad de sonido, adem´as de una mejor recepci´on fija y m´ovil, en consecuencia, una mayor audiencia. La radiodifusi´on digital terrestre, permite que en sus sistemas de transmisi´on se apliquen t´ecnicas de codificaci´on de canal, modulaci´on digital y el procesamiento de se˜nales puesto que se usan en la mayor´ıa de los est´andares. Por lo tanto, existe una mejora sustancial en la recepci´on del sonido, ya que los efectos provocados por la propagaci´on multitrayecto, debido a edificios u obst´aculos, son superados. En consecuencia, las interferencias que existen con las modulaciones anal´ogicas y digitales son eliminadas. El est´andar DRM 30 permite que el territorio boliviano ingrese dentro de un proceso de migraci´on progresivo, de la radiodifusi´on tradicional anal´ogica hacia la nueva era de la digitalizaci´on sonora. Con el est´andar elegido, es posible la reutilizaci´on de la infraestructura actual ya existente, lo que implica una reducida inversi´on en nuevos equipos para las estaciones, tan solo a˜nadiendo un excitador digital en la cadena de transmisi´on, ya es posible una transmisi´on digital b´asica. Igualmente, en el proceso de transici´on, DRM 30 puede funcionar tanto en modo h´ıbrido como en modo totalmente digital, transmitiendo se˜nales anal´ogicas y digitales sobre el mismo segmento del espectro radioel´ectrico. El est´andar de radiodifusi´on digital terrestre DRM 30 es la mejor opci´on en onda media para su aplicaci´on en el territorio
46
Por un lado, un fuerte reconocimiento al asesor de este proyecto el Ing. Juan Carlos Machicao Aparicio que cumple actualmente su labor como Director Ejecutivo Suplente en la ATT (Autoridad de Regulaci´on y Fiscalizaci´on de Telecomunicaciones y Transporte), por todo el apoyo brindado, por su calidad humana, por instruirme y guiarme a realizar este proyecto. Al docente asignado de la materia, el Ing. Jos´e F´elix Campero Bustillos, por guiarme con sus acertados consejos y aportar las mejoras constructivas al proyecto durante todo el periodo de elaboraci´on del mismo. Por otro lado, al los miembros del tribunal docente, el Ing. Wilber Flores Bustillos y el Ing. Freddy Valle Vel´asquez, por los comentarios emitidos y las aclaraciones brindadas durante la etapa final de redacci´on y defensa. Al director de la carrera, el Ing. Marcelo Ram´ırez Molina, por continuar con la mejora de la carrera y dar curso a la pronta actualizaci´on del Plan de Estudios. A todo el personal administrativo, el brazo operativo en nuestra facultad, por cumplir con su laboral cotidiana de manera ininterrumpida durante los u´ ltimos a˜nos. Finalmente, mi especial agradecimiento a esta casa de estudios superiores, la alma mater del conociemiento la cual me ha provisto del alimento intelectual durante todo este tiempo. R EFERENCES [1] [2] [3]
[4]
[5]
[6] [7] [8]
ABU (2005). RNZ - ABU Technical Investigations on Digital Radio in Medium Wave Band. Inf. t´ec. Asia-Pacic Broadcasting Union. ANGUIERA, P. (2009). “Update on studies and eld tests (DRM30)”. En: EBU/ DRM Workshop. Ed. por Universidad del Pa´ıs Vasco. ATT/ANPE/CP/2013/007 (2014). Determinaci´on de las a´ reas de servicio para los servicios de telecomunicaciones al p´ublico y radiodifusi´on. Ed. por ABS Consulting Group. url : http://www.abs-cgroup.com/ BERGER, G. (2010). Challenges and Perspectives of Digital Migration for African Media. Panos Institute of West Africa. ISRN : 978086104621. url: www.panos-ao.org BOCRA (2015). Technical specification for Radio Broadcasting Systems: DRM. Inf. t´ec. Botswana Communications Regulatory Authority. url: www.bocra.org.bw BRIGGS, J. (2003). Digital broadcasting below 30 MHz: DRM - A summary of the field tests. Inf. t´ec. EBU Technical Review. CABLE, J. (2006). “DRM - The BBC World Service distribution chain”. En: EBU Technical Review. ´ CADENA, L. y VASQUEZ D. (2007). “Migraci´on de la radiodifusi´on anal´ogica a la radiodifusi´on digital por debajo de los 30 MHz en el pa´ıs.” Escuela Polit´ecnica Nacional.
7
[9]
[10] [11]
[12]
[13] [14] [15] [16]
[17]
[18]
[19]
[20]
[21]
[22]
[23] [24]
[25] [26] [27]
[28] [29] [30] [31]
CARRILLO, E. (2012). “Estudio de la recepci´on de la se˜nal DRM (Digital Radio Mondiale) en onda media en base a pruebas de campo realizadas en Brasil”. Tesis doct. Universidad Nacional Aut´onoma de M´exico. CARTER, C. (2014). “Fostering digital radio in the world: The role of DRM”. En: The future of global radio. Ed. por Digital Radio Mondiale. CCRR-20 (2002). Special study, under No. 13.15 of the Radio Regulations, in relation to the Regional Agreements GE75, RJ81 and RJ88. Ed. por International Telecommunication Union. url: www.itu.int/ C.I.No 342 (2009). Documento de estudio y an´alisis para la implementaci´on de la radiodifusi´on digital en Colombia. Ed. por Centro de Investigaci´on de las Telecomunicaciones. CONSORTIUM (2015a). “Markets - A Snapshot”. En: The future of global radio. Ed. por Digital Radio Mondiale. CONSORTIUM, DRM (2009). Digital Radio Receiver Profiles. Ed. por The DRM Digital Broadcasting System. url: www.drm.org/. CORNELL, L. (2010). “Digital Radio Mondiale: DRM30, DRM+”. En: EBU Digital Radio Summit. Ed. por European Broadcasting Union. COSIC, M. (2013). “RJ81 and RJ88 Terrestrial Broadcasting Plans”. En: Americas Regional Radiocommunication Seminar 2013. Ed. por International Telecommunication Union. DEC.SUP, No 1391 (2011). Reglamento General a la Ley No 164 de 8 de Agosto de 2011, General de Telecomunicaciones, Tecnolog´ıas de Informaci´on y Comunicaci´on para el Sector de Telecomunicaciones. Ed. por Ministerio de Obras P´ublicas Servicios y Vivienda. url: www.oopp.gob.bo/ DELGADO, M. (2004). Transmisi´on de se˜nales de radio y televisi´on. En: Sistemas de Radio y Televisi´on (1o ed). Ed. por Paraninfo. Cap. 4, p´ags. 150 -181. url: www.paraninfo.es DEMEURE, C. (2002). New International Digital audio-broadcasting standard, voice coding and amateur radio applications. Thales Communications. DEMINCO, N. (2000). “Propagation prediction techinques and antennna modeling (150 to 1705 kHz) for Intelligent Transportation Systems (ITS) Broadcast Applications”. En: IEEE Antennas and Propagation Magazine. DETWEILER, J. (2011). “Conversion requirements for AM and FM IBOC transmission”. En: iBiquity Digital Corporation. Ed. por iBiquity Digital Corporation. url: www.nrscstandards. org/ DOC06/324-E (2002). Planning parameters for digital sound broadcasting at frequencies below 30 MHz. Inf. t´ec. International Telecommunication Union. DOC3J/140-E (2010). Measurments of medium wave field strenght in a dense urban area. Inf. t´ec. International Telecommunication Union. DOC6A/073-E (2008). Digital Radio Mondiale: DRM multi-channel simulcast, urban and in-door reception in the medium wave band. Inf. t´ec. International Telecommunication Union. DOC6E/175-E (2005). Digital Radio Mondiale: DRM Daytime MW tests. Inf. t´ec. Interna- tional Telecommunication Union. DOC6E/403-E (2006). Digital Radio Mondiale: MW Simulcast tests in Mexico D.F. Inf. t´ec. International Telecommunication Union. ERAZO, H. (2009). “Estudio y an´alisis de la tecnolog´ıa de redes de frecuencia u´ nica, y su aplicaci´on en la radiodifusi´on en las bandas de AM y FM para la optimizaci´on del espectro electromagn´etico en la ciudad de Quito”. Escuela Polit´ecnica Nacional. ETSI-ES201.980 (2014). DRM: System specification. Inf. t´ec. European Telecommunications Standards Institute. ETSI-TS102.509 (2006). DRM: Single Channel Simulcast. Inf. t´ec. European Telecommunications Standards Institute. ETSI-TS102.979 (2008). Journaline: User application specification. Inf. t´ec. European Telecommunications Standards Institute. ETSI-TS300.401 (2006). Radio Broadcasting Systems: DAB to mobile, portable and fixed receivers. Inf. t´ec. European Telecommunications Standards Institute.
[32] [33]
[34] [35] [36] [37] [38] [39] [40]
FERNANDEZ, I. (2011). “Estudio de la recepci´on del est´andar de radio digital DRM (Digital Radio Mondiale) en onda media en interiores”. Tesis doct. Universidad del Pa´ıs Vasco. FERREIRA, F. y MARIA J. (2011). Medic¸o˜ es de Campo do Sistema DRM30 (Digital Radio Mondiale) na Faixa de Ondas M´edias em S˜ao Paulo com a R´adio Cultura AM. Inf. t´ec. Instituto Nacional de Metrologia, Qualidade e Tecnologia. FUNES, K. (2008). “Estrategia de migraci´on hacia los formatos digital en el a´ rea de transmisi´on para la industria radiof´onica en El Salvador.” Universidad Don Bosco. GIL, U. y GUERRA D. (2008a). “DRM 20 kHz Simulcast Field Trials in the Medium Wave band in Mexico D.F.” En: IEEE Transactions on Broadcasting. GOEDERT, M. (2012). O futuro da R´adio AM e a digitalizac¸a˜ o da radiodifus˜ao no Brasil. Comiss˜ao de Ciˆencia e Tecnologia, Comunicac¸a˜ o e Inform´atica. GUIDE, DIGITAL RADIO (2006). Ed. por World Broadcasting Unions Technical Committee. url: www.worldbroadcastingunions.org/ HAAKINSON, E. y ROTHSCHILD S. (1988). MF Braodcasting System Performance Model. National Telecommunications Information Administration. HUBER, J. (2009). “DRM on MF and LF, coverage and technical requirements”. En: EBU Digital Radio Summit. Ed. por European Broadcasting Union. ITU-R.BS1196-5 (2015). Audio coding for digital broadcasting. Inf. t´ec. International Telecommunication Union.
˜ Dur´an Recibi´o el grado de Christian Iv´an Pena Ingeniero Electr´onico especializado en Sistemas de Telecomunicaciones el mes de Noviembre del 2017 de la Universidad Mayor de San Andr´es, La Paz Bolivia. Entre los a˜nos 2014 y 2015, por un lado, fue Auxiliar de Investigaci´on coadyuvando con la planificaci´on, ejecuci´on y evaluaci´on de los proyectos de investigaci´on, en calidad de apoyo t´ecnico en los distintos programas cient´ıco - acad´emicos para el Instituto de Electr´onica Aplicada perteneciente a la Facultad de Ingenier´ıa. Por otro lado, fue Delegado Tribunal de Competencias para Docentes siendo Miembro de la Comisi´on Docente Estudiantil. Entre los a˜nos 2012 y 2013 fue Auxiliar de Investigaci´on e Interacci´on Social realizar el mantemiento del sistema de transmisi´on de datos via internet desde Chacaltaya. Apoyando al personal cient´ıfico - t´ecnico a n de garantizar el adecuado funcionamiento de los equipos y el correcto acopio de datos para su posterior transmisi´on a los centros de investigaci´on involucrados para el Instituto de Investigaciones F´ısicas perteneciente a la Facultad de Ciencias Puras y Naturales. Contacto: Skype, Twitter, Telegram: cipenad M´ ovil: +(591) 706-7-123-3 E-mail: cipena@umsa.bo
47
48
1
Modulaciones en Amplitud y Frecuencia en base a GNU Radio Mejillones Perca, Anthony Pablo. apmejillones@gmail.com Universidad Mayor de San Andrés Facultad de Ingeniería-Instituto de Electrónica Aplicada (IEA)
Resumen—La tecnología en el campo de las
telecomunicaciones han ido evolucionando de gran manera debido a la demanda de las personas, por la necesidad a la comunicación, entonces con el avance de esta tecnología surge la tecnología SDR, que es capaz de llevar las funciones de hardware a software funciones como la modulación, filtrado, codificación, entre otros. En ese entendido la presente investigación se desarrolló con el objetivo de diseñar sistemas de modulación en software a través de GNU Radio que es un software libre. El presente trabajo es útil tanto en el área académica como dentro del área de investigación, debido a que muchos de los sistemas de modulación que en su inicio se desarrollaron en hardware, a través de GNU Radio pueden ser realizados en un entorno de simulación lo que conlleva facilidades como un menor costo y portabilidad. Dentro del área académica es provechoso ya que se puede realizar un análisis en cada sistema de modulación en cuanto a tiempo y frecuencia.
Índice de Términos—SDR, GNU Radio, Modulación, Tiempo, Frecuencia, Tasa de Muestreo, Portadora. I. INTRODUCCIÓN El desarrollo de los sistemas de modulación a través de software es bastante útil, ya que cubrirá la necesidad de experimentar en un sistema de modulación real, sin la necesidad de impleméntalo en un laboratorio, al mismo tiempo facilitará la comprensión de los diferentes sistemas de modulación, debido a que es importante para estudiantes del área de telecomunicaciones y en su formación como ingenieros , ya que los sistemas de modulación que se analizarán son la base para el desarrollo actual de la tecnología que apreciamos. Partiendo de ese entendido se pretende cubrir conceptos fundamentales como las diferencias entre una portadora y una señal de información y su importancia dentro de la modulación. Se empleará la interfaz gráfica de GNU Radio
que es GNU Radio Companion (GRC), ya que la misma brinda una gran plataforma digital para el diseño de las modulaciones porque además es una gran herramienta para la experimentación, al mismo tiempo para poder hacer un uso apropiado de GRC es importante, tener conceptos suficientemente claros en telecomunicaciones y procesamiento digital de señales. II. MODELO DEL SISTEMA DE COMUNICACIÓN La mayoría de los sistemas de comunicación operan modulando una onda de información en una portadora sinoidal, la característica principal que se debe destacar es que la frecuencia de la portadora de la señal transmitida, no es el componente que contiene la información, teniendo ese enfoque, es importante establecer un método de caracterización de señal, el cual sea independiente de la frecuencia de la portadora [1]. En ese entendido para caracterizar los métodos de modulación sin incursionar en las frecuencias elevadas de portadoras como las de AM y FM, se utilizará el concepto de señales de paso de banda y señales de pasa bajos. III. SEÑALES DE PASA BAJOS Y PASO DE BANDA
Una señal pasa bajos es una señal en la cual el espectro (contenido de frecuencia) de la señal está localizado alrededor de la frecuencia cero. Una señal de paso de banda es una señal con un espectro alejado de la frecuencia cero. Así el espectro de frecuencia de una señal de paso de banda esta usualmente localizado alrededor de la frecuencia de la portadora, lo cual es mucho más alta que el ancho de banda de la señal, lo que quiere decir que el ancho de banda de la señal de paso de banda es usualmente mucho menor que la frecuencia de portadora, el caso extremo de una señal de banda de paso es una señal
49
2
de frecuencia única con frecuencia de portadora [2], el ancho de banda de esa señal es cero y se escribe como ecuación 1. ݔሺݐሻ ൌ ݏܿܣሺʹߨ݂ ݐ ߠሻ
A continuación se muestra los gráficos de tiempo y frecuencias obtenidos del diagrama de flujo anterior:
(1)
Para realizar los distintos sistemas de modulación se usarán señales de paso de banda, ya que para el análisis que se realizará, la información no está contenida en la frecuencia de la portadora. Figura 2. Onda Modulada en Amplitud
IV. MODULACIÓN AM.
En la modulación por amplitud la portadora es proporcional a la amplitud instantánea de la señal modulante. De esta manera la señal modulante original es producida como una envolvente que varía modificando a la onda portadora. Para realizar la implementación de la modulación de amplitud en GNU Radio Companion, se usó como referencia las ecuaciones que describen la forma de onda de una señal modulada en amplitud [3]. ݒ ሺݐሻ ൌ ሺܧ ܧ ሺʹߨ݂ ݐሻሻሺ ሺʹߨ݂ ݐሻሻ
(2)
Donde: ሺܧ ܧ ሺʹߨ݂ ݐሻ: Amplitud de la onda modulada ܧ : Cambio máximo de amplitud de la envolvente (volts) ݂ : Frecuencia de la señal moduladora (hertz)
Lo cual se describe en el siguiente diagrama de flujo, mostrado en la figura 1.
Figura 3. Espectro de Modulacion AM
A. Cálculo de Potencia individual de cada componente de la señal AM El conjunto de bloques que se muestra en la figura 4, tiene el objetivo de poder adquirir por separado la potencia de portadora, potencia de la señal de la frecuencia de lado superior e inferior, de la siguiente manera: ݒ ሺݐሻ ൌ ܧ ሺʹߨ݂ ݐሻ (3) ݉ܧ െ ሺʹߨሺ݂ ݂ ሻݐሻ ʹ ݉ܧ ሺʹߨሺ݂ െ ݂ ሻݐሻ ʹ
Donde: ܧ ሺʹߨ݂ ݐሻ : Señal portadora (volts)
െ
ா ଶ
ሺʹߨሺ݂ ݂ ሻݐ: Señal de la frecuencia de
lado superior (volts)
Figura 1. Modulación AM
50
3
ா ଶ
ሺʹߨሺ݂ െ ݂ ሻݐ: Señal de la frecuencia de
lado inferior (volts) [3].
Como dicho valor es numérico solo se necesita el bloque NUMBER SINK. Lo cual se aprecia en Figura 5.
Figura 5. Potencias de portadora, bandas laterales e índice de modulación Figura 4 Diagrama de flujo cálculo de potencias
Partiendo del cálculo de potencia de una señal cabe resaltar que a lo largo del presente artículo, en algunos momentos se preferirá que las señales sean consideradas y analizadas independientemente de las unidades físicas, pero sin embargo no serán despreciadas. La amplitud de cualquier señal será medida en voltios y la potencia se mide generalmente en watts. La mayoría de las señales que se consideran son voltajes o corrientes, por lo que para obtener una potencia en las unidades apropiadas se necesita especificar una resistencia. Por tal motivo para simplificar la notación y para mantener un análisis más enfocado en las señales, con el objetivo de obtener la potencia de alguna señal x (t) medida en Voltios se optará por una resistencia igual a la unidad (R = 1Ω) [2]. Para la obtención del voltaje efectivo, GNU Radio cuenta con un bloque denominado RMS, que a su salida, obtiene el valor eficaz de la señal de entrada, una vez teniendo ese valor se lo eleva al cuadrado para obtener la potencia en watts, tal y como se lo realiza en el diagrama de flujo, para las tres componentes de la señal AM [4]. B. Cálculo del índice de Modulación
V.
MODULACIÓN FM.
Una onda con modulación angular se describe matemáticamente como sigue: ݉ሺݐሻ ൌ ܸ ሺ߱ ݐ ߠሺݐሻሻ
(5)
Donde: ݉ሺݐሻ= Onda con modulación angular ܸ = Amplitud máxima de portadora (volts) ߱ = Frecuencia de la portadora en radianes, es, decir, velocidad angular, ʹߨ݂ en radianes por segundo ߠሺݐሻ= Desviación instantánea de fase (radianes)
La magnitud y la dirección del desplazamiento de frecuencia, ߂݂, es proporcional a la amplitud y la polaridad de la señal moduladora, ܸ , y la rapidez con la que suceden los cambios de frecuencia es igual a la frecuencia ݂ de la señal moduladora [3].
El índice de modulación que es calculado y generado por el bloque CONSTANT SOURCE que en su interior posee la variable:
.
݉ൌ
݉ܧ ܿܧ
(4) Figura 6. Onda con modulación angular en el dominio de la frecuencia
51
4
Partiendo de ese concepto mostrado en la Figura 6. Para obtener la desviación de frecuencia, se debe cumplir la siguiente ecuacion 6: ݉ሺݐሻ ൌ ܸ ሾ߱ ݐ
ܭଵ ܸ ሺ߱ ݐሻ ሿ ߱
moduladora tiene mayor amplitud, la frecuencia también es elevada.
(6)
Esta señal es representada a través del bloque SIGNAL SOURCE. Debido a que se trata de la señal moduladora, como se muestra en la figura 7.
Figura 9. Modulación FM respecto al tiempo
En cuanto a la frecuencia se puede identificar su espectro, destacando que también corresponde a la función de Bessel.
Figura 7. Diagrama de flujo representando la desviación de amplitud
En primera instancia, para obtener la desviación de frecuencia, es necesario generar una desviación de amplitud como muestra la señal moduladora. Para lo cual se realiza una desviación de amplitud a través del bloque ADD CONST, este resultado de desviación de amplitud se denominó desviación de moduladora o mencionado a través del bloque VIRTUAL SINK como moduladora_desv. Dicha salida es introducida al bloque VCO, que es un Oscilador Controlado por Voltaje, que produce una determinada frecuencia cuando se introduce un determinado voltaje como amplitud, por lo cual podemos obtener una desviación de frecuencia si se introduce una desviación de amplitud, como se muestra en la figura 8.
Figura 10. Espectro de Frecuencia FM
A partir de la señal moduladora también podemos obtener su potencia, y también el índice de modulación.
Figura 11. Índice de Modulación y Potencia
VI. MODULACIÓN ASK
La técnica de modulación digital más sencilla es la modulación digital de amplitud, que no es más que modulación de amplitud con portadora completa y doble banda lateral. La ecuación 7, que describe la modulación digital de amplitud mediante una señal binaria es: ܣ (7) ݒሺݐሻ ൌ ሾͳ ݒሺݐሻሿሾ ܿ ݏሺ ߱ ݐሻ ሿ ௦
Figura 8. Diagrama de flujo modulador de frecuencia y cálculo de potencia
A partir del diagrama de flujo de la figura 8, se obtienen los siguientes gráficos, respecto al tiempo se puede ver una variación clara, cuando la onda
52
ʹ
ୟୱ୩ ሺ ሻ: Voltaje de la onda de amplitud modulada
Ȁʹ: Amplitud de la portadora no modulada (volts)
୫ ሺ ሻ: Señal binaria moduladora (volts) ɘୡ :
Frecuencia de la portadora en radianes (radianes por segundo)
5
La portadora esta “encendida” o “apagada”, y es la causa de que a la modulación digital de amplitud se le suela llamar modulación por manipulación encendido-apagado, o todo o nada (OOK, de on-off keying) [3]. A continuación se muestra el diagrama de flujo de la modulación ASK, en la entrada se tienen dos fuentes de informacion, que modularan la señal portadora, estas señales son una cuadrada y la otra una señal de un vector.
Figura 14. Modulación ASK respecto a frecuencia
VII. MODULACIÓN FSK.
La manipulación por desplazamiento de frecuencia es otro tipo relativamente sencillo y de baja eficiencia de modulación digital. La FSK binaria es una forma de modulación de ángulo, de amplitud constante, parecido a la modulación convencional de frecuencia (FM), pero la señal moduladora es una señal binaria que varía entre dos valores discretos de voltaje, y no es una forma de onda analógica que cambie continuamente. La ecuación general de la FSK binaria es: ܸ௦ ሺݐሻ ൌ ܸ ሺ ʹߨሺ݂ ݒ ሺ ሻ ȟ ሻ ሻ
Figura 12. Diagrama de flujo modulación ASK
A partir de allí conseguimos la gráfica respecto al tiempo, en este caso se trabajó con la interfaz gráfica WX, como se mencionó la modulación tiene una forma de onda de portadora de encendido o apagado.
(8)
ܸ௦ ሺݐሻ= forma de onda binaria FSK ܸ = amplitud de la portadora (volts) ݂ = frecuencia central de la portadora (hertz) ȟ =desviación máxima de frecuencia (hertz) ݒ ሺ ሻ = señal moduladora de entrada binaria (±1)
Con una FSK binaria, la señal binaria de entrada corre (desvía) a la frecuencia de la portadora. Cuando la señal binaria de entrada cambia de un 0 lógico a un 1 lógico y viceversa, la frecuencia de salida se desplaza entre dos frecuencias: Figura 13. Modulación ASK respecto al tiempo
También se obtiene el gráfico del espectro de frecuencia de la modulación ASK.
-
Frecuencia de marca, frecuencia de trabajo: frecuencia de 1 lógico (݂ ). Frecuencia de espacio: frecuencia de 0 lógico (݂௦ ).
Las frecuencias de marca y de espacio están separadas de la frecuencia de portadora por la desviación máxima de frecuencia, es decir, por ݂ േ ȟ . Sin embargo, es importante observar que las
53
6
frecuencias de marca y de espacio se asignan en forma arbitraria, dependiendo del diseño del sistema [3].
A continuación se muestra la modulación FSK respecto al tiempo, para lo cual se consideró dos entradas una cuadrada, y la otra un vector.
Para realizar la modulación FSK, en GNU Radio, es bastante similar a la modulación FM, con algunas restricciones en la entrada de datos para producir una desviación de amplitud propia de una señal moduladora digital, que posteriormente se convertirá en desviación de frecuencia con el empleo del bloque VCO. En primera instancia se definen las variables de entrada de frecuencia de portadora y la desviación de frecuencia con el nombre de freq_port y desv_frec respectivamente, para ello se emplea los bloques, WX GUI Slider, para definir variables que puedan ser modificadas durante la simulación, a partir de allí también se obtiene las variables de frecuencia de marca y frecuencia de espacio en los bloques VARIABLE, con su identificación de freq_m y freq_s.
Figura 17. Señal FSK para un vector de entrada
Es importante mencionar en las forma de onda que se diseñó, ya que la misma tiene una frecuencia elevada cuando el vector tiene un voltaje mayor en otro caso tiene una menor frecuencia, que es la frecuencia de espacio.
Figura 15. Definición de variables para la modulación FSK
Una vez que se tienen las variables, se introducen las señales moduladoras, la primera una señal cuadrada y la otra es un vector, posteriormente a través del bloque ADD CONST, se realiza la desviación de amplitud adicionando el valor de la frecuencia de espacio, de esta manera se producirá una desviación de frecuencia a través del VCO, de tal manera que se encuentre en el rango de frecuencia de marca y frecuencia de espacio.
Figura 18. Señal FSK para una señal cuadrada de entrada
Para concluir el análisis de FSK, se procede a presentar el espectro de frecuencia de la señal FSK, que muestra a las dos frecuencias una de marca y la otra de espacio.
Figura 19. Espectro de frecuencia señal FSK Figura 16. Diagrama de flujo modulación FSK
54
7
VIII. CONCLUSIONES Es importante realizar una serie de análisis en los distintos sistemas de modulación ya que ellos son la base para las tecnologías actuales, en ese sentido implementar dichas modulaciones en software es de mucho beneficio en el área académica y de investigación, ya que no existe la necesidad de estar en un laboratorio físico, o implementar circuitos de para obtener las modulaciones mencionadas. Un aspecto importante es que la realización de las distintas modulaciones, también pueden ser utilizadas con un dispositivo de hardware como los USRP, de esta manera también se tendría una experiencia real de las modulaciones trabajadas. REFERENCIAS [1] M. Fitz, Fundamentals of Communications Systems, The McGraw-Hill, 2007. [2] J. G. Proakis y M. Salehi, FUNDAMENTALS OF COMMUNICATION SYSTEMS, Pearson Education, 2014. [3] W. Tomasi, Sistemas de Comunicaciones Electrónicas, PEARSON EDUCACIÓN, 2003. [4] P. Mathys, «Power Spectral Density, Noise, and Symbol Timming Information,» 2017.
55
56
PROTOTIPO INICIAL DE UNA PRÓTESIS MIOELÉCTRICA DE LA MANO Bryan Alfonso Saravia Quisbert Facultad de Ingeniería, Instituto de Electrónica Aplicada Universidad Mayor de San Andrés La Paz, Bolivia bsaraviaq@gmail.com
Resumen Abstract— Hoy en día vemos que la tecnología ha avanzado a un nivel muy alto, y esto ha repercutido en varias disciplinas, y la medicina no es una excepción. Si por alguna razón una persona pierde una extremidad del cuerpo como ser la mano, esta llega a ser reempla- zada artificialmente por una prótesis, pero en un princi- pio la implantación de una prótesis tenía generalmente un propósito estético, es decir no tenía funcionalida- des propias. Luego se paso a una prótesis mecánica, las cuales podían realizar tareas o actividades senci- llas. Ahora se da paso a las prótesis mioeléctrica, que son controladas por una señale mioeléctrica. Este tipo de prótesis tienen el mayor grado de rehabilitación de- bido a la complejidad de su funcionamiento.
Figura 1. Esquema representativo del movimiento
2. SEÑALES ELECTROMIOGRÁFICAS 1. INTRODUCCION Desde ya hace muchos años se ha utilizado las prótesis para reemplazar partes del cuerpo perdidos, generalmente para una mano o para una pierna. Pero el sim- ple hecho de reemplazar no es suficiente, el que la mis- ma prótesis tenga funcionalidades propias, que en este caso si hablamos de una prótesis para una mano nos re- ferimos a funcionalidades electromecánicas. El realizar movimientos cotidianos como escribir o caminar son acciones bastante complejas que realiza el cerebro. El cerebro se encarga de coordinar estos movimientos complejos y manda las señales para que es- tos movimientos se realicen. Las señales que manda el cerebro son señales eléctricas y es la base del funciona- miento de este prototipo inicial de prótesis mioeléctrica de la mano.
La manera en la que se realiza cualquier movimien- to del cuerpo es la siguiente: en principio el cerebro manda una señal eléctrica a través de la medula espi- nal y después se dirige a la Unidad Motora (UM), que se conforma a partir de en una Motoneurona y una Fibra muscular. La Motoneurona se encarga de captar la señal eléctrica y la fibra muscular de reaccionar ante la señal eléctrica captada. La explicación se ilustra en la Fig. 1. Las señales que se presentan en los músculos se las conocen como señales Electromiográficas (EMG). En la Fig. 2 (a) se ilustra la forma de la señal electro- miográfica. Entre las características más importantes de una señal EMG son la frecuencia y la potencia eléctri- ca. La frecuencia de la señal EMG se encuentra alrede- dor de los 50[Hz] y la potencia eléctrica oscila entre los 50[uV] hasta los 5[mV], estas características podemos observarlas en la Fig. 2 (b).
57
(a) Señal electromiográfica
(a) Electrodos desechables (b) Caracteristica de una señal electromiográfica
Figura 2. Señales electromiográficas
3. ADQUISICIÓN DE SEÑALES EMG 3.1. Electrodos
(b) Pocisión de los electrodos
El método de adquisición de señales EMG se la realizan primeramente utilizando electrodos desechables (Fig. 3 (a)), estos se encargaran de captar las señales eléctricas de los músculos y el lugar en donde aplicar- los se lo ilustra en la Fig. 3 (b).
Figura 3.
3.2. Electromiógrafo modificado El Electromiógrafo se encarga de tomar la señal EMG y procesarla de manera tal que pueda ser útil pa- ra el funcionamiento de la prótesis de la mano. El dia- grama de bloques del electromiógrafo modificado se lo muestra en la Fig. 4.
3.3. Diseño del electromiógrafo 3.3.1. Etapa de pre-amplificación. Para esta etapa se utiliza la configuración un amplificador de instrumentación (AI), con una ganancia de A=10, para lo cual utilizaremos la siguiente ecuación: 50[KΩ] RG = A− 1 RG = 5,6[KΩ] Obtenemos el circuito mostrado en la Fig. 5.
58
Figura 4. Esquema del electromiógrafo modificado
Figura 5. Amplificador de instrumentación
Figura 7. Circuito de realimentación
Figura 6. Circuito integrador Debido a que la señal presenta un offset, es necesario aplicar un circuito integrador para eliminar este offset de la señal EMG. Este integrador también es un filtro pasa bajos, por tanto debemos diseñarlo según la máxima frecuencia que presente la señal EMG, que es de 500 [Hz] entonces: 1 fc = Para C=0.1[µF]
2πRC
= 500[Hz]
R = 270[KΩ] El circuito integrador puede observarse en la Fig.6. 3.3.2. Circuito de retroalimentación. Para tomar las señales EMG es necesario realizar una realimentación por la referencia, el circuito se muestra en la Fig. 7, ade- más se añade una salida adicional, la Malla, cuya función es de evitar corrientes de fuga que pudiera ocurrir entre los conductores de los electrodos. 3.3.3. Etapa de amplificación. Ahora aplicaremos la última amplificación a la señal, con una configuración no inversora, y con una ganancia de A=10. RF = (A− 1)R
Figura 8. Imagen de la señal captada por el osciloscopio en la Salida AI. Con R=10K
RF = 90[KΩ]
En la Fig. 9 y Fig. 10 se observan el circuito y la señal de salida. 3.3.4. Etapa de filtrado. En la etapa de filtrado debe- mos tomar en cuenta el rango de frecuencias de la señal EMG, nos referimos entre el rango de 20[Hz] hasta los 500[Hz]. Para esta etapa utilizaremos la configuración de filtro de Butterworth, para un filtro pasa bajo y pasa alto. Para el diseño del filtro pasa bajo utilizaremos la siguiente ecuación: 1 Para C=0.1[µF]
fc =
2πRC
= 20[Hz]
R = 82[KΩ]
Para el diseño del filtro pasa alto utilizaremos la siguiente ecuación: fc =
1 2πRC
= 500[Hz]
Para C=0.1[µF] R = 3,3[KΩ]
59
Figura 11. Filtro pasa bajos.
Figura 9. Circuito amplificador no inversor
Figura 12. Filtro pasa altos. Los circuitos pasa bajos, pasa altos y la señal de salida se la aprecian en la Fig. 11, Fig. 12 y Fig.13. 3.3.5. Comparador. El comparador se encargará de entregar señales digitales al conversor de frecuencia voltaje. Elcircuito y la señal de salida se aprecian en la Fig. 14 y Fig. 15.
Figura 10. Imagen de la señal captada por osciloscopio en la Salida Amp.
el
3.3.6. Conversor de frecuencia. El conversor se encargará de detectar si la frecuencia de oscilación es de 50[Hz], si es así mandara una señal digital (nivel alto). Para que el conversor pueda medir hasta la frecuencia de 50[Hz], se usa la siguiente ecuación: 1 = 50[Hz] fc = RC Para C=0.1[µF] R = 200[KΩ] En la Fig. 16 de observa el circuito conversor.
60
Figura 13. Imagen de la señal captada por el osciloscopio en la Salida pasa altos..
Figura 17. Esquema del control del prototipo.
Figura 14. Circuito comparador.
Figura 15. Imagen de la señal captada por el osciloscopio en la Salida Comp.
4. CONTROL PARA EL PROTOTIPO DE PRÓTESIS Para el control utilizaremos un PIC 18f4550, a quien lo denominaremos como el PIC maestro y un PIC 16f628a a quien lo denominaremos como PICesclavo. El PIC maestro tomara como entradas la salida del electromiógrafo, y los sensores de presión (pulsadores) que se encuentra en la punta de los dedos de la próte- sis. Y las salida son un canal de comunicación serial (USART) para transmitirle la posición de los servomo- tores, quienes se encargan de flexionar los dedos de la mano y la otra salida es para controlar la posición del último servomotor encargado de extender todos los dedos. El PIC esclavo tiene como entrada un canal de comunicación serial (USART) para recibir la transmisión del PIC maestro, y como salida tiene las señales de po- sición de los servomotores.
5. PRÓTESIS MECÁNICA
Figura 16. Circuito conversor de frecuenciavoltaje.
La prótesis mecánica contara con una serie de servomotores y sensores de presión (pulsadores), dispues- tos de la siguiente manera como muestra la Fig. 18. Se contará con 5 servomotores para controlar la flexión de los dedos (un servomotor por cada dedo), y otro servo- motor se encargará de extender los 5 dedos. Cada dedo cuenta con un sensor de presión (pulsador).
61
(a) Vista frontal
Figura 19. Esquema de la prótesis mioeléctrica de la mano. (b) Vista superior
Figura 18. Imagen del prototipo mecánico
6. PROTOTIPO La prótesis mioeléctrica contara con funcionalidad propia, que será regido por un sistema de control, cuya entrada es la salida del Adquisidor de señal EMG. Uniendo todos los bloques, el adquisidor de seña- les EMG, el controlador de la prótesis y la prótesis me- cánica obtendremos la siguiente interacción entre ellos ilustrado en la Fig. 19.
7. DESCRIPCIÓN MIENTO
DEL
FUNCIONA-
El funcionamiento del prototipo será regido por la señal EMG, el electromiógrafo leerá esta señal y se obtendrá a la salida un “1 lógico” indicando que los dedos de la prótesis tienen que flexionarse, o un “0 lógico” para indicar que se deben extender extienda. Esta sali- da será leída por el PIC maestro y enviara la posición de los servomotores por el canal de transmisión al PIC esclavo y también modificará la posición del servomo- tor encargado de extender los dedos. Si alguno de los sensores de presión (pulsadores) de alguno de los dedos es activado, el servomotor que controla dicho dedo se detendrá en su movimiento.
8. CONCLUSIONES En este artículo se diseñó un prototipo inicial para una prótesis de la mano, el cual demostró la factibili-
62
dad de realizar una prótesis que tenga una funcionalidad propia, en este caso funciones electromecánicas. El desarrollo de este artículo se ha centrado solo en movimientos básicos de extender o flexionar los dedos de la mano de la mano, pero con un mayor desarrollo del prototipo es posible lograr una prótesis que realice mas movimientos, aumentando el número de sensores en la prótesis o un electromiógrafo más desarrollados. La electrónica es la base fundamental para la implementación de este tipo de prótesis, tanto en el momento de captación de señales EMG como en el sistema de control, ello demuestra que la electrónica tiene una gran aplicación y utilidad en el campo de la medicina.
9. RECONOCIMIENTOS Gracias a la siguiente bibliografía desarrollada por distintos autores este prototipo ha sido desarrollado.
Referencias [1] ELECTROMYOGRAPHY Physiology, Engineering and Noninvasive Aplication, editado por Roberto Marletti, Philip Parker IEEE. [2] Electromyography (EMG) editado por Richárd Fiáth, György Karmos, Universidad Catolica Peter Pazmany. [3] Diseño y construcción de un sistema para la detección de señales electromiográficas editado por Irving Cifuentes Gonzales. [4] Diseño y simulación de sistemas microcontrolados en lenguaje C editado por Juan Ricardo Clavijo Mendoza. [5] Datasheet LM2917 de National Semiconductors. [6] Datasheet microcontrolador PIC18f4550 de Microchip. [7] Datasheet microcontrolador PIC16f628a de Microchip.
SISTEMA PARA MONITOR DE PARKINSON Edgar Gonzales Laura Facultad de Ingeniería, Instituto de Electrónica Aplicada Universidad Mayor de San Andrés La Paz, Bolivia edgarcatavi@hotmail.com
Resumen Abstract— Este artículo rescata información adquirida en base a un requerimiento que una persona particular para un monitor de Parkinson, para lo cual mi persona investigó y está realizando un prototipo. Se presenta el desarrollo electrónico con componentes que se encuentran en el mercado local. Todavía se encuentra en fase de investigación, posiblemente se pueda realizar un proyecto de grado con algún alumno de ingeniería electrónica.
1. INTRODUCCION La electrónica se presenta en la vida cotidiana en dispositivos de uso común. Una de las líneas de investigación que me gusta es el área de electrómedicina. El objeto de este artículo es presentar mi investigación inicial, para compartir con la comunidad las investigaciones que vengo encarando en el I.E.A.
2. La enfermedad del Parkinson La enfermedad de Parkinson, también llamada EP, es la segunda enfermedad neurogenerativa más común despúes del Alzhaimer. Afecta a personas de avanzada edad, también en poca medida a jóvenes. Los síntomas son: temblor, rigidez, lentitud de movimiento más inestabilidad de la postura. Más información se halla en la red, donde lo importante es que existe niveles para esta enfermedad, este proyecto está orientado para un nivelleve.
2.1. Antecedentes Según mi investigación no se tiene investigaciones en esta área en la UMSA, pese a que exite un acuer- do institucional entre la asociación "Mario Lagrava la UMSA con la facultad de tecnología médica.(331/2016 del 31 de agosto del 2016). En el internet se puede hallar numerosas aplicaciones app para android como: Parkinson’s Central (iOS/Android), Lift Pulse (iOS/Android) de uso gratui- to. Estas aplicaciones tienen la función de monitorear y mostrar la amplitud y frecuencia del movimiento pro- pios del Parkinson. Sin embargo no pueden controlar el movimiento. Para realizar un sistema como este y ser comercial debe cumplir con requisitos correspondientes con la ergonomía de la interacción hombre-sistema - Parte 210: Di- seño centrado en el operador humano para los sistemas interactivos (ISO 9241-210:2010) (Ratificada por AENOR en diciembre de 2010.)
2.2. Necesidad tecnológica Una de las dificultades de los monitores arriba mencionados es que el paciente debe sujetar el dispositivo móvil, entonces por el peso del dispositivo podría no ser la correcta. Por ello se requiere de algún dispositivo más pequeño que realice la medida de movimien- tos, filtre la señal, y envíe la lectura hacia un dispositivo andriod para el despliegue de la información requerida. El caso de estudio solo es para el caso de Parkinson le- ve.
3. Propuesta de solución El gráfico a continuación describe el monitor para el sistema: En la figura se tiene una propuesta para sistema donde se tiene:
63
Figura 1. Solución propuesta inicial MPU6050 (giroscópio), Arduino Nano (aprovechando que tiene puerto de programa- ción), Bluetooth (Para envío inalámbrico).
3.1. Sensor giroscópio MPU6050 Este dispositivo fabricado por la empresa bosch, presente varios dispositivos móviles, presenta una buena presición de lectura com girócópio (ejes x,y,z). Adicionalmente presenta la opción de tomar lectura con acelerómetro (medidas de la aceleración en los ejes x,y,z), y a la vez tiene un sensor de temperatura. Para el uso de este dispositivo de debe recurrir a la hoja de datos del fabricante (datasheet). La forma de comunicación es protocolo I2C. El MPU60X0
Figura 2. MPU6050 es el primer dispositivo de seguimiento de mo- vimiento integrado de 6 ejes del mundo que combina un giroscopio de 3 ejes, un acelerómetro de 3 ejes y un procesador digital de movimiento (DMP), todo en un pequeño paquete de 4x4x0.9 mm. Con su bus de sensor I2C dedicado, acepta directamente las entradas de una brújula externa de 3 ejes para proporciona una salida completa MotionFusion de 9 ejes. El dispositi- vo MotionTracking MPU-60X0, con su integración de 6 ejes, MotionFusion integrado y firmware de calibra- ción en tiempo de ejecución, permite a los fabricantes eliminar la costosa y compleja selección, calificación e integración a nivel de sistema de dispositivos discretos,
64
garantizando rendimiento de movimiento óptimo para los consumidores. El MPU-60X0 también está diseña- do para interactuar con múltiples sensores digitales no originales, como sensores de presión, en su puerto auxiliar I2C. El MPU-60X0 es compatible con la familia MPU-30X0. El MPU-60X0 presenta tres convertidores analógicos a digital de 16 bits (ADC) para digitalizar las salidas del giroscopio y tres ADC de 16 bits para digitalizar las salidas del acelerómetro. Para un seguimiento de precisión de movimientos rápidos y lentos, las piezas cuentan con un rango de escala de giroscopio programable por el usuario de ± 250, ± 500, ± 1000 y ± 2000 ° / seg (dps) y un acelerómetro programable por el usuario de escala completa rango de ± 2g, ± 4g, ± 8g y ± 16g.
3.2. Arduino Nano Arduino es un dispositivo electrónico que tiene un microntrolador de la marca Atmel. El modelo Nano tiene específicamente un modelo MEGA328P, además de tener incorporado un puerto de comuniaciones compuesto por un chip conversor de serial a USB, por el cual se puede programar al dispositivo arduino. Caracteristicas • Alto rendimiento, baja potencia AVR Microcontrolador de 8 bits • Arquitectura RISC avanzada - 131 potentes instrucciones - La mayoría de ejecución de ciclo de reloj único - 32 x 8 Registros de trabajo de propósito general - Operación completamente estática - Hasta 16 MIPS de rendimiento a 16 MHz - Multiplicador de 2 ciclos en chip • Segmentos de memoria no volátil de alta resistencia - Bytes de 32K de memoria de programa flash autoprogramable dentro del sistema - 1K Bytes EEPROM - SRAM interno de 2K Bytes - Ciclos de escritura / borrado: 10,000 Flash / 100,000 EEPROM - Sección de código de arranque opcional con bits de bloqueo independientes • Programación dentro del sistema mediante el programa de arranque en chip • Verdadera operación de lectura mientras se escribe - Bloqueo de programación para seguridad de software • Características periféricas - Dos temporizadores / contadores de 8 bits con preescalador independiente y modo de comparación - Un temporizador / contador de 16 bits con preescalador independiente, modo de comparación y captura Modo
- Contador en tiempo real con oscilador separado - Seis canales PWM - ADC de 8 canales y 10 bits en el paquete TQFP y QFN / MLF - Serie USART programable - Interfaz serial SPI Master / Slave - Interfaz serie de 2 hilos orientada a bytes (Philips I2C compatible) - Temporizador de vigilancia programable con oscila- dor separado en el chip - Comparador analógico en el chip - Interrupciones y despertar en el cambio de pin • Funciones especiales del microcontrolador - Reinicio de encendido y detección programable de apagado - Oscilador calibrado interno - Fuentes de interrupción externa e interna - Seis modos de reposo: inactivo, reducción de ruido ADC, ahorro de energía, apagado, modo de espera,y Standby extendido • E / S y paquetes - 23 líneas de E / S programables - 32-lead TQFP, y 32-pad QFN / MLF • Tensión de funcionamiento: - 2.7V - 5.5V para ATmega328P • Rango de temperatura: - Rango de temperatura de trabajo: -40 ° C a + 125 ° C • Grado de velocidad: - 0 - 8 MHz @ 2.7 - 5.5V (Rango de temperatura: -40 ° C a + 125 ° C) - 0 - 16 MHz @ 4.5 - 5.5V (Rango de temperatura automotriz: -40 ° C a + 125 ° C) • Bajo consumo de energía - Modo activo: 1.5mA @ 3V - 4MHz - Modo de apagado: 1 A @ 3V Para programar se debe contar con un entorno de programación, tener seleccionada la tarjeta, y tener cuidado en tener las librerias bien cargadas. Para este dispositivo de tiene muchas librerias ya desarrolladas para interactuar con diferentes sensores y actuadores. Las librerías para manejar el MPU son: include Ï2Cdev.h "include "MPU6050.h" include "Wire.h". Algo importante es que el sensor presenta ruido en las lecturas, para mejorar la presentación se debe realizar un filtro, en este caso es un filtro de kalman. Una vez procesado se envía los datos en forma serial hacia el siguiente dispositivo. Algo en lo que todavía estoy trabajando es en el control de los motores, ya que estos devería con- trolar el movimiento en caso de Parkinson.
3.3. Bluetooth Se ha seleccionado un HC-05 para la comunicación y envío de datos para un dispositivo móvil. El envío
Figura 3. Arduino Nano cumple el protocolo IEEE 802.15.1.
Figura 4. HC-05
3.4. Aplicación móvil Para realizar la aplicación es recomendable usar plataformas libres, por ejemplo: appinventor. Lo importante es la presentación de la amplitud y la frecuencia. Para realizar es necesario realizar el muestreo de da- tos en un intervalo de tiempo generalmente de diez se- gundos y unas quinientas muestras. El appinventor tiene soporte de la MIT (Massachusetts Institute of Technology), ingresando a su página principal se puede realizar el programa donde el diseño de la interfaz cumple con la programación realizada gráficamente.
4. Propuesta de solución El gráfico a continuación describe la forma de monitor para el sistema: La programación se realiza con bloques. La presentación inicial se hace borrando toda la pantalla y poniendo las variables iniciales. A la ves en boton de conectar debe enviar la posibilidad de selección a un dispositivo vinculado, en este caso el HC-05. Luego se tiene que conectar con el bluetooth del dispositivo móvil. El programa principal espera a recibir un dato. El siguiente subprograma dibuja un pixel en al pantalla. En esta parte todavía me encuentro desarrollando un algoritmo para procesar los datos y obtener la amplitud y la frecuencia, esto se hace con FFT (Fast Fourier Transform).
65
Figura 8. Programa principal
Figura 5. App monitor Parkinson
Figura 9. Subprograma dibuja un pixel
Figura 6. Presentaciรณn inicial
//Rx - Pin D1 #include "I2Cdev.h" #include "MPU6050.h" #include "Wire.h" const int mpuAddress = 0x68; MPU6050 mpu(mpuAddress); int gx, gy, gz;
Figura 7. Conexiรณn con el bluetooth
4.1. Desarrollo del programa para arduino El programa es el siguiente: //GND - GND //VCC - VCC //SDA - Pin A4 //SCL - Pin A5 //Tx - Pin D0
66
long tiempo_prev; float dt; int ang_x, ang_y; float ang_x_prev, ang_y_prev; void updateFiltered() { dt=(millis()tiempo_prev)/1000.0; tiempo_prev = millis(); //Calcular angulo de rotaciรณn y filtro complementario ang_y=0.98*(ang_y_prev+(gy/131)*dt) + 0.02*accel_ang_y; ang_y_prev = ang_y;
} void setup() { Serial.begin(115200); Wire.begin(); mpu.initialize(); Serial.println(mpu.testConnection() ? F("IMU iniciado correctamente") : F("Error al iniciar IMU")); } void loop() { // Leer las velocidades angulares mpu.getRotation(&gx, &gy, &gz); updateFiltered(); // El giro es en un solo eje, eje y Serial.println(ang_y); }
delay(100);
6. Conclusiones Fue posible realizar un monitor para Parkinson con la interacción hardware - software necesaria. Fue necesario realizar un filtrado de las señales del giróscopio. El desarrollo de la interfaz del monitor como aplicación android es semejante a un osciloscópio, donde el muestreo es en un tiempo y con una cantidad de datos. Para poder realizar la presentación y cálculo de la amplitud y la frecuencia, se encuentro trabajando, quizá podría realizarce un algoritmo para el arduino, quizá en la aplicación, o bien podría realizarse en ambos lados, esto para mejorar la precisión del cálculo.
7. RECONOCIMIENTOS Es importante el desarrollar este tipo de trabajos para mejorar la calidad de vida de las personas. Agradesco a la persona que se apróximo y me contó que tipo de proyecto quería.
Donde el dato a ser enviado por el bluetooth ya esta filtrado.
5. Futuras investigaciones Además de mejorar el tratamiento de las señales del giroscópio, ¿Será posible controlar el movimiento de Parkinson? es un tema pendiente donde el sistema de control en lazo cerrado sería como el mostrado en la figura 10. Para realizar el control del movimiento sería necesario
REFERENCIAS [1] Alexander V. Bermeo Maldonado - Marco F. Bravo Gua- mán, Diseño y desarrollo de un sistema inalámbrico que permita monitorear los temblores en pacientes que pa- decen la enfermedad de Parkinson utilizando software y hardware libre. Universidad Politécnica Salesiana. Cuenca: España, 2016. [2] Appinventor2, http://appinventor.mit.edu/explore/. MIT, Massachusetts Institute of Technology), Cambridge USA.
Figura 10. Propuesta de control contar con ruedas inerciales con un sistema de potencia para manejar los giros de dos motores.
67
68