Как вы думаете, сколько времени потребуется, чтобы создать усовершенствованный прототип промышленного Интернета вещей, который может:

  • Собирайте данные от датчиков к шлюзу на каждом заводе
  • Перенести данные датчиков с одного или нескольких заводов в облако или центр обработки данных
  • Автоматическое развертывание новых конфигураций на всех периферийных устройствах
  • Поддержка большого объема данных и сквозной безопасности

С правильным инструментом вы можете построить такую ​​систему менее чем за час! В этом сообщении блога я покажу вам, как реализовать расширенный прототип IIoT с использованием оборудования Raspberry Pi и программного обеспечения с открытым исходным кодом (брокер MQTT, Apache NiFi, MiNiFi и сервер MiNiFi C2). Я сосредоточусь на архитектуре, подключении, сборе данных и автоматической перенастройке.

Эта статья должна стать началом серии статей об IoT. Обработка кромок и анализ данных будут предметом следующих статей, так что следите за обновлениями :)

Промышленная архитектура Интернета вещей

Существует множество эталонных архитектур Интернета вещей. Часто в промышленных условиях у вас нет прямого доступа к датчикам и системам управления. Шлюз используется для соединения ОТ и ИТ-мира. По этой причине архитектура IIoT часто включает в себя граничные устройства, шлюзы, региональные концентраторы и, наконец, системы хранения / обработки.

На следующем рисунке показана глобальная архитектура нашей системы и программные инструменты, которые мы будем использовать на каждом уровне.

На граничном уровне датчики собирают информацию о цифровом мире и отправляют ее на шлюз через различные проводные и беспроводные протоколы (последовательный, RS-485, MODBUS, CAN bus, OPC UA, BLE, WiFi и так далее). В нашем примере мы будем использовать различные датчики (света, температуры, камеры, акселерометры и т. Д.), Которые отправляют данные на шлюз через Wi-Fi.

Шлюз - это Raspberry Pi с брокером Mosquitto и агентом MiNiFi. Mosquitto - это легкий брокер обмена сообщениями с открытым исходным кодом, который мы используем для предоставления данных с датчиков через протокол MQTT. MQTT занимает минимальную площадь, что делает его подходящим для приложений Интернета вещей и оборудования с ограниченными ресурсами, такого как телефоны или микроконтроллеры.

Apache MiNiFi - подпроект Apache NiFi - представляет собой легкий агент, который реализует основные функции Apache NiFi с упором на сбор данных на периферии.

Цели проектирования MiNiFi: небольшой размер и низкое потребление ресурсов, централизованное управление агентами и периферийный интеллект. MiNiFi может быть легко интегрирован с NiFi через протокол Site-to-Site (S2S) для создания решения для сквозного управления потоками, которое является масштабируемым, безопасным и обеспечивает полную цепочку хранения информации (источник).

В нашей системе MiNiFi будет подписываться на все темы брокера Mosquitto и пересылать каждое новое сообщение в NiFi на региональном уровне. Мы также можем использовать его для подключения к системе SCADA или любому другому поставщику данных OT.

На региональном уровне у нас есть два компонента:

Apache NiFi - мощная платформа для передачи данных с более чем 200 готовыми коннекторами. Благодаря пользовательскому интерфейсу проектирование потоков данных становится быстрым и простым.

NiFi не торгует силой ради простоты. Действительно, это хорошо масштабируемая распределенная система с гарантированной доставкой, противодавлением и распределением нагрузки. Эти функции делают NiFi отличным инструментом для приложений Интернета вещей, где качество сети может быть проблемным.

В нашей системе NiFi играет центральную роль в сборе данных с каждой фабрики и их маршрутизации в несколько систем и приложений (HDFS, HBase, Kafka, S3 и т. Д.).

Сервер MiNiFi C2 (MiNiFi Commande & Control) - еще один подпроект Apache NiFi, который в настоящее время находится в стадии разработки. Его роль заключается в обеспечении центральной точки настройки для сотен или тысяч агентов MiNiFi в дикой природе. Сервер C2 управляет версионными классами приложений (конфигурациями потока MiNiFi) и предоставляет их через Rest API. Агенты MiNiFi могут подключаться к этому API с определенной частотой для обновления своей конфигурации.

После того, как данные попадают на серверы компании, в облако или в центр обработки данных, можно реализовать большой набор приложений. Мониторинг в реальном времени, анализ и оптимизация процессов или профилактическое обслуживание - вот лишь несколько примеров. Обработка данных и реализация сценария использования будут рассмотрены в следующей статье.

Реализация системы

Приступим к созданию нашего прототипа.

Подготовка Raspberry Pi: MQTT и MiNiFi

Чтобы установить брокер Mosquitto MQTT и агент MiNiFi, выполните следующие команды на своем Raspberry Pi.

