Русский
Русский
English
Статистика
Реклама

Iiot

GrafanaZabbix Визуализация работы производственной линии

27.08.2020 20:07:22 | Автор: admin

В этой статья я хочу поделиться опытом использования open source систем Zabbix и Grafana для визуализации работы производственных линий. Информация может быть полезна тем, кто ищет быстрый способ визуального отображения или аналитики собранных данных в проектах промышленной автоматизации или IoT. Статья не является подробным руководством, это скорее концепция системы мониторинга, основанная на открытом программном обеспечении для производственного предприятия.


Инструментарий


Zabbix его мы используем давно для мониторинга ИТ инфраструктуры завода. Система оказалось настолько удобной и универсальной, что мы стали заводить в нее данные с производственных линий, датчиков и контроллеров. Это нам позволило собрать все данные метрик в одном месте, сделать простые графики расхода ресурсов и производительности оборудования, но очень не хватало аналитики и красивых графиков.
Grafana это мощнейший инструмент для аналитики и визуализации данных. Большое количество плагинов позволяют забирать данные из различных источников (zabbix, clickhouse, influxDB), обрабатывать их на лету (считать среднее значение, сумму, разницу и т.д.) и рисовать всевозможные графики (от простых линий, спидометров, таблиц до сложных схем).
Draw.io сервис, позволяющий в онлайн редакторе нарисовать от простой блок схемы до плана помещений. Есть много готовых шаблонов и нарисованных объектов. Данные можно экспортировать во все основные графические форматы или xml.


Собираем все вместе


Статей как установить и настроить Grafana и Zabbix написано много, я расскажу про основные моменты конфигурации.
На Zabbix сервере создается узел сети (host), которому будут принадлежать элементы данных (item) с метриками от наших датчиков. Имена узлов и элементов данных желательно продумать заранее и сделать максимально структурированными, так как к ним мы будем обращаться из графаны через регулярные выражения. Такой подход удобен тем, что можно одним запросом получать данные с группы элементов.


Для настройки графаны потребуется установить дополнительные плагины:


  • Zabbix by Alexander Zobnin (alexanderzobnin-zabbix-app) интеграция с zabbix
  • natel-discrete-panel плагин для дискретной визуализации на горизонтальном графике
  • pierosavi-imageit-panel плагин для отображения данных поверх своей картинки
  • agenty-flowcharting-panel плагин для динамической визуализации схемы из draw.io

Сама интеграция с заббиксом настраивается в графане, пункт меню Configuration\Data sources\Zabbix. Там нужно указать адрес api zabbix сервера, у меня это http://zabbix.local/zabbix/api_jsonrpc.php, и логин с паролем для доступа. Если все сделано правильно, при сохранении настроек будет сообщение с номером версии api: zabbix API version: 5.0.1


Создаем Dashboard


Вот тут начинается та самая магия графаны и ее плагинов.


Плагин natel-discrete-panel
У нас есть данные о статусах двигателей на линиях (работает = 1, не работает =0). При помощи графика discrete мы можем нарисовать шкалу, на которой будет видно: статус двигателя, сколько он проработал минутах/часах или % и как часто запускался.


image
Визуализация статусов двигателей


На мой взгляд, это один из лучших графиков для визуализации производительности оборудования. Сразу видно сколько времени оно простаивает, в каких режимах работает чаще. Данных может быть много, есть возможность их агрегации по диапазонам, преобразование по значениям (если значение 1, то отображать как ON)


Плагин pierosavi-imageit-panel
Imageit удобно использовать когда у вас уже есть нарисованная схема или план помещения, на которую вы хотите нанести данные с датчиков. В настройках визуализации нужно указать url адрес к картинке и добавить нужные вам элементы sensor. Элемент появляется на картинке и его можно разместить в нужном месте мышкой.


image
Схема печи с метриками температуры и давления


Плагин agenty-flowcharting-panel
Про создание визуализации FlowCharting я хотел бы рассказать более подробно, так как это невероятно функциональный инструмент. Он позволяет сделать динамическую мнемосхему, элементы которой будут реагировать на значения метрик (менять цвет, положение, название итд).


Получение данных


Создание любого элемента визуализации в графане начинается с запроса данных из источника, в нашем случае это zabbix. При помощи запросов нужно получить все метрики, которыми мы хотим воспользоваться на схеме. Реквизиты метрик это имена элементов данных в заббиксе, можно указать как отдельную метрику, так и множество с фильтрацией через регулярное выражение. В моем примере поле Item содержит выражение: /(^линия 1)|(наличие)|(кабачок)/ это означает: отобрать все метрики, имя которых строго начинается с линия 1 или содержит слово наличие или содержит слово кабачок


image
Пример настройки запроса данных о двигателях первой линии и наличии сырья


Преобразование данных


Исходные данные могут быть не всегда в том виде, в котором нам нужно их отобразить. Например, у нас есть ежеминутные данные о весе продукта в емкости (кг), и нам нужно отобразить скорость заполнения в т/час. Я это делаю следующим образом: беру данные о весе и преобразую их функцией графаны delta, которая считает разницу между значениями метрики, так текущий вес превращается в кг/мин. Затем умножаю на 0.06 для приведения результата в тонны/час. Так как метрика веса используется в нескольких запросах, я указываю для нее новый псевдоним (setAlias) и буду его использовать в правиле визуализации.


image
Пример использования параметра delta и множителя и переименования метрики в запросе


Вот еще пример преобразования данных: мне нужно было подсчитать кол-ва замесов (начало цикла = пуск двигателя). Метрика считается на основе статуса двигателя "линия 1 насос откачки из бака 1 (статус)". Преобразование: данные исходной метрики меняем функцией delta (разница значений), таким образом в метрике будет значение +1 для пуска двигателя, -1 для остановки и 0 когда двигатель не меняет свой статус. Затем убираю все значения меньше 1 и суммирую их. В результате получается кол-во пусков двигателя.


image
Пример преобразования данных из текущего статуса в кол-во пусков


Теперь про саму визуализацию


В настройках отображения есть кнопка Edit Draw, она запускает редактор, в котором можно нарисовать схему. У каждого объекта на схеме есть свои параметры. Например, если указать настройки шрифта в редакторе они будут применяться к визуализации данных в графане.


image
Так выглядит редактор в Draw.io


После сохранения схемы, она появится в графане и можно будет создавать правила изменения элементов.
В параметрах () мы указываем:


  • Options задается имя правила (Rule name), название или псевдоним метрики, данные которой будут использоваться (Apply to metrics). Тип агрегации данных (Aggregation) влияет на конечный результат метрики, так Last означает, что будет выбрано последнее значение, avg среднее значение за период, выбранный в верхнем правом углу.
  • Thresholds параметр пороговых значений, описывает логику применения цвета, то есть выбранный цвет будет применяться к элементам на схеме в зависимости от данных метрики. В моем примере при значении метрик 0 статус Ok цвет будет зеленый, при значении >1 статус Critical и цвет будет красный.
  • Color/Tooltip Mappings и Label/Text Mappings выбор элемента схемы и сценария его поведения. В первом сценарии объект будет закрашен, во втором на нем будет текст с данными из метрики. Для выбора объекта на схеме нужно нажать знак цепи и кликнуть мышкой на схеме.

image
На этом примере я закрашиваю насос и его стрелку красным цветом если он работает и зеленым если нет


При помощи плагина flowcharting мне удалось нарисовать схему всей линии, на которой:
1) меняется цвет агрегатов в соответствии с их статусом
2) есть сигнализация отсутствия продукта в емкостях
3) отображается настройка частот двигателей
4) скорость заполнения/сброса первого бака
5) подсчитывается кол-во циклов работы линии (замесы)


image
Визуализация работы производственной линии


Результат


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


Заключение


Мне очень понравилась связка Zabbix+Grafana и я рекомендую обратить на нее внимание, если вам нужно быстро обработать данные с контроллеров или датчиков без программирования или внедрения сложных коммерческих продуктов. Безусловно, это не заменит профессиональные SCADA системы, но будет достаточено как инструмент централизованного мониторинга всего производства.

Подробнее..

Как мы прокачали телеметрию крупного металлургического комбината

22.12.2020 16:08:30 | Автор: admin

Привет, Хабр! Я Ольга Пешина, эксперт по развитию новых технологий. Когда нашему производству огромной металлургической компании Северсталь требуется поиск, проработка и внедрение инновационных идей или прорывных информационных технологий, обращаются к нам.


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


Как сейчас: сбор данных по оптике


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


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


В общем, кабель порой приходится прокладывать заново, что влечёт как финансовые затраты, так и производственные риски. Ведь ситуационный центр нашей службы мониторинга состояния оборудования (СМСО), который следит за состоянием агрегатов по стационарным системам мониторинга и, соответственно, предотвращает аварии на оборудовании, становится слепым на время восстановления.
image


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


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


Пилот на LoRaWAN


Мы рассматривали несколько вариантов, в том числе Private LTE и NB-IoT. Смотрели и в сторону проприетарных решений. Но в итоге остановились на LoRaWAN, на базе которого и развернули пилотный проект. Он показал неоспоримые плюсы.


Частотный диапазон


Главный плюс, пожалуй, заключается в том, что сеть LoRaWAN, в отличие от Wi-Fi, работает в частотном диапазоне до 1 ГГц (кстати, нелицензируемом) с возможностью изменения параметров передачи. Высокая проницаемость субгигагерцевых сигналов позволяет передавать данные даже из подвала, который находится под металлопрокатным станом. Именно этот результат вдохновил нас больше всего.


Производители оборудования LoRaWAN заявляют дальность связи до 5 км в сложных условиях. В ходе пилотного внедрения в условиях повсеместного металла удалось получить устойчивый сигнал в радиусе 2,5 км от базовой станции. Для этого проекта мы ставили условие потери не более 5 % пакетов при передаче, но в течение полугода эксплуатации потери не превышали 1 %. Наши расчёты показывают, что 9 базовыми станциями, установленными на высоких объектах завода (трубах и т. п.), мы покроем сетью всю территорию, при этом будем работать не на предельных расстояниях, а с запасом.


