Sistema para conversión de semáforos convencionales en...

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Sebastián Alejandro Suárez

Sistema para conversión de

semáforos convencionales en semáforos para no videntes

Autor Ing. Sebastián Alejandro Suárez Director del trabajo Esp. Ing. Sergio R. De Jesus Melean Jurado propuesto para el trabajo

- Ing. Franco Bucafusco - Ing. Diego Fernandez - Ing. Marcelo Romeo

Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de Proyectos entre octubre y noviembre de 2018.

Página 1 de 27




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 6

1. Propósito del proyecto 7

2. Alcance del proyecto 7

3. Supuestos del proyecto 7

4. Requerimientos 7

5. Entregables principales del proyecto 8

6. Desglose del trabajo en tareas 9

7. Diagrama de Activity On Node 11

8. Diagrama de Gantt 12

9. Matriz de uso de recursos de materiales 13

10. Presupuesto detallado del proyecto 14

11. Matriz de asignación de responsabilidades 15

12. Gestión de riesgos 17 b) Tabla de gestión de riesgos: 18 c) Plan de mitigación de los riesgos 18

13. Gestión de la calidad 19

14. Comunicación del proyecto 22

15. Gestión de Compras 23 Pedido de presupuesto 23

16. Seguimiento y control 24

17. Procesos de cierre 27

Página 2 de 27




Registros de cambios Revisión Detalle de los cambios realizados Fecha

1.0 Creación del documento. 29/10/2018

1.1 Correcciones propuestas por Dr. Ing. A. Lutenberg. 08/11/2018

1.2 Completado hasta el punto 12, excepto el 8. 15/11/2018

1.3 Puntos del 13 hasta el 17 agregados. 18/11/2018

1.4 Correcciones varias propuestas por Dr. Ing. A. Lutenberg. 19/11/2018

1.5 Correcciones propuestas por Dr. Ing. A. Lutenberg. 24/11/2018

Página 3 de 27




Acta de Constitución del Proyecto

Buenos Aires, 25 de octubre de 2019

Por medio de la presente se acuerda con el Ing. Sebastián Alejandro Suárez que su Trabajo Final

de la Carrera de Especialización en Sistemas Embebidos se titulará “Sistema para conversión de semáforos

convencionales en semáforos para no videntes”, consistirá esencialmente en el prototipo preliminar de un

sistema que permite adaptar un semáforo convencional a un semáforo para no videntes o personas con

visual disminuida, y tendrá un presupuesto preliminar estimado de 600 hs de trabajo, con fecha de inicio

lunes 17 de diciembre de 2018 y fecha de presentación pública lunes 29 de julio de 2019.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg Javier Viqueira

Director de la CESE-FIUBA Adox S.A.

Esp. Ing. Sergio R. De Jesus Melean

Director del Trabajo Final

Nombre y Apellido (1) Nombre y Apellido (2)

Jurado del Trabajo Final Jurado del Trabajo Final

Nombre y Apellido (3)

Jurado del Trabajo Final

Página 4 de 27




Descripción técnica-conceptual del Proyecto a realizar En Argentina 1 de cada 10 personas poseen algún tipo de discapacidad, siendo la que más prevalece la discapacidad motora, seguida por la visual, la auditiva y la mental . 1

Uno de los problemas más comunes a los que enfrentan las personas con discapacidad visual es el cálculo de distancias en un lugar dado, el cual es necesario para evitar accidentes. Es por esta razón que se acude al uso de elementos como el bastón. Uno de los principales desafío que encuentran las personas con discapacidad visual es cruzar la calle sto se debe a quegeneral no tienen ningún tipo de señal que les indique si la calle está libre de autos circulando o si se produjo el cambio de semáforo a verde. Para estas situaciones el bastón no es de utilidad, ya que no brinda ningún tipo de información al respecto para advertir si la persona puede o no cruzar la calle sin ningún peligro. Si bien en algunas oportunidades pueden valerse de la buena intención de algún transeúnte es importante para toda persona poder valerse por sí misma y no depender de un tercero.

En 1983, el inventor argentino Mario Davila patentó el primer semáforo para Ciegos, el problema de este aparato fue su elevado precio y el constante ruido que producía.

Este proyecto consiste en desarrollar un prototipo de un hardware abierto, autónomo y económico, que permitirá ser conectado a cualquier semáforo convencional, aprendiendo el comportamiento de este, tomando como entradas la secuencia de luces del semáforo y como salida pretende advertir a la persona con discapacidad visual cuando puede o no cruzar la calle sin peligro. Esta advertencia se va a realizar por medio de un pitido generado por un buzzer y/o de su teléfono inteligente. (ver Fig. 1)

