Optimización del consumo eléctrico de placas de desarrollo IoT

Escrito por Manuel Caldas

En julio de 2018, ennomotive lanzó un desafío que buscaba una solución precisa y robusta para detectar y medir el polvo que se produce en entornos industriales.

Durante 6 semanas, 43 ingenieros de 20 países participaron en el desafío y entregaron diferentes soluciones. Tras una minuciosa evaluación, las soluciones que mejor cumplían los criterios de evaluación eran obra de Manuel Caldas, de Uruguay, Maksym Gaievsky, de Ucrania, y Sergi Palomar, de España. 

En este artículo, Manuel Caldas comparte sus conocimientos sobre cómo se podría optimizar el consumo eléctrico de placas de desarrollo en redes IoT.

Cuando cada miliamperio cuenta

Desde el nacimiento de la primera placa Arduino en 2005, el surgimiento de nuevas placas de desarrollo de otras marcas y otras de la propia familia Arduino, han puesto al alcance de muchísimas personas las potencialidades que ofrece la microelectrónica de control. En particular, posibilita la realización de proyectos muy diversos e innovadores por parte de “realizadores” que no necesariamente deben ser técnicos o ingenieros en electrónica o TI. Simplemente basta con tener conocimientos más o menos elementales de electrónica y programación, y el horizonte de posibilidades es inmenso. Si a esto añadimos la capacidad de realizar impresión 3D, tenemos al alcance la realización no solo de prototipos, sino incluso de productos finales.

Ahora bien, en no pocas situaciones tenemos que nuestro sistema a desarrollar operará en ubicaciones remotas y/o de forma autónoma. Ello implica que la alimentación eléctrica de nuestro sistema proviene de baterías, y es en este tipo de situaciones cuando la optimización del consumo eléctrico del sistema se vuelve un principio de diseño fundamental, rector de todo el concepto. Este breve artículo pretende brindar algunas consideraciones generales que el diseñador ha de tener en cuenta en este tipo de situaciones, a partir de un ejemplo ficticio concreto.

Descripción del problema

Figura 1: Grilla de sensores de humedad de suelo.

Supongamos que necesitamos desarrollar una red de monitoreo automático de humedad de suelo, cuyo objetivo principal es optimizar el riego de un determinado cultivo. La red se compone de puntos de medida o nodos, distribuidos de una determinada manera, por ejemplo en una malla o grilla de nxn nodos, separados una distancia d, como muestra la Figura 1. A partir de las mediciones de cada nodo puede generarse un mapa de humedad de suelo en toda el área considerada, utilizando técnicas de extrapolación.

Cada nodo está compuesto por una cantidad a determinar de sensores de humedad conectados a una placa de desarrollo, la cual cuenta con un módulo de conectividad que envía su medida a un gateway central, cada TS minutos. Cada nodo es alimentado por una batería de 9.0 V y 2000 mAh de capacidad nominal.

El desafío aquí planteado es minimizar el consumo eléctrico en todos los aspectos posibles, para minimizar también los costos de operación de la red, ya que cada vez que una batería se agota es preciso que una persona se dirija al predio y la sustituya. Por ello, se hace necesario maximizar la autonomía de cada nodo, minimizando su consumo eléctrico sin por ello comprometer la “calidad” del mapa de humedad generado.

En los siguientes apartados describiremos brevemente los principales factores que inciden significativamente en el consumo eléctrico de cada nodo.

Paso 1: Minimizar el número de señales I/O

En un proyecto que requiere de la utilización de una placa de desarrollo siempre tendremos un conjunto de señales de entrada/salida (I/O). Desde sensores remotos, que midan una o varias magnitudes a partir de una o varias señales, hasta sistemas de control de algún proceso, en todos los casos debemos identificar qué señales son relevantes para nuestro problema dado.

En nuestro caso debemos definir cuántos sensores tendremos en cada punto de medida o  nodo. Un solo sensor presenta la ventaja de minimizar el consumo, pero tiene poca robustez ya que si el sensor falla se pierde ese punto de medida. Esto podrá ser aceptable o no, dependerá en nuestro caso también de cuán densa es nuestra malla. Vamos a considerar dos casos, con uno y dos sensores por nodo. Asumamos también que cada sensor consume en promedio 0.5 mA, a 3.3 V.

Paso 2: Elección de la placa de desarrollo

Consideremos aquí dos opciones, la popular Arduino UNO y la más pequeña Arduino PRO Mini. Vamos a asumir los valores de consumo de estas placas en modo activo y durmiente que se muestran en la Tabla 1:

Tabla 1: Corrientes en modo activo y durmiente de las placas de desarrollo consideradas.

En el modo activo, es preciso sumar a los valores anteriores el consumo unitario de los sensores (0.5 mA), por el número de sensores (1 o 2).

Paso 3: Conectividad