Стоимость технологии


Подсчёты показали, что развертывание сети LoRaWAN для решения нашей задачи более чем в 10 раз дешевле аналогичной оптической.


Оценивая бюджет будущего масштабного проекта, мы учитывали не только стоимость передачи данных, но и затраты на подключение к сети существующих локальных контрольно-измерительных приборов (КИП). На рынке есть LoRaWAN-модемы, которые можно подключить к существующим КИП, не предпринимая серьёзной модернизации. Они избавляют от необходимости дооснащать линии датчиками там, где они уже есть.


Открытый протокол


Но даже получив хорошие результаты в частотном диапазоне LoRaWAN, мы всё ещё смотрели и на проприетарные протоколы того же участка спектра, которые заявляют большую скорость передачи данных. Они действительно работают: передают более серьёзные объёмы информации или значительно уменьшают интервал дискретности передачи. Но зависимость от вендора в условиях нашего зоопарка технологий не лучшая идея. Да и с точки зрения конкурентоспособности мы не хотели бы замыкаться на конкретных производителях, когда есть классическая открытая LPWAN-система.


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


Автономность устройств


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


Устройства LoRaWAN, которые мы тестировали в рамках пилота, при передаче раз в 5 минут продержали заряд более 3 месяцев. А это как раз минимальный срок, который нас устраивает.
Конечно, кому бы не хотелось, чтобы батареи работали год? Но тут многое зависит от условий работы. Очевидно, что при частой отправке данных или при минусовых температурах (если датчики находятся на улице зимой) длительность автономной работы будет меньше. Но мы не оставляем надежд найти партнёров, которые будут производить более энергоэффективные устройства или использовать новые типы батарей.


Безопасность


Когда мы говорим про LoRaWAN и сбор телеметрии, мы обсуждаем стык технологической и корпоративной сетей передачи данных. В технологической сети максимально высокие требования к защите информации. Но тут мы не нашли противоречий в сети LoRaWAN сигналы отлично шифруются. Предварительно мы уже проработали этот вопрос со своей информационной безопасностью для некритичных данных. Критичные данные, которые мы обязаны защищать не только в соответствии с нашими внутренними регламентами, но и по законодательству, например коммерческий учёт электроэнергии, пока останутся без LoRaWAN.


Ложка дегтя


Безусловно, у LoRaWAN есть недостатки. Главный заключается в невозможности передавать большие объёмы информации у стандарта очень низкая пропускная способность. К тому же сигнал дискретен, то есть данные не льются онлайн. Сейчас устройства отправляют информацию раз в 5 минут минимально возможный промежуток времени между пакетами на нашем пилотном стенде. Это ограничивает сферу применения LoRa, но не заставляет нас полностью отказываться от дешёвого и удобного по многим показателям стандарта.


Проанализировав результаты пилота, мы решили использовать LoRaWAN для некритичного оборудования, где можно допустить контроль параметров (температуры, уровней жидкостей, тока, вибраций и т. п.) не чаще чем раз в 5 минут, и не надо передавать гигабайты данных.


Боевой проект


Масштабное внедрение на промплощадке в Череповце только стартует. Активная фаза проекта запланирована на 2021 год.


Пока вопросов много, в том числе по помехам и ёмкости сети. Имея только теоретические расчёты на основе радиоразведки, мы не знаем, с чем столкнёмся на практике. Удастся ли нам разместить датчики так, как мы планируем? Будут ли они мешать работе оборудования? Не снесёт ли их первый же проезжающий мимо погрузчик? Не окажется ли потребность в передаче информации выше, чем мы проектировали, и не придётся ли нам срочно увеличивать запланированное количество базовых станций?


Тот факт, что LoRaWAN работает в нелицензируемом диапазоне, может добавить нам неожиданностей в радиоэфире, когда мы начнём устанавливать устройства повсеместно. Вполне ожидаемо, что на территории найдутся слепые зоны, где мы не сможем по каким-то причинам собирать информацию. Будем решать по месту ставить ретрансляторы, добавлять базовые станции или искать иные решения.


Также нам предстоит выстроить процессы замены батарей в автономных датчиках. Пока не представляем, как нам правильно (с точки зрения организации работ) следить за расходом батарей, как их менять, чтобы модемы не отправлялись в кабинеты обслуживающего персонала на 2 недели, а работали по возможности непрерывно. Но я думаю, мы с этим справимся, и LoRaWAN займёт свою нишу сбора телеметрии с некритичного оборудования, дополняя описанную выше оптическую сеть для критичных данных.


Не исключаю, что со временем у нас появятся и другие беспроводные промышленные решения, например Private LTE. Он может пригодиться там, где мы, с одной стороны, не можем протянуть провода, а с другой, всё же вынуждены передавать большие объёмы данных. Например, видеоданные с камер на удалённых площадках. Такой зоопарк решений это неплохо, когда каждое из них используется там, где это наиболее целесообразно.


Проект с LoRaWAN наверняка будет тиражироваться на других площадках Северстали. Уже сейчас нам поступает много запросов от коллег. А некоторые предприятия, оценив пилот, не стали дожидаться результатов нашего полномасштабного внедрения и запустили собственные проекты. Коллегам понравилась экономичность и уровень надёжности передачи данных с использованием этой технологии. Если мы в своих задачах отталкиваемся от мониторинга, то они решают с помощью LoRaWAN иные задачи, например контроль расходов электроэнергии и воды.


Хабравчане, а вы работали с LPWAN-решениями? Расскажите про свой опыт и кейсы применения.

Подробнее..

Recovery mode Мировой рынок умных часов рост в период коронавируса

17.07.2020 08:05:27 | Автор: admin
О том, как рост продаж умных часов в самый разгар эпидемии побил все рекорды

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

Почему эпидемия стала причиной роста продаж умных часов?


Спрос на приобретение модных и полезных гаджетов в первом квартале 2020 года рос в геометрической прогрессии. Заставив попотеть производителей, поставщиков и службы доставки, ведь только за первые три месяца было реализовано более 230.000 умных часов, на общую сумму почти 6 млрд. рублей.

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



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

В чём же их секрет? Почему, несмотря на многие ограничения и опасения, мировой спрос на рынке умных часов продолжил расти?

Изучив различные мнения, в том числе специалистов американского аналитического агентства Strategy Analytics, вывод напрашивается сам собой. Ситуация с коронавирусом многих из нас заставила задуматься о здоровье, независимо от возраста, пола и финансовых возможностей человека.

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

Лидеры продаж


Боимся быть слишком предсказуемыми, но лидером продаж на мировом рынке смарт-часов, по-прежнему остаётся компания Apple. Глобальных изменений в этом плане не произошло.

Цифры статистики от Apple по данным американского аналитического агентства Strategy Analytics:
Общая доля на рынке выросла до показателя 55%
Отгрузки увеличились на 1.5 миллиона, в сравнении с данными аналогичного периода прошлого года.
Общее число отгрузок составило почти 7.6 миллионов экземпляров

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

Второе место топовых умных часов занимает компания Samsung, что опять же весьма предсказуемо. Но факты вещь упрямая, поэтому пишем, как есть. Если говорить о достижениях компании в цифровом формате, то стоит отметить прямое влияние Ковид-19 на продажи этого бренда. Ведь начало эпидемии пошло именно со стран Азии, а Южная Корея была в числе первых.

Однако, несмотря на это, Samsung имеет следующие показатели, по сравнению с показателями 2019 года:
В первом квартале 2020 года объём поставок составил почти 1.9 миллионов экземпляров;
Рыночная же доля за первый квартал этого года снизилась на 1%, опустившись с показателя 14.9 до отметки в 13.9% (причину этого падения мы уже указали в предыдущем абзаце).

О новом игроке рынка, который занял третью позицию


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

Бронзу на мировом рынке смарт-часов получил довольно известный в мире электротехники бренд. Но это имя не так часто ассоциировалось именно со смарт-часами, поэтому неожиданное третье место, возможно, шокировало и саму компанию Garmin.
2020 год принёс бренду не только третью позицию в мире по продажам умных часов, но и увеличил их долю до 8% (при показателе 7% год назад).

Цифровые показатели Garmin тоже выглядят весьма убедительно:
Увеличение рыночной доли с 7% до 8% (как мы упоминали ранее);
Рост продаж умных часов в первом квартале 2020 года составил почти 38%;
Продано более 1.1 миллиона экземпляров часов этого бренда.

Резкий скачок показателей можно объяснить тем, что новые смарт-часы бренда Garmin нашли широкий отклик среди фитнес-тренеров и любителей спорта.

Собственно, результаты не заставили себя долго ждать. Третье место среди мировых лидеров по продажам носимой техники впервые, почти за два последних года.





*данные американского аналитического агентства Strategy Analytics

Что ждёт рынок умных часов в ближайшем будущем?


Однозначно ответить на этот вопрос, конечно, сложно. Strategy Analytics предсказал нам новый скачок роста продаж смарт-часов именно во второй половине 2020 года.

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

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

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

Вебинар Контроль качества технологии и технологической дисциплины

21.09.2020 16:09:27 | Автор: admin
image

Рады объявить о серии вебинаров посвященных контролю качества технологии и технологической дисциплины. Приглашаем всех желающих присоединиться к обсуждению во вторник, 6 октября в 11:00 по московскому времени.

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

Данная серия вебинаров будет состоять из следующих блоков:


Вводная часть: IIoT для мониторинга
Как и чем Промышленный Интернет Вещей помогает технологам
Примеры реального использования IIoT-решения на отечественных предприятиях
Онлайн-подключение к действующему заводу
Q&A с лучшими в своем классе экспертами

Мероприятие ориентировано на руководителей предприятий, специалистов, отвечающих за подготовку производства, разработчиков УП, ИТ-директоров, директоров по цифровизации и развитию.

Вебинар для вас, если вы хотите:


Выпускать больше/качественнее благодаря современному подходу к подготовке производства
Увидеть места, где уместно пересмотреть и оптимизировать технологию
Сбалансировать выпуск за счет выравнивания производственных циклов
Узнать, как и где можно сократить время переналадок и смены инструмента
Получить автоматическую фотографию рабочего дня и актуализировать на ее основе нормы времени

Присоединяйтесь к нам, чтобы узнать о последних разработках в области Промышленного Интернета Вещей, онлайн мониторинга производства и практических способах повышения его эффективности.

Регистрация:

https://winnum.timepad.ru/event/1435934/
Подробнее..

Цифровой завод интерактивный цифровой двойник

12.10.2020 20:04:57 | Автор: admin

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

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

Тема цифрового двойника не новая, но с каждым годом она становится все популярнее благодаря новым решениям на рынке Интернета Вещей, которые выводят традиционное производство на новый конкурентоспособный уровень.

Цифровой двойник в нашем понимании трехмерный компьютерный прообраз какого-либо объекта реального мира, имеющий обратную связь от него. В качестве такого объекта может выступать, например, все промышленное предприятие с его производственными линиями, конкретный экземпляр изделия или отдельный технологический процесс. Концепцию цифрового двойника можно разделить на три части:

  • Физический объект;

  • Виртуальный объект;

  • Связь между двумя этими объектами.

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

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

Интерактивный цифровой двойник базируется, в первую очередь, на информации, полученной в автоматизированном режиме от производственного оборудования и/или из информационных систем и статических источников данных (файлы и пр).

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

Коннекторы передают информацию в специальное хранилище, расположенное обычно в локальной сети предприятия и построенное на технологиях NoSQL. Хранилище способно хранить любую информацию в неограниченных объемах для последующего формирования отчетов, создания BI системы, визуализации хода производственных процессов на интерактивном цифровом двойнике, диагностики оборудования, рассылки уведомлений при выходе процесса за установленные рамки и т.д. Ключевым преимуществом такого решения относительно классических СУБД является кратное ускорение обработки данных (обработка миллиардов записей в секунду) и значительно более экономное использование дискового пространства.

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

Использование интерактивного цифрового двойника, работающего на основе Big Data, начинается с его создания и обучения. При создании используются 3D модели, созданные в любых САПР, или геометрия, созданная непосредственно на платформе в 3D Editor. Степень детализации трехмерной сцены определяется автоматизируемыми процессами, при этом создается целый трехмерный мир с широким набором инструментов по работе со светом, текстурами, пользовательскими камерами, механизмом взаимодействия с объектами и т.п. Объекты, размещенные на 3D сцене, в свою очередь, связываются с сигналами и данными, хранимыми в хранилище и для каждого из них описываются сценарии поведения в зависимости от значений сигналов, включая изменение цвета, положения объекта или его компонентов, появление информационных сообщений и т.д.

В результате интерактивный цифровой двойник становится посредником между физическим изделием и важной информацией о нем. Он реализует полноценную обратную связь для производственного оборудования или продукции предприятия, находящихся на этапе эксплуатации, на основе передачи данных из физического в виртуальный мир. В дальнейшем интерактивный цифровой двойник выносится на цеховые и уличные ТВ для контроля достижения заданных показателей и используется на рабочих местах для визуализации технологических процессов и сравнения с результатами имитационного моделирования, выполненного в соответствующем программном обеспечении. Кроме этого, одним из распространенных способов использования цифровых двойников в нашей практике является их применение в диспетчерских и мониторинговых центрах для контроля производственных и вспомогательных процессов на экраны выносится информация по всем производственным переделам, логистике, инженерному оборудованию (кондиционирование и т.п.), микроклимату, техническому состоянию оборудования и др.

Как показывает опыт, предприятия при создании и использовании 3D цифровых двойников преследуют две основных цели:

  • Оперативность принятия управленческих решений;

  • Вовлеченность персонала и повышение мотивации.

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

Сроки ввода в эксплуатацию интерактивных цифровых двойников занимают, в среднем, по нашему опыту, от 3 до 5 недель на цех, состоящий из 70-100 единиц разнообразного оборудования. Таким образом, технологии цифрового двойника дают возможность быстрого старта цифровизации производства с получением конкретных результатов в кратчайшие сроки.

Подробнее..

Концепция независимой инфраструктуры для IIoT системы на основе mesh cети

10.12.2020 22:22:03 | Автор: admin

Добрый день,

Меня зовут Алексей Бабушкин. Я СЕО независимого дизайн хауса электроники Hi-tech nation. Мы занимаемся контрактной разработкой продуктов в области интернета вещей. В свободное от работы время пилим свои решения с использованием беспроводной передачи данных и тестируем продуктовые гипотезы. Так родилась концепция независимой инфраструктуры для IIoT систем на основе mesh сети, которой я хочу с вами поделиться.

Начнём с теории

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

Типовая архитектура таких систем состоит из следующих 3-х уровней:

- оконечные периферийные устройства (датчики, контроллеры, исполнительные устройства и пр.). Этот уровень отвечает за сбор информации с устройств и за приведение её к стандартному виду, фильтрацию и локальное хранение;

- сетевые шлюзы (роутеры, gateway станции и пр.). Они создают инфраструктуру для управления и обмена данными между устройствами посредством проводных или беспроводных протоколов (RS-485, Modbus, CAN, BLE, Wi-Fi, ZigBee, LoRa, и пр.). На этом уровне происходит предварительная обработка информации, выстраивается коммуникация с верхнем уровнем и предоставляется возможность настройки и управления через веб-приложения;

- серверные решения (как правило в виде облачных платформ). Они обеспечивают удаленный доступ к системе и отвечают за более глубокий анализ собранных данных с использованием методов машинного обучения и за хранение больших объемов информации.

Теперь немного глубже

На старте формирования нашей концепции мы решили проанализировать все три уровня и выделить их слабые стороны.

На первом уровне главной головной болью является вопрос нахождения баланса между вычислительными возможностями оконечных устройств, их роли в работе всей системы и энергопотреблением. Современные сложные IIoT системы требуют большей автономности работы (в отрыве от сервера), быстрой реакции на команды (в части исполнительных устройств), дополнительной обработки информации, принятия решений на местах и простоты установки и настройки (желательно по принципу plug and play). При этом никто не отменял запрос на более низкую цену из-за большого количества подключенных устройств.

Слабые стороны второго уровня связаны, в первую очередь, с набирающим обороты переходом на беспроводную передачу данных. Радиоэфир становится все более перегруженным, поскольку большинство нелицензированных беспроводных технологий основаны на частоте 2,4 ГГц. Вскоре это станет одним из самых ограниченных ресурсов. Также стоит отметить неблагоприятную среду, в условиях реально работающих промышленных объектов, в которой приходится функционировать IIoT (большое количество металлоконструкций, высокочастотные помехи от работы производственного оборудования, Wi-Fi сети и пр.). Все эти факторы в совокупности могут привести к снижению качества работы IIoT системы или даже к полной остановке её работы. Чтобы избежать проблем со связью в будущем, современные беспроводные решения должны уметь сосуществовать с другими беспроводными технологиями, поддерживать динамическую смену каналов и работать на других частотах, например, 433 или 868 МГц.

Что касается непосредственно сетевых шлюзов, то сегодня многие производители устанавливают в свое оборудование, например, в те же роутеры или gateway-станции, как можно более высокопроизводительное "железо". Делается это не для улучшения качество сигнала, а чтобы предоставить пользователю, дополнительный функционал управления, со сложными графическими интерфейсами, выводом статистики и т.д. В первую очередь они делают это для того, чтобы оправдать завышенную стоимость новинок. Во вторую с целью улучшения пользовательского опыта при взаимодействии с продуктом. Понятно, что подобные действия продиктованы бизнесом. Возникает вопрос: зачем такое удорожание конечному пользователю. Такой подход противоречит основному принципу концепции промышленного интернета вещей, который гласит: стоимость решения не должна превышать ценность, которую пользователь получает в результате внедрения. Соответственно в интересах пользователей себестоимость отдельных компонентов должна не увеличиваться, а наоборот снижаться, как и стоимость обслуживания.

Слабые стороны третьего уровня связаны в первую очередь с недостатками облачных решений. К таким можно отнести вопросы безопасности. Согласно исследованию Crowd Research, проведенному в 2019 году, около 90% специалистов по кибербезопасности обеспокоены безопасностью используемых облачных сервисов. В некоторых отраслях (например, оборонно-промышленный комплекс) службы безопасности на основе внутренних нормативных актов ограничивают передачу данных за периметр предприятия, что исключает возможность использования облачных решений в принципе. Ещё одним недостатком облачных сервисов считают большую степень зависимости от поставщиков услуг (так называемый vendor lock-in), которые помимо предоставления сервисов и инфраструктуры, потенциально получают неконтролируемое влияние на рынок и клиентов. Так же сюда можно отнести высокую стоимость предоставления подобного рода услуг.

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

Так исторически сложилось

Все периферийные устройства мы, как правило, разрабатываем на основе микроконтроллера ESP32 разработанного компанией Espressif Systems. На наш взгляд, сегодня это один из лучших вариантов с точки зрения цена/качество/производительность на рынке. За вполне приемлемую цену мы получаем два ядра, аппаратные блоки шифрования, интегрированныеWi-FiиBluetooth модули, практически все периферийные интерфейсы и встроенный сопроцессор, на котором, посредством программирования на Assembler, можно весьма эффективно решать различные фоновые задачи в режиме ультранизкого потребления. Пришлось, конечно, практически полностью переписать китайский SDK, но сейчас не об этом.

Mesh

