UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Interfaz de usuario para sistema deantena auto-orientable

Autor:Ing. Carlos Ignacio Mancón

Director:Dr. Ing. Ariel Lutenberg (FIUBA, CONICET)

Codirector:Ing. Alejandro Permingeat (FIUBA)

Jurados:Esp. Lic. Agustín Bassi (FIUBA)

Esp. Ing. Ernesto Gigliotti (UTN-FRA)Dr. Ing. Pablo Gómez (FIUBA)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entre agostode 2016 y julio de 2017.

III

Resumen

En el presente documento se describe el diseño de una interfaz de usuario quepermite la utilización de la “Antena auto-orientable” de la firma VSATMotion

S.R.L. Esta antena se utiliza para establecer enlaces satelitales en locacionesremotas, en las que el apuntamiento correcto es fundamental para obtener un

enlace de datos adecuado.

El proceso de desarrollo de la interfaz de usuario se inició con el estudio delproblema, la captura de los requisitos, la aplicación de técnicas de gestión de

proyectos y la modelización del software mediante la metodología COMET. A lavez se seleccionó, adaptó y configuró la plataforma embebida necesaria para

utilizar una pantalla táctil y una interfaz adaptadora al estándar decomunicación RS-485.

V

Agradecimientos

A Lourdes, por su constante apoyo y paciencia.

A mi familia y amigos, que a pesar de la distancia nunca dejaron de estar a milado.

A la comunidad de la carrera de Especialización en Sistemas Embebidos, profe-sores, compañeros de cohorte y especialmente al Dr. Ing. Pablo Gómez que meacercó a la posibilidad de realizarla.

A mis directores, Ing. Alejandro Permingeat y Dr. Ing. Ariel Lutenberg, por suguía, consejos y ayuda.

VII

Índice general

Resumen III

1. Introducción General 11.1. Terminales de apertura muy pequeña . . . . . . . . . . . . . . . . . 11.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Introducción Específica 72.1. Contexto general del sistema . . . . . . . . . . . . . . . . . . . . . . 72.2. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3. Diseño e Implementación 113.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1. Selección de plataforma embebida . . . . . . . . . . . . . . . 113.1.2. Pantalla táctil . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.3. Hardware adicional . . . . . . . . . . . . . . . . . . . . . . . 133.1.4. Prototipo de Hardware . . . . . . . . . . . . . . . . . . . . . 14

3.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.1. Selección de lenguaje de software . . . . . . . . . . . . . . . 153.2.2. Selección de librería GUI . . . . . . . . . . . . . . . . . . . . . 153.2.3. Proceso de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.3.1. Modelo de requerimientos . . . . . . . . . . . . . . 163.2.3.2. Modelo de análisis . . . . . . . . . . . . . . . . . . . 173.2.3.3. Modelo de diseño . . . . . . . . . . . . . . . . . . . 17

3.2.4. Modelo del software . . . . . . . . . . . . . . . . . . . . . . . 193.2.4.1. Modelo de requerimientos . . . . . . . . . . . . . . 193.2.4.2. Modelo de análisis . . . . . . . . . . . . . . . . . . . 243.2.4.3. Modelo de diseño . . . . . . . . . . . . . . . . . . . 30

3.2.5. Entorno de desarrollo y herramientas . . . . . . . . . . . . . 303.2.6. Diseño de interfaz gráfica . . . . . . . . . . . . . . . . . . . . 31

4. Ensayos y Resultados 334.1. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2. Pruebas de Integración . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1. Integración en plataforma destino . . . . . . . . . . . . . . . 344.2.2. Integración con unidad externa . . . . . . . . . . . . . . . . . 354.2.3. Herramientas de apoyo . . . . . . . . . . . . . . . . . . . . . 36

4.3. Ensayos de validación . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5. Conclusiones 395.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Bibliografía 41

IX

Índice de figuras

1.1. Ilustración de la conformación de un enlace VSAT entre una esta-ción de servicios y una unidad de campo. . . . . . . . . . . . . . . . 1

1.2. Ilustración de la conformación de un enlace VSAT. . . . . . . . . . . 21.3. Ejemplo de distribución de elementos en unidades externa e interna. 31.4. Diagrama en bloques del sistema. . . . . . . . . . . . . . . . . . . . . 5

2.1. Diagrama de Clases Físicas del contexto del sistema. . . . . . . . . . 82.2. Diagrama de requerimientos de comunicación a alto nivel. . . . . . 92.3. Diagrama de requerimientos de interfaz a alto nivel. . . . . . . . . . 92.4. Diagrama de requerimientos funcionales a alto nivel. . . . . . . . . 10

3.1. Fotografía de plataforma Raspberry Pi 2B. . . . . . . . . . . . . . . . 113.2. Fotografía de plataforma Beaglebone Black. . . . . . . . . . . . . . . 123.3. Fotografía de Pantalla táctil de siete pulgadas. . . . . . . . . . . . . 133.4. Adaptador estándar RS-485 a USB. . . . . . . . . . . . . . . . . . . . 143.5. Fotografía durante el ensamblado del prototipo desarrollado. . . . 143.6. Diagrama de actividad del desarrollo del modelo de requerimientos. 173.7. Diagrama de actividad del desarrollo del modelo de análisis. . . . . 183.8. Diagrama de actividad del desarrollo del modelo de diseño. . . . . 193.9. Diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . 203.10. Diagrama de actividad del caso de uso Configuración. . . . . . . . . 213.11. Diagrama de actividad simplificado del caso de uso Apuntamiento. 223.12. Diagrama de actividad del caso de uso Repliegue. . . . . . . . . . . . 233.13. Diagrama de actividad del caso de uso Mover antena manualmente. . 233.14. Diagrama de actividad del caso de uso Variar velocidad de motor. . . 243.15. Diagrama de clases del modelo estático de contexto. . . . . . . . . . 253.16. Diagrama de clases de interfaces del sistema. . . . . . . . . . . . . . 253.17. Diagrama de clases del modelo estático de entidades del software. 263.18. Diagrama de comunicación para el caso de uso configuración. . . . . 273.19. Diagrama de comunicación para el caso de uso agregar enlace. . . . 283.20. Diagrama de comunicación para el caso de uso apuntamiento. . . . . 293.21. Diagrama de capas de la solución de software en la plataforma em-

bebida. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.22. Ventana básica para validación de prototipo. . . . . . . . . . . . . . 31

4.1. Diagrama ensamble de ensayos de integración para interfaz deunidad externa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2. Diagrama ensamble de ensayos de integración para interfaz deunidad externa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3. Ventana de debug para ensayos de software y hardware. . . . . . . 364.4. Ejemplo de información obtenida a través de datos procesados al-

macenados en archivos csv. . . . . . . . . . . . . . . . . . . . . . . . 37

XI

Índice de Tablas

3.1. Comparación de plataformas embebidas . . . . . . . . . . . . . . . . 12

1

Capítulo 1

Introducción General

En este capítulo se presenta el campo de aplicación del producto y, por ende,de la interfaz desarrollada; luego se describe la motivación que da origen a estedesarrollo y finalmente se define en qué consiste el trabajo realizado.

