Control de un alimentador de terneros con...

Plan de Proyecto del Trabajo Final de Carrera de Especialización de Sistemas Embebidos

Lic. Guillermo Evangelista

Página 1 de 24

Control de un alimentador de

terneros con LPC1769 Autor


Director del trabajo

Esp. Ing. Pablo Ridolfi

Jurado propuesto para el trabajo

Ing. Juan Manuel Cruz

Esp. Ing. Eric Pernia

Ing. Ramiro Alonso

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

Proyectos entre abril y mayo de 2016.



Página 2 de 24

Tabla de contenido

Registros de cambios

Acta de Constitución del Proyecto

Identificación y análisis de los interesados

1. Propósito del proyecto

2. Alcance del proyecto

3. Supuestos del proyecto

4. Requerimientos

5. Entregables principales del proyecto

6. Desglose del trabajo en tareas

7. Diagrama de Activity On Node

8. Diagrama de Gantt

9. Matriz de uso de recursos de materiales

10. Presupuesto detallado del proyecto

11. Matriz de asignación de responsabilidades

12. Gestión de riesgos

13. Gestión de la calidad

14. Comunicación del proyecto

14. Gestión de Compras

16. Seguimiento y control

17. Procesos de cierre



Página 3 de 24

Registros de cambios

Revisión Cambios realizados Fecha

1.0 Creación del documento

Se agregaron los primero 6 puntos del documento

30/03/2016

1.1 Se cambió la temática del proyecto Se agregó nombre del director del trabajo. Se ajustaron los propósito, alcances y requerimientos Se ajustaron las tareas a los nuevos requerimientos, se

agregó la duración en horas de cada una. Se creó el diagrama Aon Se creó el diagrama Gantt Se agregaron las matrices de asignación de

responsabilidad y de uso de recursos materiales Se confecciono presupuesto

06/04/2016 al

12/04/2016

1.2 Se cambió el título del proyecto Se agregaron más requerimientos Se modificaron tiempos de tareas Se modificó diagrama Gantt Se modificó diagrama AON Se corrigió matriz de asignación de responsabilidades Se actualizo el valor de HS de trabajo en el

presupuesto detallado. Se agregó gestión de riesgos Se agregó comunicación del proyecto Se agregó gestión de compras Se agregó gestión de la calidad Se agregó seguimiento y control Se agregó proceso de cierre

14/04/2016 al

19/04/2016

1.3 Corrección de errores marcados Se agregó descripción de gestión de riesgos Se modificaron algunos requerimientos

20/04/2016 al

27/04/2016

1.4 Correcciones menores Se completó gestión de riesgos Se modificó punto 5

28/04/2016



Página 4 de 24

Acta de Constitución del Proyecto

Buenos Aires, 30 de marzo de 2016

Por medio de la presente se acuerda con el Sr. Guillermo Evangelista que su Proyecto Final de la

Carrera de Especialización en Sistemas Embebidos se titulará “Control de un alimentador de terneros con

LPC 1769”, consistirá esencialmente en el desarrollo del código fuente para controlar y gestionar un sistema

de alimentación para terneros , y tendrá un presupuesto preliminar estimado de 640 hs de trabajo, con

fecha de inicio miércoles 30 de marzo de 2016 y fecha de presentación pública miércoles 14 de diciembre

de 2016.

Se adjunta a esta acta la planificación inicial.

Ariel Lutenberg Gustavo Zeitune

Director de la CESE-FIUBA ADOX S.A.



Página 5 de 24

Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto

Auspiciante Javier Viqueira Dirección Presidente ADOX

Cliente ADOX Dirección

Responsable Evangelista Guillermo

Colaboradores Pablo Ridolfi Docente CESE

Orientadores

Gustavo Zeitune

Investigación y

Desarrollo

Gerente de

Desarrollo

Jorge Fiszman

Ing. de desarrollo

Usuario Final INTA Desarrollo Tecnológico

Auspiciante: Javier Viqueira persona muy interesada en el desarrollo de este proyecto y en la

participación de alumnos de la Especialización en Sistemas Embebidos.

Colaboradores: Gustavo Zeitune gerente de desarrollo, predisposición para asesorarnos en los

detalles del sistema.

Orientadores: Jorge Fiszman trabaja junto a Gustavo Zeitune en el departamento de investigación y

desarrollo, está al tanto del día a día del proyecto. Nos va a ayudar mucho para el desarrollo del

proyecto.



Página 6 de 24

1. Propósito del proyecto El propósito de este proyecto es obtener el título de Especialista en Sistemas Embebidos que otorga

