Leaving on the Edge: гибридные IoT-решения

Опубликовано в номере:
«Интернет вещей» — это сейчас модно. Ему посвящают множество докладов и презентаций. Маркетологи прогнозируют существенный рост внедрения IoT-решений и значительную выгоду для компаний-новаторов. Но не все так просто. Успешных индустриальных IoT-проектов в наших реалиях пока совсем немного, и это в значительной степени связано с ограничениями, которые заложены в саму концепцию «Интернета вещей». Присутствие в ней облака — как компонента, в котором выполняется большая часть логики IoT-системы, — возможно далеко не всегда. Аргументы против использования облака, а значит, и классического IoT, в каждом конкретном сценарии могут быть разными, но большинство из них так или иначе связаны с двумя категориями рисков: доступностью облака и безопасностью.

Концепция граничных вычислений в IoT

Рассмотрим две крайности типовой архитектуры IoT-решения.

Если мы переносим всю логику системы на сторону объекта управления или мониторинга, то фактически получаем «классическую» АСУ или SCADA. При этом лишаясь преимуществ облачной архитектуры: неограниченной вычислительной мощности, платы только за потребленные ресурсы, простоты создания распределенных решений и большого числа готовых сервисов, которые позволяют намного быстрее получить результат в виде работающего решения.

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

Логичным компромиссом видится промежуточный подход, который бы позволял использовать преимущества облака и был лишен его основных недостатков. Методы, которые дают возможность оптимизировать облачную архитектуру путем переноса части алгоритмов обработки данных ближе к их источнику, принято называть Edge computing. Автору неизвестен устоявшийся русский перевод этого термина. Длинный вариант — «предварительная обработка на стороне поставщика данных» — лучше отражает суть концепции, но, видимо, приживется более краткий термин «граничные вычисления», который мы и будем использовать в статье.

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

Возможен ли такой компромисс в реальности? Футурологи увлеченно спорят о том, кто победит — облако и граничные вычисления или полный отказ от них. Если вопрос, что является более безопасным — облако или сервер, которым управляют внутренние специалисты, — является дискуссионным, то опровергать риск доступности (туда же отнесем и задержки в процессе передачи данных) — это все равно, что спорить с законами физики. Как можно реализовать систему, которая должна управлять процессами, протекающими практически в реальном времени, если ее алгоритмы выполняются в центре обработки данных, расположенном за тысячи километров от нее? И наконец, зачастую объект мониторинга и управления работает в местах с плохим, дорогостоящим и нестабильным покрытием каналами передачи данных. Возможность отправить в облако только данные о статусе всего процесса и агрегированные показатели эффективности позволяет значительно снизить объемы трафика, что делает особо актуальной концепцию граничных вычислений в IoT (рис. 1).

Трансформация традиционного подхода в архитектуру IoT Edge

Рис. 1. Трансформация традиционного подхода в архитектуру IoT Edge

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

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

 

Архитектура на примере прикладного решения

Рассмотрим применение архитектуры Edge computing на примере сценария мониторинга распределенных погружных насосов. Сенсоры технологического оборудования измеряют параметры насосов, включая данные о потоке жидкости, которые считываются через CAN-шину терминалом. Эта информация выводится через Modbus RTU на панели мониторинга SCADA на площадке. Сейчас параметры работы анализируются обходчиками или аварийной бригадой, поскольку данных много, а связь является ненадежной и достаточно дорогостоящей, чтобы передавать весь объем телеметрии. Кроме того, технологические данные о работе оборудования являются конфиденциальными. Оптимизацией работы обходчиков и аварийных бригад занимается специалист в офисе. Он — обычно вручную — анализирует данные, которые были собраны при возникновении неисправности или обслуживании для оптимизации работы насосов. В связи с тем что на работу обходчиков, аварийных бригад и управление ими расходуются значительные средства, часто эти функции выполняются подрядными организациями, а сбор реальной статистики по отказам и их причинам является непрозрачным и в основном ручным — в процессе видится явный резерв по оптимизации.

Как в этом случае может помочь использование граничных вычислений? Оптимизация достигается за счет применения двух самых распространенных сценариев машинного обучения. К ним относятся «поиск отклонений и аномалий» и «оптимизационные задачи». «Поиск отклонений и аномалий» (рис. 2) позволяет ответить на вопрос, какие машины работают неправильно, а «оптимизационные задачи» — выяснить, при каких значениях технологических параметров установка работает максимально эффективно (например, потребляет минимальное количество энергии при максимальном потоке жидкости). Реализаций этих алгоритмов машинного обучения достаточно много, поэтому измененная архитектура предполагает появление на площадке Edge-устройства, которое через Modbus получает параметры работы насосов и передает их в модуль машинного обучения для обработки алгоритмом «поиска аномалий».

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

Рис. 2. Поиск аномальных параметров работы технологического оборудования

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

Из примера выше можно вывести ключевые требования к современным платформам граничных вычислений в IoT:

  • централизованное управление, установка ПО и обновлений, а также определение настроек и уставок прикладных модулей;
  • коммуникация с индустриальными устройствами по промышленным протоколам (Modbus, OPC-UA и др.);
  • двунаправленная передача данных (с устройства в облако и наоборот) по распространенным протоколам передачи сообщений (MQTT, AMQP);
  • защита данных при их передаче в облако через Интернет (контроль доставки, целостности, защита от изменений в процессе передачи);
  • контроль исполнения модулей ПО IoT Edge, перезапуск в случае сбоев, уведомления о статусе работы в облако;
  • организация коммуникации и быстрой передачи сообщений по внутренней шине между изолированными прикладными модулями.

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

Архитектура устройства IoT Edge

Рис. 3. Архитектура устройства IoT Edge

Рассмотрим реализацию решений граничных вычислений для IoT на примере Microsoft Azure IoT Edge, обеспечивающего работу сервисов потоковой аналитики, машинного обучения и функции Azure на периферийных устройствах, а также AWS Greengrass.

 

Microsoft Azure IoT Edge

В качестве среды выполнения в Microsoft используются хорошо зарекомендовавшие себя контейнерные технологии Docker, благодаря которым можно применять на периферии сложные вычислительные сценарии. Контейнеры позволяют изолировать модули внутри общей операционной системы, ограничить доступные каждому модулю ресурсы, существенно упростить развертывание модулей и их независимое обновление. Множество прикладных программ уже упаковано в контейнеры Docker, и большинство существующих решений можно легко «переупаковать» для использования в IoT Edge. Кроме того, контейнер с прикладным алгоритмом может разворачиваться на устройстве непосредственно из Container store правообладателя, что позволяет, с одной стороны, упростить развертывание сложных прикладных алгоритмов на устройстве, а с другой — обеспечить защиту интеллектуальной собственности разработчика алгоритмов и публикацию обновлений на устройства. Отдельное направление развития граничных вычислений — использование Azure Stack, которое дает возможность получить сервисы Azure именно в том месте, где они необходимы, с минимальной задержкой и отсутствием зависимости от стабильности канала до глобального облака.

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

 

Практический пример

Автор столкнулся с задачей реализовать удаленный мониторинг электродвигателей, оснащенных интеллектуальными приводами (рис. 4). Привод комплектовался модулем для получения информации о параметрах работы двигателя по ModBus, поэтому решением стали полностью встроенные средства. Сначала в облачном сервисе Microsoft Azure был создан центр «Интернета вещей» IoT Hub и заведен «цифровой двойник» граничного устройства — Gateway с Azure IoT Edge. Само граничное устройство представляло собой Intel Up Board с CPU Atom x5-Z8350, eMMC на 16 Гбайт и RAM на 1 Гбайт. Для развертывания Gateway была установлена Ubuntu версии 18.04 (хотя также могли подойти RHEL, другие версии Linux или Windows). Дополнительно нужно было установить на Gateway Docker, Python и собственно среду выполнения IoT Edge, запустив команду: pip install -U azure-iot-edge-runtime-ctl. В завершение необходимо было зарегистрировать Gateway на облачном сервисе, указав его SAS-ключ в команде iotedgectl setup.

Удаленный мониторинг электродвигателей

Рис. 4. Удаленный мониторинг электродвигателей

После старта runtime данный IoT Edge Gateway уже управляется через облако с использованием «цифровых двойников». «Цифровой двойник» — это структура данных, которая содержит в себе полное описание всех настроек устройства, хранящееся в облаке. Причем такой «двойник» есть как у самого устройства, так и у каждого модуля. А модуль — это прикладной алгоритм, упакованный контейнер Docker, как мы писали выше.

Таким образом, для передачи данных с привода в облако было достаточно развернуть модуль поддержки протокола ModBus TCP, указав адрес его образа — microsoft/azureiotedge-modbus-tcp:1.0-preview. Если бы нужно было загрузить контейнер из собственного репозитория Docker, требовалось бы указать его адрес. Все адреса подробно описаны в документации на сайте.

После этого на gateway runtime самостоятельно «приезжают» контейнеры с алгоритмами поддержки протокола ModBus TCP и передачи данных в облачный IoT Hub. Статус выполнения каждого контейнера можно отслеживать как в интерфейсе в облаке (рис. 5), так и непосредственно на контроллере.

Интерфейс настройки граничного устройства в Azure

Рис. 5. Интерфейс настройки граничного устройства в Azure

Настройки для подключения к приводу по ModBus TCP задаются уже в облаке. Для этого нужно было заполнить структуру данных в формате JSON (рис. 6). Среда исполнения на граничном устройстве получает уведомление об изменении настроек модуля ModBus, и они синхронизируются с устройством. В результате модуль подключается к приводу и начинает передавать в облако значения регистров ModBus в формате JSON:

Настройка «цифрового двойника» модуля ModBus TCP

Рис. 6. Настройка «цифрового двойника» модуля ModBus TCP

{
«DisplayName»: «RPM», «HwId»: «ABB-ACS50-0001»,
«Address»: «40001»,
«Value»: «1150»,
«SourceTimestamp»: «2018-04-25 10:40:38»
},
{
«DisplayName»: «Power»,
«HwId»: «ABB-ACS50-0001»,
«Address»: «40002»,
«Value»: «5789»,
«SourceTimestamp»: «2018-04-25 10:40:38»
},
{
«DisplayName»: «Amperage»,
«HwId»: «ABB-ACS50-0001»,
«Address»: «40004»,
«Value»: «4657»,
«SourceTimestamp»: «2018-04-25 10:40:38»
}

 

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

  • Загрузить на граничное устройство модуль Azure Function и настроить преобразование значений регистров ModBus в реальные параметры с соответствующими единицами измерения.
  • Загрузить модуль Stream Analytics и настроить его таким образом, чтобы он отправлял не все значения регистров ModBus, а только те из них, которые отличаются от предыдущих, — но не реже заданного интервала.
  • Загрузить модуль машинного обучения Azure Machine Learning и настроить модель таким образом, чтобы она определяла «аномальное» сочетание параметров двигателя. А саму модель взять из галереи на сайте.
  • Подключить телеметрию к решению: с открытым исходным кодом, Azure IoT Suite с панелями мониторинга и уведомлений.

 

Заключение

IoT Edge призван дополнить и расширить применение как облачных технологий, так и традиционных систем автоматики. Суть граничных вычислений — взаимодействие облака и периферии. При централизации ресурсов Edge-вычисления вырождаются в on-premises-облако. Концепция Edge computing предполагает создание гибридных «расширений» публичного облака на on-premises ЦОД, и это отдельное направление развития граничных вычислений. Подобные решения уже существуют и позволяют получить сервисы, аналогичные облачным, с собственного оборудования. При этом сервис предоставляется с качеством управления, которое соответствует публичным облакам, но с минимальной сетевой задержкой и с отсутствием зависимости от стабильности канала к глобальному облаку. Примером такого решения является Azure Stack.

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

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *