Back end GPS - Investigación | FIUBAlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-MSE-Facundo... · Esp. Ing. Facundo Larosa Página 4 23de Acta de Constitución del Proyecto

Plan de Proyecto del Trabajo Final de la

Maestría de Sistemas Embebidos

Esp. Ing. Facundo Larosa

Página 1 de 23

Back end GPS

Autor

Esp. Ing. Facundo Santiago Larosa

Director del trabajo

Ing. Nicolás Álvarez (FIUBA, UNSAM)

Jurado propuesto para el trabajo

- Ing. Juan Manuel Cruz (FIUBA, UTN)

- Ing. Edgardo Comas (CITEDEF, UTN)

- Dr. Ing. Héctor Lacomi (CITEDEF, UTN)

Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de la

Tecnología y la Innovación entre febrero y marzo de 2017.




Página 2 de 23

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 6

2. Alcance del proyecto 7

3. Supuestos del proyecto 7

4. Requerimientos 7

5. Entregables principales del proyecto 10

6. Desglose del trabajo en tareas 10

7. Diagrama de Activity On Node 12

8. Diagrama de Gantt 12

9. Matriz de uso de recursos de materiales 14

10. Presupuesto detallado del proyecto 15

11. Matriz de asignación de responsabilidades 16

12. Gestión de riesgos 16

13. Gestión de la calidad 19

14. Comunicación del proyecto 21

15. Gestión de Compras 21

16. Seguimiento y control 22

17. Procesos de cierre 22




Página 3 de 23

Registros de cambios

Revisión Detalle de los cambios realizados Fecha

1.0 Creación del documento 15/03/2017

2.0 Corrección del documento en base a las indicaciones de Ariel

Lutenberg 29/03/2017

3.0 Corrección del documento en base a las indicaciones de Ariel

Lutenberg 30/03/2017




Página 4 de 23

Acta de Constitución del Proyecto

Buenos Aires, 15 de marzo de 2017

Por medio de la presente se acuerda con el Sr. Facundo Larosa que su Proyecto Final de la Maestría

en Sistemas Embebidos se titulará “Back end GPS”, consistirá esencialmente en el prototipo preliminar de

un backend GPS sobre FPGA, y tendrá un presupuesto preliminar estimado de 600 hs de trabajo y

$198.640,00 con fecha de inicio sábado 4 de marzo de 2017 y fecha de presentación pública lunes 4 de

diciembre de 2017.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg Facundo Larosa

Director de la MSE-FIUBA Universidad Tecnológica Nacional

Facultad Regional Haedo

Nicolás Álvarez

Director del Trabajo Final

Juan Manuel Cruz Edgardo Comas

Jurado del Trabajo Final Jurado del Trabajo Final

Héctor Lacomi

Jurado del Trabajo Final




Página 5 de 23

Descripción técnica-conceptual del proyecto a realizar

La necesidad del desarrollo de un receptor GPS avanzado definido por software radica en la necesidad de implementar sistemas de navegación de altas prestaciones. Por ejemplo, los receptores comerciales estándares si bien suelen ser suficientes para aplicaciones donde una frecuencia de muestreo de una vez por segundo es apropiada y otros parámetros (mensajes de navegación, pseudorangos, etc.) no son necesarios, esto deja fuera de la zona de aplicación el uso de receptores GPS en áreas clave tales como: sistemas espaciales (lanzadores y satélites), geodesia, sistemas autónomos (UAV), etc.

Un receptor GPS avanzado permite mayores tasas de refresco de solución, además de fuentes adicionales de datos, por ejemplo, los pseudorangos de los satélites, los cuales pueden utilizarse para implementar algoritmos más precisos (tales como los llamados de acoplamiento fuerte) en combinación con sensores inerciales. Adicionalmente, los receptores comerciales estándares están sujetos a limitaciones autoimpuestas bajo ciertas condiciones de altura y velocidad.

