Back end GPS. Esp. Ing. Facundo Santiago Larosa. Ing. Nicolás Álvarez (FIUBA, UNSAM)

Transcripción

1 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 Página 1 de 23

2 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 Desglose del trabajo en tareas Diagrama de Activity On Node Diagrama de Gantt Matriz de uso de recursos de materiales Presupuesto detallado del proyecto Matriz de asignación de responsabilidades Gestión de riesgos Gestión de la calidad Comunicación del proyecto Gestión de Compras Seguimiento y control Procesos de cierre 22 Página 2 de 23

3 Registros de cambios Revisión Detalle de los cambios realizados Fecha 1.0 Creación del documento 15/03/ Corrección del documento en base a las indicaciones de Ariel Lutenberg Corrección del documento en base a las indicaciones de Ariel Lutenberg 29/03/ /03/2017 Página 3 de 23

4 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 $ ,00 con fecha de inicio sábado 4 de marzo de 2017 y fecha de presentación pública lunes 4 de diciembre de Se adjunta a esta acta la planificación inicial. Ariel Lutenberg Director de la MSE-FIUBA Facundo Larosa Universidad Tecnológica Nacional Facultad Regional Haedo Nicolás Álvarez Director del Trabajo Final Juan Manuel Cruz Jurado del Trabajo Final Edgardo Comas Jurado del Trabajo Final Héctor Lacomi Jurado del Trabajo Final Página 4 de 23

5 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 5 de 23

6 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 6 de 23

7 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 7 de 23

8 á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. Subsistema de sincronización de reloj de entrada Subsistema de búsqueda Subsistema de seguimiento Subsistema de pruebas y comunicació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 Arquitectura: El sistema contará mínimamente con los siguientes subsistemas: 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 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 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 Página 8 de 23

9 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) 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 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) Bits de señal de entrada: Frecuencia de señal de entrada: fc=16,368 MHz Frecuencia intermedia: fi=4,092mhz Dominio de búsqueda de la frecuencia de portadora: fi 6000 Hz Dominio de búsqueda del código C/A: [0,1023] chips (el código es periódico) Intervalo de frecuencia (bin) (máximo): 500 Hz Tiempo máximo de búsqueda (locking) (máximo): 3 minutos 2.3. Módulo de seguimiento (tracking) 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 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 9 de 23

10 5. Entregables principales del proyecto 1. Documentación del sistema y subsistemas que incluya: Plan de Proyecto del Trabajo Final de la 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 10 de 23

11 6. Desglose del trabajo en tareas Plan de Proyecto del Trabajo Final de la Código EDT Nombre de tarea Duración (horas) Fase I: Front End Estudio, caracterización y pruebas de front end GPS Diseño e implementación de módulo de adquisición de señales crudas Algoritmos para procesamiento de señales crudas Documentación de pruebas front end 20 Fase II: Módulo de búsqueda Diseño de interfaz SPI para módulo de búsqueda Prueba de módulo de búsqueda con señales sintéticas Prueba de módulo de búsqueda con señales reales Documentación de pruebas de módulo de búsqueda 20 Fase III: Módulo de seguimiento Diseño y simulación del lazo de control para módulo de seguimiento en base a señales reales Diseño de interfaz SPI para módulo de seguimiento Implementación del lazo de control para módulo de seguimiento Prueba de módulo de tracking con señales sintéticas Prueba de módulo de tracking con señales reales Documentación de pruebas de módulo de seguimiento 20 Fase IV: Cierre Confección de documentación general y específica Redacción memoria del trabajo final Redacción paper Diagramación de diapositiva para exposición 20 Total 680 Página 11 de 23

12 7. Diagrama de Activity On Node Fase 1 Front End (20hs) 2.1 (20hs) (20hs) Fase 2 Módulo de búsqueda 4.2 (80hs) (20hs) 4.4 (20hs) Página 12 de 23

13 8. Diagrama de Gantt Tabla de tareas Página 13 de 23