1.1. Terminales de apertura muy pequeña

Se denomina terminal de apertura muy pequeña, o VSAT (por sus siglas en inglés,Very Small Aperture Terminal), a una estación terrestre utilizada para establecerenlaces satelitales de broadcasting o punto a punto [5].

Dichas terminales consisten de una antena parabólica que junto a un módem es-tablecen un enlace con un satélite en órbita geosincrónica o geoestacionaria (porejemplo, ARSAT[1]), siendo esta última la más común. De esta forma, el satéli-te actúa como relevo comunicando la terminal con una estación terrena que lebrinda servicios. Dicho esquema de comunicación se puede observar en la figu-ra 1.1, pero no es excluyente ya que la tecnología permite la comunicación entreterminales de igual manera.

FIGURA 1.1: Ilustración de la conformación de un enlace VSATentre una estación de servicios y una unidad de campo.

2 Capítulo 1. Introducción General

Como se dijo previamente, este tipo de enlace hace uso de satélites geoestaciona-rios. Los mismos orbitan sobre el plano ecuatorial a una distancia de 35.786kmsobre la superficie terrestre. A esta altitud, el período orbital es igual al de la ro-tación terrestre. Como el satélite se mueve en el mismo sentido que la tierra, elsatélite parece ocupar una posición fija en el firmamento visto desde cualquierposición terrestre.

En la figura 1.2 se presenta una representación de los elementos descritos, dondese puede observar al satélite en su órbita geoestacionaria sobre el ecuador y unaestación terrena que le brinda servicios a una terminal VSAT en una locaciónremota.

FIGURA 1.2: Ilustración de la conformación de un enlace VSAT.

Debido al aparente posicionamiento fijo del satélite, la terminal no tiene necesi-dad de realizar un seguimiento del mismo, lo cual simplifica su operación generalpero no elimina la necesidad de realizar un apuntamiento efectivo de la antena.

En estos tipos de enlaces el apuntamiento de la antena es de carácter crítico de-bido no solo a la apertura de la antena, sino también a la densidad de satélitesen órbita geoestacionaria a la que se ha llegado a lo largo de los años. Debe no-tarse que al posicionarse en el ecuador, los satélites que se incorporan a la órbitadeben distribuirse longitudinalmente, reduciéndose la distancia que los separancon cada nueva incorporación.

Una terminal VSAT se conforma, genéricamente, por dos unidades (figura 1.3):

1. Unidad externa, ODU por sus siglas en inglés (OutDoor Unit). Se constituyedel plato parabólico, el Feedhorn, sus conversores de subida y bajada (BUC,LNB) y la estructura accesoria que acompañe a dichos elementos.

2. Unidad interna, IDU por sus siglas en inglés (InDoor Unit). Contiene la elec-trónica necesaria para codificar/decodificar y modular y demodular las se-ñales de frecuencia intermedia que envía y recibe al BUC y LNB en la uni-dad exterior. Además incluye los elementos necesarios para la utilizaciónde la unidad según la implementación.

1.2. Motivación 3

FIGURA 1.3: Ejemplo de distribución de elementos en unidadesexterna e interna.

Los servicios que debe ofrecer cada producto comercial estará determinado porla tecnología que contenga la IDU. Si la terminal es utilizada para establecer unacomunicación orientada a datos poseerá un módem que ofrecerá puertos de RFpara la transmisión y recepción, y un puerto ethernet para establecer una red. Encambio, si la terminal se orienta a la comunicación de señales de audio y video,los componentes necesarios serán distintos a los anteriores.

Habitualmente se puede independizar la unidad interna de la etapa de modula-ción y codificación utilizando un módem comercial, dejando a la IDU todas lasfunciones accesorias necesarias para cada ODU en particular.

Respecto a las locaciones que hacen uso de este sistema de comunicación, tambiénse pueden dividir en distintos tipos:

Locaciones fijas. Residencias o instituciones en lugares remotos pero estables.Por su carácter, ideales para la utilización de antenas fijas donde el apunta-miento se realiza una sola vez.

Locaciones itinerantes. Pozos de exploración petrolera, campamentos de in-vestigación científica. Si bien permanecen estables en la misma posicióngeográfica durante un período de tiempo, al finalizar su campaña y comen-zar otra el apuntamiento se debe volver a realizar.

Locaciones móviles. Cajeros automáticos móviles, móviles de exteriores de te-levisión. En estos casos el apuntamiento se sucede continuamente. Requie-ren de un sistema de apuntamiento automático.

1.2. Motivación

Para las locaciones donde el apuntamiento se debe realizar regularmente, se deberecurrir a técnicos especializados que realicen dicha labor. Esto es problemático

4 Capítulo 1. Introducción General

y relativamente costoso, por lo que se recurrió a sistemas de apuntamiento auto-máticos que realicen la tarea en lugar de dichos técnicos.

Un usuario con una breve autocapacitación en un equipo de apuntamiento auto-mático y sin conocimientos específicos en la materia puede volverse el operadorde la antena produciendo su despliegue y apuntamiento en el establecimiento dela locación, como también el repliegue correspondiente al finalizar su uso.

Debe considerarse que ante fenómenos climáticos adversos, dicho usuario puedetambién actuar previniendo el daño de la ODU y ser, también, quien realice elapuntamiento posterior al fenómeno.

Esto último es particularmente útil en situaciones como, por ejemplo, exploracio-nes petroleras en la región patagónica donde el ambiente inhóspito y la lejaníaa los centros urbanos pueden provocar que la locación quede incomunicada du-rante un período considerable de tiempo.

Una interfaz de usuario (HMI del inglés Human Machine Interface) le permite alusuario final la utilización de las capacidades del producto Antena Auto-orientablede la firma VSATMotion S.R.L. [8] de forma simple y sin que requiera conoci-mientos específicos en la tecnología de los enlaces VSAT. Para esto, dicha interfazdebe resultar intuitiva a la hora del uso, simple a la hora de la configuración yrobusta en su funcionamiento para evitar condiciones de error que el operadorcomún no pueda solucionar.

Para facilitar la operación de la misma resulta importante la utilización de unapantalla táctil. La ausencia de periféricos para el manejo de este HMI no solo agre-ga facilidad y orden en la instalación, sino que mejora la experiencia del usuario.

Por último, el independizar los servicios que deberá ofrecer el enlace respecto dela IDU, es decir que la misma sea capaz de gestionar un apuntamiento y un re-pliegue sin importar si la terminal forma parte de un móvil de transmisión paratelevisión o si se utiliza para brindar conectividad a un tren sanitario [2], le otor-ga al producto comercial una versatilidad que puede ser capitalizada como unaimportante ventaja frente a la competencia ya establecida.

1.3. Objetivos y alcance

El propósito de este proyecto es desarrollar un prototipo de interfaz de usuariosimple y versátil que facilite la configuración, operación y mantenimiento delequipo en su conjunto.