Чтобы иметь небольшой размер, MiNiFi поставляется с минимальным набором процессоров по умолчанию. Можно добавить любой процессор NiFi, развернув NAR (архив NiFi) в каталоге lib. В последней команде блока ниже я добавляю NAR процессора MQTT.

sudo apt-get update
#install and run Mosquitto broker on default port 1883
sudo apt-get install mosquitto
mosquitto
#install and prepare MiNiFi agent
wget http://apache.crihan.fr/dist/nifi/minifi/0.4.0/minifi-0.4.0-bin.tar.gz
tar -xvf minifi-0.4.0-bin.tar.gz
cd minifi-0.4.0
#add mqtt processor
wget https://github.com/ahadjidj-hw/NiFi/raw/master/nifi-mqtt-nar-1.5.0.nar -P ./lib/

По умолчанию для настройки агента MiNiFi требуется отредактировать файл ./conf/config.yml, чтобы включить в него список используемых процессоров и их конфигурации. Конфигурация может быть написана вручную или разработана с использованием пользовательского интерфейса NiFi и экспорта потока в виде шаблона. Шаблон - это XML-файл, который нам нужно преобразовать в YML-файл с помощью MiNiFi toolkit. Вот пример файла конфигурации, который отслеживает файл и отправляет каждую строку на удаленный NiFi через S2S.

В нашем проекте мы не будем использовать эти ручные шаги. Поскольку многие агенты MiNiFi работают на географически распределенных фабриках, невозможно вручную останавливать, редактировать config.yml, а затем перезапускать каждый агент каждый раз, когда необходимо изменить его конфигурацию.

MiNiFi использует «Change Ingestor», с помощью которого агент уведомляется о потенциальной новой конфигурации. Обработчики изменений представляют собой подключаемые модули, и в настоящее время поддерживаются три модуля ввода OOTB:

  • FileChangeIngestor
  • RestChangeIngestor
  • PullHttpChangeIngestor

Мы будем использовать PullHttpChangeIngestor для запроса сервера C2 каждый период времени и загрузки любой новой доступной конфигурации. Чтобы настроить этот загрузчик, отредактируйте файл ./conf/bootstrap.conf, раскомментируйте соответствующие строки и установите следующие свойства загрузчика:

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

В этой конфигурации каждый агент MiNiFi будет запрашивать REST API сервера C2 по адресу http: // c2-server: 10080 / c2 / config каждые 1 минуту и ​​запрашивать последнюю конфигурацию для iot-minifi-raspberry-agent. класс.

Примечание: частота в 1 минуту предназначена только для демонстрационных целей. Вы не будете так часто обновлять агентов.

Не запускайте свой агент сейчас, а давайте перейдем к региональному уровню и настроим сервер MiNiFi C2 и NiFi.

Установка и настройка сервера MiNiFi C2

Установите сервер MiNiFi C2 на общедоступный сервер, доступный для агентов MiNiFi. Вы можете использовать иерархическое развертывание C2 для приложений с ограничениями по сети, как описано в нескольких строках ниже. Выполните следующую команду, чтобы установить сервер C2:

wget http://apache.crihan.fr/dist/nifi/minifi/0.4.0/minifi-c2-0.4.0-bin.tar.gz
tar -xvf minifi-c2-0.4.0-bin.tar.gz
cd minifi-c2-0.4.0

Сервер C2 предоставляет приложения MiNiFi через REST API, организованный по классам. C2 поддерживает подключаемые «поставщики конфигурации» и в настоящее время поддерживает:

  • CacheConfigurationProvider, который просматривает каталог в файловой системе или на S3.
  • DelegatingConfigurationProvider, который делегирует другому серверу C2, чтобы разрешить иерархические структуры C2.
  • NiFiRestConfigurationProvider, который извлекает шаблоны из экземпляра NiFi через свой REST API.

Настройте сервер C2 для использования NiFi в качестве поставщика конфигурации. Отредактируйте файл ./conf/minifi-c2-context.xml и укажите адрес сервера NiFi http: // nifi-dev: 8080

Установка и настройка сервера NiFi

Установите NiFi на сервере, доступном с сервера C2, и запустите его.

wget http://apache.crihan.fr/dist/nifi/1.6.0/nifi-1.6.0-bin.tar.gz
tar -xvf nifi-1.6.0-bin.tar.gz
cd nifi-1.6.0
./bin/nifi.sh start

Давайте подключимся к пользовательскому интерфейсу NiFi по адресу http: // nifi-dev: 8080 / nifi / и создадим поток, который будет выполняться в агентах MiNiFi. Но перед этим добавьте порт ввода к корневому холсту и назовите его from Raspberry MiNiFi. Здесь NiFi будет получать потоковые файлы от MiNiFi.