Simplificando el problema, se puede decir que para la construcción de un GPS de las características mencionadas se pueden utilizar componentes específicamente diseñados al efecto o bien componentes genéricos. Dependiendo de cuál sea el caso, si se utilizan componentes genéricos, se requerirá una mayor inversión en tiempo de investigación y desarrollo que en el caso de usar componentes específicos, con la ventaja de lograr una mayor flexibilidad en el diseño de la arquitectura y mayor facilidad en la adquisición de los componentes.

El desarrollo propuesto es una buena base la cual puede ser mejorada para realizar plataformas de navegación integradas que incluyan navegación inercial e incluso otros sistemas de posicionamiento satelital tales como GLONASS, Galileo y Beidou.

Dada la naturaleza del proyecto, la mayor dificultad radica en la cantidad de horas hombre necesarias para el desarrollo, la alta calificación de los recursos necesarios y la amplia variedad y profundidad de conocimientos requeridos (diseño de circuitos impresos de alta velocidad, diseño de sistemas digitales por medio de lenguajes de descripción de hardware, sistemas microcontrolados, navegación, señales mixtas, sistemas de comunicaciones, circuitos de radiofrecuencia, etc.).

Como contrapartida, la complejidad del desarrollo, es a su vez un marco excelente para la generación de capacidades técnicas que en otros proyectos se darían de forma aislada o incompleta, favoreciendo la formación de recursos humanos dentro del ámbito universitario, complementando la formación de grado y de posgrado del grupo de trabajo.

Aunque la innovación implicada mayormente se centra en el producto (el receptor en sí), el empleo de técnicas adecuadas de gestión de proyectos, de gestión de la información (utilizando herramientas de versionado), de técnicas de patrones de diseño de software, entre otras, permiten mejorar el proceso de desarrollo en sí para el presente y futuros proyectos del grupo de trabajo.




Página 6 de 23

Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante Carlos González Ingeniería Electrónica –

UTN Haedo Director

Cliente Edgardo Fernández

Vescovo

Ingeniería Aeronáutica –

UTN Haedo Director

Impulsor Edgardo Fernández

Vescovo

Ingeniería Aeronáutica –

UTN Haedo Director

Responsable Facundo Larosa Ingeniería Electrónica –

UTN Haedo Investigador

Colaboradores Anibal Guanca Ingeniería Electrónica –

UTN Haedo Docente

Orientadores Pedro Martos

Nicolás Álvarez

Ingenieria Electrónica -

FIUBA

Docente CESE-

FIUBA

Equipo Facundo Larosa Ingeniería Electrónica –

UTN Haedo Investigador

Usuario Final UTN Haedo Ingeniería Electrónica /

Ingeniería Aeronáutica




Página 7 de 23

1. Propósito del proyecto

El propósito del proyecto es diseñar, implementar y simular un módulo de hardware necesario para la

implementación de un receptor GPS definido por software. Los receptores definidos por software

tienen como ventaja un tipo de implementación más flexible lo cual permite el agregado de

funcionalidades específicas para cada aplicación (por ejemplo, filtrado digital, integración con otros

dispositivos para utilizar técnicas de navegación avanzadas, etc.). Esto resulta de gran interés para el

desarrollo de sistemas que integran navegación por satélites, tales como sistemas de aumentación

(SBAS, GBAS) o sistemas de navegación integrada con sensores para diferentes plataformas.

2. Alcance del proyecto

El proyecto incluye:

1. Estudio, caracterización y pruebas de front end GPS

2. Diseño e implementación de módulo de adquisición de señales crudas

3. Análisis de señales crudas

4. Diseño de interfaz SPI para módulo de búsqueda

5. Prueba de módulo de búsqueda con señales sintéticas

6. Prueba de módulo de búsqueda con señales reales

7. Documentación de pruebas de módulo de búsqueda

8. Diseño del lazo de control para módulo de tracking en base a señales reales

9. Diseño de interfaz SPI para módulo de tracking

10. Implementación del lazo de control para módulo de tracking