Como una primera iteración del desarrollo, el cliente propuso enfocar primero eltrabajo en una terminal orientada a datos, que interactúe con un módem satelital.

El prototipo consiste en la IDU del sistema, manteniendo independencia del mó-dem a utilizar para brindar mayor versatilidad a la hora de ensamblar el sistema.El mismo es quien contiene la fuente de alimentación del producto completo, lainterfaz serie necesaria para establecer comunicación con la Unidad de Apunta-miento presente en la ODU, la pantalla táctil y la plataforma embebida en la quese ejecuta el software para la gestión del producto.

1.3. Objetivos y alcance 5

En la figura 1.4 se puede observar un diagrama en bloques donde se explicitanlas interacciones del prototipo. Nótese la diferencia con el diagrama de la figura1.3, que se trataba de un caso genérico.

FIGURA 1.4: Diagrama en bloques del sistema.

El proyecto desarrollado incluyó:

Desarrollo de un prototipo preliminar de la unidad interna del productoantena auto-orientable.

Implementación y armado de dicha unidad en un módulo para rack 19” 2U.

Desarrollo del software embebido para dicha unidad.

Selección de lenguaje de implementación para dicho software.

Selección de la plataforma para implementación de interfaz gráfica.

Implementación de los mecanismos necesarios para la comunicación con launidad externa.

Implementación de los mecanismos necesarios para la comunicación con elmódem.

Generación de documentación del proceso de desarrollo.

El proyecto desarrollado no incluyó:

La selección de las unidades de alimentación de la unidad externa e interna.

La selección del módem a utilizar en el sistema completo.

El desarrollo del hardware embebido en el que se implemente la interfaz dela unidad interna.

7

Capítulo 2

Introducción Específica

En esta sección se presenta el contexto en el cual se inscribe el diseño realizadoy la descripción de la selección de requerimientos para la primera iteración delprototipo.

2.1. Contexto general del sistema

El prototipo se enmarca en un contexto amplio, con múltiples interacciones entrelas distintas unidades. Esto se puede observar en el diagrama del la figura 2.1.

Cada satélite puede formar parte de múltiples enlaces VSAT, donde cada uno deellos emplea una antena para la locación remota y otra para brindarle servicios aesta última.

El prototipo desarrollado se ocupa de la operación de un tipo específico de ante-na, la antena móvil. Cada una de ellas se compone de tres elementos principales:el módem que trabaja con las señales de recepción y transmisión, la unidad exter-na (ODU) y la unidad interior (IDU), que fueron descritas en la sección 1.1.

A su vez, dadas las particularidades del producto comercial de Antena Auto-orientable, la ODU se compone de la antena parabólica, la estructura mecánicay motores que le dan soporte y movimiento a esta última y el sistema de refe-rencia de actitud y rumbo (también denominado AHRS por sus siglas en inglés,Attitude and Heading Reference System) que le proporcionan al producto referenciade su posición y orientación.

Por último la IDU, es decir la interfaz desarrollada en este proyecto, además decontener la fuente de alimentación del sistema, posee la interfaz de comunicacióny la pantalla táctil cuyo uso se desprende de los requerimientos que se tratan enla siguiente sección.

En cuanto a los usuarios del producto se consideran dos tipos: el operador comúnque hará uso de las funciones básicas de apuntamiento y repliegue y el técnicocapacitado en el producto, que hace uso de todas las funciones y posee acceso atodo el producto incluyendo el hardware.

8 Capítulo 2. Introducción Específica

FIGURA 2.1: Diagrama de Clases Físicas del contexto del sistema.

2.2. Requerimientos

Durante la etapa de captura de requerimientos, se realizaron entrevistas de for-ma tal que se pudieran captar los requerimientos a nivel sistema, los cuales fue-ron reducidos a requerimientos menores según los subsistemas del prototipo adesarrollar.

Como se dijo en la sección 1.3, el prototipo debe ser capaz de establecer comuni-cación a través de una interfaz serie con la Unidad Externa. Específicamente, seestableció que la misma debía realizarse cumpliendo con la capa física del están-dar RS-485, mediante un protocolo ad-hoc implementado por el cliente.

Por otra parte, la comunicación con el módem requiere la utilización de ethernety protocolo Telnet [4].

Estos requerimientos pueden verse en la figura 2.2.

2.2. Requerimientos 9

FIGURA 2.2: Diagrama de requerimientos de comunicación a altonivel.

En cuanto a las interfaz con el usuario, se estableció que la operación del produc-to se realice mediante una pantalla táctil. A través de ella el usuario debe poderiniciar los despliegues y repliegues necesarios pero también le debe permitir con-figurar en el sistema, y siempre debe ser el medio por el cual se indique el estadotanto de la ODU como del módem (figura 2.3).

FIGURA 2.3: Diagrama de requerimientos de interfaz a alto nivel.

Por último en cuanto a la funcionalidad del prototipo, éste debe ser quien permitaal sistema modificar a qué satélite se apuntará, con qué frecuencia y polarización.También debe ser el intermediario entre el módem y la ODU, si fuese necesario yserá el medio de selección de las opciones de geolocalización. Vease figura 2.4.

A partir de estos requerimientos se realizó un trabajo de reducción de nivel de losmismos, además de la inclusión de otros que fueron surgiendo durante dicha ta-rea y durante el inicio del proceso de modelado de casos de uso del cual se hablaráen el capítulo 3, sección 3.2.3 y se expondrán los resultados en la sección 3.2.4 delmismo capítulo.

Dichos requerimientos quedaron plasmados en el documento interno VSATM-ER-009-A. El proyecto se realizó con foco en requerimientos críticos y prioritarios

10 Capítulo 2. Introducción Específica

FIGURA 2.4: Diagrama de requerimientos funcionales a alto nivel.

consensuados con el cliente. Dejando para una futura iteración los de menor prio-ridad.

11

Capítulo 3

Diseño e Implementación

En este capítulo se describen los criterios de selección de tecnologías y el proce-so de modelado y diseño utilizado. Por último se exponen los resultados de laimplementación y del modelado.

3.1. Hardware

3.1.1. Selección de plataforma embebida

El requerimiento de utilizar una pantalla táctil implicó la necesidad de utilizaruna plataforma embebida para simplificar el software a desarrollar. Por otro lado,requerimientos de menor prioridad que serán implementados en las siguientesiteraciones y la prestación de nuevos servicios impactarán no solo en la compleji-dad del software sino en la carga sobre procesador y el espacio de memoria.

Bajo estas condiciones se analizaron dos micro computadoras comerciales: Rasp-berry Pi 2B (figura 3.1) y Beaglebone Black (figura 3.2). Se trata de dos plataformasrelativamente muy similares, ambas capaces de soportar la ejecución de distribu-ciones Linux.

FIGURA 3.1: Fotografía de plataforma Raspberry Pi 2B.

Si bien hay múltiples opciones más de este tipo, al ser estos modelos de los másdifundidos, reducen el riesgo de carencia. Por otra parte, grandes comunidadeshan proliferado en torno a ellos, facilitando la resolución de errores, hallazgo desoluciones ya implementadas y soporte en foros oficiales.

