Июль 2021: Должны ли OT-исполнители принимать облако? Стратегическое решение для современных сетей

28 июля 2021 г.

Смещение того, где происходит вычислительная функциональность, варьировалось за последние десятилетия от централизованного (помните мейнфреймы и тонкие клиенты?) к распределенному. Недавно много говорят о подъеме Edge Computing. Это не конечное состояние, а очередной веха в постоянной эволюции system-of-systems архитектур. В этой статье я аргументирую за сдвиг, со временем, обратно к Облаку.

Когда началась Industry 4.0, первичная концепция была о software-defined everything. Четвертая промышленная революция должна была доставить еще больше автоматизации чем третья, мостя физический и цифровой миры. Для этого требовался сдвиг от централизованных фиксированных промышленных контроллеров к тем, что адаптируются к меняющимся рыночным нуждам и/или обратной связи от среды. Это означало сдвиг к software-defined системам. PLC, представленные как физический ввод с I/O, теперь — container workload на большой платформе. На более высоком уровне это меняет взаимодействие физического, цифрового и людей. Машины из dedicated контроллеров, не обновляемых, теперь будут driven by software-defined industrial PC, которые и драйвят машины, и понимают/адаптируются к окружению.

Большие инновации у облачных провайдеров сейчас. Можно сказать, мы в Cloud Wars. Фокусируясь на Северной Америке и Европе (исключая китайскую экосистему с Ali Baba, Baidu, Tencent), три лидирующих облачных провайдера толкают все более инновационные и полные продукты. Они также признали опасения клиентов от привязки к одному провайдеру. Пример: Google Anthos (2019) — единый согласованный способ управления Kubernetes workloads на on-prem и public cloud.

Для OT-исполнителя коннективность к такому функционалу предлагает соблазнительные перспективы системной эффективности через доступ к сервисам: data lakes, streaming analytics, data storage, IoT security management, monitoring. От клиентов слышим: внедрение похожей функциональности on-prem может быть в 2–3 раза дороже. Верю, cost gap будет расти.

IT-организации почти во всех отраслях переходят или перешли на cloud-сервисы. OT-операторы же медленно принимают cloud-техники. Хотя переход в Облако освобождает OT-оператора от maintenance задач (проvisioning, установка, обновления, патчи), они все еще хотят держать контроль и лимитировать угрозу киберуязвимостей. Частично — потому что этот разговор конфликтует с культурой, заложенной в OT-лидерах: держаться подальше от влияния IT-организаций и оставаться независимыми закупками и управлением своей tech-инфраструктурой.

Некоторые операторы понимают: перед лицом растущего давления затрат, переход в Облако может упростить операции и дать больше гибкости в масштабировании вверх/вниз. В мануфакчиринге мы видели больше в публичном домене от Microsoft и его клиентской базы, строящейся на десятилетиях бизнес- и поставщиковой привычки вокруг Windows®. Изначально фокус на predictive maintenance и quality improvement юз-кейсах.

1. Пищевая промышленность, упаковочный пионер Tetra Pak, использует новые цифровые инструменты, позволяющие его cloud-коннектед машинам предсказывать точное время обслуживания оборудования. Подключая упаковочные линии к Microsoft Azure Cloud, Tetra Pak собирает операционные данные для информированного тайминга обслуживания.
2. Производители получили новый подход к поддержанию качества в high-volume мануфакчиринге благодаря компетентному и cost-effective ИИ. Операторы могут анализировать камерные фиды в real-time для идентификации и тегирования бракованных виджетов физически или виртуально. Потенциально стало возможным инспектировать каждую деталь с конвейера — что не было ни экономично, ни практично с человеческими операторами. Особенно ценно для сложных автокомпонентов, price-sensitive, high-volume и часто safety-critical.

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

1. Разделение софта и железа — стоимость maintenance и upgrade падает значительно
2. Системы становятся гораздо более гибкими и реагируют на меняющиеся требования с значительно меньшей стоимостью, риском и временем
3. Системы становятся observable — открывает сбор данных, уникальные инсайты и closed-loop оптимизации

Вызов — доставить эти возможности, сохраняя витально важные атрибуты OT-сети: системный аптайм, детерминистическая real-time функциональность и иммунитет к кибератакам.

Архитектура для такого типа системы — то, что мы называем «Mission Critical Edge» — безопасно объединяет масштабирующие выгоды IT-инфраструктуры с надежностью, детерминистическим real-time поведением embedded платформ. Атрибуты:

1. Airgapping: Системные архитекторы должны точно определять и дедицировать CPU, память и I/O ресурсы конкретным VM. Эти VM должны быть изолированы друг от друга включая northbound и southbound коннективность. Это позволяет OT и cloud приложениям резидировать на одной системе
2. OT Manageability: Система должна быть гибкой в управлении и контроле конфигурации и сетапа. Пока система управляется локально, специфические workloads должны обновляться и управляться Облаком.
3. Performance: Real-time performance гарантирован для workloads: PLC, PAC, ECU. Значит, система, хостящая cloud workloads на цехе, может иметь дедицированный partition как бэкап для физического PLC.
4. High Availability: High availability на разных уровнях: в одной системе, между двумя системами в ячейке, по всей производственной линии.
5. Orchestration Framework Integration: Edge системы должны работать с локальными или cloud-based management фреймворками. Например, системы по заводу дедицируют часть workload для формирования Kubernetes кластеров.

В заключение, mission-critical edge архитектура позволяет OT-операторам деплоить Cloud-коннектед сервисы и workloads на заводском поле не затрагивая текущие операции. Достигается за счет возможности edge-систем на цехе запускать множественные airgapped workloads включая real-time, AI/ML, security и др. Кроме того, airgapped workloads могут комбинироваться для запуска Kubernetes-оркестрированных container workloads.

Паван Синг, VP Product Management, Lynx Software Technologies