11. Prueba de módulo de tracking con señales sintéticas

12. Prueba de módulo de tracking con señales reales

13. Documentación de pruebas de módulo de tracking

Exclusiones:

1. Operaciones y algoritmos de posicionamiento de satélites en base al contenido del mensaje de

navegación

3. Supuestos del proyecto

1. Se supone que el desarrollo es factible en base a bibliografía específica de la temática

2. Se supone que el equipo de trabajo será capaz de alcanzar un grado suficiente del dominio

del problema y de las técnicas que permitan implementar las soluciones en el marco de la

Maestría en Sistemas Embebidos

3. Se supone que la línea de trabajo actual tendrá una prioridad alta en el desarrollo de las

tareas de la organización

4. Requerimientos

A fin de detallar los requerimientos se propone un desglose en subsistemas básicos que implementan

las funcionalidades del sistema global y permiten organizar los requisitos funcionales mínimos por




Página 8 de 23

área. La arquitectura del sistema, tal como se aprecia en la Figura 1, puede variar durante el desarrollo

del proyecto, pero sin importar la implementación final, deberá poder trazarse sus funcionalidades

asegurando la cobertura total de los requerimientos propuestos a continuación.

Figura 1 – Desglose de subsistemas propuesto

Generales

1.1. Operación: El sistema recibirá a su entrada una señal GPS en banda L1 (sintética o real) que

envíe información de uno o más satélites desconocidos, cuya frecuencia central y

desplazamiento de su código C/A (código pseudoaleatorio de decorrelación) se desconocen a

priori (el intervalo posible de ambas cantidades se aclara en el punto 2.2), convenientemente

preamplificada, filtrada, convertida a frecuencia intermedia (fi) y digitalizada. El sistema será

capaz de hallar la frecuencia de portadora y desplazamiento del código C/A, mantener la

sincronización del canal y obtener el mensaje de navegación para dicho satélite.

1.2. Arquitectura: El sistema contará mínimamente con los siguientes subsistemas:

1.2.1. Subsistema de sincronización de reloj de entrada

La función de este módulo será evitar los estados no estables de entrada debidos a la

desincronización y diferencia de frecuencias del reloj de entrada y el reloj del sistema.

1.2.2. Subsistema de búsqueda (search)

La función de este módulo será la de hallar durante la inicialización del módulo la

frecuencia de portadora y fase de código C/A para un satélite determinado y alimentar

con estos datos al módulo de seguimiento

1.2.3. Subsistema de seguimiento (tracking)

La función de este módulo será la de mantener la sincronización del generador de

portadora y código C/A interno con el de un satélite determinado a partir de los datos

iniciales recibidos por el módulo de búsqueda

Subsistema de sincronización

de reloj de entrada

Subsistema de búsqueda

Subsistema de seguimiento

Subsistema de pruebas y

comunicación




Página 9 de 23

1.2.4. Subsistema de pruebas y comunicación

La función de este módulo será la de proveer información del estado del sistema a través

de alguna interfaz a definir (probablemente SPI)

1.2.5. Plataforma: La plataforma de hardware para la implementación será una FPGA Xilinx

Spartan 3E500 o una Xilinx XC6SLX16

2. Específicos

2.1. Módulo de sincronización de reloj de entrada

2.1.1. Este módulo debe evitar la posibilidad de que existan estados metaestables de datos a

la entrada del módulo de búsqueda

2.2. Módulo de búsqueda (search)

2.2.1. Bits de señal de entrada: 1

2.2.2. Frecuencia de señal de entrada: fc=16,368 MHz

2.2.3. Frecuencia intermedia: fi=4,092MHz

2.2.4. Dominio de búsqueda de la frecuencia de portadora: fi 6000 Hz

2.2.5. Dominio de búsqueda del código C/A: [0,1023] chips (el código es periódico)

2.2.6. Intervalo de frecuencia (bin) (máximo): 500 Hz

2.2.7. Tiempo máximo de búsqueda (locking) (máximo): 3 minutos

2.3. Módulo de seguimiento (tracking)

2.3.1. El módulo no deberá perder sincronización de la frecuencia de portadora y fase del

código C/A ante variaciones de la señal de entrada correspondientes con el movimiento

de un satélite de la constelación GPS y un receptor cuasiestacionario

2.3.2. El módulo debe proveer a la salida el mensaje de navegación binario

2.4. Módulo de pruebas y comunicación

El módulo de pruebas deberá proveer información a través de una interfaz (problemente

SPI) y una trama de datos (a definir) del estado de cada subsistema.

Todos los requerimientos precedentes son mandatorios salvo que se indique lo contrario. En caso de

que durante el proceso de desarrollo se verificase que no pudiera cumplirse alguno de ellos deberá

generarse un reporte sobre la limitación encontrada. De esta manera se podrá explorar la aplicación

de algún mecanismo de mitigación que pudiera ser necesario, o la flexibilización del requerimiento en

conjunto con los interesados (cliente, colaboradores, etc.).




Página 10 de 23

5. Entregables principales del proyecto

1. Documentación del sistema y subsistemas que incluya:

a. Descripción de entradas y salidas (frecuencias, tamaño y tipos de datos, señales de

control, etc.)

b. Descripción de parámetros del sistema

c. Requerimientos funcionales implementados trazables a los requerimientos del

proyecto

d. Hipótesis de diseño, justificación de la elección del diseño, estudios previos y marco

teórico (si aplica)

e. Diagrama de arquitectura

f. Reporte de ensayos realizados

g. Referencias bibliográficas

2. Publicación (paper) en formato IEEE para ser presentada en un congreso de la especialidad




Página 11 de 23

6. Desglose del trabajo en tareas

Código

EDT Nombre de tarea

Duración

(horas)

1

Fase I: Front End 140

1.1 Estudio, caracterización y pruebas de front end GPS 40

1.2 Diseño e implementación de módulo de adquisición de

señales crudas 40

1.3 Algoritmos para procesamiento de señales crudas 40

1.4 Documentación de pruebas front end 20

2

Fase II: Módulo de búsqueda 140

2.1 Diseño de interfaz SPI para módulo de búsqueda 40

2.2 Prueba de módulo de búsqueda con señales sintéticas 40

2.3 Prueba de módulo de búsqueda con señales reales 40

2.4 Documentación de pruebas de módulo de búsqueda 20

3

Fase III: Módulo de seguimiento 260

3.1 Diseño y simulación del lazo de control para módulo de

seguimiento en base a señales reales 80

3.2 Diseño de interfaz SPI para módulo de seguimiento 40

3.3 Implementación del lazo de control para módulo de

seguimiento 40

3.4 Prueba de módulo de tracking con señales sintéticas 40

3.5 Prueba de módulo de tracking con señales reales 40

3.6 Documentación de pruebas de módulo de seguimiento 20

4

Fase IV: Cierre 140

4.1 Confección de documentación general y específica 20

4.2 Redacción memoria del trabajo final 80

4.3 Redacción paper 20

4.4 Diagramación de diapositiva para exposición 20

Total 680




Página 12 de 23

7. Diagrama de Activity On Node

1.1(40hs)

1.2(40hs)

1.3(40hs)

2.1(20hs)

Fase 1Front End

Fase 2Módulo de búsqueda

1.4(20hs)

2.3(40hs)

2.2(40hs)

2.4(20hs)

3.1(40hs)

3.2(40hs)

3.3(40hs)

3.4(40hs)

3.5(40hs)

3.6(40hs)

4.1(40hs)

4.2(80hs)

4.3(20hs)

4.4(20hs)




Página 13 de 23

8. Diagrama de Gantt

Tabla de tareas




Página 14 de 23

Fase I – Front End GPS

Fase II – Módulo de búsqueda

Fase III – Módulo de seguimiento

Fase IV - Cierre




Página 15 de 23

9. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea Duración de la tarea