Добавьте процессор consumerMQTT, чтобы подписаться на брокера Mosquitto и подписаться на все темы в разделе iot / sensor. Обратите внимание, что tcp: // raspberrypi: 1883 здесь эквивалентен tcp: // localhost: 1883, поскольку этот поток будет выполняться на Raspberry Pi.

Используйте процессор UpdateAttribute, чтобы добавить атрибут «версия», который мы будем использовать для отображения функции повторной конфигурации. Вы можете добавить любой атрибут, который хотите: метку времени, имя агента, местоположение и так далее.

И, наконец, добавьте группу удаленных процессов (RPG) для отправки потребляемых событий в NiFi. Подключите эти три процессора.

Теперь ваш поток выглядит как на скриншоте ниже. Левый поток будет работать в NiFi для получения данных от MiNiFi. Правильный поток здесь предназначен только для дизайна и будет эффективно работать на каждом Raspberry Pi.

Сохраните правый поток как шаблон под именем «iot-minifi-raspberry-agent.v1». Соглашение об именах здесь очень важно. Мы должны использовать то же имя, что и имя класса, используемое в конфигурации начальной загрузки MiNiFi.

Разверните и запустите приложение

Перед запуском агентов MiNiFi на Raspberry Pi давайте посмотрим, правильно ли настроен сервер C2. Откройте в браузере следующий URL: http: // c2-server: 10080 / c2 / config? Class = iot-minifi-raspberry-agent & version = 1. Сервер C2 отвечает файлом, содержащим конфигурацию созданного нами шаблона в формате YML. Замечательно.

Если вы посмотрите логи C2, то увидите, что сервер получил запрос с параметрами {class = [iot-minifi-raspberry-agent], version = [1]}

Теперь, когда связь между различными компонентами архитектуры (MQTT, MiNiFi, NiFi и C2) работает, запустите агент MiNiFi на Raspberry Pi с помощью команды:

./bin/minifi.sh start

Через несколько секунд вы увидите следующие журналы сервера C2. Хост 192.168.1.50 (это IP-адрес Raspberry Pi) попросил сервер C2 предоставить ему последнюю версию класса «iot-minifi-raspberry-agent». По сравнению с нашим предыдущим вызовом с веб-браузером вы заметите, что агент MiNiFi не указал версию. Если вы сейчас откроете конфигурацию агента MiNiFi по адресу ./conf/config.yml, вы найдете тот же файл conf, который мы получили из C2 Rest API.

Также MQTT показывает, что агент MiNiFi подключился к брокеру и подписался на темы iot / sensor / #

Идеально! Система IIoT работает как шарм. Теперь давайте запустим наши датчики для генерации данных и публикации их в MQTT. Затем MiNiFi начнет потреблять данные и отправлять их в NiFi, как показано на следующем снимке экрана, где мы получили 196 сообщений.

Теперь давайте проверим одно из этих сообщений с особенностью происхождения NiFi. Эти данные поступают от датчика освещенности «iot / sizes / LightIntensity / z», а версия приложения - 1.

Automagic Warm Redeploy

Теперь, когда наш IIoT запущен и данные поступают с каждой фабрики в наш центр обработки данных, давайте развернем новое приложение. Для нашего теста мы внесем незначительные изменения в конфигурацию нашего агента MiNiFi. Перейдите в веб-интерфейс NiFi и отредактируйте процессор updateAttribute. Установите для атрибута «версия» значение 2 вместо 1 и сохраните поток в новом шаблоне «iot-minifi-raspberry-agent.v2». Это все! Новое приложение будет развернуто автоматически.

Вы можете увидеть журналы сервера C2 ниже, показывающие, что была обнаружена новая версия V2. Сервер C2 не имеет этой версии в кэше и запускает процесс загрузки и преобразования.

Затем агенты MiNiFi обнаруживают новую конфигурацию, создают резервную копию предыдущей конфигурации, развертывают новую и перезапускают.

Теперь посмотрим на данные, поступающие от агентов. Как вы можете видеть в пользовательском интерфейсе происхождения ниже, эти данные поступают с гироскопа и имеют версию приложения 2.

Выводы

Apache NiFi и его экосистема (сервер MiNiFi и C2) - мощные инструменты для сквозного управления данными IoT. Его можно использовать для простого и быстрого создания расширенных приложений Интернета вещей с гибкой архитектурой и расширенными функциями (автоматическое горячее развертывание, происхождение данных, обратное давление и т. Д.).

В следующих статьях я покажу вам, как использовать эти данные, защитить платформу и реализовать сценарии расширенной периферийной обработки. А пока вы можете прочитать эту статью о том, как Renault, международный производитель автомобилей, использует Apache NiFi в проектах IIoT и какие передовые практики они переняли.

Спасибо за прочтение. Как всегда, приветствуются отзывы и предложения.

Если вы нашли эту статью полезной, хлопайте в ладоши и подписывайтесь на меня, чтобы увидеть больше статей о Big Data и IoT!