Беспроводную передачу данных мы решили строить на основе разработанной нашими инженерами mesh-cети. Q-mesh это сетевой протокол, построенный поверх протоколов IEEE 802.11n, IEEE 802.11lr и Bluetooth, позволяющий объединять многочисленные устройства, распределенные по большой площади как внутри, так и снаружи помещения в единую беспроводную локальную сеть. Сеть работает на частотах 2.4 ГГц и 868 МГц или 433 МГц. Частота 2.4 ГГц используется как основная, а частота 868 МГц или 433 МГц как дополнительная, для повышения надёжности, а также для маршрутизации между удаленными сегментами сети.

Наше решение отличается от аналогичных беспроводных решений тем, что не требует применения выделенной gateway станции. Любое из оконечных устройств, имеющих гарантированное питание, может полноценно взять на себя её функции. Выбор такого устройства происходит автоматически. Как правило, им становится то, у которого лучше условия обмена информацией. Например, самый низкий уровень помех, наибольшее число доступных устройств и т.д. Если устройство, выступающее в роли ведущего, по каким-либо причинам выходит из строя, то в течение нескольких секунд будет назначено другое. Замена происходит незаметно для пользователя.

Как мы храним данные

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

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

В процессе работы такой системы может генерироваться значительный объем данных. Для их хранения, обработки и маршрутизации в системе предусмотрены сервера, построенные на микро сервисной архитектуре, которая позволяет распределять нагрузки. Это делает систему более устойчивой и надежной. Сервера обеспечивают передачу данных между удаленными ячейками mesh-сети, синхронизируют данные между собой и обновляют данные у пользователей в реальном времени. Устройства и пользователи подключаются к системе через веб-сокеты, что обеспечивает быстрый отклик устройств на команды и быстрое предоставление свежих данных пользователям.

Автономное питание

Все вычисления осуществляются внутри системы распределенным способом, в зависимости от источника питания. Что имеется в виду? Если одному из устройств с автономным питанием необходимо произвести сложные и энергозатратные вычисления, то система перенаправит эту задачу ближайшему устройству, имеющему постоянное сетевое питание. Такой подход обеспечивает приемлемый срок автономной работы для устройств с автономным питанием и ускоряет процесс принятия решения.

Элементы такой системы с автономным питанием рассчитаны на длительную работу без обслуживания. С целью экономии энергии эти устройства большую часть времени проводят в спящем режиме и, соответственно, не имеют постоянной доступности. Для эффективной работы с такими устройствами предусмотрена их виртуализация. Реализуется она следующим образом: на одном из ближайших, в смысле топологии и доступности, устройств, имеющем постоянное питание, создается виртуальная копия реального устройства и вся работа других устройств системы ведется уже с ним. Реальное же устройство по собственной инициативе общается со своим двойником и синхронизирует его состояние с реальным. Таким образом, например, пользователю нет необходимости ждать, когда проснется удаленный датчик, работающий по технологии NB-IoT, чтобы передать ему новые настройки. Он просто настраивает его цифрового двойника, и все настройки будут загружены по назначению во время очередного сеанса связи.

Ледовая арена Химик. Управление освещением реализовано согласно нашей концепцииЛедовая арена Химик. Управление освещением реализовано согласно нашей концепции

Передача данных

В отличие от традиционных сетей, например, Wi-Fi, Q-mesh поддерживает динамический выбор канала, основываясь на информации о загрузке каналов, интенсивности и спектре помех. Это способствует более устойчивой работе системы в условиях загруженного радиоэфира.

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

Скорость передачи данных в диапазоне 2.4 ГГц составляет от 0.25 до 112 Мбит/сек, а время задержки передачи от точки к точке от 5 до 50 миллисекунд. Скорость передачи данных в диапазоне 868 МГц составляет 1 Мбит/сек. Передача данных в диапазоне 433 МГц происходит на скорости 0.25 Мбит/сек.

Безопасность сети обеспечивается применением современных алгоритмов шифрования (AES с длиной ключа 192 или 256 бит) с использованием аппаратной поддержки. Трафик туннелируется между сервером и устройством или между парой устройств и шифруется отдельным ключом.Ключ генерируется из шума радиоэфира.

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

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

Управление и настройка такой системы происходит через веб-интерфейс, который может раздавать любое из устройств системы выполняющего роль сетевого шлюза (gateway станции). Учитывая ограниченные вычислительные возможности периферийных устройств, поддержку веб-интерфейса они отдают в виде скрипта на сторону браузера смартфона, ПК или планшета, которые, располагают куда большей производительностью. Так как это происходит только в момент, когда пользователь взаимодействует с системой, то нагрузки на принимающую сторону не значительны. В свою очередь, для того, чтобы устройство проснулось и передало необходимые данные дальше, ему также не нужны большие вычислительные ресурсы. Поэтому мы можем использовать более дешевые и менее производительные микроконтроллеры, создавая для пользователя дополнительную ценность. В дополнение к этому, решения для браузеров легко интегрировать, так как они работают практически с любой ОС: Linux, Mac, Android и т.п. Таким образом, на том же ESP32 с 256 Кбайт оперативной памяти, мы можем запускать веб-приложения практически, любой сложности и с любой графикой, производить сложные вычисления на стороне веб-приложения с приемлемой скоростью отображения. Это возможно потому, что основная обработка происходит на стороне значительно более производительного оборудования и, поэтому, запас вычислительных ресурсов у нас практически безграничный.

Резюме

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

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

Подробнее..

Быстрый прототип IIoT-решения на Raspberry PI и Yandex IoT

17.12.2020 10:10:32 | Автор: admin

В этой серии статей я расскажу как самостоятельно собрать полнофункциональный прототип промышленного IIoT-шлюза на базе Raspberry PI.

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

Однако в качестве быстрого и дешевого решения на этапе проверки гипотез (в момент когда вам только предстоит определиться какие данные каким способом снимать и как их потом хранить и использовать) такое решение вполне имеет право на существование.

В конце концов, с программной точки зрения, большинство современных промышленных IoT-шлюзов - не что иное, как обычные одноплатные ПК со специфической ОС (чаще всего на базе Linux) и набором предустановленного ПО.

В общем те, кто готов к подобным экспериментам на производстве, либо просто интересуется IIoT и хочет поэкспериментировать с технологиями для собственного развития - вэлкам под кат!


Постановка задачи

Для начала давайте определим, какие функции мы хотим получить на выходе.

Основная суть подобного проекта - анализ данных о производственном процессе.

То есть в первую очередь - сбор телеметрии с различных датчиков, отправка её на сервер (например в облако) для централизованной обработки и накопление истории. Дальнейшая судьба собранной статистики зависит от конкретной решаемой задачи и вашей фантазии.

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

В первой части статьи мы реализуем основные функции:

  • сбор телеметрии с промышленных датчиков по протоколу Modbus;

  • передачу данных в облако;

  • локальный мониторинг в реальном времени;

Во второй - разберемся с тем, как можно накапливать и обрабатывать телеметрию в облаке;

А в третьей - доработаем проект дополнительными фичами:

  • локальным хранилищем телеметрии;

  • устройством для прямого считывания аналогового или цифрового сигнала;

Общая архитектура

Наш небольшой прототип будет иметь все обязательные компоненты IIoT-решения:

  1. Устройство считывания показаний датчиков (можно использовать промышленный контроллер, умные датчики, или собрать свой вариант на базе любого arduino-совместимого контроллера);

  2. IIoT-шлюз, в качестве которого будет выступать Raspberry PI;

  3. Облачный сервис, который принимает данные по протоколу MQTT, сохраняет их в Managed DB и производит дальнейшую обработку - эту часть развернем на платформе Yandex.Cloud

Основные компоненты решенияОсновные компоненты решения

Настраиваем шлюз

Начнем с центрального узла нашего небольшого проекта, то есть малинки.

В качестве ядра системы на стороне шлюза удобно использовать Node-RED. Это простой и удобный инструмент Low-code разработки, который позволяет сократить время создания IoT (и не только) решений. Если по какой-то неведомой причине вы им ещё не пользуетесь - обязательно почитайте про него тут и тут!

Одно из главных преимуществ Node-RED - наличие огромного количества расширений. В том числе, специальных кубиков для работы с modbus, serial и всевозможными базами данных. Там же есть и конструктор легких дашбордов для real-time мониторинга (всё это нам понадобится).

1) Устанавливаем и настраиваем Node-RED:

Вообще Node-RED есть в официальном репозитории Raspberry и его можно поставить просто через apt-get. Но разработчики рекомендуют использовать специально подготовленный ими скрипт, который сразу ставит ещё и npm и настраивает node-RED для запуска в качестве сервиса.

Заходим на малинку и запускаем скрипт:

$ bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered)

Дожидаемся завершения установки (она может занять несколько минут). Когда установка завершена, можно сразу настроить автозапуск при старте ОС:

$ sudo systemctl enable nodered.service

Если хотите сразу озаботиться некоторой безопасностью, можно настроить вход в web-интерфейс по паролю вот по этой инструкции.

Spoiler

Файл settings.js скорее всего будет находиться в папке: /home/pi/.node-red

Теперь всё готово к запуску Nede-RED:

$ node-red-start

Если всё установилось и запустилось успешно, web-интерфейс Node-RED будет доступен в локальной сети по адресу: [IP малинки]:1880

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

Заходим в web-интерфейс, идем в настройки палитры: [Меню в правом верхнем углу] ->[Pallet manager]:

Меню настроек палитрыМеню настроек палитры

Переходим во вкладку Install, находим и устанавливаем следующие пакеты:

node-red-contrib-modbus - пакет для работы по протоколу Modbus

node-red-dashboard - дашборды для мониторинга в реальном времени

postgrestor - простой компонент для выполнения запросов к PostgreSQL

node-red-node-serialport - компонент для работы с serial (этот компонент может быть уже установлен вместе с базовыми)

Вот теперь Node-RED настроен, можно приступать к разработке!

2) Реализуем считывание данных по Modbus:

Modbus - открытый протокол, разработанный ещё в 1979 году для использования в контроллерах MODICON (бренд, между прочим, жив до сих пор и ныне принадлежит Schneider Electric).

