Nodos WSN alimentados a energía solar con sistema delaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE-Juan... · Plan de Proyecto del Trabajo Final de Carrera de Especialización

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Esp. Ing. Juan Montilla

Nodos WSN alimentados a energía solar con sistema de monitoreo de salud.

Autor


Director del trabajo

Esp. Ing. Pedro Ignacio Martos

Jurado propuesto para el trabajo

- Esp. Ing. Leonardo Carducci (FIUBA) - Mg. Ing Augusto Maya (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 19




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 19




Registros de cambios

Revisión Cambios realizados Fecha

1.0 Creación del documento 04/11/2015

1.1 Primeras correcciones y completado hasta Matriz de asignación de responsabilidades

11/11/2015

1.2 Segundas correcciones y completado hasta Procesos de cierre.

25/11/2015

1.3 Gestión de riesgos y cambio de Orientador 25/11/2015

1.4 Terceras correcciones. Cambio de título, acta constitutiva, presupuesto preliminar y detallado, objetivos, alcance, requerimientos, WBS, AON y Gantt.

01/12/2015

1.5 Modificaciones del punto 15 en adelante para contemplar los nuevos requerimientos y tareas.

9/12/2015

Página 3 de 19




Acta Constitutiva

CABA, 4 de noviembre de 2015.

Attn Juan Montilla

De mi mayor consideración

Con el fin de brindar una solución preventiva a la falta de disponibilidad de nodos Mote LSE en

red inalámbrica de área personal debido a fallas de energía o temperatura de entorno extrema, se

propone desarrollar un software para la supervisión de dichos nodos y agregarle un circuito cargador

de batería a partir de un panel solar y se lo designa a Ud como Responsable del proyecto “Nodos WSN alimentados a energía solar con sistema de monitoreo de salud”, con un presupuesto total estimado de

600 horas hombre, 4 nodos Mote LSE, 2 LPC-Link y 1 panel solar de 12V x 0.5A (10W). Con fecha

tentativa de inicio Noviembre 2015 y de finalización Junio 2016.

Se adjunta a esta acta la planificación inicial.

Esp. Ing. Pedro Ignacio Martos

Docente de la Carrera de Especialización en Sistemas Embebidos - FIUBA

Página 4 de 19




1. Nombre del Proyecto Nodos WSN alimentados a energía solar con sistema de monitoreo de salud

2. Fecha de inicio y finalización del proyecto

El proyecto tiene como fecha de inicio el 26 de Noviembre de 2015 con finalización el 30 de Junio de 2016.

3. Presupuesto preliminar asignado

➢ 600 horas hombre. ➢ 4 Nodos Mote LSE. ➢ 2 LPC-Link. ➢ 2 paneles solares 12V x 0.5A (10W)

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

Rol Nombre y Apellido Departamento Puesto

Auspiciante LSE-FIUBA

Cliente Esp. Ing. Pedro Martos LSE Docente CESE

Impulsor Ing. Esp. Juan Montilla LSE Estudiante CESE

Responsable Ing. Esp. Juan Montilla LSE Estudiante CESE

Colaboradores Dr. Ing. Ariel Lutenberg LSE Director LSE-FIUBA

Orientadores Esp. Ing. Pedro Martos LSE Docente CESE

Equipo WSN Working Group LSE

Opositores No se conocen

Usuario Final WSN Working Group LSE

-Colaborador: Ariel Lutenberg, conductor y motivador. Pondrá todos los recursos a su alcance a disposición del proyecto.

-Orientador: Pedro Martos, muy bien predispuesto y accesible. Su contribución representa un aporte muy valioso al proyecto por su trayectoria como docente de la Carrera de Especialización de Sistemas Embebidos de la UBA.

Página 5 de 19




-Responsable: Juan Montilla, su participación en el proyecto requiere un balance de horas entre tareas laborales y académicas, contemplar el tiempo de licencias, ser exigente con los plazos de la planificación.

5. Propósito y Justificación del proyecto

El propósito de este proyecto es diseñar un sistema con la capacidad de monitorear y gestionar remotamente nodos respaldados con carga de batería a partir de paneles solares y distribuidos en redes LR-WPAN. Otro propósito es obtener el título de especialista en Sistemas Embebidos de la Facultad de Ingeniería de la Universidad de Buenos Aires.

La justificación de este proyecto es proponer una solución preventiva a la falta de disponibilidad debido a fallas de energía o temperatura de entorno de nodos Mote LSE con sistema autónomo de batería, que reporte alarmas de salud a un nodo central y tome acciones para el ahorro de energía.

La necesidad surge como complemento en el despliegue de nodos que soportan el protocolo 802.15.4.

6. Objetivos

1. Agregar al nodo Mote LSE un circuito cargador a partir de un panel solar. 2. Desarrollar un software de supervisión de nodos Mote LSE con extensión de panel solar. 3. Implementar el sistema en 4 nodos desplegados en una red inalámbrica de área personal. 4. Gestionar el modo de operación del nodo en función de la tensión que entrega el circuito

cargador y la proyección de la batería restante. 5. Supervisar la temperatura del entorno del nodo. 6. Reportar a un nodo central el estado de salud del nodo. 7. Fijar y leer en forma remota las alarmas/parámetros de configuración. 8. Presentar el trabajo final en junio de 2016.

7. Alcance del proyecto

Las especificaciones del proyecto se fundamentan para operar con los nodos Mote LSE con la extensión de un circuito cargador de la batería a partir de un panel solar.

El nodo será capaz de determinar el modo de operación entre batería y panel solar en función de la tensión que entrega el circuito cargador del panel y la proyección de batería restante.

Se desarrollará un sistema de monitoreo de salud de los nodos en red LR-WPAN.

Los cambios necesarios para soportar otro hardware no son incluidos en el proyecto.

Página 6 de 19




8. Supuestos y restricciones del proyecto

Entre los supuestos se considera que el comportamiento de todos los nodos se desplegará a lo largo de la red.

La restricción principal es que no es posible realizar pruebas o mediciones con más de 4 configuraciones de nodos a la vez, por lo cual se realizarán diferentes tareas de pruebas.

9. Requerimientos

1. Requerimientos de hardware: a. Compatibilidad con nodos Mote LSE. b. Agregar al nodo Mote LSE la extensión de circuito cargador a partir de panel solar de

12V x 0.5A (10W).

2. Requerimientos de software generales: a. El sistema de monitoreo debe poder trabajar con por lo menos 4 nodos. b. El sistema debe soportar topologías de tipo estrella, peer-to-peer y árbol de cluster. c. El nodo tendrá una memoria no volátil donde guarda los valores de alarma, los

parámetros monitoreados, el tiempo total de uso, y la cantidad de ciclos de carga/descarga.

d. Todas las alarmas/parámetros de configuración/estado del nodo deben poder fijarse y leerse en forma remota (prioridad alta).

e. El cambio de modos entre batería y panel solar lo hace el nodo en función de la tensión que entrega el panel solar; el nodo debe funcionar en modo panel solar todo lo posible.

f. La recarga de la batería la decide el nodo en función de la proyección de batería restante y la tensión que entrega el panel solar.

g. Los nodos deben monitorear en todo momento: i. Consumo de corriente. ii. Temperatura ambiente.

iii. Tensión que entrega el panel solar. iv. Modo de funcionamiento (batería/panel solar). v. Alarmas cuando la temperatura ambiente es mayor o menor a un determinado

valor (2 alarmas). vi. Tiempo total que lleva el nodo funcionando (se puede hacer con un reloj de

tiempo real). h. Los nodos en modo batería deben monitorear:

i. Salud de la batería (tensión, corriente y temperatura). ii. Proyección de batería restante (conociendo la batería y el consumo, estimar

cuánto tiempo de vida le queda al nodo). iii. Alarmas: Tiempo de vida proyectado del nodo menor a un nivel prefijado;

tensión de batería menor a un valor prefijado, corriente de la batería mayor a un valor prefijado, y temperatura de batería mayor a un valor prefijado.

i. Los nodos en modo panel solar deben monitorear: i. Estado del sistema de recarga (tensión y corriente que entrega el panel y

tensión, corriente y temperatura de la batería). ii. Tiempo restante estimado para recarga total de la batería.

Página 7 de 19




iii. Cantidad de ciclos de carga/descarga acumulados. iv. Si está recargando la batería.

j. Se debe implementar un algoritmo de ahorro de energía en los nodos en estado de alarma (prioridad baja).

3. Requerimientos de documentación y entregables: a. El manual de uso debe especificar los parámetros de red configurables para

implementar el sistema. b. Los diagramas de instalación debe contemplar las tres topologías posibles de acuerdo a

802.15.4. c. Se debe presentar un informe de avance del proyecto en una presentación pública ante

el jurado el 31 de marzo de 2016. d. Se debe presentar un trabajo final con la finalización del proyecto. Este es el

requerimiento de más alta prioridad.

10. Entregables principales del proyecto

➢ Diagramas de instalación. ➢ Actualización del proyecto ante el jurado. ➢ Manual de uso. ➢ Trabajo final.

11. Desglose del trabajo en tareas

1. Planificación del proyecto (40 hs)

2. Tareas de hardware (55 hs):

2.1. Análisis del hardware nodo Mote LSE y LPC-Link (20 hs).

2.2. Adaptación de circuito cargador a partir de panel solar (35 hs).

3. Tareas de software-topologías (40 hs):

3.1. Organizar los nodos en topología de tipo estrella (10 hs).

3.2. Organizar los nodos en topología de tipo peer-to-peer (10 hs).

3.3. Organizar los nodos en topología de tipo árbol de cluster (20 hs).

4. Tareas de software-memoria (25 hs):

4.1. Memoria no volátil (10 hs).

4.2. Escribir y leer en forma remota (15 hs).

5. Tareas de software-energía (60 hs):

5.1. Medir la tensión que entrega el panel solar (5 hs).

5.2. Cambio de modos (batería/panel) (10 hs).

5.3. Proyección de batería restante (20 hs).

5.4. Recarga de batería (25 hs).

6. Tareas de software-monitoreo (80 hs):

6.1. Medir consumo de corriente (5 hs).

6.2. Modo de funcionamiento (20 hs).

6.3. Medir temperatura ambiente (15 hs).

6.4. Alarmas de temperatura (2) (20 hs).

6.5. Medir tiempo de funcionamiento (20 hs).

Página 8 de 19




7. Tareas de software-batería (50 hs):

7.1. Salud de batería (20 hs).

7.2. Generar alarmas (4) (30 hs).

8. Tareas de software-panel (70 hs):

8.1. Estado del sistema de recarga (10 hs).

8.2. Medir tiempo restante estimado para recarga total de la batería (25 hs).

8.3. Cantidad de ciclos de carga/descarga acumulados (15 hs).

8.4. Estado de recarga (20 hs).

9. Tareas de software-ahorro (60 hs):

9.1. Identificar los posibles valores de configuración para los parámetros de red (10 hs).

9.2. Definir el ciclo útil y la periodicidad de los reportes para el modo ahorro (5 hs).

9.3. Definir las funcionalidades reducidas para el modo ahorro (10 hs).

9.4. Desarrollar el algoritmo de ahorro de energía (15 hs).

9.5. Pruebas software-ahorro (20 hs).

10. Tareas de software-integración (20 hs):

10.1. Integrar todas las funcionalidades de software (5 hs).

10.2. Pruebas software-integración (15 hs).

11. Tareas de documentación y entregables (80 hs):

11.1. Documentación de los diagramas de instalación (10 hs).

11.2. Documentación del informe de avance. (10 hs).

11.3. Documentación del manual de uso (20 hs).

11.4. Documentación del trabajo final (40 hs).

12. Procesos de cierre (20 hs).

12.1. Actualización del Gantt (4 hs)

12.2. Organización de la presentación pública(3 hs)

12.3. Documentación de lecciones aprendidas (4 hs)

12.4. Documentación de problemas y soluciones (4 hs)

12.5. Comparación de horas estimadas y empleadas (2 hs)

12.6. Organización de acto de agradecimiento (3 hs)

12. Análisis de factibilidad

LPCxpresso es un toolchain que está compuesto por un IDE basado en eclipse, compiler y linker GNU, GDB debugger y también una herramienta que incluye un programador y debugger (LPC-Link) que es usado para programar el nodo Mote LSE. Por tratarse de un proyecto académico, no se esperan flujos de ingreso ni se calculan flujos de egresos, ni demás indicadores. Debido a la factibilidad técnica de implementación y de recursos es posible realizar el proyecto.

Página 9 de 19




13. Diagrama de Activity On Node

Página 10 de 19




14. Diagrama de Gantt

15. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea

Recursos requeridos (horas)

Nodos Mote LSE

LPC-Link PC Panel solar

1 Planificación del

proyecto

0 0 40 0

Página 11 de 19




2 Hardware 0 0 55 0

3 Software-topologías 40 40 40 0

4 Software-memoria 25 25 25 0

5 Software-energía 60 60 60 60

6 Software-monitoreo 80 80 80 80

7 Software-batería 50 50 50 50

8 Software-panel 70 70 70 70

9 Software-ahorro 60 60 60 60

10 Software-integración 20 20 20 20

11 Documentación y

entregables

0 0 80 0

12 Procesos de cierre 0 0 20 0

Total 405 405 600 340

16. Presupuesto detallado del proyecto

Descripción Detalle Cantidad Importe Unitario en pesos

Importe en pesos

Gastos de desarrollo

Hora/Hombre 600 100 60.000

Gastos de equipamiento

Nodo Mote LSE 4 995 3.980

LPC-Link 2 200 400

Panel Solar 12V x 0.5A (10W)

2 500 1.000

Subtotal 65.380

Gastos extras 20% Subtotal 13.076

Página 12 de 19




Total 78.456

El costo del Nodo Mote LSE fue calculado sumando los importes del circuito impreso (Ernesto Mayer S.A.), los componentes (Digi-Key Electronics.) y el soldado de los mismos (Assisi S.R.L.). No contempla gastos de I+D. LPC-Link (Embedded Artists). Para el importe del Panel Solar se toma como referencia varios proveedores locales.

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 Montilla

Responsable

Pedro Martos Cliente

Ariel Lutenberg

Colaborador

Jurado

WSN Working Group

Usuario

1 Planificación del

proyecto

P A A

2 Hardware P A S

3 Software-topologías P A C

4 Software-memoria P A C

5 Software-energía P A C

6 Software-monitoreo P A C

7 Software-batería P A C

8 Software-panel P A C

9 Software-ahorro P A C

10 Software-integración P A C

11 Documentación y

entregables

P A A A

12 Procesos de cierre P I I I

Referencias: P = Responsabilidad Primaria

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

Página 13 de 19




18. Gestión de riesgos a) Identificación de los riesgos y estimación de sus consecuencias: - Riesgo 1: Fallas en el establecimiento de la comunicación entre los nodos por diversos aspectos. - Severidad: (7). Imposibilita la supervisión de los nodos bajo ese entorno o con esa configuración y hasta que sea modificado. - Probabilidad de ocurrencia: (7). Al operar en una banda libre no licenciada, la comunicación es muy propensa a sufrir interferencia. - Tasa de no detección: (4). Puede atribuirse a errores en la programación. - Riesgo 2: El hardware del Nodo Mote LSE sufre daños. - Severidad: (9). Tiene alto grado de severidad ya que es la plataforma de implementación del sistema. - Probabilidad de ocurrencia: (5). Debido a que se han detectado fallas en prácticas anteriores. - Tasa de no detección: (3). Ya que se implementa el mismo software en distintos nodos, si funciona correctamente en uno debe funcionar igual en los demás. Puede ser no detectable al atribuirle el error al software. - Riesgo 3: El hardware del LPC-Link sufre daños. - Severidad: (2). Es poco severo ya que es posible encontrar en el laboratorio del LSE o con otros compañeros. - Probabilidad de ocurrencia: (2). En base a la experiencia en las prácticas. - Tasa de no detección: (2). Se detecta fácilmente ya que el IDE facilita esta tarea. - Riesgo 4: La estación de trabajo del responsable del proyecto sufre daños. - Severidad: (9). El responsable del proyecto cuenta con sólo una estación de trabajo personal. - Probabilidad de ocurrencia: (1). La probabilidad de ocurrencia es baja porque está en muy buen estado y tiene poco uso. - Tasa de no detección: (1). Es fácil de detectar. - Riesgo 5: La falta de experiencia en programación no permite cumplir con los tiempos de las tareas. - Severidad: (8). La mayor parte de las tareas son de programación. - Probabilidad de ocurrencia: (5). En anteriores proyectos se ha evidenciado la falta de experiencia aunque la práctica ha mejorado este aspecto. - Tasa de no detección: (4). Es relativamente baja porque los errores se pueden atribuir a otros factores. b) Tabla de gestión de riesgos: El RPN se calcula como RPN=SxOxD.

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

