Где проходит граница интеллекта мира Интернета вещей

В связи с концепцией Интернета вещей (IoT – Internet of Things) мы много говорим о пограничном (edge) интеллекте и преимуществах, которые он может принести: это унификация данных путём трансляции протоколов и агрегации данных для взаимодействия с различными новыми и устаревшими подсистемами, а также получение данных и преобразование их в более удобные для ИТ форматы; снижение затрат за счёт локального реагирования на события и их фильтрации, что позволяет быстро реагировать на ключевые события, снижая затраты на передачу необработанных данных и тем самым повышая ценность передаваемой информации; быстрое принятие решений благодаря реализации локальной бизнес-логики, за счёт оперативного локального принятия решений и автономной работы в случае сбоя связи; повышение общей безопасности системы благодаря управлению ключами, аутентификации и шифрованию (рис. 1).

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

Традиционный путь

В контексте архитектуры Интернета вещей остаётся неясным вопрос, где же на самом деле находится пограничный интеллект. Эта неопределённость в значительной степени связана с различиями между классическими архитектурами систем автоматизации и архитектурами IoT. В классической системе автоматизации граница обычно определяется как место, где реальный мир встречается с виртуальным. Это точка, где датчики и приборы взаимодействуют со SCADA-системой (или любым другим программным обеспечением, подходящим для конкретного рассматриваемого приложения). С момента, когда данные достигают этой границы, вся система работает в рамках традиционной иерархии сбора данных и управления. Обычно все данные передаются вверх по стеку в точку, где принимается решение, а результирующие команды управления передаются обратно на границу (рис. 2). 

Появление программируемых логических контроллеров (ПЛК) и интеллектуальных удалённых терминальных блоков (Remote Terminal Unit – RTU) позволило управлять локальными процессами на самой границе, передавая по цепочке только сводную информацию о процессе и возвращая в него управляющие команды, например, для изменения уставки алгоритма, регулирующего локальный поток. В этом случае архитектура и соответствующие потоки данных остаются практически неизменными. Крайне важно, что фактические данные, передаваемые по кругу, всё равно остаются в своём необработанном состоянии, заставляя центральную систему считать, например, что двоичное число, поступающее с сенсорного интерфейса, на самом деле трактуется в терминах физического измерения как изменение точки касания экрана, и оставляя граничному устройству задачу интерпретировать то, что означает с точки зрения его локальной работы изменение значения, полученного в виде двоичной переменной.

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

Архитектура систем IoT

В качестве примера рассмотрим конференц-зал компании Advantech с термостатом и обогревателем. Термостат регулярно собирает данные и обменивается ими c другими авторизованными системами. В среде Интернета вещей недостаточно отправить сообщение «регистр 123 имеет значение 456» и предоставить вышестоящим системам самим интерпретировать его. Вместо этого требуется отправить исчерпывающие данные, фактически имеющие вид «температура в конференц-зале Эйндховенского здания Advantech по адресу… в 10:05 17 февраля 2020 года равна 21,5 градуса по Цельсию». Такая информация может быть использована любым авторизованным приложением без каких-либо дополнительных знаний о системе, которая её произвела. Принципиальная характеристика системы IoT состоит в том, что порождаемые её компонентами данные должны быть представлены в виде, пригодном для потребления любыми авторизованными системами. Это означает, что данные не могут передаваться в виде простых двоичных значений, для интерпретации которых требуется знание параметров исходной среды. Любая текущая или будущая система, потребляющая данные, должна иметь возможность использовать их без каких-либо глубоких знаний о том, как они были созданы. Формат данных должен быть пригоден для свободной передачи от производителя к потребителю, не следует полагаться на согласование в режиме «опрос-ответ» со стороны некой центральной системы. Производитель данных также должен контролировать причину и момент выдачи данных: на циклической основе, в ответ на какое-то локальное событие, либо, чаще всего, и на то и на другое.

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

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

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

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

Если датчики подключены к «неразумному» последовательному или сетевому интерфейсу, а первая точка обработки восстановленных данных находится в устройстве выше этого уровня, то данное устройство является пограничным устройством или шлюзом Интернета вещей? Что, если это устройство также имеет некоторые датчики, подключённые непосредственно к нему, – это меняет суть вещей? Что делать, если интерфейс датчика не является «неразумным» и может выполнять некоторую предварительную обработку сигнала или другую локальную логику, но всё же представляет свои данные в виде необработанных двоичных регистровых значений, – он не является частью системы IoT, потому что его данные не могут быть независимо использованы, но при этом имеет пограничный интеллект?

Распределение интеллекта

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

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

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