estimaciÓn de movimiento propio en vehÍculos...

ESTIMACIÓN DE MOVIMIENTO PROPIO EN VEHÍCULOS 1

Estimación de Movimiento Propio en Vehículos

Carlos Leonardo Arce Acosta, [email protected] Juan David Betancourt Garzón, [email protected]

Trabajo de Grado presentado para optar al título de Ingeniero de Sistemas

Asesor: Andrés Felipe Hurtado Bangera, Magíster (MSc) en Ingeniería

Universidad de San Buenaventura Colombia

Facultad de Ingeniería Ingeniería de Sistemas

Santiago de Cali, Colombia 2017


Citar/How to cite (Arce & Betancourt, 2017)

Referencia/Reference

Estilo/Style: APA 6th ed. (2010)

Arce, C.A & Betancourt, J.D. (2017). Estimación de Movimiento Propio en

Vehículos. (Trabajo de grado Ingeniería de Sistemas). Universidad de

San Buenaventura Colombia, Facultad de Ingeniería, Cali.

Bibliotecas Universidad de San Buenaventura

Biblioteca Fray Alberto Montealegre OFM - Bogotá.

Biblioteca Fray Arturo Calle Restrepo OFM - Medellín, Bello, Armenia, Ibagué.

Departamento de Biblioteca - Cali.

Biblioteca Central Fray Antonio de Marchena – Cartagena.

Universidad de San Buenaventura Colombia

Universidad de San Buenaventura Colombia - http://www.usb.edu.co/ Bogotá - http://www.usbbog.edu.co Medellín - http://www.usbmed.edu.co Cali - http://www.usbcali.edu.co Cartagena - http://www.usbctg.edu.co Editorial Bonaventuriana - http://www.editorialbonaventuriana.usb.edu.co/ Revistas - http://revistas.usb.edu.co/

Biblioteca Digital (Repositorio)

http://bibliotecadigital.usb.edu.co

https://co.creativecommons.org/?page_id=13

https://co.creativecommons.org/?page_id=13


TABLA DE CONTENIDO

1. Resumen -----------------------------------------------------------------------------------------------------------------7 2. Introducción -------------------------------------------------------------------------------------------------------------9 2.1 Contexto-------------------------------------------------------------------------------------------------------9 2.2 Planteamiento del problema ---------------------------------------------------------------------------10 2.3 Justificación de Problema--------------------------------------------------------------------------------10 2.4 Objetivo General-------------------------------------------------------------------------------------------11 2.5 Objetivos Específicos--------------------------------------------------------------------------------------11 2.6 Descripción de la Solución--------------------------------------------------------------------------------11 2.6.1 Proceso de Ingeniería------------------------------------------------------------------------11 2.6.2 Productos de Software-----------------------------------------------------------------------11 3. Marco Teórico----------------------------------------------------------------------------------------------------------14 3.1 Sistemas Avanzados de Conducción-------------------------------------------------------------------14 3.1.1 Sistemas ADAS---------------------------------------------------------------------------------14 3.1.1.1 Otros Sistemas ADAS------------------------------------------------------------14 3.2 Sistemas de Posicionamiento Global (GPS) ----------------------------------------------------------15 3.2.1 Características Técnicas---------------------------------------------------------------------15 3.2.1.1 Segmento Espacial---------------------------------------------------------------15 3.2.1.2 Segmento de Control------------------------------------------------------------16

3.2.1.2 Segmento de Usuario-----------------------------------------------------------17 3.3 Unidad Inercial de Medida (IMU) ----------------------------------------------------------------------17 3.4 Servicios RestFul--------------------------------------------------------------------------------------------17 3.5 Metodología de Desarrollo en Cascada---------------------------------------------------------------18 3.5.1 Descripción de Etapas------------------------------------------------------------------------18 3.5.1.1 Etapa de Análisis------------------------------------------------------------------18 3.5.1.2 Etapa de Diseño-------------------------------------------------------------------19 3.5.1.3 Codificación-----------------------------------------------------------------------19 3.5.1.4 Pruebas-----------------------------------------------------------------------------19 3.5.1.4 Mantenimiento-------------------------------------------------------------------19 4. Proceso de Ingeniería de Software--------------------------------------------------------------------------------21 4.1 Modelo de Proceso de Desarrollo----------------------------------------------------------------------21 4.1.1 Descripción de Interacciones Realizadas------------------------------------------------21 4.2 Educción de Requisitos-----------------------------------------------------------------------------------24 4.2.1 Técnica Utilizada------------------------------------------------------------------------------24 4.2.1.1 Entrevista--------------------------------------------------------------------------24 4.2.1.2 Lectura Basada en Perspectivas-----------------------------------------------24 4.2.2 Requisitos Funcionales Documentados--------------------------------------------------24 4.3 Análisis y Diseño--------------------------------------------------------------------------------------------26 4.3.1 Objetivos de Arquitectura y Limitaciones------------------------------------------------26 4.3.1.1 Atributos de Calidad-------------------------------------------------------------26 4.3.1.1.1 Extensibilidad--------------------------------------------------------26 4.3.1.1.2 Interoperabilidad---------------------------------------------------26 4.3.1.1.3 Rendimiento----------------------------------------------------------26 4.3.1.1.4 Matenibilidad--------------------------------------------------------26 4.3.1.1.5 Usabilidad-------------------------------------------------------------26 4.3.2 Requisitos no Funcionales ------------------------------------------------------------------26 4.4 Diseño de la Arquitectura--------------------------------------------------------------------------------27 4.4.1 Vista de Alto Nivel-----------------------------------------------------------------------------27


4.4.2 Vista de Procesos------------------------------------------------------------------------------30 4.4.3 Vista Lógica-------------------------------------------------------------------------------------31 4.4.4 Vista de Desarrollo----------------------------------------------------------------------------32 4.5 Patrones de Diseño Utilizados---------------------------------------------------------------------------33 4.5.1 Modelo Vista Control (MVC) ---------------------------------------------------------------33 4.5.2 Singleton----------------------------------------------------------------------------------------34 4.6 Justificación de Diseño------------------------------------------------------------------------------------34 4.7 Desarrollo ---------------------------------------------------------------------------------------------------34 4.7.1 Tecnologías Utilizadas------------------------------------------------------------------------34 4.7.2 Tecnología Utilizada y su Relación con los Atributos de Calidad-------------------35 4.8 Prototipo del software------------------------------------------------------------------------------------36 4.8.1 Card sorting-------------------------------------------------------------------------------------36 4.8.2 Desarrollo de Prototipos---------------------------------------------------------------------38 4.8.2.1 Elementos de Interfaz Involucrados en Plataforma web----------------39 4.8.2.2 Elementos Secundarios de Interfaz------------------------------------------41 4.9 Pruebas y Evaluación de Software----------------------------------------------------------------------42 4.9.1 Prueba Sobre el Sistema de Posicionamiento Global (GPS) ------------------------43 4.9.1.1 Desviación Media Absoluta----------------------------------------------------43 4.9.2 Prueba de Comparabilidad de Velocidad: Velocímetro vs Sistema----------------46 4.9.3 Prueba de Comparabilidad App Odómetro GPS vs Sistema-------------------------50 4.9.4 Prueba de Caja Negra-------------------------------------------------------------------------53 4.10 Acceso a la Aplicación-----------------------------------------------------------------------------------54 5 Análisis de Resultados-------------------------------------------------------------------------------------------------56 5.1 Análisis de Impactos---------------------------------------------------------------------------------------56 5.2 Utilización de Herramientas-----------------------------------------------------------------------------56 5.3 Cumplimiento de Objetivos------------------------------------------------------------------------------57 5.4 Experiencia de Diseño en Ingeniería de Software--------------------------------------------------58 5.5 Trabajos Futuros--------------------------------------------------------------------------------------------59 6 Referencias---------------------------------------------------------------------------------------------------------------60 7 Anexos---------------------------------------------------------------------------------------------------------------------62


ÍNDICE DE FIGURAS Figura 3.1 Constelación Satelital -----------------------------------------------------------------------------------------16

Figura 3.2 Mapa de las Infraestructuras--------------------------------------------------------------------------------16

Figura 3.3 Comportamiento consumo de servicios REST-------------------------------------------------------------18

Figura 3.4 Metodología de desarrollo en cascada --------------------------------------------------------------------18

Figura 4.1 Diagrama de arquitectura de alto nivel--------------------------------------------------------------------28

Figura 4.2 Diagrama de actividades de todo el sistema--------------------------------------------------------------30

Figura 4.3 Modelo entidad relación--------------------------------------------------------------------------------------31

Figura 4.4 Firebase data base----------------------------------------------------------------------------------------------31

Figura 4.5 Diagrama de componentes del ecosistema---------------------------------------------------------------32

Figura 4.6 Listado de elementos para card sorting--------------------------------------------------------------------37

Figura 4.7 Diseño final velocímetro--------------------------------------------------------------------------------------39

Figura 4.8 Diseño final modelo tridimensional-------------------------------------------------------------------------40

Figura 4.9 Diseño final ubicación en el mapa---------------------------------------------------------------------------40

Figura 4.10 Ejes de rotación-----------------------------------------------------------------------------------------------41

Figura 4.11 Latitud y longitud---------------------------------------------------------------------------------------------41

Figura 4.12 Dirección de la ubicación------------------------------------------------------------------------------------41

Figura 4.13 Mapa del recorrido de la prueba---------------------------------------------------------------------------44

Figura 4.14 Donde demo 1971--------------------------------------------------------------------------------------------47

Figura 4.15 Diagrama de torta de error del sistema------------------------------------------------------------------50

Figura 4.16 Odómetro GPS-------------------------------------------------------------------------------------------------52

Figura 4.17 Aplicación móvil del sistema--------------------------------------------------------------------------------52

Figura 4.18 Mapa Odómetro GPS-----------------------------------------------------------------------------------------52

Figura 4.19 Mapa aplicación móvil del sistema-------------------------------------------------------------------------52


ÍNDICE DE TABLAS Tabla 4.1 tabla descriptiva etapa No 1: Análisis--------------------------------------------------------------------21 Tabla 4.2 tabla descriptiva etapa No 2: diseño---------------------------------------------------------------------22 Tabla 4.3 tabla descriptiva etapa No 3: codificación--------------------------------------------------------------23 Tabla 4.4 tabla descriptiva etapa No 4: pruebas--------------------------------------------------------------------23 Tabla 4.5 especificación y priorización de requisitos funcionales----------------------------------------------25 Tabla 4.6 matriz de especificación y clasificación de requisitos no funcionales ---------------------------26 Tabla 4.7 resumen tecnologías utilizadas ---------------------------------------------------------------------------35 Tabla 4.8 resultado car sorting -----------------------------------------------------------------------------------------37 Tabla 4.9 prototipo final de plataforma web------------------------------------------------------------------------38 Tabla 4.10 prototipo final aplicación móvil--------------------------------------------------------------------------42 Tabla 4.11 resultado prueba--------------------------------------------------------------------------------------------44 Tabla 4.12 resultado desviación media absoluta-------------------------------------------------------------------46 Tabla 4.13 resultados prueba de comparabilidad de velocidad------------------------------------------------47 Tabla 4.14 tabla de distribución de frecuencias prueba velocidad---------------------------------------------49 Tabla 4.15 resultado de la prueba de comparabilidad GPS------------------------------------------------------51 Tabla 4.16 distribución de frecuencia prueba comparativa GPS-----------------------------------------------51 Tabla 4.17 resultado de la prueba de caja negra-------------------------------------------------------------------54


1. RESUMEN

