Как промышленным предприятиям выстроить ИТ-ландшафт в "эпоху данных"

В 2024 году объем мирового рынка интернета вещей (IoT) оценивался в $714,48 млрд. По прогнозам аналитиков, к 2032 году рынок вырастет до $4 062,34 млрд при среднегодовом темпе роста 24,3%. С развитием технологий интернета вещей растет и объем данных, с которыми работают компании. О том, как предприятиям промышленности грамотно выстроить ИТ-инфраструктуру в таких условиях, расскажет Денис Хлебородов, основатель и генеральный директор Cloud X.

Базовые особенности ИТ-ландшафта крупного промышленного предприятия

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

Блок АСУ ТП делится на два уровня с разными задачами и требованиями. Информационный уровень (диспетчерский/надпроцессный) собирает и обогащает данные, но не формирует управляющих команд. Его функции — это приём телеметрии и событий, агрегация, визуализация в виде мнемосхем и панелей, отчётность, обмен данными с корпоративными системами и внешними источниками.

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

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

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

Новые требования к ИТ-ландшафту в "эпоху данных"

Исторически ИТ-ландшафт строился по трёхуровневой схеме: "полевой" уровень (датчики и контроллеры) — SCADA (АСУ ТП) — MES/уровень управления предприятием.

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

Однако при этом описанная архитектура дробит данные на изолированные слои и связывает их лишь точечными интеграциями. Данные рождаются в виде разнородных сигналов и проприетарных протоколов, затем проходят через SCADA (АСУ ТП) и historian с ограниченной семантикой, после чего попадают в MES/ERP уже в виде агрегатов и отчётов. В результате теряется контекст и временная точность, а единая модель объектов не формируется: у каждого уровня свои теги, справочники и правила именования. Любое изменение на полевом уровне ломает цепочку драйверов и ETL, время вывода изменений в продуктив измеряется неделями, потоковая аналитика и ИИ работают на неактуальных данных, а высокочастотная телеметрия отсеивается из-за ограничений SCADA и архивов.

Масштабирование тоже страдает: каждый новый ПЛК или протокол добавляет новую пару "источник данных — потребитель", их приходится соединять отдельным драйвером и отдельной настройкой тегов. Без единой шины событий, общей онтологии и API управление данными как активом невозможно, так как нельзя обеспечить сквозную трассируемость, версии схем, управление качеством, безопасный MLOps и исполнение моделей у края. Поэтому такая схема плохо соответствует эпохе данных и не может решить главных задач текущего этапа цифровизации.

Платформенный подход

Новая модель — платформенная. В её основе — промышленная платформа, которая закрывает сразу три функции.

Первая — "полевой" слой прямого управления устройствами: датчики и исполнительные механизмы получают команды не через разрозненные "коробки", а через отказоустойчивый кластер платформы. Он построен по принципу распределённой системы с мастерами и воркерами, связанными полно-связной топологией. Резервирование заложено в саму архитектуру: мастера мониторят воркеров, перераспределяют нагрузку, автоматически восстанавливают сервисы. Это не одна уязвимая "черная коробка", а множество узлов — логически и физически — что и обеспечивает крайне высокий уровень надёжности по сравнению с традиционными одиночными контроллерами.

Вторая — высокопроизводительный слой данных. За счет специализированных движков потоковой обработки и языков, ориентированных на стриминг, платформа умеет принимать и обрабатывать "горячие" потоки телеметрии — вплоть до сотен миллионов и миллиардов событий. То, что невозможно на классических SCADA-экранах, становится реальностью: сложные трансформации, корреляции, алерты в почти реальном времени.

Третья — слой логики и межвендорной абстракции. На практике на площадке почти всегда сосуществуют устройства разных производителей. Платформа создаёт единый "универсальный язык" взаимодействия: описанная в ней прикладная логика "упаковывается" под стек производителя А, а затем без переписывания транслируется на стек производителя Б. Компания перестаёт быть заложником вендор-локина: на полевом уровне можно использовать оптимальные по цене и доступности устройства, не жертвуя управляемостью и совместимостью. Для диспетчерского уровня это тоже даёт плюс: SCADA и аналитические витрины работают с унифицированной моделью, а не с зоопарком драйверов и протоколов.

Отдельный акцент — Edge-ИИ. В этой архитектуре модели искусственного интеллекта располагаются максимально близко к оборудованию. Узлы кластера оснащаются GPU-акселерацией; контейнеры с ИИ-сервисами разворачиваются прямо на площадке, в контуре платформы, и используют эти ресурсы для обработки событий на "границе". Вокруг ИИ строится "цифровой двойник" станции/цеха: он работает на диспетчерском уровне, сравнивает реальное поведение с эталонным и помогает оператору и автоматике принимать решения.

Диспетчеризация, в результате, получается многоуровневой. Диспетчерский уровень 1 — на самой площадке: видит технологию "вживую", работает с горячими потоками. Диспетчерский уровень 2 — надплощадочный: та же платформа, но с более длинной памятью и расширенным контекстом; сюда безопасно "подмешиваются" внешние источники (например, погодные сервисы), давая более точные прогнозы и оптимизацию. Диспетчерский уровень 3 — облачный, уже масштаба всего предприятия или холдинга: единая картина активов, сравнение производственных площадок, корпоративные KPI, долгосрочная аналитика.

Развёртывание гибко: для он-прем сценариев используется решение класса Extender Hub (управление и администрирование локальны, весь стек — на площадке). Для централизованной модели — облачный вариант, который управляется из облака, но при этом "видит" и управляет локальными узлами как единым контуром. Для оператора разница в повседневной работе минимальна: одна и та же платформа на земле и в облаке, просто разные точки администрирования.

Важно понимать жизненный цикл ИИ-моделей. Модели со временем "дрейфуют": датчик стал шумнее, сенсор запылился, процесс слегка "уплыл" — и качество распознавания/прогнозирования падает. Поэтому в архитектуре предусмотрен полный замкнутый цикл MLOps. На "горячем" слое данные агрегируются и предобрабатываются: из миллиардов событий формируются компактные, валидированные наборы. Через диод данных эти агрегаты поступают наружу — в корпоративный Data Lake/DWH. Там специализированный сервис автоматически подбирает выборки, переобучает модели, валидирует и тестирует их. Каждая новая версия проходит цифровую подпись (подтверждение корректности и целостности) и возвращается обратно на площадку, в тот самый edge-кластер, где начинает работать вместо старой. Так обеспечивается безопасное и непрерывное улучшение качества без нарушения принципов изоляции технологического контура.

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