Sistema para conversión de semáforos convencionales...
Transcript of Sistema para conversión de semáforos convencionales...
Sistema para conversión de semáforos convencionales en
semáforos para no videntesPlan de Trabajo Final de la Carrera de Especialización en Sistemas Embebidos
Autor: Ing. Sebastián Alejandro Suárez
Director: Esp. Ing. Sergio R. De Jesus Melean
Motivacion Soniforo
Segun el INDECEn Argentina 1 de cada 10 personas
poseen algún tipo de discapacidad (1).
Software y hardware abierto
(1) https://www.indec.gov.ar/ftp/cuadros/poblacion/estudio_discapacidad_07_18.pdf
Esquema general
ENTRADAPROTOTIPO
SALIDAS
Interesados
Javier Viqueira
Auspiciante/ClienteAdox S.A.
Titular de la empresa
Sebastian Alejandro Suarez
Responsable/EquipoEsp. en Sistemas Embebidos
FIUBA
Estudiante
Esp. Ing. Sergio R. De Jesus Melean
OrientadorEsp. en Sistemas Embebidos
FIUBA
Director
Personas con discapacidades
visualesUsuario final
El proposito
“ Diseñar y construir un prototipo que se adapte a
cualquier semáforo convencional, y sirva para advertir a
las personas con discapacidad visual, el cambio de las luces
del semáforo a través de su teléfono inteligente y/o el
sonido de un buzzer ”
Alcance
Prototipo funcional
Aplicación android
Protocolo para escalabilidad
con dispositivos de advertencia
Ajuste de nivel de sonido
automático
Comando a distancia
Requerimientos HARDWARE - Cargas de entradas de 220V, 50 Hz. - Aislamiento
COMUNICACIÓN - Debe proveer un red Wifi. - Proveer una señal sonora. - Boton de Activacion. - Mando a distancia.
SOFTWARE - Aprender la secuencia de cambio de luces. - Detectar el semáforo fuera de servicio. - Protocolo para escalabilidad. - SO de tiempo real.
METODOLOGÍA DE DESARROLLO- GIT.- Doxygen.
APLICACIÓN MÓVIL - Conectarse una red predeterminada. - Protocolo de vibracion.
AON
INVESTIGACIÓN PRELIMINAR
DESARROLLOHARDWARE
DESARROLLOAPP. ANDROID
DESARROLLOFIRMWARE
ENSAYOS DESARROLLOGABINETE
PRESENTACIONDEL PROYECTO
71 h 98 h / 58 h 170 h 96 h 36 h 93 h
Diagrama de Gantt
Gestión de Riesgos
RIESGO 1 Perdida Hardware, software y/o documentación).
RIESGO 2 No cumplir con el objetivo de advertir.
RIESGO 3 Modificación o aumento de requerimiento(s)
RIESGO 4 Problemas en desarrollo de la aplicación Android.
RIESGO 5 Pérdida de prioridad del proyecto.
RIESGO 6 Error de diseño del PCB .
RIESGO 7 Falla de algún componente .
Gestión de Calidad
VALIDACIONSe realizará excitando
a las diferentes entradas y observado
la salida.
VERIFICACIONRealizar pruebas de
depuración alas diferentes funciones
del sistema.
¿Preguntas?
?
¡Muchas Gracias!