Detecc * RPN*

1 7 7 4 196 3 2 6 36

2 9 5 3 135 3 3 3 27

Página 14 de 19




3 2 2 2 8

4 9 1 1 9

5 8 5 4 160 5 3 2 30

Criterio adoptado: - Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 120. Nota: - Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación. c) Plan de mitigación de los riesgos que originalmente excedían el PRN máximo establecido: - Riesgo 1: Fallas en el establecimiento de la comunicación entre los nodos por diversos aspectos. - Medida: Los ensayos serán practicados en ambientes medianamente controlados con línea de vista y corta distancia entre los nodos. - Severidad: (3). Es acotada las causas de las fallas y su accionar para corregirla. - Probabilidad de ocurrencia: (2). Al considerar las posibles interferencias es posible evitarlas. - Tasa de no detección: (4). Puede atribuirse a errores en la programación. - Riesgo 2: El hardware del Nodo Mote LSE sufre daños. - Medida: Se podrán duplicar los resultados obtenidos en los nodos que no sufrieron daños. - Severidad: (3). Será necesario estimar el comportamiento en base a simulaciones. - Probabilidad de ocurrencia: (3). Los nodos serán manejados con el cuidado pertinente. - Tasa de no detección: (3). Debido a que se implementa el mismo software en distintos nodos, si funciona correctamente en uno debe funcionar igual en los demás. Puede ser no detectable al atribuirle el error al software. - Riesgo 5: La falta de experiencia en programación no permite cumplir con los tiempos de las tareas. - Medida: El responsable del proyecto tendrá la posibilidad de consultar foros en la web y de organizar workshops con sus compañeros centrado en la comunicación, colaboración e integración entre desarrolladores de software y profesionales de operaciones en las tecnologías de la información (TI). - Severidad: (5). La gran comunidad argentina de desarrolladores de software y de otros países realizan un aporte muy valioso. - Probabilidad de ocurrencia: (3). La colaboración de compañeros mitiga este riesgo. - Tasa de no detección: (2). Las consultas ayudarán a detectar este riesgo.