Estimación de movimiento propio en vehículos enmarcado en el proyecto COMVIDAS, es una fase del proyecto la cual es la base para la sustentación de los diversos módulos que lo conforman, el objetivo primordial de este módulo es la recopilación de la información, la cual es suministrada por el hardware, y comunicársela a las capas superiores en un formato comprensible para ella. El protocolo seleccionado para la transmisión de los datos son los servicios REST, por medio de los métodos HTTP se comunica la información y se hacen las solicitudes de las mismas, retornando los datos en formato JSON. Los datos son obtenidos por medio de un sensor inercial de medida que da el vector posición para la rotación del modelo 3D por medio de puerto serial y consumiendo servicios REST sube la información obtenida a una base de datos relacional, y una aplicación móvil Android que suministra la ubicación por medio de GPS consumiendo el servicio de Firebase de Google para almacenar la información para luego ser obtenida por la plataforma web. Palabras clave: ADAS, Servicios, REST, App, Android, GPS Movimiento.

ABSTRACT

Estimate of self movement in vehicles framed in the COMVIDAS project, is a module of the project which is the basis for the support of the various modules that make it up, the primary objective of this module is the collection of information, which is provided by the hardware, and communicating it to the upper layers in a format understandable to it. The selected protocol for the transmission of the data are the REST services, by means of the HTTP methods the information is communicated and the requests of the same are made, returning the data in JSON format. The data is obtained by means of an inertial measurement sensor that gives the vector position for the rotation of the 3D model by means of a serial port and consuming services. REST uploads the information obtained to a relational database, and an Android mobile application that supplies the location by means of GPS, consuming the Google Firebase service to store the information and then be obtained by the web platform. Keywords: ADAS, Services, REST, App, Android, GPS, Movment


2. INTRODUCCIÓN

2.1 Contexto 2.2 Planteamiento del problema 2.3 Justificación del Problema 2.4 Objetivo General 2.5 Objetivos Específicos 2.6 Descripción de la solución 2.6.1 Descripción Proceso de Ingeniería 2.6.2 Productos de Software

2.6.2.1.1.1.1.1.1 2.6.2.1.1.1.1.1.2 o


2. INTRODUCCIÓN

2.1. Contexto

La falta de atención continua a la vía por parte de los conductores de vehículos ocurre debido a distracciones voluntarias e involuntarias, al cansancio, y a la somnolencia solo por enumerar algunos factores. Esta falta de atención es una de las principales causas de accidentes de tránsito, que generan no solo en nuestro entorno sino a nivel global, cuantiosos daños materiales, traumatismos en el flujo vehicular, lesiones permanentes y pérdidas de vidas humanas. Este proyecto busca contribuir a la disminución de accidentes de tránsito asociados a una distracción por parte del conductor, mediante el diseño y desarrollo de un sistema de asistencia al conductor para que le facilite esta tarea al usuario. Los sistemas de asistencia al conductor se apoyan en una fusión de sensores como radares, láseres, cámaras, y sistemas inerciales, para interpretar el entorno del vehículo y estimar la intención del conductor. Algunos de estos sensores ofrecen altas prestaciones, pero requieren una alta inversión económica. En este proyecto se apunta al desarrollo de un sistema de asistencia al conductor usando principalmente la combinación de sensores inerciales de medida y sensor GPS.[1] En este sistema se conciben dos capas generales. La primera capa es física o de hardware y corresponde a una combinación de sensores inerciales de medida, sensores GPS y equipos de cómputo de apoyo con su respectiva interfaz. Finalmente, la segunda capa corresponde al módulo de realimentación multimedia que se encarga de tomar aquellas salidas de la primera capa que requieren atención del conductor y de comunicárselas de forma oportuna y efectiva. Desde el punto de vista de investigación, el interés de este proyecto está en el diseño, desarrollo y evaluación de los algoritmos en la integración he interpretación de los datos obtenidos de los sensores, y desempeño de la capa de realimentación multimedia. Si bien existen empresas que ofrecen módulos de asistencia a la conducción, estos han sido adaptados a países con una infra estructura vial óptima y con una cultura vehicular mejor desarrollada que la que se tiene disponible en el contexto colombiano. Por esta razón, este proyecto representa una oportunidad significativa para realizar procesos de innovación con impacto en la seguridad vial, y para generar productos tecnológicos de vanguardia.


2.2. Planteamiento del Problema

Debido a las distracciones que ocurren a la hora de conducir un vehículo, el exceso de confianza e incluso la imprudencia de algunos conductores, se producen accidentes de tránsito en las vías ocasionando daños materiales, lesiones personales e inclusive la muerte tanto como al conducto o terceros. En la actualidad se reconoce que uno de los problemas más graves y que requiere atención inmediata son los accidentes de tránsito, las estadísticas así lo manifiestan, “para el 2014, el Instituto de Medicina Legal reportó 6.402 muertes por accidentes de tránsito, cifra que señala un incremento de 2,94% frente al número de casos registrados para el 2013, y se presentaron 44.172 víctimas de lesiones no fatales para un aumento de 35,61%”. A pesar de las medidas implementadas por las industrias automotrices, como la incorporación de cinturones de seguridad, air bags, entra otras medidas para preservar la vida de los ocupantes de los automóviles no siempre logran su cometido por lo cual se están investigando asistentes de conducción para carros de alta gama aportando alertas al conductor para una mejor reacción ante una situación de riesgo y así lograr una reducción de accidentes de tránsito. [2] Pero dichas soluciones también se pueden ver interpretadas como un posible problema, debido a que estos sistemas vienen de fábrica solamente en automóviles de alta gama y la posibilidad de acceder a ellos es limitada, debido a los altos precios de estos vehículos el conductor promedio no tiene la capacidad adquisitiva para cambiar su actual vehículo por uno último modelo, y en esto también entra en consideración que muchos conductores no desean cambiar su vehículo, así este sea antiguo y tenga en dinero para hacerlo. Debido a este el presente proyecto propone un sistema de asistencia a la conducción accesible e instalable en cualquier vehículo sin necesidad de cambiar el automóvil actual del propietario. [3]

2.3. Justificación del Problema

Los sistemas de asistencia para los conductores es un tema innovador y actual en el mundo automotriz, empresas multinacionales de gran renombre como: BMW, Audi, Toyota, Tesla Motors, etc. han apostado a estos sistemas de asistencia de alta gama en los últimos años como una forma de brindarle un mejor servicio a sus consumidores y facilitándoles la conducción. Debido a que la conjunción de estas tecnologías son nuevas, es decir que si se quiere acceder a un sistema como este se debe adquirir un nuevo vehículo de cualquiera de esos fabricantes, lo cual no es nada accesible para el consumidor común, por ello desarrollar un sistema de asistencia que pueda ser instalable y en cualquier vehículo permitiría la facilidad de acceder a estos servicios sin la necesidad de comprar un vehículo de alta gama. Sistemas de asistencia que le permitan al usuario conoce su posición global, en qué dirección se encuentra, indicarle a su vez a qué velocidad está viajando y se le muestre información de su vehículo, como por ejemplo la inclinación y todo esto de manera gráfica y amena, pero no de forma invasiva para no desconcentrar al conductor, da una facilidad al usuario al momento de conducir y mejorando de manera representativa la experiencia de manejo.


2.4. Objetivo General

Estimación de movimiento propio en vehículos para sistemas de asistencia a la conducción en el marco con el proyecto Comvidas, empleando unidades inerciales de medida y GPS.

2.5 Objetivos Específicos

Seleccionar las variables y diseñar un modelo de representación de variables empleadas en la estimación de movimiento propio de sistemas de asistencia a la conducción.

Seleccionar e implementar un protocolo de comunicación que permita la comunicación de los datos obtenidos del hardware a la parte del software encargada de procesarlos y representarlos de forma visual en la interfaz.

Desarrollar una interfaz de navegación de usuario para sistemas avanzados a la conducción.

Realizar pruebas sobre los módulos de estimación de movimiento propio tanto en la veracidad de los datos entregados por el hardware como en la usabilidad de la interfaz de usuario.

2.6 Descripción de la Solución

2.6.1 Proceso de Ingeniería

Se decidió utilizar la metodología de desarrollo en cascada [4] (ver 3.1.1), debido a que se tenía claro cuáles eran los módulos y funcionalidades se iban a desarrollar, y esta metodología se ajustaba de manera adecuada a las necesidades requeridas por el proyecto, ya que cada etapa a realizarse iba a ser de manera lineal o secuencial, cada está desarrollada es detallada en la sección (3.1.1).

2.6.2 Productos de Software

• Entregables de proceso de software: o Aplicativo móvil para la captura y envió de la geolocalización. o Plataforma web, en el cual se manipula la información suministrada

por el hardware y donde es representada de manera adecuada para que el conductor pueda visualizarla.

o Lector Serial, programa ejecutable (.exe), es el encargado de verificar los puertos del computador para saber si el hardware del sensor inercial de medida está conectado para proceder a la obtención de los datos y su posterior envió de la información.

• Datos:


o Se entrega adicionalmente el archivo .sql para la creación de la base de

datos con sus respectivas tablas y registros necesarios para el funcionamiento del sistemas.

o Definición de la base de datos alojada en Firebase para el almacenamiento de datos proporcionado por la aplicación móvil.

• Documentación: o El código fuente y el comportamiento del sistema está documentado

por los diagramas contenidos en este documento. o Adicionalmente el código fuente del sistema se encuentra

documentado mediante comentarios dentro del mismo código. • Código Fuente:

o Código fuente de la plataforma web. o Código fuente de la aplicación móvil. o Código fuente del programa ejecutable, el cual se comunica con el

hardware (Sensor inercial de medida).


3. MARCO TEÓRICO

3.1 Sistemas avanzados de Conducción. 3.2 Sistemas de Posicionamiento Global (GPS). 3.3 Unidad Inercial de Medida. 3.4 Servicios RestFul. 3.5 Metodología de Desarrollo en Cascada.


3. MARCO TEÓRICO

3.1 Sistemas avanzados de Conducción

Hace algunas décadas la seguridad del automóvil siempre se ha enfocado en suavizar las lecciones ocasionadas por los accidentes de tránsito, pero a medida de que la industria automotriz progresa también avanza la tecnología. En la actualidad han surgido numerosos sistemas de control y de información que ayudan al conductor en las tareas de conducción, las tecnologías más usadas son ADAS (Advanced Drives Assistance Systems) y IVIS (In-Vehicle Information Systems). [5]

3.1.1 Sistemas ADAS Sistemas avanzados de ayuda al conductor (ADAS) son tecnologías que proporcionan al conductor información esencial, automatiza tareas difíciles o repetitivas, y da lugar a un aumento de la seguridad del vehículo. Algunas de estas tecnologías han existido desde hace mucho tiempo, y que ya han demostrado que dan como resultado una experiencia de conducción mejorada y una mejor seguridad vial para el vehículo y los que lo rodean. La navegación GPS, por ejemplo, se ha vuelto colosalmente común en la fabricación de sistemas originales, OEM, desde su primera aparición en la década de 90’s. [6] Los sistemas ADAS adicionan nuevas tecnologías en el vehículo para implementar funciones avanzadas de asistencia al conductor, con el fin de hacer la actividad de la conducción más segura, fácil y agradable. [7] Los 3 principales objetivos de los sistemas ADAS son: • Reducir el peligro de tener un accidente. • En caso de que se produzca, reducir sus consecuencias. • Incrementar el confort de conducción.

3.1.1.1 Otros sistemas ADAS relevantes.

Control de la Iluminación Adaptativa: Diseñados para ayudar a los conductores a ver mejor y más lejos en la oscuridad. Esta tecnología de conducción avanzada permite a los faros girar y rotar para iluminar mejor y de manera inteligente la calzada al momento de curvas u otras situaciones. [8]

