Hace 5 meses | Por TDI a nitter.net
Publicado hace 5 meses por TDI a nitter.net

Me notificaron que mi controlador de la bomba de insulina tiene un error donde el punto decimal se elimina, es decir, cambia una dosis de 0,21 unidades a 21 unidades. Puedo reproducirlo aleatoriamente en torno a 1 de cada 5 veces por lo que probablemente sea un problema de corriente/condición de carrera*. Simplemente uno de los peores errores de software de los que he oído. El dispositivo es la app de Android insulet omnipod 5 (la única aplicación móvil disponible además de un controlador dedicado - iOS está programado para lanzar en 2024).

Comentarios

tdgwho

#1 Traducido " a lo bestia " como condición de carrera, salen cosas como esta:

"Una condición de carrera puede ocurrir en cualquier sistema eléctrico o electrónico en el que dos o más dispositivos o componentes comparten un recurso común. "

Puede que haya algo mal programado en la app y con otra cosa se sobreescriba el campo de la dosis (lo de la condición de carrera)

No me cuadra que tenga problemas de corriente, porque está convirtiendo la parte decimal a entera, probablemente un problema de unidades. Y se está poniendo el valor 21 en unas unidades cuando debería ser 0.21 en otras (100 veces mas pequeña)

tsumy

#1 Error de carrera, o condición de carrera.

Por ejemplo, cuando los eventos no se ejecutan de forma seguida si no en paralelo (threads / hilos) y terminan ejecutándose varias veces por error.

En este caso me imagino que habrá sido un 'hay que administrar dosis' (no llega la confirmación de que se ha terminado de administrar la dosis), se vuelve al punto de que la dosis ha de ser administrada. 5 veces. Más que suficiente para enviar a un paciente a un coma o muerte.

m

#13: Si no me equivoco una condición de carrera es, por ejemplo, si tengo un valor (un 8 ) y quiero sumarle otros dos (un 5 y un 3 ), y cada una de esas sumas las ejecutan un proceso diferente (A suma 5 y B suma 3), y ambos procesos corren en paralelo.

Lo que puede ocurrir es que el proceso A llega, lee el 8, lo almacena para seguidamente sumar el 5, obtener un 13 y guardarlo en la memoria donde estaba el 8. Si justo en ese momento, entre que se lee el 8 y se guarda el 13, salta el proceso B, puede ocurrir que este proceso B al leer se encontrará con un 8, sumará el 3 y escribirá un 11 en lugar del 8, si el proceso A ya había terminado, habrá puesto su 13, y este número será sustituído por un 11 por B, y si A todavía no había terminado cuando B haya terminado, lo que hará cuando termine será sobreescribir el 11 que había puesto B con un 13, en ambos casos el resultado sería erróneo (no es 16), y lo mismo pasaría si el orden fuera al revés (que B leyera primero y A entrase a funcionar antes de que B acabe).

Soluciones hay muchas, una de ellas es poner un semáforo para que no se choquen entre sí, pero eso ya es otra historia.

tsumy

#19 he padecido race Bugs de todos los tipos, y al final el que lo haya picado tendrá que averiguar que está pasando. Porque además está la vida de sus pacientes en juego.

Un race Como el que dices, donde dos hilos intentar calcular un valor y guardarlo en el mismo sitio pero aleatoriamente es muy raro de ver (aunque sea el ejemplo de primero de carrera) en el mundo real.

Si me llegase ese marrón, miraría si hay un posible evento de 'dosis administrada' que no está llegando, y puede ser incluso por un problema de hardware. 5 veces a este paciente son muchas.

porcorosso

#1 La manera más habitual de traducirlo es "condición de carrera".

Se trata del estado en el que el resultado de la ejecución de varios procesos depende del orden de ejecución: según cómo se vayan ejecutando las instrucciones el resultado final es distinto, por lo que si no se sincronizan bien éste puede ser impredecible.

https://forum.wordreference.com/threads/race-condition.2085679/

ccguy

#1 No tiene nada que ver con corriente, race conditions son un tipo de bug en software.

dudo

#21 y el software funciona en aparatos que usan… corriente, también hay bugs en el hardware.

https://es.m.wikipedia.org/wiki/Condición_de_carrera

ccguy

#39 claro hombre, y ocupa espacio físico, vamos a llamarlo algo relacionado 😁

Race condition es lo que es, y si se arregla actualizando software pues más claro...

mirav

#40 o hardware, ponte que algún inductor o condensador no esté bien dimensionado. Como ingeniero de software las condiciones de carrera siempre me parecieron de lo peor, pero diseñando circuitos eléctricos la cosa me parece bastante más complicada. quizás sea por mi poca pericia con el osciloscopio

