GNU Radio FMCOMMS1 -...

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Juan Pablo Tettamanti

GNU Radio FMCOMMS1

Autor


Director del trabajo

Esp. Ing. Pedro Ignacio Martos

Jurado propuesto para el trabajo

- Mg. Ing. Diego Brengi (UNLAM, INTI) - Ing. Octavio Alpago (FIUBA) - (???)

Este plan de trabajo ha sido realizado en el marco de la asignatura gestión de proyectos entre octubre y diciembre de 2015.

Página 1 de 25




Tabla de contenido

Registros de cambios

Acta Constitutiva

1. Nombre del Proyecto

2. Fecha de inicio y finalización del proyecto

3. Presupuesto preliminar asignado

4. Identificación y análisis de los interesados

5. Propósito y Justificación del proyecto

6. Objetivos

7. Alcance del proyecto

8. Supuestos y restricciones del proyecto

9. Requerimientos

10. Entregables principales del proyecto

11. Desglose del trabajo en tareas

12. Análisis de factibilidad

13. Diagrama de Activity On Node

14. Diagrama de Gantt

15. Matriz de uso de recursos de materiales

16. Presupuesto detallado del proyecto

17. Matriz de asignación de responsabilidades

18. Gestión de riesgos

19. Gestión de la calidad

20. Comunicación del proyecto

21. Gestión de Compras

22. Seguimiento y control

23. Procesos de cierre

Página 2 de 25




Registros de cambios

Revisión Cambios realizados Fecha

1.0 Creación del documento 01-11-2015

1.1 Definición puntos 1 a 7 01-11-2015



1.4 Correcciones generales 1 22-11-2015

1.5 Correcciones generales 2 27-11-2015

Página 3 de 25




Acta Constitutiva

27 de noviembre de 2015, CAADIEL

Attn Juan Pablo Tettamanti

De mi mayor consideración

Con el fin de implementar bloques de GNU Radio para el uso del kit de desarrollo FMCOMMS1,

se lo designa a Ud como Responsable del proyecto con “GNU Radio FMCOMMS1”, con un presupuesto

total estimado de seiscientas (600) horas hombre, con fecha tentativa de inicio 1 de noviembre de 2015

y de finalización 30 de junio de 2016.

Se adjunta a esta acta la planificación inicial.

Esp. Ing. Pedro Martos

Docente de la Carrera de Especialización en Sistemas

Embebidos - FIUBA

Página 4 de 25




1. Nombre del Proyecto

GNU Radio FMCOMMS1

2. Fecha de inicio y finalización del proyecto

01-11-2015 al 30-06-2016

3. Presupuesto preliminar asignado

600 HH

4. Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante LSE LSE - FIUBA

Cliente Pedro Ignacio Martos CESE - FIUBA Docente

Impulsor Pedro Ignacio Martos CESE - FIUBA Docente

Responsable Juan Pablo Tettamanti CESE - FIUBA Estudiante

Colaboradores Docentes CESE CESE - FIUBA

Orientadores Pedro Ignacio Martos CESE - FIUBA Docente

Equipo -

Opositores -

Usuario Final Integrantes LSE LSE - FIUBA

- Orientador: Pedro Ignacio Martos, lleva tiempo trabajando con la placa FMCOMMS1 y el software

GNU Radio.

Página 5 de 25




5. Propósito y Justificación del proyecto

El propósito de este proyecto es implementar en el software GNU Radio los bloques para el uso de la

placa FMCOMMS1, adquirir los conocimientos necesarios para llevar adelante un proyecto de Software

Defined Radio y satisfacer el requerimiento de un proyecto final de la Carrera de Especialización en

Sistemas Embebidos.

La justificación de este proyecto es que el LSE cuenta con una placa FMCOMMS1, la cual se usa en

conjunto con una placa Zedboard y el software GNU Radio para la implementación de distintos

proyectos de Software Defined Radio.

6. Objetivos

1. Terminar el proyecto antes del 30 de junio de 2016

2. Aprender sobre Software Defined Radio

3. Implementar bloques de entrada-salida de la placa FMCOMMS1 en GNU Radio

4. Enviar el código de los bloques implementados al proyecto GNU Radio

7. Alcance del proyecto

El proyecto incluye la programación de los bloques para el uso de la placa FMCOMMS1 con GNU Radio, la documentación de los bloques implementados y el envío del código al proyecto GNU Radio para su inclusión. El proyecto no incluye la aceptación del código por parte del proyecto GNU Radio, la obtención de las placas de desarrollo necesarias para implementar y testear los bloques y el funcionamiento de los bloques implementados en plataformas diferentes a la provista (Zedboard).

8. Supuestos y restricciones del proyecto

Supuestos:

● El LSE cuenta con una placa Zedboard ● El LSE cuenta con una placa FMCOMMS1 ● Las placas Zedboard y FMCOMMS1 serán ampliamente accesibles ● Se podrá obtener a modo de préstamo las placas Zedboard y FMCOMMS1 por periodos de

tiempo limitados

Restricciones:

● No se podrán reponer las placas Zedboard y FMCOMMS1 en caso de avería y o extravío.

Página 6 de 25




9. Requerimientos

Requerimientos de plataforma 1. Utilizar la placa de desarrollo Zedboard para el procesamiento de señales de RF 2. Utilizar la placa de desarrollo FMCOMMS1 para la adquisición de señales de RF 3. Utilizar el software GNU Radio para la ejecución del software

Requerimientos de SW

4. Implementar un bloque de fuente (source) para GNU Radio 5. Implementar un bloque de sumidero (sink) para GNU Radio 6. Permitir un uso pleno de la opciones del hardware de la placa FMCOMMS1 desde el software

GNU Radio

10. Entregables principales del proyecto

1. Código de los bloques FMCOMMS1 para GNU Radio 2. Documentación de usuario 3. Ejemplos de uso y validación de la plataforma

Página 7 de 25




11. Desglose del trabajo en tareas

1. Gestión del proyecto (40 hs)

2. Estudio inicial de plataforma de desarrollo (120 hs)

2.1. Estudio de software GNU Radio (40 hs)

2.2. Estudio de plataforma Zedboard (40 hs)

2.3. Estudio de placa FMCOMMS1 (40 hs)

3. Pruebas iniciales de plataforma de desarrollo (80 hs)

3.1. Pruebas del sistema operativo (20 hs)

3.2. Pruebas de drivers (20 hs)

3.3. Adquisición de señal de prueba (40 hs)

4. Diseño detallado (120 hs)

4.1. Software (80 hs)

4.2. Documentación de usuario (40 hs)

5. Implementación (120 hs)



6. Integración y ensayos (120 hs)



7. Presentación (75 hs)

7.1. Informe de avance (15 hs)

7.2. Memoria del trabajo (50 hs)

7.3. Presentación pública (10 hs)

Página 8 de 25




12. Análisis de factibilidad

Las radios definidas por software o SDR (del inglés Software Defined Radio), son sistemas de telecomunicaciones donde varios de los componentes típicamente implementados en hardware, son implementados en software.

Debido al hecho de que la mayor parte de la funcionalidad de un sistema SDR se encuentra definido en el software, los mismos resultan mucho más fáciles de modificar o upgradear.

Como consecuencia, los investigadores y desarrolladores han invertido tiempo en implementar distintos sistemas de radio utilizando esta nueva plataforma. Esto ha permitido la validación de distintos sistemas y protocolos bajo la más diversa variedad de condiciones.

Conforme esta tecnología continúa evolucionando y madurando, se espera poder incorporar funciones más avanzadas, tales como la selección de protocolos dependiendo de las condiciones atmosféricas.

A medida que las radios definidas por software se han ido volviendo más comunes, distintas compañías y organizaciones han desarrollado plataformas de hardware para el uso en este tipo de aplicaciones, siendo unas de las más conocidas, las plataformas USRP de Ettus Research.

Adicionalmente, existen varios proyectos de software para el desarrollo de radios definidas por software, siendo algunas de las más conocidas GNU Radio y OSSIE (ambas de código abierto) y Simulink y Labview (ambas sistemas propietarios).

Página 9 de 25




13. Diagrama de Activity On Node

Página 10 de 25




14. Diagrama de Gantt

Página 11 de 25




15. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea

Recursos requeridos (horas)

Zedboard FMCOMMS1 Generador de

señal Analizador de

espectro 3.1 Pruebas del

sistema

operativo

20 - - -

3.2 Pruebas de

drivers

20 20 - -

3.3 Adquisición

de señal de

prueba

40 40 40 -

6.1 Software 80 80 - 40

Total 160 140 40 40

Página 12 de 25




16. Presupuesto detallado del proyecto Costos directos de recursos humanos Costo de hora de desarrollador - 30 ARS / hora

1. Gestión del proyecto (40 hs) - 1200 ARS

2. Estudio inicial de plataforma de desarrollo (120 hs) - 3600 ARS

2.1. Estudio de software GNU Radio (40 hs) - 1200 ARS

2.2. Estudio de plataforma Zedboard (40 hs) - 1200 ARS

2.3. Estudio de placa FMCOMMS1 (40 hs) - 1200 ARS

3. Pruebas iniciales de plataforma de desarrollo (80 hs) - 2400 ARS

3.1. Pruebas del sistema operativo (20 hs) - 600 ARS

3.2. Pruebas de drivers (20 hs) - 600 ARS

3.3. Adquisición de señal de prueba (40 hs) - 1200 ARS

4. Diseño detallado (120 hs) - 3600 ARS

4.1. Software (80 hs) - 2400 ARS

4.2. Documentación de usuario (40 hs) - 1200 ARS

5. Implementación (120 hs) - 3600 ARS



6. Integración y ensayos (120 hs) - 3600 ARS



7. Presentación (75 hs) - 2250 ARS

7.1. Informe de avance (15 hs) - 450 ARS

7.2. Memoria del trabajo (50 hs) - 1500 ARS

7.3. Presentación pública (10 hs) - 300 ARS

Costos directos totales: 22250 ARS

Página 13 de 25




Costos directos en plataforma de desarrollo Estos costos ya se encuentran cubiertos al momento de iniciar este proyecto

❏ Zedboard, Academic Edition - 319 USD ❏ AD-FMCOMMS1-EBZ - 1,042.96 USD

Costos indirectos en licencias de software Estos costos ya se encuentran cubiertos al momento de iniciar este proyecto

❏ Debian GNU/Linux Jessie - 0 USD ❏ GNU Radio - 0 USD ❏ GCC - 0 USD ❏ Python - 0 USD ❏ PetaLinux - 0 USD ❏ Xilinx Design Suite - 5795 USD

Página 14 de 25




17. Matriz de asignación de responsabilidades

Código WBS Título de la tarea

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

Juan Pablo Tettamanti

Pedro Martos Jurado Ariel Lutenberg

1 Gestión del

proyecto

P C A

2.1 Estudio de GNU

Radio

P C,A C

2.2 Estudio de

Zedboard

P C,A C

2.3 Estudio de

FMCOMMS1

P C,A C

3.1 Pruebas del

sistema operativo

P C,A

3.2 Pruebas de

drivers

P C,A

3.3 Adquisición de

señal de prueba

P C,A

4.1 Software P C,A C

4.2 Documentación P C,A

5.1 Software P C,A C I

5.2 Documentación P C,A I

6.1 Software P C,A C I

6.2 Documentación P C,A I

7.1 Informe de

avance

P C,A C,A I

7.2 Memoria del

trabajo

P C,A C,A I

7.3 Presentación

pública

P C,A C,A I

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

Página 15 de 25




18. Gestión de riesgos Identificación de los riesgos y estimación de sus consecuencias

★ Riesgo 1: Pérdida o rotura de Zedboard ○ Severidad (S): 10

Si la placa se pierde o resulta dañada, es altamente probable que no se pueda reemplazar antes de la fecha de finalización del proyecto.

○ Probabilidad de ocurrencia (O): 2 La placa podría resultar dañada durante su uso o perderse si se la transporta, pero la placa es manejada con cuidado por especialistas y no es transportada con frecuencia.