19. Gestión de la calidad Para cada uno de los requerimientos del proyecto el responsable de la verificación es el responsable del proyecto y el responsable de la validación es el orientador.

● Req #1: El sistema debe operar en topologías de tipo estrella, peer-to-peer y árbol de cluster. ○ Calidad: El sistema soporta las tres topologías. ○ Grado de calidad: El sistema soporta la movilidad de los nodos. ○ Costos de conformidad: Se estima que se emplearán 50 horas de trabajo empleando

todos los recursos, para realizar las diferentes configuraciones de topologías.

Página 15 de 19




○ Costos de no conformidad: Se deberá realizar nuevamente la configuración, desechando la lógica anteriormente usada.

○ Verificación: Consultar con otro profesional si las contemplaciones abarcan las tres distintas topologías.

○ Validación: Transmitir una trama de datos a lo largo de la red para verificar que se armaron las topologías.

● Req #2: El cambio de modos entre batería y panel solar lo hace el nodo en función de la tensión

que entrega el panel solar; el nodo debe funcionar en modo panel solar todo lo posible. ○ Calidad: El nodo decide el modo de funcionamiento sobre la marcha. ○ Grado de calidad: La mayor parte del tiempo el nodo funciona en modo panel. ○ Costos de conformidad: Se estima que se habrán empleado 135 horas de desarrollo