D

#1 como ya han dicho muchos, lo más habitual es verlo traducido como "condición de carrera", pero creo que mejor traducción sería "error de concurrencia". Es un error que sucede cuando dos procesos modifican el mismo valor a la vez, si no está bien programado.

Manoel

#1 En programación multihilo, si dos o más hilos esperan a ser ejecutados y todos tienen la misma prioridad, no se puede asegurar que H hilo se vaya a ejecutar en una P posición ya que el orden para todos ellos es arbitrario.

u

#1 Las condiciones de carrera son errores de software que se producen cuando unos procedimientos que se ejecutan en paralelo no son capaces de alcanzar un resultado determinista, sino que cada vez generan un resultado distinto dependiendo de quien corra más y se ejecute primero. Son errores muy difíciles de diagnosticar porque los ordenadores actuales tienen muchos cores ejecutando distintos procesos a la vez, la duración de las instrucciones depende de muchísimos factores y es difícil razonar sobre todas las posibles formas en que se pueden ordenar las instrucciones de cada uno de los procedimientos.

Cuñado

#1 "race condition" se traduce como "condición de carrera" (aunque el significado de "condition" en este caso es "problema"), pero hay una actualización en el hilo en la que descarta que ése sea el origen del bug:

Update: not a race condition. Happens every time if you start using the carb-derived bolus calculator and then input a bolus override. Default setting for max bolus is 15 units so .15->15 units, if the user does not notice the change on confirmation modal. Max possible is .95->95

babybus

#1 condición de carrera

Yonseca

#1 Es un problema muy técnico y sí, se llama condición de carrera.

Y una putada de detectar y solucionar, por cierto. Pero deja claro que la app está fatal programada. Qué miedo.

tdgwho

#7 Hombre si, si hay alternativa y no te sientes bien usándolo, pos oye, solo faltaría lol

De todos modos el índice de fallos de esas bombas es muy bajo, realmente puede que aun a pesar de esta noticia, sea mas probable que te pinches mal y te atravieses una vena y vayas por ahi como un cerdo el dia de matanza.

The_Ignorator

#9 Sí, sí, aunque el índice de fallos sea bajo.....es como todo: percepción del riesgo, y valorar si te merece la pena.
Luego soy de los que se pirran en subirse en una montaña rusa, pero con esto me cago lol

Con el estilo manual en 25 años los accidentes que he podido tener han sido mínimos, realmente graves 1 o 2, y casi todos ellos se hubiera producido el error igual con la bomba (si la hubiera manejado manualmente, como era antes de los sensores, que ahora los van conectando)

StarlightHunter.com

#9 Si te pinchas con una aguja de insulina una vena y terminas sangrando como loco algo has hecho muy mal, o tienes hemofilia o tomas Sintrom en modo sobredosis, porque las agujas de insulina son las más finas que existen y tus plaquetas deberían tapar el agujero muy rápidamente.

Más peligroso es que te pinches en una vena y te metas la insulina intravenosa en vez de intramuscular, pero para esto tienes que intentarlo adrede. La insulina no se pincha en zonas venosas, se pincha en un pliegue de la barriga (una chicha o michelin, vamos), deltoides, muslo...

pkreuzt

#6 #7 Hay cosas más completas, lo que se llama un sistema de ciclo cerrado. Sensor de glucemia + bomba de insulina automatizada. La bomba de insulina, en lugar de poner las dosis prefijadas a horas concretas, va regulando el flujo en todo momento basándose en los datos del sensor. Hay incluso versiones "caseras" con bombas tontas y sensores normales conectados vía una app especial open source.

Las bombas conectadas creo que ya se usan en España, aunque parece que no son muy populares.

Magog

Van 25 años de diabético y sigo sin ver el plus de la bomba, ni en pintura la quiero (Si la integraran con el Libreview entonces tal vez, y solo tal vez... y yo creo que ni por esas)
#11 sistema de asa cerrada, por el momento que sea eficaz, ni está ni se le espera. El que lo consiga va a dar un pelotazo brutal

pkreuzt

#17 No se si me fiaría mucho de la integración con los sensores. Son muy delicados, tienen una tasa de fallos e inexactitud importante. Seguro que te habrá pasado lo de estar durmiendo y que salte la alarma de hipoglucemia. . . para levantarte y comprobar que nada de eso. Al medir al glucemia en el tejido intersticial, tienen un componente de sensibilidad a la postura y la irrigación sanguínea muy importante.

Respecto al sistema cerrado, me dice el endocrino que ya se usa en algunos casos. Pero no completamente automatizado, sino en un modo "híbrido" intermedio. Los médicos tampoco se fían mucho del software.

u

#18 Es que una cuestión de vida o muerte no se puede dejar al software solamente. Necesitas triplicar todo el hardware y tomar decisiones por mayoría, como hacen los aviones, para tener algo mínimamente confiable. Necesitas una memoria RAM que detecte errores y reinicie todos los cálculos cuando algo así ocurra. Necesitas un sistema que verifique que el software que ejecuta no se modifique accidental o intencionalmente. Un PC o un móvil no tiene ninguno de esos mecanismos y ofrece una robustez muy baja.

u

#10 #18 Igual es cuestión de tener tres sensores en distintas partes del cuerpo. Mientras 2 o los 3 estén de acuerdo, la bomba tira para adelante, si los tres dan diferencia, alarma.

k

#17 si llevas un buen control no necesitas la bomba. Con una bomba con el loop funcionado ( da igual que modelo elijas) vas a tener un 70% de valores en rango sin hacer nada más, el resto dependerá de tu formación en diabetes y la ganas que le pongan. En el caso de los niños la mejora dejará descansar a la familia cada noche sin temor y al chiquillo le da una completa libertad para "despreocuparse" de su enfermedad. Mi hijo lleva la Ypsopump conectada al G6, nos ha cambiado la vida.

FlautaDeCaña

Las bombas de insulina de Medtronic son de lo mejor pero el sensor guardian dura menos de lo que debería (ala, paga otro, la SS o yo) luego usan una aplicación penosa prácticamente para que compres un Apple o uses un android con software muy antiguo y puede que sin parches de seguridad recientes y si intentas usar otra aplicación gratuita con los datos que tú mismo subes te lo complican lo indecible y encima su aplicación falla bastante

Lo de jugar con la salud de la gente con diabetes es algo que parece común pero a ver quién se mete con esas multinacionales

Gry

¿Que hace la bomba de insulina si el controlador le indica que inyecte una dosis letal?

Lo normal sería que tuviera algún tipo de bloqueo de seguridad o de detección de errores.

a

#16 Curioso, me estas diciendo que una bomba de insulina no esta diseñada para que sea fisicamente imposible inyectar una dosis letal ?

The_Ignorator

A mi estas cosas son las que más me echan para atrás a la hora de ponerme un cacharro de estos

tdgwho

#4 Bueno, si te lo pones, puede que falle.

Si no te lo pones... fallarás lol

Es como el idiota del jugador de fútbol aquel que le molestaba cuando el desfibrilador le pegaba el trastazo para mantenerlo vivo. Se lo quitó, y palmó.

astronauta_rimador

#5 ostia, que jugador hizo eso?

E

#6 es un dispositivo médico. Tienen que hacerte esas preguntas por seguridad. Tienen obligación de recopilar esos datos.

Cualquiera que haya trabajado en la industria te lo confirmará, y que hay cursos a todos los empleados periódicamente

The_Ignorator

#6 Pero una cosa es el sensor (que yo también llevo, y que me parece lo más maravilloso que me ha pasado nunca con estas mierdas), y otra la bomba de insulina.

A todos los que llevamos el sensor alguna vez nos ha hecho cosas raras (basado en mi experiencia y testimonios de primera mano), pero el peligro yace en la confianza que tu le des: si ves que hace algo que no te cuadra (o directamente no lee, como me pasa en ocasiones), compruebas con el glucómetro de toda la vida.

Si ya tienes conectado el sensor y la bomba, al final trasladamos lo realmente peligroso a la acción de la bomba (no a tus propias acciones), y es lo que yo decía. Con la doble posibilidad que falle por algo sobre lo que tu no tienes control: por el propio fallo de la bomba (como puede ser el caso de la noticia) o por las ordenes que le de el sensor (que fallos nos han pasado a todos)

tarkovsky

Nunca has visto una aguja de pluma de insulina moderna, verdad? la única forma atravesarte una vena con eso es hacerlo a propósito, e incluso dudo que lo consigas

Inviegno

Cuál es la opinión de@sammy_jankis respecto a esto?

Westgard

FBI: no es un bug, es un feature... roll

sillycon

No es raro. Muchos dispositivos médicos llevan software, y el software puede tener bugs e inconsistencias. El software puede matar, amigos. Ya sea el gestor de una bomba de insulina, una máquina de radiación, el interfaz de un marcapasos o el sistema de gestión de emergencia de una ciudad. Por eso hay que darle la importancia que tiene y elevar los estándares. Tienen que ser tan fuertes como los que se tienen con los propios medicamentos. Aun no hemos llegado a eso.