Sistema Embebido para medir la Demanda Bioquímica de...

Plan de Proyecto del Trabajo Final de Carrera

de Especialización de Sistemas Embebidos

Ing. Juan Carlos Suárez Barón

Sistema Embebido para medir la Demanda

Bioquímica de Oxígeno DBO.

Autor


Director del trabajo

Mg. Ing. Eduardo Filomena (UNER)

Jurado propuesto para el trabajo

- Mg. Bioing. Juan Manuel Reta (UNER) - Esp. Ing. Sergio De Jesús Meleán (FIUBA) - Esp. Ing . Jorge Manuel Fonseca (FIUBA)

Página 1 de 31




Este plan de trabajo ha sido realizado en el marco de la asignatura Gestión de Proyectos entre abril y mayo de 2017.

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 7

1. Propósito del proyecto 8

2. Alcance del proyecto 9

3. Supuestos del proyecto 9

4. Requerimientos 9

5. Entregables principales del proyecto 10

6. Desglose del trabajo en tareas 10

7. Diagrama de Activity On Node 12

8. Diagrama de Gantt 13

9. Matriz de uso de recursos de materiales 15

10. Presupuesto detallado del proyecto 16

11. Matriz de asignación de responsabilidades 17

12. Gestión de riesgos 21

13. Gestión de la calidad 23

14. Comunicación del proyecto 24

15. Gestión de Compras 25

16. Seguimiento y control 26

17. Procesos de cierre 30

Página 2 de 31




Registros de cambios

Revisión Detalle de los cambios realizados Fecha

1.0 Creación del documento 11/04/2017

1.1 Correcciones según indicaciones hechas a la revisión 1.0: 14/04/2017

1.2 Modificación al punto 6: Desglose del trabajo en tareas 17/04/2017

1.3 Correcciones a los puntos 4, 5 y 6 26/04/2017

1.4 Diligenciamiento de los puntos 11 a 17. 27/04/2016

1.5 Modificaciones y correcciones:

● Forma del diagrama de Gantt y la duración de las tareas.

● Se modificó diagrama AON ● Punto 11. Matriz de asignación de responsabilidades