empleando todos los recursos, para el momento de cumplir este requerimiento. ○ Costos de no conformidad: Se deberá emplear más horas de trabajo para cumplir con el

requerimiento ya que esta funcionalidad es indispensable para operar con el panel solar.

○ Verificación: Controlar que a un valor de tensión específico que entrega el panel solar, el nodo cambia a modo panel y cuando no sea suficiente cambie a modo batería.

○ Validación: Leer de forma remota el modo de operación de los nodos.

● Req #3: La recarga de la batería la decide el nodo en función de la proyección de batería restante y la tensión que entrega el panel solar.

○ Calidad: El nodo decide cuando cargar la batería. ○ Grado de calidad: El sistema logra la alimentación ininterrumpida. ○ Costos de conformidad: Se emplean 60 horas. ○ Costos de no conformidad: Se deberá emplear más horas de trabajo para cumplir con el

requerimiento ya que esta funcionalidad es indispensable para operar con la batería. ○ Verificación: Controlar que las mediciones de la batería aumentan en estado de recarga. ○ Validación: Comprobar los cambios de estado de los nodos distribuidos en la red al

alcanzar los distintos umbrales.

● Req #4: El nodo monitorea distintos parámetros en todo momento y en cada modo de operación.

○ Calidad: El nodo realiza sólo las mediciones pertinentes en cada modo. ○ Grado de calidad: Se determina el grado de exactitud de las mediciones. ○ Costos de conformidad: Es necesario hacer ensayos que permitan suponer variaciones

