plataforma abierta para dispositivos vestibles...

Plan de Proyecto del Trabajo Final de la

Maestría de Sistemas Embebidos

Esp. Ing. Rodrigo Alejandro Tirapegui

Plataforma abierta para dispositivos vestibles (wearables)

Autor


Director del trabajo

Mg. Ing. Diego Javier Brengi (INTI)

Jurado propuesto para el trabajo

- Mg. Ing. Agustin Bassi (UNLZ) - Dr. Ing. Emanuel Irrazabal (UNNE) - Mg. BioIng. Eduardo Filomena (UNER)

Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de la

Tecnología y la Innovación entre marzo y abril de 2019.

Página 1 de 31




Tabla de contenido

Registros de cambios 3

Acta de Constitución del Proyecto 4

Descripción técnica-conceptual del Proyecto a realizar 5

Identificación y análisis de los interesados 8

1. Propósito del proyecto 9

2. Alcance del proyecto 9

3. Supuestos del proyecto 9

4. Requerimientos 10

5. Entregables principales del proyecto 11

6. Desglose del trabajo en tareas 11

7. Diagrama de Activity On Node 13

8. Diagrama de Gantt 14

9. Matriz de uso de recursos de materiales 15

10. Presupuesto detallado del proyecto 17

11. Matriz de asignación de responsabilidades 18

12. Gestión de riesgos 19

13. Gestión de la calidad 21

14. Comunicación del proyecto 26

15. Gestión de Compras 27

16. Seguimiento y control 27

17. Procesos de cierre 30

Página 2 de 31




Registros de cambios

Revisión Detalle de los cambios realizados Fecha

1.0 Creación del documento 16/03/2019

2.0 Confección del documento

● Redacción Acta de Constitución del proyecto ● Redacción Descripción técnica-conceptual del

Proyecto ● Redacción Identificación y Análisis de los Interesados ● Redacción ítems 1 a 9

23/03/2019

3.0 Finalización en la confección del documento

● Redacción ítems 9 a 17

24/03/2019

3.1 ● Correcciones Acta de Constitución del proyecto 31/03/2019

3.2 ● Corrección imagenes Diagrama de Gantt 03/04/2019

Página 3 de 31




Acta de Constitución del Proyecto

Buenos Aires, 3 de marzo de 2017

Por medio de la presente se acuerda con el Sr. Rodrigo Alejandro Tirapegui que su Proyecto Final

de la Maestría en Sistemas Embebidos se titulará “Plataforma abierta para dispositivos vestibles

(wearables)”, consistirá esencialmente en el prototipo preliminar de un rastreador de actividad vestible

basado en una plataforma de hardware y código abierto diseñada por el Instituto Nacional de Tecnología

Industrial (INTI), y tendrá un presupuesto preliminar estimado de 600 hs de trabajo, con fecha de inicio

lunes 11 de marzo de 2019 y fecha de presentación pública a partir del lunes 16 de diciembre de 2019.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg Diego Javier Brengi

Director de la MSE-FIUBA INTI Micro y nanotecnología

Diego Javier Brengi

Director del Trabajo Final

Agustín Bassi Emanuel Irrazabal

Jurado del Trabajo Final Jurado del Trabajo Final

Eduardo Filomena

Jurado del Trabajo Final

Página 4 de 31




Descripción técnica-conceptual del Proyecto a realizar

Los dispositivos vestibles (wearables) son pequeños módulos electrónicos que se incorporan a las prendas

o accesorios para cumplir alguna función en las áreas de entretenimiento, bienestar y deporte, pero que

también pueden aplicarse en ámbitos laborales, militares, de seguridad y vigilancia, y muchos otros.

El desarrollo de estos dispositivos se incrementó a medida que los componentes electrónicos se hicieron

más pequeños, y las tecnologías de visualización y comunicación avanzaron a lo largo de los años.

Por ejemplo, a mediados de los años setenta, la mayoría de los dispositivos electrónicos portátiles tenían

una correa que colgaba alrededor del cuello; mientras que hacia finales de la década, las cámaras, las

radios e incluso el Walkman se habían vuelto más pequeños, más baratos y personales, creando las bases 1

para la industria de la electrónica de consumo.

En la actualidad, ésta tecnología portátil es a menudo utilizada para registrar variables corporales

relacionadas con la actividad física, dado que, al estar en contacto cercano con el cuerpo, puede recopilar

datos fácilmente. Estas funciones se agrupan en una sola unidad denominada rastreador de actividad , 2

que incluye el monitoreo de los siguientes parámetros:

● Ritmo cardíaco

● Calorías quemadas

● Cantidad de pasos caminados

● Presión sanguínea

● Tiempo dedicado a realizar actividad física

A nivel mundial, el crecimiento del mercado de los rastreadores de actividad se ve impulsado por el

aumento en la tendencia de la tecnología portátil entre los jóvenes, por la generalización de una mayor

conciencia sobre salud entre los consumidores, y por la facilidad de acceso a las funciones de los

smartphones y su compatibilidad con una amplia gama de sistemas operativos.

En base a la descripción presentada, el objetivo del trabajo es desarrollar el prototipo operativo de un rastreador de actividad, que permita validar y demostrar el uso de la plataforma de hardware denominada PlatC, que fue diseñada por el Instituto Nacional de Tecnología Industrial (INTI).

Al momento de la escritura de este documento, en el INTI se han desarrollado dos plataformas abiertas para aplicación en vestibles:

● Spora, cuyo diseño está publicado en Github. ● PlatC, cuyo diseño aún no se ha publicado abiertamente, a la espera de tener avanzadas las

rutinas de firmware de prueba y alguna aplicación demostrativa.

La plataforma de hardware PlatC ha sido verificada en sus primeras etapas de encendido y programación, y queda por probar los distintos periféricos que la integran.

1 https://es.wikipedia.org/wiki/Walkman 2 https://en.wikipedia.org/wiki/Activity_tracker

Página 5 de 31




En este sentido, se busca desarrollar un prototipo de rastreador de actividad con el cual se logre cubrir los siguientes aspectos, necesarios para su publicación en forma abierta:

● Brochure de la plataforma de hardware y mejora de la documentación. ● Rutinas de prueba básicas del hardware. ● Protocolo básico de comunicación. ● Aplicación básica demostrativa con algún tipo de interacción con un smartphone o tablet para

sistema operativo Android.

Con la publicación de la plataforma PlatC se busca promover la innovación para crear, diseñar y desarrollar soluciones electrónicas en vestibles, impulsando de ese modo el desarrollo tecnológico nacional y dándole visibilidad positiva a la electrónica argentina.

El hardware de PlatC cuenta con los siguiente periféricos:

● Un módulo Bluetooth BGM113 de Silicon Labs. ● Un acelerómetro MPU 9250. ● Un pulsador. ● Un LED RGB. ● Un parlante. ● Un conector de expansión que permite agregar sensores, actuadores o un display. ● Un microcontrolador ARM Cortex M0+ SAMD21 de Atmel/Microchip.

En las figuras 1 y 2 se muestran el prototipo fabricado y el diagrama en bloques de la plataforma de hardware PlatC.

Figura 1. Prototipo de hardware plataforma PlatC.

Página 6 de 31




Figura 2. Diagrama en bloques de la plataforma de hardware PlatC.

El proyecto abarca la implementación del firmware del microcontrolador SAMD21 y una aplicación demostrativa en un smartphone que será utilizada para realizar ejercicio físico.

El firmware será implementado en base al framework denominado Reactive framework for hierarchical state machines (RKH ), el cual provee la infraestructura necesaria para construir embedded software bajo 3

el paradigma de la programación dirigida por eventos, basado en la ejecución simultánea de máquinas de estado del tipo statecharts de acuerdo con la especificación UML 2.x . 4 5

La aplicación demostrativa implementará un protocolo de comunicación (sobre Bluetooth), con el cual será posible contar la cantidad de pasos caminados, ó el número de repeticiones de abdominales o flexiones generados por PlatC, e informarlos en el momento (mediante comandos de voz, como si fuera un entrenador).

En la figura 3 se muestra la arquitectura en capas del framework RKH.

3 https://www.vortexmakes.com/que-es/ 4 http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf 5 http://agilemodeling.com/essays/umlDiagrams.htm

Página 7 de 31




Figura 3. Arquitectura en capas del framework RKH.

Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Cliente Mg. Ing. Diego Javier

Brengi

INTI Micro y

nanotecnología

Coordinador en el

área de desarrollos

electrónicos

Impulsor Mg. Ing. Diego Javier

Brengi

INTI Micro y

nanotecnología

Coordinador en el


electrónicos

Responsable Esp. Ing. Rodrigo

Alejandro Tirapegui

- Estudiante MSE

Colaboradores Ing. Francisco Gargiulo - Desarrollador

Orientadores Mg. Ing. Diego Javier

Brengi

INTI Micro y

nanotecnología

Coordinador en el


electrónicos

Usuario Final Instituciones, empresas o

entusiastas que busquen

desarrollar aplicaciones

en vestibles

- -

Página 8 de 31




1. Propósito del proyecto

El propósito de este proyecto es desarrollar el prototipo operativo de un rastreador de actividad vestible

(activity tracker), que permita demostrar el uso de la plataforma de hardware abierta denominada PlatC,

diseñada por el Instituto Nacional de Tecnología Industrial (INTI). El dispositivo le permitirá al usuario

visualizar sus estadísticas diarias de salud y estado físico, descubrir su progreso, y recibir asesoramiento

personalizado y recordatorios de sus objetivos a través de una aplicación en su smartphone o tablet.

2. Alcance del proyecto

El proyecto incluye el diseño e implementación del firmware para el prototipo de hardware de la plataforma PlatC, el diseño e implementación del software de una aplicación celular para sistema operativo Android, confección de la documentación de la plataforma de hardware y la demostración en condiciones de laboratorio.

Específicamente se cubrirán los siguiente aspectos:

● Adquisición de datos de aceleración, giroscopio y sensor de temperatura ambiente del dispositivo vestible.

● Procesamiento de los datos recogidos para determinar cantidad de pasos caminados/repeticiones de abdominales realizadas.

● Diseño e implementación de un protocolo de comunicación a través de la interfaz Bluetooth. ● Indicación del estado de conexión del dispositivo vestible. ● Visualización de los datos adquiridos y parámetros de configuración en una aplicación celular. ● Realización de tests y documentación detallados.

El proyecto no incluye el diseño y fabricación de la carcasa plástica para el dispositivo vestible, ni tampoco el manejo de más de un dispositivo en simultáneo.

3. Supuestos del proyecto

Para el desarrollo del presente proyecto se supone que:

● Los gastos en componentes e insumos serán cubiertos por INTI dentro de las posibilidades administrativas de la caja chica.

