Kā izveidot IIoT sistēmu, izmantojot Apache NiFi, MiNiFi, C2 serveri, MQTT un Raspberry Pi

Kā jūs domājat, cik ilgs laiks ir vajadzīgs, lai izveidotu modernu rūpnieciskā IoT prototipu, kas var:

  • Vāciet datus no sensoriem uz vārteju katrā rūpnīcā
  • Pārvietojiet sensoru datus no vienas vai vairākām rūpnīcām uz Cloud vai Data Center
  • Automātiski iesildīt - izvietot jaunas konfigurācijas visām malējām ierīcēm
  • Atbalsta liela mēroga datu apjomu un tiešo drošību

Izmantojot pareizo rīku, jūs varat izveidot šādu sistēmu mazāk nekā stundas laikā! Šajā emuāra ziņā es jums parādīšu, kā ieviest uzlabotu IIoT prototipu, izmantojot Raspberry Pi aparatūru un atvērtā koda programmatūras (MQTT brokeris, Apache NiFi, MiNiFi un MiNiFi C2 serveris). Es pievērsīšos arhitektūrai, savienojamībai, datu vākšanai un automātiskai pārkonfigurēšanai.

Šis raksts ir domāts rakstu sērijas par IoT sākumam. Par malu apstrādi un datu analīzi runāsim nākamajos rakstos, tāpēc sekojiet jaunumiem :)

Rūpnieciskā IoT arhitektūra

Ir daudz IoT atsauces arhitektūru. Bieži vien rūpniecības apstākļos jums nav tiešas piekļuves sensoriem un vadības sistēmām. Vārteja tiek izmantota, lai savienotu OT un IT pasauli. Šī iemesla dēļ IIoT arhitektūra bieži ietver malas ierīces, vārtejas, reģionālos mezglus un visbeidzot glabāšanas / apstrādes sistēmas.

Šajā attēlā parādīta mūsu sistēmas globālā arhitektūra un programmatūras rīki, kurus mēs izmantosim katrā līmenī.

Malu līmenī sensori apkopo informāciju par digitālo pasauli un nosūta tos vārtejai, izmantojot dažādus vadu un bezvadu protokolus (sērijas, RS-485, MODBUS, CAN kopne, OPC UA, BLE, WiFi utt.). Šajā piemērā mēs izmantosim dažādus sensorus (gaisma, temperatūra, kameras, akselerometri utt.), Kas datus sūta vārtejai, izmantojot WiFi.

Vārteja ir Raspberry Pi, kas vada Mosquitto Broker un MiNiFi aģentu. Mosquitto ir atvērtā koda, viegls ziņojumapmaiņas brokeris, kuru mēs izmantojam sensoru datu atklāšanai, izmantojot MQTT protokolu. MQTT ir minimāls nospiedums, kas padara to piemērotu IoT lietojumprogrammām un ierobežotas aparatūras, piemēram, tālruņu vai mikrokontrolleru, resursu atjaunošanai.

Apache MiNiFi - Apache NiFi apakšprojekts - ir viegls līdzeklis, kas īsteno Apache NiFi galvenās iezīmes, koncentrējoties uz datu vākšanu malā.

MiNiFi dizaina mērķi ir: mazs izmērs un mazs resursu patēriņš, aģentu centrālā vadība un visaugstākā inteliģence. MiNiFi var viegli integrēt NiFi, izmantojot Site-to-Site protokolu (S2S), lai izveidotu mērogojamu, drošu un pilnu informācijas glabāšanas ķēdi (izcelsmes vietu) nodrošinošu plūsmas pārvaldības risinājumu.

Mūsu sistēmā MiNiFi abonēs visas Mosquitto brokera tēmas un katru jauno ziņojumu pārsūtīs NiFi reģionālā līmenī. Mēs to varam izmantot arī, lai izveidotu savienojumu ar SCADA sistēmu vai jebkuru citu OT datu nodrošinātāju.

Reģionālajā līmenī mums ir divas sastāvdaļas:

Apache NiFi ir spēcīga datu plūsmas platforma ar vairāk nekā 200 savienotājiem, kas pieejami komplektācijā. Pateicoties lietotāja saskarnei, datu plūsmu projektēšana kļūst ātra un vienkārša.

NiFi nepārdod jaudu vienkāršības labad. Patiešām, tā ir ļoti pielāgojama sadalīta sistēma ar garantētu piegādi, pretspiedienu un slodzes sadalījumu. Šīs funkcijas padara NiFi par lielisku IoT lietojumprogrammu rīku, kur tīkla kvalitāte var būt sarežģīta.

Mūsu sistēmā NiFi ir galvenā loma, vācot datus no katras rūpnīcas un novirzot tos uz vairākām sistēmām un lietojumprogrammām (HDFS, HBase, Kafka, S3 un tā tālāk).