○ Tasa de no detección (D): 1 Si la placa se daña o se pierde, será totalmente evidente que esto ha ocurrido.

★ Riesgo 2: Pérdida o rotura de FMCOMMS1 ○ Severidad (S): 10

Si la placa se pierde o resulta dañada, es altamente probable que no se pueda reemplazar antes de la fecha de finalización del proyecto.

○ Probabilidad de ocurrencia (O): 2 La placa podría resultar dañada durante su uso o perderse si se la transporta, pero la placa es manejada con cuidado por especialistas y no es transportada con frecuencia.

○ Tasa de no detección (D): 1 Si la placa se daña o se pierde, será totalmente evidente que esto ha ocurrido.

★ Riesgo 3: Borrado accidental del software ○ Severidad (S): 8

Si se borra el software, se deberá comenzar desde cero. ○ Probabilidad de ocurrencia (O): 4

El desarrollador principal tiene la costumbre de borrar periódicamente archivos y carpetas en desuso mediante la secuencia Ctrl + Alt + Supr.

○ Tasa de no detección (D): 2 Si se borra un archivo, podría pasar desapercibido en el caso de que no sea un archivo de importancia crítica o bien sea de uso poco frecuente.

★ Riesgo 4: Introducción de cambios que provocan un mal comportamiento del software ○ Severidad (S): 6

En ocasiones se suelen introducir cambios que provocan un mal comportamiento; si bien los mismos son reparables, es un proceso que lleva tiempo.

○ Probabilidad de ocurrencia (O): 6 Es altamente probable que un programador, por más experimentado que sea, eventualmente introduzca cambios que provoquen un mal comportamiento.

○ Tasa de no detección (D): 4 En ocasiones, una pieza de software que introduce un mal comportamiento no lo manifiesta hasta etapas posteriores en el proceso de desarrollo.

Página 16 de 25




★ Riesgo 5: Pérdida o rotura de la PC de desarrollo ○ Severidad (S): 4

Si se pierde o se rompe la PC de desarrollo, se deberá conseguir una nueva. ○ Probabilidad de ocurrencia (O): 4

La PC de desarrollo suele transportarse con frecuencia. ○ Tasa de no detección (D): 1

La PC de desarrollo está en uso constantemente, será totalmente evidente que esto ha ocurrido.

Tabla de gestión de riesgos

Riesgo Severidad Ocurren. Detección RPN Severidad* Ocurren.*

Detecc * RPN*

1 10 2 1 20

2 10 2 1 20

3 8 4 2 64 2 4 1 8

4 6 6 4 144 4 2 2 16

5 4 4 1 64 2 2 1 4

Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 50.

Página 17 de 25




Plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido ★ Riesgo 3: Uso de software de control de versiones en la nube (github)

○ Severidad (S): 2 Si se borra la copia local, simplemente se debe descargar una copia remota. Se deberán realizar las modificaciones que no se hubieran subido al sistema de control de versiones.

○ Probabilidad de ocurrencia (O): 4 El uso de un software de control de versiones no afecta el comportamiento del desarrollador y por lo tanto la probabilidad de ocurrencia.

○ Tasa de no detección (D): 1 El uso de un software de control de versiones indica claramente si se ha eliminado algún archivo recientemente y requiere de pasos adicionales para eliminar definitivamente un archivo. Adicionalmente, el mismo puede ser recuperado de versiones anteriores.

★ Riesgo 4: Uso extensivo de pruebas unitarias ○ Severidad (S): 4

El uso de pruebas unitarias contribuye a acotar cuanto se propaga un mal comportamiento.

○ Probabilidad de ocurrencia (O): 2 El proceso de diseño de las pruebas de un software ayuda a identificar posibles fuentes de error en ocasiones antes de que se escriba el propio código a poner a prueba.

○ Tasa de no detección (D): 2 El uso de estas pruebas permite detectar que las modificaciones introducidas no alteren el comportamiento deseado, contribuyendo a la detección temprana de errores.

★ Riesgo 5: Contar con un segundo dispositivo de desarrollo ○ Severidad (S): 2