Сейчас modbus является де-факто стандартом для промышленных сетей и поддерживается подавляющим большинством контроллеров и умных датчиков. Для интересующихся, вот тут есть хорошая обзорная статья по теме.

Я же не буду подробно останавливаться на его описании. Упомяну только что протокол имеет 3 основные модификации:

  • две для использования с сетевыми интерфейсами RS-232/422/485 (Modbus ASCII и Modbus RTU)

  • и одну для обмена по TCP/IP (Modbus TCP)

Это важно, так как с одной стороны влияет на то, как Raspberry будет физически подключаться к устройствам (в первом случае понадобится переходник COM/RS-USB), а с другой - от этого зависят настройки считывания данных.

И так, подключаем девайс в соответствующее гнездо малины, создаем поток, добавляем в него кубик modbus-read и заходим в его настройки:

Для начала надо создать подключение к Modbus-серверу. Нажимаем Создать подключение и вводим параметры устройства, с которого хотим получать телеметрию:

Для варианта с RS (Serial) необходимо указать адрес порта, к которому подключено устройство, тип протокола (RTU или ASCII) и поддерживаемую скорость обмена (baud rate):

Для TCP указываем IP-адрес устройства (стоит убедиться, что для eth0 на малинке настроена статика в той же подсети и устройство успешно пингуется) и номер порта (обычно используется порт 502):

Теперь настраиваем сам кубик. Тут важны 4 параметра:

FC (код функции) - Для считывания цифровых данных - 02, для аналоговых - 04.

Address - адрес первого регистра для считывания. Адреса регистров можно посмотреть в спецификации устройства, обычно смысловые регистры идут в начале, т.е. Начинаются непосредственно с 0.

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

Poll Rate - частота опроса. Задает частоту, с которой поток будет получать данные от устройства.

В данном примере настроено получение сигналов восьми аналоговых датчиков, начиная с регистра 0000, раз в 5 секунд:

Кубик возвращает в payload массив значений регистров (если регистры указаны правильно - они же показания датчиков). Осталось их немного отформатировать и добавить метку времени. Для этого воспользуемся функцией:

var out_msg = []var values = []var values_formated = []values = msg.payload;var time = (new Date()).toISOString()var n = 0;for(var v in values){    values_formated.push({out:"A"+n.toString(), val:values[v]});    n = n+1;}out_msg.push({payload:{datetime:time, val:values_formated}});return out_msg;

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

Нажимаем кнопку Deploy в правом верхнем углу. Если подключение настроено правильно, под нодой подключения к modbus появится статус active, а во вкладке debug начнут выводиться отформатированные сообщения:

3) Настраиваем мониторинг:

Теперь настроим дашбордик для мониторинга сигналов из web-интерфейса Node-RED. Для этого используем кубик chart.

Функционал chart позволяет отображать несколько сигналов на одном графике, но подаваться они должны по отдельности - каждый в своем сообщении со своим топиком. Поэтому массив, приходящий от устройства по modbus надо разделить на отдельные сигналы. Для этого воспользуемся ещё одной функцией:

var values = [];var values_formated = [];var topic_nm = "";values = msg.payload;var n = 0;for(var v in values) // для каждого сигнала формируем свое сообщение{    topic_nm = "A"+n.toString(); // формируем название сигнала    values_formated.push( // подготовленные сообщения складываем в общий массив:        {topic:topic_nm, // название сигнала - в топик         payload:values[v]}); // значение сигнала - в payload    n = n+1;}return {payload:values_formated};

Функция в Nod-RED может иметь больше одного выхода (количество выходов настраивается в нижней части окна свойств):

Но в данном случае мы можем не знать заранее сколько сигналов (и соответственно выходов) будет. Поэтому положим всё в один массив и вернем его целиком:

...return {payload:values_formated};

А дальше воспользуемся нодой split для разделения сообщений и нодой "change" для их форматирования.

split - разделит массив на отдельные payload-ы, а в change мы положим топик и payload каждого сообщения на его законное место:

На выходе получаем поток отдельных сообщений в правильном формате, готовый для подачи в чарт. В результате получается вот такой flow:

Деплоим его и переходим по адресу: http://[IP малинки]:183/ui

И видим график сигналов в реальном времени:

Вот и всё, сбор и локальное отображение телеметрии настроено!

Настройка брокера MQTT в облаке

Теперь можно приступить к настройке серверной части решения. Для этого воспользуемся облачным сервисом Yandex, называемым Yandex IoT Core.

MQTT - ещё один де факто стандартный протокол для IoT-проектов. Вот тут есть хороший обзор самого протокола, поэтому подробно на нем останавливаться не буду, но немного расскажу как устроен MQTT-брокер от Yandex:

В Yandex IoT Core есть два основных типа объектов - реестры и устройства.

Реестры с одной стороны группируют устройства (в одном реестре может быть одновременно несколько устройств) а с другой - являются как бы второй стороной обмена сообщениями.

Каждый реестр имеет доступ к телеметрии своих устройств и может отправлять им команды. При этом у каждого реестра и каждого устройства есть свой набор топиков. Каждый реестр может читать и отправлять сообщения в свои топики, и в топики любого своего устройства. Аналогично каждое устройство может писать и читать свои топики и топики своего реестра (но не другого устройства, даже если оно "живет" в том же реестре).

Организация топиков Yandex IoT CoreОрганизация топиков Yandex IoT Core

При этом сами топики реестров и устройств никак между собой не связаны - сообщение приходит именно в тот топик, в который отправлено и в других недоступно.

Для дальнейших действий потребуется учетная запись Yandex.Cloud. Если у вас такой еще нет, ее можно достаточно быстро завести. В процессе необходимо ввести данные карты но (в отличии от некоторых других облачных сервисов) деньги с неё списываться не будут пока вы явно не переключитесь на платный аккаунт. После регистрации Yandex предоставляет небольшой грант в 4К рублей, которого на приведенные тут эксперименты хватит с лихвой.

Подключаем и настраиваем сервис:

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

Сгенерировать пару сертификатов можно при помощи утилиты OpenSSL вот такой командой:

$ openssl req -x509 \--newkey rsa:4096 \--keyout key_reg.pem \ # имя сертификата закрытого ключа--out crt_reg.pem \   # имя сертификата открытого ключа--nodes \--days 365 \--subj '/CN=localhost'

Теперь заходим в консоль Yandex.Cloud, выбираем IoT Core и создаем новый реестр:

Открытую часть ключа, сгенерированного на предыдущем шаге (crt_reg.pem), загружаем в настройки реестра. Этот сертификаты будут использоваться для считывания телеметрии из брокера внешними сервисами и отправки команд устройствам:

Нажимаем "Создать" и попадаем в настройки свежесозданного реестра. Теперь надо зарегистрировать в нем малинку в качестве устройства.

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

Заходим в Устройства и создаем новое:

Аналогично с созданием реестра загружаем сертификат из пары, созданной на малинке и нажимаем "Добавить".

На этом настройка брокера завершена, всё готово для приема сообщений.

ID устройств и реестров можно посмотреть на вкладке "Обзор". Они нужны для задания адресов топиков:

Топик устройства: $devices/<ID устройства>/events

Топик реестра: $registries/<ID реестра>/events

Также у каждого устройства и реестра есть перманентный топик. Основное отличие перманентных топиков состоит в том, что в них всегда сохраняется последнее сообщение. То есть при подключении консьюмер получит последнее отправленное в него сообщение, даже если не был в сети в момент его отправки. Адреса перманентных топиков похожи на обычные, но заканчиваются на state а не events:

Перманентный топик устройства: $devices/<ID устройства>/state

Перманентный топик реестра: $registries/<ID реестра>/state

Подробнее о топиках Yandex IoT Core можно почитать вот тут.

Настройка отправки сообщений по MQTT

Возвращаемся к проекту Node-RED.

Кубик для отправки сообщений по MQTT в Node-RED уже предустановлен. Добавляем его в поток после функции "add_time_stamp"и настраиваем:

Указываем адрес топика, в который собираемся писать, например топик реестра. Уровень сервиса (QoS) ставим 0 - для наших задач отслеживание доставки не требуется:

Заходим в настройки сервера. Тут настраиваем подключение к брокеру:

Сервер: mqtt.cloud.yandex.net

Порт: 8883

Ставим галочку Enable secure (SSL/TLS) connection и заходим в настройки TLS:

Указываем пути до файлов ключей, сгенерированных на этапе настройки IoT Core:

Сохраняем настройки и деплоим проект. В итоге flow выглядит вот так:

А телеметрия успешно отправляется в облако!

Проверить это можно с помощью утилиты командной строки yc, подписавшись на указанный в настройках топик:

$ yc iot mqtt subscribe \--cert registry-cert.pem \ # файл сертификата реестра--key registry-key.pem \  # файл ключа реестра--topic '$devices/<ID устройства>/events' \--qos 1

Либо собрав отдельный поток Nod-RED с чтением из MQTT с помощью нода "mqtt in" (интереснее, если он будет работать на другом устройстве, но и та же самая малинка тоже подойдет):

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

Результат

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

А в качестве бонуса уже есть небольшой локальный монитор сигналов, доступный в локальной сети малинки.

В следующей части начнем сохранять получаемую телеметрию и посмотрим что ещё с ней можно делать в облаке.

Пример потоков Node-RED, описываемых в статье, можно скачать тут.

Подробнее..

Промышленный интернет вещей в ПЛК Simatic S7-1x00 на примере протокола MQTT

13.01.2021 20:16:14 | Автор: admin

Обнаружил в базе знаний Siemens (SIOS) интересный пример использования контроллеров линейки S7-1200 и S7-1500 в качестве клиента протокола MQTT

Ссылка на первоисточник:https://support.industry.siemens.com/cs/document/109748872/fb-lmqtt_client-for-simatic-s7-cpu?dti=0&pnid=13685&lc=en-RU