la Universidad de Buenos Aires, y a lo largo del proyecto poder conocer los procesos de investigación

y desarrollo que se utilizan en las empresas privadas del sector.

Este proyecto también tiene como propósito desarrollar el firmware que se utiliza en el control de

alimentadores de terneros.

La justificación del proyecto radica en tener un dispositivo capaz de alimentar terneros de una

manera más eficiente y controlada. De esta manera, se puede reducir el tiempo de destete y el animal

crecerá más rápido para poderlo incorporar al sistema productivo de forma más temprana.

2. Alcance del proyecto El proyecto contempla:

El desarrollo del firmware para el alimentador de terneros.

Los distintos códigos fuentes para las funciones del artefacto.

El envío de datos a través de protocolo Ethernet.

El proyecto no contempla:

El desarrollo mecánico del alimentador.

El hardware de adquisición de datos.

La placa base utilizada para el desarrollo.

3. Supuestos del proyecto

Varios módulos ya fueron desarrollados por la empresa.

La estructura principal del alimentador ya está realizada.

La mayor parte del hardware y dispositivos de adquisición de datos ya están montados.

Ya se cuenta con varias bibliotecas y drivers desarrollados.

4. Requerimientos 1. Características del sistema

1.1. El sistema deberá tomar el peso (100Kg-- +/-10gr) de cada ternero que se alimente (1)

1.2. El sistema deberá identificar a cada ternero por medio de un lector RFID. (1)

1.3. El sistema deberá tomar leche de 5 a 15°C y entregarla a 37 - 40°C. Resolución +/-0.1°C

(1)



Página 7 de 24

1.4. El sistema deberá controlar la bomba de alimentación a través de un presóstato ubicado

en la tetina de alimentación. (1)

1.5. El sistema deberá comunicarse a través de un puerto Ethernet e intercambiar los datos

de peso e identificación de terneros con el server. (1)

1.6. Un sistema de limpieza que el firmware debe controlar. (3)

1.7. El hardware que se utilizara es una plataforma desarrollada por la propia empresa. (1)

1.8. Un botón de aprendizaje (1)

1.9. Un Sensor para medir temperatura y realizar ajustes. (1)

1.10. Nivel de líquido en el tanque, sensor de línea vacía (1).

2. Firmware

2.1. Una vez identificado el ternero (por RFID) se consultara la dieta necesaria a un servidor

conectado a través de protocolo TCP/IP. (1)

2.2 Para la conexión Ethernet se utilizará Lwip. (1)

2.3 El dispositivo se implementara con RTOS (1)

3. Gestión de proyectos

3.1 Se deberá utilizar redmine para la gestión de proyectos. (2)

3.2 se utilizara Mercurial (Hg) como sistema de repositorios. (2)

3.3 Doxygen para generar documentación del proyecto (3)

5. Entregables principales del proyecto

Informe de avance

Memoria del trabajo

Presentación ante el jurado

Demostración en video del funcionamiento del equipo



Página 8 de 24

6. Desglose del trabajo en tareas

1. Búsqueda de material bibliográfico (22 Hs)

1.1. Buscar hoja de datos de todos los componentes. (3Hs)

1.2. Analizar la documentación desarrollada por la empresa para el proyecto general. (8Hs)

1.3. Estudiar cómo funciona cada uno de los componentes. (10 Hs)

2. Diseño Firmware. (18 Hs)

2.1. Diagrama de módulos (6 Hs).

2.2. Diagrama de actividades o secuencias (los más importantes). (6 Hs)

2.3. Diagrama de interfaces entre módulos. (6 Hs)

3. Implementación de Firmware. (300 Hs)

3.1. Desarrollar código de función para controlar de temperatura de leche y nivel del

depósito. (60 Hs)

3.2. Desarrollar código de función para controlar presóstato y bomba de leche. (60 Hs)

3.3. Desarrollar código de función para obtener medición de peso desde la balanza. (60 Hs)

3.4. Implementar código de función para manejar lector RFID. (60 Hs)

3.5. Desarrollar código de función para medir temperatura y humedad ambiente. (60 Hs)

4. Testing. (200 Hs)

4.1. Test unitario de cada función de software. (50 Hs)

4.2. Test de tipo funcional por bloques de código y con implementación en forma parcial del

hardware. (50 Hs)

4.3. Ensayos de verificación (lectura de balanza, RFID, etc.). (50 Hs)

4.4. Ensayo final de validación. (50 Hs)



Página 9 de 24

5. Presentación del trabajo. (100 Hs)

5.1. Redacción del informe de avance. (20 Hs)