Fig. 1

1Fuente: INDEC. Estudio Nacional sobre el Perfil de las Personas con Discapacidad. Resultados preliminares.

Página 5 de 27




Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento /

Organización Puesto

Auspiciante Javier Viqueira Adox S.A. Titular de la empresa

Cliente Jorge Fiszman Adox S.A. -

Responsable Ing. Sebastián Alejandro

Suárez

Especialización en Sistemas

Embebidos - FIUBA-

Estudiante

Orientador Esp. Ing. Sergio R. De

Jesus Melean

- Director

Usuario Final Personas con

discapacidades visuales.

- -

Página 6 de 27




1. Propósito del proyecto El propósito de este proyecto es 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. Otro propósito es finalizar la especialización en sistemas embebidos. Dicho prototipo se desarrollará de manera abierta, es decir, que su código y hardware están disponibles para todas las personas que lo deseen y que tengan la libertad de modificarlo.

2. Alcance del proyecto El desarrollo del presente proyecto incluye:

● Desarrollo de un prototipo funcional. ● Desarrollo de una aplicación en android. ● Desarrollo de un protocolo para lograr la escalabilidad en las formas de comunicación con

dispositivos de advertencia. ● Ajuste de nivel de sonido automáticamente según ruido ambiente. ● Posibilidad de activar el sistema por medio de un comando a distancia.

El presente proyecto no incluye: ● Compatibilidad con otro sistema operativos distintos de android.

3. Supuestos del proyecto Para el desarrollo del presente proyecto se supone que:

● Todos los módulos necesarios para el proyecto podrán adquirirse. ● Se supone que la CIAA es Industrial, ya que su diseño está preparado para las

exigencias de confiabilidad, temperatura, vibraciones, ruido electromagnético, tensiones, cortocircuitos, etc.

4. Requerimientos 1. Requerimientos de Hardware:

a. Operar con cargas de entradas de 220 V, 50 Hz y hasta 5A. b. El hardware involucrado en la detección del cambio de luces debe estar

totalmente aislado del módulo principal. 2. Requerimientos de comunicación:

a. El sistema debe proveer un red Wifi que cumpla con las normas IEEE 802.11. b. Se debe proveer una señal sonora, la cual de debe controlarse automáticamente

dependiendo del ruido presente. c. Se debe proveer una interface para activar el sistema por medio de un botón. d. Se debe proveer una interface para activar el sistema por medio de un control a

distancia, el cual debe operar en la frecuencia de 2.4GHz. 3. Requerimientos del software embebido:

Página 7 de 27




a. El sistema deberá ser capaz de aprender la secuencia de cambio de luces. b. El sistema deberá ser capaz de detectar el semáforo fuera de servicio. c. Se deberá implementar un protocolo para la fácil escalabilidad de los distintos

tipos de comunicación. d. El sistema deberá implementarse en base a un sistema operativo de tiempo real.

4. Requerimientos de la metodología de desarrollo: a. Se utilizará GIT como herramienta de control de versiones. b. Se utilizará Doxygen como herramienta para generar la documentación. c. Se realizarán tests unitarios para cada módulo.

5. Requerimientos de la aplicación móvil: a. Conectarse automáticamente a la red wifi que provee el sistema. b. Definir un protocolo de vibraciones según los mensajes del sistema

5. Entregables principales del proyecto ● Manual de uso ● Manual de instalación ● Diagrama esquemático ● Gerbers de PCB ● Código fuente ● Informe final ● Presentación ante el jurado

Página 8 de 27




6. Desglose del trabajo en tareas 1. Investigación preliminar (71 hs)

1.1. Investigación sobre productos similares en el mercado. (6 hs) 1.2. Investigación sobre la frecuencia del sonido que debería producir el buzzer,

acorde a las personas no videntes. (20 hs) 1.3. Investigación sobre circuitos para aislar el sistema. (10 hs) 1.4. Investigación sobre fuentes para alimentar el sistema. (15 hs) 1.5. Investigación del módulo de radio frecuencia. (4 hs) 1.6. Investigación del módulo WiFi. (4 hs) 1.7. Investigación de cómo generar sonidos mediante la CIAA u otras alternativas. (10

hs) 1.8. Reunión de arranque. (2 hs)

