martes, 14 de octubre de 2014

Los datos: el combustible de M2M

Hola amigos. Comienzo el artículo de esta semana con mis disculpas por el atraso en su publicación, causado por un hecho fortuito que confío no se vuelva a repetir.

El tema de esta semana son los datos, que a mi modo de ver constituyen el fluido vital de todo sistema M2M y quiero comenzar hablando de uno de los fenómenos que más me ha llamado la atención en todos estos años. Lo llamo "el paso de la oscuridad a la luz" y es un fenómeno inherente a los proyectos M2M.

De la oscuridad a la luz.

Es frecuente que en los proyectos M2M los requerimientos iniciales de datos sean de baja exigencia. Muchos clientes me piden habilitar solo unas pocas mediciones por día. O me dicen que los datos históricos no son de interés, ya que necesitan la información solo para reaccionar con rapidez a lo que sucede día a día.

Una vez que el sistema está funcionando y se empieza a recibir datos, todo cambia. Con los datos en la mano el cliente empieza a extraer información y en pocas semanas se da cuenta que más datos significa mucha más información.

Una empresa que produce y distribuye gas me decía que una medición diaria por estanque le era suficiente, ya que su situación previa era una lectura manual cada 2 semanas. Actualmente usa mediciones cada 10 minutos, que le permiten detectar oportunamente que en un condominio con 3 estanques solo llenaron 2, o una variación brusca de nivel (que puede deberse a una fuga).

Una empresa eléctrica quería habilitar el monitoreo y control en tiempo real de su red de distribución en zonas rurales y no les interesaba la información histórica. Hoy utiliza la información histórica de corrientes, potencias y energía para analizar patrones de consumo estacionales.

En resumen, aunque inicialmente un proyecto M2M tenga un objetivo modesto en cuanto a la cantidad y tipo de información, al poco tiempo se descubre que se puede hacer mucho más al disponer de más datos y se produce una explosión en los requerimientos de información y su uso.

Calidad de los datos.

Hay un viejo dicho informático que dice "garbage in, garbage out", es decir, si alimentamos un sistema con datos de mala calidad, la información que obtendremos será de mala calidad.

Lo peor que le puede ocurrir a un sistema M2M es entregar información de mala calidad, aunque sea ocasionalmente, porque en poco tiempo se le perderá la confianza. Y todos sabemos lo difícil y costoso que es recuperar la confianza una vez que se ha perdido.

Por eso, uno de los factores clave en relación a los datos es su calidad. Algunas ideas para asegurar la calidad y conseguir la confianza en los datos:
  • Usar sensores de calidad.
  • Incluir mecanismos de detección automática de problemas en la medición (desconexión de sensores, cables sueltos, alteraciones en el mecanismo de medición, etc), para alertar al usuario cuando las mediciones no sean válidas.
  • Contrastar las mediciones del sistema M2M con mediciones manuales (ojalá con instrumentos certificados como patrón).
  • Identificar las causas de las diferencias en las mediciones y resolverlas a satisfacción del cliente. Muchas veces ocurre que el método manual de medición tiene errores, pero el cliente está acostumbrado a ellos y funciona de esa manera, por lo que hay que encontrar un consenso. En más de una ocasión me ha pasado que el cliente prefiere incorporar el mismo error en el sistema M2M, para mantener continuidad. En esos casos, siempre le propongo generar las dos mediciones en paralelo (la "clásica" con el error incorporado al sistema M2M y la nueva sin el error).

Oportunidad.

La oportunidad en la recepción de los datos es otro factor importante en los proyectos M2M, ya que normalmente el cliente querrá contar con las mediciones lo antes posible, pero no siempre es factible debido a las redes de comunicación, especialmente las redes celulares (que son las más utilizadas por los sistemas m2M)..

Las mejores prácticas en este caso son:
  • Ser muy claro al explicar al cliente que los datos serán entregados lo más cercano al tiempo real posible ("near real time").
  • Fijar expectativas con realismo, ojalá basadas en la experiencia. Por ejemplo, con una empresa eléctrica hemos establecido que:
    • Las actualizaciones de estados se realizarán en menos de 10 segundos en el 95 % de los casos.
    • Las operaciones remotas se realizarán y confirmarán en menos de 30 segundos en el 95% de lo casos.
    • Y hemos incluido las mediciones necesarias para validar estas estadísticas.
  • Si los dispositivos remotos son capaces de almacenar la información cuando no hay conexión de red, explicarle al cliente que no perderá datos, pero en caso de una falla prolongada de la red de comunicaciones se producirá encolamiento con la consiguiente demora en ponerse al día una vez que vuelven las comunicaciones.
  • Si los dispositivos remotos no cuentan con memoria, explicar claramente al cliente que perderá información mientras la red de comunicaciones no esté disponible.

Frecuencia.

Ya mencionamos este tema más arriba, pero quisiera agregar algunas definiciones:
  • Frecuencia de medición:
    • Es la frecuencia con que el dispositivo remoto M2M captura cada medición (es decir, lee la medición del sensor).
    • Esta frecuencia es importante cuando queremos generar alarmas si alguna medición se sale del rango normal.
    • Si la frecuencia es de una medición por segundo, en caso de alarma podemos enviar un mensaje de texto y alertar a uno o varios usuarios en menos de 10 segundos. Este es un sistema utilizado por las viñas para generar alertas de riesgo de heladas cuando la temperatura cae bajo cierto nivel.
  • Frecuencia de registro:
    • Aunque el equipo remoto esté leyendo mediciones cada un segundo, no vamos a necesitar que nos envíe cada una de esas mediciones.
    • Podríamos querer que se registre la temperatura promedio, el valor más alto y el más bajo cada 10 minutos. Esta es la frecuencia de registro y normalmente es diferente de la frecuencia de medición.
  • Frecuencia de reporte:
    • Algunos equipos remotos tienen capacidad de almacenamiento y la utilizan para optimizar el tráfico de comunicaciones.
    • Por ejemplo, pueden ser capaces de acumular y empaquetar muchos registros de medición y enviarlos en una sola transmisión, lo que aprovecha mejor el canal de comunicación y eventualmente puede también reducir los costos.
    • Podríamos configurar un equipo para que registre mediciones cada 2 minutos y acumule y empaquete 10 mediciones antes de enviarlas. Esto significa que la frecuencia de reporte sería de una transmisión cada 20 minutos.

Resumen.

Los datos son el fluido vital de todo sistema M2M y hemos aprendido que su calidad, oportunidad y frecuencia son factores importantes para el éxito de nuestros proyectos.

Sobre todo, hemos aprendido que en todo proyecto M2M se produce una "explosión de luz" en ese momento en que descubrimos con alegría que podemos hacer y obtener mucho más de lo que esperábamos.

Ese es uno de los momentos que hace de M2M una aventura fascinante.

Hasta la próxima semana. Mis mejores deseos para todos ustedes...

No hay comentarios:

Publicar un comentario