12 Capítulo 3. Diseño e Implementación

FIGURA 3.2: Fotografía de plataforma Beaglebone Black.

En la Tabla 3.1 se puede observar una comparación simplificada de las caracterís-ticas de cada opción.

TABLA 3.1: Comparación entre opciones de plataforma embebida

Concepto Raspberry Pi 2B Beaglebone Black

Procesador Broadcom BCM2836 TI Sitara AM3358Núcleo CPU 4x Cortex-A7 1x Cortex-A8Frecuencia CPU 900MHz 1GHzGPU Broadcom VideoCore IV PowerVR SGX 530RAM 1GB 512MBMemoria FLASH No 4GBAlmacenamiento microSD microSDEthernet 100Mbit 100MbitUSB 4x 2.0 Host 1x 2.0 Host, 1x 2.0 DeviceSalida de video HDMI, compuesto HDMIExpansión 40pines: 2x 46pines: GPIO, ADC,

GPIO, I2C, SPI, UART I2C, SPI, UART, CANDimensiones 85x56mm 86x53mm

Nótese que la Beaglebone ofrece mejores condiciones de conexión con numerosasI/O y estándares de comunicación pero la Raspberry es superior en términos deprocesador y memoria RAM. Estos últimos se juzgan vitales para lograr que elsoftware brinde un breve tiempo de respuesta al usuario, y facilita la implemen-tación del software al no imponer limitaciones importantes. También respecto apuertos USB la Beaglebone se encuentra en desventaja, ya que al implementar unsolo Host puede tornarse un caracter restrictivo en el futuro.

Por esta razón, y en vistas de los requerimientos futuros, se decidió utilizar laRaspberry Pi 2B como plataforma para ejecutar el software del prototipo.

3.1. Hardware 13

3.1.2. Pantalla táctil

Se selecciona una pantalla acorde al tamaño del frente del gabinete, aprovechan-do la altura del Rack 2U (aproximadamente 9cm de alto). Con siete pulgadas detamaño y una resolución de 1024x600 píxels se obtiene área suficiente para des-plegar los controles y avisos en las pantallas y aún así mantener la comodidad delusuario al operar con ellas.

En la figura 3.3 se puede observar el tamaño relativo a la plataforma seleccionaday también las conexiones necesarias para su funcionamiento. Se utiliza HDMI pa-ra comunicar la señal de video, mientras que las funciones táctiles se transmitena través de USB.

FIGURA 3.3: Fotografía de Pantalla táctil de siete pulgadas.

3.1.3. Hardware adicional

Para poder comunicar el prototipo con la ODU, se recurrió a validar la tecnologíacon un adaptador comercial. Se trata de un dongle USB que traduce las señales delpar diferencial del estándar RS-485, presentandose en el sistema operativo comouna terminal clásica. La figura 3.4 muestra una fotografía de este adaptador.

Notese que de haber sido utilizado como plataforma a la Beaglebone Black, no sepodría haber utilizado este adaptador y la pantalla táctil, ya que como se vió enla Tabla 3.1, ésta cuenta con solo un puerto Host.

Otra ventaja de utilizar este dispositivo consiste en la posibilidad de iniciar elprototipado temprano del software, sin necesidad de haber desarrollado circuitospropios para cumplir su labor.

14 Capítulo 3. Diseño e Implementación

FIGURA 3.4: Adaptador estándar RS-485 a USB.

Una vez realizadas algunas iteraciones sobre el prototipo, el adaptador puede serreemplazado por el circuito diseñado para esta función.

3.1.4. Prototipo de Hardware

En la figura 3.5 se muestra el prototipo de la IDU mientras era ensamblado. Enel centro, se ubica la Raspberry Pi con el adaptador USB/RS-485 conectado ytambién el cable de la funcionalidad táctil de la pantalla. Ésta se encuentra enel centro y arriba, viéndose solo su parte posterior. A la derecha del gabinete seobserva la fuente de alimentación de ambas unidades (IDU y ODU). Finalmentea los lados de la pantalla se encuentran el interruptor general (a la izquierda) y elbotón de emergencia (a la derecha).

FIGURA 3.5: Fotografía durante el ensamblado del prototipo desa-rrollado.

3.2. Software 15

3.2. Software

3.2.1. Selección de lenguaje de software

La selección del lenguaje de software en la que se implementó el prototipo estuvoinfluenciada por varios conceptos:

Alto nivel. Con el objetivo de acortar el período de desarrollo y sacandoprovecho de las capacidades de la plataforma seleccionada, se pretende queel lenguaje facilite el proceso de desarrollo.

Orientado a Objetos. Como se verá en la Sección 3.2.3, la metodología enfati-za el diseño ordenado de clases y objetos cuya transición a código se veráfavorecida por un lenguaje de esta orientación.

Portabilidad. En primer lugar, con la expectativa de agilizar el proceso dedesarrollo, se consideró que un lenguaje que permitiese debuggear en la mis-ma plataforma de desarrollo ahorraría tiempo durante el proceso y tambiénevitar la implementación de la alternativa que hubiera consistido en un sis-tema de cross-debugging con la plataforma objetivo. Por otra parte, utilizarlos prototipos de software como herramienta durante el desarrollo final dela ODU resultaba viable y provechoso si dichos prototipos pudieran ser eje-cutados en la estación de desarrollo de ese subsistema.

Por estas razones se optó por utilizar el lenguaje Java que, al ser tan difundido yutilizado, cuenta con amplio desarrollo de librerias, soporte y documentación.

3.2.2. Selección de librería GUI

Una vez seleccionado el lenguaje de implementación se comenzó el estudio deherramientas y librerías para la generación de la interfaz gráfica propiamente di-cha.

Java fue complementado durante un largo período de tiempo por la plataformaSwing pero más recientemente se lanzó la plataforma JavaFX. Se necesitó selec-cionar con cuál desarrollar el prototipo porque la migración de una a la otra re-presenta un cambio de paradigma. Si en una etapa futura se decidiera migrar,el esfuerzo invertido en el desarrollo previo o en la migración posterior podríahaberse utilizado en otras tareas de mayor importancia.

Teniendo en cuenta de que JavaFx surge como una evolución, o bien un reem-plazo a Swing, se decidió utilizar JavaFX en vistas de que, salvo por la mayorutilización de recursos de sistema o la necesidad de distribuciones más actualiza-das de Java, la misma posee numerosas ventajas sobre la otra. Algunas de las quese consideraron más importantes se enumeran a continuación [6]:

Separación entre modelo, vista y controlador. La modularización que ofrece seconvierte en un recurso muy valorado para el desarrollador, ya que facilitael desarrollo y posterior mantenimiento.

Manejo de eventos. Ambas librerías utilizan eventos para responder a las ac-ciones de los usuarios, pero JavaFx presenta mejoras en este campo al ser

16 Capítulo 3. Diseño e Implementación

más simples de utilizar, especialmente por su vinculación con las propieda-des.

