En IoT el problema nunca es el sensor
3 min de lectura
En resumen
En los proyectos de IoT el hardware casi nunca es el cuello de botella. Lo difícil es el diseño de la degradación: qué muestra la aplicación cuando un dispositivo lleva horas sin reportar, quién se entera y qué se le dice al usuario. Un sistema que sólo se ha diseñado para el caso en que todo funciona no es un sistema.
Los proyectos de internet de las cosas se presupuestan como si el reto fuera técnico y estuviera en el dispositivo: qué sensor, qué protocolo, qué autonomía, qué conectividad. Son decisiones reales, hay que tomarlas, y hoy están bastante resueltas por el mercado.
El problema aparece más tarde, y es de otra naturaleza. Un sistema conectado al mundo físico tiene una propiedad que el software puro no tiene: una parte de él está fuera de tu control y falla de formas que no puedes prevenir. Se agota una batería. Alguien desenchufa algo para pasar la fregona. Un camión aparca delante de una antena. Llueve.
Eso no es un caso excepcional que se trata en el capítulo de gestión de errores. Es el modo de funcionamiento normal del sistema durante buena parte de su vida útil.
Diseñar la degradación, no sólo el funcionamiento
La pregunta que ordena un proyecto de IoT es qué muestra el sistema cuando el dato no está. Y tiene más respuestas posibles de las que parece:
- Mostrar el último valor conocido, sin más. Cómodo y peligroso: el usuario cree que está viendo la realidad.
- Mostrar el último valor conocido con la hora a la que se obtuvo. Menos elegante y mucho más honesto.
- Mostrar explícitamente que no hay dato. Correcto, y a veces inaceptable para el negocio, porque una pantalla llena de huecos parece un producto roto.
- Estimar el valor. Útil en algunos dominios, y una fuente inagotable de problemas si no queda clarísimo que es una estimación.
No hay una respuesta buena para todos los casos. Lo que sí hay es una respuesta mala: no elegir, y que la decisión la tome por omisión quien implementa la pantalla.
La cifra que casi nunca está en el presupuesto
Hay una asimetría de la que se habla poco: el coste de operar la flota supera con holgura el coste de construir el software.
Un sistema con dispositivos desplegados en campo necesita saber, en todo momento, cuáles están vivos. Eso implica monitorización, alertas, un inventario que refleje la realidad y no lo que se instaló hace dos años, y — la parte más cara y la que nadie presupuesta — alguien que vaya físicamente a arreglarlo.
Ese “alguien” es un proceso operativo completo: quién recibe el aviso, en cuánto tiempo se compromete a ir, qué recambios tiene, quién paga el desplazamiento. Si ese proceso no está definido, ocurre lo mismo que con cualquier proceso sin dueño: se degrada. Al año hay un porcentaje de dispositivos silenciosos que nadie ha ido a mirar, y los datos del sistema pasan a ser una foto parcial que se presenta como si fuera completa.
Lo que aprendo cada vez
Que en IoT la frontera importante no está entre el hardware y el software, sino entre lo que se puede automatizar y lo que va a requerir que una persona se desplace. Todo el diseño debería organizarse alrededor de esa frontera: minimizar los desplazamientos, y cuando sean inevitables, hacer que el sistema diga con precisión a dónde hay que ir y qué hay que llevar.
Es el mismo patrón que en la transformación digital no es un proyecto de tecnología: el proyecto no se decide en la elección técnica, se decide en el reparto de responsabilidades operativas que nadie quiere discutir en la reunión de arranque.