[horas]

Equipos requeridos [horas]

PC Kit FPGA Nexys 2

1.x Front End 140 100 100

2.x Módulo de búsqueda 140 100 100

3.x Módulo de

seguimiento 260 200 100

4.x Cierre 140 140 0

Total proyecto 680 540 300

10. Presupuesto detallado del proyecto

N° Descripción Costo unitario Cantidad Costo total 1 Horas hombre 200 $/hora 680 horas $136.000,00 2 Amortización equipos $20/hora 840 horas $16.800,00

Subtotal costos directos $152.800,00 3 Costos indirectos aproximados

(30% costos directos) - - $45.840,00

Subtotal costos indirectos $15.280,00 Total proyecto $198.640,00




Página 16 de 23

11. Matriz de asignación de responsabilidades

Código WBS

Título de la tarea F. Larosa

Responsable

N. Álvarez Cliente

E. Fernández V.

Impulsor

Carlos González

Auspiciante

Pedro Martos

Colaborador

A. Guanca Orientador

1.x Front end GPS P A I I C C

2.x Módulo de búsqueda P A I I C C

3.x Módulo de

seguimiento P A I I C C

4.x Cierre P A I I C C

Referencias: P = Responsabilidad Primaria

S = Responsabilidad Secundaria A = Aprobación I = Informado C = Consultado

12. Gestión de riesgos 12.1 Identificación de riesgos A continuación se desarrollan los riesgos identificados y el análisis efectuado sobre los mismos.

Riesgo 1: No disponer de kit de desarrollo (Nexys 2) por rotura o pérdida

Severidad (S): 9(nueve) La severidad es alta ya que no se podrán realizar pruebas básicas.

Probabilidad de ocurrencia(O): 3(tres) La probabilidad es relativamente baja ya que el kit será utilizado sólo por el desarrollador.

Tasa de no detección (D): 10 (diez) La tasa de no detección es alta, ya que tanto en el caso de pérdida o rotura es muy difícil de preveer.

Riesgo 2: Que la FPGA que se dispone (Spartan 3E) no cuente con la capacidad suficiente para implementar el módulo objeto del proyecto

Severidad (S): 7(siete) La severidad es media-alta, ya que no se podrá implementar el módulo completo.




Página 17 de 23

Probabilidad de ocurrencia(O): 4(cuatro) La probabilidad es media-baja ya que en base a la bibliografía se puede presumir que se han implementado módulos similares sobre este tipo de plataformas.

Tasa de no detección (D): 9 (nueve) La tasa de no detección es alta, ya que no se conoce a priori y no es sencillo preveer la complejidad de los circuitos a implementar

Riesgo 3: No cumplir con los requerimientos técnicos planteados (sección 4)

Severidad (S): 5(cinco) La severidad es media ya que tratándose de un desarrollo existe la posibilidad de que sea necesario bajar las expectativas en base a los requerimientos estrictamente propuestos.

Probabilidad de ocurrencia(O): 9(nueve) La probabilidad es alta ya que las especificaciones planteadas son en realidad, cotas de máxima

Tasa de no detección (D): 9 (nueve) La probabilidad es alta ya que no se conocen a priori detalles de la implementación que permitan preveer si se va o no a cumplir con las especificaciones.

Riesgo 4: No cumplir con plazos planteados (sección 8)

Severidad (S): 10 (diez)

La severidad es máxima ya que no se podrá presentar el proyecto en el plazo acordado y finalizar la especialización.

Probabilidad de ocurrencia(O): 7(siete) La probabilidad es media-alta ya que a menudo, los proyectos que involucran desarrollos requieren de mayor cantidad de horas de lo previsto.

Tasa de no detección (D): 7 (siete) La tasa de no detección es media-alta, ya que en proyectos de desarrollo, especialmente donde no media una gran experiencia técnica en el área resulta difícil evaluar el corrimiento de plazos a priori.

Riesgo 5: Falta de tiempo de recursos humanos por contingencias ajenas al proyecto

