Автоматизация и промышленные ИТ системы: опыт внедрения и эксплуатации

Почему промышленную автоматизацию нельзя вести как обычный ИТ-проект

За последние годы граница между «заводской автоматикой» и «корпоративным ИТ» почти стёрлась. SCADA-системы работают на стандартных серверах, контроллеры подключаются к Ethernet, данные с линии уходят в облако и в системы аналитики, а операторские панели всё чаще выглядят как обычные веб-приложения. Логично, что бизнес начинает воспринимать автоматизацию как ещё одну ИТ-задачу: «напишите нам интерфейс, подключите датчики, сделайте отчёты».

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

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

Чем промышленные системы отличаются от корпоративных

Понимание этих различий определяет всю архитектуру проекта. Если относиться к ним как к «деталям», именно они и становятся источником аварий.

• Детерминированность важнее производительности. Корпоративная система оптимизируется под среднюю скорость и пропускную способность. Промышленная — под гарантированное время реакции. Команда на исполнительный механизм должна приходить в строго определённый интервал, иначе нарушается технология.
• Непрерывная работа 24/7 без окна обслуживания. Многие производства нельзя остановить «на ночь для обновления». Любое вмешательство планируется под технологические окна или ремонты, которые случаются раз в месяцы.
• Долгий жизненный цикл оборудования. Контроллеры и приводы живут 10–20 лет. Система должна уметь работать с «легаси»-протоколами и железом, которое уже снято с производства.
• Физические последствия. Ошибка в логике приводит не к неверной строке в отчёте, а к движению реального механизма, открытию клапана, изменению давления или температуры.
• Безопасность как отдельный контур. Функции аварийной защиты (Safety) должны быть независимы от прикладной автоматики и продолжать работать, даже если основная система вышла из строя.

Архитектура: разделяйте уровни и контуры

Базовый принцип, который мы закладываем в проекты, — чёткое разделение на уровни и изоляция критичного от некритичного. Классическая модель (полевой уровень, уровень контроллеров, уровень диспетчеризации SCADA/HMI, уровень MES/ERP) полезна не сама по себе, а тем, что задаёт границы ответственности и зоны отказа.

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

Сеть и кибербезопасность OT — не то же самое, что в офисе

Сегодня нельзя проектировать промышленную систему, не думая о безопасности сети. Подключение производственного оборудования к корпоративной сети и интернету открывает не только удобства, но и векторы атак, способных физически навредить процессу. При этом подходы офисной ИБ напрямую не переносятся: на производстве нельзя «принудительно установить обновление и перезагрузить», нельзя ставить агрессивный антивирус, который под нагрузкой притормозит контроллер.

Что мы считаем обязательным минимумом:

• Сегментация сети. Технологическая сеть (OT) физически или логически отделяется от корпоративной (IT) демилитаризованной зоной. Прямого доступа из офисной сети к контроллерам быть не должно.
• Принцип «только разрешённое». Между сегментами открываются только конкретные нужные соединения и протоколы, всё остальное запрещено по умолчанию.
• Контроль удалённого доступа. Удалённое подключение подрядчиков и интеграторов — частый канал инцидентов. Оно должно быть временным, журналируемым и проходить через контролируемый шлюз.
• Резервные копии конфигураций и прошивок. Не только данных, но и проектов контроллеров, настроек SCADA, образов панелей — чтобы восстановить систему после сбоя за часы, а не за недели.

Внедрение: тестирование и ввод в эксплуатацию

Главное отличие пусконаладки промышленной системы от релиза веб-сервиса — нельзя «проверить в бою». Поэтому максимум проверок переносится на этапы до контакта с реальным оборудованием.

• Эмуляция и стенд. Логику управления отлаживают на эмуляторе контроллера и тестовом стенде, где «опасные» сценарии (отказ датчика, обрыв связи, выход параметра за предел) можно проигрывать безопасно.
• FAT и SAT. Приёмка на стороне разработчика (Factory Acceptance Test) и затем на объекте (Site Acceptance Test) с заранее согласованными сценариями и критериями приёмки, а не «посмотрим, как пойдёт».
• Поэтапный ввод. Запуск по участкам, с возможностью вернуться к ручному или прежнему режиму управления. Должен существовать продуманный план отката для каждого этапа.
• Обучение операторов. Даже идеальная система бесполезна, если оператор не понимает, что означают её сигналы и как действовать при отказе. Документация и тренинг — часть внедрения, а не «потом».

Эксплуатация: где проекты живут или умирают

Внедрение — это 20% жизни системы, остальные 80% — эксплуатация. Здесь чаще всего и накапливаются проблемы, которые потом «внезапно» выливаются в аварию.

Типичная история деградации: систему запустили, она работает, документацию никто не обновляет, специалист, который её настраивал, ушёл, обновления безопасности не ставятся «чтобы не сломать», бэкапы конфигураций никто не проверял на восстановление. Через пару лет любой сбой превращается в долгий и дорогой разбор «как это вообще работает».

Что снижает риски в эксплуатации: актуальная и версионируемая документация, мониторинг состояния не только процесса, но и самой инфраструктуры (диски, сеть, ресурсы серверов SCADA), регламент обновлений с тестированием на стенде, и понятное разделение ответственности между ИТ-службой и технологами.