5.2. Redacción de la memoria escrita. (60 Hs)

5.3. Preparación de la presentación pública del trabajo. (20 Hs)

Horas totales de proyecto: 640 Hs

7. Diagrama de Activity On Node



Página 10 de 24

8. Diagrama de Gantt



Página 11 de 24



Página 12 de 24

9. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea

Recursos requeridos (horas)

Notebook Placa ADOX Laboratorio

1.1

Buscar hoja de

datos de todos

los componentes

3

1.2

Analizar la

documentación

desarrollada por

la empresa para

el proyecto

general.

8

1.3

Estudiar cómo

funciona cada

uno de los

componentes

10

3.1

Desarrollar

código de

función para

controlar de

temperatura de

leche y nivel del

depósito.

45

15



Página 13 de 24

3.2

Desarrollar código de función

para controlar presóstato y

bomba de leche.

60

3.3

Desarrollar código de función

para obtener medición de

peso desde la balanza.

60

3.4

Implementar código de

función para manejar lector

RFID

60

3.5 Desarrollar código de función

para medir temperatura y

humedad ambiente.

60

4.1 Test unitario de funciones. 47 3

4.2 Test de tipo funcional por

bloques de código y con

implementación en forma

parcial del hardware

47 3

4.3 Ensayos de verificación 47 3

4.4 Ensayo final de validación 47 3

5.1 Presentación del informe de

avance.

30

5.2 Presentación de la memoria

escrita

30



Página 14 de 24

10. Presupuesto detallado del proyecto

Categoría Detalle Costo

Costo directo 600 Hs a $120/hs $72000

Costo Indirecto 30 % del costo directo $18000

Materiales Provistos por la empresa $0

Total $90000



Página 15 de 24

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


Responsable del proyecto

Gustavo

Zeitune

Jorge Fiszman

Orientadores

Pablo Ridolfi

Director del Trabajo

ADOX

Clientes

1.1- 1.3

Búsqueda de

material

bibliográfico

P

C

C

2.1-2.3 Diseño de

Firmware

P C C,A

3.1

Desarrollar código

de función para

controlar de

temperatura de

leche y nivel del

depósito.

P

C

C, A

3.2

Desarrollar código

de función para

controlar

presóstato y bomba

de leche.

P

C

C, A

3.3

Desarrollar código

de función para

obtener medición

de peso desde la

balanza.

P

C

C, A



Página 16 de 24

3.4

Implementar

código de función

para manejar lector

RFID

P

C

C, A

3.5

Desarrollar código

de función para

medir temperatura

y humedad

ambiente.

P

C

C, A

4.1

Test unitario de

funciones.

P

C

C, A

4.2

Test de tipo

funcional por

bloques de código y

con

implementación en

forma parcial del

hardware

P

C

C, A

4.3

Ensayos de

verificación

P

C

C, A

4.4

Ensayo final de

validación

P

C

C, A

5.1

Presentación del

informe de avance.

P

A

I

5.2

Presentación de la

memoria escrita

P

A

A

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



Página 17 de 24

12. Gestión de riesgos

Ocurrencia (O): 1 (muy baja) a 10 (muy alta). Severidad (S): 1 (muy baja) a 10 (muy alta).

Detectabilidad (D): 1 (muy alta) a 10 (muy baja).

Criterio adoptado: - Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 250 Nota: - El RPN se calcula como RPN=SxOxD - Los valores marcados con (*) en la tabla corresponden luego de haber aplicado la mitigación.



Página 18 de 24

1° Riesgo: Una o más tareas llevan más tiempo de lo previsto.

Severidad 10: el cronograma se vería afectado en forma negativa

Ocurrencia 5: este tipo de proyectos llevan más horas de las previstas.

Detectabilidad 5: se debe prestar especial atención y al detectar el mínimo atraso hay

que actuar de inmediato.

2° Riesgo: Extravío de la placa de desarrollo.

Severidad 8: el proyecto se paralizaría hasta conseguir una nueva placa.

Ocurrencia 6: la placa solo será utilizada por el desarrollador.

Detectabilidad 8: es difícil de detectar.

3° Riesgo: Surgen problemas al programar las diferentes funciones del firmware.

Severidad 9: se atrasaría la planificación del proyecto.

Ocurrencia 8: los proyectos de esta envergadura, pueden sufrir complicaciones en las

etapas de desarrollo.

Detectabilidad 5: se puede detectar siguiendo la planificación y comparándola con la

realidad.

4° Riesgo: No se llegan a cumplir todos los requisitos.

Severidad 8: pueden ocurrir atrasos que causen este tipo de riesgos.

