Dispositivo embebido de

comunicación en tiempo real

por mensajes de voz

Autor: Ing. Marcelo Daniel Pistarelli

Director: Esp. Ing. Alejandro Celery

Introducción

Introducción Microcontrolador: ST STM32F412RG 1MB Flash 256KB RAM

Chip WiFi: Broadcom BCM43362

Memoria Flash SPI 2MB

Micrófono digital MEMS

Interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante - - -

Cliente Jurado CESE - -

Impulsor - - -

Responsable Ing. Marcelo D. Pistarelli DSI - FCEIA -UNR JTP

Colaboradores Voluntarios de pruebas de prototipos

- -

Orientadores Esp. Ing. Alejandro Celery

FIUBA Profesor

Equipo - - -

Opositores - - -

Usuario Final Niños de 2 a 6 años, adultos mayores y personas con algún grado de discapacidad.

- -

Propósito

Permitir la comunicación mediante mensajes de voz a personas que

tienen dificultad en manipular teléfonos inteligentes y sus aplicaciones

de mensajería.

Diseñar e implementar un dispositivo conectado a Internet que permita

la comunicación entre personas con la habilidad motriz de presionar un

botón mediante el intercambio de mensajes de voz entregados al

destinatario en tiempo real.

Aplicar y profundizar conocimientos adquiridos durante la Carrera de

Especialización.

Alcance

Diseño e implementación de tres dispositivos a nivel de hardware y

firmware.

Desarrollo del software que correrá en un servidor Linux en Internet

que permitirá el envío de mensajes de voz en tiempo real entre

dispositivos.

No incluye el desarrollo de una aplicación para teléfono inteligente

que permita el intercambio de mensajes de voz en tiempo real con los

dispositivos embebidos.

No incluye el desarrollo de aplicaciones servidor que permitan

implementar un arquitectura multi-servidor.

Requerimientos

Requerimientos funcionales del dispositivo embebido

Debe ser operable por niños de 2 a 6 años, personas mayores de 80 años y con limitaciones motrices en las manos.

Debe permitir seleccionar fácilmente el destinatario del mensaje de voz a enviar.

La grabación del mensaje de voz debe ser determinada por el período de accionamiento del pulsador de grabación.

Debe indicar mediante una alerta audible la recepción de un nuevo mensaje.

Requerimientos de conectividad del dispositivo embebido

El dispositivo embebido debe poder conectarse a una red inalámbrica Wi-Fi de 2.4Ghz.

Debe mantener una conexión TCP persistente vía Internet con el Servidor de envío de mensajes.

Requerimientos

Requerimientos de hardware del dispositivo embebido

El costo unitario de los materiales para 1000 unidades del dispositivo debe

ser inferior a 20 dólares. Sin incluir batería, parlante, botones, leds ni

carcasa.

Debe operar a batería recargable de Li-Ion.

Debe tener al menos 4 entradas salidas digitales para conexión de

pulsadores y leds indicadores de estado.

Debe tener pines de conexión al programador del microcontrolador para

facilitar la programación durante el proceso de fabricación.

Debe tener un microcontrolador de arquitectura Cortex M4 y amplia

documentación provista por el fabricante.

Debe tener un controlador de Wi-Fi con throughput TCP sin encriptación

mayor a 5Mbit/s y amplia documentación provista por el fabricante.

Debe contener una antena integrada certificada por la FCC (Comisión

Federal de Comunicaciones de los Estados Unidos).

Requerimientos

Requerimientos de hardware del dispositivo embebido

Debe tener una memoria serie no volátil conectada al microcontrolador

por bus SPI.

Debe tener un micrófono digital para la grabación de audio sin ruido

eléctrico.

Debe tener un amplificador de audio analógico o digital Clase D de

eficiencia superior al 80%

Requerimientos de firmware de dispositivo embebido

Debe utilizar un sistema operativo en tiempo real.

Debe disponer de un diseño en diferentes capas de abstracción.

Debe implementar un protocolo de comunicación de capa de aplicación

para la comunicación con el servidor de envío de mensajes en Internet.

Requerimientos