(Se corrigieron las asignaciones de aprobación y consulta.

● Se agregó nombre del director del trabajo. ● Se incluyeron las horas de trabajo dentro del

presupuesto. ● Adición de los riesgos 6, 7 y 8 al punto número 12. ● Modificaciones de la gestión de calidad. ● Corrección a lo solicitado en el punto 13 de gestión de

calidad.

28/04/2016

1.6 Modificaciones y correcciones: ● Nuevo diseño de la figura 2. Diagrama de bloques del

sistema propuesto. ● Modificación de la ruta crítica en el activity on node. ● Corrección de la mitigación del riesgo 2.

01/05/2017

1.7 Modificaciones y correcciones: ● Adición del plan de mitigación de los riesgos 4,6,7 y 8.

01/05/2017

1.8 Modificaciones y correcciones: ● Corrección del camino crítico en el AON. ● Corrección del valor de probabilidad de ocurrencia

dentro del plan de mitigación del riesgo 7. ● Nueva imagen del diagrama de Gantt.

02/05/2017

Página 3 de 31




Acta de Constitución del Proyecto

Ciudad Autónoma de Buenos Aires, 11 de abril de 2017

Atención, Ing Juan Carlos Suárez Barón

Con el fin de llevar a cabo la realización de un dispositivo, con el objetivo de usarlo como prototipo para construir un equipo de medición de la demanda bioquímica de oxígeno (DBO). Se lo designa a Ud como Responsable del proyecto con “Sistema Embebido para medida de BOD”, con un presupuesto total estimado de 667 horas/hombre, con fecha tentativa de inicio 18/04/2017 y de finalización 30/11/2017.

Se adjunta a esta acta la planificación inicial.

Dr. Ing. Ariel Lutenberg Dr. Eduardo Cortón

Director de la CESE-FIUBA Laboratorio de Biosensores y Bioanálisis

Nombre y Apellido

Director del Trabajo Final

Nombre y Apellido (1) Nombre y Apellido (2)

Jurado del Trabajo Final Jurado del Trabajo Final

Nombre y Apellido (3)

Jurado del Trabajo Final

Página 4 de 31




Descripción técnica-conceptual del Proyecto Sistema Propuesto

El sistema a desarrollar, descrito en la figura 1, es un sistema FIA (Flow Injection System) compuesto por bombas peristálticas y válvulas solenoides para bombear muestras hacia una cámara termostática o bloque de calefacción de las muestras, que luego serán dirigidas hacia el biosensor, inmerso en una jaula de Faraday.

El menú de usuario y los datos de medida serán visualizados a través de un display TFT, con el objetivo de mostrar un menú de acciones amigable e intuitivo. El objetivo principal del desarrollo del prototipo es obtener tiempos de medida de DBO de 60 minutos o menos, mejorando así el método estándar del BOD5 [1].

Figura 1. Diagrama esquemático del sistema propuesto.

Adicionalmente se presenta en la figura 2 el diagrama de bloques con el objetivo de plasmar e identificar cada componente o módulo para mayor comprensión.

Página 5 de 31




Figura 2. Diagrama de bloques del sistema propuesto.

Descripción de los módulos:

Módulo de control: Es el cerebro del sistema, realiza el control del todo el circuito hidráulico, adquiere las señales medidas por el módulo de electrodos, monitorea constantemente la cámara termostatizada y muestra los resultados a través de la pantalla táctil.

Módulo interfaz usuario: Este módulo se ocupa de la comunicación entre el equipo y el usuario mediante la pantalla táctil.

Módulo de electrodos: Forma parte del circuito hidráulico del equipo y se encarga de tomar los micropotenciales generados por el electrodo del biosensor y los amplifica a valores de tensión compatibles con el módulo de control.

Módulo de bombas peristáliticas: Forma parte del circuito hidráulico del equipo y se encarga de realizar el movimiento de la muestra y solución de calibración hacia el módulo de electrodos.

Módulo de válvulas: Forma parte del circuito hidráulico del equipo y se encarga de realizar el direccionamiento de la muestra y de la solución de calibración hacia el módulo de electrodos.

Módulo de alimentación: Se encarga de entregar las tensiones adecuadas para el correcto funcionamiento del sistema.

La figura 3 muestra una representación gráfica del circuito de la microfluídica del sistema.

Página 6 de 31




Figura 3. Circuito hidráulico o de microfluídica.

Descripción de los componentes:

● StdA y StdB: soluciones de calibración del electrodo. ● V1: Válvula de dos vías para toma de solución de calibración (Std A). ● V2: Válvula de dos vías para toma de solución de calibración (Std B). ● V3: Válvula de dos vías para toma de muestra (Sample). ● Sensor de líquido: Para detectar el paso o no de agua. ● P1: Bomba peristáltica para el movimiento de la soluciones de calibración y la muestra. ● P2: Bomba peristáltica para el movimiento de agua. ● P3: Bomba peristáltica para el movimiento de la solución de lavado o rinse. ● BA: Bomba de aire para producir la mezcla entre la muestra con aire.

Identificación y análisis de los interesados

Rol Nombre y Apellido Departamento Puesto Auspiciante LABB FCEN UBA Investigación --- Cliente LABB FCEN UBA Investigación --- Impulsor Dr. Eduardo Cortón --- --- Responsable Juan Carlos Suárez Barón --- Ingeniero Colaboradores Patricio Bos (Por definir)

Sergio Renato de Jesús Meleán

Diego Fernández (Por definir)

Ingeniería Docente CESE Docente CESE Docente CESE

Orientadores Mg. Ing. Eduardo Filomena Ingeniería --- Equipo Juan Carlos Suárez Barón --- --- Usuario Final Interesados en monitoreo de

calidad de agua. --- ---

Página 7 de 31




Cliente: Exigente a la hora del cumplimiento de fechas.

Colaborador: Dinámico y con criterio en la resolución de problemas de software.

Orientador: Su mayor influencia será a través de la elección de componentes para el hardware y orientación en el diseño del firmware/software.

Responsable: Cumplidor en tiempo y forma de las fechas pactadas, trabajará más horas de las planeadas en caso de encontrarse atrasado el proyecto.

1. Propósito del proyecto El propósito de este proyecto es el diseño de un prototipo de un sistema de medición de la demanda bioquímica de oxígeno para el monitoreo de la calidad de agua apoyado en sistemas embebidos, cuya finalidad es obtener informes de manera automática a partir de las mediciones realizadas. Adicionalmente constituirá un primer paso hacia un prototipo en el marco de un proyecto (PICT), además de ser requisito para recibirme como especialista en sistemas embebidos y adquirir conocimientos y experiencia en el diseño de equipos electroquímicos. Como nota adicional, este proyecto nace de la necesidad de construir equipos de monitoreo ambiental, específicamente de BOD de buenas prestaciones y de menor costo en comparación con los equipos importados.

2. Alcance del proyecto El proyecto incluye el diseño de los algoritmos para el cálculo de la BOD y la implementación de hardware, junto con la presentación de los resultados en un display LCD, y la elaboración de informes. Esto constituye un prototipo de un equipo a desarrollar y fabricar en un futuro.

El proyecto no incluye calibración de acuerdo a normas ambientales de monitoreo de calidad de agua nacionales e internacionales ni el diseño de los sensores a utilizar. Tampoco está previsto el diseño de la fuente de alimentación del equipo.

Página 8 de 31




3. Supuestos del proyecto Para el desarrollo del presente proyecto se supone que:

Supuestos:

La construcción de las placas de acondicionamiento de la señal de los sensores no llevará más de

cuatro semanas.

● Se podrá construir las placas de instrumentación y etapas de salida en forma casera. ● Se dispondrá de información suficiente en el internet y libros virtuales. ● La placa será correctamente ensamblada por el armador. ● Ninguna placa se quemará por una mala conexión. ● Suponiendo que el proyecto va a poder realizarse con 600 horas/hombre, y que se cuentan

con 7 meses para la realización del mismo, se estima que, trabajando una persona sola, debe dedicar aproximadamente 4 horas diarias al proyecto (sin contar fines de semana).

4. Requerimientos 1. Característica General del Prototipo

1.1 El prototipo deberá contar con un menú de usuario para realizar la medición de

muestras y la calibración del mismo.

2. Hardware

2.1 Módulo de acondicionamiento de señal: El módulo deberá acondicionar las señales

generadas por el sensor a un nivel de 0 a 3,3 Vcc.

2.2 Módulo de Interfaz Gráfica con el usuario: Una pantalla táctil para la selección de las distintas funciones del Menú.

2.3 Módulo de control fluídico: El módulo deberá implementar un driver de hardware para el control de las bombas peristálticas y de las electroválvulas.

2.4 Módulo de control: Se deberá seleccionar el microcontrolador para controlar los módulos de 2.1, 2.2, 2.3.

3. Software

3.1 Diseño de tipo modular en capas que permita hacer abstracción del hardware.

3.2 Desarrollo de los distintos drivers para los módulos mencionados en Hardware.

3.3 Desarrollo del algoritmo para la obtención de las concentraciones de demanda biológica de oxígeno (DBO).

Página 9 de 31




Regulaciones:

Normas IRAM nacionales que regulan la medición de BOD: IRAM 290151:2002 y la IRAM 290152:2002

Todos estos requerimientos son obtenidos del análisis de distintos Medidores de BOD existentes en el mercado y pueden estar sujeto a cambio, pero serán totalmente definidos antes de finalizado el período del Desglose de trabajo de Tareas (ítem número 6).

5. Entregables principales del proyecto ● Manual de usuario.

○ Configuración del prototipo. ○ Preguntas frecuentes. ○ Diagrama general. ○ Contacto de soporte. ○ Listado de piezas de insumos y repuestos comunes.

● Manual técnico del prototipo(HARDWARE). ○ Lista de materiales. ○ Esquemático y hojas de datos de las placas electrónicas construidas. ○ Hojas de datos e información de la placa de control.

● Manual técnico del prototipo (SOFTWARE). ○ Diagramas de flujo. ○ Descripción de funciones.

● Video demostrativo de funcionamiento y configuración. ● Memoria del proyecto final de carrera.

6. Desglose del trabajo en tareas Los valores indicados entre paréntesis corresponden a las horas de trabajo presupuestadas.

1. Preliminares del proyecto (20 hs). 1.1. Analizar la documentación y estado del arte (4hs). 1.2 . Planificación (10 hs). 1.3 . Aprobación (5 hs). 1.4. Exposición del anteproyecto (1 h).

2. Captura de Requerimientos (9 hs).

2.1 Hardware (3 hs). 2.2 Software (3 hs). 2.3 Documentación (3 hs).

Página 10 de 31




3. Diseño de Firmware/Software (23 hs). 3.1. Diagrama de módulos (6 hs). 3.2. Diagrama de actividades y secuencias (6 hs). 3.3. Diagrama de interfaces entre módulos (6 hs). 3.4 Documentación (5 hs).

4. Diseño de Hardware (130 hs). 4.1 Búsqueda de material bibliográfico (22 hs). 4.2 Búsqueda y selección de componentes (13 hs). 4.3 Diseño de esquemáticos (40 hs). 4.3 Revisión de los esquemáticos (5 hs). 4.5 Diseño de las PCB (30 hs). 4.6 Revisión del diseño de las PCB (10 hs). 4.7 Documentación (10 hs)

5. Pruebas (70 hs).

5.1. Pruebas individuales de cada módulo de hardware(30 hs). 5.2 Pruebas de los módulos de hardware integrados (20 hs). 5.3 Pruebas experimentales (20 hs).

6. Implementación de Firmware/Software (305 hs).

6.1. Desarrollo de la función para controlar la temperatura de la cámara termostatizada (50 hs). 6.2. Desarrollo de la función para controlar las bombas peristálticas (50 hs). 6.3 Desarrollo de la función para controlar la bomba de aire (50 hs). 6.4 Desarrollo de la funciones para controlar la pantalla táctil (50 hs). 6.5 Desarrollo de la función para controlar las válvulas. (50 hs). 6.6 Desarrollo de la función para medir DBO desde el sensor (electrodo) (50 hs). 6.7 Documentación (5 hs).

7. Testing. (100).

7.1. Test unitario de cada función de software. (25 hs). 7.2. Test funcional por bloques de código. (25 hs). 7.3. Ensayos de verificación. (25hs). 7.4. Ensayo final de validación. (25 hs).

8. Presentación del trabajo. (100)

8.1. Redacción del informe de avance. (15 hs) 8.2. Redacción de la memoria escrita. (60 hs) 8.3. Preparación de la presentación pública del trabajo. (15 hs)

Horas totales del proyecto: 667 hs

Página 11 de 31




7. Diagrama de Activity On Node

Página 12 de 31




8. Diagrama de Gantt

Página 13 de 31




Para mejor visibilidad se adjunta el enlace al mismo:

https://www.smartapp.com/gantterforgoogledrive/index.html?fileID=0B10nsYGn2AkWal9FYmZhdDVRTEk

Página 14 de 31






9. Matriz de uso de recursos de materiales

Código WBS

Nombre de la tarea

Recursos requeridos (horas)

PC Laboratorio

1.1 Analizar el estado del arte sobre desarrollos similares.

4 0

1.2 Planificación 10 0

1.3 Aprobación 5 0

1.4 Exposición del anteproyecto. 1 0

2.1 Hardware 3 0 2.2 Software 3 0 2.3 2.3 Documentación 3 0 3.1 Diagrama de módulos 6 0

3.2 Diagrama de actividades y secuencias.

6 0

3.3 Diagrama de interfaces entre módulos.

6 0

3.4 Documentación. 5 0 4.1 Búsqueda de material

bibliográfico. 22 0

4.2 Búsqueda y selección de componentes.

13 0

4.3 Diseño de esquemáticos 40 0 4.4 Revisión de los

esquemáticos. 5 0

4.5 Diseño de las PCB. 30 12 4.6 Revisión del diseño de las

PCB. 2 10

4.7 Documentación. 10 0 5.1 Pruebas individuales de cada

módulo de hardware. 0 30

5.2 Pruebas de los módulos de hardware integrados.

0 20

5.3 Pruebas experimentales. 0 20 6.1 Desarrollar función para

controlar la temperatura de la cámara termostatizada.

50 0

6.2 Desarrollar función para controlar las bombas peristálticas.

50 0

Página 15 de 31




6.3 Desarrollar función para controlar la bomba de aire.

50 0

6.4 Desarrollar funciones para controlar la pantalla táctil.

50 0

6.5 Desarrollar función para controlar las válvulas.

50 0

6.6 Desarrollar función para medir DBO desde el sensor (electrodo).

50 0

6.7 Documentación. 5 0 7.1 Test unitario de cada función

de software. 25 0

7.2 Test de tipo funcional por bloques de código.

25 0

7.3 Ensayos de verificación. 25 10 7.4 Ensayo final de validación. 25 0 8.1 Redacción del informe de

avance. 15 0

8.2 Redacción de la memoria escrita.

60 0

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

15 0

10. Presupuesto detallado del proyecto

Costos

Componente Cantidad Precio (en pesos) por unidad

Motor paso a paso * 1 400

Válvula 3 vías * 3 1000

PCB virgen 20 x 20 cm capa simple

2 80

Ácido para PCB 1 100

Sensor de BOD * 2 3600

Sensor de referencia * 1 1000

Página 16 de 31




Leds 4 20

Tubuladura de silicona* 1 50

Fuente 12V 2A 1 550

Pulsadores 4 20

Pantalla Táctil 1 3000

Horas hombre 667 hs ($300 por hora) 200100

Total $219820

* Unidad proporcionada por el cliente

Costos indirectos

Transporte $1000

Envios por correo argentino o Fletes $500

Impresiones $200

Total $1700

Costos Totales (Directos + Indirectos) $223220

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

Juan Carlos Suárez

Mg. Ing. Eduardo Filomena

Esp. Ing Diego

Fernández

Dr. Ing Ariel Lutenberg

1.1 Analizar la documentación o estado del arte.

P A --- ---

1.2 Planificación. P A --- A 1.3 Aprobación. S A --- A 1.4 Exposición del

anteproyecto. P A --- A

2.1 Hardware. P A --- --- 2.2 Software. P A --- --- 2.3 Documentación P A --- ---

Página 17 de 31




3.1 Diagrama de módulos.

P A C ---

3.2 Diagrama de actividades y secuencias.

P A C ---

3.3 Diagrama de interfaces entre

módulos.

P A C ---

3.4 Documentación. P A C --- 4.1 Búsqueda de

material bibliográfico.

P A --- ---

4.2 Búsqueda y selección de

componentes.

P A --- ---

4.3 Diseño de esquemáticos.

P A --- ---

4.4 Revisión de los esquemáticos.

P A --- ---

4.5 Diseño de las PCB.

P A --- ---

4.6 Revisión del diseño de las PCB.

P A --- ---

4.7 Documentación. P A --- --- 5.1 Pruebas

individuales de cada módulo de

hardware.

P A --- ---

5.2 Pruebas de los módulos de hardware

integrados.

P A --- ---

5.3 Pruebas experimentales.

P A --- ---

6.1 Desarrollar función para controlar la

temperatura de la cámara

termostatizada.

P A --- ---

6.2 Desarrollar función para controlar las

bombas peristálticas.

P A --- ---

Página 18 de 31





bomba de aire.

P A --- ---

6.4 Desarrollar funciones para

controlar la pantalla táctil.

P A --- ---


válvulas.

P A --- ---

6.6 Desarrollar función para

medir DBO desde el sensor

(electrodo).

P A --- ---

6.7 Documentación. P A --- --- 7.1 Test unitario de

cada función de software.

P A --- ---

7.2 Test funcional por bloques de

código.

P A --- ---

7.3 Ensayos de verificación.

P A --- ---

7.4 Ensayo final de validación.

P A --- ---

8.1 Redacción del informe de

avance.

P A --- A

8.2 Redacción de la memoria escrita.

P A --- A

8.3 Preparación de la presentación pública del

trabajo.

P A --- A

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

Página 19 de 31




12. Gestión de riesgos

Riesgo 1: Daño de la placa de desarrollo por una mala conexión eléctrica. ● Nivel de Severidad (10): Su nivel es alto ya que es la de control y procesamiento de prototipo. ● Probabilidad de ocurrencia (3): Los integrantes del equipo de trabajo están bien capacitados

y con experiencia en el manejo de electronica.

Riesgo 2: Daño de los componentes más delicados: Pantalla táctil y sensor de DBO.

● Nivel de Severidad (10): Su nivel es alto dado que no se tiene experiencia en el uso e implementación de este tipo de elementos y su daño retrasaría en gran medida el desarrollo del proyecto.

● Probabilidad de ocurrencia (5): Los miembros del equipo gozan de entrega y compromiso para aprender a usar adecuadamente estos dispositivos.

Riesgo 3: Pérdida de algún módulo de hardware del prototipo.

● Nivel de Severidad (8): Cada módulo es fundamental para la realización del equipo. ● Probabilidad de ocurrencia (5): Los distintos módulos de hardware podrían extraviarse del

espacio de trabajo por descuidos en la organización de los elementos de electrónicos de trabajo.

Riesgo 4: Aumento del precio de los distintos componentes a utilizar.

● Nivel de Severidad (5): Si bien puede existir un aumento en componente electrónicos, esto no sería muy afectos ya que se pueden utilizar algunos materiales reciclados para la construcción del prototipo.

● Probabilidad de ocurrencia (8): Debido a la actual inestabilidad económica de Argentina.

Riesgo 5: Retraso en la finalización del proyecto.

● Nivel de Severidad (10): Significa que el prototipo no se terminaría para la fecha de finalización del proyecto.

● Probabilidad de ocurrencia (6): Es probable que sea un inconveniente ya que dos de los miembros de equipo no participaron en proyectos de diseño en forma profesional.

Riesgo 6: Extravío de la placa de desarrollo.

● Nivel de Severidad (8): El proyecto se paraliza hasta conseguir una nueva placa. ● Probabilidad de ocurrencia (6): La placa solo será utilizada por el desarrollador.

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

● Severidad (9): Se atrasaría la ejecución del proyecto. ● Probabilidad de ocurrencia (8): los proyectos de esta envergadura, pueden sufrir

complicaciones en las etapas de desarrollo.

Página 20 de 31




Riesgo 8: Se pierden archivos primordiales de la pc ● Severidad (10): Por distintas razones se pueden perder archivos de la pc pueden provocar

retrasos en la planificación del proyecto. ● Probabilidad de ocurrencia (7): Nivel de ocurrencia media-alta. Fallos en la pc.

b) Tabla de gestión de riesgos: (El RPN se calcula como RPN=SxO)

Riesgo Severidad Ocurrencia RPN Severidad* Ocurrencia* RPN*

1 10 3 30

2 9 5 45 8 3 24

3 8 5 40 7 3 21

4 5 8 40 3 8 24

5 10 6 60 7 4 28

6 8 6 48 8 3 24

7 9 8 72 7 3 21

8 10 7 70 8 3 24

Criterio adoptado: - Se tomarán medidas de mitigación en los riesgos cuyos números de RPN sean mayores a 40. 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 *RPN máximo establecido:

Riesgo 2: Daño de los componentes más delicados: Pantalla táctil y sensor de DBO.

Plan de mitigación: Se pondrá especial énfasis en aprender a utilizar adecuadamente la pantalla táctil y el sensor de DBO aprovechando la documentación suficiente existente la web.

● Nivel de Severidad (8): Luego de un periodo de estudio de las hojas de datos y notas de

aplicación, aproximadamente de un mes, se estima que el nivel de conocimientos y buenas prácticas de uso mejoren, reduciendo el nivel de severidad.

● Probabilidad de ocurrencia (3): Se aumentará la experiencia en buenas prácticas de uso de la pantalla táctil y del sensor de DBO.

Página 21 de 31




Riesgo 3: Pérdida de algún módulo de hardware del prototipo.

Plan de mitigación: Se contemplará la posibilidad de fabricar y ensamblar varios módulos de hardware para tener un stock propio suficiente. Adicionalmente, se mejorará el orden del espacio de trabajo.

● Nivel de Severidad (7): Muchos de los módulos se pueden fabricar en grandes cantidades. ● Probabilidad de ocurrencia (3): Se tomarán las medidas preventivas para que el espacio de

trabajo sea lo más ordenado posible. Riesgo 4: Aumento del precio de los distintos componentes a utilizar.

Plan de mitigación: Se consultará con proveedores locales el stock y precios luego de seleccionar los componentes a utilizar. También se evaluará la posibilidad de importarlos.

● Nivel de Severidad (3): Los componentes más costosos se compran lo antes posible. ● Probabilidad de ocurrencia (8): La importación directa de componentes a través de

distribuidores mayoristas puede reducir su costo.

Riesgo 5: La poca experiencia en diseño de los distintos miembros de equipo puede provocar que no se cumplan las fechas de finalización de cada etapa.

Plan de mitigación: Se debe trazar un plan de trabajo rápido a través de consulta a expertos y foros especializados sobre diseño electrónico que permita resolver dudas en el menor tiempo posible sobre temas analógicos y digitales.

● Nivel de Severidad (7): Los miembros de equipo están conscientes de eso y están dispuestos a aumentar las horas de trabajo de ser necesario.

● Probabilidad de ocurrencia (4): Existen muchos colaboradores que están al tanto del proyecto a los que se les puede consultar para disminuir la probabilidad.

Riesgo 6: Extravío de la placa de desarrollo.

Plan de mitigación: Se debe, si el presupuesto lo permite, comprar una nueva placa y guardarla en un lugar seguro.

● Nivel de Severidad (8): Una nueva placa podría conseguirse en un plazo no muy prolongado. ● Probabilidad de ocurrencia (3): Se tratará de no transportarla si no es necesario.

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

Página 22 de 31




Plan de mitigación: 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.

● Severidad (7): Se atrasaría la planificación del proyecto, pero con consultas a orientadores se podría reducir el atraso.

● Probabilidad de ocurrencia (3): Realizar las consultas necesarias a fin de llevar el proyecto en tiempo y forma.

Riesgo 8: Se pierden archivos primordiales de la pc

Plan de mitigación: Se deben adoptar estrategias que permitan salvaguardar los archivos haciendo copia de los mismos

● Severidad (8): Copias de seguridad frecuentes. Código alojado en un repositorio. ● Probabilidad de ocurrencia (5): Mantener sistema operativo de las pc.

13. Gestión de la calidad Req 1.1 El prototipo deberá contar con un menú de usuario para realizar la medición de muestras y la calibración del mismo.

