avance del informe

master
Bruno Berlatzky 4 days ago
parent be26b497db
commit 61f9ad3d3b

@ -49,8 +49,7 @@
"title": "Auxiliar" "title": "Auxiliar"
} }
} }
], ]
"currentTab": 1
} }
], ],
"direction": "vertical" "direction": "vertical"
@ -200,10 +199,10 @@
"pdf-plus:PDF++: Toggle auto-paste": false "pdf-plus:PDF++: Toggle auto-paste": false
} }
}, },
"active": "8aee57594eb5d7de", "active": "b278be46751c1b78",
"lastOpenFiles": [ "lastOpenFiles": [
"Gestión de proyectos/Informe Practica/Informe De Gestion de proyectos.md",
"Auxiliar.md", "Auxiliar.md",
"Gestión de proyectos/Informe Practica/Informe De Gestion de proyectos.md",
"Gestión de proyectos/Informe Practica/Consultas sobre el informe.md", "Gestión de proyectos/Informe Practica/Consultas sobre el informe.md",
"Gestión de proyectos/Informe Practica/Template_Gestion_Proyectos_TC024_v2_2.pdf", "Gestión de proyectos/Informe Practica/Template_Gestion_Proyectos_TC024_v2_2.pdf",
"Materiales/Adicionales/sensors-14-02595.pdf", "Materiales/Adicionales/sensors-14-02595.pdf",

@ -1,19 +1,4 @@
### 0.1. Matriz de Riesgos Proyecto Radar UWB
| Riesgo | Descripción | Impacto | Probabilidad | Mitigación |
| --------------------------------------------- | -------------------------------------------------------------------------------------------------------- | --------- | ------------ | --------------------------------------------------------------------------------------------- |
| Falta de precisión del radar UWB | El radar puede no detectar con suficiente fidelidad señales respiratorias o cardíacas en recién nacidos. | 8 - Alto | 7 - Media | Realizar pruebas en etapas tempranas, usar sensores de referencia. |
| Dificultades en el desarrollo de algoritmos | El procesamiento de señales puede no lograr distinguir señales fisiológicas reales del ruido. | 9 - Alto | 8 - Alta | Incorporar expertos en bioseñales desde el inicio. |
| Interferencia electromagnética | El entorno doméstico podría generar interferencias que afecten al radar UWB. | 6 - Medio | 6 - Media | Realizar pruebas en diferentes entornos reales; incorporar filtros o corrección por software. |
| Inestabilidad de la conectividad Wi-Fi | Puede fallar la conexión entre dispositivo y servidor/plataforma. | 7 - Medio | 8 - Alta | Incorporar buffers locales y reconexión automática. |
| Problemas de compatibilidad hardware/software | Integrar distintos componentes puede generar errores de compatibilidad. | 6 - Medio | 6 - Media | Elegir componentes con interfaces estándar, plan de pruebas integrales. |
| Dificultad para conseguir muestras reales | Falta de acceso a bebés o familias dispuestas a participar en validaciones. | 8 - Alto | 7 - Media | Establecer acuerdos con instituciones pediátricas o centros de salud. |
| | | | | |
## 1. Tipo de proyecto ## 1. Tipo de proyecto
Este proyecto se enmarca dentro del desarrollo de un producto tecnológico con un fuerte componente de investigación aplicada. Su objetivo es explorar el uso de un elemento tecnológico existente —el radar UWB— aplicado al monitoreo no invasivo de funciones vitales en bebés durante el sueño. Este proyecto se enmarca dentro del desarrollo de un producto tecnológico con un fuerte componente de investigación aplicada. Su objetivo es explorar el uso de un elemento tecnológico existente —el radar UWB— aplicado al monitoreo no invasivo de funciones vitales en bebés durante el sueño.
@ -76,3 +61,101 @@ No se trata de un producto de implementación masiva ni de aplicación única, s
| Acceso no autorizado a la plataforma (ciberataque) | 9 | 4 | 8 | 288 | Puede comprometer datos sensibles y afectar la reputación del servicio. | | Acceso no autorizado a la plataforma (ciberataque) | 9 | 4 | 8 | 288 | Puede comprometer datos sensibles y afectar la reputación del servicio. |
| Incompatibilidad con routers del usuario | 5 | 7 | 4 | 140 | Puede impedir la conexión inicial. Impacto moderado pero común. | | Incompatibilidad con routers del usuario | 5 | 7 | 4 | 140 | Puede impedir la conexión inicial. Impacto moderado pero común. |
| Ambientes con humedad o polvo excesivo dañan el equipo | 6 | 5 | 7 | 210 | Puede provocar fallas de hardware en hogares con condiciones adversas. | | Ambientes con humedad o polvo excesivo dañan el equipo | 6 | 5 | 7 | 210 | Puede provocar fallas de hardware en hogares con condiciones adversas. |
### 2.4. Entregables
El avance del proyecto se medirá a través de tres entregables principales, que representan hitos clave dentro del desarrollo:
- **Entregable 1: Módulo de medición construido y evaluación de costos**
Este entregable corresponde a la finalización del módulo de medición, lo que permite iniciar la generación de mediciones reales.
Además, debe realizarse una comparación entre el costo real de construcción del módulo y la estimación original.
- Si se detecta una desviación significativa en el presupuesto, deberá actualizarse el análisis de factibilidad económica del proyecto en función de los nuevos costos.
- **Entregable 2: Prototipo funcional de factibilidad técnica**
Este entregable implica la construcción de un prototipo que permita validar la viabilidad técnica del sistema. El prototipo debe:
- Adquirir señales fisiológicas reales de una persona.
- Transmitir los datos a una computadora mediante conexión Wi-Fi, sin necesidad de un servidor.
- Incluir una interfaz embebida básica para interactuar con el sistema.
- **Entregable 3: Mínimo producto viable (MVP) finalizado**
Este entregable representa la integración completa de todos los componentes del sistema, en una versión funcional y coherente. El MVP debe incluir:
- Hardware completo y ensamblado, con el radar integrado.
- Método de procesamiento de señales operativo.
- Interfaz de usuario embebida.
- Servidor remoto configurado y funcional.
- Aplicación web o móvil accesible para los usuarios.
- Estructura física (gabinete) lista para uso final.
Este entregable representa una versión lista para validación final o para un posible despliegue inicial en contexto real.
### 2.5. Tabla de tareas actualizada con T18 como bloque previo a validación
| ID | Tarea | Depende de... | Pertenece a | Descripción breve |
| --- | ---------------------------------------------- | ---------------- | ------------------------ | --------------------------------------------------------------------------------------------- |
| T1 | Diseño del módulo de medición | — | Hardware | Diseño electrónico y estructural del módulo con radar UWB para adquirir señales. |
| T7 | Diseño del protocolo de medición | — | Validación | Definición del entorno, frecuencia, duración y condiciones para la toma de datos en personas. |
| T2 | Estudio para obtención de mediciones | T1, T7 | Validación | Planificación y ejecución de la recolección de mediciones fisiológicas reales de prueba. |
| T3 | Diseño de los módulos por separado | — | Hardware/Infraestructura | Diseño técnico individual del hardware, servidor, interfaz y sistema embebido. |
| T4 | Integración de todos los módulos | T3 | Hardware | Ensamblado e interconexión funcional del sistema completo. |
| T5 | Estudio y diseño del algoritmo | T1 | Procesamiento | Desarrollo del método de procesamiento de señales y definición del algoritmo. |
| T6 | Validación del algoritmo | T2, T5 | Procesamiento/Validación | Evaluación del algoritmo usando datos reales recolectados con el módulo. |
| T8 | Diseño de API y aplicación de usuario | T3 | Interfaz de Usuario | Desarrollo de la API y de la interfaz (web o móvil). |
| T9 | Configuración del servidor | T3 | Infraestructura Remota | Implementación del servidor para almacenamiento y consulta de datos. |
| T18 | Diseño del sistema de alimentación y autonomía | T3 | Hardware | Diseño del subsistema de energía y evaluación de autonomía del dispositivo. |
| T10 | Validación del prototipo | T4, T5, T18 | Validación | Verificación funcional del sistema ensamblado. |
| T11 | Diseño y construcción del gabinete | T4 | Hardware | Desarrollo de la estructura física del dispositivo. |
| T12 | Estudio normativo para cumplimiento del MVP | T4 | Validación/Regulación | Revisión de normativas técnicas que el MVP debe cumplir. |
| T13 | Homologación médica | T6, T12 | Validación/Regulación | Validación formal del sistema frente a criterios médicos. |
| T16 | Pruebas de usabilidad con usuarios finales | T8, T10 | Validación/UX | Validación de experiencia de usuario en condiciones reales o simuladas. |
| T17 | Documentación técnica del sistema completo | T10, T11, T8, T9 | Documentación | Generación de documentación técnica para validación, mantenimiento y regulación. |
### 2.6. Diseño preliminar
El diseño preliminar del producto abarca tres áreas fundamentales que aseguran su correcto funcionamiento: el hardware, el algoritmo de procesamiento de datos y la interacción del usuario a través del servidor y la aplicación. A continuación, se detallan los componentes y el flujo de trabajo propuestos para cada una de estas áreas.
1. **Diseño del Hardware:**
- **Módulo de radar DWM1000**: Emite y recibe ondas electromagnéticas para medir variaciones y extraer los datos necesarios.
- **Raspberry Pi Pico**: Controla los periféricos y gestiona la conectividad Wi-Fi, además de procesar los datos y asegurar la comunicación.
- **Display con cuatro botones**: Permite la interacción local con el sistema, visualizando los datos y realizando ajustes básicos.
- **Fuente de alimentación**: Suministra energía a los componentes, principalmente al Raspberry Pi Pico y otros módulos conectados.
2. **Diseño del Software (Algoritmo de Procesamiento de Datos):**
- **Análisis espectral**: Utilizado para estimar la **frecuencia respiratoria** a partir de los datos obtenidos por el radar.
- **Análisis de formas de onda**: Permite identificar los patrones del ritmo cardíaco, detectando los cuatro ciclos principales presentes en la señal.
3. **Diseño del Servidor y la Aplicación de Usuario:**
- **Servidor**: Se encarga de recibir los datos del dispositivo, procesar las señales y generar alertas automáticas para los usuarios si los parámetros monitoreados exceden los límites establecidos.
- **Aplicación de usuario**: Permite la interacción con el sistema, ofreciendo una interfaz para consultar los datos, recibir notificaciones y revisar el historial de mediciones.
#### 2.6.1. Requerimientos tecnicos
Los requerimientos técnicos abarcan tanto el hardware como el software necesario para el correcto funcionamiento del sistema. A continuación, se detallan los requisitos para cada uno de los componentes clave.
1. **Requerimientos del Hardware:**
- **Módulo de medición (Radar UWB)**:
El módulo de medición debe ser capaz de utilizar señales de radar UWB para medir las variables deseadas. Debe tener la capacidad de modular y demodular estas señales, así como muestrear la señal con precisión. Además, debe poder comunicarse con el centro de control para transmitir los datos obtenidos.
- **Módulo central de control**:
El módulo central debe ser capaz de manejar los periféricos conectados, tales como el display, el periférico de comunicación Wi-Fi y el periférico de medición. Este módulo debe garantizar la recuperación de todos los datos generados por el módulo de medición sin pérdida de información, volcando estos datos al módulo Wi-Fi para su transmisión al servidor a través de la red Wi-Fi sin pérdida de datos. La tasa de datos del radar es de aproximadamente **1 megabyte por segundo**, por lo que el módulo de control debe ser capaz de manejar esta cantidad de datos sin comprometer la integridad de la transmisión.
- **Requisitos de conectividad Wi-Fi**:
El módulo Wi-Fi debe ser capaz de conectarse a Internet y manejar un tránsito de datos de aproximadamente 1 megabyte por segundo sin pérdidas. También debe ser capaz de reconectarse automáticamente en caso de fluctuaciones o pérdida de conexión de la señal Wi-Fi.
2. **Requerimientos del Software:**
- El software debe ser capaz de procesar la señal cruda obtenida por el radar, realizar un análisis adecuado y extraer la **frecuencia cardíaca** y la **frecuencia respiratoria** del bebé, lidiando con el ruido presente en la señal.
- **Mitigación de movimientos**:
El software debe ser capaz de identificar y manejar los movimientos del bebé durante la medición. Debe poder filtrar los espasmos y movimientos más pequeños, descartando segmentos de datos no tan significativos sin perder precisión en las estimaciones. Para movimientos más grandes, como cambios de posición, el software debe continuar con la medición y registrar cualquier evento relevante que haya ocurrido.
3. **Requerimientos del Servidor:**
- El servidor debe ser capaz de recibir datos de múltiples usuarios simultáneamente. Debe ser diseñado de manera escalable para manejar el aumento en la cantidad de usuarios y datos sin afectar el rendimiento.
- El servidor debe procesar los datos obtenidos y generar un informe de los resultados, proporcionando un **pseudo diagnóstico** que brinde información básica sobre el comportamiento del bebé durante la noche.
4. **Requerimientos de la Aplicación de Usuario:**
- La aplicación debe ofrecer varias formas de contacto con la empresa proveedora del servicio para recibir soporte técnico.
- Debe tener un **historial** de las mediciones realizadas en diferentes días, permitiendo al usuario consultar resultados previos.
- La aplicación debe contar con un sistema de **notificación** que informe al usuario sobre el diagnóstico generado después de cada medición nocturna.

@ -70,31 +70,80 @@ Contribuir a resolver la falta de soluciones accesibles y no invasivas para el m
### 2.3. Entregables mensurables ### 2.3. Entregables mensurables
Para considerar alcanzados los objetivos del proyecto, se deberán cumplir los siguientes entregables mensurables: El avance del proyecto se medirá a través de tres entregables principales, que representan hitos clave dentro del desarrollo:
- **Entregable 1: Módulo de medición construido y evaluación de costos**
Este entregable corresponde a la finalización del módulo de medición, lo que permite iniciar la generación de mediciones reales.
Además, debe realizarse una comparación entre el costo real de construcción del módulo y la estimación original.
- Si se detecta una desviación significativa en el presupuesto, deberá actualizarse el análisis de factibilidad económica del proyecto en función de los nuevos costos.
- **Entregable 2: Prototipo funcional de factibilidad técnica**
Este entregable implica la construcción de un prototipo que permita validar la viabilidad técnica del sistema. El prototipo debe:
- Adquirir señales fisiológicas reales de una persona.
- Transmitir los datos a una computadora mediante conexión Wi-Fi, sin necesidad de un servidor.
- Incluir una interfaz embebida básica para interactuar con el sistema.
- **Entregable 3: Mínimo producto viable (MVP) finalizado**
Este entregable representa la integración completa de todos los componentes del sistema, en una versión funcional y coherente. El MVP debe incluir:
- Hardware completo y ensamblado, con el radar integrado.
- Método de procesamiento de señales operativo.
- Interfaz de usuario embebida.
- Servidor remoto configurado y funcional.
- Aplicación web o móvil accesible para los usuarios.
- Estructura física (gabinete) lista para uso final.
Este entregable representa una versión lista para validación final o para un posible despliegue inicial en contexto real.
## 3. Evaluación del proyecto
- **Módulo de medición funcional con radar UWB:** desarrollo de una unidad independiente, capaz de adquirir señales fisiológicas reales de sujetos de prueba. El módulo deberá incluir un mecanismo que permita transferir los datos registrados a una computadora, de modo que puedan ser utilizados para análisis y validación. Además, debe estar diseñado para permitir su integración posterior con el hardware principal del sistema, garantizando compatibilidad eléctrica y lógica entre ambos. ### 3.1. Tipo de proyecto
- **Banco de mediciones reales generado:** conjunto de registros obtenidos bajo condiciones representativas, incluyendo tanto mediciones tomadas con el módulo de medición desarrollado como mediciones complementarias mediante métodos tradicionales u otros medios disponibles que permitan, en la medida de lo posible, validar los datos obtenidos por el sistema. ### 3.2. Evaluación de factibilidad técnica
#### 3.2.1. Requerimientos técnicos
- **Método de procesamiento de señal desarrollado e implementado:** diseño e implementación de un algoritmo que permita, a partir de las señales adquiridas, extraer los parámetros fisiológicos de interés (frecuencia respiratoria y cardíaca) de forma precisa, robusta y evaluable en distintos entornos de ejecución. El método deberá ser capaz de filtrar ruido, compensar interferencias y manejar movimientos involuntarios leves o moderados del bebé durante el sueño, manteniendo la precisión de las mediciones dentro de rangos aceptables. Los requerimientos técnicos abarcan tanto el hardware como el software necesario para el correcto funcionamiento del sistema. A continuación, se detallan los requisitos para cada uno de los componentes clave.
- **Validación del método de procesamiento con datos reales:** aplicación del algoritmo desarrollado sobre el banco de mediciones obtenidas, con el objetivo de evaluar su desempeño, precisión y robustez ante variabilidad natural y ruido de las señales. 1. **Requerimientos del Hardware:**
- **Módulo de medición (Radar UWB)**:
El módulo de medición debe ser capaz de utilizar señales de radar UWB para medir las variables deseadas. Debe tener la capacidad de modular y demodular estas señales, así como muestrear la señal con precisión. Además, debe poder comunicarse con el centro de control para transmitir los datos obtenidos.
- **Circuito hardware integrado y funcional:** desarrollo de la placa principal del sistema, con capacidad para conectarse al módulo de medición, integrar el módulo Wi-Fi, incluir el sistema de visualización local (pantalla y botones) y contar con una solución de alimentación que permita su funcionamiento autónomo. - **Módulo central de control**:
El módulo central debe ser capaz de manejar los periféricos conectados, tales como el display, el periférico de comunicación Wi-Fi y el periférico de medición. Este módulo debe garantizar la recuperación de todos los datos generados por el módulo de medición sin pérdida de información, volcando estos datos al módulo Wi-Fi para su transmisión al servidor a través de la red Wi-Fi sin pérdida de datos. La tasa de datos del radar es de aproximadamente **1 megabyte por segundo**, por lo que el módulo de control debe ser capaz de manejar esta cantidad de datos sin comprometer la integridad de la transmisión.
- **Estructura externa del dispositivo construida:** diseño y fabricación de la estructura que contenga y proteja los componentes electrónicos del sistema, permitiendo su manipulación segura y su uso adecuado en un entorno doméstico. - **Requisitos de conectividad Wi-Fi**:
El módulo Wi-Fi debe ser capaz de conectarse a Internet y manejar un tránsito de datos de aproximadamente 1 megabyte por segundo sin pérdidas. También debe ser capaz de reconectarse automáticamente en caso de fluctuaciones o pérdida de conexión de la señal Wi-Fi.
- **Conectividad Wi-Fi estable:** el sistema debe ser capaz de transmitir datos de forma segura y confiable hacia un servidor remoto, manejando correctamente reconexiones y pérdidas temporales de red. 2. **Requerimientos del Software:**
- El software debe ser capaz de procesar la señal cruda obtenida por el radar, realizar un análisis adecuado y extraer la **frecuencia cardíaca** y la **frecuencia respiratoria** del bebé, lidiando con el ruido presente en la señal.
- **Servidor en la nube en funcionamiento:** debe estar disponible una infraestructura capaz de recibir, almacenar y organizar los datos provenientes de uno o más dispositivos. - **Mitigación de movimientos**:
El software debe ser capaz de identificar y manejar los movimientos del bebé durante la medición. Debe poder filtrar los espasmos y movimientos más pequeños, descartando segmentos de datos no tan significativos sin perder precisión en las estimaciones. Para movimientos más grandes, como cambios de posición, el software debe continuar con la medición y registrar cualquier evento relevante que haya ocurrido.
- **Plataforma web o móvil accesible:** los usuarios deben poder acceder a un entorno digital donde consultar reportes generados a partir de los datos recolectados, visualizar tendencias e historial, y recibir alertas configurables. 3. **Requerimientos del Servidor:**
- El servidor debe ser capaz de recibir datos de múltiples usuarios simultáneamente. Debe ser diseñado de manera escalable para manejar el aumento en la cantidad de usuarios y datos sin afectar el rendimiento.
Estos entregables permiten verificar el correcto funcionamiento del sistema de extremo a extremo, y constituyen los criterios fundamentales para validar el mínimo producto viable (MVP) propuesto. - El servidor debe procesar los datos obtenidos y generar un informe de los resultados, proporcionando un **pseudo diagnóstico** que brinde información básica sobre el comportamiento del bebé durante la noche.
## 3. Evaluación del proyecto 4. **Requerimientos de la Aplicación de Usuario:**
- La aplicación debe ofrecer varias formas de contacto con la empresa proveedora del servicio para recibir soporte técnico.
### 3.1. Tipo de proyecto - Debe tener un **historial** de las mediciones realizadas en diferentes días, permitiendo al usuario consultar resultados previos.
### 3.2. Evaluación de factibilidad técnica - La aplicación debe contar con un sistema de **notificación** que informe al usuario sobre el diagnóstico generado después de cada medición nocturna.
#### 3.2.2. Diseño preliminar
El diseño preliminar del producto abarca tres áreas fundamentales que aseguran su correcto funcionamiento: el hardware, el algoritmo de procesamiento de datos y la interacción del usuario a través del servidor y la aplicación. A continuación, se detallan los componentes y el flujo de trabajo propuestos para cada una de estas áreas.
1. **Diseño del Hardware:**
- **Módulo de radar DWM1000**: Emite y recibe ondas electromagnéticas para medir variaciones y extraer los datos necesarios.
- **Raspberry Pi Pico**: Controla los periféricos y gestiona la conectividad Wi-Fi, además de procesar los datos y asegurar la comunicación.
- **Display con cuatro botones**: Permite la interacción local con el sistema, visualizando los datos y realizando ajustes básicos.
- **Fuente de alimentación**: Suministra energía a los componentes, principalmente al Raspberry Pi Pico y otros módulos conectados.
2. **Diseño del Software (Algoritmo de Procesamiento de Datos):**
- **Análisis espectral**: Utilizado para estimar la **frecuencia respiratoria** a partir de los datos obtenidos por el radar.
- **Análisis de formas de onda**: Permite identificar los patrones del ritmo cardíaco, detectando los cuatro ciclos principales presentes en la señal.
3. **Diseño del Servidor y la Aplicación de Usuario:**
- **Servidor**: Se encarga de recibir los datos del dispositivo, procesar las señales y generar alertas automáticas para los usuarios si los parámetros monitoreados exceden los límites establecidos.
- **Aplicación de usuario**: Permite la interacción con el sistema, ofreciendo una interfaz para consultar los datos, recibir notificaciones y revisar el historial de mediciones.
Loading…
Cancel
Save