2. Desarrollo del hardware (90 hs) 2.1. Analisis tecnico/economico. (10 hs) 2.2. Elección de componentes. (10 h) 2.3. Reunión para determinación de hardware. (4 hs) 2.4. Selección de puertos. (6 hs) 2.5. Diseño fuente de alimentación. (20 hs) 2.6. Diseño PCB. (30 hs) 2.7. Fabricación PCB. (4 hs) 2.8. Verificación de la PCB. (6 hs)

3. Desarrollo de aplicación de android (58 hs) 3.1. Diseño de pantallas. (20 hs) 3.2. Programacion de aplicacion. (30 hs) 3.3. Testeo de aplicación. (8 hs)

4. Desarrollo de firmware (170 hs) 4.1. Familiarización con RTOS. (10 hs) 4.2. Selección de bibliotecas de código a utilizar. (10 hs) 4.3. Diseño de arquitectura. (20 hs) 4.4. Diseño de protocolo de mensajes para la comunicación con dispositivos de

advertencia. (20 hs) 4.5. Diseño de drivers genericos para dispositivos de advertencia. (15 hs) 4.6. Programación de protocolo de comunicación con dispositivos de advertencia. (20

hs) 4.7. Programación de drivers genericos. (20 hs) 4.8. Programación de arquitectura. (30 hs) 4.9. Programación aprendizaje de secuencias del semáforo. (20 hs)

4.10. Diseño de tareas del sistema operativo. (5 hs) 5. Ensayos (96 hs)

5.1. Familiarización con el framework de test unitarios. (8 hs) 5.2. Realización de test unitarios. (25 hs)

Página 9 de 27




5.3. Diseño de casos de prueba. (8 hs) 5.4. Testeo manuales. (10 hs) 5.5. Desarrollo de semáforo para testeo (45 hs)

6. Desarrollo del gabinete (36 hs) 6.1. Investigación sobre requerimientos estéticos y funcionales. (10 hs) 6.2. Diseño del gabinete. (20 hs) 6.3. Fabricación del gabinete. (6 hs)

7. Presentación del proyecto (93 hs) 7.1. Preparación del informe final (45 hs) 7.2. Escritura del manual de usuario. (20 hs) 7.3. Escritura informe de avance. (20 hs) 7.4. Preparación de diapositivas para exposicion. (8 hs)

Total: 614 hs

Página 10 de 27




7. Diagrama de Activity On Node

Página 11 de 27




8. Diagrama de Gantt

Página 12 de 27




9. Matriz de uso de recursos de materiales

Nombre de la tarea

Recursos requeridos (horas)

1 Investigación preliminar 1.1 Investigación sobre productos similares en el mercado 6h

1.2

Investigación sobre la frecuencia del sonido que debería producir el buzzer, acorde a las personas no videntes

20h

1.3 Investigación sobre circuitos para aislar el sistema 10h 1.4 Investigación sobre fuentes para alimentar el sistema 15h 1.5 Investigación del módulo de radio frecuencia 4h 1.6 Investigación del módulo WiFi 4h

1.7 Investigación de cómo generar sonidos por medio de laCIAA u otras alternativas

5h 5h

1.8 Reunión de arranque 2h 2 Desarrollo del hardware

2.1 Analisis tecnico/economico 10h 2.2 Elección de componentes 10h 2.3 Reunión para determinación de hardware 4h 2.4 Selección de puertos 4h 2h 2.5 Diseño fuente de alimentación 20h 2.6 Diseño PCB 15h 5h 2.7 Fabricación PCB 6h 2.8 Verificación de la PCB 6h 6h 6h 6h

3 Desarrollo de aplicación de android 3.1 Diseño de pantallas 20h 2h 3.2 Programacion de aplicacion 30h 15h 3.3 Testeo de aplicación 8hh 8h

4 Desarrollo de firmware 4.1 Familiarización con RTOS 10h 4.2 Selección de bibliotecas de código a utilizar 10h 4.3 Diseño de arquitectura 20h

4.4 Diseño de protocolo de mensajes para la comunicacióncon dispositivos de advertencia

20h

4.5 Diseño de drivers genericos para dispositivos de advertencia

15h

4.6 Programación de protocolo de comunicación con dispositivos de advertencia

20h

4.7 Programación de drivers genericos 20h 4.8 Programación de arquitectura 20h 4.9 Programación aprendizaje de secuencias del semáforo 30h 4.1 Diseño de tareas del sistema operativo 4h

Página 13 de 27




5 Ensayos 5.1 Familiarización con el framework de test unitarios 8h 5.2 Realización de test unitarios 25h 5.3 Diseño de casos de prueba 8h 5.4 Testeo manuale 10h 10h 2h 10h 10h 5h 5.5 Desarrollo de semáforo para testeo 20h 30h 40h

