Cómo construir un sistema IIoT usando Apache NiFi, MiNiFi, C2 Server, MQTT y Raspberry Pi

¿Cuánto tiempo cree que lleva construir un prototipo avanzado de IoT industrial que pueda:

  • Recopile datos de los sensores a una puerta de enlace en cada fábrica
  • Mueva los datos de los sensores de una o varias fábricas a la nube o al centro de datos
  • Implementar automáticamente en caliente nuevas configuraciones en todos los dispositivos de borde
  • Admite volumen de datos a gran escala y seguridad de extremo a extremo

¡Con la herramienta adecuada, puede construir dicho sistema en menos de una hora! En esta publicación de blog, le mostraré cómo implementar un prototipo avanzado de IIoT utilizando hardware Raspberry Pi y software de código abierto (broker MQTT, Apache NiFi, MiNiFi y MiNiFi C2 Server). Me centraré en la arquitectura, la conectividad, la recopilación de datos y la reconfiguración automática.

Este artículo está destinado a ser el comienzo de una serie de artículos sobre IoT. El procesamiento de bordes y el análisis de datos serán el tema de los siguientes artículos, así que estad atentos :)

Arquitectura de IoT industrial

Hay muchas arquitecturas de referencia de IoT. A menudo, en entornos industriales, no tiene acceso directo a sensores y sistemas de control. Se utiliza una puerta de enlace para unir el mundo OT y el mundo de las TI. Por esta razón, la arquitectura IIoT a menudo incluye dispositivos de borde, puertas de enlace, concentradores regionales y, finalmente, sistemas de almacenamiento / procesamiento.

La siguiente imagen muestra la arquitectura global de nuestro sistema y las herramientas de software que usaremos en cada nivel.

En el nivel del borde , los sensores recopilan información sobre el mundo digital y la envían a una puerta de enlace a través de una variedad de protocolos cableados e inalámbricos (Serie, RS-485, MODBUS, bus CAN, OPC UA, BLE, WiFi, etc.). En nuestro ejemplo, utilizaremos varios sensores (luz, temperatura, cámaras, acelerómetros, etc.) que envían datos a la puerta de enlace a través de WiFi.

La puerta de enlace es una Raspberry Pi que ejecuta un Mosquitto Broker y un agente MiNiFi. Mosquitto es un agente de mensajería liviano y de código abierto que utilizamos para exponer datos de sensores a través del protocolo MQTT. MQTT tiene una huella mínima que lo hace adecuado para aplicaciones de IoT y hardware con recursos limitados, como teléfonos o microcontroladores.

Apache MiNiFi, un subproyecto de Apache NiFi, es un agente liviano que implementa las funciones principales de Apache NiFi, centrándose en la recopilación de datos en el borde.

Los objetivos de diseño de MiNiFi son: tamaño pequeño y bajo consumo de recursos, gestión centralizada de agentes e inteligencia de borde. MiNiFi se puede integrar fácilmente con NiFi a través del protocolo Site-to-Site (S2S) para construir una solución de gestión de flujo de un extremo a otro que sea escalable, segura y proporcione una cadena de custodia completa de la información (procedencia).

En nuestro sistema, MiNiFi se suscribirá a todos los temas del corredor Mosquitto y reenviará cada mensaje nuevo a NiFi a nivel regional. También podemos usarlo para conectarnos al sistema SCADA o cualquier otro proveedor de datos OT.

A nivel regional, tenemos dos componentes:

Apache NiFi es una poderosa plataforma de flujo de datos con más de 200 conectores listos para usar. Gracias a su interfaz de usuario, diseñar flujos de datos se vuelve rápido y fácil.

NiFi no cambia el poder por la simplicidad. De hecho, es un sistema distribuido altamente escalable con entrega, contrapresión y distribución de carga garantizadas. Estas características hacen de NiFi una gran herramienta para aplicaciones de IoT donde la calidad de la red puede ser desafiante.

En nuestro sistema, NiFi desempeña el papel central de recopilar datos de cada fábrica y enrutarlos a varios sistemas y aplicaciones (HDFS, HBase, Kafka, S3, etc.).

MiNiFi C2 Server (MiNiFi Commande & Control) es otro subproyecto de Apache NiFi actualmente en desarrollo. Su función es proporcionar un punto central de configuración a cientos o miles de agentes MiNiFi en la naturaleza. El servidor C2 administra clases de aplicaciones versionadas (configuraciones de flujo MiNiFi) y las expone a través de una API Rest. Los agentes MiNiFi pueden conectarse a esta API con una frecuencia definida para actualizar su configuración.

