El IoT es una de las tecnologías de la cuarta revolución industrial que dota a los objetos de cierta "inteligencia" para que perciban cambios en su entorno físico a través de sensores, procesen esos cambios usando un cerebro o en términos más técnicos un microcontrolador y dependiendo de ese procesamiento ejecuten una acción que podría ser:
Comunicar esos datos a un servidor en internet para mostrarlos a través de un tablero o Dashboard,
Comunicar los datos a otro objeto,
Activar un motor, encender un bombillo, etc.
A esos objetos con cierta inteligencia, David Rose, profesor del MIT media Lab, los denominó objetos encantados en su libro Enchanted Objects. Sin embargo, aquí le daremos la connotación de objetos inteligentes. Ese objeto inteligente debe contar con mínimo los siguientes componentes:
Vamos a profundizar un poco sobre cada uno de esos componentes.
Los sensores son como los sentidos del objeto inteligente los cuales permiten medir variables físicas como temperatura, humedad, presión, movimiento, pH, aceleración, luminosidad, gas, ruido, flujo, entre otros, y los cambios en esas variables físicas los relaciona con cambios de una señal eléctrica como resistencia, corriente o voltaje. Por ejemplo, hay sensores de temperatura como el sensor LM35 que produce un voltaje de salida linealmente proporcional a los cambios de temperatura en grados Celsius es decir que por cada grado que aumente la temperatura el sensor proporciona un aumento en voltaje de acuerdo con una relación que suministra el fabricante del sensor.
Los sensores pueden proporcionar valores análogos que son continuos en el tiempo y pueden tomar un número infinito de valores dentro de un intervalo. Algunos sensores, en cambio, ya incorporan un conversor Análogo-Digital (ADC) y entregan valores digitales representados como ceros y unos. Para poder interpretar esos valores que arrojan los sensores, sean análogos o digitales, necesitamos un componente que procese esos datos y los convierta en magnitudes comprensibles por el ser humano, por ejemplo, temperatura expresada en grados Celsius o Fahrenheit, en lugar de voltios o bits. Ese componente es el cerebro del objeto inteligente o también denominado microcontrolador.
El microcontrolador, a través de sus pines configurados como entrada, pueden recibir los datos medidos por los sensores ya en formato binario o digital que es el idioma que entienden los microcontroladores. En el microcontrolador se carga un programa que, dependiendo del tipo de microcontrolador, puede escribirse en lenguajes de programación como C, MicroPython, Arduino, entre otros. Este programa implementa la lógica necesaria para procesar esos datos entregados por el sensor.
Por ejemplo, si el microcontrolador recibe datos de un sensor de temperatura, estos se procesan para obtener el valor en grados Celsius y mostrarlos a través de un display, si la temperatura supera un umbral definido, se puede ejecutar una acción como activar una alarma o, como se mencionó anteriormente, enviar estos datos a un servidor en internet.
Entre los microcontroladores más usados para proyectos de IoT se tiene el ESP32, las Raspberry pi pico y la familia de Arduino como el MKR GSM 1400, MKR WIFI1010, Portenta C33, entre otros.
Algunos de los microcontroladores ya vienen con interfaces de comunicación inalámbricas integradas lo que les permite comunicar sus datos, a nivel de capa física (según el modelo OSI), a otros objetos utilizando tecnologías como Zigbee, Bluetooth, LoRaWAN o directamente a internet usando WI-FI. En esos esquemas donde los objetos inteligentes envían información a Internet, normalmente se utiliza el modelo cliente - servidor, donde los clientes son los objetos inteligentes y el servidor puede estar en una red local o en la nube de AWS. Es importante mencionar que, además de la conexión WIFI a nivel de capa física, a nivel de capa de aplicación la información se puede comunicar al servidor a través de protocolos como:
HTTP: modelo cliente - servidor, basado en TCP
MQTT: modelo Publish-Suscribe (Publicación-Suscripción), basado en TCP, muy útil para aplicaciones de IoT por ser ligero, proporcionar menor consumo de energía y presentar un bajo consumo de ancho de banda.
CoAP: modelo cliente - servidor, basado en UDP, útil para dispositivos muy restringidos en recursos.
Por ejemplo, se puede implementar un servidor IoT en una instancia Amazon EC2 utilizando tecnologías de desarrollo backend como Node.js, PHP o en Python utilizando framework de desarrollo web como Flask, Django o FastAPI. En la siguiente figura se observa un esquema de esta implementación.
Vamos a analizar lo que implica implementar un servidor IoT sobre una instancia de Amazon EC2.
Cuando utilizamos Amazon EC2, nuestra responsabilidad es mayor, ya que debemos encargarnos de ciertas actividades, entre ellas:
Aprovisionar una AMI con el sistema operativo determinado.
Instalar y configurar los paquetes necesarios para la configuración y despliegue del servidor IoT. Verificar la actualización continuamente de estos paquetes.
Configurar un Auto Scaling Group para el escalamiento automático según la carga.
Configurar un balanceador de carga como un Application Load Balancer para garantizar alta Disponibilidad y distribución adecuada de tráfico.
Y en temas de costos asociados a Amazon EC2 tendríamos que pensar en su modelo de precios que podría ser:
On demand: se paga por la capacidad de cómputo por hora o segundo, es más costoso, pero no se tiene compromisos a largo plazo.
Reserved instances: permite un gran descuento, pero con compromiso de uso por uno o tres años.
Spot instance: ofrece gran descuento (hasta un 90% con respecto con On-Demand), pero se debe tener en cuenta que la instancia puede ser interrumpida en cualquier momento si AWS necesidad la capacidad.
Arquitectura Serverless para IoT en AWS
El implementar una arquitectura serverless para IoT podría disminuirnos tareas operativas, tareas de administración y ahorrarnos costos ya que solamente vamos a pagar por lo que realmente vamos a usar. Además, podemos aprovecharnos de la alta escalabilidad y alta disponibilidad que ya viene integrada y asociada a los servicios administrados de AWS sin necesidad de gestionar servidores de forma directa. Aprovechando estos beneficios, a continuación, mostraré cómo implementar una arquitectura serverless para IoT.
Como dispositivo IoT vamos a usar el módulo ESP32, un microcontrolador de 32 bits que integra interfaces de comunicación inalámbrica como WI-FI y Bluetooth, y que cuenta con una SRAM de 520 KiB. En Colombia se puede conseguir a un precio de alrededor $30000 COP (aproximadamente 8 USD). Al ESP32 conectamos un sensor DHT11 que es un sensor digital que mide temperatura y humedad. Esos valores son procesados y organizados en el ESP32, y posteriormente enviados al servicio AWS IoT.
void publishMessage()
{
StaticJsonDocument<200> doc;
// Añadir timestamp en formato ISO
time_t now = time(nullptr);
doc["timestamp"] = now;
doc["humidity"] = h;
doc["temperature"] = t; //Organizar data en un json
doc["device_id"] = "esp32_01";
char jsonBuffer[512]; //crear un buffer
serializeJson(doc, jsonBuffer); // Convertir en un string y almacenar en el buffer
esp32.publish(monitoreo_topic, jsonBuffer); //Public data al topic mqtt
}
El servicio AWS IoT es un servicio serverless que nos provee una especie de Gateway totalmente administrado por AWS, a través del cual podemos conectar y comunicar dispositivos IoT de forma segura con la nube de AWS.
La comunicación se puede realizar a través de MQTT o mediante HTTPS. En ambos casos, el tráfico se cifra mediante certificados TLS y la autenticación de los dispositivos se realiza a través de certificados X.509.
El servicio da la posibilidad de configurar reglas (Rules) que permite conectar los mensajes entrantes de los objetos inteligentes con otros servicios de AWS para su almacenamiento y posterior procesamiento. Por ejemplo, los datos se pueden almacenar en servicios como Amazon S3 o Amazon DynamoDB, procesarse a través AWS Lambda, generar notificaciones mediante Amazon SNS o analizar datos en tiempo real con Amazon Kinesis, entre otros.
Por ejemplo, yo configuré la siguiente regla para almacenar los datos en la base de datos de series de tiempo Timestream.
Antes de configurar la anterior Rule es importante crear la base de datos Timestream. Esta base de datos es una base de datos de series temporales totalmente administrada por AWS que nos ofrece dos motores: Amazon Timestream for LiveAnalytics y Amazon Timestream for Influxdb. Para la implementación de la arquitectura serverless trabajé con Amazon Timestream for LiveAnalytics.
Hasta el momento el ESP32 envía datos a AWS IoT Core y de acuerdo con la rule configurada, estos datos se almacenan en Amazon Timestream. La pregunta ahora es:
_ ¿Cómo podríamos visualizar esos datos almacenados en la base de datos a través de un dashboard aprovechando servicios serverless?_
Imaginemos el siguiente escenario: a través del ESP32 estamos monitoreando las variables de un cultivo de tomate en invernadero (temperatura, humedad del suelo, luminosidad, etc) y el agricultor quiere ver esa información de forma gráfica desde cualquier dispositivo con acceso a internet y desde cualquier lugar.
¿Qué servicios serverless de AWS necesitamos para lograrlo?
Para cumplir con este objetivo vamos a utilizar los siguientes servicios: Amazon S3, Amazon API Gateway y AWS Lambda.
- Amazon S3: servicio de almacenamiento de objetos totalmente administrado por AWS que además podemos configurar como un hosting de una web estática. Es decir que, utilizando HTML, CSS y JS podemos construir el dashboard para IoT.
Como no soy desarrollador Frontend, utilicé Kiro, un IDE con IA, que me ayudó a construir el dashboard que se muestra en la siguiente imagen.
Necesitamos de un servicio que pueda leer la información de la base de datos y entregue los datos en un formato adecuado para mostrarlos en el Dashboard. Ese servicio es AWS Lambda.
- AWS Lambda: implementa la lógica para leer los datos de la base de datos y entregarlos al frontend de forma procesada. Es un servicio en el que configuramos funciones que se ejecutan en respuesta a un evento o trigger, por ejemplo, cuando se almacena un objeto en S3 puede generar un evento que dispare una función Lambda. Esas funciones se pueden escribir en lenguajes como Python, Javascript, Java, entre otros, sin necesidad de gestionar ni mantener servidores. En la siguiente función Lambda escribí el código para leer los datos de Timestream y entregarlos al frontend en formato JSON. A continuación, muestro un parte del código que corre en Lambda.
query = f"""
# obtener parámetros
query_params = event.get('queryStringParameters', {})
device_id = query_params.get('device_id') if query_params else None
limit = query_params.get('limit', '100') if query_params else '100'
# Query para obtener todos los datos
query = f"""
SELECT
device_id,
time as timestamp,
measure_name,
CAST("measure_value"::bigint AS double) AS value
FROM sensor_values_db."values_sensors_esp32"
WHERE measure_name IN ('humidity', 'temperature')
{f"AND device_id = '{device_id}'" if device_id else ""}
ORDER BY time DESC, device_id
LIMIT {limit}
"""
response = timestream_query.query(QueryString=query)
# Procesar resultados y agrupar por timestamp y device_id
readings = {}
for row in response['Rows']:
dev_id = row['Data'][0]['ScalarValue']
ts_utc = row['Data'][1]['ScalarValue']
measure_name = row['Data'][2]['ScalarValue']
value = float(row['Data'][3]['ScalarValue'])
Como la intención es poder mostrar los datos a través de un dashboard, cada vez que un usuario o agricultor realice una petición (request) desde un navegador necesitamos de una API que invoque la función Lambda para leer los datos de la base de datos y traerlos en formato JSON para poder mostrarlos en la web. Esa API que conecta Amazon S3 (donde está la web estática para el dashboard) con AWS Lambda es Amazon API Gateway.
- API Gateway: servicio que nos permite crear, publicar, mantener, monitorear y asegurar APIs. Actúa como la puerta de entrada para que las aplicaciones accedan a datos, lógica de negocio o funcionalidad proveniente de los servicios Backend. En la arquitectura que estamos implementando, API Gateway funciona como un trigger de la función Lambda que definimos anteriormente.
Ahora cada vez que un usuario realice una solicitud GET a la URL del sitio estático alojado en Amazon S3 (es decir cuando ingrese la URL en el navegador), el dashboard envía una solicitud a Amazon API Gateway, que a su vez dispara la función AWS Lambda para consultar la base de datos, traer la información en formato JSON y mostrarla en el dashboard.
Con esta arquitectura totalmente serverless podemos ahorrar costos, reducir tareas operativas y de administración de infraestructura, aprovechamos la alta disponibilidad y escalabilidad y obtenemos una arquitectura flexible si necesitamos implementar proyectos basados en IoT.
Puedes encontrar el código completo en el siguiente repositorio de Github:
AWS_Serverless_Architecture
Top comments (0)