Además del consumo de la placa y de los sensores cuando se está en modo activo, es preciso añadir el consumo del módulo de conectividad del sensor. El consumo depende de la tecnología que se utilizará para la transmisión de datos. Supongamos que las opciones son GSM y LoRaWAN. En tal caso, la siguiente tabla muestra consumos típicos en transmisión y en modo durmiente de módulos de transmisión para Arduino de cada tecnología:

Tabla 2: Valores típicos de corrientes de módulos LoRaWAN y GSM para Arduino,.

Paso 4: Optimización del código

En esta etapa se trata de definir un ciclo de trabajo, es decir, definir el período de muestreo TS, es decir, el tiempo que transcurre entre cada envío de datos, así como el tiempo durante el cual la placa y periféricos están en estado activo y durmiente.

Asumiendo que el leer los sensores, hallar su promedio y enviar el dato al gateway lleva 5 segundos, nos resta solo un parámetro (Ts) para variar y cuantificar su impacto en el consumo global.  

Resultados

El gráfico siguiente muestra los días de autonomía de la batería en cada nodo, en función del período de transmisión de datos Ts, para el caso de diseño optimizado y diseño sin optimizar. El primero refiere a la elección de las opciones de menor consumo en los pasos 2 y 3 (Arduino Mini más LoRaWAN), el segundo a las opciones de mayor consumo (Arduino UNO más GSM). En ambos casos se utilizaron dos sensores por nodo, ya que no hay prácticamente diferencia entre utilizar uno o dos sensores en lo que a consumo refiere, y ello se debe a que la mayor parte del tiempo el sistema está en estado durmiente. Es interesante también notar que la dependencia no es lineal. Como se desprende del gráfico, nuestro diseño optimizado nos permite pasar de ~3 a 20 días de autonomía, para un Ts de 30 min!

Figura 2: Días de autonomía de una batería de 9.0 V y 2000 mAh en función del período de transmisión de datos (tiempo entre envíos consecutivos de lectura del sensor al hub central).

Alimentación solar

El diseño anterior puede incorporar un sistema de alimentación fotovoltaica (FV). La principal y obvia ventaja es la extensión de la autonomía del sensor, aunque al incluir más componentes aumenta también el número de posibles fuentes de fallas.

Para cuantificar el efecto de la inclusión de un “cargador solar” como comercialmente se conoce estos (pequeños) dispositivos, es preciso realizar algunas asunciones en cuanto al sitio de instalación. Asumimos aquí que la irradiación solar media (sobre plano horizontal) en invierno es de 2.0 PSH, y en verano de 7.0 PSH, valores típicos de latitudes medias. Típicamente la corriente nominal de cargadores solares para baterías de 9.0 V es de entre 20 y 30 mA. Asumiendo pues 20 mA obtenemos una potencia del módulo de 180 mW. Ello implica que la energía diaria media aportada por el sistema fotovoltaico es de 0.36 y 1.26 Wh en invierno y verano, respectivamente. Para el caso de un envío de datos cada 30 minutos, obtenemos una demanda energética diaria del sensor de 0.9 Wh/día.

A partir de un balance energético diario se arriba a que se logra extender la autonomía a unos 34 días, en invierno. En verano la demanda diaria es totalmente satisfecha por el aporte solar. Claro está que el determinar si esta ganancia en términos de autonomía justifica o no la inclusión de componentes adicionales (módulo solar, circuito controlador de carga) dependerá de cada caso. Simplemente hemos querido cuantificar aquí el aporte de un suministro fotovoltaico, para valores y situaciones típicas. Un análisis riguroso requiere una simulación dinámica del comportamiento transitorio de todo el sistema, para lo cual pueden utilizarse herramientas como TRNSYS, Matlab, etc.

Conclusiones

En este artículo hemos pretendido demostrar, a partir de un sencillo ejemplo, el impacto que tienen distintos parámetros de diseño en el consumo energético global de dispositivos basados en placas de desarrollo. Cuando el consumo energético es un parámetro crítico, como en el ejemplo descrito en este artículo, es preciso tener en cuenta al menos los aspectos descritos aquí: optimización del número de señales I/O, elección de una placa de desarrollo adecuada, utilización de los estados durmientes de las placas y de dispositivos periféricos, como en este caso los módulos de conectividad, y finalmente optimizaciones a nivel del programa que instalemos en la placa que utilicemos. Asimismo, debería considerarse la inclusión de alimentación fotovoltaica. La optimización conjunta de estos factores tienen un impacto significativo en la reducción del consumo energético global de los dispositivos, lo cual redunda en una minimización de costos de O&M.

Cuéntanos otras formas de reducir el consumo eléctrico en redes IoT y descubre qué mas puede hacer ennomotive por ti.

Fuentes

1. http://www.home-automation-community.com/arduino-low-power-how-to-run-atmega328p-for-a-year-on-coin-cell-battery/
2. Fuente de datos para el módulo LoRaWAN: https://www.youtube.com/watch?v=7nzej8lzwsY
3. Fuente de datos para el módulo GSM: https://www.youtube.com/watch?v=OOeOQ-ZRxz8&feature=youtu.be