Severidad (S): 9 (nueve) La severidad es alta ya que el tiempo es un recurso fundamental para el desarrollo de este proyecto.

Probabilidad de ocurrencia(O): 4(cuatro) La probabilidad es media-baja ya que se prevee una alta dedicación al proyecto

Tasa de no detección (D): 5 (cinco) La tasa de no detección es media ya que si bien ante imprevistos puntuales puede preveerse la falta de tiempo, por la naturaleza misma del proyecto podría llegar a ser necesario invertir más horas de lo previsto.




Página 18 de 23

12.2 Ponderación de riesgos

Riesgo Descripción S O D RPN S* O* D * RPN*

1 Falta de kit 9 3 10 270 2 3 10 60

2 Falta de capacidad hardware

7 4 9 252 2 4 9 72

3 No cumplir requerimientos

5 9 9 405 3 9 6 162

4 No cumplir plazos

10 7 7 490 10 3 3 90

5 Falta de recursos humanos

9 4 5 180

Criterio adoptado: se tomarán medidas de mitigación para aquellos riesgos cuyo RPN supere 200. Nota: Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación.

12.3 Plan de mitigación de riesgos

Riesgo 1: No disponer de kit de desarrollo (Nexys 2) por rotura o pérdida Medida de mitigación: Se dispondrá de un kit de repuesto facilitado por colegas en el lapso de tiempo que se necesite para adquirir un kit nuevo. De esta forma se reduce la severidad del riesgo de 9 (nueve) a 2 (dos).

Severidad (S): 2(dos) La severidad es baja ya que se dispone de una alternativa para continuar el trabajo.

Probabilidad de ocurrencia(O): 3(tres) La probabilidad es relativamente baja ya que el kit será utilizado sólo por el desarrollador.

Tasa de no detección (D): 10 (diez) La tasa de no detección es alta, ya que tanto en el caso de pérdida o rotura es muy difícil de preveer.

Riesgo 2: Que la FPGA que se dispone (Spartan 3E 500) no cuente con la capacidad suficiente para implementar el módulo objeto del proyecto Medida de mitigación: Se dispone de la posibilidad de utilizar un kit alternativo que cuenta con una Spartan XC6LX16 (de mayor capacidad). De esta forma, la severidad se reduce de 7 (siete) a 2 (dos).

Severidad (S): 2(dos) La severidad es baja ya que se dispone de una alternativa de mayor capacidad.

Probabilidad de ocurrencia(O): 4(cuatro) La probabilidad es media-baja ya que en base a la bibliografía se puede presumir que se han implementado módulos similares sobre plataformas similares.

Tasa de no detección (D): 9 (nueve) La tasa de no detección es alta, ya que no se conoce a priori y no es sencillo preveer la complejidad de los circuitos a implementar




Página 19 de 23

Riesgo 3: No cumplir con los requerimientos técnicos planteados (sección 4) Medida de mitigación: Se prestará especial atención al cumplimiento de los requerimientos técnicos desde el inicio de la etapa de implementación a fin de explicitar las posibles razones que pudieran causar acotar los requerimientos técnicos. Se informará posibles cursos de solución para alcanzar los requisitos originales de máxima. De esta forma, disminuyen la severidad (se dejarán expresadas las posibles soluciones), y la tasa de no detección (análisis temprano de la situación).

Severidad (S): 3(tres)

La severidad es media-baja ya que si bien podría no cumplirse con los requisitos de máxima del proyecto, por tratarse de un proyecto de desarrollo el análisis de las dificultades encontradas será de gran ayuda en las etapas de mejora que eventualmente se produzcan a futuro.

Probabilidad de ocurrencia(O): 6 (seis) La probabilidad es alta ya que las especificaciones planteadas son en realidad, cotas de máxima

Tasa de no detección (D): 6 (seis) La probabilidad es media ya que se prestará especial atención a los requerimientos planteados desde el inicio de la etapa de implementación.