Una vez que los datos llegan a los servidores de la empresa, en la nube o en el centro de datos , existe un gran conjunto de aplicaciones que se pueden implementar. El monitoreo en tiempo real, el análisis y la optimización de procesos o el mantenimiento predictivo son algunos ejemplos. El procesamiento de datos y la implementación de casos de uso se discutirán en un artículo futuro.

Implementación del sistema

Comencemos a construir nuestro prototipo.

Preparando la Raspberry Pi: MQTT y MiNiFi

Para instalar el agente Mosquitto MQTT y el agente MiNiFi, ejecute los siguientes comandos en su Raspberry Pi.

Para tener un tamaño pequeño, MiNiFi viene con un conjunto mínimo de procesadores predeterminados. Es posible agregar cualquier procesador NiFi implementando el NAR (Archivo NiFi) en el directorio lib. En el último comando del bloque siguiente, agrego el NAR del procesador MQTT.

sudo apt-get update#install and run Mosquitto broker on default port 1883sudo apt-get install mosquittomosquitto#install and prepare MiNiFi agentwget //apache.crihan.fr/dist/nifi/minifi/0.4.0/minifi-0.4.0-bin.tar.gztar -xvf minifi-0.4.0-bin.tar.gzcd minifi-0.4.0#add mqtt processorwget //github.com/ahadjidj-hw/NiFi/raw/master/nifi-mqtt-nar-1.5.0.nar -P ./lib/

De forma predeterminada, la configuración de un agente MiNiFi requiere editar el archivo ./conf/config.yml para incluir la lista de procesadores usados ​​y sus configuraciones. La configuración se puede escribir manualmente o diseñar usando la interfaz de usuario de NiFi y exportando el flujo como una plantilla. La plantilla es un archivo XML que necesitamos convertir a un archivo YML con el kit de herramientas MiNiFi. Aquí hay un ejemplo de un archivo de configuración que sigue a un archivo y envía cada línea a un NiFi remoto a través de S2S.

Para nuestro proyecto, no usaremos estos pasos manuales. Con muchos agentes MiNiFi que se ejecutan en fábricas distribuidas geográficamente, no es posible detener manualmente, editar el config.yml y luego reiniciar cada agente cada vez que su configuración necesita cambiar.

MiNiFi utiliza un "Change Ingestor" mediante el cual se notifica al agente de una posible nueva configuración. Los procesadores de cambios son módulos conectables y actualmente se admiten tres procesadores OOTB:

  • FileChangeIngestor
  • RestChangeIngestor
  • PullHttpChangeIngestor

Usaremos un PullHttpChangeIngestor para consultar un servidor C2 cada período de tiempo y descargar cualquier configuración nueva disponible. Para configurar este ingestor, edite el archivo ./conf/bootstrap.conf, descomente las líneas correspondientes y establezca las propiedades del ingestor de la siguiente manera:

nifi.minifi.notifier.ingestors=org.apache.nifi.minifi.bootstrap.configuration.ingestors.PullHttpChangeIngestor
# Hostname on which to pull configurations from
nifi.minifi.notifier.ingestors.pull.http.hostname=c2-server
# Port on which to pull configurations from
nifi.minifi.notifier.ingestors.pull.http.port=10080
# Path to pull configurations from
nifi.minifi.notifier.ingestors.pull.http.path=/c2/config
# Query string to pull configurations with
nifi.minifi.notifier.ingestors.pull.http.query=class=iot-minifi-raspberry-agent
# Period on which to pull configurations from, defaults to 5 minutes if commented out
nifi.minifi.notifier.ingestors.pull.http.period.ms=60000

Con esta configuración, cada agente MiNiFi consultará la API REST del servidor C2 en // c2-server: 10080 / c2 / config cada 1 minuto y solicitará la última configuración para la clase "iot-minifi-raspberry-agent".

Nota: la frecuencia de 1 minuto es solo para fines de demostración. No actualizará a sus agentes con tanta frecuencia.

No inicie su agente ahora, pasemos al nivel regional y configuremos el servidor MiNiFi C2 y NiFi.

Instalación y configuración del servidor MiNiFi C2

Instale el servidor MiNiFi C2 en un servidor público que sea accesible desde los agentes MiNiFi. Puede utilizar la implementación jerárquica de C2 para aplicaciones con restricciones de red, como se describe en algunas líneas a continuación. Ejecute el siguiente comando para instalar el servidor C2:

wget //apache.crihan.fr/dist/nifi/minifi/0.4.0/minifi-c2-0.4.0-bin.tar.gztar -xvf minifi-c2-0.4.0-bin.tar.gzcd minifi-c2-0.4.0

El servidor C2 expone las aplicaciones MiNiFi a través de una API REST organizada por clases. C2 admite "proveedores de configuración" conectables y actualmente admite:

  • The CacheConfigurationProvider, whichlooks at the directory on the filesystem or on S3
  • The DelegatingConfigurationProvider, which delegates to another C2 server to allow for hierarchical C2 structures
  • The NiFiRestConfigurationProvider, which pulls templates from a NiFi instance over its REST API

Configure the C2 Server to use NiFi as a configuration provider. Edit the file ./conf/minifi-c2-context.xml and provide the NiFi server address //nifi-dev:8080

Installing and configuring the NiFi Server

Install NiFi on a server reachable from the C2 server and run it.

wget //apache.crihan.fr/dist/nifi/1.6.0/nifi-1.6.0-bin.tar.gztar -xvf nifi-1.6.0-bin.tar.gzcd nifi-1.6.0./bin/nifi.sh start

Let’s connect to the NiFi UI at //nifi-dev:8080/nifi/ and create the flow that will run in the MiNiFi agents. But before this, add an input port to the root canvas and name it “from Raspberry MiNiFi”. This is where NiFi will receive flow files from MiNiFi.

Add a consumeMQTT processor to subscribe to the Mosquitto broker and subscribe to all topics under iot/sensors. Note that the tcp://raspberrypi:1883 here is equivalent to tcp://localhost:1883, since this flow will be running on the Raspberry Pi.

Use an UpdateAttribute processor to add a “version” attribute that we will use to show the re-configuration feature. You can add any attribute you want: timestamp, agent name, location, and so on.

And finally, add a Remote Process Group (RPG) to send the consumed events to NiFi. Connect these three processors.

Your flow now looks like the below screenshot. The left flow will be running in NiFi to receive data from MiNiFi. The right flow here is only for design and will effectively run on each Raspberry Pi.

Save the right flow as a template under the name “iot-minifi-raspberry-agent.v1”. The naming convention here is very important. We must use the same name as the class name used in the MiNiFi bootstrap configuration.

Deploy and start the application

Before starting the MiNiFi agents on the Raspberry Pi, let’s see if the C2 server is well configured. Open the following URL in your web browser : //c2-server:10080/c2/config?class=iot-minifi-raspberry-agent&version=1 . The C2 Server replies with a file containing the configuration of the template we built, in YML format . That’s great.

If you look to the C2 logs, you can see that the server received a query with the parameters {class=[iot-minifi-raspberry-agent], version=[1]}

Now that communication between the different components of the architecture (MQTT, MiNiFi, NiFi and C2) is working, start the MiNiFi agent on the Raspberry Pi with the command:

./bin/minifi.sh start

After a few seconds, you see the following C2 server logs. The host 192.168.1.50 (this is the Raspberry Pi’s IP address) asked the C2 server to give it the latest version of the class “iot-minifi-raspberry-agent”. Compared to our previous call with the web browser, you’ll notice that the MiNiFi agent didn’t specify a version. If you open now the MiNiFi agent configuration at ./conf/config.yml you will find the same conf file that we retrieved from the C2 Rest API.

Also, the MQTT shows that the MiNiFi agent connected to the broker and subscribed to the topics iot/sensors/#

Perfect! The IIoT system is running like a charm. Now let’s start our sensors to generate data and publish it in MQTT. MiNiFi will then start consuming data and sending it to NiFi as shown in the following screenshot where we have received 196 messages.

Now let’s inspect one of these messages with the provenance feature of NiFi. This data comes from the light sensor “iot/sensors/LightIntensity/z” and the application version is 1.

Automagic Warm Redeploy

Now that our IIoT is running and data is flowing from every factory to our data center, let’s deploy a new application. For our test, we will make a minor modification to our MiNiFi agent configuration. Go to the NiFi web UI and edit the updateAttribute processor. Set the “version” attribute to 2 instead of 1 and save the flow in a new template “iot-minifi-raspberry-agent.v2”. That’s all! The new application will be automagically deployed.

You can see the C2 server logs below showing that a new version V2 was detected. The C2 server does not have this version in its cache and start a download and conversion process.

Then, the MiNiFi agents detect the new configuration, backup the previous configuration, deploy the new one, and restart.

Now let’s look to the data coming from the agents. As you can see in the provenance UI below, this data comes from a Gyroscope and has an application version 2.

Conclusions

Apache NiFi and its eco-system (MiNiFi and C2 server) are powerful tools for end-to-end IoT data management. It can be used to easily and quickly build advanced IoT applications with flexible architectures and advanced features (automatic warm deploy, data provenance, backpressure, and so on).

In future articles, I’ll show you how to use this data, secure the platform, and implement advanced edge processing scenarios. In the meantime, you can read this article on how Renault, a multinational automobile manufacturer, uses Apache NiFi in IIoT projects and what are the best practices that they adopted.

Thanks for reading. As always, feedback and suggestions are welcome.

If you found this article useful then give it some claps and follow me for more Big Data and IoT articles!