По ссылке можно найти саму библиотеку с функциональным блоком MQTT_Client (с открытыми исходниками, кстати) и пояснительную записку к примеру. Документация сама по себе вполне исчерпывающая, знающие английский язык могут смело идти по ссылке и не читать эту заметку, подарив тем самым себе несколько увлекательных часов инженерных изысканий. А для остальных, менее опытных и/или более ленивых, я кратко расскажу основное и продемонстрирую свой пример работы клиента, творчески переработанный под более-менее реальное применение.

Кратко о терминах.

MQTT message queuing telemetry transport. Протокол телеметрии для передачи сообщений. Затрудняюсь перевести название корректно на русский.

Message сообщение. Непосредственно, сами передаваемые данные. Сообщение состоит из нескольких частей:

-Topic, тема сообщения. Символьная строка, размер которой в исходном примере ограничен 200 символами. Клиенты для получения сообщений должны предварительно подписаться на конкретную тему, т.е. topic

-QoS, quality of service. Дополнительный признак, указывающий ждать ли подтверждения получения сообщения или нет.

-Message text, текст сообщения. Текстовая строка из 500 символов.

Протокол построен на модели подписчик/издатель, общая логика которого слегка отличается от обычной клиент-серверной модели, привычной в промышленных протоколах.

При клиент-серверном подходе один или несколько участников исполняет роль сервера, т.е. узла в сети, который отвечает на запросы клиента. Сервер сам по себе не инициирует связь и не проявляет активность, он лишь отдает запрошенные данные и принимает уставки и команды. При этом адресация данных, тип данных и прочее закладываюся и структурируются изначально на этапе разработки серверной части. Клиент тоже должен знать эту карту адресов Modbus. Изменение набора данных требует перенастройки и клиента, и сервера.

В модели подписчик-издатель, применяемой в протоколе MQTT, совершенно необязательно заранее формировать, конфигурировать или программировать набор данных (топики). Вообще никак данные конфигурировать в серверной части не требуется. Топики создаются автоматически от издателя. Подписчики, в свою очередь, подписываются на топики, причем можно подписаться даже на тот топик, в который не написал ни разу ни один издатель. Как только в этот топик будет отправлено хотя бы одно сообщение, все подписчики его получат.

Итак, роли в протоколе MQTT.

Издатель он же publisher. Узел, который отправляет сообщения (текстовую информацию) на определенную тему (topic).

Подписчик он же subscriber. Узел, который подписывается на определенные темы. Новые сообщения в заявленных темах подписчик получает автоматически.

Роли издателя и подписчика могут совмещаться на одном и том же узле сети. Это роли клиента.

Роль сервера в протоколе MQTT выполняет узел, который называется брокер. Именно брокер запоминает, какие клиенты на какие темы подписались. Именно брокер принимает сообщения от издателей на определенную тему и автоматически раздает их соответствующим подписчикам.

К брокеру может быть подключено несколько и подписчиков, и издателей. Максимальное количество мне неизвестно. Предположу, что все ограничено лишь мощностью железа, на которой работает брокер и настройками стека TCP/IP операционной системы.

В первоисточнике (см. ссылке в начале) идет архив с библиотекой LMQTT_Client. Архив необходимо распаковать, а библиотеку подключить к уже созданному проекту Step 7. Подключение библиотеки выполняется через пункт меню Options Global Libraries Open library. В результате Вы увидите следующее:

Библиотека подключена к проекту

Библиотека содержит две версии функционального блока клиента протокола MQTT для контроллеров S7-1200 и S7-1500. В моем примере будет использоваться младший ПЛК, S7-1214. Реализации отличаются тем, что старшие S7-1500 позволяют адресовать брокер по доменному имени, а S7-1200 только по ip-адресу. Необходимо перетащить блок LMQTT_Client из библитеки во вкладку Program Files контроллера. Типы данных скопируются в проект автоматически. Далее я отхожу от примера и осуществляю вызов ФБ MQTT_Client из своего собственного функционального блока под названием MQTTExchange:

В принципе, если выполнить все настройки правильно и играть запросами через поля экземпляра функционального блока, то можно проверить работоспособность прямо сейчас. Но вначале пройдемся по основным входным и выходным пинам этого ФБ.

enable при положительном фронте этой дискретной переменной устанавливается соединение с брокером MQTT, при отрицательном фронте соединение разрывается. Т.е. для работы необходимо держать этот вход в состоянии TRUE

publishData структура для отправки (публикации) сообщения. Состоит из бита запроса на публикацию (для отправки сообщения бит необходимо взвести в истину и снять в ложь после появления флага done или error), топика и текста сообщения, а так же признака качестве QoS

subscribeToTopic структура, которая содержит флаг запроса на подписку, флаг запроса на отписку (да, можно в любой момент отписаться от топика), непосредственно имя топика и признак качества

На начальном этапе нам важны следующие две структуры, которые необходимо для установления связи с брокером: это tcpConnParam и mqttParam. Эти структуры я заполняю единожды в OB100 при запуске контроллера. Необходимый минимум для работы протокола описывается ниже.

Аппаратный идентификатор интерфейса контроллера

Идентификатор интерфейса ( сетевой карты ) ПЛК. В моем случае у меня всего один интерфейс. Его ID я уже помню наизусть, поэтому пишу 64. Подсмотреть Hardware ID можно в аппаратной конфигурации ПЛК.

Следующее идентификатор соединения. Именно логического соединения по протоколу TCP/IP, connection ID. Должно иметь значение от 1 до 4096, назначается программистом, у каждого логического соединения должен быть свой уникальный айди, иначе связь не будет функционировать. В моем случае у меня присутствует одно-единственное соединения, и я смело назначаю ему 1

Следующее назначение IP-адрес хоста, на котором функционирует брокер.

В данном примере брокер работает на моем домашнем рабочем компьютере с публичным статическим ip-адресом. Из соображений информационной безопасности два байта ip-адреса стерты. В качестве брокера выступает mosquitto под Windows. Разные способы установки брокера хорошо описаны по ссылке:

http://www.steves-internet-guide.com/install-mosquitto-broker/#manual

Там же можно скачать уже настроенный в базе брокер, его я и использую:

http://www.steves-internet-guide.com/install-mosquitto-broker/#

Никаких особенных настроек не применяется. Сертификаты шифрования не используются (об этом чуть позже). На удаленном компьютере просто запущена программа mosquitto.exe, а на удаленном маршрутизаторе сделан проброс порта 1883 (порт для стандартных коммуникаций MQTT) в локальную сеть.

Я умышленно использую брокер, недоступный локально. Одно дело поднять все в рамках локальной сети в горячо любимом диапазоне адресов 192.168.0.х или 192.168.1.х, а совсем другое убедиться в возможности работы системы, как ей и положено, по удаленным каналам связи. Ведь сам контроллер находится сейчас в лаборатории, он подключен к местному маршрутизатору от провайдера, и у контроллера есть только локальный ip-адрес, а не публичный и, тем более, не публичный статический ip.

Кстати, помним, что для организации выхода в интернет контроллеру в данном случае необходимо явно указывать шлюз в настройках его ip-адреса.

Обязательно надо прописать router address, иначе ПЛК не сможет подключиться к внешнем ресурсам глобальной сети

Следующая настройка порт, по которому удаленный брокер слушает соединения. По непонятной причине в примере этот порт указан, как 1884, в то время как стандартным портом для нешифрованных коммуникаций является 1883. Задаю его явно:

Последняя настройка символьное имя клиента. Должно быть уникально в системе. В качестве имени у меня задано S7-1214.

Гораздо разумнее было бы сделать имя клиента уникальным автоматически. Например, сделать его составным из слова SIMATIC и уникального серийного номера центрального процессора (прочитав его соответствующей системной функцией и переведя в строковое представление). С остальными настройками рекомендую ознакомиться в документации. Остановлюсь на двух из них, весьма интересных.

Первое. Last will. Буквально на русском языке завещание (сетевые граждане такие юмористы!). Если выполнить эту настройку, то клиент при подключении к брокеру передает и ее. В случае отвала связи клиента, брокер автоматически разошлет это завещание всем участникам обмена. Завещание является таким же сообщением, у него так же задается топик и текст.

Второе. Возможность шифрования трафика. Для общего тестирования можно обойтись и без него. В продакшене ни в коем случае.

Выставив поле activateSecureConn в настройках необходимо провести еще ряд манипуляций активировать глобальные настройки безопасности проекта, импортировать сертификат брокера, создать сертификат контроллера и так далее. Вопросы зашифрованного соединения я уже поднимал в заметке про OPC UA коммуникации. В целом же действия тут больше напоминают настройки безопасного соединения для Open User Communications (SecOUC). В настоящем примере вопросами безопасности передаваемых данных я пренебрегаю. Подробности настройки описаны все в той же документации.

Закончив настройки, необходимо убедиться, что все работает, как надо. Для начала, конечно же, просто подпимем соединение с удаленным брокером. Для этого достаточно подать истину на вход enable функционального блока LMQTT_Client:

Как видно, при поданном enable выходные биты tcpEstablished и mqttEstablished содержат истину, это означает, что связь установлена успешно. В процессе испытаний я обнаружил интересное поведение блока, а именно при подачи истины на вход enable подтверждение связи появлялось на одну-две секунды и пропадало. Связь устанавливалась только со второй попытки. Кроме того, при физическом обрыве связи этот ФБ просто информирует об отсутсвии соединения, и не предпринимает попыток автоматически пересоединиться. В целях автоматического соединения и пересоединения добавлен следующий нетворк:

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

В данном примере предполагается, что контроллер не только отправляет какую-либо информацию брокеру, но и подписан на топик. Точнее, даже на два топика, чтобы пример был интереснее. В качестве принимаемой информации может быть, что угодно команды, уставки, запросы архивной информации или состояния оборудования. В принципе, все ограничивается исключительно объёмом свободной рабочей памяти. Вполне логичным будет подписаться на нужные топики сразу после установления связи. И для этого потребуется поиграть с полями структуры subscribeToTopic, которую лучше все воспринимать, как управляющую структуру.