Estacionamiento Automático: Diseñados para ayudar a facilitar parte del trabajo de parqueo o en algunos sistemas ADAS realizar el trabajo total de esta actividad. Las asistencias en estaría varía desde sensores de proximidad hasta control total del timón y funciones motoras para un parqueo automático. [9]

Detección del Punto Ciego: Utilizan una variedad de sensores para proporcionarle al conductor información vital que sería difícil o imposible de conseguir a través de cualquier otro medio. Algunos de estos sistemas harán sonar una alarma si detectan la presencia de un objeto en un punto ciego, y otros incluyen cámaras que pueden transmitir una imagen a la unidad principal o en otro monitor. [10]

Sistemas de Prevención de Colisiones: utilizan una variedad de sensores para determinar si un vehículo está en peligro de chocar con otro objeto. Estos sistemas normalmente pueden detectar la proximidad de otros vehículos, peatones, animales y diversos obstáculos viales. Cuando el vehículo está en peligro de chocar


con otro objeto, el sistema de prevención de colisiones le advertirá al conductor. [11]

Control de Crucero Adaptativo: Esta tecnología avanzada de conducción es de mucha ayuda y es especialmente útil en la carretera, donde los conductores tienen que vigilar constantemente sus sistemas de control de crucero por razones de seguridad. Con control de crucero avanzado, un vehículo se reducirá de forma automática o acelerar en respuesta a las acciones del automóvil o camión en frente de él. La mayoría de estos sistemas se apagan automáticamente debajo de un determinado umbral de velocidad, pero otros incluso se pueden utilizar en stop and go de tráfico. [12]

Frenado Automatico: El frenado automático es una tecnología pre choque que está diseñada para reducir la gravedad de las colisiones de alta velocidad en el caso de un lapso de atención del conductor. [13]

3.2 Sistemas de Posicionamiento Global (GPS) 3.2.1 Características Técnicas. 3.2.1.1 Segmento Espacial. El segmento espacial GPS está constituido por una constelación de 24 satélites con trayectorias sincronizadas que orbitan por el globo terráqueo a una altitud aproximadamente a los 20.200 kilómetros, repartidos en 6 planos orbitales de 4 satélites cada uno, orbitando a la tierra dos veces al día. [14] Los satélites envían señales a la región del espectro electromagnético, transmitiendo dos señales denominadas L1 y L2, el empleo de dos señales distinta se produce a que la atmosfera ocasiona un retardo en la propagación de las ondas, siendo este un desafío para función de la frecuencia, usando estas dos frecuencias se puede conocer este retardo y compensarlo en la frecuencia, [15] las señales GPS contienen a su vez códigos cifrados insertados por modulación, transportando por medio de estos códigos en binario la información para el cálculo en la posiciones, uno de estos códigos y el más básico es el código C/A el cual va insertado en la señal L1, modulando la señal con un patrón único propio en cada satélite (código pseudoaleatorio), tratándose de una secuencia de 1023 bits generados con una frecuencia de 1.023 MHz, permitiendo determinar el tiempo invertido de la señal en que tarda en recorrer la distancia entre el satélite y el receptor, otro código modulado sobre la señal L1 y L2 es llamado código P, logrando un incremento notable en la precisión del sistema y en la velocidad de medición en el sistema, usado normalmente por receptores militares. Cada señal GPS contiene tres componentes el código pseudoaleatorio que identifica al satélite que transmitió la señal, los datos efemérides del satélite que otorgan información sobre la ubicación del satélite, y el almanaque que otorga información sobre la fecha, hora y el estado del satélite. [16]


Figura 3.1 Constelación satelital GPS. [En línea]. Disponible:

http://kobi.nat.uni-magdeburg.de/patrick/uploads/BEng/gps_constellation.png

3.2.1.2 Segmento de Control.

El segmento de control es una serie de infraestructuras en tierra necesarias para el control de los satélites en órbita. Estas instalaciones hacen seguimiento continuo a cada satélite que pasa por su región, monitoreando las orbitas de los satélites y acumulando datos para el cálculo preciso de la órbita de cada satélite, [17] ya que las orbitas también tienen una degradación causada por ciertos factores por esta razón las infraestructuras de control envían información de control a los satélites para controlar las orbitas y realizar el mantenimiento de toda la constelación estas correcciones son transmitidas en la banda S, una vez el satélite reciba la corrección la incorpora en los mensajes de navegación que el satélite emite para ser captado por el receptor. Estas orbitas recalculadas que contienen los datos de corrección se conocen con el nombre de efemérides.


Figura 3.2 Mapa de las infraestructuras. [En línea]. Disponible:

http://www.jmediciones.com/RINCON/ACTUALIZACIONES/mapaactgeo.jpg

3.2.1.3 Segmento de Usuario

Segmento de usuario consta de dos bloques el hardware siendo los elementos de recepción y el software el encargado de procesar las señales emitidas por los satélites, permitiendo el cálculo de su posición tomando como base la velocidad de la luz y el tiempo que tarda la señal en viajar, entre cada satélite y el receptor en un tiempo determinado. [18]

3.3 Unidad Inercial de Medida (IMU) Una unidad inercial de medida es un dispositivo electrónico que incorpora por lo menos un

acelerómetro y un giroscopio de esta forma puede brindarnos una serie de datos.

Las unidades de medidas inerciales actuales dependen de diferentes sensores como acelerómetros, giroscopios y magnetómetros para hacer estimaciones de posición, orientación, velocidad lineal y angular, instintivamente entre más sensores se disponen más precisas podrán ser las estimaciones, habitualmente este dispositivo electrónico cuenta con un microcontrolador, encargado de recoger, convertir y transmitir los datos entregados por los sensores. Aunque en el día de hoy las IMUS tengan varios usos. [19] 3.4 Servicios RestFul

Servicios basados en el protocolo HTTP, en la que los servicios se identifican por un único identificador de recursos uniforme. Los servicios RestFul tienen mucha similitud con los servicios web tradicionales, pero los servicios web tradicionales a diferencia de los ResFul usan una capa adicional del modelo OSI, capa SOAP, la cual utiliza la lectura de ficheros XML lo que la hace mas lenta que los servicios RestFul debido a que estos solo trabajan bajo el protocolo HTTP. [20]


Directrices:

Interfaz uniforme: Usar las características del protocolo HTTP para mejorar la semántica.

Peticiones sin estado: Cada transacción de debe tratar de manera independiente y no debe relacionarse con ninguna otra petición.

Cacheable: los clientes pueden cachear las respuestas del servidor.

Separación de cliente y servidor: El cliente y el servidor están separados y se unen mediante interfaces.

Sistema de Capas: El cliente puede estar conectado mediante la interfaz al servidor o a un intermediario, el cual para él es irrelevante de quien sea.

Mediante estos servicios se abre la posibilidad a la comunicación entre sistemas sin importar como están construidos cada una de ellos, se requiere solamente que realice la petición de manera correcta y se responderá adecuadamente. Básicamente esta arquitectura permite a cualquier aplicación acceder por medio de una interfaz uniforme a las funcionalidades de otra aplicación que las contenga, pues solo se requiere enviar una petición a un servicio publicado por esta para que se obtenga la información o la transacción esperada para esta petición. A continuación, en la Figura 2.1 se ilustra cómo diferentes aplicaciones interactúan con los servicios expuestos en un servidor. [21]

Figura 3.3 Conportamiento Consumo servicios REST

http://www.arquitecturajava.com/wp-content/uploads/00228.png

3.5 Metodología de Desarrollo en Cascada

Metodología de desarrollo de software, la cual tiene como base primaria que es de manera lineal y secuencial, la cual está dividida en 5 etapas definidas rigurosamente para las cuales se tiene como regla que para dar inicio a la siguiente se debe dar por finalizada de manera completa la etapa previa. [22]


Figura 3.4 Metodología de Desarrollo en Cascada

https://ingenieriadesoftwareutmachala.files.wordpress.com/2017/01/cascada.jpg?w=616

3.5.1 Descripción de Etapas:

3.5.1.1 Etapa de Análisis:

Etapa en la que se analizan las necesidades requeridas por los usuarios finales del software para así mismo definir los objetivos que se deben cumplir y descripción detallada de lo que debe de hace el sistema. [23]

3.5.1.2 Etapa de Diseño del sistema: Etapa en la que se estructura el proceso de definición de la arquitectura, componentes, interfaces y otras características de un sistema o componente que resulta de este proceso. [24] 3.5.1.3 Codificación. Etapa en la que se desarrolla la implementación del software, para el que se toma como base el diseño generado como salida ende la etapa anterior.

3.5.1.4 Pruebas:

Etapa en la que ya con el desarrollo terminado con un producto final, salida de la etapa previa, se inicia la etapa de pruebas en la cual se revisa que el software cumpla con todos requerimientos definidos previamente.

3.5.1.4 Mantenimiento:

Etapa en la que se toma como salida los reportes generados por las pruebas realizadas anteriormente y se procede a hacer corrección de dichos problemas encontrados.


4. PROCESO DE INGENIERÍA DE SOFTWARE

4.1 Modelo de proceso de desarrollo de software 4.2 Educción de requisitos 4.3 Análisis y diseño 4.4 Diseño de la arquitectura. 4.5 Patrones de diseño utilizados 4.6 Justificación de diseño 4.7 Desarrollo 4.8 Prototipos del software 4.9 Pruebas y evaluación de software 4.10 Acceso a la aplicación 4.11 Estándares de ingeniería empleados durante el proyecto


4. PROCESO DE INGENIERÍA DE SOFTWARE

En este capítulo se presentan los procesos específicos de ingeniería aplicados para el desarrollo de este proyecto. Los proceso son: elección de un modelo de proceso, la educción de requisitos funcionales y no funcionales, definición de artefactos necesarios para el análisis y diseño, la elección de las herramientas, patrones y tecnologías que fueron usadas durante el proceso de desarrollo del software, culminando con las respectivas pruebas que validarán el cumplimiento de los objetivos propuestos. La presentación de dichos procesos tiene como objetivo evidenciar el desarrollo de competencias en términos de desarrollo de software, por parte de los autores del documento.

4.1 Modelo de proceso de desarrollo de software.

Se decidió optar por la metodología de desarrollo en cascada debido a que se quería seguir una línea secuencial al momento de elaborar el proyecto, y esto se adecuaba de manera correcta con el modelo de desarrollo en casada. Adicionalmente a eso se recomienda usar esta metodología para los proyecto en los cuales se tiene claro cuáles son los procesos y funciones a realizar, debido a que previamente ya se había realizado un anteproyecto de grado y como se informó previamente este proyecto está enmarcado en un macroproyecto, Proyecto COMVIDAS, ya tenía una base clara por la cual seguir una senda definida, debido a estas razones se optó por la metodología de desarrollo en espiral.

4.1.1 Descripción de Iteraciones realizadas

A continuación se describe el proceso realizado en las iteraciones definidas:

Etapa No.1 Análisis

Artefactos de Entrada: Documento Proyecto COMVIDAS

Descripción:

En etapa con base en el proyecto plantea “COMVIDAS” analizando nuestro proyecto y el rol que íbamos a tener, se realizaron entrevista para conocer el pensamiento de los posibles futuros usuarios respecto a lo que ellos esperaban por parte de un sistema de asistencia a la conducción (teniendo como base nuestro enfoque de estimación de movimiento propio), se realizó un análisis y levantamiento de los requisitos que iba a tener sistema. Se identificaron todos los sistemas, softwares y hardwares, que estaban involucrados para desarrollar la solución.

Artefactos de Salida:

Listado de requerimientos funcionales a los cuales el software se iba a enfocar.

Listados de sistemas involucrados en la solución.

Listado de hardware involucrado en la solución.

Tabla 4.1 Tabla descriptiva Etapa No 1: Análisis.