Ocurrencia 7: al ser proyectos complejos, puede que no se cumplan todos los

requisitos.

Detectabilidad 6: es difícil de predecir en las primeras etapas del proyecto.

5° Riesgo: Se pierden archivos primordiales de la pc.

Severidad 10: por distintas razones se pueden perder archivos de la pc. Pueden

provocar atrasos en la planificación del proyecto.

Ocurrencia 7: nivel de ocurrencia media-alta. Fallos en la pc

Defectibilidad 9: es difícil predecir fallas en la PC, realizar copia de seguridad



Página 19 de 24

Mitigación de riesgos que superan el RPN máximo establecido:

1° Riesgo: Una o más tareas llevan más tiempo de lo previsto.

Severidad 8: el cronograma se vería afectado en forma negativa

Ocurrencia 3: se agregaran más horas de trabajo si fuese necesario.

Detectabilidad 5: si se detectan mínimos retrasos actuar rápidamente consultando a

tutores y orientadores.

2° Riesgo: Extravío de la placa de desarrollo.

Severidad 8: una nueva placa podría conseguirse en un plazo no muy prolongado.

Ocurrencia 4: se tratará de no trasportarla si no es necesario.

Detectabilidad 6: se procurara guardarla en un lugar seguro.

3° Riesgo: Surgen problemas al programar las diferentes funciones del firmware.

Severidad 7: se atrasaría la planificación del proyecto, pero con consultas a

orientadores se podría reducir este atraso.

Ocurrencia 6: realizar las consultas necesarias a fin de llevar el proyecto en tiempo y

forma

Detectabilidad 5: se puede detectar siguiendo la planificación y comparándola con la

realidad. Si se terminan funciones rápido, dedicar el tiempo que sobra a las funciones

más complejas.

4° Riesgo: No se llegan a cumplir todos los requisitos.

Severidad 7: se tratara de mitigar los riesgos antes mencionados.

Ocurrencia 6: priorizar requisitos más importantes.

Detectabilidad 5: revisar la planificación, incluir más horas de trabajo.

5° Riesgo: Se pierden archivos primordiales de la pc.

Severidad 8: copias de seguridad frecuentes. Código alojado en repositorio

Ocurrencia 5: mantener sistema operativo de las pc.

Defectibilidad 7: es difícil de detectar, pero el riesgo se reduce al tener copias de los

archivos.



Página 20 de 24

13. Gestión de la calidad

Requerimientos 1.1 a 1.7: Características del sistema

Verificación y validación:

1. Responsable de la verificación: Evangelista Guillermo

La verificación consta de realizar pruebas de debugging con los sensores del sistema.

2. Responsable de la validación: Evangelista Guillermo

La validación se realizará excitando a los sensores con valores de referencia y contrastándolo con valores de control. Por ejemplo para la prueba de la báscula, se utilizarán pesas de acero y se observará Que el valor medido por el sistema sea igual al del peso colocado. Tomar leche a una temperatura de entre 5 y 15°C y llevarla hasta valores de 37°C-40°C y compararla con un termómetro calibrado. Simular una dieta (enviando los parámetros al microcontrolador de forma manual), activar la bomba para comprobar su correcto funcionamiento y dosificación. Comprobar que al presionar el botón de aprendizaje se ponga en funcionamiento la bomba de leche. A través del firmware, medir temperatura y humedad ambiente. Compararla con medidores calibrados.

Requerimientos 2.1 a 2.3: Firmware

Verificación y validación:

1. Responsable de la verificación: Evangelista Guillermo La verificación consta de realizar pruebas de debugging a las diferentes funciones del sistema. 2. Responsable de la validación: Evangelista Guillermo La validación se realizará leyendo el sensor RFID y comprobando que los datos leídos sean los mismos que los de la tarjeta a leer. Se enviaran datos de peso (Kg) e identificación de terneros a través de Ethernet para comprobar el correcto funcionamiento de Lwip. Testeos de los bloques de funciones e implementación parcial del hardware para comprobar el correcto desempeño de los mismos.



Página 21 de 24

14. Comunicación del proyecto El plan de comunicación del proyecto es el siguiente:

PLAN DE COMUNICACIÓN DEL PROYECTO

¿Qué comunicar?

Audiencia Propósito Frecuencia Método de comunicación

Responsable

Definir objetivos, alcances y

restricciones

Director y orientadores

Evaluar como comenzar el

proyecto. Acciones

principales

Al inicio del proyecto

Reunión y correo

electrónico

Lic. Guillermo

Evangelista

Definir requerimientos

Orientadores Definir requerimientos

de forma precisa

Al inicio del proyecto y cuando sea necesario

Reunión y correo

electrónico

Lic. Guillermo

Evangelista

Informe de avance

Orientadores, director, jurado

Evidenciar evolución del

proyecto

Una vez a la mitad del proyecto

Correo electrónico Web CESE

Lic. Guillermo

Evangelista

Resolución de conflictos

Orientadores, director,

docentes CESE

Despejar dudas que surjan durante la

realización del proyecto

Cuando sea requerido

Reunión y correo

electrónico

Lic. Guillermo

Evangelista

Finalización y cierre

Director, clientes, jurados,

orientadores.

mostrar documentación

a los clientes

Al finalizar el proyecto

Correo electrónico

Lic. Guillermo

Evangelista



Página 22 de 24

15. Gestión de Compras No se prevee contratar servicios. Los materiales utilizados (placa de desarrollo) para la realización

del proyecto serán provistos por ADOX S.A., por lo cual no es necesario un análisis de gestión de

compra.

16. 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 comunicación

1.1

Finalización de búsqueda de

datos

Al finalizar la tarea


------- Correo electrónico

1.2

-------

Al finalizar la

tarea


------- Correo

electrónico

1.3

-------

Al finalizar la

tarea

Lic. Guillermo

Evangelista

------- Correo

electrónico

2.1 Diagramas terminados

Al finalizar la

tarea

Lic. Guillermo

Evangelista

------- Correo

electrónico

2.2

Diagramas terminados

Al finalizar la

tarea

Lic. Guillermo

Evangelista

------- Correo

electrónico

2.3 Diagramas terminados

Al finalizar la

tarea

Lic. Guillermo

Evangelista

------- Correo

electrónico



Página 23 de 24

Tarea del WBS

Indicador de avance





3.1

Leer en forma correcta

temperatura y nivel de liquido

Una vez por

semana

Lic. Guillermo

Evangelista

Orientadores

Director

Correo

electrónico

3.2 Leer presión en forma correcta y encender la

bomba

Una vez por semana

Lic. Guillermo

Evangelista

Orientadores

Director

Correo

electrónico

3.3

Leer puerto RS232 de la

balanza

Una vez por semana

Lic. Guillermo

Evangelista

Orientadores

Director

Correo

electrónico

3.4 Probar el código para

lectura de RFID

Una vez por semana

Lic. Guillermo

Evangelista

Orientadores

Director

Correo

electrónico

3.5 Leer en forma correcta

temperatura y humedad

Una vez por semana

Lic. Guillermo

Evangelista

Orientadores

Director

Correo

electrónico

4.1 Test unitario de

funciones.

Una vez por semana

Lic. Guillermo

Evangelista

Orientadores

Director

Correo

electrónico

4.2 Test de tipo

funcional por

bloques de

código y con

implementación

en forma

parcial del

hardware

Una vez por semana

Lic. Guillermo

Evangelista

Orientadores

Director

Correo

electrónico

4.3 Ensayos de

verificación

Una vez por semana

Lic. Guillermo

Evangelista

Orientadores

Director

Correo

electrónico



Página 24 de 24

Tarea del WBS

Indicador de avance





4.4 Ensayo final

de validación

Una vez por semana

Lic. Guillermo

Evangelista

Orientadores

Director

Correo

electrónico

5.1 Presentación del informe

A mitad del proyecto

Lic. Guillermo

Evangelista

Dr. Ing. Ariel Lutenberg

Correo

electrónico

5.2 Presentación de la memoria

del trabajo


Lic. Guillermo

Evangelista

Dr. Ing. Ariel Lutenberg Esp. Ing.

Pablo Ridolfi

Correo

electrónico

5.3 Defensa del trabajo ante el

jurado


Lic. Guillermo

Evangelista

Jurados, Director

Presentación

publica

17. Procesos de cierre A partir del listado WBS se evaluará como se llevó a cabo el proyecto, y en qué grado se cumplieron

los objetivos propuestos al inicio del mismo. Si hubieran quedado objetivos total o parcialmente

incompletos, se deberá hacer una evaluación de las causas y factores causantes y proponer acciones

futuras para asegurar el éxito de futuros proyectos.

Se archivará toda la documentación de la gestión del proyecto de forma de ser fácilmente reutilizada

en la planificación de futuros proyectos.

Luego de defendido el proyecto ante el jurado, se procederá a agradecer a todos los miembros del

equipo, director del trabajo, miembros del jurado y autoridades del CESE.

Control de un alimentador de terneros con...

Documents

Transcript of Control de un alimentador de terneros con...