6 Desarrollo del gabinete

6.1 Investigación sobre requerimientos estéticos y funcionales

10h

6.2 Diseño del gabinete 20h 6.3 Fabricación del gabinete 1h 5h 15h

7 Presentación del proyecto 7.1 Preparación del informe final 45h 2h 7.2 Escritura del manual de usuario 20h 7.3 Escritura informe de avance 20h 7.4 Preparación de diapositivas para exposicion 8h 2h

10. Presupuesto detallado del proyecto ID Descripción Cantidad Costo Total

1 Horas hombre 614 h US$ 20 US$ 12280

2 Modulo WiFI 2 u US$ 7 US$ 14

3 Modulo RF 2 u US$ 7 US$ 14

4 Arduino uno 1 u US$ 8 US$ 8

5 Placa de cobre 1 u US$ 2 US$ 20

6 Componentes varios 1 u US$ 5 US$ 5

7 Relé 5u US$ 3 U$15

8 Estaño 1 u US$ 1 US$ 1

9 Hora impresión 3D + material 36 h US$ 1 US$ 360

10 Hora impresión + papel 4 h US$ 1 US$ 4

Total costos directos (USD) US$ 12379

11 Costos indirectos (20% costos directos) -- -- US$ 24750

TOTAL US$ 14854,80

Referencias: u : unidades h : horas

Página 14 de 27




11. Matriz de asignación de responsabilidades

Código WBS Título de la tarea

Involucrados en el proyecto

Ing. Suarez Sebastian A, Responsable

Jorge Fiszman

Impulsor

Esp. Ing. Sergio R. De Jesus Melean Director

Persona no vidente Usuario

1 Investigación preliminar

1.1 Investigación sobre productos similares en el mercado P C

1.2 Investigación sobre la frecuencia del sonido que debería producir el buzzer, acorde a las personas no videntes

P I C

1.3 Investigación sobre circuitos para aislar el sistema P C

1.4 Investigación sobre fuentes para alimentar el sistema P C

1.5 Investigación del módulo de radio frecuencia P C

1.6 Investigación del módulo WiFi P C

1.7 Investigación de cómo generar sonidos por medio de la CIAA u otras alternativas

P C C

1.8 Reunión de arranque P A I I

2 Desarrollo del hardware

2.1 Analisis tecnico/economico P C A

2.2 Elección de componentes P C A

2.3 Reunión para determinación de hardware P I A

2.4 Selección de puertos P I A

2.5 Diseño fuente de alimentación P A

2.6 Diseño PCB P A

2.7 Fabricación PCB P I I

2.8 Verificación de la PCB P I

3 Desarrollo de aplicación de android

3.1 Diseño de pantallas P C I C

3.2 Programacion de aplicacion P I

3.3 Testeo de aplicación P I I C

4 Desarrollo de firmware

4.1 Familiarización con RTOS P I

4.2 Selección de bibliotecas de código a utilizar P C

4.3 Diseño de arquitectura P C

4.4 Diseño de protocolo de mensajes para la comunicación con dispositivos de advertencia

P C

4.5 Diseño de drivers genericos para dispositivos de advertencia

P C

4.6 Programación de protocolo de comunicación con dispositivos de advertencia

P C

4.7 Programación de drivers genericos P A

4.8 Programación de arquitectura P A

4.9 Programación aprendizaje de secuencias del semáforo P A

4.1 Diseño de tareas del sistema operativo P A

Página 15 de 27




5 Ensayos

5.1 Familiarización con el framework de test unitarios P C

5.2 Realización de test unitarios P C

5.3 Diseño de casos de prueba P C A

5.4 Testeo manual P C A C

5.5 Desarrollo de semáforo para testeo P C


6.1 Investigación sobre requerimientos estéticos y funcionales

P C C

6.2 Diseño del gabinete P I A

6.3 Fabricación del gabinete P I A

7 Presentación del proyecto

7.1 Preparación del informe final P I A

7.2 Escritura del manual de usuario P C A

7.3 Escritura informe de avance P A

7.4 Preparación de diapositivas para exposicion P A

Referencias: P = Responsabilidad Primaria S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado

Página 16 de 27




12. Gestión de riesgos Se identificaron los siguientes riesgos: Riesgo 1: Robo, extravío o pérdida, total o parcial, del proyecto (Hardware, software y/o documentación)

● Severidad (S): 8 – Este riesgo retrasaría significativamente el flujo del proyecto viéndose con una severidad alta si la información es muy relevante para la tarea que se esté realizando en el momento que se suscite.

● Probabilidad de ocurrencia (O): 4 – Ya existe una planificación de las áreas de trabajo para evitar este inconveniente sin embargo siempre hay una probabilidad de ocurrencia.

Riesgo 2: Posibilidad de no lograr advertir satisfactoriamente a la persona no vidente

● Severidad (S): 10 – No conseguir la advertencia a la persona no vidente puede ocasionar un lesión o incluso costarle la vida a la persona si el sistema no funciona correctamente.

● Probabilidad de ocurrencia (O): 8 – Si bien se estableció bastante tiempo a la tarea de investigación y testeo del sistema de forma que esto no suceda, es posible que alguno aspectos no puedan llegar a ser cubiertos por desconocimiento a la condición de ser una persona no vidente.

Riesgo 3: Cambio, modificación o aumento de requerimiento(s) después de una verificación

● Severidad (S): 7 – Este valor cambia mucho según la etapa en la que se encuentre el proyecto y si el requerimiento que se desea modificar está en una etapa ya realizada o no por lo tanto se tomará un valor medio.

● Probabilidad de ocurrencia (O): 10 – Los repetidos cambios de requisitos son constantes por lo tanto la probabilidad de ocurrencia es alta.

Riesgo 4: Problemas en la implementación de la aplicación Android para el control vía WiFi

● Severidad (S): 2 – La aplicación es una tarea que puede retrasarse hasta las pruebas finales como caso extremo sin verse afectado el tiempo de entrega del proyecto,

● Probabilidad de ocurrencia (O): 3 – Existe mucha información respecto a este problema en internet y bibliografía que permite solucionar rápidamente el problema.

Riesgo 5: Descripción: Pérdida de prioridad del proyecto frente a otros compromisos laborales.

● Severidad (S): 8 - Es de vital importancia que se respeten los tiempos establecidos, la ocurrencia de este riesgo impacta directamente en la fecha de entrega y en la nota final.

● Probabilidad de ocurrencia (O): 3 - No se cumplen con los hitos de avance, la duración del proyecto se alarga y se corre el riesgo de no cumplir con la fecha de entrega pactada.

Página 17 de 27




Riesgo 6: Error de diseño del PCB. Un error en el diseño del PCB invalida todo el proyecto y es necesaria otra iteración.

● Severidad (S): 10 - Se requiere una iteración de fabricación completa en caso de error. ● Probabilidad de ocurrencia (O): 4 - El error humano siempre es un factor de riesgo, y

siempre está presente en un trabajo de vital importancia. Riesgo 7: Falla de algún componente. Cualquier componente que falle impedirá una correcta puesta en marcha.

● Severidad (S): 8 - Un componente fallado no permite poner en marcha el prototipo del sistema.

● Probabilidad de ocurrencia (O): 4 - Es muy extraño que los componentes se entregan con fallas pero estas pueden ocurrir durante el montaje y soldadura en el PCB.

b) Tabla de gestión de riesgos:

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 8 4 32 4 4 16

2 10 8 80 5 4 20

3 7 10 70 5 10 20

4 2 3 6 - - -

5 8 3 24 4 3 12

6 10 4 40 7 4 28

7 8 4 32 3 4 24

c) Plan de mitigación de los riesgos Riesgo 1: Robo, extravío o pérdida, total o parcial, del proyecto (Hardware, software y/o documentación).

● Mitigación: Utilizar a GIT como sistema de gestión y manejo de código y la nube como medio para resguardar la documentación.

● Severidad*: 4 - Un buen manejo de estas herramientas ayudan a tener un backup de todo el trabajo realizado

● Ocurrencia*: 4 - Se tiene un alto grado de experiencia manejando las herramientas. Riesgo 2: Posibilidad de no lograr advertir satisfactoriamente a la persona no vidente.

● Mitigación: Involucrar a una persona no vidente en el proyecto. ● Severidad*: 5 - La experiencia de una persona no vidente es fundamental para detectar

alguna posible falla en el sistema. ● Ocurrencia*: 4 - Se realizará un testeo completo y minucioso del sistema involucrando a

dicha persona.

Página 18 de 27




Riesgo 3: Cambio, modificación o aumento de requerimiento(s) después de una verificación.

● Mitigación: 5 - Tratar de definir todos los requisitos al principio del proyecto. ● Severidad*: El impacto puede ser grande, pero está muy bien definida la finalidad del

mismo. ● Ocurrencia*: 10 - El proyecto tiene pocos requerimientos, aun así esto sucede en la

mayoría de los proyectos. Riesgo 5: Descripción: Pérdida de prioridad del proyecto frente a otros compromisos laborales.

● Mitigación: Establecer metas probables y reales desde el principio del proyecto. ● Severidad*: 4 - Si es necesario se invertirá más tiempo en el proyecto. ● Ocurrencia*: 3 - La planificación está realizada de manera consciente de tal forma de

poder llegar a la meta establecida Riesgo 6: Error de diseño del PCB. Un error en el diseño del PCB invalida todo el proyecto y es necesaria otra iteración.

● Mitigación: Control minuciosamente el diseño de la pc y la soldadura de los materiales, si es posible, solicitar la ayuda de un tercero para el control.

● Severidad*: 7 - En incorporar a una persona que realice un segundo testeo, disminuye el riesgo pero no lo baja del todo.

● Ocurrencia*: 4 - El error humano es un factor que no disminuye fácilmente. Riesgo 7: Falla de algún componente.

● Mitigación: Comprar en lo posible más de un componente por si esto ocurriese. ● Severidad*: 3 - La mayoría de los componentes ya los tengo. ● Ocurrencia*: 4 - Los componentes en su mayoría son de fácil adquisición.

13. Gestión de la calidad 1. Requerimientos de Hardware:

1.1. Operar con cargas de entradas de 220 V, 50 Hz y hasta 5A. ● Verificación: Una vez conectado el equipo a estas cargas se verificará

ocularmente la placa para cerciorarse que no existen fugas, elevada temperatura, etc.

● Validación: Se comprobará en modo debug que la toma de entrada es correcta.

1.2. El hardware involucrado en la detección del cambio de luces debe estar totalmente aislado del módulo principal.

● Verificación: Se implementarán técnicas de aislamiento. ● Validación: Se realizará un prueba ocular de la placa en busca de posibles

defectos.

2. Requerimientos de comunicación: 2.1. El sistema debe proveer un red Wifi que cumpla con las normas IEEE 802.11.

● Verificación: Se realizará una inspección ocular de la placa seleccionada tenga el sello correspondiente a dicha norma.

Página 19 de 27




● Validación: Se realizarán pruebas de conexión entre la aplicación desarrollada y el prototipo.

2.2. Se debe proveer una interface sonora, la cual de debe poder controlarse automáticamente dependiendo del ruido presente.

● Verificación: Se realizarán análisis de las hojas de datos de buzzer verificando que dicho elemento trabaja en las frecuencias requeridas.

● Validación: Se realizarán pruebas entre la aplicación desarrollada y el prototipo.

2.3. Se debe proveer una interface para activar el sistema por medio de un botón. ● Verificación: Revisar conexiones en el prototipo. ● Validación: Presionar el botón y cerciorarse que el sistema funciona

correctamente. 2.4. Se debe proveer una interface para activar el sistema por medio de un control a

distancia, el cual debe operar en la frecuencia de 2.4GHz. ● Verificación: Se realizarán análisis de las hojas de datos del módulo verificando

que dicho elemento trabaja en las frecuencias requeridas. ● Validación: Presionar el botón del control RF y cerciorarse que el sistema

funciona correctamente.

3. Requerimientos del software embebido: 3.1. El sistema deberá ser capaz de aprender la secuencia de cambio de luces.

● Verificación: Se realizarán pruebas con distintos tiempos entre luces. ● Validación: A Través de la aplicación o el pitido del buzzer se comprobará que las

advertencias se hagan de forma correcta.

3.2. El sistema deberá ser capaz de detectar el semáforo fuera de servicio. ● Verificación: Realizar una simulación de que el semáforo principal se encuentra

fuera de servicio. ● Validación: A Través de la aplicación o el pitido del buzzer se comprobará que las


3.3. Se deberá implementar un protocolo para la fácil escalabilidad de los distintos tipos de comunicación.

● Verificación: A Través de un puerto seleccionado para dicho propósito se agregara otro botón.

● Validación: A Través de la aplicación o el pitido del buzzer se comprobará que las advertencias se hagan de forma correcta.

3.4. El sistema deberá implementarse en base a un sistema operativo de tiempo real. ● Verificación: Inspección del código comprobando que la arquitectura y la

configuración corresponda a un sistema operativo de tiempo real.

Página 20 de 27




● Validación: Comprobar que las tareas se realizan de la forma esperada.

4. Requerimientos de la metodología de desarrollo: 4.1. Se utilizará GIT como herramienta de control de versiones.

● Verificación: Inspección ocular de la estructura de directorio sobre la cual se está desarrollando el código fuente.

