На промышленном предприятии у одной и той же программы ПЛК иногда оказывается две версии. Одна хранится в репозитории и считается эталонной. Вторая фактически работает на контроллере и меняется по мере наладки, ремонта и доработок оборудования. Пока производство выполняет план, расхождение между ними остается незаметным. Проблема возникает тогда, когда нужно восстановить систему или понять причину отклонения.
Так произошло на одном горнодобывающем предприятии. Расчетный ресурс бура составлял год, поэтому замену оборудования заранее включили в график и запланировали закупку. Однако за полтора месяца до установленного срока система контроля состояния обнаружила повреждение. Бур изнашивался быстрее, чем было заложено в расчетах. При проверке рабочих параметров выяснилось, что скорость бурения меняли. Новое значение не выходило за допустимые пределы, поэтому штатная сигнализация не сработала. Само по себе это изменение еще не доказывало причину ускоренного износа. Чтобы установить связь, нужно было понять, когда именно его внесли, кто это сделал и как долго установка работала в новом режиме. Восстановить эту цепочку не удалось. Из-за нехватки дискового пространства старые записи в журнале операций перезаписывались новыми. Истории изменений проекта контроллера тоже не было. Правку могли внести за девять месяцев до обнаружения повреждения, но подтвердить это оказалось невозможно. Формально аварийного события не произошло, но установку пришлось остановить, и плановая поставка была сорвана.
Так проявляется дрейф конфигурации. Программа на контроллере постепенно расходится с версией, которую предприятие считает эталонной. Пока оборудование работает, разница не видна. Она становится критичной в тот момент, когда нужно восстановить ход изменений и опереться на сохраненный проект. Раньше такие расхождения возникали реже, поскольку значительная часть логики была реализована в оборудовании и менялась нечасто. Теперь управление техпроцессом все сильнее зависит от кода, а значит, каждая наладка, модернизация или новый нештатный сценарий добавляют очередную правку.
Программный слой вырос быстрее контроля версий
Все чаще работу оборудования определяет код. Программы для станков с ЧПУ, роботизированных ячеек и дискретных линий приходится регулярно дорабатывать. Причина не только в развитии самого производства. Ни одну систему нельзя сразу описать с учетом всех возможных отклонений. Основной сценарий инженер закладывает на этапе проектирования, а обработку нештатных ситуаций добавляет уже по опыту эксплуатации. Датчик начал выдавать неверные значения, повредили кабель, отказал модуль ввода-вывода: каждый такой случай требует новой правки. Поэтому число версий неизбежно растет, а практика их фиксации часто не успевает за реальными изменениями.
Импортозамещение усилило этот разрыв. Раньше линию могли заказать под ключ у одного поставщика, с единой платформой и понятным набором инструментов. Теперь на одной площадке работают контроллеры нескольких вендоров, а проекты меняют разные подрядчики и штатные инженеры. У каждой платформы свои особенности, поэтому подход, привычный для одного контроллера, не всегда работает на другом. Часть различий проявляется только на реальном объекте, поскольку стенд не воспроизводит всех режимов.
Особенно много правок возникает во время пусконаладки. Инженеры корректируют логику под фактическую работу оборудования, а документирование не успевает за изменениями: главная задача — запустить линию. В результате уже на этом этапе файл в хранилище начинает расходиться с программой на контроллере.
После запуска главным риском становится рутина
Инженер выполнил производственную задачу, поправил логику и убедился, что оборудование работает. Но изменение не описал, а обновленный файл не загрузил в хранилище. Он не пытался нарушить правила. Просто процесс фиксации правок либо не выстроен, либо существует только на бумаге.
Одна незаписанная правка сама по себе еще не обязательно приводит к проблеме. Риск накапливается, когда изменения переходят от одного участника к другому без передачи контекста. Например, дежурный корректирует программу в ночную смену и уходит, а программист выходит утром и о правке не знает. Или подрядчик отлаживает линию по гарантии, но не передает исходники. Или инженер увольняется, и вместе с ним уходит понимание того, что менялось в проекте последние три года.
Формальные процедуры эту потерю не компенсируют. Резервную копию сняли, но не проверили, можно ли с ее помощью восстановить систему. Изменение описали одной строкой, из которой нельзя понять его причину. Регулярной сверки с программой на ПЛК нет. В результате хранилище существует, но подтвердить достоверность его содержимого нельзя.
Слабый контроль доступа дополнительно мешает установить автора правки. На части объектов отдельного пароля нет, на других вся смена работает под одной учетной записью. Если правила доступа мешают действовать в аварийной ситуации, персонал начинает их обходить.
В такой системе несанкционированное изменение внешне почти не отличается от штатной работы инженера. Контроллер продолжает работать, но определить, кто, когда и зачем изменил программу, уже невозможно.
Хранилище есть, уверенности нет
Вернуть утраченный контекст не поможет и формальное хранилище, если актуальность его содержимого никто не проверяет. На многих предприятиях его роль выполняет сетевая папка с каталогами по установкам и контроллерам. Аудитору такую структуру показать можно. Но определить по ней, сколько изменений внесли после сохранения файлов, нельзя.
Даже если копии обновляются регулярно, этого может быть недостаточно для восстановления. Исходный проект, резервная копия с контроллера и фактические настройки оборудования содержат разную информацию.
Исходный проект нужен инженеру для работы с логикой программы. В зависимости от платформы с контроллера выгружается либо скомпилированный образ, либо низкоуровневое представление кода. На старых ПЛК вместо имен переменных в такой выгрузке остаются адреса памяти, а таблица символов хранится только в среде разработки. Восстановить логику по этой копии возможно, но на остановленной линии времени на такую работу уже нет.
Отдельно существуют уставки, которые появляются при настройке оборудования на площадке. Программу разрабатывают для линейки станков, а конкретный экземпляр доводят под реальные условия. Например, если головка не доходит до заданной точки на несколько миллиметров, значение корректируют на месте. Эта настройка может остаться только в контроллере и не попасть в исходный проект.
Поэтому для восстановления нужны как минимум две составляющие: исходники, по которым инженер понимает логику программы, и слепок фактического состояния ПЛК со всеми настройками конкретного оборудования. Одно без другого не дает полной картины. Если сохраненная версия не совпадает с фактической, восстановление затягивается независимо от первопричины сбоя. Сгорел модуль ввода-вывода, заменили контроллер или обнаружили ошибку в логике: в каждом случае предприятию нужна достоверная конфигурация, которую можно загрузить и проверить.
Потери не ограничиваются продолжительностью отдельного простоя. У линии есть нормативный цикл выпуска и резерв времени на техническое обслуживание. Если этот резерв регулярно уходит на восстановление утраченного контекста, производство перестает укладываться в план. Такие отклонения повторяются, но могут не попадать в отчетность как самостоятельные инциденты.
Поэтому нужен единый доверенный источник, где хранятся схемы, исходные проекты, резервные копии и сведения обо всех правках. Его создание начинается с инвентаризации: нужно найти материалы, убрать дубли и сопоставить сохраненные файлы с фактическим состоянием оборудования.
Сам по себе документ еще не гарантирует, что команда сможет восстановить систему. Проверить это просто: передать проект другому инженеру и попросить объяснить логику программы и порядок восстановления. В программировании такой разбор называют ревью кода. В АСУ ТП он покажет, сможет ли команда восстановить систему без участия автора проекта.
Понять проект мало, нужно сверить его с ПЛК
Инвентаризация дает достоверную точку отсчета, но она быстро устаревает, если после каждой правки данные не обновляются. Поэтому следующим шагом становится регулярная сверка сохраненной копии с тем, что фактически загружено в ПЛК. Контрольная сумма показывает, что файл изменился, но не объясняет, в чем состоит правка. Более точная проверка сопоставляет две версии и показывает конкретные расхождения. Частоту сверки определяет техпроцесс. Если линия долго работает без доработок, может быть достаточно ежемесячной проверки. Во время пусконаладки, модернизации или устранения неисправностей изменения вносят чаще, поэтому и сравнивать конфигурации нужно с меньшим интервалом. Среды разработки вендоров умеют выполнять такую проверку для своих контроллеров. Сложность возникает в разнородном парке, где для каждой платформы нужен отдельный инструмент. Ручная сверка превращается в постоянный обход инженера с ноутбуком, а руководитель все равно не получает общей картины.
Система контроля версий проектов ПЛК решает эту задачу централизованно: сопоставляет сохраненные проекты с программами на контроллерах и ведет историю по всему парку. Но одного обнаружения расхождения недостаточно. Для каждой правки нужно сохранить контекст: что изменили, зачем и на каком основании. Короткого комментария может хватить штатной команде АСУ ТП, которая сама разрабатывает программу. Если линию передает подрядчик, описание должно быть понятным инженеру предприятия без участия автора.
Это требование нужно закрепить и в договоре. Изменения подрядчика должны попадать в тот же процесс: кто выгрузил программу, что исправил и когда загрузил ее обратно. Поэтому главный сдвиг здесь управленческий, а не технический. Контроль версий должен работать постоянно, а не только во время подготовки к проверке. Если предприятие три недели приводит данные в порядок перед аудитом, оно управляет не состоянием системы, а впечатлением о нем.
Когда линия остановится, восстановить ее поможет только достоверная конфигурация, а не успешно пройденная проверка.
