View
2
Download
0
Category
Preview:
Citation preview
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?
Recommended