● Validación: Comprobar los cambios realizados por medio de github sean correspondientes a los realizados en el ambiente local.

4.2. Se utilizará Doxygen como herramienta para generar la documentación. ● Verificación: Inspección ocular del código comprobando las anotaciones

correspondientes para generar la documentación por doxygen. ● Validación: Comprobar que la documentación generada sea la correcta.

5. Se realizarán tests unitarios para cada módulo. ● Verificación: A través de código de revisión provisto por github. ● Validación: Correr los test unitarios y verificar que todos se ejecuten

correctamente.

6. Requerimientos de la aplicación móvil: 6.1. Conectarse automáticamente a la red wifi que provee el sistema.

● Verificación: A través de las hojas de datos provistas por el fabricante del dispositivo.

● Validación: A Través de la aplicación se comprobará que las advertencias se hagan de forma correcta.

6.2. Definir un protocolo de vibraciones según los mensajes del sistema ● Verificación: Inspección del código fuente para comprobar que cumple con los

requisitos definidos. ● Validación: A Través de la aplicación o el pitido del buzzer se comprobará que las


Página 21 de 27




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

Avance del proyecto

Sergio R. De Jesus Melean, Javier

Viqueira

Dar a conocer el avance del

desarrollo del proyecto

Mensual Email Suarez, Sebastian Alejandro

Bloqueos, inquietudes y resolución de

problemas

Sergio R. De Jesus Melean

Consultar sobre problemas o

dudas que surjan

Cuando se requiera

Email y reuniones

Suarez, Sebastian Alejandro

Informe de avance

Jurado de tesis, Sergio R. De Jesus

Melean, Ariel Lutenberg

Poner en conocimiento de los interesados el

estado del proyecto

Unica vez Email Suarez, Sebastian Alejandro

Memoria de proyecto final

Jurado de tesis, Sergio R. De Jesus

Melean, Ariel Lutenberg

Poner en conocimiento de los interesados la

memoria del proyecto final a los efectos de su

evaluación

Unica vez Email Suarez, Sebastian Alejandro

Presentación de proyecto

final

Audiencia pública Poner en conocimiento de los asistentes el

trabajo final desarrollado para la especialización

Única vez Presentación pública


Página 22 de 27




15. Gestión de Compras La adquisición de los dispositivos requeridos para este proyecto, serán adquiridos a través de internet por medio de la plataforma de Mercadolibre. Dichos dispositivos deberán cumplir con las necesidades propias para el funcionamiento del sistema.

Pedido de presupuesto Ejemplo para solicitud de compra de componentes electrónicos:

Ciudad de Córdoba, 1 de Enero de 2019 Sres. [Razón Social del Proveedor]: Mediante la presente se solicita un presupuesto de los materiales de la lista adjunta bajo las siguientes condiciones:

● Costo: no superior a $NNN.- (N pesos argentinos) ● Modalidad de pago: Contado. ● Plazo de entrega: 10 días hábiles. ● Garantía: Los componentes se entregan en bolsas antiestáticas selladas para preservarlos de la

humedad y descargas electrostáticas.

Firma Proveedor Firma Gerente de Compras

Página 23 de 27




16. Seguimiento y control

SEGUIMIENTO DE AVANCE

WBS Indicador de avance Frecuencia de reporte

Responsable de

seguimiento

Persona a ser

informada

Método de comunicac.

1 Investigación preliminar

1.1 Conclusión sobre los productos similares en el mercado

Unica vez Suarez, Sebastian Alejandro

Director Email

1.2 Conclusión sobre la frecuencia del sonido que debería producir el buzzer, acorde a las personas no videntes


Director Email

1.3 Conclusión sobre circuitos para aislar el sistema


Director Email

1.4 Conclusión sobre fuentes para alimentar el sistema


Director Email

1.5 Conclusión del módulo de radio frecuencia


Director Email

1.6 Conclusión del módulo WiFi


Director Email

1.7 Conclusión de cómo generar sonidos por medio de la CIAA u otras alternativas


Director Email

2 Desarrollo del hardware

2.1 Finalización del analisis tecnico/economico


Director Email

2.2 Elección de componentes

Cuando ser requiera


Director Email

2.4 Conclusión sobre la selección de puertos


Director Email

2.5 Cada versión realizada sobre el diseño fuente de alimentación

Cuando ser requiera


Director Email

Página 24 de 27




2.6 Cada versión realizada sobre el diseño de la PCB

Cuando ser requiera


Director Email

2.7 Una vez realizada la fabricación de la PCB