en la carga de la batería y la temperatura para contrastar las mediciones obtenidas. ○ Costos de no conformidad: Se deberá aprender el funcionamiento del sensor térmico

IC, lo cual agregaría un estimado de 30 horas. ○ Verificación: Usar el ADC del microcontrolador para medir el voltaje de salida en el

GPIO0 del cc2520 y luego calcular la temperatura. Controlar el dispositivo cargador de batería del nodo y calcular la carga en base a la corriente proporcional reportada por el dispositivo.

○ Validación: Realizar mediciones de temperatura y de carga de la batería en distintos entornos/escenarios.

Página 16 de 19




● Req #5: Se debe implementar un algoritmo de ahorro de energía en los nodos en estado de alarma.

○ Calidad: El nodo alarmado debe consumir menos carga de la batería a lo largo del tiempo comparado con su funcionamiento normal.

○ Grado de calidad: Se desactiva la menor cantidad de funcionalidades posible. ○ Costos de conformidad: La prioridad de este requerimiento es la más baja, porque las

funcionalidades a desactivar o los parámetros a cambiar, van a depender de la aplicación específica del nodo. Las horas invertidas tratarán conseguir la configuración más estándar posible para distintas aplicaciones.

○ Costos de no conformidad: De no cumplir con este requerimiento, el sistema seguirá cumpliendo su función de supervisión.

○ Verificación: Comprobar que las funcionalidades sean desactivadas o los parámetros sean modificados al implementar el algoritmo solamente en los nodos alarmados.

○ Validación: Comprobar que cuando un nodo alcanza un umbral de alarma muestra un ahorro de energía en las mediciones de carga de la batería a lo largo del tiempo.

20. 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

Planificación del proyecto

Colaborador, Orientador

Aprobación Semanal email personal

Responsable del proyecto

Consultas específicas

Colaborador, Orientador,

Usuario

Despejar dudas Semanal, mensual

email personal


Finalización de tareas de hardware

Orientador Aprobación Al término de cada tarea

email personal


Finalización de tareas de software

Orientador Aprobación Al término de cada tarea

email personal


Entregables Orientador, Usuario, Jurado

Aprobación Al término del proyecto

email personal


Acto de agradecimiento

Colaborador, Orientador,

Usuario, Jurado

Agradecimiento Al término del proyecto

email personal


Página 17 de 19




21. Gestión de Compras No se prevé contratar servicios. Los elementos a comprar son los necesarios para agregar un circuito extensión de carga con panel solar, para lo cual se recurrirá a proveedores locales. En caso de algún riesgo negativo relacionado al equipamiento ya obtenido se acudirá a los proveedores involucrados previamente.

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

.

Planificación del

proyecto

Completado de los puntos a

definir

Semanal Responsable del proyecto

Colaborador email personal

Hardware Identificación de interfaces de medición y extensión de

circuito cargador


Orientador email personal

Software-topologías Organización de cada

topología

Una vez finalizada

cada topología



Software-memoria Escribir y leer en forma remota

Al finalizar Responsable del proyecto


Software-energía Decisión de modo y recarga

Al finalizar cada

sub-tarea



Software-monitoreo Obtener las distintas

mediciones

Al finalizar cada

sub-tarea



Página 18 de 19




Software-batería Organizar los nodos por estado de alarmas



Software-panel Obtener los 4 indicadores del

modo panel



Software-ahorro Reducir el consumo en el nodo alarmado



Software-integració

n

Integrar todas las

funcionalidades



Documentación y

entregables

Finalización de los 4 documentos

Al comenzar cada uno, semanal y al finalizar


Orientador Colaborador

Usuario Jurado

email personal

Procesos de cierre Realización de cada sub-tarea

Al finalizar todas


Orientador Colaborador

Usuario Jurado

email personal

23. Procesos de cierre

Para analizar si se respetó el Plan de Proyecto original, utilizará la herramienta Gantter para ir completando el porcentaje de finalización en base a cada sub-tarea del WBS, llevará nota de las lecciones aprendidas y problemas-soluciones al término de cada uno y llevará registro de los tiempos los empleados realmente. El responsable del proyecto organizará un acto de agradecimiento a todos los involucrados para el día de la defensa del trabajo final y será él quien financie los gastos correspondientes.

Página 19 de 19

Documents

Nodos WSN alimentados a energía solar con sistema delaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE-Juan... · Plan de Proyecto del Trabajo Final de Carrera de Especialización