По переднему фронту (то есть, по единомоментному факту) установления соединения я поднимаю локальную битовую переменную #SubscriveToTopics и выставляю номер шага процедуры подписки в 1. Номер шага используется в связи с тем, что все операции у нас ассинхронные, и их надо выполнять последовательно, одну за другой, а не все сразу (все сразу не выполнятся).

Первый шаг подписки подписаться на топик с названием global. В случае успешного выполнения операции подписки переходим на следующий шаг. Иначе выполняем процедуру переподключения (хотя, реакция может быть иной, на усмотрение разработчика)

Смотрим. Если выставлен бит выполняем подписку и шаг = 1, то

если не выставлен бит управляющей структуры подписатся, то задать имя интересующего топика (global) и поднять бит управляющей структуры подписаться

если бит управляющей структуры подписаться поднят, то смотреть на биты выполнения задания done и error. При появлении бита done сбросить бит управляющей структуры подписаться и перейти на шаг 2. В случае возникнования ошибки выполнить переподключение к брокеру.

Шаг 2. На этом шаге не нужно делать вообще ничего. Этот шаг требуется для того, чтобы ФБ клиента вызвался хотя бы один раз со сброшенным битом управляющей структуры подписаться. Для этого есть и более изящные решения, но я обошелся простейшим таймером.

После 100мс ожидания просто идем на следующий шаг, к подписке на второй топик (шаг 3).

Шаг 3 аналогичен шагу 1, за исключением имени топика. После успешного завершения шага 3 сбрасывается локальный бит выполнить подписку (#SubscriveToTopics) и обнуляются шаги подпрограммы подписки.

После выполнения подписки можно смело проверять работу клиента. Для этого я вызываю программуmosquitto_pub.exe:

mosquitto_pub.exe -h myhost.mydomain.ru -t global -m kill all humans

, где

myhost.mydomain.ru доменное имя удаленного брокера

global топик global, на который только что подписался клиент

kill all humans текст сообщения в топике global

После отправки сообщения смотрим выходную структуру subscriptionsMessage:

Как видно, в топике global прошло сообщение kill all humans

Флаг newMessageReceived нам еще пригодится в дальнейшем. Этот флаг выставляется сразу по получению нового сообщения и действителен в течении одного цикла сканирования. По нему очень удобно будет обрабатывать полученные команды, уставки или запросы.

Вторая задача контроллера в этом примере отправлять информацию о технологическом процессе через равные промежутки времени. Например, каждые сутки. Или каждые два часа. Ну, или каждые 10 секунд, потому что в учебном примере не очень хочется терять время на пустое ожидание. Поэтому каждые 10 секунд я поднимаю локальный флаг отправить данные и выставлю шаг подпрограммы отправки в 1:

Нетворк отправки данных для разнообразия написан на SCL, а не нарисован в LAD. Право же, оперировать строками в графических языках не самое удобное дело.

Всего отправляется значение 4 переменных, три из которых заданы статично в блоке данных, а одна постоянно увеличивается на небольшую дельту. На первом шаге подпрограммы задается имя топика, это имя personal0. А так же формируется строка сообщения. Поскольку оперируем мы именно символьными данными, приходится выполнять преобразование типа REAL_TO_WSTRING и конкатенацию строк. Для контроллеров, тем более, начального уровня, это не самое лучшее занятие очень быстро расходуется память и неплохо так съедаются вычислительные ресурсы. Длина передаваемого сообщения 500 символов, есть куда развернуться. Можно, так же, добавить еще и метку времени. Можно формировать буфер сообщений, тем самым аккумулируя хотя бы минимум данных на период отсутствия связи. В общем, тут можно делать, что угодно (но лучше делать, что написано в ТЗ).

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

Запустим клиент MQTT и посмотрим, что приходит в топике personal0 (именно в этот топик ПЛК и отправляет данные):

Ну, и напоследок. Демонстрация возможностей удаленного управления. Если в топике personal0 пришло сообщение exterminate, дискретный выход Q0.0 устанавливается в значение истина.

Команда издателя:

mosquitto_pub.exe -h host.domain.ru -t personal0 -m exterminate

Нетворк программы контроллера:

Проверка пришедшего сообщения выполняется только по факту прихода самого сообщения (бит newMessageReceived), что вполне логично. А далее необходимо только проверять имя топика и текст сообщения. Любые дальнейшие действия программируются, как угодно.

На этом технический пример заканчивается, и хочется немного порассуждать о возможностях применения. Они есть, и, кажется, весьма широкие. Фактически, это можно применять в любых распределенных недорогих системах, где присутствуют малые объемы информации и, в силу этого, использование специализированных телемеханических протоколов нецелесообразно в виду их высокой стоимости. Ну, например, в ЖКХ. Если маленький ПЛК смотрит на расход энергоресурсов (общедомовых, а, может, даже и поквартирных) и раз в сутки отправляет сводку в диспетчерский центр. Или смотрит на состояние общедомового оборудования, шлет параметры раз в час, но при аварии моментально. Достаточно лишь снабдить ПЛК GSM-модемом, и фактически, ничего больше не требуется, кроме простого компьютера с фиксированным ip-адресом. Рассуждая дальше, можно и без физического ПК обойтись, засунув его в облако. Главное, не забыть должным образом настроить шифрование трафика. В этом случае имеет смысл данные потребления энергоресурсов из клиента сразу складывать в базу данных, но это уже требует высокоуровневого программирования

Или, как вариант, та же распределенная система, но не только сбор данных, но и взаимодействие M2M (контроллер-контроллер). Тут точно так же, достаточно минимального канала связи и доступного брокера.

Можно даже и на скаду информацию выводить, не особо заморачиваясь с программированием серверной (брокерской) части. Ведь ничто не мешает настроить все полевые контроллеры на отправку сообщений брокеру, взять еще один контроллер, читать эти сообщения и их результат раскладывать по блокам данных, и уже из них выводить показания на тот же WinCC Advanced.

Дальнейшие исследование показали отличное применение mqtt совместно со средой Node-RED. На Node-RED была "нарисована" программа, принимающая эти данные от брокера, разбирающая полученную строку и записывающая всю информацию (метку времени, значение) в базу данных MariaDB. Она же, программа на Node-RED позволила вытаскивать информацию за указанный временной промежуток, показывать ее в виде таблицы, графика и делать выгрузку в виде .csv файла.

Подробнее..

Быстрый прототип IIoT-решения на Raspberry PI и Yandex IoT. Часть вторая

15.02.2021 10:17:19 | Автор: admin

Это вторая часть из цикла статей про прототипирование IIoT-решения на Raspberry PI и Yandex IoT.

В первой части мы реализовали основные функции на Raspberry PI:

  • сбор телеметрии с промышленных датчиков по протоколу Modbus;

  • их передачу в облако;

  • локальный мониторинг процесса в реальном времени.

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

Настало время это исправить - разберемся с тем, как можно накапливать и обрабатывать переданную телеметрию в Яндекс Облаке.


Требуемый функционал

В рамках нашего решения облако должно решать следующие основные задачи:

  • принимать телеметрию устройства;

  • накапливать телеметрию в хранилище;

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

Посмотрим, какие инструменты для решения этих задач есть в Яндекс Облаке.

Доступные инструменты

Сбор и обработка телеметрии

Yandex IoT Core

В первой части мы уже познакомились с Yandex IoT Core и достаточно подробно разобрали его функционал. Если кратко, это MQTT-брокер от Яндекса, с помощью которого осуществляется обмен сообщениями между реестрами и устройствами.

Его мы и используем, чтобы отправлять телеметрию устройства в облако (как именно? велком в первую часть)

Yandex Cloud Functions

По умолчанию, с полученными по MQTT сообщениями в облаке ничего не происходит и информацию о них можно увидеть только в логах реестра или устройства. Для того, чтобы обработать присланную телеметрию нужно использовать сервис Yandex Cloud Functions.

Этот сервис позволяет разворачивать serverless-функции (на данный момент на Python, Node.js, Bash, Go и PHP), а также обладает механизмом триггеров - запуска развернутых функций по какому-либо условию (таймеру, событию).

Например, можно создать функцию-обработчик сообщения телеметрии и триггер, привязанный к топику устройства или реестра IoT Core, который будет отправлять пришедшие в топик сообщения на обработку этой функции. Таким образом, способы обработки сообщений ограничивается только возможностями выбранного языка программирования, квотами и лимитами сервиса.

Yandex Message Queue

Yandex Message Queue - сервис для обмена сообщениями между приложениями. В рамках этого сервиса можно реализовать механизм очередей, в которые одни приложения отправляют сообщения, а другие - забирают.

Этот механизм будет полезен, если в качестве хранилища использовать ClickHouse или схожие аналитические колоночные СУБД, плохо переносящие единичные вставки - в очереди можно накопить пачку сообщений и отправить их на вставку одним большим пакетом.

Хранение телеметрии

Для хранения данных Яндекс Облако предоставляет большое количество Managed Services для разных СУБД.

Managed Service любой СУБД, позволяет быстро развернуть готовый к работе кластер с необходимым хранилищем. Также в рамках облака можно быстро масштабировать ресурсы кластера в случае увеличения нагрузки.

Доступные на текущий момент СУБД:

  • PostgreSQL

  • ClickHouse

  • MongoDB

  • MySQL

  • Redis

  • SQL Server

По умолчанию, доступ к кластеру возможен только сервисами, развернутыми в рамках той же облачной сети (Yandex Virtual Private Cloud). Но при создании кластера можно включить публичный доступ, и тогда ресурс будет доступен из любой точки интернета.

Использование накопленной телеметрии

Yandex DataLens

Это сервис визуализации данных и анализа данных. Позволяет достаточно быстро создавать дашборды на основе данных из разнообразных источников.

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

Yandex DataSphere

Сервис для ML-разработки, предоставляющий все необходимые инструменты и динамически масштабируемые ресурсы для полного цикла разработки машинного обучения.

Работа ведется в ноутбуках JupyterLab, есть возможность выбора ресурсов, на которых будет выполняться каждая отдельная ячейка (количество ядер, GPU).

Дополнительные инструменты

Yandex Monitoring

Сервис позволяет собирать, хранить и отображать метрики облачных ресурсов, а также настраивать алерты и присылать по ним уведомления. В отличии от DataLens, умеет обновлять графики онлайн и подходит для мониторинга в реальном времени!

Настройка сохранения телеметрии

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

Для этого нам нужно развернуть и настроить 4 элемента:

  • IoT Core: создать реестр, устройство, наладить передачу сообщений по MQTT (сделано в первой части);

  • Managed Service for PostgreSQL - развернуть кластер, создать таблицу для хранения телеметрии;

  • Cloud Functions - написать функцию-обработчик сообщения с телеметрией: функция должна записывать payload сообщения в БД;

  • Cloud Functions - настроить триггер IoT Core, который будет запускать функцию-обработчик при появлении нового сообщения в топике реестра.

Частично здесь мы будем опираться на пример подобного решения из документации Яндекс Облака.

Настройка PostgreSQL

Для начала подключаем и настраиваем кластер Postgres:

Сервис Managed Service for PostgreSQL в консоли.Сервис Managed Service for PostgreSQL в консоли.

Нам подойдет самая минимальная конфигурация - b2.nano (если впоследствии проект перерастет во что-то большее, ее легко можно будет расширить):

Конфигурация кластера.Конфигурация кластера.

Заводим пользователя и базу данных:

Настройки БД.Настройки БД.

В разделе хосты нужно будет разрешить публичный доступ к ресурсу:

Настройка публичного доступа к БД.Настройка публичного доступа к БД.

Это нужно для того, чтобы база была доступна для обращения из Cloud Functions.

Создадим кластер. Теперь придется подождать некоторое время пока кластер развернется и его статус поменяется с Creating на Alive.

Создание кластера.Создание кластера.

После того, как кластер развернулся, заходим в него и создаем таблицу:

Вход в SQL клиент облакаВход в SQL клиент облака

Пока будем просто складывать весь payload в одну колонку. В последствии его можно будет распарсить на отдельные колонки по каждому значению, или классический timeseries:

CREATE TABLE telemetry_hist( telemetry_timestamp timestamp,  device_nm varchar(200),  payload varchar(2000));

Такой подход удобен ещё и тем, что если в процессе доработки проекта поменяется структура payload-а, сохранение в БД не сломается и телеметрия не будет теряться.

Создание функции-обработчика

Функция будет получать сообщения из MQTT-брокера и записывать данные в таблицу, созданную ранее.

В каталоге в консоли выбираем Cloud Functions:

Сервис Cloud Functions в консоли.Сервис Cloud Functions в консоли.

Создаем функцию с названием iot-core-handler и каким-нибудь говорящим описанием.

В открывшемся редакторе выбираем среду выполнения. Мы будем использовать Python 3.7 (preview).

Выбор среды выполнения при создании YCF.Выбор среды выполнения при создании YCF.

Теперь нам доступен редактор кода. Здесь мы можем написать требуемую функцию, создать ее версию, после чего она сразу развернется и станет доступной для выполнения.

Редактор кода YCF.Редактор кода YCF.

Помимо редактора кода, можно разворачивать код из архивов в Object Storage или загруженных напрямую.

Мы будем использовать код, предоставленный в документации Яндекс Облака (гитхаб), немного поправив его под наши нужды.

Правки касаются формата таблицы и payload сообщений:

  • Функция makeInsertStatement:

    Поменяем формат инсерта согласно формату нашей таблицы, уберем разбор пэйлоада на отдельные поля, а также изменим входную переменную event_id на event_ts.

def makeInsertStatement(event_ts, payload_json, table_name):    msg = json.loads(payload_json)    msg_str = json.dumps(msg)    logger.info(msg_str)    insert=  f"""INSERT INTO {table_name} (telemetry_timestamp , device_nm , payload) VALUES ('{event_ts}','iot_test_device', '{msg_str}')"""    return insert
  • Функция makeCreateTableStatement:

    Изменим выражение в соответсвтии с форматом таблицы.

def makeCreateTableStatement(table_name):    statement = f"""CREATE TABLE {table_name} (    ( telemetry_timestamp timestamp,      device_nm varchar(200),      payload varchar(2000)    );    """    return statement
  • Функция msgHandler:

    • Изменим переменную event_id на event_ts (96 строка) и будем формировать ее следующим образом:

      event_ts = json_msg["event_metadata"]["created_at"]
      
    • Изменим значение переменной table_name на название нашей таблицы (98 строка):

      table_name = telemetry_hist
      
    • В функцию makeInsertStatement в качестве первого аргумента отправляем не event_id, а event_ts (99 строка):

      sql = makeInsertStatement(event_ts, event_payload, table_name)
      

Код с уже внесенными правками можно найти в этом гисте. Вставим его в файл index.py.

Обратите внимание, если вы использовали другое название таблицы для сохранения телеметрии, необходимо указать его в качестве значения переменной table_name на 79 строке.

Теперь, перед созданием версии функции, в форме под редактором необходимо заполнить параметры развертывания:

  • Точка входа: укажем index.msgHandler - это имя функции в файле index.py, которая будет вызываться в качестве обработчика. Указывается в формате <имя файла с функцией>.<имя обработчика>

  • Таймаут, с: 10 секунд -максимальное время выполнения функции. Облачная функция может выполняться не более 10 минут.

  • Память: 128 МБ - объем необходимой для функции памяти

  • Сервисный аккаунт - укажем (или создадим, если его еще нет) сервисный аккаунт с ролями serverless.functions.invoker и editor

  • Переменные окружения - обратите внимание, разработанная функция использует 6 переменных окружения, которые необходимо заполнить в соответствующих полях. Нужно указать следующее:

    • VERBOSE_LOG параметр, отвечающий за вывод подробной информации о выполнении функции. Введем значение True.

    • DB_HOSTNAME имя хоста БД PostgreSQL для подключения.

    • DB_PORT порт для подключения.

    • DB_NAME имя базы данных для подключения.

    • DB_USER имя пользователя для подключения.

    • DB_PASSWORD пароль, который был введен при создании кластера

Все данные для подключения (кроме пароля) можно найти в обзоре развернутого Managed Service for PostgreSQL.

Информация для подключения к БДИнформация для подключения к БД

В итоге мы получаем такое заполнение полей:

Настройки YCF.Настройки YCF.

Создадим версию функции (кнопка Создать версию).

Настройка триггера IoT Core

Вернемся в раздел Cloud Functions и выберем подраздел Триггеры.

Подраздел "Триггеры" YCF.Подраздел "Триггеры" YCF.

Создадим триггер (кнопка Создать триггер).

  • В блоке Базовые параметры:

    • В поле Имя введем имя триггера.

    • В поле Тип выберем Yandex IoT Core. Так мы укажем сервису, что будем работать с обработкой событий IoT Core. Кроме этого источника, для решения других задач можно обрабатывать сообщения Message Queue, события Object Storage, Container Registry, логов Cloud Logs, а также запускать функцию по таймеру.

  • В блоке Настройки сообщений Yandex IoT Core:

    • В поле Реестр введем iot_test-reg - реестр к которому привязано наше устройствою

    • В поле Устройство выберем Любое устройство (т.к. мы отправляем сообщения в топик реестра)

    • В поле Топик укажем топик, в который устройство отправляет данные:

      • $registries/<ID реестра>/events

Теперь триггер будет срабатывать при появлении новых данных в указанном топике.

  • В блоке Настройки функции:

    • Выберем функцию для обработки данных, созданную ранее (iot-core-handler).

    • В поле Тег версии укажем $latest - тогда триггер будет запускать последнюю развернутую .

    • В поле Сервисный аккаунт укажем созданный ранее сервисный аккаунт.

    • Остальные поля оставим пустыми.

Настройки триггера YCF.Настройки триггера YCF.

Создадим триггер с заданными настройками.

Проверка работоспособности

Всё готово!

Теперь (если всё сделано правильно) каждое сообщение, отправляемое устройством, будет через созданный триггер инициировать вызов функции. Которая, в свою очередь, положит отправленный payload в таблицу на Postgres.

Проверим логи выполнения функции (Cloud Functions -> Функции -> iot-core-handler -> Логи).

Логи выполнения функции iot-core-handler.Логи выполнения функции iot-core-handler.

Здесь отображаются сообщения, выводимые функцией в процессе работы, в том числе, сообщения об ошибках. Если сообщений об ошибках нет (а есть информационные сообщения, начинающиеся с [INFO]) - функция работает корректно.

Посмотрим теперь заполнение таблицы telemetry_hist в нашей БД (Managed Services for PostgresSQL -> telemetry_store -> SQL). Вводим имя пользователя и пароль и попадаем в редактор SQL.

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

SELECT * FROM telemetry_hist

И видим всю историю отправленных пэйлоадов:

Заполнение таблицы telemetry_hist.Заполнение таблицы telemetry_hist.

То есть всё работает: теперь телеметрия попадает в облако, накапливается в развернутой БД и доступна для дальнейшего анализа в любое удобное время из любой точки планеты!

PS. Если по каким-то причинам таблица остается пустой, можно проверить следующие моменты:

Отправило ли устройство хотя бы одно сообщение с момента деплоя функции и триггера?

  • Если нет - просто ждем пока это произойдет)

  • Если отправляло - смотрим логи выполнения функции.

    • Если логи пустые - стоит проверить триггер (в частности правильно ли указан топик и функция).

    • Если в логах ошибки - разбираемся с кодом.

    • Если функция отрабатывает и ошибок нет - проверяем настройки подключения к БД и имя таблицы.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru