Почти у каждого инженера в автоматизации есть история про “правильную” версию проекта, которую искали ночью по старым ноутбукам и флешкам. Формально система работала, но после небольшой доработки линия повела себя иначе, а доказать, что именно изменилось, никто не смог. В такие моменты становится ясно: проблема не в конкретном ПЛК или SCADA, а в том, что изменения живут без нормального контроля.
Когда проекты ПЛК и SCADA начинают вести как код, у команды появляется главное - предсказуемость. Понятно, какая версия стоит в проде, кто внес изменение, кто его проверил и как безопасно откатиться, если что-то пошло не так.
Короткий ответ
Для АСУ ТП не нужен “идеальный DevOps с первого дня”. Нужны четыре вещи: единый репозиторий, понятные ветки, релизы с тегами и обязательное ревью критичной логики. Этого уже достаточно, чтобы убрать хаос из внедрения и эксплуатации.
Почему в OT это особенно важно
В IT ошибка в релизе может стоить конверсии. В производстве ошибка в логике может стоить смены, партии продукции или аварийной остановки. Поэтому в OT версия - это вопрос не удобства, а управляемого риска.
Самая опасная практика - “быстрые правки напрямую в бою”. Они кажутся эффективными, пока не случается инцидент. Потом выясняется, что в ПЛК загружен файл, которого нет в архиве, SCADA обновлена частично, а откатиться можно только “примерно”.
Git/LFS или вендорные инструменты
Спор “что лучше” обычно не главный. Главное, чтобы система версий давала прозрачную историю и повторяемый релизный процесс.
Если проекты в основном текстовые и команда готова к Git, хорошо работает связка Git + LFS для крупных бинарников. Если экосистема вендора сильно завязана на свои форматы, можно использовать встроенные инструменты. На практике часто выигрывает гибрид: бинарные артефакты там, где им место, а процесс релизов и документация - в общем контуре версионирования.
Ключевое правило одно: у команды должна быть одна точка правды по версиям.
Релиз в АСУ ТП: что обязательно зафиксировать
Хороший релиз в промышленной автоматизации - это не только коммит и комментарий. Это пакет, где заранее зафиксированы состав изменений, риски, окно работ и план отката. Если этого нет, релиз по сути неуправляем.
Минимум, который должен быть у каждого выпуска:
•тег релиза на точной версии проекта;
•короткие release notes человеческим языком;
•перечень затронутых контроллеров, экранов SCADA и сервисов;
•подтверждение ревью критичной логики;
•проверенный сценарий rollback.
Так даже новая смена понимает, что именно выкатывалось и что делать при сбое.
Ревью кода для PLC/SCADA: на что смотреть в первую очередь
В обычном проекте можно ограничиться стилем и компиляцией. В АСУ ТП этого недостаточно. На ревью в первую очередь смотрят interlock-логику, permissive-условия, аварийные переходы и все, что влияет на безопасный режим работы.
Хорошая практика - отдельный чек ревью для safety/security-правок. Тогда “маленькое изменение таймера” не проходит как бытовая мелочь, а оценивается по реальному влиянию на процесс.
Пример политики веток (main/develop/release) под АСУ ТП
Ниже рабочий вариант, который обычно внедряется без боли даже на действующем объекте:
Что важно именно для производства:
•все выкладки привязаны к согласованным окнам;
•прямые изменения “с инженерного ноутбука в контроллер” запрещены;
•для каждого релиза фиксируется версия as-loaded на объекте;
•любые аварийные исключения потом обязательно оформляются в репозитории.
Как внедрить это без остановки текущей работы
Обычно работает спокойный сценарий в три шага. Сначала фиксируют текущий baseline по контроллерам и SCADA, чтобы у команды появилась точка отсчета. Затем вводят минимум процесса: ветки, pull request и release tags. И только после этого добавляют более строгие правила ревью и автоматизацию.
Если пытаться внедрить “всё и сразу”, команда начинает обходить процесс. Если запускать поэтапно, дисциплина приживается и реально помогает в эксплуатации.
Где уместен СТАБУР
Когда одинаковые подходы нужно тиражировать между участками и площадками, особенно важны единые правила версий и релизов. В платформенном подходе, включая проекты на базе решений СТАБУР, проще удерживать общий стандарт branch-политики, ревью и отката без “локальной самодеятельности”.
Заключение
Версионирование PLC/SCADA - это не про красивые инструменты, а про управляемые изменения. Когда команда знает, что в проде, как это туда попало и как безопасно вернуться назад, снижается и технический риск, и организационный стресс вокруг каждого релиза.
FAQ
Можно ли обойтись без Git?
Можно, если вендорный инструмент дает ту же трассируемость, контроль доступа, ревью и воспроизводимый откат.
Зачем теги релизов, если есть дата в имени файла?
Дата не гарантирует точный состав изменений. Тег связывает релиз с конкретным состоянием проекта.
Кто должен approve изменения в safety-логике?
Минимум инженер АСУ ТП и ответственный за эксплуатацию/безопасность.
Hotfix без ревью допустим?
Только как аварийное исключение с обязательным последующим оформлением и пост-ревью.
Как понять, что процесс уже работает?
Если команда за несколько минут отвечает на три вопроса: что сейчас в проде, что изменилось в последнем релизе и как откатиться.