14 Fase I Front End GPS Fase II Módulo de búsqueda Fase III Módulo de seguimiento Fase IV - Cierre Página 14 de 23

15 9. Matriz de uso de recursos de materiales Plan de Proyecto del Trabajo Final de la 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 x Módulo de búsqueda x Módulo de seguimiento x Cierre Total proyecto Presupuesto detallado del proyecto N Descripción Costo unitario Cantidad Costo total 1 Horas hombre 200 $/hora 680 horas $ ,00 2 Amortización equipos $20/hora 840 horas $16.800,00 Subtotal costos directos $ ,00 3 Costos indirectos aproximados - - $45.840,00 (30% costos directos) Subtotal costos indirectos $15.280,00 Total proyecto $ ,00 Página 15 de 23

16 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 16 de 23

17 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 17 de 23

18 12.2 Ponderación de riesgos Riesgo Descripción S O D RPN S* O* D * RPN* 1 Falta de kit Falta de capacidad hardware 3 No cumplir requerimientos 4 No cumplir plazos Falta de recursos humanos 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 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 18 de 23

19 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 19 de 23

20 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) Fase I: Front End Estudio, caracterización y pruebas de front end GPS Diseño e implementación de módulo de adquisición de señales crudas Algoritmos para procesamiento de señales crudas Documentación de pruebas front end 20 Fase II: Módulo de búsqueda Diseño de interfaz SPI para módulo de búsqueda Prueba de módulo de búsqueda con señales sintéticas Prueba de módulo de búsqueda con señales reales Documentación de pruebas de módulo de búsqueda Fase III: Módulo de seguimiento 260 Diseño y simulación del lazo de control para módulo de seguimiento en base a señales reales 3.2 Diseño de interfaz SPI para módulo de seguimiento Implementación del lazo de control para módulo de seguimiento 3.4 Prueba de módulo de tracking con señales sintéticas Prueba de módulo de tracking con señales reales Documentación de pruebas de módulo de seguimiento 20 4 Fase IV: Cierre Confección de documentación general y específica Redacción memoria del trabajo final Redacción paper Diagramación de diapositiva para exposición 20 Total 680 Página 20 de 23

21 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 Jurado de tesis, director de proyecto, director MSE Poner en conocimiento de los interesados el estado del proyecto Única vez Correo electrónico Facundo Larosa Memoria de proyecto final Jurado de tesis, director de proyecto, director MSE Poner en conocimiento de los interesados la memoria del proyecto final a los efectos de su evaluación Única vez Correo electrónico Facundo Larosa 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 21 de 23

22 15. Gestión de Compras Plan de Proyecto del Trabajo Final de la 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 Frecuenci a de reporte Responsable de seguimiento Persona a ser informad a Método de comunicació n Fase I: Front End 140 % Estudio, caracterización y pruebas de front end GPS 40 % Diseño e implementación de módulo de adquisición de señales crudas 40 % Algoritmos para procesamiento de señales crudas 40 % Semanal Facundo Larosa (Director) Correo electrónico / Reunión 1.4 Documentación de pruebas front end 20 % Fase II: Módulo de búsqueda 140 % 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 % Cada dos semanas Facundo Larosa (Director) Correo electrónico / Reunión Fase III: Módulo de seguimiento 260 % Diseño y simulación del lazo de control para módulo de seguimiento en base a señales reales 80 % Diseño de interfaz SPI para módulo de seguimiento 40 % Implementación del lazo de control para módulo de seguimiento 40 % Prueba de módulo de tracking con señales sintéticas 40 % Cada dos semanas Facundo Larosa (Director) Correo electrónico / Reunión 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 % Fase IV: Cierre 140 % Confección de documentación general y específica 4.2 Redacción memoria del trabajo final 80 % 4.3 Redacción paper 20 % 20 % Cada dos semanas Facundo Larosa (Director) Correo electrónico / Reunión 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 22 de 23

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. Página 23 de 23