Производители оборудования приложили значительные усилия для разработки привлекательных решений для подключения сенсорных сетей. В зависимости от требований к оборудованию, появилось множество вариантов. Существуют шлюзы для конкретных областей применения, такие как шлюз FlexGate от EXPEMB, оптимизированный для LoRa. Есть также многофункциональные системы, например, шлюз conga-IoT от congatec, который обеспечивает до восьми радиоантенн, позволяя использовать чрезвычайно широкий спектр беспроводных технологий, а также подключать дополнительные периферийные устройства и полевые шины. Однако специализированные аппаратные платформы — это лишь первый шаг к созданию платформы решений, которая упростит разработчикам OEM-оборудования получение данных от встроенных устройств и гетерогенных сенсорных сетей в облаке.
В идеальном мире разработчиков облачных приложений распределенное оборудование требует минимального внимания. Разработчики хотят, чтобы процесс подключения устройств, машин и систем к облаку был таким же простым, как подключение USB-устройств или плат расширения PCIe к ПК: открыть облако, распознать устройства, настроить их по мере необходимости, и подключение к облаку завершено. Если бы встроенные вычислительные устройства имели такой удобный интерфейс, включая периферийные устройства, было бы очень просто автоматически создавать все необходимые облачные приложения и панели мониторинга с помощью соответствующих фреймворков и инструментов. Проблема в том, что данные с датчиков на уровне поля — от нескольких бит для измерения температуры до гигабит данных из больших видеопотоков — генерируются множеством датчиков и передаются в широком диапазоне различных структур данных, по разнородным протоколам, интерфейсам и путям передачи. Без локальной логики, способной обрабатывать эти разнородные данные и преобразовывать их в информацию, пригодную для передачи, установление полезного соединения с облаком практически невозможно. Облачные технологии позволяют записывать любое состояние с максимальной плотностью или собирать только необходимые данные в краткосрочной или долгосрочной перспективе, например, для проведения анализа больших данных и обеспечения доступа к этим данным по запросу из любой точки мира. Для этого необходим шлюз, будь то виртуальная системная платформа или выделенное устройство, где данные принимаются, преобразуются, обрабатываются и прозрачно передаются на соответствующие облачные интерфейсы.
Основное значение шлюзов:
Шлюзы играют ключевую роль в организации сенсорных сетей, поскольку являются узлами, с которых информация передается на место, в облако или к другим соседним шлюзам. Помимо правильной аппаратной конфигурации, им также необходимы отличные лингвистические возможности и навыки принятия решений. Они должны обладать логикой для сбора, анализа и преобразования данных с датчиков, а также для определения способов использования этой информации. Наконец, им необходима способность к согласованной структуризации данных, а также логика для двусторонней связи внутри облачного решения, и все это с надежным сквозным шифрованием.
Новый облачный API (интерфейс прикладного программирования) для IoT-шлюзов congatec представляет собой пример промежуточного программного обеспечения и логики для упрощения оркестрации беспроводных сенсорных сетей. Его цель — упростить подключение встроенных вычислительных технологий и сопутствующих периферийных устройств к облаку, предоставляя готовые к использованию программные модули, которые клиенты могут использовать в качестве шаблона для разработки собственных приложений. С помощью облачного API congatec для IoT-шлюзов локальные сенсорные сети всех типов могут быть интегрированы в любое облачное решение.
IoT-шлюз взаимодействует локально с интеллектуальными датчиками, обрабатывая и преобразуя полученные данные. Встроенные модули драйверов (EDM) служат интерфейсом для стороннего оборудования и плат расширения, обеспечивая логику, которая преобразует полученные данные в специфичную для приложения семантику логики IoT-шлюза. Данные передаются в облако поэтапно через предопределенные интерфейсы и процессы принятия решений с использованием прозрачно определенных модулей и функциональных блоков, которые могут использовать идентичные логические интерфейсы во всех приложениях.
Ключевая роль промежуточного программного обеспечения:
Программное обеспечение, особенно промежуточное ПО для IoT-шлюзов, имеет решающее значение для приема данных из промышленной сферы, их преобразования, упаковки и передачи в облако по запросу. Однако именно здесь обычно возникают проблемы с совместимостью, поскольку на сегодняшний день отсутствуют стандартизированные API для связи между датчиками, шлюзами и облаком. Этот пробел необходимо устранить путем стандартизации облачных API для IoT-шлюзов. Цель состоит в том, чтобы найти единый способ приема и обработки данных локально, а затем их пересылки в облако. В конце концов, только готовая к применению и, прежде всего, стандартизированная архитектура облачного API обеспечивает интеграцию различных беспроводных сенсорных соединений, таких как Bluetooth LE, ZigBee, LoRa и другие LPWAN, а также проводных протоколов для автоматизации зданий и промышленности, по принципу «подключи и работай». Таким образом, даже сильно гетерогенные конфигурации протоколов могут быть легко интегрированы с минимальными усилиями по разработке. То же самое, конечно, относится и к облачным коммуникациям, поскольку индивидуальные требования к проприетарным серверам или предложениям сторонних компаний, таких как Microsoft Azure, Telekom или Amazon AWS Cloud, также должны удовлетворяться в режиме «подключи и работай».
Первыми стандартизированными программными компонентами являются различные функциональные модули облачного API. С точки зрения полевых условий, ключевую роль играет сенсорный модуль с EDM, реализованный в облачном API congatec для IoT-шлюзов, поскольку он обеспечивает преобразование и передачу данных от локальных датчиков и исполнительных устройств в универсальное, независимое от протокола промежуточное программное обеспечение. Он также стандартизирует измерения в свободно определяемые физические единицы и проверяет значение полученных данных. Благодаря стандартизированному интерфейсу EAPI модули могут предоставлять соответствующие аппаратные параметры, такие как температура и напряжение системы, загрузка ЦП или обнаружение кражи.
Благодаря механизму правил, разработанному специально для конкретных приложений, шлюз отправляет локальные оповещения и запускает автоматические действия при превышении или приближении к превышению определенных пороговых значений. Благодаря аппаратно-независимому механизму управления датчиками, разработчики OEM-оборудования могут последовательно внедрять одни и те же типы датчиков, например, датчики температуры, одинаковым образом. Это упрощает настройку и повышает эффективность.
Помимо этой логики подключения оборудования и абстракции, отсутствует стандартизированный облачный интерфейс, который можно было бы свободно изменять в зависимости от поставщика облачных услуг. Для решения этой проблемы компания congatec в сотрудничестве с M2MGO разработала интерфейсный модуль: коммуникационный движок. Он обеспечивает зашифрованную связь с серверами или различными облаками через интеллектуальные проводные или беспроводные соединения. Если бы все функциональные модули предлагались на основе открытого, независимого от поставщика стандарта, датчики, шлюзы и облака можно было бы свободно собирать по мере необходимости. Это всегда работало бы.
Помимо возможности подключения оборудования к облаку по принципу «подключи и работай», разработчикам также необходимо удобное решение для настройки IoT-шлюзов для реализации описанных сценариев. Одним из решений, легко интегрирующихся с облачным API congatec для IoT-шлюзов, является облачная платформа M2MGO People-System-Things (PST). Помимо управления данными устройств и систем, PST предоставляет мощный набор функций для создания приложений без программирования. Пользователи могут создавать полноценные веб-приложения с помощью редактора с функцией перетаскивания. В зависимости от доступных устройств, мобильные приложения для конечных пользователей теперь можно создавать даже автоматически, без ручного вмешательства.
Структура экосистемы:
Конечно, такой подход с открытым облачным API может быть настолько же эффективным, насколько сильна поддерживаемая им экосистема. Для действительно простых в использовании решений крупным производителям встроенных вычислительных систем, периферийных устройств и облачных решений потребуется поддержка облачного API, поскольку каждое аппаратное устройство требует выделенного сенсорного модуля, а каждое облако — соответствующего облачного модуля. В зависимости от требуемой логики принятия решений шлюзом, достаточно выполнения конкретных правил. Это минимизирует трудозатраты на разработку для подключения к облаку. В стандартных установках можно развертывать сертифицированные, готовые к использованию модули без написания ни одной строки дополнительного программного кода. Принципы «подключи и работай», а также параметризация вместо программирования являются основополагающими. Если все стандартные модули установлены правильно, предоставленный сенсорный модуль считывает, преобразует и обрабатывает данные на IoT-шлюзе сразу после захвата, используя язык облака. В результате пользователь может просматривать обработанную информацию в автоматически сгенерированном веб-приложении, вместо того чтобы программировать и разрабатывать весь процесс для каждого датчика индивидуально. В будущем все необходимые данные будут автоматически передаваться в облако и пользователю.
Преимущества стандартизации.
Но стандартизация предлагает еще больше преимуществ: благодаря стандартизированным функциональным блокам клиенты больше не привязаны к конкретному поставщику. Кроме того, стандартизация таких API обеспечивает идеальную основу для стратегий миграции OEM-производителей. Разработчикам нужно спроектировать свое IoT-приложение только один раз, а затем перенести его на любую комбинацию датчиков, шлюзов и облаков для новых приложений. Такая переносимость очень удобна, поскольку облачное решение, которое локально подключает полевые шины, а затем обменивается данными через WLAN с облаком Microsoft Azure, отличается от решения, которое собирает данные локально через WLAN или LoRa, а затем передает их через 3G/4G в телекоммуникационное облако. Если отдельные шлюзы поддерживают стандартизированный облачный API, разработчикам нужно только изменить облачный движок; все остальное может остаться неизменным. Это эффективный способ реализовать даже самые уникальные требования с помощью стандартных, готовых к применению строительных блоков. В качестве примера, вот быстрый расчет: IoT-решение с четырьмя альтернативными сетями датчиков и тремя возможными облачными средами для разных приложений ранее требовало 12 совершенно разных реализаций на IoT-шлюзе (3x4). Стандартизированный облачный API значительно упрощает задачу, сводя ее к интеграции или развертыванию всего 7 движков (3 облачных движка плюс 4 сенсорных движка). Если некоторые из этих движков уже доступны, трудозатраты сокращаются еще больше. Все эти варианты также способствуют долгосрочной доступности решений.
Текущее состояние усилий по стандартизации:
Учитывая многочисленные преимущества открытой стандартизации для OEM-производителей и поставщиков IoT-приложений, два года назад была создана рабочая группа Standardization Group for Embedded Technologies eV (SGET). В качестве предварительного результата SGET представила первую в своем роде демонстрационную систему на Embedded World 2017. В настоящее время группа работает над завершением версии 1.0 нового стандарта облачного API для встроенных систем и модулей расширения. Цель — официальное принятие стандарта в начале 2018 года. До тех пор рекомендуется привлекать к участию больше производителей, поскольку чем шире база поддержки, тем больше шансов на долгосрочное внедрение этого стандарта. Усилия по стандартизации облачного API получили бы значительный импульс, если бы, помимо производителей встроенных технологий, этот открытый стандарт также поддержали поставщики периферийных устройств и крупные поставщики облачных услуг. Поэтому получение поддержки этих заинтересованных сторон является важной задачей для SGET в процессе стандартизации.
Авторы:
