En la descripción del documento explica la información contenida en la trama y cómo se debe interpretar. A partir de ahí, crear un script que genere tramas de ese estilo y las almacene en un fichero, por ejemplo.

No tengo muy claro qué es "setting" y qué es "measure". ¿Influye uno en el otro?

Se me ocurren tres

• Médicos/enfermeros/as.
• Personal técnico que va a instalar el programa o atender cuando se produzca algún error.
• Desarrollador.

Historia de usuario

Dado que el dispositivo está conectado a un respirador
Cuando los valores de las variables del respirador estén disponibles
Entonces los valores serán procesados o almacenados.

Descripción

En la fase inicial, tiene que estar claro cómo se obtienen datos, en qué formato, cómo validarlos, qué tipo tienen, y todo lo necesario para que los datos que se pasen al resto de la aplicación sean correctos.

Resumen de los cambios

TBD

Subtareas

• Generar una lista plausible de tramas #19
• Procesar o almacenar los datos. Empezar por issue #20
• Comprobar que los datos están dentro de los rangos establecidos por el médico y sino que suene una alarma.
• Comprobar que no hay errores en la secuencia de datos, sino suena una alarma.

Dependencias

Historia

Dado que el dispositivo está conectado a un respirador.
Cuando se quieran cambiar parámetros de trabajo del respirador.
Entonces se mueven los encoders (diales) del respirador y se presionan para confirmar.

Descripción

Se deben mostrar los últimos valores de:

• Respiraciones por minuto.
• Presión pico.
• PEEP.
• Trigger de flujo.
• Rampa de subida.
  así como los valores nuevos antes de que el usuario confirme. Estos datos llegarán en la trama.

Resumen de los cambios

TBD

Subtareas

TBD

Dependencias

TBD

Tener una rama develop como referencia para el desarrollo.
Cada uno contribudor se genera su rama propia de develop y cuando quiera subir cambios lo hace a develop

Crear una implementación de referencia de la clase que obtenga datos del respirador, teniendo en cuenta todas las restricciones.

Historia

Dado que el dispositivo está conectado a un respirador.
Cuando los valores de las variables del respirador estén disponibles.
Entonces en la GUI puedo ver una gráfica de la presión y flujo de los últimos 3 minutos en intervalos de 1 segundo.

Descripción

TBD

Resumen de los cambios

TBD

Subtareas

TBD

Dependencias

TBD

Como programador quiero tener un dato en su valor raw pero también en el valor escalado teniendo en cuenta los valores de los encoders en un momento determinado.

Hay según lo he entendido cuatro variables

• Presión PEEP
• Presión Pico
• Frecuencia respiratoria (RPM)
• Volumen tidal

Trigger no sé si es una variable o no, la verdad. ¿Alguien lo puede aclarar?

Historia

Dado que un respirador (master arduino) está conectado al dispositivo en que corre este programa.
Cuando hay mas de un puerto en el dispositivo.
Entonces el programa comprueba que recibe paquetes correspondientes al respirador.

Descripción

Ahora mismo el puerto es hardcodeado en el script python. Se trata de que esto se automatice para disminuir la probabilidad de error humano por parte del sanitario.

Resumen de los cambios

TBD

Subtareas

TBD

Dependencias

TBD

def recv_packet_blocking(s):
    """Internal function to receive a Packet
    """
    packet = tx_frame()
    while s.in_waiting == 0: #waits until we receive any byte
        continue

    raw = s.read(ctypes.sizeof(packet)) #we already have readed the first byte
    #print("Readed raw: ")
    #print(raw)
    ctypes.memmove(ctypes.pointer(packet),raw,ctypes.sizeof(packet))
    return packet

que se llama desde

s = serial.Serial(port=available_ports[0], baudrate=115200, timeout=0.1)
    counter = 0

    while True:

        packet = recv_packet_blocking(s)
        print_packet(packet)

Usar una plantilla de un gitignore Python de Github, customizada para el proyecto.

Historia

Dado que hay un respirador conectado.
Cuando la aplicación esté ejecutándose en un ordenador.
Entonces no hay reinicios inesperados ni bloqueo del respirador en caso de no funcionar.

Descripción

En determinados sistemas operativos se producen cuelgues, o reinicios inesperados (actualizaciones, etc). En el OS que se instale se tiene que garantizar que esto no va a pasar.

Resumen de los cambios

TBD

Subtareas

TBD

Dependencias

TBD

Para poder llevar a cabo los tests.

De forma que el diseño sea lo más limpio posible. También usar buenas prácticas en el layout del repositorio.

Describir claramente, en historias de usuario, qué es lo que tenemos, qué es lo que hace falta, cuál es la interacción que se va a llevar a cabo. Así tendremos claro qué hay, qué se almacena, cuales son los tests que hay que pasar. Ejemplos de historias de usuario
Depende de #2

Historia

Dado que el dispositivo está conectado a un respirador.
Cuando los valores de las variables del respirador estén disponibles.
Entonces en la GUI puedo ver los últimos valores registrados incluyendo alarmas visuales.

Descripción

Se deben mostrar los últimos valores de:

• presión
• frecuencia respiratoria
• volumen tidal
• PEEP
• PINS (Presión inspiratoria)
  Y que se
• muestren alarmas en la GUI
• suenen alarmas
  en caso de que los valores estén fuera del rango fijado.

Resumen de los cambios

TBD

Subtareas

TBD

Dependencias

TBD

Historia

Dado que el dispositivo está conectado a un respirador.
Cuando quieren ajustarse los valores de la descripción.
Entonces estos van variando lentamente si se usa una rueda y no se cambian hasta que haya confirmación.

Descripción

Los siguientes valores

• RPM
• Presión pico
• Presión peep
• Disparo de flujo
• Rampa

se ajustan variando lentamente (TBD lo que es lentamente) si estoy moviendo un control tipo rueda
no se cambien al valor que se está visualizando hasta que confirme.

Resumen de los cambios

Fichero a fichero los cambios que hemos ido haciendo, siempre orientado al objetivo de la US

Subtareas

Dependencias

[HU4]

Propongo usar MKDocs para ir documentando el proyecto, además que con un comando va a permitir desplegar la docu en github con su pagina correspondiente.

Requisito: Tener algo para visualizar a las 17:00
Historia: avisando a las 14:30.

La solución in extremis que se ha aceptado es visualizar con:

• Programa python que lee los datos enviados por el controlador de arduino a través del puerto USB. Las especifcaciones son estas: https://docs.google.com/document/d/1lItbWZhYFjCUJKEzwG3V0N3ZbFNCW4r7WvXlSnQcjlk/edit?usp=sharing
• El programa python se los pasa a prometheus.
• Grafana los lee del puerto abierto por prometheus.

No es la solución final, es una solución para salir del paso.

Historia

Dado que hay un respirador conectado.
Cuando cuando se reciba una trama de datos.
Entonces queremos que no haya posibilidad de fallo debido a que se usan versiones distintas.

Descripción

Los valores de:

• versiones de protocolo.
• UUID (identificado universal único).
• numero de serie.
  y se da una alerta en el PC de un mensaje de alerta por pantalla indicando que podría haber un conflicto de versiones.

Resumen de los cambios

TBD

Subtareas

TBD

Dependencias

TBD

Añadir un Pipfile para crear el entorno y sus depencias.
Se propone usar un Python que sea mayor o igual a 3.6 (por ser el que tengan usados en los equipos).