Riesgo 4: No cumplir con plazos planteados (sección 8) Plan de mitigación: Se trabajará en base a la planificación para predecir tempranamente desvíos y tomar las medidas necesarias para corregirlos, por ejemplo, dedicar horas adicionales, buscar el consejo de especialistas, etc. De esta manera, se reduce tanto la probabilidad de ocurrencia como la tasa de no detección.

Severidad (S): 10 (diez) La severidad es máxima ya que no se podrá presentar el proyecto en el plazo acordado y finalizar la especialización.

Probabilidad de ocurrencia(O): 3(tres) La probabilidad es media-baja ya que se dispondrán de mecanismos para dedicar más horas al proyecto, contar con el consejo de especialistas, etc.

Tasa de no detección (D): 3 (tres) La tasa de no detección es media-baja ya que se evaluará de forma continua desvíos del plan original a fin de detectar tempranamente una posible extensión de plazo.




Página 20 de 23

13. Gestión de la calidad

13.1 Verificación La verificación de cada una de las fases principales se dará a través de las pruebas previstas en cada una de las etapas principales. En la tarea 1.3 se procesarán las muestras adquiridas a partir del front end GPS y se evaluará que las señales de frecuencia intermedia reflejen las características de una señal GPS en frecuencia intermedia. En las tareas 2.2 y 2.3 se evaluará el comportamiento del módulo de búsqueda utilizando señales sintéticas (señales generadas artificialmente mediante un módulo propio en la FPGA) y reales (señales adquiridas a través del front end). En las tareas 3.4 y 3.5 se evaluará el comportamiento del módulo de seguimiento utilizando señales reales y sintéticas.

Código EDT Nombre de tarea Duración (horas)

1

Fase I: Front End 140

1.1 Estudio, caracterización y pruebas de front end GPS 40

1.2 Diseño e implementación de módulo de adquisición de señales

crudas 40

1.3 Algoritmos para procesamiento de señales crudas 40

1.4 Documentación de pruebas front end 20

2

Fase II: Módulo de búsqueda 140

2.1 Diseño de interfaz SPI para módulo de búsqueda 40

2.2 Prueba de módulo de búsqueda con señales sintéticas 40

2.3 Prueba de módulo de búsqueda con señales reales 40

2.4 Documentación de pruebas de módulo de búsqueda 20

3

Fase III: Módulo de seguimiento 260

3.1 Diseño y simulación del lazo de control para módulo de

seguimiento en base a señales reales 80

3.2 Diseño de interfaz SPI para módulo de seguimiento 40

3.3 Implementación del lazo de control para módulo de

seguimiento 40

3.4 Prueba de módulo de tracking con señales sintéticas 40

3.5 Prueba de módulo de tracking con señales reales 40

3.6 Documentación de pruebas de módulo de seguimiento 20

4

Fase IV: Cierre 140

4.1 Confección de documentación general y específica 20

4.2 Redacción memoria del trabajo final 80

4.3 Redacción paper 20

4.4 Diagramación de diapositiva para exposición 20

Total 680




Página 21 de 23

13.2 Validación Por medio de las pruebas indicadas en el punto 13.1, se procederá a validar el comportamiento de los módulos diseñados durante la Especialización, a fin de corroborar su correcto funcionamiento tanto a través de señales generadas artificialmente, como de señales reales.

14. Comunicación del proyecto

PLAN DE COMUNICACIÓN DEL PROYECTO

¿Qué comunicar?

Audiencia Propósito Frecuencia Método de

comunicación Responsable

Plan de proyecto

Curso de Gestión de la Tecnología y

la Innovación

Compartir el tema de proyecto y las

estrategias de planificación

aplicadas

Única vez Presentación

privada Facundo Larosa

Plan de proyecto

Jurado de tesis, director de

proyecto, director MSE

Poner en conocimiento de los interesados el plan de proyecto

Única vez Correo

electrónico Facundo Larosa

Informe de avance



Poner en conocimiento de los interesados el

estado del proyecto

