¿Qué es la integración de SCADA con AWS IoT Core?

Reglas de tema que reparten los datos

La característica que distingue a IoT Core de un broker MQTT pelado es su motor de reglas. Una regla se define con una sentencia tipo SQL que selecciona de un filtro de tema, opcionalmente transforma la carga útil, y luego enruta el resultado a una o más acciones. Como un solo mensaje entrante puede disparar múltiples reglas y cada regla puede tener varias acciones, una lectura de tag publicada a un tema como el canal de telemetría de un sitio puede insertarse en Amazon Timestream para consulta de series de tiempo, escribirse a S3 para almacenamiento durable de bajo costo, y empujarse a un flujo de Kinesis para procesamiento en tiempo real, todo desde el único mensaje que llega. El gateway de campo simplemente publica una vez y el reparto ocurre por completo en la nube.

La jerarquía de temas es lo que hace esto manejable a escala. Un esquema de temas bien estructurado, codificando sitio, área y medición en los niveles del tema, deja que las reglas usen comodines para emparejar porciones amplias o estrechas de la telemetría. Una regla puede suscribirse a toda la telemetría de cada sitio con un comodín de múltiples niveles, o acotarse a las lecturas de presión de un solo sitio, sin que el publicador cambie nada. Diseñar el árbol de temas con cuidado de antemano rinde frutos aquí, porque la lógica de enrutamiento se expresa como filtros de tema, y una jerarquía limpia significa que los sitios nuevos y los tipos de medición nuevos encajan sin reescribir reglas.

El lenguaje de reglas tipo SQL también puede reformar la carga útil al vuelo, sacando campos específicos de un mensaje JSON, agregando metadatos, o filtrando para que solo las lecturas que cumplen una condición se reenvíen. Esto mantiene los datos innecesarios fuera de los destinos caros, por ejemplo enviando cada lectura al almacenamiento barato de S3 mientras solo reenvía las lecturas que cruzan un umbral a un flujo que dispara lógica aguas abajo. Esa selectividad por destino es gran parte de por qué el motor de reglas es el caballo de batalla de la integración en lugar de una ocurrencia tardía.

Certificados de dispositivo para gateways

IoT Core no deja que clientes anónimos se conecten. Cada dispositivo, que en un contexto SCADA por lo general significa un gateway de borde que agrega muchos tags de campo en lugar de un sensor individual, se autentica con un certificado X.509. El certificado identifica al gateway, y una política adjunta declara exactamente a qué temas se le permite a ese gateway publicar y suscribirse. Esto da un control granular fino: un gateway en un sitio puede restringirse de modo que su certificado solo permita publicar a la rama de temas de ese sitio, así que un dispositivo comprometido o mal configurado no puede inundar ni leer temas que pertenecen a otros sitios.

Administrar certificados es una disciplina operativa en lugar de un montaje único. Los certificados se aprovisionan cuando un gateway se pone en servicio, pueden rotarse en un horario para que una credencial de larga vida no se deje en su lugar indefinidamente, y pueden revocarse de inmediato si un gateway se da de baja o se sospecha comprometido. Como la revocación surte efecto en el broker, retirar un certificado corta un gateway de forma limpia sin tocar el dispositivo de campo, lo que importa cuando una unidad está físicamente remota. Registrar los certificados contra una autoridad de certificación y usar un flujo de aprovisionamiento evita que esto se vuelva una tarea manual para cada gateway nuevo.

También hay una función de modelado que vale la pena conocer, el device shadow, que es un documento JSON que IoT Core mantiene para cada dispositivo sosteniendo su estado reportado y deseado. Para un gateway SCADA el shadow es menos sobre los valores de tag individuales, que fluyen como telemetría, y más sobre la configuración y conectividad del gateway, dejando a una aplicación de nube leer el último estado conocido de un dispositivo aun mientras está fuera de línea y preparar una configuración deseada para que el dispositivo la recoja cuando se reconecte. Es una forma de razonar sobre el estado del dispositivo por separado de la avalancha de datos de medición que pasa a través de él.

IoT Core frente a un broker crudo en SCADA

Es justo preguntar por qué una planta usaría IoT Core en lugar de simplemente correr su propio broker MQTT, que es una pieza de infraestructura madura y bien entendida. La respuesta es que un broker crudo mueve mensajes y se detiene ahí. Autentica clientes y entrega las publicaciones a los suscriptores, pero no tiene noción integrada de enrutar un mensaje a una base de datos, archivarlo, o disparar lógica aguas abajo, así que todo eso tiene que construirse y operarse como aplicaciones consumidoras separadas. IoT Core pliega la autenticación, el motor de reglas de enrutamiento, y las integraciones con servicios de nube en una sola capa administrada, que es lo que un equipo realmente compra: menos plomería a la medida que construir y mantener corriendo.

El compromiso es el acoplamiento y el modelo de costo. Comprometer la ingesta de telemetría a IoT Core ata esa parte de la arquitectura a AWS, y el precio se basa en mensajes y acciones de regla, así que un flujo de muy alta frecuencia con reparto pesado se mide en consecuencia. Una planta que solo necesita mover mensajes entre sistemas en sus propias instalaciones, sin ambiciones de análisis de nube, puede encontrar un broker autoalojado más simple y barato. La decisión por lo general se reduce a si el valor está en la mensajería de campo a campo, donde un broker simple basta, o en llevar la telemetría a un conjunto rico de servicios de nube con código a la medida mínimo, donde el motor de reglas se gana su lugar.

En muchos despliegues reales IoT Core se sitúa detrás de una capa de borde en lugar de hablar con dispositivos de campo individuales, y aquí es donde encaja una plataforma de monitoreo. Una plataforma como Merobix puede recolectar tags SCADA a través de protocolos de campo mixtos, normalizarlos, y publicar un flujo MQTT limpio que un gateway reenvía a IoT Core, así que el lado de nube lidia con mensajes consistentes y bien formados en lugar de la salida cruda del dispositivo. Esa separación deja a IoT Core y a los servicios de AWS detrás de él enfocarse en almacenamiento y análisis mientras los operadores mantienen una vista operativa en vivo en la capa de monitoreo, con cada parte de la pila haciendo el trabajo para el que es más apta.

Preguntas frecuentes