Etapa No.2 Diseño

Artefactos de Entrada: Listado de Requerimientos Funcionales

Descripción:

Se diseña el sistema, el cual contara con un ecosistema de sistemas, los cuales son:

•la plataforma web, diseñada con el patrón de diseño MVC, donde el usuario tendrá una interfaz en la cual podrá ver la información suministrada por los demás sistemas, como posición geográfica por medio del API de Google Maps, velocidad actual y orientación y comportamiento del vehículo, por medio de un modelo tridimensional graficado con WebGL, adicional a eso cuenta con una base de datos MySql local donde se aloja la información actual de la información suministrada por el sensor inercial de medida y expone un servicio RestFul consumido por el lector serial, consulta una base de datos alojada por Firebase con los datos de la ubicación GPS y la velocidad, depositados ahí por la aplicación móvil.

• Lector Serial, programa ejecutable que obtiene la información del sensor inercial de medida, el cual se encarga de leer los puertos seriales del computador para obtener la información suministrada por el sensor inercial de medida, el cual se le asignara a un objeto construido como singleton, y consumiendo el servicio expuesto por la plataforma web enviara esos datos por ese medio.

Aplicativo móvil, es la aplicación nativa construida en Android nativo, con la cual se obtiene la posición global del dispositivo el cual se toma como referencia como ubicación del vehículo

Se realizaron pruebas de card Sorting por el medio de cuales se mostraban posibles diseños finales que tendría la aplicación del vehículo y los entrevistados, elegirían el elemento que pudieran relacionar más al elemento en cuestión, para así seleccionar como sería el diseño de elementos pertenecientes a la interfaz.


Diagrama de componentes del sistema.

Resultados Pruebas de card sorting

Diagramas de Secuencia.

Diagramas de Actividades

Modelo de Bases de Datos

Tabla 4.2 Tabla descriptiva Etapa No 2: Diseño.

Etapa No.3 Codificación

Artefactos de Entrada: Artefactos Salida Etapa No 2

Descripción: Se desarrollan los prototipos de los tres sistemas que forman parte de todo el proyecto, los cuales se comunican de la forma indicada


en la parte de diseño y despliegan la información como se indicó previamente. Teniendo como base primaria la etapa anterior de diseño se desarrolló con tecnologías ahí seleccionadas y le eligieron las faltantes para poder cumplir a cabalidad las necesidad expuestas.


Plataforma web, desarrollada para la parte Backend con PHP, se utilizó para el lado del cliente WebGL para la graficación del modelo 3D que representa el vehículo, la API de Google Maps para mostrar en el mapa real la ubicación del vehículo, JavaScript, Firebase para leer la información de esa base de datos la cual es actualizada por medio de la aplicación móvil, HTML y CSS para la parte gráfica. Adicional a la creación de los servicios RestFul expuestos para ser consumidos por el Lector Serial.

Lector serial, se desarrolló con el lenguaje de programación C++, se hizo uso de la librería “yei_threespace_api.h”, librería suministrada por el fabricante del sensor inercial de medida. Se consumen los servicios RestFul expuestos por la plataforma web para la transmisión de los datos del sensor.

Aplicación Móvil, desarrollada en Android nativo, del cual se hace uso del GPS del vehículo y del método

Tabla 4.3 Tabla descriptiva Etapa No 3: Codificación.

Etapa No.4 Pruebas

Artefactos de Entrada: Artefactos Salida Etapa No 3

Descripción:

Con los artefactos obtenidos en la etapa anterior se emplean pruebas para examinar la veracidad de los datos arrojados por los sistemas.

Prueba de repetitividad.

Prueba de comparabilidad.

Prueba de Caja Negra.

Artefactos de Salida: Tablas de Resultados de pruebas.

Graficos representativos de los resultados.

Tabla 4.4 Tabla descriptiva Etapa No 4: Pruebas.


4.2 Educción de Requisitos

4.2.1 Técnica utilizada:

4.2.1.1 Entrevista. La entrevista es una técnica de requisitos ampliamente conocida y utilizada al momento

de querer comprender el dominio del problema, debido a que ayuda para poder obtener la perspectiva del usuario final, permitiendo a ambas partes poder plantear dudas y compartir conocimiento o putos de vista respecto al proyecto y ayuda a tomar decisiones útiles durante el mismo. En este caso no se estableció una estructura preestablecida de entrevista, pero si se tomar en cuenta unos tópicos de interés relevante, se realizó por medio de un dialogo con el integrante del proyecto COMVIDAS y director del trabajo de grado, Ingeniero Andrés Felipe Hurtado Banguero, el cual posee una experiencia amplia y considerable respecto al tema de sistemas de asistencia a la conducción, también se tuvieron múltiples entrevistas y diálogos con conductores nuevos y experimentados, para obtener sus opiniones y aportes de lo que ellos esperarían de un sistema de asistencia a la conducción.

4.2.1.2 Lectura Basada en Perspectivas. Se identificaron requisitos existentes por medio de la lectura de diferentes fuentes

relacionadas con los diferentes y diversos sistemas de la asistencia a la conducción, tanto que proveedores los ofrecían y que servicios ofrecían en sus sistemas, para así tener en cuenta que funcionalidades era una tendencia y tener en cuenta esta información al momento de definir los requisitos del sistema. Por este medio también al conocer las funcionalidades de los sistemas de asistencia a la conducción existentes se pudo validar requisitos previamente levantados que ya habían sido identificados.

4.2.2 Requisitos funcionales documentados

En la Tabla 3.1 se relaciona la respectiva especificación y priorización de requisitos funcionales y no funcionales que fueron educidos utilizando las técnicas anteriormente descritas.

Ref. Prioridad Descripción Requisito Fuente de Info.

RF-1 Alta El sistema debe de obtener la información suministrada por el sensor inercial de medida (Pitch, Yaw, Roll. Vertor

(x,y,z)) Entrevista

RF-2 Media El sistema lector serial debe enviar la informacion

suministrada por el sensor inercial de medida al servidor (Pitch, Yaw,Rol. Vextor (x,y,z))

Entrevista

RF-3 Alta El sistema debe obtener la ubicación GPS del usuario

(latitud y longitud). Entrevista


RF-4 Media El sistema debe enviar la información de la ubicación GPS

del usuario al servido (latitud y longitud) Entrevista

RF-5 Alta El sistema debe obtener la velocidad de desplazamiento

del usuario. (kilometro por hora) Entrevista

RF-6 Media El sistema debe de enviar la velocidad desplazamiento del

usuario al servidor (kilómetros por hora). Entrevista

RF-7 Alta El sistema de poder permitirle al usuario observar

ubicación actual en un mapa. Lectura basada en perspectiva

RF-8 Alta El sistema de permitirle al usuario observar su velocidad

de desplazamiento actual. Lectura basada en perspectiva

RF-9 Alta El sistema debe permitir al usuario observar un modelo

tridimensional de su vehículo Entrevista

RF-10 Alta El sistema debe actualizar la orientación del modelo

tridimensional del vehículo respecto a los cambión de orientación obtenidos del sensor inercial de medida.

Lectura basada en perspectiva

RF-11 Baja El sistema de permitirle al usuario observar en qué