Única vez Correo


Memoria de proyecto final



Poner en conocimiento de los interesados la

memoria del proyecto final a los

efectos de su evaluación

Única vez Correo


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 Facundo Larosa

En este plan de comunicación se resumen los principales hitos de comunicación del proyecto. La comunicación referente al avance y estado de tareas se detalla en la sección 16 (Seguimiento y control).




Página 22 de 23

15. Gestión de Compras

El proyecto no posee un plan de adquisiciones, compras o contrataciones ya que se cuenta con los

elementos materiales necesarios (kits de desarrollo y PC) para su realización.

16. Seguimiento y control

Código EDT

Nombre de tarea Duraci

ón (horas)

Indicador de avance

Frecuencia de

reporte

Responsable de

seguimiento

Persona a ser

informada

Método de comunicació

n

1

Fase I: Front End 140 %

Semanal Facundo Larosa

(Director) Correo

electrónico / Reunión

1.1 Estudio, caracterización y pruebas de front end GPS 40 %

1.2 Diseño e implementación de módulo de adquisición de señales crudas 40 %

1.3 Algoritmos para procesamiento de señales crudas 40 %

1.4 Documentación de pruebas front end 20 %

2

Fase II: Módulo de búsqueda 140 %

Cada dos semanas

Facundo Larosa

(Director) Correo


2.1 Diseño de interfaz SPI para módulo de búsqueda 40 %

2.2 Prueba de módulo de búsqueda con señales sintéticas 40 %

2.3 Prueba de módulo de búsqueda con señales reales 40 %

2.4 Documentación de pruebas de módulo de búsqueda 20 %

3

Fase III: Módulo de seguimiento 260 %

Cada dos semanas

Facundo Larosa

(Director) Correo


3.1 Diseño y simulación del lazo de control para módulo de seguimiento en base a señales reales 80 %

3.2 Diseño de interfaz SPI para módulo de seguimiento 40 %

3.3 Implementación del lazo de control para módulo de seguimiento 40 %

3.4 Prueba de módulo de tracking con señales sintéticas 40 %

3.5 Prueba de módulo de tracking con señales reales 40 %

3.6 Documentación de pruebas de módulo de seguimiento 20 %

4

Fase IV: Cierre 140 %

Cada dos semanas

Facundo Larosa

(Director) Correo


4.1 Confección de documentación general y específica

20 %

4.2 Redacción memoria del trabajo final 80 %

4.3 Redacción paper 20 %

4.4 Diagramación de diapositiva para exposición 20 %

El avance de las tareas se indicará por porcentaje de completamiento según la siguiente escala:

0% : Tarea no comenzada

20% : Tarea iniciada

70% : Tarea completada con entregables en versión preliminar o código sin errores de

sintaxis, compilación, arquitectura, etc, sin documentación asociada.

90% : Tarea completada con documentación asociada en versión preliminar o pendiente

de revisión




Página 23 de 23

100%: Tarea finalizada

17. Procesos de cierre

Evaluación del plan de proyecto original Se evaluará el plan de proyecto original respecto del desempeño real con el objeto de sacar conclusiones que permitan a futuro mejores estimaciones respecto de:

Tiempo planificado para cada tarea Riesgos ocurridos, previstos o no previstos y efectividad de las medidas de mitigación

implementadas Imprecisiones, incertidumbres, malentendidos o errores de la comunicación entre los actores

del proyecto Retrabajos a consecuencia de, entre otros, especificaciones mal definidas, enfoques

incorrectos, etc. Exceso de horas extras, “cuellos de botella”, etc.

Aprobaciones formales Se gestionará y archivará la aprobación formal por parte del director de proyecto final, el jurado y el director de la Carrera de Especialización en Sistemas Embebidos (CESE) para realizar la presentación final.

Documents

Back end GPS - Investigación | FIUBAlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-MSE-Facundo... · Esp. Ing. Facundo Larosa Página 4 23de Acta de Constitución del Proyecto