Propiedades. Se trata de variables cuyos valores pueden ser observados, gene-rando acciones cuando el valor de éstas cambien. Incluso distintas propie-dades pueden ser enlazadas para que el cambio de una tenga su correlatoen la otra.

FXML. Se trata de un lenguaje basado en XML que provee la estructura paraconstruir la interfaz de usuario de forma separada de la logica de aplicación.Su utilización se vuelve extremadamente simple al utilizar SceneBuilder deOracle, que actúa como complemento al entorno de desarrollo de Java.

Utilización de CSS. Una vez creada la interfaz, el estilo de la misma puedeser modificado en cualquier momento modificando dicha hoja de estilo, sinnecesidad de alterar el resto de la implementación.

3.2.3. Proceso de desarrollo

Para desarrollar el software se emplea la metodología COMET (Concurrent Ob-ject Modeling and Architectural Design Method) originalmente introducida porHassan Gomaa en el año 2000 [3].

COMET es un método iterativo de modelado y diseño de software basado encasos de uso y paradigma orientado a objetos que aborda específicamente lasfases de modelado de requisitos, de análisis y de diseño dentro del ciclo de vidade desarrollo de software. Esta metodología emplea diagramas UML (Lenguajede Modelado Unificado).

La metodología COMET propone enfocar el modelado del software en tres fases:

modelo de requerimientos

modelo de análisis

modelo de diseño

Como herramienta para el modelado se ha empleado Enterprise Architect.

3.2.3.1. Modelo de requerimientos

En el modelo de requisitos, los requisitos funcionales del sistema se describen entérminos de actores y casos de uso. Cada caso de uso define una secuencia deinteracciones entre uno o más actores y el sistema.

Como se observa en la figura 3.6, en esta fase se comienza desarrollando un dia-grama de casos de uso donde se describen los actores y casos de uso, y posterior-mente se establecen la relaciones que unen a estos últimos. Luego se documentacada caso de uso en una descripción narrativa del mismo.

3.2. Software 17

FIGURA 3.6: Diagrama de actividad del desarrollo del modelo derequerimientos.

3.2.3.2. Modelo de análisis

En el modelo de análisis, el analisis se enfoca en entender el problema; por lo tantose enfoca en identificar los objetos del dominio del problema y el intercambio deinformación entre ellos.

Las actividades involucradas en la confección del modelo de análisis se observanen la figura 3.7.

Se comienza desarrollando un modelo estático del problema en términos de cla-ses, relaciones y atributos que intervienen en el sistema. Luego se continua es-tructurando el sistema en clases y objetos mediante la aplicación de algún criteriode estructuración para determinar dichos objetos y clases. Esto permite estable-cer los subsistemas de alto nivel del mismo. Finalmente se desarrolla un modelodinámico donde se determina qué objetos participan en cada caso de uso y sedesarrolla un diagrama de comunicación entre dichos objetos para cada uno delos casos de uso.

3.2.3.3. Modelo de diseño

En el modelo de diseño se considera el dominio de la solución. Para ello, se desa-rrolla la arquitectura del software, describiendo los componentes y sus interfaces.

Para su realización, se inicia sintetizando los artefactos del modelo de análisis,es decir integrar diagramas de interacción, de clases y statecharts que se hayancreado en diagrama mas generales (de cada tipo) que permitan observar un pa-norama general.

18 Capítulo 3. Diseño e Implementación

FIGURA 3.7: Diagrama de actividad del desarrollo del modelo deanálisis.

Una vez realizados los diagramas integradores, se comienza a diseñar la arqui-tectura del software mediante la aplicación de algún criterio de estructuración;obteniendo subsistemas. Esto permite definir las interfaces entre ellos.

En caso de trabajar con una aplicación distribuida se procede, luego, a determinarcómo serán distribuidos los componentes de los subsistemas. Una vez estructura-dos los subsistemas se procede a organizarlos en tareas concurrentes, definir lasinterfaces de éstas y desarrollar diagramas de colaboración concurrentes.

Al terminar de definir las tareas concurrentes se realiza un análisis del rendimien-to del diseño. Se aplica planificación de tiempo real para determinar si el diseñode la concurrencia cumplirá sus metas de rendimiento.

A continuación se procede a diseñar las clases de cada subsistema, diseñandosus interfaces e incluyendo todas sus operaciones. Luego se desarrolla el diseñodetallado, donde se diseña el interior de las clases compuestas incluyendo losmecanismos de sincronización.

Finalmente se analiza el rendimiento del diseño, aplicando un análisis en mayordetalle del rendimiento en tiempo real de cada subsistema.

Todas estas actividades se ven resumidas en el diagrama de actividad de la figura3.8.

3.2. Software 19

FIGURA 3.8: Diagrama de actividad del desarrollo del modelo dediseño.

3.2.4. Modelo del software

3.2.4.1. Modelo de requerimientos

Durante esta etapa se desarrolló el análisis de los casos de uso. Se identificarondoce casos y cuatro actores. Como se observa en la figura 3.9, algunos de ellosestablecen relaciones entre sí ya que para utilizar ciertas funciones se debe acce-der a un nivel más avanzado de configuración y por ello el caso de uso Ingresoa configuración avanzada se incluye en Calibración, Agregar Satélite y Mover antenamanualmente. En este ultimo caso, Variar velocidad de motor lo extiende al agregaruna interacción opcional del actor con el sistema.

Nótese que la inclusión de los casos de uso de calibración para cada sensor expli-cita que cada uno representa porciones del caso de uso Calibración, a diferencia dela inclusión anteriormente descrita, que era para explicitar un paso común en losdistintos casos de uso.

Respecto a los actores, se pueden observar los usuarios del prototipo de interfaza la izquierda del diagrama, mientras que a la derecha se encuentran los sistemasexternos, la ODU y el módem. El Técnico hereda los atributos del Operador, es decirque se trata de una generalización ya que puede realizar todas las operaciones deloperador, pero además puede acceder a otras funcionalidades del sistema.

Como se dijo en el capítulo 2, sección 2.2; se estableció con el cliente en qué ca-racterísticas se debía hacer foco en una primera iteración. Por esta razón, si bien

20 Capítulo 3. Diseño e Implementación

FIGURA 3.9: Diagrama de casos de uso.

3.2. Software 21

los casos de uso correspondientes a la calibración fueron realizados, el análisis amayor profundidad de los mismos se abordará en la próxima iteración. De estaforma, se puede alcanzar un mínimo producto viable de forma más temprana yestudiar la usabilidad del prototipo por parte de los operadores.

A continuación se muestra la descripción de los casos de uso más relevantes me-diante diagramas de actividad.

En la figura 3.10 se puede observar el caso de uso Configuración de relativa sim-plicidad. El caso de uso contempla la configuración como el proceso de seleccióndel satélite al cual se apuntará. El mismo es activado por el operador y le permite aéste la selección de una opción dentro de una lista de enlaces satelitales disponi-bles (configurables por el técnico) y posteriormente permite seleccionar el mediode posicionamiento del sistema.

FIGURA 3.10: Diagrama de actividad del caso de uso Configura-ción.