Requerimientos funcionales del servidor de envío de mensajes

Debe permitir el envío de mensajes de voz a los destinatarios en tiempo real.

Debe almacenar en una base de datos los contactos asociados a cada dispositivo

embebido.

Debe permitir la autenticación de los dispositivos embebidos.

Debe validar los destinatarios de los mensajes enviados por los dispositivos

embebidos.

Debe almacenar logs de funcionamiento del sistema en una base de datos.

Requerimientos de software del servidor de envío de mensajes

Debe correr sobre sistema operativo Linux y Windows.

Debe utilizar un framework desarrollado para el manejo asíncrono de

conexiones TCP de alta performance.

Diagrama AON

Gestión de riesgos Riesgo 1: No disponer de tiempo suficiente para llevar a cabo el proyecto.

Severidad (9): Implica que el proyecto no es terminado antes de la fecha de entrega.

Probabilidad de ocurrencia (6): El responsable del proyecto tiene una jornada laboral de 8 horas

sin contar las horas de cursado de la CESE.

Riesgo 2: La planificación del proyecto no es adecuada.

Severidad (8): Implica que el proyecto no es terminado antes de la fecha de entrega.

Probabilidad de ocurrencia (3): El responsable del proyecto tiene experiencia en la realización

de un proyecto similar y tiene dominio de los lenguajes de programación implicados.

Riesgo 3: Demoras en la adquisición de los componentes electrónicos.

Severidad (8): Implica que los tiempos planificados serán modificados, afectando al esquema de

ejecución de tareas. Puede implicar mayores costos al ser necesaria la contratación de

proveedores adicionales.

Probabilidad de ocurrencia (3): Se tendrá en cuenta al momento de la elección de los

proveedores la disponibilidad de stock, variedad y medio de envío de los componentes

electrónicos.

Gestión de riesgos Riesgo 4: Fallas en el servidor Linux VPS contratado.

Severidad (7): Implica que los tiempos planificados serán modificados, afectando al

esquema de ejecución de tareas.

Probabilidad de ocurrencia (1): El responsable del proyecto tiene experiencia en la

contratación y configuración de servidores Linux VPS.

Riesgo 5: Pérdida total o parcial del código desarrollado.

Severidad (9): Implicaría importantes retrasos en el desarrollo del trabajo

dificultando el cumplimiento con la fecha de entrega.

Probabilidad de ocurrencia (1) : Se utilizará durante toda la fase de desarrollo un

sistema de control de versiones y backup en la nube.

Gestión de riesgos

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 9 6 54 9 2 18

2 8 3 24 8 2 16

3 8 3 24 8 2 16

4 7 1 7

- - -

5 9 1 9

- --

Gestión de riesgos - Mitigación Riesgo 1 : Se coordinará con el Departamento de Sistemas de la Facultad de Ciencias

Exactas Ingeniería y Agrimensura de la UNR la reasignación de tareas con el fin de

disponer de mayor tiempo.

Severidad (9): Sin modificación.

Ocurrencia (2): Se dispone de más tiempo para dedicar al proyecto.

Riesgo 2: La planificación del proyecto será abordada dividiendo las tareas en tareas de

menor duración para aumentar la precisión.

Severidad (8): Sin modificación.

Ocurrencia (2): Se reduce la posibilidad de mala planificación temporal.

Riesgo 3: Se tendrá en cuenta al momento de la elección de los componentes

electrónicos el nivel de popularidad en cuanto a la variedad de aplicaciones de los

mismos, aumentando las posibilidades de contar con disponibilidad de stock en los

proveedores.

Severidad (8): Sin modificación.

Ocurrencia (2): Se reduce la posibilidad de retrasos por falta de stock al considerar

componentes electrónicos de uso estándar.

Gestión de la calidad

Verificación: Se realizará el diseño e implementación contrastando las

especificaciones de los elementos constitutivos con los requerimientos

establecidos.

Validación: Se realizarán pruebas de usabilidad con un grupo de

voluntarios integrado por niños de 2 a 6 años, personas mayores de 80

años y con limitaciones motrices en las manos.

¿Preguntas?