Verificación: Se le pedirá a un experto el diseño del menú. (Notar que el menú aún no se ha implementado).

Validación: Prueba de usuario para confirmar si es simple e intuitivo.

Req 2.1 Módulo de acondicionamiento de señal: El módulo deberá acondicionar las señales generadas por el sensor a nivel de 3,3 Vcc.

Verificación: Consistirá en hacer pruebas y mediciones de los niveles de voltaje generados por el sensor y por el módulo.

Validación: La validación se realizará excitando a los sensores con valores de referencia y contrastándolos con valores generados por el módulo.

Req 2.2 Módulo de Interfaz Gráfica con el usuario: Una pantalla táctil para la selección de las distintas funciones del Menú.

Verificación: Se hará una búsqueda detallada en la web de las pantallas táctiles existententes e indagando sus características de funcionamiento y precio.

Validación: A partir de la búsqueda se determinará la mejor relación calidad/precio.

Req 2.3 Módulo de control fluídico: El módulo deberá implementar un driver de hardware para el control de las bombas peristálticas y las electroválvulas.

Verificación: La verificación consistirá en hacer pruebas de funcionamiento eléctrico y de

bombeo de fluido.

Página 23 de 31




Validación: Se hará una comparación entre los resultados esperados y los obtenidos en las

pruebas de funcionamiento.

Req 2.4 Módulo de control: Se deberá seleccionar microcontrolador para controlar los módulos de 2.1, 2.2, 2.3.

Verificación: Se hará una búsqueda detallada en la web de los kits de desarrollo de microcontroladores de 32 bits existententes indagando sus características de funcionamiento, prestaciones y precio.

Validación: A partir de la búsqueda se determinará la mejor relación calidad/precio.

3.1 Diseño de tipo modular en capas que permita hacer abstracción del hardware.

Verificación: Se confrontará con otros casos de estudio similares de portabilidad de código a otras plataformas de microcontroladores.

Validación: Una vez creados los drivers se revisarán detalladamente para lograr que el diseño del firmware sea modular y con abstracción del hardware.

3.2 Desarrollo de los distintos drivers para los módulos mencionados en Hardware.

Verificación: Se confrontan los resultados del test para comprobar el funcionamiento de los drivers.

Validación: Realizar procedimientos de test eléctrico/electrónico para cada driver con el ánimo de verificar su funcionalidad.

3.3 Desarrollo del algoritmo para la obtención de las concentraciones de demanda biológica de oxígeno (DBO).

Verificación: Investigar literatura sobre el modelo matemático y su aplicación sobre cómo crear un algoritmo para su cálculo.

Validación: Una vez creado el algoritmo, usar un TDD para su control.

Página 24 de 31




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

Responsable

Análisis de factibilidad y

plan de proyecto

Eduardo Filomena

Mostrar y analizar en

forma conjunta los

resultados

Única vez al finalizar el

Análisis y el plan de

proyecto

Correo electrónico

Juan Carlos Suárez Barón

Avance del prototipo y

diseños

Eduardo Filomena

Informar el estado del proyecto

Una o dos veces

por semana

Correo electrónico


Avance del prototipo y

diseños

Eduardo Filomena

Informar el estado del proyecto

Una o dos veces

por semana

Correo electrónico


Avances con los drivers

(software)

Diego Fernández

Informar el estado de

la aplicación

Una o dos veces

por semana (Una

vez finalizado el

prototipo)

Correo electrónico


Implementación

y resultados experimentales

Eduardo Filomena

Redactar y evaluar si se

cumplieron los requerimiento

s y anotar las

oportunidades de

mejora

Única vez al finalizar la

implementación

Correo electrónico


Página 25 de 31




15. Gestión de Compras En caso de tener que comprar elementos o contratar servicios: a) Explique con qué criterios elegiría a un proveedor. b) Redacte el Statement of Work correspondiente. Proveedor: Mouser electronics y /o Digikey Item: Electrónica Criterios:

1. Búsqueda en su página web para consultar sobre la disponibilidad y variedad de componentes. 2. Pedido de cotización. 3. Envío por correo certificado. 4. Pago con dinero electrónico. 5. Pedido de comprobante de pago.

16. Seguimiento y control

Para cada tarea del proyecto establecer la frecuencia y los indicadores con los se seguirá su avance y quién será el responsable de hacer dicho seguimiento y a quién debe comunicarse la situación (en concordancia con el Plan de Comunicación del proyecto).

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. Analizar la documentación o

estado del arte

Tiene que ser algo medible,

mejor incluso si se puede medir en % de avance

1 vez por semana

Director del proyecto


Correo electrónico

1.2. Planificación

Definición de preliminares del proyecto

1 vez por semana

Eduardo Filomena

Eduardo Filomena

Correo electrónico

1.3. Aprobación

Visto bueno. 1 vez por semana

Eduardo Filomena

Eduardo Filomena

Correo electrónico

1.4. Exposición del

anteproyecto.

Presentación o

diapositivas

1 vez por semana

Dr. Ing. Ariel Lutenberg


Correo electrónico

Página 26 de 31




2.1 Hardware

Informe escrito 1 vez cada dos semanas

Eduardo Filomena

Eduardo Filomena

Correo electrónico

2.2 Software


Eduardo Filomena

Eduardo Filomena

Correo electrónico

2.3

Documentación

Informe escrito

1 vez cada dos semanas

Eduardo Filomena

Eduardo Filomena

Correo electrónico

3.1. Diagrama de módulos

Diagramas de terminados.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

3.2. Diagrama de actividades y secuencias.



Eduardo Filomena

Eduardo Filomena

Correo electrónico

3.3. Diagrama de interfaces entre

módulos.



Eduardo Filomena

Eduardo Filomena

Correo electrónico

3.4 Documentación

Informe escrito


Eduardo Filomena

Eduardo Filomena

Correo electrónico

4.1 Búsqueda de material

bibliográfico.

Finalización de búsqueda de

datos.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

4.2 Búsqueda y selección de

componentes.

Finalización de búsqueda de

datos.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

4.3 Diseño de esquemáticos.

Esquemáticos 1 vez cada dos semanas

Eduardo Filomena

Eduardo Filomena

Correo electrónico

4.4 Revisión de los

esquemáticos.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

4.5 Diseño de las PCB (30 hs)

Archivos gerber y layouts.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

Página 27 de 31




4.6 Revisión del diseño de las

PCB


Eduardo Filomena

Eduardo Filomena

Correo electrónico

4.7 Documentación

Informe escrito


Eduardo Filomena

Eduardo Filomena

Correo electrónico

5.1. Pruebas individuales de cada módulo de

hardware.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

5.2 Pruebas de los módulos de

hardware integrados.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

5.3 Pruebas experimentales.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

6.1. Desarrollar función para controlar la

temperatura de la cámara

termostatizada.

Generar el firmware para

que los actuadores de temperatura trabajen de acuerdo al punto de

operación.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

6.2. Desarrollar función para controlar las

bombas peristálticas

Generar el firmware para que las bombas hagan fluir agua

según el volumen deseado.


Eduardo Filomena

Eduardo Filomena

Correo electrónico


bomba de aire


controlar la velocidad de

flujo de la bomba de aire.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

Página 28 de 31




6.4. Desarrollar funciones para

controlar la pantalla táctil.


mostrar el menú de usuario.


Eduardo Filomena

Eduardo Filomena

Correo electrónico


válvulas.


accionar las válvulas.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

6.6 Desarrollar función para medir DBO

desde el sensor (electrodo).

Leer los valores de mV que genera el

sensor.


Eduardo Filomena

Eduardo Filomena

Correo electrónico

6.7 Documentación

Informe escrito


Eduardo Filomena

Eduardo Filomena

Correo electrónico

7.1. Test unitario de cada función

de software.

Test unitario de funciones.


Diego Fernández

Diego Fernández

Correo electrónico

7.2. Test funcional por

bloques de código.

Test de tipo funcional por

bloques de código y con

implementación

en forma parcial del hardware.


Diego Fernández

Diego Fernández

Correo electrónico

7.3. Ensayos de verificación.

Ensayos de verificación.


Diego Fernández

Diego Fernández

Correo electrónico

7.4. Ensayo final de validación.

Ensayo final de validación.


Eduardo Filomena

Diego Fernández

Correo electrónico

8.1. Redacción del informe de

avance.

Informe escrito

Eduardo Filomena


Eduardo Filomena

Correo electrónico

Página 29 de 31




8.2. Redacción de la memoria

escrita.

Presentación de la memoria.



Eduardo Filomena

Correo electrónico

8.3. Preparación de la

presentación pública del

trabajo.

Defensa del trabajo ante el

jurado.



Eduardo Filomena

Correo electrónico

17. Procesos de cierre Luego de finalizar el proyecto se desarrollarán las siguientes actividades: Establecer si el proyecto siguió las líneas de trabajo u hoja de ruta:

Persona a cargo: Responsable del proyecto Procedimiento a aplicar: Listar todos los requerimientos planteados y en función de ellos determinar si el sistema los cumple. El porcentaje de requerimientos cumplidos determinará su grado de calidad. Así mismo, lo anterior debe ser consignado en una planilla de seguimiento.

Identificar metodologías de trabajo durante el proyecto:

Persona a cargo: Responsable del proyecto Procedimiento a aplicar: A partir del listado de tareas del WBS se tendrá una planilla de seguimiento de la metodología aplicada para resolverlas. A su vez servirá como realimentación para hacer mejoras futuras.

Organizar acto de agradecimiento:

Persona a cargo: Responsable del proyecto Procedimiento a aplicar: Luego de defendido el proyecto ante el jurado, se procederá a agradecer a cada miembro del jurado y del equipo de trabajo. Si el jurado lo califica como exitoso luego se hará un brindis con las personas involucradas con champagne.

Referencias

Página 30 de 31




[1] S. Jouanneau, L. Recoules, M.J. Durand, A. Boukabache, V. Picot, Y. Primault, A. Lakel, M. Sengelin, B. Barillon, G. Thouand, Methods for assessing biochemical oxygen demand (BOD): A review, Water Research, Volume 49, 1 February 2014, Pages 62-82, ISSN 0043-1354, https://doi.org/10.1016/j.watres.2013.10.066. (http://www.sciencedirect.com/science/article/pii/S0043135413008920)

Página 31 de 31

Sistema Embebido para medir la Demanda Bioquímica de...

Documents

Transcript of Sistema Embebido para medir la Demanda Bioquímica de...