El caso de uso Apuntamiento presenta varios caminos alternativos donde se re-suelven excepciones. Para mantener la claridad del mismo sólo se muestra en lafigura 3.11 el flujo básico del caso de uso.

En el camino básico, el software releva que los sistemas externos cuenten conlos parámetros necesarios para el funcionamiento según la configuración actualdel sistema. Algunos de los caminos alternativos, por ejemplo, generan la confi-guración de los sistemas externos si éstos no contaran con los valores correctos; ogeneran mensajes de error si dichos sistemas no respondiesen. Una vez validados

22 Capítulo 3. Diseño e Implementación

los parámetros se ordena el apuntamiento y, posterior al aviso de finalización, secomprueba el resultado del apuntamiento para mostrarlo por pantalla al operador.

Como se observa, el caso es activado por el operador, pero el software debe inter-actuar con los sistemas externos módem y ODU1.

FIGURA 3.11: Diagrama de actividad simplificado del caso de usoApuntamiento.

Siendo el caso de uso repliegue más simple, su diagrama (figura 3.12) permitemostrar los caminos alternativos de un caso de uso. En dicho diagrama se puedenobservar los caminos que se suceden si ocurriese un error en el repliegue, ya seapor el aviso de un error presente en el sistema de apuntamiento informado por laODU o bien, la ausencia de resultado alguno.

El operador activa el caso de uso, ordenando el repliegue, resultando en la ordendel software a la ODU para que se realice dicha acción.

1En el diagrama en cuestión se observa un paso en el cual, el software verifica que no se hayaconfigurado ningún parámetro en el módem. Esto se debe a que de haberlo hecho, el software debeejecutar un reset de dicho equipo. Este proceso es de relativa larga duración y debe ser evitado paramejorar el tiempo de respuesta del sistema

3.2. Software 23

FIGURA 3.12: Diagrama de actividad del caso de uso Repliegue.

El caso de uso mover antena manualmente se puede observar en la figura 3.13.

FIGURA 3.13: Diagrama de actividad del caso de uso Mover antenamanualmente.

24 Capítulo 3. Diseño e Implementación

Aquí, la activación se inicia por parte del técnico. Este caso de uso puede conteneropcionalmente al caso de uso variar velocidad de motor. Esto se debe a que el técnicopueda necesitar agilizar algún proceso de mantenimiento modificando la veloci-dad de alguno de los motores. Como dicha modificación es opcional, la relaciónque vincula ambos casos es de extensión. El operador no solo no posee acceso a es-ta funcionalidad sino que durante la utilización normal del sistema, la velocidades gestionada exclusivamente por la ODU.

El caso de uso variar velocidad de motor se muestra en la figura 3.14. Nuevamente,este caso es activado por técnico y debe interactuar con la ODU.

FIGURA 3.14: Diagrama de actividad del caso de uso Variar veloci-dad de motor.

3.2.4.2. Modelo de análisis

Para esta etapa del modelado, primero se desarrolló un modelo estático del do-minio del problema que puede observarse en el diagrama de clases mostradopreviamente en la figura 2.1, en el capítulo 2, sección 2.1. De esta forma se pudo

3.2. Software 25

partir de un punto de vista abarcador, donde todos los elementos eran considera-dos.

A continuación se procedió a desarrollar un modelo estático de contexto. El mis-mo se puede observar en la figura 3.15, donde se muestra como el software desa-rrollado interactúa con los sistemas externos ODU y módem y con el usuario.

FIGURA 3.15: Diagrama de clases del modelo estático de contexto.

Para establecer las clases que gestionan la interacción con los elementos externosdel sistema, se desarrolla el diagrama de clases de la figura 3.16.

FIGURA 3.16: Diagrama de clases de interfaces del sistema.

Se procedió, luego, a desarrollar un modelo estático de las clases entidad. Estasclases son de carácter conceptual y su principal rol es el de almacenar informa-ción. Dicho modelo puede verse en la figura 3.17

26 Capítulo 3. Diseño e Implementación

FIGURA 3.17: Diagrama de clases del modelo estático de entida-des del software.

La estructuración en clases y objetos se finalizó con la determinación de las clasesinternas del sistema, que llevaran a cabo la funcionalidad del software. Esta es-tructuración se realizó en tres paquetes: Entorno, Control y Logica de aplicación. Elprimer paquete contiene las clases (y objetos) que se presentaron en la figura 3.16,mientras que el segundo contiene a los coordinadores para las distintas funccio-nes y el tercero la lógica abstracta necesaria para realizar acciones puntuales. Lasmismas son:

Entorno

• InterfazModem. Encargada de interactuar con el módem.

• InterfazOperador. Encargada de gestionar las entradas salidas hacia elususario.

• InterfazODU. Encargada de interactuar con la unidad exterior.

Control

• GestorDeAcceso. Encargada de habilitar el acceso del ususario a las dis-tintas funciones.

3.2. Software 27

• GestorDeApuntamiento. Encargada de realizar los pasos necesarios paraapuntar la antena.

• GestorDeCalibracion. Encargada de guiar al técnico durante el procesode calibración

• GestorDeConfiguracion. Encarga de administrar las distintas configura-ciones posibles.

• GestorDeMovimiento. Encargada de permitir la maniobra de la antena.

• GestorDeRepliegue. Análoga a la de apuntamiento pero para el replie-gue.

• Temporizador. Encargada de generar eventos disparados temporalmen-te.

• VerificadorDeEstados. Encargada de interpretar el estado de los elemen-tos del sistema para ser mostrados al usuario.

Lógica de aplicación

• ConfigurarModem. Lógica que debe ser aplicada para interactuar con elmódem.

• ValidacionDeAceso. Lógica que debe ser aplicada para validar el accesode un usuario a las funciones restringidas del sistema

Por último, se realizaron los diagramas de comunicación de los casos de uso paraanalizar el intercambio de mensajes entre los distintos objetos del sistema (instan-cias de las clases determinadas previamente). A continuación se presentan algu-nos de ellos, considerándolos representativos de la totalidad.

En primer lugar se presenta el diagrama para el caso de uso configuración en lafigura 3.18 para mostrar un caso simple a modo de introducción. Obsérvese losnúmeros de secuencia que acompañan a cada mensaje y le brindan un orden tem-poral. En dicho diagrama se observa cómo el operador a través de la InterfazOpe-rador establece cuál será el enlace (satélite y parámetros técnicos necesarios parala comunicación) con el que se trabajará.

FIGURA 3.18: Diagrama de comunicación para el caso de uso con-figuración.

28 Capítulo 3. Diseño e Implementación

En la figura 3.19 se presenta el diagrama correspondiente a el caso de uso agre-gar enlace que permite observar los caminos alternativos del caso. Los mismos seordenan agregando un nivel numérico adicional al nodo del camino que les daorigen. Este diagrama también presenta el manejo de permisos que se requierepara la utilización de funciones restringidas al operador pero permitidas al técnico.

FIGURA 3.19: Diagrama de comunicación para el caso de uso agre-gar enlace.