Contar con un segundo dispositivo de desarrollo permite continuar con el mismo aún en caso de falla del primer dispositivo.

○ Probabilidad de ocurrencia (O): 2 La probabilidad de ocurrencia se divide proporcionalmente entre la cantidad de dispositivos.

○ Tasa de no detección (D): 1 Es fácil detectar fallas o pérdidas de los equipos de desarrollo.

Página 18 de 25




19. Gestión de la calidad 1. Utilizar la placa de desarrollo Zedboard para el procesamiento de señales de RF

★ Calidad Utilizar la placa de desarrollo Zedboard

★ Grado de calidad No corresponde

★ Costo de conformidad Se aprueba el trabajo

★ Costos de no conformidad No se aprueba el trabajo

★ Verificación Verificar que la placa sea comprada mediante un canal autorizado (http://zedboard.org/product/zedboard)

★ Validación Confirmar que los logos de Digilent, Avnet y Zedboard se encuentran en la placa

2. Utilizar la placa de desarrollo FMCOMMS1 para la adquisición de señales de RF

★ Calidad Utilizar la placa de desarrollo Zedboard

★ Grado de calidad No corresponde

★ Costo de conformidad Se aprueba el trabajo

★ Costos de no conformidad No se aprueba el trabajo

★ Verificación Verificar que la placa sea comprada mediante un canal autorizado (http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/eval-fmcomms.html#eb-buy)

★ Validación Confirmar que el logo de Analog Devices y la leyenda AD-FMCOMMS1-EBZ se encuentren sobre la placa

Página 19 de 25

http://zedboard.org/product/zedboard

http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/eval-fmcomms.html#eb-buy

http://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/eval-fmcomms.html#eb-buy




3. Utilizar el software GNU Radio para la ejecución del software ★ Calidad

Utilizar la placa de desarrollo Zedboard ★ Grado de calidad

No corresponde ★ Costo de conformidad

Se aprueba el trabajo ★ Costos de no conformidad

No se aprueba el trabajo ★ Verificación

Descargar el codigo de una fuente confiable (http://gnuradio.org) o del repositorio de una distribución (“sudo apt-get install gnuradio” en Debian o Ubuntu)

★ Validación Comprobar que en la sección Help->About aparezca una ventana con el logo, copyright, la frase “GNU Radio Companion vXXXX” y un enlace a https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion

4. Implementar un bloque de fuente (source) para GNU Radio

★ Calidad El bloque funciona correctamente en GNU Radio

★ Grado de calidad El bloque es fácil de utilizar

★ Costo de conformidad Se debe invertir tiempo en realizar pruebas al bloque (40 hs)

★ Costos de no conformidad Proyectos posteriores no serán capaces de generar señales

★ Verificación Se analiza el diseño detallado

★ Validación Realizar mediciones de señales generadas usando este bloque

Página 20 de 25

http://gnuradio.org/

https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion




5. Implementar un bloque de sumidero (sink) para GNU Radio ★ Calidad

El bloque funciona correctamente en GNU Radio ★ Grado de calidad

El bloque es fácil de utilizar ★ Costo de conformidad

Se debe invertir tiempo en realizar pruebas al bloque (40 hs) ★ Costos de no conformidad

Proyectos posteriores no serán capaces de adquirir señales ★ Verificación

Se analiza el diseño detallado ★ Validación

Realizar mediciones de señales generadas usando este bloque

6. Permitir un uso pleno de la opciones del hardware de la placa FMCOMMS1 desde el software GNU Radio

★ Calidad Los bloques implementados en el software GNU Radio permiten la transmisión y recepción señales con una frecuencia de portadora de 400MHz a 4GHz y un ancho de banda máximo de 125MHz

★ Grado de calidad Los bloques implementados en el software GNU Radio permiten la transmisión y recepción señales hasta el valor teórico

★ Costo de conformidad Se debe invertir tiempo en realizar las pruebas correspondientes

★ Costos de no conformidad No será posible adquirir señales con la frecuencia de portadora y ancho de banda deseados

★ Validación Consultar con especialista en el tema

★ Verificación Realizar mediciones de señales conocidas por medio de la placa FMCOMMS1 para verificar la correcta recepción Realizar mediciones de señales generadas por medio de la placa FMCOMMS1 para verificar la correcta transmisión

Página 21 de 25




20. Comunicación del proyecto

PLAN DE COMUNICACIÓN DEL PROYECTO

¿Qué comunicar?

Audiencia Propósito Frecuencia Método de

comunicac.

Responsable

Estado del proyecto

Tutor Evitar retrasos Evitar errores

Semanalmente Correo

electrónico


Diseño del software

Tutor Comunicar

finalización de diseño

Al finalizar Correo

electrónico


Implementación de software

Tutor Comunicar

finalización de implementación

Al finalizar Correo

electrónico


Ensayos Tutor Comunicar

resultado de los ensayos

Al finalizar Correo

electrónico


Informes de Avance

Jurados Tutor

Comunicar estado del proyecto

31 de marzo de 2016

Informe escrito


Memoria escrita

Jurados Tutor Ariel

Lutenberg

Informar el cuerpo de

conocimiento obtenido como resultado del

proyecto

15 de julio de 2016

Informe escrito


Presentación

pública

Jurados Tutor Ariel

Lutenberg

Defender y dar a conocer

públicamente los resultados

obtenidos

31 de julio de 2016

Página 22 de 25




21. Gestión de Compras Este proyecto no requiere comprar elementos o contratar servicios.

22. 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 Cantidad de

puntos del

informe

completados

Semanalmente Juan Pablo Tettamanti

Ariel Lutenberg

Pedro Martos

Correo electrónico

2.1 Cantidad de

horas

Al finalizar Juan Pablo Tettamanti

Pedro Martos

Correo electrónico

2.2 Cantidad de

horas


Pedro Martos

Correo electrónico

2.3 Cantidad de

horas


Pedro Martos

Correo electrónico

3.1 Cantidad de

horas


Pedro Martos

Correo electrónico

3.2 Cantidad de

horas


Pedro Martos

Correo electrónico

3.3 Adquisición de

señal de prueba


Pedro Martos

Correo electrónico

Página 23 de 25




SEGUIMIENTO DE AVANCE

Tarea del WBS

Indicador de avance

Frecuencia de reporte

Responsable de seguimiento

Persona a ser informada

Método de comunicac.

4.1 Software Semanalmente Juan Pablo Tettamanti

Pedro Martos

Correo electrónico

4.2 Documentación

de usuario


Pedro Martos

Correo electrónico

5.1 Cantidad de

funcionalidades

implementadas


Pedro Martos

Correo electrónico

5.2 Porcentaje de

funciones

documentadas


Pedro Martos

Correo electrónico

6.1 Cantidad de

pruebas

realizadas


Pedro Martos

Correo electrónico

6.2 Porcentaje de

pruebas

documentadas


Pedro Martos

Correo electrónico

Página 24 de 25




23. Procesos de cierre Reunión de cierre El Ing. Juan Pablo Tettamanti liderará un análisis sobre el Proyecto con el fin de extraer las soluciones encontradas a problemas relevantes, las lecciones aprendidas durante el mismo y las oportunidades de mejora futura. Luego de finalizada la reunión, el Responsable del Proyecto elaborará una nota de reunión con las lecciones aprendidas que se distribuirá por email a todos los participantes. Entrega de su memoria escrita del proyecto El Ing. Juan Pablo Tettamanti procederá a entregar una memoria escrita que detalle claramente los resultados obtenidos. Presentación pública y defensa El Ing. Juan Pablo Tettamanti realizará la defensa pública del mismo frente a un jurado previamente establecido. Acto de agradecimiento a los involucrados El Ing. Juan Pablo Tettamanti será el encargado de agradecer al Cliente, al equipo de trabajo y a los colaboradores del Proyecto a través de una reunión final de cierre. El Auspiciante financiará los gastos de dicha reunión.

Página 25 de 25

GNU Radio FMCOMMS1 -...

Documents

Transcript of GNU Radio FMCOMMS1 -...