MiNiFi C2 serveris (MiNiFi Commande & Control) ir vēl viens Apache NiFi apakšprojekts, kas pašlaik tiek izstrādāts. Tās uzdevums ir nodrošināt centrālu konfigurācijas punktu simtiem vai tūkstošiem MiNiFi aģentu savvaļā. C2 serveris pārvalda versijas ar lietojumprogrammām (MiNiFi plūsmas konfigurācijas) un pakļauj tās, izmantojot Rest API. MiNiFi aģenti var izveidot savienojumu ar šo API noteiktā biežumā, lai atjauninātu savu konfigurāciju.

Kad dati nokļūst uzņēmuma serveros, mākonī vai datu centrā , ir pieejams liels lietojumprogrammu kopums. Reāllaika monitorings, procesu analīze un optimizācija vai paredzama uzturēšana ir daži piemēri. Datu apstrāde un izmantošanas gadījumu ieviešana tiks apspriesta nākamajā rakstā.

Sistēmas ieviešana

Sāksim veidot savu prototipu.

Raspberry Pi sagatavošana: MQTT un MiNiFi

Lai instalētu Mosquitto MQTT brokeri un MiNiFi aģentu, savā Raspberry Pi izpildiet šādas komandas.

Lai MiNiFi būtu mazs izmērs, tas ir iepakots ar minimālu noklusējuma procesoru komplektu. Ir iespējams pievienot jebkuru NiFi procesoru, izvietojot NAR (NiFi arhīvu) lib direktorijā. Zemāk esošā bloka pēdējā komandā es pievienoju MQTT procesora NAR.

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/

Pēc noklusējuma MiNiFi aģenta konfigurēšanai ir nepieciešams rediģēt failu ./conf/config.yml, lai iekļautu izmantoto procesoru sarakstu un to konfigurācijas. Konfigurāciju var rakstīt manuāli vai noformēt, izmantojot NiFi lietotāja interfeisu un plūsmu eksportējot kā veidni. Veidne ir XML fails, kas mums jāpārvērš par YML failu, izmantojot MiNiFi rīkkopu. Šis ir konfigurācijas faila piemērs, kas savieno failu un nosūta katru līniju uz attālo NiFi, izmantojot S2S.

Mūsu projektā mēs neizmantosim šīs manuālās darbības. Daudziem MiNiFi aģentiem, kas darbojas ģeogrāfiski sadalītās rūpnīcās, nav iespējams manuāli apturēt, rediģēt config.yml un pēc tam restartēt katru aģentu ikreiz, kad ir jāmaina viņu konfigurācija.

MiNiFi izmanto “Change Ingestor”, ar kuru aģentam tiek paziņots par potenciāli jaunu konfigurāciju. Pārmaiņu uzņemēji ir pievienojami moduļi, un pašlaik OOTB tiek atbalstīti trīs uzņemtāji:

  • FileChangeIngestor
  • RestChangeIngestor
  • PullHttpChangeIngestor

Mēs izmantosim PullHttpChangeIngestor, lai katru laika periodu vaicātu C2 serverim un lejupielādētu visu pieejamo jauno konfigurāciju. Lai konfigurētu šo ievadītāju, rediģējiet failu ./conf/bootstrap.conf, noņemiet atbilstošo rindiņu komentāru un iestatiet uzņemšanas rekvizītus šādi:

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

With this configuration, each MiNiFi agent will query the C2 Server REST API at //c2-server:10080/c2/config every 1 minute and ask for the latest configuration for the “iot-minifi-raspberry-agent” class.

Note: the 1 minute frequency is only for demo purposes. You won’t be updating your agents so frequently.

Don’t start your agent now, and let’s move to the regional level and configure MiNiFi C2 server and NiFi.

Installing and configuring the MiNiFi C2 Server

Install MiNiFi C2 server on a public server that’s reachable from the MiNiFi agents. You can use hierarchical C2 deployment for network constrained applications as described a few lines below. Run the following command to install the C2 server:

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

The C2 server exposes MiNiFi applications through a REST API organized by classes. C2 supports pluggable “Configuration Providers” and currently supports:

  • 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).

Turpmākajos rakstos es jums parādīšu, kā izmantot šos datus, nodrošināt platformas drošību un ieviest uzlabotus malas apstrādes scenārijus. Tikmēr jūs varat izlasīt šo rakstu par to, kā Renault, daudznacionāls automobiļu ražotājs, izmanto Apache NiFi IIoT projektos un kādas ir viņu labākās prakses.

Paldies, ka lasījāt. Kā vienmēr, atsauksmes un ieteikumi ir laipni gaidīti.

Ja jums šis raksts šķita noderīgs, dodiet tam dažus aplaudus un sekojiet man, lai iegūtu vairāk Big Data un IoT rakstu!