● Disponibilidad de los laboratorios e instrumental de INTI para cubrir la tarea de desarrollo. ● Disponibilidad de un prototipo de hardware funcional de PlatC desde la fecha de inicio del

proyecto. ● Disponibilidad de los desarrolladores del hardware para posibles consultas sobre el mismo.

Página 9 de 31




4. Requerimientos

Los requerimientos del sistema se mencionan a continuación, diferenciándolos según si se trata de requerimientos funcionales o no funcionales.

Además, se indica al lado de cada requerimiento su prioridad, siendo [1] muy prioritario y [3] poco prioritario.

Requerimientos Funcionales:

1. Módulo PlatC

1.1 Detectará movimientos con aceleración superiores a MOTION_THR. [1]

1.2 Cuando se detecte una aceleración superior a MOTION_THR, transmitirá inmediatamente un paquete PlatCData hacia PlatCApk. [1]

1.3 Cuando se detecte una aceleración superior a MOTION_THR, encenderá y mantendrá el indicador MOTION_LED durante MOTION_DET_TIME. [1]

1.4 Se vinculará con PlatCApk mediante un enlace BLE. [1]

1.5 Cuando se encuentre vinculado con PlatCApk, encenderá el indicador BLE_LED. [1]

1.6 Cuando se encuentre en proceso de carga de baterías, encenderá el indicador BATTERY_LED. [1]

1.7 Cuando no exista vínculo entre PlatCApk y no se esté en curso una indicación de detección de movimiento mediante MOTION_LED, el sistema encenderá en secuencia los indicadores MOTION_LED, BLE_LED, y BATTERY_LED cada KEEPALIVE_TIME. [1]

1.8 Recibirá el paquete PlatCApkSettings con configuraciones desde el PlatCApk. [1]

1.9 Ajustará el umbral MOTION_THR de acuerdo al paquete de configuración PlatCApkSettings enviado por PlatCApk. [1]

1.10 Cuando inicie será descubrible por PlatCApk. [1]

1.11 Cuando permanezca sin establecer vínculo con PlatCApk durante más de DISCONNECTED_TIMEOUT dejará de ser descubrible. [2]

1.12 Cuando esté vinculado a PlatCApk y se presione PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME se desvinculará y permanecerá descubrible. [1]

1.13 Cuando esté vinculado a PlatCApk y se presione PUSH_BUTTON durante menos de SHORT2LONG_BUTT_TIME transmitirá un paquete PlatCData a PlatCApk. [2]

1.14 Cuando no sea descubrible y se presione PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME será descubrible inmediatamente. [1]

2. Módulo de visualización

2.1 Deberá ser una aplicación para sistema operativo Android. [2]

2.1 Deberá mostrar los parámetros de configuración y datos adquiridos por el módulo PlatC. [1]

Página 10 de 31




2.3 Deberá describir de forma hablada los datos adquiridos por el módulo PlatC. [1]

2.2 Deberá permitir la modificación de los parámetros de configuración del módulo PlatC. [1]

Requerimientos No Funcionales:

1. Módulo PlatC

1.1 Las configuraciones de PlatCSettings serán almacenadas en memoria no volátil. [1]

1.2 Filtrará el rebote del pulsador PUSH_BUTTON. [1]

1.3 MOTION_DET_TIME será configurable en tiempo de compilación. [3]

1.4 Mantendrá el tiempo de operación en memoria no persistente. [3]

1.5 El firmware del módulo debe diseñarse minimizando el consumo. [1]

1.6 Debe cumplir con la recomendación IEC 801 de “Compatibilidad electromagnética para medición de procesos industriales y equipos de control (por extensión)”. [1]

Los requerimientos listados previamente surgen del análisis de los requerimientos establecidos por INTI durante el desarrollo es la plataforma de hardware abierta Spora.

5. Entregables principales del proyecto

Los entregables del proyecto son:

● Prototipo del módulo PlatC. ● Manual de uso de la aplicación demostrativa. ● Diagrama esquemático del hardware. ● Código fuente del software. ● Informe de avance. ● Memoria del proyecto. ● Presentación ante el jurado.

6. Desglose del trabajo en tareas

Se enumeran a continuación las tareas que componen el proyecto:

1. Gestión de Proyecto 115 hs

1.1 Planificación y presentación del Trabajo Final 15 hs

1.2 Confección del Manual de Usuario 10 hs

1.3 Confección del Informe de Avance 10 hs

1.4 Confección de la Memoria del Trabajo 60 hs

Página 11 de 31




1.5 Preparación de la Presentación Final 20 hs

2. Diseño e Implementación de Firmware 255 hs

2.1 Análisis e investigación del framework RKH 25 hs

2.2 Análisis e investigación del stack Bluetooth Low Energy (BLE) 20 hs

2.3 Configuración del entorno/herramientas de desarrollo 15 hs

2.4 Definición e implementación de máquinas de estados e interfaces 50 hs

2.5 Definición e implementación del protocolo de comunicación BLE 40 hs

2.6 Implementación de drivers para adquisición de datos de los sensores 60 hs

2.7 Implementación de drivers para el manejo del transceptor BLE 30 hs

2.8 Documentación del firmware 15 hs

3. Diseño e Implementación de Aplicación de Visualización y Configuración 135 hs

3.1 Análisis e investigación del SDK Android 15 hs

3.2 Análisis e investigación de las APIs TextToSpeech 25 hs

3.3 Configuración del entorno/herramientas de desarrollo 20 hs

3.4 Implementación de funcionalidades e interfaces 60 hs

3.5 Documentación del software 15 hs

4. Verificación y Validación 105 hs

4.1 Implementación y ejecución de rutinas de prueba del hardware 15 hs

4.2 Implementación y ejecución de pruebas unitarias del firmware 30 hs

4.3 Implementación y ejecución de pruebas unitarias del software 30 hs

4.4 Implementación y ejecución de pruebas de integración del sistema 15 hs

4.5 Documentación del proceso de verificación y validación 15 hs

Cantidad total de horas 610 hs

Página 12 de 31




7. Diagrama de Activity On Node

Las tareas se subdividen de la siguiente manera:

1. Gestión de proyectos

2. Diseño e implementación de firmware

3. Diseño e implementación de Aplicación de Visualización y Configuración

4. Verificación y validación

Figura 4. Diagrama de Activity On Node (AON).

Página 13 de 31




8. Diagrama de Gantt

Figura 5. Tabla de Gantt.

Página 14 de 31




Figura 6. Diagrama de barras de Gantt.

Se observa que la fecha de finalización del proyecto coincide con la indicada en el Acta Constitutiva.

9. Matriz de uso de recursos de materiales La ejecución del proyecto requerirá de los siguientes recursos materiales:

1. PC 2. Módulo PlatC 3. Smartphone con sistema Android 4. Instrumental de laboratorio

La siguiente tabla muestra la matriz de recursos materiales, con la cantidad de horas que cada tarea demandará de cada uno de ellos. Algunas tareas no utilizan ciertas recursos materiales, mientras que otras utilizan más de uno.

Página 15 de 31




Código WBS

Nombre de la tarea

Recursos requeridos (horas)

PC PlatC Smartphone

Instrumental

1.1 Planificación y presentación del Trabajo Final 15hs

1.2 Confección del Manual de Usuario 10hs

1.3 Confección del Informe de Avance 10hs

1.4 Confección de la Memoria del Trabajo 60hs

1.5 Preparación de la Presentación Final 20hs

2.1 Análisis e investigación del framework RKH 15hs 10hs

2.2 Análisis e investigación del stack BLE 10hs 10hs

2.3 Configuración del entorno/herramientas de

desarrollo

10hs 5hs

2.4 Definición e implementación de máquinas de

estados e interfaces

40hs 10hs

2.5 Definición e implementación del protocolo de

comunicación BLE

30hs 10hs

2.6 Implementación de drivers para adquisición de

datos de los sensores

50hs 10hs

2.7 Implementación de drivers para el manejo del

transceptor BLE

30hs 10hs

2.8 Documentación del firmware 15hs

3.1 Análisis e investigación del SDK Android 10hs 5hs

3.2 Análisis e investigación de las APIs TextToSpeech 15hs 10hs

3.3 Configuración del entorno/herramientas de

desarrollo

15hs 5hs

3.4 Implementación de funcionalidades e interfaces 50hs 10hs

3.5 Documentación del software 15hs

Página 16 de 31




4.1 Implementación y ejecución de rutinas de

prueba del hardware

5hs 5hs 5hs

4.2 Implementación y ejecución de pruebas

unitarias del firmware

20hs 5hs 5hs

4.3 Implementación y ejecución de pruebas

unitarias del software

20hs 10hs

4.4 Implementación y ejecución de pruebas de

integración del sistema

5hs 5hs 5hs

4.5 Documentación del proceso de verificación y

validación

15hs

10. Presupuesto detallado del proyecto

Categoría Descripción Cantidad Costo unitario

Subtotal

Costos Directos

Desarrollo 610 hs $ 350 / hs $ 213.500

Módulo Bluetooth BGM113 3 $ 442 $ 1326

Acelerómetro MPU 9250 3 $ 300 $ 900

Buzzer PB-1221P 3 $ 90 $ 270

MCU ATSAMD21E17A-AUT 3 $100 $ 300

IC cargador de batería MCP73832T 3 $ 25 $ 75

LED RGB 3 $ 33 $ 99

Pulsador 3 $ 10 $ 30

Conector de expansión 3 $ 45 $ 135

Fabricación y montaje PCB 3 $ 2250 $ 6750

Subtotal $ 223.385

Costos Indirectos Aproximadamente 30% de los costos directos

- - $ 67.015

Total costos del proyecto $ 290.400

Página 17 de 31




11. Matriz de asignación de responsabilidades

Código WBS Nombre de la tarea

Listar todos los nombres y apellidos y el rol definidos en el proyecto

Rodrigo Tirapegui Responsable

Diego Brengi

Impulsor

Francisco Gargiulo

Colaborador Cliente

1.1 Planificación y presentación del

Trabajo Final

P I - I

1.2 Confección del Manual de Usuario P A - I

1.3 Confección del Informe de Avance P A - I

1.4 Confección de la Memoria del Trabajo P A - -

1.5 Preparación de la Presentación Final P A - -

2.1 Análisis e investigación del framework

RKH

P - C -

2.2 Análisis e investigación del stack BLE P - C -

2.3 Configuración del

entorno/herramientas de desarrollo

P - C -

2.4 Definición e implementación de

máquinas de estados e interfaces

P I - -

2.5 Definición e implementación del

protocolo de comunicación BLE

P I - -

2.6 Implementación de drivers para

adquisición de datos de los sensores

P I - -

2.7 Implementación de drivers para el

manejo del transceptor BLE

P I - -

2.8 Documentación del firmware P I - -

3.1 Análisis e investigación del SDK

Android

P - C -

3.2 Análisis e investigación de las APIs

TextToSpeech

P - C -

Página 18 de 31




3.3 Configuración del

entorno/herramientas de desarrollo

P - C -

3.4 Implementación de funcionalidades e

interfaces

P I - -

3.5 Documentación del software P I - -

4.1 Implementación y ejecución de rutinas

de prueba del hardware

P A C I

4.2 Implementación y ejecución de

pruebas unitarias del firmware

P A C I


pruebas unitarias del software

P A C I


pruebas de integración del sistema

P A - I

4.5 Documentación del proceso de

verificación y validación

P A - I

Referencias: P = Responsabilidad Primaria

S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado

Página 19 de 31




12. Gestión de riesgos Se identifican a continuación los riesgos asociados a la realización del proyecto y se estiman sus

consecuencias de la siguiente manera:

● Severidad (S): mientras más severo más alto es el número. Rango: 1 a 10.

● Probabilidad de ocurrencia (O): mientras más probable, más alto es el número. Rango: 1 a 10.

Riesgo 1 Cancelación del proyecto por parte de INTI.

Severidad 10 Porque produce la no aprobación de la Maestría en Sistemas Embebidos.

Prob. de Ocurrencia 3 El coordinador del área de desarrollos electrónicos de INTI es el impulsor y director del proyecto.

Riesgo 2 Falta de capacidad en el ATSAMD21 (número de GPIOs, memoria RAM, memoria FLASH, etc.) para implementar las funcionalidades del módulo PlatC.

Severidad 9 Porque haría inviable el proyecto o bien implicaría reducir sus funcionalidades.

Prob. de Ocurrencia 3 Porque una investigación previa permitió determinar que la cantidad periféricos del ATSAMD21 es suficiente para la implementación del proyecto.

Riesgo 3 Defectos de fabricación en el hardware del módulo PlatC.

Severidad 6 Porque en caso de suceder realizar una nueva fabricación se traduce en pérdidas de tiempo.

Prob. de Ocurrencia 5 Porque es común que suceda toparse con algún error de ruteo o de mal dimensionamiento de los componentes.

Riesgo 4 No cumplir con la fecha de entrega pactada en el Acta de Constitución del Proyecto.

Severidad 10 Porque produce la no aprobación de la Maestría en Sistemas Embebidos.

Prob. de Ocurrencia 6 Porque el responsable del proyecto no cuenta con mucha experiencia previa en la planificación de proyectos.

Página 20 de 31




Riesgo 5 No cumplir con los requerimientos funcionales planteados

Severidad 9 Porque implica entregar un producto que no cumple con los requerimientos funcionales planteados.

Prob. de Ocurrencia 6 Porque el responsable del proyecto no cuenta con mucha experiencia previa en la ejecución de proyectos.

Se muestra a continuación la tabla de gestión de riesgos: el RPN se calcula como RPN = SxO.

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 10 3 30 - - -

2 9 3 27 - - -

3 6 5 30 - - -

4 10 6 60 10 3 30

5 9 6 54 9 4 36

Criterio adoptado: Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 40 según el criterio definido por el responsable del proyecto. Nota: - Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación. El plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido es el siguiente:

Riesgo 4 No cumplir con la fecha de entrega pactada en el Acta de Constitución del Proyecto.

Plan de mitigación Rigurosidad en el seguimiento del plan de trabajo y asignación de horas extras a tareas retrasadas.

Severidad 10 Porque aún produce la no aprobación de la Maestría en Sistemas Embebidos.

Prob. de Ocurrencia 3 Porque al ser riguroso en el seguimiento del plan de trabajo y asignar horas extras a las tareas retrasadas, el proyecto debería ser finalizado en tiempo y forma.

Página 21 de 31




Riesgo 5 No cumplir con los requerimientos funcionales planteados.

Plan de mitigación Analizar en profundidad junto con el orientador del proyecto cada uno de los requerimientos funcionales y simplificarlos en caso de ser ambiguos o requerir un tiempo de desarrollo superior al planificado.

Severidad 9 Porque implica entregar un producto que no cumple con los requerimientos funcionales planteados.

Prob. de Ocurrencia 4 Porque los requerimientos funcionales establecidos se pueden realizar en el tiempo planificado del proyecto.

13. Gestión de la calidad Se enumeran a continuación los requerimientos del proyectos, clasificándolos según sean funcionales o no funcionales; y se indica para cada uno de ellos la verificación y validación que será llevada a cabo por parte del responsable del proyecto.

Requerimientos Funcionales:

1. Módulo PlatC

1.1 Detectará movimientos con aceleración superiores a MOTION_THR. ● Verificación: Leer hoja de datos del acelerómetro MPU 9250 para verificar que tiene una

sensibilidad superior a MOTION_THR. ● Validación: Realizar movimientos con aceleración superiores a MOTION_THR y evidenciar

que el MPU 9250 los detecta, comparándolo con un acelerómetro patrón (presente en el smartphone, por ejemplo).

1.2 Cuando se detecte una aceleración superior a MOTION_THR, transmitirá inmediatamente un paquete PlatCData hacia PlatCApk.

● Verificación: Leer hoja de datos del acelerómetro MPU 9250 para verificar que tiene una sensibilidad superior a MOTION_THR.

● Validación: Conectar PlatC con el smartphone y realizar movimientos con aceleración superiores a MOTION_THR. Evidenciar que en la aplicación se reciben los valores de aceleración sensados.

1.3 Cuando se detecte una aceleración superior a MOTION_THR, encenderá y mantendrá el indicador MOTION_LED durante MOTION_DET_TIME.

● Verificación: Leer hoja de datos del acelerómetro MPU 9250 para verificar que tiene una sensibilidad superior a MOTION_THR.

● Validación: Realizar movimientos con aceleración superiores a MOTION_THR y evidenciar que el firmware del SAMD21 enciende MOTION_LED durante MOTION_DET_TIME.

1.4 Se vinculará con PlatCApk mediante un enlace BLE.

Página 22 de 31




● Verificación: Leer hoja de datos del módulo BLE BGM113 y verificar que sea compatible con el del smartphone (ambos deben ser compatibles con la norma Bluetooth 4.0).

● Validación: Iniciar el proceso de vinculación del dispositivo vestible desde la aplicación y evidenciar que efectivamente el enlace queda establecido.

1.5 Cuando se encuentre vinculado con PlatCApk, encenderá el indicador BLE_LED. ● Verificación: Leer hoja de datos del módulo BLE BGM113 y verificar que sea compatible

con el del smartphone (ambos deben ser compatibles con la norma Bluetooth 4.0). Verificar que la máquina de estados implementada en el SAMD21 enciende el BLE_LED cuando se produce el evento de conexión del BGM113.

● Validación: Iniciar el proceso de vinculación del dispositivo vestible desde la aplicación y evidenciar que efectivamente el enlace queda establecido y el BLE_LED se enciende.

1.6 Cuando se encuentre en proceso de carga de baterías, encenderá el indicador BATTERY_LED.

● Verificación: Leer hoja de datos del circuito de carga MCP73832T y verificar que sus pines estén ruteados a un GPIO del MCU SAMD21.

Verificar que la máquina de estados implementada en el SAMD21 enciende el BATTERY_LED cuando se produce el evento de inicio de carga de batería.

● Validación: Conectar el prototipo PlatC a un cargador y evidenciar que se enciende BATTERY_LED.

1.7 Cuando no exista vínculo entre PlatCApk y no se esté en curso una indicación de detección de movimiento mediante MOTION_LED, el sistema encenderá en secuencia los indicadores MOTION_LED, BLE_LED, y BATTERY_LED cada KEEPALIVE_TIME.

● Verificación: Leer hoja de datos del módulo BGM113 y verificar de qué manera indica su estado de conexión Bluetooth.

Verificar que la máquina de estados implementada en el SAMD21 enciende en secuencia los indicadores MOTION_LED, BLE_LED, y BATTERY_LED cada KEEPALIVE_TIME cuando el BGM113 está desconectado y el MPU 9250 no detecta movimiento.

● Validación: Desconectar PlatC de la aplicación que corre en el smartphone y evidenciar que se encienden en secuencia los indicadores MOTION_LED, BLE_LED, y BATTERY_LED cada KEEPALIVE_TIME.

1.8 Recibirá el paquete PlatCApkSettings con configuraciones desde el PlatCApk. ● Verificación: Leer la especificación del estandar Bluetooth 4.0 y determinar si el largo

máximo del paquete PlatCApkSettings es soportado para ser transmitido sin fragmentación.

● Validación: Conectar PlatC con la aplicación del smartphone, y evidenciar que el mensaje PlatCApkSettings es recibido mientras se debuguea el código.

1.9 Ajustará el umbral MOTION_THR de acuerdo al paquete de configuración PlatCApkSettings enviado por PlatCApk.

● Verificación: Leer la especificación del estandar Bluetooth 4.0 y determinar si el largo máximo del paquete PlatCApkSettings es soportado para ser transmitido sin fragmentación.

● Validación: Conectar PlatC con la aplicación del smartphone, y evidenciar que el mensaje PlatCApkSettings es recibido mientras se debuguea el código, y que el umbral MOTION_THR es modificado en memoria.

1.10 Cuando inicie será descubrible por PlatCApk.

Página 23 de 31




● Verificación: Leer la hoja de datos del BGM113 y analizar la manera en que el dispositivo se configura en modo Advertise (descubrible).

Verificar que la máquina de estados implementada en el SAMD21 configura al BGM113 en modo Advertise cuando el programa inicia.

● Validación: Encender PlatC y mediante el uso de un sniffer Bluetooth 4.0 capturar los paquetes que envía el BGM113 en modo Advertise.

1.11 Cuando permanezca sin establecer vínculo con PlatCApk durante más de DISCONNECTED_TIMEOUT dejará de ser descubrible.

● Verificación: Leer la hoja de datos del BGM113 y analizar la manera en que el dispositivo se saca de modo Advertise (descubrible).

Verificar que la máquina de estados implementada en el SAMD21 saca al BGM113 del modo Advertise cuando transcurrió DISCONNECTED_TIMEOUT .

● Validación: Encender PlatC y mediante el uso de un sniffer Bluetooth 4.0 capturar los paquetes que envía el BGM113 en modo Advertise. Evidenciar que transcurrido DISCONNECTED_TIMEOUT los paquetes dejan de ser transmitidos por el BGM113.

1.12 Cuando esté vinculado a PlatCApk y se presione PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME se desvinculará y permanecerá descubrible.

● Verificación: Verificar que la máquina de estados implementada en el SAMD21 configura al BGM113 del modo Advertise cuando transcurrió se presiona PUSH_BUTTON durante SHORT2LONG_BUTT_TIME.

● Validación: Encender PlatC y vincularlo a la aplicación del smartphone. Luego, pulsar PUSH_BUTTON durante SHORT2LONG_BUTT_TIME y mediante el uso de un sniffer Bluetooth 4.0 capturar los paquetes que envía el BGM113 en modo Advertise.

1.13 Cuando esté vinculado a PlatCApk y se presione PUSH_BUTTON durante menos de SHORT2LONG_BUTT_TIME transmitirá un paquete PlatCData a PlatCApk.

● Verificación: Verificar que la máquina de estados implementada en el SAMD21 envía un paquete PlatCData cuando se presiona PUSH_BUTTON durante menos de durante SHORT2LONG_BUTT_TIME .

● Validación: Encender PlatC y vincularlo a la aplicación del smartphone. Luego, pulsar PUSH_BUTTON durante menos de SHORT2LONG_BUTT_TIME y evidenciar que el paquete PlatCData se recibe en la aplicación.

1.14 Cuando no sea descubrible y se presione PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME será descubrible inmediatamente.

● Verificación: Verificar que la máquina de estados implementada en el SAMD21 configura al BGM113 en modo Advertise cuando se presiona PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME.

● Validación: Encender PlatC mediante el uso de un sniffer Bluetooth esperar hasta que no se observen más paquetes de Advertise. Luego, presionar PUSH_BUTTON durante más de SHORT2LONG_BUTT_TIME y evidenciar que el sniffer vuelve a capturar los paquetes de Advertise.

Página 24 de 31




2. Módulo de visualización

2.1 Deberá ser una aplicación para sistema operativo Android.

● Verificación: Verificar que el entorno de trabajo (Xamarin) permite desarrollar aplicaciones para el sistema operativo Android.

● Validación: Instalar la aplicación desarrollada en un smartphone Android y evidenciar que funciona correctamente.

2.1 Deberá mostrar los parámetros de configuración y datos adquiridos por el módulo PlatC.

● Verificación: Verificar que la aplicación desarrollada contiene una pantalla de configuración para los parámetros de funcionamiento de PlatC, y otra para observar los datos reportados.

● Validación: Instalar la aplicación desarrollada en un smartphone, modificar los parámetros de configuración de PlatC e impactarlos. Luego, evidenciar que se reciben mediones basadas en los nuevos umbrales de operación.

2.3 Deberá describir de forma hablada los datos adquiridos por el módulo PlatC.

● Verificación: Verificar que el entorno de trabajo (Xamarin) soporta la librería TextToSpeech.

● Validación: Vincular PlatC con el smartphone y evidenciar que la aplicación “lee” los datos recibidos.

2.2 Deberá permitir la modificación de los parámetros de configuración del módulo PlatC.

● Verificación: Leer la especificación del estándar Bluetooth 4.0 y determinar si el largo máximo del paquete PlatCApkSettings es soportado para ser transmitido sin fragmentación por la aplicación.

● Validación: Conectar PlatC con la aplicación del smartphone, y evidenciar que el mensaje PlatCApkSettings es recibido mientras se debuguea el código.

Requerimientos No Funcionales:

1. Módulo PlatC

1.1 Las configuraciones de PlatCSettings serán almacenadas en memoria no volátil.

● Verificación: Leer la hoja de datos del SAMD21 y verificar que cuenta con una zona de memoria no volátil (NVM) donde se puedan almacenar los umbrales de operación.

Buscar en Atmel Software Framework (ASF) el driver para almacenar dichos datos en la NVM.

Verificar que la máquina de estados implementada almacena los umbrales de operación en la NVM cuando se recibe un paquete PlatCSettings.

● Validación: Conectar PlatC con la aplicación del smartphone, enviar un paquete PlatCSettings y evidenciar que su contenido es almacenado en la NVM conforme se debuguea el código.

1.2 Filtrará el rebote del pulsador PUSH_BUTTON.

Página 25 de 31




● Verificación: Analizar el esquemático de PlatC y verificar que PUSH_BUTTON está conectado a un GPIO del SAMD21.

● Validación: Pulsar PUSH_BUTTON y evidenciar que la lógica anti rebote entra en acción conforme se debugue el firmware del SADM21.

1.3 MOTION_DET_TIME será configurable en tiempo de compilación.

● Verificación: Verificar que el código programado en el SAMD21 acepta como un literal de tiempo de compilación la constante MOTION_DET_TIME.

● Validación: Modificar MOTION_DET_TIME y recompilar el firmware. Debugger la nueva versión y evidenciar que el valor asignado a MOTION_DET_TIME es diferente del previo.

1.4 Mantendrá el tiempo de operación en memoria no persistente.

● Verificación: Verificar que el código programado en el SAMD21 utiliza el valor devuelto por el RTC mediante una variable no volátil de RAM.

● Validación: Vincular PlatC con el smartphone y leer el tiempo de operación reportado. Luego, reiniciar PlatC y evidenciar que el tiempo de operación volvió a cero.

1.5 El firmware del módulo debe diseñarse minimizando el consumo.

● Verificación: Leer la hoja de datos del BGM113 y SAMD21 y verificar que cuentan con modos de operación de bajo consumo.

● Validación: Realizar mediciones de consumo que permitan validar que el mismo no supere cierto umbral a definir.

1.6 Debe cumplir con la recomendación IEC 801 de “Compatibilidad electromagnética para medición de procesos industriales y equipos de control (por extensión)”.

● Verificación: Leer la hoja de datos del BGM113 y verificar que su potencia de transmisión de adecua a la especificada en la recomendación IEC 801.

● Validación: Realizar un ensayo de compatibilidad electromagnética en una institución adecuada para tal fin (por ejemplo, INTI).

14. Comunicación del proyecto El plan de comunicación del proyecto es el siguiente:

PLAN DE COMUNICACIÓN DEL PROYECTO

¿Qué comunicar?

Audiencia Propósito Frecuencia Método de comunicac.

Responsable

Plan de Proyecto Director de MSE, director del proyecto

y cliente

Evaluar los requerimientos e

indicar la motivación y la planificación del

proyecto

Una vez (al inicio del proyecto)

Documentación compartida en

formato electrónico

Esp. Ing. Rodrigo

Alejandro Tirapegui

Página 26 de 31




Diseño del firmware

Director y colaborador del proyecto

Confirmar que cumple con los requerimientos

funcionales planteados

Semanalmente

Correo electrónico

Esp. Ing. Rodrigo

Alejandro Tirapegui

Implementación del firmware

Director del proyecto

Confirmar la correcta

implementación del mismo

Semanalmente

Correo electrónico

Esp. Ing. Rodrigo

Alejandro Tirapegui

Diseño de software

Director y colaborador del proyecto

Confirmar que cumple con los requerimientos

funcionales planteados

Semanalmente

Correo electrónico

Esp. Ing. Rodrigo

Alejandro Tirapegui

Implementación de software



implementación del mismo

Semanalmente

Correo electrónico

Esp. Ing. Rodrigo

Alejandro Tirapegui

Gestión del proyecto

Director de MSE


redacción de los diferentes

documentos que componen el

proyecto

En cada entrega

Documentación compartida en

formato electrónico

Esp. Ing. Rodrigo

Alejandro Tirapegui

15. Gestión de Compras El presente proyecto no requiere la compra de componentes electrónicos dado que actualmente, INTI

cuenta con 3 (tres) prototipos fabricados del módulo PlatC. En relación con el instrumental necesario para

llevar a cabo el proyecto, INTI ofrece sus laboratorios e instrumental para cubrir la tarea, contando con

osciloscopios, equipo de soldadura e inspección, analizadores lógicos, etc.

Página 27 de 31




16. Seguimiento y control

SEGUIMIENTO DE AVANCE

Tarea del WBS

Indicador de avance

Frecuencia de reporte

Responsable de seguimiento

Persona a ser informada

Método de comunicac.

1.1 Items completados del plan de trabajo

Semanal durante la etapa de

desarrollo de la tarea

Esp Ing. Rodrigo Alejandro Tirapegui

Director MSE, director del proyecto y

cliente

Correo electrónico

1.2 Porcentaje del manual de

usuario completado





cliente

Correo electrónico

1.3 Items del informe de

avance completados



Esp .Ing. Rodrigo Alejandro Tirapegui


cliente

Correo electrónico

1.4 Items de la memoria de

trabajo completados




Director MSE y director del

proyecto

Correo electrónico

1.5 Diapositivas incluidas y video

Diario durante la etapa de



Director MSE y director del

proyecto

Correo electrónico

2.1 Documentación y ejemplos de

uso del framework RKH




Colaborador del proyecto

Correo electrónico

2.2 Documentación y ejemplos de uso del stack

BLE





Correo electrónico

2.3 Proyecto funcional en el

entorno de trabajo

Una vez al configurar el entorno de

trabajo



Link a repositorio de

GitHub

Página 28 de 31




2.4 Archivos fuente de cada

máquina de estados

implementada

Semanalmente durante la etapa

de desarrollo de la tarea




GitHub

2.5 Documento explicativo del

protocolo y archivos fuente

con la lógica implementada





Correo electrónico y link a repositorio de

GitHub

2.6 Documento explicativo y

archivos fuente con la lógica

implementada



Esp Ing. Rodrigo Alejandro Tirapegui



GitHub



implementada






GitHub

2.8 Porcentaje de la documentación

redactada





Correo electrónico

3.1 Documentación y ejemplos de uso del SDK

Android





Correo electrónico

3.2 Documentación y ejemplos de

uso de la librería TextToSpeech





Correo electrónico

3.3 Proyecto funcional en el

entorno de trabajo

Una vez al configurar el entorno de

trabajo




GitHub

Página 29 de 31






implementada






GitHub


redactada





Correo electrónico

4.1 Listado de los periféricos de

hardware probados




Director del proyecto,

colaborador del proyecto

y cliente

Correo electrónico

4.2 Listado de las pruebas

unitarias de firmware probadas






y cliente

Correo electrónico

4.3 Listado de las pruebas

unitarias de software probadas






y cliente

Correo electrónico

4.4 Listado de las pruebas de

sistema realizadas




Director del proyecto y

cliente

Correo electrónico


redactada




Director del proyecto y

cliente

Correo electrónico

Página 30 de 31




17. Procesos de cierre Al finalizar el proyecto se realizará una evaluación final que contemple las siguientes actividades:

● El responsable del proyecto analizará si se respetó el plan de proyecto original, comparando dicho cronograma contra el real e identificando las tareas que mayor divergencia de tiempo presentaron y sus causas.

● El responsable del proyecto realizará una lista de las técnicas y procedimientos que le resultaron útiles para cumplir con los objetivos preestablecidos, y las que le hayan generado retrasos, indicando las posibles causas.

● El responsable del proyecto se encargará de agradecer a todas las personas involucradas en el proyecto, miembros del jurado, docentes y autoridades de MSE.

Página 31 de 31

plataforma abierta para dispositivos vestibles...

Documents