dirección exacta respecto a su ubicación se encuentra. (ejemplo: Cra 83c #25-41)

Lectura basada en perspectiva

RF-12 Baja El sistema debe permitirle al usuario observar en que latitud y longitud exacta se encuentra respecto a su

ubicación exacta. Entrevista

RF-13 Baja El sistema debe permitirle al usuario observar el vector de

(X,Y,Z) que está afectando en ese momento el modelo tridimensional del vehículo.

Entrevista

Tabla 4.5 Especificación y priorización de requisitos funcionales


4.3 Análisis y Diseño

4.3.1 Objetivos de Arquitectura y Limitaciones. En esta sección se describen los requisitos de calidad del software que tienen un impacto significativo en el diseño de la arquitectura.

4.3.1.1 Atributo de calidad 4.3.1.1.1 Extensibilidad: El software debe estar en la capacidad de facilitar la adaptación de nuevos requisitos o cambios en la especificación. 4.3.1.1.1 Interoperabilidad: El software debe estar en la capacidad de comunicarse de manera correcta entre los componentes que forman parte del ecosistema. 4.3.1.1.1 Rendimiento: El software debe estar en la capacidad de leer y actualizar la información suministrada por el hardware y representarla en la interfaz de manera inmediata. 4.3.1.1.1 Matenibilidad: El software debe tener las propiedades que permitan mantener su funcionamiento normal, encontrar y corregir defectos, optimizar funcionalidades, alargar su ciclo de vida, minimizando el esfuerzo necesario para ello. 4.3.1.1.1 Usabilidad: El software debe contar con una interfaz sencilla entendible y poco llamativa para no distraer al conductor, adicionalmente debe mostrar de manera correcta y entendible los datos suministrados por el hardware.

4.3.2 Requisitos No Funcionales. La Tabla 3.2 presenta los requisitos no funcionales documentados.

Ref. Descripción Requisito Extensibili

dad Interopera

bilidad Rendimien

to Matenibi

lidad Usabilidad

RFN-1 El sistema debe mostrar mensajes de error que

sean informativos para el usuario.

X

RFN-2 El sistema debe tener una interfaz de usuario que

sea fácil de entender.

X

RFN-3 El sistema debe mostrar de manera clara la información suministrada por el hardware

X

RFN-4 El tiempo de carga de la plataforma web no debe

exceder los 5 segundos

X


RFN-5 La aplicación móvil debe optimizar el consumo de

datos

X

RFN-6 La Velocidad mostrada en la interfaz debe

actualizarse cada vez que haya un cambio en la misma

X

RFN-7 El modelo tridimensional del vehículo debe

actualizarse cada vez que haya un cambio en la orientación del sensor inercial de medida.

X

RFN-8 El sistema debe desarrollarse de manera que se

afecte lo menos posible al realizar un cambio

X

RFN-9 Los sistemas involucrados deben de poder

comunicarse correctamente entre ellos

X

RFN-10 El sistema debe desarrollarse de manera que se afecte lo menos posible al realizar un cambio.

X

RFN-11 El sistema debe permitir el desarrollo futuro de

nuevas funcionalidades

X

RFN-12 La plataforma web debe funcionar en navegadores

que soporten HTML5

X

RFN-13 Los servicios deben seguir los protocolos comunes de servicios RestFul que definen el uso correcto de

los métodos HTTP

X

RFN-14 El sistema debe estar documentado de forma

adecuada

X

Tabla 4.6 Matriz de especificación y clasificación de requisitos no funcionales.

4.4 Diseño de la Arquitectura.

Se utilizaron diversos estilos arquitectónicos en el software con el fin de cumplir con los requisitos funcionales y no funcionales del sistema, demanera general de pueden identificar 2, arquitectura basada en capas, cuyas capas y responsabilidades estarías distribuidas en plataforma web, la aplicación movil y el lector serial, la segunda seria el estilo arquitectónico RestFul, el cual permite la comunicación entre el lector serial y la plataforma web atra vez de servicios RestFul.


4.4.1 Vista de Alto Nivel.

Nombre Diagrama: La siguiente vista, Figura 3.1, representa la interacción a un alto nivel entre las diferentes aplicaciones que componen el sistema y los servicios que utilizan.

Figura 4.1 Diagrama de arquitectura de alto nivel.


En el diagrama de arquitectura de alto nivel representado en la figura 3.1, se muestran los diferentes componentes que interactúan y se comunican en el ecosistemas, tanto propios como externos, lo cual da la posibilidad de observas desde una perspectiva superior, las diferentes comunicaciones entre los componentes, la conexión entre ellos y que protocolo de comunicación usan. Los paquetes están haciendo referencia a las aplicaciones y servicios en la nube que componen el ecosistema de la aplicación. Todas las aplicaciones acceden a los servicios REST que los otros componentes exponen. El lector serial lee por puerto serial la información que transmite el sensor inercial de medida mediante una conexión USB, después de obtener esta información consume un servicio RestFul expuesto por la plataforma web para enviar la data obtenida y salvar esos datos en la base de datos MySQL vía protocolo ODBC, la aplicación móvil obtiene la ubicación GPS y velocidad del dispositivo y la salva en una base de datos que se encuentra en Firebase por medio de servicios expuestos por el mismo Firebase vía HTTP, esta información es consultada también vía servicios por los métodos HTTP por la plataforma web, ya cuando la plataforma web tiene toda esta información, posición GPS, velocidad y datos de orientación por parte del sensor, la utiliza para representarla de manera adecuada en la interfaz de usuario, utiliza la API de Google Maps para mostrar el mapa con la ubicación y las librerías de WebGL para mostrar el modelo tridimensional del vehículo.


4.4.2 Vista de Procesos.

Figura 4.2 Diagrama de actividades de todo el sistema


En la figura 3.2 se observa el diagrama de actividades completo del ecosistema, se ve como los tres diferentes sistemas ejecutan sus actividades en paralelo, que proceso ejecutan y que tareas realizan para cumplir con sus propias obligaciones.

4.4.3 Vista Lógica.

Respecto a los modelos de datos de los sistemas, se intentó simplificar lo máximo posible, debido a que simplemente se debía de almacenar la información relevante entregada por los dispositivos y no se contempló gestión de usuarios, el resultado del modelo de datos fue bastante simple.

Figura 4.3 Modelo Entidad Relación

En la figura 3.3 podemos ver el modelo entidad relación en el cual esta únicamente la tabla orientación, esto es debido a que solamente queremos alojar los valores obtenidos de sensor inercial del medida, tenemos id que es la llave primaria y el identificador único de la tabla, pitch, yaw y roll, que es el vector (X,Y,Z), que hace referencia a la orientación del sensor inercial de medida y mediante dichos valores se actualiza el modelo tridimensional de la vista . Cabe resaltar que esta es una base de datos MySQL.

Figura 4.4 Firebase Data Base

En la figura 3.4 podemos ver nuestra base de datos de Firebase, a diferencia de la anterior esta es una base de datos NoSQL, por eso tiene una estructura JSON como vemos en la figura 3.4, en esta base de datos se aloja la información suministrada por la aplicación móvil que por medio de un servicio REST y los métodos HTTP modifica dicha información y es consultada en tiempo real por la plataforma web y también mediante servicios, ya la plataforma móvil con esa información procede a representarla en la interfaz.


La razón por la que se tienen estas bases de datos separadas es debido a que la plataforma web y el lector serial están corriendo de manera local y la aplicación móvil no podía acceder a dichos datos, por eso se decidió usar Firebase y que la plataforma web ya conectada a internet realizara las peticiones de esa información.

4.4.4 Vistas de Desarrollo.

Figura 4.5 Diagrama de Componentes del ecosistema.


Plataforma Web: Es la encargada de reunir la información de que suministran los dispositivos. La información de la velocidad y de la ubicación GPS, la obtiene consumiendo un servicio expuesto por Firebase y la información de la orientación (Pitch, Yaw y Roll) la obtiene consultando la base de datos.

ServiceRest: Servicios RestFul expuestos para el consumo de las otras aplicaciones, se relaciona con Model, porque con ese servicio es que se actualiza la base de datos (tarea encargada al modelo).

Model: Representación en los datos el cual se utiliza para realizar consultas, modificaciones, creación y eliminación de registros en la base de datos.

View: La vista de la plataforma web donde se muestran toda la información obtenida de los dispositivos hardware y se representa de manera adecuada en la pantalla.

Controller: Encargado de escuchar la interacción con el usuario y de indicar las directrices al modelo en caso de que sea necesario.

Service: Encargado de consumir los servicios expuestos por parte de Firebase, donde se aloja la información de la ubicación (latitud y longitud) y la velocidad.

Lector Serial: Sistema encargado de leer la información del sensor inercial de medida y divulgarla a la plataforma web por medio de consumir el servicio web expuesto por la plataforma web y actualizar esos datos en la base de datos.

Yei_trheespace: Librería suministrada por el proveedor del hardware del sensor inercial de medida para obtener la información del sensor y leer por puerto serial los datos que este brinda, para luego consumir un servicio web y enviar la data.

Service: Encargado de consumir el servicio web RestFul para por medio de método HTTP (PUT) actualizar los valores de la base de datos con los brindados en tiempo real por el sensor (Pitch, Yaw, Roll).

Aplicación Móvil: Aplicativo móvil Android, encargado de recopilar la información GPS y la velocidad y por medio de un servicio REST expuesto por Firebase actualizar los datos de la base de datos ubicada precisamente en Firebase.

View. Vista de la aplicación móvil, en la que se muestra de manera informativa, la latitud y longitud actual.

GPS: Plugin de Android por el cual se puede obtener información del GPS.

Controller: Encargada de comunicarse con el plugin del GPS informar a la vista que debe pintar esa información y por medio del servicio expuesto por Firebase actualizar la base de datos por la información actualizada de latitud, longitud y velocidad.

Service: Encargado de consumir los servicios expuesto por Firebase para actualizar la base de datos con los datos obtenidos en tiempo real del dispositivo.

4.5 Patrones de Diseño Utilizados

4.5.1 Modelo Vista Controlador (MVC). Este patrón de diseño consiste en la separación de los componentes en tres capas, las cuales

son:


Modelo: Son las entidades que representan los datos de la aplicación.

Vista: Son las pantallas o vistas que el usuario observa y por donde el mismo puedo interactuar con el sistema.

Controlador: Son los encargado de supervisar esas vistas y responder de manera adecuada a cualquier evento.

En el caso de este proyecto se usó este patrón de diseño en la plataforma web, donde se separaron dichas capas para lograr un bajo acoplamiento entre los componentes. 4.5.2 Singleton Este patrón de diseño que restringe la creación de instancias de una clase, en otras palabras, sólo permite instanciar un objeto de una clase con el fin de proveer un único punto de acceso global a la clase. Es utilizado en la implementación de otros patrones de diseño y en ocasiones se prefiere al uso de variables globales pues ofrece ventajas como la inicialización diferida.

4.6 Justificación de Diseño

En el caso del patrón de diseño modelo vista controlado (MVC), permite bajo acoplamiento entre los componentes y se tuvo en cuenta desde las concepciones iniciales del proyecto, ya que ayuda a cumplir requisitos de calidad que se platearon en la fase de análisis (ver tabla 3.5) En el caso de nuestro proyecto se decidió utilizar en la implementación del lector serial el patrón de diseño Singleton, debido a que hay un proceso en el que se le el puerto serial y se instancia un objeto hidratado con los datos brindados por el sensor, el problema que había era que se estaban creando múltiples instancias del mismo objeto todo el tiempo saturando la memoria y no permitiendo al sistema trabajar correctamente, por ello se tomó la decisión de hacer dicha clase singleton para que cada vez que se hiciera una instancia de clase, no se creara una nueva sino que se llamara a la misma instancia y simplemente se actualizara los datos sin necesidad de crear otros objetos. De este modo al aplicar este patrón de diseño se logo solucionar un problema que había urgido y optimizar el uso de memoria del sistema.

4.7 Desarrollo

4.7.1 Tecnologías utilizadas

XAMPP: XAMPP es una distribución de Apache completamente gratuita y fácil de instalar que contiene MariaDB, PHP y Perl. El paquete de instalación de XAMPP ha sido diseñado para ser increíblemente fácil de instalar y usar.

jQuery: JQuery es una biblioteca de JavaScript que nos simplifica la manera de interactuar con los documentos HTML, manipular el DOM, manejar eventos y el uso de AJAX.

Three.js: Three.js es una biblioteca de JavaScript que nos sirve para crear, animar objetos en 3D y generar escenas 3D con WebGL, Canvas(2D) y SVG, además de posibilitar la importación de archivos 3D generados por 3DMax, Blender o Maya y asignar el modelo a un objeto de nuestra escena.

MySQL: sistema de gestión de bases de datos objeto-relacional, gratuito y de código abierto, es muy potente al ofrecer una gran variedad de funcionalidades y estable.


Firebase: Firebase es un Backend como servicio, nos provee de una API para guardar y sincronizar datos en la nube en tiempo real, que nos provee funciones para traer los datos de la nube en tiempo real o ante cualquier evento que se produzca en nuestros datos.

Google Maps API: Google Maps API para navegadores Web es una biblioteca de JavaScript que nos permite mostrar un mapa en nuestra página.

QT-Creator: Qt Creator es un entorno de desarrollo integrado de plataforma cruzada (IDE) para crear aplicaciones C ++ y QML para múltiples plataformas de escritorio, incrustadas y móviles. Viene con un editor de código y está integrado con herramientas para diseñar, codificar, probar, implementar y mantener su software durante todo el ciclo de vida del producto.

4.7.2 Tecnologías utilizadas y su Relación con los Atributos de Calidad.

Escalabilidad: Debido a contener información en una base de datos NoSQL como Firebase no

permite tener una capacidad de escalabilidad ya que dado el caso en el que se desarrollen funciones adicionales Firebase no cambia y así lo hiciera las necesidades con respecto a ella son por medio de servicios, así que solo sería necesario el consumo de los mismos.

Rendimiento: Al usar una librería liviana y rápida en procesamiento como lo es Three.js para

la manipulación del modelo tridimensional no proporciona un rendimiento óptimo para las funciones que requerimos en el navegador. Adicional a XAMPP que funciona como un servidor local óptimo para el despliegue de la plataforma web.

Precisión: Al momento de estar tratando con posición GPS y más en el contexto de este

proyecto que es de un sistema de asistencia a la conducción la precisión y veracidad de la información representada en el mapa es muy importante, por eso contar con el API de Google Maps nos da esa precisión y tranquilidad de estar trabajando con material distribuido por una de las compañías más grandes del mundo.

Funcionalidad y Matenibilidad: Para el funcionamiento y creación el lector seria, que está

construido en C++, se eligió QT, debido a que es un IDE que nos brinda las funciones necesaria para el desarrollo de funcionalidades nuevas que puedan surgir a futuro y asi asegurar una matenibilidad del software, adicional a que cuenta con una gran comunidad, con la que se puede apoyar para la resolución de cualquier duda.

Usabilidad: Al tener una plataforma web es necesario que sea amena y dinámica, que no sea

estática para que el usuario se sienta más cómodo con ella, JQuery nos brinda esa capacidad de modificación dinámica del DOM que necesitamos para conseguir esa meta y suplir esa necesidad.

Escalabilidad


Rendimiento

Precisión

Funcionalidad y Matenibilidad

Usabilidad

Tabla 4.7 Resumen Tecnologías Utilizadas.

4.8 Prototipos del Software

Para poder realizar el diseño de la interfaz, se decidió implementar card sorting, se le presento a un grupo de usuarios potenciales, los elementos gráficos o metáforas, estos elementos gráficos debían asociarlos a la representación de velocidad, un vehículo y un mapa, la prueba fue realizada a 15 personas.

4.8.1 Card Sorting

Los componentes graficos que formarían parte de la aplicación se listaron del 1 al 9, como se puede ver el la figura 3.6.


Figura 4.6 Listado de elementos para el Card Sorting

Lo que se quería lograr con esta prueba era que en base a unos diseños previos de elementos que formarían parte de la interfaz de usuario, para que los usuarios potenciales votaran por el que les pareciera más apropiado para cada representación. Los elementos que formarían parte de la interfaz de usuario seria el velocímetro, para esta información se diseñaron 3 posibles velocímetros, ver figura 3.6, la opción 1, 2 y 3, para el modelo tridimensional en que estaría el vehículo se diseñaron, ver figura 3.6, la opción 4, 5 y 6, y finalmente para el mapa en el que se vería la posición actual del vehículo se diseñaron, ver figura 3.6, la opción 8, 8 y 9. A los 15 participantes se les mostraron todas las figuras y ellos votaban por las que les parecieran más acertadas para información pertinente (velocímetro, modelo tridimensional y ubicación), la información resultante está depositada en la tabla 3.7.

Metáforas Velocidad Automóvil Mapa

1 3

2 8

3 4

4 9

5 1

6 5


7 7

8 0

9 8

Tabla 4.8 Resultado Card Sorting

Analizando los resultados obtenidos de la prueba de card sorting vemos que la opción 2 de velocímetro, la opción 4 del modelo del vehículo y la opción 9 de la ubicación en el mapa, fueron las más votadas, debido a ello se eligió que estos fueran los diseños finales para la plataforma web final.

4.8.2 Desarrollo de prototipos

Escena que representa: Página Principal de la plataforma web

Funcionalidades: Función de velocidad actual, modelo tridimensional del vehículo, ubicación actual en el mapa, variables que manipulan el modelo tridimensional, latitud y longitud actual, y la dirección de la ubicación actual.

Tipo Usuario: Todos los usuarios.

Tabla 4.9 Prototipo Final de Plataforma Web

Iteración 1 - No.1 – Platafroma Web


4.8.2.1 Elementos involucrados Plataforma Web

Se eligieron unos tonos oscuros, no lo suficiente para hacer difícil la lectura de la información pero si lo suficientemente opacos para que no sean demasiado llamativos para el conductor y pueda causarle una distracción que le pueda ocasionar algún accidente. Hay varios elementos que forman parte de la interfaz de usuario, dependiendo de la importancia de la información que suministraba cada elemento se le dio un tamaño especifico y una ubicación particular en la pantalla. Los 3 grandes componentes de la interfaz son el velocímetro, modelo tridimensional y el mapa de la ubicación. A estos elementos se les dio una oportunidad y cada uno se le asignó un porcentaje del 30% para que mantuvieran una simetría. La ubicación de estos elementos se decidió debido a que el sistemas va a estar ubicado en un computador portátil en un vehículo, el velocímetro que consideraos la información más sensible ya que es la podría poner en riesgo la seguridad del conductor, se ubicó a la izquierda, de forma más cercana al conductor para que me manera rápida pueda observar la información, el modelo fue ubicado en el centro de la pantalla por motivos de estética y simetría, ya que al ser circular tanto el mapa como el velocímetro ubicar el modelo a cualquiera de los extremos no sería agradable para visual que tendría la interfaz y el mapa se ubicó en la parte derecha debido a que aunque queda un poco as lejos de la visual del conductor esto es algo bueno, debido a que si el conductor está buscando una dirección o como llegar a algún lugar usando como herramienta el mapa debe ir despacio para poder detallar de manera más eficiente el mapa y esto es favorable para su integridad ya que ver el mapa y manejar a una velocidad estándar podría ser perjudicial tanto para el como para las otras personas de su entorno.

Figura 4.7 Diseño Final Velocímetro.

Respecto al velocímetro, figura 3.8, se decidió adicionar tanto la representación análoga de la aguja para indicar la velocidad como directamente de forma numérica la felicidad exacta de desplazamiento, y a que se le da la opción al usuario que de manera rápida pueda ver una velocidad aproximada de la velocidad que está llevando observando con rapidez la aguja o ver de manera exacta a qué velocidad se está desplazando, aunque fijarse directamente en los números si le toma una fracción de segundo más.


Figura 4.8 Diseño Final Modelo tridimensional.

Para el modelo tridimensional se decidió agregar una carretera que hace el efecto de movimiento al momento de conducir para que tuviera una apariencia más amena y real, porque dejar el modelo solo del vehículo flotando era demasiado austero.

Figura 4.9 Diseño Final Ubicación en el Mapa.


4.8.2.2 Elementos Secundarios Interfaz.

Estos elementos destacados son información adicional relevante para el usuario, pero no la consideramos como primordial, son en su mayoría datos informativos adicionales, por ello no tienen un papel protagónico en la pantalla, debido a eso se le proporciono a este bloque un espacio mucho menor a comparación de los elementos principales y se le asignó un color gris de fondo para que se diferenciara del bloque de los elementos principales, pero aun manteniendo los colores oscuros poco llamativos.

Figura 4.10 Ejes de rotación

Los ejes de rotación (Pitch, Yaw, Roll) son los ejes X, Y y Z en los que se rota o se mueve el modelo tridimensional del vehículo y esta información es suministrada por el sensor inercial de media la cual se usa para modificar la orientación del vehículo en el escenario 3D y se plasmó en la parte superior izquierda de la pantalla.

Figura 4.11 Latitud y Longitud

La latitud y longitud son las coordenadas de ubicación actual en las que se encuentra el vehículo estas son suministradas por el GPS del teléfono móvil y son enviadas a la API de Google Maps para generar el mapa, se consideró que estos eran datos de interés para el usuario pero debido a que no es una información primordial se decidió darle un papel secundario en la pantalla.

Figura 4.12 Dirección de la Ubicación.

La dirección de la ubicación en la que se encuentra el vehículo en ese momento se calcula por medio de las coordenadas obtenidas con el GPS del teléfono móvil, estas son enviadas al API de Google Maps que no retorna la dirección de esa ubicación, estos datos son relevantes debido a que le brinda al usuario información importante que le puede ayudar al momento de dirigirse a su destino, pero no llega a un puto de relevancia tan alto como para ser un elemento principal por ello se ubica al lado de los demás elementos destacados.


Escena que representa: Página Principal de la aplicación movil

Funcionalidades: Función de obtener velocidad, latitud y longitud

Tipo Usuario: Todos los usuarios.

Tabla 4.10 Prototipo Final de aplicación móvil

Debido a que la aplicación móvil no va a ser usada como tal por el usuario, simplemente va a ser activada al momento de iniciar el sistema, no se realizó un diseño elaborado para la misma, simplemente se muestra en manta la información que se está obteniendo del dispositivo y que se está enviado a Firebase.

4.9 Pruebas y Evaluación de Software

Para probar el sistema se elaboraron un grupo de pruebas para analizar la veracidad de los datos entregados por el sistema y si es la información suministrada al usuario es equivalente respecto a la realidad. Inicialmente se diseña, se analiza e interpreta los resultados de un estudio sobre el sistema de medición. Teniendo en cuenta un factor importante para la obtención de la localización, el dispositivo móvil como el sistema deben contar con una conexión a Internet. Las pruebas sobre el sistema están compuestas por desplazamientos entre diferentes puntos de la ciudad con el fin de conocer la desviación en la medida, la información obtenida permite validar la fiabilidad del sistema de medición GPS, para validar la velocidad que se presenta en la interfaz se hace un proceso de comparación con la velocidad que se presenta en el tacómetro del vehículo en el que se desarrollaron las pruebas.

Iteración 1 - No.1 – Platafroma Web


4.9.1 Prueba sobre el sistema de posicionamiento global (GPS) El proceso de localización y obtención de la velocidad del vehículo se basa en el GPS, por consiguiente, un error de este sistema afecta la mayor parte de la información alojada en la interfaz. La siguiente prueba se realizó con el fin de apreciar la distancia que existe entre los datos a un cierto valor central e identificar la concentración de los datos en un cierto sector de la distribución.

4.9.1.1 Desviación media absoluta Esta será una prueba de repetibilidad, la cual constara de tomar la información de la latitud

y longitud suministrada por el sistema, en repetidas ocasiones en el mismo punto en diferentes instantes de tiempo, para así probar la consistencia de la información.

La desviación media absoluta nos propone que cuando sea mayor el valor de la desviación mayor es la dispersión de los datos. Para esta prueba se realizó un desplazamiento por un área, recopilando los datos obtenidos por el GPS.


Figura 4.13 Mapa del Recorrido de la Prueba

En la figura 3.13 se visualizan 10 puntos rojos los cuales son los puntos exactos de donde se tomaron las muestras, y el área azul es el camino que se sigue en el vehículo para tomar esos datos, se recorrió el área cuatro veces para un total de 40 muestras. Los resultados arrojados fueron depositados en la tabla 3.9

Numero de muestra

Punto Latitud Longitud

1 9 3,382663 -76,51663

2 2 3,384832 -76,51669

3 6 3,383501 -76,51665

4 8 3,382937 -76,51662

5 3 3,384598 -76,51664

6 1 3,385119 -76,51662

7 4 3,384298 -76,51668

8 10 3,382411 -76,51664


9 5 3,38406 -76,51667

10 7 3,383215 -76,51668

11 1 3,385118 -76,51661

12 3 3,384536 -76,5166

13 7 3,383128 -76,51657

14 10 3,382395 -76,51663

15 6 3,383453 -76,5166

16 5 3,383975 -76,51661

17 4 3,384291 -76,51664

18 9 3,382633 -76,51659

19 2 3,384799 -76,51661

20 8 3,382889 -76,51657

21 7 3,383179 -76,51667

22 2 3,384846 -76,5167

23 5 3,384054 -76,51668

24 1 3,385118 -76,51661

25 6 3,383485 -76,51664

26 9 3,382678 -76,51662

27 4 3,38431 -76,5167

28 10 3,382406 -76,51667

29 8 3,382947 -76,51665

30 3 3,384593 -76,51664

31 6 3,383455 -76,51661

32 3 3,384538 -76,51664

33 1 3,385111 -76,51664

34 8 3,382909 -76,51659

35 9 3,382631 -76,51661

36 10 3,382374 -76,51663

37 5 3,384028 -76,51659

38 4 3,384273 -76,51665

39 2 3,384814 -76,51662

40 7 3,383169 -76,5166

Tabla 4.11 Resultado Prueba

Una vez todas las muestras han sido recopiladas, se construye una tabla para realizar la desviación media absoluta, la Tabla 3.9 contiene los datos para el estudio, la columna número de muestras hace referencia al número de la muestra tomada, la columna punto, contiene el punto en donde se


ha tomado la muestra, las columnas Latitud y Longitud, almacenan la información de las coordenadas retornadas por el GPS, una vez la tabla está construida se procede a realizar el cálculo.

Desviación media

Latitud

Desviación media

Longitud

0,000821325 2,7235E-05

Tabla 4.12 Resultado Desviación Media Absoluta

Resultados: En la Tabla 3.10 obtenemos que la desviación media en los datos de latitud es de 0,00821325, demostrando que el grado de distancia de los datos es mínimo, para los datos de la longitud, el grado de la distancia de los datos es aún menor que el que se presentó en latitud, ya que la desviación media es de 2,7235E^-05. Con esto podemos probar que los datos capturados por el sistema en el mismo punto en múltiples ocasión y en diferentes instantes de tiempo son muy próximos entre sí, lo que nos puede suministrar certeza y veracidad de los datos obtenidos.

4.9.2 Prueba de Comparabilidad de Velocidad: Velocímetro vs Sistema. La prueba realizada respecto a la velocidad consiste en comparar la información arrojada por el sistema respecto a este ítem y compararla con la entregada por el velocímetro del vehículo (Figura 3.14), para ello se grabó la pantalla del sistema para tener registro de los valores entregado y se grabó el velocímetro del vehículo, ambos videos se sincronizaron para que coincidieran en los mismos instantes de tiempo, se tomaron 45 muestras en instantes de tiempo diferentes en cada uno de los sistemas para proceder posteriormente con su análisis. Se puede ver dos video de la prueba realizada se puede encontrar en el anexo A1 y anexo A2.


Figura 4.14 Dodge Demon 1971

Después de realizar un recorrido he ir capturando los datos entregados tanto por el sistema como por el velocímetro del vehículo, los datos arrojados fueron depositaos en la tabla 3.11.

Muestra Velocímetro (kh/h) Sistema (kh/h) Error (kh/h)

1 0 0 0

2 5 6 1

3 10 12 2

4 15 15 0

5 19 19 0

6 25 28 3

7 40 44 4

8 48 56 8

9 55 60 5

10 60 65 5

11 65 67 2


12 60 63 3

13 56 58 2

14 50 50 0

15 45 47 2

16 30 40 10

17 25 28 3

18 15 19 4

19 10 11 1

20 0 0 0

21 5 8 3

22 10 11 1

23 20 33 13

24 40 48 8

25 50 53 3

26 60 62 2

27 65 69 4

28 70 70 0

29 75 72 3

30 60 68 8

31 48 53 5

32 35 36 1

33 45 51 6

34 55 60 5


35 65 71 6

36 70 75 5

37 80 81 1

38 90 87 3

39 95 92 3

40 100 99 1

41 105 102 3

42 110 106 4

43 90 94 4

44 85 87 2

45 80 82 2

Total 151

Error Promedio 3,355555556

Tabla 4.13 Resultados Prueba de Comparabilidad de velocidad

Intervalo Frecuencia

Frecuencia

Acumulada

Frecuencia

Relativa

Frecuencia Relativa

Acumulada

[0-4) 28 28 0,62 0,62

[4-8) 12 40 0,27 0,89

[8-12) 4 44 0,09 0,98

[12-16) 1 45 0,02 1,00

Total 45 1,00

Tabla 4.14 Tabla de Distribución de Frecuencia


Figura 4.15 Diagrama de Torta de Error del Sistema

Resultados: La moda en el error del sistema son 3 km/h lo que concuerda con el error promedio de 3.336 km/h de media aritmética del sistema, lo que se puede apreciar de los datos obtenidos es que la información suministrada por el sistema es muy cercana a la real obtenida con el velocímetro del vehículo, se ve que entre 0 km/h y 4 km/h esta el 62% de error, por su parte entre 4 km/h y 8km/h esta el 27% del error y el 11% restante entre 8km/h y 13 km/h.

Lo que podemos apreciar es que el error emitido por el sistema es mínimo a comparación con el del vehículo en cuestión y los casos en los que la diferencia entre el sistema y la velocidad real es muy alta, son reducidos a comparación de los resultados generales.

4.9.3 Prueba de Comparabilidad App Odometro vs Sistema

Esta prueba consiste en comparar la información de las coordenadas arrojadas por el sistema respecto a una aplicación móvil, para esta prueba se recolectaron las coordenadas suministradas por la aplicación odómetro GPS y las coordenadas del sistema, las muestras para el estudio fueron tomadas en el área de la Figura 3.13.

Muestra APP (ODOMETRO GPS) Sistema

Error

en

metros

Latitud Longitud Latitud Longitud

1 3,384833 -76,516494 3,384832317387652 -76,51668768457192 20 m

2 3,384836 -76,516498 3,384598168169329 -76,51664453265235 30 m

3 3,38483 -76,516496 3,3842982211381667 -76,51667654048211 60 m

62%

27%

9%

2%

Error del Sistema

[0-4) [4-8) [8-12) [12-16)


4 3,384279 -76,516457 3,384060234359228 -76,51666704049275 30 m

5 3,383435 -76,516438 3,3835014975674773 -76,51664551184585 20 m

6 3,38319 -76,516492 3,38321554545671367 -76,51667855407914 20 m

7 3,382766 -76,516504 3,3829372843703305 -76,51661607961262 20 m

8 3,382637 -76,516523 3,382663325936427 -76,51662553092322 10 m

9 3,382421 -76,516509 3,382411506880991 -76,51663526959565 10 m

10 3,382263 -76,516484 3,382395410947994 -76,51663070056706 20 m

11 3,382438 -76,516662 3,382633617037426 -76,5165945875191 20 m

12 3,382533 -76,516655 3,382889506551239 -76,51657104062944 40 m

13 3,383148 -76,516642 3,3831282211421487 -76,51657374245534 10 m

14 3,383490 -76,516720 3,3834536724697992 -76,51659527787183 10 m

15 3,383954 -76,516527 3,3839757446793715 -76,51661165727677 10 m

Total 330 m

Error promedio 22 m

Tabla 4.15 Resultado de la Prueba de Comparabilidad GPS

Intervalo Frecuencia Frecuencia

Acumulada

Frecuencia

Relativa Frecuencia Relativa Acumulada

[0-20) 11 11 0,73 0,73

[20-40) 3 14 0,20 0,93

[40-60) 1 15 0,07 1,00

Total 15 1,00

Tabla 4.16 Distribución de Frecuencia.

Resultados:


Para la prueba se recolectaron un total de 15 muestras, la información de la aplicación móvil Odómetro GPS y del sistema esta almacenada en la Tabla 3.13, la prueba nos arroja un resultado de error promedio de 22 metros y una frecuencia relativa del 73% en los rangos de 0 a 20 metros, para validar la proximidad del sistema al punto número dos de la Figura 3.13, se procedió a escoger la muestra número uno de la Tabla 3.13, esta muestra contiene las coordenadas del punto número dos de la Figura 3.13.

Figura 4.16 Odómetro GPS. Figura 4.17 Aplicación móvil del sistema.

Una vez seleccionada la muestra número uno de la tabla 4.13 se procedió a ingresar las coordenadas en Google Maps.


Figura 4.18 Mapa Odómetro GPS. Figura 4.19 Mapa aplicación móvil del sistema.

Una vez finalizado el proceso de ingresar las coordenadas de la aplicación móvil Odómetro GPS y

la aplicación móvil del sistema en Google Maps, se puede concluir que las coordenadas del sistema están más aproximadas al punto número dos de la Figura 3.13 frente a las coordenadas de Odómetro GPS, debido a que el error de distancia en las coordenadas del sistema al punto número dos de la Figura 3.13 se encuentra en un rango inferior a los cinco metros, caso contrario sucede con Odómetro GPS, donde su rango de error se encuentra entre los diez metros.

4.9.4 Prueba de Caja Negra Esta prueba está orientada a la funcionalidad del sistema, en esta prueba se omiten los aspectos

técnicos, en cada aspecto en el que se incurre es funcional, esta prueba fue realiza en la interfaz en usuario.

Para realizar esta prueba se define las entradas y salidas del sistema, por entradas del sistema

tenemos: Los ángulos de rotación en Euler (pitch, yaw y roll), latitud, longitud y la velocidad, en las salidas al recibir la rotación de los ángulos de Euler, se espera como respuesta del sistema, la rotación del modelo 3D del vehículo y actualización de los datos de pitch, yaw y roll con los valores correspondientes de la unidad inercial de medida, en el momento en que la latitud y longitud cambian, se espera una actualización de la ubicación del mapa en Google Maps y de la dirección que se determina a partir de las coordenadas, al recibir la velocidad, la actualización de la información del tacómetro.

ROTACION

DEL MODELO

3D

Entradas Salidas Esperadas Salidas obtenidas Éxito

Pitch Yaw Roll

Rotación del

modelo 3D

Actualización

de los datos

Rotación del

modelo 3D

Actualización

de los datos

0,00 0,00 0,00 NO SI NO SI SI

-0,29 -0,07 0,00 SI SI SI SI SI

0,46 -0,37 0,04 SI SI SI SI SI

-1,33 0,16 0,42 SI SI SI SI SI

-2,61 -0,02

-

0,01 SI SI SI SI SI

2,52 -0,03 0,05 SI SI SI SI SI

Actualización

de la Latitud Longitud

Actualización

del mapa

Actualización

de los datos

Actualización

del mapa

Actualización

de los datos


ubicación en

el mapa de

Google Maps

3,38483

-

76,51669 SI SI SI SI SI

3,38483

-

76,51669 NO NO NO NO SI

3,38512 -


3,38429 -


3,38429 -

76,51664 NO NO NO NO SI

Actualización

de la

información

del

tacómetro

Velocidad

Actualización

del

tacómetro

Actualización

del

tacómetro

10 km SI SI SI

0 km SI SI SI

0 km NO NO SI

20 km SI SI SI

60 km SI SI SI

Tabla 4.17 Resultado de la Prueba de Caja Negra.

Resultados: La Tabla 3.15 contiene la información del desarrollo de la prueba de testeo de caja

negra, en ella se puede apreciar las entradas al sistema, las salidas esperadas, y las salidas del sistema, en la columna éxito de la Tabla 3.15, se define si el sistema respondió de la manera esperada, con base a los resultados de la prueba, se puede concluir que el sistema es funcional, respondió de la manera esperada sin presentar errores.

4.10 Acceso a la Aplicación

Se espera subir al servidor lidis el código fuente de todos los sistemas desarrollados en este proyecto, tanto la plataforma web, como la aplicación móvil y el lector seria.


5. ANÁLISIS DE RESULTADOS

5.1 Análisis de impactos 5.2 Utilización de herramientas 5.3 Análisis de diseño de componentes 5.4 Cumplimiento de objetivos 5.5 Experiencia de diseño en ingeniería de software 5.6 Trabajos futuros


5. ANÁLISIS DE RESULTADOS 5.1 Análisis de Impactos

La propuesta de ingeniería discutida en el presente documento tiene diferentes impactos en el escenario en el cual se contextualiza el problema. Estos impactos pueden ser analizados y discutidos desde las siguientes dimensiones o perspectivas: ambiental, social, económica, técnica, e individual.

Ambiental: Debido a que este sistema cuenta con un mapa que le permite al conductor conocer su ubicación en todo momento, esto afectara de manera directa a una reducción los casos en donde el conductor se extravía camino a su destino, al facilitar esto significa que los conductores llegaran de una manera más fácil a sus destinos reduciendo el tiempo de viaje en los casos que el conductor se perdía, y un tiempo reducido de conducción significa un consumo de gasolina también menor, y lo competente al ambiente sería favorable con respeto a la reducción de polución de gases por parte de automóviles.

Social: Reduce un poco la brecha entre clases sociales a la posibilidad de acceder a sistemas de asistencia a la conducción ya que como este sistema es instalable en cualquier vehículo es más accesible que los vehículos que los traen equipados de fabrica

Económico: Una reducción económica en los gastos generados si se desea acceder a sistemas de asistencia a la conducción, como se mencionaba en el impacto social, debido a que es instalable en cualquier vehículo, el conductor no debe de cambiar su automóvil para poder acceder a estos sistemas.

Técnica: Debido a que estos sistemas de asistencia a la conducción estas tomando fuerza en la actualidad se prevé una gran evolución en este tópico y cambios en relación a la actualidad debido a los nuevos dispositivos de hardware que se pueden adicionar a estos sistemas.

Individual: Este puede ser el mayor impacto que genere el proyecto, debido a que está desarrollado para ser usado por un conductor, el individuo que acceda a este sistema, le asistirá de manera adecuada al momento de conducir su vehículo, facilitándole de manera notoria su actividad, gracias a la información brindad por el sistema. 5.2 Utilización de herramientas

QT IDE: Qt Creator es un entorno de desarrollo integrado de plataforma cruzada (IDE) para crear aplicaciones C ++ y QML para múltiples plataformas de escritorio, embebidas y móviles. Viene con un editor de código y está integrado con herramientas para diseñar, codificar, probar, implementar y mantener su software durante todo el ciclo de vida del producto y se utilizó para desarrollar el lector serial el cual está construido en C++.

Sublime Text 3: Editor de texto, se utilizó en la parte del desarrollo Frontent de la plataforma web debido a la facilidad que tiene este editor para ayudar mediante atajos útiles que facilitan el desarrollo y diseño web.

NetBeans IDE 8.0.2: Entorno de desarrollo, en el cual se desarrolló toda la parte backend de la plataforma web debido a que gracias a que soporta PHP, lenguaje utilizado del lado del servidor, facilita el debugg y encontrar errores, esto facilita el desarrollo.


XAMPP: Una distribución de Apache, se eligió ya que nos permite tener nuestro propio servidor web local en el cual desplegar la plataforma web para realizar las pruebas y un gestor de bases de datos para poder administrar.

Android Studio: Entorno de desarrollo certificado para el desarrollo de aplicaciones Android nativas.

Microsoft Word: Editor de texto, se utilizó para la edición de este documento, debido a su reconocimiento en este ámbito y la facilidad que ofrece al redactar documentos.

Microsoft Excel: Herramienta de hojas de cálculo, se eligió esta herramienta debido a que es muy potente y permite hacer los calculo que se requerían en este caso el cálculo de todos los resultados arrojados por las pruebas se calcularon y graficaron utilizando esta herramienta.

PostMan: Herramienta para probar servicios, se utilizó para probar los servicios expuestos por la plataforma web.

VisulaParadigm: Herramienta de modelado UML, se eligió debido a la gran variedad de diagramas que permite modelar y a la diversidad de componentes con los que cuenta, los diagramas modelados para el diseño del sistema fueron realizados en esta herramienta.

5.3 Cumplimiento de Objetivos

Teniendo como referencia los objetivos especificados en la sección 1.4 y 1.5 se contratará el cumplimiento de los mismos.

Objetivo general: Como se demuestra a lo largo de este documento, de desarrollo un numero de sistemas los cuales permiten la estimación de movimiento propio en vehículo, empleando unidades inerciales de medida por medio de sensores y GPS por medio de un dispositivo móvil, dicha información es presentada de manera adecuada al conductor para que le puedan asistir de forma correcta. Todo esto enmarcado en el proyecto COMVIDAS.

Objetivo específico 1: Se seleccionaron la variables empleadas en la estimación de movimiento propio de sistemas de asistencia a la conducción, las cuales fueron Pitch, Yaw y Roll, el vector (X, Y, Z) obtenido del sensor inercial de medida, la latitud, longitud y velocidad, obtenida del dispositivo móvil, toda esta información se representó de manera correcta en la interfaz principal de la plataforma web a la cual el usuario tiene acceso a ella.

Objetivo Especifico 2: Se seleccionó he implemento un protocolo de comunicación para la obtención de los dispositivos hardware, para el sensor inercial de medida se comunicó mediante puerto serial para la obtención de los datos suministrados por el sensor y luego mediante el consumo de servicios RestFul expuesto por la plataforma web se guardaban en la base de datos, la cual procedía a ser leída por la plataforma web para ya con esos datos obtenidos procediera a representarlos en la interfaz mediante la modificación de la orientación del modelo tridimensional. Para el caso del dispositivo móvil, por medio de una aplicación se obtenía por medio de un PlungIn de Android la posición GPS y la velocidad de desplazamiento, estos datos, latitud, longitud y velocidad, eran guardado en una base de datos NoSQL de Firebase por medio de un servicio expuesto por el mismo, luego la plataforma web procede obtener esos datos consumiendo un servicio Rest y ya con esa información procedee a representa en la


interfaz, la latitud y la longitud se utiliza para establecer la ubicación en el mapa de google maps y obtener la dirección en la que se encuentra ubicado y la velocidad es utilizada para actualizar el velocímetro de la vista y mostrar dicha información.

Objetivo Especifico 3: Se desarrolló una interfaz de usuario amigable, en la cual se representan los datos obtenidos del hardware para así conformar un sistema avanzado a la conducción que le facilita al usuario su actividad de conducción gracias a la información mostrada en la interfaz (ubicación, velocidad y orientación del vehículo).

Objetivos Especifico 4: Se realizaron pruebas de repetibilidad, comparabilidad y de caja negra, para validar la veracidad de los datos obtenidos por el hardware y representados en la interfaz, los resultados de dichas pruebas fueron positivos y alentadores, y se puede concluir que los datos representados en la interfaz suministrados por los dispositivos es veraz.

5.4 Experiencia de diseño en ingeniería de software

La experiencia obtenida tanto en la construcción de este documento y en general de toda la carrera, son muchas y muy importantes que nos marcaran tanto en la vida profesional como personal, aquí algunas de ellas:

Capacidad de comunicación con otros integrantes de equipos, liderazgo y vocería para tomar las riendas de un grupo cuando hay la necesidad de ello.

Capacidad de análisis de los problemas y la búsqueda de una solución óptima, procurando que beneficie a todas las parte involucradas.

El uso de buenas prácticas de desarrollo de software en todos los componentes que hacen parte del ecosistema, para la fácil corrección de errores y aplicación de cambios.

Capacidad de gerencia proyectos de ingeniería, planear, asignar tarea, distribución de recurso y liderazgo.

Proceso de pruebas de software, vital para el aseguramiento de la calidad y constatar que se desarrolló lo que se tenía presupuestado.

Diseño de arquitectura que permita un alto nivel de desacoplamiento y cohesión, ya que esta es la base sobre la que se levanta un proyecto y si no se ha definido de manera adecuada desde el inicio se está condenado al fracaso.

Modelamiento correcto de datos, que sea lo mas aproximado a la realidad y que supla las necesidad requeridas por el software.

5.5 Trabajos Futuros

• Intercambiar el A-GPS por un GPS para lograr la independencia de la conexión de internet del dispositivo móvil. • Implementación de algoritmos alternativos para el proceso de obtención de la velocidad del vehículo. • Diseñar una interfaz en donde se pueda seleccionar el modelo 3D del vehículo en el cual ira integrado el sistema.


6. REFERENCIAS


6. REFERENCIAS

[1] SAP, Business Intelligence Platform RESTful Web Service Developer Guide, 2017. https://help.sap.com/doc/220244879d104f2e8e8b37e0fa0bdd2d/4.2.3/en-US/sbo42sp3_bip_rest_ws_en.pdf [2] universidad complutense de madrid, Proceso software y ciclo de vida, 2009. https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/02-ProcesoCicloDeVida.pdf [3] G. Grimes, «Global positioning system standard positioning service performance standard,» 2008. [4] R. d. F., T. Vanzin y V. R. Ulbricht, «Graphical interface design: semiotic interpretation of the composition of elements,» InfoDesign, vol. 7(2), pp. 23-31, 2010. [5] N. Crilly, A. Maier y P. J. Clarkson, «Representing Artefacts as Media:Modelling the Relationship Between Designer Intent and Consumer Experience,» International Journal of Design, vol. 2(3), pp. 15-27, 2008. [6] D. C. Ling, L. S. Teo y J. G. Byrne, «Modelling interface aesthetics,» Information Sciences 152, pp. 25-46, 2003. [7] R. Heimgärtner, «A Tool for Getting Cultural Differences in HCI,» Human-Computer Interaction, New Developments, pp. 343-368, 2008. [8] Y. H. Montero y S. O. Santamaría., «Informe APEI sobre usabilidad,» No solo usabilidad, 2009. [9] F. J. Alonso, J. Naranjo, G. Zato y M. Ariza, «Integración de diferentes sistemas ADAS en un interfaz de usuario adaptado a las características del conductor,» 2011. [10] R.Ramani, S.Valarmathy, Dr. N.SuthanthiraVanitha y S.Selvaraju, M.Thiruppathi, Engineering College, TN, India, 2013. [11] Thomas O’Kane y John V. Ringwood,Vehicle Speed Estimation Using GPS/RISS (Reduced Inertial Sensor System), Department of Electronic Engineering National University of Ireland, Maynooth, (NUIM), Maynooth, Co. Kildare, 2013. [12] Simon Nestler, Marcus Tönnis, and Gudrun Klinker, Common Interaction Schemes for In-Vehicle User-Interfaces, Technische Universität München, 2009. [13] Albrecht Schmidt, Anind K. Dey, Andrew L. Kun, Automotive User Interfaces: Human Computer Interaction in the Car, Estados Unido, 2010. [14] S. M. Bascón, J. A. Rodríguez, S. L. Arroyo, A. F. Caballero y F. López-Ferreras, «An optimization on pictogram identification for the road-sign recognition task using SVMs,» Computer Vision and Image Understanding, vol. 114, nº 3, pp. 373-383, 2010.

https://help.sap.com/doc/220244879d104f2e8e8b37e0fa0bdd2d/4.2.3/en-US/sbo42sp3_bip_rest_ws_en.pdf

https://help.sap.com/doc/220244879d104f2e8e8b37e0fa0bdd2d/4.2.3/en-US/sbo42sp3_bip_rest_ws_en.pdf

https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/02-ProcesoCicloDeVida.pdf


[15] M. Bishop, Pattern recognition and machine learning, 2nd ed., Springer, 2007. [16] Damian Vigouroux, Implementación De Unidad De Mediciones Inerciales (IMU) Para Robótica Utilizando Filtro De Kalman,Universidad Simón Bolívar, 2010. [En línea]. Disponible: http://159.90.80.55/tesis/000149068.pdf [17] Alberto Manzanares, Estudio De Modelo Matemáticos De Acelerómetros Comerciales. [En línea]. Disponible: http://bibing.us.es/proyectos/abreproy/11669/fichero/Memoria.pdf [18] Tamara Rodríguez y María Bernabeu, Sistema De Posicionamiento Global (GPS), 2010. [En línea]. Disponible: http://webs.um.es/bussons/GPSresumen_TamaraElena.pdf [19] Official U.S. Government information about the Global Positioning System (GPS) and related topics. [En línea]. Disponible: http://www.gps.gov/systems/gps/space/ [20] Jeremy Laukkonen, 13 Advanced Driver Assistance Systems, 2016. [En línea]. Disponible: http://cartech.about.com/od/Safety/tp/Advanced-Driver-Assistance-Systems.htm [21] 3-Space Sensor Miniature Attitude & Heading Reference System. [En línea]. Disponible: http://yostlabs.com/wp/wp-content/downloads/3-Space/YEI_TSS_Users_Manual_3.0_r1_4Nov2014.pdf [22] W. España, Guía Breve De Servicios Web, [En línea]. Disponible: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb [23] Historia del GPS, [En línea], Disponible: http://www.alsitel.com/tecnico/gps/historia.htm [24] Pedro Gutovnik, Como funciona el GPS, 1999. [En línea], Disponible: http://gutovnik.com/como_func_sist_gps.htm

http://159.90.80.55/tesis/000149068.pdf

http://bibing.us.es/proyectos/abreproy/11669/fichero/Memoria.pdf

http://webs.um.es/bussons/GPSresumen_TamaraElena.pdf

http://cartech.about.com/od/Safety/tp/Advanced-Driver-Assistance-Systems.htm

http://yostlabs.com/wp/wp-content/downloads/3-Space/YEI_TSS_Users_Manual_3.0_r1_4Nov2014.pdf

http://yostlabs.com/wp/wp-content/downloads/3-Space/YEI_TSS_Users_Manual_3.0_r1_4Nov2014.pdf


7. ANEXOS

A1 (Video de Prueba 1, 19-Mayo-2017) https://www.youtube.com/watch?v=s5iMgAAwP0c A1 (Video de Prueba 2, 28-Julio-2017) https://www.youtube.com/watch?v=d3y4RMyTi1c

https://www.youtube.com/watch?v=s5iMgAAwP0c

https://www.youtube.com/watch?v=d3y4RMyTi1c

estimaciÓn de movimiento propio en vehÍculos...

Documents