Система управления обогатительной фабрики, спроектированная 10–15 лет назад, работает без поддержки производителя. Обновлений нет, запасные модули официально не поставляются, специалистов, знающих платформу, на рынке почти не осталось.
Типовой ответ на такую ситуацию — проект полной замены: новая платформа, новый верхний уровень, новая логика. Для фабрики это сотни миллионов рублей и годы работы, а остановы на переключение приходится вписывать в производственный план.
Есть третий путь: удержать систему в работоспособном состоянии на 5–7 лет и за это время провести миграцию поэтапно, без аврала. В международной практике такая работа называется управлением устареванием, для неё есть стандарт IEC 62402. Дальше — как она устроена.
Об АСУ ТП удобнее думать не как об одном объекте, а как о трёх слоях с разными сроками жизни.
Планировать надо не «замену АСУ ТП», а отдельную стратегию для каждого слоя. Больше всего внимания требует контроллерный уровень — он самый устойчивый и самый дорогой в замене.
Без реестра оборудования остальные шаги делать бессмысленно. На большинстве предприятий реестра нет — есть проектная документация, которая за годы эксплуатации разошлась с фактом. Минимальный набор полей:
| Поле реестра | Зачем нужно |
| Артикул, серия, версия прошивки | Основа для поиска на рынке и для оценки взаимозаменяемости |
| Место установки: номер шкафа, технологический участок | Определяет критичность и условия эксплуатации |
| Количество в работе | База для расчёта глубины резерва |
| Наличие в резерве, состояние резерва | Резерв, который никто не проверял пять лет, резервом не является |
| Доступность на рынке, срок поставки | От неё зависит, что покупать первым |
| Наработка или дата ввода | Позволяет прогнозировать износ по сроку службы |
| Наличие проекта, конфигурации, прошивки | Отдельная строка — см. шаг 5 |
Инвентаризация обычно вскрывает две вещи: часть позиций уникальна и не имеет резерва вовсе, а часть резерва физически есть, но неработоспособна или не той ревизии.
Каждую позицию реестра оценивают по двум осям: насколько критичен отказ для технологического процесса и насколько доступна замена.
| Группа | Стратегия |
| Критично, замену не найти | Максимальный приоритет. Резерв обязателен, восстановление отказавших изделий, первоочередная миграция при планировании |
| Критично, замена доступна | Резерв по сроку поставки, обычное плановое обслуживание |
| Некритично, замену не найти | Восстановление по факту отказа, накопление ремонтного оборота, миграция во вторую очередь |
| Некритично, замена доступна | Действия по факту отказа, резерв не нужен |
Смысл матрицы в том, чтобы деньги и внимание уходили в первую строку, а не распределялись ровным слоем по всему парку. На практике в неё попадает небольшая доля номенклатуры, и именно она определяет, встанет фабрика или нет.
Глубину резерва считают, а не берут с потолка. Логика такая: запас должен покрывать время, за которое изделие возвращается в работу, с поправкой на вероятность одновременных отказов.
Для позиций, которые ещё продаются, всё просто: смотрим срок поставки и допустимое время простоя. Для позиций, которых на рынке нет, работает оборот: одно изделие работает, второе в ремонте, восстановленное возвращается в резерв. Двух единиц на позицию обычно достаточно, и это дешевле, чем держать склад однотипных модулей.
Отдельный случай — момент, когда производитель объявляет снятие изделия с производства. Тогда действует закупка на весь оставшийся срок службы системы (в стандарте это называется life-of-need buy). Решение считают так: сколько системе ещё работать, как часто отказывает позиция по своей статистике и что дешевле — закупка или простой с поиском на вторичном рынке. Здесь важно не опоздать: окно, когда изделие можно купить новым, закрывается, а вторичный рынок предлагает изделия с неизвестной наработкой.
Резерв нужно проверять. Модули, годами лежащие на складе, деградируют: стареют компоненты, разряжаются батареи памяти, окисляются контакты. Регламент периодической проверки резерва — обязательная часть стратегии, иначе в момент аварии выяснится, что подмены нет.
Для критичных позиций, которых нет на рынке, восстановление часто оказывается единственным практическим способом поддерживать резерв. Возможность компонентного ремонта промышленных контроллеров и модулей ввода-вывода не отменяется самим фактом снятия изделия с производства: во многих случаях восстанавливаются отдельные элементы платы.
Два условия, без которых схема не работает. Первое: восстановленное изделие должно пройти испытания под нагрузкой и наработку перед возвратом в резерв. Модуль, проверенный только на прозвонку, в резерв ставить бессмысленно. Второе: если причина отказа была вне изделия — питание, среда, наводки, — оно вернётся в ремонт снова. Ревизия платы без поиска внешней причины оплачивает симптом.
Самая частая причина экстренной замены системы — не отказ оборудования, а утрата проектов, конфигураций и доступов. Хранить централизованно, с версиями и с проверкой восстановимости:
Проверка восстановимости не формальность: нужно хотя бы раз убедиться, что из архива действительно разворачивается рабочая конфигурация. Архив, который никто не пробовал развернуть, это не архив.
Сюда же относится вопрос прав. Лицензии и ключи позволяют работать сегодня. Дальше начинается то, о чём вспоминают позже: на каких условиях предприятию переданы права на использование ПО, что произойдёт с проектом, если подрядчик исчезнет, можно ли получить исходные тексты или хотя бы их депонирование. IEC 62402 прямо называет исходный код и права на интеллектуальную собственность предметом управления устареванием. Практический вопрос простой: если завтра менять подрядчика или среду разработки, у предприятия есть всё, чтобы продолжить работу, а не начинать заново?
Систему редко приводят в состояние «нет ни прошивок, ни исходных проектов» злым умыслом. Так выходит, когда электронику не считают активом, который требует постоянного сопровождения: версии прошивок нигде не зафиксированы, резервные копии не делаются, изменения логики вносятся «на ходу» и не документируются, а исходные проекты у поставщика никто не забирал.
Заканчивается это одинаково: отказ, поиск специалиста, сохранившего старую среду разработки, покупка модуля на вторичном рынке вслепую и простой, который стоит больше всей этой суеты. Дороже всего обходится не ремонт промышленных контроллеров, а отсутствие информации.
Правило, которое стоит ввести сразу: исходные проекты контроллеров, прошивки и лицензии забирают у поставщика в момент сдачи системы, а не через десять лет, когда они понадобились. Это одна строка в договоре, которая потом экономит месяцы.
Старая операционная система на операторской станции — это не только вопрос удобства замены. Обновлений безопасности для неё нет, антивирус на промышленной станции мешает реальному времени, а сеть АСУ ТП часто связана с остальной инфраструктурой предприятия.
Пока идёт поэтапная миграция, уязвимость нужно закрывать организационно и технически, и для этого есть отдельный стандарт — IEC 62443, кибербезопасность промышленных систем. Речь о базовых вещах: разделить сеть на зоны и каналы, не выпускать контур АСУ ТП наружу, ввести регламент съёмных носителей, развести учётные записи, держать резервные копии конфигураций.
Управление устареванием не отменяет модернизацию, а делает её планомерной. Разумная последовательность идёт сверху вниз.
Сначала обновляется верхний уровень: серверы, операторские станции, промышленные компьютеры, при необходимости SCADA. Это наименее рискованный слой, и он же часто оказывается узким местом. Затем сеть и коммуникации, включая шлюзы протоколов, которые позволяют новому верхнему уровню работать со старыми контроллерами. И только в последнюю очередь меняется контроллерный уровень: участок за участком, а не разом.
Про шлюзы отдельно. Это не бесплатное решение, а новый объект сопровождения: свои лицензии, обновления, диагностика и задержка при передаче данных. При высокой частоте опроса шлюз становится узким местом. Поэтому шлюзы включают в реестр на тех же правах, что контроллеры, дублируют по критичности, а до пуска проверяют задержку и полноту передачи сигналов.
Такая последовательность даёт смешанную конфигурацию на несколько лет. Это нормальное рабочее состояние, а не переходный дефект. Главное, чтобы смешанность была спроектирована, а не сложилась стихийно.
Стандарт требует измерять результат, и это разумно: без цифр программа управления устареванием превращается в список намерений. Достаточно пяти показателей:
• Закупать бывшие в употреблении модули без входного контроля и испытаний. Внешне исправный модуль с неизвестной наработкой – это не резерв, а отложенный отказ.
• Вносить изменения в логику без документирования. Через два года фактическая конфигурация не совпадёт ни с одним сохранённым проектом.
• Откладывать инвентаризацию до момента, когда дойдут руки. В аварийной ситуации реестр составить невозможно, а нужен он именно тогда.
• Начинать замену с контроллерного уровня. Это самый дорогой и самый рискованный слой, начинать с него — значит принять максимальный риск в самом начале проекта.
• Держать резерв, не проверяя его. Нерабочая подмена в нужный момент равна отсутствию резерва.
Ограничение задаёт не платформа, а доступность компонентов и наличие компетенций. При реестре, резерве и восстановлении горизонт в 5–7 лет реалистичен для многих систем, спроектированных в 2010-е. Это экспертная оценка, а не норматив: у каждой системы свой запас. Дальше решающим становится не железо, а способность поддерживать логику, потому что специалисты, знающие среду разработки, постепенно уходят с рынка.
Сначала попробовать выгрузить из контроллера то, что он отдаёт, и восстановить документацию по факту. Нужно учитывать: выгрузка часто не возвращает полный исходный проект, в ней может не быть символики, комментариев и части служебных данных. После отказа контроллера задача меняется принципиально: логику восстанавливают по технологическому регламенту и опросу персонала, а это уже не ремонт, а проектирование заново.
Посчитать, сколько таких изделий у вас работает и как часто они отказывают, затем оценить закупку на весь оставшийся срок службы системы. Окно, когда изделие можно купить новым, закрывается быстро, а вторичный рынок – это лотерея. Параллельно нужно понять, есть ли у позиции совместимый аналог и что потребуется для его установки: ревизия, прошивка, изменения в проекте.
Не всегда: зависит от платформы и от того, насколько различаются прошивки. Проверять это нужно заранее, при формировании резерва, а не в момент аварийной замены. Ревизия и версия прошивки поэтому и стоят в реестре отдельными полями. Проверку делают на стенде, а не на работающей системе.
Обновлений безопасности для неё не выходит, а сеть АСУ ТП часто связана с остальной инфраструктурой. Пока идёт миграция, риск закрывают разделением сети, запретом выхода наружу, регламентом носителей и резервными копиями конфигураций (ориентир — IEC 62443).
Это решение всего предприятия, а не отдельной фабрики, и реализуется оно годами. Управление устареванием и миграция не противоречат друг другу: первое даёт время, чтобы второе прошло по плану, а не под давлением очередного отказа.
С инвентаризации контроллерного уровня и с проверки того, что проекты, прошивки и лицензии существуют и восстановимы. Обе задачи выполняются силами службы АСУ ТП и дают основание для всех последующих решений.
Автор: Владимир Самоваров, ведущий эксперт ООО «Инженерная компания «555».
Спасибо!
Теперь редакторы в курсе.