Finalmente, en la figura 3.20 se presenta el diagrama de comunicación para el ca-so de uso apuntamiento. Siendo uno de los más importantes, también es uno de losmás complejos debido al número de interacciones que debe realizar el objeto Ges-torDeApuntamiento para asegurar que la ODU inicie el proceso de apuntamientocon los parámetros adecuados según la configuración actual. Nuevamente se re-dujo la cantidad de caminos alternativos para poder exponer con mayor claridadel funcionamiento principal en dicha situación. Los caminos alternativos faltantesson los pasos que el software realiza en caso de que los parámetros de los sistemasexternos no correspondan entre sí o con los del enlace configurado en el sistema.

3.2. Software 29

FIGURA 3.20: Diagrama de comunicación para el caso de usoapuntamiento.

30 Capítulo 3. Diseño e Implementación

3.2.4.3. Modelo de diseño

Durante la definición de la arquitectura de software se contempló la interaccióncon el software preexistente para la plataforma.

En la figura 3.21 se muestra como la aplicación se soporta sobre el sistema operati-vo de la plataforma embebida, la máquina virtual de Java y bibliotecas de códigodesarrolladas por terceros.

FIGURA 3.21: Diagrama de capas de la solución de software en laplataforma embebida.

La selección de estas bibliotecas permite reducir el tiempo de desarrollo al limitarel diseño detallado de los objetos particulares del diseño.

Para el manejo del puerto serie, se consideró en un primer momento la utiliza-ción de javax.comm2 pero la misma no era soportada por la arquitectura del target,por lo que se recurrió a la biblioteca RXTX3 cuya interfaz es intercambiable a laanterior y posee amplia documentación.

Por otra parte, para establecer la comunicación con el módem a través de proto-colo TELNET, se decidió la utilización de la biblioteca Apache Commons Net4 quefacilita la implementación de un cliente de dicho protocolo dentro de la aplica-ción.

Finalmente, y como se dijo en la sección 3.2.2, se utilizó la biblioteca JavaFX parael manejo de la interfaz gráfica y los eventos disparados por los usuarios a travésde la pantalla táctil.

Como se puede ver, estas bibliotecas reducen el esfuerzo de diseño de las clases deinterfaz, requiriendo la codificación de la bussines logic, es decir la lógica particularnecesaria para la aplicación específica.

3.2.5. Entorno de desarrollo y herramientas

Se seleccionó como entorno de desarrollo a la herramienta Eclipse IDE for JavaDevelopers, en su versión Neon. Para la creación de las vistas de la interfaz gráficase utilizó SceneBuilder, versión 2.0. La vinculación entre los mismos se realiza através de un plugin instalable en Eclipse.

2http://www.oracle.com/technetwork/java/index-jsp-141752.html3http://rxtx.qbang.org/4https://commons.apache.org/proper/commons-net/

3.2. Software 31

Respecto a la plataforma de Java se utilizó Java Platform, Standard Edition 8 Update141 (Java SE 8u131) en el desarrollo y durante el despliegue en la plataforma em-bebida se debió instalar un port de JavaFX para la arquitectura armv65 ya que ladistribución original de Oracle discontinuó el soporte para la misma a partir dela versión 8u65.

Por último se estableció un servidor de integración continua encargado de reali-zar la compilación de los paquetes ejecutables. Esto se hizo mediante la ejecuciónde un script implementado en Ant6 cada vez que se realiza un cambio en el códigoque se mantiene en un repositorio Git almacenado en la nube.

3.2.6. Diseño de interfaz gráfica

Para validar la estructura básica de la interfaz gráfica del prototipo se creó unaestructura consensuada con el cliente, la misma se presenta en la figura 3.22.

Como se observa, la misma es muy simple y de fácil lectura por el usuario. Elestado de los dispositivos del sistema se muestran gráficamente mediante coloresy la situación de la antena (si la misma se encuentra replegada, desplegada oen qué etapa del apuntamiento) se presenta de forma escrita en la parte inferior.Los botones para comandar el sistema se sobredimensionaron para facilitar laoperación y, por último, la imagen de los engranajes permite acceder a la ventanade configuración del sistema.

FIGURA 3.22: Ventana básica para validación de prototipo.

5http://gluonhq.com/products/mobile/javafxports/get/6Apache Ant se trata de una herramienta usada para la realización de tareas mecánicas y repe-

titivas como la compilación, similar a Make pero orientado a Java

33

Capítulo 4

Ensayos y Resultados

Durante el desarrollo de la implementación se llevaron a cabo pruebas a partir demúltiples enfoques. En este capítulo se presentan dichas pruebas.

4.1. Pruebas unitarias

Durante el desarrollo del prototipo de software se realizaron test unitarios sobreelementos críticos del software. Para esto se utilizó JUnit aprovechando su inte-gración con el entorno de desarrollo Eclipse.

Como se dijo en el capítulo 3, sección 3.2.4.3, la implementación utilizó libreríasde terceros que no fueron sujetas a pruebas, pero sí se realizaron pruebas sobrela lógica específica necesaria para la interacción con los distintos elementos delsistema (módem y unidad exterior).

Para el caso de la interfaz del módem se realizaron pruebas simulando la interac-ción con el módem que se hubiera dado a través del cliente TELNET (componentede librería Apache Commons).

Se caracterizó el comportamiento de dicho elemento durante las distintas etapasde operación, almacenando los mensajes que intercambiaba al ser utilizado porlínea de comando.Estos mensajes fueron los utilizados para realizar un mock du-rante los test.

Los tests más relevantes ejecutados sobre dicha unidad fueron:

Conexión. Donde se comprueba la rutina para establecer la conexión con eldispositivo.

Desconexión. Donde se comprueba la rutina complementaria a la anterior.

Activar generación de información de apuntamiento. Donde se comprueba la ru-tina que le ordena al módem que inicie el suministro de dicha información

Desactivar generación de información de apuntamiento. Donde se comprueba larutina que le ordena al módem que detenga el suministro de dicha informa-ción.

Por otra parte, para la interfaz de la unidad exterior se ejecutaron test inyectandopaquetes conocidos y comprobando la correcta interpretación de los mismos. Asímismo se comprobó la correcta generación de comandos que la interfaz envía ala ODU.

34 Capítulo 4. Ensayos y Resultados

Tanto para la implementación de la lógica de la aplicación como de los test quecomprobaron el funcionamiento de la misma se realizaron conforme al documen-to VSATM-ICD-0001A que establece las particularidades de la interfaz entre uni-dad interior y exterior.

4.2. Pruebas de Integración

Para el caso de la interfaz con el módem se procedió a poner bajo prueba al mó-dulo de la lógica en cuestión en conjunto con un cliente TELNET (propio de lalibrería Apache Commons) y un módem real.

Los test se ejecutaron en una PC, contra el módem, es decir, que no había simu-lación del elemento sino un dispositivo real que respondía a los comandos delmódulo. Durante la ejecución de los mismo se observó y posteriormente alma-cenó el intercambio de mensajes entre los elementos descritos. Todos los ensayosejecutados fueron aprobados exitosamente.

Para el caso de la interfaz de unidad externa se realizaron dos sets de prueba quese enumeran a continuación.

Ensayos de integración en plataforma destino.

Ensayos de integración con unidad externa.

4.2.1. Integración en plataforma destino

Para la realización de los primeros se procedió a establecer una comunicaciónentre la PC de desarrollo y la Raspberry tal como lo muestra la figura 4.1

FIGURA 4.1: Diagrama ensamble de ensayos de integración parainterfaz de unidad externa.

4.2. Pruebas de Integración 35

Para el análisis de la información recibida se establecieron tres medios en el soft-ware desarrollado.

Almacenamiento de datos crudos provenientes de la interfaz serie en un ar-chivo sin formato.

Almacenamiento de datos procesados provenientes de la interfaz serie en unarchivo con formato valores separados por comas (CSV).

Ventana de debug en el prototipo de software, visible en la pantalla táctil delprototipo de hardware.

4.2.2. Integración con unidad externa

De forma análoga a al proceso anterior, se procedió a ensayar el funcionamientodel sistema mediante la conexión del prototipo de unidad interna a una CIAA [7],componente central de la unidad exterior. Esta conexión se realiza a través de unadaptador RS232/RS485. El ensamble se puede observar en la figura 4.2.

FIGURA 4.2: Diagrama ensamble de ensayos de integración parainterfaz de unidad externa.

Estos ensayos permitieron comprobar el correcto funcionamiento de la compati-bilidad del dongle comentado en el capítulo 3, sección 3.1.3 y la interfaz serie dela ODU. Además, se utilizaron para realizar pruebas de stress sobre el prototi-po al aumentar la tasa de transferencia desde la ODU, para probar la capacidadde la plataforma embebida para soportar la carga de procesamiento derivada demayor volumen de datos a procesar

36 Capítulo 4. Ensayos y Resultados

4.2.3. Herramientas de apoyo

Como se dijo anteriormente, se implementó una ventana que permite analizar elestado y la información intercambiada por las unidades del sistema. En la mismase pueden observar tanto los datos crudos como los procesados.

Esta implementación no solo constituye un medio de comprobación durante losensayos del modulo de interfaz de unidad exterior, sino que facilita la compro-bación del sistema en general. Con esta funcionalidad se facilita el ensayo delos componentes de hardware como también de algoritmos desarrollados parala unidad exterior.

La ventana diseñada con tal objetivo se presenta en la figura 4.3. Observese que alejecutarse la aplicación desde la PC de desarrollo la ventana presenta los controlesde ventana (minimizar, maximizar y cerrar), pero si se ejecutara en el target losmismos no estarían presentes.

FIGURA 4.3: Ventana de debug para ensayos de software y hard-ware.

Por otra parte, los archivos de datos procesados que actúan como logs permitenel estudio pormenorizado de la información, de forma tal que se puede realizarbúsqueda de fallas, posibilidades de mejora de los algoritmos utilizados y estudiodel rendimiento de hardware.

Un ejemplo de la utilización de esta información se puede ver en el gráfico de lafigura 4.4.

4.3. Ensayos de validación 37

FIGURA 4.4: Ejemplo de información obtenida a través de datosprocesados almacenados en archivos csv.

4.3. Ensayos de validación

Finalmente, se realizaron los ensayos de validación para el prototipo de unidadinterior.

En dichos ensayos participó un representante de la empresa VSATMotion S.R.L.,a quién se le adjudicó el rol de operador, produciendo un número de desplieguesy repliegues de la antena, cada uno con su correspondiente apuntamiento.

Adjudicarle ese rol al representante permitió realizar, a la vez, un test de usabili-dad de la interfaz implementada.

Todos los ensayos fueron aprobados exitosamente.

39

Capítulo 5

Conclusiones

5.1. Conclusiones

Durante el desarrollo de este proyecto se alcanzaron los objetivos planteados paralos requerimientos prioritarios convenidos con el cliente pero además se le dotóa éste de una herramienta para el desarrollo y puesta a punto de su producto. Elprototipo obtenido no solo representa una versión inicial para estudiar la usabi-lidad del producto por parte de los usuarios, sino que incluye un nexo entre elsistema y el desarrollador.

La utilización del lenguaje Java para la implementación permite la utilización dela interfaz fuera del hardware embebido, que facilita la adquisición y análisis dedatos y métricas provenientes de la unidad exterior. Esto resultará ampliamen-te beneficioso para la mejora de algoritmos como también para la detección deposibles fallas tanto en hardware como en software.

5.2. Trabajo futuro

Se procederá a desarrollar un circuito impreso diseñado a medida para las nece-sidades de la interfaz para realizar la adaptación de la señal proveniente desdela unidad exterior. Esto permitirá utilizar el puerto de expansión de la RaspberryPi, adaptando el estándar RS-485 al puerto serie RS-232 compatible presente en laplataforma. Esto permitirá eliminar la dependencia de hardware ajeno y le brin-dará robustez a la unidad interna al poder controlar de forma interna la calidadde dicha interfaz de comunicación.

Se procederá a iniciar una nueva iteración con los requisitos que fueron excluidosde la primera, para aumentar las capacidades del prototipo. Un elemento impor-tante de la siguiente iteración será la implementación de la sección de calibración,que permitirá a VSATMotion S.R.L. utilizar la unidad interna durante la etapa defabricación al facilitar la puesta a punto de los sensores de la unidad exterior.

41

Bibliografía

[1] Empresa Argentina de Soluciones Satelitales Sociedad Anónima. SistemaSatelital Geoestacionario Argentino de Telecomunicaciones. Disponible:2017-07-08. URL: http://www.arsat.com.ar/satelites/.

[2] Fundación Alma. Tren Hospital para Chicos Alma. Disponible: 2017-07-12.URL: http://fundacionalma.org.ar/wp/.

[3] Hassan Gomaa. Designing Concurrent, Distributed, and Real-Time Applicationswith UML. Guías técnicas. Adison-Wesley, 2000. ISBN: 9780321951816. URL:https://books.google.com.ar/books?id=R6dQAAAAMAAJ.

[4] J. Reynolds J. Postel. TELNET PROTOCOL SPECIFICATION. RFC 854.Mayo de 1983. URL: https://tools.ietf.org/html/rfc854.

[5] Gérard Maral. VSAT networks. 2.a ed. Wiley InterScience electroniccollection. John Wiley & Sons, 2004. ISBN: 0-470-86684-5. URL:https://books.google.com.ar/books?id=47mTmPwkZNgC.

[6] Oracle. Java Platform, Standard Edition (Java SE) 8. Disponible: 2017-07-08.URL: http://docs.oracle.com/javase/8/javase-clienttechnologies.htm.

[7] Proyecto CIAA. Computadora Industrial Abierta Argentina. Disponible:2016-06-25. 2014. URL:http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start.

[8] VSATMotion. Antena auto-orientable para enlaces satelitales. Disponible:2017-07-07. URL: http://vsatmotion.com/.