Архитектурные вызовы для встраиваемых устройств (embedded devices) в промышленные интернет вещей

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

Как можно устранить пробелы, чтобы обеспечить более плавное развертывание и более эффективную повседневную работу?

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

Встраиваемые устройства в промышленный интернет вещей (IIoT)

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

Хотя и конечные узлы, и шлюзы являются встроенными устройствами, они могут значительно различаться по форм-фактору и функциональности. Устройства конечных узлов могут быть довольно маленькими. Зачастую это интеллектуальные 8- или 16-битные датчики, которые используют упрощенные беспроводные протоколы и стратегии экстремального управления питанием для питания на месте установки и работы без технического обслуживания. На другом конце спектра конечные узлы, которые могут быть мощными многопроцессорными и многоядерными устройствами с вычислительной мощностью, подобной корпоративной / серверной.

С точки зрения программного обеспечения устройства конечных узлов могут работать на «голом железе» (без операционной системы). Для более крупных устройств часто разворачивается операционная система реального времени (RTOS) или даже операционная система общего назначения (GPOS), такая как Linux.

Примерная архитектура компонента программного обеспечения для пограничного узла или конечного узла, подключенного к облаку, показана на рисунке ниже. На схеме показана типичная архитектура, которая состоит из предоставленного поставщиком облака SDK для устройства и других служб ОС / системных сервисов. Необходимо выполнение требований управления устройством для его подключения.

Архитектура IIoT программного обеспечения устройства состоит из комплекта разработчика программного обеспечения (SDK), предоставляемого поставщиком облачных услуг, для базовых служб и служб ОСОС / системные службы для управления устройствами  промышленных интернет вещей (IIoT)

Операционные системы / системные сервисы расширяются на основе встроенной инфраструктуры устройств и коммуникационной инфраструктуры, предоставляемой облачными поставщиками SDK. Эти сервисы выполняют функции, необходимые для комплексного управления устройством IIoT. Некоторые из этих функций включают службы обновления программного обеспечения (как для системного ПО, так и для приложений); системная диагностика, мониторинг состояния и профилирование услуг; и безопасные системные сервисы.

Услуги по обновлению программного обеспечения

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

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

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

Процесс обновления программного обеспечения в инфраструктуре IoT

Для обеспечения безопасного процесса обновления программного обеспечения ОС требуется сквозная инфраструктура (рисунок выше). Это включает:

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

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

Системная диагностика, мониторинг работоспособности и профилирование

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

Безопасные системные сервисы

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

Решение для интеллектуальных устройств IIoT: интеграция облачных SDK с ОС / системными сервисами

Чтобы реализовать весь потенциал  промышленных интернет вещей, устройства должны иметь возможность предлагать полный набор функций времени выполнения, ранее обсуждавшихся в этой статье. На рисунке ниже показан пример структуры коммерческого программного обеспечения, которая отвечает этим запросам и требованиям. Это конкретная платформа IIoT объединяет функции и возможности предоставляемого поставщиком облачного SDK с сервисами OS / System, необходимыми для комплексного управления устройствами.Архитектура Mentor Embedded IoT Framework (MEIF) объединяет возможности предоставляемого поставщиком облачных вычислений SDK с сервисами OS System, чтобы обеспечить всестороннее управление устройствами

Mentor Embedded IoT Framework (MEIF), новый продукт от Mentor, а теперь компании Siemens, поддерживает несколько облачных платформ, включая Amazon Web Services (AWS), Microsoft Azure и Siemens MindSphere. Архитектура MEIF также поддерживает серверные приложения на основе Eclipse IoT (например, Leshan для управления устройствами и hawkBit для управления программным обеспечением парка устройств) в облаке или локально.

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

На рисунке выше представлена ​​иллюстрация архитектуры MEIF высокого уровня. Все в MEIF относится к устройству или шлюзу. Все, что находится над MEIF, в основном идет в облачной или локальной инфраструктуре (локальный сервер, шлюз или промышленный ПК). MEIF интегрирует предоставляемый поставщиком сервис облачных вычислений SDK в среду выполнения ОС устройства, чтобы обеспечить бесперебойную работу с облачным бэкэндом. Он предоставляет дополнительные услуги, необходимые для управления и мониторинга устройства из бэкэнда. Это помогает пользователям IIoT лучше понимать и функционировать во всей среде промышленных интернет вещей.

Выводы

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

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

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