Вы должны оставить обработку в облаке или на периферии? Оба. В частности, в IIoT разработчикам необходимо начать думать об обоих направлениях.

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

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

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

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

Облако-устройство на нефтяном месторождении

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

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

Из-за этих необходимых дублирований программирование для этих настроек может быть затруднено. Например, в приложениях Oracle, в сетях SCADA все приложения работают на Java. Страницы Oracle работают на Java. Следовательно, большинство программируемых промышленных устройств должны демонстрировать, что они могут запускать одно и то же приложение Java локально. Многие поставщики платформ IIoT теперь расширили объем программирования. Они создали устройства, которые могут перетаскивать один и тот же код Java из облака в отдельные пограничные устройства для запуска этого устройства. Конечно, его нужно разрабатывать для устройства и для облака, поэтому он требует особого внимания, в основном потому, что на устройстве процесс принятия решений немного отличается. Приложение не запускается, если оно не может общаться с облаком. Когда он не может говорить с облаком, он выполняет команду точно так же, как это сделало бы облако.

Приложения резервирования в UAS

В других промышленных условиях — например, в беспилотных системах — протоколы другие. Если дрон не может связаться с оператором, у него может быть простая команда, которая гласит: «Отследить все ваши GPS-местоположения, летать по ним в обратном режиме и возвращаться туда, откуда вы пришли, пока не сможете установить связь и получить новые команды». Итак, это одна и та же концепция. Программируемые платформы IIoT в настоящее время настраиваются и разрабатываются таким образом, чтобы они могли запускать приложения на нескольких разных языках. Если приложение написано на C, Java, Python — в общем, на чем угодно, что можно прочитать в облаке — его можно перетащить в эти пограничные устройства, и оно может выполнять те же протоколы непосредственно на пограничном устройстве. Эта простая концепция меняет представление IIoT о передаче данных и принятии решений в реальном времени. Если вы напишете свой код один раз, вы сможете оставить его в обоих местах, и если устройство потеряет связь, оно знает, что делать.

Конечно, при разработке приложений для периферии и промышленного Интернета вещей необходимо учитывать множество других соображений. Безопасность остается превыше всего, и мы каждый день видим примеры, указывающие на потенциальный крах, если безопасность не будет решена должным образом. Тем не менее, потенциал для связи «облако-устройство» и выполнения приложений остается большим. Для разработчиков способность мыслить на разных платформах, языках и программных функциях — это три ключевых момента, которые следует учитывать при создании приложений для промышленного Интернета вещей.

Для исходного сообщения в блоге перейдите здесь.