UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Sistema de referencia de actitud y rumbopara una antena auto-orientable

Autor:Ing. Alejandro Permingeat

Director:Ing. Juan Cecconi (UTN-FRBA)

Jurados:Mg. Ing. Diego Brengi (INTI, UNLAM)

Ing. Gustavo Alessandrini (INTI)Bioing. Jerónimo Labruna (FIUBA)

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

III

Resumen

La presente memoria describe el diseño e implementación de un sistema querecolecta datos de un acelerómetro, un magnetómetro, un giróscopo y un GPSvinculados con el plato parabólico de una antena satelital auto-orientable (tipoVSAT) y determina la posición y orientación del plato parabólico, información

necesaria para poder apuntar correctamente la antena hacia un satélite.

El software implementado corre sobre una placa diseñada por el laboratorio deMicro y Nano Electrónica del INTI e interactúa en forma directa con la CIAA

utilizada como unidad de control de apuntamiento de la antena auto-orientabley forma parte de un producto comercial de la empresa VSATMotion S.R.L.

Este trabajo comprende el análisis de la problemática, la elección de laarquitectura adecuada, el diseño detallado, la implementación del software

generado a partir del modelo y los ensayos funcionales de calificación, todo loanterior bajo un enfoque MBSE (ingeniería de sistema dirigida por modelo)

V

Agradecimientos

A Jesucristo, mi fuente de inspiración.

A mi esposa por su infinita tolerancia y paciencia.

A mis padres y hermanas.

Al hermoso ecosistema tecnológico que constituye el Laboratorio de SistemasEmbebidos de la Universidad de Buenos Aires.

VII

Índice general

Resumen III

1. Introducción General 11.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1. Antenas tipo VSAT . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2. Necesidad de sensores para asistir el apuntamiento . . . . . 2

1.2. AHRS: Sistema de referencia de actitud y rumbo . . . . . . . . . . . 31.3. Ingeniería de software dirigida por modelos . . . . . . . . . . . . . 41.4. Objetivos y Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1. Objetivos principales . . . . . . . . . . . . . . . . . . . . . . . 51.4.2. Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . 5

2. Introducción Específica 72.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1. Primera iteración . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.2. Segunda iteración . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Metodología de desarrollo de software . . . . . . . . . . . . . . . . . 92.2.1. Modelo de requerimientos . . . . . . . . . . . . . . . . . . . . 92.2.2. Modelo de análisis . . . . . . . . . . . . . . . . . . . . . . . . 102.2.3. Modelo de diseño . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Modelado e Implementación 133.1. Descripción del hardware . . . . . . . . . . . . . . . . . . . . . . . . 133.2. Modelo de requerimientos . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1. Descripción de casos de uso . . . . . . . . . . . . . . . . . . . 153.3. Modelo de análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1. Modelado estático del dominio del problema . . . . . . . . . 173.3.2. Modelado dinámico del dominio del problema . . . . . . . . 23

3.4. Modelo de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.1. Definición de arquitectura de software . . . . . . . . . . . . . 243.4.2. Diseño detallado de componentes . . . . . . . . . . . . . . . 25

3.5. Implementación del software . . . . . . . . . . . . . . . . . . . . . . 283.5.1. Kinetis Design Studio . . . . . . . . . . . . . . . . . . . . . . 293.5.2. Processor Expert vs Kinetis SDK . . . . . . . . . . . . . . . . 303.5.3. Biblioteca Freemodbus . . . . . . . . . . . . . . . . . . . . . . 313.5.4. Biblioteca Xtrinsic eCompass . . . . . . . . . . . . . . . . . . 323.5.5. Biblioteca miNMEA . . . . . . . . . . . . . . . . . . . . . . . 33

4. Ensayos y Resultados 354.1. Plan de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.1. Base de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1.2. Estrategia de prueba . . . . . . . . . . . . . . . . . . . . . . . 354.1.3. Matriz de estrategia . . . . . . . . . . . . . . . . . . . . . . . 36

VIII

4.1.4. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2. Desarrollo de ensayos . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3. Resultados de ejecución . . . . . . . . . . . . . . . . . . . . . . . . . 38

5. Conclusiones 395.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 395.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Bibliografía 41

IX

Índice de figuras

1.1. Posición de AHRS (Sistema de Referencia de Actitud y Rumbo) enantena VSATMotion. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Diagrama en bloques de los componentes de un AHRS. . . . . . . . 4

2.1. Requerimientos de usuario de alto nivel. . . . . . . . . . . . . . . . . 7

3.1. Fotografía de placa VSATM-015. . . . . . . . . . . . . . . . . . . . . 143.2. Fotografía de placa FRDM-KE02Z. . . . . . . . . . . . . . . . . . . . 153.3. Diagrama esquemático de placa VSATM-015. . . . . . . . . . . . . . 163.4. Diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . 173.5. Diagrama de actividad del caso de uso ”colectar información de

sensores” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.6. Diagrama de actividad del caso de uso ”calcular actitud y rumbo” . 193.7. Diagrama de actividad del caso de uso ”calibrar magnetómetro” . . 203.8. Diagrama de actividad del caso de uso ”obtener actitud y rumbo” . 213.9. Diagrama de actividad del caso de uso ”obtener datos crudos de

sensores” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.10. Diagrama de clases del contexto del sistema . . . . . . . . . . . . . . 233.11. Diagrama de clases de las entidades del software . . . . . . . . . . . 243.12. Diagrama de clases de las interfaces del software . . . . . . . . . . . 253.13. Diagrama de objetos de las interfaces del software . . . . . . . . . . 263.14. Diagrama de comunicación de consulta datos a Acelerómetro . . . 273.15. Diagrama de comunicación del cálculo de actitud y rumbo . . . . . 273.16. Patrón capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.17. Patrón observar reaccionar . . . . . . . . . . . . . . . . . . . . . . . . 283.18. Patrón hibrido adoptado . . . . . . . . . . . . . . . . . . . . . . . . . 293.19. Componente ”HAL”. . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.20. Componente ”Proceso observador”. . . . . . . . . . . . . . . . . . . 313.21. Componente ”Proceso de análisis”. . . . . . . . . . . . . . . . . . . . 323.22. Componente ”Proceso de despliegue”. . . . . . . . . . . . . . . . . . 323.23. Diagrama en bloques de la arquitectura de biblioteca Xtrinsic eCom-

pass. [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.24. Sistema de coordenadas ENU utilizado por Android. [4] . . . . . . 34

4.1. Configuración de pruebas. . . . . . . . . . . . . . . . . . . . . . . . . 38

XI

Índice de Tablas

3.1. Métricas del uso de recursos del microcontrolador. . . . . . . . . . . 29

4.1. Importancia relativa de las características de calidad. . . . . . . . . 364.2. Matriz de importancia relativa por componente y característica de

calidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3. Matriz de importancia relativa por componente y nivel de prueba. 374.4. Cantidad de ensayos escritos por componente y nivel de prueba. . 37

XIII

Dedicado a Corina

1

Capítulo 1

Introducción General

En este capítulo se indica la necesidad concreta que dio origen a este proyecto;posteriormente se describen los conceptos básicos involucrados tanto en un siste-ma AHRS (Sistema de Referencia de Actitud y Rumbo), como en la ingeniería desoftware dirigida por modelos y por último se incluyen los objetivos principalesy el alcance del proyecto.

1.1. Motivación

El sistema desarrollado en el presente trabajo forma parte de un sistema mayor elcual consiste en una antena auto-apuntable tipo VSAT (terminal de apertura muypequeña), cuyo nombre comercial es VSATMotion.

Este sistema surge de la necesidad concreta del proyecto VSATMotion [10] decontar con un sistema de sensores que informen en todo momento la orientacióndel plato parabólico.

1.1.1. Antenas tipo VSAT

Las antenas tipo VSAT se emplean para establecer enlaces satelitales entre dospuntos terrestres que no necesariamente tengan linea de vista entre sí, utilizandoun satélite geoestacionario como ”repetidor”.

Estas antenas poseen un plato parabólico con un diámetro que puede variar en-tre 0.80 metros y 2.40 metros, con un valor muy difundido de 1.2 metros paraservicios de transmisión y recepción.

En general estas antenas se utilizan para comunicaciones en las siguientes ban-das, establecidas por la Unión Internacional de Telecomunicaciones:

Banda Ku. Rango de frecuencias que va desde 11,7 GHz a 12.7 GHz (frecuen-cias de bajada) y desde 14 GHz a 14.5 GHz (frecuencias de enlace ascenden-te)[9].

Banda Ka. Rango de frecuencias que va desde 18.3GHz a 18.8GHz y desde19.7 GHz y 20.2 Ghz (frecuencias de bajada) y desde 27.5GHz a 31 GHz(frecuencias de enlace ascendente)[8].

Banda C. Rango de frecuencias que va desde 3.7 GHz a 4.2 GHz (frecuenciasde bajada) y desde 5.925 GHz a 6.425 GHz (frecuencias de enlace ascenden-te)[7].

2 Capítulo 1. Introducción General

1.1.2. Necesidad de sensores para asistir el apuntamiento

Durante el apuntamiento del plato parabólico hacia un satélite geoestacionario, esnecesario conocer su posición absoluta con respecto al norte magnético y al planotangencial terrestre; y su posición relativa con respecto a la base de la antena.

Para cubrir la necesidad de obtener mediciones absolutas de la orientación delplato parabólico se planteó el desarrollo de un sistema que pueda funcionar co-mo un inclinómetro y brújula digital, que vaya adosado a la espalda del plato,tal como se puede observar en la figura 1.1. Para ello se decidió utilizar un ace-lerómetro y un magnetómetro del tipo MEMS1. Debido a que estos dispositivosse integrarían en una misma placa electrónica (VSATM-015), la cual incluiría unmicrocontrolador, y que se contaría con una infraestructura solida para realizarmediciones con sensores, se decidió incorporar también un giróscopo del tipoMEMS, ya que solo implicaba un esfuerzo muy pequeño su incorporación. Deesta manera se disponía de una placa electrónica con todos los sensores necesa-rios para conformar un AHRS (Sistema de Referencia de Actitud y Rumbo). Versección 1.2.

FIGURA 1.1: Posición de AHRS (Sistema de Referencia de Actitudy Rumbo) en antena VSATMotion.

1 MEMS: Sistemas Microelectromecánicos (Microelectromechanical Systems) se refieren a la tec-nología electromecánica, micrométrica y sus productos, y a escalas relativamente más pequeñas(escala nanométrica) se fusionan en sistemas nanoelectromecánicos (Nanoelectromechanical Sys-tems, NEMS) y Nanotecnología. https://es.wikipedia.org/wiki/Sistemas_microelectromecánicos

1.2. AHRS: Sistema de referencia de actitud y rumbo 3

Adicionalmente, para poder dar soporte al cálculo de la orientación objetivo delplato, el sistema VSATMotion requiere información de su geolocalización. Por talmotivo, se incorporó un GNSS (GPS/Glonass) a la placa electrónica del AHRS,agregando indirectamente la capacidad de poder realizar correcciones a las des-viaciones producidas por errores acumulativos del giroscopio a lo largo del tiem-po.

La placa fue diseñada por el laboratorio de Micro y Nano Electrónica del INTI(Instituto Nacional de Tecnología Industrial) dentro del marco de cooperacióncon la empresa VSATMotion, pero dichas actividades no incluyeron el desarro-llo del software. Es precisamente el desarrollo del software para la mencionadaplaca, el objetivo de este proyecto.

1.2. AHRS: Sistema de referencia de actitud y rumbo

Un sistema de referencia de actitud y rumbo (AHRS del inglés attitude and hea-ding reference system), es un sistema de sensores de tres ejes que proporciona laposición de actitud (cabeceo, rolido y rumbo) en 3D y en tiempo real. La funciónprincipal de un AHRS es proporcionar datos de orientación. Los AHRS están di-señados para reemplazar los instrumentos tradicionales basados en giroscopios ypara proporcionar una fiabilidad y una precisión superiores.

Algunas de las muchas aplicaciones de los AHRS incluyen control y estabilización,medición y corrección, y navegación. Un ejemplo de control y estabilización se presentacuando una cámara o antena montada en un sistema como un avión o un buquenecesita ser estable. La medición y corrección se aplican mejor a los sistemas deimagen en los que se utiliza un AHRS para asegurar la dirección en la que seapunta el generador de imágenes. Y en navegación, un AHRS se puede utilizarpara proporcionar orientación y dirección.

Los AHRS se componen de magnetómetros, acelerómetros y giroscopios en lostres ejes. Es muy común que se emplee tecnología microelectomecánica (MEMS)debido en parte a su costo, pero principalmente por el factor escala. En otraspalabras, un AHRS basado en MEMS incluye sensores para medir magnetismo entres ejes, aceleración en tres ejes y velocidad angular en tres ejes. Estos sensores,combinados con un procesador incorporado, crean un sistema de sensor inercialtotalmente capaz de medir la actitud de los objetos en el espacio 3D.

Los sensores en AHRS utilizan algoritmos para estimar esta actitud en el espacio3D. Algunas unidades de AHRS utilizan algoritmos de filtro Kalman tradiciona-les que emplean mediciones magnéticas y de aceleración para estimar el sesgode giroscopio variable en tiempo real. Otros sistemas AHRS utilizan filtros no-Kalman modificados que calculan una estimación de la orientación en tiemporeal. Una ventaja potencial de estos algoritmos modificados es que pueden supe-rar a los sensores tradicionales basados en filtros de Kalman proporcionando unaoptimización en tiempo real del rendimiento para entornos operativos magnéti-cos o dinámicos variables. [6]

Debido al error acumulado de las mediciones del giroscopio a lo largo del tiempose puede observar una desviación incremental entre la posición calculada y la po-sición real. Para mejorar la precisión de la medición se le agrega un sensor GNSS

4 Capítulo 1. Introducción General

(Sistema global de navegación por satélite), de esta manera se logra estabilizar losvalores leídos del giroscopio a largo plazo.

En la figura 1.2 se puede observar un diagrama en bloques de los componentesprincipales de un AHRS.

FIGURA 1.2: Diagrama en bloques de los componentes de unAHRS.

1.3. Ingeniería de software dirigida por modelos

Para abordar el desarrollo de software se pueden seguir básicamente dos cami-nos: ingeniería de software orientada a documentos o ingeniería de software (osistemas) dirigida por modelos (MBSE: Model Based System Engineering).

La primera opción consiste en aplicar los procesos de desarrollo de software clá-sicos e ir generando artefactos (artifacts) en forma de un conjunto disyunto dedocumentos de texto, hojas de cálculo, diagramas y presentaciones. Este es unenfoque muy ”caro” para el proceso de desarrollo, ya que un porcentaje signifi-cativo del costo del ciclo de vida se emplea en mantener ese conjunto disyunto deartefactos. Incluso si no se paga ese costo, los artefactos se vuelven inconsistentesy obsoletos.

En cambio en la segunda opción (MSBE) se realizan las mismas actividades delciclo de vida y se produce el mismo conjunto de entregables, pero dichos entre-gables no son un resultado inmediato de las actividades del ciclo de vida (noson los artefactos primarios). Con el enfoque MBSE, el artefacto principal de esasactividades es un modelo de sistema integrado, coherente y consistente, creadomediante el uso de una herramienta de modelado de sistemas dedicada. Todoslos demás artefactos son secundarios, generados automáticamente a partir delmodelo del sistema utilizando la misma herramienta de modelado.

El modelo del sistema sirve como un repositorio central para las decisiones dediseño. Cada decisión de diseño se captura como un elemento de modelo (o unarelación entre elementos) en un solo lugar dentro del modelo del sistema. Conel enfoque MBSE, todos los diagramas y artefactos de texto generados automáti-camente son meras vistas del modelo del sistema subyacente. No son el propiomodelo. [1]

1.4. Objetivos y Alcances 5

1.4. Objetivos y Alcances

1.4.1. Objetivos principales

El objetivo principal de este proyecto es el desarrollo del software (firmware) deuna placa modelo VSATM-015, con el fin de constituir un sistema que ofrezcaservicios de orientación y rumbo.

En dicho software la prioridad es obtener y procesar datos del acelerómetro y delmagnetómetro de modo que el sistema pueda brindar una funcionalidad equiva-lente a un inclinómetro digital y a una brújula digital.

Adicionalmente el software debe obtener e interpretar la información generadapor el GNSS acerca de la geolocalización (latitud, longitud, altura), así como tam-bién la fecha y la hora actual.

1.4.2. Alcance del proyecto

Durante la ejecución del proyecto se propusieron las siguientes funcionalidades:

Infraestructura básica del software. Involucró el desarrollo de la capa de abs-tracción de hardware y la incorporación de un módulo de comunicacióncon la CIAA (Modbus/RS-485)

Comunicación con los sensores. Incluyó la obtención de los datos crudos delacelerómetro, magnetómetro, giróscopo (todos ellos en 3 ejes) y los datosdel GNSS.

Calibración del magnetómetro. Comprendió la incorporación de un algoritmode compensación de distorciones generadas por soft iron y hard iron2.

Fusión de datos de sensores básica. Abarcó la utilización de un algoritmo básicopara obtener el cuaternion de orientación y datos filtrados de inclinación.

Originalmente se había planteado el calculo de inclinación, velocidad angular yvector norte para los planos “xy”, “yz” y “xz”, como una primer etapa de proce-samiento. Sin embargo esto fue reemplazado por un algoritmo de fusión de datos,ya que no insumió demasiado esfuerzo incorporarlo al software y brindaba nivelde procesamiento superior al planteado originalmente.

Con respecto a la infraestructura de desarrollo, se puso en marcha un servidor deintegración continua (Jenkins) y se utilizó un sistema de repositorios Git para elcontrol de versiones de software. Adicionalmente dicho repositorio git se man-tuvo sincronizado con un servidor de alojamiento de repositorios basado en web(Bitbucket).

Para asegurar la calidad se realizaron pruebas unitarias y pruebas de sistemas.

2La distorsión ”hard-iron” es la distorción producida por un material que manifiesta un cam-po aditivo constante al campo magnético terrestre, y de esta manera un valor aditivo constantea la salida de cada eje del magnetómetro. La distorsión ”soft-iron’ es el resultado de materialesque influencian o distorsionan un campo magnético, pero que no necesariamente generan un cam-po magnético por si mismos y por lo tanto no es aditivo. https://www.digikey.com/en/ptm/h/honeywell-microelectronics--precision-sensors/hard-iron-and-soft-iron-calibration

7

Capítulo 2

Introducción Específica

Este capítulo presenta las características específicas que debe poseer el softwa-re, incluyendo los requerimientos de usuario de alto nivel, los requerimientos endetalle y cuales de ellos se abordaron en cada iteración. Además se describe lametodología de desarrollo seleccionada, indicando sus fases y las tareas involu-cradas en cada una de ellas.

2.1. Requisitos

Para el desarrollo de este software se planteó un conjunto de requerimientos deusuarios al momento de definir la planificación. Posteriormente se desarrolló unconjunto de requerimientos de software (mayor nivel de detalles), discriminandoentre requerimientos funcionales, de interfaz y no funcionales. Dicho conjunto derequerimientos se reflejó en un documento con código VSATM-ER-0010-A.

En la figura 2.1 se observan los requerimientos de usuarios de alto nivel.

FIGURA 2.1: Requerimientos de usuario de alto nivel.

A continuación se indican cuales requerimientos de usuarios indicados en la pla-nificación de este proyecto (documento con código interno VSATM-G-0010-A) seabordaron por cada iteración.

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

2.1.1. Primera iteración

La primer iteración se enfocó en los requerimientos relacionados a la infraestruc-tura del software, sobre todo aquellos que tienen que ver con la comunicacióncon los sensores y con la CIAA.

Puntualmente los requerimientos abordados en esta iteración fueron:

Se debe generar un documento de requerimiento de sistema a partir de losrequerimientos de usuarios listados a continuación [REQ001]

Se debe encuestar al magnetómetro, acelerómetro, giróscopo cada 100 ms.[REQ004]

Se deben obtener del magnetómetro, acelerómetro y giróscopo los valoresleídos en los 3 ejes. [REQ005]

Se debe brindar la información al usuario a través del canal RS-485 [REQ008]

El software debe correr sobre una placa VSATM-015 versión 1. [REQ016]

El software debe estar bajo control de versiones (git) [REQ017]

El software debe ser implementado en C [REQ018]

El modelo del software debe ser implementado en una herramienta CASE.[REQ019]

2.1.2. Segunda iteración

La segunda iteración se enfocó en los requerimientos relacionados con el procesa-miento de la información de los sensores y con la generación de la documentaciónde verificación y validación.

Se debe generar un manual de usuario [REQ002]

Se debe generar un documento de casos de pruebas [REQ003]

Se debe obtener la latitud, longitud y altura del GPS cada 1 segundo. [REQ006]

Se debe obtener la hora del GPS cada 1 segundo [REQ007]

Se debe poder calibrar el magnetómetro para superar interferencias del tipohard-iron y soft-iron [REQ009]

Se debe poder indicar cuál es la inclinación con respecto al vector grave-dad para cada uno de los planos “xy”, “yz” y “xz” del sensor acelerometro.[REQ010]

Se debe poder indicar cuál es la de velocidad angular para cada uno de losplanos “xy”, “yz” y “xz”. [REQ011]

Se debe poder indicar cuál es el azimut con respecto al vector norte magné-tico para los planos “xy”, “yz” y “xz”. [REQ012]

Se debe generar una matriz de trazabilidad entre el documento de diseño ylos requerimientos. [REQ013]

2.2. Metodología de desarrollo de software 9

Se debe generar una matriz de trazabilidad entre los módulos de softwarey los módulos de diseño. [REQ014]

Se debe generar una matriz de trazabilidad entre las pruebas de integracióny los requerimientos. [REQ015]

Los requerimientos [REQ010], [REQ011] y [REQ012] fueron reemplazados por lossiguientes requerimientos

El software debe determinar la orientación en 3 ejes (cabeceo, alabeo y gi-ñada) cada 100 milisegundos [REQ20]

El software debe determinar el rumbo (ángulo de desviación con respectoal norte magnético) cada 100 milisegundos [REQ21]

2.2. Metodología de desarrollo de software

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

COMET es un método de modelado y diseño de software basado en casos de usoiterativos y paradigma orientados a objetos que aborda específicamente las fasesde modelado de requisitos, de análisis y de diseño dentro del ciclo de vida dedesarrollo de software. Esta metodología emplea diagramas UML (Lenguaje deModelado 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 CASE1 (Ingeniería de Software Asistida por Computadora)para el modelado se ha empleado Enterprise Architect.

2.2.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.

Las actividades involucradas en el modelado de requisitos son:

1Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asisti-da por Computadora) son diversas aplicaciones informáticas o programas informáticos destinadasa aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas entérminos de tiempo y de dinero.

Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del soft-ware en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementa-ción de parte del código automáticamente con el diseño dado, compilación automática, documen-tación o detección de errores entre otras.https://es.wikipedia.org/wiki/Herramienta_CASE

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

1. Desarrollar un diagrama de casos de uso. Describir los actores y casos de uso.Definir las relaciones entre casos de uso.

2. Documentar cada caso de uso en una descripción de casos de uso. Esto provee unadescripción narrativa de cada caso de uso.

2.2.2. Modelo de análisis

En el modelo de análisis, el caso de uso se ”realiza” para describir los objetos queparticipan en el caso de uso y sus interacciones.

Las actividades involucradas en la confección del modelo de análisis son:

1. Desarrollo modelo estático del dominio del problema. Analizar el punto de vistaestático del sistema en el modelo estático, en términos de las clases, relacio-nes y atributos.

2. Estructurar el sistema en clases y objetos. Aplicar el criterio de estructuraciónde objetos para determinar los objetos y clases en el sistema. Determinar lossubsistemas de alto nivel. Agregar clases al diccionario de clases.

3. Desarrollar el modelo dinámico. Determinar los objetos que participan en cadacaso de uso y desarrollar un diagrama de comunicación mostrando la se-cuencia en la interacción de dichos objetos. Para aquellos objetos que seandependientes de estado, desarrollar un diagrama de statechart.

2.2.3. Modelo de diseño

En el modelo de diseño, se desarrolla la arquitectura del software, describiendolos componentes y sus interfaces.

Las actividades involucradas en la confección del modelo de diseño son:

1. Sintetizar artefactos del modelo de análisis para producir una arquitectura inicialde software. Esto incluye sintetizar diagramas de statecharts, diagramas decomunicación y diagramas de clases.

2. Diseñar la arquitectura de software en su conjunto. Estructurar la aplicación ensubisistemas. Definir sus interfaces. Aplicar el criterio de estructuración desubsistema.

3. Diseñar la arquitectura de componentes de software distribuido. Para una aplica-ción distribuida, determinar cómo serán distribuidos los componentes desubsistemas. Definir las interfaces de comunicación para los mensajes.

4. Diseñar la arquitectura de tareas concurrentes. Estructurar los subsistemas entareas concurrentes. Definir sus interfaces. Desarrollar diagramas de cola-boración concurrente.

5. Analizar el rendimiento (performance) del diseño. Aplicar la planificación detiempo real para determinar si el diseño de la concurrencia en tiempo realcumplirá sus metas de rendimiento.

6. Diseñar las clases de cada subsistema. Diseñar las interfaces de las clases inclu-yendo sus operaciones.

2.2. Metodología de desarrollo de software 11

7. Desarrollar el diseño de software detallado. Diseñar el interior de las clases com-puestas incluyendo los mecanismo de sincronización.

8. Analizar el rendimiento del diseño de tiempo real. Aplicar un análisis en mayordetalle del rendimiento en tiempo real para cada subsistema.

13

Capítulo 3

Modelado e Implementación

En este capítulo se realiza un abordaje profundo acerca de cómo fue construidoel software, incluyendo los detalles de la plataforma de hardware donde se ejecu-tará la aplicación, los distintos modelos desarrollados siguiendo la metodologíadescrita en el capítulo anterior y las bibliotecas de software empleadas.

3.1. Descripción del hardware

El software desarrollado en este proyecto debe ejecutarse en un hardware espe-cialmente diseñado por el Laboratorio de Nano y Microelectrónica del INTI (Ins-tituto Nacional de Tecnología Industrial). Dicho hardware se emplaza dentro deun gabinete estanco, se alimenta de la línea principal de 24 Volts y se comunicacon la CIAA a través de Modbus/RS-485.

Este hardware está integrado por los siguientes componentes.

Microprocesador. Kinetis MKE02Z64VQH4 del fabricante NXP. Sus caracte-rísticas son:

• Nucleo ARM Cortex M0+

• 64 KB de tamaño de memoria de programa flash

• 4 KB de memoria RAM,

• 256 bytes EEPROM

• frecuencia de operación de nucleo 40 MHz

• frecuencia de operación de bus 20 MHz

Acelerómetro/magnetómetro. FXOS8700CQ del fabricante NXP. Sus caracterís-tica s son:

• Acelerómetro de tres ejes con resolución de 14-bits

• Aceleración seleccionable de forma dinámica en rangos de ±2 g / ±4g / ±8 g

• Magnetómetro de tres ejes con resolución de 16-bits

• Rango de medición magnético fijo de ±1200 µT

• Tasa de salida de datos de 1.563 Hz a 800 Hz seleccionable para cadasensor.

14 Capítulo 3. Modelado e Implementación

• Tasa de salida de datos de magnetísmo y de aceleración entrelazadosde hasta 400 Hz.

• Interfaz I2C y SPI

Giróscopo. FXAS21002C del fabricante NXP. Sus característica s son:

• Giróscopo de tres ejes con resolución de 16-bit

• Tasa de salida de datos de 12.5 to 800 Hz seleccionable.

• Rango de medición de velocidad angular de hasta ±2000 o/s

GNSS SE868-A del fabricante Telit. Sus características son:

• Utiliza constelaciones GPS, QZSS, y GLONASS

• Comandos NMEA y salida de datos por interfaz serie UART.

• Antena SMT integrada.

• 33 canales de tracking simultaneo

En la figura 3.1 se observa una imagen del prototipo de esta placa utilizado du-rante el desarrollo.

FIGURA 3.1: Fotografía de placa VSATM-015.

Como programador se utiliza una placa FRDM-KE02Z, como la de la figura 3.2.

En la figura 3.3 se observa un diagrama esquemático del hardware utilizado.

3.2. Modelo de requerimientos

Durante el modelado de requerimientos se llevó adelante el desarrollo de casosde uso. Se identificaron ocho casos de uso y dos actores.

El diagrama de casos de usos se puede observar en la figura 3.4

3.2. Modelo de requerimientos 15

FIGURA 3.2: Fotografía de placa FRDM-KE02Z.

3.2.1. Descripción de casos de uso

En esta sección se incluye una breve descripción de los casos de uso más repre-sentativos, junto con diagramas de actividad que indican el flujo principal y losflujos alternativos de los mismos.

El caso de uso ”colectar información de sensores” es activado periódicamentepor un timer y se encarga de encuestar el estado y luego los valores leídos delos sensores: acelerómetro, magnetómetro, giróscopo y GNSS. En la figura 3.5 sepuede observar un diagrama de actividades con la secuencia de pasos de estecaso de uso.

El caso de uso ”calcular actitud y rumbo” es activado periódicamente por un ti-mer y se ocupa de calcular la orientación (alabeo, giñada y cabeceo), el cuaternionde rotación y el ángulo con respecto al norte magnético. En la figura 3.6 se puedeobservar un diagrama de actividades con la secuencia de pasos de este caso deuso.

El caso de uso ”calibrar magnetómetro” es activado por el sistema externo y seencarga de tomar una serie de muestras del campo magnético para armar un mo-delo de perturbaciones del mismo. Una vez caracterizadas las perturbaciones seaplicará este modelo a cada medición posterior para quitar el ruido de las mismas.En la figura 3.7 se puede observar un diagrama de actividades con la secuenciade pasos de este caso de uso.

El caso de uso ”obtener actitud y rumbo” es activado por el sistema externo yse ocupa de enviarle a dicho sistema la orientación (alabeo, giñada y cabeceo), elcuaternion de rotación y el ángulo con respecto al norte magnético. En la figura3.8 se puede observar un diagrama de actividades con la secuencia de pasos deeste caso de uso.

El caso de uso ”obtener datos crudos de sensores” es activado por el sistemaexterno y se ocupa de enviarle a dicho sistema los datos crudos leídos de los sen-sores: acelerómetro, magnetómetro, giróscopo y GNSS. En la figura 3.9 se puedeobservar un diagrama de actividades con la secuencia de pasos de este caso deuso.

16 Capítulo 3. Modelado e Implementación

FIGURA 3.3: Diagrama esquemático de placa VSATM-015.

3.3. Modelo de análisis 17

FIGURA 3.4: Diagrama de casos de uso.

3.3. Modelo de análisis

Durante el desarrollo del modelo de análisis el enfoque está puesto en el dominiodel problema, para comprender en profundidad los detalles de la problemáticaque se está resolviendo. Se abordaron básicamente dos actividades:

Modelado estático. Esta actividad involucró la confección del diagrama decontexto y el diagrama de entidades. Adicionalmente se identificaron clasesde interfaz del software (bondary) y clases de control.

Modelado dinámico. Esta actividad involucró la confección de diagramas decomunicación de objetos para determinar la interacción dinámica del soft-ware.

3.3.1. Modelado estático del dominio del problema

La primera actividad abordada en el modelado estático del dominio del problemafue el desarrollo de un diagrama de clases que exponga el contexto del sistema.Dicho diagrama se puede observar en la figura 3.10 e incluye los elementos que

18 Capítulo 3. Modelado e Implementación

FIGURA 3.5: Diagrama de actividad del caso de uso ”colectar in-formación de sensores”

3.3. Modelo de análisis 19

FIGURA 3.6: Diagrama de actividad del caso de uso ”calcular ac-titud y rumbo”

20 Capítulo 3. Modelado e Implementación

FIGURA 3.7: Diagrama de actividad del caso de uso ”calibrar mag-netómetro”

3.3. Modelo de análisis 21

FIGURA 3.8: Diagrama de actividad del caso de uso ”obtener acti-tud y rumbo”

22 Capítulo 3. Modelado e Implementación

FIGURA 3.9: Diagrama de actividad del caso de uso ”obtener datoscrudos de sensores”

3.3. Modelo de análisis 23

FIGURA 3.10: Diagrama de clases del contexto del sistema

interactúan con el software. Básicamente dichos elementos son los sensores (ace-lerómetro, magnetómetro, giróscopo, GNSS) y el subsistema externo que consu-me la información generada por el software.

Posteriormente se identificaron clases entidad (aquellas clases que principalmen-te almacenan información) y se confeccionó un diagrama de clases que se puedeobservar en la figura 3.11. En dicho diagrama se pude apreciar la cadena de de-pendencia de la información.

Por último se identificaron las clases de interfaz del software (boundary), las cla-ses de control y las clases de lógica de aplicación. Particularmente las clases deinterfaz se volcaron en un diagrama de clases, indicando el vínculo de cada unade ellas con las clases externas al software, tal como puede apreciarse en la figura3.12. Adicionalmente se identificaron los mensajes que intercambian los objetosinterfaz, tal como se observa en la figura 3.13.

3.3.2. Modelado dinámico del dominio del problema

Para cada caso de uso se realizó un diagrama de comunicaciones poniendo espe-cial énfasis en los mensajes que intercambia cada objeto. Aquí solo se incluiránlos diagramas más representativos.

En el diagrama de comunicaciones de la figura 3.14 se observa la interacción delos objetos que participan al momento de consultar información al acelerómetro.Para el magnetómetro, giróscopo y GNSS (GPS/Glonass) la dinámica es muy si-milar.

En el diagrama de comunicaciones de la figura 3.15 se aprecia la interacción de losobjetos que participan en la determinación de la actitud (orientación y cuaternionde rotación) y el rumbo (desviación en grados con respecto al norte magnético).

24 Capítulo 3. Modelado e Implementación

FIGURA 3.11: Diagrama de clases de las entidades del software

3.4. Modelo de diseño

Durante el modelado del diseño se abordo en primer lugar la definición de laarquitectura del software. Posteriormente se llevó adelante el diseño detalladode cada uno de los componentes de la arquitectura.

3.4.1. Definición de arquitectura de software

Durante la definición de la arquitectura de software se seleccionaron dos arqui-tecturas de software y se integraron para confeccionar una arquitectura híbridaque se adapte a las necesidades concretas de este proyecto.

Por un lado se seleccionó una arquitectura en capas, con dos capas claramentedefinidas, como se observa en la figura 3.16

En la capa HAL se encuentran los drivers encargados de abstraer los detalles deacceso al hardware. De esta manera se facilitará la migración a otro microcontro-lador en caso de que en el futuro hiciese falta. Adicionalmente permite una mayorclaridad en la implementación, separando los drivers de la lógica de la aplicación.

En la capa de aplicación se encuentran todos los componentes que encapsulan lalógica de aplicación.

3.4. Modelo de diseño 25

FIGURA 3.12: Diagrama de clases de las interfaces del software

Por otro lado se seleccionó una arquitectura ”Observar y Reaccionar”, la cualsepara en componentes distintos el acceso a los sensores, el procesamiento de losdatos y el despliegue de los mismos, tal como se observa en la figura 3.17. [5]

Al aplicar ambos patrones se ha constituido un patrón híbrido de dos capas, talcomo se indica en la figura 3.18. La capa inferior es la capa de abstracción de hard-ware. La capa superior, correspondiente a la aplicación, incluye los componentesde un patrón observar reaccionar, pero sin los componentes ”Proceso Alarma” y”Proceso Reactor’

Este patrón híbrido contiene los siguientes componentes:

HAL: Componente de abstracción de Hardware. Capa que contiene los driversdel software que encapsulan el acceso al hardware

PO: Proceso Observador. Componente que se ocupa de recopilar la informa-ción de los sensores

PA: Proceso de análisis. Componente que se ocupa de procesar los datos cru-dos leídos de los sensores (incluye la calibración del magnetómetro y lafusión de los datos)

PD: Proceso de despliegue. Componente encargado de poner disponible losdatos al cliente

3.4.2. Diseño detallado de componentes

Todas las clases identificadas durante el modelado de análisis, se sintetizan en unsolo diagrama que contiene todas las relaciones estáticas entre clases. Del mismomodo, todos los objetos identificados se sintetizan en un solo diagrama de comu-nicaciones que contiene todos los mensajes que intercambian dichos objetos. Estees el paso llamado ”sintesis de objetos y clases” en el proceso COMET.

Luego se separan las clases y objetos y se los asigna a cada componente determi-nado según la arquitectura elegida.

26 Capítulo 3. Modelado e Implementación

FIGURA 3.13: Diagrama de objetos de las interfaces del software

3.4. Modelo de diseño 27

FIGURA 3.14: Diagrama de comunicación de consulta datos a Ace-lerómetro

FIGURA 3.15: Diagrama de comunicación del cálculo de actitud yrumbo

28 Capítulo 3. Modelado e Implementación

FIGURA 3.16: Patrón capas

FIGURA 3.17: Patrón observar reaccionar

En la figura 3.19 se pueden observar los objetos que forman parte del componenteHAL.

En la figura 3.20 se pueden observar los objetos que forman parte del componente”Proceso observador”.

En la figura 3.21 se pueden observar los objetos que forman parte del componente”Proceso de análisis”.

En la figura 3.22 se pueden observar los objetos que forman parte del componente”Proceso de despliegue”.

3.5. Implementación del software

La implementación del software se realizó en lenguaje C utilizando el ambientede desarrollo Kinetis Design Studio versión 3.0. Ver sección 3.5.1.

Como capa HAL (Hardware Abstraction Layer), se analizaron dos opciones: Ge-nerado automáticamente por Proccesor Expert o utilizar el SDK incluido en el”FRDM-KE02Z Sample Code Package”. Finalmente se resolvió utilizar la HALincluida en el FRDM-KE02Z Sample Code package. Ver sección 3.5.2.

Para la comunicación Modbus sobre RS-485 se empleó la biblioteca de códigoabierto FreeModbus. Ver sección 3.5.2.

3.5. Implementación del software 29

FIGURA 3.18: Patrón hibrido adoptado

Para la calibración del magnetómetro, cálculo de la actitud (orientación) y cálculodel rumbo se utilizó la biblioteca eCompass version 3.0 del fabricante Freesca-le/NXP. Ver sección 3.5.4.

Por ultimo, se utilizó la biblioteca miNMEA como parser del estándar NMEA01831. Ver sección 3.5.5.

En la tabla 3.1 se puede observar el porcentaje del uso de memoria de programa,de datos, EEPROM y el tiempo libre de CPU

TABLA 3.1: Métricas del uso de recursos del microcontrolador.

Recurso Porcentaje uso

Memoria programa 78 %Memoria datos 95 %

Memoria EEPROM 0 %Uso CPU 15 %

El código fuente se mantiene bajo el sistema de control de versiones GIT.

Adicionalmente se ha utilizado el servidor de integración continua Jenkins, elcual revisa periódicamente el repositorio GIT y dispara la compilación y el enla-zado del software cuando detecta un cambio en el software.

3.5.1. Kinetis Design Studio

Como herramienta de desarrollo integrado (IDE) se utilizó Kinetis Design Studioversión 3.0

Esta herramienta consiste en un Eclipse Luna SR2 (4.4.2), con los siguientes plu-gins:

1NMEA 0183 es una especificación combinada eléctrica y de datos entre aparatos electrónicosmarinos y, también, más generalmente, receptores GPS. https://es.wikipedia.org/wiki/NMEA_0183

30 Capítulo 3. Modelado e Implementación

FIGURA 3.19: Componente ”HAL”.

GNU ARM Eclipse Plugins, para dar soporte al desarrollo de software paranucleso ARM en Eclipse. Versión: 2.6.1.

Freescale Processor Expert, para generar automáticamente la capa de abstrac-ción de hardware (HAL) para los microcontroladores de la línea Kinetis deNXP.

Este IDE incluye el conjunto de herramientas GNU ARM Embedded Toolchainversión 4.8, lo cual involucra entre otras herramientas al compilador arm-none-eabi-gcc.

Adicionalmente incorpora a GNU Make versión 3.82 como herramienta para au-tomatizar el proceso de construcción (compilación) del software.

Por último, como herramienta de depuración incluye ”pemicro” para dar soportea los adaptadores de depuración P&E.

3.5.2. Processor Expert vs Kinetis SDK

Al momento de definir el conjunto de drivers que constituiría la capa HAL, sedisponía de dos opciones.

Por un lado se encontraba la opción de utilizar los drivers generados automáti-camente por la herramienta Processor Expert. Esta herramienta es muy potente,ya que permite generar los drivers de manera had-hoc y a través de una inter-faz gráfica provista por el plugin Proccesor Expert del IDE Kinetis Design Studio.Tiene la ventaja de ser muy simple de generar y de mantener, pero genera bas-tante overhead en el uso de memoria de datos y de programas, ya que utiliza doscapas con distintos niveles de abstracción de hardware.

3.5. Implementación del software 31

FIGURA 3.20: Componente ”Proceso observador”.

Por otro lado se disponía del SDK incluido en el software de ejemplo distribuidopor el fabricante para la línea de microcontroladores Kinetis MKE02Z2. Este SDKes mucho más simple y consume bastante menos memoria de datos y de progra-ma que los drivers generados por el Processor Expert. Sin embargo, no estabandesarrollados en profundidad todos los drivers necesarios.

En un primer momento se comenzó a utilizar los drivers generados por el Pro-cessor Expert. Luego de avanzar en las primeras fases de la implementación seobservó que el uso de memoria de datos y de programa era excesiva, sobre todopara un microcontrolador que dispone de muy poca memoria de datos y de pro-grama. A partir de ese momento se decidió migrar los drivers para utilizar el SDKdistribuido por el fabricante. Allí se debió modificar el driver de la UART (paramanejo de buffers independientes para cada UART) e I2C (escritura y lectura através de buffer).

3.5.3. Biblioteca Freemodbus

Para la interfaz Modbus2 se utilizó la biblioteca Freemodbus versión 1.5.0.

Dicha biblioteca es una implementación libre del protocolo Modbus, para la ar-quitectura maestro/esclavo tanto para la variante RTU como ASCII. Fue diseñadapara ser portable y está disponible para ARM STR71x, ATMega168, Freescale/-Motorola Coldfire MCF5235, TI-MSP430, LPC214X, Z8Encore, Win32 y Linux.

2Modbus es un protocolo de comunicaciones situado en el nivel 7 del Modelo OSI,basado en la arquitectura maestro/esclavo (RTU) o cliente/servidor (TCP/IP), diseña-do en 1979 por Modicon para su gama de controladores lógicos programables (PLCs).https://es.wikipedia.org/wiki/Modbus

32 Capítulo 3. Modelado e Implementación

FIGURA 3.21: Componente ”Proceso de análisis”.

FIGURA 3.22: Componente ”Proceso de despliegue”.

Particularmente para este proyecto se utiliza la variante ASCII sobre RS-485.

3.5.4. Biblioteca Xtrinsic eCompass

Para la fusión de los datos de los sensores, principalmente acelerómetro y magne-tómetro, se utilizó la biblioteca Xtrinsic eCompass del fabricante Freescale/NXP.El uso de esta biblioteca no requiere el pago de licencia cuando es utilizada conacelerómetros y magnetómetros del fabricante Freescale/NXP. Para este proyec-to en particular se utilizó el dispositivo FXOS8700CQ (ver sección 3.1) de dichofabricante.

Esta biblioteca esta implementada en código fuente ANSI C, ocupa menos de 10KBytes de memoria de programa y 4 KBytes de memoria de datos.

En la figura 3.23 se incluye un diagrama en bloques de la arquitectura. En dichodiagrama se pueden observar las etapas de calibración del magnetómetro y losdistintos sistemas de coordenadas para la fusión de los datos de los sensores. [2]

3.5. Implementación del software 33

FIGURA 3.23: Diagrama en bloques de la arquitectura de bibliote-ca Xtrinsic eCompass. [2]

Para este proyecto en particular se seleccionó el sistema de referencia de coor-denadas Android. Este es un sistema ENU: x=East, y=North, z=Up con signopositivo cuando el ángulo es anti-horario al ser observado a lo largo de un eje ensu dirección positivo, tal como se observa en la figura 3.24. [4].

Esta biblioteca debió ser adaptada para que requiera menor cantidad de memoriade datos ya que el microcontrolador seleccionado, solo cuenta con 4 KBytes de di-cha memoria. Para resolver tal motivo, se decidió disminuir el tamaño del bufferde las mediciones del magnetómetro utilizadas para determinar la perturbaciónhard-iron y soft-iron (de una matriz de 6x6x6 se cambio a una matriz de 5x5x5).Si bien la precision del modelo de perturbación se ve disminuida, no afecta drás-ticamente la calidad de las mediciones del magnetómetro, teniendo en cuenta losniveles de precision requeridos por el proyecto.

Adicionalmente se incorporó un conjunto de mediciones de magnetismo de ma-nera estática para que cuando inicie el algoritmo tenga información suficientecomo para realizar una calibración completa. De esta manera se prescinde de rea-lizar el proceso de calibración del magnetómetro cada vez que comienza a ejecu-tarse el algoritmo.

3.5.5. Biblioteca miNMEA

En primer lugar se evaluó la biblioteca ”nmealib”3 versión 0.5.3 como parserNMEA. Es una biblioteca de código abierto y de software libre, escrita en lenguajede programación C, pequeña y fácil de utilizar. Sin embargo al utilizar memoriadinámica, reservando memoria cada vez que recibe un nuevo mensaje NMEA,hace inviable su uso para este proyecto en el cual se cuenta con muy escaso espa-cio de memoria de datos.

3http://nmea.sourceforge.net/

34 Capítulo 3. Modelado e Implementación

FIGURA 3.24: Sistema de coordenadas ENU utilizado por An-droid. [4]

Posteriormente se analizó la biblioteca miNMEA4. Incluye un parser NMEA mi-nimalista escrito en lenguaje de programación C (ISO C99) para plataformas conrecursos muy escasos. No hace uso de memoria dinámica, ni de punto flotante.

Para este proyecto se selecciono la biblioteca miNMEA, habilitando solo el proce-samiento de los siguientes paquetes:

RMC. Datos específicos mínimos recomendados de GNSS (RecommendedMinimum Specific GNSS Data). De este tipo de mensajes se pueden obtenerla latitud, la longitud, la fecha y la hora.

GGA. Datos fijos del sistema de posicionamiento global (Global PositioningSystem Fixed Data). De este tipo de mensajes se pueden obtener la latitud,la longitud, la altura, la fecha y la hora

VTG. Curso sobre el terreno y velocidad sobre el terreno (Course Over Groundand Ground Speed). De este tipo de mensajes se pueden obtener la veloci-dad horizontal y el curso.

4https://github.com/cloudyourcar/minmea

35

Capítulo 4

Ensayos y Resultados

Al principio de este este capítulo se incluye la planificación realizada para abor-dar las pruebas, posteriormente se indica como fue el desarrollo de las mismas, ypor último se menciona el resultado de ejecutar las pruebas sobre el software.

4.1. Plan de pruebas

Para abordar las pruebas en el proyecto, se confeccionó un plan de ensayos. Elmismo incluye la definición de la base de test (test basis) y la estrategia de prueba.

4.1.1. Base de prueba

Para el desarrollo de los ensayos se consideraron las siguientes fuentes de infor-mación:

VSATM-G-0011-A Plan de proyecto. Desarrollo de software para un Sistemade Referencia de Actitud y Rumbo con interfaz con la CIAA

VSATM-ER-0010-A AHRS - Especificación de requerimientos de software

VSATM-ER-0018-A AHRS - Especificación de requerimientos de hardware

VSATM-UM-0001-A AHRS - Manual de usuario

Modelo de requerimientos (en herramienta Enterprise Architect)

Modelo de análisis (en herramienta Enterprise Architect)

Modelo de diseño (en herramienta Enterprise Architect)

4.1.2. Estrategia de prueba

Para los módulos de software de la capa de aplicación se planteó el desarrollode ensayos unitarios (unit tests) de tal manera que se pueda brindar una ampliacobertura del software. En cambio para la capa HAL solo se determinó crear unconjunto pequeño de ensayos unitarios, ya que dichos drivers son provistos porel fabricante.

En la tabla 4.1 se listan las características de calidad de software, junto con su im-portancia relativa. El criterio utilizado para determinar esta tabla consiste en iden-tificar en el documento de especificación de requerimientos de software, cuantos

36 Capítulo 4. Ensayos y Resultados

requerimientos están relacionados con cada una de las características de softwa-re. En otras palabras, la importancia relativa de las características de software secalculan de manera proporcional a la cantidad de requerimientos de software condichas características.

TABLA 4.1: Importancia relativa de las características de calidad.

Caracteristica de Calidad Importancia relativa

Funcionalidad 75 %Mantenibilidad 5 %

Rendimiento 20 %Total 100 %

4.1.3. Matriz de estrategia

Basado en el diseño funcional (ver sección 3.4), el software se divide en cuatrocomponentes:

HAL: Componente de abstracción de Hardware. Capa que contiene los driversdel software que encapsulan el acceso al hardware

PO: Proceso Observador. Componente que se ocupa de recopilar la informa-ción de los sensores

PA: Proceso de análisis. Componente que se ocupa de procesar los datos cru-dos leídos de los sensores (incluye la calibración del magnetómetro y lafusión de los datos)

PD: Proceso de despliegue. Componente encargado de poner disponible losdatos al cliente

En la tabla 4.2 se indica la importancia de la prueba para cada combinación decomponente / característica de calidad.

TABLA 4.2: Matriz de importancia relativa por componente y ca-racterística de calidad.

HAL PO PA PD5 % 35 % 30 % 30 %

Funcionalidad 75 % + ++ ++ ++Mantenibilidad 5 % +Rendimiento 15 % + +++ la característica de calidad es predominante para este componente+ la característica de calidad es relevante para este componente(vacío) la característica de calidad es insignificante para este componente

En la tabla 4.3 se indica la importancia de la prueba para cada combinación decomponente / nivel de prueba.

4.2. Desarrollo de ensayos 37

TABLA 4.3: Matriz de importancia relativa por componente y nivelde prueba.

HAL PO PA PD5 % 35 % 30 % 30 %

Pruebas unitarias 40 % + ++ + +Pruebas de sistema 45 % + ++ ++ ++Pruebas de aceptación 15 % + + +++ este componente sera cubierto ampliamente en este nivel de prueba+ este componente será cubierto en este nivel de prueba(vacío) este componente no será cubierto en este nivel de prueba

4.1.4. Herramientas

Como herramienta de soporte para las pruebas unitarias se utiliza la herramienta”ceedling” versión 0.28.1.

Como herramienta de soporte para la escritura y ejecución de las pruebas funcio-nales y de aceptación se utiliza ”Testlink” versión 1.9.16.

4.2. Desarrollo de ensayos

Se desarrollaron ensayos para los tres niveles de prueba: pruebas de unidad,pruebas de sistemas, pruebas de aceptación.

En la tabla 4.4 se observa la cantidad de ensayos realizados por cada nivel depruebas.

TABLA 4.4: Cantidad de ensayos escritos por componente y nivelde prueba.

HAL PO PA PD Total

Pruebas unitarias 5 13 5 6 29Pruebas de sistema 5 11 9 13 38Total 10 27 16 22 65

Para dar soporte al desarrollo de las pruebas a nivel sistemas y posteriormentepoder llevar adelante la ejecución de las mismas fue necesario confeccionar unambiente de prueba adecuado.

Por un lado se utilizó una EDU-CIAA con el firmware de microphyton para pro-bar toda aquella funcionalidad que implica la comunicación con un sistema ex-terno. Para ello se conectó la EDU-CIAA con una placa VSATM-015 a través deRS-485, tal como se puede observar en la figura 4.1. Se desarrollaron scripts enmicropython para dar soporte a la ejecución de estos ensayos.

Para realizar pruebas de rendimiento, se utilizó un osciloscopio Owon de 100MHz, apoyando las puntas en los pads de los leds de la placa VSATM-015, einstrumentando el código para que encienda y apague los leds cuando ingresa ysale respectivamente de la porción de código que se deseaba medir.

38 Capítulo 4. Ensayos y Resultados

FIGURA 4.1: Configuración de pruebas.

4.3. Resultados de ejecución

Los ensayos unitarios son ejecutados automáticamente en Jenkins sobre una PCconvencional (no se ejecutan en el target). Todos los ensayos unitarios han resul-tado satisfactorios.

Los ensayos a nivel sistema y a nivel aceptación son ejecutados manualmentesobre el target y registrados en Testlink. Todos los ensayos a nivel sistema y anivel aceptación han pasado satisfactoriamente.

39

Capítulo 5

Conclusiones

En este último capítulo se incluyen las conclusiones generales acerca del desarro-llo del proyecto. Posteriormente se indica que aspectos quedan pendientes parauna futura evolución del software.

5.1. Conclusiones generales

Durante la ejecución de este proyecto se han alcanzado los objetivos planteadosoriginalmente y también se aprovechó la oportunidad para desarrollar algunosde los requerimientos planteados para una etapa posterior, especialmente aque-llos relacionados con el cálculo avanzado de la actitud (cuaternion de rotación yfiltros pasa bajo).

Adicionalmente se abordó el modelado del software en forma completa, es decir,desde la especificación de requerimientos hasta la implementación y pruebas. Deesta manera se brinda un marco de trazabilidad de "punta a punta", lo cual cons-tituye un elemento de vital importancia en proyectos en los que se desea cumplircon normas de calidad tales como las normas DO-178c (software para industriaaeronáutica) o IEC-62304 (software para equipos médicos).

También se pusieron en marcha varias herramientas para dar un soporte sólido aeste tipo de desarrollos. Este dato no es menor, ya que esta experiencia ha brinda-do un amplio know-how que podrá ser capitalizado por la empresa VSATMotionS.R.L. para futuros proyectos que involucren una mayor complejidad y un equipode desarrollo más amplio.

5.2. Próximos pasos

Queda pendiente mejorar la conexión entre el driver RS-485 y el módulo modbus,para hacer un mejor uso de la pila de programa (memoria de datos) y de la rutinade atención de interrupción UART. Se comenzó a trabajar en esta mejora en unfork del repositorio, modificando la interfaz entre el driver RS-485 y el módulomodbus, pero en las pruebas de integración se observaba que se perdían algunosmensajes modbus de manera aleatoria. Por problemas de cronograma se decidiódejar esta mejora para una eventual nueva versión del software.

Adicionalmente se propuso a la empresa VSATMotion S.R.L. el reemplazo del mi-crocontrolador MKE02Z64VQH4 por MKE04Z64VQH4, de la placa VSATM-015,

40 Capítulo 5. Conclusiones

ya que son pin a pin compatibles, pero este último provee un tamaño de memo-ria de programa del doble de la capacidad del otro, lo cual permitirá ampliar elbuffer de calibración del magnetómetro y de esta manera obtener mejor precisionen el cálculo de la brújula digital.

41

Bibliografía

[1] Lenny Delligatti. SysML Distilled. A Brief Guide to the Systems ModelingLanguage. Guías técnicas. Pearson Education, Inc., 2014. ISBN:9780321927866. URL:https://books.google.com.ar/books?id=3bMJAgAAQBAJ&lpg.

[2] Freescale/NXP. Xtrinsic Sensor Fusion. Folleto ECOMPASSFS. Rev. 1.0.2013.

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

[4] Mark Pedley. Accelerometer and Magnetometer Sensor Simulation forTilt-Compensated eCompass. Nota de aplicación AN4696. Rev. 1.0.Freescale/NXP. 2013.

[5] Ian Sommerville. Ingeniería de Software, Novena Edición. Guías técnicas.Pearson Educación de México, S.A. de C.V., 2011. ISBN: 9786073206037.

[6] Sparton Navigation and Exploration. What is an AHRS? Disponible:2017-07-02. 2015. URL: http://www.spartonnavex.com/ahrs/.

[7] Tech-FAQ. C-band. Disponible: 2017-07-07. URL:http://www.tech-faq.com/c-band.html.

[8] Tech-FAQ. Ka-band. Disponible: 2017-07-07. URL:http://www.tech-faq.com/ka-band.shtml.

[9] Tech-FAQ. Ku-band. Disponible: 2017-07-07. URL:http://www.tech-faq.com/ku-band.shtml.

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