Привет, постоянные (и не очень) читатели!
Приходит как-то молодой IT-специалист со свежим стеком из Docker’ов, микросервисов и К8s на завод. В цеху сверкают панели управления, гудят моторы, а он пытается подключиться к этому промышленному добру.
И, внезапно (нет), оказывается, что привычный IT-стек здесь не работает — у заводчан свои протоколы, свои легенды и свои правила. Годами. Десятилетиями. Из уст в уста, от конунга к сыну и т. д. и т. п. Айтишник достаёт ноутбук, спрашивает, какая тут точка доступа, а в ответ — тишина. Только матёрый усатый автоматчик (спец по работе с автоматизированными системами на заводах) медленно поднимает глаза, откашливается и с лёгкой тоской в голосе говорит:
— Тут, сынок, Modbus по RS-485. Без TLS. Без DHCP. И если что, мы это на Delphi писали, в 2004-м.
И это ещё повезло, что на Delphi в 2004-м :) А могло быть написанно в другой стране (году этак в 1990-м) на паскале или фортране. Так и живут некоторые заводы, где вместо YAML — скрипты на паскале, вместо DevOps — старая добрая флешка с патчами, а вместо облачных масштабируемых серверов — шкаф с вентиляцией (в лучшем случае) и приклеенным на скотч листом: «Работает — не трожь!». Хотя по оценке того же Ростеха, если массово развернуть промышленный интернет вещей (IIoT) в разных секторах, это принесёт нашей экономике ~5,5 трлн рублей выгоды. Но пока такие цифры выглядят фантастикой.
В этой статье я расскажу о том, как сталкиваются два мира: IT и OT (Operational Technology). Какие сложности у айтишников в SCADA, почему интернет вещей часто работает без интернета, и как улучшение кибербеза может ухудшить его при внедрении IIoT.
SCADA, OT и старые секреты промышленных протоколов
Давайте быстро пройдёмся по технологиям предтеч из введения, а то, как говорится, не все поймут, немногие вспомнят :)
OT (Operational Technology) — это аппаратные и программные системы (программно-аппаратные комплексы, если угодно), которые управляют физическими процессами в промышленности, энергетике, транспорте и других критических инфраструктурах. Напомню, что в IT главное — данные и их обработка, а в OT ключевая задача — контроль и выполнение реальных задач: движение конвейера, нагрев реактора, подача электричества.
В OT не любят менять работающие решения, поэтому на заводах до сих пор повсеместно используют старые/устаревшие (нужное подчеркнуть) промышленные протоколы.
Modbus — популярнейший М2М-протокол, который живёт с 1979 года и до сих пор вездесущ. Он работает по схеме «ведущий–ведомый» (master/slave) по последовательным линиям, например, RS-485 (стандарт физического уровня для асинхронного интерфейса) или TCP/IP (Modbus TCP). Стандарт открыт и поддерживается почти всеми производителями железа — удобно, так как любой ПЛК из семейств Siemens, Schneider, OVEN и др. поддерживает протокол Modbus. Протокол настолько примитивен, что его можно развернуть даже на микроконтроллере без ОС.
Ремарка! ПЛК, он же программируемый логический контроллер, он же programmable logic controller, он же PLC — это промышленный компьютер для автоматизации процессов. Он считывает данные с датчиков (например, температуру или давление), обрабатывает их по заданной программе и управляет исполнительными устройствами (двигателями, клапанами, сигнализацией). Работает годами в пыли, жаре и c вибрацией; внутри обычно микроконтроллер или промышленный процессор, вроде Intel Atom (E3845) или Intel Celeron (N2930). |
Но, как грица, есть нюанс: это асинхронная система запрос–ответ с фиксированными адресами регистров и без автоматики обнаружения. Никакого DHCP и push-уведомлений — оператор запросил, например, температуру, SCADA отправила запрос, а ПЛК вернула значение.
Как это выглядит на практике?
Допустим, на заводе есть ПЛК (контроллер) и датчик температуры, оба на Modbus. ПЛК (Master) отправляет запрос: «Дай мне значение из регистра 01» (где 01 — адрес температуры). Датчик (Slave) отвечает: «01 = 25.5°C». Всё это происходит в бинарном виде (или в ASCII, если используется Modbus RTU/ASCII), но для пользователя выглядит как простой обмен числами.
Если ПЛК вышел из строя, никто не узнает об этом, пока его не опросят (в отличие, например, от протокола MQTT с логикой «издатель-подписчик» (pub/sub), где есть механизм последней воли, когда ПЛК или датчик уведомляет всех о своей смерти). Да, для критических событий используют аппаратные прерывания, но это уже совсем другая история.
Почему так? Чем проще протокол, тем меньше уровней абстракции и точек отказа — этакая инженерная эвристика. Фиксированные адреса и ручная настройка минимизируют сюрпризы, особенно в детерминированных системах (но появляются сложности с масштабированием и обслуживанием). А опрос регистров в лоб отлично работает при малом количестве переменных и высокой предсказуемости (хотя при масштабировании системы или авариях (и других событиях, где нужна реакция реального времени) эффективнее работает подписка на события.
Но уточню, что современные ПЛК (например, Siemens S7-1500, Beckhoff CX) уже поддерживают технологии 22 21 века: подписки на изменения через другой популярный протокол OPC UA (PubSub); автоконфигурацию через DCP в PROFINET, встроенный MQTT для облачных уведомлений и др.
И пару слов про OPC UA
Протокол задумывался как универсальная сквозная платформа, а потому работает практически на любой ОС. OPC UA уже предлагает безопасный обмен данными между оборудованием и приложениями. В некоторых новых российских SCADA, например, «Каскад», уже есть поддержка OPC UA наряду с Modbus и даже Profibus. Profibus — это старая добрая полевая шина от Siemens, популярная в Европе, по ней управляют модулями ввода-вывода (например, сигналы с датчиков к ПЛК), проводят диагностику (обрывы, помехи), передают параметры устройств (настройки частотников/инверторов, температурных контроллеров).
Но правда в том, что огромное количество заводов на зрелых рынках до сих пор работают по старинке с Modbus RTU. Ведь что мы автоматчики делаем, когда работает? Правильно — не трогаем.
Такие дела.
Теперь пора поговорить про SCADA-системы
SCADA (Supervisory Control And Data Acquisition — диспетчерское управление и сбор данных) — это прикладное ПО, которое управляет промышленными процессами, собирает данные с оборудования (датчиков, ПЛК), сервер SCADA их обрабатывает и выводит информацию оператору в виде графиков, схем и анимаций. Это не операционка, а именно ПО, которое работает поверх Windows, Linux или вообще без ОС.
Чаще всего SCADA работает на сервере или рабочей станции оператора. Она общается с контроллерами по протоколам — Modbus, OPC UA, Profibus и т.д. — и отображает состояние оборудования: температура, давление, аварии, уровень нефти в цистерне, число оборотов в минуту и прочее.
ВАЖНО! Да, вы правильно догадались — чтобы завод не вставал после отказа SCADA-хоста, используют принцип независимости ПЛК от SCADA: все ключевые контуры управления и защиты реализованы прямо в ПЛК и работают автономно, а небольшие перебои связи между ПЛК и SCADA не влияют на выполнение управляющих или защитных функций. Есть даже нормативные требования, вроде РД 153-34.0-20.507-98, где прямо указано, что АСУ ТП (Автоматизированная Система Управления Технологическими Процессами) должна продолжать работу даже после выхода из строя верхнего уровня (то есть SCADA). |
SCADA не любят обновлять. Там может быть всё что угодно: от собственной встроенной БД до ActiveX-компонентов, написанных в лохматом году. А в довесок — десятки скриптов, написанных руками заводских автоматчиков, которых давно уже никто не помнит. Так что любое обновление опасно — и нет гарантий, что новая версия/система не окажется менее надёжной (пускай и более продвинутой). Поэтому на заводах до сих пор можно встретить SCADA-системы на базе старых решений, вроде Citect, InTouch, InduSoft и даже самописные оболочки на Delphi 7.
Примеры популярных SCADA-систем:
Simatic WinCC (Windows Control Center)
SCADA-система от Siemens для мониторинга и управления промышленными процессами. Интегрируется с PLC Siemens, используется в автоматизации производства, энергетике и инфраструктуре. Поддерживает визуализацию и анализ данных. До 2022 года была распространена в металлургии и автопроме. Санкции сократили её использование в новых проектах, но старые установки (2000–2010-е годы) остаются на заводах. Часто встречается в legacy-системах, но новые внедрения редки из-за проблем с лицензиями.
Ignition
Кроссплатформенная SCADA от Inductive Automation. Отличается модульной архитектурой, веб-интерфейсом и поддержкой современных технологий (SQL, MQTT). Применяется в промышленности для гибкого управления и интеграции с IoT. Используется в новых IT-ориентированных проектах, но не в legacy-системах, так как слишком современна для старых заводов.
GE CIMPLICITY
SCADA-система от GE Digital, ориентированная на энергетику и производство. Предлагает визуализацию, управление и сбор данных с оборудования. Известна надёжностью и длинной историей. До санкций была популярна в энергетике и нефтегазе. Legacy-системы продолжают работать в крупных предприятиях (например, электростанциях). Новые внедрения редки из-за ухода GE из России.
КАСКАД
Активно развивающаяся универсальная российская SCADA. Делает ставку на визуализацию, безопасность и доступность. Вендор обещает лёгкую интеграцию с IIoT-платформами, но реализация зависит от конкретного проекта. Используется в нефтегазе, энергетике и металлургии. Лидер в 2025 году для новых проектов благодаря надёжности и соответствию российским стандартам. Может интегрироваться с legacy-оборудованием, но чаще встречается в новых системах.
Альфа платформа
Относительно молодая, но амбициозная российская SCADA-система, которую продвигают как инструмент цифровой трансформации промышленности (если верить презентациям). Под капотом — довольно гибкий фреймворк, позволяющий собирать не просто SCADA, а полноценную IIoT-платформу: с аналитикой, прогнозированием, веб-интерфейсами и кучей интеграций. Она включена в реестр российского ПО (№1187, Минцифры) и активно продвигается в рамках импортозамещения, особенно после санкций 2022 года.
MasterSCADA
Российская SCADA от компании «ИнСАТ», включена в реестр отечественного ПО. Ещё один отечественный тяжеловес, особенно популярен в энергетике, промышленности и ЖКХ. Поддерживает работу с распределёнными системами и широкий спектр протоколов, имеет мощную графическую оболочку и инструменты для отладки. Очень популярна в 2025 году благодаря импортозамещению. Используется в новых проектах и модернизациях, реже — в старых системах, но может интегрироваться со старым оборудованием.
TRACE MODE
Старейшая российская SCADA от AdAstra, разрабатывается с 90-х. Её любят за модульность, поддержку большого числа протоколов и дружбу с отечественным оборудованием. Применяется в энергетике, нефтегазовой отрасли и автоматизации зданий. Самые популярные версии визуально — будто попал в эпоху Windows 98, но работает стабильно (хоть и неудобно). Главная фишка — встроенный язык управления FBD (Function Block Diagram) и поддержка паскалеподобных скриптов. Работает с устаревшими и современными протоколами. Доминирует в старых системах, но теряет популярность в новых. Частый гость на тех самых заводах «работает — не трогай».
Когда два мира сталкиваются
Вот что интересно — SCADA-системы часто выступают мостами между старым и новым. Но если на старом заводе появляется IT-директор, который мечтает о DevOps, CI/CD и контейнерах в продакшене, то мечты эти разобьются о реальность. Многие контроллеры не то что Kubernetes, они и Windows 10 не узнают (нередко системы под древней Windows XP Embedded работают). Оборудование часто чинят локальные инженеры прямо в цеху с паяльником, версии ПО живут годами без апдейтов, а обновления часто либо рискованны, либо просто их нет (патчей не существует). А рядовой IT-спец, привыкший к высокоуровневым API (REST+JSON), асинхронным фреймворкам и облаку с SLA, не готов к миру регистров Modbus (это даже не ассемблер с переменными, условиями и циклами, а возня с регистрами и флагами в битах), ограниченных скоростью RS-485 и латентностью в сотни миллисекунд.
Не баян, а классика: «Всё, что нельзя запрограммировать на ассемблере, можно только спаять» :)
В старых SCADA запросить температуру — это не GET /api/sensor/temperature. Тут ты сначала узнаешь, какой у датчика номер регистра, потом — какое у него смещение адреса (offset), следом проверяешь порядок байтов (big-endian там или little-endian), а потом — с кривой документацией в руках — начинаешь писать руками опросный цикл. И если в процессе что-то пошло не так, то, скорее всего, виноват не сервер, а электромагнитные помехи на линиях из-за кривого заземления или неэкранированных витых пар. А ещё бывает, что у ПЛК просто нет времени ответить — он занят управлением реальными клапанами и машинами, что приоритетнее коммуникаций со SCADA.
И вот перед нами столкновение цивилизаций. С одной стороны — новое поколение IT-спецов: они ходят с ноутбуками, знают Python, работают с Kubernetes и любят ARM-платы (привет, Raspberry Pi). С другой — заводские автоматчики, за плечами которых DOS-программы на RTOS, прошивки двадцатилетней давности и тысячи часов работы с железом.
IT (Информационные технологии) | OT (Операционные технологии) | |
Главная цель | Обработка данных, связь/сеть, автоматизация. | Управление физическими процессами. |
Надёжность | Сервер перезагрузится после апдейта — ничего страшного, всё на кластере. | Если ПЛК ушёл в ребут посреди смены — это остановка линии, возможно, поломка оборудования и вызов комиссии. |
Обновления | Регулярные и автоматические апдейты — залог безопасности. | Обновление — это риск простоя, сбоя и повторной сертификации оборудования. |
Тестирование | Если баг, зальём хотфикс. На проде или в тестовой среде проверим. | Тестирование — на отдельном стенде, в течение недель/месяцев. Внедрение — строго по регламенту, после одобрения от заказчика и службы контроля качества. |
Безопасность | Firewall, шифрование, VPN, изолированные среды, двухфакторка. Кибербез — главное. | У нас сетка изолирована физически. Это и есть защита, поэтому Modbus без пароля. |
Инструменты | Контейнеры, виртуализация, кластеры, облака. | ПЛК (Программируемый логический контроллер), SCADA, RS-485, Delphi. |
Жизненный цикл | 5 лет для софта — это больше, чем работает любой разраб в компании. | Контроллер работает с 2004 года, и менять его никто не собирается. |
Инфраструктура | Всё должно быть зарезервировано, забэкплено и виртуализировано, в идеале — в облаке. | Стойка в щитовой. Рядом трансформатор, пыль и пара дохлых крыс. |
Культура | Agile, DevOps, CI/CD, Observability. | Если сломалось, дядь Гриша починит паяльником прямо в цеху. |
Но начинать с чего-то надо. Например, можно не строить всё на выжженном поле, а интегрировать Modbus в высокоуровневую систему через промежуточные решения, вроде, OPC UA, Node-RED или готовые шлюзы Modbus-to-MQTT/HTTP.
Вот только огромный легаси-флот устройств к этому не готов. Там нет ни TLS/SSL, ни авторизации, ни даже понятия «пользователь». Это просто железки, которые по запросу отдают значение регистра. Хочешь IIoT — изволь потрудиться: шлюзы, трансляторы, прокси, скрипты, таймеры, костыли. Где-то на этом пути ты неизбежно почувствуешь, что IIoT — это не про скорость, а про настойчивость и изобретательность.
Поэтому на новых заводах строят всё с нуля и сразу по новым стандартам.
Интернет вещей без Интернета
Промышленный Интернет вещей (Industrial IoT, IIoT) — важная часть концепции Индустрии 4.0. Он не заменяет SCADA, ПЛК и АСУ ТП, а дополняет их: подключает датчики, собирает данные, анализирует тренды и помогает принимать решения на основе аналитики в реальном времени.
ИИ, машинное обучение, предиктивная аналитика, облачные платформы — всё это не про модные технологии, а про решение бизнес-задач: снизить простой, повысить энергоэффективность, отследить износ до аварии.
Внедрение IIoT — это не революция, когда взрывают Эмпайр-стейт-билдинг и строят Бурдж-Халифу. Это скорее капитальный ремонт действующего здания по новым стандартам — где-то ставят умные датчики вместо аналоговых, где-то добавляют шлюзы для сбора телеметрии, а где-то подключают облако, чтобы видеть картину не постфактум, а в реальном времени. Всё работает, производство не останавливается, но внутри — уже совсем другой уровень понимания процессов.
Но на многих производствах до сих пор царит air gap — физическая изоляция сетей от глобальной сети. Никаких публичных IP, никаких облаков. Всё замкнуто внутри. Станции, шкафы, контроллеры — в закрытом контуре, который в идеале не маршрутизируется через глобальную сеть.
Правда, на практике не всё так стерильно. Где-то «по ошибке» протянули DSL-линию для удалённого доступа, а директор завода об этом даже не знает. Поэтому поколению постарше приходится объяснять, почему кибербез нужно делать правильно и со всей ответственностью — но это уже другая история.
В общем, умные устройства могут быть, но доступа в глобальную сеть у них может и не быть. Данные сливают локально — через внутренние сети, а то и по старинке: инженеры вечером вставляют флешку, копируют логи за смену и отправляют их голубями на анализ. Классика sneakernet. Но для заводских инженеров — это рутина.
Поэтому, чтобы хотя бы что-то облачное заработало, внедряют edge-инфраструктуру. На заводе ставят локальные шлюзы и серверы, которые собирают данные с датчиков, обрабатывают их прямо на месте и сохраняют критическую телеметрию. Внешний мир подключается к ним редко и аккуратно: по VPN или при визите главного инженера.
Слышал, как на одном предприятии весь сбор данных идёт через КПП — с копированием CSV-файлов за последние 12 часов работы на сертифицированную флешку.
Почему всё устроено именно так? Потому что надёжно.
Что дальше?
IIoT — это медленный, но неотвратимый переход от ручного управления по звонку (буквально по телефону) к цифровизации и управлению по сети.
В будущем, когда IIoT станет стандартом на заводах (а это неизбежно) неожиданных аварий станет меньше — датчики заранее подскажут об износе. Все заводы будут, так сказать, самообучаться — алгоритмы и ИИ будут анализировать, где на производстве узкие места и куда утекают ресурсы. Цеха станут гибкими — производственные цепочки будут адаптироваться к спросу в режиме реального времени. А особо крупные и прибыльные заводы будут создавать свои промышленные облака, так как публичные не подойдут по соображениям безопасности — edge-ЦОДы, которые будут обрабатывать данные локально, а не на каком-нибудь AWS. Так что системные архитекторы и админы без работы не останутся даже с массовым переходом IT-инфраструктур в облака.
Уточню, конечно, что нынешний уровень технологий редко позволяет создать полностью роботизированный завод или конвейер без слабых мест. Иногда обычный работяга на одном из этапов производства лучше самого современного IIoT-робота.
Илон Маск, набив шишек при создании своего некогда самого автоматизированного завода в мире, сказал: «Излишняя автоматизация в Tesla была ошибкой. Точнее, моей ошибкой. Люди недооценены». Линии на его заводе во Фримонте постоянно вставали, роботы не справлялись с тонкой работой, а автоматизация на некоторых участках сильно тормозила процесс.
Маск сделал следующие выводы (примерно, точную цитату из книги не помню, но донесу суть) — если ты автоматизируешь неидеальный или запутанный процесс, то ты просто ускоряешь хаос, а не работу. Поэтому прежде чем внедрять роботов нужно:
Понять, нужно ли это вообще? Возможно, и сам шаг можно убрать.
Упростить процесс до сути.
Оптимизировать вручную.
И только после полной отладки — автоматизировать.
И отдельно другая его мысль: «Каждый раз, когда человек должен взаимодействовать с системой — это потенциальная точка отказа». Если процесс зависит от внимательности или дисциплины отдельного человека, то рано или поздно человеческий фактор сыграет свою роль.
В общем, людям нужен IIoT, а IIoT нужны люди для максимально эффективной работы. Такие дела.
Не всё так гладко с IIoT, как хотелось бы
Во многих OT-системах безопасность не заложена вообще. Речь не только о шифровании — тут и базовая аутентификация через раз встречается. Протоколы типа Modbus передают команды в открытом виде — если кто-то попал в сеть, он уже администратор. Взломать SCADA часто проще, чем веб-панель вашего роутера.
Добавим сюда околонулевую цифровую гигиену на заводах: общие пароли, флешки без антивируса, ручное копирование архивов. Получим среду, где любая атака типа Win32/Stuxnet может привести к физическому разрушению инфраструктуры. Промышленный сегмент просто не готов к современной модели угроз — ни организационно, ни технически. Там предстоит колоссальная работа.
Но допустим завод перешел на IIoT, чтобы закрыть эти дыры. Парадокс в том, что это может не улучшить, а наоборот — ухудшить кибербезопасность. Удобно, конечно, когда каждый датчик подключается к Wi-Fi, шлюз стучится в облако через HTTPS, SCADA получает API, а инженер смотрит на всю эту радость в Grafana через браузер.
Но безопасно ли это? Зависит от реализации. IIoT чудовищно увеличивает площадь атаки. Там, где раньше был один точечный канал — теперь десятки устройств, приложений, шлюзов, интеграций, и каждый из них — потенциальная точка входа.
Напомню, что речь не только про промышленность и деньги, но и про объекты критической инфраструктуры. Вот, например, 5 февраля 2021 года хакеры взломали водоочистные станции во Флориде и начали повышать уровень гидроксида натрия (щёлочи) в воде в 100 раз. Как? Получили доступ к SCADA через TeamViewer (там все компьютеры работали на Windows 7 и использовали 1 общий пароль) — и всё управление было выведено в интернет без VPN, без защиты, без ограничений. Закончилась история хорошо, так как вовремя заметили.
Этот случай — не исключение. Подобных «почти катастроф» по миру больше, чем хотелось бы. Современные атаки в условиях геополитики 2025 года часто направлены не на кражу данных, а на вмешательство в физические процессы. IIoT открывает новые возможности, но и новые дыры в безопасности, которых у традиционной OT-среды просто не было.
И вместо выводов — простой тезис. Инновации неизбежны, и бояться их бесполезно. Но идти к ним вслепую — тоже не вариант. Нужно готовиться заранее, шаг за шагом. И чем раньше начнёте — тем раньше закончите мучиться :)