TesisGradoSuribresta/BovedasObsidian/Tesis De Grado Berlatzky/Auxiliar.md

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

El trabajo parte de una tecnología ya disponible, pero la resignifica al diseñar un sistema completo que permita su aplicación en un entorno doméstico, con foco en el seguimiento fisiológico preventivo. El enfoque combina tareas de diseño técnico, implementación de algoritmos, integración de hardware y desarrollo de interfaces de usuario.

El resultado esperado es un sistema funcional y validado (mínimo producto viable), orientado a resolver una necesidad específica. No se trata de un producto de implementación masiva ni de aplicación única, sino de una solución exploratoria con potencial de adaptación a distintos escenarios o entornos clínicos especializados.

## 2. 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.

El trabajo combina diseño técnico, desarrollo de hardware, implementación de algoritmos de procesamiento de señales y diseño de interfaces de usuario, integrando conocimientos de distintas disciplinas. ==Al tener un enfoque centrado en la investigación y la exploración de nuevas aplicaciones, el proyecto conlleva un costo elevado tanto en términos de desarrollo como en generación de conocimiento.==

No se trata de un producto de implementación masiva ni de aplicación única, sino de una solución específica con valor en contextos puntuales, que se busca vender en un modelo de suscripción a parejas con bebes recién nacidos. 

### 2.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. |
| Errores en los datos recolectados | Mala calidad de las mediciones por condiciones no controladas. | 7 - Medio | 7 - Media | Diseñar protocolos de recolección robustos, registrar metadatos. |
| Resultados no concluyentes | El método no logra validarse experimentalmente. | 9 - Alto | 6 - Baja | Documentar todos los pasos, dejar abierta la iteración de diseño. |
| Retrasos en la fabricación de hardware | Fallas en la entrega de componentes o problemas de diseño. | 6 - Medio | 6 - Media | Planificar buffers de tiempo, diseño modular. |
| Diseño físico poco amigable | El gabinete puede no resultar adecuado para entornos reales de uso. | 5 - Medio | 5 - Media | Testeo con familias desde el prototipo funcional. |
| Dificultad para coordinar trabajo multidisciplinario | El proyecto integra electrónica, software, procesamiento de señales y validación clínica. | 7 - Alto | 6 - Media | Establecer cronogramas claros y comunicación constante entre equipos. |
| Desviación del objetivo de MVP | Riesgo de sobrediseñar el sistema e ir más allá del producto mínimo viable. | 6 - Medio | 7 - Alta | Revisiones periódicas del alcance, definir límites del prototipo. |
| Cuestiones éticas en el monitoreo de bebés | Requiere consentimiento informado, uso responsable y privacidad. | 8 - Alto | 6 - Media | Asesoramiento legal y ético desde el inicio. |
| Requisitos regulatorios no previstos | Aunque es un MVP, podría entrar en conflicto con normativas médicas. | 7 - Alto | 5 - Baja | Consultar marcos normativos locales e internacionales desde el diseño. |

### 2.2. Riesgos del Desarrollo Comercial y Post-lanzamiento

| Riesgo | Descripción | Impacto | Probabilidad | Mitigación |
|--------|-------------|---------|--------------|------------|
| Problemas de stock o disponibilidad | Si la demanda supera la producción, no se podrá responder en tiempo. | 7 - Alto | 6 - Media | Planificar escalabilidad de ensamblado, tercerización parcial si es necesario. |
| Fallas o caídas del servidor remoto | Puede dejar inactiva la plataforma de monitoreo para los usuarios. | 9 - Crítico | 6 - Media | Infraestructura con redundancia, backups automáticos, monitoreo 24/7. |
| Dificultades con el mantenimiento de equipos alquilados | Equipos dañados o fuera de funcionamiento por mal uso o fallas técnicas. | 8 - Alto | 7 - Media | Política clara de reposición, logística inversa y mantenimiento periódico. |
| Escepticismo inicial del mercado | Dificultad para convencer a familias del valor del sistema no invasivo. | 6 - Medio | 7 - Alta | Estrategia comunicacional basada en evidencia y testimonios. |
| Baja tasa de retención de clientes | Usuarios que prueban el servicio pero lo abandonan rápido. | 6 - Medio | 6 - Media | Ofrecer soporte postventa, prueba gratuita, alertas de salud atractivas. |
| Saturación de soporte técnico | Muchos usuarios solicitando ayuda simultáneamente. | 7 - Alto | 5 - Media | Escalar el sistema de soporte gradualmente, incluir FAQs y soporte automatizado. |
| Costos operativos mayores a lo previsto | Costos de logística, mantenimiento, servidor o atención al cliente pueden ser altos. | 8 - Alto | 6 - Media | Modelar el flujo financiero con escenarios variables, ajustar tarifa de alquiler. |
| Problemas legales por uso indebido del dispositivo | El mal uso del sistema podría generar consecuencias legales o reputacionales. | 8 - Alto | 4 - Baja | Manuales de uso claros, cláusulas legales en el contrato de alquiler. |


### 2.3. ANFE Técnico Externo – Formato SOD (Severidad – Ocurrencia – Detección)

| Falla Técnica Externa | Severidad (S) | Ocurrencia (O) | Detección (D) | RPN (S×O×D) | Observaciones |
|------------------------|---------------|----------------|----------------|-------------|----------------|
| Interferencia electromagnética afecta la señal UWB | 7 | 6 | 6 | 252 | Puede degradar o distorsionar mediciones; depende del entorno del usuario. |
| Corte de servicio del servidor o nube | 9 | 5 | 7 | 315 | Inhabilita visualización de datos y alertas. Impacta en la confianza del usuario. |
| Red Wi-Fi hogareña inestable o débil | 6 | 8 | 5 | 240 | Común en algunos hogares. Puede dificultar la transmisión de datos. |
| Saturación del backend por aumento de usuarios | 8 | 6 | 6 | 288 | Si el sistema no escala correctamente, puede dejar inoperables todas las unidades. |
| Falla eléctrica por microcortes o baja tensión | 6 | 5 | 6 | 180 | Puede apagar o dañar el equipo si no está protegido. |
| Restricciones legales sobre el uso de UWB | 8 | 4 | 9 | 288 | En algunos países o regiones no está permitido el uso libre del espectro. |
| 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. |
| 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.