Cuando ser requiera


Director Email

2.8 Finalizadas las pruebas sobre la PCB

Única vez Suarez, Sebastian Alejandro

Director Email

3 Desarrollo de aplicación de android

3.1 Cada versión realizada sobre el diseño de las pantallas

Cuando ser requiera


Director Email

3.2 Cada versión realizada sobre la programación de la aplicación

Cuando ser requiera


Director, Jorge

Fiszman

Email

3.3 Finalizadas las pruebas sobre la aplicación


Director Email

4 Desarrollo de firmware

4.2 Cuando se seleccione las bibliotecas de código a utilizar

Única vez Suarez, Sebastian Alejandro

Director Email

4.3 Cada versión realizada sobre el diseño de arquitectura

Cuando ser requiera


Director Email

4.4

Cada versión realizada sobre el diseño de protocolo de mensajes para la comunicación con dispositivos de advertencia

Cuando ser requiera


Director Email

4.5 Cada versión realizada sobre el diseño de drivers genericos para dispositivos de advertencia

Cuando ser requiera


Director Email

4.6

Cada versión realizada sobre la programación de protocolo de comunicación con dispositivos de advertencia

Cuando ser requiera


Director Email

4.7 Cada versión realizada sobre la programación de drivers genericos

Cuando ser requiera


Director Email

4.8 Cada versión realizada sobre la programación de arquitectura

Cuando ser requiera


Director Email

Página 25 de 27




4.9 Cada versión realizada sobre la programación aprendizaje de secuencias del semáforo

Cuando ser requiera


Director Email

4.1 Cada versión realizada sobre el diseño de tareas del sistema operativo

Cuando ser requiera


Director Email

5 Ensayos

5.2 Finalizados los test unitarios


Director Email

5.3 Cada versión realizada sobre los diseños de casos de prueba

Cuando ser requiera


Director Email

5.4 Una vez finalizado el testeo manual

Cuando ser requiera


Director, Jorge

Fiszman

Email


6.1 Conclusión sobre los requerimientos estéticos y funcionales

Cuando ser requiera


Director Email

6.2 Cada versión realizada sobre el diseño del gabinete

Cuando ser requiera


Director Email

6.3 Una vez realizada la fabricación del gabinete


Director, Jorge

Fiszman

Email

7 Presentación del proyecto

7.1 Cada versión realizada sobre la preparación del informe final

Mensual Suarez, Sebastian Alejandro

Director, Ariel

Lutenberg

Email

7.2 Cada versión realizada sobre la escritura del manual de usuario

Semanal Suarez, Sebastian Alejandro

Directo, Ariel Lutenberg

Email

7.3 Cada versión realizada sobre la escritura informe de avance

Mensual Suarez, Sebastian Alejandro

Director, Ariel

Lutenberg

Email

7.4 Cada versión realizada sobre la preparación de diapositivas para exposicion

Cuando ser requiera


Director, Ariel

Lutenberg

Email

Página 26 de 27




17. Procesos de cierre Establecer las pautas de trabajo para realizar una reunión final de evaluación del proyecto, tal que contemple las siguientes actividades: ■ Pautas de trabajo que se seguirán para analizar si se respetó el Plan de Proyecto original:

● Responsable: Sebastian Alejandro Suarez ● Procedimiento:

○ Se revisará si se cumplieron los tiempos de entrega de cada tarea. ○ Se revisará si se cumplieron con todos los requerimientos. ○ Se analizará si fue correcto el plan de mitigación de riesgos o hubo riesgos no

contemplados. ○ Las conclusiones serán registradas en la memoria del trabajo.

■ Identificación de las técnicas y procedimientos útiles e inútiles que se utilizaron, y los problemas que surgieron y cómo se solucionaron:


○ Se evaluará si las técnicas de diseño de software utilizadas fueron las correctas. ○ Se evaluará si las técnicas utilizadas pueden utilizarse para futuros proyectos. ○ Se analizaron los problemas que surgieron durante el proyecto y cómo se solucionaron. ○ Se tomará registro en la memoria del trabajo.

■ Indicar quién organizará el acto de agradecimiento a todos los interesados, y en especial al equipo de trabajo y colaboradores:


○ Una vez finalizado el proyecto, se agradecerá formalmente a todos los colaboradores y se informará a los interesados la finalización del mismo.

○ En la memoria del proyecto se escribirá un agradecimiento al auspiciante y a los colaboradores.

Página 27 de 27

Sistema para conversión de semáforos convencionales en...

Documents

Transcript of Sistema para conversión de semáforos convencionales en...